• A video recording of the SaaS talk.
• The SaaS talk handout as a PDF
• The SaaS talk slides as a PDF (also shown below)
• Transcript of the Talk, with slides, as a PDF
• Audio recording of the SaaS talk

Yes, they cost $300. Ouch.

If you travel by airplane more than 1x per year, buy these headphones.

Slightly longer review:

These headphones use active noise cancellation to dramatically slash the volume of loud environments; they work best for continuous, white-noise-like sounds (for example, riding in an airplane). The experience of 4+ hours in the air is completely different when you cut down the noise level. Wearing these, vs. not, is a more dramatic difference in overall unpleasantness, than the difference been first-class and steeragecoach.

Each AAA battery lasts a few flights, sometimes more. You can plug in your media player, computer, etc., or just use the noise cancellation alone.

How well you speak can have a great impact on  your ability to get customers, to attract employees, to persuade others to adopt your ideas, and much more. But how do you know how well you speak? You can’t tell as you are speaking; and if you’ve never heard yourself speak but simply assume you do well, there is a great risk that you are very, very wrong.

To become a better speaker, you need to review your own “performances”. For the last few years I’ve been recording my talks (at user groups etc.) with a hand-held voice recorder. I use an Olympus WS-100 (probably obsolete by now) and you can readily find an adequate device for $70 or less.

Make the Recording

Don’t actually hold the recorder on your hand. Sit it on the podium if you use one (I don’t care for podiums, I use one only if I am presenting with my computer and the podium is the only place to put the computer); but not to close to your noisy computer. Put it on a table or unused chair in the first row, but not too close to any noisy people or equipment.

Start it at the very beginning, and stop it at the very end. It is easy to edit out extra recording later.

Put in a fresh battery, so it doesn’t run out partway through.

Listen to the Recording

Take the recorder/player in your car, copy it to  your iPod, burn to CD, whatever… but listen to it, end to end. Experience your talk as a member of the audience. Make notes about any bad habits you exhibit, such as “umm”, “ahh”, “like”, “ya-know”, long (unintentional) pauses, pointless extra words, etc. This is your first opportunity to become a better speaker by means of the recording. WARNING! The first few times this might be very, very painful.

Edit the Recording

If you plan to post this audio online (as I usually do),  clean up the recording to trim off any extra starting and ending time; the audio you post should start immediately with your talk content and end crisply. Download Audacity (or another audio editing) and use it for this initial trim.

If you can spare the time (approximately 2x the length of the talk), listen through the whole recording in Audacity, trimming out the “umms”, “ahs”, overly long pauses, etc. This is your second opportunity to become a better speaker… but only for the offline listeners, and in an artificial, one-off way. Still, for an occasional important talk it is worthwhile.

Get a Transcript

Finally, be aware that your (now-pristine) audio is completely unsearchable and invisible to Google. To make it findable, have a transcript made and post that also. You can pay CastingWords or other similar service to create a transcript for around a dollar per minute, or perhaps much more cheaply with some searching. The resulting text can be readily posted online, making your talk both more findable, and more accessible.

An example of a recorded, lightly edited, and posted talk (with transcript) is my Ruby GUI talk earlier this year.

in my code I am building video frames, 720x480x24bit. I have in mind generating a large number of these, as long as a full DVD worth at 30fps, then using ffmpeg (followed by dvdauthor) to encode them in to MPEG2 for DVD usage.

There were a few replies, but no definitive answer. With considerable experimentation, I got it to work. It turns out that (as far as I can tell) ffmpeg does not have the ability to accept piped in RGB frames. It will however accept piped in data in its “yuv4mpegpipe” format. With some searching and reading I found that this is roughly akin to the format of raw DV video; each frame consists of a header something like this:

YUV4MPEG2 W%d H%d F%d:%d Ip A0:0 C420mpeg2 XYSCSS=420MPEG2

… then an LF character, then data for the the Y, U, and V “planes”. The Y data is full resolution, while the U and Y are half-resolution (this is called “420″ in the video world). These planes are uncompressed, one byte per pixel. All of my past work with computer video (going back to Commodore 64s and Apple IIs) has arranged all of the bits for each pixel within a few bytes of each other; this format (with all the Y data for the whole frame, then all the U data, then all the V data) is starkly different.

The essential problem remaining was how to convert RGB to YUV. Happily there are plenty of online references for this. Unhappily there are few fast implementations, and a naive implementation will be very slow. I solved this problem by finding and hiring an expert in low-level data processing with MMX, SSE2, etc. instructions. (I am not in a position to publish that code here.)

In retrospect, though, there are routines included in Intel’s “Integrated Performance Primitives” library which perform this transformation in a highly optimized way. IPP is a bargain: for only a few hundred dollars you get a wealth of high optimized ready-to-use library routines for signal processing.

The ffmpeg piping solution consists, therefore, of:

1. A module which generated frames in RGB format, to contain whatever contents your application requires.
2. A module to very quickly convert these to YUV in yuv4mpegpipe format (write your own, or use routines in IPP, for the RGB->YUV420 part).
3. Pipe this data stream to ffmpeg with stdin; ffmpeg is invoked something like this: ffmpeg -y -f yuv4mpegpipe -i – -i audio.mp3 -target ntsc-dvd -aspect 4:3 foo.mpg

By using a multicore CPU and threads, this whole process can be made to happen in real time or better (i.e., one second of “wall clock” processing time, for one second of finished MPEG2 video). The resulting MPEG2 file can be used with a DVD authoring application to produce a ready-to-burn DVD ISO image.

Update: the data format above is published here as part of the mjpegtools man pages.

The 1 hour audio recording (Olympus WS-100 digital voice recorder, Audacity cleanup) is available here: SAASTalk.mp3

A transcript of the talk is available. In the talk I mentioned Paul Graham’s The Other Road Ahead, which is shorter and easier to read the my talk transcript.

A couple of people at Code Camp asked if I could come give a similar talk in-house at their firms. Yes – please contact me with the contact form to arrange a date.

The handout contents follow.

Selling your Software as a Service

Kyle Cordes
May 5, 2007

An Encouraging Idea

When you open up an IDE/editor at home, on your own time, you have a remarkable power in your hands: you can create something that you own (modulo some employment agreements). It is yours to sell, to give away, or to decline to do either, on your own terms. Likewise a company has this on a larger scale.

For the last few years my firm has been selling access to an application we wrote (and continue to write) as a service, charging a monthly fee for use, hosting, and support. I won’t name names or describe our product in detail (this talk is not spam), but I will share some things we’ve learned along the way.

What is SAAS?

Delivering a software product (especially a complex “enterprise” system, less so with consumer products) involves more than just bits in a file / on a CD-ROM:

1. Delivery of the deployable code

2. License (legal right to use it)

3. Hosting: hardware, deployment, and management thereof

4. Support for the server(s) / software on the servers

5. Support for the end users / software on their PCs or other devices

In a consulting or in-house project, the most common type of project for the audience here at Code Camp, you sell hours of labor to do the things above.

In a commercial software product company, you bundle #1 and #2 for a price, then perhaps sell a service contract for #4 and possibly #5.

With Software as a Service (SAAS) you bundle #1, #2, #3, #4, and possibly #5, then sell the result for a yearly / monthly fee times some measure of volume (per computer, per user, per transaction, per site, etc.). A company selling their software in this way is sometimes called an Application Service Provider.

The Business Model

From a business perspective, SAAS offers a recurring revenue stream rather than “spiky” up front sales. In the short term this can make higher investment demands (since the revenue arrives more slowly). In the long term, though, recurring revenues are very amenable to a sustainable ongoing business.

On the downside, as a SAAS vendor you are at greater risk of ongoing payments stopping, vs. up-front payments in full when the sale is made.

Collections are typically much less of a problem with SAAS: you will generally be paid by customers in a timely way (as they would pay for electricity, bandwidth, and other ongoing utility services).

This gradual arrive of revenues will shape your company’s financial decisions: you need to meter expenses to match.

Hosting

With SAAS, your customer stays out of the “hosting business”, but you get in to it. One way to offer reliable hosting is to put your servers in a colo facility; you can typically get a full rack (with power and bandwidth) for less than $1000 per month. This will provide redundancy in the power, air conditioning, and connectivity, which would be much more costly to provide in-house.

You will become experts in hosting, by experience. You will host more instances of your software than any one customer would, so you are in a better position to do a good job doing so.

Another route, for a smaller operation, is to rent a single dedicated server or even a “virtual” dedicated server. Or, go utterly virtual and use Amazon EC2 and S3 as your infrastructure.

Support / Operations

As an SAAS firm you can offer much more hands-on support than a traditional software vendor, because you have direct and immediate access to the production systems serving your customers.

At the same time, this access will expose your team to the customer’s pain points, making it more likely those problems are fixed soon.

With SAAS you can readily deploy updates regularly (weekly / monthly) at low cost, enable end-to-end agility. Paul Graham wrote about this in “The Other Road Ahead”.

What do customers like about SAAS?

Customer love not paying for unproven software up front, even if they have abundant cash and even if the software is in use elsewhere. They avoid making an unrecoverable investment in case their needs change or the software turns out to be inadequate.

Customers generally like not running a hosting operation: not operating a data center, not hiring employees for it, etc.

Customers benefit with SAAS’s easy scaling up or down as their needs grow and shrink. Financial decision makers often prefer costs that scale smoothly with business volume.

What do customers not like about SAAS?

Customer may be concerned that they have less direct control over an application supplied SAAS, than one hosted in-house, with less ability to persuade an operator/developer to drop everything and fix it now.

Eventually a customer may spend more with SAAS (at least in terms of the checks written to the software vendor, though perhaps not in total cost) than they would have spent buying a license up-front; thus they are prone to regret that they didn’t buy an up front license.

A customer may want to customize the software in a way the vendor does not offer.

Start Fast

SAAS provides considerable flexibility in delaying software work past the product launch; “admin” features can be less complete and more rough, if they are used primarily by the vendor’s staff instead of by the customer, and can require deeper system knowledge.

There is also a risk that the ability to get by with rough edges will too easily allow you to never truly finish the product.

What’s it like to sell software this way?

The biggest difference in selling SAAS is a more substantial long term relationship with the customer, both operationally and financially. This can be a great advantage – with a close customer relationship you will be in a position to understand their needs more fully, and innovate in your software to meet those needs better.

Customizations

The purest SAAS way to offer customizations is to not charge hourly / project fees for the changes, but rather to invest in the desired enhancements then charge a higher ongoing price for the enhanced system. Hybrid customization payments are also possible, combinations of customization fees and monthly costs. Be sure your customer understands that paying for a customization, does not grant ownership of the underlying system.

Intellectual Property

While an SAAS firm usually owns (or licenses) its software, customers should own their data (and have access to a copy of the raw data, if they ask for it). Hire a lawyer to work out the details.

Go to great lengths to keep customer data separate: you must make sure to never, even briefly or accidentally, give one customer access to another customer’s data. For small, cheap services, WHERE clauses are OK for this, but for large expensive services, use (at minimum) separate databases and server code instances, and perhaps even separate hardware.

1. No travel.
2. No need to syncronize schedules.
3. The receiving person can view the recording repeatedly, at their convenience.
4. Customers and develoeprs who join the project team later, can look at old recordings to catch up.

It turns out that I am unusually picky about the quality of such recordings; I’ve written up some technical notes on how to get good results, and posted them: HighQualityScreenRecordings.pdf.

A few highlights:

• A reasonably fast computer can both run application and record screen video at the same time; but if you will be recording the use of an application that generates a lot of disk activity, you must save the video to separate hard drive (internal, external, network server, etc.) from the hard drive you are running your OS and applications from. (For applications that generate little disk activity, a single system hard drive works fine.)

• Use a headset-style microphone, and record in a quiet place: close the door, turn off the music, etc.

• Adjust your audio levels well. Please. This is the most common and most annoying problem with screencast and podcast recordings I find.

• Bytes are cheap; use a sufficiently large window and sufficiently high bitrate.

Many more details are in the PDF linked above.

I also recorded audio of the talk with my Olympus WS-100 digital voice recorder, then used Audacity to clean it up; Audacity’s “Remove Noise” feature worked surprisingly well. The recording lasts 1 hour 23 minutes, is 49 MB in size: RubyGUIToolkitTalk.mp3

A transcript of the talk is also available.

In the audio I mention screen shots and demos; you can find those at the respective toolkits’ web sites (linked below). I also briefly discuss and demo some code from a 2005 talk about Swing.

The handout contents follow below.

Ruby GUI Toolkits

St. Louis Ruby UG – http://stlruby.org – March 27, 2007

Kyle Cordes – http://kylecordes.com – Contact me via my web site

These notes will on my web site sometime this week.

Agenda

1. Review the myriad options

2. Let’s see some code

Ruby is quite popular for web applications (mostly with Rails) and for utility scripting. But there is a world of GUIs beyond web applications, a world which is not going away. To build such applications in Ruby, we must choose a GUI toolkit and Ruby bindings. My criteria for a rich client application toolkit (or the resulting application) are perhaps harsh:

• Polished, rich set of widgets (Consider the vast array of widgets available for .NET, Java Swing, Delphi, etc.)

• Consistent, comprehensible API, with both API reference and “how-to-use-this” narrative

• Robust, production-grade: No beta, no pre-1.0.

• Features beyond what’s readily possible in a web application

• Look like 2007, not 1997

• Look and feel, if desired, like a mainstream GUI application

• Actively developed and updated

• Ideally cross-platform; at minimum, great results on Windows, where most of the customers are.

• Sufficiently popular that programmers and community resources are available

In summary: it must be suitable for creating applications that people will pay for. Not merely pay for in a vacuum or an internal-project-single-bid situation, but pay for in a competitive environment where I am trying to outmatch others who are using Java Swing, Java SWT, MFC, Visual Basic, Delphi, etc.

I investigated each option enough to form an opinion of its suitability according to the criteria above. With some of them this took only a short while. Here they are, alphabetically:

Cocoa

Sadly, I don’t have a Mac. If I did (and was targeting that platform only), the Ruby-Cocoa bridge would be very appealing, as it produces applications with a completely native Mac look&feel, and appears to be a joy to program.

http://www.rubycocoa.com/

http://rubycocoa.sourceforge.net/doc/

Fox

The Fox GUI toolkit was somewhat weak when I first learned of it a few years ago, but appears to have improved considerably since then. It uses non-native widgets (which resemble “vintage”, pre-XP-Themeing Windows controls), and has a somewhat limited selection of them. http://www.fox-toolkit.org/

FXRuby, the Ruby binding, is in the “one click installer” box. The benefit of being in the box is hard to overstate.

http://www.fxruby.org/

http://fox-tool.rubyforge.org/

Gtk

Gtk, the graphic toolkit from the GIMP and Gnome problems, is a strong candidate. Gtk is stable and well documented, and thoroughly proven by the large number of polished Gtk applications for Gnome. Gtk feels most at home on Linux, but also works on MacOS and Windows. I didn’t try MacOS, but I found it works and looks good on Windows.

Glade, the Gtk GUI design tool, treats GUI layout as data rather than code. (NeXT did this in the 1980s, and MS has recently reinvented it in the form of XAML.)

To install Gtk-Ruby on Debian (from http://ruby-gnome2.sourceforge.jp/hiki.cgi?Install+Guide+for+Windows):

sudo apt-get install ruby-gnome2

Then to try it out:

ruby -r gtk2 -e ‘Gtk.init ; Gtk::Window.new.show ; Gtk.main’

Unfortunately the simple invocations above didn’t work for me; but with a bit more work the samples run well.

JRuby + Swing, JRuby + SWT

Java Swing or Eclipse’s SWT can be used with JRuby. I didn’t investigate these much (aside from running the samples), because JRuby was not yet “ready for prime time” yet, as of around the end of 2006. It looks like there has been a lot of progress since then, so if you are reading this in mid-2007 or later, give it a close look.

require ‘java’

JFrame = javax.swing.JFrame

frame = JFrame.new(“Hello Swing”)

frame.getContentPane.add javax.swing.JLabel.new(“Hello World”)

frame.setDefaultCloseOperation JFrame::EXIT_ON_CLOSE

frame.pack

frame.visible = true

Local Web Application

Ship a “local” web application: install Rails + Mongrel + etc., and launch a web browser pointed at http://localhost:port. AJAX or Flash can be used to build a richer GUI than you can get with plain HTML. Aside from the local install process (which is not difficult), the tools are mature and powerful, and programmers are abundant. Because of these advantages, and because of the various problems with the GUI toolkits, I would consider this strongly if I needed to build a local Ruby GUI app today.

.NET

There is a Ruby-.NET bridge which can use WinForms (in .NET 1.x), but it hasn’t been updated since 2004.:

http://www.saltypickle.com/rubydotnet

There is at least one Ruby compiler in development which targets .NET (analogous to JRuby). When that is ready, it will be possible to use WinForms and WPF (the new “Vista” era .NET GUI toolkit).

http://www.plas.fit.qut.edu.au/Ruby.NET/

OpenGL / SDL

There are Ruby bindings for OpenGL and SDL; I didn’t investigate these because they are most suited for producing graphical / game software rather than application GUIs. However, as application GUIs become richer, I expect the two categories to merge to some extent, so don’t rule out this approach completely.

http://ruby-opengl.rubyforge.org/

Qt

Qt is mature, stable, and of high quality. It is used for many commercial applications on Windows and Linux. The documentation is extensive and GUI layout tools are available. Qt uses native widgets on each platform. Qt is available for free for use on open source software (including KDE and the many KDE applications). For commercial use, it is less free:

$2000 per dev, for the “desktop light” edition (one platform)

$5000 per dev, for the “full” edition on 2 platforms

$more for various other packages

The QtRuby bindings are free, and described as “very complete”:

http://developer.kde.org/language-bindings/ruby/index.html

There is a book from the Pragmatic Press about QtRuby:

“Rapid GUI Development with QtRuby”

http://www.pragmaticprogrammer.com/titles/ctrubyqt/

Qt/QtRuby is very appealing, probably the most polished of all the options, except for the price. I believe the price will prevent large scale adoption. For those large corporate Ruby GUI projects, go with Qt.

Tk

Tk is in the Ruby “box” (installed by the installer, though I also saw instructions to install it separately), and has a complete, documented API. Unfortunately, it is also quite old and generally ugly; it seems more suitable for simple GUIs for utility programs, than for large, rich applications. However, this seems to be changing – the “Tile” theme engine for Tk greatly improves the appearance.

require ‘tk’

root = TkRoot.new

button = TkButton.new(root) {

text “Hello, World!”

command proc { puts “I said, Hello!” }

}

button.pack

Tk.mainloop

Win32

Also included in the Ruby installers are SWin and VRuby. SWin is a low level Win32 API binding, with VRuby is a GUI toolkit (OO wrapper) on top of that. VRuby appears to be inspired by Visual Basic or the Delphi VCL. Its controls are the Windows controls (including the TreeView and ListView), and are of course 100% native and 0% cross-platform. It uses a clever implicit event-binding technique, requiring generally 0 lines of code to bind an event to a method.

The documentation, while detailed, is in Japanese, and this is a relatively low-level toolkit, so it may be quite hard to adopt for non-Japanese speakers.

Update, January 2008: Anthony Leotta wrote in to point out that there is now good VRuby documentation, in English.

WxRuby / WxSugar

WxWidgets itself is stable, featureful, free, and used in many commercial applications. The most common way to use Wx appear to be with its native C++ API, and with WxPython. Wx uses native widgets for each platforms, and with a little work can have a modern slick look and feel.

http://www.wxwidgets.org

Unfortunately, the WxRuby bindings are incomplete and unstable – even the demo application crashed several times.

http://wxruby.rubyforge.org/

WxSugar adds a layer of “syntactic sugar” on top of WxRuby, to enable a more expressive, compact coding style.

http://wxruby.rubyforge.org/wiki/wiki.pl?WxSugar

Ruby Scripting for a non-Ruby GUI

Ruby can be used as an embedded scripting language; to do this, you’d write your application “core” in something else, then use Ruby for instance-specific business rules, plugins, etc. I demonstrated this last year at Code Camp with Lua, the same approach works well with other languages.

So What Do We Do?

I don’t have a single answer as to which of these to use; none of them has impressed me as a compelling replacement to the mature toolkits I’ve used, such as Java Swing (in the Java language, which for all its issues, is a good language to use for interacting with massive Java APIs).

Other References

Jeff Barczewski pointed out that the “Ruby Developer’s Guide” (a 2002 book by Michael Neumann), which features a free sample chapter on Ruby GUIs.

http://wiki.rubygarden.org/Ruby/page/show/ComparingGuiToolkits/TakeTwo

http://groups.google.com/group/comp.lang.ruby/msg/58504a6e39e6a1c7

http://www.trug.ca/Ruby_GUI_Toolkits

http://www.arachnoid.com/ruby/RubyGUIProject/index.html

http://www.trug.ca/VRuby

Ruby/TK tutorial: http://members.chello.nl/~k.vangelder/ruby/learntk/hello.html

]]> http://kylecordes.com/2007/ruby-gui-toolkits/feed 8 http://kylecordes.com/2007/osx-handheld http://kylecordes.com/2007/osx-handheld#comments Tue, 09 Jan 2007 21:56:27 +0000 Kyle Cordes http://kylecordes.com/2007/01/09/osx-handheld/ iPhone: Wow

It’s a phone. It’s a PDA. It’s an iPod. It’s a widescreen video iPod. It has zero physical buttons, rather the whole front is a multi-touch-screen. I’ll leave the rest of the raving to the many other sites doing a great job of that.

The real innovation of this new device is the OS. Apple has an answer to PalmOS and Windows Mobile (CE): run their real desktop/server OSX, with Unix inside, on the phone. Today’s handhelds have much more computing power and storage than desktop PCs of a decade ago, and there are enormous benefits to running a real, common OS on such a device. I’d been saying since I bought my first Palm (a Handspring, actually) than within a decade the handheld OS’s would go away.

Apple has gone first. How soon will Microsoft follow? Will Palm and RIM make to the new era at all?

(Update: Yes, the title of this post is slightly in jest. I’m serious about real OSs in handheld devices, and the iPhone looks fantastic, but Apple is very unlikely to dominate the phone market in the way the iPod dominates the tiny-media-player market.)

Update: As an experiment, I also had CastingWords prepare a transcript of the talk. It’s somewhat tedious to read (I didn’t edit it at all), but it is available as Google fodder rather than trapped only in audio.

Beans Scripting Framework

http://jakarta.apache.org/bsf/projects.html

The BSF came from IBM in the late 1990s, and was the first major multi-scripting-language plugin API. It supports many languages (BeanShell, Groovy, Jacl (Tcl), Rhino/JavaScript, Jython, etc.), with a focus on embedding script in HTML/XML. BSF is now an Apache project and supports non-web scripting as well.

BeanShell (JSR 274)

http://beanshell.org/

BeanShell supports a superset of the Java syntax; as a result you can use it as a more-pleasant-than-Java scripting language, or use it as a Java interpreter. BeanShell was written by Pat Niemeyer here in St. Louis.

Because of the Java syntax, BeanShell can be used to get code working in an interpreted way, or as part of a script plugin/extenstion, then very easily move that code in to your core application, unlike code written in a non-Java scripting language.

Another, more extreme use of BeanShell is to use it instead of javac for an entire application, to reduce the deployment size – with Java, compressed source code is often smaller than the equivalent compressed compiled classes!

Groovy (JSR 241)

Groovy is a relatively new language, whose specific syntax and semantics are being worked out in the JSR process. Its key advantage is that its design is much more compatible with how the JVM works than other non-Java languages: it is less dynamic. Thus it is likely to achieve better performance and more straightforward access to Java features, until some future JRE adds better dynamic language support.

Java 6.0 Scripting (JSR 223)

http://jcp.org/en/jsr/detail?id=223

https://scripting.dev.java.net/

It appears that starting with Java 6.0 / 1.6, a scripting API and implementation will arrive “in the box” in the form of the javax.script package and bundled JavaScript (Rhino) implementation (as the “js” language). The API is similar to the BSF API, though more refined. The API makes it easy for a host application to support multiple script languages and integrate only once. Java 6 will be released Dec. 7, 2006.

“It’s pretty hard to defend a delayed project when you are using Billy’s Scripting Language. As a project manager or IT manager you could get fired for making that decision. However, if you build an application using MegaStandard Scripting Language X, you won’t because you followed the recommendation of a standards body. Its not your fault it doesn’t work as expected.” (Richard Monson-Haefel’s blog)

Other JSR 223 compliant scripting engines: AWK, BeanShell, Groovy, UGNL, Python, Ruby, Scheme, Tcl, many more.

Rhino (JavaScript)

You probably deploy with Java 5/1.5 or 1.4 now. Use JavaScript (the Rhino engine) today via its API and 693K js.jar file; you are prepared for the future, you will be able to use the JSR 223 API and in-the-box Rhino with little effort. All existing scripts should still work.

Experience Report

We have a large “enterprisey” product; as with many such products, there are some aspects of behavior that are inevitably customer-specific and hard to accommodate through a data-driven configuration mechanism. We use Rhino / JS scripting to add customer-specific behavior, for example in the form “if fields A and B have values C and D, then field E is required”. It was surprisingly easy to add scripting support – perhaps a few pages of code to add plug points and invoke the script engine. Recommended.

What’s a scripting language anyway?

Common answers, none of which are absolute, include “duck typing”, the lack of a complex type system, interpreted execution, ability to “just load some text and eval() it”, lack of binary compatibility concerns, and sandboxed execution.

Why script?

Scripting can provide more flexible configuration than the typical data-centric configuration approach; use it whenever you feel the temptation to invent just a little bit of an programming language, particularly in XML. (A rule to live by: do not write code in XML.)

Scripting is more important in commercial systems (which serve many customers) than in internal system; be wary of over-engineering, do not add a scripting language when a lookup table will do. Yet in a commercial system scripting provide a path to make your application “done”, in spite of ever-shifting customer-specific needs.

Scripting serves as a “soft layer” in the “Alternate Hard and Soft Layers” design approach, which I illustrated with Lua at a talk last year; there are notes about the topic on my web site.

A scriptable application is generally also a testable, modular application.

Scripting opens the door to user-generated procedure content – witness the amazing proliferation of user-written scripts in Second Life.

What should my API look like?

With rules scripting, the user configures a logic behavior for a situation the application encounters, such as a “billing rule”. Provide a carefully “shaped” (but not too complex) API, such as an entry point / script per product-type. The shaped API provides good isolation between scripts, important since rules are often filled in by users with very little programming experience.

Plugin scripting is more general, allowing the user to add capabilities and features to the application, within limits. Impose much less structure on the script; exposing very few entries points (perhaps just one), then let the script register interest in events as they require. This will make it possible for a scripter with some experience, to use an intentional design for their plugin, rather than contort it to meet your API. An end-to-end plugin spans the tiers (client/server/etc.) of the application; if your mechanism assists the script by carrying ad hoc attributes along with predefined data, such a plugin can be quite powerful. For example, it could define the entry of additional data, rules for the processing of that data, billing based on that data, etc.

External scripting, common in large desktop applications like Excel, steers the operation of the application with an API that resembles the model of a user manipulating the UI, with mild additional abstraction.

Be wary of what primitives you expose to the scripts; you may inadvertently expose your entire class structure – a large and complex “surface area” for which it will be very challenging to maintain future compatibility. Sandbox your scripts as much as feasible.

But impatience is among the three great virtues of a programmer, so I turned to Google instead, seeking command line tools for audio manipulation. It turns out that sox and lame will do the job. I installed the tools – here is the Debian / Ubuntu invocation:

apt-get install sox lame

then grabbed an MP3 file of a piece of music (Peter T. Noonan, album “Cafe at Arles”, track 9 “Life’s Old Road”, if you are curious) and repeated it a few times:

sox music.mp3 foo.wav repeat 3

lame foo.wav longmusic.mp3

This worked well, the first time… but consumed a lot of disk space. To get to 3 hours I would need enough disk space for a 3 hour uncompressed WAV file. Unfortunately Sox does not support MP3 output, and I didn’t want to compress to a format it does support, then uncompress and recompress again. So I used a Unix/Linux FIFO pipe instead of a file, with Sox running in the background to fill the pipe with data for Lame:

mkfifo foo.mp3

sox music.mp3 foo.wav repeat 10 &

lame foo.wav longmusic.mp3

a little while later, longmusic.mp3 is a very long MP3 file… but not long enough, because sox fails when the “virtual” WAV file it is writing reaches 2 Gb in size, just as it fails with a real WAV file at that size. That was about 1 hour and 41 minutes – not long enough; so I ended up looking elsewhere:

The Ugly Hack

It turns out that Lame will tolerate an MP3 which consists of several appended MP3 files as its input. It complains but keeps processing when encountering the extra headers in the middle of such a file. So this solution with cat, a pipe, and Lame, worked:

cat 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 1.mp3 | lame - longmusic.mp3

A little while later, I had a 3 hour long, valid MP3 file.

• you have some video in AVI format (for example, an MJPEG AVI from a DV video camera)
• you have some background music in mp3 format
• you want a simple one-title one-chapter DVD with that video and audio

There are plenty of sites with long and complex sets of commands to accomplish these things. But for this simplest case, the essential commands are:

ffmpeg -y -i video.avi -i audio.mp3 -target ntsc-dvd -aspect 4:3 dvd.mpg

mkdir DVD

dvdauthor -x file.xml # there is a way to avoid the file by putting a few more options here

mkisofs -dvd-video -o dvd.iso DVD

Of course, there is considerable other work involved in wiring up a full solution, but that is more project specific. I hope these example commands shorten the research time for the next fellow who needs to do this core processing.

• A finger is rather less precise than a mouse pointer – hitting small targets is hard
• Drag/drop operations (or grab-adjust operations) sometimes don’t start quite where you aimed
• Your finger blocks the point on the screen where you are pressing
• The concept of keyboard “focus” is moot on applications with no keyboard

To accomodate the first two of these, I’ve built a prototype/example of a slider control to use for audio adjustment in such an application. It has these key features:

1. It does not matter if you click on the “handle” or on the rest of the bar – because with touch screen you won’t be able to reliably do one vs. the other.
2. The adjustment is not immediate; there is a limit of the speed of the adjustment to produce smoother audio control. The slider handle will move down very quickly, but will move up slowly. This avoids the possibility of an accidental touch pushing the audio amplification in to feedback.

The prototype/example looks like the screenshot here:

… but ignore the static image, it doesn’t tell the story. To see it in action, take a look at the screencast (currently in a WMV file, easily viewable only on Windows) or download the example program and play with it. The source is also on github.

This example runs on Delphi 2007 (rather old… but I had it handy on the PC at hand), then used an enhanced version of it in a production application for a touch-screen audio control system. My secondary intention was to use it as a target to create an AJAX control with the same behaviour. Anyone want to write that?