When the CIO of Google, Dr. Douglas Merrill, speaks, you listen…

From Jay Fields…

Knowing that Erlang is a language designed to take advantage of multi-cores is enough to drive interest. Other questions that I would expect from CIOs are: Reliability? Nine nines uptime[1]. Maturity? It’s been around for 20 years. Who else is using it? Ericsson, Nortel, T-Mobile. The argument sounds compelling.

To those naysayers about using this language (you know who you are! I’ll be haunting you at night, especially today is Halloween! :),

The AXD301 has achieved a NINE nines reliability (yes, you read that right, 99.9999999%). Let’s put this in context: 5 nines is reckoned to be good (5.2 minutes of downtime/year). 7 nines almost unachievable … but we did 9. (http://www.pragmaticprogrammer.com/articles/erlang.html)

Rock on, Erlang!

and my hand slaps my face proving that the hand can still successfully slap the face. If only there were not so many commits kicking off the slap suite.

Dstamat at ELC provides a whirl wind of the many options that have come to existence in Ruby automated test land.

As I started to see my test suite slow down, Mocha to the rescue (FlexMock would have done the job too). My controller tests became focused, and my models were simply mocked and stubbed away from them completely. What if I wanted to test my views ?
Enter Selenium and Watir. Now I could even test to make sure my blind_downs were working when a user clicked on my links from browser X, Y, Z. Half way into setting up Selenium, RSpec hit the scene.

Test::Unit, Mocha, Rspec, RCov, Heckle. Throw ci_reporter in the mix for testing in continous integration (CI) setups such as pulse. Rock and roll for what rails has pulled off in the testing arena and more rock and roll considering the benefits gained by all ruby development.

There are so many amazing tools are available that incubate quality and live in complete automation. The learning curve is there, time to implement is there, but the pay off is huge and shouldn’t be ignored.

The vague and partially relevant point of this post is to illustrate the agile software development (r)evolution that passionate Rubyists have manifested in such a short amount of time. The creation, porting, adaption and adoption of these testing tools / frameworks alone should clearly exemplify this.

It’s an exciting time to be writing software

dstamat, I must agree. I’m completely enthralled.

From O’Reilly Radar,

The survival of most projects depend on working software, at least initially, and so if there is money or time many people will spend it on development. Unfortunately, people say they will “figure that ops stuff out soon”, but what they mean is “when we’re totally screwed!!!” It doesn’t have to be that way…

The blog entry mentions Puppet, a system configuration management/server automation tool written 100% in Ruby. We’re using that at work. It’s awesome. :)

Here are some links I gathered from that article on using Puppet:

Puppet, iLike and Infrastructure 2.0
Infrastructure 2.0

Spread Overview

Spread is a toolkit that provides a high performance messaging service that is resilient to faults across external or internal networks. Spread functions as a unified message bus for distributed applications, and provides highly tuned application-level multicast and group communication support. Spread services range from reliable message passing to fully ordered messages with delivery guarantees, even in case of computer failures and network partitions.

Spread is designed to encapsulate the challenging aspects of asynchronous networks and enable the construction of scalable distributed applications, allowing application builders to focus on the differentiating components of their application.

Powerful, but simple API. Only six basic calls are required to utilize Spread.

After reading the documentation this sounds really impressive. I’m going to need to play around with it to feel it out and find out if it has potential for any future projects.

Check out the platform and language support:

BSDI 4
Linux
Solaris
Irix 6.5.3 (MIPS)
AIX (powerpc)
FreeBSD (x86)
NetBSD (x86, ppc)
OpenBSD (x86)
Mac OS X (ppc)
Windows 95, 98
Windows NT, 2000, XP

C/C++ libraries with and without thread support.
Java Class to be used by applets or applications.
Perl interface.
Python interface.
Ruby interface.

I have always been interested in security. Tonight I ran across this post publicizing the white paper on cross-build injection (XBI) vulnerabilities. Some of the listed examples of XBI attacks were OpenSSH, Sendmail and Irssi. If you build software, you definitely want to read this paper and find out the recommendations to mitigate your risk from this kind of attacks.

I've been having a very strange problem on the mac the last couple of days. Subversion went from happy camper to sad clown after a MacPorts package update.

• Subversion says it needs libexpat.so.0 at run time (to commit).
• libexpat.so* exists no where on the file system
• Expat only wants to generate static libraries. The port install only generates the static libs (la) and the last release downloaded and configured with --enable-shared still refuses to generate shared libraries. The CVS release blew up so many times I quit wasting my time and moved on.
• Subversion does not have an option to make without expat
• An expat mac install package exists, but doesn't contain the desired so file

What I'm confused about is how subversion is able to build without having expat's dynamic library to link to. If it links using the static lib then there should not be the need to load the dynamic library at run time unless it is specifically made to work this way for some reason.

Of course all of this pain and confusion vanquished upon taking a closer look at the error message:

Woops, finally noticed the svnserve. ssh into Gentoo box, create a libexpat.so.0 symbolic link to the existing dynamic library. All is happy camping once again... Think about how there was some emerge -uDv world remote action at the same time as the port upgrade outdated. Slap forhead....

The three lessons learned:

1. look at error messages carefully
2. when something is server/client or distributed account for the remote side as a possible cause of the error
3. don't start writing a blog post mid way though solving a problem =]

Software security is and will become much more important in the security industry especially as security systems begin spanning public networks. Cisco seems to be taking a proactive approach to identifying and notifying customers about software security vulnerabilities. From Security Dreamer:

Cisco uses the error reporting policy to improve its products and boost its reputation. Cisco looks for problems in its products, encourages users to report new problems through a public forum, promptly notifies customers, then fixes the problem. Now that's a company with the welfare of its customers and its brand in mind

This provides insight into a different area of customer service than the traditional.

I learned an important lesson this weekend while equipping the mobile transportation unit with a hook up for the iPod. Don't cut a USB cable and plan to reconnect the wires. They are very small and a good portion of life could be spent on this task. Amazingly enough everything worked after the procedure. A wire stripper that works with small wires would have been nice though. Thanks Angad and Maks for the useful car / stereo links.

I found this on Security Dreamer with many comments on Schneier on Security

Beware of the lube!

Holy Cow! 27 Videos from the Google test automation conference 2007 with so much important information that my head is spinning (and I only watched a small portion =). Automation, testing strategies, mocking, continuous integration, UI automation, complex distributed system, and many different levels and types of testing explained. These really drive the importance of quality automated testing in many different forms that really push software and systems from many different angles.

The keynote gives a good overview of overall stratagies and the importance of processes like quick build / test turnarounds and developer testing.

The Mini-IP camera design targets surveillance and other types of monitoring applications. It is said to accept audio and video input from attached sensors, compress it in real time, and send it out using single- or multi-cast Internet protocols such as RTSP.

The Mini-IP camera is based on Micronas's Cypher 7108A SoC, which is powered by an unspecified 32-bit MIPS application processor core. The SoC integrates a streaming media encoder said to support MPEG-4, MPEG-2, MPEG-1, H.263, and MJPEG video encoding, together with an audio codec, external memory controller, cryptographic accelerator for VPN (virtual private network) functions. Other interfaces include a 10-bit camera/audio interface, standard PC hard drive and USB interfaces, and an HPI (host port interface) for attachment to a Texas Instruments DSP.

Sweet! I want one of these for Christmas! :)

What do you get when you cross Linux, Java and a traffic light controller?

Here's the answer:

Here's a conceptual overview of architecture:

Technical overview:

The new design's control processor will run Sysgo's ELinos 4.1 embedded Linux implementation, including PikeOS, Sysgo's real-time, POSIX-compatible execution environment add-on. The Linux component will provide a browser-based management interface accessible over the network or to on-site technicians. The real-time PikeOS environment, meanwhile, will host Aonix's PERC real-time Java component.

More information is located here.

Answer is:

More info.

These videos from Sun Microsystems are about the job of an IT manager. It's hilarious! Must watch webtv! :)

Episode 1:

(more...)