Category Archives: Uncategorized


When entering a new field, you not only have to learn a new set of skills, but also the industry jargon you might not be familiar with.  Before becoming a software engineer, a ‘slug’ to me was a pest in our garden that my siblings and I would pour salt on and/or run away from.  Now ‘slugs’, and what it means to ‘slugify’ a string, have taken on a whole new meaning.


A slug is a part of a website’s url, usually the part at the end that comes from the title of the page or section.  On this blog, if you were to click on the “About” section, the url would become  The slug, “about-2”, comes from the fact that it’s about the “About” page.  By convention, slugs are usually lowercase, have spaces in a phrase replaced by a dash or underscore, and have punctuation marks removed.  Sometimes smaller words are dropped or changed to make the slug more readable.  For example, with the article entitled “The U.S. is still using floppy disks to run its nuclear program” from,, you can see the slug for that article became “pentagon-floppy-disks-nuclear.”    Interesting article by the way – I remember those huge floppy disks!

Tools to Slugify

When you are writing a program, you might find the need to turn a string into a slug, i.e. to slugify it.  While you can spend the time writing code that cleans up your string, many people have created tools that are ready for you to use.  For instance, there’s an npm package to help with this and also a lodash addon.  A quick search around the internet leads to many other tools like these to help slugify strings.   Happy slugifying!


Event Review and Tips: NYC Uncubed

Last Friday, I attended the NYC Uncubed Spring Event, which combines a job fair with a bunch of neat workshops and speakers (  It was hosted at the Met Pavilion on 18th Street in Manhattan, and I had a great time. However, it is not a free event, and I bought my ticket online ahead of time for around $35 bucks after using a discount code I found online.

At the event, registration was quick and efficient.  Every attendee got a lanyard with a huge name tag that was color-coded so you could see their background, for instance, mine was yellow for being in tech.  This made networking with other people at the event easier because you could visual find people with your background and talk to them about their experience.

Pre-Event Tips

  1. Research Companies: I spent a few hours researching the companies that were going to be at the fair ahead of time.  I checked out their missions and open positions and made a short list of the companies I wanted to talk to.
  2. Practice your Elevator Pitch: You will have to answer the dreaded, open-ended question, “Tell me about yourself” multiple times at the event.  It helps if you aren’t saying it for the first time with a cool company you would love to work at!  🙂
  3. Resume: It was helpful to bring hard copies of my updated resume to the event.  Even though some companies encouraged me to apply online, other people I talked to looked at the resume to frame our conversation.

At Event Tips

  1. Have an Open Mind: Sometimes current open positions at companies have changed slightly from when you did your research.  This is a blessing and a curse because you don’t have to waste time applying for jobs you know don’t exist anymore, but…that job you wanted doesn’t exist anymore.  😦
  2. Crowds: There were a LOT of people there.   People literally wait in lines to talk to people from hiring companies.  However, the great thing was that most company booths had a bunch of employees, so you never had to wait very long to talk to someone.
  3. On-the-Spot Research: The event had an app where you could find links to the companies and their open positions.  After I talked to the top companies on my list, I explored other companies and got to talk to some really interesting people!
  4. Make a Schedule: I did not get to attend any of the workshops I wanted to because I was distracted by the event itself!  If you really want to attend a workshop, make sure you remind yourself about when it starts and ends.
  5. Dress Code: The event said to wear what you felt comfortable in…most people were in jeans.  It was a very laid-back atmosphere.  In fact, probably the most relaxed job fair I’ve ever been to.
  6. Beverages: If you want to drink alcohol, there was an open bar, but you had to bring your ID to get a wrist band.  In fact, I saw both candidates and employers drinking, which I have never seen at an event like this.  There was also free coffee, which was delicious, and also more my speed at a job fair.


Whether you are looking for a new position, or just to increase your network in the NYC area, I would suggest checking out their event next year.  I think it was well worth the price of the ticket!

Callback Hell, Express, and Koa

I would like to start off by saying that I love Node because it was enables me to write full-stack web applications built entirely in JavaScript.  A lot of applications only use JavaScript for the front-end of the app because that is what it was originally intended for, but with Node we can build entire applications!  Yay!  *raucous applause*

However, using Node on its own can be tricky.  When I was first learning how to set up my server-side using Node, my friend gave me this advice: “First lesson in using Node – use Express. ”  I was curious about what he meant, but forged forward, only to soon find myself in callback hell with a series of other issues.

Callback Hell

Callback functions are functions that are executed at a later point in time.  Because JavaScript allows for asynchronous behavior, Node uses callbacks a lot to help deal with this. Instead of having functions just return a value, they will wrap that result in a callback function.  Since functions can’t execute until all the parameters are evaluated, the callback will only fire once the asynchronous job it needs to do is complete.  Once you get used to callbacks they aren’t so bad, but your code can get complicated and hard to read if you don’t take steps to keep your code modular and clean.  Callback hell happens when you end up having callbacks within callbacks within callbacks.

Additionally, when using Node on its own, you have to worry about parsing POST requests in a certain way.  Frameworks have many different modules you can choose from to simplify this process.

Solution: Frameworks


Express is a popular framework to use with Node.  Honestly, once I started using Express I have never gone back to creating an app using just Node by itself – there are just too many benefits.  Express makes routing, serving up your static files, and a host of other things super simple.  For instance, you can require body-parser, a middleware that helps you take care of parsing data easily.


Koa differs from Express because it uses generator functions, a feature in ES6 that I happen to like a lot!  Interestingly, the people who are behind Koa are the same people that made Express, and they set out to make a tool that would make creating the server side your app even easier.  Anything you can do with Express you can do with Koa, but getting used to generator functions their syntax can take a little time.


I’m realizing as I’m writing this that this blog post should/could actually be turned into about three or four posts specifically introducing Express and Koa specifics.

TL;DR: Simplify your life by using Express or Koa when using NodeJS.


Event Loop in JavaScript

Last week, I wrote about blocking vs. non-blocking code and the asynchronous nature of JavaScript.  This week I wanted to deep dive into the event loop to explain one way JavaScript is able to deal with asynchronous functions and enables it to have non-blocking behavior.

Runtime Environment

Many people use JavaScript for the client-side of their app, but it can also be used on the server-side while using NodeJS.  No matter where the code is being executed, i.e. its runtime environment, the event loop impacts the order that functions are called.

The JS engine goes through every line of code in your application and has to make decisions about when that code should be run.

The Infamous Call Stack


A stack!  Okay, so not a call stack, but delicious nonetheless.

A stack is a common data structure.  It functions exactly the stack of pancakes my dad makes for the whole family during the holidays – one at a time, people are able to remove a pancake from the top of the stack and to their plate.  A stack works the same way – data on top of the stack can be removed, as well as added to the top of the stack until it needs to be processed.

The call stack is a special kind of stack in the JS engine.  It processes one line of code at a time, and it executes whatever is on top of the stack.  As soon as that function is finished executing, it is removed from the stack, and the line that was previously second in line is pushed to the top and executed.

Callbacks and Event Queues

Say we arrive at a line of code that needs this asynchronous behavior.  Maybe you wrote a setTimeOut in your code to invoke a function at a later time, or perhaps a function that needs to get data from the database.  These are called callback functions and the JS engine has a special way of handling them.

Instead of putting them directly into the call stack, the JS engine puts them into an event queue where it waits to be executed.  Once the call stack is empty, it checks out the event queue and moves any function that is next in line to the call stack where it is executed.

Event Loop

The event loop is this process the JavaScript engine uses to execute functions on the call stack while also checking and eventually executing the next function in line in the event queue.  As the user interacts with an application, the call stack and event queues are constantly moving and cycling through the code and reacting in response to user behavior.  This keeps your program running smoothly!

While this is a very simplified version of what happens inside of a JavaScript engine, it is important information to keep in mind when writing code.


Blocking and Non-blocking Code

A Tale of Two Burger Joints

Restaurant #1

You wait in line so the cashier can take your order. There’s about 4 guests ahead of you, and an ever increasing line of people behind you. Once you place your order, they give you a pager that lights up and vibrates when your food is ready. You step off the line and wait with the other people who placed their order before you. Eventually your buzzer goes off, you take your tray of deliciousness from the counter, and squeeze past the lines of people waiting to find a table. This whole process takes about 20-30 minutes.

Restaurant #2

There are about 3 people in ahead of you in line. The cashier takes the order of the person in front. Then, after about 15 minutes, the customer’s food is ready and they take it and leave. Now there are only 2 people in front of you in line, and the same process happens: no other orders can be taken until the transaction is complete. You have to wait until everyone in front of you places their order, pays, and gets their food. The whole process takes a really long time.

So What?

You may be thinking that Restaurant #1 sounds like any fast food place, and that you would never see a place like Restaurant #2 in business.

What does this have to do with code? Code can be blocking, like Restaurant #2. Code can also be non-blocking, like Restaurant #1. Javascript by nature is non-blocking and allows asynchronous functions to exist. From what I’ve gathered, it can take a little getting used to if you are used to writing blocking code that has to go in a certain sequence.

Some actions that need to take place in a program are asynchronous by nature.  For example, say you need to retrieve data from a database – it takes time for your program to go to the database, get the data, and return it to the client side of your app.  Meanwhile, the rest of the page still needs to load.  It would not make for a good user experience for them to look at a blank screen while the database was accessed.  Usually, you might see most of the page loaded, and maybe a spinner or message that lets the user know they are waiting for the data.  When writing code in Javascript, it’s important to keep asynchronous operations in mind so that your application functions the way you want it to.

Walk-through of Feature using React and Redux

In my previous post, I described my thought process when planning to implement the delete jobs feature.  In this post, I want to walk through the complete code from the front to the back of the app.  I hope it helps your understanding of how React, Redux, and the back-end of your app go together – I know it will certainly help me remember this process for my next React project.  


When a user clicks on the job, they see a page with all of the information about that particular job being pulled in from the API.  I also created a “Delete” button on that page, which I put into its own component file.  You can see here that I’ve imported the “raised button” component for styling from Material-UI, and that the component itself (written in JSX) has a label that says “Delete Job.”  In the Material-UI documentation for Raised Buttons, OnMouseDown is a property on the button itself that initiates a callback function when the button is pressed.  In this component, the callback is called “props.handleDelete” which we will get to see in action in the JobViewContainer where the component actually goes.


This a snippet of code for the JobViewContainer, where handleDelete is actually called. The props.handleDelete in the DeleteJobComponent from above can be seen here as a property of this container: this.handleDelete.   You can also see that the ‘this’ keyword is bound to it in the constructor of the component so that it knows exactly which job is being viewed in the container.


Below the constructor, here is the actual code for handleDelete, which will be called when the delete button component from above is clicked.  Basically, the dispatch function here initiates the deleteJob function inside of the Redux store, which starts the call to the database.  As you can see, we send in the specific jobID as a parameter to this function so that we can correctly identify which job we want to delete from the database.  The last line directs the user back to the dashboard after this function is called.


Into the Server and Back Again

This is where the deleteJob function being called in the JobViewContainer above lives.  Delete job makes a DELETE request to the database using axios, a promise based HTTP client.  You can see that this also dispatches other actions: dbRequest, deleteJobSuccess, and dbSuccess or dbFailure depending on the result from the call to the database.  The three functions dbRequest, dbSuccess, and dbFailure are called in any function that makes a call to the database to control spinners on the page that let the user know the application is waiting for data.


When the axios call is made, the id is passed along that particular API route and onto the deleteJob method in the jobs controller where all the other methods related to job manipulation live.


The actual deleteJob method that queries the database (using the ORM) is below.  If you’ve never seen a function like this before, it’s called a generator function and they are supported in ES6.  You can tell it’s a function generator because of the asterisk (*) next to the function declaration, as well as the ‘yield’ on the fourth line.  I love the concept of generator functions because they allow you take care of the asynchronous nature of calls to a database (as is the case with this particular method) in a different format.  Read up on them here.  Basically this function receives the id of the job the user wants to delete, and then deletes it.  It also sends back to the front-end which job has been deleted so that it can be taken out of the view.  Alternatively, errors are handled in the catch block in case there were any problems with access the database.


Reducer Time!

Above in the deleteJob function on the front-end, you might recall that inside of the call to axios, an action called “DELETE_JOB_SUCCESS” is dispatched inside of the reducer.  Remember, a reducer takes the previous state, combines it with an action, and returns the NEW state (ie – view) of the application.  In our case, it deletes any reference to the delete’s job on the user’s dashboard.  This reducer is specifically taking care of all the actions that have to do with jobs – setting a user’s saved jobs on the dashboard, adding jobs, and deleting jobs.  We are able to isolate the jobID from the job object that is returned from the database.  “DELETE_JOB_SUCCESS” then loops through all the jobs currently in the state until it finds the one with the matching id, and then deletes it from the view.


Use Value

I love using React with Redux because it helps keep your code modular and clean.  In my mind, it is super clear how the user pressing the delete button sets off the chain of events that deletes all references to the job in the database and also in the view. It takes getting used to, but is great to use once it is set up!

Postman Revisited

In my current project, I am in charge of getting our Rethinkdb database up and running. Not only am I new to Rethinkdb and (the ORM library we are using) but we are also using Koa as the server. Koa is similar to Express in that it simplifies setting up a server in Node, the major difference being that it relies on function generators. All of these things would make great blog posts themselves, but I wanted to focus on how I’ve finally been able to leverage the power of Postman to help my code.  (You can read my original thoughts on Postman here).  The following post illustrates how I was able to use Postman to test out POST and DELETE requests to make sure data was getting to our database.


Before starting, I checked my code to make sure it was free of errors.  Then, I started my server and database.  This may be an obvious step to many people, but when I first started coding, I literally would forget to do this every time.  Rethink has a really nifty web interface when you run it in the browser which you will catch a glimpse of later.

In our server.js file, these are the two routes I decided to test out using Postman.



This is what my addUser  function looks like – note that it uses a function generator, which you can easily spot since it uses an asterisk.  Since this was my first time using one, I decided it would be a great time to use Postman to see if I could actually get data posted to my database.

I’m using mock data here and passing it directly into my User model.  Before saving the user, it queries the table to see if there is already an existing user, and if there is it throws an error.  If not, it saves the new user to the database!


Postman mimics what your program will do when it passes data around, and the great thing is that you can use it before you have all parts of your app complete.  After running this POST request in Postman, I was able to query the database and see that the user did in fact make it in.


Rethink allows you to query your database in the browser window.  Here I double checked to make sure my test user made it into my ‘User’ table, which it did!

To make sure I could not add a duplicate user, I tried adding the same user to the database using Postman to do the same post request.  In the photo below, you can see how Postman works to do these types of requests.   You can see the url in this case is made up of localhost and port 3000, which is where my server is running from, as well as the user route (/api/user).   You choose what kind of request you want, put in the url, and press send – super easy!  In this case, it responded with “Email already taken!”, just like I wrote in my addUser function.


DELETE Success and Other Info

I tested out deleting a user by following the same steps as I did for the POST request, and it was successful!  I confirmed with the database that I no longer had any entries in my User table.   This image is just to show what a nice interface Postman has, and all the different requests you can make.  I didn’t use it this time, but you can see a “Params” button where you can add specific parameters to your request.  This is great when testing out authentication because you can pass tokens into the request.


Look at all the different types of requests you can make in Postman: GET, POST, PUT, PATCH, DELETE….and many others I haven’t gotten a chance to use yet.

Steps to using Postman*

  1. Double check your routes and functions before you try to use Postman to make sure they are doing what you want them to do
  2. Connect any servers or databases you need
  3. (IN POSTMAN) Write api call, choose request type, fill out any extra parameters, press send 
  4. Look at your results!**

*The first actual step would be to sign up for Postman at

**You will see different results depending on what kind of call you make.  Sometimes the information is really clear, but sometimes it isn’t.  After deleting the user from the database, I thought my response was an error, but it actually wasn’t.  So…be careful.

Bugs and Looking Forward

At this point, at least I know that the connection to my database is solid and that I am making queries using the correct syntax.  However, right now I have just been passing around mock data.  My next step will be connecting it to actual user data coming in from the client-side of the app.  I also need to get a better grasp of how data is passed around in Koa.  Since I am working on a team, my next actual step is to check-in with everyone at our daily meeting tomorrow to discuss next steps.  I can’t wait!