薫平BLOG

今回実装したのは「Facebook Comments」と「LikeBox」の二つ。
実装の流れは次の通り。

・AppIDとApp Secretの取得
https://developers.facebook.com/apps
より、新しいアプリケーションを作成して取得。
基本的にFacebookアカウントがある人なら誰でも取得可能。
アプリの表示名とグラフに利用される名前を入力して取得。
App Secretは日本語訳「アプリの秘訣」です。

 

 

 

 

・Comments
https://developers.facebook.com/docs/reference/plugins/comments/
から。HTML５など、三種類から選べます。
 

 

 

 

 

 

 

 

 

 

 

基本HTML５は、HTML5のヘッダーが設定されていないと動作不安定なので、

ちゃんとブログの仕様にあったものを使うの推奨です。

 

・LikeBok
まず、通常のFacebookアカウントだけでは使えないことに注意。
FacebookPageを先に作っておくこと。

結構簡単に作れます。作成はこちらから。
http://www.facebook.com/pages/create.php



 

 

 

 

 

 

ジャンルに悩んだらコミュニティで良いかと。

その後は、こちらでCommentsと同じようにLikeBoxのコードを取得すれば終了。
http://developers.facebook.com/docs/reference/plugins/like-box/
 

これ全て実装しても一時間かからないぐらいですので、

皆さん興味本位でやってみてはいかがでしょうか。

正月家でがっつり開発しようと思って、eclipseの3.7をインストールしてみた。
Macにインストールは初めての経験。（Mac OS X 10.7.2）

※下記は作業時点の情報です。情報が古い場合がありますのであしからず。


■WEBからダウンロードしたもの
pleladesのMac版は無いようなので、本家からダウンロード。
http://www.eclipse.org/downloads/

 
 
 
 
 
 
 

日本語化用にpleladesの標準版JRE無しをダウンロード。
http://mergedoc.sourceforge.jp/


 
 
 
 
 
 

AndroidSDKをgoolgeからダウンロード。
http://developer.android.com/sdk/index.html


 
 
 
 
 
 

これで下記の３つの圧縮ファイルがあるはず。
android-sdk_r16-macosx.zip
eclipse-java-indigo-SR1-macosx-cocoa-x86_64.tar.gz
pleiades-e3.7-java_20110924.zip

 
■インストール手順
GUI面倒なのでshellで。
（自分はrootユーザー以外のユーザーで作業しています。）
ソースの解凍。pleiadesはdropinsフォルダのみ日本語化のためコピー
sudo tar -xvf ~/Downloads/eclipse-java-indigo-SR1-macosx-cocoa-x86_64.tar.gz -C /Applications
sudo unzip ~/Downloads/android-sdk_r16-macosx.zip -C /Applications
sudo unzip ~/Downloads/pleiades-e3.7-java_20110924.zip
sudo cp -ra ~/Downloads/pleiades-e3.7-java_20110924/eclipse/dropins/* /Applications/eclipse/dropins/
eclipse.iniの書き換える。dropinsにパスを通す。

#viで編集
vi /Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse.ini

#最終行に下記を追加
-javaagent:../../../dropins/MergeDoc/eclipse/plugins/jp.sourceforge.mergedoc.pleiades/pleiades.jar
-clean
※-cleanは初回以外不要

#.profileを作成し、環境変数へtoolsのパスを設定
vi /User/{UserDirectory}/.profile
PATH=$PATH:/Application/android-sdk-macosx/platform-tools


Eclipse起動。日本語化を確認。
続いてAndroidSDKの設定。
ヘルプ→新規ソフトウェアのインストールで下記のように入力。



 
 
 
 
 
 
 
 
 
 
 
 

手順に従ってインストール。
つづいて、DDMSとADBの設定。
以前はtools以下にあったabe.exeが初期には無いので、UPDATEを行う。
{AndroidSDKHOME}/tools/android update sdk

これでADV Managerが表示されるので、開発するAPIをインストール。
※全部入れようとすると何時間も掛かるので注意。いまさら1.6のAPIとか入れても意味ないよね？
これでDDMSが正常に動けば一通りの作業は終了。

 
 
 
 
 
 



今日はこれまで。

アジャイルにおけるリファクタリング（再構築）の重要性の話。

アジャイルとは開発しながらソースのリファクタリングを行い、システム精度を高めていくのが絶対条件と言える。リファクタリングをしないと、デグレードが頻発するからだ。デグレードは全体の開発を遅め、停滞させる。ここで大事なのは、デグレードを放置すると、取り返しのつかないレベルでアプリケーションが退化してしまう点にある。

リリースを優先すべき時は必ずある。しかし、リファクタリングを十分にせず、デグレードを頻発させ、バグフィックスに追われてしまう状況では、その瞬間のリリースは達成できても、そのソースを使った次のリリースに必ず影響を及ぼす。一瞬の戦果のために、埋めた者すら場所を忘れる地雷を埋めるような作業だ。

自分は、過去にそういうアプリケーションを山ほど見てきた。そしてそれらの多くは、廃棄となった。新しいアプリケーションを作った方が早くなってしまうからだ。そして、その判断は、ほとんどの場合正しい。なぜなら、近年のアプリケーション開発に置いて、数年前ーあるいは半年であろうとも、過去の設計思想やフレームワーク、技術は、最新のものと大きく性能が離れているのは当然だからだ。

そのリニューアルの判断が出来ない、もしくは黙殺されたアプリケーションは悲惨だ。リファクタリングもされず、機能改修を続けるということは、いずれそのアプリケーションの荒廃を招く。埋めた地雷を避けて通れない、そんな膨大な数の地雷が埋められた死の戦場だ。そして、一番恐ろしいのは、その事実をプログラマー以外が気づいたときは、もう既に手遅れである場合がほとんどだということだ。

この自体を防げるのは、能力のあるプログラマー、つまり最前線の戦士しかいない。現場で自ら銃を持たない指揮官では気づくことは出来ない。なぜなら、ソースのリファクタリングされていないとき、死の戦場となる前にその提案できるのは、現場で日々ソースを見ているプログラマーしかいないからだ。


これが、なかなか居ないんだ。
だからリファクタリングの重要性を説明するのは難しい。

最近、仕事で有料のCMS制作なんてものに関わっているわけだが、
よくよく考えると、前職までの自分の開発者人生で、有料のCMSなどというものに触ったことがない。

自分がこれまで触ったCMSと言えば

XOOPS
WordPress
OPENPNE

その他はCMSじゃなくてフレームワークだし。（MojaviとかcakePHPとか）
かろうじてMovable Typeにちょっと触ったくらいか。
全く今まで有料に触っていなかったので、これはマズいと思って、ちょっと前から、有料のCMSというものを調べていた。
その感想は一口で言えば「こんなの大企業しか使わないんじゃないの？」というレベルの高性能なものばかりであるということ。

その中でも気になったのはこんなところ
HeartCore
Power CMS for MT
Sitecore


どれも高機能だし、多人数での更新や、複数サイトの情報を一元管理するのを前提としている。
機能比較とかは別のサイトに任せるとして、じゃあ、もっと小さい規模の有料CMSってないの？という視点で調査を継続してみた。
ターゲットとしては、従業員３００名以下の中小企業で、WEBリテラシーの低い業界をターゲットとして、最適化CMS。それが今回の自分のミッションだからだ。




これが無い。



いや、無いというのは適切じゃなくて「自分がこれ良いなー」と思えるものがない。
そこで、どうしてなんだろう？　と考えてみた。

答えは単純。
そんなCMS誰も必要としていないからなんだよね。

そもそもCMSっていうのは、コンテンツマネジメントシステムの略。
つまり、コンテンツを管理するためのシステム。
たくさんコンテンツを持っていない中小企業は、そもそも管理するシステムなんか必要ないんじゃないのかな。
需要が無い。だから開発がされない。コミュニティが存在しない。開発する企業が存在しない。
それこそWordPressや、無料のCMSを少しカスタマイズするだけで十分ユーザー満足できるものができる。

そういう企業のお客様が真に必要としているのは、
CMSじゃなくて、費用対効果の良いWEBマーケティングの成果であって、過程じゃない。
組織の変動も多くないから、情報の管理の重要性も大きくはない。
もちろん、複数のサイトなんて持たないから、マルチドメイン対応なんて必要ない。
Wizwigエディタすら、本当は不要なのかもしれない。

でも、そうじゃないお客さんに本当に必要なのは、ツール以前に、お客様に毎に真に必要なもの考え、提供するものを変えるという姿勢なんじゃないかと思う。一言で言ってしまえばそれは「ソリューション」ということになるんだろう。大企業に対しては、自社で自分たちの色にあったソリューションを作り出すノウハウがあるから、ソリューションよりも金額に見合った高機能が大事なのかもしれない。

あるお客さんには、EC機能が必要かもしれない。
あるお客さんには、機能よりも良いデザインが必要かもしれない。
あるお客さんには、なによりも高いサイト内検索がいるかもしれない。
あるお客さんには、ホームページよりもランディングページが必要かもしれない。
本当は全てを満たしてあげたいし、満たす最大限の努力をすべきなんだろう。
でも、世の中にはトレードオフって魔法の言葉があって、それに現実はいつも屈するんだよね。


なんか主題とずれて来た気がするから無理矢理まとめるけど、つまるところ、システム自体に目的なんて無いっていう当たり前の答えなんだよね。
問題は、システムを使って何を実現したいかであって、常にシステムは目的達成のためにある。
目的が「CMSを作る」ではいつまでたっても、作るべき完成系が見えない。
それは、手段の目的化だから。


「誰のために、何のためにCMSを作るのか」それが重要なんだよね。
そして、その「目的」が明確になったとき、一度CMSを作るという「手段」そのものを一度疑う必要があるかもしれないな。

2010年11月から受注案件でEC-CUBEを用いた案件に携わってきました。
そこで出た問題点や必要改善点に関して、簡単にまとめていきます。
基本的には受注側、ソリューションする側の視点で書いています。

その1はコチラ


・価格表示の問題
eccubeには価格表示が二種類存在します。
販売価格と通常価格です。
二種類存在することは、セールなどに使う目的なので問題ないのですが、商品詳細に金額が表示される際、販売価格は税込で表示されるのに対し、通常価格は税別で表示されます。別に表記的に違法ではないのですが、ECサイトの運用としては気になる点です。改修が必要とされるクライアント様は多いと思います。


・送料の個別設定について
送料の個別設定ができません。
例えば、1000円の商品一つで500円の送料がかかる場合、複数注文してもEC-CUBE上は送料が500円と表示され、実際の決済でも500円しか課金できません。
また、この問題は異なる商品を注文する問題にも直結しています。商品別に設定ができないのです。これはEC-CUBEを用いてECサイトを作る際に陥る大きな問題点の一つです。


・バックアップについて
新しいヴァージョンのEC-CUBEには、デフォルトでDBのバックアップの機能はついているのですが、自動化はされません。サーバ側の設定が必要です。
工数計上としては見落としがちな点です。


・売上集計機能の集計条件について
テストで作成したログを削除する作業は、サービスイン前にはつきものです。
しかし、EC-CUBEの場合、期間別集計と年代別集計は集計データの論理削除でデータが削除出来ません。

具体的に言えば下記の辺りの話です。
eccube/data/class/pages/admin/total/LC_Page_Admin_Total.php
$objPage->arrResults = $objQuery->select($col, $from, $where, $arrval);

よって、受注ログとは別に集計テーブルのデータを削除する必要があります。


今日はここまで

2010年11月から受注案件でEC-CUBEを用いた案件に携わってきました。
そこで出た問題点や必要改善点に関して、簡単にまとめていきます。
基本的には受注側、ソリューションする側の視点で書いています。

・DBの選択
EC-CUBEに慣れた人材がいなければ、Mysqlを選ぶべきでは無いと思います。Postgresqlにすべきです。
前に書いたエントリーにも書きましたが、テーブルdtb_customerのbirthカラムがTimestamp型で設計されているため、ECサイトとして取得が必要な生年月日の保存に問題があります。
また、初期のindexなどが整備されていないため、Mysqlに聡い人でないと運用は難しいかもしれません。

大規模案件でMysqlのスペシャリストなどが入れば別ですが、立ち上げ時にそんな人材がアサインされているのは稀だと思います。

・課金方法の選定
これは案件規模によって要件は異なるでしょうが、クレジットカードやWEBMONEY、コンビニ決済などは代理店のモジュールなどを入れなければなりません。
事前に必要な課金方法については要件を詰める必要があります。
モジュールによって導入難易度が異なるので、見積にも工期にも大きく影響します。
また、一度サービスインしてから追加するのは一度サイトを停止しなければならず、非常に面倒だと思います。

・受注管理のメール配信について
自動メール通知のタイミングを案件によって重点的に確認すべきです。
注文確認メールなど、一部はEC-CUBEのシステムでデフォルトで出るようになっているのですが、出ないメール通知もあります。発送完了メール等は出ないです。
大きな範囲で言えば、クライアントがEC-CUBEのシステムによってワンストップでサービスを行おうとしているのか、そうでないのか事前に十分なヒアリングが必要です。

・会員規約他の入力制限
DB上の制約は別として、システム上のvalidateとして、入力制限が掛けられている箇所が幾つかあります。
具体的には会員規約の文字数が1000文字です。
今回の自分の案件では、クライアントが準備した会員規約文言が1000文字内に収まりませんでした。
事前に確認しないとサービスイン間近で余計な工数が発生します
また、サイトで表示する項目の微妙な違いも事前に詰めて置く必要があります。

今回はこのへんで