この Gist は、次の Gist に収録している「Thoughtworks Technology Radar 長期トレンド分析(大企業CTO向け戦略レポート)」の図表画像(12 点)を置くためのものです。
| module FsProb.Distribution | |
| open System | |
| open FsProb.Util | |
| type IDistribution<'a> = | |
| abstract member Sample: unit -> 'a | |
| type IWeightedDistribution<'a> = | |
| inherit IDistribution<'a> |
Original paper: https://arxiv.org/abs/2605.04259
Brian Houck, Tim Bozarth, David Liu, Dean Carignan
すべてのエンジニアリングリーダーは、同じ問いを発している。「自分たちの開発者は生産的なのか?」そして「自分たちの生産性は向上しているのか?」。これらの問いは何十年にもわたって重要であり続けてきたが、AI の台頭によって、仕事の進め方そのものが根本的に変わりつつあるため、実存的な緊急性を帯びるようになった。本稿では、ソフトウェア開発の形が進化し続けても意味を持ち続ける、生産性を測定するための持続性のある多次元モデルを提案する。
React Hooks に慣れている人が Flutter / Riverpod を学ぶとき、最初に理解すべきなのは「どの API がどの hook に対応するか」ではありません。
より重要なのは、UI が再構築される条件と、依存オブジェクトや command をどこから取得するかが、React と Flutter / Riverpod では違うという点です。
React では、component は state / props / context を入力として再実行されます。
また、event handler は component の lexical scope にある値を closure として参照できます。
一方、Flutter / Riverpod では、Provider の値を UI の再構築条件に含めたいなら ref.watch で明示的に購読します。
https://github.com/Versent/saml2aws をベースに一部修正
winget install saml2aws
.NETは、Microsoftによる統合的なエコシステム管理により、標準ライブラリが充実し、フレームワーク間の整合性が比較的高く保たれています。しかし、プラットフォームの近代化とクロスプラットフォーム化を推進する過程で、時には破壊的変更を伴う進化を遂げてきた歴史も持ちます。
-
.NET Framework時代: この時期はバイナリ互換性が重視されました。しかし、依存関係の管理には課題がありました。単一のアプリケーションが参照する多数のライブラリ間で、推移的依存のバージョンが異なると競合が発生し、開発者は「bindingRedirect」という設定を手動で調整する必要がありました。これは複雑で間違いやすい作業でした。
-
.NET Core / .NET 5+ 時代: クロスプラットフォーム対応とパフォーマンス向上を目指した.NET Coreの登場により、APIの整理やアーキテクチャの刷新が行われました。この移行期には以下のような互換性の課題が顕在化しました:
- Entity Framework 6 (EF6) と EF Coreの間には直接的な互換性がなく、コードの書き換えが必要
| open Falco | |
| open Falco.Routing | |
| open Microsoft.AspNetCore.Builder | |
| let endpoints = | |
| [ get "/weather" WeatherForecast.getRandom | |
| get "/" (Response.ofPlainText "Hello World!") ] | |
| [<EntryPoint>] | |
| let main args = |