Tamale uses NIST Net, a network emulation package that runs on Linux, during research and development and testing of our products. NIST Net, which was developed and released to the public by the U.S. National Institute of Standards and Technology, allows a Linux PC set up as a router to emulate a wide variety of network conditions, e.g., packet loss, bandwidth throttling, etc. It's a very useful tool for examining how an application will work in the Real World, as opposed to on our cozy little gigabit LAN.

Although the NIST Net home page and mailing list are still up and running, neither is actively maintained by the original authors, and the NIST Net source code available for download is not compatible with recent Linux kernels, e.g., Fedora 8, Red Hat Enterprise Linux 5, or CentOS 5. Some folks on the mailing list have posted patches for getting NIST Net to compile on recent kernels. We independently developed our own local patches for making NIST Net compile on newer kernels, and we've taken things one step farther by packaging our changes in an RPM for easy building and deployment on RPM-based systems.

We hope that others will be able to benefit from our work in this area. Feel free to email comments, questions, suggestions or patches that are specific to our RPM (general questions about NIST Net should be directed to the mailing list) to nistnet@tamalesoftware.com, and we will respond as soon as we can.

We are distributing a source RPM, rather than a binary RPM, because NIST Net is compiled to work with a specific kernel version, and the odds are that you aren't using the same kernels we are. To use this RPM, download it onto the machine on which you want to run NIST Net, or on a different machine with the same kernel version, make sure you have the kernel-devel (with the same version as your kernel), libXext-devel and libXaw-devel packages installed, and run "rpmbuild --rebuild nistnet-2.0.12c-3tm.src.rpm" as root. This will produce a binary NIST Net RPM in /usr/src/redhat/RPMS/i386, or wherever binary RPMs are configured to end up on your system, and you can then install that RPM and run NIST Net as described in the documentation on the home page.

Jonathan Kamens, Manager of Operations

Tamale spent two days in September at Google London's Test Automation Conference. Google invited a small group of presenters and attendees from all over the world, whom were focused on cutting-edge research in test automation. It was inspiring to be in a room full of people willing to treat the problem of testing large and complex software projects as an engineering problem. The 15 minute breaks between presentations were as enlightening as the presentations themselves.

Most of the attendees were of the Agile school of thought; thus much of the discussion revolved around tools to automate a test-driven approach as well as unifying and simplifying the communication between developers, qa, and business analysts with regards to bugs, test cases and business requirements.

The highlight of the conference for me was the screen capture technology the team at Thoughtworks is integrating into Selenium. Imagine the ability to check in code and have it automatically trigger a build that gets deployed to various platforms. All the visual unit tests are run and recorded on each platform. When you come back to the office in the morning, you have the videos of the failed tests. If you plan your tests well, you can actually get good and always up-to-date documentation out of the successful tests.

All of the lectures can be viewed on Google Video.

All in all an exciting couple days. Thanks to Google for hosting the free conference.

Nader Akhnoukh, Director of Knowledge Acquisition

Tamale R&D sent representatives to the EclipseWorld Conference held in Cambridge, MA this week. The conference used a semi-academic format, with hour and a half classes on various topics.

Our favorites were: the Test Driven Development, Aspect Oriented Programming with AspectJ, and BIRT presentations. Besides the core materials, it was also informative to find out what companies were directly responsible for the various projects. We also found the classes that mixed methodology with straight technology introduction were the most compelling. Overall, the format made for a collegial environment.

The keynote speech was excellent. Both the speech and Tamale's reaction made for interesting reading in InfoWeek's online coverage of EclipseWorld.

See you next year EclipseWorld.

At Tamale, we have a variety of complex testing needs -- our system is distributed, multi-platform, and multi-tiered. The impact is every system action requires result verification in many locations -- a rich client on more than one desktop, several levels of caching, and various persistence levels. We make a continuous investment in our test automation, because automating our testing is a business necessity.

Nader Akhnoukh, our intrepid Director of Research, ran across Google's announcement for a conference on automated testing in early September. The content of the conference is compelling, and highly relevant to our work here at Tamale. Even better, Google is limiting the attendance to maintain a "collegial" atmosphere. To construct a small, well-qualified audience, prospective attendees were required to write an essay, and argue their case for attending the Google test conference. The challenge was almost as appealing as the conference itself, so Nader whipped up a short essay explaining our focus, challenges, and interests.

Earlier this week, Nader received confirmation that he had been invited to the Google conference.

We're excited for Nader to represent Tamale in London, and rub elbows with the the other big brains at the conference. If you're curious, here is Nader's invitation-winning essay:

Hi,

I run the Research side of R&D for a small software company called Tamale Software. Our product has created a new industry around managing the research process for companies in the financial services industry. (RMS - Research Management Solutions)

Our product uses all sorts of technologies, from a C# .NET desktop client to an AJAX/JSP/Struts web client to a J2EE/JBoss distributed real-time app server. We've gotten a lot out of the open-source community and have contributed pieces of our product, like the JMS-C# messaging bridge for instance. We have been able to employ unit test coverage at almost every level of the product except the frontend pieces.

The main problem we've encountered is that we develop a lot of our own 'widgets' or UI objects. So it's hard to use the mainstream tools that are out there, Mercury, Infragistics, etc. out of the box.

Also, while we are a small company, we have an incredibly talented dev team, and we work hard at keeping tests up-to-date, but the overhead of keeping UI automated tests up-to-date, especially as our product changes so regularly, does not seem worth the effort.

I would love to hear about both products/services out there as well as about best practices. Anything focused on the rapid product lifecycle of an agile-focused small team would be especially useful.

I'm sure you will get a lot of requests from larger companies to attend this conference, but keep an eye toward the little guys. It would be a great asset to our development effort to get more information on this front and I'd be honored to attend.

Thanks,
Nader Akhnoukh

We deliver Tamale RMS as an appliance, which is deployed on the customer premises. The Tamale appliance provides very high performance by avoiding internet related latency and bandwidth constraints.

Tamale RMS is a mission-critical application. Our clients in the financial industry depend on Tamale to keep their most proprietary research available at all times. To achieve the level of uptime and performance our customers require, we need to deploy equipment at the client location while also monitoring the system in real-time.

The Tamale Appliance is the first ever remotely managed software appliance. Tamale provides both the security and performance of a customer-site appliance, and the polished service of an application service provider. We do this by combining on-site hardware with a suite of automated monitoring, managing, and updating services.

To create a completely self-sufficient and highly reliable appliance, Tamale consulted with Boston Engineering Corporation (BEC). BEC provides engineering and design services for a whole host of industries, and specializes in the development of hardware/software systems that run for thousands of hours unattended, often in harsh conditions. Tamale leveraged their expertise to create the Tamale Appliance. BEC recently featured the Tamale Appliance in a case study.

Tamale continues to innovate the appliance. We are extending the monitoring to include more information about the health of the application (size of message queues, method latencies), in addition to the health of the hardware. As we wrote in our last post, Monju is the framework for our growing suite of measures. We have contributed the Monju framework back to the open-source community.

Tamale's second open source project, monju, is now available in SourceForge. Monju is a Java framework for JBoss that makes JBoss application server's internal states available for Nagios remote monitoring system.

This framework was designed with flexibility and convenience in mind. It provides three different styles for implementing nagios checks. Users of the framework are free to choose the style of implementation that suits their needs. Writing a nagios check using the framework can be as easy as configuring Nagios to run the packaged nagios plug-in. Or, one can develop as complex a nagios check as the Java programming language allows.

Tamale relies on Nagios for monitoring hardware and software health of all appliance products deployed at customer sites. We will be the primary user of Monju framework. We will continue to make improvements on the framework, and make them available to the community. Our hope is that other Jboss/Nagios users will contribute bug reports, patches, and enhancements. In particular, writing new JMX-based checks is very easy within the framework, and we hope the development community for these critical technologies will add to the standard library of monju checks.

This first edition of Monju is small, simple and yet quite usable. One of the immediate task to do is to pre-package as many generally useful checks into the distribution as possible. We welcome suggestions for good pre-packaged checks.

Etymology
Monju is Japanese for Manjusri, "the bodhisattava of keen awareness" (Wikipedia: http://en.wikipedia.org/wiki/Manjusri). True, a notorious nuclear reactor in Japan is also named Monju, but no association should be made to it (besides the vivid lesson in the importance of effective and detailed monitoring). Think "keen awareness". Monju is also supposed to be an acronym for some indeterminate long name that contains highly technical jargons like "Monitoing", "Nagios", and "JBoss". We'll leave it at that. (editor's note: Monju author Michi Oshima denies reports that Monju stands for "Michi Oshima's Nagios JBoss Unifier" ).