![数十億のレコードを持つ 5年目サービスの 設計と障害解決](https://cdn-ak-scissors.b.st-hatena.com/image/square/beb5fd776cc9fdf89541a1cccbf3c25fe3487677/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F14110a5448eb43a3bbdc365f3826967a%2Fslide_0.jpg%3F27606757)
Vue.jsを使った開発でよく悩まされるのがコンポーネントの肥大化です。複雑なアプリケーションになると、1つのコンポーネントが<script>ブロックだけで数百行…なんてこともめずらしくないでしょう。従来、Vue 2までの標準的な書き方では、UIとしてのコンポーネントの細分化はできてもロジックの分割や整理には限界がありました。しかし、Vue 3のComposition APIを活用すると、はるかに柔軟な整理・分割が可能です。 「Composition APIは難しそうだからまだ使っていない」という方、あるいは「導入はしているけどイマイチメリットがわからない」という方は、この機会にぜひComposition APIを活用したコンポーネントの整理術を試してみてはいかがでしょうか? なぜ、Vueのコンポーネントは肥大化するのか? 簡単な例を見てみましょう。下のサンプルはミニマムなアナログ時計のコ
とある技術課題を受けたけど落ちてしまったのでここで供養する。 課題内容 チャット機能を実装する。必要なテーブル/APIを設計し、APIドキュメント/テーブル仕様書を作成。 LINEのように、1対1のチャットとグループチャット 基本的な投稿機能の他に、既読機能/通知機能/メッセージ削除機能が必要 データベースはRDBのみを使う前提 余裕があれば以下の課題を追加で。 ユーザーの数が膨大になり、パフォーマンスが落ちてきた際に、どのようなアプローチでそれを解消するか? 自分の解答 DB設計 API設計 フィードバック内容 以下の点で高負荷な環境を想定したシステム構築の経験が足りないと判断 DBテーブルのPrimaryKeyに連番を設定しており代替案が無かった点 Push通知送信機構をAPIセッションの中に持つ設計をしていた点 将来的にSQLとNoSQLを組み合わせた設計をすることが想定されていなか
はじめましてこんにちは。 夏が本気を出してきて最近麺類しか口にしていないサーバサイドエンジニアのかしまです。 この度APIにてHTTP Status Codeとは別に、例外に対応するエラーコードを返すよう奮闘したのでその知見を共有したいと思います。 やりたいこと APIにて例外が発生した場合、以下の形式でレスポンスを返すようにします。 { "errors": [ { "code": "code1", "message": "message1", }, { "code": "code2", "message": "message2", }, ] } Why? 今回追加したAPIは外部のアプリケーションとの連携に使うため、以下の要件を満たす必要がありました。 クライアントサイドがハンドリングしやすいような設計にする エラーの識別子は不変であること そのためエラーメッセージとは別に、コードを返す
先日、友人とUnityの話をしていると、「うちではシーンは1つしか使わないよ~」と言われました。 僕はマルチシーンでの制作しかしていなかったので、かなり衝撃的な発言でした。 というわけで、その手法についていろいろ調べてみたのでまとめてみます。 でも検索しても海外サイトでしか情報が出てこないんですよねえ 単一シーン構造とは ? メリットは何? どうやって実装する? オブジェクト同士のやりとり スクリーンの管理 デバッグ まとめ 参考 検索キーワードを絞り込んだ結果、どうやらシーン1つを使用する手法は、「Single Scene Architecture」というらしい。 和訳すると「単一シーン構造」 でしょうか? どうやら、Unity Technologies社のBrett Bibby氏が2014年に紹介したものらしい。 いったいどういったものなのか見てみましょう。 単一シーン構造とは ? こ
Unityで設計をしたい クラス関係が複雑になり、どこかしらに重複したプログラムが量産され、 循環参照が起こってしまっています。 他人のソースコードは読み辛いものになってしまうことが多いです。 設計をしないと駄目だ……。 私はそう思って、Unityの設計について調べ始めました。 今回はUnityのMVPとMV(R)PについてWeb上で載っている記事を見比べ、 「その上でこうしたら良いんじゃないか?」という私独自の考えたMV(R)Pの設計の公開をします。 Unityで設計をしたい いくつかの記事 Web出身のUnityエンジニアによる大規模ゲームの基盤設計 Unityで学ぶMVPパターン ~ UniRxを使って体力Barを作成する ~ 初めてのUniRx + MVP(Model View Presenter)(Unity 2017.1.0) UniRx 4.8 - 軽量イベントフックとuGU
Pixel Watch 勢いに乗って購入したものの使い道がいまいち思いつかない皆さんこんにちは。あまり使いこなせていないのですが、とりあえずオプションで購入したオレンジバンドが上下で色が微妙に違うのが気になります。 デザインパターン システム開発の現場でオブジェクト指向のプログラミング言語が広く普及したことにより、それを利用した設計方針(デザインパターン)が提案されるようになりました。 デザインパターンとは一言で言うと、設計のノウハウ集で過去のエンジニアが使用してきた設計方法を分類別に纏めたものです。 最も有名なのはGoF(Gnag of Four)のデザインパターンで「生成」「構造」「振る舞い」の分類別に23のパターンが紹介されています。 一昔前まではこのデザインパターンはオブジェクト指向による設計の基礎知識となっていたので職場の研修や学校の授業等で履修した方も多いと思います。 しかし、
はじめに こんにちは!クライアントチームの♂Natsuki♂です。 以前は野生のUnityプログラマーとして我流でコードを書いていましたが、今は昔、 最近では設計・実装の知識も身についてスーパーインテリジェントプログラマーになりましたので、そのあたりの話をしようかと思います。 真面目な話をすると、今回はUnityにおけるMVPパターンの話をしたいと思います。 MVPパターンを用いることで、クラスの責務や依存関係が整理されて「いい感じ」のコードが書けるということをお伝えできればと思います。 対象読者 この記事は以下のような方を対象としています。 我流でコードを書いてる人 何らかのパターンを使って設計・実装してみたい人 クラスの責務や依存関係を整理したい人 MVPパターンとは MVPパターンとは、ざっくり言うとModel(データ)、View(表示)、Presenter(両者の仲介役)という役割
はじめまして。そーだい(@soudai1025)です。私は普段は技術コンサルティングや受託開発を請け負う合同会社HaveFunTechの代表として、また、予防治療の自社サービスを展開する株式会社リンケージのCTOという二足の草鞋を履き、日々、さまざまなWebサービスの開発に携わっています。 これまでの開発経験のなかで、データベース設計に関わるさまざまな問題に遭遇してきましたが、本稿ではとくに、アジャイル開発時に発生しやすい問題とその対処についてお伝えしたいと思います。開発の現場で目にしやすい実装におけるアンチパターンを示しつつ、アジャイルという指針を維持しながら、対処となるデータベース設計についてご紹介します。 会員登録のアンチパターンと処方箋 イージーな実装とシンプルな実装 Userと言う名の罠 拡張と破綻 データベースは変化に弱い 仕様変更とテーブル変更 Addで変化に追従する 正規化
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
このエントリは Ruby on Rails Advent Calendar 15 日目です。(遅くなってすいません) 同時に 14 日目のじょーかーさんのエントリへのアンサーエントリでもあります。 (まあ、じょーかーさんがこの Advent Calendar に登録したときに、タイトルから内容を推察してこれを書くことを決めましたが、実際のところ、あまりアンサーにもカウンターにもなってないし、全然関係ない内容と言えないこともないので、まあサービスクラスについては僕も推奨したことがあるし、僕も反省してるんですよ程度に読んでもらえると幸いです。) まずはじめにごめんなさい 3 年くらい前に僕は Rails にサービスクラスというものを導入するといいことがあるよと書いたのだけど、それからいくつもの Rails アプリケーションを見たり、実際に自分で開発したりして、うーんって思うことも増えてきたので
この記事は Android Advent Calendar 2016 2日目の記事です。 こんにちは。わくわくです。 現在お仕事で書いているアプリを新規で書き始めたのが2015年で、現在は2016年です。 そう、1年が経ちました。その頃から今まで書いてきて、今から書くならこんなライブラリや設計を採用するよ(したいよ) というのをまとめたいと思います。 これからAndroidアプリを書くけどどんなものつかっていけばいいんや〜?といった方の参考になれば幸いです。 すでにAndroid開発をされている方にとっては内容が薄く感じられることと思いますがご了承いただければと思っております…(予防線) (裏の目的としては自分の備忘録のようでもあったりします。) この記事では紹介しているライブラリや設計などに関しては深くは説明を書きませんが、参考になる資料などをまとめて行ければと思っております。 言語につ
みなさま、こんにちは! Cygames Research 所属、エンジニアの和泉澤と申します。 ゲーム業界歴20数年。メガドライブの時代よりゲームプログラミング一筋です。 時折、幾つかの知見をご紹介させて頂けましたらと思います。 ゲーム制作における内部実装には、古今東西、様々な方法論が存在しています。 アクション、RPG、カードゲームやアドベンチャーゲーム等、そのジャンルにより採択される方法は多種多様でありますが、制作するゲームの持つ特徴を良く理解し、そのゲームに適した設計を行うことは、ある種、ゲームプログラミングにおける醍醐味とも言えましょう。 アクションならばこの実装方法、RPGならばこれ、等といったような一意の方法論は勿論在りません。しかしながら、ゲーム業界黎明期より無数に生み出されたゲーム制作の歴史の上に、効率的な方法論というものは、ある程度通例として積み上げられています。 極シン
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く