【初心者向け】データベースのテーブル設計で僕が意識している6つのこと - Qiita
はじめまして、himakuroです。 2017年ぐらいからQiitaに記事を投下しようと考えていたのですが、なかなか筆が乗らずようやく初投稿です 軽く自己紹介をしておくと、普段は社内SEとしてPHP、Ruby、Golangを書いたり、 趣味の個人ブログ方ではプログラミング初心者に向けた記事や雑記的なものを書いたりしています。 今回は記念すべき1つ目の記事と言う事で 僕が普段テーブル設計（主に命名）で気をつけている6つの事を書きました。 僕の好みも含まれていますが、初心者の方がテーブルやカラム名を決める際の参考になればなと思います。 テーブル名は必ず複数形にする テーブルは一つしかないから単数形を使うべき！ Modelも単数形で定義するじゃん！ みたいな反論が聞こえてきそうですが、僕は複数形で定義する派です。 また複数形にする場合に、テーブル名の途中の部分を複数形にしている物をたまに見かけま
画面をデザインするということ - Qiita
この記事は社内の勉強会で話した内容を再編したものです。 私自身はPC/ブラウザ/スマホのアプリ開発をしている１エンジニアにすぎないのですが、対客や要件定義から開発、運用、そしてUIのデザインを担当しており、自分なりに伝えられるものがないかと試みたものです。 デザインとは デザインとは単に見た目だけの話ではなく、「ビジネス」と「ユーザーが得る体験価値」から始まり、それを実データと結びつけながら人の認知を通してどう見せるのかという作業です。 始まりの部分は最近だとUXデザイナー、終わりの部分はUIデザイナーとかグラフィックデザイナーとか呼ばれるような人の仕事です。そしてそれらを形にするのがエンジニアです。 画面を設計するまでの作業 ギャレットのUX5段階モデルに従って、どういったことを考えないといけないのか確認します。 （実際にUX５段階モデルを意識して仕事してるわけではありませんが、何かしら
Visual Studio CodeでPHPのメソッド一覧を表示する方法 - JavaScript勉強会
PHPのMVCフレームワークを使っていたら、機能を追加するたびにControllerやModelが肥大化していき、自分で書いたコードなのに段々把握しづらくなってきました。(汗) 論理設計はともかく、物理設計では粒度を細かくして、なるべく疎結合になるようにしようと思いました。 jsstudy.hatenablog.com 細かく分けるのは良いけど、メソッドがたくさんあった場合、メソッドの一覧表があって俯瞰できたら便利だなーと思いました。 メソッドの一覧表を作成／表示する機能って、今時のIDEなら付いてるよな？と思って調べてみたらありました！ラッキー！！！ qiita.com Visual Studio Codeの場合、Windowsなら「Ctrl + Shift + o」で表示しているファイル内にあるメソッドの一覧を表示してくれます。 「Ctrl + Shift + o」を押した後、さらに「
基本/詳細設計って呼び方やめませんか - Qiita
システムエンジニア Advent Calendar 2016 の 15 日目です。システムエンジニアなら避けては通れない設計について考えたことを書いてみようと思います。 設計ってむずかしい システム開発の様々な局面で「設計ってむずかしいなあ」と思うことがあります。細かいところはシステムの規模や自分のポジションによって変わりますが、だいたい以下に挙げたようなことで困ることが多いです。 設計 なにを、どこまで、どんなフォーマットで書くといいんだろう？ 各ドキュメントはどうやって関連付けるといいんだろう？ 基本設計書と詳細設計書はなにが違う？ 開発 なんでこういう設計になっているんだろう？ 設計されていない組み合わせのデータはどう処理すればいいんだろう？ 試験 試験データのパターンや量はどれくらい用意すればいいんだろう？ 運用 設計と実装が乖離していてなにが正しいのか分からない... 仕様変更や
古めの組織に導入する自動テスト・アンチパターン集 - Qiita
アジェンダ そもそも、なぜ自動テスト？ 自動テストと騒ぐと冷たい目で見られる事もあるという話 個人・組織としての失敗談と、その処方箋 書かないこと テストがないレガシーコードにテストを組み込む方法については、触れない そもそも、なぜ自動テスト？ 自動テストは、うまく導入すれば、プロダクト品質の担保とユーザへのデリバリー速度に大きく寄与することが分かっているため。 Web業界の先端が、自動テストの効能を体現してる たとえばこんなフロー テストコードを書く プロダクトコードを書く テストコード、プロダクトコードをコミットしてプルリクを出す プルリクをマージすると、CI環境がロジックのフルテスト、UIのフルテストを走らせる テストが全部通ったらそのまま自動的にデプロイする コンピュータに任せられることは全てコンピュータに テスト実施は単純作業なので、人間が実施しなくても良いようになっている 人間
DB スキーマ設計のガイドライン - Qiita
この記事は、2011年頃に書かれた Yii framework サイトの wiki 記事 Guidelines for good schema design の翻訳です。 もともとは Yii 1.1 のために書かれたものですが、Yii 2, Yii 3 にもそのまま適用可能ですし、もっと広く、アクティブ・レコードのような ORM 一般に通用する内容であろうと思われます。つまり、以下の文章中の "Yii" という名前は、あなたが使っている任意のフレームワークの名前に置き換えてもよい筈です。 はじめに 事実上すべての Yii アプリケーションはデータベースの上に構築されます。Yii はデータベースの取り扱いにおいて非常に柔軟ではありますが、以下に述べる設計上の選択をすれば、そうでない場合に比べて、ものごとがより一層都合良く進みます。 最初に、ごく大まかに言うと、Yii アプリケーションではアク
テスト仕様書 - Qiita
単体テスト 結合テスト システムテスト（機能テスト、負荷テスト、ボリュームテスト、セキュリティテスト、リグレッションテストetc) 受け入れテスト（シナリオテスト） 運用テスト 現場（案件）によっては、「開発エンジニア」 が一連のテストしたり、また 「QAエンジニア」 がテストしたりと異なります。 私の意見としては、 「開発エンジニア」 「QAエンジニア」 双方が確認すべきではないかと。 単体テストの実施は、開発者が担当します。 また、結合テスト（Integration Test）以降のテストはQAエンジニア、もしくはQAテスターが担当する。 単体テストのルールや網羅性は開発とQAが一緒に考えることが品質を良くする上で大事です。 お互いテストの意義というものを見直すこともできます。 また、詳細仕様を把握しているPM、Pdmや開発者。テスト設計やテストの種類を知っているテスト担当者が協力しあ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベースオブジェクトの命名規約 - Qiita