These days there’s lots of sleaze around, and one place where it annoys me is at the domain registrar GoDaddy.com. I’ve used them forever it seems — back when I saw their ad on AltaVista’s search engine. These days, though, I find their marketing to be sleazier than I appreciate. On top of that I’m not interested in paying the rates they require to keep your domain private, and for my new domains I’m interested in simple email setups and such. So Google Apps for Your Domain fits the bill quite nicely. It’s $10 per year, you get a GMail-ish setup plus more, and I don’t have to use GoDaddy.com.
I haven’t yet signed up with eNom for anything. I plan to purchase my first domain from them (via Google Apps) tomorrow. I may not be able to move all of my domains right away, but I think that by pushing my money to someone else that’s less offensive I’ll feel better about what it gets used for in the end. It’s small, but it’s one simple way to start standing up against the sleaze of the day.
It’s hard to believe that it’s been a year since my “burrito” podcastsonJSF. So what have I done in this last year with JSF? What is my opinion now and how has it changed?
Have you ever skipped out on a movie that was popular? Decided not to see it because it either didn’t fit your taste or didn’t mesh with your life in some other way? I have. I usually look back later on without regret. That’s the way I feel looking back at JSF a year later, but let give you some details.
Then run java -jar winstone-0.9.6.jar --warfile=hudson.war --httpPort=8081
You should see something like the screenshot below.
One of my favorite features of Hudson is the ability to watch the console output of a build in progress, like this one:
Other cool things include:
No more messing around with XML
I can setup a Hudson job and use it to run mvn release:clean release:prepare on my branch code. (Haven’t tried this beyond tinkering yet, though. Could possibly be manual or nightly job it seems.)
It’s easy to have several builds for different branches and see them all at once.
There’s a really cool build history graph that shows both the time it took to build each release, and whether it passed or failed — makes it easy to see your build trends on the team.
I’m looking forward to investigating it’s publishing of Javadoc and JUnit test results. I also want to see if it’ll do anything with Maven’s site generation. If so, that’d be a big win. I’ve fiddled with Continuum, but this just feels like a better setup to me, and the author seems eager to add Maven2 integration to it.
After having it around for a couple weeks, I’ve tentatively switch our build to use it. It’s just so easy to turn on, that it seems like a no brainer. If it doesn’t pan out then we can always turn CruiseControl back on, but I don’t anticipate that outcome. Something else I might try is to drop Hudson into Tomcat if winstone seems to strain, but I don’t think we’ll need that either. It’s built our stuff plenty fast in that little servlet container for a few weeks now, so I’m not anticipating any load increase to it — simply more publicity for it among our team.
Try it out. Let me know if you think it’s worth the switch.
This morning I experimented a bit with overriding the default HTML generated by validation errors in Rails. Instead of wrapping the <input> tag inside a <div class="fieldWithErrors"> indiscriminately (which was breaking the layout I wanted), I wanted to simply inject a new CSS class onto the HTML element.
I found one email showing how to use regular expressions to get the job done. It may work, but I wanted something that seemed a little less blunt. I’ve also been playing around with Hpricot lately as well. So I decided to try to combine the two. Here’s the first draft of what I came up with:
I then changed the CSS ever so slightly from the default scaffold.css:
The result looks like this:
The layout I had before is completely preserved, and I have the chance to color the input the way I want. I haven’t tried it with a <textarea>. Also, I tried to adjust for the possibility of other CSS classes already existing on the element, but I’ve only checked it in irb. Let me know if you’ve got improvements to this approach; I’d love to hear ‘em.