食べログノートでWebSocket不要の(ほぼ)リアルタイム更新を実現した話 - Tabelog Tech Blog
目次 目次 はじめに リアルタイム化の必要性 解決策の検討 予約状況の更新に必要な速度を検討 実装案のブレスト 採用するアーキテクチャの決定 実装の詳細 リリース戦略 リリースによる効果 まとめ 最後に おまけ（メディア掲載の紹介） はじめに こんにちは！ 食べログ開発本部 ウェブ開発1部 FEチームの佐々木です。 私たちが開発している食べログノートは、レストラン向けのオンライン予約台帳です。ネット予約、電話予約、ウォークインの管理、顧客管理、卓管理などを一元的に行えるツールです。 その中でも特に重要な機能がタイムスケジュール画面です。この画面は、食べログノートの中でも最もよく使われる機能です。登録された卓と予約時間を表示し、ドラッグアンドドロップで卓や時間の変更が簡単に行えます。 今回の記事では、このタイムスケジュール画面において、WebSocketを使用せずに（ほぼ）リアルタイム更新を
大規模クラウドインフラ設計・構築案件の歩き方(AWS-28)がインフラエンジニアに刺さりまくりな内容だった | iret.media
AWS Summit Japan 2024 Day1の「大規模クラウドインフラ設計・構築案件の歩き方」のセッションについてレポートです。 控えめに言っても満足度の高いセッションでした。 大規模なクラウドインフラの設計構築運用に関わる方なら首がもげるくらい頷きが多い内容であり、アーカイブが公開された際はもう一度見たいと思うほど…。 セッションの内容には「設計書の一覧サンプル」や、「アプリ/インフラチームの責任分界」といった界隈でも関心が高い内容に触れられています。 考え方のひとつとして参考にしていきたい内容がモリモリでしたので、シェアさせていただきます。 セッション概要 大規模クラウドインフラ設計・構築案件の歩き方 Level 300: 中級者向け スピーカー: アマゾン ウェブ サービス ジャパン合同会社 仲谷 岳志 様 クラウド技術のコモディティ化により、エンタープライズ分野では近年、A
開発生産性を上げるために開発をする前に考えていること - Findy Tech Blog
こんにちは。Findy Freelanceの開発チームでエンジニアをしている2boです。 この記事では私が開発生産性を上げるために開発をする前に考えていることについて書きます。 ここで「開発をする前」というのは次のようなタイミングを指します。 PdMなどから新規施策の仕様について相談を受けたとき 起票された開発Issueを最初に確認するとき 自分がIssueを作成するとき なぜこのタイミングで考えるかというと、開発を進める上での方向性を間違える可能性を減らし後から軌道修正をしやすくするためです。 なおこの記事においては、開発生産性を「開発成果物の提供価値を投入リソースで割ったもの」とします。 いくら頑張って開発をしても、そもそもやるべきことの方向性を大きく間違えると提供価値が0に近づくため開発生産性が低下します。 特に開発が高速なチームで方向性を誤ると高速に間違った方向へ進んでしまうことに
サブスクリプション課金システム開発ケーススタディ - inSmartBank
世はまさに大サブスクリプション時代。この潮流の中で弊社スマートバンクもまた、去る2023年7月12日にB/43プラスというサブスクリプションサービスをリリースしました。 サブスクリプションといえばユーザーに提供されるコンテンツや機能といった直接的な価値に焦点が当たりがちですが、その土台にはサブスクリプションビジネスを成立させるための課金システムがあります。本記事では筆者が行った課金関連の開発を振り返ってみて重要だったポイントや工夫点を伝えてみたいと思います。 すでに世に多くのサブスクリプションサービスがある中で、課金システムの実装はコモディティ化した単純な作業に思えるかもしれません。しかしながら自社サービスにてゼロから実現するとなると、想像よりも多くの思考と意思決定が必要とされる、エンジニアリング観点ではとても奥深い題材といえます。いち開発プロジェクトのケーススタディ、あるいはいちプログラ
サブスクリプション機能制御の設計における勘所 - inSmartBank
こんにちは、スマートバンクでアプリエンジニアをしている ロクネム です。 弊社では B/43という家計簿プリカアプリ を提供しており、つい先日サブスクリプションサービス「B/43プラス」をリリースしました。 このようなサブスクリプションを提供するサービスにおいては、そのサブスクリプションを利用しているユーザーのみが特定の “機能” を使用できるように “制御” する必要があるかと思います。 このサブスクリプションの機能制御を実装するにあたって、「サブスクリプションが有効ではない場合は機能を制限する」という設計では実は不十分で、その他にもさまざまな要件を考慮した上でより柔軟な設計を行う必要があります。 本記事では、このようなサブスクリプション機能制御の設計における勘所について、B/43プラスを例にご紹介します。 ※ 本記事は B/43 Tech Talk 〜 Fintech×サブスクリプショ
クリーンアーキテクチャ完全に理解した
clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心
マイクロサービス設計原則: SOLIDではなくIDEALS
キーポイント For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility. Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to inte
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
