タグ

設計に関するdmizuno55のブックマーク (147)

  • いいね(LIKE)機能を実装する~ソーシャルサービス系のDBを構築する - Database JUNKY

    いいねってなに? FACEBOOKですと、いいね、 Twitterだと♥のあれです。エンゲージメント率を高めるばかりではなく、記事の拡散にも効果を発揮しますよね。また、サービス運営者視点で話すと、話題が見つけやすくなりますよね。 ってなわけで、今度はいいね。のデータベース設計をどうするか?というのは試してみたいと思います テーブル設計 構造はいたってシンプルです。 CREATE TABLE `likes` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `article

    いいね(LIKE)機能を実装する~ソーシャルサービス系のDBを構築する - Database JUNKY
  • 契約による設計の紹介 - Hatena Developer Blog

    こんにちは、チーフエンジニアの id:hakobe932 です。 はてなでは毎週、社内技術勉強会を開催しています。先週の勉強会では現在開催中のはてなインターン2016の参加者のみなさんもインターン生も参加して、いっしょに技術交流を行いました。 このエントリでは、そこで発表した、契約による設計の紹介をしたスライドを公開します。 契約による設計はBertrand Meyer氏によるオブジェクト指向入門*1という書籍で紹介されている考え方です。 オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者: バートランド・メイヤー,酒匂寛出版社/メーカー: 翔泳社発売日: 2007/01/10メディア: 単行(ソフトカバー)購入: 11人 クリック: 307回この商品を含むブログ (130件) を見る 契約による設計で

    契約による設計の紹介 - Hatena Developer Blog
  • 「想定外」は工学では最も重い罪: 望湖庵日記 Lakeside Diary

    今回の東日大震災では,たくさんの "想定外" の事象は発生したものですから, "起こさないこと" に重点を置き, "起きた時にどう対処するか" を実に当に考えていなかった結果,深刻な事態が各所で発生しています. 理学の分野では "想定外" は胸躍ることであり,それを常に探し求めることが仕事の重要な一部となります.ニュートン力学が想定していなかったことが次々と発見された19世紀末から20世紀前半にかけて,量子力学や特殊相対性理論という新しいパラダイムが構築されていきました.理学にとっては "想定外" は革新のための駆動力であり,想定内のことしか起きないのであれば,そこで学問は停滞してしまいます. しかし,工学ではそうはいきません.工学はあくまでも実用の学です.私たちが生活する日常空間で,技術的にも経済的にも成立するモノを作り上げ使用していく,というための学問です.基的な性能を発揮するた

    「想定外」は工学では最も重い罪: 望湖庵日記 Lakeside Diary
  • この書籍について · JavaScript Plugin Architecture

    JavaScript Plugin Architecture この書籍はJavaScriptのライブラリやツールにおけるプラグインアーキテクチャについて見ていくことを目的としたものです。 次の形式で読むことができます。 Web版 PDF形式 ePub形式 Mobi形式 GitHub上で直接Markdownファイルを読むこともできますが、その場合はWeb版で読むことをオススメします。 Twitterのハッシュタグは#js_plugin_book 更新情報はRSSやリリースノートから見ることができます。 はじめに JavaScriptの世界では1つの大きなライブラリよりも小さいなものを組み合わせていくようなスタイルが多く見られます。小さなものを組み合わせて作るためには、プラグインと呼ばれる拡張の仕組みが必要となります。またそのようなプラグインがたくさんあるエコシステムの土台を作るには、プラグイ

  • @IT:連載 INDEX - 保守性・拡張性に優れたシステムを作る

    保守性・拡張性に優れたシステムを作る(12): システム開発はなぜ楽にならないか? これまで、連載ではこれまで11回にわたって、システムの拡張性・保守性を考慮するうえで重要になるオブジェクト指向における分析設計の流れや考え方を解説してきた。最終回では、なぜいまもってシステム開発が楽にならないのかについて、筆者の考え方を紹介したい。(2008/7/15) 保守性・拡張性に優れたシステムを作る(11): キミの設計に「トレーサビリティ」はあるか システム開発は5つのステップ(工程)に分けられる。全体の流れを可視化し、それぞれの工程で発生する影響範囲を追跡する。それにより、構築後の保守・拡張性をも視野に入れた作業を行うことが可能となる。(2008/2/7) 保守性・拡張性に優れたシステムを作る(10): ドメイン層をシンプルに作るためのO-Rマッピング (2007/9/13) 保守性・拡張性に

  • 破れ紙の片割れのようなMixinができてしまうワケ - @kyanny's blog

    最近「Mixin は避けられれば避けたほうがよいのではないか」と思い始めている。扱いに困るダメ実装の Mixin を簡単に作れすぎてしまうからだ。 Wikipedia の定義によると、 mixin とはオブジェクト指向プログラミング言語において、サブクラスによって継承されることにより機能を提供し、単体で動作することを意図しないクラスである。 とのことなので、そもそも Mixin される側の実装と結びつきが強くなるのは仕方ないのだろう。しかし、まれにだが破れ紙の片割れのような実装を持つ Mixin ができてしまうことがある。 一枚の紙を適当に手で破って二枚にする。断面はギザギザだが、破った二枚の紙の断面はぴったり一致する。もともと繋がっていたものを切り離したのだから当然だ。だが破れ紙の断面にぴったり合うような別の紙を用意するのは簡単ではない。別の紙を合わせる必要があるのならば、紙を破るときに

    破れ紙の片割れのようなMixinができてしまうワケ - @kyanny's blog
  • DCIアーキテクチャについて語ってみるよ - uehaj's blog

    Trygve Reenskaug氏とJames O. Coplien氏らが提唱する「DCIアーキテクチャ」について、id:digitalsoulさんが論文を翻訳してくださり、またその解説とサンプル実装(groovy, scala)を示してくださっており、読んでみたところ、大変興味深いので理解した限りを書いてみます。 おじさん登場 たとえば、あるおじさんがいたとします。 このおじさんは、白いスーツ、グラデーションの入ったサングラスと金ぴかのネックレスをつけて新宿歌舞伎町に出かけ「やくざ」として振るまいます。とおりかかったお兄さんがそのおじさんに出会い、目が合ってしまい、因縁を付けられ、お金を巻き上げられてしまいます。 さて、おじさんは家に帰ります。実は、このおじさんは家では良いお父さんとして振る舞います。赤ちゃんはこのおじさんの目を見て笑いかけます。おじさんは相好を崩し、オーよしよし。 さて

  • 破綻しにくいCSS設計の法則 15 - Qiita

    ブラウザスタイルは平坦化しておく リセットCSSはオプトアウト可能にしておく 登場頻度の高い組合せはplaceholderとして登録してから利用する 可能な限り画像はスプライト生成してから利用する それ以上分解不可能なコンポーネントは要素のように扱う コンポーネントは自己完結型のものを使う BEMはDRYになるよう粒度を下げる 可能な限り@extendは利用しない レスポンシブでない場所では、Utilitiesクラスを活用する shame.cssはいつも綺麗にしておく 詳細度または特異性の高いものほど後方に記述する 可能な限り!importantしない 可能な限りハックしない 変数をデザインガイドとして活用する CSSファイルを分割するメリットはほとんどないので一つにまとめる 1. ブラウザスタイルは平坦化しておく 例えば、こういうScrap & Buildは単に通信量のムダ。 * { f

    破綻しにくいCSS設計の法則 15 - Qiita
  • Naming -名前付け- - Qiita

    プログラミングで最も重要な技術の一つが、名前付けです。 且つ、センスが問われるものなので、上達は難しいものでもあります。 この記事では、様々な文献から抽出した名前付けに関する情報を雑多にまとめました。 -名前重要- ソフトウェアの設計のアプローチとして、『まず名前から入る』というのは、あまり語られていない秘訣としてもっと広く知られても良いように思います。 - まつもとゆきひろ 『プログラマが知るべき97のこと』 コミュニケーションの基礎 名前は、コミュニケーションの基礎となるものです。 私にもあなたにも名前が無ければ、疎通することは困難になります。 名前をコミュニケーションの基礎と見た場合に重要なルールは以下の通りです。 発音可能であること 検索可能であること ※現実世界のみであれば検索可能じゃなくても良いかも知れません。 プログラミングは、チームや複数人で行うことのほうが多いと思います。

    Naming -名前付け- - Qiita
  • [ 技術講座 ] Domain-Driven Designのエッセンス 第3回|オブジェクトの広場

    DDD難民に捧げる Domain-Driven Designのエッセンス 第3回 大規模なプロジェクトへの適用 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 書籍『Domain-Driven Design』を紹介する連載も、今回で最終回です。前回はDDDの第II部、第III部を紹介し、16のパターンによってドメインモデリングの基的なアプローチを説明しました。今回は、残る第IV部から22のパターンを紹介します。 単一ドメインを扱ったドメインモデリングのノウハウは、前回までですべて終了です。第IV部「Str

    [ 技術講座 ] Domain-Driven Designのエッセンス 第3回|オブジェクトの広場
  • [ 技術講座 ] Domain-Driven Designのエッセンス 第2回|オブジェクトの広場

    DDD難民に捧げる Domain-Driven Designのエッセンス 第2回 DDDの基礎と実践 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 連載は、全3回の予定でEric Evansの書籍『Domain-Driven Design』(以降DDD)を紹介しています。前回はDDDの概要を説明し、第I部「Putting the Domain Model to Work」からDDDの基原則となる3つのパターンを紹介しました。今回は続く第II部と第III部から、(アンチパターンを1つ含む)16のDDDパタ

  • [ 技術講座 ] Domain-Driven Designのエッセンス 第1回|オブジェクトの広場

    DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』(以降DDD)は、「

  • DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism

    この記事はartima developerに掲載されている、Trygve Reenskaug氏とJames O. Coplien氏による記事「The DCI Architecture: A New Vision of Object-Oriented Programming」を、著作権者であるBill Bennrs氏の許可を得て翻訳したものです。文内の図の著作権はArtima, Inc.に帰属します。(原文公開日:2009年3月20日) 要約 オブジェクト指向プログラミングはプログラマとエンドユーザの視点をコンピュータコードにおいて統一するものと考えられていた。この恩恵はユーザビリティとプログラムの分かりやすさの両面にわたる。しかし、オブジェクトは構造をとらえるのに長けている一方で、システムの動作をとらえることができていない。DCIはエンドユーザのロールに関する認識モデルとロール間の関係を

    DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism
  • ServiceとDCIについて - じゅんいち☆かとうの技術日誌

    面白そうなネタがあったので、自分なりの考えをまとめてみる。 Ruby/Rails 用 DI コンテナ Dee をつくった、あるいは Ruby のカルチャーについて この記事はRuby用のDIコンテナの話題なんですが、DCIについても言及されているようです。比較軸はDIそのものというより、サービスとDCIだと思うので、それについてダラダラといくつか考えをまとめてみます。多分も返事になるようでならないかも。それと宗教上の都合でDDDの視点から書きます…。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に”サービス”って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用するためのものです。後者はドメインの知識

  • “確実な記録”こそが、品質・コストに貢献する

    “形だけ”になりがちなソフトウェアレビュー 近年、ソフトウェアレビューに対する認知はますます向上しつつあります。例えば商用開発なら、「要件定義」「設計書」「ソースコード」「テスト計画」「運用手順書」などを対象としたレビューが実施されていますし、オープンソースソフトウェアのプロジェクトなら、ソースコードリポジトリへのチェックインの前にソースコードレビューを推奨したり、義務付けたりしています。 その背景として挙げられるのは、ビジネスや社会におけるITの重要性が高まっていることでしょう。われわれの日常にこれだけITが浸透しているいま、ソフトウェアの品質は、システムの運用に大きな影響を及ぼします。その品質が低下すれば、ビジネスなら機会損失や収益悪化、社会的信用の失墜につながりますし、社会インフラなら公共交通機関などのサービスがストップすることも起こり得ます。ソフトウェアレビューの認知度が向上してい

    “確実な記録”こそが、品質・コストに貢献する
  • 分散システム設計のチェックリスト - ワザノバ | wazanova

    http://monkey.org/~marius/checklist.pdf 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 TwitterのMarius Eriksenは分散システムのエキスパートであり、モジュール化され、安全でかつ効率よく機能するサーバソフトの構築のノウハウは、「Your Server as a Function」という論文にまとめられています。 また、分散システム設計における留意点も、下記の内容のチェックリストというかたちで紹介してくれています。 1. 障害耐性 もし依存先が障害を起こしたらどうなるか?その障害がゆっくりと起きたらどうか? システムをどのようにスムーズにデグレードさせることができるか? システムは想定以上の負荷にどう対処するようになっているか? 大きな障害が起き

  • Web API: The Good Parts

    Web APIの設計、開発、運用についての解説書。APIは設計次第で使いづらいものになってしまうだけでなく公開後の保守運用も難しくなってしまいます。そのためAPIを美しく設計することがとても重要です。書では「設計の美しいAPIは、使いやすい、変更しやすい、頑強である、恥ずかしくない」という考えのもと、APIをどのように設計し運用すればより効果的なのか、ありがちな罠や落とし穴を避けるにはどういう点に気をつけなければいけないのかを明らかにします。ターゲットは、URIにアクセスするとXMLやJSONなどのデータが返ってくるシンプルなタイプ――XML over HTTP方式やJSON over HTTP方式――のAPIです。読者は、Web API設計の考え方と手法を知ることができます。 はじめに 1章 Web APIとは何か 1.1 Web APIの重要性 1.1.1 APIでの利用を前提とした

    Web API: The Good Parts
  • Decomposing Twitter: Adventures in Service-Oriented Architecture

    Decomposing Twitter: Adventures in Service-Oriented Architecture Video and slides synchronized, mp3 and slide download available at http://bit.ly/15yZeLf. Jeremy Cloud discusses SOA at Twitter, approaches taken for maintaining high levels of concurrency, and briefly touches on some functional design patterns used to manage code complexity. Filmed at qconnewyork.com. Jeremy Cloud is the Tech Lead o

    Decomposing Twitter: Adventures in Service-Oriented Architecture
  • backbone.js奮闘記3, 仮想ページング

  • SSSSLIDE

    SSSSLIDE