Unfortunately, the building fire alarm went off around 12:30 forcing us out into the cold Connecticut air in a hustle of confusion. Out there we met another couple who lives far above us on the 17th floor. It turns out that there was some sort of fire in the penthouse and everything was resolved by New Haven’s finest. However,  that left us with the problem of trying to catch the elevator up when there were hundreds of humans in the crowd waiting to get lifted. We only live on the 4th floor so it was no problem for us to walk up to our floor but the other couple was left to fend for themselves being too tired (obviously) to climb 17 floors! I told them to come up to the 4th floor with us.

Therefore, I suggested that they try to catch an elevator moving in either direction from the 4th floor. I figured that the volume of people moving up would make the most hotly-saught-after commodity a space on an elevator so I figured that it’d better for them to get two spots on the way down and ride down so they could then ride back up. This sort of made sense to me but I could not forsee one major factor: drunk people coming down at the same time! So this morning, I found a few references to special elevator algorithms.

• Elevator algorithm – actually for disks but interesting
• The elevator algorithm – actually about elevators
• Heuristic algorithm to solve the multi-floor layout problem with the consideration of elevator utilization – paper

Was my gut instinct correct about catching a lift from the 4th floor?

For those who might not know, MapReduce is a novel data-processing system developed by Google for internal usage and described in their publication entitled MapReduce: Simplified Data Processing on Large Clusters. For the enlightened out there, it should be clear that the name and mechanism are derived from Lisp’s map and reduce functions. In any case, though Google’s implementation is proprietary, there have been several implementations based on their paper both written in and geared toward a variety of programming languages. Unfortunately, none of these are available in the Debian repositories. In all fairness, Debian does include CouchDB which uses map and reduce functions for generating views. However, it’s not a solution aimed at sorting and processing huge amounts of data, though it is an interesting and capable piece of software.

So, to try and get things moving, I have filed three Debian RFPs (Request For Package) for a few seperate MapReduce implementations.

• Hadoop – Probably the most well-known of the Free/Open Source implementations. Includes a distributed filesystem (HDFS), scaleable distributed database (HBase) and tools to get you going from start to finish. Hadoop is written in Java though it can interoperate with other languages (Scala, too). It’s a top-level project of the Apache Software Foundation and licensed under the Apache License 2.0 – http://hadoop.apache.org
• Skynet – A MapReduce implementation written in Ruby. It’s designed to be fault-tolerant and distrubuted, just like the big boys. Originally written for use at Geni.com and licensed under the MIT License – http://skynet.rubyforge.org/
• Disco – Though the implementation is itself written in Erlang, thus providing excellent distributed fault-tolerance, Disco jobs can be written in Python. It was developed as an in-house tool for rapid data analysis at Nokia and they seem to be quite keen on it. Disco is licensed under a modified BSD License. Page at http://discoproject.org/ and code at http://github.com/tuulos/disco/tree/master

Ok, there might be a few objections to my choices. Why did I leave out neat projects like GridGain, FileMap and BashReduce? Well, for starters, GridGain is another Java implementation that doesn’t seem (at least to me) to have the same momentum Hadoop does. FileMap and BashReduce, while novel, useful and fascinating, are not designed for use in networked environments and are therefore unsuitable for cluster situations. So then whey not MapSharp? Well, primarily because of all the Debian Mono debates going on right now (Gnome’s fail!) . I’ve done work in C# and it’s got some neat features but cool stuff doesn’t and will not ensure that users are not liable from patent litigation.

Also, it seems like those RFPs have some mistakes, so if anyone figures out how to edit them, let me know so I can clean them up.

The entire piece left me feeling really intrigued by the challenges of effectively integrating technology and education. The paper is very well researched and although I can’t articulate it,  I reached the last page of this paper feeling really good. Maybe it had to do with the enlightened view taken by the authors. Their writing is crisp and their outlook seems appropriately upbeat given the richness of the material and subject matter covered in the paper. The document bursts with elegant and thought-provoking stanzas:

Design based research is a methodology for the study of function. Often referred to as design research or design experiments, it is concerned with the design of learning processes, taking account of the involved complexities, multiple levels and contexts of educational settings. The primary aim is to develop domain-specific theories in order to understand the learning process.

Such succulent gems of insight are plentiful in the opening sections as Mor and Winters set the stage for a comprehensive reflection on the essences of design, science and learning. They are realistic about how “The complexity of classroom situations does not lend itself to the procedures of laboratory research” as they ask “To what extent are we driven by a pure quest for knowledge, and to what extent are we committed to influencing educational practice?”.

The paper continues into a very stimulating overview of design patterns and their application in the many areas of education. Though I have always liked the idea of design patterns in software, I have never been so enthralled by a discussion about the essential elements of design patterns. Also, this is the first time that I’ve heard of design patterns being used as a tool for analysis instead of construction and planning:

An important characteristic of a design pattern is that it has three facets: descriptive, normative, and collaborative. It is an analytic form, used to describe design situations and solutions, a meta-design tool, used to highlight key issues and dictate a valuable method of resolving them, and a communicative tool enabling different communities to discuss design issues and solutions.

The esteemed writers are careful to explain their thought processes without letting their comprehensive coverage become tangential. They expertly work in a mentioning of the political agendas of design pattern construction for city planning and network routing protocols to help illustrate their observations of how values influence design.

This paper is awash in fascinating pointers to further exploration and while I fully intend to follow up on some of their citations, something of immediate interest is a link to a very cool site called the Pedagogical Patterns Project which established a repository of educational design patterns. I need more time to explore but what they have seems to be very cool. It’s clear that I’ll refer back to this paper frequently as I strive to better understand the interactions of education and computing.

Mohan begins with a very logical stance on the dual subjects of technology and education by saying that “Some of the most cost effective and appropriate ways to use computers and modern technologies is to have close contact between the teachers and the taught.”. When I read this and the text before it, I wondered if all I would get would be a concise exposition detailing those business issues in India which dealt with college students. Instead, I got a whirlwind overview of select “reskilling” efforts thought (by Mohan) to be significant in the scope of the paper.

The paper is written in a casual-yet-technical style with a tone and focus that instantly reminded me of Thomas Friedman‘s many commentaries on the Indian tech sector. In fact, some of his more entertaining points might just be a tongue-in-cheek salute to the importance of education in a culture commonly associated with outsourcing:

A mixed approach to valuing staff by developing skills, providing interesting and motivating work while recognizing their individual contribution, alongside benefits and perks, will mean that you are an employer that employees don’t want to leave.

If this paper were any longer than it is, I would advise people to move along and skip it in favor of more detailed works. That being said, the topic was narrowed significantly and as such, could be considered to have an reasonably-appropriate length in addition to it’s generally generally-upbeat discourse. In fact, I actually found myself giggling at some of Mohan’s informalities and clear showings of enthusiasm.

While I favor dynamically-typed languages (like Lisp, Ruby and Python) as a matter of personal preference, I have tremendous respect for statically-typed languages (like C and Java). In my humble opinion, some of the most interesting languages are those which allow one to switch between the paradigms as need or desire dictates. Take for example, Haskell‘s type annotations or Common Lisp’s type specifiers (particularly declare). The former allows one to annotate Haskell function definitions with type information to enforce type constraints while the latter can be used to turn off Lisp’s dynamic typing system when trying to do something special like optimize certain functions.

After I discovered all of this and determined that I think it’s pretty neat but not something I have the time to pursue right now, my interest has been rekindled by a recently delivered presentation entitled Types Considered Harmful. Perhaps it’s also time for me to re-read another famous type-system paper, Java is not type-safe.

Perhaps the most interesting aspect of this paper is it’s writing style. These authors have clearly given the subject a great deal of thought and have not been shy about getting philosophical while expressing their opinions. In fact, these authors have gone out of their way to use their variety of interdisciplinary sources to help illustrate the idea that issues in computer-based learning are never purely technical. One of the first communication models they discuss is the well known psychology concept of the double bind. While the concept isn’t worth explaining here (given the ubiquity of detailed explanations), their relation of the concept to educational evaluation is certainly significant.

Evaluation is also trapped in the double bind. Student and teacher or even the other characters such as colleagues and parents exchange many contradictory stimuli about learning. For example: have critical sense versus accept as truth what is in books, express yourself efficiently versus do not talk, concentrate on homework versus play with friends, etc. These situations are inherent to evaluation in the same sense the double bind is part of communication

The tensions described here are all-too-familiar to students, both past and present. Issues such as the ones mentioned in the paper are very real obstacles that must be overcome in classrooms all over while their complexities are only emphasized further by the still-developing experience of computer-based learning.

…the computer-based learning environment must support and, if possible, amplify the expression and the emergence of contradictory relations. These are essential to the evaluation process, since provocative statements may communicate how teacher and colleagues perceive one’s performance and understanding.

With this in mind, they conclude their discussion by explicitly stating the importance of letting real-world factors influence the design of learning systems. This exceptionally well thought-out piece of technical writing should be required reading for any educator considering the deployment of a computer-based learning system or struggling with the design of an alternative assessment mechanism.

After a brief overview of the proprietary software model, Hepburn devotes a solid page examining the issues surrounding using proprietary software in schools. He cites the cost of doing business with Microsoft (according to the Microsoft School Agreement), as of Winter 2005 with a school of 400 machines, to be US$7200 for the OS alone and US$19,200 for a complete desktop package. Additionally, he notes that, in general, “…using proprietary software requires a high degree of accountability” on account of license compliance issues and other legal liabilities. Alongside the financial downsides, Hepburn makes a very good point when examining “…school’s complicity in exposing students to commercial products and corporate interests”. The idea of a classroom as a corporate marketing machine is rather unappealing.

While it’s not hard to find literature extolling the virtues of F/OSS, Hepburn does a nice job of emphasizing the potential benefits for schools. One particular point that caught my eye was his comment that “Schools can also burn OSS on to a compact disc and give it to staff or students to take home and do what they wish with it”. Granted, projects like OpenDisc have been leveraging the flexibility of F/OSS licenses for some time now, but I have been toying with the idea of using virtual machines as distributable workspaces. Personally, I find the idea of being able to send a student home with their own system saved on a thumb drive very compelling.

After touching briefly on the subject of Linux, Hepburn goes on to discuss some of the neater software packages from the F/OSS world. In particular, OpenOffice.org gets a shout out though I don’t know if I agree with his insinuation that OO.org requires fewer system resources (specifically hardware) than MS Office. Overall, I do agree with his other major points which support the ideas that the F/OSS community is better equipped to respond to change and correct errors. Moreover, I fully support the idea that more diverse exposure to different types of software will lead to an overall greater computing literacy.

With a healthy sprinkling of Lawrence Lessig quotes and shameless support for F/OSS, this paper is definitely worth a read.