Sharing Code Between Projects

Someone at Real World asked me about maintaining shared code between projects in Real Studio. He was using external project items (in XML format) and that makes it difficult to work with source control since the XML format isn’t really designed for that. We have a lot of code that we share between projects, both code that we’ve written like ActiveRecord and open source code or libraries that we’ve purchased.

We don’t try to share the code automatically. Instead we keep shared code in a separate project (ideally with testing code, although we’re not at 100%). That code is separately versioned and we update individual projects by copying the new version into the project’s that use it.

In our experience this works much better than trying to share code automatically. We work on a lot of projects and sometimes a project won’t have changes for months or even years. If the shared code has changed in the meantime, we don’t want to go back to the project that uses it and find that it may have bugs that were introduced by changes to the shared code.

This applies to other language also by the way. I can’t see myself ever having code shared between separate projects (with the exception of header files in C or C++).

If you search for vendor branches you can find some more information that’s specific to Subversion. We don’t use the vendor branch pattern ourselves but it’s worth knowing about.

Google search and Web Edition

If you use Real Studio Web Edition right now the contents of your app are invisible to Google. I think a lot of people are using WE for internal projects or for apps that need a user to log in before anything useful is available. This isn’t a problem for that kind of project but for some web apps it would be nice to have certain areas show up in Google’s search results.

This isn’t just an issue with WE, other AJAX based web apps have the same type of issue and Google has a document that describes how to make AJAX web apps crawlable:
http://code.google.com/web/ajaxcrawling/

The basic idea is that you have special hash tags for the parts of the your app that should be indexed. When Google sees those it asks your app for snapshot of what the app would look like after the JavaScript has been evaluated.

One approach that Google suggests for getting snapshots is to use something like HtmlUnit. HtmlUnit is a program that acts like a web browser but doesn’t have a user interface. It executes JavaScript just like a browser would and then you can extract the contents of the page.

I did a little bit of experimentation and found that this approach works for simple cases. I ran into a some problems with a real application but they probably have solutions. It seems like the best solution, though, is for WE to support Google’s approach itself. I’ve created a feedback report requesting this as a feature.

If there are parts of your app that could serve as entry points and you want to be able to drive search engine traffic to them, please sign to this report:
feedback://showreport?report_id=19412

Mockups Using Balsamiq

Our Senior Developer, Seth Verrinder, introduces us to a tool for creating simple and effective mockups. – Bob

Like most developers I’ve had to mock up user interfaces for a lot of projects.

In the past I’ve used two approaches for this: a) Get everyone in the same room and share a whiteboard or a piece of paper or b) use Real Studio to create an interface that doesn’t have any code behind it. I’ve even scanned hand drawn mockups and sent those in an email.

I hate using Real Studio (or any other IDE, it’s nothing against Real) to mock up interfaces. The problem is that the end result looks like it’s a real program, so if I don’t make it look nice then it looks like a program that sucks instead of a mockup of a nice program. The whole point of mockups is that nobody is sure exactly what should be on a window or how different parts of a program should fit together so polishing the UI is a waste of time.

Another problem is that a mockup that looks like a finished program is easy to mistake for a finished program by a non-programmer. This is a point I first heard made by Joel Spolsky over at Joel on Software. Unless the goal is to actually design the final interface for a program I would stay away from this approach.

The advantage of the whiteboard and paper approach is that nobody looks at a freehand drawing and thinks that the end program is going to consist of blue lines that aren’t quite straight. But the end result is usually kind of disorganized and it’s hard to store much less revise it in the future.

Enter Balsamiq Mockups. This is a very slick program written by Peldi Guilizzoni (originally written during nights and weekends while he worked at Adobe). It’s basically a wireframe drawing tool with a bunch of standard UI components like buttons, windows, scrollbars, and many more that look like they’re hand drawn. You can drag things around and change labels pretty much like a designer in an IDE except without any real limitations on where things can go since it’s all just a drawing.

The end result is a surprisingly attractive design that could never be mistaken for a working program or an actual UI. Mockups is developed using Adobe AIR and as a developer of native apps for Mac and Windows, I wasn’t sure it would feel quite like a native app and it doesn’t, but it also turns out that it’s been so well designed that it’s actually fun to use and there’s not really any learning curve to speak of. Overall, I highly recommend mockups to anyone who develops software for a living.