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.
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.
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.
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.
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.
Becoming a developer is the hot new things these days. We’ve got a tech bubble that’s ready to burst any day now and everywhere you look you see companies and investors hammering and yammering on about this idea that “everyone should learn to code”. First of all, I disagree with this statement but supposing it’s true, it creates an environment where competition is fierce and people will do unethical things in order to make it in this market. I recently had a bad experience where some of my open source code was stolen and misrepresented as someone else’s code. What it all boiled down to was trying to set up an impressive portfolio for potential employees. In the interest of being kind I won’t be naming names and changing some details because this isn’t about shaming people. This is a true story of stolen code. For those who would misrepresent others’ code as their own: take it as a warning. For those who’ve had code stolen or are afraid of it, you’re not alone and maybe this will help you figure out what to do if it happens to you.
I’m one of those weirdos who wants to code on my phone. Sometimes I’ll just get bored waiting in a lobby, riding on the ‘L’, sitting at a boring party, or sometimes I just don’t have my MacBook near me and inspiration strikes. A year ago I would have thought complete project management on iOS was impossible but it turns out you can now do everything from writing code, SSHing into servers, and managing Git repositories all from the comfort of your iPhone. Today I’m going to show you how you can manage any coding project from your phone.
Services like Heroku, Elastic Beanstalk, and the rest are great tools for “easy” and “fast” web application deployment. While I can’t deny the benefits of these PaaS providers I think that some of their users are doing a disservice to themselves by choosing to use them. When PaaS services like Heroku get used as a developer’s first introduction to application deployment it can have a lasting, sometimes negative impact on their growth trajectory.
I’m currently teaching a web development immersive course at General Assembly and we’re on the section on MVC. We’re using Ruby with Sinatra to teach MVC and a pattern I’ve noticed is that students have a PHP style mindset about how routes are handled in a modular Sinatra app. By “PHP style mindset” I mean they seem to think that the file names have something to do with how routes are rendered. I want to cover how non-PHP web applications (including but not exclusively Sinatra) handle routing today so we can clear this up for beginners to Ruby, Node.js, Python, or other dynamic languages once and for all.