GoogleのDescending into MLの和訳です。

元記事
Descending into ML: Linear Regression

機械学習へ降りる：線形回帰

コオロギ（昆虫種）は、涼しい日よりも暑い日に多く鳴くことが長く知られています。

約数十年間、専門家とアマチュアの科学者は、１分あたりの鳴き声と気温のカタログデータを持っています。

誕生日プレゼントとして、おばさんはコオロギのデータベースをくれて、この関係性の予測を学習するように頼みました。

このデータを使って、この関係性を調査したいです。

最初に、プロットすることでデータを調べます。

はい、ラインは全ての点を通ってはいませんが、線は明らかに鳴く回数と気温の関係性を現しています。

線を等式を使って表すと、以下のように関係性を書くことができます。

y = mx + b

ここで

・　yは予測しようとする摂氏の温度です。
・　mは線の勾配です。
・　xは分あたりの鳴く回数で、入力値です。
・　bは、yの切片です。

機械学習の慣例として、少し違うように以下のように書きます。

y’ = b + w1x1

ここで

・　y’は予測するラベルです。(望まれる出力)
・　bはバイアス(yの切片)で、w0を参照します。
・　w1は特徴1の重みです。重みは、伝統的な線形の等式の勾配mと同じ概念です。
・　x1は特徴です。(明示的な入力)

新しい分あたりの鳴く回数x1の温度y’を予測するために、

MySQLで、複数のテーブルを組み合わせた処理を行うときに、ビューは便利な機能です。

ビューを使うことで、よく使うテーブルの組み合わせで都度構文を組み立てる必要がなくビューを呼び出すとよいだけに簡素化されます。

ただし、ビューでも定義するときに、複雑な処理のビューを作ろうと思った場合、注意する必要があります。

まず、ビュー内でサブクエリを呼び出すのは、特定のバージョンまではできなかったのですが、最新のバージョンではできるようになっているようです。
MySQL 5.7、MariaDBなら10.2以降はできますが、それ以前のバージョンではできません。

その場合で少し複雑なビューを作ろうと思った場合、複数のビューを組み合わせることで実現可能です。

まずビューの中で呼び出そうと思っていたサブクエリにあたるビューを定義し、そのビューをビューを定義する際に呼び出すといったやり方です。

PHPで、あるプログラムを作成していて、file_get_contents関数で特定のURLからJSONファイルを取得するという処理を行っていたのですが、以前は動作していたプログラムが、サーバ移行後に file_get_contents関数で取得できなくなってしまった現象に遭遇してしまったので調査と対応について記しておきます。

状況

・　特定のURLから file_get_contents関数でJSONファイルを取得し、後に処理

・　以前は動作していたが、サーバ移転後に動作しなくなった

・　レスポンスヘッダもNULLを返すようになっていて、原因が不明

調査

まず、エラーログを見て file_get_contents 関数がエラーになっていないかどうかを調べてみたのですが、エラーにはなっていませんでした。

結果からいうと、エラーになっていたわけではなく、取得がNULLになっているという謎の結果。

解決

ファイルを取得するのに、file_get_contents関数ではなく、cURL関数を使うことで解決できました。

以下の記事が参考になりました。

file_get_contents関数が動かなかった場合の方法 ｜ Tips Note by TAM

cURL関数を使うことで、file_get_contentsとほぼ同じ動作をする関数を定義して、使用しました。

何故 file_get_contents 関数が新しいサーバで動作しなかったのかについては不明ですが、代用の関数でなんとかなりました。

だいぶ前からですが、Googleが自動広告を出す設定にしていて、それを利用しているユーザも多いのではないかと思います。

Googleの自動広告は、設定で「テキスト広告とディスプレイ広告」「インフィード広告」「記事内広告」「関連コンテンツ」「アンカー広告」「モバイル全画面広告」の6種類があります。

私も運営しているサイトにGoogleの自動広告を導入していたのですが、このうちで「モバイル全画面広告」だけは削除しました。

なぜモバイル全画面広告を削除したか

以下が、なぜモバイル前画面広告を削除したかの理由についてです。

１．ユーザ体験を著しく悪化させる

なぜモバイル全画面広告を削除したかというと、まず自分のサイトをスマホでチェックしているときに、リンクをクリックしたときに画面全体に広告がバンと表示されるのですが、これは、そのサイトを使うのをやめたくなるレベルで印象が悪いマイナスの体験でした。

いくら広告がクリックされて収入がでても、こんなに露骨に広告が表示されるサイトは使いたくないと思ってしまいました。

２．収益、クリック数が少ない

Adsenseのレポートを確認してみたところ、自動広告全体のパフォーマンスは優れていましたが、その中でのモバイル全画面広告のパフォーマンスはあまり良いとはいえませんでした。

クリック率は他の広告と比べても悪くはなかったのですが、表示回数が少ないので収益も全体からすると大きな割合ではありませんでした。

まとめ

自分で使ってみて単純に邪魔だったのと、収益がよくないという２つの理由から、自分の運営しているサイトからモバイル全画面広告を外しました。

AIの勉強として、GoogleのMachine Learningのサイトを見て勉強しているのですが、全部英語なので理解がてら翻訳で書いていきます。

機械学習とはなにか？

機会学習のシステムは、入力値をどうやって混ぜ合わせて、まだ見たことがないデータを予測することを学習します。

用語集

Label：ラベル
ラベルはyを予測するにあたっての真の事象です。
基本線形回帰における変数yです。

Features:特徴
特徴や、データを描画する入力値です。
基本線形回帰における、{x1、x2・・・・xn}変数です。

Example：例
xで、データの実体です。

Labeled example：ラベル付けされた例
特徴で(x,y)です。モデルを学習するのに使います。

Unlabelede example:ラベル付けされていない例
特徴で(x,?)です。新しいデータを予測するのに使います。

Model:モデル
モデルはからy’を予測するためのマップです。
学習した内部のパラメータによって定義されます。

モデルは特徴とラベルとの間の関係を定義します。
例として、スパムフィルターモデルはス確かな特徴をパムと関連付けます。

モデルの２つのフェーズをハイライトしましょう。

トレーニング(Traigning)：
トレーニングはモデルを構築まあは学習することを意味します。
それは、ラベル付けされた例をモデルに見せることで、特徴とラベルの間の関係を徐々に学習することを可能にします。

推論(Inference)：
推論は、訓練したモデルをラベル付けされていない例に適用することを意味します。
それは、学習されたモデルを使って有用な予測y’を作成します。
例として、
推論の間に、ラベル付けされていない例のための住宅価格の中央値を予測することができます。

回帰(regression) vs 分類(classification)

回帰モデルは連続した値を予測します。
例えば、回帰モデルは以下のような回答を予測します。

・　カリフォルニアの住宅価格は？
・　ユーザの広告のクリック率の予測は？

分類モデルは、離散的な値を予測します。
例として、分類モデルは以下のような問題の回答の予測を作成します。

・　電子メールメッセージはスパムかそうでないか
・　この画像は犬か、猫か、ハムスターか

学習の監修

以下のオプションを探索してみましょう。

電子メールがスパムかそうでないかを予測するために、監修された機械学習のモデルを開発するのを監修します。
以下のどの文章が正解でしょうか？

・　いくつかの例に適用したラベルはあてにならない。

正解
その通りです。どうやってデータの信頼性をチェックするかは重要です。このデータセットのラベルは電子メールのユーザから来ていて、電子メールをスパムとマークしています。
多くのユーザが全ての疑わしい電子メールをスパムとマークしているわけではなく、私達は電子メールがスパムであるかどうかを知るのに苦労します。
それに加えて、スパマーは意図的に間違ったラベルを提供することで私達のモデルを汚染します。

・　ラベル付けされていない例をモデルを訓練するのに使用します。

不正解
私達はラベル付された例をモデルを学習するのに使用します。
私達は訓電されたモデルを、ラベル付けされていない例がスパムかそうでないかを判定するのに対して使用します。

・　サブジェクトのヘッダーに含まれる語句はよいラベルになります

不正解
サブジェクトのヘッダに含まれる語句は素晴らしい特徴ですが、よいラベルではありません。

・　スパムにもスパムでないのにもマークされていない電子メールはラベル付けされていない例である。

正解
なぜなら私達のラベルはスパムかそうでないかの値を含んでいて、全てのスパムかそうでないかをマークされていない電子メールはラベル付されていない例です。

特徴とラベル

以下の選択を調べてみましょう。

オンラインの靴店は、ユーザに対して最適化した靴をおすすめするように監督した機械学習モデルを想定としています。
それで、そのモデルは正しいペアの靴をマーティーと、別の靴のペアをジャネットに対しておすすめします。
以下のどの選択肢が正しいでしょうか。

・　靴の美しさは使える特徴です。

間違いです。
良い特徴は、具体的で定量化できるものです。美しさは、よい特徴となるにはかなり漠然としたコンセプトです。
美しさはおそらく正しく具体的な特徴であるスタイルや色を混ぜ合わせたものです。
スタイルや色は美しさと比べるとよい特徴といえるでしょう。

・　靴のサイズは使える特徴です。

正解です。
靴のサイズは定量的なシグナルで、それはユーザがおすすめされた靴を気に入るかどうかに対して強い影響があります。
例えば、マーティーがサイズ9の靴を着ている場合、モデルは7サイズの靴をおすすめします。

・　ユーザの好みの靴は使えるラベルです。

違います。
好みは観測できず、定量化出来ないメトリクスです。
私達ができることは、観測できる好みの代理的なメトリクスを探すことです。

・　ユーザがクリックした靴の説明は有用なラベルです。

正解です。
ユーザは多分彼らが好みの靴に対してより多くを知りたいと望んでいます。
ユーザのクリックは、白髪って、観測でき、定量化できるメトリクスで、よいトレーニングのためのラベルになりえます。
　

Gitの使い方について勉強したことのメモです。

Gitとは

プログラムのソースコードなどの変更履歴を記録・追跡するための分散型バージョン管理システム。
Linuxの生みの親であるリーナス・トーバルズによって開発された。

Gitという技術自体ととく使われているGit Hubのサイトは別。

最近プログラム界隈では非常によく使われている。

Gitを使うメリット

複数人でプロジェクトに携わる場合、ソースコードの管理がしやすい（状況をメンバー全員で履歴として把握できる。他人がアップロードしたファイルをローカルにダウンロードできる）
ソースコードの変更の履歴が追えるため、古いファイルを上書きしてしまった場合でも差し戻すことも可能。(バックアップとしても機能する)

Git Hub と Git lab

Gitを使ってソースコードを管理できるサイトは様々なサイトがある。

最も有名なサイトがGit Hub。
それ以外では Git labやBacklogなどがある。

メリットでいうと、Git Hubは最もよく利用されているために機能が充実している。
しかし、プロジェクトを非公開のプライベートプロジェクトにする場合は有料会員にならないといけない。
全て公開プロジェクトで利用する場合は無料でも使用できる。

デメリットでいうと、サイトが全て英語。

Git lab

Git Hubに続いて2番手でよく利用されているサイト。
メリットとして、Git Hubとほぼ同様の機能を持ちながら、プライベートプロジェクトを無料でも作成することができる。

デメリットでいうと、やはりサイトが全て英語。

Backlog

Gitを使ったバージョン管理を行える他に、様々な機能がついている。
メリットとしてはサイトがすべて日本語なので日本人にとって使いやすい。

デメリットでいうと、無料がトライアル期間の30日間しかなく、それをすぎると最低でも2000円/月の料金が発生する。

私はこの中ではプライベートプロジェクトが個人利用で無料なことからGit labを選択しました。

Gitの使い方

Gitは、PCからコマンドラインで実行します。

ローカル環境の作業フォルダをGitのローカルリポジトリに登録し、サイトにアップロードを行います。

コマンド

git init

現在のフォルダ(カレントディレクトリ)をgitに対して初期化します。
cdコマンドで、作業フォルダに移動してから行います。

gid add ファイル名

作成したファイルをローカル環境のインデックスに登録します。

git commit -m “メッセージ”

インデックスに追加されたファイルをコミットします。
コミットとはGitの用語で、ファイルやディレクトリの変更をリポジトリに登録する操作のことです。

git commit .

インデックスに登録されたファイルの中で修正のあったファイルを全てリボジトリに登録します。
実行するとコメントを入力する画面が表示されるので、入力して保存すると変更内容が自動的にコミットされます。

git status

ローカルリポジトリの状況の確認

git remote add origin リモートリポジトリのアドレス

リモートリポジトリのアドレスを登録します。

git push origin master

登録したリモートリポジトリに、ローカルリポジトリの情報を反映されます。

git branch

現在のブランチの一覧を確認します。

git branch ブランチ名

ブランチを作成します。

git checkout ブランチ名

指定したブランチに移動します。

git checkout -b ブランチ名

上記のコマンドで、ブランチを作成して移動できます。

ブランチを移動後は、ファイルを登録したりコミットしたりするのは通常と同じです。

git push origin ブランチ名

ブランチの内容をリモートリポジトリに登録します。

git pull ブランチ名

リモートリポジトリのファイルをローカル環境にダウンロードします。

git merge ブランチ名

ブランチの状況をmasterブランチに取り込みます。

git push origin master

マスターブランチにmergeしたファイルを反映します。

git clone url

既存のリモートリポジトリをローカル環境にダウンロードします。

WordPressのサイトURLをHTTPからHTTPSに変更した後に管理画面にログインすると、500エラーでリダイレクトループが発生していると表示され、管理画面にログインできなくなりました。

以下は、対処した方法のメモです

wp-config.phpに以下を追記

wp-config.phpに以下の箇所を追記します。

追記する箇所がポイントで、wp-settings.phpを読み込む前に記述しないと、管理画面にログイン後に「このページにアクセスする権限がありません。」と表示されて別のエラーが表示されるので注意が必要です。

wp-config.phpの末尾に追記してしまうと上記のエラーが表示されたので、記述位置には注意してください。

PythonのWebスクレイピングフレームワーク「Scrapy」で、クロール中の現在のURLを取得する方法についての解説です。

Scrapyで特定のurlをクロール中、クロール中のページのurlを取得したい場合があり、方法について調べてみました。

以下の記述で取得ができました。

response.request.url

Spiderのstart_urlの記述で複数のページを設定した際、現在クロール中のページによって処理を分岐させたかったため役立ちました。

pyhtonのスクレイピングのフレームワーク「Scrapy」で、以下のことを実装しようと思い、方法で行き詰まってしまいました。

スクレイピング中に、リンク先のページから特定の要素を取得し、元の処理に加える

要するに、以下のようなイメージです。

上記のような処理は、Scrapyでよく遭遇します。

parseの処理中に、リンク先のページから要素を取得し、yieldで返します。

ただし、上記の記述は、処理2で返した辞書型の要素を、そのままRequest型で返すため、単にリンク先のページで特定の値だけ取得してその後の処理でその値を使いたい場合には、上手く処理することができません。

どう解決したらいいかを考えてみたのですが、結論としては、Scrapy.Requestを使用しないということで解決しました。

URLは確定していて、リンク先のページの特定の要素を取得したいだけであれば、他のライブラリのBeautiful Soupなどを使うことでも解決できます。

例えば以下のような処理を使用することでリンク先ページのタイトルタグを取得できます。

無理にScrapyのRequestオブジェクトを使って取得する必要はなく、処理の中で別のライブラリを使用することで上手く解決できました。

phpstormで、選択した行に一括でインデントを入れる方法について調べたのでメモです。

方法としては、インデントをいれたい行を選択して、上のメニューの「Edit」→「Indent Selection」で入れることができます。

逆に一括でインデントを下げる場合は、上記のメニューの下にある「Unindent Line Selection」で選択範囲のインデントを一括で下げることができます。

WordPressで、カスタムパーマリンクを使っていて、以下のようなことを実現しようとしていました。

パーマリンクを使ってURLを作成し、以下のようなURLのページがあったとします。

http://example.com/test/

このページに /test/ ディレクトリ以下に、数字の /1/というURLを付加し、パラメータとして処理をしようとしました。

http://example.com/test/1

上記のようなURLにして、数字の1を取り出して、プログラム内で処理しようとしていました。

しかし、いざ実行してみると・・・

http://example.com/test/1

とアドレスバーに入力すると

http://example.com/test/　　

にリダイレクトされてしまうという現象が・・・・

何故？

ちなみに

http://example.com/test/2

とアドレスバーに入力すると、問題なく表示される。

何で2は通るのに1が駄目・・・？

ということで、問題に対処するために、

WordPressのソースコードに

echo $_SERVER[‘REQUEST_URI’];

を処理開始部分から追記していって、URLがどこで変化しているかを調べてみました。

すると、最初の段階では

http://example.com/test/1

と画面上に出力されていました。

それが、どこで変化しているのか・・・

結論としては

/wp-includes/template-loader.php内の

do_action( ‘template_redirect’ );

この処理の後で、

http://example.com/test/1　→ http://example.com/test/

にURLが変化していました。

そして、上記の処理(do_action( ‘template_redirect’ );)をコメントアウトしてみたところ、

http://example.com/test/1

きちんと処理されるようになりました。

この処理を飛ばすとサイトの表示に問題が起きるわけでもなく。

というわけで、調査の結果としては以上となりました。

サーバ内での環境構築で、仮想環境を使用してプロジェクトを作成する場合があると思います。

ただし、仮想環境で作成したプログラムは主に仮想環境内で実行しているので、仮想環境の外からcronを実行しようとした場合に動作しない場合があります。

その場合で、cronで仮想環境からプログラムを実行する手順について調べました。

手順としては、シェルスクリプト(.sh)を作成して、シェルスクリプト内でサーバ内のディレクトリを移動し、仮想環境を有効にしてからプログラムを実行。

後に仮想環境から出るという手順で問題なく実行できました。

以下は仮想環境のvenvを使用した例です。

上記のシェルスクリプト(.sh)を作成し、cronで実行することで問題なく実行することができました。

最近Google Adsenseの、自動広告が利用可能になりましたが、自動広告の中で、関連コンテンツの広告があります。

関連コンテンツは、ページの下部に、同ドメインサイトの関連コンテンツを自動で表示してくれる機能で、複数の関連コンテンツと、関連コンテンツに合わせて広告も表示してくれます。

本記事では関連コンテンツの広告のクリック数と、関連コンテンツの広告でない記事のクリック数の確認方法について掲載します。

関連コンテンツの広告のクリック数

※クリックで拡大

Adsenseの管理画面で、パフォーマンスレポート→詳細レポート→「広告フォーマット」で確認できます。

要求されたコンテンツの種類→「ネイティブ/関連コンテンツ/広告あり」の項目を見ると、クリック数や収益が確認できます。

広告でない関連コンテンツのクリック数

※クリックで拡大

Adsenseの管理画面で、パフォーマンスレポート→一般的なレポート→アカウント全体の画面で、
「関連コンテンツ」タブをクリックすることで確認が可能です。

Mac OS S High Sieraで、pythonでMySQLのライブラリをインストールして使用していたところ、以下のエラーメッセージが出てしまい対処に困りました。

環境は、
OS:Mac OS S High Siera
MySQLバージョン:5.6
pythonバージョン:3.6.1
です。

ImportError: dlopen(/Library/WebServer/Documents/crawl/scraping/lib/python3.6/site-packages/_mysql.cpython-36m-darwin.so, 2): Library not loaded: libmysqlclient.18.dylib

原因について調べていたのですが、該当のファイルが開けないということで、該当ファイルへのシンボリックリンクを設定することで解決しました。

まず、

find / -name libmysqlclient.18.dylib

で、該当のファイルの存在している場所を調べます。
私の場合は、

/usr/local/mysql-5.6.19-osx10.7-x86_64/lib/libmysqlclient.18.dylib

にありました。

以下のコマンドでシンボリックリンクを設定しました。

sudo ln -s /usr/local/mysql-5.6.19-osx10.7-x86_64/lib/libmysqlclient.18.dylib /usr/local/lib/libmysqlclient.18.dylib

私の場合は、以上の手順で解決しました。

Linuxサーバの場合は、/usr/local/lib/　でなく、 /user/lib/　のパスらしいのですが、MacOSXの場合は、 /user/lib/ のパスがスーパーユーザでも書き込み不可になっていて、 /usr/lobal/lib/がシンボリックの設定箇所になります。

サイトの運営をしていて考える必要があることは、ウェブサイトのバックアップをどう取るかです。

仮にバックアップを取っていない場合、何らかの問題が起こってサーバ上のデータが消えた時に、取り返しがつかなくなります。

サーバ上のデータが消える原因としては、作業ミス、サーバのハッキング、サーバ会社川野問題など、様々なものがあります。

これらの問題に対処するための方法もまた多様で、サーバ自体を多重化することなどもありますが、基本はバックアップを取ることです。

中でもデータベースは、毎日変化する場合もあるため、こまめにバックアップを取ることが求められます。

バックアップを取る基本は、cronでデータベースのダンプファイルをサーバ内の特定のバックアップフォルダに保存することですが、この場合、サーバ自体が消えてしまったときにバックアップがありません。

そのため、サーバ自体の障害に対応するためには、サーバの外部ストレージにデータを定期的に退避させておくことも重要になりますが、手動でやると手間がかかります。

1つの方法として、Dropboxにバックアップデータを転送する方法があります。

Dropboxは無料である程度の容量までは使用できるため、バックアップを取る方法の１つとして優れています。

ただし、セキュリティ的には100%安全とはいえないので、顧客の個人情報を含む場合の方法としては推奨できません。

手順についてなのですが、Git Hubで、Linux系のOSからDropboxにファイルをアップロードするシェルスクリプト(dropbox_uploader.sh)が公開されているので、それを利用する方法は簡単なのでおすすめです。

具体的な手順としては、Qiitaの以下のページに詳しく掲載されていますので参考にするとよいと思います。

さくらVPSのデータのバックアップに Dropbox を使ってみる

流れとしては、サーバにdropbox_uploader.shをアップロードして実行権限を与え、必要なDropboxへのアクセス情報（トークン情報）を設定してやるとシェルスクリプトが利用可能になるので、あとはcronで実行することでDropboxへ好きなタイミングでアップロードできます。

ウェブサイトを構築するときに、動的URLがサイトを構築する場合に必要となる場合があります。

動的URLとは以下のようなURLで、英語ではquery string(クエリストリング)というようです。

http://ドメイン名/ディレクトリ名/product.php?id=◯◯◯

id=◯◯◯の数字の部分によって、表示されるページが変わるといったかんじです。

この動的URLというのは、SEO上不利になるのかというのは昔からしばしば議論されていて、関係あるとか無いとか言われていました。

公式には、Googleは動的URLだろうと静的URLだろうとGoogleは同様にページを扱うということを表明しています。

しかし、私はいろいろなサイトで実験をしてみた結果として、やはり動的URLはSEO上不利と言えるという結論に至りました。

何故動的URLはSEO上不利なのか

何故動的URLはSEO上不利になるのかということを考察すると、Google botが、複数のページを個別ページだと認識してくれないケースがあるからです

具体的にいうと

http://ドメイン名/ディレクトリ名/product.php?id=1
http://ドメイン名/ディレクトリ名/product.php?id=2
http://ドメイン名/ディレクトリ名/product.php?id=3
・・・
・・・
・・・
http://ドメイン名/ディレクトリ名/product.php?id=126

みたいな商品ページが120ページあるページがあったとして、Google botが、それらを個別ページだと判断せず、１つのページしかGoogleの検索結果にインデックスしない場合があります。

この場合、Googleのウェブマスターツールでは、インデックスカバレッジの項目で

Google により、ユーザーがマークしたページとは異なるページが正規ページとして選択されました
（英語で「Google chose different canonical than user」）
と表示されます。

なぜこういう現象が起こるのかは不明なのですが、例えば上記の例だと

http://ドメイン名/ディレクトリ名/product/1.html
http://ドメイン名/ディレクトリ名/product/2.html
http://ドメイン名/ディレクトリ名/product/3.html
・・・
・・・
・・・
http://ドメイン名/ディレクトリ名/product/126.html

のほうが、個別ページだと認識をしてくれやすいようです。

また、

http://ドメイン名/ディレクトリ名/product/1
http://ドメイン名/ディレクトリ名/product/2
http://ドメイン名/ディレクトリ名/product/3
・・・
・・・
・・・
http://ドメイン名/ディレクトリ名/product/126

のほうがおそらく個別にインデックスしてくれる可能性は高いと思います。

仮にインデックスされた場合はページの評価はどちらのURLでも変わらないと思うのですが、動的URLでは全てインデックスされない場合があるということが分かったので、静的URLのほうが有利であるという結論に個人的には至りました。

Google botが、何故個別ページを単一のページと誤認するケースがあるのかは謎ですが、アルゴリズム上そういう事例が発生する場合があるということが分かったので、私も考えを改めました。

動的URLを静的URLとして扱うためには、サーバ側の設定でmod_rewriteを利用したり、あるいはプログラム上の処理で工夫をする必要があります。

様々なサイトから特定の情報を収集してまとめたサイトを作成しようと思い、Pythonでスクレイピングの勉強をしています。

メモ代わりにやったことをまとめておきます。

やりたいこと

Pythonで複数のウェブサイトから特定の情報を取り出してきてまとめたい。
何故Pythonかというと、PHPでもできるのだろうけど、最近Pythonが人気なのと、勉強も兼ねて。
スクレイピングして取り出したデータをデータベースに保存するまではPythonでやって、表示するサイトはPHP+WordPressでもいいかなと。

ローカル環境でのテスト

まずサイトを立ち上げる前にローカル環境でテストを行っています。

環境
MacOS High Sierra

Pythonのインストール

まずは最新のPython3をインストール

確認したところ、本記事執筆時点でバージョンは3.6.1

仮想環境の作成

以下のコマンドで、仮想環境を作成します。

python3 -m venv scraping

仮想環境を作成してそれ以下でやることで、開発環境でライブラリの依存関係などをプロジェクトごとに制御しやすい。

上の例では「scraping」という仮想環境を作成。

上記で作成した仮想環境に入るには

. scraping/bin/activate

では入れます。

仮想環境を抜けるには

deactivate

で抜けられる。

ライブラリ「Beautiful Soup」のインストール

スクレイピングをするのに便利なライブラリ「Beautiful Soup」をインストールする。
必須ではないが、あると便利

pip install beautifulsoup4

上記のコマンドでインストールを行う。
エラーが出たが、pipのアップグレートを行うことで解決した

pip install –upgrade pip

簡単なスクレイピングのテスト

簡単なスクレイピングのテストを行った。
Beautiful Soupは、それ自体ではローカルにあるファイルしか読み込めないため、urllibというモジュールをインポートして使用し、組み合わせることで外部URLを、URL指定で読み込むことができる。

上記のプログラムでは、抜き出したいHTMLページのURLからa要素を取り出して、URLとテキスト情報を出力している。

pythonのスクレイピングでやりたいこと

特定のウェブサイトのページの、特定テーブルのtd要素を全て取り出してリスト化したい。
そのために色々と試行錯誤をしてみた。

1・Beautiful Soupを使ってみる

上記の例では、スクレイピングしたい対象のページからtd要素のテキストを抜き出して表示するというもの。

結果としては、途中のtd要素までは取得できたものの、取得するページの要素がJavascriptの広告の部分でストップしてしまい、その先の要素を取り出せなかった。

調べてみたところ、そもそも

soup = BeautifulSoup(html, ‘html.parser’)

でhtml要素を取り出して、何故かページの途中までしか正常に取得できていなかった。
原因は不明。

2.lxmlを使ってみる

Beautiful Soulを使ってみて駄目だったので、lxmlというライブラリを利用してスクレイピングをしてみました。

まずは必要なライブラリをインストールして、基本的なプログラムを作成。
上記の例は、URL指定をしてページを取得するというもの。
取得する部分でエラー。

failed to load external entity “ページURL”

よく分からないけどできなかった。

3. Scrapyを使ってみる

スクレイピング用のフレームワーク「Scrapy」を使ってみた。

Scrapyは

pip install scrapy

でインストールできる。

最初に対話モードで実行したところ、最初の時点でいきなりエラー。
一度は実行できたのに、もう一度実行するとエラーに。
意味不明・・・。

と思っていろいろと操作していたら、pythonコマンドから実行するのではなく、コマンドライン上ですぐに実行すると実行できた。

上記の例では、まずはscrapyで対象のURLのページ内容を取得し、
次で、特定のクラス名のテーブル要素の、tdのテキスト要素を取得できた。

ただし、上記の例での問題として、tdの中にspan要素があり、span要素に挟まれたテキスト情報が除外されてしまうという問題が発生した

response.xpath(‘//table[@class=”クラス名”]/tr/td/span[@class=”クラス名”]/text()’).extract()

上記に変えて実行することで、除外されていたspan要素に含まれるテキスト情報を逆に全て出力することができた。

だんだんコツがつかめてきた。

Scrapyがツールとしては一番使えそうなかんじがした(といっても、簡単なプログラムを作成した結果問題が起きなかった)ので、とりあえずはスクレイピングに使うツールとして決定。

以下は、変数「url」に入った相対パスを、現在クローラーがいるページのURLにつなげて絶対パスに変換する記述

response.urljoin(‘url’)

プロジェクトを作成する

scrapyを使用するにあたって、まずはプロジェクトを作成する

scrapy startproject プロジェクト名

これで、プロジェクト名のディレクトリが作成される。

プロジェクトを作成すると、プロジェクト名のディレクトリ以下に、フレームワークのファイルやディレクトリ一式が自動生成される。

プロジェクトを作成後、設定ファイルとして「setting.py」ファイルが作成されるが、
クロール先のサイトに迷惑をかけないように、

DOWNLOAD_DELAY = 1

を追記しておいがほうがよい。
デフォルトのダウンロード間隔は0秒のため、クロール先のサイトに思わぬ迷惑をかけてしまう場合があるので、この設定をしておくことで、ページのダウンロード間隔が1秒になるため、クロール先のサイトに迷惑を少なくできる。

Spiderの作成

Scrapyでは、Spiderと呼ばれるファイルを作成することで、クローラーを実行する。

Spiderは、コマンドラインから以下のコマンドで作成できる。

scrapy genspider　Spider名 サイトのドメイン名

上記のコマンドで、プロジェクトのspidersディレクトリ以下に、「Spider名.py」と呼ばれるファイルが作成される。

ファイルを開くと、デフォルトで

def parse(self, response):
pass

という関数が定義されているが、このparseという関数をScrapyは実行するのでこの関数を変更していく。

parseで実行した処理は、yield文を使用することでスクレイピングした値を返していく。

返す形式は、辞書形式でも問題なし、itemクラスを使用しても問題ない。

itemクラスは、プロジェクトを作成時に、「items.py」というファイル内に定義されていて、ファイルにクラスを定義することで使用できる。

yieldで返した値は、Scrapyを実行する際に、外部ファイルに出力することができる他、後述するItem Pipelineを使用することで、データベースへ保存することも可能。

実行する場合は、

scrapy crawl スパイダー名

で実行できる。

Item Pipelineの活用

ScrapyにはItem Pipelineと呼ばれる機能があり、使用することでデータをチェックしたり、データベースにデータを保存したり、parseの処理で返したItemオブジェクトを利用した処理を行うことが可能。

Pipelineの記述は、プロジェクトフォルダ内の「pipelines.py」に記述する。

pipeline.pyにクラスを定義し、setting.pyに定義をすることで呼び出す。

ITEM_PIPELINES = {
‘プロジェクト名.pipelines.クラス名’ : 300,
‘プロジェクト名.pipelines.クラス名’ : 800,
｝

上記の例の300や800といった記述は優先度で、数が小さいほど優先して処理される。
0〜1000までの間で定義され、優先度が高い順から定義されたクラスが処理される。

ここで、yieldで返されたitemオブジェクトのチェックを行ったり、データベースに保存する処理を行える。

pipeline.py内の関数 process_item内に、pipeline実行時に処理をする記述を行う。

最近のGoogleからの推奨で、ウェブサイトの全体SSL化が推奨されていますね。

私が運営している複数のサイトも、SSLに対応するため、複数のサイトをSSLに対応しました。

SSL移行の手順

手順としては以下の通りです。

１．　サイトをHTTPSで見れる設定にして、記述を諸々変更する
２・　301リダイレクトでHTTPへのアクセスはHTTPSへ飛ばす
３・　ウェブマスターツールでHTTPSのサイトを新しく登録し、Google AnalyticsのサイトのURL設定を変更する

といった形で、複数のサイト（１０サイト程度）をほぼ同時期にHTTPS化しました

SSL化する方法としては、Cloudflareの無料SSLを使っています。

結果

結果としてですが、複数のサイト（１０サイト程度）で、アクセス数の増減が発生しました。

SSL化してすぐに発生したわけではなく、1週間か2週間程度経ってから発生しました。
(それまでは問題なかったのにです。）

サイトのアクセス数の減少度合いはサイトによってばらつきがあり、最も大きく減少したサイトは、アクセス数が6割程度減少しました。

少ないサイトでは2割程度の減少で、サイトによってはアクセス数がほぼ変動なしのサイトや、むしろ増加したサイトも見られました。
（大幅に増加したサイトはなく、微増といったかんじです）

何故アクセス数が減少したかの考察

アクセス数が減少した理由についていろいろと調査してみましたが、まず、ウェブマスターツールを調べてみたところ、サイト全体の平均検索順位の低下はそこまで顕著には見られませんでした。

それにも関わらずアクセス数が減少幅が大きいサイトで6割も減少したのは、別の理由がありました。

原因としては、HTTPS移行後の特定のURLがインデックスに登録されなくなったことにありました

ウェブマスターツールで調べてみたところ、以前はインデックスされて上位に表示されていた複数のページが

「Google により、ユーザーがマークしたページとは異なるページが正規ページとして選択されました」という結果でインデックスから削除されていることが確認されました。

それらのページがランディングページとしてサイトに流入していたアクセスがごっそり消えてしまったわけです

上記のエラーは、HTTPのURLとHTTPSのURLが混在しているため、HTTPSのほうを非表示にしているといった内容ではなく、何故か移行後の特定のURLがそれまでは単一のURLとみなされていたのが重複URLをみなされてインデックスから除外されてしまうということが発生してしまったわけです。

これには正直困りました。

なぜなら、そのサイトでも、特定のページは問題なく移行できているものもあるのに、特定のURL(パーマリンク設定のURL）のぶんだけ移行できなくなってしまったからです。

設定に不備がなかったからサイトのページを何度も確認してみましたが、Canonical設定の不備や記述の不備も見当たらず、困り果ててしまいました。

そもそも、サイトやページによって何故こうもばらつきがあるのかも理解できませんでした。

HTTP→HTTPSへの完全な移行には一ヶ月ほどかかるそうなので時間がかかるのであれば仕方がないですが、もし回復しなかった場合、致命的な結果ということになります。

結論：サイト全体のHTTPS化は一概に推奨はできない

HTTPSの通信は、ネット通販で個人情報を入力するサイトなど、サイトによってはなくてはならない必須の技術です。

しかし、サイト全体のHTTP→HTTPS化は、移行に伴う検索順位の低下のリスクが伴うことが分かりました。

移行手順に不備があった可能性も考えられますが、それがGoogleの管理コンソールにどういった理由かも表示されず、ただ一方的に順位の低下やインデックスからの削除のみ、結果として受け取らないといけないのは、Google側の不備としかいいようがない気がします。

HTTPS化はGoogleから推奨はされているものの、検索順位のアップなど、メリットが明確に受け取れるわけではないので、どうしても必要という場合以外は見送ったほうが賢明な判断だと思いました。

利用しているサーバはConohaのKusanagiで、Nginx+php7の環境。

phpでフォームを作った際に、PHPの「max_input vars」の設定に引っかかって、変数が投稿できなくなってしまった。

調べてみると、現状の設定が

max_input vars 1000

になっていて、これを

max_input vars 3000

あたりに変更したい。

nginxは、.htaccessが使えないので、php.iniで設定を変更するが、どのファイルを変更したらいいのか分かりにくい。

そのときは、phpinfo()で出力したファイルで、php.iniの設定ファイルの場所が確認できるので、場所を確認する

私の環境の場合には

/etx/php7.d/php.ini

を変更すればよかった。

上記のphp.iniを開き

max_input vars 1000
↓
max_input vars 3000

に変更

その後、設定を反映させるためにphpを再起動

kusanagi php7

私の環境はphp7なので、上記のコマンドでphpを再起動して反映できる。

現在の自分の環境を確認するには、

kusanagi status

のコマンドが便利な他、phpの設定の確認には phpinfo()　を利用するとよいだろう。

サイト運営に利用していたサーバを、サーバの運営に利用していたPleskの値上がりを受けて別のサーバへ移行しました。

サーバの環境もけっこう代わりました。

移行前の環境
php5+Apache

移行後の環境
php7+Nginx

すんなりサーバが移行できたわけでなくて、いろいろとトラブルも発生したので発生した問題点と、解決方法について備忘録として書いておきます。

１．サーバを移行しようと思った理由

これまで使用していたサーバの月額費用が、Pleskのライセンス費用で値上がりしたと、いってみればそれだけの理由です。
試算してみると、Plesk抜きのサーバへ移行すると月額2000円〜最大で3000円ほど（年額換算で3万円ほど）節約できる試算になったのでこのタイミングで移行することにしました。

２，移行したサーバ会社

ConohaのVPSに移行しました。

Conohaを決めた理由としては

• サーバに最新技術が導入されていてサイトの動作速度向上が期待できる
• Pleskは使えないが、Kusanagiコマンドで簡単にサイト設定を行うことができる
• 費用面でサーバのメモリを少なくすれば月額費用はかなり少なくてすむ

という点になります。

２．移行プロセス

カスタムパーマリンクが機能しない

まず、サーバ管理のソフトウェアをApacheからNginxに変更しました。

理由としては、速いから？　よく分かりませんがそうしました。

そしてPHPのバージョンを７にしてみたのですが、これはうまく行かず、理由としては、WordPressのカスタムパーマリンクが上手く機能しなかったから。

URL/〜〜〜/〜〜〜/

上記のようなWordPress上で設定していたURL設定が機能せず、Not Foundとなる。
この解決方法がわからなかったので、別の方法を考えました。
（理由としてはNginxの設定だったのですが、最初は分かりませんでした）

Apache + HHVMを試してみる

結局サーバのNginxではだめだったので、HHVMでサーバを変更してみることにしました。

HHVMというのはPHPのバージョンの１つのようなものなのですが、NginxではなくApacheで動作します。
kusanagiだとワンボタンでサービスを変更できるので、変更してみたところ、問題なくサイトが機能した・・・ように見えました。

訪れる謎の高負荷と、サーバダウン

HHVM+Apacheは、HHVMのキャッシュに機能で動作が非常に高速で、サーバ移行前と比べると動作が高速化してめでたしめだたし・・・・かと思いました

が、数時間おきにサーバに謎の高負荷がかかりサーバダウンするという現象が起きました。

とりあえず応急処置としてこまめにHHVMの再起動設定

調べてみたところ、ConohaのKusanagiのHHVMは不安定でときどきダウンすることがあるということでした。

応急処置として、cron設定で１分ごとにHHVMを再起動するように設定しました。
これにより、仮にサーバがダウンしても長時間そのままダウンし続けるという自体は避けることができます。

原因はよく分からないのですが、とりあえず同様の現象の方はいたようで、またあくまで応急処置で、数時間に一度、数分程度サーバがダウンしてしまうということ自体が解消されたわけではなく、さすがにその状況でサーバを運営し続けることは品質面で問題といえます。

そこで、別の方法を検討することにしました。

すると、Nginxに切り替えると安定するということでした。

Nginx+PHP7に再度挑戦

最初にいったんやろうとしてあきらめたNginx+PHP7への移行に再度挑戦してみることにしました。

Conohaのサービスでは、サーバをイメージ保存しておいて、そのコピーのサーバを簡単に作成できるので、HHVMのサーバは残した状態で、コピーしたサーバを作成し、Nginxの設定に変更してテストを行いました。

こういうことがコントロールパネルから簡単にできるのも、Conohaの優れている点です。

カスタムパーマリンクの対応

まず、カスタムパーマリンクが動作しない点については、Nginxは.htaccessが使えないのでNginxの設定ファイルに記述しないといけないということでした。

Nginxの設定ファイルは、nginx.confというファイルに設定されているのですが、このファイルに正規表現を使って様々な記述がされていたので、この設定をサイトごとに設定しました。

この作業は少し手間がかかる作業でしたが、完了することで、無事パーマリンクが機能するようになりました。

PHP7で動作しないファイルの修正

次に、以前のサーバがPHP５で動かしていたので、PHP7になることで動作しないファイルが大量に出現したので、これらのエラーファイルを順に修正していきました。

エラー箇所の特定は、Nginxのエラーログファイルを見ながらエラー箇所を特定し、修正してきました。

これらは運営しているサイトの数が多かったのでかなりの作業量が必要になり、なかなか大変な作業だったのですが、HHVMにしたときに数時間おきに少しの間サーバがダウンするのはサービス品質に対して影響が大きいだろうということでやむをえず行いました。

PHP5の記述とPHP7では、特にデータベース回りの記述が変更になっている箇所が多かったので、修正箇所は多岐に渡りました。

また、WordPressのプラグインも、PHP7に対応していないプラグインは削除したり、ファイルの修正で対応できるものは対応するということが必要になりました。

サーバの移行完了

これらの作業を終えることで、無事Apache+PHP5からNginx+PHP7への移行が完了しました。

つまづいた点としては、

• .htaccessが使えないのでパーマリンク設定をnginx.confに記述しなければならない
• PHP5の記述が一部動作しないのでエラーが起こる点はPHP7で動作するように修正しなければならない

という主に２点になります。

思った以上に移行作業は時間はかかりましたが、結果的にサーバのランニングコストを下げることができ、サイトもNginx+PHP7になったことで高速化したように見えるのは良い点ではないかと思います。

まだサーバが移行したばかりなので予期せぬトラブルはあるかもしれませんが、しばらく様子見したいと思います。

phpのファイルで、特定のファイルをincludeして読み込んだ場合に、謎の空白行が上に1行入る問題がありました。

発生した問題

phpファイルのヘッダの上に謎の空白行が1行表示される

原因の究明方法

まずはchromeのデベロッパーツールでソースコードを調べたが、ソースコード上には何の問題も見られない。
phpファイルのプログラムの行を削除して調べていたところ、特定のphpファイルをincludeした際に改行が入っていた。
該当のphpファイルを調査したが、問題ないソースコードであるように見受けられ、不要な出力や改行、全角文字なども見当たらなかった。

解決策

該当の問題となっていたphpファイルを新規作成して作り直し、同様のコードをコピーペーストして同様の内容とした。
作り直したファイルをアップロードしたところ問題は解消した。

つまり、もともとのファイルを作成した際に、文字コードや改行コードの微妙な違いがあったようである。

詳しい原因は分からないが、作成した時に使っていたエディタや環境と、現在使っている環境（phpstorm)が異なっていたために、微妙な差があって発生していた問題かもしれない。

EC-CUBE３のインストールをローカル環境で試していたところ、ステップ4のインストール時のデータベース設定でエラーが出た。

データベースに接続できませんでした。 || An exception occured in driver: SQLSTATE[HY000] [2002] No such file or directory

データベースはMySQLを使用していて、データベースとユーザは作成済みだったがエラー。

原因はよくわからなかったが、以下の方法で解決した。

ホスト名の部分を

localhost

から

127.0.0.1

に変更

これで通るようになった。

原因はよくわからないが、おそらくローカル開発環境の設定上の問題であろうと思われる。

PHPのプログラムで特定のサイトURLとキーワードからGoogleでの検索順位を取得し、結果を返すプログラムを作りたいと思いました。

理由としては、運営しているサイトの検索順位の日時変動を手動でチェックして記録するというのは手間がかかる作業だからです。

プログラムで実行でき、さらにcronで自動実行し、結果をデータベースに保存するということができれば楽になります。
そういうツールもあるのですが、何かと制限があったり、融通はきかないので。

まず、プログラムで検索順位を取得する方法についてですが、考えられる方法として、Googleの検索フォームにポストで変数を投げて、結果をスクレイピングするというものですが、これは規約によりやるとまずい場合があるということでやめました。
実行回数が多かったり検知されるとIPアドレスをブロックされるということがあるみたいです。
実際にやってないので分かりませんが・・・。

もう１つの方法として、Google Custom Search APIを使用するというものです。
こちらは公式に許可されている方法なので問題はないのですが、無料の場合は１日100クエリまでということで制限が入るようです。

それでこの方法を試してみたところ、一応目的に近いものはできたので、詳細は省略しますが、ざっくりとその過程と、この方法の現状での問題点を書いていこうと思います。

１． Google Custom SearchのAPI keyを取得する

Google Custom SearchのAPIを使用するにはAPI KEYが必要となるので取得します。
方法はネットを探すと出て来る思うのでここでは省略します。

２． カスタム検索エンジンIDを取得する

プログラムの中で使用するカスタム検索エンジンの検索エンジンIDを取得します。
カスタム検索エンジンIDは、カスタム検索エンジンを作成してから、詳細の画面で「検索エンジンID」というボタンを押すと表示されます。
※ 画面はときどき変わってしまいますが、探すと詳細画面のどこかで取得できると思います。

なお、カスタム検索エンジンを作成の際にはどのサイトで使用するかのサイト名を入力する必要があるのですが、作成後に詳細画面から「基本」タブの「検索するサイト」の項目で「追加したサイトを重視して、ウェブ全体を検索する」に設定を変更することで、

３． プログラムを作成する

１．２．のAPI KEYとカスタム検索エンジンIDを作成できればあとは、目的のサイトURLとキーワードから検索結果を取得できます。

プログラムの詳細としては、カスタム検索エンジンに、検索キーワードと、その他のパラメータを引数にしてクエリを作成して引き渡すことで、JSON形式でデータが返ってくるので、それをデコードして解析します。
こう書くとややこしそうですが、プログラムとしてはそれほど複雑ではありません。
以下のサイトが参考になりました。

Google Custom Search APIを使って検索結果のURLを取得する【PHP】 – autofocus onfocus

あとは、それを目的に応じてプログラムをチューニングすると完成です。

私の場合は、複数のサイトとキーワードとサイトで調べたいので、それをテーブルに保存して引っ張り出してきてキーワードとサイトごとに実行して順位を返す。
帰ってきた順位と日付をDBに保存というところまではできました。

問題点

これで一応目的としたものについてはできたのですが問題もあります。

１．無料でのクエリ数の制限

まずは先にもあげたように、無料の場合は１日100クエリまでしか実行できないというもの。
このため、サイトの数やキーワードが増えてくると無料では対応しきれませんので、調べたい数を絞る必要があります。
増やそうと思った場合、１日に追加で1000クエリあたり$5がかかるようです。

２．検索順位が微妙に本家サイトと違う？

あと１つの問題点は、この方法で得られた検索結果と順位が微妙に本家のものと違うということです。
これは理由がよく分からないので、検索結果の厳密さを必要とする場合にこの方法はあまり推奨できないのですが、大まかな目安とする程度であれば問題なく使用できます。
これは、何故検索結果が本家と異なるのかがよく分かっていないので、今後もし原因が分かれば追記しようと思います。

PHPで、Youtubeの短縮URLを、埋め込み用URLに変換して出力する方法についての解説です。

Youtubeの短縮用URLとは、

上記のようなURLで、Youtubeの動画を共有ボタンを押すと表示されて、それをSNSやブログに投稿すると、Youtubeの動画が埋め込まれた状態で出力されます。

これは、例えばそれぞれのブログエンジンや、SNSなどが上記の短縮URLを埋め込み用のコードに変換して出力する仕様になっているのでそのようになっています。

そのため、例えばPHPのファイルで、上記のYoutubeの短縮用URLを受け取ってそのまま出力すると、そのまま短縮用のURLが出力されるだけで、埋め込まれた状態で出力されません。

これをそのまま埋め込み用の動画として出力したい場合は、埋め込み用のURLに変換して出力する必要があり、そのための関数を作ってやると出力することができます。

埋め込み用のコードについてですが、基本的にiframeを使って、先程の短縮URLを一部変形させて埋め込んでやればそのまま出力できるので、それほどややこしい処理は必要ありません。

以下は私の方で作成した関数例です。
関数呼出し時に関数に短縮用URLを渡し、埋め込み用のiframeにしたURLを返却します。
ifameの横幅はデフォルトが560にいていますが、引数として渡すことで大きさを変える事が可能です。

PHPのフレームワークの「Laravel」の勉強メモです。

Laravelとは

PHPのフレームワーク。
日本でも人気が上がってきているが、海外で特に人気がある。
モダンな要素が取り入れられている？

フレームワークを勉強するに渡って有名な「Cake PHP」も良いと思ったのですが、最近人気があるというLaravelについて学習してみることにしました。

Laravelを使用するにあたって

PHPの5.4以上が必要で、「mcrypt」のライブラリをインストール必要がある。

インストールするために「Composer」が必要になる。
ComposerとはPHPのライブラリの依存関係を管理するためのもの。
通常はライブラリはPHP全体に影響するため依存関係の管理が大変だが、コンポーザーの場合プロジェクトごとにライブラリを管理するため依存関係について対処しやすい。

Laravelのインストールと初期設定

インストール時してプロジェクトを作成する。
プロジェクト名のフォルダができ、その中にLaravelの必要なファイル一式がダウンロードされる。

最初にやること

プロジェクトで必要となるデータベースとデータベースユーザを作成する。
データベースが必要ない場合は必要なし。

データベースを作った場合はプロジェクト内のコンフィグファイル内にデータベースへの接続情報を追記する。

「.env　」が環境ファイルなので開いてデータベース情報を追記する。

artisan(アルチザン)のマイグレーションコマンドを使って、テーブルを作成する。
アルチザンというのは、Laravelに予め準備されたシェルスクリプトのようなもので、コマンドラインで様々な処理を実行することができる。

php artisan make:migration マイグレーション名 –create=テーブル名

上記のコマンドを実行することで、/database/migrations/　内にマイグレーション用のPHPファイルが作成される。

作成されたマイグレーションファイルを開いて、テーブルのカラム名などを追記する。
デフォルトでは主キーと、タイムスタンプのカラムが設定されている。

php artisan migrate

コマンドで、マイグレーションが実行され、上記マイグレーションフォルダ内に入ったマイグレーションPHPファイルが実行される。

一般的な方法であれば、phpmyadminからテーブルを作成したり管理するが、Laravelではマイグレーションコマンドと設定ファイルでテーブル構造を管理できるかんじといったところ。

しかし、見た感じややこしい。
こんなマイグレーションを使ってコマンドラインでどうこうするより、phpmyadminを使って管理するほうが簡単な気がしてならない。
このあたりはLaravel使う恩恵は微妙といったところかな…。
いろいろやってると「php artisan migrate」実行時によく分からないエラーが

Base table or view not found:

なんだこれ

php artisan migrate:refresh

これで全部解決しました。すべてのマイグレーションを再実行するかんじかな。

php artisan migrate:rollback

上記はロールバック用のコマンドで、最後に行ったマイグレーションをロールバックする

php artisan migrate:reset

すべてのマイグレーションをロールバックする
まあいずれにしてもややこしい。phpmyadminがシンプルでいいです・・・。

モデルの作成

php artisan make:model モデル名
これでモデルを作成

これで app　ディレクトリ以下に、作成したモデル名のPHPファイルができている。

tinkerコマンドでモデルのオブジェクトを作成して、コマンド形式を使ってテーブルに値を挿入できる。

php artisan tinker

このあたりの命名規則やらなんやらで完全に混乱状態・・・。

ルーティング

このあたりからようやく面白くなってきた。

ルーティングとは、指定したURLに対してどういった動作をするかをphpファイルの中に書き込んでいくこと。

設定方法はLaravelのバージョンによって異なってくる。
自分の環境はlaravelのバージョンが5.3系なので、サイトのルーティングは

/routes/web.php

に行う。
ここに指定したURLに対しての処理を書き込んでいくと、URLにアクセスしたときに指定した処理を行う。
テンプレートを読み込ます場合は、viewファイルを読み込む。

ここで、URLにIDなどの動的なパラメータ（変数）を渡すこともできるのだが、テスト環境(Mac、Appache)では動作しなかった。
確認してみると、 /private/etc/apache2/httpd.conf の AllowOverride All　にすべて変更すると
動作するようになった。（.htaccessはLaraberl上にあるので、サーバの設定が許可する設定になっていないといけない）

view

viewというのは要はテンプレートファイルのこと。

/resources/views/

以下に追加していく。

このテンプレートファイルにhtmlやphpのロジック部分を基本は記述していき、ルーティングファイルから読み込むという流れ。

共通部分のviewファイルは別に作成しておき、個別ページごとのテンプレートファイルから読み込んで変数や動的な部分を埋め込んでいくイメージにしていくと効率が良い。

コントローラー

コントローラーは、サイトの処理を担当する部分。
viewでHTMLのテンプレートを担当し、コントローラーでは処理を担当する。

artisan make:controller コントローラー名

でコントローラーを作成することで、 app/Http/Controllers

以下にファイルが生成されるので、編集することで処理を追加できる。

laravel5.3系の場合、web.phpで、ルーティングでURLで指定した処理で呼び出すコントローラを指定する。

viewとコントローラーを切り分けることで、デザイン(デザイナ担当)の部分と処理の部分(プログラマ担当)を切り分けることができる。

情報処理技術者試験の勉強をしていたら「B+木インデックス」というのが出てきていて、調べていたところ「B木」との違いがよくわからなかったので、メモ。

そもそもB木とは

自分的な解釈。
基本的に、データの検索性を高めるための多分木の木構造でのデータ格納方法。

B木とB+木の違いとは

B+木にはB木と違い以下のような要素があるようです。

・データ格納先のアドレスを末端の葉（リーフ）のみに格納する
・リーフ(葉)とリーフ(葉)を結ぶポインタを設ける

↑B+木の図

逆に言うと、通常のB木はノード（節点）にもデータが格納され、葉と葉と結ぶポインタはないということですね。

ウェブサイトのドメイン変更時に、.htaccessを使ってドメインごと301リダイレクトする場合の記述についてです。

例

example.com　を
example2.comに移転する場合の記述です。

# BEGIN WordPress

RewriteEngine on
RewriteCond %{HTTP_HOST} ^(example\.com)(:80)?
RewriteRule ^(.*) https://example2.com/$1 [R=301,L]

# END WordPress

以上の記述をリダイレクトする前のサイトのドキュメントルートに設置することで、301リダイレクトできます。

リダイレクトした後に、WordPressのデータベースの投稿内に含まれているドメイン名は置換します。以下のSQLで置換できます。

update wp_posts set post_content = replace(post_content, ‘example.com’, ‘example2.com’);

MacのOSアップデートを行うと、自身のMac上に構築していたサーバ環境が動かなくなる場合がありましたので、対処法のメモです。

まず、私のケースでいうと、不具合が起きたのが、PHP+MySQLのサイトです。
(EC-CUBEサイトを構築)

アップデート前は動いていたのが、アップデート後には画面が真っ白になるなどのエラーが起きるようになってしまいました。

私の場合、EC-CUBEでのエラーだったので、EC-CUBEのログファイルを確認

/data/logs/error.log

確認すると、以下のようなエラーが起きていました。

Fatal error(E_USER_ERROR): DB処理でエラーが発生しました。
SQL: [SET SESSION storage_engine = InnoDB]
PlaceHolder: [array (
)]
MDB2 Error: connect failed
_doConnect: [Error message: No such file or directory]
[Native code: 2002]
[Native message: No such file or directory]

要は、DB接続に関するエラーです。

ここで、ネットでいろいろと調べてみたのですが、トラブルシューティングのポイントとしては、

MACは、OSアップデート時に各種設定ファイルを初期化するが、バックアップはとっている

ということです。
具体的には、今回のケースでいえば

Apacheの設定ファイルである「httpd.conf」「php.php」を、アップデート前のファイルと比較します。

ターミナルから、以下の方法で差分を確認できます。

httpd.confの場合

diff /etc/apache2/httpd.conf /etc/apache2/httpd.conf.pre-update

差分の部分を、httpd.confに追加してやります。

php.iniの場合

php.iniは、まず、アップデートするとそもそもphp.iniがなくなっているので、作成から入ります。

cp /etc/php.ini.default /etc/php.ini

これでphp.iniが作成されるので、あとは差分を比較します。

diff /etc/php.ini /etc/php.ini-◯.◯-previous

差分をphp.iniに適用してやります。

これで設定が同じになるので、アップデート前動いていたのであれば動くようになるはずです。

適用した後、

sudo apachectl restart

でapacheを再起動するとOKです。

先日WordPressサイト構築用に、爆速WordPress対応サーバーという「kusanagi(クサナギ)」というサーバを契約してみました。

サーバの設定は

Webサーバがnginxで、PHPがhhvmです。

それで早速使ってみたのですが、WordPressは確かに早くなりました。

ただ、何故か通常のPHPスクリプトの実行に非常に時間がかるどころか、タイムアウトを頻繁に起こす状態に。
特に、軽いPHPの場合は問題なく処理できるのですが、大きいファイルサイズのPHPの場合は頻繁にタイムアウトを起こしてしまう自体に・・・。

それで、nginxの設定とひたすら格闘していたのですが、何とか原因がわかりました。

このkusanagiというサーバ特有の設定で

fastcgi_buffers 8 256k;

という設定が設定ファイルの中に入っていたのですが、よくわからないのですが、この前半の「8」というのが小さい値すぎたみたいで

fastcgi_buffers 800 256k;

とか大きいサイズにしたら問題なく動作するようになりました。

サイズに関しては環境によって適切な値が異なると思うので、一番あった値に調整してみてください。

EC-CUBE3.0のインストールまでについては前回の記事でやってみました。

今回はカスタマイズについてどう変わったのか検証してみたいと思います。

テンプレートの修正

まず、テンプレートの修正については、EC-CUBEの管理画面から行うことができます。

旧バージョンと比べてナビゲーションが左側になっていますが、ここから編集したいページやブロックを選択するのは同じです。

レイアウト編集かページ編集を選択します。

レイアウト管理の画面です。
ここは、EC-CUBEの旧バージョンとほぼ同じです。

次にページ編集画面を見てみます。

テンプレートの記述方式が、以前のSmartyからTwigに変更になっているため、記述が少し変わっています。
ただ、基本的にはHTML部分＋変数部分という意味では同じなので、記述方法が変わっているだけで大きく変わったという印象はありません。

また、author、description、keyword、robotsなど、ページごとにmeta設定を書くことができるようになっています。

以前のEC-CUBEを触ったことがある人であればそれほど難しくはないでしょう。

プログラムのカスタマイズ

さて、続いてはプログラマの人に関しては重要なプログラムのカスタマイズ方法について見ていきます。

まず、テンプレートエンジンがTwigに変更されているので、プログラムの構成がかなり変わっています。

以前は、カスタマイズをする場合は
/data/class/ 以下、または　/cata/class_extends/　以下のフォルダを修正していましたが、フォルダ構成が大幅に変わっています。

プログラムの動作部分のファイルは「src/Eccube」以下にあります。

言語がPHPと、オブジェクト指向で、またテンプレート部分とロジック部分を切り分けて作られているというのは旧バージョンと同様です。

どうやってカスタマイズするかは、カスタマイズの内容によって異なるので何ともいえませんが、ファイル名でおおよそのあたりは付くようになっています。

問い合わせ＝ContactController.php
購入＝ShoppingController.php

など…。

データベースの構成に関しては、基本的に変わっていない印象を受けました。

データベース構成はほぼそのままに、プログラムのロジックの部分はほぼ丸ごと作り変えられたかんじになっています。

この部分に関しては、Twigのほうがカスタマイズをしにくいというのではなく、古いバージョンに慣れた人であれば、はじめはTwigのプログラムを理解するのにある程度苦労するものと思われます。

カスタマイズにプラグインを使用する

EC-CUBE3.0は、カスタマイズするのにプラグインを使用できます。
しかし、公式サイトを見ても、今のところプラグインは２系に対応したものしかないようです。
そのため、プラグインに関しては、今後３系に対応したプラグインが開発されるのを待つしかなさそうです。

総括

テンプレートとデータベースに関しては、あまり旧バージョンとの違いはありませんが、プログラムのロジックの部分が旧バージョンからTwig用にほぼ作りなおされているので、プログラマの人は旧バージョンに慣れていると、おそらくはじめはカスタマイズに苦労するのではないかと思います。
また、カスタマイズできるプラグインも３系に対応したものがまだでていないので、今作るのであれば２系で作ったほうが簡単かもしれません。
ただし、２系に関してはいずれサポートされなくなり、今後の開発も当面は３系で進んでいくと思われますので、どこかのタイミングでは、新規でサイトを作るのにEC-CUBEを使用する場合は３系を使うようになっていくことが予想されます。