大前さんが制御室にいたらここまで問題は悪化しなかった、ってこと？ 作業マニュアル化の怖さを感じた。 まあ、いまそれを議論しても遅いのでとにかく早く事態が収束することを願っている。
プロセス主義 vs 職人 - masayang's diary
大前さんが制御室にいたらここまで問題は悪化しなかった、ってこと？ 作業マニュアル化の怖さを感じた。 まあ、いまそれを議論しても遅いのでとにかく早く事態が収束することを願っている。
手動発電機買ってきた - masayang's diary
自転車を発電機にするでも書いたが、災害時にはiPhone/Androidなどの携帯機器の電源確保が必須と考え、とりあえずREIに行ってみた。そしたらありましたよ。 Eton Scorpion Multipurpose Radio 手動発電/太陽電池付ラジオ・USB端子あり →普段は太陽電池で発電して、ラジオ用電池を充電できる。取手をくるくる回しても発電できて、脇にあるUSB端子からiPhone/Androidの充電ができる。試してみたが、Android携帯やNook Colorは割と楽に(ゆっくりと取手を回しても)給電できた。が、iPhone4はかなり素早く回さないと「このアクセサリでは充電できねーぞ」という警告がiPhoneより発せられる。 Eton Clipray 手動発電式懐中電灯・USB端子あり →これも取手を回してカリカリ回すと発電できる、とういやつ。やはりUSB端子からiPho
Rolling Blackout(輪番停電・計画停電)に思う - masayang's diary
2000年〜2001年にカリフォルニア州での電力危機*1を体験した俺様が発言しますよ。 震災の影響で東日本におけるRolling Blackout実施が現実となったらしい。その訳が当初は輪番停電で、後に計画停電となっているのが興味深い。たしかに計画的に停電させるので計画停電も悪くないが、元々の概念がScheduled BlackoutではなくRolling Blackoutであることに注意したい。目的は総消費電力量が総発電量を上回らないようにすることなのだから、停電をかけた区域での節電が足らなければ他の区域にも停電を拡大せざるを得ないし、節電量が充分と判断したら停電開始を遅めたり、停電終了を早めたりする事態も当然あり得る。すなわち「今日はこの区域で何時から何時まで停電する」と事前確定させることは容易ではない。従って「計画停電」という表現は誤解をまねくのではないかと危惧している。 実際、10
自立の遅れ、利権集団、そして国 - masayang's diary
Mises: Delayed adulthood, rent-seeking and the state →Creative Commons Licenseを継承して訳します。意訳度80%。 自立の遅れ、利権集団、そして国 なぜコンピュータオタクは自由を好むのか？ 子供たちがそろそろ将来を決断する年齢になってきた。長女は理学療法士を考えているという。先行き有望な感じだし、彼女もやる気充分だ。少なくとも最初のうち、私は長女を応援しようとしていた。 私は数学関係で学位を取り、コンピュータ関係の職場で仲間と共に働いてきたわけだが、理学療法士専門学校は卒業まで8年間必要という事実を知って衝撃を受けた。8年間... つまり娘はプロとして働けるようになる時には既に26歳になっている、ということだ。学費ローンの負債を抱えた上で、平均年収74,480ドルという理学療法士を目指すことに私は意義を見出せなくな
1日は8時間? 24時間? - masayang's diary
今日はこの人のTweetがよく回覧されてきた。 「二日遅れということはせいぜい48時間です。 すごい。すごすぎる。だが、天下のNTTデータはそれが基本らしい。 海外拠点との時差を有効に活用して、24時間止めることなく開発を進めることで、工期の短縮を目指す「24時間開発」。国内外で活動する優秀な人材や海外の低コストの人件費メリットを生かしたスピーディな開発手段です。システム開発に対してさらなる「迅速性」が求められる中、NTTデータでは情報システムの開発速度の向上を図る「倍速開発」（第2回参照）の一環として、「24時間開発」の早期実現にむけた取り組みをすすめています。 →ソース: 海外との時差を利用した開発で工期短縮「24時間開発」 元請が「1日=24時間」で計画して、下請けが「1日=8時間」で物事考えていたら、悲惨な結果になるだろうな。
明日のためにその１：トランザクション処理に依存しすぎない - masayang's diary
最近いわゆる非RDBでちょいと苦労したので、この記事は楽しく読めた。一方で、この記事を勘違いして読み取って、やたらとロックかけまくるようなシステムを作り上げる人達が増えないことを願って、ちょいとメモ書きなどを。 DBの「トランザクション分離レベル」が必要な理由 （PostgreSQLで，ファントム・リードを防止すべきサンプル事例） 分離レベルがデフォルト（read comitted）のままだと，恐ろしい不具合が発生する。 この後簡単な例題があって「ね、ファントムリードって怖いでしょ」という話に進んでいるわけだ。でも考えてみよう。「ある瞬間に唐突に締めきって、その瞬間にお金を分配する」なんていう処理はあるのだろうか？ 商売の世界なら「締め時間」があり、それ以前に受け付けたものなら処理の対象になる、というのが普通であろう。そして午後3時に締めて、そのコンマ数秒後に結果を出さなければならない、
証言・人生やりなおせるのなら、大学なんかもう行かない - masayang's diary
NYT: Europe’s Young Grow Agitated Over Future Prospects →高齢化/少子化に伴う年金負担増加・若者の失業率増加という問題を抱える南欧を取り上げた記事。 基本的な構造は、今日本で騒がれている問題と同じである。 強すぎる労組と、その労組が支持する政党。 現役世代の雇用は守られたが、若い世代は非正規雇用にしかありつけない。 結果、かなりの大学を卒業しても無償もしくは極めて低賃金の職にしかつけない。 “I’m a repentant college graduate,” she said. “If I had it to do over again, I wouldn’t go to college and would just start working.” 大学をでたことを後悔している。もしやり直せるのなら、大学など行かずにそのまま働き始め
Hadoopは借りて使え - masayang's diary
NTTデータが公開したHadoop資料が話題になっている。ざっと読む限り、コード事例もあって参考になることは確か。読まない手はないだろう。 だけど、Hadoop環境を自前で構築することには私はあまり賛同できない。技術屋が勉強するため、というのなら話は別だけど、事業でHadoopを使うのならクラウド上のを借りることをお勧めする。 例えば1000台のクラスタを構築して、デイリーバッチ処理が5分で終わるようになった！ と喜ぶのも良いだろう。でも、残りの23時間55分はそのクラスタどうするのか？寝かせておくのであればROI評価は非常に低いものになるだろう。 かといってケチって5台のクラスタにしたらほぼ1日中稼動したのでROIは高くなりましたが処理時間短縮には至りませんでした、なんていうのも馬鹿げている。 じゃ、どこに最適点があるのか？ 答は「自前で持たず、必要なときに必要な台数のクラスタを借りる」
Crazy Like Us: The Globalization of the American Psyche by Ethan Watters - masayang's diary
Crazy Like Us: The Globalization of the American Psyche 作者: Ethan Watters出版社/メーカー: Free Press発売日: 2010/01/12メディア: ハードカバー クリック: 4回この商品を含むブログ (5件) を見る 背景 自分は医者ではないし心理学者でもない。ただ、これだけ周囲で「心の病」に関する話題を多く見かけるようになると、その背景に興味を持たざるを得ないのも事実だ。デフレ、不況様々な原因が囁かれているし、メディアやネット上で医者や学者が何か語っていれば「ほうそうなのか」と納得してしまうこともある。 このCrazy Like Usは、たしかComedy Centralの「The Daily Show」で紹介されていた作品である。著者はEthean Watters女史。30分番組のさらに数分間という短い時間
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayang's diary
Agile開発に限らないが、システム*1業界用語ってカタカナ*2表記が多すぎる。 「いや、元々が舶来なので日本語では微妙に表現できないのですよ」という人もいるかもしれない。 でも、この「カタカナ表記のまま」ってのが意思決定者の判断を誤らせたり、新規参入者に対する壁を高くしたりしている可能性は排除できないのではないかな。 今日、この後打ち合わせが入ってるプロジェクト*3もFeature、Story、Scenarioがごっちゃになりかけている。 なんとかわかりやすく表現できないかと悩み中。 以下、自分の案。名訳があったら、是非教えていただきたい。 Feature=特徴 自分は今までFeatureを「機能」と紹介してきた。 同じ「機能」でも開発者が対象にするのはFunctionで、利用者が対象にするのはFeatureですよ、と説明してきた。 でも、安井さんと角谷さんの本29頁を読むと「特徴」がい
CPAアプリケーションに関する補足 - masayang's diary
ITMedia: iPhoneではアリエナイAndroidアプリたち →iPhoneでは有り得ないAndroidアプリというのが紹介されているが 「マリファナマップ」です。詳細は説明できませんが、乱暴に言えばマリファナの「食べログ」みたいです。作る方もすごいですけど、投稿する方もすごいと思います。 ここに出ているCPA(California Patients Association)というのは医療用大麻を処方してもらっている人達の団体。カリフォルニアでは(今のところ)大麻所持は禁止されているが、医師の処方箋をもらった上で指定された施設で利用することは認められている。 そこではCPAアプリ画面にあるように、色々な種類の大麻が選べる、と。 なので、このAndroidアプリは特に問題があるとは思えないし、データが集まるのも当然の話。むしろ、カリフォルニア地元のAppleがこのようなアプリの登録を
食べログアプリ有償化記念・Yelp裁判その後 - masayang's diary
なんかSlashdotとかいう小町みたいなサイトからYelp!関連の話題でチラホラと流れ込んでいるので、Yelp!裁判の最新情報などを... Media Post: Judge Dismisses Case Against Yelp Alleging Defamation, Coercion ニューヨーク州上級裁判所で争われていた歯医者とYelp!の件。 Yelp!上に、Glenn Reit氏が経営する歯医者に対する否定的な匿名コメントが書き込まれた。 Glenn Reit氏はその否定的コメントが正しくないとして削除をYelp!に要請。 だがYelp!側は否定的コメントだけ残し、肯定的なコメント10件を消してしまった。 3月、Reit氏はYelp!に対して名誉毀損および当該否定コメントの削除を要求する裁判を起こした。 だが同裁判所のJane Solomon判事は、Reit氏の訴えを棄却。以
Unit Test vs Functional TestそしてClean Code - masayang's diary
Agile2008でもらったゴムバンドを未だに手首につけている。確かBob Martinだったと思うが、テスト駆動開発と「Clean Code」の関係について熱く語っていた年だ。 メソッドは短く。 メソッドが実現することは一つ。 あるメソッドのテストに色々と条件を設定しているのなら、それはClean Codeではない。 だが我々はその基本を簡単に忘れてしまう。色々とテストのための道具が揃ってきたせいもあろう。基本を忘れて一つのメソッドに色々と詰め込みすぎるとテストが大変になる。Mockがあっても、だ。Fixture使うのはさらに大変だし、Seleniumとかで入力から何から条件を与えるのはもっと面倒。そしておそらく抜けが発生する。 最近、内職でPython使ったアプリを組んでいるのだが、今回は上記「基本」を徹底するようにしている。例えばこんなコードがある。 def nearby(reque
日経ITProの記事にケチつけておく - masayang's diary
日経ITPro: アジャイルはウォーターフォールよりも難しい 何を持って簡単・困難を定義するのかがわからないけど、「アジャイルはウォーターフォールよりもごまかすのが難しい」というのであれば、その通りだろう。 そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。 そもそも大規模プロジェクトを想定して生まれた手法は存在しないわけで。 ウォーターフォールは他に選択肢がなかったために大規模に適用されてきたけど、それが適切だったかはなんとも言えない。失敗しても他に選択肢がないんだから「ウォータフォールが悪い」って言えなかったしね。 ただ、最近は大規模でのAgile事例は増えてきている。日本ではまだ少ない、というところでしょ。 「要求の増加に歯止めが利きにくいアジャイル」というのも変だよね。 当初の一欄に
Agile2010 Day Three - masayang's diary
本日も我が道を行く。 From Estimate to Contract - Choosing the Right Model for Your Situation Becoming Agile: Designing a Transition Plan from Waterfall to Agile From Estimate to Contract - Choosing the Right Model for Your Situation Chris Shinkle/Jim LaRue両氏による好発表。基礎となっているのは「熊とワルツを」で紹介されているモンテカルロ法を使ったプロジェクト見積もり変動シミュレーション。このシミュレーションを元に、契約をFFP(Firm Fixed Price: 定額)にするのか、T&M(Time and Material: いわゆる人月課金)にするのか、ハ
Agile2010 Day Two - masayang's diary
目次 基調講演 LEARNING AGILE AT HARVARD PILGRIM HEALTHCARE, ONE STEP AT A TIME Fixed-Bid, Fixed-Feature, Fixed-Time Agile Development 基調講演 An Unplugged Retrospective on the Agile Decade: “Mirror Mirror on the wall are we really the most beautiful of all?” この10年のAgileをざっくばらんに振り返る。「鏡よ鏡、この世で一番美しいのは誰？」 Bedarra Research LabsのDave Thomas氏による講演。 去年の開幕基調講演も「過去10年を振り返る」みたいな感じだった。 個々の部分で面白い話はあったけど、基本的には「もういいよ」みたい
Agileの現状に対する漠然とした不安 - masayang's diary
去年のAgile2009では漠然としか感じていなかったのだけど、今年のAgile2010ではその不安がより確実になってきた。去年はCode Smellのたとえで言えば「どこかでタバコ吸ってる人がいるな」くらいの感覚だったのが、今年は「同じ部屋でタバコ吸ってるバカがいるぞ」、みたいな。 ただしCode Smellみたいなものなので、何かおかしいぞ、という程度の感覚でしかないのも事実である。 その漠然とした不安を抱かせる要因は何かというと「Agileのコモディティ化」なのであります。 自己紹介に「Certified Scrum Masterです」と説明を入れたり、「アナーターハーCSMデースカァー？」みたいな質問をしてきたりする人が今年は昨年よりも確実に目立つ。 あるいは...「わが社は自分では作りません。計画管理と実装は、コントラクタ(契約ベースで請け負う別会社)に任せてます。」みたいな丸投
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
雑感 - masayang's diary
Godfather's Burger - masayang's diary
