feed
2014年02月17日, 編集履歴
ソフトバンクのiPhone 4（4Sにあらず）からドコモにMNPしてiPhone 5sに変更した。余計なオプション契約なしで端末代金が一括0円、他のキャッシュバック等はなし、という案件。
ソフトバンクのiPhone 4は発売初期段階で買っていたので、もう三年以上。月々割りもとっくに終わっていて、ホワイトプランとパケット定額で月の支払いが六千円程度。
ドコモにMNPして一括0円のiPhone 5sに変更すると、「のりかえ割」で基本使用料が相殺、「月々サポート」で月三千円弱の割り引きがかかり、月の支払いが三千円程度になる（ただし割り引きは二年間なので、それ以降はやはり六千円程度になる）。
古い機種で高い料金と、新しい機種で安い料金、どちらを選ぶかというと当然後者だよね、っていう。どのキャリアも既存ユーザに対する優遇措置がほぼないので、二年ごとにMNPするのが料金的にはお得。一括0円の端末を選べば三千円程度の料金で運用し続けられる。
キャリアメイルについて
その際に問題になるのがキャリアメイルのアドレスが変わってしまうこと。MNPでは電話番号は変わらないがキャリアメイルのアドレスは引き継げない。二年ごとのアドレス変更通知が面倒ならば、キャリアメイルを捨てるという選択肢はあり。
GmailやiCloud等を代わりに使う、短文のみならば電話番号で送受信できるSMSを使うのもいいだろう。
容量について
iPhone 4は32GBモデルを使っていたが、iPhone 5sは16GBにした（私が契約した店では上位容量の機種はそれぞれ一万円増し程度だった）。iPhone 4では32GBギリギリで運用していた。しかし、音楽ライブラリィをすべてiPhoneに入れようとしなければ容量は足りるし、実際すべての音楽をiPhoneに入れておく必要性はまったくないのだが、「選ぶ」という行為自体にストレスが発生する。
パケット定額プランについて
iPhone 5sでLTEが利用できるようになり、自宅で回線速度を測定してみた。
- WiFi: 下り23Mbps/上り30Mbps
- LTE: 下り35Mbps/上り10Mbps
- （番外）自宅光回線: 下り66Mbps/上り26Mbps
となった。
正直ここまで高速な回線は私は必要ない。
Xiパケ・ホーダイ for iPhoneの料金が5460円だが、常時下り1Mbps制限（？ 速度は適当）くらいでもっと安いプランとか欲しい。通信量7GB超過で128kbps制限なんてことができるってことは個別に回線速度制限が可能なわけで、そういうパケット定額プランを作ることも可能なのでは（知らんけど）？ そういう安いパケット定額プランが欲しい。
MNP予約番号発行による引き止めポイント付与について
MNPをする際には予約番号というものを移行前のキャリアから発行してもらう必要がある。ソフトバンクからMNP予約番号を発行してもらった直後、引き止めのためかポイントが一万円分付与された。
一万円程度ではMNPによる恩恵に遥かに見劣りするのでスルーしたが、MNPする気がなくてふつうに機種変更とかしたいときに、フリで予約番号発行をしてみるとお得かもしれない（全員がもらえるとは限らないし、金額も変動するかもしれない）。MNP予約番号を発行するだけならば元の契約に影響はないはず。
2014年01月19日, 編集履歴
はじめに
OS Xで、
- Appleの標準的なアプリケーションにおいて、ユーザインターフェイスの文言がどのように翻訳されているのかを調べるとき
- アプリケーションのヘルプドキュメントを書いているとき
などに、アプリケーションを日英の両言語環境で同時に起動したいことがある。
しかし、通常はアプリケーションを複数起動することはできない。日本語環境で起動しているアプリケーションのユーザインターフェイスの文言が、英語環境でどうなっているのかを確認するには、システム環境設定で優先言語を変更してアプリケーションを起動し直す必要がある。これはめんどくさい。
異なる言語環境で同じアプリケーションを同時に起動することができれば、上述のような作業をするときに便利である。これはターミナルからopenコマンドを使って、
$ open -n -a Safari --args -AppleLanguages '("en-US")'
のようにすると実現できる。
openコマンド
openコマンドは、かんたんに言えばFinderでなんらかのファイルをダブルクリックしたときの動作をターミナルから行うものである。たとえば、
とすれば、カレントディレクトリィにあるhoge.txtをFinderからダブルクリックしたのと同じ動作になる（なんらかのテキストエディタでhoge.txtが開かれるであろう）。
-aオプション
openコマンドで-aオプションに続いてアプリケーション名を指定すると、そのアプリケーションでファイルが開かれる。実際にそのファイルに関連付けられているアプリケーションがなんであれ、-aオプションで指定したアプリケーションでファイルが開かれる。たとえば、
ではSafariが起動し、
$ open -a Safari hoge.html
ではHTMLファイルに関連づけされているアプリケーションがGoogle ChromeであってもSafariでhoge.htmlが開かれる。
-nオプション
openコマンドに-nオプションを指定すると、すでに起動中のアプリケーションはそのままに、新たに同じアプリケーションを起動する（DockやCommand-Tabのタスクスウィッチャにも同じアプリケーションのアイコンが複数個表示される）。
とすると、Safariが起動中であっても、それはそのままに新たにSafariを起動する。
--argsオプション
openコマンドの--argsオプションは、以下に続く引数を、起動するアプリケーションにコマンドライン引数として渡す。
$ open -a Safari --args hoge foo
とすると、Safariにhogeとfooというふたつの引数が渡される。
コマンドライン引数による言語環境の上書き
アプリケーションにコマンドライン引数で-AppleLanguagesで優先言語順を指定した配列を渡すと、システム環境設定の優先言語順を上書きすることができる（参考情報：コマンドライン引数(Launch arguments)は思ったより簡単に使える - 24/7 twenty-four seven）。
$ /Applications/Safari.app/Contents/MacOS/Safari -AppleLanguages '("en-US")'
とすると、システム環境設定で日本語を優先言語にしていようと英語環境でSafariが起動する。
まとめ
以上を組み合わせると、以下のようになる。
$ open -n -a Safari --args -AppleLanguages '("en-US")'
ターミナルから上記コマンドを実行すると、現在起動中の日本語環境のSafariはそのままに、新たに英語環境のSafariが起動される。これで日英両言語のSafariを見比べながら、ユーザインターフェイスの文言を確認できるようになる。
2013年12月08日, 編集履歴
はじめに
Jekyllは静的ウェブサイト生成システムであり、検索機能は付いていない。
プラグインで検索機能を付けられるのかもしれないが、GitHub Pages上でビルド・ホストをする場合は使えないので、ちゃんと探していない。かんたんにサイト内検索を実現するならGoogleのカスタム検索を使用する方法もあるが、Googleには頼りたくないので今回は自分で実装した。
こんなの。
キィワードを入力してエンターで検索実行。キィワードを[]（角括弧）でくくるとそれをブログ記事に付けられたタグとして認識する。たとえば[jekyll] 検索とすると、「jekyll」タグを付けられたもの、かつ本文に「検索」を含むブログ記事がヒットする。
コンセプト
基本コンセプトは「simple jekyll searching - alex pearce」を参考にした。
かいつまんで言えば、ブログ記事の情報（タイトル、URL、タグ、日付、本文）をJSONファイルに配列として詰め込み、JavaScriptで条件に合致する記事を取得するという方法をとった。
JSONファイルの作成
ブログ記事の情報を溜め込むsearch.jsonを作成する。ウェブサイトのビルド時に全ブログ記事の情報を自動で埋め込むために、Jekyllの処理対象として作成する。
---
---
[
{% for post in site.posts %}
{
"title": "{{ post.title | escape }}",
"tags": [{% for tag in post.tags%}"{{ tag }}"{% unless forloop.last %}, {% endunless %}{% endfor %}],
"url": "{{ post.url }}",
"date": {"year": "{{ post.date | date: "%Y" }}", "month": "{{ post.date | date: "%m" }}", "day": "{{ post.date | date: "%d" }}"},
"content": "{{ post.content | strip_html | strip_newlines | escape }}"
}{% unless forloop.last %},{% endunless %}
{% endfor %}
]
全体を配列として、その中にブログ記事の情報を詰め込む。Jekyllの処理対象とするためにファイル先頭にYAML Front-matterが必要。
ポイントはcontentの値に適用するフィルタ。
post.contentにはブログ記事の本文がHTMLタグ付きで入っているので、strip_htmlフィルタを適用してHTMLタグを取り除く。strip_newlinesで改行を除去して単一行にし、最後にescapeでクォーテイション文字等をエスケープする。
JSONファイルが作成できたら、一度ローカルでビルド、生成されたJSONファイルを検査し（JSONLint - The JSON Validator）、Validなファイルができているかを確認した方が良い。
検索フォーム、検索結果ページの作成
検索ページへGETリクエストを送信するフォームを作成し、すべてのページで読み込まれるテンプレート内に配置する。
<form action="/search.html" method="get">
<input type="search" name="q" placeholder="Search"/>
</form>
検索結果ページsearch.htmlを作成し、空のdiv要素をひとつ置いておく。
<div id="matchedList">
</div>
JavaScriptによる検索
search.jsを作成し、前節のsearch.htmlに読み込ませる。
search.jsの要点を書くと、
search.htmlはGETリクエストが送信されているので、URL文字列から検索キィワードを取り出し、整形するsearch.jsonを読み込むsearch.jsonから読み込んだブログ記事情報の配列から検索条件に合致するものを抜き出し、search.htmlに配置しているdivに情報を整形して埋め込む
本文にキィワードが含まれているかどうかはString.match()の正規表現を用いた。たとえばキィワードがjekyll 検索であれば(?=.*jekyll)(?=.*検索)という正規表現を本文文字列に対して用いた。この場合は、本文文字列内に「jekyll」「検索」の両方（順不同）が含まれている場合にマッチする。
まとめ
実際のファイル構成はGitHubリポジトリィを参照。
この方式の問題点はブログ記事数が増えるごとに生成されるJSONファイルが肥大化し、検索速度が低下することだが、それはそのときになって考えれば良いとして、今回はこれまで。
2013年11月26日, 編集履歴
日本電子出版協会（JEPA）というところの電子出版アワード2013にMurasakiがノミネートされてました。エキサイティング・ツール賞というジャンルです。
公式サイトの候補作品リストで他の候補を見てみると企業や有名なひとばかりで、その中にぽつんとひとりだけ場違い的にTwitterアカウント名義な私がいます。エキサイティング・ツール賞の候補作品は、
勝てる気がしねぇ……。
12月5日の22:00まで電子出版アワード2013 投稿フォームからどなたでも投票できるようなので、応援していただける方はぜひ。
他の候補者のブログ記事
2013年11月23日, 編集履歴
ブログに表示するSNS連携ウィジェット等にposition: fixed;を指定して固定位置に配置しているものを最近よく見かける。
しかしながらposition: fixed;を使う場合は慎重になるべきである。
マージンを取った余白に配置しているつもりかもしれないが、ウィンドウサイズによってはウィジェットが本文にカブってしまっていることがよくある。制作者が想定しているウィンドウサイズで皆が閲覧しているわけではないのだ。スクロールさせたりウィンドウ幅を広げたりして、なんとか読めるようになることもあるが、手間であるし非常に読みづらい。酷いときはブラウザをフルスクリーン表示させて横幅1280ピクセルとってもまだ本文にカブってしまうブログも複数見かける。
また、始めは非表示、あるいは最小化されていたのに、本文末尾付近までスクロールするとにょきっとアニメーション付きで大きくなるウィジェットも見かける。たいていは本文を読みきる前ににょきにょきと現れて本文を隠す。隠さずとも急に現れることで視線を奪い、本文を見失わせる。
ウィジェットだけではない。固定配置しているヘッダメニューやフッタメニューも同様である。頻繁に用いるわけでもないメニューがウィンドウ内の場所を占有し、本文のスペースを奪う（ツール的なウェブアプリケーションの場合は可）。
本文が大事なのであって、ウィジェットやメニューは添え物にすぎない。あったら便利程度のものが主客転倒し本文を読みづらく、あるいはまったく読めなくする。本文にカブる危険を冒してまで固定位置に配置する価値のあるものかどうかを一度よく考えてみるべきだと思う。
SNS連携ウィジェットなどはタイトル見出し付近、あるいは本文末尾に通常配置すれば十分に用を足す。ヘッダメニューは、本文が短ければわざわざ固定配置するまでもなく、ちょっとスクロールすれば一番上まで到達できるし、本文が長い場合はメニューでスペースを占有させるより本文領域を広くとった方が読みやすくなる。
固定配置を使う前に、それが本当に必要なものなのかよく考える必要があるだろう。