「B/43 Tech Talk 〜 Fintech×サブスクリプションサービス立ち上げの裏側〜」にて @ohbarye が"サブスクリプションサービスをつくる時にエンジニアが考えること"と題して発表した資料です。 イベントURL: https://smartbank.connpass.com/event/289643/
![サブスクリプションサービスをつくる時にエンジニアが考えること / Behind the Scenes: Engineering a Subscription Service](https://cdn-ak-scissors.b.st-hatena.com/image/square/d516d45d52e05e4c13b7ac670e1bdb5aaab058d3/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F4dc350cc89e84d9db828ad8bd6600f79%2Fslide_0.jpg%3F26598590)
こんにちは、スマートバンクでアプリエンジニアをしている ロクネム です。 弊社では B/43という家計簿プリカアプリ を提供しており、つい先日サブスクリプションサービス「B/43プラス」をリリースしました。 このようなサブスクリプションを提供するサービスにおいては、そのサブスクリプションを利用しているユーザーのみが特定の “機能” を使用できるように “制御” する必要があるかと思います。 このサブスクリプションの機能制御を実装するにあたって、「サブスクリプションが有効ではない場合は機能を制限する」という設計では実は不十分で、その他にもさまざまな要件を考慮した上でより柔軟な設計を行う必要があります。 本記事では、このようなサブスクリプション機能制御の設計における勘所について、B/43プラスを例にご紹介します。 ※ 本記事は B/43 Tech Talk 〜 Fintech×サブスクリプショ
Already have an account? Sign In This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply. Uh oh… We’re still waiting for our spam prevention code to load. If this message doesn’t go away soon, please ensure JavaScript is enabled, your ad blocker is disabled, and reload the page to try again.
これは designing plus nine Advent Calendar 19日目の記事です。 こんにちは。ritarと申します。 今年の10月頃、YouTubeに大きいデザイン変更がありました。 アイコンの変更、角丸やレイアウトなど全体的に一新されているのですが、中でも自分が仰天したのは「アンビエントモード」という新機能です。 アンビエントモードこのモードをオンにすると、動画の下側のUI領域が、まるで動画部分から光が漏れているかのようにじんわりと色づきます。 これを見たとき自分は度肝を抜かれました。なんたってUIの領域にコンテンツの色が侵食しているのです。 これを踏まえて、最近UIと色について考えたことを、UIデザインの歴史を振り返りながら記していきます。先に要点を言うと、UIはどんどん「無色透明」になっていくと考えます。これは「技術が生活に浸透することによってUIは存在感を減らし
※この投稿は米国時間 2022 年 12 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 オンラインで、組み立て式のテーブルを注文したとします。ところが、パッケージを開けてみると、組立説明書が入っていません。完成品がどんなものかはわかっていても、それぞれのパーツをどう組み立てればいいのか、まるでわかりません。設計が不十分な API を使うコンシューマ開発者も、同じような経験をしているといえます。適切に設計された API なら、容易に見つけ、検索してアクセスし、使用することができます。高品質の API は、コンシューマ開発者がアイデアをひらめき、新しいユースケースを作り上げる手助けになってさえくれます。 もちろん、API 設計を改善する方法はあります。たとえば、RESTful のプラクティスに従うなどです。しかし、お客様が知らず知らずのうちに、ちょっとした不便
突然ですが、エンジニアの皆さま、Javaで開発したWebアプリケーションの構成、このようになっていませんか? データとgetter/setterだけのオブジェクト(JavaBean) 画面のコントロールやビジネスロジックの処理はServletが行う データベースのアクセスは、DAO(Data Access Object)に任せる もしそうであれば、そのシステム、ドメインモデル貧血症に陥ってます。 これは、データとgetter/setterだけのオブジェクトを、Anemic(貧血症になって元気がない)オブジェクトと称し、オブジェクトとはいうものの実質的にはデータであり、それをやりとりするだけの手続き型システムなっていることを嘆いたものです。 今回は、本来のオブジェクト指向に立ち返り、そのメリットである高い保守性、再利用性、拡張性を備えた変化に強いシステムを作るための設計方法、ドメイン駆動設計
前回の記事では、デザインにおけるタイポグラフィについて、そもそもタイポグラフィって何?という部分から、その種類などの基本をご説明しました。今回からは2回に渡って、実際にWeb制作時に実践で使えるタイポグラフィデザインについて使い方や方法などを見ていきましょう。 →画像編集機能も付属のサイト作成ツール BiNDupを30日間無料体験 タイポグラフィデザインの使用例 タイポグラフィと難しく言ってはいますが、画像制作ツールでWeb用のバナーやパーツを作ったことがある方なら、実際にデザインに取り入れた経験があると思います。タイポグラフィは文字ですから、Webパーツには必須ですよね。Webで使用するとなると、ビルボードやバナーでのデザインに使うことが多くなってくると思います。 ビルボード メイン画像の上にショップ名とコピーを載せた例 バナー メディアの掲載情報へ誘導するバナー例 →画像編集機能も付属
ほとんどの最新の Web アプリケーションでは、クライアントがアプリケーションと対話する際に使用できる API を公開しています。 適切に設計された Web API には、次をサポートする目的があります。 プラットフォームの独立。 API の内部的な実装方法に関係なく、すべてのクライアントが API を呼び出すことができる必要があります。 そのためには、標準プロトコルを使用し、クライアントと Web サービスが交換するデータの形式に同意できるメカニズムを備えている必要があります。 サービスの進化。 Web API はクライアント アプリケーションから独立して進化し、機能を追加できる必要があります。 API の進化に伴い、既存のクライアント アプリケーションが変更なしに引き続き機能する必要があります。 クライアント アプリケーションが機能を十分に使用できるように、すべての機能が検出可能である
こんにちは。フロントエンドチームの金野と申します。 食べログでは現在、React+TypeScriptでフロントエンドのリプレースを進めています。 以前の記事で、食べログではAtomic Designをどのように取り入れているかの紹介をしました。 しかし、最近のリプレース作業では、Atomic Designとは異なるディレクトリ構造を採用しています。 今回の記事では、「なぜAtomic Designをやめたのか」という理由と、「どのようなディレクトリ構造にしたのか」を紹介します。 Atomic Designを導入したねらいと導入した結果 上記の記事で言及した通り、当初Atomic Designを導入したねらいは以下になります。 1. コンポーネントの責務がより明確になる 2. 見た目の粒度だけでなく、ロジックの責務も明確にできる 3. 「ドメインが入るか/入らないか」。「抽象的か/そうでな
About This Title Pages: 310 Published: January 2018 ISBN: 9781680502541 In Print Domain Modeling Made Functional Tackle Software Complexity with Domain-Driven Design and F# by Scott Wlaschin You want increased customer satisfaction, faster development cycles, and less wasted work. Domain-driven design (DDD) combined with functional programming is the innovative combo that will get you there. In th
はじめまして。TIG DXユニット 1の亀井です。 はじめに みなさん、Swagger使ってますか? Swaggerや周辺ツールについては 某先輩の記事 にて丁寧に解説されていますので、 本記事では実際にSwaggerのスキーマ定義を設計していく上で取り決めた規約について書いてみたいと思います。 前提私が在籍しているプロジェクトでは、REST APIは golang でフロントエンドを Vue.js + TypeScript で構築しています。 短期間・高品質での構築を実現するためにSwaggerを設計ドキュメントとしてだけではなく、コード自動生成やモックサーバーに活用させることで徹底したスキーマファーストな開発を行ってきました。 というわけで、今回は下記のツールを利用することを前提として規約を作成しています。 go-swagger: Goアプリケーションのハンドラ、リクエスト/レスポンス
目次 はじめに Abstract Classパターン Abstract ClassパターンRuby版 (by 助田雅紀さん) Balkingパターン Before/Afterパターン Futureパターン FutureパターンRuby版 (by 助田雅紀さん) Generation Gapパターン Hook Operationパターン Hook OperationパターンRuby版 (by 助田雅紀さん) Immutableパターン Marker Interfaceパターン Monostateパターン MonostateパターンRuby版 (by 助田雅紀さん) MonostateパターンPerl版 (by 宮川さん) Null Objectパターン Null ObjectパターンとSingletonパターン Producer-Consumerパターン Sharableパターン Singl
Googleは、5月19日未明に開催したオンラインイベント「Google I/O 2021」で、新しいデザインフレームワーク「Material You」を発表しました。 Material Youでは、これまでデザインフレームワークによってあらかじめ指定されていたカラーパレットから色を選ぶのではなく、「あなた自身のパーソナルカラーを基に、デザイナーの視点とカラーサイエンスの組み合わせによって作られたカラーパレットを生成することで、あなたがアプリケーションのルック&フィールのクリエイターになる」(Matias Duarte氏)と説明。 そして自動的にそのカラーパレットにUIが適合していくとのこと。
Web・IT・AI・デジタル・テクノロジー・通信関連 サービス・アプリ・ツール 病院・クリニック・歯医者・医療・薬 学校・教育・幼稚園・保育園・スクール 金融・投資・保険・士業 カフェ・飲食店・食品製造 料理・食べ物・飲み物 建築・建設・不動産・家・庭 商業施設・レジャー施設・文化施設 スタジオ・レンタルスペース・シェアオフィス 暮らし・インフラ・工業・メーカー 車・乗り物・モビリティ 生活・雑貨・おもちゃ・文具・家具 家電・生活用品 制作会社・開発・企画・マーケティング・コンサル デザイン・ものづくり・撮影 本・出版 求人・マッチング・転職・人材ビジネス ホテル・旅館 旅行・観光・遊び 体験・交流 イベント・お祭り 健康・運動・スポーツ・ジム 美容室・サロン・エステ・ヨガ 美容・化粧品・コスメ・ケア用品 ファッション・アクセサリー・ジュエリー ベビー・子供・キッズ・ママ 福祉・介護・お年
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く