勉強会「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を使ってみました。

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

AWSソリューションアーキテクト アソシエイト(SAA)に合格したので対策をまとめる

AWSソリューションアーキテクト アソシエイト(SAA)に合格できたので、勉強したことや感想を書いていきます。

受験を考えている方の参考になれば幸いです。

結果

結構ギリギリでした。

資格受験を決める前(約2ヶ月前)

この時の筆者のステータス

AWS実務経験:ほぼなし。(AWSを使っているプロジェクトに参加しているものの、AWSの設定をしたりするのは別のエンジニアが担当している。)

AWS保有資格:AWS クラウドラクティショナー

AWSに対する知識等:社内のAWS勉強会でECSやRDS等を使ったアプリケーションの構成について学習したことはある。クラウドラクティショナーをもっているのでAWSのサービス名とできることの概要は知っている。

Udemyで基礎を触りながら勉強した

この時点で、AWSを自分で使った経験が乏しかったので、AWSを使い方を知りたいな、と思っていました。

ただ、AWSは従量課金制なので、変に触って高額な請求とか来たら嫌だな〜と思ってなかなか手をつけれてなかったところ、Udemyで以下の講座がセールしていたのでここでやってみることにしました。

www.udemy.com

この講座でVPC、Route53、EC2、S3などなど、、、AWSのメジャーな機能をひととおりハンズオン形式で触ることができました。

資格受験を決めた後(約1ヶ月前)

今から約1ヶ月前に、資格受験を決めました。いつも通り、「勉強前に資格スケジュールを組んでしまう」スタイル*1です。

その後、以下の教材で勉強しました。

1. Udemy(セール時に購入)(1ヶ月前〜)

www.udemy.com

簡単な特徴や感想

  • 試験範囲のサービスと抑えるべきポイントをハンズオンつきで学べる
  • 講座の最後についている模擬試験は本番に比べてかなり高難度な印象

後から「あれ?このサービスってなんだっけ?」となった時にも辞書的に使えて便利でした。

2. 問題集(書籍)(10日前〜)

www.amazon.co.jp

簡単な特徴や感想

  • たくさん演習ができるのでとても良かった
  • 最後についている模擬試験は本番と同じようなレベルな印象

1周やってみて、間違えた問題は2周しました。

3. 問題集(Udemy)(2日前)

www.udemy.com

簡単な特徴と感想

  • この模擬試験は本番より難易度が高く感じた
  • 高難易度の試験はやっていない(レビューを見て、試験対策としてはやらなくてもよさそうに感じたので。)
  • 本番でも同じような形式が数問出たので助かった

なんとなく1,2の対策だけで不安になったのでUdemyでも問題集を買ってやってみました。

2日前にこれをやって、5-6割くらいしか取れなかったので絶望しましたが、2周目をやる時間もなかったので、間違えた問題を中心に見直しました。

結果的にはこの演習と同じような形式の問題や、考え方が同じ問題がいくつか本番で出題されたので、本当にやって良かったです。

手応えと感想

この試験は終わってすぐ合否がわからず、数時間後にスコアレポートの形で合否が判明します。

試験直後は、50:50くらいかな〜という印象でした。その分、合格を知ったときはめちゃくちゃ嬉しかったです。

これで資格試験も6回目になりますが、毎回試験前不安でドキドキするのが辛いですね、、笑

参考:過去の資格対策の記事

質問に答えられるって嬉しい

今回はただの日記です。

 

プログラマーになって1年以上が経ちますが、わからないことだらけ、教えてもらってばかりの毎日です。

そんな中で、この前、個人宛ではない、汎用性のある技術的な質問に答えることができたので良い日になりました。

「個人宛ではない、汎用性のある技術的な質問」

ここでいう「個人宛ではない」というのは私一人宛ではなく、チャンネルのメンバー全員に広く聞いているもの、ということを指しています。

また、「汎用的」というのは、「そのプロジェクト(案件)固有ではない」ということです。

今までも、例えば「このメソッドってどこで使っているの?」とか「このバグの原因がわからない、、、」という同僚からの質問に対して答えていたことはありました。

ただ、それらは「そのソースの固有事情に対する」解決法でした。

そういう質問に回答するのって勇気がいる

明確に自分が指定されているレビュー依頼や質問で会話するのと違って、こういった(グループ宛に投稿された)質問は「わかる人が答える」という状況になります。

今までも社内の質問チャンネルなどで、「答えられそうかも」みたいな機会はありましたが、「私よりよほど優秀なエンジニアがいるし、、、」「意気揚々と答えて間違っていたらカッコ悪いな、、、」みたいな気持ちでなかなか手が止まってしまうことが多かったです。

答えられた!

今回はRSpecに関する質問がチャンネルに投稿されました。

内容は、「通らないテストがあるが、通らない理由がわからない」というものでした。

貼られているコードを見て、ちょっと心当たりがあったので少し検証して、「これでどうですか?」と改修版のコードを説明して、動かない理由を説明してみました。

(この辺りの具体的な技術の話はQiitaに載せたいです。)

すると、無事解決できたみたいでした。

自分の成長も感じて、嬉しい気持ち

回答にあたって使った知識は、プロジェクトのメンバーが以前Slackで会話しているのを偶然読んでいて、「へー」と思ったことに由来します。

たった1問の質問を答えただけなんですが、技術的な課題に対して、得た知識とテクニックを使い、共有できたこと、今まで身をひいていたところで前に出れたことは、少しだけ成長を感じて充実した気持ちになったという話でした。

(案ずるより産むが易し)自作gemとCircleCIデビューしたら簡単だった

先日、会社の同僚が社内LTで「gemを作ってみたけど簡単だった」と言っていたので、なんだか難しそうと思って敬遠してしまっていたgem作成(ついでにCircleCI導入)をしてみました。

結論から言えば、すごく簡単でした。

gemを作ってみた

gemの作り方は以下の記事がとてもわかりやすかったので、ここでは繰り返しで手順を記載することは避けます。

qiita.com

作ったgemについて

今回は目標が「gemを作ること」だったので、内容は本当に簡単なものです。

私はプロ野球が大好きで、指標を眺めたりするのも好きなので、野球に関する指標を計算してくれるgemにしました。(といってもOPSという指標のみ)

rubygems.org

RubyGemsでの公開も簡単にできました。どれだけ簡単でも、公開されると達成感がありますね。

ちょっと変なことを言うようですが、公開されたという事実よりも、検索フォームで「baseball」と打つとサジェストで「baseball_stats(←私の作ったgemの名前)」と出るのが嬉しかったです。

なんだか認められた感というか、、、

Circle CIを使ってみた

ついでに、業務で使っているものの、設定などしたことがないCircleCIも使ってみました。

circleci.com

CircleCIでこのgemのRSpecを自動化してみました。

公式ドキュメントや記事を見ながら設定ファイルを書いてみましたが、「push時にRSpecのテストを走らせる」というところは達成できました。

最後に

単にQiitaの記事をなぞったりCircleCIの初歩の初歩を試して満足しているだけですが、今までgemやCIツールとの間にあった距離が縮まったのが嬉しかったのでブログに書きました。

「やってみる」って大事だなあと再認識した経験でした。

『情熱プログラマー』を読んで印象的だったことをつらつらと

はじめに

同僚に勧められた、『情熱プログラマー』を読んだので心に残ったことをつらつらと書いていこうと思います。

shop.ohmsha.co.jp

1番の下手くそでいよう

「自分が一番下手くそ」な環境に身を置くことで、周りに引っ張られるように成長できるという話でした。

私が今参加している地域のRubyコミュニティは、周りのレベルが高く自信を失いかけることもありますが、自分が一番下手くそであることに対する恐怖心を捨てて前向きに参加を続けていこうと思えました。

ビジネスを知る

利益を上げる等して会社に貢献することが仕事である以上、エンジニアであってもビジネスの仕組みについて理解することは当然必要である、という話です。

これを見て、ドキッとしました。

今参加しているプロジェクトが準委任契約で入っていることもあり、コーディングに気を取られるあまり、ビジネスへの理解を蔑ろにしてしまっていたことがあるなと思うのでこれをおろそかにしてはいけないですね、、、

アドベンチャーツアーガイド

マネージャーや顧客は往々にして自分が理解できない単語を話し、頭も切れるエンジニアを怖がっているため、安心感を与えることが必要という内容です。

とても共感できる内容として印象に残っています。

自分は元々非エンジニアとして仕事をしていたのもあり、エンジニアを「怖がる」という経験をしたことがあります。

わかる言葉で、顧客の行きたい場所に連れていく、本書でいうツアーガイドのようになりたいと改めて思いました。

ウォーターフォール式のキャリア開発はやめよう

ウォーターフォール式にキャリアを定め、それを目標にして変更することなく突き進むのではなく、自分がやりたいことや社会の需要に合わせてキャリア変更を行っていこうという内容です。

重要だなと思ったのは、「キャリアチェンジに対して柔軟でいること」という点であり、無計画で良い、という点ではないことです。

実際にこの前の章では「自分のロードマップを作る」という章で自分の成長の仕方を考える重要性が書かれています。

最後に

分厚い本でもないのでスラスラ読めますし、自分のキャリアを考える上で色々なヒントが書かれていたと感じます。