HTTPSプロトコル経由だと表示が崩れる

設定でサイトのアドレスをhttpsプロトコル設定にしていると、なぜかcssファイルやjsファイルがhttpプロトコル指定になっていて、読み込みされず表示が崩れてしまう不具合があった。

HTST設定などやってみたが改善されず、ソースコードをチェックしてみるもよくわからずで、とりあえず設定でのサイトのアドレスをhttpプロトコル設定にすることによって暫定解決。原因調査を継続したい。。。

Movable TypeからWord Pressへようやく移行

お盆休みを利用して、当ブログを今年の2月から移行試験をしていたMovable TypeからWord Pressへの移行を本移行してみた。今更ですが。。。。

参考にしたサイトは、Movable TypeからWordPressへのお引っ越しはすごい簡単なことがわかった。
を基にデータ移行した。

データは問題なく移行できたものの、カテゴリについては親子関係を保持してくれないので、移行後に移行作業を手作業で行うという問題はあったものの、書きかけの記事も含めて移行できたので、概ね問題ないと言える。

とりあえずはオンプレミス環境での移行だったので、今後は、WordPressをAWS上に構築すると得られるメリット まとめを参考にしながら、クラウド環境への移行を行って、スケールアウトのメリットを生かしたいと思う。。。。いつになるやら(笑

CloudFrontを利用して静的コンテンツを高速化する

このブログサイトをCloudFrontを使って高速化してみた。
早くなったかどうかはちょっとわからないが、Googleからのリクエスト速度は間違いなく上がっているので、検索順位向上には寄与している(と思いたい)。
CloudFrontはCDN(Content Delivery Network)のサービスだが、EC2やLamdaなどのAWSのサービス以外にも利用できる。
昔はCDNなんてakamaiぐらいしかなく、個人が使えるようなサービスではなかった。
CloudFrontを独自ドメインで利用するメリットは下記が挙げられる。
1.全世界からのアクセスが高速化できる。(CDNの導入目的と同じ)
例えば、当ブログサイトのドメインに割り当てられているアドレスd2p33equgohrri.cloudfront.netを正引きすると以下のように8つのアドレスが返される。
このアドレスは、リクエスト元の地域(リージョン)によって変わることになる。
>nslookup -q=A d2p33equgohrri.cloudfront.net
権限のない回答:
名前: d2p33equgohrri.cloudfront.net
Addresses: 54.230.111.20
54.230.111.187
54.230.111.227
54.230.111.55
54.230.111.251
54.230.111.57
54.230.111.220
54.230.111.238
2.Webサーバへのリクエストを減らすことが出来る=負荷を軽減できる。(CDNの導入目的と同じ)
3.(D)Dos攻撃にも耐えられる。(CDNの導入目的と同じ/但し、リクエスト数が増大するので、課金がかさむことになる)
4.CloudFrontをSSL化しておいて、CloudFront→Webサーバ 間をHTTP通信にすることにより、昨今のセキュリティ要求に対応しながら、SSL通信にかかる負荷を軽減できる。
5.SSL証明書が無料で利用できる(CloudFront独自のメリット/但し、IPベースにすると毎月600ドル課金されるので注意)
6.AWSの無料枠の対象なので、気軽に試せる(CloudFront独自のメリット)
7.HTTP/2に対応できる。(CloudFront独自のメリット?/リクエストが高速になる)
SSL証明書はLet’s Encryptを利用する方法もあるが、CloudFrontを利用すると証明書の期限が13ヵ月になっているうえ、更新が自動で行われる点がビジネス目的に耐えられる点で優れている。
CloudFrontを利用するにはWebの画面だけで完結できるが、日本語化されておらず少しハードルは高い。
ただ、WordPressサイトをCloudFrontで配信するの説明が非常に分かりやすい。
上記サイトでは、WordPressサイトの登録を変更していたが、
Origin Domain Name には、CDN用のエイリアスFQDN(例:cdn.blog.development-network.net)
Alternate Domain Names には、オリジナルのFQDN(例:blog.development-network.net)
を登録し、cdn.blog.development-network.netのCNAMEに登録後に表示されるDomain Name(例:d2p33equgohrri.cloudfront.net)をDNSに登録すればよい。
SSL証明書の発行手順は、認証がメールベースになっているので、独自ドメインのメールエイリアスを登録できるようになっている必要がある。
SSL証明書を発行しても、すぐに独自ドメイン用のSSL証明書に切り替わらず、証明書エラーが表示されるので、少し焦るがCloudFrontのStatusがDeployedになるまでは待ってみることをお勧めする(焦った)

Chromeでスマホサイトの検証を行う

UserAgentを変更して検証する方法
Google Chrome-49.0.2623.87でのUser Agentの設定変更を参考に設定することができる。
Windowsの場合には、ディベロッパーツールの開き方は、Ctrl+Shift+Iとなる。
対象のタブでのみUserAgentを変更することが出来るので、UserAgentの振分を行っているWebサイトの開発において、非常に便利なデバッグツールである。

グーグルが賭けるHTML 5の未来

@ITより。
Webアプリケーションは完全にクライアントアプリケーションを置き換えることができるのだろうか?クライアントアプリケーションがWebアプリケーションに置き換えることができない理由は、自分が考えるに3つあると思う。
セキュリティ
Webサイト特有のセキュリティ問題が挙げられる。通信経路の問題は、SSL化することで漏えいは防げるだろうし、そもそも基幹システムは、インターネットを使わずに、IPSecやVPN上の通信経路を利用できるようになった。
応答速度
応答速度は、ブラウザの動作が遅いことが原因でクライアントアプリケーションから置き換えることができない。主に基幹システムに多いと思われる。ただ、GoogleはGoogle Chromeによってこれを改善しようとしている。
表現度
Ajaxにより表現度は一段と向上したが、HTML5によりクライアントアプリケーションでしか実現できなかったものをブラウザでも同様に実現できるようになれば、表現度の問題は改善されると思われる。
今回、HTML5によって、クライアントアプリケーションに移行する際に一番ネックであった表現度を大幅に改善し、クライアントアプリケーションもWebアプリケーションに統合することができるようになるとますますブラウザの重要性は高まることになると思われる。

さむい

さむいさむい。
朝は車のフロントガラスが結露し始めるし、夜は寒いし、もう冬はそこですなぁ。
でも最近熱いこと。
それは、「cakePHP」でもWebアプリをバリバリ開発している人にとっては、いまさらって感じかもね。転職してからWebアプリ開発はご無沙汰で、別のフレームワークを触るだけでワクワクしてしまう。
そして「OpenID」。これからサイトごとにアカウントを覚える必要はないかもね。OpenIDを利用したcakePHPのサンプルアプリを作ってみたんだけど、mixiのOpenIDと連携してみたらとっても便利だった。(Yahooはセキュリティポリシー上IPアドレスからのアクセスは不正アクセスとみなしてしまうので、テスト可能な環境を選んでしまう)
LDAPのようにIDとパスワードを入力する際に問い合わせするサイトを自サイトではなくOpenIDのサイトにするという仕組みかと思ったらそうじゃないんですね。まぁその方が安全ちゃぁ安全なんですけど、OpenIDが普及するまでは利用者の戸惑いも多いかもしれませんね。

よくわからない

まぁあしあとつけてコメント書かないのは失礼というのはわかるけど、全体に公開している割合の高い「既婚男性」層が踏み逃げを嫌うという傾向もどうなのかと思う。
つまり
全体に公開している→誰か相手してくれ→日記見るだけ見て逃げるやつは嫌いだ
ってことなのか?
自分の発信した情報に対してなんらレスポンスがあるというのはうれしいことだけれど、それが当たり前だと思うというのはSNSが始まる前から自分のサイトやブログで情報を公開してきた人間からするとどうも腑に落ちないというかなんというか。。。
「mixi読み逃げ」ってダメなの?

Movable Typeを4.2にアップグレードする

Movable Type 4.2が8/14にリリースされ、mixiアカウントを使ってコメント入力を認証できるようになったらしい。今回は、アップグレードしてコメント入力を認証させるようにして、スパムを減らすようにしたい。
現在のところカスタムフィールドを使っている場合には、アップグレードによってデータが消失する可能性があるとのことなので、アップグレード前に 設定 > カスタムフィールド を表示させて確認するとよい。
基本的には、Movable Typeをアップグレードするの手順どおりでやっていけばアップグレードできるが、Apacheユーザー以外でインストールしている場合には、supportフォルダの権限変更が必要となる。
# apacheの設定ファイルを変更し、以下のディレクトリの所有権を変更する
chown apache.apache /var/www/MT-4.2-ja/mt-static/support/
mixiとのアカウント連動については、mixiCommentプラグインを見るとインストール方法がわかるので確認してほしい(ちなみに、ダウンロードのリンクは左上にある)。

Movable Typeをアップグレードする

Movable Typeを3.33から4.1にアップグレードしてみた。
なお今回は、/var/www/ にMT-3.33-jaがあり、MT-4.1-jaをコピーして動かす場合について説明する。また、データベースにはMySQLを使用しておりmtデータベースに保存されているものとする。
#作業ディレクトリでzipを解凍し、移動する
unzip MT-4_1-ja.zip
mv MT-4.1-ja /var/www/
cd /var/www
ls -l
ls -l MT-3.33-ja/
# 3.33のmt-config.cgiはそのまま利用できるので、コピーする。
cp MT-3.33-ja/mt-config.cgi MT-4.1-ja/
cd MT-4.1-ja/
# 念のためバックアップを行い、正しく保存されていることを確認する
mysqldump -u root -x –password=(パスワード) mt –default-character-set=binary > /tmp/mt.sql
less /tmp/mt.sql
# apacheの設定ファイルを変更し、以下のディレクトリの所有権を変更する
chown apache.apache /var/www/MT-4.1-ja/mt-static/
chown apache.apache /var/www/MT-4.1-ja/mt-static/images/
# 自分でインストールしたpluginがあればコピーする
cp -pR ../MT-3.33-ja/plugins/GoogleSearch/ plugins/
cp -pR ../MT-3.33-ja/plugins/Mobile plugins/
#Apacheの設定ファイルを書き換えてApacheの再起動を行う
Alias /mt /var/www/MT-3.3-ja/

Alias /mt /var/www/MT-4.1-ja/
これでmt.cgiにアクセスすれば自動的にアップグレードが始まる。
なお、アップグレード成功後、ブログの設定においてコメントのCAPTCHAプロバイダの設定欄に

CAPTCHAプロバイダがありません CAPTCHA プロバイダがありません。Image::Magickがインストールされているか、またCaptchaSourceImageBaseが正しく設定されていてmt-static/images/captcha-sourceにアクセスできるか確認してください。

と表示される場合には、mt-check.cgiにアクセスしてImage::Magickがインストールされているかどうか確認する。もしインストールされていないようであれば、
yum install ImageMagick-perl
を実行してインストールする。