Yes, you can and you probably fucking should use a relational database in your Node/Express apps. Most data you come across is relational so I’ll never understand this dogma being preached that if you use Node as your back-end then you have to pair it with MongoDB as your persistence layer (a database). You know, that MEAN stack crap everyone cheers on. Bullshit! It’s utter bullshit and anyone who’s used Node.js whilst actually thinking about their data models can see it. You use the database that best fits your dataset. Sort of like that whole “right tool for the job” idea (which is excellent advice, by the way)? Now let’s get you set up with the Bookshelf ORM and do some relational database modeling. We’ll also talk about integrating this into an Express application.
Heroku is billed as the easiest way to deploy your apps no matter the language. Node.js, PHP, Python, or Ruby – they’re all super easy to deploy says their marketing materials. What they don’t tell you is that it isn’t that simple. The value prop is that you get to focus on deployment without having to worry about servers. Trouble is, while that might technically be true, you’re trading in one set of problems for another. There’s no one size fits all “how to deploy your app to Heroku” guide but there are a few tips you can follow that’ll at least get your in the right direction and help you think of things you might not have thought of.
MySQL is my production database of choice but I always forget a few commands like how to create new users and managing permissions for those users. That’s why I’m publishing my own personal MySQL cheat sheet that covers everything from creating new databases to managing users and permissions. I still haven’t switched over to MariaDB yet but seeing how it’s a drop-in replacement for MySQL this cheat sheet should work for MariaDB as well (their APIs are compatible, MariaDB just has more optimized internals). So here’s a MySQL cheat sheet. Enjoy.
If there’s one thing a function should do it’s return a value (except for void functions but that’s another talk for another day). Whether that’s an error object or something else doesn’t matter. When we call functions we expect responses from them so when a function like jQuery’s
getJSON mysteriously fails to fire off it’s callback it can be a frustrating, long process to debug.
I use the MIT license almost exclusively on all of my open source projects. As far as I’m concerned my best options are either to make my code proprietary or, if it’s open source, then I will always use the MIT license. I refuse to use the GPL because it’s far too liberal even for a liberal guy like me. The MIT license is a great choice because it allows you to share your code under a copyleft license without forcing others to expose their proprietary code, it’s business friendly and open source friendly while still allowing for monetization. Here’s why I use the MIT license and what it’s all about.
MongoDB is a non-relational (or NoSQL) database. NoSQL databases like MongoDB have the concept of databases and collections while relational databases like MySQL have databases and tables. In a relational database you define a schema for each table in the database. This means that your tables will have a pre-defined set of columns and a value type that save your datasets in each row. A NoSQL database like MongoDB is schema-less. Instead of storing rows in a table you create “documents” that are stored in collections. Each document can be thought of as a kind of very efficient JSON file and a collection is, well, a collection of those documents. If you’r first learning Node.js you’ll probably be exposed to a lot of “MEAN Stack” tutorials that use Mongoose as the ORM. A point of confusion with Mongoose and part of the reason why I’ve personally stayed away from it for so long is because Mongoose seems to force you into defining a schema for your models and documents. But if MongoDB is schema-less doesn’t defining a schema sort of defeat the purpose of using it? The answer isn’t a simple yes or no and that’s what we’re going to explore today along with ways you can have the best of the schema-less and schema enforced world using Mongoose.
It was only about a month ago that I posted a cautionary tale about a former student who stole code from their instructors and classmates. Now, only thirty-something days later, the Catfish Coder struck again. I’m tempted to act on my frustration and publicly out this person but I’m going to stay above that. Instead I’m going to focus on why anyone thinking of using someone else’s code as a portfolio piece either as filler material or to impress employers has a 100% chance of being caught. I’ll show you how you’ll get caught, how you’ll destroy your credibility, explain why it’ll destroy any chance of getting your foot in the door, and why you’re a total asshole for stealing code. Oh, and I’ll sprinkle in a little about intellectual property while I explain how open source licensing does not give you any right to claim ownership of any piece of software even if you’re a hardcore copy-leftist and use the GPL exclusively.
Comodo seems to change the way it issues SSL certificates every other day. I’ve written in the past on how to install SSL certificates on both Apache and Nginx but last night I bought yet another Comodo PositiveSSL certificate and once again I had to figure out how to properly install it along with the chain certificates. Here’s the most recent version of how to install a Comodo Positive SSL certificate on a server running Nginx.
If you write code for a living I feel bad for you. Being a developer is not about writing code. If your job is to write code based off a spec all day long then you’re not a developer. You’re a code monkey. There’s a huge difference between writing code and being a developer, an idea I’m going to explore today.