Wednesday, March 30, 2011

Focus on organization

Our company is entering a growth phase. We have taken on a capital partner, and are in the process of quickly growing our sales staff. On the technology front, we have added a very skilled consultant developer to help me create the products that will help push our company ahead. We also are building and leveraging the skills of our creative director, Jason Moore, in new and exciting ways. He is going to be contributing to the code base on the interface side, and is already ramping up his Interface Builder knowledge to contribute to the iPhone/iPad project.

The addition of contributors on the development front is terrific news for our company, but it's also forcing me to shift my focus. Since we didn't have any in-house development staff when I joined the company, I needed to spend the majority of my waking time learning web development concepts, planning development,  and building products. I've known all along that a minimized level of attention to the organizational aspects of my position was not going to work for long. Well, now I have collaborators, so for efficiency sake it's time to take a step back and organize.

Version control, distributed software hosting, project management software and process, a dashboard page for status of our products, product based wikis, and task management. All of these are necessary, and critical to our ability to manage the technology for a company that is and will be growing quickly. We will certainly add team member(s) in the future who will focus solely on handling these issues, but for now it's time for me to divert some attention to organizational progress.

-Pat Poels

Tuesday, March 15, 2011

iPhone application hurdles

Our API is designed to segregate the database layer from the presentation layer, but we do have a few data items that have html embedded. Our textual job detail and our client about fields require some styling to be embedded, and this presented a new challenge for our iPhone app development.

Fortunately, there is a solution. The UIWebView class is designed to allow embedding of web content within the native app. The class acts much like the i-frame html tag, rendering a view of some external web url within a locally defined rectangle. Navigation of the embedded url content via links or page back calls is also possible. But the class doesn't just allow data from an external url, it will also handle rendering html from a local string via the loadHTMLString method. And that's not all. Since the method has a parameter of the base url for the content, I was able to define the app bundle as the base url. This allows me to embed a line of html defining a css file to control styling, and have that css file reside within the app bundle.

OK, that was a bunch of developer-speak. What does it mean? It means that our content department doesn't have to create iPhone friendly versions of our job descriptions. I can call the API, get the html embedded descriptions, and then style them locally inside the app. I will have to make some modifications to handle link tags differently, but at least we have a solution.

Today I added video playback from our server to the app. This was surprisingly easy to do, as the defined classes are well designed. Now that I think about it, when you don't have to worry about multiple browsers, video isn't all that hard on the web either! I do have a bunch of notification handling code to write to make the application behave well when the video switches to full screen and back, or when the phone is rotated, but I'm happy with the progress.

-Pat Poels

Wednesday, March 9, 2011

Thanks for sharing, developers!

As I said in an earlier post, we are in the early stages of producing an iPhone app. Since I will be doing most of the development of this app, whatever it turns out to be, I've been pretty immersed in learning Objective-C, the iOS environment, XCode, etc.

I produced a testbed application running the iPhone simulator on my iMac desktop. First things first, I wanted to verify that I could produce a list view of open opportunities from a search string passed to our server via our API (in development as well), and I wanted to view thumbnail images with the listed jobs, where appropriate. It was pretty easy to get this to work in my test application, but there was definitely a problem. When scrolling rows, there was a very noticeable delay happening when moving across rows that contained a thumbnail image.

I had some guesses as to what the problem(s) was. A couple were close, one was way off, but the point of my post is that finding the issues and then also determining how to resolve them was actually far easier than I would have expected.

Caching the images, and also loading them asynchronously, might seem elementary to experienced mobile app developers. You have a finite amount of storage space, you don't have a local database to query, but the visits out to the web server are costly. They need to happen, but they need to be infrequent, and they need to not hinder the user experience by having the application wait for content delivery. But consider how long it would take even an experienced developer to arrive at this solution the first time, without the benefit of the experiences shared by development community that exists everywhere on the internet. I found solutions (and several code examples) very quickly, and what could have been a big hurdle was relatively painless. I'm sure this is step 7 of 1000, and they won't all be this easy, but I'm happy about how it went.

I've done a large amount of proprietary development in my time. Nowhere to go for help, just an instruction set and a goal. I have to say, I like this development world quite a bit more. I hope that some of the things we create and document can similarly help others in the future.

-Pat Poels

Sunday, March 6, 2011

Pathways API

This project hit our to-do list a few weeks after I started with Pathways Platform. Rebuilding our own site pages had to happen first, but the reasons for creating an API have continued to mount. There are many reasons to build and expose an API. Specific to Pathways:

  • Many of our clients would like to post their Pathways' jobs on their own website. Our presentation of job listings is superior to the text-only descriptions most of them display on their own sites, and the community metrics are invaluable. Currently, their only option for embedding a Pathways' experience on their own site is to use an i-frame to the job page on our site. This exposes the full functionality of peer video and community information well, but doesn't give a uniform site experience. Clients would like to be able to present the jobs in a way that fits well with the look and feel of their own site.
  • Scalability of our websites. Our company is still small enough to have our web server and database live on the same machine. Internally, the API will allow separation of the presentation and database layers.
  • Other front end products. We already have created a Facebook application that can be added to clients Pages apps, and we are also planning an iPhone application. The API will be our method of collecting data from our servers for presentation in these and other external applications.
We are two weeks into the API projects, and have already been able to create an API complete enough to allow us to create versions of our website pages that completely isolate the database functionality from the rest of the server work. Lots of security development left to do, and a ton of testing and documentation after that, but soon we'll have this product ready to roll.

- Pat Poels

Sharing our path

Pathways Platform is a young company in the medical career space, and we are firmly focused on learning existing and creating new technologies that will help change the way that medical professionals choose their career path.

I started my personal journey with Pathways Platform in June of last year. It's been an incredible ride already, filled with taking over the architecture and development of our websites, learning the ins and outs of medical nomenclature, dealing with clients, helping with capital acquisition, and producing code as fast as possible. Now that some of my immediate hurdles have been jumped over (or run through), it's time to start documenting our technical path. I'll endeavor to outline some of our future technology plans, ask a bunch of questions, and share what we've learned along the way.

- Pat Poels
CTO, Pathways Platform