SocialWok面白そう - masayang's diary
SocialWokが面白そう。 GMailアカウントがあればすぐ使える。 これは何？ 仲間内で閉じたTwitter的空間を作る。 仕事仲間 学校・学級・同窓会 研究室・ゼミ・サークル 趣味仲間 .... その仲間内で共同作業をする際の道具になる。 Twitterみたいな仕掛でワイガヤ的議論 ファイル添付可能 つぶやきにコメントを付けられる Google Calendarを使ったスケジュール共有 Google Documentを使った資料作成・共有 必要に応じて、Twitter的つぶやきを他のサービスに公開できる Twitter Facebook FriendFeed LinkedIn なんのこっちゃかわからん人は、まず使ってみる事だ。 使い始める GMailアカウントを持っていれば、すぐ使えるよ。 http://apps.socialwok.com/ に接続 GMailアカウントを入力して
直球勝負！ - masayang's diary
DailyWTF: The Ultimate State Selector 一覧から州を選択する部分。 既に選択されている州があったら、そこにSelected属性を立てたいらしい... if ($province == "AL - Alabama") { $provinces = " <select name='usr_province'> <option selected='selected'>AL - Alabama</option> <option>AK - Alaska</option> <option>AZ - Arizona</option> <option>AR - Arkansas</option> <option>AA - Armed Forces America</option> <option>AE - Armed Forces Other Areas</option
Agile2009二日目 - masayang's diary
本日聞いてきたお話。 基調講演: I Come to Bury Agile, �Not to Praise It(PowerPoint資料) シェークスピアを読んでないと理解できない題名。 当然俺はなんのことかわからなかった。 「Agileを葬る」といっても、もうAgileが終わりということではない。 「Agileが普通になる」という宣言。 How the FBI learned to catch bad guys one iteration at a time 政府系受託開発のお話。 日本でいうSI屋さん。 お客はFBI。 FBIにおけるシステム開発の失敗事例は色々有名らしい。 そのFBIシステム部門がAgile開発を受け入れることで体質が変わりつつある、というお話。 二週間の周回開発。 計画ポーカー採用。 ペアプログラミング。 継続的統合。 一方で、CMMI Level-3は満たしてい
Agile2009三日目 - masayang's diary
本日聞いてきたお話 Scaling Scrum with Feature Teams 大規模SCRUMの話。 日本にも支社があるOdd-eによる発表。 「どんなに大規模になっても、Product Backlogは一つにまとめよ」 「The Product Ownerはどんなに大規模でも一人」 一人しかいなくて、しかも他の仕事が忙しいProduct Ownerが、膨大な量のProduct Backlogをどう管理するのか？ 一方、開発は複数チームに分けざるを得ない。 どういう根拠で開発チームを分けるのか？ 「大雑把な設計をし」「そのサブシステム単位で分ける」のが古典的な考え方。 だが、この段階での設計は非常に粗い。 その粗い設計を元にチーム分割する時点で、将来に向けての問題を埋め込むことになる。 そして問題が発覚する時点で手遅れ。まずいチーム構成のまま進むことになる。 Product Bac
これがGoogle Voiceの実力だ！ - masayang's diary
留守番電話に残された伝言を認識し、電子メールで送ってくれる。 もちろん、音声を再生することも可能。 だが、認識率は微妙なところ。 Google Voiceが認識した文章...間違っているところに赤を入れた。 Hi. This is Jean, Brodie, without work. Sorry I missed you but I wanted to just give you a very quick phone call of tonight to remind you of our at networking social tonight that will be at seven o'clock Wednesday night at the Mid, America Club about works in the thank, Bill saying that the 8 on
Cash For Clunkers終了へ - masayang's diary
LAT: 'Cash for clunkers' won't be running much longer, government says 政府は早ければ明日木曜にも、Cash for clunkers制度の終了を発表する模様。 ニューヨーク州の自動車ディーラー団体が、Cash for Clunkersからの離脱を発表したのを受けて、連邦運輸省のRay LaHood長官が終了の意向を表明。 政府からの補助金がディーラーの手元に中々届かないのが最大の原因。 日本と違って、米国の自動車ディーラーは在庫を抱えて商売をする。 政府からの補助金分を立て替えると、手元の現金が減ってしまう。 手元資金が減れば、新たな在庫を抱えることが難しくなる。 在庫が減るということは、売る車も減る、ということ。 売る車がなければ、Cash for Clunkersも意味がなくなる。 Fritz Hitchcock,
市場が決めること - masayang's diary
id:higayasuoさん SIerの解体と再生 id:JavaBlackさん 無責任な顧客企業とSIビジネスは鶏と卵 上の二つの記事を読んで思ったことをつらつらと... 自分も今のままでは、日本のシステム業界に未来はないと思っている。 二年前に書いた記事を参照。 全部顧客企業で内製しろ、と言ってるのではないよ。 内製すべきもの、外部に委託するべきものを分けるための「判断軸」を用意しないとダメ、って言ってるわけですよ。 この「判断軸」こそ、その企業の「情報戦略」なわけで。 そして「判断軸」を持ってない客ってのは、「高い〜 高い〜」とSI屋に文句をたれるのが常。 自分もひがさんと同じ理想を持っている。 でも今のシステム業界が自身を改革するのは無理だろうね。 2〜3人の気の知れた仲間でも、意見が合わなくなるときはある。 10人越えたら、中々意見はまとまらない。 ましてやそれなりの人数が集まる
クラウドの本質をITベンダが語ることが出来ない真相 - masayang's diary
さっきのに追記 ITPro: 「クラウド」とはいったい何か ITベンダーは本質を語れ 本質を語れない理由があるわけよ。 「語りたくない」あるいは「考えたくもない」真実が。 今のIT業界は、とてつもない非効率の上に成り立っている。 クラウドが本気で普及することで非効率性は排除されるだろうけど、これは市場規模の縮小を意味する。 そして「基盤エンジニア」は一気に供給過剰になる。 余剰人員でまくり。 その人達をどう食わせるかという大問題が待っている。 影響は基盤エンジニアだけには留まらないだろう。 基盤導入までの時間と費用が大幅に短縮されたら、今度はアプリケーション導入までの時間と費用が目立つのは必定。 当然、その部分の合理化が課題になる。 もちろん、このアプリ導入までの工程における「偉大なる非効率性」も、システム業界の大きな収入源なわけで。 分け合うパイが減る一方で、人は余る。 そんな現実は直視
プログラム取引と流動性 - masayang's diary
Zerohedge: Themis Trading: "Principal Program Trading Is A Way To Get The Market Go In Your Direction"経由: Bloombergがこういうインタビューを流していたとは... 聞き手: まずは住宅市場に関する意見を聞かせてください。ケースシラー指標は劇的な改善を見せたという話がある一方で、最もリスクが少ないはずの借手層における延滞が増えているとも聞きます。どうなんでしょう？ Joe Saluzzi: 私は最近言われている「景気改善」の議論はまったく買っていません。力強い反転がなければそれは回復とは言えません。悪化する速度が遅くなるのは回復とは言わないんです。 Joe: 評論家は、住宅価格下落の勢いが弱まってきた、これは良いことだとか言っていますが、何も良くなってないんです。住宅価格の下落は続
ファミレスにおける食事のカロリー表示 - masayang's diary
今日の昼は安くがっつり食うため、「IHOP」に。 テーブルの上にこんな表が置かれていた。 左から「メニュー」「カロリー(kcal)」「脂肪分(g)」「不飽和脂肪分(g)」「塩分(mg)」。 "Big County Breakfast"は、朝食といっているにも関らず2040kcalもある... 鶏肉・ベーコン・チーズのサンドイッチ＋French Friesにした。→1500kcalくらい。あと、コーラ二杯で400kcal追加。 追記: こんな規制が施行された模様。 California chain restaurants must post calorie counts starting today カリフォルニアにて店舗展開するチェーン店レストランは、各メニューのカロリーを公開しなければならない。 肥満や糖尿病を減らすことで、社会全体の医療負担を減らそうという狙い。
もうこういうのやめようよ... - masayang's diary
日経SYSTEMS実践セミナー 手戻りなしの要件定義テクニック 要件定義書の内容が不十分なまま設計作業に着手したところ，要件の追加や変更が相次ぎ，そのたびに手戻りが発生した──。システム構築に携わるITエンジニアであれば，誰しもこんな経験があるでしょう。手戻りにつながる仕様変更を防ぐには，要件定義をしっかりと行い，業務改善に役立つシステム要件を明確にし，構築時におけるユーザーからの協力体制を確保することが重要です。本セミナーでは，手戻りを起こさない要件定義の方法を徹底解説します。要件定義の経験が少ないITエンジニアでも実践しやすいように方法を分かりやすく解説するのに加えて，演習によって理解を深めていただくのですぐに現場で役立ちます。 要件定義が充分かどうかは作ってみないとわからないんだってば。 むしろ、要件定義が不充分であることを前提として、物事を進めるようにするべきなんだってば。 （株）
Java on GAE - masayang's diary
今ひとつ、存在意義がわからない。 Pythonのほうが遥かに楽に書けるような気がする...
Rintaさんの質問に答える - masayang's diary
http://d.hatena.ne.jp/Rinta/20070814#p1 長いので引用はしないよ。質問は4点あるようで Agileはプロジェクト管理の失敗をケアできるものなの？ 少人数のイタレーションでプロジェクトをまわしてくAgileでは大規模に対応できないのでは？ テストベンチはAgileだけの特徴ではないよね？ 設計書なしで保守をどうするの？ Agileはプロジェクト管理の失敗をケアできるものなの？ 次の質問への答が参考になるはず。失敗とはなにか？も参照のこと。 少人数のイタレーションでプロジェクトをまわしてくAgileでは大規模に対応できないのでは？ ウォーターフォールと同じものをAgile開発に期待するのなら、その通り。少人数でまわせば時間がかかるようになるだけ。 ここでいう「同じもの」というのは 全く使われない要件（フィーチャ） ほとんど使われない要件（フィーチャ） 使わ
権限委譲をしないことによる機会損失 - masayang's diary
日本からカンファレンス参加で出張している人と夕食。 そこでの話題。 アメリカのカンファレンスでよくやってるアンケート調査では、「役職」の他に「決定権」「予算権限」が質問される。こんな感じ。 機器発注に関するあなたの決定権限は？ 【最終決定権限を持つ】【提言するところまで】【助言するところまで】 機器発注に関するあなたの予算権限は？【1万ドルまで】【10万ドルまで】【100万ドルまで】 でも、日本の企業だとこれらがことごとく部長とかそれ以上の役職に集中しちゃうよね、というお話。 なんでも集中しちゃうから、その人達は短時間で物事を判断しなければならなくなる。 そのための説明資料作りで部下達は奔走しないといけない。 だとしても、短期間での判断を強いられるので、意思決定はどうしても「守り」に偏ったものになる。 こういう「資料作成とか説明にかかる時間」とか「保守的な判断に偏ることで失われる機会」とか
おじさんに求められる資質 - masayang's diary
自分の知らない事象を、自分の持っている知識の範囲内に置換えて考えるのは、割と普通の事である。 「あ、それはメインフレーム時代で言う○○みたいなことだね」 「なるほど。富山の薬売りみたいな事業構造だね」 だけど、そういう縮退した状態で意思決定しちゃいかんと思うんだな。 特に否定しちゃうのはよろしくない。 「あ、それはメインフレーム時代で言う○○みたいなことだな。じゃぁ、やっちゃだめだ。」 「なるほど。富山の薬売りみたいな事業構造だな。じゃぁ、やっちゃだめだ。」 こういう判断で失われるものは二つ。 新事業や技術革新の機会。 その判断をした人に対する畏敬の念。(存在していれば、の話だが) 若手が持ってきた提案を、昔の知識に置換えて考えざるを得ない状況にあることを発見したら、おじさんが取れる道は二つしかない。 勉強する。 引退する。 自分も気をつけよっと。
アジャイルな見積りと計画づくり - masayang's diary
安井さんから1月下旬に頂いた「アジャイルな見積りと計画づくり」。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者: Mike Cohn,マイクコーン,安井力,角谷信太郎出版社/メーカー: 毎日コミュニケーションズ発売日: 2009/01/29メディア: 単行本（ソフトカバー）購入: 74人 クリック: 764回この商品を含むブログ (226件) を見る なんと読むのに二ヶ月かかってしまった... 言い訳すると...印象に残った所に付箋をペタペタ貼っていたため。 大変遅れてしまって申し訳ないが、読後感想などを... 全般 これからAgileを始めたい人はもちろん、既にAgile開発に詳しいつもりの人も、「俺はウォーターフォールでいいんだ」という人にも是非読んでもらいたい本。 特に「進行基準」に興味ある人には強く推薦。 読んだ後は「見積りを精査します！」なんて
あなたの説明責任(Accountability)がなんぼのもんじゃ - masayang's diary
相変わらずのマイクロマネージメントな現場だらけで心が荒む日本出張。 が、よく見るとマイクロマネージメントには二種類あることがわかる。 「管理される側が力量不足なので、管理する側は細々と面倒みないといかん」 「管理する側の説明責任を取り繕うために、管理される側に対して細々指示を飛ばす」 今回問題にしたいのは、後者。 「私には説明責任がある。だから○○と△△と××しろ。」と部下に細々指示を出すのは簡単である。 だが、その説明責任とやらを遂行できない場合にどれくらいの損失が発生するというのだろう？ 降格・減給といった、認識可能な損失？ それとも、「こら！」と誰かに怒られるだけ？ あるいはプロジェクトがお取り潰しになる？ 説明責任を果たせない代償は様々だろう。 でも、その「代償」は「チーム全体の生産性」「部下のやる気」あるいは「部下が将来役立つ技術を学ぶための機会」を奪ってでも回避したいものなの？
IT業界で楽しく仕事をするための10カ条(毒) - masayang's diary
JavaBlackさんとこ経由: IT業界で楽しく仕事をするための10カ条のぱくり。 其の一、仕事は遊ぶための資金稼ぎと割り切るべし。 其の二、分からないことは、「わかりません」と素直にみとめるべし。 其の三、仕事中はひたすらブクマ項目追加に努めるべし。 其の四、社内外で毒を吐くべし。 其の五、勉強会やセミナーでは発表者が「もういいよ」というまで質問すべし。 其の六、専門分野を隠し、知ったかぶりする上司を嘲笑すべし。 其の七、会議は寝る場。 其の八、パソコンも携帯も持ってないととぼけるべし。 其の九、コーディングはできません、と演技すべし。 其の十、メモはポストイットで充分。 其の一、仕事は遊ぶための資金稼ぎと割り切るべし。 自分も趣味のプログラミングからこの業界に入ったけど、趣味と仕事とは別次元。趣味＝楽しい、仕事＝楽しくない。楽しみは仕事以外に持つのが吉。 其の二、分からないことは、「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
政治は時間稼ぎしかできない - masayang's diary
寒かった - masayang's diary
