# == A any? B blank?, build C cache_key, cache_key_with_version, cache_version, create, create!, create_or_find_by, create_or_find_by! D delete, delete_all, delete_by, destroy, destroy_all, destroy_by E eager_loading?, empty?, encode_with, explain F find_or_create_by, find_or_create_by!, find_or_initialize_by I initialize_copy, insert, insert!, insert_all, insert_all!, inspect J joined_includes_va
Rails3.2 で Twitter Bootstrap を使いたいけど、Windows では twitter-bootstrap-rails がインストールできなかったので、 Bootstrap で入手した bootstrap.zip を解凍し、assets 下の各ディレクトリに配置してみた。 これで Twitter Bootstrap の UI コンポーネントが使えるようになったけど、画像だけが表示されない。原因は、bootstrap.css に記述されている画像 URL が assets/images に配置したものを指していないから。 ビュー内では、assets/images に配置した画像 URL を、asset_path を使って <%= asset_path "filename.png" %> という風にして取得できる。そして、Rails の Asset Pipeline 機
rails コマンドにこんな便利機能があったなんて…っ！ qiita.com Rails アプリを新規作成するとき、決まって次の作業をやっている。 rspec_rails インストール factory_girl_rails インストール Devise インストール ユーザー作成 管理ユーザー作成 RailsAdmin インストール さすがに上記の作業を毎回やるのは面倒なので、RailsAdmin のインストールまでが終わったモックアプリを用意して使い回しているけど、それでもアプリ名をリーネームするの大変。Application Template 機能を使えば完全に自動化できそうだ。 さっそくやってみた。 @after_bundler = [] def after_bundler(&block) @after_bundler << block end gem 'rails-i18n' gem
Twitter Bootstrap を twitter-bootstrap-rails を使わず、app/assets に放り込む形で導入したんだけど、レスポンシブ・デザインにしようと思って bootstrap-responsive.css を追加しても、スタイルがちゃんと適用されない…。 表示された HTML を Chrome のデベロッパーツールで見たところ、bootstrap.css が bootstrap-responsive.css の後に読み込まれていた。スタイルが上書きされてしまっていたのか。 Asset Pipeline は何も指定しなければファイル名の昇順で読み込むから、bootstrap.css がちゃんと先に読み込まれるように対策をしなければいけないな。ファイル名を変更する、というのはスマートじゃないから、application.css を次のように編集した。 /*
I am trying to override some of the default variables provided by bootstrap, particularly some default color and font settings, but only a few them seem to be taking effect. Here's the top part of my custom.css.scss: $myOrange:#f89406; $myBlueDark: #304269; $myBlue: #91BED4; $myBlueLight: #D9E8F5; $myWhite: #eee; $myGrayBlue: #43464C; /* colors */ $linkColor: $myBlueDark; $navbarBackground: $myBlu
Posted on Wed May 21 22:41:31 +0900 2008 by nabeken 別のブランチで作業をしていて、また、ブランチを作って作業をしようと思い # git checkout -b moge // これは別のブランチからさらにブランチを作る操作で、やりたかったのは以下の操作 # git checkout -b moge master // master からもう1つブランチを作りたかった 前者でブランチを作ったことに気がつかず、masterにマージしてしまった。まだ公開予定ではない記事がマージされてしまった。さて、どうしよう。 gitk コマンドで戻すべきHEADを捜しだす。その commit-ish を master にすればよい。ただし、masterでなかったことにしたい期間のコミットを含むブランチがまだ残っていることを確認すること。さもなければ、コミット
はじめに Rubyと出会ったころ、その簡潔さに感動した著者は、「ここまで自然言語に近い形でプログラムが書けるのであれば、インターネットとPCの違いすら理解しない妻でも、少しはプログラミングができるようになるかもしれない」と、家庭での普及に挑戦したことがあります。 その試みは、渡した入門書を「はじめてのRUBAI」と読まれた時点で頓挫したわけですが、その経験から「Rubyの文法に従ってはいるが、何やら他言語の匂いを感じるコード」のことを、Rubyの潜在力を生かしきれていないという意味で「RUBAIコード」と呼ぶことにしました。 そして、社内のさまざまな分野のプログラマにRuby開発を指導してみて分かったのは、"RUBAIコード"には、実装レベルの間違いと、設計レベルの間違いがあるということです。 実装レベルの間違いとは、処理を他言語の習慣に従って記述することで引き起こされます。Javaプログ
はじめに 第3回の今回は、正規化された「テーブル」と、人間にとって分かりやすい「画面」。このギャップを超えるための中間層について解説します。 Railsによる開発では、テーブルの構造に従って、入力項目や画面遷移といったインタフェースの仕様が決まります。具体的には、あるテーブルの名前が確定すると、それに沿ってモデルやコントローラの名前が決まり、テーブルの属性によって、画面の入出力項目が決まります。さらに、モデルの関連や振る舞いに従って、定義するアクション、画面遷移、ルーティングが決まります。 この様子を、次の図1に示します。 このように、テーブル構造とインタフェースを直結してサクサクとアプリケーションを作成していくのが、Rails開発の面白さです。 しかし、よく考えてみると、「テーブル」とは、正規化された、いわば「コンピュータにとって分かりやすい」構造です。そのままだと、使いづらいアプリケー
文字で考えることができません（＝＝）図で考えたいです。なので、 ruby script/generate migration InitialSchema を実行する db/00323232333(数字列)_initial_schema.rb のような migration ファイルができる 00323232333_initial_schema.rb に "users" とか作りたいテーブルの内容を書く こんなの無理っす。 で、どうしているのか書きます。前にも書いた気がする…、が、みつからないのでまた書く。 まず、DB DesignerというWindows用のアプリケーションで、ER図（Entity Relationship Diagram）を書いて、DB（データベース）を設計をします。 # 前職で教えてもらって以来、お気に入りのアプリケーション。 fabFORCE.net http://db
30分間データモデリング ～ER図を描こう！～：データベースエンジニアへの道（2）（4/4 ページ）
Rubyでソースコードを読む時の小技について書いてみようと思う。 この投稿も参考になる。 Rubyでメソッドの定義場所を見つける方法 #Ruby - Qiita http://qiita.com/items/fc8a61b421d026a23ffe ちなみに、私はVimmerなので、Vimに寄った話です。 emacsについては身近にemacsユーザーに聞きましょう。 ctagsを活用する ctagsでtagsファイルを出力しておけば、メソッドの定義元に飛ぶのが非常に楽になります。 Railsで開発しているなら、Railsのプロジェクトルートで以下のようなコマンドを打ちます。 (bundlerでプロジェクト内にGemがある場合を想定) langmapとかは別に無くても大丈夫だと思いますが。 --excludeを付けずにctagsを実行するとjavascriptのライブラリもタグ付けされて、
Gitコマンド一覧 「WEB+DB PRESS Vol.50」はじめてのGitをみて勉強しながらコマンドをまとめてみる。 git initgitでのバージョン管理の最初のコマンド。 バージョン管理の対象のフォルダに移動してからこのコマンドを実行することで、.gitフォルダが出来てバージョン管理の対象になる。 git --bare initワークツリーのないリポジトリを作成。 git add .現在のワークツリーの状態を『記録』する。 まだコミットはされていない。 最後のピリオドまで必要。 git add -u-uオプションをつけるとワークツリー内の全てのファイルを記録する。 git add -A新しく作成されたファイルを含めてインデックスに記録する。 git add -pどの変更を次回のコミットに含めるかを選択して、インデックスに記録する。変更の内容が、論理的に関連性がない場合などに使用す
if (条件) { return 20; } else { return 30; } ↓ if (条件) return 20; return 30; こうすれば確かにネストは浅くなりますが、いつも毎回こう書く方がよいのでしょうか？ elseを書いた方がよいケースもあるのではないか 条件の部分が特殊・例外的な場合は、確かにこの方がわかりやすいと思います。 例えば、スーパーマリオで、マリオの状態が「無敵・チビ・大きい」の３種類しかないとします。 敵に触れたときの挙動を関数として書きます。 (オブジェクト指向っぽくないかもしれませんが、本記事の主眼はif-elseの書き方です。) function () { if (マリオ.is無敵モード) { 敵.死ぬ(); return ; } //以下、通常モードの場合のコードを書く } 無敵モードは特殊な状態だから、これはよいと思います。 しかし、マリオ
なぜ、「.bash_profileと.bashrcの違い」をすぐ忘れてしまうのか？ ずばり、 「どっちに書いても、実用上は対して変わらない」 からでしょう。 ちょこっと環境変数を定義する程度なら、どっちに書いても動くのです。 どっちに書いてもそれなりに動く → 違いがわからない → 忘れる これが魔の忘却ループです。 .bash_profileと.bashrcの違いを絶対に忘れない方法 ではどうすればよいか？ 「違いを自分の目ではっきりと見ること」 これに尽きます。 これから、一緒に手を動かして簡単な実験をしてみましょう。 ５分ほどで終ります。 準備はいいですか？ ① .bash_profileにechoを書いてみる .bash_profileの最下行に１行追加します。 echo "＼(うぇるかむようこそプロファイル)／" ② .bashrcにechoを書いてみる .bashrcの最下行に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
