portal Ola

Oto Tłumaczenie z angielskiego jakże trafnej, ponadczasowej i zawsze aktualnej ...

...zasady SNAFU.

Recently I've written a web app whose purpose is to aid people who switch between Russian and English QWERTY keyboard layouts and often mistype what they intend to with a wrong layout. Usually switching the layout and retyping the same thing is more effort than clicking through a Google search result that shows the mapping from the wrong to the right text. Or copying the mistyped text and pasting it into the web app. For people who mistype very often, there's even a search plugin for popular browsers.

It's my first try at a web application implemented in Python so it may have a few rough edges, but it already shows some interesting results.

The most popular mistypes seem to currently be:

цшлшзувшф (wikipedia)

crfxfnm (скачать)

ajnj (фото)

jlyjrkfccybrb (одноклассники)

цццюьфшдюкг (www.mail.ru)

офтвучюкг (jandex.ru)

нфтвучюкг (yandex.ru)

кфьидукюкг (rambler.ru)

ьфшдюкг (mail.ru)

7яшз (7zip)

нщгегиуюсщь (youtube.com)

дшмуощгктфдюсщь (livejournal.com)

d rjynfrnt (в контакте)

drjynfrnt (вконтакте)

Ылнзу (Skype)

gjujlf (погода)

yjdjcnb (новости)

Try the browser search plugin, it's fun!

After wondering for the n-th time about what would be the difference (if any) in toString() representations of a TreeMap and a Vector, I've decided to make a simple catalog for future reference.

Here it is: Java standard classes toString representation catalog.

It currently includes only JCF classes.

This script, explode_zips.sh, taken straight from the document Aleksander Adamowski's useful scripts, should be very useful for a Java Enterprise application developer or administrator. It takes a ZIP archive (which JAR/WAR/EAR archives are in their heart, too) and recursively explodes it in a way similar to what the JBoss application server does when deploying. It's very useful e.g. when you have two versions of an enterprise application and want to compare them by content e.g. using diff. Comparing binary ZIP archives wouldn't do the trick, especially if they contain other archives, which contain another ones (you get the idea). On the other hand, when you recursively unpack all the archives and get rid of the binary ZIPs, you'll be left with a directory structure which can be easily compared for differences using appropriate tool (like the aforementioned diff on UNIX systems, or e.g. Total Commander under MS Windows). Here's the actual script:

#!/bin/sh
# Iteratively explode all ZIP/JAR/WAR/EAR archives in the current dir and all the archives they contain.

foundzips=1
while [ $foundzips -gt 0 ]; do
  IFS=$'\n'
  foundzips=0
  # Not very efficient to re-find for each sublevel, but it's simple:
  for zipfile in $(find ./ -type f -iname '*.zip' -or -iname '*.[jwe]ar'); do
    foundzips=1
    echo "Archive: [$zipfile]"
    expdir="$zipfile.exploded"
    if [ ! -e "$expdir" ]; then
      dirpushed=0
      zipfilebasename="$(basename "$zipfile")"
      echo "making $expdir" && \
      mkdir "$expdir" && \
      echo "entering $expdir" && \
      pushd "$expdir" && \
      dirpushed=1 && \
      echo "unzipping $PWD/../$zipfilebasename" && \
      unzip "../$zipfilebasename" && \
      echo "removing $PWD/../$zipfilebasename" && \
      rm "../$zipfilebasename" ||
      mv "../$zipfilebasename" "../$zipfilebasename.bad"
      if [ $dirpushed -gt 0 ]; then
        popd
      fi;
    fi;
    finish=0
  done;
done;

I've published a document with all sorts of useful scripts for various tasks, ranging from encoding/decoding Base64 and quoted printable, through determination of remote host's SSL certificate expiry date, to recursively exploding ZIP/JAR/EAR archives (similar to the way JBoss does when deploying).

It's available here: Aleksander Adamowski's useful scripts.

This document is being updated whenever I write a script worth publishing.

I've compiled a list of the most useful MBeans to be found in JBoss through its JMX console: Aleksander Adamowski's JBoss JMX console tips and tricks.

It includes MBeans with operations for shutting down JBoss remotely, listing Java system properties, listing JNDI contents, forcing log4j configuration reload, listing ClassLoader info for given class, listing deployed apps, retrieving cluster information etc.

This list is being updated whenever I discover some MBean worth mentioning.

Here's a Wordle.net rendering of my blog postings up to date:

CVE-2008-1198

The problem with Java's loading of classes on demand is that it's non trivial to implement a mechanism for dynamic discovery of new classes in packages. If we only want to drop new classes into a package, and don make any further modifications in the code and application configuration (e.g. properties), then we have no other choice but to do dirty tricks with traversing the package's file structure to discover the .class files.

This requires two different code paths for class files in JAR archives and in the filesystem - that's because the JAR archive is a ZIP file and doesn't contain a tree structure of directories. Instead, it contains a flat listing of all contents. So the getResource() method is unable to give us a File object which isDirectory() in the case of a JAR archive.

I've implemented a ClassPreloader class that provides a convenient preloadCurrentPackageClasses() method that handles both cases gracefully.

You'll find the source here.