2019年最後のWEM
Web Engineer Meetup略してWEMの『WEBエンジニア勉強会』に行ってきたイベントレポです。
WEBエンジニア勉強会は主に渋谷近辺で活動、だいたい1～3年目ぐらいの若手の方も多い、Web技術を総合的に扱った勉強会となっております。公式Twitter、FBもあります。2017年から始まり、2019/11/15の今回が第15回。毎回connpassで募集しています。主催はOSCAさん。
- 2019年最後のWEM
- オープニング @engineer_osca
- axiosを型安全にするラッパーを作ったらVSCodeの補完で生産性が爆上げした話 @m_mitsuhide
- プレイングマネージャーになったときの話 @ykagano
- デザインを見ながらフロントエンドコーディングをするときの考え方 @kkoudev
- ネストした JSON を CSV に自動変換する Python ライブラリを作った @kawasin73
- 「運用と開発が同時並行で進んでいるRailsアプリケーションをDocker対応した事例について」 @grem_ito
- 世界中のフロントエンダーの残業時間を減らす、新しいフロントエンドフレームワーク @StewEucen
- WEBエンジニア歴2ヶ月で躓いたエラー10選 shinji ukai
- Pulumiで環境作成を自動化する @mov_vc
- 閉会・プチ懇親会の予定だったもの
- リンク集
- 次回WEM16は年明け!
web-engineer-meetup.connpass.com twitter.com Facebookにログイン | Facebook
今回のLT枠を除いた参加者は最終的に41人マイナスでキャンセルで30人ぐらいとなりました。抽選で落ちたらイヤーンと思い僕はブログ枠で参加しました。場所は今回も渋谷ファーストビルのミクシィさんのフロア。今回は前座なしで開始となりました。
オープニング @engineer_osca
- 最初は主催のOSCAさんの自己紹介から。(@engineer_osca)
今年ついにSIerから事業会社に移ったとのことで、主要言語がJava、PHPだったのがRubyに変わっています！ みんなエスアイヤ～を後にしてしまうのね……(泣きながらダッシュ) - 毎回恒例の参加者層のアンケートではサーバサイドが32人、フロントエンドが22人ほど。エンジニア歴は0〜1年が20人、参加者の約半分は0～3年の若手が多い構成です。一方歴10年～も12人でした。
- WEMを通じエンジニアが輝ける場、誰でも発表できる場を作りたいとのこと。このへんは多くのイベント主催の方に共通する思いですね。
OSCAの技術ブログ techblog.oscasierra.net
axiosを型安全にするラッパーを作ったらVSCodeの補完で生産性が爆上げした話 @m_mitsuhide
※上の資料はご本人のTLに載っていたもので当日のものと違うかもしれません。
- 最初はフリーランスエンジニアでLINEやDocomoの仕事でもご活躍中のまつださん。Vue.jsやNuxt.jsをよく使っているそうです。(@m_mitsuhide)
- 最初にモダンJavaScriptを取り巻く、
ブラウザ・エンジン＞開発環境＞開発支援＞FW・ライブラリ＞周辺ツールなど
の階層構造を表したパワーワード「JavaScriptカースト」が出てきて笑いを誘います。今は最下層(?）にいるところを第3層の開発支援レイヤー、TypeScript,VSCode, Webpack, Babelなどが位置するレイヤーに上がりたくてOSSを作ったとのこと。 - axios(エイクシオス)はjQueryでの非同期通信機能の代替としてモダンなJSフレームワークでよく使われるライブラリ。ここのHTTPリクエストをやりとりするところはTypeScriptを使っていてもどうしても型がAnyになってエラーの原因になる。ここを解決するOSSをなんと自分で作ったとのこと！
- そして出てきたのは……ギリシャ文字で読めませんでしたが名前は「アスピーダ」
- Visual Studio Codeを使ってその場でのライブコーディングの実演が始まります。細かいところはよく見えませんでしたが、コードヒントがあちこちでポップアップして確かに助かりそうですね。
- Nuxt.jsで使われている技術と同じでTypeScriptのジェネリクス機能を使ったインターフェスを書く形で、アスピーダの実体は型定義のコンパイラなのだそうです。と書いておいて僕もこの辺がよくわかっていませんｗ
- 実際の開発での利点として、フロントエンド側(クライアント側)とサーバ側で分けて開発をする際、サーバ側のAPIの完成を待たずしてフロントの方で開発を進めたり静的検査をしたり、APIの仕様変更にもフロント側で先行対応できたりするとのこと。この手の話でよく聞くのはサーバから固定値を返すMockのAPIを作ったりする方法ですが、それを一段進めた形かなと思いました。
- あとサーバ側の開発が大きな会社だとSIerで動きが遅いという話がでてきてウっとなりますｗ
この日も急な作業が発生したとのことでそのまま超特急で帰ってしまわれたのですが、TSカンファレンスでも発表したいとのことです。非常に高いテンションで突っ走る、勢いに満ちたLTでした。
プレイングマネージャーになったときの話 @ykagano
- 続いては加賀野さん。SIerを経て3社目、電子マネー、Web系決済担当。主にJavaを使うとのこと。 (@ykagano)
- お話はまだAndroidがOSとしても安定していなかった時代、ソーシャルアプリ全盛期に遡ります。2013年頃から始まってなかなか懐かしい。
- 自分がバックエンド、デザイナー兼企画の２人体制でアプリを作っていきます。OCRが必要でライブラリを選定したりして最終的にサービスイン、よい反応も得られて自信にも繋がったとのこと。
- そしてリリース後１年、アプリをフルリニューアルするところから本題に入りますこの時は社外に開発を委託、５社ぐらいに相見積もりを依頼。
- よくある話ですがそして見積にもかなりの差。その中で一番安かったところに委託したそうです。会場のTLでもこのフラグ発言に反応が……
- そしてうまくいかなかった開発の振り返りLTになるのですが、リスクに備えたスケジュールのバッファ、きちんと書いた設計書、デイリーでの状況キャッチアップとマネジメントサイドの正道なやるべきことはやっておられた印象です。仕様を発注側から決めすぎたのが主な原因だったとのこと。
- そして納期に間に合わなくなった委託先からは低品質な成果物が上がってきてしまったそうですが、
Thread.sleep(1000);
に会場でも笑いが起こっていました。AndroidアプリでもサーバサイドのJavaアプリでも出てくるこれは単に処理を１秒待つコードですが、開発中の仮画面ならともかく納品物にこれが入ってメイン処理が空なのは……うん、まあお察しな感じです。 - そしてリカバリは社内でやることになり、沈んだ気分で契約終了の打ち合わせに行くのですが、役員の話力がすごかったとのこと。確かに技術が主軸のエンジニアをしているとなかなか気づけないのですが、話の上手い営業とか偉い人ってこういうシーンではめちゃくちゃ頼りになるんですよね。
- 気づきとして価格の安さだけで選択してはいけない、スケジューリングは最悪のパターンも想定して考えた方がよい。
- その後の機能拡張の機会はまた別の会社に。こちらは窓口が最初営業でうまく回らなかったところ、技術が分かる開発者に変わったらうまくいったとのこと。品質担保の施策としても、割とよく見る施策できっちりやっています。
- 総合して企画部門の経験は契約、Win-Winを目指す気持ち、初期の概算見積はスピードで...と学び多し。
- 最後にプレイングマネージャー(案件もやりつつ部下の育成管理の管理職も兼任する人)の姿としての話があります。やるべきことを決める、現場感を大事に、チームメンバとの潤滑剤として精度の高いコミュニケーション、必要なことはどんどん吸収していく……などこのへんは頷ける話でした。
テンションで突っ走ったひとつ前の@m_mitsuhideさんとは対照的に、落ち着いた口調で聴きやすいLTでした。Engineering Manager界隈の人が聞いたら喜びそうなテーマの話ですね。
このWEMを含めテック系の勉強会は技術に特化した話が多いですが、なかなか珍しいテーマです。見積もりやスケジューリング、管理、外部の会社への委託などなど、このへんにはこのへんでの難しさがあり重要性があり、スマホアプリ開発でも自社サービスでもSI開発でも同じだなあと思いました。
僕の会社でもしも似たような状況になったら、相見積もりでやたら安い会社が出てきたら「そこは品質大丈夫なのか」とリスク対策のフィルターが働いて偉い人からチェックが入ったりしてくるかな～と思います。こういう局面になると技術特化のエンジニアが揃った尖った会社よりお堅めの会社の方が強そうな気はします。
デザインを見ながらフロントエンドコーディングをするときの考え方 @kkoudev
- 今度は現ミクシィで作業通話アプリmocriを担当しているKouさん。(@kkoudev) 担当はiOS/Android双方にフロントエンド/バックエンド/インフラ と幅広い！フルスタックや...
- mocriの実際の見た目を元に、元の画面デザインは固定だがレスポンシブデザインは可変の中、複数OSでどうやっていくのか？ という実戦的なお話。
- まずは画面内の各要素が配置された「領域」を見極め、そこが多くの場合そのままタグになる。
- pixelの絶対指定でなく比率で指定する「リキッドデザイン」がレスポンシブデザインにおいては多くの場合有効。
- しかしスマホなどで極端に幅が違う場合は対応しきれないので、min-widthやmax-widthで対応。
- しかしこれでも対応しきれない場合あり。しかもスマホは年々大きくなったりする。スマホ/タブレット/PCの３パターンで横の基本ピクセル数を「ブレイクポイント」として基準を定める。
- 資料で提示されたブレイクポイントの分け方はブラウザのChromeのエミュレーターでも採用されている値。
- そしてブレイクポイントは３パターンより多くしない方がよい。
- 最後はコーディングTips。要素の中央揃えのテクニックでflexboxのほかにtransformや疑似要素もGood。
- まとめとして、やはりある程度慣れが必要なので実践を!
GoogleのPageSpeed Insightsでスコア97%を達成したアプリの開発者ご本人だけのことはある、非常に実践的なお話でした。
PC前提のエンプラ開発にいるとあまり見た目にこだわる機会が少なく、最後のflexboxとか疑似要素とかこのへん理解が怪しかったので(笑)復習しようと思います。
スライドの中で紹介のあった他の資料はこちらですね。
ネストした JSON を CSV に自動変換する Python ライブラリを作った @kawasin73
- 「プログラマーあるある 独自のミニ言語つくりがち」のキャッチコピーから始まるかわしんさん。DMMでインターンを終え現T大4年、Goが得意、そして卒業後の進路も……とつよつよ学生エンジニアさんです。(@kawasin73)
- ディープラーニングやデータサイエンスの世界ではデータ形式でCSVもよく使われるとのことで、ネストありのJSONデータを変換するPythonライブラリ nested-csvを作ったのでその紹介のLT。
- 資料はすべて実際のデータ構造を例に進んでいきます。Step1の"キー": 値 のシンプルなJSONならPython標準のDictWriterで可能とのことで、このへんはPythonに詳しくなくてもなんとなく分かるでしょう。
- そしてStep2がネストしたJSON、次が配列のあるJSON、長さの異なる配列のあるJSON、長さの異なる配列が複数あるJSON、ネストした長さの異なる配列のあるJSON……とどんどん複雑になっていって頭が噴火します。会場にもTLにも笑いが増えていきます。
- これを解いたライブラリの鍵は、CSVの１行目をフォーマット指定のメタデータと定めて、用意した独自の文法でデータ構造を記述するようにしたというもの。
- そして書くのも面倒くさいので、少量のサンプルデータを読み込ませると先頭行のメタデータを自動的に作ってくれる関数も作ったそうです。うーん力作だ。
プログラミングの根幹、データ構造に立ち返ったライブラリの話でした。今回のLT枠の中で唯一Pythonネタだったので、やはりデータサイエンス界隈といえばPythonなんだなあと思いました。
GitHubリポジトリはこちら。
ご本人のブログにこのライブラリの記事もあります。
「運用と開発が同時並行で進んでいるRailsアプリケーションをDocker対応した事例について」 @grem_ito
- 今後はドリコム退職後フリーランスとして活動を始めたgremito(ぐれみと)さんからDockerネタ。キャーgremitoサーン！(@grem_ito)
- Podcast「ものラジ」もゲスト絶賛募集中とのこと！
- お題はRailsアプリを例にとってDocker上に載せる話のメリットデメリットあれこれ。
- 話はDocker入門や実際のデモを交えて進んでいきます。やるといろいろ便利だけど準備の必要のあるGem、設定やシェルスクリプトなどあちこちに落とし穴や沼もあるとのこと。
- そしてgremitoさんマシンのデスクトップからユニティちゃんがこっちを見ているのを発見しました。(そ こ じ ゃ な い)
当日のTLを見るとDockerを日常的に使っている人、使っていない人、何も困っていない人もいればハマって困った人もいて様々でした。僕も仕事はWindowsなんですがマシンスペック問題もあり、Docker化しないで開発環境を作っても現状特に困らなかったりで割とがっつり使う機会がないんですねー。今後AWS上でものを動かす機会が増えたら、このへんのコンテナ周りももう少し深掘りしていきたい所存です。
ゲスト募集中のPodcast『ものラジ』はこちら。 monorazi.hateblo.jp
こっちを見ているユニティちゃんが表紙なのは技術同人誌の『UNIBOOK 10』でした。 unity-bu.booth.pm
gremitoさんの『あてぶろぐ』ではフリーランスとしての起動の経緯なども読むことができます。 gremito.hateblo.jp
テック系Podcast『しがないラジオ』のsp.29に続いてはsp.68で再度、もんりぃ先生さんと２人で「ものラジ」パーソナリティーズとしてゲスト出演もしています。 shiganai.org
世界中のフロントエンダーの残業時間を減らす、新しいフロントエンドフレームワーク @StewEucen
- 当日話題だったのがこちら。なんとなんと自作のJavaScriptフレームワークのメインコミッターからの発表です。格好もだいぶインパクトのあった悉生 游漩さん。お名前の読みは「しちゅうゆうせん」でcall me ゆうせん(Eucen)とのこと。(@StewEucen) 台湾出身の方のようです。
- 完全に新しいアーキテクチャで作ったJavaScriptフレームワーク、仮称Ma_gician (マジシャン)。オープンソース化目指して開発中とのこと。
- デモはVSCode上で、すべてVue.jsインスタンスをMa_gician方式で実装するとコード量がこう減るよという調子で進みます。コード量が減る→バグが減る→作業時間が減る→残業時間が減るというストレートな理論です。
- Vue.jsやReact、jQueryなど他のFW/ライブラリの記法でもある程度書き方の誤りは許容するという話が出てきたり、いったい
<script src="assets/js/ma_gician">の中身はどんなになってるのかな？と興味を惹かれます。 - 時間が限られていたので主にはVue.jsだとこうなのがこうなる……という話がメインだったのですが、他にも外部依存なし、環境構築不要、トランスコンパイルの概念なし、徹底的にパフォーマンスに拘りながら開発進行中とのこと。
Better Vue.jsか、LT枠のかわしんさんのブログレポにあるようにYet Another Vue.jsなのか、あるいはそれ以上にもっともっと機能があるのか、気になるところです。11/6のGinza.jsやWe are JavaScripters!でも発表、その後もあちこちのイベントを回っておられるようなので、気になる方は東京のJS系勉強会イベントに行くとどこかで見られるかもしれません。
www.slideshare.net
Qiitaにもご本人の一連の記事があります。『【Ma_gician #01】 世界中のフロントエンダーの残業時間を減らす、新しい JavaScript フロントエンドフレームワーク』『【Ma_gician #02】 変化の術』『【Ma_gician #03】代替画像はデザイナーさんにお任せ』 qiita.com qiita.com qiita.com
WEBエンジニア歴2ヶ月で躓いたエラー10選 shinji ukai
- shinji ukaiさんのチャパタイさんの発表。(@J8Ilr1HGmm6Oe3n) 広告代理店にオーストラリア、そして今年の10月から自社開発のWebエンジニアで働き始めたとのこと。本当にエンジニア歴２ヶ月！ なんというフレッシュメン……
- その視点の活かした失敗談を10個ほど上げているのですが、まあこれがあるある過ぎて面白い。すわ新しいJSフレームワーク？！の尖った情報の後にこういうゆるく和やかな軽い話が出てきて、会場も笑いに包まれていました。当日のTLもわかりみの嵐です。
- 「不明点が出て先輩に何分後に聞くのが良いタイミングか分からなくてググる」「調べ続けていて当初の目的を忘れる」「エラー文が読めない」「チュートリアル側の間違いに気付けない」「Apacheの設定ファイルhttpd.confを変えた後再起動を忘れる」「sudoで入ってなんとなく解決」「chmod 777でなんとなく解決」とかね……もう全員通ってきた道ですねこれ。ワイもUNIXの洗礼を浴びた頃chmodとかよくやりましたわ。わははは。
失敗したら「自分は伸びしろあるな」と思うようにしているとのこと。このポジティブ精神が素晴らしい。非常に初々しい、初心者にもベテランにも共感を呼ぶLTでした。
Pulumiで環境作成を自動化する @mov_vc
- 最後はもふさんによるLT。(@mov_vc)
大阪大学→2018年からコロプラ→2019年はKaizen Platform でSREとして働いているとのこと。エンジニア２年目とのことでこちらもフレッシュ！
- お題はpulumi社が開発しているオープンソース製品、アプリケーションとインフラをデプロイできるクラウド向けプロビジョニングツール、pulumiについて。技術書典の本でも有名なTerraformの対抗馬の位置にあるツールだそうです。
- pulumi本体の開発速度がめちゃくちゃ早くてイシューが一週間でプロダクトに反映、中の人がとてもフレンドリー、などなど非常に活発で絶賛進化中。2019年はもう環境作成は自動化する時代、ぜひpulumiを!
- というpulumi愛に溢れた発表でした。ここまで推すのには会社でも使っていてプレゼンスを上げていきたいたいとか自身もOSSに参加しているとか今度技術同人誌を出すとか、何かモチベーションがあろうのだろうなあ～と思ったら、なんと最後はQiitaで公開中のpulumi Advent Calendarが寂しいから参加してほしいというオチがありましたｗ
- あと発表の最初の方で見えたマシンのデスクトップ、ワンピースの女の子のイラストが可愛かったです(そ こ じ ゃ な い)
Kaizen Platformの公式ブログに、『PulumiでECS環境を構築する』としてご本人の記事があります。 developer.kaizenplatform.com
Pulumi Advent Calendar 2019。このエントリを書いている現時点でも、まだ参加者は12/1のもふさんだけのようです。全国のpulumiユーザの皆さんジョインしましょう！ qiita.com
pulumiのGitHubリポジトリ。 github.com
閉会・プチ懇親会の予定だったもの
予定されていたのですが、時間が押してきたのでそのまま終了となりました。うーんこのWEBエンジニア勉強会は発表はためになるんですが、人と話をせずにそのまま終わってしまう感はあるので、これはあると良いですね。ばたばたしてOSCAさんともgremitoさんとも挨拶できずに終わってしまった……
★計画通り、午後休の人として名を馳せている@miriwoさん(@mirimiripc)とリアルで会うことができました！ よかったよかった。あちこちのイベントやTLやPodcastの感想ツイートでよく見かけてていつの間にかフォローもして頂いてたのです。
お互いのイベント用名刺交換をしたりしました。ワイの名刺のアイコンが可愛いという評価をいただきました(笑) kiitokさんのイベントでもよく見る@miriwoさんは転職を目指し活動中ということは、闇属性のSIerに囚われてしまっているようなのでその辺の話も今後聞きたいところです。
★もうお一方、あちこちのPodcast感想TLなどでもよくお会いするつのさん(@wasi_wasimaru)にも突撃する予定で発見できずにこれは次回か……と思いきや、帰りのエレベーターで運良く会うことができました(笑)
こちらもよかったよかった。渋谷駅まで一緒に帰っていろいろ話しました。ワイの数少ないSIerナカーマ...と見せかけてつい最近事業会社に移られたそうでそのへんの話もまた聞きたいところ。つのさんとは12月にもしがないラジオMeetup4で会えるので楽しみです。
リンク集
かわしんさんのレポ。 kawasin73.hatenablog.com
@miriwoさんのレポ。 qiita.com
西村さんのレポ。 yui-nishimura-log.hatenablog.com
次回WEM16は年明け!
という訳でWEBエンジニア勉強会#15の記録でした。主催のOSCAさんと受付のthe.arcさん(@arc_candy)、会場のミクシィさん、発表者＆参加者の皆さんありがとうございました。奇しくも今回OSSコミッターが３人同じ場所に集まったり、ベテランもいれば若手もいてマネジメントの話もあってとなかなか多彩な顔触れになり、定期的に社外から刺激を受けるのは大事だなと改めて思った次第です。
なおWEBエンジニア勉強会はOSCAさんとthe.arcさんだけだといろいろ大変なので、スタッフやサポートをしてくれる人を絶賛募集中とのことです。次回#16は2020年の年明け予定、参加予定の方はお手伝い枠に入ったりしてはいかがでしょうか。
僕も受付の手伝いぐらい普通にできるんですが、今までのイベント一般参加経験からするとブログ枠と両方は多分やらない方がいいんだよな……うーんどうしよ。
