タグ

2006年1月8日のブックマーク (30件)

  • ストーリーを教えてもらうスレッド 暫定まとめサイト

    人気再燃!ポケモンGOをより楽しむウェアラブルデバイス4選 街中で『ポケモンGO』を遊ぶにしても、スマートフォンを出したりしまったりしながら歩くのはなかなか難し…

    ストーリーを教えてもらうスレッド 暫定まとめサイト
    Wacky
    Wacky 2006/01/08
    このサイトは『ストーリーを教えてもらうスレ』のログをストーリー別に分割して置いております。
  • 2ちゃんねる 一般書籍@2ch掲示板 お勧め自己啓発書 のまとめ

    このページは2ちゃんねる 一般書籍@2ch掲示板のお勧め自己啓発書 のまとめぺーじです。 最初は書籍ごとに紹介しようかと思いましたが、書籍名のみのレスや「面白い」とか「おすすめ」としか書いてないレスは一行のみ紹介の書籍にまとめました。 順不同です デールカーネギー 道は開ける 人を動かす 7つの習慣 関連 ウエイン・W・ダイアー オグ・マンディーノ 中村天風 飯田史彦 リチャード・カールソン「楽天主義セラピー」 ジョセフマーフィー 神経言語プログラミング 仏教・内観法 多信一 杉崎仁志 藤憲幸 津留晃一 斎藤一人さん 関連 D・ウェイトリー著 「成功の心理学」 なぜこの人ばかり出世するのか エンリケ・バリオスの「アミ」シリーズ 「人生二度なし[悔いなく生きるために]」 森 信三 一行のみ紹介の書籍 自己啓発全般の話題 その他 ナポレオンヒル・きこ書房関連 三笠書房関連 サンクチュア

    Wacky
    Wacky 2006/01/08
    このページは2ちゃんねる 一般書籍@2ch掲示板のお勧め自己啓発書 のまとめぺーじです。
  • javaworld.jp

    This domain may be for sale!

    Wacky
    Wacky 2006/01/08
    本稿では、オープンソースの負荷テスト・ツール「OpenSTA」を用いることにする。
  • IronPython 1.0ベータ1でアセンブリのロード方法に変更あり

    In this story, he loses his boyish innocence and lives fully, even to excess. 既に色々なところで紹介されていますが、IronPythonのベータが出ています。めでたい。 それに関連して、以前エントリにしたCLRのアセンブリをimportするのにsys.LoadAssenblyByName()を使わないといけないという件に変更がありました。 詳しくはIronPython MLのこちらのポストをご覧ください(参照)。 要するに、sys.LoadAssenblyByName()の代わりにclr.AddReferenceByPartialName()を使えということのようです。sys.LoadAssenblyByName()は残されているけれど、あくまで下位互換性のためということです。これからはじめる人はこっちで覚

    Wacky
    Wacky 2006/01/08
    要するに、sys.LoadAssenblyByName()の代わりにclr.AddReferenceByPartialName()を使えということのようです。
  • TopPage

    Wacky
    Wacky 2006/01/08
    クロスプラットフォームライブラリであるwxWidgets(旧名:wxWindows)を使った MacOS Xでの開発手順をまとめたものです。
  • ups

    Wacky
    Wacky 2006/01/08
    UPSの波形計測結果
  • 半透明pngを表示する 〜CSSテクニック〜

    Wacky
    Wacky 2006/01/08
    IE6ではそのままでは半透明のpng画像を表示することは出来ません。今回のテクニックは、その壁を打ち破るものです。
  • プロジェクト・マネジメントの品質 | タイム・コンサルタントの日誌から

    ISO9000の品質システムは、大抵のいっぱしを気取る企業に導入され、運用されている。そして、疎まれてもいる。この標準規格自体は21世紀に入ってさらに思想を深化させ、今では品質マネジメントシステム(QMS)と自らを呼ぶようになった。しかし、率直に言って、日企業でQMSを嬉々として運用している所には、私はほとんどお目にかかったことがない。皆が従っているが、内心は無用のものだ、と感じている。保険か税金のようなものだ、と。 私はいまだに、『品質』というものが良く分からない。私自身が製造業の品質管理部門で働いた経験がないせいだろう。工場建設のプロジェクトで品質検査をしたり、システム開発の統合テストを進めるやり方についてだったら、少しは分かっているつもりだ。構成図通りに製作され、指定の材料がつかわれ、仕様書通りに機能する。そういう検査が保証する品質は、『後ろ向き品質』と呼ばれる。軍隊の行進のように

    プロジェクト・マネジメントの品質 | タイム・コンサルタントの日誌から
    Wacky
    Wacky 2006/01/08
    生産管理の世界では、よく「品質はプロセスで作りこめ」と言われる
  • 生産技術というお仕事 | タイム・コンサルタントの日誌から

    製造業にとって、製品開発のスピードは競争力のキーになる。製品開発は一般に、核となる要素技術の発明、ないし市場における新しい動向がきっかけになって始められる。むろん、業種によっては、毎年定常的に多数の新製品を出し続けるところも少なくない。そうしたケースでは、製品開発までの期間がきちんと「読める」状態にまで、管理レベルを上げていく必要がある。 プロジェクト・スケジューリングの技術に関わっているおかげで、最近は製品開発プロジェクト相談に乗るケースが増えてきた。従来、製品開発とは「固有技術」だけの世界と思われていた。ところが、近年わずかづつではあるが、プロジェクト管理という「管理技術」も必要なのだと認識される企業が増えてきたようだ。 製品開発となると、BOMの話題に触れることも多い。今年のはじめに「BOM/部品表入門」というを上梓したこともあって、いかにスムーズに新製品のBOMを構築できるかが

    生産技術というお仕事 | タイム・コンサルタントの日誌から
    Wacky
    Wacky 2006/01/08
    製造業は、製品を低価格で安定して量産できてナンボの世界である。「いかにつくるか」(How)が大事なのだ。
  • プロジェクト採算管理は重要か | タイム・コンサルタントの日誌から

    はたしてプロジェクトの採算管理は当に重要か、などというと、常識知らずのレッテルを貼られるかもしれない。とくに、受託開発をビジネスとしているシステム・インテグレーター(SIer)ではそうだ。システム開発プロジェクトは一つ間違うと、億の単位で赤字が発生し、他の数十のプロジェクトで稼いだ利益が吹っ飛びかねない。 だからプロジェクトの綿密な採算管理は必須だ。個別のプロジェクトがいかなる採算状況にあるのかを、マネジメントの側がチェックできる仕組みが求められている。いや、それだけでなく、部門単位でも収支の集計を行なって、採算で目標管理するべきだ--こういう理由から、最近、大手のSIerではプロジェクト採算管理システムの構築が活発だ。そもそも、システム開発はお手のものだから、自社ニーズにマッチした仕組みを自社内で作ってしまおう。そう考えられておられる会社もかなりある。 でも、ちょっと待ってほしい。かり

    プロジェクト採算管理は重要か | タイム・コンサルタントの日誌から
    Wacky
    Wacky 2006/01/08
    進捗管理とは、「どれだけ進んだか(工数を費やしたか)」ではなく、「あとどれだけ仕事が残っているのか」で測るべきものだからだ。
  • プロジェクト・ダイナミクスの構造 | タイム・コンサルタントの日誌から

    PMBOK Guideの編纂者たちが、いわゆる「9つのマネジメント領域」を定義したとき、そこにProject Integration Management=プロジェクト統合管理を入れたのは卓見だった。これ以外の8領域、すなわち、コスト管理、時間(スケジュール)管理、スコープ管理、品質管理、人的資源管理、調達管理、リスク管理、コミュニケーション管理、は、それぞれが独立した管理対象範囲を持っている。 (ところで、以前「マネジメントと管理はどこが違うか」にも書いたとおり、私は『管理』という日語が嫌いだ。だから、こうやって8回も9回もくり返して書かされると、ちょっとうんざりしてくる。管理という用語はあまりにも多義性の言葉で、あらゆる物事を曖昧に片づけてくれるので、ひどく便利な魔法の道具になってしまう。私は、仕事の内容を正確に表現したいので、普段はあえて、マネジメント/コントロール/アドミニストレ

    プロジェクト・ダイナミクスの構造 | タイム・コンサルタントの日誌から
    Wacky
    Wacky 2006/01/08
    プロジェクトの採算が悪化する直接原因は、スケジュールにある。元をたどっていくと、コミュニケーションやリスクの問題につきあたる。
  • 納期短縮三か条 | タイム・コンサルタントの日誌から

    私はタイム・コンサルタントである。「時間の悩み」を抱えるクライアントに対して、解決へのアプローチを示すことで、プロフェッショナルとしてのビジネスを成立させている・・・と、自己紹介には書きたい。できれば。 しかしまあ、現実はなかなかそう甘く行かない。タイム・マネジメントの仕組みを提案するだけでは、なかなかビジネスにはならないのだ。生産スケジューリングやプロジェクト・スケジューリングの仕事をしていてつくづく感じるのは、『やっぱりコスト削減が優先』という圧力の強さである。製造業や流通業向けのSCMシステム構築の課題は、物流費の削減が真っ先にくる。納期短縮は、「それもできたらやりたい」であって、部分目標でしかない。だから私は、パート・タイム・コンサルタントという存在だ。 コスト競争はすでに行き着くところまで行ってしまった。あとは非価格競争力の問題で、性能だとか品質だとかも大事だろうが、納期で勝負す

    納期短縮三か条 | タイム・コンサルタントの日誌から
    Wacky
    Wacky 2006/01/08
    「隘路に集中すべし」「進捗を皆に見せるべし」「時間はお金で買うものと思うべし」
  • 革新的生産スケジューリング入門

    生産管理・スケジューリング・APS・SCMなどの解説と用語集。批評、IT入門等。このページはスタイルシートを使用しています。 スタイルシートを利用できないブラウザのみ,この文が表示されます。どうぞあしからず。 CONTENTS このサイトの目的 (2001/11/12更新) 生産計画とスケジューリングの用語集 (2008/09/21更新) 生産計画 ワンポイント講義 (2008/07/09更新) プロジェクトマネジメント ワンポイント講義 (2008/09/12 更新) BOM構築調査法 (2006/10/25) スケジューリングと自由度の概念 (2003/2/28更新) 製造業の業務範囲とソリューションMAP (2008/03/31更新) タイム・コンサルタントの日誌から (2008/10/07更新) 考えるヒント (2008/06/11 更新) 対話風

    Wacky
    Wacky 2006/01/08
    革新をせまられつつある製造業における生産のあり方を、情報の視点から理解するためのノート
  • WBSのつくり方 | タイム・コンサルタントの日誌から

    WBSは、「仕事のBOM」である。私は最近、そう説明することにしている。プロジェクトという、始まりと終わりがある仕事の全体像を表現するには、それを構成している仕事の部分品ひとつひとつに分解して、どういう構成になっているかを示すのが一番分かりやすい。それがWBSである、と。 WBSはWork Breakdown Structureの略である。プロジェクト・マネジメントで使う用語だ。このWorkという英語はいささか多義語で、仕事(人の作業)のこともさすが、加工対象物(モノ)のことをも意味する。そのせいかどうかしらないが、WBSの作り方には従来、二通りの考えがあった。 まず、WBSは人の作業の構成表である、とする考え方がある。システム開発プロジェクトという仕事は、「要求分析」「設計」「実装」「テスト」「移行作業」などとブレークダウンしていく。「設計」はさらに「基設計」「詳細設計」「実装設計」に

    WBSのつくり方 | タイム・コンサルタントの日誌から
    Wacky
    Wacky 2006/01/08
    成果物単位にWBSをつくると、成果物全体に共通の作業が、抜け落ちがちになる弱点がある
  • 設計の価値 | タイム・コンサルタントの日誌から

    最初に、ブルネレスキのことからはじめよう。日ではほとんど名前を知られていないが、初期のイタリア・ルネッサンスを代表する人物の一人だ。フィレンツェに旅行に行く人が必ず目にする、花の聖マリア大聖堂の半球形ドームは、彼が作った。 「彼が作った」という言葉を、私は意図して使っている。彼は設計しただけでなく、建設工事の責任者でもあったのだ。つまり今風に言えばプロジェクト・マネージャである。彼は石の積み方にも工夫をこらしたし、二重ドームの間に作業者が立って歩けるスペースを確保する設計にした。施工しやすい設計をしたわけだ。職人のストライキにも見事に対処した。 彼が設計者・兼・建設責任者だったことは特筆して良い。日光東照宮の左甚五郎の立場と同じである。設計者が実作も行う。それは近世以前はあたりまえのことであった。たとえばミケランジェロ作の彫刻が、じつは彼のデッサンをもとに弟子が好きに刻んだものだったとし

    設計の価値 | タイム・コンサルタントの日誌から
    Wacky
    Wacky 2006/01/08
    モノにはお金を払うが、設計という知恵にはお金を払わない。いわば「実物経済」である。こうした実物経済主義は、最終的には設計の品質低下をまねくのだ。
  • システム設計に求められる適性 - 設計者の発言

    ◆他の職業との比較が重要 以前、システム設計は専門職であるからには求められる適性があると指摘したが、そこらへんをもう少し具体的にしておきたい。 およそどんな職業向けであっても適性の議論になると、実務者にさえ「そんなスーパーマンってこの業界にいたっけなあ」と皮肉りたくなるような安直な理想像が描かれやすい。とくに論者が職業人として自信に満ち溢れている場合に、そのような議論になるのかもしれない。反対に、自分の職業生活にやけっぱちになっている論者だと「打たれづよさ」だの「何よりも体力」みたいな、わかりやすいが乱暴な議論になりそうだ。 重要なのは「他の職業と比べた場合に、とくにどんな素質が求められるか」、さらにその職業において「劣悪であることが致命的でない素質は何か」を示すことである。たとえば、しばしば耳にする「システム開発者にとってはコミュニケーション能力が重要である」という主張は却下される。なぜ

    システム設計に求められる適性 - 設計者の発言
    Wacky
    Wacky 2006/01/08
    システム設計の仕事において、「これが劣悪ならば致命的」な能力は何か。それは「構成力」だ。
  • ホワイトカラーの仕事をカイゼンするために - 設計者の発言

    ある人が家庭の事情や不慮の事故で突然職場を去ることになったとき、仕事の引継ぎで混乱してしまう職場は少なくない。とくに「そのひとでしかやれない仕事」が多ければ多いほど、職員の退職にともなう影響は大きく、混乱が何ヶ月も尾をひいたりする。そのような状況が生じたとしたら、だいたいは「仕事を誰にも担当できるように定義しておく」という来必要な作業を怠っていた管理者の怠慢が責められるべきだが、部分的には職員自身の利己的な姿勢の結果でもある。 ◆業務が定義されることへの恐れ 職場にコンピュータを導入する過程で、職場で実施されている業務の棚卸が行われる。誰によってどんな業務が、どれくらいの頻度や工数でなされているか――それを整理・分析してシステム化の投資効果の見込みも立つ。 ところが、職員によっては業務を定義されることなど余計なお世話だったりする。そんなことをすれば、自分が給料に見合う働きをしていないこと

    ホワイトカラーの仕事をカイゼンするために - 設計者の発言
    Wacky
    Wacky 2006/01/08
    継続的に業務効率を向上させ続け、それに協力することによって仲間うちでの評価が高まり、また給与レベルも向上するという文化的・制度的な支援が必要だ。
  • レガシーの呪いを解くには勇気が必要だ - 設計者の発言

    大きなレガシーシステムはたいてい「動いているが、なぜそのような作りになっているか誰もわからない」といった状態になっている。下手に変更すればシステムが動かなくなることを担当者は身にしみて知っている。日々の業務が動いていることのほうが重要なので「なるべくシステムを変えない」ことがシステム部門としての至上命令になっていたりする。事業を支援するはずのシステムが、その発展を阻害しているなんて悪い冗談だ。 さすがにこのようなシステムなら、もののわかる経営者であれば危機感を覚える。絶え間なく変化する市場に合わせて新しいサービスを考案して事業に組み込まねばならないからだ。変化を禁じられた事業なんて死んだも同然だ。そこで大きな予算を用意して刷新プロジェクトを立ち上げるのだが、けっきょくもともとの構造をそっくり別のプラットフォームに移し変えただけのようなシステムが出来上がることがじつは少なくない。 理由はいく

    レガシーの呪いを解くには勇気が必要だ - 設計者の発言
    Wacky
    Wacky 2006/01/08
    変化を禁じられた事業なんて死んだも同然だ。
  • 設計者の発言: 詳細設計とコーディングの融合

    「CONCEPTWARE/財務管理」で例示したような「実装独立な基設計」にもとづいて、「実装依存な設計」をまとめる。それが「詳細設計」と呼ばれる工程で、なかなか問題の多い局面だ。その扱いにくさは、この工程が実装技術の未発達さゆえの「来は不要な手順」である点に端を発している。しかし、実装技術の発展にともなって詳細設計の工程はプログラミングに吸収されつつある。その変化はプログラマとアプリケーションエンジニアとの適正な棲み分けをもたらすものでもある。 ◆詳細設計の悩ましさ 経験者ならよくわかると思うが、詳細設計作業のいちばんやっかいな点は、手を抜いても誠実にやっても問題を生じる点だ。まず手を抜くと、プログラマの能力差にしたがったバラバラな品質のプログラムが出来上がる。プログラマからの問い合わせも増えるので、けっきょく手間がとられる。手を抜いてろくなことはない。 では、誰が作ってもそっくりなプ

    設計者の発言: 詳細設計とコーディングの融合
    Wacky
    Wacky 2006/01/08
    こまごました修正が入るたびに詳細設計書とコードとを確実に修正・同期してゆくための手間は、プログラムの本数が多いほど等比級数的に増える
  • 「設計情報の構造」に現れる設計品質 - 設計者の発言

    私を日語に上手は使えます。 こんな文があったら読者はどう感じるだろう。これには「書き手は日語が上手いわけではない」というメタレベルの情報が含まれている。この文が「私は日語が上手に使えます」の意味で書かれたものならば、読み手は混乱する。少なくとも書き手の日語能力が信用されることはないだろう。 同じことがシステム設計に関しても言える。設計情報そのものの構成の巧拙に、設計者自身の設計能力が示されている。どんな業務や業種を対象にしているかに関係なく、設計情報そのものがうまく構造化されていないことが、システム要件に対してうまく設計がなされていないことの間接的な証拠となる。 仕事柄、いろいろな設計書を目にするが、ざっと眺めるだけで設計者の実力がわかってしまうものだ。最初に目を通すのは「目次」だ。章立て・節立てには設計者のシステム観が反映されているし、それらのタイトル表現からは言語的センスが透け

    「設計情報の構造」に現れる設計品質 - 設計者の発言
    Wacky
    Wacky 2006/01/08
    最初に目を通すのは「目次」だ。章立て・節立てには設計者のシステム観が反映されているし、それらのタイトル表現からは言語的センスが透けて見える
  • 業務単位は「疎結合」されている - 設計者の発言

    業務のあり方には「ロジックで制御される性質」と「イベントで駆動される性質」とが混在している。しかしこれらは業務の記述を階層化することで、別個の性質として取り扱える。階層化せずに記述すれば、それらの性質が渾然一体となってわかりにくくなるか、職場の実態を表さないものになってしまう。 ◆ロジック制御とイベントドリブン 朝起きて顔を洗う。それを「眠りにつく」に後続する活動と考えれば、「活動が実施される順序」を表す矢印を用いて次のように表記できる。何も問題はなさそうだ。 眠りにつく → 起きて顔を洗う では、業務システムに含まれる活動として、「受注」と「出荷」を例にして同様のことを考えてみる。「受注してから出荷する」と言って間違いではないので、次のように表記できそうに思える。 受注する → 出荷する しかし、現実にはほとんどの受注・出荷活動はこのような「ロジック」で制御されているわけではない。誰かが

    業務単位は「疎結合」されている - 設計者の発言
    Wacky
    Wacky 2006/01/08
    イベントの勃発を認識できること(つまり「イベントリスナー」になれること)と、その認識にともなって規定の手順を実行できることが、担当者の能力要件となる。
  • わかりやすさと論理性を両立させる(前編) - 設計者の発言

    成果物の「わかりやすさ」と「論理性」を確保することは、システム開発の全工程を通じて重要な課題だ。とくに、上流工程では「論理性」が、下流工程では「わかりやすさ」が意識されなければならない。 プログラミングにおいて「論理性」をことさら重要視する必要はない。それは重要でないということではなくて、成果物が論理的でなければコンパイルエラーになるかアベンドするかで仕事にならないくらいに質的ということだ。プログラムのような機能的要素に限れば、下流工程成果物はほっといても論理的なものにならざるを得ない。それは成果物が基的に「コンピュータ」向けに用意されるものだからだ。 そのためかどうか、下流工程の成果物は「人間が理解しやすいかどうか」がおろそかなものになりがちだ。いまだに「少量のトリッキーなコード」がクールと思われがちだったりするが、それはプログラムに割り当て可能なメモリー領域が小さかった時代のなごり

    わかりやすさと論理性を両立させる(前編) - 設計者の発言
    Wacky
    Wacky 2006/01/08
    上流工程では「論理性」が、下流工程では「わかりやすさ」が意識されなければならない。
  • ユーザがなかなか仕様を決めてくれないって? - 設計者の発言

    「ユーザがなかなか仕様を決めてくれないんです」という悩みをじつによく聞く。検討の過程で明確にされたいくつかの選択肢があって、ユーザに決断力がないゆえに決めきれていないとすれば、確かに困ったものだと思う。しかし「ユーザがどんなシステムにしたいかをなかなか明確に語ってくれない」といったレベルの悩みなのであれば、問題はどちらかといえば設計者の側にある。 ◆デートの過ごし方を決める過程 休日のデートの過ごし方に関して男性から尋ねられて、事細かに意向を説明してくれる女性はどちらかといえば少ない。たいていは「うーん、いい景色を見て、なにか美味しいものを何かべたいな」なんて曖昧な答えが返ってくる。そのときに彼は「イイケシキだのナニカオイシイモノなんて曖昧な言い方をされてもわからない。もっと具体的に説明してくれないか」なんて言うだろうか。 そんなことを言う男がいるとすれば、彼女のいぶかる様子に気づくこと

    ユーザがなかなか仕様を決めてくれないって? - 設計者の発言
    Wacky
    Wacky 2006/01/08
    ユーザが「これです。これが私たちが望んでいるシステムです」と納得するまでやる。その納得感が、設計者がもたらす価値の源泉だ。
  • 要件を要件として深追いしてはいけない - 設計者の発言

    ユーザ要件は海に浮かぶ氷山のようなものだ。言語化可能な部分は海上に出たごく一部で、大部分は水没していて言語化どころか意識にのぼることさえない。このような要素をシステム設計においてどのように扱うかによって、上流工程のスタイルはまったく違ってくる。 ◆スクラッチ案件での要件の位置づけ 前回のエントリーで説明した「スクラッチ案件」において、要件はとくに重要視される。新システムを構想するためのレファレンスとなる現行システムが存在しないか、あっても貧弱すぎてアテにならないからだ。 そのような案件向けであっても、要件の扱い方は2つの流儀に分かれる。ひとつは要件全体を正面から定式化するやり方。もうひとつは言語化が困難であるような要件については深追いせずに搦め手(からめて)を用いるやり方。便宜上、前者を「A方式」、後者を「B方式」と呼んで検討しよう。 ◆要件をじっくりモデル化するA方式 上流工程手法の多く

    要件を要件として深追いしてはいけない - 設計者の発言
    Wacky
    Wacky 2006/01/08
    要件の扱い方は2つの流儀に分かれる。ひとつは要件全体を正面から定式化するやり方。もうひとつは言語化が困難であるような要件については深追いせずに搦め手(からめて)を用いるやり方
  • 各種JSライブラリのグローバル書き換え状況 - IT戦記

    先日、JS O Lait と Prototype.js が両方とも Class オブジェクトを作っていて、一緒に使えないとわかったので。各種ライブラリがどのくらいグローバルな情報をクラックしているかの調査しました。 ↓結果 Prototype.js(1.4.0) window Prototype Class Abstract Try PeriodicalExecuter $ $break $continue Enumerable $A Hash $H $R Ajax Toggle Insertion Field Form $F Position property ObjectRange Object extend inspect bind bindAsEventListener Array from bind bindAsEventListener Array_prototype each

    各種JSライブラリのグローバル書き換え状況 - IT戦記
  • WINDOWSでEMACS/Muleを使おう!!

    WINDOWSEMACS/Muleを使おう!! あなたはこのページの番目の訪問者です。 もくじ イントロダクション 基礎知識・概念など Windows 標準と比較したキー割り当ての違い 必要な DOS の知識 Mule on Win32リンク 表紙 Emacs YOSHIZAWA Masahiro <manbou@ceres.dti.ne.jp>

  • プログラマではなくテスターとして現場デビューする - 設計者の発言

    筆者はプログラミングは好きだったが、テストについてはずっと苦手意識があった。プログラムがそれなりに完成してしまうとそれで満足してしまって、さっそく次のプログラムにとりかかりたくなる。結局、システムテストの段階でハデにバグが見つかってどれだけ周りに迷惑をかけたかわからない(今思い出しても冷や汗が出る)。「自分に代わってテストだけをやってくれる要員」がいてくれたらと気で願っていた。 だから、1年前にある小さなソフト開発企業で、「新人をまずテスターとしてみっちり仕込むようにしている」と聴いたときは感心した。その発想は考えれば考えるほど合理的かつ発展的だ。筆者なりに肉付けした形で紹介したい。 ◆新人は現場のお荷物である 多くのソフト開発企業での新人教育が何から始まるかというと、大学の一般教養課程のような「コンピュータ概論」だったりする。その後に「ソフトウエア分析・設計」とか「プログラミング」の学

    プログラマではなくテスターとして現場デビューする - 設計者の発言
    Wacky
    Wacky 2006/01/08
    1年前にある小さなソフト開発企業で、「新人をまずテスターとしてみっちり仕込むようにしている」と聴いたときは感心した。
  • ⊂二二二( ^ω^)二⊃ブーン:いまから10年来の恋に決着をつけます(前編)

    1 名前: 以下、名無しにかわりましてVIPがお送りします 投稿日: 2006/01/06(金) 15:47:47.50 ID:7CTAR4uJO メールで。 そこでおまえらの力を借りたい。 メールの内容を考えてくれ>>15 8 名前: 以下、名無しにかわりましてVIPがお送りします [sage] 投稿日: 2006/01/06(金) 15:49:28.68 ID:Ckp+ThPM0 まず背景を説明しろ 10 名前: 以下、名無しにかわりましてVIPがお送りします 投稿日: 2006/01/06(金) 15:50:32.20 ID:eDy4y4O80 ♂(オレ) 19歳。学生。 178cm 65kg(どちらかというと痩せている) 髪は短め。微妙に茶髪。 顔のレベルは中の中とでも言ったところ。 学業の成績は微妙。 将来の目標等も特になく何となく毎日を生きている。ニートにはなりたくない。 現在

    Wacky
    Wacky 2006/01/08
  • ひげぽん OSとか作っちゃうかMona- - Emacs + GLOBALでソース読みを快適に

    ネットワークサーバー実装のためにuIPのソースを読もう。 NICドライバの移植のためにFreeBSDのソースを読もう。 ということで以前使っていた etags を使おうと思ったがキーバインド忘れた。 そして etags はなんだかいろいろ不満点があった気がするので GLOBALを使ってみることに。 以前GLOBALは出力をHTMLにして使ったことがあるのだが、最近EmacsにどっぷりなのでEmacsから使ってみることに。 0.GLOBALって何? GNU GLOBAL は、ソースコードに索引付けを行うことで、大規模システムのハックやレビューを効率化するソフトウエアです。 ソースファイル中の指定したシンボルを高速に見つけ出し、素早くその場所に移動することができます。多くのサブディレクトリからなり、#ifdef や main() 関数を沢山含んでいるような、いわゆる巨大なプロジェクトをハックす

    ひげぽん OSとか作っちゃうかMona- - Emacs + GLOBALでソース読みを快適に
  • ⊂二二二( ^ω^)二⊃ブーン:いまから10年来の恋に決着をつけます(後編)

    さぁ、どう出る○○www 343 名前: 1 ◆XslOVlHjck 投稿日: 2006/01/06(金) 17:57:22.76 ID:eDy4y4O80 >>330 神!!!!送信!! もう一度言う、神! 344 名前: 以下、名無しにかわりましてVIPがお送りします 投稿日: 2006/01/06(金) 17:57:39.19 ID:8RMsJHVT0 >>330 救世主だな 349 名前: 1 ◆XslOVlHjck 投稿日: 2006/01/06(金) 18:00:30.98 ID:eDy4y4O80 返信北 彼氏!?(・_・;) 結構前にフラれたって××知ってるぢゃん!(>_<) あれからいないよー(>_<) ××はちゃんと彼女できた? いません。DTです。 >>360たのむ 359 名前: 以下、名無しにかわりましてVIPがお送りします 投稿日: 2006/01/06(金)

    Wacky
    Wacky 2006/01/08