トップ > WEBエンジニアじゃないけどWEBエンジニア勉強会#14に紛れ込んでみた話

WEBエンジニアじゃないけどWEBエンジニア勉強会#14に紛れ込んでみた話

 

はじめに

まさか半年どころか9ヶ月間も空けちゃうなんて！
と思ってメモを見返したら、勉強会自体2ヶ月ぶりとかでした。
気分は社会復帰です。たまに外に出るの大事。


ということで、社会復帰にも最適なやさしいせかい、WEBエンジニア勉強会 #14 に一般参加で潜入してきました。

web-engineer-meetup.connpass.com

 

本当にWEBエンジニアだった頃に何度かお邪魔していますが、改めてご紹介すると、WEBサービス・SI問わずWEBエンジニアが集うコミュニティです。
個人開催にも関わらず2〜3ヶ月に一度のペースというハイペースで開催されております。参加者・登壇者とも若手〜中堅多め。

今回の会場はカサレアルさん。待合室がどことなくホテル風で和む。

 

さて、タイムテーブルをご覧いただければわかるように、この勉強会、前座枠というものがあり、スタート前にも誰かしらなんかしゃべっている状態なのですが。 

 

speakerdeck.com

 

こうなった。

よく考えたら人工肉なので「お肉の試食会」ですらなかった。食べなかったけどおいしいようです。畑の肉しゅごい。

 

前置き（？）が長くなりましたが、各登壇のレポートに移ります。

何故マイクロサービスにするんだっけ？ 

speakerdeck.com

スポンサーセッションだからと侮るなかれ。スピーカーの多田さんはJava、特にSpring界隈ではちょっとした有名人なのです。勉強にならないわけがない。

内容はスライドの通りです。マイクロサービスのメリデメちゃんと考えようねって話と理解。
初心者からベテランまで、万人に効くテーマではないでしょうか。

マイクロサービスに限らず、「流行ってるし、イケてる感じだから」で手法を選ぶと高確率で痛い目を見る気がします。屍の山を築いたマイクロサービスとアジャイルはもちろん、クラウドの新機能をノリで使った時とかも後悔しがちなイメージ。
言語はサーバレスだとサポート確認必須だけど、あとは意外となんとかなる気がする。このへんの、「流行りに乗った結果、クリティカルになる／ならないライン」は個人的に若干興味があります。

話が飛びました。マイクロサービスやるならハチの本読んどくといいよって社内のわりと強いエンジニアが言ってました。諸事情により英語版で読みましたが、確かに一回目を通すとよさげ。

 

失敗から知るAWSサーバレス ~ API Gateway Lambda編 ~

www.slideshare.net

 

サーバレスあるあるな落とし穴を超絶具体的に、かつわかりやすくシェアしていただいたセッション。回避策もしっかり書かれていて嬉しいスライドです。みんな苦労してるんだなあ。

受託の現場離れすぎてわからないのですが、お客さんがサーバレス指定してくる理由が気になるところ。他のシステムと平仄合わせるためとか？それとも雑誌とか読んで言ってくるのかなあ。

 

愛されるダッシュボードの作り方

speakerdeck.com

 

最初に至極どうでもいい感想言います。

スライド表紙の愛され感がすごい。

しかも登壇前にバッチリconnpassでシェアしてあるという如才なさ。これは愛されますわ。

 

JupyterHubをデモ配布に使うというアイデア、作り手目線だとめちゃくちゃアジリティ高くて素敵な反面、社内ユーザーにも相応のITリテラシーが求められそうなところ。
そのあたり、どう解決していったのか、あるいは解決しなくていいくらいITリテラシー高いユーザー層だったのかなど、気になるところ。

いずれにしても重要なのは「イテレーションを早く回す」ことなので、仕組み自体は組織に合わせて色々なパターンが考えられそうです。奥が深い。

 

アジャイル好きのウォーターフォールとの付き合い方

speakerdeck.com

 

「ウォーターフォールを批判したいわけではないが、ウォーターフォールに向いているエンジニアもいれば、アジャイルに向いているエンジニアもいる。」

という言葉に重みを感じます。

工程をまぜまぜするやり方としてはTDDが真っ先に思い浮かびましたが、そうか、リバース・エンジニアリングで仕様書作るってのも確かにそうですね。

しかも仕様書と実装の間に「ヒューマンエラーによる乖離がないことが保証されている」って現場からしても超絶助かる話でWin-Winでは。

えっ生成した仕様書が秘伝のエクセルフォーマットに合ってない？そんな殺生な。

 

mdx-deck v3 and code-surfer v3

code-surfer-v3.naturalclar.now.sh


うまく埋め込めているか若干自信がないのですが、これに関しては余計な説明はいらないでしょう。とにかくスライドを見てくれ。code-surferの動きが気持ちよすぎる。

お仕事とかで継続的に使うにはAlpha版で破壊的変更モリモリなのが不安要素ですが、一回きりの登壇用であれば問題なし。
オンラインのトレーニング資料とかに使っても映えそうです。遊んでみよう。

 

GAEによるPythonWEBアプリケーションの高速開発

speakerdeck.com

 

GCPネタ。「GAEはいいぞ！」ってなるかと思いきや微妙になりきらなかった話。

デプロイ遅いのは毎回バイトコード作ってて時間かかってそうな気もするけど、よくわかりません。Pythonの実行時のしくみ、コンパイルのタイミング以外Javaとそこまで変わらないようにも見えるんだけど、どうなんだろ。インタープリタ型とコンパイル型の境界線がわからない。

言語・フレームワーク変えまくりながら、ヘルスチェックだけのAPIデプロイするのにどのくらい時間かかるか、とかベンチマーク取ってみても楽しそう。

どのくらいリクエスト捌けるか、という観点でのベンチマークは見つかった ( https://medium.com/growthops/google-appengine-benchmark-f9961ae82e42 ) のですが、デプロイにどのくらい時間かかるかを計測したものは発見できませんでした。

 

How Can They Know That? A Study of Factors Affecting the Creepiness of Recommendations

トリは論文紹介です。
スライドが見つからなかったのですが、元ネタは多分これ。

https://interactivesystems.info/system/pdfs/907/original/RecSys-19.pdf?1566216344

「今日だってことに今日気づいて、昼休みに読んでスライド作りました」

という驚異のスピードと、そのスピード感で仕上げたとはにわかに信じがたいレベルの面白さを兼ね備えたヤバいセッションでした。

 

Creepinessという言葉はピンとこなかったのですが、検索エンジンが有能すぎる時に「えっなんで知ってんのキモ」ってなるあの感じをCreepinessって表現するようです。

Creepinessを感じやすい性格は「社会的信用が低い」「合理主義者」

Creepinessを感じやすい話題は「医療・健康」のようなセンシティブな話題

Creepinessを感じる原因は「なぜそれを薦められたのかがわからない」こと

……などなど。結果自体にそれほど驚きはなかったものの、きちんとデータで示されると興味深い内容です。

 

昔よりマシになったとはいえ英語読むのやっぱり得意じゃないので、日本語でこういうインプットもらえるのはすごいありがたいし、楽しい。

エンジニア向け、大人の論文輪講とかやってるとこないですか（真顔）

 

おわりに

終始個人的な感想ばっかでアレですが、本当に、参加してよかった。

開発の前線を離れて半年以上。参加動機は技術トレンド追えてない危機感が半分、気分転換が半分、という感じでした。

登壇の内容自体が勉強になるのはもちろんのこと、前線で頑張っている等身大の姿に、いい刺激をもらってリフレッシュできました。
えらい人がイケイケでWe're hiring!する勉強会もあれはあれで非常に勉強になるのですが、肩に力を入れて聞いているのも疲れるもの。
「開発って楽しいよね！」「もっと楽しく開発できたらいいよね！」というシンプルな想いを再確認する意味でも、こういうコミュニティの存在は素直にありがたいと思います。

しかし転職したばっかなのに、腰を据えて開発やりたい欲が募って困ります。
とりあえず美味しいお肉食べよう。

 

次回は10月〜11月開催、場所は渋谷のセンが濃厚なようです。

ご参加の方はお見逃しなく。