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.

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.

Maybe I’m too particular, maybe it’s the questions I asked, but spending just as much time with google  as I did with this service or using the “I’m feeling lucky” button would have yielded me better results.

I asked about what would be the best cloud computing platform and it did not take into account my particular situation and so half the answers were of no use to me (a flaw Alex also noticed).

I asked about which longboard I should buy (now that the weather is getting nice I’m hunting for one), and it new nothing of my question and would not allow me to start a new topic since I had not used the service enough.  I guess it is good for spam blocking, but annoying.

I also threw hunch a softball question after it crashed and burned on the first two and asked about which mac would be right for me.  It did manage to pick the type of mac I’m currently eyeballing but did not offer any help as far as which configuration or the type of customization I would need to make it useful for me.  It helped point me in the general direction but failed to yield what I consider a truly useful result.

Hopefully it can get better with time as it “learns” from the crowd, but for now it is just a novelty.

I was doing a little research and ran across this awesome, and extremely funny, video of the presentation Cal Henderson (from Flickr) did at DjangoCon 2008.

He is right on the money with many of his points.  If you never expect a site to take off, or have a lot of data, many of these issues don’t matter.  But what if you get popular…. Do you then ditch Django? Do you spend the time hacking in solutions yourself for these issues?   I’ve only done one real  project with Django, but it felt like I was so far removed from the db layer that it would be pretty hard to dig in and create solutions for the Django db shortcomings.

For getting a project off the ground though, Django does rock.  It’s pluggable app architecture makes it easy to find solutions for common problems so that you don’t have to reinvent the wheel.  I guess you just have to be realistic about the expectations for the project and decide if launchability (aka getting the site built and live) is more important than easy scalability.

For those of you that might not be aware, today is Pi Day. In a show of support I’m sporting my own piece of Pi gear today:

And for even more Pi fun, how bout a slice:

3.
1
41
592
6535
89793
238462
6433832
79502884
197169399
3751058209
7494459230
781640628620
8998628034825

I decided this would be the perfect opportunity to try my hand at something new.  So I dusted off my Python skills and dove head first into the Django pool.  I have to say, I’m quite impressed.  I’ve been a hard core PHPer for quite a number of years, but have always held fond memories of my short stint as a Python hacker.

Django was a great excuse to play with Python again.  Like any framework, there is a good bit of learning curve to go from the overly simplified hello world type app to something real world.  Now that I’m done climbing the mountain, I can look back and see it was not too hard a climb and that the mountain was really a hill considering I was relearning a new language at the same time as the framework.  It blows my mind at how little code actually had to be written to create the fully functioning site.  Apparently its true: