なぜ日本では「市民運動」が格好ワルイいのか？
原発事故以来、色々なことを考えているのだが、その一つが「なぜ日本では民意がなかなか反映されないのだろう」ということ。泊原発の再稼働容認が典型的な例。これだけ多くの人が反対しているのにも関らず（参照、参照）、必要だったはずのストレステストもなく、原子力安全委員会の形だけの二重チェック（参照）で北海道知事の再稼働容認となった。 「政治家が票集めで忙しくて実際に国を運営しているのは官僚」「官僚の業界への天下りが官民の癒着を生み出している」「マスコミはスポンサーに不利になることは報じない」などの政府やマスコミにも大きな問題があるが、国民側にも若干問題があると思う。うまく表現するのは難しいのだが、 政府は「お上」であり、市民運動とは「お上にたてつくこと」に相当する という江戸時代から続いているメンタリティが根っこのどこかにあるのではないかと思う。それが「市民運動＝左翼活動」というイメージを固定化させ
菅直人 vs. 経済産業省の戦いが壮絶になって来た
福島第一原発での事故以来、私も含めてあまり一般の人たちに知られていなかった数々の問題点が見えて来たわけだが、一番注目すべきなのは、今回の事故の、そして事故後の政府と東電の対応のていたらくの諸悪の根源は東電でも管政権でもなく、霞ヶ関の官僚たちだ、という事実である。 そもそも日本の原発を中核においたエネルギー政策は、米ソの冷戦時代に、日本国民の「反核」感情が「反米→共産主義」という方向に傾きかけたとき、米国が「毒をもって毒を制す」と読売新聞の正力松太郎を利用して日本の世論をコントロールして無理矢理押し付けたもの（参照）。「保守＝原発推進、革新＝反原発」という日本特有の図式が作られたのもその時期だ。 最初は政治指導で原発を押し進めて来た霞ヶ関の官僚たちは、少しづつ「天下りの甘い罠」に陥り、電力業界と癒着し、星の数ほどの「天下りのための原発関連法人」を作り、「いまさら原発を辞めたら自分たちの将来が
プラットフォームとして台頭して来た Facebook
週末はクリスマス休暇でロスに住む長男が遊びに来ていたのだが、金曜日の朝になって面白そうなFacebookユーザー向けのサービス案を提案して来たので、さっそく作ってみた。２４日にはクリスマスパーティもあったし、テニスも毎朝していたので、正味プログラミングをしていた時間は３０時間ぐらいしかなかったのだが、発案からわずか３日でサービスがローンチできてしまうとは（Google App EngineとFacebook APIのおかげ）、ずいぶんと便利な時代になったものだ。 日本ではまだまだだが、米国では人口の７割以上がアカウントを持つと言われるFacebook。Twitterでの不特定多数向けの「つぶやき」よりも、友達・知り合い間での「プライベートなコミュニケーション」向けのFacebookは、どちらかと言えばmixiに似ている。mixiとの根本的な違いは「大人も使っている」点。 特に最近は、「プラ
Covia、世界初のkoukouTV搭載地デジチューナー発売
iPad版のkoukouTVの紹介の際に、「本当の狙いはテレビ、セットトップボックス、車載機メーカーへのOEMビジネス」と書いたが、その第一弾がこれ。詳しくは、Coviaの製品ページを見ていただくのが一番良いと思うが、例の「実家に孫（の写真）を贈ろう」というコンセプトの元に作られたkoukouTVを搭載した地デジチューナーだ。 ちなみに、私がUIEvolutionを設立したのはちょうど１０年前。「これからは携帯電話に限らず、テレビ・カーナビ・冷蔵庫のドア・クレジットカードなどがネットに常時接続する時代になる。そんな時代に向けたソフトウェアとサービスを提供する会社」というビジョンで作った会社だが、１０年たった今でもようやくテレビとカーナビがネットに接続しはじめたばかりだ。冷蔵庫のドアやクレジットカードが常時接続しはじめるまでまだまだやることがありそうだ。 ということで、koukouTVのOE
プロトタイプ：AJAXで改良するフォーム入力
ここのところ、Google App Engine上でアプリを作っている私だが、iPhoneアプリとかを作り慣れている私としては、単純なHTMLページの組み合わせでUIを作るというのでは面白くない。そこで、サーバーがModel、クライアントがViewとControllerというアーキテクチャととことん追求してサービスを作っているのだが、そのためにはさまざまなUI部品を作らなければならず、そこにやたらと時間がかかっている。 始めた当初は、「今はオープンソースの時代だからUI部品もオープンなものを集めてくれば済む」と軽く思っていたのだが、実際に使おうとすると不必要に複雑だったり、汎用化されすぎていたりしてそのままでは使えないものが大半。結局のところ、そのまま使える品質のJavaScriptライブラリはjQueryのみで、それ以外は、（１）オープンなものを元にシンプルなものを作り直す、（２）スクラ
HTML5時代の「運営しやすいアーキテクチャ」の話
増井君と二人でPhotoShareというサービスを立ち上げてもう１５ヶ月になるが、いろいろと学んだことがある。その中でもつくづく思うのは、サービスを作り上げる段階よりも、運営のことを考えた設計が大切なこと。つまり、メンテナンスしやすい、テストしやすい、多少のミスをしても大丈夫、こまめなアップデートがしやすい、作業分担がしやすい、などなどである。 そんななかで強く感じるのは、「AJAXを見た目や使いやすさの面だけに利用するだけでなく、『運営しやすいサービス』を作るのに利用できないか」ということである。 私のイメージするアーキテクチャを図にするとこんな感じになる。 まず一番の特徴は、テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ（JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく（上の図で、CSS,
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
