Anyone who has obtained a software product knows that there will be a learning curve that needs to be traversed before they can become proficient at using that software. This is also sometimes called the “Out of box experience”. And different software products have very different “Getting Started” practices for their software.
For infrastructure software, this “Out of box experience” can be a challenging task because a developer has to learn how to take this generic software that can do many things and apply it to solving his/her problems. For software products that provide access through an Application Programming Interface (API), this usually occurs with a general program called “HelloWorld”.
In the realm of a distributed infrastructure this “HelloWorld” basically shows how to publish and receive a simple text message that contains “Hello World!”. Using an application like this is very useful because it shows a developer what the basic minimum steps are to getting an application that can communicate. And this does provide a little context on how to use their new API. What this doesn’t do, however, is that it doesn’t show them how to get their application specific messages
Here at RTI, we take the concept of “Getting Started” to a new level with our Data Distribution Service (DDS) product. With the use of a code generation tool called “rtiddsgen”, new developers can actually create applications that will publish and subscribe their own data types. This utility, rtiddsgen, provides an option called: “-example <platform_architecture>”, and it enables the developer to specify a target architecture. The target architecture can be Windows, Linux, Solaris, Java or a whole set of other Real Time Operating Systems.
Once the correct platform is selected the output from the utility is two applications with all the supporting code files needed to compile and run those applications. The two applications are a Publication application and a Subscription application that are created specifically to the message type that is fed into the rtiddsgen utility. Therefore instead of having just a simple “HelloWorld” application to start with, they now have an application that is created for any message type they can think of. The resulting code is generated with lots of inline comments detailing the individual procedure steps, and also showing where in the code the developer can make changes to affect behavior. If they want to increase the publication rate, it shows where to do that. If they want to change or modify the data being published, it shows where to add that code. If they want to act on the data instead of just printing it to the screen, it shows them where to add code. Basically, it provides all the basic building blocks they will need to really make the applications part of their custom distributed framework.
With this “Easier” getting started capability, application developers can literally reduce hours and days off of their projected development time. Therefore, the net result is that more time is spent on developing application specific “Business Logic” as opposed to infrastructure building blocks.