This year, I’ve had the pleasure to have been working on a book about React for Manning Publications. It’s been a humbling, hard, fun, and extremely rewarding experience so far. I am deeply thankful to my wife, family, friends, and all the people at Manning who have supported me in this endeavor! Writing has always been a passion of mine and it’s long been a goal of mine to write and publish a book.

I run a few re-usable APIs for the various side projects I tinker on; in this post, I wanted to share a little about them. Working on side projects is one of my favorite things to do in the pretty limited spare time I have (between family, work, friends, church, etc.). Working with software is unique in that it allows an individual to build systems, products, and prototypes that would normally be impossible for an individual.

tl;dr: I’ve written a book about React, React in Action for Manning Publications! I’m thankful to have been able to work on it and fulfill a life-goal of mine. If you’re reading this post, you probably either made your way here from somewhere on the internet or you’re reading React in Action and were directed here from the book. One of my goals for the book is to give the reader a sense of React that isn’t bogged down in jargon and is instead rooted in solid concepts and practical examples.

*tl;dr: You might have seen or read the Docker tutorial Dockerizing a Node.js web app; this is another take on how you might go about doing just that if you need a more flexible approach than the one you can find in the Docker docs (how are they not called docks?!).* Head here to check out the sample Dockerfile. ##Ahoy! I’ve been working on a small side-project/really-small startup called Charityware.

You might have seen my post from the other day about my upcoming book on React. I’m so excited to be working on this project and would love for you to be able to take part in learning about React and improving the book as it comes together. Today, React in Action is part of Manning’s Deal of the Day offering. You can get 50% off your order if you follow this link (make sure to use code DOTD102016LT).

This year, I’ve had the pleasure to have been working on a book about React for Manning Publications. It’s been a humbling, hard, fun, and extremely rewarding experience so far. I am deeply thankful to my wife, family, friends, and all the people at Manning who have supported me in this endeavor! Writing has always been a passion of mine and it’s long been a goal of mine to write and publish a book.

I am grateful for my experience in the Boy Scouts and thankful I was able to make it all the way to Eagle Scout. While everything wasn’t perfect (like anything else), I learned invaluable lessons about leadership, teamwork, respect for nature, and survival skills. One of the recurrent themes involved in our outings, gatherings, and organization was “leave things better than you find them.” It applied to the wilderness, where we would try to leave any camping areas we used (or created) cleaner than we found them to minimize our footprint and environmental impact.

<Meaningful Commit> <Meaningful Commit> <Meaningful Commit> <Trying to fix CI Build> <Trying to fix CI Build> <Still Trying to fix CI Build> <Trying to fix CI Build> <CI Build has become self-aware> <Trying to fix CI Build> <CI Build is actively breaking itself, laughing at me> <Trying to fix CI Build> <CI Build refuses to cooperate> <Works for me> <DevOps angry> <Meaningful Commit> <Trying to fix CI Build> <Trying to fix CI Build> <Meaningful Commit> <Meaningful Commit> <Transition to new CI build vendor> .

tl;dr: Start Simply: Use, build, learn what you need when you need it. Simply Start: Don’t let everything get in the way of doing something. There’s been a lot of talk, writing, presentations, and tweeting over the past year-ish about the sheer pace of development, proliferation of tools, and overall craziness of the JavaScript universe. Whether it’s been endless framework proliferation, tooling insanity, or whatever else, I’ve gotten the sense that people are equally as excited about the new things people are doing with JavaScript as they are fatigued and overwhelmed by everything.

tl;dr: I’ve written a book about React, React in Action for Manning Publications! I’m thankful to have been able to work on it and fulfill a life-goal of mine. If you’re reading this post, you probably either made your way here from somewhere on the internet or you’re reading React in Action and were directed here from the book. One of my goals for the book is to give the reader a sense of React that isn’t bogged down in jargon and is instead rooted in solid concepts and practical examples.

Concise Overview of CS Math Even though my academic background is primarily in the humanities and biochemistry, my foundations/training in math is somewhat limited when compared to what the typical comptuer science or engineering major would normally go through. As such, I’ve been doing self-remediation through the wonderful (actual and otherwise) repositories of free knowledge available to us through that whole internet thing. One resource that I’ve really enjoyed is an overview of mathematics for computer science by Prof.

tl;dr: Start Simply: Use, build, learn what you need when you need it. Simply Start: Don’t let everything get in the way of doing something. There’s been a lot of talk, writing, presentations, and tweeting over the past year-ish about the sheer pace of development, proliferation of tools, and overall craziness of the JavaScript universe. Whether it’s been endless framework proliferation, tooling insanity, or whatever else, I’ve gotten the sense that people are equally as excited about the new things people are doing with JavaScript as they are fatigued and overwhelmed by everything.

There are stages to every engineer’s relationship with a database. They might go like this: shock: “what is this new thing? This is bad! I’m not used to this!” euphoria: “I CAN DO ALL THE THINGS” self-doubt: “but I thought I could do all the things?” the hero emerges: “I just need to tune this and that and use the right tool for the right use-case” Working with MongoDB isn’t an exception.

I originally wrote this post to appear on the FloQast Engineering Blog. I know how frustrating slow apps are. I also really care about my users’ time. One of the best ways to respect peoples’ time when using your applications is by ensuring your database is humming smoothly. I’ve learned how to work with MongoDB over the years in order to make sure my users’ time isn’t wasted and wanted to share some of those lessons here.

Code for tutorial available on Github Get Your Priorities Straight Chances are that if you’ve worked on the server side of things for long enough, you’ve probably run into a situation where you need a queue of some sort to handle messaging, processing, or any sort of orderly task execution. In this tutorial, we’ll be using a certain type of queue — the priority job queue — to help us solve a fairly common problem: payment processing.

You might have seen my post from the other week about my upcoming book on React. Today, React in Action is part of Manning’s Deal of the Day. You can get 50% off your order here (make sure to use code dotd110316au!). What’s in the book? React in Action is broken into several major parts. In the first section, you’ll meet React. We’ll dive into some of the fundamental ideas in React and work with components.

You might have seen my post from the other day about my upcoming book on React. I’m so excited to be working on this project and would love for you to be able to take part in learning about React and improving the book as it comes together. Today, React in Action is part of Manning’s Deal of the Day offering. You can get 50% off your order if you follow this link (make sure to use code DOTD102016LT).

I will update this post with more resources as I find them – check back for more (Just starting out in web development? This post is written for you) Starting from scratch One of the things that I’ve learned since becoming a developer is that sometimes “you don’t know what you don’t know.” That is, sometimes you just have no idea how much you don’t really know. This can be daunting, especailly if you’re just starting out.

In Praise of The CLI One reason the GUI exists is to speed up and make clearer basic user interaction with a computer. Take, for example, moving around the Finder on OSX. If you want to open a file, you have to use a series of visual representation using the mouse as your only means of navigation. Cool, right? In many ways, the GUI is incredible; it is in part what has enabled computers to become so useful in the world.

Several months ago, I wrote about how you might go about ‘dockerizing’ a node.js web application. I was able to write an expanded version of this post for Semaphore CI’s Community site. I am re-posting it here — enjoy! Dockerizing a Node.js Web Application Introduction If you’ve ever developed anything that needs to ‘live’ somewhere besides your local machine, you know that getting an application up and running on a different machine is no simple task.

Several months ago, I wrote about how you might go about ‘dockerizing’ a node.js web application. I was able to write an expanded version of this post for Semaphore CI’s Community site. I am re-posting it here — enjoy! Dockerizing a Node.js Web Application Introduction If you’ve ever developed anything that needs to ‘live’ somewhere besides your local machine, you know that getting an application up and running on a different machine is no simple task.

Avast, Ye Old Images! If you’ve been trying out Docker or maybe just reading about it, you probably know that one of it’s strengths is the way in which builds progress by layer. RUN commands all get executed in their own intermediate container. This is great for lots of reasons, but if you don’t use the --rm=true flag when you run docker build, you’ll get stuck with lots of these guys after a while: ##Make it so

*tl;dr: You might have seen or read the Docker tutorial Dockerizing a Node.js web app; this is another take on how you might go about doing just that if you need a more flexible approach than the one you can find in the Docker docs (how are they not called docks?!).* Head here to check out the sample Dockerfile. ##Ahoy! I’ve been working on a small side-project/really-small startup called Charityware.

tl;dr: I’ve written a book about React, React in Action for Manning Publications! I’m thankful to have been able to work on it and fulfill a life-goal of mine. If you’re reading this post, you probably either made your way here from somewhere on the internet or you’re reading React in Action and were directed here from the book. One of my goals for the book is to give the reader a sense of React that isn’t bogged down in jargon and is instead rooted in solid concepts and practical examples.

I originally wrote this as a tutorial for Semaphore CI’s community site; I am republishing my own work here :) Testing React Components with Enzyme and Mocha Introduction Even if you only dabble in the JavaScript world, you have probably heard of React. React has become an increasingly popular and widely-used JavaScript application tool for developing web applications. Popular frameworks like Angular.js, Ember.js, and Backbone have traditionally been go-to choices for front-end application development, but React came onto the scene in 2013 has provided front-end engineers with (yet) another substantial alternative.

update: This post was last updated on 4/16/16 w/ more-recent react-router. tl;dr: React is the only framework you ever need to learn again! Proclaim it’s superiority from the mountaintops! No longer will we be trapped in the chains of Angular, Ember, Backbone…REACT IS FREEDOM. Eh…Jk. React is really great, but please don’t be that person. We need to love all the frameworks equally, lest we just keep reinventing them over and over and over…and over again ;) I’m way off track of this tl;dr now.

I run a few re-usable APIs for the various side projects I tinker on; in this post, I wanted to share a little about them. Working on side projects is one of my favorite things to do in the pretty limited spare time I have (between family, work, friends, church, etc.). Working with software is unique in that it allows an individual to build systems, products, and prototypes that would normally be impossible for an individual.

tl;dr: In this post I’ll highlight three modules that you can use to to run your node app in production: using forever, nodemon, and PM2. So it’s pm2 vs forever vs nodemon. Each has its own strengths and weaknesses: forever is the most general, nodemon the best suited for development, and PM2 is the most comprehensive and best-suited for production. Production Ah, Production™. That happy place where everything is supposed to go smoothly and serenely1, where programs are their supposed to be their best, most efficient and bug-less selves.

I run a few re-usable APIs for the various side projects I tinker on; in this post, I wanted to share a little about them. Working on side projects is one of my favorite things to do in the pretty limited spare time I have (between family, work, friends, church, etc.). Working with software is unique in that it allows an individual to build systems, products, and prototypes that would normally be impossible for an individual.

<Meaningful Commit> <Meaningful Commit> <Meaningful Commit> <Trying to fix CI Build> <Trying to fix CI Build> <Still Trying to fix CI Build> <Trying to fix CI Build> <CI Build has become self-aware> <Trying to fix CI Build> <CI Build is actively breaking itself, laughing at me> <Trying to fix CI Build> <CI Build refuses to cooperate> <Works for me> <DevOps angry> <Meaningful Commit> <Trying to fix CI Build> <Trying to fix CI Build> <Meaningful Commit> <Meaningful Commit> <Transition to new CI build vendor> .

#Get Functional ##tl;dr most of our programs are more complex than they have to be functional approaches tend to result in code that: is easier to read has fewer source lines is simpler places fewer demands on the developer simplicity is really difficult watch this, use lodash, learn you haskell (or another functional language) ##Mmmm…Functional I’ve been on a bit of a functional kick for the past couple months and have really been loving the way taking a more functional approach has helped me reason through and improve my code.

Since it seems to be the vogue inevitability for JS/Node engineers to dabble in Go, I am inevitably, well, dabbling in Go. My experience with the language so far has been an extremely pleasant one. In many ways it has been like sipping a surprisingly good cup of espresso that I hadn’t tried before. Furthermore, the approach it takes to extending functionality has been incredible; it’s composition over inheritance, but built into the language.

tl;dr: I’ve written a book about React, React in Action for Manning Publications! I’m thankful to have been able to work on it and fulfill a life-goal of mine. If you’re reading this post, you probably either made your way here from somewhere on the internet or you’re reading React in Action and were directed here from the book. One of my goals for the book is to give the reader a sense of React that isn’t bogged down in jargon and is instead rooted in solid concepts and practical examples.

Interviewing as a developer nowadays is at the same time pretty exciting — technology is playing a crucial and exciting role in our cultures and societies — and harrowing — tech companies are engaged in what I’ve often heard described as a “talent arms race.” As a result, there are quite a few posts, talks, books, &c. about how to crack/solve/pass the coding interview. This post isn’t about the whiteboard or problem-solving end of things, where the company is evaluating you, but rather about the part where you get to evaluate the company.

##iojs If you’re even remotely involved with the Node community at all, you’ve likely heard about a fork (of sorts) that has been in process for the past several months. That fork is iojs, and it aims to try out an open-governance model that the Node/iojs community has more ownership of (rather than waiting on Joyent). There’s a great NodeUp podcast that you can listen to if you want to get more if the inside scoop on iojs.

tl;dr: I’ve written a book about React, React in Action for Manning Publications! I’m thankful to have been able to work on it and fulfill a life-goal of mine. If you’re reading this post, you probably either made your way here from somewhere on the internet or you’re reading React in Action and were directed here from the book. One of my goals for the book is to give the reader a sense of React that isn’t bogged down in jargon and is instead rooted in solid concepts and practical examples.

You might have seen my post from the other week about my upcoming book on React. Today, React in Action is part of Manning’s Deal of the Day. You can get 50% off your order here (make sure to use code dotd110316au!). What’s in the book? React in Action is broken into several major parts. In the first section, you’ll meet React. We’ll dive into some of the fundamental ideas in React and work with components.

I’ve had the pleasure to work on a book about React — React in Action — for Manning this year. It’s been a lot of fun and I’m so excited that it’s starting to be publicly available now through the MEAP program! You can download the first chapter for FREE here. For a short while, you’ll be able to use the discount code mlthomas to get 50% off the MEAP!

This year, I’ve had the pleasure to have been working on a book about React for Manning Publications. It’s been a humbling, hard, fun, and extremely rewarding experience so far. I am deeply thankful to my wife, family, friends, and all the people at Manning who have supported me in this endeavor! Writing has always been a passion of mine and it’s long been a goal of mine to write and publish a book.

Since it seems to be the vogue inevitability for JS/Node engineers to dabble in Go, I am inevitably, well, dabbling in Go. My experience with the language so far has been an extremely pleasant one. In many ways it has been like sipping a surprisingly good cup of espresso that I hadn’t tried before. Furthermore, the approach it takes to extending functionality has been incredible; it’s composition over inheritance, but built into the language.

I originally wrote this as a tutorial for Semaphore CI’s community site; I am republishing my own work here :) Testing React Components with Enzyme and Mocha Introduction Even if you only dabble in the JavaScript world, you have probably heard of React. React has become an increasingly popular and widely-used JavaScript application tool for developing web applications. Popular frameworks like Angular.js, Ember.js, and Backbone have traditionally been go-to choices for front-end application development, but React came onto the scene in 2013 has provided front-end engineers with (yet) another substantial alternative.

tl;dr: Start Simply: Use, build, learn what you need when you need it. Simply Start: Don’t let everything get in the way of doing something. There’s been a lot of talk, writing, presentations, and tweeting over the past year-ish about the sheer pace of development, proliferation of tools, and overall craziness of the JavaScript universe. Whether it’s been endless framework proliferation, tooling insanity, or whatever else, I’ve gotten the sense that people are equally as excited about the new things people are doing with JavaScript as they are fatigued and overwhelmed by everything.

a “stream” of events, being emitted from a waterfall… eh? ¯\(ツ)/¯ tl;dr: In this post we will look at using the Event Emitter module in node.js and how we might use it to create our own event-emitting programs. The repo with some sample code can be found at https://github.com/markthethomas/eventEmitterFun If you’ve worked with client-side JavaScript, you will be familiar with the notion of events. Or, at the very least, I really really hope you are — JavaScript isn’t much fun without one of its core concepts/principles.

Origin Story I asked a question on Stack Overflow about ~7 months back (at time of writing) about requiring and including images in react native. I figured it was a simple misunderstanding on my part about the directory structure(s) used in iOS development, but it turned out to be both 1) something other people were curious about and 2) an area where the react native team was still stabilizing the API.

I don’t know about you, but there are a few modules that I tend to use really often in the projects I’m working on. I usually go with some combination of eslint, lodash, babel, and a number of others. I’ve written briefly about some of my favorites here and here. I also find myself trying to stay current with the latest version of node for security considerations as well as all the other good that comes from using the current stable version.

Are you still a JavaScript padawan learner? Then this post is for you. Maybe you’re still going over the basics of JavaScript, learning how to define functions, how objects work, and some of the other baby steps. And maybe you’ve toyed around with that semi-well known library for querying the DOM (and for doing wayyyy too many other things, IMO), le jQuery. If you have or if you’ve tried out another library, you’ve likely seen something like this:

I’ve been writing a three-part series on some great modules I love and use. This is part two, but make sure to check out the first post. Eslint: If you’re not doing static analysis on your code, you’re carrying around a giant foot-gun…and probably using it, often. Eslint comes from the jsHint/jsLint school of thought, but with some notable differences: Espree for parsing, an AST for analysis, and it’s very pluggable.

tl;dr: In this post I’ll highlight three modules that you can use to to run your node app in production: using forever, nodemon, and PM2. So it’s pm2 vs forever vs nodemon. Each has its own strengths and weaknesses: forever is the most general, nodemon the best suited for development, and PM2 is the most comprehensive and best-suited for production. Production Ah, Production™. That happy place where everything is supposed to go smoothly and serenely1, where programs are their supposed to be their best, most efficient and bug-less selves.

update: This post was last updated on 4/16/16 w/ more-recent react-router. tl;dr: React is the only framework you ever need to learn again! Proclaim it’s superiority from the mountaintops! No longer will we be trapped in the chains of Angular, Ember, Backbone…REACT IS FREEDOM. Eh…Jk. React is really great, but please don’t be that person. We need to love all the frameworks equally, lest we just keep reinventing them over and over and over…and over again ;) I’m way off track of this tl;dr now.

##iojs If you’re even remotely involved with the Node community at all, you’ve likely heard about a fork (of sorts) that has been in process for the past several months. That fork is iojs, and it aims to try out an open-governance model that the Node/iojs community has more ownership of (rather than waiting on Joyent). There’s a great NodeUp podcast that you can listen to if you want to get more if the inside scoop on iojs.

#Get Functional ##tl;dr most of our programs are more complex than they have to be functional approaches tend to result in code that: is easier to read has fewer source lines is simpler places fewer demands on the developer simplicity is really difficult watch this, use lodash, learn you haskell (or another functional language) ##Mmmm…Functional I’ve been on a bit of a functional kick for the past couple months and have really been loving the way taking a more functional approach has helped me reason through and improve my code.

Code for tutorial available on Github Get Your Priorities Straight Chances are that if you’ve worked on the server side of things for long enough, you’ve probably run into a situation where you need a queue of some sort to handle messaging, processing, or any sort of orderly task execution. In this tutorial, we’ll be using a certain type of queue — the priority job queue — to help us solve a fairly common problem: payment processing.

Since it seems to be the vogue inevitability for JS/Node engineers to dabble in Go, I am inevitably, well, dabbling in Go. My experience with the language so far has been an extremely pleasant one. In many ways it has been like sipping a surprisingly good cup of espresso that I hadn’t tried before. Furthermore, the approach it takes to extending functionality has been incredible; it’s composition over inheritance, but built into the language.

It’s been far too long since I’ve blogged. In this post, I want to reflect on some things I’ve learned as a senior engineer and try to synthesize them into a personal engineering philosophy. table of contents impact over productivity “It depends” Cleverness kills “Business knows best” Ignore best practices (sometimes) Code is the easy part “No Mysteries” Abstract & optimize later You Aren’t Going To Need It (Probably) impact over productivity If you have to optimize for something as an engineer, it should be impact.

tl;dr: I’ve written a book about React, React in Action for Manning Publications! I’m thankful to have been able to work on it and fulfill a life-goal of mine. If you’re reading this post, you probably either made your way here from somewhere on the internet or you’re reading React in Action and were directed here from the book. One of my goals for the book is to give the reader a sense of React that isn’t bogged down in jargon and is instead rooted in solid concepts and practical examples.

###Ghosting Around I’ve been tinkering around with Ghost recently and found it to be a new but promising platform in the main. There are certainly some things it will need to achieve any sort of significant user-base (plugins, apps, etc., which are coming in future releases https://github.com/tryghost/ghost/). At the very least, it’s great that there are open-source, well-supported options for blogging platforms that aren’t Wordpress and it’s cousins. I suppose it can’t hurt Nodejs and Javascript Development in general either for there to be more people using node-based platforms either.

Concise Overview of CS Math Even though my academic background is primarily in the humanities and biochemistry, my foundations/training in math is somewhat limited when compared to what the typical comptuer science or engineering major would normally go through. As such, I’ve been doing self-remediation through the wonderful (actual and otherwise) repositories of free knowledge available to us through that whole internet thing. One resource that I’ve really enjoyed is an overview of mathematics for computer science by Prof.

Trying out a new look for the blog. When I first started writing here, I was pretty swamped with other things, so I had just forked and modified an existing Ghost theme to suit my needs. It was clean and I was happy with for the most part. I still don’t have enough time to dedicate to making the design incredible, but the old look was bothering me. It felt way too cookie-cutter.

I originally wrote this as a tutorial for Semaphore CI’s community site; I am republishing my own work here :) Testing React Components with Enzyme and Mocha Introduction Even if you only dabble in the JavaScript world, you have probably heard of React. React has become an increasingly popular and widely-used JavaScript application tool for developing web applications. Popular frameworks like Angular.js, Ember.js, and Backbone have traditionally been go-to choices for front-end application development, but React came onto the scene in 2013 has provided front-end engineers with (yet) another substantial alternative.

I don’t know about you, but there are a few modules that I tend to use really often in the projects I’m working on. I usually go with some combination of eslint, lodash, babel, and a number of others. I’ve written briefly about some of my favorites here and here. I also find myself trying to stay current with the latest version of node for security considerations as well as all the other good that comes from using the current stable version.

There are stages to every engineer’s relationship with a database. They might go like this: shock: “what is this new thing? This is bad! I’m not used to this!” euphoria: “I CAN DO ALL THE THINGS” self-doubt: “but I thought I could do all the things?” the hero emerges: “I just need to tune this and that and use the right tool for the right use-case” Working with MongoDB isn’t an exception.

I originally wrote this post to appear on the FloQast Engineering Blog. I know how frustrating slow apps are. I also really care about my users’ time. One of the best ways to respect peoples’ time when using your applications is by ensuring your database is humming smoothly. I’ve learned how to work with MongoDB over the years in order to make sure my users’ time isn’t wasted and wanted to share some of those lessons here.

Code for tutorial available on Github Get Your Priorities Straight Chances are that if you’ve worked on the server side of things for long enough, you’ve probably run into a situation where you need a queue of some sort to handle messaging, processing, or any sort of orderly task execution. In this tutorial, we’ll be using a certain type of queue — the priority job queue — to help us solve a fairly common problem: payment processing.

a “stream” of events, being emitted from a waterfall… eh? ¯\(ツ)/¯ tl;dr: In this post we will look at using the Event Emitter module in node.js and how we might use it to create our own event-emitting programs. The repo with some sample code can be found at https://github.com/markthethomas/eventEmitterFun If you’ve worked with client-side JavaScript, you will be familiar with the notion of events. Or, at the very least, I really really hope you are — JavaScript isn’t much fun without one of its core concepts/principles.

Several months ago, I wrote about how you might go about ‘dockerizing’ a node.js web application. I was able to write an expanded version of this post for Semaphore CI’s Community site. I am re-posting it here — enjoy! Dockerizing a Node.js Web Application Introduction If you’ve ever developed anything that needs to ‘live’ somewhere besides your local machine, you know that getting an application up and running on a different machine is no simple task.

Origin Story I asked a question on Stack Overflow about ~7 months back (at time of writing) about requiring and including images in react native. I figured it was a simple misunderstanding on my part about the directory structure(s) used in iOS development, but it turned out to be both 1) something other people were curious about and 2) an area where the react native team was still stabilizing the API.

I don’t know about you, but there are a few modules that I tend to use really often in the projects I’m working on. I usually go with some combination of eslint, lodash, babel, and a number of others. I’ve written briefly about some of my favorites here and here. I also find myself trying to stay current with the latest version of node for security considerations as well as all the other good that comes from using the current stable version.

Are you still a JavaScript padawan learner? Then this post is for you. Maybe you’re still going over the basics of JavaScript, learning how to define functions, how objects work, and some of the other baby steps. And maybe you’ve toyed around with that semi-well known library for querying the DOM (and for doing wayyyy too many other things, IMO), le jQuery. If you have or if you’ve tried out another library, you’ve likely seen something like this:

I’ve been writing a three-part series on some great modules I love and use. This is part two, but make sure to check out the first post. Eslint: If you’re not doing static analysis on your code, you’re carrying around a giant foot-gun…and probably using it, often. Eslint comes from the jsHint/jsLint school of thought, but with some notable differences: Espree for parsing, an AST for analysis, and it’s very pluggable.

tl;dr: In this post I’ll highlight three modules that you can use to to run your node app in production: using forever, nodemon, and PM2. So it’s pm2 vs forever vs nodemon. Each has its own strengths and weaknesses: forever is the most general, nodemon the best suited for development, and PM2 is the most comprehensive and best-suited for production. Production Ah, Production™. That happy place where everything is supposed to go smoothly and serenely1, where programs are their supposed to be their best, most efficient and bug-less selves.

update: This post was last updated on 4/16/16 w/ more-recent react-router. tl;dr: React is the only framework you ever need to learn again! Proclaim it’s superiority from the mountaintops! No longer will we be trapped in the chains of Angular, Ember, Backbone…REACT IS FREEDOM. Eh…Jk. React is really great, but please don’t be that person. We need to love all the frameworks equally, lest we just keep reinventing them over and over and over…and over again ;) I’m way off track of this tl;dr now.

*tl;dr: You might have seen or read the Docker tutorial Dockerizing a Node.js web app; this is another take on how you might go about doing just that if you need a more flexible approach than the one you can find in the Docker docs (how are they not called docks?!).* Head here to check out the sample Dockerfile. ##Ahoy! I’ve been working on a small side-project/really-small startup called Charityware.

##iojs If you’re even remotely involved with the Node community at all, you’ve likely heard about a fork (of sorts) that has been in process for the past several months. That fork is iojs, and it aims to try out an open-governance model that the Node/iojs community has more ownership of (rather than waiting on Joyent). There’s a great NodeUp podcast that you can listen to if you want to get more if the inside scoop on iojs.

tl;dr: In this post I’ll highlight three modules that you can use to to run your node app in production: using forever, nodemon, and PM2. So it’s pm2 vs forever vs nodemon. Each has its own strengths and weaknesses: forever is the most general, nodemon the best suited for development, and PM2 is the most comprehensive and best-suited for production. Production Ah, Production™. That happy place where everything is supposed to go smoothly and serenely1, where programs are their supposed to be their best, most efficient and bug-less selves.

I don’t know about you, but there are a few modules that I tend to use really often in the projects I’m working on. I usually go with some combination of eslint, lodash, babel, and a number of others. I’ve written briefly about some of my favorites here and here. I also find myself trying to stay current with the latest version of node for security considerations as well as all the other good that comes from using the current stable version.

I’ve been writing a three-part series on some great modules I love and use. This is part two, but make sure to check out the first post. Eslint: If you’re not doing static analysis on your code, you’re carrying around a giant foot-gun…and probably using it, often. Eslint comes from the jsHint/jsLint school of thought, but with some notable differences: Espree for parsing, an AST for analysis, and it’s very pluggable.

tl;dr: Start Simply: Use, build, learn what you need when you need it. Simply Start: Don’t let everything get in the way of doing something. There’s been a lot of talk, writing, presentations, and tweeting over the past year-ish about the sheer pace of development, proliferation of tools, and overall craziness of the JavaScript universe. Whether it’s been endless framework proliferation, tooling insanity, or whatever else, I’ve gotten the sense that people are equally as excited about the new things people are doing with JavaScript as they are fatigued and overwhelmed by everything.

There are stages to every engineer’s relationship with a database. They might go like this: shock: “what is this new thing? This is bad! I’m not used to this!” euphoria: “I CAN DO ALL THE THINGS” self-doubt: “but I thought I could do all the things?” the hero emerges: “I just need to tune this and that and use the right tool for the right use-case” Working with MongoDB isn’t an exception.

I originally wrote this post to appear on the FloQast Engineering Blog. I know how frustrating slow apps are. I also really care about my users’ time. One of the best ways to respect peoples’ time when using your applications is by ensuring your database is humming smoothly. I’ve learned how to work with MongoDB over the years in order to make sure my users’ time isn’t wasted and wanted to share some of those lessons here.

tl;dr: In this post I’ll highlight three modules that you can use to to run your node app in production: using forever, nodemon, and PM2. So it’s pm2 vs forever vs nodemon. Each has its own strengths and weaknesses: forever is the most general, nodemon the best suited for development, and PM2 is the most comprehensive and best-suited for production. Production Ah, Production™. That happy place where everything is supposed to go smoothly and serenely1, where programs are their supposed to be their best, most efficient and bug-less selves.

It’s been far too long since I’ve blogged. In this post, I want to reflect on some things I’ve learned as a senior engineer and try to synthesize them into a personal engineering philosophy. table of contents impact over productivity “It depends” Cleverness kills “Business knows best” Ignore best practices (sometimes) Code is the easy part “No Mysteries” Abstract & optimize later You Aren’t Going To Need It (Probably) impact over productivity If you have to optimize for something as an engineer, it should be impact.

tl;dr: In this post I’ll highlight three modules that you can use to to run your node app in production: using forever, nodemon, and PM2. So it’s pm2 vs forever vs nodemon. Each has its own strengths and weaknesses: forever is the most general, nodemon the best suited for development, and PM2 is the most comprehensive and best-suited for production. Production Ah, Production™. That happy place where everything is supposed to go smoothly and serenely1, where programs are their supposed to be their best, most efficient and bug-less selves.

#Adam Grant: The surprising habits of original thinkers Just wanted to share this great TED talk about original thinking; hoping it helps developers think better about the role of procrastination in original thinking.

tl;dr: I’m following up on my “Start Simply, Simply Start” from a bit ago with some more practical thoughts on starting simply. My hope is to also write on the second of these ideas, “On Simply Starting.” Simplicity is a prerequisite for reliability Edsger W. Djikstra I wrote a short(ish) post a bit ago about starting and starting simply. It was a rather “in the moment” piece of writing, not one I’d spent a long time actually composing.

I am grateful for my experience in the Boy Scouts and thankful I was able to make it all the way to Eagle Scout. While everything wasn’t perfect (like anything else), I learned invaluable lessons about leadership, teamwork, respect for nature, and survival skills. One of the recurrent themes involved in our outings, gatherings, and organization was “leave things better than you find them.” It applied to the wilderness, where we would try to leave any camping areas we used (or created) cleaner than we found them to minimize our footprint and environmental impact.

One of my favorite books on programming so far has been Clean Code: A Handbook of Agile Software Craftsmanship (Get it here). It’s full of great wisdom on writing–you guessed it–clean code. Clean code not only makes your life better, but it will save your friends and teammates hours of headaches. And perhaps even more importantly, it reflects a care for craft and excellence in your work. Anyways, enough from me; here’s a few great quotes from a few greats on writing clean code:

I don’t know about you, but there are a few modules that I tend to use really often in the projects I’m working on. I usually go with some combination of eslint, lodash, babel, and a number of others. I’ve written briefly about some of my favorites here and here. I also find myself trying to stay current with the latest version of node for security considerations as well as all the other good that comes from using the current stable version.

##Stones People think that computer science is the art of geniuses but the actual reality is the opposite, just many people doing things that build on each other, like a wall of mini stones. –Donald Knuth

tl;dr: I’ve written a book about React, React in Action for Manning Publications! I’m thankful to have been able to work on it and fulfill a life-goal of mine. If you’re reading this post, you probably either made your way here from somewhere on the internet or you’re reading React in Action and were directed here from the book. One of my goals for the book is to give the reader a sense of React that isn’t bogged down in jargon and is instead rooted in solid concepts and practical examples.

You might have seen my post from the other week about my upcoming book on React. Today, React in Action is part of Manning’s Deal of the Day. You can get 50% off your order here (make sure to use code dotd110316au!). What’s in the book? React in Action is broken into several major parts. In the first section, you’ll meet React. We’ll dive into some of the fundamental ideas in React and work with components.

I’ve had the pleasure to work on a book about React — React in Action — for Manning this year. It’s been a lot of fun and I’m so excited that it’s starting to be publicly available now through the MEAP program! You can download the first chapter for FREE here. For a short while, you’ll be able to use the discount code mlthomas to get 50% off the MEAP!

This year, I’ve had the pleasure to have been working on a book about React for Manning Publications. It’s been a humbling, hard, fun, and extremely rewarding experience so far. I am deeply thankful to my wife, family, friends, and all the people at Manning who have supported me in this endeavor! Writing has always been a passion of mine and it’s long been a goal of mine to write and publish a book.

I originally wrote this as a tutorial for Semaphore CI’s community site; I am republishing my own work here :) Testing React Components with Enzyme and Mocha Introduction Even if you only dabble in the JavaScript world, you have probably heard of React. React has become an increasingly popular and widely-used JavaScript application tool for developing web applications. Popular frameworks like Angular.js, Ember.js, and Backbone have traditionally been go-to choices for front-end application development, but React came onto the scene in 2013 has provided front-end engineers with (yet) another substantial alternative.

Origin Story I asked a question on Stack Overflow about ~7 months back (at time of writing) about requiring and including images in react native. I figured it was a simple misunderstanding on my part about the directory structure(s) used in iOS development, but it turned out to be both 1) something other people were curious about and 2) an area where the react native team was still stabilizing the API.

update: This post was last updated on 4/16/16 w/ more-recent react-router. tl;dr: React is the only framework you ever need to learn again! Proclaim it’s superiority from the mountaintops! No longer will we be trapped in the chains of Angular, Ember, Backbone…REACT IS FREEDOM. Eh…Jk. React is really great, but please don’t be that person. We need to love all the frameworks equally, lest we just keep reinventing them over and over and over…and over again ;) I’m way off track of this tl;dr now.

tl;dr: I’ve written a book about React, React in Action for Manning Publications! I’m thankful to have been able to work on it and fulfill a life-goal of mine. If you’re reading this post, you probably either made your way here from somewhere on the internet or you’re reading React in Action and were directed here from the book. One of my goals for the book is to give the reader a sense of React that isn’t bogged down in jargon and is instead rooted in solid concepts and practical examples.

You might have seen my post from the other week about my upcoming book on React. Today, React in Action is part of Manning’s Deal of the Day. You can get 50% off your order here (make sure to use code dotd110316au!). What’s in the book? React in Action is broken into several major parts. In the first section, you’ll meet React. We’ll dive into some of the fundamental ideas in React and work with components.

I’ve had the pleasure to work on a book about React — React in Action — for Manning this year. It’s been a lot of fun and I’m so excited that it’s starting to be publicly available now through the MEAP program! You can download the first chapter for FREE here. For a short while, you’ll be able to use the discount code mlthomas to get 50% off the MEAP!

You might have seen my post from the other day about my upcoming book on React. I’m so excited to be working on this project and would love for you to be able to take part in learning about React and improving the book as it comes together. Today, React in Action is part of Manning’s Deal of the Day offering. You can get 50% off your order if you follow this link (make sure to use code DOTD102016LT).

This year, I’ve had the pleasure to have been working on a book about React for Manning Publications. It’s been a humbling, hard, fun, and extremely rewarding experience so far. I am deeply thankful to my wife, family, friends, and all the people at Manning who have supported me in this endeavor! Writing has always been a passion of mine and it’s long been a goal of mine to write and publish a book.

Origin Story I asked a question on Stack Overflow about ~7 months back (at time of writing) about requiring and including images in react native. I figured it was a simple misunderstanding on my part about the directory structure(s) used in iOS development, but it turned out to be both 1) something other people were curious about and 2) an area where the react native team was still stabilizing the API.

update: This post was last updated on 4/16/16 w/ more-recent react-router. tl;dr: React is the only framework you ever need to learn again! Proclaim it’s superiority from the mountaintops! No longer will we be trapped in the chains of Angular, Ember, Backbone…REACT IS FREEDOM. Eh…Jk. React is really great, but please don’t be that person. We need to love all the frameworks equally, lest we just keep reinventing them over and over and over…and over again ;) I’m way off track of this tl;dr now.

Code for tutorial available on Github Get Your Priorities Straight Chances are that if you’ve worked on the server side of things for long enough, you’ve probably run into a situation where you need a queue of some sort to handle messaging, processing, or any sort of orderly task execution. In this tutorial, we’ll be using a certain type of queue — the priority job queue — to help us solve a fairly common problem: payment processing.

I wanted to write a little post to announce a side project/fledgling app to the world: isBusy. With all that’s been going on in the world these last few months, a lot has changed. Very little of our lives seems to have been left untouched by the Covid-19 pandemic. One area that has been changed dramatically for many people is their work life and situation. Tragically, many people have lost their jobs or face the challenge of a radically different work environment, remote or otherwise.

I will update this post with more resources as I find them – check back for more (Just starting out in web development? This post is written for you) Starting from scratch One of the things that I’ve learned since becoming a developer is that sometimes “you don’t know what you don’t know.” That is, sometimes you just have no idea how much you don’t really know. This can be daunting, especailly if you’re just starting out.

In Praise of The CLI One reason the GUI exists is to speed up and make clearer basic user interaction with a computer. Take, for example, moving around the Finder on OSX. If you want to open a file, you have to use a series of visual representation using the mouse as your only means of navigation. Cool, right? In many ways, the GUI is incredible; it is in part what has enabled computers to become so useful in the world.

One of the first hurdles I ran into when getting started with Rails 4 is sending/receiving mail locally. I’d wired up my basic app and started to sign in for the first time when I realized that I’d given the confirmation email no way to go anywhere. With some authentication gems can loook in the logs for your local rack server and see the confirmation token, but that gets old quickly and you’re quite limited in what you can do.

Concise Overview of CS Math Even though my academic background is primarily in the humanities and biochemistry, my foundations/training in math is somewhat limited when compared to what the typical comptuer science or engineering major would normally go through. As such, I’ve been doing self-remediation through the wonderful (actual and otherwise) repositories of free knowledge available to us through that whole internet thing. One resource that I’ve really enjoyed is an overview of mathematics for computer science by Prof.

Even though JavaScript (and node.js!) is/are my first programming language love(s)1, I’ve been trying to hone my skills in Ruby and Python to better merit the whole ‘full-stack’ title thing. Also because there are some really great things that python and ruby are great for that JavaScript isn’t (vice-versa for each language, really). So, I’ll occasionally be sharing some small tips/tricks I pick up along the way in these other realms.

One of the first hurdles I ran into when getting started with Rails 4 is sending/receiving mail locally. I’d wired up my basic app and started to sign in for the first time when I realized that I’d given the confirmation email no way to go anywhere. With some authentication gems can loook in the logs for your local rack server and see the confirmation token, but that gets old quickly and you’re quite limited in what you can do.

I wanted to write a little post to announce a side project/fledgling app to the world: isBusy. With all that’s been going on in the world these last few months, a lot has changed. Very little of our lives seems to have been left untouched by the Covid-19 pandemic. One area that has been changed dramatically for many people is their work life and situation. Tragically, many people have lost their jobs or face the challenge of a radically different work environment, remote or otherwise.

Interviewing as a developer nowadays is at the same time pretty exciting — technology is playing a crucial and exciting role in our cultures and societies — and harrowing — tech companies are engaged in what I’ve often heard described as a “talent arms race.” As a result, there are quite a few posts, talks, books, &c. about how to crack/solve/pass the coding interview. This post isn’t about the whiteboard or problem-solving end of things, where the company is evaluating you, but rather about the part where you get to evaluate the company.

##That Was Easy A friend of mine shared Rich Hickey’s 2012 RailsConf Austin talk Simple Made Easy with me recently. His thoughts on complexity and simplicity were really helpful and have encouraged me to build better software that’s not obsessed with objects. I’ve already seen my SLOC-count go down significantly and am able to better reason about my programs. Anyways, I strongly encourage you to watch it if you haven’t yet already.

#Adam Grant: The surprising habits of original thinkers Just wanted to share this great TED talk about original thinking; hoping it helps developers think better about the role of procrastination in original thinking.

##That Was Easy A friend of mine shared Rich Hickey’s 2012 RailsConf Austin talk Simple Made Easy with me recently. His thoughts on complexity and simplicity were really helpful and have encouraged me to build better software that’s not obsessed with objects. I’ve already seen my SLOC-count go down significantly and am able to better reason about my programs. Anyways, I strongly encourage you to watch it if you haven’t yet already.

I originally wrote this as a tutorial for Semaphore CI’s community site; I am republishing my own work here :) Testing React Components with Enzyme and Mocha Introduction Even if you only dabble in the JavaScript world, you have probably heard of React. React has become an increasingly popular and widely-used JavaScript application tool for developing web applications. Popular frameworks like Angular.js, Ember.js, and Backbone have traditionally been go-to choices for front-end application development, but React came onto the scene in 2013 has provided front-end engineers with (yet) another substantial alternative.

tl;dr: I’m following up on my “Start Simply, Simply Start” from a bit ago with some more practical thoughts on starting simply. My hope is to also write on the second of these ideas, “On Simply Starting.” Simplicity is a prerequisite for reliability Edsger W. Djikstra I wrote a short(ish) post a bit ago about starting and starting simply. It was a rather “in the moment” piece of writing, not one I’d spent a long time actually composing.

Even though JavaScript (and node.js!) is/are my first programming language love(s)1, I’ve been trying to hone my skills in Ruby and Python to better merit the whole ‘full-stack’ title thing. Also because there are some really great things that python and ruby are great for that JavaScript isn’t (vice-versa for each language, really). So, I’ll occasionally be sharing some small tips/tricks I pick up along the way in these other realms.

Avast, Ye Old Images! If you’ve been trying out Docker or maybe just reading about it, you probably know that one of it’s strengths is the way in which builds progress by layer. RUN commands all get executed in their own intermediate container. This is great for lots of reasons, but if you don’t use the --rm=true flag when you run docker build, you’ll get stuck with lots of these guys after a while: ##Make it so

Code for tutorial available on Github Get Your Priorities Straight Chances are that if you’ve worked on the server side of things for long enough, you’ve probably run into a situation where you need a queue of some sort to handle messaging, processing, or any sort of orderly task execution. In this tutorial, we’ll be using a certain type of queue — the priority job queue — to help us solve a fairly common problem: payment processing.

Origin Story I asked a question on Stack Overflow about ~7 months back (at time of writing) about requiring and including images in react native. I figured it was a simple misunderstanding on my part about the directory structure(s) used in iOS development, but it turned out to be both 1) something other people were curious about and 2) an area where the react native team was still stabilizing the API.

One of the first hurdles I ran into when getting started with Rails 4 is sending/receiving mail locally. I’d wired up my basic app and started to sign in for the first time when I realized that I’d given the confirmation email no way to go anywhere. With some authentication gems can loook in the logs for your local rack server and see the confirmation token, but that gets old quickly and you’re quite limited in what you can do.

###Ghosting Around I’ve been tinkering around with Ghost recently and found it to be a new but promising platform in the main. There are certainly some things it will need to achieve any sort of significant user-base (plugins, apps, etc., which are coming in future releases https://github.com/tryghost/ghost/). At the very least, it’s great that there are open-source, well-supported options for blogging platforms that aren’t Wordpress and it’s cousins. I suppose it can’t hurt Nodejs and Javascript Development in general either for there to be more people using node-based platforms either.

Interviewing as a developer nowadays is at the same time pretty exciting — technology is playing a crucial and exciting role in our cultures and societies — and harrowing — tech companies are engaged in what I’ve often heard described as a “talent arms race.” As a result, there are quite a few posts, talks, books, &c. about how to crack/solve/pass the coding interview. This post isn’t about the whiteboard or problem-solving end of things, where the company is evaluating you, but rather about the part where you get to evaluate the company.