29 June 2005

GlassFish! Nice toy!

Ok, I have been a SJSAS(Sun Java System Application Server) fan since 8.0 simply because it gives me great, compelling results. It has even made some of my deployed projects a legend. Level learning curves, complete documentations, free for production deployment. You'll only need to pay for technical support if you want to. But the docs are great enough(even pseudo-techies understands it manz!). Until now, It still runs in my brains how messy, disorganized and how fucking incomplete BEA's docs . As I see it, the only downside to Sun on this game is really marketing.

Now, here's GlassFish, the SJSAS PE(Platform Edition) 9.0 as it is otherwise known, is nasty for a lot of reasons, Migs has mentioned its use of the Derby embedded database(hey, why not BerkeleyDB?). And of course it's CMP uses JDO! I don't know why they didn't choose Hibernate, but for me, the reasons are so obvious. Well, I have to build my own copy.

BEA is going Open Source

There's no actual press release link for this article. But most likely, it's not surprising if it's true. My question this time is, who will beat Open Source? Sooner high-level applications(read: ERPs) will be chipped away and be cast to this lions' den called Open Source.

But going back to BEA's open source vision. It will be supporting Spring, Beehive, Struts and JSF. Currently, it uses Avalon. This also means good bye to Workshop, Portal Frameworks and the other shitty stuff BEA is piling itself into. Because definitely, their new Portal Framework has to comply with JSR-168 which means their old customers will not need to upgrade or pretend to upgrade but will definitely require some substantial amount of re-architecturing if they still want BEA to fool them.

At least BEA now understands what the developer and users needs. What is needed are simpler frameworks from security to application management. But this has to be a 360-degree improvement not just some bell-ringers. In other words, it has to be LIGHT and FAST. Again, LIGHT and FAST!

All in all, this is more like a distress call from a sinking ship.

28 June 2005

To Mobicents, hooah!

An Open source VoIP Middleware, coolness! If brick-and-mortar telcos don't adapt and change this time, for sure they will die. The beauty and the beast of Open Source has it again. Mobicents is based on the JAIN/SLEE specifications. These specifications just like Jini/JavaSpaces are not under the J2EE umbrella, another coolness. But I wonder what JBoss has to do with this, get some brownie points?

Hopefully, The Patriot will get a booth at JavaOne 2006 ;). What we need now are cool sponsors(Starhub or SingTel?) to pass the TCK for the JCA part.

27 June 2005

Properties Configuration with XStream

Thanks to Mig's archives. I was able to rescue this old post.

August 16, 2004

Jared OdulioProperties configuration with XStream

Yes the spelling is correct, I am referring to XStream Java to XML Serialization API. For simple configurations, we could settle for Java Properties API where we can just define a properties file with key/value pair construct and load it to a Properties instance then that's it. But what if we need a more flexible configuration in XML without being overwhelmed with which XML parser to use and what performs best? A good bet would be XStream for a simple XML-based configuration you can quickly use XStream almost as you would with Java Properties API. To make that a little quicker, here's little quick and dirty sample.

Let's say we have an application that automates an administration of two remote servers via SSH so we need to keep the hostname, port, username and password(!!!) in the configuration file. First we need to define the xml configuration file:





Then let's use a value object named "ServerConfig".

public class ServerConfig{

private String host;
private String port;
private String username;
private String password;

//Constructors here..

//Getters and Setters here


Then a configuration manager class called "ConfigManager".

public class ConfigManager{

private List configs;
private XStream xstream;

public ConfigManager(){

xstream = new XStream(); //this constructor uses the XML Pull Parser 3 API

xstream.alias("linked-list", ArrayList.class);
xstream.alias("serverconfig", ServerConfig.class);

//Assumes that your config file is in the classpath.
InputStream is = this.getClass().getResourceAsStream("/serverconfig.xml");
InputStreamReader reader = new InputStreamReader(is);
configs = (List)xstream.fromXML(reader);


public List getConfigs(){

return configs;


An admin class might look something like this:

public class MainAdmin{

public static void main(String[] args){

ConfigManager manager = new ConfigManager();
List servers = manager.getConfigs();
ServerConfig config = null;
Iterator it = servers.iterator();
config = (ServerConfig)it.next();

The output will be:

August 16, 2004 08:39 PM

My take on Pornographic Coding

If the legendary "Russian Programmer" still codes today. What does he looks like now with this? Most likely his room will smell like chlorine every minute hehehehe. Very interesting piece of literature on programming :))

26 June 2005

Technical CV for Dummies

Whether it's a right decision to publish this or not, I don't know. But I know some of these turds happened to be so lucky. Anyway, I believe that some of us want to be employable for the rest of their motherf&**ng pathetic lives. So here's to your long-term job hunting portfolio. Making a believable(at least) Technical Profile.

Here are rules, not suggestions, for a Technical CV. But first, what is a Technical CV? or a Curricullum ViTAE? It is a piece of information that tells something about your technical skills or talents, the summary of how you solve problems, where in the real world did you apply your solutions, who are the living souls that can back your claims and the devils that you conspire with to get "brownie" points.

Regardless of how honest or dishonest your CV may be. You have to know some rules in order not to become obviously stupid.

  1. Start with your Name just your name. No one cares about your title yet, remember this is technical CV. Unless you're in for some asskissing position, you can use salutations such as "Engr.", "Dr." etc. together with suffixes such as "Ph. D.", "MCSD", "SCJP", "RMI/IIOP" or whatever convent or monastery you came from. The top should only be populated with your plain full name. Because you'll be facing some intimidating questions along the way when you "flash your cards" early on and that's for sure.
  2. List your tools starting from the one that you're using currently to the one that you have forgotten eons ago. Chronological arrangement is important because it is most likely that interview questions will be structured that way.
  3. List your experiences, how you've used the tools you claim you're good at from the most recent gig up to whenever the first one was. Explain how did you use those tools and for what and how did the poor company you worked for benefited from it. Explain how you solved problems as a team member or as a team leader. Specify at some point how you demonstrated strong leadership.
  4. Specify your education. Where did you learn your skills, how did you learn your skills, your certifications, your other pursuits of studies. Aaah this is where you are going to show your "scout badges". At this point you may hear exclamations like "Ow! So you're a PhD!" Yes, when you here something like that, it's like poker you're interviewer is already at the edge of his/her seat.
  5. Some references or tell them you'll give them a signed statement from each upon request. The latter is more explosive.
  6. Lastly, your contact information.
That's it. No more, no less. Maybe you're asking, "Why birthdays and other stuff are not included?". FYI, In some countries, it's illegal to ask candidates for age, sex, civil status, religion during the interview or even discuss about it. Some employers are cautious on CVs with such information and mostly likely it ends up on a shredder or someone else's ass. So make sure your CV is global-friendly. And why no pictures? Geez, if they ask for it then give it, if not then don't, because most likely they will delete it from the soft copy you just emailed to them.

And by the way, if you're CV is more like 8 pages or up...it's time for you retire. :))

22 June 2005

The Russian Programmer

Don't take this seriously now 'coz it's way back 1998-99. But reading thru, I realized how lucky I am. ;) Read on, most likely the site was written using a bootlegged Microsoft FrontPage hahahaha!

  1. Russian programmers never read manuals and rarely use online help - they easily get a
    grasp of a new program, simply because they have already tried every single program in
    this field before.

  2. Insanely untrue, a desperate ploy to get a job offer

  3. Russian programmers never pay for the software. They either crack it or buy those
    wonderful CDs with tons of cracked software that are sold for $5 bucks in every major city
    in Russia.

  4. I never pay for software and I never steal software. That's bad [programming] karma

  5. Russian programmers are always on the cutting edge of software development - they use
    the latest versions of the best tools available - it's easy, since there is no need to

  6. And we are on the bleeding edge, because we're involved in writing the best tools. While they become the "Mac Users"

  7. Russians programmers are very experienced in hardware. They will take your computer
    apart and build it back in a matter of minutes. They remember the jumpers settings for
    most boards, hard drives and other devices. They never forget what interrupts and base
    memory addresses are currently used up in their computers.

  8. Kid Stuff

  9. Russians programmers keep upgrading their computers until there are no more available
    interrupts, no room for additional memory and no free bay slots. If they can't upgrade it
    any more they buy a new one and tie both old and new computer into a LAN.

  10. Cheapos


  11. Russians programmers program on on all levels, beginning with the processor codes, table
    of which they hold for the reference on their desk. They usually remember by heart the
    list of functions of Int21H.

  12. Fundamentally essential, but waste of time these days

  13. Russian programmers remember by heart both English and Russian keyboard layouts. You can
    ask them in the middle of the night what key is between A and L and you'll hear surprised:
    "What do you mean - they are 7 keys apart?".

  14. This is funny, when they type they still look at the keyboard

  15. Russian programmers hate Microsoft and Microsoft tools, but keep using them from time to

  16. Russian programmers prefer Borland tools and install Microsoft compilers only for their
    nice Help files on Windows API.

  17. No longer applicable today

  18. Russian programmers feel themselves very comfortable on the Internet. They are always
    online - just in case they need something urgently.

  19. Big deal huh

  20. Russian programmers only work when they are in the right mood. Programming is a creative
    process and it cannot be pushed.

  21. Agree! But not uniquely Russian

  22. Russian programmers are always in the mood for programming.

  23. Most likely they don't know how to kiss anymore

  24. There are two kinds of Russian programmers - the ones that hate Windows and program on
    Unix and the ones that hate Windows and still program on Windows. Macintosh programmers
    aren't real programmers - they are more often referred to as "users".

  25. Well, this is 1998 and this guy never heard of Linux yet

  26. Russian programmers hate to code somebody else's ideas. Each program is written
    personally and from scratch.

  27. Yeah, and the next programmer will write a different code for the same application, Time wasters


  28. Russian programmers always have a copy of Doom, Duke Nukem or Quake on their hard
    drives. They play nights over the network in the Deathmatch mode.

  29. Anyway this is 1998

  30. Russian programmers never use joystick. Keyboard is a dangerous weapon in their fast

  31. Because joystick is for playing not for programming, Ivan

  32. Russian programmers never give up. They will hunt down bugs in their programs forgetting
    to eat and sleep.

  33. Because it's their fault why bugs are there in the first place anyway


  34. Russian programmers' wives are never happy. They get no attention whatsoever as long as
    the computer is in the same house.

  35. Hey, get a sex therapy program(not the one that you install on a pc jerk)

  36. There are two kinds of Russian programmers - the ones that bring profit by actually
    doing something, and the ones that bring better profit by not interfering with anything.

  37. So mostly likely they love interfering with something

  38. Russian programmers are always underpaid. There is no money in the world that amounts to
    what they are really worth.

  39. Yeah, Just like us

  40. Big bosses don't like Russian programmers. Who likes a smart ass who knows everything?

  41. Haha, even if we know everything, big bosses likes us

  42. Big bosses will never fire a Russian programmer. They know that even working 10 hours a
    week and being half-drunk Russian programmer will accomplish more than a Ph.D both in the
    short and in the long run.

  43. This is 1998, today anyone is expendable

  44. Russian programmers never prototype the code. They write on inspiration, sometimes
    without sleep, driven by the urge to see the new program run as soon as possible. When the
    program finally runs without glitches they drop on the floor and sleep for 20-30 hours
    happily smiling in their dreams.

  45. So usually it's a "Picasso" code that goes to the grave with them

  46. Russian programmers never approach programming methodically. Every program is a piece of
    art and is usually written in a highly inconvenient time when deadlines for other projects
    are around the corner.

  47. Crammers


  48. Russian programmers like sushi. Japanese restaurant is the only place they may sacriface
    the friday night debugging session for.

  49. So that's how long they take to debug their artfully written program


  50. Russian programmers eat very seldom. Usually they manage to grab something during the
    compilation or a lengthy file upload/download.

  51. Most likely their brains only works during compilation or a lengthy file upload/download


  52. Russian programmers usually sleep from 6 am to 8 am. The rest of the day (and night) is
    spent in a half-sleeping mode, although it doesn't reflect on work efficiency.

  53. Russian programmers ignore the regular schedule with lunch time starting at noon. They
    usually go to lunch around 2-3 pm. If they go to the lunch after 4 pm - they don't return.

  54. Russian programmers never start working right away in the morning.
    First they check and reply to all E-mails, read the daily news, make a
    posting to a favorite newsgroup and have a cup of tea.

  55. Who does?

  56. The morning ritual described in item 29 usually lasts through the
    first half of the day. Russian programmers start working right after
    lunch, intermixing their primary functions with Internet activity.

  57. Russian programmers like to chat on IRC. Communication with real
    people takes to much time to be taken seriously.

  58. The writer shouldn't be generalized with the rest of the Russian Programming Community


  59. If Russian programmer visits a friend who has a computer in the house,
    sooner or later he will get to it to check his mail or for some other
    important reason.

  60. If the computer in the friend's house is broken, the Russian
    programmer will fix it in no time.

  61. Big deal?

  62. Russian programmers usually fall dead asleep every time they are taken
    away from the computer. The regular life is too boring.

  63. Poor guy

  64. Russian programmers with laptops very often collapse from exhaustion
    and insomnia, because there is no place on earth where they could get
    away from their computers and take a good sleep.

  65. Even Poorer Guy!

But at any given time I would prefer to work with a Russian than an American.

17 June 2005

History repeats itself

What was done will be done again and there's nothing new under the sun. And I love the way Marc Fleury puts it here. Fleury said that "... his software is better than Gluecode, and that IBM doesn't know how to manage a software business. ". Steve Jobs said almost the same thing on Windows from eons ago. The question is, "Does it matter?". Does it matter if JBoss is better than Gluecode now? Just like it matters if Mac is better than Windows back then?

Fleury, obviously, never learned from history or he chose to ignore it. What matters now is IBM will chip a huge chunk of whatever market is left for JBoss. And from the looks of it, on the commercial standpoint, JBoss days are numbered. YAHOOOOO! I am sick of that shit.

15 June 2005

How Private are Private Fields?

Read from an interesting article. Yeah, how private are private fields? The example codes that were shown from that article were still "nice" in such a way that it has to explicitly name the private field to be screwfully modified.

Here's a more wicked way of doing it, what we'll do is to enumerate all fields then modify them all hihihihi. Note: BOYS AND GIRLS, DO NOT TRY THIS AT HOME.

Listing 1: NoMatterHowPrivate.java

package org.hacks.wicked;

* @author Jared Odulio
public class NoMatterHowPrivate {

private String yourName;
private String yourSecret;

private static NoMatterHowPrivate instance;

* @return Returns the yourName.
public String getYourName() {
return yourName;
* @param yourName The yourName to set.
public void setYourName(String yourName) {
this.yourName = yourName;
* @return Returns the yourSecret.
public String getYourSecret() {
return yourSecret;
* @param yourSecret The yourSecret to set.
public void setYourSecret(String yourSecret) {
this.yourSecret = yourSecret;
* @return Returns the instance.
public static NoMatterHowPrivate getInstance() {
if (instance == null){
instance = new NoMatterHowPrivate();
return instance;

The code above is your typical "HighLander" class. You know what's a "Highlander" class? "There can only be one..." says Duncan McLaud(?). Right, it's a singleton. And that class has a client call SissyClient.

Listing 2: SissyClient.java

package org.hacks.wicked;

* @author Jared Odulio
public class SissyClient {

private NoMatterHowPrivate nmhp;

public void setSomeStuff(){
nmhp = NoMatterHowPrivate.getInstance();

public void getSomeStuff(){

nmhp = NoMatterHowPrivate.getInstance();
System.out.println("I am " + nmhp.getYourName());
System.out.println("I am " + nmhp.getYourSecret());


SissyClient is your clueless class who thinks she's doing everything fine. :))

And here's our badass Reflections-loving class. It's called WickedHacker.

Listing 3: WickedHacker.java

package org.hacks.wicked;

import java.lang.reflect.Field;

* @author Jared Odulio
* TODO To change the template for this generated type comment go to
* Window - Preferences - Java - Code Style - Code Templates
public class WickedHacker {

private NoMatterHowPrivate toScrew;

public void screwSomeStuff(){

String[] stuffs = new String[2];
toScrew = NoMatterHowPrivate.getInstance();
Object tmp = (Object)toScrew;
Field[] fields = toScrew.getClass().getDeclaredFields();
int fldCount = fields.length;
for (int ctr = 0;ctr < fldCount; ctr++){
Class clazz = fields[ctr].getType();
if (!clazz.getName().equals(toScrew.getClass().getName())){
try {
fields[ctr].set(tmp, "Screwed");

} catch (IllegalArgumentException e) {

} catch (IllegalAccessException e) {





This class is ruthless except for the static fields. It takes on almost anything especially the privates.

We can run this by using this main class.

Listing 4: Runner.java

package org.hacks.wicked;

* @author Jared Odulio
public class Runner {

public static void main(String[] args) {
SissyClient client = new SissyClient();
new WickedHacker().screwSomeStuff();

Output will be:

I am Screwed
I am Screwed

You can try this with your existing code and have some fun. Now, run to your productions servers!

12 June 2005

JSR-69 aka The Java OLAP Interface

When you hear the word OLAP what comes first to your mind? For me, it's a few things like business intelligence, analytics, multidimensional querying. In other words, these what consists an Online Analytical Process(OLAP), it's different from OLTP(Online Transaction Process). In OLTP we have many players, the RDBMS vendors, the ORM Solution vendors etc. The OLAP today is still dominated by two known vendors, Hyperion Solutions and Cognos (known for their Powerplay and Impromptu tools).

Why is OLAP important? Obviously, business intelligence is the key to survival of any enterprise. The ability to mine and analyze data in the shortest period of time makes the difference between success or failure. Well, as I see it, the most exaggerated application of OLAP is from a popular TV program called '24'. You can see how Jack Bauer and his aides analyze tons of information in the shortest time and take only what make sense to accomplish their jobs with minimal "loss of life". These are the kind of stuff where you can't bet your life on Hibernate. For one, it doesn't fit although some freaks will try to force it just to prove the point but it's not going to happen.

Enter Java OLAP Interface. Spearheaded by Hyperion, this is one of the JSR worth watching for. Why is there a need for JOLAP? According to the spec site, "...The ultimate goal of JOLAP is to provide for OLAP systems what JDBC did for relational databases." How many OLAP systems are there in the market? Most visible, two.

JDO is the most suitable partner for this specification because its multi-querying goes naturally with JOLAP. Itching for an open JOLAP?

08 June 2005

It's 12-3 for JDO 2.0

I want to laugh my heart out. Sun voted yes, suprisingly, Macromedia yes. JDO 2.0 is a Java Standard whether EJB fucktards like it or not. In fact, EJB has time and again proven its inferiority to JDO, and EJB 3.0(???). Hey! who needs EJB 3.0? Of course, still the EJB fucktards, who else?

I think JDO's time has come. No more political wranglings, no more vendors penis-fencing. This is it. The guys behind the JSR-220, this spec is so girlish, you know why? It needs help and it needs fixing. I guess I can now spend sometime to download JPOX and start making some real business-value stuff with it.

To the IT Manager, sorry I can put in my comments to TSS, it's too many now. I think the support for JDO has been very overwhelming. So EJB guys, don't push it. Join the club.

06 June 2005

What's so genius about this Martin Fowler?

I've been listening to some Java discussions and most topics are based "according to Martin Fowler" (duh!). But by reading his principles of code writing it's just an ordinary thing especially if you are a "progressive" Java Developer. Progressive in such a way that you have almost done everything, not tried, done.

For instance, this Inversion-of-Control/Dependency Injection(DI my ass!) pattern. Before that pattern got a name it has been used from the JVM far, far away. Even without a container. If anyone writing the same Java code over and over again for long years, definitely this buzzword will be such a hit and a welcome thing to the path of redemption from years of dirty, lousy code.

I think the only edge Martin Fowler has is his ability to write in muggle terms, which some of the equally or more talented Java people doesn't have.