ITエンジニアの「やってはいけない」---目次：ITpro
設計・実装から運用，メソドロジまで，最新アンチパターンを徹底解説 先輩から教わったことのなかに多くの「やってはいけないこと」（アンチパターン）があるだろう。だが，その理由を問われると，うまく説明できないことがあるのではないだろうか。突き詰めて考えると，状況によっては「やっても構わない」こともあるし，技術の進化に伴い「やれるようになってきた」こともある。そこで設計，実装，テスト，運用，メソドロジの各分野について，取材を通じて浮かび上がった最新アンチパターンを徹底解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル３～レベル１の３段階あり，レベルの数字が大きいほど，やってはいけない度合いも大きい。 関連サイト： ■設計編 ■メソドロジ編 ■実装編 ■テスト編 ■運用編 ■サーバー運用編 ■データベース編 ■セキュリティ編 ■記録メディア編 ■方式設計編 ■内部統制編
「プログラム設計書」って必要？ | おごちゃんの雑文
最近のお題は「プログラム設計書」らしい。 私はプログラムに書くコメントが嫌いだ。それどころか コメントを書いたら負け とさえ思っている。同じ理由で、「プログラム設計書」とか「詳細仕様書」と呼ばれるコードレベルの設計書も嫌いだ。嫌いなだけじゃなくて不要だと思っている。 なんせそういったコードレベルの設計書に書くべきことは細かい。細かいということは、「実装を縛る」ものだから、その分精度が必要となる。ところが、精度を追及すると、 書くのが大変 検証が大変 版管理が大変 ということになって、いたずらに工数が増える。そして、タチの悪いことに、 すぐ嘘になり、その嘘を検証するのが困難 ということになってしまう。 何しろ人間ってのは間違える。間違えなくても、想像力に限界がある。そのため、コードレベルの設計書はどんどん改訂しなきゃいけないことになるのだが、その改訂に付随する手間もさることながら、そうやって
自分のサイトの見え方とロード時間を徹底調査
How to Completely Test Your Website | Digital Inspiration 自分のサイトは他の環境ではどのように見えているのだろう？ IE では？ Firefox では？ OS の違いはどう影響している？ それと、モバイルで環境で見ている人が多い中、ロード時間はどうなっているのだろう？ こうした疑問に答えるために使えるサイトが Digital Inspiration でまとめて紹介されていました。最近テンプレートの変更作業で使う頻度が高まっていますので、自分がつかいそうなものだけピックアップしてご紹介いたします。 他の環境でのサイトの見え方をチェック まず Browsershots はご存じの人も多いと思いますが、Linux, Windows, Mac OS X など封数の OS に数多くのブラウザを組み合わせて何十種類ものスクリーンショットを作って
建物と違って、一見簡単に修正が利きそうなのがソフトウェアの問題点かな、と
これを読んで、「SIerの仕事って『工事』だったのかあ」と思った人は私だけではないはず。 これまでSIerは、工事進行基準ではなく、開発終了時に売り上げと原価を一括計上できる「工事完成基準」を取るケースが多かった。一般的に日本のシステム開発は要件定義やユーザー企業との契約が明確でなく、開発中の手戻りや期間の超過が多い...【デスマーチがなくなる？ IT業界に義務付け「工事進行基準」ってなんだ − ＠ITより引用】 さらに「工事進行基準」と「工事完成基準」の定義を読むとますますそう思える。 工事進行基準 長期請負工事契約に関する会計上の収益認識基準の1つ。工事期間中、目的物が完成に近づくにつれて徐々に収益が発生するものと考え、工事の完成度合いに応じて工事に関する収益と原価を計上し、各会計期間に分配する方法である。“発生主義”に基づく収益認識法とされる。【工事進行基準 − ＠IT情報マネジメン
中島さんと古川さんの対談 - naoyaのはてなダイアリー
中島聡さん の おもてなしの経営学 アップルがソニーを超えた理由 (アスキー新書) を読みました。とにかく古川さん との対談が面白い。「経営学」と題している書籍ではあるのですが、この対談の箇所だけを抜き取ると、一人のソフトウェアエンジニアがどのようにして未来を切り開いたかというエンジニア論の体をなしています。 著者の中島さんの blog ははてなブックマークでも人気エントリーの常連なので、ご存じの方も多いことかと思います。 ところで 1998 年に、マイクロソフトがブラウザ戦争 (wikipedia:ブラウザ戦争)の結果、独占禁止法で提訴されたことがありました。個人的にはネットスケープがマイクロソフトにボコボコにされて「もうやめて、ネットスケープのライフは 0 よ!」と勝敗が完全についた区切り/象徴である事件だと認識していて、当時はまだそれほど IT ビジネスに関心がなかったにも関わらず興
「作っては壊す」過程があってこそ良いものが作れる
iPhone用の「はてな人気エントリーリーダー」、そろそろ形になってきたのだが、作ってみていろいろと発見した部分もあったので、全面的にクラス構成を見直し、大幅に書き直した。 HTTPで通信をしているコードが二カ所に分かれていたので、それをDataOverHTTP/XMLOverHTTPという二つのクラスにまとめ（XMLOverHTTPはDataOverHTTPのサブクラス）、はてな独自のRSSフィードを読んでいるコードから一般的なRSSフィードを扱うコードをくくりだしてRSSFeed/RSSFeedLoaderという二つのクラスにまとめて、あとで別のアプリケーションで再利用することを可能にした。それに加えて、各種ローダーに非同期通信をさせる主体をController（HotEntryViewController）からModel側（HateneHotEntry）に移すことにより、難解になりが
はてなブックマークの作り直しについて - naoyaのはてなダイアリー
id:naoya:20080320:1206009912 でも少し触れましたが、京都に来てからはてなブックマークの作り直しをしています。どういう意図を持って作り直そうとしているかを述べておきます。 まず大前提として、今のはてなブックマークに追加したい機能、変更したい仕様、本来追加するはずが途中で頓挫したものが結構な数で山積みになっています。それを実現するための基礎作りです。 追加したい機能、変更したい箇所 おそらく新システムの最初のリリース時には、それほど大きく変わった、という印象にはならないかと思います。長く続いているサービスですし、インタフェースや使い方もリリース当初からそれほど大きくは変わっていません。既存システムからの極端な変更は歓迎されないだろうと思っており、まずはオリジナルが持っていた機能をしっかり再現することが重要です。 ただし、既存システムでも問題と思っている箇所は改善して
ただユーザーを観察すればよいってわけじゃない。: DESIGN IT! w/LOVE
なんでもかんでもユーザーに聞けばよいってわけじゃない。 いや、ユーザー中心のデザインにおけるユーザー調査では、むしろ、「ユーザーの意見は聞いてはいけない」とさえいわれます。意見を聞くのではなく、ユーザーの行動を観察せよ、と。 でもね。ただユーザーを観察すればよいかっていうと、そういうわけでもないんですよね。 観察調査だっておなじで「わかろう」としなければ何も「わかりません」。 極端な話、ただ見るだけだったら目をあけてるあいだなら誰でも四六時中やってるわけです。見るだけでわかるなら、とっくにわかってていいはずです。わざわざ観察調査をするのは、単に目の前でユーザーに普段の行動をとってもらうためだけじゃありません。 観察調査というのは、ユーザーの行動のなかに未来のデザインの輪郭を見つけるためのものです。つまり、実際にはそこにあるようでない「未来のデザインの輪郭」なるものを見るわけですから、ぼーっ
お金ありきではありません、ユーザー経験ありきです。 - GoTheDistance
id:dropdbさんの所で「お金ありきか。」というエントリが書かれています。 お金ありきか。 お金ありきか。そのにー 企画屋のはしくれですので参考になればいいなと思い、ひとこと言っておきます。 経験上感じるのが、技術を担いで商売している会社においては、「こういう技術を使えばこんな面白いもんが出来るんだっていうアツさ」から企画の背骨ができて来るのが多いことです。まずはそういうアツさを共有できるようなディスカッションの場を持つことをお勧めします。これはコンサルタントをやっていて痛感するのですが、ディスカッションは議題によって狂おしく相手を選びます。特にWHATそのものを考えるディスカッションをするのであれば、ディスカッション・パートナーの発掘が何よりも大切です。彼女がディレクター的な立場なら、まず考えなければならないのはここだと思います。 技術無くしては何も生まれはしないのですが、技術目線で
ユーザビリティ | 秋元@サイボウズラボ・プログラマー・ブログ
Eric Burkeさんのブログ Staff That Happens(閉鎖)より、単純さ(Simplicity)とは、 Apple や Google と、「あなたの会社の製品」では、カバーする内容が違っているというのもあるだろうけれど、ユーザーが選べる箇所を減らすためにはどうするか、という視点を持つことについて示唆に富む比較かもしれないと思った。 [更新 2015-09-11 リンク先閉鎖確認にあわせて修正] この記事は移転前の古いURLで公開された時のものですブックマークが新旧で分散している場合があります。移転前は現在とは文体が違い「である」調です。(参考)記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません
Passion For The Future: CSVデータをテーブル形式のHTMLに変換するdata2html
CSVデータをテーブル形式のHTMLに変換するdata2html スポンサード リンク ・CSVデータをテーブル形式のHTMLに変換するdata2html http://www.vector.co.jp/soft/winnt/net/se439938.html ちょっとしたテーブルデータをWebで公開したいときに、CSVを簡単なHTMLに変換してくれるフリーソフト。カンマやタブ区切りのテキストデータを読み込ませて、フォント、罫線、背景などのテーブルの要素を指定すると、一発でHTMLを生成してくれる。 プレビュー機能があるので思い通りに変換されたかどうかを見ながら作業ができるのがよい。趣味でもゲームのスコア表などを公開するのに使えそうである。 類似ソフトはいろいろあるのだが操作と生成するHTMLがシンプルなのが気に入った。 スポンサード リンク Posted by daiya at 2008
ブックレビュー - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2002年3月13日 水曜 「すべてのプログラマのための完璧にかなり近いリスト」 -- ジャン・ダーク どんな本を読んでいるかということから、その人について多くのことを知ることができる。あなたの読む本がすべて私と同じなら、きっとあなたも私と同じように考えるようになる。私は常々そんな風に考えていた。 それでここに用意したのが「ジョエルのプログラマの書棚」だ。この短いリストは、すべての現役プログラマが本当に読むべきだと私が思っている本を集めたものだ。私自身の書いた本も気付かないようにもぐり込ませてあって、買ってもらえると私に2ドルばかり入る。 やさしいソフトウェアマネジメント Tom Demarco and Timothy R. Lister, "Peopleware: Productive Projects and Teams" 「ピープルウエア 第
Japanese - The Joel on Software Translation Project
[edit] カリフォルニア 2007年10月5日 [edit] FogBugz On Demand 2007年7月9日 [edit] マネジメントの本 2007年6月29日 [edit] 記憶に残るようなカスタマサービスへの7ステップ 2007年2月19日 [edit] ファウンダーズ アット ワーク 2007年1月30日 [edit] Copilot 2.0リリース! 2007年1月26日 [edit] ビッグピクチャー 2007年1月21日 [edit] 新年の抱負: もっといい仕事につくこと! 2006年12月20日 [edit] 50万件のバグ! 2006年12月20日 [edit] 新作! 2006年12月18日 [edit] エレガンス 2006年12月15日 人々がソフトウェアをいじるのは、多くの場合、それで遊びたくてそうしているわけではない。彼らがソフトウェアを使うの
マイクロソフト技術資料公開のニュース考 - Thoughts and Notes from CA
マイクロソフトのOSは複雑怪奇なAPIの使用をプログラムの開発者に強要し、そのプログラムを他のOSに移植することを極めて困難にしており、非常にけしからんという下記の話を読んでいるところに、 [rakuten:book:10784257:detail] 新しいもの作りの支障となるような状況。これこそが、フリーソフトウェア運動がそもそも勢いづく基礎となっている。これはマイクロソフトのオペレーティングシステム、つまりウィンドウズ用にプログラムを書いたことのあるプログラマに聞けばすぐわかることだが、ウィンドウズにはやっかいなインターフェイスがぎっしりと詰まっている。その目的は、マイクロソフトのライブラリに完全に依存しなければプログラムが作成できないようにするためである。マイクロソフトは、ウィンドウズのネイティブプログラムをほかのオペレーティングシステムに移植することをきわめて難しくしようとして、膨
Software Error
Software Error:HTML::Template->new() : Cannot open included file ./tmpl/site//.tmpl : file not found. at lib/HTML/Template.pm line 1616. HTML::Template::_init_template(HTML::Template=HASH(0x9b07918)) called at lib/HTML/Template.pm line 1189 HTML::Template::_init(HTML::Template=HASH(0x9b07918)) called at lib/HTML/Template.pm line 1083 HTML::Template::new("HTML::Template", "filename", "./tmpl/site//
REAとビジネスパターン入門(1)
コンサルティング業の片手間に，翻訳業をしている。ここしばらく作品がなかったのだが，今月（2007年8月）は2冊の監修・監訳作業を終えることが出来た。1冊は，まもなく発売される予定の『実践UML 第3版』。もう一冊は，日経BPソフトプレス発行の『ビジネスパターンによるモデル駆動設計』（以下，『モデル駆動設計』と呼ぶ）である。 『モデル駆動設計』のほうが，ちょうど書店に並び始めたので，今回は，そこに登場するREAという概念と，モデル駆動設計の方法について紹介してみたい。翻訳作業が終わって1カ月あまりになるが，この原稿の準備をするなかで，あらためてわかったこの書籍のおもしろみや，類書との類似点や相違点についても触れてみたい。 REAとは何か 『モデル駆動設計』の副題は「REAによる新しいモデリング手法」である。REAとは，リソース（Resource)，イベント（Event），エージェント（Age
"Less is more"なもの作りと合議制と
ズバリ言ってしまうと既存機能に上乗せする企画は通すのが簡単だし、リスクが少ないからだ。【機能やボタンが多すぎ!! 使いにくいUIのデジタル家電が発売されてしまう本当の理由 - キャズムを超えろ！より引用】 こういった罠にハマらないためには、色々とすべきこと・してはいけないことがあるが、たぶん最も強く意識すべきは「合議制では良いものは作れない」という法則。デザインに関わる人が多ければ多いほど、「いろいろな意見」が寄せられてしまい、「せっかく有意義な意見を出してもらったのだから」と次々に意見を取り入れているうちに、機能だけはたくさんあるけど魂が無くて妙に使いにくいものが出来てしまう。 その意味では、37signalsの人たちが言うところの「less is more」は「単に機能を削って使いやすくする」というだけの話ではなく、「企画に関わる人の数を削って魂があるものを作る」というもの作りの過程そ
kuranukiの日記 - ディフェンシブな開発 〜 SIビジネスの致命的欠陥
Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。 そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。 そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。 RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。 しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://shi3z.blog.so-net.ne.jp/2008-03-02
マスカット Project