コマンドラインから開いた Firefox.exe がなぜか新しいプロファイルとして開始される件
辞書サイトを「ファイル名から指定して実行」から素早く Firefox で開けるようにするため、以下のような e.bat を作成して、PATH に通していた。
set a=%* start "" "c:\Program Files\Mozilla Firefox\firefox.exe" "http://(辞書サイトURL)/%a%"
これで「e hello」と打つだけで「hello」について引いた辞書サイトページが Firefox で開かれる。今までは動作していたが、急に動作しなくなった。
前提環境
- Windows 7 Pro
- Firefox v67
発生内容
上記 e.bat を実行すると、なぜか以下のようなことが起きるようになった。
- 今まで: 既存の Firefox ウィンドウに新しいタブとして辞書ページがオープン
- 今回起きた: 新しい Firefox ウィンドウが新しいプロファイルで開かれて 辞書ページがオープン
発生契機
たぶん Firefox v67 から。v66 以前では発生してなかった。
対処方法
間違い探しみたいだが、以下のようにした。
Before:
set a=%* start "" "c:\Program Files\Mozilla Firefox\firefox.exe" "http://(辞書サイトURL)/%a%"
After:
set a=%* start "" "C:\Program Files\Mozilla Firefox\firefox.exe" "http://(辞書サイトURL)/%a%"
Firefox のパス先頭の c:\ を C:\ と大文字にしている。これで動くようになった。
大文字小文字に気をつけよということだろうか？
原因は？
よくわからん。
Firefox 本体が自身のパスを読み込む際に大文字小文字を考慮してうんたらかんたらしているのだと思われるが、何のために？……よくわからん。
AWS の KeyPair(キーペア) の意味や働きがよくわかってなかったので整理した
キーペアは EC2 インスタンスにログインするための一つの手段。このあたりの話題、いっつも忘れるのでまとめた。
キーペアとは
下記 AWS ドキュメントの抜粋。
パブリックキーとプライベートキーは、キーペアと呼ばれます。
つまりは(公開鍵暗号方式で用いる)公開鍵と秘密鍵の組のこと。
公開鍵暗号方式はデータ暗号化の一手法で、パブリックキー(公開鍵)で暗号化した情報はプライベートキー(秘密鍵)でのみ復号できるという性質がある。これを応用すればログイン認証が行える。
どうやってログイン認証を行うか
- 1: ユーザーは EC2 インスタンス作成時、キーペアを一つ割り当てる
- キーペアは事前につくっておく or 管理コンソール上でその場でつくる
- 2: AWS は 1 のインスタンスのログイン情報を、1 のキーペアのパブリックキーで暗号化しておく
- 3: ユーザーは 1 のインスタンスにログインする時、プライベートキーを使って AWS に問い合わせる
- すると AWS 側が暗号化されたログイン情報をそのプライベートキーで復号化する
- 正しく復号された → この人は正しい人ですね、ログインを許可します。
- 正しく復号されない → あんた誰だよ、ログインさせねえぞ。
つまり事前に AWS にキーペアを教えておけば、AWS 側は「ああ、この人のプライベートキーで復号できたんだから、この人はこのパブリックキーの持ち主なんだな」ということを判断できる。つまりは認証ができる。
実際はもう少し AWS 側が融通を利かせてくれて、以下のような感じ。
- Linux の場合 → すぐにログインできる(SSH によるログイン)
- Windows の場合 → Administrator パスワードをゲットできる(ので後はそちらでパスワード管理するなり変えるなりしてね)
キーペアの作り方
- 1: EC2 > ネットワーク＆セキュリティ > キーペア
- 2: キーペアの作成ボタン
- 3: キーペア名を適当に入れる
- 4: キーペアがつくられる
- この時、pem ファイル(プライベートキー)のダウンロードが始まるので、ダウンロードしておく
pem ファイルの入手チャンスはここしかないので、ここを逃したら、もうこのキーペアのプライベートキーは入手できなくなる。
(余談) フィンガープリントとは
フィンガープリント(元々の意味は「指紋」)とはプライベートキーのハッシュ値(厳密に言えば SSH？の仕様として定められたハッシュ処理によって導出されたハッシュ値)のこと。
用途は改ざん防止。もっと言えば「(1) ユーザーが手元で持っているプライベートキー」と「(2) AWS 側に登録されたプライベートキー」が本当に同じものであるかを確認する用。
管理コンソール上に表示されているのは (2) のフィンガープリント。(1) についてもフィンガープリントを計算してやれば確認できる。同一なら改ざんされてない。同一でないなら、改ざんされている。
プライベートキーからフィンガープリントを計算するには以下コマンドを使う。ssh-keygen コマンドでは上手く計算できない。
$ openssl pkcs8 -in xxxxx.pem -nocrypt -topk8 -outform DER | openssl sha1 -c
参考
Windows 7 で遅延付きの(タイマー実行の)画面キャプチャを実現する
Windows 10 だと簡単に行えるが、Windows 7 だとちょい苦戦した。 (2019/06/28 追記) WinShot にタイマー機能があるのでこれを使うのが楽です。環境設定 > その他の設定 > 時間差キャプチャ から秒数を指定できます。
前提
- PC
- 自分の PC は Windows 7
- vSphere Client のコンソールウィンドウで RHEL7 を開いてる
- この RHEL7 画面をキャプチャしたい
- キャプチャ画像は自分の PC で扱いたい
結論
バッチファイルをつくり、timeout コマンドで時間待ちを、commandcap でコマンドラインベースのキャプチャを行う。
@echo off echo 遅延実行します... timeout 3 python commandcap.py -a --png -o C:\data\screenshots --format "$2"
実際のキャプチャ手順は以下のとおり。
- 1: 上記バッチを起動する
- 2: 3 秒経つ前に、vSphere Client コンソールの RHEL7 をアクティブにする
- すると3 秒後に commandcap が働いてキャプチャが行われる
導入
詳細は割愛するが以下のとおり。
- Python 3 が必要
- commandcap は GitHub に置いてる
以下は試行内容のメモ
WinShot にタイマー機能はある？
Ans: 無い。
snippingtool にタイマー機能はある？
Ans: Windows 7 の snippingtool には無い。
Windows 10 の snippingtool を Windows 7 に持ってくるのは？
Ans: 動かない。
このファイルのバージョンは、現在の実行中の Windows のバージョンとは互換性がありません。コンピューターのシステム情報を確認して、x86 (32 ビット) または x64 (64 ビット) のどちらのバージョンのプログラムが必要であるかを確認してからソフトウェアの発行者に問い合わせてください。
RHEL7 のスクリーンショットを使うのは？
Ans: それでも可能だったが、今回は RHEL7 上の画像データを自分 PC に持ってくる手段がなかったので無理だった。
今回は環境の都合上、踏み台マシンからアクセスするようになっているのだが、使える IP が限られている＆他に使える IP がない＆申請も面倒くさそう、ということで諦めざるをえなかった。
テキストファイルをエディタで修正するスピードを競うゲーム edita.py をつくった
edita.py というゲームをつくった。
どんなゲーム？
ゲーム本体は edita.py というスクリプト。
実行すると、edita.py は問題文ファイルをつくった後、（ユーザーの修正を判定するため）監視に入る。
ユーザーはエディタで問題文ファイルを開いて修正する。修正できたと思ったら上書き保存。そしたら edita.py が（タイムスタンプを見てるので）更新を検知して答え合わせをする。正解するまで先に進めない。
正解したら先に進める（ラップタイムが出る）。edita.py が次の問題文をつくるので、ユーザーはエディタ側で再読込をかけて、次の問題文ファイルを修正する……と、こんな感じで遊ぶ。
全ラップを終えたら終了。合計タイムが表示される。
修正とは
問題文ファイルは小文字英単語の集まりに「一部だけ大文字が混ざった」ものだが、ユーザーのミッションは 大文字部分を見つけて、全部小文字に修正する こと。
以下は 32x10 で修正数 10 の問題文サンプル。左が問題文で、右が答え
jay liechtEnstein added shots pa jay liechtenstein added shots pa tch isa cAstle pErhaps dl notes tch isa castle perhaps dl notes million retrieved trauma elegant million retrieved trauma elegant engineer pas sellers ShakeSpear engineer pas sellers shakespear e hills mild gentleman dIctionar ===> e hills mild gentleman dictionar y conversations heights bP hunti y conversations heights bp hunti ng winners bubbLe arkanSas manda ng winners bubble arkansas manda tory deputy decorative postage p tory deputy decorative postage p rocessor calvin fair combinaTion rocessor calvin fair combination s ocean proposal js bat skilled s ocean proposal js bat skilled
ちなみに修正箇所は以下のとおり。
jay liecht[E]nstein added shots pa tch isa c[A]stle p[E]rhaps dl notes million retrieved trauma elegant engineer pas sellers [S]hake[S]pear e hills mild gentleman d[I]ctionar y conversations heights b[P] hunti ng winners bubb[L]e arkan[S]as manda tory deputy decorative postage p rocessor calvin fair combina[T]ion s ocean proposal js bat skilled
ユーザーに要求される能力
- エディタの操作スキル(特にカーソル移動系の操作)
- 正確なタイピング
- 大文字を素早く探せる動体視力あるいは正確性(焦るとマジで見つかりません)
ちなみにズルすれば秒単位で解ける（たとえば選択範囲を lowercase に変換する機能があれば、全選択→変換→上書き保存で一発）けど、それではゲームにならないので、ぜひカーソル移動で遊んでみてください。
実装の話
工夫したこと
最初はブラウザで遊べるようにすることを考えたが、ブラウザの textarea だとストレスが溜まってゲームどころじゃないと思い直した。愛用のテキストエディタで遊びたい。
しかし私の愛用は秀丸エディタであり、秀丸エディタのユーザー層でこういうゲームを遊ぶ人は相当限られていることが予想された。Qiita の読者層にも届くような手段が欲しい。ふとひらめいたのが、
- ユーザーはテキストファイルをいじる
- ゲームシステムはそのテキストファイルを監視して判定する
こんなアイデアだった。試しに書いてみたら、ああ普通に遊べるじゃん、とわかった。
ファイルの監視
無限ループでタイムスタンプ（更新日時）を調べて、前回の値と違っていたら読込をかけて判定するという形にした。
タイムスタンプは st_mtime_ns でナノ秒で取る。
def get_lastmodified_nanotime(filename):
stat_result = os.stat(filename)
return stat_result.st_mtime_ns
監視は以下のように無限ループ（いわゆるゲームループ）。ただし sleep しないと CPU 食い切って重くなるので 0.01 秒にしてる。
cur_ns = get_lastmodified_nanotime(tempfilename)
while True:
sleep(0.01)
latest_ns = get_lastmodified_nanotime(tempfilename)
if latest_ns == cur_ns:
continue
cur_ns = latest_ns
...
前回のタイムスタンプ値は cur_ns に保持。今のタイムスタンプ値は latest_ns。latest_ns と cur_ns が違う値になった = タイムスタンプが変わった = ユーザー側で修正（上書き更新か）かけられたと判断している。
タイムの計測
「ゲーム開始時の現在日時」と「ゲーム終了時の現在日時」を記録しておいて、後者から前者を引くことで秒数差分を求めるというやり方にした。
Python だと datetime という素晴らしいライブラリがあるので楽できる。
以下は現在日時の datetime オブジェクト(コードでは dt という名前を付けている)を取得する関数。
def get_now_by_dt():
""" @return A datetime object """
return datetime.datetime.now()
以下は datetime オブジェクト二つの秒数差分（ただし精度が欲しいのでマイクロ秒）を求める関数。datetime オブジェクト同士を引くと timedelta オブジェクトになる。これも datetime ライブラリの恩恵。楽すぎる。
def diff_microseconds_between_dt_and_dt(dt_future, dt_past):
delta = dt_future - dt_past
microseconds = delta / datetime.timedelta(microseconds=1)
return microseconds
最後に秒の精度を調整。1秒だと荒いし、1.111秒だと細かいかなと感じたので、1.11秒の精度に。以下のような関数を書いた。リーダブルなコード（意図をコメントで残してる）を意識してみたのですが、どうでしょうか。
def convert_microseconds_to_edita_score_float(microseconds_by_float):
# dt1 = get_now_by_dt()
# sleep(1.5)
# dt2 = get_now_by_dt()
# ms = diff_microseconds_between_dt_and_dt(dt2, dt1)
# print(ms)
# -> 1513190.0
#
# 1 <- too rough
# 1.5 <- rough a little
# 1.51 <= I chooose you!
# 1.513 <- too grain
return round(microseconds_by_float/1000000, 2)
問題文の作成
一行一単語が並んだファイルから単語リストを読み込んで、そこからランダムに選ぶ……という愚直なアルゴリズムにしている。解説は面倒なので割愛。
今回一番苦労したのは実は 単語ファイルの入手 だったりする。本当は edita.py にくっつけて配布したかったのだけど、配布 OK な単語ファイルが見つからなかったので「各自ダウンロードしてね」で妥協した。
※唯一見つけたのは SecLists という MIT LICENSE の単語リスト。これは「よく使われてるパスワードベストn」みたいな単語リストを扱ってる……けど、単語が偏りすぎると数字も混ざってて使いづらかったので、今回採用は見送った。
長文の Word を読みやすくするための表示設定(Word2013)
Word 文書のメンテという聞くだけで反射的に拒絶してしまいそうな仕事を手伝うことになったが、悲観していても仕方ないので、少しでも読む負担を減らすことを考える。
目次ペインを設ける
- 表示 > ナビゲーションウィンドウ > 見出し
ステータスバーに実際のページ番号を表示
- ステータスバー右クリック > 書式設定されたページ番号 のチェックを入れる
- ページ番号 のチェックを外す
変更履歴を全部消す
事前に複製＆ローカルに置いた上で、
- 校閲 > 削除 > コメント からコメントをすべて消す
- 校閲 > 承認 > すべての変更を反映からすべての履歴を消す
- 校閲 > 承認 > 変更履歴の記録 をオフにする
もちろん現物に対して消してもいいかどうかはプロジェクト次第。ただいったん読む分には、履歴は邪魔なのでこうやって消すと楽できる。
必要に応じて新しいウィンドウ
表示 > 新しいウィンドウ から今見てる Word ウィンドウを複製できる。必要に応じて複数枚開いて行き来すると（一枚の Word 内であちこち行ったり来たりするよりは）読みやすい。
ポメラ DM200 の後継版 DM300 があるとしたら僕はこういうものを望みます
ポメラニアンの間で「ポメラ DM300 はどうあるべきか」という持論や要望を展開する遊びが流行っている……というのは嘘だが、いくつかのブログ記事があった。それらを読んで、僕も語りたくなったので、存分に語ってみる。
次期ポメラへの要望(欲しいもの)
マルチウィンドウのサポート
僕が一番欲しいのは、ファイル A を編集している間に、別のファイル B の中身を ファイル A を開いたままで 見る――という機能。
「え？いったんファイル A を閉じてファイル B を開けばいいじゃん」と思われるかもしれないが、それは手間である。PC でのたとえになるが、デュアルディスプレイがなぜ生産的かというと、視線移動だけで他の情報にアクセスできるからだ。「ウィンドウ重ねて Alt + Tab やタスクバーから切り替えればいいじゃん」とはならない。
僕のように短期記憶にすぐれない者は、デュアルディスプレイのように 視線移動(に限りなく近いレベルでの低コスト)で、他のファイルの内容も見たい のである。
この機能がサポートされれば、長編小説や書籍の執筆も射程に入る。
ユーザー辞書の導入
新しく登録した単語はそれ専用の設定画面と一覧を用意してほしい。
DM200 では「ユーザーが新しく登録した単語」と「自動学習で学習させた単語」とがいっしょくたになっている。前者のみにアクセスすることができず、メンテしづらい。
Google 辞書でいうユーザー辞書の概念。あれが欲しい。
見出し単位の範囲選択に対応してほしい
Ctrl + Shift + Up/Down で、見出し単位の範囲選択もできるようにしてほしい。
最後に編集したところに戻る
秀丸エディタには「最後に編集したところに戻る」という、文字通り最後に編集した箇所に一発で戻れる機能があるのだが、これがポメラにもあると便利。
何が便利かというと、一通り編集し終えた後、あちこち読み返して、「執筆を続けるかー」となった時に、さっき編集し終えたところに一発で戻れるのである。
カーソルキー上下で変換候補を選択
ATOK の仕様なのかもしれないが、DM200 では変換時にカーソルキー上下で変換候補を辿ることができない。カーソルキー下を押すと変換が終わってしまう。
- 上候補: カーソルキー上
- 下候補: スペース ← ここにカーソルキー下も加えてほしい！
カレンダー強化: ジャンプ
DM200 の素晴らしい点の一つがカレンダーだと思う。この「時系列にメモできる機構」は、使い道があれば極めて強力である。
さて、要望だが、カレンダーの各予定に一発ジャンプする機能が欲しい。たとえば、
- 最後の予定に移動
- 最初の予定に移動
- クイック移動(数字キー 1-9 に指定日を割り当てて、キー一発でその日を開く)
といったもの。つまりはキー一発で指定日に素早く飛べるようにしたい。現状 DM200 ではカーソルキーで頑張ってスクロールするか、予定に検索キーワードを付けておいて検索からジャンプするかしないといけない。もうちょっと素早くアクセスしたい。
カレンダー強化: 複数カレンダーのサポート
カレンダー絡みの要望をもう一つ。
カレンダー設定を複数保持したい。
カレンダーの用途は以下のように様々であるが、
- 小説Aの時系列カレンダー(2017年4月から始まる)
- 日記カレンダー
- スケジューラー
- サブのメモ用(カレンダーは今開いているファイルを閉じずに開けるので、サブのメモ手段として重宝する)
- ……
DM200 ではカレンダー設定が必要しかないため、これら設定がすべて混在してしまう。設定は分けて、切り替えられるようにしてほしい。
一ファイルの文字数制限緩和
DM 200 の一ファイルの最大文字数は、説明書によると「1文字3バイト換算で10万文字くらい」となっているが、これをもう少し緩和してほしい。アウトラインを使って文章を書けば、一ファイルが 10 万文字を超えることはよくある。日記で1日2000文字書けば 50 日で到達するし、小説では文庫本一冊分の原稿も書ききれない。
文字数で言えば 30 万文字くらいは緩和してほしいかな……。
あとは処理速度もか。DM200 では 7 文字くらいでも保存に数秒かかるくらいもっさりする。これを秒以内に抑えてもらえると非常に助かる。
今は 10 万文字以下だと思っている（試したことない）けど、数十万文字耐えられるようにしてほしい。 保存のスピードとかも。今は 7 万文字くらい書くと保存に数秒を要する。
次期ポメラへの要望(やらなくていいこと)
ハードウェア面はこのままでいい
ハードウェア面では DM200 は現状でも理想に近いと思ってる。
これ以上小さくてもダメ。使いづらくなる。
これ以上大きくてもダメ。携帯しづらくなる。
タッチパネルも要らないし、バックライトも要らない。そんなもののために貴重なリソースを費やす必要はない。タッチはキーに比べればまだまだ不安定だし速度も遅いし技術的にもリソースを多く費やす必要がある。バックライトは、そもそも「暗い環境でも使えるようにする」がニッチすぎるし、その割にはリソースを食うから、費用対効果があるとは思えない。
画面構成も不満無し
他のブログではステータスバーがほしいといった要望があったが、ステータスはメニューからたまに見ればいい。リソースを投じてまで、リアルタイムで表示し続けるほどの価値はない。ただし、余裕があるなら表示非表示を選べるようにした上で、サポートしても良い。
他のツールは要らない
ブラウザや表計算が欲しいといった要望も見受けられたが、正直言って要らない。
それではもはやスマホである。あるいは PC か。ポメラという執筆端末としての価値は失われれる。ポメラは万能ハイテク端末ではない。携帯性に優れた執筆マシンである。
通信や同期機能も要らない
上と被るが、ポメラは執筆マシンであるべきで、通信や同期に頼るのは本質から逸れているように思う。DM200 の Sync や QR コード程度なら良いが、これ以上高級な通信や同期を（リソースを費やしてまで）取り入れる必要はない。そんなことに費やすくらいなら、エディタの操作性や機能、あるいは性能の向上に力を注いでほしい。
要望ではないが持論
ポメラのあるべき姿
ポメラはポメラ単体で快適に文章執筆できることに特化するべきだと僕は思っている。
たとえるならデジカメのようなもの。デジカメは撮影に特化したデバイスである。撮影物の編集加工やアップロードを、デジカメそのものから行うなんてことはしない。それは後で、PC にデータ転送して行えば済む話だ。
ポメラも同じで、文章執筆に特化する。文章執筆のための機能や操作性や性能は惜しまず追求し、文章のその後（ポメラで書いた後）の扱いには関与しない――このスタンスこそが、ポメラをポメラたらしめている理由であり、存在意義であると僕は思う。
以下記事でも書いたが、ポメラは一つのジャンルだ。
PC でもスマホでもない、全く別の概念。コンパクトで、しかし打ちやすい文章入力端末。ただただ執筆に専念できるマシン――それがポメラだ。ウェブ閲覧とか、データ同期とか、表計算とか、そういう「執筆でない諸々」は要らない。それは後でやればいい。PC でやればいい。スマホでやればいい。タブレットでやればいい。
……もちろん、「執筆でない諸々」もできるに越したことはない。しかし、まがいなりにもエンジニアである僕には察しがつくが、まだまだ現代技術では難しいはずだ。あるいは、実現できるにしても非現実的な価格になってしまう。だったら、リソースのすべてを「文章執筆」にだけ費やして、文章執筆マシンとしての価値にウェイトを置くべきだろう。
未来のポメラに対する懸念
僕が懸念しているのは、ポメラという「文章執筆マシン」ジャンルがなくなってしまうことである。
「執筆でない諸々」の拡充を望むポメラニアン達に応える形で、今後もポメラには「執筆でない諸々」が色々搭載され、劣化版 PC のような存在に成り果ててしまうのではないか……と危惧している。
Windows しかり、風来のシレンしかり、このような悲劇は今まで幾度となく繰り返されてきた。メカニズムはわかっている。少数派の苦悩と大人の事情である。
- メカニズム
- 「必要最小限の機能美」だけではずっとは食っていけない
- 「必要最小限の機能美」を求めるユーザーは少数派、かつ「必要最小限の機能美」を理解する開発陣も少数派（そして彼らはやがて現場や会社を離れていく）
- この先食べていくためには、「必要最小限の機能美」を離れて、リッチにしていく必要がある（そうせざるをえない）
このような悲劇がポメラにも起きないことを、僕は祈っている。
参考
他にどんな持論や要望があるかを軽く調べてみた(一部 DM100 時代の古いものもあるが)。
ひとり Slack をスタンダードプランからフリープランに戻した
2年くらい前に ひとり Slack でできることと半年使った所感をまとめる という記事を書いていたが、最近の私はひとり Slack をほとんど使ってないので、フリープランに戻した。
なぜ戻したか
大して使ってないのに月 1037 円も払っていたから。
- 最初は RSS, Twitter, メモスペースとして使っていた
- 今はあまり使ってない
- そもそもネットサーフィンほとんどしない
- メモは GitHub や Dropbox に Markdown 置いてそれをローカルのエディタで書いてる
気になっていたこと
雑多にメモ。
クレジットカード情報
消えない。あとでまたスタンダードプランにすぐ戻せる。便利。
ダウングレード後、当月支払った分はどうなる？
Slack クレジットポイントとして蓄積される。
私の場合、929 円残った。Slack ではスタンダードが 850 円/月なので、このポイントで一か月分はスタンダードが使える。
メッセージ 10000 件制約
- チャンネル内で遡ってると「#XXXXX 内のメッセージはこれだけではありません」と出て、それより遡れない
- どのチャンネルもなぜか 4/20(Sat) 以前が見れないようになっている
- 問答無用で直近三週間分しか表示しない仕様 ってこと？
- ファイル検索は 10000 件制約引っかからない模様
- 一年前に投稿したファイルが検索でひっかかかった
- 一年の間に何十万というメッセージを扱っていたけど
総メッセージ数
ダウングレードする時に「あなたのチームには n 件のメッセージがあります」的な情報が出るが、私のひとり Slack では 170 万件くらいだった。RSS や Twitter のせいだと思う。
知見
フリープランでは使えないアプリもある
Email 連携とか。アプリ情報を読むと、
このインテグレーションは、Slack のスタンダードプランかそれ以上のプランをご利用のすべてのワークスペースにてご利用いただけます
みたいに書いてあることがある。
もし Slack をフリープランでもメモアプリとして使いたいのなら
- RSS や Twitter のような情報収集系は使わない方がいい
- すぐに 10000 件超えちゃうから……
- ファイルには件数制限が無い(と思われる)ので、長文はスニペットなどで管理するのが良いと思う
- 容量制限はあるけどテキストファイルなら超えることはまずないだろうし
おわりに
使ってない時はフリーにしといて、また使いたくなったらスタンダードに戻す……そんな気軽な切り替えができるとわかったので収穫です。
EMF ファイルを MassiGra で開けるようにする
Susie プラグインを入手してから MassiGra に読み込ませる。
1: Susie プラグイン入手
TORO's Software library(Win32/Win64 Plugin) の iftgdi16.zip をゲットする。
2: MassiGra からプラグインを認識する
事前にプラグインファイル(.spiなど)を配置するフォルダをつくって、1: を配置しておく。私は MassiGra 直下に plugin フォルダをつくった。
- MassiGra を起動
- 右クリック > その他 > プラグイン設定
- プラグインがあるフォルダに上記フォルダを指定
- 成功すれば .spi ファイルなどが一覧で出るので、iftgdip.spi などにチェックが入っていることを確認して OK
これで読めるようになるはず
追加設定
必要なら EMF ファイルを MassiGra に関連付ける。デフォだとペイントになってるんで。
Firefox で指定範囲日の履歴データを CSV でエクスポートする
最初は履歴管理画面からコピペで行けるかと思っていたが、これだと URL しかコピーされなくてダメ。結局 Firefox の設定ファイル(sqliteファイル)から直接吸い出すことに。
- 前提
- アプローチ
- 1: SQLite3 を入手する
- 2: Firefox の履歴データファイルを見つける
- 3: 取得したい範囲を Unixtime で表す
- 4: SQLite3 コマンドを叩いてエクスポートする
- お疲れ様でした
- (2019/05/17 追記) スクリプト書きました
前提
必須:
- Windows 10
- Firefox 66.0.5
任意:
- Python 3.6.3
- Unixtime 変換時に使ってます
- 別の手段で変換しても良いです
アプローチ
SQLite3 コマンドを使って Firefox の履歴データ places.sqlite から直接履歴データを取り出す。ただし履歴データの日付時刻が Unixtime マイクロ秒なので、WHERE 句ではこれを指定する必要がある。
1: SQLite3 を入手する
SQLite Download Page から sqlite-tools-win32-x86-3280000.zip などをゲット。
展開すると sqlite3.exe がある。これを使う。パスを通すなり作業フォルダに配置するなり。
2: Firefox の履歴データファイルを見つける
これ。
%appdata%\Mozilla\Firefox\Profiles\XXXXXXXX.YYYYYY\places.sqlite
XXXXXXXX.YYYYYY 部分はプロファイル名。
3: 取得したい範囲を Unixtime で表す
履歴データの日付時刻が Unixtime 表記なので頑張って変換しないといけない。本記事では以下 Python でやる。最悪 Unixtime相互変換ツール - konisimple tools のようなウェブツールもある。
例: 2019/04/12～2019/04/13 を取得したい場合、以下のように変換する。
- Step1. Unixtime に変換する
- 2019/04/12 00:00:00 → 1554994800
- 2019/04/13 00:00:00 → 1555081200
- Step2. 単位を揃える(マイクロ秒にする)
- 0 を 6 個つける
- 1554994800 → 1554994800000000
- 1555081200 → 1555081200000000
肝心の変換方法は、以下スクリプトにて。date() のところに値を入れる感じ。
$ python -c "import time; import datetime; dt=datetime.date(2019,4,12); ut=time.mktime(dt.timetuple()); ret='{}000000'.format(int(ut)); print(ret);"
1554994800000000
(余談) Python スクリのもうちょっと読みやすいやつ
# -*- coding: utf-8 -*-
import time
import datetime
a_dt = datetime.date(2019,4,12)
a_ut = time.mktime(a_dt.timetuple())
ret = '{}000000'.format(int(a_ut))
print(ret)
参考: Convert datetime to Unix timestamp and convert it back in python - Stack Overflow
4: SQLite3 コマンドを叩いてエクスポートする
この手順 4: を実行する前に Firefox を終了しておくこと（そうしないとデータベースの処理が競合してエラーが出るかも ← まだ試してないのでわかりません）。または places.sqlite を作業フォルダにコピーして、コピーした方を使うこと。私は後者のコピーの方で試している。
SQLite3 のコマンドはこんな感じ。
$ sqlite3 -readonly -csv places.sqlite "SELECT title,url,last_visit_date FROM moz_places WHERE last_visit_date BETWEEN 1554994800000000 AND 1555081200000000;" > history_betwee_190412_190413.csv
注意点など:
places.sqliteのパスは適宜修正BETWEEN 1554994800000000 AND 1555081200000000;には 3: の Unixtime マイクロ秒を指定> history_betwee_190412_190413.csvは適当に出力ファイル名を指定
参考: Firefoxでの閲覧履歴をCSV形式でエクスポート - Qiita
お疲れ様でした
これで以下のような CSV ファイルがエクスポートされるはず。
"Title1",URL1,1555020329870000 "Title2",URL2,1555020463990000 ...
ちなみに places.sqlite-shm と places.sqlite-wal が生成されるが、ジャーナルモードという機能みたい。そういう仕様なので気にしなくて良い。気になるようなら下記あたりを読んで勉強。
参考: Pragma statements supported by SQLite
(2019/05/17 追記) スクリプト書きました
指定日の履歴データを取ってくる Python スクリプトを書いてみました。
毎日履歴を取って記録すれば日記になることから History + Diary → Distory と名付けてみました。
AWS EC2 インスタンスへの ssh 接続でタイムアウトしないようにする
調べるとセキュリティグループだのなんだのと AWS 系の設定ネタがヒットするが、違った。結論を言うと、AWS は無関係で、単に ssh 接続一般論の話だった。 KeepAlive パケットを送るようにすれば良い。
- もう少し詳しく
- ケース1: RLogin で AWS EC2 の Linux に SSH 接続している場合
- ケース2: ケース1で SSH 接続した Linux から、さらに ssh コマンドで接続している場合
もう少し詳しく
ssh 接続元の ssh クライアントにて、KeepAlive パケットを送る設定を行う。
ケース1: RLogin で AWS EC2 の Linux に SSH 接続している場合
RLogin のサーバー設定 > サーバー > プロトコル > SSH > KeepAliveパケットの送信間隔
ここにチェックを入れ、送信間隔を適当にする。60秒など。
ケース2: ケース1で SSH 接続した Linux から、さらに ssh コマンドで接続している場合
ケース1 で SSH 接続した Linux 上で、ssh_config をいじる
$ vi ~/.ssh/config
追加するのは以下二つ。
ServerAliveInterval 60 ServerAliveCountMax 3
これは「60秒毎にKeepAliveパケットを送ります」「でも3回連続でパケットが届かなかったら(サーバーが死んでると思うので)諦めます」という意味。
AutoHotkey で Alt + Left に前のタブを開く(Ctrl + Shift + Tab)を割り当てていると、Alt + Left で Zoom ウィンドウが勝手にアクティブになってしまう件
意味不明な現象だが、挙動と回避策だけは調べておいた。
前提
- Windows 7
- Zoom クライアント ver4.1.34814.1119
発生する問題
Zoom クライアントで会議に参加しているとき、他のウィンドウ上で Alt + Left キーを押すと、なぜか Zoom ウィンドウがアクティブになる。
発生条件
- Zoom クライアントで会議に参加し、通常表示(最小化時のコンパクトな表示ではない)している
- AutoHotkey で Alt + Left に Ctrl + Shift + Tab を割り当てている(以下)
;Alt + Left で前のタブを開く
!Left::Send {Ctrl down}{Shift down}{Tab}{Ctrl up}{Shift up}
なぜか知らないが、上記二つを満たした場合に限り、Alt + Left でタブ切り替えではなく「Zoom ウィンドウがアクティブになる」現象が起きる。
回避方法
どちらもイマイチだが二つある。
方法1. AHK の設定を無効にする
たとえば以下のようにコメントアウトして一時的に無効にする。
;Alt + Left で前のタブを開く
;!Left::Send {Ctrl down}{Shift down}{Tab}{Ctrl up}{Shift up}
ちなみに Ctrl + Shift + Tab キーは普通に使える。本当に意味不明。
方法2. Zoom ウィンドウを小さな表示にする
Zoom ウィンドウを最小化するとコンパクトな表示になる。この状態だとこの問題は発生しない。
以下メモ
以下は本問題について調べたときのメモ。
- Zoom ウィンドウの位置は関係ない（たとえばX位置をマイナスにしてどのウィンドウにも表示が重ならないようにしてみたが効果なし）
- キーボードショートカットを変えるのは不可能
Slack のスニペット機能に関する仕様や挙動を調べた
Slack をテキストストレージとして使いたかったので、仕様や挙動を一通り調べてみた。
スニペットとは
チャンネル内に長いテキストを添付できる。実体はテキストファイル。
新規作成時のパラメーター
基本パラメーター:
- タイトル(記入式)
- 記法(選択式、各種言語やMarkdownなどをサポート)
- 本文(記法に応じてハイライトされる)
- 折り返し: チェック入れると折り返し表示できる
共有パラメーター:
- 共有相手チェック(共有を行う場合はチェックを入れる、共有対象は共有相手ボックスにて選ぶ)
- 共有相手ボックス(共有先となる人やチャンネル名を入れる)
- メッセージ(共有時に追加でメッセージがあれば書く)
スニペットの公開範囲
「プライベート」属性と「共有」属性がある。
プライベートチャンネルや DM などで共有すると「プライベート」属性。関係者しか見れない。
パブリックチャンネルなどで共有すると「共有」属性。誰でも見れる。
すべてのファイル
スニペット含め全ファイルは その他 > すべてのファイル からアクセスできる。ここには自分が見れるファイル（自分が所属する「プライベート」属性のものと、「共有」属性のもの）が一覧で表示される。
ちなみにスニペット作成時に共有相手を指定しなかった場合は、（どのチャンネルにも投下されていないので）ここからアクセスするしかない（後述する検索で見つけることもできるが）。
パーマリンク
三つある。
- ワークスペース関係者限定のリッチリンク(Private Rich)
- ワークスペース関係者限定の RAW リンク(Private Raw)
- 誰でも見れる外部用リンク(Public)
Private Rich は「ファイルのリンクをコピー」などでコピーされる URL。アクセスすると Slack 上で当該ファイルを表示・編集できるページが開かれる。
Private Raw は「RAW データを表示」などでアクセスできる。その名のとおり生のデータ。
Public は「外部リンクを作成」などで(URLを)作成できる。これは後で無効にすることもできる。
(SNIPPET-TITLE).(EXT) とは？
スニペットのパーマリンクにはファイル名が含まれる。
ファイル名は「スニペットのタイトル」と「記法」によって一意に決まる。ただし同じタイトルと記法を持つスニペットが重複しても問題はない(以下参照)。
https://(TEAM-NAME).slack.com/files/XXXXXXXXX/XXXXXXXXX/helloworld.py
https://(TEAM-NAME).slack.com/files/XXXXXXXXX/XXXXXXXXX/helloworld.py
^^^^^^^^^
この辺で違いが出る。
この性質上、後からタイトルや記法を変えると、パーマリンクも変わってしまう ので注意する。
ちなみにファイル名はタイトルから 適宜マスクされるため、タイトルと全く同じ文字列になるわけではない ことにも注意する。特に日本語名。
- 例: 記法は Markdown、タイトルが「こんにちはworld」とすると、
- ファイル名は「＿＿＿＿＿world.md」になる
- 日本語部分がマスクされている
検索時の挙動
検索結果には「メッセージ」タブと「ファイル」タブがあるが、「メッセージ」タブにはヒットしたメッセージそのものが表示される(のでわかりやすい)。一方、「ファイル」タブにはヒットしたファイルしか表示されない(そのファイル内のどこにヒットしたかまでは表示されない)。
本文がヒットしたとき
「ファイル」タブに検索結果が表示される。
タイトルがヒットしたとき
「メッセージ」タブに検索結果が表示される。
ちなみに検索でヒットさせられるタイトルは スニペットを新規作成したときのタイトルのみ である。あとでタイトルを変えても、変えた後のタイトルではヒットしない。
(提案) スニペットを多数投稿する運用で、各スニペットを検索しやすくしたい場合
これはただの提案なので興味無ければ読み飛ばすこと。
私は「タイトルに検索キーワードをあれこれひっつければ、後で探しやすくなる」と考えたが、上述のとおり、新規作成以後はタイトルを変えてもヒットしてくれない。なので現実的には スレッドとしてタイトルと検索キーワードを並べたメッセージを書いておく のが良いと思う。そうすれば検索時に「メッセージ」タブにヒットしてくれてわかりやすい。
AWS でリージョンあたりの VPC 数を上限緩和する
AWS では作成可能なサービスやらリソースやらに上限があるらしい。割と低めに設定されているらしい。でも必要に応じて緩和できる。今回 VPC 数を緩和したのでメモ。
現在の上限数を見る
- 管理コンソールにログイン
- サービス > EC2 > 左ペインのダッシュボードから「制限」
リージョンあたりの VPC 数の場合だと、下の方にある「ネットワーキングの制限」の「VPC」欄。
上限緩和を行う
AWS に申請を行う必要がある。
- 上記手順で制限ページを開く
- 「制限緩和のリクエスト」リンクがあるので、解除したい部分の横にあるそれにアクセス
すると AWS サポートダッシュボードのリクエスト画面が開かれるので、以下のように選んでいく。
- Service Limit increase を選択
- Limit type は VPC を選択
- リクエストとして以下を選択
- リージョンは東京
- Limit はリージョン当たりの VPC
- Case description はまあ適当に(日本語OK)
- 文言は業務ネタもろなので載せられないが……
- 以下あたりを書いた
- 「ユースケースとしてこれがあるよ」的な箇条書き
- 現状の制限数だとこれこれこういう理由でいっぱいいっぱいなんですわ、的な理由
- 特に「他のリージョンではなくこのリージョンでの上限を増やさないといけない理由」
- どこまでしっかり書かないといけないかはよくわからん
- Contact Options は適当に
- ここでは「日本語、Web」にした
- Web だと非同期にやり取りできて楽だと思う
- Phone だとどういうふうなやり取りになるかはよくわからん
一通り書いたら Submit ボタン。
するとチケットページが開かれる。以後はここでサポートスタッフとやりとりすることになる。
緩和が開始されるまで
今回のケースだと午前に申請して、午後ティータイムの前には既に解除されていた。迅速で素敵。
サポートスタッフ曰く「また何かあったらこのチケットを Reopen してね」と。メールよりも楽でいいですね。
感想
というわけであっさり出来たのであった。
SSH クライアント RLogin を nanno.dip.jp 以外から入手する
公式サイト nanno.dip.jp がダウンしているのか、入手できなかったので、代わりの入手先を探した。
結論
GitHub からダウンロードする。
Releases · kmiya-culti/RLogin より rlogin_x32.zip または rlogin_x64.zip をダウンロードすればよい。
GitHub について
http://nanno.dip.jp/ がアクセスできない場合などにご利用ください。
nanno.dip.jp が何かと脆いからということで準備されたものだと思われる。
