komagataのブログ

最近レビューでよく書くのでまとめておきます。

指摘

idでソートするとか、idがインクリメンタルな数字ということを前提とするコードは避けよう。古い順に並べたいんだったらcreated_atとかが作成日なんだから「古い順」ということをより表現していることになる。

理由

idをuuidとかに変えた場合バグになる。

古いものを取ろうとしてidでソートしてfirstとかやっちゃいかん。

管理画面のユーザー一覧をid降順でソートしてて、最近追加されたユーザーは一番最初にきてたのuuidにしたら並びが変わった・困るとお客さんに言われることになる。

rails+postgresでidにuuidを使う - komagataのブログ

Microsoft系のライブラリやフレームワークもuuidがidのこと多い。

railsもfixturesではidはランダムに入るのでidがインクリメンタルな数字という前提のテストはコケる。（偶然動いたりするがそのうちコケる）

補足

もちろんだけど、こういうコードは全く問題ないヨ！

@post = Post.find(params[:id])

むしろidはidentifierなんだから本来の使い方。気をつけるのはソート。

つづき

created_atでソートする場合はインデックスを貼る - komagataのブログ

@is8r_ さんにこのように教えていただいたのでやってみた。

MixamoというAdobeのサービスはFBXファイルなどをアップしてアゴや膝の位置をなんとなくしていするとRigを入れてくれる。便利なサービスもあったもんだなぁ〜。

なんか手がねじれてるし、MPが減りそう！

奥さんがblender入門するぞ！と頑張っていた。

俺も年末年始触っていたので奥さんが第一号で作った変なクマにrigを入れてunityで動かしてみたい。

Standard Assetに入っていたThirdPersonControllerを使って動かしてみた！

完全に溶けてるし物理攻撃が一切無効感。なんでこうなった？

むずかしいな〜

こんなこと書いたら「クッソスクールワロタwww」と言われるかもしれないが、僕らはプログラミングとプログラミングをする人が好きなのであって教えること自体が好きなわけじゃない。

もちろんプログラミングをする人とプログラミングを通じたコミュニケーションである「教えること」も嫌いじゃないが一番やりたいのはプログラミングなのだ。

野球が好きで「おーい、磯野、野球やろうぜ」と誘うのだが野球のルールもバットの振り方も知らないというのではメンツにならない。だから教えるという感じ。

教育関係の人がキッチリやっているところの方が教え方は上手いかもしれない。

そういうところに僕らが勝っているところがあるとすれば、隣でめちゃくちゃ楽しそうに野球をやるという点だけだ。

僕らのカリキュラムの終盤に「僕らと一緒にRailsアプリでスクラム（20ポイント分）を回す」というのがある。

みんなで使っているEラーニングアプリ自体をみんなで開発する。もちろん僕も必死こいてIssueをこなす。

これは草野球でいったら試合であって非常に楽しい。早くみんなもルール覚えて試合できるようになって欲しいしサッサと一緒にやりたい。「おーい、磯野、野球やろうぜ」である。

「スクールでプログラミングを教えている」というときの気恥ずかしさ、傲慢ではないかという気持ち、プログラミングをビジネスとして教える罪悪感。役に立つからやるのか、就職に有利だからやるのかなどの気持ちについてわかりやすく文章にしようとすると違和感がある。

分かりづらくかつ正確に書こうとしたら上記のようなものになった。

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

奥さんがRubyRubyShopで買い物したといってこういうカードを見せてきた。

「さすが、伊達に広島・仙台と経費でRubyKaigiについてきてないな？」

と思ったんですがただの韓国のコスメショップだった。

ブートキャンプのアプリをDEPRECATEDなpaperclipからactive_storageに移行した。

GCSのcredential関係ってPrivate keyがそのまま入ってて改行のせいでうまく行かなかったりとかいつもハマる。エラーメッセージの内容も原因解明にあまり役に立たなくて結局ガッツリデバッグすることになって時間がかかる。

ActiveStorage + GCS + Herokuでの自分的ポイントはGCSからダウンロードできるJSONをそのまま環境変数に入れること。

storage.ymlはこんな風にするのがよい。

config/storage.yml:

google:
  service: GCS
  project: "bootcamp-224405"
  credentials: <%= ENV["GOOGLE_CREDENTIALS"] %>
  bucket: "bootcamp-fjord-jp"

こういう感じで入れておく。

$ heroku config:set GOOGLE_CREDENTIALS="$(< /path/to/bootcamp.json)"

実際にちゃんとconfigの各値が読めてるかどうかはActiveStorage::Service#configあたりをデバッグすればよい。

フィヨルドブートキャンプでも草が生えるようにしました。

最初は色も全く同じだったんですが、実装したことに満足して冷静になってみると、

「Githubと同じ色だと紛らわしいな」

とか

「Gtihubと違って一年も勉強してたらやばいから3ヶ月表示ぐらいがいいな」

などあり、もうちょっと変更していきたいと思います。

超実践的プログラミングスクール フィヨルドブートキャンプ

おはようございます。最近流行りのロタウィルスとやらにやられて体調とテンションがダダ下がりのkomagataです。

12月18日（火）に行われたBootstrap Night! vol.4でプログラミングスクールの作り方という題名でお話させてもらいました。

プログラミングスクールの作り方 - Speaker Deck

Bootstrap Night!は自己資金（出資無し）の少人数でSaaSをやってる会社の話を聞くイベントです。

第2回にも聞きに行ったことがあり、価値観が近い会社の方々の話が聞けてとても励みになるイベントです。

でもこういうのって成功している（自社サービスで食べて行けてる）人が話すべきで、まだ受託開発で糊口を凌いでいる僕なんかが話すのはおこがましいんですが、せっかくブートキャンプのお話をさせて頂ける機会なので行ってきました。

特にPaulさんのDookeeperの話は僕らのようなサービスを作るのは得意だけどマネタイズが不得意な人間にとっては涙無しには聞けない内容でしたね。

明日18日にブートストラップ企業（自己資金でやってる会社）の話を聞くBootstrap Night! vol.4にてフィヨルドブートキャンプのお話をさせていただくことになりました。

Bootstrap Night! vol.4 - connpass

若干名の空きがあるようなのでぜひ！

他にもrubyistにはおなじみのDoorkeeperのPaulさんがDoorkeeperのビジネス面の話をしてくださるようで僕も興味津々です。

最近考えてること。

業務経験アリの壁

スクールでコードを書けるようになっても業務経験アリ・ナシの壁がある。もう全然書けるようになってるしプロジェクトに入ったら役に立つよーって状態なのに業務経験ナシってだけで入れない場合が多くてもったいない。

企業からみたら業務経験ナシの人がどれだけ書けるか判断するのが難しいので怖いのはとっても理解できます。

一緒に仕事やれるプログラマーかどうかの判断

では何をやったら一緒に働けるプログラマーだと判断が付くのか。

@dandaso にも聞いたし、自分としても納得なのが、

「自社のプロダクトを2イテレーションぐらい一緒にやればわかる」

ってこと。

一緒に働けば、プログラミング力だけでなく、コミュニケーションや仕事のレポーティングの頻度・質などについても誤魔化しようがない。それは現場の人の実感としてあると思う。

でも自社のプロダクトを採用のために使えないし、その環境を整えたりレビューする手間はなかなかかけられない。

プログラミング面接代行サービス

そこで、2イテレーションやってみる部分を肩代わりしてくれるサービスはどうかと思った。

フィヨルドブートキャンプではそのEラーニングシステム自体を簡易スクラムで作っていて、僕も生徒も混ざってイテレーションを回している。開発に入るためのドキュメントも（生徒用に）そろっているし、オープンソースなので議事録もPRのやり取りも全部見れる。

一次面接的なものを通った人がこれにリモートから参加して2イテレーションやる。そしてその人のPRや、コメントのやり取りを含めた評価レポートみたいなものを提出する。

あくまで一次面接と最終面接の間のプログラミング面接部分を代行するみたいな形はどうだろうか。

別にこれで儲けたいわけじゃなくて、業務経験ナシだけどコード書けるプログラマーが就職しやすくなり、企業側もある程度安心して未経験者を取れる環境になってほしいがためのサービス。

とかどうだろう。