This past summer I set up a little 6-dollar-a-month Ditigal Ocean linux server to run crons jobs for different coding projects like my Plug-N-Play Twitter Engager and some stock analyzer scripts. It was a pretty barebones server instance so it took a bit of work to get into production-ready state. I've tried to compile the steps here so others (and future me) can reference it for a quicker setup. ?

I solved a ClojureScript error today, and after getting stuck with a strange error and scouring the internet for information I ended up on this Github issue thread where I had been asking for help on this exact issue almost 2 years ago! Well then, that seems to me like a great candidate for a blog post! So, in this post I'll show you how to get past the XMLHttpRequest Error that you might encounter when building a ClojureScript Lambda function that makes an http request! By the way, you can check out the full source code for this project here. Alright, Let's go!

This is something that often trips up newcomers to Go who are familiar with JavaScript. I think it's pretty fascinating to notice whether different programming languages decide to do things in different ways, and it's interesting that the concept of "constants" is so different in Go Lang and JavaScript. has an extremely strict definition

It's crazy that 12.13.0 is now the latest long term support version of nodejs! At work today we discovered that when we all boot up a new terminal shell and run "node -v" to get the current node version, we would all get a different number! One person was on 12.13, one was on 11.15, one was on 10.something, and one guy was even using v6.4! We had to do  something about this madness

I've been recently doing a lot of test-driven development at my new job, and one of the things I've noticed is that sometimes we will just run into snags, times when we hit a wall where it feels like we aren't making any real progress forward. There have been a few times now where we have gotten the code down to make the actual product work, but we spend a lot of time struggling to get the tests to pass and to really test the system in a way they we felt was good and proper. The trick is juggling the fact that we want to be a lean team that develops quickly but that we also want to write tests first that will pass when we implement these new features. Sometimes that last "making the test pass when they should" can be a lot more challenging that it ought to be, and it sometimes seems that we're put in a position where we need to choose between cutting corners or further increasing the risk that we ship late. To be honest I don't really have a right answer for all this, but in this post I'll think out loud about some ideas.