新人がテーブル設計でつまずいた話 | TECHSCORE BLOG | TECHSCORE BLOG
こんにちは、土屋です。 今回の記事では、私が初めてテーブル設計をしたときに、つまずいた話をまとめてみました。 テーブル設計の経験者の方には、「新人はこんなところでミスするんだ」と知っていただければいいなと思います。 【ミスその1】エンティティの属性の書き方が適切ではなかった 論理名を簡潔に書く 社員情報をまとめるエンティティに、社員のIDを属性として入れたいときがありました。 はじめは属性の論理名を、次のように「社員ID」にしていました。 ですが、「社員ID」ではなく、簡潔に「ID」とだけ書けばOKです(※)。 エンティティ「社員」の属性にIDがあると、それが「社員ID」であるのは自明だからです。 ※必ずしも当てはまるわけではありません。例えば、全てのテーブルで「社員ID」にしておくと、JOIN するときに迷いにくいので便利という意見もあります。 正しい表現か確認しながら物理名を書く 物理
複雑なJavaScriptアプリケーションを考えながら作る話
autoscale: true theme: Plain Jane,5 複雑なJavaScriptアプリケーションを考えながら作る話 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info #jsprimerを書いています JavaScript入門書に興味ある人はウォッチ :star: :warning: 注意 :warning: 作成するアプリケーションによって必要な構造は異なります 今回の話はある程度の規模で複雑性を持つクライアントサイド ライブラリ抜きで数万LOC >= 長期的にメンテンナンスや変更が発生するアプリケーション サーバサイドレンダリングはしないクライアントアプリケーション 3行でOK 複雑なJavaScriptアプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した
「シズル感」と「読みやすさ」ってどうやってデザインで解決する？お菓子専門Webメディアのリニューアルで使った手法 | THE BAKE MAGAZINE
「シズル感」と「読みやすさ」ってどうやってデザインで解決する？お菓子専門ウェブメディアのリニューアルで使った手法 こんにちは、BAKEのデザイナー井手口です。 前職では、グラフィックとウェブデザインの両方を経験できる制作会社に所属していましたが、以前から興味があったブランディングデザインを行いたく、今年の4月からBAKEではたらいています。 BAKEに入ってからは、店舗ブランドで使っている原材料のオリジナルブランド「011」のパッケージ開発や、店舗ブランドのイベント用LP作成やPOPなどのデザインを行いながら、同時進行で進めていたお菓子専門のウェブメディア『CAKE.TOKYO』を8月上旬にフルリニューアルしました。 リニューアルの経緯はCAKE.TOKYOのこちらの記事で書いたので、今回は、サイトのデザインについてデザイナー目線から説明しようと思います。 → CAKE.TOKYO 雑誌の
DHHはどのようにRailsのコントローラを書くのか | POSTD
私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
私がMVCフレームワークをもはや使わない理由
数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM
良いCSSとは - Qiita
CSSはスタイルシート言語です。 プログラミング言語のように記述的(imperative)ではなく、宣言的(declarativ）な言語です。 では良いCSSとはどのようなものでしょうか ？ それはプログラミング言語で良いコード、クリーンコードと言われるものと同じではないかと思います。 クリーンコードは、単純で直接的です。 クリーンコードは、うまく書かれた散文のようにも読めます。 -グラディ・ブーチ CSSはセレクタの命名とその記述方法によってのみ制御されるものです。 その制御はクリーンコードのように「うまく書かれた散文」を目指すべきです。 CSSの原則と設計 CSSはHTMLの見た目を制御する宣言が書かれた文書です。 そしてその設計にはHTMLも含まれるべきです。 CSSの仕組みは単純です。 要素を選択し、定義されたスタイル宣言を適応して見た目を変える。 原則も１つしかありません。CSS
まだ間に合う「CSS設計」ことはじめ。CSSの闇に飲み込まれないための考え方。
WP-D Week Day 2 「CSSについてLevel Up!」での発表資料です。
Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Not Found