資格を取るための準備で必要だと思うこと

こんにちは。

私は昨年プログラマーとして転職しましたが、「とにかく知識や技術を身につけたい、対外的に何か形として見せられるものが欲しい」、という気持ちで入社してから以下のペースで資格を取得しました。

一般的に高難度と言われているレベルの試験は応用情報を除いて受けていないのですが、今思うと結構早いペースで取得したなーと思います。

そこで今日は、資格を取る上で私が共通して取り組んでいたことを紹介します。

資格取りたいけど勉強のモチベーションが湧かないなーと思っている方の参考になれば幸いです。

ざっくり難易度を知る

資格試験であれば、資格取得サイトや今まで合格した人のブログ等に、目安の勉強時間や何ヶ月で合格しました、といったことが書いてあることが多いです。

その資格を取得できるまでの目安時間を簡単に把握しましょう。

申し込む(⭐️超オススメ)

私が何よりオススメするのは、申し込んでしまうことです。

特に有効なのは通年で受験できる試験です。

資格勉強あるあるで、「受験代を損しないためにも、日々少しずつ勉強して、合格する力がついたら申し込んで合格したい」というのがあると思いますが、少なくとも私(+私の周りの多くの人)はこのスタンスをとると、勉強しません。

いつでもできるからこそ、いつまでもやらないということです。

したがって、受けようかなーと思ってだいたい難易度と目安勉強時間がわかったら申し込んでしまうのがオススメです。

Tips

試験は日曜の15時ごろがおすすめです。

暗記すれば取れるような分野は勉強の中でストックしておいて、土曜から日曜にかけて暗記してしまうのも一つの手です。

私調べですが、15時頃はちょうど頭が働く時間でもあるそうです。

身になる勉強を...などの考えを捨ててとにかく「合格」を目標にする

これも資格勉強あるあるですが、気づいたら問題演習ばかりで「資格合格のための勉強」になっていることがあると思います。

そういう勉強法は良くないと言われがちですが、私はそれは一旦置いておいて、まずは合格を目指せばいいと考えている派です。

途中で「これ本当に役立ってるのかな」とか考え始めるとモチベーションのダウンにつながりますし、逆に資格対策を離れて勉強すると「これで合格できるのかな」等余計なことを考えてしまうと思います。

資格対策に専念するというのは本当の意味でBESTではないのかもしれないですが、モチベーションの維持などを考慮すると、少なくとも悪いことではなく、多くの人はそれほど理想な勉強をできるとも思えないので、割り切って一心不乱に合格を取りにいくのが良いんじゃないかなあと思っています。

資格対策に特化した勉強をしても無意味なんてことは絶対にないですし!

合格したときのご褒美を決めておき、宣言する

私は資格勉強をする前に、合格した時の自分へのご褒美を決めて、宣言をしていました。例えば私の場合はキーボードを買う、などでした。

単純にご褒美を楽しみに頑張る、という効果もありますし、人に言ったからには合格しないと、という気持ちも働きます。

最後に

以上が大体私が行ったことでした。共通して言えるのは、「いかに勝手に自分が勉強する仕組みを作れるか」ということかなと思います。

資格勉強はやりたいけどなかなかそちらにパワーが向かない、、、という方の参考になれば幸いです。

『パーフェクトRuby on Rails【増補改訂版】』を今読んで良かった

ずっと気になっていたものの、量が多くて躊躇っていた『パーフェクト Ruby on Rails【増補改訂版】』を読みました。

gihyo.jp

読んだ感想

  • Railsチュートリアルの延長線くらいのものかと思ったら違った
  • 自分がもしこの本から初めてRailsを勉強していたら挫折してそう
  • 実務も少し経験した今読むと知らないこともたくさん知れてかなり面白かった

構成

この本は全体的に、つまみ食いできるような形で各章が別々の機能説明となっています。

Part1でRailsの基礎知識を学習し、Part2でRailsの周辺知識を学習します。この2つで276ページまで到達するので、かなり手厚く書いてあると思います。

そしてPart3やPart4ではPart1やPart2で使った知識を使いながらサンプルアプリを1つ作りながら学習していきます。

そして最後のPart5は発展的な内容として、サンプルアプリからは離れて、複雑なロジックの場合の対応方法について学習します。

各パートの感想と良かったところ

たくさんありますが、大まかに書くと以下です。

Part1, Part2

不勉強だった以下のような点についても書かれていたり、知らなかった多くの知識をインプットできました。

細かいところだと、scopeとクラスメソッドでクエリインターフェイスを定義する時の違いも知りませんでした。

(例えば find_by を使う場合、クラスメソッド内で使ってレコードがなかった場合はnilを返すが、scope内で使ってレコードがない場合だとScopeの検索条件を除外した結果を返す。)

それぞれサンプルコードで動かしてイメージできるようになっている点も理解しやすくて良かったです。

Part3, Part4

ここではイベント開催して、他ユーザーが参加表明などをできるアプリを作成します。

OAuthを利用してGitHubログイン機能を作るのは自分で実装したことがなかったので勉強になりました。

ただ、アプリ全体の機能については結構基礎的なものだったかなと思います。

Railsチュートリアルで作るアプリの方がその点では発展的な内容を含むかなと思います。

Part5

要すればより良い設計でRailsを書くことについて色々と紹介されている章です。

サービスオブジェクト、フォームオブジェクト、プレゼンターなど、実務で触ったことがある分野もありましたが、Concernや値オブジェクトなど、なんとなく存在は知っていてもどういうものか知らなかったところについても使う場面、使い方から解説されていてありがたかったです。

初学者の1冊目としては完走できるか怪しい?

上記のように発展的な内容もあり、別々の機能の解説がそれぞれの章でされているので、これからエンジニアを目指すような方が最初の入り口としてこの本を選ぶと頭がパンクする人も多そうな気がしました。

本書の対象読者にも以下のように書かれています。

・普段Ruby on Railsを使っていて、一歩先の「レール」に乗りたい人

Ruby on Railsの学習を始め、これから本格的に使っていきたい人

・他のMVCフレームワークを扱ったことがあり、これからRuby on Railsを始める人

 

出典:『パーフェクトRuby on Rails【増補改訂版】』| すがわらまさのり 前島真一 橋立友宏 後藤優一 五十嵐邦明

まさに、という感じです。少なくとも基礎知識を持っていることは前提にしてるようです。

さいごに

実務経験を少し積んで、割とRailsできるようになってきたかな?と思っていた矢先、まだまだ知らないことが大量にあることをこの本を読んで気づけて良かったです。

Railsチュートリアルとの差分もかなりあるので、もし未経験の方などでこの本をやるか考えている方がいるなら、個人的にはやはり最初はRailsチュートリアルを勉強し、理解が進んだらこの本を取り組むくらいがちょうど良いのかなと思いました。

『SOFT SKILLS(第2版)』を読んだので感想と始めたこと

こんにちは。

先日、伊藤淳一さんの以下の記事を見て、私も『SOFT SKILLS(第2版)』を読みました。

blog.jnito.com

今日はその感想と、読んで始めたことを書いていきます。

第1部:キャリア

言われてみれば間違い無いな、と思ったのが専門特化の必要性の章です。

なんとなく今まで、「あれも知ってる、これもある程度できる」という状態になりたいなーと考えていましたが、考え方が少し変わりました。

確かに色々できると求人の選択肢は増えますが、とある分野を突き詰めていると、その分野に関する求人があった場合に必要とされる確率が格段にUPするというのは間違いなさそうです。

もちろんこれからも色々な技術に触れていきたいですが、私はまずRuby, Railsエンジニアなので、そちらをきちんともう一度勉強しようと思いました。

ということでこの章を踏まえて、『Perfect Rails』を読んで学習中です。

gihyo.jp

その次は、一度読んであまり理解できなかった『メタプログラミングRuby』にリベンジしたいです。

www.oreilly.co.jp

第2部:セルフマーケティング

まさにこのブログはこのパートを読んで始めました。

ブログはやってみたいなという気持ちがありつつも踏み出せないでいたのですが、このパートを読んでいるとむしろやらねば!という気持ちになって始めることができました。

また、Fukuoka.rbに積極的に参加するようになったのもこの影響です。これからエンジニアとして生きていく上で、近い領域にいる方々と少しでも交流を持っておきたいと考えて始めることができました。

第3部:学習

このパートで、教えることが最高の学習方法になる、とありました。

ちょうど今の会社で、新入社員のメンターになっています。自分の技術力に自信がなく、あまり技術の話ができていなかったのですが、この本を読んで、自分が実務の中で勉強になったことなどを新入社員の方と話すようにしました

その中で疑問が出てくることもあって、調べて会話などをしているとより良く理解できることも実感しているので続けていこうと思います。

第4部:生産性

ここは実践できていることは少ないのですが、内容はとても共感できるものでした。

ポモドーロテクニックは今まで何度かやっているものの、気づいたらやらなくなってしまっています。効果は十分に感じているのですが、習慣化する前に忘れてしまうという感じなので、これからも忘れては思い出してやって、を繰り返していずれ習慣化できればという気持ちです。

他にも、このパートを読んで以下はやらないとと認識しましたが、なかなか誘惑を断ち切ったり、着手することが正直できていない領域です。

  • YouTubeを見ないようにする
  • 並行作業をしない(どうしてもSlackをこまめに返そうとしてしまうが、1時間おきとかでも良いと思う)
  • スケジューリング

第5部:資産形成

ここはこの本の感想で多く言われている通り、色々と感想が分かれそうですが、少なくとも私は資産形成に関する知識が少ないので、まずは書かれている通り知識を身に付けないと話にならないなと感じました。

今は会社員としてプログラミングしているのが楽しいですが、今後のことを考えても選択肢を増やす方法を取らない理由はないので、勉強しないといけないという気持ちです。

伊藤淳一さんがお金に関する本を読んだブログを上げていたので、その中から選んで読んでみようと思います。

blog.jnito.com

第6部:フィットネス

運動不足の私にとっては、読むのが辛い章でした。笑

20代というのでかまけているといずれ大後悔が待っていそうなので少しずつでも運動せねば、、という気持ちです。

とりあえずこの本を家で読むときは家の中で立って読んだりしてみました。

第7部:マインドセット

自分でコントロールできないことに振り回されるな、といった趣旨の話が出てくるのですが、私が大学生の頃に大流行したアドラー心理学をもとにして書かれている『嫌われる勇気』を思い出しました。

www.diamond.co.jp

当時も共感してずっと意識するようにしているのですが、それがまだ体に落とし込まれていないので、これからも意識し続けていきたいですね。

感想

この本をきっかけにいくつか始めることができたことや考えることができたこともあったのでとてもよかったです。

個人的には、こうすれば全てうまくいくよ、といった論調ではなく、ハードワークも人生の中で絶対にしないとダメだよ、などのパートもあり、現実主義な内容だったのが気に入りました。

「リーダブルなテストコードについて考えよう」を聞いたので明日からやること

こんにちは。

2022年7月27日、「リーダブルなテストコードについて考えよう」という勉強会に参加しました。

veriserve-event.connpass.com

非常に勉強になったので、今日はその感想として、明日から実践することを書いていきます。

リーダブルテストコード (株式会社ソニックガーデン 伊藤 淳一さん)を聞いて

↓発表で使用された資料

出典:https://speakerdeck.com/jnchito/number-vstat

speakerdeck.com

テストレビューが不足しすぎていた気づき

ようわからんならapproveしちゃダメです

ギクっとしました。

正直、機能ばかりのレビューに目がいって、テストはおおよそテストケースが網羅されているなと思ったら、ちょっとわかりづらいところもあっても、approveしてしまっていました。

変数を使って自己満足していた気づき

変数を使わずに文字列や数値をベタ書きする

これも「あっ」と思いました。

伊藤さんのageメソッドの例みたいに、変数を使って書いている自覚がありました。

こちらの方がなんだか格好良いじゃんと思って書いていたのですが、伊藤さんの改善版と比較すると分かりやすさが一目瞭然で、自己満足の書き方だったなあと思いました。

コンテキストとセマンティクスを意識してリーダブルなE2Eテストコードを書こう/オーティファイ株式会社 末村 拓也さん を聞いて

↓発表で使用されていた資料

出典:https://speakerdeck.com/tsuemura/kontekisutotosemanteikusuwoyi-shi-siteridaburunae2etesutokodowoshu-kou

speakerdeck.com

ユーザー目線でテストを書くことの副産物

ユーザーが要素を探すときと同じ方法で要素を探したい

これに関しては無意識的に今もできているので、今後これは意識的に継続しなければと思いました。

確かにidがxxxのボタンをクリック、みたいなテストがあったらソースコード見に行って、何のボタン押されたかを確認しなきゃいけないので不都合が多いですね。

アクセシビリティの高いテストはテスタビリティも高い

なるほど!という気持ちです。

確かに「このボタンをクリックして入力して・・・」というのがスムーズにテストができ、レビュワーがそれを直感的に理解できれば、実際の操作も単純明快で直感的になっている気がします。

今までにない視点だったので大変面白いと感じました。

テストコードにはテストの意図を込めよう/株式会社ビズリーチ 風間 裕也さん

↓発表で使用されていた資料

出典:https://speakerdeck.com/nihonbuson/tesutokodonihatesutofalseyi-tu-woip-meyou

speakerdeck.com

テストケース名は、「何をテストしたのか」に加えて「なぜテストしたか(意図)」を表現するべし

個人的に自動販売機の例が刺さりました。

私は「ここで何をテストしているのか書かなきゃ」という気持ちでテストケース名は書くものの、「なんでこのテストをしているのか」まで書ききれていないなーと気づきました。

面白いと思ったのは、これを書いておくことで将来修正が必要になった場合、どういう方針でテストすれば良いかまで明確になる、というのが新しい視点でした。(とある県が統合されたら、、、の部分)

質疑応答&パネルトークを聞いて

 伊藤さんが「テストをDRYでなくすると、テストが落ちやすくなる(仕様変更したらその都度テストが大量に落ちるなど)というのはあるが、それはデメリットというよりも仕様変更のインパクトがあるという考え方をした方が良く、仕様変更されればむしろテストはきちんと落ちた方が良い」という旨のことを話されていたのが印象深かったです。

私はついついテストが落ちるのを嫌がってしまうところがありますが、そもそものこういう考え方が大切だなと感じました。

 また、テストケース名をわかりやすく表現したい、といった参加者の質問に回答するな流れで、風間さんが「テストケース名を分かりやすく書くのが難しいと感じる場合は、テストしたいことが曖昧だったり、テストしたいことが複数ある場合が多い」とおっしゃっていたのもかなり印象深いです。

自分もRSpecでitの中身が書きづらいと感じた時などがあったら、そもそもテスト対象が十分にシンプルで明確かをチェックするように心がけたいです。

明日からやること

ということで明日からやることは、以下です。

  • ようわからんテストをapproveしない
  • 変数よりベタ打ちでテストする
  • systemテストのクリックなどはラベル名で探す
  • テストケース名にテストの意図を込める
  • テストケース名がうまく書けない時はテストの対象物が十分に明確でシンプルかを再考する

「神」な先輩プログラマーから学ぶ3つのコミュニケーションメソッド

こんにちは。

私は去年からプログラマーとして働いていますが、最初に入ったプロジェクトで「神」な先輩に出会いました。

技術的なレベルが非常に高いというのはもちろんですが、それ以外にもコミュニケーションが非常に取りやすくてとてもありがたいなーと思っていました。

今年新入社員も入ってきたので自分も良い先輩になるべく、「神」な先輩から学んだコミュニケーションのメソッドをここに記載をしておきます。

質問・相談のハードルを一気に下げる一言のメソッド

最初のプロジェクトに入ったとき、まず先輩に言われました。

どんな小さいことでも分からないことはなんでも早めに聞いてください!

そんな特別か?結構言ってる人多いのでは?と思った方もいるかもしれません。

一見、よくある「分からないことがあったら聞いてね」と同じに見えるかもしれませんが、決定的に違う点が2つほど隠れています。

1つは、「どんな小さいことでも」です。

初学者にとって、「こんな些細なこと聞いてしまっていいのか」は、質問を躊躇するあるあるだと思います。それを取っ払い、どんなことでも聞いていいよーと言われるのはとても心理的に大きいです。

2つ目は、「早めに」です。

これも初学者の質問する前あるあるで、「どこまで調べてから(時間を使ってから)質問すればいいのか」というのがあると思います。それも取っ払ってくれているのです。

困ったらまずアラートを出すべし、というのはビジネスマンとしてよく言われるもののなかなか難しい、というのがビジネスマンあるあるだと思いますが、まさにそれをさせてくれている言葉だなと思います。

テキストのトーンを明るくするメソッド

その先輩のテキストのメッセージは、基本的に絵文字か、!がついています。

何かを報告したときも、「了解」と来るか「了解!」と来るかでかなり印象が違うと思います。後者の方がかなり前向きな感じです。

特にリモートだと相手の顔色や状況がわからないので、こういったところで明るいトーンを保つことは非常に重要だなと思いました。

何かを相談した後の「他にはありますか?」のメソッド

相談するのは、相手の時間を奪うことでもあるので、こちらからするとどうしても申し訳ない気持ちも大きいのですが、その先輩は相談すると、最後に「それ以外で何か困っていることないですか?」と聞いてくれます。

これは、わざわざそれだけでリモートで打ち合わせをするほどではないものの、ちょっと気になっていることなどを話すきっかけとしてとても良いなと思いました。

最後に

他にも色々あるのですが、とりあえず3つ挙げました。

いずれもちょっとしたことのわりに効果が高い気がしているので、自分も真似していこうと思います。

基本情報を取らずに応用情報技術者試験に合格できたのでやったことと感想

こんにちは。

令和4年度春の試験で、応用情報技術者試験に合格できました。

私は基本情報を取らずに応用情報にチャレンジしました。

今回は合格できるまでにやったことと教材、感想を書いていきます。

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

やったこと

応用情報技術者試験選択式の午前試験と記述式の午後試験に分かれています。

午前試験対策

いろいろな受験ブログ等を見ると、毎年同じような問題が出ると言われていたので、参考書などで全体をインプットするのではなく、過去問を解きながら覚えるかたちを取りました。

過去問道場というサイトで過去5,6年分をランダムで出題するように設定し、演習をしました。

5,6年といっても結構な量があるので1周するのも大変でした。元々は2,3周する予定だったのですが、途中で疲れて1周とちょっとしかできませんでした。

ただ、1周だけでも同じ形式の問題がたくさん出たので、解けるようになっていく実感もありましたし、対策方法は間違ってなさそうだなとは感じながら学習できました。

合わせて、過去問を解きながら、分からない用語は辞書的に参考書を使って周辺知識など合わせて学習しました。

使った参考書は『令和04年【春期】【秋期】応用情報技術者 合格教本』です。

gihyo.jp

午後試験対策

当日までの対策

午後試験は記述式の問題です。こちらは知識というよりも長文読解の要素が強いです。

こちらも過去問を使って対策しました。使った書籍は『2022 応用情報技術者 午後問題の重点対策』です。

www.itec.co.jp

午後は解答する問題を選ぶことができます。

当日どれを選ぶかを決めようと、各セクション2つ程度、過去問題を解いてみました。

ただ、年によって、取れる問題もあれば取れない問題もあったので、当日まで明確には決まりませんでした。

結局当日の問題を見て判断することに

したがって、結局当日に問題を見て解けそうだなーと思った問題を選びました。

必須の情報セキュリティ以外に選んだのは以下です。

午後試験は時間の余裕がないというのは知っていたので、このやり方は不安もあったのですが、過去問を2つずつくらいやっていたおかげで、当日素早く判断できたと思います。

感想など

今までプログラマーに転職してから1年で、以下を取得していました。

これらに比べるとやはり応用情報は取得の難易度も高く、受験までに要した学習時間も大きいので、取得できたことはとても嬉しかったです。

一方で、一般的に突破が難しいと言われている午後試験に関してはシンプルな技術力というよりも技術がテーマの長文読解能力を測られていると感じました。

私は長文の読解にはあまり苦手意識がないので、その点は良い方向に転んでくれたのかなと思っています。

基本情報を取っていないことについても、少なくとも「応用情報に合格」という点においては、支障はなかったと思います。

 

さいごに、当日は長丁場の試験になるので、集中力とも勝負になります。特に午後は、過去問を1つ解くだけでも疲れるのですが、本番は5つ解く必要があるので、過去問演習はなるべく集中した状態でやる訓練をしておくと良いと思います。

『モダンJavaScriptの基本から始める React 実践の教科書』が自分のニーズをキレイに満たしてくれた

こんにちは。

先日Reactを使っているプロジェクトに参加することになり、Reactを触ったことがなかったので勉強することにしました。

ここで手に取ったのが『モダンJavaScriptの基本から始める React 実践の教科書』です。

www.sbcr.jp

結果的にこの本が自分が知りたいなーと思っていたことをキレイに満たしてくれたので、この本の感想を書いていきたいと思います。

読む前の私の状況

プログラマーとしての経験が浅い私は、以下のような状態でした。

  • プロジェクト経験は1件
  • そのプロジェクトではRailsJqueryを使っており、自分が担当していたのは主にRails側の機能追加などの実装
  • フロント側はあまり自信がなく、Reactも触ったことがない

プロジェクト内のコードを見てみたのですが、正直「どれがReactのコードなのか?」「なぜReactを使う必要があるのか?」といったところが分かりませんでした。

知りたいと思っていたこと

そこで、私が知りたいなーと思ったのは以下のようなことです。

  • Reactは何ができるのか、の基本
  • Reactの構文の基本

ReactはリッチなUIを作れる、というくらいは知っていたのですが、具体的な書き方などを知らなかったのでそれを知りたいと思っていました。

なんでこの本を手に取ったか

Reactの本は調べるといろいろあったのですが、なぜこの本を選んだかというと、以下のような理由です。

  • 出版年が私が調べた範囲では他の本に比べて新しい(2021年9月)
  • 内容が易しそうなこと(基本部分が書かれていればとりあえず良い)

「React全く分かりません」という状態をまず脱却したかったので、とりあえず基本が押さえられていそうという理由で選びました。またReactなどのライブラリは数年でも主流な書き方等が変わりそうだなと思ったので、出版年が最近なのも考慮しました。

早速しっくりきた

本書は以下のような指摘から始まります。

「Reactの習得に苦戦してる人のほとんどは、そもそもJavaScriptへの理解が足りていない。だからこの本ではモダンなJavaScriptの基礎からやる。」

これを見て、「これですよ!」と思いました。

先ほど書いた、「どれがReactのコードかよく分からない。Reactを使う必要がわからない。」というのも、逆に言えば「JavascriptJQueryの書き方をきちんと理解していない。JavaScriptやJQuetyで何ができるのかを理解していない。」ということだったんですね。

プロジェクトに入って、Reactやらなきゃ!と焦っていましたが、その前段階でやるべき勉強があったということです。

基本を着実に解説してくれる

この本では、JavaScriptの書き方からReactの書き方まで、基本を着実に記載してくれています。(内容は公式サイトに目次の紹介があります。)

サンプルコードについては丁寧に解説がありますし、サンプル通りに書けば基本的には全て動いたのでここは新しい本を選んだという点も良かったかなと思います。

(5章あたりにちょっとサンプルコードには書き切られていない点がある*1のですが、それまでの学習を理解していたらググったり自分で補足して動くようにできると思います。)

さいごに:読んだ後の今の気持ち

この本はReactの入門書としての位置付けだと思うのでReactはもっともっと深いのだろうと思いますが、今まで、

「React使う機能追加などのタスクが来たらどうしよう・・・」

という気持ちだったのが、

「Reactのタスクやってみたいな〜」

というくらいにまで変化しました。

気持ちが前向きになったのが何より良かったかなと思います。

 

ということで、Reactを触ったことがなくて、基本を短い時間で勉強したい!という方にはオススメです!

*1:TailWindCss.jsxのファイルの先頭にimport "tailwindcss/tailwind.css"を書かないといけない