Over time my vm has grown to fill all 10 GB of diskspace I originally allocated and I have to constantly fight against filling the disk. Enough was enough and I decided to finally figure out how to grow the vm disk or setup a new one with bigger disk and migrate. Good news, it turned out to be less pain to grow disk then setup new vm.

How did I do it you ask… glad you asked.

1. Got a hold of vmware-vdiskmanager tool
   1. I use VMWare Player that does not come with this tool so I downloaded the Virtual Disk Development Kit
2. Run the vmware-vdiskmanager tool against your virtual disk
   1. Here is VMWare KB article I used detailing how to do this.
3. Resize partition of virtual machine to use new diskspace.
   1. I used GParted Live to do this
4. Enjoy the freedom from nagging popups warning you about disk space.

Being a big football fan I had been search for an excuse to do something related to my favorite sport, and this was the perfect one.  The only disappointing thing was finding out the truth about just how little my beloved Seattle Seahawks get attention from the media.

I got done with the tutorial and was stoked to try running unit tests on an existing project from within netbeans, but I quickly hit the wall when I tried running a test:

Figured no prob, I’ll just open the project properties and set the test directory.  Hit another wall, that field is read only and won’t let you type in it.  After some more playing I finally stumbled across the solution for telling NetBeans about an existing tests directory.

You have to right click on the project and select Test:

After doing that you’ll get the dialog asking where the tests dir is:

Once you set the test dir Netbeans will know where to find you’re tests and you’ll be good go:

That’s all well and good, but what if you ever want to move the test directory?  You’re up a against the same problem where the test directory in the project properties box is a read only field.  Here are the steps I took to be able to get around this:

1. close the project if  it is open
2. find your nbproject direcotry (in the project root by default)
3. pop open the project.properties file inside of the nbproject directory
4. look for the line with the test.src.dir variable
5. edit the value or remove the line and go through the steps above for telling NB where the test dir is

Our first stab at it was utilizing ini format configs and the Zend_Config_Ini importer.  The configs were nice and clean, and had support built in for being environment aware.  This also is the approach the documentation seems to be pushing, almost anything that utilizes a config example in the documentation utilizes ini style configs.

A couple thoughts kept creeping into my mind though.  Whats the performance of converting ini file into the final config object going to be like?  How does it compare to other possible approaches to loading the config object?

Only one way to find out.  Time to fire up the PHP Raceway (my little homegrown testing framework for testing out these sort of things).  What I did was take the example config from the quick start documentation and added a config section for an array of data, then set up that config for trying out the three different approaches.  First is the standard ini way, second is building an array in php then building the config object from that, and third is creating a blank config object and loading it by hand.  Here are the racers.

The Racers

The INI approach

Instantiation Code:

Config File:

The PHP Array approach

Instantiation Code:

Config File:

The PHP Config Fill approach

Instantiation Code:

Config File:

The results

*times are in seconds*
laps = 10000

PHP Array Config Format is the WINNER!
total time = 2.70539808273
average time = 0.00027054

Ini Config Format results:
total time = 4.37592101097 which is 1.67052292824 slower than the winner
average time = 0.00043759 which is 0.00016705 per lap slower than the winner
this racer took 62% longer than the winner

PHP Config Fill results:
total time = 3.37267208099 which is 0.66727399826 slower than the winner
average time = 0.00033727 which is 6.673E-5 per lap slower than the winner
this racer took 25% longer than the winner

Conclusion

If speed is absolute biggest concern, I’d have to say go with the building of an array and passing it into the constructer.  The array aproach made our eyes burn, so we ended up going with the hand filling of the config object because the little bit of performance hit was worth the trade off of and easier to work with and read config file.

One huge thing of note.  I run xcache on my systems, and to be honest could not image running a production system without some sort of opcode cacher.  If you happen to not have access to an opcode cacher these results will change drastically.  Check out what happens when I turn xcache off:

*times are in seconds*
laps = 10000

PHP Array Config Format is the WINNER!
total time = 3.0291249752
average time = 0.00030291

Ini Config Format results:
total time = 4.26868700981 which is 1.23956203461 slower than the winner
average time = 0.00042687 which is 0.00012396 per lap slower than the winner
this racer took 41% longer than the winner

PHP Config Fill results:
total time = 4.76278781891 which is 1.7336628437 slower than the winner
average time = 0.00047628 which is 0.00017337 per lap slower than the winner
this racer took 58% longer than the winner

If you you’re not running an opcode cacher looks like you had better steer clear of the hand filling approach and go with the array for speed or ini for maintainability.
In the end this sort of micro-optimization may not gain you much in terms of noticeable real world performance, especially when you compare this to the cost of database or api queries.  But if you’re a speed freak, or are trying to cut down on the work your server is having to do during the day, this is some good food for thought.

I couldn’t figure out why a string kept coming out with gibberish on the end.  The app was truncating the string because it was too long, and the spot it was getting truncated at was at a single quote mark.  My initial thinking led me down a road where I thought perhaps it was one of those goofy quote marks and maybe it had gotten incorrectly encoded along the way and was not proper UTF-8.  After determining it was not an encoding problem one of the guys at work reminded me that UTF-8 characters can be mutibyte, and perhaps it had something to do with that.  After a little research, sure enough, the substr function I was using is one of dumb functions and was chopping that multibyte character in half, leaving only the gibberish.

In PHP < version 6 the core string functionality generally disregards the fact that charters could be multibyte, and just assumes 1 byte = 1 character.  In my research I ran across a great page that has a rundown of the different problematic string functions and their level of risk when it comes to dealing with UTF-8:   Handling UTF-8 with PHP [Web Application Component Toolkit].

My particluar situation was resolved by not chopping in the middle of words and instead finding and chopping at the preceding whitespace, but if you don’t have the luxury of tweaking your logic, I highly recommend taking a look at the Multibyte String Library, or procrastinate until PHP6 is out :)

The Accidental Businessman: Communities.

Now I’ve not actually been part of the Ruby community, but I can tell you that when I cross paths with someone who is from it, I generally come away feeling the same way that Marco does.

The contrast of the PHP and Python communities was pretty good.  Having recently dipped my toe into the Python community I would have to agree with the keg party vs study group metaphor.  Though I did tend to find the python folks overly harsh and often misinformed when it came to criticism of PHPers.  Maybe our party music is disturbing their studies :)

Just launched a redesign of my wife and I’s personal blog and photo site.  You can read about some of the motivation on the MossCat Reborn post over on mosscat.com.

The work involved was a new page design and creation of a Wordpress theme from that design.  I made use of the Tan Tan Flickr Photo Album plugin to incorporate our flickr photos.  I’m very pleased with how it turned out.

The only casualty along the way was IE6 due to the png alpha used in the background images. There is a nice article on 24Ways.org discussing the issue.  I gave the SuperSleight solution a try, but it didn’t work very well, plus  I also feel that it is somewhat my duty to help the web move forward by doing my part to let IE6 die, so I’m content with the page looking like garbage on IE6.

The design utilizes YUI Grids CSS for the layout and YUI Base CSS for the style foundation.  I investigated a number of other css frameworks that are currently out there such as BluePrint and 960 GS since I’ve used YUI in the past and wanted to see what else there was.  There is a lot of great choices out there, and all have a little somthing to offer, but ultimately I came back to YUI CSS because I preferred its documentation, flexibility, and capabilities over the other options I found.