ナカザンドットネット

それって私の感想ですよね

クリスマス料理に疲れたら無水白菜カレー

バズレシピAdvent Calendar 2023の25日目です。

adventar.org

クリスマスイブで張り切ったので、もう疲れた! 込み入った料理はしたくねえ! しかし冷蔵庫には消費期限がギリギリの豚こまと、大量の白菜が眠っておられる! どうする!

そんなときに役立つのが、「無水白菜カレー」です。

www.youtube.com

食材としては、ほぼ白菜と豚肉とカレールーがあればいけます。すりおろしニンニクも必要ですが、チューブでええんじゃ。後の調味料は家にあるな!ヨシ!

玉ねぎを切らなくても甘く美味しくなるので、怠いときにめっちゃオススメ。レシピだと甘みのためにお砂糖を追加してるんですが、実はカレールーを甘口のやつにしておけば、お砂糖の工程がなくても全然大丈夫です。我が家は4歳児のためにバーモントカレー甘口のストックが豊富なので、砂糖なしでいけます。

そんなわけで調理工程の様子〜。

お手軽白菜カレー

美味しくいただきました。

アドベントカレンダー2023終了

今年もなんとか最終日にたどり着けてよかった……!

皆さんが料理にこだわったり雑にしたりしている様子が見えてめっちゃよかったです。来年もやりたいな!

塩フライドチキンでメリークリスマス

バズレシピAdvent Calendar 2023の24日目です。

adventar.org

メリークリスマス!ということで、クリスマスっぽい料理を作りました。

メリクリ

写真右のフライドチキンは「塩フライドチキン」、写真下は「超柔らかむねローストチキン」でした。

www.youtube.com

www.youtube.com

いやーどっちも美味しかった。子供達にも好評でよかったです。

納豆カルボナーラはワンパンで作れる

バズレシピAdvent Calendar 2023の22日目です。

みなさん、納豆カルボナーラは好きですか!

www.youtube.com

僕は好きです。

今回は納豆カルボナーラのワンパンバージョン、いわゆるリゾッタータによる調理に成功したので、紹介したいと思います。

途中までは原作通り

調理の順序を少し変えるだけですので、順を追っていきましょう。分量はどれも原作そのままです。

  • オリーブオイルでニンニク、ベーコン、玉ねぎを炒める
  • 酒を入れて炒める
  • ひきわり納豆を入れて炒める

ここまでは全く同じです。次が重要な変更点です。 バターはまだ入れません。 バターを一緒に煮込んでしまうと、流石に香りが飛ぶと思うので、バターは最後に入れます。

  • 白だしを入れて炒める

バターを省いただけで、ここまでほぼ原作通りにソースを作っていますね。

大きな変更点

ここからは大きく変わっていきます。

  • このタイミングでソースの水分をしっかり飛ばします

原作では酒や白だしの水分が残っていることは許容されていますよね。後でパスタの煮汁を足して水分(と塩味)を補強するとはいえ、別にソース作りの工程で積極的に水分を飛ばすことには言及されていません。

しかし本レシピでは、これから水を入れてリゾッタータを行うので、酒や白だし(もしかしたら納豆も)の水分を飛ばしておいて、水分量のコントロールを行いやすくするほうが重要です。また、水分を飛ばす過程で、ベーコンや納豆に酒や白だしの旨みが吸い込まれることも期待できます。

  • フライパンに350mlの水を入れて沸かす
  • 小さじ1/3の塩を入れる
  • 1.6mmのパスタ100gを入れて7分茹でる

この辺は、普段のリュウジのワンパンレシピを見ている方なら見覚えがあるものだと思います。

リゾッタータしてるところ

  • 茹で汁が大さじ1残るくらいまで水分が飛んだら、火を止めてバターを入れてよく混ぜる

この辺は至高を超えたボロネーゼを参考にした調理工程です。たぶん最後に入れたほうがバターの香りが活きると思いました。

  • お皿によそって、卵黄を乗せて、黒胡椒とパセリをふったら出来上がり

ということで出来上がったのがこちらです。

ワンパンで作る納豆カルボナーラ

かなりうまい

煮込むことで納豆の風味が飛んでしまわないかなと不安だったのですが、出来上がってみると、パスタとの絡みがめちゃくちゃ良くなっていて美味しいです。焦がしチーズ納豆みそラーメンでは納豆を茹でても美味しいままだったので試してみましたが、正解でした。

というわけで、原作との違いは以下のポイントでした。

  • バターを最後に入れる
  • 炒め工程で調味料の水分は飛ばす
  • 水は350ml入れる
  • 水に塩小さじ1/3を入れる

マジでめちゃくちゃ美味しいので、納豆カルボナーラ大好き勢の皆さんは是非とも作ってみてください。

アウトプットまとめ2023

そーだいさんのアウトプットまとめを見て、久々に僕もアウトプットまとめしようかなと思いました。

過去のまとめはこちら。

今回はジャンル別にしてみます。

登壇

今年登壇したのは4回でした。新潟でLTイベントの「新潟5分Tech」をスタートできたので、来年は登壇の機会が増えるかも。毎月どこかの金曜日にやる予定なので、ちょうど新潟に来れそうな方がいたら顔を出してみてください。

今あらためて考えるフルリモートでうまくいくプロダクトチームの作り方!

speakerdeck.com

技術書典14スポンサートーク

plus.monicle.co.jp

新潟5分Tech

niigata-5min-tech.connpass.com

niigata-5min-tech.connpass.com

同人誌

2019年以来となる、技術同人誌を出しました。

techbookfest.org

Pull Request

今年はひとつだけOSS活動をしていて、MUIのRemixサンプルをv1からv2に移行しました。全世界100万人のRemix + MUIユーザー(そんなにいねえよ)を救ったので褒めてほしい。

github.com

なんか今見たらRemix + MUIの体験をもうちょっとなんとかしようぜIssueが立ってたので、なんか手伝えそうなら手伝いたい。

連載

CodeZineさんで4本並行で連載を持っており、合わせて10本の記事が出ました。年内にもう一本出るかも?

オウンドメディア

会社のオウンドメディア、モニクルプラスでも時々ライター業をやっていました。

3月の純粋培養〜の記事は当初、3,000字くらいで軽めのイベント参加報告をしてほしい、みたいなオーダーを編集長から受けていたのですが、初稿をゴリっと書き終えたら13,000字くらいのマッチョな記事に仕上がっており、急遽特集記事としてラベリングされたという事故があったりしました。懐かしいですね*1

Zenn

Zennはスクラップ1本、記事3本でした。

sizu.me

しずかなインターネットも始めました(正直立ち位置に困ってる)。

ここ

雑多に書いてましたが、だいたいアドベントカレンダーですね。やはり締切はコンテンツを生む……

まとめ

オンラインも含めれば、登壇は年に1〜2回ペースで続けられています。子供の手がかからなくなってきたらもう少しやりたい気もする。

ブログ記事はここ数年で一番書いたかもしれないです。なんだかんだでCodeZineさんでの連載のおかげで、テクニカルライティングの習慣がついているのはいいことなのかも。

基本的には家事と育児と本業と技術書典開発チーム業あたりで手一杯になって疲弊していますが、今後ともアウトプットは続けていきたいと思います。

それではみなさま、良いお年を。

*1:この出来事で本格的に編集部から「開発部門のライター役」としてロックオンされたような気がします。

モニクル社のzp-チャンネルを振り返る2023

モニクル Advent Calendar 2023の14日目です。昨日はコーポレートブランディング担当・高村さんの「表記のルールを考える 〜オウンドメディア運営の現場から〜」でした。記事公開後に社内で「僕は表記揺れのチェックにReVIEW-Templateのprh-rulesみたいなのを技術同人誌を書くときに使っててー」みたいな話をしたら、テンションぶち上がってました。

さて、本題に入りましょう。1年半ほど前に、こんな記事を書きました。

blog.nkzn.net

筆者の入社前に分報文化が上手く定着せずに廃れていた times_ チャンネルでしたが、筆者が社内Twitterのような サボり場 雑談の場として利用したところ、コミュニケーションが活気づいた(ついでに命名規則を zp- にした)というお話でした。

あれからエンジニアの人数も倍くらいになり、zpチャンネルの使われ方がどうなったかを振り返ってみようと思います。

投稿頻度に差はあるものの、独り言チャンネルとしては引き続きワークしている

筆者はXと同じかそれ以上くらいの頻度でzpに投稿していますが、そこまでではないにしても、みなさん自分のペースでzpチャンネルを活用するようになっています。

zpの運用が定着した

SWEのオンボーディングのワークフローにzpチャンネルの作成が組み込まれているのも大きいかもしれません。入社時のオンボーディング作業のために onboarding_(名前) というチャンネルを立てているのですが、ひと通りのチュートリアルが終わって、初めてのPull Request出したり初めてのデプロイをしたあたりのタイミングで、 zp-(名前) へとリネームする運用にしています*1。そのため、ここ1年半くらいで入社したSWEは必ずzpチャンネルを持ってるんですよね。

やはり入社したばかりだとパブリックなチャンネルに質問や意見を投げるのが怖いということもあると思うので、「自分がイニシアチブを持っているチャンネル」がひとつあるというのは、安心につながる部分もあるのではないでしょうか。しらんけど。

日報の投稿場所としてワークするケースが増えた

割と意外だったのは、日報をつける人が続々と現れたことです。

日報としてzpを使うケースが増えた

初めは、ある新しく入ったメンバーが、習慣として出退勤の報告や日報を書いてくれていただけでした。それ自体は「ちょっとお堅い使い方だけど、それもまたzpだよね」くらいで筆者も眺めていたのですが、それを見た別のメンバーが「あれ、日報を書いておくと、翌朝や週明けに作業を再開するのがスムーズだぞ?」というのに気がついて、真似し始めたんですね。

そこからは早くて、気がついたら開発チームの過半数くらいが日報を書くようになっていました。「上長に書かされる日報」というのは筆者も新卒の頃に経験があります*2し、まあまあ面倒なものでしたが、「自分のために書く日報」というのは、こんなに定着するものなんだなあと驚いたものでした。

周りのメンバーからしても、どんな作業を抱えていて、何に困っているのかを検知しやすいので、本来の分報チャンネル的なメリットが一周回って戻ってきた感じがとてもよいですね。

ちなみに、特に日報をつけなければいけない圧力はないので、入社をご検討いただいている方はご安心ください。あくまでも「日報でも書いておかないと明日の自分が今やってる作業を思い出せる自信がない」といったような各自の現実的な判断により、自発的に行われています。

個人への連絡先や1on1の起点としての利用

モニクルでは、情報のサイロ化を避ける目的で、DM(ダイレクトメッセージ)の利用が原則禁止*3になっています。

そのため、「1on1のリスケお願いします〜」とか「今度飲みに行く時のお店どうします?」のような、個人対個人の色合いが強い連絡があるときは、zpチャンネルをDMの代わりに使うことがあります。DMと同じように「それはもっと適切な業務チャンネルで話したほうがよさそう」という話題が現れることもなくはないですが、見かけ次第誘導したりしなかったりしています。まあ他に誰もいない場所で喋られるよりは、多少のスレ違いのほうが1万倍マシです。

まとめ

というわけで、zpチャンネルが色々な活用のシーンを見せ始めていて、やっぱり社内のコミュニケーションを活発にしていてよいというお話でした。

*1:どこかの会社がそれで上手く回っているというのを見かけて真似したんだけど、どこだったか思い出せない

*2:僕が書いてたのは週報だっけな

*3:もちろん機密情報や社員自身の個人情報を扱う会話は例外です

バズレシピに慣れてきた頃に見始めた料理系YouTubeチャンネル

バズレシピAdvent Calendar 8日目です。

adventar.org

今日は、筆者がバズレシピのおかげで料理に慣れてきた頃に見るようになった、別のYouTubeチャンネルについて紹介しようと思います。

少し企画の主旨からは外れますが、たぶん需要はあるはず。

料理技術のステップアップ

どんな技術の世界でも、入門書で最初の一歩を踏み出したり、自分にもできる!と自信をつけたりした後で、もっといろんなことを学びたいと思った時のために、「次に読む本」のような学習パスがあると、スムーズにステップアップできます。

料理のステップアップについてはリュウジさんも言及しておりまして、2023年10月2日にアップロードされた、最高傑作カルボナーラ回の質問コーナーに出てきています。

回答の主旨としては、まずは虚無シリーズのような簡単なレシピから始めてもらって、慣れてきたら至高シリーズにもチャレンジしてほしい、というものでした。わかる。

まあ筆者からひとつだけ文句をつけるとするなら、例に挙げていた「虚無ボナーラ」は、いうほど簡単ではないので、初心者にはオススメしづらいという点でしょうか。終盤に半熟に仕上げる際の火入れの加減が難しくて、コメント欄で「いや、リュウジは弱火で混ぜろと言っているが、俺たち素人が火を入れてもやりすぎてボソボソになるので、諦めて火を消して余熱でできる範囲で仕上げたほうがマシ」という結論が出ちゃった程度には難しいんですよ。カルボナーラ系で一番簡単なのは、酒飲んでなかった太古に作られたレンチンカルボナーラです。

少し余談が過ぎましたが、バズレシピの中にもステップアップのパスはあるということです。

さて、それでは、他の料理系YouTubeチャンネルはどうだろう?と目を向けてみるのが本記事の主旨となります。バズレシピのいいところである、「家庭にある食材の範囲で手間をさほどかけずに美味しいものを作る」というテーマはさほど崩さずに、リュウジさんとはまた違ったアプローチで味付けをしている人を見ることで、調理技術の学びの幅が広がるのではないでしょうか。

というわけで、サッポロ一番無水みそ油鍋からバズレシピを見始めて、そろそろ3年くらい料理をしている筆者が近年見ている他のチャンネルを紹介します。

Koh Kentetsu Kitchen

まずは料理研究家コウケンテツさんのチャンネル。

www.youtube.com

リュウジさんほどの時短テクニックを駆使することは少ないものの、家庭にある材料で、愚直にレシピを教えてくれます。ジョークが滑っても誰も突っ込まないテンポ感が独特です。

チキンスティックや棒餃子、にら饅頭など、子供ウケのいいレシピには本当に助けられています。

www.youtube.com

www.youtube.com

www.youtube.com

バズレシピとの比較でいくと「常にほぼ至高」という感じがします。初心者がいきなり手を出すとしんどそうなレベル感ではありますが、バズレシピでしばらく修行を積んだ後なら、コウケンテツさんのレシピも恐れることはないはずです。

だれウマ

次はだれウマさんです。

www.youtube.com

筋肉系YouTuberという感じで、筋肉ネタ満載のトークに耐えられるかどうかが試聴を続けられるかどうかの分かれ目です。やっていきー\\💪マッチョ💪//

こちらはバズレシピの平均値くらいのレベル感のレシピが多いので、たまに手を出してもしんどいなと思わずに済むことが多いです。

特に好きなのは、2023年5月アップロードの極ツナパスタです。

www.youtube.com

飴色玉ねぎを作る部分でやたらと時間がかかる点だけが面倒くさいものの、その面倒くささが気にならないくらいに、出来上がったものが美味しいです。ハマった時は週3で食べてた。

ボディビルダーとしても活動している方なので、痩せめし系がガチなのもポイント高いです。

【賛否両論】笠原将弘の料理のほそ道

最後に、賛否両論、笠原さんのチャンネルです。

www.youtube.com

料理研究家ではなく、恵比寿の日本料理店のご主人という本職の料理人さんがやっているYouTubeチャンネルです。チャンネル開設が2023年6月ということで、最近始まったばかりと言っていいと思います。

語り口は軽快だし、編集もお上手、もちろん腕も確かなのに、ちゃんと家庭料理で扱いやすいレベル感に落とし込んでくれています。

今のところ、鶏むね肉の牛タン風とか、吉野家っぽいやつとか、親子丼を作ってみました。

www.youtube.com

www.youtube.com

www.youtube.com

料理中の雑談が深い経験に裏打ちされている感じで、大変勉強になります。

リュウジさんだと「鶏肉の下処理はしなくてもいい。これはこれで美味いし」と時短目的で端折られている部分についても、「神経質になる必要はないけど、ここまではやってもいいかもね」という下処理の範囲を実践してくれていたりして、ワンステップ上を教えてくれる感じです。とはいえ、特にバズレシピよりも面倒という感じがしないのは、笠原さんの飄々とした語り口あってのものという感じがします。

まとめ

というわけで、バズレシピで得た経験のおかげで見れるようになったチャンネルを紹介した感じになりました。

技術的な面だけでいうとファビオ飯あたりも何を言っているのかわかるようにはなってきているのですが、いかんせん材料が全く家庭料理向きではないので、今回は除かせてもらいました。

会社の同僚と話していると、バズレシピのおかげで白ごはん.comのようなレシピサイトが読めるようになってきて、重宝するようになった、といった話も聞くようになりました。筆者は動画じゃないと頭に入ってこないので使っていませんが、こういう方向性もアリですよね。

バズレシピのおかげで身についた料理の基礎を、もっといろんな場面で使えるように、今後も学びを深めていきたいと思います。

プログラミングを始めてからこれまでどこにフォーカスしてきたか振り返ってみる

mhidakaが建てたAdvent Calendar 2の8日目です。テーマ性なさすぎてほんと狂ってんなこのカレンダー……

adventar.org

というわけで何書いてもいいらしいので、サクッと書ける割に独自性の出やすい、自分の経験を振り返る系記事にしてみようと思います。

コンピュータサイエンスの大学に2005年に入学した人間としてはお恥ずかしいところなのですが、コードを書こうと思ってコードを書くようになったのは大学5年目の2009年だったので、僕の主観では2023年現在がようやくプログラマー15年目という感じです。節目っぽい感じがするので、それぞれの年で思い出深いテクノロジーを思い出していこうと思います。

それ職務経歴書じゃね?と思わなくもないですが、もうちょっとライトかつミーハーな感じでなんとかしたい。やっていきましょう。

2009年(22歳)

プログラマーとしての自我を持ち始めたのはこの年でした。なんとか卒論を書くのに必要な単位が溜まって、さて何を書こうかなと思っていたところに、担当教員から「なんかAndroidとかいうのが日本にも来るらしいじゃん?HT-03A?とかいうの買ってあげるからやってみない?」と言われて、卒業研究がAndroidになったのでした。

研究室は医療系、特にバイタルサイン系に強みがあり、さらにモバイルデバイス(当時はガラケーが主流)との連携が得意な、ちょっと特殊なところでした。そこで何をすることになったのかというと、Nonin社のパルスオキシメーターとAndroidをBluetoothで繋いで、SPPで送られてくるバイナリのストリームをいい感じにAndroidで処理できる形に落とし込むやつです。

blog.nkzn.net

これのやばい話としては、当時のAndroid 1.6って、Bluetoothが非公開APIだったんですよね。がんばってリフレクションしてBluetoothのAPIを引っ張り出しながら無理やり使ってました。当時、「すれちがったー」のesmasui先生には大変お世話になりました……

そんなわけで、2009年にフォーカスしていたテクノロジー分野はこんな感じでした。

  • Android SDK(Android 1.6)
  • Bluetooth
  • 血中酸素飽和度(SpO2値)計測

2009年当時だと、SpO2値は喘息持ちの方は知っていることが多いものの、一般的にはややマイナーなバイタルサインでした。そのため、卒業研究を他の人に説明するときに「ふーん……?」というピンと来ない感じの反応をされることが多かったです。

それが、2023年現在では、もう少し有名な指標になりました。COVID-19に罹患した際の体調の指標として、SpO2値が参照されるようになったため、計測器であるパルスオキシメーターともども、僕が研究していた分野が広く一般に知られるようになったのです。何が起こるかわからんもんじゃ。

2010年(23歳)

2010年の春に大学を卒業して、地元にUターンして就職しました。就活していた2008年の時点ではプログラミング苦手マンだったので、人柄で採ってもらえるところに拾ってもらいました。サークル活動で日本中回ってたり、サークル自治会の会計職やったり、原付で新潟県を縦断してたり、無駄にアクティブな学生生活を送っていたので、面接で「キミ営業職で入る気はない?」と訊かれてしまったのは良い思い出です。

お仕事としてはB2BのWeb系受託みたいなことをやりつつ、学生時代にご縁ができたAndroidコミュニティと関わりを持ちながら、新潟市でAndroidの勉強会を開催したりしていました。

2010年のキーワードはざっくりこんな感じでしょうか。

  • Java 1.4
  • JBoss
  • ASP.NET + HTML + CSS
  • VB.NET
  • Android 2.x
  • Android Maps

これまでの人生で、ちゃんとお仕事で.NETを触ったのはこの時期だけです。趣味でC#も触ってみましたが、言語としては全然違うのに、VB.NETとほとんど同じ標準ライブラリがちゃんと触れるのはすごいなあと感動したのを覚えています。当時メインでやっていたJavaでは、言語とランタイムの距離が近いので、言語とランタイムを分けて考える発想がなかったんですよね。今考えるとAndroid Javaというランタイムは普通のJVMとは似ても似つかない感じだったのですが、それを切り分けて考えられるきっかけになったのは、.NETの経験でした。

そういえば、大学の卒業前にGClue社でアルバイトをすることになり、Android 1.6のマップ上でGeofencingの自前実装みたいなことをするアプリを作っていました。当時の勉強会で、Android Mapsについて喋っていたのが見つかりました。

www.slideshare.net

僕のGIS元年は2010年だったようです。

2011年(24歳)

この年の9月に転職して、約10年ほど農業ITをやることになりました。それまでの期間は、Webサイトを作っていましたねえ。お仕事でWordPressを触るよりも先にConcrete 5を触るという不思議な経験をしました。結局年末には転職先でWordPress製の自社サイトをメンテしていたのを思うと、CMSと距離が近い年だったのかもしれない。

2011年のキーワードはこんな感じ。

  • Android 2.x〜3.x
    • Android Maps
    • ActionBarCompat
  • Concrete 5
  • WordPress
  • Corona SDK / Lua言語
  • Git

僕が携わることになった農業ITシステムは、現在の語彙でざっくり言えば農業向けのGISだったので、主に戦う相手はAndroid Mapsになりました。ActionBarCompatのコードリーディングをしたりもしてたようです。Android 2.x〜4.0の過渡期のあれこれに悩まされていたような気がします。

他に、当時からモバイル向けクロスプラットフォーム開発への関心があったのもあって、友人が取り組んでいたCorona SDK(現在のSolar2D)という、Lua言語でアプリが書けるフレームワークの布教もしていました。電子書籍ではありますが、人生初の本も出しました。

tatsu-zine.com

この本、本名で出しているんですよね。それまでは匿名でインターネッツをやっていましたが、こういった功績はちゃんと現実世界の自分のキャリアに寄与するべきだという意識もあったので、腹を括って本名で活動することにしました。この方針のおかげもあってか、今のところ「中川幸哉」という同姓同名の中では日本一有名な中川幸哉になれているのではないかと思います。

そういえば、現在も技術書典の運営でご一緒しているtakahashimさんと初めて会ったのはこのときでしたし、Gitを初めて触ったのもこの本を書くためでした。ReVIEWにも一瞬だけ触れた気がしますが、基本的にはMarkdownで執筆して、takahashimさんがReVIEWに書き直してくれるワークフローだったような気がします。ちゃんとReVIEWを書くのはもう少し後の話。

2023年から見ると、これが前回の卯年だったわけですが、「せっかくの年男なので、2011年は飛躍の年にしよう」と意気込んでいたのが飛躍しすぎた年でした。

2012年(25歳)

ゴリゴリとアプリを作っていた時期です。

  • Android 4.x
  • JSON
  • Google Maps Android API v2
  • Git

すでにWeb版があるサービスのモバイルアプリ版を整備していくのが主なお仕事だったので、JSON色付け係として粛々とやっていました。当時から思ってたけど、JSONってJavaScript以外の言語で使うと不便じゃないですか?

大きめのトピックとしては、なかなか使い勝手の悪かったAndroid Mapsが刷新され、Google MapsのAPIがちゃんと整備されたのがありました。当時、そこら中で喜びを伝えていたような記憶があります。

2011年と比べて薄味じゃないかって?この記事を書くのに飽きてきたのもあるけど、2011年が濃すぎたんだよ。

2013年(26歳)

お仕事的には農業機械メーカーとの協業が始まった時期です。キーワード的にはこんな感じ。

  • Android
  • Maven
  • Google Maps Android API v2
  • 農業機械(トラクター・コンバイン・田植え機)
  • オフライン機能
  • ReVIEW

こうして並べるとだいぶ濃いですね……

本業では主に、農業機械とモバイルアプリで通信して、擬似的に農業機械をインターネットとやりとりさせるやつを作ったりしていました。今振り返ると、2010年代後半にIoTという名前で流行ったやつでした。うーん先進的。Webサービスやモバイルアプリ開発の面では私たちが貢献しましたが、それ以外の部分については農業機械メーカーさんのプロダクト開発力やサービス構成力に驚かされるばかりでした。

AndroidらしいAndroidな分野としては、2013年当時だとまだ珍しかったオフライン動作にチャレンジし始めていました。AlermManagerで頑張って定期データ同期を実現する荒削りな方式を考案して、なんとかしていたような気がします。データベースを扱う機会が増えたので、OrmLiteを使ったりもしていました。そういえばパッケージマネージャとしてMavenを使うのも取り組んでた気がする。非公式な分野だったので苦しみもあったけど、jarファイルを直接扱う世界から解放されたのは嬉しかった。

他に大きいところとしては、2010〜2012年にAndroid×Googleマップの情報発信をしていたのをmhidakaさん🐏が見てくれていたようで、TechBoosterの巨大合同誌、Effective Androidに誘ってもらいました。ReVIEWをちゃんと書いたのはこのときが初めてだったと思います。

tatsu-zine.com

ちなみに、現職のCTOであるid:gabuchanも参加しています。ご縁って怖いなあ。

2014年(27歳)

このへんはあんまり本業の記憶がない……興味を持って取り組んでいたらしいのはこの辺。

  • Android
  • Android Studio
  • Gradle
  • Robolectric + JUnit
  • オフライン動作(Sync Adapter)
  • ActiveAndroid
  • Kotlin(not Android)

そうだったそうだった。Android StudioとGradleでの開発環境がいい感じになってきたので、会社のアプリのビルド環境をMavenからGradleに移行したりしていました。

Robolectricで自動テストを書きやすい環境もできてきていたので、JUnitとも仲良くなり始めていた頃です。JUnit実践入門は今でも名著だと思ってるよ。

gihyo.jp

2013年に引き続き、オフライン動作については研究を続けていました。50 Android Hacksを参考に、Sync Adapterを頑張って実装すれば割とそれっぽくなることがわかったり。当時はドキュメンテーションが全くなくて、コミュニティベースの手探りで実装方法を探っていました。

SQLiteの管理をもっと改善できないかと悩んで、ActiveAndroidを触ってみた時代もありました。最終的にはこなれているO/Rマッパーはないな、という結論になってしまい、直接SQLを書く形になりました。

ちなみに、なぜかこの頃に一度Kotlinに触っています。

www.slideshare.net

うーん先見の明はあったはずなんだけど、結局Kotlinコミュニティには全く爪痕を残せていないので、今生では強い縁がないのだなという感じ。

2015年(28歳)

ちょっとキャリアの風向きが変わってきたのがこの頃。

  • Android Lint
  • Ionic Framework + AngularJS
  • React Native

本業は相変わらずAndroidアプリ開発だったのですが、だんだんとiOSプラットフォームでも動くものを作らないといけない圧力が高まってきていました。素直にiOS SDKを学ぶ方向に行けばよかったのですが、昔からクロスプラットフォームに憧れがあったのもあって、Ionic Frameworkを試したり、当時まだ出たばかりで眉唾感のあったReact Nativeのソースを読んだりしていました。

新人教育の文脈でAndroid Lintが結構活用できるなあ、と気づいたのはこの年でした。

DroidKaigiの第1回が行われたのもこの年でしたね。2013〜2014年に取り組んでいた、Androidアプリのオフライン動作についての発表を行いました。この時点での僕はもう2年くらいずっとオフラインのことを考えていたので、アプリをオフラインで動かすのはよくある話なんだと思っていましたが、発表してみたら全然そんなことなかったのでバイアスって怖いなと思いました。

watercelldev.hatenablog.jp

2016年(29歳)

ようやく折り返しです。サクッと書けるとか言ったの誰だよ!!!!!

この年はだいぶ尖ってます。

  • Cordova
  • webpack
  • React
  • Material-UI
  • Firebase
  • React Native
  • Clean Architecture

この年は大きく分けて3つほどサービスを作っていました。

  • Cordova+React+Material-UIのiOSアプリ
  • 現場用のAndroidアプリと事務所用のWebアプリのデータ保存先としてFirebaseを使うやつ
  • React Native製の掲示板アプリのプロトタイピング

手広くはあるのですが、全体的に軸足がWebに寄ってきたなという感じがありますね。

それはそうと新規アプリが多かったのがあって、アーキテクチャ周りのトライアンドエラー経験を大量に稼げた時期でもあります。クリーンアーキテクチャをカーゴカルト的に導入して爆死したケースがたくさんあったってことだよ言わせんな恥ずかしい!

たくさんの失敗を経て、設計に関する解像度が少しずつ上がり始めた時期ではありました。特に大きかったのは、↓の発表を見て、PDS(Presentation Domain Seperation)の概念を獲得したことです。

speakerdeck.com

MVCとかMVPとかMVVMとか何が違うのか混乱していたところに、「まずはPresentationとDomainを分離するのが一番大事で、Presentationの中身をどう分けるかは、View-ControllerでもView-PresenterでもView-ViewModelでも、プラットフォームごとの特性に合わせて好きにしたらよい」という指針を与えられて、頭の中がだいぶ整理された覚えがあります。

2017年(30歳)

この年も新規サービスに携わることが多かったです。

  • GPSトラッキング
  • Kotlin + GeoJSON
  • React Native
  • React Native for Web
  • TypeScript

自社のAndroidアプリでGPSトラッキングを行い、田畑への入出場履歴を自動で生成し、労務管理に役立てるような機能を作っていました。デバッグのためにそこら中を歩き回ったのはいい思い出です。田畑のポリゴン情報と人間のポイント情報を比較して入出場を検出するために、各位置情報をGeoJSON表現に変換しつつ、Kotlin製の自作ライブラリでGeoJSONオブジェクト同士の位置関係を比較できるようにするようなことをやっていました。GISっぽーい。

また、少人数で複数プラットフォームに対応する案件が立て続けに来ていたので、片っ端からReact Nativeで薙ぎ倒していきました。ちょっと面白かったのは、プロトタイピング段階でAndroid/iOS/Webの3プラットフォーム向けに作ったとしても、運用を検討してみると、B2B分野では最終的に「Webだけあればよくね?」に収束することが多かったのでした。ちょっと写真を撮りたいくらいならブラウザで事足りますしね。

2018年(31歳)

この年はReact Native路線が強めでした。

  • React Native
  • Expo
  • React Native for Web
  • Create React App
  • TypeScript
  • Reactと相性の良さそうなアーキテクチャの研究
    • Layered Architecture
    • Atomic Design
  • SOLID原則

単純に2017年のプロジェクトが2018年も続いていた感じです。

だんだんと「実は無理にAndroid/iOSアプリを作らなくても、Webだけあればいい分野は結構ある」という認知が育ってきたのはこの年でした。React NativeでAndroid/iOSアプリも少しだけ作りましたが、最終的にはWebアプリばかり作っていたような気がします。

また、生のReact Nativeを使うのは割と疲れてきて、Expo経由しか勝たんな……みたいな顔をし始めたのもこの頃でした。技術書典4で作ったかんたん後払いアプリもExpo製です。

設計分野では、Atomic Designが流行っていた頃で、性懲りも無くカーゴカルトして爆死していました。React + Layered Architectureの実験をしていたのもこの頃ですね。

github.com

この頃には、Layered ArchitectureやClean Architectureを形だけ模倣しても実用的にはならないことは理解しており、Dependency Inversion Principle等の各種原則を場面に合わせて有効に組み合わせることができれば、教科書通りの形を守る必要はないことを実感し始めていました。

原則との付き合い方、みたいなのも意識するようになってきていたように思います。DRY原則なんかは一見扱いづらいのですが、何でもかんでも共通化すると「似てるけどちょっと違うユースケース」が入ってきたときに死ぬことがわかっていましたし、YAGNIも既に確定している将来の課題に対して無策でいることへの免罪符には使えません。SOLIDの各原則は知った時期も影響しているかもしれませんが、濫用しづらくて扱いやすいなあ、という印象がありました。

2019年(32歳)

この頃はもうほぼフロントエンド屋さんです。

  • Create React App
  • Babel
  • webpack
  • GraphQL
  • WebDriverIO
  • Appium

本業でもモバイルWebのサービスを作っていましたし、技術書典Webのサイト構築を担当し始めたのもこの頃です。

Reactと相性の良い設計については、Apollo Clientのおかげで少し進展がありました。上層のコンポーネントと通信を直接繋げてしまうのが良さそうなことがわかってきました。Layered Architectureのように通信の詳細を隠蔽するのではなく、Fragment Colocationによって、コンポーネントひとつひとつのためにFragment Colocationによって専用のデータ型を用意するのです。GraphQLの特性として、Infrastructure層相当の責務の一部(複数リソースの取りまとめ)をAPIサーバーに移管できる特性があるのですが、これのおかげで、階層をグッと減らしても実用上の問題がほとんど起こらなくなったのです。Clean Architectureの呪縛から解き放たれ、守破離が成ったときでした。

会社でモバイルアプリのE2Eテストの機運が高まっていたので、Appiumにも少しだけ手を出していました。Cordova製のアプリもあるので、WebDriverIOを経由してWebViewの操作をする方法の研究をしてたりもしました。

2020年(33歳)

COVID-19が来て、リモートワーク中心になった年です。

  • Wear OS
  • Create React App
  • Babel
  • webpack
  • GraphQL

フロントエンドな関心は続投しつつ、お仕事でWear OSアプリを作る機会があったので、あれこれキャッチアップしていました。

2021年(34歳)

10年ぶりの転職です。スキルセットがガラッと変わりました。

  • Next.js(Pages Router)
  • Ruby on Rails

まさかの完全未経験のフレームワーク×2の環境に放り込まれました。事業とチームだけ見て、使用テクノロジは全く見ないで入社したからね!仕方ないね!

一応前職でもAPIサーバーがRailsだったので、読むだけなら読めたのですが、自分で操作してみると全然感覚が違いました。ActiveAndroidの出来がそんなによくなかったのもあって、ActiveRecordインスパイア系ライブラリには忌避感があったのですが、本家本元を触ってみると、かなり使用感が良くて、驚きました。規模が大きくなってくると難しさが出てくるのは承知していますが、0→1フェーズなら現代でもRailsは良い選択肢のひとつなのだろうなと感じています。

2022年(35歳)

昨年です。ここまで来れば記憶も新しいかと思いきや、意外と何も思い出せません。

  • XState
  • Remix

仕事で診断アプリのようなものを作っていたときに、XStateによるステートマシン定義を試したりしていました。なかなかよかったので、CodeZineさんで持っている連載の中で取り上げたこともありました。

codezine.jp

また、筆者の中でエポックメイキングだったのがRemixでした。あの悪名高いReact Routerのチームが作っているということで、最大限の警戒をしながらキャッチアップしたのですが、思いのほか良いものでした。React Routerを拡張する形で、高度に通信とルーティングが統合された環境は快適でしたし、Web標準に則ることをベストプラクティスにすることで教育コストの効率を上げる方針にも好感が持てました。ブラウザ側で非同期通信をする機会がほとんどなくなったことで、脳にかかる負荷が格段に減ったのは、本当に素晴らしいことです。

2023年(36歳)

というわけで、今年です。また卯年になりましたが、24歳のときとは違ってゆるゆるとやっています。

  • Remix
  • Next.js(App Router)
  • Terraform

App RouterはRemixにインスパイアされて生まれたもの(要出典)なので、好ましい点が多いです。非同期通信は減る方向の時代なんだなーという気持ちが高まって、↓のような記事も出しました。

zenn.dev

あとは、社内で「自分のチームのことは自分でやる」という機運が高まってきたのもあって、重い腰を上げてTerraformを使ったGCPの構成にもチャレンジしています。Memorystore for RedisをCloud Runに繋ぎ込んだり頑張ってるんじゃよ。

まとめ

サクッと書けるとか言ったの誰だよ!!!!!(2回目)

後半は疲れてきて明らかに解像度が下がってた気がするので、そのうち元気な時に何か追記するかもしれませんが、ひとまず今はこれが精一杯!

うーん、なんかこういろんなことをやってきたんだなあという感じですね。小並感です。

最近EMになったので、技術の比重がやや下がってくるような気もするし、そうでもないような気もする。これからの5年間もいろんなことをやっていきたいなあ。

それでは!