Our office has 3 senior developers/architects, and about a dozen other development staff of varying levels of competence and experience. We are very busy and always looking for talented new staff. Want to join us? Figure you are architect and can really help us out?
Enter the Crucible my young Jedi. Maybe you will survive to talk about it.
What is the Crucible? It's what I like to call a political/social situation that I think many senior technical staff must survive to become accepted into the office community. You are a talented, knowledgeable and enthusiastic worker. You don't know the answer to every problem there ever was, but given a decent computer, your favorite IDE and a little sealing wax and you KNOW you could fix anything and do a great job doing it.
So you sell yourself as a go-getter, and you get dropped into the maelstrom. No problem! You settle in, you grind through the mess and while under pressure you conceive and then flesh out The Perfect Solution. In every way, The Perfect Solution is going to solve all our technical problems, and launch us into years of contented and relaxed development on time, on budget. You pat yourself on the back and go into your first technical review meeting.
You rocked! You laid out the plan, demonstrated how The Perfect Solution would fix everything, showed how it was affordable, doable, and in every other way was, well. perfect! You paused to accept praise and were slightly surprised to hear nothing but uncomfortable silence.
You just landed in the Crucible my friend, and you don't even know it yet. What happens in the next 10 minutes will determine your career at this place.
You see, here is the thing. Like most shops, our software is bad not by accident, but by DESIGN. We love our software, we love the way it is written. We love the way we write software, and worse. we don't want to change our ways. We just want to do everything we did before but have the bad stuff go away. (Recall the definition of insanity)
If you can't figure out how to do that, then you must not be the right guy for us. In other words, you will not survive the Crucible.
So how do you survive the Crucible? Next post I will talk about how I did, and maybe how you can too.
Friday, February 13, 2009
Sunday, March 18, 2007
I'm baaaaack
Well folks, rumors of my demise were... more or less correct. But I am back, and thinking of blogging again. But I want to know who is actually reading my blog. Heeeelp me folks, how do I do that?
Powered by ScribeFire.
Friday, April 21, 2006
Springleton Adventures!
10 days into my new job and so far I haven't pissed of anybody (of note). Not bad for me, but give it time, give it time.
First day on the job I couldn't keep my yapper clamped, and I started spouting off on Spring and after a good natured debate on third party code with my boss (the Sushi King) I found myself saddled with a Spring evaluation project. DOH!!! When will I learn.
So after a few days struggling with JBoss and its MBean microkernel architecture I got onto the Spring thing. I had a fair amount of trouble with JBoss class loaders and how it affected Spring and especially Spring resource locations, but I ran across the JBoss Spring Deployer and it got rid of all my class loader troubles.
So my eval project consisted of taking one of my project's MBean services and Springifying it. My coworker referred to it as making 'Springletons' - I kinda like the play on words. Once I got past JBoss class loading it turned into a very straightforward Spring conversion. That is to say, I wrote no new code (well not till later, see below), eliminated 9 of 17 classes, and deleted rafts of transaction and other resource management glue code.
The cost was the introduction of a standard Spring XML configuration file, a 60 line file. I exchanged some 500 lines of Java code for that, so I would call it a good trade. In addition, about 1/2 of the XML file is common/shared code, so I only needed about 30 lines of XML configuration to specifically code this piece.
So I go to review the code with the Sushi King early next week. He is a hard core roll-your-own coder, and its hard to anticipate what he won't like about my results, but I am sure there will be something. But, as I cheerfully note, he will either like it and buy me lunch or I will be swimming with the fishes. Oh-oh, wait - he likes sushi. Maybe we should do this code review remotely?
First day on the job I couldn't keep my yapper clamped, and I started spouting off on Spring and after a good natured debate on third party code with my boss (the Sushi King) I found myself saddled with a Spring evaluation project. DOH!!! When will I learn.
So after a few days struggling with JBoss and its MBean microkernel architecture I got onto the Spring thing. I had a fair amount of trouble with JBoss class loaders and how it affected Spring and especially Spring resource locations, but I ran across the JBoss Spring Deployer and it got rid of all my class loader troubles.
So my eval project consisted of taking one of my project's MBean services and Springifying it. My coworker referred to it as making 'Springletons' - I kinda like the play on words. Once I got past JBoss class loading it turned into a very straightforward Spring conversion. That is to say, I wrote no new code (well not till later, see below), eliminated 9 of 17 classes, and deleted rafts of transaction and other resource management glue code.
The cost was the introduction of a standard Spring XML configuration file, a 60 line file. I exchanged some 500 lines of Java code for that, so I would call it a good trade. In addition, about 1/2 of the XML file is common/shared code, so I only needed about 30 lines of XML configuration to specifically code this piece.
So I go to review the code with the Sushi King early next week. He is a hard core roll-your-own coder, and its hard to anticipate what he won't like about my results, but I am sure there will be something. But, as I cheerfully note, he will either like it and buy me lunch or I will be swimming with the fishes. Oh-oh, wait - he likes sushi. Maybe we should do this code review remotely?
Thursday, April 13, 2006
Java IDEs and other religious wars
Well I have started a new contract, and as always the first few days of a new job is always Environment Hell. There are servers, vpns, dns names, drives, passwords, and endless other configuration details to get right, and the cursory overview at lightning speed my new boss gave me was par for the course, and hopelessly inadequate. Same old same old there.
And as always happens the first day of a new job, the little battle regarding what Java IDE we were to use played itself out with glum predictability. "What IDE do you prefer" said my boss, vainly attempting a casual air - but the nervous tic around his eye and the sudden lack of breathing around the room told me that there was only one right answer. And many, many wrong ones.
I took a deep breath, briefly considered just guessing which IDE he wanted me to answer with, but in a second of reckless abandon (which I deeply regret) I looked bravely in his eye and answered truthfully.
It was the wrong answer. Woefully, deeply wrong.
His face fell, and as he half-heartedly tried to look reasonable, condenscending, forgiving, indignant and hard-line all at once, I sat back in my chair and resigned myself to yet another lecture on why HIS IDE was the only one worthy of consideration, and all the reasons why it far surpassed my hopelessly worthless favorite.
Long experience taught me to sit quietly and nod often. We had entered into that most dangerous of holy wars, the question of "The Best Java IDE". There is no winner of this ideological conflict, there is only opinions and personal preferences. Years ago I came to the conclusion that there is no Java IDE that conclusively is the best for all people in all situations. Further, many scars and many fruitless wars have taught me that there is no way to win this battle.
The question I often ponder is - why must there be a 'designated IDE' for a project? Almost always these days there is nothing specific about a project that would make it fly or crash depending on the IDE, and frankly, in this day and age of feature races and competition, there is hardly a feature in one IDE that every other major one could not claim to also have.
My very good friend volunteers for the JBuilder IDE, providing early beta testing and many other tasks that foster the improvement of the JBuilder community. We remain good friends despite the fact that I would rather use Notepad and the command line than JBuilder, and she would rather cut her fingers off and weave baskets with her nose than use my favorite IDE. Which one of us right? Well neither of course. IDE's are clearly a matter of personal preference. Why waste time and effort on forcing a particular choice on anybody?
Whats that? Am I using the IDE demanded by my new boss? Well... I installed it so I must be. Right? :-)
And as always happens the first day of a new job, the little battle regarding what Java IDE we were to use played itself out with glum predictability. "What IDE do you prefer" said my boss, vainly attempting a casual air - but the nervous tic around his eye and the sudden lack of breathing around the room told me that there was only one right answer. And many, many wrong ones.
I took a deep breath, briefly considered just guessing which IDE he wanted me to answer with, but in a second of reckless abandon (which I deeply regret) I looked bravely in his eye and answered truthfully.
It was the wrong answer. Woefully, deeply wrong.
His face fell, and as he half-heartedly tried to look reasonable, condenscending, forgiving, indignant and hard-line all at once, I sat back in my chair and resigned myself to yet another lecture on why HIS IDE was the only one worthy of consideration, and all the reasons why it far surpassed my hopelessly worthless favorite.
Long experience taught me to sit quietly and nod often. We had entered into that most dangerous of holy wars, the question of "The Best Java IDE". There is no winner of this ideological conflict, there is only opinions and personal preferences. Years ago I came to the conclusion that there is no Java IDE that conclusively is the best for all people in all situations. Further, many scars and many fruitless wars have taught me that there is no way to win this battle.
The question I often ponder is - why must there be a 'designated IDE' for a project? Almost always these days there is nothing specific about a project that would make it fly or crash depending on the IDE, and frankly, in this day and age of feature races and competition, there is hardly a feature in one IDE that every other major one could not claim to also have.
My very good friend volunteers for the JBuilder IDE, providing early beta testing and many other tasks that foster the improvement of the JBuilder community. We remain good friends despite the fact that I would rather use Notepad and the command line than JBuilder, and she would rather cut her fingers off and weave baskets with her nose than use my favorite IDE. Which one of us right? Well neither of course. IDE's are clearly a matter of personal preference. Why waste time and effort on forcing a particular choice on anybody?
Whats that? Am I using the IDE demanded by my new boss? Well... I installed it so I must be. Right? :-)
Sunday, April 09, 2006
Insecure Geeks... is it still really all about the size of your hard drive?
I am still working my way through a few tests on the JavaBlackBelt site, an 'open certification' kind of site that (some tell me) has been around for a while now. I have done a couple of the simple tests to get my 'yellow belt', the lowest level certification they will give me without having to invest a great deal of time in designing tests, questions, comments and so on. I am not yet certain its worth the effort, and it appears the emphasis at JavaBlackBelt is much more on test design than test taking. The equivalent would be telling someone to use Hibernate but they could not do a pre-fetch query unless they submitted 3 code enhancements to the codebase first. A little onerous, I am thinking.
Anyway, I took the 'Introductory OO test' and failed it. Shame on me, right? Well, first I only failed two questions, and I was only allowed to fail one. Missed it by.... THAT much! This blog is really about the style of questions that the test was presenting.
In an earlier blog on certification I mentioned that I would look forward to some kind of certification tests. Well, so far the ones at BlackBelt are definitely not the kind I am looking for. They are testing in a style I remember well from my school days (yes, I still remember my school days), and I felt the same sense of frustration answering these BlackBelt questions as I felt back then. In short, the questions were not testing my depth of knowledge, but instead focused on clever tricks to try and fool me into picking the wrong answers.
That in itself, while annoying and close to pointless, is not the main problem. I found the whole approach of reading a piece of code and describing why it would or would not compile absolutely a waste of time. Today's Java IDE's compile as you type, and even auto-complete statements with suggestions on how to remove the compile issue. Why would I bother trying to figure out if something can compile by 3 minutes of scrutiny to uncover the arcane subterfuge a tester has wrapped around a trivial compile bug when any IDE that is better than Notepad will highlight the error, autosuggest a fix and implement the fix with a single keystroke? What am I being tested on then?
It smacks of the geeky bravado I used to see in Computer Science school that used to make me sigh and go find some of my old Geology buddies to drink with. You know the guys I am talking about - the ones that organized Friday night programming contests. I remember hearing of one where the goal was to see who could write a C program that functioned as a Notepad in as few characters as possible - variables, syntax tokens, white space all counted. Doesn't anybody want to go to the sports bar and try and pick up the waitress anymore?
So I will keep trying a few more tests, and I hope I will eventually get to one that actually tries to test me on an aspect of programming design, implementation or execution that can't be auto-completed by an IDE faster than I can type. Otherwise its back to the bar. I am POSITIVE that waitress smiled at me, even before she saw the tip I left her....
Anyway, I took the 'Introductory OO test' and failed it. Shame on me, right? Well, first I only failed two questions, and I was only allowed to fail one. Missed it by.... THAT much! This blog is really about the style of questions that the test was presenting.
In an earlier blog on certification I mentioned that I would look forward to some kind of certification tests. Well, so far the ones at BlackBelt are definitely not the kind I am looking for. They are testing in a style I remember well from my school days (yes, I still remember my school days), and I felt the same sense of frustration answering these BlackBelt questions as I felt back then. In short, the questions were not testing my depth of knowledge, but instead focused on clever tricks to try and fool me into picking the wrong answers.
That in itself, while annoying and close to pointless, is not the main problem. I found the whole approach of reading a piece of code and describing why it would or would not compile absolutely a waste of time. Today's Java IDE's compile as you type, and even auto-complete statements with suggestions on how to remove the compile issue. Why would I bother trying to figure out if something can compile by 3 minutes of scrutiny to uncover the arcane subterfuge a tester has wrapped around a trivial compile bug when any IDE that is better than Notepad will highlight the error, autosuggest a fix and implement the fix with a single keystroke? What am I being tested on then?
It smacks of the geeky bravado I used to see in Computer Science school that used to make me sigh and go find some of my old Geology buddies to drink with. You know the guys I am talking about - the ones that organized Friday night programming contests. I remember hearing of one where the goal was to see who could write a C program that functioned as a Notepad in as few characters as possible - variables, syntax tokens, white space all counted. Doesn't anybody want to go to the sports bar and try and pick up the waitress anymore?
So I will keep trying a few more tests, and I hope I will eventually get to one that actually tries to test me on an aspect of programming design, implementation or execution that can't be auto-completed by an IDE faster than I can type. Otherwise its back to the bar. I am POSITIVE that waitress smiled at me, even before she saw the tip I left her....
Thursday, April 06, 2006
So I am Java Architect. Believe me?
I remember doing some recruting for a body shop company I was working for a few years back. It was during the dot boom bubble, and we were hiring anybody who could demonstrate regular breathing (and a few that were dubious). I had offered to help HR assess the technical ability of the candidates as they went through the grist mill. We were gonna hire them, cuz we hired EVERYBODY, but it was helpful to know what they could actually do.
Anyway, one particular fella really stood out. He was in his early twenties, and had applied for the position of "Senior Architect" for a contract we were bidding on. Now, I fancied myself one of those too, but I wasn't no 20 something keener, I was the ripe old age of... well... I was older than that. I brought him in for an interview.
It turns out he had had precisely TWO paying jobs in his whole life (three if you counted summer work mowing lawns), and he had never actually programmed professionally in Java. I was somewhat incredulous, but he firmly stood by his assertion that he was perfectly qualified to be a Java Architect. I remember standing and getting ready to tell him he was ballsy but was still gonna get thrown out of my office, when it hit me.
Just exactly what is a Java Architect?
The IT industry has agonized for years about certifications. We are not like, for example, engineers who have the very well respected APEGGA regulating them in Alberta. APEGGA require all jobs that need an engineer to be certified by APEGGA as being qualified. Companies that do not employ APEGGA certifed engineers can be held liable for improperly built bridges, buildings and so on. Any engineer who wants to be employeed as one must pass the APEGGA certifcation.
One can see the benefits of certification immediately, but why hasn't the IT industry adopted certifcation? How many times have employers wished to hire programmers that were REALLY qualified? And frankly, how many times have I wished I could prove my qualifcations in some emperical fashion?
Well don't hold your breath. Real, reliable and dependable certification in the IT industry isn't coming any time soon. It changes too fast, the main players in certification (Microsoft, Sun, IBM etc) usually play it for profit motives alone, and IT is simply too diverse to come up with reliable measures of training and competence. By the time you have a set of tests constructed and agreed on technolgy has blown right past ya.
All that being said, the reason for this blog was that I stumbled across the JavaBlackBelt site today. Its a cool idea! The basic open source concept taken to the certification arena. Lots of tests on all kinds of Java technologies, including Ant, Struts, Web Services, EJBs, Hibernate and so on. I am going to take a few tests over the next while.
Until then, with respect to my brash young collegue... why am I a Java Architect?
Cuz I say I am!
Anyway, one particular fella really stood out. He was in his early twenties, and had applied for the position of "Senior Architect" for a contract we were bidding on. Now, I fancied myself one of those too, but I wasn't no 20 something keener, I was the ripe old age of... well... I was older than that. I brought him in for an interview.
It turns out he had had precisely TWO paying jobs in his whole life (three if you counted summer work mowing lawns), and he had never actually programmed professionally in Java. I was somewhat incredulous, but he firmly stood by his assertion that he was perfectly qualified to be a Java Architect. I remember standing and getting ready to tell him he was ballsy but was still gonna get thrown out of my office, when it hit me.
Just exactly what is a Java Architect?
The IT industry has agonized for years about certifications. We are not like, for example, engineers who have the very well respected APEGGA regulating them in Alberta. APEGGA require all jobs that need an engineer to be certified by APEGGA as being qualified. Companies that do not employ APEGGA certifed engineers can be held liable for improperly built bridges, buildings and so on. Any engineer who wants to be employeed as one must pass the APEGGA certifcation.
One can see the benefits of certification immediately, but why hasn't the IT industry adopted certifcation? How many times have employers wished to hire programmers that were REALLY qualified? And frankly, how many times have I wished I could prove my qualifcations in some emperical fashion?
Well don't hold your breath. Real, reliable and dependable certification in the IT industry isn't coming any time soon. It changes too fast, the main players in certification (Microsoft, Sun, IBM etc) usually play it for profit motives alone, and IT is simply too diverse to come up with reliable measures of training and competence. By the time you have a set of tests constructed and agreed on technolgy has blown right past ya.
All that being said, the reason for this blog was that I stumbled across the JavaBlackBelt site today. Its a cool idea! The basic open source concept taken to the certification arena. Lots of tests on all kinds of Java technologies, including Ant, Struts, Web Services, EJBs, Hibernate and so on. I am going to take a few tests over the next while.
Until then, with respect to my brash young collegue... why am I a Java Architect?
Cuz I say I am!
Wednesday, April 05, 2006
Spring and Axis - How to beat the XML-Object impedance mismatch
Spring has a whole suite of handy helper objects that help with SOAP, JAX-RPC and Web Services, and in my opinion they are much more powerful than the terse but information-rich user manual gives them credit for.
In particular, during a recent project I stumbled across the part of the Spring manual that described how to set up a JAX-RPC proxy using CGIlib and a thin spring wrapper (the JaxRpcPortProxyFactoryBean class). I thought "hey I will give it a go" and in typical Spring fashion in perhaps 5 minutes I had a small test working that hit a very simple web service.
Adventures in Shirking My Work
With that encouraging result I turned my attention to the web service I was building at the time. The XML schema for this web service ran to several hundred lines, with a couple of dozen types including polymorphism and enumerations. The Spring JAX-RPC proxy had a simple method for specifying the XML-java mappings and I mentally cringed but started grunting my way through the glue code I needed to generate. I didn't get far - I just have never been good at menial tasks (some people would say that about my ability to do just about any task, but lets not go there, shall we?)
In an effort to avoid real work I started poking around in Spring source code, and it wasn't too long before I discovered that Spring uses the Axis JAX-RPC client to provide client-side web service connectivity. Hmmm.... I thought. I was already using Axis to serve my web service,
and I had managed to completely describe the Object-XML mappings in the Axis deployment description (WSDD file). It made me start to wonder - could I use the same type mappings for the Spring JAX-RPC client?
Working Hard to avoid Working Hard
There was a post-processing method on the JaxRpcPortProxyFactoryBean where the type mapping information could be loaded, and after a little experimentation I finally came up with:In the above code, I simply used a couple of Axis calls to read the WSDD file, extract the TypeRegistry information and then hand it off to the Axis JAX-RPC client. It worked first time I managed to properly load the TypeRegistry, flawlessly. Again, typical Spring.
Waiting for the Flash to Hit Me
I was feeling pretty cheeky for the rest of the day, having managed to add a sophisticated JAG-RPC client to my arsenal with only a couple of lines of code. It wasn't till a couple of weeks later when I was about to add a second client (to a different web service) that I really realized how quickly I could put together just about any client from a valid WSDL file and a WSDD deployment descriptor.
I have 4 or 5 working clients now, including both RPC style and Document style web services. And all as a result of feeling too lazy one day to do my real job.
Is there a lesson there? Not one I would tell my kids.
In particular, during a recent project I stumbled across the part of the Spring manual that described how to set up a JAX-RPC proxy using CGIlib and a thin spring wrapper (the JaxRpcPortProxyFactoryBean class). I thought "hey I will give it a go" and in typical Spring fashion in perhaps 5 minutes I had a small test working that hit a very simple web service.
Adventures in Shirking My Work
With that encouraging result I turned my attention to the web service I was building at the time. The XML schema for this web service ran to several hundred lines, with a couple of dozen types including polymorphism and enumerations. The Spring JAX-RPC proxy had a simple method for specifying the XML-java mappings and I mentally cringed but started grunting my way through the glue code I needed to generate. I didn't get far - I just have never been good at menial tasks (some people would say that about my ability to do just about any task, but lets not go there, shall we?)
In an effort to avoid real work I started poking around in Spring source code, and it wasn't too long before I discovered that Spring uses the Axis JAX-RPC client to provide client-side web service connectivity. Hmmm.... I thought. I was already using Axis to serve my web service,
and I had managed to completely describe the Object-XML mappings in the Axis deployment description (WSDD file). It made me start to wonder - could I use the same type mappings for the Spring JAX-RPC client?
Working Hard to avoid Working Hard
There was a post-processing method on the JaxRpcPortProxyFactoryBean where the type mapping information could be loaded, and after a little experimentation I finally came up with:
protected void postProcessJaxRpcService(javax.xml.rpc.Service service){
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setValidating(false);
factory.setNamespaceAware(true);
try
{
DocumentBuilder builder = factory.newDocumentBuilder();
Document document = builder.parse(
new ClassPathResource(classpathAccessibleWSDDFile).getInputStream());
WSDDService wsddService =
new WSDDDocument(document).getDeployment().
getWSDDService(new QName(wsddServiceName));
if ( wsddService == null )
throw new RuntimeException("No WSDD Service named \""+wsddServiceName+"\" was available");
TypeMapping serviceTypeMappings = wsddService.getTypeMapping(SOAP_ENCODING_STYLE);
TypeMappingRegistry registry = service.getTypeMappingRegistry();
registry.register(SOAP_ENCODING_STYLE, serviceTypeMappings);
}
catch (Exception e)
{
throw new RuntimeException("failed", e);
}
}
Waiting for the Flash to Hit Me
I was feeling pretty cheeky for the rest of the day, having managed to add a sophisticated JAG-RPC client to my arsenal with only a couple of lines of code. It wasn't till a couple of weeks later when I was about to add a second client (to a different web service) that I really realized how quickly I could put together just about any client from a valid WSDL file and a WSDD deployment descriptor.
I have 4 or 5 working clients now, including both RPC style and Document style web services. And all as a result of feeling too lazy one day to do my real job.
Is there a lesson there? Not one I would tell my kids.
Subscribe to:
Posts (Atom)
