投稿日:

幸せは感じるもの。


「幸せは感じるもの。」

昔っから、自分自身に言い聞かせている言葉だけど、なかなか難しい。
仕事が詰まったり、難しかったり、上手く行かなかったり、ミスしたり。

思うより人生は簡単でなくて、そんな余裕なんてなかなか無い。
こういう心構えみたいなものは、ある程度心に余裕があって、はじめて有効になる気がする。

不安がりの僕は、なんとなくお気楽そうな人を見ると、なんだかとても羨ましく思う。
僕だってなんとかそんな性格になれないかな?と思うけど、やっぱり難しい。
これは「出来ない」と言ってたら始まらないとか、そういう次元の話じゃない。
なんというかこれは、僕自身に刷り込まれた宿命なんだと思う。

だから嘆いていても仕方ない。

かわりに僕はなかなか感受性が強い方らしい。
簡単に泣けちゃうし、笑えちゃうし。
日常の些細な物事に幸せを感じることが出来たりもする。

まぁ、その辺りは不安がりの裏返しだと思ったりするところもあるけれど、
ある意味バランスが取れているんだろう。

なるべく笑って生活しよう。
なるべく無欲でいよう。
なるべく人前でカッコつけないでいよう。
なるべく出しゃばらないでいよう。
なるべく人を好きになろう。
なるべく良いことを考えよう。

幸せは感じるもの。

きっと僕の世界は、幸せな空気でいっぱいだ。

ああ、奥さんバイトから帰ってきたよ。
もうすぐご飯だね。

 

投稿日:

DotCloud + WordPress の構成ファイルをローカルで管理する


WordPress を DotCloud で運用することにしましたが、どうも push はできても pull が出来ないようです。(たぶんw)

となると、公開中のサイトの管理画面でテーマやプラグインの追加・変更を行っても、手元にファイルを残しておくことができません。また、functions.php をはじめ、自分で機能拡張するためのコーディングはやっぱりローカルで慣れたツールでやりたいところです。

そこで、なるべくローカルで管理する構成を考えてみました。

ざっとした構成は次の通りです

  • WordPress は DotCloud と Local と両方に配置
  • データベースは DotCloud を利用(ローカルも DotCloud 上のDBを参照)
  • WordPress サイトは、独自ドメインで公開(この運用の為に必要)

こんな感じにセットアップして、ローカルでサイトを管理しつつ、ファイルの変更があったら DotCloud に随時 push する方法です。

1)ローカル環境の準備

WordPress を動かすための Web サーバーを構築してください。
僕はとりあえず、MAMP を利用しました。

また、サイトの公開用のドメインでバーチャルホストを設定してください。
ここでは、www.lurala.com を使用します。
hosts に次のエントリを追加し、www.lurala.com がローカルを参照するようにします。

 2)DotCloud の環境準備

サインインしてアカウントを準備して、DotCloud の CLI 環境も準備してください。
ここはググるとすぐに出てくるし、簡単なので割愛します。

3)WordPress プロジェクトを準備する

任意のディレクトリに WordPress のプロジェクトを作成します。
とりあえずここでは、/Users/yuka2py/Projects/lurala というディレクトリを作成し、このディレクトリをプロジェクトのルートとします。ここに直接 WordPress のファイルを展開することもできますが、僕は次のディレクトリ構成としました。

/dotcloud.yml
dotcloud の設定ファイル。プロジェクトのルートに1つ必要
/public/
パブリックルート。この中にWordPressなど設定します

プロジェクトのルートには、dotcloud.yml のみとして、公開ファイルは public ディレクトリに入れてしまう感じです。では、dotcloud.yml を以下の内容で作成します。

approot で、パブリックルートディレクトリ public ディレクトリに指定しています。

そして、public フォルダを作成し、wordpress の初期ファイルを全てどどどーんと展開しておきます。

4)DotCloud にアプリケーションを展開する

DotCloud のコマンドを入力して DotCloud の設定を行っていきます。
必ず、プロジェクトのルートで操作してください。

まずは、DotCloud にアプリケーションを作成。

そして、ローカルのファイルをアップ。

これでアプリケーションが展開され、Webサーバーやデータベースの初期化が実行されます。

次に、初期化された、データベースのインフォメーションを取得します。

以下のような情報が出力されます。

この情報より、データベース接続の為のホスト名やアカウント情報を参照できます。

次に、mysql に WordPress 用のデータベースとユーザーを作成します。

まずは、mysql にログイン。

そしてデータベースの作成して、データベースを参照できるユーザーを作成。

以上で mysql の準備は完了です。
mysql から ctrl+D でログアウトします。

5) WordPress のインストールを実行する

WordPressのインストールを行います。
ここでアクセスするのは、ローカルのWebサーバーであることに注意してください。

http://www.lurala.com/wp-admin/

そして、おなじみのデータベースの設定画面です。

ここで、先ほど設定した、データベース名、ユーザー名、パスワード、そしてホスト名を入力します。
ホスト名には、dotcloud info lurala.db で参照できる、ports: mysql: のホストからポートまでの情報を入力します。僕の場合、以下の通りです。

lurala-yuka2py.dotcloud.com:18836

あとは、おなじみの WordPress インストールの流れです。

★補足★ この時点で、Web サーバーや WordPress のファイル群はローカルのものを参照し、データベースだけ DotCloud を参照する形となっています。この状態でセットアップなどすることで、ローカルにファイルを持つ事ができる感じです。ローカルで追加や更新されたデータは、dotcloud push コマンドで DotCloud にアップして更新します。

インストールが終了したら、インストールによって生成されたローカルのファイルを DotCloud に push します。

これで、ローカルで生成された設定ファイルなどが、DotCloud にも展開されます。

DotCloud でもローカルでも、参照している DB は同じなので、DotCloud 側でもキチンと WordPress が動きます。

…ととと、あとひとつ、ドメイン名の設定が残っていました。

6) WordPress を公開する

そのままローカル環境の WordPress にログインします。
[設定] > [一般] の中の「WordPress のアドレス (URL)」「サイトのアドレス (URL)」の2項目が、公開ドメイン(ここでは、http://www.lurala.com)になっていることを確認してください。

この時点で、http://www.lurala.com は、ローカル環境からのみアクセス可能です。
DotCloud のデータが http://www.lurala.com で公開されるように準備します。

まず、DotCloud にドメイン名のエイリアスを登録します。

これで登録できました。

次のコマンドで確認できます。

結果、次のような情報が確認できます。

ここで、追加した http://www.lurala.com/ が確認できます。

さて、もうひとつ、http://lurala-yuka2py.dotcloud.com/ とありますが、これは dotcloud アプリケーションのデフォルト url です。

で、この lurala-yuka2py.dotcloud.com に対して、www.lurala.com の CNAME レコードを、あなたの管理する DNS サーバーに登録します。

以上で完了です。
最後に dotcloud push した内容で、あなたの WordPress が公開されます。

7)運用方法

  • プラグインやテーマのインストールおよび管理や、functions.php の修正などは、基本的にローカルで全て作業できると思います。変な php エラーを出して焦ることもありません。ゆっくりと修正できます♪
  • 修正が完了し、ローカルでの動作確認が OK なら、dotcloud push で、本番に公開します。
  • データベースだけ共用している点に注意が必要です。
  • また、この設定のままでは、ローカルのマシンからは常にローカルの WordPress が見えています。DotCloud 上の本物のサイトを見るには、別のマシンから見るか、あるいは、hosts ファイルのエントリをコメントします。ちょっと面倒ですが、良いやり方があったら教えてください。
  • アプリケーションのルートディレクトリで、git のリポジトリを作成し、git の管理下に置くこともできます。dotcloud コマンドは、.git ディレクトリがあるとヨシナニ取りはからってくれるらしいです。

追記のおまけ

パーマリンクのための設定

WordPress のパーマリンクを使うには、public root に、以下の内容の nginx.conf の設定ファイルを置きます。

nginx.conf は dotcloud の htttpd である、nginx の設定ファイルです。

どうやら差分だけ設定できるようです(.htaccess みたいな感じかな? たぶん)。

本家のドキュメント

http://docs.dotcloud.com/tutorials/php/wordpress/

後で見つけました。 (^_^;A
やっぱり説明書から目を通さないとね。

 

 

投稿日:

MAMP でバーチャルホスト


MacOSX Lion + MAMP 2.0.5 でのバーチャルホストの設定メモです。

1)MAMP 上のポート変更(任意)

MAMP のデフォルトのポートは 8888 ですが、いろいろ面倒なので 80 に変更します(好みですので、別に、やらなくても良いです)。

MAMP の管理パネルを開いて [環境設定] > [ポート] 内の Apache ポートを 80 に変更します。

以下、この前提でのお話です。
ポートを変更されない場合は、適宜読み替えてください。

なお、ついでに、MacOS の [システム環境設定] > [共有] の「Web 共有」が OFF になっていることを確認しておきます。もし ON になってたら、OFF にしておいてください(80番ポートが競合するため)。

2)バーチャルホストの設定

ターミナルを起動して、mamp の中の httpd.conf を編集します。

httpd.conf の末尾に、以下の記述を末尾に追加します。

ディレクトリのパスや、サーバー名は個々の環境に合わせて設定します。

ここでは、/Users/yuka2py/Projects 以下に複数のバーチャルホストのディレクトリを配置する前提で、local.foreignkey.jp のドキュメントルートを /Users/yuka2py/Projects/foreignkey/public としています。

3)hosts ファイルの編集

local.foreignkey.jp のドメインでアクセスできるように、hosts ファイルにエントリを追加します。
root パスワードを聞かれるので、入力します。

末尾に以下の記述を追加します。

以上で、http://local.foreignkey.jp で /Users/yuka2py/projects/foreignkey/public にアクセスできるようになります。

 

 

 

投稿日:

phpfog に git で接続する


phpfog に git で接続します。…というかこれが出来ないと、phpfog では何も出来ないっぽいですから誰しもがやるし、それにぜんぜん難しくも無いことですが、例によってやっぱりちょっとつまづいたので、以下、メモを残しておきます。環境は MacOS X Lion です。

Public key の作成とコピー

まずは、ssh 接続の為の公開鍵の作成です。

phpfog の ssh key 登録画面にある、「Learn how to create a key>」の先の説明書の手順を参考にしつつ、以下のコマンドで作成しました。

ここで、ssh-keygen に -C オプションで phpfog に登録しているメールアドレスを指定しています。
また、key のファイル名はデフォルトで僕は OK なので、そのまま [enter] しました。

これで、id_rsa および id_rsa.pub のキーファイルが作成されました。

次に、公開鍵の id_rsa.pub を次のコマンドでクリップボードにコピーします。

これでクリップボードにコピーされます。

余談ですが、実は最初、vim で開いて範囲選択してコピーしてたのですが、その後の行程が何だか上手くいかず、選択が悪かったのかも知れませんが、とりあえず上記の方法は確実で、安心です。

phpfog へのキーの登録

さて、phpfog への公開鍵の登録です。

phpfog の管理画面で MY ACCOUNT > SSH Keys にアクセスします。

Nickname は誰のどんな接続用のキーか分かるようなラベルです。適当で OK です。

Public Key は上で作成してコピーした内容です。そのままペーストしてください。

最後に [Save SSH Key] で登録完了です。

成功したら、以下のような画面になると思います。

git で接続する

phpfog 上のアプリケーションをローカルに clone します。
プロジェクトディレクトを作成するロケーションまで cd して、以下のコマンド実行です。

ここで、git@git01…. の文字列は、php fog のアプリケーションコンソールの右上に表示される文字列です。

以上で、無事 clone できました。

 

 

投稿日:

IE6外しを上手く説明するトーク


第2回「HTML5など勉強会」 に行ってきました。

その中で、「IE6問題」を強く投げかける発表がありました。「IE6」がいつまでも Web 制作会社を苦しめ続けるのは、「そもそも Web 制作会社が IE6 をサポートし続けていることが一番の原因」と言う提言があって、僕的にはまったくその通りだなぁーと思ったりしたわけです。…とはいえ、実際のところお仕事の中には競争があります。お仕事を失うリスクを考えたりして、なかなか IE6 外しをお願いできない状況があることも事実みたいです。

そこで、僕なりのお客様とのコミュニケーション例を少しですがまとめてみました。少しバイアス掛けているトークもありますが、嘘は無いと思っています。どなたかの参考になればー嬉しいです!

IE6は既に10年も前のブラウザです。国内で7%ぐらいのシェアを残していますが、主にシステム移行が難しい企業内ユースですので、コンシューマでのシェアは無視できる程度だと考えています。

IE6は最近のモダンなブラウザと比べてセキュリティに劣る部分もあります。 Webアプリケーション全体のセキュリティを重視するのであれば、IE6を対象外とするのも、ひとつのアプローチです。(ちょっと無理あるかな?)

最近では、IE6を対象外とするメジャーなサイトも増えて来ましたね。実際、弊社がデサインで参加させて頂いている月間数千万ページビューの或るサイトでは、IE6を対象外とするよう、先方の担当者さまより依頼がありました。その理由として、十分にシェアが下がったという認知はもとより、無駄なマークアップやハック、JSの採用を減らせることで、結果、サイトの構造がシンプルになりSEO性能を高めやすく、またサイトの保守性が向上するため、将来に渡る保守コストの低減が期待できるからでした。

IE6の対応は正直なところコストが掛かります。…古いブラウザですし、コンシューマシェアも殆どありません。これにコストを掛けて対応するよりも、IE6非対応であることを利用者に明示する方法もあります。たとえばこういったアプローチも紹介されています。 http://moongift.jp/2011/01/20110114-2/

ie6alert-js の採用は、最新の Flash バージョンを採用してアプリケーションを開発するよりも、利用者に与えるインパクトは少ないのではないでしょうか? ie6alert-js は、IE6のユーザーに対して、なるべく違和感のない方法で、ブラウザアプリケーションのアップグレードを提案します。

同じ見積もり額で、IE6にも対応する業者様があるとのことですが、よく考えてみてください。IE6対応コストが無くなる訳でありません。サイトの本質的なクオリティを高めるために本来適用されるべきコストを、その業者はIE6対応に割くわけです。

明かな嘘があればご指摘くださいまし。
また、他にも良いのあれば教えてくださいまし♪