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

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

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

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

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

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

Image from Gyazo

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

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

プログラミングスクールのフィヨルドブートキャンプの提出物のレビューでよく指摘するシリーズ。

rubyではメソッド呼び出しにカッコ()が必須ではありません。カッコを使わずにメソッドを呼び出すと単に変数を参照しているように見えます。

article = Article.new
article.title # メンバ変数が呼べているように見える

rubyはこれを利用してアクセサを実現している。(c#やswiftでは専用の構文を用意している)

attr_accessor :title
def title
  @title
end

def title=(title)
  @title = title
end

↑この2つは同じ。

これは自分のプログラムにも活用できる。メソッド名が名詞であって、そういうメンバ変数のアクセサとして動いているように”見えれば”問題ないメソッドになる。

def age
  today - birthday
end
user = User.new
user.age # そういうメンバ変数にみえる

実際にはそんなメンバ変数はなく、メソッドがメンバ変数のフリをしているだけだ。クラスを使う人からみれば同じように振る舞うのであれば問題ない。 複雑な処理を整理したいとき、これを使ってなるべくそのクラスのメンバ変数に見える名詞メソッドの形にしてみよう。 たくさんのメンバ変数(に見える名詞メソッド)を扱う少数のメソッドという形になると全体が把握しやすくなる。何故ならメンバ変数よりメソッドの方が入力・出力・副作用を考えなければ行けないので複雑だから。

注意

ただ、メンバ変数のように見えるメソッドが派手な副作用を持っている時、使う人から見るとエゲツない罠となる。

プログラミングスクールのフィヨルドブートキャンプの提出物のレビューでよく指摘するシリーズ。

可読性の面

可読性(他の人が読んだ時のわかりやすさ)の面から言うと、initialize(初期化)と言える処理のみ書くべきです。

そのクラスがインスタンスになっているとき、そのインスタンスが備えているべき変数の状態などを設定しておくべきです。

newしただけなのに初期化とは言えないことをやっているとそのクラスを使った人はビックリするし、勘違いから事故が起きやすくなる。

機能の面

機能の面から言うと、大抵は受け取った引数からメンバ変数を設定する程度をするのが一般的です。

例えば、newしただけで何か文字を出力してたりすると、そのクラスをテストする時に困る。拡張するときも困る。

printer = Printer.new # ここで画面に何か出ちゃう
assert printer.ready?

これまたフィヨルドブートキャンプで何度も説明しているのでまとめておきます。

getterとsetter

一般的なGetterとSetterについてはこちら:

3.5 GetterとSetter : Javaのオブジェクト指向入門

titleというメンバ変数があった場合、getter, setterを実現するためにget_title set_titleというメソッドを作らなきゃいけないのは冗長。

rubyではアクセサというが、メンバ変数と同名のメソッドができる機能がある。

attr_accessor :title

c#やswiftなどでもプロパティという仕組みで同様のことができる。

public string Title { get; set;}

クラス名、メンバ変数名、メソッド名の原則

  • クラス名:名詞
  • メンバ変数名:名詞
  • メソッド名:動詞

変数の動詞化

見方を変えると、titleget_titleというメソッドをあてがうというのは変数をメソッド化(=動詞化)するために無理やりgetを付けていることになる。

メンバ変数のように振る舞うメソッド

rubyではメソッドを呼び出すとき必ずしも()を付ける必要がない。

foo() # カッコあり
foo # カッコなし

これにより、本来動詞であるべきメソッドを名詞にして、カッコなしで呼び出すとメンバ変数であるかのようにみえる。

article = Article.new
article.title # メンバ変数が呼べているように見える

rubyはこれを利用してアクセサを実現している。(c#やswiftでは専用の構文を用意している)

attr_accessor :title
def title
  @title
end

def title=(title)
  @title = title
end

↑この2つは同じ。

アクセサの考えを自分のプログラムに活用する

これは自分のプログラムにも活用できる。

メソッド名が名詞であって、そういうメンバ変数のアクセサとして動いているように”見えれば”問題ないメソッドになる。

def age
  today - birthday
end
user = User.new
user.age # そういうメンバ変数にみえる

実際にはそんなメンバ変数はなく、メソッドがメンバ変数のフリをしているだけだ。クラスを使う人からみれば同じように振る舞うのであれば問題ない。

複雑な処理を整理したいとき、これを使ってなるべくそのクラスのメンバ変数に見える名詞メソッドの形にしてみよう。

たくさんのメンバ変数(に見える名詞メソッド)を扱う少数のメソッドという形になると全体が把握しやすくなる。

何故ならメンバ変数よりメソッドの方が入力・出力・副作用を考えなければ行けないので複雑だから。

メソッド名の原則を外れていてるコードを見たとき

他人のrubyコードを見たとき「メソッドなのに動詞じゃない」と思ったときはこのテクニックが使われてないか考えてみよう。そして自分のコードにも取り入れるとわかりやすいコードになるかもしれない。

宣伝

ss

現場の即戦力になれるプログラミングスクール フィヨルドブートキャンプ

Saint P Rubyconf 2019

1日目始まりました。

Image from Gyazo

会場はクッソでかいJetbrainsのイベント会場。(普段何に使ってるのコレ・・・?)

Image from Gyazo

Image from Gyazo

発表は1時間毎でお昼や途中休憩は特にスケジューリングされてなく、勝手に休んだり勝手にお昼食ったりする感じらしい。

発表内容はEurukoよりはテックよりが多い。(というかEurukoがエモい話オオスギィ)

発表者はフリーランスかEvil Martiansみたいなグローバルで有名な会社の人が多くて、ロシアの会社の人は少ない感じ。

ごたごたしていて会場到着が遅れちゃったけど @hsbt さんとお会いできた。

Googleが使われて無くて全部Yandexとか、地下鉄で荷物チェックされるとか、みんな休日にはコード書かないしPC開かない?などなどロシア情報を交換しました。

@hsbt さんの発表はDay 2の最後なのでリラックスできなくて嫌そうでした😅

先週、asakusa.rbに初参加させてもらいました。

毎回、RubyKaigiに行くたびに、皆さんの圧倒的成果物を見るにつけ、

「あ〜、俺はRubyに食わせてもらってるのに何の貢献もできてない、フリーライドしててもうしわけないなあ〜」

と思ってました。

最近はメイン仕事がUnity/C#ということもあってRuby成分が減っていたのでRubyKaigi2019から戻ってから趣味のプログラミングとして「ruby関連の作業をしたい!」と思い、rubyのredmineやML、githubのruby organizationのIssueをみて何か俺にもできる作業は無いかなと探していました。

その中でloggerにPRを送ってみたりしつつ、ruby作業の気合を入れるためにasakusa.rbに初参加させてもらいに言ってきました。

結果、行ってよかったし、これからも行こうと思いました。

やはりrubyのコミッターがたくさんいて生で話せるというのは日本に住んでる圧倒的メリットだなーと思います。

だって、もしロシアのCプログラマーが日本に来てたら、

「うわ、本場の(nginxの)やつがきた、なんか話聞きたい!」

って思うし、

ヨーロッパのRubyイベントで日本人が来てたら、

「うわ、本場の(rubyの)やつがきた、この機会になんか聞いときたい!」

ってなるでしょ。

来月ロシアのサンクトペテルブルクRubyConf行きますけど、@hsbtさんがトリで発表するやつ、地元の人は、

「うわ、本場のやつがくる!」

ってなると思うんですよね(妄想)

それにrubyや有名ライブラリにcommitしてるのが当たり前のコミュニティーに行くと、

「自分も頑張らねば!」

と思うのでruby心が高まりますね。

今日はruby organizationに移ったTryRubyが日本語だと見づらい(右から読む言語でも見づらいらしい)をどうにかするのをやりたいなとおもいます。

事前にレビューさせていただいた、技術書典6で配布されたRubyとRailsの学習ガイドを@igaiga555さんからいただきました。

Image from Gyazo

チラみせ

Image from Gyazo

これからrubyの勉強を始める人に最適のガイド。

傍らに置いておけば、わからない用語が出てきたときには「これに載ってたやつだ」となるかもしれない。

見て思ったのはむしろRuby・Railsをキーワードに勉強始めてる人の方が役に立つかもしれないということ。「これからどの方向に深めていけばいいのか」がわかりやすいので。

これとRuby超入門を読めばかなりスムーズなスタートがきれるんじゃないでしょうか。

フィヨルドブートキャンプでは新しく来る人に配ろうと思っております。

電子版がBoothで500円なので気になる人は何も考えず買っちゃっていいのでは?

関連

仕事でフィヨルドブートキャンプというRailsエンジニアになるためのスクールをやっています。

FJORD BOOT CAMP(フィヨルドブートキャンプ)

「どのレベルになったら就職できるの?」

という点がイメージできないと、就職したい人にとってわかりづらいなと思ったので明確にしておきたい。

戦力として計算できるRailsエンジニアとは

僕の考える、Railsエンジニアとして就職できる最低レベルは、

「少しでもプラスの戦力として計算できる」

というものです。

「Issueを一人でこなせる」

といっても良いかもしれません。

「は?みんな10の戦力持ってるところに1とかじゃ困るんだけど?」

と思うかもしれませんが、Railsプロジェクトにとってほとんどの人類は1の戦力も無くて、マイナスです。

Railsチュートリアルを終わったばっかりで実務レベルの開発したことないぐらいの人もマイナス戦力です。

「教えるのに大量のパワーが割かれて、居ない方がプロジェクトが進む」

という状態がマイナス戦力です。

Railsプロジェクトのリーダー的な役割をした人なら感覚的にわかると思います。

「Rails経験無くてJava経験だけの人が2人送られてきても困るなぁ・・・」

これがマイナス戦力です。

「多少の教育コストはかかるけど、レビューをしっかりやればトータルで見れば助かる」

このレベルがプラス戦力です。

「Railsのコードは書かせられないけどテスト仕様書を書いててもらおう」

こんな工夫が必要な場合、マイナス戦力です 😅

プラス戦力になるための工夫

このイメージが固まってからカリキュラム終盤の内容も変わりました。

  • 弊社プロダクト(怖話など)へPRを送って5回採用される。
  • Railsプログラムのアルバイトの斡旋
  • DB設計のカリキュラム追加
  • RESTful Webアプリ設計のカリキュラム追加
  • メンターとペアプロするカリキュラム追加。

Railsの機能を一通り覚えただけじゃ駄目で、実際のプロジェクトに入るには必須の知識がかなりあります。

弊社としては一般的なプログラマー新人研修もやっているのでその中でこの辺ももっと固めていきたい所存です。

@machidaさんがholiday-jpのアイコンを作ってくれました。

https://gyazo.com/1488e11d6d99c10cd0e8a52ce459fa3d

かわいい!ありがとうございます!

最近、Next Holidayのリニューアルでholiday-jpを久しぶりに触ったらAPIが糞過ぎた。

nextとかprevとかのメソッドが無いなんて使い辛スギィ > 昔の俺

この設定をいつもやります。

class ApiController < ApplicationController
end

だとかっこ悪いので、

# config/initializers/inflections.rb:
ActiveSupport::Inflector.inflections(:en) do |inflect|
  inflect.acronym "API"
end

こうする。

class APIController < ApplicationController
end

気持ちいい。デフォルトの大文字設定に欲しいな。