As Sloth As Possible

可能な限りナマケモノでありたい

タグ:Twitter

twitterの呟きをそのままブログに載せるのってどうなの?っていう記事を見て、最近思ってたことで書いてなかったなぁってことがあったのを思い出した。

元記事に書いてあることには概ね同意で、俺も個人的には「ただ載せる」だけならやんなくてもいいのになぁと思ってるけど、元記事には結構「イヤなら見るな」「別に書き手は”あなたのために”書いてるわけじゃない、あなたが見たい/見たくないものを考慮して書く必要なんかない」ってコメントが付いてたりして、それに対してもまぁそれもそうだよなぁとも思ってる。俺がどうしてるかというと、readerにその日一日のポストをまとめた記事が上がってきても単にjjjって押してスルーするだけだし、あまりそれの頻度が高いようならレートを落として週一で見るだけにしたりもういっかーってんで購読停止したりすることもあるけど、だからってそのブログを書いてる人に「もっと読む人のことを考えた投稿をすべきじゃないですか」なんて意見したりはしない。受け手側が好きに取捨選択すればいいだけの話だとしか思わないしそうするのがWebだろうとも思ってる。

けどまぁ、ねぇ、と思うこともあるのですよ。なんと言うか、もちろん腹立たしいとかではなくて、勿体ないなぁ、というか。

twitter自体は本当にただ「つぶやく」ことができるというだけのサービスなので、そこに何を流そうが流す方の自由だし、そこから何を受けとろうが受けとる方の自由。生データ。どのくらい「生」なのかと言うと、例えば鉱山にある岩塊だったり渓谷に流れる水だったり森に生えてる野草だったりするくらいの「生」加減だと思うんだよね、あれって。

で、そういうものって、もともと「そこにある」分には「そのまま」でいいと思うし、「欲しい人は自分で山に入って取ってきてね」ってスタンスだったらそれはそれでいいんだけど、「街に持ってきてみんなに配ったり売ったりしよう」と思ったら、普通は岩塊や水や野草のままじゃなくて、岩塊は鉱物を抽出して金属塊にしたり、水はペットボトルに入れておいしい水ってラベル貼ったり、野草は薬や料理にしたりするよね、っていう。そして個人的には「twitterもやっていてブログも持っている」人が「twitterで見られるものを敢えてブログに持ってくる」というのはきっと「山奥の資源を街に持って帰ってくる」に近いような位置付けじゃないのかなぁ、と思う。

別にだからどうだと言うこともない。ブログにしろtwitterにしろ、あくまで道具なので使う人が使いたいように使えばいいだろうと思うし、だから一日分のつぶやきをまとめて貼ろうが、そもそもブログそのものをtwitter的な「生のデータを生えたい放題にさせとく場所」にしたって全然構わないと思う。俺自身、(このメインブログでは基本的にそれはやってないけど)サブブログでは本当につぶやきとか日記レベルのことを書いてたりする。上に書いたようなことも単に「俺が個人的に」「受け手として」思うだけの話で誰に何を提案するわけでもましてや強制するつもりもない。けど、「勿体ないからどうせなら加工してから店に置いときゃいいのになぁ、そうしたらきっとみんなもっと喜ぶだろうに」というなんだろ、感想、みたいなものはよく抱く。素材だけじゃなくて「編集する」っていう「料理人の腕」も見てみたいなぁ、とか。そんなもやっとした結論。

RubyCocoaを極めるプロジェクト中でtwitterクライアントを作るという話が出てたので、正月休み中にみんなでいじって遊べる程度に動くものを作ってしまおうと目下がりがり書いてる最中なのですが、なかなか楽しいね、RubyCocoa。

e84fa15a.png

CoreDataが素敵

折角なのでCoreDataを活用してやろうと、HMDT本やリファレンスと格闘してました。CoreDataってなんぞ?ってレベルからのスタートだったので結構苦労したのだけども、CoreDataってのは要はCocoaアプリ中で簡易DBとO/Rマッパーを使えるようになるフレームワークなんだね。ActiveRecord+pstoreやsqlite、みたいなもんだと言っていいのかな。

で、これが非常に便利。Xcodeのモデリングツールでデータの定義をしておけば、勝手にDBとラッパオブジェクトを作ってくれるのでモデルクラスのとこのコーディングが格段に減る。モデル同士の関連もモデリングツールで作れるし、InterfaceBuilderとの連携でコントローラ部分も自分で作る必要がないので、簡単簡単。RubyCocoaから使う場合はCocoaから使う場合と若干構成が違うので最初躊躇ったけども。自分へのメモの意味でも、Xcode3でRubyCoca-CoreDataアプリを作る際のIBチュートリアル記事をあとで書いとこう。

ちなみに、twitterのデータの読み書きはこんな感じ

まずはデータの新規作成。

# NSManagedObjectのオブジェクトを新しく作ってDBに突っ込む
user = OSX::NSEntityDescription.objc_send("insertNewObjectForEntityForName",
            "User",
            "inManagedObjectContext",
            @managedObjectContext)
user.userId = '11111111'
user.screenName = 'rucotan'                                               
user.name = 'るこたん'

これでるこたんの情報がCoreData経由で使えるようになる。実はこの時点では「るこたんの情報が管理対象になった」だけで、自分でデータの保存処理をするか、CoreDataApplicationテンプレートからプロジェクト作ってるとアプリの正常終了時に自動で保存処理が呼びだされる*1か、そのタイミングで初めてファイルやDBに書き込まれるんだけど、「管理対象になった」時点でアプリ全体で使えるデータになるのでここではあんまり気にしない。

ちなみに、以前はNSManagedObjectのプロパティをいじるのに毎回valueForKeyやsetValue_forKeyを呼び出してたみたいなんだけど、RubyCocoaの改良でラッパオブジェクトを作るようにして、NSManagedObjectをまるでRubyのオブジェクトのように扱えるようになったらしい。軸がぶれてない、素敵*2。この辺がARっぽいとこ。

続いて既にあるデータの取得。

# NSFetchRequestを用意。RDBMSにSELECTクエリを発行するみたいな感じと言えばいいかな。
request = OSX::NSFetchRequest.alloc.init

# モデルを設定。SELECT文のFROMを指定するのに相当すると理解。
entity = OSX::NSEntityDescription.entityForName_inManagedObjectContext('User', @managedObjectContext)
request.setEntity(entity)

# 述語を設定。SELECT文のWHERE句相当、かな。
predicate = OSX::NSPredicate.predicateWithFormat('screenName == %@', 'rucotan')
request.setPredicate(predicate)

error = OSX::OCObject.new
users = @managedObjectContext.executeFetchRequest_error(request, error)

これで「screenNameがrucotanであるUserのリスト」を取得できる。NSFetchRequestとかNSPredicateってのが要はDBハンドラにプリペアードクエリを渡すのと手順は大して変わらないので、日頃DBを使うアプリに慣れてると違和感ないですね。注意点としては、executeFetchRequestの返り値はOSX::NSCFArrayなので、users.empty?とかusers.firstとかやると「そんなメッセージ、わたしが受け付けるとでも思ってるの!?この愚民は言葉もまともに話(ry」と怒られてしまう。Rubyで使うときは最初にto_aしておいた方が楽かも。

これだけだとRubyのARやPerlのClass::DBIに慣れきってる身としてはかったるくてしょうがないんだけど、Xcode上のモデリングツールで受信要求テンプレートというのを作ることができて、それを使うとNSFetchRequestの生成が大分楽になる。

variables = OSX::NSMutableDictionary.dictionary # 述語に渡すパラメータ
variables['screenName'] = 'rucotan'
request = @managedObjectModel.fetchRequestFromTemplateWithName_substitutionVariables('template_name', variables)
error = OSX::OCObject.new
users = @managedObjectContext.executeFetchRequest_error(request, error)

ちなみに、Xcode上で受信要求テンプレートを作る際には述語ビルダというのが使えて、複雑なリクエストでもiTunesやMailのスマートフォルダを作る感覚で述語を生成できてしまうので非常に簡単。だと思われる。いや、まだ使ったことないの。

キーバリューコーディング

に、ついても書こうと思ったんだけど、そろそろ長くなってきたのでまたの機会に。

仮名のRuchettaについて

Rubyの「る」とCocoaの「こ」がつくものがいいなあと考えて真っ先に浮んだのが「ルッコラ」だったんだけど、rucolaって開発環境があるのね、RubyCocoaの。ので、同じくルッコラを意味するイタリア語の「Ruchetta」にしてみた(安易)。ちゃんとr(uby)とc(ocoa)とt(witter)が入ったし、「ついった」と「るけった」で語感的にも悪くないかなと思ったんだけどどうだろう。みんなでいじれるようになったら名前も新しく考えてもらってもいいかな。

先を越された

これを書いてる最中に夏ライオン(OSXのtwitterクライアント)αリリースのお知らせが…。UIかっこいいなぁ。参考にさせてもらおう。

追記

夏ライオン見易くてなかなか良かった。自分でtwitterクライアント作ってる最中なのに当面夏ライオンユーザになりそうな予感。

*1:未確認。アプリ終了時に保存されるのは確かなんだけど、それがどこから何を呼び出してるのか実はわかってない。あとでちゃんと見る。

*2:そういえば絶望先生2期って今クールでしたっけ?

ふぁぼったーの自分のふぁぼられページがしばらく前にできたとき、そこに貼られたAdSenseって、ある意味「他の人からみた自分」に対してのコンテンツマッチだよねってな話がちょっと盛り上がった。ダンボールを勧められたとか、貧しい子供への募金の広告がでた俺は心やさしい人なんじゃねとか。

で、それ以来ちょくちょく、面白いネタ出ないかなーと見に行ってるんだけど、どうにもGoogleは俺をおちょくってるとしか思えない。初日には何を思ったかHTMLエディタの広告が出てたんだけど、二日目以降は「こんな僕でも就職できた」とか「何をやってもダメな俺が副業で月収100万」とかそんなんが出続けてる。まぁ、致しかたない。マッチさせようにもコンテンツが少ないので、「ダメ人間」にマッチさせるしかないしな。昨日「ダメ社員の再チャレンジ」ってのが出たときには流石にタイムリー過ぎて凹んだけど。

それは良いとして(良かないけど)、今日見たら「子犬の激安即売会」「子犬ライブ放送中」って広告が出てたんですが、どういうことですか。他の広告も見事に「グッズ犬」「犬笛」「里親犬」「激安子犬」と犬ずくめ。

一体何にマッチしたのか謎は深まる。が、犬目当てでとりあえずクリックしてしまったこれはきっと@ono_matopeの策略に違いないと思うんだ。

↑このページのトップヘ