サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
blog.hacklife.net
Rails 勉強会が終わったので、次の勉強会のテーマ決めをした。 決まったテーマは「よりよりプログラムを書くための道具としてオブジェクト指向プログラミングを使う」。別名、「C/VB6プログラマのためのオブジェクト指向プログラミング入門」。 こんな順序で内容を解説する予定。単なる Meyer 本の焼き直しですが、最近のものでこの順序と内容の解説は見たことない気がするのでやる価値はあるかなと。 DRYとルーチン 結合性と凝集性 モジュール 情報隠蔽 抽象データ型 インスタンス モジュールの壁とインスタンス生成 各インスタンスは別のもの クラス インスタンス化可能なモジュール 開放/閉鎖原則 継承 インターフェイスと実装の分離 動的束縛 ポリモーフィズム リフレクションとか高階関数とかクロージャとかジェネリクスとか execute around method とかも枝葉として取り上げようと思う。
たまに手抜きで使うコードをなんとなく載せてみる。テンプレート使いたいんだけど、ちょっとしたスクリプトだしそもそも ERB の API どんなんだったか覚えてないし、リファレンス引くのもちょっとした手間だし。てなときに使ってる。(ERB くらい覚えろよ。という話もある。覚えてもすぐ忘れるんだよなぁ。) sample_template = Proc.new do |param1, param2| %Q! とまぁこんなかんじで始まったわけですが、 この辺はぜんぶテンプレートなんですね。 だから、どんな風に何を書こうが自由なんです。 パラメタについても記法に迷うことなく いつもの形で出力することができます。 たとえば、 #{param1} こんな風に。 文中にあっても#{param2}なんだか見慣れた形式で安心です。 かんたんですね。 !.lstrip end # 使うのも簡単。API を調べたり
ということで、戦術的ピリオダイゼーション理論(以下、PTP)に夢中な今日この頃です。先に言っておくと今日の話は強力に電波なので気をつけるように。(PTP がではなく、ソフトウェア開発の類似性を云々しているこのエントリが。) PTP というのは要約すると、「フッボールの本質は予測不可能性にある。だから様々なレベルでの状況判断(=戦術)を強化することでフッボールが上達する。」(フッボールという表記はネタ元の村松さんブログの表記に合わせた。まぁ、サッカーです。)というコンセプトだと理解した。ポイントは状況判断が予測不可能性を押さえ込んでねじ伏せる道具ではなく、柔軟に状況に応じて自分が変化し対処していくための道具と位置づけられているところ。 つまるところ、村松尚登さんのブログを読め。と。 で、これが(というか、村松さんがというべきか)いろいろ良いこと言ってる。 戦術の基本はチーム戦術 「個を育てる
ruby-list から Ruby のデザインポリシー「大クラス主義」に関するメモ。 |> * 全く同じ機能で性質だけ異なるクラスを複数用意するのは大ク |> ラス主義を標榜するRuby的でない | 「大クラス主義」が良くわからかったのですが、「少機能のクラス |を多数用意するよりも多機能なクラスを少数用意しましょう」というこ |とだろう、と思っての提案なのですが、違ってたらご指摘ください。 そういうような意味です。 ruby-list:43937 過去の大クラス主義の話。 |> |そうですか……。直交性高くていいかなーと思ったんですが。 |> |このへんが大クラス主義なんでしょうか? |> |> いや、これは多クラス主義でしょう。大クラス主義は結果的に少ク |> ラス主義につながります。 | |あ、そうでなくて、「かえって複雑」と感じるのが大クラス主義 |なのかなあ、ということです。 あ
drools の記法が DSL らしくて「へー、いいなー」と思ったりしたので、なんとなく書いてみた。バックトラックを考慮していない(最初の答えを見つけたら break する)うえに速度が速いわけでもないので記法の違う if 文と言われると返す言葉もない。 要は rule, when, then のブロックでルールを定義するというのをやってみたかったということで。 when と then はメソッド定義まではできるんだけど DSL 風なアクセスをうまいこと API として定義できなくて _when と _then で妥協した。残念。 class Rrools class Rule def initialize @rule = {} end def _when &condition @rule[:condition] = condition end alias on _when def _th
「大規模サービスの運用事例まとめ」をすべて読んでいる時間がない人はこの一枚のスライドだけでも見ておくといいかもしれない。 tech days Japan 2009 の萩原正義さんのセッション「クラウドコンピューティングのエッセンス」のスライド 33 枚目にこう書いてある。(ちなみにこれはエンタープライズアプリケーションの話。) N-tier モデル 密結合が条件 障害がないことが前提 ACID トランザクションが前提 データ層がボトルネック 新しいアーキテクチャ Scale out Key-value データ 非一貫性モデル 非同期 REST, AtomPub 関数型での処理 via http://www.microsoft.com/japan/powerpro/techdays/default.mspx の T1-401 のセッション。 それぞれについての詳しい解説は上記からダウンロード
ここ数年の大規模サービスのシステム運用について調べてみたので参照したページやファイル、本へのリンクをまとめておく。PDF へのリンクも多数含まれているのでご注意を。 時代が時代なら企業のノウハウとして隠されていたような情報がこれだけ公開してもらえているというのが非常にありがたい。公開してくれている各企業や公開してくれている人に感謝。 あとで気付いたが、Google や Facebook の事例も探しておけばよかった。Thrift とかあったのに。「こんな情報もあったよ」などあればぜひ教えてください。追記していきます。 youtube http://d.hatena.ne.jp/stanaka/20070427/1177651323 digg http://d.hatena.ne.jp/stanaka/20070427/1177651323 livedoor http://labs.cybo
はてブをちら見してあれだったんで、書いておきます。タイトルは釣りタイトルっぽいですが、そんなこともなくまったくもって正直な気持ちです。 圧倒的に生産性の高い人(サイエンティスト)の研究スタイル フレームワークに踊らされるヒマがあったら、このエントリを繰り返し100回でも200回でも読んで実践してみるべきです。(こちらも1,000オーバーのブクマが付いてはいますね。) それだけの価値がこのエントリにはあります。 どうしてもフレームワークについて読みたいなら、大前研一さんの「企業参謀」「続企業参謀」をやっぱり100回でも200回でも読んで、その後で「マッキンゼー現代の経営戦略」を読んで衝撃を受けて、そこで「企業参謀」に戻ってみたら衝撃を受けたはずのことがすべてその何べんも読んだはずのその本に書いてあったことに気付いてぶっとんでみればいいと思います。 最近では斉藤嘉則さんの本のほうが人気のようで
あと、これは蛇足だけどブルーオーシャン戦略の紹介についてはウソに近いので信じないように。まぁ、あのエントリだけじゃなく Web で情報を読むとたいていポイントがずれてます。「戦略」と付いているのをなぜか無視しようとするものが多すぎます。 本を読めば一発でわかることですが、「ブルーオーシャンを行け!」なんて言葉に価値はないんです。そんなの最初から誰でもわかっている。そこに顧客にとっての新しい価値軸を生み出すためのツールとフレームワークを紹介している(そしてそこに戦略的に思考するための仕組みが入っている)のがすごいんです。(チャン・キムのチームはそのための体系だった分析と立案のプロセスも持っているはず。だからあの本は元からできる人はあの本でもやれるけど、できない人は読んでもできずにコンサルを依頼するというそういう本です。) ブルーオーシャン戦略だって、けっきょくは魅力的で説得力をもった戦略キャ
InfoQ の "EventMachine: Fast and Scalable Event-Driven I/O Framework" には「EventMachine: 高速でスケーラブルなEvent-Driven I/Oフレームワーク」という公式な邦訳があるんだが、これが何度読んでもよく意味がわからない。 もちろん、ぼく自身がイベントドリブンというものをよく理解していないという問題が大きな壁になっているのは間違いない。でも、そもそもよく理解していないから読みたいわけで、困ってしまった。EventMachine の開発者 Francis Cianfrocca のインタビューもあり、内容はよさそうな気がする。 で、何度か読むうちに「これは原文あたったほうが早いんじゃないか」と気付き、ちまちまと理解を進めながら訳したので公開しておく。 全文訳は公式のものがあるので開発者インタビューを中心に重
いわゆる mixi のレベル1分散というものがあって、「join は使わない(方がいいケースもある)」というような話も出てきたりするんですが、join で解決できる問題はアプリケーションコード書くよりも DB にやらせたかったりします。 一方でそれぞれのテーブルは別の DB 上に載っているので、ふつうに join するわけにはいきません。 てことで、無理やり join しようとやってみた手。 まず、db_a に載っている table_a の必要なレコードを取得します。 んで、そいつの1レコードにつき一つの select 句をアプリケーションで生成します。 select v1 as name1 , v2 as name2 , v3 as name3 , v4 as name4 そしてできあがった select 句を union all. ポータブルな即席 view のできあがり。 このできあ
...的な釣りタイトルが付けられた Michael Feathers の "Abstracting Away From Exceptions" がおもしろかった。 コメント欄も盛り上がっているし、reddit の方にも本人が出張してコメントつけている。 元エントリは「Exceptions をうまくあしらうパターン見つけた気がすんだけど、どうよ?」的な内容。そこに「いやいや、そもそも例外は・・・」みたいな指摘なんかも挙がっていて楽しい。コメントまで含めて読んで、初めてバランスがよくなってる。Aaron Powell の Should you catch System.Exception? も。 exceptions とか validation とか error handling とか各箇所に工夫なく書かれると可読性が落ちるのは間違いないので、エンジンやフレームワークのようなレベルでうまいこと
東京 Ruby 会議の yugui さんのセッションを聞いて、svn head の 1.9 系を使ってみたくなったので、 http://www.ruby-lang.org/ja/documentation/repository-guide に従い、 $ svn co http://svn.ruby-lang.org/repos/ruby/trunk ruby してダウンロード。 configure がない ./configure しようと思ったら、configure がない。仕方ないから autoconf しようと思ったら、autoconf が未導入だった。 yum install autoconf してみたところ、準備されているパッケージでは ruby 1.9 で必要な autoconf のバージョンを満たしていない。(CentOS4) autoconf のダウンロード http://w
まだ読んでないけど、プログラミング界の戦略サファリかと思いきや、新しい視点の提案なのかな? Stevey's Blog Rants: The Universal Design Pattern With this context in mind, I claim that the Properties Pattern is yet another kind of domain modeling, with its own unique strengths and tradeoffs, distinct from all the other modeling schools I've mentioned. At a high level, every implementation of the Properties Pattern has the same core API. It's the
はてブで「卒業研究・修士研究時の悪循環を防ごう」というのが挙がっていたので、ぼくがふだんよく使っているツールを紹介しておく。 これはうつを防止するためのツールではなくて、日常のコミュニケーションの中で必要な質問をしてもらうためのツール。企業の中で使っているものだけど、他にも使える場面があるかと思う。 ということで、「質問があったらいつでもしてください」と言わずに質問を受け付けるための4つのステップ。 今なにをしているの?と聞く したことの説明を受ける 受けた説明について、そう考えた理由や今後についての見解を聞く 最後に、何か困っていることは?と聞く 以上。 詳細の説明は省くけど、それぞれに4つ目の質問が出てきやすいようなトリックが入っているのでバカ正直にこの順で毎日会話をすればいい。 ここに書かれていないことで前提の条件になりそうなこと(心構えとか)もいくつかあるけど、それは以前紹介した「
るびまにレポートを寄稿。感無量です。 今もよくお世話になっていますが、Ruby を使い始めて以来、るびまに育てられたと言っても過言ではないくらい、いろいろな記事を繰り返し読んできました。 Ruby に関するまとまった文章としては、リファレンスマニュアルに継いで世話になった回数が多いのは間違いありません。 ささださんの るびまを続けていきたい人、何かやってみませんか? via Rubyist Magazine 4周年に寄せて の言葉もありますし、次回以降も何かしら関わることができたらいいなと思います。
yugui さんのレビューを読んで、RAILS OF RUBY ON RAILS を買ってみた。 詳しくはまた別に書きたいが、想像以上に本当にすばらしい内容の本だった。 誤解を恐れずに言ってしまうと、RAILS OF RUBY ON RAILS は Rails2.x 世代の最高のチュートリアルだと思う。これから Rails について知りたい人は、Web で一生懸命に Rails 情報を探すよりも、まずこの本を買って読んでみるほうがいい。 読むだけなら短時間で内容に目を通せるのもチュートリアル的だ。教科書としてではなくチュートリアルとして買うのであれば、(同じくショッピングカートを作っている)「RailsによるアジャイルWebアプリケーション開発」と比べてもぼくはこちらを推す。 チュートリアルと呼んでしまうと内容が薄そうに聞こえるが、この本のすごいところはチュートリアルとしての進め方をしなが
iPhone について、否定的なエントリをいくつか読んで、ちょっと違和感があった。別に iPhone 好きでも Apple 好きでもないので、否定的に受け止められること自体は構わない。 だけど、こういうものを捉えるときのアプローチとしては、「もし、後々これが大きなターニングポイントになるとしたら、何をもってターニングポイントになりうるのか?」という視点で検討したほうがいいのではないか。と思ったのだ。 その脅威が実現する可能性についてはまた別途検討すればいい。結果として何でもない単なるおもしろインターネット端末でした、という結論なら安心してスルーするか、祭りを楽しめばいい。 ただ、検討もしないで「あれがない」「これがない」と現在あるものとの比較でないもの探しをしていると、大きな流れを見失う恐れがある。(実際に買った人から「Safari 落ちすぎ!」みたいな声も挙がっているのはひとまず横に置い
で、肝心のBDDですが、これは確かに実績を上げてました。RSpecとSeleniumを使うようになって格段にバグも減ったし、「何をやってるか知りたければまずSpecを見ろ」っていう習慣も自然に浸透したし、LLに不慣れなベテランプログラマや新人プログラマを含む混成部隊でもペアプロのお陰で開発速度を維持できたし全体の技術水準も上がりました。 あと余談だけど、「Specのないコードを書くときは上長に申請書を提出させる」とか「ペアプロ時にはナビゲータはピコピコハンマー装備」とか、今回の名言「わかんないやつは黙ってろ」とか、本当にやっちゃう人ですからねyuguiさんは。実際に。そこに痺れる憧れる。 via RubyKaigi 2008に行ってきた 以上、個人的なメモ。 最近、自分でコードを書くときはよほど小さなツールでないかぎり、ほとんど BDD で開発している。BDD の体感的の感覚としては、森博
前エントリの続きで、「業務システム開発学科」の単元を挙げてみる。 これがないと作れないという要素をボトムアップ(上流・下流からいくとボトムではないけど)で挙げていったつもり。(「エンタープライズ・コンピューティング学科」は要らぬ誤解を招きそうなので、止めておく。) やりたいこと・やるべきことを決める (Why/Whom/What) 現状のヒアリング 理想形のヒアリング 目的の確認 誰が使うのか どのようなものを作るのか 計画を立てる (When/Where/Who/How much/How) スコープを決める 実現方法の検討 見積り スケジュールを決める 担当を決める 道具を知る (How) コンピュータサイエンスの基礎 (設計しテストするのもプログラミングの一部としてここに入る) ネットワークの基礎 コンピュータアーキテクチャの基礎 OS の基礎 RDB の基礎 アプリケーションのための
SI業界が開発するシステムの目的は何か? それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。 スーパークリエイターがSI業界で即戦力になれない理由 もう業務知識幻想は止めようよ。必要なのは課題を適切に設定する能力とその解決に向けてプロジェクトを円滑に進めるプロジェクト遂行能力。その最低限の基盤になるのがコンピュータサイエンスなり、プラットフォームの知識と経験でしょう。(自分も弱いのを棚に上げて言うけどさ。) 一番性質が悪いのが「業務知識」だと思うよ。この言葉も意外に確かなものを伝えていて、所詮知識なんだよね。別にそれを使って仕事をしたわけではないから、業務スキルではなく業務知識。 「業務知識」の意味するところっていうのは、『開発チームの一員としてドメインに精通している(少なくとも文化としての用語がわかり、それが
「福井プログラマー生活向上委員会」さんをあちこち読み漁っていて、書こう書こうと思っていた話を思い出しました。きっかけとなったのは、この話。 「オブジェクト指向初心者はカプセル化のことだけ考えろ」 ここにある「基本はカプセル化」という話、賛成です。設計レベルではまた別のポイントもあると思いますが、実装レベルで一番重要なのはこの点だと思います。私がオブジェクト指向プログラミングのことを理解したと感じたのもこの辺りの話を自分の中で消化したときでした。 そのときに参考にさせて頂いた抽象データ型の説明が非常に自分の中でしっくりと来た覚えがあるので、紹介いたします。 S34さんという企業のサイトの中に"C++ Technical Documents"というコンテンツがあり、そこの記事になります。 ・抽象データ型と Java/C++ そして COM/CORBA ・Cによるオブジェクト指向'風'プログラミ
職場でここ3〜4ヶ月の間、システム再構成のためのドキュメント化プロジェクトというのを進めてきた。その中で『ドキュメントを書く』ということに対する意識が随分自分の中で変化したので、メモしておく。 まずは経緯から。 そのシステムは、いわゆるレガシーなシステムで、十数年来の歴史を持つ。これまで基盤が多少変わることがあっても基本的にソフトウェアアーキテクチャ(どのような単位で機能をモジュール化するか、どのように機能を抽象化し変化に対して柔軟にするか)に変わりはなく、作った当初の設計にツギハギしてメンテナンスを続けていた。 元々は、一体何をすれば増員以外の手段で開発量を上げられるかということを議論していた。現行のアーキテクチャのままでは求められる開発期間とバージョンアップのサイクルに対して近い将来限界を迎えることが明白であったためだ。 今のアーキテクチャや設計に問題があり、メンテナンス性を大いに損ね
reddit で見かけた DHH の話がおもしろい。こういう考え方の背景があって、だから、Rails なんだよなぁ、と納得してしまう。Java VS Rails みたいな枠組では意味のある議論にならないんだよな。(わざわざふっかけたのは Rails 側だけど) 37Signals のブログで本人も紹介していたので、そちらをリンクしておく。 http://www.37signals.com/svn/posts/981-the-secret-to-making-money-online そして、気になった発言を超訳。かなり自分のためにデフォルメしているので、ちゃんと原文を聴くことを推奨です。 2,000 人から 4,0000 円を 12 ヶ月間集められると、9,600 万円になる!どうよ!? レストランを開こうってときに、世界最高峰のイタリアンレストランを開こう!と思ってレストランを始める?そ
あかさたさんの「TDD は新規性の高いサービス開発には適さない」にとても同意。 What(何を作るかっていうゴール) が決まっているかどうかに依存するってことだよね。つまり、naoya さんが言う「新しい機能を作っているときや、新しいサービスを作っているとき」は設計でも実装でもなく、本質的に企画の状態だから TDD とか関係ないと。たまたまコードで表現できる人だから企画をコードで検証している(プロトタイプ作りながら取捨選択してサービスや機能をデザインしている)だけなんでしょう。 個人的に今まで一番「BDD/TDD すばらしい!」と感じたのは、ある機能用のライブラリを書いているとき。開発時の制約で VB6.0 を使っていたんだけど、Collection にイライラしたので Ruby の Array を移植した。 まず、要素の追加とか要素へのアクセスとかの基本機能についてこつこつとテストを書い
しかし、ソースコードには、さらに他の利用者がいることを忘れてはいけません。2、3ヵ月後、何かの変更を加えるために誰かがコードを読もうとするかもしれません。この利用者の存在は、軽視されがちですが、実際には最も重要なのです。コンピュータがコンパイルするのに余分な CPU サイクルがちょっとかかったからといって誰が気に留めるでしょうか。これに対して、プログラマがコードを修正するのに1週間かかったとなると、これは問題となります。コードを理解できれば、わずか1時間で済んだかもしれないのです。 プログラムを動作させようということに必死で、将来の開発者のことを考えていられないというのでは問題です。 「リファクタリング - プログラミングの体質改善テクニック」(Martin Fowler著) 第2章 リファクタリングの原則(P56)より 業務システムを長期で使っていくことを考えると、開発のコストをいかに小
職場で要求のヒアリングについてのコメントをしたのでこちらにも転載。 ユーザが語る要求というのは、 課題があって それを解決したくて 現行の仕組み(やシステム)の制約の上で実現する案が提案される というユーザの考え方のパターンを経て出てくるアウトプット だと理解してます。 なので、ぼくがヒアリングするときは、 「その機能がないために今困っていることは何ですか?」と質問して (課題の理解) 「それはどうして困るんですか?」と質問して (本当の課題へのアプローチ) 「つまり、こういうことですか?」(抽象化)「それはなぜですか?」(理由の掘下げ)「たとえばどういうことがありますか?」(具象化)をわからないことがなくなるまで繰り返す (課題の構造分析) ということをします。
Rack ってなに? Rack は Web サーバと Ruby プログラムや Ruby で書かれた Web アプリケーションフレームワークとの間に、最小限のインターフェースを提供します。 http://rack.rubyforge.org/ Rack のインストール gem install rack Rack の簡単な始め方 Rack を使うには、まず call されるアプリケーションを書きます。call メソッドを定義し、引数に env を取ります。 # app.rb require 'rack' class TinyCaller def call(env) [200, {'Content-Type' => 'text/html'}, ["Hello, World."]] end end 続いて、Rack を使うための DSL ファイルとなる .ru ファイルを作成します。 # tiny
次のページ
このページを最初にブックマークしてみませんか?
『満足せる豚。眠たげなポチ。』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く