サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
Yoshitaka Kawashima48 SlideshowAboutPresentationsInfographicsDocumentsLikesAboutSort byLatestMost popularGrokkingSimplicity探訪byYoshitaka Kawashima ブルックスのいう銀の弾丸とは何か?byYoshitaka Kawashima Are Design Patterns Dead?byYoshitaka Kawashima 強いて言えば「集約どう実装するのかな、を考える」な話byYoshitaka Kawashima ソフトウェアにおける 複雑さとは何なのか?byYoshitaka Kawashima Tackling ComplexitybyYoshitaka Kawashima イミュータブルデータモデルの極意byYoshitaka Kawash
読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべてのSQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。RDBMS の対象バージョン PostgreSQL: 9.4 以降MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるものUUID v1: ハードウェアごとにユニークな単調増加値UUID v4: ランダム値UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ
まえがき 一年半かっちりとした設計を頑張ってみて、なんとなく形が見えてきたので、共有しようと思います。 タイトル通り、DDD の戦術の話がメインです。 いろんなデザインパターンを勉強しましたが、その中でも効果の解りやすいもののみを取り入れることで、迷い少なく方針を決めてこれました。 途中で設計変更は何度も行っていますし、設計変更することを前提に設計してます。 まだ悩んでる部分もいくつかあります。最後の方に書いています。 目的 設計するにあたって、以下の目的が達成できることを重視している。 業務知識があればプログラミングがわからなくてもなんとなくわかるようにする 部品ごとの役割を明確にする 部品を使い回しできるようにする 部品をテスト可能にする 状況に合わせて設計方針をどんどん変えていく 新しい書き方と古い書き方を混在させやすくする リファクタリングしやすくする 使わなくなった部品を簡単に削
記念すべき１つ目は、long methodのリファクタリングを解説をしていきます。 long methodとは なぜcode smellなのか？ long methodになる原因 ソリューション 単純に同じクラス内で、privateメソッドに抽出する。 他のクラスにメソッドを持って行く。 複数の処理をしている場合に、それぞれの処理をメソッドに切り分けてあげる。 まとめ 参考 long methodとは 名前の通り、メソッドに含まれるコードの量が多すぎるということです。 なぜcode smellなのか？ そもそもなぜメソッド内のコードの量が多すぎることが問題なのでしょうか？ 2つの点が考えれると思います。 単純に読みにくいので処理を追いにくい 例えば、同じメソッドを100行ほどのコードが書かれていると、三行目くらいで読むのを諦めてしまいます。 ユニットテスト（UT）がしにくいので、バグの温床
ずっと前から積ん読状態だった「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）が、正しくない文字が含まれているといって彼のラスト・ネームを受け付けないコンピュータ・システムへの不満の記事を書いていた。もちろん彼の名前に「正しくない」ところなどない。当人の申し出たものが当人を識別するものとしては相応しいのであって、定義からして名前とはそういうものである。このことにジョンは当然ながらいらだったし、そうなるのもきわめて正当なことだ。定義からすれば事実
0は性別に関する情報が得られない場合に使います。性別に関する情報はあるのだけど1とも2とも言えない場合は9を使います。要は「0でもなくて1でも2でもなければ9」です。 これを知っていればMだとかFだとかを議論をせずに済みますね。 国際規格に従うべき理由 国際規格に従うことは色々と利点があります。まず、どうしてそういうコード体系にしたのかを説明しやすいです。また多言語対応する際も規格通りに書けば伝わるはずなので迷わずに済みます。別システムへのデータの移行や、異なるシステム間でのデータの統合もコード体系が同じならラクラクです。もしかしたら別のプロジェクトで書いたコードをそのまま使いまわせるかもしれません。技術者に対するトレーニングも不要です。 対して、わざわざ国際規格に反する実装をする場合は上記のメリットがそのままひっくり返ってデメリットになりはしますが、もちろん、それなりの理由があれば規格と
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
