CLIs are a fantastic way to build products. Unlike web applications, they take a small fraction of the time to build and are much more powerful. With the web, you can do whatever the developer programmed. With CLIs, you can easily mash-up multiple tools together yourself to perform advanced tasks. They require more technical expertise to use, but still work well for admin tasks, power-user tasks, or developer products.
At Heroku, we’ve come up with a methodology called the 12 factor app. It’s a set of principles designed to make great web applications that are easy to maintain. In that…
.npmignore is a serious hazard in Node.js projects you should immediately quit using (except in one situation as outlined below). There is a better alternative that’s been built into npm forever that’s much easier and secure!
What is npmignore?
So I’ve got this npm package called cli-ux. It’s a set of common CLI UX utilities. It has a directory in the root of the project /test that contains the test scripts. To make the npm package a bit smaller, we could do without these files. …
Coding for the browser takes serious time. You need to deal with front-end JS, CSS, design, product, and a ton more. On the other hand, building for a CLI takes a fraction of the effort. This makes CLIs particularly great for prototyping out new functionality, offering admin/internal tools, or power-user functionality.
CLIs have a much smaller footprint as well. Less code and fewer dependencies mean there is less to maintain. The code you write today is much more likely to work tomorrow in a CLI than it would be in the browser—Chrome changes far more often than Bash. …
A little shell script
I often say the best code I’ve ever written is a little tool called gh. It’s a little shell script that has saved me countless hours over the last couple of years since I wrote it.
Essentially it helps you manage your local github repositories, but it’s so much more than it sounds. Like all great CLI tools, it offers you a new, better workflow just about every time you crack open your terminal.
It’s so useful I can’t believe how few people have started to use it. Friends and coworkers I have paired with have seen me use it…
This is part 3 of a 3 part series. Part 1. Part 2.
If you want an in-depth guide on how to get started with the MEAN stack, you should really pick up my book. Still, this should offer a quick overview to help you get started.
Here is the completed project.
Learn to love the boilerplate
As I’ve said in the previous posts, MEAN is all about boilerplate. You’ll be writing it yourself, or at least copy+pasting. I would try to make sure you understand every line of it. Just because it’s boilerplate and has to be there for the app to even get…
This is part 1 of a 3 part series on the MEAN stack. Part 2. Part 3.
The MEAN stack is a popular set of components used to build modern web applications. It’s quite a bit different from how we’ve architected systems in the past and offers the chance to build maintainable, scalable, fast systems. But first, let’s talk about the old way to build a web application.
The Monolith
The Monolith is that project you’re probably working on right now. It’s that Rails server that some long-gone consultants or ambitious 10x developers threw together to get the prototype out but now…
This is part 2 of a 3 part series on the MEAN stack. Part 1. Part 3.
This ain’t omakase.
Every component in MEAN is swappable, and somewhat paradoxically, not sticking to Mongo, Express, Angular or Node is what makes MEAN great. While doing so will mess with a tidy acronym, I trust that your linguistic skills match your engineering skills and you will be able to find a suitable replacement (the MANK stack? MAKN?). Even Node is somewhat swappable, though if you swap that out this really just becomes service-oriented architecture.
MEAN is important because it gives the engineers…
The best way to be a better engineer
I don’t think engineers are very good at pairing. I know I wasn’t, and it was a big reason why I took my previous job at Carbon Five where I was pairing all the time. In addition to being a well respected shop, I thought forcing myself to pair all the time might improve my ability at working with other developers, explaining concepts to others, and might even make my job more enjoyable.
I should mention before I go further, this post is not necessarily advocating Carbon Five’s pairing philosophy nor admonishing…
Browserify? Require.js? Doesn’t Angular.js have modules?
Update 2016–04–17: I wrote this article almost 2 years ago for Angular 1.x. This article is still tremendously popular somehow, but I want to warn that it may not be the best for Angular 2.x or other methods of building JS front-ends. I have spent almost all my time writing CLI code since I wrote this, so I have really no context to say if this is still the best practice I considered it to be in 2014. Still, I offer a simple solution that many have said they prefer to more complicated setups.
Burke Holland had a fantastic post…
An open letter to my framework
I remember when we first met. I had been with C# and ASP.NET at the time. We were at the Borders Bookstore in Corvallis, Oregon, must’ve been Summer of 2009 — a playful, romantic season in the Northwest. I was deep into the Microsoft stack at the time, and (as you are aware) have the tattoo to prove it.
ASP.NET MVC was a new tool that came out I was totally into. Gone were the days of trying to manage HTML pages through a stupid GUI designer and ridiculous ViewState, I could simply ship HTML angle brackets…
