Category: JavaScript

  • Asynchronous Programming

    Asynchronous Programming

    Introduction

    JavaScript is an asynchronous programming language in Node and in the browser. In many languages such as Java, C#, Python, etc. they block the thread for I/O. What this means is when you make an HTTP/ajax call or read a text file for example, the runtime will pause on that line of code until it is successful or failure.

    JavaScript does the opposite. Using callbacks or Promises, you basically leave a phone number to call when those operations are done, while the rest of the synchronous code keeps going. In this article we’ll talk about why, give examples from JavaScript and compare against a blocking language, and show you some tips to help.

    (more…)

  • Error Handling Strategies

    Error Handling Strategies

    Introduction

    There are various ways of handling errors in programming. This includes not handling it. Many languages have created more modern ways of error handling. An error is when the program, intentionally, but mostly not, breaks. Below, I’ll cover the 4 main ones I know: try/catch, explicit returns, either, and supervising crashes. We’ll compare various languages on how they approach errors: Python, JavaScript, Lua, Go, Scala, Akka, and Elixir. Once you understand how the newer ways work, hopefully this will encourage you to abandon using potentially program crashing errors via the dated throw/raise in your programs.
    (more…)

  • AWS Adventures: Part 3 – Post Mortem on Lambdas

    AWS Adventures: Part 3 – Post Mortem on Lambdas

    Introduction

    Friends have asked that I report a from the trenches update on my thoughts on Lambdas. I fell in love about a year ago, so how do I feel now? I’ll cover the pro’s and con’s I faced, what I learned, and what I still don’t know.
    (more…)

  • AWS Adventures: Part 2 – Infrastructure As Code, Deploying a Microservice

    AWS Adventures: Part 2 – Infrastructure As Code, Deploying a Microservice

    Introduction

     

    In the old days, you’d write code and allow another team called Operations (or OPs for short) to deploy it to various servers for testing, and eventually production. Quality Assurance teams would be testing your code from a few days to a few weeks ago on another server.

    Developer tooling, infrastructure as a service, and shorter development cycles have changed all that. The Amazon practice of “you build it, you own it” has started to filter out to other companies as an adopted practice. Teams are now expected to build, deploy, and maintain their own software.

    Today, I wanted to cover what I’ve learned about automated deployments around AWS. You’ll learn why you don’t need Ansible, Chef, or even Serverless, and instead can use AWS API’s to do everything you need.

    (more…)