サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
アメリカ大統領選
masayang.hatenablog.com
Amazon謹製AMIを利用。Micro Instanceでも、まあそこそこ動く。そこにRedmineを入れようとしたのだが、Redhat系なんて10年くらいまともに使っていなかったので色々苦労した。 基本的にはこの記事に近いのだけど よくわからんかったので、Ruby Enterprise Editionってのは使わなかった。 gemsは yum install rubygems でいけた。 yum install ruby-develを実行しておかないと、ruby-mysqlの設置ができない。なんかのヘッダーファイルがない、と言われる。 gem install rake でrakeを取ってこないと(あたりまえだけど)rakeコマンドは動かない。 小規模チームのredmineならmicro instanceで充分でしょ。 おまけ automysqlbackupとs3toolsを使うと、re
のぶちゃんにはTwitterをブロックされているし、公式RTがウザいのでこちらもブロックしているが、非公式RTがえらい勢いで流れてくると「ああ、また暴走モードなんだな」とやるせない気分になるわけでございます。本日はこれだった →どうやらのぶりんは、犬を助けることが気に入らないもようである。犬顔だし、東電の犬みたいに原発持ち上げているのに。 →孫【百億円】正義氏が、佐賀県武雄市の取り組みを紹介する。武雄市とNPOが組んで、犬も連れていける避難所を用意。すばらしい。 →うむ。明らかに暴走モードである。 これでものぶちゃんの怒りは収まらないらしく、ブログでも吠えている。ｷｬﾝｷｬﾝ。 捨てる勇気 いま必要なのは、優先順位をつけて「捨てる勇気」である。それがわからない限り、日本はいつまでも負け続けるだろう。 もし、自分の飼っている猫と、見知らぬ人が遭難しかかっていたら、その見知らぬ人には申し訳ない
原発事故が引き起こした放射性物質騒動に対して「正しい情報を提供せよ」「科学的に判断して行動せよ」などという声がでているけど、それは無理というものだろう。 そもそも科学的に判断が出来る人達が大多数だったら、みのもんたみたいな輩がお茶の間に受けるはずはない。彼が「納豆が良い」といえば納豆が飛ぶように売れ、「ナスが良い」といえばナスが売り切れになるまで買い漁る。そんな人達がいるわけである。あるいは「血液型占い」。あんなのを信じちゃう思考回路の人達に「正しい情報」を提供し「科学的判断」を促すこと自体、徒労に終わる行為であろう。 つまり、パニック的な買い占め買い漁りは今後も発生するだろうし、風評被害による商品敬遠が生まれるのも避けられない。これは教育の問題であり、今さら手遅れなのである。 唯一の救いは...この手の人達は忘れるのも早いこと。放射性物質が怖いからと、あれだけ敬遠していた中国産野菜を買う
元GE技術者・菊地洋一さん講演 「命はほんとうに輝いている」の一部をパロってみた。 いろいろやってきたわけですけれども、実際に働いてみますと、システム開発の技術というのは全然確立していなかった。もう詳しい話は技術的な専門的な話になりますのでいいませんけれど、とにかくハチャメチャなんですね、施工で。施工というかシステムを造っていく開発の段階で。開発のミスが出るということは人間のやっていることですから、よく起こることですけれども、問題なのは設計そのものも十分検討されていない、いいかげんな感じで開発が進められていました。ですか ら開発中にしょっちゅう変更がある、そのことにもびっくりしましたけれども、送られてくるモジュールのインターフェースがあちこちぶつかっていたり、そういうことにもびっくりしました。自分でチェックしてみて余りにもぶつかっているので、びっくりしましたけれども、とにかく確立された技術
自転車を発電機にするでも書いたが、災害時にはiPhone/Androidなどの携帯機器の電源確保が必須と考え、とりあえずREIに行ってみた。そしたらありましたよ。 Eton Scorpion Multipurpose Radio 手動発電/太陽電池付ラジオ・USB端子あり →普段は太陽電池で発電して、ラジオ用電池を充電できる。取手をくるくる回しても発電できて、脇にあるUSB端子からiPhone/Androidの充電ができる。試してみたが、Android携帯やNook Colorは割と楽に(ゆっくりと取手を回しても)給電できた。が、iPhone4はかなり素早く回さないと「このアクセサリでは充電できねーぞ」という警告がiPhoneより発せられる。 Eton Clipray 手動発電式懐中電灯・USB端子あり →これも取手を回してカリカリ回すと発電できる、とういやつ。やはりUSB端子からiPho
2000年〜2001年にカリフォルニア州での電力危機*1を体験した俺様が発言しますよ。 震災の影響で東日本におけるRolling Blackout実施が現実となったらしい。その訳が当初は輪番停電で、後に計画停電となっているのが興味深い。たしかに計画的に停電させるので計画停電も悪くないが、元々の概念がScheduled BlackoutではなくRolling Blackoutであることに注意したい。目的は総消費電力量が総発電量を上回らないようにすることなのだから、停電をかけた区域での節電が足らなければ他の区域にも停電を拡大せざるを得ないし、節電量が充分と判断したら停電開始を遅めたり、停電終了を早めたりする事態も当然あり得る。すなわち「今日はこの区域で何時から何時まで停電する」と事前確定させることは容易ではない。従って「計画停電」という表現は誤解をまねくのではないかと危惧している。 実際、10
Mises: Delayed adulthood, rent-seeking and the state →Creative Commons Licenseを継承して訳します。意訳度80%。 自立の遅れ、利権集団、そして国 なぜコンピュータオタクは自由を好むのか？ 子供たちがそろそろ将来を決断する年齢になってきた。長女は理学療法士を考えているという。先行き有望な感じだし、彼女もやる気充分だ。少なくとも最初のうち、私は長女を応援しようとしていた。 私は数学関係で学位を取り、コンピュータ関係の職場で仲間と共に働いてきたわけだが、理学療法士専門学校は卒業まで8年間必要という事実を知って衝撃を受けた。8年間... つまり娘はプロとして働けるようになる時には既に26歳になっている、ということだ。学費ローンの負債を抱えた上で、平均年収74,480ドルという理学療法士を目指すことに私は意義を見出せなくな
Paper.liというサービスがある。 Paper.li - read a Twitter stream as a daily newspaper 現時点ではてぶが431個ついているから、そこそこ注目を集めているらしい。ぐぐって見ると自分の発言・記事が取り込まれ始めたのは去年の10月初旬あたりから。なんか知らない人からmentionが来ておそるおそるリンクを踏むと...ごちゃっとした配置の新聞風画面が。で、俺がどこにあるのかと探してみると、あんまりコンテキストと関係ないところにひっそりと。手の込んだスパムだなー、と思って最初の頃はかたっぱしからTwitterでブロックしちゃいましたよごめんなさい。 まあ別に害はないし発言や記事を取り上げていただけるのは嬉しいことなんだけど、paper.li利用者が増えてくるとなんかイライラするようになってきた。で、このイラつきはいったいなんなのだろうと考え
安物買いの銭失い...開発をアウトソースしてはいけないという事例、という題名でボーイング787開発の苦境を紹介したのが2007年12月8日。あれから3年ちょっとが過ぎ、未だに787は就航していない。 その787の状況を取り上げたLAT 2月15日記事をNaked Capitalismが解説している。まずはNaked Capitalism記事要点から。 Boeing’s Multi-Billion Outsourcing Fiasco アウトソーシングは、言われているほどコスト削減にはならない。 例えば製造業での工場人件費は製造原価の10%〜13%程度。そこを海外の安い労働者に任せてもそれほど大きな効果は得られない。 一方でアウトソースは余分な費用・リスクも発生する。 分業が進むことによる「Point of Failure(単一障害点)」の増加。 問題発覚の遅延。 現地社員の教育。 立ち上げ
「景気が良い」と言われる状態は二つある。一つは新しい技術革新やサービスで生産性が向上して実質的に成長が期待される場合。もう一つは、なんらかの原因で市場参加者が容易な融資を受けられる場合。後者はやがてどこかで限界に達し、急激な停止・逆転を見せることになる。いわゆる「バブル崩壊」と呼ばれる状態である。 そのバブルがオーストラリアでまさにはじけようとしているのではないか、という記事を見つけたので紹介しておく。 Macro Business(2010年11月16日): Deep T – The Capital Rort →「資本の不正利用」という表題。穏やかではない。 この記事では、オーストラリアの金融機関(Australian Deposit taking Institution (“ADI”))に適用されている会計基準こそが、オーストラリア不動産市場でのバブルを生む要因になっている、という事実
そのRay Hosler氏のブログに興味深い記事がある。まずは2010年6月7日のExcuses, Excuses! It’s Dangerousより。米国運輸統計局による自己統計をもとにした、2008年の死亡事故件数分類が紹介されている。 件数でみれば、クルマが最も危険で、以下、歩行者、自動二輪、自転車、列車、飛行機と続く。 では、確率で考えるとどうなるか？ こちらはWikipediaからの転載で 距離あたりでは、自動二輪が最も危険で、以下、歩行者、自転車、クルマ、列車、飛行機。 時間あたりでは、自動二輪が圧倒的に危険で、以下、自転車、歩行者、クルマ、列車、飛行機。 →時間あたりでは、自動車より自転車のほうがやや危険。ただし、大差をつけて危険な自動二輪と比較すると似たようなレベル。*1 次は、2010年8月23日のAccidents will happenという記事。こちらは、各国の自転
先日、雑感にて某ゲーム会社の失敗プロジェクト率について取り上げたが、その後「HTCの失敗率はもっとすごい」という話を聞いた。驚くなかれ95%。 調べたら2009年12月のWiredで取り上げられていたようだ。 Wired Gadget Lab: Strapped to Android, HTC Takes a Dizzying Ride to the Top →HTC社のR&D失敗率目標は「95%に設定されているよ」というお話。 失敗する、それも早い段階で失敗しておくことで、より深みにハマってからの失敗を避ける。そのことが、より速い研究開発と製品化につながる。だから95%の目標失敗率。 “It’s no longer a mystery what it takes to create a differentiated handset,” says Greengart. Handset ma
だが寝てない（笑
今日はこの人のTweetがよく回覧されてきた。 「二日遅れということはせいぜい48時間です。 すごい。すごすぎる。だが、天下のNTTデータはそれが基本らしい。 海外拠点との時差を有効に活用して、24時間止めることなく開発を進めることで、工期の短縮を目指す「24時間開発」。国内外で活動する優秀な人材や海外の低コストの人件費メリットを生かしたスピーディな開発手段です。システム開発に対してさらなる「迅速性」が求められる中、NTTデータでは情報システムの開発速度の向上を図る「倍速開発」（第2回参照）の一環として、「24時間開発」の早期実現にむけた取り組みをすすめています。 →ソース: 海外との時差を利用した開発で工期短縮「24時間開発」 元請が「1日=24時間」で計画して、下請けが「1日=8時間」で物事考えていたら、悲惨な結果になるだろうな。
日本語でのFacebook利用者が増えてきたのは喜ばしいことだけど、「TwitterをFacebookに同期させているだけ」という人も少なくない。発言数が少なければ別に構わないのだけど、怒涛のような勢いでこれをやられちゃうと他の情報が埋もれてしまう。 「そこでUnfriendですよ」と一歩飛びに行くのも悪い考えではないが、さすがにそれは失礼だろうということで「特定の人のStatus Updateを隠す」方法を紹介しておく。 まず隠したい相手を決める。で、その人の発言右上にある小さい×をつつく。 すると、利用可能な選択肢が表示される。 この発言だけ消す この人の発言を隠す この人が使っているFacebook Client(この場合はHootsuite)からの発言を全部隠す ここで必要なのは二番目の「この人の発言を隠す」なので、そいつを選択。以後、この人の発言はデフォルトでは表示されなくなる。
最近いわゆる非RDBでちょいと苦労したので、この記事は楽しく読めた。一方で、この記事を勘違いして読み取って、やたらとロックかけまくるようなシステムを作り上げる人達が増えないことを願って、ちょいとメモ書きなどを。 DBの「トランザクション分離レベル」が必要な理由 （PostgreSQLで，ファントム・リードを防止すべきサンプル事例） 分離レベルがデフォルト（read comitted）のままだと，恐ろしい不具合が発生する。 この後簡単な例題があって「ね、ファントムリードって怖いでしょ」という話に進んでいるわけだ。でも考えてみよう。「ある瞬間に唐突に締めきって、その瞬間にお金を分配する」なんていう処理はあるのだろうか？ 商売の世界なら「締め時間」があり、それ以前に受け付けたものなら処理の対象になる、というのが普通であろう。そして午後3時に締めて、そのコンマ数秒後に結果を出さなければならない、
Monday Note: iPad publishing: time to switch to v2.0経由WWD: Memo Pad: iPad Magazine Sales Drop →iPadと共に鳴り物入りで登場した「電子雑誌」その後。 Wired電子版は、6月に100,000ダウンロード。だが、10月・11月は22,500ダウンロード→マイナス78% Wired電子版は、紙版の3%にしか満たない。 Vanity Fairは、8月に10,500ダウンロード。11月は8700ダウンロード。→マイナス17%。 Vanity Fair電子版は、紙版の1%しか売れてない。 Glamourは9月に4,301売ったが、20%減が二ヶ月続き、11月は2775冊に。 GQは健闘。11月は11,000冊販売。だが5月から10月までの平均13,000よりは低下。 電子雑誌は全般的に売上が急低下している
ITPro: 「SE」は和製英語にあらず →英語圏にもSystem Engineerという職種はありますよね、というお話。 たしかにSystem Engineerという職種は存在する。ただしそれが日本のシステムエンジニア(SE)と同じかというと...ずいぶん違うように思える。例えばCareerBuilderでSystem Engineerを検索し、そこでの職種・職務説明を見ると良い。 The System Engineer is principally responsible for installing LANs and networking technologies for our clients, and training and supporting clients and their networks. The System Engineer configures the equ
Engadget: Android の分断化問題がよく分かる一枚の写真 (あほくさいので略) 開発者は別にして、一人で何台もAndroid携帯を保有する人はいないでしょ。なので、ボタン配置で悩むのってのは機種変更の時くらいではなかろうか。むしろ重視したいのは「同じハードの上で走るアプリケーションの操作一貫性」なわけでしょ。 で、iPhone/iPadでケチつけたいのはまさにそこなんよね。 YouTube →Shareボタンがあるので押してみる。 →メールでリンクを送る、ことしかできない。 Bloomberg →この矢印がついたアイコンを押すと... →メールでリンクを送る、ことしかできない。 Telegraph →共有機能はない。というか、見つけることができない。 Reuters News Pro →矢印アイコンを押すと... →メール、Twitter、Facebookで共有できるよ、とい
今朝Twitterで見かけた じゃあマネージャって何と訳せばいいの？ という意地悪な質問もしてみた。 皆さんは何と訳すべきだと思いますか？ ほげほげマネージャ、という名称が良くない件 昔は「クラス名に***Managerとか***Handlerとかつけるのは良くない」と習ったものだけど、最近はどうなんだろ。 「ほげほげマネージャ」という名称の良くない点は「その目的がわからない」からなんだよね。「なんたらハンドラー」も同様。管理してどうするのか？そもそも何のために管理しているのか？それらが名前から見えてこない。存在意義や存在目的がはっきりしなければ、そのクラスにとって本来不適切な役目・役割を背負わされる可能性が高くなる。クラスの肥大化とか、他クラスとの役割分担がややこしくなるとか。 組織の中における「管理職」も似たような立場にあるのではなかろうか。管理して何をするのか、そもそも何のために管理
というわけで某社の提供でiPad 3G/32GBを入手した。今日で5日目だが、普段使うアプリケーションはiPodとKindle for iPadに集約されつつある。家ではMacBook Proがあるし、移動中はG2使えばほとんど用は足りる。 個別のアプリケーションではiPadのほうが圧倒的に素晴らしい。UIはよくできている。Flipboardなんてのは最高にしびれた。*1 Kindle for iPadも、画面に反射する天井の光さえ気にしなければオリジナルKindleを凌駕した出来ではなかろうか。*2 だけど、そうやって褒められるのは「アプリケーションを通して情報を受け入れて、そこでおしまい」という人達だけだと思うんよ。 WSJ WSJのiPadアプリケーションで面白い記事を見つけた。是非これをTwitterでみんなに教えたい。こんな時にどうすればよいか？ ToolsメニューからEmail
問: なにをもって基本設計完了と定義するか？ この問いかけをあちこちで何度もしてきたが、納得出来る答えが帰ってきたことはない。今日もTwitter界隈でこの質問をしてみたが...やはり答えは返ってこなかった。正確には「顧客との合意形成を持って完了とする」という答になっていない答がきた、というところ。詳しくはTwitterで私の発言を検索してくだされ。Togetterにまとめようとしたが面倒くさい（笑 「何を持って基本設計完了と定義するか」という問に対する答はざっと以下のように分類できる。 完了という合意が得られれば、完了 問題点がないことを確認したら、完了 だけどこのどちらも答になっていないんだよね。 前者は「ここまでにしておきましょうかね」「そうですね」という「主観的判断とそれに対する同意」でしかない。主観的判断を下す人が設計における漏れ・誤りを見落とせばそれは必ず実装段階以降で跳ね返っ
NTTデータによる米Keane社買収は当地でもそれなりに話題になっている。金額が1000億円(12億ドル)と大きいのもあるけど、やはり日本の大企業が米国の老舗システム開発企業を買うというのはそれなりに憶測を呼ぶわけで。 ちょいとKeane社をぐぐってみた。 1965年創業。 本社はボストンだったりカリフォルニアのサンラモンだったり。今もサンラモンオフィスは残っている。 View Larger Map 90年代後半、2000年問題対応に強い、という触れ込みで伸びる。 2004年売上...$912M/利益...$32M 2005年売上...$958M/利益...$33M 2007年 Caritor社による買収 アウトソース専門企業CaritorがKeaneを買収。 買収金額は$854M。 非公開企業に。社名はKeaneを引き継ぐ。 買収時の公称・年間売上10億ドル。 得意分野 ヘルスケア、金融
Marketwatch: If mortgage rates plunged to zero →住宅ローン金利がさらに低下して「ゼロ」になるか？ Fedがさらなる金融緩和を示唆したので、住宅ローン金利はさらに低下する可能性がある。現在、米国の30年固定は4.3%程度なっている。(後述) ではどこまで下がるのか？ ゼロにはなるか？ 残念ながらゼロ金利住宅ローンがでてくる可能性はなさそうだ。ゼロ金利ローンだと、そのローンに出資する貸手が利益を得ることができない。だが、FedがMBS買取を再開すれば、さらに住宅ローン金利が下がる可能性はある。 現実は... boston.comの10月４日記事: Why monetary policy can't revive housing(金融政策は住宅市場を回復できない)では、住宅ローンの「現実」が解説されている。 金融危機前は、頭金30%を詰めばFICO
いや〜 一気に香ばしくなってきたじゃないですか米国住宅市場。 ロボサイン 先日紹介した新たな引き伸ばし工作？ それとも本当に問題あり？にて紹介した「書類の中身を確認せずにForeclosureを進めてしまった」事象を総称してRobo-Signingと呼ぶようになったようだ。ロボ・サイン＝機械的にForeclosureに必要な書類にハンコなり署名なりを記入していく、ということ。 発端 サブプライムローン破綻が問題になった頃から「Foreclosure Machine」と呼ばれる人達が存在したことが知られている。ローンの審査時より手続きが煩雑なForeclosure処理を機械的に進めていく人達。だけど、現状のForeclosureバックログはサブプライムローンが問題になった頃より遥かに多いのだ。しかも証券化されたローンは関係者が多すぎて、書類の確認だけでも相当な作業量になるらしい。 WaPo:
相変わらずクラウド活用とAgile開発を売り歩く日々なわけだが。 企業のシステム投資周期は必ずしも景気循環周期とは同期してくれない。償却が迫り、老朽化が目立っているシステムのその後を検討する際に、外部経済環境が最悪で動くに動けない、という状況に陥るのは珍しい話ではない。 だからといって現行システムの延命を図ることが正解なのだろうか。 今延命を図ろうとしているシステムは少なくとも5年前の事業戦略・事業設計・システム設計を基準にしているわけだ。当時の事業戦略が今も有効である可能性は高くはないだろう。そこを無理して延命すれば、5年後に改修ないしは再構築が待っている確率は極めて高くなる。 その場合(5年前のシステムを延命して5年待った後): 基準となる事業戦略は10年前のもの。 それを継承する事業設計も10年前のもの。 システムとして具現化した基盤もアプリも10年前の設計・技術。 これらを熟知して
NTTデータが公開したHadoop資料が話題になっている。ざっと読む限り、コード事例もあって参考になることは確か。読まない手はないだろう。 だけど、Hadoop環境を自前で構築することには私はあまり賛同できない。技術屋が勉強するため、というのなら話は別だけど、事業でHadoopを使うのならクラウド上のを借りることをお勧めする。 例えば1000台のクラスタを構築して、デイリーバッチ処理が5分で終わるようになった！ と喜ぶのも良いだろう。でも、残りの23時間55分はそのクラスタどうするのか？寝かせておくのであればROI評価は非常に低いものになるだろう。 かといってケチって5台のクラスタにしたらほぼ1日中稼動したのでROIは高くなりましたが処理時間短縮には至りませんでした、なんていうのも馬鹿げている。 じゃ、どこに最適点があるのか？ 答は「自前で持たず、必要なときに必要な台数のクラスタを借りる」
俺も使ってるClipper Card。サンフランシスコ地域で通用するSuicaのようなもの。 自分はCalTrainでしか使ってない。CalTrainにはそもそも改札口がないから、乗る前・降りた後に検札機にClipperを押し付けて精算を完了させる。車内での検札は、車掌が持ってる端末機にかざすことで正規乗車かどうかがわかるようになっている。 これがSan Francisco市内のMuni鉄道では話が変わる。Muni鉄道にはClipper対応の自動改札機が導入された。だが、この自動改札機には重大な欠陥がある。 →Clipperを使わなくても、感知器の前に手をかざせば改札は開いてしまうのだ！ この新型自動改札導入にかかった税金は$30M=25億円。Muniはこの問題を既に把握しているが、今のところ車内・改札内での人力検札強化しか手段はないという。なお、無賃乗車が見つかると罰金$75。→ソース
ITMedia: クラウドコンピューティングは本当に安上がりなのか？ →はい。安上がりです（終了） 補足 能力は想定繁忙時にあわせる。 サーバ機器を5年償却で保有。 この前提だけで、充分クラウドのほうが安上がり。そもそも想定繁忙時をどうやって見積もるのかで、高給取りのコンサルタントやら上流設計技術者やらがワラワラ沸いてきて高額な請求書を置いていく。そしてその想定繁忙能力がいかに妥当か、外れたときの責任所在をいかに曖昧にするかの駆け引きが続き、これだけでプロジェクト着手が数ヶ月は遅れる→稼動しなかった分は「機会損失」ね。 で、普通は責任所在を曖昧にするために繁忙時能力は多めに見積もられる。つまりは過剰投資。そして繁忙時／閑散時の能力差が大きいほど、この投資効果は低くなる。100あるサーバ能力が100使われることは滅多になく、普段は10とか5で動いていたら、それは損失だよね。でも負荷に応じてサ
次のページ
このページを最初にブックマークしてみませんか？
『masayangの日記（ピスト通勤他』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
