発言駆動日記

何事も発言駆動な日記。HDD

Rails3環境構築

for Windows


1. RailsInstallerパッケージをダウンロード

2.こまったらトラブルシューティング

以上 

 

for Mac OS X


1.Xcodeのインストール

次のコマンドでXcodeのバージョンを確認する。

$ xcodebuild -version 

Xcodeのバージョンが3ならGitを個別にインストールする必要があるので、ここからダウンロードする。

次のコマンドでGitのバージョンを確認する。

$ git --version

 

2. RVM(Ruby Version Manager)のインストール

下記コマンドでRVMをインストールする。詳細はこちら

$ bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer) 

上記のコマンドに従ってインストールを行う。(必要なインストールを教えてくれる)

ターミナルを開き直し、.bash_profileを読み直す。

 

3.Rubyのインストール

下記のコマンドでRubyインタプリタをインストールする。

 $ rvm install 1.9.2 

 

4.Railsのインストール

完了したら、その環境を使ってRailsをインストールする。

 $ rvm use 1.9.2 $ gem install rails 

rvm use はシェルを開くたびに繰り返す必要があるので、必要なら下記コマンドでデフォルトを設定しておく。

$ rvm default 1.9.2

次のコマンドでインストールに成功したかどうかを確かめる。 

$ rails -v

何か困ったらトラブルシューティング

以上。

DevSumi2012へいってきました。

DevSumi2012 二日目に参加しました。

聴講したセッションのうち、記憶に残った部分を綴っておこうと思います。

  1. 差別化で未来を生き抜く エンジニアの7つの秘訣 山本祐介氏
  2. オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来 倉貫義人氏
  3. アジャイルマニフェスト ディケイド 角谷信太郎氏

 

 

差別化で未来を生き抜く エンジニアの7つの秘訣


現在TwitterJapanで活躍中の山本氏による講演。これまで大手Sierやソフトウェアベンダーなど、多数の組織を渡り歩いてきた経緯を交えて、今後のキャリアビジョンやこれからを生き抜く為の秘訣をお話されました。公演中にTwitterを利用して参加者からの質問にその場で回答するなどの試みもありとても面白かった。

先を見据えるのは難しい

自分のキャリアビジョンをどのように考えているかについて。先を見据えて今を考えているように思われることも多いが、そもそも10年先の未来を見通すのは無理と断言。いつ(所属する組織を)やめるか、ではなく、このままで自分を差別化できるかどうかが重要。(会社の売り上げとかネガティブなことじゃなくて、どうやったら自分を差別化できるか。昇進が全てって時代でもないし、他の人と同じにならないことが重要と)

大事なことは、学べるか? 楽しいか? (普通に)稼げるか? の3つ。

2、3年後にも使えそうな技術だと思えばしっかり学ぶし、一過性だと思えばちょっと覗いてみるくらいにとどめる。デスマーチでもそこで楽しいと思えればいい(笑)そこにマーケットがあるから身を置いているだけ。楽しいか、学べるかが大事。

 

「知っていること」による差別化

まず情報収集からはじめる。RSS使いましょう! ブログやツイッターなどで教えたがりの人を利用する。情報発信と収集を同時にする。知らない人とのつながりができ、ブログでコメントし合ったり時々勉強会で出会うようになる。そして同じ方向を持っている人とつながるようになる。そういうつながりが大事。

 

問題解決による差別化

困ったことを解決してくれるやつになる! 楽をするためならどんな苦労でもする。 問題を解決する範囲はできるだけ広い範囲であることが大事。プロジェクトより会社より個人より世界へ! オープンな世界で自己顕示しよう。 会社の中で便利なやつになってもしょうがない。(そこで満足するのは避けたい) よりスケールアウトしていく差別化が大事。

 

言語による差別化

Javaは今後も安泰。COBOL2.0と言っても良いくらい、今後10年以上生き続けると思う。 日本語は安泰? 将来安泰な言語は? やっぱり英語大事。(ちなみに、氏は4歳までデンマークにいたが、そのころの記憶はほぼ皆無。外資系の組織にいることが多かったため英語はある程度つかえるが、英語自体は好きな映画を観ながら学んだ。勉強することはあまり好きではないので留学とかスクールには行かなかったが、好きな映画のフレーズを覚えたりして学んだ。とのこと)

 

 

オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来


現在SonicGarden代表の倉貫氏による講演。6年前、氏がブログで提案した「納品しない受託開発」を実践するに至る過程と、今どのようにそれを実践しているかについて、コミカルかつ超高速なトークで駆け抜けた50分。SIerで働く人にとっては耳の痛い問題を鮮やかに暴き、将来の展望を語る。個人的には最も印象に残ったセッションでした。

SIerは死んだ魚の目をしている

学生時代にベンチャーに参加し、バリバリのプログラマだった氏が95年に入社したSIerで感じたこと。要件や設計はコンサルタントに任せ、開発は下請けに依頼するマネジメント偏重の組織だと感じた。また、それでうまく行っているわけもなく現場の社員は読めないコードに苦戦しながら仕事をしていた。技術力を買われデスマーチプロジェクトに招聘されるたびに「この一年戦争を終わらすのはおれだ!」とアムロばりに意気込むも壁は高く、「プログラマにはなにもできないのか」と痛感すること度々。

 

脳のブレーキを壊す人との出会い

 社外の勉強会などへ参加を始め、それまで自分の延長線上にはないと思っていた本を書いてる人や講演者と関わりができた。(一緒に飲みにいったりすると、案外普通のおっさんだったりして、自分の人生の延長線上にもそいう活動がありなんじゃないかと思えるようになった)そのころ、Extreme Programming(XP)に出会う。会社でダメと言われていたことは全部Kent Beckが推奨していた。

 

環境自身をむしろ活かす

Kent Beckのやり方でマネジメントをやってみた。上の人は話を聞いてくれないので新人教育で広めていくことに。そうするうち、徐々にアジャイルなチームが育ってきた。チームを率いて赤字で火を噴くプロジェクトに自ら志願し、プロジェクトを助けにいった。切羽詰まった環境の中では氏の意見が受け入れられられることも多く、こっそりXPの技法を取り入れてみる(ペアプロのような用語を使わず、「ここは難しいので2人でやってもらいましょう!」みたいにすると大丈夫だった)そしていくつかのプロジェクトは氏によって救われることに。(氏曰く、「もともと赤字のプロジェクトなので失敗しても咎められず、むしろ成功すると高い評価を得られた(笑)」)

 

納品しない受託開発

2005年にチームが解散し、プログラマに戻りたいと熱望する氏。アジャイル悪くないが、ビジネスモデルがしっくりこない。アジャイルディフェンシブな開発SIerみたいなやり方)はあっていないと感じる。そして社内ベンチャーを立ちあげ、自ら提案するビジネスモデル「納品しない受託開発」をスタート。(「納品しない受託開発」についてはSonicGardenのWebページ氏のブログが詳しいのでそちらを参考にするとよいと思います。)

 

プログラマを一生の仕事に

プログラマはマネジメントされない方がよい、彼らはナレッジワーカーだしそういう人はいつでも仕事のことを考えている人だから。そして小さな組織の方がいい、大きな組織ではどうしても人月ビジネスになってしまう。とすれば、信頼しなければならない。会社の顔ではなく、自分の顔で信頼関係を築くことができるような、個人の顔が見える範囲の会社がよい。

 

 

アジャイルマニフェスト ディケイド


アジャイルといえば角谷氏の顔が瞼の裏に浮かび上がってくるようになってきた今日この頃。そんな角谷氏による講演。アジャイルマニフェストが提唱されてはや10年。そのディケイド(10年)を振り返る。かなり広い会場の一番後ろで聞いていたのと、角谷氏独特の話術(ネタ)に会場が度々笑いの渦に巻き込まれたこともあり、聞き逃した内容もたくさんある気がします。相当エキサイティングな講演になってました。

 

角谷氏語録

”少しずつ成長させていく 関わる人の気持ちに近づく 人間の感性に深く基づく”

”そして17人のヒーローがアジャイルマニフェストをつくった...”

”いままでバラバラだった世界から悪いやつが集結している(ソフトウェア業界とおなじだ)”

ウォーターフォールが前提では回らなくなってきている(弱りつつある)。そしてアジャイル開発がでてきた(ウォーターフォールじゃないやつとして)”

”これからはリトルピープルの時代。一人が自分の目の前の問題を解決していく時代”

”ソフトウェアは頭の中にある。 実際にコードを動かしてみてもまだ頭の中にある。実際に使ってみて始めてわかる。認識してはじめてわかる。ソフトウェアは目に見えない。”

”世界観を作り出す。世界を作る。文字列を並べるだけの簡単なお仕事ではない。だからコードを大事にしなければ。”

”プログラミングとはコードにしたものとコードにしなかったものだ。”

”人の考えをコードに変換するのがプログラマの仕事。すごい力には思い責任が伴う。”

”人とソフトウェアの間に価値がある”

”すこしずつ成長させる。 感性に基づいて。 繰り返し実施させる。 そしてソフトウェアを成長させていく。 自然なソフトウェアに近づく”

アジャイルとは形容詞。 アジャイルは度合い。どれだけアジャイルにやれているか?”

”現場はそれぞれちがう。そこにぴったりはまるプラクティスはない。”

”3回起きればパターンだ。 それに名前をつける。 他の人が使える様になる。”

”名前は流通させる為にある。 ただし、氷山の一角でしかない。”

”ひとつとして同じ現場はない。現場ライド。その中で考えなければならない。”

”ひとりひとりがヒーロー気分でがんばらないと。”

”自分のコンテキストに照らしながら、アジャイルマニフェストを読んでみる。”

アジャイルできない理由はたくさんある。もし、そういう制約がなかったとして、本当に良いソフトウェアができるのか?”

”普通の人がセイヤーー!できるのか?”

”ソーシャルコーディングGithubに飛び込む。飛び込んで掴まないといけないんじゃないか?”

”内側の質(コード)を高める必要ある。安らげるような気持ちにならないとだめ。内なる平和。”

”仕事だと思って理想を演じてみる。迷ったら仕事だとおもって演じる。”

”偉大なる問い(質問)になりたい。”

 

 

所感


 DevSumiのような勉強会に参加することで感じるのはプログラマが世界を動かしているということ。世界を変えるきっかけを生み出しているということ。価値観を大きく変えるきっかけになるし、知見を広げるチャンスでもある。すばらしい講演者はみな人のつながりを大切にしている。広がりを生み出そうとしている。ということでとてもモチベーションがあがるので、今後も参加し続けたいと思います。

読書会の宿題

先日、参加を始めて3回目となる由緒あるアジャイル読書会(現在21回目)にて、「なぜ読書会に参加する事にしたか」を知りたいという意見(宿題)をもらいました。

せっかくなので、ブログにしてみます。

 

遡る事8ヶ月、僕はウォーターフォールな思考に憑かれていました。

ソフトウェアを創るなら設計図と仕様書を完璧に仕上げなければならない。それをプログラマに投げれば、絵に描いたものが完璧に出来上がると信じていました。

 

8ヶ月前、入社直後のJava開発研修の真っ只中でした。

画面遷移などの簡単な仕様書が5人構成のチームに配布され、それを元に2週間で設計と実装を行いました。

 

完璧な設計図作りに憑かれていた僕は、他のチームが実装に取りかかるなか、1週間経っても信じられる設計図作りに余念がなく、シーケンス図とかクラス図とかのレビューをひたすら繰り返していました。

結局、ほかのチームの半分くらいの実装期間で目的のWebサイトを作れたし、まずまずの結果でした。(今思えば、自分で設計して自分で実装したし、要件の変化もほとんどない開発シミュレーションだったので、できて当たり前か。。)

 

その頃、先輩社員(@shiraco)に「設計は紙とペンでささっと書いて、はやく実装する方法もあるんだよ」とアジャイルコメントをもらったりしたのですが、さっぱり理解できませんでした。

 

その後、配属先も決まり、そこではアジャイル開発をやっているという噂を知りました。

アジャイルという言葉はそこで始めて知ったので、何だろうと思い適当に「アジャイルプラクティス」という書籍を購入し、読んでいました。(ちょうどその頃はCOBOLの研修をしている最中でした)

COBOLを学びつつ、「アジャイルプラクティス」や、先輩社員(@shiraco)から借りた「プログラマが知るべき97のこと」を読んでいるうちに、今まで見えていなかったソフトウェア開発の難しい所が見えてきた気がし、設計至上主義の呪いからも徐々に解放されてきた感じでした。(たぶん、この辺でアジャイルに興味を持ち始めました)

 

 やっと例のアジャイルなプロジェクトに配属され、しばらく様子を見ていましたが、どうやらうまく行ってるとは言いがたい感じ。半年ほど身を置いてみてアジャイルな人とそうでない人比が1:9みたいに感じられてきました、あくまで感覚ですが。以前参加したDevLoveというイベントで感じたアジャイルへの熱意みたいなものでその場全体が盛り上がっている感じがないのかもしれないと。

 

どれだけアジャイルな人でも、そうじゃない人に囲まれるとアジャイルできない、という実態を見た気がしました。

 

 アジャイル読書会に参加したいと思ったのも、自分がアジャイルである事を目指しアジャイルさを磨いていく為の思いが消えて無くなるのが嫌だったからだと思っています。この半年でソフトウェア開発に対する考え方がずいぶん変化してきていて、やっぱりアジャイルの方が楽しそうだし世の中をよくできそうな気がしています。

 

アジャイルな仲間がいれば続けていける。

 

かなり強引にまとめてしまいましたが。そう思って、これからも読書会にでかけていきます。