profile
Author:馬場一樹(kbaba1001)
旧名：あられ高菜、五月雨へちま．
2012年4月からWEBプログラマになった。まだまだ初心者。
Counter
MacのRails等の開発環境構築めも
■XCode
普通にインストールする。
その後、XCodeを起動してpropertiesを起動する。
DownloadからComand line Toolsをダウンロードする。
このとき、AppleIDでDeveloperに登録して置かなければならない。
■HomeBrew
バージョン管理ツール。MacPortsより依存関係でインストールされるソフトウェアが少ないらしい。
コマンドはapt風。
次のコマンドでインストールできる。
$ /usr/bin/ruby -e "$(/usr/bin/curl -fsSL https://raw.github.com/mxcl/homebrew/master/Library/Contributions/install_homebrew.rb)"
https://github.com/mxcl/homebrew/wiki/installation
http://mxcl.github.com/homebrew/
■rvm
複数のバージョンのRubyを管理できるソフト。でもrbenvのほうがいいかも。
インストール
$ curl -L get.rvm.io | bash -s stable
設定の読み込み
$ source ~/.rvm/scripts/rvm
$ source ~/.bash_profile
ルビーのインストール
$ rvm install 1.9.3
指定したバージョンのRubyを使う
$ rvm use 1.9.3
https://rvm.io//rvm/install/
■sublime text 2
エディタ。使い始めて1か月ほどだが結構気に入っている。
.bash_profileに次のエイリアスコマンドを記述しておく。これによりターミナルからsublime textを起動できるようになる。
alias subl="/Applications/Sublime\ Text\ 2.app/Contents/MacOS/Sublime\ Text\ 2"
http://www.sublimetext.com/
■Rails環境
Ruby on Rails Tutorialに従って、Rails環境を構築する。
http://ruby.railstutorial.org/chapters/beginning?version=3.2
まずRubyGemsをダウンロードする。
展開したディレクトリに移動して、
$ ruby setup.rb
インストール完了後、~/.gemrcを作成して、次の内容を記述する。
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri
$ gem install rails -v 3.2.3
で、Railsをインストールする。
普通にインストールする。
その後、XCodeを起動してpropertiesを起動する。
DownloadからComand line Toolsをダウンロードする。
このとき、AppleIDでDeveloperに登録して置かなければならない。
■HomeBrew
バージョン管理ツール。MacPortsより依存関係でインストールされるソフトウェアが少ないらしい。
コマンドはapt風。
次のコマンドでインストールできる。
$ /usr/bin/ruby -e "$(/usr/bin/curl -fsSL https://raw.github.com/mxcl/homebrew/master/Library/Contributions/install_homebrew.rb)"
https://github.com/mxcl/homebrew/wiki/installation
http://mxcl.github.com/homebrew/
■rvm
複数のバージョンのRubyを管理できるソフト。でもrbenvのほうがいいかも。
インストール
$ curl -L get.rvm.io | bash -s stable
設定の読み込み
$ source ~/.rvm/scripts/rvm
$ source ~/.bash_profile
ルビーのインストール
$ rvm install 1.9.3
指定したバージョンのRubyを使う
$ rvm use 1.9.3
https://rvm.io//rvm/install/
■sublime text 2
エディタ。使い始めて1か月ほどだが結構気に入っている。
.bash_profileに次のエイリアスコマンドを記述しておく。これによりターミナルからsublime textを起動できるようになる。
alias subl="/Applications/Sublime\ Text\ 2.app/Contents/MacOS/Sublime\ Text\ 2"
http://www.sublimetext.com/
■Rails環境
Ruby on Rails Tutorialに従って、Rails環境を構築する。
http://ruby.railstutorial.org/chapters/beginning?version=3.2
まずRubyGemsをダウンロードする。
展開したディレクトリに移動して、
$ ruby setup.rb
インストール完了後、~/.gemrcを作成して、次の内容を記述する。
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri
$ gem install rails -v 3.2.3
で、Railsをインストールする。
Semantic Versioning 2.0.0-rc.1の和訳【日本語化】
Semantic Versioning 2.0.0-rc.1
はソフトウェアのバージョン番号の付け方について提案しています。
まだ和訳している人がいないようなので勝手に日本語版を作ってみました。
ただ、私は英語がすごく苦手な人なので誤訳が多いと思います。
正直自分でもどうかと思う部分も多々あるので、間違っている部分やもっと上手な翻訳を指南してもらえると幸いです。
翻訳について筆者であるTom Preston-Wernerに特別に連絡はしていません。
これはCreative Commonsライセンスの表示があったためです。
以下、和訳です。
ソフトウェアマネジメントには、「依存関係の地獄」と呼ばれる恐ろしい場所が存在している。あなたがシステムを育て多くのパッケージを統合すると、ある日あなた自身がこの地獄の中にいることに気付くだろう。
多くの依存関係を持つシステムにおいて、新しいパッケージバージョンをリリースすることは、すぐに悪夢を生み出すことになるだろう。もし依存関係がきつすぎるなら、バージョンを固定してしまう危険性がある。（全ての依存パッケージの新しいバージョンがリリースされなければ、パッケージを更新できない。）もし依存関係がゆるすぎるなら、必ずバージョンの乱立を味わう事になる。（ずっと未来のバージョンとの適合性がでしゃばってくる。）バージョンの固定や乱立が発生する依存関係の地獄は、あなたのプロジェクトの進展を簡単に妨げる。
この問題の解決策として、どのようにバージョン番号を割り当て更新するかについてのシンプルなルールを提案する。このルールを実行する前に、あなたのパブリックなAPIでこのルールを使うことを宣言する必要がある。それはドキュメントによって構成されるかもしれないし、コードそのものによって強制されるかもしれない。是が非でも、このAPIが明白かつ正確であることが重要である。まずあなたのパブリックなAPIを確認し、バージョン番号を特別に増加することによってその変更を伝える。バージョンの形式をX.Y.Z(メジャー.マイナー.パッチ)で考えましょう。APIに影響を及ぼさないバグフィクスではパッチバージョンを増加する。以前の物と互換性のあるAPIの追加／変更はマイナーバージョンを、互換性のないAPIの変更はメジャーバージョンを増加する。
私はこのルールを「セマンティックバージョニング」と呼ぶ。この計画の基づくことでバージョン番号と変更理由により、潜在的なコードが意味することと、あるバージョンから次のバージョンまでに何が変更されるべきかを伝える。
この文書中のキーワード、「必須 MUST」「必須 MUST NOT」「必須 REQUIRED」「必須 SHALL」「必須 SHALL NOT」「要請 SHOULD」「要請 SHOULD NOT」「要請 RECOMMENDED」「可能 MAY」「可能 OPTIONAL」は、RFC 2119 に従って解釈して下さい。
１．セマンティックバージョニングを用いたソフトウェアではパブリックなAPIを宣言しなければならない(MUST)。このAPIはコードの中に宣言されるか、ドキュメントで厳密に存在していなければならない。ただ行うだけでなく、正確でわかりやすくあるべきだ(SHOULD)。
２．普通のバージョン番号は、X.Y.Z(X, Y, Zは正の整数)という形式でなければならない(MUST)。Xはメジャーバージョン、Yはマイナーバージョン、Zはパッチバージョン。それぞれの要素は１つずつ増加しなければならない(MUST)。例えば、1.9.0 → 1.10.0 → 1.11.0
３．メジャーバージョン番号を増加したら、マイナーバージョン番号とパッチバージョン番号を0にリセットしなければならない(MUST)。マイナーバージョン番号を増加したら、パッチバージョン番号を0にしなければならない(MUST)。例えば、1.1.3 → 2.0.0 かつ 2.1.7 → 2.2.0
４．一度バージョンを割り当てたパッケージをリリースしたら、その内容を変更してはならない(MUST NOT)。どのような変更も新しいバージョンをつけてリリースしなければならない(MUST)。
５．メジャーバージョン0(0.Y.Z)は、初期の開発のために用いる。何かがいつか変わるだろう。パブリックなAPIは安定について考え過ぎるべきではない。
６．バージョン1.0.0をパブリックなAPIと定義する。1.0.0以降のバージョンは、このパブリックなAPIとそれがどう変更するかによって決まる。
７．パッチバージョンZ(x.y.Z | x > 0)は、以前の物と互換性のあるバグフィクスを導入する場合にのみ増加する(MUST)。バグフィクスは、間違った振る舞いを修正する内部の変更と定義する。
８．マイナーバージョンY(x.Y.z | x > 0)は、
以前のものと互換性のある機能をパブリックなAPIに導入する場合にのみ増加する(MUST)。どんなに些細なことでもパブリックなAPIの機能追加はバージョンを増加しなければならない(MUST)。また、
実りのある新しい機能追加や改善がプライベートなコード中に導入された場合、バージョンを増加しても良い(MAY)。パッチレベルの変更を含む場合もバージョンを増加しても良い(MAY)。ただしマイナーバージョン番号が増加したら、パッチバージョン番号は0にリセットしなければならない(MUST)。
９．メジャーバージョンX(X.y.z | X > 0)は以前の物と互換性のない変更をパブリックなAPIに導入する場合、増加しなければならない(MUST)。また、マイナーレベルとパッチレベルの変更を含む場合、メジャーバージョン番号を増加しても良い(MAY)。メジャーバージョン番号を増加したら、マイナーバージョン番号とパッチバージョン番号は0にリセットしなければならない(MUST)。
１０．プレリリースバージョンはダッシュ(-)で隔てた識別子をパッチバージョン番号の後ろに付けることで表現しても良い(MAY)。識別子はASCIIに含まれる文字だけで構成されていなければならない(MUST)。プレリリースバージョンの優先度は同列のノーマルバージョンより低い。例えば、1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92
１１．ビルドバージョンはプラス記号で隔てた識別子をパッチバージョンの後ろに付けることで表現しても良い(MAY)。識別子はASCIIに含まれる文字だけで構成されていなければならない(MUST)。
ビルドバージョンの優先度は同列のノーマルバージョンより高い。例えば、1.0.0+build.1, 1.3.7+build.11.e0f985a
１２．優先度は、メジャー番号、マイナー番号、パッチ番号、プレリリース識別子、ビルド識別子によりバージョンを区別する事によって計算されなければならない。メジャー番号、マイナー番号、パッチ番号は常に数字通りに比較する。プレリリース識別子とビルド識別子の優先度は、それぞれの識別子によって比較しなければならない(MUST)。数字だけで構成されている識別子は数字通り比較する。文字を使っている識別子はASCIIに基づき辞書的に比較する。数字で表した識別子の優先度は、数字ではない識別子よりも常に低い。例えば、1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0-rc.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < 1.3.7+build < 1.3.7+build.2.b8f12d7 < 1.3.7+build.11.e0f985a
このアイディアは真新しくも画期的でもない。実際すでにあなたは近いことを行なっているかもしれない。問題は「近い」では不十分だということだ。いくつかの種類のフォーマルな仕様書に承諾することなしに、バージョン番号は依存関係の管理に対して本質的に役に立たない。名前と明白な定義を上記のアイディアに与えることによって、なたの意図をソフトウェアのユーザに伝えることが簡単になる。ひとたびこれらの意図が明白にしてしまえば、御しやすい依存関係の仕様書を作ることができる。
これからシンプルな例により、セマンティックバージョニングが依存関係の地獄を過去のものにすることができるということを論証する。"Firetruck"というライブラリがあるとしよう。FiretruckはLadderという名前のパッケージに依存している。Ladderはセマンティックバージョニングを用いている。Firetruckが作成された時、Ladderのバージョンは3.1.0だった。Firetruckは3.1.0で初めて導入されたいくつかの機能を使うので、あなたはFiretrucがLadderのバージョン3.1.0以上4.0.0以下に依存すると記載する事ができる。今、Ladderのバージョン3.1.1と3.2.0が入手できるとき、あなたはそれらをパッケージマネジメントシステムに導入する事ができる。また、あなたは既存の依存しているソフトウェアと互換性があるであろうことを知ることができる。
責任のある開発者として、もちろんあなたは、いくつかのパッケージの機能を更新したということを確かめたいだろう。実際の世界は複雑だ。それに対して我々は用心深くなるしかない。あなたの時間や立場を守るためにできる事は、セマンティックバージョニングによる分別のある方法で、依存するパッケージの新しいバージョンに巻き込まれることなく、パッケージをリリースしたりアップグレードしたりすることだ。
もし以上の全てのことの印象が良いなら、セマンティックバージョニングを使い始めるためにあなたがするべきことは、あなたがそれを使うこととルールに従うことを宣言することだけだ。他の人がルールを知り役立てられるようにするために、あなたのREADMEファイルからこのWEBサイトへのリンクを貼ろう。（翻訳者：リンクを貼る場合は必ず本家サイトへリンクを張ってください。）
The Semantic Versioning specification is authored by Tom Preston-Werner, inventor of Gravatars and cofounder of GitHub.
If you'd like to leave feedback, please open an issue on GitHub.
Creative Commons - CC BY 3.0 http://creativecommons.org/licenses/by/3.0/
はソフトウェアのバージョン番号の付け方について提案しています。
まだ和訳している人がいないようなので勝手に日本語版を作ってみました。
ただ、私は英語がすごく苦手な人なので誤訳が多いと思います。
正直自分でもどうかと思う部分も多々あるので、間違っている部分やもっと上手な翻訳を指南してもらえると幸いです。
翻訳について筆者であるTom Preston-Wernerに特別に連絡はしていません。
これはCreative Commonsライセンスの表示があったためです。
以下、和訳です。
Semantic Versioning 2.0.0-rc.1 日本語版
ソフトウェアマネジメントには、「依存関係の地獄」と呼ばれる恐ろしい場所が存在している。あなたがシステムを育て多くのパッケージを統合すると、ある日あなた自身がこの地獄の中にいることに気付くだろう。
多くの依存関係を持つシステムにおいて、新しいパッケージバージョンをリリースすることは、すぐに悪夢を生み出すことになるだろう。もし依存関係がきつすぎるなら、バージョンを固定してしまう危険性がある。（全ての依存パッケージの新しいバージョンがリリースされなければ、パッケージを更新できない。）もし依存関係がゆるすぎるなら、必ずバージョンの乱立を味わう事になる。（ずっと未来のバージョンとの適合性がでしゃばってくる。）バージョンの固定や乱立が発生する依存関係の地獄は、あなたのプロジェクトの進展を簡単に妨げる。
この問題の解決策として、どのようにバージョン番号を割り当て更新するかについてのシンプルなルールを提案する。このルールを実行する前に、あなたのパブリックなAPIでこのルールを使うことを宣言する必要がある。それはドキュメントによって構成されるかもしれないし、コードそのものによって強制されるかもしれない。是が非でも、このAPIが明白かつ正確であることが重要である。まずあなたのパブリックなAPIを確認し、バージョン番号を特別に増加することによってその変更を伝える。バージョンの形式をX.Y.Z(メジャー.マイナー.パッチ)で考えましょう。APIに影響を及ぼさないバグフィクスではパッチバージョンを増加する。以前の物と互換性のあるAPIの追加／変更はマイナーバージョンを、互換性のないAPIの変更はメジャーバージョンを増加する。
私はこのルールを「セマンティックバージョニング」と呼ぶ。この計画の基づくことでバージョン番号と変更理由により、潜在的なコードが意味することと、あるバージョンから次のバージョンまでに何が変更されるべきかを伝える。
■セマンティックバージョニングの詳細
この文書中のキーワード、「必須 MUST」「必須 MUST NOT」「必須 REQUIRED」「必須 SHALL」「必須 SHALL NOT」「要請 SHOULD」「要請 SHOULD NOT」「要請 RECOMMENDED」「可能 MAY」「可能 OPTIONAL」は、RFC 2119 に従って解釈して下さい。
１．セマンティックバージョニングを用いたソフトウェアではパブリックなAPIを宣言しなければならない(MUST)。このAPIはコードの中に宣言されるか、ドキュメントで厳密に存在していなければならない。ただ行うだけでなく、正確でわかりやすくあるべきだ(SHOULD)。
２．普通のバージョン番号は、X.Y.Z(X, Y, Zは正の整数)という形式でなければならない(MUST)。Xはメジャーバージョン、Yはマイナーバージョン、Zはパッチバージョン。それぞれの要素は１つずつ増加しなければならない(MUST)。例えば、1.9.0 → 1.10.0 → 1.11.0
３．メジャーバージョン番号を増加したら、マイナーバージョン番号とパッチバージョン番号を0にリセットしなければならない(MUST)。マイナーバージョン番号を増加したら、パッチバージョン番号を0にしなければならない(MUST)。例えば、1.1.3 → 2.0.0 かつ 2.1.7 → 2.2.0
４．一度バージョンを割り当てたパッケージをリリースしたら、その内容を変更してはならない(MUST NOT)。どのような変更も新しいバージョンをつけてリリースしなければならない(MUST)。
５．メジャーバージョン0(0.Y.Z)は、初期の開発のために用いる。何かがいつか変わるだろう。パブリックなAPIは安定について考え過ぎるべきではない。
６．バージョン1.0.0をパブリックなAPIと定義する。1.0.0以降のバージョンは、このパブリックなAPIとそれがどう変更するかによって決まる。
７．パッチバージョンZ(x.y.Z | x > 0)は、以前の物と互換性のあるバグフィクスを導入する場合にのみ増加する(MUST)。バグフィクスは、間違った振る舞いを修正する内部の変更と定義する。
８．マイナーバージョンY(x.Y.z | x > 0)は、
以前のものと互換性のある機能をパブリックなAPIに導入する場合にのみ増加する(MUST)。どんなに些細なことでもパブリックなAPIの機能追加はバージョンを増加しなければならない(MUST)。また、
実りのある新しい機能追加や改善がプライベートなコード中に導入された場合、バージョンを増加しても良い(MAY)。パッチレベルの変更を含む場合もバージョンを増加しても良い(MAY)。ただしマイナーバージョン番号が増加したら、パッチバージョン番号は0にリセットしなければならない(MUST)。
９．メジャーバージョンX(X.y.z | X > 0)は以前の物と互換性のない変更をパブリックなAPIに導入する場合、増加しなければならない(MUST)。また、マイナーレベルとパッチレベルの変更を含む場合、メジャーバージョン番号を増加しても良い(MAY)。メジャーバージョン番号を増加したら、マイナーバージョン番号とパッチバージョン番号は0にリセットしなければならない(MUST)。
１０．プレリリースバージョンはダッシュ(-)で隔てた識別子をパッチバージョン番号の後ろに付けることで表現しても良い(MAY)。識別子はASCIIに含まれる文字だけで構成されていなければならない(MUST)。プレリリースバージョンの優先度は同列のノーマルバージョンより低い。例えば、1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92
１１．ビルドバージョンはプラス記号で隔てた識別子をパッチバージョンの後ろに付けることで表現しても良い(MAY)。識別子はASCIIに含まれる文字だけで構成されていなければならない(MUST)。
ビルドバージョンの優先度は同列のノーマルバージョンより高い。例えば、1.0.0+build.1, 1.3.7+build.11.e0f985a
１２．優先度は、メジャー番号、マイナー番号、パッチ番号、プレリリース識別子、ビルド識別子によりバージョンを区別する事によって計算されなければならない。メジャー番号、マイナー番号、パッチ番号は常に数字通りに比較する。プレリリース識別子とビルド識別子の優先度は、それぞれの識別子によって比較しなければならない(MUST)。数字だけで構成されている識別子は数字通り比較する。文字を使っている識別子はASCIIに基づき辞書的に比較する。数字で表した識別子の優先度は、数字ではない識別子よりも常に低い。例えば、1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0-rc.1+build.1 < 1.0.0 < 1.0.0+0.3.7 < 1.3.7+build < 1.3.7+build.2.b8f12d7 < 1.3.7+build.11.e0f985a
■なぜセマンティックバージョニングを使うのか？
このアイディアは真新しくも画期的でもない。実際すでにあなたは近いことを行なっているかもしれない。問題は「近い」では不十分だということだ。いくつかの種類のフォーマルな仕様書に承諾することなしに、バージョン番号は依存関係の管理に対して本質的に役に立たない。名前と明白な定義を上記のアイディアに与えることによって、なたの意図をソフトウェアのユーザに伝えることが簡単になる。ひとたびこれらの意図が明白にしてしまえば、御しやすい依存関係の仕様書を作ることができる。
これからシンプルな例により、セマンティックバージョニングが依存関係の地獄を過去のものにすることができるということを論証する。"Firetruck"というライブラリがあるとしよう。FiretruckはLadderという名前のパッケージに依存している。Ladderはセマンティックバージョニングを用いている。Firetruckが作成された時、Ladderのバージョンは3.1.0だった。Firetruckは3.1.0で初めて導入されたいくつかの機能を使うので、あなたはFiretrucがLadderのバージョン3.1.0以上4.0.0以下に依存すると記載する事ができる。今、Ladderのバージョン3.1.1と3.2.0が入手できるとき、あなたはそれらをパッケージマネジメントシステムに導入する事ができる。また、あなたは既存の依存しているソフトウェアと互換性があるであろうことを知ることができる。
責任のある開発者として、もちろんあなたは、いくつかのパッケージの機能を更新したということを確かめたいだろう。実際の世界は複雑だ。それに対して我々は用心深くなるしかない。あなたの時間や立場を守るためにできる事は、セマンティックバージョニングによる分別のある方法で、依存するパッケージの新しいバージョンに巻き込まれることなく、パッケージをリリースしたりアップグレードしたりすることだ。
もし以上の全てのことの印象が良いなら、セマンティックバージョニングを使い始めるためにあなたがするべきことは、あなたがそれを使うこととルールに従うことを宣言することだけだ。他の人がルールを知り役立てられるようにするために、あなたのREADMEファイルからこのWEBサイトへのリンクを貼ろう。（翻訳者：リンクを貼る場合は必ず本家サイトへリンクを張ってください。）
About(以下原文通り)
The Semantic Versioning specification is authored by Tom Preston-Werner, inventor of Gravatars and cofounder of GitHub.
If you'd like to leave feedback, please open an issue on GitHub.
License
Creative Commons - CC BY 3.0 http://creativecommons.org/licenses/by/3.0/
bootstrap面白いね
bootstrapはCSSフレームワークの一種。
twitter風のWEBページを簡単に作成できる。
いちいちデザイン考えなくても良い感じのサイトが手軽にできるという・・・。
すごいね。
どんな感じになるかは下記の公式サイトを参照。
Bootstrap, from Twitter
Componentsとか見ればどんな感じになるかイメージ沸くと思う。
ページのレイアウトもScaffoldingで決められる。
Ruby on Railsへの導入
Gemfileに次のような感じで設定を書く。
source 'https://rubygems.org'
gem 'rails', '3.2.3'
gem 'bootstrap-sass', '2.0.0'
gem 'rails', '3.2.3'
gem 'bootstrap-sass', '2.0.0'
で。bundleでインストールする。
$ bundle install
実際に使っている例は、Ruby on Rails Tutorialにある。
Ruby on Rails Tutorial - Chapter 5 Filling in the layout
