feed
2014年02月24日, 編集履歴
Tomboというウェブブラウザアプリケーションのベータ版を公開しました。以下はTomboのデモ動画です。
レスポンシヴなウェブページを作成する際、様々な画面サイズの端末を持ち出したり、ウィンドウサイズを色々変えたりして表示確認をするのは面倒な作業です。Tomboを使うことでそれらの手間が軽減できます。
Tomboは、サイズが異なる複数のウィンドウで同時にページの表示確認ができるウェブブラウザです。それぞれのウィンドウ間でページ読み込みの同期、大まかなスクロール位置の同期を行います。
ベータ版ダウンロードはTomboのページから。ご意見、ご感想、バグ報告等ありましたらぜひメイルフォームか開発者のTwitterまでお知らせください。 公開停止しました。
2014年02月22日, 編集履歴
2段階認証プロセスの確認コード取得をテキストメッセージ方式にしているひとは、新しい携帯端末で確認コードを受け取れるように設定し直しておくことを忘れないようにしよう。
Googleアカウントのセキュリティ強化のために「2段階認証プロセス」を設定しているひとも少ないないと思う。
2段階認証プロセスはアカウントに携帯電話等の携帯端末を紐付ける。認証されていない端末からGoogleアカウントにログインしようとすると、紐付けられた携帯端末に確認コードが送信され、そのコードを入力しなければログインできなくするという仕組みである。
携帯端末で確認コードを受け取る方法は3つ。
- テキストメッセージ
- 音声通話
- Google Authenticator(スマートフォン用アプリケーション)
このうち、1.のテキストメッセージを受け取る方式を選択しているひとは、MNPをした場合に注意しなければならない。
テキストメッセージ方式は、アメリカ等の場合は電話番号宛てのSMSで送信されてくるようだが、日本ではSMSではなくキャリアメイルアドレス宛てにしか送信されない。MNPによって携帯電話キャリアを移行すると、当然移行前のキャリアメイルアドレスは使用できなくなるので確認コードが受け取れなくなってしまう。
MNPしたらすぐに他の認証済みの端末で設定を変更し、新しい携帯端末で確認コードを受け取れるようにしておくことを忘れてはならない。
現状、二年ごとにMNPすることが消費者にとって経済的には有利な行動である。したがって、そういう行動指針を採り、かつテキストメッセージ方式を選択しているひとは、二年ごとに2段階認証プロセスの設定を変更する必要が出てくる。設定変更は「忘れてはならない」ことであるが、二年周期ではついうっかり忘れてしまうかもしれないし、忘れておらずとも、設定変更を行うまでに確認コードを取得できない空白期間が生まれる。
その空白期間にクリティカルな状況に陥ることがないとは言えない。そうならないためにも、確認コード取得の手段はキャリアメイルアドレスに依存するテキストメッセージ方式ではなく、他のふたつの方式を選択しておくべきであろう。
音声通話形式は登録した電話番号宛てに電話がかかってきて確認コードを聞くことができる(ちゃんと日本語音声でかかってくる)。Google AuthenticatorはiPhoneやAndroid等にインストールするアプリケーションから確認コードを取得できる。
これらの方式であれば、MNPによる空白期間が存在しないはずである。確認コード取得のメイン方式をGoogle Authenticatorを選択。メインが使えないときに代わりに使用するバックアップの方式も設定できるので、そちらは音声通話方式を選択しておくと良いだろう。さらに、メイン・バックアップ両方が使えない状況のために、バックアップコードのダウンロード・印刷もしておくと安心。
とは言え、確認コードを受け取る携帯端末の紛失やバックアップコードの流出等があっては元の木阿弥なので、管理には気をつけなければならない。
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ファイルが肥大化し、検索速度が低下することだが、それはそのときになって考えれば良いとして、今回はこれまで。