James Turner, contributing editor for oreilly.com, is a freelance journalist who has written for publications as diverse as the Christian Science Monitor, Processor, Linuxworld Magazine, Developer.com and WIRED Magazine. In addition to his shorter writing, he has also written two books on Java Web Development (MySQL & JSP Web Applications" and "Struts: Kick Start"). He is the former Senior Editor of LinuxWorld Magazine and Senior Contributing Editor for Linux Today. He has also spent more than 25 years as a software engineer and system administrator, and currently works as a Senior Software Engineer for a company in the Boston area. His past employers have included the MIT Artificial Intelligence Laboratory, Xerox AI Systems, Solbourne Computer, Interleaf, the Christian Science Monitor and contracting positions at BBN and Fidelity Investments. He is a committer on the Apache Jakarta Struts project and served as the Struts 1.1B3 release manager. He lives in a 200 year old Colonial farmhouse in Derry, NH along with his wife and son. He is an open water diver and instrument-rated private pilot, as well as an avid science fiction fan.

## Just What Does an Architect Do?

### Other than marry Carol Brady, that is...

When computers were small and programs short, writing programs for them was pretty much a solo enterprise. But as computers became more powerful, and importantly, interconnected, you started to see software development in teams, and with teams came the most unfortunate of byproducts, management.

In a modern software development project, there are in fact a lot of contributors who have nothing to do with actually generating code. You have a product owner, determining exactly what functions the software should enable. You may have user experience designers, who are turning those requirements into a cohesive and logical look and feel. You have UI designers, creating graphical assets and fleshing out the U/X designers. There are strictly overhead roles such as managers of different flavors (including scrum-masters, who are really just a specific breed of manager). There are the developers themselves, who may include team leads. And then there are the folks with the mysterious title of Architect. But just what do they do?

In my depressingly long career as a software engineer (the career isn’t depressing; the length of it is), I have seen no title as subject to variable interpretation as Architect. I’ve seen architects that were essentially the MVPs of the project, and I’ve seen ones that are speed-bumps on the road of life. Why they are placed onto projects, and how they are used, can drastically influence the overall happiness and productivity of a team.

Let’s begin our look at the role of architects with the most negative example. There exists a class of companies that have architects Because They’re Supposed To. In this kind of environment, architects can gum up the works in a number of ways. First, these tend to be the people who Read Things in Magazines (or online). They tend to be in love with concepts like elegance and abstraction (which are good in moderation), and to some extent try to justify their existence by making things more complex. They rarely code.

Let’s call this subspecies of architect the Formalists. You can tell them by the fact that they have more books on UML and Patterns on their bookshelves than on languages and operating systems. The Formalists believe in form over function. As an example of the kind of poison they can spread in a project, I once had an architect explaining to me that my clean, compact and well-tested Java code was unacceptable, because I did not implement a single Pattern in it. I added a Singleton (which neither helped nor hurt the code), and he became happy.

The Formalist frequently kills the enthusiasm of the developers with mandates that drastically increase the workload of the developer for little to no benefit. Formalists are the polar opposites of the agile process, because they will insist on building in levels of complexity far in advance of a proven need for the extensibility provided. If you have a simple application laden with Enterprise Service Buses and Factories, a Formalist probably had their hand in the design.

Let me be clear, when used correctly, architects are awesome. Let’s label the group of good architects the Pragmatists. The primary phenotype of a good architect is that they know how to code, and code well. Beyond that, a good architect serves a crucial role in the definition of the product requirements, not just drawing boxes at 30,000 feet.

To understand this role, you have to look at the lifecycle of a successful product. After the basic product requirements have been laid out, but before developers start to implement, there’s an important step that many teams miss. Someone, and by someone I mean a good architect, needs to flesh out the requirements into a sufficiently detailed set of high-level tasks. It is in vogue these days to do this during the “grooming” portion of the scrum process, but it really needs to happen much earlier, and by someone looking at the entire product and how this particular task fits into the overall picture. The architect needs to answer questions such as:

• Do the U/X, UI, and development requirements really cover the end user requirements (i.e., gap analysis)?
• Is this task being designed and developed in a consistent fashion to the remainder of the application (and, where appropriate, the way software is developed at the company in general)?
• Is the design flexible enough to allow future enhancements?
• Does the application implement appropriate levels of security and meet required performance standards?
Comment: 1

## Upward Mobility: Android for iOS Developers, Part 4

### Sensors indicate activity on the planet's surface, captain!

Our mini-Encyclopedia Galactica can do a few things now, but it’s hardly ready to offer up the recipe for a Pan-Galactic Gargle Blaster yet. If we want to take things to the next level (or at least the next screen), we need to learn how to move between Activities.

Moving between Activities is the Android equivalent of switching between view controllers, but more formalized. In some ways, it’s very similar to the storyboard and segue metaphor introduced in iOS6. To begin with, we need to create a new Activity in ADT, using the File->New->Other menu pick, and then choosing Android Activity from the choices under Android. I chose to name mine DetailActivity, and place it hierarchically under the MainActivity. By doing this, the back button will return me to the original Activity when I hit it.

Using the blank template, I then added a large TextView at the top, an ImageView, and another TextView set to 10 lines of smaller text at the bottom.

Now we need to teach the MainActivity to navigate to this new page. I added a Button to the MainActivity layout, and then wired a listener up to it in the code in the onCreate method:

The mechanism that you use to transition between Activities is called an Intent. You create an Intent with the application context and the class of the Activity you wish to navigate to. Notice that unlike iOS, you don’t actually instantiate the new view you’re going to, so there’s no way to pre-populate values in the next view. So how do you pass in values? You stick them on the Intent, using the putExtra method. In this case, we put the planet name into the Intent, so that the detail page will know which planet to display.

One of the big gotchas with passing data via Intents is that you can’t just throw any old object onto it. Because of the Android architecture, it either has to be a simple object like a String, a primitive, or something that implements Serializable. You can also put Bundles or Parcels onto it.

Comment: 1

## Putting Developers to the Test

### Whiteboards and manhole covers won't find you a great programmer

Let’s imagine for a moment that you’re one of the world’s greatest chefs. You are a graduate of the CIA, have run a four-star restaurant, and had your own show on the Food Network. Now you’re interviewing to run the cafeteria at the hottest new startup in Silicon Valley (they’re offering major equity). After chatting for a bit with the CEO, she leads you outside the building. “I want to see how you work,” she says. “Cook me a meal.”

“Ok,” you respond, “where’s the kitchen?”

“Oh, no. I want you to find firewood in the park over there, build a fire ring, start a fire by rubbing some sticks together, then make a spear and hunt down a deer and cook it on the fire.”

I’ve recently had the pleasure of going through the job interview gauntlet with a few companies, and that’s essentially the process that most firms use to evaluate potential employees. They sit you down in a conference room, have someone pose you some kind of programmatic brain teaser, and then expect you to work it out on a white board.

This is so far removed from the realities of what a software engineer actually does today that you might as well be asking the candidate to sketch a portrait of the interviewer. I’m relatively fluent in at least dozen languages, but I don’t try to keep everything in my head at once. If I’m coding in Java, I’m using Eclipse. If I’m working on iOS apps, I’m in Xcode. I constantly hit command-space to autofill method signatures. I hover to get Javadoc. I search the web for code fragments.

Larry Wall says that one of the virtues of a programmer is laziness; do the least work that is needed to get the job done. When you’re hiring a developer, what you want to know is how efficient he is, and how good his code will be. If he can find the solution to a problem in five minutes of searching, it’s better than having to grind for hours trying to solve it without searching. Whiteboards don’t test that.

Comment: 1

## Upward Mobility: Android for iOS Developers, Part 3

### Handling Input Events

Now that our Android app lets you choose what planet you’re on, we should use that information to update our “Hello, world” message based on the selection. To do that, we’re going to need to handle the selection event on the spinner we created.

To do this, we need to set the setOnItemSelectedListener property on our spinner to something that implements the OnItemSelectedListener interface. The simplest way to do this is to implement it in our activity.

This is pretty straight-forward stuff. You use the parent.getItemAtPosition call (where parent is the spinner) to get the item that you selected. The item is just the string value of the selection, so we can use a simple string compare to select the appropriate message. In the same way that we got the spinner using it’s id, we can get a handle on the text view at the top of the screen, and then set the message using setText.

There are a couple of things to point out here, however. For one, the onItemSelected message gets called when the widget is created, a fact that irritates the heck out of Android developers. This means that you need to ignore the first call to the method. Thus, the purpose of the spinnerActive flag. Secondly, because we’re using the Activity as the listener, you could end up with problems if you have multiple spinners on the screen, since they would all call the same listener. You could either use the AdapterView value to determine which spinner fired the event, or use private inner classes to handle the various spinners.

Now that we’ve got our listeners implements, the last step is to tell the spinner to use the Activity as the handler.

Now when we fire up the app and select a value from the spinner, we get a personalized welcome message!

Comment

## Upward Mobility: Android for iOS Developers, Part 2

### Turning Hello World into something useful

When we last left our application, it was running on the emulator, but didn’t do much.  This week, we’ll add some more controls to our activity and wire up some functionality.

As a reminder, activities are roughly equivalent to view controllers in iOS. Right now, there’s not much in our activity, because all we have is a single label in our activity. As iOS developers, we’re used to never looking at our XIB files in the raw, because they’re pretty much human-unreadable. By contrast Android layout files (which end up in the res/layout folder in a standard Eclipse project) are both readable and intended to be edited. At the moment, here’s what ours looks like:

Comment

## Upward Mobility: Android for iOS Developers, Part 1

### Welcome to the dark side: we have cookies

Like many hardcore iOS developers, I’ve eschewed learning “the other platform” because I was happy in Apple-land. In addition, the few forays I’ve made into Android development seem to show that it was a more complex and difficult platform to work with. However, recent developments (e.g., a new job) have placed me in a position where I’m going to need to have at least a casual familiarity with Android development, so I thought I’d bring you all along on my journey.

## Getting the Development Environment Set Up on OS X

The good news is that, unlike iOS, Android is a development-platform agnostic OS. If you go to the Android developers site on a Mac, you’re going to be immediately presented with the option to download a zip file with the complete Android Developer Tools package. Fair warning that it’s pretty large, nearly 400MB. Of course, for folks used to downloading multi-gigabyte XCode drops, that may seem pretty reasonable.

Once it’s downloaded, unzip the file and move the resultant adt-bundle-mac folder into somewhere permanent. The install documentation recommends the /Developer folder, but since /Developer has been deprecated lately, you might want to just create a top level /Android folder instead.)

One additional step I took was to rename the version of Eclipse that ships with ADT to ADT-Eclipse. I already have a version of Eclipse that I use for general Java development, and I don’t want to launch the wrong one from Spotlight accidentally.

Once you’ve finished installing ADT, you can launch their version of Eclipse from Spotlight and, just like every other version of Eclipse, the first thing you’ll be asked is where you want to create your workspace. Just as with the renaming of the Eclipse application, I gave my workspace a unique Android-y name, and told Eclipse not to ask me again. This should prevent me from accidentally opening my normal Java development workspace.

Once Eclipse launches, it’s going to ask you if you want to send anonymous statistics to Google. This is a choice between you, your maker, and the NSA, so choose whatever makes you feel happy. The next thing that you’ll be presented with is a welcome popup, with the option to either create a new Android app, or run through some basic tutorials.

The tutorials aren’t actually built into the ADT. Instead, clicking on one of the links will bring you to a web page with a walkthrough. There’s not a lot of value in having me take you through a tutorial that’s already been written in detail, so I’ll hit the high points.

To start, create a new Android project. If you still have the welcome screen up, you can do that by clicking on the New Android Application... button. Otherwise, you can get to it from the File->New->Android Application Project toolbar item. You’ll immediately be presented with the New Android Application dialog.

The Android New Project Screen

There are a couple of important decisions you need to make here. The first is the package name for the project. This is equivalent to the bundle identifier in iOS development, and it needs to be unique. Luckily, iOS chose to adopt a Java-like reversed domain-name structure for bundle identifiers, so you should already be familiar with this concept.

The other big decision is the minimum version of the SDK that you will support. In iOS, we’re used to dropping support for old versions of iOS on a regular basis. Most iOS developers don’t support iOS4 anymore, and it’s not uncommon to see iOS6 as the required version for newer apps. This is because Apple has been very aggressive about carrying forward devices to new versions of the operating system; about the only things left behind by iOS6 were the original iPad and some iPod touch models.

By contrast, most Android users are at the mercy of their carriers for OS upgrades, and the story isn’t pretty. If you check Google’s own adoption stats, nearly half of all Android users are still stuck back on Gingerbread, a release now more than two years old. And, in fact, the wizard recommends you go back even further, to Froyo.

Does this mean that you can’t take advantage of the latest and greatest features in Android, and still deploy an app that the majority of users can run? No, but it does mean that you’re going to have to fail gracefully when new features aren’t available. iOS developers have had to occasionally do this in the past. For example, when new callback methods were delivered in iOS6, we had to keep both versions around to make iOS5 work. But the long, long version tail of Android means that you will have to take this practice to the next level.

## Upward Mobility: Give Your iOS Table Cells Some Class

### You're not stuck with the stock options when creating tables

UITableView is the meat and potatoes of many iOS UIs, but if you restrict yourself to the off-the-shelf table cell styles, you’re missing out on a lot of opportunities for customization. By using a combination of variable cell heights and a custom UITableViewCell class, you can make UIs that look nothing like a standard table.

To see how you can make this happen in your applications, let’s start with the world’s most boring table example, a list of my favorite foods.

The implementation for this is the stock table view code you’ll see in any iOS tutorial:

So, what can we do to take this design and make it our own? We can start by designing our own class that extends UITableViewCell, and that has its own XIB file, which we’ll call FavoriteFoodCell. There’s not much to it:

Next, create a new Interface Builder XIB file of type View. Set the class of the View to FavoriteFoodCell (not the FileOwner; keep that as a generic UIViewController.) We’ll add a label and an image view, so that the cell looks like this:

Comment

## A Commencement Speech for Graduating 2013 CS Majors

### Passion isn't just for romance novels.

Graduates, parents, guests, members of the faculty of <%= college.collegeName %>. I am honored today to have the opportunity to speak with you, as you move out of the cloistered environment of higher education, and into “the real world.” Except for those of you moving on to postgraduate degrees, of course. You will get to enjoy a life uncluttered by 401Ks and team building exercises for a few more blessed years.

But, for the rest of you, today marks your first step into a journey that will last the rest of your life, unless you’re able to cash in on your equity in some startup, in which case I’m sure you’ll be hearing from the
<%= college.collegeName %> alumni office before the check settles from your brokerage.

In my 35 years of experience in the software field, I’ve met a lot of developers, young and old. And the one thing that separated the truly successful ones from the crowd is passion. Now passion is an overused and abused term these days. Too often people take it to mean a passion for being successful, for achieving a personal goal in their life. When I talk about passion, I mean love. I’ve been in love with computers since I was 14 years old, and I’d be playing with them even if I didn’t get paid for it. If software engineering is merely a means to an end, you’re not going to be happy in the long term working in this field, because much of it is God-awful boring unless you have a passion for it.

Being passionate about software is critical to being successful, because the field is a constantly moving target. What will net you \$130K today will be done by junior programmers in five years, and unless you’re constantly adding new tools to your belt, you’re going to find yourself priced out of the market. Many of the best projects I’ve ever worked on came to me because I had already gained the skill-set on my own. Play around with new technologies, contribute to open source projects, and you may find yourself with an opportunity to apply those skills on the job, and get them into your resume. You are rarely going to get an opportunity to have your current employer pay for you to learn things, so learn them on your own and be in a position to leverage the skills when a new project comes along. But if you have a passion for technology, you’ll already be doing it, and enjoying it without needing me to tell you to. That’s why passionate people have a leg up.

People in their 20s tend to jump into small, fledgeling companies, and that’s one of the best things you can do. A junior developer at Fidelity or Akamai is going to work on one thing for long periods of time, while at a start-up you’ll get a chance to jump all over the place, learning many different aspects of the field. But don’t fall into the trap of trading long hours and happiness for the gold ring of equity. You are never going to be in better shape, less constrained by responsibilities, or have more energy than you will right now. Burning 80-hour weeks grinding code is a terrible waste of that gift. Most companies crash and burn, and that equity they gave you will be just toilet paper. It won’t pay for the time you sacrificed eating take-out pizza in front of a glowing tube rather than enjoying the best years of your life.

If you’re passionate, you’ll do the job you’re required to do, and more, but don’t let your employer abuse your enthusiasm. One of my tenets of life has always been that “a lack of planning on your part does not constitute an emergency on my part.” There will be times in your life when you have to step in and fix genuine, unforeseen emergencies, and burn the midnight oil. But if you’re being asked to do it regularly, just because your company didn’t allocate enough resources to see the job through, you’re being played for a patsy.

Consider the benefits of loyalty to your employer. More than just about any other industry, software suffers from a nomadic workforce, where spending five years at a single company is rare. Remember that in a good work environment, you make friends as well as money, and as much as you may say you will, you never keep in touch with them when you move on. But don’t be afraid to jump ship if you are truly unhappy where you are, either.

## Upward Mobility: Special Effects Wizardry

### Dress up your UIViews with a few simple tricks

Most developers aren’t great UI designers (although, as with everything, there are exceptions). But there are a few quick tricks that can dress up an app, even if you don’t eat and breathe Photoshop. Let’s look at a simple iPad single-view app with two views, each of which contains a label and a text box.

This is about as Plain Jane as you can get in an application; the only concession to visual appeal that has been made is to use a grey background with white UIViews bounding the labels and text boxes. One easy tweak we can use is to make the UIView corners rounded instead of square, which will lend a bit of flare to the design.

This is actually harder than it should be. To set rounded corners, you need to dig down into the CALayer underneath the view:

You need to set masksToBounds, because otherwise the corners will not be transparent, and the background color of the view will block whatever is beneath it in the parent view. The resulting view is subtly more classy. You can get more rounding by adjusting the cornerRadius value.

So far, so good. But that solid grey background is kind of blah, so we should dress it up a bit. An easy way to make a background pop is to use a gradient fill, a technique that the aforementioned Photoshop jockeys know and love.

Comment

## Upward Mobility: Dump Those iOS Delegates

### Blocks are the way to go

Because so much of iOS programming involves the delegate pattern (the UITableViewDelegate being a prime example), it’s natural that when programmers are developing their own classes that need to be able to asynchronously call back to a client class, they would use the delegate pattern as well. The problem with delegates is that they are fairly inflexible. For example, let’s consider the following (totally inappropriate) use of a delegate:

The problem lies when you need to call this method twice from the same class.

So far, so good, but what happens if you want to have a second method in the same class call multiply? You can only have a single delegate method, so you have to start jumping through hoops to let the delegate method know where to put the resulting value.

The modern solution to this is to use blocks. People tend to shy away from them, because the syntax is a bit arcane and un-Objective-C, but they are incredibly powerful, and Apple has signaled that they are the future, by starting to use them heavily in areas such as animation.