[​​Brown Belt] For your first job, you’ll focus on one platform, but over time you’ll need to pick up more.

When most programmers think about development tools, they immediately think about the programming language. That’s only half the picture: the language is part of a larger computing platform. Consider the olden days when computers were programmed only in assembly language; each type of computer had its own instruction set, so depending on your application, some computers could offer better instructions than others.

The same is true today. Consider Java: it’s not just a programming language; it’s a language and a set of standard libraries and a virtual machine to deploy your application on, as illustrated in Figure 3, ​Java software stack​. These layers underneath your program are called the platform—it’s like the foundation of a house. Java is a platform as much as it is a language. (In fact, there are other languages like Scala and Clojure that run on the Java platform, too.)

The platform stack goes all the way down to the hardware and possibly further to the network and storage infrastructure as well. How far you need to think depends on your application. Google, for example, needs to think all the way down to how it distributes data centers across the world—as of this writing, they build Lego-style data centers in shipping containers that they can drop anywhere they can get enough power and network bandwidth.^[25]

Chances are you don’t need to fill shipping containers with thousands of computers. But what if you need to, say, store some data and query it later? Common problem. You could solve it with in-memory data structures, flat files on disk, an embedded database, an external network database…you get the idea. You need another component in your platform, and your decision affects your product as dramatically as your choice of programming language.

---

Figure 3. Java software stack

Platform Investment

Platforms require investment in the same way as programming languages, both from the individual and from the organization. At the individual level, it takes time to learn each part of the stack and how they all interact. At the organizational level, there’s fiscal investment, deployed software (either in the field or in the data center), and a whole bunch of programmers who are familiar with the platform. Because of this, it pays to take an economic view of platforms. The usual investing advice is to do your research and diversify.

On the research front, you can’t base a decision solely on reading a few web pages; you can always find ten pages that say component x rocks and another ten that say it sucks. You need to do some firsthand investigation to see how well each component works for you in your situation.

Then there’s diversification: research multiple options, and keep your design as modular as possible. Down the road you may need to switch out your database, change languages, or otherwise rip up and rework. The Internet is a good example of modular design and diversification at work. The standards for protocols like TCP, IP, and HTTP were written so any computer could implement them; therefore, every computer implemented them. This allowed Internet protocols to flourish, and many vendor-unique protocols died off.

Here are a few practical ways to choose platforms. First, come up with three possible options and set aside a fixed amount of time to try each. Setting aside the time is essential, because it removes the pressure to solve the problem perfectly from the start—you know that you’ll throw away two options. At the end you’ve prototyped your solution several different ways, you know a lot more about the problem domain, and you can make an informed decision about the best way to proceed.

Second, make interfaces between components as generic as possible. For example, when exchanging data between components, consider using a generic format like XML or JSON instead of a custom binary format. The generic format is much easier to parse using a variety of languages and allows for easier change down the road.

Actions

Let’s consider a handful of platforms and how to get started in each. You’ll notice big differences in the workflow and programming style they demand. If possible, find a mentor who knows the platforms and who can help you program idiomatically.

Warm-up: Console Interface

First, get the program logic into shape on the simplest possible platform, a console application. This requires only one program file and no GUI beyond printf(). You can pick any language you like, but I’ll discuss C.

The objective is the classic Fahrenheit/Celsius converter. Feel free to do something fancier. Here’s a quick specification:

• The user should be able to specify the conversion as command-line arguments, -c (degrees Celsius) or -f (degrees Fahrenheit).

• The user should be able to specify the conversion as command-line arguments, -c (degrees Celsius) or -f (degrees Fahrenheit).

• If no arguments are supplied, the program should prompt the user for degrees and unit.

• If the user provides arguments that cannot be converted meaningfully (non-numeric, out of range), the program needs to detect that and print an appropriate message.

This is mostly a warm-up exercise so you don’t get bogged down in the platform itself, but even a simple console application is built on a platform. In this case, it’s your C compiler and the C standard library. On Unix-like platforms, you can display your application’s dependencies with this:

You should see something like libc. This is a shared library that’s used to provide the C standard library for all programs running on your machine.

Desktop GUI

From here things can diverge quickly depending on your preferred operating system. Windows, Mac OS, Linux, and others evolved with separate GUI programming interfaces, so creating a native application means learning a separate toolkit for each. (In the case of Mac OS, it requires learning a new programming language, too: Objective-C.)

There are also ways to create cross-platform GUI programs using a framework like Qt^[26] or a platform like Java.

Here’s a specification for your GUI temperature converter:

• The program should display a window with a text field, a drop-down box for conversion, and a second text field for the conversion result.

• The first text field should be editable but allow only digits, decimal points, and plus/minus signs.

• The second text field should not be editable; it should be used only for the program’s display.

• If the temperature entered is out of range, an error dialog should tell the user why and then clamp the entered value to the closest valid temperature.

• (Bonus points) The conversion result field should update as the user types each character.

• In your code, separate the conversion code from the code that’s handling the GUI widgets and events.

The first thing to note is there’s no main() function where you’re waiting for the user to type something. Instead, you get events from on-screen widgets when the user clicks or types something. This style of programming will probably feel strange because you’re not driving the program flow; the user is.

The second thing to note is the two-step processes where you build the graphical part of the GUI first and then add the code that makes it go. In geek terms, this is separating the view from the model. (The model is all your “business logic,” which in this case isn’t much.)

Model/view separation^[27] becomes very important in large projects, because the model is often used from multiple places. Imagine a commerce application where orders are coming in from point-of-sale terminals, shipping is pulling orders out with their own application, and accounting is pulling reports using a third application. There are three views, but only one model is needed.

Web

The beauty of web applications is that you have a standard presentation layer (HTML, CSS, JavaScript) and a standard means of communicating with a server (HTTP). The ugly side is that these technologies were originally created for pages and not applications, so building your fancy web app tends to involve a lot of late nights and cold pizza.

Web applications are here to stay, of course. It’s easy to get a basic form on a page and then create a back-end server that can both vend the page and accept a form submission. That’s what we’ll do.

The specification is very similar to the previous desktop GUI case. However, I will add the following:

• The form should live on one page only, both for its initial state and after the conversion.

• The temperature conversion must be done on the server, not using JavaScript in the web browser.

• Do this first using a form and a submit button.

• (Bonus points) Instead of submitting the form, respond to the user typing in the text field and update the conversion using JavaScript and XMLHttpRequest (aka XHR or Ajax). Again, the conversion should come from the server.

The first wall people run into with web applications is that all requests are independent. That means you cannot assume that subsequent requests to your web server are coming from the same user. You cannot assume the user will go to a page you redirected them to. They can type anything in their browser’s URL bar they please, and they can simply leave your site, too.

The next problem you hit is usually complexity. Vending one page is easy; vending a hundred turns into a real mess if you don’t structure your application well. That’s when you’re best off with a framework like Ruby on Rails. Such frameworks have a large up-front learning curve. What you get in return is a modular system that can grow in complexity and scale to large traffic loads.

In all these scenarios, we’ve only scratched the surface of what each platform can do; you could collect a whole shelf of books on each one if you decide to go further. I hope you’ve gotten a taste of each type of platform and where to go to learn more.