転職エントリーと退職エントリーは見かけるけど、途中の感想エントリーをみかけないので、つらつらと書き連ねたいと思います。だいたい1年4ヶ月ぐらい経って、一通り会社の雰囲気はわかって来たかなと。写真は五反田の西安飯荘の坦々刀削麺です。
仕事はFutureVulsの開発をちょびっとお手伝いしたのと、あとは客先常駐です。うちの会社では客先常駐は基本的に少なくて、打ち合わせはお客様のところにいくけど開発は自社に持ち帰って行う、ということが多いので、レアケースのようですね。自社の方が席が広かったりもろもろ快適ではありますが・・・今のお客様のレベルは高くて、他のベンダーさんからきている人たちのレベルも高くて良い感じです。エリートが揃っている感じ！
Goならわかるシステムプログラミングがこのたび2回目の増刷がされまして、そのタイミングでPDF販売も開始されました。ラムダノートのサイトで直販で購入し、ユーザー登録をしていただいている方はPDFが自動で追加されるとのことです。直販で購入したけど、まだユーザー登録がまだの方は、購入した時のメールアドレスでユーザー登録をすれば大丈夫なはずです。なお、1刷をお買い上げいただいた方も、1刷と3刷の両方のPDFが登録される予定とのことです。
増刷で修正するのは編集者として恥ずべきみたいな文芸の編集者の発言をみて彼我の差を感じるなど。
— keiichiro shikano λ♪ (@golden_lucky) January 14, 2019
増刷で何をどれくらい直すかについては、企画そのものに対する姿勢、制作物に対する責任、ISBNに関する規約の解釈、書籍の流通との調整、既存読者と潜在読者の調整、などなど押さえるべき要因がたくさんあるので、増刷で直すなんてあり得ない、みたいなことを言う業界人は、あまり深く考えてないと思う
— keiichiro shikano λ♪ (@golden_lucky) January 14, 2019
で、いろいろ考えた結果、弊社は増刷でがんがん最新情報にアップデートしていきますよ。たとえば来月リリース予定の第1版第3刷『Goならわかるシステムプログラミング』は、正誤を直すのはもちろん、Go 1.12Go 1.12 betaにも対応だし、DPDKとかも追記しちゃう。お楽しみに。
— keiichiro shikano λ♪ (@golden_lucky) January 14, 2019
という感じで、10ページ以上増えています。増えた内容はこんな感じです。絵文字は、変更点のダイジェストを紙面に載せるために適当に重要そうなものを抽出した（
）みたいな感じです。もしかして、雑誌以外ではHTTP/3って文字が入った最初の本になったりするんですかね？そんなことはないかな？Go 1.12について触れている本では世界最速な気がする。
Go 1.8とPrintlnの中のコードが変わったので修正DPDK/gVisorの紹介を追加論理ボリュームマネージャについての説明を追加ファイルモードについての説明を追加Windows 2018 April UpdateのAF_UNIX対応について説明を追加実行ファイルフォーマットと、アプリケーションのメモリ配置のついての項目を追加アドレス空間配置のランダム化についての説明を追加実行ファイルにアセットをバンドルする手法について紹介sync/atomicを使ってアウトオブオーダーでも読み書き順序を守るコーディング方法について紹介PySpaアドベントカレンダー2018のエントリーです。昨日は@taichiでした。
昔になるほど、少人数でプロダクトを作り上げた、短期間でやりきった、という話を聞きます。 たとえば、10年ぐらい前の事例だと怪盗ロワイヤルの開発の話とかありましたよね。 ずっと前だと、車の設計を第一線で指揮しながら、会社の経営をしていた本田宗一郎がいましたよね。
最近はそういう話を聞きません。ソーシャルゲームも開発費は5億を超えるようになってきました。 車の設計も3桁億円ですよね。個人でハンドリングできる分量を超えています。
ちょっとした構成要素、自動車のブレーキ1つを取り出しても、今は自動車会社のブレーキ担当の社員が一生かけて取り組むような感じです。 タイヤもなんでもそう。どんどん狭く深くなり、1人が見れる世界がどんどん小さくなっていきます。
1の工数で全体を完成させていた時代は、会社の中ですべてのプロセスが回せていました。 それで商品が開発して商売ができていました。で、よりよいものを作ろうとして2の工数をかけてすべてをブラッシュアップした製品ができました。 それが5になり、10になり、20になり、100になり・・・競争が続く限り、いくらでも工数は増えていきます。 たまに技術的な発展の恩恵を受けて工数あたりの生産性があがったりしますが、その上がった工数はさらなる品質向上に使われていきます。 だって、他の会社も似たような恩恵は受けますからね。その会社だけの恩恵にはなりません。
そのうち、工数の増加に対して、人を増やす速度が間に合わなくなったり、コストが見合わなくなります。 そうなると、完成品を作っていた会社は、その部品を他の下請け会社に依頼します。下請け会社も同じ程度の工数増が必要となります。 ですが、下請けの会社は多くの会社から受注し、数が増えるので吸収しやすくなります。開発費は変動費なので、たくさんの会社に卸して生産量が増えるとコスト削減効果が大きく見込めます。
そんな感じで、どんどん、外に投げる割合が増えていきます。それが経済合理性のある行動だから、それを止めることはできません。どの領域を自分で持って、どの領域を投げるか、どの順番で下請けに出していくかという選択ぐらいは制御可能です。もちろん、その部位が競争力の厳選であるならば、安易に投げると競争力の低下に繋がります。ですが、コモディティ化してしまうと、自前で頑張ってコストをかけるのは投資効果を弱め他のところで差をつけられる要因となります。ちょっと前までは自動ブレーキはメーカーの技術力を競う場になっていましたが、今は予防安全性能アセスメントというものができました。早晩、この星取表に合わせてみんな課題を解決して、差がなくなってくるでしょう。
今この瞬間だけを見て、「外に丸投げはけしからん」というのは簡単ですが、競争力につながらないなら仕方がないですよね。 急速な電動化も、ソフトウェア技術者がどこも不足するという結果になっていると思います。新しく採用しようにも、規模が大きくて雇用に柔軟性がない事業会社にでは転換が難しいです。 領域のシフトは10年、20年単位で計画して、大規模な人員の移行計画（首切りではなく）とセットでやらなければならない。そもそも人がいないのに、いらなくなるからレイオフ、みたいな欧米スタイルを日本でやってしまったら人が減って今の本業もだめになるだけですしね。
受け入れ側の上流の会社もサボっているわけではなく、受け入れ責任をきちんと果たしています。なにかトラブルがあったときに、 すぐに下請けやベンダーの名前を出して責任を転嫁する会社も一部にはありますが、基本的には名前を出さずに、 責任を持って顧客に提供する会社が大多数だと思います。お客さんは安心してそのブランド名を見て購入ができます。
ソフトウェアの場合はOSSとかがあって少し事情が異なりつつも、事情はだいたい一緒です。 最初は少人数で開発できていたのが、多くの人数が必要になっています。 ちょっとしたライブラリとかも少数や個人で開発できていたのが、最近はGoogle、Microsoft、Facebook、Amazonなどの 大手が提供しているOSSは積極的に使うが、他はおまけ（補完）として使う程度、みたいになってきています。 個人開発のOSSはいつ開発が止まるからわからないから警戒する、みたいな話もあります。 クラウドの場合はさらに一歩進んでいて、R&Dはクラウドベンダーが行い、他の利用者はお金でR&Dを支援しつつ、新しいものを利用させてもらう、といった感じの分業が進みつつある、という気がしています。他社がOSS+サポートでビジネスにしょうとしているOSSを利用しやすくして売上を剽窃・・・みたいないま一部で話題になっている話はとりあえずおいておきます。
ITの世界だと、何かしらの画期的なソフトウェアが出てきて（ゲーム開発のUnityとか）、○○の民主化、 みたいなムーブメントが発生することがたまにあります。ハードでも、Rasberry Piとかありますね。その瞬間は、技術力で劣っていた会社はその新しいちからを借りて ブーストし、市場に打って出ることができます。ですが、すぐにゼロスタートの血みどろのチキンレースがその瞬間から開始されます。 フランス革命は初の市民革命だったかもしれませんが、すぐに民主主義の社会になったわけではなく、ジャコバン派の恐怖政治が始まって、 テルミドールのクーデターがあって、ブルジョアジー政権になって、ナポレオンのクーデターが起きたりするわけで、ソフトウェアの世界も似ていますよね。 ゲームエンジンビジネスは、安価な値段で市場を席巻したUnityと、Fortoniteとか他に稼ぎ頭があるUnreal Engine 4の大規模案件以外は 無料という2大攻勢により、今はもう新しいプレイヤーが登場することはかなり難しい、という状況になっています。
工数と、システムの規模のアンバランスは、システムを作りきったあとにも問題として発生します。 昔書いたブログエントリーでは、ドメイン知識の分量がが現場のユーザーの理解できる量よりも大きくなってしまい、システムエンジニア側にドメイン知識が移動してしまう話を書きました。
少ない人数で手作りでイノベーションというのは、早急に工数の増加とともに、何らかのタイミングで損益分岐点を超え、企業の手を離れ、 競争の中でいつしかコモディティ化していく・・・多くの人が考えるイノベーションの形というのは、長いライフサイクルのほんの最初の一瞬だけなんだろうな、 というのを、前々職を辞めたブログエントリーを見て思いました。
自分がそのどこで技術の発展に関われるのか。常に0から1を生み出せる人は先頭にい続けられると思いますが、そうでない人は、早晩川下の方に流されていくんだろうな、と思っています。それでも、どこかしらのイノベーションのライフサイクルに、少しでも長く関わり続けられればいいなぁ、と思っています。
明日はbuchoです。抱腹絶倒かつお涙頂戴で感動の嵐間違いなしです。みんな超期待して待っていてください！
少し前に、レビューに参加したGo言語による並行処理が出版されました。献本もいただきました。ありがとうございました。レビューする前から、かなり読みやすい翻訳となっており、3章分レビューして欲しいと、作業分担はあったのですが、おもしろくて全部読んでしまいました。より詳しい本書の内容はmattnさんのブログが詳しいので、そちらを読んでいただくのが良いと思います。
謝辞にも書いていただいたのですが、僕もGoならわかるシステムプログラミングで並行とか並列とか書いたことがあったので、注釈として原著の内容を補足して増やしてもらう方向のコメントを少ししたりしました。Goでの並行処理を学ぶには最上の一冊としてあって欲しいですからね。僕の本はどちらかというと、「Goを学ぶ」よりも「Goで学ぶ」志向ですし。また、翻訳の指摘というよりかは「きっと著者が本来言いたかったことはこうだ」と、原文で気になったところとかも多少コメントしました。
僕のレビューの貢献はごく一部ですが、ymotongpooの献身的なコミットメントや、多くの人達のすばらしい指摘により、英語ができる人が英語で原文を読むよりも、遥かにすばらしい翻訳になっています。最新の1.11での結果以外にも、いくつも日本語オリジナルのコラムがあります。英語版を買った人も、ぜひ日本語版を手にとって見てください。
本書でも、contextに関しては4.12で説明されています。Goの設計について議論になると高確率で指摘が飛んでくるのが例外処理ですが、contextはかなりGoっぽい例外処理機構だな、と改めて思いました。例外処理機構としてのcontextについては、Pull Requestのプロポーザルでも触れられていないので、こういうことを考えている人は少ないのかな、という気持ちもあるのでこのエントリーの中でちょっと説明してみようかと思います。
例外処理というのは、よくある言語の機能としては、問題が起きたときにそれを上流に流す機能です。あまり見かけない機能としては、Rubyのretryによる再実行とかがありますね。最近話題のReactのSuspenseは、ただ上流に流すだけではなく、完了時に再実行するためのPromiseを投げる機能が追加されています。で、golangはというと他の言語にある例外はありませんが、contextが一種の例外処理を担っていると言えると思います。
Goは本書の帯のように「湯水のように」並行処理が行えます。例外は現在実行されているスレッドのスタックを巻き戻しながら、帯域脱出します。しかし、Goのように複数のgoroutineがあると、現在のスタックのみを巻き戻しても仕方がありません。contextは、sync.Condのような条件変数として動作します。起点となるgroutineから、100個のgroutineが起動したとしても、context一つで、一斉にタスクを止めることができます。正確には、各groutineがcontextを見て、任意のタイミングで処理を中断します。
GoはgoroutineがIDを持っておらず、そのために外部から強制的に中断させることはできません。しかし、中断しても良い切のいいところにいるかどうかは外部からはわからないため、合理的な設計になっていると言えます。contextの一斉停止のトリガーも、ネットワークを使うシステムでよく使われるGoらしく、自発的なキャンセル以外にも、タイムアウトなどが用意されています。このあたり、他の言語でも少し欲しくなってきます。
Go 2のproposalの中にはエラーハンドリングについてのものもありましたが、個人的には、JavaScriptやC#などのasync関数のように、contextを扱う関数をより実装しやすくする、という方が、エラーハンドリングの根本解決になるのではないか、と思ったり・・・
Go言語による並行処理はおすすめです！6月に出たGo言語で作るインタプリタ本も良かったですし、プログラミング言語別の年収ランキング中央値1位になったGoを簡単に深く学べる環境がどんどん整ってきています。
オライリー・ジャパンの最新のGo本のGo言語で作るインタプリタの献本をいただきました。ありがとうございます。
本書は海外では出版社を通して出版されていないWriting An Interpreter In Goの日本語版です。誤解している人がかなり多いので捕捉しておくと、オライリー・ジャパンの本の多くは、USオライリーの本ですが、たまに別の出版社の本の翻訳があったり、描き下ろしもあります。別の出版社だと有名なのは退屈なことはPythonにやらせようで、描き下ろしだとゼロから作るDeep Learningや、僕の書いたReal World HTTPとかがあります。
本書の翻訳はとても読みやすく、どんどん読み進めることができました。翻訳の設楽さん、お疲れ様でした。
原著は「短いページ数で実用的な言語を実装する」というのを目標に書かれています。本書のサンプルのmonkeyはどこかで見たような要素が満載の、RubyのようなJavaScriptのような言語で、前置演算子や優先順位にきちんと対応した数式、変数、if文、関数、return文を持った言語です。型も、整数、bool、nullに対応しており、4章の拡張では組み込み関数、文字列型、配列、ハッシュも実装します。お気に入りの言語風の文法を実装したい！と思っても（例えばループとか）、十分に基礎が解説されているため、応用をするのはやりやすいと思います。
プログラミング言語の要素というのは単純な単方向グラフにならず、要素が巡回するので、いくらテスト駆動開発の達人だろうが、スモールステップで開発するのが難しいジャンルのアプリケーションです。この本は動くものをどんどんスモールステップで作っていくので、非常にストレスが少なく楽しく作れます。この本はテストコードを書き、インタプリタのコードを書くというのを交互に行っていきます。
僕も、かつてFlex/Bison本を読んで、実際に趣味でインタプリタを作ってみたり（Ruby on Pythonとか）、数式パーサ（Excelのセルの数式の）を作ったりしたことがありますが、途中でずっとテストがグリーンにならない期間をずっと過ごしたり、なかなか動かなくてヤキモキして、苦しみを乗り越えてようやく動く、みたいな感じでした。本書ではうまい具合に「ここはTODOを書いて雑な実装でまずはパスして、あとで戻ってきて修正しましょう」ということが書かれています。こういう設計の分解方法はボトムアップじゃなかなか到達できなくて、熟練の業なんだろうなって思います。かつてコンパイラやインタプリタの本を読んだことがある人にも、目からウロコだと思います。僕はウロコがいっぱい落ちました。
今年、オデッセイハイブリッドを買いました。
シビックも良い車でしたが、子供三人の自転車をつもうとするとスペース的に無理なので、買い替えました。今度買い換えるときもハイブリッドにしよう、と思っていたのと、自動ブレーキは付けたいな、と思っていました。あと、２列目がベンチシートじゃないと、子供一人が三列目、ということになってしまうので、ベンチシートは最低限。ホンダだと３列シートの車は、フリードハイブリッド、ジェイドハイブリッド、ステップワゴンハイブリッド、オデッセイハイブリッドの４つあります。このうち、ステップワゴンはスパーダ仕様しかないので２列目はキャプテンシート。ジェイドも同様なので、この２車種は選択肢から外れます（ステップワゴンは契約直前に気づいてやめた）。フリードは三列目を使わない時にスペース効率が悪いので、オデッセイになりました。
自動運転は完全に自動というわけではなく、「この条件ならいける！」というのを判定して有効化してやる必要はありますが、めちゃ便利です。自動運転と一口にいっても、機能としては自動ブレーキ＆前車追従自動アクセル、高速道路限定だけど自動ハンドル、の３つです。自動ブレーキは試したことないですが、本当に楽です。もちろん、一般道の微妙なケースで「もっと早くアクセル踏んで欲しい」とか思ったりはありますが、高速道路はすごく楽です。今は状況判断は人間がやりつつ、システムの癖を把握してボタンを押すので、それなりに熟練を要する装備です。
購入前はわからなかったこととしては、自動追従モードの設定可能な最高速度は135km/hです。もちろん、前車がその速度を出さないと出ないのですが、将来、新東名が120km/hになっても利用可能です。
自動運転以外にも、音が静かだし、音楽めちゃ聞けるし、重量1.5倍になったのに燃費変わらないし、ホンダでミニバンの最高級車種なだけあって内外装もしっかりしているし、ライトとか駐車時のサイドミラー操作とかいろんなものが自動だし、すごく良いです。
これはPySpaアドベントカレンダー2017のエントリーです。
三年前に家、今月は車とローンをガシガシ組んだりしたのですが、お金を借りるということについて、まだまだ否定的な人がいたりするので、借りるということはどういうことなのかまとめてみます。 お金についての教育は日本にはないので、将来、子どもたちにお金について説明するための考えの整理でもあります。
特に、今は働き方改革という名の下に副業もできるようになってきました。去年ぐらいから自動車ローンも繰り上げ返済が可能になりましたし、残価設定ローンとの組み合わせで戦略の幅が広がったので、定期的に入る収入を当てにしたローンとくらべて、副業する人に優しくなっています。このあたりはお金を借りたことがある人も、そうじゃない人にも参考になるかなと思います。
日本だと「お金を借りる」ことを蛇蝎のように嫌がる人、恐怖を覚える人が数多くいます。そもそも何のためにお金を借りるんでしょうか。 お金を借りると当然利子が発生します。現金をがっと貯めてから購入すれば利子の分お得です。お金を借りると損です。それでも借りるのは、時間を前倒しするためです。30年ローンで家を買わずに、お金が貯まるまで待ってから買うとすると、家を手に入れるころにはもう爺さん婆さんになっているでしょう（買うまでの賃貸も別にかかります）。ファミリーカーを買う頃には子供が独立して旅行にいくことはなかった、となるかもしれません。なるべく若い内に手に入れて、それを存分に楽しむというのがお金を借りる理由といえます。つまり、お金を払うのは時間を買うということになります。
長期間使うものであれば、借りて自分のものにすることでお金を節約するというのもあります。
例えば、うちでは毎週土曜、日曜はたいてい車ででかけますし、平日も子供の病院などでよく運転します。この前売ったシビックは10年で9万キロ弱です。この期間と距離走るのであれば、レンタカーにせよ、カーシェアにせよ、タクシーにせよ、買ってしまった方が安いですし、貸し借りの手続きや待つ時間も節約できます。
家を借りるのと買うのとどちらが得かという話はよく出てきますが、短期的に見れば買ってしまったほうが得なはずです。特に、数が少なくて流動性の低いファミリータイプの新し目の物件だと、賃貸と購入で月々の金額が２倍、もしくは面積が半分というのが東京圏では平均的な差でしょう。借りる金額には、修繕の予備費やら固定資産税（自分で住まないと高い）とかも上乗せされる上に、数%の不動産投資利回り等も載ってきます。貸し出す方も商売ですからね。うちは駅からは少しありますが、23区で上モノ80平米ちょっとで、土地も同じぐらいの駐車場付き一軒家で、ローン支払いは9万円台です。
お金を借りる、という行為にも種類がたくさんあります。それによって利率が大きく異なります
これ以外にもベンチャーのファンド的なものとかもありますが、本稿ではそこは省略します。もちろん、これにとどまらずたくさん種類があります。
目的を決めて、なおかつ審査など返す見込みを確認するのが住宅ローンや自動車ローンなどです。住宅ローンは0.7%、自動車は1.9%とかでしょうか。2つ目はクレジットカードの分割やリボ払い、クレジットカードを使ったキャッシング（お金を借りる）、消費者金融などで、利率は15%とかにもなります。大きいですね。３番目のは僕は詳しくないので、省略します。
銀行などはお金を貸して利子をもらう商売です。返せない客にお金を貸すと銀行も損をしてしまうので、高リスクな分、利率があがります。 住宅や自動車の金額が大きなローンだと、支払い能力があるかどうかのチェックがあり、リスクのチェックを事前に行うためにその分利率が低くなっています。 なお、リスクチェックは所属会社とかで決まることも多いので、いくら年収が大きくても自営業だと審査が通らないことも数多くあります。 残酷ですが、大きな会社の所属して、転職前にローンを組むという話はそこから来ています。
クレジットカードも分割をせずに期日に間に合わせて支払えば利子はかかりませんが、その期日を過ぎれば「お金を借りている扱い」となって利子が発生します。分割払いやリボ払いがそうですね。クレジットカード会社は、クレジット払いの時の一定割合を手数料としますが、この利子も収益源です。リボ払いにすると年会費が安くなりますという案内がよく来ますよね。顧客獲得コスト（安くなる年会費）以上に収益が見込めるということでしょう。
基本的には短期間で返し切る前提でなければ借りない方が懸命でしょう。クレジットカードのキャッシングも、僕はやったことはないですが、海外で現金を下ろすときには便利（ただし、日本に帰ったら速攻で返すこと）とのことです。
大事な原則は「借りたら返す」ということです。クレジットカードも、クレジットのキャッシングも打ち出の小槌ではなくて、将来返さないといけないもの（返さないと利子が発生し続ける）ものです。返す見込みがないものは借りてはいけませんし、見込みがない支払いというのはたいてい、利率が極端に大きいものばかりのはずです。支払い能力を利子が超過すると、「払い過ぎた分を取り返す」みたいな広告が去年ぐらいはたくさんありましたが、払いすぎてない分 == 法定金利は当然支払わなければなりませんし、それも利率としてはかなりの額になります。
知人から聞いた嘘みたいなカード破産の話としては、リボ払いをして、その支払をクレジットカードのキャッシングを使って払う、というものがありました。 やばいですよね。鳥肌が立ちますよね。このヤバさが分からない人はこのエントリーを読んだとしてもお金を借りる系のものには手を出してはいけないです。
ミスタービッグデータこと、しましうまちから異文化理解力という本を紹介してもらいました（しうまちは確か@d1ce_から教わったと言ってた気がします）。アマゾンのレビューの圧倒的な評価を見れば分かるように、とてもすばらしい本です。著者が数十年にわたって仕事で活動してきた内容の集大成であり、多くの国々の人々に対する調査の結果がこれでもか、と盛り込まれた本です。下調べの圧倒的な量からして、この本を書ける人はほとんどいない、というカテゴリーの本です。
この本は、国際的なチームの仕事のトラブルの原因として、受け手が期待するものと、話し手が期待する価値観の違いがあるとして、８つの領域に分けて詳しく説明しています。普通に読んでもとてもおもしろく、「ああそうだよね」と思うところもたくさんありました。ただ、この本を文字通りではなく、応用的に読むこともできます。本エントリーでは2つの視点を紹介します。
ちなみに、アマゾンのKindleの方には書籍紹介として、（なぜか）本を貶めるような説明（おそらくレビュー記事のタイトルで本文を読まないと真意は分かりません）もありますが、そんなことはありません。
フューチャーアーキテクト裏アドベントカレンダーのエントリーです。9月から、DeNAからフューチャーアーキテクトに転職してお仕事しております。どちらかというとネットで話題になるのはSIerからWeb系ばかりなので、それとは逆ですね。Vulsで有名な神戸さんに声をかけていただいて、一度飲み屋で焼き鳥食べながらお話をして「次は役員呼びますわ」と言われて、今の上司の宮原洋祐さんを紹介されて焼肉を食べて、「次は会長紹介しますわ」と言われて、創業者で会長の金丸さんと面談があって「うちにおいでよ」という感じで、「次転職する時はクイズみたいなの楽しみだなぁ」と期待していたものもなく、１時間の面談でOKが出てしまい、他の会社も受けることなく決まりました。人事の方も「初めてのケース」と言われてました。
ソーシャルアプリプラットフォーム構築技法――SNSからBOTまでITをコアに成長するというお金の匂いがすごくする本が技術評論社から出版されました。その筋の人には有名な、田中洋一郎さんの渾身の一冊です。
田中洋一郎さんはソーシャルプラットフォームに長年携わってきました。その数々の経験から生み出されたのがこの本書です。技術書のカテゴリーではありますが、ソースコードよりもソーシャルプラットフォームが備えるべき機能の概要設計およぼそのチーム編成やガバナンスが中心です。ちょっと上流な本です。とはいっても技術の部分で見てもなかなかの太さです。洋一郎さんさんGoogle API Expertという、今はもうない肩書のホルダーです。たしかOpenSocialのExpertで、それゆえに認可認証周りとかの説明が手厚くなっています。このあたりは規格を見ても「何のために？」がよくわからないのですが、「なぜこうしなければならないのか」「それを実現するにはこの規格を実行すればよい」というのがクリアに説明されています。
また、時代の流れにあわせて、スマホアプリのソーシャルネットワーク認証周りとかも、iOS/Androidに向けてそれぞれ書かれていますし、ハマりがちな落とし穴とか、注意すべき点とかもたくさん書かれています。また、近年話題にあがることが多いチャットをベースにしたソーシャルアプリであるBOT周りとかもいろいろ書かれています。インターネットに絡む技術のうち、何を使ってどうすればいいのかを照らす松明のような本です。
この本が一番すごいのは、やはりSNSを運営するための組織体系とか、利用規約などについて、事細かに書かれています。おそらく、長年の経験による積み重ねのベストプラクティスです。法務やサポートなども含めて、本にかかれているとおりに実践しようとすると、軽く20人とか30人以上の大所帯のチームが必要になります。どんなにコンパクトで必要最低限に作ろうとしても、軽く年間で億の単位で、しばらく継続すると２桁億はお金がかかるでしょう。それだけの経験を得ないと書けないような本です。つまいは２桁億円分の価値があるといえます。また、これだけお金がかかってもなぜ企業はSNSを作るのかというと、それによって大きな収入を得たいからです。この本も、そういうチームを組織しつつ、きちんと「お金をいただく」というところを逃げずに書いています。なかなかこれほどお金に真摯な技術書はなかなか珍しいかと思います。
（お金の面で）こんなに（完全な）実践が難しい本もなかなかないからといって、それ以外の人に無駄ということはありません。本書のターゲットであるソーシャルネットワークを作る人と、それに乗っかるアプリケーションを作る人では、人数比は1:9以上だと思いますが、前述の技術的なところの内容は後者の人にも十分に役に立ちます。いや、まじで認証周りの情報が整理されている点だけで元とったと思える本です。
もうちょっと田中さんの目線で解説がしてほしかった項目も少しあります。例えば、僕が知っている内容だと、モバゲーの簡単会員とかはちょっと特殊だけど「なるほどなぁ」という仕組みだったりします。後は、最終章のBOTのAPIだとSlackがウェブフックも、ストリームもサポートしつつ、OAuth2認証のアプリマーケットまで備えたりとかなかなかリッチなので誰かに詳しく説明してほしいなぁとちょうど思っていたところです。まあ全体からすれば小さい話ですし、後者もまだまだ変わる可能性があるので本で扱うのはちょっとむずかしいかな、という気もしています。
それ以上に少しこの本が損しているな、というポイントは「ソーシャル」という言葉がタイトルに入っていることなんじゃないかと知人が指摘していました。確かに「ソーシャル」という言葉を使う機会は相当減っているような気がします。確かにSNSの最初のSはソーシャルですが、もはや「SNS」という用語みたいになっています。本書で書かれているプラットフォームは、たとえばGitHubだったり、アプリマーケット全般にも有効な話ばかりです。SNSだとマインドシェア１位以外は生き残りが難しいレッドオーシャン、みたいな印象がありますが、「アプリマーケット」という別の領域でも活躍できる話ばかりです。
なお、この本はとてもきれいな（クリーン＆読みやすい）日本語で書かれています。本文で丁寧に説明されていて、脚注などはありません。しかし、「◯◯をしてしまうとトラブルが発生したときに大変です」みたいな日本語の裏には、きっと表に出せないようないろいろな修羅な体験があったのではないかと想像に難くないです。ぜひとも、洋一郎さんが、人には言えない数々のトラブル事例とかを紹介してくれるディナーショーとかあるなら参加したいですね。そういうのを想像するだけでもなかなか楽しく読めます。
Real World HTTPに引き続き今年2冊目の書籍が出版されます。ASCII.jpの連載をまとめて、加筆修正したものになります。最初は、連載をつなげて、はじめに、と次回予告を書き換えてつなげればOKという感じからスタートしましたが、章構成を書き換えたり、書き始めのときに「そのうち連載で触れる予定です」を「◯◯章で説明します」に書き換えたり、せっかくだから内容を追記しようとか考え始めたり、レビューアのメンバーが「これは並列・並行の結果であって原則とは違う」みたいな細かい定義のところまで指摘してくれて説明を大幅に書き換えたり、蓋を開けたら前から最後までかなり時間をかけて修正することになりました。せっかく転職で有給消化が一ヶ月あったのですが、この原稿の修正で一ヶ月がするっと溶けました。
11/16追記 Amazonでも販売がはじまっています！
大きな修正ポイントは次の通りです:
これ以外にも数多くの修正を加えています。紙の書籍にするにあたって、数多くの知人に協力してもらって、レビューしていただいたのですが、1ページにつき1件というペースに近い300件近い意見をいただきました。これは連載をしていたので、一度細かい所まで見て修正したので些細なミスはあまりないはず、というところからの出発でしたが、遠慮なく徹底的にみてくださったレビューアのお陰で、かなり改善されています。ASCII.jpの連載終了から440コミットありました。
元は、LLでウェブアプリケーションフレームワークを普段作っているけど、低レイヤーを学ぶチャンスがなかなかない人に向けて本を書くといいのではないか、とラムダノートの鹿野さんと雑談したところから始まった連載でした。Real World HTTPも通信の低レイヤーではありましたが、こちらはOSの方面の低レイヤーになります。C言語を使った、読む側にもそれなりの知識が必要とされる本はいくつもありましたが（とても良い本です！）、本書はそういう既存の本よりも読みやすい本が提供できたのではないか、と思っています。アプリケーションレイヤーの応用例もイメージでき、古い本では紹介されているけど、現実的にあまり使われていないものは省き、逆に最近のトピックに触れるといったことで違いを出しました。
昨年から書いていたReal World HTTPがAmazonのページに表示されるようになりました。最初にコミットしたのは昨年の8/1ですが、たぶん、その数ヶ月前から書き始めていたと思うので、ほぼ丸一年です。途中でASCII.jpのシステムプログラミングの連載が始まったり、Software DesignにSphinxについて寄稿したり、もう１つ別の翻訳の企画があったり、三女が7/4に生まれたり、なかなかハードな一年間でした。
なお、表紙は皆さんが知っているものとはちょっと違うのですが、系統的に一番近いのがハシビロコウさんらしく、和名もそれしかないそうです。狙っていたわけではなく、そもそも出版時期にはアニメも終わってしまっているし、話題の動物は辞めたほうが良さそう、という話をしていたのですが、偶然これが選ばれました。
裏表紙の紹介はこんな感じです。
本書はHTTPに関する技術的な内容を一冊にまとめることを目的とした書籍です。HTTP/1.0、HTTP/1.1、HTTP/2と、HTTPが進化する道筋をたどりながら、ブラウザが内部で行っていること、サーバーとのやりとりの内容などについて、プロトコルの実例や実際の使用例などを交えながら紹介しています。 GoやJavaScriptによるコード例によって、単純なHTTPアクセス、フォームの送信、キャッシュやクッキーのコントロール、Keep-Alive、SSL/TLS、プロトコルアップグレード、サーバープッシュ、Server-Sent Events、WebSocketなどの動作を理解します。 これからウェブに関係する開発をする人や、これまで場当たり的に学んできた人にとって、幅広く複雑なHTTPとウェブ技術に関する知識を整理するのに役立ちます。HTTPでは日々新しいトピックが登場していますが、本書によって基礎をしっかりと押さえることは、さまざまな新しい技術をキャッチアップする一助にもなるでしょう。
目次はこんな感じです。
内容としては、HTTP/1.0、HTTP/1.1、HTTP/2というおおざっぱな期間ごとに次の３つの章を繰り返してその時期に登場した技術のトピックをいくつか紹介し、最後にセキュリティとRESTfulの章が追加されている感じです。
実際にはHTTPのバージョンは時期的な目安なので、そこまで厳密ではありません。消化不良にならないように読みやすく分割するための分け方です。人間の記憶はエピソードとともに知識を固定する方がやりやすいので、そういったことを心がけています。普通のHTTPのプロトコルの技術的紹介だとなかなか詳しく紹介されないであろうトピック（TLS、認証／認可、セマンティックウェブのその後、セキュリティを守るためのブラウザ技術）についても、多くの方々の強力なバックアップのもとに概要をきちんとつかめるように書きました。
アプリケーション開発だと、ウェブに関係しないシステム自体がだいぶレアになってきているので、かなり多くの人に末永く参考にしていただけるのでは、と思っています。CGI時代やJ2EE初期時代に学んだ人も、その後の知識のアップデートに役立てていただけると思います。最新のブラウザの機能（セキュリティのヘッダーとか）も、過去の経緯や機能を踏まえて追加されることがほとんどです。一通りきちっと学ぶことで、今後出てくるトピックを追いかけるのがとても楽になるはずです。「読める！読めるぞ！」とムスカになったような感動が味わえるはずです。
後は、書いていてワクワクしていたポイントは、HTTPまわりの仕様にはさまざまなエンジニアリングの創意工夫があることです。後方互換性を維持するしくみとか、サーバー・クライアントでベストな選択肢を選ぶ方法、効率の改善。こういうところに着目して読んでもらえると（上級者には）楽しいと思います。
大学のサークルの後輩の吉村総一朗（当時呼び捨てで呼んでたと思うので、あえてこのまま敬称略で書きました）から、高校生からはじめるプログラミングを献本でいただきました。ありがとうございます。
IPを使った表紙、フルカラーの本文、高校生どころか老眼鏡を使うような人でも読みやすそうな大きな文字、「（」の記号の入力の仕方から教えるような今まで無かったというか、小学校入学前の子供をターゲットにしたたのしいプログラミング Pythonではじめよう！（ただし原著。日本語は漢字や英語の習熟の問題もあって中学生以上がターゲット）の方がストイックなぐらい。こんなにコストがかかったプログラミングの本は見たことがないです。その徹底ぶりが評価されてか、Amazonのランキングでも上位に常駐しているようです。羨ましい限りです。
内容としてはHTML/JavaScript/CSSを入力してブラウザで動かしてみよう、というノリです。かつて僕が衝撃を受けた、ラベルをウインドウに貼り付けることでコードを一行も書かずにHello WorldができてしまったVisual Basicに近いアプローチです。関数とかメソッドとかクラスとかそういうのはどうでもよく、まずは動くものを表現して、徐々に新しいオモチャを提供していくスタイルです。今日ではコードスニペットを利用することも多く、Twitterのボタンを作ってみる下りはそういった操作の紹介もされています。
「チュートリアルの記事を公開したり、インターネットで困っている人を助けるといった活動はどこまでやるべきか」というのを議論したことがあります。個人的には初心者に対するサポートという意味ではオールインワンのインストーラでWindowsユーザーでも安心だし、ドキュメントにはコピペ素材が満載のPHPというのが１つのベンチマークだと思っていました。ツールやライブラリもPHP並に初心者をファシリテートしてあげるのが大切だと思っていました。僕がドキュメントツールのSphinxのコミュニティを作ったり、Pull Requestを投げたりするのも、こういった考えからです。
しかし、そこまでモチベーションが高くなく、質問ばかりしてチューターのやる気を削っていくような人もいます。そういう人は放置すべき。千尋の谷から突き落として這い上がるやつができるやつ、みたいな考えを持っている人もいます。コミュニティ運営やドキュメント整備などを行う人のリソースの少なさを考えると、残念ながらこうせざるを得ない言語やフレームワークのコミュニティも多いかもしれません。僕もPHPを基準に考えていますが、そこまで来られなかった人は残念ながらそれ以上のサポートはちょっとムリと思っています。
しかし、子供の頃に体育の授業が苦手で体を動かすことが苦手だったけど、オトナになってボルダリングをやってみたら楽しかった、インラインスケートをやってみたら楽しかったといった体験をする人が増えています。サッカー、野球のようなスポーツではなくて、マイナースポーツ系のコミュニティに行くと「元運動嫌い」のオトナはたくさんいます。千尋の谷方式というのはこの体育の授業のようなものです。「人と比べられるのが嫌なだけで体を動かすのは嫌いじゃない」人にもまんべんなく「楽しんで継続してもらう」ことはリソースが少ないとできません。これは授業が悪いというよりも少ない教師数で30人、40人の生徒を教えるというリソースの少なさが問題です。実は才能があったかもしれない子供が早期にあきらめてしまうといったこともあったかもしれません。
この本は自習できる書籍という形で提供されており、さらに豪華な装丁で「コンピューター怖い」という人にも優しくアプローチしてくれると思います。小学校からプログラミングを、みたいな話もあります。Scratchとかになるとは思いますが、当然中学、高校と学年が進めばより実用言語の方向に進んでいくでしょう。現状のリソースでは体育の授業の「運動嫌いのオトナ」が量産されていく可能性の方が強く、個人的には子供のころからのプログラミングの授業導入はどちらかというと（僕も運動嫌いだったので）反対でしたが、こういった本が増えて、自習できたり、授業外で親が教えたりといったことで落ちこぼれない仕組みができるならもしかしたら悪くないのかもしれない、と少し思いました。
個人的にはアスキーでやっている連載のように少し自分の実力よりも背伸びした内容で、自分の好奇心も満足させながらじゃないと一冊分の集中力は続かないので、この本のような本は僕には書けないなということもあり、著者の努力はすばらしいと思います。
「献本は誤用でご恵贈が正しい」みたいなのも見かけますが、誤用とか勘違いが広まって文化になる、みたいなのが好きなのであえて献本にしました。「けんぽん」。声に出すとかわいい日本語。
これはPySpaアドベントカレンダー2016の20日目のエントリーです。19日目はPySpa界で圧倒的な存在感を誇るしうまちでした。
知人にジブラルタ生命の人がいて、その人の紹介で契約件数でトップの方を紹介してもらい、保険の見直しをしました。
ゲームでも投資でも勝ちに行く、負けないようにする、この2つのどちらを選ぶかで指し手は変わってきますよね。 節税とかあんまりわからないし、投資で大儲けとかも興味ないというか、お金のこと考え続けるのはあんまり好きじゃないタイプなので、 基本路線としては、家族全員が路頭に迷わない==負けない方向で考えています。 勝つ方向に興味ある人は、r_rudiさんの #kaneの話 の方が面白いと思います。
会社でサポートされるケースも多くあります。昭和からある大企業に努め続ける前提なら、退職金とか会社の提供する財形とかいろいろあります。 該当するならそれに乗っかってしまえば考えることは少なくて済むでしょう。関東IT健保に入っていれば医療保険もいらないです。 でもまぁ、同じ会社に入る続けるかどうかも分からないし、大手に入っても業績が安定しているとは限らないし、年金は出ないという前提で、自衛のために生命保険でバックアップを組むことにしました。
嫁の医療保険は、お義母さんが入ってくれてくれているのがありましたが、それも今回引き取って、こちらで全部やるということにしました。
本日より、ascii.jpでGoならわかるシステムプログラミングという連載を開始しました。ascii.jpのプログラミング+セクションが最近作られまして、そこのコンテンツとして、遠藤侑介さんのRubyで学ぶRubyとともに連載します。遠藤さんの連載も、RubyでRubyを実装しつつRubyを学ぶというマニアックな内容で、僕の方もシステムプログラミングということで、かなり尖ったラインナップです。僕も機能はだいぶ限られていましたが、PythonでRubyを実装しようとしたこともあり、遠藤さんの連載も楽しみです。
僕自身、システムプログラミングがすごく詳しいとか、めちゃ経験があるわけではないのですが、OSに近い機能をぽちぽち分かりやすい言語で触りつつ、僕自身も学びつつ連載を続けようと思っています。内容も、よくあるLinuxのシステムプログラミング系の本で触れているようなファイル、通信、プロセス、プロセス間通信、並列処理などに触れていく予定です。システムプログラミングというと、Linuxを対象に分厚い本で学ぶ印象がありますが、サンプルを動かしつつ、WindowsでもMacでもLinuxでもなるべく平等に気軽に楽しめる連載にしていきたいと思っています。
読者層として考えているのは、スクリプト言語などでフレームワークを使ってウェブ開発をしていて「ちょっと下のレイヤーも覗いてみたいな」と思っている人です。Goを選んだのはC言語でなければやりにくかったことを短いコード行数で実現できる点と、OS間の差異で学習が引きずられることがあまりない点が優れているからです。連載の主テーマはシステムプログラミングであってGoではないのですが、他の言語はある程度知っていて、Goは余り知らないという人向けにGoの文法も必要に応じて少しずつ触れていく予定です。
プログラミング言語Goが出版され、プログラミング言語C++、Core Java的な核となる書籍がとうとう日本のGo界にもやってきました。今後はみんなのGo言語のような、脇を固める本がどんどん出て、Goのラインナップの厚みはどんどん増えていくでしょう。Goは書きやすさもあり、コンパイルでエラーチェックもしっかり行ってくれるため、Pythonと同じように「学習のための擬似言語」としてのポテンシャルもあると思います。そのため、僕の連載にかぎらず、Go「を」説明するのではなく、Go「で」説明する、という用途がガンガン増えていくと思っています。今後共よろしくおねがいします。
連載にあたっては、読者目線で徹底的に鹿野さんに文章を揉んでもらいました。当初よりも洗練され、だいぶ読みやすい内容になりました。また、タイトルも知恵を絞ってくださいました。セルフパブリッシングが来ると言われていても、きちんとした編集の方に見てもらうのは今の技術では替えられないものがあります。文章を書くということは、情報をギブするとともに、読者の方々の時間を頂く行為でもあります。その時間を少しでも有意義にしてもらえるために、内容も文章の質も高いに越したことはありません。本は十数冊関わってきましたが、まだまだ勉強させていただくことがたくさんありました。
JavaScript界隈はそれまでの業界に較べていろいろ加速しているように見えます。
その中で新しいフレームワークが出ては大騒ぎし、「2015年のおすすめのツール集」が注目され、そして2016年にはがらっと大きく変わっている。そういうフロントエンド疲れが取り沙汰されています。その中で上記の記事は、技術に造詣が深く、適切に布教を行いながら学びを得ている人間(A)がいて、その活動はいいけどそれに乗っかってマウンティングしたがりの人たちがいるとしています。では、みなさんが思うAって誰でしょうか？でもおそらく、その人達も、かつては多分下のような、現在は滅亡してしまったものに夢中になったことがあると思うんですよね。
アジャイルとウォーターフォールの対比について話題になるのは、いつものことな感じがしますが、今回はウォーターフォールを支持する側の意見がはっきりと形になっているのがちょっと違うなと思いました。とは言え、読んでいて違和感を感じるところがないこともないので、僕の考えをまとめてみます。
npm周りでごたごたがありました。その前にはCocoaPodの問題もありました。その前にはGemの話も話題になりましたよね。
うんこれ。2年ぐらい前にnode.jsで開発していた時にも、node.jsのnpmのエコシステムいつか破綻するよなぁって思ってた。で、去年cURL as DSL作ったんだよね。Rubyのコード生成はまだないけどね。 https://t.co/1C0yw0KPib
— 渋川よしき (@shibu_jp) March 6, 2016
上記のツイートはgemに絡んでのツイートであって、コンテキストはnpmではなかったのだけど、なんか予言めいたツイートに見えちゃったのかもしれないけど偶然です。ここまで、いくつかの文化の変化がありました。
新しいことを始めたり、コードを改善する上での敷居がどんどん低くなって、コードを書く自由が飛躍的に高まりました。今回起きたnpm、CocoaPod、Gemの話はこれらの流れとは逆行する話です。作る自由というのは壊す自由と表裏一体です。変更やアップロードが取り消したりすることができなければ、作るのにみんな慎重になります。無茶できるのは、セーフティネットがあるからです。そういう意味で、「unpublishを禁止しよう」というのはちょっと違うかなぁと思います。それでは防ぐことはできません。
作者が癇癪を起こしてパッケージを消すという行為を防げるパッケージ管理システムは存在しないよね。unpublishを否定すればって書いてあるまとめ記事あったけど、中身を空にしてuploadされたらどうしようもない。
— 渋川よしき (@shibu_jp) March 23, 2016
壊れたアップロードもできないように制約をかけるべきか？マイナーバージョンアップでは、使われているすべてのパッケージで壊れないかを自動テストすべきか？というのを考えていっても、どんどん不自由になるだけです。
ちなみに、npmの対応を問題視している人もいますが、たぶん運営側になったらこのような対応をせざるを得ないかなって思います。全世界から使われるサービスで、「この国のこの法律に反しているんだけど」って言われた時にどこまで対応すべきか、無視すべきか、そこをきっちりガイドライン化できる人はたぶんいない。自分の国の著作権の扱いだけでもみんな頭を抱えている状態ですし、法的アクションを起こした人優先にせざるを得ないかなぁと思います。そうでなければnpm社が潰される可能性もゼロではないし、npm全体のエコシステムがまるごと潰されるよりは、指摘があったトカゲの尻尾を切り離す方が全体の保持になると思いますし。
The npm Blog − kik, left-pad, and npmなるほど。そもそも名前に関する紛争解決ガイドラインがあって、semverを使ってユーザーに負担にならないように名前を移管することが推奨されてるのか
2016/03/24 14:15
Github社だって、指摘があったらリポジトリをクローズします。知人がこれをされたことがあるのですが、反論の余地は与えられなかったとのこと。ここに消えていったリポジトリの墓標があります。他の知人で、Bitbucketでリポジトリをクローズされた人もいます。まあこれはプライベートリポジトリが無制限になった時にエロ動画をたくさんアップしたという事案なのでアレですが・・・
使う側での防衛方法としては、リスクを恐れてgithubやnpmの使用をやめる、というのはご自由にどうぞ、と思いますが、現実的な落とし所は、きちんと信頼できる開発元のライブラリを使いましょう、以上のものはないかな、と思います。
適当に作ったライブラリの紹介をしました。スライドの流れは、10数年前の、牛尾さん(当時NEC)のアジャイル原理主義のスライドのオマージュです。Goの人気ぶりを表すエピソードとして、アドベントカレンダー(3本埋まった＆Goを関してない企業アドベントカレンダーでもたくさんGoの話が出てきてた)みたいなのを言おうと思ってたけどいい忘れました。あと、Goのキャラクターあざとい話で、ウルトラマンXのツインテール前髪パッツンメガネっ娘ホットパンツニーハイソックス白衣理系女子のルイルイ並にレベル高いあざとい、みたいに言おうかなとか一瞬思ったけど自粛しました。気になる人は映画館へGo!
あとは、このネタに至る道程としては、Unreal Wayの「それぞれの人が自分だけで高速にイテレーションを回せる」「プログラマーが間に挟まると、その分だけイテレーションが減る」「計画・実行までのサイクルが速いScrumであっても、1週間は要求の変更をブロックするから、それだと遅いよね」みたいなのがあったんですが、それを説明しだすと動くものを紹介するまで長くなっちゃうので辞めました。
普段サーバっぽいコードは書かないので、その点はいろいろ話を聞いて参考になりそうでした。MQとかね。そのうちちょっとやりたいなぁと思っていたので。あと、HashiCorp製のプラグインの仕組み(別プロセスでRPCでやりとりする)というのは、同じような奴をやろうとしていました。僕の方で考えていたのは、Go/Qtの通信用で、QtにあるQLocalSocket/QLocalServer互換のソケット(Windowsは名前付きパイプ、それ以外ではUnixドメインソケット)をバックエンドに使い、その上にdRubyっぽいレイヤーの簡易版(参照渡しはサポートしない)を用意して、HTTPのウェブアプリのようなパス上にオブジェクトを配置してメソッドと引数を渡すという感じでやろうとしています。Goはreflectを使って、QtはQMetaObjectのリフレクションを使ってメソッド呼び出しができるので、言語が違っても相互にやりとりできる(部分の検証はすでに済み)。Go側の実装は一通りできていて、Qt側は現在実装中です。これもそのうち公開できるかと思います。それ以外だと、SensorBeeのコードのASTをいじくるコードはなんかそのうち書いてみたいですね。
イベント主催かつ会場提供のエウレカさん、どうもありがとうございます。また次回以降のイベントも楽しみにしていると同時に、金銭的余裕があれば(キッチン内蔵の食器洗い乾燥機と、Nexus 5が壊れたり)しなければ懇親会も参加したかったです。
ハッカソン界隈が非常に盛り上がっています。ハッカソンという言葉が一人歩きした結果だから「まあそういうことも起きますよね」としか思えないのですが、いいタイミングなので、4-5年ぐらい前から考えていたことをまとめてみます。
ハッカソンという名前がバズワードとして広まり、いろいろなイベントのタイトルとして使われています。ただ、本来使われてきたハッカソンとは意味が違ってきています。こちらにオフラインの勉強会のスタイルの分類をまとめているのですが、ハッカソンはどちらかというと開発合宿スタイル。集中的に何か動くものを作ってみよう、という形のイベントです。
@technohippyさんが良いリンクをTweetしていたのでこれも参考に貼っておきます。
原始ハッカソンの日本語原典はこれな https://t.co/vQigFMDVf2
— ANDO Yasushi (@technohippy) March 2, 2016
一方、企業協賛のものは商品や賞金が出るということもあって、優劣を決めるイベントです。これを明確に表している分類は「コンテスト」の方が適切かと思います(数年前の感覚では)。ただ、言葉の定義というのは、神から与えられた正しい意味みたいなのはなくて、人々が使っている中で、誤用とかも含めて定着していった結果です。オリジナルの由来のみを正しいと信奉して「送り狼」を褒め言葉で使ったらたぶん友達がいなくなります。送り狼にも諸説あるみたいですが。コンテスト相当のものを「ハッカソン」と呼ぶというのはこのまま定着しそうな気はします。
「コンテスト」であれば勝敗をつけるイベントというのが明確なので当然「レギュレーション」をどう定めるのか、その中でどうパフォーマンスを出すのか、というところに参加者や審査員の意識はフォーカスします。「ハッカソン」と呼んでしまうと、「クリエイティビティを発揮しよう」みたいな印象を与えがちで、あまりルールや縛りにフォーカスしようとはしなくなるんじゃないかと思います。そういうポジティブな印象を与えたい、という主催者側の意図が「ハッカソン」という言葉を使わせている気はしますが、それが逆にハッカー気質な人がハッカソンという言葉に対してネガティブな印象を持ったり、今回の関連記事等にかかれていたように、一部の参加者「技術を発揮しないのに違和感を感じる」という悲劇につながっているのかなと思います。
ハッカソンをゲームと例えるなら、準備フェーズでスキルを成長させて相手を殴りに行くMOBAとか、RTSに近いかもしれません。この手のゲームで「この設備を最初に作っちゃえば勝ちが確定」みたいなのがあると対戦は面白くないですよね。
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 |
