Follow The Leader - Linkedin Does an App Platform, Why?

This past week saw something we've seem before, again and again, with Linkedin launching it's application platform.  The big question is why, what's the point?  Their team is pushing it as professional applications for things like sharing book reviews, documents, and extended communication options.

Okay, that's cool, but most of the people you generally connect with on Linkedin are professional peers, if you had a need for this you're probably already doing it with something like IM or google docs.  Since Linkedin is a professional network it doesn't really lend itself to the type of viral sheep throwing applications that made the Facebook platform so popular.

Now, the thing I'm really wondering is why it took them almost a year from announcing the platform (about 5 months after the Facebook platform took off) and actually releasing it.  To me it seems like the first post on their platform was a load of crap and they were just trying to grab onto a bit of the hype that Facebook had generated.  On top of this almost every application I tried to use gave me some sort of error or had information flowing outside of the visible area for the application.  I expect more from such a high profile company with over a year of development time.

This doesn't make Linkedin suck less, if anything it makes them suck more because it seems like all their doing is running after the successful ideas from other companies.  If it doesn't make it suck less, don't do it.

EC2 Makes Getting a Startup Going Suck Less

Obviously getting your startup going doesn't suck (well, hopefully not all the time), but it is a shit load of work.  You need a kick ass idea, people to build it, a way to distribute, somehow get people to pay for what you're doing and countless other tasks.  This is a lot to deal with, and since you're a startup it's probably you or a small team doing all the work.  Well, if you happen to be building a web based product Amazons EC2 platform is defiantly something to check out.

EC2 is Amazons 'Elastic Cloud Computing' platform and it lets you take advantage of Amazons huge server and computing infrastructure to run your own server instances.  There are countless advantages to running your application in the cloud like this, the big ones in my opinion are cost savings as you pay for what you use, flexibility in expanding your server farm and the reliability of a distributed and proven network.

This is really cool.  If you think back to a couple of years ago how you would setup your own infrastructure you'd need to go out and buy some expensive servers and load balances, get it all setup somewhere  and then hope the traffic doesn't blow up the machines before you can get get more in to handle the load.  Now with EC2 you don't need to worry about the hardware and over purchasing to handle the load or running out and buying a new machine when one gets fried.

Things with EC2 aren't quite perfect yet, but they're not far off and a lot of the pain points are going to be addressed in the near future (2009) Amazon says.  From the Amazon Web Services blog, here's a couple of the things to look forward to:

Awesomesauce.  Those are the exact things that have been creating extra work when using their current offering, Amazon is spot on with the features that their users are really looking for.

I really like what Amazon is doing in this space, but if you don't or if it doesn't do what you need it to there are alternatives.  Google App Engine (GAE) is one such alternative that looks pretty neat.  It's neat because it's built by google, on top of their infrastructure and allows easy integration with existing google services (docs, accounts, etc).  In it's current state it's nothing compared to EC2. 

The biggest difference is that with GAE you're tied to using python for your application development and you can't really customize the platform at all.  With EC2 you start with a basic linux (and now windows) that you can then customize with whatever you want.  But if you don't want to do all that work, and you're a python kind of person, GAE might be perfect for you.  I, on the other hand, prefer the flexibility you get with EC2 and can't wait to see where they go from here.

Go out, get started.

ActiveApi - Wrapping a RESTful API in AS3

ActiveApi is my AS3 wrapper for a RESTful api, I just came up with ActiveApi right now so if I'm stepping on someones toes just let me know.  In my last post I kind of went over how I came up with these classes so I'm just going to dive into some code. 

To get started you need to define a controller class that extends from activeapi.base.Controller.  This class should be a singleton, you can do that however you like.  Controller defines a getter base\_url that just throws an error so you'll want to override that so it returns your base url.  This is what you'll get:

Controller extends from EventDispatcher so you get all the event listening and dispatching methods from that.  This is the class that you will add listeners to for CREATE and DELETE of your objects, like this:

Point to note, I'm prefixing the type of object I am creating to the event string, this isn't the ideal design but it was the best I could come up with.

Next is defining the class that is going to be doing the RESTful operations, the Session class in this example.  For now I haven't found a reason to create a base class to extend from, instead you instantiate an object that will be used to delegate the work to.  This is what the basic Session class would look like:

This class has a bit more going on.  First off is the ResourceHandler, it takes the name of the object type you want to create and a Controller as it's parameters.  I made mine static so that I could use it in both my static create method and instance method destroy.  Under the covers the ResourceHandler sets up some HTTPService objects pointing to the urls for creating and destroying the session object and setting op the correct mehod and response type (XML).  These objects aren't accessible but are used by calling the create and destroy methods on the ResourceHandler.  In the callback I use another method on the, handle\_and\_dispatch, to do some basic parsing of the response and then dispatching the events on the controller.  The second parameter of handle\_and\_dispatch is an object and is added to the final event that is dispatched.  The auth method that was added to listen for session CREATE before might look something like this:

And that's basically it.  The ExampleController kind of acts like a central messaging system and the major work is delegated to the ResourceHandler.  I still need to pull this out from the project I'm using it for, which shouldn't take long, so if you're interested in the code let me know in the comments.  I'd also really appreciate some feedback on the design choices and improvement suggestions.  Personally I'm still left feeling like there's a better way but trying to figure something out has been sucking up way too much time.

Making Input Fields Suck Less

I subscribed to the blog Usability Post last week and have already come to love it.  There's a pile of content on this site, all geared towards making your products more user friendly.  There's everything you can think of here, from general ideas on using categories vs tags, to specific hints or tricks like how to automatically select and input field on page load.

One particular article was published last week that caught my eye on how to remove the OS X glowing blue outline for custom styled input fields.  This tip is great.  It's simple, it doesn't change the world, it doesn't disrupt anything, but it makes your app suck a whole lot less for the end user.

Check out the post, subscribe to the blog and start using these ideas to make your applications suck less, because really, who likes a sucky app?

Wrapping a RESTful Rails API in FLEX

A little while back I was talking about getting started with writing an Air app in flex that talks to a Rails backend and some of the troubles I was having.  I've been working on and off trying to fine tune what I started out with and turn it into a set of base classes for wrapping a restful api (based on the rails conventions).  I've finally got something, it's not ideal and it's really not how I would have liked he design to turn out, but it's better than anything I've come up with along the way.

I'll start out with how I would have like this little framework to have turned out.  What I was really looking for was a couple of base classes that defined the basic REST actions as well as some unifying way to dispatch and listen for events on the api.

The second problem, 'event management' I guess, wasn't too hard to solve, I created a Singleton (sort of, AS3 doesn't really let you do this, but you can kind of fake it) that extended from EventDispatcher and then added and made dispatch calls on the instance.  My class making the REST calls now needed to know about this 'Controller' class to be able to do the event dispatching, it also made sense to define the endpoint url here.

Now, the main problem I was trying to solve, having a base class to define the REST calls, kept giving me trouble.  At first defining instance methods for create, destroy, etc made sense but then as I started using the class having create as an instance method really didn't make sense; create is building the object instance and should be a static class method.  This is where my trouble started, since create (and get) actions should be static, if I wanted to define the logic in the base class then my subclass would still need to provide a wrapping method, or I'd be calling something like Base.create("object\_type") everywhere, which didn't really seem right to me.  This lead me down a long road of messing this reflection classes, and introspection methods (which are awful in AS3 in my opinion) causing a lot of ugly code and me to become frustrated with my solution.

After messing about like this for three separate coding sessions I had enough and decided to get back to what it needs to do; blew away the base classes and brought everything into the main class (for now this was the Session) and structured things the way I wanted it to look for a client of the api.  Once I got things working again it was again obvious that some things could be abstracted away, but I still have the problem that some api calls should be static and some not; which would pull me into the same mess as before with a base class.

So, Instead of doing that I created an object that wrapped up all the rest services into a single package then I created a static instance variable of this 'ResourceHandler' inside my Session class and delegated the work to it.  Now, this isn't as easy as extending from a class and overriding a couple of methods, but it does hide away all the HTTPService definitions, adding and removing event listeners, and other redundancies from the classes.

I still think there should be a cleaner way to do some of this in AS3, maybe I just don't know the language well enough though.  Part way through I did find another framework that was trying to implement ActiveResource in AS3, but the project doesn't look very active anymore.  I'll post a little walkthrough of how the classes work in a bit, it's still not complete yet but if you want to take a look at the code in the meantime leave a comment.

Rails and Air

As I said last time I've started playing around with Adobe Air, what I'm doing is a little Rails app with a Air desktop app written in Flex 3.  For the Rails portion I'm going with the standard REST actions with responses for html and xml.  The Air application then uses the REST api to communicate with the back end.  Everything is pretty straight forward, but getting flex to play nice was kind of frustrating.

The main problem was getting rails to accept the requests.  I started out with something like this:

  var service:HTTPService = new HTTPService();
  service.url = 'http://localhost:3000/sessions';
  service.addEventListener(ResultEvent.RESULT, complete);
  service.send({login:'user',password:'password'});

The first problem I ran into with this is that Rails was ignoring the requests and kept giving me a ActionController::InvalidAuthenticityToken error.  It took a little googling but I finally tracked it down to the CRSF protection in Rails 2; basically all forms submitted required a auth token to be sent with the data to validate  the form was generated by the server it is being submitted to.  This is only required for HTML forms being submitted, if the content-type is something else (like xml for my api services) the Authenticity Token is not required.

Once I got that figured out the requests were making it a little bit further but still getting hung up.  This time it was the xml parsing saying I was trying to add a second root node to the xml.  This was pretty obvious, I was passing login and password without being wrapped in anything, a couple little changes and this is where I'm at:

    var service:HTTPService = new HTTPService();
    service.method = 'POST';
    service.url = 'http://localhost:3000/sessions';
    service.contentType = HTTPService.CONTENT_TYPE_XML;
    service.addEventListener(ResultEvent.RESULT, complete);
    service.send({session:{login:'user',password:'password'}});

A little change on the server so it looks for the login and password within the session object and off to the races.  Well, sort of.  You might notice that I slipped in that service.method = "POST"; HTTPService supports POST, GET, PUT, DELETE etc for the method.  This was great so I banged out another method for logging out, basically the same as the previous one but with service.method = "DELETE".  This lead to a couple hours of debugging, googling and cURLing to try and figure out why logging out wasn't working.  Long story short, the only type of requests HTTPService actually does is POST and GET, no matter what you set the service method to.  So, reach back and pull out the hacks to come up with this for the logout action url:

    service.url = 'http://localhost:3000/sessions?_method=DELETE';

Now Rails can pick that out and knows that I'm trying to do a delete and routes the request correctly.  Now that I'm rolling it's easy to keep defining service objects and making calls to my Rails server but it's becoming clear that a lot of this can be abstracted away.  In my next post I'll talk about how I've started designing that abstraction and how it's going.

Playing with Flex 3

I've started playing around with Adobe Air and Flex 3 again, man is it annoying sometimes.  I've been programming Ruby for awhile now and really like it so maybe it's affecting how I look at other languages, but I'm starting to notice how convoluted and confusing things seem to be in other languages.  The thing that annoys me around every corner with Flex (and ActionScript 3) is how heavily the rely on events.  I understand the event pattern and how useful events can be, but most Flex code I look at gets very confusing trying to follow all the events jumping around.  Everything happens with events and listeners; click, mouse move, service calls, image loaders, url loaders…

Why does everything need to happen based on events?  Why can't some things, like service calls, block until they get a response instead of fire and forget?  It would make a little more sense if flash was multi-threaded but it isn't, so if something else starts happening and holding the runtime up it doesn't matter if you're event gets fired.  Maybe this is just me, but following from method call, to handler, to another handler because the last one threw another event is really annoying.

Well, now that I got that rant out of the way I'll start digging in and trying to fit in with the Flex event based ways.

Make It Suck Less

That's what I'm asking myself before I do anything these days.  Is what I am doing making it suck less?  Am I making it suck more?  Why am I doing it then?  I'm doing this before I write code or before changing something around the house; before doing anything.

I'm starting to find that most people, myself included, get caught up in what they're doing, what they're trying to achieve, and it distracts them.  Most people think what they're doing is great, the best, and that they must be doing it right.  If you always think what you're doing is already the perfect solution, can you really make something great?  If you're only focused on where you want to be instead of watching the road ahead of you are you going to miss the potholes along the way?

This is why I assume it sucks.  It must suck, or else why would I be writing this code?  Or why would I be taking that woodchip path out of my backyard?  Because it sucks.  The process we're using sucks, so I'm writing some code to fix it.  It sucks raking leaves and pulling up half the path at the same time so I'm putting in stepping stones.

Make it Suck Less.

Don't try and take the gold right away, you need to work up to it.  You'll just hurt yourself reaching for something that you can't get to yet.  So work up to it, little bits at a time.  Make sure what you're doing is getting there.  Make sure you're solving the problem at hand.  Make it suck less to do something.

Strands - The Other, Other Life Streaming Service

A little while back I heard some chatter on FriendFeed about another life streaming service that had just come out and was 'FriendFeed but better'.  Naturally I had to check it out and take a look for myself to see what all the hype was about over Strands.  I created my account, added some services and friended some people.  That night I spent a couple hours checking out peoples feeds and clicking around.  I hadn't looked in again until tonight, almost a month later.

There's a lot of competition in the feed aggregation or life streaming area these days so you really have to be innovative to catch peoples interests.  FriendFeed came a long at just the right time to catch people with a very solid offering before they were committed to something else.  Anyone else coming into this space really need to take the hints from the current leaders and really push the envelope to be able to pull users from services they've now become attached to.

Strands did a very good job of picking up where some of these other services had left off.  Trendwatch, recommendations and a 'hot posts' list are all things that most other services are missing.  They also had friend groups before FriendFeed added their lists feature.  All these features sounded great to me I jumped ship to check it out.

I said earlier that will the competition out there newer life streaming companies need to push he envelope, which Strands has done, but they also need to take the lead from the services that already exist.  This is where Strands dropped the ball.  One of the things everyone raves about with FriendFeed is how simple and streamlined the interface is.  There's no clutter, just your content.  This is where I feel Strands misses the target.

Everything in Strands is so bulky.  The graphics are bulky, there's lots of empty space, about the only thing that isn't bulky is the content stream, the one thing that should be.  On my homepage I can see two post, that's it.  What am I looking at other than my content?  Pictures of the people I follow, menus and a whole lot of white space.  A service that is used to view the aggregated data of your friends should really put that content front and center, as much as it can, because at the end of the day that's why I'm there.

All in all Strands did a pretty great job of coming up with some new and interesting features but they need to work on the presentation before it will become useful.  With it's current design it seems like they're trying to give all the features and areas of the site the same amount of play, but all features are not made equal.  They need to think about what people are really coming to the site for and put that in the forefront. 

Getting to started

This is the story of how I finally got around to signing up to a blogging service and getting that first post up there.  It isn’t all that exciting; there wasn’t any lighting, an explosion or even a bear attack, but this is my blog and my story so I’m going to tell it.

About a year ago things finally clicked together that as a software developer I should probably be showcasing my work and what I know, building a brand as it were.  It had nothing to do with the countless posts on building your online brand, it just came to me.  I swear.  Around this same time I came across a couple of developers talking about how building your blogging engine is a good way to showcase your work and try out new ideas with your development (can’t find any links anymore).  This really appealed to me; there’s always something new coming along and work isn’t always the best place to try every shiny thing.  So I got started.  About a year ago.

I got going at a fair clip on things, was working with the latest version of Rails (2.0 at that time) which was neat because they’ve added a lot of interesting things, but then life pulled me away.  I got married, so a lot of time was spent planning that, we bought a house and we even moved in.  It’s been a crazy year.  Even with everything going on I’d still try and pull a minute or two away to work on things.  I even managed a pretty decent design and logo.

Then I read this article by Jay Fields, someone I really respect within the rails community, on blogging.

Don’t roll your own, you don’t need the maintenance headache.

Hm.  Ya, shit, he’s right.  It’s been fun playing around with building the blog, but I wasn’t getting anywhere (though I did end up with a 17 message thread in gmail of post ideas).

With my new direction I did some research and decided on using Typepad to host my blog.  Now things aren’t quite how I’d like them (I don’t have full control over the html with the plan I got) but hey, at least I’m here.