Virtual Hosts and HTTPs

Using name-based virtual hosts on a secured connection can be problematic. This is a design limitation of the SSL protocol itself. The SSL handshake, where the client browser accepts the server certificate, must occur before the HTTP request is accessed. As a result, the request information containing the virtual host name cannot be determined prior to authentication, and it is therefore not possible to assign multiple certificates to a single IP address. If all virtual hosts on a single IP address need to authenticate against the same certificate, the addition of multiple virtual hosts should not interfere with normal SSL operations on the server. Be aware, however, that most client browsers will compare the server's domain name against the domain name listed in the certificate, if any (applicable primarily to official, CA-signed certificates). If the domain names do not match, these browsers will display a warning to the client user. In general, only address-based virtual hosts are commonly used with SSL in a production environment.

© Tomcat 6 SSL howto

Programmer Flavors

My father built custom homes, and in my youth I would occasionally work for him, mostly doing grunt labor and sometimes hanging sheet rock. He and his lead carpenter would tell me that they gave me these jobs for my own good -- so that I wouldn't go into the business. It worked.
So I can also use the analogy that building software is like building a house. We don't refer to everyone who works on a house as if they were exactly the same. There are concrete masons, roofers, plumbers, electricians, sheet rockers, plasterers, tile setters, laborers, rough carpenters, finish carpenters, and of course, general contractors. Each of these requires a different set of skills, which requires a different amount of time and effort to acquire. House-building is also subject to boom and bust cycles, like programming. If you want to get in quick, you might take a job as a laborer or a sheet rocker, where you can start getting paid without much of a learning curve. As long as demand is strong, you have steady work, and your pay might even go up if there aren't enough people to do the work. But as soon as there's a downturn, carpenters and even the general contractor can hang the sheet rock themselves.

© Bruce Eckel; A Career in Computing

J2SE applets stability

Not so long time ago I was doing some research into spurious firefox hangs occuring on applet loading. Looks like sometimes SUN tries to sweep a problem under the carpet. Or even worse - they attempt to patch their way out.

None of these approaches work - as you get either "slightly dysfunctional" components or nasty quantum regressions.

As for the carpet - some of the tickets below are "not reproducible", despite the fact that people are reproducing that massively across multiple bugzillas. See comments for the mojebanka.cz ticket and the last ubuntu ticket too. Also - there're couple of tough tickets with massive votes which once disappeared from public bugzilla - I had a bookmark on that somewhere.

So, for those who firmly believe applets are stable and well-established piece of technology, here goes some plain data (somewhat biased - as this is a bugzilla anyway). Second line is version with delivered fix:

• New plugin applet freezes the browser occasionally 6u10(b21)
• FF3 browser hangs while loading atomica and rocketmania applets from popcap.com 11-Closed, Not Reproducible, bug
• Firefox hang upon first applet launch with Windows OEM builds of Java 6u7(b01)
• Firefox with JDK 6 will cause the browser to hang 6u10(b02)
• Plugin2: Applet from www.mojebanka.cz causes FF3 to hang 11-Closed, Not Reproducible, bug
• Malformed 404s cause breakage of Java/JavaScript bridge and browser hangs 6u11(b03)
• Java Plugin in Firefox hangs since 6u4 when remote policy file is present in java.security 6u10(b26), 6u7-rev(b07)
• If <object> tag is malformed, FF browser either crashes or hangs. 6u10(b07)
• The old plugin hangs firefox 3 when loading java applets That's quite recent Ubuntu bug, not fixed still, affects 8.10 users, 8.04 works fine

Well, actually, I don't think that applets are completely not feasible, but the browser/applet bridging seems to be somewhat shaky. My opinion is that applets are the most pluggable, secure and functional approach, at least for some of possible usage scenarios.

SUN : Cloudy times

Use the cloud, build the cloud, be the cloud.

via Cloud Computing Demystified

Open/Closed Principle : Strategic Closure

It should be clear that no significant program can be 100% closed. For example, consider what would happen to the DrawAllShapes function from Listing 2 if we decided that all Circles should be drawn before any Squares. The DrawAllShapes function is not closed against a change like this. In general, no matter how “closed” a module is, there will always be some kind of change against which it is not closed. Since closure cannot be complete, it must be strategic. That is, the designer must choose the kinds of changes against which to close his design. This takes a certain amount of prescience derived from experience. The experienced designer knows the users and the industry well enough to judge the probability of different kinds of changes. He then makes sure that the open-closed principle is invoked for the most probable changes.

© Robert Martin; The Open-Closed Principle;

ScheduledThreadPoolExecutor : gotcha

This code

final int period = 1000 /*millis*/;
final int delay = 10 /*millis*/;
final int num = 20;

ScheduledExecutorService ses = 
    Executors.newScheduledThreadPool(4);

for (int i = 0; i < num; i++) {
  ses.scheduleWithFixedDelay(

    new Runnable() {
      public void run() {
        try {
          Thread.sleep(num * 1000 - 10);
        } catch (InterruptedException ie) {
          throw new RuntimeException(ie);
        }
        System.out.println("tick: " + System.currentTimeMillis());
      }
    },

    i * period, delay, TimeUnit.MILLISECONDS
  );
}

Thread.sleep(Integer.MAX_VALUE);

should produce 20 tasks which in total would tick once a second. But nope. You would get only 4 tasks, as corePoolSize does not expand if pool is unable to handle all scheduled tasks. The actual output would be something like:

tick: 1235810468265
tick: 1235810469237
tick: 1235810470278
tick: 1235810471280
tick: 1235810488274
tick: 1235810489236
tick: 1235810490277
tick: 1235810491299

The only hint for this is left in the javadocs for the ScheduledThreadPoolExecutor:

While this class inherits from ThreadPoolExecutor, a few of the inherited tuning methods are not useful for it. In particular, because it acts as a fixed-sized pool using corePoolSize threads and an unbounded queue, adjustments to maximumPoolSize have no useful effect.

Design Pattern : Good Citizen

Imagine a software system where there is no need for you to spend your time programming defensively; your objects will be used responsibly, and your methods will always be passed sensible arguments. This low-friction utopia can be approached by establishing some simple programming rules so that every class acts as a 'good citizen' in the society of classes collaborating at runtime. This page outlines some rules that we, and others, believe lead to good citizenship. All are aimed at improving clarity, reducing surprise, and promoting basic consistency. As a good citizen, I...

• Keep a consistent state at all times - init() or populate() is a code smell.
• Have no static fields or methods
• Never expect or return null.
• Fail fast - even when constructing.
• Am Easy to test- all dependent object I use can be passed to me, often in my constructor (typically as Mock Objects).
• Accept dependent object that can easily be substituted with Mock Objects (I don't use Concrete Class Dependency).
• Chain multiple constructors to a common place (using this(...)).
• Always define hashCode() alongside equals()
• Prefer immutable value objects that I can easily throw away.
• Have a special value for 'nothing' - e.g. Collections.EMPTY_SET.
• Raise checked exceptions when the caller asked for something unreasonable - e.g. open a non-existant file.
• Raise unchecked exceptions when I can't do something reasonable that the caller asked of me - e.g. disk error when reading from an opened file.
• Only catch exceptions that can be handled fully.
• Only log information that someone needs to see.

© Dan North, Aslak Hellesoy; found at PicoContainer Design Patterns