公開当初とくらべて以下の点が変わりました多分、Movable Typeを使ったことがある人が多いので説明などは今回は省かせていただきます。公開時に比べ、以下の点を改善しました。 Movable Typeのテーマを/mt/themes/にアップロードするだけで画像なども適応される@ADD_TO_SITE_NAVへの対応（ウェブページでタグを入力し、サイト全体を再構築することでナビゲーションへの追加HTML5宣言の統一（今まではXHTMLとか混ざってた）時代の進歩というものです。一応、HTML 5に適応するようになっています。 Movable Type 6で対応したDataAPIなど色々としたかったのですが、時間がなかったので追々別のテーマなどでしてみたいと思います。それと、FlexibleSearchなどしたいところもありますし。 ダウンロードダウンロードに関して、以下の条件を守ってください。 アダルト系サイト、反社会的な内容や暴力的・猟奇的表現を含むサイト、違法サイト（マルチ商法まがいの内容も含む）での利用を禁止します。このテーマを使用したことによるいかなる損害・損失・第三者と生じた紛争等について、一切責任を負いません画像はリンクウェアです。フッターリンクを消さないよう、お願いします。こんな機能を追加してほしい！というリクエストはご遠慮ください。次回製作時の参考にさせて頂きます。不具合報告は受け付けておりますが、カスタマイズ方法など、技術的サポートは致しかねます。※ 過去にWebクリエイターボックスに寄稿（公開）した記事より ダウンロードはこちらより 記載してあります通り、不具合などに関してはMovable Type 6環境（このサイトとローカル上のMovable Type）で検証しているため、多分大丈夫だと思います。もし、何かあれば@nasa114までお願いします。

さ...削除ができないGravatarの管理画面から各種プロフィールは変更することが可能なのですが、なんとウェブサイトの変更ができない...。js（JavaScript）が違うのかな、と思い停止してやってみると、デザインが崩れてしまいました。「日本語で調べれば...」と思い調べてもダメだったので英語で調べると、以下のサイトが出てきました。 Cannot Delete Websites from Gravatar 最終的にはスタッフのjackiedanaさんが回答していたものが良いと私は判断しました。回答を以下に引用させていただきます。 If you have a blog on WordPress.com, you can log into your WordPress.com Dashboard and remove the link by navigating to Users > Personal Settings. The Gravatar page method is currently broken, but it has been reported to our developers and we hope it will be resolved soon. 引用::Cannot Delete Websites from Gravatar つまり、『WordPress.comの管理画面の設定から公開プロフィールで変更ができる』ということです。また、併せてGravatarのページは現在壊れててそのうち治る的なことも記載されています。（ここは曖昧） 大体GravatarのシステムはWordPress.comを運営しているAutomatticが開発・運営しているため、アカウントを取得するとWordPress.comも使えるようになっていると思います。ブログを作る・作らないは別としてですが。 変更方法（WordPRESS.comを利用した）ということで、WordPress.comにログインして変更しましょう。自分のGravatar（アイコン）にマウスのカーソル（矢印）を当てると、以下の様に出てくると思います。 次に、Settings（設定）をクリックします。以下の様な画面に切り替わると思います。 最後に、公開プロフィールをクリックして下の方にスクロールします。 これで追加・削除ができるようになります。削除などしたらすぐに反映されるみたいです。Gravatarのサイトのバグがいつ治るのか分かりませんが、当面はこのままな感じですね。 2014年2月10日追記::このバグが出ていない人（ユーザー）もいるみたいです。出ていない人はそのままで大丈夫だと思いますが、ユーザーごとのバグって...。

Route 53はリクエスト・DNS登録数課金型今までのDNSサービスと圧倒的に違う点といえばここだと思います。大規模なサイト（GIGAZINEとか）となってくると独自で構築してたり、別途お金を払ってサービスを使っていると思います。 なので、テスト環境としてはあまり適していない...といえばそれは違う話で、サービスを組み合わせて利用することで色々とエラーページを出したりできてしまう、そんなサービスなのです。 世界各国のデータセンターから取得するのでDNSが早い日本を含め、複数の国にAmazonはデータセンターを持っています。そのメリットを活かし、複数の国のデータセンターを利用し、Route 53 を提供しています。災害時や何かがあった時でも複数の国からホスティングしているのでサーバーが落ちていない限りは大丈夫だと思います。（たいていは東京がベースになっており、東京が落ちたら...とかある。さくらは大阪なのかな...） また、ドメインも違うドメインが提供されるので、ドメインの更新を忘れることは多分ないとは思われますが、ドメインの有効期限が切れても残りの3つで補充されているという感じです。 こんな人には推奨以下の様な条件に当てはまる人は使えば良いと思います。 AWSサービスを使う方（CloudFrontとか）なるべく世界各国からDNSの取得速度を少しでも早くしたい対価がしっかりと払える方逆に、以下の様な方はGehirn DNSなどの別のサービスを検討されたほうが良いと思います。 DNSにお金を払ってられるかという人セキュリティの理由で独自構築をしないといけない人Amazon Web Servicesを1つも使ってない人大抵の人はドメインを取得してきた時に附属しているものを利用される方というのが多いように思えます。しかし、Amazon Web Servicesを使ってコンテンツを公開している人はRoute 53を利用されたほうが良いと思います。 開始方法Amazon Web Servicesを使ったことのある方であれば、ダッシュボードにアクセスし、Route 53をクリックします。 次に以下のような画面が出てくるので、"Create Record Set"をクリックしましょう。 クリックすると、以下の様な画面になっていると思います。 ドメイン名を入力し、Createをクリックします。すると、左側にドメイン名が追加されていると思います。 追加されたことを確認し、対象ドメインをダブルクリックします。 NS部分（画像では白く空白になっているけどネームサーバー）をドメインを取得した業者で変更をします。また、ドメインを今ウェブサイトなどで運用しているという方はドメインのレコード（AレコードやMXレコード）をすべて移した後にネームサーバーを変更すれば良いと思います。

世代別管理世代別管理というのは、ソースコードなどであればGithubというサービスを知っている方も多いと思います。どこが変わったのか明確にわかるので、説明などをするときに便利なサービスです。 Movable TypeやWordPressのテーマも同じことが言えて、改造した箇所などをメモしたり保存しておかないといけないです。最近では、Githubなどのgitをつかった管理などもできるようになっているみたいです。（この記事はGitを使おう！的な記事ではありませんので、Gitの使い方に関しての説明は割愛させていただきます。） 世代別管理をしていると、安心してファイルの編集ができる世代別管理をしていると、先日のMTDDC Meetup Nagoya 2014での"ファイルが壊れた！"という緊急事態にも対応することができます。 IT系イベントであればだいたいインターネットに接続したりしている場合がほとんどだと思います。Dropboxの公式サイトにアクセスして、対象のファイルを選択し、バージョンを戻すだけです。 使い方ということで、使ってみたいと思います。私は英語でDropboxを使っているので英語にっていますが、多分日本語でも同じような感じでしょう（たぶん） 1. 対象のファイルをウェブサイト上で開くこんな感じでブラウザを開いてログインして開きましょう。 2. ファイル操作一覧の右側の拡張（More）をクリック3. 復元する戻したいバージョンに復元しましょう。 3ステップでできるので、"ファイルが壊れた！"とか"ブログのロゴデータとか..."、"Git使うの面倒だけどテーマ管理したいし..."という人には向いていると思いますので、使ってみてください。 Dropbox

統一してなにか良いことあるの？統一して良いことというのは、管理が楽だったりURLが1度変わるだけという点です。 SSL対応のサイトに接続したりする人がおられると思いますが、制作している側からすると"どちらでアクセスされるのかわからない"ということがあります。そのため、このサイトでは内部リンクではURLを使わずに更新するようにしています。Movable TypeなどのCMSを利用していると、SSL対象のページにはこのURLで...という対応が正直めんどくさくなるというのもありますが。 全部SSL対応にすればいいじゃん多分、ここまで読むとそう思われる方もおられるかもしれません。ごもっともな意見なのです。 最近、NTTドコモを始めとした企業サイトがすべてのウェブサイト・ページでSSL通信を用いたサイト運営を初めています。正直、どうして保護しているのか突っ込みたい所があるのですが。（閲覧履歴が〜とかだと思う） ただ、すべてHTTPS通信にしてしまうと以下のデメリットが発生します。 アクセスするまでに時間がかかる非公式テザリングユーザーが涙目になる（EasyTetherとか証明書を毎年更新しないといけない（＝高コスト）会員制サイトを構築してしまうとどうしてもメールアドレス等が個人情報となってしまうため、写真素材サイトでは構築していないのが現状ですよね。（それ以外にも管理が面倒とかあるかもだけど） SSL対応がすべて良いというわけではないのです。 対応方法レンタルサーバーを使っている場合は.htaccessファイルを利用できれば対応することが可能です。また、VPSであれば、以下のコードをバーチャルホストに追加することで対応できますし、Apacheを使っていれば.htaccessで対応することができます。 ドメインはexample.comで作成していますので、各環境に合わせて設定してください。...

ユニバーサル・アナリティクスになるらしい私はブロガーとしての利用者なのであまりわからないのですが、ウェブサイトなどでEC（通販）サイトを運営されている人などであれば設定などが変わるらしいです。 また、JavaScriptのファイルがga.jsからanalytics.jsに変更されています。Google Analyticsの管理画面よりアクセスして従来のものからユニバーサル・アナリティクスにアップグレードする作業が必要です。（私の場合は勝手にされてたのでキャプチャとかで説明ができない...。） アップグレード作業後に、ソースコードを変更しないといけないみたいです。 ソースコード以下の様な感じです。 (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga(‘create’, ‘UA-XXXXXXXX-Y’, ‘auto’); ga(‘send’, ‘pageview’); ※ UA-XXXXXXXX-Yは自分のトラッキングコードと置き換えてください。 もし、わからなければGoogle analyticsのサイトから確認してファイルを編集した後に再構築すれば良いと思います。（大抵の場合は再構築はないと思うけど） 今すぐやるべきなのか正直、私もわからないです。今すぐやらなくてもいいような気がします。（文献読んでてPublic betaとか書いてあったし） しかし、Windowsやアンチウイルスソフトウェアなどでもそうだとは思いますが最新のものにしていて損はないと思いますので、しておいたほうが良いとは思います。（法人のサイトになったらまた変わると思う） 詳しくは以下のページに記載されていますので、確認してみてください。 Universal Analytics アップグレード センター - アップグレード ガイド - Google アナリティクス — Google Developers

元はTwitterで。Twitterで以下のように言ってしまいました。 うちのサイトだけど、多分MTなほうはレスポンシブしてもタブレットまでだと思う。 — nasa114 (@nasa114) 2014, 1月 20 世の中ではレスポンシブ全盛期と言っても過言ではない時代に入ろうとしています。しかし、レスポンシブデザインによってユーザーが使いにくいサイトになってはいけないな、と思っています。（スマホとか特に） 別に、「レスポンシブの技術がないからできないんだ」とかというわけではありません。ただ、ウェブ技術でソースコードなどを掲載するときの見やすさを重視するとどうしてもスマートフォンを対象から外すかどうかというがあると思います。このサイトに限ったことではないとは思いますが、参考にしてもらえれば良いと思います。 ユーザーのターゲットをどこに当てるかユーザーをどこを狙うかによって変わってくると思いますし、内容でも変わってくると思います。 見てもらいたいユーザーにとって不便かどうかを自分がスマホでサイトを見ていると考えるといいと思います。私はスマートフォンでは縦方向のみのスクロールで済ませたいと思っています。横に移動してイラッとしてしまうことが多いのが原因です。 横方向のスクロールを無くしたいと一概に言ってしまうとYouTubeなどの動画を掲載したら...と色々と問題が出てきてしまうのですが、半分以上の記事やサイトで執筆する記事の内容でどうなのか、ということを考えれば良いと思います。 "タブレットサイズ"で切る理由このサイトは主にサーバーなどのフロントエンドの方向などで解説したりしていきたいと思っているので、「記事が読みやすく最適ではないか」と判断しているからです。 というのも、タブレットだと大体7型〜10型サイズで、特にiPadを基準として考えると情報を表示しておくためのモニタとして活用できるのではないかな、と思っています。4:3の比率の物が多いですし、10型となるとMicrosoftのSurfaceのサイズと同じぐらいのサイズですよね。とすると、外出先でノートパソコンと一緒に持ち運んだりしていて、コーティングやサーバー管理などの作業をしていて"あれ、これって何だったっけ..."となった時に横に置いて見ながらすることができます。他にも、ノートパソコン1台でやっていてもだいたい横600px〜700pxに合わせていれば今のノートパソコンの液晶の解像度の幅に適しています。（Macの場合は1440px，一般的なWindowsのラップトップは1366px） 自分が作業をしやすいから、というわけではありませんが画面の半分にした時のことまですこし頭のなかに入れているといいかもしれません。「ユーザー（＝閲覧者）が自分（顧客など）のウェブサイトをどのようにしてみるか」ということと「ウェブサイトに使っているプラグイン（SyntaxHighlighterなど）とサイトのデザインが干渉して結果見づらくならないか」ということを考えなければいけないかなと思っています。 スマートフォンまでしたほうが良い例最後に、レスポンシブデザインを採用したほうが良いサイトとそうではないサイトについてまとめたいと思います。ただ、個人の意見も入っていますし、見やすさ重視している部分もあります...。あくまでも一例です。 対応したほうが良いサイト個人のブログ（日記とかガジェットの紹介とか）トピックやニュースなどを伝えるメディア（特にスマホ用のものを扱っているところは）個人プロフィールサイトお店のサイト（スマホで店を調べて場所を調べることも多い） 対応しないほうが良いサイトソースコードなどをある程度扱う前提のサイト（シンタックスハイライトとか）企業サイト（情報量が多くなるし、表とか多くなるとそれに合わせてしないといけないからお金もかかる。）いずれにしても、ユーザーの見やすさを重視すべきではないかと思っています。タブレットであればある程度画面と解像度も大きいので情報の表示量を多くしても読みやすいですが、スマホは大きさ・解像度の療法が小さいのでどれくらいの情報にするかを考えなければいけませんね。 タブレットのサイズ（10型ぐらい）のパソコンとかあったので約10型のタブレットはパソコンと同じ量の情報を掲載しても問題ないのかなー、と思っていたりしますが...。

（2014年2月3日追記）現在はサービスの内容が一部変わっています。 Kiteと呼ばれるPaaSサービスがあります。日本ではだいたいheroku（ヘロク）が流行っているみたいですが...。 ...

こんなかんじUbuntu環境でしか保証してません。 #!/bin/sh #Directory Setting Path=’/var/www' UploadDir=‘ghost’ ServiceName=‘ghost’ User=‘ghost’ Group=‘ghost’ #Upgrade Work Start service $ServiceName stop cd $Path wget http://ghost.org/zip/ghost-latest.zip unzip -uo ghost-latest.zip -d $UploadDir chown $User:$Group -R $UploadDir cd $UploadDir npm install service $ServiceName start echo “Update of Ghost” echo “Thank you!"screenコマンドを使ってあげれば放置してても大丈夫ですね。一応、DigitalOceanで提供されているGhostを動かしているプログラムの設定を特に変えていなければこのままで大丈夫だと思います。 変えている方は以下の点を変えてください。 Path::Ghostが設置されている一つ上のディレクトリUploadDir::Ghostの本体が入っているディレクトリ名ServiceName::プロセス化している場合、serviceコマンドを使うときのプロセス名。User,Group::Ghostを動かしているユーザーとグループ。大体ghostというユーザーとグループなので問題無いと思う。ちなみに、RHEL系で試してみたらunzipあたりでエラーが出たので多分Ubuntu専用になるでしょう、多分。 そのうちMovable Typeも時間がかかりすぎるので作成します。（本来の目的はMovable Type。PSGIの時めんどくさいのもあるけど、時間がかかりすぎるため。あと、不要なプラグイン多いし…。。。。。）

体感的にコンテンツの読み込みに時間がかかるかどうか言ってしまえば、この点かなと思います。特に、日本とアメリカや日本とイギリス、のように海外をまたいでコンテンツを提供する場合に必要だと思います。 また、使用するファイルも色々と種類がありますが、JavaScriptや画像などサイズが重いもの（リンクして表示するもの）を利用すれば良いと思います。 作成してしばらくおいておくか、作成してもずっと更新し続けるかCloudFrontにかぎらず、CDNサービスを使うときはそうなると思うのですが、作成してからずっと更新するコンテンツであればCDNは局部局部で利用し、更新が多いコンテンツ（テキスト）はあまり使わないようにすれば良いと思います。 また、CDNを使えば必ず早くなるというわけでもありません。画像サイズの最適化や画像の無駄なタグ（Exif情報）などを削除した上で表示速度が遅いのであれば利用すれば良いと思います。JavaScriptやCSSであれば、空白などを削除してサイズを圧縮し、.minファイルを作成した上で利用するのが適切ではないかと思います。 ここではツールの説明をする記事ではないので割愛しますが、Online JavaScript/CSS Compression Using YUI Compressorを利用すれば機械的にしてくれるので楽だと思います。 早くなるのは5回目以降と思っておいたほうが気が楽早くなる、と言うのは読み込みの時間のことです。読み込み時間が早くなるのは1回目は元のオリジナルサーバー（CloudFrontだとS3とか）から読み込み、キャッシュしていくため、どうしても時間がかかってしまいます。しかし、読み込み回数が多くなるとCloudFront側にキャッシュされていきます。世界の各拠点で分散して配信されるため、どこで見ても表示速度が早くなったように思われます。 今後、Route53を使わなくてもS3を使ってキャッシュする方法を執筆しようか検討中です。（ちなみに、Route53少し高くて今はGehirn DNS使ってます。）