Home › Programming
Coincidentally, a little over a week after I describe my favorite editor to put in web apps, they folks over at Basecamp announce their new editor: Trix.
Without actually integrating it yet, I feel like this is a safe bet on the next great editor for the web. Check it out at:
We’ve been lax in implementing CI in the latest project I’m working on. Now that decision has caught up with me and its time to implement something. I mainly held off on CI because I couldn’t bring myself to have to setup another Jenkins instance. I’m a long time user and fan of Jenkins, I even developed the Perforce plugin for it back when it was called Hudson.
But these days, I no longer want to manage servers, be they physical or virtual. Life is just too short. Instead, I’d like to use one of the new CI services that has cropped up in recent years. For something as important as CI, I’m not going to make a blind choice. Especially, when we’ve been spoiled with how customizable Jenkins is. So let’s get down to reviewing some build tools…
(Note: This article was originally written for the iPhone 4. Since then, we have seen the iPad 3 with Retina, and now the MacBook Pro. This technique works with all of them.)
The new iPhone 4 is certainly a marvel of technology. One of the surprising side effects it has is how bad it makes things look that weren’t designed for high-DPI displays. For the most part, text is automatically beautiful on the iPhone 4 1. However, images are a different story. What follows is my research and then the technique I used to update images on flowz.com. We use wordpress here and with this technique, image replacement is automatic. All you have to do different is upload the second, high-res file at the same time you insert the normal file in your post or page. The first thing we need to do is pull in CSS specific to high-DPI device(s) in a standards compliant way. Here is how you can do that: http://thomasmaier.me/2010/06/css-for-iphone-4-retina-display/ The trick being to use a CSS3 media query to target high DPI devices (*not* just the iPhone 4!):
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.
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…>
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:
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.
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.
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