Permalink | Leave a comment  »

Permalink | Leave a comment  »

It has been a long time since I've written an update, but I've been meaning to start again since I moved to Vancouver. Having learned of Nexopia's planned wind down and my upcoming unemployment yesterday, I have the impetus to share all the exciting projects I've had the opportunity to be a part of over the last year. I'll take things in chronological order. My apologies if it's a bit long-winded, a year without updates leaves a lot of ground to be covered.

Project Chronos

Strange how a project name always seems cool when you are working on it and tacky after the fact. I finished up this project shortly after my last update. I took it to the point where it was a fully functional SMS reminder service, then Steph came home from Banff and other opportunities presented themselves. I think I accomplished what I wanted to with this project. It was my first attempt to do full stack development right from the server up to the graphics. I learned a lot and in the end had a working product.

Prototyper

Prototyper was/is a native OS X tool for making high fidelity prototypes of iPhone applications. Prototypes could then be viewed and interacted with through a web interface or directly on an iPhone/iPod touch. I first heard the idea for this from Cam Linke in November of 2009. He, Sean Healy, Sari Maani, and Sinan Maani were already on board and had identified a need for another developer to round out the team. I was sold pretty quickly on both the idea, and the chance to work with the four of them. My biggest concern with the project was scope, I felt we needed to execute quickly. I envisioned us being somewhere or being done within 6 months. We started getting together to do actual product and development work in about January 2010. We made friends with Trevor the manager of Original Joe's and he opened up the upstairs of the restaurant for us to work on Sundays. We had a great time working there, and in telling people about it ended up starting a regular little Sunday hackathon (#codejoes) where everyone would bring their personal projects and work for the afternoon. The project was exceptionally interesting from a technical standpoint for two reasons. It was my first time working with Cocoa, a surprising mental adjustment to make that has since influenced my development in other languages as well. We also had an interesting approach to our iPhone simulator. We really wanted to make it web-accessible so that it was easy to share prototypes and gather feedback. With that in mind we decided to do the simulator in javascript/html. We wanted a smooth and natural feel though, inertial scrolling, etc. To accomplish that we implemented two layers; one layer for rendering the prototype visually with a second  "glass" div overtop that captured all click/touch events and passed them onto the appropriate handler, handled scrolling friction and gesture support. Things were moving along pretty well, but scope was a problem. We were not getting enough development time into the project only working on it part time. We decided to apply to Y-Combinator, we felt we had a good team and a good idea. The decision day came and we got an email asking some follow-up questions about our work. They then extended their decision making process a day. Finally we got our answer and we were not in. Not a big shock given the huge number of applications they deal with, but a let-down all the same, particularly after they showed enough interest to ask some follow-up questions. We applied to a couple of other accelerator funds as well, but without success. There was talk of potentially raising some seed funding outside of an accelerator so that we could afford to work on things full time. I did some personal contemplation and considered the risks, market, my own financial situation, and decided I wasn't willing to go all in on this particular project. At the same time another opportunity was presenting itself to me in the form of Rival Apps, so in fairness to both projects I stepped back from Prototyper in about April of 2010.

Rival Apps

For the last four and a half years my full time job has been working for Nexopia.com. I came on during the original major growth stage, and have learned through all of the experiences that resulted in its eventual downturn. At the end of March 2010 the company decided to try to make a move in a new direction. We had been unable to turn around user decline on Nexopia and hoped to bootstrap a new opportunity while we still had the chance. Our fearless leader, Kevin Swan, in consultation with stakeholders, had been looking for a market opportunity and identified sports social gaming as an underserved market niche. I was asked to refocus myself away from side projects to lead development down this new road and I accepted the challenge. We started out with a small fantasy hockey draft app just to get a feel for integrating with Facebook and the tools available to us. We were abandoning 4 years on our custom Nexopia ruby framework in favour of Rails. We also moved to lighter processes and fewer in-house tools. I was able to apply some of my lessons learned from Chronos and Prototyper here. We quickly pulled Chris Thompson off of Nexopia to assist, and launched in time for the playoffs. The overall feeling was that we had accomplished our goals with the app - it wasn't a big hit but we had a couple thousand users and got a feel for what we were doing. 

Sadly, at this time Nexopia was forced to lay off about half of our remaining staff. All that was left on the product development front was refocused on Rival Apps for our next endeavour. Next on the list was a game we called Baseball Empire. The idea was to create a baseball simulation and management game where you combined your friends (who were trainable) and real players (who could only be contracted to play on your team for limited periods of time). We made one major technical decision early on that shaped a lot of the development, the adoption of Sproutcore. We made the choice to try Sproutcore because we had been dissatisfied with the Rails view layer. We wanted a lot more interactivity and javascript than was easily integrated there. We continued to use Rails for the server-side logic, but moved the entire view to Sproutcore, pulling data from the server via JSON objects. Sproutcore was an excellent tool for this (most companies choose flash for this role but we simply didn't have the expertise or the time to gain it even if we had been interested in flash), though did impose a learning curve on development. The Sproutcore framework is not incredibly mature and we did spend time debugging the framework as well as our own code. In the end I'm not sure if Sproutcore was the correct choice as it came with a high cost. Redeeming it was its binding layer, which made what is normally a complicated mess of spaghetti code to update the screen, simple and elegant.

Baseball Empire development has been going well, however where it will go from here is uncertain. We "launched" very early on and it has been rewarding to see the gradual growth in users as we've fleshed our product out, from something that could barely be considered a game, towards a fairly addictive app. I'll hold off on further commentary here until the future becomes clearer.

Green Planet

I attended the first Canadian Startup Weekend in Edmonton the last weekend in June 2010. It was an amazing time. I got to work with a great team of people, some of whom I'd work with before: Cam, Sean, Joel Jackson, and others for the first time: Ken Bautista, David Quail, Sam Jenkins, Estin Edwards, Mark Donovan. I swore going into the event that the one thing I wouldn't do was a Facebook app, but with a bit of convincing they brought me around and Green Planet was born. I was impressed with how much we were able to get done in a single weekend, and I had a blast doing it. If you are considering a Startup Weekend I highly recommend it. The next one I'm attending will be in Vancouver, October 8th-10th. Green Planet is a "social game with a conscience". You complete missions and then mark them as done in the game. This in turn causes your planet to become healthier. You can also view your "Universe" to see how healthy your friends' planets are. If we get the chance to work on it more in the future, your planet will also get unhealthier over time if you don't complete any missions. As well we would add check-ins for smaller day-to-day tasks you can complete. Along with the Facebook app we also managed to produce an iPhone app so that you can check in on the go, it has not been submitted to the app store however.

Vidclipper

This was primarily a gag project, we made a trip to Calgary's DemoCamp from Edmonton, and built a demo en route to present. Our team consisted of Sean, Joel, and myself doing development. Reg Cheramy was our idea man and acquirer of a free van rental from Rent-A-Wreck and Mark did the driving. We took our inspiration from Instapaper. The goal was to make a bookmarklet you could execute on any page with a video, and then have the video queued up for later viewing in an iPad app. The project started when we got into the van, we had four hours before our demo. Needless to say it was a bit of an insane scramble of hacked together code. In the end we reduced the feature down to only working for youtube videos as we could easily (we thought) grab the h264 versions of them. We had a last minute bug that was preventing videos from loading in the iPad. We weren't able to figure out what it was and scrambled as we sent our demoers up to show off the app thinking that it was broken. As they reached the part of their demo where they warned the crowd that we hadn't quite been able to get it all done and that the next thing wasn't going to work, a miracle occurred. Our demo spontaneously worked. For every time I've demoed something only to find it broken for no known reason the universe paid me back. It was a great trip and a fun little project. I don't know that I'll ever again agree to try and complete a product entirely on a car ride though.

Concluding Thoughts

The last year has been a great time. I have learned a ton, both on the technical side, and especially on the business side of startups. I'll never be the "business guy", nor do I want to be, but I have a much better appreciation of what happens there now. I'm sad that my time with the Nexopia team is coming to an end as the people there really helped shape the person I've become. I'm excited for the chance to start somewhere fresh though. I'm in a new city ripe with opportunity, looking forward to finding something I can help make great.

Permalink | Leave a comment  »

Been awhile since I updated, spent more time coding than writing about it I guess. Project Chronos is finally up and running in private alpha. Things are still quite preliminary, it allows you to create and edit reminders, which are then sent to you at the proper time via an SMS. Here are some screenshots to get a feel for it:

The reminder creation page lets you create new reminders, clicking on the clock or calendar brings up time or date selection widgets.

Once you create a reminder you are presented with a summary screen showing a list of your upcoming and recently sent reminders.

That's really about all there is to it so far. I have a lot of ideas about other things I'd like to add, but I want to get a few people trying it out before I make any firm decisions. If you'd like to help me out by testing it, and are willing to deal with potentially some bugs and changes, please drop me a line. You can get ahold of me (@LogicWolfe) via Twitter or any other means you prefer.

Permalink | Leave a comment  »

Been making steady progress on Project Chronos this week. There will be a new blog post here soon with some details on status.

The first is Hoptoad, it is a rails service for tracking application errors. It aggregates error, tracks what deploys they've happened with, and integrates nicely with Lighthouse and GitHub (in the pay versions). It also sends you a notification email the first (and only the first) time a new error occurs. The integration though isn't at all required to appreciate the app. It makes it incredibly convenient to track what types of things are going wrong, and how frequently they are occurring. We have some in house tools designed to do this kind of thing at Nexopia, but nothing as polished. The best part about it is from the time I decided to install it to the time I had completed integration was under 2 minutes.

The second cool new service I found is New Relic, recommended to me by @tvongaza after I mentioned my pleasure with Hoptoad. New Relic does performance monitoring for your app. Measures the time it takes to complete a page, the cpu load, database load, etc. It also has a very nice development mode that lets you drill down into the details of individual transactions on your development server. It has a free version that is available for unlimited hosts, but it doesn't include the full feature set of several quite expensive pay versions. The feature set of the free edition is still excellent, it can be a bit annoying to see the constant reminders of features you can't use though. Between these two excellent services and my recent adoption of GitHub, I am feeling pretty happy about my developer tools now.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Update: Source code available from http://github.com/LogicWolfe/FBJS-Time-Picker.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

After Demo Camp the other night I was talking about the merits of Ruby as compared to Java for web development. At the time I was perhaps a few too many beers into the night to speak coherently on the issue, and it was rather difficult to communicate over the karaoke. I figured I'd take another crack at the topic here with a more thought through response. I was originally going to write this as a Ruby vs. Java comparison, but upon starting to write I realized I really don't have sufficient Java expertise to speak with any authority, so instead I'm just going to give a run down of why I like the web on Ruby. I invite comments/comparisons on the subject.

Let me start this by saying that I am not generally a language evangelist. I don't think there is a perfect language, I also don't hate any languages I've used. Languages, in my opinion, generally have a niche they are well suited for, and also usually can be used for nearly any problem with a bit of work. They always have strengths, weaknesses, and trade offs to be made. With all of that in mind I think the choice of language for a project is often far less important than the choice of people, the definition of requirements, the development methodology, etc. Please keep in mind that when I express my whole hearted support for Ruby it isn't meant to imply that Ruby is always the best choice, that other languages are inferior, or that if you disagree with me I will be offended in any way. I always enjoy a good debate of ideas and there is no way I will address every area of contention in this article so please comment away on what I missed or why I am foolish.

I'll start by addressing a couple common complaints about Ruby. I think the most obvious flaw with Ruby is its performance. It is a slow language beset by historically lackluster implementations. The problem with this as an argument against web development (as opposed to 3D rendering) is that in the big picture for web development processing performance means essentially nothing. Performance of web apps (at least the ones I work on) is dominated by database access times. On top of that it's not really performance that matters, it's scalability. Serving web pages scales incredibily well from the CPU side of things so one can always throw more processors at the problem.

Another complaint against Ruby is maintainability. This complaint was specifically made to me after Demo Camp and resulted in much of my floundering for an answer. One of the big reasons I was slow to come up with counter arguments as to the benefits/trade offs that warrant this, is that I don't really believe it's true. I took some time today to look for evidence in support of the claim, and instead found an article by Ola Bini, "The Maintenance Myth", that sums up my own feelings on the issue quite well. Basically I think there are two things that really prevent maintenance from being a disproportionate problem in a well organized dynamic language project. The first is that you write fewer lines of code. The estimates as to how many fewer vary extensively; but dynamic languages are more expressive than static ones. Fewer lines of code means fewer places to go wrong, fewer places to look when making changes, fewer lines of code to understand when you read the code later. Second, dynamic languages lend themselves to DSL's.

DSL's are another source of embarrasment to me from Wednesday night as when I tried to explain how awesome they were, I couldn't even manage to explain what they were. For those not familiar with the acronym it stands for domain specific language. Basically it means you have a nifty little framework specifically tailored to your problem that allows you to describe instances of your problem in a way that makes sense for that specific problem. The closer your language is to the problem you are solving, the less work it is to think about how to solve the problem. In a statically typed language you typically solve a problem by instantiating a factory, and then telling that factory to build an object, and then asking that object for the answer. In a dynamic language you do something like find_restaurant :type => :pizza, :budget => 25, :location => 'Edmonton' and it returns you a list of restaurants that fit the constraints. The difference is both small and large. You use the same starting information and achieve the same results, it's all about the extra thoughts/lines of code required to do it in a static language. Without the extra considerations there is significantly less potential for bugs when writing it, and for misunderstandings when reading and learning it after the fact.

I'm not making the argument that dynamic languages are inherently more maintainable than static ones. Static languages have advantages in tools: IDE's that can reason intelligently about the code, compilation that removes an entire class of bugs before runtime, and generally superior debuggers. The problems one faces though are different and I have never seen it play out that it is inherently easier to maintain static code. The least maintainable piece of code I work with is written in Java. It is unmaintainable because it was poorly designed not because of any choice about language.

Based on these arguments I claim that Ruby falls into the category of languages that can be acceptably chosen for web development. This is a large class of languages and the choice between them essentially comes down to what language will developers be the most productive in. This is a question heavily influenced by the skillsets of the developers available, the development methodology, the culture of the company, and the existence of preexisting libraries suited to the problems at hand.

In the case of Nexopia when we made the decision to switch to Ruby, we were a group of young developers, with backgrounds in a diverse set of languages. We were practicing Scrum development. We were also perhaps a little to keen on doing things ourselves, driving us to discount the importance of preexisting solutions to our problems. As a dynamic language Ruby allowed us to write small amounts of code to accomplish very powerful things. It had a vibrant community all focused on the same types of problems that we were; social media seems to be a primary cornerstone of the ruby world. Within a couple weeks of development (our testing period for the language) we had a basic object relational mapping layer, a routing and controller layer, and a templating system; and we had used them to build a couple basic test projects to great effect. Ruby was fun to develop in and we were getting a lot done quickly. When we met to discuss whether we should go forward with it no one was against it. It has been a rocky ride since that point, as I said earlier rewriting is not an easy task.

The one thing that has held true though is that Ruby has been a joy to write. I spend my time solving interesting problems. Things that would be tedious in other languages are generally addressed in Ruby with a small piece of framework that handles class generation and boiler plate for you. Fixing bugs means fixing the framework and seeing the correction propogate into everything that uses it. When I write Ruby code I never feel like a code monkey, problems that don't require thought aren't problems that should need programmers to solve them. Ruby makes this a reality.

In short, the answer to "Why Ruby?" is "because I can". Powerful language features like OO, closures, metaprogramming, eigen classes (to get all the buzz words out there), help to make it easy to not only solve problems but to solve them elegantly. The drawbacks of Ruby are not drawbacks to development, and in the end I will always choose the language that favours a developer over one that favours hardware. Ruby is a language that makes coding fun, and that is the best reason I think there can be to choose a language.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »