Daniel R.

I recently noticed I was getting low on space on one of my EBS volumes I mount on my EC2 server. After doing some research (aka Googling) it seemed like a simple procedure: umount, snapshot, create volume, resize, and mount. I even found a concise page that detailed resizing an EBS volume with sample commands. However when I got to the resize step I ran into an error along the lines of "The filesystem is already XXX blocks long. Nothing to do!". Turns out I didn't mount the complete EBS volume as a drive but instead partitioned it. The snapshot and create volume steps had increased the size of the EBS volume but not my partition. Without a graphical interface the prevailing recommendation to use gparted didn't help. Thankfully I stumbled upon another blog posting about resizing partitions using fdisk without losing data. While that post dealt with another virtual server service the same basic principles applied. After carefully deleting and recreating the partition on my EBS volume keeping the starting sector and file type the same resize2fs finally worked and I was off to the races. In retrospect the partition table hacking makes sense that it would work but isn't something I would have thought to try.

Tags: aws ebs ec2 neophi

Posted by Daniel Rinehart at 10:43 PM | Permalink | Comments (0)

I'll been a little quite on the blogging front as of late, besides the occasional user group post. The main reason for that has been the last couple of months I've been heads down doing server side Java development for a cloud computing infrastructure using Amazon's Web Services for S3, EC2, SimpleDB, and CloudFront. All that is the back end for some amazing Flex based applications that Allurent has in the works.

Being back heavy on the server side is a mixed blessing. Its an area I've done a lot of work in, in fact many of my first technically oriented posts on this blog where about Java. As a result I'm not playing with that many new things. The flip side is that I've been able to crank out a bunch of high quality code which feels good. Using Eclipse for Java development has unfortunately made me realize how far Flex Builder has to go to be a truly productive editor. Top three things I'm missing when working on ActionScript and MXML code: code formatting , MXML organize imports, and right-click run as FlexUnit test.

Allurent practices peer review before check in and automated unit testing. In order to make reviews effective we've established a coding standard so that anyone looking at someone else's code won't be distracted by funky formatting. Consistent formatting also makes looking at file differences much easier, eliminating the angry fruit salad only the whitespace changed difference report. Alas, without automated formatting support time gets wasted tabbing and spacing files to keep them readable. Likewise the need to launch an external program and occasionally tweak files to run a single TestCase or method increases the barrier to writing unit tests, which is never a good thing. Thankfully, Flexcover helps us keep tabs on areas we are lacking.

Java does has a big head start on Flex/AS3 for getting the tooling in there. Progress is being made, but for someone coming from the Java/Eclipse world, it's frustrating at times.

Tags: aws eclipse flex ide java tdd

Posted by Daniel Rinehart at 9:50 PM | Permalink | Comments (0)