Nikolay Pavlov

The most interesting sight in Manhattan, New York - a street corner with no Starbucks…

Except for very rare cases, programmers always work with black boxes.  We rely on routines, libraries and frameworks, for which we usually know nothing but what the documentation says.  You have the OS, you have its API.  You may have a managed environment like Sun Java and Microsoft .NET Framework.  On top of that, you usually have a few frameworks and libraries.  The latter are likely to be white boxes, but are usually too intricate to easily trace issues inside.

These complex environments easily end up with various stability and performance-related issues for your applications.  Especially nasty are memory weaks, which are difficult, not to say impossible to trace and resolve.

Recently we had a strange experience with a project in Java.  The system was working quite properly for many weeks with good uptime, when the project was upgraded to Java 1.6.  After the upgrade performance would start declining after a few hours, the applications consuming all the memory available.  We spent days trying to find the weak spot in our code, but to no avail.  Then we reverted temporarily the project back to Java 1.5 and, what do you know, the problem was gone!  However, we had to use Java 1.6 for various purposes.

We ultimately came to a solution - servers, running our application, get restarted every couple of hours automatically, one by one, to ensure the availability of service.

This solution looks dirty, rude, and defies all good design and programming practices.  Unfortuantely, sometimes you cannot help it.  You cannot trace and fix a problem deep in Java’s runtime, or NET’s runtime, or one or another closed source library.

I myself felt quite uncomfortable with that solution, until I learned from a good source that the same practice is used by…  Google.  Yes, Google do restart their servers on a scheduled basis.

I am still not really happy with this approach, but knowing that the big and smart guys out there do it as well is at least some comfort.

Last week’s big news for me - Embarcadero Technologies acquired CodeGear (link).

The reaction CodeGear’s guys on their blogs is highly positive, and the insiders at CodeGear are really optimistic.  They feel that someone will finally start to care about the Development Tools division.  However, I am still anxious.

(more…)

One of these days a friend asked me over IM “why bother creating desktop applications, when you can do it as a web application”?  Then I avoided the question, knowing I can’t answer it in a single sentense.  The more I though of a short answer, the more I got myself weighing the pros and cos of the two, and finally the answer became - “because sometimes you have to.“  In this post I will share my reflections on the subject.

(more…)

Putting Data into the Clipboard

Putting data into the clipboard involves these few steps:

1. Open the clipboard.
2. Empty the clipboard - except for very rare cases, you would better delete what any previous application has put into the clipboard, and replace it with your content.
3. Register a custom clipboard format, if standard ones do not suit you well.
4. Put data into the clipboard.  Repeat steps 3 and 4 for every format you support.
5. Close the clipboard.

Steps 1 and 2 are really straightforward.  You call two API functions - OpenClipboard, and EmptyClipboard.  Registering a custom clipboard format is also a piece of cake.  Simply call RegisterClipboardFormat, pass it a name for it, and store the returned value for later use with SetClipboardData.  If you register a custom format with the same name more than once, the function will return the same value as previous calls - this enables applications to exchange data, as long as they use the same format names.

Putting data into the clipboard is easy if you use NET’s class Clipboard.  Anyway, lets see how it goes the hard way - useful for C++ and Delphi developers out there.

(more…)