Bill Day: Please tell us about yourself and your interest in the Health Graph API.

David Cohen: I am a senior software developer for Isobar North America, focusing mostly on back-end development in the worlds of Java and PHP. I also box on a (very) amateur level and am in the very early contemplative stages of what kind of Health Graph application I could develop to work with that.

After participating in Isobar’s Create 48 NFC Hackathon as part of Team Beer Pants Meeting, I became aware of and interested in working with the Health Graph API through a series of similar hackathon events hosted by Terrible Labs.

BD: Why did you develop your own Java wrapper for accessing the Health Graph API?

DC: In the setting of a series of shorter hackathons – being a few hours at a time rather than a marathon over the course of several days – developing a wrapper in a language that I was already familiar with seemed like a great way to both become familiar with the new API and to provide a tool that would be of use to Java developers who wanted to created Health Graph applications in the future.

BD: Which portions of the Health Graph API does your wrapper support? Do you use all of them in your own application?

DC: The wrapper is currently a work in progress, but the goal is to have it support the entire Health Graph API. I do not currently have my own application built off of the wrapper but I do hope to be able to use it for application development in the near future.

BD: Are there any portions of the Health Graph API that you don’t currently support but plan to in the future?

DC: There are plenty of portions that are still works in progress, but nothing that isn’t currently being worked on in terms of support.

BD: What do you like about the Health Graph? What would you like to see changed?

DC: I love the depth of data potentially represented by the Health Graph. It’s hard to look at API specifications and not have at least a few ideas for a mash-up application come to mind.

The only problem I see is right now is one that most new projects, especially ones with a large scope, suffer from: The documentation could use some improvements. It should call out specific changes when API updates are made.

BD: If you could request any new feature from the Health Graph, what would it be? How would you use it?

DC: Having not really worked on the application development layer yet, my new feature request might not be ground-breakingly exciting but I would love to see an API call added that contained a map of the MIME types with keys that would not change, so that I could dynamically create my MIME type maps for wrapper calls and not have to worry about getting bad requests when the API updates.

BD: Can you share any future plans for your wrapper? What’s coming next that Health Graph developers may be excited about?

DC: Once the wrapper is stable and contains all of the current API features, I plan on writing a sample application that will give developers a good place to start implementing the features contained within the Health Graph and wrapper. After that I may even start working on an application of my own!

BD: Is there anything else we should know about you or your wrapper?

DC: Just that so far it has been a great experience working with the Health Graph and the RunKeeper team. You all have been nothing short of extraordinarily helpful and ready to answer all of my requests and point out when my “bug reports” are real or just me implementing something poorly. So thanks!

(Editor’s note: You can see David and Team Beer Pants Meeting in action at Isobar’s hackathon around 3:16 into the video below.)

Isobar Create 48 NFC Hackathon from Isobar US on Vimeo.

Cross-posted from the Health Graph blog.

Bill Day: Please tell us about yourself and your interest in the Health Graph API.

Kenny Ma: I’m an entrepreneur and software engineer in San Francisco. Prior to my venture in a new health startup, I was a lead engineer at IGN Entertainment where I worked on IGN’s social network for gamers and IGN’s mobile apps. My cofounder and I are working on improving workplace wellness by creating fitness challenges for groups within companies. The Health Graph API provides a great way to track each individual’s progress.

BD: Why did you develop your own Ruby gem for accessing the Health Graph API?

KM: There are quite a few good Ruby gems for the Health Graph API now but there weren’t any when we started.

BD: Which portions of the Health Graph API does your gem support? Do you use all of them in your own application?

KM: The gem currently supports authentication, fitness activities, sleep, weight, profile, and users. We are currently using all of these in our application and will also be adding more API support soon.

BD: Which additional portions of the Health Graph API do you plan to add in the future?

KM: We are planning to add support for strength training activities very soon. Nutrition and background activities are also on our todo list.

BD: What do you like about the Health Graph? What would you like to see changed?

KM: I love the idea of making this data available so that developers like myself can quickly build health applications on top of it. I think end users will benefit tremendously from the innovations that will come out of this. I don’t see a need to change anything at this time. Keep up the good work.

BD: If you could request any new feature from the Health Graph, what would it be? How would you use it?

KM: None. The Health Graph works very well for us and we haven’t had any problems with it for our application.

BD: Can you share any future plans for your gem? What’s coming next that Health Graph developers may be excited about?

KM: There will definitely be more API support and more test coverage. We will be releasing more updates very soon so make sure you watch the repository if you are using the gem.

BD: Is there anything else we should know about you or your gem?

KM: I’m excited to be able to share the gem with the community and any suggestions for improvment are always welcome.

Cross-posted from the Health Graph blog.

Click here to access the page or here to jump straight to the Google Docs spreadsheet. You can subscribe to the spreadsheet’s RSS feed here to receive future updates and additions via your reader of choice.

The spreadsheet is also embedded below (scroll right to see the rest of each listing).

Please contact us via Twitter @healthgraphapi, Facebook, or Google+ if you know of others that should be added. Thanks!

Cross-posted from the Health Graph blog.

Bill Day: Please tell us about yourself and your company.

Mark Kelsey: I am a doctor by profession and an amateur self taught programmer. I have developed a number of web applications and software packages which we use within my medical practice and I now also work for a software company which develops clinical decision support software. Work on my Health Graph app OS RouteMapper is therefore a bit of a sideline at the moment, though with my medical background I have lots of ideas for how the Health Graph API could be used to help people manage their medical conditions.

BD: What’s the “elevator pitch” for why someone should use your app?

MK: OS RouteMapper allows people to view their Runkeeper activities on Ordnance Survey maps within the UK. These maps are world renowned for being very detailed and in particular provide excellent detail off road. They are therefore particularly useful for walkers, cyclists or runners who don’t stick to roads! Outside the UK, the app uses OpenStreetMaps Cycle Maps which in many areas are much more detailed than Google maps, again particularly useful off road.

BD: How did you get started using the Health Graph API?

MK: After using Runkeeper to track my cycling activities, I wanted to view my activities on more detailed maps so I could see where I’d been (I’m often cycling at night along dark tracks!) and plan where else to ride.

Before the Health Graph API was released, I developed a web site that would allow me to upload GPX files to show on an OS Map. When the Health Graph API was released it was a natural development to automatically get the activities off Runkeeper. I was surprised by how many people started using the app when I published it and when I saw that people from other countries were using it I added the support for OpenStreetMaps Cycle Maps. After seeing how easy it was to integrate with the Health Graph API, I have thought of lots of other ideas about how the data could be used in different ways.

BD: How has using the Health Graph benefited you?

MK: At the moment this is just a sideline for me but I think some of the ideas I have may have even greater appeal to lots of people and may become a commercial opportunity.

BD: Which portions of the Health Graph API do you use, and why?

MK: I mainly use the activities feed and in particular the path of each activity is used to plot the route on the map. The street team feed is also used to enable users to view street team members’ activities on the maps.

BD: What do you like about the Health Graph? What would you like to see changed?

MK: It is very easy to integrate with the Health Graph and the documentation is very clear, even for an amateur programmer like me! One addition I would appreciate is the ability to view the user’s saved routes as this is currently not available. I would also like to develop the ability for users to plan routes using my maps and save them back to the Runkeeper / HealthGraph site as a route.

BD: If you could request any crazy new feature from the Health Graph, what would it be? How would you use it?

MK: With my background as a doctor, I would really love to see some integration with clinical systems and devices so that users can see data (e.g. blood glucose measurements, BP readings, Weight readings etc.) that their doctor has on the clinical system, and they can see the effect of their exercise on their medical conditions. This could extend to things like blood glucose monitors so patients can automatically upload data. I think this kind of thing could really help telemedicine develop in the future.

BD: Can you share any future plans for your app? What’s coming next that your users will be excited about? Does the Health Graph play a role in that, and if so, how?

MK: In the immediate future, I am developing a way for users to compare their performance over parts of their routes i.e. split times, so that even if they don’t follow exactly the same route twice, they can compare their performance over the parts of the route that are the same. As stated above I have a number of other ideas that I think would work well with the Health Graph and build on it. I am hoping to develop these.

BD: Is there anything else we should know about you or your application?

MK: You can follow future developments on Twitter at @osroutemapper!

Cross-posted from the Health Graph blog.

Fascinating morning keynotes

Android Open was jam packed with activities including a pre-conference day of workshops and then two days of main conference. Each morning of the regular conference began with a series of five to twenty minute long keynote talks and panels. You can see a complete listing of the speakers for both days in the conference schedule. You can also watch the keynote sessions via the Android Open 2011 Youtube video playlist (click here to access). I would encourage you to watch as many of the keynotes as possible; they contain a lot of interesting and inspirational material to get your Android juices flowing!

O’Reilly founder & CEO Tim O’Reilly (@timoreilly) kicked things off with his Day 1 opening keynote “What Android can learn from Steve Jobs“. Definitely an interesting choice of title for an Android conference! But Jobs’ passing the week before presented O’Reilly with an opportunity to discuss some of the key principles behind Apple’s success, especially the notion espoused by Jobs that a company needs to be “true to its soul”. O’Reilly examined Google’s “soul” at length, suggesting that it needs to never forget its original mission to help connect people to all the world’s information. Key takeaway for Android developers and businesses: Stay true to yourself and your mission while holding Google to its own high ideals, too.

The next keynote that caught my attention was a conversation between conference co-chair Marko Gargenta (@markogargenta) and Robert Stephens (@rstephens), CTO of Best Buy. Stephens is a pretty technical guy, even going so far as to say that Best Buy ought to get rid of their DVD section and replace it with an Arduino section! As you might imagine given the crowd, this was well received.

The thing that really stood out for me as a mobile payments developer, however, was Stephens’ discussion of the many issues with NFC deployment. He said Best Buy may bypass at least some NFC generations completely, going straight to purely cloud-based payments solutions. This joins the rising tide of anti-NFC sentiment and pragmatism that seems to be building, and echoes some of the many things PayPal has said publicly about NFC weaknesses in recent months. Takeaway: Watch major retailers such as Best Buy closely to pick up the beginnings of big shifts in mobile payments.

Day 2 saw a couple more morning keynotes that stood out for me. The first, “Android in Space” by Will Marshall (@wsm1) of NASA, dealt with building very cheap microsatellites based upon Android-based Nexus One smartphones, aka “phonesats“. “Very cheap” in this case means tens of thousands versus millions or billions of US dollars.

Marshall noted that because of the conservative nature of space flight, the CPU in phonesat Nexus Ones will actually be the fastest CPUs onboard a satellite to date when they’re launched into orbit later this year. He also asked the audience some provocative questions such as “What if we could each have personal satellites?” and “What if satellites became a software domain?”. Thing to note: Android software and off the shelf mobile phone hardware can reduce costs in some areas by two or more orders of magnitude versus traditional ways of doing things, and that could change everything in those areas.

You can read more about the phonesat project from this report from O’Reilly correspondent Alex Howard (@digiphile). Among other things, Alex links to an excellent documentary on early phonesat rocket launch testing.

The final keynote that fascinated me was “The African Laptop Killer: Android and the Developing World” by Claire Hunsaker (@chunsaker). Hunsaker discussed the tremendous rise of mobile technology in Kenya and elsewhere and how that technology is revolutionizing lives and economies. Some of the statistics quoted include:

• 99% of Internet access in Kenya is via mobile device.
• Cheap Android phones have dropped Internet access in Kenya from 31% of an average worker’s annual income to about 5%.
• Fully 20% of Kenyan GDP runs through the mobile wallet (predominantly M-PESA).
• According to Hunsaker, “Facebook will have access to most (Kenyan) users before thy can even own a mobile handset themselves” via borrowed/shared mobile handsets.

Please watch Hunsaker’s talk. It may change your perspective on the power and importance of mobile techologies.

Session highlights

There were a lot of great sessions at Android Open. Here are some notes from my favorites:

• Aleksandar Gargenta (yes, Marko is his brother) presented an excellent “Securing Android” session discussing how security is enforced. He made a number of comparisons to Java ME and desktop Linux security, noting that “Anytime something is in RAM, there are ways of recovering it”. I’d recommend spending a little time reading through Aleksandar’s slides (click here).
• Eric Burke (@burke_eric) from Square gave a nice “Beautiful Android” talk. I’d been hoping for a few payments fireworks, but Burke stuck closely to how to build attractive and functional Android apps. Among the things he noted, Android clip paths don’t handle antialiasing. This leads to very ugly interfaces unless you use offscreen bitmaps.
• Nick Farina (@nfarina) spoke about the importance of using WebViews in “From iOS to Android” (also, XCode is painful).
• Sean Byrnes of Flurry knocked it out of the park with his “Android App Engagement by the Numbers” talk! In particular, he called out the importance of releasing early and quickly to your followers, as statistics show that on average, an Android developer loses 38% of their users on the day they install your app, 50% in one week.
• Jesse Vincent (@obra) talked in “Dancing App Stores” about the somewhat suprising fact that new app versions dramatically increase sales, even with minimal changes to the app itself. He also made some good suggestions on secondary and tertiary app markets besides Google’s Android Market; check out his slides for more details.

All in all, the sessions had enough code and technical details while still being able to spark ideas in a wide variety of attendees, some Android programmers, some not.

Additional coverage and news from the conference

Conference organizers made a number of other news and information sources available to attendees. You can search some of the best via these links:

• Read the round-up of news and coverage curated by O’Reilly.
• Access all of the speaker slides provided to the organizers.
• View official conference photos.

One more highly recommended resource: The online show “All About Android” (@androidshow) broadcast live from Android Open at the end of Day 1. The conference co-chairs along with several speakers including Tim O’Reilly make appearances on the show. It’s probably worth your time to watch and get their perspective on the major Android developments flowing out of the conference.

Did it blend?

I found this first ever Android Open to be a great mix of community and technology. It struck the right tone of openness and provided both developer how-to and business oriented material. If you are interested in Android and appreciate a balanced perspective of the entire ecosystem, I would recommend this conference as a good place to tap into all things Android.

Click here to access the full article on X.com.

DEVELOPER EVANGELIST

Can you evangelize products for one of the largest local ad networks? Do you have an infectious enthusiasm for technology and mobile and web development?

CityGrid Media is an online media company that connects mobile and web publishers with local businesses by linking them through CityGrid®, its local content and advertising network. CityGrid Media owns and operates leading local consumer properties including Urbanspoon, Citysearch, and Insider Pages.

More local data and content for all. New local ads for everyone. And better performance all around. And it’s free. Our #1 goal is to see developers of all sizes thrive in local. We help developers give their local audience a better experience and get paid to do it. The CityGrid® network APIs give developers access to premium local content including user reviews, editorial content, merchant messages & more, across 75K neighborhoods nationwide.

We are looking for a Developer Evangelist to be the spokesperson, mediator and translator between the development community and our company; and facilitate the proliferation of our APIs through code tutorials, workshops, blogging, public speaking, training, and social events like MeetUps.

Our ideal evangelist will have experience with:

• hands on development with Java, Ruby, Python or other open source languages
• architecture and implementations utilizing APIs
• open source community through blogging or contributions
• involvement with conferences, MeetUps, and other social web coverage
• experimentation with new development languages, architectures, and tools

Additional qualifications include:

• B.S. in Computer Science (M.S. or Ph.D is highly desired)
• a true passion of innovation and open source technologies
• a willingness to be the “go to person” for a development community
• ability to give technical presentations, manage MeetUp groups and online forums
• 10+ years of software engineering experience + development utilizing Big Data tools
• willingness to travel 20% – 40% of the time

If you can carry the flag for our data products to the development community, we want to hear from you today!

CityGrid Media is an equal opportunity employer.

SENIOR WEB DEVELOPER

The successful candidate will be responsible for developing, testing, enhancing and maintaining Java/J2EE applications. This role will participate in the design, development and test phases of the application development lifecycle. This is a technical role which requires object-oriented programming skills, understanding of J2EE application architecture, XML and Web application security.

Responsibilities include:

• Develop, test, debug and document web based Java/J2EE applications in accordance with system architecture requirements.
• Apply industry standard object-oriented programming best practices and J2EE design patterns.
• Plan, initiate and conduct unit testing of applications as well as facilitate system testing.
• Support and troubleshoot production applications.
• Understand system performance associated with the introduction of new technologies.
• Strong problem solving skills; find solid solutions to complex problems quickly.
• As a part of a project team, share technical and product knowledge with other team members.
• Participate in technology/tools evaluation and software technical proof of concepts.

Qualifications:

• Bachelors Degree in related field preferred, work experience may be substituted.
• Java certification preferred.
• 5+ years experience in a similar role preferably in a mid-size to large corporate environment.
• Experience with Web Content Management Systems (WCMS) a plus.

Skills and knowledge:

• Expert knowledge of Java (J2SE and J2EE), XML, HTML, DHTML, JavaScript, CSS, PL/SQL, and open source projects (Spring, Log4j, AJAX, Subversion, Ibatis, etc.).
• Familiarity with J2EE design patterns, software architecture concepts and web application security.
• Excellent object-oriented programming skills and strong analytical and design skills.
• Strong interpersonal skills.
• Must possess the ability to read and interpret technical specifications, use case scenarios, test cases, and software requirements.
• Knowledge and understanding of relational database design and programming using Oracle 9i.
• Strong written and oral communication skills.

Please tell Nick I sent you if you’re interested.

Bill Day: Please tell us about yourself and your company.

Geoff Pitfield: We’re currently an angel-backed team of two. I’ve been making mobile stuff since the days when that meant doing your own hardware, and have been working on Fleetly since early 2010. I’m a Product Design grad and MBA, but I’d never really coded so I taught myself in order to build Fleetly, which has certainly been interesting. Fleetly’s the first app that lets you check in on your fitness and evaluate your overall Fitness Level, based on all the exercise that you do, from weight training to long distance running. I got started on the app when I couldn’t find anything fun to use that supported the variety of activities I was doing to train for a triathlon.

BD: What’s the “elevator pitch” for why someone should use your app?

GP: It’s a fun, social way to stay motivated about your fitness *and* get meaningful insight into what you’re doing. When it clicks for people, they end up doing things like an extra 20 pushups or running another mile just to pass their friend on the leaderboard. That’s a great thing.

BD: How did you get started using the Health Graph API?

GP: Our users started vigorously and repeatedly demanding RunKeeper integration!

BD: How will using the Health Graph benefit your business?

GP: We think it will both increase our user base and increase retention, because Health Graph integration makes it much easier for people to use – they no longer have to enter their data into multiple applications.

BD: Which portions of the Health Graph API do you use, and why?

GP: We use the Fitness Activity API, because that’s the part that fits in with what we’re doing, as well as being what our users demanded. We might add weight tracking at some point as well.

BD: What do you like about the Health Graph? What would you like to see changed?

GP: It’s fairly easy to use and is comprehensive. It would benefit from better delete tracking, and should also support an identifier for originating source on entries. Otherwise, you run into problems if someone has cross-linked multiple services. For instance, we already integrate with Health Graph partner Withings (@withings). If someone’s linked their Withings account to the Health Graph, there really should be a way to tell that a given weight entry originated as Withings ID XYZ to avoid duplication. (Editor’s note: De-duplication today falls on the app developer.)

BD: If you could request any new feature from the Health Graph, what would it be? How would you use it?

GP: Off the top of my head, I’d rather see continued focus on making the API as robust, useable, and open a platform as possible. I don’t have any blindingly great feature ideas, per se, other than what I mentioned above which I think is really important. A push update service would be nice to reduce the need for polling.

BD: Can you share any future plans for your app? What’s coming next that your users will be excited about? Does the Health Graph play a role in that, and if so, how?

GP: The really cool stuff has to remain secret. We’ll soon be introducing some new types of challenges that we think are going to be great, and very much focused on the same Fitness Activities we’re linking via the Health Graph. Also, we’ve always had our own little API but never done much to promote it, and we’re eager to help anyone who’s interested. The second most requested thing after RunKeeper is an Android app if anyone wants to play!

BD: Is there anything else we should know about you or your application?

GP: We’ve been doing a cool challenge with Lifehacker (click to access), and also have a badly under-promoted startup challenge (click here for startup challenge), both of which might be of interest. And the app’s available at www.fleetly.com/ios, so check it out!

Cross-posted from RunKeeper‘s Health Graph developer blog.

I’m a contributor to an O’Reilly book, “Building eCommerce Applications“, being handed out at the X.commerce Innovate 2011 conference.

The book contains four chapters by yours truly: A three part series on using and building your own PayPal-enabled plugins in WordPress, plus one chapter on the ins and outs of Bitcoin.

In order to get a print copy, you need to be at the conference and stop by the O’Reilly booth.

But no matter where you are, you can download free epub, mobi, and/or PDF copies of the ebook from O’Reilly’s site. Click here to get a copy for yourself.

I’d love to hear any feedback you have on my contributions or other parts of the book. Thanks in advance!

O’Reilly is also live streaming keynotes, interviews, and more from the Android Open conference today and tomorrow in San Francisco.

Watch it here: