No, just all I want to tell you about.

I vibe code Brainfuck using Eliza.

Lemmy.

“This instance” being lemmy.world?

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.

The famous violinist. Yes.

Honestly, still better than working sick with an office full of coworkers.

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.

Paid for by Nvidia.

(Joke. Maybe.)

Bacon, cheese, or peanut butter?

Why all the downvo- oh shit this is an AI-generated image, isn’t it?

(Seems like the shoelaces are fucked up, the buttons are kindof inconsistent, the eyes are a little weird.)

Yeah, in that case it gets a downvote from me as well.

No, the ketchup goes on the keys and the fries on the touchpad.

Too bad you don’t have a CD tray. I’m guessing that’s why you didn’t order a drink.

Share an example or two?

If you’re a software engineer, memorizing an ASCII table (particularly the hex numbers of each character code) is definitely helpful. If for no other reason than so that you can read things that are randomly written in binary without having to consult a table.

Something not really otherwise terribly useful that nonetheless helped me keep my sanity: learn how to convert to base64 in your head. At work, we had really boring 8-hours-a-day training for a couple of weeks. To pass the time, I came up with random strings to base64 encode in my head. “Hat is 48 61 7a. The first six bits are 010010 which in base64 is an S. The next six bits would be 000110 which in base64 is G.” Etc. I’d write down the base64 strings character by character as I derived them and then check my results for errors when I got back to my desk.

How to convert various units of measurement. (Including between imperial and metric.)

2.54 centimeters in an inch. Degrees Fahrenheit is nine fifths of degrees Celsius plus 32. Stuff like that.

deleted by creator

Are rear view cameras really “fancy” these days?

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.

Never roll your own ORM

I’ve done this. Probably 10 years ago. Even today, I maintain the same application that has the ORM in it that I designed. If I could go back in time and do something else, I’d do the same thing again. Honest to god. For my use case, I feel it was warranted. It was risky, but it worked out surprisingly well.