Productivity Engineering − Forkwell Meetup #4 行ってきた

【増枠！】Productivity Engineering − Forkwell Meetup #4 - connpass

上記イベントに行ってきた。
発表で響いた点のまとめ。

クックパッドにおけるモバイルアプリ開発の工夫　クックパッド @ichiko_revjune

• 機能ごとに開発チームを分割
  チーム内にデザイナー、エンジニアがいる
• リリースサイクルは2〜4week

実装

• 意図したとおりに実装できていること
• 効果が計測できること

方法

• 朝会
  増員に伴いチャットで行うようにした結果、他社への関心が薄れ、実装した機能のコンフリクトが生じて計測が正しく動かなかった
  そこでキックオフを行うようにした
• キックオフ(開発初期段階)
  対象はディレクタ、デザイナ、エンジニア
  大きな変更を共有
• 確認会(リリース前)
  UI/UX の一貫性を確認

これ朝会が形骸化しているってことなんじゃないのかな。どこでも起こりうることなんだな。 #forkwell_meetup

— kheiakiyama (@kheiakiyama) 2017年3月18日

Effective Retrospective　アトラクタ @ryuzee

• ふりかえりの目的
  「もっとうまくできるように」はみんな知ってる
  「仕事を急停止する」あまり知られてない。立ち止まって考える余裕を保つ
• 心理的安全性をつくる
• テクニック
  開始時に全員に口を開いてもらうと主体的参加度が上がりやすい
  施策は自分が実行者となってやる、くらいのものを少しだけ選んだほうがよい
  いっぱい採用してもどうせやらない

ふりかえりしたくなってきた。 #forkwell_meetup

— kheiakiyama (@kheiakiyama) 2017年3月18日

ふりかえりのときに全部アクション考えさせられたことがあって、ムダ感あったなあ。 #forkwell_meetup

— kheiakiyama (@kheiakiyama) 2017年3月18日

あるある>ふりかえりがワンパターンになって飽きる問題 #forkwell_meetup

— kheiakiyama (@kheiakiyama) 2017年3月18日

自己言及的なチームをつくる　GMOペパボ @june29

• 今日より明日をちょっとよくしたい
• 自分たちを変えるのは自分たちでしかできない

Make Jenkins Great Again　サイボウズ @miyajan

• 2.0 よい

最速で価値を提供する　ネクスト @masamichi

• 価値を高めるためにも、品質の共通認識をつくる必要がある
  品質の仕様化、言語化
  具体的には速度=レスポンスタイムやセキュリティ=脆弱性診断結果など
• 待ち時間や手戻りをなくす
  そのための情報共有ツール, CI, CD

品質の仕様化は、さきの発表で増えられてた業務の完了条件と同じで、言語化して共通認識つくらないと関係者が向かう方向わからなくなるんだよなあ。 #forkwell_meetup

— kheiakiyama (@kheiakiyama) 2017年3月18日

共通認識をつくるって視点では、経営者:会社の理念、開発チーム:業務の完了条件、品質保証:品質目標 みたいな感じで、ロール毎にそれぞれつくる必要あるものがある、って当たり前のことに気付かされる。 #forkwell_meetup

— kheiakiyama (@kheiakiyama) 2017年3月18日

ペアプログラミングの使いどころ　タワーズ・クエスト @t_wada

• How 考えを声出す、もしくは紙やホワイトボードに書く
• When メンバージョインしたとき、新機能実装、週1
• Why タスクは完了してこそ意味がある。並行作業で仕掛かりを増やすより1つずつ完了させる
  教育的側面、スキル伝授

Q&A

• 開発環境が人によって異なるのでは？
  開発環境の好みよりもチームの成功が大事だよね
• ペアにしかノウハウが残らないのでは？
  モブプログラミング
• 上級者にメリットがないのでは？
  教えることで知識の整理ができる

プロに限らずペア作業使っていきたい #forkwell_meetup

— kheiakiyama (@kheiakiyama) 2017年3月18日

ノウハウ共有できてない現場では情報共有ツールが・・・って話より先にペア作業から入ってみるのが一番お手軽で問題をより理解できるいい施策だと思う #forkwell_meetup

— kheiakiyama (@kheiakiyama) 2017年3月18日

ペアプロで説明することで学びになるのって、勉強会主催すると一番学べるってのと同じだな。ペアプロなら対象が1人だからハードルも低めだし。 #forkwell_meetup

— kheiakiyama (@kheiakiyama) 2017年3月18日

最後に

生産性向上っていう広い文脈だったので技術スタックの異なるいろんな人がいて面白かった。ありがとうございました。 #forkwell_meetup

— kheiakiyama (@kheiakiyama) 2017年3月18日

プログラマが知るべき97のこと

微分積分？何それ？Azure Machine Learning を使って実践から入る機械学習

はじめに

機械学習、流行ってますね。
流行りに飛びつくのはシャクだが、少しは理解を深めたい。
しかし流行りに乗じて本を買っても数学などの基礎部分でつまずいてあきらめていた。 そんな自分にも機械学習を始められた。
そう、Azure ならね。

想定する読み手

• 機械学習に興味がある
• 地道に数学を学ぶモチベーションが維持できない
• 動くプロダクトを早く見たい
• 学習コストを低く機械学習を始めたい
• 「ゼロから作るDeep Learning」を途中で挫折した

ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装

検証をはじめる前に

前提知識

さっそく手を動かしたいところだが、ちょっとだけこれを読んでほしい

一般的に機械学習で必要な手順は以下のとおり

1. 題材を決める
2. 元となるデータを用意する
3. モデルを作成する（モデル＝AI と思ってくれていい）
4. 結果を確認し、必要があればモデルを修正する
5. 4 を繰り返す

大事なのは1と2だ。
いきなり手を動かすにはデータがないといけない。
Azure Machine Learning にもいくつかサンプルデータが用意されている。

自分にはピンとくるものがなく、英語も読みたくないし、複雑なものは理解しづらいので自分で準備した。

https://raw.githubusercontent.com/kheiakiyama/HolidayEstimation/master/holiday.csv

日本の祝日かどうかを50年分出力したデータ。
人間もプログラムも読みやすいようにしたつもり。

github.com

上記プログラムで出力した。

Azureサブスクリプションを用意する

メールアドレスがあれば下のリンクから始められる。

azure.microsoft.com

正直 Azure はこのアカウント周りが非常にわかりづらく、最初のハードルになりやすい。

ログインに必要なのは Microsoft アカウントで、既存のメルアドから作成できる。
Azure のリソースを管理する単位が Azure サブスクリプションで、この単位で請求が来る。

登録にクレジットカードが必要になるが、有料の支払いをオンにしない限りは勝手に決済されることはない。
(ただしこの設定は一度オンにするともう戻せないので注意)
無料のクレジットがついているので、ちょっと試すくらいなら十分ペイできるはず。

Azure Machine Learning Studio で検証

モデル(experiment)の作成

いよいよ本題。
とはいえ説明することは特にない。

↓に大変よくできたドキュメントがある。

docs.microsoft.com

ドキュメントは日本語だが Machine Learning Studio が英語だと混乱しがちだが、ほとんどつまづくことはないはず。
ポチポチするだけで結果が出て来るのはよい。

ということでドキュメント読みながらポチポチ進めるだけなので、途中経過は飛ばす。

以下はデータをフィルタせず、アルゴリズムにランダムフォレスト（Multiclass Decision Forest） を使ってみた結果。

そこそこの正答率が出ている。
誤答している箇所をピックアップしてみる。

• 2030/1/13 祝日ではないが祝日扱い
• 2004/10/11 祝日だが祝日でない扱い

成人の日や体育の日は第2月曜となっているため、傾向が見えにくいのだろう。

国民の祝日 - Wikipedia

そもそもインプットしているデータに「曜日」や「第2週」という概念がない。
このへんを与えれば改善するだろうか。

ということでデータセット自体を作り変えてみたのがこちら。

https://raw.githubusercontent.com/kheiakiyama/HolidayEstimation/master/holiday-with-dayofweek.csv

曜日と第何週かをデータに追記した。

ロジックは特に変えずに出した結果。

かなり改善している。
今回はデータセット自体を自分で用意したのでデータセットを置き換えたが、本来は Data Transformation で加工する。
データの型の特徴を正しく認識されるように加工してあげる必要があることがわかった。

あとは春分・秋分の日あたりに間違いが見られるが、アルゴリズムの取捨選択でどうにかならない気がする。

本来、自分で実装できることを機械学習に頼るべきではなく、規則性の見えないこと・表現できないことをやってくれるもの、という位置づけで考えておくのがいいのだろう。
今回は機械学習を理解するために人間が理解できるものを例にして取り上げた。

デプロイ

こうして作成したモデルは簡単に WebService にデプロイできる。

WebAPI で公開されるので後は既存のサービスから呼び出すだけ。
Bot 連携程度なら AzureFunctions 使っておけばいい。

API のドキュメントも生成されている。
Swagger フォーマットはもうスタンダードになりつつあるるのだろうか。

認証は下の画面にある Key を Header に含めるだけ。

デプロイされたAPIはトランザクション数とコンピューティング時間の従量課金となっている。

料金 - Machine Learning | Microsoft Azure

今回は AzureFunction で毎朝 API コールして結果を Slack に流すようにしてみた。 本題ではないので詳細は省く。

3/5(日) は祝日ではないけど休日ですね。。
英語力が足りてない。

まとめ

研究者みたいに学問として学ぶのが苦にならない人は数学を着実に学び直すのはいいと思う。
しかし専門職でもない自分が、機械学習に大量の学習コストを割くという判断はしづらい。
Azure Machine Learning のように短時間でお手軽に触れるテクノロジーをうまく活用してやっていきたい。

機械学習そのものについては、これをとっかかりにしてもう少し複雑なことをやらせてみたい。
やりたいことはあるが、試行錯誤そのものよりもデータ集めるのが大変なのでどうするか迷う。

さわってわかる機械学習 Azure Macine Learning 実践ガイド

Azure+Cognitive Servicesで英語の発音を練習するWebサービスを作った

はじめに

今年から Azure により深く関わることになった。
手始めに Cognitive Services の SpeechAPI でちょっとしたWebサービスをつくった。

kheiakiyama.github.io

PCで動作確認済み。
iPhone のMobileSafariではHTML5の音声入力が動かないので動作しない。

www.microsoft.com

システム構成

趣味のサービスなのでコストがかからないように、いわゆるサーバーレスな構成。

• フロントは GitHub Pages で静的サイトホスティング
• バックエンドは Azure Function
• 英語の文章はスクレイピングして結果を TableStorage に保存
  同時に QueueStorage にも登録
• Azure Function で Queue をトリガーに Cognitive Services の Text to Speech で音声化し、BlobStorage に保存

Azure について

Cognitive Services

サイトで試しに聴いてみればわかるとおり、Text to Speech で出力した音声は自然に聴き取れる。

一方、Speech Recognition は全然自分の英語を認識してくれないので評価しづらい。
英語が堪能な人に試してもらうと認識されるので、練習あるのみ。

Speech API が $4 per 1000 calls なので、API を軸にしたサービスでペイするのはなかなか厳しそう。
あくまでも既存のサービスの満足度を高めるために利用するのがベターそう。

Azure Function

全体的にすごくよい。
Function ごとにディレクトリ切って実装するだけなので簡単。

大半が WebApps と同じ感覚で使えるので学習コストが低くて済む。
単純に REST API を簡単に作れるだけではなく、Storage をはじめとした Azure のサービスとの連携が気持ちよくできる。
たとえば Queue と Table を入力に Blob へ出力するための設定は以下のような感じ。

{
  "bindings": [
    {
      "name" : "queueItem",
      "queueName" : "speech",
      "connection" : "{queue_accesskey}",
      "type" : "queueTrigger",
      "direction" : "in"
    },
    {
      "name": "entity",
      "type": "table",
      "direction": "in",
      "tableName": "sentences",
      "partitionKey": "speech-eng",
      "rowKey": "{queueTrigger}",
      "connection": "{table_accesskey}"
    },
    {
      "name": "outBlob",
      "type": "blob",
      "direction": "out",
      "path": "speechs/{queueTrigger}.wav",
      "connection": "{blob_accesskey}"
    }
  ],
  "disabled": false
}

name に指定した名前が実装する function のパラメータ名になる。

public static async Task Run(
    string queueItem, //in queue の binding
    TableEntity entity, //in table の binding
    Stream outBlob, //out blob の binding
    TraceWriter log)
{
    //do something...
}

公式ドキュメントでは functions-triggers-bindings のあたりを読むといろんなパターンが載っている。

おそらく厳しいが、DataFactory のように今後他のパブリッククラウドとも連携されたらいいなと夢が広がる。

悪い部分をあげるとささいなレベル。
ポータル上のエディタが不便(ローカルで書けばいい)とか、下に書いたハマりポイントがあった程度。

AzureFunctions で開発するときにハマったこと - Qiita

あとがき

サービス自体について思ってること

• もうちょっと練習に適した文章使いたい。けど本などの教材からパクるわけにもいかないので悩む。
  サイトに載せていいようなまとまった資料あったらぜひ教えてください
• 日本語訳くらいは表示しておきたい。
• 正答の精度もうちょっとゆるくしたい。もしくは精度自体表示する。
• 正答率表示は回答者いないとワークしないから後で実装すべきだった。
• というかスクレイピングによって出題が増え続けるのはよくない気がする

と書いてみたものの、こうしてブログ書くとあまりいじらなくなるのでやる保証はない。

英会話・ぜったい・音読 【続・入門編】 (CDブック)

Cookpad TechConf 2017 に参加してきた

Cookpad TechConf 2017 に行ってきた。
面白いセッションばかりだった中でも印象に残ったことを中心に書きなぐっておく。
資料は ここ にまとまっている。
動画は現時点(21日22時)ではないが公開されるはず。

感想

Cookpad under a microscope

クックパッドのレシピ投稿というビジネスモデルがフィードバックループによって成り立っているという話が面白かった。
リーンスタートアップみたいな話でサービス改善のサイクルを回すんだ！みたいな話はもうお腹いっぱいだったが、ビジネス自体もそうなっているという視点は上手く回っていることを納得させられた感ある。
ビジネスにしろ組織体制にしろ、継続的な循環が生まれていないといけないのかという気持ちになった。

Building infrastructure for our global service

ローカライズのお手本みたいな話だった。
言語だけじゃなくて文化や習慣まで考えないとダメですよ、と。
ここまでグローバルに展開していくと、たとえば日本の食品関係の企業から何かを世界に展開したいときのいいパートナーになれるかもしれなくて、よりビジネスが強固に展開されるかもしれないと妄想した。

インフラは日本版とグローバル版が分かれているとのことだった。

日本版とグローバル版で分けておいて、いつかは統合したりするんだろうか。日本はコラボレーションとかのビジネス展開もいろいろあるだろうし、先行版みたいな感じでいくのかなあ。 #CookpadTechConf

— kheiakiyama (@kheiakiyama) January 21, 2017

快適なサービス開発を支える技術

これまで公開されてきた環境整備プラスアルファ。
技術で問題を解決するを地でやってる。
セットアップやデプロイ周りなど参考にしたいことがたくさんあった。

最後に

配られてたシイタケ美味しかった。まじシイタケ。

味覚糖 茸のまんま しいたけ 香ばし醤油味 15G×6袋

見守りカメラのシステムをRapberryPiで作成・運用しての感想

この記事は Raspberry Pi Advent Calendar 2016 20日目の記事です

1年前に RaspberryPi2 で室内の温度を取ってましたが、年内で単身引っ越すことになったため、家族を見守るカメラとして生まれ変わることにしました。

システム構成

• Raspberry Pi 2
• motion(動体検知目的)
• Slack
• LINE
• GrowthForecast(グラフ作成、デバッグ目的)

おおまかな流れ

1. Webカメラを接続したRaspberryPiを、毎日人がいるところが写るように設置
2. motion で動体検知する
3. motion が検知して撮影した写真ファイルをチェックして最終更新日時を保存
4. 7,19時に「最終更新日時」をチェックして、直近1時間以内に反応があるかどうかを Slack or LINE に流す

つまり、「普段そこにいるはずの家族がいないのはおかしいんじゃない？」と投げるだけのシステムです
万が一倒れてしまったりすると動体検知しないため「いない」と判別されます

使ったWebカメラはこちら

LOGICOOL ウェブカム HD画質 120万画素 C270

参考

はじめてのRaspberry PIで監視カメラを作ってみた。 - Qiita

感想

セキュリティとプライバシー

• カメラによる画像はプライバシーの塊なので、ssh などで入らない限りはファイルが見えないし、定期的にファイルは削除している
• (まだやってないけど)画像を要求するときは Slack や LINE からBotに反応させるようにするとセキュリティ問題をプラットフォームに丸投げできてよさそう

テストの問題

• motion の動体検知のしきい値(threshold)をどの程度にすべきかがカメラの位置、被写体に依存するのがつらい
• 基本的に外出してなければ「いる」のが普通なのでリアルな環境だとテストしづらい
• GrowthForecast に「いる」or「いない」を吐き出して後で追えるようにしたところ捗った
• 多少は「いない」と誤報が出るくらいでもよさそう
  

  見守りシステム、機械的にやっても生活リズムの変化に対処仕切れないので、関係者のLINEグループに投稿して、あとは人同士のコミュニケーションに促すほうがシステム上もコミュニケーション上もいいんじゃないかと思った

  — 東京都民 (@kheiakiyama) 2016年11月20日

微妙なバグ

見守りシステムで微妙なバグが見つかった。

— 東京都民 (@kheiakiyama) 2016年12月6日

5分ごとに生活反応あればその時間をファイルに記録するジョブと、12時間ごとにファイルをチェックして直近1時間以内に反応なければSlackに投げるジョブ。おそらく前者と後者がほぼ同時に実行され、ファイルを削除、記録の間に後者のジョブが走って、ファイルがない瞬間の挙動をした。

— 東京都民 (@kheiakiyama) 2016年12月6日

バッチ職人への道は険しい

あとがき

年末年始の休みでちょっとしたことをするには RaspberryPi は手頃でよいです

Raspberry Pi3 Model B ボード＆ケースセット (Element14版, Clear)-Physical Computing Lab

2016年に買ってよかったもの

お題その2「今年、買ってよかった物」

毎年恒例の買ってよかったものを書く。

本

酒井若菜と8人の男たち

ナインティナイン岡村との友情の話とか、そんな事情があったのかと驚かされた。
モー子かわいいなあと、ブログフォローしてたけど、文才すごいと思う。

酒井若菜オフィシャルブログ「ネオン堂」Powered by Ameba

ガジェット

iPad mini 4 Wi-Fiモデル MK6L2J/A (16GB・ゴールド)

本を読んだり動画視聴のタブレットは iPad が一番よい。
Kindle Fire 系も試したけど、電池の持ちとか起動し続けていたときの安定感とか、全然違う。

MISFIT 活動量計 RAY カーボンブラック/ブラックスポーツバンド 【日本正規代理店品】

半年以上使い続けているが、電池交換しただけで問題なく使えている。
週一くらいで運動量見直してたまにウォーキングしたくなる。
話のネタにもなるし、よい。

NEC Aterm WG1200HS 11ac/n/a(5GHz帯)&11n/g/b(2.4GHz帯) 無線LAN親機(Wi-Fiルーター) 同時利用タイプ 867+300Mbps PA-WG1200HS

値段で購入を決めたBuffaloの無線LAN使っていたが、半年過ぎたあたりからしばしば再起動しないとダメになり、乗り換えた。
無線LANルータはNECがいいらしいが、今まで一度も落ちてたことなく、たしかに評判どおりかもしれない。

Fire TV Stick

ガジェット操作がおぼつかない家族のために購入。
ChromeCast と比べて、リモコンがあることでTVに近い体験が得られてよいのだと実感した。

インテリア・小物

きの小いす ブラウン

きの小いす ワインレッド

直接座ったり、高めの椅子での足置きにしてる。
フローリングにマット引くのがキライなので、足が冷える時期にちょうどいい。
マリオ感。

MIU COLOR? 550MLガラス水筒　ボトル　ナイロンのカバー付き　スタイリッシュ　ポータブル　アウトドアとインドア用(ダークブルー)

パット見おしゃれという点だけがいい。
冷たい飲み物は夏にぐんぐんぬるくなる。

ゲーム

Fallout 4 - PS4

PS4で最初に買った。
FPSは好きなので、のめり込んでプレイした。
2ヶ月近くの余暇が吸収されたので本当に害悪でしかない(褒め言葉)。

グランド・セフト・オートV 【CEROレーティング「Z」】 (「特典」タイガーシャークマネーカード(「GTAオンライン」マネー$20万)DLCのプロダクトコード 同梱) [PlayStation4] - PS4

オフラインのみをプレイ。
GTA3の頃から比べて着実な進化を見た。
Fallout4 の直後にプレイするのは系統がかなり近いためオススメできない。

STEINS;GATE 0

アニメ観てやりたかったゲーム。
FullHD版の STEINS;GATE も未プレイだったので、同梱されていたのは嬉しい。
(DL 有効期限は 12/9 までとのこと)

ペルソナ5 - PS4

FF15延期もあり、衝動的に買った。
テンポ、システム、BGM などどれも最高レベルのRPG。
攻略サイト見ないほうが絶対に楽しめる。

PlayStation 4 Pro ジェット・ブラック 1TB (CUH-7000BB01)

早い。気がする。

毎年書くことでこれにより年末を感じる。

特別お題「2016年を買い物で振り返ろう」 sponsored by 三菱東京ＵＦＪ-VISAデビット

社内イベントで ISUCON を模した何かを開催した話

ISUCON 界隈を見てて羨ましかったので、社内イベントとしてそれらしいものを開催した。
なお、Web系ではなくWindowsのパッケージ開発をやってることや、参加者の技量を考慮して内容を考えた。

出題内容

• この内容を当日説明し、 10:15〜16:00 の間、課題に取り組む
• IDatabase の実装をC#で書き、アセンブリを提出する
  実際のコードとは若干異なるけど大体下のような感じ

class EventItem
{
    int X { get; set; }
    int Y { get; set; }
    DateTime Created { get; set; }
}

interface IDatabase
{
    void Initialize(IEnumuable<EventItem> items);
    EventItem[] OrderByX();
    EventItem[] OrderByY();
    〜中略〜
    EventItem[] HigherThanX(int x);
    EventItem[] LowerThanX(int x);
    〜中略〜
    string Name { get; set; }
}

• ベンチマーカーが用意されており、規定時間以内に何回 IDatabase のメンバをコールできたかでスコアが計測される
  Initialize, OrderByX, OrderByY, (中略), HigherThanX, LowerThanX, (中略) までがワンセットで後は繰り返し実行される
• 本番計測は運営側で行う
  仮計測は手元で行い、その暫定スコアは GrowthForecast に送られる
  他の参加者のスコアも自由に見れる
• 運営が15人くらいの参加者からおおむね2人組のチームを構成した

感想・反省点

• Initialize は規定時間に含めていなかったため、処理をここに寄せることでハイスコア獲得が可能になっていた
  禁止事項を曖昧にしてしまったため、どこまでの処理を寄せていいのかが参加者間で認識統一されておらず、不完全燃焼になってしまったチームが見受けられた
  この点が一番の反省点で、最低限禁止事項を明示すべきで、参加者に委ねるのは得策ではないと感じた
  スコア計測とは別で、10秒以内に処理を完了すること、などの制約をつけておくのがよさそうだった
• 普段組むことがないメンバーがペア作業をしているのは、見ていて新鮮だった
  飲み会とかせずとも、こういうイベントを通じてコミュニケーション取るのはよさそうに見えた
• 終了直後に上位者に解説してもらうことで、温度が温まった状態でハイコンテキストな話がされていて(少なくとも自分は)面白かった
  ただし「こうすると伸びた」が中心で、「なぜそれが早いのかを計算量から考えると・・・」といった話まで掘り下げられなかったのが惜しかった
• 暫定スコアを公開したのは評判よかったが、終了30分前くらいまで GrowthForecast のサーバーを落とさなかったため、結果がほぼ見えてしまった
• ベンチマーカーにバグが何度か見つかり、その場で修正することになった

運営について

• 出題内容の検討、エントリのためのサイト作成、ベンチマーカーの実装、スコアサーバーの準備、当日の進行は自分で行った
• 出題内容の相談やチーム分けなどは唯一の運営スタッフ1人に協力してもらった
• 優勝の副賞を出すための予算はエライ人に協力してもらった
• 集客はニガテなので近辺の人にお願いして宣伝してもらった
• 参加者の規模感から、運営は自分を含め2人までと決めていた
  運営に協力してほしい人≒上位に入りそうな人 なので、極力参加者に回ってもらえるように配慮した

あとがき

データベースのインデックスってどういうロジックで早くなってるんだろうか？という疑問から、調べてみたら面白かったので、それをそのままテーマにした。
今考えるとそれを理由にして、データベースがやるべき実装はすべてOK、結果のキャッシュは外側のミドルウェアがやるべきだからNG、としておけば反省点に挙げた問題は多少解消できていたかもしれない。

この手のイベント運営はわりと大変に思われるが、やっていくうちに洗練される。
出題内容の検討のみ大変で、実施だけは決まっていた3ヶ月以上前からアイデアだけ何個か書いてたけど、実務との関連が薄く、ただ楽しいだけのものになってしまいそうなので、大体ボツにした。
(それでもいい気はするが、体裁上・・・)

あと終わった後に話しそびれたこと。
今回はロジックやパフォーマンスをテーマに挙げたものの、別にそれが得意じゃなくてもいいよって話をしたかった。
パフォーマンス厨みたいな人がいれば、システム全体のアーキテクトが得意な人がいたり、たいがいの技術情報を知ってる勉強マンがいたり、コミュニケーションを円滑にするための触媒みたいな人がいたりしてチームは成り立っているよね、っていうエモい話をどっかでしようと思ったけど、エモすぎるのでここに書いておくくらいにする。

勉強会を開こう！〜IT業界に学ぶイベント運営ノウハウ・初級編〜