Vacation
December 12th, 2008
I am going to drop off the face of the planet for a week. For good reasons though, I am going on my first vacation in several years. I am taking a week long cruise down in the Caribbean. I plan on do nothing but read and relax. If an occasional drink finds its way into my hands, I wont complain. If you need to contact me, I will have access to email. However, I won’t be checking email except for in the evenings. So, if there is a delayed response I apologize. I will be back state side on 12/22.
My apologies
November 30th, 2008
I apologize for It has been a long time since I have been able to write an article. However, it hasn’t been because I am out of topics or items of interest. In fact, I have been so unbelievably swamped at work I just literally haven’t had the time. However, all that work, plus outside projects like Dataportability have given me even more items to write about.
I will devote more time to writing, especially since the holiday season is rapidly approaching. During that time I hope to carve out some much needed time to crank out some important articles. Additionally, as a pre new years resolution, I am going to commit to one article a week. This way, no matter how busy I am, I will be on the hook for one article. I look forward to writing more frequently.
Finally, I am also kind of re-tooling my blog. So, if you see rapid changing themes or information architectures, please don’t hate me. It should be done by Christmas time. I apologize for any inconveniences this may cause.
Why OneConnect is currently beating Plaxo in the aggregation race
October 13th, 2008
Recently I had twittered about how I felt Yahoo’s OneConnect beat the pants of Plaxo. After twittering that, and much to my surprise, Plaxo’s Vice President of Marketing John McCrea responded to my tweet asking me why I felt that way. In my opinion, OneConnect’s advantage boils down to three simple things: my ability to post across platforms, it’s mobile, and it doesn’t require yet another platform specific social network.
Post Across Platforms
One of the problems that faces users of social networking platforms today, albeit a small one, is their inability to post common updates across the multiple social networks they participate in. Platforms provide niche functionality which allows users to build specific social and professional networks. For example, LinkedIn is for professional contacts, Facebook for social, Twitter and Tumblr for micro blogging, etc, etc. Even though users leverage these platforms for specific purposes, users will often want to update their status across all of them. I personally find it cumbersome to log into multiple platforms to update a particular status. OneConnect eliminates this cumbersome process and allows users to update their status on multiple social networks with a single post.
It’s Mobile
I have been able to become extremely active with my Tubmlr, Flickr, Facebook, LinkedIn, Twitter accounts since I can now access all of them from my mobile device. I snap a picture, and I can upload it directory to Facebook Flickr, etc. I have a thought, and I can instantly post on Twitter. These utilities are now accessible no matter where I go and are integrated into my mobile platform (Phone, Camera, etc). However, with my increased participation in all these networks, I have finally been exposed to the need for aggregation across them. OneConnect provides that for me. Instead of launching multiple applications serially to find out what is going on, I simply launch OneConnect. This is a significant advantage in my opinion.
YASN
Yet another social network. The honeymoon is over for me; I no longer get excited about building and cultivating a social network from the ground up. I have spent plenty of hours building my Facebook, Twitter, LinkedIn networks. I will admit that they will continue to demand my time as they grow. However, starting from zero again seems dreadful to me (reminds me a lot of rolling a new character in a MMO). Even going through and importing from my existing accounts seems tedious. OneConnect doesn’t require me to build another social network to aggregate the updates. It simply leverages my existing social networks in their current states. This gives it a distinct advantage over Plaxo.
On Plaxo, I have to build yet another social network. Additionally, once I have completed building my social network, my friends must then add their other social networking accounts as feeds, and finally, allow me to see their updates. There are just so many barriers to entry here. On OneConnect, I just added my login information for my accounts and I was done. In roughly five minutes I was receiving aggregated updates from Facebook, Twitter, Flickr, etc. It didn’t require those additional steps by me, or more importantly, my friends.
I initially felt that mobile was the biggest advantage. However, after taking time to really think about this topic, not having to build another social network is the biggest for me. If Plaxo launched a mobile application tomorrow, it still would take time before it became useful as an aggregation tool for me (if ever). Building a social network, and getting all my friends to add all their feeds is too much of a hassle (for all parties involved). I have already built these social networks and would not want to do it again.
Why I am still pulling for Plaxo
I am still pulling for Plaxo after all this. Their service, in general, is superior. It’s more robust (they include far more services then OneConnect), they support more feeds, and it’s more stable. OneConnect is buggy, slow, and limited in the accounts I can add. If Plaxo can get into the mobile space, and remove some of the limitations I mentioned, Plaxo wins. It would be to good of a product to turn down. Until then, I will be launching my OneConnect application.
Last Thing
I am very impressed by John McCrea actually reaching out and engaging a random user of both their and a competitors product. I will be honest and say that may be one of the reasons why I am in the end pulling for Plaxo. Knowing Plaxo is user focused and willing to reach out and engage their users to identify how they can improve their product is impressive.
Dataportability Healthcare Task Force
October 1st, 2008
I recently blogged about how I was looking to participate in solving the social network profile interoperability problem. I am both proud and excited to say I am now a part of Dataportability Healthcare Task Force. Currently we are in the preparation phase. However, look for some white papers beginning relatively soon.
Working with Ruby on Rails; A look back (part 1 - Active Record)
August 25th, 2008
It has been about five weeks since we elevated our fist release of our new platform coded in Ruby on Rails. Looking back, my teammates and myself couldn’t be happier with making the switch over to Rails. For the most part, it has continued to amaze us with how quickly we can add new functionality. Additionally, the open source community has continued to provide valuable plugins for our application. Between the technology stack and the community, we have been able to accomplish a lot with little time.
However, like with every technology stack, not everything is perfect. Additionally, we learned as we went, so naturally we made mistakes. Now, as we get ready to complete development on our second major release for our product, we have begun to incorporate some lessons learned into both our design patterns and coding practices for our team. As we do this, I thought it would be nice to publish them here. This would allow other development shops to both learn from our mistakes, and provide additional feedback as to how we might solve them differently.
Since there are several areas for me to talk about within this topic (Active Record, RJS, Plugins, Models, etc), I am going to do this over several posts. This will allow me to go into detail on each specific area, rather then cram it all into one post.
That being said, I am going to first discuss what we have found out in regards to Active Record. This has been our biggest pain point, and we have found some great simple solutions, and utilized some amazing open source tools to help us improve performance.
Active Record, and ORM’s in general are amazing to code against. The simplicity they provide by encapsulating both the relationship, the mapping, and CRUD operations for the data types in your domain will make development easy. However, they also tend employ a load on demand, and load everything paradigm when interacting with the database. If you are not careful, these can have some serious performance implications in you application. For us, these were the two biggest offenders.
Load on Demand
The load on demand problem typically rears its ugly head when used in conjunction of an enumeration. This is typically referred to within the Rails community as the “N + 1″ problem. The code snippet below shows an example of how you could easily create it
<% @registered_users.each do |registered_user| %>
<%= registered_user.degrees.map(&amp;:title).join(', ') %>
<% end %>
In this example, you will see that for each user in the system, we are making a call to retrieve the degrees they have associated. As the number of users in the systems grows, so will the number of requests to the database. Over time, this will begin to slow your page down to a crawl. Thankfully, Rails and Active Record provide a solution for this problem.
For requests like the one listed above, you need to also include the associated degrees when initially retrieving the users from the system. This way, a join will occur in your database to bring back all the necessary data in a single call, rather then multiple.
@registered_users = User.find(:all, :conditions => "registered = true", :include => [:degrees] %>
Keep in mind, that you need to monitor to actually see if the join generated by the include option to your models find method actually improves performance. Joins prior to ORM implicate performance, its’ no different with an ORM. So, keep in mind complicated nested includes might not actually have a performance benefit.
Retrieve everything, all the time
Active Record defaults to a retrieve everything paradigm until told otherwise. Again, like load on demand, this makes development a snap. A simple find statement retrieves you a fully hydrated object. However, this can lead to unnecessary data been retrieved from the database. We found that by leveraging the built in select statement within Active Record usually solves this problem
@registered_users = User.find(:first, :select => "first_name, last_name")
Using the select statement will retrieve only the data you specify. This will allow you to keep the data retrieval as light as possible. We have since moved to always specifying exactly what data you are retrieving through the select statement. This speeds up the retrieval and adds a little extra documentation to the find.
Performance Monitoring
Through the course of our development we have found the use of several tools to help monitor our applications performance. We typically do this two ways, the first being in our local development and test environments on a single page request basis. The second being aggregate data pulled from our production boxes.
We monitor the single page performance in the development and testing environments using FiveRuns Tuneup application. This plugin installs a div at the top our your page that upon mouse over will provide diagnostics information on page you are currently viewing. We use this as our first line of defense for monitoring performance.
Additionally, we use http://github.com/wvanbergen/rails-log-analyzer/wikis to analyze our log files. This provides aggregate data and will identify your top ten poorly performing pages. Both have proven invaluable.
Don’t forget the database
At the end of the day, if you don’t let Active Record lull you into forgetting that there is a database out there, you should do fine. We simply retrieve only what we need with selects and minimize database queries with includes and have seen a tremendous reduction in time spent at the database per page request.
It seems obvious, however, when we were juggling learning a new technology stack, and sitting behind the beautifully simple API’s provided by Active Record, it was easy to let these obvious mistakes enter our code base. Fortunately, they were easy to fix.
If you have any additional Active Record improvements, suggestions, or points of interest, please post as a comment.
Things I look for when hiring
August 20th, 2008
Hiring is a very difficult thing to do. Finding someone with the right mix of passion, skills, and personality is extremely difficult. I have found that it is even more difficult when running a start up as your margin for error is absolute zero. At a start up, the stakes are extremely high, the work demand is extreme, and you don’t have money or time to make mistakes, especially hiring mistakes. You need to build and maintain a highly tuned machine. The impact of hiring someone who cannot pull their weight, has a giant ego, or is only along for a paycheck will be devastating. I’ve seen it set teams back weeks if not months.
Fortunately, I haven’t experienced anything like that as of yet. As my team has grown, each new edition has been great. Each person brings missing skill sets, great personality for start up culture, and a passion for our craft and what our company does. However, I am currently filling three open positions on my team right now. A developer, a designer, and a tester.
Starting the hiring process again has got me thinking about what I look for specifically in a developer. These aren’t in any particular order, nor am I discussing any weighting of one vs the other. Additionally, not having one of these qualities doesn’t instantly remove you from potentially getting hired. This are just some of the things I look for and why.
Passion
First and foremost, the person must be passionate about what they do. When hiring a software developer, computer science should be their religion. I want to know that when they wake up in the morning, this is what they look forward to doing. Their night stand should be stacked with Computer Science books, and their browser history should show the usual suspects.
This is important because at a start up you work a lot of hours. I typically tell someone during their interview that joining a start up isn’t a career decision, it is a lifestyle decision. Currently my team typically averages somewhere between sixty and eight hours a week. If software development isn’t your passion, it isn’t something you could do morning, noon, and night, you are most likely going to wash out.
Polyglotism
Seeing that the person understands the language that our technology is currently built upon is a plus. However, I would much rather see a few languages under the persons belt. Specifically, a good balance of dynamic, static, strong, weak, and functional.
I find this important because it shows the person is most likely stronger across the board. Additionally, I want to know, if we adapt a newer technology or language, as it is a better fit for a particular job, the person isn’t going to be totally out of their element diving into new and uncharted territory.
Independent Projects
A few years ago, I probably wouldn’t have stressed this as much. However, after seeing the difference this quality usually makes, it is high on my list. It could be anywhere from participating in local user groups, to actively developing on an open source project. I want to see that you actively participate in a broader community of your peers.
Data structures and algorithms
This is an important one, at least for me and my team. We are currently building a large scale distributed system that deals with very large data sets. More importantly, because we are a search engine, our ability to slice and dice that data in extremely fast times is critical. Without have a solid foundation in data structures and algorithms would be an extreme disadvantage. Typically I look for the usual suspects …
- Graphs
- Trees
- Linked lists
- Advanced Sorts
- Big O
Confidence and Humility
Everyone at a start up has a lot of responsibility on their shoulders. I need to know that you will have the confidence to tackle very difficult problems and solve them in short time frames. Additionally, you need to be able to ask for help, collaborate, and communicate. Finally, you need to check your ego at the door. Right now we don’t have anyone with the title of “lead”, “senior”, “architect”. We are all engineers working together towards a common goal.
Diversity
It’s important to be more then just a development rock star. This is important because of where we our in our start up. As we grow, specialization will be more important. However, right now, we need more then just a developer. Having experience in development, infrastructure, databases, and security is incredibly beneficial. Obviously finding someone with all of those is extremely rare. Typically I look for a few of those skills in a candidate. Specifically, where the team is currently lacking. Right now, having someone who has a strong back ground is security would be a major plus as the other categories are currently covered by someone on the team.
Wrap up
That’s really about it. If I think of anything else I will update the post. If anyone else has qualities they look for, please feel free to leave a comment. Additionally, if you are looking to join a start up that is working with Ruby on Rails and building a professional networking platform and search engine for the medical community, please feel free to contact me. My email address is anthony [ at ] within3 [dot] com.
Scientific and Medical Profile Interoperability
August 17th, 2008
Currently, I belong to several social networking platforms. This includes Facebook, MySpace, LinkedIn, and soon to be released Twine, and Stack Overflow. That is a lot of social networking platforms. More importantly, as the industry trends to more specific social and professional networks, the number of networking platforms I belong to will increase. If the industry continues to proliferate at its current rate, I will probably belong to around eleven or twelve sites over the next year.
The fact that I will belong to so many social / professional networking sites does not upset me. In fact, it is the exact opposite, it excites me. Each site will most likely provide an incredible amount of value specific to its vertical. For example, I would love social networking sites specific to product development, start up life, software development, and management. I would gain a tremendous amount if I could interact and collaborate with my peers in those specific areas. However, what I don’t look forward to, is having to maintain so many versions of my profile.
The sheer amount of time it would take to maintain all my profiles, which are really alternate presentations of my resume, is daunting. More importantly, as these sites specialize around professional areas, my need to keep my profiles accurate and current, increases. That means, for each experience I want to add to my profiles, I will have to log into several sites and make the same change, over and over again. This is clearly an annoyance.
I bring this up, as it is currently a problem with professional networking platform I manage. We are a professional networking platform for the medical industry. This includes physicians, researchers in the health sciences, nurses, and more. Each of these users has an extremely rich profile that contains a lot of information. Currently, our users note that maintaining these profiles even for their institutions is extremely time consuming. So here we are asking them to create and maintain duplicate. Additionally, we import and export these profiles in a format specific to the organization we are dealing with. Meaning, per each organization we interface with, we translate our representation of the users profile into a format the organization understands. This isn’t very efficient for anyone involved.
Additionally, independent of our platform, the medical industry is starting to embrace cross institution online collaboration. These future platforms will have the same problem of multiple profiles, and no consistent way of sharing the information the same as ours. Continuing to create multiple versions of the profile, and one off representations and communication protocols will not scale.
A single representation , communications protocol, and repository for a physicians profile is needed. That being said, I am now venturing into creating a profile protocol and repository for the medical industry. I am not going lone wolf, instead, I am getting involved in the FOAF (Friend of a Friend) project and the Data portability project. I will look to spearhead the medical and scientific pieces. I don’t know if these will be the final solutions, but it is where I am going to start.
As I progress, I will update through this blog. Please stay posted.
Hello World!
August 6th, 2008
Finally, I am going to enter the blogging world. I have wanted to do this for a couple years now, however, I never could seem to find the time. Oddly enough, now that I help manage a start up, and have absolutely no time (eighty hour work weeks, family, and back in school), I am going to start blogging.
Prior to my involvement at Within3, I just could never find a topic or theme that I wanted to write about. I was an applications architect building large scale systems in .NET, so it should have been simple. However, anytime I sat down at the keyboard, I would get distracted and begin writing code for whatever my current side project was.
Now that I have immersed myself (and my family) in a start up for over a year, and have successfully designed, built, and deployed my first application from the ground up (without an Enterprise IT support staff), I find that I have a long list of topics and experiences to write about.
This blog will most likely be technical in nature as I will focus on applications architecture, operations architecture, development methodologies, design patterns, and technology stacks. However, given my role as Chief Technology Officer and responsibilities in product development and delivery, I will also discuss product management, design, and organizational management.