Every day at Atomic Object starts with a brief, informal meeting. In the corporate world, “team” meetings leave a bad taste in most people’s mouths’ as being unnecessarily long, drawn out and ultimately of little value. AO’s approach is a bit different than your typical sit-around-the-conference table meeting for a few reasons:

1. Meetings create a “brain trust”. Clients generally have two or four employees working on a project at any given time. Morning meetings give employees who are not necessarily involved with the project a chance to offer their wisdom, advice and problem-solving skills. In effect, when hiring Atomic Object for your project, you are receiving the collective wisdom of the entire staff.
2. Meetings unify the team. It is not always easy to tell what various groups are working on. This is a chance to talk about what each employee is currently involved with. Knowing what others have worked on in the past provides employees with a mental reference of who may be valuable to their projects in the future.
3. Anyone may suggest a topic. Throughout the day, as ideas emerge, all employees are encouraged to add to the next morning’s meeting agenda by placing a short note or keyword on the chalk board. The chalkboard helps direct focus to the most relevant topics at hand.
4. The meetings are cheap. Standing keeps it short. No chairs, no tables allowed. Meetings rarely go much past the five-minute mark. This also eliminates the possibility of distraction by iPhones, laptops or any other device that could feasibly be resting on the table in front of the employee.
5. Learn from everyone’s mistakes. The reality is that while we always try our hardest not to, we do sometimes make mistakes. The sharing of information and lessons learned at the meetings can save other employees from making similar mistakes. This ultimately saves the company time, improves efficiency and increases client satisfaction.
6. Stand up meetings are very focused. Once the meeting begins all topics are work-related. No small talk. Topics all relate back to relevant issues surrounding the office, current projects or the industry at large.
7. Meetings are scheduled at 9AM, with mandatory attendance. This spurs employees to arrive at the office consistently and on time. In a tech office where work can theoretically be done remotely, this creates motivation to spend time in the office on a consistent basis. Time spent in the office often results in spontaneous collaborative efforts and problem solving sessions that in turn benefit our client’s projects and our efficiency.
8. Employees keep each other updated. The tech industry moves quickly. A mountain of new information is published daily. The meeting gives employees a chance to share the information they have personally found most relevant and valuable, which others may have missed.
9. Introductions are made. As new employees and customers appear around the office, it gives everyone a chance to say “hi” and meet the new face. This makes the new hire feel welcome, and fosters community within the office environment.
10. Meetings generate conversation. As topics are discussed, ideas are fostered which lead to additional discussion. This leads to discussion and collaborative opportunities among employees, after the meeting is adjourned.

Rapid Growth TV created a video about Carl Erickson and Atomic Object. Check it out on the Rapid Growth Media site.

http://www.rapidgrowthmedia.com/features/rgtvatomicobject.aspx

Over the past few months I have been involved with the development of uladoo.com. Uladoo is a small, in-house, collaborative web project between Atomic Object and David Christiansen. Uladoo provides a simple means of creating, updating and sharing charts for people who desire to track their daily activity. Uladoo uses Twitter for creating and updating charts.

David had the idea for Uladoo in the midst of a weight loss effort. He was already an active Twitter user and thought it would be convenient to be able to tweet his weight and have those tweets tracked.

I thought David's idea was interesting because he identified that Twitter could be used as an application's data source. At the time, most of the applications related to Twitter were on the surface of the Twittersphere, facing inward. Twitter clients, tweet management tools, and tweet analysis were all hot. These kind of applications were aimed at enhancing and organizing a user's Twitter experience. David realized that we could think of Twitter as a communication protocol to power Uladoo. Users could input their chart data through a multitude of Twitter clients and we could use the Twitter API to pull our application data.

Because this project was in-house, we had the luxury of being able to exercise our product design and development practices as we saw fit. We viewed the idea as experimental and decided to forgo user research. We decided to release a minimal product that was easy to learn, account free, and simple to use. If the idea took off, we'd develop it further.

Being account free was a curse and a blessing. During our discovery and design phase we kept identifying all kinds of complexities. What happens if a user tweets to the same chart twice in a day? What happens when they skip a day? What level of granularity should we display the data? We kept getting bogged down into the details and started to think that a user would have to provide preferences. We didn't want users setting preferences via Twitter because we thought that violated our principles of Uladoo being simple and easy to learn. Our principles forced us to make judgment calls and design the behaviour in accordance with our idea of the general case. Our self imposed constraints allowed us to move forward and not sputter out during the design phase.

We were able launch Uladoo within five weeks. We spent about a week in design and discovery and four weeks in construction. It was a great experience participating in a small, focused project. We're continuing to add features to Uladoo. After we had about 100 people using Uladoo, we decided to provide a 10, 30 and 60 day view of user charts. We just added a feature allowing users to embed a chart in their blog or web page. Check out the Uladoo Blog for updates on new development.

Is JRuby a realistic candidate for authoring complex desktop applications?

Yes.

UPDATE (Jan. 30, 2009): Our client has cleared us to spill our guts on the details of the project discussed here now that it’s complete… Ruby for Desktop Applications? Yes we can.

I’ve been tracking the Rich Internet Application (RIA) framework technology scene lately.

That’s a broad category. As the technology is put to use, its applicability grows into other domains. Mobile or otherwise-embedded devices, set-top boxes or game consoles, tables, and stand-alone or kiosk applications are all targets now. Web applications are still the largest niche for RIA platforms, so I’ve compiled a list of the web-oriented technologies for comparison. Since I most enjoy writing web applications in Ruby, I’m tracking the way each platform supports Ruby integration—specifically Ruby on Rails.

Here are the contenders, in order of fitness for web application development, according to my own opinion: