The Refresh - Day One

Our new set of iPads rolled in today. We have gone with 4th Generation 9.7" iPad, WiFi and, this time, 32GB. What follows is a story about opening boxes.

In the UK, iPads ship in what is basically the same boxes they ship to the Apple Store in: a shipping carton, containing a smaller carton held in a spacer inside which are five iPads in shrink-wrapped retail boxes. Once you get rid of the brown cardboard, you're holding the exact same thing you'd get in a plastic bag from the Apple Store.

Today, we spent the entire day unpacking, breaking down the shipping boxes and getting the devices into their cases.

Sidebar: The Case

There are basically only three kinds of iPad case:

  • The Folio style, which folds into a typing stand similar to the original Apple case.
  • The Kickstand-style, which props the iPad against ridges on the inside front of the case.
  • The Milspec-style, which turns the iPad into a colossal Triganic Ningi of plastic and rubber with all the ergonomics of Batman's toilet seat.

We ended up going with the Belkin Cinema Stripe Folio (Amazon.co.uk, Amazon.com). This case is unusual in that it can be used in either a kickstand mode or as a folio-style typing stand. It also protects the corners and has a very reasonable price.

Taking Inventory

The outer shipping cartons have a sticker and barcode that shows the serial numbers of the five iPads contained within. The first step, therefore, was to capture the serial numbers of all the devices.

My terror at this point in the operation is somehow getting confused between all the devices and ending up not knowing what is where, so I decided to try and keep it manageable.

First, I labelled each of the 22 boxes with a letter A through V. Next I built a simple spreadsheet that had A through V in column A, each spaced out by four intervening cells. Then I used the barcode scanner I bought for the job (Amazon.co.uk) to fill column B with the serials.

So far so good. Now we have groups of five serials in a spreadsheet. For a bigger deployment, your reseller might do this for you but I knew it wouldn't take too long with a scanner in hand.

Unboxing

The next job was to separate everything out without mixing everything up. Each of us took a box and 5 cases and followed this procedure:

  • Unpack the 5 retail boxes and keep the outer shipping container marked with the letter.
  • Unwrap the iPad and put it in its case.
  • Assemble the charger and drop it in a communal box.
  • Drop the cable - still wrapped - in a communal box.
  • Throw out the in-box documentation.
  • Stack the iPad in its case, with the base of the retail box (and, hence, the serial number of the device) back in the shipping container.
  • Stack the retail box-top in the corner for later reassembly.

Now, we have the same 5 iPads, in cases, back in the boxes they came from.

Barcoding

I wanted to put a barcode somewhere on the case of each device for later ease of troubleshooting and lookup if we ever need to. I used my list of codes and an app called Code128Encoder to generate PNG barcode files, then printed one sheet for each box.

Each person then took a box, trimmed the barcodes and passed the device, the serial number barcode and the lower-box to me. I double-checked that the barcode matched the lower-box and then stuck the barcode into the inside of the case.

At this point, every device is in its case and its serial number is stuck into the back of the case with a barcode. We can now discard the shipping boxes entirely.

Turn-on Test

We'll do more testing tomorrow but the last job for today was to simply ensure that each device booted up to the setup assistant. We finished that job and found no DOA devices.

Time Taken

There were five of us working today. Here are some rough timings for the day:

  • 11am: Start opening boxes
  • 1300: All iPads in cases, stacked in their shipping boxes, without barcodes
  • 1300-1345: Lunch
  • 1530: All iPads in cases, with barcodes, sorted into class groups.

So nearly 19 person-hours of work for 110 iPads, working out at about 10 minutes of physical prep per iPad.

IT Does Not Love iPads, and that's a good sign

I'm not normally in the business of going full-Macalope on stupid articles about iPad. After all, there aren't enough hours in the day. Having said that, one particular article has surfaced recently that I hear is being used by at least one local authority IT team in Scotland to justify an LA-wide ban on iPads.

The article by Michelle Fredette in Campus Technology entitled "IT Does Not Love iPads" is so completely off-balance that it's almost funny - until you realise that this kind of weak thinking is actually being taken seriously.

In case you don't make it to the end, here's an executive summary of the complaints:

  • iPads come in boxes
  • App licensing works differently from Microsoft's
  • Apple TV is finicky to deploy at scale
  • You need a whole new network for iPads

The only one of these that actually makes sense is the complaint about a device (AppleTV) that is, in fact, not an iPad.

Anyway, let's get into it.

Is there a higher ed institution in the United States that has not fallen into a swoon over iPads? Some colleges hand them out by the thousands to their entire student body. Others stockpile hundreds for use by faculty, staff, and administrators, or to be checked out of the library by students. On many campuses, iPads have taken over the hearts and minds of everyone.

Let's start by using words like "swoon", "stockpile" and "hearts and minds" to get it clear from the start that all this enthusiasm for iPad is just a mass delusion. Got it?

Everyone, that is, except the IT department.

Given our decades of experience with computers that the IT department love and staff and students hate, I think this can only be considered a good sign.

These sexy tablets might be the apple of faculty and students' eyes, but for IT directors and their staffs, working with iPads in an enterprise network environment is not the stuff of a love affair.

"Sexy". As we know, Real Serious Business can only be done on thick, black computers that people don't like.

To state the problem simply: iPads are designed for consumer use, and as such, they're not set up for large-scale implementations.

I hope someone told LAUSD, who just voted to roll out a $50m, 47-school iPad program. Or McAllen School District, who already have 25,000 units in the field.

They're not even set up for two users to share the same device, much less for sharing over a network.

It's 2013 and the fact that iOS is not a multi-user operating system is still coming as a shock to some people? Also, it turns out the iPad is not a mainframe computer.

For schools making a major investment in iPads on campus, the solution is a combination of new policies and investment in third-party tools for managing the devices.

So there is a solution!

For many other institutions, though, the devices are acquired as needed, or in small batches for specific purposes. In such cases, schools don't necessarily anticipate the additional tools and administration the iOS devices can require--until IT starts bumping up against the limitations of a device that's not easily managed under the school's existing network and resource management infrastructure.

So organisations that don't bother to try and understand what they're doing tend to have a hard time?

The differences between iPad device administration and that of desktop machines or laptops are apparent at all stages of their use, beginning the moment the machines arrive on campus.

You don't even get a minute's reprieve from the awful otherness!

Take, for example, the case of Seton Hill University, a school that has distinguished itself as a forerunner in campus iPad implementations, including being named a second time as an Apple Distinguished Program. In the spring of 2010, the Greensburg, PA, school ordered 1,850 iPads in anticipation of providing them to students for the following fall term. What IT faced was a giant pallet of the devices, individually wrapped or in boxes of 10.

iPads come in boxes! Unlike the Windows PCs that come on tear-off rolls and the Android tablets that come in sheets you can cut to size!

Phil Komarny, Seton Hill's vice president for information technology and CIO, says that his staff had to take each iPad out of the box, update the operating system to the most recent version, image tag it, and put it back in the box to be ready for deployment. "There was nothing else we could do, because this device that they built is completely consumer," Komarny shrugs.

To be serious for a moment, there is something else you could do: get your reseller to do this for you. I'm only leasing 120 iPads and I've had resellers falling over themselves to help us do these chores.

If I was buying 1,850, I'd think this would be the very least a reseller could do for me.

Thomas Hoover, associate vice chancellor and CIO at the University of Tennessee at Chattanooga (UTC), had a similar experience with iPads in a previous role at Pepperdine University (CA), where the IT group handed out several hundred of the devices to students, who turned them back in at the end of the year. "We'd have to manually go through and redo all the iPads," Hoover explains. "It's not like a computer device that you can configure automatically."

So once a year you had to touch every iPad once? Poor dears.

Two years after the first Seton Hill deployment, Apple brought out Apple Configurator, a free download from the Mac App Store that can be used to configure 30 devices at once. But for many campus CIOs, that's too little too late. Those with big iPad implementations tend to rely on mobile-device management (MDM) applications like MobileIron that enable enterprise-level configuration, security, and app management.

And people with big Windows implementations certainly don't have to buy any additional software or services to manage those machines, am I right?

With the iPad, app management is a whole new ballgame for IT departments familiar with licensing and managing applications in bulk for desktop or laptop machines. Rather than selecting from software options hosted on the school's network, faculty and administrators download apps from the App Store, choosing from hundreds of thousands of options. Many schools simply haven't set up a good strategy for purchasing and tracking this new approach to apps. And in lieu of a policy, faculty often download an app using their personal Apple account, and then get the university to reimburse them. (Students are generally not reimbursed for their app downloads, which are considered a "books" expense.)

If you fail to plan, etc.

More than one CIO laments that the ad hoc nature of app downloads can lead to the school purchasing the same app repeatedly, especially if it's a popular one like Numbers. Hoover describes the problem like this: "You reimburse professor A for an app, and then they leave. IT wipes out the iPad because you don't want any sensitive information from the previous person, then yeah, you're going to have to buy that app again for professor B."

Layered model deployment. It exists for a reason.

Some schools have developed workarounds to avoid repeatedly purchasing the same apps. John Haverty, assistant director of user services at Washburn University (KS), says he started to recommend that departments create a generic account for their faculty members to use. "That way, if someone does leave, that software's not going to stay with them--it's going to move on to the next person," he points out.

Again, look at the layered model but you'd probably be cheaper just eating the cost of - what - $30-50 of apps when someone leaves. After all, how often do you turn over staff? The cost of processing their employment paperwork will probably outweigh the cost of the apps they need.

Haverty raises another app-related issue for tax-exempt universities, which is the time-consuming process for getting tax reimbursements on app purchases. "We had to go ahead and make the purchase, then contact someone at Apple to provide the tax ID to get the tax reimbursed." Haverty says that often departments don't bother.

Given that tax systems haven't really caught up with the internet yet, this is hardly a surprise.

Apple has a Volume Purchasing Program for education, released in 2011, which enables educational institutions to buy apps and books in volume at discounts and tax-free. And mobile-device management providers enable schools to manage their Apple volume licensing as part of the broader MDM. Indeed, MDM solutions solve just about all the major challenges presented by Apple devices, including network access, enterprise configuration, and device and app management, as well as security requirements like the ability to remote wipe a lost or stolen device.

OH WAIT - so all this complaining was actually for nothing because solutions to these problems already exist?

Apple, in fact, recommends that enterprises use them. But for schools like Washburn that have acquired devices like iPads and apps in a more informal manner, MDMs represent a time and resource sink that they haven't yet committed to.

If you fail to plan, etc.

But even if your school works with an MDM, there's still the problem of Apple TV working within the campus enterprise. Apple's media receiver is the ideal device for mirroring iPads onto a large screen because the two devices can connect wirelessly. Even better, Apple TV is configured to receive iPad input, so content looks like it should without tweaking.

Yup, Apple TV is great but calling it "the ideal device" and pretending it is essential for an iPad deployment is a great set-up for slamming it in the next paragraph.

Apple does provide a VGA adapter that can connect iPads to televisions and monitors, but, depending on the version of your iPad, you still often have to fiddle to get it to display apps.

The VGA adapter works great - especially with the Lightning port instead of the 30-pin - and I don't know what the "fiddle to get it to display apps" thing is about. I think that's just a lie.

So Apple TV seems like a natural choice for projecting iPad content. And faculty like Apple TV for features like the ability to stream Netflix. But as UTC's Hoover says, "making Apple TV work on the campus network is an abomination on a grand scale."

An abomination on a grand scale, eh?

Hoover may be a bit hyperbolic but he's captured the zeitgeist of IT's exasperation with Apple TV, which is the subject of a July 2012 petition posted on change.org by members of the Educause Wireless Local Area Networking Constituent Group. The petition notes that while Apple has created advertising that promotes the use of Apple TV in college conference rooms, auditoriums, and laboratories, "Apple TV, AirPlay, and Bonjour technologies make it very difficult to support these scenarios on our standards-based enterprise networks."

There's no doubt Apple TV and Bonjour can be finicky at large scale - this definitely needs some work - but I guess my question is what's so wrong with using the VGA adapter if AppleTV is simply impossible.

Issues with AppleTV are tangential to whether or not you should deploy iPad and are absolutely bogus as a justification for banning iPad from your school.

To set up Apple TV, says Jeff Kell, a member of UTC's network services, "you have to enable wireless multicast/broadcast traffic. Such traffic is sent out over every access point on campus, tying up airtime." This means that in an "enterprise setting, every access point will get a copy of every device's advertisements or discoveries in the entire enterprise." Not only is this a huge waste of airtime and bandwidth, Kell says, but it is "a disaster incident waiting to happen, such as some dorm kid streaming porn onto a classroom projector."

I might be old fashioned but I think of "disaster incidents" as being a bit more serious than this. Regardless, anyone who has actually deployed an AppleTV will know that you can turn on an on-screen code that any user must enter on their device to gain access to the Apple TV. For exactly this reason.

Also: don't these massive enterprises have VLANs?

In a blog post, Matthew Libera, performing arts technology consultant at the University of North Carolina at Greensboro, described the steps he took to use Apple TV in his classroom, which included creating his own network and sacrificing access to the internet on his iPad. While it was doable, Libera wrote, "there is no way in heck that I'll be able to convince any of my faculty here that this is a worthwhile undertaking."

Correct. If you have to do this, just get a VGA adapter and get on with your job. This is still nothing to do with iPad per se.

Indeed, many schools just forbid the use of Apple TV on campus. Or they turn to companies like Aruba Networks, which offers a solution for managing Apple TV and other Bonjour protocol-reliant devices in a university enterprise network. But again, this takes an investment in a third-party toolset that's generally attractive only for institutions that are all-in when it comes to iOS devices.

Banning Apple TV isn't actually that unreasonable in its current form. Still nothing to do with iPad.

All-in schools like Seton Hill say that that its iPad program would have been impossible without a major investment in a state-of-the-art network, which included replacing wiring for full campus coverage and upgrading both the wired and wireless networks. The latter, which provides campuswide 802.11n technology, was essential to support the demands of an iPad-oriented university population.

Dunno. I'd say campus-wide WiFi is essential to support the demands of any population of people born after about 1955, regardless of the computer they're using.

With the help of Enterasys network solutions, Seton Hill also revised its approach to managing the network. Now, the school handles network traffic on three virtual LANs: one for iOS devices, one for Mac OS X traffic, and a third for Windows and guest traffic. This approach streamlines network management, but also enables IT to manage network traffic at a more granular level.

OH WAIT - so there actually is a solution to these problems? I'm starting to notice a pattern in this article.

Lynn University (FL) is another iPad-committed campus that will roll out an iPad mini program to all freshman and transfer students this fall. It was able to create a robust campus network as a windfall from hosting one of the presidential debates last October. While the school had to pick up the tab for the new network, it got good deals on some of the technology from participating companies.

Note the subtle - and untrue - inference that you have to buy a new network to support an iPad program.

According to Lynn's CIO, Chris Boniforti, the school had to provide a completely new network environment for up to 6,000 media personnel attending the debate, and it had to be totally isolated from the university's network. Lynn essentially created a whole new network, roughly the size of its existing network, with the understanding that the school would bring it in to replace its aging network once the debate was over. The school estimates that process would otherwise have taken several years and pushed back its iPad mini initiative.

So Lynn got a new network faster because they hosted a presidential debate. Not clear how this is related to iPads.

For schools like Lynn and Seton Hill that have invested heavily in what Boniforti calls the Apple ecosystem, there seem to be fewer hiccups in using enterprisewide iPads. But IT directors who want to incorporate iOS products into their campus ecosystem without making such full-scale investments say they would like a little more support from Apple.

Let's be clear: what the author means here by investing heavily in the "Apple ecosystem" is actually "taking the time to understand how these devices work".

As one Educause wireless LAN constituent mused on the group's listserv: "This is where I daydream about the likes of several Apple engineers reading this list, thinking 'Gee, maybe we should consider how to make our toys work in the actual enterprise.'"

Aaaaannd there's the "toys" canard. It's amazing to me that the FAA approved American Airlines pilots to fly with toys in the cockpit.

So this article boils down to four actual complaints:

  • iPads come in boxes
  • You don't buy apps like you bought them from Microsoft
  • Apple TV is tricky to manage at scale
  • You need to buy a whole new network for your iPad program

The first complaint is just utterly bizarre. The second is true but, as the author actually points out, there are multiple existing solutions. The third complaint is the one that's actually true. Unfortunately, it's just nothing to do with iPad. The last is just false.

The entire article follows the pattern of building up small issues (and non-issues) to be insurmountable obstacles, then quietly admitting that a solution actually exists.

Using articles like this one to justify iPad bans is pathetic and embarrassing.

The Refresh: The Device

In the last piece, I explained my thinking on the platform we're choosing for our refresh. We're sticking with iOS, not just because we're already on iOS but because I don't see compelling reasons to switch to any other platform.

A few people got in touch to ask why I hadn't considered Chromebooks in my analysis. There are a few reasons. I know there are several "Chromebooks" available but the one most people are talking about is the Samsung Series 3. From a hardware point of view, I was surprised that the Series 3 only claims 6.3 hours of battery life. That's pretty poor for an ARM-based device. Heck, I can get better than that from my Core i7-based MacBook Air. Long battery life is not something to be sniffed at - it's genuinely transformational in the classroom.

I also think the laptop form factor is limiting compared to a tablet. I don't disagree that a laptop can be a very strong form factor for document production but the laptop still generally requires a surface to work on, is difficult to use standing and lacks functionality as an integrated media capture device (i.e. shoot video on the device then edit it).

I'm also not totally convinced about ChromeOS. We use Google Apps, so actually adopting Chromebooks wouldn't be particularly hard for us. I just struggle to conceive how we would do the range of things we want to do with computers using only web apps. If your main uses are office-type applications, the web and email, I'm sure the Chromebook does a pretty good job. Right now, I think I'd need to see the platform mature significantly and reach into areas like video editing, audio editing, rich art tools and so on.

So, with that out of the way, let's talk iPads. The one question I got after the last piece that beat out the Chromebook question was why I had not written about iPad vs iPad mini. The reason I didn't include that discussion in the last piece is actually interesting in itself: last time, I was writing about platforms. The iPad and the iPad mini are not two distinct platforms to be considered separately. They are two embodiments of one platform and should not be considered separately from one another.

Of course, they are different devices and they are not direct substitutes for each other. Each does a different job, and that's what I want to consider now.

We have learned over the past couple of years that, in school, an iPad can handle everything we've thrown at it. As a result, our school now looks significantly different to most other schools that have "a few iPads" scattered around. We don't have a computer suite any more. We don't have fleets of desktops or laptops to fall back on if the iPad can't handle the task - mainly because it's impossible to justify the cost of fixed infrastructure for such rare occasions.

So, where does the iPad mini fit in? I look at this from the point of view of the job we are hiring these devices to do. We are buying them to be a pupil's only computer for three years. Where does that lead us?

For some time now, I have used the following framework to think about 7"-class tablets:

A 7" tablet makes a great adjunct to a computer; a 10" tablet can replace it.

I first wrote that about the Google Nexus 7 and, having used an iPad mini exclusively since release day, I'm fairly happy to say the same applies to the iPad mini. My experience has been that I use the mini as much as I ever used my 3rd-generation iPad - and I take it with me to more places - but I've also noticed that my laptop has become more important to me.

Two years ago, the iPad mini wasn't practical. Today it is. Why? The cloud got good. Let me explain: in 2010, the options for fluidly moving between a laptop and an iPad on one task were pretty limited. In fact, it was initially near-impossible. Today, this is much, much easier. iCloud is working well and applications like Evernote are increasingly powerful on iOS. Two years ago, iCloud didn't exist and complex applications like Evernote and the iWork suite were not close to parity with their desktop counterparts.

If I had the budget to provide two computers to each pupil, those two devices would unquestionably be a MacBook Air and an iPad mini. Unfortunately I don't, and there's no way I could persuade people to give up their iPads, so we're going with the device we know can handle everything: the full-size iPad.

Another consideration is the internals of the iPad mini. Last year, the A5 architecture looked like it was history. It had a good run in the iPad 2, which is still on sale, but clearly the future looked A6-based. The iPad mini, being essentially an iPad 2 in a smaller case, changes that. The A5 architecture is going to be a major part of the iOS landscape for the foreseeable future.

That said, it wasn't the A6 processor or the 1GB RAM specification or even the retina display that led me to decide on the 4th-generation iPad. Basically, it's about buying the newest and most capable technology we can get. We're signing a three year lease on these devices and, given how fast the mobile world is moving, I feel we need to at least start our leases on the leading edge of technology. To start with older specifications and hardware - even if that device is brand new - is something I'm wary of. We have no roadmap for how things are going to develop so I intend to equip our kids with the best kit we can put our hands on today.

Teaching Programming on iOS

I have been working for some time on a plan to move my programming classes off Macs and onto iPads. It's finally happening this year. A few people have asked me to write this up, so here goes.

As everyone knows, there are no fully-fledged software development environments for iOS. The closest is a game programming environment called Codea which, while good, doesn't easily map to the kinds of things we currently teach in exam-level Computing courses.

A few years ago, I used to teach using RealBasic on OS X. RealBasic is a fairly standard clone of VisualBasic, the language and IDE that (I guess) most Computing courses are taught with. I hated it. I hated it because the evident link between the code you wrote and the way it executes is quite obscure. I spent as much time explaining where you should type in the code as I did explaining the actual code itself.

Two years ago, I decided to change things. I switched to teaching in Ruby and I switched to using a text editor (TextWrangler) and Terminal. The simplicity is glorious! A simple link between code and result, and no magic glue in-between. I fully appreciate that libraries, frameworks and runtime support are all essential to scale software development up to real-world dimensions but that's not the game I'm playing.

Enter iPad

One of the astonishing results of our iPad 1:1 deployment has been the dramatic decline in the use of the Mac. Within less than two years, I am the only teacher still using the Mac on a regular basis. This was never part of the plan and I didn't expect that it would happen so soon. I thought it might happen eventually - perhaps in 3-4 years, certainly after one more refresh of our Mac setup.

Today, it quite seriously looks like we won't buy more than a handful of Macs again. We’re not cutting our teaching to fit what the iPad can do either - we have never done more with ICT, with better outcomes and deeper learning than we are doing now with iPads in everyone's hands.

Taking Programming Mobile (and Virtual)

So, how do we take Ruby programming mobile? Turns out, it's not so hard (assuming you understand AWS cloud computing infrastructure, IP addressing, SSH configuration and Linux sysadmin, naturally).

The basic idea is that we are going to set up an Amazon EC2 instance, SSH into it and edit and execute our code over there. There are several really nice SSH clients for iOS. My personal favourite is Prompt by Panic, but the idea is the same regardless of the client.

AWS Basics

In case you're not all that familiar with virtualised cloud computing, here's a basic run-down.

Amazon EC2 allows you to spin up a virtual Linux or Windows sever running on Amazon's computing infrastructure. You can start and stop an instance as you need it, and you only pay for the time the instance is running. Instances can run in one of several geographic areas and prices vary slightly from region to region. For my deployment, I used the EU (Ireland) region because we are going to be working interactively and want the lowest latency possible.

The per-hour prices vary by the capability of the virtual machine but, for our purposes, we don't need massive power. The per-hour costs for the smaller instances are incredibly low. An on-demand "Micro" instance costs $0.02/hour. Two cents per hour. So you fire up one of these EC2 instances in August and shut it down the next June, you're going to pay about £80. If you only run it during the school day, it's about £20 per year.

Given that we're deploying iPad anyway for all the other parts of the school, you can see how provisioning a lab just for a programming class isn't an easy conversation to have. By my calculations, my subject now costs the school £10.80 per pupil per year to run. If I had to keep buying Macs just for Computing, the per-head cost would be over £160/year.

Benefits

I'm a huge fan of strategic outsourcing. We are rapidly moving towards a situation at Cedars where we will have essentially no infrastructure in the school except for WiFi (and possibly not even that). This is deliberate: I am the only technician, systems administrator and network manager in the school. I simply don't have time to deal with deploying and looking after servers on the premises. Neither do I want to. I would much rather spend my expensive and valuable time working on things educational rather than things technical.

In order to run my class with computing resources on-site, I would have to manage a suite of laptops or desktop computers, with some kind of file server and directory infrastructure. Alternatively, I can pay Amazon a penny an hour and I don't have to care about hardware at all.

The benefits go beyond the infrastructure and finance, though. It's never been possible for me to set actual programming homework before because few families have development tools installed on their home computers. Now, though, because I know the device that's gone home and I know that the server environment is available from anywhere, I can start to set programming exercises to do at home.

Workflow

The basic programming workflow for the student looks like this: we use Prompt to connect to the server over SSH and execute the Ruby code over there. Up to now, I've been having the students edit their code using the nano text editor over a second SSH connection as it's relatively approachable for new users of command-line editors.

After some more investigation and help from Twitter pals, I realised that both Textastic (which we've used before for teaching HTML editing) and Diet Coda can edit a file and save it back to an SFTP server relatively transparently. There are advantages and disadvantages to both: Textastic is a far better Ruby editor, but Diet Coda has both editor and terminal integrated in the one app. I'm probably going to go with a combination of Textastic and Prompt for now, since we've already deployed both of those apps.

I think that programming is going to be that one special case where a hardware keyboard on an iPad is really important for two reasons: firstly, several common programming symbols are only accessible through the 'mathematical' keyboard on iOS. To type a "<" symbol, for example, you have to hit the '.?123' key, then the '#+=' key and then type the symbol. Prompt allows four customisable soft keys above the keyboard but there are often more required in programming. Textastic does have a special 'symbols bar' that allows quick access to many symbols, so it will be interesting to see if clever UI design can mitigate this problem.

The second reason for using an external keyboard is to recover even more screen space on the device. Programming using the software keyboard is possible in a pinch - great for doing something quick on the go - but you want as much screen space as possible for code.

The Evolution of iOS

I'll let you know how this goes, but I think this is a fascinating step in the evolution of the use of iOS in education. We're starting to solve some of the harder parts of the curriculum. Computer programming was one thing that people said the iPad would "never" be suitable for. Certainly, a lab of 27" iMacs would be preferable but the simple truth is that Computing Studies is not a sufficiently important part of the curriculum that the requirements of that subject can dominate the whole-school approach to IT. It's iOS's world; we just live in it.

In a sense, yes, I'm cheating in that I'm not actually programming on the iPad itself but so what? The entire point of mobile devices is that a good proportion of their power comes from being always connected to the Internet. You wouldn't say that you can't search the web with an iPad just because you can't store and search Google's index database on the device.

The idea of not owning infrastructure is really interesting and important to me. I want to stay as agile as possible with our technology and buying only what I need when I need it is an important part of this.