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!

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.

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.

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.

What I like about TeamCity: Pre-tested commit

I am one of the TeamCity developers so you can surely consider my opinion to be biased. But I am speaking here of a typical problems that any of you can experience and will try not to brag about my product too much ;-)

I'm a software developer. And though TeamCity is not an individual tool like IntelliJ IDEA, I'd like to present TeamCity features which ease my life as a software developer.

Pre-tested commit

In days before TeamCity, I used to write the following command line:

kir@work:~$ ant test && svn ci -m "FBQ-3324 fixed"

As you see, all I want is to ensure that my changes don't break tests and commit them the to version control afterwards. Usually, I wrote such a command once a day, right before going home.

Why I did so? Running the tests was a rather long process, because there were plenty integration and functional tests. And this situation is quite normal for non-pet projects. And still, I want to run all the tests to ensure that my changes won't break the build and the team is not affected by problems in my code.

Unfortunately, running a full suite of tests on the own machine is a luxury I can afford only when going home (or in the lunch time). Usually the computer load caused by running tests is pretty high and interrupts the productive development process.

Back to TeamCity. My current use case is as follows:

1. I do some modifications in the code, write more tests
   
2. I send the changelist to TeamCity and mark build configurations to be built with my changes. I also set checkbox "Commit if build successful" (see the illustration screenshot below)
   
3. I continue working with the code (edit same files, write more tests)
   
4. If TeamCity builds were successful, my IDE got the corresponding notification and my changes made in position 2 are sent to the version control. I continue working with the code, preparing for the new pre-tested commit.
   
5. If the TeamCity builds were unsuccessful, I get the information about failed tests, navigate to the failing stacktrace (all within IDE), and fix discovered problems. I.e. the build with my problematic code was run on TeamCity build agent and didn't affect the version control and my team mates' work.
   
6. The TeamCity build may be unsuccessful, but no new tests has failed (this information is also provided by TeamCity). In this case I may decide to force commit of my changes. I am on the safe side when doing that, because TeamCity IDE plugin remembers the state of my code when remote build was initiated.
   

So, as you can see, I am pretty confident that my changes won't break the build and the bad code won't go to the version control. And I like this.

What happens, when someone else commits changes and these changes conflict with mine? In such case, my commit will be rejected and IDE plugin will notify me about that. I'll have to update changed files from the version control and resolve the conflict manually - no unexpected magic here.

Please note, that TeamCity supports this scenario with different IDEs, including IntelliJ IDEA 6.0/7.0, Eclipse, and Visual Studio, with minor variations.

This feature is described on the JetBrains site in more detail, but may be it's better to try it and see for yourself.

Good luck and successful builds,
KIR