LabVIEW+PostgreSQL
LabVIEWで取得するデータはPostgreSQLに保存。ということで、データベースアクセス用のVIを用意したい。
以前はPackage ManagerをつかってPostgreSQL用のツールをインストールして使っていた（LabVIEW2011）。ところが、LabVIEW2018・2019で検索しても出てこない。さて、こまったということで、Database Connectivity Toolkit を使う方法を選択。
データベースへの接続はWindowsのODBCサービス？を使い、SQLの方はToolkitで処理というものだと理解した。
ODBCのPostgreSQLドライバーをインストールすると、ODBCデータソースのセットアップツールで、PostgreSQLを選択できる。注意しないといけないのは、32ビット・64ビットバージョンのドライバがあるのだが、これはデータソースを使うアプリのバージョンに合わせるというところ。PostgreSQLサーバーのバージョンではない。LabVIEWが32ビットなら、ODBCデータソースも32ビット。
データソースセットアップツールで付けた名前を指定すると、ToolkitをからODBCを介してデータベースのアクセスできる。なかなかうまいやり方なのかもしれない。
接続も成功したのでデーターベースをセットアップしようとして、もう一つ躓いた。
PostgreSQLは基本テーブル名等で大文字・小文字は区別しない。ただし、例外的にダブルクォーテーションでくくると大文字・小文字を使うことができる。
データベース・テーブル・カラムをいちいちSQL書いてセットアップするのは面倒なので、pgAdmin をつかってインタラクティブに済ませたい。名前をつけるとき、大文字小文字を使いわけられると命名しやすい。
大文字が混ざった名前を付けてしまったのがそもそもの問題なのだが、二つの問題が発生。
pgAdmin 4 での問題
たとえばTestTableというテーブルを作って見る。SQLでは "TestTable"と指定され、大小交じりの名前がついた。次に、TestTableを継承してChildTableを作ってみる。エラー発生。原因はSQL文でダブルクォーテーションが %20 に変換されてしまう。全ての場所というわけではなく、INHERIT構文の中だと何故か変換される。
別PC（Fedora）で pgAdmin3 が使えたので、pgAdmin3 on Fedora で試してみると、そんなエラーは起きずに、ちゃんとダブルクォーテーションのままでテーブルを作成できた。
しめしめ。
Database Connection Toolkit での問題
Toolkitのせいにしては駄目かもしれないが、次の問題はToolkit使用時に発生。接続テストを兼ねて、テーブルリストを取得し、各テーブルのカラムリストを取得するサンプルプログラムを作ってみた。
テーブル名はデータベースから取得したものをそのまま利用する。エラーがおきるとは想定していなかったのだが、エラー。TestTable って名前なのに testtable としてクエリをかけており、テーブルが見つからないよ、との事。
当然、ダブルクォーテーションでくくってあげれば正しくカラムリストを取得できるのだが、VIを使うユーザーが対応しないといけない。それならテーブル名を取得するときにダブルクォーテーションを付加して返してくれといいたい。
解決方法
面倒なのですべて小文字でセットアップしましょう。ということ。
『雨が降り続けます』『雨が降り続けています』
なぜか
「雨が振り続けています」
という表現が気になった。例えばキャスターが豪雨が続く様を表現しようとして使っていた。
『け』が気になる。「雨が降り続いています」が良いのでは？と思うのだけど。他に気になる人はいないのか？とぐぐってみると・・・・・
ちらほらいます。多くの主張は「続く」「続ける」と、自動詞・他動詞の違いだという。「複合動詞」という意見も。
「複合動詞」という説明は腑に落ちる。
「雨が降り続ける」
というという表現にはあまり違和感を感じない。ああ、降り続けているのだろうなと、思う。？？？あれ、じゃあいいじゃん、問題ないじゃん。今も自分で「ああ、降り続けて（い）るんだろうな」って思ったじゃん、ってことになって全くなにが気持ちわるいのかわからないのが気持ちわるい。
イントネーション的な事なのだろうか？よーく考えてみると、頭の中では続けているのうち、「い」はかなり弱く、感覚的には
「降り続けてる」
に近いような気がする。じゃあキャスターが
「・・・・雨は依然として降り続けてます。」
といったら違和感を感じないのだろうか？そうでもないような気がする。「降り続いている」と言ってほしい。
もともと自動詞・他動詞説を唱える人は、雨は能動的に降り続けようとするわけではなく、現象が単に「続く」だけで、「続けよう」としているわけではないと主張する。でも複合動詞派の人は、日本語は複雑で自他を超えた用法があって、「続く」事を「続ける」と表現する用法を作り上げてきたのだと言う。確かに「雨が降り続ける」のは、雨が能動的に止めようとしないわけでもないのだが、雨が降り続く様子を表現するのに使う。さて、なぜ「降り続ける」のが良いのに「降り続けて（い）る」のは気持ちわるい？
さてさて、混乱に拍車がかかってきたのだが、
https://www.lang.nagoya-u.ac.jp/bugai/kokugen/nichigen/issue/pdf/11/11-09.pdf
というような論文もあるようだ。なんだが長くて大変なのだけど、「～ける」がいかに難しい表現なのかが分かるような気がする。
継続を示す複合動詞的な働きと、「～＊を＊し続ける」という他動詞的な表現が拮抗し、他動詞的表現が勝つ場合に違和感を感じてしまうのだろうか？「雨が降り続けています」「彼が振り続けています」と並ぶと確かに気持ちが悪い。
すでに「雨が降り続ける」のは継続を示し「降り続く」様を表しているのだけど、その状態をしめそうと「続けている」とするのが問題なのだろうか。
Django + LabVIEW という話
LabVIEWでデータを取得し、Djangoで管理しているサーバーに保存するというような事をしたい。POST通信でデータ更新するのだけど、セキュリティ対策ということでユーザー認証もおこなっている。
目的を果たすためには
- LabVIEWでHTTPセッションを維持
- ユーザー認証
- POST通信
をしないといけない。ユーザー認証はPOST通信でユーザー名とパスワードの送信を行うので、順序的にはPOST通信が先。POST通信のためにはCSFR対策としてトークンを指定しないといけない。さて、どうしましょう？というのが問題だった。
解は結構簡単。セッションを維持するのは単にタスクをつなげばいいし、トークンはHEADから抜き出して、ヘッダーに追加すれば良い。そしてPOST通信して認証をすませ、そのタスクでPOST通信すれば良い。
Google Site の公開設定
Goolge Site （新しい方）でサイトを作成・公開する場合の注意。個人用とG Suiteで設定が違うのかもしれないが・・・・
新しい方であたらしくサイトを作り公開ボタンを押しても、一般公開はされない。公開ボタン横のメニューから「公開設定」を選択しても、URLの編集ができるだけ。公開ページへのアクセス制限は「他のユーザーと共有」から設定する。下書き・公開ページの共有方法をそれぞれ設定することができる。
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 で試してみたところ、問題を確かに再現。
解決したからよかったけど、なかなか根の深い問題。
