エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト

こんにちは、Development Teamの三宅です。 先日、社内（AI事業本部内）でSQL研修の講師を担当したので、今回はその内容について簡単に共有したいと思います。 はじめに 例年、AI事業本部では、新卒エンジニアの育成のためにソフトウェアエンジニア研修を行っております。今年はフルリモートでの実施となりました。研修期間は2週間ほどで、内容は前半が講義、後半が実践（チーム開発）でした。私が担当したのは、講義パートの一部であるSQL研修です。SQLやRDBにあまり慣れていない人でも、できるだけ体系的な学びが得られるようにすることを目標に、様々な資料をまとめて提供する方針で準備しました。結果的には、ハンズオン込みで4時間ほどのやや長い講義となりましたが、勉強になったという声も頂けたのでやって良かったと思っています。 研修資料 研修内容 SQL研修の内容は、基本的には大学のデータベース講義で

Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey（プログラミング言語Clojure作者）のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。 ソフトウェア危機 ソフトウェアは本質的に複雑 ソフトウェアの複雑さはどこから来るのか？ 複雑さは、別の複雑さを産む 複雑さを分類する 本当に必要な複雑さと、そうでないものがある どうやって複雑さを扱うのか

これらのサービスは Lambda と統合するように設計されており、Infrastructure as code (IAC) を使用してサービス内のリソースを作成、および破棄できます。アプリケーションをインストールしたりサーバーを設定したりすることなく、AWS SDK 経由でこれらのサービスを利用できます。Lambda 関数のコードを使用して、これらのサービスを使用することに習熟することは、適切に設計されたサーバーレスアプリケーションを作成する上で重要なステップです。 抽象化のレベルを理解する Lambda サービスは、Lambda 関数を実行する基盤となるオペレーティングシステム、ハイパーバイザー、ハードウェアへのアクセスを制限します。このサービスはインフラストラクチャを継続的に改善し変更することで、機能の追加、コストの削減、サービスのパフォーマンスの向上を実現します。あなたのコードはLa

こんにちは丸山@h13i32maruです。システム全体を簡単な図とテキストでまとめる「ARCHITECTURE.md」というものを最近知りました。これは良さそうと思い、JasperのARCHITECTURE.mdを書いてみました。 jasperapp/jasper/ARCHITECTURE.md ARCHITECTURE.md自体の目的は「プロジェクトへの新規参加者が全体像の把握を効率的に行えるようにする」という感じです。書き方の指針や注意点などは考案者による記事を見てもらうのがよさそうです。また良いサンプルとしてrust-analyzerというOSSのARCHITECTURE.mdが紹介されています。 https://matklad.github.io//2021/02/06/ARCHITECTURE.md.html https://github.com/rust-analyzer/ru

この記事はハワイアンAdvent Calendar 2020 2日目の記事です。ツイートアナリティクスによれば、1日目のブログへのエンゲージメントは32という事だそうです。今確認のためにもう一回開いたので33です。わたしは自分のブログを何回も読み直すので、99%は自分のアクセスでしょう。これまでご愛読頂きありがとうございました。 Advent Calendarの前半では進化的アーキテクチャについて触れてやっていくつもりなので、その為の前提を埋めていきたいと思います。 2020年現在、サービス開発や製品開発の為のソースコードの自動生成が進んでいますが、残念ながら製品開発の根幹となるロジックは人間が書いています。人間がソースコードを書くこの時代において、ソフトウェア設計とはなんの為にあるのでしょうか。リファクタリングはなぜ行うのでしょうか。綺麗なコードを書くのはなんの為でしょうか。綺麗なコード

技術広報のsyoneshinです。 今回は当社の開発組織メンバー達に 読んでよかった 自身が影響を受けた 他者にも読んでほしいと思った という観点で 『おすすめの技術書』とおすすめポイントを聞きました。 質問：皆さんの「おススメの技術書」 を教えてください。 【目次】 おすすめの技術書ランキング 『リーダブルコード―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)』 『マスタリングTCP/IP 入門編』 『体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践』 『達人プログラマー 職人から名匠への道』 『Webを支える技術』 『SQLアンチパターン』 『Java言語で学ぶデザインパターン入門』 『はじめて学ぶ　ソフトウェアのテスト技法』 『UNIXという考え方―その設計思想と哲学』 『Effective Jav

このブログが話題になってますね。制約を付けること自体はよいことだけど、無目的に適用すると害も生じると思います。 無目的という言い方はおかしいな…。外部キー制約をどのように使えばいいのか、逆にどんなときに使うとまずいのかを考えてみたいと思います。 tech.tabechoku.com 例えば、これ。外部キー制約はできるだけ付けるとか、何も考えずに付けるとよくないと思います。 外部キー制約は、可能な限りつけるようにしています。 DBが別れている場合、外部キーはもちろん貼れないのですが、そうでない場合はとにかく何も考えず貼っています。データベース設計の際に気をつけていること - 食べチョク開発者ブログ テーブル設計をシミュレーションする いいたいことの結論はこれ。以上終了なのですが、もう少しわかりやすく書いてみよう。 何も考えずに外部キーを貼るのは良くないな。トランザクション境界の外で結果整合性

こんにちは。技術部 開発基盤グループの諸橋です。 クックパッドでは昨今の多くのWeb企業と同じように、GitHub EnterpriseのPull Requestを使ったコードレビューを広範に実施しています。わたしたちのコードレビューでは、ソースコードの字面にとどまらず、サービスの機能として魅力的かどうかや、保守性を含めた設計が適切かといった議論に発展することも良くあります。 きょうはそんななかで話題に上がった「現在時刻」の扱いかたに関する設計の話を書きます。 背景 サービスを開発・運営している我々には、時間帯によって出し分けたり、特定の期間のみに表示したいコンテンツがたくさんあります。 そのたびにデプロイし直すというのはつらいので(特に24:00に出なくなるコンテンツなど)なんとかしたくなりますが、一方で時限式のコンテンツはその時になるまでちゃんと動いているか確証が取れないので怖いです。

2020-03-13追記: 「ドメイン駆動設計」のハードルを上げる意図はありません。そもそもそんな特殊技能でもないと思っています。「ドメイン駆動設計が合っているか」を測る材料になるかも？くらいの気持ちで読んでいただけると幸いです。 何度目か知りませんがDDDがまたブームを迎えているようで。DDD難民と言う言葉が出た頃を思うと感慨深いですね。実際難民になったわけではないので肌感覚で知らないのが残念なところですが、これはどうでもいい。 DDD、日本語ではドメイン駆動設計となりますが、DDDを冠していてもドメインが語られることは少ないようです。 数ある書籍もドメインモデリングの話ではなく、ドメインモデルをいかに実装に落とし込むかにフォーカスしていると感じています。 これはこれで仕方ないと言うか、ドメインの話って広く語れないんですよね。 ドメインは領域で境界があって範囲が限定されています。特定ドメ

日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能

Amazon Web Services ブログ 新年の抱負 : Amazon DynamoDB のベストプラクティスを守る Amazon DynamoDB のベストプラクティスを守ることを新年の抱負としてみてはいかがでしょうか。これらのベストプラクティスに従うことで、DynamoDB を使用する際のパフォーマンスを最大限に発揮し、最小限に抑えることができます。以下のリンクをクリックして、DynamoDB ドキュメントで各ベストプラクティスの詳細をご覧ください。 パーティションキーを効率的に設計して使用する DynamoDB テーブルにある各アイテムを固有に識別するプライマリーキーは、シンプルなキー (パーティションキーのみ) または複合キー (ソートキーと組み合わされたパーティションキー) にすることができます。アプリケーションは、テーブルとそのセカンダリインデックスの論理パーティションキ

はじめに 私自身は今年の 7 月にドメイン駆動設計（DDD）を実践する企業に転職したばかりで DDD 実践歴は浅いのだが、最近は開発業務の他にも中途採用者の DDD 教育や 現場で DDD！2nd のドライバー役をする機会を頂くなど、DDD の布教活動にも少し関わっている。 その中で「DDD ムズイ」という言葉をよく聞いたので、DDD の実践に悩んでいる人向けにサンプル問題の解説を通して、実は DDD 自体は難しくないんだよってことを教える目的で本記事を書いた。 TL;DR（最初に結論） DDD 自体はドメインを中心にモデリングと実装をイテレーティブに繰り返す設計プロセスであり、モデリングと OOP の理解があれば誰でもできる。 難しいのは DDD 自体ではなくて、モデリングまたは OOP である。特に「良いモデル」を得ることは非常に難しい。 なので「DDD ムズイ」と感じる人はモデリング

この記事はPLAID Advent Calendar 9日目の記事ですUI改善の前提理解、うまくできていますか？皆さんはこれまで着手してこなかった既存画面のデザイン改善をする時、どのように進めているでしょうか。 自分がプレイドで所属しているreBAISUというチームでは、タタキとして定義したスタイルガイドを旧来の画面に適用しながらUI改善する取り組みをしています。 取り組み方として、改善対象となる画面の仕様を理解しながら課題を見つけ、解決策を検討していく流れになるのですが、この仕様理解が難しいと感じていまして。 なんとか前提理解を促せる方法はないものかと検討した結果、対象画面の構成要素をひとつずつ紐解いていく方法で理解していく「デザインの逆行分析」という方法をとっていました。 デザインの逆行分析とは「リバースエンジニアリング」とも呼ばれる手法で、その考えをデザインでも応用しようというもので

モバイルアプリケーションを開発していると、この要件や仕様はクライアントとサーバーどちらに置くべきか、という議論がチームでなされることがしばしばあります。例えば、 あるレスポンスAを受けて処理Bを行い、その結果をユーザーに提示する 登録処理などで、処理C,処理Dという異なる処理を並列して行い、それらが完了したらユーザー側に通知する やろうと思えばクライアント側で処理を全て持つこともできますし、サーバー側で実装もできますね。 このような仕様のディスカッションが起きたとき、チームで統一した判断基準を持っていますか? 自分の場合、クライアントアプリはロジックをなるべくサーバーに移譲すべき という設計指針をチームに提案します。 上の例で言うならば、 サーバーから処理Bも踏まえたレスポンスA'を返してもらい、ユーザーに提示する クライアントは1リクエストをサーバーに投げる。サーバー側で処理C,Dを投げ

ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 初めまして。Yahoo! JAPANでAthenzというOSSセキュリティプラットフォームの運用・開発を行っている松本拓也です。 唐突ですが、私は色覚異常です。今回は私が見ている色について、どんなふうに見えているのか、少しでも理解していただけたらと思います。そして、それを踏まえてYahoo! JAPANのアクセシビリティーの取り組みを簡単に紹介します。 色覚異常ってどういうもの？ 色覚異常という症状についてどれほどご存じでしょうか？　色覚異常は色を見る能力に何かしら異常があることを示し、色が見えなかったり、わからないという症状があります。（今回は色覚異常に伴う視力異常については触れません）色覚異常は男性の5％程度に見られ（このあと

一寸先は闇。人生何が起こるかわかりません。 自分のスケジュール帳に CM 撮影が入る日がくるなんて誰が予想できるのでしょうか。 CM あとがき というわけで CM に出演しました。 まさか勘違いされる方はいらっしゃらないと思いますが念のため言っておきますと、この CM は自分の所属会社であるGMOインターネット株式会社の CM です。 見ればわかりますよね。間違いようがありませんよね。 撮影風景はこんな感じです。 なんだこの絵面。 撮影中はずっと「レフ版まじでまぶしい、熱い」って思ってました。 ついで自分が台本苦手ということに気づかされたり。 （CM のセリフは大筋決めつつすべてアドリブ。） なおこちらの CM は冒頭画像（スケジュール）を見ると分かるのですが SekkeiKaigi （https://nrslib.com/sekkeikaigi/）の当日朝に撮影しております。 なんという

業務で扱う(最小)単位でデータとロジックをひとまとめにして整理する技法 ドメインモデルが実現する世界 どこに何のロジックが書いてあるか、(ソースを見るだけで)わかる 改修しやすいプログラム ドメインモデルで解決したい問題 どこに何のロジックが書いてあるかわからない問題 - わからないから適当に書く→適当に書くからわからない → わからないから・・・ - ある修正をしようと思っても、どこまでが影響範囲かわからない - 使用している箇所全grepして調査 - 同じような処理、分岐が重複してしまう これを解決したい。これだけを考える。 なぜ(今までのシステムは)改修は難しいのか 機能クラスと、データクラスをわけてしまうから そのデータクラスを呼べる箇所 = 業務ロジックがかけてしまう どこになにが書いてあるかわからなくなる 共通クラス、Utilクラスを作ってしまうから 誰でも呼べる = そのクラ

すげーリポジトリ見つけた。Webサービスのシステム設計が学べる。日本語もある。システム設計ってどうやって学ぶのが効率いいんだろうって思ってたけど、コイツを出発点にするのはアリな気がする。 https://t.co/1YMBP9UMHo

この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出