watermint.org

Travel, camera, photo, and technical things. I work at Dropbox. Thoughts are my own.

[watermint-org]

Dropbox Business utilities written in Golang

今夏ごろからDropbox Business向けのツールをちょこちょこと開発しています。Dropbox Business APIは一般的なOAuth2を使った認証と、HTTPでのAPIのためたいていのプログラミング言語で簡単に扱えます。また、DropboxからPython、Ruby、Java、JavaScript、.NET、Objective-C、SwiftなどSDKもリリースされているのでこれらを使えばより簡単です。

ちなみにこれほど多くのSDKをメンテナンスするのはかなり手間ですが、それを解消するためにStoneというオープンソースが公開されています。StoneはAPI仕様記述からSDKを生成するツールで一度この仕様記述をメンテナンスしていけばSDKは自動生成できます。Dropbox APIの仕様についても同様にStoneでの仕様記述があり、公開されているSDKは自動生成されたものをベースにしています。

つくったツール

作成したのは下記二つのツールです。

dcfg … G Suiteのグループで管理されている組織、グループ構成をDropbox Businessチーム用に同期する

dreport … Dropbox Businessチームに関するメンバー一覧などをレポートとしてCSVで出力する

いずれもCLIツールでシステム管理者が利用する想定のものです。ただ、昨今はシステム管理といってもWindowsだけでなくMacなど様々なシステム環境があります。このように利用用途からかんがえて複数プラットホームで利用できたほうが便利なので、個人的には初めてとなるGolangを採用してみました。

はじめてのGolang

一番最近よく使っていたプログラミング言語はScalaだったので、カルチャーギャップというか、プログラミング言語がもつ信念のようなところに大きな差があって少し戸惑いました。

Scalaのようなオブジェクト指向的にも関数型的にもかけるプログラミング言語の直後ということもあって、Golangの書き方はややまどろっこしく感じます。ただこのまどろっこしさも次第に慣れていくことで、また考え方がわかってきたことでさほど気にならなくなってきました。

どこに書いてあったかソースは失念しましたがたとえば、「関数のなかで、計算量のオーダーが O(1) → O(n)のように変わるような書き方はあえてさせないことで、関数を使う側がどういうオーダーの計算量を常に意識させるようにしている」というような説明がありました。Golangのテストフレームワークがassertをあえて実装していない、といったこともそうですが、プログラミング言語やフレームワークで様々なヒューマンエラーを減らしていこうとする考え方とはまた違う思想を感じます。

この考え方を真に受けてコードを書いていったので、でき上がったプログラムはにたようなforループやif分岐がたくさんでき上がりました。今回、コードをかくに当たってあまり他の方のコードを読んだりしなかったので本流とはだいぶ外れているかもしれません。

パッケージ管理

Golangで戸惑ったのがパッケージ管理です。GoのプログラムはGOPATH環境変数で指定したディレクトリ以下にすべての依存ファイル、そして自分のプロジェクトファイルも置いていくという方式です。

自分のプロジェクトをたとえば、github.com/watermint/dcfg で公開する予定ならば下図のように GOPATH以下に置いていきます。外部ライブラリたとえば、github.com/dropbox/dropbox-sdk-go-unofficialを使うのであればこれらもgo getコマンドを経由して同様にGOPATH以下に配置します。

$GOPATH / src / github.com / watermint / dcfg

ひょっとすると、Goの考え方でAPIは一度公開したならば同じ名前で同じように使えるべき。という信念があるのかもしれません。 この方式で困るのは複数プロジェクトを進行しているときに、異なるバージョンのライブラリを利用したいや、ライブラリのバージョンをしばらく固定しておきたいときにはやっかいです。

また別の環境でビルドする際にも依存するライブラリの管理が煩雑になります。こういった問題に対しRubyであればgem、Javaなどではmaven、gradle、sbtなどパッケージ管理は様々あり、これらで管理するのが当たり前という風なイメージを持っています。Golangでも同じようなものを探してみましたが、いまひとつこれといったものがどれなのかわかりませんでした。

これも今回はあまり細かく調べずに、glideというツールを利用しました。glideをつかうと、依存するライブラリ郡を自分のプロジェクトフォルダ以下のvendorというフォルダにまとめてくれます。バージョン指定も可能ですし、一括してライブラリ郡をダウンロードするなど細々面倒を見てくれます。

また今回つかったdropbox-go-sdk-unofficialは名前の通りアンオフィシャルSDKで、まだ活発に大規模なリファクタリングがおこなわれていてバージョンを固定しないとまともに開発できない。。という現状もありglideによるパッケージ管理はもっとはやく導入しておけばと悔やまれました。

おそらく他のツールでも同様によしなに準備してくれるのだと思います。

ビルド

本格的にコーディングを始める前に、ビルド環境だけは念入りに準備することにしました。ビルド環境のOSのバージョンが違うことで何か問題がでたりするとかなりの時間を浪費してしまいますし、いろんなところで新しくビルドしようとおもったときにも手間がかかります。

今回はご多分に漏れずDockerを使っています。Dockerfileを用意しておいて、Dockerコンテナ上でビルドをしてそのバイナリを手元環境でテストするというワークフローを確立しました。

ついでにTravis CIでもテストが自動的に実行されるようにしておきました。テストカバレッジなども集計するという流れを自動化しておくこともできますが、これもなかなか情報が分散していて地味に手間のかかる作業でした。

これから環境を用意されようと思われる方は下記の.travis.ymlをご参考にしていただければと思います。

https://github.com/watermint/dcfg/blob/v1.3.9/.travis.yml

ここで登場するcover、gover、goverallsはカバレッジを取得、集約するためのものです。よく見るとgoverは前職の同僚が作ったものですね。こんなところでお目にかかるとは誇らしいものです。

ところでscript:のセクションはややトリッキーな書き方をしています。これもあれこれ情報を集めながら試行錯誤したものでこれでいいのか微妙なところですがひとまず動作しているのでこれで。。

- go list -f '{{if len .TestGoFiles}}"go test -coverprofile={{.Dir}}/.coverprofile {{.ImportPath}}"{{end}}' $(glide novendor) | xargs -L 1 sh -c

go testというのでカバレッジがとれますが残念ながらgo testでは1つのソースファイルについてのみテストとカバレッジ測定となってプロジェクト全体ではとれません。そこで、ソースコードひとつずつについてgo testを実行してカバレッジデータのファイルを個別につくってあとで結合するという力技です。

Retrospective

今回はCLIツールを作りましたが、利用シーンを考えるとGUIツールもぜひ作ってみたいところです。 GolangでのGUIライブラリはまだこれといった決定打がないようで、ひょっとしたらJavaでつくるか、SwiftをつかってiOSアプリにしてしまうほうがいいのかもしれません。

今回CLIとは別にhttps://github.com/gin-gonic/ginというライブラリを使ってWebサーバを立ち上げるパターンも試作してみました。Play framework等と比べればまだまだツールサポートなども弱いので生産性に課題を感じましたがしっかり作り込めばGUIでつくるよりも将来性がありそうです。

このあたりはまた次回の研究課題です。

[watermint-org]

10万枚を超える写真データの整理とストレージ選び

最初にデジタル一眼レフを買ったのがちょうど10年前。カメラも、ハードディスクも順調に増え場所も手間もかかるようになってしまったので写真の整理法から、ストレージの使い方まで半年がかりでやり方をかえていきました。

事前準備

最初はすこし軽い気持ちで始めましたが、結果的にはかなり大掛かりな作業になってしましました。

データ容量、内容の確認

ファイル形式の統一

重複の排除

ファイルの分類

新しいストレージへの移行

最初から最終形態を設計／想定していた訳ではありませんが、随時微調整しながら進めています。

整理を始める前のデータと容量

ハードディスクを整理してみると、ハードディスクはNASに搭載しているものもあわせると15本、NASは2台、総容量は30TBと一般家庭にしてはかなりの容量です。それぞれのディスクのおおよそ6〜7割は使用中で単純計算で18TBものデータが存在していました。

ただそのほとんどはバックアップ用途の重複保存です。同じデータを最低2本以上のディスクに保存することにしていたので、単純計算でデータ容量は9TB程度です。 またさらに、写真管理ソフトの形式によって重複している部分もありました。写真の管理は2001年ごろからはiPhoto、2007年ごろからはAperture、2013年からはCapture Oneを使っていました。2013年は少しだけLightroomも使っていたのでこのデータもありました。

Apertureのサポート終了に伴う移行では最終的に、Capture Oneに落ち着きましたが慣れの問題もあり最終的にCapture Oneに一本化できたのは2014年後半でした。この間、データはAperture形式とCapture One形式の二通りのライブラリとして管理していました。

ここまでの見積もりメタデータやサムネイルファイル、重複などををおおまかに調査したところ最終的なファイルサイズはおおよそ3〜4TB程度になると見積もりました。

整理を始める前の写真

もう一つの問題点は、簡単には狙った写真が見つけられないということです。連射した写真や似たような構図の写真が大量にあると、毎回無視できないほど時間がかかります。多いときには1日に1,000枚以上撮影していることもあり写真を見直すことがおっくうになってきますが、そのように大量に撮影しているときにいい写真があるのでまたもどかしい気持ちになります。

たとえば3年前の旅行で撮った写真を加工して印刷したい、といったときに該当のRAWデータを見つけるのは結構な手間がかかりました。1週間の旅行で5,000〜7,000枚程度の枚数にはなるので、ApertureやCapture Oneのライブラリを開くだけでもしっかりと時間がかかります。

撮影当時にApertureやCapture Oneで調整した結果からさらに編集したいとき、目的のApertureライブラリやCapture Oneセッションを探し出すというのはかなりの労力がかかりました。仕方なく、現像済みJPEGから再調整するということもありましたがせっかくRAWで保存してあるのに活用できないのはもったいない気がします。

このように整理を始める前はデータも、写真自体も管理がばらばらで再利用するのがとにかく面倒で、一念発起しないとできない。という状況でした。

目標と方針を決める

写真を撮るのは楽しいですが、整理するのは面倒だと感じています。写真は趣味で、ビジネスとして撮っているわけではないので、整理に割ける時間も限られます。趣味の範囲という前提に立つと「写真を撮るのも、後から見ることも楽しい」ぐらいが目標となり、このための雑務を減らし、秩序をつくっていくことがアクションとして考えられます。

この目標実現のために最初に決めた方針は次のようなことでした。

資産として再利用できるようにする。

フラットな構造に管理する。たとえば、複数のディスクに分散しないようにする。

すでに機械化されている、または将来機械化されそうな作業をしなくて良いようにする。

NASからの移行

まずは重複を排除しつつ、データを一ヶ所にまとめることにしました。3年まえからほとんどのデータは、NASのDrobo 5N (実効容量9TB)にまとめていました。このNAS上にすべてのディスクにあるデータをまとめ、整理していくのが順当ではあったのですが一つ問題がありました。

Mac OS XはNASへのアクセス性能がきわめて悪いことです。データ転送などある程度まとまった処理はさほど悪くないのですが、ファイル一覧などファイルを探す処理が極端に遅いのです。 Finderでファイル一覧を開くだけで数十秒〜数分かかることもあり作業に大きな支障がありました。通常、NASをMac OS Xから参照するとAFP (Apple File Protocol)で接続されます。これを、SMB2というプロトコルに変更すると若干改善するように見えるのですが、それでも体感速度はさほど変わりませんでした。Drobo 5NではmSSDを使ったキャッシュを搭載することができますが、このキャッシュを搭載してみてもさほど体感上変わりはありませんでした。

かわりに、Mac OS X上のVirtualBoxにUbuntu Trustyをインストールし、SMBクライアントでマウントしてみると見違えるように高速に動作し原因はMac OS Xの問題とほぼ限定されました。実際に、Mac OS Xからrsyncなどのコマンドでファイル転送してもシステムコールレベルでNAS側に制御ファイルを作成したり削除しているような振るまいが見られこのオペレーションが低速につながっていると想像できました。

作業をUbuntu上で行うことも選択肢にはありましたが、Capture OneやApertureなどMac OS X上のアプリケーションも利用する必要があることから、Drobo 5Nに集約することはあきらめて6TBのハードディスクを新たに購入しここにすべてのデータを集約することにしました。

Drobo 5Nの純粋な性能と比べても、ネットワーク越しのアクセスとUSB 3.0の直接接続では大きくスループットも違いがでます。

データのコピーとデータ形式の統一

データのコピーは基本的にすべてrsyncコマンドを使いました。信頼性があるのと、中断せざるを得ないときにも停止して安全に再開することもできます。Mac OS Xの性能問題もあり、コピーは基本的にUbuntu上で行いました。それでもDrobo 5Nからの転送はおおよそ1〜2週間程度かかったと思います。

最初にApertureライブラリを転送しました。Capture OneにApetureライブラリをインポートする機能もあるので、こういった機能も使いつつJPEG、TIFF、RAWファイルなどの元データとメタデータをApertureに依存しない形式に変換していきました。この作業も1〜2週間かかったと思います。

Capture OneはEIPというファイル形式で出力することができます。EIPはRAWデータ、メタデータ、調整データをすべてひとつのファイルにまとめたものです。EIPファイルさえあれば、調整データもメタデータも含め写真1枚ずつ開いて加工することができます。EIPファイルの実態はZIPファイルで、中にはRAWデータや調整データを含むファイルが格納されています。

Apertureのライブラリ、Lightroomのライブラリ、Capture Oneのライブラリはそれぞれライブラリとして一つ大きなパッケージとして管理するので操作が高速であったり、アルバム管理など便利ですがEIPファイルのように1枚一枚別々に管理できるとApertureやCapture Oneなど専用ソフトでなくても操作できるので、後述の重複排除など操作では重宝します。

このように、Capture OneのデータはEIP、ApertureのデータはRAW + XMPファイルとしてエクスポートして一ヶ所にまとめることができました。

重複排除

重複排除にはGeminiというアプリケーションを利用しました。ファイル数が多すぎるとUI操作がもたつくこともありますが、操作がわかりやすいのとファイルをプレビューしながら操作できる点が大きなメリットです。

Geminiでおおまかに重複排除したあとは自作のスクリプトで重複排除を進めました。RAWから現像したファイルはいったん削除することにしたので、EXIFデータを見ながら日時、カメラなどのデータが一致するJPEGファイルを削除。他には、前述のEIPファイルではZIPファイル中にRAWファイルがあるため、Gemini等の重複排除では期待通り重複を排除できないためEIPファイル中のRAWファイルデータを読み出して比較しながら重複排除するスクリプトなどを作成しました。

99%以上のファイルは有効なEXIFデータが入っているのですが、かなり古いデジカメで撮影した写真などデータが含まれていなかったり、EXIFなどのデータが破損している場合があったのでこういったファイルはそれぞれ目視確認しつつ作業を進めました。

このような作業を繰り返し重複排除が終わったときには13万枚程度の写真ファイルが整然と並びようやく全貌が明らかになりました。

分類する

写真をおおまかに2つのグループにわけることにしました。1つは、何度も見返したい写真。もうひとつはそれ以外の写真のグループです。

何度も見返したい写真は比較的しっかりバックアップがとられるように管理したい写真で、それ以外の写真は最悪なくなっても気にしないといったポリシーで管理することにしました。

グループ分けの考え方

「すでに機械化されている、または将来機械化されそうな作業をしなくて良いようにする。」という方針から、写真のレーティングで機械化されそうなところは機械にたよることにしました。

たとえば写真のなかの顔認識についてはかなり技術的に進んでいて、特定の人が写っている写真を撮り出すということは今日たやすい操作です。この画像認識技術はまだ多少精度の問題もあります。生物や植物の図鑑をつくるような目的である程度厳密に分類をするといった用途には向きません。今回の目的は必要な写真をすぐ見つけたい。というぐらいですから、多少違う写真がピックアップされたところであまり影響ありません。

Siriのようなアシスタントに「AさんとBさんが写っている去年の集合写真をさがして」とか「Cさんが写っている沖縄の海辺の写真を探して」といったら数枚がピックアップされ、ピックアップされた数枚から「ピンボケしていないものだけ」といった絞り込みもそう遠くない未来に実現するでしょう。

すでにGoogle Photosやflickrでも機械学習などの成果から「建築物」とか「食べ物」と自動的に分類したり、GPSデータがなくても建造物などから場所を推測してタグ付けするといったサービスが提供されていますのでこういった分類は手作業で時間をかける必要はありません。

今回の写真整理では利用しませんでしたが顔と名前、人のつながり、時間や場所とイベントといった付加情報のデータベースについていえばfacebookが圧倒的に大きなデータベースを持っているので、facebookが面白い提案をしてくるかもしれません。

一方すぐに機械化できないと思うのは個人的な体験による重要度の重みづけです。何の変哲もない風景写真だが自分には印象深いとか、ピンボケしているが人生の大きなターニングポイントのタイミングを象徴するとかデータとして記録していないし、定型的な表現の難しい体験による重要度はいかに機械化による分類はやや難しいでしょう。facebookやtwitterなどに記録されたイベント、発言など複合的に機械学習することでおもしろい写真の組み合わせを提案する。といったことはできたとしても、自分の印象に残ったあの写真を探す。というのとは少し方向性がちがうと思うからです。

レーティング

こう考えると機械化できるところは機械に任せるとして、印象深いシーンのみをピックアップして分類していくということにしました。ピックアップする際にはApertureやCapture Oneでは★1〜5のようにレーティングをつけることができますが、これを利用しています。

過去にもレーティングをつけていましたが統一した基準をもっていませんでした。このため時期によってほぼ★1〜3しかつかっていないとき、★3を平均として1〜5の範囲で使っているときとばらつきが生まれていました。前述の通り、個人的な体験による重要度を尺度とするので時間の経過とともに重要度が下がっているものもあれば、重要度が上がるものもあります。

たとえば、スキューバダイビングをしていて最初のころは何でもすべて珍しい魚、地形と感じ、重要と位置づけていますが、次第に慣れてくると、同じ魚／地形でも天候や構図などが優れた場合が重要であるというように変化することもあります。

レーティングは新しく★3を平均点として、★4を優秀、★5は最優秀としてつけることにしました。厳密な定義はありませんが、★5は印刷して壁に飾っておきたいような写真、★4はパソコンやスマートフォンのデスクトップ画像にしたいような写真といった感覚で点数をつけています。

★2は★3相当だが構図が似ているのでボツ、★1はピンボケや構図がかなりわるいといった使い分けです。全部の写真にレーティングをつけると面倒なので、★3以上だなとおもうときだけレーティングをつけ、同じシーンで似たような構図が多いなとおもったら★2に下げるといった調整をしています。

枚数の比率としては★1〜★2相当の枚数くらべ★3以上の枚数が1/10以下になるよう目標として、全部で13万枚ありましたので★3以上は1万枚以下を目標として調整しました。この作業が最も時間がかかり2ヶ月以上かかりましたが結果として★3はおおよそ6,000枚、★4はおおよそ700枚、★5は60枚と目標通りの枚数に調整できました。

10数年分で7,000枚、デジタル一眼レフを使い始めた近年でも1年当たり1,000枚前後となったので見通しはかなりよくなりました。

最終的に容量にして★3以上の写真は170GB、★なし〜2の写真は2TB弱とかなりコンパクト化することができました。

ストレージ

写真の保存としてこれまでRAWデータは自宅のNASやUSB接続のハードディスクに、現像済みのJPEGデータはflickrに保管していました。

今回はRAWデータも含めてクラウドストレージ上に管理することにしました。使ったのは次のストレージです。

Amazon Drive : Amazonプライム会員になると写真データは無制限に保存することができるのでCaptureとした★2以下の写真を置きます。無制限となるのはJPEGだけでなく、NEF、ARWなどRAWファイルも対象となりますが、EIP形式などは対象外なのでEIPではなくもとのNEF/ARWなどのRAWファイルに変換しておきます。

Dropbox : EIP形式にしたRAWファイルと調整済みの現像JPEGデータを保存しておきます。★3以上の写真のみ置きます。Dropboxはバージョン履歴をとれるので、編集履歴も自動的に保存されるのが利点です。

flickr : flickrにはほぼすべての現像データがすべて置いてあります。flickrは使い始めてちょうど10年ほどになりますが、容量無制限のころのProアカウントを利用しているので気兼ねなくアップロードすることができます。flickrも機械学習による自動分類ができるので発見目的に利用しています。

Google Photos : オリジナル解像度ではなく、Googleの設定した解像度以下であれば無制限に置くことができます。機械学習により自動分類されるのでここにも★2以下の写真を置きます。

多くのクラウドストレージは1TB程度以内までと容量制限がありますが、今回★3以上と★なし〜★2のように分類したことで★3以上の部分(約170GB分)については選択肢が大きく広がりました。Dropboxのようなクラウドストレージを使えばバックアップも気にすることなく自動的にとられているので大量のハードディスクやNASを管理する必要がなくなりました。

新しいワークフロー

こういった整理を進めながらも写真は日々ふえていきましたが、最終的な保存場所がきまったことでワークフローが整いました。写真を撮影したら、新しいCapture Oneのセッションを作成します。このCapture OneのセッションファイルはDropbox上に置き、すべてのファイルがDropbox上にバックアップされるようにします。

次にレーティングをつけて、★3以上の写真については調整と現像を行いEIP形式への変換などをしたうえで所定のディレクトリにエクスポートします。現像データはflickrにアップロードします。 ★なし〜★2の写真についてはRAWデータを所定の場所におきAmazon DriveとGoogle Photosにアップロードされるようにします。

ここまでの作業が完了したら該当のCapture Oneセッションは削除します。Dropbox上に削除済みファイルも保存されているので必要とあらば再度取り出せますから、心置きなく削除してしまいます。

整理をおえて

今回の整理をおえて当初もくろんだ通り、再利用については非常にやりやすくなりました。2012年の旅行写真をとりだして編集するといった基本的な操作がストレス無くできるようになりました。Google PhotosをつかってAさんが写っている写真、といったような写真のとりだしかたもできるようになりました。

まだ新しいワークフローにしてまもないこともあり、AmazonやGoogleへのアップロード作業など一部自動化できていない部分もありますが最初からDropboxに保存することでクラウド上で処理できることも多くなりました。

Dropboxに追加されたら自動的にデフォルトのレシピで現像して、Amazon、Google、flickrにアップロードするとか、レーティング情報が追加されたら長期保存対象として所定のディレクトリに置くといった仕組みを作ることもできると思います。

[watermint-org]

考えるためのツール選び (ノートからカードへ)

ちょうど使っていたノートの残りページが少なくなってきたタイミングで、書籍「知的生産の技術」を読んだことが影響して、使うノートをカード(断裁紙)に変えてみることにしました。知的生産の技術は初版が1969年と約50年ほどまえの内容ですが、今回は加えてパソコンやスマートフォンをつかったデジタル端末と連携した使い方を整理してみます。

カードとは

本エントリーでいうカードとは、特別なものではなくノートのように綴られていない1枚一枚ばらばらの紙(断裁紙)のことです。「知的生産の技術」ではB6サイズで、やや厚みのある紙(105kg)、9mmの罫線がはいったものが紹介されています。これは「京大式カード」としていまでも文具店で売られています。今回はいくつか検討した結果A5サイズ、5mmドット方眼を使うことにしました。

このような紙の片面だけに内容を書きます。ややもったいない気がしますが、両面は使いません。カードの使い方や、カードにつかう紙については後述します。

なぜカードにするか

2008年頃からノートはミドリのMDノートというのを使っていました。サイズはA5のものを主に使っています。

素朴なデザイン、クリーム色がかった紙、万年筆で書いたときも気持ちが良いなどいくつか気に入る要素があったのがこの8年ほど使い続けていた理由です。ノートは主に議事メモや計算、思考実験などいろいろな用途に使っていました。ただ近年、いくつか不便だと感じるところも増えてきました。

「知的生産の技術」にもいくつかノートよりもカードの方が優れている点が紹介されていますが、読みながら自分で気付いた理由を以下にご紹介します。

前ページに書いた内容を振り返りながら考えるのが面倒

考え中、まとめ中の内容を前ページと何度も往復しながら進めるのはかなり面倒です。できれば10ページ分ぐらいの情報量を一覧して考えたいのに、何度もページをめくらないといけないので考えが中断されてしまうのがもどかしいところでした。

特に多かったのはアプリケーションの設計をしているときにあるページにはデプロイ図、あるページにはクラス図、あるページには重要な処理のシーケンスなどを描いていたとしてこれらが一度に参照できないと一貫性があるかどうか確認できないといったケースです。

対策としてよりA4／A3サイズとか、大きめの画用紙を用意するなど紙を大きくすることで一部解消していましたが、保管する際にサイズが違うと扱いに困ったり、必要なときに大きな紙が手元にないなど完全な解消とは言えませんでした。

カードであれば机いっぱいにカードを広げてあれこれ比較しながら考えることができます。ちなみに、カードの両面を使ってしまうとこのように広げて比較するときに結局ぺらぺらめくりながらとなるのでノートで味わった不便さを引き継いでしまいます。もったいないですが贅沢にカードを片面だけを利用します。

不必要な情報を持ち歩きたくないときに困る

特に仕事上のメモが入ったノートをどう取り扱うかは悩ましいところです。パソコンやモバイルデバイスであれば暗号化やパスコードロック、遠隔から削除するなどいくつも防御手段があるので安全ですが、紙媒体ではどこかに置き忘れてしまうとどうにもなりません。

このため、仕事で使うノートは基本的に会社の机や棚に入れて施錠しておくことになります。用途ごとなどでノートを分離しすぎると持ち歩きや管理が面倒なのでできれば一冊にまとめたいのですが、会社のセキュリティーレベルで保管しておきたいのであれば分離するしかありません。

仕事用ノートには仕事上のメモだけではなく読書備忘録などを記録することもあるのですが、読書備忘録だけ持ち帰りたくてもやぶってもって帰るわけにも行かないのでやむなく持ち帰らないという選択をするしかありませんでした。

カードであれば行き先と用事にあわせて取捨選択できるのでこういった悩みがなくなります。仕事用カードは仕事場に施錠しておいておき、残りの読書備忘録や旅行メモなどはいつでも好きなように持ち歩けます。ささいな悩みもチリも積もれば大きなストレスになるのでカードの利用は大きな安心感があります。

スキャンしづらい

ノートは物理的に保管スペースもとるのと、持ち歩かないと参照できないのでやや不便です。 先月読んだ本から思いついたアイデアって何だったっけ? といった振り返りができないのではせっかくメモしても役に立ちません。こういうデータはDropboxなどクラウド上に保存して持ち歩きたいのでスキャンしています。

スキャンするのに1ページ、2ページ程度をスキャンするのはノートでも簡単ですが複数ページとなると面倒です。断裁紙であればScanSnapなどのスキャナで連続してスムースにスキャンできるのでデジタル化の手間が省けます。なお断裁紙でもパンチ穴があると穴にひっかかってうまく紙が送られないということもあるので穴をあけずに使います。

カードの使い方

カードの使い方は「知的生産の技術」に紹介されている内容をほぼ踏襲しています。次のようなことを心がけて使います。以下のような使い方を心がけているのはメモや考えを再利用しやすくするためです。

1枚に1件のトピックのみ書く

慣れるまで抵抗感がありますが、余白があっても別のトピックであれば別の紙に書きます。これは自分のまとめた情報を取捨選択したり並び替えたりして新しくアイデアをまとめていくことを重視するためです。

カードの片面のみ使う

いくつかのカードを一覧にして比較検討したいので両面使ってしまうと煩雑になります。また、異なるセキュリティーレベル（仕事用と個人用）の情報が混じったりすると管理が煩雑になるのでカードは片面だけを利用します。

カードにはなるべく文章で書く

ある程度時間が経つと自分で書いた文章でもメモの意味がわからなくなり、メモの意味がなくなってしまうといったことがあります。 議事録など議事進行に合わせてある程度速記的に書いたものは新たなカードに文章としてまとめなおしておきます。

ただ、「知的生産の技術」が書かれた時代(初版1969年)と違い現在ではパソコンやスマートフォンなどを用いて手書きよりも効率良く長文を書くことができますので、かなり長文になるようであれば迷わずパソコンを使ったほうがいいでしょう。 議事録であれば参加者などに共有する場合に手書きより電子データの方が便利です。紙に書いたメモと電子的に書いたメモをどう管理するかについてはまた別の機会に書くことにします。

日付(年月日)とタイトルを書く

カードがある程度たまって整理するときに日付やタイトルがないと内容の判断が面倒になります。いま考えようとしているトピックと関連があるのかないのか簡単に判断できるよう、面倒でも必ず記入しておいたほうがいいでしょう。また同じトピックについて複数枚ある場合は連番を振っておくべきです。

「知的生産の技術」にも書かれていましたが、日付については月日だけでなく年も書いておくべきです。個人的にも3〜4年前からは年も含めて書いていますが、年を記入していなかったときのメモは再利用するのに苦労します。特に時系列にそって整理し直そうとすると大変です。

日付についての書き方はいろいろありますが、個人的にはISO 8601の拡張形式 YYYY-MM-DDを使っています。これはある程度好みの問題ですが個人的には下記のような理由でYYYY-MM-DDにしています。

YYYYMMDDのように区切りがない場合は判読しづらい。

YYYY年MM月DD日や平成YY年MM月DD日のように漢字や和暦を使ってもよいが、手書きのときには面倒。

スキャンしたカードのファイル名も合わせたいが、YYYY.MM.DDのようなドット区切では一部ソフトウエアでうまく扱えないことがある。ハイフン区切りでは問題が起きにくい。

May 1st, 2016のように英語表記では電子化したときのファイル名を使った時系列のソートが面倒。

カードに使う紙を選ぶ

カードに使う紙をどれにするかあれこれ考えました。文具好きにはたまらない時間です。単に趣味の選択というほかに、カードとして利用するためにいくつか条件を考えました。

調達しやすさ

整理して再利用していくため、または記録を資産として残していくために利用したいので10、20年と長期的に販売されているものを選びたいものです。そのほかに、出先で紙が足りなくなって追加で手に入れられないというのももどかしいですから調達しやすさは重要な評価ポイントです。

厚さや紙質は多少変わっても構わないのですが、サイズがばらばらになると扱いづらくなるので調達しやすいサイズの紙を選ぶことにします。モレスキンのラージサイズ(A5より少しスリムな130x210mm)は持ち運ぶときに絶妙なサイズでとても魅力的だったのですが、断裁紙の状態で販売されているのをみつけることができなかったので断念しました。

「知的生産の技術」でふれられているB6サイズの京大式カードは都内の文具店を何店舗か回ってみたところ、きちんと数えていませんが2〜3割程度の店舗でおいているような印象がありました。

takeopaperのようなさまざまなサンプルから好みのサイズにカットして納品してもらえるようなサービスもあります。このため必ずしも標準サイズにこだわる必要はありませんが収納文具など周辺をととのえることまで考えれば標準サイズのほうがより手軽です。

どのサイズにするか

調達しやすいサイズとなると必然的にA4、A5、A6、B5、B6サイズなどの標準的な断裁紙を選ぶことになります。標準サイズを使えばクリアフォルダーやファイルなど収納文具も無理なく使えるので効率的です。

京大式カードのようにB6サイズは野外など立った状態でも使うことを想定して小さすぎず大きすぎずという選び方に適しています。

一方、いま野外など立った状態でメモするのであればスマートフォンを使うのが最も手っ取り早く、煩わしさがありません。このため、野外などで軽くメモをしたいという用途は縮小し、デスク上で使うことを主な利用シーンと想定しました。

このためB6サイズ(128x182mm)よりやや大きいA5サイズ(148x210mm)を使うことにしました。もともと使っていたMDノートもA5を最もよく使っていたので使い慣れているということもあります。

紙選び

まず、ちょうど紙選びをしていたときに日本橋三越の世界の万年筆祭という催事に神戸派計画というブランドが出店していたのでのぞいてきました。GRAPHILOという万年筆用紙が展示されており、試し書きもさせていただきました。ちょうどA5サイズの断裁紙もおいていたので、横に置いてあったLiscio-1と合わせて買ってきました。

価格はLiscio-1が100枚で800円(税抜)、GRAPHILOが50枚で800円(税抜)とGRAPHILOはかなり高級感があります。厚みや重さなど詳しく書いていないのでわかりませんが、目測では厚みはどちらもほぼ同じで、おそらくモレスキンやMDノートなどともさほど大きな変わりはないかと思います。

後から知ったことですが残念ながらLiscio-1は在庫限りのようで今後はGRAPHILOに統一されていくようです。どちらも100枚ずつ使ってみた時点の好みでは、Liscio-1のほうが好みだったのでこれは残念でした。GRAPHILOは非常になめらかで気持ちいいのですが、すこしざらつきがあったほうが個人的には書きやすいと感じたためです。

次に試したのがMDノートを出しているミドリからMDノートの断裁紙版、MD用紙A5 100枚パックです。こちらはオンラインストア限定で売られていますが100枚で400円(税抜)と神戸派計画と比べてもかなり手ごろです。MDノートだと176ページ(88枚)で800円程度ですからノートと比べるとさらにお得感があります。

MD用紙がいつまで手に入るかはわかりませんが、ひとまず今回の紙選びではMD用紙をメインにすることにしました。

持ち運び

ノートのように表紙がないと紙がぐちゃぐちゃになってしまうので持ち運び用の工夫が必要です。最初はA5サイズのプラスチック下敷き2枚でサンドイッチにすればよいかと考えていましたが、実際に文具店でプラスチック下敷きをみてみると比較的やわらかいものがおおいのでカッティングマットを使うことにしました。

カッティングマットだと硬さも申し分なく、適度にしっとりと手になじむのが好印象です。このカッティングマットをゴムバンドでとめて持ち歩いています。十分に硬いので、クリップボードを使うように立ち姿勢でメモを取ることもできます。

ドット方眼

方眼の大きさや濃さなどかなり好みの分かれるところだと思います。モレスキンの方眼は個人的には方眼が濃すぎるので好みではありません。MDノートの方眼は適度に薄く、あまり主張しないので長年気に入って使っています。

罫線のいれかたも、端から端までびっしり線がかかれているのはあまり好みではありません。厳密に書かなければいけないという印象があるからかもしれません。

MDノートがイメージしている原稿用紙のマス目ようにひとマスごとわずかに隙間が空いているほうが圧迫感を感じないので書きやすく感じます。

最初、断裁紙を探す際も好みの方眼のはいったA5サイズものを探していましたが全く見つかりませんでした。このため方眼についてはあきらめて、無地の断裁紙を買った上で自宅のプリンターで印刷することにしました。

個人的には5mm方眼でぱっと判別できるかどうかぎりぎりぐらい薄い方眼が好みです。印字するときも薄ければインクをあまり使わないので経済的です。

ノートからカードへ変更した効果

ノートからカードにしたことでどのぐらい生産性が上がったとか、時間が節約できたかといった定量的なデータはとらなかったのではっきりとはわかりません。ただ、前後のページをぱらぱらめくるような思考の妨げがなくなったこと、情報の取捨選択が簡単になったことは実感として確かなものがあります。

スキャンしたカードのファイルをどう管理するか、スキャン済みのカードをどう整理するか、そもそも大量のカードをどう管理するかといった課題についてはもう少し長期間試行錯誤する必要がありそうです。

考える時間と質

成果物の品質があがったかどうかの客観的判断は難しいところですが、自己満足レベルではかなり効果があったと思っています。「知的生産の技術」にもふれられていますが、なにかものを作り出すための時間においてはいかにわずらわしさをなくすかが影響を与えます。今回ノートからカードにしたことによって、本エントリーでふれたいくつかのわずらわしさがなくなりました。これにより思考が途切れることなく考えることに集中できるようになりました。

[watermint-org]

英辞郎テキストをDictionary.app用に変換

8年ほど前にも同様に、英辞郎の非暗号化テキストを購入してMac OS X標準辞書アプリ(Dictionary.app)向けにデータを変換して長らく利用していました。今回、ひさしぶりに新しくデータを購入して作り直すことにしました。

英辞郎サイトによれば、非暗号化テキストデータはバージョン145以降販売される予定はなく、最新版は144.1とのことです。いまはわざわざ自分で変換しなくとも英辞郎 for OS X Dictionary.appとして販売されていますので面倒だとか、ターミナルからコマンドをうつという作業にぴんとこない方はこちらを購入されるのが良いでしょう。辞書データのバージョンも新しいです。

一方、個人的にはすこし表示をカスタマイズしたいなという気持ちもありましたので今回は少し古いですがテキストデータを購入し、データを作り直すことにしました。

今回やりたかったところは

品詞(名詞、動詞等)ごとの表示整理

読みがなをルビとして表示

カナによる発音、大学入試のような記号は不要なので省略

といったところです。あとは文字サイズや色のテイストをOS X標準インストールされているウィズダム等とにたようなものにそろえたいと いったところです。完成形は下記のようなイメージです。品詞については、単語によって若干表現ゆれがあったので、一度ソートし直して番号を振り直しています。

変換方法とスクリプトについてはGithubにおいてあります。MITライセンスとしましたのでご自由にご利用ください。辞書データ全体について表示の確認をしているわけではないのでくずれている部分もあるかと思いますが、気になる方は随時修正いただければ。

watermint/eijiro

[watermint-org]

書評: 僕たちのゲーム史

僕たちのゲーム史

40年程度のビデオゲームの歴史を膨大な文献から、ゲーム発売当時の状況を振り返った上で考察していく、というスタイルでゲームの歴史が綴られています。

本書の直前に「教養としてのゲーム史 (ちくま新書)」というのを読んだことが本書を読む上で好対照となりました。「教養としてのゲーム史」は教養としてのとするには全体的に論拠がうすく、著者独自による振り返りであるように感じました。これは今回紹介する「僕たちの」が紹介している文献の幅広さと比較してしまうからかもしれません。

さて、「僕たちのゲーム史」の内容は今となっては当たり前となったゲームシステムや、スタイル、ジャンルを当時開発者やユーザがどのような体験を通して切り開いてきたかを丁寧に振り返っている良著です。ここまで膨大な範囲を調査し、分析することはなかなかできることではありませんから、ゲーム史評価において本書を超えるのはかなりのハードルが上がったことだろうと思っています。

本書の流れですが帯にある「スーパーマリオはアクションゲームではなかった！」は、それだけを聞けば何ことかわからないのですが、当時のゲーム雑誌での評価をもとにうまく分析しています。

しかもその2ページの記事の中で、『Beep』はファミコン用ソフト『デビルワールド』について次のように書いています。 「このタイプのゲームは、種々出つくした感がありますが、これはところどころに新しい趣向を採り入れて、十分に楽しめるできばえになっています。」 これはなかなか衝撃的な言葉ですね。僕はまだゲームの歴史を語り出したばかりなのですが、第一章の段階で、すでに特定のジャンルのゲームは「出つくした」と言われているわけです。

このようにゲーム史は常に過剰供給との戦いがあり、その状況下でも創意工夫の中で新しいジャンルが切り開かれてきました。本書はこの創意工夫を当時のゲーム体験に振り返って評価することで何が新しかったのかを丁寧に分析しているところが著者の主張をより明確に裏付けています。

ゲームの歴史を振り返ろうとするとき、ヒットしたゲームがあってそれらについて単に機能とかゲームシステムといった事実としてわかりやすい特徴をもとに分析したのではこのような裏付けをつくることはできません。

ゲームの歴史という比較的我々が慣れ親しんで、体験し、よく知っている分野であるからこそあるジャンルのゲームがどのような経緯で評価されるようになったのか、知るのは難しいことです。あるいみゲームの歴史という物語の結果を我々自身がよく知っていることもあって、なあんだそんなことか。と思うことが多かったり、拍子抜けするかもしれません。

それでも本書全体を通してみれば拍子抜けすると言うよりは、子供から歴代遊んできたゲームを思い出しながら、その面白さを追体験しているような印象さえあります。このため堅苦しすぎず、読み終わった後も気持ちよく、古いゲームでも引っ張り出してみようかなと思える構成になっていているのでしょう。

[watermint-org]

Akka + JavaFX Proof of Concept

Since GUI framework like JavaFX requires always run on main thread for handle events/manipurating UI properties. This usually cause unexpected behaviors. Fextile trying to separate layout specific codes, handling events, manipurating UI properties, and business logic on top of Akka async messaging framework.

Defining layout is very similar to JavaFX/ScalaFX applications.

object MyApp extends FextileApp { // Do layout just like JavaFX/ScalaFX application stage = new PrimaryStage { title = "My Application" width = 800 height = 600 scene = new Scene { fill = Color.BLUE } } override def props: Option[Props] = Some(Props[MyApp]) }

For all events from scene graph are transfered to actors on Akka.

class MyApp extends Actor { override def receive: Receive = { case (s: Scene, e: MouseClicked) => s.fill = Color.RED case (_, _: WindowHidden) => Fextile.shutdown() } }

code on github: semester/semester-foundation-fextile

[watermint-org]

Twitter Bootstrap like UI framework for JavaFX/ScalaFX

Feeling of Applications

Applications which running on iOS, Android, Windows, and OS X have nearly identical user experience. There are guidelines of fonts, color, margins, etc for labels, buttons, etc including effects or animation for action. User experience guidelines are publicly available for developers like below.

iOS Human Interface Guidelines

Design | Android Developers

Design library for Windows Phone

Application developers and designers refer these guidelines, then design UI/UX for their applications. For iOS and Windows Phones have official review for publishing on application store. Applications may reject when their applications are not compatible with design guidelines.

Twitter Bootstrap

However, there are no reviews for cross platform applications like web applications. Web applications may have different feeling compared to their native applications. Of course, we could find guidelines or best practices for web application UI/UX design. For example, Twitter Bootstrap(Bootstrap) is well known UI framework for designing web applications. Bootstrap is collection of CSS/JavaScript to define UI component and their categories. Defined UI components are like

Red button for destructive operation like delete file, delete repository, etc.

Yellow text region for attention to the user to describe warnings.

Bootstrap also have customization feature, called theme, to define own color scheme, fonts, sizes, etc.

JavaFX and UI framework

JavaFX is a new UI framework running on Java. JavaFX have varieties of UI components, like buttons, tab pane, tables, lists, sliders etc.

However, at least I know, there is no UI framework like Twitter Bootstrap. There are no definitions like button for destructive operation, warning text, approval operation, etc. That's why I started development of UI framework for JavaFX/ScalaFX.

Fextile; UI framework for JavaFX/ScalaFX

Fextile is my project name which coined from JavaFX and textile. On the begining of the project, I just thought it's easy to port Bootstrap's CSS into JavaFX because JavaFX has similar feature called JavaFX CSS. But there are no compatibility except syntax. So I needed to create both JavaFX CSS and class libraries.

Current implementation of Fextile built based upon ScalaFX. ScalaFX is a DSL/wrapper of JavaFX on Scala.

Sample1.scala

Sample1; simple header and labels. First label uses default fonts, size and color. Second label uses "text-primary" class on Bootstrap. Fextile also defines "text-muted", "text-warning", etc.

Sample 2; responsive layout. This sample is responsive to screen width. On wider screen, texts are aligned as two columns.

Sample2.scala

For narrow screen, text are aligned as one column.

Sample3.scala

Sample 3; screen to screen navigation. This sample uses screen to screen navigation component like UINavigationController in iOS. Screen scroll left on "Next" button pressed.

Fextile is on early starge of development. If you'd like to have more components. Please send me pull-requests on github. Thanks.

[watermint-org]

JavaFXアプリケーションの手触り感をととのえる、Fextile

この記事はJavaFX Advent Calendar 2013の13日目、昨日はorekyuuさんのJavaFXでTwitterクライアント作ってみた。でした。

手触り感

iOSや、Android、Windows、OS Xのアプリケーションは、アプリケーションの製作者が違っていてもだいたい同じような手触り感があります。これはラベルの配置や色、スペースの取り方、フォントのような見栄えはもちろんのこと、ボタンをおしたときのフィードバック、画面遷移の時のエフェクトなどさまざまな振る舞いがOSやUIフレームワークによってルールが規定されているためです。規定はたとえば次のようにガイドラインとして公開されています。

iOS Human Interface Guidelines

Design | Android Developers

Design library for Windows Phone

アプリケーション開発者はこれを参照し、アプリケーションに必要なUI/UXを作り上げていきます。iOSやWindows Phoneアプリケーションのように、アプリケーション公開までに審査があるようなケースではガイドラインに沿っていないアプリケーションは排除されるなどOSやデバイス全体のエコシステムとして手触り感の統一をしています。

クロスプラットホームの場合

ではWebアプリケーションの場合はどうでしょうか。WebアプリケーションはデバイスやOS、Webブラウザの種別やプラグインなどによって左右されることもありますが、モダンなデバイス／OSからであればたいていの環境で同じように動作します。この場合、iOSならではの手触り感、Androidならではの手触り感といったOSごとの手触り感とは違う別の手触り感が表現されることになります。Webアプリケーションでもいくつかルールやマナーはありますが、審査等はありませんので厳格かつ広く守られているガイドラインのようなモノは存在しません。

自由にデザインできるという反面、自由度が高すぎて制作コストが高くなったり、制作期間が長引いてしまうというデメリットもあります。このような課題に対して、近年ではTwitter BootstrapのようにWebのデザインルールを決めたCSSやJavaScriptライブラリを使い、アプリケーションのテイストに合わせてテーマなどをカスタマイズする手法がとられることが多くなりました。

ヘッダやボタン、ラベルがある程度のカテゴリにわけられているため、Webアプリケーション開発者・デザイナーはこれらのカテゴリを利用してデザインを決定します。カテゴリと色やサイズなどはCSSとして分離されているため、プロトタイプ開発時にはデフォルトのデザインで作成しておき、リリース時には適切なブランドカラーを配置するなどデザイン作業に余裕が生まれます。

JavaFX

クロスプラットホームのUIを作る手段としてJavaはすでによく用いられています。一昔前はJavaアプレットがあまりにも重いという印象で敬遠されることもありましたが、近年では高速化も進み、10年ほど前のユーザエクスペリエンスが低い状態ではなくなりました。ただJavaのUIフレームワークはAWTとSwingという10年ほど前の状態からあまり進歩していませんでした。その間にはMicrosoftのSilverlightやAdobe AirなどデスクトップアプリケーションのためのUIライブラリが続々と登場し差は広がる一方でした。

2008年にはJavaFX Scriptとして、新しく既存のAWT・Swingに変わるUIフレームワークが発表されました。当初、JavaFX ScriptとしてJava言語とは別の新しいプログラミング言語を使ってUIを構成するようにプロジェクトは進んでいましたが、紆余曲折の末、AWTやSwingと同様にJava言語から利用できるUIフレームワークと位置づけられてJavaFX 2がリリースされました。JavaFX 2ではWebKitエンジンを組み込んだモダンなWebView等を始めとして強力なコンポーネントが追加されました。クロスプラットホームで利用可能なUIフレームワークとして新たな選択肢が登場したといえます。

JavaFXと手触り感

JavaFXには、ボタン、タブ、リストやテーブルなど多くのコントロールが提供されています。これらのデザインはプログラムから変更したり、JavaFX CSSをつかって外部ファイルにて定義することができます。

JavaFXのコントロールは、一定のデザインテイストで制作されているためボタンやタブ、スクロールバーなどの手触り感は共通しています。ただ、ファイル削除など「破壊的な操作をするためのボタン」とか、決済をするための「同意をするためのボタン」といったユーザに対する意図を伝えるためのカテゴリ分けまでは定義されていません。このため開発者はそれぞれアプリケーションの都合に合わせて色やサイズを変えることになるのですが、自由度が高すぎて制作コストが高くなったりします。

さて、この話何か見覚えがあります。これを解決するためには、Twitter BootstrapのようなUIフレームワークがJavaFX向けにあればいいのではないか。早速、そういったライブラリがないか探してみました。ただ、ある程度探してみた限りでは求めているようなUIフレームワークは見当たりませんでした。無ければ作るしかありません。

JavaFX向けのTwitter Bootstrapを作る

さて、JavaFXには前述の通りJavaFX CSSというCSSライクな機能が提供されています。ではTwitter BootstrapのCSSをそのまま移植すればよいのではないかというのが最初の考えでした。ただ、残念ながらJavaFX CSSとCSSは直接的な互換性はなく、またJavaFX CSSからは指定できない項目があるなど簡単な移植ではすまないということが分かり、JavaFX CSSと合わせてクラスライブラリも作成することにしました。

Java言語で作ってもよかったのですが、今回は最近勉強中のScala言語を使って実装することにしました。ScalaにはScalaFXというScalaからJavaFXを利用するためのライブラリがありますので、ScalaFXをベースに作ることにしました。

Fextile

ライブラリの名前はFextileにしました。テキスタイル(Textile; 織物、布地)とJavaFXを何となく合わせた造語です。まずはデザインテイストを全体的にTwitter Bootstrapに合わせてデザインし、実際のアプリケーションをデザインしながら優先度の高いコンポーネントを製作しました。でき上がったのが次のサンプルのようなコンポーネントです。

Sample1.scala

ヘッダとテキスト。サンプルではテキストの色はデフォルトのものと、Twitter Bootstrapでのtext-primary相当のものを使っています。JavaFX CSS側にはtext-muted、text-warningなど他のクラスを定義されていますので、利用シーンごとに指定を変えて使います。

次のサンプルではデバイスや画面の広さによってコンポーネントの配置が適切に変更されるような、いわゆるレスポンシブデザインをサポートしたコンポーネントを利用しています。

画面が狭くなると、2列に表示されていたコンポーネントは1列に整列し直されます。

Sample2.scala

次のサンプルではiOSのUINavigationControllerのように、1つの画面から左から右へとより詳細な情報を表示するためのコンポーネントを使っています。ボタンを押すと、画面全体が左へスライドし新しい画面が表示されます。

Sample3.scala

いまのところこれだけですが、比較的実用的になってきました。これから実際のアプリケーションを実装する過程では、まだ多くのリファクタリングやコンポーネント追加が必要になりますが、簡単なユースケース向けにはひとまず形としてでき上がったかなと思っています。

FextileはMITライセンスにてオープンソースとして公開しておりますので、同じような問題で悩まれている方はぜひお使いいただき、新しい提案もいただければ幸いです。

[watermint-org]

Play 2.2/ScalaでLogbackの設定をLTSVにする

趣味のプログラムをPlay Framework 2.2とScalaで書いています。趣味のプログラムなので、ログを監視したりするような事はまず無いのですが、あとからプログラムで読みやすいようにLTSV (Labeled Tab-separated Values)形式で出力する事にしてみました。

ログの設定は、conf/application-logger.xml というファイルを作っておけば読み込んで適用してくれます。いろいろ試行錯誤した結果次のような設定で落ち着きました。

application-logger.xml (gist)

STDOUTへの出力はデフォルトのままとしています。ファイル${application.home}/logs/application.logへの書き込みのみLTSVとしています。

最初からログローテーションまでは設定しなくても良いのですが、ちょっと作ってみた。というレベルのプログラムでも意外と長期間動かしっぱなしになってしまった。という事もあるので、あらかじめ設定しておく事にしています。

ログに含める事ができる情報はLogbackのマニュアルによるとConversion Wordで定義されているものが使えるようです。呼び出しもとメソッド名や行番号もとれるようですが、動作速度が犠牲になるようなのでここでは有効にしませんでした。

Play framework側のプロパティでapplication.home以外に使えるものはないのか情報を探してみましたが、ソースを見たところ(Logger.scala) application.home以外は特に定義されていませんでした。

[watermint-org]

WordPressからTumblrへ移行した話

WordPressからtumblrへ、日記から文章へでも触れた通り、約7.8年さくらのレンタルサーバでWordPressを使ってブログを配信していました。今回はこの移行についての経験をもう少し詳細に記録しておこうと思います。

WordPressからTumblrへ移行した理由はいくつかあります。

パフォーマンス

表示速度が遅い。CloudFlareのようなCDNも利用していましたが、それでも読み込み開始から描画終了までは8〜11秒程度かかっていました。これはWordPressだけが原因ではなくWordPressのWidgetなど多数のプラグイン、複数のドメインから配信される画像、アフィリエイト・分析のためのビーコン、サーバがレンタル共有型ゆえのCPUリソース不足など複合的な原因がありましたので今回大幅に見直しをかけています。

今回、Tumblrから自動的に配信されるものをのぞき、アフィリエイトなども原則的には付与しない事にしました。ページレイアウトも可能な限りシンプルなものとして、読み込み速度と可読性の向上を目指しています。

結果的には現在のところ描画終了まで2〜3秒とかなりの高速化が実現できました。なお、利用していたCDNのCloudFlareについてはTumblr側との技術的な相性の問題で利用できないようで使用をあきらめ、Tumblrのみで配信をする事にしました。

http://www.quora.com/CloudFlare/Why-has-tumblr-said-that-CloudFlare-is-not-compatible-with-tumblr-Is-CloudFlare-causing-technical-problems-for-tumblr-or-are-there-other-reasons

振る舞いを見る限りだと、Tumblr側は定期的に、設定された該当のカスタムドメインのDNSを引いてみて、AレコードがTumblr (66.6.44.4)を向いているかどうかを確認しているようでした。ここで、確認が取れない場合は設定を無効化しているようです。無効化されると watermint.org にアクセスしても、Tumblrのエラーページが切なく表示されるだけになってしまします。

当初、さくらインターネット側の設定を66.6.44.4に設定しただけでした。イメージ的にはこの設定をして24〜72時間ぐらいすればインターネットに設定が反映されて、うまく行くとおもっていました。ところが72時間経っても変化が無く、あせっていろいろ設定を変えてみたところCloudFlareのDNS設定でAレコードを、Off CloudFlareとして66.6.44.4を向けてみたところほぼリアルタイムで8.8.8.8 (Google Public DNS)なども更新され無事、ドメイン設定切り替えが完了しました。

セキュリティー、メンテナンスの問題

セキュリティー上の問題。WordPressは普及しているブログエンジンですが、その内部構造がやや複雑で、かつ多数のプラグインを使って構成しているためにそれぞれのコンポーネントにおけるセキュリティー上の問題がありそうで心配でした。あまりWordPressのソース自体をみて何か対策をするという事はありませんでしたが、精神衛生上のコストというイメージでしたが負担がありました。

実際の作業は単にバージョンアップをするだけとはいえWordPress自身、プラグイン、テーマなど各コンポーネントは比較的バージョンアップサイクルが早いため、精神的な負担が高く感じていました。

TumblrはCMS含めてのホスティングになるので、運営をほぼTumblr (Yahoo!)に任せる事が出来ますからこの点では非常に負担が軽くなったと思っています。

Markdownのオーサリング

最近、仕事を始め個人的なメモ等もほとんどをMarkdown形式で書くようにしています。そうするとブログ記事等もすべてMarkdownで書きたくなるのですが、WordPressには操作性・互換性の良いオーサリングプラグインが見当たりませんでした。

WorldPressにMarkdown形式で記事投稿をするという点では、Byword 2はかなり有力な候補でした。理由としてはもともとBywordの頃から手元のドキュメント編集に使っており操作性にも慣れていることがあります。

しかし前述の通りパフォーマンスやセキュリティー／メンテナンスの問題などもありましたので、全体的な見直しをかけることで最終的な選択肢とはなりませんでした。

既存記事の移行

最終的に記事は移行しないと決めたのですが、検討した際の調べたところを紹介しておきます。

WordPressで運用してきた過去の記事は7.8年でおおよそ500本になっていました。手動で移行するのはかなり面倒な量でした。選択肢としては次の2つの方式を検討していました。

WordPressにはWordPress eXtended RSS (WXR)という形式で全記事をエクスポートする機能があります。これを、Tumblr API等を使ってTumblrへ移行するスクリプトを書く。Tumblr APIはすでにtumblifeをつかってRubyで連携プログラムを書いた事があったのでこれを使えば良いだろうというところまでは検討しました。WXR形式のデータをパースしてTumblrへ流し込む形式にするのがやや面倒だったので一度保留としました。

次に商用の移行サービスを検討しました。Import2というサービスがWordPressからTumblrへの移行をしてくれます。Import2は、WordPressとTumblr両方のID/Passwordを入れるとよしなに移行をしてくれるサービスで、サンプルとして10記事分を import2 demo というタグ付きで移行してくれます。WordPress側で画像を管理していた場合はさらにDropboxと連携するとDropbox側に画像を移行してURLなどもよしなに移行してくれるようです。 10記事分について移行してみたところ、おおむね問題なさそうに見えました。一つ問題があったのは日本語で書いた記事を編集しようとすると ＆#xxxxx; のようにユニコードでエスケープされた形式となってしまっており既存資産の移行という点ではやや難ありでした。サポートに問い合わせをすればなおったかもしれませんでしたが、結果的にはこの選択肢も保留としました。ちなみに、料金プランは500記事移行の場合、100記事〜1,000記事移行のPremiumプランとなりUSD 49でした。もう少し安かったら勢いで移行していたかもしれません。

記事を移行する／しないを判断する上で重要だったのはURLまでは移行できないことでした。Tumblrで各記事は「/post/記事ID/任意の文字列」のようなURL構造となるのでWordPressの既存URLをそのまま移行する事は出来ません。このような中途半端な移行かつ、過去の記事もすでに時代遅れとなっていることを勘案して最終的には記事移行をあきらめました。

Tumblrに移行してみて

読者の立場としてみると、読み込み速度がかなり改善したのでこれは良かったと思っています。記事を書く立場です。WordPressのHTMLエディタで時々思った通りに入力できなくて結局HTMLを直書きするということがありました。 このあたりがMarkdownで書けるようになったのでかなり安心して書けるようになったと思います。もちろん、Markdownもいろいろ書式を使い始めると表示崩れがおこりがちです。今回からなるべく文体もわかりにくくならない程度に表組などを少なめにして箇条書き中心に書いています。

[watermint-org]

写真整理のワークフロー

Aperture中心のワークフローからCapture Oneへ

事の発端はAperture 3のアップデートが異様なまでにiPhoto側に仕様を寄せてきた事です。iCloudを使わせたいのはわかるけどUXまでiPhotoに寄せてくることには不安がありました。またこれに従い、Aperture自体の継続性ってどうなんだろうという疑問もありました。

Aperture 3.2ぐらいまでは安定して動いていましたが、3.3ぐらいから急にバグらしき挙動が増えて作業に支障がでるようになってくるようになりました。Appleのことだから、コアにするならプロ向けのApertureではなく全製品を取り巻く環境の中心に位置づけたいiPhotoにするでしょう。それでここで見切りを付けて脱Apertureとしようとしたのが今年の1月頃です。

その頃丁度いくつか製品を評価してCaptureOne 7が良いのではという気持ちになってきました。プレビューと最終イメージ(印刷 or RAW現像後のイメージ)が一致する、ヨーロピアンな色使い、パース調整などとにかく出力の気持ちよさにほれぼれしてこれを中核とすることに決めました。

CaptureOneは商業カメラに詳しい方ならご存知の通り、デンマークのPhaseOne社がつくる現像ソフトウエアです。PhaseOneといえば、中判デジタルバックなどをすぐ連想されるとおもいますが、まさに商用写真／印刷向けのソリューション群を扱う会社なのです。CaptureOneもまさにそのコンセプトに沿っており、CYMK印刷、テザー撮影(スタジオなどでPCで確認しながら撮影する)などに特化していました。

CaptureOneはversion 7より、おそらくハイアマチュア向けにかなりコンシューマ市場を意識した作りになっており、ApertureやLightroomでおなじみのカタログ形式(アプリが管理する配下にアプリ経由で写真をインポートし管理下におくような管理形式)の写真管理をサポート。

CaptureOneはもともとその機能名にもある通り、Sessionというテザーセッション向けのディレクトリベースのファイル管理をベースとしておりカタログ形式はまさにCaptureOne 7での新機能でした。

最初、2013年1月頃はCaptureOneを中核に据えるため、すべてをCaptureOneのカタログ形式にしようと既存の写真などをすべてカタログ配下に管理しようとしたのですがそこで問題が生じました。

CaptureOneのカタログは明らかにシングルスレッドでの動作をしており、また、カタログに収容する写真枚数に比例して動作が遅くなる(O(n)で実行時間が長くなる)ため、実用的な収容枚数は1,000枚程度で、10,000枚を超えるとまず、カタログを読み込んで起動するだけで起動の成功率が1/3ぐらいという悲惨な状況でした。

一眼レフでは月々1,000〜2,000枚程度撮影していますので毎月カタログを分けるようにしました。これで半年ほど運用してみましたが下記のような問題がありました。

Capture One 7の問題点

写真の重複排除ができない。ApertureやLightroomを使っていれば当たり前の機能ですが、CaptureOneにはありません。SDカード/CFカードからの読み込み時に前回取り込みを消していなかったり、途中でCaptureOneがクラッシュするなど途中の状況がわからない場合でも手動ですべて解決せねばならずかなりつらい事がわかりました。

頻繁にクラッシュする。使い方の問題ではあるのでしょうけど、CaptureOneは明らかにクラッシュし過ぎです。また、編集結果を即時にfsyncしないため、クラッシュするといくらか編集が巻き戻ってしまうという残念な状況に遭遇します。

RAW+JPEGや、ムービーに対する対応が貧弱。RAW+JPEGはそもそも管理できず別々の写真として管理されます。ムービーについてはなんちゃってレベルで実装されているにすぎない印象。また、これもムービーの再生などをタイミングを同じくしてクラッシュするので未成熟さを感じます。

かなり処理が遅い。Nikon D800で撮影したデータを扱っているのである程度遅いのは覚悟の上ですが、レーティングやメタデータ編集といった画質とは関係のない操作でもApertureやLightroomと比べれば桁が一つ二つ違うぐらい応答速度が異なります。

一方次のようなこともわかりました。

CaptureOneでカタログ管理ではなく、セッション管理とすれば処理速度の低下傾向からO(n)ではなく、O(1)になる。CaptureOneのカタログに対する操作は明らかにUIの更新 → Update → UIの更新となっていて、100枚も写真を削除したり移動しようものなら、数十分は制御が帰ってこないという、泣けてくる実装です(すくなくともCaptureOne 7.1.3まででは)。セッション管理とすると、その状況が嘘のように、普通のちょっと重めなアプリとして動作してくれます。

ワークフロー

以上のような問題から、CaptureOneをオーサリングの中核とする事はあきらめて、メモリカードからの取り込み／取捨選択／キーワードの付与はCaptureOneではなくLightroomで、それ以降のポストプロダクション処理はCaptureOneでやることにしました。

取り込み／取捨選択／キーワード付与をApertureではなくLightroomにしたのは、CaptureOneとの連携のためです。Apertureはカタログ形式、つまり、Apertureが指定したディレクトリ構造しかサポートしませんが、Lightroomは取り込みデータ+XMP(写真メタデータ)をある程度自由にディレクトリ構成をデザインできるため、CaptureOneのセッションディレクトリと共有できるためです。

Lightroomでのメタデータ編集結果を共有するためにカタログ設定の「変更点をXMPに自動的に書き込む」をオンにしておきます。 CaptureOne側で該当のファイルをすでに読み込んでいるならば「ファイル」→「メタデータの読み出し」で再読み込みすればXMPファイルからメタデータを取得してくれます。

現状の写真管理ワークフローについてまとめます。

SD/CFカードからはLightroomに取り込み、その取り込み先ディレクトリはCaptureOneセッションが利用するディレクトリと共有しておきます(CaptureOne側からセッションお気に入りフォルダに設定する)。

CaptureOneに読み込まれたら、あとは必要な写真をメタデータ＋フィルタによって絞り込み、編集します。

ムービーデータについてはCaptureOneに持ち込む前に、LightroomからPremiereのプロジェクトに渡します。Peremiereに渡した後は、音量、手振れ補正などをそれぞれAuditionならびにAfterEffectsなどで行います。タイトルロゴ、字幕なども同様に編集します。

HDR向けないし、パノラマ写真を時々撮る事があるのですがこれはLightroomから直接ファイルを複数選択してそのように編集するメニューがありますのでそのように編集します。その他高度な編集はPhotoshop側で行います。

写真管理ソフトウエアにはたいてい印刷サービスが連携されていますが、Lightroom 5とApertureを比べるとデザインテンプレートなどの差でApertureに圧倒的な軍配が上がると思っています。Adobe製品は全体的に、テンプレートとかサンプル・素材が少なく、3rdパーティー製品を買う事が前提となっていますがAppleのそれはある程度高品質なテンプレート・サンプル・素材がそろっており、これだけでも十二分な利用価値があります。Apertureで発注したフォトブックはAppleの決済後、各国の印刷パートナーが印刷して配送するようです。いままでに何回かフォトブックを作っていますが、クオリティー・満足度は非常に高いです。値段はさほど高くないながら、納期も5営業日(首都圏だからかもしれませんがたいてい5営業日ではなく、5日以内に届きます)に届き、色管理も十分にしていない中でもはずれがありません。Lightroomのフォトブックは、これに比べるとかなりいろいろな点をスクラッチから作らざるを得ず、少し敷居が高く感じます。

オンラインでの写真共有はflickr、everpix、tumblrを使っています。flickrは旧来のproアカウントを継続しているので容量無制限でアップロード可能です。everpixは無料アカウントで利用しています。無料アカウントでは12ヶ月前までの写真が無制限にアップロードできます。招待などいくつかアクションを行う事でこの期間制限は延長されます。月4.99米ドルで無制限になります。flickrからの同期によるアップロードもサポートしていていまはflickrのバックアップ用に使っています。flickrは公開レベルが家族、友達などコンタクト先属性を意識しますが、everpixはアルバムごとに公開URLを作れるなど短期的な画像共有には非常に相性の良いサービスと思っています。その他に、写真共有ではtumblrを使っていますが、これは自分の良いと思う代表的な写真をのせるために使っています。flickrやeverpixは容量無制限という魅力からほぼすべてシャッターを切った写真をアップロードしていますが、ある程度絞り込んだ結果として自分の写真を管理したいという思いからtumblrに写真を載せています。

flickrならびにtumblrへのアップロードは自作のスクリプトを使っています。flickrアップロードスクリプトを作成したモチベーションは、月々数十ギガのファイルを不安定なネットワーク環境でアップロードする際、既存のアップローダーでは対応ができなかったからです。tumblrについては、EXIF情報からより多くのタグを付与してアップロードしたり、コメントを整形するために使っています。

写真１枚１枚自体の管理についてですが、このワークフローではxmpファイルが大きな意味を持っています。Lightroomでつけたタグやコメントはそのままtumblrなどに運ばれるように作っています。

各ソフトウエアの良いところと、悪いところ。

1ヶ月このワークフローで写真整理をしてみました。その中ででてきた各ソフトウエアの良いところ、悪いところを整理しておきます。

Aperture 3 - 手元にあるソフトウエアの中で最も使い勝手がよく作られています。キーボードショートカットのカスタマイズや、選択、ルーペでの拡大捜査など基本的な機能が洗練されていて、派手さはありませんが最も生産的な作業が出来ると思います。一方、課題としてはAppleの方針がころころ変わってしまうために、やや振り回されている感がある事です。

Capture One 7 - 自動色調補正、現像処理、色調調整、キーストーン調整、ウォーターマークの挿入など仕上がりについて満足のいく結果を安定的に返してくれます。色調などは好みはあるとおもいますが、自動補正の際にあまりハイライトなどが破綻しない傾向があるとおもいます。一方、課題としては操作が重かったり、頻繁にクラッシュすることがあげられます。

Lightroom 5 - 全体的に軽快に動き、Adobe製品群との連携メニューが豊富なところが売りです。ファイル管理形式が柔軟なところも便利です。一方、課題としてはUI/UXが全体的に未熟なところです。モードによって選択範囲に対する操作の適用範囲が違ったり、Camera Rawなどでは空気を読んで適切な場所にフォーカスをあててくれたりするのにLightroomはそういう配慮がありません。

[watermint-org]

WordPressからtumblrへ、日記から文章へ

過去の記事について

watermint.orgは2005年10月からWordPressを使ってブログを配信ならびに更新してきました。今回、メンテナンス性などの観点からWordPressでの配信ならびに更新をやめて、Tumblrへ移行する事としました。またこれに伴い、現在までに配信してきましたブログ記事についてはいったん公開を終了とし、必要に応じて新しく書き直したものを配信する予定です。

Tumblrへの移行にあたって、最初既存の記事もそれぞれImport2などのサービスを使って移行を検討していました。いくつか問題があったものの、少し時間をかければ技術的には解決できるだろうというところまでは検証を終えました。ここで、既存の記事についてコストをかけて移行する必要があるかどうかについて別途検討を行いました。

今までの記事は、ガジェット、ライフハック的な内容、旅行や遊びにいった記録などでしたが、それぞれ今見直すと再度これらを新しく皆様に配信するほどの必要性が見当たりませんでした。

検索キーワード等を見るといまも少なからぬ方々が本ブログにご訪問いただいている点を考慮するとすべてそれらをリンク切れにしてしまうのは少し心苦しいところでした。一方いつまでも、時代遅れとなってしまい場合によっては今では不正確な情報を掲載し続けることはかえってご迷惑をおかけする事になるだろうとの判断から、ご愛読・ご訪問いただいた皆様には申し訳ないと思いながらも、記事の移行はやめることとしました。

今後の内容について

またwatermint.orgは、いくつか技術的ないし執筆においての実験の場として利用していたために、比較的短文の記事が多かったのですが、これらも時代に合わないとの判断からやめていく事にしました。短文での情報発信は@watermint (twitter)を中心としたサービスに移行する予定です。

今後は日記的な記録よりも、数日ないし数週間程度考えて熟成させた文章を中心に掲載するつもりです。

これまでは時事ネタに反応したブログ記事をいままで何度か書いてきました。こういったPV向上を狙ったような記事は一時的にはたしかにアクセス統計をみるとPVに影響があるのですが、PV向上を狙った釣り記事が氾濫する昨今、あえて本サイトで同じ事をする必要はないと考えました。今後はホットトピックとは無縁の、地味目なテーマを中心に、より深堀した内容を配信できるよう内容を整備していこうと思います。