2月 2011 のブログ記事

Mercurialを使ってみた。

admin
(2011.02.24 04:04) | ひとりごと | | 1件のコメント

seezoo cmsがリポジトリに「BitBucket」というのを使うということで、
なんじゃそれ？と思って調べたら、
「Mercurial」という分散バージョン管理の
オープンソース用リポジトリだということが判明。
　

恥ずかしながら私「Mercurial」というものを知りませんでした。
　
調べると、Pythonで実装された分散バージョン管理システムで、
OpenSolarisやNetBeansなどのJavaの実装や
Pythonのオープンソースプロジェクトの管理に使われているとのこと。
同じ分散バージョン管理である「Git」と双璧をなす感じのものらしい。
（Subversionは集中型なのでちょっと方向が違うのでお間違えなく。）
　
GitとMercurialの開発スタートはともにBitKeeperが商用のみになり、
代わりとなる分散バージョン管理システムをつくりはじめたという似た歴史をもつらしく、
そういった経緯から、ともに機能を取り入れつつ発展してきた経緯がある。
　
ということで、内部的な動作を除いては、
基本的にはGitのようなものだと考えてよさそう。
　

前述のBitBucketは、公開リポジトリは当然自由で無料。
たしかGitHubは無料で使えるのは公開リポジトリのみだったと思うが、
BitBucketは5ユーザまでのプライベートリポジトリも無料らしい。
しかも容量制限なし。
なにそれ！？いいじゃん！！
　

コマンドラインで使う場合は「hg」というコマンドを使う。
「Mercurial」は「水銀」という意味なので、
水銀の元素記号である「Hg」からとったのだと推測。
オサレ！！
　
ちなみに「Mercurial」というソフトウェア名の由来は
水銀の方ではなくて、ギリシャ神話の「マーキュリー」に由来するとのこと。
　

hg clone
hg add
hg commit

コマンドもGitとよく似ていますな。
　
インストールなどなどは、先日東京で行われたCodeIgniterカンファレンス東京での、
SuzukiKenjiさんのセッションの資料が、
簡潔なのでそちらにゆずります　http://handsout.jp/slide/3550
　

Windowsでは、バージョン管理システムのクライアントのお決まりである、
「Tortoise」シリーズの「TortoiseHG」が出ていて、
これを使えば簡単。
　
TortoiseGitに比べて早い段階から安定した動作をしていたようです。
素晴らしい！
　

私のメイン環境であるMacでは、
まぁMacPortsでMercurialをインストールするのが簡単。
コマンド使える人は、ターミナルでゴニョゴニョすればOKなんだけど、
MacHgという使いやすいGUIクライアントがでてる。
これがなかなか完成度が高くて、かっちょくて、しかも無料！
全く不具合がないというわけではないようですが、基本的な動作を行わせてみたところ、
ほぼ問題なく動きました。
　
Gitだと、GUIクライアントでいいなと思えるのは、
@ahomuさんが
ブログでオススメしている「TOWER」くらいしかなく、
私も無料のだとひと通り試したものの、うーんとなる結果が多かったので、
この点でもMercurialが有利かなと。
　

　
その他、Mercurialはpythonで書かれているので拡張がしやすく、
subversionクライアントとして使える拡張なども配布されているようです。

いろいろ調べると、
GitとMercurialを両方かなり使い込んだ方の意見としては、
Gitのが上という意見が多いみたいです。
そして、いかんせん最近はGitブーム。。。ユーザー数としてはGitのが上ですよね。。。
いいことばかりではないです。

ただ個人的にはGUIクライアントが安定しているMercurialで行きたい。
というわけで、これからはMercurial。
すでに、Gitで動いてるプロジェクトもあるので、
まぁ両刀遣いな方向で。

MacBookProのBootCamp3.1にWindowsXP SP2

admin
(2011.02.22 09:01) | ひとりごと | | コメントはまだありません

先日譲っていただいた、MacBookPro(2010mid)Core i7モデルへ
BootCampにWindowsXP(SP2)を導入した。
　
以前から他のMacには入れたい経験があったのだが、
どういうわけか、今回は結構大変だったのでメモ。

WindowsXPは元々SP1の時に買ったものを、
SP2のコンポーネント追加してディスクに焼いたものを使って、インストール。

Macに付属のBootCampは3.1。
　
という環境で行った。

パーティションづくりから、Winのインストールまでは、
通常の手順で行っているので、特筆すべき内容はない。
　

インストール後、いつものように、本体付属の、MacOSXのインストールディスクから、
BootCampドライバをインストールしようとしたところ、
インストーラーが走っている途中で、
ブルースクリーンが表示されOSごと落ちてしまう。何度やっても同じ。
　
そして、オーディオとBlueToothのドライバが正しくインストール出来ない。

後者のドライバ関連は、インストールディスクをひらいて、
各ドライバを直接開くことで解決できた。
　

問題は前者。これが何をやってもダメ。
　
SP3の問題なのかなども考えて調べると、WindowsXPでは、
BootCampドライバが正しくインストールされていないと、
SP3のインストールがうまくできないケースがある。
今回まさにこれ。

一応このままでもWindowsとして使えるには使えるのだが、　
BootCamp関連ソフトがインストール出来ていないと、
イジェクトなどのホットキーも使えないため、
やはりいや。
　

いろいろ調べた結果、
BootCamp2.1のドライバをインストールすると、
WindowsXP(SP3)がすんなり入ることがわかった。
　
一旦、MacOSX leopardに付属のBootCamp2.1をインストール。
これで、SP3を適用できた。
この時、VisualC++2008と2005のランタイムをアップデートしてから、
SP3を適用したほうが良いと思われる。
　

その後snow leopardのインストールディスクから、
BootCamp3.x系をインストールしたら、
すべてすんなりいった。

ちょっと大変だったので、ここまでやったら、
mac側から、winclone(http://download.cnet.com/Winclone/3000-2242_4-172338.html)を使って、
クリーンな状態をイメージで保存しておくといいと思われる。

　
というわけで、WindowsXP(SP2)をBootCamp3.x系で使うのは結構大変だ。
　
インストールをする場合は、nliteを使ってSP3適用ディスクを
誰かのwindowsを使って作成させてもらったほうが良いと思われる。
ディスクのカスタマイズは、nlite(http://ja.wikipedia.org/wiki/NLite)を使えば、
比較的簡単にできる。
nliteを使えば、無印XPやSP1しか持っていない人でも、
BootCampインストール可能。

専門学校で講師をやってきました。

admin
(2011.02.16 12:53) | ひとりごと | | コメントはまだありません

本年1月より急遽ピンチヒッターとして、
某専門学校にてPHPの講師を担当しました。
　
その感想というか反省というかをまとめておきたいと思います。
　

　
担当した学科はWEBデザイン系の学科と、
満遍なくIT技術の入り口を教えるジェネラリスト系の学科でした。
　
WEBデザイン学科の方は、ひとつの世界に飛び込んでいくために、
みんなが同じ方向を向いているという感じかなと思っていたのですが、
実際はそうではなく、
一言にWEBと言っても、それぞれにやりたいこと思っていることが別々。
そして、ジェネラリスト系の学科も、当然ながら、
みんな考えていることは別々。
　
その中で、PHPという狭い世界のことを教えるのは、
正直言って大変な仕事でした。
　　
反PHPな勢力の方々が一様に仰っているのが、
「PHPは学ぶべき言語ではない」
ということです。
「PHPを使うな」ということではなく、
「PHPは他の言語で学んだ知識などを高速開発のために落としこむツール」だということですね。
　
私は元々PerlMongerであるため、
特に意識をせずに、
PHPをツールとして利用していたのですが、
講師をやってみて、反PHPな勢力の方々が仰っているのが少しわかりました。
　
PHPは良く言えば「緩い」、悪く言えば「いい加減」な言語で、
これを体系的に教えたり学んだりするのは、容易ではなかったです。
「できた気分」にさせるのは簡単でしたが、
現場で使えるレベルに到達させることは
正直できませんでした。
　
また、元々PHPが擬似オブジェクト指向な言語であるため、
JS・AS・Javaも並行で授業を受けている彼らにとっては、
これらの言語を学ぶ上で変な足かせになっている様に感じてしまいました。
　
私は現場で学んだ立場なのですが、
学校で学ぶのと、現場で学ぶのでは、
勉強方法などかなり違いがあるなというのが感想です。

来期は、他の授業の先生方との連携が必要ですね…。
　

そんな中、学生のみなさんは、よくついてきてくれたなと思います。
私が講師をしに行けば学級崩壊なのかなとか想像してましたが（笑
学生それぞれに自分自身の課題をもって授業を受けてくれた感じです。
　
ゆとりゆとりとか言われてる世代で、
正直確かに「ゆとり」と感じる部分もないことはないわけですが、
ぶっちゃけ自分が学生だったころよりよっぽどマシな学生ばかりですし、
ゆとり世代はゆとり世代ならではの視点で、
勉強してるなと思います。
　
あの世代がついてきてないのではなくて、
こちらの世代が飛び込めていないだけ、
そう思いますね。
もっとコミュニケーションとらないと。
　

　
まぁそんなこんなで、来期も先生です。
　
正式に「発信する側」につかなくてはならないフェーズに突入ってことですかね。
発信する側にまわるということは、
ますます勉強しなければならないですし、
ますますコミュニケーション能力も高めなければならないということです。
　
WEBとかITとかやってると、閉じこもり気味ですが、
それでは此処から先難しくなりそうなので、
「大名古屋WEB会議」などなどで、
外に向かっていきたいと思います。

モールはどうなの(2

admin
(2011.02.10 04:39) | ひとりごと | | 1件のコメント

昨日、名古屋79+-1生まれWEB屋会（正式名称はよくわからん）というのがあって、
その中でちょっと話のあったことを。
　
どこかのブログでECは「ショッピングモール」に集約されるのではと
書いてらっしゃる方がいらっしゃたということです。
　
思い出しました。
私も読んだ。今となってはURLなど忘れたので、
うろ覚え内容であることをご理解頂いた上で、ご覧頂きたいと思います。
　
また、毎回のようにお断りしておくが、あくまで私見であり、
今回の記事については、将来的な話なので、「へぇ」くらいで読んでいただいたほうが
よろしいかと思います。
　
すみませんが「ショッピングモール」そのものについてはあまり語らない記事かもしれないです。

さて、うろ覚えのその記事には、確か、
グルメ情報なら「ぐるなび」、中古車情報なら「Goo」
というような感じに、
それぞれの分野がそれぞれに専門特化したサイトに集約されている。
ECもそれと同じく「楽天」などの集約されるのではないか。
　
というような内容だったと思います。
　

私も、どこかのサイトに情報が集約されていくのは至極当然流れですし、
情報を読む上での情報の質の均一化という意味では、
「集約」というのは役に立つと考えています。
　

が、しかし、それが果たして「ショッピングモール」であるのか、
という点については、私は疑問符です。
　
前に挙げている、「ぐるなび」「Goo」について考えてみると、
情報こそ集約されていますが、
そこに掲載されているサービスの主体は、
ぐるなびやGooの中にあるわけではないです。
むしろ、様々な方向に向いていて、サービスの内容も様々。
それを選ぶWEBサイトとして機能しているということが言えます。
　
では、ECにおける楽天などのモールはどうでしょうか。
楽天は一様の出店システムを出店者に提供するASPという側面が強いです。
多くのモールでもそういう側面は非常に強いです。
このことは、ほぼ「サービスの均質化」に近いと思います。
（もちろん、これはやり方や努力次第でどうにかなりますが）
均質化されたサービスを集約しても、
それは必ずしも一般消費者のニーズに合っているとは言いがたい状況が生まれると思うのです。
　
従って、ECにおける「集約」の形は、
ASP型のショッピングモールではない。
と私は考えています。
　

一応言っておきますが、
「ショッピングモールがカスだクソだこんにゃろ」
と申し上げているわけではなくて、
ショッピングモール出店も、自社サイト出店もサービス主体の一形態だということを
申し上げたいだけです。
　

　
じゃあ、集約とは何か。
　
日本においては、すでにいくつか成功してる企業様はいらっしゃって、
その最たる例が、

ですね。
　
価格.comは掲載にお金はかかるものの、
色々なものの情報を集約、そしてモノを買う上での判断基準を集約しているサイトだと思います。
　　
ECにおける集約とはこう言った形態ではないでしょうか。
昨年2010年の終わりごろ日本でもサービス開始した、

も、そのひとつでしょう。
　

　
というわけで、私見をまとめると、

  • 情報はどこかに集約されるのは至極当然の流れ
  • ショッピングモール自身もその流れに乗って、一出店形態となっていく

だと思うわけです。
　
で、最後にモールに出すことはどうなのかというところに、
無理やりこじつけると、
モール出店は、こう言った流れの中で、
集約サイトなどに提出するための、
データ作成などの手間を省くサービスの一形態になるので、
メリットはそれなりにあるということになると思います。

CMSいろいろ。

admin
(2011.02.07 12:54) | ひとりごと | | コメントはまだありません

特に意味はないんだけど、CMSを集めたくなった。
年代とかめちゃくちゃかも。汎用なのを集めました。

　
まず、名古屋を代表する二つ。

　
そして、隣県の三重県四日市市の方が日本ローカライズを行っている、

　
世界を代表する2つ

（この2つは個人的にはブログツールのような気がするのだが…。）
　
古いものだと

XOOPSは

などに派生。
Mamboは

に派生。

2004〜2006年くらいの「WEB2.0」という言葉がもてはやされた頃に有名になってきたのが、

とかでしょうか。他にありましたっけ？汗汗。ごめんなさい。
　
で、そんな流れをうけて、確か2004年でしたか、
mixi上でクローズドベータのデモを見せてもらったのが、

です。多分、私が、ブログツールとしてのCMSではなく、汎用CMSで、国産のもので一番最初に見たのが、これでした。（多分、他にもっと早くからある物はあるはず）
　
その後、日本製CMSがどんどんできてきてます。私が知った順に書いていきます。

　
その他注目株

などなど。
　
まだまだ沢山あるとおもう。
オープンソースはカオスでしょうね(^-^;
（MoonGiftさんなどを御覧ください）
　
「○○がいい」みたいな議論になってますけど、
実は密かにいろんなCMSを触ってきたんですが、
（ここに並べたCMSの6割はインストール→テストまでしました）
やっぱ一長一短ですよ。
（ただし、どのCMSもその「一長」がすごくでかいんですけどね）
　
なんども言いますが、なんとなく並べてみたくなったので、
並べただけなので、この記事に特に意味はないです。

モールはどうなの（1

admin
(2011.02.06 04:09) | ひとりごと | | コメントはまだありません

とりあえず(1としましたが、続くかわかりませんので、
最初に書いておきます。
　
こちらの記事を書いたとき、楽天などのモールはどうなの？
と突っ込まれたので、一応解答を。
　
私なりの解答を。あくまで私なりの解答です。
商品によっても考え方が違うでしょうし、
立場によっても違うでしょう。
　
楽天が分かりやすいので、楽天の場合として書きます。
　

　
まず、私の立場を先に書いておきます。
まぁ私のことをご存知の方は分かっていらっしゃると思いますが、
正直楽天さんは嫌いです。
いろいろ言いたいことはありますが、
一言で言えば、運営方針とかが
消費者寄りすぎるのが問題だと考えています。
　

　
では本題。以下、やれHTMLがどうとか、システムがどうとかという話はあえて外します。それはまたいつか書きます。
　
楽天に出店するメリットは

  • システムを構築しなくてよい
  • 売る方法というのがある程度確立している
  • 出店者同士のコミュニティがある

といったところでしょうか。
　
初期費用でお金がかかり、おためし出店的なことも難しいですが、
自社サイト構築よりはずっと低く抑えられます。
　
売る方法は「楽天商法」などと呼ばれる、売り方がある程度確立されています。
またこの商法に則って、楽天主催の勉強会のようなものもあります。
　
で、個人的に楽天の一番の強みだと思っているのが
出店者同士のコミュニティです。
これは、出店者同士がリスペクトしあう良い仕組みだと思っています。
自社サイトにはない強みですね。
　

では、楽天に出すデメリットは、

  • 競合が多すぎて、価格競争になりがち
  • ランニングコストが非常に高い
  • 「ネットで売る」という仕組みとは違う側面が見え隠れする

といったところでしょうか。
　
2011年2月現在で、楽天には35,000店程度の出店があるそうです。
「mall」は日本語に訳すと「ショッピングセンター」というような意味になりますが、
「ショッピングセンター」というには、あまりに規模が大きく、
当然のように競合が多いです。
どこでも仕入れられるような商材であれば、
当然のように価格競争が始まります。
　
楽天の場合、
毎月の売上に対して成果報酬型で楽天にお金を払わなくてはなりません。
そして、楽天ポイントなどの負担も発生。
システム上様々な制約が掛けられており、
このあたりをクリアするためにも、お金が発生。
結果、売上に対して7〜10%を楽天に支払う事になります。
　
これら２つは、商材や運営方針によっては
「売上はあげられるが、利益があげられない」
ということの原因になっています。
　
メリットの中で、「楽天商法」というのが存在すると書きました。
この商法は、メールマガジンをベースとした売り方になります。
様々な方法で、メルマガ会員を集め、メルマガで人寄せする。
というようなフローになります。
これを別の見方で考えると、言い方は悪いですが、
「ネットで売っている」とは言いがたい状態でもあります。
この点は、良くもあり悪くもあるということですね。
特に、継続購入の必要性が薄い商材の場合は、
なかなか売るのに難儀し、自社サイトでリスティング広告などを使ったほうが
良いケースも多々あるのではないでしょうか。
　

かなり表面的に書いてみましたが、こんな感じです。
自社サイトもそうですし、モール出店でもそうですが、
出店者と制作サイドが、それぞれに、
いまやろうとしていることが最適解であるのかどうかを、
考えないと、まず失敗します。
また、これはサービスインしたあとも継続して考えなければなりません。
　
最近では、有名だった店舗がモール出店から手を引いたりするケースも
多々見られます。
これはネガティブな考えからの撤退も多いでしょうが、
費用対効果の面などを
ポジティブに考えての撤退も少なからずあるように思います。
　
何が最適解であるか、よく話しあってみてください。

CodeIgniterのいいとこ色々

admin
(2011.02.04 01:04) | CodeIgniter | | 1件のコメント

先日CodeIgniterが2.0にバージョンアップしたり、
はてぶ界隈で
http://h2o-space.com/blog_ver2/diary/195
こちらの記事が話題となっているようですので、
CodeIgniterを使い始めて3ヶ月の私がちょっと反応してみます。
　

 私がCIを利用しはじめた理由は、

  • コーディング規約がゆるゆる
  • インストールにコマンドがいらない
  • 拡張がらくちん
  • 比較的広いPHPのバージョンに対応
  • モデルの扱いがゆるい

というところでした。
　
モデルのあたりは、前述の話題サイトにも書かれていますね。

実際に使い始めて特にいいなと思ったのが、
ユーザーガイドのページの使いやすさ・読みやすさです。
PHPさえちゃんとできれば、
ユーザーガイドのページを見ながら開発をラクに進められます。
書籍などはいらないと言ってよいです。
学習コストが異常なほど低いです。
　

そして、コントローラーの頭の良さに驚きを隠せないです。
一度ルーティングが成功してしまえば、
どこからでも、コントローラーインスタンスを呼び出すことができるので、
値をシステム内で縦断させて、参照/変更がかなり簡単にできます。
　
また、ローダーと呼ばれる、
ライブラリや設定ビューを呼び出す機能も、頭が良いです。
　
私はCodeIgniterを使う前、自作のフレームワークを利用していたのですが、
こちらのFWに使っていたライブラリ類の移植が、
コントローラーとローダーの頭の良さで、
非常に簡単に移植できました。
　
またCI自身のコアの拡張も分かりやすく、簡単にできます。
　

で、何が一番驚きって、とにかく高速。
ぶっちゃけ、普通のサイト作ったり、
モデルパターンの少ないWEBサービスだったら、
DBのクエリの速度以外は気にしないでいいレベルです。
　

常々私はEC専業のPGだと嘘ぶいていますが、
ECはページの魅せ方を色々変える必要があったり、
決済などの問題で、色んな拡張の必要性に迫られるケースが多々あるのですが、
そのへんでCIはパワーを発揮してくれます。
　
たとえばCakePHPは、良く言えば機能満載で、
痒いところに手が届いてサイト作りをラクにしてくれますが、
悪く言えばおせっかい機能満載で、
サイトの性質や、サイト作りの方針によっては足かせになります。
　
私のECサイト構築の立場では後者の立場だったのでCIはそのへんを解決してくれました。
　

　
とは言え、CIいいところばかりでは有りません。
　
前述の通りモデルやDB周りの実装がゆるゆるで、
ぶっちゃけモデルなんかナシでどうにかできちゃいますが、
ActiveRecordの機能は有しているものの、
Cakeよりは、ずっと「DBを操作している感」のある使い方になると思います。
また、DB操作が多いサイト作りの場合、
モデルファイルが大量になるかもしれません。
　
そして、CIを使ううえでPHPerが一番戸惑うのが、セッションでしょうね。
CIのセッションは、PHPのセッションは使わず独自実装です。
cookieに全てのデータを突っ込むcookieセッションか、
DBへデータを保存するDBセッションの2パターンが用意されていますが、
やっぱりファイルを使ったセッションもほしいところ。
ファイルセッションを利用する場合は、
自作でライブラリを作るか、別に配布されているライブラリを利用擦る必要があります。
（ただ、前述のとおりライブラリづくりは比較的簡単です。）
　
デフォルトで$_GETを破棄するという豪快な仕様になっているので、
そのへんを扱うのを最初戸惑うかもしれません。
（設定さえ覚えれば、すぐに慣れますが）
私の場合は、$_REQUESTを取り回す自作ライブラリで対応しています。
@kenji_sさんから

デフォルトで$_GETを破棄するのは CodeIgniter 1.x の仕様で 2.0.0 (Reactor) からはデフォルトで$_GETが使えるように変更されています

とご指摘いただきました。ありがとうございます。ちょっと不勉強でした。
　
あと、これは良いと言う人と悪いという人がいますが、
CIのviewは基本的に生PHPです。
私の場合は、生PHPは「うーん」な人なので、Smarty拡張しました。
（ただし、Smartyも「うーん」ですｗｗPHPTALにしようかなとか考えています）
　

というわけで、とにかくCIは頭がイイんだぜ！って話になっちゃいましたが、
よくないところを吸収するには、それなりのPHPの知識も必要というわけです。
以前書いたPHPのフレームワーク選択の記事でも書きましたが、
CIは、良くも悪くもちゃんとPHPが使えているということが前提条件であるFWでしょう。　

| メインページ |