サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
やる気の出し方
tech.classi.jp
こんにちは、データプラットフォームチームの鳥山(@to_lz1)です。 Classiでは、2019年ごろからデータ基盤に「ソクラテス」の愛称をつけて運用を続けています。初期の構成は2021年に書かれたエントリ*1にも詳しいですが、数年の間に進化したことも増えてきました。 大きな変化の一例として、最近、私たちのチームではdbt*2を導入してジョブ間の依存管理やメタデータの管理を改善しました。 本記事ではこの取り組みをピックアップして紹介します。また、進化したソクラテスの構成図をアップデートするとともに、Classiデータプラットフォームチームの最新版の雰囲気もお伝えできればと思います。 dbt移行前の構成 ジョブ間の依存管理がつらい メタデータの管理がつらい 過去との差分と、移行への機運 周辺ツールのエコシステムが整った エンジニア以外のメンバーがPull Requestを出すことが減った
はじめに ソフトウェアエンジニアの onigra です。タイトルの通り、Classiは技術コミュニティの勉強会・ミートアップ等に、自社のイベントスペースを会場として提供致します。 昨今、オフラインでの勉強会・カンファレンス・ミートアップの盛り上がりを強く感じており、RubyKaigiはもちろんのこと、 Omotesando.rb などをはじめとした地域Ruby Meetupもオフライン開催がされるようになってきました。私も先日再開した Shinjuku.rb のドリンクアップに参加してきました。 参加者と交流する中で、今後の会場探しに困っていると伺ったので、西新宿にオフィスがあるClassiも会場提供できるという話をし、その流れからオーガナイザーの1人である tdakakさん より運営参加のお誘いを受けたので、引き受けることにしました。 Shinjuku.rbの再会&運営参加の経緯について
こんにちは。プロダクト本部でエンジニアをしています daichi ( id:da1chi24 ) です。 先日、社内でGitLab本の輪読会を実施しました。 さらに今回はそれだけでなく、同時期に同じ本の輪読会をした他社の方と合同で振り返りを行うイベントに参加しました。 今回は輪読会や、他社と合同で行った輪読会の振り返りの内容、経緯や学び、参加した感想をシェアします。 GitLab本とは 「GitLabに学ぶ世界最先端のリモート組織のつくりかた」(以下 GitLab本)という本です。 www.shoeisha.co.jp この本はGitLab社が公開している「The GitLab Handbook」というドキュメントを参考に、著者が自社をリモートワーク化した実体験を通して得られたノウハウをまとめた内容が書かれています。 大まかな章立ては以下のようになっています。 リモート組織のメリットを読み
[2024年4月25日 追記] Safariの動作について考慮漏れがありましたので、一部追記・編集しました。 新宿にオフィスのあるClassiは、岡山在住の私のような地方在住者だけでなく、いわゆる通勤圏内に在住していてもリモートワークで働いている人が多い会社です。必然的にミーティングはいわゆるオンラインミーティングとなり、主にGoogle Meetが利用されています。 そのGoogle Meetのチャット機能、ここ1週間ぐらい「IMEで日本語に変換のために押すエンターキーで送信されてしまう」という現象が発生しています。このエントリーを読まれている時点では対応しているかも知れませんが、2024年4月22日17時時点ではその現象は続いています(Windowsでは再現しないという情報もあります)。 入力開始 変換して確定のエンターキーを押すと 送信される エンターキーに頼らない日本語入力を頑張り
こんにちは、データプラットフォームチームの鳥山(@to_lz1)です。エンジニアの皆さん、自分のチームのパフォーマンス、計測していますか? DevOps Research and Assessment(DORA)の2019年のレポート により、開発チームのパフォーマンスを示す指標として提唱された「Four Keys」。この中に「デプロイ頻度」「変更のリードタイム」という指標があります。 『LeanとDevOpsの科学』など有名な書籍で取り上げられたこともありFour Keysそのものが広く知られるようになりましたが*1、この度Classiでもこれらの指標を可視化するダッシュボードを構築し、社内提供を始めました。 計測の事例がインターネット上に多くある中でも、 横展開を極力容易にするための設計 リリースをしてみてから「実際に役に立てる」までの工夫とフォローアップ といった辺りに独自性があるか
こんにちは。エンジニアのすずまさです。 去年の夏頃にリードタイムの計測を始めてから、振り返りで良い気づきを得られるようになったりリードタイムを減らすアクションが生まれたりと良いことがたくさんあったので、今回はその紹介をしようと思います。 リードタイムの定義 『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 でソフトウェアエンジニアやってます koki です。 Findy さま主催の「Terraform活用大全 - IaCの今。 Lunch LT」に「Terraform に test コマンドがやってきた」というタイトルで登壇してきました。 Togetter まとめ イベントのアーカイブ動画は Findy にログインするとイベントページから閲覧できます。 登壇のきっかけ SNS 経由で Findy さまからお声がけいただきました。 よく Zenn で Terraform に関する記事を書いていたのを見ていただけたようです。 ちょうど最近リリースされたTerraform の test コマンドをキャッチアップしたいと思っていたところだったので、自分の学びのためにも登壇を快諾しました。 これが俗に言う登壇駆動学習ですね。 発表内容 Terraform v1.6 で新しく
こんにちは、プロダクト開発部の藤田です。 今回は Amazon ECS(以下、ECS) と AWS Step Functions(以下、Step Functions) を組み合わせた「ワンショットタスクの実行基盤」についてご紹介します。 「ワンショットタスク」とは、指定されたコマンドやスクリプトを1度だけ実行して、終了するタスクのことです。 このようなワンショットタスクは「プライベートネットワークの内側にあるリソースへのアクセスが必要な、非定型的な操作」を実行する際などに用いられます。 例えば、プライベートネットワークの内側にある DB に対して、以下のような作業をエンジニアが実施する際に、ssh を利用して踏み台サーバーに接続して、決められた手順書を実行する・・・といったような場面を想像していただければ、イメージしやすいと思います。 DB にテーブルを追加するための migration
こんにちは、 Classi でソフトウェアエンジニアやってます koki です。 この記事では、 Renovate によって Classi の社内向け npm package を自動アップデートさせるために行った設定についてまとめます。 概要 Classi では、社内向けの共通ライブラリや Docker イメージなどを GitHub Packages で管理しています。 この GitHub Packages の利用により、それらのプライベートなパッケージを社内の様々なシステムから安全且つ効率的に利用することを実現しています。 例えば、今年の 6 月にプレスリリースが出された学習トレーニング機能を裏で支えているコンテンツ管理システムで利用している GraphQL Schema は GitHub Packages の npm registry でプライベートな npm package として管
こんにちは!学習動画・Webテストの開発を行っています エンジニアの daichi (id:kudoa) です。 この記事では、最近チームで導入したライブラリアップデートを自動化した仕組みとその経緯について紹介します。 なぜ自動化しようと思ったか サービスを開発するだけではなく、日々の運用も必要です。 その運用業務の1つとして、ライブラリのアップデートがあります。 これはサービスを運用する上では大切なことではありますが、日々ライブラリアップデートのPRをさばき続けるのも大変です。 その時間をできるだけ減らし、その分空いた時間をユーザーへの価値提供や将来の投資に充てるために、今回の自動化の仕組みを作成しました。 この辺りの話は以前勉強会でLTしたことがありますので、興味があればご覧ください。 作ったもの 前置きは長くなりましたが、凝ったものを作ったわけではありません。 作成したものはライブラ
こんにちは・こんばんは・おはようございます、エンジニアの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
こんにちは、最近データエンジニア業を多くやっているデータサイエンティストの白瀧です。 これまでClassiのデータ基盤は、Reverse ETLをしたり監視システムを導入したりとさまざまな進化をしてきました。しかし、Classiプロダクトが発展するとともにデータ量が増加し、これまでのデータ基盤では耐えられない状態に近づいてきました。 そこでデータ基盤の一部(DBからのExportを担う部分)のリアーキテクチャを実施したので、この記事で紹介したいと思います。 概要 Classiのデータ基盤では、Amazon RDSからAmazon S3へJSONで出力し、その後GCS→BigQueryという流れでデータを送り、BigQueryからもBIツールやReverse ETLなどで使っています。詳細は、Classiのデータ分析基盤であるソクラテスの紹介 - Classi開発者ブログを参照してください。
先日「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:tetsuro-itoです。 時は師走、ソフトウェアテック界隈ではおなじみとなったアドベントカレンダーの季節でした。 当社もClassi developers Advent Calendar 2022と銘打ち、24本の記事が集まりました。 今年のアドベントカレンダーを振り返る記事で締めさせていただきます。 Classi developers Advent Calendar2022 昨年も同じ方式での振り返りをしていますが、今年も同様のテイストで編集部で改めて投稿された記事を振り返り、一言ずつコメントで紹介することにしました。 もしまだご覧になっていない記事があったらぜひこの機会に読んでみてください。 振り返り 12/1 id:tetsuro-ito: 開発本部でレポートラインを整理してユニット制度を導入した話 id:Clas
みなさま、おはこんハロチャオ〜。開発支援部所属のid:aerealです。 この記事ではClassiにおけるGitHub運用委員という役割とその仕事について紹介します。 また、この記事はClassi developers Advent Calendar 2022 - Adventarの2日目の記事としてお届けします。 GitHub運用委員とは Classiでは開発のコラボレーションツールとしてGitHubを活用しています。 Webサービスで事業を提供する企業にとって最も重要なソフトウェア資産といえるソースコードをホストするサービスですから不適切に扱えば重大な損害を被ることになりますし、最近はGitHub ActionsというCIサービスも利用できますから一歩間違えれば本番環境で稼働動しているサービスに大きな影響を与えかねません。 当社には情シスやサイバーセキュリティ推進部といった部署が存在し
こんにちは。新卒 1 年目エンジニアのすずまさです。 先日、弊社 VPoT の id:nkgt_chkonk が執筆した process-book の勉強会を修了しました。 process-book は *nix系のシステムにおけるプロセスやシグナルなどについて説明することを目的に書かれました。「プロセスとかよくわかってないからちゃんと知りたいな」みたいなひとたちが想定読者です。 参加する前は UNIX の基礎的な知識も乏しかった私ですが、学びがたくさんあり毎回楽しく参加できたので紹介します。 開催の経緯 Slack でシェルスクリプトの話題で盛り上がったのをきっかけに、プロセスモデルの重要性が話に挙がり、流れでその日のうちに「process-book 読もう会」が誕生しました。 進め方は下記の通りです。 日時: 毎週木曜日 15:00〜15:30 週に 1 章ペースで進める 初めに各章ご
こんにちは、ラーニング・学習トレーニングチームの id:tkdn です。 今日は Jest shard オプションを使って CI でどうカバレッジ計測をしたか について書いていきます。 Jest v28 shard オプション Jest v28 から shard オプションが入りました。このオプションでテスト実行を指定の数で分割することができます。 Jest's own test suite on CI went from about 10 minutes to 3 on Ubuntu, and on Windows from 20 minutes to 7. 公式のアナウンスでもあるとおりですが、Jest 自身の CI でのテストが 20 分から 7 分になったという速度の変わりようです。 私たちのチームではリモートという状況の中で TDD /モブプロを実践しており、コミットによりバトン
TL;DR こんにちは。Classi開発部のminhquang4334です。 今年は開発支援部のhenchiyb先輩と一緒に 2回目でyasuoチームとして ISUCON12の予選に参加しました (参考: 1回目で参加したブログ)。 最終結果は予選通過スコアを超えて、 4位/700チーム相当でしたが、SecurityGroupの TCP:8080 ポートがオープンされていたため、レギュレーションに引っ掛かって失敗しました。 以下のチームは予選通過スコアを記録していましたが、追試において失格となっています。 yasuo 環境チェックにおいて、SecurityGroupの TCP:8080 ポートがオープンされていた このブログでは積極的に自分の感想やチームがやったことを共有したいと思っています。 全体的な感想 正直、悲しい気持ち半分、嬉しい気持ち半分で戸惑っています。予選の実施前には、ここま
みなさん、こんにちは。開発本部で本部長をしている徹郎(id:tetsuro-ito)です。 Classiでは今年度より組織のあり方を少し見直し、チームトポロジーの考え方も導入してみたので、今回はその過程の話を紹介します。 Classiのこれまでの組織 Classiでは、2020年に起こしてしまったセキュリティインシデントおよび高負荷障害の対策を全社でとるべく、組織のあり方を変えていました。 7月からは、動作しているすべてのコードに対して、チームの責任範囲を明確にしました。また、技術的な課題をそれぞれのチームの責任において改善するような動き方にも変えました。やるべきことが明確(「再建プロジェクト」と「セキュリティ強化」が最優先)で、かつ、チームが主体となって意思決定する形にしたことで、現在は各チームが担当する機能やリポジトリをしっかりとメンテナンスしていく、そんな体制になってきたと思います。
VPoTの丸山です。本日はClassiがいまのところどういうスタンスで技術選定に臨んでいるのかについてお話しします。これは「いまのところ」のスタンスであり、未来永劫このようなスタンスでいくかどうかというのは定かではありませんが、考え方のひとつとして参考になれば幸いです。 技術選定にハードリミットはかけない 結論から言うと、Classiでは「この技術スタックを必ず使ってください」という制限はかけていませんし、かけるつもりもいまのところありません。その理由は大きくふたつあります。 ひとつは、組織全体の視点でみた時に、技術スタックに関する健全な新陳代謝の機会を奪わないため、もうひとつは、メンバーレベルの視点でみても、複数の技術に触れる機会が成長につながるからです。 新陳代謝を行う機会を奪わない、というのは、どういうことでしょうか。 ひとつの技術スタックを極めていくことにも良い点はあります。ノウハ
次のページ
このページを最初にブックマークしてみませんか?
『Classi開発者ブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く