TeamGeekを読んだ

2018年8冊目

タイトルが独特なので敬遠してた。
読んでみると、Teamを作っていくリーダーの為の本という感じ。

一番印象に残ったのはHRTだが、その流れで一緒に語られていた
「技術的に貢献出来る人は確実に交換可能だ。」という部分。

技術が尖っていても、メンバーに対するHRTを感じない振る舞いがあれば、 振る舞いを指摘し、改善してもらう。改善がない場合は、チームを去ってもらう。という風に受け止めた。 （もちろんベースとなる技術は必要で、どちらも持っている人を待つというのが良いと思う）

技術だけでなくチームに貢献出来る人になるよう、全員で文化を作っていく事がいかに重要か。

自身もチームを作っていくリーダーの一人として、HRTを常に念頭に置いて、
サーヴァント型の人としてチームに貢献していきたい。
疲れてくるとどうしても傾聴出来ずに割って話をしてしまう事が最近多いので、自己コントロールをし、
メンバーを信頼しながら進める。

環境によるSQL Modeの違いではまった

Laravelで開発中にAリポジトリでは行出来るバッチをBリポジトリに移植

しかし、以下エラーが発生する。

SQLSTATE[42000]: Syntax error or access violation: 1055 'AAAAA' isn't in GROUP BY

stackoverflow.com

原因は、config/database.php で定義している strict=true|false の違いだった。

片側のリポジトリではstrict=false となっていた。。。

こういう部分をfalseに変える時はSQLを変えて、SQLを直してtrueのままにして欲しい。

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'
    ];
}

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年7冊目

 

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

 

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

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

 

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

 

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

 

 

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

 

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