While there are some great diff tools out there, there are very few good merge tools. My favorite diff tool is Kaleidoscope. And there are several others I wouldn’t mind using.

However, Kaleidoscope does not do merging. Too me, software development requires much more merging then diff’ing. And many times, github.com’s HTML diff view is more than sufficient. Heck, even command line diff works just fine for small differences. Looking at diff’s is easy and paying money for a tool that only does diffs is something I find hard to swallow.
<Read on…>

 
 

Phatness.com is the personal blog of Mike Wille

I'm a developer with a passion for building products.

You can find my slides from the M3 Conference in Columbus, OH here.

Most days, you can find me stirring the cauldron at Brilliant Chemistry.

 
 

First off, I do love Groovy & Grails. We’ve built a product with it: http://bounceoff.com. And I advise any dev shop that is Java focused to stop all development and switch immediately to G&G.

However, there are dirty little things that always ruin an otherwise perfect experience. This could be a very long post, detailing all of the tiny nits I have with Groovy & Grails. It wouldn’t be fun to write and it wouldn’t be fun to read.

Instead, I can encapsulate everything that is wrong with Groovy & Grails in one quick example. <Read on…>

 
 

Kaleidoscope is a beautiful, relatively new text and image comparison tool for Mac OS X.

When I say beautiful, I mean it has to be the most spectacular, mouth watering application I use in my development workflow.

But it has its problems. <Read on…>

 
 

Am I the only one that despises the new request mapping in Spring 3?

Why has everyone gone GaGa over spreading out the URL mappings across dozens, if not hundreds, of files?  This is a step BACKWARD people!

There was something extremely convenient about having one place to keep track of all of your URL mappings.  Hello Grails, you fantastic crispy UrlMapping.groovy, you!

My love affair with Spring is certainly in the twilight stages.

 
 

Submitted a fairly large iPhone app to the App Store. Look at this:

Hello Mike,

Thank you for submitting BounceOff 1.0 to the App Store.

We’ve completed the review of your application but this version cannot be posted to the App Store because it crashes when the user searches for a name or email without any contacts on their device. We have included additional details below to help explain the issue, and hope you’ll consider revising and resubmitting your application.

Using iPhone 3GS running iOS 4.0.2, here is how we found this crash:

Steps to reproduce:

1. Open the application
2. Select the “Buckets” tab
3. Select a Bucket
4. Select “Invite People”
5. If user has no contacts on the phone, and starts to type a name or an email, the application crashes.

We have attached detailed crash logs to help. If you need information on how to read crash logs, you may want to review the following TechNote: http://developer.apple.com/iphone/library/technotes/tn2008/tn2151.html

If you have any questions about this response, or would like to discuss it further, please feel free to reply to this email. We look forward to reviewing your revised app.

Sincerely,

App Review Team

That was the rejection email from the AppStore. I’m entirely exasperated at myself for missing this bug. (You idiot, you should know there are people with no contacts on the phone!)

I am completely taken aback and amazed at how detailed this report from Apple is. I don’t get this kind of detail from team members! I fully expected a crashing app to be simply rejected with a statement along the lines of “It crashes, you idiot.” So this is truly great. Even more impressive is that it only took them less than an hour to get back to us once the app went into review. I’m completely happy at how they handled that. Kudos Apple.

However, what is not impressive: IT TOOK 8 DAYS TO GO INTO REVIEW. Yes, I submitted on Thursday morning. On Friday afternoon of the next week, it was reviewed. I guess, having a gate keeper wouldn’t be as bad if they didn’t take so long to get your app into review.

We are on day four of our resubmission. I fear that it will take another 8 days to go into review again. All reports from the experts (aka, chockenberry: http://appdevmanual.com/ ) say that you go back to the end of the line. Instead, it would be nice if it was more of a sliding scale. Say once resubmitted on the first rejection, you get put right back in for immediate review. In the case of further rejections, you go back farther and farther back in the line for each rejection. Even some variation on that. First time, we let you slide back in. Every other time, back to the end of the line.

 
 

I picked up an iPhone 4. How?

I woke up at 3 AM the morning Apple started taking reservations. That day their store was having troubles taking orders. I kept checking almost every hour until I finally got a reserved phone at 10 AM.

On the June 24th, a friend and I got to the mall with the Apple Store at 6:45. The parking lot was empty, except for maybe 6 cars. I thought, great, Michigan’s economy might actually pay off this time. When we opened the doors, I was wrong. Apparently the hundreds to thousands of people parked in the back.

I waited in line for 4 hours and 15 minutes before I finally had my phone in my hand. I will NEVER DO THAT AGAIN.

Send it to my house next time.

The first thing you notice about the phone is that screen. That unbelievable screen. Oh yeah, and how it makes just about every image on the web look like shit. Well, if you are a website owner, there are some things you can do to make your website look better. Text is fine already. But you have to swap out your images for higher resolution counterparts.

The technique is only supported in the newest browsers. But so what? Who will be running IE 6 on an Android (You can be sure that Android handset makers will follow) or an iPhone?

From the solution I posted at Flowz:

The trick here is that we check to see if the font size for our special class is set to value declared in our high-DPI CSS file. (Our flag) It will only be set if the browser passed the media query. If the flag is set, grab every element in the DOM with the replace-2x class and change the src attribute to point to our high-res counterparts.

Go check it out:
http://flowz.com/2010/07/css-image-replacement-for-iphone-4-high-dpi-retina-display/

 
 

After starting up another Grails project and completely missing my text-to-speech solution for long build times, I decided to do something a little more re-usable.

I just released a Grails plugin that provides this functionality. It’s as simple as: 

grails install-plugin nadd-neutralizer

Right now, only Mac OS X is supported. Patches are welcome for other operating systems. Source code is here: http://github.com/digerata/grails-nadd-neutralizer

 
 

Grails docs go a long way towards being the only materials you need to learn how to use Grails. Unfortunately, it can miss a few things that are common use cases.

In any real world production app, you don’t manage your configuration from within your WAR file. How do you have a configuration file deployed out to your production server beside your WAR file?

Most of the posts out there about external configuration all talk about hard coding external config locations into a variable like so:

grails.config.locations = [ "file:${userHome}/${appName}-conf.properties"]

Well, that sucks. That is assuming, again, more about production then you really can afford. The configuration of the production system, isn’t up to the developer. It’s up to the Release Manager or System Admin or a whole team of people besides you. Rather than force them into accommodating you, the programmer, you need to make it easy for them to specify WHATEVER THE FUCK THEY WANT.
<Read on…>

 
 

This is a tip for those of you dealing with long build times, which for me, is anything greater than about 4 seconds ;)

The problem that those of us with NADD face is the second we are waiting for something to finish, we [alt|cmd]+Tab to a browser and start reading slashdot, rotten tomatoes, daringfireball, or any of a million other sites. Likely, you classify this “quick field trip” as multitasking and because you are so very good at multitasking (despite what all the experts say), you disregard the fact that your build was probably finished 10 minutes ago.
<Read on…>

 
 

Whew, Grails has some gotchas. It is so great for so many reasons. But WOW! There are some time sinks tucked away for you to discover. In the hope of helping others, here is a list of the ones that hit me.
<Read on…>