履歴データテーブルとの向き合い方_PHPerKaigi2024PHPerKaigi2024 の登壇資料です。 履歴データテーブルとの向き合い方 https://fortee.jp/phperkaigi-2024/proposal/47cf9f17-825a-4021-bf33-86e4a62bc222
Rustでリレーショナルデータベースを自作したときの成果と反省と学び - better_hacking_life
はじめに この記事では、個人プロジェクトとしてRust言語でリレーショナルデータベースを開発した経験（もう五ヶ月も前...）について、その成果と反省、得た学びを共有します。 DBMSを自作した理由 自分がDBMSの自作に着手したのは、『Designing Data-Intensive Applications』という本の内容を深く理解するためでした。 この本は、データシステムの設計と運用において最も大切な「信頼性」、「拡張性」、「保守性」を保証する方法論を、豊富な文献を引用しつつ、理論と実践の橋渡しを巧みに行いながら、丁寧に説明している名著です。読んだことがない人は速攻購入してくだい。本当にいい本です。 この本は、データベースの内部構造に関する話も豊富に含まれていたので、「データベース自作してみようか...」という気持ちになりました。 Rustを採用した理由 データベースの実装のついでに、
良いコメントが良い設計を導く
要旨 コメントを適切に記述することは、特にインターフェイス（クラスやメソッド）において重要です。これにより、直感性が高まり、抽象化が十分に行われているかを確認する手助けになります。そのため、コメントはソフトウェア設計プロセスの重要な一部と位置づけられます。 2種類のコメントタイプ まず、コメントを2種類に分類します。 1️⃣ コードをより詳細化するコメント(lower-level comment) 2️⃣ コードをより抽象化するコメント(higher-level comment) どちらも必要なコメントとしつつ、本書では後者のコメントをより重視しています。 1️⃣ コードを詳細化するコメント(lower-level comment) 変数名などに残すタイプのコメントで、宣言した対象の単位や境界値、null許容などの詳細を明示することで、コードの正確性を高めます。こちらのタイプのコメントも必
実録レガシーコード改善 / Working with Legacy Code: the True Record
2024/01/15(月) 12:00 〜 13:00 t-wadaさんが後世に残したい、実録レガシーコード改善 https://findy.connpass.com/event/304101/ テストコードが無いコードを引き継いだところからはじまる、実際に2018年に行った受託開発案件のエ…
TypeScriptで学ぶ！SOLID原則
はじめに 皆さんこんにちは、株式会社エムアイ・ラボのエンジニアです！ 今回はソフトウェア設計のSOLID原則について学習したので、弊社のメインの開発言語であるTypeScriptのサンプルコードを使って共有できればと思います。 SOLID原則は、オブジェクト思考プログラミングにおいて、ソフトウェアがメンテナンスしやすく、拡張や変更に強いソフトウェア設計を行うための原則です。 SOLID原則にはSOLIDの頭文字をそれぞれとった、５つの原則があります。 単一責任の原則（Single Responsibility Principle） 単一責任の原則とは、クラスが一つの機能や責任を持つべきで、クラスが変更される理由は一つであるべきというです。 クラスが一つの機能や責任のみを持つようにすることにより、コードは再利用可能でテストが容易になります。 単一責任の原則を遵守している例 以下のBirdクラ
開発効率を追い求めた実装プラクティス集
この記事は MICIN Advent Calendar 2023 の24日目の記事です。 前回はSaneさんの「データ基盤チームで社内インターンをやってみて」でした。 はじめに abekohです。MICINでMiROHAの開発をしております。 本記事では、書籍等から得た設計・実装パターンの知識や、実際にプロダクト開発で試して得られた経験などから編み出した、開発効率向上のためのWeb API開発のプラクティスを紹介します。 筆者が関わっているMiROHAは治験の業務支援を取り扱うプロダクトです。MiROHAの開発における特性として、以下のようなものが挙げられます。 治験業務に関するドメインが特有で複雑 前例が少なく、MVPを追求中。プロダクトのアプローチが頻繁に変わる 外部品質は高い水準が求められる これらの特性を意識して開発を促進させるために日々試行錯誤しております。 複雑なドメインに対す
DDDを実践するためのリポジトリ層の設計（Go言語による例）
The Go gopher was designed by Renée French. Illustrations by tottie. はじめに この記事は、ドメイン駆動設計（DDD）の中核概念である「リポジトリ」についての理解を深めることを目的としています。リポジトリの基本的な役割と重要性を確認し、Go言語での実装の例を紹介します。 前提 リレーショナルデータベースからデータを取得（更新）するアプリケーションを想定しています サンプルコードは Go 言語で書かれています リポジトリとは まずは、リポジトリの定義を確認してみましょう。 リポジトリパターンとは: リポジトリは、データベースから取得したデータを構造体にマッピングし、ドメインオブジェクトにアクセスするためのインターフェースを提供します。 これは、一般的なリポジトリの理解と相違ないですね。次に DDDの文脈で、より詳しい定義をみ
「コードがむずかしい」からの脱却
コード品質向上のいろは - 先達に学ぶ実践例 Lunch LT https://findy.connpass.com/event/300912/
2023年の Go での気づきに思いを馳せて構築するオレオレ Go サーバープロジェクトレイアウト
2023 年は念願叶い業務でも趣味でも Go を触ることができました。 そんな 2023 年での Go での気づきに思いを馳せ、タスク管理をするような簡単なサーバーを構築しそのプロジェクトレイアウトをご紹介してみます。 気づきといっても読む方にとっては当たり前のことかもしれません。 また、プロジェクトレイアウトはこれが正義だとは思っていません。紹介するレイアウトは業務では使っていないです。運用などもまともにしたことはありません。私がそこそこの規模のサーバーを新規で構築するならこんな風にしようかなって記事です。 気づき interface を満たすためのコードって VSCode で自動生成できたんだ よくおまじないとかファクトリー関数の戻り値とかで構造体が interface を満たしているかどうかを確認することがあるかと思います。 package main import "context"
LINEヤフー Tech Blog コード品質向上のテクニック: 第 1 回
こんにちは。コミュニケーションアプリ「LINE」のモバイルクライアントを開発している石川です。 私達は、高い開発生産性を維持するために、コード品質と開発文化の改善に注力しています。 そのために様々な取り組みを行っているのですが、その 1 つとして Review Committee の活動があります。 Review Committee では、マージ済みのコードを再度レビューし、レビューアとオーサーにフィードバックしたり、レビューで集めた知見を Weekly Report と称して毎週共有したりしています。 この Weekly Report で共有される話題は、Android や iOS といったプラットフォームや、Kotlin や Swift 言語固有の注意点も含まれるのですが、多くの場合はプログラミング一般に適用できるものになるように配慮しています。（ただし、説明のために使うコードは Ko
【日本人エンジニア必携】英語命名規則の決定版 - Qiita
弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 はじめに 英語での適切な命名は、コードの可読性や保守性を向上させるために重要です。適切な命名規則を守ることがコードの理解や共有において不可欠です。 英語での命名規則を学び、適切な命名を行うことで、コードの読みやすさや保守性を向上させ、チーム全体でのコードの理解を促進する手助けとなります。 この記事では、日本人エンジニアが英語での命名規則を理解し、適切な命名を行うための指針を提供します。 命名フローチャート 変数 関数 クラス 1. 変数 1-1. boolean 1-1-1. 存在するかどうかのフラグ 名詞 + exists
t_wadaさんと「単体テストの使い方/考え方」の疑問点についてディスカッションしました - DeNA Testing Blog
こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
分岐を丁寧に扱う理由とその方法〜ソフトウェア設計のきほん〜
はじめに この記事ではソフトウェア設計において 分岐を雑に扱うとどうなるのか 分岐を丁寧に扱うため方法とは 分岐を丁寧に扱うと何が得られるのか についてまとめました。 動画も作ったのでご覧ください ❌分岐がネストになって読みづらいclass DeliveryUseCase { fun delivery( deliveryDate: LocalDate, purchaseAmount: Int, previousMonthlyTotalAmount: Int? ): String { val today = LocalDate.now() var canTodayDelivery: Boolean var postage: Int if (previousMonthlyTotalAmount != null) { if (previousMonthlyTotalAmount >= 10_00
少しずつ育てるGo言語のプロジェクト構成
23/9/21追記：この記事を読む前に ついにGoチームから、プロジェクト構成に関するガイドが公開されました！ 本記事を読んでくださることも大変嬉しいですが、ぜひこちらのガイドもご一読ください！ この記事は何 Go言語を書いたことがある方も、興味はあるけど触ったことがない方もこんにちは。 Goに限った話ではないと思いますが、ガリガリコードを書いていて、あるタイミングで気になるのがプロジェクト構成（ここではディレクトリ構成の意図）ではないでしょうか？ それを裏付けるかのように、Go界隈では以下のリポジトリが話題に上がることがあります。Star数すごいですね😇 リポジトリ名から公式感が漂いますが、そういう訳ではないのがミソです。 こちらのリポジトリ冒頭にも記載されていますが、次の点に留意する必要があるでしょう。 これは、Goアプリケーションプロジェクトの基本的なレイアウトです。これは、コアと
強い思想: Go を Web 開発に採用する上で
Go は Web 開発に向いているか？ 最も向いている領域は「CLI ツール」「ミドルウェア」「マイクロサービス」だと思っている。なぜならそれらはコードベースを比較的小さく抑えることを前提としているからだ。 Go は大きなコードベースを抱えやすい設計の言語になっていない。 ミドルウェアとマイクロサービスに関しては小さく作ることが正義。 CLI ツールに関しては単一責務なツールであれば小さくなるが，複数を束ねるツールであっても Web サービス開発に比べれば考えることは少なくて済む。 Web 業界における「一般的な Web 開発」，すなわちモノリスを基本とした中規模以上の開発にははっきりと 向いていない と言うべきだろう。 フラットパッケージは正義か？ 私が SNS で何度か言及した以下の記事がある。 フラットパッケージ戦略は，確かに Go の文化圏においては一定の支持を集めている。Go の
今さら聞けないログの基本と設計指針 - Qiita
ログの出力場所 ログは、開発者や運用担当者が見つけやすい箇所に出力することを原則としましょう。ファイルに出力する場合は、logディレクトリなどを作成しておくことをお勧めします。基本的に、出力先は以下の4つが想定されます。 ・ファイルに出力する コンソール外で起動するアプリケーションに使用される方法です。 ・標準出力 コンソールから起動するアプリケーションで使用されます。途中経過などを出力するための出力方法です。 ・外部ログ管理ツールのファイルに出力 外部のログ管理ツールを用いることが可能な場合は、専用のログ記録場所に出力することを推奨しています。 ・外部システムへ出力 開発者・運用者の作業やコミュニケーションを円滑に行うために、Slackなどのチャットツールに出力するケースもあります。ただし、稼働率に注意する必要があり過度なログの出力は控えるようにしましょう。 基本的に、外部ログ管理システ
設計/コードレビューで"常に"心がけるポイント - little hands' lab
株式会社ログラスの松岡(@little_hand_s)です。 little-hands.hatenablog.com ↑の記事でドメインオブジェクトの設計方針を書きましたが、それ以外の全般的な設計/レビュー観点について書きます。 非常に汎用性のある内容なので、数多くのプログラミング原則を覚えるより、まずこの観点でチェックできるようにすると即効性が期待できます。 前提として、階層化されたアーキテクチャ(オニオンアーキテクチャなど)を採用しているものとします。 ①レイヤーの責務違反の実装をしていないか ②高凝集/低結合になっているか 高凝集 クラスに関して メソッドに関して 低結合 ③ユニットテストを書きやすいか 合言葉 筆者執筆書籍 現場での導入で困ったら ①レイヤーの責務違反の実装をしていないか 例として、「ユースケース層にドメイン層のルール/制約に関わる実装をしている」場合はNGです。
クリーンアーキわからんかった人のためのクリーンじゃないけどクリーンみたいなオニオンに見せかけたSOLIDの話
依存関係逆転則含む諸原則に苦しめられた方々，いかがお過ごしでしょうか． 今回はアプリ設計の話です．と言っても，前回「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」というZenn記事を書いて，反響が大きかったのでリメイクしたいなという気持ちになり執筆することにしました． 前回同様，調べていく上で誤解していた部分や理解しにくかった部分を語った上で，オニオンアーキテクチャという，クリーンじゃないけどクリーンみたいな玉ねぎについて紹介するのですが，今回はわかりやすい図解であったり，実際にどのような実装をしていくべきなのかを話の話題として加えていければ良いかな？って思っています． これは前回の記事である「クリーンアーキわからんかった人のためのオニオンアーキテクチャ」の記事の裏話的な話を一つさせてください． 今年の11月初め頃に，サポーターズという企業の学生が登壇できるLT会があり，私
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
あなたのPHPアプリ、ログはでてますか？あるいはログをだしてますか？ / Are you writing a log? Or just out a log?
予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022
