Working with teams (programming ramblings)

When we added teams into TimeTracking.im at first, we didn't think it would be useful to have teams of only 1 user... so when a user subscribed to TT.im, he was not put in a new team. This proved to be a bad decision over time because it made the code too complicated for no good reason. For example, before making a call to a method we often had to check if the user was in a team or not. The morale of the story is that there is nothing wrong with having teams composed of a single user. This is how it works now in TimeTracking.im. From now on, everyone is in a team and it is much simpler this way.

Homepage redesign

I think that we redesigned the homepage a thousand times. Everytime, we tried to show everything we could to keep the user's attention and to convince him/her to subscribe. Now, we just don't want to pack the home page with useless stuff. 

I thought about this design yesterday before going to bed. I really like the sentence that described the product. I also wanted to focus on the "enter your IM address to register" so I made the design around these. 

In the old design, MSN and AIM alternatives were too big. We don't have many users using them but still, it took half the page. Plus, the GTalk icon was unclear, we had to add "or XMPP/Jabber" to make it clearer but even then, it was not that clear. The "OR add bot@timetracking.im" made the whole thing hard to understand. Everyone must have ask themselves "what should I do?".

The new design is simpler and more powerful. It says "this is what we do and this is how you register". We don't have any tour or video or anything. Maybe we'll add them, but without breaking the simplicity of the current page.

The next weeks will tell us if it's a good design or not.

(download)

Autumn cleaning

Yesterday, I did autumn cleaning of timetracking.im. In case you didn't know, autumn is the favorite season for developers to clean the mess they did all year long... or maybe it's just my favorite season to clean up... 

All the ruby, javascript and CSS is stripped to the bare minimum and we're getting ready to upgrade to RoR3 and to do the best out of what we have now. We probably won't add many new features but timetracking.im will do what it's doing now... just in a general better way.

Timezones are a pain in the butt

We, at timetracking.im, are tracking your time on IM. That requires us to work with the timezones quite a lot because when we are displaying a timesheet, we have to convert everything in your timezone.

The problem is that everybody hates setting his/her timezone. Most of the time, it's a long cryptic list of continent and/or country and/or city and/or a completely subjective name and/or an horrible abbreviation. That's why I worked 3:32 on sniffing the user's timezone on september 23 and 24. It was longer than I thought but I got it. 

So I tested it, it automatically detected the Atlantic time zone and we're close to the Atlantic ocean, that made sense. Until yesterday, when Frank told me that we're not in the Atlantic time zone but in the Eastern time zone. Because we were in daylight saving, it would detect me as a an hour earlier which resolved to Atlantic. I hate daylight saving.

Now, everything is resolved, I wrote some javascript that deals with time zones and daylight saving. Follow my javascript blog at javascriptkata.com if you're interested in knowing more, I will post more details about it.

I remember when I began my programming career, time zones didn't exist. In fact, they existed but we weren't aware of them. The only time zone that was important was the one of my building because my application would never reach the outside world...

Sharing timetracking.im with the world

Eventually, we want to add the possibility to share your timesheets with your clients. But before creating a tedious process for creating clients and assigning them the projects that they can see, we wanted to create a simple way of sharing. So, we decided to create public timesheets and to open timetracking.im to the world. After all, you are our clients (isn't that cute!).

Take a look at it : https://www.timetracking.im/public_sheets/days/projects/1320

Setup GoDaddy certificates with OpenFire

If you ended here via a search, you probably searched way too long for the secret of how to install a GoDaddy certificates on an OpenFire server. I hope this post will answer your question.

The secret is this :

  1. In the web console, go to: Server : Server Settings : Server Certificates
  2. Open your .key file and copy all the text contents (including the BEGIN and END CERTIFICATE markers). Paste the text into the "Content of Private Key File" box.
  3. Open your .crt file and copy all the text contents. Paste the text into the "Content of Certificate file" box.
  4. Open your gd_intermediate.crt file and copy all the text contents. Paste the text into the "Content of Certificate file" box immediately following the existing crt content.
  5. Click 'save'

The source is a hard to find thread on Ignite Realtime.

At first, we never thought that it would work but the guy sounded so confident that we couldn't not try it. We tried it and it worked!

You may also bump into the certificate signing request (CSR) problem. GoDaddy requires you to have a 2048 bytes key but the OpenFire creates a 1024 bytes key. If so, try to generate a 2048 bytes key like this :

keytool -genkey -alias mydomain.tld -keyalg RSA -keysize 2048 -keystore keystore.new

Check out the thread about it.

 

New sheets are now official

My previous posts talked about the new versions of timesheets that were coming and how incredible it would be. So, today is the day. It might not be a sunny day outside but it's sunny inside my heart. For the moment, I removed the export to text because we have to think of a better formatting before putting them back.

Moving tasks from one project to another

Even the best can make mistakes!

This morning, we tracked billable time in the wrong project (which is non-billable) without noticing after an hour. We had this time manually in the database. This is a situation that we encounter from time to time because we chose to use an instant-messaging interface instead of a cumbersome web interface.

In the next weeks, we'll develop a way to correct that kind of mistake from the web (it would be near impossible to understand a IM interface for this task). The problem is not coding it, it's creating the right interface for it. It doesn't happen often, so it have to be out of the way. But when it happens, you have to find and understand the functionality fast. That's the challenge. And there's a hundred more "utilitary" screens that we'll have to do without adding complexity to timetracking.im.