ハブろぐ - havelog.ayumusato.com のフィード

a-blog cmsのText Expander用スニペット

あほむ — Wed, 10 Mar 2010 21:57:10 +0900

Text Expanderは最高です

TextExpanderが半額セール中 ( ソフトウェア ) :: ハブろぐ - havelog.ayumusato.com

以前にも紹介しましたが、TextExpanderです。今回は、a-blog cms用スニペットの最新版を公開します。キーボードのほうが好きな人や、モジュールの構造を暗記できている方は、こちらのほうがオススメなぐらいです。

参考@Text Expanderの紹介はこちら：シゴタノ！ — 寿命ものびるかも？タイピング速度を劇的に向上させる TextExpander を使い込む幸せ

acms.textexpander

http://ayumusato.com/souvenir/acms.textexpander

このURLをコピーしてください。これがスニペットデータへのアドレスになります。

「a-blog cmsのText Expander用スニペット」の続きを読む

LPO機能の検証にリファラをレッツ★改ざん

あほむ — Tue, 09 Mar 2010 23:34:29 +0900

LPO関連の機能

a-blog cmsのv1.3.0から本格的に実装されそうなLPO関連の機能について簡単に。検索エンジンからアクセスがあったときに、検索に使われていたキーワードを利用して、動的にランディングページのコンテンツを変える機能です。たとえば、弊社で制作中のサイトの404ページには、検索エンジンから404にきてしまったときに、検索に使われていたキーワードでサイト内検索した結果を表示するという実装(Ajax)がされています。

公開済みの例だと、株式会社マールさんが制作された、株式会社 JUNIOR【ジュニアー】さんのサイト（参考: 事例紹介）でも有名な機能です。このサイトのトップページに、検索エンジンからブランド名でランディングしたときは、そのブランドに関するコンテンツが表示されます。

検索ページじゃないと検証できない

そんな便利な一連の機能も、そもそも検索エンジンからアクセスしない限り、正常に動作しているかどうかは確認しようがありません。制作中のサイトでソレでは困ることも多いはず。

LPO機能の中核を成す、グローバル変数%{SEARCH_ENGINE_KEYWORD}には、検索エンジン（Google, Yahoo, Bing）からのアクセスがあった場合、検索に使用されていたキーワードが格納されます。この変数自体は、アクセス時のリファラを参照しているだけなので、リファラを任意の文字列に設定してしまえば、好きなように%{SEARCH_ENGINE_KEYWORD}の値を操作できるというわけです。

レッツ★改ざん

前置きが長くなりましたが、そんな事情により今回はリファラを任意に設定できるFirefoxのアドオンを紹介します。

リンク：refspoof :: Add-ons for Firefox

このrefspoofというアドオンは、任意のリファラーになりすましてサイトにアクセスできる機能を持っています。（別に悪いことしてるわけじゃないですよ！）スクリーンキャプチャの「ここでGoogleで検索したときのURLなどをセットします」という部分に、下のような検索ページのURLを貼り付けてみます。

おいしいりんご - Google 検索

おいしいりんご、というキーワードで検索したときのURLを貼り付けます。上のリンクをコピーするか、リンク先に飛んでからURLをコピーします。

a-blog cmsのサイトで実験

さて、a-blogcmsのサイトトップの下部にも検索ワードに反応する部分があります。これも、検索エンジンからアクセスがあると、使われたキーワードでサイト内検索をした結果を表示するようになっています。なので、手っ取り早くa-blog cmsのサイトで検証してみましょう！以下手順。

a-blog cmsのサイトにアクセス
前項でGoogleの検索URLを貼り付けた欄の横のspoofをクリック
サイトの下部を確認してみましょう！

もちろんそんなキーワードのコンテンツはありませんでしたが、検索エンジンから飛んでるわけでもないのに、リファラーを操作してなりすますことができました。

これで、LPO関連機能の検証もバッチリですね！a-blog cmsで本格的に使うのは、v1.3.0からになりそうですが、今のうちにゼヒ導入してみてください。お役立ちツールです。

archivesの画像をData URIに変換

あほむ — Tue, 09 Mar 2010 23:28:15 +0900

HTTPリクエストを減らそう運動モジュール

HTTPリクエストを減らすための手段として、ちょっと着目していたのがData URI（データスキーム）という方法。Data URIは、画像や音声などの色々なファイルをbase64エンコードを通して文字列(URI)に変換する技術です。技術のある人が極まると、えらいことできるらしいですが、今回は画像ファイルとHTMLを一体化させるために使います。

ACMS_GET_Plugin_DataUri(仮)

tpl;

        foreach ( $matches[1] as $src ) {
            // 拡張子を取得
            $ext    = pathinfo($src, PATHINFO_EXTENSION);
            // ファイル取得後、base64エンコード
            $pair[$src]  = 'data:image/'.$ext.';base64,'.base64_encode(file_get_contents(DOCUMENT_ROOT.$src));
        }

        $pair   = array_unique($pair);
        $raw    = array_keys($pair);
        $data   = array_values($pair);

        //ズバっと置き換え
        $this->tpl  = str_replace($raw, $data, $this->tpl);

        return $this->tpl;
    }
}
?>

このソースコードを、DataUri.phpとして、/php/ACMS/GET/Plugin/内に配置します。アップデートとかには一切対応しないワンタイムモジュールですが、興味のある方はどうぞ。

今回は、%{ARCHIVES_DIR}{path}のような、archivesディレクトリからの参照が確実である画像ファイルパスを対象にして、いい加減に正規表現マッチングをしています。

画像のHTTPリクエストが減る

ウェブページを表示する中で、HTTP通信の時間的コストはかなり高いです。Data URIとして、画像がHTMLの中に文字列として混ざることで、HTTP通信のコストが減少します。細かいファイルをチマチマと個別で読み込むのは想像以上に読み込み時間を食い散らかしています。

a-blog cmsの場合はHTMLと一緒に、キャッシュもバッチリされてしまいますが、そこまで大きな問題にはならないはず。サイトのページ数によってはDBのcacheテーブルの内容積がモリモリ増えてしまいそうですけど。DBの容量に自信がなかったり、サイトのページ数に自信がある場合は要注意です。

肝心の使い方は

以下、plainやvicuna等、index.htmlのテンプレート1枚で完結しているようなテーマを対象にした説明です。

当ハブろぐの場合は、既存のindex.htmlをindex_raw.htmlにリネームし、新しいindex.htmlとして下記のようなテンプレートを作成しました。

元のindex_raw.htmlの出力結果を、最後の最後でDataUriモジュールのフィルターにかけているという感じです。対象にできるimgパスがあれば、片っ端からData URIの文字列に置き換えていきます。

変換された画像は下のようなコードに変換されます。下のコードは、サブカラムの鳥さんの写真の場合です。…連続の英数字なのでハミ出ますが気にしない。

IEには元のindex_raw.htmlを使います

IEは8以降でないとData URIを表示できません。よって、ルールを使ってUser AgentからInternet Explorerには、すべて元のテンプレートである、index_raw.htmlを直接表示するように設定します。8は対応してますけど、現状のルールにはそんな器用な項目はないので全部ナシです。

そうそう滅多なことは起こらないと思いますが、なんかあったら教えてもらえると助かります。判定をもうちょっと賢くかけばもっと遊べそうですね。ちゃんと速くなるかなー？

フォームIDのログ表示をもう少しデキる子にしよう

あほむ — Tue, 09 Mar 2010 20:19:08 +0900

フォームIDのログ表示が損してた

a-blog cmsのフォームは、投稿されたデータをDBに保存しているので、後からCSV形式としてダウンロードして集計等に再利用できます。そんな投稿データですが、管理ページ上からもログとして確認することができます。

表示できるものは必要十分に備えているのですが、ちょっと大振りな感じすぎて肝心の投稿データの中身は読みづらい感じです。見栄えで損している感じですね。見せるものはあるのに、もったいないです。

じゃあ変えてみよう

/themes/system/admin/form/log.htmlを編集します。40〜57行目のtable.adminTableを下のコードに貼り替えてみます。アップデート時に上書きされないようにする場合は、件のlog.htmlを、使用中のテーマ/admin/form/log.htmlとしてコピーして編集します。


    
        
            日時
            宛先
            件名 / 本文
        
    
    
        
            {datetime}[datetime(Y/m/d H:i)]
            宛先: {mail_to}
            
                件名: {mail_subject} ( 本文を表示 )
                本文:
{mail_body}[nl2br]

日時	宛先	件名 / 本文
{datetime}[datetime(Y/m/d H:i)]	宛先: {mail_to}	件名: {mail_subject} ( 本文を表示 ) 本文: {mail_body}[nl2br]

なんということでしょう

劇的ビフォーアフターとまではいきませんが、ちょっとはソレっぽい感じになったのではないでしょうか。宛先にメールアドレスのmailtoリンクも貼ってみました。

送信時のテンプレートに、To[]でお問い合わせ主のメアドを仕込んで自動応答メール風にしている場合は、このフォームのログ画面からメーラーを起動して、お問い合わせ主に返信を書くこともできます。

「一般メール」をフォームからの送信者への自動応答メールに、「管理者宛メール」をクライアント（orサイト管理者）への送信内容の通知、というように設定しておけば、クライアントに対しては「ここでお問い合わせを確認して、送信者に返信できます」とか言うこともできるかも。

モノは言いようというヤツですね。もっとキレイに飾ってあげれば、もっとモノを言えるかもしれません。

携帯向けGoogle Analyticsの計測異常(au, softbank)

あほむ — Fri, 05 Mar 2010 18:55:31 +0900

計測異常

今回は以下のエントリーのシリーズ編です。

そいで、前エントリーあたりで言及していた計測異常について。

au: 直帰率が100%・新規セッションも100%・ページビューは1
softbank: 見あたらない。(not set)とかいうのがソレっぽい

なーんかauとsoftbank取れてないなー。おかしいなーと思っていたら只の間違い探しでした。

ga.phpがお茶目すぎた

端末情報ちゃんと食ってるよねぇ〜？と、ga.phpの140-149行目を見てました。

    $guidHeader = $_SERVER["HTTP_X_DCMGUID"];
    if (empty($guidHeader)) {
      $guidHeader = $SERVER["HTTP_X_UP_SUBNO"]; // えっ？
    }
    if (empty($guidHeader)) {
      $guidHeader = $SERVER["HTTP_X_JPHONE_UID"]; // えっ？
    }
    if (empty($guidHeader)) {
      $guidHeader = $SERVER["HTTP_X_EM_UID"]; // えっ？
    }

ん？

$SERVERってなんやねん。

    $guidHeader = $_SERVER["HTTP_X_DCMGUID"];
    if (empty($guidHeader)) {
      $guidHeader = $_SERVER["HTTP_X_UP_SUBNO"];
    }
    if (empty($guidHeader)) {
      $guidHeader = $_SERVER["HTTP_X_JPHONE_UID"];
    }
    if (empty($guidHeader)) {
      $guidHeader = $_SERVER["HTTP_X_EM_UID"];
    }

こうでしょ！

ってことで、たぶん解決。

どうしたGoogle！　大丈夫かGoogle！

ga.phpの140-149行目における、$SERVERになっているところを、$_SERVERに修正してください。（アンダースコアが足りてない）

これでたぶんdocomo以外の計測も正常に行われるようになるんじゃないでしょーか。きっと。おそらく。清々しいケアレスミスだけど、それが大公開されっぱなしって、Google先生ほどの大家になると誰も突っ込んでくれないのかな...。

うまくいったよー、っていう人とかいたら教えてくださいまし。

携帯電話向けGAモジュール for a-blog cms

あほむ — Fri, 05 Mar 2010 14:05:39 +0900

携帯向けGoogle Analyticsとa-blog cms

Google Analytics全般とa-blog cmsの相性の良さは後日言及するとして、今回は携帯対応ということでa-blog cmsのワンソースマルチユースの特徴が特に生きてきます。

同じURLでパソコンにも携帯にもiPhoneにもコンテンツを出力できるので、まとめてアクセス解析したときにも端末ごとの分析が容易になります。たとえば「PCで見られないこのコンテンツはiPhoneで多く見られてる」とか「携帯のときのトラフィックが特定エリアだけ高い」とかですね。

もちろん、絶対数の埋め合わせとかの調整は必要ですし、PCとモバイル用サイトが同じような構成とも限らないので、単純比較というよりも傾向のあぶり出しになりそうですが。サイトによっては興味深いデータが得られるのではないでしょうか。

今回はa-blog cmsでGoogle Analyticsの携帯電話向けトラッキングに対応するための、GETモジュール対応手順をまとめてみます。

GAの携帯電話向けサイト用PHPコードを出すまで

まずはここから。以下に手順を示します。

Google Analyticsのプロファイルを「編集」をクリック
画面右上の「ステータス確認」をクリック
トラッキングコードの追加手順の「アドバンス｣タブを選択
"(1) 何をトラッキングしますか？"の「携帯電話向けのサイト」を選択

以上で、"(2) 携帯電話向けのサイトにコードを貼り付けます" にPHPのコードが表示されます。スクリーンショットで示している所の文字列を控えてください。これが、携帯電話向けのトラッキングアカウントです。コードの他の部分はモジュールのサンプルコードに書いてあるので必要ありません。（今後Google側で変更があれば、サンプルコードも変更する必要がありますが、そのときはそのときで）

ga.phpをダウンロード

前項からの続きで、"(3) ファイルをルートディレクトリにコピーします" から、ga.phpをダウンロードします。これをルートディレクトリに置くわけですが、a-blog cmsの設置先、index.phpと同階層のディレクトリにga.phpをアップロードします。

トラッキングアカウントをコードに組み込む

下記のサンプルコードにトラッキングアカウントを埋め込み、/php/ACMS/GET/AnalyticsMobile.phpとしてファイルを作成します。これが後でテンプレートに記述するGETモジュールになります。

tpl, new ACMS_Corrector());

        // 下記の " MO-0000000-0 " の所を前項で控えた文字列に書き換えます
        $GA_ACCOUNT = 'MO-0000000-0';
        $GA_PIXEL   = 'ga.php';

        $url    = "";
        $url   .= $GA_PIXEL . "?";
        $url   .= "utmac=" . $GA_ACCOUNT;
        $url   .= "&utmn=" . rand(0, 0x7fffffff);

        $refer  = REFERER;
        $query  = $_SERVER["QUERY_STRING"];
        $path   = $_SERVER["REQUEST_URI"];

        if ( empty($refer) )
        {
        $refer  = "-";
        }

        $url   .= "&utmr=" . urlencode($refer);

        if ( !empty($path) )
        {
        $url   .= "&utmp=" . urlencode($path);
        }

        $url   .= "&guid=ON";
        $url    =  str_replace("&", "&", $url);

        $Tpl->add(null, array('tracksrc' => $url));

        return $Tpl->get();
    }
}
?>

テンプレートにモジュールを書く

先ほど作成した AnalyticsMobileモジュールを、携帯向けのテンプレートに記述してください。大まかには下記のサンプルコードをコピー＆ペーストするだけで大丈夫なはずです。場所はbody要素の閉じタグの直前です

（前略）

これでOK

あとは適当な日を置いて、Google Analyticsからレポートを確認しましょう。DoCoMoとかが解析結果にあれば大体成功です。

携帯かどうかというのは、ユーザーのOSの情報として代替的に示されるので、ちゃんと絞り込まないと携帯の情報は取得できません。カスタムレポートやアドバンスセグメントを併用するのが良い感じですが、とっかかりとしては下記の記事のカスタムレポートをそのまま使うのが良さそうです。

携帯用カスタムレポート for Google Analytics | カグア！Google Analytics 活用塾:事例や使い方

a-blog cms v1.3.0では、モバイルトラッキング用のアカウントと、ga.phpのパスを設定項目として、標準実装に滑りこませてしまおうかなーと勝手に検討中です。（他に影響があるような機能でもないので割と気軽）

それまではひとまず、こちらのモジュールを使っていただければと思います！ご質問なりトラブルがあれば、@ahomuまでどうぞ☆

携帯電話向けGoogle Analyticsを導入

あほむ — Thu, 04 Mar 2010 23:16:28 +0900

携帯電話とったどー

昨年の後半発表された、Google Analyticsの日本の携帯電話対応。絵文字のユニコード化といい、なぜかGoogleは日本のガラパゴス技術にも積極的な取り組みを見せてくれています。

今回、それを使って携帯電話のアクセスがなんとなく取れました。なんとなく取れたのでメモ。

でもスクリーンショットを見ると分かるとおり、Softbankっぽいキャリアが見あたりません。単純にいないだけなのか、取得できていないのか謎なので、もうちょっと調べる必要がありそうです。

=> 解決編追記@携帯向けGoogle Analyticsの計測異常(au, softbank)

携帯電話向けのGoogle Analyticsトラッキング

通常のGoogle Analyticsはga.jsを挿入することで、ユーザーがブラウザを開いたときにJavascriptが起動して、Googleにアクセス情報を送信します。

しかし、日本の携帯電話のほとんどは依然としてブラウジング時にJavascriptが使えないため、同じようなアクセス解析はできません。そこで携帯電話向けのGoogle Analyticsは以下のような、一見して回りくどいプロセスでトラッキングを行います。

(1)アクセス情報を飛ばすPHPファイル(ga.php)を設置: Google Analyticsからga.phpをダウンロードしてきて、公開ディレクトリのルートに配置します。これが、Googleにアクセス情報を飛ばす処理の本体です。
(2)ユーザーアクセス時に、(1)のPHPを起動するための下準備: HTMLファイルの先頭にトラッキングURLを生成する関数を記述。bodyタグの終了直前に、src属性が前述の関数が出すURLになっているimgタグを記述。
(3)ユーザーからのアクセスによってga.phpが起動: ユーザーがページにアクセスすると、ページ下端に仕込まれたimgタグが読み込まれます。imgタグのsrc属性がga.phpにアクセスするようなURLになっているため、ブラウザは画像を求めてga.phpにアクセスします。アクセス情報はsrcにあるURLのGETクエリーとして乗っています。
(4)ユーザーにダミー画像を Googleにはアクセス情報を: アクセスされたga.phpは、ユーザーには1x1ピクセルのダミー画像を返し、GoogleにはGETクエリーに乗ってきたアクセス情報を送ります。

普通にphpなどのプログラムを貼る必要があるため、慣れない人やHTMLオンリーな人は戸惑いを感じるかもしれません。とはいえやってること自体はコピペ天国です。

ナマのHTML+PHPなら大体こんな感じ

タイトるんるん♪

まことにもうしわけありません

ろれむいぷさむらりるれろろれむいぷさむらりるれろろれむいぷさむらりるれろろれむいぷさむらりるれろろれむいぷさむらりるれろ

" />

拡張子htmlのまま動かしたい場合は、.htaccessに下の記述を加えればいいです。

AddType application/x-httpd-php .html

携帯向けサイトを作る機会がある方はぜひ。カスタムレポートとかちゃんと設定すれば、Google AnalyticsひとつでコンテンツへのPC版等と比較しながら検討できて便利です。サービスが分散しないのはいいこと。

a-blog cmsはテンプレート上でphpが使えないので、GETモジュールにしてあげる必要があります。次回、そのGETモジュールをまるまる公開予定です。

OAuthについて（OpenIDとは違うのだよ）

あほむ — Fri, 19 Feb 2010 00:34:45 +0900

OAuth

OpenIDが、あなたは本人ですか？ねぇほんと？ねぇ？的な身元証明の技術であるのに対して、OAuthはこの人に合い鍵渡していい？ねぇ？ほんとにいいの？的な私財へのアクセス許可の技術です。

現在、Twitterの他にもYahooやGoogleのAPIもOAuth認証に対応しています。FlickrもOAuthのベースになってるような認証だった気がするけど、今はどうなんでしょうね。

とりあえずベーシック認証よりは、よっぽどセキュアというわけですが、詳しいメリットや成り立ちなどは、下の参考URLでもご覧くださいまし。

参考：APIアクセス権を委譲するプロトコル、OAuthを知る − ＠IT

そのプロセス

コンシューマー登録: アパートの管理人（サービスプロバイダ ex.Twitter）に、合い鍵収集業者（コンシューマー）として登録し、業者ID ( コンシューマーキーとコンシューマーシークレット ) を得ます。
リクエストトークンの請求: アパートの住人（ユーザー ex.Twitterユーザー）に、合い鍵くれとリクエストを送ります。その際、業者IDをユーザーに渡して、OKなら業者IDを管理人に渡してくれ、と頼みます。
ユーザーの認否: ユーザーは管理人のとこに行って、この業者に合い鍵を渡すかどうかを判断します。（Twitterとの連携サービスとかをやると、良く出てくるアレです。許可・不許可の。）
リクエストトークンの発行: ユーザーがOKを出してくれると、合い鍵業者は、管理人に合い鍵を請求するための委任状（リクエストトークン）をもらえます。
アクセストークンの入手: 委任状を手に入れた合い鍵業者は、それを携えて管理人に、そのユーザーの合い鍵（アクセストークン）をもらいに行って、それを受け取ります。
合い鍵が変わったら？: 合い鍵はたまに変わってしまうかもしれません。そのとき、合い鍵業者は委任状と前の鍵を持って、もう一度管理人に会いに行きます。委任状が今でも有効なら、新しい合い鍵を受け取れます。すでに無効なら、それは住人が、あなたとの縁を切ったということです。

逆にわかりづらい？

抽象化したら逆に分かりづらい気がする。そうでもないか？まあ、そんな感じでトカゲのしっぽを切れる程度の便利認証でござる。一晩だけの関係とかでもいいわけですよ。合い鍵業者とか訳の分からないことを言わずに、夜這い業者と訳した方が良かったか。

前エントリーで述べたような、HTTPリクエストの実装よりは、よっぽどハマりポイントはありません。仕様に従って作れば一通り問題ありませんでした。OAuthで重要なのは、その意義（使い所）とプロセスを理解することです。

RFC3986の形式でちゃんとエンコードしないとダメとか、そういうのはありますが、コンシューマー側を作る分には、そこまで大変ではありません。サービスプロバイダー側を実装するのは結構面倒くさそうな...。

「OAuthについて（OpenIDとは違うのだよ）」の続きを読む

HTTPリクエストするためのクラス書いてみた

あほむ — Thu, 18 Feb 2010 01:35:14 +0900

HTTPリクエスト再び

Twitter API用のライブラリがどうとか言いながら、全然公開してませんな。

スピンアウト品による、HTTPリクエストについてメモしとくです。この後にOAuthかな。そしてTwitter, Flickr, Google, YahooあたりのAPIと遊ぶ方法とか。一通り試した後なので、暇を見つけながら、内容をまとめて自分メモ的にブログ書くつもり。a-blog cmsと連携したTwitter BOTぐらいはちゃんと作って公開すっか。

APIを叩く用に

get('http://havelog.ayumusato.com');

$res = $http->header;
$body = $http->body;

if ( !($http->error) ) {
     return true;
} else {
     return false;
}
?>

GET！POST！で適当にリクエスト投げれて、レスポンスヘッダーもレスポンスボディも、一通り取ってこれるようにしたかったのです。API相手しか考えてないので、POSTメソッドもクエリーのやり取りしか考えられてません。

file_get_contentsとかだとレスポンスコード200以外のときのレスポンスボディを端折りやがるので、ソケット接続から始めてリクエストを書き込んで受け取って、と地味な作業を繰り返してます。地味ですけど、HTTPの仕様の勉強になります。裏でこういうやり取りされてたんですね。

ハードウェアやソフトウェアの深淵を見るには、文系の自分には叶いません。でも、たまーに少し深いところを垣間見ると、なんとなく、してやったりという気分になれます。ああ現金。

覚え書きリスト

リクエスト時の改行コードはCR+LFで鉄板くさい
末尾の改行コードが足りないとシカトされることすらある
ステータスコード204と304はレスポンスボディがない（仕様的に）
HTTP1.1のchunkedデータは、送ってきたり送ってこなかったりする
chunked受け取りたくなかったら1.0としてリクエスト
phpのparse_url関数はステキ（regex書き終わった頃に教えてもらった）
httpsはssl://に変換して、portも合わせて変える

「HTTPリクエストするためのクラス書いてみた」の続きを読む

間違った女子力を発揮するバレンタイン

あほむ — Sat, 13 Feb 2010 22:56:55 +0900

チョコをつくった

ドライフルーツとナッツ類を、適当なビターブレンド気味チョコと混ぜ合わせてコロコロして固めて粉まぶして。写真暗いですけど、実物の断面はもうちょっとキュートな感じだったと主張させていただく。

チョコを作るのはいいんですけど、余るんですよね。無塩バターが。普段料理しないのに、バターだけが大量に取り残される。きっと全国で同じような境遇の無塩バターが、そこらじゅうに溢れていると思う。そして消費されきれないまま忘れ去られていく....。ちょっと切ない感じ。

だから使ったよ！

かんせいひーん

こねこねこね

ぷっはー

少しでもバターを消費するべく、追加でスイートポテトを製造。酒を飲みながら材料を潰し混ぜ合わせて、ぐりぐりぐりぐりぐりぐりぐりぐりぐりぐり。それでも余るんですけどね。

ラッピングもした

用意してたラッピング容器に入り切らなくなったので、途中で東急ハンズに個包装を買い出しにでかけて。やっぱりバレンタインコーナーがすごい人混み。みんな大変だ。

別に今回が初めてなわけでもなく、この時期にバレンタインコーナーに乗り込んで材料やラッピングを買うぐらい、何てことはありません。挙動不審になることすらなく、堂々とラッピングを選ぶ自分がキモイ。その場にいること自体が不審だし。

あとは個包装をまとめ直して用意しましたとさー。さて、来年はどうするかな。毎年バリエーションを変えていかないと...。