conoha で redmine を SSL 化する

conoha で redmine を SSL 化する

conoha VPS サーバーで redmine が簡単にインストールできることを知ったので、今まで AWS で redmine を運用していたのですが、バージョンアップ(2→3)もしたかったので、最初っから構築し直すことにしました。

インストールは非常に簡単であっという間に出来たのですが、SSL(HTTPS) 化は自分で設定しないといけません。自動で出来なかったので、ちょっと苦慮したので、ここで備忘録までに留めておきます。

SSL 化は、あんまりコストを掛けたくなかったので、Let’s Encrypt を利用するようにします。入力項目もあるので、やはり SSL は必須かなと思うので、conoha のインストールの中で自動化したら良いのになあ〜と思うのですが。

Firewall の設定

https でのアクセスが許可されていないので、Firewall の設定で有効にし、リロードします。

# firewall-cmd --list-all
# firewall-cmd --add-service=https --zone=public --permanent
# firewall-cmd reload

SSL ライブラリの追加

インストールされている Web サーバ (Apache) には SSL ライブラリが入っていないためインストールして設定します。

# yum install mod_ssl

https アクセス時の DocumentRoot の設定

# vi /etc/httpd/conf.d/ssl.conf

最初の方に以下のコードを記入するか、あることを確認します。

DocumentRoot "/var/lib/redmine/public"

リスタートします。

# systemctl restart httpd

この状態で https でのアクセスは可能ですが、証明書が自己証明なので、通常のブラウザアクセスではアラートが出てしまうので、 Let’s Encrypt の証明書を発行して設定します。

Let’s Encrypt の証明書発行と設定

# yum install epel-release
# yum install certbot python-certbot-apache

まず、上記の2つをインストールします。次にドメインの指定をします。「ドメイン名」の部分に設定したいドメインを入力してください。

# certbot certonly --webroot -w /var/lib/redmine/public -d ドメイン名

上記を実行すると、以下のフォルダに秘密鍵や証明書が作成されます。

/etc/letsencrypt/live/ドメイン名/

ssl.conf を設定する。

# vi /etc/httpd/conf.d/ssl.conf

以下の項目を入力します。

SSLCertificateFile /etc/letsencrypt/live/ドメイン名/cert.pem 
SSLCertificateKeyFile /etc/letsencrypt/live/ドメイン名/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/ドメイン名/chain.pem

systemctl をリスタートします。

# systemctl restart httpd

https:// でアクセスしてアラートなどが出ないことを確認します。
問題なければ、これで SSL 化は完了です。

色々と文句を言う人の理論

色々と文句を言う人の理論

最近、色々と文句を言う人が近くにいて、ふと思うのだけど、大抵文句を言う人はリスクを取って動くことが出来ない人なのかなと。

そして、失敗や欠点を見つけると、その原因を指摘して、徹底攻撃して自分のできている部分を強調して安心するんだろうなと。

文句を言う人は「叱り方」を知らないのだろうなと。「怒ること」と「叱ること」とは、似て非なるものだと個人的には思っている。

「怒ること」とは基本的に感情的な感じで、責めるだけで前向きではない。しかも、自分の都合良いように動かないから「怒ること」がほとんど。議論中に怒るのとか、端的な例。だから、怒られた人達は怒られないようにするために、嘘を付いたり、隠したりするようになる。怒った人達は自分が怒ったからそうなったと思わず、相手の人間性を責めて、相手のせいにする。そう、基本的に怒る行動自体が自分の希望に沿っていないから行っているのだけど、それに気づかず相手が悪いと決めつけているからなんだよね。そして、自分の周りには結果として本音を言ってくれる人が居なくなるという。

それに対して「叱ること」とは、責めはするけど、何が悪かったのかということと、今後どうしたら良いのかを一緒に考えることだろうなと。尊敬できる親や学校の先生などはこれがしっかりと出来ている。そうすると叱られた人は自分で考えるようになる。そうして、叱られないように考えて行動が出来るようになる。これを、面倒だけど何度もするのが教育かなと。

大人もそうだけど、子どもは尚の事、繰り返さないと出来ない。最近、なんか頭のなかに残っている山本五十六さんの名言を思い出すとやっぱり真理だなと思う。

まあ、私もこんな偉そうな事書いているけど、全然出来ない人なのでもっと努力しないとなと。爆

PTA会長として卒業式に話した祝辞

PTA会長として卒業式に話した祝辞

久しぶりにブログを書いています。色々と忙しくてねえ、こちらのブログのアップが出来ていなかったです。

昨日は長女の誕生日で、先日長女の卒業式にPTA会長として祝辞を読んだのですが、皆さんに好評だったのでこのブログで紹介することにしました。PTA会長としてよりも、卒業生の親として娘やその娘の友達に向けて話しました。子どもたちにも響いてくれたようで、道端で「あ!ハイキューのおじちゃんや」と言われたので、聞いてくれていたのだなと。笑

ここから=========

卒業生の皆さん、本日はご卒業おめでとうございます。
皆さんの後ろでは、ご家族が本当に嬉しそうな顔をしておられます。
今日は私の長女もこの卒業生の中にいますので、PTA会長として、また卒業生の親として挨拶をさせて頂きます。

本日ご列席をいただきましたご来賓の皆さま、公私ともにご多忙の中、我が子らの卒業の門出に祝福を頂きまして誠にありがとうございます。地域の皆様、特にスクールガードにご協力頂いております皆様には、子どもたちを毎日見守って頂きありがとうございました。子どもたちも、皆様の活動を通して、身をもって地域におけるボランティア精神を体験し、今後のボランティア活動に活きてくると思います。子どもたち同様、私たちもその精神を見習っていきたいと思います。この場をお借りして、子どもを持つ親を代表して厚く御礼申し上げます。

校長先生をはじめ、教職員の皆様、本日こうして、子供たちが卒業を迎えられるのは、皆様が子どもたちを愛し、優しく、時には厳しくご指導いただいた賜物だと思います。本当にありがとうございました。時に子を想うあまり、難しいお願いをしてきたかと思います。それに対して誠心誠意ご対応いただきまして誠にありがとうございました。これからは人生の先輩として子どもたちの良き相談役やアドバイザーとしてご指導を賜りますよう、お願い申し上げます。

卒業生の皆さん、12年前はちょうどアテネオリンピックがあり、水泳の北島選手が金メダルを獲得し「チョー気持ちいい」という言葉が流行語になった年でした。そんな年にあなた達は私たちの子供として生まれてきてくれました。初めて抱っこした時、あなたたちはとても小さくて、私たち親は言葉では表現できない深い喜びを感じることが出来ました。

そして、6年前あなたたちは雨が少し降る4月小学校に入学しました。AKB48のヘビーローテーションという曲が流行り、初めての体育大会ではこの曲に合わせて一生懸命ダンスをしていたのを覚えています。それから、オープンスクールや音楽会、ふるさとまつりなど、小学校ではかけがえのない楽しい経験を親子ともどもさせて頂きました。
また、6年生になり修学旅行では原爆の被害になった広島を訪れ、戦争の悲惨さを感じ取り、直前に訪れたオバマ大統領の折り鶴を見、これからの平和は過去にとらわれず、自分たちが作り上げていかないといけないと考えたのではないかと思います。

この6年間、本当に楽しいことや悲しいこと、嬉しいことや悔しかったことなどたくさんあったと思います。その一つ一つは決して無駄なものにはなりません。これからのあなた達を作り上げ、成長をさせてくれます。

そんな卒業生の皆様に先に生まれた先輩として、3つの大切にすべきことをお話しさせていただきます。

一つ目は「時間」です。残念なことに人は生まれながらにして平等ではありません。お金持ちの家に生まれたり、姿形がよくうまれたり、健康な体で生まれたり、それらの逆もあります。ただ、全ての人に平等に与えられているものがあります。それが時間です。時間は全ての人に平等に同じように過ぎていきます。この時間をどのように使うかによって私たちやあなた達の未来が変わり決まっていきます。過去に何をしたかを反省する必要はありますが、それ以上に今からこの時間をどのように過ごしていくかで、あなたたちの未来が変わっていきます。あなた達の未来の為に今から過ぎていく時間を大切に使ってください。

二つ目は「努力」することです。私の好きなバレーボール漫画で「ハイキュー」があります。烏野高校バレーボール部元キャプテンの田代さんが、OB達の意志を継ぎ諦めずに努力し、全国大会で活躍する後輩たちの姿に涙し「チャンスは準備された心に降り立つ」と言うシーンがあります。諦めずに努力した者だけが手にできるものがあります。努力すれば成功するとは限りません。ですが、努力して行動した者にのみ、チャンスは訪れます。チャンスを手に入れるために努力することを忘れないでください。

三つ目は「今の友達」です。大人になると仕事などで関係する人達が増えていきますが、友達と呼べる人はなかなか現れません。なぜなら、大人になると損得勘定で物事を判断することが多くなるからです。ですが、小中学校時代の友達は、ただ偶然に同じ場所にいた、その中で気の合った仲間です。シンプルに気が合う友達なのです。そういう友達こそが本当の友達だと思います。私は福岡出身で、今でも時折帰省すると小中学校時代の友達が喜んで集まってくれます。彼ら彼女らは、私にとって人生のかけがえのない財産です。今の仲のいい友達を大切にして欲しいと思います。

卒業とは一つの区切りです。また、今日から新しい時間が始まります。
卒業する皆様の卒業文集を全て読ませて頂きました。その皆さんの夢の為にも、この「時間」「努力」「友達」の3つのことを大切にしていただきたいと思います。

最後に、卒業生皆さんに保護者として一言言わせていただきます。

生まれてきてくれて本当にありがとう。そして、こんなに大きく成長してくれてありがとう。
これからも、一緒に笑ったり、厳しく叱ったりすると思いますが、家族として同じ場所で大切な時間を、もうしばらくのあいだ一緒に歩み続けさせてください。大人になったあなた達に「あなた達の子供で良かった」と言ってもらえるように日々頑張っていきますので、これからもよろしくお願いします。

本当に卒業おめでとう。

ここまで===========

今朝も、長女が起きた一番最初に「お父さんとお母さんの子供として生まれてきてくれてありがとう」と言いました。

私は大病を患い、結婚も子供も出来ないと思っていた時期があったので、子供や家族がいてくれるような些細な事が大きな幸せに感じてしまうんです。

さて、私も時間を大切に、仕事を進めていきましょう。笑

次期バージョン、WooCommerce2.7のお話

次期バージョン、WooCommerce2.7のお話

この記事はWooCommerce Advent Calendar 2016の15日目の記事です。

ふう。先週、ちょっと某所のメールアドレス乗っ取り事件など予定外の仕事が急遽入ったりして、仕事が詰まってしまって、大変でした。

さてさて、来年2月(多分下旬)に公開予定の WooCommerce 2.7 の最新情報をお送りします。

β版が2016年12月15日にリリースされたので詳細はこちらのブログで公開しておりますので、御確認ください。

WooCommerce 2.7 β1 バージョン公開

さてさて、今回のアップデートは結構トラブルが発生する可能性があります。特にテーマやプラグインに起因する障害は前回の2.6以上に多い可能性があります。

まずは、CRUD関数への移行に伴うテンプレートの変更は大きいです。正直、ズレは怒らないかもしれませんが、以前のままですと表示速度の改善が見られない可能性などがあります。

特に変わるのが、商品ページの画像表示。今まではテーマなどで変更されていた画像ギャラリーの色々な見え方が標準で対応出来るようになりました。ズームとか色々出来るようになったので、素敵なのですが、過去のテーマを使っているとズレることもあるかもです。あまりないと思いますが、javascriptの競合なども可能性としてはあります。

詳しい部分は上記の記事を見てもらえたら分かるかと思いますが、プラグイン等が問題を起こす可能性がありますので、各バージョン対応状況などを把握した上でアップデートする必要があります。

βバージョンが公開されましたので、保守運営をされている方は早めに動作確認を進めることをお勧めします。正直β2ぐらいからでいいとは思いますが。

ちなみに、今度のコードネームがBionic Butterflyというのですが、ロボット蝶?とでも約したら良いのでしょうか?はじめて、昆虫というか虫のマスコットが表れそうです。

マスコットのデザインも結構楽しみな感じです。

あと、色々な所で公開されている情報から、Apple Payの決済プラグインが開発を開始したそうです。また、Salesforceと連携するプラグインも開発が開始されています。

世界的な広がりはまだまだ進めていくような感じですね。

WooCommerce にも最適な KUSANAGI の訳 〜 WooCommerceの開発者とECサイト運営者の視点

WooCommerce にも最適な KUSANAGI の訳 〜 WooCommerceの開発者とECサイト運営者の視点

どうも、 WooCommerce をいじり倒している田中です。

この記事はKUSANAGI Advent Calendar 2016 16日目のエントリーです。

他の皆さまが技術的なKUSANAGI が早いよ〜!と言う事を書かれているので、筆休めといいますか、「技術のこと分からんけど、KUSANAGI ってどういう場合に最適なの?」と言う事を、運営といいますか、経営などの視点から出来るだけ分かりやすく書いてみようと思います。

さてさて、「KUSANAGI = PHPのCMS系などが爆速になる」というイメージを多くの方がお持ちかと思います。はい。その通りです。ですが、他の選択肢がないの?と言いますと、それはもちろんあります。ですので、ネコも杓子もKUSANAGI が良いとはならないと思います。ですが、以下の2点で考える時には良いのではないかなと。

  1. サーバー構築及び運営費用をあまり出せない
  2. サーバー会社を限定できない

サーバー構築及び運営費用をあまり出せない

まず、爆速のサーバー環境にしたい場合に多いのが、そのサイト及びサービス独自にサーバー技術者などが付いて、独自にサーバーをカスタマイズしていくというパターンです。
それ以外にAWSなどに多いのですが、KUSANAGI のようなパッケージがあり、それを導入するというパターンです。
上記の2点は簡単に言うと、メリットとしては自由に色々とやることが出来ますが、デメリットは費用です。技術者を雇ったら人件費が掛かりますし、パッケージ使用料がかかるパッケージが多いです。(※もちろん、パッケージ費用のかからないものもあります。)

ということで、お金が湯水のようにあって、ガンガンやるんだ!という方々にはKUSANAGIは一つの選択肢でしかありません。
ですが、初期導入やスタートアップ、もしくはアーリーステージのビジネスをされている所では、サーバー運用費がそこまで出せないのは現実問題としてあります。そういう方々には運用・サーバー構築作業を含めコストメリットはかなりあるかと思います。また、適切なクラウドサーバーを選べばスケールアップもサーバーを変えること無く出来ますし、儲かったらKUSANAGI を開発しているプライム・ストラテジー様に直接サーバーの保守などのお手伝いしてもらうことも出来ます。

「KUSANAGIフルマネージドサービス」

サーバー会社を選択したい

また、大手企業様では、色々な政治的な関係で使えるサーバーが制限と言うか限定されることがあります。「当社はMSと取引が多いので、Azureを使いたい」とか、「IBMでサーバー契約しているからIBMでの契約をしたい」とか「GMOとの取引が多いからGMO系のサーバーが良い」などなど、良い悪いは別として、そういう事が日本の大企業や中規模の企業ではよくあるのですが、KUSANAGI は多数のプラットフォームに対応しているので、融通が非常に効きます。

KUSANAGIがご利用いただけるパブリッククラウド

 個人的な意見としては、クラウドサーバー系で技術などにおいて AWS がやはり一歩先を行っていると思っておりますが、現実問題としてこういうことがあるので、KUSANAGI は様々な企業内で提案しやすいサービスだと思います。(ちなみに、KUSANAGI は AWS でも使えます。)

と、ここまでが経営者的に視点での、KUSANAGI が良いんじゃないかなと思われる点です。書いています通り、上記のような条件の時に良いだろうということで、そんな条件が無ければKUSANAGI を選択肢の一つとして考えれば良いと思います。サービスにはそれぞれにメリット・デメリットがありますので。

次からは、ECサイトを運営する立場といいますか、私の本業というか WooCommerce に絡むKUSANAGI が良いんじゃない?という部分を書きたいと思います。

  1. ECサイトはキャッシュ処理でページ表示速度を上げたくない
  2. アクセス数よりもセッションやクエリー処理が気になるECサイト
  3. 手動でもスケール(メモリなどの増減)が出来ればとりあえず大丈夫かな?

ECサイトはキャッシュ処理でページ表示速度を上げたくない

ECサイトの場合、急な商品価格の変更や売れ筋商品ランキングなどリアルタイムに変更してそれを表示したいという必要があります。その時にキャッシュ処理がされていて、更新がされないというような事が起こると非常に困ります。ですので、キャッシュ処理をしなくても十分早く表示できるサーバーのほうが良いのです。
WordPressのキャッシュプラグインの中には、ページが更新されたらキャッシュを削除する処理などがされていることが増えてきて、価格変更などには更新作業をするので問題ない場合もありますが、商品ページで在庫を表示する場合やウィジェット的な部分などで商品ランキングなどを行うと、やはり全体としてキャッシュ無しで動かせた方が良いのです。
また、買い物カゴ(カート)処理や決済処理のページはキャッシュ化するとそもそも問題が発生するページがありますので、キャッシュ無しで早いというのは魅力的な部分なのです。
もちろん、KUSANAGI の機能の中にキャッシュ処理があります。ですが、そもそもの開発の経緯の中でキャッシュ処理をしなくても早く動かせる仕組みがなされています。これは、意外とECにおいては重要です。

ただ、もちろん商品ページの表示速度はECにおいては死活問題です。商品ページを表示するのに時間がかかる場合、商品購入の意志が弱くなるということは経験的にも、研究結果としても証明されていますので、商品ページの表示スピードは大事です。それにおいて、KUSANAGI のキャッシュ無しでの処理能力は十分だと思います。商品ページのコンテンツ内容にも寄りますが。

アクセス数よりもセッションやクエリー処理が気になるECサイト

そもそも、ECサイトはコンテンツサイトと比べてアクセス数が少なくても収益化が出来ます。

コンテンツサイトはPVを多数稼いで、その上に広告を表示したりアフェリエイトリンクを表示させることによって収益を出しています。ですので、広告クリック率が2%でワンクリックの収益が10円だったとした場合、10万円稼ぐためには50万PVが必要となります。
計算式:100,000円(売上)÷10円(ワンクリック)÷2% = 500,000(PV)

それに対してECサイトの場合は、平均顧客単価が6,000円で粗利率が40%で購入へのコンバージョン率が1%で平均閲覧PVが7PVだったとした場合は、約3万PVで大丈夫なのです。
計算式:100,000円 (粗利益)÷(6,000円×0.4)÷ 1% × 7PV = 29,166…..(PV)

あくまで、この数値はザックリとした一般的な数値を想定したものです。コンテンツサイトの状況や、ECサイトの取扱商品などによって大きく変わるのですが、一般的な感覚では大きなズレはないと思います。ということは、ECサイトの場合はアクセス数に耐えうるサイトよりも、カート処理が同時に沢山できるサイトが非常に大事な要素になります。そういう点でもKUSANAGI は十分な処理能力を持っています。

手動でもスケール(メモリなどの増減)が出来ればとりあえず大丈夫かな?

これは、アクセスの集中という問題です。ECサイトである話なのですが、福袋やセールのシーズンにはアクセスが集中してサーバーがダウンする事があります。ただ、常にアクセスを集中するかもしれない状態に備えていてはサーバーの運用コストが高くなってしまいます。ですので、売上が上がる時期だけサーバースペックを上げることが出来るサーバーであれば、サーバーの移行などをしなくてもスムーズにサイト運営することが出来ますので、メモリなどを増減できるパブリッククラウド系のサーバーを選べば非常に便利です。
もちろん、アクセス数などを判別して自動的にスペックを増減できるシステムも便利は便利ですが、運営者がサイト状況を把握しながらすれば、良いという点ではとりあえず増減処理がリアルタイムに出来ればそれでいいかな?と思います。

単純なアクセス集中シーズンに限らず、ECサイトというのはリピータ客を囲い込み売上を上げていく形を目指すことが多いので、中長期的にもサーバースペックを上げていくことが多いです。この場合もクラウド上でメモリなどをアップグレードしていくことが出来れば、サーバーの移転コスト等を考える必要がなくなります。

最後にECは継続運用できるシステムや環境が必要

そして、最後にKUSANAGIが EC サイトにとって良いと思われる理由の一つは、KUSANAGIはオープンソースライセンスです。ちょっと不謹慎な事を言いますが、万が一プライム・ストラテジー様が買収されたり方向転換をされたとしても、ユーザーが多ければオープンソースライセンスは多くのコントリビューターによって、大抵生き残ります。現在、ユーザーが増えている現状のKUSANAGIを見る限り、サービスの継続性はかなり高いのではないかと思います。

また、同様の理由で世界の30%のシェアのあるWordPress上で動き、ECサイトの30% を占め、Automattic が運営している WooCommerce は継続性の可能性が非常に高いので、是非ともECサイトを検討される場合は、WooCommerce 及び KUSANAGI のセットをご検討ください。

ちなみに、KUSANAGIとWooCommerceの関係は良いですよという記事はこちらを参考に。

KUSANAGIでWooCommerceを使ってみよう!

と自分の関連するサービスを結びつけて、お後がよろしいようで。爆

最後に:私の経験上、サーバーやサービスは一概にこれが良いということは無いです。サイト及びサービス運営者の状況や条件・環境によって変わりますので、あくまで参考意見としてこの記事を御覧ください。

WooCommerce って何?基本中の基本の話。

WooCommerce って何?基本中の基本の話。

最近、ぱったりとブログを更新しておりませんでしたが、Advent Calendarと言うものがありまして、WooCommerce Advent Calendar 2016も作って頂いたので、でははじめの一歩ということで、私が書くことに致しました。

えっと、まだまだ空きがあるので、WooCommerceを使ったことのある方は是非参加してみてください。否定的な意見でも大歓迎です。皆さんのご意見を聞いてみたいという感じです。

まずは、WooCommerce の基本ですね。WordPress 上で動く EC プラグインです。今、世界で一番使われている EC システムになります。WordPressとほぼ同じく、世界のECサイトの30%がWooCommerce で動いているという状態です。

ですので、基本の基本ですが、WordPressが動かないとWooCommerceは動きません。また、WooCommerceはECの基本部分だけを持っているので、ECとして凝ったこと、例えばポイント機能などは拡張プラグインとしてWooCommerceで使えるプラグインを利用して、機能を増やしていくという形です。これは、WooCommerceの基本のキホンです。

さてさて、今日は私の知る限りの WooCommerce の日本対応の歴史といいますか、そういう話と今の日本や世界での WooCommerce の状況を書かせて頂ければと思います。

そうですね、私が初めて WooCommerce を知ったのが、2012年の冬だったと思います。確か、11月とか12月とか。
その当時は、EC システムの EC cube や Zen Cart、CS cart 等をメインカスタマイズのお仕事などをしておりまして、コンテンツは WordPress か MT でみたいな感じだったんですよね。MTよりも個人的にWordPressのコードのほうが好みだったので、WordPressメインで、ECに関しては、やはりEC cubeの需要が多かったので、EC cubeのカスタマイズをメインに、個人的に好きなCS Cartを色々といじっていたという感じでした。Magentoも日本では出始めてちょろっと触っていた感じです。
そんな時にふと「WordPressでECサイトって出来ないんですか?」と質問されたんです。最初は「いやいや、出来ないでしょう。テーブル構成とか難しいし。。。いや、待てよ、metaがあるし、自由度高いから出来なくもないか。」と考えていて WordPress.org で検索して出てきたので、 WooCommerce だったんです。
実は、私が検索した時は WP-eCommerce と WooCommerce がある程度のダウンロード数を誇っていたので、まずはこの二つのコードなどを見てみました。個人的にhookが明らかに多かったのが WooCommerce だったのと、テーマを基本作っていたっぽい WooThemes という会社の開発だったので、今からの EC はコンテンツやデザイン、ひいては UI や UX がメインになると思っていたので、これは伸びるのではないかと思って、開発者の一人の Mike にメールして、「2.1から国際化対応をしっかりするとRoadmapに書いているから日本語化の部分の手伝いをしていいかな?」と書いたら、「いいよいいよ~」てな感じで Mike Jolley から返事が来まして、「じゃあ、やってみるね」と言って、すこ~しずつ、翻訳を進めるとともに、日本独自の住所の表示順番なども含めてコアとプラグインとの両方で協議しながら、進めていき、ほとんどの部分はプラグインで追加することになり、プラグインが追加しやすいようにhookを準備したり、要素を増やしたりなどを行いました。

んで、WordCampSF 2013に参加したんです。娘連れて、サンフランシスコ行って、娘はバス観光でヨセミテ国立公園などに行かせて、私はWordCampに参加する的な。で、衝撃でしたね。自動セキュリティーパッチのアップデート機能を付けると宣言して、APIを増やしていき、BlogやCMSの観念から開放されたソフトウェアにすると Matt が言っておりまして。んで、お昼ごはんを食べた後にMattが一人で居るのを発見して、いつもの下手くそ英語で話しかけて、ECプラグインなどはどう考えているのか?と聞いたら、「もちろん、中核のシステムとして動いてくれたら良いと思っている」という言葉をもらって、「よっしゃ!WooCommerceの日本対応を今進めているからオイラは頑張るよ!」と伝えて、握手して写真撮ってミーハーに帰ったという。
ちなみにその時に「Naokoって知っているか?日本でWordPressを頑張ってくれているんだよ」と言われたのですが、その当時私はTokyoのコミュニティーには全然顔を出していなかったので、「ん?誰?」と言う感じだったのは、ナ・イ・ショです。

そして、2.1をリリースしたのが2014年2月頃だったと思います。

それから少し遅れること4月頃に WooCommerce for Japan のプラグインを出した感じです。

そして、7月に複数の日本対応の決済プラグインを作成して、 WordPress.org で配布して10月のWordCampTokyo2014 に自腹で WooCommerce のブースを出して、復旧に努めた感じですね。確か、この時 WooCommerce for Japan のダウンロード数は100ぐらいだったかと。

そんで、初のWooConf をサンフランシスコでやるということで、日本翻訳者として参加せねばと、頑張って参加したんですね。まあ、小・中学校の同級生に会いに行きたかったというのもあったりするんですけどね。

ここまでは、ほぼ自腹。1円も儲けられなかったんすよね。マジで。

この時期までは WordPress のテーマやカスタマイズの仕事をしたり、EC cube や CS-Cart のカスタマイズの仕事をしつつやっていたんですよ。

まあ、オープンソースだし、GPLだし、まあ良いかと思いながらやっていた所に、Automatticに買収されるというビッグウェーブが2015年の5月に!

それからは、あれよあれよと、 WooCommerce にほぼ絞り込んでのお仕事が出来るようになったと。まあ、フルボディー3Dスキャナのビジネスもやっているので、こちらの仕事もしていますが、全然先行投資中なので、ほぼ無給でして、今は WooCommerce で生活が出来ている感じです。

今年は3Dの仕事などもあったので、2回目のWooConfはオンラインでの参加になりましたが、色々なdeveloperとお友達になれて、WooCommerce を盛り上げていきたいなと。世界的にも日本的にも。

WooCommerceをキーにして、日本のサービスを世界規模にスケールすることなどを考えて今も進めておりますが、ちょっと多くの方に納期などでご迷惑をおかけしているのですが、頑張ってやらないといけないなと思いながら11月末に39度の熱がある状態でこのブログを書いているのは、ナ・イ・ショです。笑

ちなみに今は、 WooCommerce for Japanのアクティブインストール数があと少しで2,000になります。今年のクリスマスプレゼントに2,000アクティブインストールになれば良いなと、こっそり思っている明石鳥羽のPTA会長兼まちづくり協議会副会長でした。

それでは、明日はなんと!あの!WordPressセミナートップ講師であり、複数の著書を書いている星野さんが書いてくれるそうです!星野さんは先日WooCommerceの販売サイトを構築されたので、構築した際の色々な話が聞けるのではないかと?あれ?サイトはどこだ?分からない。爆

乞うご期待!では!

 

WooCommerceの定期購入のAction hook -その1-

WooCommerceの定期購入のAction hook -その1-

定期購入のプラグインを色々と開発しているので備忘録がてら、こちらで公式サイトの内容を翻訳します。定期購入のプラグインを作ろうと思っている健気な方はご参考にいただければと思います。爆

結構大変です。ちなみに、一般的な決済に関する部分は2016年5月現在では頑張って下さい。私が将来余裕が出て作ることが出来たら説明ページを作るかもしれませんが、今の所作る予定がないので。

では、以下のページの翻訳(誤訳があったらゴメンなさい)です。

Subscriptions Action Reference

アクションフック名 : ‘scheduled_subscription_payment’

フック説明 : 定期決済が定期的に行われる際に必要です。例えば、毎年50ドルの定期購入の場合、このフックは1年に1回、最初の購入した時に実行されます。的購入のsubscription_key と user_id は、このアクションにフック関数を通して渡されます。


アクションフック名 : ‘scheduled_subscription_payment_{$gateway_id}’

フック説明 : ‘scheduled_subscription_payment’アクションのように定期購入の支払が行われる度に実行されます。違いはこれは決済方法ごとに対応を変えることができるということです。渡されるパラメーターも変わります。subscription_key と user_id の代わりに、$amount_to_chargeで支払総額(様々な商品代以外の価格を含んで)を渡し、購入された定期購入はWC_Order オブジェクトに含まれ、 WC_Product のIDが定期購入商品です。


アクションフック名 : ‘scheduled_subscription_expiration’

フック説明 : WP-Cron の処理が実行され、定期購入の期限が切れる場合に実行されます。 定期購入の subscription_key と user_id がこのアクションにフック関数を通して渡されます。


アクションフック名 : ‘woocommerce_subscriptions_activated’

フック説明 : WordPressのサイトで WooCommerce Subscription plugin が有効化された時に一度だけ実施されます。


アクションフック名 : ‘woocommerce_subscriptions_deactivated’

フック説明 : WooCommerce Subscription plugin が無効化された時に一度だけ実施されます。


アクションフック名 : ‘woocommerce_subscriptions_product_options_pricing’

フック説明 : 管理者ページで商品価格オプションが編集された時に実行されます。


アクションフック名 : ‘activated_subscription’

パラメーター :
$user_id Integer 定期購入が有効になった人のユーザーID。
$subscription_key String ユーザーアカウント上で有効になった定期購入のキー。

フック説明 : $subscription_keyで特定され、$user_idで有効であると特定された定期購入に関してこのアクションはトリガされます。


アクションフック名 : ‘cancelled_subscription’
パラメーター :
$user_id Integer 定期購入がキャンセルされた人のユーザーID
$subscription_key String 定期購入がキャンセルされた定期購入キー

フック説明 : 定期購入が管理者によってキャンセルされたり、決済システム側でキャンセルされたり、ユーザーアカウント上でキャン申された時に実行されます。


アクションフック名 : ‘subscription_end_of_prepaid_term’

パラメーター :
$user_id Integer 定期購入がキャンセルされた人のユーザーID
$subscription_key String 定期購入がキャンセルされた定期購入キー

フック説明 : 定期購入がキャンされるされた後に、現在稼働している定期購入が終了する時に実行されます。例えば、毎月更新の定期購入を3月1日に購入していた人が、3月15日にキャンセルするとその時に’cancelled_subscription’が実行され、購入完了している定期購入が終わる4月1日に’subscription_end_of_prepaid_term’が実行されます。バーチャルな商品、例えば会員費用などを定期購入で利用されている場合は’cancelled_subscription’フックよりも、このフックを使ったほうがいいです。’subscription_end_of_prepaid_term’フックは内部的にキャンセルの際のユーザーの権限を変更に使われています。


アクションフック名 : ‘subscription_expired’

パラメーター :
$user_id Integer 定期購入の有効期限が切れているユーザーID
$subscription_key String ユーザーアカウントでの有効期限が切れている定期購入キー

フック説明 : 定期購入を購入した時に設定されている期間が満了した時に実行されます。このイベントはWooCommerce Subscriptionsがcron-jobによって有効期限が切れているそれぞれの定期購入に対して、また決済プラグインによってWC_Subscriptions_Manager::expire_subscription()関数から直接実行されます。


アクションフック名 : ‘subscription_put_on-hold’

パラメーター :
$user_id Integer 定期購入の所有者のユーザーID
$subscription_key String 保留にされた定期購入のキー。

フック説明 : 定期購入が保留(一時停止)された時に実行されます。定期購入が捕虫される時とは以下です。

店舗管理者が手動で定期購入を一時停止した時。
購入者がアカウントページで手動で定期購入を一時停止にした時。
(定期購入が自動更新で一時停止になった際に、次に手動で支払いが行われるまで一時停止することもあります。詳細は定期購入の更新ガイドをごらんください。)