コアテクの路地: 作業ログの取り方
このブログをご覧のみなさんは、おそらく何らかの形で開発作業、あるいは設定作業の経験をお持ちだと思います。みなさんは、日々の作業の記録をどのように取られているでしょうか?もし、作業ログを取る習慣がない、あるいは忙しすぎて作業ログをとることに気が回っていないのであれば、作業ログを確実に取る習慣をつけることをお奨めします。この習慣は、きっとあなたの作業の信頼性を上げ、作業効率向上に貢献するはずです。 ●作業ログがなぜ必要か まず最初に、なぜ正確な作業ログをとる必要があるのでしょうか? その答えは簡単です。再現性を確保するためです。自分が不具合報告を受ける立場で考えてみてください。もし、部下やユーザから「動きません」や「バグです」という報告を受けた場合、すぐに問題があると判断するでしょうか? ほとんどの人は、まず報告されている状況を正確に理解したうえで判断したいと考えるのではないでしょうか? ●作
ユメのチカラ: カジュアルなコミュニケーション
昨日はTLF (The Linux Foundation)のシンポジウムだったのだけど、仕事にはまっていて、キャンセルしてしまった（残念）。そしたら@itoh_bmarkからTwitterで体育館の裏までちょっと来いみたいな感じで呼びだされ、気がつくとTLFの懇親会会場にいた。セミナー本体にはいかないで、懇親会だけに居るというのも、どーよという感じがしなくもないが、重要な話は懇親会でされるという「宴会第二の法則」のとおり、その日も非常に示唆に富むお話が満載であった。 来年のLinux Kernel Summitをカーネル読書会がハイジャックするという件は、各所から非公式に打診されていて、がんばります。はい。 懇親会で、TLFのスポンサー企業の皆様とお話していて、よしおかさんたまにはブログ書いてくださいよとお願いされる。あれ、「はてな」の日記書いてますよ、と言うと、会社からは「はてな」ブロッ
ユメのチカラ: セキュリティ＆プログラミングキャンプ2008
ユメのチカラ インターネットの時代になって、地球規模の知恵の集積が 可能になった。ソフトウェア開発においてもオープンソースソフトウェアのバザール的開発が注目されている。いまおきているその現実を現場の視点から記していきたい。 吉岡 弘隆 - よしおか ひろたか 日本OSS推進フォーラム ステアリングコミッティ委員 OSDL Board of Directorsを歴任 カーネル読書会主宰 2000年6月、ミラクル・リナックスの創業に参加。 95年～98年、米国OracleにてOracle RDBMSの開発をおこなっていた。 98年にNetscapeのソースコード公開(Mozilla)に衝撃をうけ、オープンソースの世界に飛びこみ、ついには会社も立ち上げてしまう。 2008年6月取締役CTOを退任し一プログラマとなった。
ユメのチカラ: 取締役退任。生涯一プログラマ宣言。
6月30日臨時株主総会において、ミラクル・リナックス株式会社の新取締役として、児玉崇、伊東達雄を選任し、それに続く、取締役会議により、新しい代表取締役として児玉崇を選任した。佐藤武前代表取締役社長は、取締役会長へ、わたしは取締役を退任した。 ここにご報告する。 さて、ここからが本題(？)である。取締役を退任したからといってミラクル・リナックスを辞めるわけではない。今後は経営者という責任ある立場を退き一技術者としてミラクル・リナックスに貢献していく。 2000年6月にミラクル・リナックスを創業以来8年にわたって取締役CTOとしてミラクル・リナックスとともに歩んできたが、取締役というよりも、技術屋としてミラクル・リナックスのV1.0の開発、OSDL (Open Source Development Lab -- The Linux FOundationの前身)への参画、そしてAsianuxプロ
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
アジアのペンギン: VMware上で動作するLinuxの時刻が遅れる
社内向けサービスのテストサーバーは、VMwareServerを利用するようにしています。良いですよね、VMware Server。これほどのソフトウェアが無料で手に入る時代になるとは、ほんの数年前でも考えもしませんでした。 さて、そのVMware Server上でMIRACLE LINUX V4.0を動作させると、ものすごい勢いで時刻が遅れます。そのままで1週間も放置すると、1日程度の遅れは当たり前といった状態です。いくらテスト用サーバーとはいえ、時刻が遅れては使いものにならないため、解決方法を調査しました。 結論としては... Linux kernel 2.6では、時刻はタイマー割り込みをカウントすることで管理されており、その割り込みは1秒間に1000回行われています。仮想化されたバーチャルマシンでは、この速度の割り込みを処理することができず、結果として時刻が送れてしまうそうです。さらに
みたのブログ: Ext3 ファイルシステムで削除したファイルを復元について
うっかりファイルを消してしまったりすることは、よくあると思います。 いろいろ事情があって、ext3 ファイルシステムで削除したファイルの復元について、半日ぐらい調べていました。 恥ずかしながら ext2 の場合も同じだろうと ext2 の場合の復元方法を一生懸命テストしたり、古い文書やメーリングリストの議論に惑わされたりしながら、やっと Linux ext3 FAQ のなかの ext3 の開発者のひとりの引用を読んで調査が終了しました。Q: How can I recover (undelete) deleted files from my ext3 partition?つまり ext2 の場合は、ファイルを削除するとき inode を "deleted" としるしをつけるだけなので、 debugfs コマンドの lsdel で削除された inode の一覧を得ることができるし、その削除さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
