日次まとめ 2021年03月13日

一般

ゲーム

『メタルマックス』30周年直前生放送をリポート。『メタルサーガ』完全新作などの新展開に関する発表も！ – ファミ通.com

技術・事業・セキュリティ等

楽天モバイル、英ストラスクライド大と自律ネットワーク共同研究へ – ケータイ Watch
ハッカーたちが脆弱なExchangeサーバーを悪用してランサムウェアをばらまいている | TechCrunch Japan
万能ノートアプリ｢Notion｣をベンチャーが絶賛する理由…1000万ユーザー超の急成長には理由がある | Business Insider Japan
Notionについては色々書きたいことが溜まり続けていて、良い機会なのでちょっと記載する。

自分も今年に入ってから公私で結構ガツガツ利用していますけど、
さすがに「万能」と呼ぶのは言いすぎで、不満はあります。

もしかすると自分がまだ「知らない」だけの可能性はありますが、現時点の自分の知識だと下記です。

一番の不満はデータベースをlookup的な使い方ができないこと。
やろうとした場合は「relation」でデータを手動で紐づけることしかできないので、ここは不便です。
「formula」(関数)使って特定のデータベースを条件付きで参照のみできる機能は激しく欲しい。

例えば、何月何日が祝日かという祝日テーブル(データベース)を作成していた場合、
別のデータベースから、その祝日テーブルを参照して、自分の日付が祝日かどうか判断する、
といったようなことが現時点の仕様ではできない(relationでデータを指定すれば参照はできるが、
つまりそれは手動操作・指定なので、自分の要件はクリアできない)。

こういったことは「自動化」してこそ業務の効率化ですからね。
マジでlookup機能は「must」(マスト)で欲しい。

あと、データベースで「rollup」したデータ(relationしたデータの参照・集計)に対して、
別データベースから「relation」の対象にできないというのはちょっと不可解。

というのも、「rollup」したデータを別プロパティで「formula」で転写して、
その転写した方なら別データベースからでも「relation」の対象にできるんです。

中身は同じデータなのに、どういうこと？となるので(内部的な動作仕様上の制限があるんだろうけど。
例えば「集計」されたものは確定データではなく、変動しうるものなので挙動・仕様としては理解できる)、
この辺とか、改善の余地はあるんじゃないのかなぁと。

あ、あともう１個あったな。「formula」で指定するプロパティ名を動的にできない＋α(正規化が不向き)。

今のところ使える関数は高機能とは言えないので、
複数データベースを組み合わせるってのがそもそもNotionの今の仕様では不向きなんです。

(複数のデータベースにある必要な(使いたい)データは全部１プロパティずつ手動でrelationが必要。
relationはデータベースに対してではなく、データベース内のプロパティに対してしか行えない。
データベースの紐づきというより、個別データの紐づき)

それでも無理にやろうとした場合は、少々複雑(面倒)なことをしていかないといけないのですが、
そういった際などでどうしても動的にプロパティ名を作って指定したいときがあるんです。

例えばプロパティ名が「name」のデータを使いたい場合、
「formula」で指定する際は「prop(“name”)」になりますが、
これを「prop(“na” + “me”)」みたいに算定して指定することはできないんです。

同じように、じゃあ、と思って、例えば「test」という名称の別プロパティを作って
そのプロパティでformulaを使って「”name”」という文字列データを生成するようにして、
その生成したデータ使って、「prop( prop(“test”) )」みたいな参照ができるか、というとこれもできない。

つまり、プロパティの指定はリテラルしか許容されていないんです。

結局、自分が検証した際は、とにかくrelationして、rollupして、formulaで転写してとかを駆使して、
さらにその上で、目的は「自動化」ですから、
formulaで長いif文を書いて使いたいプロパティを判別して、ってやってました。
ね、「面倒」でしょう・・・。
最終的にそういった運用での手法は止めました(検証段階での判断として)。
作成時点ではともかく、メンテや構造変化した際の対応に時間がかかる将来性の無い設計には耐えられなかった。

強いて面倒さを軽減させる手法と言ったら、自分が考え付いたのは、
一つのデータベースにできるだけデータを集約しておくことくらいですかね。
そのデータベースを基盤にする場合は、単純にそれだけで必要なrelationが少なくなりますから。

で、そのデータベースに対するデータの登録は「linked databases」機能を使って、
種別等ごとにフィルターして、それごとにデータベースページを分けて、
見た目は複数データベースっぽいけど、中身は一つのデータベース、
みたいな疑似的な環境にしておく、とか。

(正規化はされていないので、データベース設計的に悩ましい部分はあるとは思うが、
Notionの今の仕様だとそういったデータ構造が参照・集計する上では最も向いている。
ここはリレーションが複数あるデータベースをNotionで作ろうと思ったのなら、
一番に抑えておかないといけない点。
データベース(テーブル)を分けて作り始めると、うんざりする目に合いまくる)

さらにもう１個思い出した。
markdown記法のテキストがある程度は使えるのですが、表(テーブル)については、
markdownの表(外部テキスト)をコピペでNotionに貼り付けた場合、
データベースとしての「テーブル」になってしまうんですよね。

(一部の表記は「テーブル」にならずただの「テキスト」になってしまうケースもあった。
セル内に改行を含むテキストとかだとほぼそうなったような記憶。
ああ、そういえば「リスト」の中の改行も不完全だったな。
リストの方は改行が半角空白に置き換わっていた)

データベースとしてテーブルをコピペだけで生成できるのは、
これはこれで便利なんですけど、いわゆる単純なHTMLの「テーブル」の表現も欲しいなと思ってます。

Notion上のテーブルは全部データベース扱いなので、
markdownファイルをNotionにインポートした後、確認と修正になかなか難儀しました。

(最終的に自分は外部のmarkdownエディタの方のテーブルをキャプチャして、
画像として、テーブルをNotionに貼り付けてる。これは量が多くなかったので手動で対応した。
ちなみにNotionはブラウザでの利用でも、クリップボードから画像の貼り付けが出来る。

自分は「atto」を使って、矩形でキャプチャーして、そのままctrl+cからのctrl+vでNotionに貼り付けて終わり。
attoでキャプチャーして付箋のようになったものもescキーですぐ消せますから、
実ファイルは発生しませんし、キャプチャーのリトライや破棄に関しての手間も本当にない。

さらに脱線しますが、キャプチャーしたものをWindow化したい用途なら「Rapture」をおすすめします。
Raptureもctrl+cでクリップボードに入ります)

上記の仕様や機能不足で、データベースでちょっと高度なことをやりたいときに足かせになって実現できないものがあって、
Notionを使い倒したいのに現状はできない、という感じでした。
(もちろん書いていないところで、地味に使い勝手に言及したい箇所はありますけど、
慣れや、将来的に改善しうるだろう細かい挙動なのでその辺は割愛)

ある程度シンプルな構成なものだったら問題はないので、Notionは用途を割り切って使っています。

自分の場合は仕事だと用途によってkintoneやGoogleスプレッドシート等を使い分けて併用しているからってのもありますが、
やっぱりNotionは慣れると一つのページで色々実現できて、とても使い勝手自体は良いので、
前述の部分がNotionで実現できるようになるだけでも、利用率がかなり上昇するのになぁと。

(少なくとも現時点のNotionの仕様・機能でも、Google Sitesは自分の中でいらない子になってます。
ああ、案件によっては一部の議事録もGoogleドキュメントからNotionに記載するように運用を変更しているものもある。
リスト＝箇条書きで書いたり、To-doのチェックボックス配置できたり、画像やファイルもアップロードできるし、
ひな形＝テンプレートでページを作成できたりするので、データベースのテーブルでそれを実現すれば一覧で検索等の要件も満たせるし、
タグ付けなんかもそれ用のプロパティを作れば簡単にできるし、
「ページ」の作成、という目的においてはNotionの使い勝手は本当に良い)

ちなみに、「COMING SOON」として提供予定となっているContent APIにも期待はしています。
昔使っていたサイボウズLiveのデータ(自前のツールでJSONと実ファイルで退避済み)、Notionに移行したいなと画策している(量的に手作業だと大変なのでAPI次第で検討予定としている)。

みたいな感じで、自分の中では近年のWebサービスの中では一番Notionに熱量がある状況なのは確かです。

でもまだNotionに依存はしたくはないですけどね。
前述の仕様もそうだし、何より表示がえらい遅いことがちょくちょくある。
例えばローディングのアイコンとかが何もでないから余計にそれは困るというか、
ストレスになるというか(データベースのデータが途中までは表示されるけど、
その先がなかなか出ないとか。自分は「その先のデータがある」ことは知っているから
待てるけど、他ユーザーにそのデータベースを見せた場合、途中まで表示されたデータが
全てだと思ってしまいかねませんからね。こういったユーザビリティで甘いところもまだ目立ちます)。

ああ、まぁ、この辺は「細かい」ことなので、ひとまずは割愛。

こういった不満の裏を返せば、だからこそ「期待」しつつ、最高のツールになるよう熱量を向けている、ってのが正確か。
今に満足していることに対しての熱量ではないってのは勘違いしないで欲しいところだ。
だからこそベンチャー受けしているのかもなぁ。

関連(Notion公式)：Help & Support

その他

1月から発生しているKP41エラーが約2週間ぶりに発生(前回は3/1)。
これで7回目だ。いくつか可能性が高そうなのは逆に後回ししてまだ対応していなかったので、
そのうち、自分の中で１番可能性が高そうなのを今回対応した。
これでどうかなぁ・・・。
そしてもう１つ、Explzh。
定型圧縮後にプロセスが残る現象(少なくともVer 8.32で確認)、
アップデート(Ver 8.35)してから普通の展開でもプロセスが残るケースが頻発しだした。
(Windows 10 Pro, ver.20H2環境)

(ちなみにプロセスが残るタイミングについては
定型圧縮はbatから呼びだし、展開はシェルエクステンションから実行しているのですが、
それぞれ圧縮、展開が終わった「後」に、タスクマネージャーを見ていると、
Explzhのプロセスが出現し、CPU使用率が一時的にガッと増えるので、
そこで何かの処理をしているんでしょうけど、そのCPU使用が落ち着くと、
通常ならプロセスがそこで終了されるのに、そのまま残ってしまう、って感じです)

でも何か条件はありそうなんだよな。
100%起きているわけじゃない。ある程度時間がかかっているものか、
ファイル数が多いものか、そういった類だと発生している印象。

自分の場合、定型圧縮機能を使っているものは時間がかかるものなので、
100%発生してしまっている雰囲気。
今回、展開で確認できたのは圧縮後の容量が、
150MBくらいのもので時間がかかっていた、ってのがある。

試しにfsutil使って、1MBのダミーファイルを複数個生成し、
それをzipにしてみるケースで試したんですけど
よくよく考えればfsutilが生成したデータは0x00のみで構成されているので、
例えばzipで圧縮すると、1,000個(1GB)あっても、約1MBまで圧縮されて、
そこまで処理に時間がかからず、件の現象も発生しないという。

で、一気に10,000個(10GB)まで増やしたら、再現しました。
しかも、圧縮時と展開時、両方とも。
(今回の検証ではシェルエクステンションからの実行のみ)

気になったのは、
Antimalware Service Executable (Microsoft Defender Antivirus Service)
の方が異様にメモリを食った状態だったことですかね(1,726.8 MBくらいまでは膨らんだ)。

Explzhのプロセスを終了させても、使ったデータを削除しても、
しばらく待ってもメモリ使用量が全然落ちなかったので、止む無く再起動しましたし
(起動直後は127.7 MBだったので、どれだけ膨らんでいたか)。

CPUもディスクもネットワークも使用率が動いていなかったので、
見た目的にはメモリリークでもしてるのか？状態。
(10GBもファイル生成とかしてたから、メモリをあえて確保している可能性はわからなくもないが)

もし環境依存があるとしたらセキュリティ系のソフト、という可能性は十分にありますからねぇ・・・。

やっぱりこれ、製作者に問い合わせないと糸口が見えない系かなぁ・・・
対外的なことにどうにも時間を使いたくない。。
まだ様子見しておこう。どこかのアップデートで治るやもしれない、という消極的姿勢で行く。