komagataのブログ

フィヨルドブートキャンプというプログラミングスクールで初めてのPRに対するレビューをたくさんやっています。これらの指摘は世界中で行われていると思うので無駄が減るように書きました。

Files changedを確認したか

真っ先に注意したい点。

ローカルの自分のエディタ上で確認していたとしても、PRを作ったら必ずFiles changedを確認する癖をつけよう。GitHubのソースコードビューワーの機能で色々と気づける点もある。

明らかにFiles changedを一回も見てないなというPRはレビュワーもそれと分かります。

lintを通しているか

rubyだったらrubocop、jsだったらeslint

どういうルールが良いかという高度は話題は置いておいて、まずはlintを通しているか否か。

ファイルの末尾に改行があるか

これ

どのエディターでも設定で自動的に入るようにできるので設定すること。

なぜ最終行に改行が必要なのか - komagataのブログ

同じコミットログが続いていないか

適切な文章などの高度な話題以前に明らかに適当になっている場合がある。コミットログというのはちゃんと見られるものだということを理解しよう。

コミットログが英語／日本語になってないか

プロジェクトのルールに合わせましょう。フィヨルドブートキャンプでは統一されていればどちらでもいいです。

コミットログが雑になってないか

modifyだけ、追加だけは後から見た人が困るので駄目。困る人には1ヶ月後の自分も含まれる。

コミットしたユーザーアイコンがOctcatになっていないか

gitクライアントに設定したemailアドレスがGitHubのユーザーのメールアドレスと違う場合にこうなる。

他のチームメンバーからすると「謎のアイコンの人がコミットしてる！」という見た目になる。

これをやると他のメンバーに「ああ、普段コード書いてない（GitHubを使ってない）人なんだな・・・」という生暖かい視線を浴びる羽目になる。

不要なファイルをコミットしてないか

.DS_Store（Macのみ）とかxxx~（viのみ）とかその人にしか必要ないファイルを含めてしまってないか。開発に参加するみんなに必要なものだけを含めるようにしよう。

無意味なファイルがないか

generatorが作成した無意味なファイルは削除しよう。実装のないmoduleとか、中身のないtest、fixturesとか。

「これはgeneratorが勝手に作成したんで」

といってファイルがカオスになってるプロジェクトは誰も触りたがらない。

一つ一つどんな意味を持っているのか調べよう。

gemのgroupが適切か

testでしか使わないgemがgroup無しで全groupで読み込まれている。必要なところだけにしよう。

不要なrespond_toがないか

jsonでアクセスする必要が無いのにscaffoldのコードをそのままで残っている。htmlだけが必要ならrespond_toやformatは削除しよう。削除するときにrespond_toとformatが何をやっているのか調べた上で消すのも忘れずに。

何でもリファクタリングと言ってないか

リファクタリングはプログラムの振る舞いを変えずに内部構造を変えることなので、ちょっとした修正という意味で使ってはいけない。

秘密の情報がコミットされていないか

oauthのsecretとか。コード中では環境変数にしておこう。

これをやると、gitで過去を修正したとしてもGitHubのキャッシュに残ってしまい、完全に消すにはGitHubのサポートに連絡するとか面倒なことになる。

チームメンバーが「やっちまったな・・・」という顔になる。

.gitignoreは適切か

.DS_Storeはmacだけのファイル。.ideaはJetBrainsのエディター独自のファイル。そういった特定の環境の人向けのファイルは.gitignoreに含めるべきじゃない。

プロジェクト毎の設定じゃなくて自分のマシン固有の設定に書くべき。

大量の依存gemがコミットされていないか

gemのインストール場所をvendro/bundleとかにしてあって、その中にある大量のgemのファイルがコミットされてしまっていないか確認すること。

ネイティブバイナリが含まれたgemもあるので環境によって違うので各自がインストールするものです。

マジックナンバーが無いか

これ。

マジックナンバー (プログラム) - Wikipedia

メソッドが長すぎないか

「1メソッドは五行以内に収めるべし」というSandi Metzルールというものがあります。

そこまで徹底しなくて良いですが、何十行もあるとさすがに見辛いので修正が必要です。

綺麗な設計を身に付けるためのSandi Metzルール | A-Listers

CIをパスする前にレビュー依頼をしない

自分は何にも変えてないから通るはずだと過信しない。

理解せずコピペしてないか

ググった内容を自分のコードに取り入れることは問題ありません。しかし、その内容を自分で理解せずそのまま使うのはよくないです。理解していないコードでは何が起きるか分かりません。

日本語の作文をするのに似た内容だからといって他の本からそのまま取ってきたら違和感のある文章になってしまうのと同じように、プログラムも変数名や構造を自分のプログラムに合わせずにそのまま使えることはほぼありません。理解しているプログラマーにとっては明らかに違和感のあり無駄のあるコードに見えます。

なので、

「自分の書いたこの部分が何をやってるか理解してる？」

と先輩に聞かれると言うことがよくあります。

意味を理解した上で自分のコードの文脈に合わせた内容に変えて使いましょう。

komagata: やめたほうがいい。

質問者: これこれこういういいところがあるのですが、いかがですか？

komagata: やめたほうがいい。

以下ループ。

ってことも多い。

komagata: やめたほうがいい。

質問者: これこれこういういいところがあるのですが、いかがですか？

komagata: やめたほうがいい。

以下ループ。

ってこと多い。

今年の弊社（合同会社フィヨルド）はアップダウンの激しい年でした。

今年前半は去年末にオフィスの引っ越し・リフォームでお金を使い過ぎてしまい、必死に仕事をしてました。

その後5月にプログラミングスクールのフィヨルドブートキャンプを有料化した後は順調に生徒数が増えて、会社のお金的には安定しました。

求人サイトを作りたい

2020年はプログラミングスクールの流れとしては「スキルはあるけど業務未経験の人」のためのエンジニア求人サイトを作ろうと思っています。

プログラミングをスクールなどで勉強してスキルは十分でも業務未経験というだけで足切りされてしまう場面が多いからです。

プログラミング未経験 + 業務未経験で採用してもらえないのは仕方ないです。勉強してくださいって話です。ただ、それとプログラミングを勉強してスキルを得た人が「業務未経験」という言葉で一括りにされるのは、求職者・企業の双方にとってもったいないとおもいます。

その求人サイトを見にきて、スキルも無いという人はぜひフィヨルドブートキャンプへという流れです😄

生活・働き方

フィヨルドに入ってからずっと自社サービスで食っていきたいと思ってやってきましたが、目標を達成しつつある今、自分はどういう働き方がしたいのか、どういう生き方がしたいのかを改めて考える必要があり、まさに今模索中です。

お仕事的には求人サイトを作った後も作りたいWebサービスは常にあるので作っていきたいです。生活の方ではどこか海外に長期滞在しながら働けないかなと考えています。

僕の趣味はプログラミングとゲームと最近は旅行です。夫婦で旅行が好きなので長期滞在含めて、海外多めでそこから仕事していく方法を模索しています。

まずは1月にマレーシアに行って様子を見る予定です。

Webプログラミング学習者にとってSessionという言葉は混乱を招きます。

特定の機能の名前であるSessionと英単語としてのSession（期間）がごっちゃになるからです。

経験者はコンテキストからどういう意味でSessionと言っているのかを判断しますが、学習者には区別がつきません。

人によって、初めてSessionという単語に出会う場面が違うため、Sessionの意味を聞いても自分が出会ったSessionとは違う意味を説明されたりします。一つ一つのわからない単語を調べていく真面目な人ほど混乱してます。

Sessionクラスというのがあったとして、誰でもそれだけでは何を意味してるのかわかりません。

英単語としてのSession

まずはSessionは英単語として 期間 という意味です。プログラミングの文脈では 一つの期間 ぐらいの意味で使います。この場合は特定の何かの機能を指しているわけじゃないので、別に仕様とかもありません。

HTTP Session

HTTPクライアントがRequestを送り、HTTPサーバーが処理を行った上でResponseを返す。この一連の処理をHTTP Sessionといいます。

これのことも単にSessionという場合があります。

WebアプリのSession機能

HTTPはステートレスなプロトコルなのでWebアプリは大抵何らかの状態を保持する機能を持っています。この機能のこともSessionといいます。

この機能はPHPの様に言語が持っている場合もありますが、基本的にはライブラリ・フレームワークがそれぞれ独自のものを持っています。（rubyだとrack）

このSession機能は内容の保存方法・場所を選べ、サーバーのファイルに保存したり、データベースに保存したり色々です。

特にこの保存場所がCookieであることがあるので、学習者の混乱は加速します😅

学習者としての覚え方

そのSessionが指しているのがHTTP SessionかWebアプリのSession機能なのかをまずコンテキストから判断しましょう。それ以外だったら大抵は英単語としてのSessionです。

Herokuミートアップ第0回〜第2回ぐらいにちょこちょこ登壇したり出席してるぐらいのHeroku好きな俺ですが、Herokuに月3万ぐらいかかってて、サービスには満足してるんですが、やっぱりTokyoリージョンじゃないと遅いのでAWSかGCPに移ろうかと検討してました。

最後にHeroku EnterpriseのPrivate Spacesを検討してみようとお問い合わせしてみました。

すると要するに最小プランでも月14万ぐらい + 現在のDyno料金アップ + 各種アドオン料金もアップということでした。（まずはお打ち合わせをなどのプレッシャーを回避しつつ聞いたところによると）

おそらくTokyoリージョンが使いたいためだけに使うものじゃないんでしょうね。

GCP行きます…

RubyMineのCode Styleとlintツールの設定がずれててイライラすることがあるのでこれは良い。

5.2系では読み込まれてたんだけど、6.0.1にしたらデフォルトでは読み込まれなくなってるみたい。zeitwerkになったからかしら。

手動でrequireすればOK。

require "active_record/fixtures"

class NotificationMailerPreview < ActionMailer::Preview
  def came_comment
    id = ActiveRecord::FixtureSet.identify(:report_5)

    # ....
  end
end

フィヨルドブートキャンプ卒業生の@shita1112さんと、10年近くの縁の@rono23と、僕、machidaさんで代々木上原のゆうに感謝のお礼ディナーに行ってきました。

@shita1112さんは愛知から代々木上原に引っ越して来られたのでその引越し祝いでもあるんですが、先日@shita1112さんが投稿したいくつかのブログ記事がバズって、それを見てフィヨルドブートキャンプに来たという人が沢山いたのでお礼と、

• プログラミングスクールで、「リアルバーチャルYoutuber」というWebサービスを作りました - 猫Rails
• プログラミングスクールの理想と現実。あとフィヨルドブートキャンプについて - 猫Rails

@rono23は今年僕がサンクトペテルブルクRubyConfに行っていた時にかわりにオフィスに来てメンターをやってくれたのでそのお礼です。

豚肉の何か。

牛肉の土鍋。

主に@shita1112さんは今年からフリーランスということで歴は長いが、働いている期間は短い@rono23を交えてフリーランスプログラマーとしてのサバイバル方法を話してました。

始める時ってそういう話助かりますよね。

「開発環境のユーザーのパスワードって何？」

みたいな情報の共有って面倒ですよね。any_login入れちゃうのがいいかも。

any_loginを入れると画面の左下にアイコンが出てきて、そこをクリックするとユーザーが一覧できるプルダウンメニューが出てきます。それを選択するだけでそのユーザーでログインできるというもの。

似た仕組みを用意してる人が多いとは思いますが、無いなら導入おすすめです。

igorkasyanchuk/any_login: Easy way to login as any user in system

認証ライブラリはDevise, Authlogic, Clearance, Sorceryなど色々対応してます。

フィヨルドブートキャンプのアプリに入れてみました。

fjordllc/bootcamp: プログラマー向けEラーニングシステム