Routing Navigator が便利 - subtechグループ - 'hceT'.sub(/\Z/,'bus').reverse
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
subtechグループ - 'hceT'.sub(/\Z/,'bus').reverse - ActiveRecord を SQLObject っぽく
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
WordPress › Error
Error establishing a database connection This either means that the username and password information in your wp-config.php file is incorrect or we can't contact the database server at localhost. This could mean your host's database server is down. Are you sure you have the correct username and password? Are you sure that you have typed the correct hostname? Are you sure that the database server i
Martin Fowler's Bliki in Japanese - ビルド言語
http://martinfowler.com/bliki/BuildLanguage.html 追記: Jon Tirsenが、Rubyを使って複雑なantビルドプロセスを動かすという面白いストーリーを書いていました。 Bruce Eckel が最近、antとmakeに関する投稿をしたのだが、それに影響を受けて、私のビルド言語に関する考えをここでシェアしておきたいと思う。 antとmakeはどちらもビルド方法を指定するものであり、ビルド方法を記述するための言語である。どちらも非常に広く使われており、成功もしている。 しかし、どちらも限界に達しているようだ。大規模システムでは、ant/makeファイルを他のプログラムから生成している人をよく見かける。 上記の理由で、私はBruceの意見に賛成なのだと思う。 簡単なビルドならば、一連のタスクと依存とで簡単に表現することが出来る。こういうビルド
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
考えさせられる - yojikのlog
RubyKaigi2006 RESTのPOST,GET,PUT,DELETEとDB(というかリソース)のCRUDの類似。Webアプリケーションにおける殆どの操作は、リソースのCRUDに対応させることができる。*1 実際のアプリのレベルに落として考えると、例えばユーザをグループに追加する際に、ユーザコントローラに対して「グループに加入させよ」メッセージを送る*2のではなく、メンバシップコントローラに、ユーザ-グループ間のメンバシップをCREATE(REST的にはPOSTで依頼)してもらう事になる。*3。 上記を徹底すればWeb(アプリ|サービス)が、外部からDBのように扱えるようになる。多分、この話がActiveResourceに繋がる。(のだと思う) なんか学ぶべき点が多そうです。 あと個人的には、DBのように扱うためには、ユーザ(や他のアプリ)との対話の中で、適切な単位でCRUDを纏め上
複雑さに金が落ちる時代は本当に終わるのか？ - アンカテ
RailsやChuraのいけてないところ これは、Ruby on Railsに対する実に的確な批判だと思う。だが、これによって逆にRailsの意味が見えてきたような気がする。 (このエントリ、入口はソフトのやや専門的な話ですが、例によって大風呂敷で、そこから"The World is Flat"の話につながっていくので、できればプログラマ以外の方もおつきあい下さい) Railsというソフト開発ツールの良さは、単に便利とかフルスタック(必要な全ての機能盛合せ)ということではなく、実践的な仕事の流れが背後に想定されていることだ。頭をひねってツールを使いこなすというより、ツール(が想定しているソフト開発手順)に「乗る」という感覚で開発を進めることができる(まさに On Rails)。 だから、Railsの個々の機能の過不足を問題にするのはあまり意味が無い。仮に不足があったとしても、オープンソース
「美しいコードを書けるからRubyを選んだ」---Ruby on Rails作者 David Heinemeier Hansson氏
現在最も注目されているWebアプリケーション・フレームワークRuby on Rails。その作者であるDavid Heinemeier Hansson氏（通称DHH氏）が日本Rubyカンファレンス2006（関連記事）のために来日した。「JavaやPHPでは書けなかった美しいコードが書けるから」---Hansson氏はRubyを開発言語として選んだ理由をこう語る（聞き手はITpro編集 高橋信頼） ---なぜRubyを選んだのですか。 以前，JavaやPHPでコードを書いていました。しかし，JavaやPHPでは美しい（Beautiful）コードを書くことができず，不満を感じていました。そんな時に（リファクタリングなどで知られる）達人プログラマMartin Fowler氏がRubyを紹介した記事を読み，自分で使ってみて，Rubyは美しいコードを書くことができる，プログラマをハッピーにする言語だ
業務屋さんとWeb屋さん (recompile.net)
羽生さんのブログに「で、だ。」っていう超いいエントリーがあった。 Javaを使いたいとかSeasar使いたいとか、そんな話じゃないのね。目的が達成できるならRailsでも何でもいいんですよ。ただ、目的達成に対しての投資対効果ってものを常に意識するよね、ことです。 そうそう、まさにそれ。目的こそ重要。 だから、羽生さんの「業務システムだから？」というエントリーにある Web屋と業務屋の違いとかいうけど、DBがあってコードがあってUIがあって、値が転がっていって、分岐があって繰り返しがあって、って見ていくと同じですよ。 という部分については、ちょっとだけ、えーって思っちゃう。 せっかく全体の話で感動していたのに、部分が似ているからって、一緒にしちゃあマズいんじゃないだろうか。さらに、 少なくとも、マルチユーザな形でRDBMSを使ってる時点で適用領域はかなり似てきますよ。 ってな具合
Rails勉強会第7回（in 恵比寿） - ヤドカリデンキ商会（ブログ版）
2日連続で勉強会に出席すること自体に意義を見いだしたのははじめて。自分の中では二つの勉強会が有機的につながった感じだったので Railsの人たちの共通認識としては「ジェネレータは重要じゃない」。scaffoldは最初のきっかけという感じで実際には使わない 前半の参加セッション：DHHふたたび 自分が録音した音声と写真を撮ったスライドでRubyKaigiのDHHの講演を再現。写真のスライドが暗くて見にくかったのと写真を切り替えるタイミングがぐだぐだで、音声はともかくスライドはあまり役に立たなかった。心より恥じる DHHが講演中はRESTという言葉を使っていないのは 正確な定義でのRESTではないことがわかっていた？ RESTの宗教論争に巻き込まれるのがいやだった？ ogijunさんいわく、スライドの日本語訳はYAPCのを見てやろうと思ったとのこと。フォントは映画の字幕で使われるやつらしい 後
RailsとABDとCRUDとワークフロー - moroの日記
羽生さんのABD(Activity Based Datamodel)ですが、それを知った感想を自分なりにすごく乱暴にまとめると、DBをイベント系とリソース系にわけた上で、仕事っていうのはリソース間やイベントとリソースの間になんらかの関係を発生させる捉える、という考え方かなぁ、と。 イベントとリソース 売上げが立つ、というイベントはつまりお客さん(リソース)と商品(リソース)との間に購入/入金という関連が発生するというふうに捉えられます、と。 あんまり例えが良くありませんが、ビジネス上のできごと＝イベントに着目し、イベントも関連テーブルのエンティティを素直にcreateすることで表現するという方法論だと読んでいます。 さらにDBを設計するということは、そういったイベント、すなわちビジネス上のアクティビティをどう記録するか、という観点でデータの持ちかたを設計していくということなんじゃないでしょ
Railsの生産性とそれで提供したい価値 - moroの日記
昨晩の続き。じゃあ仕切り直してなんでRailsって生産性が高いっていうの？というお話です。 DB設計はやっぱり必要で、UIも考えなくちゃいけないうえ、自動生成は客寄せで、ワークフローエンジンもないけれども、Railsの強みって言うのは一つはまさにRubyで書けるということ。二つ目はシンプルな哲学に基づいたフルスタックなフレームワークがいまある、ということ。 言語重要 えっと、まず予防線を。JavaはダメでRuby最高、といいたいわけではなく。 Railsの強みはRubyのシンタックスの柔軟さから来るDSLっぽい記法や、Rubyの動的な側面から来る徹底的な(自動生成じゃない部分、手動で書くべきロジックの)コードの削減だったりするんじゃないかと。ブロックと遅延評価だったり、括弧が省略できることであったり、クラスがインスタンスであったり動的にメソッドが定義できたり、っていうのはすべて書きたいコー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://dev.rakusui.jp/diary/?date=20060624
http://blog.vandev.com/articles/2006/05/04/my-first-tool-for-you
http://www.loudthinking.com/arc/000592.html
http://capsctrl.que.jp/kdmsnr/diary/20060620.html
Web Services on Railsレビュー (recompile.net)
http://blog.hasmanythrough.com/articles/2006/04/21/self-referential-through
InfoQ - A Look at Common Performance Problems in Rails
