ブログ移転のお知らせ

いつもご訪問頂きありがとうございます。
Yahoo! ブログのサービス終了に伴い、ブログを移転いたします。
移転先: http://blog.a32kita.net/
詳細は、こちらの記事をご覧ください。

Yahoo! ブログでは最後の更新となります。

先月下旬、 Yahoo! ブログ公式の移行ツールではサポートされないトラックバックやコメントなどのデータを「個人用に取得する」ツールを開発していると紹介いたしましたが、

ごめんなさい。

間に合いませんでした。

言い訳としてはお盆の間も思いの外忙しかったや、 d! アニメで古いアニメ漁ってたらうっかりハマってしまった等々いろいろございますが、納期を守れないのはエンジニアとしてまだまだ未熟という証ですね ((

とはいえ、何も無いわけではないんです。

先程 master にマージしていまこんな状態、、

以下の機能の実装はできました

・ブログの基本データ (タイトル、開設日、著者名) を取得する機能

・「すべての記事」をクロールして、投稿記事の ID を片っ端から取得する機能

・投稿記事の ID から投稿先書庫などを取得する機能

…すべてスクレイピングの力技です。

ということでビルド済みバイナリでの公開は許してください (

以上の実装できた機能をもとに、とりあえず全ての記事のソースを取得するだけの「Simple Downloader」なるツールは一応動く状態にしておきました。

最新の記事から順番に HTML ソースを片っ端から PC に DL するだけのツールです。

こんな感じで書庫別に HTML ファイルが落ちてきます。

Windows 向けで Visual Studio などの C# のビルド環境をお持ちの方は、どうぞお好きにビルドしてみてください。

完全にサービスが終了する 12 月まで少しずつアップデートを続けます。

投稿機能が無効化される前にこれだけ置いていきますね。

というわけで皆様お元気で。

では。

以前よりアナウンスされておりましたTwitterのUserStreamAPIの公開終了がいよいよ実施されます。

これにより、大多数のサードパティ製Twitterクライアントが致命的なダメージを食らうことになります。

幸いなことに（？）、私はUserStreamについては無影響です。

以前はkarno氏のKrileにお世話になっておりましたが、この頃はブラウザでtwitter.comを使うか、スマホでは公式クライアントでしたので。

また、現在Webサイトにて公開しているTwitter関連ソフトウェアの中にもUserStreamを使用しているアプリケーションはございません。

ただし今回のAPI改定、実はUserStreamだけではないんです。

もう1つ大きく変更が加わるのがDM（Direct Message)…。

こちらは公開終了ではなく代替の別のAPIへの移行という形になります。

公開しているソフトウェアの中ではDM関連は使用しておりませんが、私が個人的にサーバで動かしているシステムでは使用しているため、こちらは改修するか除去する他ないでしょうね（

かなり以前からアナウンスされておりましたが、実際に停止されて影響が出始めてからでないと、対応する気が起きないんですよね、、あくまでも趣味ですから（

しかしながらこのTwitterAPI、9月には今度はルールの改定があり、そこではAPIの使用自体がかなり厳しくなりそうです。

UserStreamについては、以前から私もTwitter社にとってマネタイズ面含めてメリットが無いと感じており、こちらの停止については納得できる部分もございます。

しかしながら、APIの使用条件自体の改定は、、

スパムの原因となるアプリケーションを遮断することが目的とのことですが、パクツイ垢とかあれだけ野放しになってる状況で、どうも痒いところに手がとどかない対応が続いており、個人的にはやや不満です。。

まぁ、何を言っても所詮は無料で使わせてもらっているサービス。

文句は言えませんね。

はい。

長々と愚痴のような駄文、失礼しました。

後日、API騒動で再びTwitterユーザー間で再燃しているMastodon関連についての記事も書きます。

では。

図1 クラスライブラリで追加可能なWPF関連項目

図2 テキストファイルの追加

図3 無効なマークアップ

図4 XAML項目のプロパティ

表1 XAMLファイルとして扱わせるためのファイルのプロパティ値

具体的には，Visual Studioで編集する際は，XAML専用のモードで開かれ，また，ビルド時にはXAMLの定義データとして正しくビルドされるようになります．

(4)XAMLの記述

あとは、通常通りResourceDictionaryを定義していきます。

【解説】ビルド アクション「Page」

図4に示したとおり、XAMLファイルのビルドアクションは「Page」に設定する必要があります。
このPageについて解説をば。

XAMLの記述によって定義されたデータは、ビルド時に特殊な処理が行われます。


XAMLファイルは通常のC#コードとは違い、ILコードには変換されません。出力されたアセンブリをildasmで定義したResourceDictionaryなどを探してみると、クラスとして扱われていないのがわかるかと思います。
※UserControlやWindowなどのXAML定義はロード用・コード記述用のクラスが作成されます。

XAMLはビルド時に「BAML」というXAMLを読み込みやすくバイナリデータ化したものに変換され、出力されるアセンブリに格納されます。
その際変換元となったXAMLファイルに基づき、BAMLデータにも識別名が振られるようです。これは実行時にBAMLからインスタンスを作成する際に利用しますが、詳細については後述します。

どうやら、その「BAMLへ変換，並びにBAMLデータのアセンブリへの埋め込み」という指示を表しているのがビルドアクション「Page」のようです。
やや検証不足気味ですが。。

やや余談ですが、XAMLとBAML、実行時に生成されるインスタンスは次のような処理関係になります。


XAMLデータをファイルなどのStreamから読み込んでインスタンスを生成する「XamlReader」というクラスが実は存在しております．

しかし後でも触れますが，XAMLなどをはじめとするXMLデータのパース及びロードには実行コストが発生します．

ビルド時に予め，XAMLを読み込みやすいBAMLに変換することで，実行時に余計なロードコストが発生することを防いでいるようです．

XAMLをC#コードに変換して，そのあとに通常のコードと一緒にILにコンパイルするような仕組みを取っていると思っていたのですが，そうではなかったんですね．．．

XAMLを利用する（XAML）

UserControlなどのXAMLで、定義したResourceDictionaryを利用する場合は図7のように記述します。


ResourceDictionaryのプロパティ「Source」にXAMLのUriを指定することで参照することが可能です。
XAMLのUriについては、後述の「XAMLを参照する際のUriについて」をご覧ください。
ソリューションをビルドするまでは、ResourceDictionaryの定義内容がUserControlのデザイナに反映されない場合がございます。

すでにUserControl内で定義したResourceDictionaryと合わせて利用したい場合は、新しくResourceDictionaryを作成し、MergedDictionariesで追加してあげると良いでしょう。

XAMLを利用する（C#コード）

XAMLで定義したResourceDictionaryなどをC#のコード上で利用したい場合は、まずロードしてインスタンスを作成する必要があります。
ロードは、 System.Windows.Application 名前空間の LoadComponent メソッドを利用します。

Application.LoadComponent(new Uri("SampleClassLibrary;component/sampleresources.xaml", UriKind.Relative));

LoadComponentメソッドは指定したUriのXAMLをロードしてインスタンス化してくれるメソッドです。
戻り値はObject型になっておりますが、例えば、ResourceDictionaryを定義したXAMLをロードした場合は、そのままResourceDictionaryにキャストすることが可能です。

このとき指定するUriについては、後述の「XAMLを参照する際のUriについて」をご覧ください。

【解説】XAMLを参照する際のUriについて

XAMLの定義を利用するためには、XAMLのUriを指定して、ロードする必要があります。
Uriは通常Web上のコンテンツやローカルファイルのパスなどを指定する際に用いる型ですが、どうもWPFではアセンブリ内に格納された特殊なリソースを参照する際にも利用可能なようです。

その際のUriは文字列から初期化しますが、構文は次のとおり。

[アセンブリ名];component/[プロジェクト内でのパス(すべて小文字で)]

アセンブリ名は、恐らく出力アセンブリファイル名かプロジェクト名がこれに該当するのですが、通常はこの2つは一致するため、どちらが正解かは未検証です。
また、プロジェクト内でのパスも実際のcsprojファイルからの相対パスになるのか、あるいはcsproj内での論理パスになるのかは未検証です。既存のXAMLファイルをリンクで取り込んだ際は注意が必要です。

Uriの例

前述のサンプル「SampleClassLibrary」ではプロジェクトのルートに「SampleResources.xaml」を追加しました。
これを参照する際のUriは

SampleClassLibrary;component/sampleresources.xaml

になります。

また、プロジェクト内で「SampleDir」というディレクトリを作成し、その中に「Hoge.xaml」を定義した場合のUriは

SampleClassLibrary;component/sampledir/hoge.xaml

になります。

この辺は、通常のUserControlに対してVisualStudioが自動生成したラッパクラスの中身を見ただけなので、もっと深く調べる必要がありそうですね。

余談「ControlTemplateをXAMLで定義してみた」

コードから参照して利用する場合、ResourceDictionary以外でもXAMLに定義することが可能です。


ControlTemplateは、XAMLで記述する場合、XAMLからのロードの都合もあり、通常はResourceDictionary内で定義しますが、ControlTemplateをコードから呼び出して利用したい状況が発生しましたので、ResourceDictionaryを省略して直接定義してみました。
正攻法とは言えないでしょうが、ControlTemplateを直接XAMLで定義すると、デザイナが仕事をしてくれるんですね。便利かも（？）

ちなみに、サンプルイメージの配色がTheドイツ国旗って感じですが、実験用にわかりやすい配色がないか考えたら偶然ドイツ国旗が頭をよぎっただけです。
ドイツ国旗シンプルでかっこいいですけど、それをイカしたUIに活用するだけのデザイン力は僕にはありません。
あ、ちなみにドイツ国旗の3色のうち一番下の部分って黄色じゃなくて正確には金色みたいですね。

余談「Application.LoadComponentとXamlReader」

ぶっちゃけ頑張ってBAMLとしてアセンブリに挿入させることにこだわらずとも、リソースとしてぶちこんだXAMLファイルを実行時にXamlReaderでLoadしちゃうなんて手もなくはないです。
というか、この方法を思いつかなかった時は、そうしていました。

しかし、通常のリソースとしてXAMLデータを添付した場合、若干ちゃんとBAMLに変換させたときよりも時間がかかるようです。
そらそうですよね。
BAMLってのはビルド時にXAMLを読み込んで最適化した結果なのですから。

あとファイルサイズが変わります。
BAMLのほうがファイルサイズ小さいです。
リソースとしてXAMLファイルを取り込むとXAMLのソースがそのまま出力ファイル内に取り込まれます。
テキストエディタでバイナリを眺めるという意味不明な習性を持っている僕と致しましては、圧倒的にBAMLのほうがかっこいいバイナリになります（意味不明）


では。