kuwadgiのブックマーク (1,338)

  • たった2つのステップを意識するだけで書けない単体テストがほぼなくなる - Qiita

    はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう!』 『今までモック使ってたけど意外とモック使わなくても書けるね!』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 もくじ テスト駆動不具合修正 or リファクタリング手順 なぜテストが書けないのか 依存関係を排除できればテストは書ける 依存関係を排除するためのカギになる考え方 書けない単体テストがなくなる2

    たった2つのステップを意識するだけで書けない単体テストがほぼなくなる - Qiita
  • 関心の非対称性について - Magnolia Tech

    プログラミングにおいてちゃんと設計しないといけないのは、側機能追加に於いて要求を出す側の関心の中心が新しい機能に有るのに対して実装する側は、それと同じくらい既存の機能との整合性を取ることに置かれるという、その非対称があるからなのですよ— magnoliak🍧 (@magnolia_k_) November 22, 2023 いろいろな設計方法論とか、良いコードを書くためのお作法とか、最近だと書籍もたくさん出ていて、無限に勉強することができるのだけど、勉強ばかりしている訳にもいかず、われわれは目の前の課題を解決するためのコードを書いたり、納品するためのコードを書いたり、なんのために作っているのか分からないプロダクトのコードの断片を指示通りに書かされる日々と向き合っていかないといけない、という現実があるわけで、つまり時間は有限なのです。 この関心の非対称性というのが色々なところに在って、これ

    関心の非対称性について - Magnolia Tech
  • どうしてあなたの共通化は間違っているのか:目次 - Qiita

    はじめに この連載では共通化とモジュール分割について扱います。この話題においてQiitaで有名な記事のひとつが@MinoDrivenさんの単一責任原則で無責任な多目的クラスを爆殺するでしょう。この記事を未読の方はまずこちらを読むことをお勧めします。連載では、この記事に書かれているような基礎的な事項については既知であることを前提に、どのようにすれば単一責任原則にそったモジュールの分割を行うことが出来るのかをなるべく 「場合による」という言葉に逃げずに なるべく 網羅的・理論的に 解説します。 いいね、ストックをよろしくお願いします。 対象読者 設計に興味のあるエンジニア 基礎的な設計原則について学んだものの、実際の場面でどのように応用すればいいのかが掴めないエンジニア ミクロな設計についての知識を増やしたい人 ※この記事では、特定のメソッドをどのように作成するべきか、このクラスは複数の処理

    どうしてあなたの共通化は間違っているのか:目次 - Qiita
  • どうしてあなたの共通化は間違っているのか:第1章「単一責任原則の有用性」 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    どうしてあなたの共通化は間違っているのか:第1章「単一責任原則の有用性」 - Qiita
  • 『LeanとDevOpsの科学』をきちんと解読する 〜Four Keys だけじゃ絶対もったいなくなる話〜

    スクラムフェス福岡2024での講演資料です。 --- 皆さん、職場でFour Keysを導入していますか? Yesと答えた皆さん、『LeanとDevOpsの科学』は読みましたか? あくまで僕の周囲のみの観測で語るのですが、Four Keysを職場で導入しているという人はとても多いので…

    『LeanとDevOpsの科学』をきちんと解読する 〜Four Keys だけじゃ絶対もったいなくなる話〜
  • エッセイ: React with React Compiler は "Just JavaScript" であるか · ubugeeei/work-log · Discussion #429

    Twitter で散らかしてしまったので軽くまとめておく. 序・前提 まず前提として、コンパイラを使った最適化を行うという方針については私はとても賛成である. インターフェースを崩さずに DX を改善するにあたってこのアプローチはしばしば有効的であるし、私自身もそれを全面に押し出すフレームワークを使っている. ただし、コンパイラが介入するにあたってのメンタルモデルの変更(または統一 1) についていくつかの疑問がある. 私は普段から React を書いているわけでもなく専門家でもないので、これから話すことは React に対する意見というより、「React を使っている人は、この点どう感じているのだろうか?」という好奇心からくるもので、その是非に対するものではない. 何度も言うが私は 賛成 している. また、これらは https://react.dev/blog で React Compi

    エッセイ: React with React Compiler は "Just JavaScript" であるか · ubugeeei/work-log · Discussion #429
  • 【翻訳】テスト駆動開発の定義 - t-wadaのブログ

    このブログエントリでは、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化(Semantic Diffusion)とは、新しく作り出された用語が広まる際に来の意味や定義が弱まって伝わる現象です。 私(和田)はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正

    【翻訳】テスト駆動開発の定義 - t-wadaのブログ
  • 「UIの色を変えただけで大量のクレームを頂戴してしまった話」の何が問題か?|moutend

    結論話題の記事「UIの色を変えただけで大量のクレームを頂戴してしまった話」を読みました。ユーザーを軽視した内容に驚愕したのですが、それよりも記事が批判されている原因を理解できていない様子の方が存在することに衝撃を受けました。 現職のデザイナーあるいはデザイナーを目指している方々にお伝えしたいことは以下の3点です。 具体的な不都合を訴える問い合わせは無益なクレームではなく有益なフィードバックです。プロダクトの価値向上につながる貴重な意見ですから無視するべきではありません。 時間の経過でユーザーがUIに慣れることはありません。問い合わせをしても無駄だと学習して離脱したパターンを疑いましょう。受け入れられる場合も含めて画面の変更はユーザーに負担を強いているのだと自覚してください。 色覚特性や色とコントラストについて学びましょう。色だけで情報を伝えるデザインはアンチパターンですから避けてください。

    「UIの色を変えただけで大量のクレームを頂戴してしまった話」の何が問題か?|moutend
  • 「アニメ聖地巡礼で町おこし」はただアニメに乗っかりたいだけの気持ちでは失敗するという話

    yoshihiro tsuduki @y_tsuduki 都築由浩:作家、コミック原作、編集デザイン、大学や専門学校ではいろんなことを教えるなど出版関係でいろんな仕事を兼業する趣味の人。 このアカウントは日の政府批判とトランプ政権批判に特化したアカウントになります。日常のつぶやきを読みたい方はblueSkyを、料理画像を見たい人はinstagramで探してみてください。 tsuduki.com yoshihiro tsuduki @y_tsuduki 以前から「アニメ聖地巡礼で町おこし」とか言っている地元の人に言ってる「あなたご自身が好きになれるかどうか、そのアニメを見て判断してください。好きになれば、どうタイアップすればいいかはわかると思います。タイアップありきで作品を見もせず乗っかったら失敗します」ということ。 x.com/shirataki_co/s… 2024-03-05 15:

    「アニメ聖地巡礼で町おこし」はただアニメに乗っかりたいだけの気持ちでは失敗するという話
  • Google Cloudのサーバーレス製品を活用したアーキテクチャ | gihyo.jp

    連載は、Google Cloudのアプリ開発とDBプロダクトにおけるスペシャリスト達が、Google Cloudプロダクトを利用した、クラウドネイティブな開発を実践する方法を解説しています。 第5回の今回は、Google Cloudのサーバーレス製品を活用したアーキテクチャに焦点を当て、アプリケーション開発における実装パターンを実践的ないくつかのユースケースにあわせて紹介をします。また、サービスの選定にまよったときの判断のポイントも紹介します。 基のアーキテクチャパターン まず最初に、クラウドアーキテクチャセンターを紹介します。Google Cloudでワークロードをビルドまたは移行するためのリファレンスアーキテクチャ、ガイダンス、ベストプラクティスがまとまっているページです。クラウドのアーキテクチャを検討する際に、こまったらここを参考にするとヒントが詰まっています。 Webアプリケー

    Google Cloudのサーバーレス製品を活用したアーキテクチャ | gihyo.jp
  • 【俺得】#SFのおぞましい設定 まとめ【ネタバレ多数注意】

    ponchang🌸77 @fengyunzaiqi888 #SFのおぞましい設定 ド定番 ???『先生もどうだい?(べないのか?)』 ????『いいえ。私は遠慮しておきます』 ????『あなた達は、あの料をべました。その事をよく認識して、その扉を開けてください』 2024-03-04 19:44:42 tonkatudon @t22204102 #SFのおぞましい設定 ファウンデーション 一人の男が自動車事故で死ぬかどうかで 銀河帝国になるか、時間管理局による永遠の支配の未来か別れる、 なお、一人の男が自動車事故で死に核戦争で地球が荒廃し、外世界人スペイサーによる管理支配を経てAIに勝利した後に銀河帝国は生まれる、 2024-03-04 19:45:34

    【俺得】#SFのおぞましい設定 まとめ【ネタバレ多数注意】
  • 漫画大国フランスがついに「少女漫画」の魅力に気づきはじめた | 70年代の日本作品が半世紀を経て上陸

    世界第2位の「漫画消費国」といわれるフランス。日漫画が絶大な人気を誇るなか、これまであまり評価されてこなかったのが少女漫画だ。だが、ついに「shôjo」にも光が当てられはじめた。それには、熱烈なファンの力もある。 「絶対にアングレームに行かなくては」──ブログ「Club Shôjo」の管理人、オードリー・マニスカルコはそう決意していた。彼女が興奮する理由は、漫画家・萩尾望都(はぎお・もと)の来仏だ。2024年1月、フランス南西部の街アングレームで開催されたヨーロッパ最大級の漫画の祭典「アングレーム国際漫画祭」では、彼女の栄誉を称え、特別回顧展が催された。 1949年生まれの漫画界の巨匠、萩尾望都は、永遠の若さに囚われた吸血鬼一族を描いた『ポーの一族』(小学館)の作者だ。1970年代に日で出版されたこの傑作がフランスに上陸したのは、2023年になってからだった。フランス語版を出版したアカ

    漫画大国フランスがついに「少女漫画」の魅力に気づきはじめた | 70年代の日本作品が半世紀を経て上陸
  • Ajax 通信を簡単にする htmx の基本と実践 | フロントエンド | スタッフブログ | 名古屋のCMS構築・Web制作会社 アップルップル

    htmx は、JavaScript のコードを書かずにサーバーとの非同期通信を実現し、ページの一部を更新することを可能にする JavaScriptライブラリです。HTML属性の拡張により簡単に使用できるようにし、結果として、コードの可読性が向上し、将来のメンテナンスも容易になります。これらの特徴から、htmx はウェブサイト制作の現場での活用が期待されます。 簡潔さとアクセシビリティ: htmx は、複雑な JavaScriptコードを書かずに、HTML 内で直接動的な振る舞いを宣言することを可能にします。これにより、Web開発がよりアクセスしやすく、より理解しやすくなることを意味します。 非同期リクエストの簡易化 : htmx は、Ajaxリクエストを簡単に実装するための属性を提供します。これにより、サーバーへの非同期リクエストを簡単に行い、ページの一部を更新できます。 導入の容易さ :

    Ajax 通信を簡単にする htmx の基本と実践 | フロントエンド | スタッフブログ | 名古屋のCMS構築・Web制作会社 アップルップル
  • 雑にReactアプリを作りたい時に使ってるもの

    import "./App.css"; import { Link, Route, Switch } from "wouter"; function Nav() { return ( <nav> <Link to="/">Home</Link> <br /> <Link to="/about">About</Link> </nav> ); } function Home() { return ( <div className="App"> <h2>Home</h2> <Nav /> </div> ); } function About() { return ( <div className="App"> <h2>About</h2> <Nav /> </div> ); } function App() { return ( <> <Switch> <Route path="/" compo

    雑にReactアプリを作りたい時に使ってるもの
  • TypeScriptの代数的部分型模型

    書ではTypeScriptの型と部分型関係がなす代数的構造を解説し、型についての強固かつ柔軟なメンタルモデルを構築します。 順序理論、集合論、束論、環論、そして圏論に至るまで、複数の数学理論を利用して多角的にモデルを構築することで、型の直感的な理解を深め、型の互換性に対する自然な推論を可能となるように解説した新しい試みのです。

    TypeScriptの代数的部分型模型
  • 【徹底比較】Vue.js と React でレンダリングされる値、されない値

    *1. 画面に表示されるがコンソールにエラーが出る。 Warning: Received NaN for the `children` attribute. If this is expected, cast the value to a string. *2. 画面には表示されずコンソールにワーニングが出る。 [Vue warn]: Invalid VNode type: undefined (undefined) *3. Chrome だと以下の形式(実行環境によって異なる可能性あり)。 Mon Jan 01 2024 00:00:00 GMT+0900 (GMT+09:00) *4. ランタイムエラー。 Uncaught Error: Objects are not valid as a React child (found: object with keys {}). If you

    【徹底比較】Vue.js と React でレンダリングされる値、されない値
  • 素の JavaScript でコンポーネントを作成してみて React の気持ちを考えてみる - Qiita

    はじめに 素の JavaScript でフロント開発経験がない React 育ちのエンジニアです。 Reactフロントエンド開発をしていて大きく困ることはないのですが hooks, JSX, 様々なライブラリを使用していていると JavaScript を理解していたらという場面がちょこちょこ発生します。 そのため最近は JavaScript の基礎的な勉強をしています。 JavaScript の理解を深めることによってスムーズにキャッチアップできたり、裏側でどのように動作しているかなど想像しやすくなるだろうという目論見のもとで。 そこで、素の JavaScript を使用して TODO リストのためのコンポーネントを作成してみました。 JavaScript の Class を理解していることを前提に述べていこうと思います。 TL;DR JavaScript 組み込みの shadowDO

    素の JavaScript でコンポーネントを作成してみて React の気持ちを考えてみる - Qiita
  • IPAマンガでわかるソフトウェア開発データ分析38編.pdf

    マンガでわかる ソフトウェア開発 データ分析 データ分析事始め データ分析FAQ (参考)アジャイルメトリクスFAQ 1 独立行政法人情報処理推進機構 超合版38編 データ分析事始め 目次 データ分析基礎編 01 データ分析ってなんなの? データ分析 02 信頼幅の線、気になる 信頼幅 03 箱ひげ図のひげ、かわゆくない 箱ひげ図 04 散布図はぜんぜんばらばら 散布図と箱ひげ図 05 どれが命なの? 中央値と平均値 分析データ観察編 01 生産性は性癖が出る? 生産性 02 バグを愛したソース 信頼性(不具合密度) 03 改修・保守が好き過ぎる 開発プロダクトの種別 04 規模はアンバランスでアンビバレント ソフトウェア規模 05 開発期間は短くて長くて短い 開発期間(工期) 06 ウォーターフォールってつおい? ウォーターフォール型開発 07 ここはツールでしょ 開発ツール 08

  • 技術の素振りのために記事を書く

    技術の素振りのために記事を書く 2024.02.20 技術の素振りを、ここではある特定の言語やフレームワークに対する理解を深めるために、その技術を使って何かしらの成果物を作成することと定義します。素振りの目的としては、ドキュメントからは読み取れない Pro/Con を得ること、その技術が実際のプロジェクトで使えるかどうか調査するといった事項があげられるでしょう。ただ素振りするだけではぼんやりと頭に知識が入っている状態になりがちですが、他者への説明というアウトプットを意識することで、コードを書くことによって得られた知見を整理できるようになります。 技術の素振りを、ここではある特定の言語やフレームワークに対する理解を深めるために、その技術を使って何かしらの成果物を作成することと定義します。素振りの目的としては、ドキュメントからは読み取れない Pro/Con を得ること、その技術が実際のプロジェ

    技術の素振りのために記事を書く
  • LeanとDevOps生産性の神話(1) - 11年目のState of DevOps Report|シリコンバレーからのノート

    「LeanとDevOpsの科学」が2018年に出版されてから今年2024年で6年が経った。この書籍のもとになった「State of DevOps Report」という技術レポートが最初に発行されたのは2013年なので、それから数えるとなんと11年目である。 LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ www.amazon.co.jp 今でもたびたび参照される書籍ではあるが、書が提案している内容はほぼその有効性を失っていると言っていいのではないだろうか。 特に「フォーキーズ」と呼ばれる4つの生産性の指標で組織全体の生産性が判断できるという部分は、他でもない書の序文でマーティン・ファウラー氏が疑問を呈しているように、書の出版直後から様々な指摘がされており、当初からシリアスな現場への影響力は限

    LeanとDevOps生産性の神話(1) - 11年目のState of DevOps Report|シリコンバレーからのノート