トップ «前の日(12-03) 最新 次の日(12-05)» 追記

2004-12-04

_ マージーでーーーーー

米IBM、パソコン部門を中国大手に売却か、米紙報道

デスクトップ型からノート型まで全範囲のパソコン部門を、中国のパソコン・メーカー最大手に売却する方向で交渉していることが3日分かった。

ThinkPad が、ThinkPad がーーーーーーっ。(はいここムスカ風で)

orz orz orz orz orz orz orz orz orz orz

ThinkPad は残してください。お願いします(T_T) あの作り、あのサポートは IBM でなければ実現できませんて。プロの弁当道具箱、ThinkPad は家電メーカーの作る雑魚とは違うのだよ。雑魚とは!

販売価格の安さではない市場価値を持つ製品、メーカーは多くありません。IBM にはその舞台から下りてほしくないなぁ。Apple じゃダメなんですよ。なぜなら Apple はユーザーの声を本当に真剣には聞かないから。Apple ユーザーはそれを分かって使っているけど、やっぱそれは健全な姿じゃない。IBM のビジネスに対する姿勢こそが大事にされるべきだと思うのです。

Tags: Tool News

_ RSS はメールに似ている?

ふと思いついたネタ。ちゃんと書けるかどうか分からないけどとりあえず見出しを置いておく。

ネタ元は textfile.org 経由で「BulknewsとRSSの現在・未来」CNET Japan の楳田blog のゲスト、Bulknews の宮川さん。

Tags: Tool Net

_ referer のカット

Referer リクエストヘッダの除去

つーことは。結局 local の Wiki からたどりましたよーという referer をカットしようと思ったら透過proxy 立てるのがベストってことですね。

Tags: Tool Web

_ IQサプリ

伊東四朗はきらいじゃないが、深夜のときの香林坊出身篠井英介さんの方が好きだった。

まーそれはともかくマッチ棒クイズってマジカル頭脳パワー思い出しますね。ダメですか。オヤジですか。うっさいわ。

Tags: TV 日々

_ メッセンジャー

  • プラットフォームを選ばず
  • ファイル転送可
  • 特定のベンダーに囲い込まれない

そんなメッセンジャーないかな。MacOS Classic まで含むのでメッセンジャ−を諦めて irc ってのがいちばんだとは思うんだけど。

なんか前にもこんなこと書いたような気がするな。

Tags: Tool Net

2006-12-04

_ Creole とな

Creole: Home

via

いよいよ本家と言えそうなところで Wiki 記法の標準化を検討し始めているっぽい。

でも。個人的にはこの手のプロジェクトではいい成果が出そうにない気配をいつも感じている。もちろん標準案が完成したらそれはとてもいい成果だろう。でもそれが Web 向けの構造化テキストの標準として本当に「いいもの」になるかどうか、どうにも疑問なのだ。

現段階でもいきなり bold を <strong> で、italic を <em> で実現しようとしているところが気になって仕方がない。bold の <strong> はまぁいいとしよう。でも italic は <em> とは限らないはずだ。たまたま HTML ブラウザのデフォルトスタイルで <em> が italic になっているだけで、italic の意味するところが <em> であるというわけではない。この二つはイコールではなくて意味的には一方通行のはずである。italic が <em> を意味しないとは言わない。しかし <em> とは限らないだろう。

どうせ HTML への変換を前提に考えているんだから、最初から obsolete な italic や bold という要素を入れなければいいのになぁ。それとも物理マークアップ推奨派の人が多いのか? それはそれで合点がいくんだけど。bold や italic は文脈に応じてこういう意味になるという慣用があるので、それに従えばよいという考え方もなくはないと思うし、論理マークアップ前提にするとどうしても記法が増えてしまうので、シンプルに保つという意味では物理マークアップの方が都合がよい。

でもだったらそのものずばりの物理マークアップを推奨してくれた方がよほど潔いと思うんだよな。というかこれはあれか、Wiki 記法ではなく XHTML の方を問題にすべきなのか? でも XHTML の考え方も理解できるしなぁ。

Wiki 記法がメール上での利用など、HTML 以外のシーンも考慮する気があるのであれば物理マークアップ推奨はアリ、考慮する気がないのであれば HTML の思想に従うべき、とここではいったん単純化してみることにしよう。

で、それとは別に、個人的には引用と注の記法はぜひ考えてほしい。普通に文章書くときにはこれこそ大事だと思うんだけど、あんまり Wiki 界の人(って誰)は必要性感じてないのかな?

Tags: Wiki Text

2007-12-04

_ DQ4終了、10年来の恨みを晴らす

DQ4 やってたんすよ、ドラクエ、ドラクエ。

※ 以下ネタバレあり、注意

いやー実は以前ファミコンでやったときにね、取り忘れてたんですよ、つのぶえ。人の話をちゃんと聞いてなかったらしくて、最後の戦いでめっちゃ苦労したんです。いれかえできないから。Lv42 くらいまで鍛えたように記憶しています。

で、解いちゃってから当時流行ってた4コマでそのアイテムの存在を知ったんですよ。

えぇぇえぇぇえぇ! つのぶえって何!!

と思ったけどあとの祭り。さすがにやり直す気力はない。

あれから10年以上経ち、DS で再挑戦。やっと想定された通りの解き方ができました。なんて強力なんだ、スクルトとフバーハのコンボ。

しかしリメイク版の本当の苦しみはその後にありました。第6章の意味が分からねぇ。なんか知らんけど時間がちょっと戻っててナニしたらいいのか分からない。まぁまた人の話聞いてなかっただけかもしれないけど。なんかすれちがい通信に使う町を思いっきり整備したらいいんだ!と勘違いしてせっせと頑張るも無駄。タネが分かってからは延々と同じ戦闘のくり返し。ひどい。もう少しストーリー作ってくれたってよかったじゃないか。まぁハッピーエンドはハッピーエンドなんだけどさ。ハッピーエンドっぷりは本編よりもステキ。ドラクエは FF のようには救えない感がないところが好きだな、やっぱり。

Tags: 日々

2008-12-04

_ AutoPagerize をイントラアプリで

AutoPagerize を常用するようになってから初めて CodeRepos の Trac を見に行って気づいた。

何もせずに changeset を遡れる!

AutoPagerize のメリットは理解していたつもりだったけど、今回がいちばん感動した。なんでかなと思ったんだけど、普段 AutoPagerize の対象になるページは

  • ニュースサイトの分割記事(最近これ多すぎ)
  • 検索結果一覧

くらいで、実はこの二つは AutoPagerize がなくてもある程度の分量の情報を一目で確認できる。

しかし changeset の場合は極端な話、ほとんど情報量のない changeset が途中で混ざっていたりする*1ので、一つずつめくらなければいけない状態が結構ストレスだったようだ。自覚はなかったけど、AutoPagerize が利いたときの驚きのでかさがそれを示している。なるほど、これが「ゼロクリックにする革命」なわけだ。

ということで早速イントラの Trac でも AutoPagerize が利くようにしたいなと思ったんだけど、ここで二つ問題が。

  • イントラアプリの SITEINFO を Wedata に上げるわけにはいかない
  • かといって localhost の AutoPagerize を書き換える方法では恩恵に預かれるのは自分一人。喜びを分かち合うことができない。

そこで今回はイントラ内に HTTP で JSON を提供してくれる場所を用意することにした。これなら最初の一回は AutoPagerize の書き換えが必要だけど、以降は SITEINFO を追加していくとどんどん対応アプリを増やすことができる。

イントラの HTTP で JSON を serve

うちの場合、Subversion を WebDAV で運用しているので、Web サーバ周りで特にやることはない。具体的な方法は

JSON を Subversion リポジトリに突っ込んでその URL を AutoPagerize に教えてやるだけ

コード上では

var SITEINFO_IMPORT_URLS = [
   'http://wedata.net/databases/AutoPagerize/items.json',
]

にイントラの JSON の URL を書き足してやればオーケー。

JSON ファイルを作る

SITEINFO を作るにはまず最初

var SITEINFO = [
  {
     url: ,
     nextLink,
     pageElement,
     exampleUrl
  }
]

を書き換えていく。この過程は Wedata に上げる場合と一緒。

Wedata に上げる場合はこのままできあがったものをコピペするだけでよい。AutoPagerize では JSON を受け取ってパースするが、先ほどコピペしたデータを Wedata 側で JSON にして提供してくれるので Wedata に上げる場合は単なるコピペでよいのだ。

しかしイントラ JSON の場合は

自分で Wedata 形式に合わせて JSON にエンコードしてやる必要がある

ここだけが違う。

まず Wedata からどういうフォーマットでデータが来ているのか確認。この間 作ったもので見てみるとこんな感じ。

{
  "name": "i\u30bf\u30a6\u30f3\u30da\u30fc\u30b8 (Lite)",
  "updated_at": "2008-11-29T21:33:09+09:00",
  "database_resource_url": "http:\/\/wedata.net\/databases\/AutoPagerize",
  "created_by": "wtnabe",
  "resource_url": "http:\/\/wedata.net\/items\/25850",
  "data": {
    "pageElement": "\/\/table[descendant::hr][position() > 1]",
    "url": "^http:\/\/(?:www\\.)?itp\\.ne\\.jp\/servlet\/jp\\.ne\\.itp ...",
    "nextLink": "\/\/a[text() = \"\u6b21\u3000\u30da\u30fc\u30b8\"]",
    "exampleUrl": "http:\/\/itp.ne.jp\/servlet\/jp.ne.itp.sear.SKWSVmai ..."
  },
  "created_at": "2008-11-28T11:18:17+09:00"
}

ということは

{
  "data": {
    "pageElement": "",
    "url": "",
    "nextLink": "",
    "exampleUrl": ""
  }
}

があればいいんだな。全体としては

[
  {
    "data": {
      "pageElement": "",
      "url": "",
      "nextLink": "",
      "exampleUrl": ""
    }
  },
  {
    "data": {
      "pageElement": "",
      "url": "",
      "nextLink": "",
      "exampleUrl": ""
    }
  },
  ...
]

こんな感じになる。

JSON は意外なほどきっちりしていて、key も文字列でなければいけないとか文字列は " で囲む必要があったりするんだけど、そういうのはいちいち自分で気にするのはばからしいので、完成したら適当なツールを使ってエンコードするとよい。

自分の場合は AutoPagerize 内に直接書いた SITEINFO を別ファイルに書き出して、Ruby なり PHP なりでエンコードして、それを先ほどの JSON ファイルの方にコピペしている。

イントラ AutoPagerize、これは便利。

ちなみに Trac の SITEINFO は 0.10 系と 0.11 系で異なる。CodeRepos はこの段階で 0.11 系でイントラのものは 0.10 系だったので丸ごとコピペしただけでは動かなかった。

Tags: Firefox

*1 typo を直したとか


2009-12-04

_ RubyGems自体のアップデート

なんとなく作業してたけどまとめたことがなかったので自分用まとめ。

いつのバージョンからかは知らないんだけど、少なくとも RubyGems 1.3 時代は

$ gem install rubygems_update
$ update_rubygems

で RubyGems 自体のアップデートを行っていく。Windows の場合どうなるんだろうと思ったら

C:\Ruby\bin\update_rubygems.bat

がインストールされていたので、基本的には Ruby のインストールディレクトリに入るのかな? コードもマニュアルも読まずに書いてるけど。

一部で流行りの ~/.gems? 方式でどうするのかは分からない。