1日は8時間? 24時間? - masayang's diary
今日はこの人のTweetがよく回覧されてきた。 「二日遅れということはせいぜい48時間です。 すごい。すごすぎる。だが、天下のNTTデータはそれが基本らしい。 海外拠点との時差を有効に活用して、24時間止めることなく開発を進めることで、工期の短縮を目指す「24時間開発」。国内外で活動する優秀な人材や海外の低コストの人件費メリットを生かしたスピーディな開発手段です。システム開発に対してさらなる「迅速性」が求められる中、NTTデータでは情報システムの開発速度の向上を図る「倍速開発」（第2回参照）の一環として、「24時間開発」の早期実現にむけた取り組みをすすめています。 →ソース: 海外との時差を利用した開発で工期短縮「24時間開発」 元請が「1日=24時間」で計画して、下請けが「1日=8時間」で物事考えていたら、悲惨な結果になるだろうな。
iOSの分断化がよ〜くわかる写真 - masayang's diary
Engadget: Android の分断化問題がよく分かる一枚の写真 (あほくさいので略) 開発者は別にして、一人で何台もAndroid携帯を保有する人はいないでしょ。なので、ボタン配置で悩むのってのは機種変更の時くらいではなかろうか。むしろ重視したいのは「同じハードの上で走るアプリケーションの操作一貫性」なわけでしょ。 で、iPhone/iPadでケチつけたいのはまさにそこなんよね。 YouTube →Shareボタンがあるので押してみる。 →メールでリンクを送る、ことしかできない。 Bloomberg →この矢印がついたアイコンを押すと... →メールでリンクを送る、ことしかできない。 Telegraph →共有機能はない。というか、見つけることができない。 Reuters News Pro →矢印アイコンを押すと... →メール、Twitter、Facebookで共有できるよ、とい
マネージャ≠管理職？ - masayang's diary
今朝Twitterで見かけた じゃあマネージャって何と訳せばいいの？ という意地悪な質問もしてみた。 皆さんは何と訳すべきだと思いますか？ ほげほげマネージャ、という名称が良くない件 昔は「クラス名に***Managerとか***Handlerとかつけるのは良くない」と習ったものだけど、最近はどうなんだろ。 「ほげほげマネージャ」という名称の良くない点は「その目的がわからない」からなんだよね。「なんたらハンドラー」も同様。管理してどうするのか？そもそも何のために管理しているのか？それらが名前から見えてこない。存在意義や存在目的がはっきりしなければ、そのクラスにとって本来不適切な役目・役割を背負わされる可能性が高くなる。クラスの肥大化とか、他クラスとの役割分担がややこしくなるとか。 組織の中における「管理職」も似たような立場にあるのではなかろうか。管理して何をするのか、そもそも何のために管理
何を持って基本設計完了と定義するか？ - masayang's diary
問: なにをもって基本設計完了と定義するか？ この問いかけをあちこちで何度もしてきたが、納得出来る答えが帰ってきたことはない。今日もTwitter界隈でこの質問をしてみたが...やはり答えは返ってこなかった。正確には「顧客との合意形成を持って完了とする」という答になっていない答がきた、というところ。詳しくはTwitterで私の発言を検索してくだされ。Togetterにまとめようとしたが面倒くさい（笑 「何を持って基本設計完了と定義するか」という問に対する答はざっと以下のように分類できる。 完了という合意が得られれば、完了 問題点がないことを確認したら、完了 だけどこのどちらも答になっていないんだよね。 前者は「ここまでにしておきましょうかね」「そうですね」という「主観的判断とそれに対する同意」でしかない。主観的判断を下す人が設計における漏れ・誤りを見落とせばそれは必ず実装段階以降で跳ね返っ
Hadoopは借りて使え - masayang's diary
NTTデータが公開したHadoop資料が話題になっている。ざっと読む限り、コード事例もあって参考になることは確か。読まない手はないだろう。 だけど、Hadoop環境を自前で構築することには私はあまり賛同できない。技術屋が勉強するため、というのなら話は別だけど、事業でHadoopを使うのならクラウド上のを借りることをお勧めする。 例えば1000台のクラスタを構築して、デイリーバッチ処理が5分で終わるようになった！ と喜ぶのも良いだろう。でも、残りの23時間55分はそのクラスタどうするのか？寝かせておくのであればROI評価は非常に低いものになるだろう。 かといってケチって5台のクラスタにしたらほぼ1日中稼動したのでROIは高くなりましたが処理時間短縮には至りませんでした、なんていうのも馬鹿げている。 じゃ、どこに最適点があるのか？ 答は「自前で持たず、必要なときに必要な台数のクラスタを借りる」
iTunesの脆弱性疑う前に... - masayang's diary
TechCrunch日本語版でiTunesストアに警報―PayPalアカウントを通じて大金を盗まれた被害者続出という記事が流れているけど、これで「iTunes危ない」と判断するのは尚早だろう。今のところiTunes+PayPalという組み合わせなので、むしろPayPalのID/Passwordをなんらかの手段で入手した連中が、iTunesを使って現金を手に入れようとしている、と考えるべきではなかろうか。 ちょっと前にMMORPGを使って似たような詐取を試みた連中がいたし。ゲームで使う道具(アイテム、っての？)を、なんらかの手段で入手したPayPalアカウントに売りつけていた、ってことね。 不安な人は プリペイドカードでiTunes使う。 PayPalのワンタイムパスワードを使う。→https://www.paypal.com/us/cgi-bin/?&cmd=xpt/Marketing_C
日経ITProの記事にケチつけておく - masayang's diary
日経ITPro: アジャイルはウォーターフォールよりも難しい 何を持って簡単・困難を定義するのかがわからないけど、「アジャイルはウォーターフォールよりもごまかすのが難しい」というのであれば、その通りだろう。 そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。 そもそも大規模プロジェクトを想定して生まれた手法は存在しないわけで。 ウォーターフォールは他に選択肢がなかったために大規模に適用されてきたけど、それが適切だったかはなんとも言えない。失敗しても他に選択肢がないんだから「ウォータフォールが悪い」って言えなかったしね。 ただ、最近は大規模でのAgile事例は増えてきている。日本ではまだ少ない、というところでしょ。 「要求の増加に歯止めが利きにくいアジャイル」というのも変だよね。 当初の一欄に
Agile2010 Day One - masayang's diary
本日はワークショップやチュートリアル中心の日。コマ数が多い中、Organization & Enterprisesを「持続可能な範囲で*1」聞いてきた。 目次 How Agile Taught IBM about New Leadership Competencies Agility@Scale - Experiences from the Trenches at IBM Rational Beyond Scope, Schedule, and Cost: Optimizing Value How Agile Taught IBM about New Leadership Competencies 現在はPitney Bowes社の国際技術担当副社長をのSue McKinney女史による「大企業のAgile化に求められる指導者の資質」に関する発表。彼女は去年まではIBMにて「世界各支社のI
ものぐさな人の味方・Amazon Elastic MapReduce - masayang's diary
その昔はSlackware Linux、時代が経過したらGentoo Linuxと、サーバーまわりをいじくるのが好きだった自分だが、最近はすっかり面倒臭がりやとなり、もはや自分でサーバー環境を構築する元気はなくなった。もう時代はクラウドですよ（棒読み そして賛否両論うずまくHadoopで遊ぶ今日この頃。当然、Amazon Elastic MapReduce。以下の手順で、hadoop関係のコマンドを直接使えるようになる。 前提 elastic-mapreduce-rubyが設定されていること。Amazonサイトから入手可能。 AEMインスタンス起動 $ elastic-mapreduce --create --alive --num-instances 17 --log-uri s3n://<適切なバケット名>/logs --hadoop-version 0.20 →Job識別子が返される
Facebookの新個人情報取り扱い基準と退会者増加 - masayang's diary
Google Newsで「Facebook Backlash」を検索すると、先月末あたりからFacebookの退会者が増えていることがわかる。そのきっかけとなったのが、同SNSの新しい個人情報取り扱い基準であることは疑いない。 最新のPrivacy Policyは4月22日付。左記リンク先に原文があるが、長い。NYTのこの記事によれば、5830語もあるそうな。これはアメリカ合衆国憲法の4543語より長い。まあ、こういうのは簡潔でわかりやすいことに越したことはないが、利用者が増えれば色々突っ込んでくる奴もでてくるので、色々と対処しなければならないのであろう。 そして新基準では、利用者の情報は「デフォルトで公開」という設定になってしまった。おそらくこれが、退会を決意するきっかけになっているのであろう。 だが、デフォルトで公開ということは、きちんと設定すれば公開範囲を制限できる、ということでもあ
RPXを使って認証を賢く簡単に - masayang's diary
OpenIDだとかFacebook認証だとか、おじさんにはどういう仕組になっているのだか全然わからないのだが、世の中どんどん進化している。 この手の認証サービスを活用することで、利用者もサービス提供側も幸せになれる。 利用者は新たなID/Passwordの組合せを覚える必要がなくなる。 サービス提供側は実装も運用も軽くなる。ID/Passwordに絡む処理の多くを削れるし、漏洩防止のための運用も楽になる。 とはいうものの、OpenID、Facebook Connect、Twitter API等々複数存在する認証全てに対応しようとすると、それはそれで結構しんどい。 そこでRPXの登場となる。RPXはOpenIDやFacebook Connectなどの認証を統合するAPIを提供してくれる。 RPXを使った認証の流れ (1) 利用者が自サイトのSign-inフォームを投函。投函先はRPXドメイン
Pylons+memcacheDBでのデータ永続化チュートリアル風味 - masayang's diary
クラウドだなんだと騒がれている中で、ちょっと真面目にKey-Valueデータ格納を触り始めた。Google App Engineで、と割り切れれば話は早いのだろうが、それ以外の選択肢もあってよかろう、ということでPylons+memcacheDBの組み合わせで遊んでいる。 その心は... Pylonsはデータ永続部分を自らは用意していない。お好きなものを組み合わせてね、という思想。 memcacheDBはmemcached APIで操作できるBerkeleyDBそのもの。結構速そう&信頼できそう。 とはいうものの、PylonsもmemcacheDBも実はよくわかってないので、手探りで簡単な電話帳もどきアプリケーションを作ってみたよ。 処理方式は先日紹介したFriendFeedのやり方を参考にしている。 FriendFeedにおけるMySQLへの大規模データ格納 - masayangの日記（
動かしながら変えていくということ - masayang's diary
いまさらだけど、2008年春の時点では、FacebookはMySQLに強く依存していたんだよね。しかも1800サーバ(900のMaster/Slave組み合わせ)!! そして、裏ではCassandraへの移行が既に始まっていた、と。 いくらx86とはいえ、1800台もサーバ動かせばそれは「資産」として扱いたくなる心境だけど、そこを敢えて否定してCassandraに持っていった姿勢は見習う必要がある。そして、その移行の理由は: Cassandra does not support a full relational data model; instead, it provides clients with a simple data model that supports dynamic control over data layout and format. →データスキーマをより素早く変
バックドア - masayang's diary
The Daily WTF: Maybe I Needing Later オフショア開発委託のお話。 // maybe I needing later if ($_GET['page'] == "delete_all_files"){ echo "del"; mysql_query("DROP TABLE *"); unlink("index.php"); unlink("apps.php"); unlink("resources"); ... snip all files ... } 本番にこんなコードを入れられていたそうな。 委託元が支払いを渋ったら実行するつもりだったんでしょ。 それにしても原始的だなぁ... 本気でやるのならPHPの【 】←各自コメント欄に（笑
こういうコードを書く人を... - masayang's diary
The Daily WTF: SQL Error 191: Nested Way Too F#%&ing Deeply SELECT DISTINCT COUNT(Task.RecId) FROM Task WHERE (Task.TaskType = @P514) AND (Task.Status = @P1) AND (Task.RecId is not null) AND (((((((((((((((((((((((((((((((((((((((((((((((((((( (((((((((((((((((((((((((((((((((((((((((((((((((((( (((((((((((((((((((((((((((((((((((((((((((((((((((( ((((((((((((((((((((((((((((((((((((((((((((((((((
何度でも言おう。基本はUnit Testだ。 - masayang's diary
Twitterにて。Uncle Bob Martine曰く: Testing through the GUI is just SO seductive. But the diseases you get in the end just aren't worth the momentary pleasure. GUIを通したテストってのはすっごく魅力的だけど、その一時的な快楽と引換に待っているのはヤバい病気だ。 本来Unit TestでやるべきようなテストをGUI経由で--例えばSeleniumとか--叩くのは非効率だし、実は肝心な部分をテストできていない(しかもテストできてないことに気づかない)結果に終わるのがオチ。
データに意味を持たせてはいけない - masayang's diary
Jalopnik経由: 'X' man's tag leads to more than $19,000 in Birmingham parking tickets 米国アラバマ州Birmingham市でのお話。 車の登録番号に「XXXXXXX」を選んだScottie Roberson氏。 なぜか、Birmingham市当局から駐車違反切符総計$19,000(ざっと180万円)をもらう羽目に。 →Birmingham市の駐車違反管理システムでは自動車登録番号標を装備していない車については、「XXXXXXX」を入力する仕組みになっていたから、らしい。 結果、登録番号標なしの車の切符全部を受け取ることになった、と。 データに意味を持たせてはいけない これもCOBOL文化の名残でしょ。 '9999999'で最大値とか。 'XXXXXXX'でデータなし、とか。 NULLという概念がなかった時代から
亀井マイクロマネージメント - masayang's diary
中小企業に対する融資を一件一件審査して、「返済猶予させろ」「もっと貸してやれ」なんてことまで国は口を出すべきなのかね？ そりゃ、不況はしんどい。 だけど、中小は身軽なのも事実。 不況でライバルが１〜２社減れば、その後の回復期はかなり楽になる。 寿司屋の息子として、そんな過程を数回目撃してきた。 そういう「新陳代謝」を国が否定するようなことはあってはならないと思うのよ。 ダイエーもそうだったよね。あんなのを税金で救ったばかりに、近所の商店はどれくらい迷惑したことか。 さて本題 ちょいと古いネタだけど... TBP: Buddy, Can You Spare $5 Trillion? (わりーけど、ちょっと500兆円貸してくんねーか？) 最初の図＝労働者一人が支える、非労働者数(15歳以下＋64歳以上) 今は1.2人 2020年には2.0人。 二番目の図は貯蓄率。 ずいぶん下がっているのね。
仕組に凝り過ぎて事業機会を失っていないか？ - masayang's diary
FT: Banks make $38bn from overdraft fees CNN: Bank overdraft fees to total $38.5 billion 米国の銀行は、「Overdraft(残高不足)」手数料で、2009年になってから385億ドル(3兆6500億円)稼いだ。 これは過去最高の勢い。 Overdraftとは？ ご存知の通り、米国は「小切手」での決済が幅広く浸透している。 小切手＝紙。 小切手≠即時決済。 即時決済ではないので、小切手を振り出す側は気をつけないと残高が最低値を下回る可能性がある。*1 この最低残高を下回ると、銀行は「Overdraft対応費」を請求してくる。 自分も慣れない頃はやらかしてしまった。 手抜きシステムで収益機会 vs 手の凝ったシステムで機会損失 こうして考えるとアメリカの銀行ってすごい！ まず、システムにかける金が少なくて済
クラウドの本質をITベンダが語ることが出来ない真相 - masayang's diary
さっきのに追記 ITPro: 「クラウド」とはいったい何か ITベンダーは本質を語れ 本質を語れない理由があるわけよ。 「語りたくない」あるいは「考えたくもない」真実が。 今のIT業界は、とてつもない非効率の上に成り立っている。 クラウドが本気で普及することで非効率性は排除されるだろうけど、これは市場規模の縮小を意味する。 そして「基盤エンジニア」は一気に供給過剰になる。 余剰人員でまくり。 その人達をどう食わせるかという大問題が待っている。 影響は基盤エンジニアだけには留まらないだろう。 基盤導入までの時間と費用が大幅に短縮されたら、今度はアプリケーション導入までの時間と費用が目立つのは必定。 当然、その部分の合理化が課題になる。 もちろん、このアプリ導入までの工程における「偉大なる非効率性」も、システム業界の大きな収入源なわけで。 分け合うパイが減る一方で、人は余る。 そんな現実は直視
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
