Windows で python boto3 を使って AWS の REST API を叩くまで

AWS

例として公式ドキュメントの下記サンプルコード、

リージョン名と AZ 名を列挙するところを目標にする。特に Python コードを書く部分でハマリポイントがちらちらある。

前提

  • AWS の基礎知識がある（管理コンソールをいじってアクセスキーを発行できる）
  • Windows で Python を使う基礎知識がある（Python や pip のインストールができる）
  • Python 3.6.1
  • boto3 1.7.35

コード

# coding: utf-8

import os
import boto3

# キーを生でファイル等に保存するのは危ないので
# 環境変数から読み込むようにする.
# (使う度に環境変数にキーをセットしてね)
ACCESS_KEY = os.environ['AWS_ACCESS_KEY']
SECRET_KEY = os.environ['AWS_SECRET_KEY']

# ここでは東京リージョンを指定している.
USING_REGION_NAME = 'ap-northeast-1'

# SSL 証明書ファイルのパス.
# 今回は面倒くさいので使わない. 使わない, を意味する False を.
USE_SSL = False

ec2 = boto3.client(
    'ec2',
    aws_access_key_id=ACCESS_KEY,
    aws_secret_access_key=SECRET_KEY,
    region_name=USING_REGION_NAME,
    verify=USE_SSL
)

# Retrieves all regions/endpoints that work with EC2
response = ec2.describe_regions()
print('[Regions]')
for region in response['Regions']:
    print(region)

# Retrieves availability zones only for region of the ec2 object
response = ec2.describe_availability_zones()
print('[AZs]')
for az in response['AvailabilityZones']:
    print(az)

実行結果

$ python boto3_test.py
[Regions]
{'Endpoint': 'ec2.ap-south-1.amazonaws.com', 'RegionName': 'ap-south-1'}
...

[AZs]
{'State': 'available', 'Messages': [], 'RegionName': 'ap-northeast-1', 'ZoneName': 'ap-northeast-1a'}
...

必要な作業

(1) Python3 のインストール

割愛。

(2) boto3 のインストール

pip コマンドで一発。

$ pip install boto3

気になる人は venv 等を使って仮想環境で作業すること(仮想環境自体の解説は割愛）。

Q: (2) で応答が返ってきません

Ans: プロキシサーバ環境下の場合はその設定も行う。

$ set HTTPS_PROXY=https://(PROXY_SERVER_IP):(PORT)
$ set HTTP_PROXY=http://(PROXY_SERVER_IP):(PORT)
$ pip install boto3

Q: (2) で SSLError が出ます

Ans: てっとり早くやりたいなら以下のおまじないを使う。

$ pip install --trusted-host pypi.org --trusted-host files.pythonhosted.org boto3

やってることは、SSL 通信において信頼済ホストに「pip パッケージの配布元」を追加する、というもの。

参考: python - pip install fails with "connection error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:598)" - Stack Overflow

(3) AWS 管理コンソールでアクセスキーを取得

ポリシーやら何やら細かい話は割愛。

必要なのは「アクセスキー(Access Key)」と「シークレットキー(Secret Key)」の二つ。なおシークレットキーはアクセスキー新規時に一度のみ表示されるので、それをコピペして安全に保存しておく。

(4) 上記スクリプトを書く

たとえば boto3_test.py で保存する。

(5) 上記スクリプトをキーを設定した後、実行する

以下を実行する。

$ set AWS_ACCESS_KEY=(取得したアクセスキー)
$ set AWS_SECRET_KEY=(取得したシークレットキー)
$ python boto3_test.py

すると上記実行結果が得られるはず。

(余談) なぜキーを環境変数経由で設定させているかというと、セキュリティのため。キー情報をうっかり放置したままにしたり、どっかにアップ（特に GitHub 等に Push しちゃうケース）しちゃったりすると、悪用されて大変なことになる。このやり方ならキー情報を保存しない（ターミナルを閉じたら消える）ので安心。

Q: (5) で InsecureRequestWarning 警告が出ます

Ans: 無視すれば OK

上記スクリプトでは SSL 認証をしていない(verify=False)ので、その旨が傾向として表示されている。

D:\bin1\Python361\lib\site-packages\botocore\vendored\requests\packages\urllib3\connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)

(メモ) アクセスキーがおかしい場合

参考までにメモしておく。以下のようなエラーが出る。

$ python boto3_test.py
Traceback (most recent call last):
  File "boto3_test.py", line 28, in <module>
    response = ec2.describe_regions()
  File "D:\bin1\Python361\lib\site-packages\botocore\client.py", line 314, in _api_call
    return self._make_api_call(operation_name, kwargs)
  File "D:\bin1\Python361\lib\site-packages\botocore\client.py", line 612, in _make_api_call
    raise error_class(parsed_response, operation_name)
botocore.exceptions.ClientError: An error occurred (AuthFailure) when calling the DescribeRegions operation: AWS was not able to validate the provided access credentials

参考

おわりに

最低限動かすところはできた。

課題は SSL 部分で手抜きしていることか。本当はちゃんと証明書ファイルのパスを指定して認証するべき。

AWS で多数の EBS ボリュームを EC2 Management Console から削除する際のコツ

AWS

AWS で遊んだ時に作った EBS ボリュームたちを消したい（EBS は存在してるだけで課金される）。何十個以上となればさすがに API を叩くけど、十数個くらいだったのでスクリ書くよりも手作業が早い。

というわけで早速消そうとしたのだけど、ハマったのでまとめとく。

結論

  • ポイント1: デタッチしないと削除できない
  • ポイント2: デタッチは複数選択できないが、削除は複数選択できる
  • ポイント3: フィルターを使って消したいボリュームのみが表示されるようにすること
    • もっというとフィルターできるよう ボリューム作成時点でタグ（たとえば Name タグ）を付けておく こと
  • ポイント4: デタッチ or 削除する度に 更新ボタン を押して画面を更新すること

詳しく

1 と 2 は「仕様です」という話なので「まあそうですか」と従うしかない。

3 については、私（というか会社）の場合、一つの AWS アカウントで色んなメンバーが色んなボリュームを作っているという状況だったので、フィルターできないと死ぬ（何十という中から自分が作った分だけ手作業で探して消すのは地獄……）。ので最初からタグ付けしておいた。助かった。

4 については一番ハマった点。デタッチ or 削除した直後は 画面に反映されない ため、一番上のボリューム（もうデタッチor削除されてる）をデタッチ or 削除しようとするとエラーが出て怒られる。なのでいったん更新ボタンをクリックして明示的に画面を更新してやる。そうすると「一番上のボリュームをデタッチ」「更新ボタンクリック」「一番上のボリュームを削除」「更新ボタンをクリック」「一番上の……」という感じで、（私が当初から意図していた）機械的な繰り返しに帰着できる。

AWS で You do not have permission to access the specified resource. が出て Elastic IP を削除できない件

AWS

結論を言うと、NAT ゲートウェイ等、その Elastic IP に紐付いているリソースを先に削除 した後、その Elastip IP を解放する。

エラーメッセージから「権限が無いのかな？」と思いがちだが違う。ググっても答えは見つかりません。

Q: The association ID 'eipassoc-XXXXXXXX' does not exist が出た時は？

これは何の関連付けもされてない Elastic IP を関連付け解除しようとした時に出るエラーメッセージ。関連付け解除ではなく「解放」をすること。

Qiita 記事のアクセス数といいね数/はてなブックマーク数/ポケット数の傾向を調べてみた

Qiita

ふと気になったので調べてみた。色んな傾向が出てて面白い。ただ割合出して「へー」してるだけなので統計や数学の見地は期待しないこと。

バズったネタ記事でも 1% 程度

Qiita のランキングにも載った記事。

項目 値と単位
記事アクセス数 34771
記事いいね数/率 331(0.95%)
記事はてブ数/率 373(1.07%)
記事ポケット数/率 294(0.84%)

エンジニア（Twitter やってる率高くて反応率高い）向けで、しかも反応を得やすいであろうネタ記事であるが、それでも 1% 程度なんだなぁと。

ポケット数 > はてブ数 > いいね数の例

GitHub ネタ。

項目 値と単位
記事アクセス数 5399
記事いいね数/率 23(0.42%)
記事はてブ数/率 81(1.50%)
記事ポケット数/率 98(1.81%)

はてブ数がいいね数の約4倍という結果が出た。いいねはしないけどブックマークはする人も結構いるのかな？

また、はてブ数はポケット数との相関が高いように見える。

いいね数 > ポケット >> はてブ数の例

UNIX エンジニアが忌み嫌う Windows ネタ。

項目 値と単位
記事アクセス数 6833
記事いいね数/率 98(1.43%)
記事はてブ数/率 5(0.07%)
記事ポケット数/率 55(0.80%)

今度はいいね数がはてブ数を大きく上回った。

しかし、はてブ数とポケット数との相関が低い。

いいね数 > ポケット数 > はてブ数の例

バズるほどではないがちょこちょこ反応をいただいてるネタ（に見えるけど本人は真面目な）記事。

項目 値と単位
記事アクセス数 5724
記事いいね数/率 102(1.78%)
記事はてブ数/率 21(0.36%%)
記事ポケット数/率 48(0.83%)

いいね、ポケット、はてブが大体 1/2 ずつバラけてる。だからどうしたと言われてもよくわからん。アクセス数多い記事なので挙げてみただけ。

いいね数≒ポケット数 > はてブの例

タスク管理ネタ。

項目 値と単位
記事アクセス数 7169
記事いいね数/率 62(0.86%)
記事はてブ数/率 13(0.18%)
記事ポケット数/率 53(0.73%)

これもアクセス数多い記事なので挙げてみただけ。傾向はよくわからん。

いいね/はてブされてないが、ポケットされている例

完全なる自己満記事。

項目 値と単位
記事アクセス数 271
記事いいね数/率 0(0%)
記事はてブ数/率 0(0%)
記事ポケット数/率 2(0.73%)

いいねもはてブもされてないが、ポケットはされているという例。ポケットする層の傾向がいまいちわからないっすね。

ちなみにポケット数 2 というとショボく見えるけど、0.73% という割合は上記「ビジネスホテルで一人開発合宿する」記事と大差無い(0.84%)。

はてブされてないが、いいねとポケットされている例

オレオレタスク管理ツール作ってみたよという自己満記事。

項目 値と単位
記事アクセス数 659
記事いいね数/率 4(0.60%)
記事はてブ数/率 0(0%)
記事ポケット数/率 4(0.60%)

はてブは無いが、いいねとポケットはされている。 物置としての GitHub - Qiita 記事も同じ傾向が出ている。これは何を意味するだろうか。

検索すると一ページ目に出てくる記事の例

Windows のテキストエディタ「秀丸エディタ」ネタ。「秀丸エディタ」で検索すると一ページ目に出てくる。

項目 値と単位
記事アクセス数 5260
記事いいね数/率 9(0.17%)
記事はてブ数/率 1(0.019%)
記事ポケット数/率 3(0.057%)

（おそらく Windows 向けだから）いいねもはてブもポケット数も少ないのだと思われる。Windows ユーザーはいいねやはてブやポケットをしない人が多いということかな？

※ちなみに上記「てっとり早く Windows を使いやすくする定番ツール集」記事の反応が多い（いいね率は1.43%）が、この記事は読者を「普段は UNIX OS を使ってる人で、やむを得ず Windows を使わないといけない人」に定めているからである。つまり読者は Windows ユーザーというよりも「Windows も使う（けど普段は Windows を使ってない）ユーザー」である。

アクセス数が 40000 view 超えてるけどはてブがゼロ

いわゆるリファレンス系の記事。

項目 値と単位
記事アクセス数 43378
記事いいね数/率 7(0.016%)
記事はてブ数/率 0(0%)
記事ポケット数/率 1(0.002%)

備忘録で簡単にまとめただけだがアクセス数がやばい。「半角英数字」とかで検索しても一ページ目に出てくる。リファレンス系記事は反応が薄いんだなと実感。

おわりに

以上、自己満だが色々調べてみた。

ハード的に MacBookAir が Windows ノートパソコンより優れている点を四点ほど

MacBookAir

MacBookAir と Windows ノートパソコンを両方使っている身として、MacBookAir が（ハード的に）優れている的をまとめてみる。

最初に結論をまとめておく

  • Windows と違ってストレスが少ない
  • Windows にこだわる理由がないなら MacBookAir に乗り換えた方が良い（Windows でストレスに晒され続ける必要はない）

1. MBA は起動や終了がスリープ復帰が速い

たとえば起動しきる（電源入れてログインして操作可能になる）まで 10 秒くらい。Windows と比べて 10 倍も 20 倍も速い。冗談抜きで。

また終了やスリープも速くて、Windows みたいにタスク終了を何十秒と待つこともない。

2. MBA は軽くて薄い

インチ数にもよるけど 11 インチだと縦横は A4 用紙くらいで、厚さは人差し指と同じくらい、とコンパクト。持ち運びも楽だし、膝の上に置いても重くない。

3. MBA は音が静か

Windows 搭載ノートパソらとは違い、神経質な私でも気にならないくらいに音（HDD やらファンやらの音）が静か。たとえば小説執筆中にも「ネットで調べる用」に立ち上げておけるし、読書時も起動しっぱなしにしておける。

ちなみに他のパソコンだと音がうるさくて集中できないことがしばしばあり、自宅の Windows ノートはよくスリープにする。

4. MBA はキーボードが打ちやすい

ノーパソにおいて重要なのはキーボードの打ちやすさだけど、ノーパソのキーボードは基本的に使いづらい。国産のノートなら日本人向けに割と設計されているが性能がショボイので論外。かといって性能の高い海外製のパソコンは、ろくに設計されてないからか打ち辛い（特にカーソルキーや修飾キーなど補助系のキーは絶望的）。だから Realforce キーボードなどを外付けで別途つなげることになるのだが、これは場所を取るのでだるい。

MBA はというと、キーボードがよく設計されてて、かなり打ちやすい。別に Realforce 繋がなくてもいいかなと思える。

explorer shell:::{CLSID} に関する覚え書き

Windows

CLSID を指定して Windows の機能を呼び出すための覚え書き。

CLSID とは

Windows 内のアプリやら機能やらが持つ一意の識別子。もっというと COM コンポーネント(Windowsの機能を再利用できるようにした部品)に付く GUID。

たとえば「ファイル名を指定して実行」とか「コントロールパネルの各項目」などに CLSID が割り当てられている。

CLSID 情報はレジストリの HKEY_CLASSES_ROOT\CLSID キー配下に記録されている。

CLSID を指定して Windows の機能を呼び出す

explorer shell:::{CLSID} というコマンドラインを実行すると、CLSID が指す機能を呼び出せる。

たとえば「ファイル名を指定して実行」の CLSID は {2559a1f3-21d7-11d4-bdaf-00c04f60b9f0} なので、以下コマンドラインを叩くと、「ファイル名を指定して実行」を開ける。

explorer Shell:::{2559a1f3-21d7-11d4-bdaf-00c04f60b9f0}

他にどんな機能を呼び出せる？

既に調べてくれてる方がいらっしゃるので参考にする。

見た感じコントロールパネルやタスクバーから辿れる機能は大体呼び出せるみたい。

使えそうな CLSID を調べてみた

以下は手を動かしてみたい私の自己満足。

利用できそうな機能の CLSID を自力で抽出してみた。成果物は GitHub に置いた。端的に結果だけ見たいなら こっち。

どうやって抽出したか

reg コマンドにて HKEY_CLASSES_ROOT\CLSID 配下を上手く抽出して、必要なら Grep なり何なりで加工していくスタイルで頑張ってみた。

最初に実行したのは以下。

$ reg query "HKEY_CLASSES_ROOT\CLSID" /f "InfoTip" /s

つまり 「InfoTip」というエントリを持つキーのみ を対象にしている。それ以外の 9 割以上はよくわからないコンポーネントや外部アプリの CLSID なので用はない（もっというと用がありそうなキーに共通するのが InfoTip キーの有無っぽかったので今回こうした）。

続いて、得られたキー名の一覧を作って、今度は以下コマンド、というかバッチファイルで「各キー名に対する詳細情報(各エントリ)」をゲットした。

@echo off
setlocal
set BASEDIR=%~dp0
set SAVEPATH=%BASEDIR%3_queries.txt

del %SAVEPATH%
rem ★得られたキー名の一覧は  2_keyonly.txt に
rem ★一行一キーで保存しているものとする.
for /F "usebackq" %%i in (`type 2_keyonly.txt`) do (
  reg query %%i /f "*" /d >> %SAVEPATH%
)

あとは Grep とか使って加工しておしまい。

各エントリについて

今回、用があったのは以下二つ。

  • (既定): 機能名
  • InfoTip: 実際に呼び出されるプログラムパス(DLLに引数を渡しているケースが多い)

例を一つ挙げる。

{2559a1f3-21d7-11d4-bdaf-00c04f60b9f0}
キー名   エントリ種類  値
(既定)    REG_SZ  Run...
InfoTip     REG_SZ  @explorer.exe,-7003

これは

  • CLSID は {2559a1f3-21d7-11d4-bdaf-00c04f60b9f0}
  • これが表す機能名は「Run...」である
    • ファイル名を指定して実行のこと
    • なぜ末尾にピリオドが三つ付いてるのかは不明
    • 日本語Windows でもこの値
  • これを呼び出した時に実質呼ばれるのは @explorer.exe,-7003 である
    • explorer に埋め込まれてる 7003 番目の機能を呼び出す、みたいな指定

感想

  • reg query コマンドの使い方について勉強になった

Microsoft に買収された GitHub は今後どうなっていくのだろう

GitHub ポエム

GitHub が 8000 億円で Microsoft に買収された。公式ブログアナンスの日本語訳も GitHubの輝かしい未来 というタイトルで出ている。

今後 GitHub はどうなっていくのだろう。

なお最新情報は github lang:jaに関するTwitterニュース あたりを読むと見つかりやすい。

以下、上記タイムラインから気になった出来事を雑多に取り上げる。勉強も兼ねて私見コメント付き。

設計図共有サイト？

日経が GitHub を「設計図共有サイト」と紹介してしまい炎上した話。日経側は「わからん人にわかりやすく説明するためにこの言葉にした」みたいだが、「設計図共有サイトって何やねん。GitHub はそんなんちゃう」という指摘され燃えたようだ。今は「開発者向け共有サイト」に修正されている。

(コメント) 個人的には「ソースコード」はもはや誰もが知るべきレベルの常識だと思うんだけどなぁ。

GitLab に逃げる

GitHub競合の「GitLab」が有償プランの無料開放をオープンソースプロジェクトと教育機関向けに実施 - GIGAZINE

GitHub から GitLab に移行する人も出てるみたい。GitLab 側もチャンスを逃すまいと有料プランを無料化するなどアクティブになっている。

(コメント) 個人的には移行する気になれない。 GitHub の UI は群を抜いて優秀なので、正直これを手放すという選択肢が考えられない。ああ、すっかり依存してますな私。

IF_MS_BUYS_GITHUB_IMMA_OUT(買収されたらGitHubやめるわ) リポジトリ

面白いリポジトリがある。

GitHub - upend/IF_MS_BUYS_GITHUB_IMMA_OUT: GitHub has sold us out. This is the GitHub Evacuation Center.

Star は 2018/06/06 19:23:41 現時点で 3600 を超えている。

普通これだけ活発化したら Trending ページ に出るはずなんだけど、運営側によって非表示にされてしまったらしい。

(コメント) これはちょっと残念だよね。自分たちにとって不都合なことを隠しているわけだ。オープンで公正な世界はどうした。まあ営利企業なので不利益なことを避けるのは当然なのだろうが、この程度の活動にもメスが入ってしまうとなると、不安にはなる。

Q: なぜ Microsoft に買収されることがいけないことなの？

これは言語化が難しいところだが私の理解を書く。

GitHub は OSS を扱う世界最大のプラットフォームだ。そして OSS というものは常にオープンで公正な世界でなくてはならない。GitHub という企業は、一営利企業でながらも真摯に支えてくれていた。神経質な私も感心しているし、今も手に馴染んでいる。たとえば、

  • 機能や UI も群を抜いて使いやすく（所感では歴代No.1）、また改善され続けている
  • 余計な広告やリコメンドが一切無い
  • (チーム利用はさておき個人利用なら) 月額7ドルと 破格的に安い

あたりは素敵だ。もはや人生に無くてはならない存在だった。

さて、そんな GitHub だが、今回 Microsoft という大企業に買収されてしまった。Microsoft は同じように真摯に支えてくれるだろうか。

否、そうは思えないのである。Microsoft がオープンでなく、公正でもなく、またセンスも無いことは Windows "にも" 、あるいは Internet Explorer "にも" 携わっていればわかることだ。これまで何度も何度も振り回されてきた。「デファクトスタンダードの Windows だから」「天下の MS だから」で泣く泣く対応するハメになったことも一度や二度ではない。早い話、信用できないのである。

おわりに

マジでどうなるんだろう。お願いだから潰さないでくださいね Microsoft さん。今までどおり「GitHub の一ユーザー」として利用する、くらいのスタンスでいい。加えて新しいサービスやら何やらを 別のページで 売り込む。それくらいでいい。間違っても既存の GitHub 部分には手を入れないでほしい。たとえば広告出しちゃうとか、トップページに製品情報へのリンク入れるとか、そういうのマジでやめてね。

はぁ。どうなるんだろうなぁ。

ネット回線が遅いので AWS(Amazon Web Services) でネットサーフィンする

AWS

自宅に光回線を引き込めないのでネットが遅くて辛い。ふと「AWS 上でインスタンスつくって、そこでネットサーフィンすればよくね？」と思った。そうしたら AWS のインフラとして整備されてる高速回線が使える。快適にネットサーフィンできそうだ。

というわけで、AWS をネットサーフィン用途で使うための必要手順やら実験結果やら何やらを雑多にまとめてみた。

※2018/06/06 現在、本記事は未完成です (2018/06/20 追記) 東京リージョンとシンガポールリージョンの通信速度を比較した内容を追加。

結論

  • 使い方イメージ
    • EC2インスタンス(Windows)に自PCからリモートデスクトップで入る
    • 入った先でネットサーフィンする
  • 通信速度
  • 料金
    • インスタンスは medium(メモリ4GB) だと 8.6円/時間
    • 通信量は 17.5円/GB
  • まだ調べてないこと
    • リモートデスクトップで遅延(特に音ズレ)無く動画視聴できるか？
    • EC2インスタンスに繋ぐまでの回線が遅い場合、実用に耐えうるか？
    • VPC 等の設定(特にセキュリティ)はこれで十分か？悪用されないか？

前提

背景

ネットが遅すぎて辛い。しかも改善もできないっぽくて、

  • 自宅のネット回線が遅い。住民が集まってる時間帯だと YouTube の動画再生がカクつくレベル
  • マンション側の制約で光回線を引き込めない
  • WiMAX は繋がるが、YouTube はさておきニコニコ動画や他動画サイトはまだカクつく

こんな感じ。

AWS でネットサーフィン？

AWS 上のインスタンスは AWS のインフラとして整備された高速回線で通信する ので、ネットサーフィンにも向いてるんじゃね？と思ったわけです。

今回の目的

支障無いレベルでネットサーフィンしたい。具体的には以下。

  • YouTube やニコ動を快適に視聴できる
  • 100MBのファイルダウンロードが数十秒以内に済む(※1)

※1 ネットサーフィンには無関係だが回線速度を知る目安になるため目標にする

利用イメージ

ネットサーフィンの利用イメージは以下のとおり。

  • 1: AWS アカウントでログインする
  • 2: EC2 インスタンスを起動する
  • 3: リモートデスクトップで 2 のインスタンスにログイン
  • 4: ネットサーフィン
  • 5: 終わったら 2 のインスタンスを停止する

いちいち停止させてるのが面倒だが、稼働させてると料金がバカにならない(24Hフル稼働だと月1万円超えてくる)ので仕方ない。

環境を整える

(1) アカウント登録

AWS を使い始めるにはアカウント登録が必要。クレジットカード情報入力必須。

Q: 無料で使える？

Ans: 使えない

一応無料枠はあるが、ささやかなものである。

無料枠を超えたら自動で課金が発生するため もし何らかのミスやクラッキング被害により大量使用してしまった（されてしまった）場合、えぐい金額が請求される ことになる。セキュリティと運用は気をつけなきゃいけない。

事例:

ただ不正利用については「AWS アクセスキー等を GitHub の Public リポジトリに公開しちゃった」時に起きるので、今回のケース(インスタンスにログインしてネットサーフィンするだけ)では起きない。もちろん AWS アカウントやら後述するキーペアファイルやらはちゃんと管理するとして。

心配するべきは「インスタンスをずっと立ち上げっぱなしにしてて料金が加算され続けた」系だろう。使い終わったら停止する、など運用面で気をつけるしかない。

(2) 今回作りたい構成

  • EC2インスタンス一台

AWS には多数のサービスがあるのが、使うのは EC2 インスタンス一台のみ。こいつにリモートデスクトップでログオンして、あとはネットサーフィンするだけ。

たぶん AWS 利用としては最もシンプルな部類だと思う。別に Web サービスを運営するわけじゃないしね。

設定手順

さて AWS でインスタンスを実際に作っていくところだが、最低限でも結構煩雑だ。ここでは要点だけ書く。

  • 1: VPCをつくる
    • vpc1
  • 2: Internet Gateway をつくる
    • ig1
    • vpc1 にアタッチする
  • 3: Subnet をつくる
    • subnet1
  • 4: Default route table を設定する
    • 送信先 0.0.0.0/0 にターゲット ig1 を設定
  • 5: EC2 インスタンスをつくる
    • EC2 > インスタンス作成 > コミュニティ AMI から Windows イメージ探す
    • 例: Windows 2016 Japanese
    • インスタンスタイプは medium(メモリ4GB) が良いかと
    • vpc1, subnet1 を指定する
    • 自動割り当てパブリックIPは有効に(これないとリモートで繋げない)
    • 新しいセキュリティグループつくる
      • sg1
      • RDP(3389) TCP(6) 3389 0.0.0.0/0 を設定する(デフォで入ってるはず)
    • 新しいキーペア(秘密鍵)を作成してダウンロードしておく
  • EC2 インスタンスの追加設定
    • アクション > ネットワーキング > セキュリティグループの変更 から default も追加しておく( これしないとセキュリティ的にガバガバ )
    • アクション > Windows パスワードの取得 からログオンユーザー名(Administratorのはず)、パスワードとログオン先IPを手に入れる

これで整った。手に入れた IP とパスワードを使ってリモートデスクトップにてログインできる。

料金

続いて料金について。

前置き

まずは予備知識。

厳密な計算は非常にややこしい(この手の記事や「料金計算サービスつくってみました」は山ほどある)ので諦める。

料金は公式サイトにてまとめられている:

上記はオンデマンド（使った時間分だけ請求する）の料金だが、他にも色んな利用形態がある。ここでは割愛。

またネットを調べると要約版もちらほら見つかる。

公式サイトからざっくり計算してみた

オンデマンドインスタンスの料金 ページから試算してみた。

例: メモリ 4 GB の Windows マシンで週に10H程度(月50Hとする)使う場合

  • EC2インスタンス代が 8.5892 * 45 = 429.46 ≒ 430円/月。
  • データ転送分は 17.44円/GB かかる

まとめると、月かかる料金は 430 + 17.44*(通信GB量) 円となる。

以下に GB 毎にまとめてみた。

通信GB量 月額料金
7 552.08
10 604.4
30 953.2
100 2174
300 5662
1024(1TB) 18288.56

月30GBくらいまでは1000円以内で済む。300GBになると5600円超えてきて一般的なインターネット料金くらいにはなる。1TB にもなると割高。

参考: EC2

Windows の場合は以下。

※東京リージョン、1ドル109円、一月24時間*30日として計算

タイプ メモリ 料金($/時) (円/時) (円/日) (円/月)
t2.micro 1[GiB] 0.0198 2.1582 51.7968 1553.904
t2.small 2[GiB] 0.0396 4.3164 103.5936 3107.808
t2.medium 4[GiB] 0.0788 8.5892 206.1408 6184.224
t2.large 8[GiB] 0.1496 16.3064 391.3536 11740.608

micro や small だとメモリ少なすぎて Windows を動かす事自体が苦しい。large はネットサーフィン用にしては贅沢だと思う。medium が無難か。 1時間立ち上げてると8.6円かかる 計算に。

参考: データ通信

結論: 17.5円/GB くらいかかる

以下内約。

EC2インスタンスへのデータ受信:

  • パブリックまたは Elastic IPv4 アドレスの使用: $0.010/GB (1.09円/GB)

EC2インスタンスからのデータ送信:

  • パブリックまたは Elastic IPv4 アドレスの使用: $0.010/GB (1.09円/GB)

EC2インスタンスからインターネットへのデータ送信:

  • もし 1GB/月 以内なら: 無料
  • もし 10TB/月 以内なら: $0.140/GB (15.26円/GB)
  • もし 40TB/月 以内なら: $0.135/GB (14.715円/GB)

まとめると、

  • 今回はパブリックIPを一つ使っているので、まず 1.09 + 1.09 = 2.18 2.18円/GB かかる
  • インスタンスからデータ通信する分は、ネットサーフィンで 40TB いくことは無いと思うので 10TB/月 として 15.26円/GB かかる
  • 合わせて 17.44円/GB かかる

Q: ネットの回線速度はどれほど？

Ans: ケースバイケースだろうが手元で調べた結果を載せる

BNR スピードテスト 回線速度／通信速度 測定 で測定してみた。

シンガポールリージョン(2018/06/06)

  • 下り
    • 最高データ転送速度 24.04Mbps (3.00MB/sec)
    • 平均データ転送速度 11.18Mbps (1.39MB/sec)
  • 上り
    • データ転送速度 12.47Mbps (1.55MB/sec)
    • アップロードデータ容量 800kB

ネットサーフィンでは下り速度が重要だが、十分なポテンシャルだと思う。

ちなみに 145MB の Atom パッケージ をダウンロードしてみたところ、15秒くらいでサクっとサウンロードできた。

実家の光回線環境(2018/06/07)

実家で契約している光回線環境（基本的に通信速度で不満を感じることはない）でも試してみた。

  • 下り
    • 最高データ転送速度 78.58Mbps (9.82MB/sec)
    • 平均データ転送速度 46.67Mbps (5.83MB/sec)
  • 上り
    • データ転送速度 60.60Mbps (7.57MB/sec)
    • アップロードデータ容量 1000kB

光回線レベルには及ばない模様。

東京リージョン(2018/06/20)

  • 下り
    • 最高データ転送速度 180.27Mbps (22.53MB/sec)
    • 平均データ転送速度 103.08Mbps (12.88MB/sec)
  • 上り
    • データ転送速度 216.21Mbps (27.02MB/sec)
    • アップロードデータ容量 1000kB

速い！

しかし 145MB の Atom パッケージ をダウンロードしてみたところ、1分くらいかかってる。シンガポールリージョンより遅いのは github.com サーバーとの位置関係だろうか(東京で下り/上りが速いのも回線テストサイトが国内サーバーだからだろうか)。

その他調べたいこと

  • EC2インスタンス上で動画再生して音声を聞き取れるか
  • 聞き取れた音声に音ズレがないか
  • セキュリティ(default セキュリティグループ)はこれでいい？
    • AWS 側で用意してくれてるデフォ設定なので大丈夫だと思うけど……
  • 可用性の担保はどうする？
    • AWS側のメンテナンスやら何やらで使えないケースがあるからどうするって話
    • 普通は複数台インスタンスをアベイラビリティゾーンを分けて置いたりするが、たかがサーフィン用途でそこまでやるのも。。。（料金も倍以上になるし）

おわりに

まだまだ調査途中だが、案外イケんじゃねえか？って気がしてきた。

「カクヨム」と「小説家になろう」で同じ小説を書いてみた上で使い勝手とか仕様とか比較する

小説執筆

割と長文エントリ。拾い読みしてもいいかもしんない。

==== 前提 ====

どんな作品？

  • ブクマ数が二桁も行かないような素人が書いたラノベ
  • 文字数は 30 万文字行かないくらい(薄いラノベ2冊分くらいか)
  • ジャンルは異世界転生モノではない、とだけ言っておく

投稿方法は？

  • まずはローカルで完結させた後、1日2～3話程度を予約投稿で投稿する
  • 投稿時間帯はコアタイム（通勤通学前、昼食中、退社後）を狙う
  • 宣伝活動や足跡作戦（ブクマやフォローをすると、された側が見に来るのでアクセス数や反応を稼げる）はしない

==== 総評 ====

もし「どっちを使ったらいいの？」と訊かれたら。

一言で

Ans: カクヨムが良い、と答えます。

三言で

  • 使いやすさ、書きやすさ、軽さはカクヨムが圧勝
  • なろうは利用者数が圧勝（カクヨムとは桁が一つ二つ違うと思う）だが、ブクマ二桁に満たない素人にはあまり関係がない
  • 利用者パワーで大差無いなら、使いやすいカクヨムでいいじゃん

==== 実測データ ====

アクセス数

Ans: なろうが多い。

完結後数日後時点のアクセス数を見てみると、2.5倍の差が出た。

  • カクヨム: 1000PV
  • なろう: 2500OV

なろうには「完結ブースト」があるように見える。連載中は1日 30-60PV程度だったが、完結直後は数倍以上の伸び。

  • 完結前日: 20PV
  • 完結日: 450PV ★完結ブースト
  • 完結日翌日: 350PV
  • 完結後2日目: 600PV
  • 完結後3日目: 400PV ★数日くらい続く模様
  • 完結後4日目: 80PV
  • 完結後5日目: 10PV

アクセス数の内約

実測データと簡単な見解を。

なろう

計 2500 PV。うちパソコンが 1000 PV、携帯が 150 PV、スマホが 1350 PV。二人に一人はスマホで読んでいる。

またユニークだと計 550 PV。うちパソコンが 390 PV、携帯が 10 PV、スマホが 150 PV。スマホは 四人に一人 にまで落ち込んでいる。代わりに 七割はパソコンユーザー。

以上を踏まえると、じっくり読んでいるユーザーの大半がスマホ だとわかる。スマホユーザー向けに読みやすさを確保するのが重要と思われる。

カクヨム

計 1000 PV。

エピソードごとの累計 PV は以下のようなイメージ(ただし 2018/06/02 に見た時の約 1500 PV ベースなので 1000 PV 時点ではない)。

  • 1話: 80 PV
  • 2話: 60 PV
  • 3話: 40 PV
  • 4話: 40 PV
  • ...
  • 20話: 15 PV
  • 21話: 20 PV
  • ...
  • 38話: 30 PV
  • 39話: 30 PV
  • 40話: 35 PV

緩やかな「く」の字をしている。つまり最初と最後が多くて、中が少ない。また最後よりも最初が多い。1話は一番最初に読むので当然ではあるか。

このアクセス解析では「読者は何話まで読んでくれているのか」がわかる。上記例の場合、3話には落ち込んでいるため、1-3話を「もっと読者を引き込むように」書く必要があるだろう。あるいは読みづらくて敬遠されている可能性もあるが。

評価数

Ans: 横ばい

  • なろうではブックマーク数が一桁、ポイント評価が数件
  • カクヨムではおすすめレビューが★一桁、フォロワーが一桁

ちなみにコメントや感想は無い。

(余談) なぜカクヨムは利用者が少ないのに横ばいなのか？

Ans: アクティブユーザー（評価を付けるユーザー）率が高いから、と予想

これは体感でしかないのだが、カクヨムはアクティブユーザー率が高いように思う。カクヨムのイメージは「はてな」に近くて、はてなアカウントを持っている人が気軽にスターを付けるような、そんなコミュニティ感があるように思う。

あるいは なろうの非アクティブユーザー率が高い と言うべきかもしれない。 小説を読もう！ という読み専用のサイトも併設されているくらいだし。

==== 使い心地や仕様 ====

記法

Ans: カクヨムもなろうも同じ。

  • ルビは 鬱陶《うっとう》しい
  • 範囲指定ルビは 至極｜煩《わずら》わしい

執筆

Ans: カクヨムが書きやすく、使いやすい。

カクヨムは非常に直感的かつシンプルで、ヘルプ読まなくても使えるレベル。さすが Web を牽引する「はてな」が運営しているだけある。

なろうはいまいち使いづらい（慣れてる人にはそうでもないみたいだが）。ただ入力ボックスを貼り付けただけ、みたいな。

パソコンでたとえるならカクヨムは Macintosh で、なろうは Windows。

ブログでたとえるならカクヨムははてなブログ（をさらにシンプルかつ軽くした感じ）、なろうは FC2 ブログ（設定豊富だけど細々してて使いづらい）。

予約投稿

Ans: カクヨムの方がきめ細かい。

カクヨムは HH:MM 単位で自在に指定できる。

なろうは HH 単位まで。

なろうは小説情報の総文字数が （まだ投稿されてない）予約投稿分も含めてしまう 点が辛い。早い話、10万文字の作品を全て予約投稿していたら、10話しか投稿してなくても10万文字と見えてしまい「1話1万文字かよ、読みづらそうだなこの小説」となる。

小説管理ページ

Ans: カクヨムが見やすく、また使いやすい。

カクヨムは概要ページから一発で編集ページに飛べる。なろうは飛べない（いちいち ユーザートップページ → 投稿小説 と辿る手間がある）。

カクヨムは UI/UX を意識してつくられている。なろうはつくられないように見える（画面が汚い、煩雑で分かりづらい）。ただしなろうも慣れたらそうでもない。

アクセス解析

Ans: なろうに軍配が上がる

なろうではアクセス傾向が細かくわかるので、研究/対策も考えやすい。

なろう

観点が豊富なのと、パソコン/携帯/スマホの内約を示してくれる点が優秀。

  • 全体PV/全体ユニークPV
    • うちパソコン、携帯、スマホの内約も分かる
  • 今日/昨日のPV数
  • 過去一週間のPV合計
    • 時単位の内約も分かる
  • 日別/月別のPV数/ユニークPV数
    • PV数ベスト10も分かる

カクヨム

シンプルだが物足りない。

  • 累計PV数
  • 話ごとの累計PV数

Google Analytics を使うともっと細かく計測できるらしいが、使ってないので知らない。

小説に付与できる評価

Ans: どっちもどっち（好みが分かれると思う）

なろう

  • ブックマーク
  • ポイント(文章評価とストーリー評価)
  • 感想
  • レビュー

カクヨム

  • フォロー
  • スター(いいねボタンみたいなもん)
    • レビュー
    • 応援

スターは二種類あって、作品自体に付けるレビューと各エピソードに付ける応援がある。どちらもコメントを残すこともできる。

対比

項目 なろう カクヨム
ブックマーキング ブックマーク フォロー
いいね機能 ポイント スター
コメント 感想 応援
レビュー レビュー レビュー

だいぶ違うようで、結構似ている。一番違うのは「いいね」部分で、カクヨムは単にスターを付けるだけだが、なろうは 1-5 ポイントを振るようになっている。

目次（表示）

Ans: 両者とも大差無し。

強いて言えばなろうが中央表示で、カクヨムが左寄せ。

目次（編集）

Ans: カクヨムが使いやすい。

なろうは「この話の前に追加する」と「削除する」しかできない。

カクヨムは「このエピソードの前に追加する」と「削除する」と「並び替える」ができる。加えて、この画面で各エピソードの文字数も見えるので、全体構造を把握しやすい。

==== おわりに ====

以上、前提からして偏っているとは思うが、まとめてみた。参考になるかしら。

秀丸エディタで今開いてるファイルのディレクトリ基点でポップアップメニューを表示して一発アクセスする

つくった 秀丸エディタ AutoHotkey

結論を言うと、

  • (1)指定位置に指定ディレクトリ配下のファイル一覧をポップアップメニューで表示するプログラムを用意
  • (2)秀丸エディタマクロから 1 を呼び出す

の二段階で実現できた。

成果物

qpmenu という名前で GitHub に公開してみた。

stakiran/qpmenu: Quick file access with popup menu for Windows

(1) は AutoHotkey で作った。(2) は秀丸エディタマクロで作った。

細かいインストール方法等は上記リンクを参照。git clone(あるいは Donwload ZIP ボタンでもいいけど)による入手と、mac ファイルの適用、あと AutoHotkey のインストールがわかるならインストールできると思う。

解説

技術的じゃない部分の話。

(1) メニュー表示するプログラムについて

物好きでなければ ソフトの小物たちさんの SbFolder を使うのが無難。2000年から続いてて、窓の杜でも取り上げられる品質だし、最近の更新も 2018/05/15 Ver 3.290 と新しいし、オプションも豊富できめ細かいし、動作も軽いと素晴らしい。

(追記) SbFolder を使ったバージョンも作ってみました。

github.com

ただ私は AutoHotkey の勉強がてら、自分で書いてみることにした。

要するに (1) のプログラムは何を使ってもよい。ただし、秀丸エディタ側から呼び出すために、

  • 表示位置をスクリーン座標で指定できること
  • 基点とするフォルダパスを指定できること

上記二つをサポートしている必要がある。SbFolder はサポートしている。

(2) 秀丸エディタマクロについて

上記 AutoHotkey プログラムを呼び出す用として書いたもの。SbFolder を呼び出したい場合は、一から書き直さなきゃいけない。

技術解説 qpmenu.ahk

今回作った qpmenu のコードを解説していく。まずはメニュー表示する AutoHotkey プログラムについて。

やってることは

  • A) 表示位置(X位置とY位置)と基点フォルダパスを受け取って、
  • B) 基点フォルダパス配下をサブフォルダ含めて走査してポップアップメニューをつくり、
  • C) つくったメニューを X 位置, Y 位置に表示させて、
  • D) 選択された項目（に相当するファイルパス）を開く

という感じ。

A) オプションの受け取り

受け取りには A_Args 変数を使っている。こいつにはコマンドライン引数が入っており、

for n, param in A_Args  ; For each parameter:
{
    MsgBox Parameter number %n% is %param%.
}

上記のようにして n 番目の引数 param を取り出せる。ただこれだけだと「X位置」「Y位置」「基点フォルダパス」をわかりやすく指定できないので、qpmenu では -x 10 -y 20 "C:\work\folder" みたいな指定方法を実現できるよう、あれこれ頑張っている。最終的には args.x とか args.unclassified[1] とかで各種値を取り出せるようにした。

※A_Args 変数はバージョン 1.1.27 からのサポートなので、古い AHK だと動作しない。

B) ポップアップメニュー作成

一番苦労した部分。

全体構造はこんな感じ。

parse(menuname, list_fullpath, counter, search_dir){
  Loop, Files, %search_dir%\*, F
  {
    ; ...
    Menu, %menuname%, Add, %itemname%%EMBED_COUNTER_DELIM%%curcount%, label_open
    ; ...
  }

  Loop, Files, %search_dir%\*, D
  {
    ; ...
    Menu, %menuname%, Add, %itemname%, :%new_menuname%
    ; ...
  }
}

Loop, Files, search_dir, F で search_dir フォルダ直下のファイル名を、Loop, Files, search_dir, D で search_dir フォルダ直下のフォルダ名を取得している。ファイルの場合はメニュー項目に追加していき、フォルダの場合は parse 関数を 再帰呼び出し してサブメニューを作っていく感じ。そう、再帰呼出しだ。プログラミングっぽい。

他にも工夫点が色々あって、語り出すと長くなりそうなので割愛。もう一つだけ重要なところ、メニュー作成方法について述べておく。

メニューは Menu 命令で制御する。以下のような感じ。

  • メニュー作成(Menu Add)
    • 1ファイルにつき1メニュー項目をつくる
    • 1フォルダにつき1サブメニューをつくる
  • メニュー項目のグレーアウト(Menu Disable)
    • 空フォルダの場合は「」とだけ書かれたグレーアウト項目をつくる
  • メニュー表示(Menu Show)

色々クセがあるのだが一番厄介なのは 「各メニュー項目」と「その項目を選んだ時に実行されるファイルパス」を紐付けること だった。特に Menu の仕様が貧弱で、項目選択時に取得できるのが「選択された項目の 項目名のみ」なのが痛かった。つまり 項目名というヒントだけで、その項目に対応するファイルパスを取得しないといけない。

そのための qpmenu では 項目名 | 1 という風に、末尾に識別子の数字を付与することにした。見た目がかなりダサイが他に方法がないので致し方ない。この未熟仕様は今後改善していただきたいものだ(Menu Add 時に固有の識別子を指定できるようにすればいい)。

C) メニューを指定座標に表示

ここは(Bと比べると)比較的単純なのでコードで示す。

CoordMode Menu, Screen

; ...

posobj := determin_showpos(args)
showx := posobj.x
showy := posobj.y
Menu, %menuname_root%, Show, %showx%, %showy%

; ...

determin_showpos(args){
  ; デフォはマウス座標で, 他に指定があればそっちを使う感じに.
  pos := get_mouse_pos()

  if(is_not_empty_argument(args.x)){
    pos.x := args.x
  }
  if(is_not_empty_argument(args.y)){
    pos.y := args.y
  }

  Return pos
}

; ...

get_mouse_pos(){
  MouseGetPos, mousex, mousey

  mousepos := {}
  mousepos.x := mousex
  mousepos.y := mousey
  Return mousepos
}

長々書いたが、要するに、

  • Menu, ..., Show, %x%, %y% で 位置 (x, y) に表示できる
  • ただし座標指定をスクリーン絶対座標にするために CoordMode Menu, Screen を忘れないように！
  • マウス座標は MouseGetPos で取れる
  • qpmenu に -x とか -y とかで与えた座標は args から取ってくる(詳細解説は A を参照)

という感じ。

D) 選択された項目（に相当するファイルパス）を開く

要点は以下。

  • 選択されたメニュー項目名は A_ThisMenuItem で取れる
  • ファイルパス実行は Run, %fullpath% でいける

技術解説 qpmenu_from_hidemaru.mac

続いて秀丸エディタマクロの方。

やってること

  • (1)秀丸エディタで「今開いてるファイル」のパスを取得
  • (2)今のカーソル（キャレット）位置をスクリーン座標で取得
  • (3)1, 2 を使って qpmenu.ahk に渡すコマンドライン文字列を組み立てる
  • (4)組み立てたコマンドラインを run 文で実行

という流れ。

1 はハードコードで。

2 は xpixel キーワードと ypixel キーワード。

マクロスクリプト

$ahk_bin_path    = "C:\\Program Files\\AutoHotkey\\AutoHotkey.exe";
$qpmenu_path_ahk = currentmacrodirectory + "\\qpmenu.ahk";
$qpmenu_path_exe = currentmacrodirectory + "\\qpmenu.exe";
$qpmenu_path     = $qpmenu_path_ahk;

$DP    = "\"";
$arg_x = str(xpixel);
$arg_y = str(ypixel);
$arg_directory_of_opened_file = directory2;
$commandline = $DP + $ahk_bin_path + $DP + " " + $DP + $qpmenu_path + $DP + " -x " + $arg_x + " -y " + $arg_y + " " + $DP + $arg_directory_of_opened_file + $DP;

run $commandline;
if(result == 0){
    message "起動に失敗しました.\n> " + $commandline;
}

endmacro;

おわりに

秀丸エディタマクロを用いた連携にもだいぶ慣れてきた。どんどん便利にしていくぞい。

情報共有に Word/Excel/Powerpoint/PDF in 共有フォルダよりも Wiki を使うべき 6 の理由

Wiki ポエム

未だに WEPP(Word/Excel//Powerpoint/PDF in 共有フォルダ) が主流なのが辛い。Wiki を使った方が絶対に捗るのに。

理由1. 軽い

WEPP だと1ファイル開くだけでも10秒以上待たされることが多々ある。その上、WEPP アプリ自体が非常に重く、あれもこれも開いているとすぐに PC 全体が重たくなる。

Wiki だとブラウザでタブを開くだけなので軽い。

理由2. 検索できる

WEPP だと全文検索が出来ない。出来ないことはないが高尚なシステムが必要になるし、導入したとしても共有フォルダ上では遅いのでどのみち使い物にならない。

Wiki なら検索機能でサクっと探せる。尤も Google みたく賢くはないが、それでも無いよりは断然マシ。Wiki サーバーへのログインが許されてるならデータファイルやデータベースを直接参照して探してもいい(ちなみに Pukiwiki ならテキストファイル、Mediawiki なら DB)。

理由3. タブブラウズできる

ブラウザの優れているところはタブブラウズだと思う。複数のページをタブで開いて、自由に切り替えて読めるというインタフェースはもはや無くてはならない。これが無いとスクロールやら何やらあちこち行ったり来たりが必要で非常に読みづらい。そんなの短期記憶の優れた地頭優秀マンにしか出来ない。凡人にそんな負担を強いるのは間違っている。

Wiki はブラウザで読むからタブブラウズができる。WEPP はできない。

理由4. 更新履歴がわかる

WEPP には更新履歴は無い。Word には機能として備わっていないこともないが、使いづらいし重たい。結局「更新履歴ページ」にて表とか使って律儀にまとめていたりする。

Wiki だとデフォで更新履歴を記録してくれる。いつ、誰がどこを更新したかを追うことができる。人手でいちいち更新する必要はないし、下手な人手更新よりも読みやすく、また網羅的である(人手はしばしば抜け漏れが生じる)。

理由5. 情報発信を促せる

WEPP だと「執筆コスト」が高いので、気軽にあれこれ書こうとは思えない。

Wiki だとコストが軽いので、気軽に書ける（それでも依然として書かない人が多数派ではあるが）。気軽に書けるから情報が集まりやすい。

理由6. デザインではなくコンテンツに集中できる

WEPP ではレイアウトや装飾も自在に設定できる分、デザイン症候群（必要以上に凝って時間を無駄に使うこと）が多い。それで仕事した気になってしまう。

Wiki では最低限の文法があるだけで、基本的にコンテンツ（テキスト）そのものを書くことに集中できるので、そんな寄り道もなくなる。

==== 以下 Q & A ====

Q: それでも全ドキュメントを Wiki に移行するのは違うと思う

Ans: 同感

たとえばお客様向け資料になると「Wiki を見て」では済まない。WEPP でちゃんとしたドキュメントを整える必要がある。そこは理解している。

たとえば「管理職限定資料」みたいに閲覧者を限定すべき資料がある。Wiki ではアクセスコントロールができないので、WEPP は必要だ。

このように WEPP が有効な場面は多数ある。ただ私が言いたいのは「身内で共有する程度のドキュメントについては、WEPP じゃなくて、もっと軽い手段(Wiki)で共有すればいいじゃないの」という話。

Q: 軽さや使いやすさってそんなに重要？

Ans: 重要

ドキュメントを読むことの目的は「知りたいことを知ること」だ。あるいは「何度も読み込むことで知識として定着させること」だ。そのための負担はできるだけ少ない方がいい。

WEPP だと負担がかなり大きい。読むことに集中できない。

Wiki だと負担が小さい。WEPP よりはるかに集中できる。

「WEPP でも別に負担は大して大きくないんじゃない？」 それはただ無知なだけだ。WEPP しか知らない。Wiki を知らない。Wiki を知れば、そんな認識はひっくり返る。

Q: でも Wiki 使うのってリテラシーが必要だよね？

Ans: そうなんですよねー

業務で Wiki が流行らない理由はそこにある。リテラシーに疎い WEPP おじさんがおいそれと使いこなせる概念や代物ではない。

Q: Wiki の管理運用は誰がやるのですか？

Ans: 誰かがやる

まず Wiki サーバーの管理者が必要だが、これは WEPP における共有フォルダサーバーの管理と同じようなものなので大した苦労はないと思う。

問題は Wiki 自体の運用管理（使い方の啓蒙やトップページの整備など）。ここは誰かが頑張らないといけない。しかし、頑張りすぎるとルールだらけになって Wiki の「気軽に書ける」良さが削がれてしまう。難しい塩梅。

Q: Wiki だと複雑なテーブルレイアウトとか図表とか描けないじゃん

Ans: そもそも複雑な図表はそうは必要ないし、必要なら別ツールで描いた画像ファイルを貼ればいい

上述したデザイン症候群の可能性があるので、本当に図表が必要かを考えるといい。

もし必要だとしたら、別ツールで描いて画像ファイルに出力し、それを Wiki から表示させるのがいいだろう。

Q: オススメの Wiki は？

Ans: Wikipedia の実績がある Mediawiki が無難。

Pukiwiki は古い。メンテされてないし UI も古くて使いづらい。

Trac や Redmine は技術者寄りすぎる。IT リテラシーのない人にはハードルが高い。

Crowi は、導入できそうならしてみればいいと思う。メルカリや Yahoo を始め運用事例もちらほらあるので業務利用にも耐えうると思う。使ったことないので知らんけど。、

DokuWiki は使ったことないので知らん。

Windows の特殊フォルダ(Desktop, AppData, SendTo etc...)に関する覚え書き

Windows レジストリ

特にファイル名を指定して実行から shell:XXXXX で特殊フォルダを開けるのは地味に便利。覚えておいて損はない。

各フォルダの実体パス

レジストリにて設定されている。

  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

たとえばデスクトップフォルダは以下のように設定されており、

  • エントリ: Desktop
  • 型: REG_SZ
  • 値: C:\Users\UserHoge\Desktop

上記例だとエクスプローラーは C:\Users\UserHoge\Desktop フォルダの内容をデスクトップとして表示する。この値を変えれば、任意のフォルダをデスクトップとみなすことができる。

特殊フォルダを簡単に開く shell:XXXX

上記 Shell Folders に存在するフォルダは、ファイル名を指定して実行から shell:XXXX と打つことで開ける。

以下に例を挙げる。

  • shell:desktop でデスクトップフォルダを開く
  • shell:personal でマイドキュメントを開く
  • shell:sendto で送るフォルダを開く
  • shell:start menu でスタートメニューを開く
  • shell:recent で最近使った項目を開く

参考

foo bar baz hoge fuga piyo の違い

違い

三行で結論

  • いわゆる「ほにゃらら」を表す言葉
  • foo, bar, baz は世界的に使われている言葉で、どの国でも通じる
  • hoge, fuga, piyo は国内でのみ使われているガラパゴスな言葉で、海外には通じない

以下細かいネタが続く。

foo, bar, baz には RFC もある

foo bar baz …… は世界的にも使われている「ほにゃらら」言葉であり、なんと RFC も存在するという。

参考:

「メタ構文変数」

この「ほにゃらら言葉」は Wikipedia によると メタ構文変数 と呼ぶみたい。

CHM ファイルを HTML に変換してキーワード一覧を取り出す

CHM

Windows のヘルプファイルである CHM ファイルには「キーワード」を一覧表示する機能がある。ここに表示されてるキーワードを全部取り出したい。

結論

取り出せる。

ただし後半で Grep や正規表現の知識が必要になると思われる（無くても取り出せるが手作業地獄で大変だと思う）。

以下手順を示す。

1: HTML Help Workshop をインストールする

Download HTML Help Workshop and Documentation from Official Microsoft Download Center からインストーラーをダウンロードする。

ダウンロード後、インストーラーを叩いてインストール。

2: CHM ファイルを HTML ファイルに変換する

HTML Help Workshop を実行する。たぶん "C:\Program Files\HTML Help Workshop\hhw.exe" のはず。

実行したら以下手順で変換を実施。

  • File メニュー > Decompile を選ぶ
  • Destination folder に HTML 生成先フォルダを、Compiled help file に変換したい CHM ファイルを指定
  • OK ボタンを押す

すると、Destination folder で指定したフォルダ内に、変換された HTML ファイル等がずらりと保存されているはず。

3: キーワード一覧を取り出す

ここから大変。

hhk ファイルがあるはずなので、それをテキストエディタで開く。中身は XML でずらりと書いてあり、ここにキーワードもあるので Grep やら正規表現やらを駆使して頑張って抽出する。

hhkファイル例1: AutoHotkey

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<body>
<ul>
<li><object type="text/sitemap"><param name="Name" value="#AllowSameLineComments"><param name="Local" value="docs/commands/_AllowSameLineComments.htm"></object>
<li><object type="text/sitemap"><param name="Name" value="#ClipboardTimeout"><param name="Local" value="docs/commands/_ClipboardTimeout.htm"></object>
<li><object type="text/sitemap"><param name="Name" value="#CommentFlag"><param name="Local" value="docs/commands/_CommentFlag.htm"></object>
...

キーワードは <param name="Name" value="#AllowSameLineComments"> の #AllowSameLineComments の部分である。ここを取り出せばよい。

hhkファイル例2: 秀丸エディタ

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<HTML>
<HEAD>
<meta name="GENERATOR" content="Microsoft&reg; HTML Help Workshop 4.1">
<!-- Sitemap 1.0 -->
</HEAD><BODY>
<UL>
    <LI> <OBJECT type="text/sitemap">
        <param name="Keyword" value="ascii">
        <param name="Name" value="ascii( s1 ) 関数">
        <param name="Local" value="html/070_Function_ascii.html">
        </OBJECT>
    <LI> <OBJECT type="text/sitemap">
        <param name="Keyword" value="beep">
        <param name="Name" value="beep文">
        <param name="Local" value="html/090_MessageStatement_beep.html">
        </OBJECT>
    ...

キーワードは <param name="Keyword" value="beep"> の beep の部分である。ここを取り出せばよい。

4: 取り出したキーワード一覧から不要なキーワードを除く

この手順は不要ならしなくてもいい。

そもそもキーワード一覧を取り出す目的は「シンタックスハイライトしたいキーワードを取り出したい」だと思う。となれば、シンタックスハイライトしなくてもいいワードについては一覧から除外してやる必要がある。

例: 秀丸エディタのヘルプからキーワード一覧を取り出した場合

取り出しただけだと以下のようになった。この中にはシンタックスハイライトしなくてもいいワード(★をつけてみた)があり、これを除外する必要がある、というのが本手順だ。

ascii
beep
音               ★要らない(日本語)
サウンド         ★要らない(日本語)
break
char
columntox
restoredesktop
savedesktop
split
compfile
COMPFILE         ★要らない(重複)
比較             ★要らない(日本語)
...

さて、除外方法だが 目視しながら一つずつ頑張って消していくしかない と思う。