Snob overflow . . .

Okay, another one of my many pet peeves. When people ask questions to Stack Overflow, the community often incorrectly assumes that you are too stupid to ask a real question and instead talks down to you and won't give a straight answer, even if there is one.

Here is a case-in-point: how-to-release-all-permits-for-a-java-semaphore

The question was immediately met with contempt: "What do you need this piece of code for?". This question was not asked for clarification, but so that the discussion could go in a completely different direction. The Stack Overflow moderators are such Nazis about intervening: "This is not a question!", "This is a survey!", "These are opinions!", "This is a duplicate!" - that I am surprised they don't get upset in this situation, because you have a clear question posed, and the selected answer goes in a completely different direction. Rather than answering the question "How to release all permits for a Java Semaphore", they answered the question "How do I better design my code to keep my thread pool in sync?"

The simple answer is:

semaphore.drainPermits();
semaphore.release(totalNumPermits);

Again, whether that discussion is valuable or not, it does not answer the very straightforward question that was asked.

Sonic, What's up with your foam cups??

I have been noticing for the past few months that my Route 44 styrofoam cups from Sonic in OKC have the annoying 'feature' that they leak through the pores in the foam. I have noticed this many times - and is it ever annoying. Here is a sample from the cup I am using right now. This cup is probably two or three days old, picked up at the Bricktown Sonic:

Those little drops look like normal condensation, but they are actually water escaping through the cup. I have to keep a paper towel under my drink at all times or else my desk will be all wet. In years past I could keep the cups for a long time and this would not happen. Very strange and not a little annoying.

Java Synchronization. What's the big deal?

Throughout my career as a Java developer, I have read a non-trivial amount of code related to minimizing the impact of synchronized code blocks.  The topic of thread safety is extremely complex, and must be embarked upon carefully.  In some cases, just declaring lack of thread safety can simplify a project immensely, E.G., java swing, but there are times when it can't be avoided without introducing a lot of complexity on the other side of the API.  That's not what I am referring to, however.  Consider double-checked locking.  This technique is often used simply to reduce the amount of time it takes to call an accessor.  To illustrate, I wrote the following chunk of code:

import java.math.BigDecimal;
public class Main {
 public static final long TEST_COUNT = 1000000000L;
 public static void main(String[] args) {
 long r = 0;
 long startSync = System.currentTimeMillis();
 for (long i = 0; i < TEST_COUNT; i++)
 {
 r += getSync();
 }
 long stopSync = System.currentTimeMillis();
 long startUnsync = System.currentTimeMillis();
 for (long i = 0; i < TEST_COUNT; i++)
 {
 r += getUnSynch();
 }
 long stopUnsync = System.currentTimeMillis();
 BigDecimal syncTotal = new BigDecimal(stopSync - startSync);
 System.out.println("Sync took (" + syncTotal + ") ms., or (" + (syncTotal.divide(new BigDecimal(TEST_COUNT)).multiply(new BigDecimal(1000))) + ") microseconds average.");
 BigDecimal unsyncTotal = new BigDecimal(stopUnsync - startUnsync);
 System.out.println("Unsync took (" + unsyncTotal + ") ms., or (" + (unsyncTotal.divide(new BigDecimal(TEST_COUNT)).multiply(new BigDecimal(1000))) + ") microseconds average.");
 }
 private static synchronized long getSync()
 {
 return System.currentTimeMillis() % 100L;
 }
 private static long getUnSynch()
 {
 return System.currentTimeMillis() % 100L;
 }
}

When I ran it, this was my output:
Sync took (98345) ms., or (0.098345000) microseconds average.
Unsync took (43530) ms., or (0.04353000) microseconds average.

The difference here is 50 or so nanoseconds per access. Unless you are writing a high-performance application like a 3D game or database, I just don't see how this can even be worth discussing. Almost every application I write would involve calling these accessors on creation, which means 40 or 50 times during an entire application life, or even if it is tied to user requests like in a service or web application, 50 microseconds per request will be dwarfed by the amount of time the request itself takes. If there is a database access, just opening a connection that takes 1 millisecond to open will be 20,000 times slower than a synchronized accessor.

As engineers we sometimes like to focus on the really fun stuff, like generated bytecode or network packets or even CPU states, but synchronization overhead doesn't even seem like it's worth the time to type out.

PS: Have I said how much I hate the blogger editor???

Star(schema) Commander, Iteration 4

So, thus far I have added groupings, aggregates and degenerate dimensions to the core, and I have added references to JxBrowser which added 200MB to the project. :(

The UI for the data explorer is challenging.  I don't want to spend the rest of my life on it but I also don't want to produce an ugly piece of crap reminiscent of old Linux Motif/Tcl/Tk apps.  The Java UI is much more limiting than I remembered - most new gestures aren't accounted for, even in the newest stuff.  Maybe JavaFX?

Star(schema) Commander, Iteration 3

So much for micro releases.  :|

So far I have experienced a few interesting things:

• Micro releases are not that satisfying when doing initial development - especially across three interconnected projects - core, cli and gui libraries.
• Unit testing user interfaces really sucks.  I tried to find something but no solution seems to be around for very long.  In the end I created my own UI framework based on standalone components and messaging which made testing very easy and meant the runtime app just had to wire them together properly.  It also achieved a nice encapsulation of the different UI parts.
• It is WAY too easy to get stuck testing every detail in a UI and it can eat up a LOT of time because everything you have to do is a new one-off.
• The internet is not very helpful on the issue of user interface testing.  If I have to read another lecture about separation of responsibility and how you should test the domain layer, not the UI objects, blah blah barf, I will delete the internet.  Guess what, people? User interfaces have requirements as well and those must be tested with the same level of reliability as other parts.
• When testing a user interface, there is a lot you have to let go.  Unit testing Java code can be very granular and specific, but if you try that in a user interface it will be a train-wreck.  E.G., if a table has headers that read "Name", and "Schema", testing those is going to add more semi-useless tests and will make any change to the UI break way too many tests.  Besides which I would like to refactor my UI (changing lists to tables, etc) without extra tests breaking.
• I did manage to temper my desire to create the perfect user interface library.  I simply created what I needed and refactored as I realized that I needed more functionality.  There is a word for that but it escapes me at the moment (and most other times) ;)  . . .
• I am toying with the idea of rewriting my UI using JxBrowser - a Java library for using an embedded Chromium container.  My Java desktop apps look so crappy and take so much work to wire together and are therefore resistant to change, and HTML makes a nice container for UI code - as compared to Java code.  I am concerned about the extreme commercial nature of the project - $1600 per license minimum; I don't know what they think they are providing that is worth that price - even if I do have a free open source license at my disposal.

YAJUEHP - Yet Another JUnit Exception-Handling Post . . . *yawn*

I can't imagine anyone will find this useful when it is so tiresome to me, but after a jaunt in UI Testing purgatory I had to go back and test some plain old library code, but this time with a new twist.  I have been using the rather awesome ExpectedException class with nice results.  The Code Under Test in this case, however, threw InvocationTargetException's with wrapped cause's which made that approach too brittle.  I found this nice post about it which solved my issue:

JUNIT EXPECTEDEXCEPTION RULE: BEYOND BASICS

Toward the bottom there is a nice discussion of verifying causes.  I found another article he wrote comparing various exception strategies in JUnit here:

6 WAYS OF HANDLING EXCEPTIONS IN JUNIT. WHICH ONE TO CHOOSE?

I thought these were pretty handy - hopefully someone else will as well.

Star(schema) Commander, Iteration 2

I got version 1.1 and 1.2 out in the same night.  I have dimensions and reporting areas, and a mechanism to import dimensions from a database.  Not too useful yet, but facts are coming.