Facebookの恥汚染、数千の架空IDは、どうもあの国の仕業らしいの証拠 | More Access,More Fun!

友達数が500人以上と、「会ってない人と友達になっているのが明らかな、脇が甘い人」を狙って友人申請 複数の同一企業のOBと友人になった上で、同じ企業に勤務している人に友人申請 実在してそうな企業名にする

SNSを使ったソーシャルハッキングの第一歩って感じか。俺はFacebookとか知り合いじゃない人はフレンド申請されても無視してるなー。知り合いの知り合いとか、同じ出身地とか学校とか言われても、それは友達じゃないよ。誰でもいいから知り合い増やしたいとかも思ってないし。

cocos2dで簡単なゲーム作っていくよ（まとめ・サンプルコードあり） | リンゴにかじられたブログ

cocos2d for iphoneで簡単なゲームを作っていく。完成済み＆ソースコードはgithubで公開。

Twitter（別名デマッター）でネットジャーナリストを釣る方法（フリージャーナリスト） - 愛・蔵太のもう少し調べて書きたい日記

相変わらずお元気ですね。そしてそのコメント欄に感情的に書き込んじゃう人たち……。

 

ATPファイナル（最終戦）の組み合わせが発表された。

• グループA
• ジョコビッチ
• マレー
• フェレール
• ベルディヒ
• グループB
• ナダル
• フェデラー
• ツォンガ
• フィッシュ

グループAは、ジョコビッチの肩がどのくらい治っているか。8割くらい戻っていれば、マレー以外には通じそうだけど、フェレールなんかは多少振り回してもミスせずついてくるだろうし、そうすると消耗戦になってしまって、ラウンドロビンを戦い抜くだけで、すり切れてしまいそうだ。

マレーはラウンドロビン抜けは問題ないだろう。ジョコビッチが力尽きた場合は、フェレールよりはベルディヒかなー。

グループBは、珍しくナダルとフェデラーが同じ組になった。というか、これはインドアハードでのナダル包囲網って感じの面子だな。といっても最終戦のメンバーの中で、このコートでナダルの方が分が良さそうな相手はフェレールくらいだし、単に最終戦の面子とコートの組み合わせがナダルに厳しいってだけか。

フェデラーは余裕の一抜けだろうなー。フェデラーとナダルが何試合目に当たるんだろう。早めに当たるとフェデラー有利、後で当たるとナダルもそれなりに戦えるようになってきそう。

それでもこのグループはナダルよりもツォンガの方が抜けて来そうだ。フィッシュは怪我の具合はどうだろう。この面子だと、万全の体調でも一勝するのもきつそうだが。

一応ラウンドロビンの結果を予想してみる。

グループA

	ジョコビッチ	マレー	フェレール	ベルディヒ
ジョコビッチ		1-2	2-1	2-0	2勝1敗(2位)
マレー	2-1		2-0	2-0	3勝0敗(1位)
フェレール	1-2	0-2		1-2	0勝3敗
ベルディヒ	0-2	0-2	2-1		1勝2敗

グループB

	ナダル	フェデラー	ツォンガ	フィッシュ
ナダル		0-2	1-2	2-1	1勝2敗
フェデラー	2-0		2-1	2-0	3勝0敗(1位)
ツォンガ	2-1	1-2		1-2	1勝2敗(2位)
フィッシュ	1-2	0-2	2-1		1勝2敗

休養十分のナダルでも、この面子とこのコートではあまりいい結果が出ないと予想。ジョコビッチに関しては今シーズンこれだけ活躍したんだから、最終戦ではこのくらいの結果は残して欲しいという願望が多く入っている。実際にはラウンドロビンの途中でキャンセルしてもおかしくないと思っている。決勝はフェデラー vs. マレーかな。

ロンドンハーツ 2011/11/8

男の自分番付。もう飽きてきたな。

アメトーーク 2011/11/10

有吉のプレゼン企画。芸人の新ルールを考えよう‼

楽屋への挨拶。本番前の打ち合わせ。番組の強引なアンケート。大御所や俳優とのカラミ。評価表。却下。ロケ始まりの少し歩き。タクシーの見送り。全体として、さま～ずの立ち位置。

ブラマヨとゆかいな仲間たち　アツアツっ！ 2011/11/12

原口あきまさ。ものまね芸人の扱い。似ているより面白い。デフォルメはやり尽くされた。モノマネする勇気。

西澤保彦 殺す

「猟死の果て」の改題版だった。やられた。作者の新刊アラートしかけて買っているとこういうのにときどき引っかかる。乙一の平面犬とか。内容は、西澤保彦にしてはいまいち。

ハロルド作石 7人のシェイクスピア 5

メインの男の子供の頃の話。そして宗教。ひたすら不幸でフラストレーションがたまる話。

井上雄彦 REAL 11

野宮のトライアウトチャレンジ。十分健闘したが、これでなんとか合格してチームを変えていく話になるというのは、現状だと厳しそうだよなー。

JUNK 伊集院光 深夜の馬鹿力 2011/11/15

新幹線の空いているグリーン席で見知らぬおっさんと隣同士。なにゆえ？

奥さんと結婚記念旅行でお伊勢参り。お互い体調不良で意地の張り合い。ここのトークはまるでたけしみたいだったな。「…なんて言っちゃったりして」の連発。

最近BUMPっぽいバンドがすごい増えたな。BUMPは昔のBOOWYみたいな扱いになってるのか？

繁忙期以外の平日は、ぎりぎりになると格安のいい宿がネット予約に出てくるから、当日予約がお得らしい。知らなかった。今度試してみよう。

伊勢うどん。ふにゃふにゃの腰のないうどん。

ソニーのヘッドマウントディスプレイ。深海と宇宙とエロ。3D潮吹き。思わずよける。誰もいない部屋でHMDでエロビデオを観ているときにケーブルが膝に当たる。「誰かいる！」

自慰メン。賢者モードになったときの伊集院のテーマ曲。鈴木ヒロミツ「でも、何かが違う」。「また、つまらぬものを斬ってしまった…」

APIコールしたときの結果として、パラメータとして?format=xmlと書いたらXML形式で、?format=jsonと書いたらJSON形式で結果を返すようなやつを、どう書けばいいのか。

もちろんそれぞれ別々にアクションメソッドを用意するとか、ビューだけを差し替えるとかいろいろ手があるけれども、JSONに関してはJsonResultという便利なクラスが用意されているんで、それを使いたい。 元となる結果データは、シリアライズされること前提でクラスで定義することにした。

[sourcecode language="c#"]
public class ApiResult
{
  public string StringResult;
  public int IntResult;
  public bool BoolResult;
  public StringDictionary parameters = new StringDictionary();
}
[/sourcecode]

こんな感じの結果クラスを用意しておいて、

[sourcecode language="c#"]
public  ActionResult SomeApiCall(string format)
{
  ApiResult result = new ApiResult();
  // resultにいろいろセットする
  switch (format) {
    case "json":
      return Json[result];
    case "xml":
      var serializer = new XmlSerializer(typeof(ApiResult));
      var stream = new TextWriter(new StringBuilder());
      serializer.Serialize(stream, result);
      var xmlResult = new ContentResult();
      xmlResult.Content = stream.ToString();
      xmlResult.ContentType = "text/xml";
      return xmlResult;
  }
}
[/sourcecode]

こんな感じでいけるかと思っていたんだけど、JSONは思い通りにできたのに、XMLの方が思ったよりも大変だった。というのは、XmlSerializerがDictionaryのたぐいをシリアライズしてくれないから。

で、[PC][C]C#::DictionaryをXMLSerializerでシリアライズしたいんですが？を見つけて、これでDictionaryをXMLシリアライズしようと思ったんだけど、これでシリアライズすると、

[sourcecode language="xml"] keyname value [/sourcecode]

みたいな感じのXMLとしてシリアライズされる。JSON相当に読みやすい表現の

[sourcecode language="xml"] value [/sourcecode]

になってくれないかなー。というわけで試しに作ってみた。

[sourcecode language="c#"]
    public class SerializableDictionary : Dictionary, IXmlSerializable
    {
        public System.Xml.Schema.XmlSchema GetSchema()
        {
            return null;
        }


    public void ReadXml(System.Xml.XmlReader reader)
    {
        string key = null;
        object value = null;
        while (reader.Read())
        {
            switch (reader.NodeType)
            {

                case System.Xml.XmlNodeType.Element:
                    key = reader.Name;
                    break;
                case System.Xml.XmlNodeType.Text:
                    value = reader.Value;
                    break;
                case System.Xml.XmlNodeType.EndElement:
                    if (!string.IsNullOrEmpty(key))
                    {
                        this[key] = value;
                    }
                    else
                    {
                        reader.Read();
                        return;
                    }
                    key = null;
                    value = null;
                    break;
            }
        }
    }

    public void WriteXml(System.Xml.XmlWriter writer)
    {
        foreach (var key in Keys)
        {
            writer.WriteStartElement(key.ToString());
            writer.WriteString(this[key].ToString());
            writer.WriteEndElement();
        }
    }
}


[/sourcecode]

汎用Dictionary<Tkey, Tvalue>の場合の扱い方がよくわからなかったんで、Dictionary<string, object>に限定。あと、valueがさらに階層化されている場合の処理の書き方もわからなかったんで、一次元のDictionaryにしか対応しない。あとNode名としての妥当性チェックとかもしていない。といろいろ課題はあるけど、動く範囲では動く。

これで、最初に書いたようにDictionaryを含むResultオブジェクトを生成しておいて、それをXMLなりJSONなりで出力するようなAPIコードが簡単に書けるようになった。

今日も予報が外れて強風。昨日よりも強く、風速5〜6m/hくらい。

それでも二日目になるとだいぶ慣れてきたんで、追い風、逆風側でいろいろ試してみた。特にポジションとフットワークに気をつけてみたところ、だいぶ風で流れる球に対する入り方が安定した。

ただ、球の深さにだいぶ対応できるようになってくると、今度は左右のズレ(風で流されるだけでなく、風で球にかかっている回転の効果も強調されるんで、バウンド後の左右への変化も大きくなる)への対応が難しくなってきた。左右のズレへの心構えは、深さとはまた別の意識を持つ必要がありそうだけど、まだその具体的なコツは見つからず。

最後の方は、ネットプレイの頻度を増やしてみたんだけど、結果はぼろぼろ。風で変化する球相手にネットに出るのは、いつもにも増して難しい。途中までの軌道で打点を予測してボレーをしている場合は、ことごとく失敗する。最後までちゃんと球を見ないとなー。

そして練習が終わる頃には風がほとんど止んで、とてもいいテニス日和になっていた。今から始める人たちは幸せだねー。明日は風がないといいけど。

高速化を果たしたjQuery Mobile RC3公開。問題がなければ今週中にこのまま正式版へ！ － Publickey

速度的には微妙だったのが、だいぶましになったのか。どちらにしろモバイル向けWebアプリ向けデザインフレームワークとしてはこれ一択のつもりだけど。

Twitterを代表するツイートクリエイターのお歴々が憤怒！！ - Togetter

Twitter（別名デマッター）でネットジャーナリストを釣る方法（フリージャーナリスト） - 愛・蔵太のもう少し調べて書きたい日記にマジギレする人々。コメント欄よりもこっちの方が面白いことになっていたのか。

ザック日本、北朝鮮恐怖の４０時間「夢に出てきそう」：日本代表：サッカー：スポーツ報知

入国審査では「細密な検査」（北朝鮮）のため４時間の足止めを受けた。待機中、選手が備え付けの柵や壁に寄りかかろうとすると「北朝鮮の物に触れるな」と怒声を浴びせられたという。

宿泊した部屋には壁一面に大きな鏡。そのほかにも至る所に鏡が設置されていた。

今日は久しぶりに風もなく、曇りの割にはそれほど寒くもないテニス日和。だったんだけど、序盤で練習相手が右足を捻挫してしまい、普段のメニューの半分もこなさないうちに練習終了。

ちょっと前まで枯れ葉が大量にコート内に落ちていて、それが滑って危なかったんだけど、この数日の強風で枯れ葉もほとんどなくなり、だいぶコート状況も良くなってきたなーと思っていた。しかしその強風で折れた小枝がそこかしこに落ちていたらしい。練習相手はそのうちの大きめの一つを踏んで、足首をひねってしまった模様。そういえば俺もここ数日何回か2～3センチ程度の小枝を踏んで、踏み込んだ足がちょっとずれたことがあったなー。秋口はコート上の細かい落下物に気をつけないと。

といった感じで、テニスの練習はあまりできなかったんで、代わりにランニングを数キロ追加。捻挫はあまり軽傷では済まなかったようなので、来週の練習も厳しそうだな。

マツコ・有吉の怒り新党 2011/11/9

レトリバーにマウントされてもいい覚悟を決めて可愛がれ。マツコ、レトリバーの気持ちになる。

類似番組。元祖が勝つ。そうかなー、勝った（最初にメジャーになった）のが元祖扱いされてるだけじゃね。

男はつらいよ。今観ると面白い。

久慈光久 狼の口 ヴォルフスムント 3

安定して面白い。佐藤賢一の小説とテイストが似ているな。正義が必ずしも勝つとは限らないし、たとえ最後に勝てたとしても、その道程にはむごい目に遭った仲間達の屍が倒れ伏している。

しょうもない誤植が気になるな。束い？　下司（げし）ってのは正しいのか？　下衆（げす）と書きたかったのかな？　まあ下司（げし）でも間違いではないっぽいけど。

ラジウム発見されたら大変　検査に撤去、処分には数千万円も＋（1/2ページ） - MSN産経ニュース

東京都世田谷区で相次いで発見された“出所不明”のラジウム入りの瓶の撤去や処分に、場合によっては数千万円もの費用がかかる恐れが出ている。しかも土地・建物の所有者が全額を負担しなければならない

烏賀陽弘道氏と葛田徳之氏のツイートのまとめ - Togetter

一夜明けてからの烏賀陽氏の非暴力主義者への豹変が一番の見所かなー。あと、身内からも見捨てられていき、被害妄想的に超能力的パラフレーズで反論し始めるあたりもじわじわくる。

『ガキ使』大みそ日SPは「笑ってはいけない空港」～“CA”として過去最大規模の挑戦 | ニコニコニュース 

今年もやるのか。最近時間を長くしすぎだと思うんだが。3時間くらいでいいんじゃないの。

イタリアと大阪の実に困った相似：日経ビジネスオンライン

大阪でこれから起こることの一部始終を、私たちは、よく見ておこうではないか。

観察と学習は、きっと、後々、役に立つことになるはずだ。

最速自炊カメラ「Jucie」（仮）が電子書籍の自炊の常識を覆すほどのポテンシャルを秘めていた件 - もとまか日記乙

iPhoneのカメラで、本をカメラの枠内に捉えておいて、ページめくりをきっかけに写真撮影→各ページの画像がどんどん撮影できる→非破壊自炊、という仕組み。面白い発想だ。

［速報］jQuery Mobile 1.0正式版が公開！ モバイルアプリケーション開発の新時代へ － Publickey

ｊQuery MobileとPhoneGapでどの程度のものが作れるんだろう。暇になったら試してみよう。

<追記>試しにjQuery Mobileで作りかけだったサイトをHTMLファイルに落としてからPhoneGapのwwwディレクトリに入れてみたら、UIは普通に動くな。APIコールの部分をPhoneGapのConnection APIとStorage APIを使って書き直せば、Webサイトのオフラインクライアントアプリとかはかなり簡単に作れそう。</追記>

NOTE by Hiromi Kubota: 楽天レシピはなぜクックパッドに勝てないのか？（The reason Rakuten-recipe can't beat Cookpad）

同じレシピの投稿をするならお金にならないクックパッドより楽天レシピに投稿するに決まっている。これだけのアドバンテージがあればいくらなんでもクックパッドもやばいだろう。そう思っていたはず

報酬が金銭的インセンティブに変わると、「たのしみ」でしていた作業は「報酬をもらうため」という別の動機づけに置き換えられてしまい、とたんに「たのしくなくなる」＝〈ソーヤー効果〉

楽天レシピって立ち上げた当時話題になった後はほとんど聞かないなーと思っていたら、こういうことになっていたのか。俺もいまだにクックパッド見てるしなー。

Car Watch トヨタ、実写「ドラえもん」第2弾にドラえもんとしずかちゃん登場

やっぱりスネ夫の姿はちゃんとしたニュースサイトにはないか。ジャニーズ強し。「山下智久 スネ夫 」で Google画像検索すると、ちょっとだけ見られる。

CRUD機能を自動生成するとビュー内で使われている、HtmlHelperのEditorForメソッド。モデルオブジェクトから各要素の型や名前を取得して、妥当な編集用フォームタグを生成してくれるのはいいんだけど、気軽にカスタマイズさせてくれないようだ。

たとえば、テキストの分量によってinput type="text"にHTML属性を追加してsize="80"とかしたり、長文テキストが入るからtextareaに差し替えようと思っても、メソッドにパラメータを追加して何とかするような方法は用意されていない。

表示をカスタマイズしたければ別途テンプレートファイルを用意して、それを使ってレンダリングするようにしてやらなければならない。

HtmlHelper.EditorForメソッドの中の、

[sourcecode language="c#"]
public static MvcHtmlString EditorFor(
  this HtmlHelper html,
  Expression> expression,
  string templateName
)
[/sourcecode]

みたいにtemplateNameパラメータをシグニチャに持つタイプ。このテンプレート関連の仕様が今ひとつわからないので調査。

EditorForModel メソッド (HtmlHelper, String)によれば、まずテンプレートファイルの検索順序としては、

templateName パラメーターと名前が一致するテンプレートが、コントローラーの EditorTemplates フォルダーにある場合は、そのテンプレートが、モデルのレンダリングに使用されます。 コントローラーの EditorTemplates フォルダーにテンプレートが見つからない場合は、templateName パラメーターの名前と一致するテンプレートが Views\Shared\EditorTemplates フォルダーで検索されます。 テンプレートが見つからない場合は、既定のテンプレートが使用されます。

となっている。アプリケーション全体で共用したい場合は、Views\Shared\EditorTemplatesフォルダ内、各コントローラごとに同名のテンプレートを使い分けたい場合は各コントローラ用のViewフォルダ内（FooController.csで使うならばViews\Foo\EditorTemplatesフォルダ）に置くと。

さらに、モデルクラスのプロパティのデフォルトテンプレートを指定したければ、

[sourcecode language="c#"] [UIHint("FooTemplate")] public string FooProperty {get; set;} [/sourcecode]

なんて感じでUIHint属性をつけると、自動的にそのテンプレートが使われると書いてある。けど、元のモデルクラスがADO.NET Entity Frameworkで自動生成されたクラスの場合は、どうすればいいんだ？

普通に考えたら、自動生成されるpartial classで定義されるプロパティに、別ファイルでpartial classを定義して同名プロパティに属性を追加する方法、なんてなさそうだけど。実際やってみたら曖昧な二重定義扱いにされてコンパイルが通らないし。

と思ったら、チュートリアル: ASP.NET MVC でのテンプレート化されたヘルパーを使用したデータの表示というドキュメントを発見。その中の、

[sourcecode language="c#"]
using System.ComponentModel.DataAnnotations;
namespace MvcTmpHlprs {
  [MetadataType(typeof(ProductMD))]
  public partial class Product {
    public class ProductMD {
      public object SellStartDate { get; set; }
      [UIHint("rbDate")]
      public object SellEndDate { get; set; }
      [DataType(DataType.Date)]
      public object DiscontinuedDate { get; set; }
      [ScaffoldColumn(false)]
      public object ModifiedDate { get; set; }
      [ScaffoldColumn(false)]
      public object rowguid { get; set; }
      [ScaffoldColumn(false)]
      public object ThumbnailPhotoFileName { get; set; }
    }
  }
}
[/sourcecode]

というサンプルコードが肝。

ADO.NET Entiry Frameworkで自動生成されたpatial class（サンプルではProduct）にMetadataType(typeof(メタデータを定義するクラス名))という属性をつけておき、メタデータを定義するクラス（サンプルコードではProductMD）では、追加属性をつけたいプロパティのシグニチャと追加する属性（UIHintとか）を定義する。すると、ほかのファイルで実装されているpartial classのプロパティに対して、別ファイルから属性を追加することができるようだ。うわー、気色悪い仕様。

でもまあこれで、ADO.NET Entity Frameworkで自動生成されたモデルクラス（テーブル）のプロパティ（カラム）に対して、その表示や編集に使用されるビューテンプレートを指定できるようになった。実装コードとしてはとても気色悪いし、可読性も悪すぎるけれども。

ちなみにテンプレートファイルの記述方法（特にモデルデータの受け渡し方法）も、今ひとつわからないのだが、基本的にはビューを追加する際に出てくるダイアログで、「厳密に型指定されたビューを作成する」＆「部分ビューとして作成する」を選択し、「モデルクラス」として対応するプロパティの型を指定してやればいいんだろう。そうするとビュー内ではModelという名前でプロパティの値にアクセスできる。