肥大化するseeds.rbをうまい具合に管理する
seeds.rb中でif~elsifしたり、rakeタスクを環境分用意するなど、剛の者もいるようですが、それはあんまりにも辛みを予感させてしまいます。
個人的に楽でオススメなのが、環境毎のdirを切って、その下に実処理書いたファイル配置し、requireでごそっと開始させる方法。
root └ db ├ seeds.rb ├ seeds/ ├ development/ │ ├ users.rb │ └ ...~.rb ├ production/
こんな感じ。
規模が小さいなら、environmentごとのdir切らずに、直接ファイルおいても良いかも。
db/seeds.rbにはこんな感じの処理書いておく
seed_files_root="#{Rails.root}/db/seeds/#{Rails.env}" Dir.glob("#{seed_files_root}/**.rb").each{|file| require file if FileTest.file?(file) }
これによって、起動した時の環境に合わせたdirから、Seedするファイルが読み込まれて処理されるようになります。
というメモ。
Fabricインストール時に起きたDistributionNotFoundを解決する
OSX python2.7.5で起きたもの。
- pipでインストール
- インストールされていたparamikoは1.15.2
こんなエラー
Traceback (most recent call last): File "/usr/local/bin/fab", line 5, in <module> from pkg_resources import load_entry_point File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 2603, in <module> working_set.require(__requires__) File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 666, in require needed = self.resolve(parse_requirements(requirements)) File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/pkg_resources.py", line 565, in resolve raise DistributionNotFound(req) # XXX put more info here pkg_resources.DistributionNotFound: paramiko>=1.10
最後の行に見て取れるように、単純に依存関係が解決できていない模様。 こういう時は、エラーに書かれているバージョンを入れると固い。
pip uninstall paramiko pip install paramiko==1.10
これでOK( ・`ω・´)
Google Playで、課金テスト行うまでのメモ
作業中の簡易的なメモで、割りとうろ覚えですが、ググる取っ掛かりになれば幸いです(´・ω・`)
GooglePlayの開発者アカウントを取得して、決済設定を行っていることが前提。まずはGoogleが提供しているSandbox用の決済IDで決済処理が走るかどうか見ておくとよさげ。
http://devwalker.blogspot.jp/2013/07/google-play-in-app-billing.html
APKのアップロード
以前はできていたけど、今年の5月くらいからドラフト版での課金テストサポートしなくなったらしい。α、またはβでアプリ公開の設定が必要。
https://support.google.com/googleplay/android-developer/answer/3131213?hl=ja
ドラフト版でアプリ課金のテストができないということは、一度APKをアップロードして、特定ユーザーしか見えない形で公開状態にする必要がある。
このとき、製品版、ではなくアルファ版か、ベータ版であることを注意する。
基本、APKを作成してアップロードするだけ。APK作成時に、KeyStoreで署名する必要があるのでそこだけ注意。 http://techbooster.org/android/environment/1445/
もしUnityとかでアプリ作ってる場合は、UnityのPlayetSettingsから作成できる方法があるのでそっち使うことをおすすめ。
APKのサイズが50MBを超えていると、アップロード時に弾かれる。 個人開発のアプリだとそうそうないと思うけど、その時は、拡張APKの仕組みを導入してあげることで50MB以下に落とすことができる。 https://support.google.com/googleplay/android-developer/answer/2481797?hl=ja
拡張APKを適用した場合、拡張APKとして分割したファイルも一緒にアップロードする必要がある。
ただし、初回に登録する場合は、まずAPKだけを単体でアップロードする。
成功した後、BundleVersionと、BundleVersionCodeを変更したAPKをアップロードした後、拡張ファイル分をアップロードできるようになるので、そこでアップロードしてあげる。
一旦APKアップロードすると、「公開できない理由」の表示が大体出てるはず。
クリックすると、何が問題か教えてくれるので、警告内容を見て、修正して、アップロードして…を警告なくなるまで繰り返す。
警告が全て消えれば、アプリケーションを公開できるようになるので、間違って製品版を公開しようとしていないかチェックして、公開ボタン押す。
公開すると、大体2,3時間くらいで反映される。
アプリ内アイテムの追加
決済設定が終了+APKアップロード後に設定できるようになる。
任意のIDを振り、提供価格と提供国の設定をして、確定させればゲーム内アイテム販売可能な状態になる。
IDの振り方は、会社ドメインなどのprefix.アプリ名.アイテム名のような感じが推奨されてるらしい。
このIDに本番用のアプリ名を使うのは避けた方がいい。AppStoreと違って、ここで登録したIDと同じものは永久に使えなくなるため(´・ω・`)
テストユーザーの追加
APKアップロード後がよいかも。テストユーザーの追加が必要。
公開設定したアプリを使えるようにするには、Googleグループでテストユーザーグループを作成しておく必要がある。非公開のグループでもOK。
Gmailのアカウントが必要になるので、テスト用に1つ作成し、そのユーザーでグループ作るようにすることをおすすめ。
(実機テストで個人のGmail使うと、課金テスト時に実課金されてしまう事故が起こるかもしれないので)
APKアップロードしたバージョンのタブを選択して、「テスターのリストを管理」から、作成したグループを紐付ける。
紐付けに成功した場合、しばらく経つとGoolgeグループに所属しているアカウントに、アプリ公開の通知が飛んでくるので、飛んできた通知にあるリンクからアプリをインストールできる。
APKの設定部分で、テストユーザーのグループを指定することで、そのユーザーだけにインストールさせることができる。
APKのアップロード
なにか修正してAPK上げなおすときの注意点。
BundleVersionだけ上げても弾かれてしまう。 BundleVersion以外に、Bundle VersionCodeも変更しないと更新できないので注意。
APKアップロードした後、テストユーザーに配信されるまで最低でも2、3時間かかる(2,3時間かからないとStoreに並ばない)
なので、頻繁に更新してアップロードして、検証!みたいなことはできないのが辛み。
gulpでSlimのビルド環境作る
本当はいろいろやるつもりだったんですが、nodeの更新でミスってnpmが行方不明になったりして時間食われてしまったので、実際のコード書くには至らなかった(´・ω・`)
とりあえず、gulpでSlimビルドできるようにしたのでメモ
Slimとは
最近Railsでerbの代替として使われ始めている、HTMLテンプレートエンジン。短い記述で書けるので大変ラク。
Hamlから%抜いたやつだと思えばよいです。gem install slim
とかやれば入る。
Slim - A Fast, Lightweight Template Engine for Ruby
すばらしい。
Railsなくても、単にマークアップツールとしての使用は可能なので、これで爆速でHTML書けると思われる。
gulpfile
SlimをHtmlへビルドするには、slimrb -p "slim_file" > "export/file_name.html"
とかやればよさげ。つまり、gulpでコマンド叩ければ良いわけです。
gulpでコマンド叩くには、gulp自体のインストールした上で、gulp-shellを使うのが楽です。npm install --save-dev gulp && npm install --save-dev gulp-shell
で入れる。
gulp.pipe()
中で、shell(["command"])
とかやれば実行できます。
gulp-shellには、fileオブジェクトが渡されます。gulp-shellのドキュメント内にある「shell(commands, options) 」の項目見ると、
A command can be a template which can be interpolated by some file info (e.g. file.path).
とあり、wearefractal/vinyl · GitHubで書かれている通り、file.relative
とかやれば元のファイル名が取得できます。
このファイル名の拡張子"slim"を"html"に変換してあげれば、普通にビルド通ってHTMLが生成されます。
macにHaxe入れてみた
いわゆる、AltJSで、今後どれ使っていこうか悩んでいたりしてます(´・ω・`) とりあえず、CoffeeとTypeScriptを触ってみたんですが、あまりしっくり来ず…
今AltJSというと、だいたいこいつらだと思います。
CoffeScript (http://coffeescript.org/)
TypeScript (http://www.typescriptlang.org/)
- 実際にプロダクションで動かしてる話も結構聞くようになった、MicroSoft(というよりヘルスバーグさん)性のAltJs。型システムと型推論で、硬いコードも書けるし、JSみたいにゆるふわもできる。
- 思想は大好き。すごく書きやすい。C#erなので記法にも割りと慣れた
- そのコンパイルの遅さは欠点。型システムが導入されているので仕方ないんですけどね…でもJSはさっと書いてさっと動かしたい。
- ts.dの悪夢。きちっと使い倒そうとすると色々ハマる。大規模なら活かせるけど、小規模で型定義管理するのつらぽよ。大きいやつならいいんです、大きいやつなら。
- VisualStudioかWebStormいるよねこれ。他でもできなくはないけど、つらい。
JSX (http://jsx.github.io/)
- AltJSの新参者。DeNA製。型システム持ち。
- 他のAltJSと比較して、だいぶ素のJSに近しい。
- JSを極端に高速化しているらしく、ベンチ結果はかなりのもの
- とはいえ採用事例が…(ry 今後、極端に性能要求されるものがあったら使うかもしれない。ごめんね(´・ω・`)
Haxe (http://haxe.org/documentation/introduction/language-introduction.html)
- 歴史的には結構古い。2005年くらいから。型システム持ち。
- CoffeeScriptやTypeScriptほどではないけど、採用事例を聞くようになった。
- AltJSに分類されているものの、その実、メインストリーム張ってる言語(例えばC++とかC#とかJavaとかPHPとか)への変換も可能だったりするすごいやつ。挙句、Flashにも変換できたりします。
- 大本がActionScript界隈から出てきたものなので、ゲーム系で使われることが多い。
と、まあこれだけあるわけです。 JSXとHaxe以外は軽く触ってみて、ある程度使い勝手とか見えてきているんですが、Haxeの将来性が高そうな予感がする。
ので、これも触ってみることにして、今日のメイン。
Macにインストールする
Windowsの人は、とりあえずFlashDevelop入れれば解決する。 Macの場合は、IDE以外にvimとかSublimeとか使うことを考慮して、Haxeのシステム自体を導入してしまいます。
Homebrew
でインストールできたので楽ちんです。
~$ brew info haxe haxe: stable 3.1.3 (bottled), HEAD http://haxe.org /usr/local/Cellar/haxe/3.1.3 (1619 files, 19M) * Poured from bottle From: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/haxe.rb
最初、何も考えずにHomebrew叩くとこんなエラーが…
brew install haxe objective-caml: Unsatisfied dependency: XQuartz 0.0.0 Homebrew does not package XQuartz. Installers may be found at: https://xquartz.macosforge.org Error: An unsatisfied requirement failed this build.
これだけみても、良く分からないんですが、Unsatisfied dependencyといっているので、おそらく依存関係になにか問題があるように見えます。
そこで、おもむろに...
brew update && brew upgrade
とかやります。
その後でbrew install haxe
とかするとすんなり入ってくれました。
単純にHomebrewが古かっただけのようです。同じエラーに引っかかった時は、まずHomebrew更新するとよろしいかと(`・ω・´)
BREAK TIMESの勉強会に参加してきたメモをまとめてみた
今年2014/8頃に開催された、PR TIMESさん主催の勉強会レポです。
前回のイベント情報はこちら: http://breaktimes1.peatix.com/
当時は、自分の転職とかその辺に時間取られて、メモを公開するタイミングが掴めず…。
かなり、学びや発見多かった勉強会だったために、メモをお蔵入りさせるが偲ばれまして、今回のこのタイミングでまとめてみた次第であります( ・`ω・´)
さっそく、メモのまとめを書いてきます。
PR Timesの紹介
まず最初は、
勉強会を主催したPR TIMESさんの発表です。プレスリリースの配信掲載サイトを提供している企業。
PRサイトを運用していくときのノウハウを、BreakTimesブログで公開しているそうです。
どうやって運営しているか
アクセス解析して、指標を元に改善していく PDCAを回して、運営していっている。
主に、Google Analytics使って、
- ユーザーPV
- コンバージョン 。
また、ベージ毎のPVや、ヒートマップ(ページ内のユーザーが見ている部分)のデータを抽出した上での最適化等、いかにコンバージョンを高くするか、に絞った改善などをも実施している。
サイト改善するときに指標を見て、どういうテストをしているか
ABテスト(サービス紹介ページ)
- 以前は画像だったけど、動画いれてみるテストを実施
- ユーザーが、途中で離脱していたけれど、この対応を入れると、下までスクロールしてくれるようになって、コンバージョン高くなった
多変量テスト
ABテストの発展系。
より複雑な条件の上で、どのような動きをしているかを分析し、全体の傾向から改善部分を導き出すことが狙い。
条件が複雑になればなるほど、ケースの組み合わせが増えて、解析が大変になる。
多腕バンディット
- Google Analyticsでも使える
- パターンの表示割合を増やして、より最適な解が出るまで繰りかえしていく
- 結果に基づいて表示を変えていくにしたがって、少ないコストで最適な解が得られる
多変量テストでは、ケースの組み合わせを増やして傾向をみる分析方法。
多腕バンディットは、出てきた結果を元に、更に踏み込んだ条件やケースに絞っていく。それを繰り返すことで精度高い分析を得られるようにした解析手法。
PR TIMESさんの発表では、PR TIMESさんが自社サービスの改善を行う際に、その改善部分を導き出す話を聞くことができました。
配信するプレスを、より高く、効果的に配信するためには、まず問題を見つけて、最適な手法で解決する。そのフローが大事ですね。
多腕バンディットを用いたプロダクト改善については、最近cookpadさんが記事をあげていました。興味のある人は目を通して見るとよいと思います
http://techlife.cookpad.com/entry/2014/10/29/102036
UI/UXとはなにか。 UI ≠UX
イベント開催前は、セカイラボの森脇さんが、UI/UXの設計の話をされる予定でしたが。 残念ながら、森脇さんが、体調不良で未参加となり…
代打で、日本ディレクション協会の小嶋さんが発表されていました。 小島さんは - フリーランスのディレクター - Webデザイナやって、ディレクターに というバックボーンを持った方です。その方が話すUI/UX論だったので、若干ディレクタ的な目線のお話が聞けました。
ここからメモ
UIとUXはレイヤーがちがうということ
UXデザイン
⇒ UXデザイン !! なんのこっちゃよくわからん
実用性を設計する = UXデザイン
たとえば、普段使う椅子。椅子といってもそれぞれ全くタイプが異なる。
- 柔らかいならいいの?
- キャスター付きで動くならいいの?
- 革張りならいいの?
シックな内装に合う椅子、バーに合う椅子、コンサート会場に合う椅子… それぞれ、場、シチュエーションによって、最適な物が異なる
⇒ そういった設計をしていくのがUXデザイン
UXデザインのために考える事
- コンテンツ全体の目的、用途を想定しておく。
- ユーザーがどういう反応をするのか?
- どういう行動をするのか?
問題の定義を明確にして、想定するユーザーに正しく価値を伝えることが大事。
UIデザイン
各機能に合わせた適切なUIを作るもの。UXデザインのレイヤーより、下に位置する。 まずは、どんなUXを与えていくか、ありき
- 画面にとらわれ過ぎない!
- 使う人の気持を考える。
UXとUI の 有名な事例
NORDSTROM (大きな百貨店) IPADアプリのUX改善事例
- 実際の店舗にPC持ち込み + 実際のお客さんに使ってもらって、即座にフィードバック→ 大量に付箋が貼られては剥がされていく。
- 一週間で改善できるところまで、現地でやって開発に活かす方法。
- すぐに本格的な開発には入らない。ペーパープロトタイプベース。
- アプリだけでなく、アプリをどう触ってもらうか。テーブル台にのせて使ったりする?
- アプリの使い方の設計。どういうシチュエーションで、どんなふうに?
ユーザーが実際に使っている、リアルな世界の問題を解決するために、開発を行っていく。
ここまでイメージをしながらちゃんとUIを設計する必要がある。特にスマホ。しっかり考えてやる、やらないで大きく差がつく。
広告の視点だけでなく、ツールとしての側面まで設計していくのは当然。
UX、UIとは、と安易に語られがちで、 ユーザーに価値を伝える最適な方法かどうか、はいつの間にか忘れてしまったりしてました。 この発表は、そういう視点を思い出させてくれる良い内容だったと思います。
実際にユーザーさんに使ってもらうことほど、良いデータが取れることはないので、プロトタイプ時点からユーザーを巻き込むことの大事さを、いい感じに理解できた発表でした社記
HTML5 概要 コードサンプル
この勉強会の目玉ともいえる、お話でした。 W3Cの中の人の話が聞ける機会は、本当に貴重。
講師は、Daniel Davis氏(http://html5experts.jp/ourmaninjapan/)。元Operaの英国人。 最初の触りで、英語セッションの雰囲気を漂わせつつ、参加者にある種の覚悟をさせてましたが、 本人、日本語ペラペラで、普通に話聞けました(;・∀・)
HTML5で新たに採択されつつある、仕様の話が多めでした。
当日の資料は公開されています。
http://breaktimes.hatenablog.com/entry/2014/10/14/194903
深く知りたい方は、この資料の方を見ると捗るかと思います。
ここからメモ
HTML5とはなにか
- HTML:
構成を決める - CSS:
見た目を決める - Javascript:
動きを決める
つまり、
HTML5 = HTML4 + 新しい仕様 − 古い仕様
そもそもHTMLとは
HTML = Code onxe , rearch people everywhere.
⇒ PC、スマホ、問わず使える。汎用的な仕様。
大事なのは、正しいマークアップをすること - headerタグ等を適切に使うと、検索エンジンが有利に働く
現状では、ブラウザ差異が小さくなってきた。
ブラウザが標準化されてきた。どこでもそこそこ同じコードで動く。
まだ、完全に対応されているわけではないが、昔よりはかなりマシになっている。
HTMLは、WEBだけで使われている…わけでもなくなってきた
WEB標準大事; みんながわかる = みんな使える
HTML5が目指す先。やろうとしていこと。
- より簡単
- よりはやい
- よりフレキシブル
これまで以上にいろいろなことが、早く、簡単に実現できるようになる。
UserMediaAPI
- ユーザーのカメラとマイクのデータ取得
- 必ず、ユーザーに同意を求めるダイアログを出すようにしている。このタイアログは無効化できない。
- 取得したカメラのデータは、javascriptで操作できるようにしている。
- API仕様は、汎用的に使えるように設計している。
グローバルにある、navigatorオブジェクトを経由して、使用する。
// 使用できれば使うし、ダメだったらエラー処理呼ぶように使える。 navigator.getUserMedia({video:true}, successCallback, errorCoallback);
GeolocationAPI
結構前からある。4年前くらい? ユーザーの現在場所を使って、地図情報が取れる。
navigator.geolocation.getCurrentPosition(callback: position);
Device Orietation API
デバイスの向き、加速度とか取れる
IOSが先立って実装。標準の方が遅れてた。
取得したデータをサーバーに乗っけて、いろいろできる。
車載ブラウザあたりで使えると、新しいことができる可能性が。
window.ondevicemotion = function(event) { // event.acceleraionオブジェクト = { x, y, z} が取得可能 // event.rotationRateオブジェクト= { alpha, beta, gamma }が取得可能 }
Systen Infomation API
システム情報を取得できるAPI。
気温、気圧、湿度、騒音、距離感
まだ全部はできていない。ので、ブラウザには対応していない。APIはできてる。 デバイスハードウェアが必要になってくるので、自由に使えるようになるまで、時間がかかりそう。
naviator.system.monitor("Thurmal", successCallback); // event.thermal { state = 気温}
デバイスを介する兼ね合いもあり、データ取得が間に合わない場合は、なにもしないように動作する。
WebSocket API, WebRTC
リアルタイムでインタラクティブなデータ通信で、HTTP使うのは遅すぎる。
WebSocket: 使いやすい。けど、性能そこそこ。
WebRTC: 早いけど使いにくい
WebScoket
- コネクションのackを、最初の一回だけやって、後はやらない。早い
- 同時に送ることができる。受信もできる。
- ただし、サーバーは経由する必要あり。
WebRTC
- 最初の一回だけサーバー通信する。
- あとはP2Pで通信するようになる。
- サーバーを経由しないので、はやい
var socket = new WebSocket("ws://address"); socket.onopen = { }
SkyWayという、WebRTCを簡単に試せるサービスがあるので、簡単に試せる。
Offline Storage
複数やり方がある。
- ServiceWorker
API策定中 - IndexedDB
ブラウザによって動きが違うのでライブラリ推奨 - LocalStorage
現時点、すべてのブラウザで使える。信頼性が高い。
var online = navigator.online; window.lodclstorege["Name"];
LocalStorageは、5MBくらいデータ持てる。一時データとしては十分な容量。
Responseive Images
デバイスサイズによって、表示する画像を切替えるもの。 マルチデバイス対応が容易にできるようになる。
<picture>要素
- srcset属性
まだ入ってない。開発版ブラウザには入っていたりする。 ブラウザがサポートしてなくてもエラーはでない。画像がちゃんと表示される。
<picture> <source media='(min-width: 45em)' srcset='large.img'> <img src =""> <!-- 回避策 --> </picure>
未来のはなし
HTMLでハードウェアを操作できるようになれば、 - スマートカーを実現して、走行データを収拾した後、渋滞予測やの算出など可能に。 - 無人ドローンを用いて、農場の監視を行い、蓄積したデータから、農場の管理を自動化したり。
現時点で、Hueという商品がある。これをWEBで操作できるようになると、面白いことができそう。
HTML5でやっていくこと、できることの解説が詰まった、濃い内容だったと思います。
当日は、実際にビデオチャットを、HTMLだけで実現するデモが織り交ぜられての内容でした。
そういえば、昨日、ちょうどHTML5 が勧告となった速報が流れましたね。
http://www.w3.org/2014/10/html5-rec.html.ja
この話を聞いたときから、ずいぶん進展があったようです。
今後、語られたいろいろなAPIが実際に普及し、使われることによって、 今現在では、スマートフォンしかできないことが、WEBにもできる。そういう時代がきそうな予感がします!
終わりに
で、なんで唐突にこのメモを公開する気になったかというと、
PR TIMESさんの勉強会が、近日開催されます!
http://breaktimes.hatenablog.com/entry/nite2
次回の内容も、かなり勉強になりそうですね。これを無料でやってくれるのだから、大変ありがたいことです(´ω`)
良い勉強会なので、行ったことない人は、行ってみるとよいのではないかと思います!
自分は、絶賛炎上中で行けそうにないので、 行った方はレポして頂けると大変嬉しいです(´・ω・`)
Ruby+Railsの開発で使っているもの、について書いてみる
いろいろできて、いろいろ見えないRuby
今現在は、Rubyをメインに開発進めてる仕事してます(`・ω・´) 前職はC#でWeb開発をしていたためか、なかなかRubyに慣れない日々が続いております。
暗黙的にメソッド生やされると、なにやってるか追うのが大変つらいので、用途絞って使って頂きたく候。
という、無駄なボヤきは、見なかったことにしてください。
そろそろ、仕事で触って2ヶ月くらいになるので、振り返り含めてまとめてみます。
エディタ
RubyMine使ってます。エディタというよりIDEですね。
vimにプラグインいれまくったり、Atomをいろいろイジってみたりといろいろやりましたが、コードの検索精度とかその辺が強力すぎるので、RubyMineに落ち着きました。
ゆとラーなので、楽な方に流れるのは、まあいつものこと。むしろ正義ですらある( ・`ω・´)
とはいえ、使っている機能はそんなに多くないです。キーバインドも対して変えてないし。
仕事で使っているショートカットとか、
CMD + SHIFT + O
Fileサーチ。検索したソースファイルに一発で飛べる。CMD + B
定義元ジャンプ。メソッドなどの定義している位置へ、一発移動できます。
とはいえ、動的言語。完全な補完は無理で、複数同じ名前で定義している要素があると、候補の中から探す作業が必要になります。
まーこれはしゃーない。CMD + @
一つ前のジャンプ元に戻る。CMD + Bした後によく使います。
こんなもん。
他の機能は、まだショートカット覚えきれてないので、Find Action(Sublimeのコマンドパレットみたいなやつ)を駆使してやりくりしてます。
リファクタリングの機能が強力なのは大変よいです!
ただ動的言語なので、稀に暴走して大変なことに…。リファクタ後は、必ずDiffチェックするようにしましょう。
Bash
IDE使うといっても、Gitコマンド使ったり、その他もろもろのツールを使う時は、やはり黒い画面を使う必要があるものです。
ある程度Bashの使い心地を向上しておいた方が、いろいろ捗ります。
Terminal.appは早々にやめて、iTerm使ってます。単純にカラースキームの変更が楽だから、ですね。
あと、今自分がどのブランチにいるか、がひと目で分かるようになっていると捗る。
Git使って開発していると、頻繁にブランチを行き来するので、間違った操作しないように、注意するのは大事なことです。間違ってmasterブランチにpushすると大変面倒なことになりますしね…。
自分は、Git-Promtとか使って、常に表示できるようにしています。
http://mironal-memo.blogspot.jp/2012/08/git-completion.bash.html
使用するためには、.git-prompt.shを、homeに配置します。
curl -l ”https://raw.githubusercontent.com/git/git/master/contrib/completion/git-prompt.sh" > ~/.git-prompt.sh
設定は.bash_profileにこんな感じで。
source ~/.git-prompt.sh GIT_PS1_SHOWDIRTYSTATE=true PS1='@\u \W$(__git_ps1 "[\[\033[32m\]%s\[\033[0m\]]")\$ '
こんな感じに表示されるようになります。べんり!!
SQLクライアント
コマンドラインつらい(;ω;`)なのでGUIでも操作できるやつを使います。
大昔にRails使った開発やったときは、某Phpmyadminとか使ってましたが、辛い。
Sequel Proがマジ便利です。全部これで済ませられます。個人的には鉄板なツール。
他にも、MySqlWorkbenchとかあるのですが、使い勝手がそれほど良く感じなかったので、すぐ乗り換えましたね…。なんかストレス溜まるんですこれ。
Gem
汎用的に使えるやつを上げてみる。大体、どんなプロジェクトでも、汎用的に使えると思います。
作成元か、使い方を載せてるリンクを同時に貼っておきます( ・`ω・´)
Better errors
Railsのエラー画面を綺麗にするやつ。RailsでWeb開発するときは必携ですね。
http://morizyun.github.io/blog/better-error-gem-rails-ruby-rack/
hirb
rails-console(irb, pry)でActive Record結果を整形して表示することができます。
http://blog.dakatsuka.jp/2011/05/14/hirb-rails-console.html
pry
Ruby-Console irbを機能拡張したもの。実行結果のハイライトや、shellを実行できる機能、他の便利なGemが使えるようになること、等メリット多めです。
http://morizyun.github.io/blog/pry-command-rails-ruby/
pry_rails
rails start でpryが起動するようになります。
http://qiita.com/yaotti/items/c6e850010f36acedb0e1
railsは、標準だとirbを立ち上げるので、Railsでもpry使いたいときは必須です。
pry_byebug
ラインデバッグできるようになります。
https://rubygems.org/gems/pry-byebug
コード上に、binding.pryと書くと、そこを通ったタイミングでブレークするようになります。
unit_testや、Rakeタスク通すときにも、止まるようになるので便利。
ただ、これruby2.0以上でしか使えないので、それ以外の環境では、pry_debuggerなるものを使います。使い勝手はどちらも同じ感じですね
pry_doc
通常、Rubyでは、Deepな領域であるC側のコードを見ることができません。
pry_docsを使うと、pry上でではありますが、このコードを見ることができます。
http://qiita.com/joker1007/items/42f00b12c65bbec0e50a
メソッドの内部構造を知ることは、効率のよい開発をするために必須だと思っています。
なにかわからんことあったらガンガンコード読むと、いろいろと捗るようになります( ・`ω・´)
pry-stack_explorer
pry上で、コールスタックが参照できるようになります。デバッグに重宝します。
http://shirusu-ni-tarazu.hatenablog.jp/entry/2012/11/04/180908
動いているのに、そのメソッドなりクラスが見つからない、メタプログラミングなダークサイド臭のエラー特定するとき、あると大変助かります。
rails.erd
ER図をかいてくれるツール。
http://qiita.com/satton_maroyaka/items/55e6cf42bd677c94d0d5
開発中に、テーブル定義書的なドキュメントを作るときに使えます。
また、モデル間のRelationを見るためにも必携ですね。
実テーブル自体が、リレーション持っていなくても、RailsのAssociationに従って図を生成してくれるので、Railsを使うときは、これ使った方がよいですね。
spring
railsの起動を早くしてくれるやつ。
http://blog.livedoor.jp/sasata299/archives/51925482.html
裏側でrailsのプロセスをあげっぱなしにしておいて、それを使うようにすることで、起動時のライブラリロードとかの、あれこれを解決してくれるようです。
終わりに
Rubyは良い言語ですが、それは、たくさんのRubistが公開してくれている情報や、Gemが豊富にあるからだと思っています。
それだけ、開発者を惹きつける何かがあるんでしょうね。
自分は、「型付け欲しいなぁ・・・」とかボヤきつつ、Scalaの方を見てたりしていますが。
まだそれを理解できるところまで、Ruby深く触っていないので、まずはいろいろと使い倒してみたいと思っています( ・`ω・´)