Atomic Spin - Home

A New AO Library

2010-07-29T18:11:00Z

Atomic Object has always embraced the scholarly side of Computer Science. We encourage conference attendance and participation, writing for trade journals, and sharing technical expertise through our company blog. During the lunch hour, employees frequently give “brown bag” talks—presentations on a particular technology, problem, or methodology. When they’re not developing software at work, employees are expected to develop professionally, that is, to investigate new technologies and hone their skills. And before founding Atomic, our president, Carl Erickson, was a professor of Computer Science at GVSU, making it safe to say that AO’s had these scholastic sympathies from the very beginning.

Another symbol of our academic bent is our rather large library – yes, a physical library – of books, made available for use by Atomic employees. We have books on, to name a few, operating systems, system administration, visual design principles, agile methodologies, project management, and oh so many programming languages. In fact, our burgeoning library was outgrowing its space on our IKEA shelving, not designed to withstand the weight of such CS tomes as Knuth’s 3 volume set, The Art of Computer Programming. Also, the classification system was getting muddled, with newer books horizontally stacked atop older books being the only recognizable taxonomy.

And so we needed a new solution. Luckily for us, our Business Manager, Mary, has a background in commercial interior design and was able to use her skills in drafting to design an entire wall of built-in bookcases. With all the information radiators around the office, wall space has become an increasingly scarce commodity, so the final design left an opening for the whiteboard currently occupying the wall in addition to ample shelving. [Nerdy art history sidebar: The design references the facade of our building, symmetrical, with a large entablature supported by two engaged pilasters.] Our friend Ken Idema (of Ken Idema Builders) created the library shelves, continuing his habit of beautifying our space.

The lot of re-”cataloging” our books – unfortunately – fell on me. Lacking a technical background, you can imagine how mind-boggling it must have been to rely on reason alone to organize books on C, C++, C# and Objective-C. (Let alone Cocoon?)

With the help of a friend, the oversight of an intern, and a little sweat equity, we have made the library easier to navigate (usable) and gave it ample room for growth (scalable).

Through the process of moving and organizing the books, I became rather fond of these books so foreign to my own education – or were they? I couldn’t help but notice the prejudice for modern art cover designs among the books. They featured works by Pete Mondrain, Wassily Kandinsky, M.C. Escher, Georges Seurat (the connection of pointillism to pixels is a given), to name a few.

So please – admire with me the final product – an homage to order, learning, and to craftsmanship (of all kinds).

Simplicity is Not the Answer

2010-07-28T19:52:00Z

Don Norman writes about why Simplicity Is Not the Answer

If my cellphone only had one button it certainly would be simple, but, umm, all I could do would be to turn it on or off: I wouldn’t be able to make a phone call. Is the piano too complex because it has 88 keys and three pedals? Should we simplify it? Surely no piece of music uses all of those keys. The cry for simplicity misses the point.

Converting to UTF-16 and UCS-2 with Iconv

2010-07-28T13:29:00Z

Recently the SME Toolkit, a project sponsored by the International Finance Corporation (a member of the World Bank Group), was attempting to send international SMS messages. This gave everyone on the team a good lesson in character encodings. We had previously utilized UTF-16 to send our SMS messages to the telephone company which we were partnering with for international messages. However, when we tried to send our SMS messages to a telco in Sri Lanka, they requested that we use a predecessor to UTF-16 known as UCS-2.

Since we knew UTF-16 and UCS-2 were very similar, we didn't anticipate any problems. (The major differences between UTF-16 and UCS-2 occur for characters which we were not concerned about). We dutifully converted our messages to UCS-2, and sent them off -- only to find that no one in Sri Lanka could read them. They showed up as gibberish on our testers phones, or were not even accepted by the telco's SMS gateway -- being rejected as malformed. What had happened? UTF-16 and UCS-2 are supposed to be similar, right? Well, they are similar. Unfortunately, character encodings are widely misunderstood, and implementations differ widely. A particular program may handle even similar encodings in very different fashions.

After discovering we were sending nonsense messages, we decided to examine the logs. To our surprise, we discovered that not only was the telco receiving messages from us without a byte order mark (BOM), they were receiving our messages as if they were little endian -- with the least significant byte first! This was a major surprise to us as we had anticipated that our messages would be sent just like UTF-16: with a BOM so that the actual byte order was not an issue.

It turns out that there is a snag with the Unix Iconv library (libiconv) on certain systems depending on the system's endianness. We converted our messages in Ruby using the Iconv library which utilizes the local system's library. It seems that Iconv silently omits the BOM when converting messages to UCS-2, but does include the BOM when converting messages to UTF-16. This is surprising (and somewhat concerning), as the UCS-2 encoding is byte order sensitive, just like UTF-16. In addition, the default byte order is supposed to be big endian. Unfortunately, we couldn't find a good explanation for this behavior, so we simply adapted.

We recognized the problem when doing a trial a conversion with the Iconv library in IRB from UTF-8 to UCS-2:

On a local system:
irb(main):001:0> Iconv.conv("UCS-2","UTF-8","a") => "\000a"
On our production server:
irb(main):001:0> Iconv.conv("UCS-2","UTF-8","a") => "a\000"

For comparison, the Iconv library in IRB does include the BOM when converting from UTF-8 to UTF-16:

On a local system:
irb(main):002:0> Iconv.conv("UTF-16","UTF-8","a") => "\376\377\000a"
On our production server:
irb(main):002:0> Iconv.conv("UTF-16","UTF-8","a") => "\377\376a\000"

While this type of behavior in Iconv may be intended, it certainly is confusing and unhelpful since it isn't documented. I could find no information regarding intended behavior of Iconv other than the odd forum post which referred to UCS-2 conversion in Iconv being "broken." The UCS-2 standard allows a BOM, but it can be omitted. This wouldn't be such a problem if Iconv always converted into the same variant of UCS-2 rather than switching between big endian and little endian depending on the current architecture.

Somewhat cryptically, Ruby outputs the contents of a byte as the ASCII equivalent, or the octal value if that will not be visible. So, in our case, the character "a" gets displayed as "\000a" on one machine, and "a\000" on the other machine. This is endianness in action. One machine is clearly putting the most significant byte first, the other the least significant byte first. This is a problem since the UCS-2 standard specifies that in the absence of a BOM, the bytes should be interpreted as big endian.

Instead of receiving the character "a" (Unicode: 0x00 0x61), the telco would have received the character "愀" (Unicode: 0x61 0x00) -- a Han ideograph. No wonder the Sri Lankan phones couldn't display it!

Discussion with the telco in Sri Lanka revealed what we had come to suspect: they wanted the UCS-2 messages to be big endian. I suppose it would have been helpful if they would have specified this in the first place, but they might have (rightfully) expected that we would use the default -- big endian.

In order to force our server to use big endian, we specified it explicitly when doing our conversions with Iconv:

On our production server:
irb(main):0003:0> Iconv.conv("UCS-2BE","UTF-8","a") => "\000a"

This effectively solved our problem. No longer did we have to worry about whether our machine was representing characters differently than the telco's machines -- we specified exactly which encoding and byte order to use. Sadly, documentation of character encoding issues like this is very sparse and we had to do much research and testing ourselves before coming to this conclusion.

Polyglot Persistence and Rails 3

2010-07-27T13:18:00Z

Developers at Atomic really value using the right tool for the job. That’s why we occasionally get together outside of work to learn and teach new technologies. Keeping up with the latest tools and approaches is easiest with a group of friends and a couple of beers, so last month we organized an after-work exploration of some non-relational databases. The experience got us thinking about persistence in the new world of NoSQL and Rails 3.

ORM agnosticism has recently become a core principle of Rails. An ORM is a mapping between objects and relations, but in Rails 3 this can mean more than just alternative syntax for the same relational operations. Now your models can be persisted in an entirely different data storage paradigm, or a combination of new and old. That means more flexibility to think about your application outside of tables and columns, without sacrificing the familiarity and convention of Rails.

As with any newcomer to your application stack, you’ll need time to get familiar with performance and operational characteristics of a NoSQL database, so don’t put all your persistence eggs in the same basket. Our own approach to integrating these new tools is to take baby steps: apply them where their novel features can shine instead of completely throwing out the standard approach. Use MongoDB for the part of your app that needs a more flexible schema, and keep using Postgres for payment processing, where its transactions and durability keep it in the game.

This integrated approach to using multiple data stores is often called “polyglot persistence”. It’s more than just a transitional step towards replacing your database. It means letting you always use the right tool for the job and not falling into a monocultural mindset. The salient conclusion of our recent foray was that each database makes its own tradeoffs. Web apps wear MongoDB well, but it’s not best for critical transactions involving multiple records. Neo4j doesn’t pretend to be a whole-app data store, but might be the best way to query your huge social network. Redis is extremely flexible but it may take more work to solve your common problems: it’s more of a general-purpose toolkit than an out-of-box solution. SQL databases are still useful and mature tools for many problems, especially where transactions are necessary.

The new directions in Rails 3 aren’t just about letting you replace ActiveRecord. They entirely decouple the ORM from the core framework, so you can pick the right tools and have them all coexist in harmony. But to fully realize the dream, the greater Rails’ gem ecosystem needs to shift a bit. On a recent project combining Rails 3, ActiveRecord, and Mongoid, we’ve noticed a few common problems.

The first is gems too targeted toward ActiveRecord. Mongoid is extremely similar to Rails’ default ORM, but some gems focus so much on providing magic that they lack the configurability necessary to adapt to new storage paradigms. Too much magic without configurability can lead to too strong a tie to ActiveRecord. Rails 3 offers the convenience of convention without sacrificing the flexibility of configuration, which is a good model to follow.

Another problem we’ve seen is gems that try to accommodate multiple ORMs, but assume only one will be present. This is an acknowledged limitation of Database Cleaner, which would otherwise make fixture cleanup in a multiple database scenario easy and straightforward.

Once we got through these issues, working in a our polyglot rails application has been a fantastic experience. MongoDB has already paid off by allowing us to embed one document inside another for a surprisingly elegant solution to a modeling problem. At the same time using ActiveRecord for user accounts has let us continue using Clearance for breezy authentication and reserved the option for transactional payment processing.

This is really exciting.

How to Talk About User Experience With Clients

2010-07-21T15:45:00Z

The language that we as UX practitioners use to talk to each other isn’t always useful to our customers. Author David Sherwin suggests having a cheat sheet for talking to clients about the business value of UX and shares his own cheatsheet as a guide.

Can You Say That in English? Explaining UX Research to Clients

As much as I’d like to tell my clients to go read The Elements of User Experience and call me back when they’re done, that won’t cut it in a professional services environment. The whole team needs a common language and a philosophy that’s easy to grok.

I created a cheat sheet to help you pitch UX research using plain, client-friendly language that focuses on the business value of each exercise.

Programming for Wikipedia

2010-07-19T13:31:00Z

As one of the top ten sites on the Internet, Wikipedia is well known both for being the largest encyclopedia in the world and for having a highly unconventional editorial process. What far fewer people know about is the community of editors that has built up around the project.

While occasional, often anonymous contributions comprise the majority of article content on Wikipedia, tens of thousands of regular editors — the core community — deal with such internal tasks as article cleanup, coordinating efforts, fixing bad edits, and managing the site. I have edited Wikipedia since 2006 (though with varying degrees of activity), and it is quite an interesting and useful experience. Wikipedia’s organizational structure is extremely decentralized out of necessity, but there are numerous procedures governed mostly by convention. There is no central authority; the Wikimedia Foundation, while officially controlling the project, rarely goes beyond facilitating volunteer editors’ work.

I mostly chose to involve myself with cleaning up existing articles, monitoring new edits, and writing editing tools. Wikipedia allows users to add scripts written in JavaScript to their account in a manner similar to Greasemonkey. There are a number of these scripts, ranging widely in purpose: modifying the interface, automating common tasks, and giving easy access to technical information are some of the most common uses.

When I first started editing, I had little knowledge of programming. Some of my first experience with programming came as a result of installing a Wikipedia script that gives information about an article’s quality while viewing the article. (This isn’t as fancy as it sounds; Wikipedia has a process for assessing articles, e.g. as “B-class,” “C-class,” etc., and most articles have this information readily available but not very visible.) It was quite useful, but it had bugs, and the script’s original editor had stopped working on it. Since all user contributions to Wikipedia can be freely modified, I copied the script and tried to fix the problems with it, learning JavaScript in the process.

The script was quite basic and only used by a few people when I started working on it. Over time, I ended up rewriting most of it and adding features, mostly for my own use, but every now and then at another editor’s request. It’s now a pretty useful tool, providing a summary of an article’s passage through various editorial processes, as well as the ratings given to it by groups of editors dealing with specific topics; it’s gained more users, too, though there isn’t an easy way to tell how many.

To most people, Wikipedia is simply a useful resource, but to those who spend some time contributing to it, Wikipedia is a place to both find information and improve your own knowledge and skills by working on it.

Grand Rapids Agile UX Retreat

2010-07-16T14:55:00Z

Atomic Object hosted a second Agile UX Retreat in Grand Rapids, Michigan over the weekend of July 10-11, 2010. The first retreat was hosted earlier this year by Cooper in San Francisco. The group was initially brought together by Anders Ramsay and Lane Halley to focus on creating a new blend of user experience (UX) practices and agile software development practices.

I’ll happily admit to having more than one “pinch me” moments over the weekend as I looked around the room at the thought leaders represented in the participants who’d come to Grand Rapids from all across the country. [Side note: in our experience with bringing software professionals from major metropolises to Grand Rapids, the near universal response is compliments and utter surprise on how much GR has going on and how attractive a city it is. If GR was a company, it would desperately need a marketing strategy.] I haven’t had my brain stretched this much for some time. On the other hand, I don’t know what else I should have expected considering the talent and personalities in the room, the fact that we represented distinct disciplines each with its own history, terminology, and perspective, and the incredibly ambitious nature of the work we’re doing. Potentially so ambitious, in fact, that the idea that what we were really discussing was a post-industrial approach to collaborative, interdisciplinary, creative team work was given serious debate.

The group of twenty participants included developers, designers, testers, researchers, company owners, consultants, and employees. Approximately half of us had participated in the first retreat, and half of us were new to the group. I felt we had a great balance between new and old, and a useful diversity of experience and opinion. The spirit of mutual respect and collaboration was both remarkable and productive. The group self-organized, with a few people naturally and effectively facilitating as necessary. The Factory in downtown Grand Rapids provided a great physical space for our work.

The majority of our time (at least if you don’t count dining and drinking at San Chez Bistro on Saturday night) was spent on two initiatives. The first was to craft a statement of values. The second was to organize and summarize a list of brainstormed problems we’ve all experienced. We concluded the retreat with a plan for continuing the work we started, and a strong desire to meet again soon and push this important effort forward.

Presenter First in GTK and C

2010-07-13T14:12:00Z

Recently Mike Karlesky and I spent a week in the Baltimore area leading up a workshop-style training course. The intent of the workshop was to demonstrate Agile techniques applied in the embedded domain.

As part of the workshop, I created a small GTK application to demonstrate Presenter First and Model-View-Presenter. (Although a GUI application may not seem particularly embedded, the principle is the same: the view walls off some untestable library; the presenter and model allow us to test around it.) GTK turned out to be a good choice, since the events flying out of its widgets were much like the asynchronous events that come out of other windowing toolkits or hardware devices.

And here it is: the aptly named PF Calculator. Guess what? It’s a calculator. The calculator’s functionality is quite limited, in that it can only divide integers, but it still demonstrates Presenter First concepts quite well:

The ApplicationPresenter responds to events from the ApplicationModel and ApplicationView.
The ApplicationView fires events roughly corresponding to events coming from GTK widgets. Along the way, it does some translation to only relay the relevant information and remove traces of GTK in the event.
The ApplicationModel is used to compute the “business logic” (haha, I love that term, especially when applied in such a silly context). The Model delegates to the NumberValidator to get some help when needed.
And last (but not least), all of the above code was written Presenter First.

Everything is implemented in C. Here are a few notes about the implementation:

In a language with automatic object construction, I’d have the Presenters wire up their events in their constructor methods. Since that strategy isn’t available here, I’ve instead implemented a Presenters_RegisterForEvents function. The purpose of the function is to rip through all of the Presenters and tell them to RegisterEvents. It would be trivial to have the build system automatically generate this file in a project with many Presenters.
I only support one subscriptor to any single event. This is because I didn’t feel like implementing a bounded array or linked list to hold the function pointers. I did see something about a GSList data structure available in the GLib documentation, but I never got around to trying it out.
I call the gtk_init function in main before firing up the application. I’m not wild about this GTK-specific knowledge leaking outside of the view, but for this very simple example, it was the cleanest way to handle this detail. In a real project I’d strive to keep GTK specifics confined to views.

I depend on a number of libraries and tools to get them job done. More notes:

I’m using the Ceedling build and test harness developed by Mike Karlesky, Greg Williams, and Mark VanderVoord. Ceedling gives me easy access to unit testing via Unity, C mock generation via CMock, and C exceptions via CException. Ceedling also weaves everything together to create the executables.
- Ceedling hasn’t had a 1.0 release yet, but the code available from the Sourceforge project is quite functional.
I used this project as an excuse to monkey around with the PCRE library. I didn’t use it extensively, but it was enough to get a taste. It turns out PCRE is tasty.
I also recently heard about bstring and tried it out. Again, I didn’t use it for much, but enough such that I’m sold on it.

Warning: I haven’t tried to build this code on anything other than my personal Linux system, so I can’t say how portable it is. Here are some details about my system:

The Linux distribution is Ubuntu 10.04.
The GTK development files have been installed via the libgtk2.0-dev package.
The PCRE development files have been installed via the libpcre3-dev package.
bstring is bundled with the project.
The build system relies on Ruby and Rake. The build system uses pkg-config commands to gather the build flags for PCRE and GTK. Hopefully this means it will be easier to build the project on an arbitrary system.

To build and run the application, type rake. To run all the tests, type rake test:all. To test an individual module, like ApplicationModel, type rake test:ApplicationModel.c.

Big thanks to Mike Karlesky for assisting with Ceedling, CMock, and Unity. Also thanks to Greg Williams and Mark VanderVoord for helping develop this great software.

Resources:

The pf_gtk repository hosted on GitHub.
pf_gtk tarball
Presenter First information at Atomic Object.
Ceedling build system and other useful C tools.

Edit July 13, 2010: The article was initially published without the Ubuntu package names filled in. This has been corrected.

Consolidate Multiple FileSystemWatcher Events

2010-07-08T14:13:00Z

The .NET framework provides a FileSystemWatcher class that can be used to monitor the file system for changes. My requirements were to monitor a directory for new files or changes to existing files. When a change occurs, the application needs to read the file and immediately perform some operation based on the contents of the file.

While doing some manual testing of my initial implementation it was very obvious that the FileSystemWatcher was firing multiple events whenever I made a change to a file or copied a file into the directory being monitored. I came across the following in the MSDN documentation’s Troubleshooting FileSystemWatcher Components

Multiple Created Events Generated for a Single Action

You may notice in certain situations that a single creation event generates multiple Created events that are handled by your component. For example, if you use a FileSystemWatcher component to monitor the creation of new files in a directory, and then test it by using Notepad to create a file, you may see two Created events generated even though only a single file was created. This is because Notepad performs multiple file system actions during the writing process. Notepad writes to the disk in batches that create the content of the file and then the file attributes. Other applications may perform in the same manner. Because FileSystemWatcher monitors the operating system activities, all events that these applications fire will be picked up.

Note: Notepad may also cause other interesting event generations. For example, if you use the ChangeEventFilter to specify that you want to watch only for attribute changes, and then you write to a file in the directory you are watching using Notepad, you will raise an event. This is because Notepad updates the Archived attribute for the file during this operation.

I did some searching and was surprised that .NET did not provide any kind of wrapper around the FileSystemWatcher to make it a bit more user friendly. I ended up writing my own wrapper that would monitor a directory and only throw one event when a new file was created, or an existing file was changed.

In order to consolidate the multiple FileSystemWatcher events down to a single event, I save the timestamp when each event is received, and I check back every so often (using a Timer) to find paths that have not caused additional events in a while. When one of these paths is ready, a single Changed event is fired. An additional benefit of this technique is that the event from the FileSystemWatcher is handled very quickly, which could help prevent its internal buffer from filling up.

Here is the code for a DirectoryMonitor class that consolidates multiple Win32 events into a single Change event for each change:

using System;
using System.Collections.Generic;
using System.IO;
using System.Threading;

namespace FileSystem
{
  public delegate void FileSystemEvent(String path);

  public interface IDirectoryMonitor
  {
    event FileSystemEvent Change;
    void Start();
  }

  public class DirectoryMonitor : IDirectoryMonitor
  {
    private readonly FileSystemWatcher m_fileSystemWatcher = 
      new FileSystemWatcher();
    private readonly Dictionary<string, DateTime> m_pendingEvents = 
      new Dictionary<string, DateTime>();
    private readonly Timer m_timer;
    private bool m_timerStarted = false;

    public DirectoryMonitor(string dirPath)
    {
      m_fileSystemWatcher.Path = dirPath;
      m_fileSystemWatcher.IncludeSubdirectories = false;
      m_fileSystemWatcher.Created += new FileSystemEventHandler(OnChange);
      m_fileSystemWatcher.Changed += new FileSystemEventHandler(OnChange);

      m_timer = new Timer(OnTimeout, null, Timeout.Infinite, Timeout.Infinite);
    }

    public event FileSystemEvent Change;

    public void Start()
    {
      m_fileSystemWatcher.EnableRaisingEvents = true;
    }

    private void OnChange(object sender, FileSystemEventArgs e)
    {
      // Don't want other threads messing with the pending events right now
      lock (m_pendingEvents)
      {
        // Save a timestamp for the most recent event for this path
        m_pendingEvents[e.FullPath] = DateTime.Now;

        // Start a timer if not already started
        if (!m_timerStarted)
        {
          m_timer.Change(100, 100);
          m_timerStarted = true;
        }   
      }
    }

    private void OnTimeout(object state)
    {
      List<string> paths;

      // Don't want other threads messing with the pending events right now
      lock (m_pendingEvents)
      {
        // Get a list of all paths that should have events thrown
        paths = FindReadyPaths(m_pendingEvents);

        // Remove paths that are going to be used now
        paths.ForEach(delegate(string path)
          {
            m_pendingEvents.Remove(path);
          });

        // Stop the timer if there are no more events pending
        if (m_pendingEvents.Count == 0)
        {
          m_timer.Change(Timeout.Infinite, Timeout.Infinite);
          m_timerStarted = false;
        }
      }

      // Fire an event for each path that has changed
      paths.ForEach(delegate(string path)
        {
          FireEvent(path);
        });
    }

    private List<string> FindReadyPaths(Dictionary<string, DateTime> events)
    {
      List<string> results = new List<string>();
      DateTime now = DateTime.Now;

      foreach (KeyValuePair<string, DateTime> entry in events)
      {
        // If the path has not received a new event in the last 75ms
        // an event for the path should be fired
        double diff = now.Subtract(entry.Value).TotalMilliseconds;
        if (diff >= 75)
        {
          results.Add(entry.Key);
        }
      }

      return results;
    }

    private void FireEvent(string path)
    {
      FileSystemEvent evt = Change;
      if (evt != null)
      {
        evt(path);
      }
    }
  }
}

Catching exceptions via NSInvocation and NSProxy is no longer possible in Objective C

2010-07-06T14:39:00Z

This issue has already been raised in several places, but in the hopes of adding some more visibility to the issue I figured it would not hurt to post it here. Under the iOS 3.2 and iOS 4 simulator platforms it is no longer possible to catch exceptions via NSInvocation and Apple’s object proxy mechanism (NSProxy). Specifically, it makes it almost impossible to use OCHamcrest and OCMock as they both rely heavily on dynamic invocation and proxy objects.

The issue has already been raised here:

I created a sandbox project in an attempt to diagnose the various scenarios in which exception handling did not work. Until Apple releases a fix for the bug it is going to take some creative work-arounds in order to “move on” from the issue.

It is still possible to catch exceptions via an NSInvocation if you fallback to using the objc_msgSend function in lieu of [invocation invoke]. OCHamcrest and OCMock could be patched to temporarily use that workaround until Apple releases a fix. The Google Toolbox guys have already rolled this workaround into their test runner.

For example,

Uncatchable Implementation

Workaround

This will get around the NSInvocation issue (for the most part), but throwing exceptions within an NSProxy object is still broken. The only workaround I can envision would be to use objc_exception_throw; which appears to be undocumented. It is anyone’s guess if that will work around the issue. But it might be worth a try.

D - The little language that could

2010-06-30T23:07:00Z

(So, in reality, D probably isn’t all that little, but here’s to it making it up the mountain.)

A good while ago I wrote a post about my hope for the D programming language as an up-and-comer in systems and embedded programming. D promises to bring a number of modern language concepts and constructs to low-level systems while yet producing a fairly efficient runtime. It’s 3 years on since my original post, but I’m still hopeful.

Just a few days ago a comment came in on my original post. My friend Mark VanderVoord responded in that comment thread. I thought I’d make the content of the thread a bit more visible (below) as it’s concerned with using D in the real world.

There’s been respectable progress toward D becoming viable in the mainstream. I’ll venture a guess that it’s going to be several more years until it truly is.

Update (7/1/2010): We don’t often attract a great many comments on our posts. But we have here. I point it out because there’s good resources, background, and perspective on D in the comments. Take a read. The original comment thread that sparked this post can still be found beneath this update.

Since our comments can’t contain links, I’m listing & linkifying here what our commenters have referenced:

Steve Klabnik pointed out a new kernel project written in D (Steve is one of the authors)
Kevin Bowling recommends the book The D Programming Language written by another of our commenters Andrei Alexandrescu
Descent is an Eclipse plugin for D
Several have compared/contrasted D to the new Go programming language by Google

Update (7/6/2010): Commenter devdanke suggested Apple as a D corporate backer. Google seems to be pursuing Go; why not Apple getting behind D? Apple certainly has a lot invested in LLVM of late. Apple may just be up to something—though I’m doubtful it’s D. Time will tell…

slide Says:
June 25th, 2010 at 07:35 PM

Is there any active development that you know of to get D running on embedded, bare-metal type platforms?

Mark Says:
June 25th, 2010 at 11:01 PM
slide:

This is the current state of things as far as I know:

The official D versions (D1 and D2) by Digital Mars (DMD) are only x86 so far

GDC – this is a D front-end with a gcc backend. Theoretically this means you can target anything gcc can (which is almost everything). The work I’ve done with it (mostly ARM) has been pretty tricky to get working, though.

LDC – this is a D front-end to LLVM. Again, this means you should be able to target anything LLVM can. LLVM has a lot of momentum lately… and this port seems to be pretty active too. I have done some small experiments with getting it to target an ARM9. It seemed to work well. I hope to have more time to work on that in the future.

For either LDC or GDC, you’re getting D version 1, which is missing some of the new (in-progress) features. But, they’re more stable, so that’s nice.

D links easily to C, so bringing in libraries, RTOS’s etc is pretty easy.

I hope this helps.
Mark

Soccer-playing robot wins World Cup

2010-06-18T14:24:00Z

When asked what sports they play, most high school students typically respond “football,” “baseball,” “basketball,” or “soccer.” I, however, get to respond with something much more interesting: “robotics.”

The sport I am referring to is the FIRST Robotics Competition, a high school level competitive robot building competition. Teams from around the world, 1,808 to be exact, compete against each other every year in a world wide challenge that culminates at the Championship held in Atlanta, Georgia.

I first started competing with the only FRC team in Grand Rapids, Creston High School’s robotics team, but eventually several members and I began looking into forming our own team closer to where we lived. In late October of 2009, those of us who lived in the Forest Hills, Ada, and Cascade areas of Grand Rapids decided to form the COMETS (Creating Outstanding Minds Embracing Technology and Science) only a couple months before the 2010 season began.

This year our challenge was to build a robot that could play a game called Breakaway basically a mixture of soccer and steeplechase, where robots competed against other robots in games of three vs. three. With the help of many local area sponsors, and great mentors (local engineers, programmers, and businessmen who guide team members in their efforts), we were able to build a highly competitive robot in the six weeks we were given. In fact, we won the West Michigan District event, placed 20th in the state, and won our division in the Championship. Not too bad for a rookie team.

But the most important part of the season was definitely not our win/loss record. It was the fact that students learned new skills in CAD and metal fabrication, programming, web design, 3D animation, and marketing. Just as important is the fact that students experienced how much fun science and technology can be, and built partnerships throughout our community (in fact, it was through Atomic’s sponsorship of local area teams that I first became aware of their internship program).

However, it’s easy to say that in retrospect.

In the three years that I have been involved with robotics, I’ve had seasons where the team has lost almost every single match, as well as seasons (recently) where we did incredibly well. But in all honesty, I only remember a handful of matches we played. What I do remember is the important stuff.

For example, I remember how in 2008 I scoured the Internet and Home Depot to find a material that would trigger the robot’s photoeyes when our ‘bot’s elevator passed them. I remember in 2009 when the FRC switched from a PIC based microprocessor to the powerPC based cRIO from National Instruments, and how I had to learn a new, object oriented language that came with it. I also remember how this year the other programmers and I wrote multi-threaded Java software so our robot could efficiently manage user input and a live camera feed.

The FRC creates an environment where being interested in science and technology is alright. That environment then goes on to encourage problem solving, creativity, and a strong team spirit. For me, this environment gives me an outlet where I can learn and create with people who have the same interests as I do. I could go on, but I think that you get the idea: this robotics competition is actually much more than just a sport.

Working Faster with Working Directory

2010-06-11T00:05:00Z

I always have a shell open. Most of my daily project navigation and file-system work is done in Bash. If I can do something with a GUI or a terminal, I’ll prefer the terminal. I’m a polyglot programmer who often uses Windows, Linux, and Mac OS X all in the same day. There’s a tool I need whenever I work on the command-line: Working Directory.

Here’s a scenario:

Your project uses Java and Maven. That means the first useful bits of your code are buried somewhere like this:

/Users/capt.picard/work/FooFoo/src/main/java/org/foo

So you start out a new shell in your home directory and navigate all the way down there:

1234	/Users/capt.picard$ cd work/Users/capt.picard/work$ cd FooFoo/Users/capt.picard/work/FooFoo$ cd src/main/java/org/foo/Users/capt.picard/work/FooFoo/src/main/java/org/foo$

Whew! Maybe not a big deal once, but I hope you don’t have to do this every day! Fortunately you have command-line completion, cutting down on all that typing:

12	/Users/capt.picard$ cd wo[TAB]/Foo[TAB]/s[TAB]/m[TAB]/j[TAB][TAB][TAB]/Users/capt.picard/work/FooFoo/src/main/java/org/foo$

Wait, what? That’s still a lot of typing! This is much quicker for users of Working Directory:

12	/Users/capt.picard$ wd/Users/capt.picard/work/FooFoo/src/main/java/org/foo$

That’s it! Let’s see how that magic works.

Whenever you start a new project or workspace, just tell Working Directory (or just “wd”) that you want to make a new scheme:

/Users/capt.picard$ wdscheme foofoo

This creates a set of 10 slots associated with that scheme and copies in the contents of your previous scheme. (If you don’t need a clone of the previous scheme, you can clear those out with wdc.) Now you simply navigate to your project root, or wherever you most commonly need to start when you work on that project, using regular cd and all the tab-completions you can tolerate. Once there, you can store that directory in the default slot like this:

/Users/capt.picard/work/FooFoo/src/main/java/org/foo$ wds

If you then look at the list of slot assignments with wdl, you’ll see that you’ve stored the current directory in the 0th slot:

/Users/capt.picard$ wdl
0 /Users/capt.picard/work/FooFoo/src/main/java/org/foo
1
2
3
4
5
6
7
8
9

The first slot is special—you can access it without specifying a number at all. Just type wd to navigate to that slot and wds to set it to the current directory. The remaining slots require their number to retrieve or store. If you want to store the directory that holds your project tests in slot 3:

/Users/capt.picard$ cd work/FooFoo/src/test/java
/Users/capt.picard/work/FooFoo/src/test/java$ wds3
/Users/capt.picard/work/FooFoo/src/test/java$ wdl
0 /Users/capt.picard/work/FooFoo/src/main/java/org/foo
1
2
3 /Users/capt.picard/work/FooFoo/src/test/java
4
5
6
7
8
9

Now you can quickly navigate between source and test on the command-line:

1234	/Users/capt.picard$ wd/Users/capt.picard/work/FooFoo/src/main/java/org/foo$ wd3/Users/capt.picard/work/FooFoo/src/test/java$ wd/Users/capt.picard/work/FooFoo/src/main/java/org/foo$

You can have as many schemes as you want, but each scheme only stores 10 directories. This allows for maximum accessibility on the command-line with single-word aliases for going to or storing into each slot.

Working Directory has many other features that you may start to use over time:

wdenv stores the current scheme into similarily-named environment variables for easy use on the command-line for any purpose, like cp.
Storing directories in slots doesn’t require that you be in the directory. Just give a directory as a parameter to wds[0-9] and it will store it instead of the current directory.
wd is cross-platform, written in Bash and Perl. I’ve used it heavily over the years on Windows+cygwin, Linux, OS X, and Solaris.
wd provides a bash-completion function for its schemes. wdscheme [TAB][TAB] will list of all of your existing schemes.
Since wd stores schemes and slots on disk, all of your terminals will share the same scheme, so there’s no need to set the scheme every session. Storing a directory from one terminal makes it available in any other terminal.
You can also temporarily override the working scheme in a particular shell by just setting the value of the environment variable WDSCHEME. If this variable is set, it’s used instead of the current scheme on disk.

Working Directory has been available for some years and gets constant daily use by its small community. Most people who’ve started using it never stop! Lately you can fetch the source from github or download the latest stable release directly from the project’s Downloads area.

An intern's first impressions of agile at AO

2010-06-09T13:11:00Z

I am a student at Grand Valley State University, and I have the privilege of interning at Atomic Object this summer. AO has a good relationship with the school, and I had heard quite a bit about the company. When I was looking for an internship in the summer, I placed AO at the top of my list for local companies, but I secretly hoped that I could get accepted to a bigger corporation. Motorola labs scaled back their internship program and my interview with Apple never materialized into a job. Fortunately, Atomic was willing to invest in me this summer. After 4 weeks, I am glad that the other companies turned me down.

Agile is people-centric. On my first day, when the employees welcomed me at the standup meeting, the focus on relationships was evident. The office is free of cubicles and open to everyone. This creates an atmosphere where ideas are easily transferable and people are free to communicate. I was pleased to attend an Atomic Spin Down, where the employees and their families enjoyed a Friday night at the office socializing and playing Rock Band. The employees clearly love their job and working with each other.

The care for the individual continues with Atomic’s clients. It is evident that AO works hard to make sure the clients’ projects succeed. On my second day at work, I was able to participate in a Research, Design, and Planning session where we analyzed the potential users of an application. The client arrived to the meeting with their ideas already formulated for the application. After a little bit of prodding, they were excitedly creating personas of the users. When they left, all parties involved had a deeper understanding of the application. Instead of working with stacks of requirements, AO seeks to understand people.

Agile is test-driven. I have to admit that when I first saw test-driven development, I was a little skeptical. The tests seemed really narrow in scope and I thought you had to write twice as much code. I am still learning a lot about testing, but I definitely appreciate a full suite of tests double-checking our code. Programmers like to trick themselves into believing that they never make mistakes and can always remember what every method does. In reality, we are not perfect. Writing test may take a little more initial investment, but it reduces time tracking down bugs. My current project has made major changes mid-stride. Refactoring code is usually an arduous task, but the tests ease the process.

I have soaked up a ton of information in 4 weeks, and I hope to continue learning across the remainder of the summer. If you are looking to learn more about agile practices, I recommend reading some of the books I have read this past month.

A Good Year for the AO Roses

2010-06-07T17:14:00Z

Elvis Costello sings the melancholy tune, “A Good Year for the Roses.” The song has stuck with me, but the sad sentiment doesn’t match the colorful riot of rose blooms showing in Atomic Object’s parking lot this summer.

About five years ago, in the midst of the monster renovation of our building, it was obvious we needed to clean up and green up the parking lot area near the entrance to AOHQ.

Having lived in homes surrounded by shade trees, I was excited about the opportunity to plant this narrow strip so graced with sun most of the day.

Roses love sun. I have always loved roses, especially old-fashioned climbing roses. My mom was an accomplished rose gardener in her time and I was inspired to honor her in a way that all our parking lot visitors could also enjoy.

So, with the help of my friend Mary Bereza, I planted a long row of deep red (Don Juan), soft white (White Eden) and petal pink (Zephurin Drouhin) climbing roses along our sun-drenched fence.

Our neighbors, Bazzani Associates added more roses to their section of the long fence garden. The name of this lovely pink and white stripe rose escapes me at the moment.

It has taken awhile for the roses to really come into their own. Each year the cains strengthen, send out new branches and produce a few more blooms than last year. This year has truly been a good year for our roses.

Thanks to my mom, JoAnn O’Neill, for showing me what’s to love about roses and thanks to Rose Van Reken, Marissa Christy’s mom, for taking these pictures and capturing the beauty of AO’s roses this year.