「プロを目指す人のためのRuby入門」が躊躇なくオススメできる完成度だった

前々から色々とお世話になっている西脇.rbの伊藤淳一さん(@jnchito)が、Rubyの入門書を出版されることになり、ちょうど私が読者のターゲットに近い存在ということで１冊見本誌を頂きました。

というわけで、書評というと生意気ですが、写経も交えつつ読了したので、感想を書いてみます。

ちなみに私自身は

• プログラマとしては9年くらいやってる
• Ruby歴自体は2年くらい
• 業務で使うようになったのはここ1年くらい

といった具合。

見本誌をいただいた！
読むぞ〜 pic.twitter.com/r9s3zF7QXX

— mugi (@mugi_uno) 2017年11月18日

実践感の強さ

まず、３章（＝かなり序盤）の段階で「例題解くときはテスト自動化をしような」という説明が出てきたときにこれを感じた。

写経できるような入門書はいくつか見てきましたが、初っ端から「テストは自動化して効率よくやっていこうな」というスタンスの本はなかなか無いのでは。

個人的な経験では、通常入門書を写経していくと、「とりあえずコードを書く→動す→なんか落ちる→コードとにらめっこする」みたいなことになることが多かった覚えがある。（そしてイヤになる）

本書の場合、まずはテストを書いてエラーにしてから、実際のコードを書いてテストが通るという流れを踏んでいくので、1つずつ着実に理解していける感がある。

（さらにRubyの入門しながら、しれっとTDDの基礎的な部分も触れられるのでお得感がある）

現実を教えてくれる

読み進めていくと、

• 実際にはこれは使わないことが多い
• 幾つか書き方があるけど、こっちが主流
• こういうのが不具合の原因になりやすい

みたいな、言語仕様・文法だけを学んだだけでは把握できない部分に言及している箇所がかなり多いことに気付く。

実際このあたりは業務で使うときにかなり重要で、学ぶタイミングが少なかったり、単純にググるのが難しい概念だったりもする。

そういったところで都度道筋を教えてくれるのは初心者には嬉しいように感じた。

また、英語で出てくるバックトレースなどについて「英語が苦手な人も辞書を片手に頑張ってね」という記述があるのもなかなか新鮮だった。 わりと入門書では「今は理解しなくていいですが〜」みたいなことを書いてあったり、そもそも触れられないみたいなことも多いですが、ぶっちゃけ理解しなくていいわけがないので、そのあたりの現実突きつけてくれるのは大事。

実際のところ私自身も英語は苦手なので「うっ、すいません..！」って感じだった。

プログラミング初心者向けではなく、Ruby初心者向け

書籍内の冒頭でも触れられていますが、プログラミング自体が初心者という人にはハードルが高めかもしれない。基本的な概念の説明は無いので、「変数...?」みたいな状態だと厳しい。

逆に言うとそのぐらいちゃんとターゲットを絞った本なので、合致した層が手に取ると、かなり参考になる内容が多いと思う。

Rubyを使っていて、「自分はもうRubyバリバリ使えるぜイェーイ！」って言える人以外は、とりあえず買って目を通してみるといいかもしれない。私自身も、もう完全な初心者ではないかな〜と勝手に思っていたけど、普通に知らないことがボロボロ出てきたので、いい感じに振り返れてとても良かった。

写経しやすい

全体を通して、そもそも写経を想定して作られてるなって感じがした。

基本的には各章に１つ練習問題があるので、ざっくりとした理解チェックをするには最低限それをやればいいし、ガッツリ学びたければ、都度記載されてるサンプルコードを全て写経していくこともできる。

ちなみに紙質も違うらしく、開いたときに維持しやすいらしい。

実際維持しやすかった。すごい。

とりあえず理解度が全然違うので、写経しながら読むことをオススメする。

適宜必要な前提知識を教えてくれる

人によっては正規表現の章で、「正規表現知らないならそっち勉強してから戻ってきてね！」と、一度書籍の外に追い出されるという体験をすることになる。

このあたりは「プロを目指す人のための」という名前がピッタリだなという印象だった。実際のところ、根本の部分がフワフワしてると理解できないので、そのあたりをいい加減にしたままRubyでの正規表現の使い方を教えられても困るわけで、「知らないなら知ってから戻ってきてね！」というスタンスはとても潔いし、そうだよな、って感じがした。

トータルでの感想

私の個人的な感情とかは無視しても、かなりの良書だと思った。

Qiita等での伊藤さんの記事で普段お世話になっている人も多いと思うけど、あのわかりやすさがそのまま本になったような感覚。

周りにRubyに精通した人がいて質問できる環境なら良いが、そうじゃない場合には学ぶのが難しい要素というのが実際それなりにあって、本書の内容である程度カバーしてくれるのがとてもいいと思う。

2年前のRuby勉強し始めたころにこの本があれば〜〜〜！！と何度も思った。SIerからRuby使うようなWeb系への転職を考えている人とかには最適の1冊になるのでは。

ターゲットを絞っているぶん、合致するとかなり刺さる内容が多いのかもしれない。

• 「これからRuby勉強したいんですけど〜」
• 「それなりに書けるようになったけど、いまひとつ自信ないわ〜」

みたいな人がいたとすれば、今後はこの本をオススメすることになると思う。（私は後者だったので刺さった）

さいごに

見本誌で頂いたという立場を考えると、サクラのような書評になってしまっているように見えるかもしれないけど、内容をじっくり読んだ上で良い内容だと判断したので、躊躇なく書かせて頂きました。

これはもう、「プロを目指す人のためのRails入門」の出版が待ち遠しいですね！

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで

RSpec/Capybaraのテストコードを画面操作から出力するChrome拡張をつくった

ほぼ表題の通りの内容で、Chrome拡張を作ってみた。

完成度としてはまだまだだけど、とりあえずざっくり触れる程度にはなったので公開した。

github.com

chrome.google.com

アイコン画像は、カピバラの写真を適当になぞって作った。

なんでこんなものを？

Capybaraのテストコードを書くのが面倒だなって感じることが多かったのが1つの理由。

TDD的に、先にテストコードを書いていけるのが理想だな〜とは思うものの、Webアプリケーションの開発をしていると、現実には一度は画面から一通り確認して、その後にfeature specを書く流れが多いように感じる。

そしてCapybaraでfeature specを書こうと思うと、

• 「これはテキストじゃなくてIDで選択しないとダメか〜」
• 「あ〜、これはfindしてからsetしないといけないのか〜」

という感じで、スムーズに書けない自分がいる。

そのあたりを都度試行錯誤しているのが面倒だな〜と思い始めて、「どうせ最初に一通り画面を触ってるんだから、そのときの操作がそのままfeature specとして出力できればいいじゃん！」と思って作り始めた。

あとは、Chrome拡張って興味があったけどなにげに作ったことがなかったので、やってみたかったというのもある。

つかったもの

• Vue
• Vuex
• events (https://github.com/Gozala/events)

ContentScript ⇔ Background ⇔ DevTools という流れでデータのやり取りを非同期で行う必要があった。

ごちゃごちゃしそうだったので、非同期になる箇所はすべてeventsでラップして、全データがDevTools上にVue&Vuexで構築たストアに集約するようにしたところ、わりとスッキリした。

役割としては、

• ContentScript : 操作の監視 & 情報を集約してeventsをpublish
• Background : ContentScriptとDevTools間を中継するのみ
• DevTools : ContentScriptのデータをsubscribeしCapybaraのコードを生成

みたいな感じになった。

できること

• テキストフォーム・テキストエリアの入力 → fill_in の生成
• ラジオボタンの選択 → choose の生成
• チェックボックスの選択 → check/uncheck の生成
• セレクトボックスの選択 → select の生成
• 要素クリック → find(xxx).click / click_link / click_button の生成

あたりはできている。

一番やりたかった部分として、何でその要素を特定できるかで生成コードが変わるようになってる。

fill_in '一意のラベル', with: '入力値' # ラベルで特定できる
fill_in 'id', with: '入力値' # idで特定できる
find('.class').set('入力値') # classで特定できる
find(:xpath, '/div[1]/input[1]').set('入力値') # 上記全てが無理な場合はxpath

できないこと

まだまだ発展途上感がある。 現時点で以下は対応できていない。

• 画面遷移後の継続動作
• visit とかも作る
• fill_in 前の要素の click が不要なので省く
• などなど..

というわけで

公開してあるので、興味のある方はどうぞ。

個人的には、label/id/class/xpathの自動判別が作れたのである程度満足しているけど、機能的にもっと充実させていきたい。

要望などがあればissueにもらえると嬉しいです。

RailsDevelopersMeetupでWebpackerの話をした

2017.8.24に行われたRailsDevelopersMeetupにて、機会を頂いたので10分枠でLTをさせていただいた。

rails-developers-meetup.connpass.com

突然のメッセージ

ここ数日はコードも書かずにスプラトゥーンをやる日々だったけど、ある日Twitter経由で、主催の@yoshi_hiranoさんから「地域.rb発のLTを実現できないかと思い、Toyama.rb主催ということでリモートでLTをお願いできないか」という主旨のメッセージをいただいた。

「えっ、自分！？」と思い、宛先を間違ってるんじゃないかと何度もメッセージを見返したけど、やっぱり自分だった。

第１〜３回目の登壇者には著名な方も多く、参加者の期待に応えられる話がちゃんとできるかな〜？と心配だったけど、「せっかくの機会なのでやってみよう！」ということで、発表させてもらうことにした。

なお

自分は10分のLT枠だったけど、Keynote枠のうちのお一人が伊藤さん(@jnchitoさん)だったのにはかなり驚いた。

Toyama.rbを作ったそもそものきっかけは伊藤さんと言っても過言ではないので、まさかそれが同じイベントでリモート発表する日が来るとは予想もしてなかったし、とても嬉しかった。

事前練習

妻にお願いして、少しだけ練習した。

「何もわからなかったし、聞いてる途中ちょっと寝てたわ」という感想だった。

まあそうですよね

話した内容

ぶっちゃけた話、業務でのRails歴がまだ浅いので、人前で話せるレベルのスキルも知識も持っていない。

ただ、唯一Webpackerにはがっつり関わった経験があり、良いこともツラいこともそれなりに味わったので、今回のテーマにした。

というわけで資料です。

speakerdeck.com

10分間

10分と時間が決まっていたので、最終的にかなり内容を削った。

本当はもう少し具体的に移行手順的な話もしたかったんだけど、「結局どう感じたのか？」「よかったの？どうだったの？」といった、自分の感想的な部分を強めに出してみた。

おそらくフロントエンドにはそこまで深く関わってない方も多く参加されてただろうと予想しているので、結果的には踏み込みすぎないで丁度いい具合の仕上がりになったかな〜と勝手に思っている。（本当か？）

リモート発表

今回は、普段お仕事をしている富山の自宅からリモートでの発表だった。

初めての体験で、聞いている方の顔や雰囲気が感じ取れないのが少しさみしい感じはあったものの、意外となんとかなるもんだな、と思った。

Hangoutは負荷が高いと色々トラブルが起きやすいイメージがあったけども、そんなこともなく、基本的にはスムーズだった。

手応え的に

Twitterで感想とかを見ていると、わりとWebpackerの話聞きたかったという方も多かったようで、完全な空振りとかではなかったようで安心した。

そしてすでに使ってるという方には、ツラかったポイントは響いたようだった。そうだよね。わかるわかる。

ちなみに

音が聞き取りやすいけどマイクが良いのか部屋が静かなのか、といった感想をみかけた。

部屋は普通なのでマイクを紹介しておくと、Yetiをつかっております。

かなりでかい。
また、このマイクのおかげで、たまに「YouTuberだ！」という扱いを受けている。

やってみて

今までは北陸界隈や社内での発表ばかりで、ある意味安全な範囲で活動をしていたけども、今回始めて外に飛び出しての発表だった。（正確には家の中だけど）

正直かなり緊張していたけど、自分なりにちゃんとやれたと思うし、自信もつけられた。

あと、これは毎回思うけど、発表するとそのために知識や資料を精査する必要があるので、どちらかというと自分が学ぶことがかなり多くてとても良い。

今後も積極的にやっていきたい。

あらためて

当日聞いていただいた皆様、ありがとうございました！
主催者の皆様、おつかれさまでした！

このような機会を頂けたことに感謝しています。ありがとうございました！

フロントエンド勉強会をやった

Toyama.rb 第20回目のイベントとして、フロントエンドの入門的な勉強会をやった。

toyamarb.connpass.com

以前から懇親会などで「もくもく会以外でどういうことやりたいです？」と参加者に聞いていたところ、フロントエンドがよくわからん！という意見が多かったので、テーマに据えて勉強会をやってみることにした。

お盆

わりと面白いテーマだったので人数も結構集まるかな〜ワクワク、って思っていたら、お盆ど真ん中に設定してしまったので、普通に少人数だった。

完全に私のミス感はあるけど、人数が少ないぶん、ゆるい雰囲気でできたのでこれはこれでよかったかなって思った。（思いたい）

babel & webpack 入門

1つは私自身が話をさせてもらった。

自分自身まだまだ解ってないことが多いな〜と日々感じることが多いけど、良く使う構成であればさくっと構築できるようになってきたので、頑張ってまとめてみた。

gitpitch.com

何を話そうかな〜？と悩んだけど、自分が最初に触れたときに一番混乱したのが、babelとビルドツール(webpack/browserify/gulpなど)を同時に利用した場合の設定まわりだったので、そこを中心に話した。

資料作成＆話をしてみて

「こんなもん解るわけないよな」って改めて思った。

登場人物というか、必要なツール群が多く、かつブラウザの話なのかnode.jsの話なのかとかでも混乱するし、なかなかつらい世界だった。

自分は全部一気に学ぼうとしてパニックになった記憶があるので、資料にも書いたけど、1つずつ覚えていく、というのも大事なのかもしれない。

GitPitch

発表用の資料作成にGitPitchを利用させてもらった。

github.com

• Markdownで書けるのはやっぱりすごいいい。短時間で作れた。
• デフォルトでデザインがいい感じになるのがありがたい。
• コードのハイライトとかがめっちゃ便利だった。
• デフォルトでcssの text-transform: uppercase が適用されてるので、デフォルトだと見出しが全部大文字になっちゃう。
• → カスタムcssで打ち消せるけど、これはデフォルト無効でいいのではって思った。

感想としてはすごいよかった。 また利用させてもらうと思う。

フロントエンド開発の足回りとしてのyarn(あるいはnpm)

@hikaruworld さんの発表。 今までの歴史的経緯と、yarn/npmの話だった。

歴史の話がおもしろかった。知らないことも多かった。

話を聞きながら、いつの間にやらみんなyarn使ってるな〜って思ってた。

そして「今の話なので、来年はまたどうなってるかわかりません」という言葉を聞いて、ｳｯってなっていた。つらい世界や…

モブプロで学ぶReact/webpack/babel

話を聞くだけじゃつまらんかな〜というので、実際のコードを対象にどんな感じで環境を作ってコードを書いていくのかを、モブプロ形式でやってみた。

内容

Toyama.rbのHPで、次回のイベントと最近のイベントをconnpassから動的に取得して表示している。

• 変更前 : jQueryとlodash#templareでゴリゴリに実装
• ゴール : React/ES6で書き換える

進行

当初はドライバーを交代しながらやっていこうかな〜と思っていたんだけど、普通にツラいし時間も全然足りないだろうな、という判断から、私がドライバーをやりながら終始ツッコミをもらうというスタイルにした。

モブプロというかコーディング実況的な感じになったけど、スムーズに進んだのであれで良かったかなって思ってる。

結果

1時間半程度だったけど、以下を達成できた。

• webpackによるReact/ES6のビルド環境の構築
• Reactによるコードの書き換え
• コンポーネントの分割
• 公開

当日作成したPRはこちらです。（コミットコメントがなんちゃってイングリッシュなのは突っ込まないで..）

環境の構築もそうだけど、ビルドがコケたときにどうするか？とかを見ながら話できたのは良かったなって思った。

途中、デフォルト引数の部分でビルドエラーが起きて、原因としては babel-preset-envの設定を書き忘れていた。そのときは .babelrcに env を足してサッと動くようにしたけど、「なんでそのエラーからそれが原因だって解ったんですか？」という声があがって、「あ、うん、そうですよね…」という気持ちになった。

感想

わりといい内容だったんじゃないのかな？と主催者は勝手に思っている。

見てた感じ、モブプロは結構ウケが良かった。またやりたい。

---

※
ちなみに、実際にはLTもあった。けど、オフレコ的な話もあったのでここには書かないでおく。

AgileJapan2017 富山サテライトで発表してきた

2017/6/24に開催されたAgileJapan2017 富山サテライト会場にて機会を頂いたので、発表させていただきました。

資料はこちらです

speakerdeck.com

内容

Misocaでのミーティングやふりかえり方法について、やり方やメリット、注意点などについて話しました。

SIerから転職してからまだ数ヶ月ということもあって、以前感じていたジレンマなども踏まえて話すことができたので、ITベンチャーなどが少ない富山県のエンジニアに対しては響く内容になったのでは？と勝手に思っています。

意識したところ

現実的な話をしたかった

過去の経験として、こういった発表や資料を見た際に、

「すごい！勉強になる！あ、でもうちじゃ無理だわ！！」

と思うことがありました。

前提となっている環境の部分のハードルが高すぎて、とっても参考になるしタメになるけど、導入ができないな〜というものです。 組織が根本から異なるので、やっぱり難しいんですよね。

という経験も踏まえ、少しでも現実的な着地点をお伝えできるように意識しました。

具体的には

• 「人間ってそういうものです」

• 「そうはいっても無理だよね〜」

  ↓

• 「じゃあ、それを踏まえてどうするか？」

みたいな話を交えました。

方法より理解、そして小さくやっていく

上記スライドではあまり触れていませんが、実際の発表時には「とにかくコンテキストや意識を共有するのが大事だよ！」というのを何度も繰り返し話していました。

手法だけを導入しても上手くいかないのは、意識の部分での共有が不足しているために反発が生まれるせいだと思っていて、同時にその意識を共有するという部分が一番難しい点だとも思います。

歴史が長かったり規模が大きい組織では、現実的には無理だろうという部分もあるので、そのあたりも踏まえて、小さくやっていこうね！というお話をさせて頂きました。

---

資料を作る過程で、自分でも「なるほど！こういうことだったのか！」という発見もいくつかあり、とても楽しかったです。

（がっつり資料をレビューしてくれた社内の皆さんには感謝です）

当日参加して聞いていただいた皆様、ありがとうございました。

さー！次は何しよう！

プランニングポーカーをVue+websocketでつくってみた

作ったものの雰囲気は以下の画像を見てもらえればわかると思う

プランニングポーカー大きさわかりにくい問題

プランニングポーカーをやる機会がちょくちょくあり、それについて以下のような話を耳にしたことがあった

• ポイントの差異が直感的ではない
• 8ptは1ptの8倍ある。8倍ってことを意識できてるのかな？

最近は趣味でVue.jsを触ってることも多かったのと、今更感あるけどwebsocketを使ってみたいな〜と思ってたので、それらを利用して自分で作ってみた

github.com

使ったのは

• Vue.js 2.0
• Vuex
• Vuetify
• express

よかったこと

人によって好き嫌いありそうだけど、Vuetifyが結構よかった。

見た目がイケてたので軽い気持ちで突っ込んでみたけど、 必要な要素は一通り用意されてるし、導入も苦労がなかった。

基本的に全てのコンポーネントを *.vue ファイルにしてcssもその中に書いていった。

大きな規模でデザイナーさんがいたりすると違う苦労が出てきそうだけど、個人の趣味で使うぶんには全然コレでいいじゃん！って感じだった。

たいへんだったこと

websocketによるデータのやり取りとVuexによるfluxフローを繋ぐのがややこしかった。

Vuexにプラグインの仕組みがあるので、そこで適宜Vuex向けにmutationをコミットする感じだったけど、なんかどうにもコードが冗長になってワケがわからなくなってた。

あとはまあ、とりあえず細かいことは考えずに作っていったので、

• DBへのデータ保存はまったく考えてない。全部メモリで動いてる
• ソースが汚い

みたいな問題が密かに残っている

つかってもらってみた

実際にお仕事でプランニングポーカーをする際に使ってもらってみた。

結果として、当初の動機だったポイントの大きさの可視化ではなく、 コンセンサスが取れた場合に派手に表示されることのウケがよかった。

コンセンサス＝良い！という考えはそれでいいのかという気もするが、 とりあえず賞賛されて嫌な気持ちにはならないし、それがよかったのかもしれない。

おためし

herokuボタンがあるので、自由に試してもらえば良いかなと思う。

私の無料dynoに乗ってるのも適当に公開してます↓
https://plahhhh.herokuapp.com/

地方中小IT企業から転職してリモートワーカーになりました

新卒で入社した地元富山の企業を辞め、3月からリモートワーカーになりました。

Toyama.rbに来てくれた人などには直接話したりはしてるのですが、一応３ヶ月間は試用期間ということもあったので、ブログには書かないでいました。

（とはいえ、すでに開発ブログで自己紹介エントリを書かせてもらったりはしてるのですが）

転職に至るまで

前職は、いわゆるよくある中小SIerで、基本的には受託開発がメインでした。

ブラックとかそういう類の会社ではなく、わりと良い会社だったのではないかと思います。

ただ、昔ながらのウォーターフォールでの受託開発という性質上、工数（みんな大好き人月計算）と納期との戦いになり、本質的な価値に繋がらない部分に大きなコストをかける必要が多いことに「ぐぬぬ〜」と日々感じる生活をしていました。

自分も含め、環境を変えようと頑張っている人が少なからず存在してはいたものの、社内にも社外にも色々としがらみがあったりして、やはりそう簡単には変えられないのが実情で。

年齢もそれなりになってきて、「このままでいいのか？」と改めて考えた結果、受託開発ではない、 自社サービスを提供している環境で働いてみたい！という思いから転職することにしました。

「〜が悪い」「〜がイヤ」というよりは、会社の目的と自分の方向性がマッチしなくなった、という感じかも。

勉強会に参加するようになったり、Toyama.rbをはじめて違う世界の人に話を聞く機会が増えたりしたことも大きなきっかけになったと思います。

ただ、前職では自分の近くで一緒に仕事をしていた皆さんは良い人が多く、特に最後の上司は現場が自由に動けるよう尽力してくれていました。

そのおかげで通常では難しいような挑戦的な技術選定を行うこともできたので、今のスキルセットに繋がっている部分もあり、とても感謝しています。

リモートワーク

やりたいことをやろうと思ったら、さすがに地元で探すのは難しく、リモートワークという手段を取る必要があった、という感じです。

あくまでも、ちゃんと自分とマッチする会社だろうか？というのを最優先に考えていたので、その上でリモートワークができる会社が無かった場合は転職は諦めていたかも…

現在のところ良い環境に来れたと思っているので、この時の考えは間違ってなかったな〜と思います。

肝心のリモートワークですが、過去にソニックガーデンの倉貫さんにお話を聞いたり、なぜかToyama.rbに多数のフルリモートワーカーがいて相談し放題で何となくイメージできたり、という恵まれた状態だったこともあり、それほど心理的抵抗もなかったです。

いろんな人から「運動不足になるよ〜」とか「体に気をつけて〜」と言われることもあるのですが、冷静に考えると、もともと運動不足なのであんまり気にしてませんでした。 （リモートワークとはまた別の問題として運動しなければいけない、という気持ちはある）

実際転職してみて

今までと一番違うなと思うのは、全員がちゃんと作ってるものの価値とエンドユーザのことを考えているな〜という点。

受託開発の場合も「お客様の価値を〜」みたいなことを聞く機会もありましたが、まあ正直ほぼ綺麗事を並べているだけで、実際は納期までにいかに納品して検収を終えて利益をあげるかが一番重要だったのではないかと。

今の環境では、たとえばボタンの文言１つを決めるだけでも、それが必要なのであればちゃんと時間をとって議論しよう、という姿勢はいいな〜と感じます。

技術的な話をすると、「レベル高くてやべー！」と日々ひぃひぃ思いながら仕事してる感じ。

残業はほぼゼロなのですが、かなりスピード感があるので、１日働くともう十分疲れます。

個人的には一気にレベル１に戻った気分ですが、それがつらいということはなく、学べることも多くて楽しく働けてると思います。

内容的には、それなりに使えるフロントエンド側の知識をメインに頑張ってますが、逆にいうとそれ以外が相対的に一気に微妙なレベルに落ちた感があるので頑張らないとな〜という感じです。

うん…がんばろう

というわけで

今後もToyama.rbを続けつつ、心機一転頑張っていくのでよろしくお願いします。

（リモートワーク関連でも何かイベントとかできたらいいな〜）