フロントエンドの"ちょうどいい"自動テストのはじめかた - Atrae Tech Blog
Wevoxのフロントエンドエンジニアをしているタガミです。最近はmonorepo構成に移行中のWevoxフロントエンドのテストやデザインシステムなどをいい感じにしようとしています。 この記事では、WevoxというSaaSプロダクトのフロントエンドにおける自動テストの話をします。Wevoxはリリースから5年以上が経過し、チームのメンバーも増え、またソースコードも巨大化しています。そんな中でフロントエンドも"式年遷宮"をして、改善を繰り返しています。中にはソースコードをガラッと変えるようなリファクタもあり、担当するエンジニアにとってはデグレの心配が付き纏います。そんな日々変化するフロントエンドを支えるのが自動テストです。 Wevoxの開発チームは決して大人数ではありません。そんなチームでも品質の改善のために一歩ずつ改善しつつある経験をもとに、フロントエンドの自動テストポイントをいくつかお伝えし
Tailwind考 - uhyo/blog
皆さんこんにちは。最近とある事情でTailwind CSSにわりと真剣に向き合わないといけなくなった筆者です。 Tailwind CSSの話題は、Twitterのフロントエンド界隈では定番のトークテーマのひとつです。しかし、筆者の考えを文章にまとめたことは無かったので、このたびブログ記事にすることにしました。 結論筆者が一番みなさんに伝えたいことは、Tailwind CSSは考え無しに採用してよい技術ではなく、採用するには熟慮が必要だということです。とくに、フロントエンドのスターターキット的なプロジェクトの中にTailwind CSSが混ざっていることがありますが、あれはけっこうな罠です。気軽に採用すべきものではありません。 筆者の考えでは、Tailwind CSSの採用を考慮に入れてよいのは次の2つの場合です。 デザインにこだわりがなく、最低限整っていればいい場合。デザイナー不在のプロジ
【TypeScript 4.9 beta】satisfies に大満足
少し前に、TypeScript 4.9 betaがリリースされましたね。その中でもsatisfiesオペレータに、「おお！いいやん！」と個人的に興奮したので軽く記事にしたいと思います。 概要 一言で言うと「typoとかが嫌なので型でしばりたい が 推論は具体的なままでいてほしい」という想いを実現してくれるのがsatisfiesです。 上記のBlogも十分わかりやすいかと思いますが、本記事では、より簡素な例を用いて説明したいと思います。 以降colorsというオブジェクトを定義すると仮定して、説明を進めます...。
Rails+Next.jsでGraphQLを導入する時に考えたこと - Timee Product Team Blog
こんにちは、タイミー開発プラットフォームチームで業務委託として働いている宮城です。 タイミーはリリースから4年が経過したプロダクトで、2022年の前半から一部領域でGraphQLを利用し始め現在導入を進めています。 本記事では、GraphQLをプロダクトに導入する上で判断に迷った箇所や課題に対して、タイミーでの意思決定とその理由を紹介します。参考にしていただければ幸いです。 GraphQLの選定理由についてはこの記事では触れませんが、CTOの@kameike が以下のイベントで詳しく紹介する予定です。まだ参加申し込みは可能ですので、興味がある方はぜひ合わせてご覧ください。 timeedev.connpass.com なお、本記事のタイトルはソウゾウさんの以下の記事にインスパイアされています。 engineering.mercari.com GraphQLの「Getting Startedの
型付けを頑張る React Hook Form
はじめに React Hook Form は Controlled component と比べると利便性は高いですが、代償として型安全性をある程度放棄しています。この記事では React Hook Form を使いながらも型安全性を可能な限り高めるための解決策を紹介しています。 この記事で扱わないこと フォームライブラリを使うことの是非 React Hook Form の基本的な使い方 本題から逸れるコンポーネント設計の話 解決したいこと 次のような TextInput コンポーネント、NumberInput コンポーネントと、それらを使う Form コンポーネントについて考えます。 type TextInputProps = { name: string; }; const TextInput: React.VFC<TextInputProps> = ({ name }) => { co
JavaScriptで文字数を数えるのはそんなに簡単ではない - Qiita
はじめに JavaScriptにて文字数をカウントする方法に関する記事をいくつか目にする機会があり、今回実際に記事を参考に調べてみました。 簡単そうに見えて意外と難しいです。 String.length Googleなどで「JavaScript 文字数 カウント」とかで検索すると真っ先に出る方法です。 MDN公式ではString.lengthに関して以下のように説明されています。 length プロパティは String オブジェクトの文字列長を UTF-16 コードユニットの数で表します。 length は、 string インスタンスの読み取り専用データプロパティです。 UTF-16 コードユニット ざっくりと説明するならUnicodeで割り当てられた番号をUTF-16 という文字コード方式で割り当てられた各文字に対応するIDを指します。 難しい単語がいくつか出てきているので1つずつか
GraphQLにおけるエラーハンドリングの実践 - Gaudiy Tech Blog
こんにちは。エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyでエンジニアをしている高島（@takashima_katsu）です。 Gaudiyでは現在、BFFレイヤとしてGraphQLサーバを利用しています。導入してから1年以上が経ちますが、スキーマ駆動開発はDXの向上につながっていると実感しています。（以下のブログが詳しいです。） techblog.gaudiy.com 今回は、GraphQLの利点を活かしたエラーハンドリングの方法について、Gaudiyでの実践をもとに書いてみたいと思います。エラーハンドリングの実装について課題感のある人や、現在GraphQL Errorsを使っている人に、ぜひ読んでいただけると嬉しいです。 1. エラーハンドリングとGraphQL 2. GraphQL Errorsにおける課題 3. GraphQLエラーハンドリングの実践 3-
答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022
答えが分からないものを模索しながら作り続ける世界に我々は突入した。和田卓人氏による「組織に自動テストを根付かせる戦略」（その1）。ソフトウェア品質シンポジウム2022 9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略（2022秋版）が行われました。 講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。 本記事は、2時間におよぶこの講演をダ
組織マネジメントのあれこれ｜nishiba
トピック部下への任せ方 部下の視座の上げ方 なぜ書くのか？最近、部下と話していて言語化が進んだのでメモとして書いておく。また、いつもどおり書きなぐりの文章です。推敲などはしていません。 前置き今回あえて部下という言葉を使っています。普段は部下という言葉よりもメンバーという言葉を使います。今回は上司と部下の関係であり、上司として私が気づいたことを書くので明確に部下という言葉を使っています。 部下への任せ方仕事を任せることは非常に難しいと思っていた。しかし、難しいと感じる場面が最近減った気がする。その理由を考えたのでメモとして残す。 私は1年ほど前に今の会社に転職した。今は執行役員／VPoEを担っている。入社当初からずっとマネジャーという立場である。最初は研究開発部の副部長という立場であり、数カ月後に部長、その数カ月後にVPoE、さらに数カ月後に執行役員になった。なので、全く現場のことや配下に
再考: アプリ開発と状態遷移の管理 - ninjinkun's diary
自分が開発しているLaunchableのWebアプリがローンチされて1年半ほどになる。このWebアプリにはReduxのような状態管理ライブラリを入れないまま開発してきたのだが、今のところ困らずに開発できている。そういえば昔自分は状態管理について何か考えていたような…とブログを掘り起こしてみた。 ninjinkun.hatenablog.com このエントリは2016年にネイティブアプリを対象にして書かれているが、この後自分は2018年ごろにWebフロントエンドに軸足を移し、ネイティブアプリ開発から離れた。なのでこのエントリはWebフロントエンドエンジニアが2022年に再考した話になる。 結論としては、当時自分が管理したかった状態のほとんどは現在ApolloClientのキャッシュによって解決されている。 繰り返しになるが、自分が開発しているLaunchableのWebフロントエンドには状態
type-challengesで型パズルを解きまくってTypeScript筋を鍛える
どうも、株式会社プラハCEOの松原です この記事は「そもそもTSの型をどうやって勉強したら良いの？公式読んでも一向に覚えられないんだけど...難しいし...よく分からないから書きたくない...」とお考えの、型が嫌いな方々に向けた記事です。 type-challengesを使えば遊び感覚で練習できるよ！という楽しさを伝えつつ、最終的には「うるせぇ！！！かこう！！！（ドンッ!!!）」って方向に持ってくのが目的です（ワンピース読んでない人には意味のわからない話で申し訳ない） type-challengesとは 初級・中級・上級・鬼（意訳）に分類された様々な型パズルが用意されているので、1日1問解いていけばあら不思議、1ヶ月も経てば好きな型をささっと組み立てられるTSマッチョに。そんなTS筋を鍛えるトレーニングに最適です。 習うより慣れろ 確かにTSの公式は情報としては充実しているのですが、お世辞
A New Collaboration with Adobe | Figma Blog
There’s such an opportunity (and need!) to make design and developer tools more collaborative and accessible. When we started Figma, our stated vision was to ‘eliminate the gap between imagination and reality.’ “ There’s such an opportunity (and need!) to make design and developer tools more collaborative and accessible. When we started Figma, our stated vision was to ‘eliminate the gap between im
UXピラミッド – UXデザインの正しい評価方法 – デザイン会社 ビートラックス: ブログ
前回の「UXハニカム – UXデザインの正しい品質評価方法 –」では、サービスやプロダクトのUXデザインを評価する際に一般的に用いられている、UXハニカムを活用した方法を紹介した。加えて、実はもう一つユーザー体験のクオリティを測る方法がある。 ユーザー体験を構成する3つのポイント消費者がサービスを受けるとき、ユーザーがプロダクトを利用するときに受け取る体験の質を高めるのがUXデザイナーの仕事になる。 そして、その体験を左右するのが、1. 見た目の品質 (Look), 2. 感覚の品質 (Feel), 3. 使いやすさ (Usability) である。大きく分けてこの3つの要素のクオリティが高いほど、ユーザーに対してより優れた体験を提供することが可能になる。 実用性と利用感覚を測るUXピラミッドUXハニカムに加えて、もう一つのUXクオリティを測る手法としてUXピラミッドがある。6つの階層で構
Ubie Design Tokensを公開しました
こんにちは、Ubie株式会社でデザインエンジニアをやっているtakanoripです。 Ubieではデザインのクオリティと生産性向上のためデザイン生産基盤の整備に力を入れています。 今回その一環として開発したデザイントークンをnpmパッケージとして公開しました。（現在はColorのみ。） 開発経緯 Ubie Design Tokens開発以前からデザイントークンのようなものは存在しており、CSS Variablesとして実装されていました。しかしユースケースを想定せず作った変数があったり定義が細かすぎたりしたことで「どの変数をどういう場面で使用すれは良いかわからない」という問題が発生していました。 そこで変数の定義を見直し、より実際のデザインに即したデザイントークンを策定するとともに、プロダクトごとの実装差異をなくすためのライブラリの開発に着手しました。 Colorの定義 Ubie Desi
ReactのSuspenseを使った非同期処理のエラーハンドリング
「フロントエンドLT会 - vol.8」で発表したスライドです。 https://rakus.connpass.com/event/255095/
【freee / ICS / Ubie / RAKSUL】 デザインシステム構築の様々なアプローチ 「Design System Build #01」勉強会レポート｜RAKSUL DESIGN
【freee / ICS / Ubie / RAKSUL】 デザインシステム構築の様々なアプローチ 「Design System Build #01」勉強会レポート 近年、国内外の様々な企業のプロダクト開発に導入されている「デザインシステム」。「デザインシステム」を導入することで、デザイナーやエンジニアの開発生産性や効率性を高めたり、ユーザー体験の一貫性を提供できたりと、様々なメリットがある一方で、事業内容や成長フェーズ、組織構造などによってデザインシステムの目指すべきカタチは異なり、正解や完成がないことから、悩みを抱えている企業や開発者は少なくありません。 そこでラクスル株式会社（以下、RAKSUL）は、デザインシステムのコミュニティ「Design System Build」を立ち上げ、2022年8月23日に“デザインシステム構築の様々なアプローチ”をテーマに勉強会を開催しました。 この
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Next.js 2022年度リクルート エンジニアコース新人研修講義資料 - Speaker Deck
Design Systems For Figma
Chakra UIの歩き方 & Tips集
Chakra UIの再利用コンポーネント拡張の方法あれこれ
