ksh Days - デスマーチについて考える（デスマーチ経験のエピローグ）
このエントリは デスマーチについて考える前にデスマーチの経験を書く の続きです。(2007/2/16追記) 私はテスタとして、必ず バグの修正を「お願いします」と言う。 バグ修正確認時は、必ず直してないところも最低１箇所は触ってみる。（でよく落ちる） バグ修正が確認できたら、できるかぎり早く「確認できました。ありがとうございました」と言う。 を実践してゆきました。 ある日、一人のプログラマさんから相談を受けました 「今度の機能なんですが、納期が近いから単体テストせずにkshさんにテスト依頼しろってSEさんから言われたんですが、そんなことしたくないんです」 以下、全文はこちら
るびま
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
Open Tech Press 2人の「お婆さんハッカー」にインタビュー
Black Hatのようなカンファレンスのすばらしい点の1つは、新しい友人ができることである。とりわけ、才能に恵まれた相手に着ていたLinux Tシャツを褒められたような場合はそうだ。こうしてお近づきになったのがTerri GilbertとBecky Baceの両女史、これまでに出会ったギークやセキュリティ専門家の中でも最も注目すべき2人だ。年齢を推測するような野暮な真似をするつもりはないが、多分「お婆さんハッカー」と呼んでも彼女たちは気を悪くしないだろう。 カリフォルニア州出身の奇才Terriは、もう50年もコンピュータに関わっている。一方、アラバマ州出身のBeckyは自他共に認める実績を持ち、16年間、国家安全保障局（NSA）にいた彼女は、1980年代にNSAで開発されていた最初の侵入検知システムのプロジェクトマネージャを務めた。 現在、TerriとBeckyはInfidel, Inc
女性コンピュータエンジニアが少ない理由:Geekなぺーじ
コンピュータサイエンス分野を専攻する女性が何故少ないのか？ この問題を扱うACM-WというワーキンググループがACM内にあるそうです。 たしかに、情報工学系の学部には女性が非常に少ない気がします。 色々調べていたら、この問題に関してまとめてある論文(2002年)を発見したので何と無く読んでみました。 今回読んだ論文は「An ACM-W Literature Review on Women in Computing, Denise Gurer, Tracy Camp, SIGCSE Bulletin, Vol.34, No.2, 2002」です。 結構納得させられる内容でした。 コンピュータに興味を持つ女性の割合は、年齢が上昇するほど減少するそうです。 この論文では、問題点や取り組みを12種類に分類していました。 early in the pipeline (幼少期) attitudes (
「XPは押しつけるものではない。自分が変われば必ず伝わる」，XPの提唱者Kent Beck氏語る
「自分を変えられるのは自分しかいない」。2006年9月5日，ソフトウエア開発プロセスの一つ，eXtreme Programming（XP）を提唱しているKent Beck氏を囲んで記者懇談会が開催された。自分が変われば，必ずまわりは変わる。そんな信念が感じられた懇談会だった。 Beck氏の著書である「XPエクストリーム・プログラミング入門 第2版」は「XP is about social change.」という文章で始まっている。日本語版では「XPとは社会改革のことである」と訳されているが，ソーシャルのニュアンスが少し違うという意見もある。そこでまず「XPでいうソーシャルとはどういう意味か」と質問した。 Beck氏はソーシャルの例として「14歳になる私の娘は，ある友人と1時間くらい話をし，別の友人と同じ話をまた1時間くらいする。彼女はソーシャルな子供だ」と語った。つまり「社交的」「コミュニ
Passion For The Future: Make: Technology on Your Time Volume 01
Make: Technology on Your Time Volume 01 スポンサード リンク ・Make: Technology on Your Time Volume 01 これは面白い！。 モノを作る個人のクリエイティビティを次々に紹介していく本である。 スーパーマーケットのショッピングカーにエンジンを取り付けてゴーカートを作る人、アフリカの巨大ゴキブリを頭脳とするロボットを作る人、自宅で低温核融合の実験を続ける学者、中古マウスを自律センサーで動き回るロボットに作り変える人、VHSビデオを猫の給餌マシンに作り変える人、などなど。 クリエイティブで、少しクレイジーなものづくりの現場のドキュメンタリがカラー写真と解説で数十本。 時間があったらやってみたいと思ったのが「カイトフォト」と「ドロイドビルディング」。どちらも見ているだけでワクワクする趣味だ。 カイトフォトは凧に自動撮影機構
滑らかなアーキテクチャ
今回は（アレグザンダーのパターン）シリーズ最終巻「まちづくりの新しい理論」に目を通してみよう。われわれの（アレグザンダーの、ではなく）キーワードは「滑らか」、あるいは滑らかなアーキテクチャ」だ。 「まちづくりの新しい理論」は、「成長する全体」をいかにして作り出すかという理論とその実験の書である。「成長する全体」を作り出すための「最優先のルール」と「7つの中間的ルール」を定め、それをサンフランシスコの5年間、約90のプロジェクトからなるウォータフロント開発計画でシミュレートした過程が述べられている。 われわれは、この最優先のルールと、7つの中間的ルールをわれわれソフトウェアの言葉に翻訳しながら、具体的なソフトウェア開発プロジェクトに対してシミュレートする。 まず、「成長する全体」とは何か。もちろんアレグザンダーはあるべき「まち」を念頭に置いている（それに対して近代的な都市計画にはこれらの性質
Matzにっき(2006-07-15)
<< 2006/07/ 1 1. ミッフィー展 2. 弟家族 3. 冷蔵庫 2 1. 第一日曜日 3 1. [Ruby] Ruby on Railsトレーニング 2. 風邪 3. 地上波デジタル 4. [Ruby] るびま原稿 5. [Ruby] Web 2.0の挑戦者:プログラマフレンドリーなバグトラッキングシステム16bugs 4 1. [Ruby] トレーニング2日目 2. 六本木ヒルズ 3. [Ruby] Award on Rails 4. W-ZERO3[es] 5 1. 帰宅、校正 2. [Ruby] 「ブレイク直前のLinux」を思い起こさせるRubyのマグマ 6 1. [原稿] 『たのしいRuby』前書き 2. 「かわいそう」 7 1. 歯医者 2. Pickaxe2校正 3. 『情報処理』 4. [知財] Open Tech Press | 知的財産推進計画2006によせ
はてなに入った技術者の皆さんへ （jkondoの日記より）
最近はてなの社内では新しい技術を勉強したり、フレームワークや言語を移し変えようかという話も出ていたりして活気が出てきています。技術者も10人を超えて、色々な考え方をする人同士が刺激を与え合いながら切磋琢磨していて素晴らしいなあと思います。そういう中で、僕が技術について思う事を少しまとめてみました。 アウトプットを出す 新しい技術を習得したり、時間を掛けて作り上げた結果は、何かのアウトプットとして出さなければほとんど意味がありません。知識や結果を自分の中に残すだけで終わるのは、それを活かしてサービスを作りたくさんの人が使えるようにする事に比べると驚くほどちっぽけな仕事です。 また、3日間で作り上げた素晴らしい仕組みをそのまま1週間寝かせてしまうのは、4日目に他の人が使えるようにしてから1週間を過ごすことに比べると随分見劣りしてしまいます。 当たり前ですが、どれだけ素晴らしい仕組みを作っても、
分裂勘違い君劇場 - エンジニアがUIデザインしたがる本当の理由
ハイライトピックアップ Web2.0を引き起こしているのと同じ時代の潮流が、エンジニアの地位の低下を引き起し、エンジニアがUIデザインをしたがる動機を創り出している。 Googleは、「エンジニアの会社」という皮をかぶった「企画・マーケティング・デザイン」の会社である。 エンジニアよりデザイン能力の低いダメデザイナーがうじゃうじゃでてくる構造。 優秀な人ならデザインスキルがなくてもいいデザインができるのは幻想。現実には、デザインスキルの差は容易には超えられない壁。 デザイナーに必要な技術的知識とエンジニアの技術的知識は別物なので、エンジニアの技術力はデザインをする上でそれほど強みにならない。したがって、技術力とデザイン力を兼ね備えた優秀なデザイナーはエンジニアとデザイナーのハイブリッドではない。 一人の人間がUIのデザインと実装を両方やると二兎を追うものになってUIの質が低下する。二兎を追
バッドノウハウと「奥が深い症候群」
計算機を使っていると、何でこんなことを覚えないといけないのだ ろうか、とストレスを感じつつも、それを覚えないとソフトウェア を使いこなすことができないためにしぶしぶ覚えなければならない、 といった類いのノウハウは多い。そうした雑多なノウハウのことを、 本来は知りたくもないノウハウという意味で、私はバッドノウハウ と呼んでいる。 バッドノウハウは、ソフトウェアの複雑怪奇な仕様が歴史的に引き ずられ、根本的な改善は行われないまま、そのノウハウが文書によっ て受け継がれることによって蓄積が進行する。Unix 上で広く使わ れているツールとしてはTeX, Emacs, sendmail, bind, perl, gnuplot, procmail などは、役に立つツールであると同時に、その 複雑怪奇な仕様によって長年に渡ってユーザを苦しめ続け、バッド ノウハウの温床として悪名が名高い。こうしたツー
トヨタの強さ，GMの弱さ---「カローラ」と「Lexus」の関係から読み解く
現在までのところ「世界一」の称号を維持している自動車メーカー，米General Motors（GM）社が苦しんでいる。同社の業績不振は最近に始まったことではなく，長期にわたる低迷が報じられてきた。そして，2005年3月23日，新たなリストラ策が追加された。十分な採算の見込めない一部のブランド車種の市場撤退や，これまで「本業」の不振をカバーしてきた「副業」である金融子会社の一部売却，FRタイプの新型車の開発凍結などが柱だという。実は，同社はこのリストラ策の前に，米国にある七つの工場の閉鎖や，従業員の1割に当たる1万3000人もの人員削減策も発表している。1990年代の日本はバブル経済の崩壊に直面して「失われた10年」とも言われる一方，米国は「復活の10年」と表現される。だが，米国の自動車メーカーとなると話は別だ。その代表格であるGM社の過去十数年を総括するなら，「リストラの歴史」，もっと厳し
yohei-y:weblog: REST は難しい、だからこそ面白い
知り合いに教えてもらって知ったのだが、今月の日経ソフトウエアは Web プログラミングの特集である。 ちょっと立ち読みしたところ、内容は Web 2.0 まわりの記事だった。 その特集の中の囲み記事で REST と僕の名前が出てくるところがある。 「わかりづらい REST という言葉」というタイトルで、 REST がアーキテクチャスタイルであること、 一方で REST API は「ホームページ」のような誤用であるが、そちらの方が一般的になってしまっていること、 が簡単に記述されていた。 REST == HTTP GET+XML のような紹介よりも1万倍よかったし、 何よりこういう初心者向けのメジャー(?)な雑誌記事で REST に言及するよ うになって、本当によかったと思う。1年前には考えられなかったことだ。 ただ、気になったのは REST が難しくてわかりづらい、という話だ。 そりゃ確か
My Life Between Silicon Valley and Japan - 「ライブドアの技術の話」と「技術指向の経営」について
伊藤直也(id:naoya)の「ライブドアの技術の話」 http://d.hatena.ne.jp/naoya/20060127/1138329840 が話題になっているようなので、少し補足をしておきたい。 日本のライブドア報道を直接見聞きしているわけではないので、正確なところはよくわからないが、 今回のライブドアの件で、「ライブドアは虚業」、とか「日本のネット企業は心を改めて技術を磨け」みたいな論調を良く見かけるわけですが という書き出しで始まっているので、ネット事業について何も知らない人が、テレビ等で勝手なことを色々と言っているのだろうことは想像がつく。 まず、「ライブドアの技術の話」について、彼が書いている内容は100%正しい。 ただ、ライブドアがこうした確かな技術を持っているということと、ライブドアの経営陣が技術に対して深い関心を抱き「技術指向の経営」を行っていたかということは、全
圏外からのひとこと(2006-01-26)
* ソフトウエア業界の「バカ世界地図」 mixi発で、「Perl VS Java」というテーマが盛り上がっている。「ソフトウエア業界の中で、ある種のスキルが正当に評価されてないのでは？」という疑問に、「そうだそうだ、おかしいぞ」と同調する声が高まり、「いや、それには正当な理由がある」という反対意見が出て議論になっているようだ。 錯綜する議論の中にいろいろタメになる見解を見ることができて、業界人の端くれとしていろいろ勉強させていただいたが、ちょっと違う視点から(だってそれしか売り物がない)ブログのネタとして業界の外へ発信してみたいと思う。 まず、最初に関連するリンクをならべておく(ちょっとそれ系の用語が多いので業界外の人はパスした方がいいかも)と、mixi内のものとして、 Perlコミュ: 業務経歴書にPerl案件を書くと馬鹿にされる件 walrusさんの日記:「業務経歴書にPerl案件を書
プログラミングとは経営判断の集積である - 分裂勘違い君劇場 by ふろむだ
ソースコードの一行一行は、経営判断そのものだ。 どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるかは、そのソフトウェアステムを使って今後どのようなビジネス展開をするか、ということと一体不可分だ。プログラマーは、絶え間なく改変されていく部分と、財産として今後も使われつづけそうな部分を意識しながらコーディングする。そして、ここでいう財産とは、プログラマが財産とみなすものであるだけでなく、同時に経営的・財務的な意味においても財産であり、会社のバランスシートの「資産」の項目に登場するような性質のものだということは、多くのエンジニアが漠然としかいしきしていないように見える。 「このルーチンは、時間がかかっても、汎用的なライブラリやフレームワークにしておこう」、とエンジニアが「なんとなく」決めたとき、実は、そのエンジニアは
スラッシュドット ジャパン | 東証システム、構築は10年前ですでに耐用年数もオーバーしていた
nq曰く、"asahi.comの報道によれば、東京証券取引所の清算システムは、10年前に導入した日立製メインフレームで、一日分の取引内容を記録するハードディスクの容量で取引件数の上限が決まっているという。システムの貧弱さが断片的に報道されていたが、10年前の機材でネット取引の時代に対応できると考えていた証券取引所へ日本の経済が頼っていることに、唖然とするのは私だけではあるまい。" 続報：NIKKEI.NETの記事によれば、この週末で処理能力の増強テストを行い、23日からは約定件数の1日当たりの上限を500万件に引き上げる、とのことだ。「空白の10年」が更改遅れの原因の一つかもしれないが、迅速な決断と行動に期待したい。
木走日記 - 抜本的改良は手遅れな東京証券取引所システム〜問われる技術立国日本の脆弱性
●実は手遅れな東京証券取引所のシステム処理能力拡大策 東証の社長が株式売買システムの約定処理能力について「1日当たり700万件以上に引き上げたい」との意向を表明したそうです。 【東証問題】「約定能力を700万件以上に引き上げたい」、西室社長兼会長が表明 東京証券取引所の西室泰三社長兼会長は1月19日、株式売買システムの約定処理能力について「1日当たり700万件以上に引き上げたい」との意向を表明した。現在のシステムでは、1日当たり450万件が限界。1月30日のシステム刷新で約定処理能力を500万件まで拡大するが、さらなるシステム拡張をしたいとの考えを示した。 東証は1月18日、ライブドアの強制捜査開始による影響で約定件数がシステムの限界に迫り、午後2時40分に東証1部・2部・マザーズ市場の全銘柄の取引を強制的に停止した（関連記事1、関連記事2）。当日の会見で、東証は「年内にも1日の注文処理能
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアのための『仕事・職場・転職』応援サイト Ｔｅｃｈ総研
http://qdbm.sourceforge.net/mikio/rbbs.cgi?id=RA11419106120092212177