(積読解消)3月に読んだ本と感想

3月に読んだ本の感想を簡単にまとめていきます。

メタプログラミングRuby(リベンジ)

www.oreilly.co.jp

 1年半ほど前に読んでみたのですが、当時の私には難しく挫折しました。

今回は、以下の点に気をつけて読みました。

  • どれだけ理解に時間がかかっても、わからないまま次に進まない。
  • なるべく手元で動かしながらゆっくり進める

 その結果、無事理解をしながら最後まで読み切ることができました。

正直、メタプログラミングできるか、と言われると怪しいですが、コードを読む上での心理的ハードルはかなり下がったのかなと思います。

個人的には、10章のActiveSupport::Concernが一番難しかったですが、なんとか読み切ることができました。

リーダブルコード

www.oreilly.co.jp

 言わずと知れた名著だと思いますが、これもきちんとすべて読んでなかったので読みました。

  • 変数の寿命を意識すること
  • 明確な命名をすること
  • タスクを分割すること

など、基本的かつ重要な考え方を総復習できました。

 10章の「プロジェクト固有のコードから汎用コードを分離する」というのは意識として足りてなかった気がするので、今後意識していこうと思います。

プログラムはなぜ動くのか

bookplus.nikkei.com

 2年弱前に買って積読になっていた本をようやく読みました。

 プログラムが動く仕組みを、メモリ・レジスタという部分から解説をしてくれます。この辺りの知識を体系的に学べていなかったので、とても勉強になりました。

 この本では、何度か「プログラムが動く仕組みをきちんと理解していないような、高水準言語の書き方しかわからないプログラマではいけない」という趣旨の記述があり、そうだよなあと胸に刺さりながら読んでいました。

Flutterハッカソンで3位入賞できました

先日、Flutterのハッカソンに参加しました。

flutterlabo.tech

結果としては、会社のメンバーと力を合わせて3位入賞することができました!

参加したきっかけ

 参加したきっかけは、会社の同僚がハッカソンを見つけて誘ってくれたことでした。

 Flutterについては、一度チュートリアルをやったことがあり、ちゃんとアプリを使ってみたいなーという気持ちはありつつ、なんだかんだできていなかったので、Flutterを学ぶいい機会だと思い、参加しました。

ハッカソンの1週間で作ったアプリ

 今回のハッカソンのテーマは「アナログなイベントをデジタル化する」でした。テーマ発表から、開発したアプリの発表&コード提出までの期間は1週間でした。

 私たちのチームがつくったアプリは「Talk to me(仮)」です。

 エンジニアは、紙の名刺以上にTwitterなどでつながることが多い職種な気がします。エンジニアがリアルのイベントで会った際の名刺交換に代わるサービスと位置付けて以下のようなアプリを作りました。

↓ 作ったアプリ(発表資料の一部を修正して抜粋)

私が担当した機能

 上記の中で、私は主に以下の機能を担当しました

  • アプリでQRコードリーダを立ち上げる機能
  • QRコードリーダーで読み取った内容をFirestoreに履歴として保存する機能
  • QRコードリーダーで読みとったデータに対するメモ機能
  • アカウント編集機能

 そのほか、画面スワイプでメニュー間を移動する機能など、モバイルアプリらしい部分も作ってみました。

部品を組み合わせる感じでできるので簡単で楽しい

 Flutterの見た目の部分は、Widgetと呼ばれる部品を組み立てて作るイメージで、割と思い通りに作れる感じで楽しかったです。

 スワイプでページ間を移動するなど、モバイルアプリっぽさを実装するのも用意されたWidgetを組み合わせて使えばすぐできるのも便利な点でした。

難しかった点

 リアルタイムでデータを取ってくるのが意外と大変でした。

 例えば、アカウント編集後に更新を押してアカウント表示画面に戻っても、「Firestoreのデータは更新されているが画面の情報が変わっていない」ことが起きました。

 画面で表示するデータの持ち方によっては、都度Firestoreからデータを持ってくるのではなく、以前の情報を使いまわしているため起きていたのですが、RailsアプリだとViewの表示ごとにControllerでデータを取得するのであまり見かけない現象だと思うので、最初は解決策がよくわかりませんでした。(最終的にはStreamBuilderというものを使って解決しました。)

課題はリファクタリング

 また、きれいにコードが書けたかと言われると否です。

  • Viewにロジックがたくさん書かれている
  • 同じコードが繰り返し出てくる
  • データを取得するだけなのに大袈裟なコードになっている(気がする)

 コードが汚いことを自覚しつつも、Dartへの理解が浅くてリファクタリングができないのは悔しい点でもありました。

さいごに

 ハッカソンなるものに初めて参加しましたが、アイデア出しから実装までできてよかったです。

 また、実装の時間は仕事終わりにとっていたのですが、チーム開発でやっていると他のメンバーの頑張りが刺激になってついつい夜遅くまで実装をしていました。大学生のころの試験期間のような気持ちになって、とても楽しかったです。

 まだアプリとしての完成度は低いので、細々とFlutterの開発を続けてリリースまでやりたいなあという気持ちです。

福岡Rubyist会議03でRubyカンファレンスデビューをしました

昨日(2023年2月18日(土))、福岡Rubyist会議03にヘルパーとして参加しました。

今回の福岡Rubyist会議03が初めてのRubyカンファレンス参加でした。

regional.rubykaigi.org

今日はその感想を書いていきたいと思います。

福岡Rubyist会議03で自分の中で達成しようと思っていたこと

Fukuoka.rbでお世話になっている方に会って挨拶がしたい!

 普段Fukuoka.rbに参加していますが、基本オンライン開催なので直接会ったことがない方ばかりでした。その方々に会って挨拶をしたいなというのが1つの目標でした。

 結果としては、大倉さん、しおいさん、岡嵜さん、はしもとさん、オブさん、ideさん、、、たくさんの方に挨拶ができたので達成です!

 本当に挨拶だけになってしまったところもありましたが、「自分から話しかけて、挨拶をする」をできただけでもヨシとします。

勉強会などで話を聞いて感銘を受けた方に会って挨拶したい!

 以前ブログにも書いた*1、「ActiveDecoratorを読む」の勉強会で話をされていた松田さんや、「RubyKaigiスポンサーの裏話」でお話しされていた荻野さんが、来られると知ったので、ぜひ挨拶だけでもしたいなと思っていました。

 結果としては、それぞれいらっしゃったタイミングで、勉強会を聞いてとても良い体験ができたことを伝えることができました。お二人ともすごく優しく話してくださって、ありがたかったです。

レベルと熱量の高さに圧倒され、客観的な自分の位置を痛感

 会議中も、会議後の飲み会でも、皆さんの技術的レベルと熱量の高さに終始圧倒されていました。正直、登壇された方の発表内容も分からないことも多く、自分はいつかこの人たちと本当の意味で楽しく会話し、議論を交わすことができるようになるのか??と不安になるレベルでした。

 ただ、こういう気持ちも参加しないと得られなったわけで、いずれにせよ自分ができるのは地道に努力し続けることだけなので、圧倒された気持ちをプラスのエネルギーとして引き続きやっていこうと思いました。

ヘルパーとして参加してよかったこと

 今回は手を挙げて、ヘルパーとして参加しました。

regional.rubykaigi.org

 ヘルパーとして参加したことで、当日の一連の流れ、気にすることを一通り見れたのは勉強になりました。スタッフパーカーももらえてホクホクです。

 また、同じくヘルパーで参加した方とランチに行ったり、飲み会で話したりして、受託開発、準委任開発の話やプログラマーのキャリアの話をできたのも貴重な機会でした。

クロージングトークを踏まえて

 今回の会議の感想を書く上で、どうしても外せないのはクロージングトークかなと思います。そのくらい甚六さんのクロージングトークは心に残りました。

受けた恩がたくさんあることに気づく

 クロージングトークでは、自分がこの場にいるのも色々と恩をもらっているからだなーと思いながら聞いていました。

  • 甚六さんきっかけでFukuoka.rbに参加したこと
  • Fukuoka.rbでRubyコミュニティ参加への後押しをしてもらったこと
  • 勉強会でRubyistの熱量を受けられたこと

アウトプットで恩送り

 これらの受けた恩を「恩送り」するため、クロージングトークで出てきた言葉を借りれば、「できることを続け」て、「アウトプット」を続けていきたいです。それが恩返しにもなるんだろうと思います。

まとめ

 もし参加前の私のように、「自分の技術レベルで参加して良いものか、、」と思っている方がいれば、参加を勧めます!

  • 話は理解できなくてもそれはそれで良い(と思っています。むしろ理解できない話を聞きに行く場なのかもしれない。)
  • Rubyistの熱量に当てられる経験自体が貴重
  • 本を書いたり、色々なところで名前を聞く人たちも同じ人(当たり前ですが)と実感して勝手に距離が縮まる

 これは私の勝手な感想ですが、Rubyistの皆さんの多くは、カンファレンスで発表される内容というより、その場そのものを楽しみに来ているんだろうなーと感じました。

 今回は初めての参加で色々と緊張し続けていて、終盤飲み会で力尽きてた感じはありましたが、今度はさらに楽しく参加できそうな気がしています。

 まずは恩送りとして、このブログを通してRubyコミュニティに少しでも貢献できれば幸いです。

Sendai.rbに参加した話(「いもす法」を知った)

先日、Sendai.rbに初参加しました。

sendairb.connpass.com

参加した理由

Rubyコミュニティの居心地の良さを知った

普段参加しているFukuoka.rbの雰囲気がとても居心地良いなあと思っていることや、別でブログにも書いた勉強会*1の経験から、Rubyコミュニティっていいなあと思うことが多く、他の地域Rubyコミュニティにも参加したくなりました。

テーマが楽しそうだった

もう1つの理由として、競技プログラミング回というテーマに惹かれました。

最近少し競技プログラミングの練習問題?を解くことがあって、例えば配列の処理など勉強と実践練習になるなーと、興味が湧いていたのでちょうどよかったです。

モブプロ形式でとてもよかった

3問モブプロ形式で解きました。

2問目:つるかめ算

1問目がすごく簡単で、「こういうレベルを3つやる感じなのかな?」と思っていたら、2問目が結構骨のある問題でした。(つるかめ算

正直パッと回答イメージが浮かびませんでした。なので、司会者の方と一緒に考えながら、それをコードに落としていく作業は面白かったです。

計算の結果をfloorを使って整数になっているかどうかを判断する方法は思わず「なるほどー!」と言ってしまいました。

3問目:いもす法

3問目は、実行時間を気にしないといけない問題でした。

2問目とは違い、問題を見た時に「こうやれば答えは出せそうだなー」というイメージはついたのですが、実行時間的に不可の方法でした。

「いもす法」というアルゴリズムを使うのが正解で、そもそもこのアルゴリズムの存在を知らなかったですし、計算方法が非常に面白かったです。

さいごに

ふと思い立って参加しましたが、とても勉強になる&競技プログラミングに興味が湧いた内容でした。

勉強会「ActiveDecoratorを読む」が最高だった

2023年1月27日、「ActiveDecoratorを読む」の勉強会に参加しました。

rubygems-code-reading.connpass.com

結果、最高だったので感想を書いていきます。

Gem製作者本人からお話が聞けた

今回の題材はタイトル通りactive_decoratorだったわけですが、なんと製作者の松田明さんから直接お話を聞くことができました。

そもそもなぜこのgemを作ったか(ActionViewHelperの手触り感がちょっと、、、の話)という製作者がスピーカーだからこその話から聞けたのは貴重でした。

Rubyパワー全開のgem

勉強会では、主にinitial implementationのコミットの内容を見ながらソースコードの意味(真意)を解説いただきました。

例えば、

  • RailsSQLを発行するタイミングとdecoratorを仕込むタイミングの話
  • Controllerで定義したインスタンス変数がViewで使える肝となっているview_assignsを利用したdecotateの話

など、active_decoratorがいかにRailsの仕組みの根本に根付いたgemかということも知ることができました。

「便利」と「あるべきかたち」の話

 そのほか、個人的にとても興味深かったのは、初期のバージョンでは、

DHHの思想に基づき、関連づけで何階層かになっているインスタンスでも、controllerからviewに渡る時点でdecorateするのは最上位のもののみにしていたという話でした。

View側では1つのパーシャルに複数のモデルの情報を描画するべきではない(例: book.titleとbook.author.nameは1つのパーシャル内で書かれるべきではない)という思想で、パーシャルのlocalsで渡すタイミングでそのインスタンスにもdecorateをするという仕組みになっていたことは「どうあるべきか」が徹底されていて感動しました。

 まとめて関連インスタンスもdecorateするという仕様にするとき、本当はあまりやるたくなかった、というお話をされていたのもめちゃくちゃかっこいいなと思いました。

active_decoratorが好きになった

 gemを作られた方から直接コードの真意、背景をお聞きしつつ、Rubyパワー全開のgemであることを知れて、active_decoratorがすごく好きになりました。

 業務で使っていますが、何だか今後ちょっと使うだけでもこの勉強会の話を思い出して楽しい気持ちになれそうです。

OSSの活動に関する他の知見も得られた

勉強会のお話から、いろいろとOSSに関する知見を得ることができました。

  • (仮に便利だから、ということで機能追加のPRが届いたとしても)自分がメンテできるかどうかを考えてからマージする必要があること
  • 読むと面白いgem(逆のgem)の話

この辺りも聞けて満足でした。

decoratorに関する質問できたのでとにかく最高

さらに、勉強会の最後に、思い切って(gemのソースコードに関連する話ではなかったんですが、)decorater関係で考えていたことを質問もできて、とにかくお腹いっぱい最高でした。

『スッキリわかるSQL入門 第3版』を読んで、本を読む意味が1つ増えた気がした

先日、『スッキリわかるSQL入門 第3版 ドリル256問付き!』を読みました。

book.impress.co.jp

今回は書籍の内容はほどほどに、読み終えてふと思ったことをブログにしました。

目標はSQLに対する苦手意識の払拭

 この本を手に取った理由は、生のSQL文に対する苦手意識を払拭したい気持ちがあったからです。以前、結構複雑なSQL文を書く機会があったのですが、先輩にたくさん迷惑をかけてしまい、その時に「勉強しないとな」と思ったのがきっかけです。

SQLを演習形式で学習できる

 タイトルに「ドリル256問」とあるように、この本では演習を通じてSQLを勉強できます。演習の環境はdocoQLというサービスを使えるので、演習ごとに自分でテーブルを作ったりする必要もありません。

dokoql.jp

本を読むと「分からなくて恥ずかしい」から脱却できる、かも

 このような本を一通り読むと、少なくともその技術について入門編は一通り勉強したことになります。

 SQLの知識等が実際に身につくことはもちろんですが、私は意外とこの「入門編は一通り勉強したぞ」という自信が効用として大きいと思いました。

 今までは、SQLについて分からないことがあったら、そもそもSQLに対して自信がないので、「こんなこと聞いて良いのかな」「今から聞こうとしていることは実はすごくレベルが低い話なのでは」という気持ちになりがちでした。

 ただ、入門編を一度やると、自分の中で一手程度の「できること」のラインを引くことができるので、「できないこと」に対しても変なプライドなく、素直に受け止めて取り組むことができるようになる気がします。

おわりに

 資格を取ったりするのも、よく言われる、対外的な証明以外にも「自分はこれだけ勉強してこの技術を使うための基礎知識を理解しているんだ」という自信をつけられるという効果がかなり大切な気がするなあとふと思いました。

『Web API The Good Parts』の感想

『Web API The Good Parts』を読んだので感想等を書きます。

www.oreilly.co.jp

読んだきっかけ

Web APIについては少しだけ使ったことはありますが、自分で設計したことがなく周辺知識も疎かったので勉強したいと思っていました。

どこかで本書が勧められているのを見て、購入しました。

どんな本か?

Web APIに関して、設計のあり方から設計する上で気をつけることなどが書かれています。

例えばURLの構成であったり、セキュリティ上で気にすること(レスポンスの返し方など)が網羅的に紹介されています。

本書ではAPI設計の原則を「デファクトスタンダードに従う」としている通り、YouTubeTwitter等々のAPIの設計を紹介しながらより良い設計について議論が展開されるため、具体例とともに理解することができるのは良かったと思います。

印象に残ったこと

以下、なるほどーと思ったことを少しだけ例に書きます。

3.3 データの内部構造の考え方

ユーザーがやりたいことに対して、なるべく少ないアクセスになる設計を心がけましょうという話でした。つまり、APIをデータごとに細かく切り分けてしまうと、ユーザーがやりたいことをやるために多数のアクセスが発生してしまいます。そのようなAPIを使いこなすにはユーザーにとっても煩雑になってしまうので、ある程度まとまったパッケージで作成する必要がありそうです。

重複を避けようとすると細かく区切りたくなりそうですが、Web APIについてはそういった観点を徹底しすぎると逆効果になるんだなーと納得でした。

5章 設計変更をしやすいWeb APIを作る

5章全体にわたって、一度公開したAPIの変更の方法等について紹介されています。

特に外部に公開しているAPIの場合、まずは「変更しないこと」が最も良い方法と述べられています。

その上で変更しなければいけないときは、

  • バージョンをどこに示すか(URLに含めるのが一般的)
  • バージョン番号の付け方(メジャーバージョンごとが一般的)
  • 終了を見越した利用規約等の記載
  • バージョン切り替えのフロー

など考慮することが紹介されています。

特に公開時に終了するときを見越して利用規約等でサポート期限を明記しておくといった方法(※本書の中で必ずしも推奨されているわけではないです)は、自分がもしこの本を読まずにAPIを公開するときには完全に考慮から漏れそうなので、あらかじめこの本で頭に入れられてよかったです。

さいごに

この本を読んで、Web APIに触れてみたく、YouTubeAPIを使ってみました。

また別のブログに書きたいと思います。