こんにちは。4月にClassiへ新卒で入社した伊森です。 私は4月から8月上旬までの約4ヶ月、Classiのエンジニアとして働くための新卒研修を受けてきました。 今回はその研修期間を経て、大まかな内容の振り返りや身についた考え方を紹介していきます。 入社前の状態 研修内容の概要 ４月 ５・６月 ７・８月上旬 AWS研修 良かったところ 物足りなかったところ QA研修 実際に手を動かすテスト項目の作成課題 「品質が高い」とはどの状態を指す言葉？というディスカッション 万葉カリキュラム 研修プログラム以外にも学んだこと まとめ 入社前の状態 大学生時代はPythonを使用した画像処理を主に勉強しており、これまでWeb上で動くものを開発する世界に踏み込んだことはほとんどありませんでした。 そのため、Webの基本的な概念であるHTMLなどはぼんやりとした理解に留まっており「触ったことはあるがそれで

プロダクト本部 tetoru 開発部の中田です。普段は giraffate という ID を使っていることが多いです。 ここでは、弊社が提供している小中学校向け保護者連絡配信サービス tetoru の利用している Ruby のバージョンを 3.2 から 3.3 にバージョンアップしたときの話を共有します。 概要 tetoru では、本文章の執筆時点で Ruby 3.3.4 + YJIT で Rails アプリケーションを動かしています。YJIT とは、Ruby が備えている Just-In-Time (JIT) コンパイラの機能で、これを有効化することで実行時に機械語が生成されアプリケーションの高速化につながります。YJIT に関する詳細についてはこちらの記事をご覧ください。 Ruby 3.2.2 + YJIT から Ruby 3.3.0 + YJIT にバージョンアップした時には多少レイ

はじめに ソフトウェアエンジニアの onigra です。タイトルの通り、Classiは技術コミュニティの勉強会・ミートアップ等に、自社のイベントスペースを会場として提供致します。 昨今、オフラインでの勉強会・カンファレンス・ミートアップの盛り上がりを強く感じており、RubyKaigiはもちろんのこと、 Omotesando.rb などをはじめとした地域Ruby Meetupもオフライン開催がされるようになってきました。私も先日再開した Shinjuku.rb のドリンクアップに参加してきました。 参加者と交流する中で、今後の会場探しに困っていると伺ったので、西新宿にオフィスがあるClassiも会場提供できるという話をし、その流れからオーガナイザーの1人である tdakakさん より運営参加のお誘いを受けたので、引き受けることにしました。 Shinjuku.rbの再会&運営参加の経緯について

[2024年4月25日 追記] Safariの動作について考慮漏れがありましたので、一部追記・編集しました。 新宿にオフィスのあるClassiは、岡山在住の私のような地方在住者だけでなく、いわゆる通勤圏内に在住していてもリモートワークで働いている人が多い会社です。必然的にミーティングはいわゆるオンラインミーティングとなり、主にGoogle Meetが利用されています。 そのGoogle Meetのチャット機能、ここ1週間ぐらい「IMEで日本語に変換のために押すエンターキーで送信されてしまう」という現象が発生しています。このエントリーを読まれている時点では対応しているかも知れませんが、2024年4月22日17時時点ではその現象は続いています（Windowsでは再現しないという情報もあります）。 入力開始 変換して確定のエンターキーを押すと 送信される エンターキーに頼らない日本語入力を頑張り

こんにちは。プロダクト本部プラットフォーム部SREチームの id:ut61z です。 SREチームが主体となってSLO本読書会を社内で実施しました。 そしてなんと贅沢なことに、監訳、翻訳に携わった Google Cloud の Developer Relations Engineer である山口能迪さん(@ymotongpoo、以下山口さん)にゲストとしてお越しいただき、読書会で出てきた疑問をぶつけてSLOについて理解を深める会を開催しました。 今回は読書会、そして山口さんを囲んでSLOの理解を深める会について、経緯や読書会の進め方、学んだことなどをレポートしたいと思います。 SLO本とは? O'REILLY から翻訳書が出版されているこちらの『SLO サービスレベル目標』という書籍(以後：SLO本)です。 www.oreilly.co.jp SLI・SLO・エラーバジェットの3つについて

こんにちは。エンジニアのすずまさです。 去年の夏頃にリードタイムの計測を始めてから、振り返りで良い気づきを得られるようになったりリードタイムを減らすアクションが生まれたりと良いことがたくさんあったので、今回はその紹介をしようと思います。 リードタイムの定義 『LeanとDevOpsの科学』では、リードタイムを「コードのコミットから本番稼働までの所要時間」として定義しています。 私たちのチームのリポジトリではブランチ戦略としてGitHub Flowを採用しており、mainへのマージと本番稼働のタイミングが近しいため「PRをopenしてからマージするまでの期間」をリードタイムとして定めて計測しました。 リードタイム計測を始めた動機 私たちのチームでは「チームのスピードがあまり出ていない気がする」という漠然とした課題感がありました。しかし、課題感はありつつも、ではどうするかと言われると具体的なア

こんにちは。プロダクト本部Growth部でエンジニアをしている id:ruru8net です。 前回はこちらの記事を書かせていただきました。 tech.classi.jp 今日は前述したSRE留学中にやったことの中の「Amazon Auroraの監査ログをCloudWatch Logsを経由せずS3に保存する」を紹介したいと思います。 前提 前掲の記事にもある通り、弊社のAWSにかかっているコストを調査したところCloudWatch Logsの特にAmazon RDSの監査ログの保存にコストがかかっていることがわかりました。今回は弊社で最も使用しているAmazon AuroraのMySQLのみを対象として、監査ログをCloudWatch Logsを経由せずS3に保存する仕組みを作成しました。 作成した仕組み こちらのオープンソースの仕組みを参考に構築、またLambdaのソースを使いました。

みなさん、こんにちは。日頃からClassi開発者ブログをご覧いただき、ありがとうございます。編集部のid:tetsuro-ito です。 すっかり秋も深まって寒くなってきました。今年の夏は暑く、冬も暖冬傾向が続くそうですが、寒いものはやはり寒いですね。季節の変わり目は体調を崩しやすい時期なので、注意したいところです。 さて、冬になると、IT業界では恒例のイベントとなったAdvent calendarがさまざまな切り口で開催されます。 Classiも2016年から毎年このイベントの企画をやってきました。 Classi Advent Calendar 2016 Classi Advent Calendar 2017 Classi Advent Calendar 2018 Classi Advent Calendar 2019 Classi Advent Calendar 2020 Classi

こんにちは・こんばんは・おはようございます、エンジニアのid:aerealです。 以前、 実践OpenTelemetry - Classi開発者ブログ で紹介したようにOpenTelemetryを監視フレームワークとして導入しています。 前回の記事ではECSサービスで動くGoで書かれたWebアプリケーションへ導入しましたが、今回はAWS Lambdaの関数からOpenTelemetryを用いてDatadogにトレースを送るための試行錯誤について紹介します。 LambdaからDatadogにトレースを送りたい AWS Lambdaは小〜中程度のタスクを大量に実行することに向いたFaaSです。 汎用性・柔軟性という点ではECSなどのコンテナワークロードと比べると実行環境などに設けられた制約がやや多いですが、その代わりに最適化された実行環境で実行されるのでうまくワークロードと噛み合えばまさに安い

こんにちは・こんばんは・おはようございます、エンジニアのid:aerealです。 この記事では筆者が開発に参加しているサービスの監視フレームワークをOpenTelemetryへ移行した際の体験を紹介します。 OpenTelemetryとは OpenTelemetry is an Observability framework and toolkit designed to create and manage telemetry data such as traces, metrics, and logs. What is OpenTelemetry? サイトの説明にある通り分散トレースやメトリクス、ログなどの指標を扱う監視フレームワークです。 OpenTracingやOpenCensusなどを継承・統合したプロジェクトと言うと合点がいく方も多いのではないでしょうか。 OpenTelemet

先日「Google Meet Chat to Clipboard」というChrome拡張機能を公開しました。Google Meetから退出する時に、チャットが残っていれば自動でクリップボードに保存するというものです。 このアイデアは、社内のSlackでたびたび見かけた「Google Meetのチャットを保存し忘れた」という問題から生まれました。 個人のプロジェクトとして作成・公開しましたが、きっかけは社内にありました。そして、ChatGPTに併走してもらいながら制作した過程について少し話したところ、思った以上に興味をもってもらい、ここで紹介することになりました。 こういった弊社での小ネタ的ChatGPTの活用事例は、ChatGPTと大規模言語モデルのLT会を開きました - Classi開発者ブログでも紹介されていますので、興味があるかたはご覧ください。 制作過程 冒頭にもあるとおり、最初か

GitHub Actions と Release Please を使ったアプリケーションのリリース自動化 こんにちは @lacolaco です。最近は、先日プレスリリースが出された「学習トレーニング」機能を裏で支えているコンテンツ管理システム（以下内部CMS）の開発に携わっています。 corp.classi.jp この記事では、内部CMSのフロントエンド（Angular アプリケーション）のリリースフローを自動化している仕組みを紹介します。現在のリリースフローの全体像は次の図のようになっています。この中にある Release Please というのが、今回特に紹介したいツールです。いくつか日本語でのブログ記事などもあるので特にマイナーというわけではないと思いますが、多くの場合はライブラリのリリースに使われています。一方、アプリケーションのリリースで使っているケースはあまり発信されてないよう

こんにちは、id:aerealです。 今回はGraphQLのスキーマ管理を工夫している点について紹介します。 背景 対象となるアプリケーションは先日プレスリリースが出された学習トレーニング機能を裏で支えているコンテンツ管理システム (以下、内部CMS) で、エンドユーザ向けを含む複数のサービスから呼び出されます。またAngularで書かれたWeb UIを備えます。 内部CMSを開発するチーム内には主にサーバサイドを担当するメンバーと、主にクライアントサイドを担当するメンバーとがおり、どちらもGraphQLを用いた開発経験があります。 この内部CMSはスクラッチから開発を始めており、目指すリリース予定日に対してやることは山積みなのでうまくタスクを分担したい状況にありました。 時と場合によってはクライアントサイドのチームの手が空いていたりあるいは逆になったり、状況は目まぐるしく変わります。 で

みなさま、おはこんハロチャオ〜。開発支援部所属のid:aerealです。 この記事ではClassiにおけるGitHub運用委員という役割とその仕事について紹介します。 また、この記事はClassi developers Advent Calendar 2022 - Adventarの2日目の記事としてお届けします。 GitHub運用委員とは Classiでは開発のコラボレーションツールとしてGitHubを活用しています。 Webサービスで事業を提供する企業にとって最も重要なソフトウェア資産といえるソースコードをホストするサービスですから不適切に扱えば重大な損害を被ることになりますし、最近はGitHub ActionsというCIサービスも利用できますから一歩間違えれば本番環境で稼働動しているサービスに大きな影響を与えかねません。 当社には情シスやサイバーセキュリティ推進部といった部署が存在し

TL;DR こんにちは。Classi開発部のminhquang4334です。 今年は開発支援部のhenchiyb先輩と一緒に 2回目でyasuoチームとして ISUCON12の予選に参加しました (参考: 1回目で参加したブログ)。 最終結果は予選通過スコアを超えて、 4位/700チーム相当でしたが、SecurityGroupの TCP:8080 ポートがオープンされていたため、レギュレーションに引っ掛かって失敗しました。 以下のチームは予選通過スコアを記録していましたが、追試において失格となっています。 yasuo 環境チェックにおいて、SecurityGroupの TCP:8080 ポートがオープンされていた このブログでは積極的に自分の感想やチームがやったことを共有したいと思っています。 全体的な感想 正直、悲しい気持ち半分、嬉しい気持ち半分で戸惑っています。予選の実施前には、ここま

こんにちは、データエンジニアの石井です。 先日公開した記事「社内向けのデータ基盤から集計結果をReverse ETLしてサービスに組み込んだ話」で、ダッシュボード機能のリリースにより、Classiのデータ基盤が「社内用データ基盤」から「ユーザー影響あるシステムの一部」へ進化した話をしました。「ユーザー影響あるシステムの一部」への進化に伴い、データ基盤の品質担保は必要不可欠です。今回は、データ基盤の品質向上に取り組んだKANTプロジェクトについてご紹介します。 KANTプロジェクト 背景・課題 Classiのデータ基盤がユーザー影響あるシステムの一部になる前、つまり社内用データ基盤だった頃には以下のような課題がありました。 データ基盤の状態把握 マルチクラウドにおけるデータ基盤全体の状態把握ができていなかった データ基盤の実行状態（SUCCESS, FAIL, RUNNINGなど）の把握が、

はじめに こんにちは、開発本部所属エンジニアの id:kiryuanzu です。 現在、Classi ではサービスのセキュリティリスクをできる限りなくすために Content Security Policy を導入して脆弱性を検知する仕組みの導入を進めています。 本記事ではこの仕組みを導入する上でどのような手順が必要であり、どのような箇所で苦戦するポイントがあったかについて紹介していきます。 筆者は今まで CSP対応に携わったことがなかったのですが、導入段階の時点で想定していたよりも様々な知識が必要なことがわかり、記事にしたいと思いました。 もし数ヶ月前の自分と同じように初めてCSP対応に関わる人の一助となれば幸いです。 Content Security Policy (通称: CSP) って何? Content Security Policy とは、HTTPヘッダの種類の1つであり、クロ

VPoTの丸山です。本日はClassiがいまのところどういうスタンスで技術選定に臨んでいるのかについてお話しします。これは「いまのところ」のスタンスであり、未来永劫このようなスタンスでいくかどうかというのは定かではありませんが、考え方のひとつとして参考になれば幸いです。 技術選定にハードリミットはかけない 結論から言うと、Classiでは「この技術スタックを必ず使ってください」という制限はかけていませんし、かけるつもりもいまのところありません。その理由は大きくふたつあります。 ひとつは、組織全体の視点でみた時に、技術スタックに関する健全な新陳代謝の機会を奪わないため、もうひとつは、メンバーレベルの視点でみても、複数の技術に触れる機会が成長につながるからです。 新陳代謝を行う機会を奪わない、というのは、どういうことでしょうか。 ひとつの技術スタックを極めていくことにも良い点はあります。ノウハ

深夜の定期バッチの監視 Webサービスのオフピーク時に重たい処理を実行させるというのは一般的なプラクティスといえます。 特に深夜〜早朝は多くのサービスでバッチ処理を実行させているのではないでしょうか。 Webサービスだけではなく、当然バッチ処理も監視して失敗したらそれを発見し対処したいです。 しかし、失敗を発見しても即座にユーザ影響がないので対応は後でも良いという場合、素朴に監視ルールを作るとバッチが失敗した深夜・早朝にアラートが発報されることになります。 発報されたアラートを見て「これは今すぐに対応してなくても良いな」と判断するのであれば、それは狼少年アラートといえるのではないでしょうか。 悪貨が良貨を駆逐すると言われるように、狼少年アラートがはびこれば良貨のアラートもいずれ無視されるようになってしまうことは容易に想像できます。 Datadogの timeshift 関数でアラートの発報

こんにちは。開発本部 認証連携チームでエンジニアをしている id:ruru8net です。前回はこちらの記事を書かせていただきました。 tech.classi.jp 現在は認証基盤再建というプロジェクトの中で、主にフロントエンド開発を担当しています。この記事ではフロントエンド開発においてAPIのモックのために「Mock Service Worker」を使ったところスムーズに開発を進めることができたので、使い方を紹介したいと思います。 mswjs.io ツールの導入 弊社ではフロントエンドのフレームワークにAngularを採用しているのでAngularでの導入手順を記します。 基本的にはドキュメントの手順通りです。 1. インストール $ npm install msw --save-dev # or $ yarn add msw --dev 2. モックを定義 src/mocks/hand