Ruby’s case statements are pretty cool and more intuitive to the C, C++ counterparts. Each object in the when statement is expected to support the === operator which is invoked with the object given in the case statement. This allows you use Range, Regexp and other objects as long as they support the === operator.

More »

It’s cool that Charlie Miller fuzzed the iPhone and broke it, but the catch phrase for me was (paraphrased) “When I start the fuzzer, I want to get some sleep and when I wake up find tons of 0-days“. I remember watching the movie with my kids and it wasn’t that the factory made awesome chocolates, but the whole thing was automated with elves and such.

More »

We use Ruby, a lot. Everything from one-off scripts to modeling protocols to building mutations to packaging these things on to the product and then some. We push the language features quite a bit with native C extensions, eigen classes, DSL’s, method yanking, method redefinition, open classes, etc. We have parsers, code generators (that output C, Java, C++ or Ruby in some cases), document generators (that output wiki pages) all written in Ruby. The online help in the product is validated during build time and then aggregated into a set of HTML pages. Our 3rd generation protocol engine which powers all of our protocols and Studio has 2,323 Ruby files in trunk with a total of 215,621 lines of code!

More »

PLC’s for short, are used extensively in SCADA networks for meter readings and equipment status reports, which are then sent over an IP network (using IEC61850, DNP3, MODBUS, etc) to the Supervisory Station. PLC’s run both a piece of software to report back up to the station while simultaneously controlling physical entities like electric motors, pneumatic or hydraulic cylinders, magnetic relays, etc. You can see where I’m going with this: There are two alternate universes here and they should not affect each other. On the measurement/controlling side, responses have to be sent back within certain time bounds or things will break leading to physical and collateral damage. On the IP side, the inherent unreliability of IP networks has to be handled. This is very similar to how routing vendors [try and] isolate the control and forwarding planes, except the forwarding plane here controls and measures physical entities.

More »

At Mu, we take testing IPv6 pretty seriously, especially since the IPv4 address space is vanishing faster than you say all octets of an IPv6 address. We released our first version of IPv6 test suite for fuzzing 3 years ago which includes coverage for fragmentation, various extension headers and and options. Most of the fun in fuzzing IPv6 happens with the extension headers which are much like IPv4 options, except it’s a chained linked-list like IKE payloads. In the one of the IPv6 test suites, we have more than 100,000 test cases that exercise various parts of the IPv6 capabilities!

More »

Since I’ve worked in UI design/development at two very different companies, I thought I’d share my observations.    The other company where I worked is Apple, on  the iPod, and I will tell you without reservation that the UI development process here is superior to what I experienced on the iPod team.

The iPod had and has some of the world’s best industrial designers, but during my tenure, our actual user interface development was subject to approval by one person, who need not be named.   All user interface changes had to be routed through this person, and much time and effort was spent preparing for and managing these interactions, in ways that were often inefficient and always very stressful.    Other than Mister Veto Power, there were really only two or three people who (from where I stood) had any real say in the iPod UI.  Everyone else had opinions, but it was far from being designed with group input.   One can’t argue too much with the end result, but, much like sausage, you shouldn’t ask what went into it.   Then there is the question of what happens when the MVP (pun intended) no longer illuminates with his perfect vision.  It’s neither a typical nor ideal design process.

Contrast this with what we have here at Mu.  We flailed a bit with our interface design process in my first year or two that I was here.   What was not working for us was what I will call a feedback prototyping process.   People would prototype UI in code, show it to a few people, make a few changes, and keep going.  There wasn’t always communication among all the UI level engineers about things like consistency of behavior,  or look and feel.   We often bit off more than we could chew (sound familiar?), because it wasn’t clear soon enough what could be accomplished, in part because we didn’t realize we didn’t have a clear enough idea of what needed to be done and how much effort that would take. We have in the last year gradually instituted a version of Agile development with sprints and Scrum meetings.    We first come up with the list of every possible two-day or shorter task we can think up, that could potentially be required to produce the new feature set.   These tasks include UI mockups.   Then, while others work on back end layers of the code, one or more people with laptops go into a cave for a few days and emerge with a bunch of OmniGraffle slides.

OmniGraffle is now our tool of choice for designing UI.  It has saved us enough engineer-hours that the cost of the Pro license paid for itself within the first few months.  It presents well and is easy to modify during a discussion to quickly show what a proposed change might look like.  Because it’s clearly  not actual code, nobody is tempted to think “It’s almost done!  Ship it!”   Because it can be made to look and behave more like a real UI during a presentation, many bad ideas are discarded right away.   Sometimes, as in today’s meeting, it’s discovered that our original idea would present the new feature in too complex of a way.  It needed some newbie user features, which four of us sat and discussed the best way to implement.    This was, I thought, simply the latest of a long series of very productive UI meetings, and that is what prompted this article.

At the meeting were mainly a UI designer, our engineering manager, another engineer with more experience under the hood of our product, our Test Automation manager (who has a dotted line into Sales Engineering), our Tech Pubs manager, and myself.   Each of us has differing perspectives on UI, and a couple of us have different aesthetic sensibilities as well.   In my opinion this makes for the best team, since everyone can catch design flaws the others might miss, and come up with options others would not think of.    Bonus: we all genuinely care about the product and don’t have our sense of self-esteem tied up in whether our ideas are accepted or rejected.   The value of this alone cannot be underestimated, because it allows us to focus on the important things:

• What is going to be of most value to our customers?  
• What can we do to make the product a joy to use?
• What will show off the product well? 

The last point is something that did not occur to me until recently.  I implemented a feature that turned out to be an excellent way to communicate what our product does to a potential customer.   I do not think anyone will be implementing features solely for use in dog and pony shows, but I do think it’s important to consider the impression you will be making on a potential customer.  A User Interface needs to explain itself somewhat, otherwise your potential clients won’t understand why they need it, no matter if you have the best sales team on the planet (I strongly suspect that we do).

We understand the importance of having buy-in from all areas of the company, including  Product Management, Sales Engineering and Marketing.   We typically have a couple of rounds of mockup draft reviews, and then have a larger, sign-off  meeting which includes people from these departments.   In more than one case, some missing but crucial feature requirements were caught in time to make sure they made it into the product.   

We have also begun sending engineers to customer sites.   We have found this absolutely invaluable for seeing for ourselves how our customers use our product, listening to their issues.  Occasionally we’ll be taken to task, but one should look at it all as good input.  If a customer is frustrated, you want to know.    I myself had a chance to clear up some issues a customer was having, even as he was (justifiably) raking the product over the coals for other things!   However, when you take that feedback and put it to good use, hearing how much people appreciate that you take their input seriously, and that they are pleased with the results, is very rewarding.

This one goes to Brian who got me back to climbing after all these years.

I used to rock climb a lot. It’s one of the few sports I cherished for the longest time before I ran out of time to focus on it. There are striking similarities between rock climbing and writing software and analytical thinking to reduce problems to its bare essence. Yes, I’ve climbed the Cathedral Peak and Royal Arches with lots of unexpected happenings, inspite of the training.

More »

While I like CentOS/RHEL as a distro, it does tend to be out of date for a lot of packages; especially if that software isn’t considered fully stable. One package in particular is Ruby 1.9, which has many critical improvements (real threads!) compared to v1.8. After a lot of searching came up empty, I grabbed the RPM spec file from the OpenPKG project and ported it to CentOS/RHEL4. More »

As I mentioned in a previous post, following is an introduction to monadic computation in JavaScript. The intent of this post is to demonstrate many advantages of monadic abstraction by implementing a concrete example from ground up. The theory behind monads I will leave to other online tutorials.
More »

After exploring Haskell for some time, I find myself often adopting functional concepts in my daily work. The exposure to functional programming has even affected the set of tools and frameworks I use. For example, having to parse a custom data format I first tend to search for a Parsec clone implemented in the currently used language. This time it was for JavaScript, but a quick Google search did not reveal any relevant projects. Therefore following is the initial attempt to a probably first general purpose parser library for JavaScript, ‘p4js’.
More »