tmty.jp

さくらインターネットのレンタルサーバ(スタンダードプラン)にPlaggerを入れたメモ。

1. % cpan
   cpan 初期設定。ユーザ領域にインストールする設定を入れる。
   • いろいろ解説サイトがあるが、ここでは LAPISLAZULI HILL#Hatena さんとこを参考に、perl Makefile.PL オプションに LIB, INSTALLMAN1DIR, INSTALLMAN3DIR を設定した
   • ミラーサーバは、どこでもいいとおもうけど、これも↑のサイトを参考に、kddilabs, cpan, nara.wide にした
   • 初期設定が終わって cpan プロンプトに戻ったら、exit で抜けて、~/.cshrc に setenv PERL5LIB ~/perl/lib を追加し、% source ~/.cshrc しとく。
2. % cpan install Bundle::CPAN
   途中の設定については、(ここより前に聞かれる項目でも)全部そのまま Enter でよい
3. % cpan install Module::Install YAML Test::Base
   この後の svn からの configure & make に必要。途中で聞かれるのは、引き続き、ぜんぶそのまま Enter
4. % svn co http://svn.bulknews.net/repos/plagger/trunk/plagger
   一度ローカルにチェックアウト(さくらにsvn入れてないので)してから、さくらサーバに scp とかで運ぶ
   • 多くのサイトにあるように % cpan test Plagger したくなるが、SVN から拾ってくるのが吉っぽい。ダラダラインストールに付き合わなくてもよくて、楽。
   • 適宜覚書はてな異本 さんとこが参考になった
5. % perl Makefile.PL
6. % make

ちなみにこの流れでも途中でいろいろ聞かれるけど、ぜんぶそのままEnterでOK。% cpan test Plagger だと数時間付き合っても、大量のエラーと依存関係解決やらの作業に悩まされたけど、この方法だとずっと速いし、失敗もなかった。make がおわったら、plagger のスクリプトができているので、

% ./plagger -v
Plagger version 0.7.17

で完了確認。お疲れさまでした。

これでも、なんか失敗してよくわかんないことになったら、最終的には ~/perl やら ~/.cpan をごっそり消せば何も無かったことにできる。いろいろ試すときの方法論の一になれば。根気良くどうぞ。

Edgy -> Feisty のアップグレードは、メニューの [システム]->[システム管理]->[アップデート・マネージャ] であっさり行けた。dist-upgrade でも OK。結構入念にバックアップを取ってあったのだが、想像以上に簡単に終わってしまい、拍子抜け。OS のバージョンアップがこんだけ簡単だとウレシイなあ。いまのところ、日本語フォント名が日本語だ、くらいしか変更点に気づけてないけど、他にもいろいろあるみたい。パフォーマンス向上も結構あるらしい。

で、そのあと、Thunderbirdも2.0を使ってみようとしたが、こちらはうまくいかない。現在未解決。(2007/05/22追記、動いた。)

そもそも、本家で配布しているバイナリがSIGSEGV吐いちゃって、そのままじゃ動かない。

で、FTPサーバからソースを引っ張ってきて自前ビルドを試みた。

configure は、幾つかパッケージの不足があったものを追加インストールした後、id:unikerさん と同じ現象が出たので、同様に $ cp mail/config/mozconfig . で解決 (_ _)。でも、結局:

こんな感じでビルドできません。たぶん、launchpadフォーラムに上がってるこのレポートと同じ症状なんだけど、この、うまく行くか、まだ分からないfirefox用パッチを解読するのが吉なのか、おとなしくSynapticでThunderbird 2.0がサポートされるのを待つべきか。

そうそう、Feisty にしてから、beryl が、ちと不安定みたい。たまにタスクバーとか、ウィンドウが真っ白になってたりする。beryl 再起動すると復帰するんだけど、これもどこかに問題があるのかな。~/.xsession-errors 見ても、それっぽいエラーは吐いてないんだけど。。

その後、手動インストールに成功している勇者を発見。

1. Download Thunderbird 2. (Save to disk)
2. sudo tar -C /opt -zxvf ~/Desktop/thunderbird-*
3. sudo ln -s /opt/thunderbird/thunderbird /usr/local/bin/thunderbird
4. create a menu item:

なんと、実行場所がまずいだけだった。thunderbird起動スクリプト中の関連ファイルが解決できていなかったとか、その辺と思われる。もうちっとちゃんと調べたら分かってたかもなあ。

1.5からの移行については、2.0の起動前に ~/.mozilla-thunderbird を ~/.thunderbird にリネーム。失敗するとかなり寒いので最初はコピーにしときましょ。その後、起動すれば、1.5の設定、メール、spamフィルタの学習もちゃんと引き継げる。よかったよかった。

さっそくタグづけも使ってみた。物理的なフォルダは撤廃。MLやprojectに応じてフィルタ処理からタグを付ける。1-9のショートカットキーは3色ボールペンのノリで [1_important] [2_so_important] [3_interesting] だけ定義。to_reply, to_read も作ったけど、使うかは微妙。

デフォルトで右上の検索ボックスでタグ検索ができないのは痛いけど、GmailUI Extension を入れれば tag:<タグ名> で検索できる。よく使うケースは検索フォルダを定義すれば、いい感じにフラットな受信ボックスで使っていけそうだ。

うむうむ、いいかんじ。

# 自宅ネットが今週末までこないので、エントリさぼってたけど、忘れないうちに書いておく。

@T’sPlaza 246。2回目の参加。今回のテーマは「メディアの今後」。前回参加したときと同様、主宰の上原さん保田さんによる、ゆるっとした感じの始まりかた。こういう感じ、好きだな〜。

今回のゲストは、紙メディアから日経新聞デジタルメディア(デジタルじゃん)の重森さん、オンラインメディアからアイティメディア(Business Media 誠)の吉岡さん、ソーシャルメディアから「ワークスタイル・メモ」「アルファブロガー」著者の徳力さん。各方面の方から、「最近どうよ」の話(略しすぎ)をうかがった。

細かいまとめは、どこかの人が丁寧にまとめてくれているだろうから、「へ〜」と思ったところと、感じたところだけを書いておく。

• 2005年度の広告費は新聞:インターネットで3:1くらい(電通調査)。… まだまだ新聞って強いんだな
• 新聞は主要6紙だけで、毎日3000万部発行。 … 改めて考えると凄い数。でもオンラインメディア(たとえばPV)と同じ尺度じゃ測れないよなあ
• 紙メディア(新聞)記者の価値観には「著作権」が根強い。「ジャーナリズムを回していく」には、まだ課題有り。(重森さん) … 「大会社みたい」「お役所仕事」と括ってしまえばそれまでだが、強い価値観はブランドに不可欠だと思う。それでこその信頼感が強みになっているわけだし
• 日経もデジタルメディアをやっているが、外部の人に記事を委託する感覚/ノウハウ/時間感覚には、まだ課題がある。(重森さん) … それって記者から見たらハードルが高いってことなのかな〜。ってことは、日経で書くってのは一種ステータスにもなりうる？？
• 新聞にもよるが、基本的には見出しだけで伝わる書き方をするのがこれまでの価値観。「？」で終わる見出しなんて無い。(重森さん) … ネット記事にありがちな煽り見出しとかダメなのね。この辺、感じたことを下に書く
• 媒体として「紙」が存在する強み、できあがるまでの何重ものフィルタ、緊張感。(重森さん) … 紙とか本とか、やっぱし刷物になってるのは重厚感/信頼感みたいなものがあるね。でも、小さい頃から慣れ親しんできた「情報を得るスタイル」に裏打ちされている部分もあるとおもう。この辺も下に書く
• 定年退職「これで明日から日経読まなくて済む！」(重森さん) … へ〜、そんなこと考えるのかなー。毎日読んでる人って、もう習慣になっちゃってて離れられなくなってるもんだとおもってた。定年過ぎても延長して働いてたりする人も多いみたいだけど、それって少数派？すぱっと生活切り替えるのかな、みんな
• オンラインメディアの強みは「速報性」「いくらでも細かく書ける(紙面制限が無い)」「蓄積性」。(吉岡さん) … 「蓄積性」は「検索性」あるいは「ライフサイクル(の長さ)」ともいえるかも
• 記者の立ち位置を明確に打ち出しやすい。どっかのプレスリリースに対し、フットワークよく書けるのも、(個人でなく)会社で組織的にやってるからこそ。でも、記者クラブに入れないなど、まだ紙と比べて取材の壁がある。(吉岡さん) … 会社でやってても、記者クラブって入れないんだ.. アイティメディア上場した今でもダメなのかな〜、いまだにそんな差があるなんて驚き
• オンラインメディアは、まだ、情報の分野が偏っている。「日経xx」みたいな紙媒体ほど、幅広い分野がカバーできてない。(吉岡さん) … なるほど、確かに「日経ロジスティクス」みたいなオンラインメディアってないな
• ソーシャルメディアは、そもそもメディアを目指していない段階からスタートする。それが人(読者)/注目を集め、次第にメディアとして機能するようになっていく。(徳力さん) … 確かに、むかし「ブログ」みたいなものが流行る前に「○○メモ」ってサイトやってたら、いつのまにか読者が付いてたな。今は畳んでしまったけど
• 誰でもメディアを意識せず始められる、障壁の低さがソーシャルメディアの強みであるが、そもそもメディアとして書いていないため、全体として信頼度が統治されていない/混在している状態が弱味でもある。(徳力さん) … 統治されているのがわかる仕組みがあるといいなあ。まえ、mixiのなかで書いたような気がするけど、ベリサインみたく、第三者の情報統治認証機関があったらどうだろう。誰がどうやって認証するのかは知らん。専門家集めるとか？
• factは比較的簡単に手に入るようになり、その先のopinionも求められるようになった。(徳力さん) … 情報の得かたの変化に伴い、情報の価値もシフトしてきているのだとおもう

上に書いた、見出し/リードの付けかたや、紙メディアが持つ信頼感について、もうすこし考察してみる。

情報の得かたの変化に伴い、メディアの価値やスタイルも変化していくものだとおもう。昨今で一日に触れられる情報量といったら膨大だ。日に2-300のFeedチェックは普通だろう。僕はメディアビジネスに疎いのでよくわからないのだが、広告費だけがメディアの生命線だとすれば、煽り見出しやリードは必要な努力なのだとおもう。紙メディアは、そもそも紙に向かっているシーンが、オンラインメディアに向かっているシーンとは別であることを考えれば、煽り見出しなんて付けず、一覧性/わかりやすさが追求されていれば良い。

ところで、僕の場合、小さい頃から触れてきたメディアといったら紙(本か雑誌かマンガか、それとも自治体や学校が発行するようなペラ紙か。新聞は大人の読みものだった)か、テレビだった。テレビに至っては超田舎だったせいで民放の電波が入らず、汚い映りのNHKくらいしか見られなかった。インターネットに触れたのは高校に入ってからだ。

ともかく、紙から情報を得ることに慣れ親しんできた僕には、それが一次情報というか、情報のすべてだったようなものだ。あとは、家族親戚や友人との話くらいか。すくなくとも、僕のなかの、刷り物に対する信頼感はここに起因する部分があるのではないかとおもう。だから、小さいうちからネットを使った情報取得に慣れ親しむことのできる社会が当たり前になっていったとき、紙メディアが持つ信頼感/ブランドが現在のまま続いていくとはおもえない。

では、メディアが持つ価値って何なんだろう。価値=信頼性なのだろうか。信頼性=正確性なのだろうか。factよりも、opinionなのだろうか。それとも、(正しいとか正しくないとかは重要ではなく、)正確でなくとも、何かを感じることができるような主張/哲学に価値があるのだろうか。

価値観もメディアのポジショニングも十人十色だとおもうけど、僕だったら、「正確でなくとも、誰か(そのコンテンツのターゲット)が、何かを感じることができるような主張」を届けるようなメディアであれば、作ってみたいかな、とはおもう。

初めてのRTCカンファレンス参加@新宿ファーストウェスト。レポートを一日遅れでアップします。非常に有意義な勉強会でした。携帯アプリ、作りたくなってきたな〜。次回もぜひ参加したいです。

会場は200名くらい入りそうな、広い会議室。受付開始直後に会場に到着できたので、さっそくEM・ONEを触らせてもらった。評価機につきガタツキがあったものの、大きさといいレスポンスといい、ちょっと使った感じの印象は「意外に悪くない」ってかんじ。それでも、過去にW-ZERO3を店頭で触ったときに感じたキーボードの使いにくさ(というか、アレでは使わない、僕は)については、印象は同じだった。あのキーボードでバリバリやってるひとっているのかな？超打ちにくいんだけど。

カンファレンスが始まり、近江商人 上原さんら主催者による挨拶と今回の主旨説明。なんとなくgdgdな始まりかただったが、コンセプトは明確に伝わってきた。キャリア、OS、ブラウザ、各レイヤのプラットフォームプレイヤが一堂に会し、これまでとこれからについて語り合う、そんなかんじ。題して「携帯プラットフォームの変化」。気がつけばモバイルの仕事に関わって今年で8年目。この手の話はドキドキしますよ。

まずは、イーモバイルのCFOエリックさんによるプレゼン＆質疑応答。HSDPA高速データ通信定額をひっさげて、13年ぶりの携帯キャリア新規参入。そうか、TuKa以来(もうKDDIか)13年ぶりにもなるのか。。
しかし、この人、熱い。ダテに3600億調達してない。これだけ自社と自社のプロダクトを楽しそうに熱く語れる人がCFOだなんて、スゲーなあ、会社も楽しそうだ。
一貫した主張は、日本の携帯料金は高い！日本はMOU 150分に対し、アメリカは同じくらいのARPUで700分！僕は、そんなに電話しないけど.. でも、確かに高い。高いのに慣れさせられてて不満を感じてないだけかもしれない。
質疑では、3600億の調達話も。イーアクセス社債発行で一次金をたてて、それで主要株主を集めた。できるだけ資本金を太らせた。そうでないと銀行が相手をしてくれない(くれなかった)とか。しかし3600億って凄すぎる。で、それを1事業に突っ込むというのも、ちょっと想像が付かない。
正直、既存キャリアを刺すのは、まだ大変そうだけど、聞いてて楽しくなる話でした。「我々はネットを開放する。どんどん遊んでくれ」というような話に、ワクワクしましたです。

続いて、jig.jpの社長 福野さん。auにPCサイトビューアが載って以来、jigブラウザ使ってなかったけど、福野さんの話は、目的も戦略も一本筋が通っていて好感が持てた。今のjigブラウザってタブ切替えできるアプリの実行環境(VM on VM)になってたんだね、知らなかった。3キャリア対応で、共通アプリがバラまける環境になってたとは、なかなか面白いぞ。課金系も整備されてるみたいだし、これ、チェックしとかねばっ。
しかし、あの場(どちらかというと開発者は少なめだったように思う)のプレゼンで、アプリのソースコード見せながら熱くなっちゃう辺は、ほんとこの人エンジニアだなー、と親近感わきました。
一方で「フルブラウザは過渡期の技術。いまだにコンテンツはPC向け中心だから、携帯がそれに合わせてるだけ。フルブラウザは不要になるかもしれない」なんて意見もさらりと。うーむ、このアイデアは新鮮な感じだが、妙に納得してしまう意見だ。
名刺交換して、高専話してきました。ロボコン、プロコン。福野さん、プロコンで、函館開催の回、全国2位だったらしい。

次にMicrosoftのモバイル系事業の偉い人 梅田さん。資料が無かったのでメモから思い出せるだけ。
モバイルのWindows(CEとかWindows Mobileとか)って、イマイチ、キてる感じは無かったんだけど、MSん中じゃ超成長事業ぽい。「苦戦されてますよね？」な質問にも「苦戦しているという感覚が無い」そうだ。「VISTAもよろしく」「Xboxもよろしく」だってw
さて、MSさんは、そもそもWindows MobileのようなOSがマッチするセグメントは限られている(最初から全体に対して成立させられるビジネスモデルでは無い)と踏んでいるようだ。その辺り、端から見て「PCをほぼ独占しているMSさんにしては」という感覚になっちゃうのかもしれない。まあ、brackberryとか無いし(始まったんだっけ)、そういう意味では、まだマーケットがぜんぜん無いという風にもとれるのかも。

最後に、周りに座ったグループで「こういうフルブラウザとかPDAぽいデータ通信端末が、クリティカルマスを超えるには？」についてディスカッション＆発表。どうも、毎回こういう流れになっているらしい。なかなか面白い企画だ。
ディスカッションは、当初どうしてもネガティブというか、懐疑的な意見に行ってしまった。が、うちのグループは、中途半端、使いにくい、もっさり、なんてキーワードが出つつ、「家でできることの延長をモバイルでやりたかったんだっけ？モバイルならではの何かが欲しいんじゃないの？」という方向へ議論が進んでいった。シンプルとエロねw。arakiさんにまとめていただきました。感謝。

よそのグループの

「携帯で新しいことができても、『凄いですね』じゃダメなんですよ。『スゲーーー』じゃないと。」

という意見が印象的だった。

終了後の飲み会は、金欠につき、出席できず。。残念だったなー。でも、次回勉強会もぜひ参加したいすね。

主催者関係者のみなさま、お疲れ様でした＆ありがとうございました (_ _)

共同主催 Windows CE FAN さんのレポートはこちら。

先日仕上がったフレームワークの、背景となった業務ドメインモデルができるまでのメモ。実は別ブログに書いてあったものを再構成しただけ。が、この再構成を酔っ払った状態でやっているので、ちょっと意味不明かも。まあ、自分用のメモということで御容赦いただきたい。今に、もっと直すかもしれません。

さて、

今の出向会社に来た当初は、業務そのものを理解できていなかったのだが、長く居るうちに全社的な業務を見渡せるようになってきた。ITアーキテクトか何かに載っていたようなシステム構成図の表現技法を見よう見まねで書いてみたら、なかなか面白い絵になった。

続けて JUDE で適当な粒度のアクティビティ図を書いてみた。(作業レベルで)共通化している部分を切り出しながら、こりこり書いていたら、全部で 15 枚弱になった。ビジネススクールで学んだバリューチェーン図に並べてみると、収益/コスト構造が一目瞭然。だいぶ見通しが良くなった気がする。

アーキテクトの先輩に相談したら、もう一段階粒度の大きい、全社的な業務アクティビティを整理することを提案された。自分の中では大きめに書いていたつもりだったが、トップダウンな視点で見るには、確かにもう一段階足りなかったようだ。
ついでに、個別機能単位の設計については、input/output の視点、具象/抽象 の視点での歩み寄りと妥結点の模索についてアドバイスを貰った。こういう的確なアドバイスが出せるようになりたい。

で、さっそく粒度の大きいアクティビティを整理し、続いて、ここからロバストネス図作成へ進めていった。ユースケースをしっかり書いておくべきだったが、当時は諸事情によりとある機能実装の見積もりを進めなければならないという状況でもあった。

状況が状況だったので、結局そのままロバストネス図を起こしてみた。なんだかそれっぽいモノができたが、さて、これをどう分析に使うものか分からない。

既存のシステムと新規案件で構築するシステムとで、どう切り分けながら、どの範囲を設計すれば良いか、その落としどころも良く分からない。端的にいえば、部分最適を優先するか、全体最適を優先するか、のトレードオフという状態だった。結局当時は、的確な決定を仰ぐところまで行き着くことができず、全体最適の志向で分析を進めていった。

余談だが、先輩エンジニアが言うに、全体の分析をしっかり進めておいた後の、その後の恩恵は非常に大きい(逆に言えば、部分最適ばかり進んでしまうと、全体の抽象化、最適化にかかる調整コストが倍以上になる)事は認識しておいたほうが良いとの事。実際にコードを書く立場になることを考えれば、確かにこれは想像に難くない。これを覚悟の上で部分的な開発を進めるのであれば、既存のシステムに一切手を付けない(後からインタフェース変換部分を作る)つもりで、完全に独立させることを意識したほうが良い、ともアドバイスを貰った。

続いて、作成した図を用いたロバストネス分析。開発対象のオブジェクトを適切な単位に分割・統合するために行う分析・設計プロセスだ。UML を使ったプロセスで言えば、ユースケースからクラス図への落とし込み .. このときの仲介作業に当たるものになる。

オージス総研の「実践ロバストネス分析」 が参考になるが、僕の解釈とは少し違う説明になっているようだ。まあ、意図するところは同じなので、細かいことはあまり気にしないことにする。

まず、先に描いてきた各アクティビティを、バウンダリ、コントロール、エンティティ単位に分割して書き下してみる。バウンダリはインタフェースに当たるもので、必ずしも画面(UI)単位ではないことに注意したい。手始めに書いてみる分には画面単位で書いてみるのが直感的で良いかもしれないが、最終的にインタフェースベースの設計をする事を考えれば画面単位で分割してしまうのは適切とはいえない。

バウンダリ、コントロール、エンティティ間の関連は方向が決まっている。

バウンダリ -> コントロール -> エンティティ
|               |                 |
v              v                 v
バウンダリ -> コントロール -> エンティティ

基本的にはこの 5 方向しかない。コントロールからバウンダリ、エンティティからコントロールへ向かう(左向きの)関連が出てくるようでは単位が適切でないということになる。そういう意味では、バウンダリ、コントロール、エンティティはそれぞれ、View, Control, Model に(大体)対応していることがわかる。「関連」を uses とか depends のような動詞と考えてみれば、幾分か描きやすくなることもわかった。

ロバストネス図が大体描けたら、いよいよ分析フェーズ。ここからクラス図へ落とすことを想定し、(殆どの場合) エンティティを一クラスに見立て、CRC カードを書いてみる。CRC とは Class, Responsibility, Collaborator の略で、一枚のカードにひとつのクラスと、そのクラスの責務、協調する(させる)クラスを書いていく。余談だが、「責務」という表現をする事は、適切なオブジェクト単位を括りだすための有効な手段だと思う。

CRC に書き出した際、一クラスの Responsibility はひとつ、Collaborator は多くても 3 つ程度になっていることが望ましいようだ。一クラスに多くの責務を負わせすぎると実装が肥大化してしまうし、協調者が多すぎるのもメンテナンス性を下げてしまう(というか、そのクラスの責務が薄れてしまう)。したがって、このような分割単位になるようであれば、ロバストネス図に立ち戻り、バウンダリ、コントロール、エンティティの単位と関連を見直し、再構成を行う。

クラスに落とす際に、有効なデザインパターンを採用するのもテクニックのひとつだが、それには有効なデザインパターンが提案できるだけの知見が必要になる。こうして、なんとなくやるべきことが見えてきた。

そんなこんなで、クラス図とロバストネス図、ユースケースの行ったり来たりと、各種デザパタの適用を繰り返していくうちに、今のドメインモデルの素案ができあがった。

今から半年前の話。いろんな会社のケースでこういうののトレーニングを積むのも面白そうだ。

以上、振り返り終わり。