よみかきをしよう。

たくさんよんだりかいたりしようとおもいます。

#phperkaigi 2020 に行ってきた(day2)

day0day1 に引き続き行ってきました。

phperkaigi.jp

聴いたセッションのメモは以下にまとめてあります。必要に応じてご笑覧ください。
scrapbox.io

PHPerKaigi 、参加するのははじめてだったんですが、とっても楽しめました。様々な工夫がしてあるというか、コミュニティとしてワークしてる感がおもしろかったです。

今回はあまり強みを持てずに参加したこともあって、ガツガツコミュニケーションできるようなかんじではなかったのですが、それでも話しかけてくださった皆様、ありがとうございました。
次回はLTでもよいから登壇する側として参加できるように努力したいな、と思っています。

また、会社としてスポンサードしているカンファレンスだったのですが、会社のみんなとカンファレンスを巡れるのもとても楽しかったです。日常的な安心感と非日常的な刺激がそれぞれあるかんじで。

f:id:plane25:20200215151330j:plain
発表の瞬間、めちゃよい賞品だったので「やったー!」と思わず叫んでしまった

PHPerチャレンジ、なんと22位で賞品いただいてしまいました。ありがたや...
地味に1-2年前からルービックキューブに興味を持ち始めてたんですが、プロ仕様のルービックキューブ持ってなかったので非常にありがたくいただきました。マグネットの力でスチャっと収まる感じがすげえよい。

というわけで、来年も参加したいです!!!ちょっとは強くなって登壇するぞ!!!!!

#phperkaigi 2020 に行ってきた(day1)

昨日 に引き続き行ってきました。

phperkaigi.jp

それでは、ハイライトでお送りします。

f:id:plane25:20200210121719j:plain
これが...

f:id:plane25:20200210121823j:plain
こうじゃろ?(今半の銀鱈弁当)

以上です。最高でした。

お茶会も含めてごはんおいしかったです。

ちなみに、セッションのメモとかは以下のScrapboxにまとめてあるので、ご興味あればご覧ください。uzullaさんのレンサバ話とかヤバかったですし、きんじょうさんのお話も今後定義としてたくさん利用させていただきたい内容でした...ほくほくしてた。 scrapbox.io

#phperkaigi 2020 に行ってきた(day0)

いってきました。

phperkaigi.jp

 

f:id:plane25:20200210101644j:image 前夜祭でFREE BEERだったのもあいまって、軽く自滅していました😇

 

 

f:id:plane25:20200210101932j:image

会社のメンバーと一緒に行ったんですけど、そのうちの @itosho さんは登壇もこなしてました。おつかれさまです!!

 

f:id:plane25:20200210102205j:image

トレカもらったんですが、割とつよいらしい(はせがわさんお墨付き)だったのでお会いした方は交換しましょう!!!

 

聴いたセッションのまとめというかメモをScrapboxに公開してるので、少しでも参考になれば🙏

scrapbox.io

 

コネヒトに入社したことでCakePHPをはじめて触ってみたんですが、その感想を述べてみます。

このエントリは、 コネヒト Advent Calendar 2019 の6日目のエントリです。

qiita.com

はじめに

今年7月にコネヒトに入社しまして、5ヶ月ほど経過しました @takoba です。

コネヒトではサーバーサイドの主要言語としてPHPを採用しており、その上で採用しているアプリケーションフレームワークCakePHP です。一方でぼくは、PHPの経験こそあれど入社するまでCakePHPを触ったことがありませんでした。

このエントリでは、そんなぼくがはじめてCakePHPを触ってみた結果について書き殴ってみます。

前提

@takoba がいままで触れてきたアプリケーションフレームワーク

主要なものは、ざっとこんなかんじです。

「なんでコネヒトはCakePHPを採用しているの?」

詳しくは以下のエントリをお読みください!

www.wantedly.com

抜粋すると、以下のように「CakePHPの"制約"が、開発スピードの向上に寄与する」点が大きいようです。

いまでも採用をしているのは、CakePHPの「設定より規約」を重視しているところが個人的にはチーム開発において効果的だと考えているからです。チーム開発は、どうしても個々人によってコードのブレが出てくることもある。だから、フレームワークレベルである程度「縛り」を入れることで同じような設計やコードになり、それが開発スピードの速さ、品質の担保につながり、全体的に開発スピードが速まります。

「コネヒトにあるCakePHP製アプリケーションってどんなのがあるの?」

ママ向けコミュニティサービス「ママリ」のiOSアプリAndroidアプリで利用されているAPIアプリケーションはCakePHP3が採用されています。その他、社内に提供している管理画面のサーバーサイドもCakePHP3を採用しています。

また、弊社CTOのいとしょさんが最近つくった社内ツールでは、お試しする気持ちを込めてCakePHP4(4.0.0 bate1)が採用されています。

tech.connehito.com

感想

というわけで、ようやく本題です。

「率直にどうなん?」

「(全く触ったことないと)慣れるまでが大変ですが、慣れてからは便利だな〜〜」という気持ちです!

CakePHPは前述しているように「設定より規約」を重視したフレームワークです。そのため、触り始めはその"規約"を理解することに時間を使うことが多かった印象です。

幸い、理解するための材料はたくさんありました。既に本番環境でバリバリ動いているアプリケーションが目の前にあるので、「どのように実装してるんだ...?」とアプリケーションのコードを眺めたりlocalで動かしたりしながらフレームワークの挙動も把握していきました。また、実際にコードを書いてみて作成したPull Requestをレビューしてもらう中でも同僚から教わったりしていました。

そうやって徐々に慣れると「えーっとこの処理はどのクラスに書けばよいんだ...?」的なことは大抵のことは迷わなくて済むサクサク書けて便利だな〜〜ってなってます。

「設定より規約」が生む"共通認識"が、日々のコミュニケーションを加速させる

例えば、APIアプリケーションでユーザー情報の登録エンドポイントを追加するとします。エンドポイントがリクエストされた際に渡されるパラメータに関するバリデーション処理は、どのように表現したらよいでしょう。APIなのでView側でバリデーションすることは難しい*1ので、Controllerに書くか?Modelに書くか?という議論になりそうです。

この場合、CakePHP3で書くと「入力された値のバリデーションは、入力された値をEntityクラスに格納するとTableクラスに書いてあるバリデーションルールに沿って処理してくれるので、その結果を見ればよいな〜〜」というかんじになるので、CakePHP3を書いたことがあれば設計はそれなりに一意に定まるんですよね。*2*3

<?php
// 中略
class UsersController extends AppController
{

    public function initialize()
    {
        parent::initialize();
        // `/user/add.json` のようにリクエストするとextに合わせてJsonViewを適用してくれる
        // 従来は `AppController::initialize()` で定義しとくとよい
        $this->loadComponent('RequestHandler');

        $this->loadModel('Users');
    }

    public function add()
    {
        $user = $this->Users->newEntity($this->request->getData());
        $errors = $user->getErrors();
        if ($errors) {
            $this->set(compact('errors'));

            return;
        }

        $this->Users->save($user);
        $this->set(compact('user'));
    }
}
<?php
// 中略
class UsersTable extends Table
{
    
    public function validationDefault(Validator $validator)
    {
        $validator
            ->requirePresence('name', 'create')
            ->allowEmptyString('name', false)
            ->maxLength('name', 100);

        $validator
            ->allowEmptyString('description')
            ->maxLength('email', 255);

        return $validator;
    }
}

Ruby on Railsでもまさにそうですが、フレームワークの規約に乗ることで書き方が一意に定まるとその部分の設計を擦り合わせるコミュニケーションコストが確かに減るよな〜〜って実感しています。日々実装したりコードレビューしたりすることで、そのコストが軽くなっていき開発スピードが上がる!ということは確かに起きそうです。

また、コネヒトでは複数のアプリケーションでCakePHPを採用していますが、ドメイン知識の違いこそアプリケーションごとにあれど、アプリケーション自体に触れることへのハードルはだいぶ下がっていると感じています。開発環境のセットアップはどれかひとつのアプリケーションで覚えれば大体同じですし、見様見真似でソースコードを追っていくまでに時間はさほどかかりません。アプリケーション固有のレイアウトになってることはまず無いので、そんなに触ったことのないアプリケーションでもすぐに本質的な作業にアクセスできるのは非常によいです。

「複雑なことができない」制約による産物

一方で、こういった制約があることで「自由度が少ない!」「ちょっとレールを外れると非常に苦労する」という声も大いにあると思います。現にCakePHPとLaravelを対比する記事を読むとそんな声が大半です🙉

とはいえ、昨今のMicroservicesが流行していることも踏まえると、多くの責務をひとつのアプリケーションに委ねないことも必要だよな〜〜と感じています。

複数のアプリケーションをキューイングサービス*4などで繋いでパイプラインを組み、処理を完遂させるようなアーキテクチャは既に主流になっていますし、アプリケーション単位ではなくマクロな視点でシステム構成を設計していくことで持続可能なアーキテクチャを実現することに繋がるはずだ、と思います。別にこういったことが他のフレームワークじゃできない!ってことではないのですが、"CakePHPが持つ思想"を開発チームに装着することで理想的なアーキテクチャを実現していくための一助になるかもな?なんて思ったりしました。

おわりに

というわけで、CakePHPにはじめて触れた感想を書いてきました。特にCakePHPに関してはひよっこなので、いろいろ間違えてたらすみません><

今回は割とよくある話を改めて説いた感はあるので恐縮なのですが、とっても雑な感想としては、過去を振り返ると割とレガシーなアプリケーションを触ることが多かったので、例えば cakephp/orm のような表現力の高いORMがあるだけでも割とテンションが上がりました😇

そろそろCakePHP4がリリースされる日も近づいてきて、まだまだCakePHPは盛り上がっていくと思います。というわけで、ぼくも修練を重ねてCakePHPを使いこなし、" サービスの成長を第一に費用対効果を最大化させるコード "を書いていけるようにやっていくぞ!!!💪

[PR] エンジニア絶賛募集中です!!!

Connehito Image 柔軟な働き方を求める、サービス開発好きなPHPエンジニアWanted!

[PR] 弊社で採用している開発環境を参考に書かれたCakePHP本もよろしくな!!!

*1:入力がURLに含まれるクエリストリングだったり、POSTリクエスト時のリクエストボディだったりするので、View的な機能が介入されない場合が大半となるため。

*2:細かい話をすると、APIエンドポイントの振る舞いを考えたときに必ずしもEntityが担うバリデーション処理とエンドポイント側でのバリデーションが一致しない場合はあると思います。Laravelだとその辺りを柔軟に書けるよね!って話が多いのですが、単体テストを用いて動作保証をすることを考えると、CakePHP3でもEntityが担うバリデーションとエンドポイントが担うバリデーションを分けて書くことで、責務の分離をしつつ柔軟な振る舞いが実装できそうです。

*3:(2019/12/06 14:30追記)ブコメを見ると、LaravelだとFormRequest機能があって、それを用いるとController側でのバリデーション責務を分離できるようですね。これは便利そうだし、一定の責務分離はできそうですね。教えていただきありがとうございます!🙇‍♂️

*4:Amazon Simple Queue Serviceとかが有名。

コネヒト株式会社に入社しました

https://www.instagram.com/p/BzsgN30gM69/

2019年7月1日より、コネヒト株式会社に入社しました。

それに先立ちまして、2019年6月末日を以って株式会社Schooを退職しました。
多くの皆様には直接ご挨拶できず、このような形でのご報告となりまして誠に恐縮ではありますが、今後とも宜しくお付き合い願いたく存じます。

ちなみにSchoo社とは、2019年7月1日より業務委託契約を結んでもらいました。引き続き、必要に応じてお繋ぎしますので、ご用命がありましたらお声掛けくださいませ🙏

ここまでが TL;DR です。あとは興味があればお読みください。

誰ですか?

@takoba_ です。Webアプリケーションエンジニア兼カレー王子担当です🍛

守備範囲はサーバーサイド全般、フロントエンドあたりがメインで、あとは"なんちゃって"SREだったり、昔取った杵柄でUXデザイン的な活動をかじったりしてます。
PHPJavaScriptRubyがチョット書けます😎

なんで転職することにしたの?

前職のSchoo社、会社のビジョン的には未だに最高だと思っています。 「世の中から卒業をなくす」というミッション を中心に据えるこの会社は、この先10年、いやそれ以上の間、世の中に有意義な問いを投げかけ続けられる会社だと思っています。そして、その中で自分も活躍したい思いは十分ありました。

一方で、エンジニアとしての自分に目線を向けてみると、上記を実現するために必要な技術力、はたまたエンジニアとしての経験、もっと言えばWebサービスを構成するシステムを実装する経験を、ぼくはまだまだ身に付けられていないな、というギャップにここ数年悩まされてきました。

スタートアップ*1という環境は、とても広大な大地を開拓するような気持ちに度々させられるほど、エンジニアないしプロダクトを作る人間にとっては自由度が高い場所でした。
反面、その広大な大地を与えられたとて、実現できることは自らの器量に依存することを痛感させられました。ローンチしてから7年以上経った サービス / プロダクト において、エンジニアリングで解決したい問題は山程あるのですが、問題解決に時間が掛かることが多く、その原因として自分の器量不足を感じることが多くなりました。

特に、ぼくは「将来的にプロダクトのライフサイクルを全て見通せる人間になりたい」と思って、(割と意識して)浅く広くキャリアを積んできた人間でした*2。その代償として、エンジニアとしての強みはそこまで掘り下げきれていない、といった状態に落ち着いてしまっていると自分では捉えています。具体的には、システム/アプリケーションの設計力、そして設計したものを実現するための実装力*3などにコンプレックスを感じることが多いです。

いままでも、上記したような求めている経験を積むチャレンジを独自にいくつかしてみたつもりでしたが、まさに"雲を掴むような"状況になってしまい、まともな成功体験を得られずに終わることがしばしばある、という状態になっていました。
そういった状況において、「タレント性の強いエンジニアと切磋琢磨できる環境に飛び込みたい」という気持ちが日増しに大きくなっていったことで、転職することを検討し始めたのがきっかけです。

コネヒト社を選んだ理由は?

今回、転職を考えた際に テックブログ などで発信している内容を以前から拝見していたことから、エンジニア組織として魅力的な会社のひとつとしてコネヒト社に興味がある旨を 前CTOの島田さん にお伝えしたところ、トントン拍子で採用内定をいただくことになりました。
実際、入社してからは周りのエンジニアのハイレベル感に気後れしつつも、そんな方々とコミュニケーションするのがとてもよい刺激になっています。各種repoはノウハウの塊で、隙を見てrepo内のファイルを読んでみるとナウい実践例がたくさん知れるので、とてもよい学びになっています😇

また、個人的に関わりたいプロダクト像として、"誰かのためのインフラとなり得るプロダクト"というキーワードを掲げていました。

コネヒト社が展開する「ママリ」というプロダクトは、妊活期から妊娠期といったプレママや、出産して乳幼児の子育てをするママを主な対象として、「ママの一歩を支える」というキーワードを掲げるサービスです。

qa.mamari.jp


日本における、ママのための情報インフラとして立場を確立しつつあるプロダクトであると思うし、一歩踏み込めば"家族"というコミュニティを支える重要なプロダクトになり得るものだと、個人的には捉えています。そういったプロダクトに関われることも、入社を決断する要素のひとつとなりました。

今回は、他にも並行して数社の選考を経験させていただきましたが、最終的には元々魅力的に感じていた環境と採用時に関わっていただいた方々の熱意で入社を決断した次第です。この場を借りて、ご協力いただいた皆様に御礼申し上げます。ありがとうございました!🙇‍♂️

ちなみに島田さんとは、友人づてでご挨拶させていただいたことがきっかけで、以前からその友人含めて何度かごはん(というかカレーライス🍛)に連れてっていただいておりました。見事に餌付けされていたわけですねわかります。

ちなみにSchoo社には、引き続き"業務委託契約"を結んでもらいました

当面はわずかな時間しか費やせないかもですが、7月以降も業務委託契約を結んでもらいました。これは「微力だけど、継続してSchoo社のビジョン実現に携わりたい」という個人的な思いを受け止めてもらった形になります。

Schoo社を離れるタイミングに、度々いろんな方にお話しさせていただいたのが、北海道が誇るローカルバラエティ番組「水曜どうでしょう」のエピソードを引用した話でした。

「一生Schooする」ための力を身につけたいからこその決断

かつて、深夜番組としては異例の高視聴率を記録*4したこの番組は、人気絶頂の最中に"ラストラン(レギュラー放送最終回)"を迎えます。

その時に、キーワードとなっていたのが「一生どうでしょうします。」という一言です。具体的には、レギュラー放送として毎週放送する形を終え、"数年に一度は旅に出掛け、のんびり編集して、順次放送する"というスタイルで番組を続ける、という決断を人気絶頂の当時にしたのです。

後に、ある番組で当時の決断に際する状況を、出演者のひとりである大泉洋さんが以下のように語っていました。

とにかくね、やっぱり最後の一年二年はね、もう番組は終わるんだなあ、っていうのをずーっと考えながら、やっぱり旅をしてたんですよね。

−なんでですか?それ。

やっぱりね、やっぱり一緒に旅しているとわかるんですよ。みんながもう限界に来てるって言うのは。って言うのはね、ローカル番組って彼らが全部を作るんですね。編集から、音入れる作業から。彼らもう本当に家内制手工業みたいなもんなの。だから、『水曜どうでしょう』って番組をやっちゃうと、他の番組できないですよ。ひとつも。

でも、彼らもやっぱり、『水曜どうでしょう』っていう番組以外のこともやりたいじゃないですか。僕らはだんだん見ててわかっちゃうんですね、僕は。

また、当時の状況は、以下のページで藤やん*5が書いてたりもします。
www.htb.co.jp

先日、これらを改めて観たときに、「自分の状況にも近しいのかもな...」と勝手に思っていました。と言うのも、Schoo社が掲げている問いは、本当に一生をかけて解決しなくてはならない規模のもののように感じていたからです。

当然、目の前の問題を解決することだって、会社が存続、成長していくためには必要なのですが、ぼく自身がエンジニアというロールで向こう数十年この問いに立ち向かっていくには、一時期は違う方向を向くことも大事なのかもしれないな、と思っています。その結果、元々立ち向かってた問いにも立ち向かえる強さを身につけられるはずだ、と信じています。それが、ぼくにとっての「一生Schooします」ということになるのかな、と思っています。

今回、そんな「一生Schooする」ためのスタイルとして、業務委託契約を結んでもらう、という状況を作ってみました。パラレルワーク(複業)というキーワードが話題になりつつある現代で、個人的にもそういった枠組みに含まれるような働き方ができるのは楽しみですし、ある程度経過したタイミングで振り返ってみたいな、とも思っています。

おわりに

長々と書きましたが、要するにやっていきの気持ちでいっぱいです!今後とも何卒よろしくお願いいたします!!!🙌

ちなみに、例のリストも置いておきますね!!!!!

www.amazon.jp

*1:Schoo社も既に8期目ですが、在籍時におけるステージ的にはスタートアップです。

*2:言い換えると、エンジニアとしての実績よりも「エンジニアだけどxxもできるんやで」みたいな強みで生きてきた人間だったと自負しています。

*3:実装のボキャブラリー(デザインパターンetc.)とか、DXを支える技術とか、その他諸々。

*4:最高18.6%で、当時の同時間帯における占有率はほぼ90%台だった、みたいな話を聞いたことあります。

*5:水曜どうでしょうチーフディレクター藤村忠寿氏。