はてなブックマーク

どうも、株式会社プラハCEOの松原です 先日プラハチャレンジのメンターセッションの一環でアプリケーションのコードレビューをしていた時に「そういえば自分は新規プロジェクトのコードを読むときによくprivate methodを使って処理を抽象化しているから、これを記事にしたら誰かの役に立つかも」と思い、筆を取りました。 対象読者 新しく参画したプロジェクトで複雑なコードをレビューしたり、仕様を追う必要がある Single Level of Abstraction Principle(SLAP)が気になる private methodを使い倒してみたい 題材 実際のコードを見ながら紹介した方が分かりやすいと思うので本人の同意を得てコードを提供していただきました。 さて今回の題材はプラハチャレンジというオンラインブートキャンプです。今回のコードに関連する仕様は以下の通り： 複数のUserがPair

どうも、株式会社プラハCEOの松原です 先日プラハチャレンジのメンターセッションの一環でコードレビューしていたらデフォルト引数を使った以下のような関数を function hoge(input: string = "default") { console.log(input) } デフォルト引数が使われること（出力が"default"になる）を期待しているコードがあったので「デフォルト引数は引数がundefinedの時しか使われまへんで」って話をしました デフォルトパラメータが使われるのはundefinedの時だけ falseとか""とか0とか[]みたいな値は普段から条件式に使われることも多いのでデフォルト引数の対象になりそうなイメージを持ってしまいますが、こいつらは例えば 「0という値を持っている」 とか 「空の文字列を持っている」 状態なので、「引数が指定されていない時(≒引数の値が分

どうも。株式会社プラハCEO兼エンジニアの松原です。 弊社はメンバー全員が業務委託なのですが、転職のお誘いをする際に「今は正社員に絞って探していて...」と言われることが結構多いので、業務委託契約をあえて選択している企業側の観点をどこかにまとめておいたら今後のエンジニアのキャリア選択に役立ててもらえるのではないか？ と考えつつ、もしかしたら読んでくれた人が興味を持って応募してくれるかも、という下心も込めてキーボードを叩いています。 ただ大前提として、人や会社によって最適な契約形態はそれぞれ異なるので、今回はあくまでプラハという会社にとってなぜ業務委託契約が適しているのか、という観点に絞って話していくので「そういう考え方の会社もあるんだ」ぐらいに留めていただけたら幸いです。決して業務委託契約が全ての状況で雇用契約を回るバラ色の契約形態だと言いたいわけではないよ！ 社風や理念との合致度 プラハ

こんにちは。株式会社プラハCEOの松原です 先輩に質問したら「もうちょっと聞きたいことをまとめてくれない？」と怒られた StackOverflowに質問したけど誰も答えてくれずしばらくして通知が届いたらdownvoteだった 質問しても曖昧な回答しか返ってこなくて、お互い気まずい空気が流れる そもそも技術系の質問するのが苦手 どれか1つでも該当する方にはこの記事が役に立つかもしれません。ちなみに僕は新人時代にフルコンボだドン 最近ではプラハチャレンジのメンターとして質問を受ける側に立つことが多いのですが、「これは答えやすい」と思う質問もあれば「ちょっと答えづらい...」と思う質問もあります。かれこれメンターとして1000個近くの質問を受けて来たので、せっかくの経験を生かしてより良い質問に繋がるチェックシートを作ってみました。 相手に十分な情報を与えているか 「プログラマが知るべき97のこと

こんにちは。株式会社プラハCEOの松原です 先日プラハチャレンジで「CQSとCQRSって何が違うんだろうね？」と話し合ったので内容をまとめてみます。 結論:CQRSとCQSの違い CQSはオブジェクト単位でメソッドの責務を更新と取得に応じて明確に分離すること CQRSはそれをアーキテクチャレベルに適用したもの。ただ、データソースの分離を行うか〜など分離レベルに関する定義は様々存在した CQSの定義 我らがMartin Fowler氏によればCQSという用語自体が登場したのはBertrand Meyer氏の書籍で、 The fundamental idea is that we should divide an object's methods into two sharply separated categories: と記載の通り、「オブジェクトのメソッド」を2つのカテゴリ（クエリとコマ

こんにちは。株式会社プラハCEOの松原です 注目を集めつつあるMySQLプラットフォームのPlanetScaleですが、外部キー制約が効かないという一見致命的に見える仕様について調べていたところ、こちらのDiscussionで興味深い回答が開発者から寄せられていたので日本語でまとめ直してみようと思いました。 外部キー制約がなくてもそれほど困らない理由 今回の話はParentテーブル(id)とChildテーブル(id,parent_id)を前提に考えていきます そもそも外部キー制約は何に役立つのか 今回のDiscussionでは質問者から「外部キー制約がないとこういう時に困るよ！」と質問が寄せられています： 外部キー制約がないと参照先のデータが存在していることを保証できない！ 外部キー制約がないとデータの重複を回避できない！ それぞれの質問に対して回答者の回答は以下の通りです： 外部制約がな

こんにちは。株式会社プラハCEOの松原です 先日プラハチャレンジのメンターセッションで「ドメイン知識が漏れるってどういうことなの？」という話になったので、その際に話したことをまとめてみようと思いました。 こちら本日のメイン、ドメイン知識が漏れまくっているコードです： class Person { // (ドメイン) public age: number public constructor(age: number) { this.age = age } } class Usecase1 { // （アプリケーションサービス層に属するクラス。コントローラー層のメソッドの1つと捉えていただいてもOKです） do(p: Person) { if (p.age > 18) { // 18歳以上なら登録できる！ } } } class Usecase2 { // （アプリケーションサービス層に属する

こんにちは。株式会社プラハCEOの松原です TL;DR デキる人は完成形を見せてから詳細を進めていく 30%ぐらい完成したタイミングで完成イメージを一度見せて、齟齬がないことを確認すると良い コードも完成イメージを一度レビューしてもらってから細部を実装した方が良いのではないか テストケースだけ先に見てもらうと良いんじゃない？ 仕事がデキる人はなぜ〇〇なのか 「仕事がデキる人はなぜ〇〇なのか」みたいなビジネス書によく書いてあるテクニックがあります。それは 頼まれた仕事は30%ぐらい完成したタイミングで一度依頼主に見せて、認識齟齬がないことを確認すること よく出てくるのがプレゼンの例です： 仕事がデキないパターン 上司「今度の企画案を部長に説明するためのプレゼンを作っておいてくれ。プレゼンは1週間後ね」 部下「わかりました！」 〜1週間後〜 部下「できました！」 上司「なにこれ！全然思ってたの

こんにちは。株式会社プラハCEOの松原です。 どんな人にこの記事を読んで欲しいか コードレビューの効率化に悩んでいる コードレビューのやり方に自信が持てず、何か参考になる事例を知りたい 使い捨てコードレビューに翻弄される日々 1~2年ほど前に自社サービスを開発していた頃、弊社では全てのプルリクエスト（以降PR）に対してランダムに割り当てられたレビュワー2名、もしくはテックリード1名にapproveされない限りマージしない運用で開発していました。開発者が5名ぐらいだったと記憶しているので、規模の割にはリッチなレビュー体制だったのではないでしょうか。 修正点があれば指摘して、直して、再確認して、merge。 来る日も来る日も、確認、指摘、修正、再確認、merge。 次第に「僕ら業務時間の大半をコードレビューに使ってね？」と、レビューに費やす時間が気になるようになってきたあたりで、一度自分たちの

こんにちは。株式会社プラハCEOの松原です。 先日プラハチャレンジの参加者に「Cache-Control: max-age=0って何の意味があるの？毎回サーバーに問い合わせてたらキャッシュのメリットがないのでは？」と聞かれたので、それについて思ったことをまとめてみます TL:DR; どでかいレスポンスを毎回取得しなくて済む 内容が更新されたらすぐ知りたいけどめっちゃ重いから毎回受け取りたくないリソースに向いてる 説明 例えば、内容が変わったらすぐに反映させたいどでかい画像を返してくるサーバーに複数回アクセスするケースを考えてみます レスポンスにmax-age=0が指定されている場合、2回目以降も毎回サーバーまでは問い合わせるけど変更がなければレスポンスのボディにはどでかい画像は含まれていない状態で返ってきます。空っぽです。1回目のレスポンス（どでかい画像）をクライアントがキャッシュしている

idをautoincrementしない方が良い理由 こんにちは。株式会社プラハCEOの松原です。 最近プラハチャレンジの参加者とお話している際に 「PKのidはautoincrementするとして...」 とナチュラルにid=autoincrementするものという前提が見えたので、「本当にidをautoincrementしても良いものだろうか？」と気になったことを書いてみようと思います。もしフレームワークが自動的にautoincrementでテーブルを作るからなんとなく使っているという方がいたらご一読いただいた後、それでも連番を使いたい理由があれば教えて欲しいです・・！ 不必要に情報を晒すことになる スクレイピングされたり もしも僕が某大手に勤めているエンジニアで「競合サービスAにのってる物件情報、全部コピーして新しいサービス作ろうぜ」と指示されたらですよ？「人としてそれはやっちゃダメで

こんにちは。株式会社プラハCEOの松原です。 弊社は主にスタートアップの新規事業に特化してデザイン・開発をするものづくり集団です。 最近改めて「プラハでエンジニアとして働く上で最低限必要なスキルって何よ？」という話になったのでリスト化してみました。 ついでにそれらにまつわる知識をうまくまとめてくれている情報源を追記しておくので、何かしらの学習素材として使っていただけると幸いです。 前提 前提として弊社が相手にしているスタートアップや新規事業の開発においては とにかく速く仮説検証し続けること が重要なので、継続的に機能改修しやすい柔らかなソフトウェアを作ることに重点が置かれています。他の事業であれば他のスキルが重視されますし、これらが新規事業の開発において絶対の指針だと言うつもりは全くないので 「あ〜新規事業の開発を主に手掛けているプラハっていう特定の会社(N=1)ではこんなスキルが求められ

こんにちは。株式会社プラハCEOの松原です。 DDDに基づいて開発しているアプリケーションの「認証」ってどこで実装するのが良いのだろう？ 対象読者 何となくDDDに関する本を読んで理解した気がする 試しにDDDに基づいてアプリケーションを実装し始めた 認証の実装をどこに書くべきかわからず詰まった 結論（オニオンアーキテクチャの場合） 実装はUI層かInfrastructure層 自分ならInfrastructure層 認証後のインターフェースはアプリケーション層 コンテキストは1つにまとめている前提（認証コンテキストを作らない場合の置き場所） UI層って何やねん DDDとの相性の良さからよく併用されるオニオンアーキテクチャの図を見ると、以下3つの層が一番外側に位置しています： UI(User Interface) Infrastructure Tests (図はこちらから引用) UIと言え

こんにちは。株式会社プラハCEOの松原です。 だいぶ前ですが、弊社に入社したメンバーから「ジェネリクスのメリットがいまいちピンとこない」と聞かれたので思ったことをまとめてみます ジェネリクスの使い方 ひとまずTypeScriptでジェネリクスの使い方をおさらいしてみます function hoge1(input1: string) { console.log(input1) return input1 } function hoge2(input2: number) { console.log(input2) return input2 } hoge1("string only") hoge2(100000)

こんばんは。株式会社プラハCEO兼エンジニアの松原です。 例えばNode.jsでテストを書いてる時こんなコマンドを見たことはありませんか？ dotenv -e .test.env -- jest --config config.json .test.envの後に紛れ込んでいる --。これは一体何なのか？ 結論 「--」は「これ以降の入力はオプションではありません」と指定する記号です。 bashのドキュメントでその存在について言及されています: Unless otherwise noted, each builtin command documented as accepting options preceded by ‘-’ accepts ‘--’ to signify the end of the options. The :, true, false, and test/[ buil