Still Learning

I read a joke at a site that I frequent which made me laugh:

Q: How do you tell an introverted computer scientist from an extroverted computer scientist?

A: An extroverted computer scientist looks at your shoes when he talks to you.

The laughter was of the smuggest, most patronizing sort you can imagine. I come from an Irish Catholic family, one of six children, where it's hard to get a word in edge-wise. We all read, watch movies, love the arts, form opinions that are dearly held, and generally consider ourselves to be an outgoing, engaging, personable group.

I've always told myself and anyone else who would listen that I am a made engineer, not born. I didn't grow up fixing cars or radios. I went to school to study mechanical engineering with little understanding of what the field was about. I took calculus and physics as a senior in high school; engineering seemed to be a natural next step. I knew lots of guys who had an innate, natural insight into the way things worked. My reality was confined to the computers where I made a living running simulations.

My youth pre-dated the personal computer revolution, so I didn't discover programming by hacking on a beloved Tandy. My segue into software engineering came about because my mechanical engineering work involved working with Unix workstations and code written in Fortran and C. Those led to C++ and Java for networked PCs. The transition was a quiet, gradual one.

Programming wasn't a burning thirst to be slaked. The passions of my adolescence were playing basketball and the guitar.

One of my employers went through a phase of testing all of us. I took the Myers-Briggs test and found out that I was type ENFJ - slightly extroverted, intuitive, borderline judging, and off the scale on feeling. When I got the results for my Hermann brain dominance, they said I was almost a perfect square: equal facility in upper and lower, left and right modes.

I have proof: I'm nobody's stereotypical geek. Hence the smug laughter at the joke.

Imagine my surprise when I went to my most recent performance review. My boss told me that there were no problems with my technical performance. Everyone agreed that I was knowledgeable and competent - no worries there.

But I was sabotaging myself with my body language. Some of the business folks that I came into contact with said I wouldn't make eye contact with them. I looked down at the table and appeared to not be listening. My facial expressions were "dismissive" when other people presented ideas. My body language excluded others: arms folded, one leg crossed over the other.

My self-awareness failed me. I might have had an idea that this was true, but it hadn't been spelled out for me so clearly. The feedback from people outside my normal sphere was telling.

How could this be true? How did this happen to me?

It reminded me again how important perception is.

Technical people love to say how they hate politics, that the focus should be on the problem at hand, that technology is a meritocracy where the best argument wins. But this assumes that science and technology represent Platonic ideals of absolute truth, as objective and detached as a free body diagram.

As long as there are two people in the room there will be politics. Persuasion will always be necessary. I've been reminded that even the best argument can be undone by the other pathways that humans have evolved. Your tone of voice, your expression, your posture, your ability to pick up on the cues telling you when it's your turn to speak, etc. - all communicate a message in parallel with the words and pictures you're emitting at the whiteboard.

Gödel taught us that mathematics cannot achieve that ideal objectivity and completeness. David Wolpert is proving that the same is true of our understanding of the physical universe. How can I be so certain of my views?

I have to be more conscious of social graces. I have to watch to ensure that arrogance isn't creeping in on me. I need to remember the phrase "Have strong opinions, lightly held."

I started practicing yesterday by doing some simple things: make eye contact when others are speaking; keep hands in the lap instead of folding arms; listen attentively when others are talking; take a breath before offering an opinion.

Is it possible to rewire oneself again? I hope so.

Where Have All The Data Modelers Gone?

I noticed a curious thing at work recently. We have hundreds of instances of Oracle and SQL Server deployed on servers in our data center. Data warehouses that dwarf Home Depot archive many terabytes of information. There's an army of administrators keeping watch, ensuring that no SELECT goes unfulfilled. You can't throw a rock without hitting a Java or .NET developer, well-versed in SQL, chomping at the bit to write an application to deliver that information via the web to any and all clients. Everyone agrees that data are the crown jewels, the lifeblood of any modern business.

If this is true, where have all the data modelers gone?

I see very few people who are comfortable and conversant with concepts like normalization and dimensional modeling. Application developers who possess encyclopedic knowledge of SQL syntax, but lack sound relational design principles and best practices, are given free rein to create whatever tables satisfy the immediate needs of their current project. Extracts are taken, data is duplicated, modifications are made without communicating them back to the source system from whence they came. The number of servers and schemas multiplies. The disk storage required grows exponentially at an ever-increasing rate. Terabytes are maintained, but the unique data might fit on a modest USB key if it could be normalized and extracted. The database administrators don't have any passion for the discipline. Data warehouse designers, ignorant or dismissive of dimensional modeling ideas, create duplicates of source data that are little more than staging areas. There's no cleansing or de-duplication going on. Reports are generated from these staging tables, in spite of better advice.

How did we get here? Where did all that knowledge go?

When the COBOL dinosaurs walked the earth, and mainframes were the kings of business, developers were of one mind. The person who wrote the logic also handled the flat files for persistence and the green screens for the user interface. They were expected to know everything about the system.

Relational databases came along in the 1970s after Ted Codd published his seminal paper on the relational model. There was a land rush to create working implementations of the model. Where there once was a single dominant language for business logic and persistence, COBOL, now there were two: client and SQL. Client/server was all the rage.

Personal computing took processing power out of the data centers, with their raised floors and frigid temperatures, and put it out on desktops. Networks knitted those islands together, first using LANs inside companies and then the Internet over the whole world. Client/server fell out of favor. Fat clients gave way to thin. Two tiers became three; three became four or more. Object-oriented programming took over both the desktop and middle layers, relegating relational databases to the back room. First C++, then Java, and now C# became the brokers between the persistent data and the end users. Object-relational impedance mismatch became the order of the day.

I don't know if increased specialization and layering has put relational practitioners in a funk, but it looks to me like true expertise in this area is dying. I've been fortunate to work with someone lately who is both a well-read devotee of Ralph Kimball and experienced at standing up several successful data warehouses that use dimensional techniques. But he's a singleton; I don't know of anyone else in the enterprise who speaks the same language. Tools for entity-relationship modeling (e.g. ERWin) are buried in the DBA's toolbox, hidden by scripting and client tools (e.g. TOAD), like a specialized wrench reserved for out-of-the-ordinary tasks.

Contrast this with the state of the middle tier. There's a cacophony of voices whenever someone proposes an object design. Good UML tools, both commercial and free, help to make even the gnarliest whiteboard session intelligible and clean.

It has dawned on me that data are still the crown jewels of every business. Client and middle tier technologies continue to evolve rapidly, coming and going at a rapid pace. But the data lives on forever.

Data warehousing and OLAP were huge in the late 90s. Kimball and Inmon slugged it out for dominance. Articles and books were written; consultancies prospered; businesses gobbled up advice and software as quickly as their pocketbooks would allow.

Has the animal spirit gone out of this field? The furor has died down and moved elsewhere, but the need to manage information and deliver it in a timely way to customers is still with us. I don't know if the problem is "solved" so completely that it's become routine everywhere but at my current employer.

But from where I sit today, knowing relational databases and dimensional modeling very well looks like a good bet if you want to have a rare and valuable skill.

How to use the same JNDI resource name on Tomcat and WebLogic

I figured out how to do something that has inspired a few questions on Java forums that I frequent. I write applications using Java 5 and Spring 2.5 and deploy them on Java EE app servers like Tomcat 5.5.26 and WebLogic 10.0. The problem is how to have a single configuration that can be deployed on both without requiring any changes.

Here's how I did it:

First, I added a JNDI resource to my web.xml file with resource name "jdbc/Foo".

Next I had to set up data sources in both my WebLogic project domain, using the admin console, and Tomcat. The mechanics for each are slightly different.

For Tomcat, I created a context.xml and put it in the META-INF directory of my web application. The JNDI name is the same as the in the web.xml: "jdbc/Foo".

When I go into the WebLogic admin console to create the JNDI data source, the key is to specify the JNDI name like this: "jdbc.Foo". Note the dot instead of the slash.

The last detail is the Spring configuration. I use the org.springframework.jndi.JndiObjectFactoryBean. The JNDI name that I give it is "java:comp/env/jdbc/Foo".

Once I build the WAR file, I can switch between Tomcat and WebLogic in IntelliJ at will. No changes needed.