Welcome!

Welcome to the Software Development Conference West blog.

Aladdin does Software DRM Your Way

We had a fun chat with Gregg Gronowski, VP Sales for Aladdin, who are securing the (software parts of the) global village with the latest iteration of HASP. Gregg makes the very good point that, nowadays, the whole picture of software protection extends to far more than copy-protection, per se: to the proper administration of licensed components, critical support data files, etc., (and that some security strategies may not even require copy protection so much as they do a coherent scheme for select intellectual property protection, coupled with an orderly, easy-to-use solution for license enforcement, flexibly compatible with many different business models and purchase/subscription schemes).

Lately, he says, they've been doing luncheon seminars across the US, sharing with developers some of the gleanings of their research on hacking methods, tools, and risks. Pretty interesting — plus, they've picked some great restaurants.

FourJs' Genero Studio 4GL Environment

Genero is a platform-independent, distributed, highly-scaleable runtime system for developing big, data-intensive business-process apps in heterogeneous enterprise environments, emphasizing integration with existing databases and with other apps via an XML/SOAP interface to web services. On the client side, the Genero system manages an XML-based abstraction of the presentation layer that gets rendered on the client side to support HTML, Java, Windows, WML and Mac OS X — so one set of processes can drive diverse clients. FourJs has wrapped Genero with a very terse and powerful 4GL and supplied a pretty IDE with strong forms development tools, a basic integrated debugger, profiler, project/build manager, and other goodness. FourJs also offers Genero db: a high-performance/high-availability database that supports SQL-92 (plus select SQL-99 features), and extensions mapping to Oracle PL/SQL, Microsoft Transact-SQL and Informix, and ODBC/JDBC drivers, as well as its native driver for the Genero server. Runs on Windows-everything and many flavors of Linux, and promises in-memory database-like performance on huge datasets.

Plus, y'know, it's ... really not expensive. Pretty intriguing — we're gonna download their trials next week and play. More later.

AccuSoft's VisiQuest 4.1

Just met with Ian Lee, VP at AccuSoft. Their main product is ImageGear, probably the leading image processing library ... it's part of software like PaintShop Pro and is at the center of critical apps being fielded by clients as diverse as eBay and the US Dept. of Homeland Security.

At SD West, they've introduced version 4.1 of their VisiQuest package, an undeniably-cool visual programming environment for image and data analysis. It maps to ImageGear functions, natch, including them as glyphs. You can also add your own glyphs in C/C++, Perl, Fortran and other languages. And now, you can also import functions developed with MATLAB.

You get this stuff into VisiQuest, wire it up with parameterized connectors into a program flow, then put your flowchart to work on real data: 2D, 3D, 5D, hyperdimensional. Great for anyone doing information-extraction from audio, satellite imagery, multidimensional/hyperspectral imagery, etc.

---

Testing expert Michael Hunter tests the waters at SD West as he attends Dave Astels session on "Behavior Driven Development" and Linda Hayes presentation on "Cost Effective Test Automation Strategies." Michael can be contacted at http://www.thebraidytester.com/.

SDWest: Agility And Architecture

Yesterday and today have been jam-packed with interesting sessions. The best of the bunch by far, though, was the roundtable discussion on agility and architecture Bob Martin led this afternoon.

I'm still trying to decide whether SD was incredibly smart or incredibly silly in putting this session in a rather small room. Bob Martin is the most engaging speaker I know, and his sessions are always packed. This one was no exception: standing room only, with plenty of people doing just that. While a larger room would have fixed that, I think the small room actually increased the quality of the discussion by forcing everyone into such close proximity. (So I'm going to go with incredibly smart.)

The discussion was deep and funny and wide-ranging (Bob's opening question: "Which white dwarf is closest to our sun?") and illuminating. The most interesting points for me:

• Agility does not mean not doing architecture; rather, it means basing that architecture on and validating it with working code.
• When asked what you do when you get ninety percent of your application written and then discover that your architecture won't work for the last ten percent, Bob replied "Ship that ninety percent!"
• The only way to guarantee that your code/design/architecture can evolve is to constantly evolve it.
• Agility enables architecture. Agility makes architecture a continuous topic of conversation.
• The first, most important part of making code flexible is to surround it with tests.
• The ability to test your code is much more important than your architecture will ever be.
• The valuable part of planning is the act, not the resulting documents. So repeat the act over and over and over so that you gain ever more practice with it.
• Architects figure out what needs to be done and then sell that to the teams doing the work. The best way to do this selling? Pair program the implementation with them.

Bob Martin is one of a very few people whose talks I attend just because he is the speaker. Sessions like this are the reason I attend SD.

SDWest: Behavior Driven Development

This morning I'm learning about Behavior Driven Development (BDD) from Dave Astels. At its core, BDD is just Test Driven Development (TDD) with different syntax.

TDD relies on unit testing frameworks, and everything you do references testing: Your tests execute within a TestCase. You Assert that conditions are/not true. You VerifyValue class member values. Everything conspires to make you very focused on the state of the object under test. This is one reason why wars often break out regarding whether private methods should be unit tested - private methods are part of the object's state, so from some points of view it makes just as much sense to unit test them as it does to unit test the public methods.

BDD changes the focus from testing state to specifying behavior. Your tests execute within a Context. You state that behavior should/not be true. The environment helps you focus on the behavior that should result from a specific context rather than the state that should hold in a specific case.

Like I said, pretty much just TDD with different syntax. Dave believes, however, that the different syntax induces a different frame of mind. I've only been doing BDD for two hours, but I would have to agree. The language you speak affects and to some extent restricts the thoughts you can think. This is true for spoken languages, it is true for programming languages, and this morning I'm learning that it's true for design languages as well.

One potential downside is that BDD's supporting framework rSpec is only available for Ruby. (Which, I'm learning, is a very fun language!) Dave says there are Java and .Net implementations in the works, however. Hopefully we won't have to wait too long!

SDWest: Behavior Driven Development

This morning I'm learning about Behavior Driven Development (BDD) from Dave Astels. At its core, BDD is just Test Driven Development (TDD) with different syntax.

TDD relies on unit testing frameworks, and everything you do references testing: Your tests execute within a TestCase. You Assert that conditions are/not true. You VerifyValue class member values. Everything conspires to make you very focused on the state of the object under test. This is one reason why wars often break out regarding whether private methods should be unit tested - private methods are part of the object's state, so from some points of view it makes just as much sense to unit test them as it does to unit test the public methods.

BDD changes the focus from testing state to specifying behavior. Your tests execute within a Context. You state that behavior should/not be true. The environment helps you focus on the behavior that should result from a specific context rather than the state that should hold in a specific case.

Like I said, pretty much just TDD with different syntax. Dave believes, however, that the different syntax induces a different frame of mind. I've only been doing TDD for two hours, but I would have to agree. The language you speak affects and to some extent restricts the thoughts you can think. This is true for spoken languages, it is true for programming languages, and this morning I'm learning that it's true for design languages as well.

One potential downside is that BDD's supporting framework rSpec is only available for Ruby. (Which, I'm learning, is a very fun language!) Dave says there are Java and .Net implementations in the works, however. Hopefully we won't have to wait too long!

SDWest: Cost Effective Test Automation Strategies

First up today was Linda Hayes talking about Cost Effective Test Automation Strategies. She grabbed my attention right off the bat by making clear that test automation is not about reducing your test staffing but rather about your leveraging testing resources. In fact, she says, if your goal is to reduce support and rework costs, then you actually need to do more testing, not less.

Right on!

Other choice quotes:

• If you haven't achieved quality in your product development process, it makes zero sense to start optimizing (i.e., reduce testing on) it.
• The best requirement ever written is a test case.
• The one time record-and-replay is useful is to track a manual testing session. It's like the black box on an airplane - only useful after a crash.

Oh, and those cost effective test automation strategies the talk was purportedly about? Linda covered those in spades. The short version is "Build a framework". Linda is partial to using class libraries that wrap the necessary functionality for interacting with widgets (be they UI widgets, or database functionality, or SOAP messages, or whatever) that are then called from data-driven test cases. She likes this level because that functionality tends to be generic across applications, so you can use a single framework as the foundation for testing multiple applications.

I agree this is the place to start. Linda's framework is equivalent to the controls abstraction layer of our Physical Object Model. We of course see a huge amount of value in raising the level of abstraction from poking individual controls up to thinking in terms of user actions - our test cases just seem simpler when they talk about what the user is trying to accomplish rather than the details of which UI they have to poke to do so. And thanks to Execution Behavior Manager we can write just one test case and still hit every execution path.

Even so, this was a very good tutorial. Let's see if the rest of this week can be as good.