DevLOVE2009 Fusion でお話しました:「Nature of Software Development のために」 - 角谷HTML化計画(2009-12-12)
■1 DevLOVE2009 Fusion でお話しました:「Nature of Software Development のために」 とりいそぎ背景画像集。関西Ruby会議02とスライドはほぼ同じです(実はトークの内容はだいぶ違う): For Natural Software DevelomentView more documents from Shintaro Kakutani. slideshare kakutani.com(PDF;9.1MB) スクリーンの右端が切れるのは、リフレッシュレートの調整の問題なんだよなあ、というのをトークが始まるまで忘れていた。 2010.01.15(金)のアレグザンダー祭りもよろしくお願いします。2010.01.15(金)のアレグザンダー祭りもよろしくお願いします(reprise!)。 2010-02-04追記: YouTubeで動画が公開されました
Google製Webパフォーマンス測定ツール·Speed Tracer MOONGIFT
Speed TracerはGoogle Chrome向けのオープンソース・ソフトウェア。Webサイトのパフォーマンスを測定するのはApacheのabをはじめ、様々なツールが存在する。だが最近のWebサイトではAjaxやJavaScriptを活用する等、単なるリクエスト送信だけでは適切なチューニングが難しくなっている。 Google Chromeをお使いの開発者はぜひ そこでGoogleが開発したのがSpeed Tracerだ。Speed TracerはGoogle Chromeにインストールするソフトウェアで、GWT（Google Web Toolkit）の2.0公開に合わせたツールとして提供されることになった。Google Chromeを使っている開発者はぜひ使ってみよう。 インストールするとアドレスバーの横に緑のアイコンが表示される。クリックするとモニターウィンドウが開き、計測が開始す
Google Chrome 拡張ことはじめ - 2nd life (移転しました)
2009年12月8日*1(日本時間では12/9朝)、拡張機能が有効(除くOSX)な Google Chrome ベータ版がリリースされました。同時にこつこつ開発を続けてた、はてなブックマーク Google Chrome 拡張ベータ版も公開したので、良かったら使ってみてください :D http://hatena.g.hatena.ne.jp/hatenabookmark/20091209/1260314705 というわけで、Google Chrome 拡張を作ってみたのですが、その時に参考にした資料やドキュメントをまとめてみました。 Google Chrome 拡張APIドキュメント http://code.google.com/chrome/extensions/docs.html 基本的に上のURLで必要なAPIのドキュメントはまとめられています。またページ中央下の「Doc versio
astah* 発売、ダウンロード開始です。：An Agile Way：オルタナティブ・ブログ
10/19, astah* の販売・ダウンロードを開始しました。コミュニティー版も、アイコン含めて変わっていますので、ぜひ、使ってみてください。従来のJUDEライセンスでそのまま動きます。 http://astah.change-vision.com やりたかったことは、これまでモデリングツールの導入を困難にしていた機能面、価格面での障壁をできるだけ取り去って、全世界のソフトウェア開発現場に使いやすいツールを届ける、ということ。そのために、思い切った価格帯（特に astah* UML)、エディションの変更、などをいっぺんに行なっています。 ポイント： モデリングツールを従来の2エディション（有償・無償）から3エディション（有償2種類・無償1種類）に拡充。新エディション「astah* UML」を従来製品の中間エディションとし、製品選択の幅を広げるとともに、低価格でサポート可能なモデリング環境
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
デザイン・パターンとは何か
先日のMVCの議論の際には、私自身いろいろと勉強させていただいたが、少し心配になったのは、「MVCの定義だって時代とともに変わる」「ウェブサービス用のMVCはSmalltalk時代のMVCとは異なるもの」「MVCなんか理解してなくてもアプリケーションが作れればいいじゃん」など、そもそも「MVCとは何か」どころか「デザイン・パターンとは何か」を理解していないんじゃないかと思われる発言が見られたこと。ということで、今日はデザイン・パターンについてひと言。 デザイン・パターンとは、（業界に蓄積されたノウハウに立脚した）何かを作る際の指針のこと。ソフトウェアに限らず、ものを作るときにはさまざまな（場合によってはお互いに矛盾する）要求条件や制約が課せられるわけだが、そんな時に過去にさまざまな事例を解決してきた先人の知恵を「パターン化」してノウハウとして身につけておけば、似たような事例に出会った時に効
Ruby on RailsのMVCは「えせMVC」？ | スラド
ストーリー by hylom 2009年10月14日 17時29分 結局は個々のスキルに依存するのよ、 部門より ブログ「Life is beautiful」の記事「Ruby on Railsの「えせMVC」の弊害」が話題になっている。 記事では、「RailsのMVCは厳密にはMVCではなく、Controllerにビジネスロジックを書いてしまうため、データの整合性を損なう可能性がある」との主張がなされている。これは、O/RマッパーであるActiveRecordをModelと認識してしまい、Controllerにロジックを書いてしまうからではないかと推測されている。RailsではMVCをきちんと理解していないとこういった作り方になってしまうので、フレームワークとしては不完全なのではないか？ とも書かれている。 追記やコメントでは、「RailsではActiveRecord::Baseを継承して
アジャイル開発のためのプロジェクト管理·IceScrum MOONGIFT
IceScrumはJava製のオープンソース・ソフトウェア。未だに世の中ではウォーターフォール型の開発が行われている。確かにプロジェクトの開始直後はウォーターフォール型の方が進めやすい。だが後々になって火をふきトラブルを生むのもまたウォーターフォールだ。これだけ何度も繰り返してきて、それでいて未だに行うのはなぜなのだろう。 アジャイル開発のためのプロジェクト管理 アジャイル開発が全ての解決手段になる訳ではない。これもまた手法であり、適切に自分たちにあった形で取り入れなければ火をふくのは当然だ。だが真剣にアジャイル開発を取り入れていくなら、改善される可能性はある。そのためのプロジェクト管理に使ってみたいのがIceScrumだ。 IceScrumはアジャイル開発専用のプロジェクト管理だ。機能をノート形式で記述し、スプリントにおけるバックログを管理、ロードマップやリリースプランを通じてプロジェク
えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
Ruby on Railsは「えせMVC」じゃないよー - このブログは証明できない。
Life is beautifulのこのエントリーは「釣り」でしょ？ no title 先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 ということで、MVCの解説をされています。それは、OK。で、Railsが「えせMVC」だという理由。 ActiveRecordそのものはとても便利なもので全く問題はないのだが、問題はRailsの解説書などでActiveRecordを使って抽象化されたデータベースをModelと読んでいるケースが多く見受けられる点だ。 上に述べた通
O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
パターン、Wiki、XP 時を超えた創造の原則 - 情報考学 Passion For The Future
・パターン、Wiki、XP 時を超えた創造の原則 一緒に集合知プロジェクトの仕事をした江渡さんの新刊『パターン、Wiki、XP 時を超えた創造の原則』を読んだ。名著『ゲーデル、エッシャー、バッハ』の如く、シンプルな着眼点で異な物を結びつけ、普遍の道理に導く手際に感動した。 建築家のクリストファー・アレグザンダーが1960年代に考え出した思想が、形を変えて現代のソフトウェア開発手法や、Wikipediaで花開いたWiki型の共創コミュニティに受け継がれてきていることを解明した本である。 アレグザンダーは都市計画によって作られた「人工都市」と、長い時間をかけて生成された「自然都市」を区別した。人工都市はどこかよそよそしく、自然都市は落ち着いた感じがある。ひと言で言い表すことができないけれど、自然都市にはある種の美しさ、「無名の質」とでも呼べるような価値が備わっていることに注目したのだ。 そして
Route 477(2009-07-28)
■ [book][lisp] Let Over Lambdaを読んでCommon Lispに興味を持った 途中まで読んだ。 4434133632 Lispマクロを使っていろいろ遊ぶぜ！という本。内容は濃いけど、章(テーマ)が7つあり、一つ一つの節は短めなので少しずつ読んでいくことができる。 Lisp方言には「Common Lisp」と「Scheme」(あとArcとかClojureとか)があるわけだけど、 本書で「Lisp」と書いてあればCommon Lispの方を指す。だからLispコンパイラの存在は当然だし、リーダーマクロもある。 第3のアンクオート「,.」とか全く知らなかったぜ。 んでまあ、マクロと関係ないんだけど、Schemeはシンプルさを取るために、Lispが持っていたいろいろなものを切り捨ててるんだなぁというのを今さら。 loopマクロとか、「Common Lisp使いの書くLi
Smalltalk好きから見た『パターン、Wiki、XP 〜時を超えた創造の原則』 - Smalltalkのtは小文字です
パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ) 作者: 江渡浩一郎出版社/メーカー: 技術評論社発売日: 2009/07/10メディア: 単行本（ソフトカバー）購入: 75人 クリック: 1,306回この商品を含むブログ (159件) を見る とても面白かったのであっという間に読み終えてしまいました。タイトルにある「パターン」「Wiki」「XP」については、以前、それぞれの成立経緯を調べてみたこともあったので、べつに買って読むほどのことはないかなーと当初は思っていたのですが、著者による、 RubyKaigi2009初日のライトニングトークの一番最初に発表します。タイトルは『パターン、Wiki、XP、そしてRuby』。テーマは、この本とRubyの関わりです。 この本には、オブジェクト指向の生みの親であるアラン・ケイやSmalltalkとの関わ
Twitter、進化するアーキテクチャ
原文(投稿日：2009/6/26)へのリンク Twitterサービスチームの主任エンジニアであり、主に最適化とスケーラビリティを担当しているEvan Weaver氏が、QCon London 2009においてTwitterのアーキテクチャ、とりわけ過去一年にわたって行ってきたウェブサイトの最適化について語った。 Twitterで使われているツールの多くはオープンソースである。そのスタックは、フロントサイドにRails、中間のビジネス層にC、Scala、Java、データストアとしてMySQLを利用してつくられている。すべてがRAM上に保持されており、データベースは単なるバックアップである。Railsのフロントエンドはレンダリング、複合キャッシュ、DBクエリ、同期的挿入を扱う。このフロントエンドは、MySQLクライアント、Memcachedクライアント、JSONクライアントなどの、多くはCで書
Uses This: Interviews
1277 interviews since 2009 Welcome! Uses This is a collection of nerdy interviews asking people from all walks of life what they use to get the job done. Gabby DaRienzo Game developer, artist (Celeste, Nobody Saves The World) March 29, 2024 in artist, game, windows Naz Hamid Software designer March 15, 2024 in designer, mac Justin Duke Founder/CEO (Buttondown) February 26, 2024 in developer, mac A
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
そもそもMVCとWebフレームワークの比較って正しい行為なんですか？, おい、ゆとり！横浜のビール祭で飲むぞ。 - 32nd Diary(2009-10-13)
http://twitter.com/apps
https://dankogai.livedoor.blog/archives/51232105.html