DEV Community: Joe

How I upgraded my laptop without any hardware changes

Joe — Wed, 27 May 2020 19:54:32 +0000

I want a new laptop. I know I don't need it, but I feel like it would be a quality-of-life upgrade. I currently own a 2017 Razer Blade Stealth; it does the job 80% of the time. Although, it does start to show its age when I am working on a project. Build times are getting longer, the fan sounds like a drone is on my desk, and general frustration ensues.

However, I like my laptop. I have everything set up just right - my terminal, fonts, apps, OS Settings, and everything else. I don't really want a new laptop. I just don't want to have to wait so long for angular to compile a site, or npm build to take as long. So, I started to think about what I could do.

I am most productive when everything just works. I don't want to have to take any extra time waiting on something or switching context. So even though it sounds small, having to wait ~20 seconds for something to rebuild and be ready can add up over time.

With that in mind, my laptop isn't the problem - the build is. I knew Visual Studio Code allows for remote development, and I started to wonder if I could just switch to that. The bar was high though. I have everything just so. With 4 keyboard shortcuts I can

launch a terminal with mongod, mongo shell, the app, and any dependent services running
open vsCode pointed to whatever project I need to work on

Whatever I changed has to support that. I don't want to manually ssh into a server and set things up. It just needs to work when I say so.

So I went looking at Azure VMs. I picked out a "compute optimized" sever and instantly ran into snag. You are initially limited to 4vCPUs in a region, and I was getting one with 8. It wasn't looking good, but I downgraded to one with 4 cores and gave it a try. I figured I can always go down the upgrade path when/if this worked out.

I spent the rest of the evening getting it set up. Installing mongo, node, setting up ssh, moving my terminal aliases over, everything. The hardest part was integrating it into my workflow.

I found ways to still keep my keyboard shortcuts locally, but just modified the commands to do everything remote. I just can't figure out how to automatically launch vsCode and have it connect to the remote server. I still have to do it the long way. 😣

Overall, I am a mostly impressed. That server cut my build times down by about 80%, and with the tooling in vsCode I really don't even notice. I set up port forwarding so localhost:xxxx traffic is sent over the ssh connection, and it feels perfect.

The best part is the price. I manually start/stop the VM when I need to, so it only runs for a short while. I'm guessing it will cost $17/month. Not bad! I could do that for years before getting a new laptop would have been cheaper.

Bonus points for my fan not whining at me the entire time :) A quiet computer is a good computer.

Music for Coding: A Spotify playlist for progamming

Joe — Sun, 17 Nov 2019 15:02:23 +0000

Do you want to know how to irritate software engineers? Break their focus. Much of what we do is problem solving. Sometimes they are simple, but often they don't have an obvious solution. If we aren't able to focus on the problem at hand then solving it is harder than it should be.

I work in an open-office environment. There are only 4 of us in the room, but it can still be distracting. Someone is on a call. These two are catching up. Did he say my name?

Downing out the noise is imperative.

I have tried every "focus" playlist Spotify recommended to me, but they all had a problem. Some were too slow and peaceful that I could fall asleep listening to them 😴. Others were catchy, but I find lyrics in music to be distracting.

I wanted something upbeat, not too crazy, no lyrics, but wouldn't put me to sleep. Enter the creatively named Music for Coding. 3 hours of music to drown out the noise when you need it the most. I have been using it for a few months and it hasn't let me down yet. If you are in the mood for something new and different then give it a try.

Enough distraction - back to that problem!

The Full Stack Developer

Joe — Thu, 14 Nov 2019 20:37:59 +0000

Technical books are a funny thing - most of them are out of date shortly after publishing. I can't even begin to remember how many I have either donated or deleted from my digital library. The problem is simple. They don't stay relevant in the fast-paced world that is software development. So I get excited when I find a technical book that has what it takes to stand the test of time. The latest one is The Full Stack Developer by Chris Northwood.

This book stands-out due to the focus on the day-to-day aspect of being a developer. Don't pick this up expecting to learn the details of a framework or language. What you will learn is how planning works, designing system, dev-ops, and so much more. Take a second and read this excerpt on "Constantly Learning"

“One area where the modern full stack developer working in a digital organization will differ from a traditional enterprise is that the products they are working on will constantly evolve in response to the real world at a rapid pace, rather than simply in response to requirements being pushed upon them by the organization. It is no longer enough to build something to meet some acceptance criteria and then push it out into the world; you and your team will have to check that any change you've made is actually having the impact you want it to have.

Getting into a position to do this can be hard unless your team is truly working as a core part of your organization. Any new feature you build or change you make also requires you to understand why that change is being made—is it to increase sign-ups or sales, or to satisfy some other business need? Once you understand this underlying motivation, then shipping a feature is no longer enough, if that feature cannot satisfy this underlying cause.”

Excerpt From: Chris Northwood. “The Full Stack Developer.”

It has been said there are two kinds of unknowns: Those you know and those you don't. A "known unknown" is when you recognize where a knowledge gap is; while an "unknown unknown" is when you don't.

You typically learn these "unknown unknowns" on the job, but The Full Stack Developer is a jumpstart down that path. If you want to be a professional software developer then you need this book. There is a lot of information to gain, and nothing to lose.

Fault-Tolerance: An NPM Package to Format and Normalize Errors

Joe — Wed, 06 Nov 2019 14:45:07 +0000

Developers don't spend enough time thinking about their errors. I see too many projects that throw Error('invalid data') or even worse throw 'invalid data' 😱. That isn't useful! Give me some context, bud.

But we (myself included) aren't usually thinking about the failure case. We are thinking about the solution and (at best) are simply guarding against some bad input. That needs to change. Errors need context to be useful. String interpolation isn't good enough - it still requires thought. An error databag is what we need.

So when I was tired of seeing less than helpful errors at work, I set out to create something that was effortless to use, and would make log messages incrementally better. What I ended up with is a project I am calling Fault-Tolerance. The concept behind it is trivial - extend the default Error object to format the output better.

In the most basic example you can throw new Fault('Move along'). In reality, though, that kind of error isn't as helpful as you want. Errors have context and we don't want to lose that.

function checkpoint(droids:[]){
  try{
    droids.forEach(d => {
      if(isWanted(d)) {
        if(jediIsPresent) {
          throw new Error('These are not the droids you are looking for');
        }
        detain(d);
      }
    })
  }
  catch(e) {
    // a Fault will preserve the original stacktrace
    throw new Fault(e, {droids: droids});
  }
}

The output from that would look like:

Error: These are not the droids you are looking for
    at ......
    at ......
    at ......
metadata:
{
  "droids": [
      {
       "name": "R2D2",
       "owner": "Skywalker",
       "purpose": "astromech"
      },
      {
       "name": "C3PO",
       "owner": "Skywalker",
       "purpose": "comic relief" 
      }
  ]
}

This gives you a much better way to include additional information with the added benefit of a consistent log format.

Check out the Fault-Tolerance on Gitlab for more examples. It is also available as an NPM package.

Photo by Pankaj Patel on Unsplash

Woodworking has made be a better developer

Joe — Mon, 04 Nov 2019 21:41:13 +0000

Woodworking has been one of my passions for about 5 years now. 99% of what I do is with hand tools - dimensioning wood, planing it smooth, joinery, everything. Some people think it is crazy, but I truly believe it has made me a better developer.

It has caused me to slow down

The choices I make are more deliberate. I stop to think more. I make sure what I am doing is elegant, extensible, and testable. The result is that I spend less time trying to build something and more time actually building it.

I'm not saying I write perfect code (I should tell you about some of the bugs I have caused!) but I understand the code more and find it easier to pinpoint a problem when found.

I pay more attention to the details

Consistency is a sign of a good, clean code base. If you aren't paying attention to the structure and style of code, then the result is a messy project.

Nothing screams "legacy" more than seeing several different code styles intermixed. Unless you have seen it, you might not understand, but the code feels messy, unkempt, and buggy. It doesn't mean it is - it just comes across like that.

Visualizing the design in my head

Woodworking is a 3Dimensional space. You need to know how components are going to interact, move, join together, and assemble. Being able to take a design and visualize how it fits into the system gives you a feeling of freedom. Once you can do that, then you are able to make changes as you go and be confident of the result.

Recognizing mistakes early

This dovetails with the previous one. "Fail early and often" is a phrase I hear a lot, but recognizing when something is going to fail is even more important. Nobody wants to spend the time solving an issue only to find out it won't work or causes another problem upstream.

Recognize not only when something has failed, but will fail. That will ultimately make you a better developer.

Cover Photo by Will Suddreth on Unsplash