[Windows] AutoHotKey その2

職場の Windows PC に AutoHotKey というソフトを導入して、キーバインドを変更したら、ものすごくキー入力が楽になった。ホームポジションから手をはずさずに上下左右、行頭・行末にカーソルを移動させたり、文字を削除したりできる。ストレスフリー。

カーソル移動系がスムーズにできるようになったのはいいのだけれども、日本語キーボードを使いながらプログラムを書いていると、クオーテーションマーク ('シングルも"ダブルも) を打つ際に、ホームポジションから手が外れることが気になった。手が外れるということは、その瞬間に目線も画面から外れているので、その一瞬の無駄な作業が積み重なって時間が取られていたり、ストレスを感じていたりした。ということで、AutoHotKey を使って、解決。

; F13 + s で シングルクオーテーション
F13 & s::send, '

; F13 + l で ダブルクオーテーション
F13 & l::send, "

シングルの"s" と、できればダブルの "d" で行きたかったけれども、"F13+d" は文字削除に割り振っているので、代わりに "l"。F13を押しながら、左右の薬指で両クオーテーションマークが打てるようになった。

[本] 「最適化」をあらゆる場面で取り入れる

「最速の仕事術は人工知能が知っている (WirelessWire News)」で『最速の仕事術はプログラマーが知っている』という本の紹介があり、まさにその日 (9月22日) に Amazon で購入。

1章から2章くらいまでは「やり方」レベルの具体的な効率化の言及が多く、すぐにでも取り入れられるやり方がいくつも見つかった。よく考えずに慣例に従ってしまっていることが身近にあることを改めて思い知らされる...3章からは、もう少し抽象的なレベルでのお話。プレーヤーだったり、マネージャーだったり、経営者だったり、という視点での仕事の進め方について。例えば、「例外処理」を仕事を進めていく上でも作っておく、というのは、なんとなくやっていたことだけれども、名前をつけて指摘してもらえたので、明確に意識できるようになった。

プログラマーは徹底的に無駄を省く「最適化」を常に行っており、その最適化はプログラム内だけではなくて、作業・道具の使い方、プレーヤーとしての働き方、リーダーとしての働き方、経営者としての働き方、、、どのレベルにおいても適応可能である、それゆえに『最速の仕事術はプログラマーが知っている』ということなのだ。

一番最後の一文がカッコ良い:

本書で紹介してきた多くの思考法や、コラムで紹介したループの最適化や負荷分散、スケーラビリティの確保といった考え方は、プログラミング以外のあらゆる仕事に適用可能な、汎用性の高い「原理そのもの」なのである。(ibid.:219)

WirelessWire News でも言及がされているけれども、ぜひ2021年現在の最新の状況での「最適化」について、詳しく知りたいと思ったし、また、人工知能 (やディープラーニング等) について勉強したいと思った。

[本] 読書の秋、アウトプットの秋

強い日差しもひと段落して、過ごしやすい陽気になってきたので、この頃できていなかった読書とアウトプット活動を頑張ろうと決意。特にアウトプットは文字通り全然できていなあkったので、『アウトプット大全』を読むところからスタート。

著者の樺沢さんは、インプットの量もすごいし (例えば、月20冊の読書、月10本以上の映画、など[p.7])、アウトプットも凄すぎる (例えば、メルマガ、毎日発酵13年、YouTube、毎日更新5年、など [p.8])。そんな凄すぎる人がアウトプットの利点から、具体的な話し方、書き方、行動の仕方をわかりやすく教えてくれる、そんな本。

私は特に書くアウトプット(第3章)を続けていきたいと思っているので、書くことで脳幹網様体不活系(Reticular, Activating System) というカッコ良い名前の脳の部位が活性化して、記憶力や学習脳力が高まるとしれたことはなんだか嬉しい [pp.114f]。

また面白かったのは、ぼーっとする時間もアウトプットには大切であるという指摘。ぼーっとしているときには「デフォルトモード・ネットワーク」というカッコ良い状態が活発に稼働するとのこと。隙間時間をとにかく埋めてしまおうとするのではなく、空白の時間を作り出すことが脳味噌にとってすごく重要な意味を持つ [pp.142]]。

読書感想文のテンプレも紹介してもらえる。「ビフォー + 気付き + TO DO」[p.250] は書きやすそうなので、使っていきたい。

ふとしたときにパラパラめくり直してみるだけでも、毎回学びがありそう。

[本][英語] 推量の助動詞 will と must の対比

以前の記事では、推論用法の must「~にちがいない」とshould「~のはずだ」「きっと~だ」を取り上げた。日本語訳として表出する以前の意味の違いがあった。

今回は推論用法の will「~だろう」を取り上げて、must と対比的に理解をする。

柏野 (2012) によると、推論用法の mustは「現在入手できる情報」または「以前からの知識」に基づく推論であり、一方、willは「以前からの知識」に基づいた予測である。「以前からの知識」は「常識」「経験」などのことである。表にまとめてみよう：

助動詞	現在入手できる情報	以前からの知識
must	◯	◯
will	×	◯

柏野 (2012) の例を利用して具体的に説明しよう。must による推論は「現在入手できる情報」「以前からの知識」のどちらを根拠とできる。なので：

1. A: Someone's knocking at the door. (誰か、ドアをノックしている)

というAさんの発話に対して、

1. B: That must be Linda; only Linda knocks that way.
2. B: That must be Linda; she said she would come today.

のどちらの答え方もできる。前者は「ああいうノックの仕方はリンダしかいない」という「現在入手できる情報」を基にした推論であり、後者は「リンダは今日来るって言っていた」という「以前からの知識」を基にした推論である。一方で、willの場合は：

1. B: ^× That will be Linda; only Linda knocks that way.
2. B: That will be Linda; she said she would come today.

というように、「以前からの知識」に基づく予測しか許されない。

最後に、確信の強さについて柏野 (2012) から引用しておこう。

...一般にイギリス英語では must のほうが will よりも確実度が高く、アメリカ英語では will のほうが must よりも確実度が高い...

(ibid.: 38)

Forest は推量用法の willに対して「たぶん~だろう」という訳を当てているが、少なくともアメリカ英語であれば「たぶん」は不要と言える。

助動詞は調べれば調べるほど面白いし、わかるようなわからないような感じが募っていく..

• 柏野健次. (2012). 『英語語法詳解―英語語法学の確立へ向けて』. 三省堂

[本][英語] いい本は、爽やかに頑張ろうと思わせてくれる

小野和俊さんの『その仕事、全部やめてみよう』を拝読。

「あ、それでいいんだ」と気づかせてくれるというか励ましてくれるような面白いエピソードがたくさんあって (例えば「キレる」お話)、また、具体的なアドバイスもある。肩の力を抜いてリラックスさせてらもい、同時に、前向きに頑張ろうと思わせてくれる、そんな素敵な本だった。文章を読むだけでこんな爽やかな気分にしてもらえるのだから、実際に一緒にお仕事をされている方は羨ましい (とはいえ、実際の現場はシビアで高い能力が要求されるのだろうけど...)。

YouTubeの Ghelia Monthly (ギリアチャンネル) で小野さんを知り、すっかりファンになってしまった。

[本][英語] 推量を表す must と should (ought to)

今日も英語のお勉強。以前の記事に引き続き、助動詞。 今回は must と should (ought to)。

いわゆる推量の意味で、mustは「~にちがいない」、shouldは「~のはずだ」「きっと~だ」と訳す。日本語訳からもわかるように、must は should よりも確信が強い。Forest から例を引こう (p. 122f)：

1. She must be Bobby's sister. (彼女はボビーのお姉さんにちがいない。)
2. He should win the race. (彼はきっとレースに勝つはずだ。)

確信の度合い、という観点からから考えると、mustを使っている上の例文の方が、shouldを使っている下の例文よりも、確信度が高い。

ただ、実は、2つの助動詞の意味のちがいは確信の強さだけではないのだ。

must は「現在入手できる根拠に基づいた、現在の状況に関する確信」を表し、should は「判断の当否が将来において確かめられ得るような推測」を表す (今井 1995: 59)。

例を引用しよう：

3. You must be crazy!
4. ^×You should/ought to be crazy!
5. ^×John must be back by tomorrow morning.
6. John should be back by tomorrow morning.
(ibid.: 59, 一部改)

3の例文が示していることは、ある人がおかしな言動をしており (現在入手できる根拠)、そこから「あなたはcrazyにちがいない」と確信を持って判断している (現在の状況に関する確信) ということ。なので、must がふさわしくて、4のようにshouldは不適切になる。一方、5,6 の例文の方は、ジョンが明日の朝帰ってくるかどうかは、明日の朝に当否がわかる (判断の当否が将来において確かめられ得るような推測」。よって should が適切である。逆に must は不適切となる。

この考え方を踏まえて、冒頭の Forest からの引用を見直してみよう。はじめの文は、ボビーとそっくりの話し方・口癖・外見...などから確信を持って判断している (現在入手できる根拠) 、ということで must を使っているのだろう。一方、2番の文は、レースが終わってみれば彼が勝ったかどうかが判明 (判断の頭皮が将来において確かめられる) するので should がふさわしい、ということになる。

must と should (ought to) の使い分けは、(1)確信の度合いの強さ、(2)「現在の証拠で現在の確信」or「将来確認できる推量」、の2点となるわけだけれども、おそらく、より根本的な違いは(2)の点になるのだろう。というのは、「現在入手できる根拠に基づいた、現在の状況に関する確信」であれば、必然的に確信の度合いは高くなり、「判断の当否が将来において確かめられ得るような推測」であれば確信の度合いは下がる (未来のこと確信を持って推測することは難しい) からだ。

助動詞は日本語訳を機械的に当てはめて満足していたけれども、色々調べてみると面白い。

• 石黒昭博(2009).『総合英語 Forest』桐原書店
• 今井邦彦(1995).『英語の使い方』大修館書店

[Windows] AutoHotKey で キーバインディング

個人的にはずっとMacを利用しているのだけれども、その理由の一つが「矢印キーを押さなくてもカーソルを動かせる」という、すごく小さい理由。矢印キーは大体エンターキーの下あたりにあるけれども、カーソルを動かすために一度右手をホームポジションから離して、カーソルキーを押して、Jのぽっちを探してホームポジションを取り直し、、、という小さな繰り返しが煩わしく感じてしまうのだけれども、Macであれば、特に設定もせずに、Control(^)+f/b/n/p でカーソルを右/左/下/上、に動かすことができる。さらにいうと、Control(^)+a/eで、行頭/行末 に移動したり、Control(^)+kで、カーソルから行末までをカットしたり、、、など、ホームポジションから手を動かさずともさくさくカーソルを動かすことができる。標準で Windows ではそのような使い方はできない。だから Windows を使いたくなかった。

職場のPCがWindowsという縛りがあり、渋々矢印キーを押しながら仕事をしていたのだが、少し調べてみたらAutoHotKeyという素晴らしいソフトがあるとわかった。これは、色々な機能があるようだけれども、AutoHotKeyを使うことによって、任意の実際の入力がなされたときに、任意の別の入力がされたようにマップすることができてしまう。例えば、CapsLock を押しながらfを押すと、矢印右ボタンが押されたことにできてしまう。このソフトを利用することで、Windows であってもホームポジションから手を離さずに、Mac と同じようにカーソル移動(その他)ができてしまう。

カーソル移動以外にも色々できるので、備忘も兼ねてシェア。なお ChangeKeyというソフトを使ってCapsLockをF13キーとして割り振っている:

;Ctrl + q で閉じる
^q::send, !{F4}

;Ctrl + k で カタカナ (F7キー)
^k::send, {F7}

;Emacs風。なお、CapsLockをF13に割り振っている(ChgKey を利用している。Scan
Code --> 0x0064)
F13 & a::send,{Blind}{Home}
F13 & e::send,{Blind}{End}
F13 & p::send,{Blind}{Up}
F13 & b::send,{Blind}{Left}
F13 & n::send,{Blind}{Down}
F13 & f::send,{Blind}{Right}
F13 & d::Delete
F13 & h::Backspace
F13 & m::Send {Blind}{Enter}
F13 & k::send +{End}{Delete}
F13 & u::send +{Home}{Delete}
; Altキーは ! , Ctrlキーは ^
!f::send, ^{Right}   ;カーソルを1単語右
+!f::send, +^{Right}   ;選択肢ながらカーソルを1単語右
!b::send, ^{Left}   ;カーソルを1単語左
+!b::send, +^{Left}   ;選択肢ながらカーソルを1単語左

;F13 (Capslock) を押しながら ↑で音量Up、↓でDown
F13 & Up::
Send,{Volume_Up 1}
SoundPlay, x64
Return

F13 & Down::
Send,{Volume_Down 1}
SoundPlay, x64
Return

;今日の日付を入力 F13(CapsLock) + t
F13 & t::
FOrmatTime, TImeString,, yyyyMMdd
Send, %TimeString%
Return

[本][英語] 可能性を表すmayとcan の違い

英語のお勉強メモ。助動詞は難しいのだけれども調べていくと面白い。

助動詞の may も can も「~かもしれない」という可能性を表せる。Forestから例をひいてみる (p. 120f)：

• We may have some rain tomorrow.「明日はいくらか雨が降るかもしれません。」
• Anybody can make mistakes.「だれにだって間違いはありうる。」

さて、ここで問題にしたいのは may と can の差異である。「日本語訳」レベルでは全く同じになってしまうが、日本語に出てこない「意味」には違いがあるはずだ。今井 (1995) は次のように説明する (p. 61)：

「可能性をあらわす」という点で may と can は等しい。だが、mayが「現実的」可能性を表すのに対して、canは「一般的・理論的」可能性をあらわす、という点では異なる。

具体例を見てみよう：

• The area may be flooded after the typhoon.
  (台風の後なのでその地域はいま洪水になっているかもしれない)
• The area can be flooded after a typhoon.
  (その地域は台風の後洪水に見舞わられることがあり得る)
(ibid.:61, emphasis in the original, 一部改)

1つ目の例文は、実際に台風があり(the typhoon)その結果として現実に洪水になっているかもしれない、ことをあらわす。これが「現実的」可能性ということ。一方、2つ目の例文は、台風が起きた場合 (a typhoon) その地域は洪水になり得ると言っている (台風一般から期待される降水量よりも地域の排水量のが少ない、など)。

冒頭のForestの例に戻ろう。"We may have some rain tomorrow." では現実の話をしている事になる。一方、"Anybody can make mistakes." では、一般論として、人間という生き物は間違えうるものだ、と語っている。

日本語訳には出てこない違い、とても面白い。

• 石黒昭博(2009).『総合英語 Forest』桐原書店
• 今井邦彦(1995).『英語の使い方』大修館書店

[Python] 場合に応じて異なる関数を呼ぶ、をスッキリと

PySimpleGUI の Cookbook はとても勉強になるし、読んでいて楽しい。例えば、 "Recipe - Callback Function Simulation" の部分を読んでいて、なるほどなぁ、と思ったことがあった。

ある入力が受けて、その入力に応じた関数を呼ぶ、ということはよくある。イメージで言うと、変数event の値が "1" なら function1を、"2" なら function2を呼ぶ、と言うケース:

# 関数の定義
def function1():
	print("function1 is called")
def function2():
	print("function2 is called")

# なんらかの入力がある
event = "1"

# 場合分けで実行
if event == "1":
	function1()
elif event == "2":
	function2()

# event が "1" なので function1() が呼ばれる
# "function1 is called"

if とか elif とかで書いても問題なく動いてくれるのだけれども、もっとシンプルに書く方法が今回のお話。場合分けが多くなったりした時にもとても役に立つ。どうやるかというと、辞書(dictionary)を使う。入力と関数を辞書に入れておく:

# 関数の定義 (上と同じ)
def function1():
	print("function1 is called")
def function2():
	print("function2 is called")

# この辞書を作っておく
dispatch_dictionary = {"1":function1, "2":function2}

# なんらかの入力がある
event = "1"

# 場合分けで実行
if event in dispatch_dictionary:
	function_to_call = dispatch_dictionary[event]
	function_to_call()

# event が "1" なので function1() が呼ばれる
# "function1 is called"

function_to_call に function1 を一度入れておいて、それから () をつけてあげるとその関数を呼ぶことができる。

PySimpleGUIにはランチャーアプリを作って利用しているのだけれども、このやり方でコードがずいぶんスッキリしてくれた。

[Python] Ctrl + C (右クックからコピー) したものを取得する pyperclip

エクセルで保存した情報を簡単に処理して、その結果を社内のデータベースに転記する作業がある。そのデータベースのインターフェースはブラウザになっていて、恐ろしいことに(?)そのブラウザに表示される100~300くらいある(場合によってはもっとたくさんある)テキストボックス(inputで作られている)には、一括でエクセルのデータをコピペすることができないようになっている。なので、基本的には、100~300ある(場合によってはそれ以上の)テキストボックスには、エクセルの計算結果を一つずつコピペ、または、一つずつ手入力することが求められる設計となっている。

誰にとっても明白なように、一つずつコピペをしたり手入力するのは時間の浪費であるし、またミスの温床になりかねない。なので、ブラウザに入力するための別のエクセルを作成して、そこに一度計算結果をコピペして、そこからそのエクセルのVBAでブラウザに情報を渡すようにしている。

情報の処理・保存用のエクセル→→(コピーandペースト)→→ブラウザに情報を渡すVBAエクセル→→(VBA)→→ブラウザに入力完了

このVBAエクセルのおかげで作業はずいぶん楽になったのだけれども、やはりまだ辛い。結局、初めのエクセルから次のエクセルへコピペする作業は、文字通り「作業のための作業」であるからだ。ということで、少しでもこの作業を有意義なもの(?)にしようと考えて、少し調べてみたら、Python の pyperclip というライブラリーを使うとなんとかなりそうだと判明。pyperclip はコピーした文字列を取得できてしまう便利なライブラリ。新しいフローとしては:

情報の処理・保存用のエクセル→→(コピー and Python実行)→→ブラウザに入力完了

となり、少しだけ作業工程を減らすことができる。なお、"Python実行" のところでは pyperclip で情報を取得して、selenium で入力という流れ。

準備としては、まずはインストール。

pip install pyperclip

コピー(Ctrl+C、Cmd+C、右クリックからコピー)してクリップボードにある文字列を取得するには：

import pyperclip
pyperclip.paste()

でOK。例えば、エクセルで縦に1から4まで入力して、その範囲をコピーしてからpyperclip.pate()を使ってみる:

print(pyperclip.paste())
# 1
# 2
# 3
# 4

Windows なら改行は "\r\n" なので分割してリスト化もできる:

print(pyperclip.paste().split("\r\n"))
# ['1', '2', '3', '4', '']

最後の空が気になるので、シンプルに:

print(pyperclip.paste().split())
# ['1', '2', '3', '4']

のが簡単。

1列なら単に .split() でリスト化できるけれども、2列だと少し工夫(?)が必要。

エクセル上で1と5が横に並んでいるのは、"1\t5" というように、タブで区切られている。改行は上と同じ。なので、横に見て [[1,5],[2,6]...]というリストが欲しければ、まずは改行("\r\n")で区切り、それからタブ("\t")で区切ってあげれば良い:

print([i.split("\t") for i in pyperclip.paste().split("\r\n")])
# [['1', '5'], ['2', '6'], ['3', '7'], ['4', '8'], ['']]

やっぱり最後は空になってしまうので、if ではじいてあげる:

print([i.split("\t") for i in pyperclip.paste().split("\r\n") if len(i)>1])
# [['1', '5'], ['2', '6'], ['3', '7'], ['4', '8']]

pyperclipを使えば、一列のデータでも、2列(以上)のデータでも、コピーができるデータであれば簡単に取得して、リスト化ができると分かった。後は selenium に頑張ってもらってチクチク入力すれば完了。

[Coffee] Breville The Smart Grinder Pro でエスプレッソ

「巣篭もり」「おうち時間」の重要性が増しており、気軽にカフェにも行けないような今日この頃。ワクチンの普及によって社会的な状況は変わるかもしれないけれども、とは言え、おうちで美味しいコーヒーを飲めたらいいなぁと思い、ついに念願だった電動のコーヒーミルを購入。

Breville の The Smart Grinder Pro という製品。購入にあたり、検討したところは：

1. エスプレッソ用の細かさで挽ける [must]
2. ドリップ用の細かさでも挽ける [must]
3. ポルタフィルターに直接挽いた粉を入れられる [wish]
4. 価格が高すぎない [must]
5. 見た目がおしゃれに思える [wish]
6. お掃除がかんたん [wish]

というあたり。エスプレッソでもドリップでもどちらでも利用できて、価格がほどほどのもの (例えば10万円、とかは無理)が必須条件。可能であれば、ポルタフィルターに直接粉が落とせる (一度他の入れ物に入れてから、ポルタフィルターに移すのは大変)、関連して、お掃除がかんたんなのがよい (掃除が大変だと、そのうち面倒くさくて使わなくなる)。あとは、せっかく買うので、できればおしゃれ (に見える) ものが良いなぁ、とかんがえて色々調べてみて出てきたのが Breville。

挽く際の細かさは、写真の向かって右側の丸いところをカチカチ回すことで設定可能。エスプレッソの時は"15"、ドリップの時は"50"という数値が今のところのお気に入り。なお、この数値は前回の数値が保存されるので、一度コンセントを抜いてしまっても、次に同じ数値で挽くことができる。参考までに、"50"の細かさで挽いた粉がこんな感じ:

中深煎りとか深煎りの豆を買ってきておくと、手軽にエスプレッソにもできるし、ドリップコーヒーにもできる。今までは手挽きのミルを使っていて、手挽きのミルの良さを楽しんでいたのだけど、電動で手軽に挽けるのはまた別の良さがある。なお、注意点(?)として、コンセントがアースつき。

利用するコンセントの縦棒が2本( | | )だけの場合は、変換コード (例えば、アース有りプラグを、縦棒2本+アースターミナル用の電線 に変換してくれるもの) を利用する必要がある。

海外の製品だけど、今のところは東日本の普通の住居の電気 (100V, 50Hz) で利用できている。

手軽にエスプレッソもドリップも飲みたい方はおすすめです。