feed
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 」を参考にした。
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;を使う場合は慎重になるべきである。
また、始めは非表示、あるいは最小化されていたのに、本文末尾付近までスクロールするとにょきっとアニメーション付きで大きくなるウィジェットも見かける。たいていは本文を読みきる前ににょきにょきと現れて本文を隠す。隠さずとも急に現れることで視線を奪い、本文を見失わせる。
ウィジェットだけではない。固定配置しているヘッダメニューやフッタメニューも同様である。頻繁に用いるわけでもないメニューがウィンドウ内の場所を占有し、本文のスペースを奪う（ツール的なウェブアプリケーションの場合は可）。
本文が大事なのであって、ウィジェットやメニューは添え物にすぎない。あったら便利程度のものが主客転倒し本文を読みづらく、あるいはまったく読めなくする。本文にカブる危険を冒してまで固定位置に配置する価値のあるものかどうかを一度よく考えてみるべきだと思う。
SNS連携ウィジェットなどはタイトル見出し付近、あるいは本文末尾に通常配置すれば十分に用を足す。ヘッダメニューは、本文が短ければわざわざ固定配置するまでもなく、ちょっとスクロールすれば一番上まで到達できるし、本文が長い場合はメニューでスペースを占有させるより本文領域を広くとった方が読みやすくなる。
固定配置を使う前に、それが本当に必要なものなのかよく考える必要があるだろう。
2013年11月21日, 編集履歴
ブログ記事にタグを設定し、タグ一覧ページ を作った（2013年12月8日追記：「Jekyll製ウェブサイトに簡易検索機能を実装する 」にて実装した検索機能に統合したためdeprecated）。
Front-matterでタグを付ける
Jekyllでブログ記事を書くときに、Front-matterにタグを埋め込むことができる。この記事の場合だと、Front-matterは以下のようになっている。
---
layout: post
title: Jekyllで簡易タグページを作る
tags: jekyll github
---
tags:部分はスペース区切りかYAMLフォーマットのリスト形式で複数のタグを設定することができる。
タグ一覧ページを作る
タグを付けたら当然その一覧ページが欲しいが、Jekyllにはタグ一覧ページを出力する機能はついていない。プラグイン（Jekyllはプラグインで機能拡張ができる）でそういうのがあるのかもしれんけど、GitHub Pages 上でビルドする場合はプラグインは使えないので自分でなんとかするしかない。
あまり複雑なことをやろうとすると深みにはまるので、シンプルにいく。/blog/tags.htmlファイルを作成する。この中にブログ記事中で設定されているタグと、そのタグが付けられた記事を羅列する。今回は以下のような記述を/blog/tags.htmlに追加した。
{% for tag in site.tags %}
<article>
<h1 id="tag_{{ tag[0] }}">{{ tag[0] }}</h1>
<ul>
{% for post in tag[1] %}
<li><a href="{{ post.url }}">{{ post.title }}</a></li>
{% endfor %}
</ul>
</article>
{% endfor %}
site.tagsには全タグの情報がハッシュとして入っている。キィはタグの文字列、値はそのタグが付けられた記事の配列になっている。
Jekyll（Liquid）でハッシュを{% for %}文に掛けると、一時変数には各要素のキィ・値ペアが配列として渡される（インデックス0にキィ、1にその値）。上記の場合、{% for %}文の一時変数tagは配列になっており、tag[0]がタグ文字列、tag[1]がそのタグが付けられた記事情報の配列である。
ここではタグ毎に記事へのリンク付きでタイトルをリスト表示している。これにてタグ一覧ページは完成。
各記事にタグ一覧ページへのリンクを付ける
各ブログ記事にタグ一覧ページへのリンクを付ける。_layouts/post.htmlに以下のような記述を追加した。
<nav id="tags">
<h2>tags:</h2>
<ul>
{% for tag in page.tags %}
<li><a href="/blog/tags.html#tag_{{ tag }}">{{ tag }}</a></li>
{% endfor %}
</ul>
</nav>
page.tagsにその記事で設定したタグ文字列が配列で入っているので、これを使って{% for %}文を回す（注：site.tagsはハッシュ、page.tagsは文字列の配列である）。
問題点
今回のタグ一覧ページは簡易的なものである。ひとつのページに、すべてのタグとタグが付けられた記事を羅列しているだけで、「JekyllのPagination設定 」でやったようなページ分けもない。したがって、記事数が増えるごとにどんどん肥大化していくという問題がある。
それほど頻繁にブログを更新するわけでもなし、増えてきたら増えてきたでまたそのとき考えるということで、今回はこれまで。