きょうリリースされたサイボウズさんのFeedpathをみて感想をつらつら考えていたが、POLAR BEAR BLOGさんがつっこんでいた。まったくもって同感ということで、後追いエントリを書いてみたい。（自分自身の勤務先のサービスに対する自戒の意味も大いにこめてます。） タギングや情報共有の機能に目を向ける前に、RSSリーダーとして十分な機能を提供しているか、ベータテストの間に再確認する必要があるのではないでしょうか。 僕も単純な「RSSの追加」（OPMLで複数とかじゃなくてよ）をしようとして、「認識できません」といわれた。別にひねくれたRSSでなくて、この日記のRSSで。ほかのRSSも含めて5回も10回も試したがだめだった。ブラウザが悪いのかな、、？ Validateを通っているOPMLも、なんだかエラーで読み込んでくれなかったし。 結局リーダーとして使い始めるところにすらいたらなかった。
Wednesday, January 11, 2006 もう XML 言語を開発するな Don’t Invent XML Languages by Tim Bray (Updated: 2006/01/09) XML の X は「拡張可能(Extensible)」という意味だ。自分の問題に応じて自分の XML 言語を開発できることをウリにしている。でも、僕は過去 2 、3 年の経験から、そうすべきではないことを悟った。本当に必要な時以外はね。今からそれを説明する。そして、もし本当に必要な時がくれば、関連文書のOn XML Language Design を読んで欲しい。 僕は最近ある XML 言語の開発を手伝っていたのだけれど、どうか話半分で聞いて欲しい。僕は言語デザインをメインでやっているわけではないし、僕がもし専門技術でなにか言えることがあるとすれば、それは主としてたくさんの異なる X
レジデント初期研修用資料 引っ越し前の旧blogです。新しいアドレスは http://medt00lz.s59.xrea.com/wp/ になります 専門医を目指すのは楽しいのだろうか? 始めはかけだし、使いっ走り。 そのうち手技を覚えて、自分でも何か｢やれる｣ことがだんだんと増えてくる3年目。 一人立ちを始めて、｢やれる｣と思っていたことが、実は全くイけていなかったことに 気がついて、泣きそうになりながら勉強を始める7年目。 勉強のモチベーションというのは、｢あいつは使える｣という周囲からの賞賛だった。 患者さんをよくしたいとか、医学の進歩のためとか、そういったお題目はどうでもよかった。 結果としてそうなることはあっても。 専門家の抱えるジレンマ ｢使える奴｣という声を集めるためには、その状況へ最適化しなくてはならない。 ところが、同じ状況に最適化しすぎてしまうと、もはや｢使える｣な
帰省、寿司、陶芸体験 8/13（火） 妻の実家の墓参りへ行き、俺の実家へ帰省。風呂に入る前に子供達と外で水鉄砲で水を掛け合いびしょ濡れになる。最後のほうはどうにでもなれと思い、ホースやバケツで直接水をかけ合う。久しぶりの大胆な遊び方に子供たちは大声をあげながら騒いでいるが、田…
IT Pro の開発ドキュメントの最適化で笑わせていただいた。これ書いた人は画面仕様で酷い目に遭ったことがないんだろう。笑った箇所は次の通り。 画面仕様書をプロトタイプ・アプリケーションで代用する方法がある。Webシステムの場合は，HTMLの作り方を工夫すればプロトタイプで実際の入力手順や画面遷移も確認できるようになる。エンドユーザーにとっても，ドキュメントよりは実際の画面で確認した方が分かりやすいので，手戻りが減る。これは帳票にも同じことが言える。 あのな、HTMLで作る画面なんざ、紙芝居だよ。「ふいんき」をかもし出すだけで、そいつは「仕様」じゃねぇ！ボタン配置や文字色を目の前で変えられるものだから、いつまでたっても顧客は「ちょっとコレ直して」と言ってくるんだよ。気軽に直せるものとお金を頂戴しないと直せないものがあることをギッチリと顧客に理解していただくために、画面仕様書はどうしても必要
Part1●効率化を図る リスクを考えながら無駄をなくす ドキュメントを大幅に削減したいのであれば，開発プロセスを見直すのが最も効果がある。ユーザーや開発者同士の意思疎通が図られ，お互いの合意がとれているのであれば，ドキュメントは省略可能だ。この特徴を最大限に生かしたのが，XP（Extreme Programming）による開発である。 ただ，XPを含め，お互いの合意がとれている状態にするのはかなり難しい。規模が大きくなればそもそも困難になるほか，ユーザーの立場からするとリスク回避のためにどうしてもドキュメントが不可欠になる。開発プロセスの見直しが難しい場合は，合意がとれているものは省略する，できるだけ再利用する，などして地道にドキュメントを削減していくしかない。 開発プロセスを見直す 一般に，システム構築では要求→分析→設計→実装→テストといった手順を踏んでいくが，このようなプロセスでは
mixiなどのコミュニティサイトでSEにまつわるエピソードを見ると実にネガティブなものばかり。残業の多さを嘆いたり、デスマーチは明確なのに逃れる術がないことを憂いたり、35才定年説を恐れたり等々。 そこで他の業界はどうかなぁと思っていろいろ見てまわって気づいた法則がありますのでご紹介。 【BtoCとBtoBではBtoBのほうがネガティブ】 直接個人を相手にするような業種(BtoC)と、企業を相手にするような業種(BtoB)だと、BtoBのほうが概してネガティブなようです。これは、BtoC業界に身を置くことを志向した人自体が人間やその職種が好きというポジティブな要素が強いからではないかと思っております。それに対してBtoB業界に身を置くことを志向した人は、人間関係に煩わされたくない、自分の好きな仕事だけやりたい、とにかく大きな仕事をしたい等、自身の考えかたが抽象的かつ関心が限定的で、実際仕事
なにやら物騒なタイトルつけてますが。敢えてこーさせてもらいました。 まずは例の如く私の例から書き始めましょうかね。今お守りしてるシステムのひとつなんですが。私が引き継いだ（というよりは無理矢理押し付けられた）時点で既に３年のソースそっから２年で２回のメジャーバージョンアップと幾多のマイナーバージョンアップを繰り返した結果。 見事なまでにシステム全体が複雑怪奇になっておりまして。既にメイン管理者（といっても全部一人でやってるだけなんですが）の私でさえ、全容が理解できるかできないかの瀬戸際に立たされております。「あれ？ここどーやってんだっけ？」と自分の書いたソースを目の前にして首を傾げることもしばし。 え？それはテメェが実力不足なだけ？もちろんそれはそうなのですが（反論しろ＞俺）。 私の実力云々を問わずして、既に目の前に立ちふさがってる問題があると。 私しかシステムの内容が理解できない既にシス
SEライフVol.4 SEのための見える化!の技術がまもなく発売されます。見える化! というのは、タスクとか、スケジュールとか、本来見えない物をどう見えるようにしてプロジェクトを成功に導くかという話。はてなでいうところのあしかみたいなもん。 SE ライフ Vol.4 SEのための見える化!の技術 (SEライフ) 作者: 技術評論社編集部出版社/メーカー: 技術評論社発売日: 2005/11/29メディア: 大型本 クリック: 17回この商品を含むブログ (30件) を見る この中で「はてなが挑む見える化」という題名で、僕のインタビュー記事が掲載されています。企業の隠し事はイクナイとか、半数に反対されたときこそやるべきとか、思いつく人は一万人いてもやる人は一人か二人、とかあとはてなアイデアのこととか、そんな話をしました。 インタビュワーの方が上手だったので、僕も話したいことをストレートに伝え
このところ大きなサービスを持ってる大きな企業が運用するウェブサイトについて考えることが多かったので、ちょっと書き殴ってみるとします。 一見すると大企業ってのは人もたくさんいるし資金もたくさんあるし、小さな企業と競争になっても、簡単にそれを踏みつぶしてしまえるような印象を受けます。いやいや、そんなに簡単じゃないんだよっていうのがイノベーションのジレンマであり、大企業病のジレンマであり。で、ウェブの企業にもう一つ当てはまるジレンマがあるなあと最近思います。 はてなダイアリーのキーワードページに、Yahoo! ニュースのトピックページからリンクされることがあります。そのニュースが Yahoo! Japan のトップページに載ってたりするものだと、キーワードページへの瞬間最大トラフィックが恐ろしいことになります。最近は対策を練ったので問題ないのですが、一時期は Yahoo! トップに載ってるニュー
証券会社のボードには株価が表示されず、ようやく午後１時半に復旧します。過去にもシステム障害が発生したことがありますが、全銘柄にわたり売買が停止するのは初めてでした。 各家庭に届けられた夕刊の紙面が異様でした。株式欄に値が全然入っていない紙面です。 10月のプログラム変更が引き金に今までの報道からシステム障害の経緯をまとめてみました。 10月8日〜10日の三連休 売買取引の増加に伴い、1日あたりの処理量を増やすため売買システムの能力増強を行います。 この時にプログラムにバグがあることをシステム担当の富士通が発見します。富士通がプログラムを修正、テストを行い、修正したプログラムを仮登録します。 10月13日(木） 東証の関連会社でシステム管理を担う東証コンピュータシステムが、富士通からの作業指示書をもとにプログラムを本番環境へ登録します。 ところが、富士通が作成した作業指示書に記載漏れがあった
連載1回目に当たり、まずアーキテクチャ不在のシステムがどうなるか、簡単な例で紹介しよう。インターネット・ショッピングのWebサイトを思い浮かべていただこう。インターネット上で商品のカタログを見せてオーダーを受け付けるということであれば、次のようなシステム構成でも一応可能である。 さて、このようなシステムで販売を開始後、商品に人気が出て注文が殺到したらどうなるだろうか。マシンの能力が追いつかず、注文がさばき切れなくなって、今度は苦情が殺到することになりかねない。 CPUやメモリの能力を増強して対応しようとしても、マシンを増強している間は、システムの停止を余儀なくされるし、増強しても、1台のマシンでは物理的に搭載できるCPUとメモリの限界がある。 また、このシステム構成はセキュリティ的にも問題がある。一応ファイアウォールは設置しているが、さまざまなテクニックを駆使されてセキュリティが破られ、サ
ITアーキテクトという職種は、その職種をつくり上げてきた先人がいたからこそ、今日存在するものだといえる。ITアーキテクトをつくり上げ、現在第一線のITアーキテクトとして活躍しているエンジニアは、どのような道筋をたどってきたのか。また、今日のITアーキテクトの流行をどのように見ているのか。情報処理推進機構（IPA）ITアーキテクト委員会の主事を務める日本IBM サービス事業 ストラテジー＆コンピテンシー IBMディスティングイッシュド・エンジニア ITアーキテクト 榊原彰氏のインタビューをお送りする 私が入社したときには、実はITアーキテクトという職種は存在していませんでした。現在でいうプロジェクトマネージャもITアーキテクトもすべて「システムエンジニア」（SE）という1つの職種でくくられていたのです。システムエンジニアのほか、メインフレームマシンの保守を担当する「カスタマーエンジニア」、そ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く