2019-05-09

とある大手 SIer で苦悩しているエンジニアの持論まとめ

企業・会社・働き方ポエム

ただのメモ。「私の持論や志向はこんな感じですねん」を素早く展開する用。

2019-05-07

秀丸エディタの本を書いた

秀丸エディタつくった

「今さら秀丸エディタ？」と思われるかもしれないが、日本語の文章を執筆する上では秀丸エディタは有力な選択肢になると私は信じている。この度、既にエディタを使って執筆している方を対象とした秀丸エディタ本を出版したので、簡単に紹介しておく。

書いた本
どんな本？
対象読者
部と章の解説

書いた本

執筆を効率化したい人のための秀丸エディタ実践入門 - Kindleストア

f:id:stakiran:20190507072518j:plain

どんな本？

本書には「執筆の効率化」「秀丸エディタ」という二つの軸がある。

執筆の効率とは、執筆（テキストエディタで文章を書くこと）の効率を指す。効率というとピンと来ないかもしれないが、エディタの機能や設定、テキストファイルの扱い方や変換など、執筆においては 知っているかどうか・身に付けているかどうかで効率に何倍・何十倍と違いが出る ことがある。本書では、このあまり意識されない「執筆の効率」について、意識的に焦点を当て、読者が自ら執筆の効率を高められるようになることを目指す。

また本書は秀丸エディタ本なので、秀丸エディタに関する解説が大半を占める。本書では基本的な機能に限らず、設定や操作方法の仕組みやコンセプトといった話題にも言及している。レシピのような即効性は無いが、実践に役立つ知識が身に付くものと期待している。また、秀丸エディタを知らない、あるいは興味があるユーザーが、秀丸エディタがどんなものであるかを手早く知るのにも役立つだろう。

対象読者

既にエディタを使って執筆しているが、エンジニアやプログラマーほど高度ではない方 を対象としている。

本書には「インストールって何？」というような初心者向けの解説はない。また、本書はエンジニアやプログラマーから見たら「そんなの知ってるよ」「ヘルプに書いてあることじゃん」であり、退屈に映るだろう。

部と章の解説

本書は 5 つの部から構成している。全体像を簡単に紹介する。

第1部秀丸エディタの基礎知識

秀丸エディタを使う上で押さえておきたい基本事項を解説している。

第１章入手とインストールと初期設定
第２章画面構成と見方
第３章秀丸エディタのヘルプを理解する
第４章秀丸エディタの機能（コマンド）を理解する
第５章機能（コマンド）を呼び出す４の方法

これらを知っておくと、秀丸エディタと付き合いやすくなる。いわば秀丸エディタにおける基礎と言える。このあたりを知らないと「多機能すぎて何がなんだかわからない」となるが、知っておけば何かとあたりをつけやすくなる。

第2部基本的な操作や概念

テキストエディタ全般において通用する基本的な操作や概念について解説している。

第６章「元に戻す」と「やり直し」
第７章コピペの基礎
第８章検索
第９章置換
第１０章文字数を知る
第１１章表示制御～より読みやすい表示を求めて～
第１２章ジャンプ～カーソルを素早く移動させる～
第１３章他のファイルを素早く開く

解説は、これらを知らない方向けに「これはこういうものです」「最低限使うにはこのようにします」という感じで、わかりやすくしている。単にヘルプを読んだり、ネットで調べたりするよりも丁寧にしてみたつもりである。

逆に、既に知っている方・使いこなしている方にとっては退屈になるだろう。

第3部高度な操作や概念

テキストエディタまたは秀丸エディタにおける、割と高度な操作や概念について解説している。

第１４章 grep
第１５章正規表現
第１６章マクロ

高度な分、ややこしいものでもあるが、未経験者でも最低限使いこなせるよう、丁寧な解説を心がけた。ページ数や画像も多少多めに費やしている。

第4部アウトラインと Markdown

私も常用しているアウトラインと Markdown について解説している。

第１７章ファイルタイプ別の設定
第１８章アウトライン～見出しと目次による階層的俯瞰～
第１９章マークアップ言語 Markdown ことはじめ

こちらも内容的には高度で、マニアックと呼べるレベルかもしれないが、私が常用している手段でもあり、また秀丸エディタから離れられない理由でもある。秀丸エディタの真価とも言えるだろう。余力があればぜひチャレンジしていただきたい。

第5部設定に関する高度なトピックス

他の部に入らなかったネタを扱っている。具体的には秀丸エディタの設定に絡むネタを二つほど。

第２０章関連付け～ファイルを秀丸エディタで開く方法とその仕組み～
第２１章設定のバックアップと共有

これらは直接執筆の効率には役立たないが、人によっては知っておくと便利だと思われる。

2019-04-29

uBlock Origin でドメインではなくドメイン内の特定サイトのみブロックする

Firefox

uBlock Origin のフィルターの書き方がちょっと独特で迷ったのでメモ。

サンプル
(おまけ) フィルター設定画面の開き方
(おまけ) 一時的に無効にする
参考

サンプル

Twitter を例にする。

例1: アカウント stakiran2 のページをブロック。

||twitter.com/stakiran2^|$document

例2: アカウント名に rush を含むページをブロック(大文字小文字問わず)。

||twitter.com/*rush*^|$document

(おまけ) フィルター設定画面の開き方

ツールバー > uBlock Origin のアイコン > ダッシュボードを開く(なんか→←→と矢印が三つあるアイコン) > Myフィルター

(おまけ) 一時的に無効にする

コメント構文「先頭に ! を付ける」を使う。

参考

2019-04-29

Google 日本語入力で単語登録、辞書ツール、プロパティを呼び出すコマンドライン

Google日本語入力

言語バーは邪魔なので普段は非表示しているが、

言語バーが邪魔なのでデフォルトで非表示にする＆必要な時にだけ表示する - stamemo

使いたい時（単語登録やら辞書ツールやらプロパティ）に再表示するのも面倒くさい。コマンドラインがあれば楽なのだがと思って、調べてみたら、あった。

前提
コマンドライン
おわりに

前提

Windows 10
Google 日本語入力 v2.24.3250.0
実行ファイルのパスは適宜読み替えること

コマンドライン

単語登録

"C:\Program Files (x86)\Google\Google Japanese Input\GoogleIMEJaTool.exe" --mode=word_register_dialog

プロパティ

"C:\Program Files (x86)\Google\Google Japanese Input\GoogleIMEJaTool.exe" --mode=config_dialog

辞書ツール

"C:\Program Files (x86)\Google\Google Japanese Input\GoogleIMEJaTool.exe" --mode=dictionary_tool

バージョン情報

"C:\Program Files (x86)\Google\Google Japanese Input\GoogleIMEJaTool.exe"

引数なしで GoogleIMEJaTool.exe を起動する。

おわりに

これで言語バーを普段隠しつつも、Google 日本語入力の設定を楽に呼び出せるようになった。

2019-04-08

秀丸エディタのマークは「秀丸エディタ以外で更新される」と位置がズレる

秀丸エディタ

秀丸エディタのマーク位置がズレる原因がやっとわかったのでまとめておく。

対象バージョン
レポート
なぜズレてしまう？

対象バージョン

秀丸エディタ V8.69

レポート

たとえば a.txt の 1000 行目にマークを付けたとする。

a.txt を秀丸エディタで編集している限りは、a.txt を編集しても（マークした部分が 1000 行以外の行番号になっても）マーク位置は正確に保持される。

しかし a.txt が 秀丸エディタ以外の手段で更新され、マーク位置の行番号が変わってしまった場合、マーク位置は反映されない。たとえば a.txt をメモ帳で開いて、先頭に 5 行の空行を追加したとすると、マーク位置が 5 行ほどズレてしまう。

なぜズレてしまう？

Ans: たぶんだが秀丸エディタの「マーク位置を追従する仕組み」のせいだろう。

一度マークした位置（行数）は、ファイル内容の変更（行の増減）により変化してしまうが、秀丸エディタはこれをちゃんと追従してくれる。この追従だが、秀丸エディタで当該ファイル（マークを付けたファイル）を編集している時に動的に更新する ことで実現されている。実際、行番号エリアのマークの目印（緑色の背景）は、行の増減に応じてズレるはずだ。

これは言い換えれば「秀丸エディタで編集している時にしか追従できない」とも言える。

したがって、秀丸エディタ以外の方法で編集（行を増減）した場合は、追従もできない。マーク位置はズレてしまう……。

2019-04-04

Firefox Quantum で Default Bookmark Folder アドオンを入れてるのにブックマーク追加位置がずれる件

Firefox

Firefox Quantum では、ブックマークを追加してもメニューの一番下に追加されない。これに対処するのに Default Bookmark Folder アドオンをインストールする。これでめでたし……かと思いきや、最近ブックマークの位置がまたズレた。一番下ではなく、下から二番目とか三番目とかになる。

対処方法
原因

対処方法

「フォルダの中身にブックマークがたくさん（100以上とか）並んだ状態」を避ける。

具体的にはサブフォルダを掘って分類したり、別フォルダに移動させたり、使っていないブックマークはいっそのこと削除したりする。上手くいけば、ブックマーク追加位置がメニューの一番下になるはず。ならない場合、まだ「たくさん並んだ状態」が存在しているので、探して対処する。

※幸いにも Firefox ではブックマークをエクスポートできるし、履歴を消してなければアドレスバーから検索してアクセスもできるので、ブックマークの断捨離は積極的に行うと良い。たとえばエクスポートしておけば、あとで問題が生じてもインポートし直して戻せる。

原因

よくわからん。

2019-04-04

フリーソフト利用申請の効率化を提案したいので現時点の意見をまとめておく

企業・会社・働き方ポエム

フリーソフト利用申請の現状と問題点について書き、その後で「こうすればいいのでは」という意見を書く。

なぜ申請が必要？
主な仕組み
フリーソフトに対する、あるべき認識
現状の問題点
改善したい箇所
提案したい仕組み
この仕組みを浸透させた後の副次効果
教育
おわりに
(余談) 私の思い

なぜ申請が必要？

リスクを未然に防ぐため。

リスク:

ライセンス違反してしまい、賠償請求
スパイウェア/ウイルスが混入したフリーソフトを使ってしまう
フリーソフトの脆弱性を突かれてしまう

なぜ申請制にすると防げる？:

利用機会を（申請というハードルを設けることで）物理的に減らせるから
利用前までのプロセスを強化すればリスクを減らせるから
- ウイルスチェックを義務にする → ウイルス混入を防止できる
- ライセンス調査を義務にする → ライセンス違反を防止できる
申請により責任を明確にし、会社として対処しやすくするため
- 責任保持者は申請者と承認者
- 会社としては何か起きても責任保持者をクビにすれば体裁を保てる

主な仕組み

以下の組み合わせ。

承認制
- 承認者としては上司、上長、情シスなど
- 承認が多段になることもある
- Excel や Wiki などに必要事項を記入する
  - ウイルスチェック結果
  - ライセンス
  - ソフト名
  - バージョン
  - 入手先 URL
  - 利用用途
  - 利用期間
  - ……
禁止リスト（ここに乗っているソフトは問答無用で利用禁止）
許可リスト（ここに乗っているソフトは申請不要）

フリーソフトに対する、あるべき認識

PC 操作はいかに効率化できるかが重要
- 1 操作 10 秒の短縮でも、1 日 100 操作すれば 1000 秒の短縮になる
- 操作に要するコストを減らせば減らすほど、ノイズが減るので、仕事に集中できる
Windows は効率という観点では優れていない OS
Windows で PC 操作を効率化するにはフリーソフトを使う or 自分でツールつくるのが常套手段
- しかしつくるのは簡単ではないため、フリーソフトを使う

結論としてフリーソフトはバリバリ使って当たり前。

現状の問題点

記入事項が多すぎる

申請時に記入する内容が多すぎて申請に時間がかかる。

有効期限がある

半期ごとに再申請が必要、など有効期限があるせいで申請の手間が定期的に再発する。

記入に時間がかかる

特に Excel ファイルだと動作が重い、同時更新ができずに待ちが発生する、部署単位やチーム単位で別々につくるので後でマージが発生するなど記入に時間がかかる。

承認されるまでの時間が長い

使いたい時にすぐに使えない。2 日以上待たされることもある。

承認が形式的で意味を成していない

試しにそれっぽい理由でフリーゲームを申請してみたら通過したことがある
承認者は承認時、申請者の申請内容を見ているだけ
- 申請内容のフリーソフトに関する調査は行っていない

個人的な改善用途では容認されずらい

個人的な効率化、省力化、ストレス軽減程度の用途だと承認されづらい。

特に承認側が無理解 or 怠惰だと「よほど緊急性と必要性がない限り」一蹴されることがある。

承認可否が承認者の主観に依存している

たとえば承認者に嫌われてしまうと申請が一蹴されやすくなる。

改善したい箇所

フリーソフトは危険という認識

フリーソフトは危険だと一蹴するのは「パソコン使うと危ないから紙で仕事しろ」「車使うと危ないから歩け」と言っているくらいに無知にも程がある。無論、危険はゼロではないが、それは何の世界や道具であっても同じこと。

従業員の良識に任せれば良い。「何かあったら最悪クビになる」ことを周知しておけば、（危険を犯しそうな）無知な人は使わないし、無知でない人はそれでも使う。元々効率に無頓着は前者は無視すればいい。問題は、そうではない後者が、理不尽で不自由な承認制によって効率化を阻害されていることにあり、この阻害の根本原因が「フリーソフトは危険」という無知な認識である。この認識をなくすために、従業員各々の責任のもとで自由に使わせる方向性を採用する（そうすることで後者の人間の非効率阻害をなくす）べき。

申請時の記入事項 → シンプルにする

「ソフト名」「入手先」くらいで良い。

用途は問わない

フリーソフトは個人的な改善用途でも使うべきなので、いちいち用途は問わない。申請時の作文も面倒くさい。

管理する → 把握する

フリーソフト利用を管理しようと考えるから非効率になる。実用的には「承認が下りたフリーソフトはこれ」「承認が下りなかったフリーソフトとその理由はこれ」が把握できればそれで良い。

承認する → チェックする

承認するのではなく「そのフリーソフトを使ってもいいかを皆でチェックする」と考える。

たとえば申請内容を表示するサイトを用意し、全社全員が閲覧＆コメントを書けるようにする。そうすれば「そのバージョンには脆弱性がありますよ」とか「そのソフト、もう更新停止しているみたいですね」とか「ウイルス対策ソフトの設定によってはウイルス誤検知することがあります」とかいった実用的な情報も集まりやすい。また「いいね」が使えるシステムなら賛同リアクションも見える。少なくとも無知な承認者数人よりは圧倒的に有意義。

なおコメントがない場合はデフォルトで利用 OK する。つまりコメントがなければそのまま利用可能になる。問題がある時だけコメントして対処するという形。

部門単位の管理 → 全社共通の共有

部門単位で利用管理するのではコストがかかりすぎる。全社全員が見れる場所に登録する、という形態にする。もちろん誰でも自由に登録可能。承認プロセスも介さない。

提案したい仕組み

フリーソフトを「登録」する:

ブラウザから簡単に登録できる
登録後、全社全員が見れるサイトに情報が載る
- ここでコメントがあれば申請者は考え直し、場合によっては利用を停止する
つまり「登録されたフリーソフト」の一覧が載っているサイト
- 1 ソフト 1 ページで専用ページがある
- 1 ページには「利用可能」「利用不可能」「利用不可能の理由」などの情報がある

登録画面:

ソフト名、入手先 URL、ウイルスチェック結果のスクショ
ソフト名
- 細かい表記ゆれをどう吸収するか……
入手先 URL
- チェックをかけて、海賊サイトの URL だったらエラーを出すなどする
スクショ
- 「フリーソフトは危険だ」派を黙らせるためのパラメーター
- これがあれば何か起きても「ウイルス対策ソフトでは問題無かった」という逃げ道がつくれる
登録者名は本名公開固定
- 責任を見せるためにも匿名は認めない

コメントについて:

誰でも自由に書けるようにする
- 名前は公開 or 非公開が選べる
  - 非公開：ハードルを下げるために匿名コメントも必要
  - 公開：ゲーミフィケーションやアピールのために必要
コメント例
- 例1:「そのバージョンには脆弱性がありますよ」
- 例2:「このソフト、もう更新停止しているみたいですけど」
- 例3:「ウイルス対策ソフトの設定によってはウイルス誤検知しますね」
- 例4:「このソフト、バージョン xxx からは商用利用できないです」

利用可否の判断について:

個々のページに「利用ステータス」パラメーターがある
- 利用可能
- 利用不可能
従業員はこのステータスを見て、利用可能だったら自由に使う
利用ステータスを更新できるのは登録者本人のみ

ダイレクトダウンロード:

可能なら入手先は「ダウンロード済のバイナリ等を置いた社内サーバ」にしたい
- いちいち公式サイトから DL するのは手間
- 公式サイトが潰れて使えなくなる可能性もある
- しかし再配布条件について調べないといけないのが手間か

この仕組みを浸透させた後の副次効果

無知な人がフリーソフトを知り、リテラシーと効率がアップする
「フリーソフトに詳しい従業員」という立場や仕事が生まれる

理想を言えば Stackoverflow や Yahoo 知恵袋のカテゴリマスターのような「メンテ役」が生まれると良い。フリーソフトで従業員（特に大企業にもなると何百、何千人）らを効率化できれば、それは大きな貢献となる。メンテ役だけでメシを食べる人がいてもいい。何なら「フリーソフト促進部」みたいな部をつくっても良いくらい。

教育

フリーソフトに関する知識や実践要領は実地的なものであり、自ら携わらない限り、身につくことはない。自ら携わってない者については、明示的な教育が必要である。

「フリーソフトは危険だ」が偏見であること
フリーソフトが効率化において大いに役立つこと
- 代表的なカテゴリやフリーソフトの紹介？
各人が自分好みに PC の設定を変えるように、フリーソフトも自由に試すのが普通だということ
フリーソフトを使う上でのリスクの種類と自衛方法
フリーソフトの入手方法、説明書の読み方、使い方
フリーソフト、フリーウェア、OSS の違い
「フリーソフト」という言葉の意味がケースバイケースである点について
……

とはいえ無知な者を引き上げるのは骨が折れるから、教育はあくまでも「"フリーソフトを使いたい人が自由に使える風土" を実現するための道具」として使うべきだろう。つまり「教育しているよ」という活動や実績の事実をもって否定派を黙らせる材料にする。

おわりに

まだまだ荒削りだが、言葉にしないと始まらないので、とりあえずダンプしてみた。

(余談) 私の思い

仕事 PC も、自宅 PC みたいに自由にフリーソフトを導入して効率化したい
フリーソフトに詳しい人間というポジションを社内で得たい
- 自分主導で快適に仕事したい（コンサルやエヴァンジェリストのイメージ）
- あわよくばそれに見合った報酬も欲しい

2019-04-03

Pandoc で Markdown to HTML すると Access violation in generated code when executing data at が出る件

Pandoc

Pandoc で Markdown から ePub を生成する作業をしているが、ちょっとした表示確認には ePub よりも軽い手段で確認したい。つまりは HTML である。

しかし Pandoc で Markdown to HTML すると Access violation in generated code when executing data at ... のようなエラーが たまに 出る。対処がやっとわかったのでまとめる。

前提

Windows 10 + Pandoc 2.5

対処

--self-contained オプションは使わない。

--standalone オプションを使う。

コマンドライン Before/After

before$ pandoc -f markdown -t html5 --self-contained -c stylesheet.css hidemaru.md title.txt -o book.html --toc --toc-depth=2
after $ pandoc -f markdown -t html --standalone -c ./stylesheet.css hidemaru.md title.txt -o book.html --toc --toc-depth=2

細かい修正がちらほらあるが、肝心なのは --self-contained → --standalone だと思う。

原因は？

不明。--self-contained オプション（に相当する実装）が不安定なのだろうか。

2019-03-20

テキストファイルに記載されたファイルパスを開く秀丸エディタマクロ pathjump

秀丸エディタ

たとえば a.txt に filename.ext という記載があったとして、ここにカーソルを合わせてる時に filename.ext を一発で開く……なんてことがしたかったので、マクロをつくった。

どんなマクロ？
使い方
マクロ
実装の話

どんなマクロ？

d:\data\text\work_201903.txt を開いているとする。内容は以下。

……（中略）……
日報はこっちに移した nippou.txt#2019/03
……（中略）……

この時、「nippou.txt#2019/03」の部分にカーソルを合わせてから本マクロを呼び出すと、

d:\data\text\nippou.txt が開かれる
キーワード「2019/03」で検索が走り、最初にヒットしたところまでジャンプする

こんな挙動をする。

つまり記載した（相対）ファイルパスに一発でジャンプするマクロ。

記法としては以下三つがある。ファイル名のみ、行番号つき、検索キーワードつき。

filename.ext ← filename.ext を開く
filename.ext@20 ← filename.ext の 21 行目を開く
filename.ext#apple ← filename.ext を開いて apple で検索する

使い方

下記マクロを pathjump.mac など適当にファイルに保存後、秀丸エディタに登録。あとはキー割り当てなどを割り当てて呼び出しやすくする。私は F12 に割り当てている。

マクロ

// pathjumper
// カーソル位置にあるファイルパスを秀丸エディタで開くマクロ.
//
// 対応している表記
// - filename.ext         ← filename.ext を開く
// - filename.ext@20      ← filename.ext の 21 行目を開く
// - filename.ext#apple   ← filename.ext を開いて apple で検索する
//
// 仕様など
// - 表記中のファイルが存在しない場合は何もしない.
// - 表記中のファイルは「今開かれているファイルのあるディレクトリ」
//   を基準とした相対パスとして扱われる.
// - 表記として絶対パスは使えない.
//   例: C:\Data\text.txt
// - 表記の左右は行頭, 行末, 半角スペース, タブのいずれかでなければならない.
//    OK  xxx filename.ext yyy
//    NG  xxxfilename.extyyy
// - 行番号が大きすぎる場合は最終行にジャンプする

$curdir = directory;
#curx = x;
$curline = gettext(0, y, linelen ,y, 0);

if(strlen($curline) == 0){
    endmacro;
}
$c = midstr($curline, #curx, 1);
if($c == " " || $c == "\t"){
    endmacro;
}

// xxxxIxxx
//      ^
//      ここを一文字ずつ左にズレながら見る.
//      空白が見つかったら, その位置の一文字右が抽出開始位置.
//
// ただし先頭まで来ちゃったら開始位置は先頭とみなす.
#startpos = -1;
if(#curx == 0){
    #startpos = 0;
}else{
    #searchpos = #curx;
    while(#searchpos > 0){
        #searchpos = #searchpos - 1;
        $c = midstr($curline, #searchpos, 1);
        if($c == " " || $c == "\t"){
            #startpos = #searchpos + 1;
            break;
        }
    }
    if(#startpos == -1){
        #startpos = 0;
    }
}

#endpos = -1;
#lineendpos = linelen;
if(#curx == #lineendpos){
    #endpos = #lineendpos;
}else{
    #searchpos = #curx;
    while(#searchpos < #lineendpos){
        #searchpos = #searchpos + 1;
        $c = midstr($curline, #searchpos, 1);
        if($c == " " || $c == "\t"){
            //#endpos = #searchpos + 1;
            #endpos = #searchpos;
            break;
        }
    }
    if(#endpos == -1){
        #endpos = #lineendpos;
    }
}

#pickup_length = #endpos - #startpos;
$pickuped_word = midstr($curline, #startpos, #pickup_length);
$start_c = midstr($curline, #startpos, 1);
$end_c = midstr($curline, #endpos, 1);
//message "[" + $curline + "]\n[" + $pickuped_word + "]";

#idx_linejumpmark = strstr($pickuped_word, "@");
#idx_findjumpmark = strstr($pickuped_word, "#");
$openee_filename = $pickuped_word;
$openee_option = "";
if(#idx_linejumpmark != -1){
    $openee_filename = midstr($pickuped_word, 0, #idx_linejumpmark);
    $openee_linenumber = midstr($pickuped_word, #idx_linejumpmark + 1);
    $openee_option = "/k" + $openee_linenumber;
}else if(#idx_findjumpmark != -1){
    $openee_filename = midstr($pickuped_word, 0, #idx_findjumpmark);
    $openee_findoption = "/sCWRZ";
    $openee_findtext = midstr($pickuped_word, #idx_findjumpmark + 1);
    $openee_option = $openee_findoption + "," + "\"" + $openee_findtext + "\"";
}

// カレントディレクトリが秀丸エディタの macro 用フォルダになっているので
// 今開いているファイルのディレクトリを用いる.
$openee_fullpath = directory + "\\" + $openee_filename;

// 存在しないファイルパスで openfile すると新規になっちゃうのでガードする.
// 開けない → 無効, だとわかるので何もせずに終わるだけでいい.
if(existfile($openee_fullpath) == false){
    endmacro;
}

$commandline_for_openfile = $openee_option + " " + "\"" + $openee_fullpath + "\"";
//message $commandline_for_openfile;

openfile $commandline_for_openfile;
endmacro;

// [テスト]
// 筆者環境で実行することを想定.
//
// houtliner.mac
// xxx houtliner.mac@100
// houtliner.mac@9999 yyy
// xxx houtliner.mac#OK_if_not_outline_file yyy

実装の話

以下マクロプログラミングの話が続く。

アルゴリズム全体

こんな感じ

1: カーソル X 位置を記憶
2: 1を基点に、一文字ずつ左を見ていって、区切りに到達したら止まる
3: 1を基点に、一文字ずつ右を見ていって、区切りに到達したら止まる
4: 2と3の情報を使って、区切り間の文字列を取り出す
5: 4 の文字列からファイル名部分とオプション(行番号 or キーワード)部分を取り出す
6: 5 の情報を使って openfile 命令を呼び出す

ファイルパス表記はどうやって抽出する？

上記の 2 と 3 にあたるところ。

最初は「単語選択」→「コピー」みたいに操作を呼び出して済まそうと思ったけど、単語選択操作の精度がポンコツすぎたのでやめて、自力でパースすることにした。

パースをシンプルにするために「区切りとは何か」の明確なルールを設けた。以下のいずれか。

行頭
行末
半角スペース
タブ

これ以外は受け付けない。たとえば

var = "filename.ext"

↑ こんな行から filename.ext を取り出すことはできない。「"」も区切りにすれば済むじゃないか、とはそのとおりだが、きりがないのでやめた。

抽出したファイルパスを開いて行番号ジャンプまで行うにはどうすればいい？

最初は run 命令でファイルを開く、down 命令で一行スクロール……みたいにゴリゴリ操作をエミュレートする方向で考えていたけど、run 命令でファイルを開いてもマクロの制御がそっち（run で開いたファイル）に移らないので没。

どうしたものかと悩んで、秀丸エディタのオプションを漁ったり、マクロ命令を漁ったりしてたら、別の方法が見つかる。openfile 命令。

秀丸エディタには /k100 で 100 行目を開く、みたいなオプションがある
openfile 命令を使うと、このオプションがそのまま使える

というわけで openfile を採用。

テストはどうやってるの？

すまない、手作業でテキトーにやっただけ……。

別にファイルを破壊するマクロでもないので、挙動が気になるなら適当に試していただければ。

2019-03-20

GitHub Pages を使えば「Markdown ファイルを書いてアップするだけで」ウェブサイトをつくれる(ビルド作業も不要)

GitHub

Markdown 愛用者で、かつ書いたテキストを公開したい私のような人種にとって障壁となるのは「テキストを見やすい形でウェブサイトに公開すること」だった。この障壁を取っ払う優れた方法は無かった。

今までの方法:

ブログサービスなど → ログインや管理画面など画面を経由するのがだるい
- 例: はてなブログ
Wiki → Markdown に対応していない、自前でサーバーを用意する必要があるのがだるい
- 例: Mediawiki
静的ウェブサイトジェネレーター → ビルドがだるい、生成されたファイルの管理がだるい
- 例: Hugo、MkDocs

しかし優れた方法が見つかった。その名も GitHub Pages。

成果物
このやり方のメリット
このやり方のデメリット
なぜこんなこと(ビルド無しでウェブサイトを生成)が実現できるか
導入手順
デモ
参考

成果物

Monolithic Texts | monolithic

本記事のやり方でつくっているのが、この Monolithic だ。これは一つのテーマを一つのページ(Monolithic/一枚岩)で記述した雑記帳であるが、このウェブサイトの更新に必要な作業は以下だけである。

ローカルで Markdown ファイルを書く
リポジトリに Push する

これだけで上記ウェブサイトにも反映される。ローカルでビルド作業する必要もない。ただただテキストだけ書いていたい私としては、これがすこぶる快適なのだ。

このやり方のメリット

ローカルで Markdown で書ける
ビルド作業が必要ない（環境も必要ない）
ビルドしてできた生成物を管理する必要もない
プライベートリポジトリにすれば Markdown の生原稿（やウェブサイトに公開してない他ファイル）は見られない

このやり方のデメリット

GitHub Pages に反映されるまでに多少のタイムラグがある
- 10 秒あれば反映される時もあるし、1 分経っても反映されないこともある
生成物がどう表示されるかを素早く確認できない（GitHub Pages 側で反映されるまで待つ必要がある）
デザインテーマが非常に限られている
下準備がちょっと面倒くさい

なぜこんなこと(ビルド無しでウェブサイトを生成)が実現できるか

Ans: GitHub Pages 側でビルドしてくれてるから。

GitHub Pages では Jekyll という静的ウェブサイトジェネレーターを使っている。この Jekyll の設定ファイルとか書いてリポジトリに置いておけば、push するたびに GitHub で勝手にビルドを走らせてくれる。

導入手順

リポジトリをつくる
最低 1 回は push する(これしないと次手順 GitHub Pages 有効化ができない)
リポジトリの Settings から GitHub Pages を有効にする＆サイトテーマを適当に選択する
- ウェブサイト URL が発行されるのでメモしとく
リポジトリに index.md をつくる
リポジトリに Jekyll 関連の設定ファイル(※1)をつくる
push

ウェブサイト URL にアクセスすると、index.md が HTML 化されて表示されるはず。index.md からリンクが張られた他ページも同様（逆を言えばリンクが張られてない Markdown ファイルは HTML 化されない）。

デモ

本記事のやり方で、todochute という自作タスク管理ツールのウェブサイトをつくってみた

リポジトリ: stakiran/todochute-releases
ウェブサイト: todochute | todochute-releases

参考

2019-03-20

Windows 10 でフォルダの右クリックメニューが汚いので掃除する

Windows

ふと気になったのだが、Windows 10 の右クリックメニューがごちゃごちゃしていて汚い。不要な項目を削除することにした。調べたことをまとめとく。

どうやって掃除する？
見るキー
消し方
Q: なぜエントリやキーを消さない？
Q: レジストリいじっても項目が消えないんだけど？
参考

どうやって掃除する？

右クリックメニューの項目はレジストリに保存されてる
レジストリをいじって、消したい項目に対応するデータを消せばいい

見るキー

HKEY_CLASSES_ROOT*\shellex\ContextMenuHandlers
HKEY_CLASSES_ROOT\AllFilesystemObjects\shellex\ContextMenuHandlers
HKEY_CLASSES_ROOT\Folder\shellex\ContextMenuHandlers
HKEY_CLASSES_ROOT\Directory\shellex\ContextMenuHandlers
HKEY_CLASSES_ROOT\Directory\Background\shellex\ContextMenuHandlers
HKEY_CLASSES_ROOT\Drive\shellex\ContextMenuHandlers

たくさんある。Folder と Dierctory みたいに違いがよくわからんキーもあれば、* やら AllFilesystemObjects みたいに「すべてのファイルタイプに対して追加」的な意味を持つものまである。ややこしい。一通り見てみることをおすすめする。

消し方

ContextMenuHandlers キーの直下にアプリ名や CLSID 名などでキーがある。

無効にしたいキーを開き、 (既定) エントリの値を適当に書き換える。

例:

{4A7C4306-57E0-4C0C-83A9-78C1528F618C}

↓

-{4A7C4306-57E0-4C0C-83A9-78C1528F618C}

Q: なぜエントリやキーを消さない？

Ans: ソフトウェア側のアップデートが入った時に「キーが無いやん。作り直さな」と作り直されてしまう恐れがあるから。

このように消さずに置いておけば、そのような作り直しを防げる（率が上がる）。

Q: レジストリいじっても項目が消えないんだけど？

Ans: エクスプローラーあるいは Windows を再起動しないと消えてくれないこともあるみたい。

参考

2019-03-18

Stack Overflow が落ちてる光景を始めて目撃した

StackOverflow

2019/03/18 13:20 頃、Stack Overflow が死んでいるという珍しい光景に出くわした。Twitter の盛り上がりなども含めて色々とまとめてみた。

どんな画面？
体験した感想は？
- マジで不便ですね
- どんどん増えるツイート
Twitter 上での反響
もっと反応が見たい方

どんな画面？

本文は以下だった。

Routine maintenance usually takes less than an hour. If this turns into an extended outage, we will tweet updates from @StackStatus or post details on the status blog.

そしてよくわからん画像が 6 枚貼られていた（以下そのうちの1枚を直リン）。

stackoverflow_offline_ide

謎である。何かのユーモアなのだろうか（私にはよくわからない）。

体験した感想は？

マジで不便ですね

Javascript 開発中はマジで不便ですね。わからないことをググると大体 MDN か Stack Overflow かの二択で、より実践的なネタは大体 Stack Overflow がヒットするわけですが、それが死んだとなるともう不便で不便で仕方ない。

私は重たい日本語ブログが嫌いなので、技術的なちょっとしたわからないことはなるべく Stack Overflow でひっかかるようにするのですが、ここが死んだとなると、重たい日本語ブログに頼らざるを得ない。

……と思ったのですが Google のキャッシュを見ることで解決しました。キャッシュは本当に便利。

どんどん増えるツイート

Twitter の検索画面を開いたままにしていると、どんどん新しい通知が来ます。復旧を願う声がぞくぞく。エンジニアのイベントにエア参加しているみたいで楽しいです。

Twitter 上での反響

有効ツイート数は 15、調査日時は 2019/03/18 13:30 ですが、こんな意見がありました。

画像がちょっと……
- 画像はこちら: https://cdn.sstatic.net/sites/stackoverflow/Img/offline-ide-1.png
- 1.png から 6.png まであります
- これがズラリと並んでます
仕事にならん
珍しいね

ちなみに、一番最初に呟いたのはたぶんこの人。

ぼるぼるさんのツイート: "Stackoverflowが死んでて仕事ができない人"

もっと反応が見たい方

以下をどうぞ。

stackoverflow lang:ja since:2019-03-18 until:2019-03-19 - Twitter検索

since/until フィルター入れてるので、後日読んでも見れると思います。発生日時はたぶん 2019/03/18 13:00 あたりなので、そのあたりまで遡っていただければ。

(追記) 検索キーワードちょっと甘かった。「stack overflow」にしたらもうちょっとヒットする。

stack overflow lang:ja since:2019-03-18 until:2019-03-19 - Twitter検索

2019-03-16

匿名 Slack について実現方法や現実などを簡単に調べてまとめた

Slack コミュニケーション

匿名 Slack を実現してみたかったので、先駆者たちの情報を漁って簡単にまとめてみた。一部個人的な試行過程も盛り込んである。

どうやって実現するの？
- 1 の例
- 2 の例
よく起こる問題
結論

どうやって実現するの？

方法は二通り。

1: Bot つくる
2: 別の匿名入力手段をつくる

1 は「ユーザーから受け取ったメッセージを、匿名で、どっかのチャンネルにポストする」ようなBot。匿名でポストしたい人は、Bot に対して DM を送る形になる。

2 は、「Slack にポストできる何らかの投稿サービス」から Slack に匿名でポストするイメージ。

1 の例

2 の例

Google Formsを使ってSlackに匿名で投稿 - k's tech blog

手順としては以下のような感じ。

1: Slack 側で「この URL にパラメータ投げたらメッセージ投稿できるぜ」な URL を発行する
- アクセスキーみたいなもん
- バレたら誰でも使えるので扱いには注意する
2: Google Forms で、1 に投稿する匿名フォームをつくる

よく起こる問題

誰がやるの？簡単にできるの？問題

匿名投稿システムの開発やらメンテやらを誰がやるのかという話。

言い出しっぺがやることになるのだと思う。

上記記事の範囲内では「ある個人が提案して」「サクっと許可もらって」「試しに作って運用してみた」くらいの軽さみたい。逆を言えば、そのくらいはフットワークの軽いチームでないとダメなんだろうと思う。

※私の体験談を言うと「意見集まりにくいので匿名チャット作りたいです。Botつくります。権限ください」 → 「ダメ」「業務ツールで "とりあえず試す" はナシ」で一蹴。

吐き出して終わり問題

改善系の会議や活動でもありがちだが 不満や改善点は挙がるものの、その先の具体的行動がない というパターン。

複数の記事が指摘していたことなので、陥りがちなことなのだと思う。

誰かわかる問題

これは Slack や匿名といった文脈ではなく、（私が携わっていたある界隈の）Twitter の Peing 質問箱の文脈なのだが、 匿名であっても文体や質問内容から大体誰かがわかる ことがあるらしい。特に対人要領に長けている人が、この能力に優れているように思う。

また、不満や改善をぶつけたいが、日頃そのようなネタを抱いている人間が少数 or 自分のみという場合、匿名でぶつけても事実上「あ、アイツだ」とバレてしまうという問題もある（投稿内容の希少性問題）。

匿名に対する危険視

これは調べたことではなく実体験だが、匿名投稿手段について検討しようとすると、無知な人や保守的な人が牙を向いてくる。

もし誹謗中傷が来たらどうするの？
荒れたらどうするの？
匿名なんて手段に頼るのはどうかと思うよ？某掲示板じゃないんだから
普通に相談すれば良くない？匿名にする必要性は何？
匿名の意見なんて信用できるわけねえだろ

結論

二行で。

導入できるかどうかは職場次第
- できそうな場合はサクっとできる
- 一蹴された場合はたぶん無理
吐き出された意見を行動に移す仕組みも欲しいね

2019-03-16

秀丸エディタで使いやすいファイルヒストリ(最近使ったファイル)を実現するマクロ

秀丸エディタ

秀丸エディタにはファイルヒストリ機能があり、最近使ったファイルに素早くアクセスできるが、これが少し使いづらい。不満として以下があった。

メニューアクセラレータを自由に設定したい
フォーマットにもう少し融通を利かせたい
キー割り当てから一発で呼び出したい
「ファイルヒストリのつづき」 ← これは要らない、一段で一気に表示してほしい

このあたりを解消するためマクロをつくった

マクロ
解説
作者の使い方
資料
- ファイルヒストリの保存件数
- ファイルヒストリの実体

マクロ

// [使いやすいファイルヒストリメニュー]
// 秀丸エディタ内蔵のファイルヒストリはフルパス表記のため読みづらく、
// またメニューアクセラレータもカスタマイズできません。
// このマクロを使うと、そのあたりをカスタマイズできます。
//
// デフォルトでは以下フォーマットで表示します。
//   (番号): (ファイル名)
// また、メニューアクセラレータはファイル名先頭文字を割り当てます。
// (これにより文字キーでファイル名を選択できるようになります)
//
// 他のフォーマットにカスタマイズしたい場合は
// このマクロを適当にいじってください (^^;
//
//
// [このマクロの動作に必要なこと]
// ・ファイルヒストリの記録を有効にする
//   → その他 > 動作環境 > 設定の対象 > ファイル > ヒストリ
//      「つづきも記録」にチェックを入れてください

#i = 0;
#SEARCH_UPPER_COUNT = 100;
while(#i < #SEARCH_UPPER_COUNT){
    $hist_fullpath = getfilehist(#i);
    #last_delim_pos = strrstr($hist_fullpath, "\\");
    if(#last_delim_pos == -1){
        break;
    }
    $hist_filename = midstr($hist_fullpath, #last_delim_pos + 1);

    // メニュー項目表示用文字列を整える.
    // とりあえずファイル名ベースで番号とアクセラレータ付けてみる.
    $index_for_display = str(#i);
    if(strlen($index_for_display)==1){
        $index_for_display = "0" + $index_for_display;
    }
    $hist_filename_with_accel = "&" + $hist_filename;
    $array_for_display[#i] = $index_for_display + ": " + $hist_filename_with_accel;

    // 実際に開くフルパスも保持しとかないと後で取り出せない.
    $array_for_opening[#i] = $hist_fullpath;

    #i = #i + 1;
}
#actual_item_count = #i;

if(#use_mouse_pos==true){
    mousemenuarray $array_for_display, #actual_item_count;
}else{
    menuarray $array_for_display, #actual_item_count;
}

if(result==0){
    endmacro;
}

#selected_id = result - 1;
$selected_fullpath = $array_for_opening[#selected_id];
$selected_fullpath_with_surround = "\"" + $selected_fullpath + "\"";
$editor_fullpath = hidemarudir+"\\hidemaru.exe";
$editor_fullpath_with_surround = "\"" + $editor_fullpath + "\"";

$tha_last_commandline = $editor_fullpath_with_surround + " " + $selected_fullpath_with_surround;
//message $tha_last_commandline;
run $tha_last_commandline;

解説

解説はマクロ内にコメントで書いたのでそちらを読んでください。

インストール方法などは割愛（既に秀丸エディタマクロに習熟しているものとする）。

作者の使い方

私は Ctrl + H に割り当てて使っている。H は History の H。

これを呼び出す時はたいてい開きたいファイル名がわかっているので、Ctrl + H でメニューを開いた後、文字キー一文字目を押してリーチできることが多い。素早い。便利。

資料

秀丸エディタの仕様など今回調べた情報をまとめておく。

ファイルヒストリの保存件数

実は可変である。

ヘルプによると、

記録できる個数は、ファイル名の長さによって変化します。（目安：フルパスで半角５０文字で約５０個）

ファイルヒストリの実体

レジストリに記録されている。

キー:

HKEY_CURRENT_USER\Software\Hidemaruo\Hidemaru\Hidemaru.dat\FileHist

エントリ:

000
- REG_BINARY
- ファイルのフルパスを記録
001
- 同上
002
...
c
- REG_DWORD
- エントリ xxx の上限数を記録
- たとえば上限が 69 個なら 69 が記録される(実際は 16 進数なので 45 だけど(
  - 000 ～ 068 まで存在することになる

書いた本

どんな本？

対象読者

部と章の解説

第1部 秀丸エディタの基礎知識

第2部 基本的な操作や概念

第3部 高度な操作や概念

第4部 アウトラインと Markdown

第5部 設定に関する高度なトピックス

サンプル

(おまけ) フィルター設定画面の開き方

(おまけ) 一時的に無効にする

参考

前提

コマンドライン

単語登録

プロパティ

辞書ツール

バージョン情報

おわりに

対象バージョン

レポート

なぜズレてしまう？

対処方法

原因

なぜ申請が必要？

主な仕組み

フリーソフトに対する、あるべき認識

現状の問題点

記入事項が多すぎる

有効期限がある

記入に時間がかかる

承認されるまでの時間が長い

承認が形式的で意味を成していない

個人的な改善用途では容認されずらい

承認可否が承認者の主観に依存している

改善したい箇所

フリーソフトは危険という認識

申請時の記入事項 → シンプルにする

用途は問わない

管理する → 把握する

承認する → チェックする

部門単位の管理 → 全社共通の共有

提案したい仕組み

この仕組みを浸透させた後の副次効果

教育

おわりに

(余談) 私の思い

前提

対処

コマンドライン Before/After

原因は？

どんなマクロ？

使い方

マクロ

実装の話

アルゴリズム全体

ファイルパス表記はどうやって抽出する？

抽出したファイルパスを開いて行番号ジャンプまで行うにはどうすればいい？

テストはどうやってるの？

成果物

このやり方のメリット

このやり方のデメリット

なぜこんなこと(ビルド無しでウェブサイトを生成)が実現できるか

導入手順

デモ

参考

どうやって掃除する？

見るキー

消し方

Q: なぜエントリやキーを消さない？

Q: レジストリいじっても項目が消えないんだけど？

参考

どんな画面？

体験した感想は？

マジで不便ですね

どんどん増えるツイート

Twitter 上での反響

もっと反応が見たい方

どうやって実現するの？

第1部秀丸エディタの基礎知識

第2部基本的な操作や概念

第3部高度な操作や概念

第4部アウトラインと Markdown

第5部設定に関する高度なトピックス