Cyberdog

I'd argue that the "toy language" concept was well in place on '80s computers. You could get into BASIC easily and do stuff, but if you wanted to do complex games or fast graphics or anything non-trivial, you had to learn assembly - BASIC was the "toy language."

Assuming you're serious for a moment, I don't think AI is really a practical tool for working with big data.

- The "hallucination" factor means every result an AI tells you about big data is suspect. I'm sure some of you who really understand AI more than the average person can "um akshually" me on this and tell me how it's possible to configure ChatGPT to absolutely be honest 100% of the time but given the current state of what I've seen from general-purpose AI tools, I just can't trust it. In many ways this is worse than MongoDB just dropping data since at least Mongo won't make up conclusions about data that's not there.

- At the end of the day - and I think we're going to be seeing this happen a lot in the future with other workflows as well - you're using this heavy, low-performance general-purpose tool to solve a problem which can be solved much more performatively by using tools which have been designed from the beginning to handle data management and analysis. The reason traditional SQL RDBMSes have endured and aren't going anywhere soon is partially because they've proven to be a very good compromise between general functionality and performance for the task of managing various types of data. AI is nowhere near as good of a balance for this task in almost all cases.

All that being said, the same way Electron has proven to be a popular tool for writing widely-used desktop and mobile applications, performance and UI concerns be damned all the way to hell, I'm sure we'll be seeing AI-powered "big data" analysis tools very soon if they're not out there already, and they will suck but people will use them anyway to everyone's detriment.

Very good take. CSS is at a point of complexity now where you can't really blame anyone for not knowing everything you can do with it or every new feature that's been adopted in the last couple years, especially for full-stackers like me. I know a lot, including more than enough to get my job done, and though I will still learn new things now and then (I didn't know container queries existed before this article and now that I do I may use them in the future), I'm not in a hurry to learn every new bleeding-edge feature which are probably just going to cause compatibility issues for some non-insignificant number of my clients' browsers (or my clients' clients' browsers) anyway.

Also, as someone who started doing web dev professionally nearly 20 years ago where if it didn't work in IE 6 then you just couldn't use it at all, I just instinctually don't even bother with new (as in 3-4 years old) CSS or JS features most of the time. It's pretty deeply ingrained in me and I suspect many other devs who were around in that time. That said, 5-year-old CSS and JS specs at this point are pretty damn good and you can do a whole lot of cool stuff with them, so this is not nearly as painful now as it was back then.

Good enough is good enough.

From what I can tell it's because some of these "edge" service providers will expect you to give them a WASM binary instead of a PHP script.

The other caveats about "edge" throughout this discussion aside, if I needed to do this, I'd try to write something in Zig or (gag) JS or something else that compiles to WASM directly rather than writing a script for an interpreter that runs under WASM.

Agreed. I don't have faith they can make a usable device if they can't make a usable web page.

Never break, take over, or "fix" scrolling! Never!

I remember when "compute" was a verb.

For those in the western hemisphere, local time zone adjustment means that midnight on 1970-01-01 GMT becomes some time in the afternoon or evening of the day before.

Mac Source Ports is such a wonderful site. It looks like we'll never be a first-class gaming platform again for 99% of major games but at least the projects hosted on this site increases the depth of the back catalog we can play, and it's great to have them all collected in one place.

I found it boring and incredibly pretentious, and it's possible to suddenly die for seemingly random reasons - for example, I dropped the game after examining a parked car caused me to die. I don't remember the details as to how the game justified that because I was pretty fed up with it at that point.

If you really want another game with Fallout 1-like gameplay, check out Atom RPG. It's currently $6 on GOG so it's probably for sale on Steam too. I got stuck on that one too when I got to a point where my melee-focused build was causing me to get blasted to bits before I could even touch my enemies in a crucial part of the game, but at least I had dozens of enjoyable hours of gameplay before I got to that part.

For people wanting to use BSD in desktop systems, they arguably are. For those like me who primarily use it in servers, they’re not.

I wonder if another solution would be for channels broadcast a subchannel which has more frequent i-frames, but lowered resolution and framerate to compensate for it in terms of overall bandwidth. When you surf, the TV could first hit up the subchannel, get the low-rez i-frame, and start showing a lower-quality version of the channel's video feed much faster, then start working on fetching and decoding the "real," full-resolution video feed and switch it over when it's ready. It still wouldn't be as fast and perfect as it was for analog and it'd require some industry collaboration and a bit of new hardware, but it still should be a more pleasant experience for people who just want to quickly see what's on.

Could you elaborate? Why would a pilot not know when to turn their engines on, and why is the timing not obvious (eg, "when we want the airplane to move")?

Please move to every country on the planet and replicate your work there.

Pathologic, a Drupal module which uses some simple heuristics to find and correct broken links and image paths in content which might happen because the content was migrated between servers, the URL of the server it was hosted on changed (such as when they started using HTTPS - early versions of this module predated the "all sites must use HTTPS" idea), the content used relative paths but was being viewed in a context where a full URL was necessary like a feed reader, etc.

It came about when I was working on the site for a local newspaper where the writers would work on articles using an internal copy of the site which would then be migrated to the live site when published, but when they linked to other articles, they would often copy-paste the URL of the article as it was on that internal site, causing a broken link when the article was published. Rather than try to teach a bunch of crusty journalists what relative paths were, I just wrote a bit of code to fix those URLs for them. With the client's permission I later cleaned up and open-sourced that module.

At its peak it was installed on over 70,000 Drupal installations that we know of (not all of them reported usage data). It's still being developed, though by other developers in the last few years as I have lost interest (and client work) in Drupal, but I'm still quite proud of it, and I still love to hear from people who say it was a must-have for their sites and made their lives so much easier.

https://drupal.org/project/pathologic

As a web developer of 17 years, I'm dumbstruck at the idea that you're making three times as much doing this as you did at a damned defense contractor. They must have been totally chumping you.

My marriage.

But for real, the first full-time programming gig I had was at a place that displayed huge tables of stock prices or something like that - I don't recall the exact data or why we were providing it, but I do remember the problem that I was assigned to solving: the tables of data were so large that on modest computers and those newfangled smartphones, system performance would drag to a crawl.

I was tasked with solving this problem, but not tasked with solving it in a particular way. This would have been around 2007, so IE 6 was the primary target, and if jQuery was out yet, it wasn't widely used yet.

After a good deal of experimentation, the solution I came up with was kind of ridiculous - the page would load the table, then remove all but the first two screen-heights of rows and replace it with a single row with a CSS height parameter set to the sum of all the other rows in the table. As the user scrolled through the table, rows of data were added below the existing rows while the footer "megarow" was shrunk, while a header "megarow" was created and set to the height of rows of data that were removed. The experience was flawless if you didn't scroll too fast or use the home/end keys, but even if you did you just saw a flash of an empty table row before the correct rows were loaded into place. It worked really well.

Anyway, that took up the bulk of my first three weeks working there before some higher-up took a look at the books and decided they needed to start laying people off in reverse order that they were fired - which I guess makes sense if you don't want to be bothered to do an evaluation of someone's skill, but still, it was pretty offputting to lose my first real dev job that way. To this day I have no idea if that code ever saw production - the product was an expensive subscription service so I had no way of checking up on it inexpensively.

Fortunately I was able to rebound and get another dev gig through a friend of my stepfather, and I've continued to hack away ever since.

Well… yes, of course those things are copyrighted. I'm a bit surprised you didn't foresee that issue.

But still, it sounds like you learned a lot about Stripe and that other API. Those are good skills to have. If nothing else you've padded your resume quite strongly, so the project wasn't entirely for nothing.

What I meant was that two redwood forests in the Pacific northwest will look very similar to each other at the ground level. If you want to find another forest which looks similar to the one that the Star Wars scene was filmed in, they're all over the place.

Okay, my fault for forgetting where I was posting. What I meant to say is this:

When you are amongst the trees, one redwood (sequoia sempervirens) forest located in or near Humboldt County, California, looks very similar to any other redwood (sequoia sempervirens) forest located in or near Humboldt County, California, unless one forest or the other is very new growth or very old growth or similar extreme circumstances, and assuming you visit the two forests at roughly the same time of year.

The decking in the article was rhetorical. And I admit I was speaking exclusively of the forests in northwestern California. I have no idea what anyone does in British Colombia.

They all have value in the environmental sense, but in terms of hiking and camping and sightseeing, it's pretty hard to tell one forest from another once you're among the trees. (Maybe there's an idiom along those lines.)

If by "redwood forest" you only mean old-growth forests, sure. The trees being harvested commercially today are only a few decades old. Second-growth and managed forests won't have the occasional ancient giants the old-growth ones have but they are still clearly forests to the humans and other animals living among them.

I suppose if you had a fondness for that particular arrangement of trees, yes, it's sad they're gone. But there are other forests in that area which look practically identical to what you saw in the movie, believe me, just waiting to be hiked through and camped under. Some of them are literally in city parks.

I remember the day that my dad told me that tourists actually came to Humboldt to see the trees. Boring old trees? Really? Having grown up among them I didn't understand how unusual they were yet.

And lumber for other parts of houses as well, and wooden furniture, and paper products. And since trees in managed forests are grown denser than they grow naturally, a thicker, more carbon-capturing forest was planted in its place.

If it was a commercially-managed forest, it's a bit dramatic to say it was "obliterated" any more than a cornfield gets "obliterated" when the corn is harvested in the fall. Tree seedlings would have been planted in the field soon after the wood was harvested.

The days of lumberjacks going into virgin forests to harvest wood in that area are over - it's all either national parks or other protected forests which might get thinned for fire management reasons but never clear-cut, or managed forests that periodically get harvested and replanted, just like corn and wheat. (Source: I grew up in Humboldt County and still have family there.)

Agreed. “Google is good and Microsoft is evil” is a take from two decades ago.

What is the point of using a query builder if you’re only going to support a single RDBMS? Why not write straight SQL and avoid the unnecessary abstraction layer? Is the query builder really going to be easier to learn to use (particularly for non-trivial queries) than SQL?

Hopefully they had comprehensive test coverage. That would have helped greatly in that regard.

OmniWeb was great! Loved the vertical tabs. I wish Safari supported them. My screen is far wider than it is tall and vertical scrolling is a natural movement, darn it!

I used iCab (the Mac port of CAB) for a few years in the early '00s since it had a very good balance of features and resource usage. It's still around but it's been rewritten to use WebKit so there's not really much point to it anymore.

http://icab.de