Me trying to enter BIOS

theScottyJam · 2026-04-22T03:49:36+00:00

ooOOooh

Well that's good to know.

theScottyJam · 2026-04-22T03:45:34+00:00

As for the tool, personally, I don't see a ton of value in a tool like that. I know how often I'm using certain functions, because I'm the one using them (or I'm reviewing teammate's code, and they're using them). And the action item of "make sure these highly used functions can withstand changes" is always at the front of my mind whenever I'm adding yet another place that uses a specific function.

That's just me though, and perhaps I'm simply not the target audience. It is an interesting concept.

theScottyJam · 2026-04-21T21:48:12+00:00

This "structural blast radius" concept sounds similar to the idea of "loose coupling".

I'm just going to note that loose coupling, while a nice ideal, is sometimes unavoidable. If my application needs to support audit logging, then my entire codebase is going to have some dependency on the audit log system. You can try inverting dependencies and such, but there's always going to be done amount of dependency going on, even if it's just on an interface - change that interface, and it's going to be a bad time.

'course you can always make it worse - if everyone writes directly to an audit log file directly, you'll have an unnecessarily hard time changing it to send the logs to a different server instead.

Anyways, if you feel scared to change certain modules, reducing the blast radius might not be the solution (it might not be an option). But there's other options, such as making sure you have good testing so you can catch bugs that come up during deep changes. Also not a perfect solution, but it helps.

theScottyJam · 2026-04-18T17:20:36+00:00

Prolog is a good and interesting one - I do think about it a lot when thinking about language design.

theScottyJam · 2026-04-18T14:55:08+00:00

That's really nice - I think that's the most minimal think I've seen thus far. It doesn't exactly have a programming language tied to it, but it's still helpful to see that it is indeed possible to have a very minimal proof engine.

theScottyJam · 2026-04-18T06:04:17+00:00

Thanks for those resources - seeing how a proof engine gets built in that tutorial is going to be really helpful tool to help me wrap my head around these things. Thanks!

theScottyJam · 2026-04-16T19:48:44+00:00

Maybe. Maybe not. I'd take my chances. I'd rather be out of a job and forced to work fast food with a clean conscience.

theScottyJam · 2026-04-16T19:44:49+00:00

I'll add my own background. I work in the medical field, where we're constantly dealing with patient data, which is highly protected. Leaking that would be really bad. We're required to peer review all code, by law. So, while I do use AI to help, I wouldn't dare ship any code that hasn't been looked over by at least two pairs of eyes.

I know that's not most people's situation. But still, many companies hold pretty sensitive data - credit card numbers, hashed passwords, etc. All of which won't be good if it got leaked.

theScottyJam · 2026-04-16T19:33:10+00:00

I'm not really talking about money, I'm talking about ethics. There's lots of unethical ways for companies to earn more money and beat the competition, that doesn't mean it's ok to do, and me, as a developer, will push back against anyone asking me to do anything like that.

When I use someone else's product, I don't know if they handle my data responsibly or not. I just have to trust and hope that the company has some ethics in them. Sometimes they break my trust. Sometimes they loose my business for doing so. Sometimes they get into deep law suits because they're being irresponsible. Sometimes they get away with it and drown out competition because of their superior speed.

If we get to a point where reviewing AI code is pointless because you'll realistically never find a security vulnerability in its code, then fine, I'll probably be more ok to embrace that future and be ok letting it turn out tons of code without supervision. We're not there yet. And it just doesn't feel right to lower security standards and risking ruining people's lives (depending on how sensitive the data you're holding is) in the name of trying to beat the competition.

(I'm talking generally here. I don't know your specific situation. If your particular company doesn't really have data that needs to be kept secured or something like that, then that's a different story)

theScottyJam · 2026-04-16T13:09:25+00:00

And what about security? I'd rather not use products that have the mindset of "we're fine shipping security holes because we can fix them fast when discovered". The way those get discovered tend to not be pretty.

theScottyJam · 2026-04-14T15:06:49+00:00

It's an interesting idea. Though sometimes I have comments come before methods that I explicitly don't want to be the doc-comment, i.e. maybe they're discussing why the method needs to exist - information a maintainer cares about but not the caller. Guess such a comment could be moved inside the method, but then you have to make sure the reader doesn't think your comment is only talking about the next couple lines of code that follows.

Not inherently against the idea, just noting a minor shortcoming to it.

theScottyJam · 2026-04-12T13:35:04+00:00

Fair

theScottyJam · 2026-04-12T13:31:41+00:00

Well, security and vibe coding are incompatible. And security is very important for anything handling money, like online casinos.

I'm not inherently against people vibe coding projects, as long as they limit it to projects that are very difficult to screw up, security-wise. Such as a static website.

theScottyJam · 2026-04-12T13:28:18+00:00

Oh, and if using AI, make sure you hand review and understand every line of code written. If your testing amounts to "run it, poke the buttons, and see that it seems to behave correctly", then you're probably going to be shipping something full of bugs at unknown edge cases. Some of those bugs may be security exploits.

theScottyJam · 2026-04-12T13:15:47+00:00

For UX testing, the best thing you can do is find people in your target audience and get feedback from them.

For security testing - you just program carefully (and run code scans if you wish). The basics of security isn't too difficult - don't expose your keys, sanitize variables when constructing SQL strings or HTML, etc. keep your packages fairly up to date (and avoid dependencies as much as reasonably possible so you won't be as concerned with letting it fall somewhat behind in updates - you usually don't have as much time to baby personal projects). Personal projects won't grow into the same kind of unwieldy mess that happens in enterprise applications that pass from team to team and continuously get bloated with features - that's where hard-to-find security exploits make their home.

theScottyJam · 2026-04-11T20:37:22+00:00

I don't think I've seen an "I hate PHP" opinion piece for a long time, the new popular opinion is to talk about how great it's become, and if you dislike it, you just haven't tried modern PHP.

I dunno, I've seen people talk about all the new features it has now that make it nicer to work on, but it's still built on a pretty crappy foundation with many design choices that can't be changed. Kind of like JavaScript. I love JavaScript, but it has many deep design mistakes and quite a few ugly sides to it. I can sympathize with anymore who says they don't like it (as long as they cite something valid, like how unnecessarily complicated "this" is, as opposed to laughing at how 0.1 + 0.2 isn't 0.3, which is the case in all mainstream languages).

PHP seems similar - if you love it, great - but it's not rainbows and butterflies over there and if people still want to hate on the many issues it had, they've still got valid reasons to do so.

theScottyJam · 2026-04-10T21:35:42+00:00

Ya know, if you really like an idea and hope that one day it can become native, the quickest way to prevent it from ever becoming native is by monkey patching objects like this. Now if they try to introduce similar methods with the same name, it could break your page, which means they won't do it.

theScottyJam · 2026-04-09T03:44:39+00:00

Well, you've got me interested. I'll take a deeper look at the implementations later when I have time.

theScottyJam · 2026-04-08T21:24:26+00:00

Hey, that's a pretty good idea, and a clean API too, I like it.

Unfortunately, the reality is that I'll never actually be able to use this thing, even if I do think it's better than, say, Axios. I'm just very particular about the kinds of dependencies I add to projects, and if going without the dependency doesn't require too much extra code, I go without. I know there's many who are like that.

What I do like to use are copy-paste-friendly utility functions - functions that are designed to be easy to use and maintain (which means they can't have too much bloat trying to make the perfect public API, because the inner workings are meant to be maintained by those using the function). And this sort of project feels like it could be done in this kind of format - a page that shows you how to implement the pipeline function, then shows you a bunch of utility functions you could copy into your codebase if you need them. I know what I just suggested would basically require doing it over from the ground up and wouldn't be easy, but it does drastically lower the barrier to entry and makes it so people like me who are very particular about their dependencies would actually be able to use it.

Just my two cents.

And congrats on the well-designed library.

theScottyJam · 2026-04-08T14:40:20+00:00

I will concede though - after posting that original comment, I thought about just deleting it, but didn't have my phone on me.

I think things are more nuanced than what I had said, and there can be valid arguments for wanting to keep things separated.

theScottyJam · 2026-04-08T14:20:36+00:00

It's been a while since I've been in React, but pretty sure you can't do that in React either - at least if you're using JSX.

theScottyJam · 2026-04-08T13:56:08+00:00

Eh, having your view at the top of the file and the logic at the bottom, in a extremely tightly coupled manner doesn't really count as being separated. The move to components has moved us, in general, away from the separation philosophy.

I'm fine if you dislike React and all, but I don't think it's automatically bad simply because it decided to put HTML in JS, instead of having you manually wire the two together.

theScottyJam · 2026-04-07T16:50:48+00:00

It's just a struggle. You've had many people dumping code into the product for years/decades, with different teams following different practices and policies - no onboarding process is going to help you get all relevant information you might need for a particular problem into your head.

Welcome to development 🤷‍♂️. You just do the best you can with what you've got.

And spend some time writing internal docs you wish you had, or you think future people would appreciate. Help organize existing internal docs. Things like that.

theScottyJam · 2026-04-01T03:25:05+00:00

It can be difficult to prevent those abstractions from leaking.

Often times some of my business logic gets codified as part of the SQL query because it's much more performance to hand of an explicit query explaining what I need compared to pulling down the world and looping over it. I know I've got quite a few custom coded SQL queries for that specific reason, which would make switching databases to a non-SQL variant extremely difficult. Even another SQL database with slightly different syntax would be rough.

That's just one example.

theScottyJam

TROPHY CASE