超入門！テーブル設計をデータモデリングから考えよう
基本から学ぶ テーブル設計 超入門！ 〜データモデリングとテーブル設計の基本を学ぼう〜 https://modeling-how-to-learn.connpass.com/event/242944/ にてお話した際のプレゼン資料です。 入門者に向けて、テーブルを設計する上でモデリングすると良いよという話をしました。（熟練者は、そうだよねーっておさらいするか、そこは別の考え方があるんじゃないなどを呟いて貰えればといった内容です） モデリングして設計する際に、色々なモデルがあります。その中で、データモデルは静的な要素が強いモデルなので、モデリング全般を考えた際に、入門者にとって捉えやすいのではと考えています。 テーブルを設計する上で、データモデリングをしてデータモデルを作ることで、より良いテーブル構造を考えやすくなります。 #テーブル設計 #モデリング #データモデル #RDRA #概念モデ
設計を学びたいときに読みたい本一覧 - Qiita
これは何 の参加記事です。 エンジニアとして開発をしていく以上、設計についての知識を身につけていくことはとても重要です。 とはいえ設計という言葉からは何を勉強するべきかがいまいちピンときません。 この記事では、僕が読んできた設計に関するおすすめの本を網羅的に紹介しています。 これから設計を勉強する方の役に立てれば幸いです。 おすすめの本一覧 おすすめの本を紹介していきます。 他にもおすすめがあればぜひ編集リクエストをください！ オブジェクト指向設計実践ガイド 設計を始めに学ぶならこれ、という一冊です。 エンジニアとして開発を行なっている中で、オブジェクト指向設計は一番汎用的に使う設計知識なのではないでしょうか？ オブジェクト指向設計を学ぶことで、いわゆる「におう実装」と「良い実装」を見極めることができるようになると思います。 知らなかったら読んだほうが良いキーワード SOLID原則 Cle
髪型別コーデ検索におけるSPAの開発 - ZOZO TECH BLOG
こんにちは、WEAR部の繁谷です。 普段はバックエンドのエンジニアとしてWEARの開発を行っています。 ZOZOテクノロジーズは4月7日に「髪型別コーデ検索」をリリースしました。 プレスリリースは是非こちらを御覧ください。 髪型別コーデ検索のフロントエンドはSPA(Single Page Application)でつくられており、こちらの開発を行った際に意識した設計について紹介します。 はじめに 髪型別コーデ検索は、ZOZO研究所の福岡チームが研究・開発したAIを活用し髪型からコーディネートを検索するAPIを利用して、SPAのWebサービスとして提供しています。 こちらは髪型別コーデ検索のアーキテクチャを簡単に示したものです。 今回私は研究所が提供するAPI以外のエンジニアリングに関する部分である、バックエンドのAPI開発、フロントエンドの開発、それらのインフラ構築を担当しました。 その中
RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
個人的なアプリケーション設計のバイブル3選 - Runner in the High
自分が本格的に設計を意識するようになったのは、2015年の夏に現職であるFringe81株式会社で開催されていたサマーインターンに参加してからだ。 インターンではDDDとクリーン・アーキテクチャ*1を一から勉強してAPIサーバーに実装する、というカリキュラムであったが、いま思うと2週間という比較的長いインターンで僕が学べたことと言えば本当に微々たるものだった。つまるところ、それくらいには設計というものは奥が深い。常になんらか特定のデザイン・パターンなりアーキテクチャ・パターンを適用することでアプリケーション開発がうまくいくということはなく、それらの様々な知識から少しづつ応用されたものが最終的なアプリケーションの設計に対して真の洞察を与えてくれるものというのが、僕自身のいまの認識である。 設計はまさに Connecting the dots そのものだ。多くを知れば知るほど、アプリケーション
ソフトウェア設計の学び方を考える
ソフトウェア設計の課題 ソフトウエア設計の品質 学習と成長 設計の初歩を学ぶ 中級者への道 上級者の挑戦Read less
Androidアーキテクチャことはじめ ― 選定する意味と、MVP、Clean Architecture、MVVM、Fluxの特徴を理解する｜ハイクラス転職・求人情報サイト AMBI（アンビ）
Androidアーキテクチャことはじめ ― 選定する意味と、MVP、Clean Architecture、MVVM、Fluxの特徴を理解する Androidアプリの開発において悩ましいアーキテクチャの選定。本記事では選定する意味を改めて整理し、 MVP・Clean Architecture・MVVM・Fluxといった最新の実例を紹介します。 はじめまして。Androidエンジニアの藤原聖（ふじわら・さとる／@satorufujiwara）です。 現在は株式会社サイバーエージェントで、エンジニアリングマネージャーを兼任しています。2017年で35歳になり、定年を迎えました（プログラマの定年については「体型を支える技術」などを参照）。 Androidアプリ開発には2010年から携わっていますが、今現在の関心事は何といっても公式開発言語に採用されたKotlin。そしてもう一つが、Androidの
設計サンプルで学ぶ、AWS構築の原則 - Webアプリ アーキテクチャのベストプラクティスを理解する - エンジニアHub｜若手Webエンジニアのキャリアを考える！
設計サンプルで学ぶ、AWS構築の原則 - Webアプリ アーキテクチャのベストプラクティスを理解する AWS入門者に向け、同サービスのエキスパートである、クラスメソッドの八幡豊さんが、Webアプリケーション開発のためのAWS構築の基本を解説します。広範な領域をフォローするAWSですが、広範ゆえに、なにをどのように選ぶべきか……。こんなお悩みを持つ方はぜひご一読を。 クラウドコンピューティングサービス・Amazon Web Services（以下、AWS）は、数多くの高機能なクラウドサービスを簡単に利用できることから、多くの企業が導入しています。AWSの知識を身につけることは、いまやエンジニアにとっての必修科目です。 そのサービス範囲は広範にわたることから、「なにを」「どうやって」使うかのかが重要な知識になってきます。AWSの各サービスのポテンシャルを引き出すためには、それぞれの長所・短所を
DBの寿命はアプリより長い！ 長生きするDBに必要な設計とリファクタリングを実践から学ぶ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
DBの寿命はアプリより長い！ 長生きするDBに必要な設計とリファクタリングを実践から学ぶ アプリケーションの寿命よりも長く、データの追加やテーブルの変更で成長し続ける「データベース」と、どのように付き合っていけばよいのでしょうか？ 曽根壮大（soudai）さんによる寄稿です。 こんにちは。そーだい（@soudai1025）です。 新しいサービスを始めるとき、必ずと言っていいほどデータベースは利用されています。また今稼働しているサービスの多くでも、RDBMSをはじめ、いろいろなデータベースが利用されています。そんなに広く利用されているデータベースだからこそ、多くの問題の元になるのもまた事実です。 そこで今回は、Webサービスを中心にデータベースの選び方、設計についてお話していきたいと思います。そして私もまさに今、2011年から続くWebサービス「オミカレ」のRDBMSのリファクタリングに携わ
Microservicesでなぜ作るのか - An Epicurean
「Microservices時代の監視設計」と言うエントリーを書きたいのだけど、そもそもなんでMicroservicesで作る必要があるのかというところを先に書く必要があると感じたので私見を述べてみる。すでにMicroservicesで作っている人からすると「何をいまさら」と言う内容も多いかもしれません。 Microservicesでなぜ作るのか ドメイン分割のレイヤーの変遷 今は成長段階 Microservicesのメリットとアーキテクト クラウドはフレームワークになった 共有データベースアンチパターンとMicroservices設計 Microservices時代の監視設計 参考図書など Microservicesでなぜ作るのか 身も蓋もないことを書いてしまうと、これはもう「潮流がそうなっているから」ということだと思う。業界がそういうアプリケーションの作り方をしてノウハウを貯めていく流
光を超えるためのフロントエンドアーキテクチャ - Speaker Deck
HTML5 Conference 11/25
アーキ部：テーブル設計をやってみよう！ - そこに仁義はあるのか(仮)
毎週金曜の定時後に弊社でアーキ部なるものが開催されています(✌'ω' ✌) スピードラーニング的に@kawasimaさんのお話を聞く会ですが、今週はテーブル設計がテーマでした！ この記事がすごく良かったので、触発されてブログ書く！！！ developer.hatenastaff.com お題 ↓のお題が出て、テーブル設計を考えてみるはなし。 要求仕様は以下のとおり。 ・宿の部屋は、シングルやツインのような部屋タイプが設定できます。 ・宿側で宿泊プランを設定できます。宿泊プランは適用される日付が設定できます。 ・プランには複数の部屋タイプが含まれることがあります。 ・宿側でプラン・部屋タイプ・宿泊日ごとに宿泊費の設定ができます。 ・カスタマはプラン・部屋タイプ・宿泊日を指定して宿泊予約ができます。 ・予約は会員でも非会員でも可能です。 ・また、会員・非会員に関わらず、宿をお気に入りに登録でき
Data Models
Data Models: A Comprehensive Guide to Structuring Information for Optimal Insights and Decision-Making In the realm of data management, the use of effective data models plays a pivotal role in organizing and representing information in a structured and meaningful way. Data models serve as the blueprint for databases, facilitating efficient data storage, retrieval, and analysis. This article delves
フロントエンドのコンポーネント設計に立ち向かう - Qiita
ReactやVueなどコンポーネントベースで作っていくViewのライブラリが普及したことで、コンポーネント指向での開発が一般化してきた昨今のフロントエンドですが、このコンポーネントの設計に悩まれる方も多いのではないでしょうか。 コンポーネントをどの粒度、どんな状態で分割するのが良いのか、などなど、特にチームで開発する時に認識が揃っていないとカオスになりがちな部分であると思うので、自分なりの設計をする際の指針を言語化しようというのが本記事の目的です。同じように悩まれている方にも何らか示唆を提供することができたら嬉しいです。 想定読者 「コンポーネント設計？なにそれ？おいしいの？」という方 初めてコンポーネント設計でアプリ作ってみたけど、本当にこれでいいのか自信の無い方 はじめに: "コンポーネント"とは まず最初に"コンポーネント"という言葉についてですが、ここでは「GUIのパーツをモジュー
コマンドラインツールを作るときに参考にしている資料 | SOTA
コマンドラインツールについて語るときに僕の語ること - YAPC::Asia Tokyo 2014 コマンドラインツールが好きで昔からつくってきた． 今年のYAPCで，そのコマンドラインツールをつくるときにどういうことを意識して作っているのか？どのような流れで開発しているのか？といったことを語る機会をもらえた． 具体的な内容については，是非トークを聴きに来てもらうとして， スライドをつくるにあったって過去に読んだ資料や，よく参考にしている記事を集め直したので，その一部を参考資料としてまとめておく． UNIXという考え方 UNIXという考え方 Mike GancarzによるUNIXの思想や哲学をまとめた本．古いが全然色あせてない． コマンドラインツールの作り方を書いた本ではないが，これらの思想の上で動くツールはこの思想に準拠して作られるべきだと思う．何度も読んで考え方を染み付かせた． 小さい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - Katsukiniwa/awesome-software-design-ja: 日本語でのソフトウェア開発・設計に関する記事や書籍をまとめたリポジトリです
CSS設計全盛期に学ぶフロントエンド設計
Vue.js設計地図 〜設計概念の依存関係からフロントエンド設計を見つめ直す〜
アンチパターンから学ぶ RDBの正しい設計 / learn-from-failure-2
設計ガイドライン
