Why I Use the MIT License

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.

Read on

Why Define a Mongoose Schema?

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.

Read on

The Catfish Coder Strikes Again

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.

Read on

Another Way to Install PositiveSSL Certs on Nginx

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.

Read on

Being a Developer Is Not About Writing Code

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.

Read on

Quickie: Find Out Which PHP Extensions Are Installed

If you write PHP long enough you’ll eventually come to the point where you want to use some of its extensions. But are they enabled? Are they even installed? Here’s how to find out in a few key strokes.

Read on

Is Paying for GitHub Worth It?

We all have personal Git repositories that we need to keep private. Surprisingly, most people use Git exclusively for version control whether it be for public or private repositories. Many of those people end up making their private projects public to avoid paying the monthly fee.

I just subscribed to GitHub’s personal paid account which costs $7 for unlimited private repositories. Today I want to talk about why I’ve decided to host my private repos on GitHub and if it’s worth the price.

Read on

Forking Is Legit

Everyone loves GitHub. No one likes to be tricked. That’s why you should always use their convenient fork button to maintain your own copy of a project. This sounds obvious but you’d be surprised how many people are maintaining duplicate copies of popular repositories in non-forked form. Sometimes this is a simple mistake or misunderstanding of how Git and GitHub actually work but unfortunately there have been so many cases of abuse on GitHub involving “code theft” that maintaining your own copy of a repo any other way will be considered abuse by default.

I recently wrote about a case where one of my open source projects was being misrepresented as someone else’s work. This got me thinking about forking and what the MIT license really means. Today I want to get into more detail about why forking is so important and what the MIT license allows you to do with someone else’s work.

Read on

Clean Code Is Good Code

When it comes to code style I am a hardcore extremist. I’m not talking about things like spaces vs. tabs. What I’m getting at is clean, readable code. I’m into its visual appeal. Clean code is code that looks like a pretty pattern from across the room. It’s code I can understand a year from now. Clean code is good code and good code is working code. Let’s talk about what clean code is and how to write it.

Read on

Dotnever: Keep Secrets in Your Project Without the Use of a Library

Let’s state the obvious here: you don’t want to store secrets in a public Git repository (usually on GitHub) but you need to use those secrets to run your app. It’s a conundrum. How do you keep API keys, hash salts, passwords, and other sensitive information out of your public repository but still available to your app at runtime? The answer that most people have settled on is the very popular dotenv module/package/whatever your language of choice calls libraries. This module keeps your secrets safe in a .env file ignored by Git that’s stored in your project’s root directory and it’s contents are automatically loaded as environment variables when the system starts up. It’s a great idea but we just don’t need it anymore. Here I’ll offer up an alternative to dotenv, when dotenv makes sense to use, and why most projects can safely and easily ditch this library.

Read on