Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "re-configuring"
-
Shouting to my chromecast for more than a week because it kept crashing.
Factory reset -> total 1h re-configuring, works perfectly again. One hour was all that was needed.
I know the list with alternatives comes now, but I really see this as the perfect device. Does exactly what I want.
Damn, this experience made me violent as F.2 -
So, I've had a personal project going for a couple of years now. It's one of those "I think this could be the billion-dollar idea" things. But I suffer from the typical "it's not PERFECT, so let's start again!" mentality, and the "hmm, I'm not sure I like that technology choice, so let's start again!" mentality.
Or, at least, I DID until 3-4 months ago.
I made the decision that I was going to charge ahead with it even if I started having second thoughts along the way. But, at the same time, I made the decision that I was going to rely on as little external technology as possible. Simplicity was going to be the key guiding light and if I couldn't truly justify bringing a given technology into the mix, it'd stay out.
That means that when I built the front end, I would go with plain HTML/CSS/JS... you know, just like I did 20+ years ago... and when I built the back end, I'd minimize the libraries I used as much as possible (though I allowed myself a bit more flexibility on the back end because that seems to be where there's less issues generally). Similarly, any choice I made I wanted to have little to no additional tooling required.
So, given this is a webapp with a Node back-end, I had some decisions to make.
On the back end, I decided to go with Express. Previously, I had written all the server code myself from "first principles", so I effectively built my own version of Express in other words. And you know what? It worked fine! It wasn't particularly hard, the code wasn't especially bad, and it worked. So, I considered re-using that code from the previous iteration, but I ultimately decided that Express brings enough value - more specifically all the middleware available for it - to justify going with it. I also stuck with NeDB for my data storage needs since that was aces all along (though I did switch to nedb-promises instead of writing my own async/await wrapper around it as I had previously done).
What I DIDN'T do though is go with TypeScript. In previous versions, I had. And, hey, it worked fine. TS of course brings some value, but having to have a compile step in it goes against my "as little additional tooling as possible" mantra, and the value it brings I find to be dubious when there's just one developer. As it stands, my "tooling" amounts to a few very simple JS scripts run with NPM. It's very simple, and that was my big goal: simplicity.
On the front end, I of course had to choose a framework first. React is fine, Angular is horrid, Vue, Svelte, others are okay. But I didn't want to bother with any of that because I dislike the level of abstraction they bring. But I also didn't want to be building my own widget library. I've done that before and it takes a lot of time and effort to do it well. So, after looking at many different options, I settled on Webix. I'm a fan of that library because it has a JS-centric approach. There's no JSX-like intermediate format, no build step involved, it's just straight, simple JS, and it's powerful and looks pretty good. Perfect for my needs. For one specific capability I did allow myself to bring in AnimeJS and ThreeJS. That's it though, no other dependencies (well, at first, I was using Axios because it was comfortable, but I've since migrated to plain old fetch). And no Webpack, no bundling at all, in fact. I dynamically load resources, which effectively is code-splitting, and I have some NPM scripts to do minification for a production build, but otherwise the code that runs in the browser is what I actually wrote, unlike using a framework.
So, what's the point of this whole rant?
The point is that I've made more progress in these last few months than I did the previous several years, and the experience has been SO much better!
All the tools and dependencies we tend to use these days, by and large, I think get in the way. Oh, to be sure, they have their own benefits, I'm not denying that... but I'm not at all convinced those benefits outweighs the time lost configuring this tool or that, fixing breakages caused by dependency updates, dealing with obtuse errors spit out by code I didn't write, going from the code in the browser to the actual source code to get anywhere when debugging, parsing crappy documentation, and just generally having the project be so much more complex and difficult to reason about. It's cognitive overload.
I've been doing this professionaly for a LONG time, I've seen so many fads come and go. The one thing I think we've lost along the way is the idea that simplicity leads to the best outcomes, and simplicity doesn't automatically mean you write less code, doesn't mean you cede responsibility for various things to third parties. Those things aren't automatically bad, but they CAN be, and I think more than we realize. We get wrapped up in "what everyone else is doing", we don't stop to question the "best practices", we just blindly follow.
I'm done with that, and my project is better for it! -
A normal day on my CMS as a Service...
URL: https://go to CMS
> Login screen: enter credentials, check checbox "remember me" (which doesn't remember you)
> redirected to SSO (single sign-on welcome page)
> Re-enter URL to go to CMS
> Fires up second browser on second screen, do the exact same things as above
--- Code editing
As it's a very modern CMS, you have to edit the code via the CMS using a bulky and honestly shitty editor (or rather: they didn't spend time configuring it to be at least semi-decent).
Plus default white horrible theme.
> Go to "/themes"
> Scroll all the way down the page
> Enter filename in search box
> Click the "Edit" button, which is a small button located right next to a much bigger red "DELETE" button. When you middle click (as I always open files in new tabs) on the DELETE button, it DELETES without confirmation. In such cases, you lose up to three days of work asking the providers to set it back up for you via their backup - and charge you for that. So sorry for deleting an *important* file
> Edit the file.
> Save the file - it takes 3 seconds. Upon saving, rescroll again to where you were in the code.
> On the other screen, refresh dev view of current template
> Wait 5 seconds
> If there are any special blocks, they all load via a semi-synchronous AJAX request (it's async, but they load one by one), the same time you waited to refresh your page.
> Notice you forgot adding some markup
> Re-edit the file, save...
> OH NO - I'VE BEEN BACKGROUNDEDLY DISCONNECTED. Back to Login page.
> Enter credentials.
> Am not on the CMS, but on the SSO
> Navigate back to file
> Re-write new changes
--- Manager comes in:
I need to you edit XXX objects in DB Manager (a big PHPMyAdmin if you will)
> New tab, go to https://DB
> Although still connected on CMS, I have to re-enter credentials
> Am redirected to SSO
> Re-enter https://DB
> Find the object (20 seconds of loading)
> Find the appropriate field
> Find out the field is in fact another object located elsewhere
> Uff, thank goodness, there's a shortcut button to directly edit said elsewhere object
> Operates on elsewhere object + save
> Re-edits original object + save
> ERROR 500, APPLICATION UNEXPECTEDLY CRASHED
:') painful much?
(for those who ask: yes i've got plenty of mind-reflexes in order to minimise losses)2