先日のエントリーに、「論理的に考える力のない人が、 『放射能は危険』→『原発は不要』→『脱原発』 となっているのは理解できます。 普通に論理的に考える力のある人は、 『脱原発したときのリスク』を考え、 脱原発をしないほうがよいのでは？という意見の方が多いと感じています。 中島さんのような方が、なぜ、脱原発一直線なのかが理解できません。 脱原発について書かれるのはよいのですが、 一度、なぜ脱原発を訴えているのか？についても、この場に書いていただけないでしょうか？」というコメントをいただいたので、今回はその質問に答えてみる。 実は、福島第一原発での事故の第一報を聞いた時に最初に私の頭に浮かんだことは、「この事故は、日本だけでなく、世界全体の原子力技術の発展に大きなブレーキをかける事になる。１０００年に一度の津波のためにたまたま起こった事故のために、日本のエネルギー政策を変更したり、原子力発電を
satoshiに関するsiroccoのブックマーク (52)
-
sirocco 2011/07/19
-
菅首相はなぜ色々と重要なことをとうとつに発表するのか？
ここのところ、浜岡原発の停止要請、ストレステスト、脱原発宣言、と色々と重要なことをとうとつに発表する菅首相。「党内の意思の統一ができていない」「政権維持のための人気取り」「思いつきで記者会見をしている」などの批判の声が多く聞かれるが、これに関しては、先日のテレビで古賀茂明氏（国民の負担を最小限にする東電の破綻処理の方法を提案した結果、退職勧告を受けてしまった経済産業省の人）がとても納得の出来る説明をしていたので（参照、参照）、私なりの解説をしてみる。 分かりやすく言えば、菅首相は東電（＝原発推進派）相手のオセロゲームをしているのである。脱原発の菅首相が白、あくまで原発推進の東電が黒。オセロ盤の外にいる国民の多くは白（つまり脱原発）を応援しているが、選挙の時以外は盤面の外にいるので何もできない。盤面の上には、電力会社と政治家はもちろんのこと、経産省の官僚、原子力関係の学者、経団連に属する大企
-
政府の初動の悪さが生んだ大量の被曝者
SPEEDIによるデータを公開しなかった理由は「パニックを恐れて」と聞いたが、SPEEDIによるデータをちゃんと利用せずに適切な避難指示を出さなかった国の責任は重い。 私の記録では、３０キロ圏外でも浪江町や飯舘村の一部では、３月１８日の時点で１５０μS/hという高い放射線が観測されていた（文部科学省発表の公式データ←【追記：URLを追加しました】）。当時、国は「ただちに健康に影響の出るレベルではない」と言っていたが、文科省が今回使った８時間屋外、１６時間屋内（屋外の４０％の放射線量）という数値を使って計算すれば、そのあたりに住む人たちは、妊婦や子供も含めて、３月１８日だけで２.２mSの外部被曝を受けていたという計算になる。 今は３０μS/h以下に下がっていることから考えると、その差（約１２０μS/h）は半減期の短い放射性ヨウ素からのものと考えて良いので、３号機から大量に放射性物質が放出され
-
エンジニアから見た原発
典型的な「理科系少年」として育った私にとっては、原子力発電は宇宙旅行や人工知能とならぶ「人類の英知を集めた科学技術の結晶」であり、あこがれでもあった。ブルーバックスの相対性理論に関する本はすべて読んだし、アインシュタインの書いた e=mc2 という式は私にとってはまさに「人類の英知」を象徴するシンボルであった。高校時代の前半までは、自分は物理学者になると確信していたぐらいだ。ひょんなきっかけからコンピューターの世界に足を踏み入れ、ソフトウェア・エンジニアとしての道を歩むことになったが、科学技術全般に対する情熱は今でも持っている。 そんな私なので、今までは当然のように「原子力発電」の支持者であった。資源の乏しい日本にとって「石油が不要で、二酸化炭素を放出しないクリーンな原子力発電」こそ日本にふさわしい発電方法であると信じていたし、自動車・エレクトロニクスに続く輸出産業としての原子力に期待もし
-
２０１１年はソシアル・アプリ元年か？Facebookユーザー向けグループウェアFruence
１１〜１２月にかけて、３本連続してGoogle App Engine上のアプリを作ったので、かなりDatastoreにも慣れて来たし、ライブラリも充実してきた。これならば、小さなアプリなら２〜３日で開発＋リリースする事も十分に可能だ。ということで、正月休みの間に「書き初め」として何か自分の日々の仕事の役に立つものを作ろうと思い立ったのが１日の夜。 そこでまず候補として思いついたのが、オンラインの「to-do リスト」サービス。ここのところ、本の執筆、雑誌のコラム、CloudReaders、neu.Notes、neu.Draw、neu.Annotate、neu.Journal と複数のプロジェクトに同時に関っているため、記憶やメモに頼って作業するのは不可能になって来た。そこで、どのデバイスからでも簡単にアクセスできる「オンライン to-do リスト」が欲しいと思ったのだ。 ただ、単なる「オン
-
Oracleの「Android訴訟」についてひと言
今日のこちら（米国西海岸）でのもっぱらの話題は、Oracleの「Android訴訟（詳細）」だが、これに関しては、私も含めて「やはり来たか」と見ている専門家は多い。 そもそも、スマートフォン以前の携帯電話用のJavaがプラットフォームとして成功しなかった理由の一つは、J2MEが根っこのところで、NTTドコモ独自のDoJaとモトローラ主導のMIDPに分岐してしまったことにあるし、同じJ2ME間でも実装の差異が大きく "write once, run everywhere" が机上の空論になってしまったことにある。Sunがちゃんとリーダーシップを発揮できなかったためである。 その意味では、J2ME/MIDPとコンパチビリティがなく、Sunから正式にJavaをライセンスしていないAndroidはけしからん、というのは（今はOracleの一部になった）Sunから見れば当然のこと。 「J2MEの時に
-
スタートダッシュ型仕事術：実践編
昨日書いた「『時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す』という働き方」というエントリー、Twitterやハテブでたくさんのフィードバックをいただいたが、その中で気になったものの一つが、「そうは言っても仕様がころころ変更になるからスタートダッシュで仕事をしていたら時間が無駄になる」というもの。 まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェアの宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャの大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたりまえ。 ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部分を一気に作って、早めに（仕様変更が必用かどうかの）見極めをする必用がある」という点。特に「作って見なければ分からない」部
-
ユーザーに尋ねても必ずしも正しい答えは返ってこない
今日はたまたま「ユーザーからのフィードバックを集めることの難しさ」が話題になったので、それに関連するエントリー。 もの作りにおいて、「ユーザーが何を必要としているか」を知ることは大切だが、だからと言ってユーザーに尋ねれば正しい答えが返ってくる訳ではないところが難しいところ。具体的な例としては、こんなものがある。 1. サイレント・マジョリティの声は聞こえてこない これはMicrosoftで実際にあったことだが、Outlookのチームではユーザーから寄せられる機能追加のリクエストに従って色々な機能を足していた時期があったが、その結果不必要な機能ばかり増えて、単純な作業が逆にやりにくくなってしまった（たとえばカスタム・フォームが良い例）。このケースでは、ごく一部のヘビー・ユーザーばかりが声がでかく、「今の機能で十分、これ以上複雑にしないで欲しい」というユーザーは何も言ってこない（こういう人たち
-
iPadアプリ作成日記: アプリ間の連携について一考察
CloudReadersというPDF/マンガリーダーを個人で、neu.Notesという手書きノートアプリをneu.Pen LLCを通して開発・リリースしている私だが、当然のようにその二つを組み合わせて「PDFの赤入れアプリ」を作って欲しいというユーザーからのリクエストは聞こえて来るし、私自身も欲しい。 これまで二つのプロトタイプを作っては見たのだが、どうも気に入らないのでリリースは見合わせている。 最初に作ったのは、CloudReadersに "Annotation Mode" (赤入れモード)を追加したバージョン。とりあえず赤入れが出来るところまでは三日ぐらいであっさりと動いたのだが、「シンプルでサクサク読める」ことを最優先に設計されているCloudReadersの場合、追加した書込みを常に表示するのかしないのかでかなりパフォーマンスに影響が出るし、「赤入れモード」という明示的なモードを
-
勝てば官軍、負ければガラパゴス
私が数年前からこのブログで使っている「ガラパゴス化」という言葉、今やテレビや雑誌でまで見る様になり、何だかうれしいような悲しいような、複雑な気持ちである。 私が最初に公の場でこの言葉を使ったのは、２００１年のCTIA（米国最大の携帯通信業界のカンファレンス）でのこと。UIEvolutionというベンチャー企業を立ち上げたばかりでもあり、この業界でなんとか注目を集めようと、「NTTドコモのiモードのことなら詳しいので、日本の若い人たちのライフスタイルがiモードでどう変わったからなら解説できるよ」と会議の主催者に連絡すると、いきなり２０００人も収容できる会場を割り当てられたのだ。 私がNTTドコモから来た人間だと勘違いした人もいたようで、会場は超満員。冒頭でドワンゴの「釣りバカ気分」の面白さを手振り身振りで伝えたところそれが大受けで、日本のギャルの生態系の解説も交えながら、日本の「ケータイ文化
-
iPadアプリ開発日誌：neu.Notes 1.2 は会議室でも使える！？
最近、CloudReadersと並行して力を入れて開発しているのが、手書きノート作成用の neu.Notes。1.1が致命的なバグを抱えていたために、すぐにアップデートをしていただいたユーザーにご迷惑をかけてしまい、大変申し訳ないことをしてしまった。被害を最小にするために、ストアから一度引っ込めておいたのだが、ようやくそのバグも取れ、1.2として仕切り直しのリリースである。今度は、1.0からも1.1からもきれいにデータを引き継げるように作ってあるので、ご安心いただきたい。 ちなみに、今回のアップデートには大小のさまざまな機能が含まれている。 １. 外部ディスプレー・サポート これは私自身が欲しかった機能だが、VGAアダプターでプロジェクターに繋ぐことにより、現在描画中のページをプロジェクターに表示するようにした。この機能を使えば、会議室におけるホワイトボード代わりに使うことができる。ホワイ
-
Life is beautiful: とある家電メーカーでの会話：クラウドテレビ編
ある日本の家電メーカーでの会話。まずは副社長室での会話から。 技術部長：副社長、来年度の予算の件はどうなりましたか 副社長：大丈夫だと言っただろう。台湾・中国からの追い上げは相変わらず激しいが、テレビは家電ビジネスの要だ、経営陣としてもここだけは手を抜けない。来年も君たちにがんばってもらわなければならない。 技術部長：もちろんです。そのあたりは現場のエンジニアたちも強く感じてると思います。ちなみに、メールに書いてあった「戦略の変更」って何ですか？ 副社長：そのことなんだが、経営会議でも持ち上がったんだが、台湾勢と戦うには、我が社にしかできない「差別化要因」が必要だ。価格競争では彼らにかなわない、消費者にとって目に見える価値を提供して、台湾製品よりも３割・４割増の値段でも喜んで買ってもらえるテレビを作らなければならない。私は、キーワードは「クラウド」だと思っている。 技術部長：え？「ク、クラ
-
Google App Engine入門：実践編
今週に入って、Tiny Message に続く二つ目の Google App Engine ベースのサービスをリリースした。３日ぐらいで試験的に作った Tiny Message とは異なり、今回のものは、丸二ヶ月間寝る間も惜しんで作った力作である。 米国向けのサービスな上に招待制のSNSなので、ここではサービスそのものは公開しないが、いくつかこだわって作った部分があるので、それについて語ってみようかと思う。 1. 対象となるユーザーの絞り込み FacebookやTwitterのような巨人が存在している中で、それにまっこうから対抗するようなソシアル・ネットワーク・サービスを作ったところで無謀なだけである。そこで、逆に対象にするユーザー層を究極にまで絞り込んで、彼らのライススタイルに徹底的にマッチしたサービスを作ることにより差別化をはかる、という戦略を選択。対象は「LAに住む２０〜３０代の社交
-
無名関数を使った非同期通信のススメ（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) その書きやすさのために、実務経験の
-
直感的なUIとhand-eye-cordinationの話
下のビデオは一歳度児がiPhoneのフォト・アルバムの機能を使っている姿を撮影したものだが、これを見ると「直感的なUI」とは、まさに人間が赤ん坊のうちにマスターする"hand eye cordination（目からフィードバックを受けながら手先を動かして物をコントロールする能力）"に合致したものなのだということが良く分かる。 【追記】参考までに、私が特に好きなUI関連の書物二冊へのリンクを張っておく。特に「誰のためのデザイン」はUIが単なるソフトウェアやウェブ・サイトのUIデザインの問題ではないことに目を開かせてくれる良書だ。 ・誰のためのデザイン?—認知科学者のデザイン原論 ・Envision Information
-
Google App Engine入門：実行効率を犠牲にせずに開発効率だけを上げるテクニック
一つ前の富豪プログラミングのエントリーともつながる話だが、Google App Engineは「ちゃんとスケーラビリティを考慮してアプリケーションを作るには何に気をつけなければならないか」を勉強するには絶好の環境だ。そこで今回は、その「ケチな大富豪的なプログラミング」の実践編。 Google App Engine上のアプリをいくつか書いているうちに、必要に迫られて自然発生的にできてきたのが、gdispatchという数十行のコードからなる小さなモジュール（ソースコードはgithubに置いてある）。これをGoogle App Engineに標準で付いて来るwebappと組み合わせてフレームワークとして使っている。 gdispatchを設計する上で重視したのは、 （１）Google App Engine上でのアプリの開発を効率化する上で「明らかにこれがあると開発効率が格段に向上する」というもの以
-
「リニアにスケールするように作れる」からこそのGoogle App Engine
Google App Engineを使った最初の作品 Tiny Message （http://tinymsg.appspot.com）をリリースしてまだ２０時間経っていないが、設計の過程でいろいろと学べたことがある。 その中でも一番収穫として大きいのは、「Google App Engineを使えば、リニアにスケールするサービスを作ることが可能」だということが実感できたこと。 もちろん、Google App Engine上に作ったからと言ってすべてのアプリがリニアにスケールするわけではなし、どんなアプリでもそう作れるわけではない。Entity Groupの構成を間違えればそこがボトルネックになるし、Queryの二重ループなんかを書いたら、すぐにタイムアウトしてしまう。 リニアなスケーラビリティを持つDatastoreの上で作るとは言え、やはりDatastoreの仕組みをちゃんと理解してデー
-
-
Tiny Message
Have you ever wondered if you could type more than 140 characters in your tweets? Tiny Message is the answer. Type whatever you want to type here (there is no 140 character limit), and click 'make my tweet' button below. We will generate a tweet for you.
-
Python Hack : 噛めば噛むほどおいしくなるクロージャの話
最近 JavaScript を書く機会が増えているが、それに従って自分のコーディングスタイルが少しづつだが変化してきているのが分かる。もともと「コードの読みやすさ」や「実行効率」にとことんこだわるタイプだが、（JavaやC++になくて）JavaScriptやRubyにあるクロージャや無名関数が私のコーディングスタイルにとてもマッチしているからだと思う。 簡単な例を紹介しよう。Pythonで書かれた config.py というモジュール。config.yamlという設定ファイルを読み込んで Dictionary として返す config.get() という関数。普通に実装すると、以下のような感じになる。 import yaml _config = None def get(): global _config if not _config: data = open('config.yaml')
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました