Four Keysがなぜ重要なのか - 開発チームのパフォーマンスを改善する方法について - yigarashiのブログ
ソフトウェアエンジニアとして働き始めて以来、ずっとソフトウェアデリバリーのパフォーマンスに興味を持って、さまざまな改善活動をしてきた。当初はスクラムを中心としたプロセスの改善に注力したが、最近はチームの成熟に伴って技術的なプラクティスに興味が移りつつある。より広い視点からデリバリーについて考えるのは非常に楽しい仕事だ。 デリバリーのパフォーマンスを改善していくには、定量指標として確立されたFour Keysを計測し改善するのが業界標準となりつつある。恥ずかしながら、私はこれまでこのFour Keysが腹落ちせず、積極的に計測してこなかった。しかし、多方面に興味が向いて知識や経験が蓄積するにつれて、猛烈にFour Keysの重要性が腹落ちしてきた。この記事では、現時点における自分のFour Keysに関する理解と解釈を整理してみようと思う。 Four Keysとは Four Keysの妥当性
技術的負債じゃなく、もはや技術的不良債権
何番煎じか分かりませんがバズワードについて怪文書を書きます。 自分の思考の整理でしかありません （技術的）負債の誤用 技術的負債という言葉を多くの日本人はまちがって使っているらしい（要出典）。 本来的な意味はこちらであった https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor 自分なりに解釈すると。 簡単に言えば、元々の意味は、場当たり的なコードのことではなく不完全なものをインクリメンタルにブラッシュアップして開発すること。 その不完全さを一時的に許容することを負債と呼んでいた。返済も必要だとのこと。 なるほど、負債ってそういうものか。技術的負債に関して、元々の会計上の負債という考え方に沿って元銀行員の方が考えたのが面白かった。 https://zenn.dev/ikeo/articles/33e3e6a0905577
Web フロントエンドにおけるコロケーション (co-location) という考え方について - mizdra's blog
Webフロントエンド界隈の文献などにあたっていると、「コロケーション (co-location)」という考え方が時々登場します。 コロケーションを簡単に説明すると、関連するリソース同士を近くに置いておく、という考え方です。 FooComponent.tsx と同じディレクトリに FooComponent.test.tsx を置く GraphQL fragment は、クエリを発行するコンポーネントファイル (pages/user.tsx) ではなく、fragment を利用するコンポーネントファイル (components/UserInfo.tsx) の中で定義する pages/user.tsx からはサブコンポーネントのファイルで定義されている fragment を import してきて、クエリを組み立てて発行する API ドキュメントは API.md に書くのではなく、コードの中にド
npm-scripts を書く時の手癖 - mizdra's blog
かれこれ 5 年くらい趣味開発で npm-scripts を書き続けている。長年書き続けているとノウハウが蓄積されてきて、「こう書くとスッキリする」「迷いがなくなる」「後から拡張したくなった時に、簡単に拡張できる」みたいな書き方が身についてきた。自分の型、あるいは手癖のようなものだと思う。 せっかくなので、id:mizdra の今の npm-scripts を書く時の手癖を書き連ねてみる。 基本形 { "scripts": { "build": "webpack --mode production", "dev": "webpack-dev-server --mode development", "lint": "eslint .", "test": "jest" } } 一番シンプルな npm-scripts を書く時のパターン。以下の 4 つの script を登録している。 buil
あなたはDRY原則を誤認している？ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? DRY原則。 WebフレームワークRuby on Railsが基本理念のひとつとして採用している有名なソフトウェア開発原則です。素晴らしい原則なのですが、最近Railsを始めた人や新卒のエンジニアさんなど、DRY原則を誤認してしまう人が非常に多い為、DRY原則に関する説明をQiitaにまとめておくことにします。 よくある間違った認識 DRY原則を誤認しているとはどういうことなのか？最も多いのが「DRYとはコードを重複させないという意味である」と認識しているケースです。当然、コードを重複させないという部分もDRYの一部ではあるのですが、こ
MediaPipe Solutions guide | Google AI Edge | Google AI for Developers
Get started You can get started with MediaPipe Solutions by selecting any of the tasks listed in the left navigation tree, including vision, text, and audio tasks. If you need help setting up a development environment for use with MediaPipe Tasks, check out the setup guides for Android, web apps, and Python. Legacy solutions We have ended support for the MediaPipe Legacy Solutions listed below as
Conventional Commits
Conventional Commits 人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様 Conventional Commits 1.0.0 概要 Conventional Commits の仕様はコミットメッセージのための軽量の規約です。 明示的なコミット履歴を作成するための簡単なルールを提供します。この規則に従うことで自動化ツールの導入を簡単にします。 コミットメッセージで機能追加・修正・破壊的変更などを説明することで、この規約は SemVer と協調動作します。 コミットメッセージは次のような形にする必要があります: 原文： <type>[optional scope]: <description> [optional body] [optional footer(s)] 訳： <型>[任意 スコープ]: <タイトル> [任意 本文] [任意 フッター] あな
Next.js + NestJS + GraphQLで変化に追従するフロントエンドへ 〜 ショッピングクーポンの事例紹介
今回は、fragmentを活用するためにパターンCを採用しており、厳密には、以下のように方針を定めています。 SSR時のクエリ発行: ページコンポーネント単位 CSR時のクエリ発行: CSRが必要なコンポーネント単位 この際、取得したqueryの結果をどのようにfragmentへ変換するかというのがポイントです。 そこで、graphql-anywhereの filter メソッドを用いることで、クエリ結果をfragmentへ変換します。 以下は、簡略化されたクーポンページの実装例です。 type DetailPageProps = { // GraphQLクエリの結果 data: Query } const DetailPage: FunctionComponent<DetailPageProps> = ({ data }) => { // couponはGraphQLのCouponスキー
How I/we got 2k stars - ゆーすけべー日記
Honoという僕が作っているWebフレームワークのGitHubスター数が2,000に迫ってきた。これまで作ってきたOSSのソフトウェアでは最高で revealgo の221、次点で gh-markdown-preview の134だ。それが一気に2,000である。 もちろん、スターの数がソフトウェアの良し悪しを決めるものではない。 それに2,000はとりわけ多いわけではない。 でも、以前の自分には遥か彼方に見えていた数を獲得できたのは、とても嬉しいことだ。 去年12月から作り始めて9ヶ月間、552コミット。 今や使ってくれる人も増えた。 cdnjs のAPI Serverのバックエンドにも使われているし、 HonoをきっかけにGitHubスポンサーをしてくれている企業や人も現れている。 なにより、いろんなことを勉強させてもらった。 今回はHonoというプロダクトがどうやって2,000のスタ
フロントエンドのテストコードを書くときに大切にしていること - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、フロントエンドエキスパートチームの @mugi_unoです！ kintone では フロントエンドの刷新プロジェクト（通称フロリア）が進行中です。 blog.cybozu.io kintone の開発では E2E 主体の自動テストを整備していましたが、 フロントエンドの刷新に合わせて、新たにフロントエンド側でのテストコードを積極的に書いています。 テストを書くことに不慣れなメンバーもいるため、日々 Pull Request 上でのレビューやペア・モブ作業を通じて、知見の共有が行われています。今回はフロントエンド刷新のテストを書いてきた中から、筆者が有用だと感じた知見やノウハウを紹介したいと思います。 目次 💡「実はそれ最初からパスしてるかもしれない」 期待する操作で期待する結果になることを厳密に検証する 他のテストケースによって前提条件を担保する 💡「テストコード上のロジッ
2016年だけどMakefileを使ってみる - Qiita
この資料はなに？ Makeの良さを伝えるものです CとかC++の持ち物じゃない 普段使うコマンドのショートカットみたいな 2016年でもMakefileは便利 頑張らないでScala 〜VOYAGE GROUPにおけるアドネットワーク開発の戦略〜 // Speaker Deck Makeってなに？Makefile??? make(メイク)は、プログラムのビルド作業を自動化するツール。コンパイル、リンク、インストール等のルールを記述したテキストファイル (makefile) に従って、これらの作業を自動的に行う。 出典：https://ja.wikipedia.org/wiki/Make つまり、自動化のためのツール。 make が生成するのはふつう C のプログラムだが、べつに C のプログラムに限らず、Makefile に書く生成コマンドの書きように よっては、TeX のファイルだろうが
CPUアーキテクチャの種類(x86, x64, arm) - わくわくBank
命令の仕方 x86 x64 は CISC(Complex Instruction Set Computer) と呼ばれる命令セットです。 「複雑な処理」を「少ない命令」で実行しようとする思想です。 arm は RISC(Reduced Instruction Set Computer) と呼ばれる命令セットです。 ビット数 ビット数が大きくなるにつれ、一度に処理できる量が増えます。処理スピードUP・利用可能なメモリ容量UPが見込めます。 x86, x64 x86 は 32bit です。 x64 は 64bit です。 arm arm については、ARMv7 では 32bit でした。 ARMv8(2011年発表) では実行モードというのがあり、AArch32だと32bit 、AArch64だと64bit となるようです。(ややこしい…) Linuxでは、ARMv7までのアーキテクチャの表記
なにこれ便利すぎる！ WebページのURLを入力すると、編集可能なFigma用に変換できるプラグイン -html.to.design
WebページのURLを入力するだけで、編集可能なFigmaデザインに変換できる無料プラグインを紹介します。 AppleなどのWebページを1クリックで変換するのはもちろん、日本語のWebページでも問題なく動作しました。Webデザインの勉強用に、既存サイトをリニュアールする用にも便利ですね。 html.to.design -Figma URLを入力するだけでFigmaに変換 html.to.designの利用方法 html.to.designの使い方 URLを入力するだけでFigmaに変換 html.to.designは、URLを入力するだけでFigmaに変換できる無料のプラグインです。さまざまなWebページを編集可能なFigmaデザインに変換します。 すべてをゼロから作成することなく、別のWebサイトを使用して独自のデザインのインスピレーションを得られます。 既存のWebサイトをリデザイン
Terraform - Route 53 alias のホストゾーンID のお話
背景 Terraform で Route 53 で alias を使う際に必ず欲しい情報のはず。 課題 「zone_id 何設定するんだっけ？」の答えを知りたい。 そんな時のブックマークです。 解決 Amazon API Gateway AWS AppSync 調査中... Amazon CloudFront AWS Elastic Beanstalk Elastic Load Balancing(Application, Classic, Network) Global Accelerator 調査中... Amazon Simple Storage Service Amazon Virtual Private Cloud 調査中... 一言 一部調査中ですみません。 何も考えずに当該ドメインのホストゾーンID設定するとコケますよ。 20年以上のビジネス歴を持つインフラの専門家。セキュリ
サービスクラスについては僕も悪かったと思っているけど、それでもCQSは実現したいんだ - Qiita
このエントリは Ruby on Rails Advent Calendar 15 日目です。（遅くなってすいません） 同時に 14 日目のじょーかーさんのエントリへのアンサーエントリでもあります。 （まあ、じょーかーさんがこの Advent Calendar に登録したときに、タイトルから内容を推察してこれを書くことを決めましたが、実際のところ、あまりアンサーにもカウンターにもなってないし、全然関係ない内容と言えないこともないので、まあサービスクラスについては僕も推奨したことがあるし、僕も反省してるんですよ程度に読んでもらえると幸いです。） まずはじめにごめんなさい 3 年くらい前に僕は Rails にサービスクラスというものを導入するといいことがあるよと書いたのだけど、それからいくつもの Rails アプリケーションを見たり、実際に自分で開発したりして、うーんって思うことも増えてきたので
Rails on YOUTRUST ＜ロジックどこ置く？編＞ - YOUTRUST Tech Blog
こんにちは、YOUTRUSTのやまでぃ（YOUTRUST/Twitter）です。 前回の記事より約4ヶ月振りの登場です。 前回の記事ではたくさんの反響ありがとうございました。まだ未読の方は是非読んでみてください。（スケーラブルなリスティングロジックについてです） 最近のわたくし事ですが 今ONE PIECEの連載が最終章に突入して熱いとの噂をキャッチし、8月に入ってから漫画を最初から全巻読み直しています。 僕のマイサウナである国立温泉 湯楽の里に全巻置いてあり、毎回1000円弱でサウナに水風呂に漫画まで読めて最高です。深夜1時まで営業しており、最近土日の大半はここにいます。（何なら平日も昼間からいるときも？） マイサウナの湯楽の里。食堂で毎回サバ注文してます。 今回は何書くの？ Railsのロジックのクラス分けについて書きます。 弊社ではキャリアSNSとHR SaaSの2つのプロダクトを提
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NatML for Unity | Unity
GitHub - kt3k/remarker: :arrow_forward: Remark cli
Help content — Shopify Polaris
RailsDiff