I think I just went through the 5 stages of AI grief.

At first I was thinking no way an AI can just whole cloth generate an app. I’d actually tried before using other tools, but this time I was using Cursor which if you don’t know is basically VS Code editor with AI built into it. Turns out it pretty much did exactly what I’d asked it to, with only a few revisions needed.

This on some levels kinda made me a bit angry. It seemed it really was as good as all the vibe coders (still hate this name) were claiming. Of course, this was still a really simple concept that I had asked it to do. It was not a simple straight app though, I had asked it to make a Chrome extension. I wasn’t expecting it to work so quickly.

So, I bargained that this would simply help me Get Things Done faster. I have ideas, I can’t afford to hire people to help me out and I can’t do it all myself. So now I have a tool that can help me create all the apps I want in record time. Net win for me, right?

But as I went through it some more, I started to realize I was instantly dependant on it. This kinda made me depressed in that I still knew how to create an HTML form element and hook it up with Javascript and everything else, but that I didn’t want to anymore. I wanted the AI to do it in 10 seconds instead of taking minutes to do it myself. And I felt like well that’s it for humans right? The AI can do it faster and we’re lazy.

And then it started happening: I was asking it simple things and it just failed to do it. I asked for a text box to set the name of the saved tabs. It couldn’t do it even after several promptings. It made the box, sure, but it wouldn’t save the name or display it in the dropdowns. I asked for a checkbox to set whether to close all the tabs after saving them. It failed repeatedly to do that as well. At least I was cognizant enough to have used Git from the start to save things when they worked, so I could just revert back. Because I am an experienced developer. I actually did that a few times. I’ve now accepted that, properly used, the AI can save time and crank out boilerplate code, and boot up a new project quickly. But the devil is in the details and that requires experience and knowledge still.

The 5 Stages of AI grief was originally published in The Subversive Maker on Medium, where people are continuing the conversation by highlighting and responding to this story.

Some years ago I used this wonderful thing called Dreamfactory. It was pretty awesome as it let you design your database schema (giving you multiple types of databases you could connect to. I used MySQL) and then quickly and simply just generate an API to access it.

It was also neat in that it made doing your authentication and user tracking easily. It also supported multiple front end applications if that’s what you wanted. You could quickly spin up a server using Bitnami or Docker and have your backend up and running in minutes.

It was all open source. Emphasis on “was” because at a certain point they essentially crippled the open source version, requiring you to pay up for the basic stuff like the MySQL connector. I went back to check it out because I wanted to use it for a new project and thats what I discovered.

Now, I don’t begrudge them trying to make money. We’re all trying to do that, right? And to be fair, their license (apache 2) allowed for this. And all the previous code is still there (https://lnkd.in/g3CdUHDC) if anyone wanted to pick up that ball and run with it.

So far, it doesn’t seem like anyone has done so. But I think there’s still potential there. I don’t know of anything modern that quite fits the bill like DreamFactory did. Maybe I just haven’t seen it yet. I was checking out Supabase, which seems close. And I have/am using Firebase for some projects. But I miss Dreamfactory…

Full disclosure: yeah, I used AI to make a dumb image to head this article…

Some years ago I used this wonderful thing called Dreamfactory. was originally published in The Subversive Maker on Medium, where people are continuing the conversation by highlighting and responding to this story.

Because I love fixing mountains of really bad CSS that only works superficially and breaks in almost any other situation.

No, really, I do, because it means I can write articles like this one. After spending a week fixing the issue.

Look, I get it. Somebody before you implemented something and you just cut and pasted and perpetuated the mistake endlessly without thinking about it.

And maybe it even made some sort of perverse sense back in ’02 when it was done as a hack because CSS just wouldn’t behave the way they wanted it to. I’ve been there. Believe me. And I’d probably chew myself out for doing it if I had a time machine…

So today’s adventure in bad CSS is this:

If you’re going to use something, read the fuckin documentation first. Like, seriously. It’s not that hard.

Point in case, Twitter Bootstrap and its grid layout. This probably applies to numerous other similar grid layout systems. If you are going to use it, then please use it correctly.

The problem I encountered was the use of the col-* classes. Two problems actually. One was in using a ‘col-12’ just to get an element to be 100% wide. This on the surface isn’t necessarily that terrible, if used correctly. Which leads to the second problem. Which is not using them correctly inside an element with a ‘row’ class.

Yeah, just throwing a col-12 (or worse, ‘col-md-12 col-lg-12 col-sm-12’) in there might get you want you want at first and seem simpler than going through all the trouble of adding a class with a “width: 100%” on it. But that’s where the chaos begins.

I asked ChatGPT about it:

Using Bootstrap’s col-* classes without a parent containing the row class can lead to unexpected and undesirable layout and spacing issues in your web page. Bootstrap's grid system is designed to work within a specific structure, and not following this structure can cause problems. Here's why it's not recommended:

1. Padding and Margins: The row class in Bootstrap contains negative margins that offset the padding applied by the col-* classes. If you don't use the row class, you might encounter issues with spacing and alignment. Columns might not line up correctly or have unexpected gaps between them.

2. Clearing Floats: Bootstrap relies on the concept of clearing floats within the row class. Without the row class, you might encounter float-related issues, where elements might overlap or not position themselves as expected.

3. Responsive Behavior: The col-* classes in Bootstrap are designed to stack vertically on smaller screens and form a grid on larger screens. Using them without the row class might disrupt this behavior and make your layout look inconsistent on different devices.

4. Alignment: The row class is essential for aligning columns properly. If you skip it, you may have trouble vertically aligning columns and ensuring a consistent layout.

5. Maintainability: Following Bootstrap’s grid structure makes your code more maintainable and easier for other developers to understand. Deviating from the recommended structure can lead to confusion and difficulties when working on the project in a team or revisiting it later.

Yeah. It’s not wrong. And it said it in a much nicer, non expletive laden manner than I wanted to. Did I mention I spent a week fixing these?

I experienced all of these issues. Because of the improper use of (ie, not using) row classes, there were subsequent weird issues with padding and margins, not being responsive, etc.

But the biggest issue was the floats not being cleared. Which leads me to the other big issue: directly using floats on everything for the wrong reasons. Especially using float on a 100% wide element.

All these floats everywhere and not clearing them anywhere led to the situation where it was not possible to determine in the code how tall everything was. This meant I could not determine if something was visible after scrolling. Which means I cannot optimize things, or display something when the scrolling got to the bottom. Or even just properly show the scroll bar, and eliminate multiple scroll bars. Scrolling bad. See first rule of Website Design Club.

Again, I asked ChatGPT for some wisdom (and therefor some text to bloat up this article. I’m shameless).

Floating elements that are 100% wide can lead to unexpected and potentially problematic behavior in your web layout. While it’s not inherently “bad” to float 100% wide elements, you should be aware of the following considerations:

Collapsing Parent Elements: When you float an element with a width of 100%, it can cause its parent element to collapse, meaning the parent element may have a height of zero. This can result in content overflowing outside of the parent element or overlapping with other content on the page.

Overflow Issues: When a 100% wide element is floated, its width can extend beyond the bounds of its parent container. This can result in horizontal scrolling, which is generally undesirable on most web pages.

Responsive Design Challenges: Floating elements with fixed or 100% width can make it challenging to create responsive designs. On smaller screens, these elements may not adapt well, leading to layout issues or content that doesn’t fit within the viewport.

Float Clearing: To address the issues created by floating 100% wide elements, you often need to use additional CSS to clear the floats. This can add complexity to your CSS and make your code harder to maintain.

Negative Effects on Accessibility: Improperly floated elements can negatively affect the accessibility of your website. Screen readers may not interpret the content as intended, and users with disabilities may have difficulty navigating your site.

Inconsistent Behavior: The behavior of floated 100% wide elements can be inconsistent across different browsers and devices. Some browsers may interpret the float differently, leading to inconsistencies in your layout.

Again, totaly on point. Everything was collapsing making the heights all 0. You can’t make an infinite scroller that lazy loads new content if you cant determine how high everything is and calculate when the bottom is in view.

So to summarize:

1. Don’t blindly keep doing what you’ve seen others do. Read the documentation.
2. Don’t use col-* without a containing row.
3. Don’t float things unless you need to. Use clear afterwards if you do.

Oh, and, start using Flexbox. It’s pretty universally available now. To be fair, it wasn’t in 2015 when all this floating and col-* shit started. See 1.

Adventures in really bad CSS was originally published in The Subversive Maker on Medium, where people are continuing the conversation by highlighting and responding to this story.

Being an opportunist is not necessarily a bad thing. Case in point for this silly idea that happened just yesterday, a rorschacht blot thing using GPT. And unlike a lot of other ideas we have, I took this one and ran with it. The story goes something like this…

The morning started off the way it frequently does these days, with a discussion about asking Chat GPT to do things we probably shouldn’t be asking it to do, and for which it rightly refused to do.

Being as I am like most people an opportunist at times, I made the suggestion that we should start registering domain names with GPT in them. I started with some names I thought of, and quickly saw they were already registered and available for sale for 5 figures or more. Clearly we were already late to this idea.

Catgpt was suggested, but I had already seen that one done at cat-gpt.com. A few others went by. And then the magic happened. Somebody suggested blotgpt.com, a site that horks up rorschacht gpt blots.

I thought well, that sounds easy enough. So I checked. And the domain was available, and only $3. Why not. Lets do this. For the actual code, since rorschachts are essentially random by design, there was no need to have an AI render the image. But, I could ask ChatGPT to generate the code for me.

A few minutes later and I had a functioning website. After clicking on the image a half dozen times I got the one at the top of this article. I posted that into the chat as proof and the person who started this asked if we are both insane because we are seeing the same thing?

Over the next few hours I continued with chatGPT trying to refine the output with no success. This was interesting to me because AI more or less nailed it the first try, and as I tried to get it to generate a better algorithm I became a little frustrated. Overall it still saved me time and probably allowed me to try many other methods each saving me time on implementation. I was also able to show the code to my son, who is nowhere at the point of being able to write something like this from scratch, but he could read it and generally understand what it was trying to do.

In the meantime, the image I posted led to a tangential conversation about Blotman. He’s like Batman but his only power is that he looks like a different Rorschach blot to everyone who sees him. His name just happens to be Rorschacht before the terrible accident happens that turns him into Blotman. Naturally, I had to plug these ideas into chatGPT to generate a story treatment.

By the early afternoon, after getting my favorite Smashburger lunch at the casino, I had registered the domain name blotgpt.com and pointed it at my hosting at hostgator.com. And viola, I was done.

In retrospect, if it weren’t for chatGPT I probably would not have followed through on this idea. Surely I could have wrote this myself, in maybe an hour or so, maybe longer given that I haven’t used the HTML canvas that much and would have had to read the documentation or google it. And if I would have tried all the other ways of generating the image (polygons, filled line paths, trying to figure out how to mirror the image left to right, etc) it probably could have turned into an all day thing. Knowing that up front, I probably wouldn’t have even bothered. ChatGPT got me up and running with this rorschacht GPT idea in literally 10 minutes.

Blotgpt.com Day 1 was originally published in The Subversive Maker on Medium, where people are continuing the conversation by highlighting and responding to this story.

Certainly none of this is new and for all I know I am unintentionally plagiarizing some old website from a decade ago, but these occurred to me recently when looking at some design elements in an app I use.

So here it is, the first four rules of Website Design Club as they occurred to me off the top of my head when looking at this incredibly badly designed app.

First rule of Website Design Club: Don’t Scroll

Don’t make people scroll. Like seriously, DON’T MAKE THEM SCROLL. I mean it. Do anything you can to avoid the need for scrolling. This is bad on a desktop and even worse on a mobile device. Now I know you have to scroll to show content that won’t fit, of course. And sometimes scrolling is better than, say, making them flip through pages like in a book (see rule 3). Scrolling is particularly egregious when its navigation though, which is the case in the design that I am going on about.

In this case, there is a sort of side bar with a bunch of search and filter settings. Ok, not necessarily bad there. However inside this thing are several settings that are lists. A couple types of users, some status options, etc. Most of them are shortish (5–15 things) but some of them can be huge, like the users. If I click on a user the list of potentially 100 or more expands out, and the only way to close it back down is to scroll all the way to the end and click Show Less. Also the whole content area also scrolls (and is mostly blank). What the hell?

Second rule of Website Design Club: Make it easy to click a target

This is one part of Fitts’s Law. You want people to click things, right? So make it easy to click things. Don’t make the target smaller than it needs to be. It’s not cute, it’s just hard to use. The bigger it is, the easier it is to hit. This should be obvious but it’s amazing how often apps have tiny icons or buttons that are hard to click on. Its worse on a mobile device when all you have is fat finger to try and mash the button (and not hit other things nearby). And here’s a hint: you can even make the target area bigger than the visual que. Its ok. Nobody’s going to complain. Just don’t put all your targets right up against each other in most cases, visually… but the “hit box” can butt right up against the next element (just make sure they get an equal amount of extra area). If it takes even a fraction of an extra second to get your pointer or finger into just the right spot, it’s going to slow the user down and frustrate them. It literally causes mental pain when you have to think about how to hit that target.

Third rule of Website Design Club: Make the target close by

This is part 2 of Fitts’s law. Of course there’s only so much you can do to keep things close together. The extreme of this would be to stack every button on top of each other so you don’t have to travel anywhere to ge to the button you want. But then you’d have to cycle through them. That of course doesn’t work either. But then we do that sometimes, like with windows that overlap. If you had a desk you’d spread your papers out, but you would keep them as close as possible along with your calculator or other tools. Nobody wants to reach over a large table to get to something constantly. Why make somebody do that in a website? Case in point the design in question. Not only does it require constant scrolling just to see things, but then you have to travel all over the place to get to the button you need (Show More and Show Less). This is why scroll bar arrows started being placed next to each other instead of at either end of the scroll bar.

Fourth rule of Website Design Club: Minimize clicks

Here’s a dirty secret. Nobody wants to click. If they had it their way the website would just know what you wanted to do and just do it. So clicking (or tapping, to be inclusive of mobile) is a necessary evil. Keep it to a minimum. In the design here, I have to click to see more of a list, then click again (after probably needing to scroll and locate the click target) to close the list. If I want to select something in that list, I have to click on it first. Then close the list. Then scroll back to where I was. God Damnit.

Fifth rule of Website Design Club: Keep things in the same place

If you can’t even find the target easily, that’s a problem. If things are moving around you can’t develop muscle memory to get to the target and click. It’s also visually confusing. It can literally give you a headache as you try to visually track where things are so you can be prepared to mash that button you know you are going to need next. When things are scrolling around, or boxes are expanding and contracting and the buttons and links are constantly moving that all adds up to mental and physical overhead you don’t want the user experiencing. God forbid the sequence is something that might have to be necessarily repeated a few times in a row. Something that should happen quickly from memory does not.

In conclusion: Design is not just Make It Pretty

So there you go. This design breaks all these rules and probably more I haven’t even thought of yet. Its awful. It was designed by a graphic artist who does not understand real UI/UX design. It was implemented faithfully by programmers who either didn’t care, or didn’t think twice about the usability of the design. Furthermore it’s being perpetuated in another part of the system as a matter of fact without reviewing if it’s really the way to go. Ugh.

5 Rules of Website Design was originally published in The Subversive Maker on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the biggest things that makes me insane code wise is when I see something done twice (or more) when it should have been done once.

Case in point a recent experience where I was asked to add an important bit of new functionality to a feature that had frankly languished for a couple years. For some reason a customer had gotten all hot and bothered over this feature and demanded this new functionality. It had been on the roadmap originally, but the feature was done as an “MVP” and never worked on since.

In the original design of this feature, it was implemented at the level of “I read a tutorial on how to do this”. That was the front end. The back end repurposed something that was never meant to be used in this way, but the developer of that bit had to his probable chagrin made it clean and flexible enough to be bastardized into something he had not intended.

But back on the front end, it had a requirement that it be a screen accessible from the primary navigation. Ok, great. That was done and it worked well enough. There was also the need for it to work as a floating popup window. And there lays the problem. The second developer working on the popup decided to just make mostly new UI code for this. It was never in parity with the full screen version and had issues.

And this is why you reuse code. Not only just to save you time, but to eliminate situations where something should work the same but it does not because its different code. You will invariably have differences. And this sort of thing will frustrate end users because to them it looks the same.. or it should.. but it doesn’t work the same.

I have seen code duplicated verbatim. So it might work and look the same at first but invariably it will diverge. Now you have to fix things in multiple places and hope you got it right.

Since I was tasked to add this new functionality and after looking at the code I realized I would have to write it twice, I decided that I had to fix the previous developer’s lack of vision.

To this end I refactored the full screen code as it worked much better, and I completely ditched the popup code. Since this is Angular, I had to refactor the code to use auxiliary routes and make the styling work properly. I wrote code to embed that component in a popup.

Now I have one code component that works in both places. Yes, this took more time to do, but it resulted in a much better and more consistent UI. Taking that time to think things through and using the framework features to my advantage made for a better product.

Just before hitting the finish line, I was asked if this could be also done not just as a popup but as a completely new browser window. Because I had already refactored this properly, I was ready for this request. A simple search of NPM packages yielded one that could pop out an Angular component into a window. And viola!

I am confident that had this other developer been given this task they would have failed, or at the very least, produced a bunch more unmaintainable buggy duplicated code and technical debt.

Because nothing is ever truly done, I have now been asked to also make this feature embeded into a different part of the app with its functionality linked to another feature. Since I have already done this refactoring, its ready to go for this new functionality. Again, a less forward thinking developer would probably again copy/paste or write new code to do the same thing again. I have seen it happen many times.

This is one of things that separates a Code Monkey from a Component Monkey.

Code Reuse. It’s a thing. was originally published in The Subversive Maker on Medium, where people are continuing the conversation by highlighting and responding to this story.

So I’ve told this story many times to many people over the years, but never thought to actually write it down in any form.

This would have been early high school, or maybe even jr high. I don’t remember exactly. It was Michigan, in the mid 80’s.

Now, I’ve never been great at math. I am pretty slow to solve problems and there are some things I just never got well. It was much harder with teachers who did not have patience to teach it well. Such was the problem with this one particular teacher.

He would just scribble things down on the chalkboard, cancel this out here… write this there, see, easy? No sir, not easy. I didn’t understand the logic and he offered no explanation as to why you do it that way. It was just here, cram this method down your throat and don’t ask why.

I would gradually fall behind and get only a C grade in the class. Meanwhile at home I was programming just fine, including doing trigonometric calculations. Mostly I knew that because my dad explained it once years before and it made sense.

So of course, I wanted to take the programming class. They were using Apple IIc’s a DEC minicomputer of some sort. It was required to get my math teacher’s approval to take the programming class, which he denied me.

I went instead to the programming teacher and asked if I could take the class anyway. I told him I was doing programming at home. He did not want me using the DEC, but I was allowed to use the IIc’s. I believe his justification to letting me in the class was to learn things like word processing, and other applications on the Apples.

Now of course, I had to be a quiet rebel in this class. For instance, I wrote a simple mad-libs program. You know, where it asks you for a number of words of a specific type and then it creates a story from a template with the words inserted into it. Its quite funny. At least we all thought so. As the other kids started printing out the generated stories, using the line printer with green bar tractor feed paper, my teacher got pretty pissed. I guess the paper was not cheap back then. I think he traced it all back to me and I got in trouble. Or at least some sort of stern talking to.

In another case, we were tasked with writing a circle drawing algorithm. I knew how to do this already using sin() and cos() but I also knew it was incredibly slow. Also most people did it with a simple loop over x or y, but this left gaps in the line. I used an algorithm I borrowed from a magazine I had for my Sinclair which showed a way to draw a solid circle using only basic integer math and no trig functions. It was like a zillion times faster. My math teacher was like what is this? It’s not trig. He was unhappy because I did not use the trig functions.

Flash forward a few years (ahem..) and today I am a professional software developer. So I say, to you, math teacher who’s name I wish I could remember, fuck you.

Dear algebra teacher: f*ck you. was originally published in The Subversive Maker on Medium, where people are continuing the conversation by highlighting and responding to this story.

I can’t imagine being the kind of person who is not constantly inventing things, or thinking of new projects to build, or coming up with other ideas for things to create whether its an app, a story, or whatever. I’ve been doing it since I was a self aware humanoid, from around 7 years old maybe?

Of course, I had not had the foresight to log all these ideas. Much less blog about them or otherwise write them all down (I mean, there were no such thing as blogs back then). Now of course I do have notebooks, graph paper pads, etc with ideas drawn out, from when I was pretty young.

Since I decided to build a single canonical list of my ideas, I figured, well, I might as well go back and log all the previous ideas and half completed projects I’ve had. And so I figured, they should all be numbered.

Starting from 1, though, for some current idea, seemed wrong. And since my 7 year old self didn’t write down his first idea with a big “#1" on it, well, what number do I start with? Of course, I could now get distracted by the idea that if I just had a time machine, I could go back… ok, I mentally digress. Stay on target.

Lets say that, conservatively, I probably have one reasonable idea a week. Its probably a lot more than that, but one idea a week that’s worth writing down. Over the span of my conscious life, that’s what, maybe just over 2000 ideas? 2000 is a cool number. Let’s start with that!

Of course, most of those ideas never came to fruition. Which is why I want to log all my ideas and then consciously decide yes, I am going to work on that, or no, I’m backlogging that one — but it’s there for future reference.

The other aspect of this is that I think I want to blog about these many ideas I’ve had. I have a lifetime of nerdy ideas and projects that may not interest anyone (unless you find an 8 bit multiprocessing computer interesting..) but it would help me sort out all that mental backlog of ideas and projects.

This could be at once both depressing at the number of ideas that never happened, but also, perhaps inspiring for the ones that did come to pass. And maybe, hopefully, I’ll get refocused on the current viable ideas.

I’m already hitting this blogging thing pretty well.

How many ideas have YOU had? was originally published in The Subversive Maker on Medium, where people are continuing the conversation by highlighting and responding to this story.

So my second resolution, and honestly I think I’ve probably promised myself to do this before, but hey, lets try again, is to make a single big list of all the things in my head. I actually have a few such lists. I have some lists in Google Keep. I have my Trello board of projects. So I have been doing better at this.

But the bigger part of this is that, I should have a single list. A simple, easy to access list. Then I can go through and estimate each thing for time, money, etc. Finally I could then choose a small number of them and decide these are the ones I am going focus on doing to completion. I could decide to even just focus on one single thing at a time, but I am not sure I can be that laser focussed.

Naturally, this immediately leads to a few of my app ideas. If only I had an app to help me manage this list. If it had such and such feature it could make things better for me. And maybe other people as well. So maybe I should make that app first. You can see where this leads. I end up not doing anything at all because I’ve gone down the rabbit hole and that lead to 10 other things and now my head is full of things and I can’t get anywhere. I’ve blocked myself.

No, I need to back that up. Back to the list. Use whatever tool I have available for now. Add these app ideas to the list.

Write the list. Prioritize the list. Make estimates. Then decide what ones to focus on. And then log my work on them even if it’s just time spent thinking about them. Make notes. etc. And if I am not going to work on the prioritized items, then I should re-prioritize the list explicitly.

I already have a sort of workflow. Often I use Google’s Keep app because it’s super simple to use and syncs between my phone and desktop. So I will note an idea in there. But I also have a Trello board for ideas and projects and to track their actual progress. So I will “promote” the idea into a card in Trello. I’ve also got a Mindmeister “mind map” of software ideas that I haven’t touched in a long time. I’ve just lacked discipline in actually maintaining these things and updating them daily.

What I haven’t done is make a single point of reference, and I have not expressly prioritized and picked the ones I actually want to make sure I work on. So thats my goal. Narrow down that list, and start/finish actual things.

We’ll see how it goes.

Resolution #2: the big list was originally published in The Subversive Maker on Medium, where people are continuing the conversation by highlighting and responding to this story.