渡辺謙のダボス会議での発言
渡辺謙のダボス会議でのスピーチ全文が、東京新聞のサイトに公開されている。 渡辺謙さん、ダボス会議でスピーチ 原子力からの転換訴える ”国は栄えて行くべきだ、経済や文明は発展していくべきだ、人は進化して行くべきだ。私たちはそうして前へ前へ進み、上を見上げて来ました。しかし度を超えた成長は無理を呼びます。日本には「足るを知る」という言葉があります。自分に必要な物を知っていると言う意味です。人間が一人生きて行く為の物質はそんなに多くないはずです。こんなに電気に頼らなくても人間は生きて行けるはずです。「原子力」という、人間が最後までコントロールできない物質に頼って生きて行く恐怖を味わった今、再生エネルギーに大きく舵を取らなければ、子供たちに未来を手渡すことはかなわないと感じています。” しごくまっとうな、地に足のついた発言である。こういう「まともな意見」がちゃんと政策が反映されていく国になって欲し
ある電力会社OBのインタビュー：エイプリルフール編
（このエントリーは、２０１１年のエイプリルフール向けのものであり、ここに書いてあることは、すべてフィクションなので誤解しないでいただきたい） 私：今日は、お忙しい中、インタビューの時間を使っていただきありがとうございます。 OB: 気にしなくてもいいよ。こっちは引退した身だし、家にいても原発のニュースばかり見ているだけだしね。 私：ありがとうございます。さっそくですが、福島第一での事故に関してどう思われますか？ OB： 正直言って、私が現役の時に起こらなくて良かったと胸をなで下ろしているところだよ。まだ臨界状態にはなっていないようだが、それを除けば「考えられる限り最悪の事態」だよ。 私：今回の事故に関しては「人災だ」という意見もあるようですが、どう思われますか？ OB：君も知ってると思うが、日本の原発は耐震性に関してだけ言えば世界一だよ。今回は、たまたま１０００年に一度の巨大津波が来て電源
google appengine に関してひと言
ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt
Life is beautiful: 「時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す」という働き方
かれこれ３０年以上もこの業界でプログラムを毎日のように書いて来た私。当然、自分なりの働き方のノウハウみたいなものも会得して来たつもりだ。以前ここに「私のとっておきのプログラミングスタイル」というエントリーを書いたので、まだ読んでいないプログラマーの方にはぜひとも読んでいただきたい。 ちなみに、そんな中でも後輩とか部下に教えるのが一番難しいのが、「スタートダッシュでできるだけはやくめどをつける」という仕事スタイル。どのエンジニアも、ちゃんと説明すればこの働き方の効用は理解してもらえるのだが、実際の現場でちゃんと実行できる人は１００人に１人もいない。 「人はみな怠惰だから、締め切りに迫られなければがんばれないんだ」と言ってしまえばそれまでだが、「まがりなりにもプロとして仕事をする限りは、ペース配分ぐらいはちゃんと考えて仕事をすべき」というのが私の主張。トップクラスのマラソンランナーでペース配分
Life is beautiful
「6年勤めたNTTを退職しました」という記事が、注目を浴びているようですが、この筆者が NTT を辞めた理由が、私が３２年前（１９８６年）に NTT を辞めた理由とあまり変わらないのに、少々驚きました。 私が NTT を辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたことがなかったので、これを機会に書くことにしました。普段ならメルマガ（週刊 Life is beautiful）の読者限定で書くところですが、今回だけは、出来るだけ多くの人に読んで欲しいので、ブログ記事として公開します。 当時、NTTは電電公社から民営化したばかりで、１９８５年に入社した私は、NTTとしては第１期生でした。大学は、早稲田の理工学部電子通信学科で、修士課程まで行きました（当時は、情報学科はまだ独立しておらず、電子通信学科がソフトウェアとハードウェアの両方をカバーしていました）。
iPadアプリ作成日誌: Apple に Submit しました
先日予告した「クラウド本棚付きeBook Reader」（正式名称はCloud Readers）、予定通りに開発も終わり、 Apple に Submit することができたのでここに報告させていただく（現在、Appleによる審査中）。前のエントリーでも書いたが、これは私自身がiPhoneで主にマンガを読むために自分用に作ったマンガリーダー（非売品）をiPad用に改造したもの。１年近くもの間、細かなところで微調整を繰り返して作り込んで来たものなので、満足していただけると思う。 一つだけ不安なのが、リリース前に実機でのテストができなかったこと。本来ならば、iPad上で私自身がしばらく使い込んで微調整を繰り返してからリリースするべきなのだが、「iPadアプリストアのグランド・オープニングに自分の作品を並べたい」という欲求には勝てず、エミュレータでのテストに頼らなければならなかったのが残念。 もう一
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
無名関数を使った非同期通信のススメ（JavaScript）
ここ最近はブラウザーの上で動く思いっきりRIAなアプリケーションを書いている私。こと通信の部分になると JavaScript での開発効率が、C++/Java/Objective Cなどと比べて格段に高いことをつくづく感じている毎日なので、今日は、そのあたりを少し解説してみようかと思う。 サーバーのAPIにアクセスするプログラムを書く方法は色々とあるが、「サーバー上の特定のURLにHTTPでアクセスして結果をXMLやHTMLやJSONで受け取る」というケースに限定すれば、基本的に３つのパターンに分けられる。 1. 同期通信 result = urlfetch.fetch("http://www.google.com/") if result.status_code == 200: doSomethingWithResult(result.content) その書きやすさのために、実務経験の
Twitterの有効な使い方、その１
ブログに関しては、Early Adaptorとして早くから有効に使わせていただいている私だが（このブログを始めたのは２００４年、その前にも一つ別のところにブログを書いていた）、Twitterに関しては「どうもいまいちピンと来ない」というのが正直な感想。 今年に入ってからメディアに異常なほどにもてはやされていたTwitterも、「Twitter is a Fad - Business Week」、「セカンドライフとTwitter」など、「Twitterは一時的な熱狂にすぎない。セカンドライフと同じ道をたどるんじゃないか」という冷めた意見も多く見られるようになった。 私自身もPhotoShareからの連携で写真へのリンクを自動投稿する以外はほとんどアクセスしなくなってしまっていたのだが、今回、開発者向けのあるウェブサービスをリリースすることになり、Twitterが有効に使えるケースがあることに
「官僚たちの夏」と「ガラパゴス携帯」と
知り合いの勧めで録画したままにしてあった「官僚たちの夏」を今になって見ている私だが、あのドラマを単純に「なぜ戦後の日本はあれほどの急成長をとげたのか」という視点から見るだけでなく、「その同じ日本でなぜガラパゴス携帯ができてしまったのか」を考えながら見るとより面白い。 「今の官僚や企業が（あのころの官僚や企業とくらべて）だらしないから」という見方もあるかも知れないが、私としては「そもそも官僚主導の産業政策が今の時代に合わなくなっている」と見る方が正解に近いように思える。 もちろん、その場その場で異なる状況があるので、あまりに単純化して見るのは危険だが、少なくともアナログ方式からデジタル方式に移行した2Gケータイの時代に霞ヶ関主導で「モトローラやノキアなどの海外メーカーに席巻されることを嫌い、あえて日本独自の方式を採用して国内の携帯機器産業を保護・育成しようとした」ことは歴然とした事実である。
PhotoShare の Atom/JSON/JSONP Feed の正式発表
PhotoShareの写真のFeedに関しては、少し前に実装が完了していたのだが、「サンプルをきちんと整えてから」などと考えているといつまでたっても発表できないので、とりあえずFeedのURLのみ発表してしまうことにした。 PhotoShareの場合、ユーザーごとにユニークなIDが当てはめられている。iPhone上のPhotoShareからメアドを登録後に通常のブラウザーからログインして、"My Photo"を開いた時にURLバーに表示されるURLの最後の部分がそれだ。例えば私の場合、それが"http://www.bcphotoshare.com/photos/67"なので、"67"がユーザーIDとなる。
GoogleのAndroid向けのアプリビジネスはなぜ魅力的ではないか？
PhotoShareをiPhone向けに提供して早くも一年になるが、もっとも良く投げかけられる質問は「PhotoShareはAndroidとかの他のプラットフォームに移植しないの？」というものだ。 少し前までは、「まだiPhone以外のビジネスが十分に大きくないから今はまだ早い」、「iPhone上でやるべきことはまだ沢山あるから」、などと答えて来たのだが、最近は少し見方が変わってきた。 今の勢いでHTML5が進化・浸透してくれるのであれば、わざわざ移植コストをかけてAndroidやWindows Mobile向けにネーティブ・アプリを開発するよりは、少なくともUIの部分をすべてHTML+Javascriptにまかせたアーキテクチャでのインタラクティブなアプリの開発というのも十分に可能性があるように思えてきたのだ。 この「HTML+Javascriptですべて出来るじゃん」という発想は、そも
私がブログを書くときに意識していること
１．とにかく分かりやすく書くこと ２．難しい言葉の使用をできるだけ避けること ３．何を伝えたいのかはっきりと意識して書くこと ４．伝えたいことをできるだけ一つに絞ること ５．視点・立ち位置がぶれないようにすること ６．一つのエントリーをあまり長くしないこと ７．できるだけ明るく・ポジティブに表現すること ８．ユーモアを交えること ９．無理せずに自然にまかせて書くこと １０．既存の枠組みにとらわれずに書くこと 糸井重里の「ボキャブラリーというのは『どれだけむずかしい言葉を知っているか』ではなく、『どれだけやさしい（人に伝わりやすい）言葉を知っているか』という意味なんです」という言葉は本当に正しいと思う。 どんな文章にも言えることだが、分かりやすくなければ読んでもらえないし伝わらない。せっかくブログを書くのだから、読んでもらいたいし伝えたい。それがブログの「おもてなし」。 【同時に読んでいただ
「戦略的OS」の開発がことごとく失敗している点に関する一考察
９０年代にIBM、Microsoft、Apple各社が巨額の開発費を投じて作っていた「戦略的OS」がすべて失敗してしまったことを皆さんはご存知だろうか？ IBMが作っていたのはOS/2。元々はMicrosoftとの共同開発だったが、途中で仲違いをしてしまい、最後はIBMだけが細々とサポートしていたことすら覚えていない人が多いとは思うが、Windows95の成功であっというまに市場から消えてしまったのがOS/2。具体的な数値は公開されていないので分からないが、両社が数百人体制で数年間開発していたので、少なく見積もっても日本円で数百億円は投じられたことは間違いない。 Cairoの方は私自身が初期のころにいたこともあるし、最終的には「Chicago(Windows95のプロジェクト名) vs. Cairo」の戦いの最前線にいた私としては知りすぎている点も多いのだが、一つだけ確かなのは、プロジェク
Life is beautiful: Amazon AffiliateがGoogle AdSenseに勝てる理由
今まで、このブログでも何回もGoogleとMicrosoftを比較して、Googleにばかり軍配を上げてきた私だが、Googleに弱点が全く無いと思っているかというと決してそんなことはない。そこで、今日はこのブログでも採用しているAmazon AffiliateとGoogle AdSenseとを比較した場合、どうして私が「長い目で見たらAmazon Affiliateの方が強いかも知れない」と思っているかを述べてみたい。 まずは、このブログでの過去数ヶ月の実データを元に、Amazon Affiliateの結果をまとめると以下のようになる。 ・測定単位： 10万ページビュー ・クリック数： 約2500クリック ・注文数： 約150点 ・アマゾンの売り上げ： 約25万円 ・紹介料： 約1万５千円 まあ妥当な数値である。クリック率は約2.5%。クリックから実際の注文へのコンバージョン率は約6%で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
iTunesストアで酒井法子の曲が売れている件について