【近日公開】EC-CUBE４系 プラグイン ココから選択

systemkdです。

（新作プラグインを近日公開予定と書いた続きです）

少しずつ情報をまとめようと思ってたのですが、投稿を分けるとわけが分からなくなる気がするので、この投稿を育てる（？）ことにします ^^;

ということで、新作プラグインのおさらいから順に。

過去最大のプラグイン（当社比）

今回のプラグインは、私が今まで作成したプラグインの中で最大サイズのプラグインとなります。

今までは、タイムセール機能を追加することができる、「タイムセールPro+」が１位

ついで、ポイント機能の拡張が行える「ポイント機能拡張」が２位

そして、「まとめ買い価格設定」が３位

（開発期間的には、２位と３位が逆転するかな）

だったのですが、超えてきました。

と言っても、サイズも開発期間も機能には関係ないので それは置いといて ^^;

プラグインの名前は 「ココから選択」 プラグイン

プラグインの名称は、「ココから選択」プラグインで、ココから選択して購入ができるプラグインになっている

プラグインの機能は、EC-CUBE４系へ「新しい販売方法を追加する」プラグインとなります。

新しい販売方法を追加ってどういうこととなりますが、それはロゴを見れば分かるかな、

ということでロゴ画像は、これです！







ロゴに機能の概要が書かれていて、分かりやすいですよね　^^;

選べるセット販売　が行えるようになるプラグイン

そうです。EC-CUBEで、選べるセット販売が行えるようになるプラグインです。

セット販売はいくつかプラグインがあるかと思いますが、選べるやつは無いと思います。

（私の検索ワードが悪いだけの可能性もありますが・・・^^;

詳細な機能・できることについは、また次回。

EC-CUBE４系向けプラグイン まとめ買い価格設定プラグイン

systemkdです。

まとめ買い価格設定プラグインの紹介です。

EC-CUBE３系向けにも作成していましたが、４系向けにも作成しています。

まとめ買い価格設定プラグイン

その名の通り、通常の商品価格とは別に、まとめて購入を行った場合の価格を設定できるようになるプラグインです。





具体的には、 商品を５点・１０点・２０点などまとめて購入を行ってもらえる場合に、販売価格を値引きした状態にすることができるプラグインとなります。

まとめ買い価格の設定は、SKU単位で行えるようになっており、お得感をアピールするための表示も行うことができるようになっています。

まとめ買い価格の設定

まとめ買い価格の設定は、管理画面の商品管理から行えるようになっており、

設定できる項目は、「まとめ買いの数量に対する価格」だけでなく「割引率」も設定できるようになっています。

[規格なし商品]



[規格あり商品]

まとめ買い価格は、数量ごとに複数設定できるようになっています。

これにより、３点まとめて購入であれば 100円引き、5点まとめて購入であれば 150円引きといった設定を行うこともできます。

まとめ買い設定商品の購入について

まとめ買い価格設定を行った商品の購入は通常の商品購入と変わらない流れで行うことができます。


まとめ買い価格が設定された商品の詳細ページを表示した際、自動で「数量」ごとの「単価（税込）」が表示されるようになっています。

３系の同プラグインにはなかったのですが、４系では販促的な部分も考え表示されるようになっています。




また、カート内でも「まとめ買い値引き」によってどのくらいお得になっているかが分かるようになっています。


ちなみに、上記表示が不要だと思う場合は、プラグインの設定よりOFFにすることもできるようになっています。



なお、まとめ買いでの値引き情報は、注文情報としては「値引き」として扱われるようになっております。

まとめ買いの表示は、購入の動線だけではなく、もちろんマイページの注文履歴にも表示ｓれるようになっています。

直接値引きモードも搭載

先程、まとめ買いでの値引き情報は、注文情報としては「値引き」として扱われると記載しましたが、値引き方式を切り替えることにより、直接値引きモードを利用することも可能です。





直越値引きモードでは、「販売価格 - 値引き」という形ではなく、販売価格を値引いた状態で動作します。

まとめ

EC-CUBE４系で、まとめ買い値引きによる販売が行えるようになるプラグイン

「まとめ買い価格設定」プラグイン

有料プラグインとなっていますが、ショップでボリュームディスカウントを導入したいという方は是非ご確認頂ければと思います。

不明点・気になる部分等ありましたら、お気軽にメールください。

なお、まとめ買い価格設定プラグインと合わせ使うと相乗効果を発揮するプラグインもありますので、それは次回紹介させて頂きたいと思います。

近日EC-CUBE４系の新作プラグインを公開予定

systemkdです。

ほぼ更新とまってます。はい。

まぁ、プラグインに全力投球しているということで m(_ _)m

ということで作ったプラグインの宣伝です。

（完全に更新とまるよりは良いはず！！）

新作プラグインまもなく公開

タイトルの通り近日中にEC-CUBE４系向けの新作プラグインを公開します！

既にストアへの申請は終わっているので、何事もなければ２週間程度で公開できるかと思います。

今回のプラグインは、私が今まで作成したプラグインの中でぶっちぎりで最大（容量）のプラグインになります。

それはそれは壮大なプラグインです！？ ^^;

プラグインの名前は？

プラグインの名前は、「ココから選択」です。

そう、ココから選択して購入することができるプラグインです。

（って何それ。。）

結局どんなプラグインなの？

結局どんなプラグインかというと、

EC-CUBE４系へ「新しい販売方法を追加するプラグイン」です！

公開できるまでもう少し日にちがあるので、詳細は次回へ

EC-CUBE4系 オーナーズストアからインストールしたプラグインの独自アップデートを行う

SYSTEM_KDです。

久々のブログ更新です。

今回は、誰向けなのか不明な、EC-CUBE４系でオーナーズストアからインストールしたプラグインを独自アップデートを行う方法です。

オーナーズストアからインストールしたプラグインのアップデートは簡単には行えない

オーナーズストアからプラグインのインストールを行うと、基本的にはプラグインのアップデートはオーナーズストア経由でしか行なえません。

特に問題はないのですが、バグってて今すぐ修正できるパッチを用意しておきたい場合や、独自のカスタマイズを適用したいと言う場合には、差分ファイルを手動適用するということでしか対応できません。

（もしや、ec-cube.coは手動適用もできないんじゃないかな・・）


EC-CUBE3系までのプラグインは、オーナーズストアのマイページからダウンロードできるので、独自プラグインとしてインストールすれば、そっち側でアップデートが可能。　ってそんな使い方はやらないですかね。


まぁ、そんなこんなで４系はアップデートしたいときの回避策がないという不安を解消するために、アップデートする策を考えました。

その策とは・・・

独自プラグインをインストールし、そのプラグインでオーナーズストアからインストールしたプラグインをアップデート

ドン！（大した策じゃない


４系でも、独自プラグインのインストールできるので、そっち側から「オーナーズストアのプラグイン」の方を更新してしまうという作戦です。


と言っても、既にオーナーズストアでインストールされているものを、独自プラグインでインストールしようとしても、それは行えません。


流れとしては、アップデートしたいプラグインの、アップデート後のプラグイン（tar.gz）を含めたプラグインを、独自プラグインとして用意。
そのプラグインをインストールし、有効化する際の処理で、（保持しているプラグインファイルを用いて）独自アップデートしてしまうというものです。

（説明下手くそ）


まぁ、こんなイメージ。

で、コードの方は、

namespace Plugin\PlgPatch; // 環境に合わせて変更


use Eccube\Entity\Plugin;
use Eccube\Exception\PluginException;
use Eccube\Plugin\AbstractPluginManager;
use Eccube\Repository\PluginRepository;
use Eccube\Service\PluginService;
use Eccube\Util\CacheUtil;
use Eccube\Util\StringUtil;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Symfony\Component\Filesystem\Filesystem;
use Symfony\Component\Finder\Finder;

class PluginManager extends AbstractPluginManager
{

    /** @var PluginRepository */
    protected $pluginRepository;

    /** @var CacheUtil */
    protected $cacheUtil;

    /** @var PluginService */
    protected $pluginService;

    private $upFileName;

    private $plgCode;

    private const PLG_PATH = __DIR__ . '/Resource/upfile/';

    /**
     * @param array $meta
     * @param ContainerInterface $container
     * @throws PluginException
     */
    public function enable(array $meta, ContainerInterface $container)
    {

        log_info('[PlgPatch]パッチ適用開始');

        $this->initialize($container);

        log_info('[PlgPatch]更新対象プラグインの存在チェック開始');

        $Plugin = $this->getPlugin();

        log_info('[PlgPatch]更新対象プラグインの存在チェック終了');

        // プラグインの手動アップデート
        $this->plgManualUpdate($Plugin);

        log_info('[PlgPatch]パッチ適用完了');
    }

    /**
     * @param ContainerInterface $container
     */
    private function initialize(ContainerInterface $container)
    {
        $this->pluginRepository = $container->get(PluginRepository::class);
        $this->cacheUtil = $container->get(CacheUtil::class);
        $this->pluginService = $container->get(PluginService::class);

        $finder = Finder::create()
            ->in(self::PLG_PATH)
            ->files();

        /** @var \SplFileInfo $item */
        foreach ($finder as $item) {
            $this->upFileName = $item->getFilename();

            $fileName = explode(".", $item->getFilename());
            $this->plgCode = $fileName[0];
        }
    }

    /**
     * @param string $plgCode
     * @return Plugin
     * @throws PluginException
     */
    private function getPlugin($plgCode = "")
    {

        if (empty($plgCode)) {
            $plgCode = $this->plgCode;
        }

        /** @var Plugin $Plugin */
        $Plugin = $this->pluginRepository->findOneBy(['code' => $plgCode]);

        if (!$Plugin) {
            log_error("[PlgPatch]更新対象プラグインがインストールされていません。");
            throw new PluginException("[PlgPatch]更新対象プラグインがインストールされていません。");
        }

        return $Plugin;
    }

    /**
     * @param Plugin $Plugin
     * @param string $upFileName
     * @throws PluginException
     */
    private function plgManualUpdate(Plugin $Plugin, $upFileName = "")
    {

        $fs = new Filesystem();

        if ($upFileName == "") {
            $upFileName = $this->upFileName;
        }

        $upFilePath = self::PLG_PATH . $upFileName;

        /** @var CacheUtil $cacheUtil */
        $cacheUtil = $this->cacheUtil;

        /** @var PluginService $pluginService */
        $pluginService = $this->pluginService;

        // ファイル配置
        $tmpDir = null;
        try {
            $cacheUtil->clearCache();

            $tmpDir = $pluginService->createTempDir();
            $tmpFile = sha1(StringUtil::random(32)) . '.tar.gz';

            log_info('[PlgPatch]プラグインファイルコピー開始', [
                'origin' => $upFilePath,
                'target' => $tmpDir . '/' . $tmpFile,
            ]);

            $fs->copy($upFilePath, $tmpDir . '/' . $tmpFile, true);

            log_info('[PlgPatch]プラグインファイルコピー完了');

            log_info('[PlgPatch]Update', [$Plugin]);

            $pluginService->update($Plugin, $tmpDir . '/' . $tmpFile);

            log_info('[PlgPatch]一時ディレクトリから削除', [$tmpDir]);

            $fs->remove($tmpDir);

            log_info('[PlgPatch]一時ディレクトリから削除完了');

            return;

        } catch (PluginException $e) {
            if (!empty($tmpDir) && file_exists($tmpDir)) {
                $fs = new Filesystem();
                $fs->remove($tmpDir);
            }
            $message = $e->getMessage();
            log_error('[PlgPatch]' . $message);

            throw $e;
        } catch (\Exception $er) {
            // Catch composer install error | Other error
            if (!empty($tmpDir) && file_exists($tmpDir)) {
                $fs = new Filesystem();
                $fs->remove($tmpDir);
            }
            log_error('plugin install failed.', ['original-message' => $er->getMessage()]);
            throw $er;
        }
    }
}

主要部分を全部はっつけてみた。

（わりと多かった・・・githubにするべきだったか）



普通にプラグインを作成する要領で、composer.json を用意して、上記コードをPluginManager.phpとして配置。

Resource/upfile にアップデートを行いたいプラグインを[プラグインコード].tar.tz　のファイル名で配置すればOK.


独自プラグインとして、インストールした後、有効化を行うと Resource/upfile に格納したプラグインでアップデートされます。
（※複数は未対応）

注意点

上記で、そこそこ上手く更新できると思いますが、注意点がいくつかあります。

1. ファイルは上書きで配置される

もとのプラグインファイルに対して、更新用プラグインが上書きされます。
ファイルの置き換えのみであれば、問題ないのですがファイルを削除している場合は消えてくれないので注意。


2. スキーマがアップデートされない

次期バージョン(4.0.4）で解決されるはずですが、4.0.3までは独自プラグインのアップデートでは、スキーマ更新されないので、テーブルに変更を行った場合このアップデートだけでは反映されません。

残念・・・

といいつつ、これは対応策があります。

更新用に独自プラグインとしてインストールしたプラグインをアンインストールするだけです。

プラグインのアンインストールを実施すると、スキーマアップデートが流れてくれるので、その処理の巻き添え（良い意味で）でアップデートされます。

更新用プラグインは、アップデートが終わると必要ないですし、アンインストールまでが一連の更新処理ということで。


３．バージョンは変えない方が良い

アップデート対象のプラグインのバージョンを変えてしまうと、次のアップデートできちんとアップデートされない可能性があるので、アップデート対象プラグインのバージョン番号は変えずに、プラグイン名に、変更版である旨を追記するのが良いです。


以上。

Pluginで追加したEntityを別Pluginにて拡張

SYSTEM_KDです。




EC-CUBE4でのプラグイン開発時メモです。


EC-CUBE4系では、traitを用いてEntityを拡張できるようにEntityの拡張機構が用意されています。


※Entity拡張機構


これによって、プラグインから本体のEntityを拡張することができるのですが、プラグインで追加したEntityを別のプラグインから拡張しようとして、微妙にハマってしまったとメモになります。

プラグインで追加したEntityをプラグインで拡張

やり方としては、本体のEntityを拡張するときと同様。
アノテーションで適用するEntityを指定する際に、プラグインのEntityを指定するだけ。

/**  
 * Trait LabTrait 
 * @Eccube\EntityExtension("Plugin\TargetPlugin\Entity\TargetClass")  
 */
trait LabTrait  
{  
  public function getDummy()  
  {
    return "xxx";  
  }  
}

ただ、拡張される側のEntityを普通に用意しただけだと、Entity重複してるよと怒られるので、本体側のEntityと同じように、クラスが存在してるかチェックで囲むようにします。

※これを実施しておかないと、proxy生成は成功するけど生成されたファイルを削除しないと、それ以降どうしようもなくなってしまうので注意

if (!class_exists('\Plugin\TargetPlugin\Entity\TargetClass')) {
    /**
     * TargetClass
     *
     * [略]
     */
    class TargetClass extends \Eccube\Entity\AbstractEntity
    {
      ・・・
    }
}

これでOKっと思ったけど、ここがハマりポイントでした。

これだと、bin/console eccube:generate:proxies を実行した際にエラーが発生してしまいました。

プラグインのEntityは拡張できないのかなと思いつつ、EC-CUBEの拡張機構部分のコードを追ってみると、}の後に改行が欲しそうな雰囲気だったので、付け足してみたら解決しました。

（実は環境の問題とかって可能性もあるのかな・・・）

if (!class_exists('\Plugin\TargetPlugin\Entity\TargetClass')) {
    /**
     * TargetClass
     *
     * [略]
     */
    class TargetClass extends \Eccube\Entity\AbstractEntity
    {
      ・・・
    }
}
// ← 最後の空行部分

ということで、Pluginで追加したEntityを別Pluginにて拡張する際のメモでした。

EC-CUBE4でプラグインからのマイグレーションでEntityManager・Entityを使う方法

SYSTEM_KDです。


今回のブログから、StackEdit を利用してMarkdownで書いてみています。
（いや、何の宣言？


久々の投稿ですが、内容はEC-CUBE４でのマイグレーションについてです。


ほぼメモです。

EC-CUBE4でのプラグインからマイグレーション

EC-CUBE３では、プラグインでテーブルの拡張・データ追加を行う際はPluginMigrationで行いますが、
４系ではテーブルの拡張は「doctrine:schema:update」での拡張が推奨されてます。

（まぁ、プラグインからのテーブル拡張は、プラグイン機構部分が良しなにしてくれるのであまり気にしなくてOK）


データの追加を行う際も、PluginMigrationから行えます。

AbstractPluginManager を継承して enable() 関数にてinsertするなり、$container（ContainerInterface） からEntityManagerを利用するなりしてデータ追加が行えます。


ただ、この方法だと再度 enable()が操作した際にinsertしないようにチェックする必要があります。

プラグインをバージョンアップして、追加するデータが増えた際・既に追加しているデータを変更する際など、管理が面倒くさい。


振り返らずに、前に進みたいです。


ということで、３系と同様にマイグレーションファイルを用意して、追加するデータを管理したいと思います。


必要なファイル
（プラグイン用ディレクトリの中）

• PluginManager.php
• DoctrineMigrations/Version2019XXXXXXXXXX.php
  
  
  VersionXXXのファイルは、下記コマンドで生成
  （生成できたらプラグインの中に持ってくる）

bin/console doctrine:migrations:generate

PluginManager.php は、Eccube\Plugin\AbstractPluginManagerを継承する。

AbstractPluginManagerにある、migrationメソッドを呼べば３系の時みたいにバージョン管理しながらデータ追加が行える。


有効にした際にデータ追加したい場合

public function enable(array $meta, ContainerInterface $container)  
{  
    $this->migration($meta['code'], $container);
}

逆にアンインストールで削除する場合

public function uninstall(array $meta, ContainerInterface $container)  
{  
    $this->migration($meta['code'], $container, 0);  
}

あとは、マイグレーションファイル内の up() 関数で、`addSql`すれば良い。
※アンインストール時は、down()

（色々とサンプルが転がっているのでざっくりで　m(_ _)m


でも、これだとEntityManager使えない。Entityが使えない。。使いたい。。


で、本題のEntityManagerを使ってのマイグレーションです。

マイグレーションファイルで、ContainerAwareInterfaceをimplementsし、
use ContainerAwareTraitを差し込んであげれば、ContainerInterfaceを使えるようになると見せかけて、ならない。

bin/console doctrine:migrations:migrate

で、app/DoctrineMigrations にあるマイグレーションファイルは良い感じになりますが、プラグインの方はダメっぽい。

やり方が悪いだけだったりして・・・^^;


解決方法
Eccube\Plugin\AbstractPluginManagerのmigration 関数をベースにちょっと書き換えます。

PluginManager .php

class PluginManager extends AbstractPluginManager  
{
 /**  
  * @param array $meta  
  * @param ContainerInterface $container  
  * @throws MigrationException  
  */
 public function uninstall(array $meta, ContainerInterface $container)  
 {  
     $this->pluginMigration($meta, $container, 0);  
 }  
   
 /**  
  * * @param array $meta  
  * @param ContainerInterface $container  
  * @throws MigrationException  
  */
 public function enable(array $meta, ContainerInterface $container)  
 {  
     $this->pluginMigration($meta, $container);  
 }

 protected function pluginMigration(array $meta, ContainerInterface $container, $version = null)  
 {
     $migrationFilePath = __DIR__ . '/DoctrineMigrations';  
     $connection = $container->get('database_connection');  
   
     $pluginCode = $meta['code'];  
   
     $config = new Configuration($connection);  
     $config->setMigrationsNamespace('\Plugin\\' . $pluginCode . '\DoctrineMigrations');  
     $config->setMigrationsDirectory($migrationFilePath);  
     $config->registerMigrationsFromDirectory($migrationFilePath);  
     $config->setMigrationsTableName(self::MIGRATION_TABLE_PREFIX . $pluginCode);  
   
     /** @var Version $objVersion */  
     foreach ($config->getMigrations() as $objVersion) {  
         $versionMigration = $objVersion->getMigration();  

         if ($versionMigration instanceof ContainerAwareInterface) {  
             $versionMigration->setContainer($container);  
         }  
     }
   
     $migration = new Migration($config);  
     $migration->migrate($version, false);  
 }
}

間違え探しみたいな微妙な違いですが、、
キモとなる部分はこの部分になります。

ContainerInterfaceをVersionXXX側に渡してあげるようにします。

/** @var Version $objVersion */  
foreach ($config->getMigrations() as $objVersion) {  
    $versionMigration = $objVersion->getMigration();  

    if ($versionMigration instanceof ContainerAwareInterface) {  
        $versionMigration->setContainer($container);  
    }  
}

これで無事にマイグレーションをバージョン管理しながら、EntityManager・Entityを使うことができます。

final class VersionXXX extends AbstractMigration implements ContainerAwareInterface  
{
    use ContainerAwareTrait;

    public function up(Schema $schema): void  
    {  
        /** @var EntityManagerInterface $entityManager */  
        $entityManager = $this->container->get('doctrine.orm.entity_manager');  
   
        $ProductRepository = $entityManager->getRepository(Product::class);
    }  
   
    public function down(Schema $schema): void  
    {  
   
    }
}

まとめ

bin/console でマイグレーションする場合は、VersionXXXの方だけで良いけど、
EC-CUBE４のプラグインでマイグレーションする際は、PluginMigrationでContainerInterfaceを渡してあげる必要がある。

Azure (App Service) に EC-CUBE 4 をインストール

SYSTEM_KD です。

自分用のEC-CUBE3 デモ環境を Azure に構築していますが、EC-CUBE4系も欲しいなということで、今更ながらEC-CUBE4 のデモ環境を Azureに構築したいと思います。

ちなみに、なぜAzureかというと、「楽」で「便利」で「安い」からです。

App Service を利用すれば、マネージドな環境なのでサーバの設定を気にすることもなく楽。
SSL証明書も付いてる（もちろん独自ドメインでな無く、そもそもLet’s Encryptを使えば気にしなくても良いというのはありますが・・まぁ環境作ったら付いてるので便利）
安いのは、そのままです。無料で使えます。

App Service 作成

では、環境作成します。

Azure にアクセスして、左側のメニューから App Service を選択します。




App Service のページが表示されるので、「＋追加」から「Web Apps」を選択します。

作成をクリックして、「アプリ名」に好きな名称（ドメイン名になるので、他の人とかぶるとダメ）を指定。

リソースグループは「新規作成」を選択。（別に既存があるなら既存でも良い。自由に）

OS は「Windows」を選択（Linuxを選ぶと有料）

公開で、「コード」を選択。（Docker イメージは有料）

App Service プラン/選択で、新規作成から、場所は「Japan」で、プランは、「開発/テスト」の「F1」を選択。




（しばらく見ないうちに、UIめちゃめちゃ変わっている。。^^;　


「作成」で環境用意完了！！


App Service で先程作成したものを選択して、概要の「URL」をクリックすると、デフォページが表示されるかと思います。

EC-CUBE4 をインストール

環境が作成できましたので、インストール作業をすすめていきます。


ソースコードをアップしたいのですが、FTP経由でアップすると時間がかかるので、Git でアップしたいと思います。


メニューから、「デプロイセンター」を選択して、「Local Git」を選びます。
※ここらへんも前と変わっている・・・。


ひとまず、git clone します。


clone できたら、そこに EC-CUBE４のソースを配置して、コミットして、push します。


※ディレクトリを作成して、その中にソースを置くと Azure 側の「仮想アプリケーションとディレクトリ」の設定を調整する必要があるので、とくにディレクトリは作成せずそのままソースコードを配置


これで配置は完了。


さくっとインストール。


のはずが、微妙に罠がありました。


まず、web.config でエラーが発生してインストールが表示されない。

<add segment=”bin” />

を削除して対応。


ついでに、 git 管理から、 bin ディレクトリを除外。


app/Plugin ディレクトリが空で、git 管理から外れるため、.gitkeep を追加。

同じく、app/Customize/Controller と app/Customize/Entity にも、.gitkeep を追加


終わりと思いきや、まだあります。。

app/template/admin
app/template/default
app/template/user_data
app/proxyentity
app/PluginData
src/Eccube/Resource/doctrine/migration

にも同様に、.gitkeep 追加


再度 push して、インストールにトライ！


重い。。






ようやく、インストール画面。


DBは、MySQL In App を使います。


Azureのコンソールで、

D:\home\data\mysql
に移動すると


MYSQLCONNSTR_localdb.txt があるので、表示すると接続情報が書いてますので、DBへの接続情報はそれを利用します。





なんとか、インストール完了。


git 経由でアップしたことによって、色々とハマりましたが、４系用の検証環境ができました。


ただ、Azure 無料プランで無理やり動かすのは厳しいようで、最初の表示はかなり時間を必要とします。
（キャッシュが生成されれば、それなりには動きます）

Docker For Mac で Kubernetes を試してEC-CUBEを動かしてみる（その４）

SYSTEM_KDです。

その１、その２、その３　とやってきて、ようやくEC-CUBEをインストールするところにたどりつきました。

Kubernetes な環境に EC-CUBE3 をインストール

インストールに利用する EC-CUBEは 3.0.15 になります。

ここからは楽勝ですね。

いままで作ってきたものを全て起動させた状態にします。

WEBサーバー側で、マウントしているホストのディレクトリに、EC-CUBE3 のソースを配置します。

そして、ポート指定して localhostにアクセスすれば、ようこそページが表示されました。

流れにそって進んでいきます。

EC-CUBEをインストールするには、事前にDBを作成しておく必要があるので、GUI等にてアクセスを行って、事前に作成しておきます。

接続情報の設定

データベースの種類で、 MySQLを選択

データベースのホスト名に、mysql-server を設定

データベース名は、事前に作成したもの

ユーザ名は root

パスワードは 「その２」の先に作成したものです。

・・・　インストール中　・・・

無事インストールできました！！

PODを増やして 複数台っぽくしてみる

EC-CUBE３のインストールに成功しましたので、Kubernetes っぽく PODの数を増やしてみたいと思います。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mycentos7
  labels:
    app: mycentos7
spec:
  replicas: 2
  selector:
    matchLabels:
      app: mycentos7
  template:
    metadata:
      labels:
        app: mycentos7
    spec:
      containers:
      - name: mycentos7
        image: localhost:5000/web/mycentos7:2
        ports:
        - containerPort: 80
        volumeMounts:
        - mountPath: /var/www
          name: docroot
      volumes:
      - name: docroot
        persistentVolumeClaim:
          claimName: centos7-volume-claims

replicas を 指定してあげることにより、PODを増やすことができます。

デプロイします。

kubectl apply -f centos7.yml

確認してみます。

NAME                            READY     STATUS    RESTARTS   AGE
mycentos7-884464574-m5952       1/1       Running   0          58s
mycentos7-884464574-qb99x       1/1       Running   0          14h
mysql-server-5b9788cc57-2wvmq   1/1       Running   0          18h

増えました。

どっちの POD も Volume が共通で、ホストのものをみているので、複数台状態でも一応動きました。

（※EC-CUBEは複数台構成で動くことが想定されていません）

速度てきな問題への対応

ここまで動かしてみると重大な問題があることがわかりました。


それは、動作が遅いということです。

Docker For Mac でホスト側をマウントして普通に動かした場合も同様に遅いので、ある程度は想定しておりましたが、やはり遅いみたいです。


ぱっと思いつく問題点は、Volume 周りかなと思いますので、確認していみたいと思います。

Docker Image にパックしてみる

ソースコード全体についてホスト側をマウントしているようにしていましたが、イメージ内にパックしてみます


完全に全体をイメージに入れてしまうと、ログとかキャッシュ用にファイルを作成する部分がエラーになるので、app の配下だけはホスト側のディレクトリをマウントするようにしました。

結果は、

ソースコード全体をマウントした場合
TOP画面　・・・　平均 5.15秒
商品一覧　・・・　平均 4.86秒

一部のみマウントした状態
TOP画面　・・・　平均 1.34秒
商品一覧　・・・　平均 1.04秒


早くなりました！

ファイルが分かれて個別に作成するのが面倒な問題に対応

設定ファイルを個別に作成してきましたが、個別に create するのが面倒になってきましたので、１ファイルにまとめたいと思います。

と言ってもまとめるのは簡単です。

それぞれの設定ファイルを一箇所に集めて、「---」で区切るだけです。

（ついでに全体、ソースをはる）

# Volume
apiVersion: v1
kind: PersistentVolume
metadata:
  name: centos7-volume
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: centos7-storage
  hostPath:
    path: /ホスト側フルパス

---
# Volume Caims
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: centos7-volume-claims
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: centos7-storage

---
# deploy
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mycentos7
  labels:
    app: mycentos7
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mycentos7
  template:
    metadata:
      labels:
        app: mycentos7
    spec:
      containers:
      - name: mycentos7
        image: localhost:5000/web/mycentos7:3
        ports:
        - containerPort: 80
        volumeMounts:
        - mountPath: /var/www/app
          name: docroot
      volumes:
      - name: docroot
        persistentVolumeClaim:
          claimName: centos7-volume-claims

---
# Service
apiVersion: v1
kind: Service
metadata:
  name: mycentos7
  labels:
    app: mycentos7
spec:
  ports:
    - port: 80
      nodePort: 31000
  selector:
    app: mycentos7
  type: NodePort

毎回アクセスするポートが変わるのも面倒だったので、こっそり固定にしてます。
ついでに、MySQLの方もはっておきます

# Secret
apiVersion: v1
kind: Secret
metadata:
  name: mysql-pass
type: Opaque
data:
  password: XXXXX # echo -n "pass" | base64  # base64した値を設定

---
# Volume
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-volume
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: mysql-storage
  hostPath:
    path: /ホスト側のフルパス

---
# Volume Claims
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-volume-claims
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: mysql-storage

---
# Deploy
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql-server
  labels:
    app: mysql-server
spec:
  selector:
    matchLabels:
      app: mysql-server
  template:
    metadata:
      labels:
        app: mysql-server
    spec:
      containers:
      - name: mysql-server
        image: mysql:5.6
        ports:
        - containerPort: 3306
        volumeMounts:
        - mountPath: /var/lib/mysql
          name: mysql-storage
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
      volumes:
      - name: mysql-storage
        persistentVolumeClaim:
          claimName: mysql-volume-claims

---
# Service 外部用
apiVersion: v1
kind: Service
metadata:
  name: mysql-server-open
  labels:
    app: mysql-server
spec:
  ports:
    - port: 3306
      nodePort: 31001
  selector:
    app: mysql-server 
  type: NodePort

---
#Service 内部用
apiVersion: v1
kind: Service
metadata:
  name: mysql-server
  labels:
    app: mysql-server
spec:
  ports:
    - port: 3306
  selector:
    app: mysql-server
  clusterIP: None

Secret 部分のパスワードは、パスワードをbase64した値を設定します。

ということで、 Docker For Mac で Kubernetesを試しながらEC-CUBEをインストールするところまでできました。


よくわからないまま進んできましたが、Kubernetes の情報がのっているページ（GKEのドキュメントとか）の内容がなんとなく理解できるようになったのは収穫だったかなとおもっています。


その４は切りが悪いので、その５を書こうかなと思いつつ、以上、Docker For Mac で Kubernetes を試してEC-CUBEを動かしてみる（その４）でした。

EC-CUBE3向けプラグイン 条件でつくれるカテゴリ をリリース

SYSTEM_KD です。

前回のプラグインを公開してから、かなり時間がたってしまいましたが、

久々の　新作プラグイン　「条件でつくれるカテゴリ」　プラグインをリリースしました。

条件でつくるカテゴリ

今回のプラグインは、どんなプラグインかと言いますと、プラグイン名の通り

条件を利用してカテゴリをつくるれプラグインとなります。

具体的にどういうことかというと、カテゴリに対して　カテゴリ内に表示する商品を取得するための条件を設定して、その条件にもとづいて自動でカテゴリへ商品を振り分けることができるプラグインとなっています。

通常であれば、カテゴリに属する商品は手動にて選択を行うため、新たに商品が追加された場合・属するカテゴリを変更したい場合などにおいて、都度設定を行う手間が発生します。

また、商品の在庫状態に応じたカテゴリなど、動的に変化するものによるカテゴリを作成することは難しい状態となります。

ですが、このプラグインを利用すれば、条件にマッチさせることにより、自動で振り分けを行う動的なカテゴリを用意することができます。

様々な条件設定

カテゴリを作成するために様々な条件を利用することができます。

条件は組み合わせて利用することができるので、色々なパターンでカテゴリを用意することができます。

「商品ID (From)」「商品ID (To)」

商品IDの範囲で指定
Fromのみ、Toのみの指定も可能です。

「商品名」

商品名の前方・部分・後方一致で指定
商品名を利用してグループ化したカテゴリを用意したい場合に利用できます。

「商品コード」

商品コードの前方・部分・後方一致で指定
ルールに基づいて商品コードを付与している場合など、商品コードを利用して商品の種類ごとにグループ化したカテゴリを用意した場合に利用できます。

「商品種別」

商品種別で指定
商品種別を OR 条件にて指定することができます。

「販売価格 (From)」「販売価格 (To)」

販売価格の範囲で指定
Fromのみ、Toのみの指定も可能です。

販売価格を利用して、◯円以上・✕円以下・◯円 ～ ✕円 といった、販売価格をもとにしたカテゴリを用意したい場合にご利用できます。

「通常価格 (From)」「通常価格 (To)」

通常価格の範囲で指定
Fromのみ、Toのみの指定も可能です。

販売価格ではなく、通常価格をもとにしたカテゴリを用意したい場合にご利用できます。

「在庫 (無制限)」「在庫 (From)」「在庫 (To)」

在庫の状態で指定
在庫無制限のもの・在庫Fromのみ、Toのみ、範囲で指定可能です。

在庫が少なくなってきたものをまとめ、「残りわずか」「ラスト１点」といった内容が動的に変化するカテゴリを簡単に用意できます。

「タグ」

タグで指定
タグを OR 条件にて指定することができます。

新商品のタグが付いた商品を集めたカテゴリを用意することができます。

「販売制限数 (From)」「販売制限数 (To)」

販売制限数で指定
Fromのみ、Toのみの指定も可能です。

一度に購入できる条件である、販売数を利用したカテゴリを用意することができます。

「お届け可能日」

お届け可能日で指定
お届け日単位でまとめたカテゴリを用意することができます。

条件カテゴリの組み合わせ

条件を利用したカテゴリは、条件通しの組み合わせだけではなく カテゴリ階層 にて組み合わせることが可能です。

条件を利用したカテゴリは、親カテゴリからの条件を引き継ぐようになっているため、下の階層に進むごとに条件によって絞り込みを行っていくことができます。

条件付きカテゴリの親カテゴリが通常のカテゴリ（商品とカテゴリを手動にて結びつける状態）の場合でも同様に親カテゴリの条件（選択した商品）を引き継ぎます。

このため、全ての商品から条件で絞り込むだけでなく、手動で選択した商品からさらに条件にて絞り込むといったことができます。

また、これとは逆に、あるカテゴリの下に条件を付けたカテゴリを配置し、その親カテゴリで抽出される商品は、紐づくカテゴリにて抽出されたものを表示したいという場合があるかと思います。

こういった場合は、親カテゴリを 条件カテゴリ に設定しておき、何も条件を指定しないことにより実現することができるようになっています。

なお、この様に条件を利用したカテゴリは親の条件を引き継ぐ仕組み上、条件の下に紐づくカテゴリは、条件カテゴリでないといけない縛りとなっております。

（自動で条件カテゴリを選択した状態となるので、利用する上で意識することは特にないかと思います）

親カテゴリの選択

メインの機能としては、上記となるのですが、サブ機能としてカテゴリを登録する際に、親カテゴリを選択できる機能があります。

通常、カテゴリを作成した後でのカテゴリの階層変更は容易ではありません。

（一度削除して登録し直す、CSVで再登録、データベースを直接変更などが必要）

せっかく条件を指定したカテゴリを用意しても、階層を間違えてしまいやり直しというのは、面白くありません。

このため、当プラグインには、カテゴリの登録（更新）の際に、親カテゴリを選択できるようになっているため、後からカテゴリの階層を変更することができます。

管理画面での検索

条件を利用したカテゴリについて、主にフロント側についての機能を説明しましたが、管理画面側についても同様に条件を利用したカテゴリでの検索を行うことができます。

また、検索結果のCSV出力についても、同様に条件を利用したカテゴリを反映した結果の出力が行えるようになっております。

（ただし、CSVダウンロード機能は拡張しにくいため、カテゴリ条件版というのを別途用意しております）

まとめ

ということで、久々の新作プラグイン　条件でつくれる　プラグインをリリースしましたので、魅力ある商品を、もっと有効的にカテゴライズしてお客様にみせたいといった方は、是非利用してみてください。

EC-CUBE3 向け プラグイン 条件でつくれるカテゴリ

以上、プラグインのご紹介でした。

EC-CUBEの公式メルマガでプラグインを取り上げて頂きました

SYSTEM_KDです。

 

タイトルままですが、株式会社ロックオンさんが発行しているEC-CUBEの公式メールマガジンにて、私が作成したプラグインを紹介頂きましたー！！

 

 

おーーーー！！ありがとうございます！！

 

EC-CUBE 3.0 プラグイン

2016年08月09日に発行されました、「EC-CUBE 3.0注目プラグインをご紹介!【管理機能編】」という公式メールマガジンにて、「管理サポートプラグイン【詳しい商品一覧】」、「会員データ移行プラグイン for EC-CUBE３」と「メンテンナスプラグイン」の計３プラグインが紹介されました。

 

そのうち、「管理サポートプラグイン【詳しい商品一覧】」と「メンテナンスプラグイン」は私が作成したプラグインになります。

（紹介３個中２個が私のプラグインとは！本当にありがとうございます。m(_ _)m　）

 

なお、「会員データ移行プラグイン」は、のぶろぐさんが作成されている２系の会員データを３系に移すことが出来るプラグインになります。
（２系から３系にリプレースする場合は、データの移行は必須だと思いますので、重宝しそうですね）

 

以上、公式メルマガで取り上げて頂いた喜びの内容でした。

EC-CUBE3.1a が公開されました。

SYSTEM_KDです。

EC-CUBE3の次期アップデートバージョン、EC-CUBE3.1 の評価版である、3.1a が公開されました。

https://www.ec-cube.net/press/detail.php?press_id=227

EC-CUBE3は、現在3.0.x としてバグフィックス等のマイナーバージョンアップが進んでおり、現在バージョン「3.0.13」が最新となっておりますが、3.1a は今後予定されている大型バージョンアップの評価版（第一弾）となっているようです。

EC-CUBE3.1 について

主な変更点としましては、以下が行われるようです。
（GitHub の EC-CUBE3.1.0 リリース計画より抜粋）

コアの機構見直し
・機能カスタマイズ性の向上に向けた機構改善
・フロントのデザインテンプレートでのフォームヘルパーの利用の見直し・分解
・Eccube-Upgrade-Fixerの開発
・プラグインの依存関係を解決する機構を実装
・EC-CUBEスタイルガイドラインの作成
・データベースのデータ型とカラム名の変更（for 3.1）

機能改善
・受注・配送データの改善
・デバイス毎にデザインテンプレートやレイアウトを設定する機能

その他
・初期インストール時のデータ投入をCSVファイルに変更

いやーガッツリと変わりますね。
（今、公開済みのプラグインを対応させるのに結構かかりそうだな・・）


ということで、ソースコードも合わせて確認してみましたが、たしかに色々と変わってますねー

まぁ、利用するフレームワークのバージョン自体が上がってますし、コアの機構に見直しが入ってこともありで、そりゃそうですが　^^;

まだ、3.1a　なので作り込みとしては、これからだと思いますが、カスタマイズ性向上部分についても、こんな感じになるというイメージを確認することができますので、ソースを落としてきて見てみるのも良いかと思います。
（って、どの対象向けの発言なんだこれｗ）


なお、デザイン部分の改善については、今回の3.1a には含まれていないので、今後公開されていくようです。
（そっちはそっちでどの位変更が入るのか気になるところです）


ちなみに、今後のマイルストーンとしては、EC-CUBE 3.1.0a2　が2017年5月公開となっているようです。

その中に「機能カスタマイズ性の向上に関する機構改善のフィードバック反映」が含まれているのですが、そのフィードバックできる会が、下記で開催されるようです。

2017年3月15日（水）　株式会社ロックオン本社

2017年3月16日（木）　株式会社ロックオン東京支社


ちょっと気になるし、行ってみようかなー。


以上、EC-CUBE3.1a が公開されました　でした。

EC-CUBE3向けプラグイン タイムセールpro をリリース

SYSTEM_KDです。

久々の新作プラグインとなります、EC-CUBE3向けのプラグイン「タイムセールpro」をリリースしました。

 

タイムセールPro

どんなプラグインかと言いますと、EC-CUBE3へタイムセール機能を追加するプラグインとなります。

（はい。そのままです。）

 

 

タイムセールプラグインですので、指定した「期間」に本来とは別の価格を設定することが可能となります。

セールを行いたい商品へタイムセール開始日と終了日、その間の価格を設定すれば、自動的に指定期間内だけ、特別価格で販売を行うといったことができます。

 

 

また、期間の指定は、日付だけでなく時間単位で細かく設定することができます。

このため、90分限定セールといったことも簡単に行うことができます。

 

 

さらに、指定した期間中、常にセールを行うだけではなく、「時間」「曜日」を絞ったセールを行うことができます。

このため、来月は1ヶ月間「土日限定」のセールを行いたいといった場合や、「火曜日の17時から30分間だけ」セールを行いたいといったことも、実現することができます。

 

 

上記の設定は、商品ごとに行えるのですが、同様の設定を複数の商品に行う場合は、設定時間が手間となっていまします。

ですが、当プラグインでは、これを回避しスムーズにタイムセールの設定を行えるようにするため、「共通設定」を作成できるようになっています。

 

共通設定でも、タイムセールの開始・終了の期間（日時）、時間・曜日の設定は変わることなく行え、価格についても、割引率を設定することが可能となっています。

 

共通設定設定の反映は、商品ごとでの選択・一覧からの一括設定にて行うことができ、複数の商品へも簡単に反映できるようになっています。

また、価格について割引率を設定できるようになっていると書きましたが、一部の商品は指定の割引率を利用せず、別の価格を設定したいという場合もあるかと思います。

そんな時のため、商品ごとのタイムセール設定にて「割引率」を利用せず「任意の価格」を利用するといった設定が行えるようになっております。

 

 

まとめ

タイムセールを実施する際に、利用できるものを色々と実装してみましたので、プラグインの名称を「タイムセールpro」と名付けてみました。

これから、年末年始に向けてECサイト（EC-CUBE3の）にて、タイムセールの実施をお考えでしたら、いかがでしょうか？

EC-CUBE3 向けプラグイン「タイムセールpro」

 

また、「あータイムセールプラグインにこの機能が付いていたら導入したんだけど」といった意見がございましたら、お気軽に申し付け下さい（笑）。もしかしたら、実装するかもです。

 

以上、EC-CUBE3向けプラグイン「タイムセールpro」のご紹介でした。

AzureのAppServiceで MySQL In App (プレビュー)なるものを見つけたので、EC-CUBE3を構築してみた

SYSTEM_KDです。

久々に、AzureのAppServiceで作ったEC-CUBE3環境（非公開）のコンソールを開いてたら、「MySQL In App (プレビュー)」なるものを発見したので、EC-CUBE3の環境を構築してみようと思います。

（試して書く方式ではなく、今試しながら作っていくのでゴールできるか分かりません！）

 

Web + MySQL 環境を作成

では早速。

「＋新規」から、「すべて表示」を選択。

 

表示されたら、「Web + モバイル」を選択。

 

フィルターへ「mysql」とかを入力して、「Web App + MySQL」を探す。

 

「作成」を押して、必要情報を入力。

その際、「データベース プロバイダー」は、「MySQL In App (プレビュー)」を選択します。

※ちなみにプランは、無料プランです

 

入力できたら、作成。

 

PHPMyAdminへアクセス

環境が作成できたので、メニューの中の「MySQL In App (プレビュー)」を選択してみます。

 

上部にある「管理」ボタンを押すと、PHPMyAdmin へアクセスできました。

 

 

おぉー

 

・・・

・・・

 

IDとパスワード何ですか？？

 

・・・

ググってみた結果、DB名は「azuredb」だということが判明しましたが、肝心のIDとパスワードが何なのかよくわからんです。

（デプロイ用の情報とかを入れてみたけどダメでした）

 

・・・・

・・・・

 

あ、よくみたら、先程の　MySQL In App (プレビュー)　ページに、接続文字列の環境変数というものがありました。

 

ここへ入ってるかもしれないので、確認してみます。

（って、どうやって見るんだこれ）

 

MySQL への接続情報を取り出す

ググってみたら、それっぽいページを見つけたので、参考にしてみます。

https://blogs.msdn.microsoft.com/appserviceteam/2016/08/18/announcing-mysql-in-app-preview-for-web-apps/#mysqlconnect

 

接続情報を取り出している部分だけ、お借りして。

以下のように、xxx.php　処理を作成。

<?php

$connectstr_dbhost = '';
$connectstr_dbname = '';
$connectstr_dbusername = '';
$connectstr_dbpassword = '';

foreach ($_SERVER as $key => $value) {
if (strpos($key, "MYSQLCONNSTR_localdb") !== 0) {
    continue;
}

$connectstr_dbhost = preg_replace("/^.*Data Source=(.+?);.*$/", "\\1", $value);
$connectstr_dbname = preg_replace("/^.*Database=(.+?);.*$/", "\\1", $value);
$connectstr_dbusername = preg_replace("/^.*User Id=(.+?);.*$/", "\\1", $value);
$connectstr_dbpassword = preg_replace("/^.*Password=(.+?)$/", "\\1", $value);
}

print_r("connectstr_dbhost = " . $connectstr_dbhost . "<br>");
print_r("connectstr_dbname = " . $connectstr_dbname . "<br>");
print_r("connectstr_dbusername = " . $connectstr_dbusername . "<br>");
print_r("connectstr_dbpassword = " . $connectstr_dbpassword . "<br>");

 

FTPでアップして、上記のページアクセス！

とれたー！！

 

って、

https://blogs.msdn.microsoft.com/appserviceteam/2016/08/18/announcing-mysql-in-app-preview-for-web-apps/#mysqlconnect

にのってるIDとパスワードじゃないか・・・。

 

ということで、このIDとパスワードを利用して、phpMyAdmin へアクセスできました。

 

EC-CUBE3をインストール

MySQLへの接続情報をゲットできましたので、EC-CUBE3をインストールしてみます。

まずは、ソースを配置します。

 

AzureへEC-CUBE3を設置する際、展開したファイルをアップする方法を行っていたのですが、「vendor」のファイル数が多いのもありうちの貧弱ネット環境だと、結構時間がかかるし、かといって圧縮した状態でアップ後に展開してもタイムアウトして上手く展開できなかったりするので、バシッと行くのがないんですよね。。

ということで、今回はローカルGitからアップします。

（それなりに、時間はかかりますが、他の方法より早いし、後々の管理も楽です）

 

まぁ、好きな方法でファイルをアップします。

ちなみに、今回インストールする、EC-CUBEのバージョンは 3.0.10 です。

 

ファイルがアップできたので、インストールしていきます。

 

次へ進む。

 

 

おっと、権限チェックにひっかかりました。

Azure は自動でディレクトリ作れない仕様だったはずですので、手動で指定されたディレクトリを作成します。

 

ディレクトリを作成すれば、次へ進めるようになるので、次は「サイトの設定」を入力します。

（まぁ説明不要ですね）

 

次はいよいよ、データベースの設定です。

 

取得したMySQLの接続情報を設定します。

（ポート番号含め、全部設定）

 

 

おぉ！！あっさり接続できました！！

 

あとは、テーブルの作成が上手くいくか・・・。

（ClearDBの無料枠は、同時接続数に阻まれて簡単には作成させてもらえないんですよね。。）

 

・・・・

 

完了！！！！

 

まとめ

Azureの無料枠というか無料に踊らされて、何回かEC-CUBE３をインストールしましたが、今回はかなりさくっとインストールできました。

しかも、（PHP7にしている恩恵もあるかもしれませんが）無料枠でもそれなりのレスポンスで動作してくれる気がします。

私の感覚としては、SQLiteで動作させたときよりもレスポンスよさ気です。

 

ということで、ちょっと整えたらプラグインのデモ環境用に公開したいと思います！！

 

以上、AzureのApp Service で MySQL In App (プレビュー)なるものを見つけたので、EC-CUBE3を構築してみた　でした。