秀丸エディタマクロで IME オンオフを制御するための imestate imeswitch imeregisterword の挙動

秀丸エディタ上で「こんな時は IME をオフにしたい」的なことがしたかったので、一通り調べてみた。

状態取得: imestate

日本語入力中なら 1、そうでなければ 0 を返す。

例:

message ""+str(imestate);

状態変更: imeswitch

半角全角キーを一回押した時のような挙動。

つまり日本語入力モードと英文字入力モードをトグルで切り替える。

単語登録: imeregisterword

使用中の IME の単語登録ダイアログを出す。

上記を踏まえて

imeswitch はトグルなので、そのままでは 常に IME をオフにする、またはオンにすることができない。一工夫必要。

IME をオフにする

#IME_ON = 1;
#IME_OFF = 0;
if(imestate == #IME_ON){
    imeswitch;
}

オンだったら switch してオフにする。オフだったら何もしない。これで常にオフになる。

IME をオンにする

#IME_ON = 1;
#IME_OFF = 0;
if(imestate == #IME_OFF){
    imeswitch;
}

Golang で指定ファイルを関連付けで開く on Windows

たとえば hoge.ini というコマンドラインを与えると、Windows であれば「ini に関連付けられたテキストエディタ」で開いてくれる。しかし Golang の exec.Command() では開いてくれない。さあどうする？

ini ファイルを何で開くかを明示的に与える？

一般論として、お使いのエディタに ini ファイルパスを指定したコマンドラインを実行すれば良い。でも「お使いのエディタ」はどうやって取得する？まさか関連付けの仕組み(assoc コマンドやらレジストリやら)を愚直に辿らねばならないというのか……。

もっとスマートな解があった

調べてたら、ああ、なるほどと氷解。start コマンドでラップする のですね。

以下サンプル。

if doEditIni {
    err := exec.Command("cmd", "/c", "start", "", yourCommandLine).Start()
    if err != nil {
        fmt.Printf("Fail to read file '%v'", err)
    }
    success()
}

ただし start コマンドだけでは開けない(start コマンドは start.exe ではなく cmd.exe が持つ機能)ので、さらに cmd をかます必要がある。

参考: open-golang/exec_windows.go at master · skratchdot/open-golang

Golang で書き込むファイルの文字コードは LF 固定であるということ(CRLF はサポートしていない)

Python の時はちゃんと CRLF で書いてくれていたが、Golang だと LF 固定になる模様。Go 公式も「CRLF はサポートしない」と結論を出している。

試したコード

func list2file(filepath string, lines []string) {
    fp, err := os.Create(filepath)
    if err != nil {
        abort(err.Error())
    }
    defer fp.Close()

    writer := bufio.NewWriter(fp)
    for _, line := range lines {
        writer.WriteString(line + "\n")
    }
    writer.Flush()
}

CRLF をサポートしない、の根拠は？

Go の GitHub リポジトリ。

• os: output CR LF for \n on Windows · Issue #28822 · golang/go

上記 Issue で色々議論されいるが、mattn さんの発言がわかりやすい。

• issuecomment-439251733
  • クロスプラットフォームアプリつくってる時に CRLF のせいで苦労してる
  • Golang は移植性が強いのにもったいない
  • Win10 の notepad も LF 対応したよ
• issuecomment-441442408

んで、一番最後らへんに

We aren't going to do this, so closing.

と結論が出されて close されてる。

Golang で winapi を叩く練習として GetWindowText を呼び出してみた

最初は AllenDang/w32 を検討していたが、手元の Windows 7 で動かなかった＆ なんか fork してる別ソース使わないとダメ(or 自分でソース直す)っぽかった、で面倒だったので、一度自分で書いてみることに。

ソース

package main

import (
    "fmt"
    "syscall"
    "unsafe"
)

func main() {
    user32, err := syscall.LoadDLL("user32.dll")
    if err != nil {
        panic(err)
    }
    defer user32.Release()

    procGetForegroundWindow, err := user32.FindProc("GetForegroundWindow")
    if err != nil {
        panic(err)
    }
    hwnd, _, _ := procGetForegroundWindow.Call()

    procGetWindowTextLength, err := user32.FindProc("GetWindowTextLengthW")
    if err != nil {
        panic(err)
    }
    textLength, _, _ := procGetWindowTextLength.Call(hwnd)
    textLength = textLength + 1

    procGetWindowText, err := user32.FindProc("GetWindowTextW")
    if err != nil {
        panic(err)
    }
    // LPTSTR が *uint16
    buf := make([]uint16, textLength)
    procGetWindowText.Call(hwnd, uintptr(unsafe.Pointer(&buf[0])), textLength)

    text := syscall.UTF16ToString(buf)
    fmt.Println(text)
}

解説

Golang 側で winapi を叩く仕組みがあるので、これに従う。

• windows - GoDoc

基本的には syscall モジュールを使って DLL ロードして、そっから Proc をロードして、んで Call するという流れ。

• winapi の構造体や型の軍団が猛威を奮う
  • 自分で MSDN 見て書いてもいいが、 w32/typedef.go この辺を見るのが楽
• []int の string 化は syscall.UTF16ToString(buf)

感想

• winapi 側の型とか構造体とか作り込むのだるそう。w32/typedef.go まるごとパクろうかなぁ。ライセンスは BSD
• まずは小さなツール作成(で使う Proc のみを最小限定義)するのがよさそうか。少しずつ作って慣れる作戦
• あまり外部には頼りたくない……（w32 含めあまり栄えてない感じだし）

参考

• goでWindows APIを実行する覚書 - Qiita
• windows - GoDoc
• 参考にできそうなソース: github.com/AllenDang/w32/
  • GetWindowTextLengthW
  • w32/typedef.go

AWS CloudFormation の YAML テンプレートを書くためのノウハウ

最近はがっつり AWS の CloudFormation で Infrastructure As Code してた。だいぶ要領を得てきたと思うので、思いつく限りまとめてみる。

YAML で書く

JSON よりも YAML の方が人間に優しい。持論だが JSON と YAML は、HTML と Markdown くらいの差があると思っている。

エディタのパワーに頼る

コードハイライトやアウトラインなど、エディタの力は出来るだけ借りたい。Visual Studio Code 等が使える環境下なら何の問題もないが、そうじゃない場合は適宜設定を頑張る必要がある。これは頑張った方が良い。YAML は割とすぐに何百行となってしまうが、何の力も無いと辛い。

私は秀丸エディタ使いなので、以下その前提で書く。

コードハイライトする

テンプレートが長くなると Key: やら Key: Value といった行がずらりずらりになって見づらくなるので、見易くハイライトしてあげた方が良い。

• 単一行の Key-Value
• 複数行の Key-Value の Key
• 文字定数 "..."
• コメント # ...

Visual Studio Code 等が使える環境下なら何の問題もないが、そうじゃない場合はハイライト設定を頑張る必要がある。私は秀丸エディタ使いなので自分でハイライト設定をつくった。

設定ファイルは Gist にアップしてみた。

→ 秀丸エディタ YAML 強調定義ファイル

単語補完する

テンプレートをつくる時は !Ref やら !FindInMap やらで(ファイル中に書かれた名前を)指定することが多いので、ファイル内の単語補完が効いていると楽。

秀丸エディタなら以下。

• ファイルタイプ別の設定 > その他 > 単語補完
• 単語補完の自動表示
• 自動表示にチェック入れる、表示方法はリスト

アウトライン(シンボル)を認識させる

エディタによっては関数やクラス単位で目次を表示する機能があるが、これを Key-Value に対して適用できるとすこぶる便利。

リファレンスを読む

テンプレートの書き方はリファレンスが詳しい。

• AWS::EC2::Instance - AWS CloudFormation
• AWS::EC2::NetworkInterface - AWS CloudFormation
• AWS::EC2::Volume - AWS CloudFormation
• AWS::EC2::Route - AWS CloudFormation
• ...

というか how to ... やら ... not working やらでググってもあまり見つからないので、まずは熟読した方が良さそう。

GitHub でコード例を検索する

リファレンス見てもピンとこない場合は、実例を探す。GitHub が役立つ。

• Search · "VPC.DefaultSecurityGroup"

まあたまにポンコツコードにぶち上がって「んだよ動かねえじゃん」になるけど。

関連するリソースは近くにまとめて書く

たとえば AWS::EC2::Volume と AWS::EC2::VolumeAttachment とか、AWS::IAM::InstanceProfile と AWS::IAM::Role など、セットで使うリソースは固めて書いた方が見通しが良い。

関連するリソースをコメントで区切る

たとえば以下のように、関連リソースを区切るコメントがあると読みやすい。

  # ======== Instances ======== ★区切り

  # ここに AWS::EC2::Instance の定義がずらずら
  # ...

  # ======== IAM ======== ★区切り

  # ここに AWS::EC2::InstanceProfile やら AWS::IAM::Role やらの定義がずらずら
  # ...

  # ...

このようなコメントを嫌うエンジニアもいるかもしれないけど、テンプレート作成はプログラミングというよりは「リソース XXXX をつくるために XXXX の定義を書く」という感じで「XXXX の定義」単位で書く、探す、修正する、並び替えるゲーになるから、愚直にコメントを工夫して見通しを良くするのが楽だと思う。

わかりづらい定義や設定には適宜コメントを書く

「なんでこんな書き方してるの？」とならないように、読み取れない部分には適宜コメントを入れておく。

例:

• EBS に DependsOn を付けてアタッチ順をコントロールしているのはなぜか？
• EBS のデバイス名の命名規則はなぜこのようにしているのか？

Name タグはちゃんと設定する

しばしば管理コンソール上にいろんなリソースが散らばっていて「テンプレートでつくったのどれだ」となっちゃうので、一意に検索できるよう Name タグを入れておく。

私は以下のように「Name タグの Suffix を毎回指定させる」「そしたら projA-vpc-(Suffix) みたいな Name タグがつく」方式にした。

Parameters:
  NameTagSuffix:
    Description: Name tag suffix.
    Default: xxxxx
    Type: String

Resources:
  VPC1:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      InstanceTenancy: default
      Tags:
      - Key: Name
        Value: !Join [ "-", ["projA", "vpc", "Ref":"NameTagSuffix"] ]

たとえば Suffix を stakirantest にすれば、検索時も stakirantest とか stak とかで絞り込める。

AWSCLI でローカルでテンプレート検証できるようにする

書いたテンプレートの検証は、管理コンソールのデザイナーからも行えるが、いちいちコピペするのがだるい。ローカルでコマンド叩いてできた方が楽。

→ AWS CloudFormation テンプレートの検証をローカルで行えるようにした(AWSCLI使用) - stamemo

バージョン管理する

Infrastructure As Code の恩恵はバージョン管理してこそ。

GitHub や GitLab に入れて管理する。きりのいいところでタグ付けてリリースする。課題は Issue で管理する。

CloudFormation で自動化に取り組む際はちゃんと時間を取る

間違っても「普段忙しいのに加えて」この自動化も頑張る、みたいなことはしちゃいけない。以下のように、やることは意外と多いので、ちゃんとしたテンプレートをつくるのは意外と時間がかかる。

• YAML の書き方を把握する(手を動かしながら)
• 自動化したい環境を、どうやってコードで表現するかの考える(管理コンソールでこうなってるのをテンプレートで書くと？の答え探し)
• 書いたテンプレートが動くかを流して確認(上記規模だと作成も削除も数分くらいかかる)
• 環境組んだ後の 各サーバーの設定(ログインしてあれこれ)とその後の動作確認
  • ここは手作業
  • ここが本質的に時間かかるならテンプレートの動作確認も結局時間かかる
• ……

私が取り組んだのは 1-vpc、4-subnet、3-route-table、5-server、6-ebs くらいの規模のテンプレートだったが、これでも丸々一週間近くかかってる。

AWS CloudFormation テンプレートの検証をローカルで行えるようにした(AWSCLI使用)

Win7 x86 で AWSCLI を用いて CloudFormation テンプレート検証をローカルで行えるようにした。

Thanks! awscli(Python版)でCloudFormationテンプレートをValidateする ｜ DevelopersIO

1 結論

cat template.yaml | xargs -0 aws cloudformation validate-template --template-body --no-verify-ssl

感想:

• 管理コンソールのデザイナーからいちいちコピペするよりも何十倍も快適
• コマンド叩いて数秒くらいで結果返ってくる。良き

2 上記コマンドラインを動作させるのに

AWS CLI:

• pip install awscli

各種 AWS 関連環境変数:

• 環境変数 - AWS Command Line Interface を参考に
• AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION など
  • AWS_DEFAULT_REGION は ap-northeast-1(東京リージョン)
  • アクセスキー等は IAM ユーザーからゲットする

Git for Windows:

• cat, xargs などはこいつに同梱されているのがてっとり早い
• Cygwin やら MinGW などでも良い

プロキシ:

• 社内環境などで通信が通らない場合は適宜設定する
• HTTPS_PROXY と HTTP_PROXY

SSL 証明書(--no-verify-ssl で無視したくない人向け):

• AWS_CA_BUNDLE 環境変数に crt ファイルのパスを指定する等
• AWSCLI の証明書サーチアルゴリズムは AWS CLI 1.9.0がリリースされました ｜ DevelopersIO あたりにまとまってる
• (余談) Firefox に組み込んでる証明書取り出そうとしたけど無理だった
  • %appdata%\Mozilla\Firefox\Profiles\XXXXXXXX.YYYYYYYY\cert9.db
  • db ファイルって何？crt ファイルが欲しかったのよー……

Outlook 2016 で現在のビューをすべてのフォルダーに適用(反映)する

最後の再起動が地味に罠だった。Outlook 2013 の時は普通に反映されてたのに。

手順

• 1: 適当なフォルダを開く
• 2: 表示 > ビューの設定 を開く

列ボタンから不要な列を弾く。

グループ化ボタンからグループ化(今日とか三週間前とかでグループ化されるやつ)を解く。「並び替え方法に従って……」のチェックを外せば良い。

その他のビュー設定も必要なら行って。

• 3: 表示 > ビューの変更 > 現在のビューを新しいビューとして保存

MyView など適当な名前をつけて保存。

これを選択した後、

• 4: 表示 > ビューの変更 > 現在のビューを他のメールフォルダーに適用する

適用先フォルダーを選ぶダイアログが出るので、すべてのフォルダーにチェックを入れる。

• 5: 再起動する

再起動でハマった

5: の再起動をしないと反映されないことがある。私は 30 分無駄にした。

Outlook 2016 で F1 キーを押して既読するようにする

デフォでは閲覧した後に勝手に既読になるが、これだと使いづらい。既読は自分のタイミングで行いたい。そこで F1 キーで既読させてみる。

Outlook 側の設定と AutoHotkey が必要。

1: Outlook 側の設定

オプション > 詳細設定 > outlook ウィンドウ > 閲覧ウィンドウ > 閲覧ウィンドウでの表示が終わったら開封済にする を外す。

2: AutoHotkey の設定

Outlook デフォでは Ctrl + Q キーで既読操作になるが、これは押しづらいので、F1 キーで押せるようにする。

#IfWinActive ahk_class rctrl_renwnd32
F1::Send,^q
#IfWinActive

テキストファイルをコンビニで印刷するために markdown to pdf する

自宅で印刷する必要性に駆られたのだが、コンビニだと Office や PDF 形式しか対応してない。Office は持ってないので PDF しかない……というわけで、テキストファイル(Markdown)から PDF をつくる方法を調べた。

結論

以下の二段階にした。

• markdown to html は Pandoc で行う
• html to pdf は Prince で行う

前提

• Windows 10 x64

markdown to html

Pandoc を導入し、以下コマンドラインで可能。

$ pandoc text.md -o text.html

html to pdf

まずは Prince をインストールする。非商用なら無料で使えます。

次に以下 CSS ファイルをつくる。

@font-face {
    font-family: serif;
    src: url("C:/WINDOWS/Fonts/MSMINCHO.TTC");
}

@font-face {
    font-family: sans-serif;
    src: url("C:/WINDOWS/Fonts/MSGOTHIC.TTC");
}

そして Prince を起動し、

• CSS & JavaScript の CSS 欄に上記 CSS ファイルを読み込む
• Add files から text.html を読み込む
• CONVERT ボタンで変換する

これで text.pdf が生成されるはず。

Q&A

Q: CSS ファイルを指定するのはなぜ？

何も指定しないと日本語フォントが効かずに PDF が文字化けするから。

参考: Trouble-Free Travel/TechWiki

Q: コンビニでの印刷はどうやっている？

USB メモリに PDF ファイルを入れて、コンビニのプリント機で。

Q: なぜ Pandoc で PDF 変換まで完結させない？

ちょっと試したけど動かなかったから。

以前は LaTex をインストールしてたから多分動いてたんだけど、ある時「これ容量食うしもういいや」と削除した。だからなのだろう、PDF エンジンが無くて Pandoc の PDF 変換が動かなかった。他のエンジンということで、pdfroff http://gnuwin32.sourceforge.net/packages/groff.htm も試してみたけど、これも動かず(たぶん groff と pdfroff は別物)。

……と困惑してきたので、いったんやめて、別手段探してたら Prince でいけそうだったのでそうした。

Markdown をプレビューできる mkup を Win 7 で試した

Markdown プレビュー手段として mattn さんの mkup が便利そうだったので試したら、ちょっと詰まったのでまとめとく。

前提

• Windows 7 32bit

導入まで

そのまま go get するとエラーが出る。

$ go get github.com/mattn/mkup
package gopkg.in/fsnotify.v1: unrecognized import path "gopkg.in/fsnotify.v1" (https fetch: Get https://gopkg.in/fsnotify.v1?go-get=1: proxyconnect tcp: EOF)

どうも mkup が import してる "gopkg.in/fsnotify.v1" というパスが古いみたい。

fsnotify.v1 - gopkg.in/fsnotify/fsnotify.v1 とか gopkg.in/fsnotify.v1: unrecognized import path · Issue #1323 · revel/revel を見て、正しくは github.com/fsnotify/fsnotify の模様。

というわけで mkup のソースを直接直す。

$ pushd %gopath%\src\github.com\mattn\mkup\main.go

$ hide main.go
エディタは何でもいいので

import (
    ...
    "github.com/fsnotify/fsnotify"
    ...

↑ こうする

ビルド。コマンドラインってこれで良いんだろうか。

$ go build -o mkup.exe

試す。

$ mkup
Listening at :8000

動いた。試しに README.md を修正してみると、動的に反映された。

最後に mkup.exe を %gopath%\bin に移して(行儀良くないだろうけど)完了。どこからでも mkup 使えるようになった。

Win10 だとエラー出ません

しかし Win10 x64 環境だとエラーが出ず、 go get github.com/mattn/mkup だけで使えるようになった。

……どういうことだろう。この手の unrecognized import path エラー、割と遭遇するのでちゃんと調べたいところ。なんとなく Win7 x86 という古い環境のせいな気はしているが、いまいち情報はヒットせず。

【第二版】ファイアウォールやネットワークにおける上り、下り、イングレス(Ingress)、エグレス(Egress)、インバウンド(Inbound)、アウトバウンド(Outbound)の違い

一年以上前に以下記事を書いたが、

• ファイアウォールやネットワークにおける上り、下り、イングレス(Ingress)、エグレス(Egress)、インバウンド(Inbound)、アウトバウンド(Outbound)の違い

上手く整理できておらず誤りもあったので、改めて整理した。

まとめ

• ingress = inbound = 受信 = Download = 下り
• egress = outbound = 送信 = Upload = 上り
• 英語で言えば ingress/egress は名詞で、inbound/outbound は形容詞
• ただし一部では意味が逆になるケースがある
  • 例: GCP ファイアウォールルールの「暗黙の下り許可ルール
  • 下りなので受信時のフィルタリングを想像するが、実際は送信時のフィルタリングを指している

したがって上記の言葉が出現した時は、同義語であるどれか(自分にとって直感的に理解しやすいもの)で置き換えれば読みやすい。たとえば inbound、ingress という言葉を見たら「あ、受信方向なんだな」と解釈すればいい。

ただし、どの用語を使うかはサービスや界隈次第で変わってくる＆用語として定められていることがある。たとえばファイルウォールの文脈では「ダウンロードフィルタリング」などとは言わないし、AWS のセキュリティグループでも Ingress/Egress などとは言わない(言っても通じるとは思うが)。

以下ソース

VPC のセキュリティグループ - Amazon Virtual Private Cloud

• 引用

  • Inbound …… 同じセキュリティグループに割り当てられたインスタンスからのインバウンドトラフィックを許可する

  • Outbound …… すべての発信 IPv4 トラフィックを許可する

• まとめ
  • インバウンド(アウトバウンド)とは「インバウンド(アウトバウンド)トラフィック」のこと
  • インバウンド = 外から中に入ってくる方向 = 受信
  • アウトバウンド = 中から外に出ていく方向 = 送信

ファイアウォール ルールの概要  |  VPC  |  Google Cloud

• 引用

  • 双方向ではなく、受信（ingress）トラフィックまたは送信（egress）トラフィックに適用されます。

  • 暗黙の下り許可ルール: アクションが allow、宛先が 0.0.0.0/0、優先度が可能な限り低い（65535）egress ルールでは、GCP によってブロックされたトラフィックを除き、すべてのインスタンスが任意の宛先にトラフィックを送信できます。

  • 暗黙の上り拒否ルール: アクションが deny、送信元が 0.0.0.0/0、優先度が可能な限り低い（65535）ingress ルールでは、受信トラフィックをブロックすることによって、すべてのインスタンスが保護されます。

• まとめ
  • ingress(egress) とは「ingress(egress) トラフィック」のこと
  • ingress は受信
  • egress は送信
  • 下りとは中(インスタンス)から外に出ていく方向
  • 上りとは外から中(インスタンス)に入ってくる方向

ingress とegress の考え方 | NetFlow Analyzer ナレッジベース

• 引用

  • (1)ingress 装置へ入力するタイミングで帯域情報計測

  • (2)egress 装置から出力するタイミングで帯域情報計測

• まとめ
  • ingress は外から中(装置)に入ってくる方向
  • egress は中(装置)から外に出ていく方向

［用語集］通信速度で使われる「上り」「下り」はどのような通信を表しますか。 | よくあるご質問（FAQ） | サポート | ソフトバンク

• 引用

  • 「上り」 パソコンや携帯電話からインターネット上へファイルを転送する際の通信

  • 「下り」 インターネット上からファイルをパソコンや携帯電話に受け取る際の通信。

• まとめ
  • 上りは送信(Upload)
  • 下りは受信(Download)

英和辞典

• ソースと引用
  • ingressの意味・使い方｜英辞郎 on the WEB：アルク

    • 入ること

  • egressの意味・使い方｜英辞郎 on the WEB：アルク

    • 退出

  • inboundの意味・使い方｜英辞郎 on the WEB：アルク

    • [形] 入ってくる

  • outboundの意味・使い方｜英辞郎 on the WEB：アルク

    • [形] 外国行きの

• まとめ
  • ingress と egress は名詞
  • inbound と outbound は形容詞
  • ingress/inbound は「入る」
  • egress/outbound は「出る」

Windows で cal コマンドを使ってカレンダー一覧を作る

テキストのカレンダー一覧が欲しかったのでつくることにした。Windows には cal コマンドがないので何とかして入手し、これを何度も呼び出すようなバッチファイルを書くことで実現。

前提

• Windows7 32bit

1: Gcal の入手

cal コマンドの代替として GnuWin32 の Gcal を使う。

• Download GnuWin from SourceForge.net

上記はタイトルが「GnuWin」となっているが、ダウンロードするのは Gcal に必要な部分のみである。ちなみにインストーラーなので普通に実行してインストールする。

(参考) インストール後のファイル構成

Gcal に必要なファイルのみが整っている。

$ dir /b "C:\Program Files\GnuWin32\bin"
gcal-daily
gcal-daily.orig
gcal-ddiff
gcal-ddiff.orig
gcal-ddiffdrv
gcal-ddiffdrv.orig
gcal-dst
gcal-dst.orig
gcal-gcalltx
gcal-gcalltx.orig
gcal-gcalltx.pl
gcal-gcalltx.pl.orig
gcal-moon
gcal-moon.orig
gcal-mrms
gcal-mrms.orig
gcal-srss
gcal-srss.orig
gcal-wlocdrv
gcal-wlocdrv.orig
gcal.exe
gcal2txt.exe
libiconv2.dll
libintl3.dll
rxspencer.dll
tcal.exe
txt2gcal.exe

2: Gcal を試しに実行してみる

年と月を指定してみた。

$ "C:\Program Files\GnuWin32\bin\gcal.exe" 01 2019

     January 2019
 Su Mo Tu We Th Fr Sa
        1  2  3  4  5
  6  7  8  9 10 11 12
 13 14 15 16 17 18 19
 20 21 22 23 24 25 26
 27 28 29 30 31

年だけ指定してみた（このオプションは続く一覧作成時に使う）。

$ "C:\Program Files\GnuWin32\bin\gcal.exe" 2004


                                  2004


      January                   February                   March
 Su Mo Tu We Th Fr Sa      Su Mo Tu We Th Fr Sa      Su Mo Tu We Th Fr Sa
              1  2  3       1  2  3  4  5  6  7          1  2  3  4  5  6
  4  5  6  7  8  9 10       8  9 10 11 12 13 14       7  8  9 10 11 12 13
 11 12 13 14 15 16 17      15 16 17 18 19 20 21      14 15 16 17 18 19 20
 18 19 20 21 22 23 24      22 23 24 25 26 27 28      21 22 23 24 25 26 27
 25 26 27 28 29 30 31      29                        28 29 30 31



       April                      May                       June
 Su Mo Tu We Th Fr Sa      Su Mo Tu We Th Fr Sa      Su Mo Tu We Th Fr Sa
              1  2  3                         1             1  2  3  4  5
  4  5  6  7  8  9 10       2  3  4  5  6  7  8       6  7  8  9 10 11 12
 11 12 13 14 15 16 17       9 10 11 12 13 14 15      13 14 15 16 17 18 19
 18 19 20 21 22 23 24      16 17 18 19 20 21 22      20 21 22 23 24 25 26
 25 26 27 28 29 30         23 24 25 26 27 28 29      27 28 29 30
                           30 31


        July                     August                  September
 Su Mo Tu We Th Fr Sa      Su Mo Tu We Th Fr Sa      Su Mo Tu We Th Fr Sa
              1  2  3       1  2  3  4  5  6  7                1  2  3  4
  4  5  6  7  8  9 10       8  9 10 11 12 13 14       5  6  7  8  9 10 11
 11 12 13 14 15 16 17      15 16 17 18 19 20 21      12 13 14 15 16 17 18
 18 19 20 21 22 23 24      22 23 24 25 26 27 28      19 20 21 22 23 24 25
 25 26 27 28 29 30 31      29 30 31                  26 27 28 29 30



      October                   November                  December
 Su Mo Tu We Th Fr Sa      Su Mo Tu We Th Fr Sa      Su Mo Tu We Th Fr Sa
                 1  2          1  2  3  4  5  6                1  2  3  4
  3  4  5  6  7  8  9       7  8  9 10 11 12 13       5  6  7  8  9 10 11
 10 11 12 13 14 15 16      14 15 16 17 18 19 20      12 13 14 15 16 17 18
 17 18 19 20 21 22 23      21 22 23 24 25 26 27      19 20 21 22 23 24 25
 24 25 26 27 28 29 30      28 29 30                  26 27 28 29 30 31
 31

3: カレンダー一覧をつくる

Gcal が動くことがわかったので、カレンダー一覧をつくる。

まともにコマンドラインオプションを読み解くと骨が折れる ので手抜きすることに。前記にて、年数だけ与えると「その年の月表示を 3 列 4 行で並べて表示する」ことことがわかっているので、この出力を並べることにした。バッチファイルを使う。

output.bat

@echo off
setlocal
set calcmd="C:\Program Files\GnuWin32\bin\gcal.exe"
set calstart=1970
set calend=2100

set name_merged=all_%calstart%_%calend%.txt

echo.> %name_merged%
for /L %%i in (%calstart%,1,%calend%) do (
    echo %%i...
    %calcmd% %%i > %%i.txt
    type %%i.txt >> %name_merged%
)

これを実行すると、以下のようにファイルがつくられる。

$ dir /b
...
2019/06/27  19:12             2,428 1970.txt
2019/06/27  19:12             2,428 1971.txt
...
2019/06/27  19:12             2,428 2100.txt
2019/06/27  19:12           318,070 all_1970_2100.txt
2019/06/27  19:12               299 output.bat

all_1970_2100.txt は 1970.txt、1971.txt、……の内容を一ファイルでずらりと並んだもの。

とりあえず最低限カレンダー一覧をゲットできたので良しとする。

(余談1) cal コマンドで Gcal を呼び出せるようにする

以下のバッチファイルを PATH の通ったフォルダに置く。

cal.bat

@echo off
"C:\Program Files\GnuWin32\bin\gcal.exe" %*

(余談2) カレンダーのスペル

• calendar
• calender

突然ですが正しいのはどっちでしょう。

……前者、calendar が正解です。dar なんですね（最近まで普通に間違ってた）。

(余談3) カレンダーへのアクセス

今回つくったカレンダーにどうやってアクセスするか。私は以下のようにした。

• github\stakiran\text\calendar に 1970.txt, 1971, ... 2100.txt を配置
• 愛用している fenrir を再スキャン

これで fenrir から 2019 と打つだけで 2019 年のカレンダーにアクセスできる。fenrir は AutoHotkey にて Alt + 1 で起動できるようにしているので、実際は Alt + 1 → 2019 の二段階でアクセス可。かなり素早くカレンダーを開けるようになった。

Q: 「普通に余談 1 を整備してからコマンドプロンプトで cal 2019 と叩けばいいのでは？」

ダメ。コマンドプロンプト上の表示は見づらい。愛用のテキストエディタで見れることが重要なのである。

参考

• Mac のターミナル上でカレンダーが見られる「cal」コマンドを Windows でも実現する方法 - Corredor
• cal command in Linux with Examples - GeeksforGeeks
• GnuWin32 - Wikipedia
• GnuWin download | SourceForge.net
• Windows で GNU Tools を使う。 GnuWin32 | みむらの手記手帳

メモリ 4 GB の Windows で頑張るマン

大人の事情でメモリ 4GB の Windows で頑張らないといけない人向けに、「こうすれば Windows が軽くなるよ」「こんな工夫をしたら上手いことやりくりできるよ」といったテクニックを雑多にまとめる。

前提は Windows7 32bit だが、他の Windows でも一部は通用すると思う。

コントロールパネル

ひととおり目を通して、要らないものは無効にする。

特に以下。

• Windows Update（頻度を落とすなど）
• コンピューターの簡単操作センター
• システム > システムの詳細設定 > 詳細設定 > パフォーマンスの設定 > 視覚効果 > パフォーマンスを優先する
• 電源オプション（省エネしない方向に倒す）
• プログラムと機能（一通り目を通して要らないプログラムはアンインストール）

サービス

services.msc の「開始」「自動」になっているサービスに注目、一通り見て要らないものは停止/無効にする。

いくつか例を挙げる。

• IP Helper（ipv6 使ってないから要らない）
• Windows Defender（既に他のセキュリティソフトがあるので要らない）
• Windows Search（たまに最適化処理が走って重くて邪魔だし検索はあまり使ってないので要らない）
• Tabret PC Input Service（タブレット使わないので要らない）

私もあまり詳しくない。詳細はサービス名をググって調べて勉強する。

タスクスケジューラ

これも一通り目を通して、要らないものは無効に。

• タスクスケジューラライブラリ(AdobeやGoogleの設定がある)
• タスクスケジューラライブラリ\Microsoft\Windows 配下
  • フィードバック送信系の Autochk, Application Experience, Customer Experience Improvement Program, DiskDiagnostic など

これもサービスと同じく、よくわからないものはググって調べる。

HDD の音がうるさい → 何かが悪さしてるので対処する

HDD のファン音や書き込み音がうるさい＝何か活発に動いているプロセスがある、のでそいつを突き詰めて対処（たいていは停止して無効化する流れになる）する。

確認には Process Explorer を使う。CPU観点(CPU列)、メモリ観点(Private Bytes列)、I/O観点(Disk Writes列)などで降順ソートして、たくさん消費しているプロセスを探す。

見つけたら詳細を開いて、プロセス名やコマンドラインをメモ。ググって詳細を調べる。たいてい「このプロセスはどういう役割があるの？」「無効化してもいいの？」「無効化手段は？」的な情報にヒットする。

この対処の過程でサービスやタスクスケジューラを触ることも多い。

ブラウザ

ここでは Firefox を想定する。

• 可能なら古いバージョン（最近のブラウザはメモリをやたら食う）を使う
  • Quantum 以前（しかしセキュリティ的に問題があるので非推奨）
• タブは 5 個以内で抑えたい。不要なものはすぐ閉じる。
• アドオンは最小限に
  • 本当に必要なものだけ厳選する。10個以内、できれば5個以内に抑えたい
• ページは開きっぱなしではなく、必要な時に都度開くようにする(アドレスバーを使えば履歴やブクマから探しやすい)
• about:memory ページの GC ボタンはこまめに押す

セキュリティソフト

なるべく無効にする方向に倒す。

対象:

• スキャンのスケジュール
• アップデートのスケジュール
• リアルタイム監視系
• 例外設定系

対処:

• 実行頻度は毎日→週一くらいにする
• 実行時間帯は昼休憩や深夜など触ってない時間帯にする（特に深夜の場合は PC つけっぱなしが許される環境でないとダメだが）
• リアルタイム系はオフにしてしまうのが望ましい
• オフにできないなら例外設定から「よく Read/Write するフォルダ」を弾く

組織のルールによっては設定 NG なこともあるので事前に確認しておくこと。

おそらく良くて「業務に支障があるなら適宜設定を緩めてもいいが自己責任で」的な結論になっている。これに対して「そりゃ怖い。じゃあ今のままでいいや」とビクビクしないこと。必要以上のビクビクは「事故起きるから車使うのやめよ」レベルの無知。リテラシーがあるなら「これくらいまでなら緩めてもまあ大丈夫かな」という塩梅がわかるはず。

メール、チャット、インスタントメッセンジャー

• 非同期チェックにする
  • 例：1日3回、決まったタイミングで見る（見る時に起動して見終わったら終了する）
• 使っていない手段は封じる
  • 例：滅多に使ってないインスタントメッセンジャーは「使ってません。メール or チャットで」とメッセージ欄に残しておいて普段は起動しない
• 使っていないメールは削除する
  • Outlook を例にすると……
    • 削除後は圧縮操作も必要
    • pst ファイルは数百MB以下に抑えたい
• チャットクライアントは最も軽い組み合わせを模索した方が良いかも
  • ブラウザでログインするのが良いのか、デスクトップクライアントを使うのが良いのか……
  • ブラウザの場合、Firefox がいいのか Chrome がいいのか……
  • はたまた Franz のような多環境オールインワンタイプのクライアントがいいのか……

アプリ系

使ってないアプリは最小化する or 終了する

• 行儀いいアプリなら最小化したらメモリ量が減る（使い始めたらまた増えるけど）
• 最小化でも追いつかないなら終了して、必要な時だけ使うようにする

おすすめは「仕事セット（この仕事の時はこのアプリとこのアプリを使う、という組み合わせ）」を洗い出した上で、仕事セット以外のアプリを全部終了すること。もちろん、何度も仕事セットを切り替えるのはだるいので、「今日は仕事セットAだけやる」「明日は午前にB、午後にCにしよう」のようにある程度のスパンで集中的に使えるように仕事をコントロールする必要がある。

EXCEL/WORD/POWERPOINT/PDF はなるべく使わない

Microsoft Office 系のファイルは総じて重たいなので、なるべく関わらない。

自分が使う場合は、テキストエディタ + テキストファイルで済むようにする。もし「なんだ手抜きは」という輩がいたら、内向きの見栄えにどれほどの価値があるのか等、本質を突いてバトっても良いレベル。

Virtualbox や IDE を使う必要があるような仕事には近づかない

4GB で仮想マシンや IDE を使うこと自体に無理があるので、そういう仕事には近づかない。

ちなみに Visual Studio Code で HTML/CSS/Javascript(ES5) を開発する場合、何の拡張も使わないなら（他のテクニックを駆使すれば）かろうじて可能。

おわりに

以上、他にもあるかもしれないが、ぱっと思いつくものを書き殴ってみた。4GB はキツイぜ……。

括弧のタッチタイピングができないので AutoHotkey で `a[[` で括弧 `()` を入力してカーソルを真ん中に持っていく Hotstring をつくった

括弧らへん（右上段 8,9 あたり）のタッチタイピングが全然身についてくれないので、AutoHotkey の Hotstring でカバーしてみることにした。

AutoHotkey コード

#Hotstring ? ;単語途中でも発動させる

::a[[::
  Clipboard = ()
  Send,^v
  SendInput {Left}
return

#Hotstring ?0

解説

Clipboard について

Hotstring で文字列を貼り付ける方法には二種類がある。Send でキー単位で送るのと、Clipboard で全部コピーしてから Ctrl + V を送るのと。前者は IME 状態に左右されるのがデメリット、後者はクリップボード内容が消えちゃうのがデメリット。……今回は IME に左右されず常に半角括弧を入れたかったのでクリップボードにした。

SendInput {Left} について

これは () 挿入後にカーソルをこの括弧の中に移動させる命令。Left キーを一回分送っているだけ。

#Hotstring ? について

これは Hotstring を単語途中でも発動させるためのオプション。これを有効にすると uaaaa[[ と打った時に uaaa() となる。uaaa…… と単語入力の途中で一致しているのに発動している（普通は誤発動防止のため発動しない）。

ただし、この言わば「誤発動防止を無効するオプション」をずっと無効化しておくと（この記述より先の HotString でも全部無効になっちゃってしまい）望ましくないので、#Hotstring ?0 で元に戻している。

感想

かなり便利。括弧 () は地味に多用するが、いままで 2 回に 1 回は間違っていた。これがほぼミスらなくなり、また手元を見たりすることもなくなった。

AutoHotkey は素晴らしい。

もう年だからか、タッチタイピングみたいな手続き記憶的なことがなかなか身についてくれないので、こういう機転は今後ますます大事になってくるかもしれない。