Apple restricts Pebble from being awesome with iPhones
ericmigi.com
Show HN: I made a tool to port tweets to Bluesky mantaining their original date
bluemigrate.com
Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
github.com
Karatsuba Matrix Multiplication and Its Efficient Hardware Implementations
arxiv.org
US appeals court rules AI generated art cannot be copyrighted
reuters.com
A Tale of Four Kernels [pdf] (2008)
users.csc.calpoly.edu
Designing Electronics That Work
hscott.net
Google to buy Wiz for $32B
reuters.com
Turkish university annuls Erdogan rival's degree, preventing run for president
reuters.com
Preview: Amazon S3 Tables and Lakehouse in DuckDB
duckdb.org
Amazon to kill off local Alexa processing, all voice requests shipped to cloud
theregister.com
Nvidia Dynamo: A Datacenter Scale Distributed Inference Serving Framework
github.com
This is no world for an axolotl
english.elpais.com
Verification-First Development
buttondown.com
Spaceium Inc (YC S24) Is Hiring a Software Engineer
ycombinator.com
Microsoft quantum computing claim still lacks evidence
nature.com
The race is on to build the most complex machine
economist.com
Rust on the RP2350 (2024)
thejpster.org.uk
I'm all for splitting up the definitions of "test-first development" (TFD) and "test-driven development" (TDD), because I think for many forms of software development TFD is an anti-pattern that actively discourages people from writing tests.
Unfortunately this article appears to want to treat TDD as a sub-set of TFD. I'd like to redefine TDD to mean "you bundle tests with your implementation when you commit to source control" - where it doesn't matter if you wrote the tests before or after the implementation.
I write a lot of my tests after, often using snapshot testing. I get the key benefits of a robust test suite - protection against future changes introducing bugs that my test suite would have caught - but I don't go through the torment of trying to figure out how to test something that I've not yet even fully designed.