Do We Still Need Programmers?

When reading descriptions of how software is produced, I often wonder what role programmers play. Programmers used to be the people who made software, but now a lot of other people are involved and claim credit for doing the work.

There has to be an "architect" who guides the overall structure of the system. Often architects are former programmers, but they are far too important to write any code anymore.

Then there is the "user experience" designer, who decides how the software should interact with its users. We used to call this "user interface design", but the UX people have redefined UI design to be the monkeywork of laying out controls and fields on forms. Programmers can't be trusted with any important design decisions.

There is the database administrator (DBA), who ensures that the programmers can't screw up the database schema.

There are testers who tell the programmers whether they have done their jobs well enough.

With all these other people making the important decisions, what does a programmer do? Apparently programmers are glorified typists who transcribe specifications written by architects and UX designers into code that is verified by testers.

Of course, that's not how things are.

While there are teams and organizations that operate as described above, a lot of software is created by solitary programmers. The boss says "We need feature X," and a programmer then designs the user experience, updates the database schema, implements the new functionality, tests it, creates some new icons in Photoshop, adds a couple of pages to the user manual, and deploys the new software to the customer.

Somehow a programmer is able to do this without help from all those people who are too important to write code.

Those other people aren't useless. Software is certainly better when a good architect and good DBA maintain its structure, and when a talented UX designer makes it easy to use, and when good testers find the problems. But software is still made by programmers. Those other people don't make software—they make wishes.

UTF-8

Matt Gallagher's "User interface strings in Cocoa" post is good for its overall purpose (telling people how to use NSLocalizedString()), but I especially like this little embedded rant:

A quick swipe at almost everybody: UTF-8 has been around since 1993 and Unicode 2.0 since 1996; if you have created any 8-bit character content since 1996 in anything other than UTF-8, then I hate you.

I weep to think of the years of programmer time that are still wasted attempting to support non-Unicode formats without characters getting garbled because people are still creating content using ancient encodings without useful identifiers to indicate what nonsense encoding they're using (or worse, people creating content that explicitly uses the wrong encoding for an encoding-specific text field).

MacRoman? Atrocious. Big-5? I hope you want to see garbage output. Windows Latin? You suck. If you're creating new content using anything other than UTF-8, UTF-16 or UTF-32 then you should be forced to serve prison time with whatever idiot monkey decided that UTF-16 should be allowed little-endian and big-endian variants instead of a single authoritative encoding.

Yeah, seriously. If you call yourself a programmer, but you don't understand what all this Unicode, UTF-8, and UTF-16 business is about, please read Joel Spolsky's The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!).

The Apple Store Needs a Checkout Counter

The Apple Store is a great place to go if you want to play with new Apple products or get help at the Genius Bar. But if you go there to buy something, the experience is confusing and humiliating.

Everyone knows how the process of buying something at a store is supposed to work:

  1. You pick up the product(s) you want to buy.
  2. You go to the end of the line at the checkout counter.
  3. When it's your turn, you step up to the counter, transact your business, and go on your way.

In contrast, here is how things work at the Apple Store:

  1. You pick up the product(s) you want to buy.
  2. You stand there like a child who has lost his mommy, looking around for a friendly Apple associate who can help you.
  3. As the Apple associates are always busy helping other customers, you pick one and stand nearby, hoping to catch their attention when they are finished with the current customer.
  4. Eventually, after helping the current customer, and maybe a few others who are also standing nearby, the associate asks how they can help you. You say you want to buy the things you have been holding. The associate says, "OK, I'll find someone to help you", and goes to look for one of the associates who has one of the magic credit-card-reading devices. You stand there looking lost again for a while.
  5. Eventually, a person with a magic device arrives to let you make your purchase. You fumble around, juggling products between your armpits, your crotch, and under your chin while you present each item for scanning. Then you drop all the items while you dig out your wallet and credit card.
  6. While you pick up the items you have dropped, the person swipes your card, then hands the little device back to you so you can check some boxes and sign your name. Again, your items have to go into your armpits and onto the floor.
  7. While you pick up your items again, the person goes to one corner of the store to get your printed receipt, then to the opposite corner of the store to get you a bag, then back to you. You help the associate put your items into the bag, and then you go on your way.

Wouldn't this all be easier if there was a checkout counter?

Sometimes the old ways are best.

What I've Learned about iOS Development

I've been playing around with development for Mac OS X and iOS for a few years. I've had a pretty good grasp of how Cocoa and UIKit worked, and I've written some simple apps, but for the past month I've been working on my first Real iOS Application. I've had to solve some problems that were easily ignored when writing little apps for fun. What follows is a randomly ordered collection of some of the little techniques and tips I didn't know before, which may be useful for other Cocoa newbies.

App Idea: Prose Translation Assistant

(This is just an idea. As I explain my post about Why I Loved The Social Network, I think ideas are cheap, so if you want to "steal" this idea and make the app, I heartily support you.)

A friend has started a personal project to translate the works of Jules Verne from the original French into English, as he is dissatisfied with the existing English translations. He is going about it pretty much the way I would: he has a browser window open with the original French text, a browser window with Google Translate, and a text editor where he is writing the English translation. He also has a French-English dictionary on hand.

I wondered whether there might be some software available that is specifically designed for this purpose. Some Googling finds plenty of applications to assist in translation, but all the ones I found are designed to help translate conversations, e-mails, or other such things. I couldn't find anything designed for assisting with translating a novel, play, or other such work, where the translation needs to be written by a human in an accurate-but-artful way.

It got me thinking about how I would design an application to assist with this process, making it less necessary to switch between various applications and documents.

Why I Loved The Social Network

I'm writing this the night before the Oscars, but that is not why I'm writing. I only saw three of the films nominated for Best Picture: The King's Speech, True Grit, and The Social Network. While I enjoyed The King's Speech and True Grit,, I haven't thought about them since I saw them. In contrast, I still think about The Social Network every day.

For some, The Social Network is just a story about how an arrogant jerk became a billionaire by screwing over his friends and business associates. I didn't see it that way. To me, it is a story about the nature of creativity and invention.

Setting Up for Use of Microsoft Symbol Server

When debugging native Win32 code, it is useful to have the debug symbols for all of Microsoft's DLLs. The easiest way to set this up is to just set an environment variable before starting Visual Studio (or other Microsoft debugging tools):

set _NT_SYMBOL_PATH=srv*c:\symbols*http://msdl.microsoft.com/download/symbols

The first time you run the debugger after setting this, it will take some time to start as it downloads symbol files from the Internet into your local symbol cache, but it will be faster after that. Whenever you update your system with patches or service packs, the new symbols will automatically be downloaded the next time you debug.

For more information, see these pages:

(This post is really for my own benefit. I have trouble finding this information whenever I set up a new development workstation, so I'm putting it somewhere I'll know to look.)

Visual Studio 2008 Code Snippet for Inserting a String.Format() call

Over the past year I've been (re-)learning how to use Visual Studio 2008. I did a lot of work in the 90's and early 00's with Visual Studios 5, 6, and 2003, but then I had a few years away from Windows development, and I've had limited experience with .NET development. So I'm constantly discovering "new things" about Visual Studio that my coworkers already know.

One nifty feature of Visual Studio is "code snippets", which are basically little bits of code that can be quickly inserted into a source file using Intellisense. The inserted code includes placeholders that can be replaced with whatever you need. For example, if you are typing away in a C# source file and type the keyword for, you'll see the Intellsense window pop up with "for" as the selected item, and if you hit the Tab key a couple of times a complete for statement with braces, a loop variable, and everything will be inserted. You can then hit Tab to move to the loop variable name (in case you don't like i) and again to go into the loop body.

(Other IDEs have similar features, calling them abbreviations, macros, etc. You don't need to tell me that Visual Studio isn't magically unique.)

Visual Studio has a whole bunch of these snippets built in, but you can also define your own by writing an XML file and saving it where Visual Studio can find it. For example, here is a snippet I wrote to quickly insert String.Format() expressions:

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>String.Format</Title>
      <Description>Creates a String.Format() call</Description>
      <Author>Kristopher Johnson</Author>
      <SnippetTypes>
        <SnippetType>Expansion</SnippetType>
      </SnippetTypes>
      <Shortcut>sf</Shortcut>
    </Header>
    <Snippet>
      <Declarations>
        <Literal>
          <ID>format</ID>
          <ToolTip>Replace with format string</ToolTip>
          <Default>format</Default>
        </Literal>
        <Literal>
          <ID>arguments</ID>
          <ToolTip>Replace with arguments</ToolTip>
          <Default>arguments</Default>
        </Literal>
      </Declarations>
      <Code Language="CSharp">
        <![CDATA[String.Format("$format$", $arguments$)$end$]]>
      </Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

Just save this as a file called StringFormat.snippet in your Documents\Visual Studio 2008\Code Snippets\Visual C#\My Code Snippets folder. (You can specify another location using the Code Snippets Manager in the Tools menu.) Then, when editing a C# source file, if you type sf and hit Tab a couple of times, this will magically appear in your code:

String.Format(" format ", arguments )

The format placeholder will be selected, so you can replace it with your format string, then hit Tab and the arguments placeholder will be selected, so you can replace it. You can keep hitting Tab to go back and forth between the placeholders. When finished, hit Return and the cursor will go to the end of the line.

Alas, snippets only work for C#, Visual Basic, and XML editing. Most of my work is in C++, so I have to keep writing code the old-fashioned way there (or use macros).

Note that I have been talking about Visual Studio 2008. "Why aren't you using Visual Studio 2010?" some will ask. Shut up.

For a more comprehensive tutorial on creating code snippets, see Switch On The Code: C# Tutorial - Visual Studio Code Snippets.

AppleScript for Bulk Conversion of PowerPoint Documents to Keynote

The instructor in one of my MBA-prerequisite classes distributed a set of PowerPoint presentations as course notes. I want to review these on my iPad, so I needed to convert them to Keynote.

This is pretty easy to do manually on a Mac: Just right-click the PPT file, select Open With... -> Keynote from the menu (which reads the PowerPoint file into Keynote), then File -> Save As... to store it where you want it. However, I am a programmer, so I would rather spend a few hours figuring out how to write a program to do a repetitive task than simply spend the five minutes needed to do it by hand.

At first I tried using Apple's Automator utility, which is supposed to make stuff like this easy, but I couldn't figure it out. So, I took the plunge into AppleScript.

As with every foray I make into AppleScriptLand, I was frustrated, annoyed, saddened, and exhausted by the experience. But I did succeed (if two hours spent futzing with AppleScript can possibly be called a success).

So, if you have need for a utility for converting a bunch of PowerPoint files to Keynote, open up the AppleScript Editor and copy and paste this script into the window:

on open droppedFiles
    set theDestinationFolder to (choose folder with prompt "Choose destination folder") as Unicode text
    repeat with theFile in droppedFiles
        tell application "Keynote"
            open theFile
            set theSlideshow to slideshow 1
            set theDestinationPath to theDestinationFolder & (name of theSlideshow)
            save theSlideshow in theDestinationPath
            close theSlideshow
        end tell
    end repeat
end open

Click the Compile button, and assuming you see no errors, choose File -> Save, set the File Format to Application, and save it to the desired place with the desired name.

Then, to convert files, just select them in the Finder and drag them onto the application icon. You will be prompted for a destination folder, then the script will do its thing.

The script looks pretty simple and straightforward, right? Well, AppleScript is a language that is easy to read, but very, very difficult to write. Every programming language that tries to "look like plain English" is a nightmare to use, because like English, the rules are illogical, arbitrary, and self-contradictory. Every application, like Keynote, has its own commands and object types, and the documentation is poor, so you end up doing a lot of experimentation and hair-pulling. The hardest part of this particular script was figuring out that I needed to add the as Unicode text conversion in order to produce a valid file path.

(This article is based upon my question and answer in the Ask Different Q&A forum.)

Air Display vs. MaxiVista

Most of the time, I work at the Windows 7 computer in my home office with a dual-monitor setup. A lot of non-geeks have never used a dual-monitor setup: you will just have to trust me when I tell you that, for a programmer or any other person who needs to look at a lot of information all at once, it is much more productive than a single-monitor setup. It's not a luxury—it's a necessity.

When I have to leave the home office and go into the office office, I take a Windows laptop. This is less productive, due both to the small screen size and the fact that I have only one screen. So I decided to try out a couple of apps that allow one to use an iPad as a second monitor.

Syndicate content