なかなかイイですよ Tampermonkey

ChromeにTamperMonkeyなるエクステンションがあるのですが、これがナカナカいいです。
http://tampermonkey.net/about.html?version=2.5.29

任意のWebサイトのhtmlに介入して書き換えてしまうものです。
利用には、中級javascript使いである必要があります。
なぜって、生のjavascriptを使って「htmlに介入」するので。

似たようなコンセプトでは、例えば有名なAdBlockがありますが、アレはバナー広告専用ですし、
日本国内のショッピングサイト類等には対応してないわけです。

で、具体的にどうするかですが、例えば、とあるショッピングサイト。特定団体の誹謗中傷を目的としてはいませんので、縮小しまくってます。それでも見えちゃってますが、まあ許してください。



ここのショッピングサイトは、あまりカスタマイズが出来ないらしいのですが、iframeで捻じ込むっていう方法論が確率しちゃって、結構な分量のカタログを見せられます。とはいえ、長すぎじゃね？と思うところも多々あります。だって、縦2000ピクセルとかありえないですよ。どんだけスクロールさせるんだよ。商品を売る気があるのかよ？

そこでTamperMonkeyの出番。
https://chrome.google.com/webstore/detail/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en-GB
https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo
話の都合上、入れるしかないので、入れてください。

しかし単体では動きません。個々のユーザスクリプトをインストールする必要があります。

前述のケースでは、こんなことをヤラカすスクリプトを書きました。


一定サイズ以上の巨大なiframeを、リンクに差し替えます。これが効くと、画面がゴッソリ縦に縮みますから、サクっと商品をチェックできます。

TamperMonkeyでは御謹製リポジトリがあるのですが、ファイル名が、*.user.jsだと何処からでもインストールできるっぽい。ので、githubに貼りました。

https://gist.github.com/raw/3255264/50bd0ae0e598f7b943ea5c022d208cbc143944cf/iframedisabler.user.js

インストールが始まっちゃいますが、ご安心を。断った上でソースの確認ができます。

味を締めて、もうひとつ書きました。tumblrのreblog用です。



小生が常用しているPCは、14インチワイドなので、縦がやや狭いです。ですが、tumblrはどういう訳か、縦長い画面の方が使いやすいように出来てるようです。Android Tablet で縦持ちで使うと、驚きの使いやすさ。

実際にはそんなに大それた話ではありません。画像を縮小しちゃってもいいわけです。Bookmarkletはそうなっています。PC用に、っていうか、ユーザPCの画面サイズに合わせて縮小してくれないもんでしょうか。やってくれなさそうなので、TamperMonkeyの出番です。



スクリプトはコイツです。
https://gist.github.com/raw/3255265/c90e19012f422f39952182b6d30724d19ced2534/tumblrnallowscreen.user.js

日本人のIE好きは異常

日本人のインターネットエクスプローラ好きは、日本人同士なら周知だと思いますが、
世界的に見ると、シェアはかなり落ちてるようです。既に4割を割ってるらしい。

http://gs.statcounter.com/



IEのユーザが、完全にChromeに流れてるのが一目瞭然です。ただし、これが日本に限ると未だにIEのぶっちぎりなのです。


不思議ですね。と言いたいところですが、理由は明らか。日本人の「長い物には巻かれる」という資質が出てるのでしょう。大多数の日本人がMS Windowsを使ってる。そして、その大半は、やはりオマケのIEを使いつづける。というわけです。何の疑いものなく。

IE自体は、別段優れてはいません。Windowsのオマケという立場を利用してるにも関わらず、スピードはChromeに大きく遅れていました。特にIE6の頃が顕著でした。特にベテランGmailユーザはご存知だと思います。IE6でGmailを使うと、激遅であることを。

別の理由もあります。大企業では大抵「IT推進部」或いはそれに類する部署があり、社内のPCやらソフトやらを管理しています。 そういう会社では、大抵、初期にインストールしっぱなしのIE6を未だに使っていたりします。しかもjavascriptはOFF。「仕事」しかできません。ある意味組織票ですね。

ちなみに、先のブラウザ統計グラフですが、数年スパンのものも見られます。



Chromeの尋常ならざる追い上げが凄い。


日本でも、年単位で見ると、IEのシェアは落ちつつあるようです。このペースでいくとあと3年はかかりそうですね。

もっと流行ってもいいと思うmozilla prism.

mozilla prismをご存知でしょうか。

http://prism.mozillalabs.com/

webアプリ専用ブラウザです。というと何のこっちゃ判らないかもしれません。

初期起動時は、次のような設定画面がいきなり出ます。



これを操作していくと何が起こるかというと、特定のURLの対するデスクトップショートカットが出来ます。これはOSを問いません。Microsoft Windowsは元よりubuntuですら同じです。

要するに、特定のURLだけをいきなり開くブラウザとなるわけです。

何が嬉しいかというと、特定の数件のWEBサービスを常用する場合ですね。

普通だったら、ブラウザを起動して、URLを入力もしくはブックマークから選ぶ。
もしくはタブブラウザを常用している人は、スタートアップに入れてるかもですね。

しかし、prismでは、デスクトップショートカットで行きなりWEBサービスが開くので
普通のネイティブGUIアプリと、使い勝手は変わりません。

そして、昨今のWEBサービスは、ajaxを使いまくりで、モノによってはドラッグ＆ドロップすら出来たりします。より一層、WEBサービスとネイティブアプリの差は縮まっています。

プロジェクト通り、コイツはmozilla/firefoxと同郷なので、スピードの面ではgoogle chromeにやや押されがちですが、firefoxよりも起動がやや早く快適に使えます。

グーグル画像検索が、快適化

おもむろにグーグル画像検索を使ってみたら、
またパワーアップしてましたね。
しかも何で気づかなかったかというと、
Firefox専用らしい！ Google Chromeでは稼働しません。



サムネイルの密度が上がって、ページ切り替え無しの上下スクロール。
グーグルマップのアレの延長線上にある技術でしょう。
iPhone等では、フリックでめくれるので、
むしろPC版でのスクロール実装は遅かったぐらい。

スクロールが差し掛かると、画像のロードをするlazyloadの採用。
なので、絶望的なスクロール範囲の割に、PCのメモリ使用は控えめな筈。

カーソルが重なると、ウニョンと拡大、さらにそれを選ぶと、
ページに飛びますが、とんだ先では、本来のページが背景に隠れて、
画像を、勝手にライトボックス表示。

XMLは「固い」とお嘆きの貴兄に、YamlとJSON。

ソフトウエア業界で、XMLを知らない人は、

21世紀の現代では居ないでしょう。

15年以上前の、発祥当時は、

知る人ぞ知る的な面が多かったのですが。

XMLは、端的に言えば、HTMLのイトコです。

厳密には、HTMLのXML準拠がXHTMLで？

XMLの複雑版(?)のSGMLが、だったか？

#調べてもらえば済む話なんで、本稿では正確さは目指しません。

不等号によるタグで、囲んだり挟んだりして、

データの階層構造を表します。

HTMLのFONTタグやらAタグやらが、

まさしくそうですよね。

しかし、XMLはエンタープライズ界隈発祥なので、

Javaと同じ業を背負っています。「固い」です。

XMLは、様々なソフトウエアの「定義ファイル」として

使われているので、どこでデモ見つかります。

http://technet.microsoft.com/ja-jp/library/ee909429.aspx

http://developer.android.com/intl/ja/guide/topics/manifest/manifest-intro.html

面倒臭そうでしょ？

とにかく文字が多い。ギチギチです。

エンタープライズ界隈で、コレを面倒だと言う人は居ません。

面倒なのはコレだけじゃないので、

麻痺しちゃってるんじゃないでしょうか。

もしくは、Eclipse等で編集します。

まあ、データ交換言語として発祥したので、

プログラムで生成する分には構いません。

手で書かせちゃいかんだろ、って話です。

データの構造を表すのに、何通りか方法が有っちゃうのも

混乱を招く＆学習しにくくなる理由でしょう。

「XML技術者認定制度」って欲分からない組織もありますね。

http://www.xmlmaster.org/

仕 事を増やす仕事に絶望した！

Java業界は、Eclipseを使うしかない、から良いのですが、

pythonやらPHPやらは、Eclipseに依存は無いので、

わざわざxmlの編集だけに使う、って非合理的です。

#実際、流石の使い勝手ではあるのですが。

故に、xml専用の編集ツールも、幾つか存在します。

http://freesoft-100.com/pasokon/editor_xml.html

しかし、別のエントリでも筆者が何度となく申している通り、

手段の為に、別の手段を必要とするのは、回り道ですらありません。

仕事を増やす仕事に絶望した！

結論だけ言っちゃえば、既に別の選択肢が現れています。

データ型を絞り込む事で、記述の簡素化＆再構築をしています。

javascriptベースで、サーバと通信するならjson

http://www.json.org/example.html

XMLとの比較も載ってるので、エラくあっさりしたのが判るでしょう。

javascriptやpythonの、静的データ構文に酷似してるので、

プログラマには非常に馴染みやすい形式の筈。

手で書くのも苦にはなりませんが、

javascript以外でも、変換関数が付属してたりします。

更に、手で書いてもラクな(それを目指した)

フォーマットもあります。yaml

http://www.yaml.org/start.html

サンプルを見ると「そういうことね」と思えるでしょう。

ここまでシンプルになれば、

CSVの代替として現実的でしょう。

見た目はもちろん互換性は無いけど、用途的にね。

CSVだったら、カラム順を合わせなきゃなりませんし、

ダブルクオーテーションを含むカラムの表現がアレだったり

カンマだったり、カラムの途中で改行してくれちゃったり

取り込みはかなり面倒臭いです。

yamlはデータ構造の表現が有るので、心配は要りません。

殆どの言語向けの実装があるので、

とりあえず設定ファイルはyamlにしちゃえ、

と言うのもアリです。

「webアプリケーション」は、ネイティブアプリに比べると、色々面倒

情報漏洩やらの懸念から、

企業では、従業員個人単位での単体アプリケーションの運用を辞めて

シン(thin)クライアント化やら、web化やらに進みつつ有ります。

3年ぐらい前から？

web化については、従業員PCに入れるのはブラウザだけで済むので、

「情報管理統括部」としては、大幅に気楽だとは思いますが、

作る方は、むしろ手間が掛かったりします。

#ソリューションの本質は、「苦労」の箇所を「変える」事なので

#開発稼業は、ある程度それを覚悟してやってる訳ではありますが。

例えは、「登録をしたい」と言えば、

基本的に、

• 追加
• 検索
• 修正
• 削除
• (終いには)変更履歴、

の4〜5機能の実装を含んでいます。

「アンタ、「登録」としか言わなかったじゃないか！」

とゴネても無駄です。結局作ることになります。

webベースでこれらの実装をするのは、実はかなりコスト(手間)が掛かります。

• 従業員データは、dbに入れるでしょう。
• 編集画面は、htmlで書いて、ブラウザに送ります。
• ブラウザ側で、人間がFORMを埋めて、submitして、サーバに送ります。
• 空欄チェック、全角半角、英数字、メイルアドレス書式等
• サーバからチェック結果を戻す。
• サーバは、dbに格納する。

上記、3段階で、全て、入力項目の管理をしなければなりません。

それ自体は、単体アプリでも必要ですが。

webベースで勝手が違うのは、

ブラウザとサーバの2ヶ所で処理する事です。

しかもその間の通信方法は「HTTPでなければならない」。

入力に不備が有ります、と画面に出すだけで結構苦労します。

サーバ側の実装はPHPだったりJavaだったり、

ブラウザ側はHTMLで、とか言語も違ったりします。

加えて、編集＋新規＋削除 それぞれで

似て非なる実装を何回か繰り返さなければなりません。

更に、これを「○○管理」全て、繰り返す訳です。

余程の工夫をしないと、工数削減は出来ない、と言うのは

そろそろお解り頂けるでしょうか。

やっつけ仕事で、コピペしても良いのですが、

実装量は確実に増えます。バグりやすくもなります。

筆者が言うまでもなく、

これをどうにかしようという動きも当然ありまして

とっくの昔から、地球規模で進んでいるわけで、

それぞれの言語で、幾つかのフレームワークが産まれています。

しかし「それを持ってくればOK」、で済めばプログラマ要りません。

クライアントの「担当者」がやってみれば良いです。

#本当にそれで済んじゃえば、商売あがったり、な訳ですが。

グーグルが始めた「ajax」は、実はその「どうにか」の一つでもあります。

ブラウザjavascript側に、大部分の処理を移譲することで、

ブラウザとサーバの通信回数をゴッソリ減らせるわけです。

ですので、

ごくたまーに「IE6で、しかもjavascript禁止」だと、

血の気が引きます。ザザーっと。

8年前のテクノロジーに付き合わなければならなくなります。

2010年現在で、改めてIE6互換環境を用意するのにもかなり骨が折れます。

正規で入手する方法は、既にありません。

正直、割増料金が欲しいぐらいです。

マイクロソフト本人が「IE6よりIE7の方が安心」って言ってるんだから

いい加減入れ替えましょうよ。「IT推進部」の皆さん。

http://www.microsoft.com/japan/Windows/ie/ie6/downloads/default.mspx

自分で「より快適」とか言っちゃだめでしょう。

appengineの真骨頂は、pythonにあり

日本の、エンタープライズ界隈の方々は強情で、
app engineのdatastoreを難解だと感じている様です。＋

JavaのJVMによる、他言語実装、例えばrubyもあり、
http://jruby.org/
app engineでrubyを使う人も居るには居るらしい。
http://code.google.com/p/appengine-jruby/

RDBのJava実装がありまして、
OpenOfficeのBaseでも内蔵してる代物なんですが、
http://hsqldb.org/

これをdatastoreのミドルウエアとして使った人も居ます。
http://www.littlesoft.jp/sql4g/

確かに、RDBMを使えれば、リレーション使いまくりですが、
そもそもJavaは、「固い」言語なので、datastoreの柔軟さが活かせません。

って言うか、そこまでpython使いたくないですか？と聞きたい。

pythonのwsgirefとか、webappは、JavaのServletに近い考え方ですね。
どっちが先だか私は知りません。
しかし、app engineの真骨頂はdatastoreにあります。

RDBに、GUIツールが存在するのは、「管理が面倒臭い」の裏返しです。
Java自身のためのEclipseが存在するのと同義です。

しかし、datastoreのORマッピングなら、ソースを修正するだけです。
pythonなら多重継承すらできます。

いやもう、SQLなんか書いてられませんよ。面倒で。

JavaのJDOとやらからでも、比較的簡潔な記述が書けますが、
http://code.google.com/intl/ja/appengine/docs/java/datastore/dataclasses.html

pythonのそれとは簡潔さが比較になりません。
http://code.google.com/intl/ja/appengine/docs/python/datastore/entitiesandmodels.html

記述量は、5倍以上ですね。
筆者は(python版の切り口に対して)「え？これだけでいいの？」と素直に感動しました。

pythonのアレを強引にJavaで例えるなら、
classのstatic変数の初期化で、カラム名＆型の定義をしています。
しかもnewすると、同名の変数が、データカラムとして使えるという。
Javaでそんな記述は不可能です。pythonだからこそ可能です。

しかしこれはpython djangoのORマッピング機能上に実装したものらしいので、
http://docs.djangoproject.com/en/dev/ref/models/instances/
python djangoが、もともとイカしていたといった方が良いでしょう。

datastoreが難解なわけじゃなくて、
JDOのアノーテーションが気持ち悪いのです。
見比べでつくづく思いました。

グーグルのファイル共有サービスは日本人には難しいか

仕事上の都合で、

取引先の担当者と、グーグルドキュメントの共有を試みました。

結論から言うと、まるでうまく行きませんでした。

「ドキュメントに入れておきましたよ」って言っても

何時のまにか忘れてしまって、

メイルで着信している分から探したいらしいですね。

結局、メイル添付での運用に戻ってしまいました。

日本人は、マイクロソフトが

Outlook Expressをオマケで付けたお陰で、

メイル添付に慣れきっています。

わざわざ、webサイトを開こう、って気はまるでない見たいですね。

#メイル添付ファイルでの運用は、問題点だらけなのですが、

#それに気づかずに、頑張ってしまうケースが殆ど。らしい。

#その証拠に、「○○管理用.xls」って一杯作ってるでしょう？

「Gmailアカウントを持っている」というだけじゃ駄目らしい。

結局、「Gmailを常用してます」って人しか残らない。今のところは。

この辺りを何とかしないことには、日本では中々普及しないでしょう。

それを痛感しました。これはグーグル系に限った話では無いでしょう。

Windows 7から、Outlook Expressの付属を辞めて、

Windows Liveに移行して欲しい感じですが、

日本市場に関して言えば、しばらくは無理に思います。

理由は前述のとおり。

Gmailに慣れた筆者には、微妙なwebサービスでした。

という側面もあったりします。

今更 dropbox を使ってみる

今更試しました。

http://www.dropbox.com/

専用クライアントソフトからしかアカウント登録できなかったりとか、

世間一般に言うwebサービスとは、大幅に毛色が違いますね。

まあ、「FTPもNASも要らないよ！」が売りらしいので、

こういう線で攻めるのはアリなんでしょう。

サイトのダウンロードURLに行くと、

プラットフォームを自動判定して、exeなりdebなりが飛んできます。

#海外のサービスサイトでは、概ね、機種は自動判定ですね。

Windowsで試すことにします。

#何故って、前にubuntuで試そうとしたら、動かなかったので

落ちてきたインストーラを起動すると、

Windowsならスタートメニューにdropboxが入ります。

起動すると、タスクトレイに常駐します。

初回であれば、その場でアカウント作成を要求してきます。

Freeアカウントを選択しました。

さりげなく「共有フォルダ」が開きますが、

見た目は普通のエクスプローラですが、

中身のファイル群には、左下に「同期してますアイコン」が付くようになります。

C:\Documents and Settings\筆者\My Documents\My Dropbox

でした。

共有フォルダの中身アイコン群を、右クリックしてみても、

特に何か、機能が増えてる感はしませんね。

ただ漠然と、ファイルを放り込むだけの様です。

あとは、タスクトレイに常駐している「何か」が

同期を繰り返します。

これであれば、「日常、Windowsな人々」に勧めても

どうにかなるだろうと思います。

次回の案件で試してみようかと思う次第です。