You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Help us understand the problem. What is going on with this article? Rails3.2からRails4.2に上げたらActiveRecordが遅くなったので、どうやって調査して、どのように対処したかを語ってみたい。 とても長いので、ダルい人は最初と最後だけ読めばよいです。 TL;DR 環境: Ruby 2.1.5 ARオブジェクトを大量に(ざっくり750kくらい)loadするバッチ処理 3.2系での実行時間は約480sec、 4.2系では約2900sec 約6倍の性能劣化 原因: preloadで性能劣化してた CollectionProxyの生成周りで遅くなってた Rails4からARオブジェクトの1attribute毎にObject生成するので遅い GCの時間も増えた 調査方法: Githubのcommit、Issueを
過去9年わたりWebアプリケーションを開発してきたNiket氏( @nexneo )は、2013年からGoを使って作業をするようになりました。この講演では、彼がどのようにRubyのモノリシックアプリケーションを分解しつつ、Goで記述されたマイクロサービスへと至ったかについて説明しています。講演のスライドは、 speakerdeck.com/nexneo/joy-of-single-purpose-services-in-go で閲覧可能です。 Single purpose servicesというのは、単一の問題を解決するサービスのことです。 一般的に マイクロサービス としても知られています。 Niket氏は、学校側が親御さんたちと連絡したり成績表や出席を管理したりするための人気オンラインプラットフォーム、 Beehively の開発者です。BeehivelyはRubyベースのアプリケーシ
haml との互換性にはかなり気を使っているけど、一部意図的に非互換にしていたり、正確な仕様がわからず再現できていない箇所があったり、haml の奇妙な挙動が直っていたりして、完全に全く同じ動作にはなっていない。 先日 faml を本番に投入して今も動いている。faml 導入にあたって実際にはアプリケーション側のビューを一部書き換えたけど、大量のビューがある中での変更点は十分少なかったと思う。 なお、このエントリ内での「元々の haml」は haml 4.0.6 を指している。過去のバージョンは知らない。 どれくらい高速なのか 元々 faml を書き始めたきっかけは「haml と slim に文法的に大きな差があるわけではないんだし、slim と同程度高速な haml のレンダリングエンジンは書けるはず」という点だった。 なので、slim と同じくらい高速ではあるものの、slim 以上に高
Railsアプリケーション構築ガイド¶ 業務でRuby on Railsを利用する人のための、アプリケーション構築ガイド 最終更新日: Feb 03, 2018 Ruby on Railsは、流儀・規則に従うことで効率的なシステム開発が可能となるWebアプリケーションフレームワークです。 レールの上に乗って開発を行っているうちは、 少ないコード量で複雑なアプリケーションを 簡単に実装できる、Railsというフレームワークの強力さ、美しさを体感できるはずです。 しかし、少しでもレールから外れたアプリケーションを実装しようとすると、途端に複雑になるのも事実です。 業務アプリケーション構築の分野では、Railsの流儀とは相容れない実装を強いられる事が多々あります。 レールから外れたアプリケーションをよく考えずに実装すると、 コードが難解になり、システムのメンテナンス性が大きく下がってしまいます。
みなさん、こんにちは。 ウェブ・サーバーサイドを担当しています、Railsエンジニアの黒田です。 マネーフォワードも早いもので、サービスインしてから2年以上が経過しました。 サービスをご愛顧してくださっている皆様には、心から感謝しております。 さて、今回のエンジニアブログは「リファクタリング」についてです。 マネーフォワードのように、ユーザーファースト&デリバリー優先で爆速開発を進めていると、サービスとしてはイケてても、コード的にイケてるとは言い難い部分が発生してしまいがちです。 「思いやりのないコード」「可読性が悪いコード」「必要以上に複雑なコード」は、バグ発生率を高め、開発スピードを低下させ、何よりエンジニアの気分を憂鬱にさせてしまいます。。。 マネーフォワードでは継続的かつ積極的にリファクタリングの時間を創る取組みをしていますが、そのなかで今回はRailsのリファクタリングでとても便
ずいぶん前のことだが、Webアプリケーション開発フレームワーク「Ruby on Rails」が00年代後半にブームを巻き起こしたとき、強い主張を持つソフトウェアとしてRailsは多くの議論を呼び起こした。その中でも最大のものはプログラマの生産性に関するもの。当時、すでにいくつも存在していたJavaベースのWebアプリケーション開発フレームワークに比べて、Ruby on Railsは10倍の生産性を達成できるという主張だ。 Rubyの生産性はJavaの10倍――。この主張が多くのエンジニアの琴線、もしくは逆鱗に触れた。「さすがに10倍は大げさだ」、「いや、現実に設定ファイルやコードを書く行数が劇的に減るのだから、そのぐらい当然だ」と意見が分かれたのだ。 2005年のリリースから約10年。Railsの生みの親で、今もプロジェクトをリードするデイビッド・ハイネマイヤー・ハンソン氏は当時を振り返り
Railsのコントローラーでのrenderメソッドの使い方について説明します。 renderメソッドは、「コントローラー(Controller)」と「ビュー(View)」のそれぞれにあります。 ここではコントローラーのrenderメソッドの使い方を示します。 ビューでのrenderメソッドの使い方は こちらを参照してください。 動作確認 Rails 4.1 目次 1. ビューを表示する 1.1. 暗黙的なビューの表示する 1.2. 他のアクションのビューを表示する(actionオプション) 1.3. 他のコントローラーのビューを表示する(templateオプション) 2. JSONを返す 2.1. renderメソッド 2.2. jbuilder 2.3. ActiveModelSerializer 3. ビュー以外を表示する 3.1. 文字列を表示する(textオプション) 3.2. X
11月4日に入社しましたエンジニアの越川です。 本日は、私がコードを書く際に気をつけていることを書こうと思ったのですが、どう書くかに迷った末、ブログ記事駆動ハッカソンを行うことでそのプロセスで考えいたことなどを記事にすることにしました。 私はコードを書く際におもてなしの心が大事だと思っています。おもてなしの心は最終的なアウトプットに触れるユーザーはもちろんのこと、チームメンバー、未来の自身へ向けた思いやりです。 今回題材とするのは、KPTツールです。KPTは、日々の活動を振り返り「Keep」すべきこと「Problem」であること「Try」したいことを上げて、活動を振り返るために使われます。 先日行われた「オレたちが目指す”最強のエンジニアドリブン”」を終えた後に振り返りでKPT使ったので、それをWebアプリにしてみます。 今回のコードはすべて、ppworks/furikaeri/tree/
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに RubyのコミッターでもありRailsなどの多くのOSSで活躍されているMarc-André Lafortune さんのブログに面白い記事があったので筆を取りました. (許可は取りましたヨ) Why I Won't Squash My Commits *注釈 [...] で記された文章は原文には存在しない私の注釈であるので留意されたいです. 翻訳に至らない所があれば編集リクエスト待ってます. 要約 PR,feature単位でcommitをまとめるかどうかでRailsのプロジェクト上などで揉めた. それぞれのcommitは独立し
技術部の中村です。 この度、クックパッド社員のこれまでの発表資料を開発者ブログにまとめて掲載することになりました。フレームワーク、デザイン、開発、運用フローなど、クックパッドでの開発における技術的知見が数多く紹介されています。 http://techlife.cookpad.com/presentations クックパッドは、多くのオープンソースプロジェクトに支えられながらここまで成長してきました。社内ライブラリの公開やオープンソースプロジェクトへの参画だけに留まらず、多くのイベントで発表を行い、我々の得た知識を還元していくことで、今後もコミュニティに対してより貢献していきたいと考えています。 なお、掲載している発表資料は下記のGitHubレポジトリにて管理されています。興味のある方はこちらもご覧ください。 https://github.com/cookpad/presentations
技術部開発基盤グループの森田です 昨日の2011年7月14日、「Ruby Recipes and Japanese Cooking At Cookpad」におきまして、「どんどん使う」と題し、弊社で開発/運用しているExtension Frameworkの紹介をさせて頂きました。その際に利用したスライドを公開致します。 スライドの主な内容は以下の2点です。 「プロトタイプで作成中のコードを機能単位で実装し、メインのコードと区別することで、低品質と高品質のコードを使い分ける」 「障害が発生した場合も影響を最小限に抑える」 スライドが、少しでも皆様のサービス開発の助けになれば幸いです。 Createanduse [slideshare id=8601603&w=425&h=355&sc=no] View more presentations from eudoxa
以前投稿した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 │ │ │
はじめに 今回はドキュメント指向型データベースの代表としてMongoDBを取り上げます。ドキュメント指向型データベースはRDBMSと違って、スキーマ(テーブル定義)が必要ないことが大きな特徴です。 今回も利用したコードやプログラムはgithubに置いてあるので適宜参照してください。 MongoDBの特徴 前々回、前回と紹介したmemcachedやTokyoTyrantは基本的にRDBMSと組み合わせて、「RDBMSの弱い部分を補う」という使い方でした。しかしMongoDBは少し違っていて、JOINが行えないこととトランザクションをサポートしていないこと以外は、ほぼRDBMSと同じように扱うことができるため、「RDBMSの代替として使う」ことが可能です。 上述したようにMongoDBはRDBMSと違ってJOINはできませんが、代わりに基準となるオブジェクトに別のオブジェクトをあらかじめe
技術部・開発基盤グループの中村です。 この度、クックパッドが開発し、オープンソースとして公開しているRuby on Rails向けプロトタイプ開発用のプラグイン「Chanko」を再設計し、Ruby 2.0.0 への移行に引き続き Chanko 2.0.0 をリリースしました。Chanko 2.0.0 では、これまでのバージョンと互換性を保ちながら、主に実行速度やコードの可読性について改善が加えられています。 http://cookpad.github.io/chanko/ Chankoとは Chankoは、素早く安全に新機能のプロトタイプを行うためのフレームワークです。クックパッドでは今現在でも、Chankoを使って多くの機能を独立して開発し、対象範囲を限定して公開することで新機能の検証サイクルを回しています。Chankoを利用して拡張した機能でエラーが起きた場合、拡張前の機能に自動的に切
本ガイドでは、Railsの「エンジン」について解説します。Railsエンジンのきわめて簡潔で使いやすいインターフェイスを用いて、ホストとなるRailsアプリケーションに機能を追加する方法についても解説します。 このガイドの内容: エンジンの役割 エンジンの生成方法 エンジンのビルド方法 エンジンをアプリケーションにフックする エンジン機能をアプリケーションで上書きする 読み込み/設定フックでRailsフレームワークが読み込まれないようにする方法 1 Railsにおけるエンジンの役割 Railsのエンジン(engine)は、ホストとなるRailsアプリケーションに機能を提供するミニチュア版Railsアプリケーションとみなせます。この場合、ホストとなるRailsアプリケーションは、実際にはエンジンに「ターボをかけた」ようなものにすぎず、Rails::ApplicationクラスはRails::
前回、前々回の記事では、Rackの生まれた背景、Rackとは何か、実際にRackアプリケーションを作る際に使えるものをご紹介しましたが、もう一つまだ説明していない重要な要素がRackにはあります。今回は、そのミドルウェアという仕組みについてご紹介します。 ミドルウェアとは ミドルウェアとは何かを一言で言うと、「別なアプリケーションをラップして、リクエストやレスポンスを加工したり、処理を切り換えたりするRackアプリケーション」です。 この仕組みがあることで一体何ができるのでしょうか。Webアプリケーションを作っていると、リクエストやレスポンスをアプリケーションに行く前やアプリケーションの処理の後に加工したくなることはよくあります。例えば、条件に応じてURLの書き換えをしたり、エンコーディングの変換をしたり、Cookieの処理をしたり…といったことが日常茶飯事です。こういう処理を、サーバと
はじめに 今回からタイプ毎に代表的なNoSQLデータベースを扱っていきます。まず今回は、揮発性key-valueストアの代表としてmemcachedを取り上げます。 なお、利用したコードやプログラムはgithubに置いてあります。適宜参照してください。 どんなところに使える? memcachedの特徴は、何といってもデータの揮発性(memcachedサーバを停止すると全データが消えてしまうこと)です[1]。そのため、データが消えても影響が小さいところに利用シーンは限られてきます。一方、連想配列(ハッシュ)のように使えて扱いやすいこと、様々なサイトでの事例があること、などから導入はしやすいです。 具体的な利用シーン memcachedの具体的な利用シーンとしては、以下の事柄が考えられます。 RDBMSから取得したデータのキャッシュ 消えても大きな影響の無いデータの保存 一般的には(1)のよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く