モブプロ楽しい
最近仕事でモブプロをやっている。楽しい。
何が楽しいか
- 自分だけでは立ち止まるようなところでも誰かしらが解決してくれるので立ち止まらず進められる
- typo指摘してもらえる。助かる。
- typo指摘しただけで感謝される。嬉しい。
- コードレビューで悩むことがない（モブプロの時点で解決している）
- 全員が一発で仕様を理解できる（モブプロの時点で解決している）
- テストなど、手を抜かずにしっかりやる傾向がある（例：ここのテストはこれで十分だろうか？いや、このcontextも書かないと。みたいな）
- たくさんしゃべるので、のどの筋力低下防止になりそう（しらんけど）
気をつけないといけないこと
一方、気をつけないといけないこともある。
- 急いで進めようとしてピリピリすると、質問がしづらい空気とか、作業を止めて話したりしづらい空気ができたりしてよくない
- 個人のもくもく作業をみんなで眺める形になるともったいない（せっかく人が集まっているのだから、ただコードを書く以上に、一つでも多くの疑問が解消されるとよさそう）
- 各々がそれぞれ別の作業をする以上の生産性を求めるのはさすがに無理がある気がしている（多少効率が落ちても、長い目で見て情報共有やら教育も兼ねられたから良いよね、くらいの温度感でやりたい）
- 全員が悩まず実装できるようなお題でわざわざモブプロする必要はなさそう
今のところは、以上のような感想。あらゆる開発作業をモブプロにしたいとは思わないけど、要所要所でやっていけたらいいな
最近の情報収集のやりかた
RSS
SlackでRSSフィードを登録して、Slackから見に行って読んでる。登録したいときは /feed subscribe [url] で随時足している。
今の所登録しているURL一覧は以下の通り。
Title: Release notes from compiler URL: https://github.com/elm/compiler/releases.atom Title: Microsoft Edge Blog URL: https://blogs.windows.com/msedgedev/feed/ Title: webpack - Medium URL: https://medium.com/feed/webpack Title: Babel Blog URL: https://babeljs.io/blog/feed.xml Title: mizchi's blog URL: https://mizchi.hatenablog.com/rss title: blog.jxck.io URL: https://blog.jxck.io/feeds/atom.xml Title: Mozilla Hacks – the Web developer blog URL: https://hacks.mozilla.org/feed/ Title: WebKit URL: https://webkit.org/feed/ Title: Next.js Blog URL: https://nextjs.org/feed.xml Title: React URL: https://reactjs.org/feed.xml Title: Yarn URL: https://yarnpkg.com/feed.xml Title: The npm Blog URL: https://blog.npmjs.org/rss Title: Updates URL: https://developers.google.com/web/updates/rss.xml Title: TypeScript URL: https://devblogs.microsoft.com/typescript/feed/ Title: JSer.info URL: https://jser.info/rss/
記事が流れてきたらなるべく読んで、Slack上でコメントつけるようにしてる。
情報流してくれそうなアカウントをフォローしたり、ツイート数多くてあんまり自分が見てもしょうがないなというアカウントは外したりミュートしたりして、リストとかできれいに整理しなくてもそこそこTLが役立つようには気をつけてる。とはいえTwitterなので技術と関係ないものも見ているし、そんな頑張って見てもいない。
理想
ちょうどいい量の情報が、ちょうどいいタイミングで入ってくるといいなと思っているので、今後もちょうどいい感じを目指して整えていきたい。
2019年の振り返り
今年は結婚式をさせてもらったり、ラーメンをたくさん食べたり、初めてタピオカを飲んだりしました。今年も元気においしいものをたくさん食べれて良かったです。
CSSで■、●、▲を描く
CSSでいろいろ描けるようになっておきたいなという気持ちだけは以前からあったものの、これまでちゃんとキャッチアップできていませんでした。まずは簡単なものからということで、●と▲と■をCSSで描いて、その実装方法について書いておきたいと思います1。
■
これは、widthとheightと背景色を指定するだけですね。
●
●も簡単で、直径の半分をborder-radiusに指定すると円になります。
.circle { --diameter: 200px; width: var(--diameter); height: var(--diameter); border-radius: calc(var(--diameter / 2)); }
▲
▲はちょっと難しかったです。CSS triangleで検索してみると、以下のジェネレータが出てきました。
生成されたCSSは以下のようになっています。
width: 0;
height: 0;
border-style: solid;
border-width: 0 0 200px 200px;
border-color: transparent transparent #007bff transparent;
なるほど（わからん）。
よくわからないので、詳しく見ていきます。
border-width
まずは、MDNでborder-widthのページを見てみます。
border-widthに値を4つ指定すると、 border-width: 上 右 下 左の指定になるみたいです。しかしそれでもなぜ上の記述、border-width: 0 0 200px 200px で三角形になるのか理解できません。色の指定を border-color: #007bff;にすればただの正方形になるので、border-colorの指定が肝なのでしょう。
border-color
MDNには、border-colorに4つの値を指定したときの例が載っています。なるほど、色をつけてみるとわかりやすいです。borderは上下左右指定すると、それぞれが台形になるんですね。
それぞれ別の色を指定すれば、きれいに三角形ができるまでの過程がわかりやすいので、アニメーションさせてみました。
See the Pen Animation of making triangle by gaaamii (@gaaamii-the-sasster) on CodePen.
それぞれのborder-widthをboxの幅の半分に指定したところ、boxの中身が全部borderで埋め尽くされ、きれいに三角形で四等分されました。なお、border-box: 0にしておかないとbox内の領域をそのまま保とうとしてしまうので、boxに大きいborderが付くだけになってしまうので注意です。
表示したい三角形の部分以外をtransparentにしていた
こうやって見た上だと、先程のborder-colorの指定 transparent transparent #007bff transparent; が理解できます。下のborderだけ色を付けほかは透明にすることで、色をつけたところの三角形だけが表示される感じになっていたのです。
さらに、伸ばしたい辺のborder-widthをboxと同じ長さに、かつ向かい合う辺のborder-widthを0に、それ以外の辺はboxと半分の長さにすることで、いい感じにboxの幅と同じ長さの底辺の二等辺三角形が描けました。
まとめ
今回、CodePenで書きながら一通り確認しました。書いたものも一応公開してるので興味ある人は見てみてください。
See the Pen basic shapes (●▲■) drawn by css by gaaamii (@gaaamii-the-sasster) on CodePen.
三角形の描き方を理解するのに思ったより時間がかかりましたが、とりあえずは●▲■の描き方を覚えられたので、次はこれを組み合わせていろんな形の表現に挑戦していきたいと思います。調べたらElmのロゴをCSSで描いてる人がいた2ので、自分でもいずれチャレンジしてみたいです。
-
この記事ではIE11などの古いブラウザについてはあまり考慮していないので、仕事の使ったりする場合は caniuse.com で確認するなどしてからにしてください 🙏↩
2020/01〜2020/03 やること
次のクオーター（2020/01~03）の個人目標がざっくり決まったので、社外でやることだけ書いておく。
- 会社のTechブログを2週に1記事（以上）更新する
- 何かしらの勉強会で1回以上発表（LTも可）する
- Elm Japan 2020 にcfpを出す
3ヶ月で1回の勉強会発表というのは慣れてる人からしたら大したことないのだろうけど、自分はまだ1度も社外で発表らしいことをしたことがないので、そこをクリアしておきたいというのがある。
逆にTechブログはハードルが低いしネタもありそうなので2週に1記事にした。とはいえ今クオーターの実績は2記事なので、その3倍と考えるとやっぱり大変そうでもある。
Elm Japan 2020はElm作者のEvanさんとかも来るガチイベントなのでcfp通すのは厳しそうだけど、cfpを出すというのも良い経験になりそうなので頑張りたい（締め切りまで時間あまりないので年末年始頑張ろう）。
「平成Ruby会議 01」を見に行った
同僚の id:atomiyama さんがRustでgemを書く話をするそうで面白そうだったので行ってきました。
各セッションの感想など
RubyでJVMを実装してみる
なるほどわからない #heiseirubykaigiB
— gaaamii (@gaaamii) 2019年12月14日
Rubyのしくみ読まないと
— gaaamii (@gaaamii) 2019年12月14日
Javaでコンパイルして出てくるバイトコード読んで云々という話だったけど、ぼけーっとバイトコード眺めてる間に話が進んですぐについていけなくなってしまった。あとスライドのコードとかあまり見れなくて視力の衰えを感じた...。
rustで拡張モジュールを作成してgemにする
- 順を追って説明してくれてありがたかった。
- Rustで速くなるんだったら一部だけRustで書いてgemにするのはよさそう。どんなモジュールだとRustにするメリットが大きいんだろうと興味が湧いた。
- 以前はffiを通じて他言語の実装を使うみたいなのはなんかすごい特殊なイメージがあったけど、最近（というか去年の今頃）ElmでPortを通じてJSのライブラリ呼び出すみたいなことをしてからは、必要があってインタフェースがちゃんとしてるんだったらやっていいんじゃないのという気持ちになっていたのでなおさら興味深かった。
やわらか増税 〜はじめての増税対応〜
軽減税率対応...大変そう... #heiseirubykaigib
— gaaamii (@gaaamii) 2019年12月14日
gemを書いたりするのも国税庁の仕事にするべきではと思った#heiseirubykaigib
— gaaamii (@gaaamii) 2019年12月14日
真のREST
真のREST from Toru Kawamura
www.slideshare.net
自分は正直RESTといえば「URLでリソース表してHTTPのメソッドでCRUDするやつ、Railsがやってるやつ」みたいな雑認識があったので、その雑認識がとりあえずは潰されてよかった。特にREST APIはハイパーテキスト駆動ではないといけないというのが全然自分の頭の中になく、なんなら驚いてしまった。ちゃんと勉強しよう...。RESTful Web APIsという本が良いらしいので読んでおきたい。
全体の感想
どのセッションも自分が知らなかったことが多く、勉強になりました。どんなプラットフォーム向けに何を書こうにも、コンピュータそのものとか言語処理系のしくみとかWebの歴史とか、そういう基礎的なこと（だけど実務で学ぶ緊急性があまりないこと）をしっかり理解しておかないといけないな...と同世代のできる人たちを見ていて感じました。
高さいっぱいのアコーディオンメニュー
See the Pen Full height accordion by gaaamii (@gaaamii-the-sasster) on CodePen.
高さいっぱいのアコーディオンメニューを書いてみた。calc()は幸福度が高い。
こういうの必要なことはちょいちょいありそう。
「サバイバルファミリー」を観ました
突然電気もガスも水道も使えなくなって情報も全然入ってこないみたいな状況で家族みんなで東京脱出して云々というすごい大変そうな話だけど、暗い感じはなくてへらへら笑いながら観れて楽しかったです。
PWA Night vol.10 行ってきました
なんで参加したか
趣味でMarkdownエディタを書いていて、一応create-elm-appが吐き出すmanifest.jsonとregisterServiceWorker.jsをそのまま利用してPWA対応してあるのだけど、Service Workerとキャッシュ周りよくわかってないのでそこらへん知れたらいいな〜と思い参加しました。
メモ
- SPAのSEOは相変わらずちょっと大変
- プロダクションでがっつりPWAやっていってる人は、「アプリじゃストアの審査通らない！」「じゃあPWAだ！」というパターンが多いっぽい
- Service Worker 周りは特殊なことしないのであれば自分でいちから書かずにworkbox使っておけばよさそう
- https://oo.parts のデモ見せてもらったけどよく出来ていてネイティブアプリ感あった
- WebAssemblyがどういうところに使えるのか実例見せてもらって雰囲気がわかった（雰囲気だけ）
- JSとWebAssemblyが違うところとして、型情報があるから安定して動作するみたいな話が興味深かった（まだあんまりよくわかってないので学んでいきたい）
所感
個人的にPWAは、検索して、リンクをクリックして、使って、気に入ったらインストールして使うっていうプログレッシブな感じが気に入ってて、デスクトップアプリに関してはほとんどこれでいいのではという感じがしてます。普通のウェブアプリならそんなに難しい作業も必要ないので、いま使ってるウェブサービスの多くも、今後は当たり前にPWA対応されていくのだと思います。
雑にはてなブログテーマ用意して公開もせず使ってる
ちょっと前に、はてなブログのテーマを作った。いや、作ったというか手元にテンプレートをおいていじくったやつを貼っ付けてるといったほうがいいかもしれない。
はてなブログは以下に素晴らしいテーマがたくさんある。
あるんだけど、せっかくCSS読み書きできるのだから自分で書いてちまちま直すほうが、週末に庭の手入れしてるじいさんみたいな感じで楽しそうと思った。はてなブログの自作は以下のページを読むとわりと簡単にできる。
ありがたいことに、そのまま適用してもちゃんとした見た目になるボイラープレートがある。ありがたい。つまり、自作テーマを作るといっても自分でいちから書く必要はなく、ボイラープレートのリポジトリをcloneしてきて、npm i; npm start して、確認しながらCSSを書いて、ビルドされたCSSを貼るだけでいい。投稿したテーマは、良い具合の出来になるまではストアに公開せず、自分のブログにだけ適用しておけばいい。
リモートワークについて
最近仕事どうやってやるのがいいかなあと考える機会が多く、その中でリモートワークについても考えることがある。今の所は以下のように考えてる。
自分はフルリモートじゃないと絶対嫌だという気持ちはないのだけど、考えてみれば往復2時間くらい毎日使うのはもったいないよなあと思う。たとえば週3日のリモートワークが許されているとして、時給が2000円だとしたら、往復2時間×週3日×2000円×4週間×12ヶ月って考えて、576000円！？お得！ってなる。実際、自社にリモートワーク制度ができたときは少し感動した。
通勤時間が無いと平日こんなに時間ができるのか…！すごい！
— gaaamii (@gaaamii) 2018年10月10日
もちろんリモートワークはチーム的には工夫しないといけないこと（ビデオ会議どうしようとかちょっと相談したいときどうしようとか）が出てくるので最初は面倒だとも思うし、一緒に働く人とオフラインでワイワイする時間もあったほうがいいと思うんだけど、通勤時間は当たり前に受け入れすぎて忘れがちだけどなかなかの損だよなあ、何も週5日でやらなくても、という思いもある。リモートワークがどうしてもできないとかではなくちょっとした工夫で成り立つレベルであれば取り入れたほうがよさそうだと考えている。
Custom TypesのデータをJS界に受け渡しする(Elm)
Elmでアプリケーションの状態をlocalStorageに保存しとくようなものを作っていて、カスタムタイプはどうするのか知らなかったのでメモ。
雑にそのままportに渡そうとしたところ、以下のコンパイルエラーが出てきました。
The
setStorageport is trying to transmit aColorThemevalue:259| port setStorage : ModelExposedToStorage -> Cmd msg
I cannot handle that. The types that CAN flow in and out of Elm include:
Ints, Floats, Bools, Strings, Maybes, Lists, Arrays, tuples, records, and JSON values.
Since JSON values can flow through, you can use JSON encoders and decoders to allow other types through as well. More advanced users often just do everything with encoders and decoders for more control and better errors.
上の ColorThemeというのが、localStorageに保存したかったけどできなかったカスタムタイプのデータですね。具体的にはこういうものです。
type ColorTheme = WhiteTheme | DarkTheme
で、エラーに出ている通り、
Since JSON values can flow through, you can use JSON encoders and decoders to allow other types through as well. More advanced users often just do everything with encoders and decoders for more control and better errors.
JSON encodersとdecodersとやらを使えばいいようです。
対応
どういうこと？
localStorageに保存するときにJSONの形にencodeして、localStorageから取り出してきたときにはElmのデータにdecodeしてます。問題になったColorThemeのところは、こんな感じでcaseで文字列にしたやつをencodeしているだけです。
素朴に趣味開発をやっていく
趣味開発は楽しい。楽しいけど時間とモチベ保つのが大変。そのため、以下のようなポリシーで素朴に趣味開発をやっていきたい、というメモ。
- 自分で使うものは自分でつくる
- すぐに完成させるつもりで始めない
- 何度でも書き直す
自分で使うものは自分でつくる
自分で使うものは自分でつくるという感じでやっていきたい。ブログ下書きに使うMarkdownエディタとか、TODOリストとか、RSSリーダーとか。それで稼ごうとか流行らせようとかは一切考えない。
幸いMarkdownエディタもTODOリストもRSSリーダーも、既存のもので自分にとって完全にしっくりくるものがないので、趣味開発のネタに困ることはなさそう。
すぐに完成させるつもりで始めない
自分で使うものといっても比較対象は一流の他のアプリになってしまうので、最初からそこを目指してしまってつらくてモチベーション保てないということになってしまう。本当に自分がそれが最高といえる状態が完成だとして、そこにたどりつくのにどれくらいかかるかはわからない。だから、完成させるつもりで一気に頑張ろうとせず、完成するまではその不便さと付き合う覚悟を決めてそれに接する。不便だと直したくなるので、モチベーションは保たれる。
何度でも書き直す
せっかく仕事と違って自由なので、リニューアルしたいときにできる。技術的にこれ使いたいからという理由で書き直してしまってもいい。
で、なにやってるのか
最近は https://nekobito.github.io をちまちまつくってる。
JSON色付けたいへん問題
この前、以下のツイートを目にして、面白いな〜と思いました。たしかにフロントエンドの仕事は、サーバーからJSONとして返ってきたデータを人向けに表示するという仕事が多く、雑に言い表せてる感じが面白い。
湯婆婆「フン。フロントエンドエンジニアというのかい？」
— ぷーじ (@YuG1224) 2019年9月15日
フロントエンドエンジニア「はい」
湯婆婆「贅沢な名だねぇ。今からおまえの名前は "JSON色付け係" だ。いいかい、 "JSON色付け係" だよ。分かったら返事をするんだ "JSON色付け係" ！！」
上のはジョークだと思うんですが、とはいえ真面目に考えてみると、JSONを人に見やすくする作業をひたすらやっているのだから、もう少し仕事楽になってもいいんじゃないか？なんでJSON色付け係は相変わらず大変なんだ？という疑問が湧いてきます。それについて、自分なりに考えを整理しておきたいと思いました。
JSON色付け係は何をしているのか
自分の最近の仕事を振り返ると、JSON色付けの仕事は前準備と実装の2段階に分けることができます。
前準備
機能を作る以前に、1行のコードも存在しない段階。
言語やライブラリの選定
もちろんやることによって何を選ぶべきか違うと思うのですが、やることが一般的なJSON色付けなら選ぶべきものは以下の4つになると思います。
言語
ブラウザならJavaScriptで書けばいいんだろうという感じですが、ES5で書くのがしんどいけど、ES5で配らないとちゃんと動かない環境があり、そういう環境でも使ってもらいたいので、なにかしらの工夫をしてES5のJavaScriptに吐き出すような仕組みを使ってます。ここでやるのは言語選びみたいなものです。ES6で書くか、TypeScriptで書くか、はたまたほかのAltJSで書くか。
画面表示
画面に表示するものを、こういう感じで書きたいです。
<h1>{{ blogPost.title }}</h1>
こういったテンプレート機能みたいなもので、このデータはここに表示されるというのを書けるようになります。
また、パフォーマンスでいうと、画面の差分更新（仮想DOM）も多くのライブラリがサポートしている機能です。
状態管理
ユーザーが画面操作すると状態が変わって、画面も変わる。というのがだいたいのアプリケーションに必要な挙動です。 これをするには、状態をどっかで持っておく必要があります。Reduxとかだと一箇所に状態を集めて、react-reduxで必要なコンテナとつないで状態入れるみたいなやりかたをします。
ルーター
ページ遷移をDOMの書き換えで表現するやり方（SPA）が流行りです。なんで流行ってるかというと、そうするとサーバーとやり取りするデータ量やページの再描画する部分が減って動作が速くなったりするからですが、そういったことを実現するにはブラウザ側に、このURLだったらこのページを表示するみたいなルーターが必要です。
ビルド設定
あと、上の言語選びでも書きましたが、最近のフロントエンドはソースコード書いてサーバーにアップロードして終わりではなく、モジュールを結合して圧縮されたES5に吐き出したりする必要があります。そこで、webpackなり何なりをつかってどうやって吐き出すか、という設定を書いたりします。
実装
一通り整ったら、機能追加の際にコードを書き足すだけになっているはずです。画面を書いて、振る舞いを実装して、色を付けたりします。ここで、なるべくデザインの意図や使われ方を理解して再利用しやすい形にしておけば、以降の実装の手間が減ります。
そこで、コンポーネント指向だったりAtomic Designだったりなんやかんやの方法論で、モジュールや画面パーツの再利用性を実現します。
なにが大変なのか
だいたい上に書いたようなことをやっているわけですが、それを踏まえて改めてなにが大変なのかと考えると、やっぱり前準備がけっこうたいへんです。○○アプリを3ヶ月でつくりたい！といったときに、前準備に1ヶ月かけてしまっては相当つらいですが、何も考えてないゼロの状態から始めると1ヶ月くらいかかってしまいます。
また、ディレクトリ構造やモジュール分けをそのJSON色付け係のセンスで行ってしまうと、実装の属人性が高い状態になってしまいます。
どうするべきか
ライブラリをあれこれ選ぶことはできればプロダクト開発以前に終わらせていて、開発が始まるときには、Railsみたいにコマンドばしばし叩くと雛形が出来上がるような仕組みまでできているとよさそうです。
たとえばangular-cli だと、だいたいアプリケーションに必要なものがng generateコマンドで作れそうです。
ただ、じゃあみんなAngular CLI使えばいいかというとたぶんそんなことはないので、どのライブラリやフレームワークが適しているかなども含めて考えてこれくらいのセットアップやらその後の保守をできるJSON色付けの専門家が、コマンド叩けば適切な場所へのモジュール追加やビルドができる環境を提供する、という形がいいのじゃないかなと考えています。
で、実装者の方はドメイン知識を活かした名前付けだったり、ユーザーの気持ちよさを実現するための技巧を凝らしたCSSアニメーションだったりに集中することができると、整った開発環境の上で、安心してイケてるウェブアプリケーションを作っていけるのではないでしょうか。
それなりに大変
と、ここまで書くと、フロントエンド環境の提供みたいな部分は、JSON色付けとは全く別物ですね...。どちらかというと、実装者のほうがJSON色付け係と言えそうです。
実装するのがJSON色付け係であれば、フロントエンド環境を整える人にもなにか係名がほしいなと思いますが、実際の現場ではそもそもフロントエンド専任者というポジションでさえとても少なく、フロントエンドなんて呼び名でも贅沢なのにその中でさらに名前を持つなんてことは湯婆婆が許すとは思えませんし、その担当が分かれていることは実際にはほとんどないと思います。
ただそれはあくまでも湯婆婆の都合なので、JSON色付け係と呼ばれる仕事の中にも実はいろいろ属性の違うものが隠れとるんだということを忘れなければ、いちいち「フロントエンドなんて大したことやってない。おれはデザインできないしサーバーサイドは中途半端だしデータ分析なんて一切できない...うわあああ」みたいな気持ちにならなくて済みそうです。もちろん全部できる最強な人も世の中にはいるのですが、まあそれはおいといて、JSON色付け係もそれなりに大変だし、一つ一つ丁寧にやってくしかないという気持ちを改めて持ったのでした。
