Archives

It has been a good run, but Ajax the buzzword will dip below the radar in 2009. That’s not to say that we’ll all stop writing JavaScript and using XHR in the coming year — quite the contrary. Full 100% of web applications will incorporate Ajax technologies, we just will use the “Ajax” buzzword less and less, much as “HTML” became just another acronymic noun in the early days of the web. So that’s not really controversial.

What’s really going to happen in 2009 that will impact all of us RIA developers? The first raft of Ajax-enable webapps will be undergoing maintenance. Supportability is the real test of frameworks, architectures and designs. How easy are they to support? How painful is the life of a maintenance programmer working on a Dojo codebase versus a JQuery codebase?

We’ve been emphasizing the use of application level MVC frameworks here of late.Why? Because we feel that the best and most sustainable metaphor for RIA’s is that of the desktop component GUI, not of the souped up webapp — client/server making its triumphant return. Without this guiding principle — that we are writing applications that consume backend services rather than backend services that display interfaces — we face escalating development and maintenance costs.

I hope then to see two front end web development trends for the coming year:

1. Abstraction away from the underlying browser platform. Widgets, components, whatever you call them; the average front end web developer shouldn’t have to tangle with the DOM or low-level browser events.
2. Adoption of application level MVC frameworks like PureMVC. A standard way of wiring up complex GUI’s will save us from ourselves. See Swing for a cautionary tale of woe.

What are you predictions for the coming year?

Share/Bookmark

When your http://localhost/~username/ sites go haywire, it’s time to dig into your Apache config files

As Rails pros know, Phusion Passenger allows you to serve multiple Rails apps on the same Apache webserver instance with few configuration or deployment headaches. When you install it in your local Mac dev environment, you can easily work on a bunch of Rails projects simultaneously without having to manually start and stop individual server instances all the time. The OS X Passenger preference pane makes deployment even easier. Just add a project, give it a custom local URL, and point it at a directory. You’re good to go.

But what happens if you’re already using OS X’s built-in Apache webserver to dish up local content such as PHP applications or static HTML? When I first got Passenger up and running, all of my local sites in /Users/<username>/Sites/ stopped working. It took a bunch of digging, but I eventually realized that something in my Apache configuration had gotten messed up during the Passenger installation process. I was missing the configuration file for my OS X user account. OS X generates this file the first time you enable web sharing for any individual user. It’s responsible for mapping your /Sites subdirectory to localhost URLs, so that http://localhost/~<username>/myapplication/ points to /Sites/myapplication/index.html.

Share/Bookmark

Here’s a slightly edited version of my Twitter feed for December 23rd, 2008:

1:59 PM: Wow! Rails 3 = Merb 2.

2:50 PM: Merb is fun to say. Merb Merb Merb Merb Merb. We welcome our new Merby overlords.

2:50 PM: Also twitter added actual people search, so it’s a weird day all around.

2:57 PM: Co-worker, over IM: “I feel like the communists and capitalists just joined forces.”

2:58 PM: Let’s see… the Rails/Merb backlash should start in about an hour. The backlash to the backlash is scheduled for Tuesday.

2:57 PM: Message from @faithfulgeek: @noelrap it’s not like MS just open sourced Windows!

2:59 PM: @faithfulgeek Only, one hopes, with a lot fewer bugs

3:04 PM: @greggpollack So when do we get the I’m RoR/I’m Merb video that ends with the two of them… well, I guess I’d leave the ending up to you

3:25 PM: Am I in a silly mood because I’ve been saying “Merb Merb” for the last half hour, or am I saying “Merb Merb” because I’m in a silly mood?

What have we learned from this? A few things:

• The combination of the impending holiday weekend and the weirdness of the news made me kind of giddy.
• All those people jabbering about how Twitter is the water cooler for the 21st century may be on to something. (I was working at home that day.)
• The Merb/Rails merger is a seriously surprising and weird piece of news.

Share/Bookmark

As I have discussed earlier, you can go very, very far in unit testing your view controllers using the following recipe, without the need to bend over backwards or employ any mocking frameworks:

1. Initialize the view controller in your setup using initWithNibName:bundle:.
2. Force the view to initialize by invoking the controller’s loadView method within your setUp method.
3. Write tests to assert dependencies or behavior.

This works well enough for view controllers, but when it comes time to test your application delegate, this simple approach can begin to break down. Unlike UIViewController, your application delegate is only initialized as a by-product of loading the NIB. Thus, to get this code under test I find OCMock particularly useful.

I show an example unit test below, and discuss how I approached the problem..

Share/Bookmark