Four keys を計測する CLI ツールを作った - Qiita
はじめに Four keys とはソフトウェア開発の生産性を測定するのに利用される以下の4つの指標のことである（参考）。 デプロイ頻度（Deployment Frequency） ソフトウェアのデプロイ頻度 変更リードタイム（Lead time for changes） ある変更をソフトウェアに適用してから、その変更がリリースされるまでの時間 障害修正時間（Time to restore） ソフトウェアに障害が発生してから、その障害が修正されるまでにかかった時間 障害率（Change failure rate）ソフトウェアのデプロイのうち障害が発生したデプロイの割合 これらの指標を簡易に測定するための CLI ツールを作成した。 この記事では、この CLI ツールについて紹介する。 使い方 インストール Releases の最新バージョンから自分の環境に合わせた実行ファイルをダウンロードす
理想的なStorybookのワークフローとは - Qiita
こちらの記事は、Dominic Nguyen 氏により2018年 5月に公開された『 The Delightful Storybook Workflow 』の和訳です。 本記事は原著者から許可を得た上で記事を公開しています。 あなたのチームのアドオン、コンフィギュレーション、APIといった一連のニーズに合わせてカスタマイズできる事は、Storybookの大きな利点です。しかし、Storybookは指先一つで様々なオプションが操れるが故に、全体像ーStorybookのワークフローを見失いがちです。 今回、私は4つのプロフェッショナルチームとStorybookのメンテナー達にインタビューを行い、彼らの「生産性、セットアップ、メンバーの満足度」のバランスを取るためのコアワークフローを要約しました。この記事では、StorybookでUIコンポーネントを生産するための効率的な反復プロセスについて説明
[翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita
こんにちは、食べログシステム本部長の京和です。 本エントリでは Shopify の Engineering Blog から、Kirsten Westeinde による「Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity」を翻訳して掲載します。 食べログではユーザーや飲食店に価値を届けるスピードを最大化するべく、マイクロサービス化などをはじめとしたこれまでの組織やアーキテクチャを刷新するための取り組みを始めています。しかし、マイクロサービスはアプリケーションアーキテクチャとインフラアーキテクチャが複雑に絡み合ったシステムで技術的難易度が非常に高く、適切に構築できなければ「分散されたモノリス」と呼ばれるアンチパターンに陥ります。1 Shopifyではマイクロサービスではなく、
![[翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/15ef8078be3e3da04452bb61b549b0c2e924abfb/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU3JUJGJUJCJUU4JUE4JUIzJTVEJTIwU2hvcGlmeSVFMyU4MSVBQiVFMyU4MSU4QSVFMyU4MSU5MSVFMyU4MiU4QiVFMyU4MyVBMiVFMyU4MiVCOCVFMyU4MyVBNSVFMyU4MyVBOSVFMyU4MyVBMiVFMyU4MyU4RSVFMyU4MyVBQSVFMyU4MiVCOSVFMyU4MSVCOCVFMyU4MSVBRSVFNyVBNyVCQiVFOCVBMSU4QyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzM0EzQzNDJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9MGZmMDEzOTY1NDhkMDNjYThjYTVmMWFlZGZkMjNkN2U%26mark-x%3D120%26mark-y%3D96%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDB0a3lvd2EmdHh0LWNvbG9yPSUyMzNBM0MzQyZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWZiZDJlOGIzYmQzMjk3ZDIxOTA4MjFhZDlkMGI0NTE2%26blend-x%3D120%26blend-y%3D445%26blend-mode%3Dnormal%26txt64%3DaW4g6aOf44G544Ot44Kw%26txt-width%3D972%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25233A3C3C%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D134%26txt-y%3D546%26s%3D82e163327a6dfc81be1ea9d983b95f9d)
食べログの大規模なレガシーシステムを段階的に改善していく取り組み - Qiita
こんにちは、食べログシステム本部長の京和です。 今年の4月から本部長になりました。さらに4月に娘が生まれました 本エントリでは食べログで1年を通じて取り組んだ、大規模なレガシーシステムの段階的な改善について紹介します。[翻訳] Shopifyにおけるモジュラモノリスへの移行 に続いて2記事目のアドベントカレンダーになります。 どのように段階的に進めるか 食べログは今年で15年目のサービスで、Railsになってからは13年が経過しています。これだけ歴史があればあちこちにガタが来ているのは当然で、無数にある課題に対してどこからどのように取り組んでいくかを最初に決める必要がありました。 まず最初の前提として以下のように考えました。 既存のビジネスや開発を止めるような悪影響を与えない。むしろなるべく早くポジティブな影響を与えていきたい。 これだけ歴史のあるシステムを改善していくのは長い時間がかかる
4年ぶりにエンジニアに戻った人の話 - Qiita
こんにちは、Qiita初投稿です。 色々あって昨年末に4年間勤めていた外資系のゲーム会社でのプロデューサー業を辞めてエンジニアに戻りました。 前職ではエンジニアではなく、翻訳やアカウントマネージメント系の仕事などをやっていました。 エンジニアブログを書く前に、今回は元エンジニアが4年間経ってエンジニアに戻って世界が一変していた、浦島太郎のような話をしたいと思います。 経歴: 2011年: 大手企業に新卒でエンジニア就職 秋入社というのもありまさかの新卒唯一の日本人、まわりは中国人とインド人ばっかり。入社一日目でエンジニア職人気なさすぎオワタと思う。まわりのエンジニアが毎月行われれていた深夜作業に駆り出されていくのを怯える毎日（結局一度もその作業をすることはなかったが） 2013年: ベンチャー企業へ転職 前職ではテスト業務しか触れず、いつの間にかポジションもQAエンジニアになってしまったの
思いもよらないものをnpm publishしてしまった話（前任者の顔写真など） - Qiita
俺「すっげぇいい名前のライブラリ思いついた！！」 俺「npm あるかな？あるかな？」 （カタカタ） 俺「なかった！よっしゃ一番乗りや！！！今すぐ作らないと！！！」 俺「npm init enter enter enter enter npm publish うおおおおおおおいっけぇぇぇ！！！！！！！」 （ｶﾀｶﾀｶﾀｶﾀｶﾀｶﾀｶﾀｶﾀｯﾀｰﾝ） 俺「ミ゜ッ！」 ーーー おはようございます。本番環境でやらかしちゃった人 Advent Calendar 2019の 23 日目を担当する、@sandessOjisanです。この記事では 思いもよらないものを npm publish したお話 を紹介します。 僕は あるとき 色々な会社の仕事を請け負っていた時期があり、そのときの無邪気なnpm publishによって、良くないことをしてしまったというお話しです。このコマンドを叩くといきなり本番環境
Amplify vs Firebase 比較してみた - Qiita
サーバレスアーキテクチャの選択肢として、AWSのAmplify、GoogleのFirebaseが有力な候補となっているのではないでしょうか。 実際にAmplify・Firebaseの両者に触れ、比較・検討して得られた知見をまとめました。 ※直近プロダクトの開発にAmplifyを採用して進めてきたので、Amplifyを軸に記事を書いています。 API連携 AmplifyとFirebaseとで異なる特徴のひとつにAWS AppSync（GraphQLをすぐに利用できるフルマネージドサービス）を利用できる点があります。 自前でGraphQLを構築するのは手間がかかりますが、AmplifyのAPIモジュールは「AWS AppSync」をサポートしているので簡単に構築できます。DynamoDBやLambdaとのアクセスもシームレスに行えるので非常に便利です。 以下はその他のAppSyncのメリット
中の人に聞いたGitHub flowの本当の使い方 - Qiita
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
誰でもQiita投稿のtypoをチェックできるようにNowでlint機能を公開しました - Qiita
予定通りならば、先週にtypoチェック機能へtextlintを追加した話を投稿したはずです。 最近の投稿はそれを使って私が個人的趣味で編集リクエストを出しているのですが、 やっぱり古い記事のtypoも気になるわけで。 でも古い記事の保守判断って外部からは難しいので… いっそ自主的にできる環境があればいいのかなあと思いました。1 Qiita Typo Checker (無料どころの例に漏れずスリープするのでアクセスは遅いです) khsk/Qiita-typo-checker-zeit: Qiita-typo-checkerをユーザー指定と任意テキストに限定したWebアプリとしてzeitにデプロイします ということでコードをいじって、Webアプリケーションフレームワークを導入してブラウザから使えるようにしてみました。 機能はSlackに投げていたもの以上のものではないので、アプリやZEIT周り
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Next.js 8がリリースされた 🎉 新機能・改善点まとめ - Qiita
FirebaseでWebチャットアプリをデプロイするまで（1時間コース）