2019-09-23

kaggle の kernel で、 albumentations.torch が使えなくなった

結論

from albumentations.torch import ToTensor

ではなく、

from albumentations.pytorch import ToTensor

で呼び出さなくてはならない。

背景

画像関連の機械学習でよく使うデータ拡張をまとめた albumentations に、日頃からとてもお世話になっている。

github.com

検索すると色々出てくるし、公式のdocument も充実しているので、ここで使い方を紹介することはしない。ただ、pytorch と組み合わせて使う際に必要な処理の呼び出し方が変わっていたから、一応記事を書くことにした。
こんなのは、ちょっと調べれば出てくるし、1ヶ月後には常識になってるんだと思うけど、
Twitter に書くだけじゃ自分が忘れてしまいそうだったので。

参考

www.kaggle.com

まさにtips だから、qiita にも後で上げておこう。

2019-07-14

Goodby iPhone XS

ついに、Pixel 3aを本格的に使い始めた。今まで約8年間iPhone に固執してきた僕にとって、これは大きな一歩だ。

本当は、5月中旬に手に入れていたが、なかなか iPhone を手放す踏ん切りがつかなかった。
嫌だった理由の大きな要因がApple Watchだった。
Apple Watch はAndroid と連携することができないので、Apple Watch も外さなくてはならない。
そうすると、iPhone と Apple Watch を売る手間がかかる。ゴミ箱にぽいと捨てられるような値段ではないし。かといって売るのはめんどくさい。メルカリに出したらめっちゃ値切られて嫌な思いするし。あの値引き交渉について思うところはあるが、ここでは本筋とブレるので割愛する。
大した本筋ではないが。

そんなことをあれこれ考えていたときに、iPhone を譲って欲しいという知人と、Apple Watch を譲って欲しいという知人が別々に現れ状況が一転した。
どちらも一気に手放せるなら晴れやかな気分でスマホも時計も Android に乗り換えることができる。
ということで、両者に承諾の連絡をした。

先週、先に Apple Watch が僕の手元を離れた。 1日スマートウォッチをつけない生活をしてみたが、睡眠トラッキングができないことにとてつもない不安を感じた。
なくなってわかる重度の依存。悩んだ末、rebuild.fm で昔紹介されていたAmazfit を購入した。

www.tjc-jp.com

そして、Amazfitが届いた日に、sim を iPhone XS から抜き、Pixel 3a に刺した。

今の所、一点を除き大きな不満はない。
ただ一つの不満は、 Mac のロック解除が面倒になったことだ。今までは Apple Watch を使ってロック解除を行っていたのに、
わざわざTouch ID に指を置かなくてはならなくなった。
これが不便極まりない。
この際、Windows に移行するか？ｗ

会社では Beats のワイヤレスヘッドホンを使っているので、その接続周りでも不満が噴出することが想定される。
でも、それは早くても明後日の話。
とりあえず次の iPhone が出る頃までは Pixel 3a に頑張ってもらおうと思う。

Goodby iPhone XS...

2019-07-14

WF-1000XM3 を買った ~拝啓 sony のご担当者様へ~

sony の新ヘッドホン、WF-1000XM3 を買った。

www.sony.jp

昨日、ソニーの新しいイヤホン WF-1000XM3 を買った(発売日！)。ワイヤレスでかつノイズキャンセリングが搭載されているスグレモノ。とりあえず1日使ってみたがとてもよい！！

自分はAirPodsやその他のワイヤレスイヤホンを使ったことがないので比較ができるわけではないが、感想を書いていこうと思う。

良かったところ

ノイズキャンセリングすごい！

ワイヤレスイヤホンのノイズキャンセリングってこんなにすごいのか！と感動した。
今までノイズキャンセリングイヤホンを使ったことがないのできちんと比較はできないが、めちゃくちゃすごい！
どのぐらいすごいかと言うと、beatsのヘッドホンと比べても遜色ないぐらいすごい！

www.apple.com

自分は汗っかきなので、町中でヘッドホンを付ける訳にはいかない。
特に今の季節。何度か試したけど無理だった。
イヤホンならその問題は(たぶん)起きない。夏がくるのがちょっと楽しみになった。

USB Type-C

おそらくこれはAirPodsを真似たものなのだろうが、イヤホンがケースにしまってあり、そのケースがイヤホンを充電する。そして、そのケースを USB Type-C で充電する。
この Type-C というのが評価が高い！
まだ電池が切れるまで使用してはいないのでバッテリー持ちの話はできないが、
公称6時間持つので、おそらく東京 - 福岡間のフライトぐらいなら問題ないぐらい持ちそうだ。
2時間程度使ってバッテリー 70% だったので、あながち間違ってはいないと思う。

タッチコントロールと操作性

これもおそらくAirPodsを真似たものなのだろうが、イヤホンにタッチセンサーが付いていて、デフォルトでは右のイヤホンをタッチすると音楽やpodcastの再生を止めることができ、左のイヤホンをタッチするとノイズキャンセリングをオフにできる。
タッチセンサーの挙動は、専用アプリである程度コントロールすることができるらしい。
また、耳からイヤホンを外すと自動的に音声がOFF になったりイヤホンをケースに戻すときに磁石がいい感じで仕事していたりと、AirPods の影を感じるｗ

Googleアシスタント

Googleアシスタントと連携できるらしい。
まだ自分は連携していないが、便利なのかも知れない。
何分後に雨降りそう？とか聞いてみたい。

悪いところ

今回このイヤホンを買うことをを決断した理由は、iPhoneとApple Watchから離れることをにしたからだ。今まで約10年間iPhoneを使い続け、仕事でもMacを使用している。そのため、音楽を聴くデバイスも、自然とbeatsを選択するようになった。しかし、アップル製品は非常に便利な反面、アンドロイドユーザの気持ちが全くわからないことに気づいた。そこで、今まで無意識下で選択していたApple製品を離れ、Apple以外の製品に目を向けることにした。今から、製品と顧客体験の悪かったところを書くが、基本的にはAppleとの比較だ。

設定がめんどくさい

Beats の設定はめちゃくちゃ簡単だ(iOS との接続限定)。製品を買ってきて電源ボタンを長押しするだけでiPhoneとペアリングできる。
それに比べると、本製品はアンドロイドアプリをダウンロードしないと設定が始まらない。これで文句を言うのは若干可愛そうな話ではあるが、アップル製品の凄さを感じた。

購入が面倒

いくつか商品の購入体験が悪い部分があったので書いておく。
このブログをsonyが見つけることはないと思うが、届けばいいなと願っておく。
今年は七夕の短冊を書いていないので、短冊代わりで。

入店時

発売日を完全に忘れていたので、sony ストアに直接出向いて商品を購入した。
店内は割と空いていて、特に並んでる様子もなかったので店員に WF-1000XM3 を買いたい旨を伝えた。
すると、 試着しなくて大丈夫ですか？ と聞かれた。はじめ、意味がわからなかった。自分は買うと言っているのになぜ試着を勧めるのか？
少し戸惑った後、"買います"と再び伝えた。
なぜ試着を勧めれたのかは後々わかることになる。

購入時

店舗の奥に進み、席に座るよう指示された。この時点でめんどくさい。スマホを買うときみたいだ。。。そして、ソニーのアプリをダウンロードしてログインしろと告げられた。その工程を経ると、2000円オフになるらしい。そんな割引が受けられるなら、ダウンロードしてログインするしかない。さらに、アンケートに答えると500円オフになると言う。その後、各種保険の説明とかされて、結局製品を手に入れるために約15分かかった。せっかく新しい製品を買ったのによくわからない不快感を感じた。

嫌だったこと

ヘッドホンの設定がめんどくさいのは仕方ない。なので、顧客体験のどこに違和感を感じたかを書いていく。

入店時

買うと決めているものを買いに来たのに、試着を勧めるれるのは意味がわからない。
せっかく sony が "業界最高クラスのノイズキャンセリング性能(完全ワイヤレス型ノイズキャンセリングヘッドホンにおいて)" と銘打って発売した、
世界で最高の ノイズキャンセリング機能付き完全ワイヤレス なのに、なぜ試着する必要などあるのだろうか？
迷っている人に試着を進めるならわかる。でも、買うと決めている人に試着を勧めるのは明らかにマイナスだ。

だめな理由はこんな感じ。

事象	結果	確率
試着なし	買う	100%
試着なし	買わない	0%
試着あり	買う	90%
試着あり	買わない	10%

試着をしなかったら必ず買う人も、試着をすることによって買わなくなる可能性がある。
だったら、試着なんてさせずに買わせたほうが良い。

おそらく、店員さんもびっくりしたのだと思う。
察するに、買うと決めてくる人は少なく、迷った末に買う人が多いのだろうと思う。
そして、試着を勧めるのは、迷っている人に買わせるためには最適な手段だと思う。

事象	結果	確率
試着なし	買う	0%
試着なし	買わない	100%
試着あり	買う	10%
試着あり	買わない	90%

でも、自分に対して試着を勧めたのは明らかに間違いだ。

購入時

上述の通り自分はApple 製品をたくさん使ってきた。オンラインで購入したものもたくさんあるし、Apple Store で購入したものもある。
Apple Store の体験が最高だとは全く思わない。
死ぬほど列に並ばされるし、土日だと購入まで2時間かかることもある。
なので、トータルで考えるとソニーストアの方が製品を手に入れるまでにかかった時間は短い。だからこそ、そこで差別化すべきなのではないかと思う。せっかく並ばずに商品を買えるなら、その商品を買うまでの時間を圧倒的に減らせばよい。そうするとApple Storeは待たされるが、ソニーストアでは迅速に製品が手に入るという良い顧客体験を得ることができる。しかし、今のやり方では印象が悪くなる事はあれ良くなる事は無いように思う。そんなことをする位なら最初から2000円引きにしてくれればいいのにと強く思う。

あと、500円OFF のアンケートが試着に関してだった。
これが試着を進められた理由だったのだ。
そのアンケートもかなり作りが悪い。
せっかくアプリを(4G回線で)インストールしてログインにもかかわらず、
独自のフォームで作っているのでWeb 経由で再度ログインしないと使えなかった。
500円払って得られた情報と、500円払って顧客に与えたマイナスの印象。
自分にとっては後者のデメリットのほうが大きいと思う。
特に急いでいたので辛かった。かといって、その500円を断るほど自分は裕福ではない。
いろいろ悲しくなった。

結論

製品は神。35000 円でも売れると思う(Podcast聞くぐらいなので音質とかは知らないが)。ただ、sony ストアでの顧客体験は正直よくなかった。もっと自社の製品に誇りを持ってほしいと切に願う。

2019-07-01

PHPカンファレンス福岡2019 に参加した

2019/06/29に福岡ファッションビルで開催された、PHPカンファレンス福岡2019 に参加してきました。
今回は、一般参加枠でした。
参加したイベント(非公式含)は、以下の通り

エールズ祭り金曜日 (PHPカンファレンス福岡2019前日）
PHPカンファレンス福岡2019 本編
PHPカンファレンス福岡2019 懇親会
PHPカンファレンス福岡2019 非公式二次会
エールズ祭り土曜日 (PHPカンファレンス福岡2019当日）
FUKUOKA CRAFT
(非公式)PHP Conference Fukuoka 2019 After Hack!!
PHPカンファレンス福岡最終イベントhamaco祭り(https://twitter.com/cakephper/status/1145320193473650688)

と、盛りだくさんの3日間でした。
一方、都合で【非公式】PHPカンファレンス福岡2019前夜祭リジェクトコンのが残念でした。
来年は是非参加したいと思います。

よくお見かけする方、久々にお会いした方、初めて拝見する方等、いろいろな方とお話する機会がありました。
時系列に沿って振り返ろうと思います。

エールズ祭り金曜日 (PHPカンファレンス福岡2019前日）

例年PHPカンファレンスの前夜と当日は、ガストロパブエールズというお店に各々集まって、
ビール(とかワインとかウイスキーとか)を飲むというイベントがあった。
今年はそのイベントの参加者をコンパスで募集し、飲み放題にする方針になった。
残念ながら写真は一枚もないが、1日目は35人ぐらい集まってワイワイ楽しんだ。
来年もきっと行われるので、特に初めて福岡に来る人にはおすすめだ！！次の日少し眠いというリスクと引き換えに、莫大なリターンが期待できる。

エールズ祭り金曜日のあとは、恒例の元祖長浜屋。
恒例なのに今年は自分と@uessy_akrしか参加者がいなかった。
まあ、人数に関係なく楽しめるのが元祖なので、全然問題ないけど。

カンファレンス本編

いろいろなセッションが行われていたが、残念ながら今回は殆ど参加しなかった。
今年は自分の発表がないからこそ、発表中にどのようなことが行われているのかを知りたかったからだ。
所属している会社がスポンサーをしているので、そのスポンサーブースに立つ仕事をしてみたり(結局知り合いとしか話してないが)、
ロリポップからの挑戦状に挑んでみたりした。
特に、新企画 "ロリポップからの挑戦状" は、白熱した(?) バトルが繰り広げられていて面白かった

コードゴルフとセキュリティチャレンジが行われており、自分はコードゴルフに参加した。途中までは最高スコアを更新したりしていたが、最終的には大差で負けてしまった。
ちょっぴり悲しかったが、3時間無我夢中で楽しめたのでとても面白い体験だった。

この挑戦状の問題は、翌日Fusic で行われたAfter Hack で、題材に取り上げられ大いに盛り上がった。

カンファレンス懇親会

懇親会では、多くの方と話す機会があった。
そして、これは自分の悪い癖だが、知っている人とばかり話してしまう。
その結果、話した多くの人とエールズで再会した。
もっと知らない人と話せばよかった。次回は、xxさんと話すという目標(?) みたいなのを持って参加しようかな。

カンファレンス非公式二次会

懇親会のあと、美味しいビールが売っているお店に20人ぐらいで流れ着いた。
そこでこの伝説のギャグ(?) が生まれたのだった。

『これ俺が言ったらバーン！ですよ』 .@soudai1025 さん#phpconfuk pic.twitter.com/Lwc8JBg0HH
— ナコ先輩 (@nako0123) June 29, 2019

一方的に存じ上げていた@_nabeen に挨拶するなどもした。

エールズ祭り土曜日

エールズ祭り金曜日を凌駕するほとの人数が集まっていた。本当に、足の踏み場もないぐらいｗ
だけど、お店の対応はスムーズで、グラスが空になるとすぐにビールが補充された。
ありがとうございました！

FUKUOKA CRAFT

そろそろ帰ろうかなんて思っていたが、@kis さんの一声で次のお店が決まった。
"リスクを取りましょう！" を掛け声に、これでもかと言うぐらいご飯をたのんだｗ
どれも美味しかった。パクチー以外は。
なんか、納豆 = 弁当のバランとかなんとかそんな話をしていた気がする。よっていたのであまり覚えていないがｗ
2時頃まで飲んだところで解散。ただ、自分は参加していないがどうやらその続きがあったらしい。。。

今の状況一言でまとめると、寝過ごしアウト、となる
— sji (@sji_ch) June 30, 2019

(非公式)PHP Conference Fukuoka 2019 After Hack!!

Fusic という福岡の会社が毎年やっている、After Hackに参加した。ここで一番盛り上がったのが、前日にPHPカンファレンス本編で行われたコードゴルフ。
お題は、Web サイトの表示を変えずに表示するのに使うコード(正確には /var/www/html 以下においてあるファイルサイズ)をへらすこと。当日は @m3m0r7 の優勝で幕を下ろしたが、もっと時間があれば！！！と思っていた人も少なくなく、
あの手この手でコード量を削っていったのでした。
そして、ついに 0B に到達！

#phpconfuk 今日のゴルフのホールアウトスコアです、ありがとうございました。 pic.twitter.com/eOWEGxtt8y
— uzulla (@uzulla) June 30, 2019

これは(おそらく)レギュレーション違反だがｗその後も、同時に行われていたセキュリティチャレンジの感想戦をやったり大いに盛り上がった。
来年もやるのでぜひ来てください！(After Hack という名前怖い説があるらしいですが、ホント楽しいだけの回なのでぜひ！！！)

PHPカンファレンス福岡最終イベントhamaco祭り

After Hack のあとは、月曜日に飛行機をとっている @hamaco と一緒に飲みに行く会が開かれた。一緒に行っていた @seike460 の電池が切れる瞬間を観測したりして、いろいろ面白かったｗ焼き鳥とかビールとかラーメンとか。福岡っぽい(と東京の人が感じるであろう)ものをいろいろ食べた。
このイベントも来年も開催予定なので、福岡延泊される方はぜひ声かけてください！！

謝辞

こんな、濃厚な3日間を過ごせたのも、ひとえに @tsubakimoto_s を委員長とするスタッフの方々のおかげです。
本当にありがとうございました！！こうして振り返ってみると、PHPカンファレンス福岡を中心に様々なイベントが層をなしていることが実感できます。
そして、PHPカンファレンス福岡という屋台骨がしっかりしているからこそ、その周りのイベントが覆いかぶさって盛り上がっているのだなと感じました。
とても楽しかったです！！！

来年に向けて

同僚である@seike460が2020年の実行委員長を担当することが発表されました。
敬意と祝福を胸に、影から見守っておきたいと思います。来年もとても楽しみにしています！！！

2019-03-01

はじめてのPHPプロフェッショナル開発を読んだ

書評なんて偉そうなことを言える立場ではございませんが、
購入し本日届いたのでざっと感想のようなものを書いていきます。

f:id:adiboy:20190228232941j:plain — 買った本

全体の感想

PHP の歴史やPSR の説明、DockerやCI、静的解析ツールの使い方などモダンな開発環境が紹介されている
Slackの紹介や障害との付き合い方など、実際に開発現場でしか味わえないような内容も書いてあり、親近感が湧く
解説がとても丁寧なので、独学の人にも学びやすそうに思える
普段業務で使っている内容を公開してくれている感がある(CakePHPやTravis CI, コンテナの運用など)

読んでいて著者の一人がブログでおっしゃられている内容を確実に実現している本だと感じました。
itosho525.hatenablog.com

裏を返せば、

完全なる初心者向けではない
フレームワークの使い方に特化した内容ではない
帯に短し襷に長し(失礼だけど、御本人がおっしゃってるので泣)

ということを念頭に置いて読まなくてはなりません。
自分も1~2時間ぐらいでサラッと読むような感じだったので(休みの日にサンプルコード動かしてみます)、自分よりも熟練の人にとっては物足りないかと思います。

では、この本は誰におすすめか。
それはまさに、これから入ってくる新人の方たちです(上から目線ですいません)。
この時期に発売されたのも、会社に入ってくる新人の人たちを狙い撃ちにしている感じがします笑
これは全然悪い意味ではなく、この本を人数分買って渡しておけば、勝手にぐんぐん成長してくれることでしょう。

自分の勝手な妄想ですが、

現状モダンな開発ができている組織

幅広い知識が必要ですが、この本で網羅的に(広く浅く)触れられているので、
必要性・重要性の説明、Hello World ぐらいまでの教育コストが削減できると思います。

モダンな開発にこれから取り組みたい

新人にモダンな開発手法があることを学んでもらい、「これは、最新の本にも書かれていない高等テクニックですか？(煽り)」的な感じで追い立てられることで組織全体にモダンな開発が広がる(妄想強め)

というような効果が期待できると思います。

あと、これはあまり大きな声では言えないことなのですが、
入社した会社が、モダンな開発をできているかどうか？を測る物差しにもなると思います。
自分の会社は他の会社と比べて開発しやすい環境にあるのか？
ということを知ることができる本です。

もちろん、5年目の人がよんでも10年目の人が読んでも学びはあるでしょう。
しかし、上記のような理由で新人の方にぜひ読んでいただきたい本です。
全国にあるPHPの会社に入社する新入社員の分だけ売れることを願ってやみません。

細かい感想

しっかり読んだ章、さっと読み飛ばした章などばらつきがあるので、
読んだところはしっかりと、飛ばしたところは正直に書いていこうと思います。
また、いくつか自分はこうしてるといった補足情報なども書いていこうと思います。

導入編

Chapter01　進化するPHP

01-01　PHPの歴史
01-02　PHPの特徴

自分はPHP の歴史についてほとんど何も知らなかったのだということを実感させられました。
<?= ?> のシンタックスは PHP5.4~ なのか、など、興味深い発見がありました。
誰かの伝記を読んでいる感じでした。

Chapter02　PHPのエコシステム

02-01　モダンなPHPを支えるコミュニティの力
02-02　PHP-FIGとPSR
02-03　PHPのパッケージ管理
02-04　PHPのアプリケーションフレームワーク

PSR は、名前はよく聞くしなんとなく知っていたけど、
何種類あるのか？などということは恥ずかしながら知らなかったので、とても勉強になりました。
逆にこの辺は、何年かPHP を触っている不勉強な人間が読んだほうが面白いと思います。

Chapter03　PHPをはじめよう

03-01　エディタ
03-02　DockerでPHPの開発環境を整える

自分はPhpStorm を使ってます。
あと、開発環境構築も丁寧に解説されており、これならあまりつまずくことなく環境構築ができるのではないかと感じました。

Chapter04　モダンPHPの文法と基礎文法

04-01　基本的な構文
04-02　型と演算
04-03　分岐処理
04-04　繰り返し処理
04-05　関数
04-06　PHP7の新機能

不勉強ながら、PHP7 の新機能の中には知らないものもあり、大変勉強になりました。
早速明日から使っていこうと思います。

入門編

Chapter05　チームのための開発環境構築

Chapter06　設計から始める

Chapter07　CakePHPを使ってみよう

Chapter08　質問と回答機能の実装

Chapter09　ユーザー管理機能の実装

Chapter10　テストコードを書く

ごめんなさい。ぜんぶ飛ばしました。
ほとんど見たことあるような内容だったので。。(ここを飛ばしたのがサラッと読めた原因というか理由) 後日動かしてみます！

　実践編

Chapter11　チーム開発の現場

11-01　個人開発とチーム開発の違い
11-02　GitHubを使った課題の「見える化」
11-03　Slackを使った日々のコミュニケーション
11-04　ツールの選定方法

自分がこの業界に入ったのは、Rebuild.fm で聞く話にワクワクしたからという部分が大きいわけですが、
この章の話は、その頃の気持ちを思い出させてくれるような生き生きとした内容でした。

Chapter12　Pull Request 駆動によるコードレビュー

12-01　コードレビューの必要性
12-02　Pull Requestを利用したコードレビューの方法
12-03　コードレビューをしてみよう

この章は、チーム開発をしたことがない人に特におすすめだと思います。短いですがｗ
LGTMの解説があったのは笑いました！

ちなみに、typo 見つけましたｗ

f:id:adiboy:20190228233045j:plain — typo

Chapter13　開発に役立つツール

13-01　なぜツールを使うのか
13-02　PHP_CodeSniffer:コーディング規約チェックツール
13-03　PHPStan: コード解析ツール

このあたりは、必読だと思います。
ちなみに自分はScrutinizer というサービスを使って静的解析をやってます。
PHP_CodeSniffer は、git の pre-commit に入れてます(ときどきめんどくさくて切ってるのは墓まで持っていく内緒のうちの一つです)。

scrutinizer-ci.com

Chapter14　継続的インテグレーション

14-01　なぜ継続的インテグレーションが必要なのか
14-02　CIツールとは
14-03　CIを利用してみる

自分はCircle CI を使ってます。
ただ、せっかくなのでTravis CI も触ってみようと思います。

Chapter15　デプロイの自動化

15-01　Webアプリケーションの公開
15-02　ソフトウェアのデプロイメントサイクル
15-03　デプロイ自動化のメリット
15-04　コンテナベースのビルド&デプロイ
15-05　コンテナのデプロイサイクル
15-06　コンテナのデプロイを楽にするオーケストレーションツール

ここが一番の驚きでした。
普通にコンテナを運用されてるんですね。
もちろん要件にもよりますが、自分はアプリケーションをコンテナで運用した経験がないので、とても興味深かったです。
Ansible + Deployer といったタイプの(なんと呼べばいいのかわからない)話も併記しておいてほしかったなと思います。
そんなこと言ってる時点でもはやモダンではないのかもしれませんが。

発展編

Chapter16　障害と向き合う

16-01　障害は突然やってくる
16-02　障害についての重要な考え方
16-03　障害と向き合うためのツール

自分はこのあたりを利用しています。(いつもお世話になっております) github.com

github.com

Chapter17　SQLチューニング

Chapter18　PHPとセキュリティ

このあたりは、Web システムを語る上では外せないという理由で入っているのでしょうが、
それぞれの内容で本が書けるぐらい奥が深い話なので、より詳細な本へのイントロといった内容だと思います。
ただ、書いてある内容は厳選されており、知らないと話にならないような内容なので、とても重要だと思います。

Chapter19　外の世界に飛び出そう

19-01　OSSへの貢献
19-02　最新情報のキャッチアップ
19-03　更にその先へ

いやー。いいこと書いてありますね。
自分は最近全く登壇できていない(というか、勉強会にも行っていない)ので、一度初心にかえろうと思います。

ということで、ざっとではありますが、感想を書かせていただきました。
明日出社したら、早速新人教育の担当に渡してみようと思います。

すべての新人PHPer がこの本を手に取り、素敵なスタートダッシュを切れることを願ってやみません。

2019-02-16

自作のValidatorを使う

CakePHP

CakePHP のドキュメントには、再利用可能なバリデーターを作成するという説明書きがあります。
~~PR を送るのは後回しにして~~ 今回の記事では、その使い方を書いていこうと思います。

ドキュメントに書いてあるコードはこんな感じです。

namespace App\Model\Validation;

use Cake\Validation\Validator;

class ContactValidator extends Validator
{
    public function __construct()
    {
        parent::__construct();
        // バリデーションのルールを加える
    }
}

なるほど。ContactValidatorというバリデーターを作ることができるのかということがわかります。つまり、この機能を使うと、

public function __construct()
{
    parent::__construct();
    $this
        ->scala('name')
        ->requirePresence('name')
        ->notBlank('name');
}

という書き方ができるようになります。

これをうまいこと呼ぶと、いつもモデルで書いているおなじみの、

class UsersTable extends Table
{
    public function validationDefault(Validator $validator)
    {
        $validator
            ->scala('name')
            ->requirePresence('name')
            ->notBlank('name');

        return $validator;
    }
}

が、

class UsersTable extends Table
{
    public function validationDefault(Validator $validator)
    {
        return $validator;
    }
}

というふうに書けそうです。では、$validator を ContactValidator に変更するにはどのようにすればよいのでしょうか？

答えは、モデルの設定にあります。

use App\Validation\ContactValidator;

class UsersTable extends Table
{
    // この行を追加
    protected $_validatorClass = UsersValidator::class;

    public function validationDefault(Validator $validator)
    {
        return $validator;
    }
}

$_validatorClass というプロパティに呼び出したいValidator をセットします。あとは、自動でいい感じに $validator が ContactValidator のインスタンスに差し替えられます。

これを使うと、明示的に宣言しつついい感じでValidation を隠蔽できます。更に、Behavior を new する必要すらないので、テストが(前回よりも更に)書きやすい！

ちなみに、

public function validationAdd(Validator $validator)
{
    // default とは違う処理
    return $validator;
}

という処理を書きたいことがあります。そんなときは、

use App\Model\Validator\UsersAddValidator;

class UsersTable extends Table
{
    protected function createValidator($name)
    {
        if ($name == 'add') {
            $this->_validatorClass = UsersAddValidator::class;
        }
        return parent::createValidator($name);
    }
}

という感じで、$this->_validatorClass を上書きしてあげると良いでしょう。

2019-02-01

Migration に書く処理を共通化した親クラスを作りたい

CakePHP3

CakePHP3 のマイグレーションについて

CakePHP3 は、デフォルトで Phinx というマイグレーションツールを使用しています。

docs.phinx.org

マイグレーションファイルの雛形は以下のようになっており、

$ bin/cake migrations create MyCustomMigration

これを実行すると、

config/Migrations/20160121164955_my_custom.php

というファイルが作成されます。

ファイルの中身は、

<?php

use Migrations\AbstractMigration;

class MyCustomMigration extends AbstractMigration
{
    public function change()
    {
    }
}

のようになっています。

今回の話は、 extends AbstractMigration を変更したいという話です。

やるべきこと

親クラスを作る

config/Migrations/AppMigrations.php

<?php
namespace Config\Migrations;

use Migrations\AbstractMigration;

class AppMigrations extends AbstractMigration
{
    protected function commonUtil()
    {
        // 共通処理
    }
}

ドキュメント https://book.cakephp.org/3.0/ja/migrations.html#id2 にある通りに、カラムの情報を書こうとすると、けっこうコードが長くなるので、割と共通化のしがいがあります。
特に、オプションとかは共通なものも多いでしょうし。

親クラスを継承する

config/Migrations/20160121164955_my_custom.php をちょこっと編集します。

<?php

// use Migrations\AbstractMigration; # 消す
                                                           
class MyCustomMigration extends AppMigrations // ← 変更する

composer.json を編集

    "autoload": {
        "psr-4": {
            "App\\": "src/",
            "Config\\": "config/" # この行を追加！
        }
    },

composer.json の autoloadに Config を追加します。

composer install

composer install をします。
これにより、 Config という名前の namespace が認識されます (詳細はよくわかってない)

以上！ここまでできたら、Migration を実行できます。

そこそこめんどくさいですが、別で class を作ったりすると、いちいち $table を渡さなくてはならなかったりして見た目が美しくありません。

Trait を使ったり、Plugin を使ったりと、他にも色々な方法はあると思いますが、
特定の案件だけで用いる特殊な処理を共通化したい場合は今回のように親クラスを作ってあげるとさっと進めて良いのだろうなと思います。

結論

背景

参考