だ。ログ。

開発とかスノボとかやきうとか。

CUBE3の特定ディレクトリにリダイレクト

EC-CUBEを使っていて一覧ページは使わない。詳細ページは使わない。
ランディングページだけでよろしく~みたいなオーダーが来る事がある。
トップページだけでページを完結させたいって奴だけど、何もしないと一覧ページや詳細ページを辿る事が出来てしまい、ややダサい。
ってな事で、トップページにリダイレクトさせる

/src/Eccube/Controller/ProductController.php

# 一覧ページ
public function index(Application $app, Request $request)

# 詳細ページ
public function detail(Application $app, Request $request, $id)

#リダイレクト
header("Location: /");
exit;

各表示コントローラーでリダイレクトする。
もう使いませんってな時は301リダイレクトでも良いのかもしれない。

リバースプロキシの無限リダイレクト

無限地獄

rider-dice.hatenablog.comの記事の続き
リバースプロキシ掛けた側の設定は良かったけど、じゃあmofumofu.comにアクセスがあった場合に、hogehoge.comにリダイレクトしなきゃな。
.htaccessを記述

<Files ~ "^\.ht">
deny from all
</Files>

# Redirect
Redirect permanent / http://hogehoge.com/

えーと…FireFoxChrome共にリダイレクトループしてるよ。と警告が。
確かになんでもかんでもリダイレクトさせてしまうと、hogehoge.comからのアクセスもhogehoge.comに返してしまって無限地獄に。
んで以下のように修正

<Files ~ "^\.ht">
deny from all
</Files>

# Redirect
RewriteRule ^mofumofu\.com(.*) http://hogehoge.com/mofumofu/$1

mofumofu.comへのリクエストに関してをhogehoge.comに転送してね。と。
あとはhttpsとかIPのデフォルトでも同様の処理を書けばOK。

リバースプロキシを使った複数サイトの統合風味のようなもの

前提条件

CentOS 6.9
Apache 2.2
バーチャルホストにて運用中である
にて動作を確認。

やりたいこと

1. アクセスするドメインhttp://hogehoge.com/
2. 上記のドメイン内で表示させるドメインhttp://mofumofu.com/

【なにがやりたいか?】
http://hogehoge.com/mofumofu/ にアクセスした場合、http://mofumofu.com/内のコンテンツを表示させる

やること

リバースプロキシを使って、1のサーバーでアクセスした際に2のサーバーのコンテンツを取得し表示させる。

$ cd /etc/httpd/conf.d/
$ vi hogehoge.com

#<VirtualHost *:80>内に記述
    ProxyPass /mofumofu/ http://mofumofu.com/
    ProxyPassReverse /mofumofu/ http://mofumofu/

$ service httpd restart

リバースプロキシを掛け、mofumofuディレクトリ内にアクセスがあった場合はmofumofu.com内のコンテンツを表示させる。
これで
http://hogehoge.com/mofumofu/にアクセスすると
http://mofumofu.com/のコンテンツが表示される事を確認。

一応PHPやDBのアクセスも動作していたので、サーバー移転や統合で使えそうかな。と。

Facebook Graph APIのアクセストークンを引き伸ばす

期限

まず無期限が出来ないらしい。
と言う事は永続的にアプリを運用する場合、運用においてアクセストークンを更新し続ける必要性がある。
何も意識せずアクセストークンを発行すると有効期限が1日のアクセストークンになっていて、気が付いたら有効期限切れになってしまう。

期限を伸ばす

最大で2ヶ月(60日)のアクセストークンを発行する事が可能。
とは言え2ヶ月でトークンが切れてしまう事を考慮すると、その度にトークンの取得を行わねばならない。
FBのフィードページを運用する場合、運用担当者にこの辺を任せないと瑕疵責任だけこっちに巻かれてしまう可能性が有るので教育コストを含めた提案にしておかないと後々厄介。

手順

トークンが発行出来ている事を前提
現行でのFacebook Graph APIのバージョンは2.9なので現行バージョンでの確認の仕方とする

https://graph.facebook.com/oauth/access_token?grant_type=fb_exchange_token&client_id=アプリID&client_secret=鍵ID&fb_exchange_token=アクセストークン

小難しい事はせず文字列を取得したデータに書き換えてブラウザで開くとJSON、生データ、ヘッダーのタブが表示される。
表示されているaccess_tokenを貼り付けて終わり。

検証

ツール&サポート>アクセストークンツールに移動し自分のアプリの[デバッグ]を選択し、生成されたトークンを貼り付けデバッグをクリックするとアクセストークン情報が出て来るので有効期限が(約2ヶ月以内)となっている事を確認しておく。

自動でトークン更新時期ですよリマインダとか作るのか、自動的にトークン発行して更新するのか。と言う部分はあるが
そこまでご丁寧にシステム運用するのは自社サービスレベルで良いかな。と。

Facebookのフィードを取得する

よりユーザーライクにて言う意味ではFacebookTwitterと言ったソーシャルの更新をサイトに埋め込んで表示させたい。ってな事が多いかと。
特にFacebookや本人や団体が明示化されているので信頼度も高く、リピーターとのコミュニケーションにもなりやすい。
ってな訳で、サイトにフェイスブックのフィードを表示させてたいと言うオーダーが来たので忘備録。

Facebook Graph APIを利用する

Facebookから提供されているAPIのGraphAPIにてフィードをcurlを利用して取得する。
記事をアップした2017年7月10日時点でのバージョンは2.9、今後も倍ばりとバージョンアップされ仕様が変わっていくのであくまでも2.9のバージョンで動きました。ってレベルのメモ。

1. Facebookにログインしアプリケーションを登録する

https://developers.facebook.com/apps/ にて新しいアプリを追加 をクリックする。必要情報を入力し、ダッシュボードに移動。
ダッシュボードに表示されている

・アプリID
・app secret

上記2項をメモ帳などに保存しておく。

2. 作成したアプリの動作チェックを行う

ダッシュボード上部のメニューにある[ツール&サポート]をクリックする。
遷移したページメニューの[グラフAPIエクスプローラ]をクリック

グラフAPIエクスプローラのアクセストークフィールドの横のボタンから「ユーザーアクセストークンを取得」をクリックし
作成したアプリケーションで取得したいデータを選択。今回の場合はフィードを取得するので[user_posts]を選択しアクセストークンを取得をクリック。
この時取得したアクセストークンをリクエストの際に使うのでメモ保存しておく。

リクエストクエリの作成

フィードを取得するクエリを作成する。

$url = "https://graph.facebook.com/v2.9/me?fields=feed&access_token={上記で取得したトークン}";

このURLをcurlにて取得する

$ch = curl_init();
curl_setopt_array($ch,
	array(
		CURLOPT_URL => $url,
		CURLOPT_SSL_VERIFYPEER =>false,
		CURLOPT_RETURNTRANSFER =>true,
	)
);
$res = curl_exec($ch);
curl_close($ch);

$arrFeed = json_decode($res, TRUE);

curlにクエリを渡し取得したデータから表示するデータを形成する。

上記のクエリのままだとデフォルト値なので取得するデータは25件あるのでデータとして重い可能性がある。
例として5件のみに絞りたい場合は以下

$url = "https://graph.facebook.com/v2.9/me?fields=feed.limit(5)&access_token={上記で取得したトークン}";

feedに.limit(件数)を記述する事で取得件数を明示的に指定する事が可能。

問題点

開発途上のAPIのため高い頻度で取得するクエリの記述形式が変わる。
いままで取得出来たフィードが突然取得できなくなる事があるので「安定運用」と言う言葉が使えない。

また、レスポンス速度もお世辞にも良いとは言えずデータを取得するまでにややラグを感じる。
サイト速度を重視している場合、かなりの確率で論外と言われてしまう。
「どうにかならないの?」と言うオーダーを貰って、リアルタイムではなく1日数回フィードを取得して
データベースに書き込んでDBから取得すると言うやり方をしたが、まったくもってリアルタイム性が無くてシステム屋としてはう~む。。と。

画像のズームを実装する

Amazonで目にする商品にマウスカーソルが当たった際に画像が大きく拡大表示するアレ。
ECサイト構築の際の御用聞きでベンチマークとなっているサイトがAmazonである場合に結構な確率で言われる。
それ専用のプラグインも出回っているがjsで対処出来るのでメモ。

必要なjs imagezoomer
http://zoomsl.sergeland.ru/

ロシアのサイトです。
js本体のみなのでダウンロードして適当なディレクトリに設置。書いてる時のバージョンが3.0だったのでそれに沿う。

1. jsの読み込み

<script type="text/javascript" src="/hoge/fuga/zoomsl-3.0.js"></script>

至ってシンプル、ヘッダでもフッタでも管理しやすい場所に記述する。

2. イベントの実装

<script type="text/javascript">
$(function(){
	$(".image-zoomer").imagezoomsl({
		zoomrange: [1, 10],
		zoomstart:5,
		magnifierpos: "left",
		innerzoom: true,
		innerzoommagnifier: true
	});
});
</script>

3. 画像ファイルへのクラスの貼り付け

	<div id="detail_image_box__item--{{ loop.index }}"><img src="{{ app.config.image_save_urlpath }}/{{ ProductImage|no_image_product }}" class="image-zoomer"/></div>
</script>

imgとなる部分に今回宣言したclassを設定して終わり。

色々と選択肢はあるけど、スタイルシートや属性、クラスをアレコレと付ける必要が無い事がいちばん大きい。
ロシア語ながらサンプルも有るので動かして、ああこれがこう言う機能なんだ。と言う部分で探り探りやらなきゃいけないが
ミッションとしては画像にカーソルが当たった際にズームして欲しい。と言う部分の要件は満たしている。
これ以上に高機能な事をやりたい場合はデザインを含めて考えないといけないような気がする。

あとスマホはあまり期待しない方が良い。

山口俊の登板

2017年7月2日 とうとう山口俊がベイスターズと対峙する日
それまで何度となく山口投手の抑えを先発をスタジアムから見守り、ときに落胆もあったけれど声援を送った選手が2016年にFAでジャイアンツへ。
6月の初登板では堂々の無安打投球を披露、ツボに入った時の山口俊投手の強さを見せつけた試合だった事と
ベイファンからすればあまり気持ちの良いFAでは無かった事でブーイング必須と言う事もあり好投されて「ちょうきもちいいーー!」と言われるフラグじゃないかと危惧。

案の定試合開始前のマウンドに向かう際にレフトから浴びせられる大ブーイング。両手を広げ「なに?気にしてないよ」とアピールする山口投手でしたが
10年近くハマスタで彼を観ていただけに本当に効いていないとは思えないブラフかな。と。
さて試合は初回は三者凡退に抑えるものの、打線はセンター返しを基本に2回にロペス選手のレフトへ突き刺さるライナーのホームラン
打たれた後の山口投手を見ると「まあしかたない」とつぶやきながら気を取り直すもののことごとく甘いボールを打ち返されランナーを溜めタイムリ
3回には筒香選手への初球、中途半端に変化しない半速球をフルスイングされライトへ軽々運ばれ、その後もズルズルと4回9安打6失点で降板

ベイスターズは同一カード3連勝、ビジターでのスウィープに成功すると共に、菅野投手、マイコラス投手、山口投手と言う
いまのジャイアンツの投手陣の軸となる3人相手にしっかりと勝利を収めました。

山口投手、ベイスターズ野手共に手の内を知っているだけにどんな作戦を取ってくうかと楽しみだったのですが
ベイスターズは初回のセーフティバントの構えとセンターから逆方向に打ち返すワンシーム対策を徹底していたように見えます。
特に手元で変化するボールとして去年から身につけたワンシームは打ち損じ凡打を「打たせる」武器。
そのワンシームを攻略する為の対策として、変化を見極める為にボールを引きつける逆方向、特に宮﨑選手が上手い印象ですがヒットを重ねれば
ワンシームやスプリットは使いづらくなり、カウントが悪くなれば力のあるストレートを。と言う詰将棋のようなロジックをしていたように感じます。

逆に山口投手はあまり調子が良くなかった事もありますが、ベイスターズを意識してしまい投球に集中できていなかったかなと。
この敗戦だけで言えば、山口投手の攻略は苦手とするフィールディングに加えてワンシーム対策をして投げづらくして選択肢を狭める事を他球団にもある程度意識付けられたかと。

あくまでも調子が悪い事が前提ですが、大まかな山口投手の弱点を古巣が浮き彫りにした。
そう言えばバッテリーを組んでいた髙城選手が山口選手のウィークポイントと言う事を言っていたし、同一リーグ移籍の怖さ今後も感じる事になりそうだなと。


ただ、いまのジャイアンツを象徴していたなと思うのは、山口投手の降板が決定した段階で誰も声を掛けにいかない。
年上、外様と言う事でなかなか話が出来る人が少ないと言う事もあるでしょうが、打たれた状況フォローが無くポツンとベンチに座る山口選手を観てFAの難しさを改めて実感しました。
そして、最終回の満塁のチャンスでベンチが移りましたがベンチの前で声を出しているのが今年加入した石川慎吾選手のみ。
他の選手はなかなか積極的に声が出せていない状況でした、今のジャイアンツに必要なのは勝利ですが、生え抜きの選手が生き生きする為に何が必要なのか。
あくまでも個人的な意見でしかないですが、OBや外野が四の五の言わずに野球に集中出来る環境だと思います。
俺の時代は、俺らの頃は。その時とは状況が大きく変わっている。確かに現役を引退し現場から遠ざかっているOBが声を掛けてくれる。それだけチーム愛が有る事だと思いますが
ややもすると精神論とおれぞれの価値観の押し付け合いが、ジャイアンツを迷走させている。そんな風に感じる終末でした。