かっこいい感じのネタじゃないのが残念だが…(笑)

表題の通り、
Kindle Unlimited対象の本をUnlimitedで読むつもりが
購入してしまったので、恥を忍びつつ返金をお願いしたって話。

それ以上でもそれ以下でもないのだけど、
それを言ってしまうと話が終わっちゃうので、
なんでそうなったのかをここに書きたいと思う。

うっかり違うスクリプトを起動してしまった

話が本題から若干逸れるが、僕は自動化が大好きだ。

あれもこれもちょっとでも繰り返しが発生しそうなら
自動化したいという気持ちを持たずにはいられない。

まぁ、ありとあらゆることを自動化してるの？
かと言われると、もちろんありとあらゆる繰り返し作業を
自動化したい気持ちは持っているが
実際にできているのは5%くらいだ(笑)

話を本題に戻すと今回のことは数少ない
僕お手製の自動化プログラムによって引き起こされた。

見出しにあるスクリプトというのが
その自動化したプログラムのことなのだけど、
ちょっとした作業を自動化した
小さいプログラムだと思って欲しい。

なぜそんなものを作ろうかと思ったかというと、
Kindle Unlimitedは
読み放題と謳ってはいるけど、
一度に利用できる本は10冊という制限があるからだ。

10冊は少ないように感じるが
どの本を利用するか厳選し、
その後10回利用ボタンをクリックする
作業は、個人的にはかったるすぎる。

だからプログラムを動かしたら
10個の利用開始ボタンを自動でクリックする
プログラムを作った。

ここまでは良い。

このプログラムだけなら
今回の問題は起こらなかった。

Kindle本の購入プログラムが仇になった

実は上記のKindle Unlimitedを一括で
利用するためのプログラムとは別に
Unlimited対象外の通常のKindle本を
一括購入するプログラムも作っていた。

なんでかというとこちらは一度に購入できる
冊数に制限などないため、セールなどでまとめ買いをすると
多いときは数十冊一度に購入するのだけど、
10回のクリックがかったるいと思ってしまう
怠け者の僕には数十回のクリックはとても耐えられない。

だから一括購入するプログラムを作ったんだけど、
自分用のプログラムだからあったらいいけど、
なくてもまぁ大丈夫みたいな機能は付けてない。

だってかったるいから(笑)

そして今回そのかったるいによって省かれた機能が

「本当に購入するかどうかの確認画面」

プログラムをやる人ならわざわざ説明するまでもないと思うけど
実際のお金が動いたりする場合は本当に購入していいのか大体確認画面を
用意することが多い。

いろんな人が使うから知らない間に決済されていたみたいな
トラブルを防ぐためだ。

でも自分で作って使うくらいのものなら間違えないだろう。
確認画面を作る方が面倒だし。

と思ってしまったのだ。

お客さんから依頼された仕事だったら、
面倒とか言えないのだが、自分のツールなら
それができてしまう…

恐ろしい。

ここまで書いたらオチが見えたかもしれないが、
そうなぜこれが起こったかは

「間違えて購入前の確認がない一括購入用のプログラムを起動してしまった」

この1行に集約される。

一瞬事態が飲み込めなかった

ちなみに間違えてプログラムを起動した直後は
何が起こったのか自分でもわかっていなかった。

10通の購入完了メールを見るまでは(笑)

慌ててキャンセルを試みるものの(Kindle本は購入直後の画面ならキャンセルができる)
何をテンパったのかその後Ulimitedの一括利用開始プログラムも実行してしまい
購入完了画面がグッバイするというヘマもやらかしてしまったため、
サポートの方に相談することになった…

以前にも間違って購入した本をキャンセルさせてもらったことがあるが、
10冊も間違えたことなんてない。

サポートの方に相談したら
無事キャンセルを受けてくれたのだが、
キャンセルはAmazonの裁量で応じてるので
今回は対応したけど、キャンセルできない時
もあるから注意してね。

と言われてしまった(当たり前)

流石に今回はキャンセルは無理かなーと思ったので
ホッとしたが、もしキャンセルできなかったら
金銭的もそうだが、間違って購入した本が
著者の方には失礼ながら、Unlimitedだったから
読んでみようかと思ったけど普通だったら買わないよなー。

という類の本だったので、ライブラリにさほど欲しくない本が
並ぶという精神的ダメージも上乗せされるところだった。

サポートの方改めて対応してくれてありがとうございます。
100%僕が悪いです。

確認画面付けます…

というわけで記事が終わったら購入プログラムに確認画面の
処理を追加することにする。

最近CONOHA VPSを使う機会が増えてきました。
シンプルな設定画面でKUSANAGIが使えるのが気に入っています。
管理画面が重いのがちょっとなとは思いますけど…

さて今日はロードバランサー経由でVPS(KUSANAGI)を複数台立てた時に
遭遇する問題を暫定的に解決しました。

管理画面を移動するたびにセッションが切れる

正確にはランダムなので、画面遷移するときもあるんですが、
AWSと違ってCONOHAのロードバランサーは特定のurlの時は
このVPSみたいに指定することが管理画面上でできないので、
ロードバランサーを組み込んでみても、管理画面をアクセスするたびに
ログアウトしたり、設定が反映されなかったりする状態にになります。

僕の場合は具体的にはVPSを2台、データベースサーバーを1台、オブジェクトストレージを1台って
構成でした。

hostsファイルで片方のVPSのIPアドレスを指定

色々検索しまくったんですが、解決方法はAWSのものしか出てこなくて
困ったので、サポートに相談してみたところまさかの回答をいただきました。

見出しにも書いてある通りローカルのhostsファイルに片方のVPSのIPアドレスを
指定すれば少なくても自分のMacからの接続は片方のVPSだけに固定できる。

言われてみれば当たり前だし、その手法って割と使っていたのに
全然頭に浮かばず。

やったらあっさり解決したし。

hostsファイルで設定するデメリット

管理画面をいじりたいという当初の目標は達成したんですが、
運用面で考えると正直微妙だったりします。
今回の件は記事自体はライターさんが更新することもあって
ライターさんにhostsファイルいじってっていうの？
って思ったりします。

個人的には問題解決してスッキリしました。

最近とある講座を受講しています。

その講座はメールで色々なお知らせや役に立つ情報が送られてくるので、後で見返せるようにpdfにして保存していました。

何故pdfで保存しているのかというと僕自身が「インボックスゼロ」という方式でメールを処理していることもあり、基本的にフォルダなどを作ったりはせず閲覧したものはすべてアーカイブしてしまうためです。

※インボックスゼロについては記事の主旨にそれるのでこの記事では解説しませんが、メール処理の方法としては簡単だけど非常に効果的な運用ルールだと思うので、興味のある方は是非検索してみてください。

都度エクスポートがめんどくさい

普段はMacのMailを使ってメールの運用をしています。

エクスポートしたいメールを選択して都度pdfにエクスポートしているのですが、一日複数メールが送られてくるものを都度処理するのが、とにかくめんどくさい。

これはなんとか自動化したい！

そこでApple Scriptでエクスポートを自動化する処理を書いたのですが、書き出す先のフォルダ指定をApple Scriptで書くのがこれまた面倒だったので、Downloadフォルダに出力したものをしばらく手動で動かしていました。

ただ、この手の処理は一部の処理だけを自動化するだけではあまり自動化するメリットを感じられないので、フォルダへの振り分けも自動化することにしました。

シェルスクリプトで移動する処理を書いてみたものの・・・

フォルダの振り分け自体はシェルスクリプトで書く方が楽だったので、シェルスクリプトで書いて、これ自体は問題ないのですが、書き出しスクリプトを走らせた後に、振り分けスクリプトを実行するという、「つなぎの部分」が手動でしないといけないことが地味にめんどい・・・

なので、Apple Scriptで書き出す処理にシェルスクリプトの実行も組み込むことも考えたのですが、ちょっとコードを書く気分でもなかったので、フォルダアクションで振り分けてしまおうと思いました。

しかし普段全く使わないので、めんどくさい(またw)気分になってしまった時に、ふと目に入ったのがHazel(公式サイトはこちら).

※HazelはMacで簡単にメールの振り分けの要領でファイルの振り分けしたりリネームしたり、スクリプトの実行などを行えるとっても便利なツールです。色々設定をしていたのですが、Mac入れ替えでデータを初期化する際ルールのバックアップを忘れてルールが消えて以来、入っているものの放置してました。

導入したものの全く使っていなかったHazel

そうだ！Hazelでシェルスクリプトを実行しよう！

と思い、Downloadフォルダにpdfが出力されたら振り分けスクリプトが実行されるようにしました。

Hazel簡単で楽チン。

前置き長くなりましたが、具体的にどうしたかこれから解説していきます。

Hazelの設定

Hazelのメニュー画面を出します。

上記の赤枠で囲った部分をクリックします。

左下にも「＋」ボタンがありますが、それは実行するフォルダをどこにするかを指定する際のものです。

今回はDownloadフォルダにあるpdfファイルに対して実行しますので、ここは登録されているという前提で進めます。(購入時は左側のFoldersには何もありません)

上記のような画面が表示されますので、Nameの欄にわかりやすい名前を付けてください。

続いて四角の線で囲われた2つの段の上側、3つの選択欄をそれぞれ「Kind」「is」「PDF」と設定します。

これはファイルの種類がpdfの場合に実行しますという意味です。

色々な組み合わせがありますので、興味のある方は是非試してみてください。

上の段の設定が完了したら続いて下の段を「Run shell script」「実行するスクリプトファイルを指定」

に設定してください。

※キャプチャ画像では「embedded script」となっていますが、これは別途スクリプトファイルを読み込むのではなくHazelに直接スクリプトを記載する方法です。この場合スクリプトを記述するためには右側の「Edit script」をクリックすると入力画面が表示されます。また余談ですが、シェルスクリプト以外にApple Scriptも実行できます。

設定したら「OK」ボタンをクリックします。

以上で設定は完了です。

あとはHazelが自動で判断して振り分けのスクリプトを実行してくれます。

便利だ！

まとめ

なんでもかんでもプログラムを書こうと思ってしまいがちですが、すでに便利なツールがあるならそっちを使った方がいいですよね。

ではまた。

Apple Watchを購入予定の人は購入したらSuicaをiPhoneに移すのを激しくおすすめします！

iPhone XとAir Pods、Apple Watchを揃えるとちょっと未来人みたいな気分になります(笑)

さて、今日はそのApple WatchのSuicaの話。

コンビニでチャージするしか方法がないと思ってた。

これは別にApple WatchでもiPhoneでも一緒ですが、自分が持っているのがVISAカードだけで、かつApple Pay対応のものがなかったので、Suicaのチャージはコンビニでするしかないと思ってました。

Suicaを使えるようになったのはすごい便利だけど、これは不便だなと。

まぁ仕方ないかと思ってしばらくそのままで使っていたのですが、こないだ新しくiPhoneを入手した友達から「デヴィットカードは使えないの？」と聞かれたことから再度調べて見ることにしました。

すると、元々対応していたのに知らなかったのか、知らない間に対応していたのかはわからないのだけど、「Apple PayにVISAは対応していないけどSuicaにはVISAのカードが登録出来る」ということがわかりました。

デヴィットカードはSuicaにカードを登録すれば使える

僕の調べた範囲ではデヴィットカードはApple Payで利用出来るカードの中にはないようなのですが、「Suicaの登録カードをVISAデヴィットにすればデヴィットカードを使える
」ことがわかりました。

では実際にどのように登録したのか解説して行きます。

カードの登録方法

実際の登録方法ですが、今回は住信SBIデヴィットを使っての検証になります。

※他のデヴィットカードでは検証していないので、その点はご了承ください。

登録はiPhoneのSuicaアプリからしか出来ない

登録自体はiPhoneのSuicaアプリから行います。

チャージも同様です。

Apple Payに対応しているカードだとApple Watch側からチャージをすることも可能のようですが、住信SBIデヴィットカードでは出来ず、下記のようなメッセージが出ました。

入金チャージをクリック

では登録解説に入って行きます。

iPhoneのSuicaアプリを立ち上げて「入金(チャージ)」(上記写真の赤枠で囲った緑のボタンです)をクリックしてください。

実際の登録画面を見せたいところだが・・・

で、本来ならここからカードを登録していく流れになるのですが、どうも一回登録しちゃうと登録画面でないみたいで、残念ながらお見せすることができません。

カード情報を入力して登録、みたいな流れだった気がします。

なお、登録情報を変更することは可能ですが、記事の主旨からそれるので、この記事では解説しません。

登録完了後表示されるカードアイコンをクリックして決済

無事登録が完了すると、「入金(チャージ)」のボタンをクリックすると上記のように、登録済みのカードとApple Payのボタンが表示されます。

そして、登録済みのカードアイコンをクリックすると確認ボタンが表示されるのでそれをクリックすることで決済が行われチャージされます。

チャージする金額の変更方法

チャージされる金額は上に書いてある「入金(チャージ)」の「金額変更」のボタンをクリックして変更できます。

金額は「1,000」「3,000」「5,000」「その他」から選ぶことができます。

まとめ

正直もっと早くこのことに気づきたかった(笑)

仕事帰りにチャージするためにコンビニに寄ったりしていたのでorz

これでどこでもチャージできる！！

最高！！

が、一個だけ注意点。

チャージが行えるのは4:00–26:00まで。

僕は昨日27時過ぎにチャージしようとしてチャージできず、そのまま寝てしまって、翌日改札で引っかかったのはいうまでもありませんorz

海外にいるときに日本でしか見れないサイトなどを閲覧したい場合、VPNサーバーを使ってアクセスします。

VPNサーバーの詳細については記事の主旨と異なるので、ここでは触れませんが、興味がある方は検索して見てください。

VPNサーバー自体は各地にありますが、日本で有名なのは筑波大学が公開してくれているVPN Gateというサイトです。

使用するDDNSはL2TP/IPsecにチェックが入っているものを使う

ここがハマったポイントなのですが、VPN Gateが対応している日本のサーバーは複数あるのですが、上記写真の赤枠にあるL2TP/IPsecにチェックが入っているところを使わないと接続ができません。

海外にいるときMacを使って接続しようとしたときにハマりました。

ご参考まで。

わかってしまえば簡単だったのですが、なかなか解決できずにはまったので解決法を記載します。

High SierraにOSをアップデートした後VM ware Fusion10を起動したところ

「接続先の有効なピア プロセスが見つかりません」

と言うエラーが出て起動ができなくなってしまいました。

ネットで検索すると、やれキャッシュファイルを削除しろだの色々な解決方法が見つかったのですが、
どれも上手くいかず。

原因としてはMac側の実行許可が下りなかったのが原因

ずっとVM ware側の問題だと思っていたのですが、原因はOS側

Macの「システム環境設定」→「セキュリティーとプライバシー」で、ダウンロードしたアプリケーションの実行許可画面で、VM ware Fusionが許可されていないので、許可すれば直ります。

記事を書くにあたって許可の画面を出したかったのですが、再現できなかったのですが、上の画面から許可できます。

phpを.htmlファイル上で実行する手法は昔からあって僕も何度か使ってみたんだけど、今回はクライアント案件でハマったので、メモ。

この手法を用いる場合は.htaccessの設定が重要なのだけど、エックスサーバーの場合割り振られたサーバー番号によって対処方法が異なる。

今回の案件は2001年より前に稼働しているサーバーが割り当てられていたので、そのやり方について書く。

2001年より前から稼働しているエックスサーバー上でphpをhtmlで走らせるために.htaccessに書く項目

結論としては下の2行を.htaccess上に追加すればOK

AddHandler fcgid-script .html
FCGIWrapper “サーバーのパス/xserver_php/php-cgi” .html