Saturday, November 30, 2013

Accessing the World Via Cellphone

My mother doesn't have a connection to the Internet. For that matter, she doesn't have a computer; if I ever want to explore the reasons why I'm a closet Luddite, I need look no further. This makes the Thanksgiving holiday a bit challenging: I want to spend the entire week visiting (less traffic, less overall stress), but usually need to work at least a couple of days.

It used to be that there were plenty of neighbors with open wifi, but in the past few years they've either changed providers or learned about security; now everyone in range requires a password. We've tried going to the town library, but that's really not a great place to work (when did librarians switch from shushing patrons to talking loudly amongst themselves?). And we've spent days with family and friends, but it's hard to actually focus on work in that situation.

This year I decided to try something different: bring my Internet with me via a mobile hotspot. I'd used Clear WiMax at a client site for a couple of months, and occasionally tether my cellphone, so thought that it might be a viable solution. After some research I settled on a prepaid 5 gigabyte plan from T-Mobile. Their coverage map indicated an excellent signal at my mother's house (unlike AT&T, where I'm lucky to get one bar on the second floor), there was no long-term commitment, and the price was good ($42.40: $30 for service, $10 for a SIM, and $2.40 for tax). I was also able to use my old (unlocked) Galaxy Nexus as the hotspot: it's limited to 3G, but I didn't think the extra speed of LTE justified the $150 cost of a new device.

Overall, the experiment was a success: I consistently saw download speeds in the 2-4 Mbit/sec range, and was able to browse the web, connect to remote servers via SSH, and participate in video chats without problem. Not quite what I'm used to from my home FiOS service, but better than the ADSL service that I used for ten years.

The major problem that I experienced was that it took a long time to initiate connections. It didn't matter whether I was opening an SSH session or a web page; I'd wait several seconds until the data started flowing. Once the connection was established, data flowed without delay.

Well, almost without delay: when downloading large files, I could see the rate fluctuating, from a high of around 600 kbytes/sec down to a low under 10 kbytes/sec, with occasional stalls. I'm not sure whether that was due to rate limiting on the part of T-Mobile, or competition for the network. At one point I looked at the phone's status screen, and saw the network type repeatedly switching between UMTS, HSDPA, and HSPA+, so the latter seems most likely. But video calls didn't seem affected, other than occasional blurring.

Bottom line: for less than the cost of a tank of gas, I was able to work in my pajamas. Well worth it.

Tuesday, November 12, 2013

What Can You Build in a Day?

I spent this past Sunday morning as a mentor at the Pilot Philly hackathon. It's a 24-hour hackathon for high school students, and going in, I had some trepidation. I envisioned a post-Katrina-esque setting, filled with teenage boys who hadn't slept in 24 hours. I'm also a bit concerned that hackathons foster a culture of “build it fast and who cares what happens next” that isn't compatible with long-term software development.

And I had a commitment for Saturday. But I exchanged a few emails with the organizers, they said they'd take any time I could give, so I arrived at 9 AM on Sunday. While the workspace — with tables jammed together and sleeping bags strewn on the floor — did have a post-apocalypse gestalt, my fears of chaos turned out to be unwarranted: the teams were focused on getting their projects done.

My gender assumptions also turned out to be wrong: while I didn't count, my sense was that at least a quarter of the participants were young women. I know that there are several organizations that focus on breaking down the gender divide in technology. Either they're having an effect, or the “digital generation” views such divides as ancient history.

I was pointed at a team building an app to select random takeout from local restaurants (“when you don't want to make a decision about lunch”). They had reached the point where they were getting data from the third-party service, but were having some trouble extracting the data they needed and formatting it in HTML (“if this was a command-line app we'd be all over it”). They were working in Python, a language that I've used only recreationally, but debugging is something that I can do. We worked through logging, and discussed how to filter the service results. I helped them with HTML, and showed them some of the resources that I use. And in a short time, the app was working.

I say “a short time,” but it was really the entire morning. At one point, while the team was working on details, I sent my wife a message that I'd be home around 1:30 for lunch. Her response: “you mean 2:30, right?” I have to be honest: it's been years since my at-work mornings passed so quickly.

And that is my take-away from this experience. I hope that, via anecdotes and advice, I have made these four kids better programmers. But there's no question that they've reminded me why I got into this field in the first place.

Friday, November 8, 2013

Review: Coursera's "Functional Programming Principles in Scala" by Martin Odersky

I just completed this class as part of my introduction to Scala. For those of you that aren't familiar with Coursera, it is one of a growing number of organizations that provide free online education, taught by professors from well-known universities. These organizations are part of a revolution in education, one that might just change the way we think about post-secondary education. At present, they provide an excellent way to sharpen one's skills.

This was my first Coursera class, and I was impressed by its basic mechanics: the class website, lectures, and assignments. I'm not certain how much of this is attributable to the Coursera team, and how much to Martin Odersky's grad students. I expect the automated grading tools to be the latter, but the general website to be shared between classes. Unfortunately, it appears that you can't look at a class' content without signing up, so I'll have to wait for my next class to make a comparison.

If you're thinking of taking an online class, I caution you not to underestimate the time commitment. This class was advertised as 5-7 hours a week, which doesn't seem like much until you try to fit it into your schedule. I gave over a couple evenings a week for lectures, along with several hours for assignments (usually before work, but occasionally on weekends). Since I got my undergraduate degree in a part-time program, taking two classes a semester in addition a full-time job as a software developer, I didn't think I'd have trouble with the workload. I don't think my lifestyle has changed much in the intervening dozen years, but it was tough to fit this class in.

On to the class. It was seven weeks long, with a couple of hours of lectures each week and a total of six programming assignments (some spanning more than a week). Lectures were broken into segments of 10-30 minutes, focusing on a single topic. However, they weren't simply videos: each lecture had one or more “quizzes” embedded within it, requiring viewer interaction and occasional typing. As a result, you'll need access to the Internet; they aren't something that you can complete on a plane.*

Assignments are packaged as ZIP files containing skeleton source code and an Eclipse project configuration. They can also be built using the sbt build tool, and you need to use this tool to submit them. The source code provides stub methods for the expected implementation and a few minimal unit tests; you are expected to add more tests while completing the assignment. When you submit an assignment, an automated grading tool runs a battery of unit tests and a style check (don't use short-circuit returns!). If you fail any of the unit tests, you'll see the test output but not the test itself; sometimes it's a challenge to figure out what the grader is trying to test.

If you've watched the MIT 6.001 lectures by Abelson and Sussman (aka the SICP lectures), you'll find the Odersky lectures very similar, at least at the beginning (to the point of using many of the same examples). Another point of similarity is that the lectures do not focus on the language itself. For Scheme, that's not so bad: the language is simple. For Scala, you'll want to have an introductory book by your side (for example, Odersky's own Programming in Scala). You'll also want to keep the Scala Standard Library documentation open.

My chief complaint with the course is that it occasionally focused on functional programming to the detriment of good programming, particularly in the assignments. For example, the assignment on Huffman coding used classes as mere data containers, moving all of the logic into standalone functions. Within the context of the assignment — pattern matching — this approach makes sense. However, in the real world I would want to see this implemented with runtime polymorphism: pattern matching in this example is just a glorified switch.**

That said, I highly recommend this class. If you haven't worked with a functional language in the past, you'll find the ideas new and (hopefully) interesting. Even if you have used a functional language, you might find something new: for me, the assignment on “functional sets” (implementing the Set abstraction in pure code) was particularly interesting. And if you're using Scala professionally, I think it's worthwhile to see how the creator of the language approaches problems.

I'll finish with an unexpected insight: Java's generics implementation — and in particular, that parameterized collections don't behave like arrays — was 100% intentional. I'm not sure if you'll be able to watch this lecture, but if you do, you'll see (about 7 minutes in) Odersky explain how Java arrays are bad because they don't allow the compiler to catch certain type errors (the same material is also covered in Programming in Scala). After seeing this, I dug up the JSR-14 spec, and saw that yes, Odersky was one of the people responsible.


* Actually, it may be possible to watch on a plane; a quick session with Firebug indicates that the videos are straightforward HTML5. I haven't looked at the code behind them, so it's possible that the quizzes are implemented in JavaScript.

** My concern is that the assignments distribute logic rather than encapsulate it. A more egregious example, but one less open to explication, is in a later assignment: defining a simple type alias to represent a list of pairs. What the simple alias does not convey, however, is that the list must remain sorted. An object-oriented approach would maintain this invariant in the class; consumers would never see/create an unsorted list. The functional approach, by comparison, requires every function that transforms the list to maintain the invariant.