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