勉強会勉強会に参加してきました。
なんか漢字漢字で堅苦しい感じがしますか、なんの事はない勉強会についてみんなで勉強しようという会です。メタ勉強会ですね。
会場は楽天カフェテリアをお借りしました。ありがとうございます。
勉強会についてはみなさん色々な思いがああるようで、たくさんの方の意見が聞けたのは嬉しかったです。「あぁ、やっぱりその辺で苦労してるんだ。」とか「えっそんなコトある?」みたいな感じで話が盛り上がってました。暗黙知が形式知化していく間くらいのフェーズなのかあちこちで話が弾んでいる様子を見ていてニヤニヤしていました。
この日はみんな 「じゃ、それDoorkeeper立てちゃおう」が合言葉になってて、コミュニティが作られていたように思います(Doorkeeperは開催イベントが決まっていなくてもコミュニティページから作成できる)。あちこちで自然発生的に興味のある分野についての話が行われていたりして関西の盛り上がりを感じました。
個人的に特筆すべきは、お久しぶりに伊藤(@JunichiIto77)さんとお会いして神戸周りで地域Rubyの会をやりたいねぇ。とお話できたことでした。一方的に教える・教えられる関係ではなくて対等に話合える場づくりが西脇〜東灘(神戸)で出来たらいいよねって話をしてました。ご興味ある方はコメント打つなりメンションなりしてください。(正直伊藤さんと技術的に対等ってのは厳しいかもしれないですが、まぁなんとか色んな形が模索できればいいかなとか思ってる…)
このあたりの話は元々勝手に Kobe.rbとか Higashinada.rbでもやろうかなぁとか思っていたのでその辺りの話に繋がりそうです。最終的にどういう形になるかわからないですが、楽しくやりたいですね。
※伊藤さんのblogでも言及してくれていた。
DevLOVE関西「勉強会勉強会」に参加しました #DevKan – give IT a try
勉強会勉強会(@hyoshiok)
楽天・吉岡さんのお話。本編前に少しプレゼンテーション・パターン本について少しお話したのは楽しかったです。勉強会のタイプ・分類分けの元になりそうなお話でした。勉強会パターンをまとめると面白いかもねってお話もありましたがこれにも同意。
実は自分もポジションペーパー代わりと自分の考えの整理に何枚かスライドを作っていたのですが内容的には吉岡さんの話に一番似ていました。
# 会議と勉強会。についてはまだもやもやしていますが、まぁこのへんについては勉強会ってそもそもなんなの?って議論をしなければならないでしょう。
勉強会を開催する大まかな流れ(@pwim)
Doorkeeperを開発しているモバリーンの Paulさん。
言語の壁があるのがもどかしい。ってお話でした。この辺がDoorkeeperやTokyoRubyistMeetupを開催する動機になってるんですね。
私もDoorkeeperを使っていますが、言語の壁を取り払えてないのには心苦しい思いをしています。”目指せ英語力UP”ですね。紹介にあるコミュニティの内3つは私が立てたコミュニティだったという衝撃の事実(笑)Doorkeeperの普及に貢献できているならいいなぁと思います。時々 Paulさんともバグや機能について話をしたりするのですが、必要だと思ってもらえたものは即対応してもらえるので信頼感があります。
社内勉強会のお話(@yohhatu)
社内勉強会で困った事とその対応策ノウハウのお話でした。
社内での開催でお困りの方は@yohhatuに相談してみるのが良いかも。
いつもは発表者側にいるイメージのだいくしーさんやirofさんが運営スタッフをやって裏方に徹したいたのは新鮮でした。まぁ、裏方やってても目立ってましたけどね。いろんな事を試行錯誤やってたので良い経験になりました。ありがとうございました。
約一年前の事ですが、cucumber-rails で tableish が削除されています。
History.md
## [v1.2.0](https://github.com/cucumber/cucumber-rails/compare/v1.1.1…v1.2.0)
### Removed features
* The (deprecated) tableish method has been removed. See https://gist.github.com/1299371 for an alternative. (Aslak Hellesøy)
table要素をarrayに変換してくれる便利なメソッドがなぜ削除されたのか…
コミッタの方曰く、Capybaraに強力なAPIがあるんだからいらないでしょ。って方針らしい。
なので v1.2.0 以降では以下のようにするのがよさそう。
https://gist.github.com/4563036
https://gist.github.com/1299371
http://dennisreimann.de/blog/capybara-finder-for-cucumber-rails-deprecated-tableish/
http://www.flickr.com/photos/hsbt/8275763891/
大盛況だったRailsGirlsKyoto 1st.
あれから2週間経ち今年も終わろうとしています。
RailsGirlsKyotoでは事前事後でわりとバタバタして大変でしたが、自分にとってかけがえのない経験になった事は間違いありません。
なにより参加者の皆様からは想像以上の反響を頂きました。イベント自体が楽しかった事や Ruby, Railsに出会えて良かった事などもアフターパーティーで熱く語っていただいたのが特に印象的で「more イベントに是非参加したい。第2回の開催をしたい。お手伝いしたい。」など具体的な内容も耳にしました。Girlsだからなのか京都だからなのかはわからないのですが、皆さんからはすごくパワーを感じました。 (当日の様子は公式blogで !)
続きを読む…
さて本日は “DevLOVE関西2012 Drive” 当日。
スタッフとしての参加なのでバタバタしそうです。
ネット見たり書き込みしたりする暇はないと思われる。
もしかしたらしっかりセッションを聞くこともできないかもしれないので
今思っている事を事前に書いておこうと思います。
DevLOVE関西2012Drive
今回のテーマは “Drive(駆動)”
開発を車などに見立て、前輪を技術・後輪をファシリテーションとしています。
車には前輪駆動の車もあるし、後輪駆動の車もありますよね。
前輪駆動(ぜんりんくどう)とは車輪を有する輸送機器の駆動方式で、前後の車輪のうち前方の車輪を駆動する方式である。
前輪駆動 – Wikipedia
前輪駆動は車を前輪で引っ張り、後輪駆動はその逆で後方から車を押しています。
前輪駆動も後輪駆動も舗装された道を走るのには大して変わらないかもしれません。でも荒れた道を走ってる時に前輪駆動車の前輪がぬかるみや砂、雪にはまってしまうと大変です。唯一の動力源が空回りしてしまうと当然車は前に進みません。
そんな事態を回避する為には四輪駆動が有効です。
たとえ前輪がハマっても後輪が押し出してくれる。後輪がハマっても前輪が引っ張りあげてくれる。悪路でもより安定して走行できる簡単な仕組みです。
すぐれた技術だけで開発できるかもしれない。
合意形成や相互理解をサポートする力でチームを動かすコトもできるかもしれない。
その両方のチカラがあれば、両者がお互いのチカラを深く理解し合えばより開発は安定するのではないでしょうか。技術にフォーカスしている人たちにはファシリテーションに関連する分野にも興味をもって欲しい。ファシリテーションにフォーカスしている人たちには技術への興味をもって欲しい。
よりよい開発。安定したチカラを生み出すためにも。
一人の人間がマルチな才能を持つことに越したことはありませんが、人には向き不向きがあります。誰もが万能にはなれません。一人の人間ができるコトには限界があります。
でもお互いの分野に興味をもって欲しい。その分野の人がどういうコトにフォーカスして、どんな取り組みをしているのかを知っておいて欲しい。そう思うのです。
なにはともあれ、楽しい一日になりますように。
来てくれたみなさんに笑顔でいてもらえますように。
たくさんの交流がありますように。
明日からの開発が少しでも良い方向に変わりますように。
ちなみにAWDってのもあるんだけどね :P
五輪以上を装備する自動車では総輪駆動または全輪駆動 (AWD) と呼ぶことが多く、欧州流の表記では6×6、8×8などとなる。
四輪駆動 – Wikipedia
Advent Calendar募集サイト “Adventar“
コレいいですね。
ちょっとしたモノを作って色んなコトが楽に運用できれば嬉しいですね。
但し、IT系に顕著に見受けられる 25日超えても書き続けるっていう変態行為はできないですね。日付範囲の指定ができれば嬉しいかも?
今年のAdvent Calendarで流行するかな?
最近はけっこうATNDでAdvent Calendarを募集することが多いみたいなんですが、ATNDは何日に書くことになるのかわかりにくく、順番も決めづらいなどAdvent Calendarの募集には向いてないと個人的には思ってたので、Advent Calendarの登録サイトを作ってみました。
Advent Calendarの登録サイトつくりました – Webtech Walker
参考: 師走を楽しもう。技術系アドベントカレンダーの魅力とは – @IT
ScrumBC in 大阪に参加してきた。
詳細なレポートは
Scrum BootCamp大阪に参加してきました #scrumbc – 亀岡的プログラマ日記
に譲るとして
今回思った事など。
やっぱりワークショップはオモシロイ。
ネタバレ禁止な気がするのであんまり書かないけれど
やっぱりチームにはワークショップを定期的にやってもらいたい。
色んな気づきが得られるコト間違いなし。
なんの為にスクラムでやりたいのか
大質問大会の時に思ったのは
どうやってスクラムやるかに頭がいきがちで、
なんの為にスクラムでやりたいのかを忘れがちな気がする。
「どうやったらうまく行きますか?」
「なにから始めたらいい?」
に対しては逆に
「何をどうしたいですか?」
「何のためにスクラムを選択したのか?」
を聞いてから答えたい。
それによってどうすればいいかは変わってくると思う。
(当然コンテキストによって答えは変わってくるよね)
「なんかスクラム導入したらうまく行くんですよね。」
とかいう認識は避けたい。
あと別にスクラムやりますって宣言してフレームワーク使わなくてもいいし
紹介されているやり方を全部キッチリそのままやらなくてもいいと思う。
@nawoto さんも スクラムガイドナナメ読みで
• 軽量
• 理解が容易
• 習得は非常に困難 (←なんでやねん !!)
と紹介されていて、
習得が困難なのは、習得するものではなくて、
みんながそれぞれ創りあげていくものだからと言っていたけれど
それとも合致すると思う。
スクラムマスターの背中を見て学べ!!
もうひとつ
大質問大会の時に思ったのは
質問に答えていたスクラムマスター陣のマインドがなんかすごい。
正直なにがすごいのか言い難いのだけれど、
・詳細までコンテキストを把握しようとしたり (コンテキスト依存の具体的な質問が多かったので、曖昧な答えを出して
もやもやのままで帰って欲しくないという思いからだと思う)
・質問に対する姿勢とか
・全員に合意をとって質問進めるとか (この時間すら自己組織化しようとすのか)
その空気を生で感じるコトがとてもいい勉強になりました。
# 質問の答えが抽象的すぎて役に立たないコトはよくあるし。当たり前のコトっぽくてもできてないコト多いよね。
ひたすら感謝
また関西でやるコトがあればなにかしらお手伝いしたいと思います。
ずっと喋りっぱなしの@nawotoさんと それを支えるコーチ陣 @kawaguti さん、@miholovesq さん
急遽 大質問大会に登壇された@masahirotaguchiさん
会場で設営、TAしてくれた @toshiotmさん や 関西メンバの皆さん
ありがとうございました。
そして最後にこの企画を立ちあげて大阪に ScrumBCを呼び込んだ @yohhatu に感謝します。
毎回検索したりしてるのでメモ
rake db:fixtures:load
test/fixtures に配置した テーブル名.yml(yaml形式で記述されたデータ定義) ファイルをDBに登録する。
テーブル名指定
FIXTURES=x,y
ex. rake db:fixtures:load FIXTURES=x,y
サブディレクトリ指定 (test/fixtures 以下でサブディレクトリを切ってデータを分ける場合など)
FIXTURES_DIR=z
ex. rake db:fixtures:load FIXTURES=x,y FIXTURES_DIR=z
ディレクトリ指定 (test/fixtures 以外でパス指定する場合)
FIXTURES_PATH=spec/fixtures
ex. rake db:fixtures:load FIXTURES=x,y FIXTURES_PATH=spec/fixtures
Load fixtures into the current environment’s database. Load specific fixtures using FIXTURES=x,y. Load from subdirectory in test/fixtures using FIXTURES_DIR=z. Specify an alternative path (eg. spec/fixtures) using FIXTURES_PATH=spec/fixtures.
cucumber で javascriptテストなどをする場合はシナリオごとに @javascript タグを付ける。
テストを実行するとなんらかのWebDriver (デフォルトはselenium) がブラウザを起動して
テストを実行するわけだが、alert や confirm が邪魔になる場合がある。
これらの確認をする必要がない場合は単純に alert や confirm を上書きして
なんの挙動もしないようにしてしまえば良い。
さらに web_steps_ja.rb に利用部品として書いて好きな時にユーザが呼び出せるようにしてしまえば良いかな。
web_steps_ja.rb
module NotificationHelpers
def ignore_notification(page)
page.evaluate_script("window.alert = function(msg) { return true; }")
page.evaluate_script("window.confirm = function(msg) { return true; }")
end
end
World(NotificationHelpers)</p>
<p>前提 /^通知を無視する$/ do
ignore_notification(page)
end
test.features (サンプル)
@javascript
シナリオ: 〜〜〜を登録する
前提 ログイン名が"xxxxx"、パスワードが"yyyy"のユーザでログインしている
前提 "〜〜〜登録"ページを表示している
前提 通知を無視する</p>
<pre><code> 〜以下任意のテスト〜
もし 〜をクリックする
ならば 〜が表示されていること
</code></pre>
<p>
上記テストを実行するとブラウザが勝手に起動してテスト動いていくので selenium に免疫のない人はびっくりしないように :-)
環境:Mac OSX 10.6.7
(RVMの導入方法は他にもありますが、今回の方法では git が必須です。)
RVMは Ruby Version Managerで Rubyの複数バージョンを混在させる事ができるます。またgemsetと仕組みで プロジェクト毎に使用するgemやそのバージョンを切り替えると云う事が可能です。
Macバイナリでの導入の方が楽かなと思っていたのだけれど、なんだかよくわからないので結局 git でインストールする事に。
といっても全然難しくない。簡単。
適当なディレクトリで git clone
$ git clone git://github.com/wayneeseguin/rvm.git
$ cd rvm
$ ./install
以上で インストール環境。
.bashrc に以下を追加。(できれば最後の方に)
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # This loads RVM into a shell session.
.bash_profile に下記の設定がない人はこれも追加。
if [ -f $HOME/.bashrc ]; then
source $HOME/.bashrc
fi
ターミナル再起動
$ rvm -v
rvm 1.2.6 by Wayne E. Seguin (wayneeseguin at gmail.com) [http://rvm.beginrescueend.com/]
2010年に書いた記事が下書きのままだったので改めて公開しました。
一部、下記サイトを参考にしています。
Ruby Freaks Lounge:第39回 RVM(Ruby Version Manager)による環境構築|gihyo.jp … 技術評論社
Ruby Freaks Lounge:第40回 RVM(Ruby Version Manager)による環境構築(2)|gihyo.jp … 技術評論社
そもそも paths.rb の中で Model使えるのかとか思ったのですが、なんの事はない。普通に User.find(123) とかできるのですね。ちゃんと理解していないからこんな疑問が発生するのでしょう。
それはさておき。
when /フォロワーが([0-9]+)人いるユーザのプロフィール画面/
user = Users.find(:first, :conditions => { :follower => $1.to_i} )
edit_user_info_path(user.id)
([0-9]+) など、正規表現でマッチングさせておきと $1 で値渡してあげれば OK
正規表現のマッチングで () 内にヒットしたものが $1, $2…となるのを知らない人は意外にいるようだ。
paths.rb っていうか、結局 routes.rb の話なんだよね。