手の内を明かしにくい件について - 最速配信研究会(@yamaz)
１年ほど前からWEBサービスの内部アーキテクチャを公開する事例が増えてきた. はてな、イー・マーキュリー共同勉強会 WEB+DB PRESS ライブドア構築ノウハウ大公開 U.S Yahoo!のTechTalk こういう試みは面白いので,ガンガンやってほしいなぁと思う.ただ自分としては 一方的に情報を受け取るのみでこちらからお返しができないことに多少引け目を感じていた. 個人的には自分が得てきた経験や知識をBlogとかに書きたいんだけど, あまりに具体的なことやコアアーキテクチャに関わる部分はいろいろ 会社的に問題ありそうなのでどうにも書けなさそうと考えている. 実際のところこういうジレンマに陥ってる人は多いのかなぁと思う.たいていの 内部アーキテクチャなどをバラしてるBlogは書いてる人が社長とかCTOとかだったり, 会社がそういうのに寛容なケースのみで,一般の社員が書くのはどうにもまず
階層化するサービス (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ SOA自体、特に難しい概念ではありません。しかし、どうしてもややこしくなるのがサービスという概念です。栗原さんの書かれた「本当は単純な「SOA」という考え方」では、 実際には、SOAの考え方は極めて単純である。ソフトウェアを「サービス」という部品の集まりとして構築しようというだけのことなのだ。 サービスとは「複数のアプリケーションをまたがって共用され得るソフトウェア部品である」と言える。 サービスはビジネスプロセスの一部（サブプロセス）を表現していることが多い。 このことから、SOAとBPMの相性は極めて良いということが言える。SOAにより、ビジネスプロセス（を実装するソフトウェア）を部品化し、BPMでそれを組み合わせ、ワークフロー管理することで自由度の高い業務システ
Movable Type ブログ検索や tag 検索の結果を素敵な URL で - 2xup.org
2006-07-07T14:05:53+09:00 もうちょっと UI が解りやすくなるともっと良いのだけれど Flickr にアクセスしていつも良いなあと思うのは、直感的な URL だと思います。例えば /photos/kaminogoya/ にアクセスすれば僕の写真がみれます (最近のアカウントは不思議な文字列になっていますけれど…。設定できるのかな？)。そのあとに sets/ とつければいくつか用意された Photo Set の一覧ページに移動します。また、/こんな風にわかりやすいと、一度アクセスしたあとであればなんとなく解るようになってきますよね。こういった URL もデザインのひとつだと思います。 おなじように解りやすく気付いてからとても重宝しているのが microformats 関係でもおなじみ Technorati のウェブサイトです (.com の方)。Technorati
OOエンジニアの輪！ 〜 第 34 回 比嘉 康雄 さんの巻 〜
特になし。 私は人を丸ごと尊敬することはありません。それぞれ好きなところもあれば、嫌いなところもある。できるだけいろんな人の素敵な点を見つけて、その素敵な点を 認識したいです。 現在のお仕事について -- まず最初に、現在の業務についてお話していただけますか？ 弊社でこの 4 月より「Seasar2 技術推進グループ」が新しくできました。そこで主に、弊社の中での Seasar2 を使ったプロジェクトへの支援や、商用サポートなどをやっています。 あるいは、ちょっと会社の仕事には関係ないんですけど、Seasar プロダクトの強化もやっています。 -- 基本的には技術的なリーダーをされているのでしょうか？それともマネジメントが中心ですか？ 時と場合によりけりで、会社ではマネジメントとして判断することがほとんどです。 Seasar ファウンデーションではチーフコミッターとしての役割がありますので、
要求仕様戦争（その3）
■仕様書をどうこうする――「要求」の見える化 「要求を仕様化する技術・表現する技術」がオススメ。「要求とは」「仕様とは」からはじめて、仕様戦争までの経緯、回避するための具体的施策までが分かる。「Excel を用いた仕様書」はなかなか興味深い。 著者は「要求」と「仕様」の関係をロジックツリーに見立てる。こんなカンジ。仕様1～n を実装すれば要求Ａが実現する、という仕掛けだ。 ┌───┐ │要求Ａ │ └┬──┘ ├─仕様1（スペック1-1,1-2,1-3...） ├─仕様2（スペック2-1,2-2,2-3...） ├─ … └─仕様n（スペックn-1,n-2,n-3...） まぁ、こんなにキレイにならないだろうが、「このスペック（群）で"やりたいこと"は実現していると言えるのだろうか?」という視線が、どのフェーズでも配れるという点は素晴らしいと思う（実際に目配りするかどうかは別として）。 本
要求仕様戦争（その2）
■要求どおりに動かない、書いたとおりに動く 「こんなときどうします?」なんて律儀に訊いてくるプログラマならまだいい。その度に顧客と丁丁発止して決めりゃいいから。しかし、世の中には律儀じゃないプログラマもいる。律儀じゃないプログラマは、いちいち確認しない。結果こうなる。 「書いたとおりに作りました」 「書いてあることしか作っていません」 「書いてないことは作りこんでいません」 「書いてないことは何がおきるか分かりません」 つまり、メインルートから外れると何が起こるか（書いた本人も）分からないブツができあがる。あるいは良かれと思ってプログラマが仕様を創造することにある。経験豊かで優秀なプログラマが先回りすると喜ばれるが、失敗して「よけいなお世話」を作りこんでしまう場合もある。 あるいは、最初からこうなることを承知の上で、「書いてないもの」を実装するために別料金を請求するベンダーもいる。いわゆる
要求仕様戦争（その1）
■要求仕様とは 要求仕様とは、開発するシステムに対する顧客のニーズのこと。要するに「お客さんがやりたいこと」そのもの。仕様調整で紛糾したときの決め台詞「結局アナタは何がしたいの?」の【何】に相当する。仕様トラブルの100％はこのスレ違いによる。 要求仕様について考えるために、ちょっとした質問に答えてみよう。以下のa. b. のうち、「要求仕様」を表現しているのはどちらになるだろうか? a. 身長57メートル体重550トン b. 汎用人型決戦兵器 まず a. を考えてみる。これは「何」だろうか? これは「何」かのスペックだ（しかも部分的だ）。身長・体重は分かるが、横幅や厚み、姿かたち、素材 etc... は分からない。これは受注側が「○○はどうするの?」といちいち問い合わせる必要がある。当然、聞くのを忘れたスペックは製造者の「思い」で作られるリスクを負う。 次に b. はどうだろう。身長・体
複雑さに金が落ちる時代は本当に終わるのか？ - アンカテ
RailsやChuraのいけてないところ これは、Ruby on Railsに対する実に的確な批判だと思う。だが、これによって逆にRailsの意味が見えてきたような気がする。 (このエントリ、入口はソフトのやや専門的な話ですが、例によって大風呂敷で、そこから"The World is Flat"の話につながっていくので、できればプログラマ以外の方もおつきあい下さい) Railsというソフト開発ツールの良さは、単に便利とかフルスタック(必要な全ての機能盛合せ)ということではなく、実践的な仕事の流れが背後に想定されていることだ。頭をひねってツールを使いこなすというより、ツール(が想定しているソフト開発手順)に「乗る」という感覚で開発を進めることができる(まさに On Rails)。 だから、Railsの個々の機能の過不足を問題にするのはあまり意味が無い。仮に不足があったとしても、オープンソース
Less is More -- 身軽なことはいいことだ - アンカテ
"Less is More"というすんばらすいスピーチ発見。 IT Conversations: Jason Fried - Less is More(スピーチ本体) Less as a competitive advantage: My 10 minutes at Web 2.0 - Signal vs. Noise (by 37signals)(Transcript) em.log: "Less Is More"(日本語の短い解説) 話しているのは、37signalsのCEO Jason Fried氏。 Less Money Less People Less Time Less Abstractions More Constraints がいいよというだけのお話ですが、抽象論でなくどれも具体的な話。校長先生の話のような話ではなく、いかにも社長の話。これがIT企業の現実なんですね。 Ti
PHPのスケーラビリティとパフォーマンス:phpspot開発日誌
Digg PHP's Scalability and Performance - O'Reilly ONLamp Blog This article addresses the all-to-common false assumptions about the cost of scalability and performance in PHP applications. PHPのスケーラビリティとパフォーマンスに関する記事。 Digg等に関して等いくつか面白いことが書いてあった部分のメモ JobbyはWASPフレームワークで書かれている Diggは１ヶ月で２億ＰＶ Diggは３台のウェブサーバー＆８台のＤＢサーバーで構成されている DiggはＡＰＣ、ＭＣａｃｈｅを使っている DiggやFlickrのような大規模なアプリを１，２人で安くメンテでき、かつ素早く構築するのにPHPは適している
OBB vs AABB - Radium Software Development
iPhoneの一般修理店は予約なしでも来店できる？ 基本的には飛び込みで修理に行ってもOK iPhoneを置いていたソファにうっかりと腰かけてしまい、パネルを割ってしまった、こんな時はスマホの一般修理店へ行きましょう。画面割れは、スマホやタブレットの故障原因として非常に多いものです。予約なしで突然お店に行っても平気かしらと、不安に思う方々もいらっしゃるかもしれません。結論としては特に問題はなく、予約なしで訪問しても画面割れの修理はお願いできます。 ただし他のサービス業のお店同様、予約なしの場合、お店が混雑していると順番待ちをしなければいけないです。特に繁盛しているスマホ修理のお店だと、行列が店内で出来ており、予約なしだと、自分の順番が巡ってくるまで長時間待たされる可能性があります。平日の朝、昼なら利用客が少ない場合が多く、飛び込みでも比較スムーズに修理が頼めます。 予約は入れた方が時短に、
naoyaのはてなダイアリー - YouTube の負荷
なんつったって動画ですよ。 ブログとかmixi日記のようなテキストレベルのコンテンツに比べて、はるかにサーバーにかかる負荷は高いはずです。 YouTube と mixi を比較して "負荷" の話をしていて、「動画配信だから負荷が高い」と断定していますが、これは何を"負荷"とするかにもよるかなと思います。 "負荷" というと CPU load や I/O などリソースの消費っぷりを指す言葉というイメージがありますが。(一般的には違うものでしょうか?) そういう意味での負荷で言ったら、「YouTube = 動画 / mixi = テキストだから YouTube の方が負荷が高い」という断定はやや微妙です。負荷の種類が違うのです。 YouTube のシステムを見たときにその焦点になるのは、まず第一にネットワーク帯域。第二にストレージをどうしているかというところじゃないかなと思います。動画配信に
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
J2EE design decisions
J2EE design decisions(written by Chris Richardson) http://www.javaworld.com/javaworld/jw-01-2006/jw-0130-pojo_p.html ■概要 POJOs in Action（Manning Publications, January 2006） からの抜粋 「Patterns of Enterprise Application Architecture」の考え方をJ2EEの世界をベースに、より実装に近い観点で論述された記事と考えてもらうとわかり易いかもしれません。新規性に富んだ話は多くはなかったですが、よく纏まった記事かと思います。 ■要約 最近 POJOs、ライトウェイトフレームワークの話題が賑わせていますが、盲目的にそれを利用することは、EJB で犯した問題を繰り返すことになると警告して
＠IT：初めてのソフトウェアメトリクス（後編）
初めてのソフトウェアメトリクス（後編） ソフトウェアメトリクスを現場に組み込む テクノロジックアート 長瀬嘉秀｜矢野大介 2006/1/14 前編（ソフトウェアの品質を数値化して確かめる）、中編（凝集度と結合度：このコードのどこが悪いのか？）を通じて、ソフトウェア・メトリクスの概要を解説しながら、ツールを利用したメトリクス測定による問題点の抽出方法を提示しました。今回は、実際の開発現場で設計改善するときの問題点や、メトリクス測定を利用した改善方法を説明します。 1. 開発現場の現状 一般的に、開発が進み、機能が増えていくに従って、図1のような複数のクライアントコードからロジックコードが呼び出されるような構造になっていきます。図1で明らかなように、依存性がとても複雑になるため、徐々に拡張性や可読性、保守性が悪化していきます。また、単純に重複したコードを共通化・共有していくと、さらに複雑さが増
「50%の完成度でサービスを出す」という言葉を誤解してはいけない
はてなの近藤社長の、「５０％完成度でサービスを出す」という指摘は、まさに「ソフトウェアはサービス」の時代を反映する、ものすごく意味のある言葉だが、万が一勘違いする人がいると困るので、自戒も含めて補足しておく。 ここで言う「５０％の完成度」とは、「サービスとして『完成品』と呼ぶにはまだ機能が十分揃っていない」という意味の完成度を指し、決して「アーキテクチャーや不完全だったり、明らかなバグがあるのにサービスインしてかまわない」という意味ではないので注意が必要だ。 少し前に、私の会社で外部のエンジニアを使ってあるウェブ・サービスを作ったことがあるのだが、慣れていない人にプロジェクトのマネージメントをさせてしまったために（これは私のミス）、一応外見上は動いているものが出来てきたものの、スケーラビリティに明らかな問題があり、ユーザーの数が増えたときに破綻するようなものが出来てきてしまったのだ。 担当
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Efficient data transfer through zero copy
http://www.seshop.com/event/dev/2006/data/download/10-D/10-D-7_HI.pdf
Java Developer Connection
システム・エンジニアの基礎知識