読書感想文「ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた」 はじめに こんにちは、レバテックCTO室でテックリードを担当しているかわうそです。 今回は、夏といえば夏休みの宿題、夏休みの宿題といえば読書感想文ということで読書感想文を書いてみました。 読書感想文の対象読書として選んだのは、”ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた”になります。 特に選んだ理由とかはないんですが、 読書感想文を書いてみようと思ったタイミングと読もうと思ったタイミングがたまたま重なったのが理由です笑 感想 読んでみて最初に思ったことは「うわーそれあるあるだわぁ」がたくさんあったことですw ソフトウェア開発をしていると幾度も失敗をしてしまうことはあると思いますが、こういった失敗を他のエンジニアたちもしているんだなと思うと

はじめに はじめまして！レバテック開発部でレバテックプラットフォーム開発チームに所属している塚原です。 直近に認証・認可周りの改修を予定しているため、チーム内で認証・認可の基礎からOAuth・OpenID Connectの仕組みを学ぶ勉強会を実施しました。今回はそこで学んだことのうち、認証・認可の基礎とOAuthの仕組みをまとめます。また、WebフレームワークとしてHono、JavaScriptランタイムとしてBunを使って、OAuthクライアントを実装してみます。 対象読者 認証と認可の違いってなんだっけ...?という人 Basic認証やDigest認証てなんだっけ...?という人 OAuthはライブラリ使って実装してるから仕組みよくわかっていない...という人 OAuthのクライアントの実装って何をすればいいんだっけ...?という人 認証・認可の基礎 2024/7/18 追記 こちらで

初めに レバテック開発部の今井です。 ソフトウェア開発において、データの状態管理は非常に重要です。注文の状態、ユーザーの認証状態、プロジェクトの進行状態など、多岐にわたる状況で、適切な状態管理が求められます。しかし、ビジネス要件の変化や新機能の追加に伴い、状態管理が複雑化し、保守が難しくなることがあります。 この記事では、データの状態管理を簡単にするためにMECEを初めとした方法で分析を提案します。これによって、柔軟で効率的なシステム設計が可能になることを目指します。 TL;DR MECEの原則を使ってenum型ステータスを分解する方法を解説する MECEによる分解から一次情報と二次情報という区分を提案し、分析の高度化を目指す 一次情報と二次情報の区分とシステム間のデータ連係の関係性について考察する 対象読者 システムの保守性・拡張性に興味関心のあるエンジニア enumをMECEに分解する

はじめに 業務委託の丹羽です。 レバテックフリーランス経由で、レバテック開発部のSREチームに業務委託で参画させていただいています。 業務委託の私でも、我が物顔でレバテック開発部のテックブログに寄稿して構わないとのことなので、今回は掲題の件について、振り返りながら記事にさせていただきます。 ざっくりこんな人 AWSの基盤となるクラウド部分と、EC2内部でOS・ミドルウェアをメインに、各パラメータを修正したり、それらをAnsibleに書き起こしてCodeCommitで管理しているくらいのIaC経験があるインフラの人でした。 そこからスキルアップと挑戦をしたいという思いで、フリーランスに転向してSREやDevOpsに興味を持ち始めた人です。 SLI/SLO...？ CICD...？ 何それ、美味しそう！ 話したいこと フリーランスってどんな仕事してるの？ レバテックフリーランスに興味のある方は

はじめに レバテック開発部、SREチームに所属している金澤です。 弊社開発部では、Datadogで行っていた監視からNewrelicを用いたオブザーバビリティへの移行を行う決定をしました。 そして、なぜオブザーバビリティを採用したのか、DatadogからNewrelicへ移行したのかといった意思決定をADRとして記録し、社内に展開しています。 今回はこのADRの内容を公開します！ ※本記事はNewrelic、Datadogを肯定、否定するものではございません。 ADR コンテキスト 事業軸 レバテックの事業戦略は事業ポートフォリオ構想に従っている 既存の事業を拡大させながら新規サービスを生み出し続ける 事業ポートフォリオ構想 開発軸 事業領域の大きさ、深さが拡大し必要なドメイン知識が肥大化 スケーラビリティとアジリティの担保が困難になってきた バグ、障害の発生 レビュー工数の増加 新規参画

レバテック開発部の前原です。以前はプラットフォームチームとしてマイクロサービスの開発を行っていましたが、開発部の新たな試みにより、事業の特定の問題を解消するチームとして社内の営業支援システムの改修を行っています。 はじめに レバテックの社内の営業支援システムでは、数多くのステークホルダーからの要望をもとに開発が行われます。ステークホルダーからは「このテーブルにカラムを追加してください」といった具体的な要望が多く寄せられます。開発部ではこれらの要望に対して検討を重ね、要件の調整を行いますが、多くの場合、そのままカラムを追加することが多いです。 カラムの追加によって要望が実現されるかは考慮されますが、データモデリングを通して「モデルにどのような概念を含めるか」の検討は不十分でした。 その結果、本来必要な概念がデータモデルに反映されず、運用で問題をカバーすることになりました。これにより問題の解決

はじめに こんにちにんにん、 art です。 僕が所属するレバテック開発部では、最近デザインシステム『VoLT』が誕生しました。 レバテックでは複数のプロジェクトが運用されており、フロントエンドの技術スタックは Vue.js × Nuxt React x Next.js の２つが採用されています。 ですので、両方の技術スタックに対応したデザインシステムを作る必要があるわけですね。 あら大変。_(:3 」∠ )_ というわけでこの記事では、『VoLT』のUIコンポーネントライブラリを制作するにあたり、肝となったデザインシステムのマルチフレームワーク対応についてお話しします。 🔗そもそも『VoLT』とはなんぞや？構築の背景は？と気になった方は、こちらをご覧ください！ 想定読者 デザインシステムに興味のある方 これからデザインシステム関連の業務に携わる方 すでにデザインシステム関連の業務に携わ

はじめに はじめまして。レバテック開発部ITSプロダクト開発グループ所属の池永です。 私は現在スクラムマスターとしてチームに参画しており、日々チームが強く、楽しくなれるように試行錯誤しております。 かれこれ一年半ほどスクラムマスターを経験させていただいてきましたが、色んな壁にぶつかってきました。 特にスクラムにおける「ふりかえり（レトロスペクティブ）」において生じた壁について色んなエンジニアと話しているうちに、あるあるなんだなぁ〜と感じたため、この記事を書いております。 この記事では自身のぶつかってきた壁と、そこに対してどのようなアプローチを取ったか、そしてどうなったかを少しだけ共有しようと思います。 何かしらの参考になったら幸いです。 話すこと スクラムにおけるふりかえりのあるある あるあるに対して自分がやったこと そのアプローチをとってどうなったか 話さないこと 色んなふりかえり手法に

これはなに ども、レバテック開発部のもりたです。 今回はSQLのサブクエリについてまとめます。仕事でクエリを書く際、サブクエリは頻出の構文だと思うんですが、同時にサブクエリの書き方を完全に理解しているよという人は案外少ないのではないでしょうか？[1] 実際、MySQLの公式ドキュメントを見ると12ページくらいを割かれており、意外と奥深いのがサブクエリです。使いこなせると便利ですし、何よりちょっとSQLのコツみたいなのがわかって面白いよ、ということで記事にしてみました。 前提 この記事は以下の前提を含んでいます。 環境 MySQL8.0系 読者の知識 なんとなくサブクエリが書ける けど相関サブクエリとかになると「あーっ」つってGoogle meetを閉じてしまうくらいのレベル感 記事のボリューム 18,000文字 おれの卒論が20,000文字だった マサカリ 間違ってたら投げてくれ〜〜 それ

このように、REST の設計原則に従って API を構築することで、ほとんどの API 設計は直感的に、かつ問題なく行うことができます。 デザインパターンの紹介 ここからが本題です。大抵の場合、上の例で示したような API 設計で十分です。 ただ、複雑な要件では、上のような典型的な API 設計のみでは良いAPIを設計するための4つの特性を満たせないことがあり、そのような場合のためにデザインパターンが有効です。 カスタムメソッド 概要 カスタムメソッドは、標準的な CRUD 操作（作成、読み取り、更新、削除）では対応できない特定の操作が必要になる場合に便利です。例えば、メールの送信や即時の文書翻訳など、通常の create や update メソッドでは処理が難しい操作がこれに該当します。 参考までに、以下に Google が出しているカスタムメソッドの記事を示します。 実装例 以下は、カ

伝えたいこと 論理的思考だけでは立ち行かない厄介な問題への武器として、システム思考という選択肢も持っておくと分析の幅が広がるかも 要約 レガシーシステム、どうする？というありふれた厄介な問題 どうすべきかの仮説はあるけど分析が甘そう システム思考で解像度UP、新たな仮説を立てられた 社内のレガシーなシステムを今後どうしていくか？ システムの詳細は省きますが、10年くらい前からシステムを持っている多くの企業が、この問題を抱えていると思います。 この問題をどうにかするためにマイクロサービスが流行し、成功したり失敗したり、、今も闘っている企業は多いでしょう。 弊社はマイクロサービス化に失敗した側で、今も闘い続けているのです。 どうアプローチすれば良いかわからない レガシーシステムは総じて歴史が深く、事業を支えてきた重要なシステムです。 故に規模は大きくなり、関係者も多くなり、変更容易性は下がって

TL;DR TypeORMで発生していたスロークエリを改善 スロークエリを改善したらECSの負荷も減少 はじめに スロークエリを改善したら、ECSコンテナ側の負荷も下がってなんでだろ？と思ったので記事にしようと思います。 環境 TypeORM v0.3.20 Node.js v18.x バックエンドインフラ ECS on Fargate => Amazon Aurora MySQL 負荷改善の前と後 まずはどのくらい改善したのかを示します。 この時ECSコンテナ8台動いてました。(4vCPU 8GBMem) 改善前 改善後 改善前と改善後は一日前の同じ時間帯のものです。 ちゃんと動いてるのか不安になるくらい下がってました笑 どのような対応をしたのか スロークエリの出ていたクエリでMySQLの実行計画を確認しました。 TypeALL,index, Using Filesort等はなかったので

はじめに Git Graphという拡張機能を使います。 Git GraphとGitLensという拡張機能を使います。[1] また、gitから開かれるエディタをvscodeにしておきます。 コミットのまとめかた（1分未満でできるよ） ステータスバーのGit Graphのボタンをクリックして、Git Graphの画面を開きます。 まとめたいコミットの一つ前のコミット（今回だとinit）を右クリックして、「Rebase current branch on this Commit...」を選択します。 「Launch Interactive Rebase in new Terminal」にチェックを入れて「Yes, rebase」をクリックします。 こんな画面が開きます。 まとめたいコミットを上から順にpickからsquashに変更します。最後の一つはpickのままにしておきます。そして「STAR

TL;DR TiDBにおけるパフォーマンス検証をどうやって行ったか パフォーマンス検証を行ったときにつまづいた問題とその対応策 TiDBの仕様やアーキテクチャなどの話はありません 前提 対象のDBはAmazon Auroraで稼働中 DBエンジンはMySQL TiDBに移行できないかPoCを実施 DB周りにいろんな課題があり、TiDBで解決できないか検証 TiDB Cloudで検証 本番運用を想定してTiDB Dedicatedを利用 先にお伝えしたいこと TiDB導入したいとか言う前に、今使っているRDBで発生しているスロークエリとかIndex設計を見直した方が良いです笑 理由はこの記事を見てもらえるとわかると思いますｗ パフォーマンス検証の進め方 1. パフォーマンス検証に利用するクエリを洗い出す 観点としては以下の2つ 実行される頻度が高いSQL 実行速度が遅いSQL（スロークエリ）

TL;DR セキュリティー対策には予防的統制と発見的統制の 2 つの観点が欠かせない AWS が提供するセキュリティーサービスが予防的・発見的統制にどう寄与するかを解説 セキュリティー対策は、リスクの特定と可視化、リスク分析と優先度付け、施策費用の算出、経営層への報告とサポートの獲得で進めるべし セキュリティーは、単に技術やツールを導入するだけではなく、組織全体の意識や文化、そして継続的な改善が求められる はじめに レバテック開発部レバテックプラットフォーム開発チームに所属している内藤です。 普段は、バックエンドの設計や実装、さらにインフラの構築まで幅広く担当しています。 最近、私は弊社開発部を代表して（色々な方面から怒られそう笑）、AWS セキュリティインシデント擬似体験 GameDay に参加する機会に恵まれました。このイベントでは、セキュリティインシデントへの対応方法や予防策など、実

これはなに ども、レバテック開発部のもりたです。最近めっちゃ元気！！ 今回は『データベースについて勉強したいあなたに送る技術書17冊(+11冊1講義7link)』として、もりたがここ半年くらいでわーっと集めたデータベース周りの書籍（とか）を紹介していきます。アプリケーションって結局はデータベースみたいなところがあると思うんですが、おれは長いことデータベースをどう学んだら良いのか分かりませんでした。同じような気持ちを抱えているITエンジニアの人もいると思うので、学習ロードマップと合わせて紹介していきます。 なお具体的な対象読者は業務でなんとなくSQL書いてるけど、ウィンドウ関数とか言われると分からんな……くらいの人です。 扱う領域と扱わない領域 扱う領域としてはだいたい以下 再入門本 SQL 内部構造 論理設計 周辺知識 データベース理論 その他高度なもの モデリング、NoSQL、分散データ