テストで手を抜く:steps to phantasien t(2006-02-12)
海辺のカフカ もらいもの. すばらしく面白かった. (実はもう内容をほとんど覚えていないが, それは良い娯楽作品の条件だと思う...) 村上春樹はなんというか, 日本語が卓越しているね. こんなにストレスなく読めて, かつ下品でない日本語を書ける作家は他に見ない. アマゾン・ドット・コムの光と影 前から気になっていたのを近所の本屋で発見し読む. 資本主義的に良い会社で働くのが幸せとは限らないのは実感としては 当り前ではあるが, Amazon(JP) の配送センターで働くという極端なケースの体験記. Amazon は素晴しい企業だ. 流通やアルバイトの活用といった計算機的でない部分の出来が良いと 計算機は威力を発揮するのだなあ. Expert One-on-One J2EE Development without EJB Spring Framwork の思想に基いた J2EE のアプリケー
Martin Fowler's Bliki in Japanese - 技術的負債
http://www.martinfowler.com/bliki/TechnicalDebt.html システムに新しい機能を追加するとしよう。2つのやり方があるはずだ。ひとつは、早いけれど、ぐちゃぐちゃになるやり方（将来、変更が困難になることは分かっているよね）。もうひとつは、キレイな設計だけど、導入に時間のかかるやり方。 「技術的負債」とは、Ward Cunningham が作ったメタファーである。上記の問題について考える際に、この言葉が役に立つ。このメタファーを使うと、早いけれど汚い解決方法は（ファイナンスの負債と同じく）技術的な負債が発生する、ということになる。 通常の負債と同じく、こちらの負債も利子を払う必要がでてくる。 早いけれど汚い設計を選んだせいで、将来の開発において余分な労力をさかねばならなくなる、というわけだ。 これからずっと利子を払いつづけていくことも可能だし、 リ
スラッシュドット ジャパン | バグを発見する典型的なやり方ってありますか？
あるAnonymous Coward曰く、"Mu: 経由で、「w3mのデバッグの記録」というのを読んだ。 w3mのバグを修正した時の記録です。バグ修正のケーススタディ的な物があると有用かなと思ったので、公開します。 バグの発見方法 * なにはともあれ、ktrace * fstatでオープンしているファイルの状態を見る * w3mのソースからgzipの処理部を探す * pcloseが呼ばれているのかを検証 * pcloseではクローズできないpipeがある? * pipeをオープンする方法は、popenだけではない 時々、じっとログを眺めていたかと思うと「キター」とかいってバグを発見するヒトもいるのですが、みなさんはバグを発見するための定石などありますか？聞いてみたいです。"
モノーキ〜デバッグパターン
デザインパターンを勉強していて、ふとデバッグにもパターンがあるよな。 と思って作ってみました。 これって、どこかに協力を仰ぎたいけど、誰に頼むんだ？ （結果的に協力してもらいました。thanks XPMLの皆さん、lemonさん） 何かおもいついた方はこちらへメールか、掲示板へ プログラマ用セキュリティホールパターンってのが欲しいな 例えばSQL injectionとかいうセキュリティホール。 こんなの知らないと絶対やってしまう。 OSとかの設定ではなく、プログラマの設計において注意するセキュリティホールのパターンが欲しい。 集計などはやってもいいので、どこかで有志を募って集めてくれませんかね？ ○デバッグパターンについて ・デバッグパターンとはプログラマから観測できる現象とそれに対する原因と対策をパターンとして登録したものです。中にはアンチパターンという、やってはいけないパターンも存在し
技術的負債 （TechnicalDebt） - モジログ
Martin Fowler's Bliki in Japanese : 技術的負債（TechnicalDebt） http://capsctrl.que.jp/kdmsnr/wiki/bliki/?TechnicalDebt ＜早いけれど汚い解決方法は（ファイナンスの負債と同じく）技術的な負債が発生する＞。 これはすごくうまいメタファーだ。 ＜早いけれど汚い設計を選んだせいで、将来の開発において余分な労力をさかねばならなくなる、というわけだ。これからずっと利子を払いつづけていくことも可能だし、リファクタリングによって良い設計に修正し、元本を減らしてしまうということも可能だ。もちろん元本を減らすのにはコストがかかる。だが、それによって将来かかる利子が減るため、結果的には得なのである＞。 このメタファーは、ITを超えて通用しそうだ。「部屋を散らかしたままにする」なんていうのも、まさに負債だろう
デスマーチパンチドランカー
特に目的も無く、ぼんやりとまどろむ日曜夕方。んーーーーー。やっぱ休日はこうでないとねー。ちょこっとだけ暇。この按配がちょうどいい。 プルルルルっ。プルルルルっ。 ん？携帯？ プルルルルっ。プルルルルっ。 知らん番号だなぁ・・・・・放っておくか？ プルルルルっ。プルルルルっ。 ・・・・・・しつこいなぁ。諦めろよその辺で。 プルルルルっ。プルルルルっ。 だーーーーーー！うっせーーーーーーーー！わかったよ取ればいいんだろ取れば！もしもし？ 「あのぉ、お休み中すいません、△△ですけど・・・・」 会社のひとからでした。そっか会社のひと・・・・え？会社の人？ ひょ、ひょっとして？トラブった？サービス止まった？ 「いや、そーゆー訳じゃないんですけど」 違うんかい。ビビらせんでくれぃ。じゃあ一体何・・・・ふん・・・・ふん・・・・・。 （約２０分具体的内容が続きますが省略） 「ありがとうございましたー」 ん
道具箱の整理
はじめに この記事は、mymy-mycompany分室の2005年10月に1ヶ月をかけて書いたものです。ブログだと後から参照するのが大変なので、ここにまとめておきます。また、ブログでは時間の都合で書けなかった話も追加していく予定です。 私の道具箱 ここ１ヶ月ほど、私的Ｗｅｂサイトプロジェクトなるものに参加しています。オープンソース方式ではなくて伽藍方式。以前、オープンソースのカンファレンスに出たときに、そこで発表していた学生が、ちらと「実はオープンソースよりも伽藍のほうがクオリティが高いものができると思っているんだよね～」と話していたのが、非常～に気になってはいるのですが、そのあたりは、各自のモチベーションと時間の取り方の違いでしょうね。オープンソースでもコミットする人数（アクティブな人）が限られていれば伽藍に近くなるし、伽藍にしてもうまくいかないプロジェクトごまんとあるわけなので。 で、
多様化するWebアプリケーションへの攻撃
第１回「機密情報に合法的に近づけるWebアプリケーションを守れ」では、「Unvalidated Input（許可されていない入力）」における「Hiddenフィールドマニピュレーション」の手法について説明した。いままでアプリケーションセキュリティに携わらなかった方にも、Webサイトが攻撃されるメカニズムが、意外に単純なものであることが理解してもらえたと思う。 前回の内容に対して、周囲からいくつか質問をもらった。「こんなこと書いていいのか？」というものである。つまり、誰もが簡単に攻撃を行えることを示すことによって、かえって被害を増加させるのではないか、という懸念を持たれたわけだ。今回の記事では、より多くの攻撃手法を説明していくため、本論に移る前にこういった質問に回答しておきたい。 私たちはすでに本連載で記しているような脅威の中にいる。それは、Webアプリケーションセキュリティに携わったことのあ
naoyaのはてなダイアリー - 大規模サービスを展開する企業が陥るジレンマ
このところ大きなサービスを持ってる大きな企業が運用するウェブサイトについて考えることが多かったので、ちょっと書き殴ってみるとします。 一見すると大企業ってのは人もたくさんいるし資金もたくさんあるし、小さな企業と競争になっても、簡単にそれを踏みつぶしてしまえるような印象を受けます。いやいや、そんなに簡単じゃないんだよっていうのがイノベーションのジレンマであり、大企業病のジレンマであり。で、ウェブの企業にもう一つ当てはまるジレンマがあるなあと最近思います。 はてなダイアリーのキーワードページに、Yahoo! ニュースのトピックページからリンクされることがあります。そのニュースが Yahoo! Japan のトップページに載ってたりするものだと、キーワードページへの瞬間最大トラフィックが恐ろしいことになります。最近は対策を練ったので問題ないのですが、一時期は Yahoo! トップに載ってるニュー
userAgent一覧
ブラウザの判別や携帯の機種判別に利用するためのユーザーエージェント一覧です。ただし、ユーザーエージェントは詐称（偽物）される場合があるため、完全にユーザーエージェントでブラウザなどの判別ができるわけではありません（詐称の方法のページを参照）。ここに掲載されているものは、このサーバーなどに対してアクセスしてきたユーザーエージェント名などを抽出したものなどです。あまりに古いブラウザおよびマイナーなブラウザに関してはアクセスログがないため掲載できていません。 [トップページに戻る] ■iPhone ●iOS Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1C28 Safari/419.3 ●iOS2 Mozilla/5.0 (iPhone
Web2.0時代らしいエンジニアのクリエイティビティの引き出し方
Foxnews の "Lerning From Google" という記事を読んだ。特に目新しいことは書いていないのだが、その冒頭に書いてある、 The top executives at Google recently admitted that they kind of let their employees invent and develop whatever they think is cool and the company has no problem putting it online to see what happens. 【意訳】Googleの重役たちは、エンジニア自身がカッコいいと思うものであれば、何であれ（誰にも了解を取らずに）作ってしまって良く、会社としてもそれをそのままサービスとして公開してしまってユーザーがどう反応するかを試してみる、というやり方が全然かまわ
CNET Japan Blog - 近藤淳也の新ネットコミュニティ論：50%の完成度でサービスを出す
はてなでサービスを出す時に心がけていることとして、「50%くらいの完成度でサービスを出す」という事があります。 普通に考えれば、サービスは「これで完成」と思う部分まで作り上げて出すべきものである気がしますが、ウェブサービスの場合、実際は半分くらいの完成度で出した方がうまく行く確率が高いと思います。 新しいサービス（例えばブログとWikiがくっついたようなダイアリー）の構想を考えたとして、そのサービスの機能は3種類ぐらいに分けて考えられます。 最低限必要な機能…ログインや日記を書く機能など。どんなシステムでも持ち合わせている機能 そのサービスを特徴付ける基本機能…キーワードの自動リンクシステムや、それを実現するためのキーワード作成機能など。どのサービスにもあるわけではないが、サービスのコンセプトを表すために必須の機能 発展的機能…1.や2.を前提として考えた場合に必要となるであろう機能。コメ
Bridge Word
This shop will be powered by Are you the store owner? Log in here
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MSDN ホームページ
Download details: Windows Server 2003 Resource Kit Tools