この記事は MICIN Advent Calendar 2023 の17日目の記事です。 前回は小泉さんの「エンジニアがfigmaに入門してデザインを加速させる」でした。 MICINのDTx事業部でアプリケーションエンジニアをやっている佐藤です。直近で、認知行動療法を行うアプリケーションの開発を担当していました[1]。本稿では、そのテストコードの実装の際に考えたことを書きます。 重要なケースを網羅するテストコードを書きたい 今回のアプリケーションでは、考慮すべき状態の数が多く、その状態に基づく画面表示の条件分岐も多いため、仕様を整理するだけで大変でした。これに対応するテストケースの数は当然多くなります。だからこそ、ロジックの単体テストで、重要なケースを網羅しておきたいと考えました。 以下、本記事での説明のために必要な要件などを簡単に示しておきます。 要件 アプリケーションの要件は、以下のよ

この記事は MICIN Advent Calendar 2023 の 5日目の記事です。 前回は竹内さんの、Socket.ioコンテナオーケストレーションハンズオン でした。 tblsはいいぞ🦍 筆者はtblsの大ファンであり、特にViewpoints機能が他のツールとは一線を画していると思っています。今回はその良さをお伝えできればと思います。 TL;DR tblsは実際のスキーマからDBのドキュメントを生成するツール ER図が巨大化しても、tblsのViewpointごとに分割することでDBの全体像が理解可能になる Viewpointの粒度に困ったら一旦トランザクションと集計の単位に設定する 個別のテーブルとViewpointは相互に参照できる CIに組み込むことでドキュメンテーション忘れを防げる なんのためにDBのドキュメンテーションを行うか DBのドキュメンテーションはそれなりにコ

先日ジャストシステム様主催のJustTechTalk#11で CRE について発表しました。 JustTechTalk#11 エンジニアの新しいキャリア Customer Reliability Engineer (CRE) - 株式会社ジャストシステム | Doorkeeper speakerdeck.com このエントリでは、イベントの様子や登壇の補足をします。 CREへの期待とイベントの様子 CRE ははてなさんを皮切りに、私の所属する XFLAG スタジオ、最近はメルカリさんも設立したことで注目を浴び始めています。 これまでエンジニアリングリソースは、新機能の開発やプロモーション施策といった KPI に直結する、いわば経営陣から見えやすい部分に対し集中されてきました。 CS というお客様に近い場所で長くエンジニアとして携わってきた私は、そのことにずっと疑問を抱きつつも、CS こそ今

今月15日・16日と二日間に渡って開催された、「デブサミ」こと Developers Summit 2018 にて登壇、発表をしてきました。タイトルは、「自分」をまるごと活かす！私が“CRE”というキャリアを選んだ理由 。 みなさまご静聴いただきありがとうございました！！さきほどの資料を公開しましたー！ https://t.co/ul2uQMSAFb #devsumi #devsumia— a-know | Daisuke Inoue (@a_know) 2018年2月16日 資料は以下です。 speakerdeck.com 今回の発表で「伝えたい」「これを機に改めて考えてみてほしいな」と思っていたことは、以下のようなこと。 「自分を活かす」とは言うけれど、そもそも「自分」ってどんな存在なんだろうね。考えてみよう 僕が "CRE" という仕事を選び、今もなおその仕事をしている理由は、○○だ

若手エンジニアを不幸にしないための開発の「べからず」集　組織運営編から記事を独立させました。 優秀な技術者ほど辞めてしまいやすいのは、多くの会社に共通していることです。 この文章では、どうして優秀な技術者が辞めていってしまうのか、その理由を探るとともに、そうならないようにするための対処方法を少しずつ書き足していきたいと思っています。 マネジャーのみなさんへの前書き 会社の資産であるソースコードはきちんと管理されてますか？ 「きちんと金庫にしまってある」ではありません。 開発が進みやすく、今のソースコードはどのように品質が保たれているのかがわかるようになって 管理されてますか。 ソフトウェアの開発などで生じている課題は、どのように管理されていますか。 「去年の△月ごろに問題になっていたあの件は、結局どうなったのかい。」 「担当していた○○さんがだったら知っているんですけれども、もうやめちゃい

開発チームのチームリーダーやってたときってどんなこと考えながらやってた？って相談があって、僕がチームリーダーやってたときはこういうことに気をつけてたよ。って話をした。今は僕はリーダーは後輩にまかせて、自分はシニアエンジニア的な立場でコードを書いたりウロウロしたりして楽しく過ごしてるんだけども。 4つの混ぜない やってるときは特に考えてなかったけど、今になって考えるとこういうこと気にしてたなーってのね。数は、単に4つ思い出した。ってだけ。 帽子を混ぜない エンジニア出身のチームリーダーって、こんな帽子をかぶってることが多いかな: 組織マネージャの帽子で 後輩の育成や組織としての成長を考えたり 開発リードの帽子で クオリティの最後の砦みたいな役割や、チームの外との調整をやったり プロジェクトマネージャの帽子で プロジェクトをどうやってうまく回していくかを考えたり なので「今の自分の気持ちはどの