Out of curiosity, I went and found the OrcaSlicer ticket where they’re working on adding the bricklaying feature to OrcaSlicer. Seems like they’re just hoping it doesn’t attract Stratasys’ attention.

Even if they have to remove the feature, it’ll still be in the history of the repo and it should be relatively easy to unrevert and rebuild personally on one’s own computer if necessary. Until the codebase changes enough to make it harder to maintain the fork.

Oh, I didn’t say I knew how to make that happen.

Democrats when they’re in power promoting places like Puerto Rico and DC into states definitely wouldn’t hurt, though.

Also, theoretically Trump getting less and less popular is probably helping its chances.

And more awareness of the existence of the pact is definitely beneficial.

Whether it’s likely to happen even if the above all happens, who knows.

It’s way past time to get the National Popular Vote Interstate Compact to 270.

Stratasys still has a patent on it

That’s putting it generously, isn’t it?

This video from a year ago goes into why the patent they have today isn’t valid. (Short answer: prior art. They patented it in 1995 and that expired in 2015 in the U.S. and 2016 in Europe. Then they re-patented it in 2020, which isn’t really something they can do, but the patent office granted it anyway, probably unaware of the prior patent. There’s kindof a “new claim” in the later patent, but there’s prior art for that as well in the form of a 2019 feature request on PrusaSlicer’s Github.)

I get that Stratasys has lawyers and money and might theoretically be able to win even a case with as little merit as a patent case regarding that 2020 patent would have. But I’m not sure I’d go so far as to say they have a (valid) patent.

Lemmy.

Nobody’s said “this is going to be my year” in many many years.

Mom wanted me to go into music performance. I went into computer science both because “holy shit how cool is that” and to get out of music performance.

My alma mater had three computer departments: CSC/CompSci, CIS/Computer Information Systems, and Graphic Design. I’ve never been artistic, really, so I didn’t have a lot of interest in Graphic Design. But I didn’t know the difference really between CIS and CSC going into college.

I went to the head of the CIS department to ask about the difference and he was like “CSC is about building the plane, CIS is about flying the plane.” Misinterpreting that to mean CSC was about hardware and CIS was about software, I thought I wanted CIS. When I met with the CSC head, he met with me in a little lab in the CSC department. And on the shelves on the walls, there were robotic coin sorters and Lego robots and stuff. And that’s basically when I realized the CSC department was my people.

If your elephant needs pain relief, make sure to administer Tylenol orally.

Sulfer should be labeled “hell”.

At least in my peer group, people hated Voyager when it was running too.

Two books I started reading knowing I’d disagree with the author:

• Introduction to Austrian Economics. That school of economics is helpful as a model for understanding economics, though only through the lens of an idealized system. The same way that understanding how a point-like mass moves helps you understand how a canon ball moves. But then it goes on to say that your inalienable/natural right to safety in your person is basically the fundamental property right from which all of what the anarcho-capitalists call “theory” directly derives. Which makes it rather circular. “Property rights ∴ property rights.”
• The Singularity Is Near by Ray Kurzweil. I knew my reaction to it would be visceral, but defending DRM was the last straw. I finished the Austrian Economics book. But I didn’t get a quarter of the way into the Kurzweil book before rage quitting.

Follow Scrum, Lean / Kanban, or eXtreme Programming to the letter, and let your team focus on the product.

This.

But invest in learning how to do it right. Hire agile coaches to help and listen to them. “Agile theater” helps no one and only breeds hostility to any attempt at improving the process.

🙄

Why you gotta do my man Mandelbrot like that?

Finally I can get a leg up in Pass the Pigs.

How long is this kind of shit going to go on before we start having a serious conversation about making “limit dependencies” a widely-agreed-upon fundamental security practice? Right along with “validate your inputs” and “encrypt sensitive data” and such.

I pronounce it “AUR” of course.

Oh good. Missouri in the national news again. :\

Java, Postgres mostly but also LDAP and random in-house-written RESTful services, almost 20 years.

• The objects we store in the Postgres database are very “hierarchical” in nature, with one top-level object and lots of child/grandchild/great-grandchild objects. (We asked for a Mongo database but the infra team at the time said "make do with Postgres.)
• As I mentioned, some of that hierarchy is in LDAP or RESTful services, not in Postgres, so we needed something capable of dealing with multiple storage backends that would stitch the objects together as necessary. So the “ORM” needed to have backends for multiple backend systems.
• We knew clients would need a vast number of different queries. So we made a RESTful endpoint that gave the full power of the ORM to (authorized) clients. If they needed different data, we’d be like “change your query like this” and they didn’t have to wait on us.
• Early in the project, we consciously designed an extensible JSON representation of our hierarchical objects. That is what’s returned from the aforementioned RESTful endpoint.
• However, we also created a “shortcuts” system to allow us to “balance” how much of the logic lived on the server vs in the client. (It can mix and match. Like “apply this shortcut, but also filter this way and paginate” or whatever.)
• We made the API of the ORM such that it could both be used to query from the database/LDAP/RESTful systems, or be used as a client SDK for the aforementioned RESTful query endpoint that the application exposed.
• It’s both “more than an ORM” (querying from non-database sort of backends) and not fully an ORM (read only, doesn’t handle schema evolution.) But it’s fair to say it’s more “an ORM” than “not an ORM”.
• The implementation of the Postgres backend part of it is heavily inspired by Django’s ORM.

We couldn’t have pressed Hibernate into this use case. It doesn’t really deal with hierarchical data and sure as hell doesn’t know how to query from LDAP. I don’t know that anything existed at the time (nor am I sure anything exists now) that would fulfill our use case.

And the alternative to what we built was a massive, unmaintainable DAO with ridiculous numbers of individual queries in it that would have to be modified or added to endlessly every time someone needed to filter a bit differently or whatever.

This was a developed-in-house e-commerce web application at a major e-retailer. So fortunately that monstrosity of a cookie-handling mess was only ever used by one company.

You know what, though? Talking about this reminds me of another story about the same e-commerce application.

After a customer placed an order on this e-commerce site, the company’s fraud department had to evaluate the order to make sure it wasn’t fraudulently placed. (As in, with a credit card not owned or authorized for use by the purchaser.) Once that was done, the order had to be communicated to a worker at the warehouse so they could pack the right items into a box, put on a shipping label, and set the box aside to be picked up by the UPS truck which would come once a day near the end of the day.

The application used by the fraud department and the application that displayed new orders to warehouse workers was one and the same application. Whether a user had fraud-evaluating powers or pack-items-in-boxes powers just depended on what permissions their particular user had. (That may have been decided by LDAP groups. I don’t remember for sure.)

Meanwhile, the e-commerce site offered gift cards for sale online. The gift card would be shipped to the customer. And there was a box where you could write a message associated with the gift card. So, for instance, someone could buy a gift card to be sent to their nephew’s address or whatever and include a little note like “Happy Birthday. Don’t spend it all at once.” or whatever. And the fraud/pick-and-pack application would display all details of the order including any messages associated with the gift cards.

Well, I found a stored cross-site scripting vulnerability where if you put <script>...</script> tags with some JavaScript in the gift card message box and completed the order, the JavaScript would execute any time someone viewed the details page for the order in the fraud/pick-and-pack application. And of course, the JavaScript could do within that application just about anything the user could do with their given permissions.

The main danger was that a malicious actor with sufficient knowledge of how our fraud application worked could place an order fraudulently with someone else’s credit card and include in the order a gift card with a malicious JavaScript payload in the message box, and then that malicious JavaScript could automatically mark the order “a-ok, no fraud here” when a fraud department worker loaded the order details page, letting the order be fulfilled without any actual fraud review.

The fix was pretty simple. Just stick a <c:out>...</c:out> in the appropriate place in the fraud/pick-and-pack application code. But it was an interesting example of a vulnerability in a not-customer-facing application that could none-the-less be exploited by any public customer/user without any particular special access.

If you’re interested in one more interesting story about the same e-commerce application, see this comment I made a while ago.