リマインダーと ToDo リスト。
探してないから、あるのかないのかは分からない。ここに書いてある事はあまり(ほとんど)熟考しないでメモ感覚で書きなぐっている。だから、恥ずかしげな間違いもするんだけど、まあそれはご愛嬌(〜メソッドで逃げたり)。
そんな訳で、色々と ToDo 感覚で忘れないうちに書いとけって感じになる。問題は、結構放置エントリーもあるってこと。追っかけようと思って書いたはいいけど、次々に新しいものに目がいって流れていったり。
MT のキーワードか RightFields とかでそれ用のフィールドデータ用意して、それをもとに拡張できたりしないかな？データを別場所にストアしておいて、それを Gmail かどっかに投げてもいいんだけど。とりあえず、MT ポストと連動して動いてくれると嬉しい。
別サービス(check*pad)とかで管理してもいいんだけど、MT ポスト後にもう１回作業ってのも面倒。その時に片付ければいいのかもしれないけど、そうもいかなかったりするし。
まずは調べてみるか。
会社で使ってる Hiki が Hiki Farm で簡単に作れるようになった。で、ちょうどあるホスティングサービスの焼き直しというか別クライアント用に移植(?)する作業をしていたので、なんとなくいいなーと思ったり。
考え方自体は、特に目新しい事ではないかもしれない。Blog だとかのホスティングサービスではぱっと見、各ユーザにアプリケーションのクローニングをしてるようなものだし。じゃあ、なんで今扱ってるサービス(アプリ)を対応させてないかって言うと、なんでだろう。性質的にクローンを作る機会は想定できたんだけど、時間かな。自分には精一杯だったんだ、と言ってみよう。移植作業は量的に大した事ないし…、でも検証とかがなぁ。
クローニングをシステムに取り入れて、その辺含んだ検証を済ませておけばオペレーションを人任せにできるし、さばけ具合も違う気がする。となると、結構まずいミス？はぁ、今も結構急がしめな雰囲気なんだよなぁ。上の人に強引目に「この部分のテストが残ってます！先のばしたら忘れます！手間です！」って言って無理矢理今のタスク作った訳だし。これ以上は、ね。
なんとなく、強めの興味が引かれるところ。これって常識機能？
機能変更、お知らせなど - はてなブックマーク日記 - 複数タグによるブックマークの絞り込み機能追加について
Yahoo MyWeb2.0 を使っていた事もあって、「あって当然」な機能として受け止めていた「関連タグ」での絞り込みについに対応してくれた。まあ、最近ではそれほど強い欲求があったわけじゃないけど、やっぱ嬉しい。これで「組み合わせフィルタ」でアグリゲーションできる。Web インターフェース(HTML)も RSS も直接引っ張って来れるから、ちょっとした使い方で「はてなブックマーク関連タグ検索」ができるわけだ。
そういえば、HTML 側の URL は / 区切りできれいなのに、RSS だとクエリがくっつくのはどうして？パラメータ的に難しいとか？まあ特にこだわりはないからいいんだけど、CoolURIを結構意識してたと思うから暇になった時(があれば)やって欲しいかも。
さて、これでローカルにごっそり持ってきた意味が薄れてきたかな…。１日１回、「はてな to Local/Local to del.icio.us」っていう強引な同期をしてるんだけど、どうしようかな。XPost を常に出来るように職場環境を整備するのはいずれやるとして、「ローカルにデータを持つ意味」を早めに定義しちゃわないと、惰性に成り下がっちゃいそう。
「XUL ではてなにお化粧する」位のつもりでやった方が身の丈に合ってるかも。設計とか運用とかの勉強に自作プログラムの題材が欲しいんだけど、あまり意味がないものを題材にするのも気が引ける。トラフィック量での迷惑行為を考えると、ローカルに毎日ちょっとずつバックアップしとくのはいいかなと思うんだけどね。
まあ、とりあえず念願の(?)関連タグサポートおめでとう、オレ。
はてなブックマークの連鎖反応は知ってたけど、ブログで体験すると結構びっくり。
ご指導 TB 経由で過去最高のアクセス。StatWatch 見た瞬間こし抜けるかと思った。"Hits Today" が見た事ない数字になってる。まあ、有名ブログなら少ないくらいの数なんだろうけど、小物を自負する身としては相当なもんだ。
せっかく教えていただいたものを無駄にするのも嫌だし、これを機会にサーバ周りも積極的に勉強しないとな。分かってはいたんだけど、ネットワーク技術は必須。ネットワークエンジニア程の知識はいらないと思うけど、せめて WebAPI を実装して疎結合を実現させる為に必要なサーバ整備関連知識は早めに身につけないと。まずは負荷分散とか？
えせミレニアム！
KoshigoeBLOG: 内向き API と外向き APIで書いたことで指摘を受けたのでメモ。
naoyaのはてなダイアリー - 疎結合のための Web API
違うよー、DB 直接叩かないのはサービス間の密結合を避けるためなんです。疎結合。
せっかく『XML開発者の日』に参加してみても、まったく身についていなかったようです。見当違いなこといって申し訳ない。疎結合はかなりのキーワードでしたね。
自分のケースでは、データ量を上手く調整できていなかったせいで、「DBからデータ取得→整形→ onHTTP →取得→パース→集計」みたいな流れが高負荷になっていたわけです(データの性質的に更新早くてキャッシュもどうしていいか分からないし)。で、 on HTTP をやめた理由の１つに外に公開する予定が無くなった(予定は未定)のでストレス感じさせるようなつくりはよくないだろう、と。まあ、初期設計段階で問題があったってことなんでしょうけど。
はてな SNS (ダイアリーも)での事は「流通しちゃった RSS の制御」は無理だってことなのかな？パブリックで書いた日記をプライベートにしても、巣立った RSS には手が出せない、と。MT で記事を修正してもそれが Bloglines に反映されるまでには時間差があるわけだし。売り場に並んだ肉を回収するのは一苦労なんだ、と(…、なんか違う)。
勘違い記事のせいで不愉快な思いとかしてたらごめんなさい。ご指摘ありがとうございました。
野良 RSS (キャッシュされた RSS)って厄介かも。
はてなダイアリー日記 - はてなSNSにおけるプライベートモードの日記の取り扱いについて
はてな SNS は RSS をアグリゲートしているらしい。以前勤め先でちょっとした機能を実装する際に、外向けがあるかもってことで XML on HTTP な API でデータ受信できる仕組みにした事がある。これは、データ量とかパースの手間とかの問題で DB 直読みに変更したんだけど、はてな SNS は RSS から読んだ方が効率がいいのかな？
DB アクセスがボトルネックになるって話はよく聞くから、自分のケースと一緒かは分からない。でも、RSS 生成時に DB アクセスが必要なら、特に意味はないんじゃないかな、と。古い情報がキャッシュに残ってしまうっていうのも結構見落としがちなケースで、実際リリース前のテスト時に引っかかったりする。今ではその辺も(頭の中の)チェックリストにあったりするんだけど。
はてな 【本当ですか？】 日記をプライベートモードにされているユーザの皆様。 『はてラボのはてなSNS(http://sns.hatelabo.jp/)で、はてなダイアリーを ・・
(例え閲覧側に対してプライベートでも)Web サービスに致命的な個人情報を載せるってのはあり得ないし、それは利用者側の注意不足というか情報リテラシー(?)がどうこうって部分だと思う。ただ、やっぱ隠したい情報を隠せないってのは問題。ただでさえ、はてなブックマークが嫌だって言う人がいる状況なんだし。
50% ルールとか、ラボ企画の難しさなのかな。実は最近似た感じのミスをしてる。「既存財産(情報)に対する影響」を見落としてしまった事によるミス。機能追加の際には、その機能へのチェックリストとそれが影響する範囲の抽出／チェックリストが必要だと思い知らされました。
ラボ企画自体は、個人的に賛成。楽しいものがぽこぽこ出てくれると何となく嬉しいし、刺激になったりもする。ただ、やっぱ「気軽」だけで進めていくと見落とす事も多かったり。社内ラボの場合は、あくまで「中の人が作っている」っていう制約がある事を意識しておかないといけないな、と。
で、まあはてなの失敗(?)については注意点を教えてくれたケーススタディとして受け止めるとして、気になる事はちょっと違う。内部で利用する API に内部から提供する on HTTP なものを使うべきかどうかって事。RSS みたいな公開フォーマット(?)はパースしやすいし、手軽に使えるってのはいい。ただ、せっかく内部の情報を使えるのに、あえて公開 API を使う利点ってのはどこにあるのか、と。
以前の失敗を考えると、DB を使えるなら DB から直接データを取り出して、プログラム的に使いやすい形に整形する方が手間がないと思う。 on HTTP で流す情報も大本は DB な訳だし、DB ボトルネックもそれほど関係ないんじゃないのかな？キャッシュどうこうって問題は両方のケースでそれなりの仕組みが考えられると思う。サーバ周りは弱いから言い切れないんだけど、HTTP キャッシュ(サーバアプリに実装されてるやつ)に頼る方法とプログラムレベルでのキャッシュ機構とでどれだけ違いがあるんだろう？
自分の失敗は、Web 2.0 熱にうなされてた時期の失敗だったと理解してるんだけど、細かく「内向き API と外向き API」について考えたりはしてない。実際はどうなんだろう？
このごろはてなブックマークのトップを使わず各分類ページを直接使っているせいで、どれがどういうページなのか分からなくなってきた。
特に、ある URL 以下の被ブックマークを調べるために、/entrylist はよく見ている。で、似たものとして /bookmarklist もあったり。/entrylist は「注目」具合について見ていて、/bookmarklist は「新着」をみている。しきい値設定が出来るか出来ないかの違い(だと思う)。
/entrylist は Web インターフェースを見ると 3users|5users っていう選択ししかない感じで、今までとりあえず 3users で自分のドメインの被ブックマークをチェックしてた。で、/bookmarklist 経由のアクセスがきっかけでこっちで調べるべきかもとか思ったんだけど、実は URL いじったら済む話だった。はてなブックマークでそんな話題を見かけた気がするけど、流してた…。しきい値は threshould で設定可能。
はてなブックマークはアプリケーションっぽい機能集合な感じがする。個人的な使い方の問題かもしれないけど、必要な機能(集約方法)だけをブックマークなりフィード購読なりして使っている。なので、Web っぽい導線を意識して使う機会がなかったり。一般的な情報が集まる「ポータル」っぽく見ると Web の導線を意識した UI 設計(?)が必要なんだろうけど、ここまで機能単位での切り取りが簡単になってくるとその辺は意味なく見えてしまう。「(いるかわからないけど)一般人の利用者」を意識した場合は必要だろうけど、まあどうなんだろう。
API も充実してきてサーバ状態も落ち着いて来たらの話だけど、ブラウザを経由した利用じゃなくしてもいいんじゃないかな？広告収入とか考えれば、Webインターフェースを無くすなんて事はあり得ないけど、使いやすさを考えれば専用クライアントがあると面白そう。データをローカルに落とす事が出来れば操作周りも色々と充実させられそうだし。データのインポートをどれくらいで終了できるかってのが問題ではあるけど、そこをクリアできれば「自分のブックマーク」に対するアクセスはかなり楽が出来ると思う。
『「自分のブックマーク」へのアクセス』に関する操作系を充実させたとして、じゃあ何が出来るのって言われると「何かな？」としか答えられないんだけど。そういえば、Web Service のクライアントってほとんど Web アプリケーションな気がする。なんでだろう？Web 開発者しか興味がないのかな？「売る」事が出来ないから「広告経由」で収益を上げるしかないってこと？利用回数が制限されてるものもあるし、その辺も関係するのかな。
「デスクトップと Web とをシームレスに」ってのはまだまだ現実的じゃないのかな？
オブジェクト指向でよく聞くのが抽象化。アジャイル開発でよく聞くのが独立性。
どちらもまだいまいち身に付いてないから細かいところは分からない。とりあえず、これからのプロジェクトの進め方がアジャイルでやっていこうってことなので、独立性ってものは意識しておかないとまずい気がしてる。
クラスを基本単位にして設計／実装を行う場合、問題対象を抽象化する。で、抽象化とかクラスとかで再利用が云々って話になると、すぐ思いつくのが継承。基本になる abstract なクラスを設計して、それを継承して具体的なクラス(具象化？)をしていく。で、ここで注意しないと、階層的に依存関係ができたりするのかもしれない。そうなると、独立性の問題が出てくる。アジャイルは「変更がある」事を前提にしているから、依存関係がありすぎるとつぶれると思う。横関係での依存関係(クラス内でインスタンスを"作る"とか？)も注意しなきゃいけないけど、変更前提な進め方をする場合、縦関係も注意しておかないと危険な感じがする。
結局、再利用がどうとか考えて複雑な関係を作ってしまうと、「作り直した方が早いし安い」って事になるっぽい。「シンプルな設計」と「生産性を考慮した継承」とのバランスをどうとっていくか。プラグイン機能について調べてみたらその辺のヒントが掴めるのかな？
以前買うだけ買っておいた『アジャイルソフトウェア開発の奥義』をそろそろちゃんと読まないとか。いろいろたまって消化できてない…。
今見ているページの被ブックマークを知る場合は、"del.icio.us related"として用意されている事は分かった。
じゃあ、サイトレベルで集約された結果を見る方法は用意されているのか。多分、はてなブックマークみたいに URL を指定して、「その階層以降を含む」っていう調べ方は出来ない感じ。…、どうしよう。MT からアーカイブのパーマリンクもってきて、"del.icio.us/rss/url" をアグリゲートしてったらいいのか？エントリの数だけアクセスしないといけなくなるし、これはさすがに駄目でしょう。
実はそれほど難しい事じゃなかった。"del.icio.us/search/all="経由で、サイトに共通したタイトルを検索したら解決。一本釣りできるかどうかはそのタイトル次第ではあるんだけど、"Koshigoe***"では問題なかった。
…、このくらいすぐ思いつかなきゃ駄目だよね。
http://del.icio.us/url/[MD5(URL)]
今見ているコンテンツの被ブックマークを知りたい場合、Bookmarklet を使えると簡単。で、del.icio.us って URL を MD5ハッシュで渡さないといけない。JavaScript でも高度な JavaScript 技集で公開されているライブラリ使えば (少なくとも)PHP の md5 関数と同等の結果を得られるんだけど、Bookmarklet で外部スクリプトって読み込めたっけ？
いい感じの方法が見当たらなかったので、とりあえず強引にローカルサーバに置いた PHP スクリプトを経由する Bookmarklet を作ってみた。
Bookmarklet
javascript:location.href='http://localhost/widget/durl/proxy.php?'+location.href
proxy.php
<?php
$url = (isset($_SERVER["QUERY_STRING"])) ? md5($_SERVER["QUERY_STRING"]) : "";
header("Location: http://del.icio.us/url/" . $url);
?>
Firefox Extension でボタン作ったらもっとスマート(?)にいけると思うんだけど、とりあえずはこれで。del.icio.us をもうちょっとしっかり探したらその辺のツールが提供されてるのかな？色々と公開されてるけど、いまいちどれが何なのか分からない。メインの SBS ははてなだし、詳しく見た事がなかったり。
URL を受け取る Web アプリケーション(サービス)を利用して「今見ている URL に関する情報」を調べる場合、Bookmarklet を使うのがお気に入りなんだけど今回みたいなケースはどう解決するのが正解なんだろう？Ajax の外部ドメイン問題もなんだけど、自前(同ドメイン)のサーバサイドスクリプトを経由するってのは強引すぎるのかな？Greasemonkey で常にリンク出しておくとかも微妙だし、Firefox 以外使わない事考えると XUL でボタン？
まあ、超個人的ツールだしこれでよしとしよう。
Koshigoe ChangeLog - リージョン内を PHP eval してミニバッファに出力
細かい事は分からないままなんだけど、shell-command-on-region でリージョンの中身をパイプ処理で外部コマンドに渡せるらしいので、Web を漁ってそれっぽい elisp を書いてみた。
とりあえず、EUC-JP スクリプトでそれなりに動きそうな感じ。
while(!feof(STDIN)) {
$region .= fgets(STDIN);
}
$argv で受け取れると勘違いしてた。パイプはストリーム(?)だ。raw POST もこの辺で受け取れるとか何だとか。
アドバイスを受けて、SGML のエスケープは用意されたモード付属の機能で実現する事ができた。
PHP をちょこちょこいじる際に、Emacs で編集してるんだったらわざわざブラウザ上で確認する必要もないんじゃないかと思ったりする。CLI にしても、ファイルに保存してターミナルから実行ってのが面倒。Emacs Shell(?)だとしても同じ。リージョン内のコードを eval して、結果を別バッファで表示したらいいんじゃないかと思うんだけど、これはどこかで用意されてたりするのかな？
http 経由での実行結果を知りたい場合は、phpinteractive を使った方がいいと思うんだけど関数の評価をしたい時とかは Emacs で完結すると嬉しい気がする。Perl なり Ruby なりで調べたら似た感じのがあるかな？
会社に行ったら机の上に Zend Studio 5.1 が置かれていた。
Zend Studio 自体は入社時から用意してもらっていたんだけど、Emacs を使い始めた事と使いこなせなかった事から利用をやめていた。で、せっかく最新のものを用意してもらった訳だしアップグレードしてみた。
ちょこちょこと何が出来るのかを確認しながら設定をいじってから使い始める。デバッガ機能は coLinux 上で試してないから保留だけど、Subversion 連携は嬉しいかも。psvn を使いこなせてない現状を考えると、これはなかなか嬉しい。ただ、カーソル操作(ページング周り)が不満だらけ。Zend Studio は結構独自のキーバインディングで、高機能なだけに数も多い。特に、メタキーとの組み合わせは xkeymacs を有効にしても使えるか微妙。文字が小さいからだとは思うけど、カーソル移動が重いし。コメントとか関数とかのブロック畳み込み機能は楽しい。Emacs でどうやるかは調べてないけど、できるのかな？
基本的に、編集作業だけを考えるなら、Emacs でいいと思う。問題は、リモートデバッグみたいな機能。開発環境として塚ている仮想マシン上(PHP5)で問題なく動くようなら、開発は Zend Studio で行う方がいいかもしれない。気になるキーバインディングも、一応は Emacs セットみたな項目が用意されてるし、ちゃんと調べれば Emacs の挙動を実現できるのかもしれない。PHPUnit/phpDocumentor/Subversion/Debugger/Editor あたりを１つの環境で完結できれば嬉しい。
世の中の PHP プログラマは何を使って開発してるんだろう？Emacs って少数派？ペアプロとか考えると、チーム共通の環境ってのも必要になりそうだけど、効率考えると慣れたものを使いたい。「コンソールを共有する」必要はあるけど、「マシンを共有」する必要ってないのかな？VNC ってのも現実的じゃない気がするし、動きやすい机の配置が重要なのかな。一応、職場の開発チームでは「背中合わせルール」を実践している。助けが必要な場合は横か後ろを向けばいいし、「机越しにこんにちわ」で照れる事もない。
とりあえず、Emacs から PHPUnit/phpDocumenter/Subversion/Debugger を操作する方法を探してみよう。
前に作った del.icio.us 版を焼き直して簡素にしたもの。かなり車輪度高め。検証不十分。PHP4 で動作。
…、みかん箱行きだ。社長、今日出した要望破り捨ててください。
X デーも近いなぁ。考えて行動してるつもりなんだけど、見当違いの方向に進んでるのかな？
どうやら"/search"で稼いでいたらしい。「人」じゃなくて「ボット」？まあ、疑惑(?)が晴れて一安心。
ウェブ上で WYSIWYG。スタイルとレイアウトが選択できて、"http://アカウント.googlepages.com/"にホスティング。これは何狙いなんだろう。ブログは先がないとか、ユーザ層的に限界が見えてきたって事？レイアウト的にブログっぽさがあるけど、どうなんだろう。
UI の実験なのかどうなのか分からないけど、どうも微妙。もちろん、技術的にはすごいんだと思うけど。
ドメイン取得した際に、lab.koshigoe.jp としておもちゃ置き場を作っておいた。
とりあえず、Wiki の方に置いていた Greasemonkey を持っていってみた。はてなブックマークの自分のブックマーク一覧に、ブックマーク URL のドメインか第１階層の URL に対する entrylist へのリンクを追加する Greasemonkey も追加してみた。使い道は微妙な気もするけど、記事単位で切り取る事が多くなって、その前後とか他の注目されてる記事を知りたい時に使おうかな、と。
JS いまいちなので、もし使う場合は要注意。動作確認は、OSX(10.4.5)の Firefox1.5.1。
いつからか分からないけど、タグをインクリメンタルサーチできるようになってたらしい。
自分のブックマークリストにトップからタグリストを表示しない設定にしていたので気づかなかった。たまたまタグで絞り込んだら、変な入力欄があったので適当に打ち込んでみるとどうやらインクリメンタルサーチができるらしい。ちょっとびっくりしたけど、「初心者向けじゃないサービス」だし、どこかでアナウンスはしてるんだろうからありなんでしょう。軽く「クラックされたか！」って思ったのは自分くらいだろうし。
こんな調子でいつのまにか「関連タグ」での絞り込みも出来るようになるのかな？個人的にはラボもいいけど、もうちょっとデータ利用周りを発展させてくれたり、次のステージへの展望を見せてくれたりすると嬉しい。はてなSNSについてはSNS自体使わないから割とどうでも良さげなんだけど、統合アプリとしてはてなサービスが使いやすくなるとすれば嬉しい。「SNS」ってものを意識しないでいいし、多分操作感も大差なく使えるんだろうし。
そういえば、自分用のローカルはてなが途中で止まってる…。そろそろ再開しないと。
clmemo@aka: HTML 内の <, > ,& を quote する |Blogger|Emacs|
M-x sgml-quote
*scratch* で試すと "M-x sgml-mode" してからじゃないと、"M-x sgml-quote[no match]"になる。HTML っぽい文を書いてモードが切り替わったら有効になるってことかな？
ちなみに、Emacs22 から使えるようです。
lisp さっぱりなので、どうしたらいいのか分からない。
ブログにプログラムのコードを貼付ける場合、HTMLエスケープしてから<pre>タグで囲んでいる。で、最近はブログへのポストを Emacs から行っているので、せっかくだしエスケープを Emacs からうまくやれないものか、と。今は別バッファにコピーして replace-string で置換して、元のバッファにコピーしてでなんとなので。
リージョン内のコードを読み込んで、それを置換するだけだからあまり難しくはない気がしてる。それこそ、自分でどうにかなるんじゃないかとか。置換周りは外部プログラムに任せたら簡単だろうし(PHP なら htmlspecialchars)。
先のエントリーで書いた事もあるので、自分で挑戦してみようかなとも思うんだけど、類似スクリプトがないとどうしようもない。
多分、この辺が分かればいけるんじゃないかな。車輪になりそうな気がするし、他に解決策があるような気もする。HTML 関係の mode とか調べたら機能として提供されてるのかな？どうしよう。
どうも根本的な事が分からなくなってきた気がする。
コードを書くとか、素早く書くとか、動くものを作るとか、オブジェクトがどうとか、アジャイルがどうとか。自分が身につけなきゃ(思い出さなきゃ)いけないのは「考えて実現する力」っていう根本的なところなんじゃないかと今更ながらに、不安感と一緒に思うようになってきた。これは働き始めてからずっとではあるんだけど、なんとか2.0とか新しいものに流されてうだうだやってきてしまったせいで頭の隅に追いやられてたように思う。
会社の上の人に「ツールギーク(フリーク)」と言われた段階で気づくべきだったんだけど、なるほど「プログラマ」じゃなくて「コレクター」っぽいそぶりを随所に見せていた訳だ。ちゃんと(無意識かもだけど)忠告してくれていたのに、気づけなかった。それが悪いとは思わないし、アンテナは張り続けるべきだと思う。けど、開発リソースが云々で困っている時にそんなことしてちゃ駄目でしょう、と。「勉強」してたらいいんじゃなくて、「何を」身につけようとしてるのか、「何が」出来るようになろうとしているのかをちゃんと考えなきゃいけなかった。
で、じゃあ何やったらいいんだってのが分からない。学生時代にクイックソートがどうとかハッシュがどうとかっていうアルゴリズムの授業は受けた。ただ、クイックソートもハッシュも今は言語レベルで用意されてる。そこで、それを理解して何にいかせるのって事が大事なんだと思うけど、よくわからない。発想の仕方？それを実現していく手法の中からプログラミング技術を学んで、それらを取り込んでいけって事なのかな。
結局、誰かのソースコード読んで興味深いコードを拾い集めていくって方法しかないのかな？「Aっていうサービス」の「x機能」ってどうやって実装されてるんだろう、こういう実装をするまでにどんなモデリング(設計、考え方)があったんだろう、とか。んー、これは実践できてない。見た目に惹かれるタイプなので、出てくるサービスを「使う」ところで止まってしまう。「似た感じのを作って勉強だ」って考えても、ソースコードが公開されているにもかかわらず自分で書くところから始めてしまう。勉強して身につけるのに簡単な方法は「誰かに説明できる」って事と「誰かに教えてもらう」が結構大事な気がする。そう考えると、プログラミングで「誰かに教えてもらう」事の「誰か」がソースコードに該当するのかな。後でコードを見る場合は答え合わせ？
なんだか自虐ネタっぽい愚痴になってしまった。これから始まるプロジェクトから本格的にアジャイル開発をやっていくみたいで、どうもアジャイルってのはプログラマ(開発者)の技量にかかっている気がしてしょうがない。今までは割と修正がメインだったから、既存財産を元に(迷惑かけながらも)なんとかやって来れた(と思う)。けど、これからはかなり厳しくなるんじゃないかなとかなり不安。なので、「緊急度高め」で根っこの部分で自己改善が必須。
『お勉強BTS』たてようかな…。ToDo とかメモよりもなんだか強迫観念が後押ししてくれそう。あー、中間試験とかあったらどうしよう。予習できる範囲ならあった方がいいかも？プログラマのドリルって売ってないの？業務レベルで役に足つ問題集くれぃ。
改めて技術者ってのは凄いなと思ったり。やっぱ自分で考えて調べて身につけてってのは重要だ。「教えてー」とか「英語読めねー」とか「誰か作れー」とか、駄目駄目だ。同じコードを２度書かないってのは実装中の話で、「同じ事をするコード」が存在したら「書かなくていい」って事じゃない。本当に書けるならいいけど、何の根拠もない自分には当てはまらない。「書かない」なら「読め」ってのが最低限の作法かな?
あまりにもネタが見当たらなかったので、愚痴エントリーでした。…、本当に問題集ってないですか？あ、どこぞのコーディングコンテストみたいなやつの問題を探したらいいのか？
色々と評判が立っているようなので使ってみた。
とりあえず１つのフィードを登録して読むところまで。
フィード登録の仕方が分からない。軽く探しまわった感じで、直接登録できないようだという事を理解。なので、ブックマークレットから登録してみる。…、「フォルダがない」と怒られる。マイフォルダはフォルダじゃないらしい。とりあえずフォルダを作っておく。作ったフォルダの下三角マークからメニューが出たので、そこから登録。ぽこぽこウィンドウ(DHTML)がでてくるのはいいんだけど、作業終了したら閉じてほしかったり。購読画面が３ペインで、フィードリスト／記事のリスト／アイテム閲覧とあるんだけど、見出しと概要を見て流し読みしたい場合にどうすればいいのか分からない。WEB型リーダーに慣れきっているので、クライアント型のインターフェースはちょっと苦手。
まあ、とりあえず乗り換えを考えるまでもないってのが結論。Bloglines っぽいインターフェースに慣れてると、どうもメーラー型のインターフェースは使いづらくなるのかな？Ajax がどうこうってのは β だから効果が見えないってことで無視。これから UI はものすごい早さで進化させてくれるんでしょう。お金いっぱいあるってのはいいなぁ。
QEMU の OSX 用 GUI フロントエンドQを使ってみる。
とりあえず簡単に試すところから。Q.app を ダウンロードしてインストールしたら、FreeOSZoo download pageからOS イメージをダウンロードして利用。Q の Guest PC->New Guest PC を開いて、Hardware の "Harddisk:"でダウンロードしたイメージを指定する。そうしたら、あとは再生ボタン(Start PC)を押して OS を立ち上げる。
x86 用の Debian を落として使ってるんだけど、なんだか起動がものすごく遅い。５分以上かかった気がする。とりあえず、Win の coLinux っぽい事が出来そうなので、これからちょっといじってみる予定。OSX は BSD 系だからそのまま使えばいいのかもしれないけど、あまりごちゃごちゃいじると色々不具合でたり、OS アップデートのタイミングで色々困る事もある。なので、開発環境みたいな混沌とする空間は切り離した方が安全。
ネットワーク周りとか色々いじんないと使えなそう…。サーバの勉強になるかな？
firefox からエディタを利用する方法
会社の Windows では xpi 読み込み時点で XML パースエラーになったので、自宅 Mac で挑戦。
SVN の関係上、デフォルト文字コードを EUC-JP にしているので、EUC 版をインストール。mozex の設定は以下の通り。
フォームのテキストエリア上からコンテクストメニューを出して"mozex->Edit Textarea"を選択すると、Emacs が立ち上がってフォーム内容を開く。それを編集したらバッファを kill して、テキストエリアをクリックすると編集内容が反映される。バッファは自動保存にしてるので、もしかしたら保存する必要があるのかもしれない。
気になるのは、Emacs が新しく立ち上がること。エディタ指定間違えてるとかかな？
なんで Feedburner にこだわり続けてたんだっけ…？
勤め先は『企業向け』の RSS パブリッシングプラットフォーム(?)を ASP で提供している。なのに、ここでは Feedburner を利用してきた。まあ、先出しサービスだし、ブロガー向きってのもあって使ってきた訳だけど、実際自社サービスと(利用する機能として)競合するものを使うのはいかがなものかと。別にシェアがどうとか、販売状況がどうとかって事じゃない。開発に身を置くものとして、その実際を知らなくてどうするのか、ということ。機能追加だとかバグ対応だとかはやってても、実際使ってなかった訳で、そうすると「こういう機能が欲しい」とかって要望も出にくかったり。トレンド調査とかはマーケティング担当の人ががつりやってくれてる(はずだ)し、自分はまず自分の足下見なきゃいけないっぽい。「この機能がいまいち」とか言われても実感できてないと「？」だし。
ホスティング前提で結果が出るサービスだから、両立が出来ない。Feedburner 発行のフィード購読者と自社サービス発行のフィード購読者を同じにする事は仕組み上無理。同じフィードを２つも購読する人なんていない。で、これまで使わなかった理由は、「有料サービスを使っていいのか？」ってのと、「企業向けサービスを使っていいのか？」っていう不安から。そんなものはちょっと上の人に確認をとって、使わせてもらえるように交渉すれば問題ないはず。基本的なところでコミュニケーション不足(?)だった感じ。
本当の一番の理由は、「『この会社に勤めてる』ってのが分かると会社に迷惑かかるかな」って事だったりするんだけど、最近「中の人のブログ」として無事公認(?)されたので、思い切って使う事に(勝手に)決めた。月曜日に胸はって事後確認しよう…。
ちょっとはサーバ関係を知ってみようと、とりあえずドメインとってみた。
取得したドメインは、koshigoe.jp 。HN とかここの名称にも使ってるんだけど、これは田舎の地区名。で、Blog と Wiki とおもちゃを置くホスト名を変えてみる。Blog は blog.koshigoe.jp。Wiki は wiki.koshigoe.jp。おもちゃ置き場は lab.koshigoe.jp。
一応、慣例に習ってホスト名を決めてみたけど、"lab"は完全に名前負け。まあ、Blog はテンプレいじったりして JS が動かなくなったりしてるので、サンプルは別場所に置いた方がいいのかな、と。アクセスできるようになるにはしばらくかかるし、整理するのにもさらに時間がかかるからひたすら待ちの状況。
サーバは移ってないし、sakura ドメインも有効なままだから特に何もする事がない。用意されたサーバ管理画面からちょこっといじって完了ってのは嬉しいんだけど、結局なんも勉強になってないのはご愛嬌。２重ドメイン生活(?)が始まる訳だけど、MT と dokuwiki が吐き出すフィードの URL いじらないとかな。せっかくドメインとった訳だし、sakura ドメインの露出は最低限にしないと。
今日の勉強会で、XUL のさわりについて発表した。
発表が終わった後に見つけた Web 上の記事。
【PHPウォッチ】第13回 Firefox/MozillaのXML言語「XUL」で作るリッチ・クライアント：IT Pro
PEAR::XML_XUL っていうパッケージを使う事で、XUL クライアントを構築する事が出来るらしい。2005/03/20 時点でメンテナンスが止まっているらしく、"This package is not maintained, if you would like to take over please go to this page"というメッセージが出ている。alpha 版のまま眠ってしまった模様。Ajax と違ってあまり人気がないのかな？
上の記事で知れて嬉しかったのは、XUL の動作定義は JS で行うという事。XUL が直接関わる処理の実装は全て JavaScript で行われると解釈して問題なさそう。実際どうかはまだ調査継続なんだけど、Ajax みたいにクライアント側の処理は JavaScript で行う。で、サーバ処理が必要な場合はクライアントの JavaScript からサーバスクリプトをたたけばいい。ちょっと考えればすぐに考えつく事かもしれないけど、XUL がどんなものかを知るだけでいっぱいいっぱいだった時期なので助かった。結局、HTML が XUL に置き換わったって事だ。
XUL アプリケーションは Ajax より楽しそうだと思うんだけど、あまり使われてない気がする。最近だと、MAB っていう Amazon 検索GUIアプリが出た程度しか知らない。ちょっと前だと、XUL で実装されたフィードリーダーの BloxOr とか。ブラウザ依存がある事とか関係あるのかな？インターフェースの貧弱さが HTML の弱点だと思うし、それを解決するために Flash とか DHTML が使われてるんだと思う。でも、結局デスクトップに似せたりして、普通の GUI に引っ張られてるってことは、OS が用意した GUI がより優れてるってことだろう。XUL アプリを単体で走らせる事が出来る XUL Runner ってランタイムもある事だし、ランタイムの信頼性を考慮しても研究開発レベルで取り組んでも面白いと思うんだけど。
Web アプリの場合、インターフェースがデスクトップアプリと違ったりする事で、ユーザにストレスを与えたりする。それを解決する１つの方法として XUL は有望かなって気がしてる。強制オープンソースってのにちょっと不安はあるけど、PHP の エンコーダみたいなプチバイナリ化は可能だと思う。
なんにしても、自分にとって JavaScript がコア技術だってのは間違いないのかな。
プロジェクト規模でのアジャイルを初体験。早速洗礼。
アジャイルに慣れてないというか、プロジェクト規模でアジャイル開発するのは初体験。で、マイルストーンを置く段階から戸惑いというか迷子状態。開発に必要なタスクは設計担当者とリーダーが持っていたんだけど、それに関わらずにいたので全体がよくわからなかったりした。で、ざっくりなタスクというか作るべき機能を提示されて、その優先度みたいなのをフロントさんと営業さん(開発から見たカスタマ)に聞いていた。カスタマ側(と自分)はこれまでのウォーターフォールに慣れてたせいで、なんだか？？？な感じ。ミーティング後の社長のお言葉でみんな納得顔。「アジャイルでやってこうってのと関係ある？」。その辺ですれ違がってたって事です。
アジャイルはよくわからないんだけど、要は長期のかっちりしたスケジュールは作らないで機能単位で実装＆レビューを繰り返していこうっていうスタンスなんだと思う。なので、まず実物を早く見たいようなものがあるならそれを教えてもらって、そこから取りかかる。１つのイテレーションが回ってる間に、色々と事情が変わったりする事を想定して無駄なリスケジュールをさけるというか、スケジュールを組み直す事自体から解放されようとする。
なんとなくアジャイルに抵抗感を持つ人たちの気持ちがわかった気がする。そういう人たちと未熟者の自分の感想を同じにしちゃいけないとは思うけど、不安感があるのは確かだと思う。やるべき事が最初に明確になってると、自分の役割がはっきりするから安心感がある。そこで、開発を進めながらやる事を決めていくようなスタイルに急に切り替わると、どうしても戸惑う。自分がアジャイルを理解してないからだとは思うんだけど、こいつは厄介。
アジャイルに興味はあるし、アジャイルを知った時に受けた感じからするといい感じの進め方だとは思う。以前、簡単なレクチャーを受けてはいたんだけど、プロジェクト規模でのアジャイルは初めてなので、これから実際に体験して体に覚えさせるしかないと思う。
そんな混乱に満ちたミーディング。ついつい、場をさらに混乱させるような発言をしてしまったり。プロジェクトのマネージメントって大変だなぁ。
# リーダー！改めて「アジャイル勉強会」お願いします！緊急度高めで！…、と月曜にでもぼやいてみようかな。
てめぇ、トラバッくれてんじゃねぇぞ、こら。
あぁ？知るかよ。タグんぞ、こら。
意外にごろがいいなと思いつつぼやいてみたり。Google で調べると結構使われてる(?)っぽい。出るとこ出たらこんな感じで口喧嘩してたりするのかな？
特定のRSS/Atomフィードへのアクセスは多くても30分毎程度にとどめてください。特定のプログラムからご利用の場合などは、クライアント側でのキャッシュなどもご考慮ください。
機能変更、お知らせなど - はてなブックマーク日記 - 自動巡回ツールやRSS/Atomフィード取得に関する注意書きについて
軽く冷や汗…。お気に入りのおもちゃだったはてながついに怒った。「ヤクルトは１人１本までよ！」と。
色々と自分の都合のためにいじくってたけど、反省。一応、Blog に貼付ける場合とかはキャッシュしてたし、ローカルに取り込む場合もそれほど頻度は多くなかったりしたと思う。UA も URL とメールアドレスつけてるし。最低限のマナーは守ってきたつもり。ただ、ローカルでのテストの際はかなり負荷をかけたかも。sleep を１秒かけたところで、やっぱ迷惑行為だったかも。
ただ、なんで今んだろうって気もする。ここ最近サーバの調子が悪い感じだったけど、API 公開したらそうなるのは分かりきってるし結構前から兆候はあったんじゃないの？サーバに関してはさっぱりだから何とも言えないんだけど(会社の状況見てかなり大変なお仕事だってのは実感してます)。やっぱ、ネットワークエンジニアさんは貴重なんだな。
何でも出来るスーパープログラマさんは尊敬できるけど、それってほんの一握りの人たちしかなれないと思ってる。Web 開発で、プログラム技術とネットワーク技術は切り離せないものだってのは分かるけど、業務レベルで万全を期そうと考えた場合専門家を置いた方が都合がよさそう。
はてな批判じゃないです。さりげなく自分の状況に対して言い訳してるだけです。サーバわけわからん。
ブログ専門のアクセス解析サービス「Measure Map」がGoogle傘下に (MYCOM PC WEB) 個人的に大ショック。
Google Analytics みたいに無料で使えるなら、ユーザーとしては嬉しいんだけど一応似た業界で働いている身としては結構ショック。これで Feedburner まで飲み込まれるなんて事になったら…。Feed 生成とその効果測定には興味ないよね？
Feedpath に乗り換えてみようかなぁと試してる最中に、サーバダウンとか。
まあ、β版だから仕方がないんだろう。おとなしく、正式版になるまでは Bloglines 使うかな。Feedpath は使い方がいまいち分からない。100 件以上のアイテムがたまった時にどうやって 101 件目以降を見たらいいのかすら分からない。タグで分類したフィードのアイテムをまとめて見れるのはいいんだけど、重複したまま表示されるのが嫌。これは他のリーダーでもそうなのかもしれないけど、まとめ読みの場合は Perlmalink でまとめちゃっていいと思う。
心配なのは、偶然出会った backtrace の画面。普通にフィードを読んでたら突然エラー画面が表示されて、ずらずらと backtrace メッセージが…。いいのか？デバッグしたいんでしょうけど、客に見せるような情報じゃないでしょう。しかも、DB エラーだから余計な心配をしてしまったり。確実にホストアドレスとDB 名、ユーザ名とかは見れる。しばらく客側の接続切ればいいのに。βだってのが売りなんだろうし…。
フィードアグリゲーションサービスを提供する場合、相当なサーバリソースがないと現実的じゃない。実際、Bloglines が実例を見せてくれた訳だし。こうなると、やっぱ Bloglines から乗り換える理由は完全になくなるなぁ。
ちゃんとした機能として提供されてるかもしれないけど、とりあえず自作。
はてなブックマークの /entrylist では URL を指定してその階層以下のエントリーに対する被ブックマーク情報が得られる。で、そこから得られる RSS を利用して、どんなタグがつけられてきたかを軽く一覧にして見てみる。
とりあえず、思いつきなだけなのでデバッグ的コード(PHP5 and PEAR::HTTP_Request)。
<?php
require_once("HTTP/Request.php");
/** check argument **/
if ($argc != 2) {
die("Usage: php get_recent_tags.ph <SITE URL>\n");
}
if (!preg_match("/^https?/", $argv[1])) {
die("Enable protocols are http or https.\n");
}
/** get feed **/
$http = new HTTP_Request();
$http->addHeader("User-Agent", "www.koshigoe.sakura.ne.jp");
$http->setURL("http://b.hatena.ne.jp/entrylist?mode=rss&sort=eid&threshold=5&url=" . urlencode($argv[1]));
$result = $http->sendRequest();
if (PEAR::isError($result)) {
die($result->getMessage() . "\n");
}
$content = $http->getResponseBody();
/** parse feed **/
$parser = simplexml_load_string($content);
$tags = array();
foreach ($parser->item as $item) {
$dc = $item->children('http://purl.org/dc/elements/1.1/');
foreach ($dc->subject as $subject) {
$tag = mb_convert_encoding(trim((string)$subject), "euc-jp", "utf-8");
$tags[md5($tag)] = $tag;
}
}
/** dump **/
var_dump(array_values($tags));
?>
CLI での利用。引数に調べたいサイト URL を与えると、そこ以下のエントリーに対してつけられたタグが得られる。RSS は 最近 50 件で取得してるので、ここみたいにあまりブックマークされてないとこの URL じゃないと使えないので注意。
なんでこんなもん作ったかって言うと、サイトの概要を掴むためにタグのリスト見たら分かりやすかったりするのかなという勝手なイメージから。例えば、はてなブックマークの注目記事からタグでフィルタする際に、お気に入りサイトでのタグられ具合をみてフィルタに採用してみるとか。
後は、SBS での最近の人気タグとか見てフィルタタグの候補をリストアップとかしたらいいのかな？
タグをつけられたりカテゴリー(ディレクトリ)で分類できるサービスはたくさんある。
分類機能は標準で、それがタグなのかディレクトリなのかはまあいい。で、Bloglines に登録してたフィードを Feedpath に登録してた時に思ったのが、フィードってざっくり分類で十分だなという事。基本的に新着記事を全部読む派なので、どう分類してあったところで意味がない。むしろショートカットキーだったりクリック操作が増える分邪魔になる。どういう目的で集めてどんな情報なのかがざっくり分かればいいという事で、Feedpath でつけたタグは全て Tech。今のところ１つしかつけられないっぽいけど、今のインターフェースならそれでいいと思う。というか、タグである意味はあまり感じられない。
RSS リーダーの場合、フィードの属性をタグで表す分類と、購読時のまとめ読み属性を表す分類の２つが必要な気がしてきた。ようは、検索目的で必要になるメタデータと、購読する時に必要なメタデータって違うんじゃねえのってこと。情報をたくさんつけなきゃいけないのはうざいかもしれないけど、この程度ならインターフェースの設計次第でどうにでもなりそう。
あれか、タグと別にボックスみたいな名前でまとめたらいいのかな？メールの受信箱とかみたくさ。あれ？これは Feedpath のインターフェースに対する感想か…？いや、Rojo もそうだった気がする。んー、まあ頑張ってください、と。
byteMyCode - Online code snippet repository.
code snippets と呼ばれる特定処理を行うコードを登録し、それについてタグをつけたりして共有していくポータルサイトらしい。タグは今のところ言語レベルだったり、String や Validate といった対象や目的を表すものが利用されている模様。
今日初めて知ったんだけど、いつ頃開始だったんだろう。機能的には snippets 投稿とタグ付け、ブックマーク、用語定義(?)とか。オープンソースの検索エンジンがある事は知ってるけど、使った事がない。何を基準に探していいかいまいち分からないし、ちょっとした処理は Google で探した方が早い気がしてる。具体的に何を探すのかが決まってたり、コードを読みたい時には便利なんだろうけど。で、byteMyCode は結構分かりやすくて面白そう。確実に処理(機能)レベルでコードが集まるし、それぞれに概要がくっついてる訳だから多分見やすくて分かりやすい。
早速、Bloglines に RSS を登録したんだけど、なんだか調子が悪い。Bloglines が悪いのか、byteMyCode の RSS が悪いのか分からないけど、どうなんだろう。まあ、今のところ数が少ないから十分見て回れるけど、今後充実してくる事を期待すると、更新を RSS で受け取りたい。Bloglines の "500 Internal Server Error" はやっぱ "Validation Error"なのかな？ログインしないと駄目とか？そろそろまた新しい RSS リーダー探そうかな。Web 型のリーダーはもう頭打ちな感じだけど…。Feedpath とか？
byteMyCode は何となく気軽にコードを書ける気がする。自分用の "knowledge base"っぽく使ってもいい気がするし。もちろん、著作権というか誰かが書いたコードを丸コピーとかはまずいだろうけど。まあ、どこまでオープンにできるかっていう線引きが難しいかな。CPAN とか PEAR、JSAN みたいに「言語コミュニティ公認！」みたいなライブラリとしての登録は敷居が高いけど、関数レベルで日曜プログラマ感が出せるのはいい感じ。
もうちょっと触ってみて判断しないとね。
みごとなまでにチンピラ兄さんにからまれた。
通勤途中の電車で、込んでいる中をドア側に移動していたら突然足を蹴り上げられた。どうやら、足があたった(蹴った？)らしく、それにご立腹だった模様。気づかずにそのまま行こうとしたのが悪かったらしく、振り向き様の胸ぐらロック。なんだかんだと怒られて、出ました「オモテ出ろ、こら！」。ここでヒーロー登場。「ひとごろしー！」。優しげなおじさんが勇気を振り絞って言ってくれました。ちんぴらさんはびっくり。あっという間に、おじさんとちんぴらさんとの口喧嘩。置いていかれて寂しかったので、仲裁役として参加。
バレンタインに逆電車男。エルメス気分かぁ。嬉しくない！
カテゴリーのRSSを作る。
@smate.NET: カテゴリ別 RSS 作成
少々古い記事だったので、MT3.2 とは多少違いが合ったものの基本的にそのまま。
というわけで、カテゴリーごとのRSSを出してみた。カテゴリーアーカイブのページ上部にさりげなくおいてあります。
どうにも長ったらしいカテゴリーリストが気に入らないので、整理。
まず、どうやらサブカテゴリーはいらないようなので削除。合わせていくつかのカテゴリー名を変更。それから、サイドメニューとして列挙表示すると結局長ったらしくなるので、エントリー表示側にタグクラウド表示する。これは以前試しで作ったものを一部修正しただけ。
以前のカテゴリークラウドでは XML を MT テンプレートを利用して作って、それを XMLHttpRequest で読み込んで…ってやってたんだけど、別に XML する必要はなかった。同じドメインだし、JSON っぽいテンプレートで js ファイルをつくって、<script>タグから読み込めばいい。CSS は Perl の HTML::TagCloud が吐き出すものを利用。
なんというか、自分には MT が向いてない気がしてきた。MT じゃなきゃいけない理由も見つからないし、固定的な分類方法もいらついて仕方がない。かといって、wiki ってのも微妙。tDiary とかがいいのかな？分類を自動的にしてくれて、Emacs から投稿できるツール。ついでに、吐き出すフィードも分類できると嬉しかったり。それと、分類を一括で処理できるツールがついてるとさらに嬉しい。
カテゴリを整理してて思ったのは、カテゴリを無くすと困るけど、ブログ自体にどういう情報があるのかっていう検討がつく情報があれば代用できるなってこと。エントリーごとにメタデータくっつけておいて、それを収集して整形したものをトップページあたりに貼付けられればそれでいい気がする。そういう意味で、trackword はいい感じ。実際に求められた検索語(記事のメタデータ)を列挙する訳で、つまりこのブログに何が書かれているかが分かりやすい。ついでに、trackword 経由のトラフィックも結構いい割合。調べてないけど、集積データを加工できるならそれで代用してカテゴリ撤去が出来るかも。
MT でメモってのはやっぱ微妙だなぁ。
先日購入した Happy Hacking Keyboard。かなりの強敵。
もの自体がどうこうじゃないんだけど、101 とか 102 とかの英語キーボードが初めてなせいで、かなりてこずる。刻印を見ながらでもそれなりにうまく移行できるかと思ってたんだけど、大間違い。プログラムを書く上で、半ば癖になってる文字列を囲むダブルクォーテーションとか、括弧、代入の際のイコールとかが厄介。手の動きが染み付いてるから、そういう場面の時に勝手にキーを叩いてしまう。そうすると、実際にうたれる文字が見当違いだからたちが悪い。削除して刻印見直して数度の間違いを経て修正完了。なんとも厄介な強敵だ。
キーの配置自体は結構いいかもと思う。実際、代入(=)は Shift いらずだしクォーテーション文字とかコロンとかが手近(右小指)にあるのはコーディングに相性がいいのかもしれない。ただ、やっぱり癖になってる動作を強制するのは苦労しそう。
頑張れオレ。
Happy Hacking Keyboard が到着。
紆余曲折を経て、何事もなかったように今朝到着。早速 Mac につないでみる。Mac 用に スイッチを切り替えて Command キーが使えるようにして、斜面刻印の一部キーを有効にするためにドライバをインストール。
株式会社PFU | Happy Hacking Keyboard)。
101 キーボードを使うのは初めてなので結構とまどいがあるけど、まあそれは慣れでしょう。キータッチは Apple 純正と比べるとスカスカ。Apple 純正で好きだったのが「かなキー」と「英数キー」なんだけど、HHKB ではことえりショートカットか Emacs キーバインディングを使わないといけない。Emacs の方はなんだかかなと英数が混ざる感じが合ったり、別のキーバインディングが無効になったりするのでことえりショートカットに慣れないと。ついつい癖でかなキー押そうとして横長のスペースキーを押してしまったりして混乱。
とりあえず、しばらく使って遊んでみる。
Happy Hacking Keyboard の配送予定が昨日。
昨日は早めに会社を出たにもかかわらず、途中のコンビニでぐずってしまいニアミス。20-21時の間の配送で、見事に20:00に来やがった。
今日はもっと早めに会社を出て電車乗り継ぎもスムーズに、寄り道せずに帰宅。…、朝 08:20 に来てやがった。20時と8時を間違えてやがる。
こっちのミスかと思ったけど、返信メールでちゃんと20-21時って書いてあるし、備考欄にも20:30〜21:00でお願いしますって書いたはず。つまり、備考欄なんかまったく無視されてる、と。まあ、それはしょうがない。配送の順番とかで前後するだろうし。ただ、20と8は間違えちゃ駄目だろうよ。
なんだかんだで、休日の朝に起こされての受け取りになりそうだ。
時間指定なんて信用できないってのはわかってたんだけどさ…。
お天気Webサービス仕様 - Weather Hacks - livedoor 天気情報
以前、天気予報は業界のなんちゃらがどうこうで…ってな記事を見てあきらめてたんだけど、こうして Web Service として実装されてちょっとびっくり。
でっかいところで技術力があると、企画とか折衝とか実現力とかがやっぱ違うのかな、と。Sledge にしても、提供サービスでの API 実装、安定したサーバ運用とか、根っこのところの部分で見せられる技術力ってのは凄いんだなぁと改めて実感したり。
一般ユーザ向けのサービスではパクリだ後だしだと、色々言われたり個人的にも思うところはあるんだけど、"技術力(実現力)"って部分では素直に尊敬。入りたいとは思わないし、相手にされるとも思ってないんだけど、技術集団として割と別働隊っぽく動いてくれると好きになれるかも。
そんなわけで、また１つおもちゃが増えた事を喜ぼう。
プロレスラーが大仁田議員を告訴へ - nikkansports.com > 社会ニュース
普通に自分のアドレスが From の迷惑メールとかくるんだけど…。携帯に自分のアドレスからメールがきた時は、ぷち呪怨。From って有効なの？サーバの経路とかは有効だと思うけど、ヘッダに記載される情報って自分で書けるよね？見る人が見れば分かるんだろうけど、少なくとも From だけでどうこう言うのは難しい気がする。
XULRunner - MDC
XML でポン。
ホスティング系(?)のブログとかでは基本的に JS が使えない。これはまあ当たり前の処置。色々と解決策は(難しいにしても)あるのかもしれないけど、共有スペースである以上危険は出来るだけさけるべき。
とはいえ、色々と遊びたいのも事実で、世に出回る Widget を試してみたいってのはよくある。問題は、JS をそのまま使わせると(JS で出来る事は)何でも出来てしまうという点。じゃあ、"何でも"っていう所が解決できればいい訳だ。個人的に１つの答えだと思うのが、XML 形式の Widget。
気になるのは、Google Module とか Dashboard は 大枠では XML なんだけど、実際は JS で書かれてる事。監視体制とかが整えば、それでも検閲する機会があるわけだからそれなりに安全ではあるんだけど、危険でもある。JS ベースで機能の実装を開発者に任せる方法は、開発者が既知の技術を使える分、簡単で楽しかったりする。それが理由で活発化したりするから、JS を使うなとは言えないけど。
それなりの機能を(自由に)実装しようとしたら、どうしてもプログラミング(スクリプト)言語を使う必要がある。ただ、ブロブパーツみたいにちょこちょことしたものを作る場合、ある程度機能を制限しても問題ない気がする。
というわけで、はてなダイアリーも XML 書いて実装できる Widget 作ってください。もしくは、CPAN Author がこんもりいらっしゃるようなので、"はてなぱん"とか作ってダイアリーモジュールのディレクトリサービスを始めください。
まあ、冗談はいいとして、そんなこんなで XUL Runner が気になってきたので XUL を勉強してみようかな、と。
軽く概要を眺めた程度なので、詳細は分からず。Wiki 記法で書かれたテキストをXHTML/RTF/LaTeXとかに変換するためのパッケージっぽい。
XHTMLとかっていうフォーマット種類が指定されている理由がよくわからないんだけど、多分ルール書いたり拡張したりすれば、色々なフォーマットに対応させる事は出来ると思う。関連ツールをパッケージ化してベース(フレームワーク)を作るのが目的っぽいし。
これをうまく使えば、PukiWiki<->DokuWiki みたいな変換が出来るようになるのかな？まあ相変わらずプラグインがどうこうってのは残るけど、その辺はうまく代替表現とかSCMとかの衝突みたいな表現で強調してやればいい訳だし。
もうちょっと見てみて面白そうならいじってみたい。
株式会社PFU | Happy Hacking Keyboard
"Happy Kacking Keyboard"っていう名前に惹かれて注文してしまった。
これまで購入したキーボード全てが買える位の値段だったけど、何も気にせず注文。今週の木曜には届くらしい。Emacs を使うようになって一番かわったのは、カーソルキーを使わなくなった事と、Control キーを常時使うようになったこと。自宅では Apple 純正のキーボードを使っているので、Control キーは最初から A キーの左にある。ので、特に違和感なく押す事は出来る。会社の Win でもキー配置を入れ替えて同様の環境を作った。問題は、指が短いからか使い方を間違えているからか、C-b がキツい事。今日危うく手首が腱鞘炎になりかけた。Control を左小指で、b を左人差し指ってのは間違いなきがしてきた。キータイピングは(当たり前かもだけど)かなり自己流で、何が正しいとかは知らない。届けば問題ないと思うし、ひとそれぞれやり方はあると思う。どこかのビルさんはオール人差し指だって話だし。
とりあえず、Apple 純正の清々しいまでの汚れやすさと、やたらかくかくした感じのキータッチから解放される日が間近。小型キーボードなだけに、リターンキーから右側にはキーがない。ファンクションキーとカーソル周り、テンンキーが省略されてる。OSX の場合、Eject とかボリュームコントロールが結構気に入ってたりするんだけど、その辺も多分 Fn+どれかで対応できるっぽい(キーの手前側面に刻印がある)。C-b での腱鞘炎危機はどうなるかわからないけど、両手を使うように強制してなんとか我慢するしかない気がする。少なくとも会社で購入をお願いするわけにはいかないし、手持ちのキーボードで頑張るしかない。実際、どんなキーボードがいいとかっていう確たる主張がある訳じゃないし。まあ、この使い心地次第ではごねるかもしれないけど。ただ、見合うだけの成果をあげないとだし、多分黙ってるのが正解な気がする。
実は年末あたりにリリースされるって言う噂の Optimus Keyboard(?) を狙っていたりもする。今回購入のキーボードがさほど効果がないようなら、楽しさ追求で乗り換えるでしょう。多分、また値段気にせず即購入。３ボタンのやつもちょっと欲しい気もするけど、どうかな？小型キーボードになったらスペースが空くし、そこ埋めるのにいいかも！…、欲しくなってきた。
理由があって支持されているっぽい、Happy Hacking Keyboard を使い続けたらそれなりに"出来る人"っぽく見てもらえるかな？
# 102(101?)な配列は気合いでカバー。完全にHTMLベースのブログと違って、独自の記法を持つ Wiki では結構難しいらしい。
インポート／エクスポート自体に対応した Wiki はあるらしい。PukiWiki ではいくつかの形式からインポートできたりエクスポートできたりする模様。ただ、Wiki は相当な数があるから、全てに対応している訳じゃないしそれを目指すのも現実的じゃない。ある標準的な記法にエクスポートして、それをインポートするようなやり方なら可能かもしれないけど。
何も考えずに dokuwiki を利用してる訳だけど、ここのデータを別の Wiki に持っていく場合、手作業でごりごりやるしかないのかな？プラグインとかを考えると、たいした量じゃない場合は手作業の方がいいのかも。自分の Wiki で書いてきた事はごちゃごちゃしてるから、それを整理する意味でも有効かも。
Wiki って実はまだまだ一般的じゃないのかな？自分が使って仕事でも使ってるから、結構標準的なツールだっていう意識を持っちゃってる事に気づいた。ブログにしろ Wiki にしろ一般的に考えるとまだ目新しいものなのかも。tDiary が Wiki なのかは分からないけど、それ意外だとさほど使われてないのか。手打ち HTML だったり、オーサリングツール使って好きにデザインするって人が主流だ。
Wiki を使う場合は、愛着を持って何か機能が欲しくなったら自力で作ってみんなでハッピーになろうっていう気概が必要なのかも。
どうも StatWatch が表示する数字が信用できない。
中身をいじくったせいだと思うんだけど、最近の数字がうさんくさい。どうもうまくリセットできてない気がする。ここのアクセス数はだいたい１日100アクセスくらいなんだけど、ここ最近の StatWatch は 200 を超えた数字を表示している。時間がおかしいのは多分ロケールあたりがおかしくなってるんだろうからいいとして、日々のリセットがうまくいってないのかなと思う。
とりわけ大事な数字って訳じゃないし、嘘でも数字が増えてるのは嬉しいから放置。DB をいじくったりしたせいかな？
以前 MT の XML-RPC の練習に del.icio.us の１日分のポストを MT にポストするスクリプトを書いて、今も利用している訳だけどこれがどうも日付がおかしい事に気づく。で、以前は date で引っ張ってきてた関係でとりあえず gmdate を使ってたんだけど、なんだか変だったので tag に日付タグを指定して強引に引っ張ってくるように修正した。そこで、日付タグを作る部分がそのまま gmdate だったために２日前のポストを引っ張ってきていたらしい。
公開しておきながら無責任なんだけど、以前公開したスクリプト自体は修正なし。運用上の問題だし、元々そのまま使ってもらうために公開した訳じゃない。PHP で XML-RPC を使うためのサンプルになればとというのが目的。実際使ってる人がいるかは相変わらず分からないんだけど。
Emacs 用の hatena-mode を利用してメモをはてなダイアリーに書き留めておく。
Emacs にもだいぶ慣れてきて、***-mode が楽しくて仕方がない。会社の技術 wiki も pukiwiki-mode で編集して、会社のでは失敗したけど自宅に環境作って hiki-mode を試してみたり。このMTも mapae を利用してポストしてる。で、hatena-mode も少し試したんだけど、はてなダイアリーは使うために無理矢理ネタ(スポーツとかテレビとか)を作ってたから１月とか簡単にさぼる事になる。なので、Emacs+hatena-mode って組み合わせから ChangeLog っぽい使い方ではてなダイアリーを使っていこう、と。hatena-mode はバックアップも撮ってくれるから手元にも情報が残るし。
元々、メモ環境を作ろうと hiki とか pukiwiki とか tDiary とかのを Emacs が対応してる wiki クローンを試してたんだけど、いまいち凍結とかがわからなくて挫折。とりあえず、はてながさくさくできそうなのではてなに決定。サーバをレンタルしてる都合上、データを移動させる必要性が出てくるかもしれないし、Web サービスの方が良さそうな気もする。バックアップは自動で出来るし(複数環境に散在するけど)。
今利用している『書き留める』系ツールは以下の通り。
ScrapBook は SBM でいいやと思って使ってこなかったけど、チートシート的な手元に置いておきたい情報を切り抜くのに結構便利でお気に入り。
クリーンインストールの影響で、Stufflt Expanderがなくなってた。
とりあえず、入れ直せばいいやって事でフリーソフトの紹介サイトとかから行こうと思ったんだけど、これがリンク切れっぽくて駄目。ことごとくハズレなので、Google先生に"Stufflt Expander"で聞いてみた。トップの方にくる"Stufflt Official Site"がすでにおかしな事になってる。で、act2って方を選ぶとなんとかたどり着く事が出来た。
どうやら、stufflt.act2.co.jpが応答しなくなっていて、www.act2.co.jpからたどると行けるらしい。
Feedburner.jpを使い始めたので、StatWatchも.jpに対応させてみる。
StatWatch自体も1.2にバージョンがあがっていたので、これをアップデートしてみる。MTプラグインなので、そのまま上書き。見た目がちょっと修正されてる模様。1.1では"Top Pages This Week"に空欄が表示されたりしてたけど、1.2ではそこらはfixされたっぽい。
見た目はいいけど、フィードレポートの"Subscribers"が表示されてないのはなんでだ？.comから.jpにかえたからっぽいし、.jp用のAPIに対応させないといけないのでソースを見てみる。
表示制御は、lib/StatWatch.pmのgetFeedStatsメソッドから返ってくる"has_feed"っていうフラグが鍵らしい。で、has_feedを1(ON)にするにはBLOGトップのHTMLヘッダからlink要素を探して、そのhref属性値の先頭28文字が"http://feed.feedburner.com/"とイコールでないといけないらしい。なので、先頭27文字が"http://feeds.feedburner.jp/"とイコールになったらという条件に変更。それで、その下の方にawarenessAPIのURLが書かれていて、それも.com用なので.jpに変更。とりあえず、これだけ修正して再度StatWatchのレポート画面にアクセス。無事、表示される事を確認。StatWatchはC.C.らしいので、手元のソースを修正するだけなら問題はないよね…？
ここで、修正とかバージョンアップとかする前に確認して疑問だったのが、.jpにあるawarenessAPIのドキュメントが.comのものを和訳しただけだった事。.jpにして出力される事が確認できたから、多分.jpに置き換えればいいんだろうけど、ちょっと混乱。
--- StatWatch.pm.orig 2005-11-09 06:27:54.000000000 +0900
+++ StatWatch.pm 2006-02-04 01:20:32.000000000 +0900
@@ -513,7 +513,7 @@
for my $link (@{ $blog_response->headers->{link} }) {
my @link_bits = split(/;/,$link);
chop(my $url = substr($link_bits[0],1));
- if (substr($url,0,28) eq "http://feeds.feedburner.com/") {
+ if (substr($url,0,27) eq "http://feeds.feedburner.jp/") {
$feed_url = $url;
last;
}
@@ -522,7 +522,7 @@
my ($feed_subscribers,$feed_subscribers_bg,$has_feed,$feed_average,$feed_permit);
if ($feed_url) {
my $feed_dates = usableDate("feedburner");
- my $feed_average_request = HTTP::Request->new(GET => "http://api.feedburner.com/awareness/1.0/GetFeedData?uri=$feed_url&dates=$feed_dates");
+ my $feed_average_request = HTTP::Request->new(GET => "http://api.feedburner.jp/awareness/1.0/GetFeedData?uri=$feed_url&dates=$feed_dates");
my $feed_average_response = $user_agent->request($feed_average_request);
use XML::Simple;
自宅のOSXで軽くだけどSubversionを使い始めている。
基本的にEmacsのvc-svnかTrac、svnXからの利用だけで、CUIだとか概念だとかはよくわかってない。なので、分かりやすく説明してもらって勉強になった。基本的なところが分かってなくて、branchとtagの概念を運用で実現するって所を知らないままSubversionを使ってたのがショック。
Subversionでtrunk/branch/tagっていうCVS的な運用をする場合、(プロジェクトの)リポジトリをディレクトリで分割して擬似的に実現するらしい。プロジェクトfooがあるとして、foo/truckとfoo/branchesとfoo/tagsみたいにディレクトリを分けて、それぞれにtrunkからコピーする形で運用していくとbranchとかtagとかが実現できる、と。実際の運用にはsvn switchとかsvn mergeとか細かいところは色々あるらしいんだけど、そこはちゃんとしたドキュメントを参照。
ドキュメントをろくに読まないまま使い始めたのが悪いんだけど、今までのものはどうしよう。svn moveとかでどうにかなるのかな？基本的に疑似branchだったり疑似tagだったりする訳だから問題ないとは思うんだけど。
six olq: Movable Type:: Emacs フロントエンド「mapae」
直前のエントリで無事ポストできる事を確認。
*scratch*バッファはデフォルトだとメッセージが表示されてる。ここまで使ってきて何かを表示しておく必要性は感じていないので、これを消す。
(setq initial-scratch-message "")
OSXのTerminalでsvn diffすると文字化けする。
エンコーディングの設定を間違えてる気はするんだけど、svnのエンコーディングにTerminalのエンコーディングを合わせてもファイル自体のエンコーディングがsvnのものと違うと結局化ける。
これまでdiffとかコミットログはTracから見てたから気にしてなかったんだけど、psvn.elを使ってみた時にやたら化けるので気になってきた。改めてTracから見てみるとエンコーディングの差を吸収してくれてる。
diffはsvnからの出力を直接見るものではないのかな？まあ、日本語を使わなければ問題ないからソースには日本語を書くなってことなのかも。
Terminalで見る必然性はなかったりするし、Tracの色分けがきれいだからTrac使い続ければいいのかな。
# vc-svn.elで複数ファイルを一括コミットするのはどうすりゃいいんだ？
学生の頃、階乗計算を行う再帰関数をC言語で書かされた。
「どんどん階層を下っていって、底にたどり着いたら遡って計算して帰ってくる」とかいった説明を受けた気がする。if文使って最後を判定してreturnで1とか返してた気がするなぁ、とか思い出しながら適当な関数を再帰処理で実装してみた。
/**
* 前月以前 $num ヶ月分の日数を再帰計算
*
* @param Integer $num 過去 $num ヶ月
* @return Integer 過去 $num ヶ月の日数
*/
function getDaysOfPastMonths($num) {
if ($num == 0) {
return 0;
} else {
return date("t", mktime(0, 0, 0, date("m")-$num, 1, date("Y"))) + getDaysOfPastMonths($num-1);
}
}
当月を含まない過去Nヶ月の日数を計算してみる。今月の３ヶ月前なら、31(１月)＋31(12月)＋30(11月)=92日。ループで計算できるし、効率がどうっていうとこまで理解できてないから、これでどうって事は言えない。とりあえず、なんでもかんでもループで回してた気がするので、これを機会に再帰処理を使ってこうかな、と。今回の実装が正しい再帰処理になってるのか微妙だけど、動くしいいかなと。ちなみに上記コードはPHP。
php-modeは色づけとか補完とかマニュアルへのショーとカットに対応している。
よくよく考えてみると、どうやら構文チェックは対応していない模様。"php -l"で構文チェックはできる訳だし、どっかにあるはずだとさまよっているとあった。
Editors emacs - PHP Wiki
ここに掲載されているコードを.emacsに追加するだけでOK。
Lucky bag::blog: Firefox のサイドバーを強化する機能拡張
All-In-One Sidebar :: Sidebar Extension for Mozilla Firefox
なんだか面白そうなのをもう１つ見つけてしまった。これは分割はできないみたいだけど、色々と出来るみたい。サイドバーに(今見てる)Webページを表示できるから、ブログ書いたりするときにいいかも。別の拡張で解決できるのかもしれないけど、色々いじれそうでちょっと期待。
んー、とりあえずSidebar Mixがシンプルで分かりやすい気がするし、とりあえずこれは後回しかな。
# そういえば、拡張機能は『無効』に出来るんだよね。前に勘違いした記事書いた気がする…。
先のエントリーの通りしばらくSidebar Mixを使ってタブ付き分割サイドバー機能を堪能してみようと試行錯誤中。
で、Sidebar Mixにパネルを追加するにはchrom://形式でXULのパスを指定しないといけない。
Chrome Protocol Links - The Extensions Mirror
Dev : Firefox Chrome URLs - MozillaZine Knowledge Base
こんな感じで公開されてるのもあるんだけど、ScrapBookは見当たらなかった。で、どうやって探したらいいんだろうと適当に試してみたらできちゃったり。
Firefox でサイドバーの機能を分割表示する拡張『Sidebar Mix』＠あの頃のように…
先のエントリーでも掲載したこのページにヒントが合った。"chrome://パッケージ名/content/XULファイル名"である程度はいけるっぽい。OSXの場合Firefoxの拡張は、"~/Library/Application Support/Firefox/Profiles/プロファイル名/extensions"以下に置かれる。パッケージディレクトリの下にあるchrome/にjarファイルがあるので、それを適当なところにコピーして展開する。
% jar xvf パッケージのjarファイル名
ScrapBookのjarファイルを展開すると、"content/scrapbook/scrapbook.xul"があるので、どうもこれっぽいと当たりを付けて"chrome://content/scrapbook/scrapbook.xul"で試してみる。…、駄目だ。参考にしたページを見る限り、"chrome://パッケージ名/content/XULファイル名"なにおいがするので、"chrome://scrapbook/content/scrapbook.xul"で試してみる。…、おお。出来た。
1.3 - The Chrome URL :: XUL Planetとか見たらChromeURLがどういう規則で組み立てられてるか分かるのかな？とりあえず、こんな感じでちょこちょこいじってみよう。
Sidebar Mix
Firefox でサイドバーの機能を分割表示する拡張『Sidebar Mix』＠あの頃のように…
自宅のMacのディスプレイはは22か23インチのChinemaDisplay。Mac購入を決めた頃にFlashとかPhotoshopをよく触ってて、パネルを開いたときの窮屈具合に我慢できなくなったので思い切って購入。すばらしく快適なPCライフが送れている。PCはそこそこのスペックがあればよくて、大事なのはインターフェース。
せっかくの大画面だけど、基本的に全画面表示はしない。FlashだとかPhotoshopだとかを触らなくなったせいもあるけど、基本的にテキスト表示の場合横幅1900はやりすぎ。適当なところで折り返してくれないと、読みにくくてしょうがない。ウェブコンテンツとかでCSSとかテーブルでレイアウトがちゃんとしてればいいけど、結構いいかげんだったりする。
そんなわけで、Firefoxを1000くらいでEmacs(エディタ)を800くらいな感じで横並びにしてたりする。後はブラウザの背後にTerminal。画面が大きいので、複数アプリケーションを並べて使えるのがいい。
で、ちょっと気が変わってきてたりする。仮想デスクトップをまた試そうかなぁと。開発作業してると、変種作業(Editor)と変更反映(Terminalでrsync)と確認作業(WebBrouser)な流れが基本になる。で、TerminalとFirefoxが重なってなんとなく面倒な感じがする。どうせ並べられないなら、仮想デスクトップ用意して作業ごとに画面自体を分けてみようかな、と。
ただ、Firefoxを全画面表示するには抵抗がある。けど、仮想デスクトップ使うなら１画面１ブラウザでいっとけとも思う。そうすると、何かで余分なスペースを埋める必要があるんだけど、まず思いつくのはサイドバー。元々ブックマークは常に開いてたんだけど、色々便利なサイドバーを試してみたいし横並びとかで表示できると嬉しい。
前置きが長ったらしいんだけど、要はSidebar Mixを利用して複数サイドバーで無駄なスペースを有効活用しようじゃないか、と。
# 無駄な贅沢万歳。
