DEV Community: Andrew Colannino

How to harass your elected officials using TypeScript

Andrew Colannino — Mon, 20 Jul 2020 12:28:08 +0000

This post originally appeared on my blog, which you can read here in glorious dark theme.

Folks

Friends

Fellas and fellettes

As you all know, it's apocalypse season. Now more than ever, in times like these, in uncertain times, and in hard times - We all need to come together and harass our elected officials.

The US response to COVID-19 has been an abject failure, at each and every level of government. This is not controversial or interesting or technical, so I'm not going to write further about it.

Instead, lets shift focus to Gina Raimondo, and how I've made it my quarantine mission to bother her. You see, Gina is the leader of the small state of Rhode Island. Rhode Island fits into my internet narrative because, for at least one point in time, it had record low COVID numbers, relative to the rest of the country. It had succeeded in flattening the curve.

Enter Gina Raimondo. Gina saw these numbers, and thought they looked great. I agree Gina! Great numbers! On July 4th however, Gina decided to get bold, and started initiating "Phase 3" or whatever the hell. This phase can basically be translated into "hooray, corona times are over! party time!!!!! 🥳"

This is an obviously bad idea, especially with the rest of the country still floundering around in the COVID swamp like fools. I've been pretty frustrated by Gina's actions and statements, so I tried channeling that into something "productive"(?) with my dumb web app. It's an expression of my anger and pure bewilderment of this government, and I had fun making it. Let's talk about how I did it.

TypeScript is good and you should use it

When harassing your local government: type-safety is of utmost importance.

I shouldn't need to espouse the virtues of TypeScript to you by now. You've undoubtedly seen a trillion articles with the exact same premise. I'll just ask... If you're not using TypeScript in 2020: What's wrong with you?

To give a short explanation of what this even is: TypeScript is a "typed superset" of JavaScript. That's an overly complex way of saying that all JavaScript programs are also TypeScript programs. TypeScript is not a magical new language. It is just some really nice features and keywords slathered over JavaScript that, in my opinion, essentially "fix" the language and make me want to use it.

The biggest and boldest benefit of using TypeScript is the full intellisense you get inside of the VS Code editor. Intellisense is like autocomplete on your phone, except that it works. It brings the coding experience much closer to C#, in that methods actually tell you what the hell they want, and the editor will screech if there's a problem. This is unlike JavaScript, which often feels like coding in a feedback-less empty and silent bottomless hole of despair and doom.

"The only people who don't like TypeScript are the people who haven't tried it yet!" - me, 2020

A case study in bad corporate decision-making

Not everyone shares my beliefs. Pretend, for the sake of argument, that you are a high-level executive at a leading fintech company. A team of smart people in this company do some research for their next project, and decide to use TypeScript as their language of choice. Neat! I am very in favor of this, and so are the higher-ups who approved this team's choice. They start developing the app in TypeScript, enjoying the freedom and simplicity.

Enter the TypeScript-hating executive. This executive is not afraid to make his case against TypeScript to each and every engineer of the company. He does just this in a large conference call. His reasoning for why the team must switch back to plain JavaScript immediately are:

If you can't learn JavaScript you're bad and shouldn't be hired
Something something extra build-pipeline steps

Even though they did half the project in TypeScript, they were forced to strip away all their types. This story is, to me, a great tragedy, much sadder than whatever garbage Shakespeare ever put out. It genuinely upsets me that - because one high-up dude had a biased and incorrect understanding of a technology - a team had to stop what they were doing and make their software actively worse halfway through development.

My point with this big long anecdote is: Fight for the technology that you think is best. In this case, the people in this story did fight to use TypeScript, and still lost. Management sided with the executive here, and that's a shame. Thankfully for me however, my bad web app is a purely personal project, so I can just go nuts with it and do whatever.

Going nuts with it and doing whatever - Why I'm using Preact instead of React

For my UI layer, I'm using Preact instead of React. Note the all-important P here. This stands for petite, meaning Preact is a petite React. Essentially, it enables the same great developer experience of React, with the added benefit of getting to ship a much less bloated runtime to users.

Preact accomplishes this by doing away with a lot of the React cruft, namely the reimplementation of every standard browser event into "synthetic events". Facebook had a good reason to do this for React: They wanted to support legacy Internet Explorer, for all the Facebook grannies and gramps out there.

This is fine and well and "noble" I guess, but I think it's becoming rapidly unneeded to degrade your app by supporting legacy browsers. For the most part, everyone's switched to their phones, which usually come preinstalled with evergreen browsers like Chrome or Safari. Second, even if there are some stragglers out there on their old Gateway's running IE 6, we really need to draw the backwards-compatibility line somewhere, ideally before we go totally bonkers, like some people. My deepest condolences go out to all the Gateway fans.

Yarn good, npm bad

I'm using the Yarn command-line tool, instead of the more popular npm. I'd really like to ask you all, why are you still using npm in 2020? Yarn has a much more pleasant-looking CLI (command-line interface, pronounced like CLEE!), and to me, still feels faster than npm. Have you ever really looked at the output that npm spews all over the sacred console? It's a disgrace. The colors were chosen seemingly at random, whenever it does anything at all it flashes and SCREECHES, and it draws all sorts of ASCII art rectangles whenever something needs an update.

My complaints here seems arbitrary and stupid, and sure, I'll concede both of those points. However, to me, these things matter. I'm a "visual person", for whatever that's worth, so if I'm going to pick a CLI to stare at all day for hours-on-end, it better not look like ass. Like npm. Yarn has subtle, soft colors, smoothly-animated progress spinners, and the lock files look a lot cleaner to my eyes. Of course, you should never look directly at the lock files with your unworthy human eyes, but sometimes I like to check up on what the machine is doing.

Yes, it's maintained by Facebook, a very not good company. But guess what? npm is owned by Microsoft now, and they are also an organization that will burn in the corporate version of hell. It's 2020, and all your fav CLI tools are cancelled. Congrats!

Pair program whenever you can

In the grand-scheme of things, you don't matter. I don't matter either. Do pair programming. Or, do the much more extreme, but still great in its own way, mob programming. I have enough pop-off energy on this subject to write an entire blog series on it, but I won't do that now. Instead, I'll keep this section relevant.

I had an idea for something to implement - I wanted the COVID cases to count up over time, rather than immediately jump to the number on page load like it was doing before. My buddy was available to pair at the time, so we started working on the feature. I was a bit fried from it being 7pm after a long workday, and so was my co-programmer. However, we each melded our minds together to complete the feature. While we were both exhausted: I used my knowledge of the hooks API to get the timer itself working, and he used deductive reasoning to figure out that the animation should be exponential, rather than animate via pre-cached speeds like we had at first. The code we wrote that day is right here, and it really turned out great. I don't think it would have been possible using the traditional "everybody split up!" methodology of software development.

A younger, less-mature me would have been bummed that I couldn't figure out the exponential animation by myself. Now, 2020 Apocalypse Year Andrew knows better. I don't matter, and neither do you. The software matters. To make the best possible software, one must throw away their ego. Destroy your ego. Throw it in a box, and throw that box off a cliff. Into a fire. Acid fire. Where we're going, you won't be needing that.

Parcel good, webpack bad

In the end, everything had to be bundled together. TypeScript had to be transpiled down to JavaScript, source-code minified, and assets included into the mix. My bundler of choice was Parcel, instead of the more popular webpack.

Parcel is just webpack, but not a mess. I know it's comforting to use these "super simple CLIs" like create-react-app, preact-cli, or gatsby-cli, but I strongly advise you to reconsider. These all use webpack under the hood. Here's some recent footage I found of the average webpack config file.

What does this mean for you? And why should you care? Well, let's say you want to customize something in the bundler configuration, anything at all. Want to use ReasonML instead of TypeScript? Great, go nuts, I don't judge. Now, if you used create-react-app, you need to do something called ejecting. This is the equivalent of slamming the eject button in a helicopter and tumbling out of the air unto your inevitable splat. Don't do this.

Instead, just use Parcel. Parcel is more like... taking the train. It's pretty safe, probably not going to crash, and you don't have to pilot the damn thing. It just goes and goes, and all you've got to do is remember your stop. It's a "zero-config solution", or at least it tries its darndest to be. If you've got a TypeScript file, Parcel deduces that you like type-safety, so without any further developer action, it figures out how to transpile that for you. I think Parcel really tied my whole app together, and kept me sane while making it.

Conclusion

I mostly focused on the technical stuff here, because it's what I'm decent at, and it's fun. However, we should not lose sight of the person who brought us all together here today: Gina Raimondo. I hope all my bad internet posts catch her attention and annoy her. I encourage you to annoy her too. Please, actually, go do that. I think she is bad.

If you live in the US, you most likely also have an incompetent governor who is floundering the response to COVID-19. I highly encourage you to fork me on GitHub!, and make your very own web app to heckle local leaders with. They all could use a lot more of that these days.

How I struggled to build a Nextcloud server (and won!)

Andrew Colannino — Thu, 02 Jul 2020 03:22:08 +0000

This post originally appeared on my blog, which you can read here in glorious dark theme.

Why am I doing this to myself?

I really like taking notes. Notes are an extension of my stupid brain, which can't remember a damn thing on its own. All these notes were being stored on Google's servers, which didn't seem like the best idea. And it wasn't just notes. Pictures, videos, miscellaneous files, I was giving it all to Google for free.

Since my notes contain my bad ideas, and they are my bad ideas alone, I wanted to take back control of my data. After researching ways to do such a thing (through the Google search engine of course), my best option seemed to be a Nextcloud server.

Nextcloud has all the niceties of a Google Drive or Dropbox, but you host it yourself on your own hardware, and no one's allowed to snoop. This sounded great! This'll be so easy! I'll get this running in just a couple minutes!

Maybe you guessed it from the length of this article, but... this was not the case. Building and setting up this server was a nightmare hellhole, and I'm here today to share my hell with you, the reader, for free!

This isn't so much a guide or tutorial - more just me explaining (and venting about) the massive effort it took to set this damn thing up. I hope somebody someday learns something from my suffering, or is maybe just entertained.

The hardware

I had been interested in doing something, anything at all, with a Raspberry Pi for a while, so this was my excuse. Beyond that, I just followed this great article from a Pi magazine for my hardware choices. If you're wondering what hardware I used, look there. I copied it exactly. Plus, c'mon, look how cute everything looks stacked up like that! A literal "stack"! Ha!

One part the guide doesn't explain very well was the "USB powered hub" - both why you need one, and what that actually is. Is it a hub powered by USB? A USB powered by a "hub"? What is a "hub"? Maybe it seems obvious to you, and maybe I was just sleep deprived at the time, but I was having trouble wrapping my smooth brain around this concept.

Turns out, the USB hub is simply needed to provide power to the two hard drives, rather than the power going to the Pi and the drives. I have no idea if this was really necessary, but it makes me feel 10% more confident my drives won't crap out at any moment, and that helps me go to sleep at night.

RAID 1, or whatever that means

Here I was, all ready to go in fulfilling my long-held dream of running my own little server. Then my stupid coworker comes in, and asks "hey, what if your drive fails? what will you do then?" and ruins all of my fun.

He tells me I should do "RAID", which is apparently all the rage. RAID stands for "Redundant, Awesome... I dunno", and was invented on a whim by some random nerds in the 80's. To attempt to give an actual explanation: Using a RAID 1 setup means you get data redundancy, as it will constantly mirror the drives. If one drive craps out, the other drive will still have all the same data, so you just replace the broken one and go about your day as normal. The downside of RAID 1 is you're getting half the storage capacity that you paid for, but I figured 1 terabyte was large enough to store plenty of memes.

Setting up the RAID array was by far the most pain-free part of the process. Actually, it was the only pain-free part, the rest was pure suffering. I recommend doing this for fun if you're bored on a Friday evening. It's cathartic, and the only part of this whole thing that just worked.

All I had to do was run some cute little commands from the guide, and I was golden. I didn't fully understand the intricacies of everything I was doing, and the command-line interfaces for some of these programs were absolutely wild (press 'n' for a new partition, and 'p' for a "primary partition"? Really fdisk? Does this make you happy?), but other than that, it was all smooth sailing.

I should note - no one on the internet really cared to explain how a RAID setup should work with Nextcloud. Eventually I figured this out - the RAID array is seen by the OS as one device, so just politely ask Nextcloud to use that instead of the SD card. I ended up having to create a symlink from Nextcloud's data directory to a directory on my RAID device, but this wasn't the worst thing I had to suffer through.

Big Pixel Energy destroys my WiFi

So here I am, all proud and happy of my brand new Raspberry Pi running a fresh ~~Raspbian~~ Raspberry Pi OS. As I was setting up the RAID array, downloading lots of cute UNIX-style utilities, the WiFi starts to cut in-and-out. This has been a problem on my other main machines ever since I switched them to Linux, so I figured it was the mysterious Intel WiFi+bluetooth death bug plaguing me on yet another machine.

I did some more digging, and found what I believe to be the truth (or, as close as I'll ever get to the truth). There appears to be a widely reported problem with the Pi 4 where the signals coming out from the HDMI (which are shaped like squares?) are the same frequency(?) as the WiFi. So, if your display resolution is pumped up high enough, and that HDMI is cranking out lots of square signals, the WiFi gets totally borked. Neat.

This is clearly absurd, and I hate it. Hardware is bad, and everyone saying "programmers gotta learn hardware too!!!" should get off my lawn. At first I started following the internet's advice to simply "lower your screen resolution so the WiFi goes fast", but this became tiring on the eyes (especially with the added problem of not being able to use redshift on the Pi).

Even though I was reluctant to at first, eventually I started controlling my Pi via an SSH terminal from another machine to avoid this problem entirely. Boy oh boy, was this a joyful discovery. Not only was I freed from whatever stupid resolution the WiFi demanded, but I could also use my beloved blue-light filter to prevent my retinas from burning up. Sure, I had no GUI, but learning to do everything through the terminal came easily enough, and once I got there, I felt like some kind of computer wiz-kid.

The installation

After the RAID was set up and I got SSH going, it was time to install Nextcloud. This proved to be shockingly difficult. There can't just be a little sudo apt install nextcloud action, no no no no no. You need to install each little bit yourself, by hand, and glue every piece together (nextcloud isn't even in the apt repository, of course you have to download / unpack something called a "tarball" yourself).

Attempt 1: Snap!

Snap is Canonical's (maker of Ubuntu) locked-down little sandbox for Linux apps. The word "container" is thrown around when describing it, and I have no idea if that's correct, but I sure as heck wouldn't recommend the official Nextcloud snap.

The major selling point of snap is that it bundles together an application's dependencies, so it will just work on any Linux distribution. This sounds great! Sign me up! I'm lazy and hate installing my own dependencies! Who the heck wants to do that? Shell scripts, that's who.

Problem is, this doesn't really work on every distro, and in fact, it doesn't work on the latest Raspberry Pi OS. Do I know why? No. The Nextcloud snap failed silently before starting up, and it was too shy to tell me why. Cool.

Attempt 2: Some shell scripts I found

At this stage, I was still committed to being a lazy jerk. There's no way in heck I would manually install 30-something php modules by hand. So, I found a flashy looking site that claimed to have the scripts for me. It didn't work. The script took multiple runs to actually complete itself, and after the 5th or so attempt, it seemed happy. I went to the web GUI, told it to "initialize", and it kinda hung out there for a while. I went to take a walk, and when I came back and it was still pretending to initialize.

I found another official-sounding shell script, in a last-ditch attempt at being lazy. At least this script had the courage to fail immediately, as it's hardcoded to only work specifically on Ubuntu 20.04. Would have been real nice if it had told me that up-front, but hey, I'm not the one going through the trouble of writing all these (failing) shell scripts.

Attempt 3: The hard way

Being lazy clearly wasn't going so well. By now several days had passed, and all I had to show for myself was a whole terabyte of nothing. Worse yet, the shell scripts I ran had spread their little tentacles all over my pure OS install, so I knew I'd have trouble in the future if I left all that cruft in-place. I decided to re-image my OS, and that I would repeat the RAID setup once I got Nextcloud going.

As previously mentioned, the recommended installation wants you to install and hook each bit up together yourself. This approach made some sense as I learned (sort of, vaguely) more about how Nextcloud works - It's running on a webserver directly on your machine, handling all the networking and whatnot, with a full-on SQL database and lots of PHP magic happening too. So, it's understandable that Nextcloud has to spread it's mischievous claws in each and every crevice of your OS.

I followed the Nextcloud documentation, which sure does exist. In their defense, all of their software is free and open, including the docs, so I could have submitted any number of changes, and yet here I am selfishly writing this blog. The worst part of this process was the aforementioned php modules, which had to be installed one-by-one, and had mismatched names compared to the Debian repository. I had these all installed after about an hour, and I remember listening to a podcast in the background while suffering through it.

After apt installing every module (seriously, why doesn't php have it's own package manager?!), then gliding through the initialization of Nextcloud with occ, my server was working. The Nextcloud Hub web interface greeted me with the most pleasant design and animations I had seen in quite some time. It was over. I had won.

Conclusion

All in all, I sure did have a time. The admin page still won't stop whining about a "PHP memory limit". I don't even know what that means. If PHP is running out of memory, I wish it would just ask the OS for more. Really I don't mind, I've got plenty. I thought maybe they had some good reason for annoying me, but as I read more about the haphazardous history of PHP, I decided to change my mind. "I have absolutely no idea how to write a programming language", said the writer of the PHP programming language.

Maybe my takeaway from all this is that nobody knows how to do anything. I certainly still don't, but at least I now have a functioning home server with several gigabytes of memes loaded on it.

If you're new to Linux (or bash I guess), I'm not sure I'd recommend doing any of this. I had been using Linux on my main machines for the better part of a year, and have gotten sorta okay at using the terminal. Linux makes me smile, and plopping into an SSH terminal and clacking away at the keyboard brings me joy, but it might not do the same for you. I dunno.

If you like this post, you'll love my next one: How to harass your elected officials using TypeScript