私がこれまでGitの研修講師やブランチ戦略のコンサルティングをおこなってきた経験に基づいて、この記事を書きます。 Gitのワークフローについては自転車置き場の議論になりがちであまり乗り気がしないのですが、最近少し発見があったのと、実際に多くの現場で明らかにフィットしないのに git-flow を検討したり採用したりしようとして苦労をしている様を目撃することが多いので書くことにしました。 この記事で主張する内容はタイトルの通りですが、まず前提として以下を宣言しておきます: 全てのケースに100%フィットするようなワークフローは存在しない git-flowがフィットするケースも探せばあるかもしれない 例えばすでに何年もgit-flowでうまく回せてるよ、など どのようなワークフローを採用するかは最終的にはあなた（のチーム）が判断すべき さて、 git-flow は 2010年1月「A succ

play function is 何 Storybook 6.4 では、CSF 3.0 や new Story Store など、いくつかの新機能が導入されましたが、その目玉機能の 1 つが play function です。 // RegistrationForm.stories.ts|tsx import React from "react"; import { ComponentStory, ComponentMeta } from "@storybook/react"; import { screen, userEvent } from "@storybook/testing-library"; import { RegistrationForm } from "./RegistrationForm"; export default { /* 👇 The title prop i

TypeScript x React x Storybook のプロジェクトを CSF3.0 対応させようとして型問題でテンパったら読む記事TypeScriptReactstorybook はじめに 先日 Storybook 6.4 がリリースされ、CSF 3.0 がフィーチャーフラグなしで使えるようになりました。 意気揚々と移行を試みたものの、story object に適用できる型がかなり増えており、どれを使うのが正解か理解するのに時間がかかりました。 同じように悩んでいる方の助けになればと思い、備忘録として調べた内容を残しておきます。 TL;DR Storybook 6.4 であることが前提ですが、とりあえず CSF 3.0 なら ComponentStoryObj, CSF 2.0 なら ComponentStoryFn 使っておけば間違いないでしょう。 Meta と Story

はじめに 今回は有名企業の公開されているエンジニア新人研修資料をまとめました。 昨今、新人向けの研修資料を公開する企業が増えています。 またクオリティーがかなり高いものが多く、初級者~中級者でも学びがある資料となっています。 資料の作り方も勉強になるので「勉強会で登壇している人」「企業の研修担当の人」にも有益な資料になっています。 この記事の主な対象者 有名企業の研修資料を網羅的に見たい人 エンジニア初級~中級者の人 独学で学習をしている人 研修資料の作成を今後していきたい人 ミクシィ まずはじめに紹介するのは、毎年新人向けの研修資料を公開している株式会社ミクシィです。 ミクシィの研修資料で公開されている内容は、 Git研修 データベース研修 設計・テスト研修 コンテナ研修 iOSアプリ開発研修 Androidアプリ開発研修 フロントエンド研修 ゲーム開発研修 Flutter研修 AI研修

WHERE 条件のフィールドを UPDATE するのって，明示的にロックしてなくても安全？全パターン調べてみました！MySQLSQLPostgreSQLDatabaseQiitaEngineerFesta2022 TL; DR MySQL/Postgres とも， MVCC アーキテクチャの恩恵で， SELECT と UPDATE は基本的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ，排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ，これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で，更新対象をサブクエリの SELECT から自己参照している場合は例外。トランザクション分離

WHERE 条件のフィールドを UPDATE するのって，明示的にロックしてなくても安全？全パターン調べてみました！MySQLSQLPostgreSQLDatabaseQiitaEngineerFesta2022 TL; DR MySQL/Postgres とも， MVCC アーキテクチャの恩恵で， SELECT と UPDATE は基本的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ，排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ，これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で，更新対象をサブクエリの SELECT から自己参照している場合は例外。トランザクション分離

はじめに Herokuのブロク記事10 Habits of a Happy Node Hacker (2016)を、「洋の東西を問わず、みんな『10のなんとか』って好きなんだな」と思いながら眺めていたら、結構面白かったので内容をピックアップしてみます。 以前、Go言語で幸せになれる10のテクニックというのをあるブログ記事を元にして書いた時には、原題の "Ten Useful Techniques in Go"を意訳して「幸せになれる」としたのだが、今回は原題にシッカリ"Happy"が入っているというおまけ付き。 なお、「2016年版」と言っているのは2013(2014？)年版があるから。これらを読み比べてみるのもまた面白いが、とりあえず今回は最新の2016年版のご紹介。 1. 新しいプロジェクトは npm init で始めろ 新しいプロジェクトはこう始めようよ、と言っている。

個人でも業務でもすごくお世話になっている CircleCI について説明したいと思います。 設定する際の Tips など個人的な観点を元に紹介していきます！ CircleCI の構造をざっくりと理解する CircleCI で設定する .circleci/config.yml ファイルの中身の構造について理解していきます。 config.yml は大きく分けて、 version, orbs, executors, commands, jobs, workflows の6つのキーワードに分かれています。 この6つのキーワードを理解することで CircleCI がよくわからない方もざっくりと理解することができます。 version キーワードを除くその他のキーワードを見てもらうとわかりますが、基本的に ****s になっているので複数指定することができます。 では順番にそれぞれのキーワードについ

CircleCI2.0の特徴のひとつであるWorkflowを触ってみます。 workflowを設定してみる CircleCI2.0でWorkflowを設定しなかった場合、buildjobのみが走ります。 試しに以下を試してみます。 version: 2 jobs: hoge: # <-- ここ working_directory: ~/workspace docker: - image: node:9.4.0 steps: - checkout - run: name: Echo command: echo hello, world.

この記事でCloudWatch Evidentlyについて調べていると、「機能フラグ」や「A/Bテスト」などインフラエンジニアには若干聞き慣れないリリース用語が出てきました。 アジャイル開発やCI/CDの台頭に伴い多数出現したこれらのリリース戦略用語をまとめて整理してみることにします。 インフラエンジニアやSREと呼ばれるロールの方々も、リリース戦略を知っておくとCI/CD環境の構築やIaC、はたまたミドルウェアのバージョンアップなどで役立つと思います。 以下ウェブサイトを参考に、各用語を「デプロイ戦略」と「テスト戦略」の大きく2つに分けて紹介します。 デプロイ戦略 従来型のデプロイ（インプレースデプロイ） システム本番環境が一種類のみ存在し、新バージョンの資材デプロイによって旧バージョンの資材を上書いてしまうパターンです。 環境の設計や管理、維持コストをシンプルに抑えられるメリットがあり

概要 Design Documentと聞くと何を想像しますか？ 一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。 設計書、簡単に説明するのであればソフトウェアを「どうやって作るの？」を説明したドキュメントです。 Googleではソフトウェアエンジニアリング文化における重要な要素として、今回お話ししていくDesign Docsと呼ばれるものがあります。 Design Docsとは？ Design Docsとは、開発者がコーディングに着手する前にソフトウェアシステムまたはアプリケーションの開発する人が作成するドキュメントです。 => ソフトウェア設計における仕様書や設計書とは別物と捉えた方がよいです。 仕様書、設計書は作成した上でのDesign Docsの作成となるようです。 このドキュメントには、高レベルの実装戦略と主な設計の決定事項がまとめられて

[いわゆる退職エントリ] Microsoft を辞めることにしました（あるいはサポートエンジニア → Product Marketing Manager になるまでなど）退職エントリ 皆さんごきげんよう。ういこうと申します。 これまで日本マイクロソフト株式会社で Azure のフロントエンド領域を中心としたサービスの Product Marketing Manager をしておりましたが、6/30 日をもって退職することとなりました。 きっと Microsoft 界隈以外では、あなたどなた？という感じだと思いますので、少し自己紹介と、退職エントリ（のようなもの）を書くことにした理由を紹介させてください。ちょっと、いや...かな～り長いので、おやつでも食べながら読むものがないなーというときや、今エンジニアなんだけど、マーケティングなど、テクニカル ロール外の職種に転換しようと思ってる、あるい

先日とあるイベントでこちらの内容の発表をさせていただきました。 その中でNxに関して触れた際に(77ページあたり)、もう少し掘り下げて聞いてみたいという声を多方からいただきまして、私がNxを推す理由を記事にしてみることにしました。 Nxとはなんぞや Nxはひととでいうと、「モノレポ管理ツール」の一種です。 マイクロサービスやマイクロフロントエンドでサービスを構築する場合に、複数のサービス・プロジェクトを運用する必要がありますが、そのプロジェクトを別々のリポジトリで運用するのではなく、一つのリポジトリでモノリシックに扱うことで、依存関係の解決などの管理をしやすくするためのツールです。 中でもNxはJavascript/Node/Typescriptに特化しているため、フロントエンドやBFF開発での文脈でよく登場します。 他のモノレポ管理ツールとの違い Nxの比較対象としてLernaがよくあが

「経年劣化に耐えるコード」というのは、だれもが目指すものでしょう。「そもそもフロントエンドのコードは、今ある技術で最良のものを書き捨てるべき」という意見も理解できますが「備えあれば憂いなし」ということもありますので、ここにメモを残します。あくまで、私なりのベストプラクティスですのでご了承ください。 5層に別れた SFC 私はレイヤーによる技術の分離で、ReactComponent の経年劣化に備えています。ここでいうSFCとは「Stateless Functional Component」の略称ではありません。Vue.js の文脈にある「Single File Component」を指します。 // (1) import層 import React from 'react' import styled from 'styled-components' // (2) Types層 type

はじめに この記事は、Vue.js Amsterdam 2020にてThorsten Lünborg氏の行った講演「Composition API Best Practices」の抄訳（直訳ではない要約しながらの翻訳）です。 ついつい無秩序になりがちなsetup()内の治安をどう守るかについてチームメンバーと考える中で、参考になりそうなこちらの講演の内容を共有するために翻訳しました。 もし翻訳に不正確な部分があれば指摘していただけると幸いです。 翻訳元動画はこちら👇 Vue.js Amsterdamとは 年に一度開催されるVueコミュニティにおける世界最大のカンファレンス。 https://www.vuejs.amsterdam/ 「Composition API Best Practices」抄訳 ref() vs. reactive() ref()とreactive()、どちらを使う

Vue3 Composition APIにおいて、Providerパターン(provide/inject)の使い方と、なぜ重要なのか、理解する。JavaScriptTypeScript設計Vue.jsNuxt はじめに Composition APIで、Providerパターン(provide/inject)が、なぜ重要なのでしょうか。 Composition APIを使えば「状態やロジック」を簡単にコンポーネントの外に切り出すことができます。 しかしながら、Composition APIだけでは「ロジックや状態は切り出せても、複数コンポーネント間で共有できない」からです。 Composition APIによって、荷物をダンボールに梱包はできても、運ぶ人がいない状態です。 みなさんは、VueのProviderパターン(provide/inject)って使ったことありますか? https:/

Vue Composition API を使ったストアパターンと TypeScript の組み合わせはどのくらいスケールするか？TypeScriptVue.jsvue-composition-api Vue.js の公式ドキュメントには「状態管理」という章があり、そこでは単純なストアパターンと、より大規模向けという Vuex ライブラリを使う 2 つの手法が紹介されています。 ですが、それぞれどこに長所・短所がありどのような基準で選択すれば良いのかは「大規模」というあやふやな基準でしか示されていません。実際その境界はどこにあるのでしょうか？ さて、TypeScript も同様に大規模アプリケーション向けと言われます。型安全性の有用さは他言語の世界で実証されています。ところが残念なことに Vuex の API 設計とは極めて相性が悪いというのはよく言われます。現時点で両者を両立させるのは大変

ここ数年の流れについて 技術的側面 Webフロントエンド（ほぼTypeScript＆React界隈）において、オブジェクト指向（厳密に言うとクラスの利用）から脱却する流れがあります。原因は以下の2点。 クラスの継承の問題点が（IT業界全体に）広く定着したこと JS/TSの進化、Reactの進化、関数型言語の考え方などの影響により、クラスを用いてデータと関数群を紐づけるメリットが薄くなったこと 現状、設計レベル（実務的にはどの関数を纏めてモジュール化するのか、モジュール同士をどう繋ぎ合わせるのか、フォルダ割りどうするのか等）のノウハウがまだ固まっておらず、既存の設計論はそれなりに有効です。 コミュニティ的側面（政治） これらの流れはWebフロントエンドの中でもTypeScript＆Reactの界隈が主導しており、そのノウハウは長年絶対視されてきたオブジェクト指向を解体するような内容であったた

概要 内容に応じてサイズが可変する textarea を、できるだけ手間をかけず、スマートな実装を試みます。 しかも、ネイティブのフォームが持っている利点をそのまま活かして、堅牢でアクセシブルな設計を目指します。 標準 textarea の難点 HTML の textarea 要素は基本的に高さが固定されていて使い勝手が悪いです。３行分くらいしか領域がなくて、長い文章を打つのがとにかく苦痛なんていうこともザラです。 最近のブラウザ実装では、多少気を利かせてくれているのか、テキストエリアの領域をドラッグで拡大・縮小できます。 ただ私は思うのです。めんどくさいし、最初っから、入力するテキスト量に応じて自動的に伸び縮みしてくれればいいのに……と。スクロールバーなんて、１ページにひとつあればじゅうぶんなんですよ。 実装方法 難しいことはありませんが、HTML と CSS、JS が協調して動作します

JavaScriptには、import * as という構文があります。これは、インポート先のモジュールの中身全部をオブジェクト（モジュール名前空間オブジェクト）として取得できる構文です。 import * as mod from "./some-module"; console.log(mod.foo, mod.bar); たまに、「この構文を使うとTree Shakingが効かなくなる」といった説明が見られることがありますが、必ずしもそうではありません。そこで、この記事ではimport * as構文とパフォーマンス最適化に関連する正しい知識と、その背景をご紹介します。 webpackで検証してみよう Tree shakingを行うのはモジュールバンドラであることが知られています。そこで、webpackを使って色々と構文を検証してみましょう。今回は次のような設定を用います。これは最適化を