Wednesday, December 5, 2012

Specifing arrays size/capacity - my latest buggy code and a bestpractice

 
We're often required to specify size/capacity when allocating array like structures.

While you MUST specify size for Java's primitive arrays. With realizable arrays like ArrayList/Vector, specifying #capacity is too often a #premature-optimization, that you could avoid.




happened to introduce a bug to our code base, by initialized an ArrayList with a negative capacity value:

List<RetrievedDocument> docs =  new ArrayList<RetrievedDocument>(scoreDocs.length - resultsOffset);

Performing such profanity results in an #IAE being thrown (triggered by a NegativeArraySizeException thrown by the underlying primitive array structure.
public ArrayList(int capacity) {
firstIndex = lastIndex = 0;
try {
array = newElementArray(capacity);
} catch (NegativeArraySizeException e) {
throw new IllegalArgumentException();
}
}

Lesson for the next 50 years (or until I switch off from Java):

Whenever setting the size of an array (or anything sizable) to an unknown ahead value, spend a second to consider whether the value could be negative.
Then, if the desired resulting behavior is to create a zero-sized array instead, use this one-liner for that:
new ArrayList( Math.max(0, possiblyNegativeCapacity) );
Q: Do you know if other languages makes the use case above easier/less error prone?

Q: Any other related best practices and pitfalls you would like to share?

Sunday, August 26, 2012

Cleaner code with Apache Commons

It seems I can no longer write any piece of code without including the Apache Commons libraries.
They just contain everything that the ancient architects of the Java language forgot to include in the java.* APIs; Commons save huge amounts of coding debugging time, by capturing ever repeating patterns, allowing effective reuse which results helps with clean code.

Tuesday, November 29, 2011

HPEL - A fast binary logging for WebSphere v8

Troubleshooting Java EE apps running on WebSphere just got a bit easier with WebSphere v8's new binary logging and tracing mechanism: HPEL (High Performance Extensible Logging).
HPEL provides logging/tracing run-time performance boost (x3.5-x5 claimed) increasing the chances that you'll be able to turn on tracing on a production system.
HPEL comes with two offline viewing tools: A crafty command-line tool for log analysis, and a web based traces viewer on the Web admin console (handy for remote servers).

The command line utility has a tail function and can filter by: Logger/Thread ID/Time/Server startup instance/etc. Which is a good enough reason for me to get rid of my (slow performing) custom Python based filtering scripts.

Good old legacy text based logs are still supported but are recommended for development mode only.

Tuesday, April 5, 2011

10 things I like about Android development


  1. Java - Write in Java on both the Client and Server sides. Simplifies development and presents a low learning curve for newcomers.

  2. Paid apps culture - Unlike when using web apps, mobile app users we're tamed to pay for the apps they like (Thank you Apple for cracking the ice). Developing for Android might be the first time that you'll sell a piece of software directly to your users (it is my first time, and I've been programming since 1996).

  3. TTD - When creating a new Android Eclipse project it auto suggest to create matching test project. Proves to show that the Eclipse perspective designer had TTD in mind.

  4. API Demos - Good samples project to copy code segments from. Bundled with the SDK.

  5. No single point of entry - No single main() function. Your application can have multiple entry points (Activities), which can be used to service the user's Intents. Different from what I'm used to.

  6. Construct UI using XML - specifying UI elements using a markup language makes more sense than doing it programmatically (attention Swing).

  7. Multiple App markets - More choices for us developers.

  8. Coping with multiple device resolutions - using density independent pixels worked well for my modest needs.

  9. App Inventor - Ridiculously easy to build your first app. Go try it.

  10. What's your 10th? Comment if you have one.


My first App:


My first app is the Weight Watchers Points Tracker (diet related), that I've initially created for my own usage, then later posted to the Android Market. Surprisingly it has been doing pretty good (>10K installations). I'll need to see what comes next...

Friday, March 25, 2011

Spice up your tests - execute in (repeatable) random order

We have a series of SIPp tests that periodically runs against a SIP server we develop. The tests repository keeps on growing and we've gathered up a nice pile of tests.

As good tests should be isolated from one another, their order of execution is arbitrary by definition. The tests should produce the same results consistently regardless of where they are located in the execution chain. I thought I might take this to the test, and perhaps find a bug or two along the way.
Working in Python, I now simply shuffle the list of tests prior to execution:

random.shuffle(testList)
executor.exec(testList)


Nice. Now what happens if a certain execution order fails? I would find the issue and fix it, what else?! Right, but how will I reproduce the same exact execution order that failed before, in order to validate the fix?
One naive option is saving the entire execution order as a list of indices, this is not very comfortable. A simpler option is to simply seed your random object with the same seed int value used during the execution to reproduce. Here's the code:

import random
seedValue = options.get('shuffleSeed', random.randint(0, 10000)) # Seed is provided by the user in an attempt to reproduce, otherwise it's set to some random value.
random.seed(seedValue)
random.shuffle(testList)
print 'Shuffled with seed=' + str(seedValue)
executor.exec(testList)


Thursday, September 23, 2010

Case insensitive Map key - code smell

Here's the bug that had me working today (a Sukot holiday):

_myMap.put(key.toLowerCase())
...
_myMap.get(key) // without lower casing the key.

At first you might think of this as a common human error, but I claim that it's no less of a code smell:

Why trust yourself to always remember to lower/upper case all of the interactions with the map? What about trusting others?
So, instead of using a HashMap, use an Apache CaseInsensitiveMap that nicely and safely encapsulates this key's case concern.

P.S.
I would expect CaseInsensitiveMap to become a part of the Java SDK.

Wednesday, September 22, 2010

My attempts with IP Spoofing – Revisited

One upon a time (Jan 2009) I've written this post, basically saying that you're not likely to be able to spoof IP address over the Internet.
Turns out I was dead wrong!

It happened so the very experienced Mr Filipe, from Brazil, came across the post and left me a comment saying that Spoofing over the internet is quiet possible.
I replied surprised, and after a number of comments ping-pongs, we started chatting online, and Felipe had agreed to give me a live spoofing demo:
On my end, I've configured my home router to forward TCP/UDP packets to my desktop, where I ran a wireshark network capture to monitor any incoming packets.
Then Felipe sent a burst of packets from random IP source addresses. Proving me that IP spoofing over the Internet is a reality indeed.

(What do you think? Isn't this kind of stuff is what makes the Internet so amazingly wonderful? two people from two different parts of the world, united by joint interest and kindness :))

So, Thank you Filipe!

A few notes on why spoofing might *not* work:

  1. According to Filipe, the recipient's ISP is much more likely to block the spoofed packet, than the sender's ISP. For example if the recipient's ISP see a bogon source IP.
    That's a bit counter-intuitive, because, assuming the ISPs really do care about preventing spoofing, it's a very easy job for the sender's ISP to tell if the packet's source IP is one of the IPs that it handed out to customers, or moreover, to the particular customer (sender).

  2. If you are behind a NAT device, then any source address you are planning to use (be it spoofed or real) will be overwritten by the NAT anyway, so make sure you are on a real public IP.

  3. No reason to get excited. TCP spoofing is very limited as you won't make it across the TCP handshake, because the recipients will send their ACK,SYN response to the spoofed IP, which you probably don't have much control over.
    In a LAN things are a bit different, if you can manipulate the recipient's ARP table to think that the spoofed IP MAC address is yours. I haven't dag deep.


Feel free to comment.