builderscon tokyo 2018 1日目に参加してきた
行ってきたーーー！
全部のトーク聞けないのもどかしすぎたけど、選んだどのトークでも「知らなかった、を聞く」を圧倒的な衝撃をもって体験させてもらった。
エンジニアになってよかったって、身体にすとんとくる感覚があった。明日も楽しみ。
トーク
トークはこちら↓↓を拝聴した！
全部メモを取ってたんだけど、ちょっと内容に自信無いものもあるから抜粋で記事にあげた。
産業でガチ利用されるRaspberry Piの話
産業でガチ利用されるRaspberry Piの話 - builderscon tokyo 2018
by @kazuph さん
ラズパイほんとに使われてるんだ……！ っていうレベルのガチ無知だったりしたんだけどちゃんと聞けたw
セキュリティとかログとか、webと同じテーマだけど違う制約の問題になっているところが個人的に面白かった！
開発現場で役立たせるための設計原則とパターン
開発現場で役立たせるための設計原則とパターン - builderscon tokyo 2018
by @shinpei0213 さん
あるあるすぎる課題を「『デザパタによる構造化』と『設計原則によるレビュー』とのサイクル」で鮮やかに解決しててテンションあがった！
事前知識なしで理解する、静的検査のいろは
事前知識なしで理解する、静的検査のいろは - builderscon tokyo 2018
by Kuniwak さん
スライドめちゃくちゃわかりやすかった！ 構文解析をひとさらいするとソースコードとかエラーメッセージとかの見方が変わって面白いなーと。
これからRubyやるし、rubocop読もうというきもち。
これはスライドが完璧すぎて足すこと無い……w スピーカーの方がブログ記事上げていらしたので貼らせていただきます↓↓
機械学習を用いず数学でゲーム内の需要予測をする
機械学習を用いず数学でゲーム内の需要予測をする - builderscon tokyo 2018
by @nessie_sesein さん
数学徒な名言がばんばん出てきて楽しかったw 黒い羊の寓話を体現するようなセッションだった。
airflowを用いて、複雑大規模なジョブフロー管理に立ち向かう
airflowを用いて、複雑大規模なジョブフロー管理に立ち向かう - builderscon tokyo 2018
by Attsun さん
airflow気になってたから聞けてよかった。Pythonのコードで管理っていうのイメージつかなかったけどふむふむ、てなった。
サーバー大丈夫か……？ てなったけど豊富な余力があるのねブレインパッド……！w
スライド公開されてた！
builderscon2018 airflowを用いて、 複雑大規模なジョブフロー管理 に立ち向かう - Speaker Deck
安全なランダムネスの理論と実践
Safe randomness: theory and practice - builderscon tokyo 2018
by Kenji Rikitake さん
はずかしながら全然考えたことなくて、PCのハード部分（打鍵とか）からランダムネスを生成する発想も知らなかった……！
こちらもスライド公開されてた！
Safe randomness: theory and practice - Speaker Deck
lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話
lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話 - builderscon tokyo 2018
by Rui Ueyama さん
ちょっとこのトークの感動はまだうまく言語化できてない……。
メモだけ↓↓
builderscon tokyo 2018 聴講メモ #4「lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話」by Rui Ueyamaさん
（スライド公開されたら貼らせていただきます）
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。
lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話
@rui314
テーマ
- lldの紹介
- 開発を始めた経緯
- 速くてシンプルなコードを書くためのポイント
- 具体的な高速化のテクニック
テイクホームメッセージ
- 問題についてよく考えて、自分が良いと思うやり方を勇気をもって試してみよう
仮にアンチパターンであっても - 存在しない問題を作り出さない。もともとの問題を直接解決できないのか、をよく考えよう
- 「Unixの開発環境の標準リンカになる」という大きな目標も、誰も挑戦しないだけで意外と実現可能だったりするので、挑戦してみよう
内容
- リンカ：オブジェクトファイルを1つの実行ファイル・DSOにまとめるもの
- 何もしないプログラムのソースコードを、既存のリンカに入れて、出力されたバイナリを印刷して読んだ
→ 1bitだけ変えてみたりして理解していった。 - 当時、Linux, Windows, mac OS すべてファイル形式違うのにひとつのリンカでやっていた
→ スクラッチで書き直し。Windowsだけターゲットとするようにした- 「書き直したくなる気持ちはわかるけど」「リファクタリングでいいのでは」などの意見
→ 無視して書いたら10倍早くなった。 いちいち対応してると 無い問題を解決しようとすることになる - 遅いプログラムを構造によって早くすることはできないが、構造によって自然と早いプログラムが書ける
構造が先、コードは後
- 「書き直したくなる気持ちはわかるけど」「リファクタリングでいいのでは」などの意見
- 他の人が、同じデザインでLinuxのリンカを作った → 4バージョンに対応することに
- OSSとして、オーナーシップを持っておく
- 1回しかコントリビュートしない人が、自分の（狭いスコープで）達成したいことのためにプルリクを出してくる
→ 送ること自体は良いが、それを取り入れるかはオーナーが判断する
きれいなコードはオーナーが保つ
- 1回しかコントリビュートしない人が、自分の（狭いスコープで）達成したいことのためにプルリクを出してくる
- 2回書く ← 1回目から学ぶ。できれば3回書く
質疑
- 「コードを2, 3回書き直してみる」：最初のコードに引きずられそう
1回目書いてるときに思った「ここをこうしてみたら」を次に実践してみる、思いつくものは全部試す感じ。
しっくりくるものを探す。 - 「コードを共有しない」：改修コストがある反面、共通化するとif文が増えたりする。どう選んだ？
勘です。 - 次の目標は
Linuxのディストリビューション全体が10秒でビルドされる、とか？w
カーゴ・カルト・プログラミングはやらない。
80年代に決められたデフォルト値に従う理由は無い。
感想
さいしょわかんないとこ来ちゃったーと思いながら聞いてて、終わったときにはエンジニアとして何かを叩き起こされたような感じで、まだうまく言葉にできない……。
すごく素敵なセッションだった。動画公開されたらまた改めて聴いてみる。それでできれば改めてまとめてみる。
builderscon tokyo 2018 聴講メモ #3「機械学習を用いず数学でゲーム内の需要予測をする」by @nessie_seseinさん
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。
機械学習を用いずに数学でゲーム内の需要予測をする
@nessie_sesein
カヤックのゲームレベルデザイナー
テーマ
純粋数学の見方・考え方を理解する
分析の重要性と問題
- 数学について
- ゲーム内の需要予測
テイクホームメッセージ
なぜの追求、数値と言語の行き来
- 理論ベースで需要予測を行うと、機械学習とは違って未来を最適化するアクションが見えやすい
- データが少なくてもいける
- 時間が経つと予測がズレるが、原因を見つけやすい
内容めも
- 分析の重要性と問題
- 純粋数学
- 証明するまで正しさを認めない、見える範囲の事実にだけ言及するのが数学
- なぜの追求：事実以外の認知をしたとき、なぜ自分はそう考えた？ を追求する
- 数値と言語の行き来：数値による根拠を元に認知する。バイアスを取り除く
- ゲーム内の需要予測
あるある：「新規ガチャ売れた → 復刻ガチャでも売れるでしょ！」← なぜ主観的予測がこうなるのか？
もし売上構成が「課金上位者10％が売上の90％を占めていた」場合、その人達がガチャをコンプリート・カンストしたら買わない
→ 残りの課金下位90％（売上の10％を占めていた）の人達だけが復刻ガチャに課金しうる- 前提条件とゴールの設定
- データを眺める
サンプル500くらいあればいいと統計学的には良いと言われるけど、高々有限なんだから全部見ればいい。
自分は5,000くらいは眺める - 仮説作成
- 仮説を数値に落とし込む
ゴール（ユーザーがガチャを何回回すか）と相関がありそうなものから順番に処理。
「レベル5になったら何人かのユーザーは満足しちゃうかな」→ とりあえず8割くらいガチャやめるとする
端点さえ合っていれば中身はどうとでもできる
= 相関係数を元に一度 y = ax + b を用意して、例えば上側にふくらむ非線形の式にしたいのであれば、上側にふくらませるf(x)をかける
→ y = (ax + b)・f(x) - 例外処理・微調整
土台の式ができても、3割くらいはズレている → 外したり、影響を小さくする関数をはさんだり
→ ゴールと相関のある部分を求めて、例外をつぶしていく
- 施策
改を出す前に、☆5の排出率を上げて、改を欲しがりそうなユーザーを増やしておく → 売上144% - 機械学習
ユーザー数はあっても、1ユーザーあたりの試行回数が少ないと処理する例外が多くなる。
前処理しやすい、DBが機械学習用に整っている、データが多い、というケースでは機械学習が適用できる。
そうでなければ理論で予測したほうがいい。
質疑
- 今のお話に必要な数学的素養を身につけるのにおすすめの本
普段から「なぜ？」を考える癖をつけてみるといいかも - ドメイン知識・仮説
自分が「なぜ」を追求して、誰にでもそれを説明できるように用意する。
自分がユーザーにもなって、行動経済学や心理学の知見ともあわせながら説明できるようにする。
感想
面白かったあー！
言葉の端々に数学徒感が出てて楽しかったw 「高々有限なんだから全部見る」は名言。
定理・公理や数式ではなくて、なんていうか「"数学的"なものの見方」にこだわって話を進められていた。
質疑にあったように日常的な習慣づけで数字の扱い方を変えていけるんだなって素直に思った。
でも別に知識が何もいらないということではなく、普段からなぜを考えていくことで知識の身につけ方も変わっていくのかなあとか。
大人になったあとの勉強の仕方もあるかもしれないと思った。
builderscon tokyo 2018 聴講メモ #2「開発現場で役立たせるための設計原則とパターン」by @shinpei0213さん
（スライドもし公開されたら貼らせていただきます）
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。
開発現場で役立たせるための設計原則とパターン
by Shinpeim
『WEB+DB vol.91』データ構造特集がおすすめ
テーマ
- このケースで何が最適か、どうやって判断するの？
「適材適所」「ケースバイケース」は何ら回答になっていない
テイクホームメッセージ
- 複数の選択肢を用意する → 問題の「変わりやすいところ」を考慮して設計原則からレビュー を繰り返す
- 設計原則
- 単一責任原則
- 開放閉鎖原則
- 凝集度・結合度
内容めも
設計・パターンは抽象的な話が多く、空中戦になりがち
- 「抽象化」って人による
- 「責務」って考え方による
「システム全体に責務を持つからSystemManagerクラス作ろう」← 反論できるか？
そもそも設計って？
複数の分割構造の選択肢から 選び出す こと。設計原則・デザインパターンはその武器- デザインパターン：カタログ
- 設計原則：良い構造かを判断する指針
パターンを使って分割する ⇔ 目の前に立ち上がってきた構造に対して、原則を使ってレビューする
例題：掲示板ウォッチスレ 投稿通知機能
単一責任原則
でも「責務」ってふわっとしてる……
あるモジュールを変更する理由が2つ以上あってはいけない
「なんとなく駄目」だったのが「コメント通知の仕様変更でもスター通知の仕様変更でもこのクラスに変更が必要になるから、駄目」になる開放閉鎖原則
例題：引き落としできなかったらsuspend、3回引き落としできなかったら永久追放
新しい機能を足す時に、既存のクラスを書き換える必要がある ← 拡張に開かれていない凝集度と結合度
凝集度は高く、結合度は低く- Customerに関する操作をCustomerSuspenderにやらせてしまっている
- Customerにとって他人であるCustomerSuspenderの処理をCustomerが何度も呼ぶ必要がある
「なんかオブザーバーパターンっぽくね？」ってにおいを感じる
- CommentObseverを作ると、そいつはスターというイベントは完全スルーできる
- パターンに従ってCommentとCommentObsercerを分けてみたけど、分ける必要はあるのか？
そもそもオブザーバーパターンて何だっけ、から「開放閉鎖の原則」を評価軸にする- 今回のケース、拡張される？（コメント発生時に通知以外のイベントが足されることある？ オブザーバー足される？）
→ 結合度はOKだが、現実的な未来予測について見るとそもそも分ける必要があるのか不明 - 今回のケース、修正に対して閉じなければならないの？（コメントの仕様が変わったとき、通知の仕様はそのままなの？）
→ むしろ凝集度がNG
- 今回のケース、拡張される？（コメント発生時に通知以外のイベントが足されることある？ オブザーバー足される？）
- パターンを使って構造化したとき、設計原則を使ってレビューすると「実は不適切では」ということもある
Commentクラスにひとまとまりにしてしまう
単一責任原則はどうなる？ まざっているのでは？- コメントの仕様が変わる（→ 通知の仕様もきっと変わる）ときに、Commentクラスだけの改修で足りる
→ 単一責任原則を満たしている
- コメントの仕様が変わる（→ 通知の仕様もきっと変わる）ときに、Commentクラスだけの改修で足りる
まずは問題を見極める = どこが変わりやすいポイントか
コメント発生時に通知以外のイベントが足されるのであれば、オブザーバーパターンでよかった。
どこが変わりやすいポイントかがわからないと、単一責任原則で設計のレビューができない未知の問題に対する解決
どこが変わりやすい（やわらかい）部分で、どこが変わりにくい（固い）部分なのか、まずは問題と向き合う。
KISS原則、YAGNI原則
質疑
- 設計原則について適用フェーズによって分けられるかも？（← あまり聞こえなかった）
SOLIDの原則のうちSとOが今日の話だった。KISSやYAGNIもやや抽象的なもの。
LとかDは抽象度が低く、自分で構造を考えるときに使えるかも。 - チーム開発で、設計レビュー時には一通りコードを書いてしまっている
前職は採用時に絞っていて、暗黙知で通っていた。
現職では設計レビューうまくできていない。
感想
「なんかあかん」設計にデザパタ適用して、それをさらに設計原則からレビューする、ていうサイクルを実演してみせてた。
オーディエンスが例題見た時に持った「なんかあかん」をきれいに議論に落とし込んでてとてもスマート、聞いててテンションあがった。
自分のためにもチームのためにも、パターンと原則を武器として身につけねば……！
アニメと構成そろえてて、合間合間に息子さんのショットが入るの和んだw
builderscon tokyo 2018 聴講メモ #1「産業でガチ利用されるRaspberryPiの話」by @kazuphさん
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。
産業でガチ利用されるRaspberryPiの話
@kazuph
- 日本で最初のスマートロックAkerun
テーマ
- なぜラズパイ？
- 利用実績
- より強固なデバイスにするために
- ラズパイで駄目な場合
テイクホームメッセージ
- ラズパイが完全に品質面で他を圧倒している
- ラズパイが完全にIoTレディーになった（Wi-Fi, Bluetooth対応によって）
- ラズパイが同類では最安
- 大量のソフトウェア資源があるので、試作・開発コストが低くて済む
内容めも
ラズパイ：高い品質・安価・汎用的な開発環境・安定供給
利用実績
- Akerunプロトタイピング
秋葉原で買える、Pythonで書ける。買い出し含めて1日でできる。 - 組み込み製品のデバッグ
Node, Python, Golang
Jenkinsでビルドしたイメージをラズパイ経由で組み込み製品に反映させる - 工場での出荷ツール
状態をラズパイ経由で飛ばしてPCのブラウザから確認できる
向上ツール開発祭り（治具祭り）← テンション上がらないので「祭り」として数日間実施
工場でAnsible：物理的に組み立て → 検査 → 自壊プログラムを流し込む → Ansibleを流せなくする
2016年から一回も交換なし - IoTゲートウェイ
工場で実際に使っていて、大丈夫だと思った
BLEが標準搭載になって、別途ドングルを買う必要が無くなった
性能：1m離れたところで計測すると、旧製品が25％くらいだったのがラズパイで80％近く
5m離れると差は小さくなる、これはBluetoothの仕様として当然- 電源まわり：
ラズパイだけだと怖い。雷サージ対策済みのACアダプタ、拡張基盤で静電気対策 - ログ：
容量・I/O上限・接続できない（お客さんの環境に置いてあるので）
→ すぐ削除、できるだけオンメモリ、S3に日次アップロード - セキュリティ：
大事なものはSDカードに置かない
機密情報はすべて拡張基盤（nRF52）
ゲートウェイ起因でクリティカルな処理が行われないように。乗っ取られても開かない（サーバーからの指示が必要）
あくまでゲートウェイとして暗号化されたあれこれを仲介しているだけ、「開ける」という動作を起こせない - ソフトウェアアップデート
nRF52でイメージ作成・更新してラズパイに反映させる（？）
- 電源まわり：
- Akerunプロトタイピング
ラズパイでは駄目なとき
質疑
- 使う上で気をつけること
正直あんまりケアしていない。濡れたり静電気とかは別だけど、雑に使っても意外と大丈夫。
SDカードは耐久試験して使ってる。良いやつを使うべし - ゲートウェイとして使うとき、ラズパイがどこかに置いてあると思うと物理的なセキュリティが気になる（SDカードが抜かれていじられたり）
レンタルというビジネス形態上、SDカードを抜けないようにはしていない。
スマートロックの場合、基本的にラズパイは室内に置いてあるのでいいでしょうと思っている。 - ラズパイの次のバージョンで改善してほしいところ
今でもLinuxベースなので改善はしていけると思っている。
IoTまわりの通信規格、新しいのが出てきている。範囲が広く、通信量も保てる規格が出たらそれに対応したくなると思う - 5GHz対応が必要になる場合というのは 企業ユースの場合、5GHzを必須で求められることがある
- TensorFlow？
うちでは使ってない、ファームビルドが対応してるよという紹介だった。最近ラズパイ用のビルドが出たので使ってる人もいるらしい - SDカード選定
メーカーを選定 → 連続で書き込み・読み込み - ラズパイ0
安価で小型で、良いなと思っている。
ただ品質がまだ不安、有線LANに対応しておらずtoBだと合わないかもしれない。 - SDカード
T社じゃないですかねw
感想
使ってみたくなった！！
組み込み系ぜんぜんやったことなくて用語がたまにわからなかったけど、WEBなところもあって（むしろWEBとの境界が曖昧になっていて）意外とわかりながら聞けた。
セキュリティとログみたいに、WEB開発と同じテーマで前提の違う解決をしてるの知っとくとWEB開発にも活かせるところがある気がした。
夏休みの思い出に横浜でなんちゃって開発合宿してきた
書いてたら長くなっちゃったから一言で言うと↓↓
軽いノリで遠出をして、その中のアトラクションのひとつとして勉強・開発を入れてみたところ、心身を休めつつ充足感も得られて楽しかった という話。
なんちゃって開発合宿
ふと思い立って、東京23区内に住んでるエンジニア2人で「なんちゃって開発合宿＠横浜」してきた。
「なんちゃって」なのはさして開発もしてないし別に合宿と呼ぶような距離でもないため（笑
他に呼び方が思いつかなかったから「開発合宿」と書いてみたけど、
あくまで余暇としての遠出で、その中のアトラクションのひとつがカフェでの勉強・開発 という感じ。
経緯＆目的
- 夏休みを取った！
- 旅行でも行きたいねー
- でも雨らしいよ
- ひきこもるかー
- 出かけて開発しよう
前から1人か2人でビジホ開発合宿やってみたかったというのもあり、こうなった次第。
会全体の目的は、別に話し合ったわけでもないけどたぶんこんな感じ↓↓
- 気分転換
- やろうと思いつつやれてないことをやる
拠点
作業拠点
横浜ランドマークタワー地下1階にある BUKATSUDO さんのコワーキングスペース WORK LOUNGE を使わせていただいた。
- 最寄り駅は桜木町とみなとみらい
- 電源・wi-fi完備
- ドロップインは1時間500円、4時間以上2,000円
- 初回利用時に会員登録が必要（300円）※ 要身分証明書
申込書類には自分の住所等のほかに会社名も書く。 - 利用中出入り自由
利用開始時、会員カードと交換にセキュリティカードをもらい、ゲートにかざして出入りする。 - WORK LOUNGE 内は原則おしゃべり禁止
カーテンで区切られたソファスペースは商談・打ち合わせOK。 - 飲食物持ち込み可
ただし食事は WORK LOUNGE の外にあるフリースペースで。 - コワーキングスペース以外にレンタルキッチンとかあるっぽい
- 有料のコーヒー（おいしい）と焼き菓子がいい匂いしてる
横浜近辺には他にもいくつかノマドカフェあるみたいだったけど、土日に長居するのに勝手がよさそうだったからここに。
静かだしおしゃれだしソファだしでとてもよかった、正解だった！
宿泊拠点
新横浜のフジビューホテルさんにお世話になった。
連れの要望で大浴場が欲しいとのことだったので、温泉付きのここを予約。
新横浜フジビューホテル スパ＆レジデンス｜新横浜のホテル｜新横浜スパ天然温泉・岩盤浴
- 部屋（ツイン）きれい、満足
- 温泉は弱アルカリ性、ややぬるぬるで良き
- 浴槽が熱めとぬるめで分かれてるのも良き
- サウナも良き
- お風呂場のアメニティは必要十分
ただシャンプーの質はさして良くない - 朝食バイキングは普通
- 土日の1泊温泉朝食付きで6,000円
予約プランによっては温泉・朝食がそれぞれ別料金かもしれない - wi-fiあったけどパスワードかかってなかった（から使ってない）
- 従業員さんたちがにこやかで親切！
直前に予約したのがかえって良かったのかな？ 総合的に見て満足度高いしコスパ良かったと思う、また来たい！
タイムテーブル（？）
綿密に計画立ててたわけではなく結果的にこうなった↓↓
- 金曜
- 22時 発案＆催行決定＆予約
- 土曜
- 10時 出発
- 11時 到着＆昼食
- 12時 籠城スタート
- 16時半 撤退
- 17時 ホテルチェックイン
- 18時 夕食
- 20時 温泉
- 25時 就寝
- 日曜
- 9時 朝食
- 11時 籠城スタート
- 15時 昼食
- 20時 撤退
- 21時 温泉
- 25時 就寝
- 月曜
- 9時 朝食
- 9時半 チェックアウト
- 11時 解散
やったこと
とにかく各人でもくもく。
私は「katacodaで今度こそdockerに慣れる」を目標にしてたからこれをメインにして
- katacoda
やっとやっとdocker使おうという気になった！ 次はKubernetesやる〜 - 『エンジニアリング組織論への招待』
会社で個人的にメンタリングを求められたから、参考にするためにメモを取りながら。 - ブログ記事執筆
これはホテルで。最近やってることを自分の中で整理するため。（11月か12月に公開するつもり）
いつものことをぎゅっと集中してやった感じ。
「わざわざ遠出してやることか？」という疑問もあるかもだけど、katacoda毎日ちょっとずつだとなかなか進まなかったしちょうどよい内容だったと思う。
あと実は前に会社で開発合宿（こっちは温泉旅館の開発合宿プラン）行ったことがあって、そのとき個人的な反省として「一人で作業するならアイデア出し・設計・環境構築はNG」「ゆえに、開発するならコーディングに取り掛かれる状態を事前に作っておくべし」というのがあったので、今回開発は考えなかった。
あんまり詳しく聞いてないけど連れは仕事の開発をしてたらしい。
感想＆反省
感想
休息と勉強・仕事を両立させられたのが何より良かった！！
のんびり休んだ感も何かがんばった感も両方得られた。
それ以外だと↓↓
- 気持ち：
- お金かけたしがんばらなきゃ、という思いがすこし生まれる
- 作業拠点と宿泊拠点分けたの、個人的には良かった。メリハリつけられた
- 観光的なことにあまり気を割かなくていい距離感で、今回の気軽な企画に合ってた
- 宿泊拠点：
- 洗濯もゴミ捨ても掃除も無いの最高
- 浴場なんだかんだ必要な気がした。部屋のシャワーだと日常感が出る
- 外に作業場を持つならホテルに作業環境はいらない
- 作業場：
- 出入り自由＆飲み物自由＆居眠り可なのが籠城要件な気がした
- 近くにコンビニがあれば最高だった
あと合宿とは関係ないけど、一日集中するために今後続けようと思ったこと↓↓
- 朝、作業に入る前に大学入試センター試験（の簡単な設問）を1問解く
- 昼食は炭水化物メインの料理を避ける
- 眠気で頭が重たくなってきたらあきらめてちょっと寝る
うしろ2つは前から気をつけてたけど今回改めて。
センター試験は試しにやってみたらちょうどよかったから続ける。数IAの簡単な計算でも頭を作業モードにするには十分だった。
反省
次はこうする↓↓
- 土日月じゃなくて金土日にする
金夜出発 → 土曜朝 〜 日曜夜で作業 → 日曜夜解散 のほうがどう見てもコスパよかった - 昼食・夕食の場所、できる範囲で事前に決めておく
せめて外で食べるか買って食べるかだけでも - 折り畳み傘を持っていく
買い物が発生すると開店時間まで待たないといけない
おわり
費用は交通費・宿泊費・コワーキングスペース代・外食代あわせて2万ちょっとだった。
またやる！
Geeks Who Drink in Tokyo -俺の!私の!ベストカレーEdition- でヌーラボTシャツもらった
backlogでいつもお世話になってるヌーラボさん東京オフィスにおじゃましてきた！
でなぜかカレーガチ勢のみなさんにまじってLTしてきたw
てんやわんやしてしまったけど、菊すけさんの山椒カレーうどんと湯布院の名湯が票を集め（笑）まさかの優勝を果たしてしまった↓↓
まさかの優勝！！ ありがとうございました！！ #GWD_Nulab pic.twitter.com/h6GnRSA61C
— hirapi (@chmv71) August 24, 2018
ご投票くださった方々ありがとうございました……！
メインのもうやんカレーものせとく↓↓
カレーとtechのいろんな話聞きながら食べるもうやん、良かった。
もうやんカレーおいしかった、サイドのうどんとチキンも主役級だった。nulab様もうやんカレー様ありがとうございましたごちそうさまでしたー！
— hirapi (@chmv71) August 24, 2018
#GWD_Nulab pic.twitter.com/wqgx6OeZ74
持って帰りたかったけど持てなさそうだったからその場で2杯食べた。仕方なかった。
それと、遅刻して最初のほう聞けなかったけど合間合間に流れてた動画を見るにヌーラボさんめっちゃ楽しそうだった……！
海外支社があると空気が自由なのかなあ、宮古島でリゾートワークうらやましい。
司会者の方も言ってたけど何のためのイベントだったんだこれは……w
でもたくさんお話しできたしカレーにちょっと詳しくなれたしTシャツも頂けたし、参加してよかったです！！
またおじゃまさせてくださいーw
