SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。 このスライドでまとめているのは SaaS とは、ビジネスモデル x 技術であることを理解する SaaS アーキテクトでどのように SaaS を作っていくのか？を考える SaaS KPI で…
SaaS アーキテクチャ概要
SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。 このスライドでまとめているのは SaaS とは、ビジネスモデル x 技術であることを理解する SaaS アーキテクトでどのように SaaS を作っていくのか？を考える SaaS KPI で…
QAイベントに参加して - Qiita
背景 先日、デブサミの後に参加してきたQAイベントでの議論と、 その次の日の業後にあるマイクロサービスメインで扱われている企業のQA部長の方 とディスカッションしてきて感じた内容や発見をここに残す。 前提 ビジネスアーキテクトとして品質管理も担っている自分としては、 ビジネスサイドから品質を考えないなんて言語道断！というマインドがある。 エンタープライズアーキテクチャモデルの4階層を見てもらうのが一番早い。 私たちは、日々手作業のアナログな業務活動に加えて、 情報システムなどを使った業務プロセスと込みで、 全体としてサービス全体を成り立たせて、それをエンドユーザーなどに提供している。 BtoCだろうが、BtoBだろうが、この本質部分は一緒である。 そのビジネスの中で、「ここの連携早くしたい」とか 「この情報は、企業の存続のために死守したい」などという EAの最上位層であるビジネスアーキテク
技術的負債イベントに参加して - Qiita
前置き 業後に技術的負債のイベントに参加してきました。 内容がそれぞれバラバラであるかに見えて、自分の中ではすべてが有機的に繋がって感じました。 ただ、懇親会に参加できなかったのは残念です💦 開発サイドの方や、テスト設計されている方、組織構造と絡めて話されている方 などそれぞれが違った観点で技術的負債についてアウトプットされていました。 技術的負債の定義 「コードを書くというのは、借金をするようなもの。 少しの借金は速やかに返済(リファクタリング活動により)される限り開発を加速させるが、 危険なのは借金が返済されない状態が続くこと。」 という文が紹介されました。 つくっているプロダクトで得られる売り上げよりも、 変更などにかかるコストが上回っている状態なわけだから、 お金という定義が明確な数値として、負債曲線グラフ的なもので定期的にチェックできる体制が望ましいですね。 で、事前に負債解消
女友達 - 椎彩人 | 少年ジャンプ＋
JASRAC許諾第9009285055Y45038号 JASRAC許諾第9009285050Y45038号 JASRAC許諾第9009285049Y43128号 許諾番号 ID000002929 ABJマークは、この電子書店・電子書籍配信サービスが、著作権者からコンテンツ使用許諾を得た正規版配信サービスであることを示す登録商標(登録番号 第6091713号)です。
What it was like working for GitLab
February 8, 2024 I joined GitLab in October 2015, and left in December 2021 after working there for a little more than six years. While I previously wrote about leaving GitLab to work on Inko, I never discussed what it was like working for GitLab between 2015 and 2021. There are two reasons for this: I was suffering from burnout, and didn't have the energy to revisit the last six years of my life
運用設計における設計項目の体系化 / 20240207-ssmjp-operation-design-items
ssmjp ssmonline #38 "第四回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/307397/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
最近のGoの後方互換性について（2024年も積極的にバージョンアップしよう） - Money Forward Developers Blog
こんにちは！マネーフォワードエックスカンパニー 個人サービス開発部 バンキングアプリ開発グループの仲川です。 みなさん2024年は気持ち良くスタートを切れたでしょうか？私は年始の初売りセールでスマートロックを購入して自宅に取り付けたんですが、施錠が機能していないことに全く気づかず、1週間ほどノーガード状態で「鍵のある生活から解放された！」と浮かれて過ごしていました。 さてソフトウエアエンジニアにとって鍵より煩わしいのは、後方互換性のないソフトウエアのバージョンアップ作業だと思います。今回のテーマはそんな後方互換性についてです。 Goでは2023年にリリースされたv1.21で後方互換性を向上させるための機能が含まれ、公式ブログで後方互換性に関して改めて言及されました。また2024年2月にリリース予定のv1.22では標準ライブラリで初めてv2パッケージが導入される予定であるなど、後方互換性に関
t_wadaさんと「単体テストの使い方/考え方」の疑問点についてディスカッションしました - DeNA Testing Blog
こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
チームの機能と配備を考えるための7つのチーム責務定義ガイドライン - mtx2s’s blog
前回の記事ではチーム中心の組織づくりの設計原則について書いた。今回は、それらの原則に基づくチームをソフトウェアプロダクト組織内にどう配備し、どのような機能を持たせるかについて考える。これは言わば、チームの責務を定義することに他ならない。本記事ではこれを、7つのガイドラインとして書き出してみることにした。 前回の記事：『チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog』 mtx2s.hatenablog.com 1. ストリームアラインド 2. オーナーシップ制 3. バリエーション分割 4. 技術横断型 5. DevOps 6. 機能横断型 7. マルチスキル 組織設計とはアーキテクティングである 1. ストリームアラインド ソフトウェアプロダクト組織の開発フローは、ユーザーや市場の観察をもとにアイデアを生み出すことから始まる。そのアイデアを仮説として、それを
実録レガシーコード改善 / Working with Legacy Code: the True Record
2024/01/15(月) 12:00 〜 13:00 t-wadaさんが後世に残したい、実録レガシーコード改善 https://findy.connpass.com/event/304101/ テストコードが無いコードを引き継いだところからはじまる、実際に2018年に行った受託開発案件のエ…
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
Dropboxが新開発した「非同期処理フレームワーク」はどのように構築されているのか？
複数のプログラムを順番に処理していく同期処理システムでは、どこかひとつの処理に時間がかかると後続の処理がまるごと遅れてしまいます。そんな同期処理に対し、ある処理の完了を待たずに次の処理を実行できるのが非同期処理。重たい処理によるボトルネックを回避できるため、ウェブサイトの応答速度改善などに役立てられています。クラウドストレージサービスのDropboxで開発が進められていた大規模な非同期処理フレームワークについて、同社のエンジニアであるArun Sai Krishnan氏が解説を行っています。 How we designed Dropbox’s ATF - an async task framework - Dropbox https://dropbox.tech/infrastructure/asynchronous-task-scheduling-at-dropbox これまでDropb
Getting Started Performance Troubleshoot
仮想スレッド/ネイティブイメージ/CRaC/ノンブロッキングにも対応！ msで起動しオンプレからサーバレスまで幅広く利用できる 軽量OSSフレームワークQuarkus
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Java Persistenceを使ったアーキテクチュア：パターンと戦略
アプリケーションエンジニアこそ「監視」だよね！と私が考える訳 #phpkansai
ロストメロウ 1話 - ジャンプルーキー！
DX DevEx 360 | Technology Radar | Thoughtworks
Feature FlagsのDX/UXの 頂点「 DevCycle 」に 辿り着くまでの道のり
Beyond API Compatibility: Understanding the Full Impact of Breaking Changes
状態設計から「なんとなく」を無くそう
