カテゴリー別アーカイブ: サイトA

MySQLデータベース使用の写真+記事サイト

Webフォントにそろそろ手を出すの事

WordPressでは、ヴァージョン3.6とTwenty Thirteenのペアから本格的採用が始まったWebフォント（WebFonts）。WordPressでの新技術採用は見切り発車というか地固めというか、1年くらいして各社ブラウザがWordPressに合わせてくるのを待って、次第に導入するのが都合が良い。HTML5然り、レスポンシブデザイン然り。それで、Twenty Thirteenの登場からは1年というタイミング、そろそろ趣味のサイト以外でも採用して良い頃合いなのではないかなと思ったので、なるべく安牌的な導入方法を調べてみることにした。

Webフォントの概要

Webフォントというのは、従来のようにユーザのローカル環境にあるフォントを引っ張ってきてWEBコンテンツを表示させるのではなく、WEB制作者側があらかじめ指定したフォントをユーザ側にダウンロードさせて、ある程度制作者側が想定した通りの表示内容で表示させる仕組み。この仕組みがあれば、font-family : sans-serif;のように指定した結果がWindows環境とMac環境で全く異なって表示されてしまうという、デザイン上の困り事も軽減される。

採用のデメリットは、Webページが重くなること。何しろフォントセットを丸々ダウンロードさせるわけで、特にモバイル環境のユーザに対してはストレスを与える結果になる事が多い。また、サイトの表示が重くなると、SEO的観点からもあまりよろしくない。この辺りは膨大な文字数が必要な日本語フォントでは、とりわけ顕著である問題。

Webフォントの仕組みはCSS3の正式規格で、これ自体をサポートしていないブラウザは切り捨てる方向で話を進める。こういう話のときに取り残されるブラウザは大抵IEなのだが、実は元々WebフォントはIEの拡張規格から来ているので、案外IE4などでも使えたりする。ただ、IE8以前の場合はフォントの規格自体がEOTという独自路線のみ対応なので、場合によっては切り捨ててしまった方が面倒でないだろう。

Webフォントとして使用できる形式

そう、どのタイプのフォントがWebフォントとして使用できるかは、ブラウザ側の対応状況に依存する。TrueTypeフォントやOpenTypeフォントはPC環境に付属する一般的なフォントだが、Firefox、Chrome、Safariともにかなり以前のヴァージョンから対応している。また、Mobile SafariではiOSの4.2から対応している。日本発売のiOSデバイスならば、上限までアップデートすれば全デバイスで表示が可能ということだ。
TrueTypeやOpenTypeを表示できないのが、IE。先程も書いた通り、一貫してEOT形式を採用してきた。そのため、表示したいフォントがTrueTypeやOpenTypeであった場合、EOTに変換した上で、同じフォントをIE用に指定して読み込ませるという方針が考えられる。
TrueTypeフォントのEOTへの変換は、WEBサービスやローカルアプリケーションなどが検索すれば出てくる。代表的なところとしてはココ。

.ttf／.otfとEOTの組み合わせ指定の場合

TrueTypeならびにOpenTypeフォントと、EOTに変換後のフォントが揃ったと仮定する。IE以外で未変換のフォント、IEでEOTフォントを表示させるように指定するには、スタイルシートに以下のように書く。

/*mplus-1c-thin.ttfというファイルを元にする場合*/
/*EOTはmplus-1c-thin.eotというファイル名で作成したと仮定*/
 
/*今回使用するフォントにtestfontという名称をふる*/
@font-face{
	font-family: "testfont";
	src: url("mplus-1c-thin.eot");
}
@font-face{
	font-family: "testfont";
	src: url("mplus-1c-thin.ttf") format("truetype");
}
 
/*h1見出しのフォントを全てtestfontにする場合*/
h1{
font-family: "testfont";
}

あらかじめ@font-faceでfont-familyの名前空間を確保しておき、srcでパスを指定する。その後、実際に使う箇所ではfont-familyで呼び出す。何も難しいところは無い。ただ、IE用のEOT指定の場合はformatをつけてはいけないというところは注意だ。
このように.ttf／.otfと.eotの組み合わせ指定をすれば、4以上のIEを含めた大抵のブラウザで表示が出来る。カバー率は高いだろう。

WOFFを使用する場合

ただ、TrueTypeやOpenTypeをそのまま指定する方法には、閲覧者がフォントをそのままダウンロードできてしまうという短所がある。WEB制作者的にそれで困るところはあまりないが、フォントメーカーなどはそれでは困るので、Webフォント用の新規格としてWOFFというのが策定された。最新ブラウザなどは一様に対応しているし、これから主流になっていくであろうフォーマットだ。
WOFFのメリットとして、著作権情報が盛り込めたり、データを圧縮できたりというものがある。特に後者の恩恵は大きい。

/*mplus-1c-thin.woffというファイルを元にする場合*/
 
/*今回使用するフォントにtestfontという名称をふる*/
@font-face{
	font-family: "testfont";
	src: url("mplus-1c-thin.woff") format("woff");
}
 
/*h1見出しのフォントを全てtestfontにする場合*/
h1{
font-family: "testfont";
}

WOFFに対応するブラウザは、IEは9以降、Chrome、Firefoxは割と前のヴァージョンからに対応しているので意識しないで良いだろう。Safariでは、Mac版、iOS版とも対応は5.1からと遅めで、これはOSX10.6 Snow LeopardとiOS5以降となる。iOS5以降ということで、日本発売のiOSデバイスではiPhone3Gが非対応になるし、iPhone3GSでもiOS5にアップグレードしないユーザは切り捨てだ。WOFFだけ指定するのは、MacやiOSにおいてもIE8以前バッサリ切り捨てと同じくらいの決断となる。
WOFFへの対応ヴァージョンの確認はこちらのページが便利だろう。

Webフォントのサブセット化

何とかWebフォントの容量を軽くしたいという場合には、サイト上で使う文字だけを組み込んだサブセットを作成する方法がある。武蔵システムのサブセットフォントメーカーというソフトを落として使うのが早い。サブセット化＆WOFF変換をすれば、日本語フォントでも常識的なサイズに落ちてくれる。

とは言え、日本語Webフォント導入の動機は薄いかも

各社ブラウザの対応によって、確かにWebフォント導入への障壁は低くなっている。ただ、そのわりにWebフォントを使ったサイトというのがイマイチ流行っていないのは、やはり日本語の文字数が膨大で、ページ本文のフォントとして使用するのがあまりにナンセンスだからだろう。例に挙げたmplus-1p-thin.ttfというフォントで1.6MB。フォントによっては20MBくらいになるものもあるので、気に入ったデザインのフォントをよく考えないで採用すると泣きを見る。あくまでせいぜいアルファベット程度の文字セットをダウンロードさせようという目論見から来ている規格なのだろう。

cPanelファイルマネージャに対するいくつかの不満点

コメントをどうぞ

以前の紹介記事で、cPanelのファイルマネージャはオフライン環境を一掃できるような多機能なアプリケーションだと書きました。しかしながら、使い込んでいくと判る不便なところもあります。今回は一般的なオフラインアプリケーションと比較して、cPanelが劣っている点について書いてみようと思います。

まずはFTPクライアントの代わりとなる、ファイルマネージャの主要部分についてですが、以下のような不満点があります。

同じディレクトリに同じファイル名のファイルを作成しようとしたとき、代替案を出してくれない
ローカル環境からのファイルのドラッグ&ドロップに対応していない

まず上の項目についてはなかなか根深い問題のようで、この仕様に関連しているだろうと思われる不具合がたくさんあります。同名の新規ファイルが作れないことの他、同じディレクトリ内に既存ファイルのコピーが作れない（オフラインのFTPクライアントであれば、大抵は既存のファイル名の後ろに数字や文字列をつけた新しいファイルを作ってくれる）、はては別ディレクトリから同名のファイルを移動してくると、勝手に既存ファイルを上書きしてしまうなどの問題が発生します。これではうっかり操作ミスなどをしてしまった場合は一巻の終わりです。

下の項目も非常に不便な仕様で、ローカルのファイルをアップロードする場合面倒くさいだけではなく、フォルダを丸ごとアップする場合に、一度圧縮などで1ファイルに纏めた上でアップローダを使って上げなければならないという制約がつきます（まあ、アップローダと圧縮・解凍ツールは標準でついていますが）。

次に、付属のエディタであるHTML editor/Code editorですが、以下の点が不十分に感じられます。

拡張子が.htmlでないとHTML editorが立ち上がってくれない
指定文字コードでうまく開いてくれない場合がある。開き直さなければならない

前者は拡張子.tplのテンプレートファイルや、phpコードを含んだhtmlファイル（拡張子.php）をエディットする時に不便です。拡張子に関わらず両方のエディタを選択できるようにしなかったのは、どうにも不可解な仕様に思えます。

以上、総括するならば、オフラインのアプリケーションと比べてかなり大味な作りになっているということが言えると思います。オフラインのアプリケーションであれば、環境設定パネルなどでアプリケーションの挙動をかなり変えられるのが普通ですが、このファイルマネージャのsettingメニューには、文字コードについての確認ダイアログを出すか出さないかの一項目しか存在しませんでした。つまり、オフラインアプリケーションの代わりにファイルマネージャを使うためには、相応の忍耐強さと、アプリケーションの挙動についてある程度予測できる洞察力が必要なのかもしれません。

今回は悪い点ばかりを列挙しました。前回便利な点ばかり挙げたエントリと合わせて、サイト作成環境選びの判断材料に使ってもらえれば幸いです。

サブドメイン設定とシンボリックリンクの作成

コメントをどうぞ

前の投稿の続きになります。

サイトAにサブドメインを追加することが決まったので、優等生アプリケーションcPanelを使って設定します。cPanelのDomainsのボックスにSubdomainsがあるのでクリック、サブドメイン設定のページに遷移するので、テキストフィールドにサブドメイン名とサブドメインのドキュメントルートを入力して終わりです。ドキュメントルートとは、サブドメインhttp://××.○○○.com/にアクセスされた時に開くディレクトリのことで、今回サイトAのサブドメインhttp://en.○○○.com/のルートにはhttp://www.○○○.com/enというディレクトリを作り指定しました。

さて、前回のエントリで書きました通り、サブドメイン設定後にある問題にぶちあたりました。サイトAではサイトに共通のスタイルシートをhttp://www.○○○.com/cssにまとめて置いていたのですが、http://en.○○○.com/以下のファイルから相対パス指定でアクセスしようとすると、not foundになってしまうのです。サブドメインのドキュメントルートをhttp://www.○○○.com/enにしているわけですから、cssディレクトリ中の例えばsample.cssというファイルにアクセスするには、相対パスで”../css/sample.css”と指定すれば良いと思っていました。しかしエラー表示を見ると、要求したアドレスの頭がhttp://en.○○○.com/になっています。つまり、サブドメインを作成してしまうとそのアドレスのドキュメントルートにどのデイレクトリを指定しているかに関わりなく、アドレス要求の頭がサブドメインになってしまいそれ以上遡れないようになるのです。

調べてみると、この問題を解決するための考え方には以下の3通りがあるようです。

ディレクトリ構成を再考する
ファイル指定は常に絶対パスで行う
サーバのOSであるUNIXのファイルシステム上で設定をいじる

まず一番上のディレクトリ構成の再考ですが、簡単に言うと大前提である一箇所に纏められたcssファイルの使用をあきらめるということになります。サブドメインに個別のcssデイレクトリをつくって、一部の共通スタイルシートは重複して存在させるようにします。この方法であればサブドメインから遡れない箇所にあるファイルにアクセスしなくて済みます。ただ、当然ながら片方のcssファイルに加えた変更はもう片方に反映されないため、サイト全体に関わるスタイルの変更を行う時には、共通ファイルに複数の版が存在してしまわないよう気をつけなければなりません。

次に、絶対パスの使用です。簡単に言うと相対パスを使わず、ファイルを呼び出す時は必ずhttp://から始まるアドレスを入力するという方法です。PHPなどのスクリプト言語が使用できる環境なら、http://www.○○○.com/の部分を定数として定義、cssファイルなどが呼び出されるときに文字列連結するようにすれば、将来的にドメインを移行することになっても修正箇所が少なくて済みます。

最後のひとつ、UNIXファイルシステムの機能を使う方法は、windowsのショートカット、MacOSのエイリアスにあたるシンボリックリンクを使う方法です。今回の解決法にはこれを採用しました。

とは言えUNIXコマンドの知識は皆無だったので、webで調べながらコマンドを打つ方法では操作を間違えてしまった時に何が起こるのか予想もつかないということで、もう少し簡単で安全な方法を探しました（本当はcPanelに標準でついていてほしい機能だったのですが）。すると、どうやらPHP4以降のバージョンにはシンボリックリンク作成のためのsymlinkという関数が搭載されているようです。

symlink関数は、symlink(引数1,引数2)という書式をもち、引数1にはリンク先（上の例でいうならhttp://www.○○○.com/以下のcssデイレクトリ）、引数2には新しく用意するパスを与えます。ただこの際に行うのはあくまでサーバのUNIXファイルシステムに対する操作なので、http://から始まるパスではなく、サーバから提供されたドキュメントルートのパスを与えてやらなければなりません。このサイトAの場合には、/home/ユーザ名/public_html/がドキュメントルート（http://www.○○○.com/でアクセスできる場所）として与えられていたので、symlink(/home/ユーザ名/public_html/css,/home/ユーザ名/public_html/en/css);という命令を実行してシンボリックリンクを作成しました。

さて、こうしたシンボリックリンクを作成の度に手打ちでphpファイルを修正、ブラウザからアクセスという手順を踏むのは面倒です。そこでフォームから与えられたパスでリンクを作ってくれるphpファイルを作成しました（右クリックメニューからからダウンロードを選択してください。あと圧縮ファイルなので実行時には解凍してください）。

Symlinkcreator.rar（2012.6追記：配布終了しました。代わりにソースコードを書き連ねておきます。）

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>tool_symlink</title>
</head>
<body>
<p><strong>Create a symboliclink of selected file/directory.</strong></p>
<p>Paths like /home/username/public_html/... are required.</p>
<form action="tool_symlink.php" method="post">
<p>Original to a link : <input type="text" name="linkoriginal" /></p>
<p>Jump from this new path : <input type="text" name="jumpfrom" /></p>
<p><input type="submit" value="create" /></p></form>
<?php
if(!empty($_POST["linkoriginal"]) && !empty($_POST["jumpfrom"])){
if(file_exists($_POST["linkoriginal"])){
if(file_exists($_POST["jumpfrom"])){
echo "ERROR : The name you entered for symboliclink is already used.<br /> ";
}
else{ 
symlink($_POST["linkoriginal"],$_POST["jumpfrom"]);
echo "Symbolic link <strong>".$_POST["jumpfrom"]."</strong> to <strong>".$_POST["linkoriginal"]."</strong> is now available.";
}
}
else{
echo "ERROR : The file/directory you have requested as original is not found.";
}
}
?>
</body>
</html>

ちなみにセキュリティ対策は何も行っていないプログラムなので、外部からアクセスできないデイレクトリに置いて使う必要があります。あとこのプログラムによって引き起こされた損害に対して作者は責任を負いません。実際簡単なプログラムなので、無許可で改変して実用化してもらえればと思います。

解決法に辿り着くまで、それから実際にプログラムを完成させるまでかかった時間を、同じ問題にぶつかった人がこれで短縮できればと思っています。

サイトAにサブドメインを設定するべきか

1件のフィードバック

サイトを巡回していると、http://www.○○○.com/××といったwwwから始まるページアドレスの他に、http://××.○○○.comのような任意の単語がドメインネームの前に置かれたアドレスのページをよく見かけます。例えばgoogleであれば、検索のトップページhttp://www.google.com/に対して、google docsのページはhttp://docs.google.com/、google mapsのページはhttp://maps.google.com/のように提供する機能の単語をドメインネームgoogle.comの前につけています。

これがサブドメインと言われるもので、ディレクトリへのパスをそのままページアドレスにする方法に対して有利な点がいくつかあります。具体的には、

深い階層にあるデイレクトリに、短いアドレスでアクセスできる
検索エンジンの検索結果として、1サブドメインにつき1件として扱ってくれる場合がある

一方で、検索エンジンの被リンク数をドメインの評価として加算していくアルゴリズムを考えると、サブドメイン毎に加算ポイントがばらけてしまう状態はSEO的なディスアドバンテージになります。このようにサブドメインでの運営は長所も短所もあるので、実際に導入する場合にはサイトの将来的なプランに沿う選択であるか考えてみる必要があります。

さて、サイトAの計画には、日本語ページの他に英語版のページをつくる予定がありました。この英語版ページにはサブドメインhttp://en.○○○.com/のようなアドレスを設定しましたが、それは以下のような理由によるものです。

日本語版と英語版で提供する機能は違うものを想定している
英語版のアドレスからサイトにやってきた人が、日本語のコンテンツに遭遇してしまうことを避けたい

つまりページの想定している客層が異なるので、不必要な導線は除いておく必要があったのです。例えば英語版を閲覧していた人が存在しないページのリクエストを送ってしまった場合、404エラーのページから自動的に戻る、あるいはアドレスを削って辿り着く先が日本語版ページのトップだと不安になってしまうのではないかと思うのです。

そういうわけで、サブドメインを設定するかどうかの問題は解決しましたが、設定時には予期せぬ落とし穴にハマってしまいました。サブドメイン設定時には気をつけなければならない問題なのですが、それは次のエントリにでも書こうと思います。

cPanelの多機能なファイルマネージャ

1件のフィードバック

サーバ管理ソフトウェアcPanelには、標準で多機能なファイルマネージャが付属しています。

このスクリーンショットで大体何ができるかの説明は済んでしまっているような気がしますが、あえて機能を箇条書きにしてみます。

ファイルのアップロード・ダウンロード
新規ディレクトリ、ファイルの作成
コピーや移動、名前の変更などのファイル操作
ファイルの圧縮・解凍
アクセス権の変更
コード/HTMLエディタ

このような機能があります。つまり基本的にFTPクライアントでできることがオンラインでできるようになるため、サイト作成のために別途FTPクライアントを用意する必要がありません。

また、最後に挙げたコード/HTMLエディタは出来の良いシェアウェア程度の機能を備えているため、サイト作成の中心的なツールとなり得るポテンシャルがあります。以下にスクリーンショットを何点か用意しました。

左の2点（それぞれcss、phpを編集しています）のスクリーンショットで立ち上がっているのは、code editorというアプリケーションです。一方右の2点は拡張子が.htmlのファイルのときに選択できるHTML editorです。
コードビュー、デザインビューといったHTMLエディタではおなじみの機能も備えています。

さて、こうしたFTP機能と強力なエディタをcPanelは標準搭載しているわけですが、そうなればcPanelを採用したサーバでサイト作成をする場合、従来の作成手順、”ローカルで作成したファイルをサーバにアップロードする”を踏襲することなく、完全にオンラインの作業でまかなえてしまえることになります。この方法ではローカル環境とリモート環境で気付かぬうちに複数の版ができてしまうという問題を解決できるばかりでなく、GoogleDocsのような、自宅、職場、ネットカフェなどの環境を問わず作業ができるという恩恵も受けられます。

ということで、サイトAの作成にはこのcPanelの環境を用いてみることにしました。使い込んでいくうちに足りない部分や不具合などが明らかになってくると思うので、それはその都度このブログで報告していきたいと思っています。

（2012.6追記：サイトの一時閉鎖の影響で、スクリーンショット画像が無しの状態になっています。想像を掻き立ててください）

cPanelについて

コメントをどうぞ

契約前は全く知らなかったのですが、WebhostingPadはサーバ管理ソフトウェアのcPanelを採用したサーバでした。契約手続きが完了するとこのcPanelのアカウントが発行され、以降は各種設定変更もこのソフトウェア上で行うようになっています。個人的にとても使い易いと感じたので、少しだけこのソフトウェアについて調べてみました。

まずサーバ管理ソフトウェアの役割についてですが、サーバ管理のために必要な各種コマンドを、コマンドラインでの操作ではなく直感的なインターフェースで行えるというメリットを管理者側に提供します。のみならずcPanelなどのソフトウェアはサーバ利用者側からの変更手続きにもわかり易いインターフェースを提供します。ちょうどwindowsのコントロールパネル、MacOSXのシステム環境設定パネルのような外観になっています。

利用者がいじることを許可された設定項目は、この画面にアイコンとして現れます。

コントロールパネルをもったサーバ管理ソフトウェアとしては他に、Plesk、Webminなどがメジャーなようです。日本のレンタルサーバでは設定画面を自前で用意している場合が多いのに対し、海外サーバではこうしたサーバ管理ソフトウェアを導入し、設定画面の使用方法についてはwebの解説をあたってくれという態度のサーバが多いようです。サーバ側としては人的ソースの節約になりますし、ユーザ側としては操作に一度慣れてしまえば、サーバを移転した際にも操作に戸惑わずに済むという利点もあります。

さて、以上サーバ管理ソフトウェアの概観でしたが、cPanelがサーバ管理ソフトウェアの選択肢としてどうかということに関しては、比較を行ったわけでも管理者として導入してみたわけでもないので言及ができません。あくまでこうしたソフトウェアに触れるのがはじめての利用者側の人間として、以下の機能がついているのが特に便利だと感じました。

サイトのバックアップ機能
ファイルマネージャ（GUIのFTPソフトのような外観）で書類を選択し、直接編集もできる
アクセス統計
ディレクトリにパスワードをかけたり特定のIPからのアクセス拒否が手間なくできる
サブドメインの追加

この他にも機能がたくさんありそうです。ちなみにcPanelは多言語対応でもあり、説明やシステムメッセージの言語として日本語を選ぶこともできます。90点くらいの日本語なので、90点あれば十分と感じる人にはここも訴求ポイントになると思います。

以上がcPanelについてでした。個人的によく使う機能の解説は以降のエントリでも行っていきたいと思っています。

WebhostingPad契約時の注意点

コメントをどうぞ

前回の続きです。

WebhostingPadの契約手続きは、次のページを参考にしながら行いました。

http://webhostingpad.e-saba.com/　WebhostingPadのレビューと検証

（直リンクはリンクポリシーを見つけることができなかったのでしません）

ほとんどこのページの手順通りで済んだのですが、ドメイン料金を総額からディスカウントするという請求の仕方のため、総額表示が高くなっているように見えるという不安なポイントがあります。また有料オプションの選択も訊かれるため（その文章にはfreeという単語も入っているので、ホイホイと選んでしまわないよう注意）国内サーバとの契約と同じように不安なく進んだかと言えば、そうでもなかったりします。契約画面、文章もこのページの書かれた頃とは異なっている可能性もあるため、英語に自信がない場合は得意な人に手伝ってもらった方が良いかもしれません。