IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
Bootstrap と BEM を組み合わせた CSS 設計パターンについて考える | PSYENCE:MEDIA
前置き - CSS 設計が難しい件について 誤解を恐れずに言うならば、CSS は変数も関数も条件分岐もない、ある種ゆるふわな言語（仕様）といえます。そのためプログラミング言語のように記述ミス一つで全ての挙動が止まるなんてことはありませんし、いくら冗長に記述しようがブラウザ上での挙動に差異が生まれることも殆どありません。ちょっと嗜めばそれっぽいものが作れてしまうので、マークアップエンジニアのいない小規模体制の組織であれば、サーバーサイドエンジニアやデザイナーが片手間で習得して実装してしまうというのも珍しいことではないでしょう。それでも良かったのかもしれません。これまでは…。 片手間で学習した知識というのはなかなか体系化されないものです。CSS も御多分に漏れずプログラミングのテクノロジーは日進月歩なため、その時は最新だった技術が僅か一年も経たないうちに廃れてしまい、バッドノウハウ化してしまう
CSVってなによ状態で困ってます
俗にいう「使えないシステム」ってやつをつかまされたのかもしれない。 今、WEBアプリみたいので、業務ツール作っているんだけど完成が見えてきた段階で実はボロボロのものが出来上がってることに気が付いてきた。たとえば月報とか日報みたいなアウトプットが必要なデータが10種類ぐらいあるんだけど、全部CSVっていう言語でしか出せない。CSVをエクセルで開くとところどころ文字化けになってて全然使えないし、そもそも罫線もないしページングもされてない。社外のコンサルに聞いても、CSVは機械同士がやり取りするための言語で、人が使うデータはエクセルで出せるようにするのが普通って言っている。ベンダーにそういったら「それは無理」の一点張り。コンサルはベンダーの瑕疵だからなおさせろ、ベンダーはやらない、で膠着状態。CSVだけじゃなくてほかにも必要な集計が画面上でできなかったり、そもそも機能自体が欠落していたりとかして
クラスの命名のアンチパターン - Qiita
昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParameter FooResult, FooStatistics, FooSummary FooBuffer, FooList, FooCollection, ... ProductListItem, TranslationTableEntry, etc. Prod
詳細設計書ってよくわからない - 未来のいつか/hyoshiokの日記
わたしは、情報システムと呼ばれているものを作った経験がないので、よくわからないのだが、世の中には詳細設計書というのがあるらしい。 下記参照。 http://gm7add9.wordpress.com/2012/11/30/%E8%A9%B3%E7%B4%B0%E8%A8%AD%E8%A8%88%E6%9B%B8/ プログラムの詳細設計をやる人というのがいて、その人が書くらしい。あくまで自分には経験がないので、伝聞、想像でものを言っている。 プログラムの詳細設計というのは、プログラムへの要求仕様というのがあって、それを実現するために書くらしい。要求仕様というのは最終的な利用者が、こーゆーものが欲しいとか、こーゆーことができたらいいなということを、なんらかの方法で、なんらかの形でまとめたものらしい。 そんでもって、要求仕様を作る人と、詳細設計を作る人と、プログラムを作る人と、テストをする人と、
@nippondanji 氏の「データベース設計徹底指南！！」は神プレゼン！脅威の主義主張の一貫性保証は DB エンジニアの鏡だった件！ - #garagekidztweetz
ツイート今日は、第 1 回のSQL アンチパターンの回から良コンテンツを提供しまくりなエンバカデロ・テクノロジーズさん主催の第 3 回 DB エンジニアのための勉強会に参加してきました。 今回は 漢(オトコ)のコンピュータ道で有名な漢の中の漢、 @nippondanji 氏がデータベース設計を徹底指南してくれるということで、元々 DB エンジニアがバックグランドのわたしとしてはいかないわけにはいかんだろう、と喜び勇んでいってきました！ 内容はというと下記の概要をカバーする内容でした。 リレーショナルデータベース（以下RDB）は登場してからかなりの時間が経っています。その名が示すように、RDBはリレーショナルモデルをベースに考案されたソフトウェアです。しかしながら、未だに現場ではRDBが使いこなされているとは言いがたく、リレーショナルモデルへの理解も進まず、誤った常識が跋扈しているのが現状で
価値ある設計書かどうかはIPOで決まる - 現場のためのソフトウェア開発プロセス - たかのり日記
昨日のエントリで、ドキュメント（設計書）の有用性について書きましたが、これはよくある話。 では、どうすれば価値のある設計書になるのかについて、もう一歩踏み込んで考えてみます。 まず、設計書とは、最終的にコードを作成するための成果物であり、価値のない設計書とは、コードを作成するのに役に立たないものだと言えるでしょう。 「顧客にレビューしてもらうため」とか「エンジニア間でコミュニケーションを取るため」といった意見もあると思いますが、それも最終的には、コードまで落とし込むための過程と考えられます。 その設計書を作成する上で、設計技法としては、以下のようなキーワードが必ずと言ってよいほど挙げられます。 構造化設計、DFD、ER オブジェクト指向設計、UML、デザインパターン 設計に関する書籍では、大抵このような設計技法を扱っているのですが、これらのものは、分析や表現に重きがあり、どうすれば良い設計
MVCは死んだ。MOVEするときがきた - きしだのHatena
Conrad Irwinさんの「MVC is dead, it's time to MOVE on.」を訳してみました。 MVC is dead, it's time to MOVE on. この訳文も原文のライセンスを引き継いでCC-BY-3.0ライセンスで利用可能とします。 追記13:58 すでに訳してた方がいました。MVCの時代は終わった。MOVEを使い始めましょう。 - ふじこのプログラミング奮闘記 MVCは死んだ。MOVEするときがきた MVCはすばらしいアイデアだ。モデルを持ち、モデルは内部に少しの状態をもつ。ビューは内部に少しのUIをもつ。そして、コントローラは内部に少しの・・・ 何を持つ？ 私は確かにこのことに気づいた最初の人物ではない。しかし示されたようなMVCの問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいか
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指して
プログラミングと設計は本来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根本的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の
リレーションシップ駆動要件分析(RDRA)の実践 | システム設計日記
採用支援の新サイトの構築プロジェクトが始まった。 * 仕事を探して応募するためのジョブサイト * 求人情報を登録するアプリ * 応募者と採用側の連絡アプリ * 採用側の応募者管理アプリ * サイト運営のための機能 こんな感じで、５つのコンテキストが、関連しあったシステム。 もしかしたら、採用企業側の採用関連システムとの連係も必要になるかもしれない。 コンテキストモデル RDRA の基本ステップ。最初は、「システム価値」を明確にすること。 その中でも、第一歩は、コンテキスト図を描いて、「関連する人」「関連する外部システム」を洗い出して、関係者で共通理解にすること。 募集と採用は、密接に関係しているし、小規模な企業の採用であれば、募集情報をサイトに掲載する人と、それに対する応募に対応して、選考をする人は、同じ人（部門）。 ただ、この二つの業務は本質的に、別の業務。ここらへんの登場人物分けが、最
キャズムを超えろ！ - 団塊～シニア層向けのWeb設計 やっちゃいけない10のＵＩ
一時期パソコン教室の講師をやっていたことによる経験と、昨今Webサービス運用にあたって中高年層からのクレームなどを自分なりにまとめた結果として、50代以上のユーザに対するWebサービス＆PCアプリケーションのUI設計における以下10のTIPSを公開してみたいと思う。...といってもたかだか10個で収まる簡単な話ではないので、思いついたら都度追加して行きたい。 ID，ニックネームを考えさせてはいけない。半角英字開始限定は論外 IDやニックネームが思いつかない方が多い。これはシニアに限らず、ITリテラシーがそれほど高くない若年層についても言えること。作る側の人間も「過去にWebで使ったID,Nicknameは全て使っちゃダメ。何か新しいのを考えて入れてみて。」と言われると結構悩んじゃうもの。それと同じ状態に陥ると思っていただけるとわかりやすい。「IDのかわりに電話番号でもいいですよ」というと結
何故データベース設計は軽視されるのか？
1 ：NAME IS NULL：2008/12/01(月) 01:07:27 ID:X6n/IiFX 何故データベース設計は軽視されるのか？ ここでいうデータベース設計とは、 特定の業務システムにおける テーブルレイアウトを設計し、決める作業であるとします。 業務システムにおいては、 このデータベース設計（テーブル設計）は仕様そのものを定義する作業にも 近いと思いますし、この設計は開発工程やその後の運用における品質を 絶対的に左右するものだと思っています。 逆にこの設計があまりにも実現すべき仕様と比較し不整合なため、 その後の開発工程がデスマーチに陥ることも少なくないのではないでしょうか？ にも関わらず、正規化程度も理解できないような担当者が この設計を行っていたり、業務システムの受託開発において、 「テーブルレイアウトを決める」という作業が、あまりにも軽視されているような 気がしています
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Analyze IT.
IDEA * IDEA