2018-03-24

Git ignore していたファイルを後から Git 管理対象とする

管理対象 -> 管理対象外の方法はすぐに見つかるが。逆は初めてだったのでメモ

add に force option があったのか

git add -f ./xxxxxxx

2018-03-19

LaravelでAPIを作成しCSRF_TOKEN無効でPOSTしたい時にハマる事

これはいつもハマるのでメモ（というか基本は無効にしないが）

Laravel5.4.x

/app/Http/Middleware/VerifyCsrfToken.php

<?php

class VerifyCsrfToken extends Middleware
{
    /**
     * The URIs that should be excluded from CSRF verification.
     *
     * @var array
     */
    protected $except = [
        'xxxxxxxxxxxxxxxxxxxx/xxxxxxxxxx/xxxxxxxxxxxx'
    ];
}

2018-03-17

PHPのVersionを指定してパッケージをインストールする

あれ？composer install で PHP の Version 違うよ？ってエラーが出た

手元の VM が PHP7.1 で本番が 7.0 だった時に発生

 doctrine/inflector v1.3.0 requires php ^7.1 -> your PHP version (7.0.21) does not satisfy that requirement.

composer.json
    "config": {
        "preferred-install": "dist",
        "sort-packages": true,
        "optimize-autoloader": true,
        "php": "7.0.21" <------------ ここに環境の Version を指定しておく

指定した後に composer install すると、config で指定した Version に依存したパッケージを探してくれる

2018-03-17

レガシーコード改善ガイド読んでる

2018年7冊目

iPhone8Plus + kindleアプリに変えてとりあえずポチるが続いて、物理本は会社にあるけど読みやすいKindle版を購入。

ずっと読みたいと思いながら読めてなかった一冊。

テスト駆動について学び、設計を学びながら思うことは自分の中で良いコードとは？と考えた時の理想となる姿が少しずつ見えてきた事。

まずはいかにこのコードを保証するか。そのためにどういうテストが書けるかをイメージする。テストが書きづらそうだなと思えば、再考の余地があるというふうに最近は考えている。

レガシーコードのジレンマはその通り、コードを変えたい、テスト書きたい。テスト書くためにコードを変えなければ。という流れはある。

理想的で美しく、パターンを駆使した設計にするための方法を示しているわけではありません。そのことについて書かれた本はたくさんありますので、そういった手法を使う機会があれば、是非使ってみてください。これらの章で説明しているのは、設計を「より良く」する方法です。「より良く」のレベルは状況によって異なり、たいていは、以前の設計より少し保守しやすくなるだけです。だからといってその作業を軽視しないでください。この作業は多少機械的なものですが、扱いやすくなるように大きなクラスを分割するといった些細なことによって、アプリケーションに大きな違いが出てきます。

より良くの定義を少し保守しやすくするという答え。とても現実味がある。コードは書いた瞬間から長い保守に入る。その保守は業務のメインになるし、そのためにリファクタしながら腐敗を少なくするという根本にある考えと思う。

2018-03-10

PHPerKaigi2018に行ってきた！

PHPerKaigi2018 に行ってきた！

https://phperkaigi.jp/2018/

練馬駅と隣接する会場という事でアクセスがめちゃ便利
3/9 も面白かったけど、特に3/10の以下トークは今考えている事に近い事で特に刺激が強かった

SOLIDの原則って、どんなふうに使うの？

オープン・クローズの原則を元に先輩と若手のリファクタリングを通すストーリー。
ToDoクラスの条件分岐をInterface（抽象に依存）しながら、最終的にはResolverで解決していくあたりが学びが多かった

質問に挙がった
「急に出てきたResolverはどこから？リストのようなものはあるか？」という質問
デザインパターンや、フレームワークの中身を見るとよいかも。という事だった。
このあたりは学びの部分だと感じたので、コアを読んでいかなければと思う。
参考書として上げていた○◯コードという本の名前を聞きそびれた。。。残念。

BEAR.Sunday

インターフェースの説明が非常にわかりやすく、
特にAOPの考えかたの部分（ドメインロジックとアプリケーションロジック）の説明が分かりやすかった。
AOPは言葉は聞いた事があるが、中身を理解していなかったので、入門者にとっても図解がとてもありがたい。
BEAR.Sunday 聞いた事なかったので、いい機会になった。

PHPStanで始める継続的型検査

Phan以外の静的方検査のライブラリとしてとても便利そう。
一緒に話に挙がったCIでコケた時に自動でIssueを立てるreviewdog は使ってみたい。
GitLabも機能についてのIssueが立っていたので、もしかしたら最新では利用出来るようになるかもという感じ

雑感

飲みながら話聞けたり、コンパクトで会場の盛り上がりも高く楽しかった。
今日は大坂から知人が来て懇親会に出られなかったので次回があれば、是非参加したい!!
他のPHPカンファレンスも行ってみたいし、トークすると1.5倍楽しめるという事なので挑戦したい。

運営スタッフのみなさん。トークを行って頂いた皆さん、本当に楽しいイベントをありがとうございます！！！！

資料のリンクは後日！

2018-02-26

エンジニアリング組織論を読んだ

2018年6冊目

タイムラインで複数の人がオススメしていたので読み始め見た。

まだ2割くらいかな。ってところで思うところが多すぎてメモを更新するスタイルとする。

前の記事のアプリケーション設計でもそうだが、ハイライトが多すぎて後でハイライトを追うスタイルだと理解まで落とし込むまでに次のハイライトに進んでしまい理解が追いつかない。ちょい出しで進めたほうがよさそう。

認知的不協和

認知の歪み

事実と解釈

怒りを悲しみとして伝える

この部分がチーム開発に重要と思っている。

サイボウズのチームのことだけを考えたでも話していたが、事実と解釈を誤って伝えるとどうしてもコミュニケーションの中でフィルタや増減がかかってしまうので意識したい。

冒頭で書いていた、以下はいつも思ってることなので、これは読もう！とすぐに感じた。

最近設計関連を読むことが多いのはテスト容易性を高めるためであり、テスト容易性のコード設計は正しいドメインの理解と、コードレビューでは指摘できない部分の強化、つまりチーム内における開発手法や思想の共有、それはチームとしての価値観につながる。

いいコードを書きたい

だから、

いい設計をしたい

だから、いいチームを作りたい

そのチームが事業に売り上げをもたらす強さを持てば最強じゃないか

■当たり前のことを意識してやるアクノレッジメントは、

・ちゃんと挨拶する

・無視しないで話を聞く

・相手に感謝を伝える

・気にかけて話しかける

・自分本位でなく相手本位で話をする

書いてあるように本当に小学生の標語のようだ。実際はこれが人の基本という事だな。

小学生の時の校長先生が常にいっていたのは

1、挨拶

2、学習

3、読書

だったな。挨拶が一番にくるあたり、コミュニケーションの基本ということになるな。

最初にも書いてあったが、

エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」という考え方

これに尽きると思う。見積りもスケジュールもすべてこれをベースに考えたい。

2018-02-26

.NETのエンタープライズアプリケーションアーキテクチャ第2版を読んだ

2018年5冊目

ページ数が鈍器級で7割くらい読んだので途中で記載

現時点の疑問を書いておいて、後で読み終えた時に答え合わせをする。

階層化アーキテクチャで、階層ごとの説明が、今まで読んだどの本よりも詳細でわかりやすい。

過去に実践ドメイン駆動設計や階層化アーキテクチャについて調べてきた、実装してきた人にとっては、読んでいてコードが想像できるのでスラスラ読める。

気になっていたEntityの動きがなんとなく掴めてきた。まだ完全ではないけど、DTOだが永続化層へのアクセスに使うためのクラスという考えか。

ViewModelとしてのDTOとは異なる。

本来は永続化層とのやりとりの前に一段置いて状態を管理するsroreとしての役割かと思っていたが、この部分DTOとEntityの違いは残りのページで理解を深めたい

初学者にとっては具体的なコードが少ないため想像がつきにくいと思う。

https://www.amazon.co.jp/NETのエンタープライズアプリケーションアーキテクチャ第2版-NETを例にしたアプリケーション設計原則-ディノ-エスポシト-ebook/dp/B00ZQZ8JNE

2/1くらいこらコツコツと通勤の朝限定で読んでる。朝は理解できる。帰りだと理解できない。なので帰りは違うことをするようにしている。