コンパイラ勉強会というちょっと心をそそる勉強会があったので参加した。勉強会っぽい勉強会（ってどんなだよ）に参加するのは久々だったので、つい出来心でLTでもしようかと思った。LTすれば定員オーバーでも参加できるだろうという下心があった。 https://connpass.com/event/103976/ LTのつもりでいたら、お時間30分も頂いてしまった。困った。モダンなコンパイラのことで話すネタを持っていない。こーゆー時はLLVMのことなどをさらっと話せるようになりたい。 そこで温故知新、昔話でお茶を濁すことにした。ごめんなさい。「愚者は経験に学び、賢者は歴史に学ぶ」とかなんとか。*1 新卒で入社したDECでの最初のプロジェクトは日本語COBOLの開発だった。その話をネタにした。 若い人はCOBOLという言語の出で立ちなどは知らないだろうから、昔話としてはちょうどいいと思った。COBOL

タイトルは釣りです、すみません。無駄に長いのでお忙しい人は、どーぞ、飛ばしちゃってください。 自分は今年の9月で満60歳になる。60歳というと多くの日本企業の御多分にもれず定年である。定年後に何をするのかしないのか、ここで簡単に記してみる。 日本の伝統的な大手企業（経団連に属するような企業）では、定年などの制度がしっかり整備されているので、先輩たちがどんな暮らしをしているかおおよそのロールモデルがある。一方で自分が今所属している企業は20年ちょっと前に創業したネット系である。規模は大企業だが相対的に若い企業なのでそもそも50代の従業員がそんなにいなくて定年退職した人も数えるくらいである。 日本において職業プログラマの世界では、特にフリーランスではなくて会社に所属している場合、35歳定年説というのが炎上系のネタとしてよく議論される。特にSI系の場合、多重下請け構造の中で歳を食ってプログラミン

自分は図書館が大好きなので、しょっちゅう図書館に行っている。中学時代に可愛いこが図書委員をやっていたので、その頃から図書館が好きだ。図書館短大の女子と合コンをしたこともある（関係ないけど） 通勤の行き帰りに図書館に寄るのがもはや日常と言っても過言ではない。 ネットのおかげで図書館に直接行かなくても本を予約できる。 図書館好きならば誰でも使っている、日本最大の図書館検索サイト・カーリルを使いこなそう。 https://calil.jp/ 面白そうな本を見つける ネットで図書館検索をする ネットで予約する 忘れた頃に予約した本が借りられる 図書館に行って借りる 図書館でぶらぶらして関係ない本も借りる 感想をネットに書く 読んでも読まなくても期限がきたら返却するので積ん読にはならなくてネットの感想だけが残る。 予約してすぐ借りられる本もあれば、予約が殺到していて何ヶ月も待つ本がある。すぐに読みた

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

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

工学部を卒業したので、大学時代は数学を勉強したはずなのだがすっかり忘れている。小中学校の頃は算数とか数学の最初の方は結構好きだったのであるが、高校の中盤から後半にかけてすっかりちんぷんかんぷんで理解が遅れてしまい、大学の数学はさっぱりだった。 大学の物理や数学は何のために学ぶのかというモチベーションを見つけられないまま単位を取るために仕方なくこなしていた。 正直言って電子回路の設計とか構造体の設計の仕事にでも従事しない限り大学時代の物理や数学を日常的に使うということはない。 コンピューターサイエンスの勉強もちょっとはしたが、物理や数学のような学問に比べると、理論的な積み重ねは薄いし、コンピューターサイエンスをサイエンスと呼ぶのはおこがましいような気もしないでもない。 なんてことをつらつら思っていたのだが、最近数学をガッツリ学び直したいと思っている。 数学を学んだところで仕事にすぐに役立つわ

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

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

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

倉貫さんが、ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)を紹介していた。 ずいぶん前に読んだのだけど、本棚から引っ張りだして、パラパラと再読した。180ページほどなので、お気楽に読めるのであるが、中身は濃い。 最後の章（19章）は「永続的な学習」を取り上げている。１）学習環境を作り上げる。２）ソフトウェア開発における技芸の熟達。３）訓練コースは細心の注意を払って選択すること。４）ソフトウェア開発コミュニティ内で目立つことを奨励する。５）内省的な実践者になる。 学習環境を作り上げる。 １）学習環境を作り上げるために、組織内に講座を設ける。２）興味深いテーマのセミナーには部外者も招待する。３）学習時間はプロセス改善の投資である。 具体的なコツがいろいろ詰まっている。 ソフトウェア開発における技芸の

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というOSというかカーネルはLinus Torvaldsが学生のときに趣味で作ったのがはじまりだ。それは1991年ころの話で彼が21歳の頃だ。個人の趣味で作ったものが、いつの間にかに世界中のコンピュータだけでなく、携帯や家電や様々な機械の制御に使われている。 Linus Torvalds - Wikipedia 1994年ころには、PCで動く個人向けOSとしては十分な機能を持っていた。Xもあるし、gccなどのコンパイラもあるし、GNU Emacsやbashもあるので、ちょっとしたプログラムを作るには十分な機能を持っていた。 当時、勤め先のマシンはSunのワークステーションで仕事でLinuxを使う機会は全然なかったのだけど、自宅のPCにSlackwareのCDを入れてみたりした。日常的に使うことはなかったけど、1998年にOracleがLinux版を出し

産業技術大学院大学のenPiTという講座で、永瀬さんと共同でやっているアジャイル開発手法特論の授業が今日から開始した。 この授業は事前学習科目という位置づけで、秋に開講予定のPBL (Project Based Learning) を実施するのにあたっての、前提となる知識やスキルをみにつける。ここでは座学でアジャイル開発手法を学ぶ。40人を超える受講者が集まって、昨年より遥かに多いのでちょっと大変かもしれない。昨年は10数人。琉球大学の学生さんもTV会議システムで遠隔地から参加する。TV会議システムの設定に手間取ってしまって、ご迷惑をおかけした。来週はもう少しうまくやりたい。 参加者のみなさんの自己紹介などを聞いた。各自、強い思いを持って参加されていて、その期待に答えるために全力投球をしないといけない。これからの半年間、楽しみである。 enPiT BizSysD – 産業技術大学院大学 e

先日文明塾の修了生のみなさまとお話したときのこと(コミュニティとしての大学 - 未来のいつか/hyoshiokの日記参照)。ハッカー文化とかオープンソースのことをあれやこれやお話したのだけど、その中で現役の学生さんから「ゼミでIT係を担ってからよくソースコードを何気なく閲覧してしいました。しかし、自由にソースコードが見れる環境が衝撃的で素晴らしいことであることに吉岡さんのお話を聞いて学ばせていただきました。」という感想をいただいた。 そうだ。すっかり忘れていた。オープンソースが当たり前じゃない時代があった。とてつもない衝撃を受けた自分がいたことをすっかり忘れていた。 1998年1月。Netscapeが自社のブラウザのソースコードを公開するということを発表した。当時のシリコンバレー日記にそのことを書いている。http://web.archive.org/web/19990423102903/

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

ウェブ系のサービスを提供しているところは常識なんだけど、世間ではあまり知られていないことは、サービスは基本的には自社で作るということだ。 日本において、ITシステムはユーザー企業が作るのではなく、それを専業にしているベンダーが作る事が多い。SI (System Integrater)と呼ばれる企業だ。ハードウェアベンダーのSI部隊であったり、独立系と呼ばれるベンダーだったりする。統計では受注ソフトウェアの売上になる。 *1 わたしはSI企業にいた経験がないので、本当の実態を知る立場にはないけど、想像するに、大手ベンダーが受注したシステム開発の案件を、誰かが要求定義して、それを文書にして、その文書をもとに誰かが設計して、その設計書をもとに、誰かが実装をする。テスト仕様書を誰かが作って、誰かがテストをする。発注側とシステムを受注する企業が別の場合は、何をいくらでいつまでに作るかというのを契約で

いろいろな人がgitは難しいという。そうなのかなー。ふーん。自分はあんまりそうは思わないけどつらつらと考えてみた。（無駄に長いし、有意義なことを書いてあるわけではないので、お急ぎの人はスルーしちゃってください） 前提として、分散バージョン管理システムを使うケースというのは、複数の人が共同でソフトウェアなどを作るという状況のときだ。管理の対象は通常ファイルになる。複数の人が同じところにいるという必要はないけど、別に同じ場所にいてもいい。「分散」というぐらいだから、インターネットさえ繋がっていれば、地球の裏側でもいいし、火星から共同開発をしてもかまわない。そーゆー前提でソフトウェアを開発するとする。 それのレポジトリをどこに置くかという問題は、社内のどっかのサーバーでもいいし、自分のPCでもいいし、インターネット経由でコラボレーションをするのならgithubみたいなサービスを使うというのでもい

日本において、就職したあと、大学で学び直すというのは、それほど一般的ではないような気がする。諸外国はどうなんだろうか？ 下記の資料などをみてみると、OECD教育データベース(２００５年)の調査では、25歳以上の大学生の比率は、日本は2％で最低、OECD平均は20.6%、最高はアイスランド40.1%となっている。 http://www.mext.go.jp/b_menu/shingi/chukyo/chukyo4/028/siryo/__icsFiles/afieldfile/2010/03/05/1287479_01.pdf また、社会人学生の比率も、通信制（放送大学を含む）を含めても平成13年に18,340人をピークに現象減少している。入学者に占める社会人割合は2%を切る。 日本はまれにみる社会人が勉強しない社会なのか？ enPiTなどのプログラムを作っても、顧客となる社会人に刺さらなけ

みんなで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を利

1990年代のインターネットというのは利用者も少なく閉じた世界観があって、自由というもののある種の見えない掟みたいなものがあった。あったのかもしれない。当時ネットニュースという掲示板みたいなものがあって、今で言うところの中二病をこじらせたいい歳をした大人たちが日夜あーでもないこーでもないと言い合っていた。 fjというネットニュースがあって、日々いろいろな話題が議論されていた。あなたの会社のエラい人も若い頃、そのネットニュースに書き込んでいたかもしれない。若き日の（15年前）まつもとゆきひろさんとかがいるよ。 たまたま、そのころのニュースを発見して、あまりの懐かしさにここに再掲することにする。若き日の、あの人やこの人の中二病時代の書き込みである。 編集解説はわたし。それ以外は、当時の誰か。 https://groups.google.com/forum/?hl=ja#!topic/fj.co