Stellaqua - TOMの技術日記 このページをアンテナに追加 RSSフィード

2013年07月31日

[][][][]BEAR.Sunday meetup #2に行ってきました

何と、前回の記事の日付が2年前という恐ろしい状況!…止まった時計を再び動かすべく、はてなダイアリーに戻って参りました。

という事で、BEAR.Sunday meetup #2にお邪魔させて頂いてきたので、ご報告を。

会場はとってもオシャレなHubTokyoさん。WebSterさんの提供で、食べ物・飲み物に困らずに非常にリラックスした状況で、なるほど、これが勉強会ではなくmeetupなんだと実感しました。

全員が自己紹介も兼ねてLT必須という事で、何の話をしようかと思ったんですが、ちょうどTDDフレームワークのWaltzを作っていて、DocTestが動く状態になったところだったので、その紹介をさせて頂きました。

http://www.slideshare.net/stellaqua/bea-rmeetup2-lt

他の方が時間節約の為に1台のPCに資料をまとめてプレゼンしている中、どうしてもDemoをやりたい、というわがままで自分のPCでLTさせて頂きました。頑張ってビジュアルにこだわったテスト結果の楽譜表示は、特に女性陣には好評だったようで、満足しとりますw Waltzのもっと深い話は、またいつかどこかで…。

自分のLTはともかくとして、みなさん3分間という短い時間なのに(自分も含めてオーバーしてた人多数ではありましたがw)、とっても濃い内容で素敵でした。

また、メインセッションの方も、@koriymさん、@mackstarさん、果ては、NateさんのAngularJSの話が直に聞けるという何とも贅沢なmeetupでございました。特に、@koriymさんのプレゼンは、「いよいよBEARの世界進出が始まる…!?」と思いながら、本当にワクワクしながら聞いていました。

自分もBEARを応援し続けてきた一人として、このワクワク感をもっと世に広めるべく、自分にできる事を進めていこうと心新たにしたところで、筆を置きたいと思います。

2010年05月06日

[][]TopHatenarのランキングを周期表っぽく並べたものを作ってみた

何かふいに思い付いて、TopHatenarはてなダイアリーのランキングを元素周期表みたいに並べたもの*1を作ってみました。

ランキング周期表

何の意味があるかって? 何の意味もありません。(笑)

元々、アイデアのネタの一つとして「周期表の形式で何かを並べたら面白いものが作れないかな。」と思っていたのがあって、「ちょうど順番に並んでいるものだし、何かのランキングを周期表に見立てて並べたら面白いかも…。」ぐらいの軽い気持ちで、勢いに任せて作ってみたものです。

内部的には、必要な情報の位置をURLXPathを使って指定して取ってくるような作りにしてあって、設定ファイルさえいじれば、色んなランキングの周期表が作れるので、徐々に対象を増やしていこうかなと思っています。*2

ちなみに、元素記号的な感じになっているアルファベット数文字は、この周期表内で被らないようにしながら、はてなIDを省略したものですが、はてなーの皆さんならその数文字だけで誰だか分かるかもしれませんね。( ̄ー ̄)

あとは、せっかく元素のメタファーを持たせたので、その絡みで何か面白い事ができないか考えたりはしていますが、このWebサービスが発展の方向に向かうかどうかは…現時点では未定です…。

とりあえず思い付いたら、すぐに作ってすぐ公開をモットーに、また色々作っていこうかなと思います。

*1:ランタノイド・アクチノイドは一つの元素という扱いにしています。

*2TopHatenarのランキングはAPIが無さそうだったので、スクレイピングして情報を取ってきている為、TopHatenar側のHTML構成変更などがあった場合、予告なく当サービスを停止する場合があるのでご了承の程を。

2010年03月29日

[][]ツイッターを掲示板的に利用できるTweetboardをはてなダイアリーに設置してみた

今までツイッターは使うのにどうしても抵抗があって利用してこなかったんですが、Tweetboardという素敵なサービスがあるのを知って当ブログに設置してみたので、これを利用してツイッターを活用していこうかと思います。

Tweetboardというのは、Webサイトにツイッターを利用した掲示板を設置できるサービスで、プロフィール欄の右側にある"tweets"というボタンがそれです。

使い方は詳しく紹介しているサイトがあったので、そちらのリンクを貼っておきます。

Free Dynamic DNS(DDNS) by POP3,IMAP4,FTP,HTTP-BASIC for Home Server, VPS | MyDNS.JP

ちょっと苦労話

Tweetboardは現在アルファ版との事で、利用する場合はテスター扱いという事のようで、管理者に招待リクエストを送って承認してもらって初めて利用できるようになります。

招待リクエストを送る事自体は簡単だったんですが、何せ1件1件人手で承認をしているようで、私の場合は結局最初のリクエストから1ヶ月ほど掛かって、なおかつ2回ほど催促をしてやっと承認してもらえました。(^^;

あと、もう一つ苦労したのが、はてなダイアリーで利用できるJavaScriptが特定のものだけに制限されている事で、これに関してはGoogleガジェットを間に挟む事で解決する事ができました。

ただどうしても解決できなかった問題があって、本来は左端に設置されるものを右端に持って来ざるを得なくて、展開表示すると画面からはみ出てしまうので、いちいち画面スクロールしないといけなくなっています…。

というのは、Googleガジェットがiframeに展開される関係で、どうしても展開表示された状態の幅での表示領域を確保しておく必要があって、しかも確保されたiframe領域の内側はいくら背景を透過させても、その後ろにあるリンクとかをクリックする事ができないので、iframeの表示領域部分にリンクが掛からないように、右側に持ってくるしかありませんでした。

という事でちょっと使いにくさは残ってしまったんですが、Tweetboardの機能自体は非常に面白いと思うので、どんどん使っていこうと思います。

今後のツイッターの使い方

実はちょっと前から既に始めていたんですが、FriendFeed経由で当ブログの更新状況をツイッターにつぶやくようにしていました。

一応、ツイッターでの発言はそのままTweetboardにも反映されるようなので、Tweetboard上にはブログの更新履歴が並ぶような感じになるかなと思います。そうすると、記事毎にスレッドが作られる形になるので、各記事に関連する話はそのスレッド上で展開していくようにしようかなと思っています。

そんな訳で、記事に対してツッコミとか、それ以外でも単なるテスト投稿でも構わないので、どうぞお気軽に使ってみて下さいね〜。

2009年03月24日

[][]Webサイトやブログの文章を元に、雪の結晶のような模様の画像を生成するサービスを作ってみた

何となくアイデアが湧いてきてカリカリと作っていたんですが、とりあえず形になるところまでできたので、公開してみます。

DoCrystal 〜文章の結晶生成サービス〜

使い方

使い方は簡単。サイトのURLか文章を直接入力するかして"DoCrystal!"ボタンを押すと、対象の文章を元に雪の結晶っぽい画像を生成します。

文章を直接入力する場合は、それなりに文章量が多くないと結晶が育たないと思うのでご注意を。

基本的には、ただそれだけのサービスなんですが…ブログパーツなどで、"自分のブログの結晶"というような形で貼ってもらえる事を想定して作ってみたものです。

アルゴリズムは企業秘密という事にしておこうかと思いますが、基本的に対象文章の文字の量・質によって、結晶の枝が伸びるようになっています。

なので、Googleみたいにシンプルなサイトだと、結晶もシンプルになります。

http://www.stellaqua.com/docrystal/images/id_9d0f4061beb6ae41f64eb124665e0768_small.png

逆に、当ブログのように文字の多いサイトだと、結晶もごちゃっとした感じになります。

http://www.stellaqua.com/docrystal/images/id_39b533a4ca7fc4c69303a326bc91de11_small.png

ランダム生成ではなくきちんと文章を解析しているので、全く同じ文章であれば同じ結晶になりますが、どういう文章だとどんな結晶になるかは、正直、作った本人でも分かりません…。

ちなみに、意味解析はしていないので、「ありがとう」とかいっぱい書いても、キレイな結晶になる訳ではないので、あしからず。(笑)

APIについて

直接画像を返すAPIを用意しています。imgタグを使って、一度生成した結晶画像や、特定のURLの結晶画像を表示させる事ができます。以下は、当ブログの結晶画像を表示する例です。

<img src="http://www.stellaqua.com/docrystal/api/images.php?url=http://d.hatena.ne.jp/stellaqua/">

一度生成して、IDが付与された画像の場合は、urlパラメータの代わりに"id={画像ID}"として、画像を指定する事もできます。

また、"size=small"を付けると、100x100pxの小さい画像になります。(通常サイズは、300x300pxです。)

エラーがある場合は、全てレスポンスコード500を返します。*1

文章量が多いサイトのURLを指定した場合、初めてのアクセスの場合は解析・画像生成を行う為、多少時間が掛かる事があるのでご注意下さい。

ちなみに…この記事書く時に、はてな記法で結晶画像を貼り付けようとしたところ、どうも動的URLはダメっぽいので、慌てて静的URL用のRewriteRuleを作りました。以下のように書けば、はてなダイアリー内で結晶画像を貼り付ける事ができます。

[http://www.stellaqua.com/docrystal/images/id_39b533a4ca7fc4c69303a326bc91de11_small.png:image]

画像のIDは、画像生成した時に表示される大きい結晶画像のURLに入っていますので、そこから得る事ができます。


という訳で、ぜひ遊んでみてやって下さいね。

*1:きちんとエラーコードを分けていないのは手抜きです。すみません。(^^;ゞ

2008年09月14日

[][]RESTfulWebサービス読書会第5回に行ってきた

今回は(今回も?)、読書会というよりは、おしゃべり会みたいな感じで、AtomPubの話題を中心にREST議論をしてきました。

話の中心は、「はてなダイアリーのAtomPubって何か気持ち悪いよね」という話題でした。

もう既に各所で言われている話とは思いつつも、自分でリソース設計とかする時の参考になるかも、という期待を沿えて、簡単に書いておこうかと思います。

まずは、はてなダイアリーのAtomPub対応の仕様へのリンクを貼っておきます。

はてなダイアリーAtomPubとは - はてなキーワード

話に挙がった"気持ち悪さ"の一番は、下書きエントリーを公開する時のやり方で、こんな感じのリクエストを投げるようになっています。

PUT /はてなID/atom/blog/20080101/XXXXXXXX
X-HATENA-PUBLISH: 1

※話の中で挙がったんですが、"blog"は"draft"の間違いですよね…きっと…。

こういう仕様になったのは、色々と都合もあっての事だとは思うんですが、せっかくAtomPubに対応したのに、AtomPubの仕様として用意されている下書きの機能(app:draft)を使わずに、下書きという別リソースにしたのは何でだろうね?…という辺りがその場でのみんなのツッコミどころでした。

想像するに、はてな"ダイアリー"である以上、日付ベースのデータ管理になっていて、今更、他の形式の管理には変えられないというのが一番のネックになっているんだろうなとは思いますが…。

で、AtomPub的にどうかというのは置いておいたとして、記事リソースと下書きリソースという2つのリソースに分けるというリソース設計なんだという立場で見たとしても、"X-HATENA-PUBLISH"という独自のヘッダを使うのは、REST的に美しくないよね…という話もしました。

あと、リソース設計する時に気を付けないといけないなと思った点として、例に挙げた下書き公開操作は、結局のところ、

  • 下書きリソースの内容を取得
  • その内容で新しく記事リソースを作成
  • 下書きリソースを削除

という3つの動作が内部的に行われる事になるはずなので、最初、「GET→POST→DELETEってクライアント側がリクエストを投げるようにすればいいんじゃないの?」と思ってしまったんですが、いずれかのリクエストが失敗した時の整合性が取れなくなってしまうので、これら3つは一連の操作として行われなければいけないんですね…。

こういった、"下書き"→"公開"みたいに、状態を別リソースとして定義していて、その状態を変化させるリクエストを投げたい場合は、状態変更専用のリソースを別途定義しておいて、パラメータとして元の状態のリソースのURIを渡す…というのがスマートな方法かなという話になりました。

はてなダイアリーの場合だと、

PUT /publication?drafturi=/はてなID/atom/blog/20080101/XXXXXXXX

みたいな感じ?*1

まぁ、今までRESTfulな読書会をずっとやってきていて、「何を今更…」と言われそうですが(^^;、具体例としてこういった事例を見ないと、なかなか感覚的に分からないので、今回、目の前にある具体例として、はてなダイアリーのAtomPub実装をベースに議論できたのは良かったなぁと思います。

という訳で、「やっぱり具体的にやってみなきゃ分かんないところも多いよね…」という事もあるし、ちょっと作りたいサービスもあったので、バックエンドをRESTfulに設計してみようかなと思って、今日はインフラ部分を色々とやっていました。

自分で一から実装するのは面倒臭いし、せっかくの機会だからと思って、まだ右も左も分かっていないRailsに手を出してみた訳ですが、Railsとは直接関係無いところで色々と時間を掛けてしまい、やっとこさ「scaffoldで作ったbookmarkリソースにGETしたら、XMLで結果が返ってきたよ、わ〜い♪」というところに辿り着いた辺りで力尽きてしまいました。(^^;ゞ

Rails(およびRuby)はまだ全然分かってないので、勉強しつつボチボチやっていこうと思います。

*1:でも、「状態を変える」という動詞的な意味合いが強い感じがするから、何となく違和感があるような気がしてしまうなぁ…。(^^;