スクリーンショットを使う機会ってあるじゃないですか。でも mac のスクリーンショットをそのまま貼ろうとすると 24bit ででかいので、さすがにファイルサイズを節約したいわけです。
で、Photoshop のある環境では「Web用に保存」を使ってたんだけど、さすがにおおげさだし、ない場合にどうしてたかというと以下のような感じだった。
- GIMP で PNG-8 を作ろうと画像のモードを Indexed にすると色が大きく変わってしまう
- Preview.app で PNG-8 を作る方法が分からない
- ImageMagick は option 調べるのが面倒
- sips は調べたけどよく分からず
ということで
JamieMason/ImageOptim-CLI: Make optimisation of images part of your automated build process
を入れた。24bit のままでも半分くらいになったりするので、もう減色とかいいや。
Windows だと
Pngyu この辺を使えばいいのかな。
9時に寝て3時に起きてしまったので勢いに任せてガシガシ読んでみた。
読んだのは小説とかじゃなくて 明日の広告 変化した消費者とコミュニケーションする方法 (アスキー新書) で、勉強のつもりで読んでいる。
結論としては、速読ができない人には割とよい。
- ページめくりの違和感はある程度慣れる。
- 誰に渡してもみんなスワイプして画面崩壊を見てガッカリするんだけど、ページ送りをスワイプじゃなくてタップでするようにするとある程度は慣れます。
- とりあえずタッチデバイスなのでハイライトがめっちゃ楽。
- 付箋貼りまくりの人としてはこのハイライトの楽さは大変よい。
- メモもそれなりに書けるけど、日本語変換が処理速度的にも変換精度的にもだいぶザンネンな感じ。
- 辞書は単純に便利そうだけど、縦書きの日本語の本で特に必要なかったのでまだ使い勝手はよく分からない。
で、このハイライト、メモは「マイクリッピング」というドキュメントになっていて、Kindle端末、Kindleアプリ間などで同期できるほか、USBストレージから普通の "My Clippings.txt" というテキストファイルとして取り出せる。これは良い。
ただしとても残念なことに
このアイテムのクリッピングの上限に達しました
というツレナイものがあったりして、「付箋貼りまくり読み」にはやはり向かないようです。My Clippings.txt には含まれていないハイライトもKindleの本の上には再現されており、.sdrなフォルダの中のどこかに違う方法で保存してるんだろうなぁ。うーん、おれの読書はやはりマイナーな方なのかな。
あとやはり見開きの情報量の多さに改めて感心。やっぱ電子書籍は読書体験的にはかなり劣化してるんですよ。で、これを「再現」しようとするのではなく、電子書籍ならではのより良い読書体験が提供され、それを我々が実感できるようになれば、時代は変わるんだろうなぁとぼんやり思ったのでした。
※ 書き忘れ日記掘り起こし
なんかやり方が間違ってるかもしれないし、2010-01 段階での話なので、ベストプラクティスは時とともに変わっている可能性があります。
背景というか要求
- これまでガラケーに全部メールで RTM のタスクを通知していたが、多すぎる通知はないのと同じ状態になってしまった
- 通常のメールを reminder と思って無視してた
- PocketWiFi を入れて通信費をそちらに集約したいので通知も iPod touch の方に来てほしい
参考までにこれまでは
- PC で RTM に入力
- ガラケーに reminder メール
- 閲覧用にみるぽん
- どうしても出先でタスクを追加するのに Inbox アドレスをガラケーに登録
という構成だった。
選択肢
- みるぽん
- 標準の「カレンダー」アプリの通知
- RTM純正アプリ ( + Pro アカウント )
くらいを考えた。
- みるぽんは試した段階で通知機能がなかった。
- 標準のカレンダーへ RTM を直接同期することはできないっぽい
- Google Calendar と touch カレンダーの同期、RTM と Google Calendar の同期はそれぞれ記事がある
やってみよう。
悪戦苦闘
- Google Calendar と touch の「カレンダー」の同期は問題なくできる
- RTM -> Google Calendar には方法が2種類くらいあるんだけど、どうしてもうまくいかない
- 時間が掛かるという情報もあるが丸一日以上待っても反映されない
何か勘違いしてるかもしれないけど、さすがにちょっとこれはしんどい。
結論
- 予定の俯瞰用にRTM のプライベートアドレスを「カレンダー」から「参照」することにした
- 予定の俯瞰はこれで十分
- RTM 純正アプリ ( + Pro アカウント )
本当は「参照」だけで全部解決すると思ったんだけど、「参照」だと「通知」情報が落ちてしまうので
touch で通知を受け取りたいという当初の要求は満たせなかった。
とは言え、参照カレンダーでの見やすさは今までに体感できていなかったものなので、これはこれで活用することに。
時間もなかったので「通知」は純正アプリ頼みにした。なんか負けた気がする。
今回、
- カレンダーの「同期」と「参照」の違い
- アプリの通知機能と iCal の通知情報の扱い
を新たに学んだ。分かってるようで分かってないことってたくさんある。
※ 純正アプリを使い始めてすぐにタスクの見やすさ、追加、編集しやすさなどかなり練られていることを痛感。これは $25/y の価値あると思う。要は手帳買うのと同じだよね。
年末からやってたドットファイル一本化の流れ。ダラダラっとメモ。
環境判別あれこれ
.emacs
実際には書き換えの際に .emacs.el という名前にしちゃったんだけど、それはともかく。
(when (fboundp 'XXX-mode)
())
(cond (window-system
())
(when (eq window-system 'mac)
())
(when (eq window-system 'w32)
())
(if (> emacs-major-version 21)
(progn
()))
なんかこんなの使ってます。
.zshrc
uname くらいしか思いつかないけど、そんなもんなんでしょうか。
- Linux
- FreeBSD
- Darwin
あとはコマンドの実行をそのまま評価したり。
Rake の定義
task 定義
- file
- dir
- task
「何かの処理で何かのファイルを生成する」のでなければ task を使う。
メソッド定義
task の定義時に必要なメソッドは当然 task 定義より前に定義されていなければならないが、実行時に必要なメソッドは task 定義のあとに書いておくことができる。
def method_A
end
if ( method_A )
task task_A do
method_B
end
end
def method_B
end
つまりこういうこと。
Rake の呼び出し
task 呼び出し
task の中から他の task を呼び出すことはたぶんできない。依存 task として定義することはできる。
ということは task は何かの戻り値をもとに処理を決定するように書くのではなく、何かの処理が完了している場合にこの処理が実行可能という形で組み立てていく必要がある。
メソッド呼び出し
task の中からメソッドの呼び出しは普通にできる。
ただし task も namespace も Ruby 的には Global というか main のメソッドであり、その中のブロックも main に属している。例えばメソッドを何らかの module や class の中に用意した場合、task のスコープと合わないので変数の受け渡し、定数の参照で食い違いが発生する。(恐らく Capistrano は set メソッドでこの問題を解決している。まだそこまで読み込んでないけど。)
ここ注意。
オプションを取らずにタスクを取る
基本的に Rakefile で扱えるのは task のみで、Ruby スクリプトへオプションを与えるという形は考えない方がよさげ。
仮に似ているけどちょっと違う task というものが増えそうなら task 定義そのものを動的に行えるようにすればよい。task はメソッドとは違うので、特に難しいことはない。例えば
[ .. ].each { |e|
desc "desc_#{e}"
task "task_#{e}" do
..
end
}
てな形。
デフォルトでタスク一覧を出力
Rake は default を定義しておかないと怒られるが、default でいきなり仕事が始まっちゃうのはちょっとなぁと思ったので、-T 相当の動きをしてくれるようにしてみた。
注目すべきは libipmsg を作っている点かしら。これで各プラットフォーム向けにバラバラにできてる感のあった IP messenger が扱いやすくなる予感。なにげに Win版v2 互換度がいちばん高いものなんじゃなかろうか。
動かしてみてないけど。
SourceForge.net: New Spyc (0.2.5) for a New Year!
だそうで。PHP で YAML を扱う人は要チェック。って、まずお前がチェックしろってか。
CHANGES を読む限りはなんかすごく速くなってそうな予感。わくわく。
個人的には中高生くらいの頃から、正月にことさら一年を振り返ったりする TV がいやで、なおかつまったくこの頃に気持ちが新たにならないことを自覚していた。学生にとっては特に気持ちが新たになるのは年度の切り替わる4月だもの。
今は「そういえば何かの区切りに振り返っておかないと、ずるずるいつ何が起きたんだかよく分からないまま老けちゃうよー」という変な感覚が強くなってきている。一応去年は自分の中だけのニュースを列挙して振り返ったが今年はまだやってないな。今度(こら)やってみようかな。
今回は帰省の車中で『金持ち父さん貧乏父さん』を読んでいた。面白かった。まだあまり現実的な話として自分の中に入ってきていない部分が多いんだけど、少なくとも地道に会社のために働くことが、まったくと言っていいほど将来のためにならないことだけは理解しているつもり。
帰ってきてご飯を食べたら何をやるかというと、休みのたびにやっているんだけど Windows のアップデートorz いつのように CD を用意してあるのでそれを、、、ないorz うわー。せっかく作った CD 忘れてきたよーと思ったら元データをノートに入れたまんま持ち歩いている自分。うーん。でも CD 作成の作業をやらなきゃこの元データは存在してないんだよな。えらいぞ、一昨日の自分。
とりあえず IP messenger で大量のファイルを転送。10BASE/T なんだけどギリギリくらいのスピードが出る。さすが。Adobe Reader とか OOo とか J2RE とか Firefox とかをどっかんどっかんインストール。しかし WindowsUpdate の分は面倒で用意してない。ここからが長いんだよな。何しろまだ ISDN だから。
というわけでも WindowsUpdate を待ちながらもそもそと日記を書きながらいつも通りに新年を迎えたのでした。明けましておめでとうございます。
HTML のタグそのものと a, list についてクラスが完成。これで必要なパーツはほとんど揃ったので内容に注力できそうな予感。よっしゃ! あー疲れた。
時間はいくらあっても足りない。頑張ってるつもりなんだが、自分の要求水準に達することが全然ない。なんなんだ。実力不足か、まだまだわき目振りまくりなのか。要求水準が高すぎるってことはないと思うんだが。
あれこれ考えて自分のマシンにまた Namazu を仕込むことにした。手元のデータを Namazu と Wiki で使いやすくしようって魂胆。なぜか正月実家に帰ると自分のマシンの整理をしたくなる自分。(通信環境が弱いからなぁ。)
しかし「せっかくだし」と突っ込んだ ActivePerl 5.8.2 に対応してなさげ(2.0.12)。5.6.1 build 635 にしたらうまく行った。うーん、少し面白くないなぁ。まぁ Namazu ってもうあまり構われていないしねぇ。代わりの検索システムが出てくればいいんだろうけど。。。
機会があったら Namazu 以外のシステムも試してみるか。