Skip to content

Notes from the week of 2011-11-13

Developer Evangelist position

Jason Elkin of CityGrid Media is looking for a Developer Evangelist. If you’re interested, drop him an email (be sure to mention I sent you, please).

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 position

Passing this along for Nick Berra at Inceed. Nick has a client needing two senior Java developers for short term contract-to-hire positions.

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.

IronApp: Connecting triathletes via the Health Graph and Facebook

This week we turn our Health Graph partner profile gaze upon IronApp (@ironapp), the “Home for Triathletes on Facebook”. Learn how founder Tyson Miller (@tysonmiller) enriches IronApp’s community of triathletes using the Health Graph (@healthgraphapi).

Bill Day: Please tell us about yourself and IronApp.

Tyson Miller: Being an Ironman triathlete and a web entrepreneur for many years, I always wondered why there weren’t any real social networks for triathletes, particularly focusing on the half and iron distances. It’s because of this that we built IronApp over the past year. We launched in December 2010 with a pretty simple app and have grown to around 50,000 athletes over the past year.

BD: Why would someone use IronApp?

TM: IronApp enables triathletes to keep a race portfolio and see which people on Facebook are doing these races. This hasn’t been done on Facebook before. In addition to this, athletes can also train with their Facebook friends and see which friend is training the most. Lastly, we have groups for each race on our app and athletes doing the same races can easily share information within these groups.

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

TM: I have been using RunKeeper for quite a while and I think it’s a great product. I always knew that within RunKeeper’s large user-base there were probably a lot of triathletes that would love to interact with other triathletes registered for the same races. Our users were also looking for the perfect tool to track their training while still using our app. When the Health Graph API was launched we knew that it would be great for us.

BD: How has using the Health Graph benefited your business?

TM: In addition to increasing the value of our offering, the Health Graph has gotten our app a large amount of exposure. This exposure has been invaluable to us.

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

TM: Currently we are pulling training data from the API and tying it to our athletes’ upcoming triathlons. This enables users signed up for the same races to see each other’s training and how it’s progressing. This is very helpful for our athletes, particularly when training for long Ironman races.

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

TM: So far everything has been great…off the top of my head there is nothing else that we would need!

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

TM: We are really interested in getting real-time location data and seeing what can be done with done with that. I think it would be great if some of our triathletes could be notified if another IronApp-using triathlete that was participating in the same race was nearby.

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?

TM: We are currently coming up with a game plan for the future and we definitely see the Health Graph as a part of that. Training sessions and training data will be further integrated into IronApp and for that we will continue to utilize the Health Graph API. Spatial data might also have a place in our app in the future!

BD: Is there anything else we should know about you or your application?
TM: Our mission is to provide the best app for triathletes online and we are going to continue to work very hard to fulfill that mission. We look forward to continuing to work alongside RunKeeper with the Health Graph API.

Cross-posted from the Health Graph blog.

Health Graph tip: Authorization removal callbacks

This deauthorization callback how-to is the first of an intermittent series of tips-and-tricks posts. Note that this post was updated to reflect more liberal API Policies in May 2012.

The Health Graph now supports callback URLs for removal of user authorizations. You should specify your callback URL when you register your application in the Partner portal.

Here’s how it works: Whenever a user permanently disconnects your application from their RunKeeper account and they have not authorized you to retain their Health Graph data after that disconnection, the system will send an HTTP POST to the callback URL (in application/json format) with a single parameter, “access_token“, that contains the now-invalid token. The request from the Health Graph system will look like this:


POST callback_url HTTP/1.1
Host: callback_host
Content-Type: application/json
Content-Length: nnn

{"access_token":"some_token"}

where callback_url is the URL supplied during registration, callback_host is the host portion of callback_url, nnn is the length of the request body, and some_token is the revoked token.

Please refer to the Health Graph Registration and Authorization documentation for more.

Additional notes: If you request data retention capabilities, you are required to honor the user’s decision as to whether to authorize your retention or not at disconnection time. In that case, you must implement this callback such that if the Health Graph system calls you using it, you delete the given user’s Health Graph originated data. Note that this callback is patterned after a similar callback in Facebook’s OAuth deauthorization implementation.

Questions? Please post them to the callback discussion on the Health Graph group.

Cross-posted from the Health Graph blog.

Innovate 2011 Highlights

I was recently privileged to attend both the O’Reilly Android Open and X.commerce Innovate conferences back-to-back in San Francisco. Both were mind and network expanding events, and I’d highly recommend either to developers and business colleagues considering attending next year.

I hope to write more about my key takeaways from Android Open at some point in the future. For this article, let’s focus on Innovate.

So much transpired in a few short days that it would be impossible to capture everything in one short article. I’ll do my best to give you the overall flavor and major highlights, then I’ll dive a bit deeper to discuss some of the particular technical “breakout” sessions I attended.

Ready? Let’s go!

Keynotes and major announcements

The conference began each morning with a series of general session keynotes. You can access the conference schedule to see a full list of speakers, or better still, watch the keynotes (as well as breakout sessions) from the Innovate 2011 video site (click here to access).

Watch the Day 1 keynotes for yourself below (click here if the embed doesn’t work below):

Naveed Anwar, head of X.commerce community, discussed many of the key Day 1 developments in his blog post here. Some of the big ticket items for developers and merchants included:

  • Launch of the “X.commerce Fabric“, a message-broker based system allowing developers to integrate and use various commerce capabilities. The Fabric ties together various components from eBay, PayPal, Magento, and other eBay companies with capabilities built by third parties, large and small. Much more on this to come.
  • PayPal debuted “PayPal Access“, a new online “commerce identity” comparable to social identity, but for making commerce transactions faster and easier for the consumer. Read more about PayPal Access from the Janrain blog; I’ll also have much more to say about PayPal Access in coming months.
  • Magento launched much tighter integration with eBay, allowing merchants to push products from Magento into eBay with just a few short clicks. You can read a third party take on the many and central Magento-related announcements via AuctionBytes (click here).
  • Facebook announced Open Graph integration with Magento and GSI Commerce enabling, among other things, “Want” and “Own” buttons analogous to the already ubiquitous “Like” button. You can read much more about the eBay-Facebook partnership in this ZDNet article.

With the major announcements out of the way, the Day 1 afternoon and Day 2 morning keynotes could focus on inspirational higher ordered bits. These sessions were great motivation for attendees to take advantage of all of the technical tools at their disposal to make the world a better place. Whether by building corporate giving into their fundamental commercial business model, or by thinking about the effects of the current recession and the innovation that could get us out of it, or by imbuing everything we do with thoughtful design, these sessions were all meant to light the creative spark.

I particularly enjoyed seeing Steven Cooper (@developersteve), whom I featured in an interview article for the X.com site last year, receive a community award at the beginning of the day 2 morning keynotes. You can watch the awards presentation and all of the Day 2 keynotes here:

If the embed fails to load, you can alternatively click here for the Day 2 morning general session.

Other things I found striking during the second morning’s general session:

  • Marshal Cohen spoke at length about the current recession and what might need doing, especially in the United States, to innovate our way out of it. One item in particular stuck with me: He pointed out that while the current recession is not the longest in US history (yet), it is the deepest by job losses. I have to agree with his conclusion that a fundamental shift is underway and many of the lost jobs aren’t coming back, so it’s more important than ever to focus on new commerce opportunities. Build your business to take advantage of inevitable innovations and the sky’s the limit.
  • X.commerce developer evangelist Praveen Alavilli (@ppalavilli) showed some live X.commerce code in front of thousands. Always a gutsy move! Access his demo code yourself from GitHub here. By the way, Praveen has written a great blog post about getting started with the Fabric since Innovate completed; click here to check it out.
  • Hip-hop artist Chamillionaire (@chamillionaire) stole the show discussing how he used community and tech skills to build his fan base from the streets of Houston to the Grammys and beyond. What an amazing innovator! I’d highly recommend watching at least his portion of the day 2 keynote; prepare to be impressed and inspired.

I could write several more articles about the various keynote speakers and their stories. Instead, I’ll encourage you again to watch the videos for yourself.

Partner pavilion and a free O’Reilly book for you

There was a wide range of X.commerce partners showing their wares in the Partner Pavilion during and in between sessions. Somtimes I wondered just how they were packing so many thousands of attendees in such a small space! (The secret, of course, was lots of free coffee, snacks, and soda.)

Here’s a shot I took the first day of the X.commerce booth to give you a feel for the foot traffic:

One other cool thing going on in the Partner Pavilion, in my not so humble opinion, was that O’Reilly Media was giving away printed copies of the new book “Building eCommerce Applications”. This book is a collection of some of the most interesting and varied articles written by contributors to the X.commerce DevZone.

Even if you weren’t able to attend the conference, you can still download a free e-book copy from O’Reilly (click here to get your copy).

And yes, yours truly does have four articles included in the book, so I am a bit biased. Still, you can’t beat free, right?

Session highlights

I attended a number of interesting sessions at the conference. Rather than try to list them all, I thought I’d focus on the key points from the most interesting and useful for me.

  • Two related sessions, “Introducing the X.commerce platform” and “From Code to Capability“, showed developers how to get started with the dive deep into the new X.commerce Fabric. I’d highly recommend clicking on the session titles and watching the sessions to get up to speed asap. You should also download the X.commerce Developer Package and the X.commerce Innovate demo code so you can try it out for yourself. Fabric will be a very important piece of the commerce development puzzle in the months to come.
  • We all know mobile commerce is a BIG opportunity, right? What you might or might not know is how to take advantage of the various social, local, and mobile development strategies to capitalize upon it. “Commerce goes SoLoMo: Social, Local, Mobile” discusses what’s possible, focusing on Milo and Where.com (both eBay companies) in particular. I’d also recommend watching the “Mobile face-off: HTML5 vs. native apps vs. mobile platforms” panel to get a grip on the realities of native, HTML, and hybrid mobile development. I enjoyed both sessions and took away the point that we can do almost anything with today’s mobile technologies (boy have we come a long way since WAP and J2ME!).

Things to watch in the coming year

In summary, Innovate was crammed full of technologies to watch and good information on getting started with them. I’d recommend trying out Fabric and Access as soon as possible and paying attention to both as they roll out in the months ahead. There are also some very nice Magento and Facebook commerce opportunities coming; pay attention, and profit!

I’d love to hear your thoughts on the conference, the news coming out of it, and the new commerce possibilities available as a result of those announcements. Please leave a comment to let me know what you think. And happy commerce hacking!

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

Health Graph on Google+ and new partner logos

Cross-posted from the Health Graph blog.

I’m excited to announce our new Health Graph Google+ page!

We always welcome your comments on our blog and via our Health Graph discussion group, Twitter @healthgraphapi, and Health Graph Facebook page. But if you spend time in G+, we’d love to share and talk with you there, too!

Please circle our page to join in the conversation about all things health and fitness for developers.

Another change: We’re rolling out a new Health Graph icon and logo across all of our sites and accounts (see the G+ screenshot above for example). We’d love to hear your feedback on them. And if you’re a developer who has built (or is building) an app on the Health Graph API, we’d like to provide you with updated logos for use on your landing page.

Please contact us and we’ll get a suitable copy of the logo to you asap.

Notes from the week of 2011-11-06

Corporate wellness, meet Limeade and the Health Graph

I’m very pleased to continue our series of Health Graph partner profiles with a discussion with Erick Rivas (@erickrivas) of Limeade (@limeade). Limeade is a leading corporate wellness provider that recently announced support for RunKeeper and other Health Graph API (@healthgraphapi) partner devices and apps in their Limeade Open App & Device Platform. Read on to learn more about how Limeade is using the Health Graph to make the workplace healthier and more fun too!

Bill Day: What do you do for Limeade?

Erick Rivas: I’m CTO and VP of Product Development at Limeade.

BD: How does your work at Limeade help corporations and their people?

ER: People spend a lot of time at work. And, habits at work — what you eat, how active you are, how you manage stress, etc. — have a huge effect on health and happiness. We help reinforce and change company culture in ways that promote health, happiness and productivity.

BD: That is a fantastic mission! How do you take advantage of the Health Graph API in your work?

ER: There is a lot of innovation going on in the area of fitness devices and apps. Users want to leverage best-in-class fitness devices and apps they already use and have that activity automatically count towards the rewards and incentives that are part of their company’s worksite wellness program.

For example, I took my daughter for a trick-or-treating “walk” of 3 miles around our neighborhood last night using RunKeeper and this morning, via our Health Graph integration, I automatically got 1 point for that as part of the walking challenge that I am participating in at Limeade. Employees can receive health insurance premium deductions, Amazon.com Gift Cards, be entered into a raffle for an iPad, and so on when certain points thresholds are met.

BD: How do you see this partnership with RunKeeper benefiting individual employees at the companies you’re working with?

ER: Our integration via the Health Graph API gives RunKeeper users a way to connect with others at their company in a social context. It gives Limeade users a fun way to track their physical activity using the fitness app or device of their choice.

BD: When a user starts using RunKeeper capabilities via the Health Graph integration in Limeade, what specifically happens behind the scenes?

ER: Upon authorization by the user (using OAuth), we are downloading/syncing with all Fitness Activity types and associated units (miles, calories, minutes) that are supported by the Health Graph API.

BD: Any thoughts on the overall strategy we’re taking with the Health Graph and the developer community?

ER: I really like the vision and direction of the Health Graph in providing an open way for users to store, manage and share historical health data from multiple providers.

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

ER: I’d like to be able to distinguish between activities that were recorded by a device versus self-reported activities in the activity feed that is returned from the Health Graph API without having to parse through the GPS data.

Also, I’d like to be able know what the source of the device data is in cases where the user is not using the RunKeeper app (say they were using a partner device from Fitbit, Polar or Garmin). That way, we could not only show that you had (say) burned 10,000 calories in the last two weeks as part of your company’s Biggest Loser weight maintenance challenge, but also break that down by type of device.

BD: Thanks for the suggestions and requests, we appreciate them very much. What’s next for Limeade and your use of the Health Graph?

ER: We follow an Agile Development approach at Limeade and as a result we are deploying product improvements once a month.

In the near term, we will be improving the visualization of self-improvement information (activity, biometrics) and social features on the site.

Pulling additional data types that are stored in the Health Graph outside of physical/fitness activities (nutrition, weight, blood glucose levels, etc.) is something we will be supporting as well.

BD: Is there anything else we should know about you and your customers’ use of Limeade?

ER: I trust that a lot of Limeade users will be excited about the integration with RunKeeper and the Health Graph API. And I look forward to feedback on ways that we can make it even better!

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

Fleetly delights users via Health Graph integration

I recently had the pleasure of speaking with Geoff Pitfield (@gpitfield) of Fleetly (@fleetly) about his company and their new Fleetly app release which now includes support for RunKeeper users via Health Graph (@healthgraphapi) integration. Here’s an inside look at how one developer keeps their users happy and healthy with the Health Graph.

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.

Design a site like this with WordPress.com
Get started