タグ

設計に関するmonomotiのブックマーク (7)

  • RESTful API との比較で GraphQL API を作ることの難しさ|qsona

    上の資料でも書いてるんですが、要点を言うと以下のようなことを主張している。 API の設計手法として、以下の2つのパターンが考えられる ・Resource-based API ・Usecase-based API Usecase-based というのは要はクライアントの要求にそのまま沿った形で API を作るということだ。しかし、UI やその他クライアントの要求というのは変わりやすいものなので、そのたびにいちいち API を変更しないといけないとか、API に一貫性がなくて使いにくいとか、1つの endpoint で多数の要求に対処する "神API" が作られてパフォーマンスが悪化する、というような問題が起こる。 したがって、注意深く RESTful API を設計すると Resource-based になる。ここで言っている Resource というのはテーブル設計にやや近いが、そのまま

    RESTful API との比較で GraphQL API を作ることの難しさ|qsona
  • 誰もがマツダスタジアムに魅了される理由。設計に隠された驚きの7原則

    2017/9/7 12:20  野口学 2009年にオープンした広島東洋カープの新拠地、MAZDA Zoom-Zoom スタジアム広島(マツダスタジアム)。訪れた者なら誰もが魅了されるこの異空間は、日のこれまでのスタジアムの概念を覆すようなアプローチによってつくられた。「スタジアム・アリーナを核としたまちづくり」が経済産業省を中心に進められるなど、今やスポーツの域を超えて大きな注目を浴びているスタジアム・アリーナ建設。今回、マツダスタジアムの設計に関わった株式会社スポーツファシリティ研究所代表取締役の上林功氏が、同スタジアムに隠された知られざる特徴と、未来のスタジアム・アリーナ建設のヒントを明かした――。(取材・文=野口学) 後編はこちらマツダスタジアムは人の意欲を喚起させるスタジアム マツダスタジアムはオープン以来、これまで非常に数多くのファンが足を運んでいる。初年度となる2009年

    誰もがマツダスタジアムに魅了される理由。設計に隠された驚きの7原則
  • in the looop | Looops communications

    ループス・コミュニケーションズは、 企業のSNS活用戦略の立案・運用改善、啓発教育などのコンサルティングサービスや、リーダーシップやイノベーションをテーマとした企業研修を提供しています。

    monomoti
    monomoti 2012/09/05
    いやほんま重要。
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • 複合主キーを避けるべき理由 - 虎塚

    データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 (2011/07/25 追記)複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり

    複合主キーを避けるべき理由 - 虎塚
    monomoti
    monomoti 2011/07/14
    いつも迷うけど、なるほど。
  • memcached を使ったアプリケーションの設計について - blog.nomadscafe.jp

    クライアントからmemcachedを利用する際の、ベストプラクティスは以前書いているので、その前段階でmemcachedを含めたWebアプリケーションのアーキテクチャ(と一部クライアントの話)について今の個人的な考えをまとめてみます。Kyoto Tycoonを使ったキャッシュサーバでも基は同じだと思います 1) 使わない memcachedをアプリケーションに組み込むことで、プログラムがどうしても複雑になりがちです。データの削除や更新の際にキャッシュの更新を忘れると多くの問題が発生します。例えばユーザがニックネームやプロフィール写真を更新したのに画面上変わらないなどの現象が起こると、ユーザに対して不快な思いをさせてしまうでしょう。またデータベースが非同期のレプリケーションを行っている場合、masterに対してデータの変更をかけ、更新が反映される前にslaveから読み込んでしまい、キャッシ

  • Twitterにおける大規模システム構築、3つの原則

    4月に米サンタクララで行われたMySQL Confernce & Expo 211では、TwitterのJeremy Cole氏が「Big and Small Data at @Twitter」と題して、同社のシステムにおける原則とシステム構成について紹介したプレゼンテーションが行われました。 1日に1億5000万以上のツイートが行われているTwitterのシステムはどのように構築されているのか、その内容を紹介しましょう。 Twitterにおける原則 TwitterのJeremy Cole氏。

    Twitterにおける大規模システム構築、3つの原則
  • 1