Topper’s Blog

http://blog.phusion.nl/2009/03/01/phusion-passenger-211-beta-released-thanks-sponsors/

• Support for Rails 2.3
• Improved compatibility with other Apache modules, such as mod_rewrite
• Ruby 1.9 support
• Support for NFS setups
• Various I/O handling and scaling improvements and fixes
• Improved mod_xsendfile support.
• Ability to disable Phusion Passenger for arbitrary URLs (PassengerEnabled option)
• Improved application compatibility
• Better cross-platform support (including OS X)
• Non-interactive installer
• Improved command-line admin tools
• Ability to display backtraces for all threads
• Improved security
• More customization options for exotic systems/setups
• Various usability improvements
• Various other minor improvements and bug fixes

This thing is really starting to look like a great and simple way to deploy *real* apps.

Hiivelogic: My Video and Slides from Acts as Conference 2009

Slides have a great quote from Steve Jobs and the talk is really great.

Saying no to features is really difficult, but hugely important. It’s nice to see Dan Benjamin pushing developers to push back on requirements. It’s hard sometimes, but the end-product is really worth it.

I think the part that he doesn’t dig into deeply enough is true understanding of the market your product is going to end up in. Too many developers get caught up in the code and the computer aspect of their product. It takes a lot of work to try to understand the user and the market surrounding the user.

A lot of times understanding the product is harder than writing code, but it’s something that everyone in your team really needs to spend a lot of time educating themselves on in order to create a successful product.

DesignAday – Truism

“Broken gets fixed. Shoddy lasts forever.”

One of the developers I work with said this after I complained about a lingering issue in one of our products. It rings true. When deadlines are tight, and there is more work to get done[...]

I know this is true for any website I’ve ever worked on (except the sites that I have created myself). You have experience with this?

h/t Daring Fireball

I followed the instructions at the phusion passenger site and couldn't exactly get my app to run in a suburi - it kept trying to use that suburi when looking up routes.

I had found this:

WRONG!

However, there was a deprecation warning - and it seemed not to work at all. I then stumbled upon this which seems to work:

RIGHT!

If you care - my virtual host looks something like:

Made a rails-based pastebin today: http://github.com/tobowers/pastebin/tree/master. Very much alpha-ish code (without specs) but it seems to work fairly well, and I didn't see another rails pastebin out there.

Easy to add support for tons of languages. Right now it only displays the options for rails, ruby, javascript, plaintext, css, html, actionscript.

These two projects are pretty incredible (much nicer than the syntax gem):

http://textpow.rubyforge.org/index.xhtml
http://ultraviolet.rubyforge.org/usage.xhtml

H/T Dan Benjamin

This is really cool... check out the carzilla! This is the first time I've ever seen tilt-shift video (seen the photos).

Metal Heart from Keith Loutit on Vimeo.

I know it's kind of cliched to complain about Time Warner, but...

1. Cable went out at 5pm yesterday.
2. Called. Telephone system says: Customers in Brooklyn, your cable might be out from 4pm to 6am.
3. This morning. 8am. No cable, no internet.
4. Call. Oh I'm sorry sir - my computer says your area might have cable out from 12:42am to 3:30pm today

A shifting outage window. If only we could have those at all our jobs. Also - no warning, and no information about the *old* outage window available to their customer service reps.

Agile is doing great for developers - how can we make it more "other more deliverable-oriented person" friendly?

A list apart has done it again:

Getting Real About Agile Design:

We are told that the modern org chart is hyperlinked, but in many companies design is still a single point of decision. Designers must let go of perfection to produce rapid, iterative work: “90% right” solutions are par for the course for Agile. This can be counterintuitive, but for better or worse, Agile prioritizes the timeline over virtuosity. Certainly it makes designing to impress other designers harder. No great loss.

There comes a point at which compromises become too great, however. In the words of Alan Cooper, “there is no large group of people out there waiting in a breathless delirium to purchase your lousy product.” Best-to-market usually beats first-to-market, and designers naturally work well as quality custodians, lobbying sponsors for extra resources where required to do the product justice.