舎路(シアトル)日記

シアトルで働く日本人プログラマの日記です。

blog.8-p.info のトップページは、いまも更新している日本語ブログと英語ブログ、さらに過去のブログに投稿した記事のタイトルとリンクを JSON にしたものを読み込んで、目次っぽく表示するようになっている。

このページを Nuxt.js 化したのは去年のはなしだけど、最近ここに D3 で GitHub 風のカレンダーを追加して、あわせて全体のデザインも刷新してみた。可視化してみると、日本語をメインで書いていた年と、英語をメインで書いていた年、ちょっと悲しいけれど徐々にまばらになる投稿量とかが一目瞭然で面白い。

Nuxt.js

Nuxt.js は去年に blog.8-p.info で使いだして、今年は 8-p.info のほうでも使いだした。

Nuxt.js, というか Vue.js の Single File Component は見た目が HTML に近くてとっつきやすいのが良い。

React を使っている Next.js とか、React + GraphQL の Gatsby も気になるけれど、数枚の静的ページにヘッダが共通で、くらいのものを書くのに .js の中に JSX を書くのは、個人的にはちょっと大げさすぎるように思う。

D3

D3 は定期的に使ってみては、しばらくすると完全に使いかたを忘れてしまうライブラリなのだけど、またがんばって使ってみた。

Thinking with Joins なんていわれるように、データと DOM とを “join” することで DOM の mutation を管理しようとする D3 と、HTML を毎回作り直して、差分を計算することで DOM の mutation を管理しようとする Vue, React 世代のライブラリとの間だと、思想的にちょっとぶつかるところがある。

探してみると、D3 + Vue.js とか、Vue のテンプレート側で SVG を生成する流派の人もいるけれど、私はそこまで Vue.js 愛が無い。今回は Watchers でプロパティを監視して、更新があったタイミングで D3 を呼び出すようにしてみた。

Material Design

「ここをクリックすると開きますよ」というのを +/- で表すのはあまりに90年代すぎるかなと思って、この部分は Material Design を参考に、V 字のアイコンを Font Awesome を使って表示している。

まとめ

Nuxt.js + D3 で自分のブログを可視化してみた。

  • Nuxt.js はヘッダとフッタを共通化する程度でも、JavaScript をあまり書かなくても便利
  • D3 と Vue や React を組み合わせるのは、思想や機能がぶつかるところもあるけど、なんとかなる
  • Material Design は UI カタログとしても使える

フロントエンド、仕事では最近あまり触らなくなってしまったけど、たまにやると楽しいですね。やっぱり絵が出るのは良い。

Q3 をふりかえる

Sep 30, 2018

Rust

英語ブログのほうは、Rust についてだけ書くことに決めてみた。

そのほかにも、rust-lang/rust に細々とした修正を送ったり (いまのところ8コミット)、RustConf のために8月にポートランドに行ってみたり、Seattle Rust Meetup にも何度か参加してみたり、Rust に割いた時間は多かった。

日本語ブログ

日本語ブログはテーマらしいテーマもなく書いている。

二つ目の記事がすごく読まれたのは良かった。

「あの人は言葉づかいは乱暴だけど根はいいひとで」「厳しさのなかにも優しさが」みたいな人物像は日本に限らないことだとは思うんだけど、この乱暴さや厳しさとかって別に必要ない、可能ならば取り除けるに越したことはないのでは、と最近は思う。

もっというと、私は 2ch 世代というか、直接的でともすれば乱暴なコミュニケーションを、新しくて効率的なものと思っていたきらいがある。そういうのは平成で終わりにしたい。

仕事

キャリアについて少し自覚的になれたことと、社内カンファレンスに参加したり講演の動画を見たり、といった時間を意識的にとれたのは良かった。

ミーティングで中断されがちなせいか、今日はこれだけしか出来てないのか、と思うような日が多いのは良くなかった。AWS 側の大物である Colm MacCárthaigh さんが

Unpopular opinion: to really make it as a senior/lead engineer, you have to get good at soaking up interruptions, only managing or minimizing them for others not yourself. You just have to adapt to working productively in smaller time slices and handling context switches. Tough!

なんて Twitter に書いていたのは、私がいまそれを心配するのは杞憂かもしれないけど、どんどん偉くなって時間を細切れにしていくのが目指すところなのかというと、それはちょっと違うよなという気持ちになった。 ‏

育児

妻と離れることを子が非常に嫌がるので、最近 (といってもここ数日) は寝かしつけを代わったりしている。母親なしで父親と過ごす時間を増やすことが、母離れの助けになるらしい。

Q4 にむけて

Q2 に書いていたポモドーロタイマーはまだ毎日使えるようになっていないので、これは完成させたい。

こういう中途半端なものは他にもいくつかあったと思うので、なにかを新しくはじめるよりは、色々を終わらせていく四半期にしていきたい。

キャリア近況

Sep 28, 2018

30代も折り返しに差し掛かりつつあるせいか、自分のキャリアというか、いままでと、これからの仕事について考えることが時折ある。

グローバル志向の先にあった平均化

日本にいた頃の私のキャリアには、ぼんやりとだけど、グローバル志向という軸があった。これは、ミクシィの社員として Facebook や Twitter といったアメリカ生まれのサービスが日本を席巻していくのをみていた、苦い思い出からきているのだと思う。

「日本人はインターネットに実名をのせたりはしないのですよ」「自分の近況を随一報告するなんて暇人しかやらないのでは」みたいな予測がどんどん裏切られていくのは『山椒魚戦争』みたいでちょっとコミカルですらあり、それ以来、私は日本人の特殊さというのを信じきれずにいる。

一方で、世界中から人々が集まって作ってるソフトウェアに、東京で日本語を話す人々が集まって作っているソフトウェアが勝つ理由もないなあという諦念もあった。数の論理。目玉の数さえ十分あれば、どんなバグも深刻ではない。同時期に普及しつつあったスマートフォンもその悲観を後押しした。

今になって思うとこれはだいぶ単純な世界観で、当時の私は視野が狭かった。ミクシィはその後モンストで復活するし、メルカリや LINE は日本を主な市場として成功している。製品が成功しなくても会社が成功することはあるし、会社が成功しなくても個人が成功することもある。もちろんその逆もある。

それでも、当時の (やや正確さに欠ける) 現状認識は危機感に、危機感は行動につながって、英語を勉強して、アマゾンジャパンに転職したりしていた。

外資企業を渡り歩く人々はそれなりにいる。日本以外をすべて「外資」とくくるのも乱暴なはなしだけど、投資銀行からアマゾンにきたり、アマゾンからグーグルに行ったり、そういうキャリアはそこまで珍しくもない。日本のスタートアップに入る人々はちょっと珍しくて、経歴から「元グーグル」という肩書がなかなか外れなかったりする。

日本にいたら次の転職はそれで乗り切れたかもしれないけれど、私は結局シアトルにまで引越してしまった。アメリカに来て現地の人々に紛れてみると、私のキャリアはとりたてグローバルといえるものでもないことに気づく。みんな英語はできるし、アメリカ以外の国で教育を受けたり、働いたりしたことのある人は珍しくない。

私は平均的になってしまった。

専門性とその軸

シアトルに来てから4年、何回かチームを移ったりもしたけれど、こうして振り返るとあんまり軸といえるものがない。社内でよく使われがちな技術スタックには詳しくなったし、よく質問したり調べたりしたとは思うけれど、得意を作るよりは苦手を減らす期間になっていたように思う。まわりの評判は悪くないし、all rounder として評価されることもある。でも、このままで良いのかというと不安がある。

そういったわけで、最近は “The Passionate Programmer” を読みながら、今後の方向性なんてものを考えたりしている。昔に “My Job Went to India” というタイトルだった頃に読んだ記憶があるけれど、久しぶりに読んでみると良いことが書いてある。

This book isn’t about struggling to maintain the level of mediocrity required not to get fired. It’s about being awesome.

かっこいいし、かくありたい。

morrita さんは以前に “Soft Skills” との対比を指摘していたけれど、一方で二つに共通する部分もある。自分の専門性を意識して作ること、というのはその一つだ。私はこれがまだ出来ていない。

私は他人の作ったスタックに過剰に肩入れして、インターネットで我田引水の議論を繰り広げる人々があまり好きではなくて、それを専門性をはっきりさせないことや、仕事で好きな言語を使わないことの、言い訳にしていたきらいがある。「製品の成功こそが重要であって、言語は重要でない」と言ってみせるのはかっこいいし、我田引水をする必要はないけれど、過剰な肩入れのリスクはリターンでもって報われることもある、という認識が薄かった。

最近 Rust の話をしたり、それがらみのイベントに行ったりしているのは、言語自体が好みというのもあるけれど、専門性をちゃんと作って、自分を周りから差別化しないと、という意識もちょっとある。

専門性はプログラミング言語に限らない。例えば、プロダクトマネージャーと組んでアプリケーションを作る仕事と、時系列データベースがメモリからディスクに書き出すのをどうこうするような低レベルな仕事のどちらを選ぶかという軸もあるし、国際化やアクセシビリティみたいな分野のうちどこを選ぶかという軸もある。交通や決済といった業界も軸になるだろう。

もちろん全てが出来たら素晴らしいけれど、それは無理そうなので、だんだん意識的に仕事を選ぶようにしたいなと思う。

エンジニアを育てるはなしが、たぶん以下の Takuto Kihira さんの tweet をきっかけに盛り上がっていた。

昨日の飲みで、某CTOが「エンジニアを育てるって言うけど、紀平さん誰かに育てられました?自分で育ったでしょ?だからエンジニアに対しては、頑張れ、としか言いようがないと思うんですよね」って話をしていて、まあ確かにそうだと思った。自分はしかし親に環境を用意してもらったな。本とかPCとか。

私の立場は、Dai MIKURUBE さんの tweet に近い。

エンジニアの成長について「自分は自力で育った」「今まで見てきた人は誰かに育てられたというより自力で育ってきてた」は観察としてたぶん真なんだけど、「だからこれからもそれでいい」は明確に偽だと思うんだよなー。それって各種の職人業が次々廃れてるのと同じことを再現するだけのような気がする

私自身も大学で情報工学を学ぶまえに多少はプログラミングができたほうなので、独学で「育った」傾向があるんだけど、後続の人々も同じパスを通るべきかといわれると、そうとは思わない。

性格や環境が私と似通った人だったら、同じパスを通ってもいいとは思う。本やインターネットから情報を集めて色々試すのは私にとっては楽しいことだったし、それをする時間的な余裕もあった。自分でやったんだという自負が自信につながっている部分もある。

ただ、世の中には自分とは違った性格や環境で、かつエンジニアを目指しているひとも沢山いるはずで、そういう人々には他のパスのほうが適しているかもしれない。いまの教育やコミュニティのありかたが、ある種の人々、たとえば女性を、不必要にフィルタリングしてしまっている可能性はあると思う。

Increasing Rust’s Reach

最近みて感心したのは、Rust というプログラミング言語の人々がやっている Increasing Rust’s Reach というプログラムだ。

This program matches Rust team members from all parts of the project with individuals who are underrepresented in Rust’s community and the tech industry for a partnership of three (3) months, from mid-May to mid-August. Each partnership agrees to a commitment of 3–5 hours per week working on a Rust Project.

ここでは、Rust チームのメンバーと、Rust コミュニティであまりみかけない (underrepresented な) 人々とをつないで、定期的なミーティングの機会や、カンファレンスへの渡航費の支援なんかを行っている。

“underrepresented” というのは明確には定義されていないけれど、今年の参加者 をみると、ジェンダー・人種・国籍あたりが考慮されているのだろうと思う。

Rust は比較的新しいプログラミング言語で、コミュニティを広げるまえに、言語やライブラリに対してやることがあるだろうという意見もあるかもしれない。ただ、コミュニティが大きくなっていくことは、結果として言語やライブラリに対して良いフィードバックがあるはずで、どちらも同時にやる必要がある (コミュニティについて働きかけるのは、余力ができてからやることではない) というのが今風の考えかたなんだと思う。

Recurse Center の Social Rules

もう少し草の根で、個人でも注意できるようなものには、Recurse Center の Social Rules がある。

Recurse Center はプログラミングができる人むけに、より学ぶための場を提供している施設ないしプログラムで、以前は Hacker School という名前だった。実際になにが行われているかについては、ニューヨークのエンジニアコミュニティについて。Hacker Schoolでプログラミング修行中 がわかりやすい。

Recurse Center の Social Rules は4つの禁止事項からなっている。

  • No well-actually’s (それは実は…で話を遮らない)
  • No feigning surprise (知らないんですか! と驚いたふりをしない)
  • No backseat driving (会話に突然割り込まない)
  • No subtle -isms (お母さんでも使える、みたいな微妙な差別をしない)

ここで禁止されているコミュニケーションのいくつかは、もしかすると、コミュニティによっては許容されているかもしれない。どこからがだめなのか、という線引きの難しさについては Recurse Center も自覚的で、Social Rules の冒頭には

One thing that often confuses people about the social rules is that we expect people to break them from time to time. This means they’re different and totally separate from our code of conduct.

という但し書きがある。

私も、勉強会なんかで、発表している人の話を突然さえぎって間違いを指摘する人がいても「勉強会は相互に学びあう場であるし、間違いを指摘されるのは別に恥ずかしいことではない」「モヒカン族から手斧が飛んできた」とかなんとか許容してしまっていたように思う。

あるコミュニティのなかでのコミュニケーション様式は、最終的には個々のコミュニティが決めるべきものだけれど、ある種の振る舞いを「あり」としたときに、それを苦手とする人々を遠ざけてしまう可能性であるとか、それと引き換えに何を得ているのか、といったことは立ち止まって考えてみてもいいと思う。

まとめ

エンジニアを「育てる」話を枕に、コミュニティのありかたを変えようとする、Increasing Rust’s Reach と Recurse Center の Social Rules を紹介しました。

後者については、自分が過去にできていたかというと大分あやしいけれど、最近は気をつけるようになりました。自分自身は、率直に物事を指摘する、勢いのある若手のつもりでいても、在籍年数を重ねるうちに、同じ振る舞いが想像以上に威圧的にとられてしまうこともあるので、みなさん注意しましょう。

すこし前に、Manning Publications から「こういう企画の持ち込みがあったんだけど、どう思う?」というメールをもらって、アンケートに答えるという機会があった。

Manning はアメリカの技術系出版社で、日本で翻訳書が出るときには、オライリージャパンをはじめ色々な出版社からでること、その際に表紙も変えられてしまうことも相まっていまひとつ存在感がないかもしれないけれど、jQuery の John Resig 自らが著者に名を連ねる Secrets of the JavaScript Ninja や、Keras の François Chollet が書いた Deep Learning with Python、ちょっと毛色が変わったところでは、higepon さんオススメの Soft Skills まで、手広くやっている。

技術系書籍の編集者の k16 さんは、英語圏のIT系技術書ブランドについての雑感

しかし現在は、この記事でも一押しの No Starch Press はじめ、やはり中堅どころの Manning Publications など、現時点で創業20年前後を迎えている中小の出版社のほうがむしろ精力的に面白い書籍を生み出している印象があります。

Manning を「中堅どころ」と形容している。

Write for Us

Manning のサイトには Write for Us というページがあり、Manning から本を出すまでのプロセスが詳細に説明されている。特に面白いのが最初に著者が提出しなくてはいけない企画の提案書で、そこには

  1. Tell us about yourself.
  2. Tell us about the book’s topic.
  3. Tell us about the book you plan to write.
  4. Q&A
  5. Tell us about your readers.
  6. Tell us about the competition.
  7. Book size and illustrations
  8. Contact information
  9. Schedule
  10. Table of Contents

という10個の項目について細かく質問がある。例えば Tell us about the book’s topic なら

  • What is the technology or idea that you’re writing about?
  • Why is it important now?
  • In a couple sentences, tell us roughly how it works or what makes it different from its alternatives?

Tell us about your readers なら

Your book will teach your readers how to accomplish the objectives you’ve established for the book. It’s critical to be clear about the minimum qualifications you’re assuming of your reader and what you’ll need to teach them.

こういった感じ。マッハ新書のような自費出版が話題をあつめる2018年には、すこし慎重すぎるような感じも否めないけれど、これで選別した企画にさらに編集者がついて質を担保するのが、インターネットで無料の情報が得られる時代に、出版社が担うべき役割だとも思う。

この提案書を送ると、Manning と外部の人々からのフィードバックが著者に送られる。

After we have had a chance to review your submission, we will send you feedback, both from us and from outside experts. As a rule, you can expect to revise your proposal several times during the discussions.

冒頭でふれた私が答えたアンケートは、おそらく、この “outside experts” からのフィードバックとして扱われるのだと思う。

まとめ

Manning というアメリカの技術系出版社についてと、その出版社が公開している企画提案書について紹介しました。

ちなみに、提案書を送ったあとの流れについてもシステマチックに流れが決まっていて、読んでみるとなかなか感心します。日本の出版社でも同じようなプロセスは決められているんだろうけど、私はそういうものを目にする立場にないので新鮮でした。

こういう質問を自問自答してみるのは、例えば自分でブログや YouTube チャンネルをはじめて、そのリーチを伸ばしたいときにも役に立つんじゃないかと思う。そこまでかっちりしたくないですかそうですか。