あれは私がまだ大学助手をしていたころだから3年ほど前のことだと思う。 私の勤めていた大学(情報系)では「プログラミング研究会」みたいなサークル活動が行われていて プログラミングの講義を受け持っていた私はそのサークルにちょくちょく顔を見せるようになっていた。 そこにはとびっきりかわいい女子学生が一人いたのだけれど、その子はゲームが大好きで 「自分でもゲームが作りたい」と一念発起してゲームコンテストに作品を出品することになった。 しかし、彼女はプログラミングの講義(Java)を1年くらい受けているものの、 本格的なモノを作った経験がなく、ひとりでは行き詰まりをみせているようだった。 彼女はひとりでいることが多く、パソコンに向かって黙々とプログラムを書いているのをよく見かけた。 それを気にかけていた私はたまに彼女をランチに誘うようになり、彼女の方もしだいに私に打ち解けてきた。 私たちはだんだんと

最近忙しくて……というか、本音をいうと「エンジニアライフで投稿していくことに意味があるのか」と真剣に考えましたが、わたしで伝えられることがあれば伝えるべきだと思い再開させていただくことにしました。 さて前回、業務分析についてエンジニアの皆様が興味をもたれているのかいないのかをうかがいましたが、独断でそこそこニーズはあると判断させていただきましたので、具体的な話を進めていきたいと思います。 要求の源泉。それは「そのシステムの機能をナゼ実装する必要があるのか」を示した理由です。 わたしが新人に近いころ、要求の源泉を把握できるチャンスはありませんでした。「仕様書にかかれたモノを作りなさい」と、ドキュメントを渡されただけです（逆にそれ以上のアクションができなかったわたしのスキルがシレテいますが）。 そうなると普通の感覚では仕様書にかかれた以上のモノはできないわけですが、たぶん日本の文化なのでしょう

「生産効率を上げろ！生産効率がすべてだ！」と叫んでやまない弊社と弊社の極悪評価制度（生産効率のみに特化した評価基準）を打破すべく、「生産性も大事だけど、それと同じくらい品質も大事でしょ？」という思いを明日、経営者レベルの幹部の方々にぶつけてこようと思います。変わるかどうかはわかりませんけど。言わないより言ったほうがいいじゃないですか。 なんで「生産効率」が第一で「品質」が二の次なのか - とりあえずなんですけどね ↓ 結果報告 僕「プログラマの評価が"生産効率"だけなのはおかしいです。"品質"も評価軸に入れるべきでは」 経営幹部Ａ「今、高品質な部品を別の部署で作ってるから、それを使えばおｋ」 経営幹部Ｂ「高収益を目指すためには生産性の向上は絶対不可欠」 経営幹部Ｃ「（うなずいてる）」 経営幹部Ｄ「（うなずいてる）」 経営幹部Ａ「その高品質な部品を顧客に提供すること、そしてその上で使われるシ

ディレクトリの中にある大量のファイルを高速に読み込む方法が知りたかったので、実験してみた。想定しているシチュエーションは、一つ一つのファイルは数KB程度だが数が多い、という場合である。適当な順番でアクセスすると、ランダムアクセスになってしまいとても時間がかかる。個々のファイルを読み込む順番はどうでも良く、すべてのファイルを処理することさえできればいいので、原理的にはシーケンシャルアクセスで処理できてしかるべきである。 まず、ファイルシステムについて。HDDやSSDなどのハードウェアにアクセスする際には、ファイル名などという概念はもちろん存在しない。ファイル名と実際のディスク上の対応を管理するのがファイルシステムの主な役割である。ファイルシステムは、ファイル名からそのファイルに対応するブロック番号（メモリアドレスみたいなもんだな）を調べて、そのブロック番号を指定してHDDやSSDにアクセスす

良品計画は独自の開発手法を採用することで、システム開発の短期化とコスト削減を図った。2006年12月に再構築したMD（マーチャンダイジング）システムを皮切りに、08年12月までに約130のアプリケーションを社内で開発。一方で、IT 投資の売上高比率は04年の1.8％から0.9％に半減させた。「7割主義」と「スピード対応」を方針に掲げ、利用部門の要望に最速1日、遅くとも1～2週間で対応する。開発手法の独創性と、経営に資するシステム部門の姿が評価された。 「無印良品」ブランドの小売店を展開する良品計画は、1週間に1本という猛スピードで新しいアプリケーションを開発したり、機能を強化したりしている。「思い立ったら即実行。合格最低ラインの7割主義で素早くシステムを開発し、検証と改善を繰り返す」。IT戦略を統括する小森孝取締役 情報システム担当部長兼流通推進担当管掌は強調する。 同社は独自の開発方法論

私は基本的に、C++でソース書くときはやたらめったらconst付けます。 なぜならHaskellが好きだからです(ぇ じゃなくて、状態の変更によるバグを減らすためです。 しかし、他人が書いたソースを見てると、オブジェクトのconst操作を考えて設計されてないことが けっこうあり、Is〜とかGet〜といった名前の関数の中でメンバの状態を変更してたりします。 これはとくに、JavaやC#のようなconstメンバ関数がない言語からC++に移植するようなときに 起こりやすいのですが、C++でもconstメンバ関数の存在を知ってか知らずかconstが付いてないことが多々あります。 書籍でいうと、『Game Programming Gems』では明らかにconst操作なメンバ関数にconst付いてないですね。 C++で大きなプログラムを組む際は、元となるコード(移植元やライブラリ)がオブジェクトのco

GNUプロジェクトの配布アーカイブなどを中心に、LZMAを用いた圧縮形式を目にする機会が増えてきた。組み込み用途などへの活用も期待されるこの圧縮形式を紹介しよう。 2001年に開発された可逆圧縮アルゴリズム「LZMA」（Lempel-Ziv-Markov chain-Algorithm）が静かな注目を集めている。LZMAといえば、高い圧縮率を備え、Windowsアーカイバ「7-Zip」に採用されていることでも知られる。 ZIPやLHAなど、ファイルのアーカイブと圧縮が統合されているWindows由来のプログラムとは異なり、UNIXやLinuxでは伝統的にアーカイブと圧縮が個々のコマンドとして用意されており、それらを組み合わせて利用することになる。現在では、アーカイブがtar、圧縮にはGNU zip（.gz）やbzip2（.bz2）が併用されることが多い。 .gzや.bz2をしのぐ圧縮率が特

id:t-wada と話してた時に出てきた「プログラマの麻疹」 プログラマはみんなどうせかかるんだから早めにかかっておいた方が良い そしてかかっておくと治った後にはさらに良いコードが書けるようになるので 恐れずにかかりましょう 名前 症状 僕の状態 OO 厨 多分、現在一番キャリアが多い。一時期 AOP 厨になってしまった人も含むことがある。Smalltalk を神格化し始める かかり中 function 厨 最近増えてきた。マルチコア時代に最適というわかりやすい感染源ができたことも要因の一つ。LISP が世界を作っていると信じる 挫折中 三項演算子厨 どんどんネストした三項演算子を書いてしまう。気がつくと自分でもよくわからなくなってることもある 治療済み テスト厨 テストのためだけにコードを書いてしまう。プロダクトコードのきれいさよりもテストのしやすさを求めてしまう 治療中 lambda

一番右端の立っているビット位置(RightMostBit)を求めるコードで速いのないかなーと探していたら、ものっっっすごいコードに出会ってしまったのでご紹介。2ch のビット演算スレで 32bit 値のコードに出会って衝撃を受けて、その後 64bit 値版のヒントを見つけたのでコードを書いてみました。 この問題は ハッカーのたのしみ―本物のプログラマはいかにして問題を解くか (Google book search で原著 Hacker's delight が読めたのでそれで済ませた) で number of trailing zeros (ntz) として紹介されています。bit で考えたときに右側に 0 がいくつあるかを数えるもの。1 だと 0、2 だと 1、0x80 なら 7、12 なら 2 といったぐあい。0 のときに表題どおりの問題として考えるといくつを返すの？ってことになるので、

チケット駆動開発を実践してプロジェクトが大きく改善された事実を話して、一番気になる質問がある。 「チケット駆動開発を運用したプロジェクトはツールで改善されたのですか？　それともプロセスで改善したのですか？」 質問の意図は、チケット駆動開発の話を聞くとBTSやらバージョン管理やらツールの使い方の話が多い。 そのプロセス改善はツールに依存しすぎではないか？ ツール無しの開発プロセスにできるのか？ チケット駆動開発は、BTSがなければ運用できないのか？ と。 この質問は今の僕が抱える問題点の一つを持っている。 それについては後でまとめる。 【1】チケット駆動開発の定義の一つは、BTSチケットをXPのタスクカードのように使うことだ。 すなわち、障害だけでなく要望なども取り扱う。 この方法は、Issue Trackingとも呼ばれている。 つまり、障害修正のワークフローをSW開発における全ての作業の

八朔さんによるチケット駆動開発の運用例をメモ。 【元ネタ】 チケット駆動開発 - Live a meaningful Life プロジェクトの作業をWBSの観点で、要件→成果物→作業のツリー構造へ分解している。 プロマネらしく、チケットの構造が上手だと思う。 このやり方ならば、ソース←【チケット(作業)】→【チケット(要件)】の観点で追跡可能だ。 【チケット(要件)】で集計すれば、顧客向けの進捗報告として、進捗率や工数を集計できる。 アジャイル開発の観点では、要件はストーリーカード、成果物や作業はタスクカードに割り当てられると思う。 顧客の観点でシステムの価値を表すのがストーリーカードであり、チケット駆動開発における成果物は、開発者の観点で捕らえるべきだろうと思う。 そうでなければ、開発者が作業するレベルにならないからだ。 後で、八朔さんに聞いたら、要件のチケットから実際のテストケースへ落

もう1つの、DBのかたち、分散Key-Valueストアとは：分散Key-Valueストアの本命「Bigtable」（1）（1/3 ページ） RDBとは別の、クラウド時代のデータベースとして注目を浴びている「分散Key-Valueストア」。その本命ともいえる、Googleの数々のサービスの基盤技術「Bigtable」について徹底解説 クラウド時代のデータベース「分散Key-Valueストア」 グーグルがインターネットの世界をここまで席けんできた最大の理由は何でしょうか。実は、それは同社の優れた検索技術ではありません。グーグルが成し遂げた最も大きなブレークスルーの1つは、同社が生み出した巨大な分散データストア、「Bigtable」にあります。 Bigtableは、Google検索をはじめ、YouTubeやGoogle Map、Google Earth、Google Analytics、Goog

私、餡子のためなら逆立ちだってしますよ。 こじらせている。 食べたいと思ったら食べたいのである。 ここが北カリフォルニアの片田舎であろうと、私があんみつが食べたいと思えば、あんみつは今すぐ作って食べなくてはいけないものになる。食いしん坊の思考は凄まじい。 子供が観ていたアニメで、赤ちゃんが空の…

2007年頃のバグ管理の資料があったのでメモ。 【元ネタ】 [Think IT] 第3回：取材お断り！の裏事情 (2/3) ・現状は、半分以上が紙もしくはExcel ・今後は、Bugzilla、Visual Studio 2005 Team Foundation ServerなどのBTSを使いたい人が多い 以前、バグをExcelで管理していた時、バグ管理IDは特別なExcelシートで採番するやり方で運用されていた。 そこでユニークなバグ管理IDを採番した後、その障害管理票を紙に印刷して運用していた。 その紙には、判子の欄があった。 判子の欄には、開発者、テスト担当者、プロジェクトリーダーの3つの欄があった。 それは、他の人の作業した結果を認めたら、各人が判子を押していく運用フローになっていた。 つまり、ワークフローと言う概念が当時の開発者だった僕の頭にはなかったけれど、たとえアナログであろ

はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

ゲームの作り方とアルゴリズムをジャンル別にまとめてみました。ゲーム制作や、プログラミングの勉強用にご活用ください。言語別ゲームプログラミング制作講座一覧もあわせてお読みください。 リンク切れがおきていたものは、URLを表示しておくので、Internet Archiveなどでキャッシュを表示させてみてください。 RPG ゲームの乱数解析 乱数を利用した敵出現アルゴリズムの解説 各種ゲームプログラム解析 FF、ドラクエ、ロマサガのプログラムの解析。乱数の計算など ダメージ計算あれこれ（http://ysfactory.nobody.jp/ys/prg/calculation_public.html） ダメージの計算式 エンカウントについて考えてみる エンカウント（マップでの敵との遭遇）の処理方法いろいろ RPGの作り方 - ゲームヘル2000 RPGのアルゴリズム ドルアーガの塔 乱数の工夫の