The mobile phone is the new computer.  The desktop computer is not going away, but the smartphone market is growing fast.  Phones are being used as computers by more people and for more purposes. Just as we still have supercomputers today but most people use desktop computers everyday, soon desktop computers will be relegated to the specialist and elite professional, and most people will use their mobile phones for their computing needs. 

Already there are more mobile phones than computers connected to the internet.  Smartphones are generally cheaper than computers. With their primary role as communication devices, they are often more useful.  The smartphone of today will be the standard phone a few years from now.  With profits from applications growing, we’ll see continued subsidies of the hardware and operating systems by manufacturers and carriers, keeping new phones cheap or free. 

We’re also seeing a change in how people use computers.  More often applications we use are centered around communications (more commonly termed “workflow”) than the more traditional personal computer task of document creation.  In the business world, we file expense reports, approve decisions, or comment on proposals.  As consumers, we read reviews, send short notes to friends, and share photos.  Email is the killer app of the late 20th century, rather than the word processor or spreadsheet.

I’ve never been a gadget geek and have skirted getting into mobile application development before now.  The actual engineering challenges of working with native code on a device doesn’t scare me, but just didn’t seem worth it.  Developing apps for a phone typically meant that you were working for a carrier, directly or indirectly subjected to the whims of a monstrously large company, and often disconnected from the people actually using the application.  Mobile development also seemed to attract the same style of engineer as game development: interested in the tech for itself, with less interest in the end result, and a feeling that the application is “cool” because it runs on a gadget, independent of its usefulness.  Mobile apps weren’t attractive to me as a developer or someone who might use them.  I always said that I would start using a PDA when they had the resolution and battery life of paper, and the phone was suited for direct communication with another human being via voice.

Last year, I started to notice a change.  App development on an iPhone seemed like a different thing.  Applications ranged from useful to silly. Whether they were expressive or empowering, they were more about the people who they were built for, than about those who they were built by.  I bought an iPhone and wrote a couple of toy apps in ObjectiveC, but more notably, I started using my phone as more than a phone: for email, finding directions, micro-blogging, and even the idle entertainment of web surfing.

The iPhone has revitalized the landscape for mobile application development.  However, with all due respect, the BlackBerry had pioneered the “phone as computer” experience, but its focus on business users and Microsoft compatibility has not drawn mass adoption (despite a large group of avid followers).  What we’re seeing now is that BlackBerry’s cutting edge in the business world is complimented by the iPhone’s consumer appeal.  Further, Palm has reinvented its mobile platform and seeks to bring the best of both with a dynamic consumer experience and more power for the applications.  While the iPhone is growing, Symbian and RIM (BlackBerry) still dominate the market. 

SmartPhone operating systems actively innovate to keep up with advances in hardware and ease development with improved tools and APIs. These innovations are not purely technical.   The iPhone App Store reduced barriers to application development by providing easy access to distribution.  Unsurprisingly, people will develop more apps when there is an accessible market and distribution channel.  Blackberry App World and Windows Marketplace for Mobile are likely to drive the success of existing applications for those operating systems and draw new developers as well. Also OS-independent frameworks, like Rhomobile and PhoneGap, allow developers to reach people on diverse phones with a single codebase.

In a recent article by Gary Kim, Forrester analyst Julie Ask identifies three things as the killer advantages of mobile devices: “immediacy, simplicity, and context.” When those are combined with usefulness, we’re going to start to see a different flavor of software application emerge that will transform the way we use mobile phones. I do believe that referring to the use of software applications as “computing” will become archaic. The age of software as communications medium will have arrived.

Participating in the Berkman Center Ruby on Rails Workshop for Women was like making stone soup. Not to diminish my part as a teacher or the efforts of volunteers in San Francisco who worked to create the curriculum over the past several months, but the Boston area had all the makings of a successful workshop before I arrived.

Liana Leahy (@lleahy) and Mary Tolbert (@mtolbert) are vibrant leaders, skilled organizers, as well as strong technologists. Ruby on Rails developers from all of the Boston area were drawn by a clear need for teachers and mentors. Volunteers generously shared their experience and trouble-shooting skills. Andy Grigorowitz taught the group who had no prior programming experience. Jim Barkley and Dev Purkayastha also volunteered to teach, but I think ended up joining the group of amazing TAs. The facilities at Harvard provided a supportive physical environment with wireless connections, power outlets embedded in the desks and microphones for each student to ask a question and be heard. The physical environment and supportive human presence contributed to a sense of abundance that I feel is a key part of the workshop’s success.

As important as the event itself are the activities which follow. Josh Nichols and others from Boston Ruby warmly welcomed workshop participants into their midst. The Boston Ruby group offers frequent meetings on the 1st, 2nd and 3rd Tuesday of every month, representing a thriving community of developers. Because so many local developers showed up and offered friendly assistance, it means that people from the workshop can attend a Boston Ruby meetup or hack session and maybe they will already know someone there. It is a powerful thing feeling that you are amongst friends.

I was inspired and honored to be a part of this event. It is my hope and expectation that the work will continue through the Open Source Code Crunch and future workshops.

Fabulous sponsors:

Special thanks to

• Desi from DevChix for recruiting sponsors and spreading the word
• Jacob Rothstein and Ilen Zazueta-Hall for last minute work on the handouts
• Sarah Mei for tireless improvements to the install instructions and moral support

In preparing to teach a new class, Ruby on Rails Fundamentals, I felt strongly that I wanted to teach test-driven development (TDD).  Initially my motivation was that I found it hard to learn TDD when I learned Rails.  I found little instructional material on the web and the variety of test frameworks was a bit overwhelming.  As an experienced programmer, I understood the methodology (although I hadn’t practiced it much), but couldn’t find good resources to teach myself the basic syntax.  I found cucumber quite approachable, but struggled with TestUnit and RSpec (which I eventually learned well through pair programming).  I figured that if people didn’t learn TDD in an introductory class, how the heck were they to learn it at all?  Also, the last thing I want is for graduates of my class to have experience building web applications in Ruby on Rails that have no tests.

There were negative reactions from some folks via email and twitter, but I had just as many people encouraging the teaching of TDD, so I decided to move forward with my plan.  Wolfram Arnold is a big proponent of throwing the newbies into the status quo.  We should teach them the real thing, not yesterday’s news, and certainly not teach them practices that we would frown upon.  I reflected on my own TDD experience and realized that one of the benefits of TDD and one of the things that makes it hard is that I really need to understand what my code is doing to test it.  That might sound strange, but it is surprisingly easy to get an intended high-level effect you want without really understanding exactly what your code is doing, especially with Rails.  If you force yourself to write a test, you are creating a detailed contract with yourself.  It is a crystallization of your design that requires an understanding of the code.  I thought that would be really good for the class.  We could write tests that cover some important details that it is easy to gloss over as a newbie.  In this way, TDD would start as a teaching/learning tool, rather than the design tool that it usually is in a typical development process.

Today I met with another TDD teaching proponent, Alex Chafee.  He had twittered that he always teaches testing first, and I was intrigued. I joined his regular Sunday study group as a TA, where I had fun teaching about nested routes, debugging collection_select, and spreading the word about nested attributes.  After the class, a few students stayed late and joined me as I learned from Alex about his approach to teaching, which he calls test-driven teaching (TDT).  He did this intially in teaching java and more recently teaching Ruby.  For homework assignments he would give student tests and then they would write the code to make them pass.  This is one of those ideas that I hadn’t thought of, but as soon as he told me about it, the idea seemed an obvious way to teach.  What beter way to specify an assignment that to provide a test?

What I’d ike to do for the class is to start with TDT and then shift to TDD once the students are familiar enough with the Ruby syntax and the Rails object model.  It is perhaps aggressive for 6 2-hour classes, but with homework assignments between classes and students who are already programmers, it seems like it could fit into the time frame.

My first challenge is to figure out what are the essential Ruby language constructs that people need to know for writing Rails applications, what would be good exercises for learning those skills, and then write the tests that would require that code to be written.  It feels like a little bit ‘o Ruby jeopardy.  Alex has promised to meet with me again to brainstorm and I’ll publish what we come up with, but if you are reading this and you write Rails applications, I would love your feedback on what are the essential Ruby skills for a Rails engineer (plus any Ruby, Rails or TDD teaching tips would be welcome).

I’ll be teaching Ruby on Rails in a hands-on class in SF. In starts quite soon, on 8/25. It will be suitable for anyone who has attended one of the recent workshops or for anyone who is a programmer already but just doesn’t know Ruby or Rails. For folks who need to install a dev environment, there’s an SFRuby Meetup install fest on 8/24.  You can sign up for the class online.  Here’s the course description:

Ruby on Rails Fundamentals
You will learn how to create data-driven web applications with Ruby on Rails. Through test-driven and exploratory development, you will become familiar with ActiveRecord, including associations. You will gain an understanding of the SQL implicitly written through your Ruby code. You will learn about customizing views, view helpers, routes and controller actions. At the end of this class, the “generate scaffold” command will hold no magic. There will be short assignments that you will be expected to accomplish between classes.

• 6 weeks, one 2-hour evening class per week, Tuesdays 8/25 – 9/29, 6:30-8:30pm
• You must bring your own laptop to work on
• Prerequisite: you must have already installed Ruby and Rails and be comfortable using command line tools. You must have some programming experience, but need not know Ruby.

In keeping with the workshop tradition, we’ll figure out childcare if there are folks who want to enroll in the class and need it.  Depending on the number of kids, the JCC has some different options, so we need to see what’s needed before we make specific plans.  So, don’t let worries about childcare keep you from signing up!  I know this question can be just as important for Dads and for Moms these days.

Many thanks to Andrea Heilbronner for organizing the class and Michael Pope for organizing the Install Fest. It is great to be part of a community who sees a need and makes things happen.

A rise in hacker love songs points to a positive sign for women in computing.  What better way to feel like software engineering is hot than to hear about it in a clever, catchy tune?

Coder Girl “feels like my first ‘hello world’… her source is tight… sharper than most chicks you know”

Theory Girl “she doesn’t want to code in C or Perl… because she uses an abstract machine… she knows all of Knuth, volumes 1 through 3.

In Code Monkey, Jonathan Coulton comes out as a coder in love, providing a fun glimpse into the life of a web developer. Here is my all-time favorite performance: