Show newer

Hi there. Please if you see this toot boost for helping our new Trans Safety Network instance federate across the 'verse.

Oop, looks like I've been out of the C++ game for long enough that I forgot some fundamentals. ;)

CoderPad does support `unique_ptr`; you have to ` <memory>` to pull it in because C++'s std lib is carved up into a bunch of smaller headers.

It's been awhile!

Show thread

Anyone familiar with the CoderPad environment:

Is there anything special one must do to access `std::unique_ptr`? I'd expect that to be available but it seems to be missing from their C++ environment.

Hypothetically speaking, I can see no obvious reason copyright law cannot be extended to exclude from "fair use" the injection of images into a machine learning engine without consent of the copyright owner of the image.

This will need to be done carefully, because if the goal is to throw a wrench into Stable Diffusion and its siblings, that wrench can easily ping-pong into e.g. banning Google from creating ContentID fingerprints to protect artists from copyright abuse. Some specific dimensions to pin down:

- what is a machine learning engine?

- what does it mean to train one on an artist's work?

- what does 'consent' look like? How explicit must it be?

Implementation will be messy but it's always messy; this is copyright, there's no other kind of implementation of copyright. "...other nations have thought that these monopolies produce more embarrassment than advantage to society" (Thomas Jefferson). But it may be a good idea if we have no alternative that protects the livelihoods of artists in a world where everyone is now a mediocre visual artist.

... And, of course, US copyright law has no bearing on China's law. Nor Russia. Nor dozens of other countries. So we would have to be prepared for our entertainment industries paying top-dollar for human labor competing on the international stage with a sea of mediocre artists that cost electrons and little else.

When you want to update a LaTeX document with some information provided on the command line.

blog.fixermark.com/posts/2022/

General thought:

I fear the possibility GraphQL is a trap. I think, in principle, it's a good idea. In practice, I'm concerned that pretending one can offer a pretty flat access to the underlying data in a backend store ignores some irreducible complexity in the question of data storage and retrieval.

How easy is it, in general, to build a GraphQL query that is expensive to answer because it skips all the indexes the backing database supports? I don't know; I've only worked with one or two GraphQL APIs. But one advantage to REST and RPC is that since you have to be intentional about creating new procedures or new resources, you have to be intentional about creating indexes.

Can modern DB engines compute those indexes based on usage patterns or is it still a very manual process?

I think full-stack engineers consistently underestimate the benefit of the entire stack being in as few programming languages as possible.

Fortunately, now that TypeScript exists that doesn't place an onerous burden on the backend architecture.

Followup on previous thoughts.

When I speak of "Test-driven development," I'm usually thinking of unit tests and integration tests. I think building those out before you have a concrete implementation tends to be putting the cart before the horse. They're most useful as regression tests to make sure you haven't broken something important when you make changes in the future.

Test-driven development can be quite valuable for end-to-end tests if you can get the client to agree on what the software is supposed to do in the form of a walkthrough of the behavior. I still tend to put this alongside or slightly after the initial design (most clients I work with aren't abstract system thinkers, so it's real hard to get them to understand a design they can't see and touch), but getting the client to agree that their initial ask matches to a test script of the form "User goes to A, clicks B, enters C, should see D happen" is a form of test-driven development when you implement a program to satisfy that script.

... but I still tend to keep that script hand-written before wasting the cycles on automating it in code.

Broadly speaking, a few principles guide my software engineering these days:

* Automated tests: Great, must-have, let you make guarantees about what your software will do, write them and have them.

* User stories: Great, must-have, make sure you're writing the correct thing, make them and implement to them

* Test-driven design: Terrible, big waste of time, borderline anti-human practice, assumes omniscience. Don't stress about this; just write code.

The story of College Technology University part 2, where plans are slightly derailed because people are involved. personal-blog.fixermark.com/po

It's weird / funny to me how comfortable I've gotten in TypeScript, to the point that I prefer it over Java consistently. Not an outcome I would have predicted, but Microsoft does have a knack for building and maintaining good languages.

It's the hundred little things, like the fact that TypeScript constructors are (a) named "constructor" (one fewer thing to change in a refactor that renames the class) and (b) have a syntactic shortcut for passing in arguments that do nothing but get retained in the object state. Every time I write Java and I have to pass in a Foo named 'f' so I can write 'foo=f' in the constructor body, I die a little inside.

Mark's principle of sufficient comments: Any meta-programming demands comments to demonstrate how to use it in the language you are meta-programming on top of.

In which I convince a bunch of players to accomplish goals for me by roleplaying a college dean.

personal-blog.fixermark.com/po

This represents a not-insignificant part of my career.

A lot of the stuff we see on Mars could easily be transplanted into an Earth desert.

But from time to time, she reminds us she's an alien planet with one third of Earth's standard gravity.

sciencealert.com/check-out-the

I've been trying to get back to at least as much control theory as I understood in my college days, and this is a pretty neat explainer of the notion of stable vs. unstable control systems (what they intuitively mean, without diving headlong into the math of how we get the systems model to tell us if we're looking at a stable / unstable one).

jbconsulting.substack.com/p/yo

Show older
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.