aes

joined 1 year ago
[–] aes@programming.dev 6 points 1 week ago

"Thanks for sharing your story, which nobody knew to ask for", perhaps?

[–] aes@programming.dev 8 points 3 weeks ago (1 children)

The second part sounds like a thing phones should already be capable of, if it weren't for trying to charge for something. Or snoop on me. Or something worse I just haven't thought of.

Enshittification is such a downer. Oh, well, guillotines will fix it eventually, I guess.

[–] aes@programming.dev 2 points 3 weeks ago

So close! Get one that does poached eggs. It's basically like an ice-cube tray, but the cells are bigger so they fit a whole egg. Only downside is that you need to be quite precise when filling the water. (We use a kitchen scale and measure it to the gram, but it's perfect every time)

The exact model we have is the Cuisinart CEC-10, but I'm sure there are others.

[–] aes@programming.dev 2 points 1 month ago

https://open.spotify.com/episode/3umFrR0Bpu1fmXpO1PzDdh?si=NPMlzRCtTZGakiuikO8GEw

This. So much this.

I'm a member of Sveriges Ingenjörer. Fortunately, I've never needed serious union help, but it's probably because the background threat is more than enough. And the salary statistics alone are worth the dues!

[–] aes@programming.dev 7 points 2 months ago

Axioms are not like the others, they're assumed to be true even before considering any evidence or even arguments.

[–] aes@programming.dev 2 points 3 months ago

Yesss... You're not wrong, but I really do believe the solution we want is to be found somewhere in that direction. Considering the Google graveyard, the faang crowd isn't all that reliable either.

[–] aes@programming.dev 3 points 3 months ago (2 children)

This is a somewhat surprising position to see in the fediverse...

(I mean, I get what you're saying, and I guess someone should bring that to the party, but there is s different way)

[–] aes@programming.dev 2 points 3 months ago

Sounds reasonable, but a lot of recent advances come from being able to let the machine train against itself, or a twin / opponent without human involvement.

As an example of just running the thing itself, consider a neural network given the objective of re-creating its input with a narrow layer in the middle. This forces a narrower description (eg age/sex/race/facing left or right/whatever) of the feature space.

Another is GAN, where you run fake vs spot-the-fake until it gets good.

[–] aes@programming.dev 2 points 4 months ago

Well, Rust has a lot of string flavors, and I like utf-8 being the norm, but there are a bunch of cases where enforcing utf-8 is a nuisance, so getting string features without the aggro enforcement is nice.

There's probably some fruity way to make this a security issue, but I care about ascii printables and not caring about anything else. This is a nice trade off: the technical parts are en-US utf-8, the rest is very liberal.

[–] aes@programming.dev 6 points 5 months ago

Protein / calories, and glycemic index, right. There are a few other considerations, but primarily these, for me

[–] aes@programming.dev 2 points 5 months ago (2 children)

Rust implementation of the Meta-II meta compiler. I used bstr, which was interesting.

[–] aes@programming.dev 1 points 6 months ago* (last edited 6 months ago)

Backstage has become quite misaligned to what we were originally trying to do. Originally, we were trying to inventory and map the service eco-system, to deal with a few concrete problems. For example, when developing new things, you had to go through the village elders and the grape vine to find out what everyone else was doing. Another serious problem was not knowing / forgetting that we had some tool that would've been very useful when the on-call pager went off at fuck you dark thirty.

A reason we could build that map in System-Z (the predecessor of Backstage) is that our (sort of) HTTP/2 had a feature to tell us who had called methods on a service. (you could get the same from munging access logs, if you have them)

Anyway, the key features were that you could see what services your service was calling, who was calling you, and how those other systems were doing, and that you could see all the tools (e.g. build, logs, monitoring) your service was connected to. (for the ops / on-call use case)

A lot of those tool integrations were just links to "blahchat/#team", "themonitoring/theservice?alerts=all" or whatever, to hotlink directly into the right place.

It was built on an opt-in philosophy, where "blahchat/#team" was the default, but if (you're John-John and) you insist that the channel for ALF has to be #melmac, you can have that, but you have to add it yourself.

More recently, I've seen swagger/openapi used to great effect. I still want the map of who's calling who and I strongly recommend mechanicanizing how that's made. (extract it from logs or something, don't rely on hand-drawn maps) I want to like C4, but I haven't managed to get any use out of it. Just throw it in graphviz dot-file.

Oh, one trick that's useful there: local maps. For each service S, get the list of everything that connects to it. Make a subset graph of those services, but make sure to include the other connections between those, the ones that don't involve S. ("oh, so that's why...")

 

Hi. I'm at a complete loss, so...

Background: 4.0.3. A 3D "fps" world, with the usual capsule shape suspect protagonist. I'm adding a SubViewport, and a Camera to render onto a Decal with albedo set to a ViewportTexture from the SubViewport.

I can (sort of, unreliably) make it work in the editor, but never in the game(!) With transparent bg, it's just invisible, without, it's black, and if I pick the icon.svg instead, that works. The (inner, well, both actually) camera is active, and I've fiddled with Clear Mode and Update Mode on the SubViewport. (and every other setting I can think of)

In the editor, rendering both camera view and a label on top works, both in the SubViewport texture view, and on the Decal in the 3D view(!)

What am I missing?!

view more: next ›