サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Nintendo Direct
aloerina01.github.io
これまでエンジニアやスクラムマスターとしてスクラムチームに関わって来ましたが、その過程で何度も「相対見積もり」や「ストーリーポイント」に纏わる悩みにぶち当たってきました。工数や期間での見積もりに慣れていた私にとって、それらは理解も実践もしにくい手強いものでした。 今回は、私が実際に直面した問題と、それらを打破するためチームで取り組んできたことを思い返してみようと思います。 壁1. 「相対見積もり」の考え方を理解できない 壁2. ストーリーポイントが「何を見積もる手段か」を理解していない 壁3. 見積もりをコミットメントと捉えてしまう まとめ 壁1. 「相対見積もり」の考え方を理解できない バックログ上に積まれたユーザーストーリーやエピックを見積もろうとしたとき、私たちは真っ先に「こんなコンポーネントを新規実装するだろう、おそらく2日くらい掛かる」「あの既存機能をいじる必要があるが、複雑な箇
期待値を言語化する、期待値を伝える、期待値をすり合わせる。 チームをマネジメントしたりサポートしたりすると、こういった期待値の調整をする場面はよくありますよね。 今回は期待される側ではなく期待する側に注目して、「何を期待しているか」「どのように期待を伝えているか」について考えてみようと思います。私がチームマネジメントやスクラムマスターをしていてよく陥る失敗を思い返しながら、自分への注意喚起を兼ねて整理してみます。 何に期待するか 私は期待の種類を4つのレイヤに分類して捉えています。 状態への期待 ひとつひとつの出来事・仕事・タスクについてではなく、それらを繰り返しどういう状態を維持してほしいと思っているかを指します。「案件の優先順位に沿ってうまく計画立てて進行している状態を維持してほしい(ときには失敗することもあるだろうが、その改善も含めて停滞せず前進し続けていればよい)」といったものです
Vue + Vuexを使ったWebアプリケーションを開発していて、以下のような悩みにぶち当たったことありませんか? 悩み1. VuexのmapHelperを使うとコードが読みにくくなる 「created内で呼ばれているこの関数はどこに定義されているんだ…? methods? それともStoreのアクション…?」 「import部分を見るにこのComponentはどのStoreにも依存してなさそうだ…。と思いきや、mapStateでいろんなStoreの値を読み込んでいるぞ…」 悩み2. ビジネスロジック層がない 「ページ読み込み時に走るAPIアクセスはどこに実装されている? Componentのcreated? Storeのアクション? ロジックがまとまっている層がなくて処理の入り口を見つけにくい…」 「クリックされたら見た目を変えてAPIアクセスしてStoreを更新する実装をしたいけど、ど
私の関わるいくつかのチームではよくふりかえりをします。ScrumチームがSprint毎に行う「Sprint Retrospective」であったり、フロントエンドエンジニアのチームが隔週で行う「カイゼンミーティング」であったり、呼び名や頻度や内容は様々ですが、定期的に自分たちの行動を思い返し何らかの学びを得る活動をしています。 今回は、これらのふりかえりを私がどのように設計しているかについて、ふりかえってみようと思います。せっかくなのでテンプレートという形で書き出してみます。 ちなみにこの記事では「過去のある期間を振り返って気づきや学びを得て、今後の行動に反映する一連の活動」を ふりかえり と呼び、ふりかえりの一貫として開催されるミーティングを ふりかえりミーティング と呼び分けることとします。 ふりかえりの大枠をデザインする ふりかえりの目的 ふりかえり目的の達成基準 条件・制約 個別の
このブログのCIをCircleCIからGitHub Actionsに移行しましたので、備忘のために作業時のメモを(補足を添えて)公開します。 動機 GitHub ActionsをCIとして業務利用できるかどうか体感で確認したかったためです。 要件 developmentブランチへのpushをトリガーにRaketaskを実行し、jekyllによって静的サイトを生成する 生成された静的サイトをmasterブランチへpushする 直近のビルド成功時のCommitと比較し、/_posts/以下に差分がある場合はindexを生成しAlgoliaサーバにアップする やったこと /.github/workflowsディレクトリを作成する(命名固定) ディレクトリ以下にGithub Actionsのconfigファイルを作成する(命名は自由なのでdeploy.ymlとする) deploy.ymlにCirc
先日「React v16.6.0: lazy, memo and contextType」にていくつかの新機能が発表されました。この中のReact.memoが個人的に嬉しい機能だったので、軽く調べてみました。 React.memoとは何か Class components can bail out from rendering when their input props are the same using PureComponent or shouldComponentUpdate. ReactではComponentの再レンダリング回数を最小限にしパフォーマンスを上げる方法として、shouldComponentUpdateやPure Componentがあります。ですがFunctional Componentを使う場合はこの仕組みを利用できませんでした。これを可能にしてくれるのがRea
私は現在、フロントエンドエンジニア5人のチームのマネージャーと、職種混合8人チームのスクラムマスターを担当しています。どちらの役割においても、チームがより自律的で効果的になることを意識して関わっています。 ところで、心配性な私はチームが将来出くわすであろう失敗やトラブルを予測して先回りで対策しようとする傾向にありました。 この案件は〇〇さんが担当したら苦戦するかもしれないから、△△さんにヘルプはいる準備をしておいてもらおう ふりかえりの開催は面倒臭がられるだろうから、自分が開催する役目をしよう この人とあの人は相性が悪くて上手く進捗しないだろうから、別々のチームにしよう 実例ではないのですが、例えばこんな感じです。 こういったリスクヘッジや環境整備などは、本の言葉を借りるなら「未来や人間関係の不確実性を減らすこと」と言えそうで、マネージャーの仕事であるように感じていました。 一方で、その不
Vue + Vuexで中〜大規模なアプリケーションの開発をするとき、どんな設計にするか未だによく悩みます。試してみては捨ててを繰り返していて、そろそろ自分の中でベターなパターンを固めたいと思いつつも固まらず、気づけば数年経ちました。 そういった前提を踏まえつつではありますが、現時点で設計時に意識していることをTips的に少しずつまとめてみようと思います。今回はVuexのGetterに関するお話です。 Getterの役割を見直す 副作用のないクエリとして実装する プロパティアクセスとメソッドアクセスを区別して命名する プリミティブでシンプルなクエリとして実装する 表示用の加工処理はComponentに実装する 例外1. 加工された値の賞味期限が長い場合 例外2. 加工処理が複数Componentで繰り返される場合 おわりに Getterの役割を見直す VuexはFluxアーキテクチャを参考に
先日モブプロMeetupが開催されました。モブプロに関する知見や悩みが共有されて、モブプロの楽しさや難しさを再認識できる良い時間でした。 ところで、このイベントでは参加者から質問を集める機会があったのですが、どれも身近に感じる質問だったので、自分の思考整理のために私の目線で答えて見ようと思います。現場の実例共有も兼ねて。 有識者が参加していない場合、コードレビューをどうしていますか? 参加者に合わせてモブプロのゴールを調整しています。 私のチームのモブプロでは有識者が参加しているケースが多いので、「GitHub上でのコードレビューなく即Mergeできる状態」を目指すことが多いです。とはいえ欠席が重なり有識者がいない場合もあるので、その際は「参加者の中では合意の取れた状態」を目指し、あとで有識者にレビューしてもらったりしています。急ぎでない場合は別の案件に取り組む、できる部分だけやる、といっ
Babel7.4.0 から、長いことお世話になってきた @babel/polyfill が非推奨となりました。加えて、@babel/preset-env と @babel/ransform-runtime が core-js@3 に対応したようです🎉 これらに伴いpolyfill周りの設定方法が変わったので、その内容をメモしておこうと思います。 Babel と core-js の関係のおさらい これからのpolyfill設定方法 1. preset-env と useBuiltIns:usage で必要なpolyfillだけ読み込む方法 2. preset-env と useBuiltIns:entry で全polyfillを読み込む方法 3. transform-runtime を使う方法 Proposal の使い方 参考 Babel と core-js の関係のおさらい Babelが
algoliaとは Products to accelerate search and discovery experiences across any device and platform. algoliaとは全文検索エンジンサービスです。「algoliaサーバにブログやドキュメントなどのコンテンツデータをアップすると、そのデータを全文検索するAPIを利用できる」といった感じのものです。 例を挙げると、Vue, React, Webpack, babel などの公式ドキュメントにある検索機能が、algoliaのDocSearchという機能によって実現されています。 今回は、このalgoliaを使ってブログに全文検索を実装した方法をまとめてみます。 手順 algoliaのフリーアカウントを取得する jekyll-algoliaを使い、ブログコンテンツをalgoliaサーバにアップする a
チーム目標を設定するフレームワークをつくったので紹介したい チームメンバーがチーム目標に向かって適切に行動を起こすためには、適切な解像度の目標を定義する必要があります。マネージャーがチームの目標を決める際や、スクラムチームメンバーが議論してチーム目標を決める際に活用できるフレームワークを考えてみたのでご参考にどうぞ。
主業務で関わっているプロダクトにおいて、2018年中頃あたりからフロントエンドのテックリードを担当していました。今はチームマネジメントに重きを置きつつ、次のテックリードにバトン渡しをしている段階です。 テックリードになる前後でどんなことを考えていたのか、どんなことをしていたのかをふと振り返ってみたのでメモを残します。 環境・前提条件 プロダクトについて 5年以上続いているプロダクト フロントエンドエンジニアが触るリポジトリが4つ bundleされるjsが複数あり、フレームワークや設計が全部違う Vue・React・内製フレームワークを利用 プロジェクトについて プロジェクトメンバー増加中(40〜50人) 伴って、調整ごとが多い(仕様、スコープ、スケジュール等) 伴って、開発フロー等の見直しが必要な状況 プランニング→デザイン→サーバ開発→フロント開発→QA→リリース というウォーターフォー
React+Fluxアプリケーションのメンテをしている中で「propsのバケツリレーを減らすためにContainerを増やしてもよいか?」というディスカッションになったので、考察をまとめてみます。 いまの設計の確認 FluxUtilsフレームワークを利用している 複数のStoreを持つ ComponentTreeのRootをContainerとし、StoreのStateを受け取る Tree状に配置された各Componentにはprops経由で状態を受け渡す 各Componentはローカルステートを持つことができる ちなみに、ここで言うFluxの定義については「React+Fluxで正しく設計するためのFlux見直しガイド」にてまとめています。 propsのバケツリレーと単一Containerとは? Reactアプリケーションでしばしばある「ComponentTreeのRootでアプリケーシ
私のチームは週の数時間をモブプログラミングに割り当てています。楽しみながら開発でき、しかも開発フローにまつわる悩みが解消されてとても良い感じです。 ただ、始めから上手くできたわけではなくて悩みもいろいろありました。その解決の糸口となったのが「モブプログラミング・ベストプラクティス」でした。 そこで今回はこの本の内容と感想、そして体験談をまとめつつ、モブプロを始めてみようと思う人・始めてみたばかりの人にモブプロの魅力を伝えてみようと思います! レッツモビング! モブまたはモブプログラミングとは? なぜモブプロをするの? リソース効率とフロー効率の違い フロー効率を良くしていくためのモブとは モブプロの始め方 モブプロの準備 モブプロの登場人物と役割 モブプロの進行 モブプロの心がけ モブプロの成果の測り方 よくある悩み エキスパートがいる場合にうまく進行するには? 新人や知識のない人がいる場
シェルスクリプトはWebアプリケーションの開発において必須スキルというわけではないのかもしれませんが、ビルドやデプロイのスクリプトを書くときに結構役立ったりします。ただ、たまにしか書かないこともありなかなか入門レベルから上達せず、適切なスクリプトが書けているか不安になることがあります。 そんなときに頼りにしているのがGoogle製のShell Style Guide(以下「ガイド」)です。とりあえず最低限のお作法としてこれに従いつつ、要所要所をアレンジして使っています。 今回は中でも特に気をつけている部分をピックアップしてチェック表代わりにしてみようと思います。 どのshellを使うか いつshellを使うか 拡張子 エラーメッセージ フォーマット 変数展開 コマンド置換 test, [, [[ empty check ファイル名のワイルドカード whileとパイプライン 命名規則 関数
VueComponent間で再利用可能な部品を実装するための機能がmixinです。mixinを使った共通化の例はよく見かけますし、私もしばしばやってきました。ただ、どうも自分の実装方法だと後々不便になったり見通しが悪かったりと、使い勝手の悪いものになってしまうことが多かったです。 そこで今回は自分の過去の実装例を見返しながら、なぜ失敗したのか、mixinをどうを使うべきかについて、現時点の考えをまとめてみます。 この記事で紹介する失敗例は、私が携わったプロダクト開発においてデメリットの方が大きかった実装例です。 便宜上「アンチパターン」「失敗例」といった表現をしていますが、あくまで個人的にやりたくないパターン程度の意味合いです。 失敗例1. Template Methodパターンを意識したmixin 暗黙的挙動の危うさ OverrideではなくMergeしているだけ Classの継承とmi
ES2015+で実装するためにBabelのpolyfillを利用する場面は多いと思いますが、Babel6.xまでと7.xではその導入方法が変わっているので注意が必要です。今回はBabel7.xでの用途別polyfillの設定方法と、キモとなるuseBuiltInsオプションの挙動についてまとめてみます(執筆時点でのBabelのバージョンは7.1.0です)。 なお、6.xまでの設定方法は「Babelの設定を見直すための逆引きガイド」にまとめてあります。polyfillのことだけでなく、Babelとは何か、どのように利用するのか、といったことも併せてまとめてありますので良ければご参考にどうぞ。 2019/06/21 追記 Babel7.4.0から @babel/polyfill が非推奨となっています。変更点や新しい設定方法は「Babel7.4で非推奨になったbabel/polyfillの代替
Vue.nextTickとは? callbackを延期し、DOMの更新サイクル後に実行します。DOM更新を待ち受けるために、いくつかのデータを変更した直後に使用してください。 VueはDOMを非同期に更新するため、「DOMを更新した後にその更新済みのDOMに対して何らかの処理をする」といったような場面でnextTickが役立ちます。 // single file component <template> <div>{{ message }}</div> </template> <script> export default { data() { return { message: 'default' } }, mounted() { this.message = 'hello'; console.log(this.$el.textContent); // default この時点ではまだD
Reactの良さを活かしやすいFluxは、Webアプリケーションの設計手法としてずいぶん馴染みのあるものになったように感じます。私もFluxを取り入れた開発を2年近く経験し、知見も溜まり、使い慣れたような気持ちでいました。 が、使い始めた頃はもちろん、今でも何となく分かったつもりでいる部分があったり、複雑な実装が必要な場面で悩むことがあったりします。「Fluxはダメだ!うまく実現できない!」と投げ出したくなるときもありますが、そんなときこそ基礎へ立ち返る機会。 そんなわけでFluxに再入門し、Fluxとは何なのか、どう実装するのが適切なのかを公式ドキュメントに則って整理してみようと思います。 Fluxとは Dispatcher 要件1 イベントが発生したらすべてのCallbackを実行すること 要件2 Callbackの実行順序を制御できること Action Actionに必要なたった2つ
JSに似て読み書きしやすいシンタックスに加え、型推論やジェネリクスなど魅力的な機能を備えたDart。JavaScriptに変換する仕組みがある点や、iOS、Android、Webの3大Clientで使える言語を目指して設計されている点を踏まえると、DartでのWebフロントエンド開発も夢ではないように感じます。 ただ、言語がよければすぐに使えるというわけではなく、使いやすさや開発環境も大切な要素の1つです。 昨今のWebフロントエンドはできることが増え、それに伴いエコシステムもとても進歩していて、複雑で大規模な開発でもスムーズに行えるようになってきている印象です(1番最初の環境構築が大変とよく言われますが、その大変さも徐々に緩和されてきていると思います)。 そこで、DartでのWebフロントエンド開発がどの程度現実的なのかを「エコシステム」という観点でまとめてみました。各々のツールの簡単な
Flutterとは、Dartという言語でモバイルアプリを開発するためのSDKです。iOSアプリとAndroidアプリを同じコードベースで実装できるとのことで、普段はWebアプリを開発している私にもとっつきやすそうなので入門してみました。 一通り入門が済んだので、どうやって入門したか、入門してみてどうだったか、Webエンジニアの視点でFlutter・Dartに期待することなどをまとめました。 基礎知識 Dartとは Flutterとは 入門の仕方 概要 ハンズオン Dart SDKのインストール Flutterのインストール VSCodeプラグインのインストール Android端末(検証端末)の接続、そしてDeploy 入門してみてどうだったか Dart言語について 開発環境について Flutterについて おすすめの読み物 おわりに 基礎知識 Dartとは Googleが開発している言語
はじめに VueをつかってWebアプリケーションを実装するとき、Componentをどう切るかって誰でも一度は悩みますよね(悩みますよね?)。とりあえず思いつくままに切ってみたり、繰り返し使いそうなもので切ってみたり、CSSのスコープで切ってみたり…。いろいろな切り口があると思います。 この「いろいろな切り口」でコンポーネントを切ることができる点が、コンポーネント設計を難しくしている所以だと考えています。 そこで今回は、どのような切り口・観点でコンポーネントを切ればよいのか、そのときに気をつけるべきことは何か、といったComponentの設計方法についてまとめてみます。 すべての実用ケースを想定できているわけではないと思いますが、大小いくつかのWebアプリを開発する際に利用してみて今のところいい感じに運用できている方法です(というか自然と収束して出来上がった考え方という感じです)。 はじめ
Babelって結局なんなんだ 定義 構成要素 babel-core babel-polyfill Plugins 最新の記法でJSを書くにはどうしたらいいんだ 最低限の設定方法 1. Installする 2. .babelrcに設定を書く 3. polyfillをrequireする 4. Babeる(Babelでコンパイルする) Webpackと組み合わせた実践例 キホンのキ polyfillの機能を制限なく使いたい、でも無駄なものは入れたくない 「二重読み込み制約」のリスクを背負わずにpolyfillを使いたい グローバルを汚染せずにpolyfillを使いたい、複数ファイルでpolyfillを使いたい 早見表 細かい機能を上手く使いこなしたい 設定はショートハンドで書けるよ babel-preset-esXXXX はいくつを使えばいいんだ ES2015+のソースをそのままminifyでき
throttleとdebounceといきなり言われてピンとくる人もそうでない人も、ここらでおさらいしませんか? という回です。これらが何なのか、どう使うのか、どう実装するのかを今一度確認していきましょう。 なぜ今更こんなことをするのかというと、自分が先日忘れていたからです😳 ナニコレ throttleとdebounceとは、簡単に言うと間引き処理の一種です。連続して大量に繰り返される処理を間引いて負荷を軽減させたりするときに使います。 throttle 連続して大量に繰り返される処理を一定感覚で間引くものです。 よく使われるのはscrollイベントです。スクロールイベントをすべてハンドリングすると処理回数が多くなり、場合によってはスクロールがもっさりしてしまいますよね。それを防ぎます。 debounce 連続して大量に繰り返される処理が指定時間内に何度発生しても最後の1回だけ実行するもの
先日CORS(Cross-Origin Resource Sharing)でハマったので、今更だけど復習。Same Origin Policy(同一オリジンポリシー)について基本的なところから調べ直しました。 オリジンとは オリジン = スキーム、ホスト、ポートの組み合わせ (※スキームによって微妙に違うこともある) http://www.exsample.com:80/index.htmlのURLを例にすると スキーム = http:// ホスト = www.exsample.com ポート = 80 (ポート番号「80」は省略可なので普段見かけることは少ない) 同一オリジンポリシーとは TL;DR セキュリティを守るための重要な仕組み あるページを開いたときに、関連するリソース(JavaScript等)を同じオリジンからしか取得しない そうしないと個人情報の保護も外部からの攻撃にもガバ
背景 document.writeを使ってる外部ライブラリを動的読込する必要があった そのライブラリが読み込まれた後にしなければならない処理がある document.writeは使うなってあれほど言ってるのに!! それでもそんなライブラリ(内製だった…)を使わなければならない場面もあります。しかも<script src="..."></script>で読み込めず、動的読込(※)しなきゃいけない場面もあります。それが人生です。 ※動的読込の例 <script> if (conditions) { var scriptElement = document.createElement('script'); scriptElement.src = '//cdn.hoge.com/library.js'; var headElement = document.getElementsByTagName
まえがき ここ最近、Vueを使って実装されたWebアプリが随分と増えてきたように感じます。自分も何度となく実装してきました。すごく小さなデモを作るときにも使えるし、中規模以上のWebアプリを作るときにも使えるし、扱いやすいライブラリでとても好きです。 ある程度の規模になってくると「複数の画面でデータを共有したい」「こっちのComponentの状態をあっちのComponentに伝えたい」といったような問題にぶち当たり、アーキテクチャを導入することでそれらを解決するというのもお馴染みな感じです。特にVueでは双方向データバインディングの特性上、MVVMアーキテクチャが使われることが多いと思います。 今回は、VueでMVVMを実現する際に起き得る設計上の問題について、現時点での私の解決方針をまとめてみました😌 まえがき Vue+MVVMとはどんなものか 一般的なMVVMを理解する View V
Webのパフォーマンスを改善するテクニックとしてよく使われるlazyloadですが、一口にlazyloadといっても、その仕組みを解剖すると種類や実装方法は様々でした。今回はlazyloadを広義の『遅延読込』と捉えいくつかの視点から分類してまとめ、仕様に応じた実装方法について紹介します。 と言っても一般論ではなくあくまで持論なので、そこはご容赦ください🙆 (タイトルも盛りましたがご容赦ください🙅) lazyloadの対象 lazyloadのトリガー loadイベントのObserver 1. LazyloadComponent各々がScrollViewのスクロールイベントを監視する 2. ScrollViewが自身のスクロールイベントを監視する 3. 第三者(LazyLoadHandler等)がScrollViewのスクロールイベントを監視する LazyloadComponentの形式
次のページ
このページを最初にブックマークしてみませんか?
『mille-feuille code』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く