今月の項目
11月の何か 3日
文化の日
4日
峰岸　あやの（らき☆すた）　誕生日〜☆ミ
10日
藤倉　いつき（ツナガル★バングル）誕生日〜☆ミ
23日
勤労感謝の日
佐和文香（お願いお星さま）　誕生日〜☆ミ

OneDrive Sync Enginが正常に動作しません。

ファイルを追加しても更新をしない。
一時停止したり、なんだりを繰り返していると、「再起動しています」と表示され、ファイルの検索中からやり直しです。

ファイル数が５万を超えているのが原因でしょうか？

書き込んだ瞬間にクラウドにアップロードしろとか？　そういう事は考えていないんですよ、遅くても良いので確実にやって欲しいのです。

その点、DropBoxは途中でクライアントが落ちることもありませんし、大量のファイルを一気に移動したりしても特に問題なく動いています。


Bitcaseの時もYahooBoxのときもそうでしたが、OneDriveでもダメのようです。

まぁ、それをいったらVSもそうでしたね、
ファイルを更新すると、本来はビルドしてから実行されるのですが、

とあるプロジェクト（Ｇ単位）の場合、ファイルを変更しても、全く無反応です。
ソリューション全体の中で、ごく一部のプロジェクトだけなんですよね。

わけわかりません。
（ＶＳでは、ソリューション単位やプロジェクト単位でその手の設定は出来ず、VS全体の設定です。）

おそらく、Windowsのファイルやらディレクトリの変更検出の仕組みその物が、ファイル数とか、ハンドル数の上限があって、それのせいであぶれているのが有るんじゃ無いかと思うんです。
（FileSystemWatcher の事です。）

そもそも、ファイル更新通知は非同期に送られてくる時点で、ファイル更新の検知としては精度が低いんですから、システム負荷にならないように、ゆっくり確実に行って欲しいです。

システムの監視が行き渡らないので有れば、ファイルの情報をアプリ側で保持し、　特に、ファイルIDですね、これでファイル名が変更されても一意性を確保できますので、NTFSのジャーナルファイル（使い方知らない）などと併せて、移動なども上手く検出出来るようになれば良いですね。

階段から落ちました。

ついさっきです。


ちょ〜足痛いです。


このビルに通い始めて、４，５年になるかと思いますが、
あたしが、階段から落ちたのはこれで３回目です。


１年くらいに１度落ちているという感じですね？

ちなみに落ちそうになるのは数ヶ月に１度有るので、１割くらいの確率で、本当に落ちていると言うことでしょうか？


階段を降りながら、あれこれしているのが悪いことは分かっていますが、あれこれをし終わってから出かけるとか、あれこれするために何処かで立ち止まるとか、そういう事をすると、数分のロスが発生するので、ちょっと困ります。

ちょっと困るのと、年に一度、かなり困るのとどっちが良いのかと言うことですよね？

年に一度落ちて、５日くらい掛けて治したとして、
その間は歩行速度が２／３に落ちたとして、

一日１時間程度歩いているあたしとしては、ロスは３０分くらいでしょうか？なので×５で１５０分／年の無駄が発生しているわけですね。


それに対し、２２日／月主にお昼休みだけとすると、１日に月３分準備に欠けた場合１ヶ月で６６分　１年で７９２分

重大な故障を起こさない限りは、ながらの方が良いと言うことですよね？


なので、注意力が散漫になりすぎるような行動をする場合は、止まりましょう。

足を比ねって済むくらいのないようなら、ゆっくり降りれば良いでしょうか？


ところで、捻挫をしたくらいで病院に行くのもアレなので、薬局でサロンパスを買ってきました。

愛用のタイガーバームも売っては居ましたが、会社で使うので、ちょっとね？


で・・・まぁ箱のサイズも小さいですし、サイズも箱に記載されていたので小さいのは分かっていたのですが・・・


めっちゃ小さいよね？

驚きの小ささだよ！

そして、何を考えているのか分からないけど、２枚が一つのフィルムにくっついて格納されていて、取り扱いがえらく面倒。

２枚ずつ使えって事かな？

取りあえず、ひねった左足の足首周辺に１枚貼りました。

仕事を始めて３０分。

足から、膏薬が蒸発してきたので、目が痛い。
そして、かなり臭う。

これならタイガーバームの方が良かったかもしれない。

枚数が半分で、これの倍くらいサイズがありそうなのが、倍の値段で売ってたんだけど、
そっちは臭わないとか書いてあったから、それじゃ無いとダメなのかもしれない。

以前のサロンパスのＣＭで、ヒラメ貼りとかって、喫茶店の従業員が足に貼っていましたが、こんなに臭っては仕事出来ないですよね〜

取りあえず、余りの３９枚は冷蔵庫に入れておきました。

次誰か使うでしょうか？？

実は１６日に書いていたのですが、途中で忙しくなり消してしまったので、また１から書き直しです。

先日の最後にフォルダの作成方法について書きました。

また、フォルダをたどっていくときの注意点についても書きました。

あと、何が必要でしょうか？？


ファイルの送信ですね？


ファイルの送信は、色々なところに紹介されているようなMIME形式でMethod POSTを利用するのが最も楽です。

先日までの手段を用いて、フォルダのupload_locationを取得したら、それに対して、methodをPOSTに設定して

UploadFileで送信するだけで終わりです。

始め、ご丁寧にMIMEのmulti-partを作成してUploadDataを使って送信しようとしたんですが、"Content-Type"でエラーが出て送信が出来なかったんですよ。

ですので、送信先と、送信元で違うファイル名を設定することが出来ません。
ファイルに対する情報設定は事前にやっておく必要があります。


実際の送信方法はこちら

Byte[] bData = wc.UploadFile(UploadLocation + "?access_token=" + access_token, "POST", FullName);

また、APIその物に
http://msdn.microsoft.com/en-us/library/dn631834.aspx
ここを見ていただければ分かりますが、
name、description、sort_by以外に書き込める内容が存在しません。

プロパティの変更は、ほぼ何も出来ないと思って間違い有りません。

まぁ、descriptionにコード化したupdatetimeなどの情報を忍ばせても良いですが、
そこまでするのかな？って感じはしなくもありません。

ローカルの送信元のファイルがクラウド側の送信先のファイル日付より新しくなっていたら、更新するという非常にシンプルな構造でも、自動更新は可能です。

取りあえず、実行完了時に帰ってくるByte[]にフォルダ作成時と同じように新しいファイルのid等が入ったJSONが有りますので、それを利用すれば、デスクリプション等の変更やファイルのダウンロードが可能です。


これで、一応目的の、OneDriveの指定場所に、指定したフォルダの内容を自動的にアップロード／更新が出来る状態になりました。

ですが、まだちょっと問題が有ります。


そう、消したファイルです。


消したディレクトリを、まるまるクラウド側で消すのは、色々と問題が有ります。

なので、ディレクトリ削除については今回は行いませんが、

１個１個のファイルなら別です。


ファイルを削除する場合はこちら

ちなみに、UploadDataを利用していますが・・・送信データはありません。
wc.UploadData("https://apis.live.net/v5.0/" + id + "?access_token=" + access_token, "DELETE", new Byte[0]);

また、削除するので、返信もありません。多分、JSONが帰ってきたら、ファイルの削除に失敗しているとかそういう感じでしょうか？

イマイチ分かりません。

それにしてもMethod Deleteが日の目を見るとは思いませんでした。
httpの仕様にはかなり以前からDleteは存在したのですが、誰かが、Deleteを送信しただけでファイルが削除されてしまってはWWWなんか存在出来たものではありません。

ですが、OAuthが出来て、セキュリティの高い認証・クラウドでのファイルの授受が頻繁に行われるようになった現在になって、漸く利用出来るようになったと言うことでしょうか？


では、次回からは上級編です。

アクセストークンの更新の仕方などを調べておきます。
（１時間？程度で有効期限が切れます。）

Vista以降のWindowsを終了していると、

xx個のプログラムが閉じられていません。

とか、そう言った類のメッセージが出て、なかなか終了出来ないときがあります。


これは主に、アプリケーション側が、OSからの終了メッセージに対して、終了しようとしたときに、

「ファイルを保存しますか？」

とかってメッセージを出して放置している場合になります。


それに対して「シャットダウンする」ボタンを押したりすると、アプリケーションは強制終了され、データは保存されないままで終了してしまいます。

まぁ、さっき編集した内容が保存されないだけなら、未だ何ともないのですが・・・・

自動で保存され、保存している最中に強制終了とかした場合には、未だ処理されていない書き出し内容が、全く保存されないままで、終了してしまうため、ファイルが壊れると言うよりも、未完のままって事になり、二度と読めなくなってしまうでしょう。


ちなみに、diskアクセスが終わっていないだけの場合は、アプリが堕ちても問題は無いので大丈夫です。

データは途中でフラッシュなどせず、迅速に出力し、その後で、書き終わるのを待つと良いでしょう。


では、本題。


最近気がついたのですが、携帯もタブレットも、タスクを着ることが無くなりました。

それだけAndroidというOSが安定してきたと言うことに成ると思います。

先月頃202Fが爆音を発し大変な目に遭いましたが、あれは再起動することで治りました。
どうも、音声出力系でおかしな事になったみたいです。

アプリも堕ちなければOSも堕ちなかったので、数ヶ月ずっと使い続けてきた結果軽微な不具合が蓄積されていったんでしょうね？

タスクスケジューラや、タスクキラーと言われるアプリケーションが活躍する場面は無くなったと言うことです。

Windowsのタスクマネージャも、結局の所アプリがフリーズするから必要になるものであって、アプリもOSも正常に動いているのであれば、タスクを切る必要は全くなく、タスクマネージャも要りません。


Ctrl+Alt+Delなんて呪文は要らなくなる時期が来るのかもしれません。


ところで、microsoftが言うWindowsが未だに堕ちまくると言う原因についてですが、

一般的には、デバイスドライバの不具合だそうです。

OSの深層部分はきわめて堅牢に出来ており滅多なことでは落ちません。
でも、デバイスドライバはそれよりも下層で動作する物も有り、デバイスドライバで不具合が起きるとOSにも影響があります。

OSはデバイスも仮想化して、デバイスをOSよりも上層で動作させている物も多いですが、全てではありませんし、結果的にはOSより下層のハードウェアに対して処理を送る関係で、デバイスドライバの不具合というのはとても致命的です。

また、OSよりも上層のアプリケーションであっても、OSによるタスクスイッチの瞬間を狙われたらひとたまりもありません。

OSとアプリが同じハードウェアで実行されている現状ではどうしようも無いのです。
.netフレームワークなどのOSを丸ごと隠蔽してしまうような、そう言った開発環境のみにしなければ防ぎようがありませんが、未だにC++やら他の言語がいまだに使われていますし、C#使いながらもAPIを呼びまくっています（笑

ランタイムの拡充と、OSの不可侵を推し進めないとダメですよね〜

先日のアップから間が空きましたが・・・仕事の方が忙しくて結構時間掛かったんですよ？


で先日はOneDriveのルートディレクトリを取得するところまで書きましたが・・・

では、そのデータの解体から始めましょう。

受信するのは先述の通りテキスト形式のJSONと言うものです。

で、これが・・・まぁ、色々と面倒なんですよ？
専用の形式であるため、自分で解読するしか無い様な雰囲気です。
まぁ、複雑な書式では無いので、1行ずつ読んでも良いですが、面倒なことこの上ありません。

そこで、.netの３．５とか４あたりからはこれのデコーダーが付録されています。

JsonReaderWriterFactory

と言うものですね。

しかも、これがやっかい、XML形式で返答するという物。

そこであたしのお勧めはこちら、

System.Net.WebClient wc = new System.Net.WebClient(); //WebClient作成
System.Xml.XmlDocument xDoc = new System.Xml.XmlDocument(); //出力用のXMLドキュメント

Byte[] dat = wc.DownloadData(URL); //バイナリ形式で戻り値を取得
System.Xml.XmlDictionaryReader xdr = System.Runtime.Serialization.Json.JsonReaderWriterFactory.CreateJsonReader(dat, System.Xml.XmlDictionaryReaderQuotas.Max); //リーダーに掛ける

xdr.Read();//ルートオブジェクトの読み込み
xDoc.LoadXml(xdr.ReadOuterXml());//変換済みのXMLソースをXmlドキュメントに流し込む

あとはxDocを一般的なxmlとして処理すれば、問題なくＯＫ


所で、これで取得するのは、ルートディレクトリの情報です。

これを取得しただけでは何も出来ません。

操作したい対象のフィルだを開いて、ファイルをダウンロードする、アップロードする、　そう言った事をしないといけません。


じゃぁ、目的のフォルダを取得するにはどうしたら良いでしょうか？
じゃぁ、
https://apis.live.net/v5.0/me/skydrive?
とやったところを
https://apis.live.net/v5.0/me/skydrive/フォルダ１/フォルダ２?

と殺れば出てくるでしょうか？？

答えはノーです。

実際のフォルダは全て数字名になっているので、この方法では取得出来ません。

そこで利用するのが「upload_location」タグです。

これは、下位層の情報が含まれている場所へのリンクが格納されています。
（注：これ以降の情報はJSON形式がXML形式になったものです。）

<upload_location type="string">https://apis.live.net/v5.0/folder.xxxxxxxxxxxxxxxxxxx/files/</upload_location>
これをダウンロードすることで、フォルダの中身一覧が取得出来、その中から希望するフォルダの情報を取得することになります。

ちなみに、
upload_location以外の情報源として、<id type="string">folder.xxxxxxx</id>があります。

https://apis.live.net/v5.0/に idタグの中身を貼り付けることでフォルダその物にアクセス出来ます。
さらにその後ろに/files/を付けることで、フォルダの中のファイルの一覧を取得出来ます。

なお、ファイルの一覧と言っていますが、ファイルやらフォルダがすべて混ざって値が返ってくるので、
<type type="string">folder</type>または<type type="string">album</type>で、<name type="string">フォルダ名</name>が探しているフォルダ名かどうかを確認することで、確定出来ます。


また、ファイルの場合は
<id type="string">file.xxxxxxxx</id>
と、idの先頭もfileになり、
upload_locationの後ろもfilesからcontentに変わり、これを取得することで、多分ダウンロードすることになります。
<upload_location type="string">https://apis.live.net/v5.0/file.xxxxxxxxxxxxxx/content/</upload_location>


ってことで、/フォルダ１/フォルダ２を取得するには、

１．ルートディレクトリの情報を取得する。
２．ルートディレクトリのファイル一覧を取得する。
３．フォルダ１の情報を探す
４．フォルダ１のファイル一覧を取得する。
５．フォルダ２の情報を探す。
６．フォルダ２のファイル一覧を取得する。
といった方法をとる必要があるようです。

ちなみに注意事項ですが・・・・
ファイル一覧に表示されているフォルダの情報は当該フォルダのファイル一覧へのリンクしか保持していません。

フォルダその物の情報が必要な場合は、upload_locationを使う場合は、/files/を消してからデータの取得をするか、
idを用いるか、どちらかと言うことに成ります。

なぜフォルダの情報が必要なのでしょうか？
ある程度の情報なら、わざわざ取得しなくても分かるのでは無いかと言うことですが・・・・

じつはこれ、それなりに重要なのです。

フォルダの新規作成は、フォルダに対して行うので/files/や/content/が付いている状態で行っても、成功しません。
それと、
新規作成したフォルダは、当然中身がありません。

中身の一覧を返す/files/では中身が無い状態では、ほぼ情報を返しません。

<root type=\"object\"><data type=\"array\"></data></root>

これだけですね。

なので、フォルダの情報とフォルダのリスト情報をペアで保存しておかなければ前後不覚に陥ります。
基本的には、ディレクトリ階層のフォルダのidを全部保存しておく必要があるでしょう。
他に使うのであれば、日付などの情報も、予め抜いておくと良いでしょう。

せっかくのXML形式なのでそのまま取っておけば、便利かもしれません。
でも、必要な情報だけを保持した、構造体とかにしておくのも一つの手ですね☆

ちなみに、データが一つでもあれば、

<parent_id type="string">folder.xxxxxxxx</parent_id>

で、前のフォルダ情報が分かります。

不便です。


ちなみに、フォルダの作成方法ですが・・・・

フォルダを作成するフォルダのidに対して、
https://apis.live.net/v5.0/folder.xxxxxxxxxxxxxx?access_token=xxxxxxxx

{name:"フォルダ１"}

をデータで送ります。

wc.Headers["Content-Type"] = "application/json";

にする必要があります。

先日の記事をバッサリしました。


ふんだんに間違えております。


まず、OneDrive関連の開発をする人は、ここを見ましょう。

http://msdn.microsoft.com/ja-jp/onedrive

日本語サイトです☆　ありがたいです。

で、ここでログインしておくと便利なのか、その先でログインしておいた方が便利なのかは微妙なんですが、

ダッシュボードのタブのリンクを開くと

ここ
https://account.live.com/developers/applications

へ飛ばされます。

こここそが、マイアプリ用のクライアントIDを発行してくれる場所です。


注）
先日の販売者ダッシュボードは、別のクライアントIDを発行するので、oAuth用クライアントIDと書かれては居ますが、それを発行しただけでは、OneDriveへのアクセスは出来ません。


で、正しい方での話ですが・・・
「マイ アプリ」を押したり、「アプリケーションの作成」を押したりすると、アプリケーションの登録画面が出来るので、好きな名前でアプリケーションの作成をします。

Windows8用とかを押すと、ストアアプリ用の有料サイトに飛ばされるので、デスクトップアプリの場合は「Windows ストア ダッシュボード」は押さないで、そのまま名称を入れて「同意する」を押します。

すると、それ以外の情報を設定する画面が出るので、主に必須項目を入れるだけで、ＯＫです。
クライアントIDを取得する場合は、API設定の所で
「モバイル クライアント アプリ/デスクトップ クライアント アプリ:」を「はい」にして、保存します。

販売者ダッシュボードのように面倒な設定は一切無く、セキュアコードも不要ですし、リダイレクトURLも要りません。


そう、これで、簡単に発行出来る上・・・・販売者ダッシュボードのように、アカウントの承認も要りません。


あっ、ちなみに、承認はされました☆

念のため取っておこうかと思います。


で、設定したアプリの名称やアイコンやらメモやらは、ログイン画面で表示されますので、それなりにちゃんとやった方が良いかと思います。


ってことで、その辺りを適当にこなせば、晴れて接続が出来る様になります。

ちなみに、販売者ダッシュボードで発行されるクライアントIDはクラスIDの用なとても長いもので、ハイフンで繋がれていますが、

正しい方は？１６桁くらいの英数字です。

ってことで、正しい？アクセル用のアドレスは以下の通り

https://login.live.com/oauth20_authorize.srf?client_id=クライアントＩＤ&scope=wl.skydrive_update&response_type=token&redirect_uri=https://login.live.com/oauth20_desktop.srf

読み込み専用のscopeはwl.skydriveですね。


これでアクセストークンが帰ってきます。

ユーザーのログイン画面で、無事ログインが完了すると、アクセス権確認画面がひょうじされ、ＯＫすると、画面はリダイレクトされて、

https://login.live.com/oauth20_desktop.srf#access_token=超長いコード&token_type=bearer&expires_in=3600&scope=wl.skydrive_update&user_id=IDらしい

の画面が表示されます。

ちなみに、真っ白な画面です。

で、ここで重要なのが、アドレスに付いている#access_token以下です。
アクセストークンは８００文字以上の超長い文字。

処理が完了してログアウトするまでこの値はずっと必要です。

webbrowserコントロールを利用している場合は

DocumentCompletedのe

WebBrowserDocumentCompletedEventArgs.Url.Fragment
を確認して#以下が格納されていればアクセストークンが正しく帰ってきています。

そうで無い場合、DocumentCompletedは、ログイン処理中に何回かリダイレクトがある関係で、何度も呼びだされますので、アドレスが正しいか確認してから、内容を取得する様にした方が良いですね。


さて、ここまでwebBrowserで対応してきた人も、ここから先は出来ません。

なぜって・・・・実際のアクセスを行うときは「skydrive.json」とかって名前でデータが帰ってきますし、そもそもhtml形式では無いからです。

webbrowserでは名前を付けて保存しますか？ってダイアログが出て非常に不便です。

これ以降は、
System.Net.WebClientでも使った方が良いでしょうか？

webbrowserと違い、プロクシの設定とかが必要になるのかもしれませんので、ご注意を☆

で、実際のこれ以降のアクセス方法については、次回をお待ち下さい☆ミ

色々ともめにもめた他種族対応

絵文字は日本の携帯電話で開発されたとても特異な機能です。


絵文字というくらい、文字のように扱われていますが、実際には文字では無く絵ですよね。

「一見は百聞にしかず」

文章だけでは伝わりにくいニュアンスを絵を交えることで一気に解決する。

それが絵文字です。

場合によっては、絵文字だけでメールが完遂することもあるくらい。一見の威力はすごい。


絵文字とは、メールの文中に絵を混ぜることを可能にした特殊な機能です。


これは、日本や中国などの、象形文字を利用している国ならではの方法であるとあたしは思っています。


でも、これが世界に飛び出し、世界的に利用されるようになったから大変。

何故、unicodeはこんな絵文字までを文字として取り込んだのでしょうか？？


これが、間違いの発端だったのでは無いでしょうか？

日本における絵文字は、当然日本人が作ったので、日本人がベースになっていますが、世界中の民族が使うことで、このことについて苦情が殺到しています。


でも、あえて言います。


日本人は白人ではありません。

白人を模して作られた絵ではありません。


あくまで黄色人種と呼ばれている。白人でも黒人でも無い人種を題材に作られています。


黒人の人達が、色白の人を模した絵文字を使うことに抵抗があるのは絵文字の本来の成り立ちから考えれば、全くもってどうでも良いことです。

使いたくなければ使わなければ良いんです。それだけです。


しかし、unicodeが文字として登録してしまったために、色々なデバイスで利用されるようになり、黒人や白人達が絵文字を使う機会を与えてしまいました。

日本人は、黄色人種の中では肌色が明るい方なので、白人の人達は違和感なく使えるかもしれません。

でも、あえて言わせて貰えば、白人は、「赤い人」です。

白人の絵文字は白いと言うよりも、赤いです。


まぁ、そんな感じの、前提の話は終わり。


先日アップされた、下記ページを見ていただければ分かりますが
http://internet.watch.impress.co.jp/docs/news/20141105_674642.html

人の肌色が対応しなければならないと言われている１５１文字について、肌色情報を追加することで、色を変更出来るようにするというのです。

肌の色は5色です。
既に登録されている「原色」をのぞけば４色分追加です。

１５１×４の６０４文字を追加した方が絶対に分かりやすいと思うのですが、なぜ色情報の追加とかにしたのでしょうか？

unicodeは本来の役目から考えれば、単一のコードで世界中の文字を表せるようにするための物です。

人種色と言われている物が５色有るのであれば、絵文字も5色分用意するべきじゃ無いでしょうか？

例えば、濃い肌色にすれば、それは「黒人」を表す文字と言うことです。薄くすれば「白人」でしょうか？

同じ模様でも表す意味が違えば、それは別の文字と言うことです。

Ａだけで
ÀÁÂÃÄÅÆ
こんなに種類を作っているのに、何故絵文字はダメなのでしょうか？

鳥と烏（カラス）で漢字は両方登録されているのに、なぜ絵文字はダメなのでしょうか？


文字が増える？

そのためのunicodeでは無いのでしょうか？


ほんとに、何を考えているのでしょうね？



それとは別ですが・・・・

絵文字はともかく、人相も人それぞれです。
XBOXやWii等は、自キャラとしてアバターの作成が出来ます。　好きな絵をストアから買って貼り付けるPSNとは違います。

このアバターの選択肢の狭さに閉口いたします。


PSO2ではモーフィングにより非常に多種多様な顔を作る事が出来ますが、それでも自分の顔と似たものは作れません。

まぁ、ゲームにおいて自分の人相なんてどうでも良いので、好きなタイプの顔を作る事になるのですが・・・・それすらも出来ない。

誰もが玩具物語の保安官みたいな顔になる。

あたしはオタクですから、もうちょっとアニメ調の絵が好みなんですよ。


使えないですね〜