後方互換性を意識するというお話

そろそろ金曜日の天使の元ネタが増えても良いのになーと思ってるyappoです。転職した先でブログ書かないんでしょうか。

あーもーイチから作ったがええんかなぁ・・・。HTTP::EngineもStandaloneがPlackのおかげでremoveされるし。てーかモジュールを簡単にリムーブしてくれるなと・・・。よくみんなついていくよな、こんな事に。

とか好き放題言われてるようなんで一言いっておくと、まったくの嘘っぱちでHTTP::Engine::Interface::Standaloneまだ削除されてませんね。

世のおーぷんなんちゃらな感じでライブラリとかを出してる人は、誰しもが自分のプロダクトの後方互換性くらい意識してるでしょう。
HTTP::Engineだって例外ではありません。Plack/PSGIが熱いだとかいっていて開発するリソースが減ったとしても、一度世の中に出て使われてる以上は採用した人が困らないようにバグを潰すなり何なりでメンテナンスするべきです。
出来ないのなら変わりの人をみつけるか諦めるのも自由なんですが。

まぁ、そんな訳でHTTP::Engineなんかは黙々とバグ潰しをしてたり、raw_bodyがメモリ馬鹿食いしてうざいよねって時には、既存の挙動を壊さないように新たなオプションを豆乳してたりします。after PSGIでも。

まぁ、2年ぶりくらいにCPAN関連のモジュールをアップデートしてはまったとかでいうんなら御愁傷様です。まぁそれで困るような所でいきなりupgradeしてはまるとかそういう事はあり得ないと思ってますが。
とも思ったけど

Plack、::Server::*が全部DEPRECATEDになった。ひでぇなぁ・・・。Impl -> Server -> Handler。すばらしくどーでも良いリファクタだこと。表層の名前をぽこぽこ変える神経がすげぇよ・・・。

らしいので良くわかりませんね。
そもそも Plack::Handler になるのって正式リリースまえのDEVELOPER RELEASEなのに何を言っているんでしょうか。僕には理解出来ません。

という事で、ただでさえ後方互換性を意識してても酷い事言われるので、みなさんしっかり後方互換性を意識しましょうねというおとぎ話でした。

.codeという新sTLDをICANNに提案するのはどうか

航空業界のsTLDがあるんだからプログラムコードの為のsTLDだってあったって良いじゃない。
git clone git://remedie.code/ とか出来たらカッコいいっしょ！
.code sTLDが提案されてるのか調べてないけど、なんかあったら使うプロジェクトいっぱいありそうだよねー

Shibuya.PM tech talk #10 の申し込み間に合わなかった人への提案とust時代の勉強会の関わり方

昨夜に募集開始されたShibuya.PM tech talk #10ですが、夜に募集開始したのにも関わらず3時間足らずで定員オーバーとなりました。
wassrとか等を見ると行きたいけど間に合わないよーという話もチラホラでてます。

そこで提案なのですが折角ネット中継されるので「Shibuya Perl Mongersテクニカルトーク#10 パブリックビューイング」という催しを同時開催するのはどうでしょうか?
ustで見れるから会場に来なくてもいい。という話ではなく、やはり現地にきたら現地に来たなりの何かが得られるので、というか一人で見るよりも同じ目的の人間が集まってワイワイ見た方がたのしいじゃんすか。
定員で参加出来なくて「現地で得られるもの」的な収穫は半減するかもしれないけど、そういったパブリックビューイング的な会場に数人数十人集まれば得る物は出てくると思うんですよね。
会場次第では現地と違ってわいわい酒飲みながら見れるし、一人で見るのと比べると懇談会まで開催出来ちゃう！

勉強会といっても地理的条件やら会場のキャパシティやらで参加希望者全員が参加出来るなんて事は稀なので、こういった形で勉強会をスケールアウトして行くと現地の開催者の人手的な負担もかけずに規模を拡大出来そうです。
パブリックビューイング会場が増えれば各拠点でust配信してustreamer的な何かで全拠点の映像を出してプロジェクターで出力したり、発表の質問とかも会場ごとに出したりと双方向的な何かもできるかもですね。

僕は発表するので参加出来ないですが、誰か「Shibuya Perl Mongersテクニカルトーク#10 パブリックビューイング」やらないか？もちろんどこかしらの会社さんの会議室等を利用する感じになるでしょうが。。。

ustじゃやだやだやだという人は前夜祭的な日程で開催されるHECon #1に是非お越し下さい。発表枠もまだまだあるよ！

追記：早速賛同してくれる方々が現れましたよ！
大阪:Shibuya.pm ustream中継 新大阪サテライト会場 - 葉っぱ日記
京都:Shibuya Perl Mongersテクニカルトーク#10 京都サテライト開場のご案内 - antipop
札幌:?
恵比寿:?

git.coderepos.org 作る計画

CodeReposにgitリポジトリ追加するよ！
予定は7月後半くらいまでにやる予定なんだけども、まだgit使ってないからどうしたら良いか悩み中です。
それなのでブクマコメントとかで意見とかみんな書いてくれると嬉しいです。

おもな概要は、既存のsvnリポジトリやtracの環境は今まで通り残す。
新規に git リポジトリを上げて、gitweb?か何かでブラウジング。
svn と git の間では sync しませんが、もしなんか良いツールがあれば使うのもあり(ちゃんと動けば)
htpasswdはgitもsvnも共有(できるよね?)。

こんな感じです。ご意見よろしゅうお願いします。

あ、あと7月前半にcoderepos.orgのサーバ引っ越しするかもです。

git.coderepos.org 作る計画

CodeReposにgitリポジトリ追加するよ！
予定は7月後半くらいまでにやる予定なんだけども、まだgit使ってないからどうしたら良いか悩み中です。
それなのでブクマコメントとかで意見とかみんな書いてくれると嬉しいです。

おもな概要は、既存のsvnリポジトリやtracの環境は今まで通り残す。
新規に git リポジトリを上げて、gitweb?か何かでブラウジング。
svn と git の間では sync しませんが、もしなんか良いツールがあれば使うのもあり(ちゃんと動けば)
htpasswdはgitもsvnも共有(できるよね?)。

こんな感じです。ご意見よろしゅうお願いします。

あ、あと7月前半にcoderepos.orgのサーバ引っ越しするかもです。

CodeReposにうpする事は恐くないよ

ユーザ避けとしてのSubversion - blog.fuktommy.comのミラー

だから早いうちからソースを公開するのはいいことだと思うんですけど、 問題もあるんですよね。 ソースはできるだけ早くから公開したいんですけど、 実際にユーザが使うのは「ひととおりできあがった」あとにしてほしいんです。 早くから使われると、当然完成度も低いですし、 仕様の変更だってちょくちょくあるから、 「完成度は低いし、バージョンアップのたびに互換性なくなるし、つかえねー」 という評判が立ってしまう。

これは二つの問題を混ぜて考えてしまっている。

ソースを公開する=将来のユーザになる層に告知するという考え方がまず間違っています。
そりゃ2chとかでスレ立ててやっちゃえば、混ぜこぜになっちゃうのもしょうがないかもしれないすけど、ひげぽんとかの成功例もあるからプロジェクトの切り盛り次第かも。

って話が脱線したけど、CodeReposにコードを上げる事は恐い事ではありません。
まず、CodeReposに作りかけのコードを上げた程度じゃ将来のユーザーは気づく事が出来ません。黙ってcommitする分には、commit logを追いかけまくってる人くらいしか気づかないので問題ありません。
作りかけのコードを上げて、最終的な利用者に使われて評判を落としたくなければ、アナウンスしなければいいんですよ。
じゃぁ、どうやって仲間を見つけるかって?
commitしたらlogに残るから、それみて面白そうなら蟻のごとく皆たかって来るし#codereposにでもさらっと流せばlog追いかけてない開発出来る人とかが気にしてくれるかもしれない。
その程度で最初はコツコツやってけば良いんですよ。最初はスルーされてたけど自分一人で頑張ってるうちに他人から見ても面白い物に進化してたら集まって来るしね。
そしたらあっと言う間に完成度が上がって、勝手に広報してくれる人も出て来るよ。mobircのようにね。

この辺りの他人の評価を気にしすぎるのが日本人の短所でも長所でもあるけど公開されなきゃ存在しないと同じなんだから、たかだか最初の評価気にする程度で出さないのはとても損な事だと思うのですね。
もちろん戦略的に出していく事に関しては、各人の自由なわけでめちゃくちゃ尊重しまくるのは当然なのですが、今回はうpしずらい理由がちっちゃい事なら、そんなの気にせずコミットちゃえよ！you！って感じです。

まあ、そういうわけだから、id:naoyaとid:jkondoには是が非でもhtpasswdを送って欲しいし、未完成な状態でもいいからサントゥニーを klab の仙石さんははやくCodeReposにcommitしてほしいということでした。

そして、オレも作りかけにも満たないTemplate::Classをコミットしたよ！

Wiiリモコンのリコールの件

まだコメントが醒めない今日この頃ですが、任天堂から「Ｗｉｉリモコン」のストラップについてのお願いというのが出ましたね。

つきましては、お客様に安心してご使用いただくためにも、より強度のある１mmの「ひも」でのプレイをしていただきたく、お手数をお掛けしますが、お持ちのストラップをご確認いただき、0.6mmの「ひも」の場合は、下記のとおり交換(無償)の手続きをお取りいただきますようお願い申しあげます。

ふむふむ、0.6mmだったから、切れたのか！1mmを送ってもらえば良いんだね！
説明ページの写真はみわけ付きにくいしWii本体とか手元にないからノギスで計ってみました。
信頼のおけるブロガーなのに、信じてくれない人も少数居たので様々な角度から写真取りましたよ！



どうみても1mmの紐です。本当にありがとうございました。

1mmの紐が切れた人にはサポート無しですか？
Wii用のストラップじゃないと、ちゃんと手首に固定してくんなくて危険で遊べない！

---

J-PHONE Vodafone Softbank から続く業者に付き合うのをやめようキャンペーン

jsky vodafone live Yahooケータイと会社が買われる度にサービス名が変わったりブランドが変わって
これらの上でコンテンツを作る人たちは毎度毎度対応していかなければならない今日この頃いかがお過ごしでしょうか。

例えばCPANのHTTP::MobileAgent::JPhone

package HTTP::MobileAgent::JPhone;


use strict;

use vars qw($VERSION);

$VERSION = 0.18;

use base qw(HTTP::MobileAgent::Vodafone);

1;

Vodafoneを継承しているだけです。
たぶん、H::UA::VodafenもYahooを継承する様になるでしょう。
激しくBKです。

3度ある事は4度、5度あるはずなので自衛策を考えてみませんか？
そこで良い事を思いつきました。

例の会社が身売りしてもブランド名変わっても、変わる事の無い統一した名前をつければ良いのではないかと！
その名も ThirdForce!
メアドも @thirdforce.ne.jp でやっとけば、身売りしてもユーザーに迷惑かけませんよ！
各種言語のモジュールもThirdForceで統一です。

これはすばらしいアイディアです。

Google Maps APIはAjax使ってないのね

よくよく考えれば当然なのですが、Google Maps ApiはAjaxを使ってないんですよね。
動的にGoogleへの通信を行ってる箇所もありますが、多分iframeを使って表示エリアの情報を送ってるだけっぽい。レスポンスデータが0バイトだし。

そりゃドメイン違うから使えるわけなかったか。。。

で、Google Maps APIとAjaxってキーワードがセットで使われる事があるけど
Google Maps APIの実装がAjaxで成り立っている訳ではなく、Google Maps APIを利用しているサイトがAjaxを使ってサイト独自のデータを動的に取得しているだけ
なのですね。

だから、Google MapsとかGoogle LocalはAjaxを使ってます。
Google Maps API単体ではAjaxは使ってません。
となるのでFA?

ホントはサービス提供者側はサービス利用者に対して、Ajaxなんて単語を意識させちゃだめなんですけどね。
でも、時勢でグリグリ動く系のサイトは全てAjaxと呼ばれる症候群。

という、何を今更というメモですた。

新しいYahoo!で"Search Word Cloud"を検索してみた

初日だから引っかからないだろうとおもって検索して三田ですよ。
googleには引っかからなかったけど、Y!はどうだろうと思ったら引っかかって田ですよ。

"Search Word Cloud"で

よくよく見たら

1. RssRolling
RssRolling. (You can always get) what you want. [ YappoLogs ] ... [ YappoLogs ] Search Word Cloud うまい説明が思い浮かばないのですが javascriptファイルをページに貼り付けておくだけで、そのペ ...
naoya.dyndns.org/~naoya/rssrolling - 172k - 2005年10月4日 - キャッシュ - このサイト内で検索

RssRollingは、更新頻度高いからすぐにindex更新が早いのはわかるけど
なんで、10月4日？
US時間？

謎が多いYSTですた。

　　　　　　ﾊﾞｶ　　　　ｺﾞﾙｧ 　　　　　　　　　　　　　　　　　　　　　　　　　ﾌﾟﾝﾌﾟﾝ 　　　　ヽ(`Д´)ﾉ　ヽ(`Д´)ﾉ　　(`Д´)ﾉ　　　 （　`Д） 　　　　|￣￣￣|─|￣￣￣|─|￣￣￣|─□（ ヽ┐U ～ ～　￣◎￣　　.￣◎￣　　￣◎￣　　 ◎－>┘◎

検索会議行きます

検索会議第三弾 『Yahoo! HACKS』会議、お申込開始！
って、開始２時間以内に定員オーバーだしｗ

自分はエントリできたけどエントリできなかった人に
「月曜日はY!シャツきてきて！」
いわれたけど、どうせならはてなシャツのがｳｹ狙えそうだからほすぃ

#今回のおみあげのボリュームはどんなもんだろ

はてなキーワードからリンクを消すBookmarklet作った

はてなのページからコピペするときにキーワードリンクが激しくうざかったので勢いで作った。
今も反省しない。
Greasemonkey版は本家でも紹介されてたけどなんとなく再発明
IE限定だと思います。

Bookmarklet

追記:ちゃんとした実装がすでにありましたorzhttp://www.hatena.ne.jp/info/bookmarklet

さようなら xxx 2.0　こんにちわ xxx 3.0

YAMDAS現更新履歴 ついカッとなってまとめてしまった。「2.0」ならなんでもよかった

さて、これまで当方は何度も「なんちゃら 2.0」の氾濫に警鐘を鳴らしてきたが（ウソ）、これまで単発的に取り上げてきたものを中心にざっとまとめてみた。大体、公開時期が古い順。現在火だるま状態なのだが、ちょっと逃避したくなったもので……

というわけで2.0な物は徐々に増えているらしい。
世間的には来年あたりから2.0が注目されるかも知れませんが、2.0が出回る前に3.0なんてのが出るのが定石だと思われるので
こんな3.0がくる？ってのをリストアップしよう。

・Web 3.0

デバイス毎でのパーソナライズに対応、HTTPのプロトコルも新しく

・Where 3.0

落し物検索や迷子検索などの、プライバシーに配慮しつつもリアルオブジェクトとの連携など

・Who 3.0 (SNS 3.0)

顔面認証システムにより名前を度忘れしても、久しぶりに会った人の情報が瞬時に分かる技術など

・spam 3.0

世界中の携帯電話がspam wareに悩まされる、携帯業界が大変なことに

・Search 3.0

あ、次は5.0か

・JavaScript 3.0

なぜかwindow.statusが再評価される

・folksonomy 3.0

folksonomy 3.0 is folksonomy of real world.

・The INTERNET 3.0

惑星間データ転送に対応かも

・IP 3.0

V6は？てか、（略

・hatena 3.0

はてなラボトリーを開設、海中式サーバを開発して巨万の富を得る

・blogWatcher 3.0

なんでも評判検索が搭載されるはず

・GREE Night 3.0

今度は東京ドームでしょ

・Pair programming 3.0

衣食住を共にして、阿吽の呼吸でプログラムを行う手法が注目される

・CEO 3.0

マッチョ系CEOが注目される

うーん・・・肩こった・・・・・

ACCで垣間見た はてなブックマークの効果

そんなこんなのACCですが
実は先週の土曜日から公開していて、ある種の実験をしていたのですよね。
はてなブックマークに自演ブックマークしただけで、どんだけ人が見に来るのかな？と
エントリ数は
はてなブックマーク(51)
del.icio.us(13)
となっとります。1470.netのほうにも数件あるぽいです。
で、13:52分現在

[today:74 | total:2404 counter by File::CounterSS]

となっているので、トップページPVが賞味6日で2400件になることが出来た、という事がわかります。
これもネタしだいなんでしょうけどね。
告知方法がこれだけなのにそこそこのトラフィックが集まってるので、スパマーにばれたら大変なことになりそうね。

なので頑張ってください、はてなの中の人。
色々防御手法はあるし、めんどいけど既存の抜け道とか塞げばよいはず。

綾瀬メソッド

高橋、もんた、miyagawaに続く新しいメソッドが登場

綾瀬

メソッド

もんたメソッドネタにトラックバックしてくださったSensitiveさん経由で発見した

まずは、綾瀬メソッドのプレゼンをご覧頂こう。

( ﾟ∀ﾟ)彡 _ ( ﾟ∀ﾟ) ⊂彡 _ ∩ ( ﾟ∀ﾟ)彡 _ ( ﾟ∀ﾟ) ⊂彡 _ ∩ ( ﾟ∀ﾟ)彡 _ (ﾟ∀ﾟ) ⊂彡 _ ∩ ( ﾟ∀ﾟ)彡 _ ( ﾟ∀ﾟ) ⊂彡 _ ∩ ( ﾟ∀ﾟ)彡 _ ( ﾟ∀ﾟ) ⊂彡 _ ∩ (ﾟ∀ﾟ)彡 _ ( ﾟ∀ﾟ) ⊂彡 _ ∩ ( ﾟ∀ﾟ)彡 _ ( ﾟ∀ﾟ) ⊂彡 _ ∩ ( ﾟ∀ﾟ)彡

deliciousったのは秘密

901iS - たまには携帯の話

800MHzのデンパがゆんゆん。SH901iCで無残に切断されたアンテナの配線だけが空しい。
テレビ電話切り替え機能。未だにテレビ電話の使い方が分からない人が多いので、電話で説明しながらテレビ電話に移行できる。docomoの中の人はよくがんばった！

次にN901iS。逆境に耐えよく頑張った！感動した！
早く利用動向を見極めて定額制対応になって欲しいですな。
世の中の流れに負けた感じになってるけど、フルブラウザ搭載は素直に喜ばしい。
フルブラウザ⇔既存ブラウザとのシームレスな連携が取れないと、携帯端末にフルブラウザ入れる意味無いけど連携できるようになってるのかな。

本命のPDF。
Flash以上に良い機能拡張ではないでしょうか。
いまやiアプリは太りすぎて死んでいるわけで、ちょっとした物でc-htmlで表現しきれない事をやりたい時に超有用です。
読み物コンテンツや、日記などに雰囲気を出すためにPDF化した情報を提供するとかグリーティングメールとかが即効で出てくるのかな。
他にも、検索系、コミュニティ、EC、などへの活用事例が沢山出来そうです。
Flashだと仕様の制限があって応用範囲が狭かったのですが、PDFなら制限作ることも無いだろうから期待です。
携帯ブラウザもそろそろJavaScriptに対応してもいいんじゃないのかしら？

http://www.nttdocomo.co.jp/p_s/imode/make/pdf/index.html　【はい、お願いします。】

そんな物よりもm1000クレクレクレ

XMLHTTPRequest memo

http://antipop.zapto.org/mt/archives/001242.php
http://www.xml.com/pub/a/2005/02/09/xml-http-request.html
http://jibbering.com/2002/4/httprequest.html

JavaScriptだけでHTTP通信してXMLを取得してDOMったりする物。
どっちにしろサーバにリクエストを投げるのは一緒だったりするので
無理してこれを使ったところで、クライアントに負担掛けちゃって良くない事も多そう。

うまくXMLHTTPをはめ込めるところが無いか考えてみよ。

Blog版ORDBの技術仕様編

Blog版ORDBが実行に移るのか？より

俺らのほうも手が空いたら実はやろうかと思ってたんすが、やるならできる範囲でですが協力しますよ。
一度どういうの考えてるのか聞いて見たいな。

という事で、少し考えてみた。
運用に関しては、棚に上げてしまって仕様っぽいものを。

各Blogからブラックリストを取得するプロトコルはORDBとかと同じDNSでいいかなと思います。
DNSを利用する事で、各ツールに新たなプロトコルを実装する必要が無くなるため
導入も簡単になると思います。

具体的にどのような情報をブラックリストに含めるかというと
ホスト名とURLに絞ったブラックリストが必要なのかなと思うので以下のように分けます。

1.ホスト名

host.bl.example.jpのサブドメンとして、ホスト名を記入


http://spam.example.com/をブラックリスト対象にする時

spam.example.com.host.bl.example.jp

http://*.example.net/をブラックリスト対象にする時

*.example.com.host.bl.example.jp

2.URL

url.bl.example.jpのサブドメンとして、ホスト名を記入


http://example.com/spam/以下をブラックリスト対象にする時

example.com/spam/を符号化する.url.bl.example.jp

こんな感じのホスト名をDNSにAレコードとして登録しておきます。
Blogツール側でhttp://example.org/spamer/がブラックリスト登録されている場合は
調べたいブラックリストの内容に応じたホスト名に変換してDNSにてAレコード検索します。

たとえば192.168.0.1(問題ありそう)が帰ってきたらブラックリストサイトと分かるようにするとかですね。
戻ってくるIPアドレスの内容で悪質度が分かるようにするのもいいですね。

ただ、このままだとブラックリストに登録されていない情報を検索する時に大変な事になるので

*.url.bl.example.jp    IN A 192.168.0.254

*.host.bl.example.jp    IN A 192.168.0.254

という感じのレコードをゾーンファイルに記入して、ブラックリスト未登録のホストは192.168.0.254を返すようにします。

DNSにする利点としては、

ごくごく基本的なプロトコルで導入がしやすい

手間をかけずに広域分散データベースとして利用できる

耐障害性・高可用性

こんな感じなので、システムが仕上がってきたらセカンダリサーバを
ライブドア、ニフティ、はてななどなどなどのプロバイダさんに設置してもらって
効果的な負荷分散も可能になると思われます。

しっかりしたスパム対策をするには、プロバイダ含め色々な層の方々による
ボランティアが必須でしょうな。
システムなんかよりも運営（人）が一番大変。

あのエントリを書いてから気が付いたのですが、MT-BlacklistなんていうPluginが既にあったりしたですね。

MTでのトラックバックスパム対策
updateping spam とBlog版ORDB

MTでのトラックバックスパム対策

ついにトラックバックスパムが大量に来るようになってきた。
コメントスパム以上にありえない量をspamって来るので、暫定的に対処してみた。

MT2.661でやってみました。

mt-tb.cgiの

use strict;

がある行の直下に

use CGI qw(:standard);

my $data = param('url');

if ($data) {

  my $datas = "$data";

  die if $datas =~ /chat\-nett\.com/;

  die if $datas =~ /terashells\.com/;

}

を追加してみました。

  die if $datas =~ /chat\-nett\.com/;

  die if $datas =~ /terashells\.com/;

の部分は、しつこいspamサイトのURLに変更してやってください。

updateping spam とBlog版ORDBのトラックバックバージョンも必要になってきそうな今日この頃。
Six Apartの実装と、ORDBサービス運営母体が出来ないと何も始まらないのか・・・
いや、MT用のORDBモジュール作っちゃえばいいのか。

運用的には、嫌がらせでブラックリストに載せられちゃう件の対策しないといけないのか。
むしろexcerptに日本語無ければ弾く対策でいいじゃんって思うかもだけど
日本語圏以外の人々も困ってるだろうし、せっかくだから日本人以外の人も活用できるといいもんね。

FOMA対応のiアプリなXML-RPCクライアント配布開始しました

せっかくFOMAを買ったというのとSUNLOOPさんから、FOMA用に画像サイズを拡張して欲しいとの要望もあったので、大きな画像送信が出来るクライアントも公開しました。
70×70から252×308へと画像サイズが大きくなりました。

内容的には、前回公開したものと変わっていません。
FOMAだから、動画も送信できるといいんですけど、5秒くらいの動画しかアップできないかもしれないので保留中。

以前のエントリにて質問要望がありましたので、この場を借りて回答など。
Toyoaki's PCさん

3.11だけかもしれないけど、カテゴリの設定が主カテゴリではなく副カテゴリとして登録されちゃいます．．．主カテゴリ空っぽ(^_^;)。

まだ、3.11で試してないですが早いうちにFixします。

Konpeki Blogさん

要望 ＞ 一つの MovableType で複数の Blog を作っている場合、投稿時にそれらを選択できるようにしてもらうと嬉しいです。カテゴリの選択なんかが煩雑になりそうだけど…。
(追記 ＞ えーと、設定変更すれば選択できなくもないんですが、いちいち通信しなきゃいけないので、投稿時に、iアプリ側で切り替えれる方式の方がいいという意味です。)

アプリ起動時の最初の画面にある「設定」→「保存」で、投稿先Blogが選択できるのですが、これじゃだめですか？
現在は、投稿先Blogを決定した後にカテゴリ一覧をXML-RPC使って取得して、アプリ内にカテゴリリストを保存しているので、投稿画面でBlog選択をつけると各Blog毎にカテゴリ管理をする感じになります。

要望 ＞ タイトルや本文の表示部分を携帯の表示領域に合わせて引きのばしてほしい。(SH900iでは編集画面が別なので、問題はないですが。)

その実装方法が見つからなくて。。。

あとpingの件も、ちょっと調べてみます。

ダウンロード先→http://tech.yappo.jp/download/imoblog-foma-alpha.zip

関連：
iアプリなXML-RPCクライアント配布開始しました
iアプリでXML-RPCクライアント作ってみた

JavaScriptで検索

高林さんのBlogにJavaScriptだけでページ内grepするスクリプトが紹介されていた。

JavaScript でインクリメンタル grep 検索

こりゃ、色々な応用が考えられますな。

なんかこう、サーバ/クライアント全部面倒見る方向でないといかんよな。
うん、

モバイルコンテンツ関係の集まり

昨日、とある人と話をしてて「勝手サイトの集まりみたいのって最近無いね」って話が出てきた。
ギガヘルツとかでやってた雰囲気の集まりって確かに最近聞かないので
ケーターイインプレスの中の人とか、ソフトバンクの中の人とかが音頭とったら実現しそうね、と思ってみた。
ビジネスなモバイル交流会はあるけど、普通の人の集まりが無くて寂しい今日この頃。

ふと思ったけど、モバイルコンテンツ関係者に的を絞ったソーシャルネットとか立ち上げたらどうなるんだろう。
どこかで作らないなら作ってみようかな。

iアプリなXML-RPCクライアント配布開始しました

Movable TypeのXML-RPC APIに対応したDoJaなクライアントの一般配布を始めました。
MTコンパチなXML-RPCを実装しているシステムでもきっと使えます。
2ヶ月近く前のネタなんで、すでにどっかで実装されていそうですがせっかく作ったので。

概要としては
サーバ側の変更を行うことなく携帯電話だけでBlogの記事投稿や写真アップロードが出来ます
携帯電話が直接XML-RPCをしゃべるのです。

想定携帯端末は504i以上です。P504iとSO506iCでの動作確認はしています。
きっと503iでも動くはず（投稿記事の文字数は少なくなるけど）

少しだけ手の込んだことは

iアプリの内部文字コードであるUCS-2とUTF-8の文字コード変換処理。

DoJa3.0のアップロードサイズ制限(10k)以内になるようBase64されたJpeg画像を調整する(単なるリサイズ)

XMLの乱暴な解釈
こんな感じです。

XMLの解釈は手抜きなのでMT2.661以外では動作するかは分かりません。
画像ネタもFOMA900iシリーズに特化させれば、もうちょい面白い事が出来そうですが、あいにく900iシリーズが手元に無いので開発できてません。
J-Phone対応もきっと出来るけど、現在端末買う意志無いので当面未定。（って配布の問題が）
AUについては。。。。。。。。。。。。KDDIさんの暖かいご支援待ってます。

Atom API対応については、HTTPヘッダを用いない仕様が出るまでは手が出せません。
Atom対応のみの所は自前でmoblog対応してるはずなので問題ないといえば問題なさそう。

既存のエントリも編集できる機能については、10k制限・端末の文字入力の壁がある中で、PCで書いた文章を満足のいく形で編集が出来るのかが謎なので未実装です。
超気軽に写真付き投稿をするには便利かなとも思っとります。

ざっくりとした事はiアプリでXML-RPCクライアント作ってみたに書いてあります。
その他は、配布ファイルのreadmeに読みにくい文章で記述しています。

ダウンロード先→http://tech.yappo.jp/download/imoblog-alpha.zip

Posted by Yappo at 05:31 | Comments (2) | TrackBack

iアプリでXML-RPCクライアント作ってみた

Movable TypeのXML-RPC APIに対応したDoJaなクライアントを作ってみました。
既に実装されているのだろうと思って探したけどAtomMEっての位しか見当たらなかった。

技術的な要素としては、UTF-8でエンコードされたデータをHTTP通信で行なうと言う所が一つのトピックでした。
iアプリのHTTP通信はSJISを前提としているようなので、無理やりUTF8に対応してみました。
ただ、この方法を使うと既存のJ2MEなXMLパーサが使えないので、力技でXML解析するしかないです。
今現在使用しているAPIは
metaWeblog.newPost
mt.setPostCategories
mt.publishPost
のみです。

一応
blogger.getUsersBlogs
mt.getCategoryList
辺りにも対応する予定です。
rsd.xmlにも対応しておいたほうが良いかな

余力があれば、内蔵のカメラ機能を使いつつ
metaWeblog.newMediaObject
に対応するのもありですね。

よくあるMTのmoblog対応との優位点は、サーバやmtの改造を行なう必要が無い所ですかね。
iアプリが直接XML-RPC使いますから。

もし需要があったら配布するのも考えてみるかも。
でも、blogプロバイダ系の所だと一般ユーザがiアプリの設置出来ないのかもなぁ。
http通信するホストは、iアプリのダウンロード元ホストと同一のホスト名でないといけない。
でも、こんな感じのiアプリ導入したら他社との差別化が出来たりするのかな？
メールで日記書く方が気楽って意見もあるから、そうでもないか。

あ、ATOM APIはDoJaじゃ無理っす。
X-WSSE:　←これはDoJaじゃ吐けない。

Net::MSNメモ

Net::MSNのサンプルを動かしてみた。動いた。
でも「○○がサインインしました」メッセージが表示されない。
というか、サンプルを終了させた後に再度サンプルを実行させてもオンラインにならない。
何でだと思ってMSN.pm調べたら、接続イベント時のMSNコマンドの出力順番間違ってるみたい。
CHGをSYNより先に送ってるからダメっぽい。
と言うか、何か余計なお節介してるコードだな。。。
って事でMSN.pmの該当部分をコメントアウトして

SYN 0
CHG NLN

の順番にコマンドを送ってみた。

おお！うまくいった。

REA メールアドレス スクリーンネームをUTF8にしてurlencodeしたもの
で名前変更も出来るのね。

とりあえず、blogdbで使ってみるかの。

RSS周りの事でお金を作るという事は？

なんとなく社長さんに呼ばれてる気がしたので、なんとなく書いてみる。

blog検索だけではお金を生み出すのはむづかしいでしょうな。
例えば、RSSフィード中に広告を挿入する仕組みが始まっているらしいけど、blog検索の利用者にはマッチしないでしょうしね。
blog検索のみで収益をあげるのか、それ以外の何かで収益を取るのかっていう目標設定にもよるかもしれないですけどね。
blog検索に専念するとしても、本気でblogを検索させるだけで終わらせちゃうのか。とか。
blog検索で出来る先の事を考えてしまうと、単純な広告モデルは出来ないかも。
まぁ、これもblog検索作る人の方向性にもよりけりかな。

どう転んでも、株主さんをどう説得するかって言うのは各社さんの内情次第ではありますな。
でもまぁ、納得していただけるだけの判断材料は各種取り揃えてるはずですけどね。

あ、blogdb.jp始めるときは、うちのCFO様に納得していただきましたよ。えぇちゃんと;-)
CFO様に納得していただけないと初期投資の資金手に入りませんから。えぇえぇ

weblogUpdates.metapingを提唱してみるテスト

みやがわさんのweblogUpdates.ping の拡張メモをみて。

第4引数にメタデータを入れると言うアイデアは素晴らしいのだけど、単純な更新情報のみを提供しているpingサーバには必要が無い情報なんですよね。
でも、第4引数が欲しいpingサーバもあるので、旨い事出来ないかなとちょっと考えてみた。
いっその事、現状のweblogUpdates.pingはそのまま残して新しいメソッド作っちゃえばいいのかなと思った。

weblogUpdates.metaping(String metadata)

こんな感じで、
metadataの部分は、更新されたエントリのみが含まれたRSSやAtomデータを適当な何かでシリアライズして入れておく。
metadataは出せる情報は全て格納しておく、こうしないと既存のメタファイルを取りに来るサイトも出てきてしまう。

こうしておけばping通知を受け付ける各アグリゲータは、わざわざ通知してきたblogサイトからメタファイルを取ってくる作業が無くなるし
更新された情報のみがネットワーク上に流れるから全体のトラフィックや負荷は減ると思う。

blogツール側ではpingとmetapingの２種類の送信先を管理しなくちゃならなくなるので受け入れられないかもだけど
blog検索エンジンとか、その界隈の人たちにとっては有用じゃないかなぁと思った。

適当な思いつきだけど、どんなもんでしょ。

人工無脳にもホルモンを

現在トレンドな人工無脳の実装方法って、ベイジアンとかマルコフとか使った物が主流っぽいけど
やっぱり文字列以外の入力が無いので自己主張はしにくいんですよね。
ふと思ったんだけど、人工無脳にホルモンを導入したらどうなるんだろうなと。
ドーパミンとか緊張するホルモンとか空腹になるホルモンとか、感情よりもレイヤーが低いものを人工無脳に実装してみるの。
入力文字列に対するホルモンの状態を記憶として持たせておくと自我もどきが実装できるのかなとも思う。

ちなみにひよこには感情モデルが入ってるけど旨く機能してない。
やっぱりもっと単純なホルモンモデルで。