はてなブックマーク

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

はじめに はじめまして！ レバテックでプロダクトデザイナーをしている成田です。 現在は日々のプロダクトデザインの業務に加え、デザインシステム『VoLT』の構築と運用に取り組んでいます。 なんとか社外公開まで漕ぎ着けた『VoLT』ですが、プロジェクトが開始してすぐの頃は「無理だ」と弱音を吐きたくなるほど課題が散見されていました。実際、私は何度も「え〜無理なんだが」と声に出しながら作業を進めていました（笑） 本記事では、Figmaでのコンポーネント管理の話を中心に、抱えていた課題を解決するために生み出した 「インスタンスガイドライン」 というものについてお話しできればと思います。 ちなみに、デザインシステム構築の背景や目的が書かれた記事も公開されているので、気になる方はぜひチェックしてみてください👏 何が難しい？レバテックのデザインシステム デザインシステムは、定義すること自体は難しくありま

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

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

はじめに どうも、認定スクラムマスターの瀬尾です。 弊社ではエンジニアの支援制度として認定スクラムマスター取得の補助があります。これを利用して Certified ScrumMaster （CSM） を取得したので、その研修で学んだスクラムの基礎をまとめ、更にふ〜んとなったことや疑問に思ったことについて書いていけたらと思います！ 私が受講したのは、Joe Justice 先生の認定スクラムマスター講座です。2日間の研修があったのち、Webテストを受けて合格しました。ちなみに合格すると合格証と下のバッジがもらえます。Linkedin にも資格を登録してもらえました。 受講の背景を簡単にまとめてみる 受講前の知識量は「開発部に参画してから1年くらいスクラムの開発メンバーとして働いた」程度のものだった 3ヶ月くらい、見様見真似でスクラムマスターのような動きをしてはいた スクラムがアジャイルの具体

お疲れ様です。 レバテック開発部でDevRelを担当しているヤマモトヒロキです。 「月1本テックブログ執筆」を志しておりましたが、 GWの波に飲まれて4月執筆を逃してしまいました。人は怠惰な生き物です。 過去の記事はこちら。 やってみた 3行サマリ 仮説「開発生産性向上のキーファクターは、開発組織外にある」 「非エンジニア向けの開発生産性研修」をやってみた 研修設計の肝は①抽象概念インプット→②自社具体例→③理想行動の具体化 背景 現在私はDevRelやっておりますが、出自はマーケターで事業企画にキャリアの軸足を置いている、 ゴリゴリの非エンジニアです。 事業の責任者として事業を率いる立場と、 DevRelとしてイケてる開発組織を作り発信する立場の両方を経験したうえで、 「事業の継続的な成長と、開発生産性の維持向上の両立ほんと難しい～」 というあるあるな悩みと日々戦い続けている一人です。

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

TL;DR 改善のサイクルを設ける ふりかえりはふりかえりなのでふりかえる Actionはとりあえずやってみる。代わりに効果検証を忘れずに。 はじめに レバテックの多くのチームではスクラムに取り組んでいます。 今回は、自チームのレトロスペクティブのやり方とその設計背景についてまとめようと思います。 レトロスペクティブについて まず、レトロスペクティブについてスクラムガイドでは以下のように書かれています。 スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。 スプリントレトロスペクティブには、以下の目的がある。 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。 うまくいった項目や今後の改善が必要な項目を特定・整理する。 スクラムチームの作業の改善実施計画を作成する。 スクラムガイドに書かれているように、レトロスペクティブとはスプ

TL;DR NewRelic は、ただの「監視ツール」じゃなく「オールインワンオブザーバビリティプラットフォーム」である 「APM」「ブラウザー監視」「インフラストラクチャ監視」「ログ管理」は既に弊チームに導入している 「Synthetic Monitoring」「Errors Inbox」「分散トレーシング」「CodeStream」は今後弊チームに導入していきたい はじめに こんにちは、NewRelic のゆるキャラ「ニャリック」のステッカーを会社の PC に貼っている内藤です。 先日、弊社の tomo_nxn さんと一緒に、「New Relic 実践入門 第2版」(翔泳社、3410円)を無料でもらう目的で 担当プロジェクトで New Relic を活用していく目的で、New Relic 日本法人初のハンズオンイベントに参加してきました w イベント内容については、tomo_nxn さん

あ…ありのまま今起こったことを話すぜ！ はじめに どうも、レバテックでCREをやっている住村です。 去年から飼い始めた犬が先日1歳の誕生日を迎えて、「もう1歳か」と「まだそれくらいしか経ってないのか」という矛盾した感覚を覚えます。 世のお父さんお母さんたちもこういう感覚なんでしょうか？ 先日、Gmailの送信ガイドラインの変更で各社でもList-Unsubscribeヘッダの対応に追われたり、自社ドメインのDMARC認証状況を確認するためにDMARCレポートを見るようになったりで様々な対応を迫られていると思います。 関連して、今回は自社のメーリングリストが他社のDMARCレポートで認証失敗として検知されたので、その対応で得た知見を書こうと思います。 概要 メーリングリストなどによるメールの転送時、DMARC認証に失敗することがある メール転送時にエンベロープFromが書き換わり、ヘッダFr

はじめに レバテック開発部SREチームに所属している井上です。 普段は、SREエンジニアとしてオブザーバビリティを強化したり、インフラをIaC化をしたりトイルの撲滅活動をしています。 最近弊社の社員がテックブログをたくさん書いており、有益な記事が多く投稿されていますが、真面目な記事が多いので、ここであえてポップな内容の記事を投稿しようと思いました。 新生活の時期となり、キーボードが気になる！という方が大勢いらっしゃると思います。 そこで、ビギナー向けのキーボードの楽しみ方 についてざっくり書いていきます！ （自作基盤やプログラムを作ったりキースイッチをハンダ付けしたり、modしたりしている方々はこの記事の内容では物足りないと思いますので、記事をそっ閉じしてくださいｗ） 外付けキーボードの魅力 さて、みなさんはパソコンで作業するときに外付けのキーボードを使っていますか？ ラップトップのビルト

TL;DR デザインシステム「VoLT」のデザイントークン(VoLT Design Tokens)の社内運用を開始 Tokens Studioを使用してデザイントークンを定義 token-transformerとstyle-dictionaryを使用してJSON連携とコード変換を実行 デザイントークンを社内向けにnpm packageとして配布 はじめに レバテック開発部でPdMとテックリードを担当している、ふるしょう(古庄)です。 今回はレバテックのデザインシステム「VoLT」が本格的に社内運用を始めたデザイントークンをどのように運用しているかを紹介します！ VoLTの誕生背景は、弊社CTO室のかわうそさんが先日公開した記事や、ビザスク社と開催した合同勉強会スライドにて発信しております！ デザイントークン(Design Tokens)とは デザイントークンとは、デザインシステムにおいて適

これはなに ども、レバテック開発部のもりたです。 タイトルの通りなんですが、SQLチューニングってつまり宣言型言語でリファクタリングするってことだよね、というのを書きます。なお具体的なリファクタの方法とか実行計画の読み方とかはスコープ外です（別で書く予定）。 SQLチューニングはリファクタリング まずSQLチューニングというと、パフォーマンス改善みたいな意味合いが強いと思います。ただ、SQLチューニングは本質的にはリファクタリング的な行為であるはずです。リファクタリングの定義を確認すると、 リファクタリングとは、ソフトウェアの外部の振る舞いを保ったままで、内部の構造を改善していく作業を指します。 引用元: 『リファクタリング 既存のコードを安全に改善する 第2版』 雑にいえば、結果を変えないでコードを改善することです。ここでいう改善とは内部品質を向上させることで、例えば保守容易性であったり

はじめに 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

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

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等はなかったので

取り急ぎの記載ですが、以下のpiyoさんの記事がかなりまとまっているのでこちらを読んでいただくのが良さそうです。 https://piyolog.hatenadiary.jp/entry/2024/04/01/035321 これはなに ここ数日インターネットで騒がれたxzのセキュリティ事案について一旦自分で調べたやつです。 ついでに、こういう件の当事者（自社製品に脆弱性が見つかったり、脆弱性を発見したり）になったときどうしよう、というところも少し調べました。 xzについて調べた内容 概要と結論 Linux向けに広く利用されていたxzにsshでバックドアできる脆弱性が埋め込まれていた 対象のバージョンはxz 5.6.0, 5.6.1 5.6.1が最新なので一般的なLinuxディストリビューションでは利用されてないっぽい RedHatの一部ディストロ以外は問題ない こちらの記事が正確 XZ U

これは『2023年度を数字で振り返る「技術広報LT大会」』の登壇内容について、 口頭で話したことを補足しつつ、その他話せなかったこと含めてドキュメントにまとめたものです。 LT大会は楽しいですね、各社の発表も有益情報が多かったので、また行こうと思います。 TL;DR テックブログの投稿本数が94倍、PV数が39倍に。 まずは、定石に則りアンチパターンを潰す。 自社の風土に合わせてローカライズしてアウトプットを継続する工夫を。 書きたいものを書いてもらった上で、「できる限り読まれる努力」は運営の責任。 当ドキュメントは色々私が書いてますが、全て編集長がやったことです。 荒廃したテックブログの再生 荒廃してました！ レバテック開発部としては、年2本しかテックブログを書いていませんでした。 荒廃の定義にもよりますが、私はこれを荒廃と見てました。 技術広報を促進していくタイミングで、まずはここから

これはなに ども、レバテック開発部のもりたです。 Aurora MySQLの2系が2024年10月31日にサポート終了となります。これに向けてどこもかしこも Aurora3系に移行していると思うので、Aurora2系（MySQL5.7）→ Aurora3系（MySQL8.0）の主だった変更点をまとめてみました。 前提と意図 Aurora3系と書いてますが、LTSであるAurora3.04を想定しています Aurora3.04はMySQL8.0.28に相当するので、そこまでの変更点を書きます MySQL8.0.28までの変更点を網羅すると膨大すぎるので、網羅はしません 詳しくはリリースノートなどを参照してください MySQL8.0の新機能 - MySQL8.0リファレンスマニュアル MySQL8.0〜MySQL8.0.37までのリリースノート - MySQL8.0リファレンスマニュアル Am

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

はじめに レバテック株式会社で主にサービスサイトのディレクターをしている山本です！ 普段はデザインシステムや、デザインの制作進行管理などをメインで担当しています。 レバテックでは、Figmaというデザインツールを用いて多くのメンバーがデザイン制作を行なっているんですが、いろんな人が各々のやり方でデザインデータを作成するので、属人的なズレがたくさん発生し、コミュニケーションコストや内部品質管理などの色々な問題が起きていました。 例 Auto LayoutとFrameが混在 コンポーネントのプロパティ名がバラバラ etc... 私自身、フロントエンドの理解はありつつもレバレジーズに入社してからFigmaを触り始めたため、社内のデザイナーにちょこちょこ質問を投げかけて勉強していました。当たり前に使っているtipsでも意外と「知らなかった」ような内容もたくさんあり、今回は私が「これは賢い！」と思っ

これはなに ども、レバテック開発部のもりたです。 クエリチューニングを学ぶとき、環境を作るのがとにかく面倒なんですが、そこんところをショートカットしてクエリチューニングの練習ができる環境を作りました。今回はそのご紹介です。 なお対象はMySQLです。 概要 こちらのリポジトリをクローンしてローカルのDockerで動かせます。 立ち上げ方等はREADMEにも書いてありますが、コンテナを立ち上げるとテーブルデータが入った状態で立ち上がります。改善可能なクエリが40本くらい用意してあるので、それのチューニングをして楽しいな、みたいな使い方を想定しています。書籍などでクエリチューニングの仕方自体は学んだんだけど、試す環境がないなあという方向けです。 動機と狙い なんのために作ったのかということも整理しておきたいんですが、RDB周りの勉強をしていて、ハンズオン系教材が少ないなと感じたのが発端です。W

これはなに ども、レバテック開発部のもりたです。家族全員風邪引いてます！！ 2024年2月より、レバテック開発部でもZennの運用を始めました。もりたはこういう記事を書くのが大好きで、社内のドキュメント共有システムに年間700本くらいの資料やメモ書きを残しています。たぶん記事を書くのは得意な方の人間だと思うので、どうやってアウトプットを作るのか？　という点についてこれを機にまとめてみました。 具体的に扱うのは、どうやって書くことを見つけて、どのように書くのか？　という点です。 構成 以下の点について書きます。 ネタ出し未満 企画 実際の書き方 書かないのは以下の点です アウトプットのメリット DevRelと技術記事 上手な文章の書き方 1. ネタ出し未満 ここでは、記事を書く前に、まず日常的にやっておくといいぞ、みたいなことを紹介します。記事っていきなりできるんじゃなくて、揺籃期みたいなの

（テーブルの構成は『SQLアンチパターン』p53を引用） このテーブルは要望とバグ報告が可能なチケット発行システムで利用されます。バグ報告の場合はseverity（重大さ）とversion_affected（影響のあるバージョン）の属性を含み、要望の場合はsponsor（要望元スポンサー）を含みます。そのほかの属性（date_reported, reporter, riority, status）は共通のものです。（以降、共通の属性を基底、issue_type別の属性をサブタイプなどと呼びます。） このような設計が取られる背景には、リレーショナルデータベースがそもそも拡張性に乏しく、その反面で開発者には少ない工数でシステムを拡張する柔軟性が求められるという点が挙げられます。ただ、RDB本来の責務である「データを守ること」に立ち返ったとき、この拡張性の乏しさは堅牢性の裏返しであり、基本的にメ

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

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

TL;DR スマホでQRコードを読み込むプロフィール交換アプリを開発した。 イベントソーシングだったり Hono だったり、気になる技術を試せた。 アプリのレスポンスが速く、懇親会も盛り上がったのでよかった！ はじめに レバテック開発部で基盤システムグループに所属している瀬尾です。 普段はマイクロサービスのつらみを味わったりしています。 昨年末に弊社で大規模な懇親会があり、そこでの交流を増やす目的として、互いの QR コードを読み取りプロフィールを交換するアプリを作りました。 この記事では、そのアプリをどんな技術でどのように開発していったかをご紹介しようと思います！ 技術スタック 言語 Typescript Go（Lambdaで使用） フロントエンド Node.js Next.js, TailwindCSS バックエンド Bun Hono, Prisma イベントソーシング インフラ AW