Skip to content

Instantly share code, notes, and snippets.

using NetVips;
if (ModuleInitializer.VipsInitialized)
{
Console.WriteLine(
$"Inited libvips {NetVips.NetVips.Version(0)}.{NetVips.NetVips.Version(1)}.{NetVips.NetVips.Version(2)}");
}
else
{
Console.WriteLine(ModuleInitializer.Exception.Message);

鉄道指向プログラミング(の安易な利用)に反対する

(原文:Against Railway-Oriented Programming)

2019年12月20日

この記事は、2019年のF#アドベントカレンダーの一部です。他の素晴らしい記事もぜひご覧ください。企画者のSergey Tihon氏に感謝します。

6年半前、私は「鉄道指向プログラミング」と呼ぶものに関する記事を書き、講演を行いました。これは、エラーを生成する関数を連結するために、Result / Either をどのように使用するかを、自分自身や他の人に説明するための手段でした。

@matarillo
matarillo / Linq.fs
Last active March 8, 2025 08:52
LINQ: Building an IQueryable provider series
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) =

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
matarillo / Json.fs
Created November 26, 2024 10:38
コンピュテーション式を使わない書き方
module Json
open System.Text
[<AbstractClass>]
type JNode() =
abstract member Stringify: unit -> string
[<AbstractClass>]
type JValue() =
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 ->
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
@matarillo
matarillo / 1_srp.md
Last active February 20, 2025 02:26
SOLID原則はソリッドではない

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

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

2019年11月11日

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

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

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

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

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

詳細