良いAlfred Workflowを教えてもらいました。Chromeのタブを検索できるAlfred Workflowがすこぶる便利です。 どんなの? こんな感じで、tabsと打ち込むと現在開いているタブの一覧が出てきます。検索文字を入れると、インクリメンタルサーチができます。僕みたいにタブを30個とか平気で開いちゃう人には必需品ですね! Workflowはこちらからダウンロードできます。
HerokuでのパフォーマンスモニタリングにはNewRelicアドオンを入れるのも便利ですが、Libratoという「よりHerokuに寄り添った」メトリクスを出してくれるアドオンもあります。 こんな感じ とあるサービスで導入してみたところ、こんな感じでメトリクスが出ます。 RouterのQueueが詰まっていないか?とか、Dynoのメモリの推移や、PostgreSQLの容量は大丈夫か?といった情報をひと目で把握できる感じです。ダッシュボード的な感じですね。 他にも必要なメトリクスがあれば追加することができます。 もちろんアラートを設定することもできます。 無料のプランから使えるので、まずはお試しで。 とはいえ無料のプランでも十分に使えるクオリティだと思います。Herokuでアプリを運用している方は、ぜひご活用を! Librato
「突然の死」をコピペしたいけれども、いちいちジェネレータをググるのが面倒になったのでAlfred Workflowにしました。 使い方 まずは「突然の死」Alfred Workflowをダウンロード。Workflowをインストール後、Alfredを起動してsd [中に入れたい文字]を打ち込んでエンターキーを押すと、自動的にクリップボードにコピーされます。 _人人人人人人_ > 突然の死 <  ̄YYYYYY ̄ Alfred -> Rubyにマルチバイト文字列が適切にutf-8で渡らない問題 ヘッダでcoding: utf-8としていても、Alfredからマルチバイト文字列がRubyスクリプトに渡されるときにASCII-8BITの形で渡ってきてしまうため、そのままだとincompatible character encodings: UTF-8 and ASCII-8BITというエラーになって
Improve Rails performance by adding a few gemsでRailsのアプリがちょっと速くなるかも知れないGemが紹介されていたので、早速試してみました。 どんなGem? RailsのViewのエスケープ処理を高速化するescape_utils みんな大好きblank?メソッドの処理を高速化するfast_blank JSONに関する処理を高速化するoj OJは個人的には定番でしたが、それ以外は知らないGemでした。 Railsアプリのテストの実行速度で前後比較してみた 小規模ではあるもののテストが充実しているアプリで、上記のGemを使用している場合と使用していない場合とで比較してみました。Rails4.0.5で、Ruby2.0.0の環境。 使用前:Finished in 117.683018 seconds 使用後:Finished in 101.366
以前投稿したAngularJSとRailsの丁度良い関係を探るという記事のコード解説編です。前回はざっくりとしたアーキテクチャの紹介のみにとどめていたので、このエントリでサンプルコードの詳細について解説します。 バージョン情報 ruby 2.1.3 rails 4.1.7 devise 3.2.4 angularjs 1.3.2 ディレクトリ構造 app以下のディレクトリ構造は以下のような形です。 app ├── assets │ ├── images │ ├── javascripts │ │ ├── app │ │ │ └── tasks │ │ │ ├── tasks.controller.js.erb │ │ │ ├── tasks.html.erb │ │ │ ├── tasks.js.erb │ │ │
AngularJSとRailsのインテグレーションと言うと、やれ「RailsはAPIに専念してビューは全部AngularJSだ!」という極端な話になりがちな気がするのですが、それだとRailsの良いところが活かせませんよね。AngularJSの持ち味はDOM操作三昧で複雑になりがちな画面を良い感じにコーディングできるところにあると思うので、そういう画面でだけAngularJSを使ってはどうか?というのが今回のアイデアです。 丁度良い感じに使う そういう訳で今回作ったサンプルのアプリとソースコードがこちらになります。 https://todo-rails-sample.herokuapp.com/ https://github.com/mahm/todo-rails/ ユーザー認証はふっつーにdeviseを使って、Todoを編集する画面だけAngularJSを利用している、という感じのサンプ
あらましと考察 テストデータを大量に作っては作りなおすときに、最初ふっつーにcreate!でデータを作ってた 重すぎて泣きそうになった Twitterで「毎回コミットしているからでは?」という助言をいただく そういうわけで毎回コミットするのとトランザクションで最後にコミットするのと、ついでにバルクインサートするの、どれが一番速いか試してみた いずれにしてもバルクインサートが圧倒的に速いが、あえて毎回コミットかトランザクションかで比較すると、100レコードか1000レコードぐらいのオーダーでは若干トランザクションが速い(誤差の範囲な気もするけど・・・)。ただし10000レコードのオーダーになると逆転する。 SQLiteはコミットの度にファイルに書き込む仕様のため、常にトランザクションが優位になると思ったら、そうでもなかった(参考:SQLiteデータベースのチューニング)。このあたりの挙動の理
※ Ruby2.0以上の話です。 ときにActiveRecord::Relationが便利なのは、実際にto_aされるまでSQLが発行されないことですよね。SQLが発行されるまではいろいろな条件をインスタンス内に保持しておいてくれます。全件取得してインスタンス化してから絞り込む、なんてしていたら死んでしまいますからね。これ、無限に要素がある配列から特定条件の要素のみ10個取り出したい、というときでも似たようなことできませんかね? Enumerable#lazyを使えばできるよ redditのWhats you’re favorite ruby trick or quirk that most people don’t know about.というスレでも話題になっていたのですが、例えば API経由でとあるサイトの記事が取得できるとする。 記事はすっごくたくさんある。全部取得とかしたら死ねる
Rubyといったオブジェクト指向言語を学ぶと、メソッドの定義方法としてインスタンスメソッドとクラスメソッドという2通りの定義方法があることを学ぶと思います。しかし、言語自体のガイドブックには「定義方法にインスタンスメソッドとクラスメソッドがある」と書いてあるだけで、大抵その使い分けについては書かれていません。 そういう訳で、このエントリではその使い分けについて少し考えてみたいと思います。理論的に厳密な使い分けを目指すというよりは、そもそも使い分けの検討が全くつかない!という方に向けて、その指針の一助となることを目指します。 インスタンスメソッドとクラスメソッドとはそもそものところ、Rubyといった「オブジェクト指向の考え方」を実装した言語の機能です。その機能がなぜあるのか?というそもそものところは、オブジェクト指向の考え方にさかのぼることになります。 そこで、インスタンスメソッドとクラスメ
HOMEソフトウェア開発AngularJSでWebアプリケーションを作ろうと思った時に構成に悩んだら、generator-angular-fullstackからはじめるのが良いのでは AngularJSでWebアプリケーションを作ろうと思った時に構成に悩んだら、generator-angular-fullstackからはじめるのが良いのでは AngularJSはあくまでクライアントサイドのフレームワークなので、サーバサイドをどうしようかなーと悩むことがあると思います。Railsが得意ならRailsに組み込むのもいいんですが、Railsはビューヘルパーが異様に充実しているので、Rails上でAngularJSのコードを書いてるとRailsの良いところが10%も生かせてない気がして辛い気持ちになってきます。うーん、どうしよう。 そんな風に悩んだらYeomanのgeneratorであるgener
プログラミングを生業としていると、人のコードを引き継いで開発するなんてこともままある訳ですが、そういうときに一番困るのは「使われていないコード」だなー、としみじみ感じます。 使われていないコードがもたらす弊害 特に動的言語で書かれたコードというのは前触れ無く呼び出される可能性があるため、本当に利用されていないのかどうなのか、きっちりと調べあげるのは困難なケースがあります。例えばrubyであれば、method_missingでキャッチしてsendで動的に処理先を振り分けるなんてことをしていると、単純にgrepして利用状況を見るだけでは不十分な場合があります。 そういう意味では「使われていないコード」というよりは、「使われているのか使われていないのかはっきり分からないコード」という方が適切な表現かも知れません。 そういった「はっきりと判断のつかないコード」がある状態だと何が問題なのかと言うと、
HOMEソフトウェア開発ActiveRecord::Base#touchでレコードの数だけupdateがコールされてしまうのをひとまとめにしてくれる「Activerecord::DelayTouching」 ActiveRecord::Base#touchでレコードの数だけupdateがコールされてしまうのをひとまとめにしてくれる「Activerecord::DelayTouching」 子レコードにbelongs_to :parent, touch: trueなどと宣言した場合、親レコードにaccepts_nested_attributes_for :childrenと宣言した上で親レコードを更新すると、子レコードの数だけUPDATE文が実行される動きになる。本来1回で済むはずのUPDATEの実行がN-1回分余計に実行されるわけで、これをひとまとめにしてくれるGemがactivereco
Railsアプリを運用していると、DBスキーマの変更にあわせてデータも移し替えたりしたいこと、ありますよね。時には、DBスキーマと関係なく、一律データをリフレッシュさせるためにバッチを流したりすることもあるかと思います。 そういう場合はRakeタスクなんかを作成して流すと思うのですが、一度きり流すものをRakeタスクにするのも何だかなーと思うのと、かといってコンソールで直接流すのもなんだかなーという気持ちがあります。それを解決するのがnondestructive_migrationsです。 データのマイグレーション DBのマイグレーションと同じように、データのマイグレーションを管理してくれる仕組みです。 class UpdatePhoneNumbers < ActiveRecord::Migration def up # データ変更のスクリプト end def down # 戻しのスクリプ
HOMEソフトウェア開発ruby2.2から使えるslice_afterが便利そうだなと思ったら、既にslice_beforeがあった件 「要素をn個ごとに区切って配列にする」という処理ではEnumerable#each_sliceが便利ですが、これを「n個」とかではなく、パターンマッチで区切りたいなーと思うことがあると思います。で、Ruby 2.2.0-preview1 Releasedで「へー、Enumerable#slice_afterってのが追加されるんだ」とRuby2.2からやっとパターンマッチで区切れるようなメソッドが追加されるのかと思ったら、既にEnumerable#slice_beforeがあったよ、という話。 slice_beforeとslice_after 知らなかったslice_beforeというのはこんな奴(参考:リファレンス) # 偶数要素をチャンクの先頭と見なす
ちょっとしたコードの書き方でパフォーマンスが変わることがあります。リーダビリティを重視する向きからすれば小手先のテクニックに映るかも知れないのですが、リーダビリティを維持しながらちゃんとしたパフォーマンスを出すためにも、テクニックを知ることは大事なことだと思うのです。 結構違うもんですなー というわけで、そんなテクニックをまとめたスライドがWriting Fast Ruby。見ていて参考になったのでメモ。 たとえば引数に&blockをとってcallするよりも、yieldの方が5倍速い、とか、 def slow(&block) block.call end def fast yield end mapにブロックを渡すよりも、シンボルを渡す方が20%速い、とか (1..100).map {|i| i.to_s} (1..100).map(&:to_s) mapしてからflattenを呼び出すよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く