2011年11月13日日曜日

GoogleドキュメントHTMLタグ編集オワタ:GoogleのWeb標準意識の低さ

以前Googleドキュメントは使えないHTMLタグがあって不便という旨の記事を書きましたが、いつの間にか新しくなったGoogleドキュメントではHTMLによる編集機能はなくなったようです。いやはや残念。

Google ドキュメントの新バージョン - Google ドキュメント ヘルプ

その他の変更点

Google ドキュメントの旧バージョンの機能の一部がご利用いただけなくなっていますが、間もなく追加いたしますのでご安心ください。

ただし、Google ドキュメントの旧バージョンの次の機能は、新しいバージョンではご利用いただけません。

  • Google Gears によるドキュメントへのオフライン アクセス
  • HTML の編集
  • CSS の編集

前から思っていましたが、GoogleってWeb標準が嫌いなんですかね?(そんな事はないと信じたいですが…) このBlogを書いているBloggerも、Google Sitesも、改行を勝手に<br>に書き換えようとするし(しかも<br/>じゃなくて<br>)。Google Sitesには昔のGoogleドキュメント同様HTMLタグの制限があるし。CSSは使えないし。Google+のストリームでもHTMLタグ使えないし。

天下のGoogle様がそれでいいのか!もっとXHTML的なコードを吐いてくれ。そして使わせてくれ。ローカルで編集するものならともかく、Webに公開する文書は標準的なHTMLにしましょうよ。意味を主にしたデザインみたいなので書けるとなお嬉しい(なかなか出ないねこういうの)

一Google信者からのお願いでした。

2011年11月6日日曜日

[情弱注意]弊社のメール誤送信防止施策

私は情弱な会社に務めています。

そんな弊社で、近年メール誤送信によるセキュリティ事故(情報漏えい等)が頻発しているということで、メール誤送信防止策が打たれました。とても個性的な施策なので全世界に展開しようと思います。

今までのメール送信

今までは誰がどこにメールを送ろうが、メールの宛先に特別な制限はない。

今まではメールの送り主が社員だろうが協力会社社員(以下ベンダ)だろうが、社内へ送ろうが社外へ送ろうが、特に制限なく送れました。なお、ここでいうベンダさんとは、弊社に派遣されていて、弊社のPCを使って業務を行う人のことを指します。

メール誤送信防止策実施後のメール送信

今後はベンダさんが社外にメールを送信するときは、社員のメアドをCCに入れることが必須になる。

施策実施後は、社員のメール送信は今までと変わりませんが、ベンダさんが社外へメールを送信するときは、社員のメアドをCCに追加することが必須になります。なおCCの追加は手動です。将来的に、社員へのCC付与のないベンダアドレスからのメールは、メールサーバで遮断される予定のようです。この施策により、ベンダさんが社外へメールを出す時は社員にも見られるんだということによる緊張感が生まれ、誤送信が防げるというものです。とても前衛的な施策ですね。

ちなみに、「普段からCCにML付けててそこに社員も含まれているから変わらなくね?」と思ったあなた、ダメです。CCに社員の個人アドレスが必要です。きっとメールサーバ側でMLのメンバ確認なんて高度な技は使えないんでしょうね、管理者が。

施策による問題

社外へのメールは例外なくCC追加が必須なため、ベンダさんが自社へするメールも社員が見られることになる。

「ベンダさんが社外へ送るメールは例外なくCC付与」なので、ベンダさんが自社へ連絡するためのメールにも社員のCCを付けます。結果として、ベンダさんがベンダさんの自社とやりとりしているメールが社員に見えてしまいます。しかしそこは、見られたくない内容は添付ファイルにして暗号化する等の対策が取れるため問題ありません。

社内の反応

「これ考えた奴死ねよ」こんな意見が一般的です。どこからどう見ても完全情弱企業です。本当にありがとうございました。

こんなクズ施策にいちいち文句つけるのもあほらしいですが、そもそも誤送信防止になっていない。メール送るときにCCで確認するからって、目で確認するからOKならそもそも誤送信問題なんて発生しないだろうが。メール作るときは返信やテンプレから作るから手で追加なんてほとんどしないし。そして業務形態によらず社内一斉に適用するのもおかしい。百歩譲ってMLに社員が含まれる場合はCC付与不要にすべき。でないとCC付けられた社員はメールが2通届くことになる。無駄だろ。

メール誤送信の完全撤廃は確かに難しい課題ではあるが、本気でやるならメールサーバに機能追加して、添付ファイルの自動暗号化(複合方法は予め送信先と決めておく)等の施策にするべきだと思う(特別な仕組みではなく、お客様ごとにパスワードを定める等でよい)。そこまでやらないにしても、送信者、宛先のドメインによって、NGワードを定めたり、送信先を限定したり、有効な手は色々考えられる。が、いずれもメールサーバに機能追加が必要なため、弊社のメール管理者では実施不可となるんだろう。

今回実施されたゴミ施策は、社員の誰もがメール誤送信防止の観点では何の意味もなく、ただベンダさんに余計な手間を増やすもの という認識を持っていると思いますが、弊社のようなアレな組織は、一度打ち出されたセキュリティ対策の施策は、それを上回る施策を閃かない限り廃止されません。大切なのは「上回る」です。他の観点の施策ではただプラスされるだけで、今回の施策がなくなることありません。きっとメールサーバ側に手が入っても「クライアント側の施策は継続」とかになるんでしょうね。

情弱は一刻も早くこの世から消えて欲しいものです(会社がなくなるのは困りますが…)。

弊社のその他のメール誤送信防止施策

今回のあまりにひどい施策以外にも、今まで幾つかの施策が適用されていますので紹介します。

  • メーリングリストの適正化:MLのメンバを社員とベンダで分ける施策が打たれています。この施策により、社員のみに展開する情報をベンダ込のMLに送ってしまい、ベンダに見られてしまう恐れがなくなるはずです。代わりに同じ情報を共有する場合でも社員用MLとベンダ用MLの両方にメールを送る必要が生まれますが。
  • メーラーのメアド自動補完機能の停止:「メールの誤送信はメーラーのメアド自動補完機能により、想定外の宛先が追加されることにより起こる」という仮定(前提)の元打たれた施策。アドレス帳から手で選択すれば誤送信は無くせるはずです。
  • メーラーとそのアドオンの統一:社内のメーラーはThunderbirdに統一されました。理由は忘れました。アドオンとしてcheck and sendKeyword HighlightConfirmed-Addressがあります。なお、他のアドオンを入れることは許されています。
Posted by Picasa

2011年10月31日月曜日

MVVMでApplicationCommandsのコマンドを使うには?

WPFの定義済みコマンドを使用する方法

WPFには、一般的に使えそうなコマンドを定義したApplicationCommandsクラスがあります。ここにCopyPasteOpenみたいなコマンドが揃っています(同じようなクラスにMediaCommands、NavigationCommands、ComponentCommands、EditingCommandsってのがあります。詳しくは[MSDN]コマンド実行の概要参照)。

ここに定義されているのはRoutedCommandなので、コマンドを実行するコントロール(CommandSource)と処理するコントロール(CommandTarget)を別にすることができるみたい。具体的には、処理するコントロールにCommandBindingを設定すればいいみたい。以下はApplicationCommands.OpenButtonで実行してWindowで処理するイメージとXAML例。

 
<Window>
  (中略)
  <Window.CommandBinding>
    <CommandBinding Command="Open" Executed="DoOpen" />
  </Window.CommandBinding>
  <Grid>
    <Border>
      <Button Command="Open" Content="Open" />
    </Border>
  </Grid>
</Window>
(検証してないので動くかどうかは不明・・・)

DoOpenはViewModel出定義したコマンドのExecutedイベントハンドラ。つまりViewModelが処理用のメソッドを公開すれば、ViewModelでコマンドの処理を実装できるってこと。実際にコマンドが実行されると↓みたいな流れでDoOpenが呼ばれる(多分)。

 

これでApplicationCommandsの定義済みコマンドを使うことが出来ました。

MVVMにおけるCommandBindingの問題点

でもこれMVVMでやっちゃダメだよね。

なんでって、CommandBindingExecutedイベントのイベントハンドラ(ExecutedRoutedEventHandler)の定義って↓でしょ。

public delegate void ExecutedRoutedEventHandler (
 Object sender,
 ExecutedRoutedEventArgs e
)

これのsenderって、コマンドを実行したコントロール(CommandSource)が入るんですよね。そんなものViewModelに渡しちゃダメですよね? ViewModelがコントロールなんて受け取った日には、ViewとViewModel分けた意味がなくなってしまうので。

そこで問題だ。CommandBindingを使わずにどうやってApplicationCommandsのコマンドを使うか?

3択―ひとつだけ選びなさい

  • 答え①ハンサムな私は突如CommandBindingを使わないアイデアをひらめく
  • 答え②Microsoftが新しいクラスを提供してくれる
  • 答え③使えない。現実は非情である。

答え②に○を付けたいが、MicrosoftはMVVM関連ではBehaviorが最近入ったばかり、新たに追加クラスを提供してくれることは期待できない。

やはり答えは……………①しかねえようだ!

全部独自コマンドにすれば問題ないけど、やっぱりOpenとかNewとかは標準で定義されているコマンドを使いたいよね。Trigger&ActionBehavior使って、パラメータ渡さないメソッドにバインディングするような仕組みを作るか。あ、でもドラッグアンドドロップの時どうしよう。。。Object型のパラメータは有りにするか。でもそもそもViewModelが公開していいのはプロパティとコマンドだけだよね。。。メソッドを公開するという仕組み自体がダメか。。。イベントハンドラ付きのプロパティ定義する?でもそれって独自コマンド定義するのとあんまり変わらないような。。。。。。。。。。。

「答え-③ 答え③ 答え③」

どうしたもんかなー

参考

Posted by Picasa

2011年10月22日土曜日

MVVMを図にしてみた

MVVMに則ったクラスの機能分担
ユーザ入力によるイベント発生時の動作
Modelの処理中にプロパティ変更イベントが発生した場合の動作

最近真面目にプログラム書いてるので久々の更新。

WPFで書くにはMVVMというデザインパターン(?)で書くのが定説らしい。で、色々調べてみましたが、MVVM人気ないんですかね。要る要らないとかの宗教論争が多いです。要るか要らないかは使う側が考えるから、提供側はバシッと情報提供頼むよ(To マイクロソフト)。提供元がフラフラしてるからMVVMの考え方もフラフラしてるみたい。その辺は追々書いてみます(やる気の神が降りてきたら…)。

で、勉強も兼ねてMVVMの役割分担を図にしてみました。合ってるかどうかは不明。合ってなくてもいいんだ。まだ考え方がフラフラしてるんだし。MVVMは基本的に3つのクラスで構成されます。VMを複数のクラスに分けたりVを入れ替えたりするかもしれませんが、考え方的にはM-V-VMの3つ。適当に解釈してこれらの役割を書くと以下のとおり。

  • Model: 目に見えない処理をするクラス
  • View: 目に見える処理するクラス
  • ViewModel: Modelを目に見える形に変換するクラス

語弊がありすぎる気がしますが、細かく書くときりがないのでこの程度に。なおViewは目に見える処理しか行わないので、基本的にはXAMLだけ記述することになります。だけどXAMLだけでは書き切れない処理はコードビハインドと言ってC#で書いてもいいそうです。もっとも、コードビハインドの是非こそがMVVMの最大の争点な気もしますけど。その辺はおいおい(やる気の神がry)

図はModel、ViewModel、Viewが横並びになっていますが、ModelはViewModelやViewを気にする必要はありません。ViewModelもViewを意識する必要はありません。「全く意識しないわけではない」と説明されることもありますが、ありません。あってはならないのです。多分ないです。その説明は追々(やる気のry)。MVVMは各クラスで役割分担を明確にするために用いられるため、不要な参照はしません。ViewModelがViewを全く知らなくても成り立ってしまうなんて。マイクロソフトに、そしてデータバインディングに感謝。

ViewModelはModelのインスタンスを、ViewはViewModelのインスタンスを持ちます。なお、図には書いていませんがViewModelが持つModelのインスタンスは非公開ですのでお間違いなく。ViewがModelを触れるなんてことはありません。また、ViewModelもプロパティとコマンドしか公開しないので、ViewがViewModelを操作することもできません。Viewは飽くまでも表示だけです。

で、MVVMにすると何がいいのかってことですが、言わなきゃわからん奴は使わなくていいよ。データバインドとコマンドバインドのおかげで表示部(View)と演算部(ModelとひょっとしたらViewModel)を完全に分離できてるんだぞ。View取り替えるだけで表示部を変えられるなんてステキじゃないか。

VはMやVMと切り離されている(灰色は壁です)ので、V1をV2に取り替えてもOK(V2も同じVMに対応している前提)

「そんなのデータテンプレートでもできるだろ?」って思ったあなた、Viewを完全に独立させるには↓みたいにイベントハンドラ内でViewを参照してはダメなんですが大丈夫でしょうか。

public void button1_Click(object sender, EventArgs e)
{
  // ボタンが押されたらTextBox1の文字列で検索実行
  string word = TextBox1.Text; // ←TextBox1というViewの名前を使用しているのでMVVM的にはNG
  this.search(word);
}

「イベントハンドラでViewの値取れないとか無理ゲーじゃね?」と思ったあなた、そもそもその発想がMVVM的ではないのですよ。MVVMではModelが演算データの原本で、ViewModelが表示データの原本なんですよ。Viewはそれを表示してるだけなんだから、ViewModel(=コマンド規定側≒イベントハンドラ側)にはコマンド(≒イベント)を処理するためのデータは全てあるのですよ。なきゃおかしいのです。

「じゃあウィンドウの状態とかドラッグアンドドロップされたファイルのパスみたいにView操作契機で生じるデータ知りたいときどうするの?」と思ったあなた、長くなるので続きはまた今度(やる気がry)。端的に言うとTriggerやらActionやらBehaviorやらMessengerやらを使うとなんでもできるらしいです。

で、このTrigger、Action、Behavior、MessengerがMVVMの気に食わないところなんですよね。せっかくの美しいMVVMの概念をややこしくしている気がして。

久々の長文だったから疲れた。

Posted by Picasa

2011年5月10日火曜日

GWの計画と実績

まず今年のGWは、家中の掃除を片付ける。これで気持ちがすっきりする。

次に休み明けに作る予定の資料作成を終わらせる。もはや休み明けを恐れることもない。

そして最後に、情報処理試験の勉強とお絵描きを両立させて過ごすと予告しよう。

なるほど、完璧な作戦っすね。

不可能だという点に目をつぶればよぉ~~

几帳面な性格でねーーー
この順番に必ず、やると言ったらやる!
これが予告だ!

え、もうGW終わったの?

Posted by Picasa

2011年4月24日日曜日

[何でも比較] 原発データのCSV提供から考える、データ公開フォーマット

東電のWebサイトに原発の情報がPDFでアップされていましたが、最近はCSVで提供されているようです。

  • 東電のページ: 東日本大震災後の福島第一・第二原子力発電所の状況
  • 本日は「提供するフォーマットとしてCSVを選んだこと」について考察します。

    世の中にはデータを提供するフォーマットとして考えられるのは、今回の採用されたCSV以外に以下のものが考えられます。

    • プレーンテキスト(txt)
    • Excelファイル(xls, xlsx)
    • OpenOffice.orgファイル(ods)
    • HTML
    • XML
    • データベースで使用するファイルフォーマット(db, sqlite3)

    それぞれについてメリット・デメリットを考えてみます。この際、提供者側の手間は考えないものとします。

    フォーマット毎のメリット・デメリット
    フォーマットメリットデメリット
    txt100%読める。読み出しアプリを特別用意する必要がない。ブラウザでも見られる。閲覧側で整形しづらい。データとして扱うのが面倒。
    cvs頑張ればテキストとしても読める。様々なアプリでも読め、そこから他のフォーマットへの変換も容易。表として閲覧するためにはExcel等のアプリがないときつい。
    xls, xlsx広く普及しているので多くの環境で閲覧できることが期待できる。表計算やグラフ化が容易。OpenOffice.orgでも開けないことはない。フォーマットが公開されているとは言え、Excelがないと実質閲覧できない。
    ods表計算やグラフ化が容易。結構色んなアプリでサポートされている。開けるアプリを持っているユーザは少ない。情弱は間違い無く開けない。
    htm, htmlブラウザでそのまま開けるため、ほぼ100%閲覧環境が用意できる。表の形で表示可能。データとして扱うのが困難。
    xmlXSLを一緒に公開すれば、様々な形に変換可能。閲覧者側でも(頑張れば)任意の整形が可能。気合を入れればテキストとしても…(いやムリだな)。XMLファイルだけ渡されてもどうしようもない。情弱は間違い無く開けない。
    db, sqlite3情報の蓄積、検索が容易。巨大なデータでも扱える。閲覧できるアプリを用意することが結構困難。

    そして各フォーマットの特徴をまとめるとだいたいこうなります↓

    各フォーマットの特徴
    フォーマット 閲覧環境の用意のしやすさ データ整形のしやすさ 複数テーブル 巨大なデータ 総合
    txt ××4
    csv ×5
    xls, xlsx 8
    ods ×7
    htm, html ×6
    xml ×4
    db, sqlite3 ×7

    比較してみた感想

    こうやってみるとCSVって微妙に見えますね。。。ですが大事なのは、閲覧性とデータ整形のしやすさを兼ね備えたフォーマットは今のところCSVしかないということです。プログラマ的にはXMLの方が柔軟性は高いんですが、情弱を含めた一般の人が見ることを考えると、CSVやExcel形式の方が汎用性は高いんでしょうね。MS-Office持ってない人間を切り捨てていいなら、いっそExcel形式で公開した方が見る側には楽なのかもしれませんね。っていうかCSVで公開してもどうせExcelで変換して見るんでしょうし。

    データサイズについて

    ところで今回の比較には「データサイズ」というものを考慮していません。経産省やLASDEC容量が大きいファイルがサーバーや回線を圧迫しないようにすることを1つの目的として重要情報はPDFやExcelではなくHTMLやCSVで公開するように呼びかけていますが、データは圧縮すればいいわけですので、重要な問題ではありません。そもそもPDFやExcelのせいで回線圧迫が頻発って通信キャリアの問題じゃないんでしょうか?PDFをJPGに変換しろと言っていますが逆にファイルサイズでかくなるんじゃないでしょうか?複数枚のPDFならその枚数分JPG変換するんでしょうか?1分1秒を争うものも多々あると言っていますが、そもそもデータの公開時期自体が数日遅れてなので気にするオーダーではありません。見当違いな呼びかけは止めて頂きたいものです。

    ケータイでの閲覧

    LASDECの呼びかけではHTML,CSVでデータを提供するもう1つの目的として、ケータイでの閲覧を挙げていますが、ケータイでのCSV閲覧なんて嫌がらせ以外の何者でもありません。そもそもガラケーを含めたケータイでの閲覧をサポートを考慮するならテキストとHTML以外の選択肢はなくなります。データサイズを気にするのであれば、ケータイからのアクセスはテキスト、PCやスマートフォンはHTML、とサーバ側で振り分ければいいだけの話です。見当違いな呼びかけはry

    今回の選択と今後の選択

    しかし悲しい現実ですね。たかがデータテーブル1つ公開するにしても、選択肢がこんなもんしかないとは。結局Excel必須ですか。マイクロソフトはExcelファイルを閲覧するためのExcel Viewerを無料で公開していますので、お金のない人でも手軽に 閲覧できます。ですが、サードパーティから手軽な閲覧編集ソフトが出ないんですよね(OpenOffice.orgは手軽にという条件に反しています)。一方Web上での閲覧手段としてGoogle Documentがあるので一昔前に比べればだいぶ選択肢は広がりました。Excelも2007以降はXML+ZIP圧縮のxlsx形式になっているので、今後は閲覧できるアプリが出てくるかもしれません(需要ないかなー)。

    ファイルフォーマットとその閲覧に関する議論はいつの時代にもあるものですが、画像に関してはアプリ側が何にでも対応できるようになっていくことで対応してきました(実質jpg, png, bmpの3種なのでブラウザでも事足りる)。動画に関してはまだまだ勢力争いが盛んでありますが、こちらもアプリ側での対応が柔軟であることと、Web上でもFlashによるプレイヤで対応しています(WebMとかH.264とかはry)。

    しかしデータファイルというのはちょっと特殊で、その場で閲覧するだけでなく、計算したり並び替えたりグラフ化したり比較したりと、ユーザが欲しがる閲覧形態が多数あります。ですので、画像や動画のように「表示できればよい」というものではないのです。ここら辺をうまくカバーしたフォーマット、アプリが普及しない限りExcelの土俵はまだまだ崩れないでしょう(というかその辺を見事にカバーしているのがExcelなんですけどね)。

    今回の一件ではCSVが採択されたわけですが、これは最適な選択ではなく、少ない選択肢から選んだ最善の選択である、という点に注意しなければなりません。

    参考記事

    2011年4月16日土曜日

    「カスタムアクションのVBScriptランタイムにアクセスできませんでした」エラーの対処方法

    EIZO ScreenSlicerがなんか重い→アップデートしよう→インストールで記事名エラーorz

    ググリまくったところ、以下のコマンドプロンプトを管理者として実行し、vbscript.dllを再登録すれば問題ないらしい。

    C:\windows\system32>regsvr32 -u vbscript.dll
    
    C:\windows\system32>regsvr32 vbscript.dll
    

    でもそれでもダメで、更にググリまくったところ以下の記事でレジストリエントリ消せとあった。

    HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{ B54F3741-5B07-11CF-A4B0-00AA004A55E8}
    

    なんとかインストール成功!

    でもEIZO ScreenSlicerが重いのは変わらずorz

    2011年4月6日水曜日

    東京都知事選立候補者のまとめ

    東京都知事選が来週の日曜(4/10)に迫っています。地震があったので誰が立候補するのかバタバタしましたが、全部で11人になったようです。

    時間がなくてなかなか政見放送全部を見るのは難しい、という人のために、まとめてみました。参考にしてください。

    名前概要
    谷山 ゆうじろう無所属(映画監督)。選挙運動では自転車を使う。ガソリンは一滴も使わない。被災地へオリンピック資金を含む1兆円を支援。9つの政策
    ふるかわ 圭吾無所属(会社役員)。外国人の土地購入規制。在日の通名禁止。パチンコの換金完全撤廃。外国人に都発行の身分証携行義務化。東京オリンピック、築地市場移転反対。豊洲カジノ。新銀行東京廃業。青少年健全育成条例見直し。※「清き一票」のお願いはしない。お願いするのは皆さんだ。
    わたなべ 美樹無所属(会社経営)。都のサービス満足度向上。省エネ分野で世界をリード。中小零細商店街等の支援。観光業(築地、大相撲)。経費削減。被災地へ1000億支援、10万人受入れ。24時間365日都民一筋の都政を行う。
    石原 慎太郎無所属(東京都知事)。震災復旧/防災対策。青少年保護条例継続。※政見放送では今までの実績についての説明が多い。
    ドクター・中松無所属(国際想像学者)。完全災害防備都市。自分は地震、津波、原子力、新エネルギーのプロ。先進国中最も安い税金。東京を世界の金融・教育センター。長寿者の激励。
    マック 赤坂スマイル党(財団法人会長)。10度!、20度!!、30度!!!
    東国原 英夫無所属(無職)。テーマ「強い東京、優しい東京、元気な東京、東京から日本復活」(※政見放送は精神論のみ。具体的な政策はマニフェスト参照)。
    小池 あきら無所属(政党役員)。築地移転白紙化。原発脱却。医療介護の立て直し。都立病院復活。4年で特養老人ホーム15,000人分、保育園20,000人分増。国民健康保険料引き下げ、18歳までと75歳以上の医療費無料。中小企業支援。30人学級。オリンピック費用を防災に割り当て。
    姫治 けんじ平和党核兵器廃絶平和運動(建物管理業)。都予算25%削減、20%を国の財政破綻対策、5%を少子化対策。地震水害対策強化。機会平等再チャレンジ応援制度。緑地・自然環境保全。知事・区議らの報酬削減。築地市場の再検討。ゴミ有効活用再検討。スカイツリー傍に慰霊堂建立。姉妹都市の拡充。核兵器廃絶平和運動自治体宣言、憲法改新推進自治体宣言
    おがみ おさむ東京維新の会(僧侶)。オリンピック誘致反対。都議会議員、区議会議員の報酬削減。都民税10%削減。都内の食品の消費税を0%にする。無駄な建物撤廃。赤信号時の左折許可。待機児童0対策。町工場の活性化。
    杉田 健新しい日本(政治団体代表幹事)。震災復興に全力。危機管理体制の総見直し。教育、福祉の拡充。ワンコインサポート制度電磁波発生装置の撤去

    以下ちょっと私見が入った感想。

    まずさ、党派無所属ってのやめようよ。小池あきらってもろ共産党なのに、無所属で出るてるのは党の名前が邪魔ってことでしょう。それに民主党支持者が誰なのか分からなくなってしまいます(今回は民主党の人はいないそうですが)。まーざっくりと投票対象ふるいにかける際はこの党派は重宝するんですけどね。

    あと政見放送で震災への憂いを言うのもやめてほしい。ただでさえ候補者がどんな人間か知ることが難しいのに。そういうのは他でやってください。加えてほとんどが防災の話中心。本当にそれが現在の都政の中心的な問題なんですか?経済復旧の話って和民以外ほとんどの人がしてないけどいいの?

    SEやってる人間としては、こういうプレゼン力を問うようなやり方ではなく、どの問題に対して誰がどう考えているか、を一覧にして欲しいですね。そうしないと評価するのがめんどくさい。防災(防犯)、経済(財政)、外国人、観光、築地移転、東京オリンピック、青少年健全育成条例とか10個ぐらいキーワード挙げて、各候補者に各々500字ぐらいでまとめてもらう。ついでになんか政策するなら財源の捻出方法も明記する。それを選挙管理委員会が公開する。そういうのやってほしい。そうすれば選ぶ方もだいぶ楽になる。

    まーどうなりますかね。ちょっと先が読めない選挙になる気がします。

    • 投票日: 4/10(日) 7:00~20:00
    • 持ち物: 投票所入場整理券(家に届く封筒に入っている紙)。期日前投票も同じ。期日前投票の場合は投票所入場整理券の裏の投票宣誓書欄を記入してください。
    • 期日前投票: 3/25(金)~4/9(土) 時間は自治体によりますが、だいたい8:30~20:00
    • 参考リンク:東京都選挙管理委員会 - 東京都知事選

    2011年4月3日日曜日

    [原発関連]素人が調べたQ&A

    原発がやばい状態にあって、いつまでも心が落ち着かない昨今ですね。

    ただただ不安にしてても仕方ないので、報道聞いてても分からないことについて、今まで個人的に調べた結果をまとめます

    筆者は原発には完全な素人ですので、ここに書いてあることが正しくない可能性は大いにあります。ご注意ください。

    原子力保安院って何?

    正確には「原子力安全・保安院」。立場的には、経済産業省の外局である「資源エネルギー庁」の特別機関です。

    原子力や電力やガスなんかの安全を保つため、立入検査、報告徴収、業務改善命令を出したりします。

    そのため、今回原発問題が発生した際に東電に対して調査命令、報告命令を出し、その結果を逐次発表しているわけです。

    大きな見方をすれば、この人達の発言は政府の見解であると拡大解釈することもできます。

    2ch、ニコ動等で「不安院」と呼ばれているのはここの人達の事です。

    「不安員」は誤字。

    どうしてこうなった?

    地震と津波に端を発していることは明らかです。ですがここまでことが大きくなるにはいくつか原因があります。

    まず、地震そのものではそれほどダメージはなかったようです。そう言えるのは地震発生時に原発の停止は成功したからです。

    次に津波ですが、こいつが事を大きくしています。原発で非常事態が起きた場合、やらなきゃならない3つのこととして「止める・冷やす・閉じ込める」というのがあるそうですが、このうち福島第一原発で成功したのは「止める」だけ。「冷やす」は冷却装置が動かなかった&燃料タンクが流されたことにより実施不可となってしまいました。

    冷却装置が動かなかったのは非常要電源が動かなかったから、と言われていますが、なんで動かなかったのかは不明(誰か知ってたら教えてください)。地震の影響でしょうか? ちなみに非常要電源は地下施設にあるそうです。

    燃料タンクが流されたのは津波のせいですが、なんで津波が来るような場所にそんなもん置いておくのかというと、タンカーで給油するのに便利だからだそうです(人からの伝聞)。

    電源装置にしろ燃料タンクにしろ、海から離れたところに置けよ、と考えてしまいそうですが、丸裸で置いといたわけではないですし、高台に置くと地震に弱くなってしまう(参考記事)そうです。

    結果として、電源がない→冷却ができない→燃料棒の熱で圧力容器内の水が蒸発→燃料棒が露出→露出した部分がどんどん発熱→燃料棒の被覆が破損(!?)という流れになっています。

    直ちに健康に影響がないって本当?

    「直ちに」がどの程度の期間を表すのかにもよりますが、数日以内に影響はないと思います。ですが逆に、数年~数十年後には発ガン率があがるなどの影響が出る可能性はあるそうです。

    ちなみに人間が1年間に浴びても良いとされる放射線量は1mSvです。でもこの値を超えた放射線を浴びても直ちに健康に影響はありません。24日に原発作業員がベータ線熱傷(放射線熱傷の一種)を起こしましたが、これは放射性物質が長時間肌にくっついていた場合になるものなので、単純に放射線を浴び続けていてもなりません(多分)。

    そもそも、放射線被曝によって「直ちに影響が出る」レベルになっていたらアウトだと思うのですが、人間は1000mSvぐらい浴びないとすぐに死の可能性は出ないそうです。大量の放射線被曝による発ガン率の上昇だって、その影響は数年~数十年後に現れるもので、そのときになってから被曝が原因だと証明するのも難しそうです。しかも確率論なので、たくさん浴びても何の異常も来さない人もたくさんいるはずです。なので、この「直ちに~」というのは、何の尺度にもならない見解だということです。

    あと、テレビなんかで原発付近の放射線量をCTスキャンや飛行機での移動時の被爆量と比較していますが、あれは時間あたりに浴びる放射線量です(単位はmSv/hまたはμSv/hなど)。なので「CTスキャンの10分の1なので安全」というのであれば「じゃあ1日2時間浴び続けてたら5日でCTスキャン1時間浴びるのと同じってこと?」って話になります。

    結局、年間で累積どの程度の線量を浴びるかが肝であり、瞬間値をどうのこうの言っても、あまり意味がありません。

    今年の流行語大賞にノミネートされるのではと早くも囁かれています。

    よく出てくる単位: Sv(シーベルト)、Bq(ベクレル)、Gy(グレイ)って何?

    Bqが放射線の量の単位。SvとGyが放射線の強さの単位。放射性物質からの距離や遮蔽物の影響を考えた放射線の強さ(吸収線量)の単位がGy、さらにそれに放射線の種類ごとの人体に与える影響度合いを積算した放射線の強さ(線量当量)の単位がSvです。

    原発からの放射線量がSvで発表されるのは、実際に人体に影響を与える度合いを意味しているからです。

    ほうれん草や水の汚染報道時にに出てくる単位がBqなのは、単純に付着している放射線の量を表しているからです。その気になれば、汚染されたほうれん草畑から100m地点にある農家がどの程度の線量当量を受けるか測定出来るかもしれませんが、どうせ検出限界未満でしょう。

    チェルノブイリみたいになることあなるの?

    まず、チェルノブイリ(以下チェルノ)原発の事件とは状況が全然違うので、同じ事故は起こりません。チェルノは原子炉フルパワー動作中にふっ飛んだのに対し、福島第一原発は既に動作を停止しています。なので、よほど意図的なオペミスをしない限り、同じ事象は起こりません。

    ですが、自己の結果放射性物質が漏洩している点は同じです。福島第一原発でも海水汚染などで放射性物質の漏洩がありますので、この状態が続けば、放射能汚染が広がることは変わりありません。

    ちなみに福島第一原発も水素爆発を起こしていますが、あれは建屋上部が吹っ飛んだだけなので、事象は別です。

    もうこんなこと起こらないように原発止めればよくね?

    まず、今全国にある原発を全て停止した場合、他の発電所では電力供給が足りません。これは今運転を停止している発電所を全て動作させた場合でも足りないそうです(東電の会見内容より)。

    一方、火力発電所をもっと新設すれば、必要電力をまかなえるかもしれませんが、これだとCOP15で日本が(というか鳩山が)掲げたCO2の25%削減に反することになります。

    結局、発電効率の高い発電方法閃くか、消費電力半減する商品がブレークスルーされない限り、原発に頼らざるをえない状況は変わらないと思います。

    繰り返しになりますが、伝聞や私見が多大に含まれていることをご理解ください。

    2011年4月2日土曜日

    [訂正]募金と寄付

    すみません。国語力が足りていませんでした。

    この前書いた記事とかで「募金するときは」とか書いていましたが、そもそも募金とは寄付金を募ることなので、我々一般人が募金箱にお金を入れる行為は寄付が正しいようです。恥ずかしながら知りませんでした・・・orz

    過去の記事は訂正しています。

    2011年3月21日月曜日

    寄付するときは良く考えましょう

    先週の大地震+大津波で甚大な被害を被った東北地方。そして続々と始まる各地での義捐金募集活動。

    この前も書きましたが、寄付をする場合は寄付先を良く考えてください。今回のように、1つの寄付先(=東北地方)へ複数から募金を行っている場合、理屈上どこへ寄付しても届く額(もしくは相当の物資)は同じはずです。

    しかし実際には怪しいニュースでやっているような募金詐欺もあります。ですので、なるべく信頼できる機関に寄付をすることを心がけなければなりません。

    結論を言えば、赤十字か役所などの公の機関以外には寄付する必要はありません。街頭で声を上げている人たちや、コンビニに置いてある募金箱には寄付をする必要はありません。あなたが1000円寄付しようとしているのなら、(信頼できる機関であるという前提で)赤十字か役所に寄付すれば届くのですから、わざわざバイトや見ず知らずの人間が持っている募金箱に入れる必要はありません

    断っておきますが、善意できちんと活動している方々もいらっしゃるともちろん思っています。ですが、怪しい集団がいることも確かですので、無用なトラブルを防ぐためにも、赤十字か役所がいいと言っているまでです。身の回りに信頼できるボランティア団体がいるならそこへ寄付しても良いですが、どこへ入れようとあなたが送る義捐金は変わらない、ということを認識してください

    赤十字が集めた義捐金は義援金配分委員会という組織に集められ、そこで計画的に利用がされます(参考)。それすら信じられないとなるとどうにもなりませんが、少なくとも駅で所属不明の人達が行っている募金活動よりは信用できると私は思っています。

    こういう事態だからこそ、効率よく義捐金を集めることができるように、皆さん注意しましょう。

    ちなみに、義捐金が集まりすぎるのでは?と思う人も居らっしゃる方もいるかも知れませんが、日本人が1億3000万人いるとして、1人1万円寄付しても1兆3000万円です。アメリカのリスク分析会社の概算によれば、住宅被害だけで1兆6000億円かかるそうです。ですので、義捐金はいくらあっても溢れるということはありません。

    今回の震災の一日も早い復興を祈るとともに、義捐金も少しずつではありますが、出していきたいと思います。

    [地震じゃないよ] やっと一段落

     

    久々に絵を描いてみたらクソ下手になってたww

    ここ数カ月ずっと仕事関係のプログラム作りに追われてた。しかも業務と直接関係ないからたちが悪い。

    ブラウザアプリケーションなんだけど、とりわけ苦労したのがIE6サポート公式にも葬られているブラウザを何故なおもサポートし続けないといけないかというと、会社の既定ブラウザがIE6だから。何故既定がIE6かというと社内システムが対応していないから。何この情弱企業。

    IE6さえ捨ててくれれば開発期間が半分以下になるな。本当に窓から捨ててくれよ。

    Posted by Picasa

    2011年1月30日日曜日

    休日に部屋から出たら負けかなと思ってる

    前回話したO/Rマッピングに悩む日々。外出しているヒマなどない!

    ふつーに決め打ちでダカダカコード打てば終わることも、気に入らないのでいつまでも悩み続けて、早1週間。

    1週間はえーよ。っていうかもう2011年1ヶ月終わっちまったじゃん!

    2011年1月23日日曜日

    [書籍]C#ショートコードプログラミング (MSDNプログラミングシリーズ)


    面白そう。MSDNからこんなのが出るとは思わなかった。

    中を見ると、結構無茶と思えることしてまでコードを短くしています。LINQやラムダ式は当たり前w

    興味はあるけど、2,940円か。。。ふつーにMSDNの記事として出してくれればよかったのになー

    オブジェクト指向とSQLの親和性の悪さについて…は既に語りつくされていた

    先日、会社の人何人かにオブジェクト指向だとSQLって使いにくいよね?って話をしたんですが、みんな反応薄orz

    私の説明の仕方が悪かったんだと思って、言いたいことをまとめていたら、全部↓に書いてあったw

    はい、もう言うことありませんw 周知の事実だったんですね。無知でした。

    でももうちょっと書きたい。

    例えばSQL使ったプログラムって↓みたいな感じになると思うんですよ。

    [PHPでPDO使った場合の例]
    // SQLを書く
    $query = "SELECT name, age FROM PersonTable WHERE sex=male;";
    
    // DBのインスタンスにSQLを渡して結果を受け取る
    $statement = $database->query($query);
    

    ↑みたいにさ、SQLってさ、検索のロジックと戻り値を書くじゃん。それってさ、関数だよね。だから、SQLを渡して検索させるのってさ、データ保持してるオブジェクトに関数ポインタを渡して検索させるのと同じだよね。

    でもってそのロジックも戻り値も不定なわけじゃん(選択する列は任意だし、そもそもINSERTUPDATEのように戻り値がないSQLもある)。だからSQL受け取るオブジェクト(のクラス)は、渡された関数ポインタの戻り値がどんなものであって許容しなければならないってことになる(↑の例で言えばquery関数の戻り値は不定(PDOだとPDOStatement型が戻りますが))。オブジェクト指向的に(かどうか知りませんが)、そんなよくわかんない関数、外部に公開したくないですよ。

    さらにやっかいなのが、SQLが単なる文字列であること。操作(SELECTINSERT)、選択列、WHERE句等を1文に記述する。しかも操作によって構文が違う。「INSERT INTO ~」とか、INTOいらねーだろって思いますw 英語的に気持ち悪いのかもしれませんが、だったら METHOD=INSERT TARGET=PersonTable; みたいな書き方にして欲しいと、オブジェクト指向的に(かどうか知りませんが)思うわけですよ。

    最後に、色々ぐぐってみると、オブジェクト指向派とSQL(というかデータ中心指向?)派では、しばしば宗教論争があるらしく、喧嘩の種になるそうです。

    色々書きましたが、私はSQLを否定しているわけではありませんよ。オブジェクト指向との親和性の低さを嘆いているだけです。データベースを、文字列を指定するだけで自由に検索できるなんてスバラシイじゃないですか。

    しかし、結局、永続化データをオブジェクト指向で扱いたい場合は、、どうすればいいんだ??(意地でも何でもありのquery関数を公開することはしたくない。。。そして特定のテーブルに特化した処理も書きたくない。。。逃げちゃダメだ逃げちゃダメだ逃げちゃry)

    2011年1月4日火曜日

    [4コマ]冬休み最終日

    明日(正確には今日)から仕事か。。。

    冬休み中にやっちまおうと思っていたことが何もできてねー

    今年もこうしてのんべんだらりと消化していくんだろうなー

    寒いの嫌だなー

    2011年1月3日月曜日

    あけましておめでとうございます!!

    どジャアァァ~~~~ん

    というわけで2011年、卯年、うさ耳スタンドと言えば大統領のD4C。退廃しきった2010年の私を隣の世界へ捨て、無傷の2011年の私に入れ替わってきました。気分はそんな感じ。

    今年もこのどうしようもないジョジョオタをどうぞよろしくお願いします。