2019-05-10

Slack のスニペット機能に関する仕様や挙動を調べた

Slack

Slack をテキストストレージとして使いたかったので、仕様や挙動を一通り調べてみた。

スニペットとは
- 新規作成時のパラメーター
- スニペットの公開範囲
すべてのファイル
パーマリンク
- (SNIPPET-TITLE).(EXT) とは？
検索時の挙動

スニペットとは

チャンネル内に長いテキストを添付できる。実体はテキストファイル。

新規作成時のパラメーター

基本パラメーター:

タイトル(記入式)
記法(選択式、各種言語やMarkdownなどをサポート)
本文(記法に応じてハイライトされる)
- 折り返し: チェック入れると折り返し表示できる

共有パラメーター:

共有相手チェック(共有を行う場合はチェックを入れる、共有対象は共有相手ボックスにて選ぶ)
共有相手ボックス(共有先となる人やチャンネル名を入れる)
メッセージ(共有時に追加でメッセージがあれば書く)

スニペットの公開範囲

「プライベート」属性と「共有」属性がある。

プライベートチャンネルや DM などで共有すると「プライベート」属性。関係者しか見れない。

パブリックチャンネルなどで共有すると「共有」属性。誰でも見れる。

すべてのファイル

スニペット含め全ファイルはその他 > すべてのファイルからアクセスできる。ここには自分が見れるファイル（自分が所属する「プライベート」属性のものと、「共有」属性のもの）が一覧で表示される。

ちなみにスニペット作成時に共有相手を指定しなかった場合は、（どのチャンネルにも投下されていないので）ここからアクセスするしかない（後述する検索で見つけることもできるが）。

パーマリンク

三つある。

ワークスペース関係者限定のリッチリンク(Private Rich)
- https://(TEAM-NAME).slack.com/files/XXXXXXXXX/XXXXXXXXX/(SNIPPET-TITLE).(EXT)
ワークスペース関係者限定の RAW リンク(Private Raw)
- https://files.slack.com/files-pri/XXXXXXXXX-XXXXXXXXX/(SNIPPET-TITLE).(EXT)
誰でも見れる外部用リンク(Public)
- https://slack-files.com/XXXXXXXXX-XXXXXXXXX-XXXXXXXXX

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」になる
- 日本語部分がマスクされている

検索時の挙動

検索結果には「メッセージ」タブと「ファイル」タブがあるが、「メッセージ」タブにはヒットしたメッセージそのものが表示される(のでわかりやすい)。一方、「ファイル」タブにはヒットしたファイルしか表示されない(そのファイル内のどこにヒットしたかまでは表示されない)。

本文がヒットしたとき

「ファイル」タブに検索結果が表示される。

タイトルがヒットしたとき

「メッセージ」タブに検索結果が表示される。

ちなみに検索でヒットさせられるタイトルは スニペットを新規作成したときのタイトルのみ である。あとでタイトルを変えても、変えた後のタイトルではヒットしない。

(提案) スニペットを多数投稿する運用で、各スニペットを検索しやすくしたい場合

これはただの提案なので興味無ければ読み飛ばすこと。

私は「タイトルに検索キーワードをあれこれひっつければ、後で探しやすくなる」と考えたが、上述のとおり、新規作成以後はタイトルを変えてもヒットしてくれない。なので現実的には スレッドとしてタイトルと検索キーワードを並べたメッセージを書いておく のが良いと思う。そうすれば検索時に「メッセージ」タブにヒットしてくれてわかりやすい。

2019-05-09

AWS でリージョンあたりの VPC 数を上限緩和する

AWS

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 してね」と。メールよりも楽でいいですね。

感想

というわけであっさり出来たのであった。

2019-05-09

SSH クライアント RLogin を nanno.dip.jp 以外から入手する

RLogin

公式サイト nanno.dip.jp がダウンしているのか、入手できなかったので、代わりの入手先を探した。

結論

GitHub からダウンロードする。

Releases · kmiya-culti/RLogin より rlogin_x32.zip または rlogin_x64.zip をダウンロードすればよい。

GitHub について

公式サイトや代替サイトに以下文言がある。

http://nanno.dip.jp/ がアクセスできない場合などにご利用ください。

nanno.dip.jp が何かと脆いからということで準備されたものだと思われる。

2019-05-09

Ctrl + Alt + K キーを押すと Kindle が開かれる件

Kindle

結論を言うと Windows の「ショートカット」の「ショートカットキー」として Ctrl + Alt + K が勝手に設定されていた。Kindle インストール時に勝手にされたんだと思う。

対処方法

shell:start menu を開く
Programs\Amazon\Amazon Kindle\Kindle.lnk
右クリック > プロパティからショートカットキーを消す

参考

kiyo7447: Kindleを入れたらCtrl+Alt+Kのショートカットが使えなくなった。

本当に助かりました。ありがとうございます。この記事見つからなかったら原因不明のまま AutoHotkey でロックするところでした。

所感

それはそうと、勝手にショートカットキー設定するのは行儀悪いなぁ……。

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

スニペットとは

新規作成時のパラメーター

スニペットの公開範囲

すべてのファイル

パーマリンク

(SNIPPET-TITLE).(EXT) とは？

検索時の挙動

本文がヒットしたとき

タイトルがヒットしたとき

(提案) スニペットを多数投稿する運用で、各スニペットを検索しやすくしたい場合

現在の上限数を見る

上限緩和を行う

緩和が開始されるまで

感想

結論

GitHub について

対処方法

参考

所感

書いた本

どんな本？

対象読者

部と章の解説

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

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

第3部 高度な操作や概念

第4部 アウトラインと Markdown

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

サンプル

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

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

参考

前提

コマンドライン

単語登録

プロパティ

辞書ツール

バージョン情報

おわりに

対象バージョン

レポート

なぜズレてしまう？

対処方法

原因

なぜ申請が必要？

主な仕組み

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

現状の問題点

記入事項が多すぎる

有効期限がある

記入に時間がかかる

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

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

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

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

改善したい箇所

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

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

用途は問わない

管理する → 把握する

承認する → チェックする

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

提案したい仕組み

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

教育

おわりに

(余談) 私の思い

前提

対処

コマンドライン Before/After

原因は？

どんなマクロ？

使い方

マクロ

実装の話

アルゴリズム全体

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

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

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

成果物

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

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

第3部高度な操作や概念

第4部アウトラインと Markdown

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