iFeel a little better about my Phone

July 14th, 2008

Okay, day three playing with my new iPhone 2.0 software and I can say that this is ALMOST better then my iPhone 1.1.4 that was jailbroken. The only missing piece is my Last-FM Audio Scrobbler Plug-in for iPod. They did release a Last-FM app, but were unable to include the Scrobbling of iPod songs yet. Getting that out of the way, here are the new apps that I have grown to love (in order):

  1. Todo - took me a while to find it, but it syncs with Remember The Milk. Finally, I can have my list wherever I go, even if there is no internet connection. For instance, my Trader Joe’s as is in a dead zone for AT&T. I forgot the milk more then a few times.
  2. Mobile Flickr - There are a few Flickr Apps available and some for free, but this one is a bit more polished and lets you upload.
  3. MotoRacer - This is a fun game. I was dyeing to try a game that used the entire phone as to steer. That is just cool.
  4. Pandora Radio - Solid app. Works over EDGE very well.
  5. midome - This will guess a song that you hum. Yes Really! This is not very useful for me as is does not work for a lot of the obscure music that I like, but it is cool nothing the less. It guessed “Bullet With Butterfly Wings” from “Smashing Pumpkins” on the first try.
  6. FileMagnet - Will transfer and show a variety of file types. So far I have tried png images and pdf files. Simple and elegant interface.
I my neck hurts from looking down at this phone all weekend but I have not been able to stop myself. I am not sure if I feel compelled to get the 3G iPhone with all of these new features to play with. Maybe I will wait for the next big breakthrough. More battery life? Edible case? Who knows.

iFumble

July 11th, 2008

Well… I am one of the thousands holding a useless iPhone today. At 6:20 am PST, I started the the slow upgrade. I went through a download, backup, 3 restarts, and a restore. Then after all of that, in the process of activating, I get a long “Accessing iTunes Store” wait.

Accessing iTunes Store

This goes on for 20 or so minutes, in which time, I decided to check to see if MobileMe was up… OOps, looks like that is down too:

MobileMe is down

Then, iTunes finally gives me an error message:

iTunes Error -2

I am not exactly going to sell my stock now but this will not be good marketing. Apple is trying to break into the enterprise market and I think this will make I.T. departments think twice. From reports that I have seen this is effecting both 3G users and EDGE users that are upgrading around the world. My Advice… WAIT.

You only get two

July 9th, 2008

In web app development, as in anything else you have to have a balanced set of requirements. As the business folk have always said: “Cost, Quality, and Speed - You only get two”. It just seems to work out that way. Now for us in web development we have a different three to choose from: Speed of development, speed of served product, and flexibility of design. Each needs attention, but too much attention too one will deplete the others and lead to a poor product. Lets inspect each:

Speed of development

An app can not be built in a day, but it should be built in a few months. By the time an app gets through design, development, and testing a lot of things can change. I don’t know anybody who has worked on a long or short term project that did not have one or two requirement changes after development had begun. This is why we use Scrum right? Obviously if the reality is that requirements will be added during development, it makes a lot of sense that the longer you are developing, the more last minute changes you will do. However, if you are able to cut the development time, it is easier to convince the business that their super important icon color change can go out in the next sprint.

Speed of served product

Does it scale they will all say. Will your app be fast enough and your servers be strong enough to handle a lot of users and / or slow clients. Some argue that Frameworks that make development easier are less flexible and harder to scale. To be completely honest they are right but it is important to measure each and decide if some sort of balance could benefit you more or at least break even.

Flexibility of design

It is important for the app to be flexible enough to meet user needs and have an enticing interface. This one is interesting because not too long ago I would have counted this as one of the two most important along with speed to develop. That is until just before I started to get inspired to write my post “SproutCore is a chainsaw and YUI is a paring knife“. That is when I realized that a Web App is quite different from a web site and really should follow more closely the rules of a desktop app. In desktop apps we are better off using common OS interface elements that people have grown accustomed too.

Which two do I choose

As you may conclude from the last paragraph, it depends on wether it is a web app or a web site. For a web app, I would choose speed of development and speed of served product as these tend to have a need to make it too market as a complete finished product in a short time-frame and rely on the back-end heavily to process data. Also, consider this quote from UPA – ”Consistency is one of the most important aspects of a repeatable user experience. If users know what to expect, it will be easier for them to build a conceptual map of what should happen next“. On the other hand a web site has a different purpose and I would trade speed of served product for flexibility of design as the idea is to entice users to enter and look around.

JavaScript Developer, the ingredient list

July 3rd, 2008

I was asked to list some qualities that one should look for in a good front-end engineer. Here is my list:

I wonder why it is so difficult to find all of these qualities in one developer. It seems like focusing on these areas would be smart for anybody who wants to work as a JavaScript Developer.

Apache on iPhone - Some real Jack Bower Sh&%

July 2nd, 2008

This morning on the train, I started to browse through the Jail Broken installer app, on my iPhone. In the past months I have installed a lot of cool little tools that have really integrated themselves into my life. LastFm, Locate Me, and SSH to name a few. I have passed over the Apache server every time, failing to see why somebody would need one on their phone. This morning it hit me–Freelance web designers! WOW! think about it. A designer is so vulnerable to having their designs ripped off when they make them available to show to a client. Now imagine instead that designer were to host the site from their iPhone and connect to the client’s network. For a controlled amount of time the developer would be able to show the design to the client and let them interact with all of the features. This is way better then watermarking a PNG file.

SproutCore is a chainsaw and YUI is a paring knife

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.

Thinking beyond Web 2.0

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.



 

The Afterburners

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.

RailsConf - the retrospective

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.

Serendipitized

May 28th, 2008

One year ago…

I was working in a relatively small engineering group in a company where I had tons of creative control over my work and made crap money. Now, I work in a massive nationwide engineering group where my opinion makes a difference locally but inevitably ends up getting lost in the shuffle when up against the sexier, higher profile projects in the company. Add the fact that my desk was in front of a huge window with a view of mountains and is now a panoramic of three cloth walls and the most intense office lighting. I started to feel that i was hemorrhaging all of my creative energy.

As a first attempt to solve the problem,

I started working out ways to work from home. This helped a bit but not for too long. Turns out I can’t stand being alone for too long. I had no idea how much I needed the action of the office. I also like the 3:00 pm coffee banter. 

Okay, so it looks like I need more ideas.

Then it happened…

At the worst of my inspiration slump, I decided to take on a few extra credit tasks around the project. One constant throughout my career is that in every job I start a side project. Somehow that project manages to play a major part in my next career move.

Giving it some thought it makes sense:

Side projects are not controlled by the business. It seems without the influence of product managers I am left with full creative control. 

Disclaimer: I am by no means diminishing the contribution of Product Management. I just think it is useful for a developer to have some sort of skunkworks project where he/she is not regulated by our level headed friends. This is why we have hackdays, I am just not that competitive.

My little contribution is a useful little piece of code that everybody needs and nobody had time to do. I am proud of the results and I am seeing the effects in a lot of ways.

See more posts from Eric Gelinas on blog.standardpixel.com