Treadwell氏はまた、Microsoftは一部のホステッドサービスにAtomインターフェースを提供することによって、「Atom Publishing Protocol（Atom出版プロトコル）」に対するサポートの充実を図っているとも語った。

http://japan.cnet.com/news/media/story/0,2000056023,20368443,00.htm

大手企業では、言わずと知れたGoogleが既にGDataAPIとして、完成直前のAtomPubから派生（現在AtomPub仕様に軌道修正中）させたAPI群を提供しており、現在までAtomから少々距離を置いていたMicrosoftが、ここに来て発表するのはちょっとびっくりでした。（Microsoftのことだから、いつ何か捻くれたキックが飛び出してくないとも限りません。"the devils in the details"と言いますからね;-）　

もしかしたら、これはある意味、SOAPへの死亡宣告になるのかもしれません。

しかしながら、このMicrosoftの動きがGoogleの時のようなモメンタムを得られるか、というと、どうかなとも思います(*1)。理由は色々ありますが、そもそもMicrosoftのWeb API とか言ってもピンとこないケースが多いんじゃないなかと。米Yahoo買収してこの分野に入ろうとは苦労しているようですが...。
(*1)但し、今回発表された、ADO.NET Data ServicesのAtomPubサポートにより、企業ネットワークでは裏方で利用が広まる可能性がある。

日本では、先日、AtomPub Interop 2008 Tokyoが開催されました。NTT Communications某氏がホストをしてくださり、参加者はNTT、リコーなどから集まり、非常に有意義なInterop(相互接続実験)でした。私は一応、Fudeを持参させていただきました。（その後で食べた餃子は結構美味しかったｗ）

http://teahut.sakura.ne.jp/b/2008-01-30-1.html
http://blogs.ricollab.jp/webtech/2008/02/atompub_interop/

とりあえず、今回の発表の原文から、直訳及び意訳。

Atom Publishing Protocol (AtomPub) as the future direction
将来的な方向としてのAtomPub（Atom出版プロトコル）

Microsoft is making a large investment in unifying our developer platform protocols for services on the open, standards-based Atom format (RFC 4287) and the Atom Publishing Protocol (RFC 5023). At MIX we are enabling several new Live services with AtomPub endpoints which enable any HTTP-aware application to easily consume Atom feeds of photos and for unstructured application storage (see below for more details). Or you can use any Atom-aware public tools or libraries, such as .NET WCF Syndication to read or write these cloud service-based feeds.

 In addition, these same protocols and the same services are now ADO.NET Data Services (formerly known as “ Project Astoria”) compatible. This means we now support LINQ queries from .NET code directly against our service endpoints, leveraging a large amount of existing knowledge and tooling shared with on-premise SQL deployments.

マイクロソフトは、オープンな標準（規格）ベースのAtomフォーマット及び、Atom出版プロトコルを用いて、我々の種々のサービスで用いる開発プラットホームプロトコルを統合すべく、大きな投資を行っています。今回のMixにて、AtomPubを活用する、幾つかの新しいLiveサービスを有効にし（発表し？）、HTTPを解するどんなアプリケーションでも写真や非構造的？アプリケーションストレージのAtomフィードを活用できるでしょう。（省略） AtomPubをサポートする、ADO.NET Data Servicesで、LINQ to Atom（省略）

..

Application Based Storage

Application Based storage is an experimental API which allows application developers to store a small amount of state/configuration data in the Windows Live data centers on behalf of a user. This API has an AtomPub service end point so developers will be able to call this using ADO.NET data services or other AtomPub compatible tools. The real value kicks in here if an application was to have hundreds of thousands of users as the client bandwidth and storage are offloaded to Windows Live infrastructure. 

The service and documentation will be available next week.

アプリケーションベースのストレージ（Application Based storage）は、実験的なAPIで、アプリケーション開発者が、ユーザーのために、少々の状態または設定情報をWindows Liveのデータセンターに保存できるようにする、というものです。このAPIは、AtomPubのエンドポイントを提供しているので、開発者は、ADO.NETデータサービスや他のAtomPub互換ツールを使ってこのAPIを呼ぶことができます。（一行省略）

サービスとドキュメンテーションは、来週公開されます。

...

Windows Live Photo API (CTP Refresh with AtomPub end point)

The Windows Live Photo API allows users to securely grant permission (via Delegated Authentication) for a third party web site to create/read/update/delete on their photos store in Windows Live. The Photo API refresh has several things which make it easier and faster for third parties to implement.

• Third party web sites can now link/refer to images directly from the web browser so they no longer need to proxy images, and effectively save on image bandwidth bills.
• A new AtomPub end point which makes it even easier to integrate.

The service and documentation will be available next week.

Windows Live フォト API は、安全にサードパーティのウェブサイトに権限を与えて、Windows Live へ写真を追加、読み出し、更新、削除を行えるようにします。フォトAPIは、サードパーティの開発者が、より簡単にすばやく実装できるように、幾つかの特徴があります。

• サードパーティのウェブサイトから、直リンク出来ます。
• AtomPubにより、より簡便な相互運用が可能

サービスとドキュメンテーションは、来週公開されます。

http://dev.live.com/blogs/devlive/archive/2008/02/27/213.aspx

基本的には、こちらの英語版のページで更新情報を発信していく予定です。AtomPubを利用したウェブサービスの開発の助けになれば幸いです。

WordPress 2.3 beta 1 has significantly upgraded support for the Atom Publishing Protocol. - WordPress 2.3 ♥ AtomPub

Anyhow, WordPress 2.3 is going to be a first-rate Atom Protocol sever. - Long-Weekend Fun

実は、Atomプロトコル用のライブラリを秘かに開発していて（元はここで公開していたもの）、これを使ってそろそろ色々とソフトウェアを公開して行きたいなぁと思っています。

やっとアプリケーションとデータの移行が終わってひと段落した所ですが、まだBlogWriteを含めて開発環境が移行しきれていない部分もあります。以前まではDelphi７でしたが今回からDelphi Studio 2006にしたので色々と移行作業が残っています。

さて、Vistaの正式版が出る前、ベータ版の頃から使っていた訳ですが、Vistaは使えるのかというと…残念ながら、まだまだ本格的利用には耐えられないと思います。個人用のも含めて複数台のVistaを利用していますが、最新のUpdateを当てた状態でも、それぞれで問題が起きています。ほとんどがドライバーとの問題で、無線Lanのドライバーのせいで突然ブルースクリーンで再起動がかかったり、USBスティックを挿すとドライバーを検索していますのまま固まったり、などなど…。　大体は問題の組み合わせを突き止めたので、地雷を慎重に回避すれば大体動いているのですが、普通はそんな事はしたくないですよね。

一番厄介だった問題は、VistaのUltimateの機能である、MUIのインストールと、PC完全バックアップの機能が、これといったエラー文も無く単に失敗する現象でした。　同様の現象は検索すると色々出てきます。　散々調べたのですが解決策が見つからず、色々試した挙句、判明したのが、ハードディスクが二つあって、Slaveの方にVistaを入れてある場合にこの現象が起きるようです。　デュアルブートにしているPCだったのでちょっと特殊な環境ではありますが、なんだかなぁ…と。いずれにせよ、Masterの方を抜いて起動して実行すると何事もなかったかのようにMUIのインストールが成功しました。とりあえずこれで簡単にWindowsを英語表示にしたり出来ますので、開発したアプリケーションの国際化も多少楽になりそうです。

問題も色々ありますが、いくつか良い点もある（見た目がXPよりはマシ、とかMUIとか）ので、他の問題はマイクロソフトが改良していくのを待つしか無いようですね。

休み明けの機会に、本格的に調べて見たのですが、原因はSQLiteのデータベースファイルが４００MBにもなっていたからでした。　このブログはちょっと放って置くとあっという間に迷惑メールやトラックバックが溜まって恐ろしい事になってしまいます。

通常の手順だとSQLiteからMySQLには変換出来なかったので、この記事を参考にして、テーブル毎に変換するようソースを弄ってなんとかデータをMySQLに入れる事が出来ました。共有のMySQLサーバーなので動作は速くは無いですが、安定して動いてくれているようです。　

DB変換前はログインすら出来なくなっていたので大幅に改善されました。投稿ボタンを押したら「インターナルサーバーエラー」とかもホントやる気を無くしてくれます。やっぱりブログを書くのは楽しくないと行けませんね。　という事でブログを書くならBlogWrite＾＾；

あ、あと一時的に記事に対するコメントとトラックバックをオフにしています。何しろ多い日は一日に数百件の迷惑コメントとかがあって負荷が高いので、なんらかの解決策を考え付くまでちょっとオフにさせてください。済みません。

基本的にはどうも、字体の変更なので大きな影響はないよ、という事らしいのですが、一部、事情により、新たな字体が追加され、旧字体に加え、新規に文字が追加されたようです。

http://www.jisc.go.jp/newstopics/2005/040220kanjicode.pdf

「表外漢字字体表（1,022字）の一部については、技術的な制約から、新しい漢字として追加を行った。」

実は、これが曲者で、

「漢字は、国際標準であるISOにおいても規格化されている。ISOの規格では、今回新規に追加した文字と既存の文字を別の字として扱っている。したがってISOの規定に合わせるため、１０字については追加の規定を行った。」

という上記に該当する、既存文字と追加文字が共存する一部例外の文字に関しては、BlogWriteにおいて（HTMLエディタの方では）入力しただけで化けるようです。もちろん、例え正常に入力出来たとしても、それらの文字を使った場合、XPやそれ以前のパソコンで見ると化けて表示されてしまいます。 (なので、このまま、入力した時点で化けます、という方がBlogWrite的には良いかも)

また、幾つか実験した限りでは、Web上のCGIアプリケーション等でも、これらの文字を入力すると、数値参照に変換されてしまったりという問題も確認しました。

しかし、困ったものです…。一応、変換時に候補一覧を表示させると、「環境依存文字」と表記されるのですが、気をつけていないと、つい間違って使ってしまいそうです。一目では字体の違いがわからない同じ文字が二つ並んでいるのですから…。

（１）外部WebサービスAPIの連携拡大

画像共有サイト
Flickr
フォト蔵
はてなフォトライフ

動画共有サイト
AmebaVision
YouTube

＊動画共有サイトでは現状、投稿用APIは無いようなので、今の所対応は出来ないが、動向は注目しています。

ストレージサービス
Amazon Simple Storage Service (Amazon S3)
Google Base

アフィリエイトサービス
Amazonアソシエイト・プログラム

特定業務系サービス
REPS

以上、これらの外部サービスとAPIを通じて連携する事が可能になった今、とても面白いものが出来ると思っています。XMLによって有機的に異なるサービスが連携する時がついに来たか、という感じです。BlogWriteはそれらを自在につまみ食いする蛸足の（触手があっちこっち伸びる）ようになったらいいなと…

ただし、BlogWriteはver1からver2への移行時に、ユーザーインターフェース的には一変したものの、内部仕様はver1から引きずっている所が多々あり、上記のサービス1つ追加するのも大変な作業となります。（そもそも、３種類のAPIをサポートし、かつ各ブログ毎の違いを吸収するだけでもかなり大変）

必然的に、内部機能をそれぞれモジュール化し、プラグイン形式でブロックみたい必要に応じて、組み合わせて動作するようにするのが理想となります。 （犠牲になる部分もあるのですが）

つまり、またver1からver2の時のように、今度は内部構造をフルスクラッチで作り直し…。それか、いっそのこと、別のアプリケーションにしてしまうか…。

そこで、検討をしなくてはならないもう1つの要素の一つとして、API規格の本命、Atom出版プロトコルの件。

（２）新たな通信規格「Atom出版プロトコル」への対応

 既存のAPIの限界や問題点を踏まえ、IETFで規格化が進んでいるAtom publishing protocol。

恐らくVoxあたりで対応してくるだろうと思われるし、Voxで利用するAPIとしては機能的に最適だとも思う。これも、既存の記事だけでなく、色々な情報が入ってくる為、機能をフルに有効活用するには、BlogWriteの内部的に大幅な変更が必要になりそうです。

という事で、BlogWriteとしてあと一歩踏み出すには、何をするにも、大幅な変更が必要になるという事が判明していて、現在、色々と悶々としている所です。

いずれにしても、あくまで今年の目標なんで、あんまり期待しないでください。

これに関しては、昔から色々考えていたので少し言いたい所があります。 私も以前から日本発のソフトウェアはもっと増えて良いのではないか、と考えていました。（自分の事は棚の上の天井に置いておいてｗ）

で、少ないことの原因を、「日本発のソフトが少ないのは日本人が英語が苦手だから」 というのは、語弊がある、またはほんの一面の中の一部しか説明していないと思う訳です。というのも、

（１）そもそも魅力的なソフトウェアが無い現実
海外でウケルだろうな、とか革新的だ、という日本製のオリジナルなPCソフト、ウェブサービスが思い浮かばない。微妙にセンス（見た目や操作性、求める機能）が違う、例えば笑いのツボが異なるような感じで、何かちょっと違うという事も多い。 それに常に２歩３歩遅れている、黒船到来してから慌ててキャッチアップしてる状態じゃぁ･･･。

（２）海外での展開なんて頭から考えていないケース
あまりにも、日本固有の事情に合わせて便利にしすぎて海外へ持っていけないというのも多い。細かい所こだわって高品質、日本人ユーザーにとっては高機能なんだけど…

（３）日本の大手ソフトウェア開発企業の根源的弊害
政府系の仕事や、天下り団体から随意契約しちゃって、下請け、孫受けに丸投げするだけの大手企業がスーパープログラマを抱え込んでしまって、人材が腐ってる。

（４）ソフト（ウェア）といっても、じゃあゲームソフトは、というのは弾氏が指摘している通りだし。

最後に、弾氏が指摘するように、アメリカをアメリカたらしめている魅力が世界から人材を集め、さらに魅力あるものになっていくというスパイラル。このせいで、多くのソフトウェアがアメリカ発（のように見える）なのでしょう。実際には氏が指摘しているように、結果として有名なソフトウェアを作った人が行き着く所がアメリカ、という事も非常に多い。

だって、アメリカから声がかかったら行きたくなっちゃうでしょｗ 大抵の人は。で、
>英語を操れないと世界デビューはままならず、そして世界デビューした途端に合州国から声がかかる。このジレンマをどう解決していくか。

これには、日本自体が魅力ある、つまり、声がかかったらつい来たくなる所にする必要がある、という事ではないでしょか。mixiを作った方のように優秀な方が自然と集まってくるような所に…

もちろん、最終的には英語は必要になるし、日本にいても最新動向を追っ掛けたり、基礎技術や規格文書を読むのに、英語（に限らず）読解能力はソフトウェアエンジニアとして有益なことは確かです。

但し、英語さえ出来れば、と考えてしまうと、後で大きなパンチを食らうんじゃないかと思います。英会話なんて後からついてくるもんです。まずは、物とやる気ありき。さあ徹夜だ、違ｗ という事で、あとは若い世代に任せた。

上記リンク先にもありますが、制限事項として、

    * 現在のところAPIのご利用は、1日１０００クエリーまでに制限させていただいております。
    * API経由でアップロードできる画像サイズの上限は１００KBです。(有料プランも現在は１００KBまで・後日対応予定)
    * 子ユーザーでAPIを利用することはできません。

という事で、画像サイズ100KBというのはちょっと痛いですが、1日１０００クエリーは問題ないでしょう。

現在、細かい挙動に問題がないか相性確認のテストを行なっております。結果はこのページで御報告致します。

という事で、結果報告：

現状、テストした限り、下記の問題点が判明しています。

（１）改行タグが自動で挿入されてしまい、改行が増えてしまう問題を確認。 （18:18 2007/02/26 修正を確認）
（２）画像（ファイル）のアップロード時、成功しているのだけど、リスポンスの形式が異なる（間違っている？）為、画像URLが取れない。 （18:18 2007/02/26 修正を確認）

他にもあるかも…

追記：
今、報告の返事を頂きました。来週の頭には直ってるかも、期待です！
上記、(1)と(2)の修正確認しました。　

今の所判明した制限事項として、
（３）追記が出来ないのは仕様？ (JUGEMだけ固有の制限はシンドイなぁ…) （18:18 2007/02/26追加）
（４）*コメント「受け付ける・受け付けない」　*トラックバック「受け付ける・受け付けない」のオプション指定は出来ない仕様。（18:18 2007/02/26追加）

しかし、動的ページは再構築がない分、BlogWriteからの投稿処理も、相当早く感じますね！

動作環境
 Windows (Vistaで確認)

ライセンス
 フリー

ダウンロード
 rimo_tv_screensaver.zip (244KB)

一応、マウス操作の有効・無効を設定できます。

いえ、買うか買わないか、ではなく（Windowsアプリケーション開発者として選択肢はない）、またひとつPCが増えてしまう事…、また開発環境は移行すべきかどうか。

問題のひとつは、今使っているハードウェアではVistaはまともに動作しないので、新たにPC毎新調する必要がある事です。Vistaは去年のBeta2からRC1としばらく使って見ましたが、最低CPU 2GHz以上、メモリ1Gはないとつらい感じです。さらに、複数のアプリケーションを起動して色々するというヘビーな利用するのであれば、メモリは2Gないとつらいです。グラフィックカードもましな物にしないと…。

つまり、いまどきのCPUとメモリを買うー＞マザーボードから丸ごと入れ替えー＞新調した方が、となり、Vistaの為に一台買わないといけなくなります。今まで利用してたまったく問題のないPCをどうすれば良いのか、というのに悩むのです。まったく問題なくある程度満足しているPCと環境を捨てるのもどうかと思うし、開発環境として取って起きたい…。ノートはすでにXPのがあるし...。

ただでさえ、Windowsアプリ開発用Windowsマシンと、Webアプリ開発用Linuxサーバーに挟まれているのに、Vista用買ったら３方囲まれてしまいます＾＾　排熱で茹で上がりそう。

こういう時こそ仮想マシンの出番なのですが、仮想マシン上では確かAeroとか有効にならなかったのでテストにならない上、仮想マシンだけの為にVistaのライセンスが１つ必要なのはなんとも無駄。

で、開発環境で使うマシンはどちらにするか…。個人的には、今までのWindows OSの中ではWindows 2000が一番堅牢でしかも軽い（余計なのがついてない）と思っていて、開発マシンは未だにそれなのです。いずれは移行しなければと思っていますが、なかなか捨てがたいのです、これが。

開発環境は主にDelphi7で行ってきました。しかしVistaではDelphi7は互換性がないアプリケーションに登録されていて、動くには動きますが後々問題になりそうなので、問題なく動くDelphi Studio 2006に移行する事も考えなくてはなりません。Delphi Studio 2006は既に持ってますが、開発環境を移行する、というのは開発者にとっては実はおおごとなんです。

また、エディタで有名な秀丸の開発者の方も、古いWindowsでも動くように、何世代も前の開発環境を使って開発しているらしいですが、私も同様にそういうのも大事だと思っています。

結局私は、Windos2000の起動さえもっと早くなれば、100％それで満足なんですよ！えぇ。

まだ内容は詳しくは把握していないのですが、そろそろ、ドラフト１０をベースに作った、Atomicクライアントもアップデートしなくちゃならないし、不動産物件検索CGI - REPS も、Atom出版プロトコル対応の作業始めたいし、将来的には、Atomicで作ったコードをBlogWrite にも反映させて行きたいし...と色々大変です。

BlogWriteに関しては、Atomicで処理をコンポーネント化しているので、 これを使う予定です。

//Atomクライアントのオブジェクト
AtomClient := TAtomClient.Create(self);

//Atomクライアントの設定して
AtomClient.Username := 'hoge';
AtomClient.Password := 'hogehoge';
AtomClient.AuthType := atNone;
AtomClient.IntrospectionUri := 'http://example.org/atom';

//サービスドキュメントを取得
AtomClient.getIntrospection();

//introspectionオブジェクトが返るので、一番はじめのワークスペース内の、一番はじめのコレクションへ投稿する為の、URIを選びます
Href := Introspection.Workspaces[0].Collections[0].Href

//エントリのオブジェクト
AtomEntry := TAtomEntry.Create;

//エントリの設定
AtomEntry.Title.Text := 'タイトル';
AtomEntry.Content.Text := '本文';

//エントリの投稿
AtomClient.postEntry(Href, AtomEntry);

//結果成功であれば、エントリのオブジェクトが返り、AtomEntry.editUri に投稿(Put)すれば編集、Deleteすれば削除も出来る。
AtomClient.updateEntry(AtomEntry.editUri, AtomEntry);
AtomClient.deleteEntry(AtomEntry.editUri);

といった感じ...

C#や、Javaでも、Googleが提供しているライブラリを使えば、似たような感じで出来るのではないかと思います。

アカウント追加、記事の取得等は出来るのですが、投稿すると、

HTTP/1.1 400 Bad Request
Content-Type: application/x.atom+xml

<?xml version="1.0" encoding="UTF-8">
<error>XML parse failed</error>

というエラーが返ってきます。私のアカウントだけでしょうか．．．何も変えていないので、アメブロ側で何か障害が起きているのかもしれません。

因みにアメブロだと、JavaScriptを使ったエントリを弾く等、色々制限があって、それも含めてもうちょっと、頑張って頂きたく思ったり．．．

で、今回の件で調査中に見つけた、Ameba Vision 動画投稿サービス。こういった、新しいWeb APIにも取り組んでいらっしゃる事ですし少し期待します．．．。ぜひともAtom出版プロトコルでやってほしかったですが、よく読むと意識していらっしゃるようなので、将来的にもしや、という事もありそうです。

追記：21:25 2006/12/27
お、直ったようですね。対応早い。　ただ、APIで返るブログURIが、まだ、
http://172.16.4.207:7001/blogwrite
http://172.16.4.207:7001/servlet/_atom/blog/10000347xxx/10022356xxx
のようになってしまっています。EditURIも同じくで、PUT時にエラーになります。同様の原因で、BlogWrite内の「ブログの確認」を押しても、上記のページ へ行ってしまって、正常に閲覧できません。

また、GET時に、タイトルなどが、文字化けを起こす事があって これまたエラーになる事があります。

以上、ついでに宜しくお願い致します！

追記２：
URIも直った！早い＾＾　大感謝です。

やめて～、中国や韓国みたいになってしまう...orz 　この番組を知った韓国の人が皮肉を込めて曰く、

インターネット匿名性問題 <- 韓国では簡単です!

1. すべての国民に個人別識別番号(住民番号)を生まれる時から与えます

2. インターネットサイトに加入する時は住民番号を必ず記入しなければなりません!

3. 誰か悪意性 threadをあげれば, 住民番号を問い合わせして簡単逮捕します!

これが韓国式デモクラシー, 言論の自由です!  誇らしいです!

追記：
うわ、番組の続きで、韓国のこの制度を「日本が注目している制度」とNHKが紹介した..orz

KBSという韓国公共放送の番組で「インターネットの魔女狩りは許されるのか」という番組があったという。では、国が行なう魔女狩りは許されるのだろうか？　参照：「親日反民族行為真相糾明委員会、「親日派」名簿１０６人公表」 。他にも情報倫理委員会が、親日的ウェブサイトを次々と停止している状況も同時に取り上げるべきでしたね。

言論統制や検閲を行なった時点で、どれだけ国民が事実無根の煽動に惑わされやすくなるか、韓国人と中国人そして北朝鮮の人たちと歴史討論してみればすぐ分かります。対して、情報を規制せずに、critical thinkingを重視する欧米特にアメリカ人と討論してみれば、何が重要かが分かるでしょう。

実名登録、監視、規制強化云々は、実際に沢山の人を殺している車、排気ガスを出して環境汚染をする車、今すぐ全廃すべき、と言うのと同じぐらいピントが外れている気がします。

今回は、サンフランシスコの宮川さんと日本の会場を、二台のPCで結んだオンライン経由でのプレゼンをしていただくという稀有な事があったのですが、音質もクリアで思ったより良かったと思いました。微力ながらお手伝いしたのですが、録画するとかそげな余裕はございませんでした、済みません（笑）

そんなこんなで午前中は準備などで、落ち着いてじっくりと発表を聞いている余裕が無かったのですが、後半は沢山勉強させて頂きました。皆さんのお話を聞いているだけで、なぜか色々とモティベーションがアップするから不思議です。個々の内容について感想は一杯あるのですが、まとめ切れない気がするのでまたの機会に。

所で、コメントした内容で少し言葉足らずの所があったかもしれないので、例の、Webサービス認証に関して少し補足です。　もうかなり前になりますが、WSS認証の混乱については、こんな経緯があったんです（今は解決しているはずですが）＝＞　ココログ Atom API の小さくて大きな問題

認証周りは色々大変ですね。 個人的には、Atom出版プロトコルでの挙動が標準的な流れになってくれないかとずっと期待してますが、もう決まるだろうと思ってたのですが、まだです．．．。また詳細に追っかけ始めますので、また何か出てきたらエントリに起こしていきたいと思っています。

ともかく今回は無事終わって良かったです。　ご協力いただいた皆様、この場を借りて多謝。