はてなブックマーク

この記事は Classi developers Advent Calendar 2022 の 22 日目の記事です。 こんにちは！Classiでモバイルエンジニアをしています、楠瀬大志（id:indiamela）です。 最近、とあるプロジェクトを進めるにあたって、動作検証用のミニアプリを作りました。 本稿ではiOSアプリ開発に絞り、ミニアプリからはじめる新規プロジェクト開発の進め方やメリットについて、僕が学んだことを書いていきたいと思います。 ※現在進行中のプロジェクトなので詳しい技術や画面は今回紹介しません。そういった内容はまた別の記事で紹介できればと思います。 背景 今回のプロジェクトは、先の見えないことが多く、ロジックや画面設計を手探りで決めるところから始めなければいけませんでした。 そういった状況では、新しいAPIの仕様やUI/UXを検討するために、モバイルアプリ上ですぐ試して確認

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

はじめに こんにちは！開発本部所属のエンジニアの id:kiryuanzu です。 9月8日(木) 〜 9月10日(土) にRubyKaigi 2022が開催されました。 今回弊社ではシルバースポンサーとして協賛し、3名のエンジニアがオフラインで RubyKaigi に3日間通して参加しました。本記事では参加メンバーによる感想レポートをお送りします。 参加する前 筆者自身は学生時代に何度かオフライン参加を経験したのですが、同行した2名の新卒エンジニアは今回が初参加となりました。行く前にできるだけ RubyKaigi がどんなものか知っておこうということで、開催1ヶ月前から igaigaさんによるプログラム解説を実施していただき、発表される内容の予習を行いました。 他にも、津の気になる飲食店をみんなで探して事前に予約したり、会ってみたい他社のエンジニアさんや OSS開発者の方について話すとい

こんにちは。新卒 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 ポートがオープンされていた このブログでは積極的に自分の感想やチームがやったことを共有したいと思っています。 全体的な感想 正直、悲しい気持ち半分、嬉しい気持ち半分で戸惑っています。予選の実施前には、ここま

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

みなさん、こんにちは。開発本部で本部長をしている徹郎(id:tetsuro-ito)です。 Classiでは今年度より組織のあり方を少し見直し、チームトポロジーの考え方も導入してみたので、今回はその過程の話を紹介します。 Classiのこれまでの組織 Classiでは、2020年に起こしてしまったセキュリティインシデントおよび高負荷障害の対策を全社でとるべく、組織のあり方を変えていました。 7月からは、動作しているすべてのコードに対して、チームの責任範囲を明確にしました。また、技術的な課題をそれぞれのチームの責任において改善するような動き方にも変えました。やるべきことが明確（「再建プロジェクト」と「セキュリティ強化」が最優先）で、かつ、チームが主体となって意思決定する形にしたことで、現在は各チームが担当する機能やリポジトリをしっかりとメンテナンスしていく、そんな体制になってきたと思います。

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

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

こんにちは、データエンジニアの滑川(@tomoyanamekawa)です。 Classiでは2022年5月に学校内のユーザー利用状況を集計し可視化したダッシュボード機能をリリースしました。 この機能のデータ集計は既存の社内用データ基盤からのReverse ETLで実現しました。 そのアーキテクチャの説明と「社内用データ基盤」から「ユーザー影響あるシステムの一部」になったことによる変化について紹介します。 ダッシュボード機能とは 概要 先生のみが利用可能な機能 先生と学年・クラスごとの生徒の利用状況を可視化したダッシュボードを提供する機能 要件・制約 アプリケーションはAWS上で動かす 前日までの利用状況がアプリケーション上で朝8時までに閲覧可能になっていること 学校/学年/クラスごとで集計する 学校を横断した集計はしない 既存の社内用データ基盤とは 社内でのデータ分析を主な用途としているB

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

こんにちは。開発本部の遠藤です。 ClassiではAmazon ECSをアプリケーション実行環境として利用しています。 ECSの各種メトリクスをDatadogを使ってモニタリングしながら、日々安定稼働しているかどうかをチェックしています。 そのうちの一つの重要なメトリクスとして、ECSのFargate TaskのCPU利用率が過度に高まっていないか、があるのですが、ある時期、CPU利用率が100%を超えてしまっていて「一体なにが起きてるんだ？？」と疑問を持ちました。 今回はそれについて深堀りしてみたので、ニッチなトピックですが紹介したいと思います。 ECS Fargate TaskのCPU利用率が100%を超えて表示されている こちらが実際にCPU利用率が100%を超えてしまったときのグラフです。 Datadogのメトリクスは ecs.fargate.cpu.percent です。なお、c

コミュニケーションチームのid:NozomuMiyamotoです。 Classiでは、2021年12月のAngularJSのEOLに向けて、Web Componentsを利用した段階的AngularJS脱出作戦を進めてきました。これはAngular Elementsと呼ばれるAngularで作成したコンポーネントをWebComponentsに変換する技術を用い、部分的にシステムリプレースを行う作戦です。 今回は、そこでぶつかった課題と解決に用いたWebComponentsの配信アーキテクチャについて紹介します。 背景 Classiにはplatformと呼ばれる最初期から存在する巨大なリポジトリがあります。このリポジトリには様々な言語で書かれた複数のサービスが共存しており、全体像を把握することが非常に困難です。これを管理可能なレベルまで解体するとともに、EOLを迎えるシステムの置き換えを行う

こんにちは、開発支援部基盤インフラチームの kenryooo です。 Classiでは過去の高負荷によるアクセス障害での反省を踏まえ、エンジニア向けに保守運用スキルを高める施策として、朝当番という制度を運用しています。今回はその紹介をします。 目的 朝当番制度は、下記を目的に運用しています。 Classiのピークタイム(毎朝8:00 - 9:30)に問題が起きた場合、社内向けにスムーズな情報連携を行う サービス品質の継続的な改善 パフォーマンスや監視内容に異常があった場合や、依存している外部接続システムやSaaSのメンテナンス情報などを担当チームへ共有する 担当エンジニアの育成 Classiシステムの全体像の理解 担当外のアプリケーション(リポジトリ)の理解 システム監視の入門(Datadog) インシデントハンドリングの入門 背景と課題 朝当番制度は、下記の背景と課題感からスタートしてい

この記事は Classi developers Advent Calendar 2021 の23日目の記事です。 こんにちは、プロダクト開発部の2年目の@minhquang4334です。 今年の8月に、同じ部で3年目の@henchiyb 先輩と一緒に yasuoチームを作り、ISUCON11 オンライン予選に初めて参加しました。参加するきっかけは弊社に業務委託として来てくださっている@soudaiさんからISUCONの話について聞かれて、面白そうなので、チャレンジしてみました。結果はRubyで4万点まで達成できましたが、全体のチームの100/598 位ぐらいで敗退してしまいました。 オンライン予選が終わった後、数百万点を達成したチームはどうやってそこまで出来たのかとずっと疑問でした。各チームの解説ブログを見てみましたが、目を通しただけですぐ忘れてしまい、知見を深く理解できないと思いました。

この記事はClassi developers Advent Calendar 2021の18日目の記事です。 昨日は基盤インフラチームのめるさんによる「バックエンドエンジニアが基盤インフラチームに異動して半年ほど経った話」でした。 こんにちは、データAI部でデータサイエンティストをしている高木です。 弊社では顧客である先生、生徒、保護者からClassiの機能や契約に関する問い合わせを日々頂いております。 これらの問い合わせの内容を分析し、Classiの現状の課題や今後解決していくための施策などを社内で検討しています。 今回は問い合わせ内容を言語処理技術の一つであるトピックモデルを使って分析した内容についてご紹介します。 なぜ分析する必要があったのか？ Classiへの問い合わせやその対応の内容は、担当者によってテキスト化された状態で管理されています。 弊社のカスタマーサポート・カスタマーサ

開発本部の onigra です。今回の記事は、Classiのアプリケーション実行環境をAmazon EC2からECSに移行しているお話をします。 この記事では「Ruby on RailsのWebアプリケーションをECSに移行する上での技術的なトピック」ではなく、「なぜClassiはEC2からECSに移行する必要があるのか」「どのように移行を進めているのか」についてをお話します。 なお、この記事は Classi developers Advent Calendar 2021 11日目の記事です。昨日は データプラットフォームチームの滑川さんによる Cloud Composer 2へのupgradeでどハマりした話 でした。 なぜEC2からECSに移行する必要があったのか 私が入社した当初、Classiは前述の通りAmazon EC2で稼働していました。それ自体に問題は無いのですが、サーバのプ

開発本部 認証連携チームでエンジニアをしている、id:ruru8net です。 これはClassi developers Advent Calendar 2021の9日目の記事です。 昨日の記事はこちらです。 Hardening 2021 Active Fault 参加レポート - 桐生あんずです 以前のClassi Advent Calender 2019では新卒が入社半年で社内サービスをリリースしてエンジニア楽しいってなったお話を書かせていただきましたが、あれから2年の間に業務の中で様々な経験をし、さらに知識やスキルを身につけていくことができました。 今日はその中でも自分が担当しているサービスの、バッチ監視の仕組みを考えたので紹介させてください。 背景 担当チームでは毎日深夜2時にDBからデータを削除するバッチを動かしています。 他にも社内では様々なバッチが動いていますが、これらを監視

この記事は Classi developers Advent Calendar 2021 の 7日目の記事です。 こんにちは。顧客サポート基盤チーム兼、技術戦略室にてエンジニアをしています、中島です。 みなさんは、日々仕事をする上で必須である「誰かに質問をする」という行為について、自信を持って適切に行うことはできているでしょうか？ 先月弊社では外部講師である、株式会社フィッシャーデータのあんちべさん をお招きし、質問力向上のための研修を実施しました。今回はこの研修を実施するに至った背景、研修内容を少しお見せするのと、社内の反響をお伝えします。 質問力を向上しよう！と至った背景 弊社は2020年2月頃よりリモートワークへの移行を行い、1年半以上が経過しました。リモートワークのお困りごととして一般的にもよく聞かれる、コミュニケーションについての課題を見聞きするようになってきました。 （ちなみに

はじめに すっかり寒くなりましたが、皆さまいかがお過ごしでしょうか。Classiの佐々木（@sasata299）です。 タイトルにもありますが、9月まで担っていた開発本部長*1を離れて、10月からエンジニアに役割を変えました。この記事では、どんなことを思って、どんな風に考えて進めてきたのかをお伝えできたらと思っています。 最近やっていたこと 開発本部として80名を超える大きな組織となり、最近は主にこの辺りに関わってきました。 開発本部として大切にしたいことを決定 CTOの責務を、VPoTとVPoEに分解*2 アラート対応の体制化や手当検討 既存の部から役割を分けて分割する形で、開発支援部の新設 評価体制の変更 余談ですが、こういった組織課題に対して、当初はVPoTである丸山（id:nkgt_chkonk）、稲富（@laco2net）、佐々木という3人体制でスクラムで進めていました。実際やっ

新卒入社三年目の小野です。校務チームで生徒を登録する機能の開発を行っています。 先日、弊社で新卒オンボーディングチームに所属されている @igaiga555 さんが主催するエラスティックリーダーシップ読書会を修了しました。会の概要や感想を書かせていただきます。 開催されるまでの流れ 新卒オンボーディングチームで、新卒メンバーにチーム開発時に知っておくべき知識を身につけて欲しい、という課題感があったようです。オンボーディングチームの方が、知識を身につけるには社内メンバーによく読まれている本を読むと良いのではと考えて、プロダクト開発部の雑談・相談チャンネルでマネジメントや組織についてのおすすめの本を募りました。結果、エラスティックリーダーシップ が最多得票しました。さらに、エラスティックリーダーシップについて、フロントエンドエキスパートチームの @lacolaco さんが「必読書で良いのでは」

こんにちは、サイバーセキュリティ推進部の野溝(@nomizooone)です。普段はClassiサービスの脆弱性診断や顧客対応などを担当しています。 先日、Hardening Projectにより開催された/dev/hardening – Hardening Drivers Conference 2021 のセッション「CSIRTの受援力」にて、私を含むClassiサイバーセキュリティ推進部の3名がパネラーとしてお話をさせていただきました。 「Hardening Project」（ハードニングプロジェクト）とはウェブサイトの安全性を追求する技術の啓蒙と人材の育成や、技術の社会的認知の向上による健全なネット社会への進歩に貢献することを目的としたセキュリティ界隈の皆さんにはおなじみのコミュニティです。 インシデント情報公開が登壇のきっかけに Classiは昨年度、大規模な個人情報漏えい事件をおこ

こんにちは、データAI部でPythonエンジニアをしている平田(@JesseTetsuya)です。普段は、PoCとデータをもってくる、というところ以外全部やる、というスタンスで開発業務を行っています。 日頃は、Flask1.1.4を利用していましたが、2021年5月11日にFlask2.0へのメジャーバージョンアップがありました。 メジャーバージョンアップということもあり、多くのアップデート項目がありました。そこで、特に日頃の業務に関わりそうなアップデートについて当記事にまとめていこうと思います。 Flaskとは？ Flaskは、PythonistaのArmin Ronachertによって2010年に初回リリースされました。いまでは、 Armin Ronacherを筆頭にPalletプロジェクトと言う名前でFlaskを含む、Flaskに関連する各ライブラリのメンテナンスがPalletプロジ