Google Calendar API v2でredirectされる場合が出てきた

たぶんv2なんだけど、よく分かってない。

今回の話はRubyで、使っているライブラリは

wtnabe/gcalapi

です。

リンク先は fork した自分のリポジトリで、こっちで redirect に対応しましたという話。

自分は Android にカレンダーの「参照」機能がないことに困って1wtnabe/ical2gcal で RTM のイベント(iCal)を Google カレンダーに取り込んでスマホなどから確認できるようにしているんだけど、これの転送に一昨日くらいから急に失敗するようになってきた。（実際には以前から毎回必ずうまく動くわけではないんだけど、現実的に困らない程度には同期が取れる状態になっていたのに、それがまともに同期できなくなった。）

で、とりあえず手動で動かしてみると Moved Temporarily ってエラーが返ってきてる。これを確認したところで Twitter に投げておいたら

こんな返事をもらったので、

  • gcalapi を fork して修正
  • gcalapi を利用している ical2gcal の方は依存ライブラリの URL を変更

てな感じで対応しました。

とりあえず Bundler で使っている場合は

gem 'gcalapi', :git => 'https://github.com/wtnabe/gcalapi'

ってしとくと 0.1.2r （redirect対応）が入ってなんとか動くようになります。ical2gcal はこれを利用するように変更して新しい gem を push しておきました。

本当は pull-req した方がいいんだろうけど、すでに github 上の repos と rubygems.org の gem は作者が合ってなくて、どこに push しても変わらんかなという気がしたので、fork したものを Bundler で使うようにしちゃいました。

どうせ Google Calendar API v3 に移行しなくちゃいけないので、そのうち gcalapi は使わないように変更しなきゃなー。（と、実は1年くらい思っている。）

※ インフルエンザの予防接種受けたので酒が飲めなかったおかげで思わず 昨日はだらだらコード書いて夜更かししてしまった。

  1. iOSには大昔からある ↩

embed gist用にCSSを追加した

ほんとはその CSS を gist に置こうとしたんだけどうまく post できないので日記を書くメソッド。「ありがち」だとこんな感じでだいたい gist っぽい表示になる。気をつけるのは table, td, th, pre, heading 辺りかな。

tDiary 2.2 系標準テーマで全部同じように効くかどうかは分かりません。div.main や div.section の中にたぶんスタイルを書いてるんだけど、目的の要素の前に .gist や .gist-data があった場合に gist っぽいスタイルを自分で書いたりしてお茶を濁してる感じです。

.gist-data h1 {
  background: none;
  color:      inherit;
}
.gist-data h2 {
  background: none;
  border:     none;
  color:      inherit;
}
div.main .gist-data table {
  background:      transparent;
  border-collapse: separate;
  border-spacing:  1px;
}
div.main .gist-data table,
div.main .gist-data th,
div.main .gist-data td {
  border-color: #999999;
  background:   none;
}
div.main .gist-data th {
  background: #eeeeee;
  text-align: center;
}
div.main .gist-data table.lines {
  border-collapse: collapse;
  margin:          0;
}
div.section .gist-data pre {
  line-height: inherit;
}

Colloquy 乗り換え失敗

さて先日からの問題で、nadoka + X-Chat の組み合わせが悪いのは分かっているのだが、nadoka を直す時間もスキルもない場合はどうしたらいいのでしょうか。そうですね、

  1. nadoka をやめる
  2. X-Chat をやめる

どっちかだと思います。このうち 2 の方がコストが小さそうなので 2 を試みます。今回用意したのはこちら。

Colloquy: IRC, SILC & ICB Client

現在の IRC クライアントの状況

Colloquy のデフォルトの設定は複数のチャンネルを利用しようとした場合にあまり使いやすいものではありませんでしたが、タブ付きウィンドウ + ドロワーによるリスト表示 の状態にしたらほぼ X-Chat と同じ使い勝手が実現できました。よーしよし、じゃあ乗り換えるかと思って Colloquy から手元の TwitterIRCGateway に接続したとき、Colloquy がいきなり落ちた。

しゅーりょー1。

そうです。実は登場人物はもう一人いたのです。それが Twitter. 先日 IRC クライアントで使うように設定 して以来、こいつも同居できてくれないと困るわけです。

でまぁ結局最後に登場してきてまだ便利さがよく分かっていない nadoka の proxy 接続が追いやられてまだ放置プレイ中だったりします。

OSX の IRC クライアントは以前からいろいろ試しているので、他に自分の気に入ったものがあるかどうか疑わしく、難儀しています。とは言えほとんどのクライアントは数年前にチェックしたきりなので今は多少は状況が変わっているかもしれませんが。

うーん思ったより大変。

[2007-12-16 追記] Conversation も TwitterIRCGateway に繋いだら落ちた。もうどないやねん。

  1. TwitterIRCGateway のバージョンアップにも少し期待したけど、Changes を読む限りでは関係なさげ。 ↩

PukiWiki にケチつけたくなる気持ちは分かるけど

秘密結社UBE本部 Wikiは氏ね

記法については自分はよくできてる方だと思ってるのでこれは置いとくとして。

PukiWiki はすでに雑誌や書籍で扱うことが普通になっちゃったけど、内部の作り的には結構ダメな部類だと思う。それでも流行ったのは PHP というキャッチーな言語でほとんど class レスという、まるで Perl 4 時代の KENT CGI のような作りだから。つまり、チープ改造厨に受けたという要素が大きい。1しかし現在の開発の状況は正直芳しくない2し、派生プロジェクトも小手先の改造に終始している感が否めない。

つーか今から新規に Wiki を使い始めるなら PukiWiki である必要は全然ないんで。「PukiWiki がスタンダード」だなんてデマに騙されずにあれこれ試してみればいいし、自分で設置して動かすのが面倒くさいなら livedoor Wiki とか使う方が「ユーザー」的には正しい選択だと思う。すでに大量の資産ができちゃったのでわたしゃ他の Wiki に移ろうって気もなくなっちゃってるけども。

※ 遅い遅いっていうのはもしかして localhost で動かしてるのかな。だとすると結構重いはず。デフォルトの関連ページだのなんだの重たくなる機能をすべて取っ払って別な機械でサーバ立てて動かせばかなり軽く動くと思う。少なくとも検索さえしなければ。Apache2

  • mod_php なら Windows でもそれなりに軽い。でもまぁ、編集してる文書の倍近いデータを毎回転送するとか、問題はあちこちにあるんだけど。

日本語が安心して使えて導入が楽ちんでオープンソースなエンタープライズ Wiki みたいなものがあればいいのかな。まださすがにちょっとそういうのは難しいよね。

あと個人的には Web デベロッパ界隈に「Wiki の開発が流行らなくなってしまった感」があるのがまずいような気もする。本当は設計がきれいで拡張しやすいとか、逆に他の CMS やアプリに組み込みやすい Wiki ってのを作る余地はまだまだあると思うんだけど、そういう方向は「DB からちょこっとデータ取ってきて Ajax でサクっと編集」とか「Feed を加工してマッシュアップ」みたいなものと違って今は流行らないんだよね。なんか今から Web アプリ発表するなら prototype の一つも使って Web 2.0 風のエフェクト掛けておかなきゃ、みたいな訳の分からない強迫観念があるんじゃなかろうか。

  1. もっとも、自分も PukiWiki を一度改造しまくったおかげで PHP での処理の問題点を山ほど勉強させてもらったわけだけど。 ↩

  2. カンファレンスや雑誌、書籍に名前や人は出てくるが、コードを commit できる人、したいと思う人がほとんど出てこなくなったし、プロジェクト代表はドメイン管理もそっちのけで Rails と Ajax に夢中。 ↩

雪

なかなか降りますね。12月中にちゃんと積もるのはずいぶん久しぶりな気がします。

北陸は気温が高く、雪が水分を含みまくって重いので歩くのは大変です。なんで歩くのが大変かっていうと、なんか面倒になってタイヤ替えてないので、今は歩きなのです。あっはっは。ま、そんなときもあるさ。

Java Embedding Plugin for Mac OS X

http://javaplugin.sourceforge.net/

恥ずかしながら知りませんでした。Safari 以外でも最新の Java 環境をプラグインで利用しよう。

すーばーらーしーいー

「IEでしか読めないページ，Windowsでしか使えないシステムは不適」，経産省が調達ガイドライン作成へ (IT Pro)

ま。当たり前なんですがね。

この認識が広く、そして早く広まることを期待。

ニューキーボードゲッツ

予定より1週間ほど早く届いた。改めてお名前を。OKI MINI KEYBOARD Pro 日本語 89 KEY でございます。

思ったよりキートップとキーピッチがでかい。感触は ThinkPad の感触をちょっと鈍くしたような感じ。簡単に言うと少し安っぽい感じがする。やはり ThinkPad 並みとはいかないみたいだ。でも全体的には浅く軽いこのキータッチはかなりいい感じだ。静かだし。

ポインティングデバイスはやはりどう考えても TrackPoint には遠く及ばない。TrackPoint のセンターボタンの使い心地に慣れるとこのホイールというやつは操作性が中途半端な感じがする。また、ポインタの動作もカタイ。TrackPoint のように 1px 単位で動かすのはかなり至難の業だし、クリックの感触もカタイ。キーボードの感触が軽めなだけにこのギャップが、気になってしまう。TrackPoint のような柔らかいクリック感を望むのは贅沢すぎるということか。世の中でこの TrackPoint 系のポインティングデバイスの評判は総じて見るとあまり高くないと思うのだが、それはこういう微妙なチューニングのできていないデバイスの評判が浸透しているからなんだろうなぁ。

ファンクションキーの向こう側に余裕がない。要するにファンクションキーは沈んでいるカッコウになってしまっている。かつて似たようなキーボードを触ったことがある。Compaq Armada M300 のキーボードだ。そのとき感じたいやな感じを、やはり今も抱いてしまう。ESC キーを打つたびに指がぶつかってしまう。これは慣れないとけっこうつらいかも。

Home, End がカーソルキーに密着していて間違って押しやすい。↑ に PgUp、↓ に PgDn を Fn とのコンビネーションで割り当てたように、← に Home、→ に End を割り当てるべきだったと思う。最近の ThinkPad のキーボードもここにブラウズ用のキーを割り当てているけど、絶対失敗だと思うなぁ。

まーそれでもこのキーボードで、恐らくタイピングに関しての疲れはかなり解消できるだろう。やはりキータッチは軽くないとダメみたいだ。全体的に酷評しているように読めるが、値段を考えるとよいモノだと思う。ポインティングデバイス内蔵で小さいキーボードということになると現時点ではこれ以上の選択肢はちょっとないかもしれないと思うくらいだ。そうそう、ハードレベルで Ctrl と CapsLock の入れ替え機能があるので、Unix で素のコンソールを触る時にこのキーボードがあると重宝しそう。（USB だけど…。）

ただまぁ、ウルトラナビ付きキーボードがテンキーレスで出たら間違いなくそれがナンバーワンだとは思うけどね。来年の今くらいまでにそれが出ていなければ今度は Realforce 89 にしようかなぁ…。

それにしてもぷらっとホームから届いた箱がでかくてびっくりした。OKI の製品の箱をさらに取り扱い厳重注意の精密機器として梱包していた。うーん、キーボードなんてそんな壊れるもんじゃないだろうに。Space Saver の箱そのまま送ってきた若松通商とは大違いだ。

About

例によって個人のなんちゃらです