The Great White North

Thursday, August 28, 2008

Javascript is Awesome Now

This year I've been learning two languages: Javascript and Perl (I'll talk about Perl later). I have a few years of "experience" with javascript. I mean onclick="alert('Bork!!!! you broke it...')" counts right? I remember about 3 years ago when the AJAX buzz first came to my attention. We were using it on our project for the first time. I did a few simple XMLHttpRequest things and it was cool. But I gave the UI guy on our team a bunch of grief for the "ridiculous" amount of javascript he was writing:

WTF are you thinking, making a whole domain model in javascript? And using javascript to write html snippets or pretending to do OO programming? We do all that stuff on the server side.... Don't you know javascript sucks?


Well it did until recently. I've started working on a few things that require some serious javascript. Now I want to apologize to my former teammate, you knew what it was all about long before I did. I should have listened back then because javascript is dead sexy now! jQuery is amazing and I really like Greasmonkey as well. I'm finally starting to understand how javascript the language itself works and how that relates to running it in the browser environment. It's really opened my eyes to the power of functional programming as well. Passing around functions is great! I find that it spills over and I get frustrated writing java sometimes now. I'll be coding along thinking: ok now all i have to do is pass in this function here... DOH!


Most recently the whole namespaces pattern really helped me structure my code in a way that made sense. For the longest time I was trying to figure out a clean way to lay out all the different callbacks so that they weren't all nested 12 deep and tangled up. Now I'm starting to get good reuse and I can easily separate related code out into separate files.

This same hurdle keeps coming up. Every time I try to learn a new programming language one of the things I worry about the most is where do I put the files? How do I make packages/namespaces/modules? Where do 3rd party plugins/libraries/frameworks go? I need to understand that structure--I guess my mind just works that way. In .NET I have my VS projects and namespaces all there keeping my code in order. Same with java, packages are built into the language and components have well defined structure (WAR, EAR, JAR files). It doesn't feel like I know the language until I can create a "Project" from scratch and know where to put the files and how to structure the code in those files.

So I can finally say I've crossed that milestone with javascript. Now I can build something useful with it. To me that is awesome.

Wednesday, July 4, 2007

Essentials of Corporate Vocabulary

I won't claim anything unique about my observations on how the English language has suffered at the hands of Corporate America. But that wouldn't stop me from throwing my thoughts into the mix now would it?

Currently my personal favorite is leverage.

In physics class this was sort of a synonym for torque. At work it's a verb. I hear this word all the time at the office and generally speaking (unless we're talking about moving a heavy file cabinet or something) this is what is meant:

From MBA Jargon Watch:

"...'leverage' is used indiscriminately to describe how a resource can be applied to a particular environment or situation. 'We intend to leverage our investment in IT infrastructure across our business units to drive profits.'"

Usually you only hear the big-wig manager types using this type of talk in their high level "strategic" type meetings. Which is fine you see, what concerns me is when what I'll call other non-big-wig types (such as lowly developers like myself) start using it as well.

Please excuse my IT bias in advance; is it just me or is this term used particularly in reference to us techno geeks? Think about what they're saying. "We'll leverage our development resources to provide blah blah blah...." or the like. To me that just sounds like a politically correct way of saying "Let's get the monkeys down in dev on that blah blah blah..."

We all need tools that'll get us more for less I suppose. It just has a different tone when that tool is you. I digress... Just stop and think the next time you're about to leverage some resource. To the guy upstairs, YOU'RE the monkey, buddy.

Sunday, June 24, 2007

What's a Requirement? (Part 2)

I think it is instructive to examine this same question in another sense. What is a requirement? Or what is the definition of the word itself. If it were clear to everyone, a lot more software projects would succeed.

I've noticed that everyone has a different idea about what the definition is or should be. Go watch a requirements meeting between some developers and customers sometime, you'll see what I mean. Technical types seem to think mostly in terms of the implementation, while customer types tend to think more about the business process etc. But then again, people don't always follow their role entirely either--you get business people diving into deep implementation details, and developer monkeys trying to dictate how the customer should run the business. All of this makes answering the "What's a requirement?" question pretty challenging to say the least.

In school they said requirements are definitely very separate from any implementation details. Then there's Functional Requirements as opposed to just straight up ones. The "Functional" denotes constraints on how the system should accomplish the regular requirements. In practice I've seen requirements that call out details at a much lower level almost naming the class that will be written. I don't know where this low level definition came from it's probably just anecdotal. So things are already getting fuzzy again.

My point is maybe there isn't one true definition of requirement to rule them all, but for your team there probably should be. It's probably worthwhile to sit down and say "When I say requirement I mean <insert your favorite definition>". Hopefully doing this will avoid situations where people are upset because "Hey that's not a requirement!" (AKA: We don't have to build that, right? Because I'll have to work 16 hr days to hit the date). Or after delivery when the customer asks about feature x which he swears was a requirement.

Sounds nice but in reality I think sitting down to formalize the definition of requirement would just result in the same confrontations only now we'd be able to argue about the definition of requirement as well as whether or not that export button was definitely in this release!

Don't give up on me yet. I don't think the situation is hopeless. I want to give you my super abstract definition of requirements to rule them all. It will solve all of your software development woes. It's also free for everybody. In my mind requirements = decisions. I like to think of it that way because decisions have to be made from the 10000 ft overview level down to the package name. Which people need to be involved in any given decision obviously varies.

The key to making it work is realizing that decisions will have to be made in all stages of the project. So spend less time blaming people and arguing about why we humans are not always clairvoyant. Spend more time making the right decisions with the information you have. You'll make a lot of decisions at the beginning of the project. Then things will change and so will the decisions. Things that nobody thought of will come up at the worst possible time. Instead of pretending like you had already thought of that why not just help make the decision.

It sounds nice on paper doesn't it?

Thursday, June 7, 2007

ApplicationContext Tricks

Part of our project is a standalone J2SE app with a good 'ol static void main. We plan to have several instances of this application running at the same time on the same server. Each instance will be configured differently as well. However, we only want to deploy one copy of the jar. We're using Spring so the issue is basically how do we initialize our ApplicationContext such that it points at the right configuration settings?


First off, we'll have application instances that require completely different Spring config files. That's easy enough we just pass in a parameter and we're done. It gets tricky where we'll need multiple app instances running off the same Spring config but with slightly different settings for some beans. For example, instance A needs a bean to point at a server on port 9000 while instance B needs the same bean to point to a different server on port 10000.


As it turns out, the solution is relatively simple:


public static void main(final String[] args) {
    String configPath = args[0];
    String propertiesPath = args[1];
    PropertyOverrideConfigurer configurer = new PropertyOverrideConfigurer();
    configurer.setLocation(new FileSystemResource(propertiesPath));
    AbstractApplicationContext context =
        new FileSystemXmlApplicationContext(new String[]{configPath}, false);

    context.addBeanFactoryPostProcessor(configurer);
    context.refresh();
    // rest of your main code
}

We make use of Spring's PropertyOverrideConfigurer which basically allows you to override property values specified in the config file with values found in a standard java properties file. Usually you would just configure this as a bean within your Spring config file. But we get sneaky and programmatically add it to our application context before the beans are initialized. This lets us choose which properties file we want to load at run time. Now we don't have to write a complete Spring config for each instance of the application we want to run. Easy as pie!

Saturday, June 2, 2007

What’s a Requirement? (Part 1)

Considerable effort goes into answering this question at the beginning of some if not most software projects. Obviously the developer needs to know what to build. This calls for some meetings! A few of the stake holders begin to gather the “requirements” into some form. It turns out the requirements can be anything from a high-level drawing on a conference room whiteboard, an email chain that everyone has at least part of, or an agonizing 300 page numbered outline nested incredibly deep in a

1.      incredibly

a.       silly

b.      pointless

                                                                           i.      attempt

2.      to predict

        a.       everything

                     i.      up front.

Naturally the results of these exercises are deemed to be completely accurate and a date has either already been set or is set at the end of the meeting. So this is all well and good, but we all know the fun is only just beginning. Everyone gets down to work but it is only a matter of time until some new meetings are scheduled to again discuss exactly what is a requirement. So why is it that these subsequent meetings always seem to take on a more dramatic tone?

Let's begin

My friend has been blogging for a while now over at return Hot.Code() ?? Junk.Code(); He has inspired me and I thought I might have some fun blogging about software development and corporate life. They say if you want to become a better writer that you should write. So here goes nothing...