Archives

Image credit:  MIT New Media Medicine group at the MIT Media Lab

The New Media Medicine group at the MIT Media Lab suggests a key to solving healthcare problems lies in establishing new kinds of collaboration between patients and practitioners. Traditionally, the relationship has been one of “inequality” where practitioners and medical experts monopolize access to information. This leaves the power of the people and the ability to collaborate untapped. The New Media Medicine group is creating projects that offer innovative user experiences that can drive change. Let’s take a look at two.

Avatars To Assist Patient-Physician Collaboration
One of the most frustrating things when care is needed can be the delays of getting an appointment or someone to talk to. The I’m Listening system uses an avatar to conduct a pre-office visit interview. The avatar-based interview is meant to enhance, not substitute for, the doctor’s own interview of the patient. The avatar can be used to provide, with a sense of immediacy, educational materials, care suggestions and information to better assist the patient in working with the doctor. The information from the interview can help save the doctor time in terms of getting a basic understanding of the patient’s condition.  watch the video

An Open Source Stethoscope
Imagine an inexpensive and easy to use stethoscope that you could use yourself to take readings that could be streamed over the internet to a physician. This is the result of the IDA project, an open source effort to create an inexpensive stethoscope that is not only easy to use but also easy to manufacture all over the world. MIT’s New Media Medicine group points out such instruments could have an impact in developing countries where the physician to patient ratio is 1 to 200,000.  watch the video

These two projects and others at the New Media Medicine group at the MIT Media Lab show how rethinking the role of users and the possibilities of user experience can enable innovative and game-changing technologies and solutions in healthcare.

For more, visit the New Media Medicine group at the MIT Media Lab.

Anybody who has been to our office knows I am an Android fan. My prediction is that the Android platform will end up with a much, much larger install base than iPhone OS. Originally, I felt this way because you can get a Android phone on every carrier for a lower cost than the iPhone – many of them are now free with a contract. This is good enough, but I have a new insight. The Android OS does a great job of directing your attention to highly important information. As such, its easier for new users to pick up and for busy people to use. How can this be? You should argue that the the Android OS so similar to the iPhone OS. You are right. However, it comes down to usability. The majority of people out there won’t explore their device to find information. They just want the phone to do the work for them. If it doesn’t smack them in the head it might as well not exist. Android has two crucial features that make it a helper more than just a smart phone.

This year’s Day of Mobile had a number of interesting tracks, including the ever popular hack-a-thon.

In the hack-a-thon, developers worked alone or in teams to build applications that targeted any one of the mobile platforms (iPhone, Blackberry, Android, Palm, Windows Phone) and presented their applications to the attendees to win prizes.

Our own Mike Laurence, who won the in in the open source category for developing an iPhone application for the Lighthouse issue tracking service. In three hours.

How? By using our recently released Core Resource Framework, a local/remote resource management framework that accelerates the creation of API clients, our soon to be released DynamicCell project, and integrating with the Lighthouse API. Pretty sweet.

I talked to Mike about it afterwards, and here’s what he had to say:

“Three hours is a pretty short time to develop an application, but this was a good chance to test out the Core Resource framework. I’ve been working on the framework itself for the last five months or so; for the hackathon I decided to see if I could actually make a working app in 3 hours. I ended up creating a Lighthouse account (bug tracking website) for the project, and because Lighthouse has a nice API, that’s what I used as my source. I did get an app up and running in 3 hours, which was pretty exciting. It even looked decent, due to the other open source project I announced (DynamicCell.”)

The Core Resources framework is available now, and look for an announcement on the DynamicCell project in the next week or so.

We’re building a fair number of iPhone and iPad applications now, and it’s great so have someone like Mike on the team and contributing back to the community.

We’re currently in the process of interviewing candidates for 1-2 Senior, and 2-3 junior level Rails Developers, and I’m wondering about the skills that are most critical, and how best to identify the best candidates.

My normal interview process flows like this:

1. Quick Phone screen evaluating basic development skills, background, availability, personality
2. Basic coding problem (less than 1hr to complete)
3. Phone call to review coding problem, ‘how would you handle X?’ questions, etc
4. On site interview targeting: Communication, Communication, Communication, (and tech)
5. Final decision

Independent of the language they will be working with, I’ve found decent success with having candidates answer some standard dev questions, solve a basic coding problem, and demonstrate their ability to whiteboard a design.

The problem is that it doesn’t scale. When we’ve opened up positions in the past, either Senior or Junior, there have been so many applications that its hard to contact them all. This leads to a reshuffling of the tasks and matching criteria, in an attempt to identify the ‘best’ matches, and ‘filter out’ the others.  So instead of calling each candidate first, we might simply reply to them with the details of the coding assignment. I’ve seen 40 people send the “I’m an extremely hard worker, very interested in your position and would do anything to join your wonderful company” cover letter and resume, and then get whittled down to only 10 candidates that actually submit the assignment.  (Note to applicants: ‘showing up’ is an important first step!)

I came across an interesting post titled ’11 tips on hiring a rails developer’ which mentioned some ‘filtering’ criteria to identify the best candidates

You can read the full description of each one, but there are a few of these that I wanted to highlight:

1. Don’t use Monster.com or recruitment agencies.
2. Poach Talent from other companies!
   
3. Don’t hire someone that doesn’t know Rails at all.
4. Look for open source contributions.
5. A personal Rails blog is required.
6. A university degree is not important.
7. Be wary of holes in proficiency.
8. Avoid brand-name superstars.
9. Hire perpetually.
10. Have a company Rails blog
11. Special compensation.

So each of these tips is meant as a heuristic or proxy of the true underlying ability. Any time you are making generalizations you are going to miss out on a few exceptions, but hopefully you end up with what you are looking for.

Starting with the most controversial first, (#5) while I like the idea of giving a strong preference to someone that has a rails blog, and loves  Ruby, Rails, and Web Development enough to be opinionated and spend their own time ranting about it, I’m not sure I could make it a filtering criteria. Doesn’t that seem a bit strong?

I feel the same about (#4) Open Source contribution. I think its great if they have it, but I’m not sure I would reject any candidates that haven’t contributed to open source.

While I’ve met many systems administrators that (#6) don’t have a degree, and are very good at their craft, I haven’t really encountered many solid developers that don’t have a degree. That’s not to say they aren’t out there, I’m just saying I’ve never encountered them, and I’m reluctant to use it as a filter. Do you think that there are many strong Rails developers out there without degrees? (I don’t care if they have a CS degree, but I think I prefer that they have some kind of degree)

As it relates to (#1) and (#11), I know for sure that the economics of finding a candidate through your own network and contacts can be less expensive than the recruiter fees (assuming you find a decent candidate and don’t waste a lot of your own time doing it), and if you are able to find someone directly, it frees up cash for such amenities as ‘New Macbook Pro’, ‘RailsConf’, and ‘Fridge full of XXX’.

If I was in charge of everything

I really like what Andy Singleton describes regarding how his team at Assembla is organized and tackles Agile Development, and on the right project, I’d really like take his advice and try this one:

“Don’t interview. Just pay people to join a project, pull a task from the queue, and find out what they can do.”

Anyways,  I’d be very interested in your thoughts regarding what makes for a Solid Rails developer, where you find them, how you keep them, and what you’ve learned.

(Oh, and if you know any passionate Rails Developers in the Chicago area, send them over!)

In this little post, Eric Miraglia of the YUI team points out that Ext JS’ recent change from LGPL to GPL and their inclusion of some YUI code without including the text of the YUI license (BSD) may violate the terms of that license.

I don’t think this is a serious infraction, but it does point out how important good will and amicable relationships are between open source projects that violate one another’s licensing terms all the time.

So Adobe is opening up their Flash platform via the Open Screen Project. Opening up in this case doesn’t mean “Open Source,” more like Open Spec. The spec for SWF has been published since 1998, but it came with onerous licensing restrictions. Adobe has now removed those licensing restrictions and promised to publish more API and protocol details.

Why is Adobe doing this? From their FAQ:

The Open Screen Project is working to enable a consistent runtime environment – taking advantage of Adobe® Flash® Player and, in the future, Adobe AIR™ – that will remove barriers for developers and designers as they publish content and applications across desktops and consumer devices, including phones, mobile Internet devices (MIDs), and set top boxes. The Open Screen Project will address potential technology fragmentation by enabling the runtime technology to be updated seamlessly over the air on mobile devices. The consistent runtime environment will provide optimal performance across a variety of operating systems and devices, and ultimately provide the best experience to consumers.

Some bloggers have speculated that this initiative is aimed at creating a Flash/AIR runtime on the iPhone. Maybe. But right now this thing looks more like an industry cooperative (not necessarily a bad thing) rather than a dynamic open source project.

Competition is the keen cutting edge of business, always shaving away at costs.

– Henry Ford

I’ve been working with Java and Microsoft technologies — .NET most recently — in one form or another for quite some time. My company, now headquartered in Chicago with an office in NYC, was actually founded in Seattle by a group of four developers that had met around developing an Exchange-based bulk email system to replace the sendmail-based ones that Microsoft was using at the time. In that span, despite all of the food fights about total cost of ownership (TCO), etc., I haven’t seen any evidence that Linux, Windows, Mac, Java, .NET, etc., puts you at a significant business advantage one way or the other. Until now.

One thing I overlooked with the release of Ext JS 2.1 is that it is now GPL rather than LGPL. That means that if you build Ext JS 2.1 into your app, it would have to be GPL’s if you planned to distribute it. (See this flame thread on the extjs forum).

Not a problem if you are providing a service, but if you are distributing the application, then you are GPL infected.

If we look at part of the GPL v2:

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

Now IANAL, but if you distribute a stub application with at least 2 UI implementations that can be downloaded and installed separately, you might be OK. Another argument for designing your applications as service providers that can be accessed by multiple different clients. That way you can change UI frameworks as necessary, such as when your current framework changes open source licenses.

Got an Open Source or Free software project? Want some young, eager college developers to give you a boost? Then you should check out the Google Summer of Code. The details:

Over the coming months we’ll be working with open source and free software groups to select hundreds of student projects from thousands of applications. Then, during the summer, we’ll distribute millions of dollars in stipends to the students cranking out the code. Our goal is to increase the world’s supply of open source software while providing young programmers inspiring, meaningful summer jobs.

Since the first Google Summer of Code in 2005, the program has had remarkable success. Last year we connected 900 students with more than 130 open source mentoring groups, including such prominent organizations as Dojo, Python, Samba and Ubuntu. Several past students are still contributing to their projects and many are serving as mentors in this year’s program. Meanwhile, similar programs are springing up all over, including the Finnish Summer Code Program, the GNOME Women’s Summer Outreach Program, the Season of Usability, and game publisher NCSoft’s Winter of Code.

This year’s Google Summer of Code promises to be the most successful we’ve ever held. We’ve extended the program timeline to allow students and mentors to discuss applications before settling in to write them, and we’re continuing last year’s tradition of announcing accepted applicants early to allow students more time to bond with their project communities.

We look forward to applications from organizations and students eager to participate.  Applications for organizations open March 3 and close March 12; for students, applications open March 24 and close March 31.  Coding will run from May 26 through August 18.

Note the appropriate use of the semicolon in the second-to-last sentence. We’re thinking of gettin us one of them thar summer of code students for one of our own Open Source projects: RSH.

Technorati Tags: announcement, google, summer of code

After my enthusiastic support for the open-source Songbird media browser, I recently got the chance to sit down (virtually) with Stephen Lau, Songbird’s developer evangelist. Stephen was full of thorough, informative answers about Songbird’s technical underpinnings, business model, development methodology and roadmap to version 1.0.

Agile Ajax: For software that’s still pretty far from a polished, commercial 1.0 version, Songbird has attracted a devoted following and an active user base. How and why do you think that’s happened?

Stephen Lau: We owe it all to our fans! The users that have adopted Songbird have definitely put up with some growing pains as we get closer to our consumer 1.0 release, but they’ve done so because they see the value in having a completely open platform as a media player. They are the type of users who are early adopters, music geeks, tech geeks, etc. and as near as we can tell, Songbird’s following has grown via word of mouth (blogs, reviews, etc.) from our users.