Wrong.

It is true that if you have a single object that is synchronized in every request, locking that object will severely impact performance when concurrency goes up. However, you should analyze the actual usage pattern and data structures to determine the actual contention.

For instance, suppose you are writing a messaging application, where clients write and read from their respective inboxes. The application as a whole is meant to support 10,000s concurrent clients. The supported operations are writing an object to someone’s inbox, reading objects from a specific inbox, and subscribing to notifications. With this performance profile, it’s seems like a good idea to make the global data structure that maps client’s IDs to inboxes lock-free, otherwise concurrent searches to find a specific inbox will block one another.

However, if any specific inbox is not meant to carry a significant load, there is no harm in implementing the Inbox data structure (that is responsible for one specific Inbox/Message Queue) without restricting yourself to lock-free data structures. Locking when there is no contention is not an expensive operation!

Writing and using lock-free structures is usually harder than locking, except for simple scenarios. In order to maintain class invariants between the different data structures you use, sometimes a lock is simple and effective. You should be familiar with your language’s lock-free options, but don’t be swayed by the hype and “coolness” of lock-freedom, and use it when it’s actually required or where it saves you code. If it complicates your design, try to defer it until you’re convinced you actually need it.

Related posts:

1. Don’t switch your lock object mid-lock
2. Never use synchronized methods or lock on this
3. Playing with a few ReaderWriterLocks in .Net

No related posts.

This process helps us stabilize versions within a matter of days and proceed quickly from trunk to QA to Production.

A problem we experienced with this process was it was hard to make sure all bugfixes were properly merged to trunk. The commonplace practice is to merge all changes from the version branch to trunk at the end of the release cycle (when the version is “frozen”).

There are at least two problems with this approach:

• First, it is usually one person who is left the ugly task of doing the merge of all these bugfixes that weren’t previously merged, usually in files he didn’t touch and knows nothing about.
• Second, if there are bugfixes on the version branch after the version is frozen, what is to guarantee they will reach trunk? The sad answer  is “nothing” – we had several regression bugs because people forgot to merge their bugfixes).

Here is our NewAndImprovedProcess™ (as implemented by our very own Sergey Goncharov):

We setup a TeamCity build that monitors all version branches. It runs nightly, and examines the mergeinfo SVN property on all modified files. If it detects files that were committed to the version branch but weren’t merged to trunk, it fails and send an email to the responsible developer. A little convenience feature we sprinkled in was that if you have a change set that you really don’t want to merge to trunk, you can write in the commit note “[NO MERGE]” and the build will ignore this commit (you can also do a ‘recorded merge’, which is the proper SVN way of doing it, although  adding the commit note is faster in a quick-and-dirty way).

Related posts:

1. Some More on TeamCity
2. Knuth and The City (TeamCity!)
3. This comes BEFORE your business logic!

The code is hosted at Github, and the issue list at Google Code. Also, note that there is a guest account if you want to play with the system (Thanks Anna for the idea).

We currently have 100% user satisfaction, which is to say that Aya (my fiancé, and the one user whom Kuzando was tailored for) is actively using it to plan her schedule at the lab. You’re invited to do the same – if there are some missing features that would make your usage of Kuzando more pleasant, let me know.

Related posts:

1. A survey of open APIs
2. Disable Resharper C# 3 syntax
3. Cancelor – a java task cancelation service

Related posts:

1. Rise of Eldrazi draft walkthrough
2. Magic draft walkthrough creator
3. Another draft walkthrough, 4-color Alara

Wrong.

Over the years, I have discovered that effective communication is at least as important, if not more, than the more technical aspects of a programmer’s work (this might be true for other fields, but I can’t really comment about that).

Interpersonal – Top on this list is “being a good and friendly person”. We spend most of our waking hours at work, and progressively fewer of this time is spent on the computer coding. Therefore, you want the people you work with to be … the sort of people you’d like to spend time with (a little self-defining here, but still). Working with someone who’s rude, inconsiderate, or just plain not nice can make the best workplace in the world into the worst.

Responsibility - people you work with, whether team mates, managers or other colleagues, are all a key instrument to your success at your own tasks. Today’s high tech company is a highly chaotic and fast paced environment, in which you are rarely working on some research project all alone in your basement. More often, you are cooperating with other people to create something larger, starting from product managers, tech leads, QA, managers and support. You depend on them for the successful delivery of your work. There’s nothing more annoying than not being able to finish a feature just because some crucial link in this chain neglected his responsibilities.

Email/Face to Face – At most modern organizations, you send and receive dozens of emails every day. Email is very convenient – you can send it without ever leaving your desktop, it’s saved and archived and you use it to reach several people at once. It is also a trap. Some things are better not handled through email or Skype! I cannot stress this issue enough. Countless time have I seen an important process stuck because it was handled via email, and the sender wrongfully assumed that this was enough to make the recipient take the required actions.

When you have something urgent or important, it’s most effective to accompany or replace the email with a face to face conversation. Sometimes all you need to say is “I’ve sent you an email about yada yada, please see the details there because I need it for this and that”. This helps focus the recipient and ensures he’ll take the necessary actions. Another point worth saying about email, is that you should adjust the form of communication to your recipient. Some people can be counted on to reply to most emails within an hour, and to never skip an important email, while others must be ‘nagged’ to repeatedly. If you use Outlook, you should use its reminder system to make sure the emails that are important to you (both outgoing and incoming) get handled.

Avoid long email threads and large recipient lists at any cost! These can serve as announcements, but as soon as such emails turn to discussions, people just tune out and the thread becomes an exercise in uselessness. Identify these wasted keystrokes and instead solve the issues by talking to the key people. If the other party tries to continue a useless email thread, just reply “I’d rather discuss this face to face, it’ll be shorter” for all of us.

When I was young, nobody told me programming was a “people profession”, but the truth is that it really is. What is your opinion?

Related posts:

1. Welcome
2. Reminder – Email Subscritpion
3. I Don’t Like Google Today

1. Cut some cucumbers, pepper and tomatoes (either normal or Sherry).
2. Pick some of your favorite cheeses. We used Merlot, Massdam, Mozzarella and Tsfatit, but you can use any. Cut down to small cubes.
3. Add some pumpkin & caraway seeds to make it more interesting.
4. Add olive oil and lemon juice in generous portions.
5. Spice it up – salt, four seasons pepper, Marjoram and Za’tar.

And voilà:

No related posts.

import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.util.zip.ZipEntry;
import java.util.zip.ZipFile;
 
/**
 * Loads classes from war files. See http://www2.java.net/blog/2008/07/25/how-load-classes-jar-or-zip
 */
public final class WarClassLoader extends ClassLoader {
    private final ZipFile file;
 
    public WarClassLoader(String filename) throws IOException {
        this.file = new ZipFile(filename);
    }
 
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        ZipEntry entry = this.file.getEntry("WEB-INF/classes/" + name.replace('.', '/') + ".class");
        if (entry == null) {
            throw new ClassNotFoundException(name);
        }
        try {
            byte[] array = new byte[1024];
            InputStream in = this.file.getInputStream(entry);
            ByteArrayOutputStream out = new ByteArrayOutputStream(array.length);
            int length = in.read(array);
            while (length > 0) {
                out.write(array, 0, length);
                length = in.read(array);
            }
            return defineClass(name, out.toByteArray(), 0, out.size());
        }
        catch (IOException exception) {
            throw new ClassNotFoundException(name, exception);
        }
    }
}

Two notes:

1. This code isn’t really production grade, as the streams aren’t closed and whatnot
2. It is missing one critical addition – if the classes in the war depend on the jars that are included within it, this class loader will not be able to load these classes. I managed to work around the problem because I already had all those jars in my classpath anyway, but in principle the code above needs a bit of extension to be able to work with the embedded jars.

Related posts:

1. Don’t switch your lock object mid-lock
2. Unhandled Exceptions Crash .NET Threads
3. Cancelor – a java task cancelation service

We are still in “closed beta”, which means you need an invite to get in (but can then forward invites to your friends).
If you want one, drop me a line with your email.

Big big thanks to everyone in our team for making it happen!

Related posts:

1. Delver Beta Invites
2. Delving Blogs
3. Delver is Online

Related posts:

1. My favorite Stacks
2. StackOverflow Overflow
3. We Finally Found An Apartment!