カテゴリー: 情報技術

PARC自由学校で「アクティビストのためのソーシャルメディア講座」の講師を引き受けることにした。

この間、社会問題を追うことと、社会運動の中で技術を使うこと（あるいは技術を使ってメディアを作ること）の二つを追ってきた。二兎を追う者は一兎をも得ずと言われそうだが、負け惜しみを言っておけばどちらもそこそこ成果を上げている。と言っても、どちらも社会的認知を受けるにはほど遠いから成果と言うにはあまりに乏しいものに過ぎない。僕は技術系の人間ではないのだが、だからこそ、現在の日本社会の中での技術のあり方については相当問題が見えるところもある。自分の非力ゆえに社会的認知が得られないのだが、現在の日本、企業社会も市民社会もともに持つ大きな問題もそこには横たわっている。
“情報コミュニケーション技術のあり方にもの申す” の続きを読む

オルター・トレード・ジャパンのWebサイトにWordPressを導入してはやりのレスポンシブWebデザインにしてみた。http://altertrade.jp/ “レスポンシブWebデザイン” の続きを読む

これまでプライバシー・ポリシーとは団体・組織が取り扱う個人情報をどう会員や顧客に不利益を与えない形で処理するかを定めておけばよかったかもしれない。その対象は送られてくる質問、メールや電話、FAX、注文データなどの取り扱いをしっかりしておくということ。厳密に言えば当然Webのアクセス記録やメールのやりとりを記録したサーバーログもそこに入るが、しっかりと運用していれば外部に漏れることはないものだった。

しかし、インターネット上の急激な認証化の動き（具体的にはFacebookやGoogleなどが実名での登録を要求し、その登録規模がかつてないほどの大きなものになったこと）に伴って、その対応も変えざるをえなくなってきている。

たとえば、Webアクセス解析はGoogle Analyticsなどのサービスを使っていれば、誰がどのページを見ている、という情報は自社内で管理はできずに、Google上で把握されてしまう。本来、誰が見ているという情報の部分は追わないというのがあるべきプライバシー・ポリシーであったはずだが、GoogleアカウントやFacebookアカウントと結びつけられることで把握されてしまう可能性は飛躍的に高まっている。

それ以上にFacebookなどとWebサイトを結びつけると逆にこのサイトを支持する、という形で自らを晒していく動きが大きくなっている。これは自分の意志でやっていくわけであり、積極的にこうした人たちと結びついていくことで、その組織の存在が身近に感じられるという効果もあり、今後の大きなトレンドになっていくだろう。正の側面が語られることが多いが、負の側面がないかどうか、今後の議論には十分注目する必要があるだろう。

一方、Google Analyticsなどによって、本人が知らない間に閲覧記録が取られてしまうという問題は検討すべき課題として大きくなっている。

Google Analyticsは無料で提供され、その機能も高く、さまざまなガイドブックも売られているので、トレーニングの負荷も低く、多くの団体で使われている。ユーザーの側でGoogleにアクセス記録を取られないように防御する方法がないわけではないが、基本的にほぼすべての人のアクセス記録はGoogleのデータとして保存される。

これに関してはオープンソースのアクセス解析を使うことで解決することは可能だ。オープンソースのアクセス解析のPiwikは直感的にわかりやすいインターフェースで完成度も高い。しかも、訪問者のオプトアウトも確保しているなど、プライバシーに関する配慮も高い。

問題としてはGoogle Analyticsは日々システムが更新され、新しくなっていくのに対して、オープンソースのシステムは管理者がアップデートしない限り、更新されないこと。またGoogleと基本は同じなので、知っている人にとってはトレーニング不要だけど初心者向けのマニュアルがあるわけではないこと。しかし、後者の問題はPiwikのインターフェースが直感的に理解可能で、Googleのものとほぼ同様に使えるという点で、大きな問題ではない。

プライバシー概念が大きく変わっている中、あるべきプライバシー・ポリシーを確定することは容易ではない。
しかし、楽だからという理由だけでGoogleを使い続けることが許されるか一度考える必要があるだろう。

Piwikをインストールしてみたが、完成度はかなり高く感じた。アクセスがあった地域の情報は国単位ではなく、やはりもっと細かい行政単位で情報が必要だろうが、それはGeoIPのエクステンションをインストールすることで可能（なお、パフォーマンスが要求される環境ではGeoIPのApacheのモジュールをインストールすることが望ましいようだ。今回は省略。詳しくはMod_GeoIP）。

サーバーに１つインストールすれば複数の異なるサイトを解析できて、しかもユーザー権限も個別に設定できるなど、便利である。使い込んでみるともっと別の評価が出てくるかもしれないけれども。

TwitterやFacebookのように時系列にデータが並ぶメディアだと大事な情報が過去に流れてしまうので時系列ではない情報の受け皿としてMediawiki（Wikipediaのエンジンのオープンソース版）でやろうと考えた。

しかし、Wikiの文法はくせがある。それをうまく意識しなくて使えるようにしてくれるオンラインエディター(WYSWYGエディター）、FCKeditorを組み合わせればかなり使いやすくなる。

ところがもうこのFCKeditor（CKeditor）のextensionはメンテナンスされておらず、古いextensionは現在のバージョンのMediaWikiでは使えないことがわかった。PHP 5.3へのアップデートあたりの問題が絡んでいるのだろうか。FCKeditorなしのWikiだと使ってもらうのはかなり難しいと思う。

他にもオンラインエディターはあるのだけど、どうも使い物にならない感触。この状況ではMediawiki自身のオルタナティブを考えないといけないかもしれない。でもあのやさしくはないWikiで作れたWikipedia、よくみんな書いていると関心してしまう。

Wikiにこだわらず、WordPressなどのstaticページを使うのも手かもしれないし、その他に使えるものとかあるだろうか？

結局、FacebookとかTwitterしか使ったことのない人に使ってもらえるものと考えるとMediaWikiはきつい。情報オタクにはいいかもしれないけれども。
MindTouchは使いやすそう。ただ、気になるのはオープンソースとして提供されてはいるものの、企業の展開に左右されそう。将来にもオープンソースとして使い続けることができる確実性はMediaWikiの方が上か。

正直言って困っている。何かいいアイデアあったら教えてください。

サーバーのバックアップは悩むところだ。公共性の高い、保存価値の高いWebサイトの管理をしていて、もしそのデータが失われてしまったら、とてもまずい。

以前であれば異なる場所にあるサーバー間で重要なファイルを相互にバックアップさせておけばどれかのサーバーがクラッシュしても、重要なデータは失わない、という形でとりあえず十分と思っていたけれども、たとえば自分が急病や事故で動けない状態になった時にアウトになってしまう。不正侵入を防ぐために特定のIPアドレス以外からはサーバーにはログインできないように防御しているので、逆にそれが仇になってデータが取り出せなくなる危惧がある。

高価なバックアップ装置を買ったとしても火事でサーバーごと焼けたらおしまい。またバックアップできていると思って確認したらこわれていて取れていなかった、というケースも結構ある。

そのような場合、またクラウド企業の出番になってしまうのだけど他に解がないので、またもやDropboxを使う。

DropboxはLinuxサーバー上でも使えるのでLinuxサーバーにインストールする手もあるが、常に常駐させておくとメモリー使用量も大きいし、バックアップを毎時やるのでなければ常駐させておくのはエネルギー効率が悪い。

アップデートする時だけ常駐させ、アップデート終了したら終了させるシェルスクリプトを書けばいいかと思っていたら、こんなのがあった。Dropbox Uploader …curlさえ入っていれば動くBashスクリプト。Dropboxをインストールする必要すらない。

まずはバックアップの準備。

#!/bin/sh
tar -C / -czf /バックアップディレクトリ/wwwdata.tar var/www/(backuptarget)
mysqldump -u ユーザーID -pパスワード -x データベース名 | gzip >
/(backupdir)/db.mysql.dump.gz

これでバックアップ対象のHTMLファイルとデータベースがバックアップディレクトリに２つのファイルに保存される。

#!/bin/sh
TODAY=`date '+%d'`
cp /(backupdir)/wwwdata.tar /(backupdir_history)/wwwdata.$TODAY.tar
cp /(backupdir)/db.mysql.dump.gz /(backupdir_history)/db.msql.dump.$TODAY.gz

これでバックアップディレクトリ履歴のディレクトリに www.日付け.tarなどの形式で保存される。以前の状態のデータも1月は保存される（ディスクに容量がなければこの部分は省いてもいいかもしれない）。これはローカルのディスク上でだけ保存して、Dropboxには入れない（容量制限を考えて）。Dropboxには最新ファイルだけ入れる（これだと最新ファイルが壊れていたりすれば終わりなのでもう少し工夫した方がいいかもしれないが）。

#!/bin/sh
echo パスワード | gpg --passphrase-fd 0 --batch -c
/(backupdir)/db.mysql.dump.gz
echo パスワード | gpg --passphrase-fd 0 --batch -c
/(backupdir)/wwwdata.tar
mv /(backupdir)/*.gpg /Dropboxに同期させるディレクトリ

これで設定したパスワードでgpgを使って暗号化される。gpgはLinux版だけでなく、Mac版やWindows版もあるので、どんな環境でもパスワードさえわかれば元のファイルに戻すことが可能。暗号化も不要という場合はこのプロセスも省略可能。

あとは、Dropboxのアカウントを作っておき、curlが入っていればdropbox_uploader.shをコピーして実行する。

シェル上で、./dropbox_uploader.sh と打つと、

This is the first time you run this script.
 Please open this URL from your Browser, and access using your account:

 -> https://www2.dropbox.com/developers/apps

 If you haven't already done, click "Create an App" and fill in the
 form with the following data:

  App name: MyUploader2*********
  Description: What do you want...
  Access level: Full Dropbox

 Now, click on the "Create" button.

 When your new App is successfully created, please insert the
 App Key and App Secret:

 # App key: 

と聞いてくる。シェルを離れて、ブラウザで https://www2.dropbox.com/developers/apps にアクセスし、”I agree with the Dropbox Developer terms and conditions.” をチェックして、Submitボタンを押すと、App name: を聞いてくるので上記のMyUploader2***….をコピーして入れて、Descriptionには自分のサーバーのバックアップだということがわかる文章を入れ、Access levelの選択をFull Dropboxの選択をする。そうすると、App key と App secretを表示するので、それをシェルに戻り、入力する。そうするとシェルの方で、
https://www2.dropbox.com/1/oauth/authorize?oauth_token=********
にアクセスしてAppをDropbox側で承認するように求められるので、ブラウザ上でこのURIを開く。承認ボタンを押せば、設定終了。

あとはとっても簡単

sh dropbox_uploader.sh upload ./Dropbox/*

これでDropboxに保存される。

上記のスクリプトを適当に作って、crontabに登録し、毎朝3時とかサーバー負荷が低いと思われる時に自動実行するように設定しておけばいい。

この方法の助かることはバックアップが無事行われているかオンラインであればどこでもチェックができる（サーバーに装着されたバックアップ装置のチェックよりもはるかに楽）。

もっともバックアップされたファイルの内容が想定している状態になっているかはファイルをダウンロードして確認することは必要だろうけれども。

あとは自分以外でサーバー管理できる人とパスワード情報を共有する必要がある。問題は共有してもサーバーを復元することのできる人がそういないことかもしれない。ただ、できる人が見つかればサイトは復元できるはず。

写真のオンラインギャラリーを実現するオープンソースのサーバーアプリケーション、多数あるけれども、ざっと調べてみて、Piwigo (http://piwigo.org/)が柔軟性も高く、しかもコミュニティの活発さもあって、よさそうだということでインストールしてみた。

MySQL5とPHP5が使えればインストールはきわめて簡単。
写真のアップロードは複数ファイルをまとめてWebインターフェースを通じてすることもできるし、Windows、Mac、Linux対応の専用ソフトpLoaderを使って透かし（watermark）を入れつつアップロードという芸当もできる。

写真の分類は１つの写真を複数のアルバムに入れることができ、しかもアルバムは階層構造、つまり入れ子にできるため、極めて柔軟にフォトライブラリーを構築することができる。

ユーザーごとに権限を指定できる（ただし、顧客によって個別の高解像度を提供したりしなかったり、というような高度な制御は標準機能では無理そう）。

Extensionが多く開発されていて、Facebook、Twitter、Google+などのお馴染みのものはもちろん、たとえばアップした写真をWordPressで表示するとか、ページを完全に多言語対応にするものや、PayPalでの支払いを実現するExtensionもある（PaypalやWordPressのケースはどこまで使えるかはまだ未確認）。

デザインはテーマとしてすでに開発されているものをダウンロードして利用することができる。CSSでのカスタマイズもLocalFiles EditorというExtensionを使うと、ブラウザー上で簡単に書き換えられる。簡単に静止ページを作るExtensionであるAdditional Pagesも便利。

３つの異なる用途にさっそくインストールしてみたが、異なる用途に対応する柔軟さがある。

特にExtended Descriptionは多言語化を可能にするExtensionで、多言語化が不可欠な人には非常に魅力なので、少しメモしておく。

多言語化対応にするExtended Description

Piwigoのメニューは多言語対応している（45言語！[追記]Piwigo 2.3.3でエスペラントが加わり46言語になった）ので、Language SwitchというExtensionを有効化すれば、メニューはすぐに多言語対応になる。

写真のデータやアルバムの表記は基本的に１つしか入力項目がない（データベースの入力項目が１つずつしか存在していない）が、このデータを[lang=defalut]デフォルト言語用[/lang][lang=en]英語用[/lang][lang=ja]日本語[/lang]などという書式で書くことで多言語化するのがこのExtension。

ブラウザーのデフォルト言語の表記が表示され、またLanguage Switchのアイコンで切り替えることでブラウザの設定にはない言語に変更することもできる。

データの入力スペースは言語別に書く欄が分かれておらず、１つの欄に複数の言語のデータをタグと共に入力しなければならないので、入力の手間は大きくなり、管理画面からデータの視認性も少し落ちるが、多言語で組みたいという場合は大きな威力を発揮するだろう。

こうしたすぐれたシステムを見てしまうと、それを使って何か作ってみたくなる。それくらいおもしろい。

その他、いくつか、使う際にカスタマイズする必要を感じるので、そのやり方を記録しておく。

日本語の言語設定のアイコンが日の丸になってしまうことを修正

多国語切り替え（Language Switch）を有効化すると、日の丸が日本語表示のマークになる。
こりゃいやなので、
Piwigoインストールしたディレクトリ/language/ja_JP/ja_JP.jpgを書き換える。

アルバムの領域がクリックできるようにする

トップのページからアルバムをクリックする際、アルバムの文字やサムネイルの写真はクリックできるが、その他の部分はそうではない。アルバムが表示される領域はマウスでポインターを持って行く(hover）で色が変わるので、あたかもその領域をクリックすればそのアルバムが表示されるようになっているように思える。しかし何も変わらないため、人によってはそこから先に行けないと思ってしまうかもしれない。

そこで、文字・サムネイル画像以外のアルバムの領域をクリックしても当該アルバムに飛ぶようにjQueryを使って改造する。

Piwigoのインストールディレクトリ/themes/default/template/header.tpl
{get_combined_scripts load=’header’}
の下に以下を書き加える。

これでアルバムをクリックすれば飛んでくれるはず。

高解像度の写真はダウンロードのアイコンクリックに限るように改造

高解像度が許可されたユーザーに対してはWebページの写真（サムネールよりも大きな個別の写真ページで表示される写真）をクリックすると高解像度の写真が出るようになっている。

しかし、この方法だと高解像度の写真をダウンロードした人が把握できなくなる。高解像度の写真をダウンロードした人をアクセス解析（History追跡機能）で把握したい、しかし、管理者だけは写真クリックで高解像度の写真を表示できるようにという団体のニーズに合わせるため、ソースに手を加えた（管理者には可能にしたのは高解像度の写真のURLが管理者にはすぐにわかるようにするため）。

インストールディレクトリ/themes/default/template/picture_content.tpl
のファイルを書き換える。下記で
{if isset($U_ADMIN)}
{/if}
でくくったところがそれ。

日本語に対応していないExtensionを使う場合

Piwigoインストールしたディレクトリ/plugins/プラグインの名前/language
の下に ja_JP というディレクトリを作り、たぶん存在しているだろうen_USかen_UKのディレクトリーの中味をコピーした上で、plugin.lang.phpなどというファイル名のファイルを翻訳していく。
書式は
$lang[‘Top’] = ‘Top’;
のようになっているので、
$lang[‘Top’] = ‘トップ’;
としてやればいい。

オープンソースの精神に立てば、使う以上、日本語対応させた時はそのプラグイン（Extension）の作者に日本語の翻訳ファイルを送って貢献すべきだろう。しかしものによっては大量の翻訳になるので、全部やろうと思うと大変になることもある。

Extension download_multiの翻訳を修正する

アルバムごとや個々の写真をまとめてダウンロードできるExtension、Download_Multi、便利なプラグインだが、管理画面が英語を選択しても、フランス語のまま。これも上記の方法で、ja_JPディレクトリーを作成して、そこで翻訳すればいい。実はen_UKの翻訳セットは準備されているのだけど、管理画面のところはフランス語のままになっているので、言語設定を変えても管理画面は変わらない。

download_multi/language/ja_JP
に
download_multi/language/en_UK
の内容をコピーして、フランス語になっているものを日本語にしてやればいい。なお、グループは複数選ばなくても、Ctrlを押して指定してやらないと、選択したことにならず、エラーが出て、いつまでたっても設定できないことになってしまうので注意が必要。

翻訳の足りない部分、おかしい部分

バッチ・マネージャーで下記の翻訳が足りないのでlanguage/ja_JP/admin.lang.php に追加。
$lang[‘The whole page’] = ‘このページすべて’;
$lang[‘The whole set’] = ‘すべての写真’;
$lang[‘Who can see this photo?’] = ‘この写真の閲覧許可対象’;

同ファイルで
s/アックション/アクション/ ←アックションと書かれた部分3カ所一括置換
s/アドミニ/管理ページ/

日本語で問題になるかも＝メール文字コード

コンタクトフォーム用のExtensionはあるが、日本語用のメールのExtensionは存在していないので、メールの文字コードはUTF-8になる。今時、ほとんどのメールクライアントはUTF-8は読めると見なせれば問題ないが、そうでない場合、文字化けする。

気になる人はExtension作るしかない。

使用しなかったExtension

LMT

著作権を選択して表示する。よくできているが、単に著作権の種類を表示するだけでなく、カメラマンの写真を預かるような場合、著作権者の名前を保存しなければならない場合、Piwigoのauthorとは別にデータを保存することになってしまい、煩雑になるので、利用をあきらめた。写真によってCreative Commonsの異なるレベルやCopyright (CopyLeft) を使い分けるという時は威力を発揮するかもしれない。

Extended_authorとCopyrights

著作権者をプルダウンで選択できると思ったのだけど、うまくいかなかった。あらかじめ著者情報を入れておけばよかったのだろう。今後使ってみようと思うが、個人的なメモとして残しておく。

いずれにしても、写真を効果的に共有したいという場合にはひじょうに使えるシステムであると思う。今後の発展にも期待したい。

追記: タイトルバナーにHomeへのリンクを追加

タイトルバナーにHomeへの戻りのリンクがないのは使いにくい、ということで

themes/default/template/header.tpl に下記のリンクを追加。こうすると管理画面で書き込むPage bannerの文章にまで同じリンクがかかってしまう（Page bannerで書き込む文章を</a>で始め、その続きの文章のどこかにリンクを設定して最後の</a>を省けば、ちょうどうまく行くんだが…）。またリンク文字の色はテーマによって決めさせた方がいいからここでstyleで書くのは御法度だろうが、何と書けば正解なのか今わからないので暫定的に。

<div id=”theHeader”><a href=”/photos/” style=”text-decoration:none;color:white”>{$PAGE_BANNER}</a></div>

Piwigoに関する情報

:
Piwigo Website: http://piwigo.org/
Twitter: @Piwigo

WordPressでサイトを構築していて、他のブラウザーでは問題が起きないのに、iPadでだけレイアウトが崩れるという現象が起きた。

メインのコラムに右にメニューを置くタイプのレイアウト。他のすべてのブラウザーで想定通りに表示されるのに、iPadだけはメニューが右の位置に入らず、メインのコラムの下に来てしまう。

CSSのwidth、paddingやmarginの設定の問題かと思ってチェックしてみたけど、どうも違う。

相当時間がかかったけど、問題は Viewport の設定であることが判明

このタグをコメントアウトしたら正常に表示された。
横幅が広くないサイトでは問題は起きていない。
仮説だけど、iPadのViewportは980pxであり、1000px超す場合は上記の指定ではおかしくなるということだろうか。

iPadに対する最適化まで余裕が持てないので、とりあえず、上記タグの無効化でよしとしておく。