日記帳だ! with Tux on Libserver

最近知ってびっくりしたんだけど、JavaScriptって直接的にフォーマットを決めて日時を文字列化することはできないらしい。

もちろんそういうライブラリもあるんですけどね。

システム間で日時をやりとりするときに使われるのがこの形式の文字列なのですが。

date.toISOString() –> “2021-02-06T14:39:03.419Z”

これ取得したのは23時台なんだけど、14時? って見える。

でも、そうじゃないんですよ。ポイントは文字列の最後に付いた”Z”ですね。

これでUTCであることを表している。日本標準時はUTC+9だから、9時間足せば23時39分だね。

詳しく言うとこれはISO 8601形式で、この形式にはいろいろ書き方があって、

このBlogのRSSでは”2021-02-05T23:10:00+09:00″という形で書いている。

この+09:00でこの日時はUTC+9で書かれたことを表している。

ただ、これは本質的には”2021-02-05T14:10:00Z”と同じものである。

こう言われるとJavaScriptが賢いのかアホなのかよくわからないが、多分アホだと思う。

とはいえ、時間は世界中どこでも同じものであって、どこから見るかによって変わるというのも正論ではある。

基本的にJavaScriptの用途からしてみれば、動作しているシステムのタイムゾーンで表示できればよいわけだが、

どこで動いてもシンガポール時刻で表示したいみたいなニーズもあるかもしれない。

そこでJavaScriptの比較的新しい機能(といっても2013年ごろにはあったらしい)として、Intl.DateTimeFormat というのがある。

Intl.DateTimeFormat (MDN Web Docs)

fmt=new Intl.DateTimeFormat('ja-JP',
   {timeZone:"Asia/Singapore", year:"numeric", month:"2-digit",
    day:"2-digit", hour12:false, hour:"2-digit", minute:"2-digit"});
fmt.format(date);

これでさっきの日本時刻で23:39を表していたデータを食わせると、”2021/02/06 22:39″というのが返ってくる。

year:”numeric”とかいうのは、表示する要素の表示方法をせっせと指定してるんですね。

これは時間帯だけではなく、どの言語の表記を使うかというのも選んでいるので、

“ja-JP”の部分を”de-DE”にすると”06.02.2021, 22:39″というドイツ式の表記で出てくる。

順番もそうだけど(ヨーロッパでは日→月→年が多い)、区切り文字も変わるんですね。

あと、month:”long”とかすると、”06. Februar 2021″のような表記になる。ドイツ語の2月ってそういう表記でしたね。

曜日とか和暦とかも扱えるみたいだが、なかなかクセの多いものに見える。

まぁどうしてこういうこと書いたかって、Power Automationで何にも考えずに作るとUTC表記だらけになったからなんですけどね。

確かにクラウド上で実行するということは、どこで実行しているかタイムゾーンを決めることが難しい。

するとUTCということにされてしまいがちだと。(もちろんそれは最初に書いたようにZ付きの表記であることは多い)

なので意図的にタイムゾーンを変換する処理を入れたりとか、そういうことが必要になるわけですね。

JavaScriptがこうというのは直接的な原因ではないんだけど、間接的には関係ありそうなので。

クラウド時代には実行されている地域のタイムゾーンによるとしては意図した結果が得られないことがあり、

そういうことを回避するためにはそのための処理を入れないといけないというわけ。

Power Automationではタイムゾーン変換を行う処理ブロックがあるので、それで違和感がないタイムゾーンに変換することになる。

あと、Power Automationから呼び出せるExcelScriptでは、日時の処理は基本的にJavaScriptと同じなので、Intl.DateTimeFormatでやることになる。

実はそういうところで調べたのがこれだと。ブラウザで動くJavaScriptはここまで考えることは少ないと思う。

4月までに、業務上のとあるワークフローがExcelワークシートでの管理に変わるらしい。

在宅勤務続きで、現状のワークフローが実態に即していないことがあって、見直しがはいることになったのだが、

新しい仕組みでは 起票→承認 というようなフローで表現しにくくなったので、

ワークシートに必要事項を記載し、記名するという運用になったようだが、なんだかなぁと。

ただ、従来のワークフローもいろいろほころびがあって、どっちもどっちという気はしなくもない。

でも、さすがにワークシートに記名するって、なりすましとかそういう問題じゃないんだよなぁ。

厳密なことをやろうとすると、そういうシステムを構築してもらわないといけないけど。

いや、本当はそれをするべきだと思うんだけどね。

そこでExcelワークシートにスクリプトなどで自動入力する仕組みを作れないものかと。

いろいろ調べてたところ、Microsoft Power Automationが最近になって社内向けに開放されていたらしい。

もともとMicrosoft Flowという名前だったのが改められたらしい。

これを使うことでこういうことができそう。

1. Microsoft Formsで作られたフォームに必要事項を入力
2. 1.をPower Automationで受信して、上司にMicrosoft TeamsかE-mailで承認依頼を送る
3. 上司からのレスポンスをPower Automationで確認して、承認されたらExcelワークシートに自動入力する

あるいは、こういうこともできそう。

1. Excel Onlineでワークシートにコメントを付ける(コメントには記載者情報が付く)
2. Power Automationでワークシートにコメントが付いたことを確認して、ワークシートに自動入力する

ExcelについてはExcelScriptというスクリプト言語が呼び出せるので、それでそこそこ複雑な処理もできる。

ワークシートの編集はパスワードロックをかけておいて、

Power Automationで自動入力するときだけ一時解除する仕組みにすれば、誤記が起きることはないだろう。

(といっても、厳密な編集制限はできないと思われるので、気休め程度かもしれないけど)

このPower Automationというツールは、何らかのトリガによって、各種処理・条件分岐を行うものである。

トリガを発生させるのが自分だけならば「ボタン」というトリガもあるのだが、

他の人が入力を受けてやるとすれば、自動フローと呼ばれる何らかの事象を受けて動くものか、スケジュールに従って動くかどちらかである。

自動フローは、メールの受信、Teamsのメッセージ受信、ファイルの変更、Formsの入力などをトリガにできる。

というわけで、Power Automationを起動させるというよりは、ファイルを編集するとか、そういうところを入口にするといいみたいですね。

最初はVBAかなぁなんて思ったけど、用途からするとWebベースのインターフェース(Teamsもそう)を入口にした方がよさそうで、

いろいろ勘案するとVBAは選択肢に入らなくて、なんかいい方法はないかなぁと悩んでリファレンス見てたら、

Power Automation使えと書いてあって、これうちの職場で使えたか? と思ったら最近になって使えるようになってたと。

ただ、できることは多いなりに制約も多いので、なかなか難しいんですけどね。

しかしまぁMicrosoftもいろいろ作ってるもんだなとは思いましたね。

これ何に使うんだ? みたいなツールがたくさんあるとは思ってたけど、うまく組み合わさるようになってるんですね。

最近、Microsoft Accessで作られたデータベースをカスタマイズしている。

前任者がAccessで登録情報をもとにあれこれ計算するシステムを作ってたんですね。

今までAccessはあんまり触ったことがなかったので、こんな風になってるのかと見ながらやっている。

カスタマイズ内容がAccessのリレーショナルデータベースの処理で全て実現できればよいけど、

ならないところはVBAでスクリプトを組みながら、利便性を高めているところ。

このシステム、クエリに複雑な計算式が埋め込まれていて、

それでもってあれこれと計算を行う仕組みになっているのだが、計算式の見通しが悪く理解に苦労したところはある。

シンプルな計算式とデータベースの結合を巧妙に使っているところはうまくやっているなと思ったが、

不正な入力があるとおかしな結果になるので、それをチェックする機能をフォームにつけたりというのはあった。

なかなかままならないものである。

WikipediaのMicrosoft Accessの説明にこう書いてあって、確かにそうだなと思ったんだけど。

データベースに精通した技術者であれば、比較的高度なアプリケーションが開発できるが、そうではない人でも各種のウィザード機能を使用することにより小規模で簡単なアプリケーションの構築が可能であるとしている。データベース入門者に対して敷居が低いように見えるが、効率のよい実用的なシステムを構築するには、それなりの技術が必要である。

(Microsoft Access (Wikipedia))

作り込みできる部分は多いのだが、そのためにはデータベースやAccessというアプリケーションの知識が必要である。

Accessで作り込んだシステムを維持管理していくためには、そこが課題である。

同じようなことがExcelのワークシートで作り込まれていたとすればここまで苦労はしないけど。

ただ、使い勝手の面で問題があるということで、Accessで作り込んだんだと思うけどね。

前任者の意図は理解できるが、引き継いだ方としては正直苦労しているというのが実情ですね。

システムを理解することの難しさ、Accessというツールへの親しみのなさ、

そして前任者の作り込みに甘い面があり(実運用してわかることはあるんだけど)、十分な引き継ぎもない中で対応を迫られたこと。

このような状況で、当初は取り付きにくく、なかなか辛い話だった。もうだいたい理解したからいいですが。

もちろんAccessにもよい面はあるし、リレーショナルデータベースの知識があれば解決できる問題は多い。

情報処理技術者試験でもおなじみの話ではあり、IT技術者なら知っていて当然の知識ということである。

もっとも、うちの職場で自分のことをIT技術者だと思っている人はほとんどいないので、この知識に期待するのは難しいけど。

そう考えるとダメだと思うんだけどなぁ……