According to Larry Wall there are three great virtues a programmer may posess. Basically, it says you have to be kind of an asshole to be a good programmer. I’ve met and worked with enough programmers to want to say that might just be true. But it’s definitely not a virtue to be an asshole. So try not to be. If you’re interested in what the virtues are then go ahead and click on through.
The Real Favicon Generator is a great tool. It takes your one large icon and turns it into a PNG or ICO suitable for every browser and platform on the planet. Plus it gives you the code to paste into your site. The problem is, it’s sixteen lines! For a favicon! There’s something wrong with the world when you need to bloat your HTML with 16 <link> tags just so you can have a pretty favicon on mobile, Windows 8, and a few other browsers. But I’m not in charge so I reluctantly stuck those sixteen lines into a partial and dutifully included them at build time. Lame.
If you’re coming to Node from a different server-side language like PHP you may find that deploying Node apps into production is weird, scary, and confusing. What’s with all the command line tools and the weird setups you need to do on the server?, you may ask. You may be used to dropping a few files into a public_html folder on your server and expecting them to “just work”. Well, not to worry. Publishing Node apps into production is different but once you understand how they actually work all those weird steps you have to take start making perfect sense. The better you understand how Node apps work the more comfortable and confident you’ll be when it comes time to deploy them.
If you use a Git hook to deploy your projects you might have run across the problem of accidentally deploying the wrong branch. This can easily be resolved by adding a check in your post-receive hook but what if you have a project that you build locally before deploying and your dist folder is not under version control? I wrote a quick inline Grunt task to guard against accidentally deploying the wrong branch. You can use this code directly within your Gruntfile. I may roll this into a plugin in the future.
So you have a new MacBook and you know what HTML5 is. You self identify as a programmer or developer or designer or, hacker. You’re the resident “tech person” at home and at work and one day your boss asks you to build him a new website. This plants the seed of an idea that’ll grow into the poisonous plant of a thought. You’re going to be a “web designer”. You’re going to have a website and business cards and, yeah, a “real business”. Please save yourself and everyone else the trouble and don’t do that. Before we get into why you shouldn’t, I’ll be the first to admit that I have been guilty of most of the mistakes I’m about to call out. So if you feel offended or find you’re guilty of some of these, don’t worry. The point isn’t to make you feel bad, it’s to give some perspective and hopefully plant the seeds of some better ideas.
It’s New Year’s Eve and website owners everywhere will be calling up their developers asking them to update the copyright year on all of their websites. It’s your job to update the copyright notice but this is the year you finally realize that simply displaying the current year isn’t enough. You need to show the year the site was created up to the current year (e.g. “2001 – 2015”). On top of that, you’ve got a mix of static HTML and dynamic PHP pages. How does one dynamically generate a copyright notice on a static page? Easy: JavaScript with a fallback or PHP depending on your stack. If you use any other language the code will be roughly the same with some syntax differences thrown in.
If you’ve used any jQuery plugins in your time – and lord knows I used to live on jQuery plugins – then you’ve probably seen the example code tell you to wrap your plugin calls in a $(document).ready() or $(window).load() but do you know what they are or how they’re different? Most people are very familiar with $(document).ready() but not a lot of love is given to $(window).load. If you’re trying to understand how jQuery works and move beyond the copy-paste mentality that many new JavaScript developers start off with, here’s a quick but thorough explanation of these functions and how to use them.
When I first started using the terminal for development it was a strange and awkward thing for me. I couldn’t stop thinking that having a GUI application to run the tasks I was trying to complete was superior and easier. Now, five years later, GUI apps get in my way more than help. GUI apps have become cumbersome to use while the terminal seems natural. If you’ve never used the terminal much in development or you’re just getting into it, here are some tricks I’ve learned that’ll change the way you do things forever.
I was checking out the source of a site that used some Google Web Fonts today and noticed they were loading them through the JavaScript FontLoadewr script. Being ever the curious one I began to wonder what the benefits were and if they were worth it. In the process I learned some new tricks to help with site performance and formed some strong opinions on how I won’t be using Google Web Fonts.
I upgraded my main server from Ubuntu 12.04 to 14.04 yesterday and after the upgrade Apache didn’t want to serve anything but 500 errors. Turns out that Ubuntu 14.04 brings with it an upgrade to Apache 2.4 (used to be 2.2). One of many issues were errors stemming from .htaccess files. Here’s how to fix those.