general

xml sort by excel

Quickest way for a one-off XML sort – OR – Learning to keep the heavy tools in the shed

What’s the quickest way/tool to sort a 1000 entries xml file?
Your requirements: The xml is parked on your desktop. You only need to sort it just once so you can manually examine it. Sort by the tag “relevance:score”.

How would you go about it? Would you:
A) Craft a pipe stream of shell utils?
B) Use the heavy tools – a Java main() that with uses JDom?
C) Refresh the XSLT skills you never had?
D) Try your luck with a Python script?
E) search for an online XML editor tool?
F) Or, my pick at the bottom.

Example xml document to sort:

<feed>
    <entry>
        <title>Bibi</title>
        <score>0.21000001</score>
    </entry>
    <entry>
        <title>Lapid</title>
        <score>0.42000002</score>
    </entry>
    <entry>
        <title>Yechimovich</title>
        <score>0.235</score>
    </entry>
    <!--- 997 more entries -->
</feed>

My Pick: considered all the above but it sounded like a headache for a simple sort operation. So I’ve …. thrown the file at MS Excel, turns out it can digest it rather well, and then I sorted by the score column. Yes! Surprising. But crappy MS Excel did the job (the original schema had more nesting than the document in the example above).

Life-saver lesson: Spend time picking the right tool for the job, than on the job itself.

One click to sort

One click to sort

minus84

Specifing arrays size/capacity – my latest buggy code and a best practice

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.

 

 

I 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?

binary-text

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.

hi-256-2-d47bd4b1848d98268cb94c21e7f3a256b36b8ae7

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…

baby

New Java blog out there

A new baby blog was born: Java Tech Sharing.
Proud father: Guy Moshkovich.

I recommend adding to your RSS/Atom reader.