Amazon の Kindle 版商品ページにアクセスすると A notice to our users という画面が表示される件

f:id:stakiran:20181101074418p:plain

Firefox 63.0 で Amazon の Kindle 版書籍の商品ページ(たとえば 拙作の電子書籍 ページ)を開こうとすると「A notice to our users」と題したページが表示され、商品ページが表示されないという現象に遭遇した。

これは何?

これは「あなたが使っているブラウザは古いので、最新化してください」という Amazon の伝達事項( と思われるが後述するように最新化してもダメだったのでよくわからん

2018/11/01 07:30 現在、まだ商品ページを見れるようにする方法はわかっていません(後述しますが Amazon 側の不具合じゃないかと想像)

どういうこと?

古いブラウザには脆弱性が存在するので、Amazon では最新を使わせるようにしていると思われる。

先週は表示されなかったので、たぶんつい最近(きりがいいから 2018/11/01 から?)追加された機能だと思われる。

どうすれば元々の商品ページにアクセスできる?

どれを試してもダメだった。どういうことなの……。

方法1. ブラウザをバージョンアップする

Firefox 63.0 を、現時点の最新版である 63.0.1 に更新した。

が、A notice to our users 画面は消えてくれない。

方法2. Amazon アカウントでログイン

ログインしたら違うのかなと思ったが、効果無し。

方法3. 別のブラウザでアクセス

普段は Firefox 使いの私だが、Windows に入ってた IE11 でアクセスしてみた。効果無し。

現時点の結論

結論: とりあえず様子見する

先週までは普通に見れていたので、たぶん最近(きりの良さを考えれば 2018/11/01 から?)導入された機能だと思われる。が、ブラウザを最新化しても効果はないし、Kindle 版の商品ページは何であれこの画面が出るし、 Twitter によるとモバイル端末でも出るようだし、ググっても何の対処方法も出てこないし、で「つい最近リリースされたばかりの機能で」「Amazon 側になんか不具合がある」のではと私は想像している。

時間が経てば解決してくれるかな、と消極的に様子見しようと思う。

サポートに質問してみてもいいけど、A notice to our users ページでは英語圏の電話番号しか書いてないんだよなぁ……。

(参考) 全文の意訳

A notice to our users

ユーザーのみなさまへのお知らせ。

The browser or mobile device you use to access the internet does not support modern security standards that Amazon and others use to protect customers. To complete the entry of your payment information, please upgrade or use a different browser or mobile device to ensure that your experience on Amazon will be uninterrupted.

あなたがインターネットを見るのに使っているブラウザやモバイル端末は、最新のセキュリティをサポートしていません(≒バージョンが古いので脆弱性とかあるかもしれません)。このままだと支払い手続きするのが危ないんで、ちゃんとした(通信が途中で途切れない)ブラウザを使ってください。

To install or update a supported browser please visit any of the browsers website

サポート対象ブラウザのインストール or アップデート方法について、各ブラウザのウェブサイトを見てください。

Windows でパスの通ったディレクトリに入れておくと捗るバッチファイル

個人的によく使うものを紹介してみる。バッチファイルの中身と解説付き。

どちらかといえば「こういうふうにしてバッチファイルを適宜置いてやると便利なので参考にしてね」の意味合いが強いかもしれない。

なお「パスに通す」の意味や手順などは解説しない。

TIPS

最初に全般事項を TIPS としてまとめておく。

ファイル名を指定して実行からでも使える

パスに通したバッチファイルは「ファイル名を指定して実行」からでも使える。本記事で言えば PC ロックの lock.bat は、「ファイル名を指定して実行」から呼ぶことが多いかもしれない。

(余談) 「ファイル名を指定して実行」については拙作ですが以下にまとめてます。

日本語を echo や title で表示する時は文字コードを SJIS にする

バッチファイル(を解釈して実行するコマンドプロンプト)のデフォルトの文字コードは SJIS なので、他の文字コードで日本語を書いていると、表示時に文字化けする。

======== 汎用的なもの ========

「b」で一つ上のディレクトリに移動する(BackのB)

b.bat

@echo off
echo %cd%
echo   VVV
cd ..
echo %cd%

肝は cd .. だけだが、移動前後がわかるように echo で出力している。ここは好みか。

「qq」で今開いているコマンドプロンプトを終了する

qq.bat

@echo off
exit

単に exit するだけだが、exit やら quit と打つよりも圧倒的に速いのでオススメ。

「pp」でプロンプトを「$ 」にする

pp.bat

@echo off
rem my favorite prompt
prompt $$ 

これは完全に私の好みだが、デフォルトのプロンプトは長くて気に入らない。

C:\Users\stakiran> ipconfig /all
^^^^^^^^^^^^^^^^^
ここが長くて気に入らない

私は短い表示の以下が好き。

$ ipconfig /all
^
たった一文字。短い。

「here」でカレントディレクトリをエクスプローラーで開く

here.bat

@echo off
explorer .

「lock N」で N 秒後に PC をロックする

lock.bat

@echo off
set n=%1
title %n%秒後にロック
timeout /T %n% /nobreak
rundll32 user32.dll,LockWorkStation

timeout コマンドは指定秒数だけ待つコマンド。/nobreak はキーを押しても復帰しないオプション。これ入れないと、うっかりキー押しちゃった時に timeout による待ちが終了してしまうすぐロックに入ってしまう。

rundll32 user32.dll,LockWorkStation はおまじない。user32.dll という Windows に備わってるデフォの DLL ファイルに、LockWorkStation という機能(関数)があって、それを呼び出している。

======== Git/GitHub 系 ========

「save メッセージ」でカレントディレクトリの変更を Git コミットする

save.bat

@echo off
setlocal
set /p commitmsg="input your commit message>"
if "%commitmsg%"=="" (
    echo A commit message is required.
    exit /b
)
pushd %cd%
echo saving...
git add -A
git commit -m "%commitmsg%"
popd

特にひとり Git や GitHub している場合、コミットは適当でいいのでなるべく端折りたい。私は save.bat を配置して save コマンドにて実現させた。以下解説。

setlocal は呼び出し元の環境変数を汚染しないための指定。「ここで環境変数定義しても、それはここのローカル限定ですよ」の意。

set /p で入力プロンプトを出しつつ入力を受け付ける。

で、pushd でカレントディレクトリに移ってから git コマンドを叩く。最後に popd でディレクトリを戻す。pushd と popd のくだりはややこしいが、

  • (1) save.bat のあるディレクトリ
  • (2) save.bat の呼び出し元ディレクトリ(カレントディレクトリ)

と、ディレクトリが二つあって、何もしないと (1) 基準で進んでしまうので、明示的に (2) にしているという意図がある。このように「カレントディレクトリはどこなのか、を明示的に指定してやる」と、バッチファイルの呼び出し時にハマりづらくなる。

「glog」でカレントディレクトリの Git ログを TortoiseGit ログダイアログで開く

glog.bat

@echo off
start "" "C:\Program Files\TortoiseGit\bin\TortoiseGitProc.exe" prm=/command:log /path:"%cd%"

======== REST API 系 ========

「token」で GitHub の Personal Access Token をセットする

token.bat

@echo off
set PERSONAL_ACCESS_TOKEN=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

REST API を叩くスクリプトを使う前に実行する。

もちろんトークン情報はプライベート情報なので扱いに注意すること。たとえば「俺が考えた最強の "パスに通しておきたいバッチファイル"」リポジトリをつくって、うっかりトークンを書いた token.bat をプッシュしちゃう、なんてことのないように。

余談だが、AWS で不正アクセス食らって請求を食らう件のトラブルは、大半がトークン(AWS用語でいうとアクセスキー)情報をプッシュしちゃったことが原因である。

「proxy」で今設定している HTTP_PROXY などを見る

proxy.bat

@echo off
echo Result of "set | findstr HTTP"
set | findstr HTTP

set コマンドは(本来は環境変数を設定するコマンドだが何も指定しないと)環境変数を一覧表示する。findstr は UNIX でいう grep。

「proxy1」でプロキシ設定1 を HTTP_PROXY などに設定する

proxy1.bat

@echo off
set HTTP_PROXY=http://(PROXY-SERVER-IP):(PROXY-SERVER-PORT)
set HTTPS_PROXY=https://(PROXY-SERVER-IP):(PROXY-SERVER-PORT)

proxy1 の名前は適宜工夫する。設定個数が少ないなら proxy1 とか proxy2 でも覚えられると思う。「proxy」という単語が打ちづらくて気に入らないなら「p1」とか「p2」でもいいかもしれない。

「proxyoff」でプロキシ設定をクリアする(HTTP_PROXY などをクリア)

proxyoff.bat

@echo off
set HTTP_PROXY=
set HTTPS_PROXY=

======== その他系 ========

「cm」でディレクトリブックマークツールを使う

cm.bat

すいません拙作ツールです。バッチファイル中身は長いので載せません。 GitHub へのリンクだけ。ちなみに 130L くらい。あと ブックマーク情報を cm.bat と同じディレクトリ内に txt で保存する こともご了承ください。

ちなみにこのツールは bashmarks に触発されてつくりました。

「hide」で指定ファイルを秀丸エディタで開く

hide.bat

@echo off
pushd %cd%
start "" "C:\Program Files\Hidemaru\HIDEMARU.EXE" %*
popd

まず秀丸エディタ(に限らずテキストエディタ全般)は、引数としてファイルパスを与えるとそのファイルを開くようになっているので、これを利用する。

pushd については「今開いているコンソールをカレントディレクトリにする」ために必要。というのも、これをしなければ「カレントディレクトリ = hide.batのあるディレクトリ」となってしまい、前者のディレクトリを指さないため、相対的にファイルパスを指定した時に見つけられなくなる。

start を使っているのは、ノンブロッキングで実行するため。これを単に "C:\Program Files\Hidemaru\HIDEMARU.EXE" %* としちゃうと、秀丸エディタを終了するまでこの DOS 窓が閉じられないため煩わしい。

最後の popd はおまじない。呼び出し先のバッチでカレントディレクトリを変えた時は、最後に popd でもとに戻すことを心がけておくとハマらない。

おわりに

コマンドプロンプトを使う機会が多い方は、このやり方で色々カスタマイズすると便利になるのでぜひお試しを。

他にもオススメのバッチファイルなどあれば教えて下さい!

TortoiseGit のログメッセージダイアログでデフォルトの表示期間を絞る

設定でデフォルトの表示期間を絞るか、コマンドライン引数で範囲指定するか。

前提

  • TortoiseGit v2.7.0

方法1. 設定でデフォルトの表示期間を絞る

Settings > General > Dialogs 1

Log messages というグループボックス内の Default Limitation of log messages のドロップダウンメニュー

選択肢として以下がある。

  • No limitation(全範囲)
  • Last selected date(前回選択した範囲)
  • Last N Commit(s)
  • Last N year(s)
  • Last N week(s)

何もいじってなければ一番上の No limitation になっているが、これだとコミット数が多い場合にダイアログ表示が重たい。適宜変えると良い。

参考: How to set the default dates range in TortoiseGit log dialog? - Stack Overflow

方法2. コマンドライン引数で表示範囲を絞る

まず指定ディレクトリにある Git ローカルリポジトリのログダイアログを開くコマンドラインは以下のとおり。

"C:\Program Files\TortoiseGit\bin\TortoiseGitProc.exe" prm=/command:log /path:"指定ディレクトリ"

続いて、直近の N を取得する系のオプションは以下のとおり。

/limit:"N Commit"
/limit:"N Year"
/limit:"N Month"
/limit:"N Week"

たとえば直近 10 件のコミットを表示したい場合は、以下のとおり。

"C:\Program Files\TortoiseGit\bin\TortoiseGitProc.exe" prm=/command:log /path:"指定ディレクトリ" /limit:"10 Commit"

方法1と方法2が混ざった時の挙動

直感的な挙動だが、一応書いておく。

  • Case1: 方法2(コマンドライン引数による指定)で、/limit オプションを指定しない

→ 方法1 で設定したデフォルトの範囲が使われる

  • Case2: 方法2(コマンドライン引数による指定)で、/limit オプションを指定する

→ 方法1 で設定したデフォルトの範囲は無視され、/limit オプションで指定した範囲が使われる

おわりに

TortoiseGit のログダイアログは本当に見やすいが、常に全件表示するのが(特にコミット数が多いリポジトリだと)いまいちだった。が、これで表示範囲を絞れるので、快適になった。

Slack など業務チャットの運用で物申したいこと

職場で Slack によるチャットコミュニケーションが活発化してきたけど、運用面で不満があるので言語化しておく。

雑談や宣伝を Mention (@channel など)で投稿しないでほしい

Mention は言わば口頭で話しかけて割り込む行為に等しい。Mention が許されるのは 割り込んでも仕方ない時 だけだ。

にもかかわらず、「~~というニュースが面白かった」だの「~~の部署で~~になったみたいよ」だの「10日は兼ねての通り役員の~~さんが来訪されます」だの、それ割り込んでまで言うこと? というメッセージがしばしば @channel やら @here やらで Mention されてくる。これはたとえるなら、仕事している人に対して肩をたたいて「ねぇねぇ、~~というニュースが面白かったんだよ」などと言うようなもの。正直言ってウザくないですか。

仕事は集中して取り組むことが大事だ。メールにせよチャットにせよ電話にせよ口頭にせよ、割り込まれるのは望ましくない。Mention という行為は、Mention された側に通知が行くため、れっきとした割り込みになる。

  • Q: 「じゃあ通知を切ればいいじゃないか」
    • Ans: ダメ。割り込み自体は時には必要なので、割り込まれたことに気付くために必要である(通知を切ってると緊急のメッセージを送られても気付けない)。通知を切ることは、耳栓をして声掛けをシャットアウトし、また肩叩かれても無視する行為に等しい。
  • Q: 「チャンネル毎に通知やらミュートやらは制御できるので、うざいチャンネルだけ切ればいいのでは?」
    • Ans: それで済むならそうしたいところだが、 一つのチャンネルにはたいてい重要なネタとどうでもいいネタ(ノイズ)が混在する。切ってしまうと、前者も見逃してしまうことになる
  • Q: 「通知が来ても、通知ダイアログの内容を読んで "あとでいいや" と判断すればいいだけなので大した手間ではないと思うけど」
    • Ans: 手間でいうとそうだが、問題の本質は集中自体が邪魔されることだ。たとえば将棋のプロ棋士が大局で集中して読んでいる最中に、肩を叩かれて割り込まれたら、と考えてほしい。たとえ1秒で済んだとしても邪魔なはずだ。肩を叩かれること自体が問題なのだ。

アバターを入れてほしい

アバターがあるとメッセージの主を視覚的に一瞬で判断できる。文字を読むよりも断然速い。チャットでは膨大な量のメッセージを読むこともあるので、読むのに要する負担はできるだけ減らしたい。アバターはその役に立つ。

別に顔写真である必要はないので、その人であることがわかるようなアバターを何でもいいから入れてほしい。

その人であることが一意にわかるアバターを入れてほしい

繰り返しになるが、業務用チャットにおける アバターの意義は、その人であることが視覚的に一目でわかる ことだと私は思っている。なので何でもいいからといって、判別しづらいアバターは控えてほしいところ。

よくあるのが、仲間意識なのか複数人で同じロゴをアバターにするケース。たとえば同じロゴを設定した人が 5 人いたら、アバターを見ただけでは 5 人の誰かまではわからない。結局名前という文字列まで見ないといけない。

名前はローマ字で統一してほしい

まず名前の 書き方(フォーマット)は統一してほしい。人によって山田太郎だったり太郎山田だったり山田たろうだったりヤマダタロウだったり YAMADA TAROU だったり Taro Yamada だったり tarou yamada だったりする。見づらいったらありゃしない。ただでさえアバターのせいで判別コストが高いのに、名前のせいでさらに高くなってしまっている。

また、名前は出来れば ローマ字で記述してほしい。検索しやすいから だ。「漢字の方が視認性が高い」という意見もあるが、 視認性はアバターでわかる ので、私は打ちやすいローマ字が良い派。ここは好みだろう。

リアクションしてほしい

「了解しました」「読みました」というリアクションがほしい。でないと読んだかどうかがわからない。

仕事は段取りが大事だ。読んだかどうかがわからなければ、「読みました?」と尋ねることになる。尋ねずに進んでもいいが、たまに「まだ読んでないんだけど」と食い違いが起きることがある。いちいち口頭で尋ねていてはチャットの意味がない。

チャットの意義は、(リアルタイムに話し合っているのでなければ)お互いが自分のペースで仕事を進められることにある。そのためには、相手が自分でペースで進められるように、自分のボールを相手に返すことが重要。つまりはメッセージに対する反応である。

私としては「反応が無い=了承した」で良いとも思っているが、この運用はたまに「読んでないんだけど」と衝突が生じる。特に忙しい管理職に顕著。彼らは少しでも楽をしたいがために、こういうところにまで気が回らないし手も回らない。そのくせ、お偉いさんのどうでもいい雑談コメントにはリアクションしていたりする。

リアクションした後で「了解しました」は要らないと思う

二重。無駄。

たぶん「リアクションだけでは失礼ではないか」という意識があるのだろうが、チャットはもっとフランクに使って良いと思う。

ただし、(リアルタイムにコミュニケーションを進めている最中に)了解したことを相手にすぐに伝えたい場合は、Mention を付けて「了解しました」と書くこともある。リアクションしたことを通知させるためだ。これは私もよく使う。

使うルールになったんだからログインしてほしい

一部の使わない勢(主にリテラシー無い人や毎回「この雑務対応早くして」と怒られてる人)のせいで、結局メールでも知らせたり、口頭で知らせたりといった手間が生じている。

面倒くさいことこの上ない。使うルールになったんだからログインしてくれ。使い方わからないなら調べて。訊いて。

私としてはメールや口頭でも知らせるというお世話を廃止する、くらいしても良いと思う。怠け者のせいでこちらが負担を負うのはばかばかしい。

管理人はある程度詳しい人にしてほしい

ワークスペースの管理者が詳しくない人だと、「REST API 使いたいんすけど」 → 「(よーわからんから)ダメ」 が起きる。あるいは 「理由は何?」 → 「ちょっと試したい、触ってみたい」 → 「業務で明確に必要という理由がないとダメ」 というお堅い反応が返ってくる。

CRUD のうち CUD する権限であれば、まあわかる。下手なことすれば実害が出るから。でも Read するだけ、たとえばパブリックチャンネルを Read するだけのトークンくらいなら、許可してくれてもいいんじゃないか。ちょっと試してみるのもダメ?色々触って遊んでみたり試したりするもんでしょ、エンジニアなんだから。そうやって得られるものもある。つくられるものもある。Read だけなら実害は無い。

  • Q: API で取ったデータを悪用するとも限らないでしょ?
    • Ans: それ言っちゃキリないでしょ。手動コピペでもできるじゃん。API 使おうとすると性悪説になるの、なんで?
  • Q: Slack が落ちたらどうすんねん
    • Ans: 落ちません。Rate Limit などの仕組みが入ってます。
  • Q: プライベートでひとり Slack で試せば?
    • Ans: 会社は勉強の機会でもあると思っているので、そういう機会を潰す真似はイヤだなぁ。それに仕事で使ってるパブリックチャンネルに対して実行してみることにこそ意味がある。プライベートで数件投稿しただけでのチャンネルで実験するのと、色んな会話が既になされている会社のチャンネルで試してみるのとでは、意味合いが違うでしょ。
  • Q: そんな暇ないだろ。仕事しろよ?
    • Ans: してます。暇ではないです、学習の時間です。タスク管理をしてイエスマンから脱却すれば、できますよ。 イエスマン言いなりの社畜でタスク管理すらしらない残業当たり前マンと一緒にしないでください

これは一例に過ぎない。管理者が詳しくないと、すぐに一蹴される。一応反論もするが、まあ反論も一蹴されちゃうね。そして反感を買って、目をつけられる。

せっかく良いシステム使ってるのに、管理人の都合で束縛されるの、ほんともったいない。

おわりに

以上、宗教論や好みもあるだろうが、私の思いを書いてみた。

Slack で日記を書く Slack 日記のすすめ

Slack 日記 とはその名のとおり、Slack で日記を書くこと。

f:id:stakiran:20181026213012j:plain

Slack は本来チャットツールだが、その書きやすさと遊び心は日記を書いたり読み返したりすることにも適している。

本記事では Slack で日記を書くことのメリット、手順、所感などについてまとめる。

  • Slack とは
    • ワークスペース
    • チャンネル
    • メッセージ
    • 参考
  • Slack で日記を書くことのメリット
    • ブラウザさえあればどこからでも書ける
    • ファイル管理に頭を悩まさなくていい
    • 画像挿入も簡単
    • 絵文字が使える
    • 検索できる
  • Slack 日記でできないこと
    • カレンダー
    • カテゴリ・タグ
    • インターネットへの公開
    • 他ブログ形式へのエクスポート
  • Slack 日記をはじめる ~アカウント作成~
  • Slack 日記をはじめる ~日記の書き方~
    • (1) チャンネルの作成
    • (2) 日記の書き込み
  • Slack 日記をはじめる ~日記の読み方~
    • (1) チャンネル一覧から辿る
    • (2) カレンダーから巡る
    • (3) 検索から探す
  • Slack 日記をはじめる ~日記の整理~
    • サイドバーからチャンネルを非表示にする
    • 非表示にしたチャンネルをサイドバーに表示する
    • 現在月のチャンネルを一番上に表示したい
    • チャンネル一覧の表示順を思い通りに制御したい
  • Slack 日記をはじめる ~おわりに~
  • 雑多なトピック
    • 有料プランについて
    • バックアップ(エクスポート)について
      • (1) Slack の機能を使う
      • (2) 外部ツールを使う
    • 既存の Slack ワークスペースで Slack 日記を始めるには
    • #general チャンネルを非表示にしたい
  • おわりに
続きを読む

Slack のエクスポートについて種類や仕様やフォーマットについて簡単にまとめてみた

エクスポートは二種類ある。

Standard Export と Corporate Export。

Standard Export

「ワークスペース管理者 or オーナー」が「すべてのパブリックチャンネル」について「指定期間に」投稿されたメッセージすべてを json 形式でエクスポートする機能。

期間について以下選択肢がある。

  • 直近1日以内
  • 直近1週間以内
  • 直近1月(30日)以内
  • 全期間
  • 指定期間(startとendをカレンダーで指定)

エクスポートを実行すると Slack 側にリクエストが送信され、ダウンロード準備が整うと案内がメールや通知が来る。案内に従って URL を開くと、エクスポート画面が開いて、ダウンロード可能なリンクが載っている。

ディレクトリ構造

$ cd
D:\download\(ユーザー名) Slack export (期間名)

$ tree /f
│  channels.json
│  integration_logs.json
│  users.json
│  
├─public_channel_01
├─public_channel_02
│      2018-10-24.json
│      
├─public_channel_03
├─public_channel_04
│      2018-10-23.json
│      2018-10-24.json
│      
...

channels.json

各パブリックチャンネルの設定情報。ユーザー名は ID で記述されている。

[
    {
        "id": "XXXXXXXXX",
        "name": "public_channel_01",
        "created": "XXXXXXXXXX",
        "creator": "U4499TRLM",
        "is_archived": false,
        "is_general": false,
        "members": [
            "U4499TRLM"
        ],
        "topic": {
            "value": "",
            "creator": "",
            "last_set": "0"
        },
        "purpose": {
            "value": "",
            "creator": "",
            "last_set": "0"
        }
    },
    ...
]

integration_logs.json

Slack の連携機能を使っている場合は、その情報。

たとえば以下は Email 連携(Gmail で受信したメールを指定チャンネルにも流す等) を行っているので、その分の設定が書いてある。

[
    {
        "user_id": "U4499TRLM",
        "user_name": "stakiran",
        "date": "XXXXXXXXX",
        "change_type": "updated",
        "service_id": "XXXXXXXXXXXX",
        "service_type": "Email",
        "scope": "incoming-webhook",
        "channel": "C8RQL22SW"
    },
    ...
]

users.json

ワークスペースに参加するユーザー情報。

[
    {
        "id": "U4499TRLM",
        "team_id": "T44T06U8P",
        "name": "stakiran",
        "deleted": false,
        "color": "XXXXXX",
        "real_name": "XXXX XXXX",
        "tz": "Asia\/Tokyo",
        "tz_label": "Japan Standard Time",
        "tz_offset": 32400,
        "profile": {
            "title": "",
            "phone": "",
            "skype": "",
            ...
        },
        "is_admin": true,
        "is_owner": true,
        "is_primary_owner": true,
        "is_restricted": false,
        "is_ultra_restricted": false,
        "is_bot": false,
        "is_app_user": false,
        "updated": XXXXXXXXXX
    },
    ...
]

YYYY-MM-DD.json の中身

1メッセージ1オブジェクト、が配列で並んでいる感じ。

細かい中身はメッセージ内容によってだいぶ違う。下記は連携で Twitter の検索結果を流しているので、bot_message などと表記されている。これが普通のメッセージだと "text" 欄にデータが入っていたりする。

[
    {
        "username": "IFTTT",
        "icons": {
            ...
        },
        "attachments": [
            {
                "title": "XXXXXXXX",
                ...
            }
        ],
        ...
        "text": null,
        "type": "message",
        "subtype": "bot_message",
        "ts": "XXXXXXXXXX.XXXXXX"
    },
    ...
]

Corporate Export

プライベートチャンネルやダイレクトメッセージなど「関係者しか見れないプライベートなデータ」を「ワークスペースのオーナー」が「やむを得ない事情で取得したい」場合に使えるエクスポート機能。

やむを得ない事情とは何だと思うが、Slack のインポート/エクスポートの手段 – Slack から一部引用すると、

企業がハラスメントや企業秘密の盗難の報告を受け、職場での調査を行う必要がある場合。

特定の通信内容の一定期間における記録保管が規制により義務付けられている金融サービス企業。

訴訟や捜査により、裁判所命令で Slack の情報を開示しなければならない場合。

出番は限られそうである。

ちなみに Corporate Export エクスポート時に Slack 側への申請 が必要となる。無条件にエクスポートできるわけではない。

どちらを使うべき?

私はひとり Slack をしているので、

stakiran.hatenablog.com

Standard Export で十分。

AutoHotkey の Hotstrings(ホットストリング) はクリップボードを使うと動作が安定する

AutoHotkey には PhraseExpress や TextExpander のように「省略語を入力した直後に、対応する文字列を即挿入する」機能がある。Hotstrings(ホットストリング) と呼ぶ。

普通に書くと、ホットストリングは「1文字ずつ挿入する」挙動になるが、この挙動だとたまに問題が起きることがある。

Before

#Hotstring *
#Hotstring O
::m@@::mailaddress@mail.address.com

上記の場合、m@@ と打つと、m@@ の三文字が消去された後、mai → ……と、対応するメールアドレスが一文字ずつ高速で挿入されていく。

ただし、これだと問題が起きることがある。たとえば日本語入力モードがオンの時は「まいぁっdれっs@まいl.あっdれっs.こm」となってしまう。

また、挿入文字列が長い場合は、挿入し終えるまでに時間がかかる。極端な例を出すが、1文字0.1秒で挿入するとしても、20文字あれば2秒かかってしまう。

そんな時は クリップボード経由で貼り付ける と動作が安定する。

After

以下のように書く。

#Hotstring *
#Hotstring O
::m@@::
    Clipboard = mailaddress@mail.address.com
    Send,^v
return

上記の場合、m@@ と打つと、m@@ の三文字が消去された後、mailaddress@mail.address.com という文字列が一気に挿入される。日本語入力モードがオンでも関係がない。

これは、一文字ずつ挿入しているのではなく「挿入したい "mailaddress@mail.address.com" という文字列をクリップボードにコピーして」「Ctrl + V で貼り付ける」という操作を行っているためだ。文字列がなんであろうと、どれだけ長かろうと、一気に貼り付ける。

注意点

しかし、このクリップボード経由で挿入するやり方にも問題、というかクセがある。

  • 既にクリップボードに存在していたデータが上書きされる
  • Ctrl + V が効かない入力フィールド上では入力できない
  • .ahk ファイルに記述するのが面倒くさい(3行分多い)

とはいえ、1文字ずつ挿入するよりも動作が安定してストレスが少ないので、悩んでいる方は試されたい。

使い所

色んな場面でよく使う文字列については、このクリップボード経由のやり方が良いのではないかと思う。個人的には、

  • 自分のアカウント名
  • 現在日付時刻

の二つについて、このクリップボード経由のやり方を採用している。日本語入力モードにかかわらず、安定してサクっと挿入できるのでストレスが無い。

ローカルに置いた MDwiki を Internet Explorer でも読めるようにする

前提

  • MDwiki v0.6.2
  • IE11

コード

mdwiki.html の以下部分について、

<!-- START dist/MDwiki.js -->
<script type="text/javascript">;(function() {

/**
 * Block-Level Grammar
 */

var block = {
  newline: /^\n+/,
  code: /^( {4}[^\n]+\n*)+/,
  fences: noop,
  hr: /^( *[-*_]){3,} *(?:\n+|$)/,
  heading: /^ *(#{1,6}) *([^\n]+?) *#* *(?:\n+|$)/,
  ...

ローカル(file:///)上で外部ファイル読み込みのセキュリティ制約を回避するいくつかの方法 - Qiita の IE11 の部分を参考に、以下のように埋める。

<!-- START dist/MDwiki.js -->
<script type="text/javascript">;(function() {

/* ★★★ 追加した ★★★ */
$.ajaxSetup({
  xhr: function() {
    try {
      return new ActiveXObject("Microsoft.XMLHTTP");
    } catch (e) {
      return new XMLHttpRequest();
    }
  }
});
/* ★★★ 追加した ★★★ */

/**
 * Block-Level Grammar
 */

var block = {
  newline: /^\n+/,
  code: /^( {4}[^\n]+\n*)+/,
  fences: noop,
  hr: /^( *[-*_]){3,} *(?:\n+|$)/,
  heading: /^ *(#{1,6}) *([^\n]+?) *#* *(?:\n+|$)/,

FAQ

Q: IE11 以外の IE ではどうやるの?

上記 Qiita に書いてある。ここでは紹介しない。

Q: なぜこれで IE でも読めるようになる?

IE は「ローカルから外部ファイルを読み込む」動作を禁止している。セキュリティのためだ。

これをしておかないと、「外部に置いた有害な javascript ファイル」を読み込む HTML ファイルが、これ一つでウイルスとなってしまう。なにせ HTML ファイルを開いた時点で、有害な javascript ファイルが読み込まれ実行されてしまうからだ。こういう事態を防ぐために ローカルから外部ファイルを読みに行く動作自体を禁止してしまおう となっている。

で、MDwiki では xxxx.md にアクセスした際に、その内容を動的にパースして HTML に変換して表示する、という処理を行っているのだが、この「xxxx.md の内容を取得する」ときに、外部ファイルを読み込む処理を使っている。もっというと XMLHttpRequest()。

幸いにも IE には Microsoft.XMLHTTP という「IE でしか使えない "外部ファイルを読み込む処理"」があり、こちららについては上記の制約が無い(ActiveX を使っているので ActiveX の設定として禁止してたら結局使えないが、IE 使う環境なら ActiveX も有効になっていると思われるので結果的に使える)。

Q: 読めないけど?(共有フォルダに置いている)

私の環境では、UNC パスの場合は読めなかった。ローカルにコピーすれば読めた。

どうやれば読めるようになるのだろう?MSDN の About Native XMLHTTP (Internet Explorer) を見た限り、インターネットオプションのセキュリティを工夫すればいけそうな気がしないでもないが、閲覧者側に設定変更を要求するのは優しくない。

ESLint で Javascript ソースファイルのタブ幅をコマンドでサクっと直す

ポイントは二つ。

  • .eslintrc.json にタブ幅のルールを書いておく
  • eslint --fix hoge.js で hoge.js を、ルールに従って修正する

.eslintrc.json

以下はタブ幅は 4 以外はエラーにするよ、というルールのみを記述した例。

{
    "rules": {
        "indent": [
            "error",
            4
        ]
    }
}

ルールを適用するコマンド

hoge.js に対してルールを自動適用(破壊的修正)したければ、

$ eslint --fix hoge.js

を実行する。

Excel VBA の RoundUp() と Javascript の Math.ceil() は負の値の切り上げ方が違う

VBA 製の計算ツールを Web アプリ化している時に、切り上げの部分で少しハマったのでメモ。

結論

  • -1.01 を切り上げたらどうなる?」に対する解は二通りある
    • 解1: -2 負の方向に切り上げる
    • 解2: -1 正の方向に切り上げる
  • VBA の Application.WorksheetFunction.RoundUp(-1.01, 0)-2 を返す
  • Javascript の Math.ceil(-1.01)-1 を返す

当たり前に使っている数学関数も、言語(実装)が違うと挙動が違ってくることがあるので、ちゃんと確かめてから使いましょう。

ハマったこと

(1) VBA で Application.WorksheetFunction.RoundUp(x, 0) を部分を、「切り上げは Javascript では Math.ceil(x) だよね」と捉えて実装した。

(2) 実装した関数やクラスは、Unittest を適宜通していたが、「負の値を切り上げる」パターンはテストしてなかった。

(3) 画面レベルのテストの時に「なんか結果が微妙に合わない」現象に遭遇。

で、デバッガで辿ってみると、切り上げの部分で -1 と -2 の違いが出てましたとさ。

で、切り上げ方向はどっちが正しいの?

Ans: わかりません

先人

同じようにハマった方がいらっしゃいました。

おわりに

Ceiling の挙動の違いについてメモしたかっただけなので、テスト方法がどうこう等はこれ以上議論しない。

それにしても切り上げ方向の絶対的な正解は無さそうだし、もう少し調べていると銀行丸めだのなんだの、と意外と罠が多い印象も受けたので、うん、どうすればいいんだろこれ。とりあえず今回は「VBA 製ツールと同じ結果を返す」が要件だったので、Javascript 側では Math.ceil() のラッパー関数(与えられた数 v が負の時は return Math.ceil(v) - 1 をする)を作って対処した。

「ファイル名を指定して実行」の本を書きました

「ファイル名を指定して実行」のすべて という本を書きました。電子書籍です。

f:id:stakiran:20181014082641j:plain

内容紹介や思いを語らせてください。後半はただの日記です。

どんな本か?

Windows の「ファイル名を指定して実行」について、とことん掘り下げました。内容としては、

  • 「ファイル名を指定して実行」の基本的な使い方
  • 「ファイル名を指定して実行」を使うと何が嬉しいのか
  • 「ファイル名を指定して実行」から実行できるファイル名たち
  • 「ファイル名を指定して実行」に好きな名前で好きなファイルを登録する方法
  • 「ファイル名を指定して実行」の履歴に関する詳細(有効無効切り替え、履歴削除、履歴データ構造詳細など)

などを盛り込んでおり、「ファイル名を指定して実行」を知らない初心者の方から、「普通に多用してますけど」という上級者の方まで幅広く対象にしております。

初心者の方は「ファイル名を指定して実行」を使って、アプリケーションや機能を素早く呼び出せるようになります。また、Windows の知識や用語解説も(ノイズにならない程度に少し)差し込んでいるので、併せて読んでいただけると理解がいっそう深まり、Windows に対するハードルが下がると考えております。

中上級者の方は「ファイル名を指定して実行」に関して、新たな発見があるかもしれません。「そんなコマンドがあるんだ」とか「そんな仕組みになっているんだ」など、何かしら出会えたら幸いです。あるいは読み物として、「ファイル名を指定して実行」好きの一人がどこまで追求できているかを興味本位で覗いてもらっても大歓迎です。

なぜ書こうと思ったか

元々「ファイル名を指定して実行」が好きで、後輩に啓蒙したり、Qiita に 「ファイル名を指定して実行」を極める という記事を書くほどでした。

ちょうど最近、電子書籍を書きたくて、まずは何か手頃なネタで書いてみようと Qiitaの過去ネタ をあさっていたところ、上記記事を思い出し、「せっかくだから有料コンテンツとしてどこまで仕上げられるか挑戦してみよう」という気になりました。

執筆手段

詳しくは Markdown ベースで KDP に電子書籍を出版してみた - stamemo にてまとめていますが、簡単にまとめると以下のとおりです。

私は Markdown + テキストエディタが大好きで、Word などを使うことは考えていなかったのですが、幸いにもでんでんコンバーターという手段があったのには助かりました。epub 変換は、自力でやると Pandoc あたりを用いることになるのでしょうが、自前で変換するのは何かと大変そうで、今回「とりあえず何か出版してみたい」を満たす上で障壁になりそうだったので控えました。

執筆期間とその中身

おおよそ 2018/10/03(水) ~ 2018/10/13(土) の 10 日間です。

まず予備調査として 2018/10/01 に 2 時間ほど電子書籍の出版方法について調べ、メジャーで手続きも簡単な KDP で出版してみようと決めました。

2018/10/03 の朝に早速読者層や目次を練り始め、余暇時間の大半を使って書き上げていきました。元ネタ記事 「ファイル名を指定して実行」を極める こそありますが、ほぼ全面的に書き直しました。また、Qiita 記事とは違い、初心者の方も対象に含めていたので、解説を丁寧に行うよう注意しながら進めました。

執筆ですが、休日はポモドーロテクニックを使ってほぼ費やしてました。ある日のタスク管理ログは以下のようになっています。

4 2018/10/06 Sat 07:16 07:50 a run
4 2018/10/06 Sat 07:50 07:50 XXXXXXXX
4 2018/10/06 Sat 07:50 08:19 XXXXXXXX
4 2018/10/06 Sat 08:19 09:57 b run
4 2018/10/06 Sat 09:57 10:18 b XXXXXXXX
4 2018/10/06 Sat 10:18 10:49 b run
4 2018/10/06 Sat 10:49 12:25 XXXXXXXX
4 2018/10/06 Sat 12:25 12:25 XXXXXXXX
4 2018/10/06 Sat 12:25 12:25 XXXXXXXX
4 2018/10/06 Sat 12:28 12:59 d run
4 2018/10/06 Sat 12:59 13:08 XXXXXXXX
4 2018/10/06 Sat 13:08 13:46 d run
4 2018/10/06 Sat 13:46 14:04 XXXXXXXX
4 2018/10/06 Sat 14:04 14:35 d run
……

XXXXXXXX は伏せてますが休憩として家事や食事などを差し込んだものです。30分のポモドーロで書いて、休んで、また30分セットして……というサイクルをひたすら繰り返していました。たぶんフロー体験も出来てたと思います。久しぶりに充実した休日でしたね。

一通り原稿が仕上がって、見栄えや校正に入ったのが 2018/10/10 です。ここからはでんでんコンバーターにアップロードして、出来た epub をダウンロードして、Kindle Previewer で読み込ませて……の繰り返しでした。今、作業フォルダの残骸を見ると epub ファイルは 59 個ありました。

校正や推敲は、何度やってもきりがなくて、泥沼にハマる感覚でしたかね。ここで折れても仕方ないので、「これならまあ大丈夫だろう」と思えたラインで出版に踏み切りました。それが 2018/10/13 の夜です。

日付が変わる前に出版完了して、翌日朝調べてみたら、無事出版されてました。

お値段

出版に際し、最も頭を悩ませるのがお値段らしいのですが、私はあまり迷いませんでした。

  • まずは軽めの本を一冊出してみたい
  • 100ページくらいだし、印税が1冊約100円でわかりやすいから 300円 でいいか

という具合に決めました。

ふと「最初から無料とか1円とかでもいいのでは」と思いもしましたが、無料を言い訳に手抜きをしたくはなかったんで、300円に見合ったコンテンツをきちんと書くという意味でも、300円にしました。

ちなみに、これ以上の値段(たとえば1冊200円が入る600円、1冊300円が入る900円)は、ボリュームと内容的に不適当だろうと考えて採用しませんでした。大半はネットで調べればわかりますし、上級者や本職の方なら自分で手を動かしたり、あるいは Microsoft の技術サイトを読めばわかることです。ボリュームは、だいぶ頑張ったのですが、100 ページ超えたくらいですね。しかも設定手順などの画像が多少あるので、文章だけで言えば 70 ページくらいでしょう。頑張れば Qiita の長文記事として書けなくもないレベルです。

そんなわけで、300円です。

反響

カテゴリが誤っているのと、まだまだ宣伝不足なのもありますが、レポートを見たら購入が付いていました。買っていただいた方、本当にありがとうございます。

反響はもっと知りたいので、もう少し宣伝していこうと思います。本記事もその一環です。もちろん、宣伝ばかりしていては煩わしいので、本ブログや Twitter ではこのくらいにして、あとは別の方法を考えます。何か良い手段はないでしょうかねぇ。

おわりに

というわけで、初電子書籍の執筆&出版日記でした。

Markdown ベースで KDP に電子書籍を出版してみた

「ファイル名を指定して実行」のすべて

f:id:stakiran:20181014082641j:plain

前々から書いてみたかった電子書籍。ようやく形になったので色々とまとめておく。

出版までの流れ

  • Amazon Kindle Direct Publishing にログインして会員登録する
    • Amazon アカウントでログイン後、著者情報を登録する
    • 振込先口座情報もここで登録する
  • 書籍データの原稿をつくる
    • 本文(.md)
    • 画像(.jpg)
    • 表紙(.jpg)
  • 書籍データを変換して epub ファイルをつくる
  • KDP にて新しい本を登録
    • epub ファイルと表紙をアップロード
    • 書籍情報も書いて保存していく
  • 問題がなければ 48 時間以内に出版される

なぜ KDP?

Ans: 電子書籍サイトとしてメジャーで、かつ出版方法も簡単みたいだから。

なぜでんでんコンバーター?

Ans: Markdown で書けるから。

会員登録について

  • 著者/出版社情報
    • 本名や本住所を登録する
    • この情報をもとに振込手続きを行うので、ハンドル名とかだと死ぬ
  • 支払いの受け取り方法
    • 振込先の銀行口座を登録し、「支払い通貨」を JPY() にして、さらに「次の通貨で行われた顧客取引の場合」を11マーケットプライスに
      • ブラジル(amazon.com.br)とメキシコ(amazon.com.mx)を除く11カ国
    • ちなみにブラジルとメキシコは小切手による支払いしか対応してない
    • 古いブログでは手数料がなんたらかんたらとあるが、それは昔の話なので無視していい
  • 税に関する情報
    • インタビューに答える
    • TIN という米国納税者IDを聞かれるが、持っていないので空欄でいい
    • インタビューに完了すると「適用される源泉徴収税率 30%」となるが、これは米国内で売れた時の税率なので気にしなくていい

書籍データと変換

KDP は epub ファイルや docx ファイルをアップロードする方法をサポートしているが、私は Markdown が好きなのと、変換処理に手こずりたくはなかったので でんでんコンバーター を使用。

用意するデータは以下のとおり。

  • 書籍本文.md
  • 画像1.jpg
  • 画像2.jpg
  • ...
  • cover.jpg (表紙)

Markdown のように普通に書いていけばいい。細かい文法の違いや運用については以下。

  • 電子書籍専用文法は でんでんマークダウン を見ること
    • 使うのはルビと改ページくらいか
  • 見出しはレベル1を「章」、レベル2を「節」に
    • レベル1がタイトルで、レベル2が章、レベル3が節、ではない(タイトル用の見出しは要らない)

出来上がったら、でんでんコンバーターにて上記ファイルをすべて選択してアップロード。epub ファイルをダウンロードできるので、ダウンロードしとく。

変換した epub ファイルのプレビュー

Kindle Previewer | Amazon Kindle ダイレクト・パブリッシング がおすすめ。

ファイルサイズ 260MB で、動作も中々に重いが、ウェブ上のプレビューアよりは断然早い、使いやすい、見やすい。

Markdown ファイルのプレビュー

epub に変換するのは面倒くさい、でも Markdown で書いた結果を HTML で見てみたいという場合は GitHub にアップするといい。

プライベートリポジトリを作って、上記データをまるごと放り込めば、もうそれだけで書籍っぽく表示される。画像のリンク切れや Markdown 文法のミスもわかる。

執筆フロー

Markdown を書くフェーズ、でんでんコンバーターで変換するフェーズ、Kindle Previewer でプレビューするフェーズの三つがある。後者二つは手作業な上に時間もかかる(といっても十数秒~数十秒だが)ので、まずは Markdown ファイルのみで本文を完成させる のが吉だろう。

で、本文が完成したら、あとは後者二つを繰り返して細かい見栄えや言い回しを修正していく。その際も、一つ修正してまた変換し直すよりは、まずは全部読んで指摘事項をメモしておいて、その後に指摘事項を全部反映する、のようにやるのが良い。

つまり 変換作業は時間がかかるので、いかに変換作業回数を減らすかが肝。ここに無頓着だと、あっという間に何十分何時間と時間が消えていく。

epub データのレイアウト(体裁)を変えたい

でんでんマークダウンは css 編集に対応しているので、css をいじる。

Downloads - でんでんコンバーター より default.zip をダウンロードし、展開した default.css をコピーして markdown ファイルと同じファイルに置く。これをいじってレイアウトを変える。なお、でんでんコンバーターにアップロード時は、この css ファイルも忘れず選択してアップロードすること。

css のテストは 電書ちゃんのでんでんエディター 上で試すと理解が早い。

以下、参考までに私が 「ファイル名を指定して実行」のすべて で使った css を載せておく。

/* -------
   Fontsize
   ------- */

/* 2, 1.5, 1.25 → ちょっと大きすぎるので小さめに */

h1 {
  font-size: 1.5em;
}

h2 {
  font-size: 1.25em;
}

h3 {
  font-size: 1.125em;
}


/* -------
   Borders
   ------- */

/* 見出しを枠線で強調 */

h1 {
  border-left: 8px ridge #000000;
  border-bottom: 4px ridge #000000;
}

h2 {
  border-left: 6px solid #000000;
}

h3 {
  border-left: 6px double #000000;
}

/* テーブルに枠線を引く */

table {
  border-collapse: collapse;
  border: solid 2px black;
}
table th{
  border: solid 1px black;
}
table td {
  border: solid 1px black;
}

/* --------------
   Margin Padding
   -------------- */

/* 見出し間のマージンが広いので小さく*/

h1 {
  margin-top: 20px;
  margin-bottom: 20px;
}

h2, h3, h4 {
  padding-left: 6px;
  margin-top: 16px;
  margin-bottom: 16px;
}

/* リストインデントスペース深すぎる(2em)ので小さく */

ul, li {
  margin-left: 8px;
}

/* ネスト時は <li><br/><br/><ul> と br が二つ入って二行分空くので消す */
li br {
  display: none;
}

/* 段落間が広すぎる(1.25em)ので, 狭く */

p {
  margin-top: 8px;
  margin-bottom: 8px;
}

/* 画像と段落間もやや狭いので, 画像側のマージンを広めに. */

img {
  margin-top: 12px;
  margin-bottom: 12px;
}

/* 同上テーブルも */

table {
  margin-top: 12px;
  margin-bottom: 12px;
}

/* ----
   Code
   ---- */

/* 黒背景白文字ベースと, 左寄りすぎで見づらいのを少し離す.
   code 単体だと pre 内の行毎に適用されるのでセレクタ指定は工夫する. */
pre {
  margin-left: 2px;
  padding-left: 4px;
  color: white;
  background-color: #333333;
  border: 1px solid silver;
}
p > code, li > code {
  margin-left: 2px;
  padding: 4px;
  color: white;
  background-color: #333333;
}

/* ----
   Misc
   ---- */

/* 見た目が不揃いなのを解消する
   - 半角英文字使うので等角じゃないと不均一になる
   - 全角半角入り交じる行が改行前に勝手にスペース調整されるのを防ぐ
*/
p, li, code, table {
  font-family: monospace;
  word-break: break-all;
}

/* 改行位置がほんの少しずれるのを回避する */
p {
  text-align: justify;
}

/* 段落ごとに自動でスペースを付与 */
p {
  text-indent: 1em;
}

/* 太字単体だと強調が乏しいので下線も付ける */
strong {
  text-decoration: underline;
}

表紙

おそらく一番の難所。普通は業者に頼むらしいが、お試しの個人出版で頼むのは気が引ける。せっかくなので自力でつくってみた。

表紙全般:

  • 本文からはリンクしない
  • jpg 形式
  • x : y = 1 : 1.6 つまり x, y = 1000, 1600
    • 理想は x, y = 1600, 2560
    • 最低でも x, y = 625, 1000
  • 圧縮せず高画質で
  • 表紙境界用に 3-4 pixel の細い薄灰色線があるとよい

私は x, y = 1600, 2560 サイズでつくることにした。

続いて表紙デザインだが、私に語れるほどの知見はないので頑張って調べてください。あと色んな作者さんの表紙を覗いてみるのもオススメ。自分でも書けそうなシンプルな表紙もあったりする。

最終的に私は以下のような表紙をつくった。

f:id:stakiran:20181014082641j:plain

表紙中央はタグクラウドというもので WordClouds.com で無料で作れる。 商用利用も普通にできる。引用しておくと、

Are there any restrictions on using my word clouds?

The word cloud images you create are yours to use any way you see fit. Feel free however to give credit to Wordclouds.com and spread the word! You are even allowed to use the generated word clouds commercially.

ただ、このタグクラウド画像つくるのに数時間は要した。意図したキーワードを上手いこと表示させるための重み付けパラメーターの指定に苦戦。一部を挙げておくと、こんな感じ。

8 RUN
3 PATH
3 notepad
2 AppPath
2 PATHEXT
...
1 system
1 .BAT
1 .CPL
1 winver
1 ncpa
1 NoRun

「RUN」は表示させたいから重めにして、あ、でも PATH も表示させたいから……みたいにかなり微調整した。

KDP にて新しい本を登録

KDP にログインして、つくった Markdown やら表紙をアップロードしたり、書籍情報を入力したりする。

私の場合、1冊売れたら100円、というわかりやすい指標を試すつもりで、以下のように登録。

  • DRM(コピープロテクト)
    • する。
    • 「無料でもいいから読んでもらいたい!」でもない限りは、すればいい
    • 今回は有料で売るつもりなので、価値を落とす真似はしない
  • KDP セレクト
    • しない。
    • KDP セレクトをするとロイヤリティ(印税率)を35%→70%にできるが、90日のKindle縛り(他のサイトで売れない)がある
    • また Kindle Unlimited などの読み放題スペースにも掲載され、アクセス数が稼げるのがメリットらしいが、私は下手に数ページ読まれて購入されないのがもったいないなと思った
    • 総合すると、初めてだし、まずは「しない」でいいか、と判断
  • 値段
    • 300\ JPY
    • 1冊売れたら100円、とわかりやすいので

登録後、48時間に審査され、問題無ければ出版される。

私の場合、昨日夜 22:00 頃完了して、今朝 7:00 頃確認したら、既に出版されていた。問題無ければスピーディーに行くのだと思う。

出版後の確認

カテゴリがなぜか「本 › 人文・思想 › 教育学」という無関係なカテゴリだったので、変更依頼を出した。

Amazon Kindleダイレクト・パブリッシング:KDPについてのご質問のお問い合わせ より 本の詳細 > カテゴリーおよびキーワードを更新 と辿って、以下内容を書いて提出。

以下書籍のカテゴリ情報の変更をお願いいたします。

電子書籍名:『「ファイル名を指定して実行」のすべて 』
ASIN番号:『B07JF3BHP5』

現在のカテゴリ:
・Kindleストア > Kindle本 > 人文・思想 > 教育学

変更後のカテゴリ:
・Kindleストア > Kindle本 > コンピュータ・IT
・Kindleストア > Kindle本 > コンピュータ・IT > OS

2018/10/14 08:19:34 現在、まだ結果は来てない(出したのが 7:40 くらいだし)。 (2018/10/15 追記) 変更されました。

おわりに

KDP というシステムとでんでんコンバーターという Markdown ベースコンバーターのおかげで、割と簡単に出版できたかなと思う。

とりあえずは結果が楽しみです。何もしないと誰にも読まれずに埋もれるみたいなので、宣伝も積極的にやっていきます。皆さまも、もし気になったらぜひ購入してください。

余談: 元ネタって Qiita だよね?

鋭い方は気づいているかもしれませんが、元ネタは 「ファイル名を指定して実行」を極める - Qiita です。

Qiita の方は「わかる方向け」にかなり簡単に書いてますが、今回の書籍は、初心者の方でも読めるよう丁寧に書いています。また、画像もふんだんに利用したり、履歴や PATH といった中上級者向けトピックも内容を何倍にも増やして解説しているので、ぜひ読んでいただければと。

ポメラ DM200 購入に迷っている方の背中を押す記事

ポメラ DM200(以下ポメラ)ユーザーが少なくて寂しいので、迷っている方を引き込むための記事を書いてみました。ありそうな疑問を Q&A 形式でまとめていきます。

自宅メインだから不要でしょ?

Ans: 自宅メインでも使えます。

ポメラのメリットは二つありますが、どちらも自宅メインな使い方でも効力を発揮します。

  • (1) ネット接続やゲームなど余計な機能が付いてないので、執筆に集中できる
  • (2) 起動が速く、小型で軽いのでどこでも(たとえばベッドでも)気軽に使える
  • (3) キーボードが静音なので同居人がいても比較的共存しやすい

(1) は、PC による執筆が捗らない人に刺さるでしょう。ポメラを使うと「今までの自分がいかに寄り道しまくりで集中できてなかったか」がわかります。たまに訪れる「かなり集中できる時」が、PC よりも簡単に手に入るようになる、と言えばいいでしょうか。これは実際に使ってみないとわかりません。私はこの点を知っているので、PC ではなくポメラで書くことが多いです。

(2) は、のんびり読書したり音楽を聴いたりするのと同じようにのんびり書きたい場合に重宝します。ソファーの上、ベッドの上、布団の上、とどこでもサクっと使えます。ただ(体勢にもよりますが)さすがに長時間の執筆はキツイので、長時間書く時はちゃんとデスクを使いたいですね。

(3) は、あくまでも私が普段使っている Realforce キーボードと比較しての話です。静音なので、会社の昼休憩中に小説をバリバリ書くこともできますし、集合住宅の夜でも気兼ね無く書けます。同居人が居て、キーボードうるさいと言われる方に関しても、同居人のストレスを軽減できるでしょう。

外出先で使える?テーブル無いケースが多いから無理でしょ?

Ans: 座れさえしたら使えます。

ポメラは小さいので、太ももや膝に乗せてタイピングできます。実際、私は病院や飲食店や電車内ではしばしばポメラを使います。

ただし、肩幅は取るので、隣席が埋まっている場合は使えない(小柄な方なら使える?)ですね。

バッテリーの持ちが心配なのですが?

Ans: フル充電で10時間くらいはもちます。

よほどずぼらでなければ、バッテリー切れの前に充電すると思います。

ポメラに書いたデータを PC に転送する方法がよくわからないのですが?

Ans: 複数あります。

以下のとおりです。

  • (1) 本体メモリに保存し、USB で PC に繋いで「ポメラをドライブとして」扱う
  • (2) SDカードに保存し、PC にも SD カードを挿して接続する
  • (3) ポメラ Sync(無線通信)を使う

どれも一長一短です。

(1) は追加の道具や設定が要らないのがメリットですが、PC に繋ぐ時が面倒です。USB ケーブルでポメラと PC を繋ぎ、ポメラ側で「PCリンク」を実行して初めて PC 側で認識されます。

(2) は (1) と似ていますが、SD カードを用意し、また抜き差しする手間があります。

(3) は無線ルータと Gmail アカウント設定が必要ですが、指定したメールアドレスにデータを送信できます。IFTTT と組み合わせると、Gmail からさらに別のサービスに流すこともできるようです。

ちなみに私は (1) にしています。一番シンプルだからです。

気軽に書けるのはわかったけど結局 PC で清書するんでしょ?だるくない?

Ans: 工夫しましょう。

たとえば私の場合、ブログは(基本的に調べながら書きますし一記事が短時間で終わるので)PC のみで書いてます。小説は、以下のようにしています。

  • プロット練ったり下書き書いたり、はポメラでする
  • ポメラのデータは定期的にバックアップする(週一)
  • 原稿がきりのいいところまで出来たら、PC 上で(よりリッチなツールと広い画面で主に推敲などの)作業を行う

ポメラは設定や下書きをバリバリ書き殴るのに適していると思っています。

他にもやり方はあるでしょう。自分に合ったやり方を模索してみてください。

辞書変換がバカすぎて使い物にならないのでは?

Ans: DM200 の ATOK は割と賢いです。

個人的には Windows デフォの IME と同等以上です。自動学習や辞書登録もあるので、使い込むほど馴染んできます。

キーボードが打ちづらそうに見えますが?

Ans: 神経質な私でも結構打ちやすいですよ

Realforce を複数枚買う程度には神経質な私ですが、ポメラのキーボードは割と打ちやすいと思います。JIS 配列の91(テンキーレス)キーボードです。

ただし、細かいことを書くと、こうなりますかね。

  • 文字キーで日本語入力する分には問題無いし、そこいらのノート PC よりは打ちやすく設計されている印象。MacBookAir と同じくらい
  • 修飾キーや半角全角キーなど補助系キーは打ちづらい

エディタが貧弱そうで心配なのですが?

Ans: まあまあ使いやすいです。

少なくとも Windows のメモ帳やそこいらのメモアプリよりは上です。テキストエディタにはさすがに劣りますが、ポメラには以下があるので助かります。

  • (1) アウトライン機能
  • (2) キーボードショートカット

(1) はテキストを見出しで区切って階層化する機能です。目次みたいに見出しが表示されるので全体構造を把握しやすいですし、Ctrl + Up/Down で前/次の見出しに一発ジャンプできるので素早くあちこちを辿れます。私はポメラの魅力の 5 割はこのアウトラインだと思ってます。手放せません。

(2) は、ポメラの各種操作にショートカットキーを充てることができる、という意味です。キーボードカスタマイズですね。検索、置換、文字数表示、辞書引きなど基本的な機能は揃っています。

ファイル名、ファイル数、ファイルサイズ、対応文字コードが心配なのですが?

Ans: 端的にまとめておきます。

  • ファイル名上限は全角25文字くらいまで
  • ファイル数は空き領域次第だが、数百程度なら問題無い
  • ファイルサイズ上限は 1 ファイル 30 万バイト(日本語おおよそ10万文字)くらい
  • 文字コードは UTF-8、改行コードは CRLF だが、設定により変更可能

過去記事 ポメラ DM200 を買ったので仕様とか使い心地とかまとめる にもまとめてあるので参照してください。

マウスとか無いんでしょ?どうやって操作すんの?

Ans: テキストエディタをイメージしてもらえるとわかりやすいです。

上にメニューバーが並んでいて、メニューバーは専用のキーで一発アクセスして、カーソルキーで項目を選ぶという感じです。

Windows だと Alt キーでメニューバーを開きますが、ポメラではメニューキーがあります。ちょうど左 Alt あたりの位置にあります。簡単ですね。

ポメラを使っている人の感想を調べたいのですが?

Ans: Twitter で調べましょう

新機種 DM30 が出てますけど、DM30 が良いの?

Ans: いいえ。DM200 が良いです。

※(注) これは DM30 をネットで調べただけの意見です。

少なくとも画面の大きさ、キーボードの操作性、ATOK やバッテリーなどの性能面では DM200 が優れています。ポメラシリーズで DM200 が歴代最高傑作です。

で、DM30 はというと、「折り畳める」「電池式」といった特徴がありますが、使いやすさと性能面では DM200 より落ちています。特徴を愛せる人のみが使えばいいでしょう。私は違います。純粋な書きやすさと手軽さを求めている大半の方も違うと思います。

Chromebook や MacBookAir で良くない?

Ans: ポメラは軽さが魅力です。

Chromebook も MacBookAir も所詮は PC です。ネットやアプリは使えますが、起動は遅いし、ネット環境が無いと話になりませんし、同期も必要ですし、大きくて重たいし、アップデートとかだるいし、と PC の制約をやはり受けてしまいます。

ポメラは違います。デジタルメモです。PC よりもだいぶシンプルです。ただテキストを書くためだけの装置ですからね。Chromebook や MacBookAir よりも「ただテキストを書くこと」に関してはだけは、圧倒的に手軽に使えます。この軽さは病みつきになります。

壊れないか心配です

Ans: 乱暴に扱わなければ大丈夫だと思います。

私は 10ヶ月ほど、ほぼ毎日ポメラを「ロフトの A4 サイズタブレットケース」に入れて、これをリュックに入れて通勤やらお出かけやらに持ち歩いていますが、特に壊れてはいません。

でも、お高いんでしょう?

Ans: お高いです。

諭吉さん 3-5 人はお亡くなりになられます。

おわりに

以上、ポメラ DM200 の購入を渋っている方向けに、背中を後押しする記事を Q&A 形式でお届けしてみました。いかがでしたでしょうか。参考になりましたら幸いです。

ポメラ DM200 を快適に使うために必要な2つのコト

ポメラ DM200 を使う上で(個人的に)絶対に譲れない(と思う)点を二点ほど。

(1) アウトラインを使う

アウトラインとは要するに「目次」を導入する機能で、これを使うと「大見出し」「中見出し」「小見出し」といった単位で文章を構造化でき、格段に扱いやすくなる。

できること:

  • 目次のように見出し一覧が表示される
    • 全体構造を捉えやすい
    • どこにどんな文章を書いていたかを探しやすい
  • 「次の見出し」「前に見出し」と見出し単位でジャンプできる
    • 何百行あっても一瞬でジャンプできる

Markdown 記法かドット記法か

結論を言うと、どっちでもいい。お好きな方を。

記法を一発で打てるよう辞書登録を

日本語入力中でも入力しやすいよう辞書登録すると楽。

  • 例1: m1#
  • 例2: m2##

これをしておかないと、見出しを書く時に左上の小さな半角全角ボタンを押す羽目になる(見出し記法は半角文字なので半角モードで打たないといけない)。押しづらい。

快適にスクロールする二つの方法

  • Ctrl + Up/Down で前後の見出しにジャンプする
  • Alt + Up/Down で1画面分スクロールする

ちなみに Alt + Shift + Up/Down で1画面分の行選択ができる。惜しいのは、Ctrl + Shift + Up/Down による見出し単位の行選択には対応していないこと。本当に惜しい。

FOF と EOF をつくる

FOF(First Of File) と EOF(End Of File) を設けておくと便利。

# FOF

<ここに本文を書いていく>

# EOF

こうすると Ctrl + Up/Down の見出し間ジャンプで「ファイル先頭/ファイル末尾に飛べる」ようになる

(2) Sync は使わない

文章執筆に専念したいなら極力無駄は省きたい。ポメラ DM200 は既にインターネット機能を省いているが、まだ不十分である。Sync 機能もできれば省きたい。

Sync 機能のデメリット:

  • 「同期取れてるかな?」という確認や心配に意識が持って行かれる
  • Sync 機能が働く分、バッテリーの消耗が速くなる
    • 実測はしていません
  • Sync 機能が働く分、ポメラの動作が重くなる
    • 実測はしていません

じゃあどうやって PC にデータを送るの?:

  • USBケーブルで繋いで手動でコピーする
    • SDカードと同じようなやり方
    • デジカメだってそうしてる
  • SD カードを使う

手動コピーは面倒くさくないですか?:

  • 面倒くさいが、Sync 機能のデメリットよりはマシ