Nov 30, 2008

TeamCity 4.0 runs Checkvist's tests

I'm working on two projects: TeamCity - a rather popular continuous integration and build management server, and Checkvist - a simple and fast online outliner with task sharing and keyboard navigation.

I use Checkvist to plan my work on TeamCity, and recently I got a chance to use TeamCity to assist Checkvist development.

TeamCity recently reached its next milestone - 4.0 release. One of the interesting things it has is Rake build runner (so it can test Ruby and Rails projects).

You know, software must be tested before the release. So I tested this runner by creating a Checkvist build configuration in TeamCity. It happened to work so nice, that I couldn't resist to prepare a short and dirty demo

Definetely, I had to break some Checklist tests to demonstrate some cool TeamCity features :)




Aug 3, 2008

We named it Checkvist

We've finally decided to open public registration for our pet project.

This is an online task management service, similar to those already available on the Web (like RTM or todoist).

What's the difference? We're trying to make a tool which allows

  • Work fast. From the very beginning, we strive to provide usable keyboard navigation around checklists.
  • Work together. You can share a checklist, add comments to tasks, send notifications to your colleagues.
  • Brainstorm on large complicated tasks, splitting them into a hierarchy of subtasks.
  • Repeat activities. Sometimes you have to go through a checklist again and again (like when you publish a book or release another version of your software). You can create a checklist once and clone it when the work should be repeated.

Interested? Here it is: http://checkvist.com
Blog: http://checkvist.tumblr.com
Feedback forum: http://checkvist.uservoice.com

We like our tool, please try it, you might like it as well :)

Apr 28, 2008

TeamCity developer blog

TeamCity team has decided that it might be a good idea to have an own "unofficial" developer blog. It's a kind of experiment, because most developer's time is spent on, well, developing. But sometimes it is enticing to share some ideas, findings, tell about a feature which will be available in the next EAP build. And this stuff may be too "unofficial" and personal to go to the main product blog.

Anyway, this blog already has some interesting notes and I hope it will emerge over the time.

So, starting from this moment, I'm going to post TeamCity-related articles to developer blog (and even added it to my FriendFeed stuff).

BTW, on the home page of the blog there is a poll about which new SCM should be supported by the next version of TeamCity - Calcutta. Add your vote!

Apr 22, 2008

href value for javascript link anchor

If you create a link with javascript handler, and href attribute doesn't matter for you, do not use # as the value of the attribute. This results in page scrolling to the top of the page in MSIE.

Instead, use value like javascript:// - this is safe and most browsers will ignore it. And this is what you want when you have an onclick handler, isn't it?

Update: I was pointed out, that if javascript click event was cancelled in onclick handler (like Event.stop(e) in prototype), you can safely put # to the href, because default click behaviour will be disabled in this case. This works, but I still prefer to put javascript:// to the link href - IMO this reveals intentions more explicit.

Feb 24, 2008

Internet Explorer rendering problems or how to repaint Web-page

A short prelude.

I'm developing a small checklist application, to study ruby/rails and to play with various Web 2.0 UI patterns. And to get a tool which will help me to organize all my todos.

On the checklist screen I have, guess what - list of tasks, the checklist is comprised of. On some actions (like completing a task) the tasks are updated incrementally (with plain Javascript), on some actions (like undo) the list is reloaded as a whole.

Now the story.

To avoid task rendering in two places (on the server-side, when tasks are loaded from the server and on the client-side when they are updated in-place) I've used an approach when all rendering is performed by Javascript, even on the full page reload. This implies generation of the HTML on the browser-side and inserting the resulting HTML into the page in window.onload hook.

The problem was that in IE the inserted HTML was rendered like a total mess. Elements were painted one upon another, lost their position, styles.

As I found out later, the page resize fixes the rendering.

So I had to force a repaint of the inserted elements to fix the rendering.

The solution was simple. All I had to do was to add a fake CSS class to the inserted element and remove it afterwards (in fact, there is no strict need to remove the class). This operation forces an element restyling in IE and fixes its rendering. Looks like a hack, and it is.

By the way, moving task list rendering from the server side to browser gave me performance gain of 200% on the server.

Jan 12, 2008

TeamCity: immediate test failure notifications

This feature is particularly useful, if you have lengthy builds.

With most continuous integration tools, one have to wait until build is finished to get notified about test failure. TeamCity can send notification right after test failure, before build completion.

Scenario

  • Developer commits a change
  • Build is started
  • A test fails
    • Notification "Build is failing" is sent to the developer and to other subscribers via configured notifiers
    • Test failure details immediately appear in the Web UI
    • Clickable stacktrace on the Web page allows to open the test and the stacktrace in IDE
    • Developer can see if this test failed in the previous build


  • If the fix is simple, developer commits the fix even before original build has finished.
  • Optionally, developer may stop the original build to free the build agent.
  • Otherwise the original build finishes (possibly with other test failures).
  • TeamCity sends notification about build completion and its results.
According to this scenario, it may take a little time between problem detection and the fix, and the same little time the broken code will stay in the version control system. And this is a Good Thing, and I like this.

You can read more about this and other features on the official TeamCity site.

Good builds in new year,

KIR

BTW, in the previous post I described how to avoid broken code in version control at all.