The IBM Fungibles

I heard an interesting word lately with regard to IBM and downsizing. The term is fungible. Per the LinkedIn post an IBM fungible is "someone on their bench who had similar qualities to other employees."

I guess that's an interesting way to put it. It does describe it pretty accurately. Someone who, if they suddenly vanished, either wouldn't be missed or could be replaced with an equivalent "off the street" very quickly with no meaningful loss in output.

the fungibles are fine. they get things done. it's important to keep in mind their billable hours generate the exact same revenue and profit as the key non-fungible people.

so who are the fungibles? maybe it's another way of stating the 80/20 rule. 20 percent are the key contributors who the firm is keen to keep on board and keep happy. the other 80 percent are fungible, can be freely interchanged with no difference. they can be laid off and there are essentially an unlimited number of replacements who can be instantly activated if needed. or to use my earlier 4 in 17 observation, the fungibles are the rest, the 13 in 17.

of course there's no plan to let 80 percent go. that would be crazy. however IBM believe some clump of the 80 can be safely let go in a layoff and things will just continue pretty much as they were and previous levels will quickly be reached again. they are probably right.

using Oracle REPLACE() function to generate Java unicode escape codes

On my current project the UI is a corporate web app. The user base will be global and the supported languages at this point will be English and some Western European languages. The localization setup is a standard Java messages.properties, with per-language messages_fr.properties for French for example.

The developers tokenize the UI screens and put the English content into messages.properties. an external team delivers the translated tokens, which development then puts into the messages_X.properties to complete the process.

With the Western European languages there are sometimes non-ASCII characters with accents or whatnot from the translators. In the .properties files I wanted to convert these accented and non-ASCII characters to \u Java escape codes.

I have access to Oracle and SQL*Developer so I decided to get the database to do the work. A nice thing about SQL*Developer is that it just works to copy in accented characters to the SQL window so that makes it easy. I got Oracle to do the work by using the Oracle REPLACE function which did what I wanted. Now replace() is handy because the function can be nested with itself to call it repeatedly using replace() itself as the input. This makes it really easy to add new characters and build it up as they appear in the translation content. So here's the example code.


select
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
'Complété avec succès',
'é', '\u00E9'),
'Ú', '\u00DA'),
'í', '\u00ED'),
'ä', '\u00E4'),
'ü', '\u00FC'),
'ß', '\u00DF'),
'á', '\u00E1'),
'¿', '\u00BF'),
'È', '\u00C8'),
'ì', '\u00EC'),
'ó', '\u00F3'),
'´', '\u00B4'),
'ú', '\u00FA'),
'ë', '\u00EB'),
'à', '\u00E0'),
'è', '\u00E8'),
'ç', '\u00E7'),
'ê', '\u00EA')
from dual;

the output for the above will be

Compl\u00E9t\u00E9 avec succ\u00E8s

In Eclipse there is a handy feature you can check by hovering the cursor over the \u escaped text in a .properties file and Eclipse will show it in its displayed form with the accented characters.

I don't doubt there's lots of ways to do this. Which makes it a bit of an interesting or fun problem in a way. This is what I did which worked well for me.