富山でRubyコミュニティがあればいいのにー！
と言っていたところ、
Toyama.rb が本当に誕生しました。
2015/12/5に第一回もくもく会を行います。
詳細は上記Doorkeeperイベントページから！
（至るまでの経緯などはまた開催後に詳細なレポートを作成します。
2015/11/29現時点では6名/最大10名と、まだ4名分の枠があります。
興味がある方はぜひ気軽にどうぞ！
Ruby初心者なんですけど・・
→そもそも私が初心者なので大丈夫です！
Rubyじゃないとダメですか？
→交流自体もひとつの目的なので全然okです！
勉強会がはじめて or あんまり行ったことないので心配です
→人生初参加の勉強会で富山から兵庫まで行った人が言うには、
行ってみれば意外と「あ、大丈夫だ」と思うそうです。
終わった後には懇親会も予定しています！（自由参加です）
あなたのご参加をお待ちしています！
2015-10-10〜2015-10-11にて、
西脇.rb & 神戸.rb主催の Rubyプログラミングキャンプ 2015に参加してきました！
主催の伊藤さんのブログにも掲載されております。blog.jnito.com
他の参加メンバーと違うのは、
私は「富山県からの参加」というところだと思います。
実際にやったことやタイムテーブルなどは
伊藤さんのブログをご参照いただければ良いかと思うので、
私は勉強会初参加＆遠隔からの参加という観点でレポートにしてみます
仕事ではJava/JavaScriptを主に利用していますが、
以前からRuby/Railsを趣味で触っていました。
ただ、やっていることといえば
と、出家したかのように写経ばかり。
一体次は何をしたら？と、独学の限界を感じ始めていたころ、以下ページに辿り着きました
nishiwaki-koberb.doorkeeper.jp
一泊二日のプログラミング合宿！
これは面白そう！でも・・
今まで勉強会というものへの参加に意欲的ではありませんでした。
参加したとしても、
みたいなケースがほとんど。
自分から「参加してみたい！」と思ったのは初めてだったので、こういう機会は逃したくないー！
でも、どうやら参加には定員があるようで、
パッと見たところ定員はあと１名・・・
「やっぱり人気なんだな。すぐ埋まるだろうし、埋まれば諦めもつくな」
と自分に言い訳をしつつも案内ページをちらちらチェックしていたのですが、これがまた意外と埋まらない。
おもいきって妻に見せてみました。
だめ！って言われたらそれで諦めようと・・・
私「こんなのあるんだよねー、でも遠いからねー、きびしいよねー」
そして
妻「行きなさい！」
（※実際は富山弁）
まさかの背中を押してくれる結果でした。
これが決め手になり、その日の夜には参加ボタンをポチってました。
正直これが無かったら行ってなかったかもしれません。妻に感謝です。
というわけで飛び込んできた勉強会でしたが、ありきたりですが
という感想です！
Rubyでもくもくしに行ったつもりだったのですが、むしろ技術への考え方や姿勢というものを改めて見つめ直すことができたほうが大きかったかもしれません。
そして何よりみなさん優しかったです。
実は勉強会前日からすごい体調が悪く、
声もほとんど出ないような状態で参加していました。
（この芸人さんに近かった）
「うわぁ、変な声のやつが田舎から来たわぁ」
と思われるな、と泣きそうになってたんですが、
そんなことは微塵もなく、とてもフレンドリーに接していただけました。
いままで勉強会といえば、話を聞くだけのようなものがメインでした。
けど正直、そういったスタイルで参加した社外勉強会は、９０％は内容を忘れています。
しかし、手を動かして得た経験は習得具合がかなり違うと思っています。
社内でも定期的に勉強会が行われていますが、これもやはり講師の話を聞くだけの形がほとんどなので、ハンズオン形式も取り入れていきたいですね〜
そして、発表会があったのも個人的には大きかったです。
１日目と２日目の終わりに中間・終了発表の機会があり、一人５分くらいと短いものではありますが、これが集中具合をかなり上げてくれたと思っています。
発表会があるんだ、という簡易的なゴールが設定されていると
と、必然的にダラダラしないで作業をすることができました。
メリハリって大事ですね。
私が調べた限りでは、富山にはRubyコミュニティがありません。
そして、いわゆるWEB系企業というのもそこまで多くないという認識です。
働き方というよりも、生き方のレベルから違う人々と触れ合えるのは
とても貴重な体験になったと思っています。
環境を変えてみる、というだけでも得られるものは多かったです。
遠方じゃなくても集中できるから！という意見もありますが、
遠方の場合は以下のような状態が自動的に発生します
遠方参加の場合はどうしても交通費などが発生します。
今回の私のケースでは、前泊もしたので、＋１日の宿泊費も発生しています。
さらに、気軽に出かけて参加というわけにはいかないので、次に参加できるのは一体いつになるのかはわかりません。もしかしたらもう参加できないかもしれません・・
こうなるともう「やるしかねえ！」という気持ちも少しは発生します。
生々しいですが、こういうのは単純で効果的なのかもしれません・・
参加者のみなさんと仲良くなれた（と私は勝手に思っている）のですが、これで次に会えるのが一体いつになるのか解らない、というのが寂しく、一番残念な点かもしれません。
本当に素晴らしいコミュニティだと思ったので、気軽に行けるなら毎回でも参加させていただきたいくらいでした。
土日での合宿でしたが、私は金曜のお仕事終了後から移動したのですが、これがまたなかなかハード。
移動に５時間以上かかるうえ、体調も悪いということで正直ちょっとしんどかったです。「いけるっしょ！余裕余裕！」とナメてかかっていたのですが、もう学生の時のような若さはないんだな、と悲しい現実を突きつけられた気分でした。
次に遠方の勉強会に参加する機会があるならば、もう少し余裕をもったスケジュールを組んだほうがよさそうです。
「ああ面白かった」で終わってしまうともったいない。
そういうわけで今後どうする？というところを考えてみました。
今回の参加で思ったのは
「参加してみればなんとかなる」というところでした。
積極的に（妻に頼んで）他の勉強会にもどんどん出てみようかと思います。
※ちなみに先週に早速他の勉強会に行ってきました。
リーダブルコード、良書ですよね〜
プログラマならぜひ一度は読んで欲しいと思いました
最近社内で勉強会でスピーカーをする機会があったので、
この本の内容の紹介と、特筆して紹介したい部分を話しました。
ただ、その際の資料作成と実際の勉強会での反応を受けて、
いろいろ思うところがありました。
リーダブルコードに書かれている内容はすばらしいです、
やっぱり綺麗なコードが一番だと思います。
でも、やはり現実的には理想論的な部分もあると思います。
納期が存在する受託開発の場合、
どうしても付きまとうのが「で、間に合うの？」という話。
私：どうですか！？すごい読みやすくて綺麗なコードでしょう！？
上司：で、間に合うの？
私：いえ、無理です！！
上司：おい！
こうなるのは目に見えています。
そこで思うのは、
「そんな一気に綺麗にしようとせずに、少しずつ全員の意識を変えればいいじゃない」
という案
でも・・・
全員が「いつものメンバー」なら問題なしです。
でもよくある状況として
私：この期間だときびしいです！
上司：あと１ヶ月で４人月ぶんだな！よし、BPと新人で４人投入だ！
私：うわー！！
こういうケース。
妊婦さん９人集めても１ヶ月じゃ赤ちゃんは産めないの！！
上の例は結構極端ですが、
一時期だけ入ってすぐ抜けてしまうようなメンバーがいた場合、
リーダブルコードを徹底することによるメリットが薄くなってしまいます。
徹底したとしても
私：いいですか、綺麗なコードを書いてくださいね！
BPさん：はい、わかりました！
〜１ヶ月後〜
BPさん：どうですか！綺麗なコードでしょう！
私：すてき！
上司：で、終わったの？
BPさん：いえ！では契約終了なのでさようなら！
私：さようなら！
上司：おい！
こうなります。
そして最大の障壁が・・・
リーダブルコードの勉強会内で
「returnを使ったガード文を利用してネストを浅くするといいですよ！」
と紹介しました。
すると、
「returnは１個しか使ったらダメだって教わった」
という意見が聞けました。
リーダブルコードに書かれている内容の中には、
古くからエンジニアをされている方が教わった内容と
相反する部分がどうしても出てくるようです。
他に考えられる例としては、たとえば
「変数は使う箇所の近くで定義する」
なども挙げられると思います。
こういうときにどう説明するのかが難しいな〜、
というより、どう説き伏せるかを考えないといけないんだな、と感じました。
色々と問題がたくさん。
どうしていけばいいんだろう・・・？
私はあくまでも「リーダブルコードは素晴らしい」という考えです。
やっぱりこの考えは広めたい。
自分なりに少し考えてみました。
ただし、あくまでも納期などを考える必要があるため、
ここでいうアンチパターンというのは
「こういうコーディングをしてはいけません！」
ということではなく
「こういうのはあんまり綺麗じゃないですよ」
というもの。
期間が無い状況などで出来るだけ高い効果を出すためには
ガチガチにしばるのではなく、ざっくりとした方針だけを示すのがベストだと思います。
そのときに、やはり口頭だけでは分かり難いので、
簡単な例を用意しておけばいいのかな〜と思いました。
極端な例ですが、たとえば変数名で
var newOrderIdForRegistrationNewManagedUser
とかを見せて、「ほら、長いでしょう？」みたいな。
覚えさせるよりも雰囲気を感じ取ってもらうほうがいいと思います。
先ほどの例でいうと
「returnは１個だ！」
と言われて
「は！？バカじゃねえの！？」
と言わないようにしましょう。
今、returnを複数使うことで読みやすくなるケースがある、というのに理由があるように、
returnは1個だ、というのも根拠があるということです。
かくゆう私も「なんでだろう？」と思って調べたところ、
構造化プログラミングの考えから、goto＝悪！みたいな認識が広がり、
制御ルーチンは上からちゃんと読めるようにしようね！
↓
途中でreturnしたら飛ぶからこれもやめようね！
みたいなことだという認識です。
でもこれも立派な考えであり、先人の知恵です。
これを認めた上で
・言語や取り巻く環境などが変わっていること
・むしろreturnが多い方が可読性が上がること
などを説明すれば分かってもらえる・・・かもしれません。
（だめかもしれないけど
でました！精神論！
もはや究極はコレかなと。
もう正直、自分だけでも徹底的に頑張るしかないと思いました。
そしてその上でパフォーマンスも出すと。
身をもって綺麗なコードのメリットを証明するのが一番説得力がある気がします。
と言ってしまうとひどいですが、
案外周りを見渡すと同感してくれる人がいるもんだと思います。
むしろ意外と多いかもしれませんよ。
少しずつ意識改革を広げていくのも重要なことだと思います。
というわけで、結局何が言いたかったの？みたいな内容でしたが、
私は綺麗なコードを書いていきたいです。
お わ り
Railsを利用して、１本学習系のサービスを開発中です。
そこに付与する認証機能として、
やはり独自でemailなどの情報を保持しておきたくないので、
Omniauthを利用して
を利用しようかと考えています。
Google先生に教えていただきながら進めていくと、
どうしても出てくるのが Devise という名前。
認証に関わるような「あるある処理」を一括実装できるようで、
いろいろ説明を読んでいると、たしかにすごい。
でも、触っていると（私が初心者だからもあると思いますが）疑問が湧いてきます。
いろいろな機能が一気に突っ込まれることは理解できましたが、
私自身使いこなせる気がしていません。
たしかに各所に存在する情報を利用すると、
簡単に認証系が実装できましたが、
一部はなんとなく動作を把握できましたが、細かいところは個人的にブラックボックスです。
「使いこなせないお前が悪い」、と言われたらそれまでなのですが、
まずはRuby on Railsでの認証のなんたるかを把握してから
こういうものに手を出したほうがいいのでは？という気持ちになってきました。
普段の業務では Java/javascript を利用しており、
OSSのライブラリやフレームワークを利用することも多々あります。
ただし、トラブルが起きた際にはソースを読んで動きを追うことも多々あります。
javascript系のライブラリであれば、実際に手を加えて直すこともあります。
ただ、これをJava/javascript初心者だったころにやれと言われたら無理だった気がします。
今のところ一人で進めている開発なので、
何か起きた時に自分で対応できるよう、認証系でDeviseは利用しないことにしました。
正直、DeviseというGemはすばらしいと思いました。
あれだけのものを、瞬く間に作れてしまう。これはやはり驚異的です。
こういったものを有効活用して効率的に作成するのもRailsの魅力だと考えているので、
いずれ自作した認証部を置き換えてみたいと思います。
でも実際のところ業務とかでは使うのだろうか？
認証と言っても、やはりサービスモデルによって色々差異はあると思いますし、
すべてが共通だとは思えないです。
Deviseを入れてカスタマイズするのと、スクラッチで作るのを天秤にかけて
より効率的なほうを選んでいく感じなのかな？
うーん、やはりまだまだ未熟でございます。。
最近、自分の仕事もしながら、新人さん一人の教育担当もやっています
その中で、
「ああ、こういうことを意識してもらえればな〜」
ということが多々あります。
新人さんに意識してほしいことを、
ちょっと自分なりにまとめてみました。
※ただ、私自身もまだまだ未熟者です。
以下は自分自身に言い聞かせる意味も込めてです
よく聞くのが
「合ってるはずなんですけど・・・」
「書いてある通りにやったんですが・・・」
みたいなワードです
気持ちはわかります
私も言いたくなること多いですから
でも、よほどのことがないかぎり、
コンピュータは我々人間とくらべて遥かに正確です。
我々の間違った指示通り、正確に間違ってくれるのです
まずはそこを冷静に受け止めましょう。
たとえば、なんらかの環境を構築する際など、
ちゃんと動かないケースがあると思います。
こういうときは、まあググって調べるのももちろん良いですが、
１つずつ潰すことで、怪しいと思われる箇所を狭めていきましょう
そもそも自分の作業工程が正確か、あらためて確認しましょう
- 本当に１字１句正しいのか？
- 無意識に飛ばした工程などはないか？
意外と多いのが、調べるだけ調べてから
「この工程が抜けない？」
「このライブラリ入ってなくない？」
「これファイル名違わない？」
みたいなケースです
私もやらかすことはあるので決して怒ったりはしませんが、
お互いになんとも言えない悲壮感が漂います。
環境の差異を確認しましょう。
などです
案外些細なことがキーだったりすることも多いものです
ミドルウェアの構築などの場合、ログが超重要です。
慣れてくると当然のようにログを見るのですが、
新人の子の場合「ログを見ればいいんだ」ということを
最初は解らないようです。
「どこかにログがないか？」
ということを意識しましょう。
早めに質問をするのも技術です
新人である間のほうが、質問に対し快く回答してもらえます
個人的には、手が止まってしまったら質問したほうがいいと思っています。
「手が止まる」というのは、
打つ手がなくなったことを指します。
もちろん自分でやれるだけのことはやる努力はしましょう。
Googleなどで検索した情報を参考にするのは構いませんが、
それをすべて鵜呑みにしてしまわないようにしてください。
自分の中で「信用できる！」という理由を見つけてから使うようにしましょう
などでしょうか。
これについては明確な回答はなく、感覚的な部分も多いかと思います。
内容が心配であれば有識者に聞きましょう
うまく質問をできたほうが、解決も速くなります
以下を先に整理すると良いと思います
地味に6が重要だと思います
質問される側からすると、
頭の中でどこまでの引き出しを開けるべきなのか考える必要があるため、
「この子はどこまで理解済みなのだろう？」
という情報を先に知りたいものです
この頭の引き出しを探す作業は結構疲れるので、
先に理解度を伝えること自体が相手への配慮になります
ざっと思いついたのはこんな感じです。
果たして私がちゃんと出来てるのか？みたいな点もあるのですが、
とりあえず上記を意識してもらえれば、
時間を無駄にせず、先輩も優しく接してくれる（重要）のではないでしょうか
bootstrap先生のパワーもあるとは思いますが、
見た目的にもそれっぽくなってきたような気がします。
ここまでで気付いたところなど。
まだ先の章を見ていないのでなんともいえませんが、
scaffoldが登場しないなとふと気づきました。
初心者向けの書籍やサイトを見ていると必ずといっていいほど
といったパターンが多いと思います。
そういうもんなのだな、と勝手に思っていましたが、
今のところRailsチュートリアルでは出番なしです。
ふと、scaffoldって実務だと使わないのか？という考えにいたり、
調べていると、参考になりそうなエントリがいろいろと。。
RailsのScaffoldは単なるマーケティングツールで実際の開発では使わない？ - QA@IT
Rails Q＆A「Scaffoldで作成されるテストはそのまま使うべきか？」 - give IT a try
いまのところ
「使わないことはないけど、フル活用するわけではない」
と勝手に解釈しています。
たしかに初めてscaffoldを使ってみたときには、「すげー！』と思いましたが、
勝手にあれだけの量のソースを生成されるのは若干不気味な感じもしました。
個人的には1つずつアクションを作っていくほうが好みかも？
Userモデルに remember_tokenというカラムを増やすところで、
なんだかうまく追加できない事象に陥って少しハマりました。
結果、以下手順で解決
rails sでサーバを起動している場合、一旦止めるrake db:migrate:resetrake db:migrate:reset RAILS_ENV=testポイントは
の2点でした。
普通にやっていれば問題なくいけるのだと思いますが、
私の場合、一度空のmigrationファイルを実行してしまってからおかしくなりました。
8.18、以下テスト実行です
rspec spec/models/user_spec.rb
エラー内容
`method_missing': undefined method `its' for RSpec::ExampleGroups ::User::RememberToken:Class (NoMethodError)
原因
itsメソッドがRspec3.0以降で消滅しているらしい。
expectを利用した形式に書き換えればokだった。
(チュートリアル内にも、"itsはこれと同義だよ！"みたいな記述はある）
ただ、ワンライナーを意識する場合には以下のように置き換えるといいっぽい
it { is_expected.not_to be_blank }
GemfileにGithubへのURLも記載しているが、いらないっぽい
gem 'database_cleaner', github: 'bmabey/database_cleaner'
↓
gem 'database_cleaner'
アプリ固有のモジュールってどこにおけばいいんだ？
というのがいまひとつ解ってなかったのですが、
普通にHelperに書いても良い感じなのですね・・・
viewからの参照用のメソッドのみを定義するものかと思ってたのですが、
普通にcontrollerでincludeして使っていい感じのようです。
（お仕事で利用されている方からしたらどうなのでしょう？）
とはいえ、大きいモジュールになってくると
なんでもかんでもHelperにいれてたら大変なことになりそう。
concernを使う？lib配下に置くのか？
課題として覚えておこう・・・
Windows環境でRailsチュートリアルを進める中で、
Macとどうしても比較してしまうのが、ターミナルの使い勝手
基本的にgit bashを利用して全て作業していたのですが、
これを機に調べてみたところ、cmderというのがいい感じっぽい
というわけで導入してみたのでメモ
zip落としてきて解凍して終了
Visual C++ runtime をインストール http://www.microsoft.com/ja-jp/download/confirmation.aspx?id=48145
完璧にする方法は無さげ。とりあえずlsで化けなくする
~/.bash_profileを編集
alias ls='ls --show-control-chars'
~/.vimrcを編集
以下を追加
set encoding=cp932 set termencoding=cp932 set fileencoding=utf-8 set fileencodings=utf-8,cp932
なんかvimでバックスペースが効かなくなった！ (Shift押しながらだと効く）
SublimeText使うから別にいいし、と自分に言い訳して現実逃避中
というわけで、上記設定したらこんな感じに
ちょっと半透明なのがcool そして普通に使いやすい。
（しれっと６章までおわりました）
