Figma to MUIThe Easiest Way to Export Figma to Material UIWe convert your designs on Figma to Material UI that is seamless so you can boost your MUI development.
ビジネスインパクトのない新機能に費やす時間とコストを低減する｜mtx2s
リリースした新機能がビジネス指標に何の影響も与えていない。ユーザーからの評判も芳しくない。いや、そもそも反応すらない無風状態。我々が費やした努力と時間はなんだったのか。 このような失敗は、ソフトウェアプロダクト開発に携わっていると何度でも経験します。むしろ、期待通りの成果を得られることの方が少ないでしょう。 失敗から得られる知見もありますが、それと引き換えに費やしたコストと時間は戻せません。それが繰り返されると、組織全体の士気が落ち、学習性無力感に支配されていきます。ソフトウェアプロダクトは、そのマネジメントにおいて、常にこれらのリスクを抱えています。 本記事では、機能リリースに伴うこのようなリスクを制御する方法について考えます。 期待する成果が得られないことを前提に計画する機能リリースが期待どおりのインパクトをビジネスにもたらすかどうか。それを事前に予測し、世の中に送り出すべきアイデアを
クラウド時代も「アプリ」と「基盤」のチーム分けで本当にいいの？ - Qiita
私は新卒のときから10年ほどIT業界、ときには会社を移りながらエンタープライズのSI（System Integration）のさまざまな現場で働いてきましたが、システム開発のチーム編成として「アプリケーション担当」と「インフラ担当」に分かれていることが長らく当たり前でした。 最近はAWSをはじめとするパブリッククラウドの台頭、特に抽象度の高いマネージドサービスの普及によって従来型の分業モデルが理に叶わなくなってきたのでは？と感じることが増えたので、ポエムを書いてみます。 みなさんの案件はどんなチーム分けですか？ 私がよくいた「エンタープライズの業務システム開発」はこんなフォーメーションが多かったです。 とある社内向けWebシステムの開発体制 ユーザー企業（発注元の会社スタッフ） アプリケーション担当：通称「業務」。要求定義と仕様調整。事業会社だとコードレビューまではしないところが多い印象
従来とアジャイルで、品質メトリクスには本質的な違いがあるのではないか - ソフトウェアの品質を学びまくる
ソフトウェア開発における品質のメトリクスについて、新旧2冊の本を比べてみました。 1冊は、『初めて学ぶソフトウェアメトリクス』。 原著『Five Core Metrics: The Intelligence Behind Successful Software Management』（Lawrence H. Putnam、Ware Myers著）は、2003年に出版されています*1。 初めて学ぶソフトウエアメトリクス~プロジェクト見積もりのためのデータの導き方 作者:ローレンス・H・パトナム,ウエア・マイヤーズ日経BPAmazon もう1冊は、『アジャイルメトリクス』。 原著『Agile Metrics in Action: How to measure and improve team performance』（Christopher W. H. Davis著）は、2015年に出版されて
モダンなテストレベル設計（ユニットテスト～システムテスト等をどう設計するか）の原則 - 千里霧中
プロジェクト全体のテストを組み立てる際に重要な課題になるのが、テストレベル設計です。テストレベル設計は、ユニットテスト、結合テスト、システムテストといったテストレベルを、どのような責務・段取りで行うか分析・設計する活動です。 このテストレベル設計ですが、ここ10年程度の間に望ましいアプローチが変わってきたと感じています。今回はこの変化と、変化後のモダンなテストレベル設計の原則について、考えていることを書き出したいと思います。 旧来のテストレベル設計のアプローチ 旧来、このテストレベル設計では、Vモデルをベースしたアプローチや、自工程完結・品質積み上げをベースとしたアプローチがよく見られました。 このうち一つ目のVモデルをベースとしたアプローチは、要求定義から設計までの上流工程への対応を観点に、テストレベルを設計するものです。 （Vモデルが必須と明言しているわけではなく、極端な例ですが）例え
雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
Auth.js | Authentication for the Web
// auth.ts import NextAuth from "next-auth" import GitHub from "next-auth/providers/github" export const { auth, handlers } = NextAuth({ providers: [GitHub] }) // middleware.ts export { auth as middleware } from "@/auth" // app/api/auth/[...nextauth]/route.ts import { handlers } from "@/auth" export const { GET, POST } = handlers // src/auth.ts import { SvelteKitAuth } from "@auth/sveltekit" impor
コードは2回書きたい - Mitsuyuki.Shiiba
TDD についておさらいしておきたいなと思ったので読んだ t-wada.hatenablog.jp とても良かった。自動テスト、テストファースト、テスト駆動開発のそれぞれについて、どういうものなのか・効果・注意点が分かりやすく説明されている。たしかに、自動テストは必ず使うけど、テストファーストやテスト駆動開発は状況に合わせてやったりやらなかったりする 書籍「テスト駆動開発」の付録Cと対になっているということなので、付録Cも読みたくなって読み直しておいた。そちらにはテスト駆動開発のこれまでとこれからについて書いてあるので、頭の整理ができてとてもよかった Checking Driven Development 付録Cでは、開発者自身が書く自動テストはテストではなくてチェック、ということについて触れられている。そうだなぁって思う。自動テストでは、自分が考えたとおりに動くかどうかをチェックしている
要件定義～システム設計ができる人材になれる記事 - Qiita
はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの？」 「要件定義ってなに？」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。 そのため、本記事では実装（プログラミング）を開始する前に必要となる、 『企画～設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装（プログラミング）に使用する時間
開発組織の生産性を可視化するState of DevOpsとFour Keysとは(増補改訂版) / Introduction to State of DevOps and Four Keys for Visualizing Productivity in Development Organizations expanded and revised edition
以下のイベントの発表資料です。 https://phpcon.php.gr.jp/2022/ 想定課題 開発がスケールしたり、開発年数が経過すると、様々な要因で開発生産性の低下が起こります。 そこで現場のエンジニアは改善をしたくなるかと思いますが、大抵の場合、ステークホルダーと工数確保の合意が必要になります。 その際にこのようなことを言われがちではないでしょうか？ 今動いているものを直す必要ある？ 効果測定どうやんの？ 費用対効果はどれくらい？ パフォーマンスチューニングの世界には「推測するな計測せよ」という言葉がありますが、開発組織における生産性についても測定してモニタリングする必要があると思います。 本セッションの目標 以上を踏まえ、本トークでは開発組織とステークホルダーの間の共通言語を獲得することを目標に以下の内容についてお話します。 State of DevOpsとは Four K
SRE に成る君に最低限の開発力を身に着けてほしい - じゃあ、おうちで学べる
はじめに まず、はじめに皆さんへ言っておきたいことがあります。 このドキュメントの目的は皆さんをやる気にさせて一心不乱にコードを書きまくって新機能追加や改善をしてソフトウェアを開発していってほしいというわけではないということです。 もちろん、そうなってくれれば嬉しいですが気合が入ったからプログラムを急に書けるようになるわけではないのでそのような目的は一切ありません。また、この文章にはインフラエンジニアがコードを読み書きできなくて良いという意図はなくポジショニングトーク的にSREという単語を利用しておりますので何も言わないでください。 SREはそもそも、コードを書かなくてもよいエンジニアではない SREとは、ITサービスの信頼性を高めるために、ITエンジニア（開発者）が信頼性向上のために行う設計やアプローチ、またはこれらを行うチームや役割を指します。 Google では、SREチームの50～
テストコード導入奮闘記～私はこうやってプロジェクトにテストコードを導入しました～ - Qiita
導入 どうやら新卒2年目社員のAさんが上司のZさんにプロジェクトにおいてテストコード導入を打診してるようです。少し内容を見てみましょうか。 Aさん(新卒2年目社員)「最近テスト自動化やテストコード、TDDなどの単語をよく聞きます。うちはテストコード書いてないですし、実装後の簡単な動作確認、最終の結合テストしかしていません。開発体験と品質を上げるために、テストコードを導入したいです。」 Zさん(上司)「そうは言うがね、君。今のうちの状況を見てごらんよ。みんな複数のプロジェクトに関わっていて、常に多忙。残業時間もぎりぎりで何とかプロジェクトが回っている状態だよ。そんなみんなにさらに作業を増やすようなことを提案するというのかね？しかも、テストコードはお客様からしたら作っても作らなくても関係ない、いわば直接利益に関係ないような作業じゃないか。もちろん、世の中で認知されているということは知ってるよ？
独自Webアプリや社内ツールが作り放題のオープンソース開発環境「ToolJet」を使ってみた！ - paiza times
どうも、まさとらん（@0310lan）です！ 今回は、さまざまなWebサービスやデータベースと連携して、独自のWebアプリなどを手軽に開発できるサービスをご紹介します！ データソースの連携や画面デザインなどはドラッグ＆ドロップの操作で簡単に構築が可能で、ロジックやイベント処理などもわずかなJavaScriptを利用するだけで開発できるのが特徴です。 オープンソースで開発が進められており、セルフホストすることで大きな制限もなく活用できるのでご興味ある方はぜひ参考にしてください。 【 ToolJet 】 ■「ToolJet」の使い方 それでは、「ToolJet」をどのように使えばいいのか詳しく見ていきましょう！ まずはメールアドレスを入力したら【Create an account】ボタンをクリックして無料のユーザー登録を済ませておきます。 メールアドレス宛にユーザー登録用のリンクが送付されるの
やっぱりwebpackがわからない（エピソード1）
やっぱりwebpackがわからない（エピソード2）、そもそもnpmからわからないを公開しました。 webpackがわからない 最近はViteが注目されだして、実際にとても良いビルドツールです。Vue.jsのEvan Youさんが開発しただけのことはありますね。ネーミングもイカしてます。しかし、だからといって、では開発環境にViteを採用しようと簡単にはできないのが、業務の辛い所です。新しい技術を採用して、「わしが全責任を引き受けるぜよ」というThe 男気！な人はなかなかいません。 したがって、当分はwebpackを使い続けることになるのですが、これが未だによくわからないという人が意外と多いです。フロントエンドプログラミングの初心者に近い人などは、この段階でつまずくことにより、すっかり自信をなくしてしまうこともあります。 ですが一先ず安心してください。webpackを含むこれらフロントエンド
テストの自動化とテスト駆動開発
組織としてテスト自動化に取り組むべき理由と、手段としてのテスト駆動開発を紹介する講演資料です。以下のような内容です。 ねらい： ・主に顧客向けの業務システム(B2B)を開発している、 ・プロジェクトベース、ウォーターフォールプロセスが主流の開発現場や運用保守の現場にいる、 ・マネージャーのかたに向け、 ・テスト自動化が自分たちのメリットになると納得してもらい、 ・その道筋として2つのアプローチを紹介して、 - テスト駆動開発 - ペアプログラミング ・組織的・長期的に取り組む価値を感じてもらう アジェンダ: 1.自動化したい理由 2.必要な人材を考える 3.テスト自動化の端緒 ～テスト駆動開発について～ 4.深めつつ広げる鍵 ～ペアプログラミングについて～ 5.見る夢について
デジタル化の流行と「上流工程」の終焉 - SaaSベンチャーで働くエンタープライズ部長のブログ
DX（デジタルトランスフォーメーション）という言葉が流行し、猫も杓子もデジタル化という言葉を使い始めました。さて、デジタル化とは何なのか、そして流行しはじめたのはなぜなのか。 端を発するのは経産省の「2025年の崖」のレポートだと言われていますが、レポート読んではみたものの本題はSAP ERPの保守期限を意識した基幹システムの刷新化と技術的負債の返済であるにもかかわらず、日本企業のスピード感の話だったり、なぜかマイクロサービスとAI、アジャイルサービスなど流行のワードがたくさん出ており、論点がぼやけている印象を受けてしまいました。 基幹システム刷新化においてマイクロサービスなどは一部で使えるかもしれませんが、銀の弾丸とは思いませんし、現状整理によってはきちんとしたデータベース設計とウォーターフォールを主としたロジック移行が最適解であることも十分にありえるといち技術者としては思います。 僕自
技術的負債とステークホルダと説明責任と / The Debt
Talked at CloudNative Days Spring 2021 Online #CNDO2021. https://event.cloudnativedays.jp/cndo2021/talks/801
プロダクトマネジメントの罠「ビルドトラップ」とは？ アジャイルや組織改革の専門家、吉羽龍太郎氏が解説
プロダクト作りにはさまざまな「罠」がある。機能の開発とリリースに集中してしまい、顧客の本当の課題、プロダクトの本当の価値がおざなりになってしまう状況のことを「ビルドトラップ」と言い、プロダクトを開発する組織において陥りやすい「罠」の一つだ。なぜこの問題が起こるのか。どうすれば、本質的なプロダクト作りに立ち戻れるのか。『プロダクトマネジメント――ビルドトラップを避け顧客に価値を届ける』の訳者であり、アジャイル開発や組織改革のトレーニングなどを行う専門家、吉羽龍太郎氏が語った。 大事なのはアウトプットではなく、アウトカムとインパクト 吉羽氏はアジャイル開発やDevOps、クラウドコンピューティング、インフラ構築自動化、組織改革を中心にオンサイトでのコンサルティングやトレーニングを提供する専門家。吉羽氏がCTOを務めるアトラクタも同様のサービスを提供している。また吉羽氏は青山大学では非常勤講師と
Hotwireとは何なのか？
はじめに HotwireはBasecampが発表した、モダンなWebアプリケーションを作るための新しいアプローチです。名前もHTML OVER THE WIREから来ているように、HotwireではHTMLをサーバーから送ります。「それ普通のWebアプリケーションでは？」と思う方もいるかもしれませんが、SPA + APIサーバでJSONが使われるのに対し、SPAと同様の体験をHTMLを中心に置いて作るアプローチであることを示す表現です。 僕個人は、最初は「ふ〜ん」という感じだったんですが turbo-railsを読みつつHotwireのデモアプリをPhoenixに移植してみたり WebSocketではないTurbo Streamsのsourceを作ってみて遊んだり と、ある程度触ってみて良さが理解できてきたので、Hotwireを使うと何が嬉しいのか、Hotwireの各要素の紹介を記事として
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜテストを書くの？（または書かないの？） 〜テストコードの7つの役割〜 / #tamarubykaigi01
