Yoshitaka Kawashima
clojure java architecture devlove complexity antifragile software design cynefin framework data modeling struts1 jvm excel programming sier 銀の弾丸 design patterns flexibility domain model simple made easy tactical periodization lateral thinking review architecture review drift into failure testing test harness maven jjug ccc chaos engineering simplicity oop yagni waterfall methodology agile software
Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス
読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ
Laravel で DDD のレイヤードアーキテクチャを試す
まえがき 一年半かっちりとした設計を頑張ってみて、なんとなく形が見えてきたので、共有しようと思います。 タイトル通り、DDD の戦術の話がメインです。 いろんなデザインパターンを勉強しましたが、その中でも効果の解りやすいもののみを取り入れることで、迷い少なく方針を決めてこれました。 途中で設計変更は何度も行っていますし、設計変更することを前提に設計してます。 まだ悩んでる部分もいくつかあります。最後の方に書いています。 目的 設計するにあたって、以下の目的が達成できることを重視している。 業務知識があればプログラミングがわからなくてもなんとなくわかるようにする 部品ごとの役割を明確にする 部品を使い回しできるようにする 部品をテスト可能にする 状況に合わせて設計方針をどんどん変えていく 新しい書き方と古い書き方を混在させやすくする リファクタリングしやすくする 使わなくなった部品を簡単に削
code smell リファクタリング[long method編] - kinのリファクタリング日記
記念すべき１つ目は、long methodのリファクタリングを解説をしていきます。 long methodとは なぜcode smellなのか？ long methodになる原因 ソリューション 単純に同じクラス内で、privateメソッドに抽出する。 他のクラスにメソッドを持って行く。 複数の処理をしている場合に、それぞれの処理をメソッドに切り分けてあげる。 まとめ 参考 long methodとは 名前の通り、メソッドに含まれるコードの量が多すぎるということです。 なぜcode smellなのか？ そもそもなぜメソッド内のコードの量が多すぎることが問題なのでしょうか？ 2つの点が考えれると思います。 単純に読みにくいので処理を追いにくい 例えば、同じメソッドを100行ほどのコードが書かれていると、三行目くらいで読むのを諦めてしまいます。 ユニットテスト（UT）がしにくいので、バグの温床
![code smell リファクタリング[long method編] - kinのリファクタリング日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/04c59daf0f5cabff00c546fdfe60086a79b05ff2/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F26006613474644195%2F26006613475874578%2F1577408842)
「SQLアンチパターン」を避けるためのチェックリスト①（DB論理設計編） - log4ketancho
ずっと前から積ん読状態だった「SQLアンチパターン」を読みました。 何年積んでたか分からないSQLアンチパターン読み終わったー。噂に違わずいい本ですねー。もっと早く読むべきだった。— @ketancho (@ketancho) 2018年3月6日 噂通りとても良い本で、まさに「エンジニアとしての血肉本」と言えます。1, 2年目の頃に読んでおくべきだったなーと少し後悔しています。 SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る 読んで終わりだと身につかないと思うので、自分なりのチェックポイントを言語化しておこうと思います。長くなってしまったので、章ごとに4つに分けたいと思います。この記事はその第一弾と
プログラマの抱いている名前についての誤謬
パトリック・ミッケンジー（Patrick McKenzie）さんのブログ・エントリ、 “Falsehoods Programmers Believe About Names” の日本語訳です。翻訳の公開を快諾してくださったミッケンジーさんに感謝します。 公開: 2012-02-22 Posted on June 17, 2010 by Patrick きょう、ジョン・グレアム゠カミング（John Graham-Cumming）が、正しくない文字が含まれているといって彼のラスト・ネームを受け付けないコンピュータ・システムへの不満の記事を書いていた。もちろん彼の名前に「正しくない」ところなどない。当人の申し出たものが当人を識別するものとしては相応しいのであって、定義からして名前とはそういうものである。このことにジョンは当然ながらいらだったし、そうなるのもきわめて正当なことだ。定義からすれば事実
システムで「性別」の情報を扱う前に知っておくべきこと - Qiita
0は性別に関する情報が得られない場合に使います。性別に関する情報はあるのだけど1とも2とも言えない場合は9を使います。要は「0でもなくて1でも2でもなければ9」です。 これを知っていればMだとかFだとかを議論をせずに済みますね。 国際規格に従うべき理由 国際規格に従うことは色々と利点があります。まず、どうしてそういうコード体系にしたのかを説明しやすいです。また多言語対応する際も規格通りに書けば伝わるはずなので迷わずに済みます。別システムへのデータの移行や、異なるシステム間でのデータの統合もコード体系が同じならラクラクです。もしかしたら別のプロジェクトで書いたコードをそのまま使いまわせるかもしれません。技術者に対するトレーニングも不要です。 対して、わざわざ国際規格に反する実装をする場合は上記のメリットがそのままひっくり返ってデメリットになりはしますが、もちろん、それなりの理由があれば規格と
画面遷移に疑問を感じたあなたにオススメするUI Flowsというツール | UXデザイン会社Standardのブログ
2014.11.19 / UI 画面遷移に疑問を感じたあなたにオススメするUI Flowsというツール Tomohiro Suzuki クライアントやディレクターから渡された画面遷移図を元にワイヤーフレームを作ってみると、後から足りない画面が次々に発見された、または画面内の情報がどこに繋がるのか分からないといった経験はありませんか？ この画面遷移図というものは本来は制作範囲の全体像と構造を明確にし、必要な画面というものを洗い出したりするものです。通常のWebサイトであれば、従来のような画面遷移図でも問題ないかもしれませんが、多くのインタラクションが発生するサービスの設計では複雑化しやすく、何度も情報を行き来して確認することになるため時間がかかります。 原因のひとつとして、画面遷移図では画面名のみを記載して繋げていくことになるため、必要な情報が不足していることが挙げられます。その結果、本来で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
)
ドメイン駆動設計(DDD) カテゴリーの記事一覧 - little hands' lab