昨年末に戸建てを買って住んでいる。建売だが、自分で注文住宅作るとこれを得られはしないだろうなという良さがあり満足している。 近隣は下町っぽい風情があって、静かで良い。うちを含めて半数ぐらいはわりと新しく建て変わっているが、半数はけっこうな築年数。買ったときに聞いた地域の建築基準に照らすと、まるっきり建て替えるというのも厳しそうだなとか思ってみている。かくいう我が家も、もともと3軒あった土地を不動産業者が買い上げて、2区画にされたものだ。 そんな感じで暮らしていると、同じ町内の家が空き家になって売出し中になっているのに気づいた。物件情報見たわけではないが、外観だけみていると、そのまま住むには古そうだが、その家単独で建て替えもできないんじゃないかという雰囲気。とはいえ地価はあるので、果たして買う人いるんだろうか。もしくはうちと同じように都合よく近隣とまるめて整理されるようなことがあるのだろうか

わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分

はじめに 基盤チームでバックエンドエンジニアをやっている松田（ @tadamatu ）です。 以前にCTO川口が当ブログ内で公開した以下の記事があります。 devblog.thebase.in 新規接続の限界 BASE のアクセス量の伸びは凄まじくこの構成でも接続エラーが発生するようになってしまいました。 ピーク時に秒間 2 万もの新規接続が primary インスタンスへ行われているといった状態です。 この記事が公開されたのが約２年前で、当時100万程度 だったショップ数は170万を超え、我々はまだまだ伸ばしたいと考えています。 これは、ショップ数の伸びとともに、指数関数的に増えていくユーザのアクセスを捌く必要があることを意味します。 ブログ公開当時、我々はさまざまな検討の末、以下のような対策を取りました。 残された手段は primary のインスタンスに対しての接続数を如何にして減らす

2022年5月15日(日)に開催されたSRE NEXT 2022 Day 2の登壇資料です。 ▼SRE NEXT 2022オフィシャルサイト https://sre-next.dev/2022/ ▼発表の概要 https://sre-next.dev/2022/schedule#jp20

分散システムにおける適度な結合とは - Viadik Khononov氏のDDD Europeでの講演より を読んで、ソースコードの結合度を測るコナーセンスという概念を初めて知った。コナーセンスは日本語で検索しても情報がほとんどない。そこでコナーセンスの理解を深めるために英語サイト connascence.io を翻訳した。 翻訳サイトはこちら。元サイトが work in progress なのでコンテンツの分量は少ない。 コナーセンス(翻訳) この記事では上の翻訳サイトと Connascence - Wikipedia をもとにコナーセンスの概要を説明する。 コナーセンスとは コナーセンスはソフトウェアの品質を測る結合度のメトリクスであり、Meilir Page-Jones により提唱された。初めて本格的に解説されたのは 1996 年の著作『What every programmer s

I've created and consumed many API's over the past few years. During that time, I've come across good and bad practices and have experienced nasty situations when consuming and building API's. But there also have been great moments. There are helpful articles online which present many best practices, but many of them lack some practicality in my opinion. Knowing the theory with few examples is goo

本ブログは、こちらに掲載されている英文ブログの意訳です。万が一内容に相違がある場合は、原文が優先されます。また、PDF版をダウンロードいただけます。 はじめに – 共同創業者兼共同最高経営責任者より 2022年4月上旬に発生した障害により、お客様へのサービス提供が中断されたことをお詫び申し上げます。私たちは、当社の製品がお客様のビジネスにとってミッションクリティカルであることを理解しており、その責任を重く受け止めています。今回の全責任は私たちにあり、影響を受けたお客様の信頼を回復するために尽力しています。 アトラシアンのコア バリューの 1 つに「オープンな企業文化、デタラメは無し (Open company, no bullshit)」というものがあります。この価値を実現する取り組みの一環として、インシデントについてオープンに議論し、学びにつなげています。そして、このインデント事後レビュ

検索エンジンのMore-Like-Thisクエリとグラフアルゴリズムによる類似記事集約

こんにちは ! テクニカルトレーナーの杉本圭太です ! 最近読んで面白かった漫画は「海が走るエンドロール」です。 私は業務でお客様に AWS の様々なトレーニングを提供しているのですが、コースによっては AWS を利用したシステムのアーキテクチャ図を受講者自身に描いていただく演習を取り入れており、よくこんな相談を受けます。 「どうやって AWS のアーキテクチャ図を描くのが正解なんですか ?」 AWS のアーキテクチャ図を描く状況は以下のように様々な場面であり、同じような疑問や悩みをお持ちの方も多いのではないでしょうか ? 詳細設計で構成図が必要 チームで wiki などに図を貼り付けて残したい 構成検討フェーズなどで図を見てディスカッションしたい ワークショップを試しながら理解を深めるなど自分のために描きたい そこで今回は AWS アーキテクチャ図をどうやって描けば良いか悩んでいる方へ、

Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ

この記事は Merpay Tech Openness Month 2022 の15日目の記事です。 はじめに こんにちは。Credit Design Teamでバックエンドエンジニアをしている@tanaka0325です。主にメルペイスマート払いの開発をしています。 この記事では、先日私のチームで作成したユニットテストのガイドラインについて紹介します。 課題 現在私が担当している「メルペイスマート払い」のマイクロサービスは、もともと「メルカリ月イチ払い」として提供されていたコードを流用し、新規要件となる機能を追加して作られたマイクロサービスです。 マイクロサービス化するにあたり、「メルカリ月イチ払い」にあったデータはマイクロサービスリリース後に随時マイグレーションをする方針になったので、既存のデータをマイグレーションしつつ、定額払いなどの新規機能を追加してきました。メルペイスマート払いのマイ

情報化時代が到来し、日常で意思決定をする回数と選択肢の数が急増したことで、推薦システムの需要が高まっています。そのため、昨今では多くのウェブサービスへ新たに推薦システムの導入が検討されることも増えました。本書では、推薦システムの概要から、UI/UX、アルゴリズム、実システムへの組み込み、評価まで紹介し、適切な推薦システムの実装ができるようになります。「実際の仕事に活かす」ことを目的に、著者たちが実務で経験した推薦システムの成功事例や失敗事例を交えながら、実サービスに推薦システムを組み込むという観点を重視した入門的な内容です。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作成し、増刷書籍を印刷した月です。お手持ちの書籍では、すでに修正が施されている場合がありますので、書籍最終ページの奥付でお手持ちの書籍の刷版

Rationale The entire premise behind GitOps is to use Git as the source of truth for infrastructure and application configuration, taking advantage of Git workflows, while at the same time, having automation that realizes the configurations described in Git repositories (GitOps operators when we are deploying to Kubernetes). That said, both infrastructure configuration and application configuration

ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog Yahoo! JAPANアプリの通知系バックエンドシステムを主に担当しているエンジニアの福盛です。 Yahoo! JAPANアプリの通知系バックエンドシステムについては、以下の記事でも紹介しています。もし興味があればこちらも参照ください。 チームのスキル向上にもつながるシステム刷新 〜 Yahoo! JAPANアプリ「お知らせ」機能の開発事例 Scalaで使うMessage Queue 〜 Yahoo! JAPANアプリのお知らせ送信でのApache Pulsarの活用 今回は開発とトラブルシュートの効率を大幅に向上する、アプリケーションログの埋め込みと活用方法について紹介いたします。 本記事では「JavaおよびScalaで構築さ

本記事ではSIerに所属する著者が3年間にわたり、私たちのグループで実践している「1on1」の内容を紹介します（グループの業務内容は主にAI系の自社製品開発です）。 ・1on1をこれから始める方 ・1on1の取り組みを検討をされている方 ・1on1を実施しており、さらに改善を検討されている上司側の方 ・1on1を実施してもらっているが、なんだかしっくりきていない部下側の方 こうした方々にとって、何らか参考となれば幸いです。 とくにIT系の企業や職種では1on1を開催しているところも多いと思います。 新人プログラマの方にとっても、1on1を実施する側がどのようなことを考えて実施しているのか、ひとつの例として参考にいただければ幸いです。 （なおQiitaでは現在、新人プログラマ応援 - みんなで新人を育てよう！企画も開催中です） 私が自分の頭を整理するために記事化しましたが、非常に長い文章にな

経緯 IIDX用の専用コントローラの打鍵音は大分うるさく、環境を整えていても集合住宅では昼間しかプレイできない。 音ゲーの「あと一回でやめる」は99%嘘で、実際には成功するか疲れきるまで無限にあと一回が追加され続けるので、計画的にきっちり気持ち良く終わるのは結構難しい。 調子が良くなってきたところで時間を理由に切り上げるのはなかなか歯痒いのと、音ゲーを抜きにしても夜中にあまり音を出せない環境だったので、思い切って防音室を買うことにした。 結果 単にPCと机だけ入れて済ませるなら簡単だったんだけど、やっぱり一箇所でなるべく全部完結させたくなり、これまで使っていた介護ベッドPC環境一式もどうにかして防音室内に維持したくなった。 試行錯誤の末なんとかうまい具合に全部無理なく収まって、飯の用意とトイレと風呂以外は防音室からほぼ出ないで済むようになった。 部屋中の家具が全部可動するおかげでどんな体勢

翻訳を担当した書籍『ソフトウェアアーキテクチャの基礎――エンジニアリングに基づく体系的アプローチ』（オライリー・ジャパン）が3月8日に発売されます。本書は、2020年1月に出版されたMark Richards, Neal Ford著『Fundamentals of Software Architecture』（O'Reilly Media）を全訳したものです。 www.oreilly.co.jp ソフトウェアアーキテクチャとは、ソフトウェアシステムの成功に欠かせない重要な土台です。そのためソフトウェア開発者には、効果的なアーキテクチャを実現するスキルが求められます。本書は、そうした効果的なアーキテクチャを設計、構築、維持するアーキテクトになるために必要なスキルや知識を、現代的な視点から整理して包括的に解説する書籍です。 ソフトウェアアーキテクチャの定義から、アーキテクトの役割、モジュールや

※本ブログは2022/2に執筆されています。そのため、アップデートによって内容が現在と異なる可能性があります。 はじめに モバイル事業本部プロダクトエンジニアリングセクション マネージャーの安田です。 インフラっぽいことやクラウドっぽいことやデータエンジニアっぽいことをやってます。 今回、モバイル事業部で使うS3のコスト削減のため、ストレージクラスの移行等を行うライフサイクルの設定を行いましたのでご紹介します。 これからS3の管理を行っていく方、コスト削減に興味のある方の参考になれば幸いです。 実施の背景 モバイル事業本部ではドワンゴジェイピーやアニメロミックスなど音楽配信ビジネスを中心に展開しており、様々なレーベルからお預かりした楽曲データを管理しています。 また、ニコニコ事業本部ができる前からサービスを行っており、多大な量のシステムログやクラウドサービスのログデータなどが存在しています

voicodという音声入力でメモを書けるシンプルなウェブアプリケーションを書きました。 音声入力でメモができるシンプルなアプリケーションを書きました。https://t.co/EHSKnNKNaL x-callbackを使ってショートカット.app 等と連携すれば、入力内容をNotionに保存したりできます。 Note: SpeechRecognitionに対応したブラウザ(ChromeやSafari)が必要 Source: https://t.co/NnzXVjlGnF pic.twitter.com/yzoA3VIzzl — azu (@azu_re) February 10, 2022 SpeechRecognitionというウェブブラウザで音声認識をするAPIを使っているので、このAPIに対応しているブラウザが必要になります。 具体的にはGoogle ChromeやSafariなど