サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
ドラクエ3
mayah.jp
先日、某VC投資先の方々に対して、「ソフトウェアエンジニアの採用時にコーディングテストをやりたいがどうしたら良いか？」ということについて語ってきたので、こちらにもエッセンスをまとめたいと思います。 コーディングテストの目的 なぜ我々はコーディングテストをやるのでしょうか？ もちろん、第一目的はソフトウェアエンジニアの採用候補者のスキルを見極めるためです。 過去に、経歴も良さそう、技術的な議論もスムーズにできる、なのにコードが書けない候補者に、私は何度か出会っています。「コードが書けない」のレベルは、（ある程度易しい）論理をプログラムに翻訳できず、まともな if 文が書けないというレベルを言っています。熟練者でもド・モルガンの法則をうっかり間違えるぐらいはあると思いますが、そういう話ではありません。コードが書けない候補者は、そもそも条件が書き下せません。このような候補者を雇ってはいけません。
一定時間内に題意を満たすようなプログラムを、よりたくさん、より高速に書くことを競うプログラミングコンテスト、およびその形式のことはしばしば「競技プログラミング」と呼ばれています。今となっては当たり前となった言葉ですが、私が現役でこのような競技に参加していた頃 (2005年まで) はそのような言葉はなく、単に「プログラミングコンテスト」と呼ばれていました。 さて、競技プログラミングという言葉はいつ生まれたのでしょうか？ 一部では “competitive programming” の訳語であると思われていますが、実はそうでもないのです。 自分の体験談を少し振り返ると、私が YUHA で競技プログラミングに関連する同人誌的なものを書き始めた 2008 年夏 (C74) には、「競技プログラミング」という言葉はまだ広くは知られてはおらず、同人誌中でも競技プログラミングという言葉は使われていません
主に友人知人向けへの周知です。2019 年 3 月末で G を退職しています。 何か新しいことをやろうと思って水面下で様々準備していたのですが、事業を 0 から起こすというのは経営のスキルも足らずなかなか難しいなと攻めあぐねていたところ、前前職 (W) の上司の紹介で VISITS technologies の CTO 職をやってほしいという話になり、社長と話してみるとやりたかった事業ドメインに近かったため、引受けてみることにしました (万が一事業に失敗したらどこか拾ってください)。 いわゆる退職エントリはドラフトを長々と書いてみたのですが、書いた結果あんまり公にすることではないなと思ってお蔵入りにしました。積もる話は直接聞いてください。 現在丸の内勤務になったので、主に丸の内近辺の方(わかる範囲だとPFNとかTDとか)、遊んでください。ただ、G の頃より異常に忙しいので（これがスタートア
OCamlとは OCaml は Haskell とは違って純粋でない関数型言語です。ML (Meta Language) という言語ファミリーの方言の一つで、フランスの INRIA という研究所で開発されています。速度を稼ぐために命令型のように書こうと思えば書けるし、遅延評価もデフォルトではしません。その分、実用的なアプリケーションが書きやすくなっています。 他の言語をある程度知っている人は、これを読めば OCaml のとりあえずの基礎をマスターして OCaml を書くことができるようになります。他の関数型言語の知識は仮定していませんが、C/C++ ぐらいの知識があれば読めると思います。元の Perl 基礎文法最速マスターではリファレンスぽい作りですが、チュートリアルぽくなってしまいました。 なお、読んでいると分かりますが、色々とめんどくさいことが多いように感じます。しかし、これをちゃんと
ここ5年ほど pre commit review があるような環境(主に chromium とか)で働いてきたので、コミットメッセージの書き方を自分なりにまとめておきます。 コミットメッセージで伝えたいことはパッチのコンテキストである コミットメッセージはコードレビュー依頼であるという態度で記述します(受け売り)。そのため、コードレビュー者がパッチのコンテキストを理解できるように記述するべきです。なにをやっているのか分からないパッチを渡されるより、これはこういう理由でこういう変更をやっているパッチだということを伝えてからパッチを見たほうが、パッチの理解も速いでしょう。レビュー者にパッチのコンテキストを理解してもらえれば、コードレビュー速度が上がったり、コードのミスが見つけてもらいやすくなるという利点があります。 コミットメッセージの基本的なフォーマット コミットメッセージには一般的に使われ
ちょっと行列演算をしたかったので適当にコードを書き散らしていたのですが、速度が必要な演算であるために既成のライブラリを使うこととしました。今回は行列乗算ができれば良いのでBLASを生で使ってもそんなに問題ありません。BLASの中でも高速な実装であるOpenBLASを使い、適当に書いたコードと速度の比較をしてみます。 結論から言うと、OpenBLASの速さを舐めてました。まさか50倍の速度差がでるとは。 比較に用いたマシンは、MacBook Pro 2013 Late 13 inch (2.4 GHz Intel Core i5) です。 インストール Macの場合はbrewで。LinuxでもOpenBLASのパッケージはたいていのディストリビューションにはあると思います。
OCaml は Haskell とは違って純粋でない関数型言語です。ML (Meta Language) という言語ファミリーの方言の一つで、フランスの INRIA という研究所で開発されています。速度を稼ぐために命令型のように書こうと思えば書けるし、遅延評価もデフォルトではしません。その分、practical なアプリケーションが書きやすくなっています。 他の言語をある程度知っている人はこれを読めば OCaml のとりあえずの基礎をマスターして OCaml を書くことができるようになります。多分。関数型言語の知識は仮定していません。C/C++ ぐらいの知識があれば読めると思います。元の Perl 基礎文法最速マスターではリファレンスぽい作りですが、チュートリアルぽくなってしまいました。 なお、読んでいると分かりますが、色々とめんどくさいことが多いように感じます。しかし、これをちゃんと書く
気がついたら１年近くも MAYAH.JP は更新されてなかったのですね。というのも体調をある種崩したっきりなのが悪いんですが。 さて、この記事は Competitive Programming Advent Calendar の 23 日めの記事です。 競技プログラミングについて書かれた書籍はあまりありません。日本語であげるなら、次の２つが有名だと思います。 プログラミングコンテストチャレンジブック 目指せ!プログラミング世界一―大学対抗プログラミングコンテストICPCへの挑戦 また最近知った本で英語で競技プログラミングとはあんまり関係ない本のですが、Cracking the Coding Interview: 150 Programming Interview Questions and Solutionsという本もあるようです。おもしろかったので参考までに。 今回の話はそういう本ではな
いろいろ思いつくけど、時間がないのでブログに書いて誰かにやってもらおう or 教えてもらおう or 調べてもらおうのコーナー第１弾。今回のように、思いついたけど時間がないので自分がやらないと決めたアイデアは全部公開していくことにしたい。 バランスシートには、資産、負債、純資産の項目があり、資産＝負債＋純資産が常に成り立つ。ソースコードを資産だと思うと、それは負債と純資産からなっている。 では、負債や純資産とは何か。負債は後で返さなくちゃいけないものだ。借りておくと利子も発生する。これに対応するのは汚いコードである。後で書きなおさないといけないし、書きなおさなければ利子が溜まって保守性などに影響し、最終的にコードが破綻する。技術的負債という単語があり、まあ、これのことだ。純資産は、うまく定義できなかったので、ここでは負債ではないものというふうにここで定義しよう。 次にやりたいのは、負債がどれ
http://partake.in/ デモページ イベント管理支援ツールといえば ATND が有名です。しかし、ATND は参加者にメッセージが送れないなどの不満点があります。イベント主催者からさんざん不満点を聞いているのに、何故か代替サービスがなかなか現れないので自分でつくってしまいました。 ATND と何が違うのか？ まず、よく聞く ATND の不満点をおさらいします。 参加者に連絡を取ることが出来ない。 イベントに参加登録をしたことを忘れてしまう 行けるかどうかわからないイベントでもとりあえず登録をしておくため、ドタキャン発生率が高い。 PARTAKE はこの３つの不満点の解消を狙っています。もちろん、まだ発展途上であるため、全てが解決されているわけではありません。しかし、解決のために改良し続けます。 参加者への連絡手段 PARTAKE では、イベント参加者の連絡手段を確保するため
18日金曜日から21日月曜日まで、ICFP Programming Contest 2010 に参加。 今回は初めは俺言語で出るために一人で出ていたのだが、途中でチーム Oh!tomaton に 合流した。チーム Oh!tomaton は、tsukuno, kinaba, mayah の３人。順位は２７位のようだ。二人のブログは、d.y.d. となんとなくな日々のコメントにある。 あと、俺言語で出るという目標を掲げていたが、一応一人の時は使っていた。機能は絶対的に足りないので OCaml と ruby も併用していたが...。３人になってからは OCaml, ruby, C++, Java, D あたりが使われていた。tsukuno は PHP も使っていたらしい。 はじめ とりあえず問題を 15 分ぐらい書けて読む。 今回のタスクは、お金を稼ぐこと！ らしい。どうやってお金を稼ぐかとい
Java で main メソッドの中にコードを書くと数割遅くなるという現象に遭遇。Sun の JDK 1.4, 1.5 では再現する。1.6 では再現しない。1.5 を使っている人はまだいくらかいるだろうから (1.4 は保守関連の需要しかないものだと信じたいが)、注意喚起も兼ねてまとめる。 事の発端 あるフレームワークのオーバーヘッドを計りたいので、フレームワークを使わずに重い計算をした場合とフレームワークを使って計算した場合の、速度差を比較しようとした人がいるだのが、「フレームワークを使った方が速い」という結果が得られた。 誰もがそれは何かの間違いだろうと思ってコードを見るが、誰も間違いを見つけることが出来ない。そのうち「main に計算を書くと遅いんじゃね？」と誰かが言い出したのだが、誰も信じようとはしなかった。そりゃそうだわな。 わけがわからんので、まあ試さないよりはよいだろうと思
唐突だけど、11月末で IBM を辞めることになった。別にリストラされたわけではなく、自分で決めたことなので誤解なきように。引き留めは丸３日も続いてかなりヘトヘトになった。 辞める理由はいくつもある。私にダメージを与えるような出来事などがいっぺんに色々来て、そのとき以来自分の仕事上でのパフォーマンスが非常に落ちた。成果は出してないワケではないのだけど、心理的に非常につらかった。さらに、会社が私に求めていることと、私がやりたいことがすごく乖離しまった。また、その頃から組織のあり方に関して色々喚いて何度か上に議論をふっかけたのだがその議論も平行線をたどっただけだった。 この１年の一番の反省点は、組織のことは喚いたが、自分のことは喚くのが圧倒的に不足していたことだ。また、入社当時に「ソフトウェア系ならなんでもやるよ」的なことをちょっと言っていたのだが、いつのころからか本当にただのなんでも屋になり
だいぶ遅くなってしまいましたが BRIDGE 2009 に参加した記録です。津田さんが来てた keynote session は残念ながら聞けていないので、その後の session についてのまとめです。聞いている分だけしかまとめられないので、後は適宜リンク集で補足します。 Session 5: 若手起業セッション 若くして起業した人に話を聞くセッション。質問があらかじめ用意されていて、それに何人かが答えるという形式で行なわれた。全てを書くと大変なので、面白い回答があった質問だけいくつかまとめる。 何故起業したのか ほとんど全員の答えが、自分のやりたいことをやりたかったから。しかし、「自由にやりたいことをできると思ったが結局雑務などの土方の仕事が多い。起業前では上司から仕事をもらっていたのが起業後ではそれがお客さんになっただけで、ある意味特に変わってない。」という意見が後の質問項目の回答で
凡例 過去の国内予選の問題を全て実装・分析してみました。 難易度は☆５段階で表しています。★は☆半分を表します。 ☆ ：非常に易しい。全員が解いてほしい問題。 ☆☆ ：易しい。アジア地区予選に進む為には絶対に解かなければならない。 ☆☆☆ ：標準。アジア地区予選に進む為にはこのクラスの問題を１つは解けなければならない。 ☆☆☆☆ ：難しい。上位に食い込む為には解かなければならない。 ☆☆☆☆☆：大変難しい。上位陣でも難しい。 解法・アルゴリズムでは、キーとなるアルゴリズム名を書いています。ad-hoc と書いてあるものは、その場その場で実装して解いていく問題を表しています。 ソースは、私が解いたソースへのリンクを張っています。 公式の output や PKU での問題と解答を比較していますが、解答が提供されていない問題もあるため、正答と比較出来ない場合が有ります。その場合備考
ちょっと遅れたけど参戦するよ。 プログラミングテクニックのまとめ 中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント 優秀なプログラマは空気を読んで空気を描く 槍玉に挙がっているのは、次の３か条。 変数のスコープは小さく抑える Do Not Repeat Yourself (DRYの原則) 同じコードは2度書くな 言語を極めよ 何人かは「ケースバイケース」だと言ったし、それは間違ってない。しかしケースバイケースだと言うのは簡単だがこれは何にも指針を示してない。ケースバイケースだと言われた側は、結局そこから何も学ぶことが出来ない。納得はしちゃうかもしれないけどね。こういうエントリを読んだってことは何かを知りたかったわけだよね。だとしたら、何か曲がりなりにでも指針が示されるべきじゃないかな。というわけで僕なりの指針を示したいと思う。 さて、この中で Le
Recent Update2008-10-14: [書評] 要するに 2008-10-05: [書評] 1984 年 2008-10-01: ICPC 国内予選 全解 2008-10-01: ACM-ICPC 国内予選・アジア地区予選・世界大会 2008-10-01: ACM-ICPC 国内予選
make とは make は、決められた規則に従って必要なコマンドを自動的に実行してくれるツールです。もともとは C 言語のコンパイル・リンクを行うために作られましたが、現在ではソフトウェアのインストールや一時ファイルの消去など、様々な場面で使われています。 make は、更新時刻を見て必要なファイルのコンパイルだけを行ってくれるなど、ソフトウェアの生産性を大幅に向上させることが可能です。 make を使うためにすることは、Makefile と呼ばれる設定ファイルを書くことだけです。Makefile を書けば、後は makeと叩くだけで必要なことが全て行なわれます。 最初の Makefile まず簡単な Makefile の書き方を説明します。ここでは、prog1.c, prog2.c という C 言語のソースと、ライブラリ libm.a を使って、実行ファイル prog を作ることを考え
C/C++, Java は使える、大学で ML とか Scheme もやった、そろそろスクリプト言語を覚えたい、という人向けに、一時間で Ruby がある程度 (日常的な処理が少しは出来る程度) 使える様になるまでをまとめます。他のスクリプト言語の知識は仮定しません。 このページでは、例示による学習を期待しています。すなわち、例と結果を与えられることでその意味を理解するということです。これが出来ないと一時間で使えるようになるのは厳しい。オブジェクト指向、正規表現と聞いて一つでも意味が分からない人は別のところで勉強してください。速習を目指しているので、細かいところは全部割愛しています。とりあえず使えるようになった後にちゃんとした入門書を読んでください。 とりあえず動かす (10 分) Ruby はインストールされているものとします。とりあえず ruby と叩いて起動。 $ ruby 出力でき
この記事は長い間メンテナンスされていません。間違いがいくつか含まれています。このままでもある程度は役に立つと思いますが、正確な仕様は W3C の文書を参照してください。 この文書は、HTML の仕様をなるべく守りながらも、現実的にはどのようにマークアップをしていくかということに対して、一つの指針を示したものです。 前提知識として、PC 一般の使い方、ウェブの用語の知識を仮定します。技術には詳しくなくても構いませんが、用語を聞いて意味が分かるということを前提にしています。 目次 HTML の理念 HTML とはどのようなものであるか、そして HTML 文書とはどのようなものであるべきかについての簡単な説明をします。 XML ひとめぐり XML の基本を押さえることで、これからの HTML 文書制作のための基礎を作ります。 XHTML1.1 ひとめぐり ユニバーサルな情報発進のために、正しい
call/cc を使って簡単な Coroutine を作ります。call/cc 入門だと思ってもらえれば幸いです。 coroutine とは ここでは coroutine を「実行の途中でリターンでき、さらにそこ(実行の途中)から再開することが出来る何か」の意味で使用します。適当な疑似言語で書くと次の通り。関数の途中でのリターンを suspend(), 途中からの再開を resume() で表すことにします。 ここでは、これを scheme の call/cc を用いて表すことを目指します。 call/cc とは call/cc とは、call-with-current-continuation という scheme の関数で、「現在の継続(current continuation)を生成し、それを関数に渡してその関数を実行する」ものです。読者の殆どは「継続」についてよく知っているかもしれ
ユニバーサルな HTML へ向けて これから、XHTML1.1 による文書制作を学んでいくわけですが、HTML の理念でもお話したように、情報を発進する手段としての HTML は、なるべく環境に依存しないものでなければなりません。もし、HTML 文書の中に、レイアウトに関する情報を含めてしまったとしましょう。もし、これを「携帯電話のブラウザ」と、「パソコンのブラウザ」の両方で利用したいと考えた場合、あなたはどうするでしょうか。携帯電話のブラウザでは、出来ることは限られています。それに合わせて制作すると、パソコンのブラウザでは表示が寂しくなってしまうかも知れません。また、パソコンのブラウザに合わせて制作すると、こんどは携帯電話のブラウザでは見るに見られない表示になってしまうでしょう。結局、同じ内容でレイアウトを変えたものを二つも作ることになります。これでは、とても環境に依存しない情報とは言え
C/C++, Java は使える、大学で ML とか Scheme もやった、そろそろスクリプト言語を覚えたい、という人向けに、 一時間で Ruby がある程度 (日常的な処理が少しは出来る程度) 使える様になるまでをまとめます。他のスクリプト言語の知識は仮定しません。 このページでは、例示による学習を期待しています。 すなわち、例と結果を与えられることでその意味を理解するということです。 これが出来ないと一時間で使えるようになるのは厳しい。 オブジェクト指向、正規表現と聞いて一つでも意味が分からない人は別のところで勉強してください。 速習を目指しているので、細かいところは全部割愛しています。 とりあえず使えるようになった後にちゃんとした入門書を読んでください。 とりあえず動かす (10 分) Ruby はインストールされているものとします。とりあえず ruby と叩いて起動。 $ rub
次のページ
このページを最初にブックマークしてみませんか？
『MAYAH - MAYAH』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
