投稿日:

最近ごそごそ作っていた個人情報端末のその後

夜中と日曜あたりに暇々に勉強がてら作っていた

最近ごそごそ作っていた個人情報端末

のその後。

結構切り貼り技術にはなっている状態なのだが構成の概略まとめると次の感じ

個々の要の技術は、やりやすいもの(キー監視するのにWin32→C#→ASP.NETとか)を選んだ結果、見事につぎはぎ状態。でも逆に言うと切り貼りすれば個人で目的ベースのシステムが作れる時代になったとか、よい時代だなーと。

細かくいうとMiServerをクラウドに持って行こうとしたらwebhook禁止と言われて、MiServerとMiReceiverを分けたとか、

NASのDockerにデプロイしたらNASごとコケて、さすがにNASがこけたら被害で顔面蒼白ものなので、当面ローカル実行で将来ラズバイに持って行きたいところとか。

あとは個々の取得情報をまだよい形にサマリー化できていないな。それでも毎日立ち上げる気になるくらいの便利さはでてきつつある感じ。

中の情報集約/解析を当面強化かな。

投稿日:

Microsoft ToDoは「今日の予定」をAPIで取得できないらしい

ここしばらく個人的な情報をいろいろ有機結合するために、いろいろ調べたり試作したりしていて、Gmail/Googleカレンダー取得とかTwitter Botとかブラウザ音声合成/音声入力とかSlack APIとかクラウド系DBとかVue間websocketとかBluetooth検出とか、ラズパイデプロイとかいろいろ調べた訳です。

調査とか試作とかもそれなりに今風技術の勉強になって面白かったのです。

私は個人的に最近ToDoはMicrosoft ToDoを使っていたので、ここらを自動操作するためにMicrosoft Graph APIをここ1週間～2週間近く調べていたのです。Graph APIはいろんなツールでのアクセス方法が公開されていてそれはそれなりによく出来ているとは思うものの、自分が使っているツールとは相性が悪く(バグというより双方の仕様上の制限的なもの)でああだこうだやっていて結局素でGET/POSTしてなんとか安定取得の方法もわかり、

https://docs.microsoft.com/ja-jp/graph/auth-v2-user

Microsoft ToDo APIのアクセスも出来るようになり

https://docs.microsoft.com/ja-jp/graph/api/resources/todo-overview?view=graph-rest-beta

さぁこれでToDoの半自動管理も出来るかと思っていろいろやったあげく

Microsoft ToDo のAPIは「今日の予定(My Day)」をAPIで取得できないらしい

https://stackoverflow.com/questions/59540550/get-put-steps-to-microsofts-todo-tasks-via-api

という話がでてきて(しかも他の検索情報だと結構長く放置されているらしい?)超がっかりという話であります。

ToDoは別ソフトへの移行を考えるか。。。Azure APIアクセスは機械学習APIを試すころまで保留かね。。。

投稿日:

2020/10/11付近

土曜は適当にお酒

ライフログ動画を圧縮編集

今秋初の鍋物

ローカルツールをリモートサーバープロジェクトとローカルサーバープロジェクトに分離

新アイデアpaper browserとpuzzle to doの実現可能検討

投稿日:

自身のある日のキータイプとマウスクリック

これはとある日の自身のキーボードタイプとマウスクリックの分布です(朝起動を忘れた時間があるので朝が少し途切れている) これは

と思ってツールを作ってみた訳です。

この手のツールは恐らく探せば売ってるだろうし、オープンソースでもどこかにはあるだろうが、キーロガー的なものを入れられると困るし、金かけてやることでもないのでこれも最近の夜中のごそごそ手作りです。

最初はnodejsあたりでローカル実行しようと思ったのですが、キーマウスの挙動を追うにはWin32 APIをアクセスできたほうがよいので、node系のnative apiツール(node-gyp,edge-jsあたり)を検討したものの思ったより面倒そうだし、typescriptと相性が悪かったりで、それならもうC#のほうがよかろうと検討(昔Windows xp用仮想キーボードドライバをC++で書いたことはあるもののさすがにこの目的くらいでC++はもう気力が無理)。

昔は結構Windows Form系の案件はやってたので久しぶりのC#。変にUI付けるよりはデバッグサーバーで動かしてRESTで操作するのが楽かなーと思って、はじめてのASP.net Coreでサンプルまねまね作ってみたものです。

ちなみに縦軸数値はPCの負荷にならないように粗いサンプリングにしているので正確なタイプ数ではなくあくまで指標で。

これ見て思ったのは

  • 自分のキータイプ数はたいしたことないな
  • 自分は相変わらず夜型だな
  • どの時間帯付近で休憩しているかはなんとなく分かる(夕刻にパフォーマンスが下がるのは意識がある)

他人と比較しないとわからないが、わりと集中時間にむらはあるのだろう。

投稿日:

[Docker]Docker for Windows でディスク共有したいならWSL2をオフにしたほうが無難

以前、

Docker Toolbox for Windows は基本Cドライブ内しかディスク共有できない

というのを書いたのだが、VirtualBoxなどVMツールがHyper-Vと共存できるようになったということで休みの日に、ながら操作でVirtualBox環境を整理しながらDocker Toolbox for WindowsからDocker for Windowsに差し替えた。

デザインもおしゃれだし、操作感もMac版に近くなったし、正式版の安心感でそのまま使っていたのだが、ある日突然 画面に 「WSL2に切り替えましょう」的なアップデートが来たので、指示に合わせてWSL2パッチを当ててWSL2設定に切り替えた。

で最近案件都合から各種テスト環境を整理していたら、以前使っていたdocker-domposeがうまく動かない。どうもディスク共有が出来ていない。ネットでいろいろ引いた結果、

https://docs.docker.com/docker-for-windows/wsl/#best-practices

https://github.com/docker/for-win/issues/4812

どうやらDocker for Windows をWSL2で使うときは、ディスク共有はWSLのlinuxファイルシステム範囲内で使うべきらしい。

丁度Docker Toolbox for Windowsのディスク共有もCドライブ内で行ったほうが無難(出来ない訳ではないがそこで悩んでも無駄)と似た話でWSL内のファイルパス内を使ったほうが安定らしい。

そこでどうしても引っかかるならWSL2をオフにして、WSLでやるのがよさそう。

DockerをWindowsで使うときはローカル開発などパフォーマンスが気になるケースはほとんどないだろうから、WSL2 をオフにしておいたほうが悩まずに済む気がする。

ちなみにWSLのままであれば、docker-composeの相対パスも、絶対パス記述(D:\\xxxx\xxxx)もうまく扱ってくれた。

あとはVirtualBoxの設定のほうだな。。。以前使っていた過去環境VMは話通りほぼ動いているのだが、以前のWindows 10環境をVM化していたものは、使い物にならない速度でしか走らないので、VirtualBox環境は別マシンに分離する方向で検討中。