あけましておめでとうございます。本年もよろしくお願いします。
2011年は忙しすぎて、ロクな写真がなかったので、数年前に飛行機からとった写真を。
今年は穏やかな年になるといいなと思ってます。
年末というか、最後の3ヶ月は、例の書き物の執筆に忙殺されておりました。もうちょっとかなぁ。
ただ、なんだかしらないですが、その三ヶ月の間に、前歯が2本折れる（1本づつ。1ヶ月おき）とか、どうも集中力を欠かざる得ないトラブルが連続していて、そういうのがしんどい感じでした。歯は1本は入ったけど、もう一本は年越ししてしまいました。年末〜年明けは、自宅ファイルサーバが壊れるのと、ディスプレイが壊れるのとということで、ちょっとトラブル続きです。十分用心したいと思います。
ともあれ、集中して、いろいろ、やっつけて行きたいと思います。
ときどき、PDFのテキスト的な差分を取りたくなることがあります。Acrobat の機能に比較があるので、これを使うことも可能ですが、遅いし、不要な差分が出たりして面倒くさいです。
我慢して使ってたんですが、探してみたら、pdftotext使ってFileMerge(コマンドラインからはopendiff)するのがサイコーだというので、試してみたら確かにサイコーだった。
opendiffは名前のごとく昔からあるものですが、差分取る前にフィルタを適用する機能があるので、これを使います。 MacWorldの記事とここを参考にしました。
やることは、大きく2つ。pdftotext をインストールして日本語を扱えるように設定することと、シェルスクリプトを一つ書いてFileMergeで設定することです。
まず、pdftotextですが、MacPorts でpopplerとxpdfを入れるという手もあるのですが（上記は、その手順を書いてあった)、gtkとか使っていて、パッケージの依存がとても深いので、オススメしません。同記事に、バイナリのありかがかいてあったので、それを用いました。このディレクトリの xdf-tools-3.dmg をもってきて、中にあるパッケージをインストールします。
さらに、日本語エンコーディングファイルが必要なので、ここからxpdf-japanese.tar.gzをダウンロードしてきます。以下の手順。ルートかルート相当で操作:
mkdir -p /usr/local/share/xpdf
cd /usr/local/share/xpdf
tar zxf ~/Downloads/xpdf-japanese.tar.gz # パスは適当に変更
mv xpdf-japanese japanese
最後に、xpdfrc をに設定を追加。上書きしないように注意。
cat japanese/add-to-xpdfrc >> /usr/local/etc/xpdfrc
ここまでで、pdftotext で日本語が通るようになるので、以下のようなシェルスクリプトを用意します。
#!/bin/sh
pdftotext -layout -nopgbrk -enc UTF-8 "$1" -
適当に名前をつけて、適当な場所において、chmod +x しておきます。
最後に、FileMergeを立ち上げて、Preferenceから、Filterを選びます。Filterの設定で、+を押し、
extension へ pdf 、filter へ"pdftotextへのパス $(FILE)" と設定して閉じます。
これで、pdf で diff できます。
ただし、エンコーディングの関係で、"File not ascii" と警告されてしまい "Proceed" 押さないといけないという問題点があります。この記事にあったように、エンコーディング強制してみるとかしてみたんだけど、旨くいきません。だれか上手い方法おしえてください.
iTunes Matchの事とか、ストリーミングに関しての話もあって、もっぱら音楽周りの話が注目されがちですが、 僕は、iCloud の本質は、同期不整合解決にあると思っています。
Lionのリリースノートである、What's New in Mac OS X Lion というデベロッパ向けの文書があります。 これの一番最初に書かれているのは、iCloud Storage APIの説明です。 一番最初に書いてあるぐらいなので、Appleが一番大事だと思っているフィーチャはiCloud Storage APIだと言うこともできるでしょう。
それで、iCloud Storage APIでできるのは、簡単にいうと、
を実現してるところです。 （これに加えて、Key-Value storeもありますが、これについては、今回は置いておきます。）
これのどこにインパクトがあるかというと、同期の不整合解決です。
Dropbox含めて、いろいろな形で「ファイルの同期」する仕掛けは提供されているし、先に、VMwareもProject Octopusを発表したぐらいで、ファイル同期が情報共有のための仕掛けとして重要なのは、誰もが知っているところです。
しかし、分散している端末それぞれでコピーをもっている以上、様々な理由で同期は失敗します。実際、Dropboxで同期が失敗すると、タイムスタンプ入りのファイルができてしまいます。これらのファイルの間の不整合を解決するのは、簡単にできる場合もありますが、 うっかり二箇所でExcelファイルをいじっていたりすると、目に手も当てられない状況になりますよね。 さらに、複数のファイルから構成される情報等の場合、ファイル同期にトランザクションみたいな概念もないわけですから、大変なことになります。
iCloud Storage APIの場合、同期の不整合解決をアプリケーション側でコントロールできるようになっています。ファイル、という、一種の「バイナリデータ」ではなく、 意味を持った情報として中身を統合することができるのは、そのファイルを読み書きできるアプリケーションだけなわけですから、自然な方法と言えると思います。
これができると、 ユーザは、自分の作ったファイルであれば、全く同期を意識せず、 ファイルは手元にあるのに関わらず、端末間で完全に共有され、ストレージが見えなくなると思います。 さらに、履歴もTimeMachineで保存されますから、遡ることも可能。 これがAppleの狙いだと思います。 iPadもそうだったという人もいますが、Appleやろうとしているコンセプトの一つは「見えなくすること」だとも思ってます。
一方、モバイルデバイスとクラウドの間での情報同期が容易であるということのインパクトは他にもあります。 昨今いわれている回線品質とかの関係でいうと、どうしてもラストホップの太さは期待出来ないわけで、 なんでもかんでもクラウドにおいてブラウザで叩くというのは、通信帯域が確保できていれば快適ですが、 そうでない場合は厳しいわけです。そんなこともあいまって、ここいらの技術が今後重要になるんじゃないでしょうか。
アプリケーションの対応ということでは、少なくとも、OmniOutliner 等で有名な Omni Groupと1Password の AgileBitsは間違い無く対応してくるでしょう。1Passwordは3.9がAppStore向けにでたところですが、4.0を開発中ということで、iCloudがリリースされたら、4.0が出で来るのではないかと。
蛇足ですが、個人的には、Documentあるいはファイルやフォルダという抽象化がベストかどうか前から疑問持っていて、 もっと良い形はとれないものかと、常日頃考えています。そんなわけで、この動きは注目しています。
Rails 3.1 が出たので、昨今作っているアプリをマイグレーションしてみました。
まず、3.1 のコードベースで bundle して、rspec走らせると、jQuery-UI 使ってる部分のコードが動作しないせいで、integration test (Capybara-Webkit使ってる)が通らないところが数カ所出ました。
原因は、jQuery関係の .jsなファイルを publicから見付けてくれなかったから。バックワードコンパチビリティ的に多少問題ある部分がありそうな予感だけど、追求は面倒くさそう。ちなみに、development環境で実行しても、何も出ないので、何が起こってるかさっぱり分かりません(笑)。
そんなわけで、正当に、Asset Pipeline 使うように変更したら動くようになりました。Rails 3.0 向けに書かれたコードで Asset Pipeline使うためには、下記三点の修正が必要のようです。
Ruby on Rails Guide: Asset Pipeline の一番最後にこそっと書いてある修正が必要です。
適宜 public の下のイメージ、JavaScript、 スタイルシートを app/assets の下などに移します。
場合によると、上記アセットを参照しているパスの修正が必要（私の場合は image/ほげ と書いてあった部分で、一部、image/ を削らないとダメなのがあった)
これで、なんでもかんでも public にあるという状態から解放されるので、少しコードのコンポーネント化をすすめられそうです。
Lion、段々慣れてきました。スクロール方向にさえ。
特に評判がわるいのは、Mission Controlの操作性が違うことと、Trackpadの縦スクロールの件のようですね。 少し慣れてきたので、思うところを書いてみます。
まず、スクロール方向の操作は、元々Scroll Barの操作の方向と画面の動く方向が逆だったのに、みんなスクロールバーの操作に慣れているというのがネック。
で、どうも、トラックパッドを活かした操作を持ち込もうとすると、どうしても、これが足かせになるんですね。たとえば、Safariは二本指左右で、Forward/Backwardボタンの操作がそのままできるだけでなく、前、後のウィンドウの中身を覗き見られるような操作になってるけど（これは、超、便利。大変直感的）、これが逆向きだと、直感的じゃない感じ。
これ、つまり、中身の動きに指の動きを合致させたかったのが変更の理由だと思うのですね。なので、諦めて慣れることにしました。で、二日もさわってると、だいたい慣れます。そんなにハードル高くない。
ただ、インターフェースの練りに一部問題があります。気がついていることを書くと、
ここいらの作り込みは、まだまだな感じ。改善されるといいな。。
Mission ControlはSpaces+Exposeと操作性ががらりと変わったので、前と同じであることを期待していた人は、超絶がっかりしているようです。気持ちは分かる。特に、全ウィンドウを出す操作が無くなったのは確かにちょっと悲しい。
ただ、実は、頭切り替えて、使い方をあわせてやると、あきらかに使いやすい部分があります。気がついたのは、
といったあたりでしょうか。
結構住めば都な気がしてきています。
前は嫌いだったんですけど、実は、単一の仕事にフォーカスできて、Dockとかで表示されるノイズに邪魔されないから有効という気がして来ました。Mind Mappingとか図書く作業なんかは、とっても向いてる気がします。
で、フルスクリーンモードがスペース一つに割当たることから、左右3本指スワイプで切り替えられるし、必要ならControl+数字でも、Cmd-Tabでも、Dockクリックでも切り替わるので、思っていたより困らない感じ。
ともあれ、ポイントは、今までの使い方をかえないといけないということで、ハードル高いと思う人は多いと思うけど、切り替えられればいいんじゃないかと。僕は割と幸せになれそうだと思いました。
とくに、トラックパッド操作が非常に快適。まぁ、デスクトップもクラムシェル環境も全部トラックパッドに統一したおかげってのもありますけどね。
少し我慢して使ってみるのもオススメです。
OS X Lion、早速入れてみました。
それで、神奈川方面オフィスの環境では気づかなかったのですが、Xerox C3050 で、印刷ができなくなりました。
原因は、/usr/bin/python が 2.6 から 2.7 にあがったせいでした。 Xerox のドライバは .pyc で提供されているため、/usr/bin/python2.6 に食わせればOKということになります。
対処は簡単。/Library/Printers/FujiXerox/Filter/fxnpdftopdf.bundle/Contents/MacOS にある fxnpdftopdf というスクリプトで、python 2.6 を使うようにすれば良いだけです。以下のような感じ。
2052% diff -c fxnpdftopdf.FCS
*** fxnpdftopdf.FCS Wed Oct 27 12:54:26 2010
--- fxnpdftopdf Thu Jul 21 08:40:12 2011
***************
*** 12,17 ****
fi
PARDIR=${0%/*}
! /usr/bin/python "$PARDIR/driver.pyc" "$1" "$2" "$3" "$4" "$5" "$LASTARG"
exit $?
--- 12,17 ----
fi
PARDIR=${0%/*}
! /usr/bin/python2.6 "$PARDIR/driver.pyc" "$1" "$2" "$3" "$4" "$5" "$LASTARG"
exit $?
いよいよWWDC。最後にWWDCに行ってから、随分長いですが、毎回行きたいとはおもってるんですが、あいかわらず行けません。
ちまたでは、iCloudが大きな話題です。前からAppleのノースカロライナのデータセンタの話は、とても大きな何かの一部では無いかとおもっていて、iCloudの話には大きな興味があります。
過去に少しTweetしたりしてるんですが、前から気になっていることを、少し整理して、書いておきます。
モバイル端末の能力は、バッテリ効率の点で、プロセッサ能力、メモリの量等の上でのバランスが重要だと思います。ここで、過去のiPhoneのCPU性能を見ると、チップの能力から最大限のクロックを使うのではなく、一段遅くしてバッテリ効率を稼ぐアプローチを取っているように思えます。たとえば、iPhone4とiPad(1)ではプロセッサは同じA4だけれど、バッテリ容量の小さいiPhone4は、クロック落としているようです。
一方、ユーザの視点であれば、もっとモバイル端末を高度に使いたいという要望があるわけで、アプリケーション視点では、プロセッサ能力は上げられればそれに越したことは無いわけです。アプローチは、シンクライアントだったり、ある種のクライアントサーバ型モデルだったりします。Google検索のようなクラウド系のサービスも、ある種のシンクライアント型に近いと言えるでしょう。また、最近登場してきているiPhone用の音声認識ソフト等は、要素を取り出すのを端末でやり、認識処理をサーバ側でやるようになっていて、今後、この手のアプローチは増えると思います。
僕は、ブラウザをフロントエンドとしたシステムだけがクラウドでは無いのではないかなと思っていて、クラウドの活用で、モバイル端末の能力のバランスをとれるんじゃないかと思っています。
一方、モバイルにも使われ始めていますが、マルチコアのシステムの能力を、上手に使い切るのは、難しいことです。ある種の言語を用いると上手に使い切れるというのもあると思いますが、とりあえず、ここでは置いておいて、いわゆる逐次実行を前提とした言語を考えます。
この手のシステムの場合、実行コンテクストを何らかの方法で上手に多重化する必要があり、典型的には同期が問題になるわけです。(イベントドリブン型のNode.jsなんかも、関連した話題になりそうだけど、これも置いときます。)
CPU能力を使い切るという意味でいうなら、細かくタスクを分割して順次処理するようにキューに積み、それを順次実行するようにすれば良いと考えられます。一方、タスクを分割し、あとで実行させるように詰んで行くのは、既存の言語環境とライブラリのデザイン方式では、難しく、プログラマの立場でいうなら、大きな負担があります。
ここで、ある種のショックを受けたのは、Appleの技術者がCにClosureを導入し、Closure単位でディスパッチキューに詰んで実行する仕掛け(Grand Central Dispatch)を提案したことです。Closure単位で詰むことができれば、プログラミングはとても容易になります。そして、システムレベルでディスパッチキューが管理されることで、上手にプロセッサ能力を使い切ることが出来ます。
プログラミングする立場で言えば、Closure+GCDを使うようにプログラムを書いてさえいれば、利用可能なプロセッサの能力に応じて処理能力がスケールします。
ここで、GCDがローカルプロセッサのものだけでなく、自宅にある比較的能力の高いデスクトップ等、自分の持っている計算資源を統合して使えるようになったり、あるいは、クラウドで用意されている計算資源を組み合わせて使うことが出来るようになれば、蛇口を捻って水をだすように、計算能力を使うことが出来るようになります。TimeCupsuleやAppleTV等のデバイスも全て一緒に動くとしたら？
僕は、iCloudの正体は、実は、これではないかと思っているのですが、はたしてどうでしょう。
たとえば、デベロッパは、フロントエンドにあたるAppとバックエンドで動くAppを登録でき、組み合わせ実行できるとしたら？通信の遅延の問題とか、帯域の問題とかはあるんだけど、上手にやると面白そうです。
レコードレーベルの話もあるわけですが、正直、ユーザのストレージの代行を単にするだけなら、Appleが自分でやらなくても良いかもしれない。大きめのDCをあれだけコストかけて準備するのは、それなりの理由があるんじゃないか、きっと、そこにとどまらない何かがあるんじゃないかなぁと、期待してたりしします。
そんなわけで、明日のKeynote、リアルタイムで見られるかどうか分かりませんが、大いに期待しています。
ここしばらく、Rails 3.x ベースで簡単な開発をしています。
どうせやるなら、新しいことやらないと、ということで、今回は Behavior Driven 開発をしようとしてました。Cucumberでの、振る舞いベースの要求仕様策定から、RSpecを用いた Test Driven な開発へと落とし込んで行く方法です。The RSpec Bookやら、Continuous Testing: with Ruby, Rails, and JavaScriptを読みつつ、色々と実験してました。
そんなわけで、いくつかTipsなどまとめたいと思っているのですが、とりあえず、役に立ちそうなことを先に書いみようということで、前置きが長くなりましたが、capybara-webkitについて。
RSpecは、 「プログラムの振舞 (behaviour)」を記述するためのドメイン特化言語 (DomainSpecific Language:DSL) を提供するフレームワーク」です。まぁ、リンク先にあるように、Test::Unitを違う書き方で出来るということなんですが、DSLの出来が違うと、これだけ思考方法がかわるのか、というぐらいのものです。まぁ、メソッドやオブジェクトあるいはオブジェクト群に対する振る舞いのテストをする仕掛けなわけです。
テストは、最後の段では、全体を統合した Integration testをしたいわけです。Webアプリだと、ページを開いて、フォームを埋めて、ボタンを押して..などといった操作をして、結果を検証するわけです。
RSpecのIntegration testを支援する仕掛けとして、Capybaraがあります。Capybaraは、Rackベースのアプリケーションを対象にして テストができる仕掛けとDSLを提供しています。DSLは、同種のソフトのWebratがベースになっています。デフォルトのドライバは、Rackベースのアプリを対象としたブラウザエミュレーションですが、ドライバ部分を適当に導入すると、異なる形でエミュレーションできます。最初は、Webratを使ってたのですが、更新が止まっていたり、最近のRailsと相性わるいなど、色々不都合があり、直してつかってたのですが、その後、Capybara見付けたので、こちらを主に使うようになりました。
デフォルトのRackベースドライバは軽くて良いのですが、ブラウザのエミュレーションにJavaScriptエンジンが無いので、Ajaxベースのアプリのテストが出来ません。そのため、JavaScript使えるドライバがあるのですが、どれも、帯に短し襷に長しと言う状態でした。
ここで、ようやく、capybara-webkitの話になるのですが、こいつは、Qt用にポートされた、SafariやChromeで使われているWebkitフレームワークを使って、ブラウザエミュレーションします。これにより、フルにJavaScriptが使えるHTML5ブラウザでテストできることになります。この方法を思いついた奴は頭イイと思う。。
少し試してみたのですが、うまいことAjaxなコードのテストが出来ます。ブラウザが立ち上がらないので、ホントにヘッドレスでできます。MacOS Xで試す範囲だと、ビルドも簡単だし、非常に簡単に使えて良いです。試したなかでは、一番マトモにつかえそうです。
ただし、エンコーディングの関係で少し問題があったので、直して、pull requestだしました。そのうち、反映されるでしょう。(socketから帰ってきた文字列に強制的に set_encodingするだけ)
オススメします。
追記 (2011/6/18)
pull request 通って反映されています。
OmniOutliner for iPad の話を書きましたが、テンプレートでSolarized (lightとdark)というのがあって、なんだと思って、リンクをたぐってみたら、Solarizedというカラースキームがあるのですね。
ポイントは、こんなかんじです
(英語で色の話書いたこと無いので、間違いあったら教えてください。ガキの頃は勉強してたんだけど)
見ての通り、読みやすいと思います。いろんな端末やエディタでの設定方法がダウンロード可能なので、使ってみると良いかも。
とりあえずは、color picker に設定を入れ、Terminal.app で設定してみました。僕は、普段は、Terminal.app の "Novel" テーマを少しいじったものを主端末に、ログ用追跡ウィンドウに "Homebrew"を使っているのですが、これのDark/Lightの組み合わせでも良いような気がしてきた。Novelは気に入っているのですけど、Homebrewとの差が大きすぎて辛いのが解消できる気がします。
ただ、Terminal.app用のサンプルでは、Novelより少し背景色が明るすぎる気がするので、背景色と選択色を入れ替えました。暫く使ってみるかな。
最近、RubyMine使ってRailsな開発してるんですが、こいつ用の設定見付けました (rubymine-solarized)。
iPad出た当時から、OmniGroupの人も出すと言っていたので、待ちわびていたのですが、OmniGroupのOutlineエディタ、OmniOutlinerのiPad版が、ついにAppStoreに出てきました。
僕はMac版のヘビーユーザです。Mac用もWindows用もアウトラインエディタといわれる類のものは、ThinkTankやMoreから始まって相当数試していて、常に良いアウトラインプロセッサを求めてきたアウトラインプロセッサオタクです(笑)。そんな僕が、ここ数年は、OmniOutliner for Macをヘビーに使っていました。OmniOutliner for Macは大変良く出来ていますので、オススメです。
そんなわけで、早速、購入＋インストールして使ってみました。噂には聞いていましたが、インターフェースが程良く練られているので、メモとりには最高でしょう。しばらくは、これでゆくかな。。
一方、Mac版とファイル共通なので、比較的大きいものを突っ込んでみましたが、特に問題無くうごいています。メモリ少ないせいもあって、大きいと少しかったるいですが、iPad1でも、使えないことは無い感じ（内部ファイルはXMLなので、xmlpp して 8万行ぐらいのファイル。実際の文書の行数は10分の1ぐらいでしょう）。文書スタイルは完璧に再現されているように見えます。
実は、論文をOmniOutlinerで書いてLaTeXに変換するバックエンドをRubyで書いてもってるというのもあって、非常に依存度が高いので、大変ありがたいです。これで作業が進むと良いなぁ（笑）
あと、拡大縮小機能がついています。最初読み込ませたら文字がでかくてビックリしたのですが、デフォルトは、150%拡大になってます。
唯一気になるのは、同期はWebDAVサーバとiDiskです。DropBoxで出来ないがちょいと痛い。まだ、アプリケーション間連携を試していませんが、当面の措置としては、個人的には、WebDAVサーバを作り直すかな、という感じです。OmniFocusもWebDAVが基本なんですが、このアプリに関しては、DropBoxとの同期が欲しいのではないかなと思います。サポートされないかな。
ともあれ、バージョン1(1.0.1だけど)としては秀逸だし、OmniGroupの製品なので、今後のバージョンアップも大変期待できると思います。AppStore で 2400円と、$19.99というUS価格より例によって高いですが、オススメできると思います。
しばらく前からさくらのVPSを使っていたのですが、調子が良いので、自宅での常時運用サービスを、概ね移してしまいました。もともと、震災の前から準備してたのだけれど、良い機会だったので一気に移動。全部ZFSにしたかったので、やってみた結果、うまくいったので書いておきます。
最初の980円のプランのころは、試すかどうか迷っていたんだけど、FreeBSDを動かせるようになった時点で試しはじめました(最初は512のプラン)。昨今Linuxでも結構慣れてるんだけど、より使い慣れていて、想定外で困る事がないので、やはりBSD系は助かるのです。しかし、20Gだとメールサーバを動かすのには容量不足でした。きっとそのうち容量増のプランが出ると思ったら、でてきたので早速実験。
容量計算すると、50G の UFSあれば、当面足りると思っていたので、VPS 1.5G(2core, 1.5GMem, 50G) プランを試してみたんですが、困ったことにディスクが2個に別れていて、20G + 30G の構成なのです。容量増えても１個目は20G。。これにはまいりました。
一方、インストールするときはPXEboot イメージでのブートのため、Fixit環境をつくれないのです（これは改善要望だそう。。）そのため、現在入ってるディスクに入っているものをインタラクティブに修理するのは結構大変。
ということで、諦めて大きめのプランに切り替えて、ブート側ディスクは使わないということにしたら、結構良い感じになりました。
インストールは、こんな感じでやった
さらに、オプションですが、ブートできたら、1台目に同様にGPTパーティション切って zpool add してしまえば、2台で一つのプールで使えるようにできます。短期運用予定のサーバで実験的に作ってみましたが、全く問題無く動きます。
何点か注意点を。。
2個ともZFSにしてしまうと、前述のごとく、PXEbootでFixitつくれないので、ブート環境が壊れると、復旧が相当難しいと思われる（多分さくらの中の人にたすけてもらわないと無理）。zfs.ko をkldloadできるかどうかが問題なんだけど、方法あるかな。ともかく、覚悟が必要です。
契約が済むまでは、OP25制限がかかり、サーバから見て外向きの帯域が2Mbpsに絞られます。この制限は、支払いが完了した後の営業日の17時以降に解除される。
契約は最短3ヶ月です。僕みたいにOP25制限外したくて支払い済ませてから気が変わると勿体ないことになります（汗）
ところで、VPSでZFS使うことの美点は、バックアップが楽な点。zfs send | bzip2 とかして、バックアップすることが容易です。結果、移設もとっても楽。スナップショットで完全にフリーズされているので安全。メリット大きいかもです。
Delicousの代わりにPinboardオススメという話。
僕は、情報収集と整理のためのワークフローの一つの出口として、Delicious使ってました。ここしばらくは、RSS系のものについては、主にGoogle Readerか、そのフロントエンド(ReederのiPad/iPhone版とMac版)を使って読み、適当にDeliciousに突っ込んでいましたし、Twitterで見付けて開いたリンクも同様です。Bookmarklet登録しとけば、一発で突っ込めるから便利だし、対応してるアプリが多かったので、非常に便利だった。たとえば、Delibarとか、各種Safari用、Firefox用の拡張も便利で、大変助かっていた。
ところが、2010年12月に、Delicious Bookmarkが閉鎖されるか？などと騒ぎになって、初めて依存度高いことに気づきました。なにしろ、最近のYahooなので、先行きの不透明感はぬぐいきれない。そのうえ、これの代替って結構ないんですね。アプリがAPIに依存してるせいもあって、アプリに依存していると、難しい。
そんなときに、John Gruber氏がPinboardを勧めたので、試してみたのです。実は、前にも他で勧められていて、サイトだけは随分前にチラと見たんだけど、登録料金払わないと使えないので、見送ってたのです。一度きりだし、たかだか数ドルなので、まぁ、いいかと思って試してみた。
それから暫くつかっていますが、とても便利です。大変オススメできます。理由を書いてみましょう。
サイト自体が軽い
まぁ、Deliciousも軽いんだけど、それ以上にかるい。ページ自体の情報量が少ないので軽い。 (開発の上でのコンセプトは、「データなくさない、バカっぱやい、便利な機能を提供」だそうです）
「とりあえずブックマーク」し「あとでタグ付け」するのが楽
何も入力せずにブックマークするもの含め、Bookmarletが豊富に用意されている(このあたりに一覧あり)。くわえて、frame使ってますが、 ページ自体を見ながらタグを順番に編集する機能があってとても便利。
Twitter 連携がリッチ
URLつきの自分のTwitter tweet を勝手にブックマークしてくれます。 favorite つけたtweetをブックマークすることも可能。 Twitterユーザには、とてもありがたいと思いますよ。想像以上に便利。
アーカイブ機能があり、全文検索できる(有料オプション。年間契約 $29)
登録されたURLは、最大1ページ100Mまでキャッシュしてくれます。 さらに、キャッシュの内容に対して、全文検索できる。 これも、思っているより便利さが実感できます。
いろんなサイトのブックマークを自動インポートできる
Delicious, Instapaper, ReadItLater, Google Reader から出てくる情報を、自動でインポートできます。 これを上手く使うと、Deliciousでサポートしてるアプリでブックマークしたものを、そのままもってこれる。
Deliciousに加え、Safari, Firefoxなどからexportしたbookmarkをimportできる。
日本語でも使える
ボランティアによって日本語化されてます。
Delicious とAPIコンパチ
URLだけかえれば、そのまま使える。
Deliciousほどでないけど、アプリサポートが充実してきている
このあたりに説明があります。ReederもDelibarもサポート!
安い
支払いは一度だけ。今$9.28です。価格は、ユーザ数に応じて上がる。 先のアーカイブオプションは、$29/year だけど、できることを考えると、とても安い。
開発者が頑張っている
頑張ってると思います。フィードバックに対する反応に好感もてる。
そんなわけで、強くオススメです。
ちなみに、1月に、開発・運用している人が日本にやってきたので、お会いしたのですが、ナイスガイでした:)
地震のおり、皆さん大変だと思います。私と家族と親類は無事です。
それで、たまたま、先週から某社のVPSへの移行しようと準備していたのですが、計画停電の話も出ているので、思い切ってアクティブ系のモノは全て移行してしまいました。
某社のサーバは関西にあるようなので、これで自宅サーバを落としてしまえば、セーブ出来ますので。
とりあえず、ちゃんと動いていそうですけれど、様子みながらという感じです。
みんなで乗り切りましょう。。。
前にも書きましたが、相変わらずAppleのカナル型を愛用しています。
で、前書いたときに試したUltimate Ears SuperFi 4 に、Complyのチップが付いてたんですね。 良い感じだった上に、色々なメーカ毎に各種あるので、もしかすると良いかなと思って、ER-4Pと、Apple用のを買ってためしたら、とぉっても良いのです。ちょいと高いし(3ペアで国内業者価格2100円)、使ってるとダメになるので定期的に交換が必要なのですが、オススメ。一昨年に入手して以来、ずっと使ってます。そんでもって、耳に負担かかるER-4Pイラナイという結論に（笑）
Appleのカナル型は、元々ドライバが2個なので、高域ホドホド、低域ホドホドで良い感じなのですが、全体にボリュームが増す感じになります。大変オトクな感じになります。
まぁ、Appleのに限らないですが、Complyのチップ試していないならオススメです。Amazonで売ってる業者もいるし、ヨドバシでも売ってるのですが、メーカとモデル指定で大きさが違うので、注意が必要です。Appleのは T-140ってタイプで、僕は、M型が合ってる。
3組入りがコストパフォーマンス良いですが、騙されたと思って一組買って試してみると良いです。国内で売ってる業者は、ググってみてください。僕は、eイヤホンさんから買ってます。
などと書いてから、Complyのページ見たら、新しいタイプのフォームがでてる。Whoomp!ですと。しかも、T-140がオススメされていないという。。
試さないといけないけど、T-140Mが入手可能なのを確認して、あわてて購入。。。
ここのところ、書こうと思ってることが結構たまってきています。
... なのですが、MovableType 3.xの頃（だと思う）ぐらいから少しづつ直していたテンプレートがついに破綻して、どうにもならなくなりました。
ということで、テンプレートとデザインは心機一転でやりなおすことに（笑）。
暫くデザインが色々と（色も含めて）代わったりするとおもいますが、内容かわらずということで、よろしくお願い致します:)
Recent Comments