VimConf 2018の資料集

3行で

資料集だよ

足りないところ、ミスなどあったら指摘お願いします。

なるべく拾います

本題

Official

Keynotes

Sessions

LTs

補足

SmartHR焼肉会社説明会に行ってきた話

3行で

SmartHRの焼肉会社説明会に行ってきたよ

おいしかったよ

楽しかったよ

発端

Twitterを眺めていたら、こんなのが流れてきたのです。

焼肉おごられるとか都市伝説だと思っていました。

見つけたその場で登録。

とはいえ、以前SmartHRさんのエンジニアの入社歓迎会の練習をする会に申し込んで抽選で外れた経験がありました。

そのため、今回も抽選で外れるだろうと高をくくっていたのです。

smarthr.connpass.com

準備

応募して、数日経った後にSmartHRさんからメールが来ていました。

当落かなと思って開いてみると、中にはこんな文言が

予想を上回る多くの方からご応募をいただいているため、複数回に分けての開催を検討しております。 お手数ですが、 こちらのフォームから参加可能日をお送りいただけますと幸いです。 また、開催希望地もアンケートを取らせていただいておりますが、確実にご希望に添えるわけではございませんのでご了承いただけますと幸いです。 *1

複数回に分けて焼肉会社説明会開催するとかまじかという気持ちと日程だけじゃなく希望地までアンケート取るとか良心的すぎかという気持ちで私の心はいっぱいになりました。

アンケートにも即座に返信。

そのときの私はまだ油断していたのです。

きっと抽選で外れるだろうし、焼肉は別の機会で食べれるだろうと。

招待

あれは、11/12のことでした。 SmartHRさんから焼肉の招待のメールが来ていたのです。

私は、本当に焼肉を奢ってもらえる上に会社説明会もしてもらえるなどという上手い話があるのかと訝しみながら当日を待ちました。

焼肉(11/15)

20:00からだったので、10分ほど前に渋谷に到着。

ただ、焼肉会場のビルを間違えて、5分ほどロスしたので、店に着いたのは3分前でした。まさか渋谷で迷うとは...

お店に到着すると、店の前にそれっぽい方いたので、SmartHRの方ですか?と声をかけ席に案内してもらいました。

全体的に会社説明というより、双方が質問して、答え合う的な感じでした。

社員さん同士も見ず知らずの人と焼肉を囲んでいるにも関わらず、かなりフランクな話題を話されていました。

時間が半分すぎたあたりで、席をチェンジしました。

以下、聞いた話で記憶に残ったものをつらつらと。

  • 自己紹介でぷりんたいさんに「ぷりんたいです」って言われて、一瞬???ってなった
  • 焼肉は特選コースだった(店員さんの声が聞こえた)
  • 私は、ずっと肉を焼いてもらってひたすら食べる人になっていた
  • 実は招待された人は私含めて4人だったっぽいが、手違いがあったらしく、1人不在だった
  • 現行のチーム構成はバックエンド17人に対して、フロントエンド2人と比較的?攻めた構成
  • インフラエンジニアはフルマネージドなサービスしか使っていないこと、また会社の方針的に職種として存在しない
  • インフラについては、SmartHR本体はAWS Elastic Beans Talk、アドオンの年末調整機能などはHeroku
  • 今回の焼肉会は計4回開催していて、毎回開催場所もメンバーも違う
  • 私が行ったのは2回め
  • メンバーは事前のアンケートで答えてもらった話したい人になるべくしつつとスケジュールの兼ね合いで決めた
  • フロントエンド的にはbootstrapとかSprocketとかCofeeScriptとか残ってて割とつらいところはちょこちょこある
  • 新しく開発した機能はReact + ReduxでフルSPAだったりするけど、ブランドテイストを合わせるためにbootstrapに寄せてたりする
  • React + Reduxなのは、フロントエンドのうち1人がReact大好きだから
  • Vueやろうみたいな話もあるらしい
  • smarthr.css的な秘伝のCSSがある
  • 全社的に使えるコンポーネントガイドも整備しようと画策してるけど手が足りない
  • 今までは機能的に一覧、詳細、フォームが中心ということもあり、Railsのテンプレートでどんどこ開発してきたため、フロントエンドが少なくてもギリギリ回っていた
  • プラットフォーム構想に伴い、新機能は独立したサービスとして、マイクロサービス的な開発をしており、フロントエンド必要だよねってなってきた
  • サービスをお客さんがめちゃくちゃ使い込んでくれており、ユーザーの方が詳しい可能性すらあるらしい
  • SlackにegosaチャンネルがあってSmartHRについてつぶやくと拾ってる
  • めっちゃフィードバックが来る
  • 新機能の企画はユーザーからのフィードバックを元に、ビジネスチームが検討してGoがでる
  • エンジニアからボトムアップ的なものは、エンジニアが実際に労務をやってるわけでもないのでほぼない。ビジネスチームの検討を良い意味で信頼しているし、いつも納得させられる
  • エンジニアも技術志向よりプロダクト志向が強い。これははっきりと面接のときとかにも言ってる
  • エンジニアさん人柄の良さそうな人が多かった
  • CPOは行政と関わったりもする
  • CPOに限らず役員の仕事は足りないところをやる感じ
  • VPoEはいるけど、CTOはいない
  • VPoEは評価、ピープルマネジメントはやるけど、採用はぷりんたい氏にまるごと権限委譲しているらしい
  • VPoEとはいえ、マネジメント半分、プレイヤー半分
  • VPoEは、1 on 1は20人いるエンジニア全員と2週間に1度やっており、1 on 1 Weekと実装ウィークを2週間サイクルで繰り返しているらしい

ちなみに上記とは別に殊更心に残ったことがあったので書いておきます。

SmartHRさん、会社の銀行口座残高まで全社員に公開しているなどかなり情報をオープンにされていますが、評価と1 on 1の内容だけはオープンにしていないそうです。

1 on 1は割とセンシティブな話題も扱うことが多いと思うのですんなり納得できます。

しかし、評価については企業によって全公開とはいわずとも一部上位者だけ公開になっているところもあります。

そう考えると、評価の公開非公開はそれぞれメリットデメリットがあるはずです。

となるとなぜSmartHRさんはあえて公開していないんだろうと気になっていました。

あまりに気になっていたので良い機会と思い、なぜ公開していないのか・これからも公開するつもりはないのかとVPoEの芹澤さんに聞いたところ、こんな答えが返ってきました。

「評価は評価者と被評価者のコミュニケーションというコンテキストがあって意味を成すもの。 そのコンテキストを抜きに評価を公開して他人が知ったところで知った当人も、評価者も被評価者も誰も得しないどころか、変に勘ぐって害しか生まない。 評価を公開することで得られるメリットは、評価を公開する以外にもやりようがいくらでもある。 だからこそ、これからも評価を公開することはしない」

多少、言葉は違ったかもしれませんがだいたいこんな感じだったはず。

これを聞いたときに、なるほどなあと非常に腑に落ちました。この会社はコミュニケーションを丁寧にやることが全社員に行き渡っているんだろうなと。

焼肉会社説明会もプロダクト自体のわかりやすさも社員に対する情報公開もその一端だと思います。

ちょっと感動したのと記憶に強く残ったので、別立てで書きました。

YAKINIKU NO OWARI

楽しかった焼肉もあっという間に終わり。

帰り際にぷりんたいさんに焼肉会社説明会の話、どこまで記事にしていいですかと聞いたら、全部していいですよとお墨付きをもらいました。

ので、包み隠さず書いてます。

何か間違ったこと書いていたら、教えてください。修正します。

もっとよくなりそうなところ

  1. 店の入口にSmartHRの人と分かるようにストラップあるいはTシャツを着て、立っててほしかった
  2. 6人席は招待された人に対角で座ってもらうほうが社員さんとまんべんなく喋れた気がする

1は予約の名前教えてもらってたので、それで解決しますね。書いてて気づいた。雑魚だった。

最後

SmartHRの皆様、おいしい焼肉といろいろとお話をありがとうございました!

上記、聞いた話についての文責は私にあります。間違ったこと書いてたらごめんなさい。

本当に正確なことが知りたい方はSmartHRの中の人に聞いてみてください。

ちなみに絶賛採用中らしいので、案内置いときます。

smarthr.co.jp

ではでは。

*1:実際に来たメールより一部抜粋

技術書典5に一般参加した話

TL;DR

行ってきたよ!

広かったよ!

楽しかったよ!

TL

  • 10:40 現着
  • 10:48 最後尾に並ぶ
  • 11:00 開場
  • 11:24 入場できた
  • 12:03 離脱

戦利品

サークル名
技術書典運営事務局 技術季報 vol.4
メルカリ技術書典部 メルブーーック
FOLIO Publications FOLIO ENGINEER BOOK #01
Nutcracker(ナットクラッカー) りあクト! TypeScriptで始めるつらくないReact開発 上下合本ダウンロードカード
越後屋(エチゴヤ WebでもReact Nativeがしたい!
すべてがM(icro)になる Microservices architecture よろず本 その二
潜推艦 ConditionalTypes I/O - TypeScript3.1 推論型の活用と合成 -
mican juice. 図でざっくり分かるWEBフロントエンドの歴史本
虎の穴ラボ 虎の穴ラボの薄い本。

雑感

  • 入場待機列がサンシャインシティを半周ぐらいしていて驚いた
  • 入場前整理券なくなったけど、現地に到着してから入場するまでの待ち時間は前回とさほど変化なし
  • 会場が広いと島と島の区切れで多少人が減るので、休憩できて、快適
  • 人が集まっている以上、どうしてもメインの通路は明らかに空気がよろしくない
  • 第4回より、後払いアプリ対応のサークルが増えた気がする。購入した中だとFOLIO以外、対応していた。
  • Twitterで混雑具合が回ってきたが、中に入ってみれば写真から感じる印象よりは圧倒的に快適だった(入場した時間の問題かも)
  • react-native本がめっちゃ増えてて、web frontend FW界隈の本は前回とほぼ同じかちょい少ないぐらいの印象
  • 当日参加できていないサークルが割と目に付いた

最後に

技術書の感想は、また今度書きます。 強くてニューゲームかと思いきや、会場が3倍になり、普通のニューゲームをやりきった運営チームに最大限の感謝を。お疲れ様でした。 また、サークル参加者の皆様、素敵な技術書をありがとうございます。 次回も楽しみにしています。

閃の軌跡Ⅳをクリアした話

はじめに

この文章はポエムです。

中身

9/27に発売された閃の軌跡Ⅳを、クリアしました。

最高だった。

あれこれ

ネタバレはしません。ぜひプレイしてください。

総プレイ時間130時間ちょっと、約3週間、トロフィーコンプリート率は85%でした。

振り返り

軌跡シリーズ沼に足を踏み入れたのも、今は昔、中学生のとき。 当時、全盛期だったPSP。モンハンも飽きたなあと思っていたところに目に止まった空の軌跡SCを購入したときが始まりです。

何がアレって買ってびっくり、UMD2枚組。Wikipediaを曰く、史上初だったらしいです。 何も前提知識なしに買ったためSCから始めるという重大なポカをやって、話がよくわからないなと思ったことを鮮明に覚えています。 そして、RPGにも関わらずキャラを育成することもしなかったため、第二章荒ぶる大地でのイベント戦闘がどうしてもクリアできずに、投げました。 アビスワーム8匹で深淵よりの激震連打されるとdelayして順番回ってこないし、無理じゃん

それから、しばらく経った後に、SCはFCからの続きものだと気づき、FCからやり直したのでした。 それ以来、軌跡シリーズに魅了され続けています。 発売日翌日には必ず有給を取るようになってしまった。

そんな軌跡シリーズですが、FCの最初の章でクエストを期限切れにしてしまって以降、できるだけすべてのキャラクターに話しかけてからストーリーを進めることを信条としています。

圧倒的に練られた世界観、そこに息づく魅力的なキャラクターたち、それらを踏まえながら進んでいくストーリー。

叶うことならば、シリーズの完結を見届けたいですね。

これから、始めたい人はPSVITAでリメイク作品がでてるので、そこから入るといいと思います。

順番にはお気をつけて。

それでは、これからじっくり設定資料集を読むことにします。

ではでは。

エンジニアリング組織論への招待を読んで 〜歴史と技術と組織論〜

TL;DR

  • エンジニアリング組織論への招待を読んで、最高だったので、おすすめする記事です
  • 最高になっているので、エモめ
  • 歴史はいいぞ
  • エンジニアリング組織論への招待はいいぞ

始めに

出た当初、結構話題になり、知っている方も多いと思いますが、エンジニアリング組織論への招待を読みました。

gihyo.jp

内容があまりにも好物だったので、技術評論社に誤字脱字訂正まで送ってしまった。

何がよかったのか、内容をかいつまみながら説明していこうかと思います。

内容

5章立てとなっており、目次は以下の通りです。

Chapter1から順に、個人の思考 -> 1対1の関係 -> 1対多(チーム)の関係 -> プロダクトとチームとの関係 -> アーキテクチャと組織の関係という風に説明されていきます。 詳細は読んでください。

何が良かったのか

一言で言えば、歴史的背景の解説を丁寧にしてくれている点です。 例えば、昨今、流行りのアジャイルについてその思想的背景から説明してくれている本はなかなかないと思います。 アジャイルという思想の源流を辿れば、そこには世界に冠たるトヨタかんばん方式があり、さらにその後ろにはデミング博士の開発した馴染み深いPDCAサイクルがいます。 そして、その隣には戦後から続くベトナム戦争で疲弊したアメリカ国内での思想潮流の変化と東洋文化の融合がいるわけです。 ジョブズが東洋思想に傾倒していたのはそれなりに有名ですし、シリコンバレーがカリフォルニアにあることもちょっと世界地図を見れば分かりますが、この2つに関係があるとはまったくもって知りませんでした。 まったく関係なさそうに見える事柄でも、意外な関係にあるものはそれこそ無限にあります。 それを紐解いていける手がかりの1つが歴史だと思います。 きっと、要素分解的な思想を持つ西洋文明の裏には、第一次世界大戦がいますし、産業革命がいますし、ルネサンスもいます。一方で東洋文化の裏には、明治維新がいますし、清帝国がいますし、インドや東南アジア諸国も関係してくるでしょう。 このダイナミクスに心がウキウキしてしまいませんか?  今まさに、そういう世界に生きていると思うとちょっと楽しくなってきます。

少し脇道にそれると、私は大学で経営学をやり、高校では世界史と日本史がやりたいから文系(もちろん、数学・理科が苦手だったのもある)に行ったタイプの人間です。 なので、一見関係ないけれども、歴史を振り返ると実は関係があるものが大好物なのです。

本書は、コンピューターサイエンスがめちゃくちゃ好きでコードを書いているタイプの人には刺さらないと思います。 ある程度、経済学・経営学を学んだことがあって戦後の経営学の流れが分かっていると一層面白いと思います。 もっと言えば、戦後のアメリカ史も軽く学んでおいたほうが面白いと思います。

組織とアーキテクチャについて

コンウェイの法則は圧倒的に正しい。 業務でフロントエンドがメインで、マイクロサービスの話がアツいので興味があったりするんですが、これも組織構造の話と切っても切り離せないなあと思うことしきりです。 興味ある人は以下をどうぞ。 www.atmarkit.co.jp

歴史について

何かについて深く知りたいってなったときに歴史に当たるのは結構重要だと思います。

最近だと、Real World HTTPもHTTPの発展の歴史を織り交ぜつつ、コードとロジックで実践するタイプの本になってて、めっちゃ良かったです。

www.oreilly.co.jp

1年どころか1ヶ月1週間で劇的に状況が変化していく今だからこそ、歴史に当たるというのも大事なことだと思います。 Libraryの歴史とか、言語の歴史とか。

最後に

エンジニアリング組織論はいいぞ。

P.S.

著者さんのTwitterのbioに『「エンジニアリング組織論への招待」というタイトルの本を書きました。控えめに言って名著です。』って書いてあって笑いました。 悔しいですが、控えめに言って名著です。

twitter.com

DevFest 2018 Tokyoに参加してきた話

TL;DR

DevFest 2018 Tokyoに参加してきたけど、すべてのセッションを聞くことは分身するか時間遡行しないと無理だったのでレポートだよ! 他の人も書いてくれると私が他のセッションに参加した気になれて幸せなので、書いて欲しいっす。

tokyo2018.gdgjapan.org

参加したセッション

技術領域 セッションタイトル
Web 仮)実践!!Web パフォーマンス改善!
Web PWAのイマ
ML Google AIY Vision kitで遊ぼう ~麻雀牌のリアルタイム識別
Flutter FLutterとの1年
Firebase Realtime Database for high traffic production application
Web TypeScript導入で得られる「変えていく勇気」
Firebase Firebase Realtime Database in Production

Webばっかりに偏るかと思ったら、意外とバランスがいい感じになりました。

セッション詳細

仮)実践!!Web パフォーマンス改善!

基本情報

内容メモ

  • ライブコーディングをしながら、自作したウェブサイトのパフォーマンスを改善していくというセッション。
  • 作成した釣りのブログでまず、Lighthouseで現状分析 -> 18点
  • ひたすら改善
    • リソースのサイズを圧縮(gzip化 / コードのminify)
    • 使ってないCSS/JSを送らないようにする(Code splitting / Dynamic import )
    • 画像の最適化(tool入れる / CDN活用 / Lazy Load)
    • リソースの取得順を調整(Resource Hintsでpreconnect / font-displayでフォント戦略の設定)
  • 最終的にはLighthouseで99点
  • パフォーマンスの改善は1つ改善して、auditsするの繰り返し
  • JSはDownload -> Parse -> Compile -> Executeの4段階を持つので、コストが高い
  • 高速なJSは4つのすべてで速い
  • Page Load時に見えるところを最優先して、地道に減らしていく
  • ほとんど同じ話がWeb performance made easy (Google I/O '18) - YouTubeで見れる

感想

  • devtools、めっちゃ便利
  • Webパフォーマンス改善のやっていきが高まった
  • ライブコーディングで改善前と改善後の差が一目瞭然で、分かりやすかった
  • ライブコーディング用のCheatsheetの用意めっちゃ大事

リンク

www.youtube.com

PWAのイマ

基本情報

内容メモ

  • PWAの魅力の1つは、UXがよくなること
  • PWAはNativeアプリをインストールするほどにはロイヤリティが高くない人にもアプローチできる手段
  • PWAはだいたい2つの技術でできている
    • Service Worker
    • Web App Manifest
  • SafariのPWAはかなり渋い
  • GitHub - Polymer/pwa-starter-kit: Starter templates for building PWAs.でPWA with Polymerができるし、PWAに限らないhelper関数を提供してくれる
  • PWAがGoogle DevelopersのWeb Fundamentalsにあるように、Webアプリの必須項目になりつつある
  • 世界的に見れば、Android優勢な国ほどPWAの成功事例が上がってきている(Ex. スタバ、航空会社)
  • 日本はApple次第かも
  • PWAは完全にNativeアプリを置き換えるものではない、あくまで別物
  • ページロードのタイミングで通知の許可を取りに行くのはアンチパターンオブアンチパターンなので、絶対にやらないこと
    • アプリでは、起動時に許可を求めるので、それと同じにしがちなウェブサイトがかなり多い
    • 1度、拒否されると現状では2度とアプリから通知の許可を求めるバナーを出すことができない
    • PWAはロイヤリティの低いユーザー向けなので、ストーリー設計がより重要になる

感想

  • iOS SafariのPWA対応が想像以上に渋くて驚いた
  • 世界的に見ると、PWAじゃないの?マジ?みたいな世界線になりつつあるのすごい

リンク

Google AIY Vision kitで遊ぼう ~麻雀牌のリアルタイム識別

基本情報

  • Presenter: RIo Kurihara
  • 資料:後日公開

内容メモ

  • 麻雀が好きだけど、符計算ができない -> 物体検出で符計算させるアプリを作ろう
  • 先輩の協力でイケてる学習モデルができた
  • 東北大学の学生チームとか、KDDIによる麻雀アプリがリリースされて焦る
  • LINE Botの開発をしたが、若干もっさり...
  • Google AIY Version Kit(スマートカメラ自作キット)でやろう
  • 実演デモ
    • 速度は改善したが、学習モデルの制約で精度は低い
  • 今後の展望

感想

  • ものづくりしてて、めっちゃ良い発表だった
  • エッジ・モバイルデバイス上でMLを動かすニーズが高まってきてる -> TensorFlow.jsのとかに繋がってきてるのだろうか
  • 実演デモで「3筒」とか「5索」がきちんと認識された
  • 実演デモで「發」が「西」に認識されてた
  • どれぐらい早くなったのか分からなかったので、比較みたいなの欲しかったかも

Flutterとの1年

基本情報

内容メモ

  • FlutterをProduction投入して1年経ったので、四方山話
  • 去年のGoogle I/Oから使ってる
  • 思うように動かなければ最悪、ネイティブで書けるとの確信からproductionへ投入
  • Hot Reload便利
  • Dartでのクロスプラットホームのコード共有率は、画面数ベースで95%、コードベースだと70%
  • ちょいちょいネイティブとFlutterの連携画面がある(OpenCV使う、テキスト周りのバグ回避)
  • Alphaから使ってるので、バグを踏み抜いてきた
  • BetaになってだいぶFixされた
  • UIのバグは大抵、回避策がある

感想

  • Flutter、よさそう
  • Flutterもreact-nativeも、クロスプラットホームは特殊文字が含まれるテキストは鬼門感がある
  • Alphaから使っていて、どっちのプラットフォームもネイティブコードを見れるってめちゃくちゃすごい
  • Hot Reloadは最高

Realtime Database for high traffic production application

基本情報

内容メモ

  • Firebase Realtime Databaseをproductionに投入して1年経ったので、開発と運用と少しの技術的テクニックの話
  • メルカリチャンネル(Live e-commerce)で使っている
  • 開発
    • クライアントからは直接、Firebaseを叩かずに、メルカリのサーバーを挟んで、サーバーからFirebaseのAPIをcallする構成にしている
    • この構成によって、更新頻度の間引きや禁止ワードのフィルタリングなどができ、Realtime Databaseに対するクライアントのpermissionを考えなくて済む
  • 運用
    • メルカリは全体で59000/secのAPI callがある規模感
    • メルカリチャンネルはだいたい1500stremers/day, 30K viewers/day, 5M yen / streamという規模感
    • Realtime Databaseはauto scaleしない、かつdatabaseごとに制約があるので、自前で15台以上のインスタンスを立てて、Vertical Shardingしてる
    • 今ならFirestoreがあるよ
    • モニタリングは自前ツール(KibanaとMackerel)とStackdriverでダッシュボード化して、異常状態と正常状態を可視化
    • 「すべてのサービスは落ちる」ので、問題発生->検知->対応のフローを迅速かつ円滑にいくように整備
    • メルカリチャンネルはしかるべき権限を持つ人がボタン1つで、メンテナンスモードに切り替えられる
  • Cloud FirestoreとRealtime Databaseの違いはThe Firebase Blog: Cloud Firestore for Realtime Database Developersを読んでね
  • 詳しいアーキテクチャが気になる人はRealtime Messaging with Firebase #phpcon2017 - Speaker Deckを読んでね

感想

  • メイン開発者のきりんさんがjoinしてから開発期間1ヶ月でメルカリチャンネル機能がローンチされてるのすごい
  • メルカリの規模感で本番運用してる知見、めっちゃ貴重
  • 障害発生時のAlertボットの配慮が行き届いて本当に良い
    • CSメンバーしか起きていないときでも意思決定ができるだけの情報を提供するために英語->日本語翻訳をかけてる
    • 障害発生は@channelだけど、復帰はつけない

リンク

TypeScript導入で得られる「変えていく勇気」

基本情報

内容メモ

  • Typescriptの歴史
    • JSは、HTMLの中に書けば手軽に動かせる言語から.jsファイルじゃない何かをJSへと変換して動かす言語に変化してきた
    • 変換するなら処理を足してコンパイルも変換に入れてもより安全にしたっていいんじゃない? -> Typescript
  • コードが腐る
    • コードは変わらないけど、コード以外の部分(チームメンバーの技量、増減、仕様変更etc.)が劇的に変わっていく
    • 現代では、常にリファクタリングが求められ、それを行うためには「変えていく勇気」が必要
  • 型検査の安心感
    • とはいえ、信用ならないこともあるので、値オブジェクトや混同防止プロパティを使っていこう
  • 継承は抽象的性質の表現、Not、処理の共通化手段
  • コンパイルエラーを有効に用いたリファクタリングメソッド:「炙り出し」の紹介

感想

  • 型定義ファイル、昔はnpmで管理できなかったのか...つらそう...
  • 昔は.js.tsを混ぜて運用もできなかったのか...つらそう
  • とある人が型検査は第1のテストって言ってたけど、まさにそういう話だった
  • なぜ今Typescriptなのかという歴史から入って、実際にどんなTipsがあるかの紹介の構成は本当に分かりやすかった
  • Typescriptやりたみが高まった

リンク

Firebase Realtime Database in Production

基本情報

内容

  • AI MessengerというBtoB向けのチャットボットにFirebase Realtime Databaseを使っている話
  • データの書き込みはメルカリと同じく、Clientから直接Firebase Realtime Databaseは叩かず、一旦サーバーを経由する
    • メルカリと同じ構成ではあるものの、その理由はちょっと違い、主にRealtime Databaseのクエリの制約の厳しさ・データマイグレーションの大変さから
  • いくつかの技術的問題にどう対処したか
    • Realtime DBは意外と書き込みの反映が遅いので、Client側で管理が必要
    • 値のクエリでフィルタリングが非常に苦手なので、データ設計の段階からそうならないように考慮すべき
    • Firebaseで大量のデータにFilterをかけるとReadが100%になり、読み書きが停止する。Googleから何したんだと連絡が来たらしいw。Big Tableへのダブルライトで回避
  • Full ManagedなServiceだろうと、すべてのサービスは止まる
    • だが、BtoBなので、サービスが止まるは許されない(元々の仕様では、そこまで厳しいダウンタイム運用になる予定ではなかったらしい)
    • Realtime DB障害時はBigTableなどにダブルライトされているデータをPollingして擬似的にRealtime DBを再現
  • Cloud Firestoreへの移行していきたい

感想

  • 奇しくも、きりんさんのセッションとほぼ同じタイトルで、青野さんも苦笑いしてた
  • それだけFirebase Realtime Databaseがアツいということでもある
  • サービスを止めることができないという要件がPJ最初期に上がっていたら、Realtime DBの選定には行かなかった可能性もありそうな感じだった
  • Realtime DB、工夫が結構いりそうだった

リンク

全体を通して

  • セッション間の移動がめちゃくちゃ混んでて、運営チーム大変そうだった
  • Google Dev User Groupめっちゃあって、コミュニティ多くて楽しそう
  • セッション7本連続で聞くと、頭がパンクする
  • Realtime DBの話、2つあったが、別のサービス間で使い方の似ている所、違う所が比較できて良かった
  • 部屋が満室で入れないのは悲しい
  • WiFiはできれば、欲しい
  • セッションのプレゼンターは、ウェブ・ネイティブアプリ・MLなど色々なバックグラウンドの人が集まるので、どういう発表の組み立てにするか苦心しそう
  • 全体的なやっていきが高まった

最後に

運営チームの皆様、発表者の皆様、素敵なお祭りをありがとうございました!🎉

P.S.

DevFest 2018 Tokyoの資料をまとめてくれている方がいらっしゃるので、他のセッションの資料が見たい方はご覧ください

技術書典#4の戦利品の感想の話

はじめに

もう、技術書典#4から1ヶ月近く経ってしまいましたがようやく戦利品すべてを読了したので軽く内容紹介と感想をば。

戦利品一覧

  • 技術季報
  • Cheap Dive into React Native
  • ネコミミでもわかるフロントエンド環境構築
  • オレオレ仮想DOM作りたいだけだった
  • こまるUI よくしてみた本
  • Libraries of React
  • Get Ready for Next.js

感想たち

基本情報は技術書典4公式サイトより一部抜粋。

技術季報

基本情報

  • 運営チームによる公式パンフレット
  • サークルマップ(物理)とか技術書典レポートとか特別寄稿が掲載されてる
  • 技術書典

感想

  • 運営へのお布施のつもりで購入
  • 技術書典レポートめっちゃ面白い
  • 特別寄稿は、普段の情報収集では入ってこない情報の発見がある
  • あまりに面白かったため、技術書典に参戦したあとの喫茶店でほぼ読破した
  • 初めての人は買っておくのが吉
  • 次回も買う

Cheap Dive into React Native

基本情報

  • なかざんさんのReact Native本
  • 技術書典後払いiOSアプリをcreate-react-native-appで作った話
  • React NativeでWebアプリとAndroidアプリを同時開発した話
  • React Native Androidの内部実装の話

感想


ネコミミでもわかるフロントエンド環境構築

基本情報

  • 汐瀬なぎさんのフロントエンド環境構築本
  • ネコミミ

感想

  • package.json, yarn, npm, babel, webpack, ESLint, Prettierなどフロントエンド環境構築で単語だけは知ってるみたいなやつらを丁寧に解説してくれている
  • Jest, Flowも解説してくれている
  • めっちゃわかりやすい、もう2週間ぐらい早く読みたかった
  • フロントエンド、魔法の言葉多くて怖い人におすすめ
  • ネコミミはいいぞ

オレオレ仮想DOM作りたいだけだった

基本情報

  • ukyoさんのオレオレVirtual DOM実装本
  • Virtual DOMのアルゴリズムとか色々

感想

  • React Nativeを仕事で触っているので、役に立つかと思い購入
  • ukyoさんに「Virtual DOM実装するには役に立つけど、React書くには役に立たないと思う」と言われたw
  • JSXがJSでどのようにトランスパイルされるかから始まり、VDOMのレンダリングロジック、ライフサイクルメソッドの実装、果てはReactFiberの簡単なやつを使った非同期レンダリングの実装と盛りだくさん
  • 完全には理解できなかったので、読みなおす
  • VDOMのレンダリングロジックを知っていると、最適化に役に立つかもしれない
  • Virtual DOMが作りたい人におすすめ
  • ダウナーな女の子が目印

こまるUI よくしてみた本

基本情報

  • いしまるさん、ゆずさん、ナユさんの共著
  • UI本

感想

  • あー、これ見たことあるというUIがいっぱい
  • 解法もいっぱい
  • ユーザーとして使っているときは、なんだこのUIと思うものの、作る側になるとすぐに忘れるので気をつける
  • noteで読める
  • 「こまるUIよくしてみた本」for note #技術書典|ナユ|note
  • ブースで草ステッカー売ってた
  • 表紙の女の子が持ってるのは積み木?

Libraries of React, Get Ready for Next.js

基本情報

  • どちらも著者はれいなさん
  • ReactのtipsとNext.jsの入門書

感想

  • Libraries of React
    • ReactのStateless Functional Componentの書き方やJSX記法など明日から使えるテクニックがいっぱい
    • ライブラリとして、recompose, Parcel, styled-componentsの3つを紹介
    • styled-components導入したさがある
    • 表紙は魔女っ娘
  • Get Ready for Next.js
    • Next.jsとNuxt.jsの違いに気がついておらず、Nuxt.jsの入門本だと思っていた
    • Next.jsはReactのServer Side Renderingライブラリ、Nuxt.jsはVuewのServer Side Renderingライブラリ
    • Next.js、めっちゃシンプルっぽいので触ってみたい
    • Server Side Renderingの利点とかなぜするかがいまいちよく分かってないのでその辺を調べねば
    • 表紙はメイドの人形
  • どちらもBOOTHで買える
  • れいな@底なし沼の魔女 - BOOTH(同人誌通販・ダウンロード)

おわりに

なんだか販促記事みたいになってしまいました。 今回は、ReactやReact Nativeなど割とフロントエンドに焦点を当てて買ってきましたが、次回はもうちょっと裾野を広げたい。 次回の技術書典でも素敵な技術書に遭遇できますようにと祈りを捧げておきます。

おしまい