TypeScriptは強力な型システムが魅力です。 しかし、複雑な型定義は理解が難しいです。特にライブラリの型定義などはジェネリクスや交差型などがネストしていることも多く、すぐに把握するのが難しい場合があります。 Visual Studio Code（以下VSCode）でTypeScriptの開発をしている際、型にカーソルをホバーすると型情報が表示されます。 しかし、深いネストや複雑な型の場合、展開される情報が不十分で、定義を追う必要があります。 そんな時に役立つVSCodeの拡張機能がないかな〜と探していたら「Prettify TypeScript」というぴったりの拡張機能を発見しました！この拡張機能を使うと、ホバーした時に型が展開された状態で表示されるため、型情報を把握しやすくなります。 Prettify TypeScriptの概要 Prettify TypeScriptを使用すること

こんにちは。 atama plus株式会社の @kzk-maeda です。 最近VPoE始めました。 あと最近テクニカルライターになりました。 この記事では、エンジニアチームで技術ブログを執筆する文化を促進するために開催した「みんなでTechBlog書いてみようWorkshop」の取り組みとその成果について紹介します。 また、その際に作成した記事のカタ「TechBlog執筆指南書」全文も併せて公開しますので、みなさんの記事作成の一助になれば幸いです！ 「TechBlog執筆指南書」は末尾に記載するのでぜひご参照ください！ Workshop開催についての話 Workshop開催の発端 Engineering Management室という、atama plusのEngineering Manager陣を集めたチームの推進テーマの一つに「技術広報の促進」が掲げられていました。 この活動の目的は、

はじめに atama plusで働くエンジニアのミッチーです。 最近、私のチームで初めて業務委託エンジニアの方にJoinいただきました。atama plusのプロダクトチームは、スクラム開発を採用しており、密なコミュニケーションを取りながら日々働いています。フルタイムで動くスクラムチームと週2-3日稼働の業務委託エンジニアが協力しながらどのように開発を進めていったか、いくつか工夫があったのでその点について書いてみようと思います。普段スクラム開発をしていて、これから業務委託の方にJoinいただくことを検討している方に、少しでも参考になれば嬉しいです。 採用とオンボーディング 採用プロセスについて細かくは書きませんが、面談時には働き方のイメージがすり合わせられるよう、どのようなチケットを渡す予定か簡単に説明しました。 チケットの種類は、バグの調査・修正や、その他開発テーマの実装が主になること

こんにちは！atama plusのhikarinです。 Webサービスにおいて、パフォーマンスは非常に重要です。2017年と2018年のGoogleの調査（出典）によると、ページ表示速度が1秒から3秒になると直帰率が32%増加し、6秒になると106%増加すると報告されています。このように、ページの読み込み速度が遅れるだけでユーザーが離脱するリスクが高まるのです。 また、パフォーマンスと言えば、最近ではService Level Objective（SLO）とService Level Indicator（SLI）をSREで決めて運用している組織が増えています。これにより、サービスの信頼性とユーザー体験を高める努力がなされています。 本記事では、組織全体でパフォーマンス課題に向き合うための体制づくりについて紹介します。 atama plusが抱えていた問題：パフォーマンス課題に組織全体で取り

こんにちは！atama plusでQAをやっている池上です。 ソフトウェア開発においては、QCD（品質・コスト・納期）のバランスを整えながら、ユーザーに良いプロダクトを提供することが重要です。 本記事では、教材という特性を踏まえたテストケースの効率化について紹介します。 はじめに atama plusでは、学生向けのAIを用いた学習システムを開発しており、複数の開発チームがそれぞれ同一プロダクトの異なる部分を担当しています。 リリース前には各チームのプログラムを統合し、網羅的なリグレッションテストである「リリーステスト」を実施しています。 QAチームは、生徒の学習体験を網羅することを最優先に考え、全教科に対してリリーステストを行っていました。 そのため、各教科に対応した多くのテストケースが作成され、リリーステストは大規模なプロジェクトとなっていました。 テストケース増加に伴うリスク 202

TypeScriptではtype alias syntax（型エイリアス構文）とinterface declaration（インターフェース宣言）を使って型を定義できます。 おおよそ両者同じことができるので、どちらを使うか迷います。 両者の使い分けに関する記事は沢山あります。 これらの記事を読んで基本的にはtypeを使えば良いと思っていました。 ですが最近以下のことがあり、typeとinterfaceの使い分けがわからなくなってしまいました。 typeよりもinterfaceの方がコンパイルのパフォーマンスが良いという話を耳にした。 interfaceしか使えない特定の機能を知った。 そこでtypeとinterfaceの違いを学んで、どう使い分ければよいかを整理しました。 type, interfaceそれぞれのメリット typeのメリット interfaceで表現できないことが表現できる

こんにちは！atama plusのパンダ好きエンジニア@pandineerです。 今回は、2024夏版と称して、atama plus社内で行われているエンジニア達の技術交流活動である「devplus」についてご紹介します。 atama plusのエンジニアの活動を知ってもらうとともに、社内の技術交流を深めたいと思っている方に、1つのアプローチの事例紹介ができればと思います。 atama plusエンジニア達の知識交流会「devplus」 atama plusでは、毎週30分、「devplus」という名称でエンジニア達の知識交流の場を設けています。 内容は様々で、最近業務で実装したコードの話もあれば、ドメイン（教育領域）について最近調べたこと、最近読んで良かった本の紹介など、特に制限はありません。 発表形式も自由で、スライドをつくる人もいれば、簡単なドキュメントをベースに対話形式で進めたり、

こんにちは！ atama plusのDevRelチームです。 atama plusのエンジニア組織としてTech Blog強化月間を開催しており、 その一環として弊社のエンジニアたちがどんな環境で開発しているかを知ってもらうために記事を書きます！ 弊社のエンジニアチームの雰囲気やこだわりを感じてもらえると嬉しいです。 では早速いきましょう！ PC内環境 開発で利用しているPCは？ 実は弊社の創業エンジニアメンバーが、Microsoft出身ということもあってか敬虔なWindows信者だったのですが 最近Macに寝返ったため、現在は全員がMacで開発していることとなりました。 使っているシェルは？ 圧倒的にzshが多いですね！ それぞれのこだわりも見ていってみましょう。 zshユーザーのこだわりやお気に入りのplugin zsh-git-prompt入れるとgit操作事故を防げるよ！ http

こんにちは！atama plusのパンダ好きエンジニア @pandineer です。 今回は、2024夏版と称して、atama plusで取り組まれているギルド活動の最近について、ご紹介します。 atama plusのエンジニアの活動を知ってもらうとともに、組織的な課題解決のアプローチを探している方の選択肢の1つとしてもらえたら嬉しいです。 ギルドとは atama plusにおけるギルドとは、特定技術領域や、エンジニアが関係する特定テーマについて、そのテーマに興味関心のある有志がチーム横断で集まる組織体です。 ギルドの活動は目的によって様々ではありますが、Spotifyモデルにおけるギルドと近しいものになっています。 ギルドの中には、さらに分科会のような形で「パーティ」をという組織を持つギルドもあります。 ギルド発足の背景 atama plusでは、開発の規模が大きくなり複雑性も増していく

この関数に同期関数を渡した時は非同期ではなく同期的に処理を実行するよう変更したかったです。 これを実現するには、大きく分けて以下の2パターンがあると思います。 1つの関数で同期処理と非同期処理を上手く扱えるようにする 関数を同期処理版と非同期処理版の2つを作成する パターン2では、同じような関数を2つ作ることになるため、以下の問題があります。 振る舞いを変えたいときに両方に変更を入れる必要がある。どちらかに変更を入れ忘れた際バグにつながる可能性がある。 2重で実装されていることを知らない開発者がコードを追う際に認知負荷が上がる。 そのため、1つの関数で同期処理と非同期処理を切り替える方法を模索しました。 解決策: オーバーロードを使う オーバーロードを利用することで引数ごとに返り値の型を定義してやることで、やりたかったことが実現できました。 function exampleFunction

こんにちは、atama plusのDev Relチームです。 atama plusでは、Zennを公式のTechblogとして活用していくことにしました。今回は、その背景とお知らせをさせてください。 なぜTechblogを推進することにしたのか 今までの記事発信は、執筆者の発信したいというモチベーション由来の記事を除くと、正直なところ採用を主眼としていたものが多かったです。 atama plusでは今後エンジニアの成長機会を増やしていきたいと思っており、今回その一環としてTechblogとしての建付けを整理し、執筆を推進をすることに決めました。 （記事の本題とはズレますが、社内では新しくEnablingチームとDev Relチームができ、エンジニアの成長支援・文化の整備に力を注いでいます） エンジニアがTechblogを執筆をすることで ・学習した内容のより深い理解の促進 ・社内での成果・

TypeScriptを用いた開発では、その型システムを活かしてランタイムエラーを事前に防いだり、実装漏れを防いだりとコードの安全性の向上を図ることができます。 本記事では、個人的に知ったおかげでコードの安全性が増した！と感じたtipsをまとめました。 ※ なお、linterを用いたコードの安全性向上も非常に有効ですが、この記事では主にTypeScriptの型システムに焦点を当てています。 tips集 配列周りのtips まずは配列を扱う際に役立つ、tipsを紹介します。 配列からUnion型を作成する ↓のように(typeof array)[number]で配列の全要素を持つUnion型を作成できます。 const fruits = ["apple", "banana", "lemon"] as const; type Fruit = (typeof fruits)[number]; //

こんにちは、SREチームでデータエンジニアをしているkumewataです。 私はこれまでは新規プロダクト開発に携わるプロダクトエンジニアとして活動していましたが、10月からSREチームに異動しました。プロダクト開発を通じてデータの重要性を感じ、次はデータ関連の仕事をしたいと考えていました。ちょうどその時、SREチーム内でデータ基盤のサブチームが新設されると知り、手を上げて異動することができました。 現在、主にデータ基盤の構築に取り組みつつ、SREチームの活動にも参加しています。自分を一言で表すなら、「SRE見習い兼データエンジニア見習い」です。 この記事では、そんな私が感じたSREとプロダクト開発の違いについて紹介します。 違いその1：定量 vs 定性 プロダクト開発をしていた時は、定性的な側面の比重が高かったように思います。プロダクト体験を形作る初期段階では、特にユーザーの感覚や体験を重

はじめに こんにちは。atama plusという教育系スタートアップでWebエンジニアをしているsekkenです。 この記事はatama plus Advent Calendar 2023の16日目の記事です。 本記事では、これまで「自動テストを実装する方が良い」という印象しかなかった私が、 自動テストを実装する機運が高まったのをきっかけにテストファーストを意識した開発にチャレンジしたので振り返ってみます。 テストファーストな開発をやってみたいと思ったきっかけ 機運 私が入社した当初はクライアントのテストコードが不十分でした。ちょうど自動テストライブラリにいくつか触れたり、スライドや書籍を読んだりしたこともあり、私の中でテストを書くこと自体も品質・生産性の向上につながるテストファーストな開発をやってみたいという機運が高まっていました。 本番不具合発生後の振り返りで、自動テスト強化が対策の一

この記事はatama plus Advent Calendar 2023の8日目の記事です。 はじめに こんにちは。新卒2年目エンジニアのyutake27です。 今年の3月から7月にかけて、Vue 2で構築された社内ツールをReactに置き換えるプロジェクトに参加しました。これまでの業務では既に色々と開発環境が整備されているリポジトリでの開発をしており、ディレクトリ構成やCI整備など初期段階から考えるようなプロジェクトに関わるのはこれが初めての経験でした。 この経験を通じて、チーム開発では手動の繰り返し作業が発生しないよう自動化したり、方針をドキュメント化したりすることで、本質的な作業時間を増やし、チーム全体の作業の効率化を実現できることを学びました。 今回の記事では実際にプロジェクトの中で行ってみて効果的だった行動と振り返ってみると取り組むべきだったことについて共有します。少しでも参考に

こんにちは、atama plus というスタートアップで web エンジニアをしている yubon です。 atama plus Advent Calendar 2023 の 7 日目になります。 本記事では、atama plus で実際に開発・運用している React プロジェクトにおいて、機能的な凝集度を高めるために行ったディレクトリ構成の再設計について紹介します。 フロントエンドのディレクトリ構成に関する考え方や設計思想は多くの記事で紹介されていますが、「業務で開発しているプロジェクトのコードで、ペインがある状態から再設計して実際に移行した」というケーススタディ的な記事は少なそうだったので、書き残しておこうと思います。

はじめに 最近チームに React 18 を布教することの多い osuzu です。 普段の業務で、ペアプロ時に設計意図を伝えたり、コードレビューで都度自分の意図を伝えたりしてきました。 今回、これまでのチーム開発の経験やドキュメントに目を通す中で、自分が良いと考えている設計やコードレビューの観点を言語化することが出来てきたので、筆を執ってみました。 この記事はコードレビューの観点をチーム内へ知見共有するために書きましたが、社内に閉じる必要もない内容のため、Zenn でオープンに公開することにしています。 設計部分はプロジェクト（チーム）に依存していることが多く参考にしにくい部分もあるかもしれませんが、この記事がコードレビューや設計ガイドラインのような形で少しでも参考になれば幸いです。 記事の対象外 コードレビューそのものの基準や観点は取り扱いません。下記記事など適宜参考に。 Google

こんにちは！atama plus のippei & kumeです。 こちらの記事で紹介したように、assessmentチームでは「学力の測定」と「学習」の接続をスムーズにするために検証用プロダクトの開発を進めてきました。 今回はこの検証用プロダクトの技術選定についての紹介です。 技術的な背景 本プロダクトをリリースする前提として、利用者数と利用期間は限られつつも実際に高校生に利用してしてもらうため、本番クオリティの学習体験を短期間で用意する必要がありました。 その制限の下で、今回はatama plusが保有する2つの既存プロダクトの体験部分を切り出し、検証用プロダクトに埋め込むという形を取りました。この埋め込みについての詳細は別記事に任せ、今回はプロダクト全体としての技術選定について書きます。 「atama＋」：DjangoのAPI＋Angularのアプリ 「オンライン模試」：Django

こんにちは！atama plusのkumeです。 先日atama plus開発チームのnote記事「Zennのアカウントを開設しました」で紹介したように、assessmentチームでは「学力の測定」と「学習」の接続をスムーズにするための検証/開発を進めてきました。 今後、この検証用プロダクトを開発する上で取り組んだ技術的テーマについて、記事を公開予定です。 この記事では、開発したプロダクトに関する制約や背景と、公開予定のテーマについて紹介します。 今回開発したプロダクトについて atama plusのassessmentチームでは、昨年の6月から年明けにかけて「学力の測定」と「学習」の接続をスムーズにするための検証用プロダクトを開発してきました。 ユーザー募集の都合上、（8月に実装開始して）11月末の初期リリースをターゲットとする短期間での開発となりました。また、今回はプロトタイプ等ではな

障害対応訓練を通じて運用改善したはなし こんにちは、atama plusでSREをやっている石井です。 atama plusのSREチームは会社のミッションに加え、「生徒が学習に集中できるプロダクト基盤を実現する」というチームミッションを持ってます。 ミッションの実現のために高い信頼性(壊れづらい・壊れてもすぐに復旧できる)を持ち、atama plusのサービスの成長に耐える基盤作りを行っています。 今回はこの中の「壊れてもすぐに復旧できる」を実現する為の障害対応訓練についてご紹介します。 少しでもatama plusやSREに興味を持っていただけたらとてもうれしいです。 atama plusのSREがどのようなことをしているチームなのかについては、こちらのnoteをご覧ください。 【学びを止めるな】10万人以上の生徒の学習から大規模オンライン模試まで支えるチームの紹介 背景 atama