ITエンジニアの「やってはいけない」---目次：ITpro
設計・実装から運用，メソドロジまで，最新アンチパターンを徹底解説 先輩から教わったことのなかに多くの「やってはいけないこと」（アンチパターン）があるだろう。だが，その理由を問われると，うまく説明できないことがあるのではないだろうか。突き詰めて考えると，状況によっては「やっても構わない」こともあるし，技術の進化に伴い「やれるようになってきた」こともある。そこで設計，実装，テスト，運用，メソドロジの各分野について，取材を通じて浮かび上がった最新アンチパターンを徹底解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル３～レベル１の３段階あり，レベルの数字が大きいほど，やってはいけない度合いも大きい。 関連サイト： ■設計編 ■メソドロジ編 ■実装編 ■テスト編 ■運用編 ■サーバー運用編 ■データベース編 ■セキュリティ編 ■記録メディア編 ■方式設計編 ■内部統制編
ウノウラボ Unoh Labs: WEBアプリのテストに必須なツール７種
こんにちは！やまもと＠テスト番長です。 前回satoさんの書いたエントリーが好評のようですね。 自分は実は美術系出身です。なので「デザインセンスのある人からみた～」というエントリーでも続けて書いちゃおうかなと一瞬思いましたが、世の中にはWEBデザインのプロの方もいらっしゃることだし、控えておきましょう。 センスってのも考え込むと難しいですしね。 個人的には、WEBデザインの美醜って「使いやすさ」とかなり直結な気がしてます。 さて、今回は僕が普段テストに使っているツールでもご紹介してみようかと思います。 Selenium 一年前くらいに登場した無償の自動実行ツールです。 有償の自動実行ツールは以前からありましたが、 ベンチャーが購入するには高価なものなので 大手以外にはあまり導入されていなかったであろう類のツールです。 テストシナリオにそってブラウザを自動で操作してくれます。
ウノウラボ Unoh Labs: 1人のエンジニアがフォト蔵リニューアルを通して学んだこと（前編）
naoyaです。 いつも技術系の記事が多いのですが、今日はすこし別のテーマでエントリしたいと思います。 僕は入社してからフォト蔵チームで、フォト蔵のバグ修正や機能拡張を行ってきました。 現在、フォト蔵は11月1日にサイトデザインの大幅なリニューアルを行い、現在は試用期間中です。僕もフォト蔵チームで、フォト蔵をオープンして以来3回目となるサイトデザインのリニューアルに設計当初から参加できる貴重なチャンスを得ることができました。 なので、今回はフォト蔵のリニューアルを通して体験したこと、学べた、感じたことについて書きたいと思います。 フォト蔵のリニューアル開始時（2006年7月下旬頃）は、次のような人員体制でした。 ・リーダー：１人 ・デザイナー：１人 ・エンジニア：１人（僕） 第一章：リニューアル開始 リニューアルにあたっての最初の作業は、美人デザイナーsashaさんがサイト
サービス開発発想と企業システム発想
スケーラビリティと機能性は不可分。発行するSQL文が増える可能性がある以上、明らかにトレードオフの関係となる。 キレイ事や正論やあるべき論ではなく、実際、これでいいんじゃないかと思うんだがどうだろう、と言う質問。 ■Webサービス開発： キーワード：むしろ冗長でも良い、まずは最適化発想禁止、スケーラビリティは運用しながら調整（計算できないし、サービスの発展にあわせて作るかえるべき） 目的：極論だけど日単位で機能追加が可能であることを最重視 ■エンタープライズなサービス開発： キーワード：冗長は害悪、常に100%の最適化発想、スケーラビリティは社員の数と伸びで計算可能 目的：スケーラビリティは基本的に予測可能として考える。安定性と機能完成度重視なので、あらゆることを固める必要あり。アジャイル発想で、最近はそうでもないかもしれないけど、Webサービスほど発展が不明確ではないと思う。(M&Aして
Dashi Blog - Variety Of Information at One blog
Diabetes is a condition which requires constant monitoring. Keep in mind that when it comes to screening your blood sugar people who are diabetic are advised to ensure that they buy testing kits. When you receive the test strips they are usually in a box, someone only needs a couple of them and then other Read More
ソフトウェア開発に進歩がない理由 - 酔狂人の異説(新館)
「ITプロジェクトの実態とは！」というエントリで取り上げられていたソフトウェア開発を皮肉った絵をきっかけに、ソフトウェア開発では30年以上も前の本が通用するという話題になっている。 http://www.dashiblog.com/blogs/000140.php http://blogs.itmedia.co.jp/kyoko/2006/10/post_54f4.html http://blogs.itmedia.co.jp/kurikiyo/2006/10/post_aa72.html http://blogs.itmedia.co.jp/himi/2006/10/post_fa30.html 実際、「十年一日のごとく進歩なし」と書いたように、ソフトウェア開発には進歩がないかのように見える。それには以下のような理由がある。 人の心は読めない ソフトウェア開発に関わる人々が学習しようとし
少人数開発と「能力プール」 - 設計者の発言
■少人数プロジェクトが儲かる理由 開発案件の最終利益率とプロジェクトメンバー数には一定の相関がある。開発に関わったメンバーの数が少ないほど、一般に利益率は高い。実際に数字で調べてみたわけではないが、筆者の過去の経験からも確信できるし、そのように思い当たる人も多いだろう。 その理由は単純である。メンバーが多いほど、メンバー間の情報伝達のためのコスト（情報コスト）が飛躍的に増えるためだ。指示やいわゆるホウレンソウのための初期コストだけでなく、訂正や伝達ミスにともなうさまざまな後追いコストが、人数の多いプロジェクトほど大きくなる。メンバーが２人のときに情報コストが１だとすれば、（１人のときなら０）、人数に従って次のようにコストは増えてゆく。 ２人 １ ３人 ３ ４人 ６ ５人 １０ ： ： ｎ人 n(n-1)/2 たとえこの事実が理解されていたとしても、これらのコストを考慮して工数積み上
Ruby on Railsのチームから学ぶ仕事術
Ruby on Rails自体についての解説は、「WebプログラマはRailsに乗るべきか？」や、「Rubyでアジャイルプロトタイピング」にもありますので、そちらもぜひご覧ください。本記事は2006年に執筆されたものです。RubyやRuby on Rails全般の最新情報は＠IT Coding Edgeフォーラムをご参照ください。 素早く開発が行えるRuby on Railsに驚くとともに、Railsのプロジェクトの素早さの根源はどこにあるのか不思議に思った人も多いことでしょう。 Ruby on Railsの開発には、37singals社のDavid Heinemeier Hansson氏を中心とする11名で構成されたチームがかかわっています。 Core team behind Ruby on Rails Ruby on RailsによるWebアプリケーション構築風景を撮影したいくつかのス
デスマーチについて考える前にデスマーチの経験を書く - ブログは死なず、ただ放置されるのみ。
その昔、とあるプロジェクトがものすごいことになっていて、猛烈な勢いでスケジュールが遅れているのに、仕様がまったく決まっておらず「とりあえず」作ったモノを現地にブチこんで、そのあと燃え上がるであろう事態を収めよという命のもと、テスタとして放り込まれたことがある。 まずお客さんがいいかげんだった。もともと現行システムがあるので「仕様は現行と同じでいい」と言いながら、思いつきで「新しいシステムだからこんな機能も欲しい」という、失敗するならそれ！ ということを頻繁に行った。 受けたSEもいいかげんだった。お客さんが「このボタンを押すと計算結果が出る」というと、仕様書には「ボタン押下により計算結果が出力される」としか書かなかった。その計算はどのデータに基づいてどのような式で行われるのかは書かれなかった。もしそれをお客さんが（幸運にも！）教えてくれても、それが議事録に書かれることはなかった。 受けたプ
ksh Days - デスマーチについて考える（デスマーチ経験のエピローグ）
このエントリは デスマーチについて考える前にデスマーチの経験を書く の続きです。(2007/2/16追記) 私はテスタとして、必ず バグの修正を「お願いします」と言う。 バグ修正確認時は、必ず直してないところも最低１箇所は触ってみる。（でよく落ちる） バグ修正が確認できたら、できるかぎり早く「確認できました。ありがとうございました」と言う。 を実践してゆきました。 ある日、一人のプログラマさんから相談を受けました 「今度の機能なんですが、納期が近いから単体テストせずにkshさんにテスト依頼しろってSEさんから言われたんですが、そんなことしたくないんです」 以下、全文はこちら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
