kazumi-learning

[kazumi-learning]

実質6万のパソコンでプログラミングスクールを卒業した話

これは「フィヨルドブートキャンプ Advent Calendar 2022 Part1」の14日目の記事です。

昨日はガラムマサラさんのAtCoderのB問題が解けるようになったでした！

軽く自己紹介

こんにちは。 最近異業種からエンジニアに未経験転職したkazumiと申します。 フィヨルドブートキャンプというプログラミングスクールを受講してプログラミングの基礎知識を学んでおりました。

今回はスクール受講時に使っていたパソコンが実は実質6万程度のものだった、というお話です。(どんな話)

格安PCでも（さほど）問題なくプログラミングを学習したり、開発することができます。

プログラミングを学びたいけど「良いPC持っていないし・・・新しく購入しないといけないのかな？」と思っている方に読んでいただきたいです。

どんなパソコンでもプログラミング学習は今すぐ始められる

プログラミング学習は今皆さんがお持ちのPCで今すぐ始めることができます。 もちろん必要なツールをインストールするための空き容量は必要ですが、決して高価で高性能なPCである必要はないのです。

最近ではcodesandboxのようにブラウザ上に開発環境を作ってくれるサービスもあるので、インターネットに繋がりさえすれば、もはやツールをインストールする必要すらありません。

お金をかけずにどなたでもプログラミングを楽しめるのです。

一般的なプログラミングスクール受講時に必要とされているPCの要件

しかし、プログラミングスクールに入会して勉強しようと思ったら話は変わります。

多くのプログラミングスクールでは受講時に必要なPCのスペックを提示しており、それに合わせたPCを用意しなければなりません。就職を最終的な目標としているスクールが多いため、実際のお仕事で使うような端末が必要なんですね。

で、「どんなパソコンを用意する必要があるの？」ってお話なんですが、ほぼ全てのスクールでMacのパソコンを持っていることを条件としています。

Macのパソコンというとお安いモデルでも10数万円します。

お高いです・・・！

せっかくプログラミングスクールで勉強をしようと思っても、わざわざお高いPCを購入しなければならないのであれば「やっぱりやめようかな」とか「独学で乗り切ろうかな」という気持ちになる人もいるかもしれませんよね。

Windowsでも受講可能だったスクール

多くのプログラミングスクールがMacのPCを持っていることを必須とする一方で、私が受講していたフィヨルドブートキャンプではWindowsやLinuxのPCでも受講可能でした。

詳細は受講できるパソコンの要件に書いてあります。

これはWindowsのPCしか持っていなかった私にとってはめちゃくちゃありがたかったです。

だって「自分がプログラミング学習を続けられるか分からない状態」でわざわざMacを購入するのって結構な賭けじゃないですか。 何らかの事情でプログラミング学習を辞めたいと思った時にMacを購入したことが無駄になる可能性があるので。

入会にあたって余計な投資をせずに今持っているWindowsのPCで受講できるというのは、入会時のハードルをかなり引き下げてくれました。

Windowsで開発ってやりづらくないの？

Windowsは開発環境としては向いていない、というイメージをお持ちの方もいらっしゃるかもしれませんが、WSLというソフトを使うことでWindowsの中にLinuxの仮装環境を作ることができるのです。

これによってMacや本物のLinuxと同じくらい快適に開発を進めることができます。

WSLは本当に使いやすいのでおすすめです。 無料です。

格安PCで開発に支障は出ないのか

私の使っていたWindowsのPCはHP Pavilion13 Corei5 8GBで、趣味でインターネットを楽しむには十分でしたが、開発に使うPCとしては低スペックの部類に入ると思います。（見た目がピンクで可愛いから買った）

新品で値段は8万3500円ですが30％ポイントバックだったので実質6万円以下。

実際にこの格安PCでスクールのカリキュラムを全てこなし卒業制作の自作サービスの開発も行いました。

私は初めてrailsでの開発でbundle installした時にインストールが終わるまで数十秒かかったのですが、「あ〜これMacだったら数秒で終わるやつだ」と、処理が遅いのは自分のPCのせいだと思っていました。

しかし色んなコーディング動画などを観ていると、Macを使っている人でもbundle installとかyarn installで数十秒は待機時間が発生していることに気付きました。 そこで私のPCもMacのPCも実は性能に大差がないのでは？と思い始めました。

実際、最近エンジニア就職してMacを使い始めたのですが私の使っていたPCと比べて「めっちゃ早く動くやん」と思ったことは別にないです。

格安PCで困ったこと

しかし1つだけ格安PCで困ったこともありました。

それはサブモニターを接続するとPCがめちゃくちゃ重くなり動作がガクガクになっていたことです。 これは流石に低スペックが原因だと思います。

そのためサブモニターを使うことを諦めてずっとPCのモニターのみで開発をしていました。 輪読会の時も、1つのモニターの中で電子書籍とエディタ開いてドライバーやったりしてました。画面ぎゅうぎゅう。

めちゃくちゃ困るというほどではないけど、少し生産性が悪かったように思います。

・・・うん。

ということは、それなりのスペックのPCを持っていた方が開発や学習はしやすいということになりますね。

（そりゃそうだろう）

なんか雑だけど結論

それなりにハイスペックなPCの方が開発はしやすいけど、 低スペックPCでも1からサービスを作り上げることはできる、というのが結論です。

いきなりMacなどの高価なPCを用意しなくても、まずはお持ちのPCからプログラミング学習を始めるのはめちゃくちゃアリですよ、ってことが言いたかったんです。

うん・・・

エンジニア就職したら立派なPCで開発できます！ｗ

さて、明日のアドカレはtamakiさんにバトンタッチです！

[kazumi-learning]

外貨の給料も計算できる「ペイレコ」をリリースしました

外貨の報酬がある人のためのかんたん給料計算ツールペイレコをリリースしました！

目次

自己紹介

作成したサービスについて

使い方

使用技術

苦労した点

最後に一言

自己紹介

kazumiと申します。フィヨルドブートキャンプというプログラミングスクールの受講生です。 キャリアチェンジを考えたことがきっかけで今年の1月中旬、未経験からプログラミング学習を始めました。

今回のブログはスクールの卒業課題として作成したWebサービス【ペイレコ】の紹介記事となります。

作成したサービスについて

サービスとリポジトリURL

サービスURL https://payreco.vercel.app

Backendリポジトリ https://github.com/kazumi3858/payreco-backend

Frontendリポジトリ https://github.com/kazumi3858/payreco-frontend

サービスの概要

ペイレコは「外貨の報酬がある人のためのかんたん給料計算ツール」です。 シフトを入力すると時給or日給額から給料計算をしてくれるツールは既にいくつかありますが、それらの既存サービスと異なる点は、外貨の報酬を日本円に換算して計算してくれるところです。

作ったきっかけ

私は海外の企業に登録をして仕事をしており、時給制で外貨の報酬を得ています。 毎日働いた時間を手帳にメモしておいて後日まとめて請求書ツールに入力しているのですが、これでは「現時点で今月いくら稼いだのか？」が分かりませんでした。

わざわざ為替レートを調べるのが面倒なので、「これくらいは稼いだだろう」といつも頭の中でおおよそのレートで計算していました。しかし想像していた月収より受け取った額が少なくて「あれ？」と思うことがよくありました。（最近は円安なのでその逆ですが）

そこで毎日為替レートを取得し、働いた時間を記録するだけで給料を日本円表示してくれるサービスを作成しました。 外貨の報酬がない方でも使っていただけますし、仕事のスケジュール帳代わりに使うこともできます。

使い方

まずはGoogleアカウントでログイン

トップページからGoogleアカウントでログインします。

勤務先を登録

勤務先情報を入力して保存します。 ユーザーの操作をなるべく減らすために入力項目はシンプルにしています。

勤務先の名前をクリックしてスケジュールを登録

先ほど登録した勤務先を選択して、仕事のスケジュールを登録します。

ここがこだわりなのですが、登録の際に「シフトの時刻を入力するか」「働いた合計時間のみを入力するか」ユーザーが選べるようになっています。

シフト制で働いている方の一般的なニーズを考えると、シフトの時刻を入力してスケジュール帳代わりにされたい方が多いと思います。そのためシフトの時刻と休憩時間を入力して給料が計算できるようになっています。

一方で私自身の勤務はシフト制ではありません。好きな時間に働いて、働いた時間の分だけ報酬がもらえます。 そのため働いた合計時間だけを入力してサクっと給料計算できるような仕様も加えました。

給料は日本円表示で確認

スケジュール登録後はすぐに日本円の給料が表示されます。 また、別ページでは今月稼いだ金額と年間稼いだ金額を確認できるようになっています。

使い方の説明は以上です。

使用技術

以下の技術を使用しました

Next.js 12.2.5

TypeScript 4.7.4

Rails 7.0.3.1 (APIモード)

フロントのAPI関連のコードはorvalというnpmを使ってOpenAPI仕様書から自動生成しております。TypeScriptの型も自動生成されるので保守性の高いコードが生まれます。

認証機能はFirebase Authenticationを使用しています。リスエストをする度にバックエンドでトークン検証を行うので安全に使っていただけます。

cssはtailwindを使っています。

テストはRspec・jest・cypressを使いました。コンポーネントテストではmswを使ってAPIをモックしています。

ほとんどが初挑戦でした

フィヨルドブートキャンプではRails + Vue.js(MPA方式)の学習がメインでテストはMiniTestを使っていたので、今回使用した技術はほとんどが初挑戦でした。

7月の終わりごろから技術検証や技術選定を開始し、8月の中旬ごろからReactやTypeScriptの学習を始めました。 9月頃からjestとcypressを触り始め、9月下旬にtailwindを学びました。 短期間で色々な技術を詰め込みすぎたため、まだどの技術も使いこなせているというわけではありませんがなんとか1人でサービスを作ることができました。

自分ではすごく成長したように感じています。

苦労した点

OpenAPIに苦戦

OpenAPIについて勉強しようと思ったのですが、仕様書の例を見ても全く書き方が分かりませんでした。正直ステータスコードが何なのかも分かっていませんでした。

最初は海外のエンジニアの方のYoutube動画を見て真似をして仕様書を書いてみました。しかしステータスコードもモデルの定義も誤りがひどくて修正ばかりしていました。

おそらくOpenAPIのymlファイルは50回以上作り直してると思います。ymlファイルを作り直す度にAPI関連のコードを再生成して・・・悲惨なことになっていました。

Firebase Authenticationの導入が難しい

Firebase AuthenticationによるGoogle認証機能の導入が大変でした。 実装も少し難しいのですが、それよりも「トークンってどうやって検証するの？JWTって何？」「フロントエンドからバックエンドへの連携をどうやるの？」といった仕組みの部分を理解することができませんでした。

時間をかけて認証機能を実装することはできたのですがその後もFirebaseには苦しみました。例えばmswを使ってモックデータを取得できずにドハマりしていたのですが、実はFirebaseをモックしていなかったことが原因だったり、ハマりポイントの先にいつもFirebaseがいました。

精神が鍛えられた

逆に言うとOpenAPIとFirebase Authentication以外ではあまり躓くことがなくスムーズに実装できました。

React側の状態管理にはreact-queryを採用しましたがとても簡単にAPIをリフェッチできるのでお気に入りです。 RailsはAPIモードを初めて利用しましたが債務がAPIのみ、というのはシンプルで良いなと思いました。 また、tailwindを初めて使ってみてその簡単さに感動しました。

分からないことが多すぎて大変な時期もありましたが、どうにか自力で解決してきました。この経験のおかげで元々強かったメンタルが更に鍛えられたような気がします。

最後に一言

初めてWebサービスを1人で作ってみて驚いたのは、サービスを作ることでこんなに知識が増えるのか、という点です。

スクールのチーム開発プラクティスのおかげで少しだけ開発体験はあったのですが、その頃はまだ「APIって自分で作るものなの？」「ヘッダーって何？レスポンスって何？」というレベルでした。 今ではAPIのことはもちろん型定義やステータスコード、CORSなど様々なことが理解できるようになりました。新しいフレームワークを学ぶことに抵抗もありません。

改めて、フィヨルドブートキャンプのプラクティスはどれもやりがいがあるなと思いました。

9か月間楽しく学習に取り組めたので周りの皆さんにとても感謝しています。ありがとうごさいました。 そして他の受講生の皆さんの卒業を応援しています！

ペイレコ トップページはこちら

[kazumi-learning]

フィヨルドブートキャンプのプラクティスの感想

フィヨルドブートキャンプのプラクティスの感想を書いていきます。

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

フィヨルドブートキャンプは私が受講していたオンラインのプログラミングスクールです。 卒業するまでにRuby on RailsやVue.js等の技術を学びます。

私は知人に紹介されるまで存じ上げなかったのですが、どうやらRailsエンジニアの方々の間では有名なスクールのようです。 受講生の中にはプログラミング経験者の方もいらっしゃいますが、私を含め未経験者の方が圧倒的に多い印象です。

フィヨルドブートキャンプのプラクティスの内容は一般公開されており以下のURLから確認いただけます。私は発展編以外のプラクティスを終えて卒業生扱いになりました！

https://bootcamp.fjord.jp/practices

最初にお断りしておきますが、このブログ記事は「受講生にプラクティスを乗り越えるTipsを伝えたい！」というキラキラしたものではございませんｗ

ただ「このプラクティスきつかったなー！これは面白かったなー！」と、私が言いたいことを言うだけの自己満記事でございます。

初期のプラクティスLinux、Git、Ruby、あたりの感想

Linux

Linuxが何なのかすら知らなかった私ですが基本的なコマンドはすぐに覚えられました。 WSLを使っているのでWSL特有の仕様にちょこちょこハマることはありましたが、楽しく学習できたように思います。

「マウスを使わずにコマンドラインで操作するσ(ﾟ∀ﾟ )ｵﾚカコイイ・・・」という気持ちが芽生えました。

ただ、SSH接続は難しかったです！ 最初のほうのプラクティスの中では段違いで難しいのではないでしょうか。 SSH接続のついでにWSL内のIPアドレスを固定しようと思ったのですができませんでした・・・。

Git

GitやGithubの使い方を学びました。 最初の頃Git操作が怖くて怖くてたまりませんでした。 mainブランチ以外のブランチから新しいブランチを切ってしまってFile ChangedにPRに関係のないファイルを含めてしまうなど、初学者のGitミスあるあるは一通り経験した気がします。

さすがに最初の頃に比べたら慣れましたが今でもコンフリクトはちょっと怖いです。

Ruby

Rubyのプラクティスあたりから急激にプラクティスを提出することが楽しくなりました。 プログラムを作ること自体が楽しいのはもちろんですが、私はメンターさんからコードレビューをもらうのが嬉しくていつもわくわくしていました。 小学生の頃赤ペン先生からお返事くるのを待っていたのと同じような気持ちです（？）

それくらいメンターさんからのご指摘やアドバイスが的確で勉強になっていたんです。 メンターさんによってレビューされる時の視点やコメントの仕方が異なるのでそこも面白いなと思っていました。

メンターの皆さんに対して憧れの気持ちも強かったのでレビューを通して憧れの皆さんとコミュニケーションが取れるという点でモチベーションが上がっていました。

中期のプラクティスRails、JavaScript、Vue.jsあたりの感想

Sinatra

私が自作サービス以外のプラクティスで1番苦戦したのがこのSinatraです！ この頃の私にとってすごく難しかったです。 （他の受講生はあまりSinatra難しかった～と言ってる方がいないのですが何故でしょう？）

まずネットに参考になる情報がなさすぎる！ 調べようと思っても情報がないのでいつまで経っても分からない！

とにかく苦しみながら作業していました。やっと完成したメモアプリは愛着が湧きますね。

Ruby on Rails

Railsのプラクティスを終えた時の感想は「全くRailsのこと分かっていないままプラクティスが終わってしまった！これでいいのか！？」でした。

プラクティスを終えるための超必要最小限の知識は身に付いたけど、それ以外は全く分からない、それどころかプラクティスで必要だった知識すらもきちんと理解できているか怪しいレベルでした。

そう、Railsは初学者のようにプログラミング経験がほとんどない方でもちょっとあーしてこーすればアプリが作れてしまう恐ろしい素晴らしいツールだったんです。

本当にこのまま次のプラクティスに進んで良かったんだろうか、という気持ちが強かったですね。

オブジェクト指向(ruby)

オブジェクト指向は全く意味が分かりませんでしたｗ クラスに良い感じの名前を付けて関連するメソッドを振り分けることをオブジェクト指向と呼ぶんだと思っていました。

メンターさんからのレビューでオブジェクト指向とはどういうものかを教えていただいたのですが全く理解ができず・・・ 初めてメンターさんにペアプロをしていただきました。（このペアプロが私にとっては最初で最後の1回でした）

ペアプロを経てオブジェクト指向の概念は理解できたのですが自分でオブジェクト指向に沿ったコードを作るのはとても難しいなと思いました。

JavaScript

JavaScriptはRubyと比べるとコードが読みづらいため最初は苦手意識がありました。 しかしやればやるほどRubyと似ているかも、ということに気付きました。例えばconstructorってinitializeメソッドじゃない？とか、thisってインスタンス変数じゃない？のように。 もしかしたら全てのプログラミング言語は似ているのかもしれないなと思いました

JavaScriptのメモアプリは苦手なクラス設計が含まれていたのでメンターさんに「厳しめにご指摘ください」とお願いしていました。 ものすごく勉強になるレビューをいただき、少しだけオブジェクトを作る意味が分かったのはこの頃です。

Vue.js

素のJavaScriptに比べてとても便利だなと思いました。 1つのファイルにhtml/cssを記述できるのが画期的で面白かったです。そしてv-modelが便利！ メモアプリのプラクティスではcomputedの挙動がよく分からずにハマっていました。 ハマり倒すとVue.jsのライフサイクルが少しづつ分かるようになって面白かったです。

後期のプラクティス チーム開発、自作サービス

チーム開発

多くの受講生が1番楽しかったと言っていたのがチーム開発のプラクティスです。 フィヨルドブートキャンプの名物ですね。

実は、個人的にはチーム開発の思い出はそんなに残っていないんですよね。 というのもこの後に言及する卒業制作の「自作サービス」が大変すぎて、チーム開発での思い出は全て忘れてしまいましたｗ

ただ、「kazumiさんのレビューがすごい」というお話を私のいないところでしてくださっていたようで、それを聞いてとても嬉しかったことは覚えています。

チーム開発では私が担当したイシューはそんなに難しいものがなかったので、予定よりも大分早く終わりそうだったんです。 しかし早くチーム開発を卒業してしまうと残ったチームメンバーのレビューをほとんどしないまま終えてしまうことになり、それが申し訳ないなと思いました。 そこでDiscordチャンネルでレビュー依頼の募集を始め（笑）、しばらくレビューに専念する期間を作ってみました。

募集したおかげで沢山のレビューを経験することができて勉強になりました。

自作サービス

最後が集大成となる自作サービスのプラクティスです。 当初「1ヵ月くらいでできそうだな。ゆっくりやって1ヵ月半くらいか。」と思っていたのですが2か月半かかりました。 想像以上に大変でした！！！

何故大変だったかというと、新しい技術を詰め込みすぎましたｗ フィヨルドブートキャンプの過去のプラクティスで勉強してきたのはRuby on Rails、JavaScript、Vue.js、Minitestです。チーム開発でもRailsとVue.js(MPA方式)のアプリを作っていました。

そして自作サービスで新しく取り入れた技術は、React(Next.js)、TypeScript、OpenAPI、Firebase Authentication、tailwind、RSpec、jest、cypress、mswです。 Railsも初めてのAPIモード。

実装も大変だったのですがそれ以上にFirebase AuthenticationとOpenAPIの基礎部分の学習がきつかったです。

それまで仕事を1日3～4時間しながら学習をしていたのですが、自作サービスに入ってからは仕事をする余裕がなくなってしまいました。 1日1～2時間だけ働いて残りの全ての時間を自作サービスに注ぐようになりました。 9月は1日12時間作業する日もあったりと、かなり自分を追い込んでいましたｗ

先に就活をする受講生は自作サービスを作らないまま卒業することもあるらしいのですが、私は自作サービスを作って本当に良かったなと思います。 何故かというと、自作サービスを作る前と後とで、自分の技術力に対しての自信が大きくアップしたからです。 「Railsのこと何も分かっていないのにどうしよう」と思っていたあの私が、こんなにもRailsの事を理解できる日が来るとは。

とはいえ、まだまだ初学者レベルです。 これからプロのエンジニアを目指す私にはまだまだ知識が足りないと感じています。 というわけで、スクールを卒業したけれどこれからも新しいことを積極的に学ぶ姿勢は変えずに頑張ります。

[kazumi-learning]

fly.ioを使ってRailsアプリをデプロイした時の手順

fly.ioでデプロイ

スクールの卒業課題として自作サービスを作成しておりデプロイ先を探していました。 fly.ioというサービスに無料枠があって気軽に利用できそうだったので試しに使ってみることにしました。

今回のブログ記事はデプロイ時の手順メモとなります。

私の環境

WSL(Debian)

RailsアプリはAPIモード

まずはインストール

手順は全て公式サイトに書いてあるのでまずはそちらを確認してください。

最初にflyctlをインストールします。

$ curl -L https://fly.io/install.sh | sh

インストールすると以下のメッセージが表示されました。

# 省略 flyctl was installed successfully to /home/kazumi/.fly/bin/flyctl Manually add the directory to your $HOME/.bash_profile (or similar) export FLYCTL_INSTALL="/home/kazumi/.fly" export PATH="$FLYCTL_INSTALL/bin:$PATH" Run '/home/kazumi/.fly/bin/flyctl --help' to get started

上記案内の通りexport FLYCTL_INSTALL="/home/kazumi/.fly" export PATH="$FLYCTL_INSTALL/bin:$PATH"を.bash_profileに記述するとパスが通りました。

次にサインアップ

サインアップコマンドを実行します。

$ flyctl auth signup

するとブラウザが立ち上がり登録画面が表示されます。 EmailまたはGithubアカウントを使って登録しましょう。 クレジットカードの登録は必須ではなく、カード情報の記入無しでfreeプランを開始できます。

サインアップすると以下のメッセージが表示されました。

Waiting for session... Done successfully logged in as （自分のメールアドレス）

ログインコマンドはflyctl auth loginです。

起動前の設定を行う

lauchコマンドを使って設定ファイルを生成していきます。 質問がいくつか出てくるので回答します。

$ flyctl launch # 質問が出てくるので答える ? App Name (leave blank to use an auto-generated name): アプリ名を入力 ? Select region: nrt (Tokyo, Japan) ? Would you like to set up a Postgresql database now? Yes ? Select configuration: Development - Single node, 1x shared CPU, 256MB RAM, 1GB disk Monitoring Deployment 1 desired, 1 placed, 0 healthy, 0 unhealthy

無料枠で使えるリソースの説明

Our pricing is designed to let you run small applications for free, and scale costs affordably as your needs grow. Fly.io services are billed per organization. Billing is based on the resources provisioned for your app, prorated for the time they are up. Each organization includes enough usage to run small apps. Resources included for free: * Up to 3 shared-cpu-1x 256mb VMs * 3GB persistent volume storage (total) * 160GB outbound data transfer

引用元はこちら。

無料枠に収めるのであれば4番目の質問はSingle node, 1x shared CPU, 256MB RAM, 1GB diskを選ぶことになると思います。

DBが作成されるとDB情報が表示されます。

Creating postgres cluster {アプリ名}-db in organization personal Postgres cluster {アプリ名}-db created Username: postgres Password: {パスワード} Hostname: {アプリ名}-db.internal Proxy Port: {ポート番号} PG Port: {ポート番号} Save your credentials in a secure place -- you won't be able to see them again!

you won't be able to see them again! (この情報はもう二度と見られんぜよ)と、怖いことが書いてあるのでこの情報はどこか安全な場所に保存しておきましょう。

launchコマンドで生成されたファイルは以下の4つです。

.dockerignore

Dockerfile

fly.toml

fly.rake

デプロイコマンドを実行する

deployコマンドを実行します。

$ fly deploy

以上の手順でデプロイは完了です！ アプリをブラウザで確認する時はこちらのコマンドになります。

$ flyctl open

エラーにハマった

RailsはAPIモードでの利用だったため、lib/tasks/fly.rakeの7行目task :build => 'assets:precompile'の=> 'assets:precompile'部分を消さないとデプロイができませんでした。

# ここを task :build => 'assets:precompile' # こうした task :build #=> 'assets:precompile'

APIモードの場合必要ないはずのassets:precompileがbuild時に実行を試みるためエラーになっていたようです。 この点に関してはネットに全く情報がないので正しい解決策かどうかは分かりかねます。

より適切な方法があれば教えていただきたいです。

[kazumi-learning]

自作サービス制作過程その1

プログラミングスクール フィヨルドブートキャンプの卒業課題として自作サービスを作ります。出来上がるまでの過程をちょこちょこブログで報告していこうと思います。

自作サービスで作るもの

作るものは「勤務時間管理・給料計算ツール」です。 スマホにあるシフト管理アプリと似たようなサービスと言ったほうが想像がつきやすいかもしれませんね。

よくあるシフト管理ツールとの違いは外貨対応する点です。

なぜなら私自身がいま時給制かつドル払いの仕事をしており、「現時点で私は日本円でいくら稼いでいるのだろう？」と、収入が分からないまま仕事をしていたからですｗ （請求ツールを開いて更にレートを調べるのがめんどくさいので調べてませんでしたｗ）

そこで働いた時間を記録していくだけで稼いだ金額を日本円表示してくれるツールを作ることにしました。

既存のスマホのシフト管理アプリは入力がしづらいなと思う点がいくつかあるのでスムーズな操作ができるサービスを目指しています。

どの技術を採用するか問題

今直面しているのが「どの言語、どのフレームワーク、どのライブラリ」を使うかという点です。

ちなみにこれまでにプログラミングスクール フィヨルドブートキャンプで学んできた技術の一部は以下です。

Ruby

Ruby on Rails

JavaScript

Vue.js

そして今回私が新たに取り入れようとしている技術が以下です。

React

TypeScript

OpenAPI

Firebase

うん・・・

大丈夫なのかねｗｗｗ 新しいことを沢山やろうとしていますｗ

Vue.jsではなくReactを選んだ理由は私が気になっている企業がReactを使用していたからです。 少しづつReactについて調べているのですがVue.jsよりも学習しやすいように感じています。

短いですが今回の報告はここまで。 スクール卒業と就職に向けて頑張ります。

[kazumi-learning]

ターミナル用24-bitカラーコードを確認できるnpmを作りました

自作npm mojicolorを作りました

ターミナルのコマンドライン（CLI）で気軽に使えるnpm mojicolorを作りました。 こちらは24-bitカラーコードを色別でグラデーション表示してくれるツールです。

利用方法

以下のURLにインストール方法を書いているので是非ご覧ください。

npm https://www.npmjs.com/package/mojicolor

github https://github.com/kazumi3858/mojicolor

注意事項

24-bitカラーコードとは言っても、ターミナルで実際に利用できる色は限られている場合が多いです。 （そのため多くのグラデーションを再現することはできませんでした。悔しいけど。） もしご利用のターミナルでそのカラーコードが見つからない場合は似た色が表示されるようになります。

なぜこのnpmを作ろうと思ったのか

以前からコマンドラインプロンプトの文字色が可愛くないから変えたいな～と思っていました。 ですがターミナルのカラーコードをネットで検索しても一般的な8色、または256色の情報しか出てきませんでした。

特に気に入った色が見つからないのでコマンドラインプロンプトの文字色変更も諦めていました。

しかししばらくして、 私が入会しているプログラミングスクール（フィヨルドブートキャンプ）の課題で自作npmを作ることになりました。

そこで「そういえばコマンドラインプロンプトの色変えたいんだった！そのために自分で24-bitカラーコードを簡単に確認できるnpmを作ろう！」と思い立ったわけです。

スクールの課題とはいえ自分の欲しいものを自分で作る体験ができたので良かったです。

[kazumi-learning]

JavaScript Standard Styleのインストール手順【リンター・フォーマッター】

JavaScript Standard Styleとは？

JavaScript Standard StyleはJavascriptで書いたコードを綺麗に整形したりエラーを発見してくれるツールのことです。

詳しくは公式サイトをご覧ください。

インストール手順メモ

私の環境

WSL2 (Debian) テキストエディタにVS code使用

グローバルにインストールしてみた

公式サイトにも書いてあるように、JavaScript Standard Styleはグローバルにインストールするかローカルにインストールするかを選べます。

私はグローバルにインストールすることにしました。 以下のコマンドを打ち込みます。

$ npm install standard --global

これだけでインストールか完了しました！ standardコマンドでプログラムをチェックしてくれるようになります。

試しに事前に作ったFizzBuzzプログラムでstandardを使ってみました。

$ standard fizzbuzz.js standard: Use JavaScript Standard Style (https://standardjs.com) standard: Run `standard --fix` to automatically fix some problems. /work/js/js-practices/01.fizzbuzz/fizzbuzz.js:2:19: Expected '===' and instead saw '=='. (eqeqeq) /work/js/js-practices/01.fizzbuzz/fizzbuzz.js:3:28: Extra semicolon. (semi) /work/js/js-practices/01.fizzbuzz/fizzbuzz.js:4:25: Expected '===' and instead saw '=='. (eqeqeq) /work/js/js-practices/01.fizzbuzz/fizzbuzz.js:5:24: Extra semicolon. (semi) /work/js/js-practices/01.fizzbuzz/fizzbuzz.js:6:25: Expected '===' and instead saw '=='. (eqeqeq) /work/js/js-practices/01.fizzbuzz/fizzbuzz.js:7:24: Extra semicolon. (semi) /work/js/js-practices/01.fizzbuzz/fizzbuzz.js:9:24: Extra semicolon. (semi)

ちゃんと問題点を指摘したコメントが表示されました！

VS codeでも使えるようにする

Visual Studio Code上でもJavaScript Standard Styleを使ってプログラムをチェックしてくれるようにします。

まずはVS codeを起動してctrl + Pを押し、以下をコピーして貼り付けます。

ext install standard.vscode-standard

これで拡張機能がインストールされました。

デフォルト設定はローカル環境でインストールされた状態で動作するようになっています。 私のようにグローバルにインストールした場合はsetting.jsonに追記します。

"standard.usePackageJson": false, // プロジェクトのpackage.jsonの設定を使う場合はtrueにする "standard.enableGlobally": true

これでVS code上でリアルタイムでプログラムをチェックしてくれるようになりました。 詳しい設定はこちらをご覧ください。

[kazumi-learning]

WSL2 Debianでrails test:systemを使えるようにするメモ

WSLでシステムテストができない

私の環境

Windows11 WSL2 Debian

rails test:systemを実行するとエラーに

rails test:systemを実行すると以下のエラーが出ます。

rails aborted! Webdrivers::BrowserNotFound: Failed to find Chrome binary. （中略） Tasks: TOP => test:system (See full trace by running task with --trace)

解決方法

Chromeをインストールします。

wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb sudo apt install ./google-chrome-stable_current_amd64.deb

application_system_test_case.rbファイルを以下のように編集します。

（:selenium_chrome_headlessが重要です）

require 'test_helper' class ApplicationSystemTestCase < ActionDispatch::SystemTestCase driven_by :selenium_chrome_headless end

これでrails test:systemが実行できるようになりました！

参考： https://u1tnk.github.io/blog/2021/06/28/wsl2_rails_test_system_config/ https://qiita.com/skuroki@github/items/ca4b8b172723955e2eeb

[kazumi-learning]

なぜポリモーフィック関連はSQLアンチパターンなのか

railsの学習中に「ポリモーフィック関連はSQLアンチパターンである」ということを知りました。

そもそもポリモーフィック関連とは？

railsガイドより引用しました。

「ポリモーフィック関連付け（polymorphic association）」は、関連付けのやや高度な応用です。ポリモーフィック関連付けを使うと、ある1つのモデルが他の複数のモデルに属していることを、1つの関連付けだけで表現できます。たとえば、写真（picture）モデルがあり、このモデルを従業員（employee）モデルと製品（product）モデルの両方に従属させたいとします。この場合は以下のように宣言します。・・・（後略）

複数のテーブルに対してあるテーブルを関連付けしたい時に使うんですね。

SQLアンチパターンとは？

アンチパターンは不適切な解決策を意味します。 つまり、SQLアンチパターンとは「SQLを扱う際にこんなことはしちゃだめですよ」というパターンのことですね。

SQLアンチパターンは複数あるのでぜひ調べてみてください。

ポリモーフィック関連はなぜアンチパターンと呼ばれているのか

本題に入ります。

私は「ポリモーフィック関連めちゃくちゃ便利じゃん！なんでアンチパターンなの？」と思い調べました。

すると「外部キー制約を付けることができないから」という答えがいくつか見られました。

ふむふむ・・・ でもなんで外部キー制約を付けられないことがマズいの？

そこが全く理解できず嘆いていたところ、フィヨルドブートキャンプのメンターさんに教えていただきました。

ポリモーフィック関連のように外部キー制約がない場合、SQL側でデータの書き換えができてしまうそうです。

例えば、ポリモーフィック関連では参照先_type 参照先_id、2つ揃ってようやくデータを引っ張り出せるわけですが、SQL側で参照先_typeが書き換わってしまうということが起こりえます。参照先_idだけ残っていてもどのテーブルのことを示しているのか分からずデータが取り出せません。

一方で、外部キー制約が付いているデータは書き換えようとするとエラーが出ます つまりデータの整合性を守ってくれるのです。

外部キー制約ってすごいのね・・・。

[kazumi-learning]

最近のプログラミング学習状況

学習から70日以上が経過

プログラミングスクール フィヨルドブートキャンプに2022年1月中旬に入会し、学習開始から70日以上経ちました。

全くのプログラミング初心者だった私がこの70日でできるようになったことはこんな感じです。

Linuxの操作（CUI）ができるようになった

WindowsにWSLをインストールし、仮想のLinux環境で学習をしています。 最初はコマンドもcdやpwdくらいしか覚えられなかったのですが、最近はちょっと便利なtreeなども使うようになりました。

「このコマンド本当に実行していいのかな？」「これインストールするの怖い」といった不安も徐々になくなってきました。

rubyで簡単なプログラムを書けるようになった

フィヨルドブートキャンプの課題をこなしていただけですがrubyで簡単なプログラムを作れるようになりました。 自分で1番よくできたな～と思うのはrubyでwcコマンドを実装する課題でしょうか。

メソッドの作り方とかクラス分けとかはまだあまり理解できていませんが、ロジックを考えるのは以前より上手くなった気がします。

Gitのことが少し分かった

正直Gitの操作は怖いですｗｗ

です���少しづつブランチを作る意味であったりコミットを重ねる意味を理解してきました。

今は個人のレポジトリにプッシュするだけなので良いんですが、チーム開発のレポジトリに触れるのはめっちゃ怖いです。（いつチーム開発できるかは分からないけど）

初心者向け向けのGit本を買ったので読みたいと思います。

VScodeをそこそこ使いこなせるようになった

テキストエディタはVScodeを使用しています。 VScodeめちゃくちゃ良いですね・・・好きです！！

1番のお気に入りポイントはVScode上でWSLに接続できるところです。便利すぎる！

学習で感じたあれこれ

フィヨルドブートキャンプの課題をこなしていく中で強く感じたのは「自分は本を読むのがとても苦手だ」ということｗ

コードを書く課題は夢中になってできるんだけど、本を読む課題は中々進まないｗ 昔から本を読むことにあまり興味を持てずほとんど本を読まずに歳を重ねてきたからな～。

それでも新しい知識を得ることは嬉しい！

今後の楽しみ

今後の学習の楽しみはJava Scriptですかね。正直Java Scriptが何なのか全然分からないんですけど（ホームページに動きをつけるってことは分かるけど）、気になる！

私はHTMLとCSSが好きだから絶対Java Scriptも好きになれる！（と思う）

引き続きコツコツ勉強がんばります。

[kazumi-learning]

HTML･CSSの便利なチェックツール

HTMLのインデント整形ツール

Syncer

https://lab.syncer.jp/Tool/HTML-PrettyPrint/

コピーしたコードを貼り付けるだけでインデントを揃えてくれます。 インデント数も指定できるので便利です。

HTMLのエラーチェックツール

W3C

https://validator.w3.org/#validate_by_input

コピーしたコードを貼り付ける、ファイルを選択する、URLを入力する、のどれかを行うとエラーチェックしてくれます。

CSSのエラーチェックツール

W3C

https://jigsaw.w3.org/css-validator/#validate_by_input

コピーしたコードを貼り付ける、ファイルを選択する、URLを入力する、のどれかを行うとエラーチェックしてくれます。 HTML版と違って日本語表示なので分かりやすいですね。

コードを書いた後はこれらのツールでチェックするクセをつけたいです。

[kazumi-learning]

【Ruby】ARGV.getoptsは実行2回目以降、中身が消える？

前回のブログ記事でARGV.getoptsを使うとコマンドラインのオプションを受け取った処理が書けるとお伝えしました。

そのARGV.getopts使用時の注意事項です。 （こちらの情報は私が入会しているフィヨルドブートキャンプのメンターさんに教えていただきました）

1回処理を実行すると中身が消える？

言葉で説明するよりも実際に見ていただいたほうが分かりやすいと思うので簡単な例を用意しました。

# test1.rb require 'optparse' def test @option = ARGV.getopts('a') # オプションaを受け取るようにする end p test # 1回目の実行 p test # 2回目の実行

# 実行結果 $ ruby test1.rb -a {"a"=>true} # 1回目の結果 {"a"=>false} # 2回目の結果

コマンドラインのオプションを受け取るためのtestメソッドを作って、そのメソッドを2回実行してみました。

すると実行結果のように、1回目は{"a"=>true}ですが2回目は{"a"=>false}になっています！

どうやらARGV.getoptsで受け取ったものは1度実行されるとなくなってしまうようです。これは知りませんでした！

解決方法は ||= を使って変数を初期化する

解決するためには||=（自己代入演算子）を使用します。||=は、左辺がfalseまたは未定義の時に右辺を代入します。

# test1.rb require 'optparse' def test @option ||= ARGV.getopts('a') # 自己代入演算子に書き換えた end p test p test

# 実行結果 $ ruby test1.rb -a {"a"=>true} # 1回目の結果 {"a"=>true} # 2回目の結果

これで2回目以降もちゃんとオプションを受け取れるようになりました。

[kazumi-learning]

【Ruby】コマンドのオプションを使った処理はARGV.getoptsで

オプションの有無を返す

例えばARGV.getopts("abc")と書くと、コマンドラインのオプションにa、b、cがあればtrueを返し、なければfalseを返します。

# test1.rb require 'optparse' results = ARGV.getopts("abc") p results

# 実行結果 $ ruby test1.rb -a {"a"=>true, "b"=>false, "c"=>false} $ ruby test1.rb -acb {"a"=>true, "b"=>true, "c"=>true} $ ruby test1.rb -ca {"a"=>true, "b"=>false, "c"=>true}

公式リファレンスを見ると、getopts(short_opt, *long_opt)のように1番目にショートネームオプション、あればその後にロングネームオプションを書くんですね。

オプションに引数がある場合

オプションに引数がある場合は:を直後に付けると良いです。

# test2.rb require 'optparse' results = ARGV.getopts("abc:") # cの後にコロン付けたよ p results

# 実行結果 $ ruby test2.rb -a -c 1 {"a"=>true, "b"=>false, "c"=>"1"}

活用方法

ARGV.getoptsを使った簡単なif文を作ってみました。

# test3.rb require "optparse" results = ARGV.getopts("a") if results["a"] # オプションaがtrueの時 puts "オプションaがあったよ" else puts "オプションがなかったよ" end

# 実行結果 $ ruby test3.rb -a オプションaがあったよ $ ruby test3.rb オプションがなかったよ

う～ん、便利！

【追記】注意点

ARGV.getoptsの注意点ですが、1回目と2回目の実行結果が変わってしまいます。 詳しくはこちらの記事をご覧ください。

[kazumi-learning]

Tumblrブログにhighlight.jsを導入

TumblrブログにはMarkdown機能がありますが、ソースコードを表示させてもシンタックスハイライトされません。

自分でhighlight.jsを導入

というわけで自分でこのブログにhighlight.jsを導入し、シンタックスハイライトを有効化させました。

やり方は簡単です。HTMLの編集画面で以下のコードを<head>タグ内に貼り付けるだけ。

<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.4.0/styles/base16/default.min.css"><script src="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.4.0/highlight.min.js"></script><script>hljs.initHighlightingOnLoad();</script>

default.min.cssの部分を変更することでハイライトの色（スタイル）を変えられます。 どんなスタイルがあるかは公式サイトをご覧ご覧ください。

[kazumi-learning]

【WSL2】開始ディレクトリをWindows側からLinux側に変更

デフォルト設定ではWSL起動時にWindows側のフォルダから始まる。

WSLをダウンロードしたあと、WSLの画面（私はDebian）を開いてみると

デフォルトでは開始ディレクトリが/mnt/c/Users/ユーザー名になっています。 これはWindows側のディレクトリ（フォルダ）です。

これをLinux側のホームディレクトリに変更します。

設定画面から変更可能。

まずは設定画面（私の場合はDebian）を開く。

設定画面の中の「開始ディレクトリ」が%USERPROFILE%となっているので\\wsl$\Debian\home\ユーザー名に変えて「保存」します。

（バックスラッシュが￥表示になるのはそういう仕様だからです。）

すると開始ディレクトリがLinux側のホームディレクトリ（チルダ~マークがホームディレクトリを表しています）になりました！

これによって起動速度が上がった気がします。（気のせいか？）

[kazumi-learning]

Sinatra実行時のServer handler not foundエラー

私の環境：Windows11 WSL (Debian : bash)

Server handler (thin,puma,reel,HTTP,webrick) not foundというエラーが出た。

Sinatraをインストールして実行しようとすると

Server handler (thin,puma,reel,HTTP,webrick) not found. (RuntimeError)

とエラーが出てしまいました。

どうやらthin,puma,reel,HTTP,webrickこの中のいずれかのgemをインストールしないとSinatraは使えないそうです。 （古いRubyのバージョンではデフォルトでwebrickが入っていたので問題なかったようです）

というわけで

gem install thin

thinというgemをインストール。 無事Sinatraが使えるようになりました。

[kazumi-learning]

Githubでプルリクエストを行う手順

Step1 リモートリポジトリをフォークする。

（※すでにフォーク済みの場合はこのステップはとばします）

GIthubで該当のレポジトリにアクセスし、右上のフォークボタンをクリック。すると自分のアカウントにフォークされたレポジトリが生まれます。

フォークされたレポジトリページで「Code」をクリック。「HTTPS」に表示されるURL https://github.com/アカウント名/レポジトリ名.git をコピー。

Step2 フォークしたリポジトリをクローンする

（※すでにクローン済みの場合はこのステップはとばします）

自分のPCでターミナルを開き、リモートリポジトリをクローンしたいディレクトリに cd ディレクトリ名 で移動しておきます。

先ほどコピーしたURLを使って、git clone https://github.com/アカウント名/レポジトリ名.gitを実行。

これでPC上（ローカル）にリモートリポジトリがクローンされました。ls -lで確認するとレポジトリ名のついたディレクリができていますね。

Step3 作業用ブランチを作って作業する

作業したいディレクトリに cd ディレクトリ名 で移動します。

git checkout -b ブランチ名 を実行し、作業用ブランチを作成＆そのブランチにチェックアウトします。

作業用ブランチにて何かファイルを作成してみましょう。vimを使用する場合はvi ファイル名で起動します。もちろん他のテキストエディタを使ってもOKです。

作業用ブランチを作るとき、何も指定しなければ現在いるブランチを派生元としてブランチが作られます。

mainブランチからブランチを作る場合はmainブランチに移動して git checkout -b ブランチ名 を実行。または git checkout -b ブランチ名 main のように派生元を明示します。

Step4 ファイルをコミットする（add→commit）

作ったファイルを git add ファイル名 でインデックスにあげ、git commit -m "コメント" でコミットします。

git status でファイルの状態を確認してみると「nothing to commit, working tree clean」と表示され、コミット済みであることが分かります。

Step5 プルリクエストをつくる

git push origin ブランチ名 でリモートリポジトリにプッシュします。

Githubのアカウント名とパスワード（トークン）を入力するとプッシュが完了します。

Github上に自動でCompare &Pull Requestボタンが現れるのでクリック。

プルリクエスト先を自分のフォークしたレポジトリに変更しておく。

（これは職場によってはそのままクローン元を選択しておくのかも？）

コメントを残して「Create Pull Request」をクリック。

以上です。