釣りの仕方を教えてもらうという機会は人生においてそうそうあるものではない。老子曰く「授人以魚 不如授人以漁」。魚を与えるのではなく、釣りの仕方を教える。ということらしい。*1 新卒は、研修でいろいろな釣りの仕方を教わっている最中かと思う。新人ゆえの特権だ。中途入社の人間は基本的には放置というのが世の常だろう。釣り方は既に身につけているという前提で雇用されているのだからしょうがない。 よく考えてみると例えばDebugの方法とか誰かに教わったかというと多くの人は見よう見まねでどうにか自分のスタイルを確立していったのではないだろうか。いまでこそ、テストの方法とか、ソースコードの読み方のような書籍があるけど、そのようなものは例外的な存在のような気がする。 IT業界のような変化の激しい業界では、2年前には影も形もなかった技術がぽっとでてきて業界を席巻しているようにみえる。そして、そのようなものは当然

昨日に引き続いてLinux Kernelがらみのお話を。カーネルを読むための基礎知識としてプロセッサーアーキテクチャの詳細な理解が必要である。ページングがどーだとか、例外処理がどうだとか、もうちょっと細かいところになるとキャッシュがどうだとか、スーパーパイプラインだ、スーパースカラーだ、ハイパースレッディングがどうだとか。アーキテクチャが変わってもデータ型の概念とかメモリ階層とか例外処理、割り込みなどの概念はある意味共通である。そーゆー概念の正しい理解が必須である。その理解を得るために、マニュアルを読まなければいけない。（当たり前だけど） そこでインテルのマニュアルである。カーネルを読むための基礎知識として下記を読む。 The IA-32 Intel(R) Architecture Software Developer's Manual, Volume 3: System Programm

継続的インテグレーション(CI - Continuous Integration)と継続的デリバリー(CD - Continuous Delivery)について知りたかったら、闘うプログラマー［新装版］を読もう。 これはWindows NTの開発物語だ。大規模基盤ソフトウェアの現場の葛藤を生々しく描いていて、ソフトウェア開発に従事しているものには必読書といっても過言ではない。 デスマーチ、ドッグフードを食う、ビルド、業界人なら誰でも聞いたことがあるジャーゴン（業界用語）がちりばめられている。本書によって、それらの用語を覚えた人も少なくないと思う。 「カトラー（開発の総責任者、伝説のプログラマー）は、オペレーティング・システムを開発するときは、機能を増やすより、スケジュールを短縮するべきだと考えている。最初のバージョンは、機能を減らしても、早くリリースしたほうがいい。最初は機能を最小限にして

PBL(Project Based Learning)の授業を持っていて、その教員が集まってあーだこーだという会に参加している。PBLという手法は必ずしも教員にとっても経験豊富なものではないので学生の指導方法とかに悩みが多いので、いろいろな立場の人が集まって、あーだこーだ試行錯誤や悩みについて披露し合う。 産業技術大学院大学でのPBLはウェブアプリケーションの作り方を学ぶというもので、モダンなソフトウェア開発手法やクラウドを前提としたツールなどを利用してチームで実際にものを作る。 *1 キーワードとして、Continuous Delivery (CD), Test Automation, Continuous Integration (CI), Version Control System, Test Driven Development (TDD), Platform as a serv

勉強会コミュニティCROSS2016に行って来た。チラシ200枚と楽天のステッカー500枚を配布した。 http://2016.cross-party.com/ 会場は今年も横浜港大さん橋ホール。天気にもめぐまれ気持ちいい。 及川さん、伊勢さん、森藤さんとのパネルディスカッションに出た。 http://2016.cross-party.com/program/x4 会場の様子 伊勢さんと森藤さん 及川さん 会場から、会社から勉強会の参加が禁止されているという話を聞くのですが、そのような場合はどうしたらいいですか、という趣旨の説明を受けた。 世界はソフトウェアで出来ているという時代にわれわれは生きている。ソフトウェアは人が創る。そのためによい人材を雇用するのが経営のトッププライオリティになる。勉強会への参加や発表を奨励することはあっても禁止することはナンセンスだ。そんなこともわからない経営者

傳智之さんから送っていただいた倉貫さんの近著リモートチームでうまくいく マネジメントの?常識?を変える新しいワークスタイルを読んだ。ありがとうございました。 わたしじしんは現在在宅勤務をしているわけではないが、いろいろと倉貫さんらの試みについて聞いたり、本を読んでみたりして、想像するに、新しい働き方のひとつであることは間違いないのだけど、マネジメントおよびチームメンバーには高度な専門性や自立性が要求される仕組みだと思った。 会社に行って仕事をするという「従来型」の仕事になれたものにとってリモートでの仕事の進め方には、それなりに必要なスキルがあって、チーム運営でのコツが必要かと思う。そのコツについて、本書はこれでもかこれでもかと記している。 在宅勤務の人たちがチームになって働くことをリモートワークと言う。フリーランスの人がひとりで在宅勤務をするという形ではなくて、チームで働くことが特徴になる

昨日「知っていること。出来ること。結果を出すこと」で書いたことの続き。*1 学校の授業とか講義は主に知っていることを増やすことに繋がる。知っていることの確認はテストなんかで行う。暗記ものとかは記憶力勝負で、勉強そのものはそんなに楽しくない。すくなくともわたしはそうであった。モチベーションを維持するのが難しい。 知識偏重型の覚えればいいというタイプのものはインターネット時代には価値は低い。調べればわかることを無理して覚える必要は低い。 絵を描くとか楽器を演奏するとかは暗記ものと違って、練習をしたり、実際にやってみる必要があるタイプのものである。うまいヘタはあっても練習を重ねればある程度は出来るようになる。その対象に興味がなければ練習を続けることが苦痛で練習も熱心にやらないのであまり上達もしない。絵を描くことが好きな人は別に誰に言われるわけでもなく、ノートに落書きをしたりして、絵をひたすら描い

先日、オープンソース関連のセミナーを聞く機会があって、弁護士の先生がオープンソースをコンプライアンスの観点から解説をされていた。 弁護士の仕事はクライアントからの相談事を主に法律等の観点からアドバイスすることなので、クライアントがオープンソースにはどのようなリスクがあるかという質問をすれば、当然ながら「XXXというリスクがある」とか「XXXのリスクを避けるためにYYYという対策をとる必要がある」とか言う回答になる。 コンプライアンスという観点から、オープンソースのライセンスを検討すれば、GNU GPLのオープンソースを利用して、著作権者から訴えられない利用方法とか、MITの場合はどうだという方向になる。 クライアントも別にオープンソースに詳しいということもないから法律的な相談をするわけで、いかにリスクを最小化するかという文脈では上記のようなやりとりになる。 つまりこの文脈の中では、オープン

Regional Scrum Gathering Tokyo 2015に参加した。 http://2015.scrumgatheringtokyo.org/ Day 1 program Regional Scrum Gathering Tokyo 2015: Schedule 朝からJames Coplienの話を生で聞けるなど豪華なセッションがあって、お得感満載なイベント。産業技術大学院大学もスポンサーになっていてenPiTのちらしなどを配布していた。弁当もがっつりでていた。美味しかった。 (James O. Coplien) スクラムについての誤解などを解説、議論していた。わたしはスクラムの基本を彼から習ったので、そーゆーもんだと思っているが、ちまたに流布されているスクラム的なあれやこれやについて、それは違うというスタンスで解説した。ある意味、そもそもなんでスクラムが必要なのかというと

キーノートはドワンゴの川上さん。はじめて講演を聞いたのだが、キレキレで面白かった。言いたい放題。 クラウドの登場でウェブエンジニアが簡単にサービスを作れるようになった。それがエンジニアの質の低下を招いているのではないかという指摘をしていた。 スクリプトエンジニア、コンピュータの動作原理を知らないエンジニア、性能の理論的限界を計算できない、開発手法の宗教的依存度が高い、自分の頭で考えるより結果をググって覚えるだけ。二流のエンジニアの大量生産という現象を指摘していた。 自分の会社の会長が、エンジニアをdisるというのは自分がその会社にいたらちょっときついなあという印象を持つのだけど、ベースには技術者に対する愛があるので、ちゃんとコンテキストを理解すれば、そんなこともないのかなと思った。 一つ一つを文脈を無視して切り取ると誤解を招きかねないフレーズである。技術者に取ってのレッドオーシャンを避ける

セミナーとか勉強会で話をしていて、あるいはそのような勉強会を主催していてよくある悩みの一つが質問が出ないというのがある。 質問がでないのは、日本人が奥ゆかしいのだとか、質問するのが恥ずかしいとか、文化的な何かにその原因を求める人もいれば、講師の発表がそもそも質問を前提としていないとか、セミナーの形式にその原因を求める人もいる。 原因はなんであれ、一方通行のセミナーより、インタラクティブな質疑応答が活発にあるものの方が、参加者にとっても講演者にとってもメリットが多いと思うのだが、なかなかその価値観が共有されていない。 その問題についてFacebookで話題になっていたので、ちょっと考えをまとめてみた。 なぜ質問が必要なのか。なぜ質問が重要なのか。 勉強会などで質問が求められるのはなぜなのだろうか。もちろん質問を受けることを前提としないセミナーや講習というものはある。そうではなくて自主的な勉強

ツイッター創業物語 金と権力、友情、そして裏切りを読んだ。 すごい話だ。ツイッターの創業時の人々の物語になっている。共同創業者、CEO、取締役会、さまざまなステークホルダーがエゴをむき出しにやりあう。 日本ではツイッターの創業者としてジャック・ドーシーが有名だが、共同創業者のエブ・ウィリアムズや取締役会との確執がこれでもかと描かれている。初代CEOのジャックは取締役会からクビを言い渡され、その後釜にエブが就任する。そしてそのエブも最後には取締役会で解任される。 ツイッターとは何なのか。自分のエゴを表現する手段なのか、それとも周囲で起きていることを伝えるものなのか。ジャックとエブはその根本のところで対立する。 ツイッターを題材にしたIT業界のすぐれた民族誌だ。緻密な取材で人々の栄光と挫折が描かれている。お勧めの一冊になっている。

Tech-Party CROSS ビールが始まる前のパネルディスカッションという名の雑談セッションに参加した。 先達に聞くこれからのエンジニア像 会場はこんな感じ。 （山口さん撮影） パネルが始まるまでの一コマ。 （黒崎さん撮影） こんな感じのパネルディスカッション。 パネルというのは話が予想もしないところに行くのが面白いのだけど、通常は予定調和的なところに行ってしまいがちだ。結局、打ち合わせと言う名の飲み会での話が一番面白かったりする。この飲み会をそのまま配信しちゃえばいいんじゃね的な打ち合わせを司会（予定）の森藤さんがメモを取って、そのメモをベースにパネルの構成を考えてくれた。 ところがその森藤さんがインフルエンザでダウンして急遽実行委員長の山口さんが代打で司会を担当することになった。山口さんが森藤さんの残したメモをもとに司会進行すると言うアクロバティックなものになった。森藤さんの言語

昨年も出たのだけど、今年もHeroku meetup の新年会に参加した。 Heroku Meetup #13 新年会 - Japan Heroku User Group | Doorkeeper ついでにLTもやった。 あいまいランチの竹葉さんも発表していた。よかったです。 （この日記は、1/27に書いた。２週間ためため日記）

前回山手線徒歩一周、約13時間。 - 未来のいつか/hyoshiokの日記で山手線一周を徒歩で歩いたのだが、その話をいろいろな人にすると結構興味がある人が多い。そこでまた徒歩一周をすることにした。友人に声をかけたところなんと二十人を越える人たちが参加表明をした。意外と山手線一周をやりたい人がいることを知って驚愕した。世の中物好きが多いということかw 年末に企画していたのだけど、幹事が風邪を引いちゃって年明けまで延期。そしたら今度はわたしが転んで怪我をしてしまった。とほほ。痛みが引いたとは言いがたいけど歩けないこともないので行けるところまで行ってみようと思い参加した。途中離脱もありという幹事である。感じである。 段取りとしては6時半ころに御徒町に集合して時計回り（山手線外回り）で一周。最後に銭湯で汗を流し、打ち上げをする。前回が約13時間だったので、今回も同様の時間がかかると予想される。 （

まつもとゆきひろさん監修の角川インターネット講座２　ネットを支えるオープンソース　ソフトウェアの進化 角川学芸出版全集に「ハッカー精神とは何か」を寄稿した。 第一部、プログラミングがすべてを作った 序章、インターネットはソフトウエアでできている。まつもとゆきひろ インターネットを支えるソフトウェアを知る。法林浩之 プログラミングとは何か。久野靖 プログラミングと教育。阿部和広 ハッカー精神とは何か。吉岡弘隆 第二部、オープンソースが高めたネットの価値 ライセンスというプロトコル。やまねひでき オープンソース化が生んだ変化。瀧田佐登子 企業とオープンソース。鵜飼文敏 久しぶりの執筆だったので、七転八倒しながら書くことになった。 わたしのところは、60年代のハッカー達から70年代を経て、Richard StallmanのGNU Projectなどを紹介しつつ、OSSへの流れを歴史とともに解説し

いろいろと驚く。昔、オープンソースに敵対していたMicrosoftも自ら基幹ソフトウェアをOSS化する時代である。どんな大企業もオープンイノベーションを無視していけない時代になった。 .NET Core is Open Source | .NET Blog 30年くらい前のいわゆる垂直統合の時代は、ハードウェアからOSからコンパイラやRDBMSや、アプリまですべて自前で提供するというのが優れたビジネスモデルだと考えられていて、その完成系がIBMだった。ハードウェアベンダーは多かれ少なかれIBM的なビジネスモデルを目指していた。それは国産各社も例外ではない。80年代になって、潮目がごろっとかわり、専業ベンダーが台頭してくる。OSならMicrosoft、UnixならSun Micro、RDBMSならOracle、CPUならIntel。それぞれの専業ベンダーはそれに資源を集中するので、イノベーシ

Twitterなどで返事（リプライ）がひどいものをクソリプ（クソみたいなリプライと言う意味か）と言うらしい。 例えば、下記のような例がある。 特にどうというものでもない言明に対して、いろいろな角度からツッコミがはいる。どーでもいいだろうと思うようなツッコミだらけになって何を話題にしているかすら定かではなくなる。 「XはAである」という記述に対して「AでないXもあります」「AなXが嫌いな人もいる」（あといろいろどーでもいい言明が続く）などなどリプライがついてくる。それをクソリプというらしい。 クソみたいなリプライなので、事の本質からどんどん離れて行く。何か生産的な議論がされるわけでもない。時にはけんか腰の言い合いというか罵り合い発展したりする。 最初の書き込みが、単なる記述で、そこに価値判断（良い悪い）などが含まれていようがいまいが、クソリプが返ってくる。 豆腐の色なんて、どーでもいいわけで

プログラマという職業について、もう25年くらいになるのであるが、その間にコンピュータのコストパフォーマンスは、それこそムーアの法則に従って、10万倍〜100万倍くらい向上した。にもかかわらづ、デバッグの方法というものの劇的な変化はほとんどみられない。 プログラミング入門書では、デバッグについて、ほとんど議論されていないし、仮にふれられていても、おざなりな方法というか、かなり邪険にあつかわれていたりする。プログラマの多くの時間がデバッグについやされていたとしてもだ。 たまたま手元にあった、C実践プログラミング(ISBN4-900900-64-8)という10年くらい前に買った参考書では、450ページのうちデバッガの利用については、4行ほど記述がある。たった4行である。診断用のprintf()を挿入するということは3ページにわたって記述されているのにだ。 流石に21世紀になってprintf()デ

楽天テクノロジーカンファレンスを開催した。今年も事務局としてあれやこれやかかわった。個人的な振返りを記す。 三木谷社長のキーノート。 2007年から開催しているので、今年で8回目だ。最初の二回は社外の人として参加して、2009年からは中の人になったので、内側からいろいろみることになる。 第一回のカンファレンスの時は、撮影、録画、録音その他禁止ということで、ブログにアップすることもはばかられるような閉じたカンファレンスだったなんてことはきっと誰も覚えていないだろう。*1 2008年の時はLinuxのディストリビューション大集合という企画をやらさせていただいた。コミュニティ企画で、いろいろなコミュニティ系（非商用）のLinuxディストリビューションを集めてパネルディスカッションをした。*2 そして、2009年。その直前に第100回カーネル読書会にLinusが来て、自分のなかでは、大騒ぎだったの