2001年、17人のメンバーによって アジャイル宣言 が発表されました。私はその立案者そして著者の1人であることに誇りを感じます。この出来事は、何かをする上でより良い方法を導き出すことへの期待、そしてソフトウェアを開発することで世界をより良くするといった、私自身の活力の源となり、極めて重要なターニング・ポイントとなりました。 あれから14年が経ち、私たちは行き先を見失っています。”アジャイル”という言葉はスローガン化してしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまったとすら言えます。2～3のソフトウェア開発のプラクティスを、不十分に生半可に試みるといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重ねるといった、口先だけのアジャイルの 狂信者 がたくさんいるのです。 更にひどいのは、アジャイル開発手法その

Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上

連載：ハッカーの系譜①スティーブ・ウォズニアック (1/6) 世界で最も愛されるハッカー 「ハッカー」という言葉の定義は曖昧だ。高度なプログラミング技術やネットワーク技術を持つ技術者をハッカーと呼ぶこともあれば、セキュリティを破ってデータを盗む犯罪者をハッカーという場合もある。辞書には「コンピューターに熱中している人」（大辞林）と漠然と記されているだけだ。定義が定まっていないのは、彼らが表立って自らを語ることが少なく、その実態が掴みにくいからだろう。そんな彼らについて正しく理解するには、本物のハッカーの生き方、考え方、技術力を知るのが近道だ。 本連載では、テクノロジー業界の人々が敬意を込めてハッカーと呼ぶ人物に焦点を当てることで、世界を動かす原動力になっているハッカーたちの実像に迫りたい。第1回では、スティーブ・ジョブズと共にアップルを設立したスティーブ・ウォズニアックを取り上げる。ビジネ

医療、スポーツ、飲食――プログラミングで自身の専門分野をより良くしていこうとチャレンジしている人たちに、ハッカソン芸人「ハブチン」こと、羽渕彰博がお話を伺うシリーズ。第一弾は、現役の整形外科医であり、医療×ITで起業も果たした医師の黒坂望さんだ。 総合病院の整形外科医である黒坂望氏は、医療に従事しながら、ITで医療の発展を目指すために、プログラミングを学びながらWebサービスを開発している。黒坂さんはなぜWebサービスを開発するのか、なぜプログラミングを学んでいるのだろうか。 守りの医療から攻めの医療へ 黒坂望氏 1969年、神奈川県生まれ。横浜市立大学医学部博士課程卒業。 大学病院で整形外科医として働き始め、その後オーストラリアにリウマチの勉強のために留学。帰国後、一般病院で整形外科部長、副院長を務め、病院の経営改善に携わる。 現在、新百合ケ丘総合病院整形外科やクリニックなどで外来診療な

2015年05月27日: 表が見にくいというご意見を頂いたため、原文著者に連絡のうえ体裁を修正しました。 上位のレベルには下位のレベルの知識も蓄積されているということに注意してください。つまり、レベル n であれば n より低いレベルの知識も全てあります。 コンピュータサイエンス データ構造

17 Sep 2014 on developers hiring 5 alternatives to the Fizzbuzz test for hiring programmers I compiled a list over the last 100 so-called programmers who came to me looking for a job. 75 of them failed one or more of our three simple programming tests. Let me emphase that; 75 out of 100 applicants to a programming job can not program. At all. You might have heard of the Fizz Buzz test. I first rea

本連載も5年目になるが、今年は私がこの業界に長年関わる中で得た教訓というテーマで書いてみたいと考えている。 この業界で仕事をしていると、いろいろな場面で「どんな人がソフトウェアエンジニアに向いているのか」という話題になる。一番多いのが人を採用する場面でだが、キャリアパスに悩んでいるエンジニアに相談されるケースもあれば、子どもたちの教育に関する話題でこの話になることもある。 問題解決能力の高さ どんな人がソフトウェアエンジニアに向いているかを一言で言えば、それは「問題解決能力の高さ」である。それも、知識や経験を使った問題解決でははなく、複雑な問題をよりシンプルな問題の集まりに分解して解決していくという、地頭を使った純粋な問題解決能力の高さである。 算数、数学への興味 私は典型的な「理科系少年」として少年時代を過ごした。小学生のときは、算数の応用問題を解くのが大好きだった。武蔵や開成などの名門

Sallyann Freudenberg博士はQCon Londonで，作業環境における神経多様性について講演した。プログラミングは複雑で創造的な作業だ。Freudenberg博士は，プログラミングを行うプログラマが一般的に使用している，数多くの技術について検討した。例えば， 1. チャンキング: 我々が短期記憶に保持できるのは5～9個であるという，7 (+/-2)ルールを克服する。“ひとつひとつの事をそれぞれスロットに入れる代わりに，ポインタを入れるようなもの”だと，Freudenberg博士は説明する。例えば，チェスに関する研究は多数存在するが，その中のひとつ，Chase，Simon両氏による研究によれば，熟練したチェス競技者は，短期記憶の各スロットには“シベリアントラップ”(訳注：チェスの手筋のひとつ)などへの参照を格納しておいて，その内容は別の場所に記憶することができる。 “このよ

はじめまして、今年の2月にクリアコードに入社した横山です。この記事では、私がクリアコードに入社した理由のひとつである「フリーソフトウェアを仕事にしたい」ということについて、フリーソフトウェアやクリアコードに興味を持ったきっかけと、入社までの経緯をお伝えします。 フリーソフトウェアに興味を持ったきっかけ 私は社会人になってから本格的にプログラミングを始めました。研修や仕事でプログラミングに触れるにつれて楽しさを感じ、研修で触れたRubyがよさそうだったので、趣味でもプログラムを書いたりしていました。 その頃、何度か社内外の勉強会で発表する機会があり、既存のプレゼンテーションツールに不満を感じていました。そこで、新しいツールを探していたところ、Rubyで作られているRabbitというソフトウェアがあることを知り、次のような点が気に入って使い始めました。 テキストエディタで書けるのでバージョン管

私はこの7年半、 Ronimo でプログラミングを学ぶ多くのインターン生を指導し、様々なタイプの大学生や大学院生を見てきました。彼らのほとんどには、共通して言える学ぶべきことがあります。特別なテクニック、アルゴリズム、数学、あるいは特定の形式についての話だと思う人もいるかもしれません。もちろんそれも必要ですが、中心的なものではないと私は考えます。彼らが主軸として学ぶ必要があるのは、自己統制力です。常に可能な限り読みやすいコードを書き、開発中の変更により秩序がなくなってきた時にはきちんとリファクタリングを行い、使用されていないコードを除去し、コメントを追加することができるという力です。 プログラミングのインターン生を指導する際、この話にほとんどの時間をかけます。上級のテクニックでもなければエンジンの詳細についてでもなく、概ね彼らにより良いコードを書かせることに主眼を置きます。いつもインターン

10. 「何か」は分かるが「なぜ」が分からないコメント プログラミング入門コースでは、早い段階かつ頻繁にコメントを記述することを生徒に教えます。プログラムを書き始めた初期段階（ごく単純なコードであっても、時に理解し難いことがあります）では、これは実際に役立つことなのですが、習慣にとらわれてしまうプログラマが多くいます。 上記のコードが何をするのか分かりますか？ 私は分かりません。 問題は、多くのコメントがそのコードが 何をする のかを説明していますが、 なぜ そのコードが書かれているかが説明されていません。では、異なるコメントが書かれた同じコードを見てみましょう。 こちらの方が分かりやすいですね。何が起きているのかを完全に理解できるとは言えませんが、最低でもなぜこのコードが必要なのかが文脈から判断することができます。 コメントは、構文を理解してもらうためにではなく、読み手がコードを理解しや

あなたは、これからキャリアを切り拓こうとしている素晴らしいエンジニアたちを抱えています。チームは優れた成果を出して成長し続けているので、何らかの具体的な方法で賞賛したいと考えています。すぐに思いつくことは、特にエンジニアたちがそのチーム内ですでに事実上リーダーの役割を果たしている場合には、彼らにチーム内での役職を与えて昇進させることでしょう。でもその報酬は、本当にエンジニアたちが望んでいるものでしょうか？　もしかしたら彼ら自身も、昇進は望むべきもの、と思い込んでいるだけではないでしょうか？ 人材マネジメント力は別のスキル エンジニアの世界では、エンジニアたちが技術面ではピークに達した後に、これまで習得したものとは全く別の、社交面だとかソフト面におけるスキルを学ぶよう求められることがよくあります。これらは、エンジニアたちが過去のキャリアではほとんど気にしていなかったものです。このようなスキル

先週、 Hacker News上で興味深い議論が行われました 。テーマは Linux Kernelのコーディングスタイル についてです。 議論の中で私は、 コーディングで垂直方向にそろえるインデントをとるべきか というささやかな聖戦を仕掛けました。私は全面的に賛成です。理由を説明しましょう。 垂直方向にそろえるインデントをとるとは？ 簡単な例を挙げてみます。 int robert_age = 32; int annalouise_age = 25; int bob_age = 250; int dorothy_age = 56; ちょっと見ただけで、「bob_age」がおかしいと分かるでしょう。また、目視であちこち探さなくても、全ての値が整数であることが簡単に確認できます。 この考え方は 一般的に 共有 されているわけではありません。ですので、なぜ 多くの 人たち がこれを有効なスタイルガ

私は毎日、 Teamed.io で働くことに興味のあるプログラマから何通かメールをもらいます。彼らへの最初の質問は「あなたのレートは？」（ 当社は時給ベースで給与を計算します ）ということです。何より驚かされるのは、2つの方向性で、誤った試算をしているプログラマが多く見られるということです。 時給5ドルから500ドル（600円から60,000円）まで答えはさまざまです。決して否定はしませんが、私自身で代案を出してみます。このブログ記事では、どういった要素を計算に入れるか、または入れないかを述べたいと思います。私の個人的なキャリアもありますが、これが業界のスタンダードとは思わないでください。あくまで客観的で論理的だと思っていますが。それでは説明しましょう。 オープンソースへのコントリビューション ソフトウェア開発者にとってまずポイントとなり、かつ重要となる特性です。あなたはオープンソースプロ

まつもと ゆきひろ1965年大阪府生まれで、4歳の頃から鳥取県米子市で育つ。筑波大学卒業後、数社を経て(株)ネットワーク応用通信研究所に入社。プログラミング言語「Ruby」の生みの親として知られる。島根県松江市在住で、Ruby開発の功績から同市の名誉市民にも選ばれた。 まつもとさんのブログ『Matzにっき』twitter 世界中に大勢のユーザーを抱える、日本産プログラミング言語 Ruby。その開発者である まつもとゆきひろ さんに、Ruby 開発の裏側と成功までの道のり、そして未来を生き抜くエンジニアさんへのアドバイスを伺いました。 プログラミングとの出会いは、父が買ってきたポケコンのBASICー プログラミング言語に興味を持ったキッカケはなんですか？ 私が子供の頃は、コンピュータって全然一般的ではなかったんですよ。ものすごく尖った人だけが、NECのPC-8001 や SHARP の MZ

今日は、開発者が見積もりを作成している時に脳内でどんなことが起きているのか話してみたいと思います。なぜこんなにも見積もり作業が難しいのか、そして、私の見積もり精度は相変わらずひどいものですが、私がどうやって（非常に幸せな事業主の方々に向けて）ソフトウェアを書いて生計を立てる術を編み出してきたのかについてお話ししたいと思います。 まずは昔話をひとつ。 あれは\<私がものすごく年寄りには見えない程度の年代をここに挿入>頃でした、私は年若き開発者でした ^(1) 。大学のコーディング演習では優秀な成績を修め、若手開発者として誰がどんな問題を提示してきても解決し、想像を絶する速さでどしどしコードを量産していました。新しい言語は週末の間に習得し、書けるようになっていました（少なくともそう信じていました）。 それで自然な流れとして自分でプロジェクトを取り仕切ることになりました。アカウント・マネージャが

挑発的なタイトルによって誰かが気分を害してしまう前に、私はこの問いに対する答えも書いてしまうことにしました。答えは“ノー”です。しかしこのテーマには、なかなか興味深い議論があるのです。HaskellやErlangや、特にClojureなどのあら探しをするつもりはないのでしょうが、Piaw NaはQ&AサイトQuoraの あるアンサー で以下のようにコメントしています。 プログラミング言語を固定するのは二流のエンジニア／コンピュータサイエンティストである証です。 [中略] 私がErlangのサーバに携わるポジションの採用をした時も、Erlangのスペシャリストだと言うエンジニアより、優秀なオールラウンダーのエンジニアを雇ってErlang（これに限らず何でも）を学ばせてそのポジションを埋める方が断然いいと感じました。 Na氏の意見は1990年代に設立されたGoogleやAmazonなどの技術系