旧gaaamiiのブログ

間違ったことを書いている時があります。コメントやTwitter、ブコメなどでご指摘ください

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」を見に行った

Ruby 勉強会

同僚の id:atomiyama さんがRustでgemを書く話をするそうで面白そうだったので行ってきました。

heiseirb.github.io

各セッションの感想など

RubyでJVMを実装してみる

speakerdeck.com

Javaでコンパイルして出てくるバイトコード読んで云々という話だったけど、ぼけーっとバイトコード眺めてる間に話が進んですぐについていけなくなってしまった。あとスライドのコードとかあまり見れなくて視力の衰えを感じた...。

rustで拡張モジュールを作成してgemにする

speakerdeck.com

  • 順を追って説明してくれてありがたかった。
  • Rustで速くなるんだったら一部だけRustで書いてgemにするのはよさそう。どんなモジュールだとRustにするメリットが大きいんだろうと興味が湧いた。
  • 以前はffiを通じて他言語の実装を使うみたいなのはなんかすごい特殊なイメージがあったけど、最近（というか去年の今頃）ElmでPortを通じてJSのライブラリ呼び出すみたいなことをしてからは、必要があってインタフェースがちゃんとしてるんだったらやっていいんじゃないのという気持ちになっていたのでなおさら興味深かった。

やわらか増税 〜はじめての増税対応〜

真のREST

www.slideshare.net

自分は正直RESTといえば「URLでリソース表してHTTPのメソッドでCRUDするやつ、Railsがやってるやつ」みたいな雑認識があったので、その雑認識がとりあえずは潰されてよかった。特にREST APIはハイパーテキスト駆動ではないといけないというのが全然自分の頭の中になく、なんなら驚いてしまった。ちゃんと勉強しよう...。RESTful Web APIsという本が良いらしいので読んでおきたい。

全体の感想

どのセッションも自分が知らなかったことが多く、勉強になりました。どんなプラットフォーム向けに何を書こうにも、コンピュータそのものとか言語処理系のしくみとかWebの歴史とか、そういう基礎的なこと（だけど実務で学ぶ緊急性があまりないこと）をしっかり理解しておかないといけないな...と同世代のできる人たちを見ていて感じました。

「サバイバルファミリー」を観ました

映画

サバイバルファミリー

サバイバルファミリー

Amazon

突然電気もガスも水道も使えなくなって情報も全然入ってこないみたいな状況で家族みんなで東京脱出して云々というすごい大変そうな話だけど、暗い感じはなくてへらへら笑いながら観れて楽しかったです。

PWA Night vol.10 行ってきました

PWA 勉強会

pwanight.connpass.com

なんで参加したか

趣味で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 考えごと

ちょっと前に、はてなブログのテーマを作った。いや、作ったというか手元にテンプレートをおいていじくったやつを貼っ付けてるといったほうがいいかもしれない。

はてなブログは以下に素晴らしいテーマがたくさんある。

blog.hatena.ne.jp

あるんだけど、せっかくCSS読み書きできるのだから自分で書いてちまちま直すほうが、週末に庭の手入れしてるじいさんみたいな感じで楽しそうと思った。はてなブログの自作は以下のページを読むとわりと簡単にできる。

help.hatenablog.com

ありがたいことに、そのまま適用してもちゃんとした見た目になるボイラープレートがある。ありがたい。つまり、自作テーマを作るといっても自分でいちから書く必要はなく、ボイラープレートのリポジトリをcloneしてきて、npm i; npm start して、確認しながらCSSを書いて、ビルドされたCSSを貼るだけでいい。投稿したテーマは、良い具合の出来になるまではストアに公開せず、自分のブログにだけ適用しておけばいい。

f:id:shgam:20191112000312p:plain
自作テーマ管理画面

リモートワークについて

考えごと

最近仕事どうやってやるのがいいかなあと考える機会が多く、その中でリモートワークについても考えることがある。今の所は以下のように考えてる。

自分はフルリモートじゃないと絶対嫌だという気持ちはないのだけど、考えてみれば往復2時間くらい毎日使うのはもったいないよなあと思う。たとえば週3日のリモートワークが許されているとして、時給が2000円だとしたら、往復2時間×週3日×2000円×4週間×12ヶ月って考えて、576000円！？お得！ってなる。実際、自社にリモートワーク制度ができたときは少し感動した。

もちろんリモートワークはチーム的には工夫しないといけないこと（ビデオ会議どうしようとかちょっと相談したいときどうしようとか）が出てくるので最初は面倒だとも思うし、一緒に働く人とオフラインでワイワイする時間もあったほうがいいと思うんだけど、通勤時間は当たり前に受け入れすぎて忘れがちだけどなかなかの損だよなあ、何も週5日でやらなくても、という思いもある。リモートワークがどうしてもできないとかではなくちょっとした工夫で成り立つレベルであれば取り入れたほうがよさそうだと考えている。

Custom TypesのデータをJS界に受け渡しする(Elm)

Elm

Elmでアプリケーションの状態をlocalStorageに保存しとくようなものを作っていて、カスタムタイプはどうするのか知らなかったのでメモ。

雑にそのままportに渡そうとしたところ、以下のコンパイルエラーが出てきました。

The setStorage port is trying to transmit a ColorTheme value:

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として返ってきたデータを人向けに表示するという仕事が多く、雑に言い表せてる感じが面白い。

上のはジョークだと思うんですが、とはいえ真面目に考えてみると、JSONを人に見やすくする作業をひたすらやっているのだから、もう少し仕事楽になってもいいんじゃないか？なんでJSON色付け係は相変わらず大変なんだ？という疑問が湧いてきます。それについて、自分なりに考えを整理しておきたいと思いました。

JSON色付け係は何をしているのか

自分の最近の仕事を振り返ると、JSON色付けの仕事は前準備と実装の2段階に分けることができます。

前準備

機能を作る以前に、1行のコードも存在しない段階。

言語やライブラリの選定

もちろんやることによって何を選ぶべきか違うと思うのですが、やることが一般的なJSON色付けなら選ぶべきものは以下の4つになると思います。

言語

ブラウザならJavaScriptで書けばいいんだろうという感じですが、ES5で書くのがしんどいけど、ES5で配らないとちゃんと動かない環境があり、そういう環境でも使ってもらいたいので、なにかしらの工夫をしてES5のJavaScriptに吐き出すような仕組みを使ってます。ここでやるのは言語選びみたいなものです。ES6で書くか、TypeScriptで書くか、はたまたほかのAltJSで書くか。

画面表示

画面に表示するものを、こういう感じで書きたいです。

<h1>{{ blogPost.title }}</h1>

こういったテンプレート機能みたいなもので、このデータはここに表示されるというのを書けるようになります。

また、パフォーマンスでいうと、画面の差分更新（仮想DOM）も多くのライブラリがサポートしている機能です。

ja.reactjs.org

状態管理

ユーザーが画面操作すると状態が変わって、画面も変わる。というのがだいたいのアプリケーションに必要な挙動です。 これをするには、状態をどっかで持っておく必要があります。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色付け係もそれなりに大変だし、一つ一つ丁寧にやってくしかないという気持ちを改めて持ったのでした。

ISUCON9（予選）の振り返り

ISUCON

今年も、 id:karur4n と二人で、くもキャストチームとしてISUCON9に参戦しました。楽しかったですが、今年も予選突破できず悔しい。

スコアの発表を見ると、

2,600 　くもキャスト

でした。

isucon.net

例年、我々のような弱小チームに語れることなどない...という気持ちであまり真面目に振り返っていなかったのですが、我々のような弱小でも弱小なりに楽しめるんだぞというのが（まだ出たことない人などに）伝わればいいかなと思い、振り返りを書いてみました。

※ISUCONってなに？という方はこちらをご覧ください。

qiita.com

お題

毎年楽しみなお題ですが、今年はIsucariでした。椅子を販売できるサイトらしい。

f:id:shgam:20190908003340p:plain

開始時間の変更

ポータルサイトに不具合があったようで、10::00 -> 10:10に変更されました。我々は、Discordで通話してたんですがマイクの入力がイヤホンからになっていたのでMacの内蔵マイクにしたりとかそういうことをしていました。

Alibaba Cloudコンソールでイメージ展開

迅速に問題は解消されて、予告通り10:10に開始しました。

今回は、予選マニュアルの通りにAlibaba Cloudのコンソールでサーバーにイメージを展開するところからのスタートでした。前回までのISUCONは特にサーバーのセットアップが必要なく、ポータルサイトに入るとチームに与えられたサーバーのIPが表示されているので、そこにsshで入って作業を開始するという流れでした。

設定・起動を終え、サーバー名とGlobal IPとPrivate IPをポータルサイトに登録、Alibaba Cloudのコンソール画面でログインのために作成/設定しておいた鍵を共有、ローカルの/etc/hostsを編集して起動したIsucariの画面を確認するなどしました（10:30）。

f:id:shgam:20190908002040p:plain

ソースコードをプライベートリポジトリへ

id:karur4n に、Githubにプライベートリポジトリを作成、ソースコードを置いて、Contributorに追加してもらいました（10:48）。

使う参考実装はNode(TS)とSinatra(Ruby)どっちがいいかね〜みたいな感じだったので、その判断するために実装読んでもらっていたりもしました。TSでいきましょうとなって、TSでいくことに。

最初のボトルネック探し

また、alpを使ってボトルネックを探すのも、 id:karur4n がやってくれていました（11:18）。

f:id:shgam:20190907222211p:plain

2台構成にする

マニュアルを読むと、3台まで使って良いことがわかったので、ウェブ用とDB用に分けようということで、同じ手順でもう1台サーバーをたてました。この新しいサーバーのプライベートIPを環境変数のMYSQL_HOSTにすればええやろと思ったのですが、ベンチを走らせたところ、どうも接続できていない（11:23）。

セキュリティグループを疑って、3306ポートを開放するルールを追加（11:41）。

しかしうまくいかない...。ここでVPCの仕組み自体の理解が浅いために、あれ、プライベートIPの指定じゃだめ？なんか追加で設定必要？などなどの寄り道をします。寄り道をしたあげく、ping叩いてプライベートIPでちゃんと通信できとるやんというのに気付き、疑念が晴れる（12:01）。

通信はできるけどmysqlクライアントからの接続だけできんぞという問題の切り分けがようやくできたので、mysqlの設定を疑い、無事、MySQLの bind-address オプションが127.0.0.1になっていたのを外すことができました（12:55）。

N+1潰し

僕が2台構成の設定をしている間に、id:karur4n が /users/transactions.json のN+1潰しにあたりました。

ベンチ実行 -> failed.

2台構成、N+1潰しが入ったところでベンチを実行。failしました（12:57）。修正に時間かかりそうだったので、一旦ふたりとも昼飯を食うべく休憩に入ります。1時間くらい昼休憩にしてカレーを食べました（14:00）。

ISUCONサーバー環境git設定

そこまでソースの変更をscpでアップロードしてしていたのを、サーバー環境で git pull できるようにするべく、設定をしました。サーバー環境で ssh-keygenしたやつをGithubの設定画面で設定（14:06）。

git clone したけど、publicディレクトリがちゃんとコピーできてなかったりなんやかんやで時間がたっていたが、そんなこんなの間にfailedの修正もid:karur4n が終わらせてくれていました（14:50）。

ベンチ実行 -> 1210

ベンチがパスして、スコア5000だ！！！！やった！！！と喜んでいたら、見ていたのはJob idの方で、実際は1210ｲｽｺｲﾝでした（14:55ごろ）。

1台構成にしてベンチ実行 -> 900くらい

2台構成にした意味あるんか？という疑問があったので、環境変数変えてlocalhostのMySQLにつなぐように戻して再度ベンチ実行。900くらいになったので、よしじゃあ2台にしとこうというやりとりをしました（14:55ごろ）。

ts-node -> nodeへの変更

ExecStart = /home/isucon/local/node/bin/node /home/isucon/isucari/webapp/nodejs/node_modules/.bin/ts-node index.ts になっていたのを、ExecStart = /home/isucon/local/node/bin/node /home/isucon/isucari/webapp/nodejs/node_modules/.bin/ts-node index.js ビルドしたやつを実行するように変更（14:58ごろ）。TypeScriptだとビルドあるからということでそうなったんですが、よく考えるとts-nodeも結局ビルドしてからプロセス立ち上げるのでこれはやらなくてもよかった...?

campaign値の変更

今回のお題はIsucariという架空の椅子専門フリマサイトであり、以下のような仕様になっていました。

POST /initialize のレスポンスにて、ｲｽｺｲﾝ還元キャンペーンの「還元率の設定」を返すことができます。この還元率によりユーザが増減します。 有効な値は 0 以上 4 以下の整数で 0 の場合はキャンペーン機能が無効になります。

ここまで（スコアだと1210）ではこれをずっと0にしたままだったので、値を変えてベンチを走らせた結果、以下のようになりました（15:16）。

f:id:shgam:20190907233535p:plain

外部サービスのURL取得にDBから引っ張るのやめようとする

アプリケーションから外部APIを叩いている箇所があり、そのAPIのURLがDBに入っていて、それを毎回SQLで取得していました。テーブルには外部APIのURLがこのように保存されていました。

mysql> select * from configs \G;
*************************** 1. row ***************************
name: payment_service_url
 val: https://payment26.isucon9q.catatsuy.org
*************************** 2. row ***************************
name: shipment_service_url
 val: https://shipment26.isucon9q.catatsuy.org
2 rows in set (0.01 sec)

じゃあこれを文字列としてソースコードに書いちゃっていいんじゃないか、と思ってそうしたものの、ベンチがfailするようになってしまいました（15:26）。

GET /users/transactions.json: got response status code 500; expected 200,
POST /buy: got response status code 500; expected 400 (item_id: 50002),
POST /buy: got response status code 500; expected 200 (item_id: 50001)

よくマニュアルを読むと ベンチマーク走行時にこの値は書き換わる とのこと。残念でした。

外部サービスのURLをキャッシュしようとする

せめてこの値をキャッシュしようとしました。lru-cache というパッケージを追加し、取得の関数でキャッシュを作り、以降はそれを見るように変更しました（16:30）。しかしスコアに改善は見られず...。

getItem

/itesm/:id.json に対応するgetItemという関数がだいぶクエリを発行していたので、これもJOINすればN+1潰せる系かと思い、手を出しました（16:53）。

が、結局悩んでいる間にその修正は間に合わなそうになります（17:21）。

API リクエストが直列になってるの並列にしようとする

id:karu4n の方では、/buy で行われているAPI リクエストを並列にしようとしていました（16:55）。こちらはコミットして変更を反映するものの、スコアに影響は出ませんでした（17:14）。

なぜかfailする

時間も時間なので、そろそろ大きい改善を諦めて調整に入ろうとします。が、ベンチを走らせるとfailedになっていまいました（17:24）。しかしfailedにならず普通にpassするときもあり、よくわからんなとなります。外部サービスのURLをキャッシュするやつがなにかよくない...?と推測してその変更を外して走らせたりしたところ、安定してpassするようになったので外して提出しようと思いますが、最後の方でキャッシュをsetする位置を変えた（/initializeが叩かれたときにキャッシュするようにした）やつで試したところ、passするようだったのでその変更入れました。

ウェブサーバーのmysqlを停止

なんかもう大きなことできないなと思ってつつtopを眺めていると、ときどきmysqldが上に上がってくることがあって、DBサーバーでもないのにこいついらんやろと思ったので、おもむろにウェブサーバーの方で sudo /etc/init.d/mysql stopしときました（18:00ごろ）。

nginxいじる

最後の最後でもう時間もないですが、ぺろっと設定入れて改善するものがあれば入れたいという感じで、 id:karur4n がNginxからgzip圧縮して返すような設定を入れてくれていました。スコアが伸びなかったのでもとに戻してフィニッシュ（18:10）。

感想など

以上は、当日終わったあとにやったことを振り返ってまとめただけのものなので、僕らの勘違いが含まれている可能性もあります。後日講評と解説が公開されたら、それを読みながら再度振り返りをしたいと思います。

こうやってやっていたことを振り返ると、1つ1つ検証せず複数修正を入れて一気にベンチ走らせてスコア伸びたり落ちたりして一喜一憂という場面もあったので、相変わらず雑だったなという反省もあります。

また個人的には、ソースコードを開けば明らかに無駄に発生してそうなDBへの問い合わせは見つかるんですが、それをスピーディに直してベンチ走らせてスコア伸ばすということができておらず、すごい純粋に力不足だったな〜と感じました。そこらへん毎年 id:karur4n のほうができているので、足を引っ張ってしまって申し訳ない。

一方で、一昨年、昨年も出てるので慣れてきたのもあり、やろうとしていたことはそんなに悪くなかったような気がします。マニュアル読んでまずサーバー環境を2台に増やすとか、修正をちゃんとgitで管理/反映するとか、alpでやばそうなところを見つけてそこを直すとか、failしたらログを見て原因を見つける、というようなことはできていたので、そこらへんは例年に比べてバタバタ感が減っていて良かったと思いました。

なにより楽しかったので、また来年も参加してみようと思います。一緒に出てくれた id:karur4n と運営の方々に感謝です。 お疲れさまでした 🍣

デスクトップPWA楽しい

Elm

趣味で https://github.com/gaaamii/nekobito というMarkdownエディタをElmで書いているんだけど、久しぶりに開いたら、Chromeアプリとしてインストールできるようになっていた。

f:id:shgam:20190827003521p:plain

ダウンロードされたものを見ると、 app_mode_loader という謎ファイルができているようだ。あとでこれどういうことなのか見てみたい。

どういう仕組みなのかよくわかっていないけどたぶん、以前PWAお試しようと思って雑に置いておいたmanifest.jsonのおかげのような気がする。

なにはともあれ、Elmで書いたものが、ネイティブアプリのように起動できて使える...!!楽しい!!!

趣味開発やっていきたさが高まった。

（追記）デスクトップPWAというらしい。楽しい。

「Elm Meetup in Summer」参加した

Elm 勉強会

書くのが一日遅れましたが、Elm Meetup in Summer - connpassに参加してきました！ 楽しかった〜！昨日ちゃんと感想書こうと思ったけど寝てしまったので、いまさらですが箇条書きで書いておきます。

感想

  • 人がたくさんいてElmの勢いを感じた。
  • Elm in Actionという良さそうな本を知ることができてよかった。
  • Fringe81の泉さんの個人開発リポジトリを知れてよかった。Firebaseは自分も趣味開発で使いたいので参考になる。
  • モジュール分割はみんな悩んでそう。
    • モジュール分割の方法が、これだ！っていうのがわかれば大きなアプリでも安心して作れそう。
  • プロダクトで採用してるという人が思ったよりいたけど、Elmはまだメジャーバージョンが0なのに採用できるのけっこう勇気あると思う。どんと来い、breaking change という感じなんだろうか（自分も0.18のときに採用したので人のことを言えない）。
  • Elm普段から使ってる人は割と普通に便利に使ってて、Elm大好き！というよりは淡々とやっていってる感じがあってよかった。
  • jinjorさんのスライドを見ればElmの歴史がわかるので時々見返したい。

仕事のやりがいとは何か？をもう一度観てみた

TED Talks


ずいぶん昔に、まだ働き始める前にこの動画を見た時は、ふーんそうなんだとしか思わなかった。そら褒められた方が仕事楽しくなるよねと。

働き始めてしばらく経ち、動画を見返してみた。動画で強調されているように、大げさなリアクションではなくちょっとしフィードバックだけでもモチベーションに影響があるということが、実感としてわかるようになっていた。

働き出す前に見たときよりも、動画内で語られているちょっとしたフィードバックの大事さが腑に落ちる感じがあって面白かった。