ちょっと気になっていたので買ってみました。Chef実践入門 で、写経しています。ただし、Ubuntu を対象の OS にしているので、記載するコマンドが違っていたりするので、純粋に「写経」ではないのですが、ちょっと頑張ってみましょう。
ちなみに、Ember.js の写経対象として、Ember.js Testing on Rails を買ってみたものの、ちょくちょく記載が誤っていたりなんだりで進んでいないのでした。 先日の更新でだいぶマシになったので、ちょっとこちらも頑張ってみよう。
1月から4月の3週目くらいまで某プロジェクトでお世話になっていて、今現在別のプロジェクトに移ったので前のプロジェクトの思い出を書こうかと思って書いています。(現在は別のプロジェクトにいる)
※注 特にまとまりはありません。
基本的に、今いる会社はどこかの現場に常駐で入って作業をするということがないため、他の会社の人たちが活躍しているプロジェクトを見れる機会がないのですが、今回なぜか(信じられないことに)私に声がかかったので、他の会社の人たちが活躍しているプロジェクトを見たいというのもあって、「行きたい」宣言をして(実力的に不安を感じながらも)参加させていただいたのでした。
参加したプロジェクトは、pull request 運用が普通に根付いているところで、プロジェクト外の人たちからもレビューが飛んでくるところ。。 斧がバンバン飛んできて、最初の3週間は毎日心に斧が刺さって抜けなかった…(ごもっともな斧なので、弾き返すこともできず100%命中する始末)
朝、目が覚めたときに指摘のメールが十数件溜まっていたり、出した PR がなかなか通らずに rebase して直しては指摘を受け、直しては指摘を受け…を繰り返したりするうちに、~~~心が麻痺して~~~ 学習して斧の量も減ってきた、というのが最初の1ヶ月目のことであった。
この間、だいたい指摘されやすいものが見えてきて、私の場合、block を取るメソッドでコードを短くできるならば積極的にそちらを使うとか、名前のつけ方(意識しても指摘もらうんですが…)とか、spec の書き方とか、が代表的なものであった。(だいたい全部じゃん？ってのはなしの方向で)
そこらへんの怪しいところは書いた後に何回か確認して PR 出すように心がけても、まだすんなり merge はされないのであった。
2ヶ月目。プロジェクトのコーディングもだんだんペースができてきて、かつ、機能がそれなりに触れるくらいの数になってきたころ、ラードに溺れる毎日がやってくる。
1ヶ月目のような指摘は減ったものの、詰めの甘い、ちょっとしたミスとか名前おかしいとかいう指摘が目立つようになってきた。 いわゆる、「だからお前は詰めが甘い、ラードでも飲んでろ」案件である。
毎日、いただいたパイン飴を舐め、押し寄せるラードを飲み込む毎日。
この頃、ラードとは別に、杏仁豆腐 という新たな魔物と出会うのであるが、その恐ろしさを目の当たりにするのは、プロジェクトを抜ける間際のことなのであった…
この月はなんかモリモリ書いていた気がする。機能はここでだいたい作ってしまっておこうって感じだったので、必死だったような… このあたりから、メンバーの杏仁豆腐攻めが始まるのであった。
きっかけは中華屋でお昼を食べたときである。定食を頼むとほぼデザートに杏仁豆腐が付いてくる。「杏仁豆腐が苦手だ」というので、大好きというわけでもないのであるが 私がその杏仁豆腐をもらった。その瞬間。「僕のもあげますよ」という声が…その日の昼、私は杏仁豆腐を4人分食べることになったのである。
これが悪ノリの始まりである。
さて、最後の月である。
すっかり話のオチに使われることも慣れ、すっかり排水口キャラが定着していた。あまりにオチに使われたり、杏仁豆腐の餌食になることが増えたため、「排水口もたまには詰まるんだよ！」と言ったくらいである。でも効かないwww
しかもこの頃には既に、お世話になっている会社内では私の顔を知らなくとも「杏仁豆腐が大好きな人がいるらしい」ということで、三度の飯より杏仁豆腐が好きでもない私のことが杏仁豆腐大好き野郎としてキャラが確立されていた。 どれほどかというと、帰社日ということでおじゃまするといきなり「杏仁さん」、と言われるほどである。
がコメントに出てくることも増えた。(理由は訊かないで欲しい)
しかもこの頃、大阪の方面にいる知り合いからも、杏仁豆腐に関するいじりを受けることが多くなり、ｲﾗｯ としながらコメントを返していた。(現在も継続中である)
この頃、リファクタリングが結構行われていたので、気がついたら自分の書いたコードが一行もなくなるのでは？ と思ったこともありました。
なんか思い出形式で書くと、ネタにされていることが多すぎて泣けてくるのでありますが、非常に勉強をさせていただきました。 コーディングのスタンスとか、考え方、gemとかその使い方とか本当に勉強になりました。仕様とか設計についても勿論考えたりはするのですが、コードについて本当によく考えさせられた期間だったと思います。
以前に作っていたプロジェクトのコードとか見ると違和感を感じるので、少しは成長できているのかな？とも感じています。
最後に、僕の写真がプリントされたTシャツをプレゼントにいただきました。ありがとうございました。
次は若干、Tシャツが僕より先に行っているようです…
(文章はおもしろおかしく茶化して書いていますが、フィクションではありません！)
P.S 写真に撮ったものだけで数えても、2/25 から数えて 55 個も杏仁豆腐を食べていました…どう考えても過剰摂取です。
今日仕事で gretel が使いやすかったのでメモ。
これまでの パンくずリスト(breadcrumbs) は、だいたい、controller の中で add_breadcrumb みたいなメソッド を呼び出してリストを作る感じなのですが、 gretel はちょっと違うのね。
gem を install します。ここは適宜、bundle とかにしてください。
$ gem install gretel設定を記述するファイルを出力するコマンドを入力します。いわゆる、install コマンドです。
$ rails g gretel:installこのコマンドを打つと、config/breadcrumb.rb が作成されます。 ここに表示するパンくずの設定を書くのですが、
# Root crumb
crumb :root do
link "Home", root_path
end
# Issue list
crumb :issues do
link "All issues"
parent :root
endこの記述で、 Home > All issues のパンくずの設定ができました。
view の layout と、パンくずを表示する画面にメソッドを書く必要があるのですが、パンくずの関係の設定はこのファイルに書くだけです。
これの何が嬉しいかというと、controller に書くタイプの下の例だと、update で更新に失敗したとき、edit で設定したパンくずの設定をもう一度書かないといけない。これが面倒で漏れやすいんですよ。
# 結構適当に書いてる
def edit
add_breadcrumb 'Home', root_path # ←ここ
add_breadcrumb 'All Issues', nil # ←ここ
end
def update
@post = Post.find(params[:id])
@post.attributes = post_params
if @post.update
redirect_to posts_path
else
add_breadcrumb 'Home', root_path # ←ここ
add_breadcrumb 'All Issues', nil # ←ここ
render action: :edit
end
endgretel は、この設定と後述する view 側の設定で、view単位でパンくずの設定が書けるのでこの点は気にせず、DRYに書けます。
とりあえずパンくずを出力するには、app/views/layouts/application.html.erb に
<%= breadcrumbs %>のように書き、表示したい各view に 以下のように書けば、 Home > All Issues が出力されます。
<%= breadcrumb :issues %>
# 指定された :issues から parent の設定をたどって、 'Home > All Issues' が出力されるview 単位にパンくずが設定できるので、前述のようにupdate と edit に同じ記述をする必要がなく、DRY にパンくずが書けます。しかも、指定した crumb から parent たどっていくだけなので、設定自体も非常に見やすい。
gretel を見ると、bootstrap や foundation5 に対応していたり、リストの形式を ol, ul にしたり、class の指定をしたりもできます。
私が仕事で使ったときは、別にパンくず用のデザインがあったので、そのデザインで出力されるように書きました。 Building the breadcrumbs manually のパートに書かれているやり方を使えば簡単に独自レイアウトにも対応できます。
とにかく、DRY にしかも簡単に書けるのがすばらしいので、パンくず実装するときは使ってみてください。
先日の関西Ruby会議05でひとりレポート作成班をしていたので、その関係でレポートをるびまに寄稿しました。で、ちょっと褒められたので、自分なりに地域Ruby会議レポートを書くときに気をつけていたことを書き残しておこうかと思います。
もともとは、初めてレポートを作成した、前回の関西Ruby会議04のときに意識したことがベースになっています。基本は読み手が読み疲れしないようにするということを意識しています。
地域Ruby会議のレポートを書くとき、発表者のセッションは全部載せたいと思う。でも、そうなると長くなるので読み疲れが心配になる。
ということで、あまり1セッションに対して長い文章を書かないようにしています。ただし、少なすぎると記事の空白が気になってくる ので、空白とのバランスを考えて文章の量を調整します。これは解像度の違うPCとかスマートフォンで見ると実際の見え方が変わるので、複数マシンで確認するのがベストです。今回は、MBAとVAIO PROとスマートフォンで確認しました。
レポートなので、そのセッションのあったことを書けばいいのですが、自分が書くのにセッションの内容のまとめだけだともったいないです。
スライドへのリンクがあるなら、スライドを見ればだいたい内容はわかると思うので、そこに載っていないことや自分がどう思ったかを書いたほうが読む方にも「こういう印象を与える発表だったんだな」とか「当日はこんな感じだったんだ」みたいなイメージをプラスできるんじゃないかな、と思っています。(まぁ、お前の意見はどうでもいい、と思われてるかもしれないけど……)
これはまぁ、普通か。
発表の内容を知りたいと思う人が多いかもしれないですが、私は地域Ruby会議の雰囲気が好きだったりするので、当日の様子がわかる写真を入れるようにしています。
「楽しい」とか「勉強になる」とか「こんなやり方もあるのね」みたいなものが読む人にも伝えられれば、別の地域で開催する人たちのヒントにもなるかなぁ、なんて。
あまりに完璧を求めるがために、会議当日に楽しめないくらい必死にレポートするとか、記事にあれこれ全部入れるとか、はしません。
文章は深い内容を伝えるにはいいですが、雰囲気みたいなものは画像である程度伝えられると思います。写真があるなら写真を貼って、無駄に文章の量を多くしないようにします。発表者の方のスライドがあれば、発表内容もだいたいそちらをみれば伝わるはず。やはり文章考えたり、推敲したり、誤字脱字直すのが一番しんどいですからね。ただそのためには、
というのが必要になるので、これは運営のときに準備しておくとよいと思います。
セッション別に担当をわけてメンバーがパートの分を書いて結合すると思うんですが、最終的には誰かがバランスを取らないといけないと思います。
今回は私ひとりで作成したのでこれには該当しないのですが、前回は複数人で作って私が最後全体を見て手直しをしました(るびま編集とのやりとり担当が私だったので)。セッションのレポートはメンバーの個性みたいなものが出るのがよいと思っていて、でも全体のバランスを崩しすぎるものアレだな、というのでこの方法を採りました。 これが良い方法かと言われれば疑問はあるのですが、誰か一人のスタイルを真似るよりはメンバーの個性が出たほうが面白い記事になるんじゃないかなぁと思っています。
これが一番むずかしいのですが、会議の開催からレポート提出・公開までの間が空いてしまうのと、会議が終わった達成感から、レポート作成から逃避したくなるんですよね。。
前回作成時にこれに悩んだので、今回はそうしないようにすぐにレポートを作ろう！と思っていましたが、締め切りが遠いのでエンジンがかかりませんでした…… でも、締め切り前に頑張るんですよね。一応、会議終了一週間で当日とっていたメモの整理をしていたのが助かりました。記憶が新鮮なうちに何か手を打つとよいと思います。もちろん、記事ができていると一番いいんですよ！
とまぁ、これくらいが意識していることです。
2連続でレポート書いたので、次回は別の人に席を譲ろうかなと思っています。レポート書いてるびまに投稿すると、るびま編集の中身がみえるし、編集者がどんなこと考えているかも知れるので、いい経験になると思うんです。私がるびま編集に参加するきっかけは、前回のレポート提出なんですよ。
レポートは怖くない。けど、自分のエンジンがかからないのが一番怖い。経験者は語る……
「地域Ruby会議やりたい」ってなったときに「ちょっとどうすればいいのかな……」とか「こんな規模でやっていいのか？」ってなりませんか？
先日やった関西Ruby会議05は、開催メンバーは割と訓練されたRubyistだったのでまぁそれなりにどうすればいいとか知っているわけなんですが、立ち上げたばかりの地域Rubyist集団とかコミュニティってこういうの困ったりしないのかな？というのを RWC 終わった後に日本Rubyの会理事のしまださんとちょっとお話したのでした。
そのRWC終わりのときに、そういう人たちを拾える場ってあるかな？どうすれば拾えるかな？って話をしたのですが、今のところはこちらのページにあるように地域Ruby会議のMLに投げてもらうとか、どこかの地域Ruby会議を開催した人になんかしらのメッセージを送るとかしかないみたいという話をしました。
開放された駆け込み寺的なところは、地域Ruby会議のMLしかないですが、開催が決まってからでなくて相談レベルでもMLに投げてしまってもいいと思うんですよね。折角そういうMLがあるので使うべき。寂れてなくなっていくよりは全然いいと思います。費用的なところも併せて。
また、マサカリ担いで新規に会議を開拓した人はいても開催に際して「こうでなくてはいけない」とかマサカリ投げてくる人はいないと思うので、安心して投げていいと思います。
私は関西Ruby会議05やる前に、福岡Ruby会議、大江戸Ruby会議と岡山Ruby会議に参加して主催者の方や参加者の方に相談してみたり、たまたま遭遇した角谷さんに相談したりとかもしました。これはお金かかっちゃうんですけど、やはり生の声を訊くのは一番グッとくるってのはあります。
地域Ruby会議は、先日の関西Ruby会議で角谷さんもおっしゃってましたが、「地域Ruby会議は好き勝手にやったらいいもの」なので、人数とか規模とかどうでもいいんですよね。 どうしても規模が大きいものや、著名なRubyistが集う地域会議が話題になってしまうので(仕方ないんだけど)、そういうものだって考えてしまいがちなんですけど、どうでもいいんですよ。九州Ruby会議02とかTokyuRuby会議とかみたいに自由でいいと思うんです。(つまり、いい前例がある！)
九州Ruby会議02は、バーでビール飲んでて発表者の話ほとんど聴いてないだろｗってものもあったし(けど、みんなめちゃ交流してたｗ)、バーなんでそんなにキャパもなかったし。そういう変わった点に話題になる地域Ruby会議があってもいいと思うんですよね。そろそろ、Tokyu, うなぎ(あれはrbでしたっけ？)を超えるもの待望論が出てきてもおかしくないｗ
人が集まらない、ということはないと思います。やるって言ったら、割と人が集まってきます。(関西のときも、中身決まる前に結構な参加応募がありました) 土着のRubyistのみでできるならばそれが地域Ruby会議っぽさがあっていいと思うんですけど、他地域の人呼んじゃってもいいと思います。私らも他地域から強力な人呼んでますからね。 私みたいな地域Ruby会議に参加するのが趣味みたいな人や、他地域の地域Ruby会議に興味持ってる人もいると思うのです。
極力小さい規模でやりたいというなら、宣伝しないってのもありだと思います。地域のコミュニティにだけ情報流すとか。 無理に大きくして運営側の負担を大きくすると、暗黒面にとらわれて「良い」と思えるものも良く感じられなくなっちゃいます。自分達が運営していて楽しいとか、負担に感じ無い程度でやるのがいいです。やたら理想が積み重なって大きくやりたいとかなるかもしれませんが、小さくやって広げていくのがいいと思います。年に一回とかいう縛りもないですし、小さく何回もやる、それなりの規模を年に一回やる、やりたいときにやる、なんでもありです。
なんかネタなくなると、地域Ruby会議とかいうおっさんになってる感…(いや、レポート書くと高まってくるんですよ、なんかが)