GMail on Chrome
GMailでメールを読もう選択するとそこで止まってしまう。そのうちにタイムアウトになるのかエラーが表示される。
Firefoxでは問題ないので単にブラウザの問題らしい。
で、別アカウントで試してみるとChromeでもアクセスできそう・・・・
もう訳わからんのだけど、Chromeアプリをつかってみましょうというようなコメントを見かけた気がしたので、GMailアプリをつかってみた。問題ない。
まったく同じブラウザで直接接続すると駄目、アプリはOK。もう訳わからん。
--app モードでメニュー無し運用していたのだけど、とりあえずは諦めてアプリをつかってみるか。（昔はウィンドウズのスタートメニューにもあらわれたような気がするけど、ない？）
Office 365 Word で Adobe PDF Maker がアンロードされてしまう
たくさんのWordおよびPDFドキュメントを、Acrobat DCをつかって統合していた。エクスプローラーで複数選択して右クリック、Acrobatで結合。とても便利。
あるときWordで編集作業をしていて、PDF変換時に異常終了したような記憶がある。そのエラー以降、リボンにAdobeメニューがあらわれなくなってしまった。直接変換する事はあるにはあるが、頻度は少ないのでその時は気にしていなかった。
落とし穴は、いつものようにファイルを直接PDFに変換しようとした時。正確にいうと、PDFファイルに新しくWordファイルからページ追加しようとした時におきた。Wordをつかって変換しているようなのだけど、「PDF Makerが見つからない」という。修復するか？というので修復すれどまったく効果なし。Acrobat DC を再インストールしてもだめ。Officeを再インストールしてもだめ。症状としては
- Wordでアドインの状況をみてみると、「アンロードされた」と表示されている。
- 他のアドオンは起動時にロード
- ExcelではOK
なんど、有効化しても症状は変わらない。結局解決方法は
の下の方にある、レジストリ編集。アドオンに対する動作設定が、つねにアンロードになっている様子。切り替えたらちゃんと動くようになった。
これけっこうわけわからん状況なのでは？巷の人々は対応できるのだろうか。
おんどとりWebStorage API
おんどとりで温度モニタをしている。測定値はおんどとりWebStorageにアップロードされ、ログインすると測定結果をオンラインで確認できる。とても便利。
アップロードされたデーターはAPIをつかってダウンロードする事もできる。JavaScriptから直接叩くのは禁止されているのだけど、サーバーサイドでダウンロードして利用できる。サーバーに限定するわけでもなく、要はスタンドアロンなアプリケーションからはOKなわけで、たとえばLabViewをつかったGUIモニタなんてのも簡単に作る事ができる。
さて、最近DjangoベースのWebアプリを利用していろいろやっているわけだが、Djangoの方でもおんどとりデータを活用したい。いちいちWebStorageにアクセスするのも効率が悪いので、Djangoデーターベースをキャッシュとしてつかい、データベースに該当するデータがなければ、WebStorageから値を取得・保存するようなものを作りたい。
DjangoはPhyton3で動いていて、Python3 では urllib をつかってHTTP通信をすれば良いとGoogle先生が教えてくれたので、試してみた・・・・・・が、うまくいかない。LabViewでPOST通信をつかって最新データを取得できるのは確認済み。urllib のサンプルを見ても特段複雑な事をしているわけでもないので、コードに問題があるとも思い難い。半日くらい悩んでいたのだが、ようやく問題の特定にいたった。
APIを使うには、POST通信でリクエスト情報をJSON形式で送る。受信データもJSON形式。なんどやってもフォーマットエラーが帰ってくるので、送信データーの中身が悪いのか？と悩んでいたところ、問題はデータではなくてヘッダーにある事が判明。urllib で Content-Type を application/json に指定しているのだが、設定されているヘッダーを確認してみると、Content-type となっている。どうやら内部で、最初の文字以外は小文字に変換している様子。HTTP通信の規格上、大文字・小文字の区別はしないので、この仕様になにも問題ない。
ところが・・・・・ WebStorage 側ではどうやら大文字・小文字の区別をしているらしい。いくら Content-type で JSON 指定をしても、サーバー側で Content-Type をまたれると、データ・フォーマットの指定ができず、400番のエラーを返してくれる。話をややこしくしているのは、エラーコード 415 は JSONフォーマットエラーになっていて、エラーコードの説明だけではどこに問題があるのか判断つきにくくなっている事か？
LabViewの方でヘッダー情報を編集して試してみようとしたところ、LabView のVIでは、ヘッダー種類はすでにリスト化されていて、小文字に変更するという単純な事ができない。（もしLabViewのVIが小文字変換していたら、なかなか厄介な問題だった）
解決方法は Python の requests モジュールを利用する事。こちらは勝手に文字種変換なんてことはせず、指定したものをそのまま送信してくれる。Content-Type と Content-type で試してみたところ、問題を確かに再現。
解決したからよかったけど、なかなか根の深い問題。
Window subsystem for Linux をためしている話
Windows10でLinuxを使おうとすると、別のホストにリモートログイン、Virtual Box的なもの、Cygwin等が候補にあったが、最近は Windows subsystem for Linux が選択肢にふくまれるようになった。
いろいろ考えて、WSLを今回使えるようにしようとしている。使えるようにとは emacs が使えて、ROOT が使える事。
X11は MobaXterm で対応。
とりあえずいろいろな所にかいてあるように、有効化後にMicrosoft ShopでUbuntu かDebianかSuSE をインストール。今回は Ubuntu を選んでみた。正直なところDebianとなにが違うの？と思わないでもないが、Ubuntu。
ROOTはパッケージ化されていないのでビルドが必要。RPM系がリリースされると嬉しい所。いちいちビルドするのは面倒だ。
そうはいっても必要なので、開発環境を整えて、必要なライブラリもちょこちょこインストールして、ビルド。WSLの欠点はIOの遅さかもしれない。ディスクアクセスはなんでこんなに遅いのだろうか？ROOTのビルドはそもそも時間がかかるのだけど、IOの遅さがさらに足を引っ張っている。
どうしてNASが表示されないのか、ずーっと困っていた話
LAN中のDesktopPCからは見えるNASが、Laptopからは見えない。まったく意味がわからず困っていたところ、以下の記事をみつけた。
わかってみれば「そうなのね」というものなのだけど、流石にわからん。きっとどこかでニュースになっていたのかもしれないけど、しらんがな。って感じ。
とりあえず有効化して、再起動。
つかっていないけどWSL
Windows Subsystem for Linux を使い始めるひとがまわりにぽちぽちと出てきた。どんなものなのかを見てみると、Ubuntu on Window, SuSE on Windows, Fedora on Windows とメジャーなところを選択しながら、Linux環境をストアから導入できるというなんともまあお手軽な感じ。
周りのひとの使い方を見てみると、WSLでOpenSSHを動かしておいて、SSHクライアントで接続して、別立てのXserver上にX11クライアントを飛ばすといった使い方をしている。
X server はないのかしら？
とググってみても、Xmingを使えだのVcXsrvを使えだのばかり。まだNativeにXserverが動くところまでは来ていないようですね。
どうやらまだまだ MobaXterm が活躍する余地がたくさんアリそうな話でした。
自前でWindows Desktopに統合してくれるようになったら、かなり使える環境なきがする。
