昔は全部無料でWebテキストが読めたが今は1000円くらいで購入することになってる。今でも進化しながらメンテナンスされており神。

2つの不確実性とリファクタリング プロダクションコードを書いていると、リファクタリングをしなければならないコードにぶち当たります。 正直なところリファクタリングは時間がかかるので避けたいものですが、必要になるようです。 必要な理由は大きく分けて2つあります。 1つ目は市場など外部の不確実性に対抗し、既存実装では不要だった抽象化を機能のために追加するためです。 これは因果的に回避できませんが、プロダクトの改善に直結するという意味でポジティブなものです。 2つ目は内部不確実性に対抗し、既存コードの意図の明瞭化や、必要以上の抽象化で身動きが取れない状況を改善するためです。 これは注意深くコードを構成することで回避可能なものです。 今回の記事では後者のリファクタリングを回避するためにどのようにコードを構成すべきかについて、筆者の判断基準を明確化することと、Railsでの適用例を示します。 (事例は
(訳注: 2016/3/2、頂いたフィードバックをもとに記事を修正いたしました。) Ruby on Railsは最近、急激に注目を集めていますが、その原因はほとんど、この言語が斬新なテクノロジーとしてもてはやされたことと、タイミングにあります。技術的な優位性は時間の経過とともに失われますから、タイミングがよかっただけでは、一過性のブームに終わり、このムーブメントの隆盛は長続きしません。従って、「Railsがいかにして、適切な技術としての位置を維持し続けるるだけでなく、影響力とコミュニティを拡大し続けてきたのか」をより多くの人に説明していく必要があります。そして、その維持・拡大を可能にした/していく要因は、物議を醸すことさえあるRailsの基本原則にあると考えています。 この基本原則はここ10年ほどの間に進化を続けてきましたが、最も強固な柱となっているルールはやはり、公開当初から制定されてい
Architecting RESTful Rails 4 API 22 Oct 2013 This is a follow-up to my previous post about Authentication with Rails, Devise and AngularJS. This time we’ll focus more on some aspects of the API implementation. One thing to keep in mind, where my previous example used Rails 3.2, I’m using Rails 4 this time around. Versioning If you are building an API which could be potentially consumed by many dif
『パーフェクト Ruby on Rails』(すがわらまさのり, 前島真一, 近藤宇智朗, 橋立友宏)を読みました。「Rails 開発に慣れてきたかな」くらいの人にちょうどいい内容だったと思います。それくらいレベルの人が少し上を目指したり、より Rails らしい設計や開発の仕方を学んだりするのにいい書籍だと思いました。Ruby 2 や Rails 4 向けの説明になっているので、新しめの情報を得たいような場合にもお薦めです。逆に、最新の Ruby や Rails でバリバリ開発しているような人には既知のことばかりで物足りないんじゃないかなという印象です。 全体的に興味はあったのですが、購入の決め手となったのは第9章「より実践的なモデルの使い方」です。どう設計するか、どうリファクタリングするかの1つの指針として読んでみたいと思いました。実際に読んだ感想としては、学びも多く、読んでよかったと
RubyKaigi 2014 talk. Points for *practical* use of metaprogramming in Ruby.
追記 まじで鳩さんのスライドでDCIについて理解したつもりになるの危険だからやめた方がいいです。せめて d.hatena.ne.jp/digitalsoul/20… を読みましょう。DCIはエンドユーザのメンタルモデルを実装に落とし込むための設計パラダイムです— Naoto Takai (@takai) December 27, 2012 ということで、以下の内容はすべて間違いである可能性が高いです。 元記事 Data - Context - Interaction いわゆる DCI が最近の人気らしい。 DCI そのものの説明をこのエントリでする気はないので、 Sapporo Ruby Kaigi の角谷さんのプレゼンなどを見るとよい。 Rails の場合、 Data はまぁ ActiveRecord / Mongoid などのいわゆる MVC におけるモデル、であっていると思う。これに
こんにちは、@IT編集部の西村賢です。IT系のオンラインメディアで編集・記者をしております。タイトルに「ど素人」と書くと、ちょっと嘘になるので「素人」と書きましたが、素人がWebアプリを作ってみた体験談と感想を書いてみたいと思います。「オレもプログラミングを勉強して何か作ってみたい!」と考えている人や、「自分でサーバを借りて何かやってみようと思っていたんだよね」という人の参考になれば幸いです。 去年の夏、Webアプリケーション開発フレームワークのRuby on Railsのことを調べていて「面白そうだな」と思い、ドキュメントに従ってサンプルアプリをいくつか作ってみました。作ったり壊したりしている間に、こう思いました。 「あれ? これなら自分が欲しかったサービスが作れちゃうんじゃないの?」 で、「Worklista」(ワークリスタ)という名前のWebサービスを作りました。3カ月ほど前から親し
ActiveSupport による Date, Time クラスの拡張まとめ。バージョンは 2.0.2 準拠。ソースを読んで script/console で動作確認を行っています。 相互置換 Date でも Time でも、それぞれ to_time および to_date で相互に置換できます。 必要であれば to_datetime で DateTime 型への変換も可能です。 to_s の拡張 to_s に引数をつける事で、所定の形式で出力してくれます。 Time.now.to_s(:db) => "2008-2-23 17:49:29" 引数と出力の対応は以下のとおり。 Time 引数出力 :db%Y-%m-%d %H:%M:%S :time%H:%M :short%d %b %H:%M :long%B %d, %Y %H:%M :long_ordinallambda { |time
はじめに 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 | つい全力ツッコミしてしまうエンジニアCEOのブログ | sumyappを読みました。最初ツッコミどころが凄い*1なと思ったんですが、二回読んでちょっと思い当たる節があるなと思ったので書きます。 Rails を勉強しない方が良い理由 Railsにはscaffoldがあるので間口がすごく広いです。実際それを紹介した 15m intro video*2 が理由で人気を博しました。が、奥行きが深い。どこまで学べば「Railsを使いこなせます」って言えるのかまるでわかりません。 鉄板作法が共有されていない 2005年に出てきた割に意外に鉄板作法が共有されていません。 たとえばビジネスロジックをどこに置くのかについては以下のような議論があります やはりお前らのMVCは間違っている Rails の
2013年12月2日更新: 参照されることが多いので Rails 4 の情報を訳注として追記しました。また、Rails 4 に関する情報は、 WEB+DB PRESS Vol.73 が非常に参考になるので、一読をおすすめします。 この文章は Mitch Crowe 氏のブログより 2012年4月14日の記事を翻訳したものです。 The 10 Most Underused ActiveRecord::Relation Methods http://blog.mitchcrowe.com/blog/2012/04/14/10-most-underused-activerecord-relation-methods/ 昨日は ActiveRecord::Relation のコードに膝まで浸かって、使われているのをこれまで全然見たことがない面白いナゲットを思い出させてくれた。この記事で、十分に活用
昨日 @bekkou68 さんに「前島さんってどうやってRubyやRails関連の情報を収集しているんですか?」って聞かれたのでまとめてみます。とりあえず海外のブログ限定で。日本ブログ編は気が向いたらやります…。 RailsCasts 有名すぎて説明不要かもしれませんね。毎週2つ(うち1つは有料購読が必要)の Rails 関連動画をアップロードしてくれているサイトです。良質な情報を定期的に届けてくれるすばらしいサイトですね。1ヶ月9ドル払って有料購読する価値は間違いなくあると断言できます。動画中で紹介しているライブラリの情報もすばらしいですが、コード例もかなりRailsっぽく綺麗に書かれていて大変参考になります。 RubyFlow いろいろなRuby開発者のブログの更新情報をまとめたブログ。簡単な紹介文に各ブログのリンクがくっついているような形式です。日によってばらつきがありますが、だいた
Rubyのデフォルト引数では、他の引数に依存した式を書ける。地味に便利。 [1] pry(main)> def foo(a, b = a * 2) [1] pry(main)* puts b [1] pry(main)* end => nil [2] pry(main)> foo(3) 6 => nil 再帰もかける。デフォルト引数で再帰させてフィボナってみる [3] pry(main)> def fib(n,r = (n <=1 ? n : fib(n-2) + fib(n-1))) [3] pry(main)* r [3] pry(main)* end => nil [4] pry(main)> 11.times do |n| puts "fib(#{n}) => #{fib(n)}" end fib(0) => 0 fib(1) => 1 fib(2) => 1 fib(3) =>
https://2021.pycon.jp/time-table/?id=273396 Webアプリ開発とデータベースマイグレーションには密接な関係があり、Pythonでよく採用されるDjangoやSQLAlchemyには、DBのスキーマを変更するマイグレーション機能があります。一般的に、プログラムを実装するときはリポジトリでブランチを作りそれぞれのブランチで実装作業を進めます。Webアプリの開発でも同様ですが、各ブランチでDBスキーマを変更する場合には注意が必要です。例えば、複数のブランチで同じテーブルのカラムを追加して使いたい場合や、DBスキーマの変更が競合する場合は、ブランチのマージ時に競合してしまいます。多くの機能を並行開発したり、マージするまでの期間が長い場合には、このような競合が増えてしまいます。 このトークでは、Djangoを例に、データベースマイグレーションの仕組みから、実
最近のRuby on Railsプロジェクトで使ってるもの・やっていることを紹介します。 rake setupちょっと前にこの記事を読んでやりたかったやつです。 Setting up a new machine for Ruby development by David of 37signals $ git clone git@your-server:you/your-repo.git $ rake setup すると、開発に必要な環境ができあがるというrake task。今いるプロジェクトではデータベースを作りなおして、開発環境用のテストデータを投入。テストデータのまとめ、各種URLなどを表示しています。 何かデータが変になったとか、まっさらの状態から動かしたいとか、そういう時はとにかくrake setupすればOK。 rake setupを一発叩けばアプリがそれなりに動く状態になる、っ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く