My favorite example of this came to me by way of Phillip Alvelda. Tech folks know him as the founder and former CEO of MobiTV. But his latest passion is his foundation, the Westminster Institute for Science Education. Through it, one of the courses he teaches is basic programming for middle schoolers. And what is he using for his course ? The iPad.

After his time at MIT, CalTech, NASA and in the tech startup world, Alvelda is now tackling the decline of science in schools’ elementary, middle- and high-school curriculum. What kids are currently taught does not “have much to do with what science is actually like,” Alvelda tells me. “It’s more about history of science and other people’s ideas.”

His foundation’s philosophy is to teach young people the power of creative exploration using 21st century tools. The class he teaches uses the iPad (a 21st century digital tool that’s far cheaper than anything most schools can afford of similar capability, he says) and an app called Codea. The app enables the creation of games and projects right on the device using the Lua programming language. (See video below for example.) Alvelda (who has no affiliation with Codea) calls it “a completely powerful and self-contained programming environment” that he says is great for teaching simple programming, something he considers essential for them when they eventually become working adults.

Codea, which first hit Apple’s App Store in October for $7.99, was created by Simeon Nasilowski, a programmer living in Adelaide, Australia who says he started designing the app never imagining it would be used in an educational setting, much less anyone else even seeing it.

He’s a mobile app developer by trade, but built Codea for himself because, he says, he wanted to write a bit of code but didn’t have his laptop on him. Most of the time, if he was away from his desk and inspiration stuck, all he’d have on him was his iPad.

But it wasn’t just about convenience for Nasilowski either. He also believes in touch as a fantastic interaction mode for programming for its ability to simplify the sometimes needlessly complicated. An example, cited by Nasilowski:

When you write code you could try to define a color as three values, red, green and blue with values between 0 and 255. You might type “120″ and that’s some sort of gray. In Codea, if you have a function or part of your code that requires a color, it highlights that part of the code and it pops up a color picker you choose from there.

That simplicity and ease of interaction is what makes this app and a tool like the iPad so appealing to Alvelda and other forward-thinking educators. The iPad is a cheap, simple way to teach programming, the potential lingua franca of the future. Plus, you don’t need a developer license or a lot of money. But despite all the possibility and promise of that, Apple’s stance on certain kinds of coding apps is working against this goal.

Codea did make it through the App Store verification process — Apple somewhat relaxed rules last year that stated apps cannot contain any non-Apple executable code. Now the rule limits only downloadable executable code. Other coding apps have been approved too, like Textastic, For: i and Koder.

Codea has seen 25,000 downloads since October, but just last week Apple contacted Nasilowski and had him take out the code-sharing feature of his app. A disappointment for sure. It’s not just Codea though. A more high-profile kerfuffle happened in 2010 when Apple rejected Scratch, a well-liked programming app for kids created by MIT’s Media Lab. The reason it was rejected was under the former rules — that have since been relaxed — that banned any executable code that wasn’t Apple’s.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Flash analysis: Steve Jobs
• Forecast: Tablet App Sales To Hit $8B by 2015
• Forecast: the evolution of the e-book market

1. Source code. Great movie, eh? But also, when a developer writes software, source code is the actual program as it is being typed into the computer, written in a programming language. Source code is usually kept secret and closely guarded by companies, although “open source” software bares its code to the world.

2. Regression. A programmer friend once mentioned that a bug was “regressed.” I had vivid images of animals regressing to primordial ooze. Software regression is a bug that makes things stop working correctly after an event that changes the operating environment, like a system update. Not to be confused with regression testing, which in the programming sense, generally means making sure updates to software don’t introduce new bugs to existing, working features, and that previously identified bugs have been fixed. So it actually has nothing to do with science fiction.

3. Deprecated. “Cheer up!” might be your first reaction to your friend who tells you a critical programming library he or she relies on has been deprecated. That actually isn’t a bad instinct, because when something is deprecated it means it’s no longer supported by the manufacturer and may disappear in the future. If your program relies on a feature Apple has deprecated, your program could “break” in new OS versions unless you update it to use newer programming libraries. Generally speaking, if something is deprecated, it means it’s still there, but is no longer supported.

4. Release Candidate. No this isn’t about politics. Many readers probably know that a “test” phase of a program is a Beta. At some point, though, a product moves past the Beta phase (and the even earlier Alpha phase) and becomes a Release Candidate, usually designated RC. It might also be referred to as a Final Candidate or FC by some. Marking a build an RC or FC is the developers’ way of saying “we think this is probably good enough to ship.” Apple often releases several Final Candidate builds, the last of which becomes the…

5. GM. No this isn’t the General Manager (my first thought!), but rather the Gold Master. The code is frozen, and the FC designated the final GM is what ships. There should be no code differences between the last FC and the GM. Having the GM installed is pretty much equivalent to having the product. It’s the master version which is turned into the product: shipped on disk, downloaded or sold via the Mac App Store. You might hear people say software has “gone gold”; this is what they’re talking about.

So to review, when someone says “After we regressed our app in the new Mac OS, we found out that a library we relied on had been deprecated, so we went back to the source code to recompile our program. Now we have a solid FC and hopefully we’ll go GM next week!” you’ll know exactly what you’re talking about.

What other programming terms have slipped you up in casual conversation, and what are some other definitions you think people might appreciate?

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Why iMessage won’t kill SMS
• Mobile Q1: All Eyes on Tablets, T-Mobile and AT&T
• A Media Tablet Forecast, 2011 – 2015

Golden % Braeburn is a company that has been setup to license the storefront used to sell Wil’s most excellent Delicious Library. He tried to find a usable storefront to license since there are many pitfalls to creating your own. Security concerns, state & federal tax nuances, international fees & taxes considerations, interfacing with banks and credit clearinghouses and management of product keys are just a few of the nightmares awaiting those DIY’ers. Mac developers could just use sites like Kagi, but you are then limited by what they provide and must fit into their box. Not being satisfied with any of those options, Wil rolled his own.

With Golden % Braeburn, Wil licenses the full source code to you to do with as you please (except for the removal of the code which calculates his “piece of the action”). If you make changes, Wil will evaluates the efficacy of the feature(s) and can choose to incorporate them into the main codebase to share with other Golden % Braeburn users.

Here’s everything you get:

• a 100% Cocoa app & app components
• store front-end
• store back-end (credit card processor / transaction keeper)
• remote client (to manage licenses and the store)
• expo store (allows on-floor credit swipe & receipt/license print)
• QuickBooks integration
• on-the fly localization (Wil talked about this library he wrote and it is pretty neat stuff …if you’re a developer)
• AppleScript integration

Users experience the store within your application as a sheet. The interface is completely customizable and has some advantages over web apps, like population of fields from the Address Book and a much more secure feel when the user clicks “buy”. Everything is automatic – you do not need to sit and respond to license e-mails or hand-generate keys. It is all handled between the front-end and back-end seamlessly.

A Mac Mini has enough horsepower to run the back-end, but you will need a static IP address and a bit of bandwidth. Will highly recommends a RAID configuration for your disks (hey, it is customer data)

There is no sign-up fee. There is no annual fee. There are no monthly fees. There are no fixed per-transaction fees. The only fee is 5% of the transactions that are fulfilled via the storefront. You are still free to sell your wares on any other site. There are other non-GB fees that are required, but you can read more about Golden % Braeburn on their site. The best part about it (in my opine) is that even if Will decides to disband Golden % Braeburn, you still have the source and can continue to use it (without the cut!). Think about what would happen if Kagi went out of business and it was your only means to sell your app.

The talk was highly interactive and it was great to see so many developers interested in this offering. They had double the usual attendance and folks were not afraid to ask questions and challenge assumptions.

When you are in the Seattle area, I highly recommend popping in on the Xcoders meetings. You can find out more about the group and subscribe to their various calendar and content feeds right on the main page.

If you have questions or experiences with about Golden % Braeburn, drop a note in the comments. I can consolidate them and shoot them Wil’s way for response (or encourage him to respond directly in the comments if he has time). Feel free to drop a note with your experiences with his storefront (if you are a Delicious Monster aficionado) or OS X software storefronts in general (the good, bad and ugly).

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Why iPad 2 Will Lead Consumers Into the Post-PC Era
• The Near-Term Evolution of Social Commerce
• Content Farms: The Players, The Benefits, The Risks

The Text At A Glance

Aaron has a great, teaching-writing style. You definitely get the feel of being in the classroom, learning right from the professor. The preface makes at least two, fairly substantial claims. First, that the nook covers the Objective-C language, Cocoa design patterns and how to use Xcode, Interface Builder and Instruments. And, second, that you will learn 80% of what you need to know to get started programming for the Mac. I have to agree with both claims as you will definitely learn a great deal of the fundamentals of the language and tools and that the book can be used as a reference post-read.

This third edition has been updated to cover Leopard-only technologies (such as garbage collection and Objective-C 2.0) and does a decent job showing where to utilize the new language features and delves into the depths of intricacies of the new memory management facilities in Leopard (and how to code for both Tiger & Leopard). Covering tools like gdb and Instruments is an amazing thing to do, since many programmers are still rely solely on printf or (in the case of Mac programming) NSLog.

The sample applications range from trivial to pretty neat & indicative of real-world Mac programming, error-logic and all. I especially like the challenges in the exercises, many of which have you modify example code, sometimes accompanied by the mantra: “This is hard, and you are not stupid.”

If you are interested at all in programming for OS X or have programmed for the Mac and want to pick up some hints on how code specifically for features in Leopard, Aaron’s books is a must-buy. I’d definitely recommend keeping all of Apple’s updated Objective-C 2.0 information handy as it will fill in the 20% Aaron doesn’t cover and go a bit deeper as well.

The Gory Details

Here is a breakdown of the chapters and what each covers:

• Chapter 1. Cocoa: What Is It?
• Chapter 2. Let’s Get Started
• Chapter 3. Objective-C
• Chapter 4. Memory Management
• Chapter 5. Target/Action
• Chapter 6. Helper Objects
• Chapter 7. Key-Value Coding; Key-Value Observing
• Chapter 8. NSArrayController
• Chapter 9. NSUndoManager
• Chapter 10. Archiving
• Chapter 11. Basic Core Data
• Chapter 12. Nib Files and NSWindowController
• Chapter 13. User Defaults
• Chapter 14. Using Notifications
• Chapter 15. Using Alert Panels
• Chapter 16. Localization
• Chapter 17. Custom Views
• Chapter 18. Images and Mouse Events
• Chapter 19. Keyboard Events
• Chapter 20. Drawing Text with Attributes
• Chapter 21. Pasteboards and Nil-Targeted Actions
• Chapter 22. Categories
• Chapter 23. Drag-and-Drop
• Chapter 24. NSTimer
• Chapter 25. Sheets
• Chapter 26. Creating NSFormatters
• Chapter 27. Printing
• Chapter 28. Web Service
• Chapter 29. View Swapping
• Chapter 30. Core Data Relationships
• Chapter 31. Garbage Collection
• Chapter 32. Core Animation
• Chapter 33. A Simple Cocoa/OpenGL Application
• Chapter 34. NSTask
• Chapter 35. The End

(Choosing to cover topics such as threading is a huge plus and not the normal faire for this type of text)

Full book reference information:

You can find it at Amazon (they even have a Kindle-ready version), Safari Books Online and (most likely) at your favorite local bookstore.

List price is $49.99 USD but you can find it in the low $30′s if you poke around.

If you snagged a copy of the tome, drop a note in the comments with your take on the text.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Is Software the Key to Green Data Centers?

1. The hard drive that had all of your code on it dies suddenly
2. You didn’t have a backup in TimeMachine
3. Files become corrupted
4. You remove some important code, or overwrite it, accidentally – and save over your only copy; and you don’t know how you’ll ever manage to rewrite those thousands of lines of code over again
5. All of the above

This is where Subversion (called “SVN” for short) comes in handy.

What does it do? Well, in addition to storing a backup copy of your files, it is a “version control” system. This means that every time you upload a new/changed copy of something, it’s saved as a new revision of the file, not replacing the existing. All of those revisions are kept, so if you need to “roll back” to a previous version, you only need to tell the “repository” which version you want.

In practice, it’s not quite that simple. Subversion is mostly a console-based, text-only application, which is difficult for the average user. I’m holding out hope that “Versions” (a Mac SVN client) will show up soon, but it’s been in “coming soon” mode for a while. svnX is another Cocoa-based option, but difficult to use.

Fortunately, since version 1.5, Xcode has offered built-in support for Subversion. It wasn’t until more recently that they got the kinks worked out. Sure, you can use SVN for other types of files – images, binaries, and other bits of data, but code is the best use – you can “merge” changes in the text itself between revisions.

One thing that is important to note: you’ll need a “host” for your SVN repository. This can be your local machine (works on any Mac, Linux, or Windows box), but it’s easiest to find a server provider on the web somewhere. That allows for other people to access it (if needed), and it’s a safe, off-site backup. I’m using it to keep multiple computers “synced” with the latest copy of code.

I can recommend VersionShelf as a host; I’ve been using them for a little bit (still in my 30-day trial). There are others out there – if you know of a better one, please note it in the comments.

Once you create a repository, you must upload the project the first time using the console or some other safe SVN client. Xcode doesn’t work for the initial upload. You’ll then need to download a “working copy” from the repository to begin using SVN properly.

How to upload (you’ll need to understand basic Unix terminal commands for this part):

(if you haven’t already, you’ll need to install the SVN client – get it here)

1. Open Terminal from /Applications/Utilities/
2. Type svn import localpath subversionpath -m "Initial import", where localpath is the directory containing your Xcode project that you wish to upload, and the subversionpath is the destination directory of your subversion repository that you set up

It will most likely ask for your password. Once that’s done, you’ll need to re-download the files that you just uploaded, so that they’re set as a “working copy”.

Fortunately, you can do this with Xcode.

1. Open Xcode, and click “Preferences” under the “Xcode menu…
2. Choose the “SCM” tab.
3. Click the addition sign button under the “Repositories” list to create a new entry.
4. Type any name you want in the “Name” field, and type in the information your SVN provider gave you for the URL, user, and password fields. Xcode should be able to fill in the boxes in between, usually.

5. Click OK.
6. If the “Repositories” window doesn’t appear, get it from the “SCM” menu.

7. Choose your new repository from the list. You should see a file browser… file the folder that you just uploaded. Click it, and click the “Checkout” button in the toolbar.
8. It will ask you where to save it. I don’t recommend overwriting the old copy – put it somewhere else for safe keeping.

Once you’ve downloaded the new copy, you will from then on work with it – don’t use your old one. SVN makes some hidden changes to the files to make them work for versioning.

Now when you edit and save files, you’ll see letters on the left side of the “Groups & Files” list in Xcode, marking directories and files. “M” means modifications have been made to your local “working copy” that you must “commit” to the repository. “U” means the repository has been updated, and you’ll need to update your now out-of-date local working copy.

You can use the “Commit” and “Update” commands (when you have files selected in the Groups & Files list) in the “SCM” menu in Xcode to download or upload changes to/from the repository.

For more on Subversion, and how it works, check out the free online book from O’Reily.

I’m exploring automated builds (and exporting those builds to a template DMG automatically), and I’ll see if I can come up with a tutorial once I figure it out.

Related research and analysis from GigaOM Pro:
Subscriber content. Sign up for a free trial.

• Why iPad 2 Will Lead Consumers Into the Post-PC Era
• The Near-Term Evolution of Social Commerce
• Content Farms: The Players, The Benefits, The Risks