Building a BUG App
With the BUGbase and respective BUGmodules connected and the Dragonfly perspective running, I was finally ready to see what the BUG could do. One of the panes in the Dragonfly perspective features a list of the most recent 15 applications submitted by members of the BUG developer community. Unfortunately, this pane is not integrated yet with the ability to click on a desired application and have it download and configure itself within Eclipse. Instead, I had to open a separate browser, navigate to the respective application's hosting page, download the respective jar file, switch back to Eclipse, create a new project, import the jar file contents and execute the code.
Like other Eclipse embedded device perspectives, Dragonfly prompts for program execution in a BUGbundle emulator or on the BUGbase itself. The inclusion of the emulator and the open source, freely accessible nature of these BUG development tools lets interested users test drive a virtual BUG while simultaneously developing and even uploading their own BUG programs to the BUG community website. As for the existing BUG programs available at the time of this review, most of them were small and briefly interesting, typically highlighting a BUGbase feature such as manipulating its display, reacting to button presses or interacting with the BUGmodules via simple I/O or data collection. Beyond a few novelties such as a GPS alarm clock or a motion detecting camera program, very few were actually productive programs that might excite non-technical users.
One of the most significant limiting factors to building really compelling BUG applications is its current requirement to be tethered to a USB network-enabled computer for any network communication. It's a major oversight that Bug Labs could have avoided if it had simply included a simple WiFi radio chip into the BUGbase. While existing BUGmodules can be used for data collection, display and the BUGbase microSD slot can be used for additional data storage beyond its primary function of hosting a copy of the kernel and the device's root file system, the lack of wireless communication deflated my enthusiasm and severely constrained a number of programming ideas for what I wanted this first generation model BUG to do.
Lack of an existing wireless network BUGmodule notwithstanding, there were still plenty of ideas to explore and many prototypes of the most obvious concepts have already been submitted to the BUG community website. Due to time and resource constraints, most of these concepts are very brief demos or skeletons upon which future features have yet to be fleshed out. The demos also provide ample code examples upon which to learn and start exploring the Java libraries that interface with the various modules. For example, collecting position data from the BUGlocate GPS module would have been a time consuming effort had it not been for the sample code supplied by early adventurers. As a consequence of the fast track evolution of the BUG by the small but very passionate and seemingly always working Bug Labs engineers coupled with the fact that like any start-up, objectives and resources have to be prioritized to survive, comprehensive developer documentation is a work in progress. This makes finding the right answers a time consuming search through the BUG community forums and Wikis or sometimes even an IRC conversation with one of the dedicated Bug Labs engineers. Compounding the problem of a stable SDK is the fact that the BUG kernel is also changing at a rapid pace with bug fixing efforts, surpassing limitations and generally smoothing out the product's rough edges.
It should come as no surprise that a product design as ambitious and complex as the BUG, developed under the tight constraints of a start-up budget and time to market pressures, that Bug Labs has shipped the product in a bleeding edge developmental state. For Bug Labs early adopter market, these problems are part of the compromise of having access to such innovation. As such, any developer seriously considering a BUG investment should be prepared to replace the BUG's kernel and root filesystem when applications accidentally bork the device. Unlike consumer-oriented products like the Asus eeePC, there does not yet exist an easy way to restore the BUG in the event of a system crash or corrupt file. The BUG forums are peppered with stories of flustered customers left with wonky systems after a few days of development. I encountered a serious problem after running an application that hosed the BUGview display, requiring a re-formatting of the BUG's MMC storage card and subsequent re-installation of the unit's kernel and file system. This was not a trivial task but fortunately the Bug Labs engineers were available to help me restore the device to working condition. The problem actually turned out to be a hardware related issue, but the exercise of upgrading the BUG to the latest revision was apprehensively educational.
Bugs also exist in the Dragonfly SDK, with one of the more annoying issues in the build I reviewed being the inability to delete a BUG application jar from the device even though a menu prompt offers the option to do so. Until this menu item placeholder has working code behind it, application jars must be manually deleted by telnet'ing or ssh'ing into the BUGbase as root and deleting the respective jar(s) location in the /opt/concierge/apps/ directory. Finally, there were discrepancies between the Virtual BUG emulator and the Real BUG device. What ran successfully in the emulator didn't always identically translate to the BUGbase, especially those employing the BUGview. After a while, I stopped using the Virtual BUG emulator and dumped my applications directly to the BUGbase for an accurate rendition of my programs.
Finally, the BUGbase connection had an annoying aspect of creating a new Ehternet connection with my OSX 10.4 system each time I connected the device to the computer. By the end of this review, I had over 20 Ethernet configurations, 19 of which were disabled. Again, the never-sleeping Bug Labs engineers came to the rescue with a MAC address setting shell script (emailed to me on a Sunday morning!) that eradicated the issue.
More To Come
While working with the Bug Labs engineers toward restoring my BUGbase to the latest build, they shared with me the news that they were working on a new upgrade using an entirely different Linux distribution. The R1.2 release is based on a LTIB root filesystem. The new R1.3 kernel is migrating to Poky Linux. This new Linux distro will greatly expand the system applications thanks to Poky's superior build system supporting more up-to-date application packages. This update will effectively turn the BUG into a mini-PC of sorts with the possibility of hosting scripting languages like Perl, Python, and Ruby. More importantly, the upgrade will offer better networking, support for WiFi and the new WiFi module, more robust OS and recovery modes and more.
The BUG is a work in progress, and that's one of its appealing aspects. There are no pretentious claims by the company that their product is designed for rock solid 'stake your business reputation' on this product's stability. Rather, it is for the tinker, the educator and the programmer looking for a modular playground to build, experiment and explore.
Early adopters may be agitated by the device's limitations and first generation flakiness, but the sense of close knit community coupled with the adventure of innovation balance out the frustration and anxiety associated with unknown territory. The less patient developer should wait until the re-engineered R1.3 release with its promise of wireless networking and greatly expanded programming flexibility beyond the Java language.
The other more obvious consideration toward the purchase of the BUGbundle is its price. At over $600 for this first generation model, skeptics can successfully debate that a sophisticated, programmable smartphone containing all the features of the BUGbundle could be purchased for much less and could immediately benefit from wireless networking and a robust development environment. However, this obviates the central tenant of the Bug Labs objective of interchangeable building modules based on an open design, allowing the mix and match of PC card-slot style functionality in a mobile device. Until the arrival of Android and OpenMoko phones, most smartphones like the Apple iPhone and Microsoft Windows Mobile platforms require proprietary lock-in development languages and environments that are more geared toward structured commerce than playful experimentation.
In its current state, the most satisfied customers of the BUG will be the gadget tinkering developer and the introductory computer science education markets. Bleeding edge developers who risk navigating the BUG's sharp edges may discover buried treasure within the product's modular approach.