beijaflor
こんにちは、 iCARE でフロントエンドの技術顧問をやっている大谷です これは iCARE さんをお手伝いし始めて 1年ちょっと経ったので振り返り & 最近一気に増えた新しいメンバーにこんなことやってきた人間だよ、というのを伝えるためのひとりアドベントカレンダーです
talk about design from point of view from ordinary engineer 普通のエンジニアから見たデザインについての話
iCARE の技術顧問がどんな事をやっているか - 2021アドベントカレンダー の最終日の記事は iCARE の dev ブログに投稿しました 技術顧問ひとりアドベントカレンダーを書く | 働くひとと組織の健康を創る iCARE
ある日 GitHub から怒りのメッセージが届きました 55件のセキュリティアラートがあります 前日まではなにもなかったので驚いたのですが、別に大きなセキュリティホールが発見されたわけではなく、過去の分も含めて通知されていなかった脆弱性が急に届くようになったようです。ライブラリのアップデートを怠っていたのが悪いのですが、このまま放置というわけにも行かないな、ということで一気にがっつりアップデートを行うこととにしました スケジュールを決めて告知を行うCarely は 40
考えてみたら Webpacker を本格的に触る前に CircleCI の改善とかやっているので最初から SRE っぽいことやっていますね。フロントエンドエンジニアの領域が拡大している現在、この辺りの領域には口出せて当たり前感はあるので、 iCARE でも一定以上コミットしています 障害対応フロントエンド起因の障害に関しては率先して対応しますと表明しています。特にビルドに起因するプロダクション環境でしか発生しない問題や、デプロイに起因するフロントとインフラの境目の問題などの
2021年度の前半で特に注力したのは Webpacker 離脱と CircleCI の改善でした マネージャーと課題感のすり合わせもできており、実際に傍目で見てもこの辺りに課題があるのは明白だったのでそのまま進めても良かったのですが、実際に日々の実装しているメンバーと認識がずれると良くないな、というのと、外から見ただけではわからない改善点もあるかも、ということでアンケートを行い、職種と併せて辛いことを選択式と自由記入で、また改善のアイデアも一緒に回答してもらいました 結果
これまでメインで実装していたメンバーが Engneer Manager になり、新しいメンバーがどんどん入ってくる事で、実装のスピードは進みチームでの分業もできるようになったのですが、同時にもう少しひいた目線でアプリケーションの今後を考える必要があるなという事で、 CTO, VPoE と相談してアーキテクト会を発足してもらいました 成長痛という感じだと思いますが、メンバーが日々の実務で感じながらもなかなか改善できない部分や、中期以上を目指した時にエンジニアリングの観点で考え
ある時サーバサイドのメンバーからこんな事を言われました 最近のフロントエンドの実装が高度化していてわからないんだよね・・・ ちょうど自分も Carely の構成に慣れてきたタイミングだったので、それなら、とサーバサイド向けの勉強会を開催しました。社内でコードを触っている人が対象という事で、資料はざっくりめに作って実際に手を動かしながら解説するような構成です 基礎編1 全体像を把握してコードを書けるようになる全体的な構成と Rails → 画面までの処理の流れを説明 3
定期的にペアプロを行っています。毎週定期的に時間をとって実施したり、困った事があったらつないで一緒に実施したり、ぼくも含めてメンバー全員あまりペアプロの経験はなかったのですが、繰り返し実施する事でワークするようになってきました。現在はメンバー間でも行われているようです 課題によってこんなパターンで進めています メンバーが実装、ぼくがブレーン やることはある程度明確だけど、進め方がちょっと難しかったり現在の実装が複雑だったりする時にこの方法をとります。リファクタリング（
Carely は企業労務のための SaaS で、利用するのは導入企業の「人事労務担当者」と「従業員」の方たちです。特に「従業員」に関してはすべてのユーザーがきちんと使える事が前提となっており、 i18n への対応を行っています もともとが Ruby on Rails のアプリだったため、locale の設定は i18n を使ってなされているんですが、これはフロントエンド側ではそのままでは利用する事ができません。そのため、 i18n-js を利用してフロントエンド向けの lo
Carely のバックエンドは基本 GraphQL で実装されていて、フロントエンドでは apollo-client を使ってアクセスしています。これらの仕組みはぼくの前の技術顧問でもある 翁さん が構成をしてくれていたもので現在のメンバーは詳しく仕組みを理解せずに使い方を覚えて実装している状態でした GraphQL の導入から時間もたち、利用されている箇所が増えてきたことでいくつか課題が見つかってきたので対応を行いました useQuery, useMutate の型を通
iCARE ではローカルの開発環境には Docker を活用しつつ、本番環境はコンテナを使わない ec2 インスタンスで運用しています Rails のバージョンアップに向けた作業中に、こちらの開発用 Docker イメージのビルドがされないということで調査をしました 開発環境を整備したタイミングでは Docker Hub の自動ビルドが無料プランでもできていたのが有料になってしまったのが原因だったようです。運用ルールも明確ではなかったので、有料プランへの以降とビルドルール
サービスの初期であれば localhost で開発できると思いますが、 Carely はログインして運用することが前提のサービスになっているため、 lvh.me というループバックドメイン を利用していました。そして、ついにその日がきたのです Lvh.me showing parked domain page. expired? | Hacker News ある朝の Slack で開発環境にアクセスできないという報告がエンジニアから一斉に上がりました。原因を突き止めるのに
Carely でのフロントエンドテストはかなり限定的でにしか使われていません これは feature-spec による e2e テストが充実している事と、コードの共通化がそこまでなされていないのでテストのコストが高いことが原因と思われます 現在実装されているのはこの 3種類です jest による unit テスト storyshots による dom snapshot テスト storyshots によるイメージテスト ぼく自身フロントエンドのテスト導入はコスト面
株式会社iCARE では技術系のドキュメント共有に Kibela を利用しています ドキュメントの維持はコストがかかるので最低限にしたいのですが、同時に必要なドキュメントというものもあります。開発を優先しているとドキュメンテーションはどうしても後回しになりがちです。また、質が高く劣化しにくいドキュメントを書くのにも技術が必要です お気持ちドキュメントを書く実装から少し離れた視点で長期的な方向を見るためにお気持ちを表明しています。これらは、日々の実装で厳しさの片鱗を見つけた
ぼくが関わり始めた 2020年10月ころはフロントエンドエンジニアはまだ5人程度だったのが、今では15人を超えて一気に3倍に増えました 人数が増えてきて問題になるのがコード品質のばらつきです。マネージャー陣もすべてのコードの把握はできませんし、関われる時間が限られた技術顧問ではなおさらです また、これまで実装されたコードもあまり明示的な共有はされておらず、それぞれが思い思いに共通化していたため車輪の再発明が大量に発生していました ちょうどいいタイミングということで、共通
株式会社iCARE ではデザインシステムに注力しています 詳しくは各メンバーの発表がたくさんあるのでそちらを参照していただくとして、ぼくは旗振りというかアドバイザーというか、方向の調整役というかみたいなことをやっています はじまりCarely は SaaS としての歴史も長く、色々な多くの機能が盛り込まれています。また実装時期によって、実装やデザインに統一感がないという課題がありました その中で最初に課題に上がったのはフロントエンドエンジニア側の開発のやりにくさでした。
歴史が長いアプリケーションだとどうしても npm script の中身が肥大化してしまいますよね。Carely では現在 52 個のスクリプトが登録されています ぼくが手伝い始めたタイミングはどんどんコマンドを拡張していった直後の時期でたくさんの問題が発生していました 命名に一貫性がない コマンドが多すぎてどれを使ったらいいかわからない コマンドによってコミット差分が対象なのか、全ファイルが対象なのかバラバラ 共通部分がコピペされており、修正時に複数箇所対応しないと
