Movable Typeの最近のブログ記事
シックス・アパート株式会社から昨日アナウンスのあったとおり、TypePad上のブログを携帯電話で閲覧できるようにするサーバーソフトウェア、TypeCastが、オープンソースプロジェクトとして公開されました。このソフトウェアを利用すれば、Movable Type上のブログやコメントを、TypeCast経由で携帯から閲覧できるようになるわけです。
。。。携帯か。携帯でブログ。。。あんま読まないな、俺。
それよりMTユーザーに朗報なのは、TypeCastとともに、TypePadで利用している絵文字画像がGPLおよびCCというご自由にお使いくださいライセンスで公開されたことです。ですよね？MTでも絵文字使いたいですよね？
ZIGOROuさんの記事を読んで知った通称SREGを、先日作ったMT 4.1のOpenID 2.0 OPプラグインに実装してみた。requiredとoptionalの違いとか、ユーザーが何を送るかを選ぶ機能とかを実装しないといかんな。
で、テストしようと思ったんだけど、どのRPがSREGを使ってくれるのかわからないので、とりあえずMTの標準のOpenIDコメント機能にもSREG機能を使わせるようにして、myopenid.comでテストして、んでローカルでテストしてみた。とりあえず動いた。
SREG使ってるRPを知ってる人教えてください。
を書いた。
http://code.sixapart.com/trac/mtplugins/browser/trunk/openid2-server
ちょっとまだ迷ってるところがいくつかあるのだが、まあまあ晒してしまえという勢いでコミットしたので、バグだらけでご勘弁。新しいNet::OpenID::Serverのやつも必要です。
で、僕もYappoさんの丁寧な解説とコード、それにid:lopnorさんのコードのおかげで楽できました。ありがとうございます。
http://fastladder.com/
http://lopnor.homeip.net/~danjou/authenopenid/
http://pibb.com/
http://twitwi.tw/
http://limilic.com/
で試したんだけど、pibbはhttpsが必要でこのホスティングに入ってないので、ログイン完了後の画面に遷移できなかった。twitwiはopenid2.local_idに無難なURLを指定すればログインできたけど、指定せずにmt.cgi?__mode=openidみたいなidentityで行くとエラーになった。limilicもログイン完了後のリダイレクトでエラーになった。たぶんこっちのコードが悪いんだろうけど、どこを直すかわからないので誰かが教えてくれるのを気長に待つことにします。
リッチテキストエディタのプラグイン化
Template Set関連API
Atom 1.0 (PP)
XML-RPCでウェブページ関連のAPI追加
MTML as a programming language
くらいかな。
はてなスターをMovable Typeで表示する方法はいろんな人が書いてるけど、やっぱHTMLタグ書くのはMTらしくないだろーってことで、今日のhack-a-thonでMTHatenaStarを書いてみた。
出力するHTMLについては、「さりげないはてなスター」に書いてあったHTMLを丸ごといただきました。ありがとうございます。
使い方
- はてなスターにブログを登録し、トークンを入手する。
- プラグインフォルダにMTHatenaStarフォルダを丸ごと放り込む。
- プラグインの設定画面で、１で取得したトークンを入力し、保存する。
- はてなスターを表示したい場所に<$MTHatenaStar$>を書く。ただし、MTEntriesのコンテキスト内（つまり、MTEntryTitleとかを使える場所）に。
- 再構築（ダイナミックパブリッシングなら不要）。
- はて☆スタ。
はてなスターを表示する場所に<script>タグも一緒に表示されちゃうのがいやなときや、はてなの指示通りに<head>の中に書きたいときは、<$MTHatenaStarScript$>タグを使えば、<script>だけを別途出力できます。ただし、処理の関係で<$MTHatenaStar$>よりは前に置く必要があります。
もちろんダイナミックパブリッシング対応だよ！
Movable Type 4で最初に目にするDashboard。そこにはプラグインでwidgetを追加できるのです。ところで、最近ブログというものの存在を脅かしているTwitter。一言二言ブログに書くのはちょっと重いけど、Twitterならお気楽につぶやける。MTにログインしてみたものの「ブログを書く」ボタンが押せない...。
そんなとき、MT4のダッシュボードから直接Twitterでつぶやけたら便利やね。はいきた、それPlu。今日は木曜日、Six Apart hack day (エンジニアは1日ハックしてていいよの日)。
こちらからどうぞ。あと、作ってる最中にustreamしてたもんで、プラグインを紹介する部分をビデオ撮りしてみた。こちら。
MT4まじ面白いっすよ。
By the way, MT4 RC1 supports moblogging out of the box... for Nokia users. AtomServer in MT4 RC1 includes Nokia Lifeblog protocol support. I have been testing the feature with my own N80 phone and so far it's working for me. Since the feature is experimental, we won't thoroughly test it before MT4 will officially be released. But hey, you can help us test it while you have fun with moblogging with MT4.
There is a known issue - MT4 running on IIS has a minor issue with Lifeblog. Everytime Lifeblog client sends items to MT4, it ends up in an error. However, the items do get to MT4 and they appear fine on blogs.
So, Nokia users, have fun with MT4 (and TypePad and Vox too) !
The term release candidate refers to a version with potential to be a final product, ready to release unless fatal bugs emerge. In this stage, the product features all designed functionalities and no known showstopper class bugs. At this phase the product is usually code complete.Wikipedia contributors, "Software release life cycle," Wikipedia, The Free Encyclopedia, http://en.wikipedia.org/w/index.php?title=Software_release_life_cycle&oldid=145490320#Release_candidate (accessed July 21, 2007).
リリース候補版とは、ソフトウェアの開発－出荷サイクルの中で、製品としてリリースしてもよい内容を含んでいる、ベータよりも広く利用されることを念頭において出されるテスト版です。一般に、リリース候補版では製品仕様はすでに確定しており、そのほぼすべてが実装済みの状態で出されます。リリース候補版を出した後は、製品開発チームはIn Development/開発中というフェーズから、Stabilize/安定化と呼ばれるフェーズに移行し、要するにバグ取りに集中します。品質保証担当は、この版での全機能テストに全力を傾けることになり、開発担当はそばで胃の痛い思いでテストを見つめているということになります。
この時期になると、機能要望はほぼすべて次のバージョンへとまわされます。また、報告されるすべてのバグを修正するわけでもなくなります。Show Stopperとか、Release Blockerとか呼ばれる、いわゆるデカいバグ、多くのユースケースで出現し、製品の円滑な使用を妨げること著しいというバグは直しますが、比較的マイナーな特定の環境でのみ起こる現象や、バグではあるが簡単に回避可能であるようなものの中には、「直さない」という明示的な判断をした上で、製品出荷後に再検討するリストに追加されるものもあります。こういう判断は、品質保証、ユーザーサポート、開発などと協議の上で、製品管理担当が行うのが普通です。
スーツにありがちな誤解で、バグが数えるほどになっていないと「品質が保証されていない」とか思っている人がいますが、よほど小さなソフトウェアでもない限りそういうことはまずありません。問題はバグの数自体ではなく、すべてのバグに対して適切な判断（直す、先送り、機能そのものを削るなど）を下しているかどうかにあります。この、バグに対して適切な判断を下せるかどうかが、製品管理担当（プロダクトマネージャ）にとってもっとも重要な資質であるといっていいでしょう。この判断を下すには、さまざまな種類のユーザーの目で、製品とそのバグを見つめることができなければならないからです。おっとこれは余談でした。
リリース候補版を世に出すメリットは、製品開発チームにとっては実運用環境でテストしてもらうことでテスト環境では気づかない重大なバグを発見できる機会を得ることです。ユーザーにとってのメリットは、製品仕様の固まったブツを入手することで、製品の購入や適用の是非の判断を出荷前から始められることや、自分の環境で先に製品を導入することで、自分の環境でしか起こらない問題をフィードバックしたり、それを認識した上で修正する方法を考えたり、場合によってはその問題があるがゆえに導入しないという判断を下したりすることができることです。
MTのオープンソース版でライセンスの議論が某閉鎖的掲示板で花盛りなわけですが、MTがGPLを選択するとしたら、それはGPLが提供するものが提供者はもちろん受け取る側にも最大の利益をもたらすからそうするわけで。
MTのようなソフトウェアでは、受け取る側が常に一次提供者から受け取るとは限らないわけで。受け取った側が今度は提供者の帽子を被ることがある。そのとき、一次提供者から受け取った人と二次提供者から受け取った人が享受する自由が異なっていたら、このようなモデルは一次提供者はもちろん、二次三次受け取り者にも不利益になる可能性があるわけで、二次提供者に同じ自由の提供を強制するライセンスを選択するのが自然な流れということになる。
このシステムの中で自分だけ人よりちょっぴり幸せになろうという発想だと、こういうものは理解できないし、理解しようとすることがともすれば捻じ曲げる方法を探すことになってしまいがちだが、そもそも一次提供者が何を考えてそのライセンスで自分に引き渡してくれたのかを考えれば、ことはそれほど難しい話ではないはずなんだけどね。厳格に法律の運用に関する議論を戦わせているわけじゃないみたいだし。
まあ以前から個人無償ライセンスをどこまでの範囲で利用できるかについて似たような、意味のない議論があるようだし、話題に上っているってだけでいいんじゃないのってことなのか。
MTみたいにバックエンドの処理は共通で、テンプレートを差し替えることで通常の検索と検索結果へのフィードとを切り替えている場合、バックエンドでどうやってフィードリーダーからのアクセスかどうかを知ればいいのだ、という疑問。
livedoor Reader, google reader, bloglines, いずれも決め手となるHTTPヘッダーがなかった。HTTP_ACCEPTでフィード系が前に来ているやつはフィードリーダー、とか決められると思ったんだけどなー。無念。
