すずかのプログラミング勉強記

元教員からエンジニアを目指す、プログラミング勉強記録です。

未経験からフィヨルドブートキャンプを卒業して、エンジニアになりました!

はじめに

6月半ばに自作サービスのリリースをもって、フィヨルドブートキャンプ(以下FBC)を卒業しました。
加えて並行して行なっていた就職活動で、第一志望の企業より内定をいただくことができ、7/1よりWebエンジニアとして働きはじめました。

この記事では、FBCでの生活や就職活動の振り返りを書きます。
FBCに入会を検討している方、現在学習中の方に読んでいただけると嬉しいです。

自己紹介

すずかと申します。

前職では高校の国語の教員をしていましたが、2023年3月に退職しました。その後、FBCで1年2ヶ月間勉強し、先日最後のカリキュラムを終えて卒業しました。

フィヨルドブートキャンプとは?

「現場の即戦力となれる」オンラインのプログラミングスクールです。
詳しくは公式サイトをご覧ください。 bootcamp.fjord.jp

入会まで

入会時の状況

新卒から5年間働いた、高校教員を退職した直後でした。

退職理由は、月45~100時間程度の残業があり、健康に働き続けることが難しいと思ったからです。 教員の仕事自体は好きだったので、次に何を目指せばいいのか分からずに悩んでいました。

FBCに入った理由

前職では情報管理部という部署に所属しており、学校業務支援システムの管理や、生徒用タブレットの選定などの仕事をしていました。そのため、学校のデジタル化やICT教育の分野に強い関心を持っていました。

加えて、夫がWebエンジニアとして楽しそうに働いていたことから、プログラミングに興味がありました。
退職後に何をしようか考える中で、夫からFBCを強くすすめられ、入会しました。

プログラミング歴

大学は文系学部出身、IT関係の企業に勤めた経験もなく、プログラミングの知識はほぼゼロでした。

以下のような知識レベルです:

  • ターミナルを立ち上げたことがない。
  • GitHub」や「Linux」の存在はもちろん知らない。
  • Ruby」と「Rails」の違いがわからない。
  • Macの使い方すらよくわからない。
  • 独学でVBAを勉強して、挫折した経験がある。
  • ProgateでHTML・CSSをちょっとやった。

卒業までにかかった期間

期間は約1年2ヶ月で、学習時間は2636時間でした。(最後の方は就活と並行していたので、色が薄いです)

他の卒業生と比べると、期間は平均的、学習時間は長めかなと思います。

ちなみにこの期間の生活費は、夫婦共通のものは夫が多めに払ってくれて、不足分や私個人の出費(FBCの受講料など)は教員時代の貯金を使いました。
税金や保険の手続きなどで後悔したことも多いので、無職期間の家計管理について気になる方はお声がけください😅

カリキュラムについて

FBCのカリキュラムはざっくり分けると、基礎的なインプット期間→チーム開発→自作サービスに分かれています。
以下に、インプットのカリキュラムの中で特に印象に残ったものを挙げます。

より詳しいカリキュラムについては、こちらからご確認ください。
学習内容 | FJORD BOOT CAMP(フィヨルドブートキャンプ)

Linux

入学して最初の関門でした。
Linuxの本を読んで基本的なコマンドについて勉強した後、VPSサービスで用意したサーバーにLinuxをインストールして、SSH接続を行います。黒い画面で見慣れない英語がたくさん出てきて、仰天した記憶があります。

Ruby

Rubyに関する書籍を二冊を読んだ後、ボウリングのスコア計算プログラムやlsコマンドなどを作り、レビューをもらいます。
大変だったのは「lsコマンドに-lオプションを実装する」課題で、ぐしゃぐしゃになってしまったコードをどうしていいかわからず、泣く泣くそのまま提出しました。(レビューしてもらって綺麗になりました)

データベース

DBやSQLについて、それぞれ書籍で勉強した後、例題の設計を考えてER図を提出します。 この時点でRailsに触れていないため、何に使うのかよくわからないのが辛くて、日報に愚痴を長文で書いたりしました😅(のちに重要性がわかりました。)

Sinatra

Railsで開発する前に、よりシンプルなフレームワークSinatraを使い、Web開発の基礎を学びます。
Sinatraの情報が少なく調べるのが難しかったですが、生まれて初めてメモアプリを作った時は感動しました。

Rails

書籍でRailsの基礎を勉強した後、簡単なアプリケーションに機能を追加していきます。
Sinatraで大変だったデータベースを扱う処理が、一瞬で実装できることに感動しました。また、Railsにたどり着けた嬉しさから、このプラクティスは楽しかった印象があります。

JavaScript

基礎的な文法をインプットした後に、いくつかのプログラムを作ってレビューをしてもらいます。
「非同期処理」の課題が特に難しく、思ったような順番で動いてくれずに苦戦しました。
また、「npmパッケージの作成」の課題では、自分で作りたいものを考えて、パッケージサイトにリリースします。 私は学校を検索できるコマンドラインツールを作りました。
自作のnpmパッケージを公開しました - すずかのプログラミング勉強記

React

公式ドキュメントを読んでインプットした後、Create React Appを使ってSPAのメモアプリを作ります。
この「公式ドキュメントを読む」のが分量が多く、心が折れそうになりました。先に進んでいる受講生・卒業生の方々にアドバイスをいただき、どうにか乗り越えました。

チーム開発について

FBCの学習に使っている「ブートキャンプ」というWebアプリに、新機能の追加やバグの修正などを行います。

初めは不安でしたが、簡単なIssueからスモールステップで割り振ってもらえるので、すぐに慣れました。仲間と一つのアプリケーションを作るのは非常にやりがいがあり、FBCのカリキュラムの中で一番楽しかったです。

チーム開発については、こちらの記事に詳しく書きました。
フィヨルドブートキャンプでプログラミングの勉強をする【11ヶ月目】 - すずかのプログラミング勉強記

自作サービスについて

開発期間は3ヶ月ほどで、山手線を徒歩で一周する人のための記録アプリ「YamaNotes」を作りました。

詳しくはこちらをご覧ください。
山手線を徒歩で一周する人のための記録アプリ「YamaNotes」をリリースしました - すずかのプログラミング勉強記

楽しかったこと

ブートキャンプの開発に関われた

チーム開発で、実際に使われているWebアプリの開発に関われたのが楽しかったです。
ここでは、メンターさんからIssueが割り振られるだけでなく、自分で新機能の提案をすることもできます。私は「日報提出のお祝いメッセージを何回も出す」というIssueを作り、自分で開発を担当しました。実装後は、受講生の皆さんからSNSで感想をもらうことができました。

ブログやLTでアウトプットできた

卒業までに、ブログに29本の記事を書きました。はじめは正直誰も読んでくれないと思っていましたが、想像以上に多くの方に読んでもらうことができ、勉強を続けるモチベーションになりました。
加えて、FBC内のLT会などで4回登壇する機会があり、あたたかいフィードバックをいただきました。考えていることを言語化する練習になったのはもちろん、自分の発表が誰かの役に立つかもしれないと考えると、自己肯定感が上がりました。

仲間ができた

FBC内のイベントを通して、受講生の方やメンターさんとのつながりができました。Discordで輪読会や雑談をしたり、Rubyコミュニティのオフラインイベントに一緒に参加したりするのが楽しかったです。
特に、就職活動中はメンタルが不安定で、皆さんに非常に支えられました。最終面接の10分後には、Discordで皆さんとお話ししていたぐらいです😊

大変だったこと

学習内容が難しかった

FBCのカリキュラムの中で、「何かの記事の内容をそのままやったらできた」という課題は一つもありませんでした。自分で資料を読んで、必要な情報を集め、手を動かしてエラーと立ち向かわなくてはいけません。
学習が進むにつれ、わからないことにも慣れていきましたが、序盤の方が特に辛かったです。

提出物がなかなか合格できない

課題の提出物を作ると、メンターさんにレビューをしていただきます。
できなくて当然なのはわかっているのですが、100個近いコメントをいただいた時は、自信をなくして修正する気力が失せたりしました😅
慣れてくると、コメントが多いのはメンターさんの愛だと思えるようになり、何度再提出になってもあまり気にしなくなりました。苦労した分、合格した時の喜びは大きかったです✨

いつ卒業できるのか不安

カリキュラムが多いため、いつ卒業できるかが常に不安でした。
私は入学時に「1年で卒業する」という目標を立てていましたが、結局達成はできなかったです💦(もっと短期間で卒業している方も沢山いるので、やり方次第だと思います)
ただその分、課題の発展的な要件にも取り組んだり、カリキュラムとは直接関係ない技術書を読んだりなど、深掘りして学習することがある程度できたと思っています。

就職活動について

自作サービスの後半と並行して、就職活動を行いました。
FBCの紹介企業を一社受けて、その会社から内定をいただきました。

スケジュール

やったこと
4月中旬 FBC内での企業説明会
5月上旬 カジュアル面談→書類選考
5月中旬 RubyKaigiや個人的な事情(引越し)などで一度中断
6月上旬 一次面接
6月中旬 最終面接
6月中旬 オファー面談→内定
7/1 入社

就職先について

FBCの紹介企業で、教育関係のプロダクトを作っている会社です。
前職の経験が活かせるイメージが湧いたため、カジュアル面談を受ける前からほぼ入社を決めていました😊

選考対策について

FBC側で、履歴書・職務経歴書の添削、面談練習を2回していただきました。どちらもすごく丁寧にフィードバックをいただきました。

以前、転職活動がうまくいかなかった経験があり、不安はとても強かったです。
内定をいただくことができたのは、関係者の皆様に親身にサポートしてもらったこと、FBCの卒業生の評判が良かったことのおかげだと思っています。

今後やりたいこと

子ども達や先生方の役に立つプロダクトを作れるようになりたいです。そのために一日も早く戦力になれるよう、技術力を上げていくことが当面の目標です。

また、会社のFBC卒業生は私が一人目なので、頑張って働いて「さすがFBC卒業生」と言ってもらえるようになりたいです!

今後のFBCとの関わり方

勉強会に参加したい

FBCには、現役生だけでやっている勉強会はもちろん、卒業生と現役生が混じっているものや、卒業生の方が中心となって運営している勉強会があります。
現在私が参加している現場で使える Ruby on Rails 5速習実践ガイド の輪読会は、あと数ヶ月続きそうなので、卒業後も継続して参加していきたいです。その後も、難しめの技術書を読む輪読会など、何かしらに参加していたいと思っています。

カリキュラムを復習したい

「卒業したのでFBCをやり切った」と書けたらいいのですが、実はまだやっていない「発展編」というカリキュラムがあります。加えて、この記事を書いていて、序盤のカリキュラムはかなり忘れていることに気づきました😅
まだまだFBCから学ぶべきことは多いので、今後も勉強をさせていただきます。

自作サービスを改善する

最終課題として作った自作サービスを、実際に使ってくれる人がいました。
アプリの性質上、本格的に使ってもらえるのは秋頃だと思うので、今後もパフォーマンスの改善や新機能の追加などをしていきたいです。

おわりに

FBCを卒業して就職し、晴れて無職生活も卒業できました✨ 応援してくださった皆さまに、改めて感謝申し上げます。

勉強生活には終わりを告げましたが、エンジニアとしてはここがスタートになります。
FBC卒業生の名に恥じぬよう頑張りますので、今後ともよろしくお願いします。

山手線を徒歩で一周する人のための記録アプリ「YamaNotes」をリリースしました

YamaNotesのロゴ

はじめに

山手線を徒歩で一周する人のための記録アプリ「YamaNotes」をリリースしました。
この記事では「YamaNotes」の使い方や、開発過程で苦労したことなどをまとめます。

6/14追記:東京の気温が高くなることが予想されています。熱中症予防のため、涼しくなってからの挑戦をおすすめします。

自己紹介

すずかと申します。
昨年4月にFJORD BOOT CAMPフィヨルドブートキャンプ:以下FBC)に入学して、プログラミング歴は約1年です。以前は高校の国語教員をしていましたが、新しい挑戦をするため退職し、未経験からWebエンジニアを目指しています。

アプリの概要

山手線一周に徒歩で挑戦する人向けの記録アプリです。
各駅の到着時刻や、疲れ具合のメモなどを、簡単に記録することができます。

山手線徒歩一周チャレンジとは?

その名の通り、山手線を徒歩で歩くことです。
正式なデータではありませんが、総歩行距離は約45km、12時間ぐらいかかることが多いようです。RTAとして挑戦している人もいます。

使い方

ログインする

トップ画面からGoogle アカウントでログインします。 トップ画面のキャプチャ

初期設定をする

モード(外回り or 内回り)と、出発駅を設定します。 初期設定画面のキャプチャ

進捗を確認する

現在の進捗が地図上に表示されます。残りの駅数や距離を確認しましょう。 ダッシュボードのキャプチャ

到着する

駅に着いたら、「到着」ボタンを押しましょう。メモを追加したり、Xで進捗をポストすることもできます。 到着画面のキャプチャ

履歴を確認する

到着時刻の編集や、メモの追加を行います。間違えて「到着」ボタンを押した場合は、削除することもできます。 履歴画面のキャプチャ

開発に至る経緯

昨年4月に15時間ほどかけて、はじめて山手線を一周しました。 普段ほぼ運動しない私にとっては辛い挑戦でしたが、歩き終わった時の達成感はこれまで感じたことのないものでした。
この挑戦をもっと楽しくするために、「YamaNotes」を作りました。

技術スタック

技術選定の理由

「必要な機能を短期間で作ること」「コストを抑えて作ること」を軸に行いました。

短期間で必要な機能を作るため、Rails7とHotwireで実装

FBCのカリキュラムでReactを学習していたため、他のフレームワークを使用することも検討しましたが、数行のコードでSPA風の挙動を実現できる開発コストの低さに惹かれ、Hotwireを採用しました。
本格的な開発に入る前に、猫でもわかるHotwire入門パーフェクト Ruby on Railsで学習し、想定した機能が問題なく実装できることを確認しました。
実際に開発してみると、Hotwireを使ったのは大正解で、JavaScriptをほとんど書かず素早く実装できることに感動しました。やりたいことを整理した上で、サービスの規模に合わせた技術選定をする重要性を実感しました。

コストを抑えて作るため、APIやデプロイ先を調査

しばらくはサービスを継続したいと考えているため、維持費を抑えることにこだわりました。一部に従量課金制のものがありますが、想定されるアクセス数なら無料で運用できるよう作りました。
特にコストを抑えるために考慮したのは、以下の2つの箇所です。

地図の表示と描画にLeaflet + OpenStreetMapを使用

当初は開発の情報量の多さ・地図の見やすさなどに魅力を感じ、Google Maps APIの使用を検討しました。しかし無料枠がやや少ないと感じたため断念し、無料で使えるものを探した結果、OpenStreetMapで地図を表示してLeafletというライブラリで線や吹き出しを追加することにしました。
加えて、地図タイルをOpenStreetMap標準のものからMapTilerのものに差し替えました。こちらは従量課金制で無料の範囲に収まることをを想定していますが、場合によっては無料のものに戻すつもりです。地図の見やすさとコスト削減を両立できたと思っています。

Render.com + Supabaseでデプロイ

当初はFly.ioにデプロイするつもりでしたが、無料プランが無くなったようなので、Supabaseのデータベースを使ってRender.comにデプロイしました。
Supabaseに触れるのは初めてでしたが、同じFBC生の方が書いたこちらの記事に助けられて、無事デプロイすることができました。
Rails7+Render.com+Supabaseで無料デプロイ - はるまきのブログ

こだわったこと

「YamaNotes」というネーミング

「名前重要」という言葉をよく聞くので、サービス名はこだわりました。
山手線の「Yamanote」と、記録を表す「Note」を組み合わせ、複数形の「YamaNotes」としました。
山手線一周アプリ」といっても、地図や情報提供・RTAのための時間管理など、色々なアプリが考えられますが、この名前が決まったことにより、山手線一周の「記録」に特化する方向性に決まりました。

地図上に線を引いて、進捗をわかりやすくすること

「記録」に特化したアプリなので、ユーザーは地図を別で用意していることを想定しています。そのため、アプリ上に地図の表示は必須ではなく、下のように路線図に進捗を表示する方法もありました。

地図を使わない実装イメージ:路線図はillustACよりクレジット表記不要のものを使用

しかし、山手線の駅間は最長の区間(大崎〜品川間:約2.0km)と最短の区間(日暮里〜西日暮里間:約0.5km)では、かなりの差があります。路線図の色を変える方式では、駅間の距離の違いを反映できないと考え、地図上に直線を引くことにしました。
進捗をわかりやすくするとともに、地図に直接線が引かれるワクワク感があり、気に入っています。

全ての機能やメソッドに対してテストを書くこと

不具合を見つけてより快適に使ってもらうため、テストコードをもれなく書くよう意識しました。
FBCのカリキュラムではMinitestでテストを書いていましたが、自作サービスではRSpecを使うことにしたので、Everyday Rails - RSpecによるRailsテスト入門を参考に勉強しました。その後、全てのpublicなメソッドや機能について、ひたすらテストを追加しました。

simplecovによると、テストカバレッジは99%のようです。 テストカバレッジ 今後も勉強を続けて、今書けていないテスト(認証周りの異常系など)も追加していきたいです。

苦労したこと

Hotwireが魔法のように見える

「YamaNotes」では、以下の箇所にHotwireを使用しています。

  • Turbo Drive:基本的な画面遷移
  • Turbo Frames:編集フォームの表示
  • Turbo Streams:編集後の更新処理
  • Stimulus:地図の表示・線の描画、モーダル・ハンバーガーメニューなど(tailwindcss-stimulus-componentsを使用)

数行のコードを書くだけで動きをつけることができ、非常に便利に感じる一方で、特にTurbo Streamの実装で理解が浅いせいで思うように動かず、苦労しました。 到着履歴画面の削除機能など、まだまだTurboに置き換えたい部分があるので、もっと深く理解できるよう勉強したいです。

カスタムバリデーションを設定すること

到着機能の実装において、「駅の数以上に到着できない」「前後の記録と齟齬がある到着時刻を設定できない」など、色々なバリデーションを設定する必要がありました。
最も苦労したのが、「隣駅以外に到着できないようにする」バリデーションです。内回り・外回りそれぞれで対応する必要があったため、当初はStationテーブルに「外回り時の次の駅ID」と「内回り時の次の駅ID」を持たせる設計にしていました。
ただ、実装時に作りにくさを感じたため、紙に書き出してロジックを考え、次の駅の取得方法を考え直しました。

ロジックを考えた時のメモ

考えた時のメモ

データベースには「外回り時の次の駅ID」のみを持たせ、Stationクラスのnextメソッドで外回り・内回りに応じて条件分岐することで、要件を満たすバリデーションを設定することができました。

使いやすいデザインにすること

CSSが苦手なのもあり、最低限使えるデザインにするまでが、まず大変でした。一通りデザインを入れた後も、レスポンシブ対応・OGPやFaviconの設定・画像の圧縮やaltの設定・・・・など、使い勝手の良いアプリにするためにやるべき作業が山のようにあり、苦労しました。
自分なりのデザインを入れた後は、FBCのデザイナーさんにレビューをしていただき、修正を繰り返しました。お陰様で、シンプルで使いやすいデザインになったと思っています。
「普通に使えるサービス」のデザインが、如何に考えて作られているかを知ることができ、デザイナーさんへ尊敬の念が湧きました。

今後やりたいこと

複数回記録できるようにする

ファーストリリースでは最低限の機能に絞ったため、現在の実装では、作成できる歩行記録はユーザ一人につき一つだけとなっています。つまり、二周目を歩く際には、一周目の記録を削除して記録する必要があります。
RTAをするために山手線を何周もする人は想定されるため、将来的に複数の歩行記録を作成・閲覧できるようにしたいです。

パフォーマンスの改善

現在は到着ボタンを押した時に、約2秒の時間がかかっています。到着ボタンは何度も押すことになるので、もう少し速くしたいところです。
発行されるクエリを減らすためのリファクタリングや、使っていないインスタンス変数の削除、キャッシュの利用などを行って、若干速くはなりましたが、サクサク動くにはまだ至っていません。到着時にカスタムバリデーションを複数実行していることや、Render.comに東京リージョンがなくシンガポールに設定していることが、要因として考えられます。
今後はパフォーマンスについて勉強するとともに、東京リージョンがあるサービスへの移行も検討しようと思っています。

到着駅に応じたイラストや文言を追加

現在は到着画面が二種類(歩き終わった時用とそれ以外用)だけなのですが、着いた駅や進捗に応じたイラストを表示できると楽しいかなと思っています。例えば、上野駅に着いた時にパンダのイラスト、残り一駅の時に「あとちょっとだから頑張れ!」的なメッセージを出すなどしたいです。

おわりに

作り始めた時は、作りきれるか不安でしたが、どうにかリリースすることができました。
無事リリースできたのは、毎日お世話になったFBCの皆様、あたたかい言葉をかけてくれたRubyコミュニティの皆様、SNSを通じて応援してくださった方々のおかげだと思っています。
YamaNotesは今後も改善を続けるつもりなので、ご意見や感想などをいただけると嬉しいです!

フィヨルドブートキャンプでプログラミングの勉強をする【13ヶ月目】

未経験からフィヨルドブートキャンプ(以下FBC)で勉強して、1年1ヶ月が経ちました。

今月も振り返りを書いていきます!卒業が見えてきたので、振り返りを書くのはこれで最後(にしたい)です😅


4月の過ごし方

自作サービスを集中して進めつつ、気候が良かったので、息抜きに外で遊んでいることが多かったです。

4月中旬には、江ノ島に日帰りで行ってきました!新江ノ島水族館で、カピパラがお風呂に入っていたのが可愛かったです🥰

お風呂に入るカピパラの写真

勉強の状況

4/4~5/3で修了したプラクティスは2つだけです。

1ヶ月間で修了したプラクティス一覧

開発に参加して PR を送りマージする

CI

自作サービスは、「Webサービスを作る」という大きな1つのプラクティスになっているため、修了はしていませんが、作業としては結構進みました。

作業が残っているプラクティスは「Webサービスを作る」「デザインレビュー」「コードレビュー」「リリース」のあと4つです。


勉強時間

学習時間は13ヶ月間(396日)累計で2451時間でした。

学習時間

4月後半からは就職活動を並行して行うことにし、書類の作成を進めました。

FBCのホームページに書いてある目安時間(1200時間)の倍以上かかっていますが、もう一息頑張ります!


自作サービスの進捗

「山手線を徒歩で一周する人のための記録アプリ」を作っています。

今月取り組んだこととしては、以下の通りです。

履歴一覧機能→履歴編集機能→公開機能→メモ追加用モーダル→ヘルプのモーダル→ハンバーガーメニュー→利用規約・プライバシーポリシー作成→バグ修正

地図の表示や到着などの基本的な機能が動作するようになりました。現在はデザインを入れたりテストを書いたりなど、細かい部分の実装を進めています。

全ての機能が出来たら、FBCのメンターさんにコードレビュー・デザインレビューをお願いします。レビュー対応が終わり次第、6月上旬のリリースを目指しています。

ロゴ(仮)ができました!

できるようになったこと

  • カスタムバリデーションを実装できるようになった
    到着機能の実装で、「駅の数以上に到着できない」「前後の記録と齟齬がある到着時刻を設定できない」など、色々なバリデーションを設定する必要がありました。
    特に難しかったのが、「隣の駅以外の到着できないようにする」バリデーションです。内回りモード・外回りモードそれぞれに対応する必要があり、かつ駅の登録順に依存しないようにする必要がありました。紙に書き出してロジックを考えてから実装することで、要件を満たすバリデーションを設定することができました。

    考えた時のメモ

    バリデーションを考えた時のメモ

    Stationsテーブルに「外回り時の次の駅id」のカラムを持たせ、内回り・外回りで条件分岐させることで、登録順に依存せずかつバリデーションも設定することができました。

  • Hotwireを使用して簡単な機能を作れるようになった
    自作サービスでは、ダッシュボード画面と到着一覧・編集画面にHotwireを使用しています。 使っている箇所は以下の通りです。

    • Turbo Drive:基本的な画面遷移
    • Turbo Frames:編集フォームの表示
    • Turbo Streams:編集後の更新処理
    • Stimulus:地図の表示・線の描画、モーダル・ハンバーガーメニューなど(tailwindcss-stimulus-componentsを使用)

    Hotwireを扱うのは初めてでしたが、「猫でもわかるHotwire」「パーフェクトRuby on Rails」を読み、基本的な実装方法を理解しました。一度やり方がわかると、JavaScriptをほとんど書かず、素早く実装できることに感動しました✨

  • RSpecで簡単なモデルテスト・システムテストが書けるようになった
    モデルとシステムテストの追加が概ね終わりました。ある程度実装が進んでから一気にテストを書いたら、量が多く大変だったので、その後は機能を作ると同時にテストを書くようにしています。
    今後は、Helperのテスト追加とリファクタリングをする予定です。特に、一部のテストでは「内回りモード」「外回りモード」の2つが存在するため、shared_examplesshared_contextを使用して、もう少しDRYになるようリファクタリングしたいです。

苦労したこと

  • CIだけで落ちるシステムテストの修正に苦戦
    ローカルでは全て成功しているシステムテストが、一つだけCIで落ちるようになり、何時間も詰まりました。エラー文を見ると、Capybaraのclick_onで要素が見つからないのが原因でしたが、特に怪しい部分もなかったため、手がかりがなく非常に困りました😭
    FBCの先輩に「何かしらのキャッシュが関係しているかも」とアドバイスいただき、一度全てのキャッシュ・失敗した履歴を削除して再度実行したら、解決することができました。ローカルで再現しない不具合の原因を特定することの、難しさを感じました。

  • リファクタリングの終わりが見えない
    「とりあえず動くようになる」ことと、「ユーザが使っても問題なく動くようにする」ことの間が、思った以上に長いです😅
    自分なりに工夫してコードを書いたつもりでも、余分なクエリが発行されていたり、特定の状況下のみバグが起きたり、想定しない不具合がたくさん起きました。
    現在リファクタリングを進めていますが、全てのコードに自信を持てている状態には程遠いです。納得のいく状態に近づくよう、気になったことは部分はメモして、定期的にリファクタリングしたいです。

  • デザイン関係で考慮すべきことが多い
    全てのページにデザインを入れるはもちろんですが、レスポンシブ対応・titleタグやmeta descriptionの設定・OGPやFaviconの設定など、使い勝手の良いアプリにするためにやるべきことが沢山ありました。
    デザインの重要性はわかっているので、ストレスなく使えるものにしたいです。ただ、凝りすぎると一生リリースできないので、どこまでこだわるかが悩ましいです🤔

イベント参加など

  • RubyKaigi 2024事前勉強会に参加
    申込時に補欠でしたが、当日数時間前に繰り上がって参加できました。 Ruby Kaigiの話を理解するため、議題となる内容の背景知識を解説してくださっていたのがありがたかったです。JITコンパイラやパーサー改善など、初心者向けの解説でも私にとっては難しかったですが、何を勉強すればわかるようになるのかがわかりました。( 雑談で「Rubyのしくみ」という本の存在も知りました)
    懇親会では有名なRubyistの方や、同じ元教員のエンジニアさんとお話しでき、勉強のモチベーションが上がりました✨

  • Urawa.rb #4を主催
    今回は初参加の方が多く、まだ見ぬ世界を教えてもらう素敵な時間になりました。
    活動報告→Urawa.rb #4 活動報告 | Notion
    新しく購入した「Linuxコマンドかるた」が盛り上がり、詳しい方に解説をしてもらって勉強になりました。今は結構忘れてしまったので、毎月やって定着させたいと思います😅
    参加者の方に、「Urawa.rbの参加者は穏やかでいい人しかいない」と言っていただき、本当にその通りだなと感謝しています🙇‍♀️

今の気持ち

自作サービスの追い込みや就職活動の準備・プライベートでは引越しが重なり、4~5月はバタバタしています💦 色々と不安になることも多いですが、FBC生やメンターさんとの雑談にかなり支えられています!

卒業直前に改めてFBCの良さを感じているので、幸せに働くエンジニアになって恩を返せるよう頑張ります💪

5月の目標

  • 自作サービスのデザインレビュー・コードレビューを提出する。
  • 就職活動を後悔がないよう頑張る。
  • RubyKaigi 2024を楽しむ。

Action Mailerのスキップ時に発生するZeitwerk::NameErrorの解決方法

はじめに

Rails でアプリケーションを作成中、あるgemのコマンドを実行するとZeitwerk::NameErrorが発生しました。

expected file /Users/suzuka/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/devise-4.9.3/app/mailers/devise/mailer.rb to define constant Devise::Mailer, but didn't (Zeitwerk::NameError)

調べたことの理解を深めるため、解決した手順をまとめます。

実行環境


エラーの原因

アプリケーションを作るときに、メール機能を使う予定がないため、Action Mailer をスキップしたことです。

rails new sample_app --skip-action-mailer

調べたこと

Action Mailerが無効な場合、Devise::Mailerクラスは定義されない

エラー文にある devise/mailer.rbのファイルを見に行ったところ、以下のようなコードが書かれていました。

deviseはActionMailerが定義されている場合のみ、Devise::Mailerクラスを定義しています。

if defined?(ActionMailer)
  class Devise::Mailer < Devise.parent_mailer.constantize
    include Devise::Mailers::Helpers
  ......
  end
end

このアプリではAction Mailerをスキップしているので、Devise::Mailerクラスは定義されません。

Zeitwerkはファイル名からクラス名を推測する

エラー文にある、Zeitwerkとは何なのでしょうか?

Rails6から導入された、命名規則に則ったファイルを自動で読み込むgemで、「ツァイトヴェルク」と読むようです。このgemがあることによって、requireをたくさん書かなくても、必要なファイルを読み込めるようになります。 github.com Rails6以降、デフォルトで読み込みはzeitwerkモードで実行され、ファイル名と異なる命名規則のモジュール名・クラス名が定義されていた場合はエラーが発生します。

Zeitwerk使用時の、ファイル構造と定義されているクラスとモジュールの例は、以下のとおりです。

lib/my_gem.rb -> MyGem
lib/my_gem/foo.rb -> MyGem::Foo
lib/my_gem/bar_baz.rb -> MyGem::BarBaz
lib/my_gem/woo/zoo.rb -> MyGem::Woo::Zoo

つまり、devise/mailer.rbという名前のファイルがあることで、Zeitwerkは「Devise::Mailerクラスが定義されているはず」と判断します。しかし、このアプリでは実際にはDevise::Mailerクラスが存在しないため、Zeitwerk::NameErrorが発生しました。

解決方法

以下のIssueを参考にしました。

Rails6 without ActionMailer won't boot with zeitwerk eager-loading · Issue #5140 · heartcombo/devise · GitHub

このIssueでは、2 つの解決方法をあげていますが、今回はより簡単な「ダミーのDevise::Mailerクラスを定義する」という方法で行うことにします。

config/initializers/devise.rbに以下を追記しました。

if Rails.autoloaders.zeitwerk_enabled? && !defined?(ActionMailer)
  class Devise::Mailer; end
end

このコードによって Zeitwerkがファイル名から予測するクラスを定義することができ、エラーを解消することができました。

参考文献

Zeitwerkについて:

Zeitwerk::NameErrorの解決について:

フィヨルドブートキャンプでプログラミングの勉強をする【1年経過】

未経験からフィヨルドブートキャンプ(以下FBC)で勉強して、1年(12ヶ月)が経ちました。

3月上旬にチーム開発の作業を終え、そこから自作サービスを作り始めて開発していたら、3月はあっという間に終わっていました。

今月の振り返りと、1年間の振り返りを書いていきます😊


3月の過ごし方

5月にRubyKaigiと引越しの予定があり、取れる時間が減りそうなため、3~4月は自作サービスを何よりも優先して頑張ることに決めました😊

とはいえ、振り返ると3月は結構外出もしており、特にUrawa.rb#3の室内花見が楽しかったです!

飾り付けされたコバトン

3月末には元生徒からお誘いをもらって、昨年まで主顧問していた部活の卒業イベントにお邪魔してきました。元生徒・元同僚の努力する姿に刺激をもらい、自分も頑張ろうという気持ちになりました✨

勉強の状況

3/4~4/3で修了したプラクティスは4つです。

1ヶ月間で修了したプラクティス一覧

リソース・データ設計

技術検証をする

カンバンを作る

ペーパープロトタイプを作る

修了したプラクティス

作業が残っているプラクティスは、「Webサービスを作る」「CI」「デプロイ」「デザインレビュー」「コードレビュー」「リリース」のあと6つです。 自作サービスのリリースまで終わったら、卒業となります✨


勉強時間

学習時間は12ヶ月間(366日)累計で2257時間でした。

学習時間

月平均すると約190時間です。最初の方は学習習慣をつけるため、月200時間以上を目標に取り組みましたが、後半は時間を特に意識しなかったため微減しました。

退職時に決めていた、「最低限、仕事をしていた時間と同じ時間は勉強する」ということは達成できたと思います!


自作サービスの進捗

「YamaNotes」(仮)という、「山手線を徒歩で一周する人のための記録アプリ」を作ることにしました。

イメージはこんな感じです😊

自作サービスのイメージ

今月取り組んだこととしては、以下の通りです。

ペーパープロトタイプ作成→DBとリソースの設計→技術検証→カンバンを作る→rails new→リンターの導入→地図表示機能追加→ログイン・到着機能追加→CIの構築→テスト作成

フレームワークRails(+Hotwire)を使用し、テストはRSpecで書くことにしました。 メイン画面は一応動くようになり、現在はカスタムバリデーションの設定とテスト(ログインと到着)に苦戦中です。

できるようになったこと

  • RSpecの基本的な構文を書けるようになった
    RSpecFBCの必須のカリキュラムに入っていないので、自作サービスを作る段階で初めて勉強しました。
    「Everyday Rails - RSpecによるRailsテスト入門」という本を毎日少しずつ読み、3分の2ぐらい読み終えました。非常にわかりやすいので、実際テストコードを書くときも、この本を見ながら書いています。
    チーム開発ではMinitestを使っていましたが、私は何となくRSpecのほうが好きかもしれないです😊

  • Hotwireの基本的な使い方を理解できた
    こちらもFBCのカリキュラムにはないので、「猫でもわかるHotwire入門 Turbo編」を読んで勉強しました。(読んでいる途中に教材を書いたのがFBC卒業生の方と知り、テンションが上がりました✨)
    画面の一部だけを書き換える処理を、JavaScriptを使わずに簡単に実装できて感動しました。自作サービスでは、地図の描画・到着記録の編集・モーダルの表示などでHotwireを使っていく予定です。

  • GitHub ActionsでCIの構築をできるようになった
    コードをGitHubにプッシュしたら、自動でテスト・RuboCop・ESLintが動くようにしました。
    ドキュメントを読んで、ワークフローファイルを作って動かすところまではすんなりいきました。ただ、いざ実行してみるとMailerに関するエラー→selenium_chromeに関わるエラー→Tailwindに関わるエラーが出てて困りました😇
    その都度エラー文を読んで解決していくことで、無事動作するようにできたので良かったです。

苦労したこと

  • 開発できる環境を整えること
    「いざ作るぞ!」となってから、快適にコードを書く環境ができるまでが長かったです。
    リンターの指摘が厳しすぎる・エラーメッセージやflashが表示されない・CIの実行でエラーが出るなど、本来取り組みたいこととは異なる箇所で直したい箇所が出てきて、その都度修正を繰り返しました。
    今まで何も気にせずコードをかけていた、bootcampアプリの環境のありがたさを感じました😅
  • ログイン機能の作成
    自作サービスでは、DeviseとOmniAuthを使ってGoogleログインを実装することにしました。OAuthの解説サイト、Devise・OmniAuthの公式ドキュメントを読みながら試行錯誤しました。
    特に詰まったのが、「ログインボタンを押すとCORSエラーが出る」という問題です。Rails7系だけで起きる問題のようで、ボタンのTurboを無効化すると解決できたのですが、その情報を見つけるまでが大変でした。
    Turboについては、どこでどのように実行されるのかがよくわかっていないので、もう少し修行したいと思います😇

イベント参加など

  • Urawa.rb #3を主催
    第3回目は「室内花見会」と称して、もくもく会と懇親会を行いました。 童心に帰って沢山遊び、参加者の皆さんと親睦を深めることができました🌸
    活動の様子はこちら:Urawa.rb #3 活動報告 | Notion

  • FBC内のLT会で登壇
    テーマが「最近面白かったこと・もの」だったので、地域.rbの立ち上げについてお話をしました。Urawa.rbに興味を持ってくれる方がいたので、嬉しかったです。
    FBC内のLTは今回で4回目で、だいぶ慣れました。次は地域.rbなど、外部のLTに挑戦したいです!

1年間の振り返り

勉強を継続できた嬉しさと、1年間フルコミットしても卒業できていない悔しさが入り混じっています😅
1年間でできたこと・できなかったことをまとめておきます。

  • 入学時のバックグラウンド:

    • 高校の国語教員を退職直後。
    • 退職金でMacを購入し、使い方がよくわからない。
    • プログラミングの勉強歴ほぼなし。ProgateでHTML・CSSをちょっとやった。
  • 1年間でできたこと:

    • Railsで簡単なアプリケーションを作るために必要な知識をつけること。
    • 毎日日報を書くこと。(366回)
    • 毎月振り返りブログを書くこと。(12回)
    • FBCの皆さんと交流や、輪読会などで一緒に勉強すること。
    • 現役エンジニアさんの知り合いを作ること。
  • できなかったこと:

    • FBCを1年で卒業すること。
    • 定期的に技術記事を書くこと。
    • FBC外のイベントでLTをすること。

お世話になっているメンターさん、受講生・卒業生の皆さんには、大変感謝しています。卒業までもう少し、よろしくお願いいたします🙇‍♀️

4月の目標

  • 一通りの機能を完成させる。
  • デザインレビューを提出する。

フィヨルドブートキャンプでプログラミングの勉強をする【11ヶ月目】

フィヨルドブートキャンプ(以下FBC)で勉強して、11ヶ月目が終わりました。

2月はチーム開発の山場で、先月より難しめのIssueやレビューにも取り組みました!振り返りを書いていきます😊


2月の過ごし方

相変わらず寒い日が多いので、引きこもり気味で過ごしていました。 2月上旬に雪が降ったので、雪だるまを作りました。

雪だるまの写真

材料について、質問されることがあったので書いておきます。

ペットボトルのコーラの蓋(マジックで黒く塗りつぶす)
切れたヘアゴ
にんじんのしっぽ
ほっぺ 100均の造花の一部
マフラー 細めのタオル

雪だるまを作りたい方の参考になると嬉しいです😊

FBCのチーム開発について

今月はチーム開発中心に進めたので、FBCのチーム開発の中身を簡単に書いておきます。

FBCでの学習は、「bootcamp」というWebアプリを使っています。提出物や日報の作成・質問・イベントのお知らせなど、学習の大半はこれを使って行います。 github.com

チーム開発のプラクティスまで到達すると、受講生自身でこのbootcampのリポジトリにPRを作り、バグの修正・新機能の追加などを行います。 つまりFBCの学習サイトは、先輩方が書いたコードの積み重ねでできているということです✨(すごい!)

開発は、以下の流れで進みます。

Issue割り振り→作業→PR作成(→必要ならデザイン依頼)→受講生レビュー→メンターさんレビュー→マージ→ステージング環境で動作確認→本番環境で動作確認

Issueには難易度に応じてポイントがつけられていて、20pt貯まったら修了となります。私の感覚ですが、簡単なものだと1pt、3pt以上だと苦戦するかなという印象です。

詳しくはこちらもご確認ください。 bootcamp.fjord.jp

勉強の状況

2/4~3/3で修了したプラクティスは1つだけです。

1ヶ月間で修了したプラクティス一覧

どんなサービスを作るかを考える

修了したプラクティス

ラクティスは進んでいませんが、チーム開発はだいぶ進捗がありました。今の状況としては、以下のとおりです。

チーム開発のポイント数

ざっくりいうと、作業が終わっているのが15pt、作業中なのが3pt、これから取り組むのが2ptです。作業自体は、あと2つのIssueに取り組めば終わりとなります。


勉強時間

学習時間は11ヶ月間(336日)累計で2065時間でした。

学習時間

学習時間が2,000時間に到達しました。 「まだ卒業できないの?」という声が聞こえてきそうです💦

FBC卒業までにかかる期間は、入学時点のプログラミング経験・深掘り学習の度合いなどにより、かなり幅があるように感じます。

深く理解するために時間をかけて卒業される方も沢山いるので、私も焦りすぎずに進めていきます😊


できるようになったこと

  • 仕様が決まりきっていないIssueを進められるようになった
    先月は「文字を修正する」などの簡単なIssueが中心でしたが、今月は「ポートフォリオ一覧ページを追加する」という、使い勝手が大きく変わるIssueにも取り組みました。
    割り振られた時点で、表示する項目やURL、既存のコードとどこまで共通化するか等が決まってなかったので、迷った箇所は相談しながら進めました。 テキストコミュニケーションの難しさを感じることが多々ありましたが、以前よりは慣れてきました!

  • Net::HTTPやnokogiriを使って、スクレイピングができるようになった
    bootcamp上でGitHubの草(Contribution)が表示されていたのですが、GItHubの仕様変更により表示されなくなっていました。バグを修正するため、Net::HTTPライブラリとgem「nokogiri」を使用したコードの修正を行いました。
    「草を取得して表示できたが、GitHub上の草とほんの少し異なる」というバグに苦しみましたが、無事原因がわかり、 PRの作成→レビューまで進めることができました。

  • 自分でIssueを作れるようになった
    普段自分が使っているシステムなので、自分でIssueを立てることにも取り組みました。
    立てたIssueの中には、私自身にアサインしてもらえたものもあり、自分の意見でbootcampが変わっていくのが非常に嬉しかったです😊

苦労したこと

  • 難しめのレビューを依頼された時、コードを理解できない
    フロントエンドの知識不足で、ReactやVue.jsが関わるレビューの依頼をいただいた際、なかなか理解できず時間がかかってしまいました💦
    レビュイーの方をお待たせしたくないと思う一方で、Approveには責任が伴うことも感じています。今は、多少時間がかかってもコードの流れを丁寧に追い、数回読んでも理解できない部分を質問するという方法で進めようかなと思っています。
  • バグの再現や検証が難しい
    現在、bootcamp本体ではなく、bootcampのリポジトリ上で動いているGitHub Actions・関連する別のWebアプリのバグ修正に取り組んでいます。
    本体のリポジトリを汚さないよう、検証用のリポジトリとWebアプリを用意して、バグの再現に取り組みました。色々実験してもバグを再現させることができず、右往左往しました。
    今後はバグ修正に取り組む際は、闇雲に手を動かすのではなく、「ログや状況を整理して仮説を立てる」のを意識したいと思います。

イベント参加など

  • Urawa.rb #2を主催
    2回目も参加者の皆さんがとても素敵な方々で、和やかな時間を過ごせました。チーム開発のIssueのアドバイスもいただき、大変助かりました🙏
    第3回はいつものもくもく会にプラスして、エア花見会もやります🌸まだ人が集まっていないので、これを読んでいる皆様、もしご興味があればお申し込みください!(切実) urawarb.connpass.com

  • Rails Girls Tokyo 16thにスタッフとして参加
    昨年ガールズとして参加したRails Girlsに、今年はスタッフとして参加させていただきました✨
    プログラミングの楽しさや、Rubyコミュニティの素晴らしさを感じることができ、貴重な経験となりました。これについてはどこかのタイミングでブログを書きたいと思っています。

  • 就職相談や企業説明会に参加
    今まで目を逸らしがちでしたが、そろそろ就活のことを考えなければならなくなりました😅
    個別の就職相談を初めてお願いし、1時間以上親身に相談に乗っていただきました🙇‍♀️
    加えて合同企業説明会に参加し、4社の説明を聞いたり、直接質問したりしました。就職に向け、実力をつけることを意識しつつFBC卒業を目指します!

今の気持ち

チーム開発が終盤に差し掛かり、「早く卒業したい」という気持ちが増してきました。 入学時点では卒業がイメージできなかったことを考えると、結構進んだな思います😊

時間は無限にあるわけではないのでスピードも意識しますが、「スキルをつけて幸せなエンジニアになる」という目標を常に忘れずにいようと思います!

3月の目標

  • チーム開発を終わらせる。
  • 自作サービスの計画を立てる。

「追いかけるメソッド」は定義できるが「猫クラス」はエラーになる【Ruby】

はじめに

輪読会で「現場で使える Ruby on Rails 5速習実践ガイド」を読んでいると、Rubyの文法説明の例で「猫クラス」・「追いかけるメソッド」が出てきました。

実際に irbで「猫クラス」を作ったところ、class/module name must be CONSTANT (SyntaxError)というエラーが出て、定義できませんでした。

irb(main):* class 猫
irb(main):> end
/Users/suzuka/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/irb-1.11.2/lib/irb/workspace.rb:117:in `eval': (irb):1: class/module name must be CONSTANT (SyntaxError)

同じ日本語でも、「追いかけるメソッド」は定義できたため、「猫クラス」を定義できないのを不思議に思いました。

irb(main):* def 追いかける
irb(main):> end
=> :追いかける

この記事では、「猫クラス」が定義できない理由について、調べたことをまとめます。

初心者が書いた記事のため、間違いなどあれば指摘していただけると嬉しいです。


実行環境


結論

クラス名はアルファベット大文字始まりでなくてはいけないようです。

「猫クラス」はエラーになりますが、「A猫クラス」は定義できました。

irb(main):* class A猫
irb(main):> end
=> nil

メソッド名には「アルファベット大文字始まり」の決まりがないため、日本語はもちろん、絵文字や記号でも定義できました。

irb(main):* def 猫
irb(main):> end
=> :猫
irb(main):* def 🐈
irb(main):> end
=> :🐈
irb(main):* def -
irb(main):> end
=> :-


クラス名が大文字始まりの理由

では、なぜクラス名は大文字始まりでなくてはいけないのでしょうか?

「猫クラス」を定義した時の、エラー文を見てみましょう。

class/module name must be CONSTANT (SyntaxError)
訳:クラス/モジュール名は定数である必要があります (構文エラー)

一見クラス定義には関係なさそうな、「定数」という言葉が出てきました。

定数は大文字で始める

Ruby の変数・定数は、最初の一文字によってローカル変数・インスタンス変数・クラス変数・グローバル変数・定数のどれかに区別されます。

その中で、アルファベット大文字 (A-Z) で始まるものが定数です。

クラス定義では定数への代入が行われる

では、定数とクラスの定義はどんな関係があるのでしょうか?
公式ドキュメントに説明がありました。

クラス定義式はクラスオブジェクトの生成を行うと同時に、名前がクラス名である定数にクラスオブジェクトを代入する動作をします。クラス名を参照することは文法上は定数を参照していることになります。 変数と定数 (Ruby 3.3 リファレンスマニュアル)

少し説明が難しいので、「Catクラス」が定義された場合を例に説明します。

class Cat
end

このコードが実行された時、以下の 2 つの処理がされています。

  • 新しくクラスオブジェクトを作る。
    クラスもオブジェクトの一つで、Classクラスのインスタンスです。
  • クラスオブジェクトを定数「Cat」に代入する。

下のようなコードを思い浮かべると、オブジェクトの作成と代入のイメージしやすいかもしれません。(この書き方でもクラスを定義できます)

Cat = Class.new

つまり、クラス定義ではクラス名と同名の定数への代入が行われており、定数はアルファベット大文字で始まる必要があります。

まとめ

  • 「猫クラス」を定義するとエラーになる理由は、Rubyクラス名はアルファベット大文字始まりである必要があるから。
  • クラス名がアルファベット大文字始まりでないといけない理由は、クラス定義の際に内部で定数への代入が行われているから。


おまけ:「猫クラス」を作るには?

どうしても「猫クラス」を作りたかったので、方法を調べました。

1. gemを検討する

ruby-japanizeという、Rubyを日本語で書けるようにする素敵なgemがありました。

github.com

私の環境では Rubyのバージョンを切り替えてもエラーが出てしまい、動きませんでした。 下のようなコードが書けるみたいなので使ってみたかったです 🥲

  組(数値) {
  定義(:足す) {|他の数|
    自分.+(他の数)
    }
  }

  ある数 = 5.足す 6


2. 一度変数に代入する

「猫」という変数にクラスオブジェクトを代入するようにしたところ、猫.newができるようになりました。

猫 = Class.new do
  def 鳴く
    puts 'にゃー'
  end
end

タマ = 猫.new
タマ.鳴く
# => にゃー

ただし、名前なしのクラスオブジェクトを「猫」という変数に代入しているだけなので、クラス名を調べると「nil」になっています。

"文字列".class.name
# => "String"

タマ.class.name
# => nil

真の猫クラスを定義できたわけではなく、見た目上猫.newができているだけです😅

できる限り日本語にした

偽物とはいえ、せっかく猫.newができるようになったので、できる限り日本語のコードを書いてみました。

  • 準備:エイリアスの設定と、猫クラスの中に属性・メソッドを追加
alias 表示する puts

猫 = Class.new do
  attr_reader :名前

  def initialize(名前)
    @名前 = 名前
  end

  class << self
    alias 作る new
  end

  def 鳴く
    表示する 'にゃー'
  end
end
  • コードを日本語で動かす
ある猫 = 猫.作る('タマ')
ある猫.鳴く
表示する ある猫.名前
# => にゃー
# => タマ

日本語化はとても難しくて、初心者には短いコードで限界でした。

どうしても日本語でコードを書きたい時は、日本語プログラミング言語の「なでしこ」を使うのがいいと思いました。 nadesi.com

参考文献