Archive for June, 2008

SproutCore is a chainsaw and YUI is a paring knife

Monday, June 30th, 2008

I have been playing with SproutCore a bit lately. So many great features and so very very simple. At first, I was expecting to either dismiss it as another library or love it so much that I replace my current favorite. Neither turned out to be the case, I love when a new solution can come along to solve a problem that I had already accepted would never be solved. In fact, SproutCore solves the same need for web client interfaces that Ruby on Rails solves for server web applications. 

The JavaScript fat client is here to stay.

The entire “Web 2.0″ movement has proven that users love a solid fat client. I use gMail and Flickr every day as do hundreds of others and I know none of us miss waiting for a page load every time we click on a message or save a caption. Building these fat clients can be tedious with all of the state changes that need to be carefully choreographed. As an example, when you delete an email message, you might want to update a total message count. Was that the last unread message? well then you will also have to change the unread count to zero and change the folder style from bold to normal weight. Luckily, these are all pretty common needs and the SproutCore framework exists to provide this functionality to us allowing us to focus on other things.

This does not replace the need for traditional libraries.

Indeed we are becoming more and more aware that there are two different categories of web project, Web Apps and Web Sites. Web Apps are a lot like a desktop client. Users expect to have a single interface and be able to get to everything they need in few clicks. Web Sites, on the other hand are more like a news paper and people expect to enter through a front page of some kind and explore in to get more detailed information on a subject. For me, I have settled on creating one Web App project with a Ruby on Rails back-end mixed with a client written in SproutCore. Another project however, is a simple information site which will use PHP, along with a little interface help from YUI. I think it this is an important distinction to make as I can see these two areas branching off more and more as time goes on.

Posted in Web Interface Development | 2 Comments »

Thinking beyond Web 2.0

Wednesday, June 18th, 2008

Over the past few years we have seen people do some remarkable things with Javascript. This is almost like the age of enlightenment for Front-End developers. In a short amount of time we have gone from a majority of hobbyists and hackers to a group with a fair amount of true engineers. In some cases we are even gaining respect from back-end coders. We have done well for ourselves. 

Now we are experiencing some growing pains as Libraries are created and each competes to make their code faster and better. We are left wondering what direction to head next. It seems that there are so manny possibilities going in so many directions that if we follow the wrong one we could end up loosing our way and get left behind by the time Web 2.0 gives way to Web 3.0.1 Gold Vista-Leopard. Honestly though, I don’t think that things work that way. None of the changes that brought us to “Web 2.0″ should have been a surprise. We had been tinkering with ways to make things more interactive for years. Also, coding styles may have changed. This was no surprise either, we knew that we were hacking Javascript all along. I think in some way we all knew the time would come where we had to start respecting it as a real language and start following some standards. So, here we are still waiting for the next train. I think it should be obvious if you use common sense. Everything that you are doing now that you have always done, but just seems wrong will be replaced by a way that actually works. 

Here are a few areas that I think would be smart areas to focus:

  • Unit Testing: We will find ourselves building complex applications which can have many points of failure. Unit testing each interface can help us to make sure that each component of our code meets guidelines before moveing to build the next component. When QA comes knocking on your door they will find fewer bugs and you will have an easier time fixing bugs that are found because you will be more familiar with your code. It is no wonder why your buddies that code languages like Ruby and Java are crazy about Test Driven Development. Here are some resources that are available to unit test Javascript:
  • Name Spacing: For any of us that have subscribed to Dustan Diaz’s blog or that use the YUI libaray, this is old news. Still a lot of us are not keeping our code in a namespace. This ensures that any future home that your code finds itself. May it be a browser running Javascript 8.0 or a new JS library, your code will not collide with anybody elses code. When all browsers decide to start to support a String.toJSON() method, it will not conflict with your ME.string.toJSON() method. for more info on this check out the daddy of all JS namespacing posts: http://www.dustindiaz.com/namespace-your-javascript/
  • Code Composition: We need to start thinking of our code as something that is going to be seen by other people. Code should be reusable and the more organized, commented, and spaced it is, the better. Cleanly composed code also is easier to troubleshoot. Sold yet? Good. Here are a few tips:
    • Use a minifier that strips our comments and spacing before moving code to production. This gives developers the freedom to comment and space as much as they need without effecting the weight of the page over the wire. 
    • Use symantic names for your methods. We all know that the only documentation that we want to write is our code. When somebody encounters an object that you have created to deal with a customer they will be way more likely to understand a method named “saveCustomerData()” then one named “ajaxCall()”. 
    • If you don’t need to re-use it, nest it. For example, if you are calling a method that asks for a function as a parameter to use a call back, nest the function inside of the method call. A lot of people think that it is cleaner to declare the function first and then put its reference into the method call, but this moves the code for the function out of context while reading the code. It also requires more work for the browser to first declare the function and then envoke it later. Here is a code example:

          yourObject.yourMethod(function(
           /* string */ argument 1,
           /* Object */ argument 2
          ){
           //Code here
          });

This all comes down to common sense. I am sure that there are a lot more things that could be added to this list and I would love to revise this later. This is the direction that I am heading for now.



 

Posted in Web Interface Development | No Comments »

The Afterburners

Thursday, June 12th, 2008

Last week, in an effort to meet an impossible timeline, our team was asked to make a few changes. We were assigned 7 people from other teams. We also were asked to stay some extra hours and work the weekend. Our commitment was amazing. We worked for an entire week of 12 hour days. The lack of ego and complacency remarkable. This was not by any means my ideal way to spend a week but I understood what needed to be done and the consequences if the goal was not met.

 

Introduce 7 new people

to a team that has been working together and there are bound to be a few bruised egos. Think of the actors involved

  • Heros - some people love to be the one person on their team that knows one subject better then anybody else. With 7 new people there are bound to be one or two people the will match or exceed that skill.
  • Black Boxers - Some people just don’t like to collaborate. Maybe they are trying to hide a perceived or real lack of talent or maybe they are just anti-social.
  • Power Grabbers - There is usually one or two on the team that aspire to manage the entire team. They can be arrogant, nosey, and pushy.

All of these types are toxic to a teams ability to gel. I am not absolutely sure how, but we seemed to have none of these on board. Sure we had our conflicts but everybody was genuinely glad to help. This is more impressive considering most of the new people were traveling from our main office, and are now more then 5 hours away from their homes and families. 

 

Management started off on the right foot,

We all got the impression early on that this was a short term push for an important goal. Most of us felt that the request was made with respect and we saw our management committing themselves at the same level. Every hour that we were there we knew that they were there too. Now beyond that they picked up our lunched, dinners, snacks, and even threw in 30 minutes of seated massage with the professional misuse. These gestures did a lot to keep the 12 hour days from becoming stressful, which would have been very easy.  

Agile methods were employed

in one way or another. It was not a proper Agile project but we had tasks, a burn down, standup meetings, and most importantly a time box of one week of which we all were made well aware. These key articles of Agile were the keys to any successes that week. Many to my team mates had never been on a proper Agile project. I do not think that anybody could deny the positive affect that they had even if they never credit it to Agile.

 

Lastly, sense of purpose

was the jet fuel that propelled most of us through the week. We were obviously convinced that the work that we were doing was going to affect the bottom line in more than a usual way. There was a sense of pride. 

 

This pace was astonishing though not as all sustainable.

By the final day of the week I did start to see cracks appear. Everybody on the team was obviously exhausted and creativity was starting to wane. The next week, (yes this one) seemed less productive then any before. This was not a bad exorcize though, we managed to build some strong relationships and get a lot of work done in a short time. I am not sure if I would recommend this as a way too save time because it seems like there will be more time lost as the team recovers their motivation and creativity. It is however a great way for a new team to gel.

Posted in Agile Development | No Comments »

RailsConf - the retrospective

Monday, June 2nd, 2008

This was my first year ever attending a conference so I have no frame of reference. I do know that I enjoyed just about every geeky moment. I was able to connect with other people who have been through or are going through a lot of the same things that I am in my career.

A major benefit for me

was that since I do not work at at company that uses Rails, so I am not immersed in the culture like other developers. I am surrounded by some of the most accomplished front-end engineers and I am thankful. My back-end technology of choice however, is Rails and at times I start to feel like it only exists in a lonely little world of my own. I try to make a point of listening to podcasts and reading blogs to keep me in the loop but there is obviously no feedback there. 

What stood out to me

was the after-party scene. Don’t get me wrong, I got a lot of inspiration out of the couple keynotes that I was able to catch but I would have come here just to meet the Rails heros. I am leaving Portland with so much inspiration to try some of the things that I learned.

The hard part

for me is that I am not a Rails developer at my “Day Job”. I have to go back and try to apply what I can to better my job as it stands. I am also, going to do everything that I can to do some Rails stuff on the side so that I don’t loose my momentum.

Posted in Inspiration | 4 Comments »