当社の規定により満60歳で定年退職をした。長いようで短かった会社員生活も一区切りだ。自分のプログラマとしての会社員生活を振り返ってみる。無駄に長いし結論はないのでお忙しい人は飛ばして欲しい。 9月末なのでブログ界隈では退職エントリーがそこかしこに書かれると思うが、その中で自分の退職エントリーを連ねることにどれほどの意味があろうか。もちろんないのだが、それでも多くの書き手の年齢を考えると満60歳定年退職というところに若干の希少価値を見出せなくもない。 1984年に大学院修了して以来、プログラマとしてのキャリアを重ねてきた。大学時代の同期でプログラマとして就職したものは皆無だ。当時、工学部の同期はメーカーに就職するのがほとんどで、大手家電メーカー、自動車メーカー、電力会社などなど、当時の誰でも名前を知っている人気企業に就職するものが大半だった。 その中で、日本ディジタルイクイップメント（DEC

夏休みなので、たまたま読んでいたCoders at Work プログラミングの技をめぐる探求という本の中にJamie Zawinskiのインタビューが載っていた。この本は著名なプロラグマを集めたインタビュー集で、Unixを創ったKen ThompsonやらDonald Knuthやらすごい人たちが登場している。 その中でJamie Zawinskiはそれほど著名でもなければ誰もが使っているすごいシステムを開発したというわけでもない。私が彼の名前を知ったのはNetscapeのソースコード公開時にMozilla.orgを仕切っていた頃なので、20年近く前である。 彼はxemacsの開発者としても著名で、当時GNU Emacsではなくてxemacsを日常的に使っていたので馴染みにある名前だった。xemacsとGNU Emacsはのちにマージされるのだけど前者が今で言う所のバザール型開発で、後者が

本日開催した、「声優ハッカソン」に審査員として参加した。 https://apps.rakuten.co.jp/special/rakkathon201602/ 声優ハッカソンというのは、プロの声優の声を使ったアプリを作るというイベントだ。何を言っているか、実のところわたしも参加するまでわからなかった。頭の中に？マークがぐるぐるしながら参加した。 アプリの題材はなんでもいい。ゲームでもいいし、VRやARでもなんでもいい。ゲームであれば、ナレーションをプロの声優にやってもらう。とかなんとか。 2日間でアプリを完成して、最後に2分間のプレゼンをする。 プレゼンの評価ポイントはデモである。どんなに高尚なアイデアであろうが実装されていないものに価値はない。ハッカソンは作ってなんぼという価値観が支配している。 それを勘違いしているグループがいくつもあった。 自分は審査員として、どんな作品もなるべくい

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

サイボーズ式の小崎さんのインタビューが面白い。*1 仕事が楽しくなくて、後ろ向きな動機からはじめた仕事が本職になっちゃうとか、人生のなかで二つの俺プロジェクトとか、仕事をサボって勝手にやってみたらうまくいったとか、なかなか面白い。 言われたことをちゃんとやるというのは重要だけど、言われたことしかやらないというのでは成長がない。勝手に何かをやって、学んでいくと言うのが成長には欠かせない。 自分にとってもオープンソースなんかは業務とは一切関係ないところからはじめていつのまにかにそれが仕事になっていて、あまつさえ会社を立ち上げてしまった。 Googleの20％ルールはそれを制度化したものとして有名だが、正式な業務以外を勝手にやるものをシャドーワークとか、スカンクワークとか言う。社内でそれを黙認したり、むしろ奨励したりする企業もある。DECはそのようなプロジェクトをミッドナイト・プロジェクトとよん

FacebookのHacker Wayという行動原理のなかに、Done is better than perfect（完璧よりもやることだ）というのがある。IPOのときの目論見書にそれが書いてある。 Registration Statement on Form S-1 The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. They just have to go fix it ― often in the face of people who say it’s impossible o

Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記という日記がとんでもなく読まれていてビビる。ブックマークもいっぱいついた。はてなブックマーク - Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記 Linusがgitを２週間で作ったという話はわりと知られていなかったようなので、その話である。 gitっていつから作られているのだろうか。ということで、本家のリポジトリから引っ張ってくる。 $ git clone https://github.com/git/git わたしのしょぼいネット環境でも2分はかからない。 最初の10個のコミットは次のようになる。 $ git log --oneline|tail 9426167 Add "-lz" to link line to get in zlib. 7660a18 Add new fsck

プレゼン資料で画像を使いたい場合がある。 インターネットで検索して適当にコピペするというのは、その画像の著作権を持っている人の権利を侵害する可能性が高いので、よろしくない。 そこで、再利用可能な画像の検索方法が必要になってくる。 1) Image検索で、Search Toolsをクリック 2) Usage rightsをクリック。そのなかで権利関係で選ぶ。ライセンスでフィルターしない。再利用、変更可能。再利用可能。非商用、再利用、変更可能。非商用、再利用可能。のなかから選ぶ。 再利用可能な画像はいっぱいあるので、そこから選んで利用しよう。くれぐれも、自分が著作権を持たない、画像をぺたぺたはるのはやめよう。よく、マンガのキャラクタなどを分別なしに使っている人がいるが、おすすめできない。多くの場合は引用の範囲を超えているので、やめたほうがいい。 下記のサーチエンジンのリストも便利だ。 http

あなたが現役のエンジニアならば英語から逃れることは出来ない。エンジニアというプロフェッショナルな職業を選択した以上、自分の職業に誠実になるならば、学び続けなくてはならないし、その場合、英語を避けて通ることはできない。 まあ、50代以上で、もう引退だとか言う人であれば、ぎりぎり逃げ切るということは不可能ではないかもしれないが、それは現役エンジニアというカテゴリではないので、除外する。もちろん、50代だろうが60代だろうが現役であるならば英語から逃れることはできない。 少なくともインターネットの業界とかIT業界とかそーゆーところで飯を食っている人であれば、ほとんどすべての情報は英語でやり取りされていて、一次情報の質と量については英語のそれは日本語それを圧倒している。もし、そのような認識を持っていないとしたら、それはそれで相当ヤバいと思う。 もちろん英語を学ぶとか学ばないとかは余計なお世話である

日本の風物詩、新卒入社。4月1日の入社式。 思い起こせば30年前の自分だ。希望と不安で臨んだ入社式。合宿の集合研修。 当時はIT産業という言葉は一般的ではなかった。コンピュータ産業だった。そしてコンピュータ産業はハードウェアベンダーが支配していた。ソフトウェア産業が生まれるかうまれないかの時代だ。 自分は大学でソフトウェアを学んだので、ソフトウェアを作ることを仕事にしたいと考えていた。そして、そのころはソフトウェア専業ベンダーというのがまた生まれて間もない頃なので、就職先としては自分の中には候補になっていなかった。ソフトウェアを作りたいのならハードウェアベンダーに行く。そのような時代だった。 IBMがコンピュータ産業を支配していた。メインフレームと呼ばれる、汎用大型コンピュータを作るのがハードウェアベンダのビジネスモデルだった。そして、そのようなベンダーはIBM以外残っていない。すべて時代

みんなでGitHubを勉強するにゃんっ！に参加するのでいろいろGitとかGitHubについて再勉強ちう。 そしたらGitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)を著者の大塚さんから送付いただいた。読了。ありがとうございます。 目次をみるとなかなかよさげだったので、期待しながら読んだ。素晴らしい。 http://gihyo.jp/magazine/wdpress/plus/978-4-7741-6366-6/0001 第1章GitHubの世界へようこそ 第2章Gitの導入 第3章GitHubを利用するための準備 第4章Gitを操作しながら学ぶ 第5章GitHubの機能を徹底解説 第6章はじめてのPull Request 第7章Pull Requestが送られてきたら 第8章GitHubと連携するツールとサービス 第9章GitHubを利

若い人は知らないのだけど、昔自作サーバーカンファレンスというのをやった。自作？サーバー？意味わからない。そもそもサーバーって何よ。というのが昨今の若い人の反応だと思う。 そのような時代背景のもと自作サーバーカンファレンスの同窓会に参加した。http://atnd.org/events/47968 クラウドの時代。自前でサーバーを準備するなんて意味わからない。そーゆーことだ。 RubyやPythonでコードを書く時代にアセンブリ言語でしこしこコードを書くという意味が分からない。時間の無駄。という感覚と似ている。 経済的な観点から言うとサーバーを自作するということに意義を見いだすのは難しい。というかない。 ベンダーのサーバーの価格が自作するよりも遥かに高いということであれば、それを自作する意義もあるが、昨今そのようなこともない。 そのようなコスト構造のときに自作サーバーを持つということにどのよ

不格好経営―チームDeNAの挑戦を読んだ。 1999年秋、当時のオフィスにて（17ページ） 彼女のキャリアはよく知られている。マッキンゼーでキャリアを積みパートナーになるが、インターネットベンチャーのDeNAを創業し社長になる。そして夫の看病のため社長を退任し現在にいたる。そして本書は、彼女のビジネスに対する考え、DeNAの原点を余すことなく記している。 コンサルタントとして順風満帆だった著書がなぜか起業し、それまでのキャリアが張り子の虎だったことを学ぶ。とんでもない失敗を繰り返し、その度に学んでいく。失敗を成長の糧にしていく過程がこれでもかこれでもかと記されている。 インターネットのオークションサイトを作るというのが創業時のビジネスモデルだ。そして、詳細な仕様書を作りサイト構築を外注する。さすがコンサルあがり、やることにそつがない。システム開発を発注する。そして、「開発が完了したはずのそ

自己紹介というのは、簡単なようでいて難しい。自分は何者かを5秒でいう。15秒でいう。3分でいう。それぞれに難しいものがある。 社会人として、自分を知ってもらうということは、仕事の一環として、最初の一歩だ。仕事じゃなくても、コミュニティでの自己紹介とか、親戚一同での自己紹介とか、簡単なようでいて難しい。 その場所にあなたはなぜいて、何者かを簡潔に表現する。それが難しい。 例えば、仕事上での初対面であれば、名刺交換をしつつ、XX株式会社、開発のよしおかでございます、でいいのであるが、勉強会で、全然自分の会社のことを知らないあるいは興味のない人に、第二営業部第三課の営業やるおです、なんて所属を説明しても、自己紹介にはならないし、そもそも第二営業部第三課が何をやっているかなんてことは参加者は知りもしないし、しったこっちゃない。なんできみがここにいるのかが意味がわからない。勉強会で営業やるお君が自己

知識。スキル。コンピテンシー。 知っているか知らないか。出来るか出来ないか。結果を出せるか出せないか。言葉にするとなんていうことはないけど雲泥の差がある。 インターネットの時代、記憶の価値は低い。ネットで調べれば大抵のことは分かる。ネットは外脳（外部記憶装置）だ。記憶容量は無限でコストはゼロ。 プログラミング言語の文法を知っていたとしても、プログラミングが出来るとは限らない。プログラミングが出来るか出来ないかは大きな差だ。何かを出来る能力のことをスキルという。 問題はそのスキルをどう獲得するか。プログラミングであればひたすらコードを読んだり、サンプルを写経したり、デバッガーで動作をおったりしながらスキルを獲得して行く。王道はない。かけた時間に比例したスキルが身につく。もちろん人によって、そのスキルの獲得スピードは違うだろうけど、読み書きした時間に比例したスキルの向上はある。ラーニングカーブ