自分を攻略していく記録

自分がやりたいことを達成するには何をすればいいのか、その攻略していく過程をつらつらと

海外(ベトナム)でiPhoneをひったくられた話(盗難時のロックとか対処法とか保険とか)

iPhoneベトナムホーチミンでひったくられたのだが、いざそういう状況になると結構テンパるし、実際にひったくられる前から対策できることがあると感じた。ネットで「iPhoneの盗難にあった時にどうすればいいのか」みたいな記事はヒットするが、実際に盗難にあった人が書いているケースは多くなさそうだし、なにより「iPhoneを消去」コマンドまで実行している人はそんなに多くないと思うので記録しておく。

海外にいる時は、スマホはパスポートの次に大切なものになると思うので、なくした時に備えて準備をしておくのが大切だと実感した。

事件の流れ

12時30分頃

離れたところまで移動して昼食を食べようと思い、Grab(東南アジア版Uber; タクシー配車アプリ)を使って車を待っていた。その車が近辺まで来たので、歩道の限りなく道路よりで歩いていた。ちょうど別件でチャットが来たので返信していたところ、背後からバイクに乗った人にiPhoneをひったくられた。普段なるべく気をつけるようにしているつもりだったが、この時は気を抜いておりノーガードだった。すぐに走って追いかけたが、道がごみごみしており、路地に曲がられたところで見失った。隣にいた目撃者によると、「反対側の車線にいたバイクが急にUターンしてこっちにやってきたと思ったらiPhoneを盗んでいったんだよ」とのこと。

12時35分頃

バイクを見失ったあと、すぐにWiFiのあるところに入って、iPadの「iPhoneを探す」で、盗難にあった端末の位置情報検索を試みるが、すでにオフラインになっており位置情報分からず。返ってくる可能性はゼロだと思ったので、iPhoneを探すのオプションにある、端末の中に入っている情報を削除するリクエストを申請(下の画像)。この機能は、iPhoneに入っている情報をすべて削除して、アクティベーションロックをかけるアクティベーションロックがかかっている端末は、そのApple IDとパスワードを入れない限り何もできない携帯となる(文鎮となる)。デメリットとしては、それを発動すると位置情報が一切分からなくなってしまうこと。端末が手元に返ってくる可能性が低い時に実行する最終手段であると言える。ただ、万が一返ってきた時は自分のApple IDでログインすれば元通り利用できる。この時、盗まれた端末からApple IDをログアウトはしないほうが良く、Apple IDを残しておくと、アクティベーションロックが維持できる。

f:id:ngo275:20190802005016p:plain
iPhoneを文鎮化する最終手段

13時11分

iPhoneのデータ削除の完了メールが届く。30分強前に申請した削除リクエストが実行されたよう。申請した時は盗難にあった端末がオフラインだったが、盗んだ人が13:11に再起動してネットを掴んだ際に削除が実行されたようだ。

f:id:ngo275:20190802014642p:plain
iPhoneのデータ削除のメール通知

13時30分

盗んだ人が、奪ったiPhoneApple IDのログインを試みている旨のメール通知が届く。これが突破できないと、アクティベーションロックが解除できないので、誰も利用できない高価なハードウェア端末になってしまう。Apple IDを端末に残しておく限り、所有権が自分にあり、他の人が勝手に初期化して利用することもできない。

f:id:ngo275:20190802014524p:plain
Apple IDログインのリクエストの通知

13時〜14時30分

一緒にいたベトナム人の知人と警察に盗難届けを出しに行く。現場から徒歩5分ほどのところに交番があり、そこでいろんな書類の手続きをする。書類の手続きは思ったより煩雑かつかなりのマニュアルで1時間半もかかった。自分のパスポートや、知人のIDを控えて盗難届けを入手。これがないと海外旅行保険の携行品損害保険が利用できない。1つのアイテムあたり10万円まで保証されるのでiPhoneだと金銭的には大きな痛手にならずに済む。今回はAIGの保険に入っていたが、もしそういうのに入っていなかったとしても、クレジットカードの海外旅行保険でカバーされる。

f:id:ngo275:20190802020809j:plain:w400
盗難届けの手続きの様子

16時頃

手元にAndroid端末も持っていたのでそれを使って、Skypeで保険会社に電話をする。この通話は、5分で勝手に切れてしまったので、課金していない状態だと日本に海外から電話する場合5分まで無料で行けるぽい(?)。その後は友人の携帯で電話して保険の書類等をメールで送ってもらった。以前、中国・深センで入院して、保険を利用した時にも思ったが、メールのやりとりで完結したいところ。どうやら保険会社側は、メールだと届いているのか、迷惑メールとして処理されていないか等が不安なようだ。わざわざ10分も電話しなくても、メールだったら、テンプレを事前に作っておいて、コピペして、請求書のPDFを貼れば終わりだと思うのだが...。

今年中国に行ったときにも保険のお世話になっていた。海外旅行保険は大切...。せめてクレジットカードの海外旅行保険の確認だけでもしておくべき。

diary.shuichi.tech

iPhoneの端末自体の処理とその後のバックアップ処理で頭がいっぱいになっていたが、盗難にあったSIMカードのことを思い出す。香港で購入したiPhone XRだったのでデュアルSIMで、ベトナムのViettelのSIMと、中国のChina UnicomのSIMが入っている状態だった

ベトナムの方はプリペイドで、購入時にパスポートの登録もしていなかったため、同じ番号のSIMカード再発行ができず、この電話番号に紐付いていたZalo(ベトナム版LINE)のアカウントが闇へと消えてしまった。とはいえ、Zaloの他にこの番号を使っていたわけではないので、ベトナムSIMの被害はそこまで大きくはない。

ただ、今回の1件で一番ダメージが合ったのが、中国SIMの紛失だ。中国のSIMカードと銀行カードを持っており、支付宝(Alipay)はその両方を利用している。盗難直後の段階で支付宝にログインできていたのを確認したのだが、夜の時点でセッションが切れてログインが求められるようになっている。おそらく、中国SIMを他の端末で利用して、いくつかのサービスにログインしようとしたのだと思われる。支付宝にはパスワードがないと入れないと思うが少々不安。微博(Weibo; 中国版Twitter)は起動してみると、パスワードが変更されました、というポップアップが出てきて強制ログアウト。中国のアプリやWebサービスは電話番号認証しかないことがしばしばあるので、非常に危険だと判断して、China Unicomのアプリから電話番号の停止の手続きを行うことに。次に中国に行った時に現地でSIMを再発行して色々と作業をしないといけないと思われる。

中国SIMの停止方法

かなりマニアックだが、中国のSIMカードを紛失してしまって一時停止したい場合の方法をメモしておく。China Unicomのアプリを利用している。服务 -> 客服 -> 在线客服をタップする(一枚目)。次にテキストボックスに办理停机保号と打つと(2枚目)色々でてくるので、停机保号をタップ(3枚目)。「点我」の部分をタップすると4枚目のようになる。最後は、本人確認の6桁のコードを求められたが、登録をしたことがない人(今回も未登録)は、パスポートの下6桁になるようだ。

客服をタップ 办理停机保号と打つ 停机保号をタップ 月5元でサスペンドできる
f:id:ngo275:20190802022116p:plain:w250 f:id:ngo275:20190802022243p:plain:w250 f:id:ngo275:20190802022335p:plain:w250 f:id:ngo275:20190802022427p:plain:w250

雑感

東南アジアとかだと、道で携帯をいじるのは危険だというのは常識だし気をつけているつもりだったが、少し気を抜いている時に奪われたので結構ショックだった。その後の処置は、近くにいた友人がサイバーセキュリティとかの事業に関わっていたということもあり、的確なアドバイスをもらいながら対応できた。自分1人だったらApple IDのログアウトをして情報を断とうとしていたと思う。「iPhoneを削除」を行うと、アクティベーションロックという呪文によって誰も利用できなくなるというものこの時に教えてもらった。逆にApple IDを切断してしまうとこの呪文も解けてしまう。誰かの手に渡ったiPhoneで自分のApple IDがハックされたら怖いと思っていたが、冷静にiCoudのサイトから自分のアカウントが乗っ取られるリスクと同じなので大丈夫そうである。どこにあるか分からない僕のiPhoneは、第三者が利用できないただのハードウェアになっており、その利用方法が気になる。何も知らない人に高値で売られるのか、解体してパーツを売るのか、脱獄してリセットするのか。資源の観点から言うと、自分のApple IDを切り離して、誰か他の人がそのデバイスを利用できるようにした方が良いという見方もある。

盗難SIMの方も面倒で、日本のSIMを紛失してしまった場合、日本に帰るまでいろいろなサービスが利用できなくなってしまう。ただ、手元に日本のSIMが残っていたものの、今回は格安SIMで海外ローミングできない状態だったので、LINE等いくつかのサービスにはアクセスできない。WhatsAppやLINEはラップトップアプリを入れてログインしておけば、紛失してもログイン状態を保つことができたはずなので、アプリをパソコンでも利用しておけばよかった少し後悔している。パソコンでそういうチャットツールを入れていると気が散ると思ってあえて入れていなかった。

データに関しては、盗難に遭う日の朝に最後のバックアップの記録があり、新しいiPhoneApple IDでログインするとほぼすべてのデータが復元できた。写真も一枚も失わずに済んだ。また、2段階認証のアプリを、Google AuthenticatorからAuthyに移行もしていたので、紛失したあとも特にアプリの2段階認証で詰むことはなかった。

海外にいる時は、スマホはパスポートの次に大切なものになると思うので、なくした時に備えて準備をしておくのが大切だと実感した。

まとめ

盗難に気をつけるのももちろんだが、普段から対策しておくと大惨事にはならないので、以下のことを行っておくとよいと思った。

※以下iPhoneを前提とする

事前にしておきたいこと

  • iPhoneを探す」は絶対にオンにしておくべき
  • Apple IDは2段階認証をオンにしておくべき
  • Google AuthenticatorよりもAuthyなど複数端末で利用できるようにしておくべき
    • 2段階認証するための端末が1つしかないと、それを紛失すると詰む
  • データのバックアップは取っておく
  • スマホのケースで、指を入れれるリングのやつをつけておくべき
    • ひったくり難易度が跳ね上がる。今回もそれをしておけば防げた事故。
  • 日本で格安SIMを使っている場合は、海外ローミングのオプションを確認して可能であれば有効化しておく
    • そもそもデフォルトがオフになっており海外でSMSを受け取れない。
  • LINEとかは複数デバイスでログインしておいたほうが良い
  • (中国のSIMは中国以外で利用する時はSIM PINでロックした方が安全...??)

起こってしまった時の対応

  • iPhoneを探す」を使う
    • 落としてしまったとかで見つけられる可能性があるなら「紛失モード」にする
    • 盗難とかで善良な人が拾ってくれる可能性がないなら、「削除」をする
  • 焦ってApple IDのサインアウトをしない
    • iPhoneを削除」が適切に実行されていれば自分の情報は安全かつ、その端末を第三者がリセットすることもできない。
  • SIMカードを止める
  • 警察に届け出を出す
    • たとえ見つかる可能性がないにしろ、保険で必要になる。
  • 保険会社に連絡する
    • クレジットカード付帯である可能性大。

参考リンク

support.apple.com

プログラミングの勉強をする前に知っておきたかったこと・知っておいてほしいこと

forやifを使ってプログラムを書いて、そのファイルを実行すると記述したことが実行されるで、それがどうやってゲームやアプリになっていくのか

大学生の頃に授業でJavaプログラミング言語)の課題を解いていて、ずっとそう思っていた。 if文for文プログラミング言語における基本的な文法)で簡単な数学の問題が解けても、それが一体どうやってゲームになったり、Webサービスやアプリになるのか全く検討がつかなかった。プログラミングの細かい文法だけ勉強しても全体感が全く掴めなかったので、結局その授業では大した理解が得られなかったのである。このような「プログラミング自体の勉強はやってみたけど、で、それで?」って現象は割とあるあるなんじゃないかなと思う。今となって思うのは全体感を掴まずに細かい文法を勉強をしてしまったのが原因だと思っている。

そうなってしまった当時の自分が知っておきたかった、と思うことを書いていく。具体的には、以下のようなこと。

  • ソフトウェアにおいて、プログラミングがどこでどう利用されているのか
  • 「プログラミングの勉強」と言うけど、自分が取り組みべきことは一体何なのか

以前、以下のブログを書いたが、このようにがっつり勉強しだす前に知りたかった内容にした。

diary.shuichi.tech

時間をかけることで結果的にプログラミングの全体感が分かったが、時間をかけないと難解だと思った。プログラミングを勉強してみたいという非技術職の人も含めこれからプログラミングを勉強してみたいと興味がある人にも参考になればいいなと思う。ただ、機械学習等の研究の文脈におけるプログラミングは、計算のツールの色が強く用途が異なる。ここではソフトウェア開発の領域におけるプログラミングについて考えていく。

TL;DR

  • 「プログラミング」はモノづくりのごく一部に過ぎず、プログラミング言語そのものよりもその背景にある考え方が大切
  • 非技術系の人がソフトウェアの理解のためにプログラミングを学ぶのは遠回りの可能性大
  • プログラミング学習には、「何か作ってみると良い」と言われて、どうしていいのか分からなくても大丈夫。できる人に、ブレイクダウンしてもらおう
  • 規模感によってエンジニアリングの役割は変わってくるのでそれを踏まえてインターン・転職先を探してみよう

ソフトウェアにおいて、プログラミングがどこでどう利用されているのか

プログラミングの教科書で出てくるような基礎的なプログラムと、実際にWebやアプリで動いているプログラムは結構異なって見える。プログラミングの教科書に出てくるようなプログラムは非常にシンプルで、偶数と奇数を判別するプログラムだったり正直使いみちがピンとこないケースが多い。一方で、Webやアプリは先人達のプログラムが何層にも積み重なった上に自分たちのコードを書いていく。雛形プログラムが存在し、そこに自分でカスタムしていくイメージになる。

では具体的にどんな感じでソフトウェアが構築されているのかかなりざっくりと見ていく。

ここではInstagramを例にとってみる。

InstagramはWebサイトとアプリ(iOSAndroid)の3つの利用方法がある。

f:id:ngo275:20190614013306p:plain:w600
InstagramのUI

ユーザが触れるWeb、iOSAndroid、これらを引っくるめて「フロントエンド」と呼ぶ。フロントエンドでは、フォローしている人の画像や動画、ストーリーを画面に表示する。Webやアプリの画面を表示するためには、データを取得しなければならないが、そのデータ取得の窓口になるのが「サーバ」と呼ばれるヤツだ。画面を更新しようとするとWi-Fi等を通じた通信が必要になるが、それはサーバにデータを問い合わせているからである。

f:id:ngo275:20190614020444p:plain:w600
流れ 1/2

次に、サーバはデータベースから必要な情報を検索する(Instagramほど巨大なサービスになるとこんなシンプルな構成ではないが、イメージはこんな感じ)。サーバは、自分がフォローしている人の画像や動画、コメントといった情報をデータベースから取得し、フロントエンドに返却して、フロントエンドはそれを画面に表示する。フロントエンドに対比して、サーバやデータベース等を引っくるめてバックエンドと表現される

f:id:ngo275:20190614020506p:plain:w600
流れ 2/2

大きな流れは上記の通りだが、これらの各登場人物の内部でそれぞれプログラミングが利用されている。プログラムが実行される環境には、iOSなのか、Androidなのか、Windowsなのか、様々なモノが存在し、プログラマはそれに応じてプログラミング言語を使い分けている。いろんな言語を習得している、と聞くとハードに感じるかもしれないが、日本語(標準語)をマスターすると関西弁や博多弁はなんとなくできるのと同様であるケースが多い(もちろん言語によるが)。

登場人物 言語 備考
Webフロントエンド JavaScript、HTML、CSS HTMLとCSSは厳密にはマークアップ言語と言われる
iOS Swift、Objective-C 最近はもっぱらSwiftが一般的
Android Kotlin、Java Kotlinが最近は人気
サーバ Java、Go、RubyPythonPHP、いろいろ JavaJavaScriptは全くの別物
データベース SQL 厳密にはプログラミング言語ではないけど分類のイメージ的にはここ

たとえば、ストーリーの機能を追加しようと思った時、Webフロントエンド・iOS・Androindでストーリーの画面に関するプログラムをそれぞれのプログラミング言語で書いておき、サーバ側もストーリーをフロントエンドに返却する窓口を作っておく必要がある。データベースに関しても、ストーリーを保存するための空間を確保する必要がある(こういったデータベースの変更をマイグレーションと呼ぶ)。それぞれのプログラミング言語で機能開発をすることになる。気をつけたいのは、Ruby on Railsのようなフレームワークだ。フレームワークとは、プログラミング言語とは違い、モノを作る上で頻繁に必要になる機能を集めた便利ツールである。Ruby on Railsは、Rubyというプログラミング言語を使って、簡単にWebサイトが構築できるが、Webフロントエンド、サーバ、データベースアクセス等全てがいい感じに処理されるようになっているので、それぞれの登場人物の関係性がよく分からなくてもそれぽくなってしまい、システム内部の理解がかえって難しいので注意が必要だ。

ソフトウェアエンジニアは、プログラムを書いたら、次に、各プラットフォームにそのプログラムを配置する必要がある。プログラムを書いて、それをアップロードして、ユーザからの入力(クリックとか)を待ち受けておくようにするのだ。Webサイトだったら自分でインターネットにプログラムをアップロードしてユーザからのリクエストを待ち受けるようにしておけばいいのだが、iOSAndroidの場合はユーザにアプリをインストールして貰う必要がある(Instagramのアプリを利用する時はApp StoreGoogle Playを通じてインストールをしなければならない)。このように、プログラムを各プラットフォームにセットする作業をデプロイと言う(英語で配置という意味)。

デプロイが完了すると、ユーザがそのサービスを利用できるようになり、ユーザ数の増加に応じて、機能の追加や、バグの修正をしていくことになる。その都度、プログラムを書いて、サーバなりにデプロイする。iOSのアプリをアップデートすると機能が増えていることがしばしばあるが、それは新しい機能の入ったプログラムをダウンロードしたからである。

ここではInstagramを例にとったが、ハードウェア(IoTとか)でも同様で、プログラムを実行するためのチップと電源があればそのチップにプログラムを焼いておくことで、好きなプログラムをハードウェア上で利用することができる。例えば、チップ(Arduinoとか)に温度計センサーを付けて、28度を超えると冷房のスイッチをオンにするというプログラムを書いてチップに焼いておくと、電源が供給されている限り、そのプログラムは実行される。

f:id:ngo275:20180505001828p:plain:w600
GPSを組み合わせたマイコンのイメージ

「プログラミングの勉強」と言うけど、自分が取り組むべきことは一体何なのか

プログラミングの勉強をしたいけど何をすればいいのか、としばしば質問されるが、これは難しい…。どうやってプログラミングを勉強するのか、といった方法論はネットでたくさん引っかかるしオンライン講座も充実しているので比較的どうにかなりやすいが、何を勉強するのか、という質問は難しいと感じる。

f:id:ngo275:20190619000313p:plain:w600
プログラミングはソフトウェアのごく一部の要素に過ぎない

上で書いてきたようにプログラミングがどこで利用されているのか見てみると、「プログラミング」はWebサービスやアプリといったソフトウェアを作る上で、部分的なものに過ぎないのが分かる。それを踏まえた上で、プログラミングの勉強について考えてみる。

技術系ではない人が技術のことの理解のためにプログラミングを勉強したい場合

技術系ではない人がテクノロジーのことをより理解するためにプログラミングをやってみるのはとても良いことだと思う。ところが、プログラミングの文法や書き方が分かることは、システムがどう動いているのかの理解にそこまで繋がらないのが正直なところだ。大学でプログラミングの課題が出た時はまさしくこの問題に直面した。「で、だから何?」問題だ。「AI、機械学習といえばPython」、「Web開発といえばRuby」といった流れでプログラミング言語を勉強してみるケースを見かけるが、それでAIやWebの仕組みを理解するのは到底厳しい。

プログラミングの勉強は、言ってみれば、公認会計士試験の勉強をするのと同様だと思っていて、ソフトウェアエンジニア(会計士)になりたいなら必須だが、テクノロジーやシステムの内部(財務諸表の読み方やファイナンスの仕組み)を学ぶためにプログラミング(公認会計士試験)を勉強するのはちょっと違うアプローチに感じる。監査業務はできないが、財務諸表を見てビジネスの様子が想像できる人は大勢いる。プログラミングも同様で、コーディングはできないが、アプリがどう動いていてどう作っていけばいいのか知っている人も大勢いる。エンジニアではない人が、エンジニアになりたくてプログラミングの勉強するのでない限り、プログラミングをやる必要性はそこまでないと思う。

f:id:ngo275:20190619000656p:plain:w600
プログラミングから始めるのはなかなか厳しい

学ぶのであれば、プログラミングより先に以下のような項目かと思う。

  • プログラミングの背景にある思想。プログラミングに重要なのはプログラミング言語そのものよりその背景にある考え方であるUNIXという考え方ーその設計思想と哲学という本が勉強になると思う。「オブジェクト指向」と呼ばれる思考方法も学ぶとプログラマの頭の中が分かるようになる。

  • ソフトウェア開発のフロー。アジャイルウォーターフォールの概念や、その違い。スクラム開発の概念等。実践はともかく、考え方については書籍(スクラム実践入門)から学ぶことができる。要件定義から始まって、仕様に落とし込み、タスクとして細かく落としていき、デプロイまでする。と言ったような流れが分かると普段ソフトウェアエンジニアと呼ばれる人が何をしているのかが分かる。

  • データベースについて。ER図や簡単なSQLの使い方等。ER図とは、データベースの設計図のようなものである。描けるようになる必要はないが、プログラミングをする上で重要なオブジェクト指向の概念に触れることができるし、普段触っているアプリが、どのようにデータベースに記録されているのか、ということはすごく勉強になる。それに関連してSQLやBigQueryを使った分析方法も知るとビジネスに生きてくる。ソフトウェアを提供している会社は必ず分析ツールを導入しており、自分たちのサービスがどれくらいどのように利用されているのか常に分析している。SQLやBigQueryはデータベース検索のための特殊な言語だと思えばよい。

  • APIについて。フロントエンドはサーバにデータを問い合わせるが、APIと呼ばれるインターフェースがその間に存在するのが一般的だ。サービスによってAPIの仕様が異なっており、システムの内部を理解する上で非常に勉強になる。昨今は銀行APIというワードが流行っているが、APIを理解しておくとそういう技術的なテーマも腹落ちしやすい。これに関連してJSONと呼ばれるフォーマットも知っておくと良いと思う。実際に暗号通貨の取引所が公開しているAPIを見て勉強すると面白いかもしれない。

  • (参考)UIUXについて。Webデザイナーが利用するようなデザインツールまで使える必要はないが、Googleが提唱しているマテリアルデザインや、Appleが提唱しているHuman Interface Guidelines等にも目を通しておくと良い。日本語訳もググればあるはず。

  • (参考)Gitフローについても知っておくと良いかも知れない。プログラマはGitと呼ばれるバージョン管理ツールでソースコードを管理するのが一般的だが、そのコンセプトが若干慣れにくい。スプレッドシートは複数人で編集可能だが、ソースコードも同様に複数人で編集可能で、それを簡単にするのがGitである。

これらのことはソフトウェアエンジニアだとプログラミング以外に求められる基本的な要件でもある。これらを理解してさらに追求したくなったらプログラミングを勉強していけばいいと思う。プログラミングの背景にある考え方が重要なのであってプログラミング言語そのものが重要なわけではないということに気をつけてほしい。

ソフトウェアエンジニアなるものに興味があってプログラミングの勉強をする場合

この場合は、プログラミングの勉強はもちろんだが、上で書いたようなことも学んだ方が良い。

プログラミングの勉強をしたいなら、何かモノを作りながら学ぶのが一番。という意見もよく聞くが、そもそもどういうモノがどれくらいの難易度で作れるのか分からない人にそうアドバイスするのは手厳しい感がある。すでにそういう作りたいモノが思い描けているのであれば良いのだが、思い描くだけでも意外と難しいのも事実。プログラミングが分かる人に、作ってみたいものや何ができそうなのかを話してみて、それに必要となる技術や難易度をブレイクダウンしてもらう(全体感を示してもらえる)のが良いと思う(周りにそんな人いないよ、という方がいましたらTwitterで連絡いただければ話を聞きます)。何を勉強すればいいのかが分かったら、あとは、Progateやオンライン講座で勉強していけば良いと思う。

大切なのは、ソフトウェアエンジニアの人が知っておくべきことはプログラミング以外の要素が想像以上に大きくて、プログラミングだけできてもダメだということ。僕は初めそれを知らなくて、プログラミングだけ勉強したが、結局良く分からなかった。

プログラミングを勉強した先について

ソフトウェアエンジニアに興味がある人が、プログラミングを勉強したとして、その後にどういう選択肢があるのか少し深掘りしてみる。フロントエンドとバックエンドに分けて説明したが、会社やプロジェクトの規模によって、個人がどこまで関与するかでエンジニアがやるべきことや求められることも大きく異なってくる。

  1. 数人規模の開発

  2. 十数人~数百人規模の開発

  3. 数百人~の開発

1の場合は、新しいサービスのアイデアのプロトタイプを作ったり検証、立ち上げのフェーズ。この規模感では、1人がやるべき領域が広くなり、SwiftでiOSアプリの開発をしつつ、サーバをGoで書く、と言ったこともある。大量のリクエストをうまくさばくと言うよりは、トラブルに柔軟に対応しつつ、最速でデプロイすることにフォーカスする。

2の場合は、ユーザがある程度付いてきて、サーバダウンもなく、多くのリクエストに対応できるように開発するステージ。新機能開発だけでなく、バグ修正、リファクタリングソースコードのお掃除)、テスト、とまんべんなくリソースを割かないといけない。1人が担う仕事が特化してきて、サーバの開発をする人はサーバ、フロントエンドを開発する人はフロントエンドにフォーカスするのが一般的。もちろん、スキルの幅が広いソフトウェアエンジニアであれば、人が足りていないところを柔軟にカバーする動きをすることはある。1の場合と比べて各領域に対してより深い知識理解が求められる。

3の場合は、SEのイメージになる。降りてきた仕様に対して納期までに完成させるのが最重要項目になる。個人に求められる技術力はそこまで高くはない。

1、2、3のどれがいいのかは個人の性格や好みによるところが大きいと思う。また、1から3のように他のセグメントに移動するのはそこまで楽なわけではない。余談だが、給与に関しては、実力主義だが給料が良いのは2で、スタートアップでリスク(そもそも会社がなくなるとか)があるものの上場や売却を狙うなら1、といったところ。3は昔ながらの人海戦術的なソフトウェア開発といった印象で、ちゃんとした場所を選ばないと結構大変そうなイメージである。

初心者からエンジニアとしてのキャリアを探すのであれば、こういった選択肢があるのを踏まえた上で、インターンシップ探しや、転職活動をするのが良いと思う。知人経由やTwitter経由でインターンシップを探したり転職先を探すケースはたまに見かけるが、必ずしもそういう人が周りにいるとも限らないと思う。そういうケースではWantedlyが一番良いのかな、と思う。現に、僕が正社員として初めて入社した先に連絡した媒体はWantedlyだった。当時、バイトの求人もなかったが、その会社や事業に興味があったので、とりあえず連絡してみて、面談をしてバイトをさせてもらえることになった。

www.wantedly.com

まとめ

プログラミング学習についてつらつらと書いてきたがまとめると、

  • 「プログラミング」はモノづくりのごく一部に過ぎず、プログラミング言語そのものよりもその背景にある考え方が大切
  • 非技術系の人がソフトウェアの理解のためにプログラミングを学ぶのは遠回りの可能性大
  • プログラミング学習には、「何か作ってみると良い」と言われて、どうしていいのか分からなくても大丈夫。できる人に、ブレイクダウンしてもらおう
  • 規模感によってエンジニアリングの役割は変わってくるのでそれを踏まえてインターン・転職先を探してみよう

ブロックチェーンまわりの技術本を書きました

2019年3月にKADOKAWAからブロックチェーンプログラミングのためのコンピュータサイエンスがわかる本という本を出版した。内容はプログラミングの基礎的な話から最後はBitcoinやEthereumの内容について踏み込んでいく、というもので共著での執筆だった。5章立てで僕は最後の章(Ethereumについて)をメインに担当した。諸事情があり4章(Bitcoinについて)もほぼ大半を執筆した。

執筆のきっかけは大学の友人経由で話をもらい、そこで「やってみるか」という感じで引き受けた。当初50ページほどという話だったので、1ヶ月くらい週末や平日の夜に時間を割いて執筆をした。結局、コラムだったり5章以外の修正等を行ったのでその後もちょくちょく時間を割いた。

本の構成

CHAPTER1: コンピュータ基礎

データ構造とアルゴリズム、CPUの仕組みなどを扱う。

いきなりメモリの話とかになるので、完全にプログラミング初心者だともしかすると少し圧倒されてしまうかもしれない。逆にすこしかじったことがある人だと心地よいくらいの難易度だと思う。

CHAPTER2: 暗号とセキュリティ

共通鍵暗号公開鍵暗号ハッシュ関数、デジタル署名などを扱う。

ブロックチェーンに限らず、インターネット関連のニュースとかで目にするようなセキュリティ周りの話。公開鍵と秘密鍵の関係だったり、ハッシュ化の仕組みだったり。

CHAPTER3: ネットワーク

プロトコル、HTTP通信、Websocket、P2P通信などを学ぶ。

ブロックチェーン以前に分散型データベースの「分散型とは」といった内容も触れるので個人的にも学びが大きい章だった。

CHAPTER4: ブロックチェーン応用(Bitcoin編)

Bitcoinを題材に、ブロックチェーンの仕組みを学ぶ。

CHAPTER5: ブロックチェーン応用(Ethereum編)

Ethereumを活用したアプリケーションの開発を学ぶ。スマートコントラクトを用いたアプリの仕組みを理解する。

執筆に際して実際に簡単なアプリを作ったが、そのコードが以下のリポジトリ。Vue.jsでWebのフロントエンドを実装して、SolidityでEthereumのスマートコントラクトを書いてある。

github.com

感想

今回は初めての本の執筆で、なおかつ共著だったが、思っている以上に大変だった。共著でも各人のパートが完全に独立しているなら良いのだが、今回はそこまで独立していたわけでもなく、5章ともなると1~4章をしっかり考慮しないと、情報の過不足だったり、本の難易度が急に変わってしまう。例えば、Ethereumで利用されているマークルパトリシアツリーというデータ構造が1~3章のデータ構造の部分で解説されていたっけ?みたいな感じ。

あとで辛い思いをしないように最初にちゃんと構成を考えたり、なるべくあとで修正しやすいように気をつけたり、他の人のレビューを受けて修正したりと、複数人でプロダクト開発をしているかのような感覚で、ある種の面白さがあった。本の執筆もプロダクト開発と通ずるところがあるな、と。と同時に、本を出すことのハードルが非常に下がってきているようにも感じた。有志で好きにウェブサービスを作って公開できるようになったのと同様に、本もそれに近い状態になってきているんだろうと思った。紙媒体だと在庫の管理やお金周りの観点から少し骨が折れるが、Kindleのような電子書籍だとかなりハードルが低くなっている。MyISBNを使えば、個人で出版社を通さずとも紙の本を出版できるらしい(使ったわけではないので詳しくはわからない...)。

何はともあれ、出版までできてよかった。少しプログラミングかじったことがある人だとちょうど良いくらいの難易度になったと思う。

ウェブサイトを作る時に便利なサービスたち(ロゴ生成、LP作成、画像引用とか)

リモートワークをしている時に作業場・カフェ難民になりがちで苦労したので、コンセントやWiFiつきのカフェを探すサービス「Nomady」を作った

その時にクリエイティブ周りで苦労したので利用したサービスをメモしておく。

作ったサービスはこちら

nomady.work

LPはこちら

mailchi.mp

ロゴの作成について

何か作り始めるにあたって最初に必要なのがロゴ。CrowdWorksでロゴの作成をお願いすることもできるが価格のイメージは以下のような感じで、個人でお試しにやってみるには若干高いと感じなくもない。安くても2万円。

f:id:ngo275:20190428100020p:plain:w500
CrowdWorksのロゴ作成の価格感

前々から無料で簡単にロゴを作れるサイトを探していたのだが、最近見つけた面白いのがBrandMarkというやつ。タイトル(サブタイトルも付けれる)と関連するタグを入力すると勝手にそれっぽいロゴを大量に生成してくれるサービスで、他のロゴメイカーに比べてバリエーションが非常に豊か。cafe、nomad、mapとかで試したら以下のアイコンが勝手に出てきて感動した。「cafe」のようなわかりやすいタグを入れるとそれなりの精度で生成されるようだった。ただし、アイコンジェネレーターではなくあくまでロゴメイカーなので注意。

f:id:ngo275:20190428223455p:plain
BrandMarkの生成物

次に、試しに自分の名前を入れてみた。Tシャツや名刺に入るとこんな感じだよ、という画像も出てきて面白い。価格的にはそのアイコンの画像データを落とすには25ドル(3000円弱)でアイコンの変更等他の要求もあれば65ドル、175ドル、というプランもある。簡単に利用したいだけであればスクショだけでもどうにかなってしまうのだが...。

f:id:ngo275:20190428100803g:plain:w600
BrandMark

BrandMarkのリンクはこちら(再掲)

app.brandmark.io

ランディングページに関して

通称LP。ユーザーが初めて訪れるサービス紹介のページのことで、大体のサービスにはつきもの。いろいろなLPメイカーが存在するが、個人的にはMailChimpというメール管理サービスが提供しているLP作成機能が簡単で良かった。プログラミングとかも一切触らずにサイトの公開まで済ませられる。デメリットとしては、公開される時のドメインがMailChimpのものなのでカスタムドメインをセットするには年間99ドルかかる、ということ。また、無料版だとサイトの一番下にMailChimpのロゴが入ってしまう。

他にもUnicorn Platformといういい感じのサイトもあるが、これは生成したLPのHTMLやCSSJavaScriptをダウンロードする形式なので、自分でそれらのファイルを配置する必要がありエンジニアリングの知識が多少求められる。

f:id:ngo275:20190425203851p:plain:w500
MailChimp

MailChimpで試しにLPを作ってみたのが下のような感じ(再掲)。1時間くらいでできた。

mailchi.mp

商用可能な無料画像について

いい感じの画像を差し込みたいときはO-DANをよく利用するが、今回もLPの画像をここで検索した。32個のサイトを横断的に検索でき、それなりの数の写真がヒットするのでオススメ。

o-dan.net

f:id:ngo275:20190428100328p:plain:w500
O-DAN

他にも2018年の後半に少し話題になったAIを使った顔生成サイトも面白い。人の写真を使うときは以下のサイトで生成したものを使うと良いかもしれない。ただ、日本人に絞るのが難しい...。

www.thispersondoesnotexist.com

iOS関連

今回作ったのはWebアプリだが、iOSアプリを開発した時に利用したものもメモしておく。

iOSアプリ開発をする時のアイコンはicon8がいい感じ。アプリでよく見かけるようなアイコンが揃っているので便利だし、料金も無料。

icons8.com

iOSアプリが出来上がって、いざリリースをしようとすると、App Storeに乗せるイメージ画像が必要になるのだが、これが意外と手間だったりする。チームにデザイナーがいればいいが、個人で開発している場合はなおさら手間になる。

f:id:ngo275:20190428221349j:plain:w300
App Storeで出てくるプレビュー画像

StoreScreensというサービスが良さげで、アプリでApp Storeの載せる画像(スクリーンショットと呼ばれるやつ)を作成できる。

f:id:ngo275:20190428224737p:plain
StoreScreensのイメージ

中国の深センの病院を退院して無事帰国しました。(医療搬送とかお金とか海外旅行保険の話)

2019年の2月16日に深センで肺気胸にかかって現地の病院で丸1週間入院した。 詳細については以下に書いたとおり。

diary.shuichi.tech

無事帰国できたので、その際の医療搬送や、海外旅行保険、お金周りについて書いておく。

保険の選択

短期で海外旅行に行くときは、わざわざ保険に入らない人も多いのではないだろうか。少なくとも自分はそういうタイプだった。

2018年に何の前触れもなく気胸になってからは、急病のリスクを考慮して、海外旅行保険が手厚くカバーされている(と思われる)アメックスのクレジットカードを発行しており、今回はアメックスのクレジットカード付帯の海外旅行保険を利用した。

カードによって自動付帯のものや利用しないと発動しないものがあるので要注意。

海外旅行保険利用までの流れ

最初に病院に着いて診察して入院が確定したあとに、クレジットカードの裏に書いてある電話番号に電話をかけて、「中国で病気になって入院することになったので保険を利用したい」という旨を伝えた。たしか日本時間の夜22時半くらいだったと思う。24時間のコールセンターを持っているので、夜中に電話をしても対応してもらえる

保険会社に自分が利用している病院を伝えると、後は向こう側が病院に問い合わせて病状や今後の医療方針について確認してくれた。また毎日のように病状や保険の詳細について電話でやりとりをした。メールでのやりとりもあったのだが、こちらがメールで返すとメールで返信が来るのではなく電話で連絡が来たのが不思議だった。メールだと既読かどうかがわからない、と言った理由があるそうだ。

重要な論点として、同じ病気の再発であれば保険対象外になる、ということがある。今回の病気は右肺の気胸なのだが、昨年左肺の気胸を発症しており、再発とみなされると保険の適用外になってしまうので、日本の医師に再発かどうかの問い合わせたりと確認作業があり、保険の適用可否についてはすぐに分からなかった。幸いにも、今回のケースは再発ではないと判断され(右と左は関係ないので当たり前ではある)保険適用になったが、場合によっては降りないケースもあるので注意が必要だ。

クレジットカード付帯の海外旅行保険の実態

クレジットカード会社が持っている海外旅行保険の中身について少し深ぼってみる。各クレジットカード会社は海外旅行保険をサポートしているが、実はアメックス付帯の海外旅行保険でもVisaの付帯のものでも、EAJ (Emergency Assistance Japan)という日本の上場企業が実際のサービスを提供している。お金の負担自体はアメックスやVisaなど保険を扱っている会社が行うのだが、現地の医師とのコミュニケーションや、コールセンターそのものはEAJが行っているのである。クレジットカードの裏に書いてある24時間のコールセンターとは、EAJのコールセンターのことを指す。言い換えると、僕の場合アメックスの保険だが、実際にやり取りしていたのはEAJの人であるということだ。

f:id:ngo275:20190228220213p:plain:w500
EAJと保険会社の関係(参照:https://emergency.co.jp/service/remedy/insurer/ )

入院する病院が、EAJが提携している医療機関(世界で1700ほど; 2019年2月時点)である場合は、キャッシュレス診療になり、患者はお金を払わず保険会社が代わりに払ってくれる。ここでのキャッシュレスは電子マネーとかクレジットカード払いということではなく、お金そのものを出さないという意味である。保険会社が払ってくれるのだが、厳密には、EAJが病院側に対して一旦建て替え、手数料分を上乗せしてアメックス側がEAJに支払っているのである。

今回お世話になった病院は提携外の医療機関だったが、うまくEAJの中国人スタッフの方に話をまとめていただき、キャッシュレス診療になった。スタッフは世界の各地にいるそうで、今回は广州という深センから2時間ほどのエリアから来てくださった。

かかったお金

実際に診察してから退院までにかかった金額は、4000元程度なので7万円未満だった。実際は自分でなくアメックスが払ってくれているのだが。アメリカだと桁が1つ違ってくるのかもしれないが深センの病院は思ったより安い。もし手術をしたとしても日本の3割負担の額より少々高い、程度だった。

この治療費の負担は、疾病治療費用保険金と呼ばれる。ところが、今回保険に助けられたのは、救援者費用保険金だった。この救援者費用保険金とは、現地まで救援に来てくれた人の負担をカバーしてくれるものである。これが適用される条件は保険によって異なるが、アメックスの場合は、7日以上の入院が対象になるのでちょうど対象になった。

一般的に肺に何かしら疾患があった場合は、飛行に乗るのが制限され、航空会社にも断れる。今回のケースでは、帰国まで1ヶ月飛行機を控える必要があり、それより早く帰国するには医療搬送で飛行機に乗る必要があった。この医療搬送も、救援者費用保険金でまかなうことができた。医師・看護師と同伴で酸素や緊急用の医療器具とともに飛行機に乗ることで、発症から2週間後、退院から一週間後に帰れることになった。医師と看護師を日本から深センに呼んで一緒に帰国することになるので、自分で手配すると数百万円はかかってくるのだが、今回は保険でこれがまるまるカバーされたのが救いだった。

まとめると、保険でカバーされたのは、病院で発生した一切の金額(ただし、食事代は除く)と帰りの交通費(医療搬送)の大部分。交通費ついては少しややこしく、もともと保険なしで帰国する際に発生したであろう、深センから家までの飛行機代・電車代・バス代は自分で払って、それ以外の医療搬送の分等は負担してもらえた。

帰国までの流れ

早く帰りたいという旨を伝えていたので、保険会社(おそらくEAJ)の顧問医師が推奨しうるする最短の日程で帰国することになった。EAJが飛行機の予約や医療搬送の手配をしてくれ、そこで初めて自分の帰国日が分かった。

帰国当日は同行してくれる医師と看護師が滞在中のホテルのロビーまで来てくれ、深センから香港空港行きの専用のバンで移動した。EAJの現地の中国人スタッフもそれに同行してくれた。この時に同行してくれた看護師さんは、50を超えてからイギリスの大学院に行ったり今は旦那さんと開業されていたりと、アクティブな方で、どうやら東大の看護科でチアリーダー部だったらしく珍しい出自の方だった。

今回は医療搬送ということで、客室乗務員(や訳ありの人も?)ゲートから出国手続きを行い、列に並ぶことなく搭乗エリアまで到着した。

f:id:ngo275:20190228224205p:plain:w400
出国ゲート

飛行機では全く違和感がなかったわけでもないが、幸いなことに大きな問題もなく、無事に自宅まで帰ることができた。

みんな海外旅行保険はちゃんと確認しておこう

中国の深センで入院してしまった話

最近何かと話題な深センそんな深センで急遽入院することになってしまった。英語も全く通じずかなり苦労した。もともとは東南アジアに行こう、と思っていたが、通り道の香港・深センに寄り道した矢先のことだった。

f:id:ngo275:20190217230120p:plain
深センのとある大学病院の一室

気胸

2018年の春に二度左の肺気胸にかかり手術もした。この(肺)気胸という病気は、肺に穴が開くもので、肺の外に抜け出た空気が肺を圧迫してしまい、放って置くと肺が潰れて最悪の場合心臓に圧がかかりショック死することもある。痩せ型の若い男性に多く、特に春に発生しやすいらしい。二度発症したあと、手術したので完治したと思っていたが、今回発症したのは右側だった。右も左も気胸になってしまった。

肺に異変を感じる

深センの街中(@小米之家)で買い物をしている時に、下においてあるものを見ようとかがんだ際に肺がグググっとなって痛みを感じだした。以前体験したことがある感覚だったのでおそらく気胸だろうなとすぐに感じた。あとは、時期的にも、香港・深センは日本の5月くらいの気候だったので春っぽさもあり気胸の可能性をより一層感じた。一応、気のせいであることを期待して少し様子を見たが、どうやら痛み・違和感が引かないのですぐに病院に行くことにした。とは言え病院の検討もつかないので、深センに住んでいる中国人の友達に、SOSを送った

会話の様子① 会話の様子②
f:id:ngo275:20190217234828p:plain:w300 f:id:ngo275:20190217225927p:plain:w300

その日に会う約束すらしていなかったのに、連絡してからすぐに返信が来て「タクシーで向かうからこの病院に来て」と言ってくれた。返信も早くてすぐ対応してくれる感じがたまらない。タクシーを捕まえて病院に向かって、無事に彼と合流できた。

はじめての海外での診察

f:id:ngo275:20190219101406p:plain:w400
やたらカジュアルな診察エリア

この病院には、診察室という診察室がなく、広間に5~6個机があって各机に1人担当医がいる、という感じだった。週末だからそうなっているだけなのかもしれないけど。そこで軽く症状について話したあと、レントゲンのフロアに向かった。この時、医師とのコミュニケーションは、ローカルな病院に来てしまったせいか全く英語も通じず、友人がすべて通訳をしてくれた(彼は英語はペラペラで日本語も少し話す)。

f:id:ngo275:20190217231145p:plain:w500
レントゲンの待合室

レントゲンでは、日本で受ける時と全く同じ姿勢を取らされて、「ここはどこでも同じなんだ」、とふと思った。ただ、レントゲンを撮った後は、レントゲンのデータが出来上がるまで待合室で待つ、というプロセスがあった。できあがったデータを自分で発行して、次の場所に持っていく。

このレントゲンを医師が見ると「気胸ですね」と言って、呼吸器の先生が登場してそのまま引き継ぎ。なるほど、カジュアルな診察スペースでポンポン回していい感じに患者を振り分けているようだ。合理的。

そのまま入院

気胸と言われた時点で入院ということは覚悟していたが、案の定入院することになった。ただ、そこまで重くない容態だったのでメスを入れずに安静にするだけで済んだ。もし悪化したら次の日メスを入れて処置をしようと言われた。

気になるお値段だが、レントゲンを取る前に200元(3400円程度)の支払いをして、レントゲンを取り終わった後にもまた支払いをした。日本で入院した時は、最後にまとめてすべて清算したが、この病院では初めのカジュアルな診察の直後に支払いプロセスが挟まったのが意外だった。また、入院の手続きをする時にデポジットで3000元(約5万円)を払った。まるでホテルのよう。でも一泊は大体150元(約2500円)程度らしい。手術をする場合でも日本の3割負担の値段より少し高い程度で思ったより安かった。クレジットカードはアメックスが利用できなくてVisaを使おうとすると銀聯カードだけ、と言われて友達が建て替えてくれた。中国に行く時に銀聯カードはあった方が安心かもしれない。クレジットカードの保険で保険会社がいい感じに払ってくれて自分はお金を出さずに済ませる方法もあるが、この病院は対象外だったのでそれもできなさそうだった(保険は後述)。

支払いの仕方については、画像のようなマシンで医師から受け取った紙についているバーコードを読み取ってAlipayやWeChat Payで支払いができた。クレジットカードも使えるようだったが、病院内に、WeChat Payの広告とかもあってモバイル決済を推奨していた。日本で入院したときも同じようなマシンで簡単にクレジットカードで支払いができたので、ここでは中国スゴイとはならなかった。

f:id:ngo275:20190217234705p:plain:w400
支払い機

その後は病室で夕飯を食べたり入院のための準備をした。入院の手続きではいくつか同意書を書かされたが、これは日本でもここでも同じような感じだった。

医師が何かあったら連絡してくれ、と友達にWeChatを教えていたのがびっくり。日本の感覚では、患者の付添人に医師がLINEを教えるような感じだろうか。

時間も21時半を回っていて、夕飯が何もなかったので饿了么(フードデリバリーのサービス、日本のUberEATSと同じ感じ)で出前を頼んだ。普通に配達員が病室までやってきたのにも驚いた。面会手続きとか、入室できる時間の制約とかないんかい、と。

病室の様子

日本で入院した時と病室の様子は大体同じような感じだったが、トイレットペーパーがないのと、シャワーの水回りがひどくてとても使う気にならなかったのが違う点だった。大衆点評でティッシュを頼んだが、デリバリーの人が病室まで来てくれてティッシュを届けてくれた。こういうアプリが病室から使えるのでコンビニに自分で行く必要すらなかった。

入院した次の日に、「お昼ご飯は何時ですか?」と聞いたら、「出ないからデリバリーなりで手配して」と言われてしまった。これじゃただの素泊りだ。。もし中国の電話番号を使えなかったら饿了么も利用できないしホントに詰んできたかもしれない。中国において電話番号はパスポート・ビザ(とはいえ観光なら特に不要)の次に重要な気がする

後は患者の数自体が少なく、ヨボヨボの高齢者がほんとにいなかったのもびっくりだった。平均年齢が20代と言われるくらい若い街であるというのを痛感した。平日になると見舞いに来ている人が増えて、非常に声が大きく騒がしかった。

自分の部屋が2つベッドがあり隣にもうひとり患者が来たが、ベッドを仕切るカーテンがないことに気づいた。その人の友だちは一日中いるし、何ならそのまま寝泊まりし始めた。カーテンがないからかめっちゃ絡まれる。でも、イヤホンなしに動画見るし話し声が大きいし、いびきもうるさいし、急に日本の病院が恋しくなった。日本ではヒソヒソ話す人もいるくらい静か。

f:id:ngo275:20190219101522p:plain:w400
患者の友達が寝始めた

都内で入院した時は、担当の看護師さんが変わるたびに挨拶に来て様子を伺いに来てくれたが、深センではそういうのもなくほとんど放置だった。たしかに日本の看護師さんは優しすぎると言うかもう少し雑に扱っても大丈夫なのに、と思ってしまう。

病棟に監視カメラが多く設置されていて、地下にいくとセキュリティルームで警備員たちが映像を見ていたのも中国っぽさがあった。セキュリティルームの扉が全開で外から監視カメラの映像まで丸見えだったけど。

保険の話

お金については上でさらっと書いたが、意外と安くて安心した。とは言え出費は出費で辛いので、クレジットカードの保険を利用することにした。アメックスカードの保険を使うために、カードの裏に書いてある電話番号に電話をかけた。保険に関して伺いたいと伝えると、電話代がかかるだろう、ということで向こうから折返し電話をくれ、そこで状況を詳しく話した。帰りのチケットまで含めカバーされるようでアメックスサマサマである。アメックスの保険の提携がある病院であれば、キャッシュレス診療ができるそうで、お金は一切出さずにアメックス側が負担してくれる。ただ、今回はローカルな病院だったのでそういうのはなかった。

去年も急に気胸になったので、こういった自体に備えてクレジットカードの保険について知っておいて良かったと思う。額が大きければ他のカードの保険も併用を考えるが今回はアメックスだけでカバーできそうだったのでそれだけにしておいた。

雑感

今回は、病院選びから、医師とのコミュニケーション、お金の建て替えなど、現地の友達にすべて助けてもらってどうにかなったが、1人だったらかなり厳しかった。たしかに、日本人や海外の人ががかかるような病院に行けば言語でここまで困ることはなかっただろうが、実際に症状が出た時はそんなことを考えるゆとりもなかった。言語についてはホントに英語が通じなかった。ベテランの医師は簡単な英語が通じたが、中堅クラスの医師とはコミュニケーションが大変で自分の容態についても自分だけでは聞くこともままならなかった。ましてや看護師はほぼ話せないので見回りに来て調子を聞かれても苦労した。

今となっては、なかなかできない経験だし、いい経験になったと思えるが、もし助けてくれる人やちゃんとした病院がない地域だったら、と思うと恐怖である。旅行は好きだし病気になったからと言って控えるつもりはないが、友達はちゃんと大切にしようと強く思った。ピンチになった時に助けてくれる人がいるのは生きる上で最も大切。

P.S.

肺の病気なので1~2週間は飛行機に乗れませんが、帰ったら再発リスクを除くために手術をする可能性が高く、3月はまた都内で入院しているかもしれないのでかまってください。

追記

  • 無事帰国しました。

diary.shuichi.tech

  • 保険を使っていい病院に行けばこんなローカルな思いはしなかったようです。

2019年ももう1ヶ月経ったので振り返っておく

ざっくり振り返り

仕事の他に、人に会ったり、機械学習とかインプットに時間を割いたり、英語の訓練をしたり、といったところ。地味に毎朝1TEDを心がけてるのが続いてるのは良かった。あとは去年の後半に書いていた書籍がやっと落ち着いた。詳細はここで見れるようになった(3月中旬発売らしい)。

www.ted.com

年末まで中国にいたが、ゆっくり実家で過ごすと、今まで気づかなかった色々な気付きがあって地味に刺激的だった。特に中国で見たものが横浜の実家近辺だと当たり前のようにないのだ...。常にまわりに好奇心を持っていると、いつも気にしていなかったことが、目について考えるようになった

一方で2019年も1ヶ月が経ってしまうが、まだ何もしていないという感覚があって焦ってはいる。シンガポールのビザ待ちの状態で、それも自分のコントロール配下にないので打つ手がなく精神的にじわじわくる、というのがある。何よりも、年始に立てた目標に対して何もできていないのが辛い(ビザの関係で難しいというのもあるが...)。

仕事的な話

1月末からシンガポールのビザが下りて現地のスタートアップで働いている予定だったが、ビザが出るのが長引いており、結局2月3日現在も横浜の実家にいる。とはいっても1月頭からその会社でリモートワークをしており、実家とか都内の適当な場所でノマドワークをしている。2年前まで1年ほど浅草のホステルに住んでいたので、久しぶりにそこに泊まって浅草をフラフラしたりもしてた。

f:id:ngo275:20190203122657p:plain:w400
浅草・雷門

「リモートワークをしてる」と言うと羨ましがられることもあるが、実際やってみると思ったより気分が上がらない。雑談する相手がいる、質問できる人がいる、というのはオフィスに行く大きなメリットだと痛感する。また、新しい会社のSlackにも入っているが、まだ小さい組織ということもあり、口頭でのコミュニケーションが多いようでSlackで情報を完全に追うことができないという難しさもある。結局タスクをもらってそれをさばいていくだけの人になってしまう。当初リモートワークも1ヶ月くらいの予定だったので良いかな、と思っていたが、2月ももう少しリモートワークが続きそうなのでちょっと萎える。リモートワークしたい時はできるけど普段はオフィスに行く、くらいのリモート度合いが精神的に優しい気がする。

今はフロントエンドエンジニアとしてReactを触っていて、具体的にはReact、ReduxAtlaskitrecomposeredux-sagaあたりを使っている感じ。ReactにはいくつかUI系のライブラリがあるが、Atlaskitは個人的には品揃えが良い点が気に入った。よく使うコンポーネントが豊富に準備されているので、デザイナーが不在でも一般的なデザインに仕上げやすいと思われる。

読書メモ

読書をするよりぼーっと考え事をすることが増えたが地味に何冊か呼んだのでメモ。

  • ファクトフルネス

    • 自分の世界に対する認識がいかに時代遅れになっていたのかを痛感できた。チンパンジークイズというのを見て全部わかるなら読む必要もないけど、自分の場合はチンパンジー並の正答率だった。
  • The Culture Map

    • 色んな国籍の人と働くために役に立つ知見が得られる。ストレートにネガティブなフィードバックを与えるのが当たり前な文化圏もあれば、日本のように遠回しに伝える文化圏もあるので、そういった文化の違いを知らずにプロジェクトを進めるとコミュニケーションミスが起こるよね、という話だった。
  • 言語処理のための機械学習入門

    • 機械学習をバリバリ研究していた友人から薦められた本。自然言語処理の基礎となっているアルゴリズムを学ぶためには一番の良書だと紹介された。確かに丁寧に説明されていたが、いきなり数学の話がガンガン出てくるのでしっかり数学を学んでいないと詰むな、という感想。勉強になった。正直ここにある内容を知らずにブラックボックスのまま自然言語処理のライブラリを使うことは可能だが、アプリ開発がここまで簡単になってきている中、そういったアルゴリズムが分かってなおかつ作れる人が今後求められていくんだろうな、と感じた。
  • お金の流れでわかる世界の歴史

    • ローマ帝国オスマン・トルコ帝国などこれまでの文明や帝国の裏では経済がどう動いていたのか、という側面から世界史を覗けて面白い。戦争するにもファイナンスが必要で、それができなかったナポレオンは結局負けてしまったのだとか。現代のビジネスも全く同様に良いものを作るためにはお金をちゃんと集められる力が必要なんだなと歴史から学べる

まとめ

2019年に向けて準備に1ヶ月かけてしまったという感じ。目標に対して何もできないのは思っているよりもきつい...。

シンガポールのGO-JEKとGrabのエンジニア求人を受けた話

はじめに

11~12月あたりにシンガポールのGO-JEKとGrabのiOSエンジニア求人を受けてみたのでその時のことを書いていく。これらはそれぞれインドネシアシンガポール発のユニコーンである。

f:id:ngo275:20181231211330p:plain:w400
GO-JEKとGrab

シンガポールのエンジニア転職情報はまだまだ少ないが、アメリカに比べビザも圧倒的に取りやすいしアリだと思う。

結論は、GO-JEKとGrabではない、他のアーリーステージのスタートアップ※にジョインすることにしたので、GO-JEKは後半の方で辞退、Grabは普通に途中で落ちた。

※ ここでは触れていない会社です。

英語やビザの話はここでは触れずに、実際にどういうことが聞かれたのか日程感はどんな感じなのか、という話にフォーカスする。海外で働いてみたいけど面接ってどんな感じなんだろう、どういう準備をすればいいのだろうという人の参考になれば良いなと思う。LinkedInのプレミアム機能で、求人に応募している人がどのエリアから来ているのか見ることができるのだが、インドからの応募がめちゃくちゃ多いのが分かった。シンガポールの求人に対して一番応募しているのがインドなことが多い。日本からもっとガツガツそういうところに出ていく人が増えるといいなと思った。

TL;DR

  • 英語はコミュニケーションできるくらいには必要だけど、営業できるレベルまで求められない。
  • アメリカ英語のような慣れ親しんだ英語ではないと思ったほうが良い。
  • 時間がかかる。平気で1ヶ月とかかかる。シンガポールに限った話ではないと思うが、思ったより時間がかかるのだなと実感した。面接はどれも平日の日中に行われたが、正社員で働きながらだとかなり大変そう。
  • アルゴリズムというよりは、アーキテクチャやテストといった実践的なことが重視されているように感じた。

GO-JEKを受けた記録

⬇参考までに、ここに一般公開されているGO-JEKの採用フローが書いてある。

blog.gojekengineering.com

11月中旬 応募する

LinkedInの求人からGO-JEKの採用ページに飛んで、そこで自分でペイメントのiOSエンジニアを応募してみた。

Resume(履歴書)はこのサイトで作成した。ちゃんと作っておくべき。

11月23日 最初の返信が来る

応募の返信が23日に返ってきた。応募してから返信が来るまでに一週間もかかってないとは思うが記録がなくて正確にはわからない。

Hi Shuichi,

Greetings from GO-JEK Group! I was hoping I could set up a 30-minute call between you and our team, to discuss the opportunity a bit. Would you mind letting me know some times you're available over the next few days?

We usually have the call through Google Hangouts / WhatsApp call, but kindly let us know if you have preferences.

We're looking forward to speaking with you. 

軽く30分くらいコールしましょう、ということだったので、いついつが開いてるよ、と20分後に返信した。

その日のうちに、Googleカレンダーで招待が来て27日にコールすることになった。

11月27日 最初のコールをする

エンジニアではなく採用担当と思われる女性の方とコールをした。お互い自己紹介をした後、会社や求人のポジションの説明を受けた。それに関して質問をしたり、という感じ。これで落ちることはないと思われる。

この後、2日間かけてやってほしい課題を送るので時間を確保できる時にメールをしてくれ、と言われた。多分何かを作る課題だろう...。

11月30日 技術課題を行う

この日とその翌日はまるまる時間が確保できそうだったので、朝9時半過ぎに、課題を送ってくれと催促した。その30分後くらいに以下のような返信が来た。

Hi Shuichi,
Good morning, thanks for the reminder. 

Before we move forward to the next process, allow us to present you with a challenge. Please find attached in this e-mail a problem statement for you to solve.

...中略

Ideally, it should take you 2 days to solve this. So if you can send it to us no later than Sunday, 2 December 2018, we would really appreciate it so that we can begin the review process faster. 

Please let us know if you have any urgent matter and need more time for complete the test or have any question regarding the test. We will be more than happy to help you out.
Can't wait to see your great work. 

添付されていたPDFに仕様とデザインが書いてあり、それに従ったアプリを作る、というものだった。その仕様やデザインについてはここでは伏せるが、iOSアプリを好きにMVVMなりMVPなりで設計して実装、それに関連してUIテスト、ユニットテストを書きなさいという感じ。APIについては彼らがHerokuで立てたものを利用する。

2日間でこれを実装できる人いるのか?という量だったが、とりあえずざっくりと機能を実装して、QuickNimbleを使ってドメイン周りとバリデーションに関してユニットテストを書いた(UIテストは画面数も少なかったので気持ち書いたくらい)。時間が足りず、デザインは一部断念した箇所もあったが、12月1日の日付が変わる頃(12月2日の0時過ぎ)にメールで提出した。

機能で言うと一応仕様通りにできてはいるが、デザインが一部当てれていなかったり、実装ミスでネットワークエラーの表示がうまくいかない状態だったので少々不安...。

12月7日 技術課題の結果が来る

コードを提出したのが土日で、コード見るから少し待っててね、と3日月曜の朝に言われて、7日にメールが来た。技術面接に進むので日程を教えて欲しいということだった。どうやら技術課題はパスしたらしい

この後、技術面接の日程調整の連絡をして11日に行うことになった。

技術面接はしたことがない + 馴れない英語での説明、ということだったので以下のようなリンクを参考にして勉強をした。

Glassdoor

Glassdoorというサイトで他の人が実際に受けた面接内容とか色々見れる。

ソートや探索のアルゴリズム

このGitHubのリンクがiOSエンジニアのアルゴリズム勉強には最強だと思う。クイックソートバブルソートの実装、バイナリツリーの実装など良く耳にするアルゴリズムはできるようにしておいた。このリンクにはたくさんの情報が載っているが、その中でも聞いたことあるが不安というところだけ確認した。

iOS開発について

iOS自体のライフサイクルと、ViewControllerのライフサイクルは以下のリンクで確認した。なんとなく分かっていたが、英語でちゃんと説明はできなかったのでいい復習になった。

以下で、普段なんとなく利用しているパッケージマネージャについても一応確認しておいた。Static LibraryとDynamic Libaryの違いとか。

12月11日 技術面接のコールをする

シンガポール人とインドネシア人がそれぞれリモートで参加して自分を含めて3人でコールをした。英語はシンガポールなまりとインドネシアなまりで結構辛かった。

以下iOSエンジニア前提で質問されたこと

日本語で見ると普通の内容に見えるけど英語でやると結構難しく感じた

  • 参照型と値型について教えて
    • 変数がポインタであるか、値そのものを持つか。たとえば、クラスは参照型なのである箇所で中身を変更すると、同じモノを参照している他の箇所の変数の値が変わってしまう。一方で、構造体は値型なので同じモノを参照していた他の変数に何も影響がない、的な話をした。Reference type just has its reference, while value type has value itselt instead of reference. みたいな英文になってしまい説明になってなくね?って自分で思って少々焦り、クラスと構造体を引き合いに出して説明した。
  • 強参照・弱参照について教えて
    • 強参照はReference Counterにカウントされるが、弱参照はカウントされない。ViewControllerがお互い参照する時は、弱参照を使わないとお互い参照しあってメモリリークする、みたいな話をした。
  • 先の技術課題で採用したアーキテクチャ(ここではMVP)について説明して
    • Viewはユーザからのイベントを受け付けてPresenterに伝え、Presenterからの通知を受けて描画する。重要なのはロジックを持たないようにすること。PresenterはUIロジックを主に担当する。ビジネスロジックは持たないようにして、必要に応じてモデルに処理を移譲する。Modelはビジネスロジックを主に担当し、API通信や端末のキャッシュアクセスとかはこの階層で行う。といった説明をした。
  • クリーンアーキテクチャの経験あるならそれについても教えて
    • MVPの特にモデルについてUseCase、Repository、Datastore、Entityと細かく分けることによってそれぞれの責務を明確にした感じ。UseCaseはビジネスロジックに集中し、データアクセスの詳細については関与しない。こうすることによって、モック化しやくなり、ビジネスロジックについてのユニットテストが容易になる。というフワッとした説明をした。
  • クリーンアーキテクチャでデータはどう扱うの?(具体的にどう聞かれたかは覚えていない...)
    • domain層からpresentation層にデータを渡す時はトランスレータを噛ましてUIが扱いやすいように変換する。また、APIからのデータはEntityを使ってマッピングするが、Entity自体はメソッドを持たないただのイミュータブルなオブジェクトとして扱う方が好き、という話をした。
  • (先の技術課題のコードを見ながら)この部分(Presenterが保持しているModelをセットする関数をPresenterのinit以外で実行可能になっている箇所)の意図を教えて
    • イニシャライザ以外で変更可能なのは嫌だったけど、Presenterについてのユニットテストを書く時にモデルのモックをセットする用にやむを得ずそうした。時間があったらそこの部分を直したかったんだよね。と話した。時間的制約から仕方がない、と思ってさぼっていたところを突かれた。コメントくらいつけておけば良かった。
  • (先の技術課題のコードを見ながら)この部分(Protocolで重複している箇所)をBaseProtocolみたいにして抽象化するのは考えなかった?
    • 可能ではあるけど、Base〇〇という親クラスみたいなものを作る方針が好きじゃなかったからそうしなかった。重複量が多いなら考えるけどここはそこまで大きくならないところなのでこのままにした、これは好みの問題かもしれない、と話した。
  • (先の技術課題のコードを見ながら)この部分(PresenterやModel用にそれぞれProtocolを宣言している箇所)の意図を教えて
    • PresenterやModelに対してユニットテストを書く時に、Presenter・ModelのProtocolを採用したモックを使うことで、ユニットテストを簡潔に書けるようになるから。DIをしたかった。という回答をした。

一部覚えていないが概要としては上記のような感じだった。自分の回答に対して深ぼるような感じだった。ここではライブコーディングはなかった。

こっちから質問したこと

  • ストーリーボードは使う?使わない?
    • これは本当にチームによる。ストーリーボードを使わないところもあるね。
  • 開発スタイルはアジャイルなの?
    • そう、チームによるけど俺は2週間のスプリントだよ。
  • タスク管理はどうしているの?
  • デザイナーとはどういうコミュニケーションをするの?
    • (たしかZeppelinでもらってやってると言っていた気がするが、)とりあえず普通だった記憶だけある。
  • 2日間の課題って結構仕様重かったけどみんな終わるの?

あとは少し雑談をしつつ計1時間弱のコールで終わった。

12月12日 技術面接の結果が来る

技術面接の結果に関するメールが来た。パスしたようだ。

そして次の技術面接のラウンドを行うから開いてる日を教えてくれ、と。技術面接はあと1~2回あるらしい。長い...。この時点で最初に応募してからすでに一ヶ月が経とうとしている...。

12月18日 技術面接2ラウンド目を行う

ネットの調子がめちゃくちゃ悪かったのと家のすぐ隣で工事をしていて騒がしかったこともあり、開始して10分程でリスケすることになった。

この時の相手はインド人2人だったのだが、マジなインド英語は初めてだったので最初ホントに何を言っているのか分からなかった。

10分程度だったが、質問されたのはこんな感じ。

  • UIのライフサイクルについて教えて
  • 描画の流れについて説明して
  • UIWindowとUIViewの違いは
  • LayoutIfNeededの呼ぶタイミングは?

前回と違って今回はライブコーディングもあるようだったがネット環境がひどすぎてその前に終了した。

辞退の連絡

他で並行していたスタートアップからオファーをもらっており、そちらに行くことにしたので、リスケの日付が確定する前にGO-JEKの方を辞退することにした。小さいスタートアップを選ぶことにした。

Grabを受けた記録

11月28日 応募する

Stackoverflowで見かけてGrabのiOSエンジニアの求人に応募してみた。

12月4日 最初の返信が来る

完全に忘れた頃にメールが来て、とりあえずコールをするので開いてる日を教えてくれという趣旨だった。その2日後の12月6日にコールをすることになった。

12月6日 軽いコールと技術課題と行う

お互いの自己紹介とポジションの説明とかとりあえずそんな感じのコール。GO-JEKの時と同様に軽い感じのコールだった。

その後にコードテストのリンクを送るからやってみて欲しいとのこと。

Codilityというサイトで行う。

app.codility.com

ちょうどこの日は時間があったのでそのまま受けてみた。

Swiftを使って、設問があってその条件を満たすコードを書く、というもので2問で制限時間は45分だった。GO-JEKより全然軽い課題だったが、2問目が意外と難しくて途中で力尽きた。簡単な引数だとうまくいくけど、エッジケースではfailする感じの出来栄え。

12月7日 技術課題の結果が来る

普通にできなかったから終わりかと思っていたが、次の技術面接に進む、というメールが来た。こちらの予定の確認なしに13日にカレンダーの招待が来ていた。まあ空いてたわけだけど。

12月13日 技術面接をする

技術面接の案内のメールにTipsに関するYouTube動画のリンクが張ってあった。

www.youtube.com

技術面接の所要時間は、1時間のラウンドが2回で計2時間でアルゴリズムについてと、iOSドメイン知識についてだった。

アルゴリズムについて

  • バイナリツリーのdepth(heightだったかも)の算出方法を教えて
    • ここにあるのを思い出しながら、自分の下に何もノードがない時は1を返して、下にノードがある時は、左側と右側のノードで大きい方と1を足して返す関数を再帰的に呼ぶ、と答えた。
  • [ライブコーディング] じゃそれを実装してみて
    • 以下のように答えた記憶はあるけどdepthとheightを間違えて答えたかもしれない。ちなみに以下のコードはdepthではなくheightの実装。
class BinaryTree {
  var left: BinaryTree?
  var right: BinaryTree?
  var parent: BinaryTree?

  func height() -> Int {
    if left == nil && right == nil {
      return 0
    } else {
      return 1 + max(left?.height() ?? 0, right?.height() ?? 0)
    }
  }
}
  • その計算量はどれくらい?
    • n個のノード全部を走査するからO(n)、と答えた。
  • [ライブコーディング] バイナリツリーのdiameterの実装をしてみて
    • diameterとは、あるバイナリツリーにおける最長距離のことらしいが、初耳だった。あるノードを取った時に左サイドのノードのheightと右サイドのノードのheightを足した値を各ノードで計算しその値が最大の時に最長経路になる、と答えてその実装をした(ここでは厳密に覚えていないので割愛)。でもそうすると計算量が非常に大きくなってしまうよね、という指摘をされた。それに対してどう対応するのかを見られたが、明らかに小さいものは計算しないようにしたいけど具体的な計算方法はその場で実装できない、といった感じだった。

iOSドメイン知識について

  • strong、weak、unownedについて教えて
    • strongはReference Counterにカウントされるが、weakとunownedはカウントされないのでweakとunownedはすぐ解放される。weakは解放されるとnilを返すが、unownedは解放された状態でアクセスするとクラッシュする。と説明した。
  • Retain Cycleについて教えて
    • 恥ずかしながらこれについては英語で分からなくて、ちょっと分からないと返してしまった。循環参照のことだった。Circular Reference的な名前だと思ってたからなんだろうってその場で困ってしまった。循環参照も知らないやつってなってしまったかもしれない...。
  • DIについて教えて
    • コード自体を抽象化しておいて、外から変数とか具体的なものを注入すること。これによってテスト時にモック化が容易になるというメリットがある。と答えた。
  • [ライブコーディング] セクションヘッダーにFruit、Vegetable、Drinkのラベルを入れてそれぞれのセクションには["Apple", "Banana", "Lemon"]、["Carrot", "Lettuce"]、["Beer", "Water", "Tea"]のラベルをUITableViewで描画する時の実装をして
    • 以下から書き始める感じ。正直細かいメソッド名( func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { )とかは覚えていなかったので、うろ覚えで進めた。IDEじゃなかったので補完が一切ない環境でのコーディングだった。普段Xcodeを使っていると、補完で細かいメソッド名までは覚えていない人が多いだろうし、間違っていてもXcodeが教えてくれるが、ここではそれがなかったので何をテストしたかったのかイマイチピンとこなかった。とりあえずオーソドックスな実装をした。
struct Fruit {
  var data = ["Apple", "Banana", "Lemon"]
}
struct Vegetable {
  var data = ["Carrot", "Lettuce"]
}
struct Drink {
  var data = ["Beer", "Water", "Tea"]
}

class ViewController {}

12月17日 技術面接の結果が来る

結果はダメだった。循環参照知らないって言ってしまったくらいだから仕方ないと思おう。

まとめ

  • 英語はコミュニケーションできるくらいには必要だけど、営業できるレベルまで求められない。
  • アメリカ英語のような慣れ親しんだ英語ではないと思ったほうが良い。
  • 時間がかかる。平気で1ヶ月とかかかる。シンガポールに限った話ではないが、思ったより時間がかかるのだなと実感した。面接はどれも平日の日中に行われたが、正社員で働きながらだとかなり大変そう。
  • アルゴリズムというよりは、アーキテクチャやテストといった実践的なことが重視されているように感じた。

とにかくインド人はこういった戦いをひたすらしており、日本人ももっとチャレンジする人が増えるといいなと思っった。

上海に行ってきたけど想像以上にグローバルだった

今は次にやることに備えてフリーランスという名のほぼニート状態なので、時間がある今のうちにということで、観光がてら上海に行ってきた。2017年の7月にも行ったのだが、その時はほとんど観光もできなかったので今回上海らしさを感じることができた。

想像以上に綺麗な街並み

上海の南京西路エリアらへんを散策したが、かなり整っていて街が綺麗だった。東京でいうところの表参道のような感じ。物価はバラツキがあるものの綺麗なところに行くと東京より高い。汚いお店に入ると安いのだが、一定以上だと東京の方が安い状態。こっちに住んでいる日本人に話を伺ったところ、物価や地価は東京より高いし、子育てもこっちの方がもはや良いのだとか。子育てが忙しい中、フードデリバリーやタクシー配車サービスがない生活が想像できないと言われたが完全に納得。

2017年の12月にオープンしたロースタリーのスターバックス(詳しくはこちら)にも行ってきた。スターバックスの平均的なサイズと比較すると300倍の大きさを誇ると言われており、確かに大きさに圧倒されるほどだった。高級感が強く、コーヒー一杯800円とかした気がする。

南京西路の通り 世界で一番大きいスターバックス
f:id:ngo275:20181222232124j:plain:w300 f:id:ngo275:20181222232155j:plain:w300

機械というか新しいものがそこら中に置いてあるのが中国らしくて良かった。以下は上海の地下鉄のとある駅の様子だが、自販機の形をした何かがたくさん置いてある。

謎の自販機群① 謎の自販機群②
f:id:ngo275:20181222233155j:plain:w300 f:id:ngo275:20181222233227j:plain:w300

監視されている感の強い街

上海の中でも金融街である外滩(wai tan)に行くと監視カメラが非常に目に入った。信号のいたるところに設置されてあり、歩行者が信号無視を全然していなかった。監視されているという感覚が、人々のマナーを変えているのだろう。監視カメラではこういうふうに映っています、というデモ画像が見れるものもあったが、確かにそれを見ると悪さをするとすぐに見つかると思ってしまう。

信号の上に着いてあるカメラ 監視カメラの映像が見れる信号
f:id:ngo275:20181222233512j:plain:w300 f:id:ngo275:20181222233818j:plain:w300

異常にデカイWeWork

先日中国人向けにメディアをやっている日本人スタートアップの開発に少し関わったのだが、彼らは上海のWeWorkにオフィスを構えていたので遊びに行ってきた。上海にWeWorkはたくさん(10個近く?)あり規模もピンきりなようだが、そのスタートアップが入っていたのは、廃墟を丸々WeWorkの建物にリノベーションした巨大なコワーキングスペースだった。WeWork 696号というところなのでぜひ上海に行く機会があれば行ってみて欲しい。

中国人以外の人もそこそこ多く、いたるところで英語が聞こえてきた。多くの人が中国語はもちろん英語でもコミュニケーションできるように感じた。深センだとまだまだそういうシーンは少ないが、上海は想像以上にグローバルな印象を受けた。もちろんWeWorkが外資ということもあるが。

上から見た光景 カフェのようなおしゃれ空間
f:id:ngo275:20181222231432j:plain:w300 f:id:ngo275:20181222234104j:plain:w300

そのスタートアップの人とはWeChatのミニプログラムの存在が最近非常に強いという話をした。たとえば同程艺龙(tong cheng yi long)というExpediaのようなOTAサービスが今年IPOしたが、その利用者の8割はミニプログラムだそう。自社でアプリを持たなくてもミニプログラムでバイラルで広げやすくなっている。実際にミニプログラムの開発をしてみたことがあるのだが、iOSAndroidの開発に比べると工数が半分以下で済むという実感がある。ログインやシェア機能、支払い機能などよく利用する機能が提供されているのが大きい。

f:id:ngo275:20181222235158p:plain:w300
WeChatのミニプログラムのランキング(2018年10月)

雑感

若い人は東京よりグローバルに仕事をしている印象を受けた(WeWorkがそもそも外資だから英語を使う機会が多いだけなのかもしれないが...)。物価や暮らしやすさもひっくるめて、正直なめていたなぁと反省した。

なぜか深センで登壇してきた話

ことの経緯

11月の後半に、深センをメインに活動されている高須さんから、「12/15に深センでデザインに関連したイベントがあって、主催者が日本人のデザイナーのスピーカーを探しているのだけど、そのタイミングでもし深センにいるなら出てみない?デザインとは言っても何でも良いと思う。」という連絡をもらった。タイミングも合うし、せっかくの機会なので参加してみることにした。英語か中国語でお願いしますと言われたので、英語でのスピーチをすることになった。ペラペラではないが、中国語に比べたら全然余裕だろうという謎の余裕が生まれた。

いざ会場に行ってみると、自分の写真が思い切り映った看板が作られていて、結構マジなイベントなのか、と思って結構びっくり。

f:id:ngo275:20181216094529p:plain:w400

話したこと

speakerdeck.com

今回のイベントの趣旨はイノベーションについてデザインの観点から考えるということだった。デザインと言っても広義だし、日本人から見た深センは興味深いだろうと思い、深センがどう他の都市(特に日本)と異なっていると思うか、という話をした。具体的には、深セン人はテクノロジーを何でもかんでも日常生活に実装してしまうが、それが非常に特殊なことで、それゆえに深センイノベーションの街となっている、という話。

f:id:ngo275:20181216095002p:plain:w400

深センにいると、謎の便利ツールや無人レストランを見かけるが、それらに使われている技術そのものはとてもシンプルで、便利だと思うから実際に作ってみた、というものが非常に多い。もちろん深センには若い人が多く、そういうものを受け入れる文化がある、とか工場が多いので簡単に量産できる、という環境があるのは事実だが、今回の登壇で触れたのは、WeChatのようなプラットフォーム上で簡単に0->1のプロトタイピングができ、テクノロジーを日常生活に応用するための土壌ができているということだ。検証してみたいアイディアがあるとすると、WeChatの公式アカウントや、ミニプログラムを簡単に作ってリリースすることができる。ミニプログラムは、WeChatのユーザベースが提供されている上、アプリのダウンロードの必要もなく、認証やペイメント周りが簡単に組み込めるという利点がある。ハードウェア系のスタートアップだとそういったソフトウェア部分の開発のショートカットが非常にありがたい。日本だとそういったプラットフォームが弱く、検証するためにやるべきことがどうしても多くなってしまう。こういった背景もあり、とりあえずやってみた、というハードルが非常に低いのは大きな特徴だと思っている。

最後にパネルディスカッションもあった。

f:id:ngo275:20181216094927p:plain:w400

感想

  • スピーチの冒頭で、「深センがイノベーティブだと思う人?」と質問するとほとんどの人が手を上げた。ところが、実際に深センに住んでいる人からすると、馴れてしまって見えなくなっている部分が多いようで、深センの外の人からこう思われている、という話が興味深かったようだった。

  • スライドは中国語にして自己紹介も中国語でしたので結構受け入れてもらえてよかった。他の国に行く時に、なるべく現地の言葉で挨拶とかをした方が仲良くなれると思っていて、そのことを今日は実感できた。英語圏で英語で話しかけるのは納得だけど、そうでない国はやはり現地の言葉で挨拶をした方が印象が良く映るに違いにない。

  • 馴れない英語での発表だったが、だからこそ、真顔ではなく笑顔で話すことが本当に重要だと感じた。こういう時こそドヤ顔大切

  • 発表終わった後に、デザイナーの仕事アドバイスとかでいいから受けてくれないか、と言われて仕事を頼まれた(断ったけど)。行動起こせば海外でも仕事ってもらえるんだろうな、と痛感した。

  • イベントの後に発表したメンバーとスタッフの人達で夕食を食べに行ったが、色んな国籍の人がいて会話が英語になっていた。やっぱり国籍が3つ以上になると英語になってしまうし、中国にいながらにして英語の大切さは感じた。

f:id:ngo275:20181216094822p:plain:w400

3年弱でゼロからフルスタックエンジニアになるまでにやったこと

はじめに

そもそも何をもってフルスタックというのかという話もあるが、ここでは、開発するプラットフォームや言語を問わずエンジニアとしてすぐ働ける、というイメージでフルスタックエンジニアという言葉を使っている。ベテランのエンジニアからすると自分の技術力はまだまだだし、自分でフルスタックエンジニアというのは恐れ多いが、iOSAndroidのモバイル環境やウェブ、ブロックチェーン周りのいろんな技術を現場レベルで触ってきた過程で、どういうことをいつ学んできたのか書いていく。もちろんこれが正しいわけでもないし、人によってはフルスタックにならずに何かに尖らせたいということもあるので、参考程度にとどめていただければ、と思う。

長いので、あらかじめまとめを書いておくと以下のような感じ

  • 週末とかもひたすら好きなモノを作ってみる。その際、できれば新しい技術で作ってみるのに挑戦する。
  • 環境に慣れてきたら変える。会社でもいいし、プロジェクトでもいいし、言語でもいいし、役職でもいいし、そこに安住しない。
  • 自分より格段にすごいエンジニアと一緒に働く。
  • ビジネスサイドともコミュニケーションは取る。UMLとか書くといいかも。
  • (アウトプットもした方がいい。自分はできてなかったので偉そうなことは言えないが...)

きっかけ

2015年の12月、大学の同級生が作ったCandleという会社でインターンを始め、プログラミングをHTMLから本格的に勉強したのがスタートだった。これは大学4年の冬。大学の課題でなんとなくJavaを触ったことはあったが、コンピュータ・サイエンスの基礎とかはやったこともなく、2015年12月の時点ではほぼ初めての状態だった。大学時代は、ラクロスというスポーツをやっていて、ほとんどの時間を部活、筋トレ、映像を見ることに費やしており、恥ずかしながら勉強にあまり時間を割けなかった。基本朝4時半起きだったしそれを言い訳にしていた感は否めないが...。とにかく、大学4年の終わりに部活を引退し、その1ヶ月後から、当時なんとなく興味を持っていたプログラミングに熱中しだした

▼大学院試験前夜の様子(白が自分)。遅刻ギリギリに試験には間に合ったが、第1希望は落ちた...

f:id:ngo275:20181121235617p:plain:w300

2015年12月~ : 1年強のインターンで0.8人前くらいに

インターンといっても初めの1ヶ月はHTML、CSSJavaScript(jQueryとかの使い方)、PHPをひたすら勉強して簡単なウェブアプリを作ったりしていた。 とりあえずドットインストールとかを見ながら写経して動くものを作ってみる という感じ。 当時はProgateとかの選択肢もなく、ドットインストールがバイブルになっていた。確かに環境構築とか、 思い通りにいかないところで何時間(下手すると数日)も消えるのが当たり前だったが、問題を解決するのが楽しくて1日中パソコンを触っていた のを覚えている。でも「最悪誰か聞ける人がいるから大丈夫」という環境でなければ、心が折れてプログラミングを投げ出していたかもしれない。僕自身は、「気づいたらパソコンと育っていた」というタイプのエンジニアではないので、初学者がプログラミングを勉強してても続かなくなってしまう理由がとても分かる。誰もが初めはチンプンカンプンで心が折れそうになるのは当たり前なので、決して「自分は向いてないのではないか」と思わないでほしい。そのうち分かるようになる、とやり続けていると、本当にそのうち分かるようになっている。

1年ちょっとひたすらコードを書いたり技術書を読み漁って、基本的なコンピュータ・サイエンスの知識(TCP/IPとかネットワークの基礎知識・アセンブラまわりとかの知識)をつけて、iOSなら普通に他の会社(Candle以外)でもやっていけるようになっていたと思う。

最初の1年で読んだ本を印象に残った順にピックアップしてみる。

Candleでは優秀なiOSエンジニアがそばにいて、その人が綺麗なコードというものを教えてくれたおかげで一気にレベルをあげてもらえた。そういう人が身近にいないと早く成長するのは難しいかもしれない。その時は、いくつかのスタートアップを手伝い、ずっと働いて月50万くらいは稼げるようになっていた気がする。

▼できる人に自分のレベルを無理やり上げてもらうのが早い、というは念能力と同じ

f:id:ngo275:20181121235308p:plain:w300

2017年1月~ : AnyPayにiOSエンジニアとして関わりだす

プログラミングを真剣に初めて1年強経った2017年の1月末に、AnyPayにiOSエンジニアのバイトとして関わりだした。1年強できる限りプログラミングを勉強してきて、ある程度動くコードを書けるようにはなったつもりだったが、30歳を過ぎた力強いエンジニアたちに囲まれると、いかに自分のレベルが低かったのかを痛感した。議論のレベルが学生エンジニア同士では中々ないレベルだった(もちろん学生エンジニアでもそういうのに平気でついていける人もいるが多くはない)。いかにしてテストを書きやすいコードを書くのか、こういう設計だとこういう問題が起きてくる、とかモバイル開発におけるテスト・アーキテクチャについてとにかくキャッチアップした。周りのレベルが上がって刺激的だったので、そういう環境に身を置こうと思い、2017年の4月から正社員として入社することにした

www.wantedly.com

エンジニア歴10年以上の人のパソコンの手さばきが早すぎて衝撃的だったのを今でも覚えている。ショートカットをガンガン駆使していて、とにかくキーボードから手が動かないのだ。他にも、バグやわからないことを調べる時は、Qiitaや第三者のブログを当たるのではなく、とにかく公式のドキュメントを参照していたのも当時の自分には新鮮に映った。当時の僕は、馴れないものを触る時は、まずQiitaで日本語で簡単に説明してるのを見てから自分で少しずついじってみる、というのが染み付いてしまっていた。これ自体は悪いことではないかもしれないが、すごいエンジニアと言われている人は公式のドキュメントで正しい情報を取りに行くのだと痛感した。ベテランのエンジニアと一緒に働くことでこうした些細だけどエンジニアとして大切なことを学ぶことができる

「ゼロからですが本気でプログラミングを勉強します!」と言ってこういう環境に飛び込むのは、数学オリンピック優勝とかよっぽどのことがないない限り基本通らないので、どこかで半年~1年くらい実戦経験を積んでから、レベルの高い環境に移動するのが良いと感じた。むしろはじめからベテランエンジニアに囲まれると、力の差に絶望しか感じないので、個人的には、学生であれば友達のスタートアップとか初心者でも入りやすいところから入るのがオススメ。僕は、初めのうちは、とにかく自分の周りの環境にこだわっていて、自分のレベルが上がると周りの環境を変えるのをかなり意識した

この時期読んだ技術書はこんな感じ。FinTechの業界に対するキャッチアップが必要で、技術書よりもFinTechの法律の本などが中心だった。

2017年6月~ : サーバーのコードも書くようになる

AnyPayに入った初めのうちは就業時間に関係なくずっとiOSの開発をしていたが、数ヶ月経つと新しい環境にも慣れてきて、仕事が終わったあとはひたすらRailsの勉強をした。というのも、サーバがRailsで書かれていたからだ。APIを専任で書いている人もいなかったので、自分が書けるようにようになると頼りにされるとも思った。仕事後や週末に、1ヶ月くらいこっそり勉強してから、サーバも興味あるとCTOに話をして、わからないことを教えてもらいつつRailsのコードも書くようになった。この時は、Ruby on Railsチュートリアルを半分強やって、Railsに関する技術書(パーフェクト Ruby on Rails)を読んで勉強したのだが、Railsに独特の覚えるべきことが多く苦労した。結局自分で簡単なアプリを作ることでRailsの基本や、よく利用されるライブラリ、ActiveRecordの使い方を習得した

そういった甲斐もあって、2017年の夏過ぎから新規事業のサーバーの開発(Rails)もほぼ1人でやらせてもらって、ここでDBの設計からしごかれながらなんとか完成させた。このときにGKE(Google Kubernetes Engine)で開発をしたので、Kubernetesについても勉強することとなった。このプロジェクトを通じて、アラートやロギングをしっかりしておかないと、あとで調査もできないし経済的損失も馬鹿にならないというのも学んだ。

会社の環境にもよるが、チャレンジさせてもらえる環境であれば、ガンガンやりたいことを伝えてやらせてもらうべき。もし逆に、スタートアップで働いているのに、そういうチャレンジがさせてもらえないなら、他の会社を探すなりした方が良いと思っている。いろんな言語・技術に触りたいわけじゃなくても、iOS開発でも機能の要件定義から仕様に落とすとか、ロールをもらえるかどうかも同様。

2017年11月~ : JavaScriptブロックチェーンの世界に入り込んでしまう

f:id:ngo275:20181202234611p:plain:w300

Railsを3~4ヶ月くらい開発した後、そのプロジェクトは運用のフェーズに入り落ち着いてきて、また新しいプロジェクトの開発にも関わりだした。それは暗号通貨関連のプロジェクトでReact NativeでiOS/Androidアプリを作るものだった。2017年の11月くらい、ちょうど暗号通貨が話題の頃で、プライベートの時間にはJavaScriptやSolidityをコツコツ勉強しており、AnyPayの業務でもそういった技術を触るようになった。Railsの時と同様に、業務で使えそうな技術をプライベートで勉強しておいて、ある程度分かってきたら、会社でそれを活かせるところに関わりたい欲をアピールした。それが受け入れられるかどうかは会社によると思うが、幸いなことにAnyPayのCTOはそういった姿勢に対して非常にポジティブで応援してくれる方だった。ブロックチェーン系のプロジェクトはJavaScriptとの相性が良いということもあり、この時期(2017年の冬)から最近(2018年11月)に至るまでほとんどJavaScriptを書いていた。

JavaScriptはプログラミング初心者の頃によく勉強すると思うが、JavaScriptを本格的にプロダクトで利用するとなると学ぶことが非常に多い。書き方が柔軟すぎるからだ。特にウェブのフロントエンドの変化は早く、去年学んだことがもうdeprecatedになってしまう勢い。ただ、開発者が多いので、GitHubJavaScript系のプロジェクトを見つけるのが非常に容易で、大きなプロジェクトのソースコードを読んだり動かしてみることで勉強をした。特にブロックチェーン系の文脈でJavaScriptを学びだしたので、ICOしているプロジェクトや有名なプロジェクトを参考にした。もし最初の言語がJavaScriptの場合は、勉強のために大きなプロジェクトのコードを読むのは辛いかもしれないが、他の言語の知識があると補完しあうことで理解が早まると実感した。特に、Swiftのような静的型付け言語と、Rubyのような動的型付け言語をそれぞれ学んだことで、新しく言語を学ぶ時の理解度が初めの頃に比べてグッと早まった。Ethereumというブロックチェーンを扱う際に、Solidityという新しいプログラミング言語を利用するのだが、Solidityはほとんど勉強しなくてもコードが読めたし、実装も苦労しなかった。Goに関しては少し苦労したし、まだ自信を持って書けるとは言えないが...。

2018年8月~ : プロダクトの設計も関わりだす

初めの2年でモバイル(iOSAndroid少し)とウェブの開発、ブロックチェーン関連(Ethereum)の開発、アナリティクス周りがそれっぽくできるようになったが、3年目にUMLやDBの設計・プロダクトのアーキテクチャについて、シニアエンジニアとの議論を通じて学ぶことができた。「コードは書ける」という状態から、要件から仕様に起こすといったプロダクトの設計レベルのことにも関わり、エンジニアとして少し深みが出たかもしれない。個人的には、プロダクトの設計の部分が割と重要だと思っていて、独学では中々学べないので実践で学んでいくしかない。PMが普段何をしているのか、ということに注意を払ってみるとこうした設計レベルのことを行っており、エンジニアもそういったプロセスを見ると勉強になると思った。

f:id:ngo275:20181203002419p:plain:w300

ビジネスサイドの人が何を考えているのか理解することが非常に大切で、そういったことを理解するためにもUMLは欠かせないと思う。エンジニアとしては価値のあるものを作りたいという気持ちがあるが、ビジネスとしてサステイナブルでないものを作るのは、ビジネスとしては間違っているし、中で働いているエンジニアも給料も上がらずいい思いをしないと思う。

その他

  • プライベートの時間で自分でモバイルやウェブのアプリを作ったりして、興味がある技術を試したりしていたのも今となっては良い勉強だった。たとえば、Firebaseに興味を持ってサーバレスのアプリ開発をしていたが、AnyPayでも、プロジェクトによってはFirebaseのRealtime Databaseを利用する案件もあり、プライベートで学んだ知識を還元することができた。

  • IoT系のプロジェクトも少し関わって、はんだごてを握ったりArduinoをガシガシ使ったりした時期もあり、ものづくりの可能性を感じた。アプリ開発だけしているとどうしてもアプリ開発が先に思いついてしまうが、ハードウェアの開発もすると、欲しいもの何でも作れる気がしてきてエンジニアとしては楽しみが増えた。その点では中国の深センは面白い。

  • アウトプットが少なかったことは反省。インプットするものの、ついついアウトプットが少なくなってしまっていた。外部のイベントで登壇やLTをする時期もあったが、忙しくなったタイミングでいつも途絶えてしまう。そこで知り合った人から仕事をもらえたりもするのでアウトプットするのは大切。

  • 週末にアメリカ人の会社を手伝っていたのは良い経験になった。英語でのコミュニケーションも勉強になったし、シリコンバレーでずっとエンジニアしていた人だったので、いつもと異なるスタートアップの文化を日本にいながらにして感じることができた。今はもう手伝っていないが、イギリスに移転したからおいでよ、とお誘いもいただけた。

まとめ

つらつら書いてきたが、自分がしてきたことのうち意識したことをまとめると以下のような感じ。どこでもよく見かける内容ではある。

  • 週末とかもひたすら好きなモノを作ってみる。その際、できれば新しい技術で作ってみるのに挑戦する。
  • 環境に慣れてきたら変える。会社でもいいし、プロジェクトでもいいし、言語でもいいし、役職でもいいし、そこに安住しない。
  • 自分より格段にすごいエンジニアと一緒に働く。
  • ビジネスサイドともコミュニケーションは取る。UMLとか書くといいかも。
  • (アウトプットもした方がいい。自分はできてなかったので偉そうなことは言えないが...)

Node.js+ExpressでAPIサーバを立てる(ES6, Webpack, Flow, Jest, ESLint)

まずJavaScriptの歴史をざっと見てみる

1995年にJavaが登場したが、その勢いに便乗して、ブレンダン・アイクが開発したLiveScriptがJavaScriptへと改名したことにより、 JavaScript爆誕

その翌年、マイクロソフトJavaScriptのライセンスがなかったために独自のJScriptを開発。ところが、JavaScriptを開発していたNetscape Navigator社は、JavaScriptJScriptの互換性があまりにひどかったことから1997年にECMA InternationalにJavaScriptJScriptの統合を依頼。このJavaScriptのメイン機能を乗せた言語をECMAScript(ES)と言う。統合を依頼とはいったものの、この統合がなかなかうまく進まず、2000年代前後は、JavaScriptが重い・セキュリティホールになりがち、などと言った理由から人気が落ち、Flashの方が人気を博した。

しかし、2005年にGoogle mapがAjaxを駆使して非同期通信をWebブラウザからできるようにしたことで、JavaScriptが再度盛り上がることとなった。2008年にはV8というJavaScriptエンジンが登場したりと、さらに熱が高まっていった。

JavaScriptの最大の欠点は モジュール機能の欠如している ことだった。それを解決するべく生まれたのが CommonJS である。これはあくまで規格であって、2009年に登場したNode.jsはCommonJSの1つである。Node.jsの登場によって、JavaScriptはブラウザ以外からも利用できることが証明された。そして、Node.jsのようにCommonJSで作られたツール群をブラウザでも利用できるようにしたい、というニーズが生まれ、その解決方法がbrowserifyやWebpackである。gulpやgruntはタスクランナー(JavaScriptのコードを書いてから、実際にブラウザで使えるまでの諸々の作業を自動化してくれるツール)だがWebpackはその機能も含んでいる。

一方で、ECMAScriptの策定も進んでおり、2016年に策定されたECMAScriptはES7と呼ばれ、2015年に作成されたものはES6と呼ばれる。ES6やES7のように新しい構文が登場する一方で、ついていけないブラウザには babel と呼ばれるものを使って対応することになる。

以下を参照

qiita.com

Node.jsでAPIサーバを実装していく

では、APIサーバをNode.js(Express)で構築して行くことにする。フロントエンドをVue.jsReact.jsで実装するとなると、同じリポジトリAPIサーバ・フロントエンドの実装を行うことが想定されるが、その場合は、Node.jsもWebpackでES6の記法に従うことになるだろう(const hoge = require('hoge') ではなく、 import hoge from 'hoge' という記法になるイメージ)。

まずExpressをインストールして簡単なサーバを構築する

$ yarn add express

次にルートディレクトリに、 app.js を作成して以下のように編集する。

// app.js
const express = require('express');
const app = express();

app.get('/', function(req, res){
  res.send({ message: 'hello world' });
});

app.listen(3000);

ディレクトリ構成は以下のようになる。

.
├── app.js
├── package.json
└── yarn.lock

node app.js とすると http://localhost:3000/ が起動するはず。

{
  "message": "hello world"
}

が返ってくれば成功。

Node.jsをWebpack+ES6に対応させる

今の状態だとモジュールのインポートがReact.jsなどと異なった形である( import hoge from 'hoge' ではなく、 const hoge = require('hoge') )。React.jsでお馴染みの flowESLintJestにも対応させるべく、WebpackでES6対応する。

Webpackのセットアップ

$ yarn add -D babel-core babel-polyfill babel-preset-env babel-loader@7 webpack webpack-cli webpack-merge flow-babel-webpack-plugin webpack-node-externals
$ yarn add -D babel-regenerator-runtime babel-preset-es2015 babel-preset-stage-2

Webpackの設定ファイルを書く。

configというディレクトリを作成し、 webpack.config.base.js という名前で以下のように実装する。

const path = require('path');
const nodeExternals = require('webpack-node-externals');
const FlowBabelWebpackPlugin = require('flow-babel-webpack-plugin');

module.exports = {
  target: 'node',
  externals: [nodeExternals()],
  mode: 'development',
  entry: ['babel-regenerator-runtime', './app.js'],
  output: {
    path: path.resolve(__dirname, '../dist'),
    filename: 'server.js',
  },
  resolve: {
    modules: ['node_modules'],
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        use: [
          {
            loader: 'babel-loader',
            options: {
              plugins: ['transform-flow-strip-types'],
              presets: ['flow', 'stage-2'],
            },
          },
        ],
        // node_modules は除外する
        exclude: /node_modules/,
      },
    ],
  },
  plugins: [new FlowBabelWebpackPlugin()],
  node: {
    net: 'empty',
    tls: 'empty',
    dns: 'empty',
    fs: 'empty',
    __dirname: true,
  },
  watchOptions: {
    ignored: ['node_modules'],
  },
};

続いて、同じディレクトリに、 webpack.config.dev.js と言う名前で以下のように編集する。

const merge = require('webpack-merge');
const baseConfig = require('./webpack.config.base');

const config = merge(baseConfig, {
  mode: 'development',
});

module.exports = config;

.babelrc というファイルを作成し、中身を以下のように編集しておく。

{
  "presets": ["es2015", "flow"]
}

flowのセットアップ

続いて、flowのセットアップをしていく。

$ yarn add -D babel-cli babel-preset-flow flow-bin
$ yarn flow init

すると、 .flowconfig が生成されるので、以下のように編集しておく。

[ignore]
.*/node_modules/.*
.*/dist/.*
.*/test/.*


[include]

[libs]
flow-typed

[lints]
deprecated-call-syntax=off

[options]
esproposal.decorators=ignore
module.name_mapper='^src\/\(.*\)$' -> '<PROJECT_ROOT>/src/\1'
module.system=haste
all=false

ESLintのセットアップ

コードの静的解析ツールESLintを入れる。

$ yarn add -D eslint
$ ./node_modules/.bin/eslint --init

f:id:ngo275:20181107180200p:plain

これで生成された .eslintrc.json を以下のように編集する。

{
    "extends": "airbnb-base",
    "parserOptions": {
        "ecmaVersion": 7,
        "sourceType": "module"
    },
    "parser": "babel-eslint",
    "env": {
        "browser": true,
        "es6": true
    },
    "plugins": ["flowtype"],
    "rules": {
        "flowtype/no-types-missing-file-annotation": 1,
        "max-len": [2, 100, 4, {"ignoreUrls": true}]
    }
}

上の eslint の初期化時には関連するライブラリをインストールしていないので、以下でインストールする。

$ yarn add -D babel-eslint eslint-plugin-flowtype eslint-config-airbnb-base eslint-plugin-import

.eslintignore というファイルを生成して、ESLintの対象から外すものを明示しておく。

server.js
flow-typed
__tests__
__mocks__
node_modules
.idea
.vscode

これで yarn eslint . と実行すると、ESLintの結果が出力される。ここで出たエラーは、 yarn eslint . --fix とすると自動で修正される。

Jestのセットアップ

$ yarn add -D jest
$ yarn add -D babel-jest babel-core

Node.jsをWebpackで起動する

この時点で、 Node.jsをWebpackで起動するのに必要なものは揃った。

package.json は以下のようにする。

{
  "main": "./dist/server.js",
  "scripts": {
    "start": "node ./dist/server.js",
    "flow": "flow",
    "eslint": "eslint .",
    "test": "jest",
    "webpack-dev": "webpack --config config/webpack.config.dev.js"
  },
  "dependencies": {
    "express": "^4.16.4"
  },
  "devDependencies": {
    "babel-cli": "^6.26.0",
    "babel-core": "^6.26.3",
    "babel-eslint": "^10.0.1",
    "babel-jest": "^23.6.0",
    "babel-loader": "7",
    "babel-polyfill": "^6.26.0",
    "babel-preset-env": "^1.7.0",
    "babel-preset-es2015": "^6.24.1",
    "babel-preset-flow": "^6.23.0",
    "babel-preset-stage-2": "^6.24.1",
    "babel-regenerator-runtime": "^6.5.0",
    "eslint": "^5.8.0",
    "eslint-config-airbnb-base": "^13.1.0",
    "eslint-plugin-flowtype": "^3.2.0",
    "eslint-plugin-import": "^2.14.0",
    "flow-babel-webpack-plugin": "^1.1.1",
    "flow-bin": "^0.85.0",
    "jest": "^23.6.0",
    "webpack": "^4.25.1",
    "webpack-cli": "^3.1.2",
    "webpack-merge": "^4.1.4",
    "webpack-node-externals": "^1.7.2"
  }
}

最初に作成した app.js の中身をES6に対応させるために1行目を以下のように書き換える。

import express from 'express';

package.json にあるように起動コマンドを実行してみる。

$ yarn webpack-dev
$ yarn start

すると、 localhost:3000 が起動できるようになっているのが確認できる。

編集したファイルを自動で反映するようにする

$ yarn add -D nodemon concurrently

必要なライブラリのインストールが完了したら次は、 package.json に以下の行を追加する。

{
  ...
  "script": {
   ...
    "dev": "concurrently \"NODE_ENV=development webpack -w --config config/webpack.config.dev.js\" \"nodemon --watch ./dist/server.js\""
  },
  ...
}

以下でローカルホストが起動したら成功。

$ yarn dev

ソースコードはこちら。

github.com

インドネシアの首都ジャカルタに行って感じたこと

初めてインドネシアジャカルタに行ってきた。

コタ地区というエリアに泊まったが、そこは古都のようで「新興国」と言わんばかりの街並みだった。道路や建物の舗装は行き届いていない様子。

グランドインドネシアという新しい巨大なショッピングモールがあるのだが、そこは非常に綺麗で賑わっていた。ららぽーとに似ている。

f:id:ngo275:20181021122722p:plain:w500

物価については、観光客が行くようなご飯どころだと日本の3分の2くらいの価格だろうか。ローカルなお店だと半額どころではなく安い。ショッピングモールの店はどこも日本より若干安い、程度に収まっていた。海外のブランドだと当然っちゃ当然である。クレジットカードが使えることもあるが現金での支払いが多い。現地通貨はルピアだが、1,000,000ルピア = 8000円くらいなので計算も非常にややこしい。たとえばタクシーに乗ると83,000ルピアとかになったりする。Go-Jekというバイクタクシーの配車サービスが手がけているGoPayも対応しているレストランをちらほら見かけた。

f:id:ngo275:20181021123423p:plain:w400

現地の人は、イスラム系が多く、スカーフを纏っている人を割と見かける。全体として親日な印象を受け、レストランとかでは「ありがとうございます」とか日本語で挨拶されることが何度かあった。観光客感が出ていたのだろう。

電車は一応あるようだが、車かバイクで移動が多いようで、交通の状態が非常に悪かった。6km移動しようとすると平気で30分かかるくらい。ホーチミンに比べるとバイクの割合は少なかったが、Go-Jekというバイクタクシーの配車サービスが流行っており、バイクで人を乗せるケースが非常に多いのを実感した。日本やシンガポールだと地下鉄が発達しているので一人で数百人を運ぶことが可能だが、ジャカルタだと一人で一人を運ぶのが普通になっており、人の輸送効率が極めて悪い。結果的にタクシードライバーという職業の人がどうしても増えてしまう。自転車や電動スクーター(これが世界でうまく行っているのかどうかはさておき)のように一人で移動する手段が流行すれば運転手が新しい仕事に就いて経済がより回るようになるのかな、と思ったり。

f:id:ngo275:20181021121216p:plain:w500

インフラが人口増加のスピードについていけなかったために社会としていびつになってしまったように感じた。経済は発展しているにも関わらず、それを享受できてない層が一定数いるのだ。そういった層に対してどうやってお金が回ってくるようにするのか、を考えさせられた。その点でGo-JekやGrabはフィットしたんだなと思う(タクシードライバーをすることでお金を稼ぐチャンネルが増えた)。現地で仲良くなったインドネシア大学(日本でいう東大)でコンピュータサイエンスを学んでいる子は、来年からシンガポールで働く内定をもらったが契約書にサインしに行くためのお金が足りなくてやばい、と言っていた。プログラミングができるならそれでバイトしたら?と言ってもそもそも案件自体が少ないらしく中々ありつけないのだとか。こういうところに行くとマイクロファイナンスがいかに必要なのかを実感する。

あとは、物価も比較的安いのでご飯代を出す代わりにローカルな話をしてくれる人とご飯が食べれるレストランがあるといいなあと感じた。Tinderに対するYentaのように、相席屋に対するローカルな人と外国からきて話を聞きたい人がマッチングできる場所のイメージ。場合によってはそこから雇用とかも生まれたりして良さそう、と一人で散策しながら思った。

ブロックチェーンと今後の姿

ブロックチェーンとは

f:id:ngo275:20181003234825p:plain:w500

ブロックチェーンとは、端的に言うとデータ保持の1つの方法に過ぎない。一本の鎖のようにブロックを繋げて行き、その各ブロックの中に様々なデータを格納していく。一度ブロックに刻まれたデータは改ざんが理論上難しく、安全性が高いと言われている。

インターネットは、あらゆる情報の交換を可能にして人々の暮らしを大きく変えた。一方で、ブロックチェーンはインターネットの次のイノベーションである、と表現されることがあるがそれは一体どういうことなのか。この新しいデータ保存の方法がなぜそこまで注目を浴びているのか。

インターネットは、インターネットそのもので情報が交換できるようになり、その上に様々なアプリケーションが作られた。一方でブロックチェーンは、ブロックチェーンそのもので情報だけでなく価値の交換ができるようになる。お金のやりとりもアプリケーションの下のインフラレベルで可能になるということだ。そうすると、ブロックチェーン上のアプリケーションの比重はインターネットの世界におけるアプリケーションのそれと比較してずっと小さくなる。一部の大きい会社が圧倒的な富を得ているという現状が覆されるかもしれない。

f:id:ngo275:20181003234841p:plain:w500

ブロックチェーンの今

2009年にビットコインが始動したのを皮切りに、多くのブロックチェーンの応用例が登場してきた。2015年にメインネットがリリースされたEthereumは、2017年に非常に注目され、スマートコントラクトという概念が広く認知された。世の中の契約をスマートコントラクトで表現することで、管理者が不在でも複数人の間での契約が執行できるようになる。もちろんまだまだ課題は多いが、多くの人がそれを解決すべくしのぎを削っており、EOSやZilliqaなどEthereumのライバル的なブロックチェーンプロジェクトが出てきている。

ブロックチェーンは、コンセンサスアルゴリズム(次のブロックをどうやって決めるのか、というアルゴリズム)や、処理の高速化、ファイナリティーの確保(新規で追加したブロックが覆されないことの保証)、分散化、といった課題を抱えており、海外ではそれを解決するためのプロジェクトが多い。また、ConsenSysのようにDApps(ブロックチェーンを利用したアプリケーション)を作るためのツールを開発する動きもある。一方で、日本は、デベロッパーレベルではDAppsの開発は盛んだと思うが、資本を投下してブロックチェーンの業界で戦っているプレイヤーはまだごく一握りだ。

今後どうなるのか

Facebookの情報漏洩や仮想通貨取引所・銀行のクラッキングなど、サービス利用者がサービス提供者を信頼して預けているはずのデータやお金が大きな危険にされされている現状がある。そういった多くのアセットを持つ会社は常にクラッカー(悪いハッカー)からの攻撃に晒されているのである。今後は、ユーザが自分のデータやお金を管理することになっていくはずだろう。逆に言えば、各企業がそういった個人的なデータや資産を持ちたくなくなってくるだろう。たとえば、Webアプリのデータ自体はサービス提供者側が持っていたとしても全て暗号化され、データの持ち主の秘密鍵を使ってのみデータを読み取れるようになるとか、他には、分散型取引所のように自分でお金を管理して取引所が利用できるとか。Dropboxのようなストレージサービスや、チャットアプリといった個人情報が絡むサービスにおいて、どうやって個人で管理できる形で提供するか、という流れが起こるだろう。

この問題を解決するにあたって必ずしもブロックチェーンを使う必要はないが、どこかの中央集権的な管理者に依存することなくデータや価値の保存・交換の安全に行うためには、ブロックチェーンとの相性が良い。既存のWeb技術と分散的な技術のつなぎ目に注目していきたい。そういった観点からすると、任意のアプリケーションをブロックチェーンに乗せることができるTendermintは非常に興味深い。

今後もブロックチェーンそのものを使った技術開発や改良はもちろん必要になるが、それを使って何を解決するかが重要なのであって、ブロックチェーンの技術が目的になってはいけない。