PHP-CS-Fixer camelCaseな変数名をsnake_caseに変換するcustom-fixers

PHP-CS-Fixerを使って、camelCaseな変数名をsnake_caseに変換するcustom-fixersです。 protected な変数は対象外にしています。

<?php

namespace App\Fixers;

use PhpCsFixer\AbstractFixer;
use PhpCsFixer\FixerDefinition\CodeSample;
use PhpCsFixer\FixerDefinition\FixerDefinition;
use PhpCsFixer\Tokenizer\Token;
use PhpCsFixer\Tokenizer\Tokens;
use SplFileInfo;

class SnakeCaseVariableFixer extends AbstractFixer
{
    /**
     * https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/blob/d208496b85c57217e76502b55e2228f3bfe7452b/src/FixerFactory.php#L131
     */
    public function getName(): string
    {
        return 'App/snake_case_variable';
    }

    public function getDefinition(): FixerDefinition
    {
        return new FixerDefinition(
            'Variable names should be in snake_case.',
            [
                new CodeSample('<?php $camelCase = "example";'),
            ]
        );
    }

    public function isCandidate(Tokens $tokens): bool
    {
        return $tokens->isAllTokenKindsFound([T_VARIABLE]);
    }

    public function applyFix(SplFileInfo $file, Tokens $tokens): void
    {
        foreach ($tokens as $index => $token) {
            if ($token->isGivenKind(T_VARIABLE)) {
                 /**
                 * This section processes the exclusion of protected variables.
                 * When the variable is protected, it will be preceded by 'protected' and a space, 
                 * both of which are tokens. Thus, we check the token value at $index - 2 to identify
                 * if it is 'protected' and skip processing if so.
                 */
                if ($index > 2) {
                    $previousToken = $tokens[$index - 2];
                    if ($previousToken->isGivenKind(T_PROTECTED)) {
                        continue;
                    }
                }

                $variable_name = $token->getContent();
                $snake_case_name = $this->convertToSnakeCase($variable_name);
                if ($variable_name !== $snake_case_name) {
                    $tokens[$index] = new Token([T_VARIABLE, $snake_case_name]);
                }
            }
        }
    }

    private function convertToSnakeCase($string): string
    {
        return '$'.strtolower(preg_replace('/([a-z])([A-Z])/', '$1_$2', substr($string, 1)));
    }
}

docker compose cp でディレクトリ配下のファイルを全てコピーしたい

結論

コピー元に . を指定することで指定したディレクトリ配下のファイル・ディレクトリ全てがコピーされる。

docker compose cp database/migrations/. app:/src/database/migrations/

ファイルだけ, 拡張子を指定したい... などのユースケースは for で愚直にloopするしかない。

for file in database/migrations/*.rb; do docker compose cp $file app:/src/database/migrations/; done

何に困っていたか

cpコマンドと同じノリで実行しようとしたがダメだったので調べたメモ。

docker compose cp database/migrations/* app:/src/database/migrations/

"docker compose cp" requires exactly 2 arguments.
See 'docker compose cp --help'.

Usage:  docker compose cp [OPTIONS] SERVICE:SRC_PATH DEST_PATH|-
    docker compose cp [OPTIONS] SRC_PATH|- SERVICE:DEST_PATH

Copy files/folders between a service container and the local filesystem

関連リンク

docs.docker.com

github.com

www.warp.dev

マイクロサービス化 Yes/Noチャート

マイクロサービス化するの難しいな〜と思い、思考整理がてらメモ。 大半のサービスでは、コアドメインは複雑性が高いので、サブドメインから分離していくことになると思う。

Yes/Noチャート

コナーセンス

リファクタリングを進める際の尺度として活用できる。

https://www.oreilly.co.jp//books/9784873119823/

https://snoozer05.hatenablog.jp/entry/2020/12/11/150913

コアドメインとサブドメイン

マイクロサービスというよりDDDの話になるが、コアドメイン・サブドメインという考え方を元に分割粒度を決める。

https://www.amazon.co.jp/dp/4798121967

https://learn.microsoft.com/ja-jp/azure/architecture/microservices/model/domain-analysis

「教養として知っておきたい33の哲学」を読んだら哲学の深さに圧倒された

書籍

代表的な哲学者33名の思想がまとめられています。 図解いちばんやさしい哲学(2013出版)という本に加筆・修正したものらしいです。

フッサール

客観は存在しない 主観と主観のあいだで共通する部分が客観と勘違いされているだけ

個人的にはとても気に入った考え方です。

ものごとの本質はあいまい

歳を重ねるにつれてこの気持ちが分かるようになりました。 物事の多面性や複雑性がより明らかになり、単純な答えや定義が難しくなります。

心理は存在しない

ここまでの引用を見ると、何か達観した達人のような考え方を感じますが、 フッサールの哲学は「現象学」という名で、人間の経験や意識の本質的な特徴を研究する哲学の一分野だそうです。

なので、達観とは少し違う考え方なのかもしれません。

あるサイトとの出会い

本書を読んでいて、代表的な哲学をまとめてマップにしてみようか、という軽い気持ちが湧きました。 Googleで調べてみたところすでに存在し、かつとんでもない量の哲学者がいることを知りました。

www.denizcemonduygu.com

最も引きで見たらこんな感じです。

もう一つ、別のサイトも見つけました。 全対戦ネットワーク図というネーミングが面白いですね。

psychotoolbox.web.fc2.com

広すぎる「哲学」の世界

哲学とは、果てしなく広がる思考の海でとんでもない深さだと理解しました。

専門家ではありませんが、たまには「哲学」を意識して自分なりの答えを探し続けようと思います。

2011~2020あたりのソーシャルゲーム年表

はじめに

筆者が触ったことのあるソーシャルゲームや特に印象に残ったものをメモをとして残しておこうと思います。

いつか自分が懐かしむために。

  1. 個人の調査であるため、不確実な情報が含まれている可能性があります、ご注意ください
  2. Facebook/Android/iOSなど媒体でリリース日に差異がある場合、より早い日を優先して記載しています
  3. 日本版のリリース日を優先して記載しています
  4. できるだけ正式名称で記載することを心がけています
  5. 一部「ソーシャルゲーム」の定義から外れているものも含まれています

年表

2009年代

  • 2009年12月11日 アングリーバード

2010年代

2011年代

2012年代

2013年代

2014年代

2015年代

2016年代

  • 2016年1月28日 誰ガ為のアルケミスト

  • 2016年2月5日 セブンナイツ

  • 2016年2月4日 逆転オセロニア

  • 2016年3月2日 クラッシュ・ロワイヤル

  • 2016年4月26日 [乃木坂46公式]乃木恋~坂道の下で、あの日僕は恋をした~

    • 思ったよりもゲーム性が良くてしばらくハマっていました、このゲームがきっかけで乃木坂の動画を見るようになった。
  • 2016年7月22日 Pokémon GO

    • FUJIROCKに行く途中のSAでインストールしたので、ポケモンもポケストップも見つからず「なんだこれは?」という気持ちになったのを覚えています。帰宅後に普通に遊びました。
  • 2016年7月31日 白猫テニス

  • 2016年8月25日 ガーデンスケイプ

  • 2016年11月17日 遊戯王 デュエルリンクス

  • 2016年12月17日 #コンパス【戦闘摂理解析システム】

2017年代

  • 2017年2月16日 崩壊3rd

  • 2017年3月24日 放置少女〜百花繚乱の萌姫たち〜

  • 2017年4月20日 さんぽけ ~三国志大戦ぽけっと~

  • 2017年6月6日 SINoALICE -シノアリス-

  • 2017年7月4日 みんゴル

  • 2017年9月21日 テラバトル2

  • 2017年9月13日 アズールレーン

  • 2017年9月19日 ホームスケイプ

    • ガーデンスケイプの続編らしい
  • 2017年10月25日

  • 2017年11月14日 荒野行動

2018年代

2019年代

  • 2019年2月26日 黒い砂漠 MOBILE

  • 2019年4月10日 メイプルストーリーM

  • 2019年6月4日 七つの大罪 ~光と闇の交戦グランドクロス~

  • 2019年8月8日 TEPPEN

  • 2019年9月25日 マリオカート ツアー

2020年代

  • 2020年1月16日 アークナイツ

  • 2020年6月30日 AFKアリーナ

    • 2023年時点の多くのソシャゲはこのゲーミフィケーションを参考にしている事が多い気がします。
  • 2020年9月28日 原神

    • 何社かが夢破れてきた「モバイルアプリで本格MMORPG」を正当に切り開いていきました、凄すぎます。

2021年代

2022年代

  • 2022年2月10日 Heaven Burns Red(ヘブンバーンズレッド)

2023年代

  • 2023年7月17日 ポケモンスリープ
    • 数日試しましたが、僕にはApple Watchで十分だった...すまんカビゴン。

おわりに

改めて見返すと色々なゲームが登場してクオリティも劇的に向上していますね、mixiで農業をしていた時代が少し愛おしくなりました。

記事を書いていたらゲーム欲が出てきたので何かインストールしようかな。

参考資料

iphoneac-blog.com

iphoneac-blog.com

「東大教授の考え続ける力がつく 思考習慣」を読んだ

今週のお題「最近読んでるもの」だったので :)

東大教授の考え続ける力がつく 思考習慣

Audibleで聴いていたのをきっかけに、挿絵や図を確認したくて買ってみたところ、 やりたいことの発見・人間関係・問題解決 が記載されており、仕事で活用できそうな一冊でした。

「Audibleで聴きながら本書を眺める」 のも良い時間の使い方だなと小さな発見です。

第3章「情報」に惑わされない思考習慣

特に印象に残っている章です。

「事実」と「意見」を分けて考えるは意識しないとなかなかできないので、気づきを与えられました。

どこまでが「事実」なのかを、エビデンスをもとに判断する重要性を痛感します。

次は何を読もうか

最近は自己啓発本や技術書を読む事が多かったので、たまにはライトノベルかマンガでも…「キノの旅」か「よつばと!」を読みたくなってきました。

「キノの旅」は2020年に新刊

「よつばと!」は2021年に新刊

そういえば葬送のフリーレンを観ていて思いましたが、キノの旅ももう一度アニメ化してくれないかな。たのむ。

今週末は本屋に行っ色んな棚をじっくり探してみよう。

視座を高めるために「プロダクトマネージャーのしごと」を読んだ

TL;DR

  • プロダクトマネージャーという肩書きに権威があるわけでは無い
  • 仕事は他の人の助けをもってこそ達成できる
  • 失敗を回避する事はできない、失敗から学び成長する

はじめに

本書はプロダクトマネジメントの基礎、戦略立案、ロードマッピング、リーダーシップ、ステークホルダーとのコミュニケーションなど、幅広いトピックを網羅しています。

各章にはまとめとチェックリストが用意されており、自分の達成項目を確認するためにも役立ちます。

目次

  • 1章 プロダクトマネジメントの実践
  • 2章 プロダクトマネジメントのCOREスキル
  • 3章 好奇心をあらわにする
  • 4章 過剰コミュニケーションの技術
  • 5章 シニアステークホルダーと働く(ポーカーゲームをする)
  • 6章 ユーザーに話しかける(あるいは「ポーカーって何?」)
  • 7章 「ベストプラクティス」のワーストなところ
  • 8章 アジャイルについての素晴らしくも残念な真実
  • 9章 ドキュメントは無限に時間を浪費する(そう、ロードマップもドキュメント)
  • 10章 ビジョン、ミッション、達成目標、戦略を始めとしたイケてる言葉たち
  • 11章 「データ、舵を取れ!」
  • 12章 優先順位づけ:すべてのよりどころ
  • 13章 おうちでやってみよう:リモートワークの試練と困難
  • 14章 プロダクトマネージャーのなかのマネージャー(プロダクトリーダーシップ編)
  • 15章 良いときと悪いとき
  • 16章 どんなことでも

1章 プロダクトマネジメントの実践

プロダクトマネージャーとして週に60時間も働いてはいけない

長時間労働しているプロダクトマネージャーを多く見てきたので予想外な一文でした。

チームが目標を達成できるようにタスクを優先付けすることが重要であり、労働時間はやはり短い方がいいのですね。

組織やチームごとに千差万別です。

プロダクトマネージャーという職種には固定の定義がなく、組織によって求められる役割が変わるということを認識することが大切です。 多くの異なる役割がありますが、どれも柔軟性が必要とされています。

2章 プロダクトマネジメントのCOREスキル

What, exactly, is a Product Manager? が有名のようですが、 この問いに対する答えはこの図だけで表現することはできません。この章ではコミュニケーション、組織化、リサーチ、実行の重要性に焦点を当てています。

www.mindtheproduct.com

3章 好奇心をあらわにする

プロダクトの失敗と個人的な失敗は分ける

というケーススタディがとても印象的でした。読み進める中で、何度もうなずいてしまいました。

4章 過剰コミュニケーションの技術

そこには「あのさ、新しいiPhoneアプリのApp Storeへの申請を今晩中にできる?」とありました。 混乱しました。緊急指示ってこと? 優先度は高くないただのちょっとしたお願い? 今すぐやってほしいってこと?”

上司からの急な指示は多くの人が悩むポイントではないでしょうか。 この章では、プロダクトマネジメントの分野における伝え方の重要性を端的に示しています。

プロダクトマネジメントでいちばん危険な言葉:「よさそう」

LGTMの時も言ってしまう「よさそう」ですが、 エンジニアリングマネージャーやプロダクトマネージャー(EMやPdM)を目指す人々にとっては、このような曖昧な表現は避けるべきです。

なぜなら、それはしばしば不確実性を招き、チームメンバー間の誤解を生む可能性があるからです。

5章 シニアステークホルダーと働く(ポーカーゲームをする)

ステークホルダーとの関係を保ちつつ、ユーザー主義を貫く事が主軸に書かれています。

いくつかのシナリオを想定したpros/consが登場するので、今の仕事ですぐに活用できるケースを見つける事ができるでしょう。

6章 ユーザーに話しかける(あるいは「ポーカーって何?」)

ステークホルダーとユーザーは違う

ハッとしました。チームによってはステークホルダーという単語の範囲にバラツキがある場合が多いので、ハッキリ認識合わせをするべき一文だと感じました。

また、ユーザーペルソナの落とし穴について書かれており、仕様を検討する上で重要な事がまとめられています。

7章 「ベストプラクティス」のワーストなところ

誇張を鵜呑みにしない

多くの場合、何かの登壇や技術ブログで発信される情報はとても耳障りの良い内容が多いです。

その情報を鵜呑みにするのではなく、発表している組織が作ったものを実際に触る事が真実に近いでしょう。

8章 アジャイルについての素晴らしくも残念な真実

ウォーターフォールからアジャイルに変わるときの期待値を設定する

上記のケーススタディは意思決定と会話する上で大事な要素に見えます。

多くのWeb系企業ではアジャイルを導入していますが、デッドラインももちろん存在する為、バランスが難しいと感じています。

この難しさについては、2011年10月8日にのスクウェア・エニックスCTO 橋本 善久 さんが公開されているPDFがとても勉強になりました。

ゲーム開発 プロジェクトマネジメント講座

ゲーム開発 プロジェクトマネジメント講座 141ページ

9章 ドキュメントは無限に時間を浪費する(そう、ロードマップもドキュメント)

私はPdMではありませんが、それでもドキュメントの作成・メンテに無限に時間を浪費した経験があります。

例えば、1年くらい殆どExcelやPowerPointやMiroしか触っていなかったんじゃないか?と感じる時期さえありました。

ドキュメントを完璧にする事を目指すのではなく、短い時間でぱぱっと書いていまう、それを繰り返す方が良いということです。

メニューは食事ではない

という言葉がまさにそれを表現していました。

10章 ビジョン、ミッション、達成目標、戦略を始めとしたイケてる言葉たち

この点については企業毎の特色が強くでるので難しいのですが、

優れた戦略はシンプルで明快だ

という一文に強く頷き、過去に経験した目標設定を少し振り返ってみました。

マトリクスでちょっと複雑な目標管理をしている現場などもありましたし、OKRとMBOを混在させて税制並の難解さをだしている現場もありました。

ただ、私が最も脳をクリアに目標を意識しつつ働けたのは、30名程度のスタートアップでゴールが明確な時だった事を思い出しました。

個人的にはOKRを用いた目標設定が好みです。

www.kaonavi.jp

11章 「データ、舵を取れ!」

データという概念の難しさと、データドリブンに基づいたプロダクトマネジメントの使いどろこについて説明しています。

データドリブンに全てを委ねることなく、優先順位や意思決定は変わらずに必要だという事がわかりました。

12章 優先順位づけ:すべてのよりどころ

会社のゴール、戦略、チームのゴール、プロダクトビジョン…etc

様々な観点での意思決定が必要である事が語られています。

手短に言えば、ベストを尽くすのです

この一文にある通り、一箇所をみていれば良いわけではないし、意思決定は常にトレードオフだと表現されています。

但し、過去に私が学んだ事として、意思決定は全てを見通した上で行われるわけではありません。

その時点での情報を元に最適にみえる解を出す事は十分に意思決定であり、将来振り返ってみて失敗だったとしてもそれはある程度仕方のない事です。

マネジメントに関わる人は、ある時点で過去の意思決定が失敗だと思ったとしても、当時の情報で十分に検討した結果であれば、それについてあまり悔やみすぎる必要はないと私は思っています。

13章 おうちでやってみよう:リモートワークの試練と困難

同期・非同期のコミュニケーションをいかに活用していくかについて勉強になりました。

準備と練習には3倍かける

同期コミュニケーションによる価値のある時間を作るためには、その3倍の時間をかけて用意する必要があると説かれています。

これは本当にその通りで、ラバーダッキング法を用いて自分のアイデアを反芻するのが大事になるでしょう。

https://ja.m.wikipedia.org/wiki/ラバーダック・デバッグ/ja.m.wikipedia.org

14章 プロダクトマネージャーのなかのマネージャー(プロダクトリーダーシップ編)

幹部に反射的に「はい」と応えることがいかにチームを壊滅させ、あなたを昇進させるか!

この章では、ケーススタディがいくつかありますが、そこに全てが詰まっています。

15章 良いときと悪いとき

キャリアにおいては、「良いとき」と「悪いとき」が入り混じってぼやけて、グレーな「大丈夫なとき」に見えることが何度もあるでしょう。

中には常に「良いとき」を過ごしているように見える人もいますが、そんな事はありません。

どんな人でもアップダウンがあり、モヤモヤしている時があるのだと思います。

16章 どんなことでも

プロダクトマネージャーを続けていく事で貴方自身も成長します。

失敗はつきものであり、恐れるのではなくそこから学ぶ必要がある事が締として書かれています。

おわりに

リーダーやEMにフォーカスした内容を求めている方は下記の一冊もオススメです。

簡単な差分を紹介すると下記の通りです。

  • プロダクトマネージャーのしごと
    • 製品の全体像と市場、チームの成功、ロードマップ作成や機能定義...etc
  • エンジニアリングマネージャーのしごと
    • 技術チームの効率と製品の技術的や、チームメンバーのキャリア成長とモチベーション維持...etc