タグ

ブックマーク / satoshi.blogs.com (39)

  • 野田総理の言う「電気がもたらした豊かで人間らしい暮らし」のイメージを作ってみた

    野田総理の原発再稼働へ向けた会見には違和感を覚えた人も多いと思うが、私がもっとも違和感を感じたのは「私たちは、大都市における、豊かで、人間らしい暮らしを電力供給地に頼って支えて来ました」という一節。 野田総理が(実際にはその後ろにいる経産省が)言うところの「大都市における豊かで人間らしい暮らし」とは何を指すのだろうか?すぐに頭に浮かぶのは、オール電化のマンション、クーラー、電気ポット、食洗機、24時間営業のコンビニエンスストア、50インチの液晶テレビ、パチンコ屋、ゲームセンター、ネオン街などだ。 イメージにしてみるとこうなる。 一方、原発事故が福島県の人々から奪ったのは、一生かけて育んで来た畑であり、安心してべられる地元の材であり、校庭で泥まみれになって遊ぶ子供たちの笑顔である。 どちらを「人間らしい豊かな暮らし」と呼ぶべきか、どんな国を私たちの子孫に残したいのか。今一度考え直すべき時

    野田総理の言う「電気がもたらした豊かで人間らしい暮らし」のイメージを作ってみた
    shkatou
    shkatou 2012/06/09
    昔は技術系のエントリーはわかりやすく視点も面白かったのになぁー。反原発になってから急に気持ち悪いエントリーばかりで残念。
  • Nokia+Microsoftパートナーシップは、「3強3OS時代」の幕開けか

    おおかたの予想通り、NokiaはGoogleではなくMicrosoftをパートナーとして選んだ(参照)。簡単に解説すると、 NokiaはWindows Phone7をNokiaのスマートフォンの唯一無二のプラットフォームとして選択する NokiaはMicrosoftのBingサーチエンジンとadCenterを全面的に採用する 低価格端末にはSymbianを使いつづけるが、これ以上のSymbianへの開発投資は行わない 開発中のMeeGoベースの機種は一応は出すが、これはWindows Phone7への「中継ぎ」でしかない 携帯電話、スマートデバイスを作っている部門を別々のビネスユニットとする(スピンアウトではなし) ソフトウェア(Symbian + MeeGo)の開発部門を大幅にカットする NokiaはMicrosoftにソフトウェアのライセンスフィーを払うことになるため粗利益率は下がる

    shkatou
    shkatou 2011/02/12
    溢れるNokiaの技術者をGoogleがかっさらおうと目論んでいるわけね。
  • 日本のケータイが「ガラパゴス化」した本当の理由

    「ガラパゴス」という言葉が今年の流行語大賞の候補に選ばれたということを聞いていたので、密かに受賞しないかと期待していたのだが、残念ながら大賞は逃したようだ(もし大賞に選ばれていたら、私が受賞することになったのかどうかの疑問はこれで解けずに終わってしまった)。しかし、この言葉をずいぶん前から使っている私としては、この言葉が一人歩きしているようでなんとも言えない気持ちなのでひと言。 まず最初に断っておくと、私が2001年のCTIA(米国の携帯電話業界で一番大きなカンファレンス)のスピーチでこの言葉を使った時は、単に日という「単一民族で、国民の大半の生活レベルが同じで、家電とか携帯電話のようなガジェットに流れるお金が比較的多い」という特殊な環境で、iモードを中心に「ケータイ・ライフスタイル」が異常なスピードで進化をとげていることを表して、「ガラパゴス現象」と呼んだだけのこと。決してネガティブな

  • Google App Engine入門:実践編

    今週に入って、Tiny Message に続く二つ目の Google App Engine ベースのサービスをリリースした。3日ぐらいで試験的に作った Tiny Message とは異なり、今回のものは、丸二ヶ月間寝る間も惜しんで作った力作である。 米国向けのサービスな上に招待制のSNSなので、ここではサービスそのものは公開しないが、いくつかこだわって作った部分があるので、それについて語ってみようかと思う。 1. 対象となるユーザーの絞り込み FacebookやTwitterのような巨人が存在している中で、それにまっこうから対抗するようなソシアル・ネットワーク・サービスを作ったところで無謀なだけである。そこで、逆に対象にするユーザー層を究極にまで絞り込んで、彼らのライススタイルに徹底的にマッチしたサービスを作ることにより差別化をはかる、という戦略を選択。対象は「LAに住む20〜30代の社交

    Google App Engine入門:実践編
  • Google App Engine入門:Entity Groupとトランザクション処理

    今週に入ってから、ようやく少し気でGoogle App Engineでプログラムを書き始めている私だが、ようやく Entity Group の使い方が分かって来たので簡単に解説してみる。 Entity Groupとは、一口で言えば「トランザクションを使ったアトミックな読み書きの対象となるEntity(=データベース上のオブジェクト)の集まり」である。 イメージとしては、まず「一つのハノイの塔を三人で同時に遊んでいる姿」を思い浮かべると分かりやすいかも知れない。全くのルールなしで皆で同時に遊ぼうとすると、腕が交錯してぐちゃぐちゃになってしまう。 そこで、「ある時点でハノイの塔ボード(三つの棒を支えている水平に置かれた板)に触ることが出来る人は常に一人。一度ボードに触った人はすべての円盤をいずれかの棒の位置に置いた状態にしてからしか手を離してはいけない。もし自分がハノイの塔に触りたい時に、す

    shkatou
    shkatou 2009/11/10
    Google App Engineがどうやってスケールしているか理解しておくために読んでおく。
  • 「RESTful MVC」なアーキテクチャの話

    最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON(XMLでもかまわない)をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく(ずる=来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事)

    「RESTful MVC」なアーキテクチャの話
  • Ruby on Railsの「えせMVC」の弊害

    先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC(Model View Controller)がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの(コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること)を避

    shkatou
    shkatou 2009/10/12
    Controllerにビジネスロジックを持たせるか
  • 常に地に足をつけて仕事をするということ

    こちら(北米)で仕事をする場合、一番の褒め言葉は「あいつはAccountableだ」という言葉。辞書には、Accountableには「責任のある」などの訳語が乗っているが、仕事の場面で使う場合は「安心して仕事をまかせておける」という意味。 プログラミングにしろ他の仕事にしろ、何をしていてもさまざまな「予想外の問題」が生じるもの。そういう問題への対処も含めた上で、「あの人に仕事をまかせておけば安心」と思ってもらうには、さまざまなところに予防線を張り、常に「地に足をつけた」状態で、着実に仕事を進めて行くことが何よりも大切。

    shkatou
    shkatou 2009/02/24
    「あの人に仕事をまかせておけば安心」と思ってもらうには、さまざまなところに予防線を張り、常に「地に足をつけた」状態で、着実に仕事を進めて行くことが何よりも大切
  • iPhoneのJailbreakの危険性に関してひと言

    iPhoneをハックして、Appleが認めている以上のカスタマイズを可能にしたり、Apple公認のApp Store以外からのソフトをインストール可能にしたり、することをJailbreak(=脱獄)と言うのだが、PhotoShareでの会話とかを見ていると、その危険性をちゃんと理解せずにJailbreakしている人たちがたくさんいるようなので、ひとこと警告しておく。 まず最初に考慮しておくべきことは、iPhoneはNintendo DSやSony PSPと違い、携帯電話でありメールマシンであり、インターネットマシンであり、住所録やらメールやらウェブサイトのパスワードなどの個人情報を思いっきりやりとりする、ある意味パソコン以上にプライバシー管理が大切なマシンであること。当然、ウィルスに感染したり、セキュリティホールからハッカーに情報を盗まれたりしないようにすることがものすごく大切。 パソコン

  • スケーラビリティとユーザービリティの話

    先日のPhotoShareのスケーラビリティのエントリーに関しては、さまざまなご意見をいただき、とても良い勉強になっている。ただし、少し分かりにくかった部分があると思うのでそこに関して補足しておく。 サーバーのスケーラビリティに関してはすでに色々なところに書かれているが、今回の私が注目しているのは、どうやってサーバーのキャパシティを増やすか、という話ではなく、サーバーのキャパシティを超えたトラフィックが来てしまった際にどんな挙動をするように設計しておくのが良いか、という話である。 限られた資源を使って数万人・数十万人の人たちにサービスを提供するかぎり、予想外の急激なトラフィック増加でサーバーに過負荷がかかったりすることはどうしてもあるわけで、そこで問題となるのは、その手の過負荷をどうさばくか。 たとえば写真に付いたコメントを表示させる場合、「最新の情報をすぐに」表示するのが良いのが当たり前

  • マルチスレッド・プログラミングの落とし穴、その2

    ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その1(かもしれない)」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。 PhotoShareのバックエンドのようにCRUD(Create/Read/Update/Delete)のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに(HTTP Requestに返事をする前に)データベースに変更を加え、Readの際にも(キャッシュを使う・使わないを別にして)データベースの最新の状況を反映するデータを返すように設計するのが普通である。 このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックと

  • Life is beautiful: Google Chromeに関してひとこと

    今回Googleが発表したウェブ・ブラウザー、Google Chromeは、ひと言で言えば、「安定度・安全度を高めるために、それぞれのタブを別プロセスで走らせるタブ・ブラウザー」である。 95年にIE3.0を設計した時には、タブのコンセプトも存在せず、セキュリティの問題もそれほど強く意識していなかったので、ウィンドウごとに1スレッドを割り当てたマルチ・スレッドを選択した訳だが、ここまでウェブ・アプリケーションが重要になってくると、マルチ・プロセスに移行するのは当然。特定のページ上でのJavaScriptの挙動がおかしくなったからと言って、ブラウザーすべてが落ちてしまう今までの設計が異常。 一つのウィンドウ下で管理させるそれぞれのタブにプロセスを割り当てる、一般的に一つのウィンドウに一つのプロセスやスレッドを割り当てる通常のGUIアプリケーションとは異なるが、ユーザー・モデルとリソース管理は

  • なぜ「iPhoneキラー」がことごとく失敗するのか

    MBAの授業の一環で、"Marketing Myopia" (by Theodor Levitt) という1960年に書かれた論文を読む機会があったのだが、色々とうなずけるところがあったので、メモ代わりに。 家電メーカーのような技術系の会社は、どうしても技術系の人が経営者になりがち。技術系の人は(私も含めてだが)色々な問題を論理的に解決しようとする。技術的な問題を解決するためにはこのアプローチはとても有効だが、消費者心理のように曖昧で非論理的なものには適用できない。 技術系の経営者が陥りやすい失敗は、自分がコントロールできる分野、すなわち、技術的に難しい問題を解決することにばかりエネルギーをそそぎ、非論理的で簡単にはコントロールできない消費者の動向のようなものに十分な注意を払わないこと。 その結果、「消費者はどのみち論理的な行動なんてしないんだから、それに関して色々と戦略を立てたところで無

    shkatou
    shkatou 2008/08/25
    技術系の経営者が陥りやすい失敗は、自分がコントロールできる分野、すなわち、技術的に難しい問題を解決することにばかりエネルギーをそそぎ、非論理的で簡単にはコントロールできない消費者の動向のようなものに十
  • iPhoneがなぜそれほどまでに「革命的」なのか

    iPhoneに関しては、まだ誤解している人も多いようなので、念のために解説しておくと、iPhoneがこれほどまでに通信業界で注目されているのは、マルチタッチのUIを採用しているからでも、NextStepの血を引く最先端のiPhoneOSを積んでいるからでもない。NTTドコモなどの旧来型の通信キャリアからみれば「単なるデバイスの調達先」でしかなかったデバイスメーカーがキャリアのビジネスに口も手も出している点にある。 私がAppleとAT&Tの提携発表で一番驚かされたのは、その料金体系であった。パソコン並にネットワークを使うiPhone向けの使い放題プラン(日の「パケ放題」に相当する部分、ただし容量制限は一切ない)が月々わずか20ドルというのは、当に破壊的な価格である。この価格故にiPhoneは非常に魅力的なデバイスとなっているし、これだけ普及している。もちろん、それを実現するためにAT&

  • 「作っては壊す」過程があってこそ良いものが作れる

    iPhone用の「はてな人気エントリーリーダー」、そろそろ形になってきたのだが、作ってみていろいろと発見した部分もあったので、全面的にクラス構成を見直し、大幅に書き直した。 HTTPで通信をしているコードが二カ所に分かれていたので、それをDataOverHTTP/XMLOverHTTPという二つのクラスにまとめ(XMLOverHTTPはDataOverHTTPのサブクラス)、はてな独自のRSSフィードを読んでいるコードから一般的なRSSフィードを扱うコードをくくりだしてRSSFeed/RSSFeedLoaderという二つのクラスにまとめて、あとで別のアプリケーションで再利用することを可能にした。それに加えて、各種ローダーに非同期通信をさせる主体をController(HotEntryViewController)からModel側(HateneHotEntry)に移すことにより、難解になりが

  • Life is beautiful: 日本語とオブジェクト指向

    先日、日経BPの出版局の方と話をする機会があったのだが、私がマイクロソフトでウィンドウズ95の開発に関わったことに触れた際、「ユーザーインターフェイスの設計において、日人であることで何か役に立ったことはありますか?」と聞かれた。日人であることがプラスになったとは思わないが、ふと思い出したことがある。当時、「日語はオブジェクト指向な言語だな」と思ったことである。 その当時(90年代初頭)、アップルの方が使い勝手に関しては一歩も二歩もマイクロソフトより進んでおり、そのためには、もともとゼロックスが提案しアップルが商品化した、「オブジェクト指向ユーザーインターフェイス」の考え方を、より推し進めるしかないという戦略で、ウィンドウズ95のユーザーインターフェイス(当時は Object-Oriented Shell と呼ばれていた)の開発をしていた。 「オブジェクト指向ユーザーインターフェイス」

    Life is beautiful: 日本語とオブジェクト指向
  • "Less is more"なもの作りと合議制と

    ズバリ言ってしまうと既存機能に上乗せする企画は通すのが簡単だし、リスクが少ないからだ。【機能やボタンが多すぎ!! 使いにくいUIのデジタル家電が発売されてしまう当の理由 - キャズムを超えろ!より引用】 こういった罠にハマらないためには、色々とすべきこと・してはいけないことがあるが、たぶん最も強く意識すべきは「合議制では良いものは作れない」という法則。デザインに関わる人が多ければ多いほど、「いろいろな意見」が寄せられてしまい、「せっかく有意義な意見を出してもらったのだから」と次々に意見を取り入れているうちに、機能だけはたくさんあるけど魂が無くて妙に使いにくいものが出来てしまう。 その意味では、37signalsの人たちが言うところの「less is more」は「単に機能を削って使いやすくする」というだけの話ではなく、「企画に関わる人の数を削って魂があるものを作る」というもの作りの過程そ

  • Life is beautiful: Microsoft/Yahoo:買収はたぶん成功するだろうけど、問題はそれからだ

    今回のMicrosoftによるYahooの買収のオファー。ウェブの世界ではどうしてもGoogleに勝つことができないMicrosoftとしては、Yahooのビジネスはのどから手が出るほど欲しい存在。Googleに追い越され、成長に陰りが見え始めた結果株価が安くなったYahooは今がお買い得。WindowsとOfficeというドル箱を抱えながらも、そのドル箱が稼ぎだす莫大な現金をどこに投資すべきかがいまいち見いだせてないMicrosoftとしては、Yahooを買うことによりその価値を買収価格より高くする、というストーリーは説得力がある。 一方、Yahooの株主にとってみればこれは朗報。ずるずると下がり続けていた株に対してこれだけのプレミアムを付けてもらえば喜んで売るのが大半の株主。 少し悩ましい立場にいるのが、Yahooの現行の経営陣。株主利益を最大にするのが役割の経営陣とすれば、このプレミ

  • Life is beautiful: MacWorld Expo: なぜiPod touchのアップグレードのみ有料なのか?

    スティーブ・ジョブズの基調講演でもうひとつひっかかったのが、Apple TVとiPhoneのソフトウェア・アップグレードが無料なのに、iPod touchのアップグレードが20ドルなこと。Apple TVとiPhoneのソフトウェア・アップグレードが無料なことに触れたときは、誇らしげにストップして拍手を受けたのに、iPhone touch のアップグレードに関しては、「これから販売するiPod touchには無料で新しいアプリケーションがついて来るけど、既存のiPod touchに関しては20ドル」と、あっさりと流したことに妙な違和感を感じた人も、「Appleはセコい」と思った人も多いはずだ。 私も「アレ?」と思ったのだが、思いあたるフシがあったので、AppleのAnnual report を調べてみたところ、答えが見つかった。 エンロン・スキャンダル以来、厳しくなった米国の会計基準が理由

  • 「言論の自由」の大切さに関して一言

    民主党は18歳未満の若年者が犯罪に巻き込まれるのを防ぐため、インターネット上の違法・有害サイトの削除をプロバイダーなどに義務付ける法案の国会提出に向け、党内調整を始めた。自殺勧誘や、児童買春の温床とされる出会い系や児童ポルノなどに簡単にアクセスできないようにする狙い。与党との共同提出も視野に入れており、今月召集の通常国会での成立を目指す。 検討中の法案では、サイト開設者やプロバイダーは違法情報を発見し次第、削除しなくてはならないと規定。違法かどうか明確でなくとも、有害な恐れがある場合は児童が閲覧できなくなるような措置を講じるよう義務付ける。罰則を設けることも視野に入れる。 【NIKKEI NET(日経ネット):主要ニュース−各分野の重要ニュースを掲載より引用】 弾さんも指摘していたが、この民主党の発言は先進国の政党としては許しがたい発言。イギリスやアメリカなら法案どころか、それを臭わす発言