<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>foursics blog</title>
    <link rel="alternate" type="text/html" href="http://blog.foursics.jp/hironobu/" />
    <link rel="self" type="application/atom+xml" href="http://blog.foursics.jp/hironobu/atom.xml" />
    <id>tag:blog.foursics.jp,2011-12-29:/hironobu//2</id>
    <updated>2011-10-24T09:08:50Z</updated>
    
    <generator uri="http://www.sixapart.com/movabletype/">Movable Type Pro 5.12</generator>

<entry>
    <title>ハマスタを貶すなら日没を待て 〜日没サスペンデッドにつき再試合〜</title>
    <link rel="alternate" type="text/html" href="http://blog.foursics.jp/hironobu/2011/10/twilight-of-npb-2.html" />
    <id>tag:blog.foursics.jp,2011:/hironobu//2.355</id>

    <published>2011-10-23T15:37:01Z</published>
    <updated>2011-10-24T09:08:50Z</updated>

    <summary> 続けてもう少し書く。 ○京急＋ミツウロコ等横浜系企業連合に勝ち目はあったのか？...</summary>
    <author>
        <name>Hironobu Koura</name>
        
    </author>
    
        <category term="sports" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://blog.foursics.jp/hironobu/">
        <![CDATA[<p>
<a href="http://blog.foursics.jp/hironobu/2011/10/twilight-of-npb.html">続けて</a>もう少し書く。
</p>

<p>
○京急＋ミツウロコ等横浜系企業連合に勝ち目はあったのか？
</p>

<p>
多分、万に一つの勝ち目も無かったかと。先般より私は「NPB＝秘密クラブ」説を唱えておりますが、球団売却およびその承認にはその性質が諸に出ます。まあ、どのような場であれ、既存プレイヤーに対する事前の根回しは大変に重要であり、その中から自らの後ろ盾になってくれそうな奴を見つけておくというのは非常に重要です。今回いろいろあったとはいえ、ある程度DeNAとTBSおよびオーナー会議も絡めて交渉の道筋が立った後での挙手というのは、どう見積もっても不利なんですよね。去年も結局話は流れたとはいえ、ノジマが参入しようとして素気無くされたのも記憶に新しいところ。
</p>

<p>
また、企業連合すなわちJVという形で参入する場合、球団会社をどのように構成するつもりなのかが一社のみによる単独保有の場合以上に問題になるんじゃないでしょうか。まあ、合弁会社として各企業からの出向社員・役員だらけで構成することもできますが、出資比率や株主構成の変更にもいちいちうるさく言ってくるNPBの監視の下、続けて行くのは容易ではないはずです。そこをもう球団企業単体でも足腰強くやって行ける経営を目指してみたいな絵図をハッタリ半分でもいいので描けていたならあるいはですが、まあ、無理筋だなと。
</p>

<p>
○無料招待席くらい、どこにでもある話じゃんね？
</p>

<p>
地域密着のためにと打った施策が時代背景の変遷によって実態にそぐわなくなる事例というのは良くある話で、これなんかもそうなんだよねと言ってしまえばそれまでなんですが。
</p>

<p>
<a href="http://blog.livedoor.jp/tbi38/archives/4436036.html">http://blog.livedoor.jp/tbi38/archives/4436036.html</a><br/>
変革!! Baystars blog : 知ってほしい。ハマスタが抱える事実
</p>

<blockquote>
横浜スタジアムは、横浜公園が国有地であること、且つ都市公園法によりプロ野球専用の球場を建設することが出来ないことから、第３セクターとして設立された㈱横浜スタジアムが球場建設後に横浜市に無料で寄付したという経緯があります。<br>
この寄付に対する見返りとして横浜市は、『公園施設の寄付に関する契約』をスタジアム側と締結。株式会社は球場施設のプロ野球興行開催の優先的使用の許可にはじまり、売店経営・広告物掲出・放映権等あらゆる権利を『４５年』間に亘って握り続けているのです。<br>
他方、㈱横浜スタジアムは球場建設費充当のため１口250万円の株を、『４５年』間プロ野球公式戦バックネット裏特別席の無料優先権を付与する形で販売。すると20億円の資金が集まったそうです。<br>
単純計算すると無料席は800席存在、過去の記事では設立後の増資分を含めると1200席あるとも言われます。<br>
文春が言うところの『永久シート』を含め、広告・物販収入が入らない本拠地使用球団が収入源の頼みの綱の入場料のうち、1000席以上をゼロで計算しなければならないというのは球団経営を逼迫させる要因にしかなりません。<br>
</blockquote>

<p>
たかだか1000席程度をタダ席扱いしなければいかんのがそんなに大事なら、収容人員4万人のビッグスワンの優に半分以上をタダ券で集めたとすらうたわれるアルビレックス新潟の立場は一体どうなるんでしょう。しかも当時は指定管理者指名もまだない「間借り」状態で条件は同じだったはずですし。
</p>

<p>
だいたい、今の横浜スタジアムの空席って1000席どころの話じゃないじゃん。
</p>

<p>
○というか
</p>

<p>
この横浜スタジアム建設時の施策をまるで悪代官のタクラミのような扱いで報じられるってつまり、地域のためによかれと思って行う取引がいつ爆弾として扱われるか分からない、って言ってるようなものなわけで。これじゃ地域密着なんておっそろしくて口にできないって話じゃないかなあ。この程度の融通の話、ホントに他球場にはないの？何がそんなに悪い話なの？これ。コレ読んで皆さん「けしからん！」ってお怒りなんですか？どこがよろしくないんでしょうか。
</p>

<p>
そしてこれは何度でも言いますが、そんっなに球場会社がおいしいところ握ってるなら尚の事ここの株買って支配権を握りましょうよって話にしかならないと思うんですけど。<a href="http://www.uforeader.com/v1/se/E04682_0070FR47_8_51.html">同業者さんなんだから話もしやすいでしょう、フジさんとテレ朝さんがそれぞれ持ってる5.74%</a>を買い取るところから始めてみたっていいんじゃないでしょうか。ねえ？
</p>

<p>
○もう椅子取りゲームは終わった
</p>

<p>
横浜を出てだいたいどこへ行くのか、アテを考えて言ってらっしゃるのか不思議な方が大勢ですが、楽天参入時に「最後の椅子」として取り上げられたのが仙台なのであって、あとはもう、NPBの本拠地としてキャパが保てるかどうか疑わしい場所ばかりですよ。
</p>

<p>
NPB、そしてMLBでも同じような傾向なんですが、プロ野球球団本拠地として選ばれているのはどこもだいたい「100万人以上」の都市・都市圏ばかりなんです。そのくらいの規模が無いと、平日三連戦の興行も含めた観客動員で安定した数字を見込めない。そして球場への安定したアクセスを確保するための交通網を整備できる余力が保てない。1,2週に一度のホームゲーム開催で済むサッカーの試合とは要求される都市機能レベルが根本的に異なるんです。これを日本で供給できる都市圏って、札仙広福レベルがギリギリ。それ以下は形の上では100万人居るけれども、といったようなところばかり。
</p>

<p>
それでなくても新潟は独立リーグ球団であるアルビレックスBCとの兼ね合いもあるし、指定管理者はアルビレックス新潟・都市緑化センターグループが持ってるし(これぞ地元球団と財団法人とのJVですよ)、ここに食い込むのもこれはこれで大変ですよ。まあ、金に物言わせてぶんどるって方法もあるかもしれませんけど、横浜スタジアムとこっちと、どちらが安いかな、という話で。静岡だって、草薙球場にプロ野球を入れるにはさらに改修が必要でその費用負担は球団にお願いする必要がっていう話ですし。ま、どこも一筋縄じゃ行きませんよ。
</p>

<p>
○あたしとあのこの、どっちをとるの？(何
</p>

<p>
結論としては、「地元密着か球団存続か」を仮に二者択一で決めなければいけないときに、後者を選ぶ声が多くの場合圧倒的に多数であるということがNPBの限界であり、そこに正面から向かい合おうとせずにただのアリバイ作りとして前者を振りかざすその姿勢って、どういうことよと。
</p>

<p>
その地元からとってみれば、(曲がりなりにも)愛してきたクラブがそこから居なくなろうかというのに、外野はそれを黙って受け入れろと迫る。その図が如何に暴力的なものなのかは、実際にこれを受ける立場にならないと分からないものかもしれません。その他大勢にとってはNPBの試合は「TVを通して」観るものでしかなく、それが何処で行われているかは知ったことじゃないわけなのです。
</p>]]>
        
    </content>
</entry>

<entry>
    <title>ハマスタを貶すなら日没を待て</title>
    <link rel="alternate" type="text/html" href="http://blog.foursics.jp/hironobu/2011/10/twilight-of-npb.html" />
    <id>tag:blog.foursics.jp,2011:/hironobu//2.354</id>

    <published>2011-10-22T15:26:39Z</published>
    <updated>2011-10-22T16:28:41Z</updated>

    <summary> この問題って、結局TBSがどこまで腰据えてNPBにコミットしているのかを測るだ...</summary>
    <author>
        <name>Hironobu Koura</name>
        
    </author>
    
        <category term="sports" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://blog.foursics.jp/hironobu/">
        <![CDATA[<p>
この問題って、結局TBSがどこまで腰据えてNPBにコミットしているのかを測るだけの意味しかなくて、ナベツネといっしょになってハマスタに向かって「きたないなさすが」とか言って拳振り上げて喜んでるような輩は一度我に帰ってそのおめでたさを心配した方がいいと思います。さもないとどこぞの球団社長みたいなことになりますよ。あ、中日ドラゴンズさんリーグ優勝おめでとうございます。
</p>

<p>
たとえば楽天が仙台入りするにあたっての宮城球場改修や広島の新球場建設に何十億が投下されたように、<strong>日常的な運営にかかるコストとは別に</strong>TBSがスタジアムおよびその周辺・地元に対して投資を行ったという話は寡聞にして全く聞いていませんし。もしそういう実績が本当はあるならそれを交渉材料にすればいいし、それがないなら尚の事、市やハマスタに対してお金も出さずに言うことだけ聞かせようというなら、どんだけ虫のいい話ですか？というだけのことでしょう。得るもの欲しけりゃコストも払えと。
</p>

<p>
<a href="http://blog.livedoor.jp/yuill/archives/51620215.html">http://blog.livedoor.jp/yuill/archives/51620215.html</a><br>
バックスクリーンの下で ～For All of Baseball Supporters～ : さらば、横浜
</p>

<p>
<a href="http://blog.livedoor.jp/tbi38/archives/4436036.html">http://blog.livedoor.jp/tbi38/archives/4436036.html</a><br/>
変革!! Baystars blog : 知ってほしい。ハマスタが抱える事実
</p>

<p>
この手の「ハマスタぼったくり」論に簡単に乗っかる人たちって、横浜スタジアム以外の球場がどのような運用になってるのか調べようともしないのかほんとに不思議なくらいですね。そんなにハマスタを好きなようにしたいなら、<strong>なぜ「株式会社横浜スタジアム」を買おうとしないんでしょう。</strong>
</p>

<p>
<a href="http://www.uforeader.com/v1/se/E04682_0070FR47_8_51.html">http://www.uforeader.com/v1/se/E04682_0070FR47_8_51.html</a><br/>
株式会社　横浜スタジアム - 大株主の状況 (娯楽業) - 有価証券報告書を閲覧・検索するなら有報リーダー
</p>

<p>
「ハマスタをボールパーク化する」ために球場会社(=株式会社横浜スタジアム)と球団会社(=株式会社横浜ベイスターズおよびTBS)が手を取り合いましょう、って話で、ディールとしては普通に事業提携か、それで足りないなら企業買収して同一グループ化しましょう、って話の進め方すればいいはずなのに、なぜそういう話にならないのかさっぱり理解できない。「(NPB球団は)球場施設の管理・運営権の受託を目指している。」と言うなら、<strong>既にその権利を持ってる会社を買えばいいじゃん</strong>と。現にオリックスは株式会社大阪シティドームに対してそれをやっている。(経営再建中という有利な状況があったからとはいえ)
</p>

<p>
<a href="http://ja.wikipedia.org/wiki/大阪シティドーム">http://ja.wikipedia.org/wiki/大阪シティドーム</a><br>
大阪シティドーム - Wikipedia
</p>

<p>
<a href="http://ja.wikinews.org/wiki/大阪ドーム、オリックスが買収へ">http://ja.wikinews.org/wiki/大阪ドーム、オリックスが買収へ</a><br/>
大阪ドーム、オリックスが買収へ - ウィキニュース
</p>

<p>
もちろん一口に株式会社と言っても、それぞれの社の事情や設立経緯などいろいろあり、買収するにもすんなり行かないことだってあります。が、ダメならダメでそこを取り上げばいい話。そこでやっと「ハマスタがこっちの交渉に乗ってくれない」という話をすればいい訳です。やれ市とスタジアムの癒着だとか黒い噂だとかいう話にしたいなら、そういう交渉を吹っかけてきっちりと状況を整えてから思いきりやればよろしい。
</p>

<p>
いずれにしろ、どのような交渉が球場会社と球団会社の間にあったのか知りませんが、ここまでのTBSの球団経営へのコミットのしかたを振り返るに、<strong>球団存続のための最低限のことくらいしかしてないんじゃないかあんたたち？</strong>という疑念しか浮かばない訳でして。
</p>

<p>
<a href="http://www.uforeader.com/v1/se/E04682_S00087UM_14_24.html">http://www.uforeader.com/v1/se/E04682_S00087UM_14_24.html</a><br/>
株式会社　横浜スタジアム - 事業の種類別セグメント情報 (娯楽業) - 有価証券報告書を閲覧・検索するなら有報リーダー
</p>

<p>
ざっと眺められる限りにおいてのデータですが、どこも概ね年間10億前後の球場使用料を支払っているというデータが出てきます。中日や巨人、ソフトバンクなどにおいては数十億単位とも。一方で横浜スタジアムは7.8億(2010年度)。この額が妥当かどうか。さらに広告収入等球団分配金は約2.8億(同)。これらの収支が他の球団・球場のケースと比べてどうなのか。こういった一つ一つの数字を基準にしないと、できる話もできなくなってしまいます。それと、「間借り」が悪いならヤクルトだって同じ事例になるわけですが、こっちには問題がないのかどうなのか。そこを踏まえずに横浜だけ取り上げてどうこう言ってしまうあたりに、おめでたさばかりがつのります。
</p>

<p>
球団経営がそうであるように、球場経営だってタダじゃできない。人的にも金銭的にも必要なリソースがあり、それらを負担して初めてその取り分を主張できるわけです。現状球場会社がそれらを全て負担しているおかげで他より安めの球場使用料で済んでいるというだけのことだったりはしませんか？もし広告・物販収入の配分を変えて球団会社にもより多く取り分が行くようにする代わりに、人を出してくれとか、あれやこれややってくれ、みたいな話になったときに、球団およびTBSにそれに対応するだけの態勢やコスト余力あるんですか？大丈夫ですか？カネもヒトも出さない、けど利益は寄越せ、という交渉だとしたらあまりにあんまりではないですかね。
</p>

<p>
その上で、横浜に残って続ける場合の収支と、外に出て行って球場を自前でゼロから作る、あるいは既存のところに入るといった場合とそれぞれ比較し、最適なオプションを選択すればいいだけのことでしょう。それで儲かる、そういうアテがある、っていうなら幾らでもどうぞと思います。しかしどうでもいいところで「ハマスタはがめつい」と騒ぎに騒いで煽りに煽って、勢い良く飛び出そうたってどこに行こうというんでしょう。大方行った先で変な業者にうんこつかまされるか、もっとがめつい業者にシリの毛まで抜かされる事態になるかのどっちかでは。まあ、シリの毛抜かれるのが気持ちいいって人もいるかもしれないなあ。
</p>

<p>
ちなみに、TBSがベイスターズを横浜から出すなと主張する根拠が「TBSがハマスタの株主だから」と真剣に言ってる奴が居てコーヒー吹きました。おめでたさもここまで来るといよいよ盆と暮れの区別すら付かなそうな。ていうか、そんな関係性がTBSと球場会社の間にあるのなら、TBSからハマスタに「もっとベイスターズのために働けよゴラ」って<strong>プレッシャーをかければそれだけで済む話になっちゃう</strong>と思います。大丈夫なんでしょうか。
</p>

<p>
<a href="http://blog.livedoor.jp/nanjhogei/archives/5148672.html">http://blog.livedoor.jp/nanjhogei/archives/5148672.html</a><br/>
"当確"でございます！！ : 横浜スタジアム社長が激怒！！！
</p>]]>
        
    </content>
</entry>

<entry>
    <title>サーバPC運用にちょっと長めのHDMIケーブルがあると生きていけそうだ。</title>
    <link rel="alternate" type="text/html" href="http://blog.foursics.jp/hironobu/2011/06/hdmi-cable-for-home-server-pc.html" />
    <id>tag:blog.foursics.jp,2011:/hironobu//2.345</id>

    <published>2011-06-24T14:52:10Z</published>
    <updated>2011-06-24T15:27:37Z</updated>

    <summary> つい先日まで自宅のサーバPC用にディスプレイを用意してたんだけど、あまりに使う...</summary>
    <author>
        <name>Hironobu Koura</name>
        
    </author>
    
        <category term="comp" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://blog.foursics.jp/hironobu/">
        <![CDATA[<p>
つい先日まで自宅のサーバPC用にディスプレイを用意してたんだけど、あまりに使う局面がなさすぎて手放した。そしたら急にマシントラブルに見舞われるという何とかの法則並みの展開がついさっき起こった。
</p>

<p>
何でそんな馬鹿なことになってんの、とこれだけだと自分でも思うが、最近のPC(というかマザボ)はDVI+HDMI出力、でVGAなしという構成が一般的になってきているので、VGAしか受けられなかった以前のディスプレイだとそもそも繋がらなくなるので、代わりのディスプレイを探そうってことになってたわけで。
</p>

<p>
ただ何ぶん代わりのディスプレイを仕入れる前のトラブル発生だったのでだいぶテンパってしまったが、このHDMI端子を思い出して、テレビとHDDレコーダにつなげてある奴をひっぺがしてPCをテレビにつなげてみたら、何事も無かったように表示してくれて無事にトラブルシュートできた。
</p>

<table  border="0" cellpadding="5"><tr><td colspan="2"><a href="http://www.amazon.co.jp/PLANEX-%E3%83%8F%E3%82%A4%E3%82%B9%E3%83%94%E3%83%BC%E3%83%89HDMI-Ver1-4%E3%82%B1%E3%83%BC%E3%83%96%E3%83%AB-Xbox360%E5%AF%BE%E5%BF%9C-PL-HDMI02/dp/B000T6XR0K%3FSubscriptionId%3D15SMZCTB9V8NGR2TW082%26tag%3Dhironobu-22%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3DB000T6XR0K" target="_top">PLANEX ハイスピードHDMI Ver1.4ケーブル 2m (PS3/Xbox360対応) PL-HDMI02</a><img src="http://www.assoc-amazon.jp/e/ir?t=hironobu-22&l=ur2&o=9" width="1" height="1" style="border: none;" alt="" /></td></tr><tr><td valign="top"><a href="http://www.amazon.co.jp/PLANEX-%E3%83%8F%E3%82%A4%E3%82%B9%E3%83%94%E3%83%BC%E3%83%89HDMI-Ver1-4%E3%82%B1%E3%83%BC%E3%83%96%E3%83%AB-Xbox360%E5%AF%BE%E5%BF%9C-PL-HDMI02/dp/B000T6XR0K%3FSubscriptionId%3D15SMZCTB9V8NGR2TW082%26tag%3Dhironobu-22%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3DB000T6XR0K" target="_top"><img src="http://ecx.images-amazon.com/images/I/31n1r51mKqL._SL160_.jpg" border="0" alt="PLANEX ハイスピードHDMI Ver1.4ケーブル 2m (PS3/Xbox360対応) PL-HDMI02" /></a></td><td valign="top"><font size="-1"><br />プラネックス  2007-07-26<br />売り上げランキング : 24<br /><br /><br /><a href="http://www.amazon.co.jp/PLANEX-%E3%83%8F%E3%82%A4%E3%82%B9%E3%83%94%E3%83%BC%E3%83%89HDMI-Ver1-4%E3%82%B1%E3%83%BC%E3%83%96%E3%83%AB-Xbox360%E5%AF%BE%E5%BF%9C-PL-HDMI02/dp/B000T6XR0K%3FSubscriptionId%3D15SMZCTB9V8NGR2TW082%26tag%3Dhironobu-22%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3DB000T6XR0K" target="_top">Amazonで詳しく見る</a></font><font size="-2"> by <a href="http://www.goodpic.com/mt/aws/index.html" >G-Tools</a></font></td></tr></table>

<p>
今回使ったのはケーブル長1mくらいだったのでかなり取り回しで難儀したけど、3mなり5mくらいあれば、普段つないでおく用事はないけど何かあった時にビデオ出力がほしい、みたいなサーバPC用途には全く問題がなさそうだ。これからの時代、サーバPC向けにちょっと長めのHDMIケーブルはオススメですな。
</p>]]>
        
    </content>
</entry>

<entry>
    <title>ドコモ版iPhoneは出ない たぶん出ないと思う 出ないんじゃないかな</title>
    <link rel="alternate" type="text/html" href="http://blog.foursics.jp/hironobu/2011/06/maybe-goodbye-docomo-and-apple.html" />
    <id>tag:blog.foursics.jp,2011:/hironobu//2.344</id>

    <published>2011-06-18T02:58:03Z</published>
    <updated>2011-06-18T03:58:26Z</updated>

    <summary> まちょっと覚悟は(ry なんてことをドコモ社長が株主総会でコメントした件で、ニ...</summary>
    <author>
        <name>Hironobu Koura</name>
        
    </author>
    
        <category term="social" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://blog.foursics.jp/hironobu/">
        <![CDATA[<p>
まちょっと覚悟は(ry
</p>

<p>
なんてことをドコモ社長が株主総会でコメントした件で、ニュースサイトがにぎやかしく「ドコモ、iPhoneを断念」との報が駆け巡った昨日17日ですが。
</p>

<p>
まず最初に、この株主総会中にドコモ首脳部である山田社長・辻村副社長両名がドコモ版iPhone発売の可能性ありやなしやを問われて曰く、
</p>

<blockquote>
<p>
iPhoneの販売について、辻村清行代表取締役副社長が回答。「アップルが発売しているiPhoneやiPadは、世界的に売れており、ユーザーインターフェイスに優れた端末だと認識している」と前置きしながらも、「NTTドコモは、iPhoneを発売する予定はない」と断言した。
</p>

<p>
　その理由として辻村副社長は、「ドコモには、約5000万人のiモード利用者がいるが、おサイフケータイ、iチャネル、iコンシェルといった機能をスマートフォンでも利用したいというユーザーが多い。ドコモにとって、いかにこれを広げていくかが大事である。しかしアップルの場合は、この機能を加えることができない。一方で、Androidを搭載したスマートフォンは、既存のiモードサービスを乗せることができる。5000万人のiモードユーザーが、気持ちよくスマートフォンを使っていただくために、ドコモはAndroidをベースにやっていく」と語った。
</p>

<p>
<a href="http://k-tai.impress.co.jp/docs/news/20110617_453942.html">http://k-tai.impress.co.jp/docs/news/20110617_453942.html</a><br>
NTTドコモ、株主総会で「iPhoneの発売はない」と断言 - ケータイ Watch
</p>
</blockquote>

<p>
「発売する予定はない」のはずっと前からだし、その意味では従来の見解を繰り返したと見てよいコメントだが、折に触れてドコモはiPhone/iPad発売に向けた意気込みを公言し隠そうとすらしなかったように、発売に向けた<b>見込みは厳しいが意欲はある</b>という姿勢を崩してはいなかった。
</p>

<p>
<a href="http://k-tai.impress.co.jp/docs/news/20090730_306024.html">http://k-tai.impress.co.jp/docs/news/20090730_306024.html</a><br>
ドコモ、第1四半期減収減益も計画進捗は順調 - ケータイ Watch
</p>

<p>
すなわち、この従来の姿勢から一見踏み込んだように見えるこのコメントをどう解釈するかがポイントになるのだが、
</p>

<p>
<a href="http://www.nikkei.com/tech/personal/article/g=96958A88889DE3E2E4E4EBE7E2E2E2EAE2E5E0E2E3E2E2E2E2E2E2E2%3Bp=9694E3EAE3E0E0E2E2EBE0E4E2E6">http://www.nikkei.com/tech/personal/article/g=96958A88889DE3E2E4E4EBE7E2E2E2EAE2E5E0E2E3E2E2E2E2E2E2E2%3Bp=9694E3EAE3E0E0E2E2EBE0E4E2E6</a><br>
アップル「iPad」にＮＴＴドコモがラブコールを贈る理由　　：日本経済新聞
</p>

<p>
この日経記事のライターである石川温氏(<a href="http://twitter.com/iskw226/">@iskw226</a>)のツイートが今回の株主総会での社長発言を伝える一次ソース(の一つ)として広まっていったようである。
</p>

<!-- http://twitter.com/#!/iskw226/status/81542453592731648 --> <style type='text/css'>.bbpBox81542453592731648 {background:url(http://a1.twimg.com/images/themes/theme4/bg.gif) #0099B9;padding:20px;} p.bbpTweet{background:#fff;padding:10px 12px 10px 12px;margin:0;min-height:48px;color:#000;font-size:18px !important;line-height:22px;-moz-border-radius:5px;-webkit-border-radius:5px} p.bbpTweet span.metadata{display:block;width:100%;clear:both;margin-top:8px;padding-top:12px;height:40px;border-top:1px solid #fff;border-top:1px solid #e6e6e6} p.bbpTweet span.metadata span.author{line-height:19px} p.bbpTweet span.metadata span.author img{float:left;margin:0 7px 0 0px;width:38px;height:38px} p.bbpTweet a:hover{text-decoration:underline}p.bbpTweet span.timestamp{font-size:12px;display:block}</style> <div class='bbpBox81542453592731648'><p class='bbpTweet'>株主からの質問「ドコモからiPhoneを発売するのか？」。ドコモ辻村副社長「iモードユーザーがスマートフォンに移行している。5000万のiモードユーザーが気持ちよくスマートフォンを使ってもらうためにはAndroidになる。iPhoneを導入する予定はない」<span class='timestamp'><a title='Fri Jun 17 02:03:30 +0000 2011' href='http://twitter.com/#!/iskw226/status/81542453592731648'>less than a minute ago</a> via <a href="http://www.echofon.com/" rel="nofollow">Echofon</a> <a href='http://twitter.com/intent/favorite?tweet_id=81542453592731648'><img src='http://si0.twimg.com/images/dev/cms/intents/icons/favorite.png' /> Favorite</a> <a href='http://twitter.com/intent/retweet?tweet_id=81542453592731648'><img src='http://si0.twimg.com/images/dev/cms/intents/icons/retweet.png' /> Retweet</a> <a href='http://twitter.com/intent/tweet?in_reply_to=81542453592731648'><img src='http://si0.twimg.com/images/dev/cms/intents/icons/reply.png' /> Reply</a></span><span class='metadata'><span class='author'><a href='http://twitter.com/iskw226'><img src='http://a0.twimg.com/profile_images/195679494/ishikawa004_normal.jpg' /></a><strong><a href='http://twitter.com/iskw226'>石川 温</a></strong><br/>iskw226</span></span></p></div> <!-- end of tweet -->

<p>
続けて石川氏は<a href="http://twitter.com/#!/iskw226/status/81557950052831232">「アップルとの交渉は打ち切られたのでは」</a>との見解を発している。これは推測だが、<b>その場の語調としては</b>確かにドコモが断念したかのような、そう思わせるような何かがあったものかもしれない。
</p>

<p>
ちなみにこれを受けてと思われる、同じく総会に臨席していたライターの石野純也(<a href="http://twitter.com/june_ya">@june_ya</a>)氏がこのようなコメントをのせている。
</p>

<!-- http://twitter.com/#!/june_ya/status/81542242103336960 --> <style type='text/css'>.bbpBox81542242103336960 {background:url(http://a1.twimg.com/images/themes/theme5/bg.gif) #352726;padding:20px;} p.bbpTweet{background:#fff;padding:10px 12px 10px 12px;margin:0;min-height:48px;color:#000;font-size:18px !important;line-height:22px;-moz-border-radius:5px;-webkit-border-radius:5px} p.bbpTweet span.metadata{display:block;width:100%;clear:both;margin-top:8px;padding-top:12px;height:40px;border-top:1px solid #fff;border-top:1px solid #e6e6e6} p.bbpTweet span.metadata span.author{line-height:19px} p.bbpTweet span.metadata span.author img{float:left;margin:0 7px 0 0px;width:38px;height:38px} p.bbpTweet a:hover{text-decoration:underline}p.bbpTweet span.timestamp{font-size:12px;display:block}</style> <div class='bbpBox81542242103336960'><p class='bbpTweet'>ドコモ辻村氏、現在のところiPhoneを販売する予定はない。ここまで言い切ったのは初めてかな。<span class='timestamp'><a title='Fri Jun 17 02:02:40 +0000 2011' href='http://twitter.com/#!/june_ya/status/81542242103336960'>less than a minute ago</a> via <a href="http://twicca.r246.jp/" rel="nofollow">twicca</a> <a href='http://twitter.com/intent/favorite?tweet_id=81542242103336960'><img src='http://si0.twimg.com/images/dev/cms/intents/icons/favorite.png' /> Favorite</a> <a href='http://twitter.com/intent/retweet?tweet_id=81542242103336960'><img src='http://si0.twimg.com/images/dev/cms/intents/icons/retweet.png' /> Retweet</a> <a href='http://twitter.com/intent/tweet?in_reply_to=81542242103336960'><img src='http://si0.twimg.com/images/dev/cms/intents/icons/reply.png' /> Reply</a></span><span class='metadata'><span class='author'><a href='http://twitter.com/june_ya'><img src='http://a1.twimg.com/profile_images/1375941615/DSC_0221_normal.jpg' /></a><strong><a href='http://twitter.com/june_ya'>Junya ISHINO/石野純也</a></strong><br/>june_ya</span></span></p></div> <!-- end of tweet -->

<p>
「ここまで言い切ったのは初めて」と、彼もそのように述べている。やはりそこの「ニュアンス」はこれまでとやや違うことを感じ取ったようだ。
</p>

<p>
この後、gigazineを皮切りに、速報系ブログからwebニュース、個人まとめブログなど、サイト硬軟を問わず様々な場でこの一件がやり取りされることになる。
</p>

<p>
その後石川氏は追加取材を行った。「iPhoneを導入する予定はない」としたコメントのウラを取りに行ったものと思われる。「ニュアンス」だけで判断することの危険性を考えれば当然の行動だ。するとここではほぼ否定のコメント、すなわち<b>見込みは厳しいが意欲はある</b>姿勢は継続したままであることを引き出したのである。
</p>

<!-- https://twitter.com/#!/iskw226/status/81670311929577472 --> <style type='text/css'>.bbpBox81670311929577472 {background:url(http://a1.twimg.com/images/themes/theme4/bg.gif) #0099B9;padding:20px;} p.bbpTweet{background:#fff;padding:10px 12px 10px 12px;margin:0;min-height:48px;color:#000;font-size:18px !important;line-height:22px;-moz-border-radius:5px;-webkit-border-radius:5px} p.bbpTweet span.metadata{display:block;width:100%;clear:both;margin-top:8px;padding-top:12px;height:40px;border-top:1px solid #fff;border-top:1px solid #e6e6e6} p.bbpTweet span.metadata span.author{line-height:19px} p.bbpTweet span.metadata span.author img{float:left;margin:0 7px 0 0px;width:38px;height:38px} p.bbpTweet a:hover{text-decoration:underline}p.bbpTweet span.timestamp{font-size:12px;display:block}</style> <div class='bbpBox81670311929577472'><p class='bbpTweet'>ドコモ株主総会での「iPhoneの導入はない」発言について、先ほど、山田社長、辻村副社長に聞いてみました。すると「"現時点"という言葉が抜けていた」（辻村副社長）、「スタンスは従来と変わっていない」（山田社長）とのことでした。<span class='timestamp'><a title='Fri Jun 17 10:31:34 +0000 2011' href='https://twitter.com/#!/iskw226/status/81670311929577472'>less than a minute ago</a> via <a href="http://www.echofon.com/" rel="nofollow">Echofon</a> <a href='http://twitter.com/intent/favorite?tweet_id=81670311929577472'><img src='http://si0.twimg.com/images/dev/cms/intents/icons/favorite.png' /> Favorite</a> <a href='http://twitter.com/intent/retweet?tweet_id=81670311929577472'><img src='http://si0.twimg.com/images/dev/cms/intents/icons/retweet.png' /> Retweet</a> <a href='http://twitter.com/intent/tweet?in_reply_to=81670311929577472'><img src='http://si0.twimg.com/images/dev/cms/intents/icons/reply.png' /> Reply</a></span><span class='metadata'><span class='author'><a href='http://twitter.com/iskw226'><img src='http://a0.twimg.com/profile_images/195679494/ishikawa004_normal.jpg' /></a><strong><a href='http://twitter.com/iskw226'>石川 温</a></strong><br/>iskw226</span></span></p></div> <!-- end of tweet -->

<p>
もともとドコモとしてもこの交渉がかなりの難事業であることは認めていて、勝ち目のうすいことはハナから覚悟していた節はある。というか、<a href="http://itpro.nikkeibp.co.jp/article/NEWS/20080613/308041/">外部からの伝聞を元に意思決定しているようなことを口外してはばからず</a>、それをもとに一喜一憂揺れ動く乙女心に様式美を漂わせつつあったところで、「負け戦」の覚悟が無ければただいいだけ踊らされた阿呆だったわけであります。そもそも「ノーコメント」で通して良かったところを無駄に口を開けてしまって墓穴を掘り続け、招かなくても良い展開を自ら呼び込んでしまったのであって、このドコモ首脳部の一貫した口の軽さと認識の甘さは、どうあがいても失敗の誹りを免れないだろう。
</p>

<p>
しかし今回の件より深刻なのは、この報道を扱った各種メディアの姿勢である。twitterの普及は、従来以上に情報のリアルタイム性を増すこととなった。今我々は、「これは」と思わせる事象は即座に取り出され、全世界に発信されてしまう社会を迎えている。しかし事象には必ず文脈があり、類似する並行事例がある。そこに基づいて正当な価値を付加し、正誤や軽重を判断し流通可能な「情報」として加工するためにどうしても必要な「時間」と「手間」がある。今回、この一件においてそれらが全く機能せず、最初の精査どころか「現時点では」すらそぎ落とされ、「ドコモが正式にiPhoneを断念した」とされてしまった。内容としては全く従来と変わらなかったのに、である。
</p>

<p>
こうしたコメントのニュアンスを十分にコントロールできなかったドコモ首脳部の失敗性向は終始一貫しており、その点で批判を免れ得ないことは何度でも重ねて指摘しておく。しかしその一方、事象を情報へと精錬する過程の間にかなりの予断と憶測と期待(おそらく、<b>「ドコモがiPhoneを諦めてくれたほうがいい」と考える人は相当に多かったものと思われる</b>)が入り込み、<strong>最終的に判断できる状態になる前に「本来の意図とは180度異なる」情報が出回ってしまった</strong>ことへは、より深刻な認識が必要ではないだろうか。おそらく未決事項の秘匿性をことのほか重要視するAppleのこと、このような交渉下手を繰り返すドコモをこれ以上相手にすることはないだろうとする見立てには十分すぎるほどの合理性があろうし、これにより決定的かつ最終的に、iPhone導入の道筋は絶たれたとしても不思議はない。そしてその場合、ドコモに引導を渡したのはニュースメディアということになるわけだから。
</p>

<p>
もしこれでも「なぁに、ドコモからiPhoneなんて出っこないんだし、結果として同じことじゃないか」と言う向きがあるかもしれない。結果として同じなら報道内容が異なってもかまわない？そうか。ありもしない事実をでっち上げられ、結果としてその方向に向かわされることで、立ち会わなくても良かったはずの災厄を招いた事例がどれだけあったか、それらは全く大したことがないか。そうか。
</p>]]>
        
    </content>
</entry>

<entry>
    <title>Core Foundationを知る / CFHostでエラーハンドリング</title>
    <link rel="alternate" type="text/html" href="http://blog.foursics.jp/hironobu/2011/05/core-foundation-cfhost-error-handling.html" />
    <id>tag:blog.foursics.jp,2011:/hironobu//2.342</id>

    <published>2011-05-24T11:39:33Z</published>
    <updated>2011-05-24T17:46:55Z</updated>

    <summary> さて、プログラミングは正常系ばかりではだめで、エラーもちゃんと扱えるようにしと...</summary>
    <author>
        <name>Hironobu Koura</name>
        
    </author>
    
        <category term="mac" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://blog.foursics.jp/hironobu/">
        <![CDATA[<p>
さて、プログラミングは正常系ばかりではだめで、エラーもちゃんと扱えるようにしとかないといけない。とりわけネットワークプログラミングについては特にそれが言えるんじゃないでしょうか。並のPCでも最近は潤沢なメモリ事情を拝啓にすれば、malloc()がNULLを返すことはそうそう無いと看做すことはできても(でも危険だよ！)、それにくらべればネットワークは格段に不確実であり、名前が引けなかったり、TCPコネクションが確立できなかったりすることは普通にある。正常系以上にエラー系におけるAPIの挙動はぜひ把握しておきたい。
</p>

<p>
前のエントリまででCFHostを非同期による解決例を追ったので、それに続けて話を進めてみます。
</p>

<p>
○ネットワークが無効な場合<br>
○DNSサーバが応答しない場合
</p>

<p>
上記2例については、いずれの場合もコールバック関数(CFHostClientCallBack)の呼び出しにエラー(CFStreamError)を渡される。具体的には、CFStreamErrorのdomainフィールドに12(kCFStreamErrorDomainNetDB)、errorフィールドに8(EAI_NONAME)が与えられた状態でのコールバックとなる。
</p>

<p>
domainがkCFStreamErrorDomainNetDBだった場合、errorコードは/usr/include/netdb.hに定義されている通りであるとはCFHost Referenceに書かれてある通りなのだが、当のnetdb.hを読んでみるとEAI_XXX、すなわちgetaddrinfo()のエラーコードが定義されているのみである。つまるところ、CFHostの下位レイヤーではgetaddrinfo()が使われ、そのエラーコードがCFStreamErrorに設定されてコールバックされるということなのだろう。
</p>

<p>
<a href="http://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFHostRef/Reference/reference.html%23//apple_ref/doc/uid/TP40003333-CH6-DontLinkElementID_2">http://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFHostRef/Reference/reference.html%23//apple_ref/doc/uid/TP40003333-CH6-DontLinkElementID_2</a><br/>
CFHost Reference
</p>

<p>
○存在しない名前を引いた場合
</p>

<p>
DNS的に言えばNXDOMAINだったときの話。この時も、コールバックで受け取るパラメータとしては上記2項と同じであり、domain = 12およびerror = 8が設定されたCFStreamError構造体が渡されることになる。EAI_NONAMEの意味からすればそのとおりではあるのだけれども、上記二つと区別がつかないというのは何となく納得が行かない気も、しないでもない。まあ、区別をつけたくば他の方法を使えということなのだろう。
</p>

<p>
○CFHostGetAddresses()の第二引数(Boolean *hasBeenResolved)について
</p>

<p>
上記"CFHost Reference"にあるように、CFHostGetAddresses()は名前解決の完了したCFHostオブジェクトを第一引数に持ち、名前解決を済ませたことによって得られたsockaddr構造体を生のバイト列としてCFDataオブジェクトにし、それをCFArray配列オブジェクトとして返すという仕様の関数である。
</p>

<p>
ただし、前述のようにいくつかの要因によって名前解決が出来なかった場合もあり、その際にはエラーコード指定の上でCFHostClientCallBack関数が呼び出される訳だが、そのエラー発生時のコールバック発生後にCFHostGetAddresses()関数を使うと、第二引数hasBeenResolvedは、名前解決ができたできないに関わらずTRUEが与えられるらしい点に注意せねばいけない模様。つまり、名前解決ができたかどうかはこの第二引数から得られる値で確かめることはできず、もっぱら返値が非NULL(何らかのCFArrayオブジェクト)かどうかでしか分からないらしい、ということである。
</p>

<p>
挙動から見る限りは、この第二引数は単にコールバック関数が呼ばれたかどうか、すなわち「名前解決の処理がおわったかどうか」だけを見ることができる、と看做したほうが自然なようである。
</p>]]>
        
    </content>
</entry>

<entry>
    <title>Core Foundation Hacks / iPhoneでも同じように動くのか？</title>
    <link rel="alternate" type="text/html" href="http://blog.foursics.jp/hironobu/2011/05/core-foundation-hacks-also-on-iphone.html" />
    <id>tag:blog.foursics.jp,2011:/hironobu//2.341</id>

    <published>2011-05-16T16:08:23Z</published>
    <updated>2011-05-16T16:14:12Z</updated>

    <summary> さて、ここまでやってきた内容はMacOSX上の話にてございました(しかもSno...</summary>
    <author>
        <name>Hironobu Koura</name>
        
    </author>
    
        <category term="mac" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://blog.foursics.jp/hironobu/">
        <![CDATA[<p>
さて、ここまでやってきた内容はMacOSX上の話にてございました(しかもSnow Leopard)。これがiOS上でも同じように挙動するかどうかも追っておきたい。
</p>

<p>
一応、MacOSX/iOS間で(ある程度)共通の環境基盤ということで用意されている以上、挙動がMacとiPhone/iPadとで食い違ったりしてたら嫌じゃんと。適宜こうした差異があるんだかないんだかというのは自分の目で確かめておきたいものでありまして。
</p>

<p>
下記の実装によって、MacOSXでの動作と同様にデフォルトではaccept()されたサーバ側ソケットがCFReadStreamClose()/CFWriteStreamClose()の呼び出しの際に同時にはcloseされず、kCFStreamPropertyShouldCloseNativeSocketプロパティをTRUE(kCFBooleanTrue)に設定することで同時closeとなるよう挙動を変更できることが確認できました。よろしければ皆様もご確認くださいませ。
</p>

<pre class="brush: objc">
#import &lt;UIKit/UIKit.h&gt;

@interface iPhoneSocketServerAppDelegate : NSObject &lt;UIApplicationDelegate, NSStreamDelegate&gt; {
    CFSocketRef _socket;
}

@property (nonatomic, retain) IBOutlet UIWindow *window;

@property (nonatomic, retain) IBOutlet UINavigationController *navigationController;

@end

</pre>

<pre class="brush: objc">
#import "iPhoneSocketServerAppDelegate.h"

#include &lt;sys/socket.h&gt;
#include &lt;arpa/inet.h&gt;


@implementation iPhoneSocketServerAppDelegate


- (void)stream:(NSStream *)aStream handleEvent:(NSStreamEvent)eventCode
{
    NSLog(@"stream = %@, eventCode = %u", aStream, eventCode);
    
    switch (eventCode) {
        case NSStreamEventOpenCompleted:
            NSLog(@"open completed");
            [aStream close];
            [aStream removeFromRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
            [aStream release];
            break;
            
        case NSStreamEventHasBytesAvailable:
            [aStream close];
            [aStream removeFromRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
            [aStream release];
            break;
    }
}

- (void)setupInputStream:(NSInputStream*)instream
{
    [instream setDelegate:self];
    [instream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
    [instream open];
}

- (void)setupOutputStream:(NSOutputStream*)outstream
{
    [outstream setDelegate:self];
    [outstream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
    [outstream open];
}


static void
_server_socket_callback_2(CFSocketRef s, CFSocketCallBackType type, CFDataRef address, const void* data, void* info)
{
    CFSocketNativeHandle handle = *(CFSocketNativeHandle*)data;
    iPhoneSocketServerAppDelegate* appdele = (iPhoneSocketServerAppDelegate*)info;
    
    NSLog(@"accepted. (s = %p)", s);
    NSLog(@"handle = %d", handle);
    
    CFReadStreamRef readStream = NULL;
    CFWriteStreamRef writeStream = NULL;
    
    CFStreamCreatePairWithSocket(kCFAllocatorDefault, handle, &readStream, &writeStream);
    
    CFReadStreamSetProperty(readStream, kCFStreamPropertyShouldCloseNativeSocket, kCFBooleanTrue);
    CFWriteStreamSetProperty(writeStream, kCFStreamPropertyShouldCloseNativeSocket, kCFBooleanTrue);
    
    [appdele setupInputStream:(NSInputStream*)readStream];
    [appdele setupOutputStream:(NSOutputStream*)writeStream];
    
    NSLog(@"readStream = %p, writeStream = %p", readStream, writeStream);
}

- (void)doServer
{
    CFSocketContext context = { 0, self, NULL, NULL, NULL };
    CFSocketRef socket = CFSocketCreate(kCFAllocatorDefault, PF_INET, SOCK_STREAM, 0, kCFSocketAcceptCallBack, _server_socket_callback_2, &context);
    
    int yes = 1;
    setsockopt(CFSocketGetNative(socket), SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes));
    
    struct sockaddr_in sin;
    memset(&sin, 0, sizeof(sin));
    sin.sin_family = AF_INET;
    sin.sin_addr.s_addr = INADDR_ANY;
    sin.sin_port = htons(8888);
    sin.sin_len = sizeof(struct sockaddr_in);
    
    CFDataRef data = CFDataCreate(kCFAllocatorDefault, (UInt8*)&sin, sizeof(sin));
    CFSocketSetAddress(socket, data);
    CFRelease(data);
    
    CFRunLoopSourceRef source = CFSocketCreateRunLoopSource(kCFAllocatorDefault, socket, 0);
    CFRunLoopAddSource(CFRunLoopGetCurrent(), source, kCFRunLoopCommonModes);
    CFRelease(source);
    
    NSLog(@"socket = %p", socket);
}

@synthesize window=_window;

@synthesize navigationController=_navigationController;

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    // Override point for customization after application launch.
    // Add the navigation controller's view to the window and display.
    self.window.rootViewController = self.navigationController;
    [self.window makeKeyAndVisible];
    
    [self doServer];
    return YES;
}

- (void)dealloc
{
    [_window release];
    [_navigationController release];
    
    CFSocketInvalidate(_socket);
    CFRelease(_socket);
    _socket = nil;
    [super dealloc];
}

</pre>

<script type="text/javascript">
SyntaxHighlighter.all();
</script>]]>
        
    </content>
</entry>

<entry>
    <title>もっとCore Foundation / サーバソケットとCFStreamと私</title>
    <link rel="alternate" type="text/html" href="http://blog.foursics.jp/hironobu/2011/05/core-foundation-server-socket-and-cfstream-and-me.html" />
    <id>tag:blog.foursics.jp,2011:/hironobu//2.340</id>

    <published>2011-05-16T10:27:12Z</published>
    <updated>2011-05-16T11:09:49Z</updated>

    <summary> で。 CFStream APIについて触れたかったのはこっち。CFStream...</summary>
    <author>
        <name>Hironobu Koura</name>
        
    </author>
    
        <category term="mac" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://blog.foursics.jp/hironobu/">
        <![CDATA[<p>
で。
</p>

<p>
CFStream APIについて触れたかったのはこっち。CFStreamはネットワーク部分はいわゆるTCP/IPソケットと同じなので、connectとacceptによって通信路が確立される。
</p>

<p>
前のエントリで触れた内容ではクライアント側の実装、すなわちconnect側だったわけだが、もちろんサーバソケット(accept側)の実装もできる。ちょっと手間はかかるけれどもこんな感じ。
</p>

<pre class="brush: objc">
static void
_server_socket_callback(CFSocketRef s, CFSocketCallBackType type, CFDataRef address, const void* data, void* info)
{
    CFSocketNativeHandle handle = *(CFSocketNativeHandle*)data;
    
    NSLog(@"accepted. (s = %p, handle = %d)", s, handle);
    
    CFReadStreamRef readStream = NULL;
    CFWriteStreamRef writeStream = NULL;
    
    CFStreamCreatePairWithSocket(kCFAllocatorDefault, handle, &readStream, &writeStream);
    
    if (_setup_read_stream(readStream) != 0) {
        CFRelease(readStream);
        readStream = NULL;
    }
    if (_setup_write_stream(writeStream) != 0) {
        CFRelease(writeStream);
        writeStream = NULL;
    }
    
    NSLog(@"readStream = %p, writeStream = %p", readStream, writeStream);
}

static void
_do_server()
{
    CFSocketContext context = { 0, NULL, NULL, NULL, NULL };
    CFSocketRef socket = CFSocketCreate(kCFAllocatorDefault, PF_INET, SOCK_STREAM, 0, kCFSocketAcceptCallBack, _server_socket_callback, &context);

    int yes = 1;
    setsockopt(CFSocketGetNative(socket), SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes));
    
    struct sockaddr_in sin;
    memset(&sin, 0, sizeof(sin));
    sin.sin_family = AF_INET;
    sin.sin_addr.s_addr = INADDR_ANY;
    sin.sin_port = htons(8888);
    sin.sin_len = sizeof(struct sockaddr_in);
    
    CFDataRef data = CFDataCreate(kCFAllocatorDefault, (UInt8*)&sin, sizeof(sin));
    CFSocketSetAddress(socket, data);
    CFRelease(data);
    
    CFRunLoopSourceRef source = CFSocketCreateRunLoopSource(kCFAllocatorDefault, socket, 0);
    CFRunLoopAddSource(CFRunLoopGetCurrent(), source, kCFRunLoopCommonModes);
    CFRelease(source);
    
    NSLog(@"socket = %p", socket);
}
</pre>

<ol>
<li>CFSocketCreate()でCFSocketオブジェクトを生成し、
<li>CFSocketSetAddress()でバインディングアドレスを指定、
<li>CFSocketCreateRunLoopSource()およびCFRunLoopAddSource()でRun LoopにCFSocketオブジェクトを登録、
<li>最初のCFSocketCreate()で登録したコールバック(_server_socket_callback)にacceptされたソケットディスクリプタ(=CFSocketNativeHandle)が渡り、
<li>4.のソケットディスクリプタからCFStreamCreatePairWithSocket()より、CFReadStream/CFWriteStreamを生成。
</ol>

<p>
これ以降は前エントリの扱いと同じ。
</p>

<p>
んで。
</p>

<p>
このパターンで生成されたCFReadStream/CFWriteStreamは、CFReadStreamClose()/CFWriteStreamClose()してもTCP接続は閉じないという現象を確認してしまいました。これそういうもん？と色々調べたところ、CFReadStream/CFWriteStreamオブジェクトのプロパティkCFStreamPropertyShouldCloseNativeSocketをTRUE(kCFBooleanTrue)にするとちゃんと閉じてくれるようになった。
</p>

<pre class="brush: objc">
static void
_server_socket_callback(CFSocketRef s, CFSocketCallBackType type, CFDataRef address, const void* data, void* info)
{
    switch (type) {
        case kCFSocketAcceptCallBack: {
            CFSocketNativeHandle handle = *(CFSocketNativeHandle*)data;
            
            NSLog(@"accepted. (s = %p, handle=%d)", s, handle);
            
            CFReadStreamRef readStream = NULL;
            CFWriteStreamRef writeStream = NULL;
            
            CFStreamCreatePairWithSocket(kCFAllocatorDefault, handle, &readStream, &writeStream);
            
            CFReadStreamSetProperty(readStream, kCFStreamPropertyShouldCloseNativeSocket, kCFBooleanTrue);
            CFWriteStreamSetProperty(writeStream, kCFStreamPropertyShouldCloseNativeSocket, kCFBooleanTrue);
            
            if (_setup_read_stream(readStream) != 0) {
                CFRelease(readStream);
                readStream = NULL;
            }
            if (_setup_write_stream(writeStream) != 0) {
                CFRelease(writeStream);
                writeStream = NULL;
            }

            NSLog(@"readStream = %p, writeStream = %p", readStream, writeStream);
        }
            break;
    }
}
</pre>

<script type="text/javascript">
SyntaxHighlighter.all();
</script>]]>
        
    </content>
</entry>

<entry>
    <title>もっとCore Foundation / CFStreamこそがtoll-freeだよ</title>
    <link rel="alternate" type="text/html" href="http://blog.foursics.jp/hironobu/2011/05/core-foundation-cfstream.html" />
    <id>tag:blog.foursics.jp,2011:/hironobu//2.339</id>

    <published>2011-05-16T09:13:54Z</published>
    <updated>2011-05-16T09:20:47Z</updated>

    <summary> さて前のエントリでCFHostをうっかりtoll-freeだと勘違いして書いて...</summary>
    <author>
        <name>Hironobu Koura</name>
        
    </author>
    
        <category term="mac" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://blog.foursics.jp/hironobu/">
        <![CDATA[<p>
さて前のエントリでCFHostをうっかりtoll-freeだと勘違いして書いてしまったせいで、引き続きのこのエントリが内容がらりと変えることになってしまいましてね、と前置きをしつつの第2回であります。
</p>

<p>
さて無事クエリを解決できたCFHostを用いていよいよ通信の確立ですが。CFStream APIを使えばそのまま非同期接続が可能なのでそれで充分です。さっそく行ってみる。ざっくり。
</p>

<pre class="brush: objc">
static int
_setup_read_stream(CFReadStreamRef readStream)
{
    CFStreamClientContext context = { 0, NULL, NULL, NULL, NULL };
    if (!CFReadStreamSetClient(readStream,
                               kCFStreamEventOpenCompleted |
                               kCFStreamEventHasBytesAvailable |
                               kCFStreamEventErrorOccurred |
                               kCFStreamEventEndEncountered,
                               _read_stream_callback, &context)) {
        CFStreamError err = CFReadStreamGetError(readStream);
        NSLog(@"err = %d/%ld", err.error, err.domain);
        return -1;
    }
    CFReadStreamScheduleWithRunLoop(readStream, CFRunLoopGetCurrent(), kCFRunLoopCommonModes);
    
    if (!CFReadStreamOpen(readStream)) {
        // error.
        CFStreamError err = CFReadStreamGetError(readStream);
        NSLog(@"err = %d/%ld", err.error, err.domain);
        
        CFReadStreamSetClient(readStream, kCFStreamEventNone, NULL, NULL);
        CFReadStreamUnscheduleFromRunLoop(readStream, CFRunLoopGetCurrent(), kCFRunLoopCommonModes);
        return -1;
    }
    
    return 0;
}

static int
_setup_write_stream(CFWriteStreamRef writeStream)
{
    CFStreamClientContext context = { 0, NULL, NULL, NULL, NULL };
    
    if (!CFWriteStreamSetClient(writeStream,
                                kCFStreamEventOpenCompleted |
                                kCFStreamEventCanAcceptBytes |
                                kCFStreamEventErrorOccurred |
                                kCFStreamEventEndEncountered,
                                _write_stream_callback, &context)) {
        CFStreamError err = CFWriteStreamGetError(writeStream);
        NSLog(@"err = %d/%ld", err.error, err.domain);
        return -1;
    }
    CFWriteStreamScheduleWithRunLoop(writeStream, CFRunLoopGetCurrent(), kCFRunLoopCommonModes);
    
    if (!CFWriteStreamOpen(writeStream)) {
        // error.
        CFStreamError err = CFWriteStreamGetError(writeStream);
        NSLog(@"err = %d/%ld", err.error, err.domain);
        
        CFWriteStreamSetClient(writeStream, kCFStreamEventNone, NULL, NULL);
        CFWriteStreamUnscheduleFromRunLoop(writeStream, CFRunLoopGetCurrent(), kCFRunLoopCommonModes);
        return -1;
    }
    
    return 0;
}

static void
_do_connect(CFHostRef host)
{
    NSLog(@"host = %@", host);
    
    CFReadStreamRef readStream = NULL;
    CFWriteStreamRef writeStream = NULL;
    
    CFStreamCreatePairWithSocketToCFHost(kCFAllocatorDefault, host, 80, &readStream, &writeStream);
    
    NSLog(@"readStream = %@", readStream);
    NSLog(@"writeStream = %@", writeStream);
    
    if (_setup_read_stream(readStream) != 0) {
        CFRelease(readStream);
        readStream = NULL;
    }
    if (_setup_write_stream(writeStream) != 0) {
        CFRelease(writeStream);
        writeStream = NULL;
    }

    NSLog(@"connect start.");
}
</pre>

<p>
_do_connect()で使うCFStreamCreatePairWithSocketToCFHost()からCFReadStream/CFWriteStreamオブジェクトを取り出してこれをCFRunLoopにバインドするまでで一連の処理になります。read/writeともに、使用するAPIの流れは以下の通り。
</p>

<ol>
<li>CFXxxStreamSetClient()
<li>CFXxxStreamScheduleWithRunLoop()
<li>CFXxxStreamOpen()
</ol>

<p>
最初のCFXxxStreamSetClient()でコールバック関数を指定した後、Run Loopに登録。その後にCFXxxStreamOpen()でCFStreamを開けばコールバック関数に処理が渡り始める。
</p>

<pre class="brush: objc">
static void
_read_stream_callback(CFReadStreamRef readStream, CFStreamEventType eventType, void* info)
{
    NSLog(@"readStream = %p, eventType = %ld", readStream, eventType);
    
    switch (eventType) {
        case kCFStreamEventOpenCompleted:
            ...            
        case kCFStreamEventHasBytesAvailable:
            ...
        case kCFStreamEventEndEncountered:
            ...
        case kCFStreamEventErrorOccurred:
            ...
    }
}

static void
_write_stream_callback(CFWriteStreamRef writeStream, CFStreamEventType eventType, void* info)
{
    NSLog(@"writeStream = %p, eventType = %ld", writeStream, eventType);
    
    switch (eventType) {
        case kCFStreamEventOpenCompleted:
            ...
        case kCFStreamEventCanAcceptBytes:
            ...
        case kCFStreamEventEndEncountered:
            ...
        case kCFStreamEventErrorOccurred:
            ...
    }
}
</pre>

<p>
一方で、ここまでコールバックを設定するのにCFHostClientContextおよびCFStreamClientContextという構造体があったけれども、これがコールバック関数の引数に渡ってくることになる。
</p>

<pre class="brush: objc">
struct CFHostClientContext {
  CFIndex			 version;
  void *			  info;
  CFAllocatorRetainCallBack  retain;
  CFAllocatorReleaseCallBack  release;
  CFAllocatorCopyDescriptionCallBack  copyDescription;
};
typedef struct CFHostClientContext	  CFHostClientContext;

typedef CALLBACK_API_C( void , CFHostClientCallBack )(CFHostRef theHost, CFHostInfoType typeInfo, const CFStreamError *error, void *info);

typedef struct {
    CFIndex version;
    void *info;
    void *(*retain)(void *info);
    void (*release)(void *info);
    CFStringRef (*copyDescription)(void *info);
} CFStreamClientContext;

typedef void (*CFReadStreamClientCallBack)(CFReadStreamRef stream, CFStreamEventType type, void *clientCallBackInfo);
typedef void (*CFWriteStreamClientCallBack)(CFWriteStreamRef stream, CFStreamEventType type, void *clientCallBackInfo);
</pre>

<p>
CFHostClientContextおよびCFStreamClientContextのinfoフィールドで指定したアドレスが、CFHostClientCallBackの第4引数info、CFReadStreamClientCallBack/CFWriteStreamClientCallBackの第3引数clientCallBackInfoに渡ってくる。
</p>

<p>
このCFHostClientContext/CFStreamClientContextでは、infoフィールドのアドレスをCoreFoundationオブジェクトが標準でそうであるように、参照カウントの仕組みを前提としており、infoを引数にするretain/release関数を指定することができる。それぞれretain/releaseフィールドはこの用途で使われる。また、copyDescriptionフィールドは、デバッグ用途などでオブジェクトの内容を文字列化する際に使うことができる。CocoaでNSLogに書式化文字列を使って"%@"にオブジェクトを直接ぶち込み、オブジェクトの内容をコンソールに簡易に出力することができるアレのこと。
</p>

<p>
ただ、retain/release/copyDescriptionフィールドはあまり重要性が高くなく、Cocoaとの連携で考える限りにおいて参照カウントの管理についてもObjective-C側でのみ面倒を見ていれば大抵は用が足りると思われ、あんまりそこは気にしなくてよさそうな感触である。
</p>

<script type="text/javascript">
SyntaxHighlighter.all();
</script>]]>
        
    </content>
</entry>

<entry>
    <title>Core Foundationをもっと使おうじゃないか / CFHostで非同期に名前解決</title>
    <link rel="alternate" type="text/html" href="http://blog.foursics.jp/hironobu/2011/05/core-foundation-cfhost.html" />
    <id>tag:blog.foursics.jp,2011:/hironobu//2.338</id>

    <published>2011-05-13T03:19:18Z</published>
    <updated>2011-05-13T09:40:40Z</updated>

    <summary> ちょっと自分で必要があって調べたので、ここにまとめておこうと思う。Core F...</summary>
    <author>
        <name>Hironobu Koura</name>
        
    </author>
    
        <category term="mac" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://blog.foursics.jp/hironobu/">
        <![CDATA[<p>
ちょっと自分で必要があって調べたので、ここにまとめておこうと思う。Core Foundationネタである。
</p>

<p>
大抵のことはCocoa(というかFoundationとAppKit)レイヤーで済んでしまうので、割とこう厄介になることは少ないもんなんだけど、いざ細かいところが気になり出して手を加えようとしはじめると粒度が荒くて...なんてことが割とある。以下はそのときに調べて使ったものを少しずつ小分けにまとめてみたもの。備忘録的に行ってみよう。
</p>

<p>
＊＊＊
</p>

<p>
CFHostで非同期に名前解決を行えることを知ったのでそのやり方をまとめてみた。CFHostは普通の同期解決も非同期解決もできるんだが、メインループとの親和的な統合を歌っているだけあり、非同期解決の方でこそその旨味が発揮されるというものかもしれない。っていうか同期解決なら普通にNSHost(Cocoa)でもできるし。
</p>

<p>
非同期で名前解決することで得られるメリットは「アプリの挙動が安定すること」だ。MacOSX/iOSいずれであっても、ユーザの操作にはできるだけダイレクトに応答するようにした方が、アプリが安定して動いている感じがしてよろこばれるし、また何かしらのブロッキングな処理で一見アプリの動作が止まっているように見えても、「名前解決をしているのか」「データを読もうとしているのか」がわかる、あるいは本当に異常で「フリーズして」しまっているのかを見分けられるというのはアプリケーションに対する安心感として帰ってくる。また、もし誤操作でブロッキングさせた、もしくはブロックしている間に気が変わって他のことをしたくなったなら、簡単にキャンセルして元に戻せるようにもしたい。快適なインターネットライフ(何)のために、アプリケーションの挙動はできるだけユーザに安心と信頼を与えられるようでありたいものだ。
</p>

<p>
ネットワークアプリケーションを作るときに、ブロッキングが発生するタイミングは大きく三つある。
</p>

<ul>
<li>名前解決
<li>TCP接続の確立(connect(),accept())
<li>データの送受信
</ul>

<p>
これらの状況で何も考えずに処理を書くと簡単にブロックが発生してしまう。ブロックが発生するというのは即ちGUI操作が止まってウィンドウは動かせずボタンは押せず、レインボーカーソルのお出ましである。「サーバとの通信を行います」とモーダルダイアログで告知してたまに通信を行うだけの必要最低限のネットワーク機能しか無いようなやつならまだしも、メールソフトやブラウザが頻繁に固まるようなアプリケーションばかりでは、正直快適とは言いがたい。
</p>

<p>
Cocoaではこの「データの送受信」については既に非同期処理が導入されている(NSStreamsとか)。このため大抵のケースはこれで間に合うが、前の二つ「名前解決」「connect()/accept()」については同期のみ、というか手の入れようが無い。まあDNSはローカル上でもキャッシュ機構が働いているし、NSURLなどではそこも含めて隠蔽しているはずなので(未確認だけど)、こまけえこたぁ気に(ryってことなのかもしれない。
</p>

<p>
しかしNSURLにはそぐわないがヘビーにTCP/IPをつつきたい用途なんかもやっぱりあるわけで、そうするとあとはBSDソケットレイヤーでO_NONBLOCKを...とか言いたくなるところだが、Core FoundationにはCFHostというAPIがあって、こいつで非同期クエリが飛ばせるらしいと知った<s>(しかもNSHostのtoll-free)</s>←勘違いでした(_ _)。
</p>




<p>
<a href="http://developer.apple.com/library/ios/#documentation/CoreFoundation/Reference/CFHostRef/Reference/reference.html">http://developer.apple.com/library/ios/#documentation/CoreFoundation/Reference/CFHostRef/Reference/reference.html</a><br/>
CFHost Reference
</p>

<p>
おおまかな流れとしては以下の通り。
</p>

<ol>
<li>CFHostCreateWithName()でインスタンス生成
<li>CFHostSetClient()でコールバックを設定
<li>CFHostScheduleWithRunLoop()でメインループに接続
<li>CFHostStartInfoResolution()でクエリ送信
<li>2.で設定したコールバックでクエリ応答を受信
</ol>

<pre class="brush: js">
static void
_host_client_callback(CFHostRef host, CFHostInfoType typeInfo, const CFStreamError *err, void* info)
{
    Boolean resolved = FALSE;
    
    CFArrayRef addr = CFHostGetAddressing(host, &resolved);
    
    NSLog(@"ASYNC: resolved = %d, err = %d/%ld", resolved, err->error, err->domain);
    NSLog(@"ASYNC: result = %@", addr);    
}

static void
_do_query(CFStringRef s)
{
    Boolean ret, resolved;
    CFStreamError err;
    
    CFHostRef host = CFHostCreateWithName(NULL, s);
    CFHostClientContext context = { 0, NULL, CFRetain, CFRelease, NULL };
    
    CFHostSetClient(host, _host_client_callback, &context);
    
    CFHostScheduleWithRunLoop(host, CFRunLoopGetMain(), kCFRunLoopDefaultMode);
    ret = CFHostStartInfoResolution(host, kCFHostAddresses, &err);
    {
        CFArrayRef addr;
        
        NSLog(@"SYNC: ret = %d", ret);
        
        addr = CFHostGetAddressing(host, &resolved);
        
        NSLog(@"SYNC: resolved = %d, err = %d/%ld", resolved, err.error, err.domain);
        NSLog(@"SYNC: result = %@", addr);    
    }
}
</pre>

<p>
CFHostStartInfoResolution()に至る前にCFHostSetClient()を行ってコールバックを設定していなければ、非同期解決にはならずにそのままCFHostStartInfoResolution()でブロックがかかる。
</p>

<p>
そして_do_query()の引数にCFStringRefが与えられているがこれもNSStringのtoll-free bridgeがかかっているので、呼び出す時はNSStringオブジェクトにキャストして渡してやればよい。
</p>

<pre class="brush: objc">
    NSString* s = @"www.google.com";
    _do_query((CFStringRef)s);
</pre>

<p>
そして実行結果は下記のようになる。
</p>

<pre class="brush: plain">
2011-05-13 12:17:54.757 CFHostTester[65231:903] SYNC: ret = 1
2011-05-13 12:17:54.760 CFHostTester[65231:903] SYNC: resolved = 0, err = 0/0
2011-05-13 12:17:54.761 CFHostTester[65231:903] SYNC: result = (null)
2011-05-13 12:17:54.860 CFHostTester[65231:903] ASYNC: resolved = 1, err = 0/0
2011-05-13 12:17:54.861 CFHostTester[65231:903] ASYNC: result = (
    <10020000 40e9b769 00000000 00000000>,
    <10020000 40e9b76a 00000000 00000000>,
    <10020000 40e9b793 00000000 00000000>,
    <10020000 40e9b763 00000000 00000000>,
    <10020000 40e9b767 00000000 00000000>,
    <10020000 40e9b768 00000000 00000000>
)
</pre>

<p>
ログの出力に「SYNC:」と「ASYNC:」とそれぞれ付く箇所の出力内容に注意。SYNC:の付く箇所はCFHostStartInfoResolution()を呼んだ直後に取ったデータだが、ここには決して名前解決したデータが乗ってくることはない。何度も同じ名前解決を行って確実にDNSキャッシュに乗ったと思われる状況でも同じだったので、非同期設定を行ったCFHostではコールバックが行われるまではDNS情報はCFHostオブジェクトには渡って来ない、と見るべきなよう。もちろん、非同期設定を行わないつまりCFHostSetClient()およびCFHostScheduleWithRunLoop()を呼ばなければ、普通に「SYNC:」の行で結果は返る。
</p>

<script type="text/javascript">
SyntaxHighlighter.all()
</script>]]>
        
    </content>
</entry>

<entry>
    <title>「ずっと好きだった」が、好きだった。</title>
    <link rel="alternate" type="text/html" href="http://blog.foursics.jp/hironobu/2011/04/zutto-sukidatta-noni.html" />
    <id>tag:blog.foursics.jp,2011:/hironobu//2.337</id>

    <published>2011-04-09T14:47:03Z</published>
    <updated>2011-04-09T14:56:53Z</updated>

    <summary> ...とタイトルをつけてみた割には、僕はどっちかというと「彼女」の方がより好き...</summary>
    <author>
        <name>Hironobu Koura</name>
        
    </author>
    
        <category term="music" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://blog.foursics.jp/hironobu/">
        <![CDATA[<p>
...とタイトルをつけてみた割には、僕はどっちかというと「彼女」の方がより好きだな。
</p>

<p>
騒動そのものを追うのは他の人に任せて、僕は今、この件について感じたことだけを話そう。
</p>

<p>
斉藤和義自身の主張が反原発でも親原発でも、僕はどちらでもかまわないと思っている。そしてそのことを口舌で語るのではなく、音楽によって主張したという点において、そこにミュージシャンとしての気概を見いだして嬉しくもある。しかし一方で、それが「『ずっと好きだった」の替え歌」として行われたことには、すごく残念な思いがある。
</p>

<p>
<a href="http://music.goo.ne.jp/lyric/LYRUTND91949/index.html" title="ずっと好きだった 斉藤和義 歌詞情報 - goo 音楽" target="_blank">ずっと好きだった 斉藤和義 歌詞情報 - goo 音楽</a><br>
</p>

<p>
彼自身、どのような批判でも受けて立つ気持ちだったのだろうと思う。そこは最大限尊重したい。あと作風もわざわざ「青い光」を持ち出すまでもなく、割と社会的な話題をちりばめることは少なくないので、それ自体にとりたてて意外だとか驚いたとかってことも特には無い。そもそも清志郎チルドレンでもあるわけで(というのは笹平さん(<a href="http://twitter.com/sshrtk/">@sshrtk</a>)の指摘で気がついた、というか思い出した)、この局面で抱く思いもいろいろあるだろうってのは分かる。事務所やレコード会社など周囲との葛藤や軋轢も相当いろんなものがあろうし、その辺はここではおいておく。
</p>

<p>
<table  border="0" cellpadding="5"><tr><td colspan="2"><a href="http://www.amazon.co.jp/RESPECT-%E3%82%AA%E3%83%A0%E3%83%8B%E3%83%90%E3%82%B9/dp/B00005FK0Q%3FSubscriptionId%3D15SMZCTB9V8NGR2TW082%26tag%3Dhironobu-22%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3DB00005FK0Q" target="_top">RESPECT!</a><img src="http://www.assoc-amazon.jp/e/ir?t=hironobu-22&l=ur2&o=9" width="1" height="1" style="border: none;" alt="" /></td></tr><tr><td valign="top"><a href="http://www.amazon.co.jp/RESPECT-%E3%82%AA%E3%83%A0%E3%83%8B%E3%83%90%E3%82%B9/dp/B00005FK0Q%3FSubscriptionId%3D15SMZCTB9V8NGR2TW082%26tag%3Dhironobu-22%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3DB00005FK0Q" target="_top"><img src="http://ecx.images-amazon.com/images/I/518DKXENAZL._SL160_.jpg" border="0" alt="RESPECT!" /></a></td><td valign="top"><font size="-1">オムニバス 忌野清志郎 仲井戸麗市 三宅伸治 石田長生 泉谷しげる 及川光博 矢野顕子 坂崎幸之助 <br /><br />ポリドール  2000-05-05<br />売り上げランキング : 31802<br /><br /><br /><a href="http://www.amazon.co.jp/RESPECT-%E3%82%AA%E3%83%A0%E3%83%8B%E3%83%90%E3%82%B9/dp/B00005FK0Q%3FSubscriptionId%3D15SMZCTB9V8NGR2TW082%26tag%3Dhironobu-22%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3DB00005FK0Q" target="_top">Amazonで詳しく見る</a></font><font size="-2"> by <a href="http://www.goodpic.com/mt/aws/index.html" >G-Tools</a></font></td></tr></table>
</p>

<p>
ただ、今回の「ずっとウソだった」の歌詞を聞いて、というかこの騒動の発端を耳にしてからずっと、どうにも強い違和感があった。
</p>

<p>
「ずっと好きだった」は形の上ではずっと好きだった女の子への未練をぶつける歌詞だが、「ずっと好きだった」のに、その思いに応えてくれなかった相手を責めるといったことではなく、未練を断ち切れずにいる自分の焼き焦がれるような内面をさらけ出す歌である。
</p>

<p>
<iframe title="YouTube video player" width="480" height="390" src="http://www.youtube.com/embed/vvFrFTIFDFA" frameborder="0" allowfullscreen></iframe>
</p>

<p>
「ずっと好きだった」だけだとはっきりしてこないかもしれないが、最初にも挙げた「彼女」やちょっと毛色は違うが「進め なまけもの」あたりを例に挙げたい。あと「ずっとウソだった」路線から攻めるなら、「ポストにマヨネーズ」の方なんかも近いかもしれない。
</p>

<p>
<table  border="0" cellpadding="5"><tr><td colspan="2"><a href="http://www.amazon.co.jp/%E6%AD%8C%E3%81%86%E3%81%9F%E3%81%8415-SINGLES-BEST-1993%7E2007-%E6%96%89%E8%97%A4%E5%92%8C%E7%BE%A9/dp/B0017LIIDC%3FSubscriptionId%3D15SMZCTB9V8NGR2TW082%26tag%3Dhironobu-22%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3DB0017LIIDC" target="_top">歌うたい15 SINGLES BEST 1993~2007</a><img src="http://www.assoc-amazon.jp/e/ir?t=hironobu-22&l=ur2&o=9" width="1" height="1" style="border: none;" alt="" /></td></tr><tr><td valign="top"><a href="http://www.amazon.co.jp/%E6%AD%8C%E3%81%86%E3%81%9F%E3%81%8415-SINGLES-BEST-1993%7E2007-%E6%96%89%E8%97%A4%E5%92%8C%E7%BE%A9/dp/B0017LIIDC%3FSubscriptionId%3D15SMZCTB9V8NGR2TW082%26tag%3Dhironobu-22%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3DB0017LIIDC" target="_top"><img src="http://ecx.images-amazon.com/images/I/41erBp7Tq2L._SL160_.jpg" border="0" alt="歌うたい15 SINGLES BEST 1993~2007" /></a></td><td valign="top"><font size="-1">斉藤和義 斉藤和義と玲葉奈 <br /><br />ビクターエンタテインメント  2008-08-06<br />売り上げランキング : 69<br /><br /><br /><a href="http://www.amazon.co.jp/%E6%AD%8C%E3%81%86%E3%81%9F%E3%81%8415-SINGLES-BEST-1993%7E2007-%E6%96%89%E8%97%A4%E5%92%8C%E7%BE%A9/dp/B0017LIIDC%3FSubscriptionId%3D15SMZCTB9V8NGR2TW082%26tag%3Dhironobu-22%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3DB0017LIIDC" target="_top">Amazonで詳しく見る</a></font><font size="-2"> by <a href="http://www.goodpic.com/mt/aws/index.html" >G-Tools</a></font></td></tr></table>
</p>

<p>
好きだった、それでも別れた相手に「気づけなかった涙してたこと」をいつまでもひきずり(「彼女」)、うまくいかない毎日の、アパートに帰り着き眠ろうとするも賑やかそうな「隣が目障りだけれど寝ちゃえば平気」と敢えて外ではなく内へ意識を持って行こうとすることで軽く強がってみたり(「進め なまけもの」)、ストーカーだか変質者だかへどが出るような嫌がらせをしてくる相手に同じレベルになって相手してみせるなど(「ポストにマヨネーズ」)、これでもかと、脆く無様な自分の内面を引きずり出して描き出し、それを歌にする。「あんたの人生 楽しそうだな」って皮肉だろうか、それとも本心だろうか。何とも身震いさせる、ワクワクさせる歌詞を書いてくれるじゃないか。
</p>

<p>
こんな男が「ずっと好きだった」と歌う。他の歌から比べればかなり抑制の効いた内容だけに、むしろその内面はどれだけのカオスになっているものかと、想像かきたたせられるものがある。この歌で同じようなことドロドロと書いてたら野暮ってもんだよね、ってなくらいのもんだ。
</p>

<p>
斉藤和義というとそのくらいのものが言ってみれば「先入観」として浮かぶので、その上で「ずっとウソだった」を聞かされてん？何だ政府と東電disだとか？え？そんな歌だっけ？と、軽く面食らってしまった。「ずっと好きだった」と言う自分は、それを口にすればする程辛くなっていくことが分かっているはずなんだが、「ずっとウソだった」と嘆く自分からは、そんな様子は感じられなかった。いつもなら、相手に対して手に握り構えるナイフのあまりの冷たさに我が身をも凍てつかせ滅びさせようともする自分に向けた鋭さが、「ずっとウソだった」では全く立ちのぼって来なかった。
</p>

<p>
替え歌なんだから、元歌にどこまでも従属しなきゃいけないってもんでもなし、好きに組み変わって当然だと割り切る考え方もできる一方、作者本人の手によるものながら、しかもタイトルも歌詞構成もかなりそのままなのに詞世界を全然トレースしていないというのは、正直にぶっちゃけてしまえば、「ガッカリ」した。
</p>

<p>
プロテストソングをやりたいならやればいい(「ご勝手に」と突き放す意味ではなく)。けど、「ずっと好きだった」<strong>を好きだった</strong>立場からすれば、作者本人がこんなことをしてしまったら、まるで元歌が死んでしまったようである。元歌の自分と、替え歌の自分は、全く繋がっていないんだろうか。...いやむしろ実際は、<strong>同じように辛いし、同じように自分が責めを負うべき</strong>なんじゃないか。世間は政府や東電へのその批判精神と勇気に感動したなんつってるが、本当はそんな簡単な話じゃないんじゃないか。ねえ。どうなんだ。ああ、モヤモヤする。
</p>

<p>
教えてよ。やっぱいいや...。
</p>]]>
        
    </content>
</entry>

<entry>
    <title>あけましてアジア杯</title>
    <link rel="alternate" type="text/html" href="http://blog.foursics.jp/hironobu/2011/01/asiancup2011.html" />
    <id>tag:blog.foursics.jp,2011:/hironobu//2.335</id>

    <published>2011-01-31T14:37:57Z</published>
    <updated>2011-01-31T14:48:39Z</updated>

    <summary> 気づいたら1月も終わりかけなんですがとりあえず1月のうち何もなしってのもどーよ...</summary>
    <author>
        <name>Hironobu Koura</name>
        
    </author>
    
        <category term="sports" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://blog.foursics.jp/hironobu/">
        <![CDATA[<p>
気づいたら1月も終わりかけなんですがとりあえず1月のうち何もなしってのもどーよ何か書いとけって気がしたので。てかやっちまったよアジアカップ。
</p>

<p>
なんか2011年が始まったと思ったら不意打ちくらいになだれこんだアジアカップだったのでまとまった感慨とかになってませんがまあ何と言うかやっちまったよおい。
</p>

<p>
<a href="http://www.nhk.or.jp/sports/asiancup/">http://www.nhk.or.jp/sports/asiancup/</a><br/>
NHK AFCアジアカップ2011
</p>

<p>
アンコール放送がBS1でやるらしいんですので復習のために覚えときましょうね奥様。
</p>]]>
        
    </content>
</entry>

<entry>
    <title>bind()してlisten()してaccept()してNSStreamしてみたらえんやこら</title>
    <link rel="alternate" type="text/html" href="http://blog.foursics.jp/hironobu/2010/12/bind-listen-accept-and-nsstream.html" />
    <id>tag:blog.foursics.jp,2010:/hironobu//2.334</id>

    <published>2010-12-15T10:41:11Z</published>
    <updated>2010-12-15T11:24:13Z</updated>

    <summary> NSStreamのメソッドでさらに足りないなーと思っていたのがCFStream...</summary>
    <author>
        <name>Hironobu Koura</name>
        
    </author>
    
        <category term="mac" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://blog.foursics.jp/hironobu/">
        <![CDATA[<p>
NSStreamのメソッドでさらに足りないなーと思っていたのがCFStreamCreatePairWithSocketっていうAPI。...いやもっとぶっちゃけて言えばbind()してlisten()してaccept()するサーバソケットをNSStreamで使いたいなー、という。
</p>

<p>
で、結論から言ってしまうとこれでNSInputStream/NSOutputStreamが取れるのはいいんだが、closeするときがめんどくさい。お行儀悪くてもいいって言うなら止めはしないが。めんどくさいというのは、inputもoutputも共々closeしてもソケットそのものをcloseしないとpeerにFINを送ってくれないようなのです。
</p>

<p>
まあCocoaで組むサーバアプリなんてそうそうないんで普通は気にしないもんだけど(というかだからこそNSStreamでは手薄なんだが)、だからといって全く使わないこともないわけでねえ。DCC(IRC)とか、FTPとかね。
</p>

<p>
というわけでいろいろ試してみたけど、closeするまでちゃんとソケットのディスクリプタそのものをちゃんと管理しておけってところのようだ。まあせっかくなのでCFSocketまで使え、っていうソリューションもあるけどどっちにしろ多少の追加実装が必要そうなことには変わりなさげ。
</p>]]>
        
    </content>
</entry>

<entry>
    <title>NSHostでv6→v4フォールバックが起こらない</title>
    <link rel="alternate" type="text/html" href="http://blog.foursics.jp/hironobu/2010/12/v6-v4-fallback-fails-on-nshost.html" />
    <id>tag:blog.foursics.jp,2010:/hironobu//2.333</id>

    <published>2010-12-14T03:50:46Z</published>
    <updated>2011-12-29T05:49:53Z</updated>

    <summary> v6/v4両アドレスを併用しているホストで、v4アドレスでのみlisten()...</summary>
    <author>
        <name>Hironobu Koura</name>
        
    </author>
    
        <category term="mac" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://blog.foursics.jp/hironobu/">
        <![CDATA[<p>
v6/v4両アドレスを併用しているホストで、v4アドレスでのみlisten()しているサーバプロセスに対してMacから接続しようとする際、しくじるというパターンがあった。具体的に言うとtiarraがv6アドレスでlisten()してくれなかったんですがね。
</p>

<p>
Intermezzoの中で+[NSHost getStreamsToHost:port:inputStream:outputStream:]を使っていたのが、これがうまくなかったらしい。v6アドレスでconnect()しに行って蹴られてそこでくじけて終了してた。telnetだとv6失敗→v4の順でフォールバックしてくれるのに、Intermezzoの手製コードだとそれが起こらなかったの。
</p>

<p>
実はこの+[NSHost getStreamsToHost:port:inputStream:outputStream:]メソッドはiOS SDKでは使えないため、以下のような置き換え用のコードが存在している。これに切り替えて動作させたらv6→v4の順にconnect()してくれて問題を回避できた。1番目の引数にホスト名を表す文字列(NSString)を要求するので、-[NSHost name]を使って渡すようにした。
</p>

<p>
<a href="http://developer.apple.com/library/ios/#qa/qa2009/qa1652.html">http://developer.apple.com/library/ios/#qa/qa2009/qa1652.html</a><br/>
Technical Q&A QA1652: Using NSStreams For A TCP Connection Without NSHost
</p>

<p>
というわけで、NSHostで名前解決を先にしてしまうとv6→v4フォールバックが起こらなかったよ、という結果報告でござった。
</p>]]>
        
    </content>
</entry>

<entry>
    <title>NPB=Nippon Promotional Baseball</title>
    <link rel="alternate" type="text/html" href="http://blog.foursics.jp/hironobu/2010/10/nippon-promotional-baseball.html" />
    <id>tag:blog.foursics.jp,2010:/hironobu//2.331</id>

    <published>2010-10-19T15:51:50Z</published>
    <updated>2011-05-16T11:35:17Z</updated>

    <summary> 第一報を聞いての感想は、まあ、やっぱりか、だった。 http://www.as...</summary>
    <author>
        <name>Hironobu Koura</name>
        
    </author>
    
        <category term="sports" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://blog.foursics.jp/hironobu/">
        <![CDATA[<p>
第一報を聞いての感想は、まあ、やっぱりか、だった。
</p>

<p>
<a href="http://www.asahi.com/business/update/0930/TKY201009300525.html">http://www.asahi.com/business/update/0930/TKY201009300525.html</a><br/>
asahi.com（朝日新聞社）：横浜ベイスターズ売却を打診　ＴＢＳ、住生活Ｇ軸に - ビジネス・経済
</p>

<p>
TBSが親会社になった経緯も考えれば遠くないうちに彼らが手を引きたがっても全く不思議はなかったわけだし、それを上回るスピードでテレビ・新聞業界の業績悪化が伝えられる昨今の情勢ではおそらくこの展開はどう頑張っても不可避だったろう。さてしかし、問題はその先だ。
</p>

<p>
この半月ちょっとほど眺めている限りで、この潮田会長が積極的に野球への思い入れを語ったらしいコメントというのがほとんどと言っていい程伝わって来ない。
</p>

<p>
<a href="http://www.sanspo.com/baseball/news/101013/bse1010130504000-n1.htm">http://www.sanspo.com/baseball/news/101013/bse1010130504000-n1.htm</a><br/>
【潮田会長に聞く】「大洋ファンだった」 - 野球 - SANSPO.COM
</p>

<blockquote>
<p>－－会長の個人的なベイスターズの印象は</p>

<p>　「ビジネスに私情を持ち込むべきではないが、個人的には子供のころから大洋ファンだった。秋山（登）選手らいい選手がたくさんいたいい印象を、今のベイスターズにも持っている」</p>
</blockquote>

<p>
正味このくらい。よりにもよってそこかよ98年は無視かよというのはまず呆然だし、この潮田会長の年齢と秋山登の活躍時期を重ね合わせると、せいぜい小学校高学年くらいとか、その時代のほんの一部分しか語っていないにすぎない。かつて近鉄球団消滅の大騒動でライブドア・堀江、楽天・三木谷両氏を巻き込んでの買収競争を踏まえて眺めれば、何とも冷めきったものだ。
</p>

<p>
(ほんとは阪神タイガース株式を公開化しようとしてこれまた物議を醸した村上ファンドのことも思い出すんだけど、あの頃の村上氏のコメントや姿勢やらを覚えてないのよね。)
</p>

<p>
この2004年前後当時、あれだけ騒がれた球界再編問題も今や全く何も言われなくなってしまった。その一方でNPBは「地域密着」をうたうようになった。スワローズは「東京ヤクルト」、ライオンズは「埼玉西武」となり、チーム名に地域名を冠して地元に良い顔をするようになった。その十何年も先を行っていたはずの横浜ベイスターズはしかし、そこから後退しようとしている。
</p>

<p>
<a href="http://www.nikkansports.com/baseball/news/p-bb-tp0-20101013-689663.html">http://www.nikkansports.com/baseball/news/p-bb-tp0-20101013-689663.html</a><br/>
チーム名「リクシル」示唆、10月中合意へ - 野球ニュース : nikkansports.com
</p>

<p>
今回のことはつまり、NPBが地元に向けて「地域密着」を語りかけるその顔は全くの嘘、作り物ですよと宣言したに等しい。
</p>

<p>
<a href="http://www.nikkansports.com/baseball/news/p-bb-tp0-20101003-686089.html">http://www.nikkansports.com/baseball/news/p-bb-tp0-20101003-686089.html</a><br/>
横浜買収ノジマ名乗り、地元残留訴える - 野球ニュース : nikkansports.com
</p>

<p>
本当に「地域密着」を謳い文句にしたいなら、ノジマの挙手は渡りに船のはずだ。住生活グループがどれだけ良い条件で受けようとしているのか知らないが、せめて等しく交渉のテーブルに着かせて対話をとるべきではないのか。
</p>

<p>
しかし私はこの話の当初からNPBはそうしないだろうと思っていたし、実際そうなりつつある。そして住生活潮田会長は横浜から出て行く可能性を全く隠そうとしない。そこに疑義が挟まるのは自然な成り行きであろう。
</p>

<p>
<a href="http://www.asahi.com/sports/update/1014/TKY201010140401.html">http://www.asahi.com/sports/update/1014/TKY201010140401.html</a><br/>
asahi.com（朝日新聞社）：横浜買収「宣伝できればいいのか」　住生活を知事批判 - スポーツ
</p>

<p>
松沢知事のこの指摘は確かに的外れであったかもしれない。NPBは何はなくともまずは「宣伝第一」なのだ。しかし、彼らがそこに「地域密着」の仮面を被って振る舞い、地元にファンに良い顔をしようとしたのは紛れも無い事実だ。その精神からすれば今回のように何とか残ってくれないかという地元の声や努力も聞き流し見え見えの出来レースを誰憚ること無く繰り広げて涼しい顔をするなど、到底できないはずだ。
</p>

<p>
知事にはそのつもりはおそらくなかっただろうが、この指摘はNPBに対して「地域と企業のどっちを取るのか」と踏み絵を迫った構図になり、NPBは彼ら自身何を今更当然知ってんだろあんたらくらいのつもりで返したんだろうが、「企業様が第一でござい」とにべもない体を成したと。何のことは無い、集約すればそこだ。
</p>

<p>
<a href="http://www.sanspo.com/baseball/news/101015/bse1010150504001-n1.htm">http://www.sanspo.com/baseball/news/101015/bse1010150504001-n1.htm</a><br/>
横浜・若林オーナー異論「知事の勘違いでは」 - 野球 - SANSPO.COM
</p>

<p>
このTBS・若林現横浜オーナーからしてこのシッポの振りよう(そこで経営難に喘ぐヴェルディ&mdash;<a href="http://www1.xebio.co.jp/pdf_press/東京ヴェルディとの包括スポンサー契約について.pdf">でも何とかスポンサーも見つかってよかったね！</a>&mdash;を引き合いに出してるのはそういう意図なんだろうか(苦笑))なのだから、松沢知事としては取りつく島も無い。おそらく、オーナー会議では身売りの条件から売却後の運営方針移転の有無など、だいたいの想定されるシナリオ大枠が出来上がって合意が取れているのであろう。細部が煮詰まり次第、涼しい顔で記者会見がセッティングされるものと思われる。
</p>

<p>
ちゃんちゃらおかしいけどね。
</p>

<p>
この「身売り劇」...まさに「劇」、球団売却における全てのプロセスはおそらく明かされないまま、まさに「密室談合(笑)」で筋書きに沿って決まって行くことだろう。何故住生活だったのか、何故ノジマはダメなのか、多くの何故を闇に葬り、何食わぬ顔で来季を迎えようとすることだろう。しかしてその姿は、身内だけに媚び、ファンの興味は引かず、地元も顧みない、ただの秘密クラブである。ようこそ桃色クラブへとか看板でも出したらいい。きゃーミッチー。
</p>

<p>
いいんですよ別に、NPBが企業第一でも。でもそれだったら、そのように言って振る舞ってくれた方がすっきりするし、やりやすいってもんですよ。中途半端にJリーグのマネして「こんな風にしてりゃ地元やファンは満足なんだろ」なんて馬鹿にするのもいい加減にしろと言っている。松沢知事の指摘が「うっとうしい」ってそりゃ、そうなるようにNPB(とベイスターズ、てかマルハ？)が詐欺にかけたんだから。当然でしょ。
</p>

<p>
<a href="http://www.nikkansports.com/baseball/news/f-bb-tp0-20101018-691597.html">http://www.nikkansports.com/baseball/news/f-bb-tp0-20101018-691597.html</a><br/>
「宣伝目的」発言に不快感　住生活会長 - 野球ニュース : nikkansports.com
</p>

<p>
願わくば、このような唾棄すべき茶番劇に、泉田さんや篠田さんがのこのこ首をつっこんだりすることなどなきよう。もうね。フランチャイズなんて奴らNPBにとってはただの寄生先ってことなんだから。
</p>

<p>
<a href="http://www.sponichi.co.jp/baseball/flash/KFullFlash20101001049.html">http://www.sponichi.co.jp/baseball/flash/KFullFlash20101001049.html</a><br/>
乗り気な新潟知事　横浜　準本拠地化なら「歓迎したい」（野球） ― スポニチ Sponichi Annex ニュース
</p>

<p>
<a href="http://sankei.jp.msn.com/sports/baseball/101002/bbl1010022119021-n1.htm">http://sankei.jp.msn.com/sports/baseball/101002/bbl1010022119021-n1.htm</a><br/>
【プロ野球】新潟市長「誠意見せたい」　横浜の試合誘致に - MSN産経ニュース
</p>]]>
        
    </content>
</entry>

<entry>
    <title>古のMSX関連の書籍が発掘されたので読み返していた。</title>
    <link rel="alternate" type="text/html" href="http://blog.foursics.jp/hironobu/2010/09/old-msx-books.html" />
    <id>tag:blog.foursics.jp,2010:/hironobu//2.330</id>

    <published>2010-09-25T14:50:30Z</published>
    <updated>2010-09-25T16:31:16Z</updated>

    <summary> 先日実家に帰る機会があったので、ついでに兼ねてから始末しろしろと言われていた置...</summary>
    <author>
        <name>Hironobu Koura</name>
        
    </author>
    
        <category term="comp" scheme="http://www.sixapart.com/ns/types#category" />
    
        <category term="life" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://blog.foursics.jp/hironobu/">
        <![CDATA[<p>
先日実家に帰る機会があったので、ついでに兼ねてから始末しろしろと言われていた置きっぱなしの本やら雑誌やらをいろいろ引き取るなり始末するなりやってきた。
</p>

<p>
で、いろいろあった中でMSX関連の本がいくつも残ってたのでこいつを持って来た。もうちょっとあった気もするけど、こんなもんか。
</p>

<img alt="msx-books.png" src="http://blog.foursics.jp/hironobu/2010/09/25/msx-books.png" width="320" height="240" class="mt-image-left" style="float: left; margin: 0 20px 20px 0;" />

<p>
読み返してみるといろんなことを忘れてるなあと。Z80のマシン語そのものは置いておく(x86のそれを見てるといろいろ思い出すところがあるからねえ)としても、やれスプライトがどうとか割り込みがどうとかI/Oポートがどうとか、あと多色刷りなんてのもあったなあ。
</p>

<p>
今のPCだと複雑度が増した分、直接さわってる感が少ないけどこの頃は楽しかったなあとも思う一方で、この頃苦労してたあの辺の話題が今はこうなったんだな、的な感慨がひとしおで、これは手元に持って来てよかった、てかこのまま取っておくべきだなと思った。裁断とかデジタル化はたぶんしない。...たぶん。
</p>

<br style="clear: both;">
<p>
あとMSXじゃないけどこんなのも↓あったよ。
</p>

<a href="http://blog.foursics.jp/hironobu/2010/09/25/old-magazine.png"><img alt="old-magazine.png" src="http://blog.foursics.jp/hironobu/assets_c/2010/09/old-magazine-thumb-239x320-22.png" width="239" height="320" class="mt-image-left" style="float: left; margin: 0 20px 20px 0;" /></a>]]>
        
    </content>
</entry>

</feed>

