フィヨルドブートキャンプをWindowsマシンでも受講できるようにしました。

WindowsではWSL2を使うためWSL2が動くマシン限定ではありますが。(最近のマシンならほとんどOK)

WSL2はかなり優秀で速度もMacと同じか速いぐらいです。僕の場合はMacより性能がいいWindowsマシンでの体感ですがHyper-Vのおかげか圧倒的にWSL2で動かしたRailsの方が速いです。

独自のinitに変えられてるなど若干の違いはありますが基本的に直接入れたLinuxと同じ感覚で使えます。むしろWindowsとの連携機能が多数あるので便利になってるところの方が多いぐらい。

ただ快適なのは経験者の方の話で、これから勉強を始める方にとっては若干敷居が高いので難易度的にはまだMacを一番オススメしております。

フィヨルドブートキャンプをやる上でのOS選び | FJORD BOOT CAMP(フィヨルドブートキャンプ)

まあプログラマーの実際の仕事ってのは純粋なプログラミングというよりこういう環境作りでの苦戦とか、何回ハマったか、バッドノウハウをいくつ知ってるか的なところがあるのでどのOSがいいのかと試行錯誤するのもいいとは思います。

スクールの内容をWindows対応にするのは意外と大変で、最初はMacのBoot CampでWindowsを入れてやってたんですが、色々と使いづらいところもあってWindowsマシンを買ってやりました。

Alienware x17買った - komagataのブログ

macとWSL2環境の違い(macとLinuxの違いも含む)は色々あって下記の連載を全部Windows+WSL2用に書き換えたりしました。

「本当は怖くない黒い画面」入門(Windows + WSL2編)

/binの中身を見てみる箇所があるんですが、macと違って/binがディレクトリじゃなくて1ファイルになってるので説明が難しくなっちゃったり、デフォルトのディレクトリが/mnt/c/Users/komagaになってたり(ホームディレクトリはまた別)、デフォルトシェルがmacはzshだけどbashだったり、経験者の人にとっては、

「あ~この辺違うのね」

で済む点でも初めて知る方にとっては複雑な経緯を回避して説明するのが難しです。まあmac用の教材を用意するときもLinuxとの違いで困ったのでどっちもどっちです。

未だに僕はM1 Macを持ってなくてトラブル時にはM1 Macを持ってるメンターの方に頼らせていただいてますが、次のMacBook Proが出たタイミングで購入してそちらの教材も作っていきたいと思います。

プログラミングスクールのフィヨルドブートキャンプを運営しています。

プログラミングに限らずですが、メンターの役割の人が、

「生徒の人から質問がきた時になぜすぐに答えを即答してくれないのか」

について書きたいと思います。

質問している人にとっては、「なんですぐ答えを即答してくれないんだよ、ヒントとかいいからさ。ウゼェ〜」と思っちゃうかもしれません。

そこでプログラミングのバグを殺人事件、バグの原因を犯人に例えて書いてみたいと思います。

プログラムが動かない殺人事件

新米プログラマー「このプログラムが動きません、なぜでしょうか?」

新米捜査官「この殺人事件の犯人がわかりません、誰でしょうか?」

ベテランプログラマー「15行目のiの変数が原因ですよ。」

ベテラン刑事「吉田が犯人だ。」

〜次の事件〜

新米捜査官「この殺人事件の犯人がわかりません、誰でしょうか?」

ベテラン刑事「おい!毎回俺に犯人を聞くつもりか?捜査の仕方を覚えろ!」

ベテラン刑事「まず関係者に事情聴取をしろ」

ベテラン刑事「そしてアリバイを調べろ」

ベテランプログラマー「まずエラーメッセージとログを確認してください。」

ベテランプログラマー「まずはprintデバッグをしてみましょう。」

犯人だけわかっても意味がない

多数の事件を経験してきても犯人だけ知ってるだけでは意味がありません。次の事件を解決できる捜査方法を知っている必要があります。

スクールで課題をやるのはそのためであって、答え自体に意味はありません。

あらゆる推理小説の犯人だけ知ってても推理することが出来ないのと同じです。

課題を通して(プログラミングの問題の)捜査方法を学び、習得することが目的です。

プログラミングの捜査方法

プログラミングの捜査方法を身につけるとは、下記を指します。

  • デバッグ方法を身につける
  • わからない情報の調べ方を身につける

それを学ぶにはまず基本的な用語・概念を学んでおく必要があります。

例えば、

「アリバイってなんですか?」

「事情聴取ってどうやってやるんですか?」

「警察が守るべき法律には何がありますか?」

などを知らないと捜査方法を学ぶことが出来ません。

プログラミングでいえば、

「Terminalの使い方」

「Linuxの使い方」

「HTTPの理解」

などがそれにあたります。

そして自走へ

基本的な知識と捜査方法を覚えればあとは自分で新しい事件を経験していけば一人で成長していくことが出来ます。

プログラミングでも同じです。常に新しい技術が出てくるので誰かに教わるのではなく、自分で技術を習得する必要性が出てきますが、基本知識と捜査方法さえ分かっていれば自分で調べて学んでいくことが出来ます。

フィヨルドブートキャンプというプログラミングスクールのEラーニングアプリをCloud Run + Railsで動かしています。

1ヶ月使ってみた結果、8,000円ぐらいでした。

Image from Gyazo

Cloud Runが300円でCloud SQLが7,000円って感じです。Cloud Buildとかちょこまかしたのはありますが誤差の範囲。

Cloud Runは1コンテナだったら1日10円ぐらいなんですよね。信じられないほど安い。

これでDockerイメージ放り込んでおけば自動スケールの環境が手に入るならほとんどの仕事のアプリはこれでいい気がします。パフォーマンスもいいし、これからのアプリは全部これで行こうと思います。

fjordcop作った - komagataのブログ

これをgemにしました。

rubocop-fjord

gemにした理由は、gistだと適当感があってこれにしたがってくださいと言い辛いからです。 メンテについては腹を括ったのでやっていきます。

とにかくエディタ論争とこういうルールについての議論をするのが辛い。

プログラミングスクールで使うことを念頭に置いているので他にも教育やスクールをやっている方には便利かも知れません。

group :development do
  gem 'rubocop-fjord', require: false
end

.rubocop.ymlにこう書く。

inherit_gem:
  rubocop-fjord:
    - "config/rubocop.yml"
    # - "config/rails.yml"

フィヨルドブートキャンプのレビューでいつも書いてることシリーズ。

基本的にはこちらのrisacanさんの内容と同じです。

コミットメッセージの書き方. 適切な情報を残そう | by risacan | Medium

この内容から下記の二つを引いた感じです。

  • 先頭を必ず絵文字ってのは基本の考えとしてはない方が良さそう(プロジェクトで決めてこれを採用するのは全く問題ない)
  • 最初だけ英語ってのは全体を英語か日本語に統一した方が良さそう。

ずっと残るものだからあまり流行に左右される書き方はしない方がいいかなと思います。

また、あまりシステマチックなルールにするとコミットメッセージの基本である「何を考えて書いたのをわかりやすく説明する」という姿勢が弱まっちゃいそうだなという思いもあります。

フィヨルドブートキャンプでメンターとしてレビューしているときに、rubocopのカリキュラム以降は提出するコードをrubocopを通してから提出するようにお願いしています。

しかし、デフォルトのrubocopだと不便なところがあったのでfjordとしての設定を作りました。

方針は下記の2点です。

  • なるべくrubocopのデフォルトに従う。
  • rails newしたコードで指摘されまくるなど、流石にこれは厳しいという点のみ外す。

gistに置いたので下記のように書けば使えます。

.rubocop.yml:

inherit_from:
  - https://gist.github.com/komagata/9ad19373b9f9059ca52e727fbb7f2944/raw/e3a9bf5db5459a8172f634a677f7dccae66df060/ruby.yml
  - https://gist.github.com/komagata/9ad19373b9f9059ca52e727fbb7f2944/raw/e3a9bf5db5459a8172f634a677f7dccae66df060/rails.yml

require:
  - rubocop-minitest

Fjord rubocop configuration.

ruby用とrails用に分かれているのでrailsを使わない場合はそちらを読み込む必要は無いです。

それぞれgistのrevisionでURLが変わるので更新するには最新のURLを見に行って書き換える必要があります。

フィヨルドブートキャンプでメンターとしてコードレビューをしています。自由な形式でプログラムを書く課題の場合、やはりオブジェクト指向プログラミングにみなさん苦戦しているようです。

特に、オブジェクト指向プログラミングのイメージが掴めないと、

「何をクラスメソッドにして何をインスタンスメソッドにすればいいのか」

がわかりません。(みんなここで詰まっている)

なので、これを説明するのはものすごく難しいんですが、挑戦してみます。

(クラスを定義する記法や使い方はRuby超入門などで読んだという方を前提とします。)

クラスとインスタンス

クラスインスタンス鋳型実体 だと考えてください。

鋳型とはこういうやつです。

Image from Gyazo

タイヤキの鋳型はタイヤキそのものとは別のものですが、その鋳型からできる全てのタイヤキの形を決めています。

Image from Gyazo

Person(人)クラスで考えてみます。

Person(人)というものは現実の世界にはいません。実際にいるのは駒形、町田といった人の実体です。哺乳類という動物がいないのと同じです。実際にいるのはポチやタマです。

Personにはname(名前)やage(年齢)といった属性がありますが、「そういう属性があるよ」ということは共通していますが、実際の名前はそれぞれ実体によって違います。

クラス変数とインスタンス変数

そうやって考えてみると、変数に関してはクラス変数(もしくは定数)とインスタンス変数のどちらにすべきか自然とわかると思います。

例えば「目の数」という属性はPersonに共通する内容なのでクラス変数(もしくは定数)がふさわしいです。「性別」という属性はインスタンスによって違うのでインスタンス変数がふさわしいです。

クラスメソッドとインスタンスメソッド

全てをクラス変数とクラスメソッドで処理するというのは手続き型プログラミングの世界です。

関数(メソッド)は極力引数の情報だけで処理が完結すべきというのは関数型プログラミングの世界です。

オブジェクト指向プログラミングでは、極力「インスタンス変数を使ってそのインスタンス自身に処理させる」というのが基本です。

例えばself_introduce(自己紹介する)というメソッドを作る場合、それぞれこうなります。

手続き型プログラミング:

class Person
  def self.name=(name)
    @@name = name
  end

  def self.self_introduce
    puts "I'm #{@@name}."
  end
end

Person.name = "komagata"
Person.self_introcude

関数型プログラミング:

def self_introduce(name)
  puts "I'm #{name}."
end

self_introduce("komagata")

オブジェクト指向プログラミング:

class Person
  def initialize(name)
    @name = name
  end

  def self_introcude
    puts "I'm #{name}."
  end
end

komagata = Person.new("komagata")
komagata.self_introduce

どれが良い悪いというのはないですが、オブジェクト指向プログラミングは最後のスタイルです。

極力、実体(インスタンス)が個別に持つ情報を利用してインスタンスメソッドを呼び出して処理する。そういう書き方が基本です。

例えば「人を探す」というメソッドがあった場合、(なんらかの人物が他の人物を探すとかでない限り)特定の実体には関係がないのでクラスメソッドが適しています。

class Person
  def self.find(name)
    # 探して新しいPersonインスタンスを返す
  end
end

実際は実装上の都合やテクニックが加わってくるのでこれに当てはまらない場合もありますがあくまで基本の考え方はこれです。

Image from Gyazo

フィヨルドブートキャンプでリアクションにGitHubにもあるアイコンに独自に少し追加したんですが、プログラミングスクールとしては💪がすごく使い勝手が良い。

すごく日本人的かもですが、頑張ります!とか頑張ろ!って意味ですごく使いやすい。

という発表をBurikaigi2020 - connpassでさせていただきました。

Image from Gyazo

プログラミングスクールの問題点

一番言いたかったのは「未学習」と「未経験」を一緒にするのはやめようっていう話です。

Burikaigi

.net/C#・Java・Rubyという感じに三つの部屋に分かれていました。もちろん僕はRubyの部屋で、とても発表も面白かったんですが、他の2部屋の内容もめっちゃ気になりました。

C#はUnityをやってる時にやっていて、まだ全然習熟してないのでもし話聞いたらすごく勉強になりそうだし(Blazerとか聞きたかったわぁ)、Javaは最新の話題を全然キャッチアップできてないので聞きたかったです。

両方とも最近の話題がキャッチアップできるイベントがあったら行きたいなと思います。

Image from Gyazo

年齢層高めの我々おっさんにとっては最高の食事群でしたね。

鰤しゃぶ以外にも富山(主に魚!)の名物が満載。我々の好きなものばっかりじゃん。鰤しゃぶは昆布に日本酒をなみなみと注ぎ、火をつけてアルコールを飛ばした上でしゃぶしゃぶ…はかどるわぁ〜。

Image from Gyazo

Ruby部屋の皆さんは知った顔ばかり和みました。@muryoimplさんの地元の金沢も行きたいからイベントやって欲しいなどと話つつ、とても楽しく飲み食いできました。

もうおっさんの好きなもの全て集めて、千葉のホテル三日月とかでイベントやって欲しいですね😁

フィヨルドブートキャンプでいつも話すのでここに書いておきます。

入りたい会社が無い

勉強を始めたばかりで、

「プログラマーとしてどういう会社に入りたい?」

と聞かれても特に無くて当然だと思う。

会社のホームページや求人サイトに書かれるパブリックな情報は良いことしか書いてないし、将来性とか言われてもピンとこない。

せいぜい「ブラックじゃない会社が良い」「給料の高い会社が良い」とか。

おすすめの探し方

おすすめの探し方はプログラミング関係のイベントに色々行って、どこかのコミュニティに属してみることです。(プログラマ自身が主催してるところがいい)

コミュニティに属すると「こういうプログラマーになりたい」とか「この人と一緒に働けたらいいな」とか「この評判のいい会社で働きたい」など、自然と自分の中に好き嫌いができてきます。

普通の社会人は自社の悪口を社外で言わないものらしいですが、(僕を含めて)現場のプログラマーはイベントや懇親会で普通に悪いところも話しがちです😭

悪いところを含めて色んな会社のリアルな情報が聞けるので、コミュニティ内での会社の評判というのは概ね現実に即しているという印象です。

イベントに行く前に

そもそもある程度プログラミングの知識が無いとイベントに行っても話される意味がさっぱりでクッソつまらないのでいきなり行くのはおすすめしません。

rubyやrailsを噛り始めたぐらいで行き始めるのがおすすめ。

イベントの探し方

イベントの探し方はrubyだったら近所の地域rubyコミュニティを探してみるか、connpassで自分の使ってる技術で検索してみると良いと思います。