Link Post: We Give a F*** How the Site Loads

That's right. The almighty F-word was breaking how some stylesheets were loading for deviants who were accessing the site from computers with overly sensitive system-wide profanity filters installed. These users' browsers likely stopped parsing the stylesheet entirely upon reaching the word in the stylesheet, leading to a fairly ugly and/or broken page.

This article points out two things:

1. It's hard to test for end user computers because you never know when something they have installed is going to mess up your site.
2. It's important to be professional ALL the time not just on things the end users are going to see.

http://dt.deviantart.com/journal/We-Give-a-F-How-the-Site-Loads-392679726

via CSS-Tricks

Keep Zend From Looking for a View File

I was working with PHPExcel in a Zend Framework and didn't want to have to create an empty view file for an action that's always going to create an Excel file. I looked it up and you can disable Zend looking for a view file using the code below.

public function downloadAction(){
    $this->_helper->viewRenderer->setNoRender(true);
    // output binary data here
}

Git Tags Not Showing in Github

I recently started messing with tags in git and I found to my surprise that when I pushed from my laptop to github.com that they didn't automatically get pushed with my changes.

You need to take the additional step of pushing your tags using the following command.

git push --tags <remote>

If you're pushing to your origin you can ignore the <remote> part.

Getting Started With Vagrant using PuPHPet.com

Note: I don't usually redo a blog post (the original will remain online for ever as far as I'm concerned) but I think that the landscape has changed enough in the last couple months that I needed to rewrite this post using a better solution.

Ideally, we should all be developing our code in our own little space on our own little local server. This allows us to easily make changes without messing up production code or stepping over other's work. This is usually cost prohibitive so we're "forced" to use virtual machines to make this a reality.

The problem we face is that each developer needs to have a virtual machine that is setup exactly (or nearly exactly) like our production server. This requires a long list of configuration changes that need to be made on every machine. For example, install the apache package, update this configuration file, setup MySQL so you can access the databases remotely. Then we run into more problems when additional changes are needed because the developer has to take time out of their schedule to make them on each machine. There are also passwords that have to be remembered and /etc/host changes that need to be made. You'll be in even worse shape if the deployment consists of multiple VMs. Read More

Link Post:Technical Debt Strategies

In software development, there is always a tension between two opposing forces: the desire to do it fast, and the desire to do it right. I could probably write an entire blog post on just that topic, but for now I’ll settle for the short version. If you do it right, then, later, when you want to extend it, or modify it, or use it as a jumping off point for branching out in a whole new direction (and you will always want to do these things eventually, if your software lives long enough), you can do so easily, with a solid foundation as a base. The downside is that it will take longer. If you do it fast, you get results faster, which means you can serve a customer’s needs before they change, fill a window of opportunity before it closes, or perhaps even beat your competitors to the market with your offering. But when you have to modify it later (which you will), it will end up taking even more time to clean things up than if you’d just done it right in the first place.

As someone who it going to have to deal with a technical debt problem in the coming months this article presents a good list of the possible ways to deal with it.

http://barefootcoder.blogspot.co.il/2013/07/technical-debt-strategies.html

50% faster paint time with Bootstrap 3

Paul Irish does a quick and dirty benchmark of Bootstrap 3 RC 1 and sees a significant performance increase due to their use of flat design.

[embed]http://www.youtube.com/watch?v=Z1IqzeA3XXg[/embed]

Link Post: What kind of queries are bad for MySQL?

A good rundown of queries that are "bad" from a performance standpoint. My favorite is the first one:

Any query is bad. Send a query only if you must. (Hint: use caching like memcache or redis)

http://www.mysqlperformanceblog.com/2013/07/19/what-kind-of-queries-are-bad-for-mysql/

Vagrant Reload

I was working on a Vagrant VM and I needed to refresh the configuration because I needed another package installed. Normally, I would just perform a vagrant halt and then a vagrant up so it would install the missing packaged but I mistyped 'halt' and I got the help screen. I noticed there was an option for vagrant reload which as it turns out performs basically the same process and halt and then up.

It may not be a great tip but it has saved me a little typing.

Getting Vagrant to Use A Different Base Box After It's Already Been Created

I've been slowly trying to work Vagrant into my workflow. I've found it best to use it when starting new projects (most of my old projects already have a existing VM) but the last couple days I've been fighting a problem where every PHP script on a VM takes 5 seconds to finish. I've tried everything from completely destroying the VM and starting over, creating a new PuPHPet configuration, and trying a different networking setup. In desperation, I tried changing the base box that Vagrant used from 64 to 32 bit and then downgraded from Ubuntu Precise 12.04 to Ubuntu Lucid 10.04 and I was shocked when those had no effect on what VM Vagrant used. Read More

Link Post: On Git's Shortcomings

I'm a big believer in git, so big that all of my new projects use it (and I'm very slowly converting my old projects) but it does have it's downsides. My biggest beef is how hard it is for less experienced programmers to use it because of the command line usage and how hard it can be to understand branches, rebasing, and merging (I know it shouldn't be that difficult). GitHub for Windows and GitHub for Mac is helping with this but the default way to learn git is still the command line.

This article has a couple complaints that I've heard before (the number of commands and access control) but it also has a couple that I haven't heard but might not every be a problem for you (large repos, and large contributors on a single branch).

http://www.peterlundgren.com/blog/on-gits-shortcomings/

Via reddit.com