Twitterクライアントで「いいね!」ボタンを実装するアイデア

公開下書き

(あとで大幅に書き直します．)

「いいね!」ボタンを押す側のクライアント処理

前提条件: 「いいね!」と伝えたいtweetが選ばれている．

  1. 選ばれている tweet に対して favorites/create API を発行． (お気に入り)
  2. そのとき特定の文字列(ハッシュタグ?)と対象ステータスIDを含むメッセージを，「いいね!」の送り先に tweet する．(このtweetを，ここでは「表示制御メッセージ」呼ぶ)
    1. 機械的なメッセージにすると，非対応クライアントではワケがわからず悲しい．例えば「@monamour555 #ppnow_iine 256」などではなく，「@monamour555 いいね! #ppnow_iine 256」など自然言語な文を入れると，みんな幸せ．

「いいね!」ボタンを表示する側のクライアントの処理

  1. statuses/mentions を監視．
  2. 得られた mentions に特定の文字列(ハッシュタグ?)が含まれなければ通常処理 [ここで終わり]
  3. 特定の文字列(ハッシュタグ?) を抽出して，表示する内容を選択(下記"拡張"参照)
  4. ステータスIDをメッセージから，送信元ユーザIDをAPIから，それぞれ抽出して，表示制御メッセージを送信したユーザが，ステータスIDに対応するtweet をお気に入りに加えているかどうか確認．
  5. お気に入りにあったら，該当するtweetに「いいね!」的メッセージを表示する．
  6. 制御表示メッセージは，対応クライアントでは，TLには表示しない．

拡張

ハッシュタグを複数定義しておくことで #ppnow_iine →「いいね!」，#ppnow_otsukare →「おつかれ!」， #ppnow_daijoubu →「だいじょうぶ!」など実現可能．

補足

お気に入りを併用するのは，表示制御メッセージに偶然マッチしてしまうことを防ぐため．非公式RTだと書式によっては有り得る．
(慰めのメッセージがお気に入りとなるのはアレなので)公式RTを使う手も考えたけれど，鍵付きのユーザの扱いが難しそう．

"東京"における幼少期技術教育の特殊性

前提

このエントリを書くきっかけは，昨日，とあるシークレットなイベントでシラフおよび飲みの会場での話だ．　でも，エンジニアの地位とか幼少期教育*1に関わるどこのテーブルでも聞かれる話でもある．一般論として捉えて頂きたい．
そして，ここで私が記す仮説が正解だと強弁するつもりもない．私の経験には基づいているけれども，長女はまだ10歳，次女は8歳，長男に至っては3歳．あと15年は追跡しないと評価不能だろう．

東京と地方の違い?

教育の難しさを考える文脈で，割と出るのは，東京*2と地方の子供たちの反応の違い．テンプレートは，下記のようなもの．

  • 地方の子供と東京の子供は違う
    • 地方の子供に教えると，目をキラキラさせる．純朴
    • 東京の子供は…

その理由としてのテンプレートは，

  • だって，東京には，技術教育以外に面白いものがたくさんあるし
  • そういえば，地方には，何も無いものね．

というもの．

上記は，実際に教育に携わった人の経験に基づく意見なので，否定の余地は無いように思う．しかし，そこを敢えて考えてみる．今日的な理由として正しいだろうか．

映画やボウリングやアーケードゲームが娯楽だったような30年前なら，真だろう．　しかし，今や子供たちの娯楽に特別な施設は要らなくなりつつあることには，別段の異論はないだろう．家庭用ゲーム機の普及で自宅で十分に遊べるし，郊外型ショッピングモールの林立でゲームソフトやマンガを始めとする娯楽リソースには容易にアクセスできるようになった．
入手困難なソフトは，Amazonワンクリックで翌日には手に入る．面白い動画も，webブラウザのワンクリックで地域格差なく表示できる．うわ駅前に何もないじゃんっていうような田舎でも，ADSLしか引けないから遅いっていう程度のハンデだ．
30年前と同様の，公園や校庭で遊ぶ好きな本を読むなどの子供の活動は，もともと地域格差が少ない*3．
技術教育以外の子供の娯楽に関しては急速にフラット化が進んでおり，東京の子供の特殊性は失われる方向にあるはず．　ここであっさり書いたので繰り返す．"技術教育以外の子供の娯楽に関しては"

仮説

事実関係

東京という都市は，極めて恵まれている．各県の県庁所在地に相当するような規模の区が23個もあり，加えて大規模な市もある．それぞれに課外の学習機会を得られる公立の機関が存在する．国立研究機関や大学が山のようにあり，それぞれが独自に博物館/科学館を開設している．企業のメセナ活動としての博物館/科学館もある．これらの膨大な量の施設は，総計すると膨大な，技術教育の機会を提供している．

また，人口が多いということは，技術者も集積していることも意味する．　篤志を持ったエンジニアや研究者が土曜日や日曜日を使って教育の機会を提供しているのは，web検索エンジンを1分操れば見えてくる．

そして，これらの幼少期教育は，無料もしくは材料費程度，展示の一般公開への入園料程度で提供されている．

この事実は，冷静に考えると，驚くべきことだ．　東京で子供を育てている親の一人として，関係者の尽力にいくら感謝しても足りないくらいだと思う．

けれども，それらの方々を少しがっかりさせるようなことを，私は感じている．

「膨大な技術教育の機会が子供の意欲を失わせる」という仮説

しかし，この豊富さが，東京の子供の技術教育への取組み態度に，悪い方向で影響しているのではないか．　最近，私は，そのように思うようになってきている．

"いつでもできる == ついにやらない"は，古今東西，言われてきたことである．
この悪い関連が，"技術教育"と"東京の子供"の間にできているのではないだろうか．

言うまでもないことであるけれども，この仮説が正しくとも，技術教育の機会を増やそうとしている方々が悪いとは思えない．仮に全ての子供たちに技術教育の機会を一瞬でも与えようとするならば，現時点の機会でも全く足りないのは想像に難くない．　矛盾するように受け取られるかもしれないが，私見としては，技術教育の機会は万人に行き渡るレベルに至っていないとさえ思う．

キュレータとしての親の役割

話を少し脇に振る．　博物館に近づかない大多数の方々にとって，知名度は高くなさそうな*4職業に，"キュレータ"がある．この職種の詳細はWikipedia辺りをご参照頂くとしてザックリと言うと，山のようにある展示・教育リソースを整理構成して，スジの通った独自の企画を打ち出す要職がキュレータである．　博物館のお客さんというのは，言い換えると，キュレータの作ったメニューに沿って体験し，自らの経験の一部とする存在とも言える．

仮説通り，子供が膨大な技術教育の機会を得て選択できない状況にあるとするならば，それらのリソースを整理して子供に体験の機会を提案する存在が必要である．技術教育の機会が複数の組織に跨っている現在の東京において，子供たちにオーダーメードの企画を提案できるようなリソースを各組織に求めるのは難しい．　それを唯一可能とするのは，子供が属する家庭であり，その中でキュレーションを行う能力を第一に期待できるのは，親であろうと思う．

キュレータとしての役割を阻害するもの

仮説および対策案が正しいとして，妨げるケースがあるとすれば，2つ考えられる．
一つ目は，親が博物館|美術館|科学館の類に縁がない，もしくは縁遠くなっているというケース．　親が専門職の場合は，(子供の為でなく)自らこの類の施設に行く習慣がついている場合が少なくないが，そういう親ばかりではない．
もうひとつは，親が忙しい，というケース．　全ての親が子供の休みのときに休めるわけでもない．　特に，エンジニアは残業が100時間に迫る勢いなど珍しくないので，事実上，子供のために情報収集などする時間など取れない．

現場の人の感触は否定しないが…

余暇を削って技術教育の機会創出に関わっている人々が，その感触として伝えているのだから，東京の子供は特殊なのかもしれない．
ただ，その原因については，深く検討する必要があるのではと思う．

まとめる．

  • 機会が少ないということは割と意識されがちである．
  • 一方，機会が多すぎることについては，意識されないことが多い．
    • さらに弊害については，頑張りの成果であるがゆえに下手をすると努力の否定に聞こえかねないので，声にするのは憚れる．
  • しかし，その仮説を立てることはできる．
  • その仮説が真だとするならば，親の関与が解決策として期待できる．
  • 解決策としての親も，可避/不可避な課題を抱えている．


(2011年2月15日，文意を変えない程度に加筆訂正)

*1:ここで言う幼少期とは，概ね小学生を指す

*2:私が住んでいて見聞きするのが東京だから．もしかすると「都市部」と汎化できるのかもしれない

*3:もちろん，雪が降ると2時間歩いて学校に行かなければいけないような限界集落は日本にも存在はする．しかし，そういうところに東京から子供向け教育の為に出向くというのは，よほどのレアケースなので今回のエントリでは考慮していない．

*4:というと失礼だが

文化庁メディア芸術祭へ行ってきた

3連休の最後で，かつイベント最終日．混むよねぇとは思いつつ，行ってみて，やっぱり混んでいた．orz

notart日記で劣化パクったパスティーシュした"10番目の感傷"は，大盛況で並ぶ気を起こせず．

ustのシンポジウムを視て気になっていた"帰り道のアートスペース"は「えがく→とりこむ→はる→みる」の体験のうち，テクノメディア的な鍵のはずの「とりこむ」が(理由の説明なく)できなくなっていて，結果，ユーザへのインタラクションである「みる」の部分が得られないという状態．　機材トラブルか何かかもしれないけれど，説明くらいはして欲しいところ．　シンポジウムでもいろいろツッコまれていたけれど，残念ながらそれ以前のレベルで，あの会場で，一番ワケの判らない展示になっていたと思う．

共に，最終日に行った私が悪い．

とはいえ，作品の見せ方は判りやすいし，じっくり見られる展示もいくつかあったし，行ってよかった．

今年度，私の涙腺の制御権を奪った一押しショートムービー"Googuri Googuri"が推薦作品に選ばれているのをみて「ほらほらやっぱり」と思ったりとか，ムービーでしか見たことがなくて気になっていた"TEAMLAB HANGER"を手にとってみることができたりとか．"i3DG"のコロンブスの卵っぷりに「私はエンジニアとしては頭固すぎるのかなぁ」と思ったりとか．

組込みでのオブジェクト指向的思考


コメントください。
とのことなので，書いてみる．


ではなぜ、オブジェクト指向を取り上げずに、今なお構造化設計にこだわっているのか...
その理由は、クラス設計には、思考の転換が必要で、ハードルが高いと感じているからです。

RTOSを扱うということは，事前に与えられ継承不可能なクラス群のインスタンスを操作することと換言できる．
μITRONで提供されるリソース群は，カーネルオブジェクトと呼ばれる．μITRONはオブジェクト指向なRTOSではないが，オブジェクト指向的な何かを理解せずに使うのは，おそらく難しい．

私は筆者と面識があり，あまりに当然のことすぎて筆が滑ったのだろうと判っているのだけれども，ツッコまなければならないところはツッコむ．クラス設計はオブジェクト指向の部分集合でしかない．ここをすり替えてしまうとミスリーディングになってしまう．

筆者は初学者も想定読者としているようなので，念のため記しておくと，オブジェクト指向にはいくつかの流派があり，クラスベースはその一つ．別の流派に，オブジェクトベース*1というものもある．

組込みシステムでは，極めて似てはいるが同一ではない処理をさせることが多い．例えばシリアルポートが多数ついていて，1個だけがFIFO付きだったり，とか．このような時の定石の一つとして，実行単位オブジェクト*2のエントリポイントを複数にしながらも，共通にできるところは極力サブルーチンに纏めるという手がある．これはオブジェクトベースの考え方に(洗練はされていないが)近い．

さらに言うと，データ構造に関してはオブジェクト指向の理解は必須と言ってよいと思う．
言語処理系や通信パケットをやり取りするようなアプリケーションのC言語記述では，しばしば下記のような構造体に出会う．

struct atom {
    int type;
    union {
       int integer;
       struct {
         char *buffer;
         size_t size;
        } string;

これは，integer と string が atom クラスのインヘリタンスであると見ることもできる．実際，オブジェクト指向言語では，そのように記述されるのが一般的である．

μITRON系のカーネルでは，メールボックスのT_MSG構造体で，上記のような手法が(やや強引な型キャストと共に)使われている．判っていない人は誤用してカーネルパニックを起こす．μITRONアプリの開発者の大半が，一度は通る道(?)である．

クラスベースの設計思想が判っていないと，この辺りをきちんと理解するのは難しいかもしれない．

というわけで

組込みでもオブジェクト指向の習得は，やはり必要であるのでは，と．
しかもOSの使用が珍しくなくなった昨今，初学者だからといって逃げられないかもしれない．

余談

とは言っても，いきなりクラスとインヘリタンスから説明を始めてしまうオブジェクト指向本が多くて，組込みシステムの実開発現場に取り込みづらいというのは，言えるような気がする．
…とかいうことを放言しておくと「じゃあお前が書け」って話になりそうなので，割といいんじゃないかなと思う構成の本へのリンクをつけて逃げる．

リアルタイムUML―オブジェクト指向による組込みシステム開発入門 (Object Oriented Selection)

リアルタイムUML―オブジェクト指向による組込みシステム開発入門 (Object Oriented Selection)

原書は3版になっている．和訳は2版で，UML的には古くなってしまった．けれども，UMLの書き方を学ぶのではなくオブジェクト指向の組込みシステム適用のエッセンスを学ぶのであれば，今も十分に役に立つ．たぶん．

*1:プロトタイプベースと呼ばれることもある

*2:スレッドとかタスクとか割込みハンドラとか

RBT-001 を OSX で使ってみる．

ロボット関係で割と人気があるらしい，Bluetooth SPP モジュール RBT-001 *1． Webの情報を漁ってみたけれど，どれもこれも Windows と繋ぐ例ばかりで，OSX での情報がない．

人柱として，やってみた．


…あっさり繋がった．ま，それが Bluetooth の目指しているところではあるのだけれど．

OSX 側には，

/dev/cu.EasyBT-COM1
/dev/tty.EasyBT-COM1

てなファイルができあがる．
RBT-001 の電源OFFにしても，ファイルは消えないらしい．

RBT-001 Bluetooth evaluation kit

雑感

標準状態の 9600bps 8N1 以外の設定にするには，ちょっとした細工*2が要る．言い換えると，通信設定を 9600bps 8N1 のまま使うのであれば，何の細工も要らずシリアルを bluetooth で飛ばせる．　ちょっと値段が微妙なのが残念．でも，マイコン野郎は1台持っているといろいろ面白く使えるのではなかろうか．

*1:フィジカルコンピューティング系でも使いでがありそうなのに，ロボット系に情報が集中しているのは，デアゴスティーニの「週刊My Robot」の付録として格安に入手できた経緯だろうか

*2:ブート時にコマンドモードに遷移させる

Headlessなbuckminsterでsubversiveをインストールする．

Eclipse

現象

Web上にある情報の通り，下記のようにインストールすると

buckminster install http://download.cloudsmith.com/buckminster/external org.eclipse.buckminster.subversive.headless.feature

エラーが出てインストールできない．

An error occurred while collecting items to be installed
[0]session context was:(profile=Buckminster, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=).
[0]No repository found containing: osgi.bundle,com.ibm.icu,4.0.1.v20090822
[0]No repository found containing: osgi.bundle,javax.servlet,2.5.0.v200806031605
[0]No repository found containing: osgi.bundle,org.eclipse.core.databinding,1.2.0.M20090819-0800
[0]No repository found containing: osgi.bundle,org.eclipse.core.databinding.observable,1.2.0.M20090902-0800
[0]No repository found containing: osgi.bundle,org.eclipse.core.databinding.property,1.2.0.M20090819-0800
[0]No repository found containing: osgi.bundle,org.eclipse.equinox.concurrent,1.0.1.R35x_v20100209
[0]No repository found containing: osgi.bundle,org.eclipse.help,3.4.1.v20090805_35x
[0]No repository found containing: osgi.bundle,org.eclipse.jface,3.5.2.M20100120-0800
[0]No repository found containing: osgi.bundle,org.eclipse.jface.databinding,1.3.1.M20090826-0800
[0]No repository found containing: osgi.bundle,org.eclipse.swt,3.5.2.v3557f
[0]No repository found containing: osgi.bundle,org.eclipse.ui,3.5.2.M20100120-0800
[0]No repository found containing: osgi.bundle,org.eclipse.ui.workbench,3.5.2.M20100113-0800

対策

先に，PDEのインストールが要るらしい．

buckminster install http://download.eclipse.org/eclipse/updates/3.6 org.eclipse.pde

PizzaFactory for Document Developer のDITA対応

お仕事 Eclipse

DITA対応っても幅広い．
PF for DD のターゲットは，当面，生の XML を書くことも厭わないモヒカン系開発者．モヒカンはモヒカンらしく，XML や DTD と闘ってほしいので，セットアップの手間を省くことに重点を置いている．*1

今日の不満とその改善策は，DITA-OT のインストール．

一人で使っている限りは，使いたくなったら zip をダウンロードして展開して，エディタとDTDの設定をして…というのはさほどの苦ではないけれど，会社ともなれば複数名で環境を同期しなければならない．　

また，DITA-OT は改造/拡張してナンボというところがあるので，社内の各自の改造/拡張の共有は極めて重要．ちょっと目を離すと，すぐに環境が同期しなくなる．

…って言っている私は，いまだに 1.4.x 系の DITA-OT が手元に入っていて，同僚の OT と既にバージョンがズレている．非常にマズい．

そこで，Eclipse p2 の rootfiles を用いて，DITA-OT そのものをアップデートサイトからダウンロード可能にした．原理的には，社内で改造/拡張をしたものを取り込んで，新しいバージョンのフィーチャーとすれば，環境が無秩序になることはない．*2

ついでに，DTD のマッピングを行うプラグインも作った．これで，いちいち手入力しなくても XML file の新規作成で DTD から生成できる．


例によって http://update.pizzafactory.jp/docdev/ からインストール/アップデート可能．

*1:まあつまり，私自身が楽をしたいというのが， - 現時点での - 設計の根本思想

*2:改造/拡張の情報が共有されるかといった社会学的な側面は，また別の話．