EC-CUBE 2.4系のカスタマイズ

eccube-logoEC-CUBE2.4系をカスタマイズして使用している知人から相談を受けて、送料の扱いをEC-CUBE標準では対応出来ないパターンに対応させました。

ヒントとなるカスタマイズポイントは、EC-CUBEの公式カスタマイズ本(青本)に書いてあったので、その部分を修正することと、後は実現したい内容を整理すると、極々単純な計算式に修正するだけで行けるという事がわかったので、実際のカスタマイズはEC-CUBEの構成ファイル3つを少し修正するのと、データベースに一つレコードを追加するだけでOKでした。これらの検証はWindows上にインストールしたPostgreSQL+Apache/PHP+phpPgAdminの環境で簡単に行えました。簡単な検証ならXAMPPでも良いかも知れませんね。

続きを読む

Windows7環境でPostgreSQL

PostgreSQLは今までずっとLinuxサーバー上に構築してきたので、Windows版を使った経験が無くて敬遠していた所があったのですが、EC-CUBEのテストをやりたいのでPostgreSQLをローカル環境で使いたくて試してみたところ簡単に構築出来てしまいました。

pgAdmin-IIIPostgreSQLのWindows版をインストールするのは、コレといってどうという話でも無いのですが、インストーラに「スタックビルダ」というものが付属されていて、試しにオプションを確認してみたところ、Apache/PHPという項目と、phpPgAdminという項目があるではないですか。選択するとネット経由で当該インストーラをDLしてくる仕組みらしいですが、PostgreSQLをインストールしたPATHを案内してやるだけで後はお気軽インストール。

続きを読む

Windowsパソコンのネットワークポート使用状況を確認して競合トラブル対応(Windows)

以前、Windowsアプリケーションを実行した際のネットワークトラブルの原因として、「ウェルノウンポートの競合」というエントリーを記しましたが、ポートの競合の状態をもっとWindowsライクに調べる方法を思い出したので追加情報です。

使うのは「リソースモニター」の「ネットワーク」タブです。

リソースモニターのネットワークタブからリッスンポートを確認出来る。

リソースモニターのネットワークタブからリッスンポートを確認出来る。

続きを読む

livedoorが各種サービスの提供を終了

ライブドアがメールをはじめ、各種サービスを終了させるアナウンスを出した様です。

livedoor、新たなチャレンジにむけて一部サービスを終了 – livedoor 広報ブログ

ライブドア・ブログを数年前から使っていて、これはこれで重宝しているので、ブログサービスが終了にならなかった事は幸いと捉えているのですが、メールとPICSは少しだけ使っているのでちょっとだけ面倒です。

メールは他のメールアドレスに転送し、登録しているメーリングリストのメールアドレスを切り替えるしかありません。猶予期間がありますがとっとと対策しておいた方が良いと思うので本日早速変更しました。ライブドアメールはGoogleが提供しているGoogle Appsを流用しているので、メールに付随してカレンダー機能等が問題になりそうな気がします。

私はGoogleが提供しているGmailをメインにしているので、カレンダー機能はライブドア側では使っていませんでした。こういう場合は「使ってなくて良かった」って感じですが、ライブドアメールのカレンダー機能(実質Googleのサービス)を使ってた人はエクスポートして、Gmail等のアカウントを新たに作ってからICSファイルをインポートする方法が一番の近道ですね。

カレンダーをエクスポートする – Google カレンダー ヘルプ

PICSについては、既存の画像ファイルをまとめてダウンロードする機能を2013年5月上旬に実装すると書いていますが、あんまりあてにしない方が良いと思っています。ライブドアって無償サービスに関しては結構約束を破るので(w

実は今回のアナウンスで初めて知ったサービスもあって、統合スパムフィルタ「スパムちゃんぷるー」なんかは「知ってたら利用させてもらったのに!」と今更ながら思ったりもする訳ですが時既に遅しですね。その他にもリストアップされています。該当サービスをご利用の方は、期限までにバックアップを取るなり、代替サービスへの移行を検討する必要がありますね。

全く余談ですが、私にとっては、先日アナウンスされたGoogleリーダー(RSS)の廃止が一番痛いですけどね。やっぱりfreedlyしかないかなぁ。

New Relicを使ってみる

インフラ系エンジニアとして食っている立場上、押さえておくべきだろうなと思ったので実際に自分の管理サーバーでパフォーマンス監視ツールを使ってみる事にしました。

ちょっと調べれば分かる事なので記しちゃいますが、当サイトは現時点VPS上のLinuxサーバーで稼働させています。普通にこうやって記事をPOSTしたり、実験的なWebサービスを公開したりする分には特に不自由もなく、レスポンスも許容範囲内に収まっていると感じているのですが、実際の数値を見てみたくなった為です。

色々有ると思いますが、サーバーパフォーマンス監視サービスとして定評のある「New Relic」の無料版を使ってみる事にしました。無料版の範囲でも充分参考になるデータが取れます。

New Relic対応OS

New Relic対応OS

上図の画面キャプチャの通り、Linux(deb系、rpm系、その他)と、Windows 2003 / 2008 Serverに対応しています。インストールはオフィシャルの手順に従って行いましたが、さほど難しくありませんでした。ネット上に日本語のインストール手順が無いのは、まぁそういうもんだなって感じです。(公式の手順は簡単な英語だし、特殊なインストール手順では無いので頑張りましょう)

当サイトでは、Web系は主にPHPとMySQLを使っているので、PHPしか監視していません。Pythonは今後積極的に使っていきたいと思っていますが現時点は計測する程の事も無いのでパスです。Rubyは個人的にはあんまり好きじゃないので後回しです。

現時点、このサービスの対象プラットフォームは下記の通り。

  • Ruby
  • PHP
  • .Net
  • Java
  • Python
  • iOS
  • Android Apps

これだけ対応していますので、ほとんどのサーバーアプリケーションの処理速度とか、ページ毎の処理の遅さとかを追跡するには充分ではないかと思われます。レスポンスが遅いページはソースコードを要見直しですね。