転職エントリーと退職エントリーは見かけるけど、途中の感想エントリーをみかけないので、つらつらと書き連ねたいと思います。だいたい1年4ヶ月ぐらい経って、一通り会社の雰囲気はわかって来たかなと。写真は五反田の西安飯荘の坦々刀削麺です。

• http://blog.shibu.jp/article/181834465.html#more

仕事はFutureVulsの開発をちょびっとお手伝いしたのと、あとは客先常駐です。うちの会社では客先常駐は基本的に少なくて、打ち合わせはお客様のところにいくけど開発は自社に持ち帰って行う、ということが多いので、レアケースのようですね。自社の方が席が広かったりもろもろ快適ではありますが・・・今のお客様のレベルは高くて、他のベンダーさんからきている人たちのレベルも高くて良い感じです。エリートが揃っている感じ！

B2Bなお仕事はどうなのか

お客様と直接お仕事をする一次受けでなおかつ開発まできちんとしている（下に投げない）B2Bな会社、なおかつ、お客様とお互いに信頼関係がないところの仕事は受けない、という姿勢が良いな、ということでフューチャーを受けて入社しましたが、実際、技術の話がきちんとできるメンバーも多くてとても居心地が良いです。 新しい案件を次々とこなすので、インフラ周りの担当になったら、AWSとかGCPのクラウド機能を駆使してインフラを構築していく経験値はかなりたまりそうです。

SIerは古いバージョンをずっと使い続けるとか、技術力が置いていかれるみたいなイメージを持っている（し、そういう話をするのをアイデンティティにしているSIer dis芸）人がいますが、最近はセキュリティもあるので、サポート期限を超えちゃったものを使うことは基本的にないんじゃないですかね。

最近のフロントの開発はAngularの最新LTSの6で使っています。この前までいたプロジェクトではNext.jsでサーバーサイドレンダリングとかもやりました。うちの他の案件でよく使われるのはVue.jsです。Next.jsはフロントでUIを仮想DOMで構築して、初回時はサーバー側でもHTMLを作るというフレームワークで、フロントが主、サーバーが従という感じですが、サーバーサイドレンダリングが行われて、2回目以降はブラウザ側でも高速化のために動作する、と見方を変えると、古き良きウェブアプリケーションと似たアーキテクチャになるので、Next.jsはサーバー側でテンプレートでHTMLを生成する古き良きフレームワークでの開発から移行してくるには逆に敷居が低いんじゃないかなって思いました。仮想DOMも、よくできたテンプレートと変わらないですしね。言語はES2018でやったり、今はAngularなのでTypeScriptですね。コード管理はみんなgitです。

サーバー側はNode.jsだったり、OpenJDK 11だったり、Goだったりを使っています。 SpringBootはなかなかやってみると良いものですね。

開発環境はdocker-composeで一発で上がるように整備したりしました。僕はやっていないですがK8sな人もいます。

今のところの新し目の技術スタックとか手を動かしてコードがんがん書いていくし、新しいものに触れるチャンスは多い気がします。

エンタープライズとウェブ系の大きな違いって、何かな、という話ですが、客先の人の言葉ですが「時間を扱う」というところですね。

機関系。DBトランザクションではどうにもならない時間（物理的に東京から大阪まで配送etc）を扱う必要があり、タスクをまとめて扱ったり、費用発生もタイミングまちまちで、掛とかもあって入金タイミングもばらばらで、月次や日次の締めもあって、キューとかバッチが活躍する、という感じぽい

— 渋川よしき (@shibu_jp) January 30, 2019

ウェブ系のバッチ処理、たいていはサムネイル作成のタスク、みたいなちょっと時間のかかる処理でワーカー数を節約するために時間方向に多重化する、ぐらいの使い方や、アクセス数が多すぎるとエラーになってしまう外部API呼び出しへの対応が多いと思います。決済が、外部のStripeのカードAPIを一発叩いたらOK！というのであればシンプルなのですが、掛だったりしますし、費用発生のタイミングが企業間で物が渡されるタイミングだったり、なんだったり。1トランザクションできれいに収まらないで、数日、数週間、数ヶ月に渡って行われる処理とかそういうのがあると。

Amazonがクロネコヤマトからデリバリープロバイダーになったタイミングで、ヨドバシに乗り換えた宣言をした人が僕のTLにけっこういたのですが、それはウェブサービスがどんなにクオリティが高くても、最終的な物理世界のインフラの信頼性をサービスの信頼性として感じている人がそれなりに多い、ということなんじゃないかと思います。で、その物理の世界を扱うにはエンタープライズな考えが必要と。どんなにかっちょいいウェブサービスも最後に世界に働きかけるには人の手が必要で、物が必要で、時間を扱う必要がある。その作法をしっかり学びたいですね。まだ関わっている仕事はフューチャーが関わっている分野からするとごく一部ですが、そういうガチなところにも触れていきたいです。

同期（ウェブ）と非同期（エンタープライズ）と考えると、二つの世界は非連続ではなくて、連続的なものに見えてきます。ウェブでもちょっと非同期な世界ってありますよね？機械学習の推論を走らせる部分だったり。 エンタープライズでも、今まで非同期でバッチを分けていた処理を、共有メモリ的に全員同時にコミットしていくみたいなシステム化ができるかもしれない。そういうチャレンジをするには良い環境なので、楽しんでいきたいですね。

今まではどちらかというと、デスクトップアプリだったり、ゲームだったり、フロントエンド周りだったりの前面の仕事ばかりで、サーバー側の仕事は経験値がまだ低いですが（概念はだいたい把握しているものの）、せっかくなのでインフラ周りも勉強中です。がんがん手を動かせるようになりたい。

予想外でよかったこと

うちは、コンサルタント方面も、アーキテクト方面とキャリアパスは選択肢がありますが、どちらにいくにしても基本的に新入社員は開発を学びます。なので、お客様とお話する人も技術がわかっていて、話をしていてインピーダンスミスマッチは感じないです。今何が起きているのか、というのを説明するときも、言葉の翻訳に気を使わないのでも、率直に話をすれば通じるのが気持ちが良いです。

会社を選ぶ基準として考えていたけど、転職エントリーでさらっとしか書いてなかったことが1つあって、新卒採用をきちんとしている会社にしたい、という気持ちがありました。前回のエントリーにも書いた、南場さんの「社会資本」という言葉ですが、これは不動産みたいなものだけではなくて、人もそうだなと思います。仕事ができるメンバーというのは、勝手にキノコとかサイバイマンのように生えるわけではなくて、本人も努力しつつ、先輩から働くための技能を教えてもらい、その結果働くスキルを身につけて、今一緒にいます。よく「自分は誰からも教えてもらってない」ということをTwitterで書いている人がいますが、そういう人も本やウェブの記事を読んだりしているわけで、それは間接的に教わっていることになります。ソフトウェアの人材はどこもかしこも人手不足ですが、転職エージェントに大金積んで人を集めている会社よりは、今までプログラミングをしていなかった人も含めて採用して、新人教育をきちんと行なって、ソフトウェア開発ができる人口を増やしている会社で、なおかつ子供を大学に通わせるぐらいのお給料をきちんといただける会社というのは、その社会資本を強くしていくための貢献を果たしている会社と言えます。

フューチャーはその新卒採用をきちんと回している会社です。一緒に仕事した若いメンバーはみなとても優秀で、若手のスキルアップに貢献できたのはとても楽しかったです。

情熱プログラマーの「一番の下手くそでいよう」という考え方は僕は好きじゃないです。今時はインターネットでいろいろな強い人とは繋がれるので、自分を引き上げてくれる人はいくらでも供給できますよね。そのためにわざわざ組織を変える必要はないなって思っています。どちらかというと、成長に貢献してレベルアップをさせてあげる立場でありたいと思います。自分の能力の限界のせいで、若いメンバーの限界が低くなってしまうのは申し訳ないので、自分も全力でスキルアップは引き続きやっていきます。一緒に仕事したメンバーが「一緒に仕事できてよかった」という思いがあります。実際そういう感想をいっぱいもらえて、一年めの貢献としては十分に果たせたかな、と思います。

本を書くとか、外部の勉強会での発表は申請を出せばすぐOKが出ます。もっといろいろ厳しいのかなと思っていましたが、NGが出たことはないですね。「申請が必要なのかよ」という人がいるかもしれませんが、それは大抵のウェブ系の会社もそうですよね。DeNAもそうでしたので、差はないですね。あと、Node学園祭のスポンサー依頼が来たのですがどうですかね？と聞いてみたらOKもらえてロゴを出すことができました。JAWSの方も出るみたいですね。お客様との契約次第ですが、純粋な技術ネタならOKということで、たまに仕事で学んだことをQiitaに書いたりもしています。社内イントラに書くよりも検索でひっかかる方が便利ですよね。

https://nodefest.jp/2018/sponsors.html

OSSもいくつか公開していたりコミットしているメンバーもいます。あとは、OSS系とコミュニティが違ってあまり認知していなかったのですが、競技プログラミングの世界は面白いですね。日々の本の執筆とか週末は家族の時間なのでがっつり取り組むとかは今すぐはできないのですが、参加してみたいですね。競技プログラミングで活躍していた人が入社して、既存のシステムを爆速にしたとか。かっこいいですね。

今後取り組みたいこと

Twitterで見かけるプログラマー界隈では、プログラミング言語としての「JavaScript」は、まるで腫れ物のように言う人はまだまだいます。アメリカに数年いてみて、あのあたりの人たちはみんなJavaScript大好きです。フロントも、サーバーも、データベースも、バッチ処理も（AWS Lambdaとか）、モバイル、アプリケーションのマクロも、JavaScriptで全部やりたい、ずっと書いていたいという気持ちを強く持っている人たちが多い。20年前のJavaで全部やりたいとかそういうのと同じ盛り上がりを感じました。良くも悪くも我々はあのあたりの人たちの成果物を我々が使うことが多いので、JavaScriptはまだまだ広がっていくことが考えられます。

そうなると、ここしばらくの間は、JavaScriptが得意なほど学習の高速道路にのって見える世界が一気に広がります。フューチャーは全コンサルタントにAI教育を行う取り組みをしていますが、全コンサルタントに教養としてES2019とかの新しいJavaScript（TypeScript）を学べる機会とか教育コンテンツが提供できたらなぁ、と思っています。

自社サービスの開発もしていこう、という話もあるので、前職でゲーム開発のプロセスにいろいろ携わっていて、そこでやりきれなかった（提案したけど通らなかった）例のシステム開発はしたいなぁと思っています。あとは、ゲームの業界が他のウェブやらエンタープライズよりも先進的に進んでいる技術をB2B開発に輸入というのもやりたいですね。

やりたいことは多いけど人手が足りないので、一緒に暴れてやるぜ、という人がいたら連絡ください。外に発表できるのはIRが出ている事例ばっかりですが、基本的に国内の有名な誰しもが知っていそうな会社の案件が多いです。年末のベストプロジェクトを決めるプレゼン大会の資料とか見たら、きっと10人中5人ぐらいはフューチャーに興味を持ってもらえると思うのに、見せられないのは残念なのです。B2B2Cみたいな案件も多いので、世の中に出ていくものを作りたい、と思っているB2C志向な人にも悪くないと思います。アルバイトも募集あります。

あ、この前の業績はとても良かったです。昨年末は前者イベントがハワイでした。

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はgit以外にも対応している旨を紹介
  • golang-jp.orgをgolang.orgに
  • GogLandがGoLandになってベータでなくなったので記述を修正
  • Delveのmacのインストール方法が変わったので説明を修正
  • デバッガを実行してもconvT2E()の中に飛ばなくなったので記述を削除
  • 〓Go 1.8とPrintlnの中のコードが変わったので修正
• io.Writer
  • Go 1.10で追加されたstrings.Builderを追加
  • io.Writer/io.Reader向けインタフェースを提供した方が良い設計である説明を追加
• チャネル
  • GoのプログラミングモデルがCommunicating Sequential Processesである説明を追加
• システムコール
  • macの取り扱いが変わったことを追加
  • 〓DPDK/gVisorの紹介を追加
• ファイルシステム
  • 〓論理ボリュームマネージャについての説明を追加
  • 〓ファイルモードについての説明を追加
  • ホームディレクトリの追加でGo 1.12のos.UserHomeDir()について言及
• ファイルシステム2
  • select属のサンプルとしてevioを紹介
• TCP
  • Pythonのドキュメント日本語訳のURLが本家にマージされた変更を反映
• UDP
  • UDP/TCPの説明を読みやすく修正
  • QUICについての紹介を追加
  • UDPのサンプルとして、NTP、peerdiscoveryについて紹介
  • HTTP over QUICをHTTP/3に修正
• Unixドメインソケット
  • 〓Windows 2018 April UpdateのAF_UNIX対応について説明を追加
• プロセス
  • Go 1.8で追加されたos.Executable()について追記
  • BusyBoxについて紹介
  • 作業フォルダは1つのプロセスあたり1つしか持てない旨を追加
  • 環境変数の説明を少し増量
  • 1.12で追加されるos.ProcessStateのExitCode()メソッドについて追加
  • 1.9からはLinuxではfork()/exec()ではなくて、clone()を使って高速化した話を追加
  • InstagramがコミットしたPython 3.7のコピー・オン・ライト時のメモリ効率改善について紹介
• メモリ
  • Go 1.12のメモリ管理の変更について少し追記
  • 動的メモリ圧縮の例にWindows 10 November UpdateやLinuxのzswapも追加
  • GoのGCが1.8から1.11までの間に大幅に改善されたので停止時間の数値を更新
  • 〓実行ファイルフォーマットと、アプリケーションのメモリ配置のついての項目を追加
  • 〓アドレス空間配置のランダム化についての説明を追加
  • 〓実行ファイルにアセットをバンドルする手法について紹介
• 並列処理
  • goroutineがなぜ早くて軽いのかの説明を追加
  • goroutineがOSスレッドよりも劣る点の説明を追加
  • sync/atomicパッケージの紹介に「コンペア・アンド・スワップ」というカテゴリ名の紹介を追加
  • 〓sync/atomicを使ってアウトオブオーダーでも読み書き順序を守るコーディング方法について紹介
• コンテナ
  • IBMのRedhat買収にともない、rktの開発が非注力になったので説明を削除
• セキュリティ
  • CPUセキュリティフィーチャーのリンクを紹介
• 参考書籍
  • ［試して理解］Linuxのしくみが良い本だったので追加
  • 『Go言語による並行処理』が良い本だったので追加
• 終わりに
  • 新たにレビューに参加してくださった山口さん、cocoatomoさん、progrhymeさんのお名前を追加

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大攻勢により、今はもう新しいプレイヤーが登場することはかなり難しい、という状況になっています。

工数と、システムの規模のアンバランスは、システムを作りきったあとにも問題として発生します。 昔書いたブログエントリーでは、ドメイン知識の分量がが現場のユーザーの理解できる量よりも大きくなってしまい、システムエンジニア側にドメイン知識が移動してしまう話を書きました。

• SIerの未来は明るい？

少ない人数で手作りでイノベーションというのは、早急に工数の増加とともに、何らかのタイミングで損益分岐点を超え、企業の手を離れ、 競争の中でいつしかコモディティ化していく・・・多くの人が考えるイノベーションの形というのは、長いライフサイクルのほんの最初の一瞬だけなんだろうな、 というのを、前々職を辞めたブログエントリーを見て思いました。

自分がそのどこで技術の発展に関われるのか。常に0から1を生み出せる人は先頭にい続けられると思いますが、そうでない人は、早晩川下の方に流されていくんだろうな、と思っています。それでも、どこかしらのイノベーションのライフサイクルに、少しでも長く関わり続けられればいいなぁ、と思っています。

明日はbuchoです。抱腹絶倒かつお涙頂戴で感動の嵐間違いなしです。みんな超期待して待っていてください！

少し前に、レビューに参加したGo言語による並行処理が出版されました。献本もいただきました。ありがとうございました。レビューする前から、かなり読みやすい翻訳となっており、3章分レビューして欲しいと、作業分担はあったのですが、おもしろくて全部読んでしまいました。より詳しい本書の内容はmattnさんのブログが詳しいので、そちらを読んでいただくのが良いと思います。

謝辞にも書いていただいたのですが、僕もGoならわかるシステムプログラミングで並行とか並列とか書いたことがあったので、注釈として原著の内容を補足して増やしてもらう方向のコメントを少ししたりしました。Goでの並行処理を学ぶには最上の一冊としてあって欲しいですからね。僕の本はどちらかというと、「Goを学ぶ」よりも「Goで学ぶ」志向ですし。また、翻訳の指摘というよりかは「きっと著者が本来言いたかったことはこうだ」と、原文で気になったところとかも多少コメントしました。

僕のレビューの貢献はごく一部ですが、ymotongpooの献身的なコミットメントや、多くの人達のすばらしい指摘により、英語ができる人が英語で原文を読むよりも、遥かにすばらしい翻訳になっています。最新の1.11での結果以外にも、いくつも日本語オリジナルのコラムがあります。英語版を買った人も、ぜひ日本語版を手にとって見てください。

context

本書でも、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を書いて雑な実装でまずはパスして、あとで戻ってきて修正しましょう」ということが書かれています。こういう設計の分解方法はボトムアップじゃなかなか到達できなくて、熟練の業なんだろうなって思います。かつてコンパイラやインタプリタの本を読んだことがある人にも、目からウロコだと思います。僕はウロコがいっぱい落ちました。

言語を作りたい以外の人にもおすすめ

比較的短い分量で、スモールステップで開発していく手順で説明は進みますが、言語の要素としては基礎的な、lexerでトークンに分けて、parserでASTを作り、evaluatorで実行する、という王道な構造になっています。本書はインタプリタを作る本ですが、これらの技術要素というのは処理系を作る以外にもいくらでも応用例があります。

例えば、字句解析だけは他のものを利用しつつ、そのさきの部分は自作する、みたいなことも可能です。evaluatorの代わりに、情報を出力する変換器をくっつける（本書のInspect()の応用みたいな）ことも可能です。

例えば、ちょっとしたテキストのパースとか、データの解析にも応用できます。JSONやTOMLのようなオリジナルのデータ・フォーマットを作る、みたいなこともできるでしょう。本書でもちょっびっと触れられていますが、JavaScript界隈の最近の発展もJS自身のパーサがJSで作られたことからカンブリア爆発が起きているのでは、と僕は思っています。jslintのフォーマッター、minify、concatツール、prettierのようなコードフォーマッター、babelのようなトランスパイラまで、すべてはこれらの技術要素が少なからず貢献しています。

このように、本書を読んで身につく技術というのは、身につければ今まで自動化が難しかったようなものをガンガン自動化していくための武器になります。夢が広がりますね！

Goは擬似言語としても有用というのは本当だろうか？

昔僕が読んだ本はparser部分はC言語を生成する特定のパーサジェネレータを前提としていたため、他の言語で実装するにはどこを参考にすればいいのか難しい、ということがありましたが、この本が良いのは標準ライブラリだけを使っていて、なおかつコードジェネレータを使わない（昔はgo tool yacc添付されてた）説明になっています。そのため、ここで学んだことを他の言語で応用するのは比較的やりやすいと言えます。

Goが勉強できてインタプリタも作れて最高じゃん、と思って買った「Go言語で作るインタプリタ」だけど、Goについては「Go言語はわかりやすい言語だから知らなくても雰囲気で読めるよ」だけで済ませててなかなかロックだなと思った

— ANDO Yasushi (@technohippy) July 13, 2018

とはいえ、上記のような感想を持たれる方も多いでしょう。僕もReal World HTTPやGoならわかるシステムプログラミングでは、「Goはシンプルな言語なので、動く擬似言語として他の言語のユーザーでも難しくないよ」ということを書いたことがあります。

自分の書いた本では証明にならないと思うので、せっかくの機会なので、Python 3.7で3章まで実装してみました。Pythonは一番書いていたのは2.5とか2.6の時代で、その後は2.xと3.xの両対応のコード、みたいな実装ばかりしていました。Python 3で増えた機能を積極的に使ってみるということで、漸進的型付けにチャレンジしてみました。ついでに、環境構築の仕方もQiitaにアップしています。

• https://github.com/shibukawa/interpreter-in-python
• Python 3.7とVisual Studio Codeで型チェックが捗る内作Pythonアプリケーション開発環境の構築

実際にやってみると、言語ごとの違いが致命的になることはありませんでした。Goにしかない文法要素とかもあまりないですしね。ただ、やってみて気になったのが、Goのinterfaceが、他の言語でいうnullableが自動でつく、という点ですね。全部にnullになる可能性があることを明記していくか（Pythonのmypyだと、Optionalをつける）、NullObjectを作るか・・・僕の実装は後者にしています。あとは、astパッケージのサンプルの、プライベートなstatementNode()関数を使ったインタフェース指定も他の言語ではみないやり方なので、明示的にインタフェースを実装する宣言が必要になるでしょう。

あと、Pythonならでは、というのだと、インタプリタ言語で上から実行しつつ型を作っていくため、前方参照ができない、というのが一つあります。あとは歴史的経緯で、Python 2.3まではbool型がなく、0/1の数値を使っていたため、isinstance(True, int)が真になってしまう。このあたりは宣言の順番だったり、比較の順番をちょっと修正する必要があります。Environmentでは親の環境を属性で持つので自分自身の型を属性で持ちますが、Pythonとmypyはメンバーの評価を先に行ってからクラスができあがるため、そのまま書くと未定義のエラーになります。属性の方は文字列で"Environment"と書いておけば大丈夫、と@methaneさんからアドバイスもらいました。

ちなみに、Rustでやられている方もいますね！

Goのサンプルコードは少し改善の余地あるものの、良い本です

一部、サンプルコードの書き方は気になるところがありました。もし自分がレビューアだったら（翻訳ではなくて原文に対してですが）指摘していただろうなという点は以下の通りです。

• iotaの定数の最初の値を_で読み捨てているけど、これなくても良い気が。初期値が0であると壊れるようなコードもないので。
• 配列（というよりもスライス）は、nilであれば長さゼロのスライスとして扱われるので、わざわざ初期値を与えなくてもいいのでは。
• Goで推奨されているテーブルテストが多様されているのは良い傾向だけど、ループごとにt.Run()を呼ぶとエラーがわかりやすくなってさらに良いです。PythonにもsubTestというのがあります。
• エラーと評価結果を同じreturnで返しているのはどうなんだろうか？多値返却できるし、エラーは混ぜないほうが良いような

まあ、すごく細かい内容なので、大勢には影響はないです。とても夢が広がる内容でよかったです。今まではC言語だったり、関数型言語だったり、特定のパーサジェネレータをターゲットにしていた本が多かったジャンルで、Goで実用的な言語が作れる本というのは貴重です。僕の二冊の本（HTTP、システムプログラミング）に続いて、日本で「Goで学べる」シリーズの三冊目といえるでしょう。

原著者の次の本はバイトコードを使ったコンパイラの本ですね。こちらもそのうち出てくるんでしょうか？楽しみです。

オデッセイハイブリッド

今年、オデッセイハイブリッドを買いました。

シビックも良い車でしたが、子供三人の自転車をつもうとするとスペース的に無理なので、買い替えました。今度買い換えるときもハイブリッドにしよう、と思っていたのと、自動ブレーキは付けたいな、と思っていました。あと、２列目がベンチシートじゃないと、子供一人が三列目、ということになってしまうので、ベンチシートは最低限。ホンダだと３列シートの車は、フリードハイブリッド、ジェイドハイブリッド、ステップワゴンハイブリッド、オデッセイハイブリッドの４つあります。このうち、ステップワゴンはスパーダ仕様しかないので２列目はキャプテンシート。ジェイドも同様なので、この２車種は選択肢から外れます（ステップワゴンは契約直前に気づいてやめた）。フリードは三列目を使わない時にスペース効率が悪いので、オデッセイになりました。

自動運転は完全に自動というわけではなく、「この条件ならいける！」というのを判定して有効化してやる必要はありますが、めちゃ便利です。自動運転と一口にいっても、機能としては自動ブレーキ＆前車追従自動アクセル、高速道路限定だけど自動ハンドル、の３つです。自動ブレーキは試したことないですが、本当に楽です。もちろん、一般道の微妙なケースで「もっと早くアクセル踏んで欲しい」とか思ったりはありますが、高速道路はすごく楽です。今は状況判断は人間がやりつつ、システムの癖を把握してボタンを押すので、それなりに熟練を要する装備です。

購入前はわからなかったこととしては、自動追従モードの設定可能な最高速度は135km/hです。もちろん、前車がその速度を出さないと出ないのですが、将来、新東名が120km/hになっても利用可能です。

自動運転以外にも、音が静かだし、音楽めちゃ聞けるし、重量1.5倍になったのに燃費変わらないし、ホンダでミニバンの最高級車種なだけあって内外装もしっかりしているし、ライトとか駐車時のサイドミラー操作とかいろんなものが自動だし、すごく良いです。

• ローンについて

インラインスケートのフレーム

いま仲間内で話題のAliExpressでインラインスケートのフレームを買いました。

1輪と4輪目が数mm持ち上がっていて、直進性は劣るけど、旋回性に優れる「ロッカリング」フレームというやつです。色は虹色プラズマ加工。あまり期待していなかったけど、以前使っていたSEBAフレーム以上の剛性感で、ロッカリング。とても安定して滑れます。やすいし、チーム全員で色を揃えるとかも不可能ではありません。

光るウィール

これも話題のAliExpressで買ったウィールです。光ります。子供が大会でがんばったご褒美に買いました。子供のやる気に20%ぐらいプラスになったので、安くて良い買い物でした。子供の習い事・お稽古ごとというか趣味はモチベーションが15割。

SHOW BY ROCK!!のサントラ各種

チートアイテムです。これ聴いていると、ジムの30分の有酸素運動が5分に感じます。心拍数の負荷をかなり高めても辛くなくなります。なお、効果には個人差があります。

子供の恐竜ヘルメット

どこに行っても目立ちます。安全装備ってつけるのを嫌がる事が多く、それゆえにリスクを増大させることが多いのですが、喜んで付けてくれるという点もすばらしいです。次女のスケート開始で赤を買いましたが、長女用に緑を買い増しました。

アオキの洗えるスーツ、ノンアイロンワイシャツ

転職を機に、スーツ生活をはじめました。スーツは選ばなくて良いのが楽です。入社の数日前にアオキに駆け込んで、いろいろ相談に乗っていただいて、本当に洗えるスーツを買いました。セットで、ノーアイロンワイシャツもセットで。アイロンがけもいらないというのはすごく楽です。いつでもきれいでシャキッとしたシャツが着れる。いろんな柄のものが出てきたので、来年に追加で買い足したいです。

エアリズムとジオライト

転職はまだ暑い9月だったので、少しでも涼しくなるようにユニクロのエアリズムの肌着を買いましたが、とても快適でした。冬はヒートテックでも良かったのですが、まわりで評判が良かったモンベルのジオライトにしました。温かいけど汗を書いても快適という肌着です。外は寒くても、ビル内は暑かったりとか、通勤ラッシュの電車が暑かったりするので、どんな環境でも快適なのは助かりますね。

オリエントの時計

スーツ生活になったので、腕時計を買いました。フォッシルのスマートウォッチとどちらにしようか悩みましたが、スマートじゃない方にしました。金属バンドのだとなんか気になってしまってしまって付けなくなっちゃうというのが何度かありましたが、この革バンドは違和感なく付けられています。そんなに重くないし。

ニンテンドークラシックミニ スーパーファミコン

子供の最初のビデオゲームとして買いました。マリオカートを少しずつ。やってます。

HUAWEI P9 Lite

お金はかけたくないけど、きちんとアップデートしてくれる無難なAndroid端末、というニーズを確実に果たしてくれる端末です。Android Oneが特定キャリアだったり、Nexus/Pixelがなくなったので、仕方なく、という感じの後ろ向きを全力でカバーしてくれるので良いです。ストレージは32GBないと、OSアップデートがストレージ開けがめんどいですね。

どうぶつしょうぎ

ファミコンミニは買ったけど、ふだんはあまりやっておらず、基本的にはトランプ、ウノ、どうぶつしょうぎとかのアナログゲームをやるようにしています。うまーく相手に満足を与えた感じで負けるのはテクニックが必要ですね。

Google Home mini

夢が広がるデバイスです。E17対応の小型のスマートLEDバルブが出たら、家中の電球を取り替えたいぐらい。子どもたちも喜んで「おーけーぐーぐる、ショウバイロックのおんがくながして」とか言っています。

これはPySpaアドベントカレンダー2017のエントリーです。

三年前に家、今月は車とローンをガシガシ組んだりしたのですが、お金を借りるということについて、まだまだ否定的な人がいたりするので、借りるということはどういうことなのかまとめてみます。 お金についての教育は日本にはないので、将来、子どもたちにお金について説明するための考えの整理でもあります。

特に、今は働き方改革という名の下に副業もできるようになってきました。去年ぐらいから自動車ローンも繰り上げ返済が可能になりましたし、残価設定ローンとの組み合わせで戦略の幅が広がったので、定期的に入る収入を当てにしたローンとくらべて、副業する人に優しくなっています。このあたりはお金を借りたことがある人も、そうじゃない人にも参考になるかなと思います。

お金を借りる==時間を買う

日本だと「お金を借りる」ことを蛇蝎のように嫌がる人、恐怖を覚える人が数多くいます。そもそも何のためにお金を借りるんでしょうか。 お金を借りると当然利子が発生します。現金をがっと貯めてから購入すれば利子の分お得です。お金を借りると損です。それでも借りるのは、時間を前倒しするためです。30年ローンで家を買わずに、お金が貯まるまで待ってから買うとすると、家を手に入れるころにはもう爺さん婆さんになっているでしょう（買うまでの賃貸も別にかかります）。ファミリーカーを買う頃には子供が独立して旅行にいくことはなかった、となるかもしれません。なるべく若い内に手に入れて、それを存分に楽しむというのがお金を借りる理由といえます。つまり、お金を払うのは時間を買うということになります。

長期間使うものであれば、借りて自分のものにすることでお金を節約するというのもあります。

例えば、うちでは毎週土曜、日曜はたいてい車ででかけますし、平日も子供の病院などでよく運転します。この前売ったシビックは10年で9万キロ弱です。この期間と距離走るのであれば、レンタカーにせよ、カーシェアにせよ、タクシーにせよ、買ってしまった方が安いですし、貸し借りの手続きや待つ時間も節約できます。

家を借りるのと買うのとどちらが得かという話はよく出てきますが、短期的に見れば買ってしまったほうが得なはずです。特に、数が少なくて流動性の低いファミリータイプの新し目の物件だと、賃貸と購入で月々の金額が２倍、もしくは面積が半分というのが東京圏では平均的な差でしょう。借りる金額には、修繕の予備費やら固定資産税（自分で住まないと高い）とかも上乗せされる上に、数%の不動産投資利回り等も載ってきます。貸し出す方も商売ですからね。うちは駅からは少しありますが、23区で上モノ80平米ちょっとで、土地も同じぐらいの駐車場付き一軒家で、ローン支払いは9万円台です。

大事なのは返済できること

お金を借りる、という行為にも種類がたくさんあります。それによって利率が大きく異なります

• 目的を決めて借りる。返す見込みがあるものを借りる == 利率が低い
• 目的が不特定 or/and 返す見込みの確認が少なく簡単に借りる == 利率が高い

これ以外にもベンチャーのファンド的なものとかもありますが、本稿ではそこは省略します。もちろん、これにとどまらずたくさん種類があります。

目的を決めて、なおかつ審査など返す見込みを確認するのが住宅ローンや自動車ローンなどです。住宅ローンは0.7%、自動車は1.9%とかでしょうか。2つ目はクレジットカードの分割やリボ払い、クレジットカードを使ったキャッシング（お金を借りる）、消費者金融などで、利率は15%とかにもなります。大きいですね。３番目のは僕は詳しくないので、省略します。

銀行などはお金を貸して利子をもらう商売です。返せない客にお金を貸すと銀行も損をしてしまうので、高リスクな分、利率があがります。 住宅や自動車の金額が大きなローンだと、支払い能力があるかどうかのチェックがあり、リスクのチェックを事前に行うためにその分利率が低くなっています。 なお、リスクチェックは所属会社とかで決まることも多いので、いくら年収が大きくても自営業だと審査が通らないことも数多くあります。 残酷ですが、大きな会社の所属して、転職前にローンを組むという話はそこから来ています。

クレジットカードも分割をせずに期日に間に合わせて支払えば利子はかかりませんが、その期日を過ぎれば「お金を借りている扱い」となって利子が発生します。分割払いやリボ払いがそうですね。クレジットカード会社は、クレジット払いの時の一定割合を手数料としますが、この利子も収益源です。リボ払いにすると年会費が安くなりますという案内がよく来ますよね。顧客獲得コスト（安くなる年会費）以上に収益が見込めるということでしょう。

基本的には短期間で返し切る前提でなければ借りない方が懸命でしょう。クレジットカードのキャッシングも、僕はやったことはないですが、海外で現金を下ろすときには便利（ただし、日本に帰ったら速攻で返すこと）とのことです。

大事な原則は「借りたら返す」ということです。クレジットカードも、クレジットのキャッシングも打ち出の小槌ではなくて、将来返さないといけないもの（返さないと利子が発生し続ける）ものです。返す見込みがないものは借りてはいけませんし、見込みがない支払いというのはたいてい、利率が極端に大きいものばかりのはずです。支払い能力を利子が超過すると、「払い過ぎた分を取り返す」みたいな広告が去年ぐらいはたくさんありましたが、払いすぎてない分 == 法定金利は当然支払わなければなりませんし、それも利率としてはかなりの額になります。

知人から聞いた嘘みたいなカード破産の話としては、リボ払いをして、その支払をクレジットカードのキャッシングを使って払う、というものがありました。 やばいですよね。鳥肌が立ちますよね。このヤバさが分からない人はこのエントリーを読んだとしてもお金を借りる系のものには手を出してはいけないです。

繰り上げ返済とローン戦略

さて、ようやく書きたかったところに来ました。

お金を借りると利子が発生するので、利子を減らすには借りる額と期間を減らすのが基本戦略になります。具体的には頭金をたくさんぶっこんで支払い能力のあるかぎり月々の支払いを増やす、ということになります。

しかし、頭金を大量につっこむと、手元資金がなくなるため、突発的な出費で身動きが取りにくくなります。月々の支払いを増やすのもそうですね。やばいですよね。家だと数十年のローンになりますので、その間にライフスタイルは大きく変わってきます。結婚。出産。子供の教育費用。同じ会社で年功で収入があがるなら話は早いのですが、そういう時代でもなくなってきていますし、育休の場合はその期間年収が減ります。老後の積立も自分でやらないといけない時代ですので、その出費も考えないといけません。

このあたりは去年と今年のPySpaアドベントカレンダーに色々話があります。僕もジブラルタ生命の営業の人に分析とかしてもらいましたし、フィナンシャルプランナーがPySpaでブームです。客観的に分析してもらうと良いです。うちはローンを組んだ後でしたが。

• passiveな#kaneの話
• 私とお金の話
• 資産運用に取り組み始めた

ライフスタイルというお話だと、ローンの支払いとは関係ないけど、次のエントリーもおすすめです。

• 成年後見制度の話
• Goならわかる相続放棄

ローンは決まった額を常に払っていきますが、基本の作戦としては、なるべく支払い期間を延ばして、月々の支払いを減らすということになります。で、余裕のあるときには、繰り上げ返済で払っていきます。支払額を一時的に増やすことはできても一時的に減らすことはできないという下方硬直性があるので、それ以外の作戦はないでしょう。去年あたりから、自動車でも繰り上げ返済できるようになりました。なので、副業収入を当てにしないで破綻しないようになるべく薄く払うローンにしておいて、副業収入が入ったらガンガン返す、というのが可能になりました。特に僕の場合は書籍の印税でしたので、「月収」「ボーナス」という枠に入れづらく、総額でいくら入るかといった話があっても、ローンに組み込みにくいというのがありました。せいぜい、ある程度まとまってから頭金に入れる以外はありませんでした。みなさん、安心して本を書きましょう。

• pyspa books（概念）についてのまとめ 2017年版

家の場合は団信にたいてい入るので、ずばっと死んでしまえばローンはチャラになって資産として家族に残るので心配はありませんが、中途半端に病気とか怪我で働けなくなるのが一番ダメージが大きいです。うちは収入保証の生命保険とかも組み合わせています。利率はかなり高くなりますが三大疾病、八大疾病でチャラになるというローンのオプションもありますね。去年も紹介しましたが、必要かどうかはDeNAの提供している遺伝子検査のMyCodeとかも参考になります。

残価設定ローン

とりあえず、時期は伸ばせるだけ伸ばすということで、変数は頭金だけになりました。頭金に対しても作戦がいくつかあります。

住宅ローンだと、一部の銀行（新生銀行？）が、銀行口座に入っている金額の分は利子が発生しないという住宅ローンを提供しています。現金がたくさんある人には良いと思います。

自動車だと残価設定ローンというものがあります。これは、3年とか5年後に決まった額（3年後だと半額、5年後だと1/3）を払って乗り続けるか、次の車を買うかが選べるというローンですが、見方を変えれば、その決まった額の分、頭金を後払いにしているといえます。オデッセイハイブリッドのローンをこの前組みましたが、320万ぐらい借りて、ボーナスは15万、月々は14000円で、最終支払は111万円です。転職したばかりでまだ今月はボーナスすくないという時期で、頭金も払えないこともないのですが、まあ色々出費もある時期ですし、とりあえず手元に残す作戦で残価設定ローンにしました。来年以降がっと返す予定ではあります。

ホンダのお店の案内によると、残価設定ローン利用者は2/3ぐらいにも上るとのこと。期間が長くなりがちということもありそうですが、利率も低めで積極的に勧めているようです。

住宅ローンは低金利だからこれを借りっぱなしで別のものにお金を使うというのは正しいのか

利率だけみれば住宅ローンは自動車の1/3ぐらいではありますが、実際計算してみるとやはり金額が大きな分、住宅ローンの利子の総額は大きいです。

繰り上げ返済をどちらを先に払うかというと、100万円に対して、住宅ローンだと30年後の100万円を先行して支払う==100万x30年x利率の分の利子を支払わなくて済みます（うちは元金均等なので、元利均等だとちょっと違うかも）。20万円ぐらいにはなります。自動車ローンだと、そもそもの利子分の総額が20万円なので、繰り上げ返済してもリターンはそんなになかったりします。住宅ローン減税を考えると最初10年はあまり返さない方がいい、みたいに言う人もいますが、利子総額を考えるとそんなことなくて、最初からガンガン返せるなら返しちゃった方が計算すると得です。

まとめ

セダンのシビックハイブリッドで、トランクはベビーカーでいっぱいで、子供三人をリアシートにチャイルドシートで並べて、後部座席の足元に長女の自転車を入れて無理やり公園にいく、みたいな生活でしたがスペースに余裕が出てきて、次女と三女も子供用自転車が必要になっても運べるようになりました。子供のチャレンジと成長に車がボトルネックになりそうだったのが解消されました。

お金を借りる時は計画的に。いざとなれば売ってしまう（チャラにする）というオプションもありますし計算すれば怖いものじゃないです。最初のフィットのローンを組む時はドキドキしましたけど、今回はまったくそのようなこともなく「あ、月々15000円以下でいけるならもっと早く買い替えれば良かった」と思ったぐらい。

ライフスタイルの変化に対応できる柔軟性を考慮することで、若いうちに大きな買い物ができます。年齢が上がると体力も落ちてくるので、子どもたちと思い出をたくさん作る上でも、うまくローンを活用していくと良いです。

ミスタービッグデータこと、しましうまちから異文化理解力という本を紹介してもらいました（しうまちは確か@d1ce_から教わったと言ってた気がします）。アマゾンのレビューの圧倒的な評価を見れば分かるように、とてもすばらしい本です。著者が数十年にわたって仕事で活動してきた内容の集大成であり、多くの国々の人々に対する調査の結果がこれでもか、と盛り込まれた本です。下調べの圧倒的な量からして、この本を書ける人はほとんどいない、というカテゴリーの本です。

この本は、国際的なチームの仕事のトラブルの原因として、受け手が期待するものと、話し手が期待する価値観の違いがあるとして、８つの領域に分けて詳しく説明しています。普通に読んでもとてもおもしろく、「ああそうだよね」と思うところもたくさんありました。ただ、この本を文字通りではなく、応用的に読むこともできます。本エントリーでは2つの視点を紹介します。

ちなみに、アマゾンのKindleの方には書籍紹介として、（なぜか）本を貶めるような説明（おそらくレビュー記事のタイトルで本文を読まないと真意は分かりません）もありますが、そんなことはありません。

• 「残念ながら、日本人の8割にこのビジネス書はいらない。」 HONZ書評掲載で話題沸騰! (10/7、佐藤瑛人さん)
• 「ビジネスで英語を必要とする人々は、この知識こそ必要だ。」 成毛眞さん(HONZ代表)推薦!

日本国内のカルチャーギャップについて考察するための武器

本書では、国ごとの考え方の違いを、カルチャーマップという絵を出しながら紹介しています。何かの発言をするときに、どのようなスタンスで言葉を選ぶか、直接的な言葉を使うのか、間接的な言葉を使うのかといった感じです。ビジネス上よくある8つの場面ごとに、1次元にきれいにマッピングされた分類になっています。

本書の中でも「集団同士のあくまでも相対的なもの」「集団の中でも差がある」ということは強調されています。まさに現在の日本の状況は、この本で触れられている状況が国内で発生しています。よくTwitterで回ってくる、算数の掛け算の順序の問題がそうですね。日本はもともと、明治維新のころ、学問の文化吸収ではヨーロッパ圏をお手本にしていました。掛け算問題はたいてい「習ってなくても正解なら減点すべきでない」という文脈でTwitterが回ってきますが、本書によると、フランスとかも「習ったことによる説明以外はバツにされる」と紹介されていました。どこかで見た話ですね。

一方、ビジネス書の世界でもコンピューターでも、最近は新しい考え方、製品はアメリカからもたらされることが多いです。アメリカは「古い日本」に対して新しい文化や考えをもたらす国、という位置づけです。本書で言えば、ヨーロッパ的な演繹的な考え方で作られたカリキュラムに対し、アメリカ式のプラグマティックな思想との文化衝突といえるでしょう。今まで目の前にあった問題が、別の視点で見えてきますよね。これに限らず、日本人は「積み上げ型の価値観をまったく別の価値観を持ってきて破壊する」みたいな物語が好きですよね。

もちろん、ドイツを見れば分かるように、演繹的な考えも間違っているわけではなく、きちんと運用されることによって成功はできます。アメリカもそうです。どちらも間違っているわけではありません。ちなみに、知人に教員がいる方は当然ご存知だと思いますが、現在の教員は多種多様なタスクを抱えて労働時間が極めて長い状況にあります。紋切り型でバサバサやっていかないとそもそも回らない、というところが元凶な気がします。そういう状況であれば、掛け算に順序に対して物申しても「クレーマーがきた」としか対応できないと思うので、こういう事情も含めて親が子供に教えてあげるしかないんだろうな、という気がしています。

また、Twitterでよく見られる「欧米では◯◯なのに、日本では◯◯」というテンプレートも、欧と米が結構違う価値観にあるという説明を何度も読んだ後に見かけると「ふふっ、坊やなのね」という気持ちになれます。

書籍を書く人のための武器

国によって、伝えたいこと（情報、褒めるというポジティブ・フィードバック、叱るというネガティブ・フィードバック）が違う、というのが本書の主張ですが、では実際、本書はそれをどうやって読者に伝えているんでしょうか？

1. コミュニケーションで失敗した事例
2. コミュニケーションスタイルの違いの概要
3. 文化論のセミナーであった、コミュニケーションスタイルの違いを見せつけるできごと
4. コンテキストという概念の紹介
5. アメリカで子供の時に受けた教育の紹介
6. 他の国の事例の紹介
7. 言葉を歴史から分析
8. フランス人クライアントの経験とフランス語の特徴
9. コミュニケーション指標のグラフ
10. グラフを使って、今までの話の事例の背景を解説
11. コミュニケーション指標が違う国だと、「良いコミュニケーションが違う」という理論説明
12. イタリア人の同僚の話
13. 指標グラフは相対的な位置づけが大事という説明
14. イギリス人が体験した、相対文化に関する事例の紹介✗2
15. 中国とヨーロッパの文化の差の吸収するコンサルタントの話
16. 自分よりハイコンテキストの人と仕事をする時のアドバイス
17. 自分よりローコンテキストの人と仕事をする時のアドバイス
18. 3つ以上の多文化間で仕事するときのアドバイス
19. 文化間での手法の紹介や、手法を使うときのアドバイス
20. 文化を明文化することで成功した事例
21. 最初の失敗事例の後日談（次の日は成功した）

これでもだいぶ省いていますが、大きなポイントは2つです。

• 事例がたくさんある。そして、事例は失敗パターンから、徐々に成功するという並び
• 事例の間に、理論的な説明。説明にあたっては、その後にフォローとしてすでに説明した事例を引き合いに解説したり、新しい事例を並べたり

なかなかここまでの事例を集めるのは大変です。僕が書いてきた本も、がんばってサンプルとかエピソードとか挟むようにはしてきましたが、ここまでたくさんは集められませんでした。著者が本業でやっている異文化間のコミュニケーションのコンサルタントという仕事ならではの内容といえます。

僕がかつて翻訳した本で、めちゃくちゃ苦労した本に、オライリーのアート・オブ・コミュニティがあります。なるべく日本語として読みやすくなるように頑張りましたが、そもそも「読みやすい」「読みにくい」という物差しが文化の差から生じたものだとはこの時は思っていませんでした。アート・オブ・コミュニティは抽象的な理論を最初にたくさん説明して、説明しきってから実際のコミュニティでの適用方法や事例などを紹介していきます。最初に説明した、欧州的な流れですよね。これがなかなか読みにくくて苦戦しました。

日本人とイギリス人で理論の積み上げ方が違うという前提を理解していれば愚直に訳す以外の他の作戦もあったと思います。例えば後半の訳文を先に訳してしまい、説明する内容の外堀を埋めてから前半を訳す、といった具合です。ウルトラCとしては、本文の順序を入れ替えて翻訳するというのも、実現可能性の理論は置いといて、可能性としてはありです。

実際、ここまで意識する必要があるのか、と思われる方もいますが、今時だとアマゾンとかでランキング上位に入ると、翻訳のオファーとかも来るそうです。翻訳そのものは翻訳者ががんばるところですが、その翻訳が終わったあとの文章がそれぞれの国の人にとって、とっつきやすいかどうかはこの構成で決まってしまいます。世界に売り込みたい人はマストバイです。もちろん、日本国内であっても性格の違いはよく観察されるので、広い人を満足させるテクを盗めれば本書の価値が大きく上がります。次に本を書く時は大いに参考にしたいと思います。

本書の3通りの読み方どれも楽しい

本書はもちろん、そのまま国際的なコミュニケーションのテクニックの本として読んでも役に立ちます。国際的な仕事をしている人はこれだけでも十分価値があります。一方で、本ブログで紹介してきたように、身の回りの事象に当てはめて読んでみてもいろいろなことが見えてきます。「あ、あの人は気性がメキシコ人っぽいな」とか。前節で紹介したように、本書そのものの構造を分析してみて、書籍執筆とかに役立てるという読み方もできます。本当に、どの読み方をしてもスキがないというか楽しめます。

ITエンジニアに読んでほしい！技術書・ビジネス書 大賞 2018ではエントリーがないですが、僕にとっては間違いなく、今年のベスト本ですね。あ、自分の本を抜いてですよ。Real World HTTPとGoならわかるシステムプログラミングもよろしくお願いします。

フューチャーアーキテクト裏アドベントカレンダーのエントリーです。9月から、DeNAからフューチャーアーキテクトに転職してお仕事しております。どちらかというとネットで話題になるのはSIerからWeb系ばかりなので、それとは逆ですね。Vulsで有名な神戸さんに声をかけていただいて、一度飲み屋で焼き鳥食べながらお話をして「次は役員呼びますわ」と言われて、今の上司の宮原洋祐さんを紹介されて焼肉を食べて、「次は会長紹介しますわ」と言われて、創業者で会長の金丸さんと面談があって「うちにおいでよ」という感じで、「次転職する時はクイズみたいなの楽しみだなぁ」と期待していたものもなく、１時間の面談でOKが出てしまい、他の会社も受けることなく決まりました。人事の方も「初めてのケース」と言われてました。

なぜフューチャーを選んだのか

一応、転職エージェントに何回か会ってみたりもしたものの、なかなかいいなと思える案件がありませんでした。B2Bで経験をしっかりと積みたいと思っていたのですが（おそらくエージェントへのキックバックが大きいと思われる）ウェブ系の会社とかが多く、B2Bの会社の紹介はありませんでした。自分で外資系のところに英語のレジュメを送ったりもしたのですが、日本国内だとセールスエンジニア的なものが多く、中の方も色々探してくれたのですが、Job Descriptionとマッチするのは本国にしかない、みたいな感じでした。社内SE業だとなかなか合わないんですよね。本を書いたというのも外資系だと別にプラスにならないですし。英語のレジュメを添削してくれた方々、某社のMさん、Fさん、結果は出せませんでしたが、その節は大変ありがとうございました。

B2Bの会社と一口にいってもいろいろあります。企業向けのSaaSみたいなのもあります。が、コンサルをして業務のグランドデザインをして、実装も自社で行うSIerがいいな、と思っていました。きちんとお客様のところに入って業務改善をやりたいし、下請けもつまらないですし、でもコードで話がしたい。そこにバッチリ当てはまったのが一番重要なポイントでした。実際、入社前に話をした人たちや、同じプロジェクトになった人たちはみんなスキルも熱意も高く、入社１−２年目の人たちも、僕が同い年だったときよりもよっぽど有能な感じですし。僕の知らないこともたくさんあります。もちろん、Web系よりも堅いところもありますが、楽しく仕事しています。

後は個人的な趣向ですが、前職の入社時に南場さんが言われていた「会社は黒字を維持してきちんと税金を納めるのが大切。社会資本の力を借りられるお陰で会社が経営できているので、社会にお返しをしないといけない」という理念がシンプルにいいなと思っていたので、きちんと黒字を出しているところがいいな、というのもありました。そういう意味では新人をきちんと取って教育しているというのもそうですね。社会的な持続可能性にコミットしているところですね。

もちろん、転職といえば待遇も動機ではありますが、神戸さんから「渋川さんがこんな給料安いなんて怒りを感じる」と言っていただき、オファー面談のときも「前職の給料は弊社の基準と差が大きいので参考にしませんでした」と言っていただきました。といっても、ボーナスの割合が大きくて、月々は変わらないので生活レベルは変わらないです。寿司はくら寿司です。廻り続けています。あと、出社時間は比較的遅めにさせてもらっているので、子供を幼稚園に送ってから、というDeNAのときにやっていたことも継続できています。

なぜB2Bにこだわったのか

一言で言えば、前職、前々職が楽しかったからです。どちらも社内SE的な立ち回りをしていました。自動車の車体やら樹脂のCADのアドオンだったり、電装系のCADだったり、それらの周辺システムだったり、ゲームのライブラリやミドルウェアだったり、サーバーサイドだったり、運用改善の入力補助ツールだったり、マスターデータの変換ツールだったり、目の前にいるユーザーさんのためにやる仕事はそれはそれでおもしろかったのですが、小さい仕事だと一人。たいてい片手で収まる人数での開発です。大きい仕事というと外部ベンダーさんにお願いして、その調整役みたいになってしまいます。社内SE業、FFRKチーム用語で言うと芝刈り業は楽しくても、仕事が小さくまとまってしまいます。せっかくなら、森林をガッと伐採してダムをガツン！と作るような仕事がしたいなって思っていました。なのでSIerです。

もうひとつは、pyspa仲間で受託開発とかSIerやっている人たちの話を聞いて、いろんな業務ドメインに関われるのはうらやましいなって思っていました。事業会社やWeb系だと、どうしても自社のビジネスの範囲で仕事のドメインが決まってしまいます。もちろん、それも悪くはないですし、ずっとそうでした。タイミングがあえば社内システム刷新で大きな仕事もあります。最近は大々的に募集して自社開発をしようとしている事業会社も増えてきていますので、面白い案件に入れるチャンスはあると思います。今回はフューチャーに決まるのが想像以上に早かったし、探していた条件とバッチリ合っていたので、他の会社はあまり検討もしませんでしたが。

SIerだと技術が古くて・・・みたいな話が話題になることが多いですが、実際はそんなに長くない期間でいろんな案件を回していきますし、その時々で最適な技術スタックでガンガン作っている、というのが入ってみてわかったことです。まあすべての会社がそうではないと思いますが、自社サービスでも一度当たると、古いコードがずーっと残って・・・というのもありえるし、大規模サービスでも、インフラ部隊ががんばってくれちゃって、SQLのjoin禁止以外に大規模を実感する開発があんまりない・・・みたいなのもありえますし、それと比べたら、すでにいろいろな体験をさせていただいて、日々勉強して追いつかなきゃ、という感じです。もちろん、大規模公官庁向け案件とか完成後数年は寝かせてから実稼働みたいな世界もあるので、全てがそうとはいえませんが・・・開発力だけじゃなくて、社会人力も日々鍛えられています。

SIerといえばスーツ

「プログラマー」「スーツ」で検索すると、「スーツ着用の会社は避けるべき」みたいな検索結果ばかりが出てくる今日このごろですが、入社以来ずっとスーツで通っています。別に自社にいるときはスーツ必須じゃないし、スーツ来てない人も多いです。客先がOKなら客先もスーツじゃなくてもいいです。

入社のときのドレスコードがわからずとりあえずスーツを買っていったのですが、最近のスーツは快適ですね！アオキの洗えるスーツ、ドライメッシュ素材の干すだけでいいノンアイロンワイシャツ、ユニクロのエアリズム下着。冬はモンベルのジオラインの下着。ジーパンTシャツよりもよっぽど快適で、暑がりで12月でも昼間はTシャツだったりするぐらいの僕でも大丈夫。何より毎日考えなくてもいいので楽。採用ページ用に写真を撮られた時に「ビジネスカジュアルで！」と言われたのですが、ビジネスカジュアルとか逆に難しいです。あ、でも辛いラーメンとか食べる時はちょっと気を使います。

辛いラーメンといえばDeNAには、ヒカリエから地下におりてずっと地下を通ると、雨に濡れずに中本渋谷店に行けるという最強の福利厚生がありまして、かなりヘビーに利用させていただいていましたので、そこのところを心配される方も多いと思います。北極は2倍とか3倍とかも選べて、最大の10倍もクリア済みです。中本はなくても、隣の五反田駅にはラーメン凪があって、30辛MAXにすると満足のできる辛さなので、今のところそれでなんとかなっています。トップ写真はそれです。といっても毎日はいかないですけどね。大抵はおにやんまです。

最後は運

転職体験記とかいろいろネットにあっても、その通りにやったら同じ体験が得られるものではないですよね。いい会社に入っても配属ガチャはありますし、上司ガチャもあります。会社に成長させてもらおう、勉強させてもらおう、みたいな期待を持ってしまうと、運良く自分の期待するチャンスにヒットしないと満足できなくなってしまいます。

会社には仕事とチャレンジ（東芝的な意味ではないです）さえあればいいと思ってます。もちろん、なんか尖ったスキルがある人であればそれでレバレッジするのは当然ですが、僕はジェネラリストで、スペシャリストと名乗れるスキルはないです。ただ、同じスライムをやっつけても、仕事への取り組み方によって経験値が2な人も、200な人もいるというのがゲームと違う世界なので、積極的に仕事に関わって、さらに自分の芸風を広げたいなって思っています。趣味でウェブフロントエンドの本を書いたら、後からそれを見てそれ系の仕事が降ってくるとかは前職でもありました。良い職場であればあるほど、とりあえず道は自分で拓けばいいという思いは忘れずにいたいです。たまたま勉強できるような仕事だったとしても、もともと勉強しておけば、さらに良いパフォーマンスを出せたはずですし。

振り返ってみると、前職でも、前々職でも運は良かった気がします。配属運も上司運も同僚運も。とくに、最近はSNSとかのお陰で、やめたあとも変わらず繋がっていられますし。実際に飲みに行ったりとかも前と変わらず、あるいは退職前にはつながってない人とさらに繋がったりもあります。そんな感じで、あまり以前よりも退職した！みたいな心の区切りとかもあまりなくて、部署が変わった＋アルファぐらいの気持ちではあります。今週末納車される車は前々職のホンダのオデッセイハイブリッドだし、野球はベイスターズ応援しますし。自分にとっては断続的なステップではないという気持ちです。

ソーシャルアプリプラットフォーム構築技法――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でも販売がはじまっています！

大きな修正ポイントは次の通りです:

• 連載の分量の関係で、同じテーマを何回かに分けていたのをまとめた
• 並列処理の記事からチャネル関連を抜き出して、加筆を大幅に加えて独立した章に
• タイマーやクロックについての章を追加
• セキュリティについての章を追加
• Go 1.9で追加されたもろもろを追加
• 締切の一週間前に、連載で紹介したIntelliJ IDEAのCommunity版で、Goプラグインがダウンロードできなくなったというレビューの報告を受けて急遽Visual Studio Codeに差し替え
• 高尾編集長の徹底的な修正で日本語が大幅に改善した
• 雪だるまの絵が、妻の書いたフクロウに変わった

これ以外にも数多くの修正を加えています。紙の書籍にするにあたって、数多くの知人に協力してもらって、レビューしていただいたのですが、1ページにつき1件というペースに近い300件近い意見をいただきました。これは連載をしていたので、一度細かい所まで見て修正したので些細なミスはあまりないはず、というところからの出発でしたが、遠慮なく徹底的にみてくださったレビューアのお陰で、かなり改善されています。ASCII.jpの連載終了から440コミットありました。

元は、LLでウェブアプリケーションフレームワークを普段作っているけど、低レイヤーを学ぶチャンスがなかなかない人に向けて本を書くといいのではないか、とラムダノートの鹿野さんと雑談したところから始まった連載でした。Real World HTTPも通信の低レイヤーではありましたが、こちらはOSの方面の低レイヤーになります。C言語を使った、読む側にもそれなりの知識が必要とされる本はいくつもありましたが（とても良い本です！）、本書はそういう既存の本よりも読みやすい本が提供できたのではないか、と思っています。アプリケーションレイヤーの応用例もイメージでき、古い本では紹介されているけど、現実的にあまり使われていないものは省き、逆に最近のトピックに触れるといったことで違いを出しました。

販売計画

ラムダノートさんは、取次を使っておらず、販売チャンネルも厳選されています。その分でお値段の割に濃い内容をお届けできているわけですが、直販サイトでは、10/19（木）午前中から予約開始予定です。実際にお手元に届くのは25日（水）ないし26日（木）から順次発送予定です。店頭販売は、10/22（日）の技術書典3での初売りを皮切りに、いくつかのラムダノートの書籍を扱う大手の書店で順次並び始めます。最速で入手したい方は、技術書典がチャンスです。近々、Amazonでも販売される予定です。

IT系でいうと、海外に比べて日本が遅れて云々、という話題が上がることもありますが、日本語で手に入る情報の質や量はかなり高まっていると思います。Goの書籍として見ても、そのあたりの海外の書籍には負けないものになったと思います。技術書展で出てくる本もかなり面白そうな本が多く、日本の底力を感じます。日本語という言語の壁はネガティブにしか見られないことが多いのですが、逆に日本の中ですごいことをやって世界をあっと言わせるチャンスでもあるはずです。

本書の他にも、定理証明の面白そうな本も出ますし、近々、僕の知人のグループx2がオライリーからそれぞれ電子書籍が出ます。こちらもよろしくお願いします。

• Sphinxをはじめよう」が改訂されます。
• 仕事ではじめる機械学習

前者はSphinxの入門書の改訂版で、使われることが増えてきたMarkdownと併用する方法なども書かれています。後者は以前の技術書典に出てた本のパワーアップ版で、各種手法の使い分けや、その名の通り既存のサービスに組み込んでいく方法などが説明されています。なお、本書も含めて、これらの本はSphinxで書かれています。これらの本はre:view変換して書かれました。本書は鹿野さんが作った拡張機能などの魔改造Sphinxで書かれており、僕も知らないなぞテクニックが駆使されています。そのうちこれの解説記事とかが公開されるのを期待。

こんなに知人同士の執筆時期がかぶると、お互いにレビューに参加するのも難しかったり、結構大変でした。みなさんお疲れ様でした。

目次

最後に目次をざっと紹介します。

はじめに
1. Go言語で覗くシステムプログラミングの世界
  1.1. システムプログラミングとは
    1.1.1. OSの機能について
  1.2. Go言語
  1.3. Go言語のインストールと準備
    1.3.1. Visual Studio CodeでGoが使えるようにする
    1.3.2. はじめてのGoプロジェクト
  1.4. デバッガーを使ってシステムコールを「見る」
    1.4.1. Visual Studio Codeでデバッガーを有効にする
    1.4.2. デバッガーを使って"Hello World!"の裏側を覗く
  1.5. 本章のまとめと次章予告
  1.6. 問題
2. 低レベルアクセスへの入口1：io.Writer
  2.1. io.WriterはOSが持つファイルのシステムコールの相似形
  2.2. Go言語のインタフェース
  2.3. io.Writerは「インタフェース」
  2.4. io.Writerを使う構造体の例
    2.4.1. ファイル出力
    2.4.2. 画面出力
    2.4.3. 書かれた内容を記憶しておくバッファ
    2.4.4. インターネットアクセスの送信
    2.4.5. io.Writerのデコレータ
    2.4.6. フォーマットしてデータをio.Writerに書き出す
  2.5. インタフェースの実装状況・利用状況を調べる
  2.6. 低レベルの機能を組み合わせて入出力APIを作る
  2.7. 本章のまとめと次章予告
  2.8. 問題
3. 低レベルアクセスへの入口2：io.Reader
  3.1. io.Reader
  3.2. io.Readerの補助関数
    3.2.1. 読み込みの補助関数
    3.2.2. コピーの補助関数
  3.3. 入出力に関するio.Writerとio.Reader以外のインタフェース
    3.3.1. 入出力関連の複合インタフェース
    3.3.2. 入出力関連インタフェースのキャスト
  3.4. io.Readerを満たす構造体で、よく使うもの
    3.4.1. 標準入力
    3.4.2. ファイル入力
    3.4.3. ネットワーク通信の読み込み
    3.4.4. メモリに蓄えた内容をio.Readerとして読み出すバッファ
  3.5. バイナリ解析用のio.Reader関連機能
    3.5.1. 必要な部位を切り出すio.LimitReader／io.SectionReader
    3.5.2. エンディアン変換
    3.5.3. PNGファイルを分析してみる
    3.5.4. PNG画像に秘密のテキストを入れてみる
  3.6. テキスト解析用のio.Reader関連機能
    3.6.1. 改行／単語で区切る
    3.6.2. データ型を指定して解析
    3.6.3. その他の形式の決まったフォーマットの文字列の解析
  3.7. io.Reader／io.Writerでストリームを自由に操る
  3.8. 本章のまとめと次章予告
  3.9. 問題
4. 低レベルアクセスへの入口3：チャネル
  4.1. goroutine
  4.2. チャネル
    4.2.1. チャネルの使用方法
    4.2.2. チャネルの3つの状態
    4.2.3. for文
    4.2.4. チャネルとselect文
    4.2.5. コンテキスト
  4.3. システムからの通知
    4.3.1. OSからのシグナルをチャネルで受け取る例
  4.4. 本章のまとめと次章予告
  4.5. 問題
5. システムコール
  5.1. システムコールとは何か？
    5.1.1. CPUの動作モード
    5.1.2. システムコールでモードの壁を越える
    5.1.3. システムコールがないとどうなるか？
  5.2. Go言語におけるシステムコールの実装
    5.2.1. 各OSにおけるシステムコールの実装を見てみよう
    5.2.2. macOSにおけるシステムコールの実装（syscall.Open）
    5.2.3. LinuxにおけるGoのシステムコール実装（syscall.Open）
    5.2.4. WindowsにおけるGoのシステムコール実装（syscall.Open）
  5.3. POSIXとC言語の標準規格
  5.4. システムコールより内側の世界
    5.4.1. システムコール関数はSYSCALL_DEFINExマクロで定義される
    5.4.2. CPUが関数を実行できるようにするまで
  5.5. Go言語のシステムコールとPOSIX
  5.6. システムコールのモニタリング
    5.6.1. Linux
    5.6.2. FreeBSD
    5.6.3. macOS
    5.6.4. Windows
  5.7. エラー処理
  5.8. 本章のまとめと次章予告
  5.9. 問題
6. TCPソケットとHTTPの実装
  6.1. プロトコルとレイヤー
  6.2. HTTPとその上のプロトコルたち
    6.2.1. HTTPの基本
    6.2.2. RPC
    6.2.3. REST
    6.2.4. GraphQL
  6.3. ソケットとは
  6.4. ソケット通信の基本構造
  6.5. Go言語でHTTPサーバーを実装する
    6.5.1. TCPソケットを使ったHTTPサーバー
    6.5.2. TCPソケットを使ったHTTPクライアント
  6.6. 速度改善（1）: HTTP/1.1のKeep-Aliveに対応させる
    6.6.1. Keep-Alive対応のHTTPサーバー
    6.6.2. Keep-Alive対応のHTTPクライアント
  6.7. 速度改善（2）: 圧縮
    6.7.1. gzip圧縮に対応したクライアント
    6.7.2. gzip圧縮に対応したサーバー
  6.8. 速度改善（3）: チャンク形式のボディー送信
    6.8.1. チャンク形式のサーバーの実装
    6.8.2. チャンク形式のクライアントの実装
  6.9. 速度改善（4）: パイプライニング
    6.9.1. パイプライニングのサーバー実装
    6.9.2. パイプライニングのクライアント実装
    6.9.3. パイプライニングとHTTP/2
  6.10. 本章のまとめと次章予告
7. UDPソケットを使ったマルチキャスト通信
  7.1. UDPとTCPの用途の違い
    7.1.1. UDPが使われる場面は昔と今で変わってきている
  7.2. UDPとTCPの処理の流れの違い
    7.2.1. サーバー側の実装例
    7.2.2. クライアント側の実装例
  7.3. UDPのマルチキャストの実装例
    7.3.1. サーバー側の実装例
    7.3.2. クライアント側の実装例
    7.3.3. 実行例
  7.4. UDPとTCPの機能面の違い
    7.4.1. TCPには再送処理とフロー処理がある
    7.4.2. UDPではフレームサイズも気にしよう
    7.4.3. 輻輳制御とフェアネス
  7.5. 本章のまとめと次章予告
8. 高速なUnixドメインソケット
  8.1. Unixドメインソケットの基本
  8.2. Unixドメインソケットの使い方
    8.2.1. ストリーム型のUnixドメインソケット
    8.2.2. Unixドメインソケット版のHTTPサーバーを作る
    8.2.3. Unixドメインソケット版のHTTPクライアントを作る
    8.2.4. データグラム型のUnixドメインソケット
  8.3. Windowsの名前付きパイプ
  8.4. UnixドメインソケットとTCPのベンチマーク
  8.5. ソケットのシステムコール小話
  8.6. 本章のまとめと次章予告
9. ファイルシステムの基礎とGo言語の標準パッケージ
  9.1. ファイルシステムの基礎
    9.1.1. 複雑なファイルシステムとVFS
  9.2. ファイル／ディレクトリを扱うGo言語の関数たち
    9.2.1. ファイル作成／読み込み
    9.2.2. ディレクトリの作成
    9.2.3. ファイルの削除／移動／リネーム
    9.2.4. ファイルの属性の取得
    9.2.5. ファイルの存在チェック
    9.2.6. OS固有のファイル属性を取得する
    9.2.7. ファイルの同一性チェック
    9.2.8. ファイルの属性の設定
    9.2.9. リンク
    9.2.10. ディレクトリ情報の取得
  9.3. OS内部におけるファイル操作の高速化
  9.4. ファイルパスとマルチプラットフォーム
    9.4.1. Go言語でパス表記を扱うパッケージ
  9.5. path/filepathパッケージの関数たち
    9.5.1. ディレクトリのパスとファイル名とを連結する
    9.5.2. パスを分割する
    9.5.3. 複数のパスからなる文字列を分解する
    9.5.4. パスのクリーン化
    9.5.5. 環境変数などの展開
    9.5.6. ファイル名のパターンにマッチするファイルの抽出
    9.5.7. ディレクトリのトラバース
  9.6. 本章のまとめと次章予告
10. ファイルシステムの最深部を扱うGo言語の関数
  10.1. ファイルの変更監視（syscall.Inotify*）
  10.2. ファイルのロック（syscall.Flock()）
    10.2.1. syscall.Flock()によるPOSIX系OSでのファイルロック
    10.2.2. LockFileEx()によるWindowsでのファイルロック
    10.2.3. FileLock構造体の使い方
  10.3. ファイルのメモリへのマッピング（syscall.Mmap()）
    10.3.1. mmapの実行速度
  10.4. 同期・非同期／ブロッキング・ノンブロッキング
    10.4.1. 同期・ブロッキング処理
    10.4.2. 同期・ノンブロッキング処理
    10.4.3. 非同期・ブロッキング処理
    10.4.4. 非同期・ノンブロッキング処理
    10.4.5. Go言語でさまざまなI/Oモデルを扱う手法
  10.5. select属のシステムコールによるI/O多重化
  10.6. 本章のまとめと次章予告
11. プロセスの役割とGo言語による操作
  11.1. プロセスに含まれるもの（Go言語視点）
    11.1.1. プロセスID
    11.1.2. プロセスグループ・セッショングループ
    11.1.3. ユーザーIDとグループID
    11.1.4. 実効ユーザーIDと実効グループID
    11.1.5. 作業フォルダ
    11.1.6. ファイルディスクリプタ
  11.2. プロセスの入出力
    11.2.1. コマンドライン引数
    11.2.2. 環境変数
    11.2.3. 終了コード
  11.3. プロセスの名前や資源情報の取得
  11.4. OSから見たプロセス
  11.5. exec.Cmdによるプロセスの起動
    11.5.1. リアルタイムな入出力
  11.6. os.Processによるプロセスの起動・操作
  11.7. プロセスに関する便利なGo言語のライブラリ
    11.7.1. プロセスの出力に色づけをする
    11.7.2. 外部プロセスに対して自分が擬似端末だと詐称する
  11.8. Go言語では触れることのない世界
    11.8.1. fork()/exec()
    11.8.2. フォークと並行処理
    11.8.3. デーモン化
  11.9. 子プロセスの内部実装
  11.10. 本章のまとめと次章予告
12. シグナルによるプロセス間の通信
  12.1. シグナルのライフサイクル
  12.2. シグナルの種類
    12.2.1. ハンドルできないシグナル
    12.2.2. サーバーアプリケーションでハンドルするシグナル
    12.2.3. コンソールアプリケーションでハンドルするシグナル
    12.2.4. たまに使うかもしれない、その他のシグナル
  12.3. Go言語におけるシグナルの種類
  12.4. シグナルのハンドラを書く
    12.4.1. シグナルを無視する
    12.4.2. シグナルのハンドラをデフォルトに戻す
    12.4.3. シグナルの送付を停止させる
    12.4.4. シグナルを他のプロセスに送る
  12.5. シグナルの応用例（Server::Starter）
    12.5.1. Server::Starterの使い方
    12.5.2. Server::Starterが子プロセスを再起動する仕組み
    12.5.3. Server::Starter対応のサーバーの実装例
  12.6. Go言語ランタイムにおけるシグナルの内部実装
  12.7. Windowsとシグナル
  12.8. 本章のまとめと次章予告
13. Go言語と並列処理
  13.1. 複数の仕事を同時に行うとは？
  13.2. Go言語の並列処理のための道具
    13.2.1. goroutineと情報共有
  13.3. スレッドとgoroutineの違い
  13.4. GoのランタイムはミニOS
  13.5. runtimeパッケージのgoroutine関連の機能
    13.5.1. runtime.LockOSThread()／runtime.UnlockOSThread()
    13.5.2. runtime.Gosched()
    13.5.3. runtime.GOMAXPROCS(n)／runtime.NumCPU()
  13.6. Race Detector
  13.7. syncパッケージ
    13.7.1. sync.Mutex／sync.RWMutex
    13.7.2. sync.WaitGroup
    13.7.3. sync.Once
    13.7.4. sync.Cond
    13.7.5. sync.Pool
    13.7.6. sync.Map
  13.8. sync/atomicパッケージ
  13.9. 本章のまとめと次章予告
14. 並行・並列処理の手法と設計のパターン
  14.1. 並列・並行処理の手法のパターン
    14.1.1. マルチプロセス
    14.1.2. イベント駆動
    14.1.3. マルチスレッド
    14.1.4. ストリーミング・プロセッシング
  14.2. Goにおける並行・並列処理のパターン集
    14.2.1. 同期→非同期化
    14.2.2. 非同期→同期化
    14.2.3. タスク生成と処理を分ける：Producer-Consumer
    14.2.4. 開始した順で処理する：チャネルのチャネル
    14.2.5. タスク処理が詰まったら待機：バックプレッシャー
    14.2.6. 並列forループ
    14.2.7. 決まった数のgoroutineでタスクを消化：ワーカープール
    14.2.8. 依存関係のあるタスクを表現する：Future/Promise
    14.2.9. イベントの流れを定義する：ReactiveX
    14.2.10. 自立した複数のシステムで協調動作：アクターモデル
  14.3. 本章のまとめと次章予告
15. Go言語のメモリ管理
  15.1. メモリ確保の旅
    15.1.1. 物理メモリと仮想メモリ
    15.1.2. OSカーネルがプロセスのメモリを確保するまで
    15.1.3. 実行時の動的なメモリ確保：ヒープ
    15.1.4. 実行時の動的なメモリ確保：スタック
    15.1.5. ユーザーコードでメモリを使う
  15.2. Go言語の配列
  15.3. Go言語のスライス
    15.3.1. スライスの作成方法
    15.3.2. スライスのメモリ確保
  15.4. ガベージコレクタ
  15.5. 本章のまとめと次章予告
16. 時間と時刻
  16.1. OSのタイマー／カウンターの仕組み
  16.2. さまざまな時間
  16.3. 時間に関するシステムコール
    16.3.1. runtime.now()
    16.3.2. runtime.semasleep()
  16.4. Go言語で時間を扱う
    16.4.1. 時間と時刻
    16.4.2. スリープ
    16.4.3. チャネルを使ったタイマー
  16.5. 時刻のフォーマット
  16.6. 本章のまとめと次章予告
17. Go言語とコンテナ
  17.1. 仮想化
    17.1.1. 仮想化は低レイヤーの技術の組み合わせ
  17.2. コンテナ
  17.3. libcontainerでコンテナを自作する
    17.3.1. コンテナのブートに必要な下準備
  17.4. 本章のまとめ
Appendix 1. セキュリティ関連のOSの機能とssh
  1.1. 乱数
    1.1.1. 2種類の乱数生成アルゴリズム
    1.1.2. 乱数のシステムコール
    1.1.3. 乱数の使い方
1  .2. TLS（Transport Layer Security）
    1.2.1. ルート証明書
    1.2.2. ルート証明書の取得
  1.3. ssh（Secure Shell）
    1.3.1. sshの基本的な流れ
    1.3.2. Goによるssh接続
    1.3.3. scp（Secure Copy）
1.4. キーチェーン
    1.4.1. キーチェーンとは
Appendix 2. 参考文献
あとがき
謝辞

昨年から書いていた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では日々新しいトピックが登場していますが、本書によって基礎をしっかりと押さえることは、さまざまな新しい技術をキャッチアップする一助にもなるでしょう。

目次はこんな感じです。

1. HTTP/1.0 のシンタックス:基本となる 4 つの要素
2. HTTP/1.0 のセマンティクス:ブラウザの基本機能の裏側
3. Go 言語による HTTP/1.0 クライアントの実装
4. HTTP/1.1 のシンタックス:高速化と安全性を求めた拡張
5. HTTP/1.1 のセマンティクス:広がる HTTP の用途
6. Go 言語による HTTP1.1 クライアントの実装
7. HTTP/2 のシンタックス:プロトコルの再定義
8. HTTP/2 のセマンティクス:新しいユースケース
9. Go 言語による HTTP/2、HTML 5 のプロトコルの実装
10. セキュリティ:ブラウザを守るHTTPの機能
11. クライアント視点で見るRESTful API

内容としては、HTTP/1.0、HTTP/1.1、HTTP/2というおおざっぱな期間ごとに次の３つの章を繰り返してその時期に登場した技術のトピックをいくつか紹介し、最後にセキュリティとRESTfulの章が追加されている感じです。

• HTTPのシンタックス
• HTTPのセマンティクス
• 実際にコードを書いて試してみる

実際にはHTTPのバージョンは時期的な目安なので、そこまで厳密ではありません。消化不良にならないように読みやすく分割するための分け方です。人間の記憶はエピソードとともに知識を固定する方がやりやすいので、そういったことを心がけています。普通のHTTPのプロトコルの技術的紹介だとなかなか詳しく紹介されないであろうトピック（TLS、認証／認可、セマンティックウェブのその後、セキュリティを守るためのブラウザ技術）についても、多くの方々の強力なバックアップのもとに概要をきちんとつかめるように書きました。

アプリケーション開発だと、ウェブに関係しないシステム自体がだいぶレアになってきているので、かなり多くの人に末永く参考にしていただけるのでは、と思っています。CGI時代やJ2EE初期時代に学んだ人も、その後の知識のアップデートに役立てていただけると思います。最新のブラウザの機能（セキュリティのヘッダーとか）も、過去の経緯や機能を踏まえて追加されることがほとんどです。一通りきちっと学ぶことで、今後出てくるトピックを追いかけるのがとても楽になるはずです。「読める！読めるぞ！」とムスカになったような感動が味わえるはずです。

後は、書いていてワクワクしていたポイントは、HTTPまわりの仕様にはさまざまなエンジニアリングの創意工夫があることです。後方互換性を維持するしくみとか、サーバー・クライアントでベストな選択肢を選ぶ方法、効率の改善。こういうところに着目して読んでもらえると（上級者には）楽しいと思います。

なぜ書こうと思ったのか

書き始めたきっかけは、cURL as DSLというツールの開発です。現在ではウェブ上の資料も充実してきて、本がなくても調べる難易度が下がっていますが、書こうと思った当時はGo言語でREST APIのクライアントを書く情報がまとまっていませんでした。curlコマンドの使い方やJSONのパースなども含めて、Go言語のネットワークプログラミングを一冊で理解できる本とか面白いのではないか？と思って書き始めました。しかし、書く以上は言語が変わっても使える知識がきちんと伝わる本にしよう、と思ってウェブの知識をいろいろ補完する内容を増やしていきました。

この時点では100ページちょっとの電子書籍の予定で、夏ぐらいにはだそうと思っていました。しかし、ウェブの基礎知識というのが結構厄介で、インターネット上に書かれている内容は玉石混交で、すでに古くなった内容や、今ではバッドノウハウでしかないことがベストプラクティスであると喧伝されている例も数多くあります。徐々に、Goの本から離れて、ウェブの基礎知識の内容が増えていきました。間違ったことを書いてはいけないので、RFCとにらめっこする日々でしたが、現代のブラウザ技術というのは、かなり複雑で、いろいろなレイヤーを理解しないと把握することすら困難です。新しい技術やら、セキュリティのニュースやらは流れてきますが、なんとなく雰囲気で「ふんふん」とわかった気になっている人も多いのではないでしょうか。僕もそういう所が多かったな、と書きながら思い知らされました。

Sphinxで書いていましたが、当初予定の夏頃にはPDFのページ数がどんどん増え「なかなかゴールが見えてこないぞ」という状況が続きました。1つの機能の紹介を書くにも、一週間から数週間はかかりました。とはいっても、つらいとか、うんざりとかはなくて、「この仕組の裏側はどういうヘッダーがやりとりされているんだろうか？」と、どんどん好奇心が湧いて収められなかった、という感じです。他の執筆と並行で走っていた時期があったとはいえ、ずーっとワクワクしながらRFCやらW3Cの仕様を見たりしていました。

年が明けるころには300ページを超える見込みになり、改めて企画会議をやり直して、紙の書籍として本屋に並ぶ運びとなりました。「Real World HTTP」というタイトルや、「ブラウザ視点でユーザーから見える機能の裏側を解説する」というコンセプトが決まってからは、構成が散らからずにうまくまとまる方向で原稿が転がりました。章内の各項目は比較的独立しているため、興味のあるところをつまみ読みもできる構成になっています。自分が知りたいことを集めて書いた本なので、ゲラが上がってレビューをするのも「すごい！このPDFには自分が知りたかったことがいっぱい書いてあるぞ！」と楽しく何度も読めました。

書く時に心がけたこと

まずは書かないことを決めました。ブラウザを扱いますが、JavaScriptのUIレイヤーは扱わないことにしました。Mithril本で扱ったレイヤーです。Reactが勝ちつつありますが、Fluxレイヤーまわりのゴタゴタが落ち着くまでは手を出すつもりはないです。Mithrilは1.0が出て、アグレッシブにダイエットしてきているので、Mithril本のアップデートは今後考えたいところです。

あとは、サーバーサイドの設計についても考えないことにしました。ちょうどオライリーには水野さんのWeb API: The Good Partsがあります。また、マイクロサービスが出てきて、デプロイの戦略も一緒に考えないといけない感じになってきており、手広くなりすぎます。また、低レベルの通信に関しては、これまたオライリーのハイパフォーマンスブラウザネットワーキングがあり、僕の技量的にもあれは絶対超えられないので、そこはスルーすることにして、この二冊の間をカバーするということにしました。

書籍にするにあたっては、現代で使われてなくて覚えるだけ無駄となる機能というのは極力排除し、現在でも使われているもの、あるいはその礎となったものをきちんと網羅するように書いていきました。書籍というメディアには得意なところと不得意なところがあります。電子書籍になってライフサイクルが変わりましたが、紙を前提とするとバージョンアップが頻繁なものは取り上げるのが大変です。また、辞書のように網羅性をとことん高め、検索もできる、というものはウェブの方が得意です。単なるRFC集ではなく、エピソードでイメージが想像しやすいように構成しています。超長文となると、ウェブよりも書籍の方が読者体験をデザインしやすいメリットがあります。途中「こんなに時間かけてもいいのかな？他の人が同じ内容で先に出してしまわないかな？」と（HTTP特集がSD誌やWeb+DBの予告に乗るたびに心配になったりもしましたが、編集をしてくださった瀧澤さんからは「一人の著者が、１人のブレない視点で内容をまとめるということ自体にも価値がある」と言ってくださいました。

ローカルの執筆環境としてはVimでSphinxです。gitlab CIでepubとPDFをビルドするようにしていました。こちらのchezouさんによる「Gitlab CIを使ってSphinxのドキュメントを自動でPDFにビルドする」のイメージを使わせてもらいつつ、Sphinxは最新のmasterをぶっこむビルド構成にしています。ちょうど昨日、@tk0miyaと@shimizukawaの不断の努力によってSphinx 1.6.1がリリースされましたが、このリリースはepub checkの警告とエラーが激減（Sphinx本体のドキュメントはゼロ）しています。自分の本の原稿とSphinx自身のドキュメントを題材にエラーを潰してコミットしまくっているうちにコミッターに推薦されてコミッターにもなりました。O'Reillyさんの中のフローは今まで通りですが、epubからkindlegenでKindleのファイルを生成することも可能になったりもしたし、Sphinx自身も今後、同人活動やら出版に活用できるように頑張っていきたい所存です。

あと、今回はAmazon Pollyを執筆に活用しました。Sphinx拡張を作り、段落ごとにMP3化して、最後にファイル単位のMP3を作成しています。レビューというのは視点を変えるのが大事です。紙で印刷して見る、というのも視点を変える方法ではありますが、今回はAmazon Pollyで音声ファイルにして耳で確認する方法にしました。助詞間違いとかは耳で聞くとすぐ分かりますし、文章の繋がりが悪かったり、定義を説明せずに先に行ったり、文章の内容が飛んだりといったことがかなり拾いやすくなります。一冊を全部音声化すると15時間ぐらいになりますが、通勤時間などで繰り返しレビューしてました。有料API（無料枠がでかいので実質かかりませんでしたが）はCIでは利用せず、ローカルで必要に応じて作っていました。「サーバー」「ヘッダー」など、長音をなるべく付けるようにしたのは、音声合成との相性によるものです。ついでに好きな声優の声とか選べるとうれしいです > Amazonさん

耳でレビューで気づいたのは、1.2倍速ぐらいまであれば細かい文法を気づけるんですが、それ以上になると文法ミスの発見には不向きということですね。ただし、説明していない概念が突発的に来たぞ、とか、大きな流れのデバッグには1.5倍速ぐらいでもいけました。2倍速ぐらいになると間違いとかまったく関係なく意味だけが流れ込んできますね。高速音声で洗脳とかできそうだなってちょっと思いました。

これまで関わってくださった多くの方々に感謝

ウェブの開発はあまりにも普遍化してしまったので、もはや誰に何を教わったかも思い出せないぐらい、ずっと過去からいろいろな人に教わってきたことがこの本には入っています。Twitterでのちょっとしたやりとり、Qiitaのコメント、社内外の人とのSlackの会話、会社での雑談や立ち話。もちろん業務を知りながら学んだことなど、細かいものも含めればきりがありません。謝辞には本書に対する直接的な貢献をしていただいた方々の名前を入れていますが、僕と技術的な会話した人はほぼ例外なく入っていると思っていただけると幸いです。また、直接会ってない方々でも、いくつか本文から参照させていただいたウェブサイトやスライドなどで助けていただいた方もたくさんいます。この場を借りて感謝申し上げます。

特に、この本の「こんなところまで知ることができる！」というカバレッジを上げるウリであるところのTLS、セキュリティ、認可・認証まわりは、僕にとってもチャレンジングでした。その分野の専門の人達にレビューしてもらい、安心して読めるものになったと思います。ラムダノートのプロフェッショナルSSL/TLSはもっと早く読みたかったですね（購入して速攻読んで今後読むべき本として紹介しています）。

子供もいるので、土日はなるべく家族の時間としていますが、去年は並行でいろいろやりすぎたのもあるので、もう少し余裕を持ちたいところです。家族にも感謝。いつ書いているの？とよく聞かれるんですが、執筆と仕事と子供と遊ぶ以外はほとんどしてません。テレビもほとんど見ず（SHOW BY ROCK!!#を除く）、ゲームもほとんどやらず（SHOW BY ROCK!!を除く）、コンピュータ以外の本もほとんど買わない（SHOW BY ROCK!!#オフィシャルブックを除く）ですが、子供の成長を見るのが趣味となっています。4歳の長女はバランスバイクのおかげで転ばずに一発で自転車乗れるようになったり、インラインスケートで1.5m間隔のパイロンのスラロームもできるようになったし、英単語勉強しているし、先日3歳になったばかりの次女もスケートを始めました。両親の子供時代よりも着実に小さい頃からいろんなことができるし、子供にいろいろなチャレンジを楽しく提供するのが楽しみです。

大学のサークルの後輩の吉村総一朗（当時呼び捨てで呼んでたと思うので、あえてこのまま敬称略で書きました）から、高校生からはじめるプログラミングを献本でいただきました。ありがとうございます。

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健保に入っていれば医療保険もいらないです。 でもまぁ、同じ会社に入る続けるかどうかも分からないし、大手に入っても業績が安定しているとは限らないし、年金は出ないという前提で、自衛のために生命保険でバックアップを組むことにしました。

嫁の医療保険は、お義母さんが入ってくれてくれているのがありましたが、それも今回引き取って、こちらで全部やるということにしました。

生命保険とは

掛け捨ての方はおいといて、貯蓄性の生命保険は金融商品としての基本特性は

• きまった期間以上(60歳とか)継続してお金を入れ続ければ増えて帰ってくる
• 途中解約すると返ってこない
• 途中で契約者の身に何かあったら、満額払ったのと同じ扱いになる

最後のポイントが他の金融資産と大きく違うポイントですよね。年金を作る手段としては401Kとかいろいろありますが、家族や子供がいるならメリットが大きいですよね。 ただし、税金の控除の枠はそれほど大きくないので、すぐ限界にいっちゃいます。減税メインで狙うなら401Kとかの方がいいんですかね。 金融機関目線だと、引き出しにくくするデメリットを課すことで資金がプールされて、それで契約者の事故や病気などの統計的に見積もれるリスクをコントロールできる金融商品ということになるかと思います。

生命保険は人生の各種トラブルの確率と統計を元にしたビジネスなので、基本的には保険会社の商品によって何処のリスクを多くとるかでパフォーマンスが変わります。 自分の生活とか加入時の状態や時代に合わない商品もあります。 「誰でも入れる」というのはリスクが高い人もサポートするということで、リスクが低い人にとっては損、みたいな。最近話題になっている手数料の問題とかもあったり、金融機関の取り分の多い商品というのも確かにあります。 今時だと60歳までに死んだり、病気になる人というのは割合的には多くないらしいのですが、60歳で保証が終わってしまうやつとか。

ちなみにリスク・コントロールに関しては今は契約者側に少し分があって、遺伝子検査で病気の成りやすさを見ることができます。弊社のMY CODEとか、それ以外にもいろいろあります。比較したわけではないのでどれがいいかは分かりませんが、今のところ、遺伝子検査の結果を保険会社が参照してはいけないということになっているので、ユーザ側がオトクな保険を選ぶ基準にできます。掛け捨て保険ぐらいならいらないかもしれませんが、住宅ローンで三大疾病オプション、八大疾病オプションをつけるとか、年金機能もつけた年数十万以上の保険をかけるなら悪くない投資だと思います。僕は検査結果を見て住宅ローンは団信だけにしました。

いくつもの商品を組み合わせて自分用にポートフォリオを組むのは保険を知り尽くしていないと難しいので、詳しい人にお世話になったほうがいいです。

ちなみに保険が役に立つ時というのは、契約した保険会社のフローをいかに効率よく回すかということになるので、なるべくそこに近い人の方が融通がきくっぽいです。 正社員の人に今回お願いできましたが、別の(アフラック)で専属営業している方に長らくお世話になってきましたけど、そちらも悪くはなかったです。まあ同じような保険のおばちゃんでも保険金降りるまで何度もやりとりが必要だったことがあるので(嫁の方の契約)、人のスキル差によるところもありそうです。

あと、心の病で心療内科にかかったりすると回復するまで入れなかったりしますし、女性は妊娠するといろいろ契約上ペナルティがあります。妊娠すると1/6以上の確率でおきるといわれている流産の後処置、あるいは帝王切開でも手術を受けた扱いになってしまいます。 健康な時、結婚した直後、あるいは子供が生まれたなど、家庭環境が大きく変わったときが見直しのポイントですよね。

ところで、今年はポリティカル・コレクトネスに注目が集まった1年でした。ポリコレ棒なる言葉が使われるようになったり。SHOW BY ROCK!!というサンリオのIPがあるのですが、ポリコレの視点で考えるとなかなか興味深いです。基本ケモナーだし、世の中のありとあらゆるフェティシズムを考えられる限り詰め込み、腐男子も腐女子も平等にサービスしようとする姿勢は素晴らしいですね。趣向の違いを封じる方向性ではなくて、お互いの趣向の違いを最大限に尊重する、そういうポリコレが広まってほしいものです。進化させると巻き髪がほどけるシアンと垢抜けていくウワサノペタルズにはちょっと納得はいかないですが。

必要な保険

どのぐらいの生活がしたいか、生活スタイル・・・等で必要な額は変わります。あとは個人年金ですね。 老後に必要なお金は3000万ぐらいって言われていますよね。生命保険で補償してもらいつつ、最終的にそのぐらいが残る貯蓄型の保険プランが必要なプランということなります。 国の年金が出なくなっても、まわりの人達よりも平均して貯蓄があれば物価下降があって相対的になんとかなるでしょう。

今回の営業の方に教わったことの中で「なるほど」と思ったのは、必要な額はどんどん減りますよ、ということ。10年後であれば、10年分の生活のコストはすでに払い済みと考えられます。 それに従って、経年で補償額が減るようなプランを組めばムダがないですよ、と。

リスクとしては死亡よりも、働けなくなることの方が大きい、ということも教わりました。遺族年金とかもらえるんでしたっけ。働けない方が病院の費用とかがかさみます。すぱっと死んでしまったほうが家族には負担が少ないと。 ということで、働けない時のサポートの保険は就業期間中は必要です。

あとは子供関係ですよね。学資保険的なもの。子供にかかるお金って小学校ぐらいではすごく低くてそれから増えていきますよね。東京都だとだいたい医療費も中学卒業までは所得制限もなく無料です。 定額でお金を入れていく学資保険ってあまり実体に合わないというか、余裕があるうちにぶっこんでおきたいところ。 小学校入学前は、幼稚園、認可保育園、認可外保育園など、条件によって大きく変わってきます。あとは習い事事情ですね。

子供の医療に関してはめっちゃお世話になっているし、もうしわけないのでふるさと納税はしてません。いや、今住んでいる区にふるさと納税してもいいんですけどね。感謝状くれるらしいです。

もちろん、共働きであれば必要性はだいぶ下がるでしょう。知り合いでもフィナンシャルプランナースキルがある共働きの人は投資信託や401K中心の人が多いです。ただ、共働きでも何かあったら分業していた家事の分担が減り、子供の世話やら何やらで仕事に取り組める時間が減ったりというのもあり、まったくいらないということはないはず。病院通いが必要など、配偶者に負担がかかる状態になってしまう確率もゼロではないですし。

中古の一軒家

家も保険のポートフォリオの一部です。僕が死んだ後は団信のおかげでローン残高はゼロになりますしね。住居費がかからなければ死語必要な金額は大分減るので必要な補償額もだいぶ減ります。 ローンを払い終わっていたら生命保険としての役割はなくなりますが「自分が死んだら家を売って金を作る」手段になります。

家の値段って、知っている人からすればほぼ推定できちゃうものなので隠してもしょうがないので書いておくと4000万ぐらいです。築14年の一軒家です。 木造建築は27年で評価がゼロになるらしいので買った時点で上モノは半額バーゲン。おそらく新築時5000万ぐらい予想で、だいたい最終価格3000万ぐらいになる予想。

10年スパンぐらいで考えたら、5-10年落ちの駅チカマンションの方が価格下落も少ないし、 売りやすいと思いますが、一軒家は土地代だけになれば時間による低減はなくなります。 ローン残高が3000万切れば、今後は「ローン返済」ではなくて「売れば返ってくる土地に貯金」というイメージ。 賃貸で家族5人の広さの家を借りると15万以上とかになるし、駐車場付きでそれよりも遥か少ない月々の支払い額なのでだいぶ助かります。 ワンルームとかを別にすれば、賃貸と比較すると同じ金額で広さが2倍 or 同じ広さで金額は半額という実感。

家の売りやすさは考慮しました。あまり小さい狭小地は櫛形の土地だと建て替えもままならず売れないということで除外。ハザードマップ的にも安心な小高い丘の上。 古くからの神社や寺が残っている場所は安心(ymotongpoo談)というアドバイスも参考に。子供が多い地域で通り抜けの車も少ない静かな場所です。 あまりに地方だったりすると売ろうにも売れずに大変という話は聞きますが、人口減少して居住区域が縮小していってもまあ大丈夫でしょう。転がして儲けようという感じではないので。安くしてでも売れればOK。 副都心線で渋谷まで一本だし、外環が東名まで開通したら車の移動もラクになりますしね。

ところで、艦これの映画が今上映されているようですね。艦これのアニメが放送された時は「父兄参観のようだ」と言われました。放送されたSHOW BY ROCK!!のアニメをたまたま見たのですが「忍迅雷音、10話ぶりに出た！」とかやはり父兄参観という感じですね。Free To Playのゲームは課金してもらう機会を増やすために大量のコンテンツを投入します。SHOW BY ROCK!!も二期アニメでは歌を歌う主要メンバーだけで、7バンド25人もいます。12話300分を平等に分割すると１人10分です。キャラクタが画面に出ない回も多く、出てもしゃべらないとか。Free To Playゲームのアニメ化は今後も続くと思いますし、「尺が短い」などの話も出てくると思いますが、今季は落ちたアニメも出て制作現場はますます厳しいそうですので、ひとまず動く絵にしてくれただけでも感謝です。

最終的に入った保険

年額で100万円以上です。多いですか？あと30年で3000万貯めるなら、今時は派手に利子もつかないし、単純計算で100万です。子供の学資保険的なものもあったり、いろいろあるので単純な割り算ではないですがそのぐらいです。 アフラックで入っていた保険も「これは条件がいい時に入れたものだから残したほうがいい」と言ってくれるような営業の方だったおかげで、安心感はだいぶありました。

とりあえず、目の前の住宅ローンと、その保険の月々10万ぐらいをがんばってはらってさえいれば、将来のことはそれほど心配しなくていい、というのはいいですね。 その日暮らしだと日々お金を数えないといけない。贅沢したいわけじゃないし、寿司は回っててもいいし、むしろビッくらポンの方が子供がうれしい。僕が仕事してお金を稼ぐのは「お金の心配を頭から追い出すため」です。 そしてその空いた頭で、本を書いたりしたい。論文を読んで実装とかもしたい。来年は処理系とかも作ってみたいです。

生命保険の計画は安心をどのように得るか、という計画なんだなってのがすごい実感できました。

明日はchezou氏です

ところで、今嫁がプライムビデオでウルトラマンネクサスの11話を見ているけど、これお子様向けなん・・・

本日より、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「で」説明する、という用途がガンガン増えていくと思っています。今後共よろしくおねがいします。

連載にあたっては、読者目線で徹底的に鹿野さんに文章を揉んでもらいました。当初よりも洗練され、だいぶ読みやすい内容になりました。また、タイトルも知恵を絞ってくださいました。セルフパブリッシングが来ると言われていても、きちんとした編集の方に見てもらうのは今の技術では替えられないものがあります。文章を書くということは、情報をギブするとともに、読者の方々の時間を頂く行為でもあります。その時間を少しでも有意義にしてもらえるために、内容も文章の質も高いに越したことはありません。本は十数冊関わってきましたが、まだまだ勉強させていただくことがたくさんありました。