matarillo

module My.Linq

open System
open System.Collections.Generic
open System.Linq
open System.Linq.Expressions
open System.Reflection

// 条件に一致する最初の結果を返す関数
let rec tryFirst (funcs: ('a -> 'b option) list) (input: 'a) =

matarillo

https://www.youtube.com/watch?v=1VgptLwP588

Mark RussinovichによるRustの技術セッションです。Markがどういう話をしているのか、およそ10分区切りで要約して。

Mark RussinovichのマイクロソフトにおけるRust採用についての講演要約

最初の10分 (0:00-10:00)

Markは、マイクロソフトがRustを採用した理由から話し始めています。マイクロソフトでは、過去10年間のセキュリティ脆弱性の約70%がC/C++でのメモリ安全性の問題に起因していることが明らかになりました。Markは個人的にC言語をシンプルで美しいと考えていますが、C++は複雑すぎると感じています。Rustは正確性を強制するシンプルでエレガントな言語だと彼は確信しています。

2022年9月、Markは「新しいC/C++コードはRustで書くべき」というツイートを投稿し、これが彼の中で最も反響の大きいツイートとなりました。このツイート後、サティア・ナデラCEOから電話があり、MarkはマイクロソフトのRust採用を推進することになりました。このムーブメントはマイクロソフト全体からの草の根の取り組みの一部であり、後に米国国家安全保障局(NSA)もC/C++からの移行を推奨することになります。

matarillo

module Json

open System.Text

[<AbstractClass>]
type JNode() =
    abstract member Stringify: unit -> string

[<AbstractClass>]
type JValue() =

matarillo

Title	GUIアーキテクチャ
Author	Martin Fowler
Date	18 July 2006

GUIアーキテクチャ

原文: GUI Architectures (martinfowler.com)

matarillo

module Cont

type Cont<'r, 'a> = ('a -> 'r) -> 'r

let cont (f: ('a -> 'r) -> 'r) : Cont<'r, 'a> = f

let bind (m: Cont<'r, 'a>) (f: 'a -> Cont<'r, 'b>) : Cont<'r, 'b> = fun k -> m (fun a -> f a k)

let callCC (f: ('a -> Cont<'r, 'b>) -> Cont<'r, 'a>) : Cont<'r, 'a> =
    fun k ->

matarillo

matarillo

SOLIDはソリッドではない - 単一責任原則を検証する

https://naildrivin5.com/blog/2019/11/11/solid-is-not-solid-rexamining-the-single-responsibility-principle.html

2019年11月11日

最近、SOLIDの原則について考えていて、その有用性に疑問を感じている。 SOLIDの原則は曖昧で、範囲が広すぎて、混乱を招き、場合によっては完全に間違っている。しかし、これらの原則の動機は正しい。問題は、ニュアンスの異なる概念を簡潔な文に落とし込もうとすることにあって、翻訳の過程で価値の大部分を失っているのだ。 これはプログラマーを間違った道へと導いてしまう（私にとっては確かにそうだった）。

おさらいとして、SOLIDの原則は以下の通りである：

matarillo

基調講演:あなたの考えをデバッグする

システムの構築には無数の複雑さが伴います。しかし、ソフトウェアエンジニアリングの20年の経験から、システムを本当に作ったり壊したりするものは何かを学びました。それは意思決定です。それはプログラミング言語でも、データストアでも、デプロイメントモデルでも、[ここにお気に入りの技術を挿入してください]でもありません。それは、行われた意思決定とそれが引き起こす波及効果についてです。私たちは、カフェイン入りチーターよりも速く疾走する業界の最新かつ最高のものについていくために、無限の時間を費やしています...しかし、私たちの思考プロセスを質問したり、改善したり、本質的にはデバッグしたりするために、どれだけの時間が費やされたのでしょうか?

意思決定をどのように構成し、それが構築するソフトウェアにどのように影響するか?最適でない意思決定が発生した場合、意思決定プロセス自体を熟考しますか?私はここ数年、意思決定の思考プロセスをデバッグし、ブレークポイントを配置して、どの仮定が私をここに導いたのか、そして私が見逃した可能性のある代替案を検査してきました。その結果、私の思考プロセスはより構造化され、合理化され、よりバランスのとれた意思決定につながりました。このセッションに参加して、クリティカルシンキングがどのように意思決定プロセスを変革し、ユーザーのために構築するソリューションの品質を向上させることができるかを検討してください。

YouTube: Keynote: Debug your thinking - Laila Bougria - NDC London 2024

詳細

matarillo

Keynote: Debug your thinking

There’s a myriad of complexity involved in building systems. However, two decades in software engineering taught me what truly makes or breaks a system: decisions. It’s not the programming language, the data store, the deployment model, or [insert your favorite tech here]. It’s about the decisions made and the ripple effects they cause. We spend endless hours trying to keep up with the latest and greatest in an industry that sprints faster than a caffeinated cheetah... But how much time was invested in questioning, improving, or, essentially, debugging our thinking process?

How do you structure your decisions, and how do they affect the software you build? When suboptimal decisions occur, do you reflect on the decision-making process itself? I've spent the last few years debugging my decision-making thought process, placing breakpoints to inspect which assumptions got me here and what alternatives I may have mi

matarillo

[
    [
        {
            "title": "Keynote: Debug your thinking",
            "text": "There’s a myriad of complexity involved in building systems. However, two decades in software engineering taught me what truly makes or breaks a system: decisions. It’s not the programming language, the data store, the deployment model, or [insert your favorite tech here]. It’s about the decisions made and the ripple effects they cause. We spend endless hours trying to keep up with the latest and greatest in an industry that sprints faster than a caffeinated cheetah... But how much time was invested in questioning, improving, or, essentially, debugging our thinking process?",
            "courseText": "How do you structure your decisions, and how do they affect the software you build? When suboptimal decisions occur, do you reflect on the decision-making process itself? I've spent the last few years debugging my decision-making thought process, placing breakpoints to inspect which assumptions got me here and what alter