old_3流プログラマのメモ書き3ryupg.hatenablog.com に移転中。過去記事重複しています。 元 開発職→現 情シスで何でも屋の三流プログラマのコーディング、サーバ管理、PC生活関係のメモ書き。 このメモが忘れっぽい自分とググってきた技術者の役に立ってくれれば幸いです。 by Jehoshaphat
震災後もIT業界の「なぜなぜ」需要は減らず
「なぜ」を何度も繰り返し、問題の再発防止策を導き出す「なぜなぜ分析」は、簡単なように見えて、実は非常に奥が深い。実際にやってみると、案外難しいことが分かる。 トヨタ自動車で語り継がれてきた「なぜなぜ5回」という言葉が今では世間に広く知られたこともあってか、なぜなぜ分析とは「なぜ」を5回繰り返す分析手法であり、5回繰り返すと問題の解決策にたどり着けると考えている人は少なからずいるように思われる。 だが日経情報ストラテジーの誌面で「なぜなぜ分析のここが落とし穴＜実践編＞」を連載しているマネジメント・ダイナミクス社長の小倉仁志氏は、「なぜの回数は扱う事象ごとに変わってくるので、回数そのものに意味は無い。私は様々な業界でなぜなぜ分析を実施してきたが、業種によってもなぜの回数は随分違ってくることを体験的に理解している」と話す。 そこで分析に入る前にまず、「なぜは5回繰り返すものだ」という強い先入観を
正規表現確認ツール RegEx Cafe を作った - 9mの日記
RegEx Cafe - JavaScript Regular Expression Tester http://kkosuge.github.com/regex-cafe/ CoffeeScriptで書いたのでCafeです。 サクッと正規表現の確認をしたいとき Rubular が便利で使う事が多かったんだけど、落ちてる事が多かった。サイト自体が落ちてなくても、テスト結果の表示がベラボーに遅い事があったりする。入力するたびAjaxで結果取りに行ってるから遅くなるのは仕方ない気するんだけど、簡単な確認くらいならJavaScriptでいいじゃんと思ったので再開発しました次第です。Githubページにホスティングしてもらってるので落ちる事ほとんどないだろうし、通信しないので速いです。 正規表現テストツールの既出感やばいけど、その中でもRegEx Cafeはだいぶ使い易くて良いと思う。 Cof
開発現場で学べること（10） プロジェクトが失敗する不吉な匂いとは
エンジニアは日々現場で学ぶ 開発現場で学べること 最終回（第10回） プロジェクトが失敗する不吉な匂いとは クロノス 山野寛 2004/11/2 エンジニアにとって最も大切なことの1つが、開発現場での経験だ。それがエンジニアに多くの知識と勘をもたらす。そんな開発現場で若きエンジニアが失敗し、そこで何を学んでいくか。それを毎回紹介したい。 ■プロジェクトが終了へ 1年以上続いたこのプロジェクト（「第1回 忙しいのはユーザーだ」を参照）も、ようやくカットオーバーを迎えることができた。今回の開発では、何度となく苦難やトラブルがあったが、いま考えるとすべてがよい経験になったように思う。そしてこの連載も今回が最終回である。いままでこの連載を読んでいただいた読者の中には、われわれのプロジェクトが最終的にどのような終わりを迎えるのかと興味をお持ちの方もいらっしゃるのではないだろうか。であれば安心していた
特異なバグ - Wikipedia
特異なバグ (英: unusual software bugs) とは、ソフトウェアバグの中でも特に修正が難しいものを言う。いくつかの種類があるが、直感的に理解しがたいような理論を発表した科学者に由来して名前が付いているものが多い。 ハイゼンバグ (Heisenbugs)[編集] ハイゼンバグは、それを調査しようとすると変貌したり消えたりするバグである。 ハイゼンバグの例： リリース版では発生するがデバッグ版（-DDEBUGコンパイルオプション等）では発生しない。 普通に実行すれば発生するがデバッガなどの環境では発生しない。 ユーザーの環境では発生するが開発者の環境では発生しない。 結合テストでは発生するが同じチェックをしているはずの単体テストでは発生しない。 何が起きているのか調べようと出力命令を入れると（いわゆる「printfデバッグ」）発生しなくなる。 競合状態によって発生している。
優れたプログラマになる秘訣は「我慢して他人のコードを読む」 - DailyJS | エンタープライズ | マイコミジャーナル
DailyJS - A JavaScript blog. Google CodeやGitHubをはじめさまざまなプロジェクトホスティングサービスが存在する現在では、オープンソースプロジェクトはとても簡単にはじめられる。ただし、そういったプロジェクトのすべてが優れた結果を残せるわけではない。大半のプロジェクトは終わらせることもできず、ただ誰にも触られることのない存在になっていく。 プログラマであれば誰しもより優れたプログラマになりたいと考えるだろう。WebにはプログラミングテクニックやTIPS、デザインパターンやアンチパターンなど、さまざまなプログラミングに関するノウハウがあり、多くのプログラマがそうしたノウハウを活用している。しかしながら、いくら努力してもいまいち自分のスキルの上達を感じられない方も少なくないだろう。 以前からよく言われていることだが、Alex Kessinger氏が7月2
「遅れているプロジェクトに追加人員を投入するとさらに遅れる」法則を逆向きに適用 - 人生を書き換える者すらいた。
久々の更新です。 相変わらず忙しいですが、最近の仕事の大きなポイントは上海と香港に良いビジネスパートナーが見つかったことです。いつまでも日本だけで活動してても明るい展望は描けないのでチャンスを伺ってましたが、来月ぐらいからこちらの新プロジェクトに本腰を入れることになります。日本が総体的にはだんだんダメになっていく、というのは抗し難い流れだけれども、震災と菅政権がそれをグッと加速させたと思う。 今日書くのは、先月の「なぜ優秀なプログラマは人を雇わないか」に関連して、いかにして少人数の非請負型プロジェクトの成功確率を上げるか、という話。前から考えていたことを、新プロジェクト開始にあたって改めて整理してみた。 ここでいう成功、というのは、きっちり黒字を出す、ということである。 例題として、平均的なプログラマ10人のチームで10ヶ月かかるプロジェクトがあるとしよう。100人月だから、ざっと１人月5
ゲームを作ってるときに心がけてること - GAME NEVER SLEEPS
今日はプレイテストがあった。開発中のゲームを、ある程度傾向の定まったグループに遊んでもらって、マジックミラーとかカメラごしにどんなところで詰まるのかみたり、あらかじめ用意した質問に答えてもらったり、ゲームの良かったところ悪かったところを討論してもらったりするイベントだ。 まあ、数週間おきにやってるもんだから、ある程度評価が予想できるし、いつもつい気が重くなってしまう。なぜかというと、けっこう厳しいことを言われるから。 特に若いグループは批判がキツくて、「PS2並」とか、「つまらない○○（大作タイトル）」とか、「ダウンロード用ならいいんじゃん」とか、「え、これ売るの？マジで？」とか、おしっこ漏れそうな罵詈雑言を毎回聞かされる。 だが、今回は違う。僕は周りに今回は大丈夫って宣言してた。ゲームの内容に対するチュートリアルが入り、ストーリーが語られるムービーが入り、適切な音楽が流れ、要するに最終的
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
EA流のPMのタスク管理の仕方