Welcome to GuerillaProgrammer.com Sign in | Join | Help

Syndication

Tags

    No tags have been created or used yet.
Don’t jump ship!

Being a consultant can be a lot of fun.  You constantly get to work on new and exciting projects.  You have the opportunity to make a real contribution to your client’s business.  You even get a degree of control over you ultimate destiny.  It is not necessarily an easy road to walk but it definitely has its rewards.

 

Not everybody is cut out to play in this arena.  It is not really a question of talent.  The truth is; in most fields talent is not really the qualifier: just look at our political class.  The real qualifier is just showing up day after day and for some people that can be a real battle.  Internal dialog saying “I suck”, “I’m not good enough to be here”, “They’re going to find out that I suck and then fire me” and so on does nothing to help you and none of it is true.  The problem comes about when that internal dialog drives a person to action.

 

In one case it drove a person to quit a project just as things were getting interesting.  He told his client that he couldn’t handle it and quit.  Just like that.  He did complain a bit ahead of time, but nobody took it that seriously.  If developers aren’t whining about things they are either busy actually working or asleep.  So nobody took the whining seriously.  All the same he quit; gave the manager his two weeks notice and began wrapping up his affairs.

 

The head slapper here is two fold.  First he quit without having already arranged a new project and second he quit in middle of a project.  The second problem is the bigger of the two it just isn’t as immediate.  The first problem though is a bit dumb.  If you know that your project is wrapping up you start a search for the next one.  Six weeks is a lot of lead time and enough to ensure that you’ll have a gig well in hand when your current one wraps.  Recruiters will take care of this for you, but it takes a bit of management to get what you want out of them.

 

Quitting in middle of a project though is huge.  In very simple terms: Don’t ever do that!  It will eat at you like cancer.  By quitting in middle of a project you can pretty much write off that client forever.  They won’t trust you again for any reason.  Second, people in IT get around and so does your reputation.  The manager you just quit on in a year or two will be in a new company that you want to work for.  Guess what happens when you name comes up?  Your resume goes in the trash can.  You might be the hottest Silver Light developer in four states and it won’t matter.

 

The lesson is this: if you sign up for a gig you work it until it is done or the client cancels the project.  Your word, a signature on a contract, has to mean something.  Quitting in middle of a contract is an indication that your word can’t be trusted.  A consultant that can’t be trusted is an unemployable consultant.

Posted Monday, October 06, 2008 8:47 AM by jakew | 0 Comments

Funny - failure

Ironic that I write about failure suggesting that if you are going to do something that it is better to fail in a way that leaves a smoking crater than to just wither away and disappear.  And then bring on the clowns!

 

Not sure causing a financial meltdown and stuffing Western Civilization in the corner is what I had in mind.  But I guess if you are going to leave a smoking crater behind as your legacy you can’t do much better.

Posted Wednesday, September 24, 2008 8:57 AM by jakew | 0 Comments

Status reporting

Because I tend to do a lot of behind the scenes work in the projects that I get nobody really sees my work.  They know if it doesnt work, but there really isnt anything to see.  This type of work tends to eat up fairly large chunks of time between spikes.  The result is that there can be a few days between deliverables which can leave customers wondering what it is that I'm up to.  To take care of this I tend to do daily updates.  This way I'm able to tell my client what I'm doing.  It also causes me to chunk my work down a little so that everyday I have something accomplished even if it can be tested in the larger system yet.

 

I realize most developers hate doing status reports.  So do I.  Nobody actually reads them and if things do get sideways nobody is going to care.  But here is thing - for whatever reason people actually read my status reports and as a result I tend to not get in to those sideways situations very often. 

 

Part of the reason people don't read status reports is because a lot of the time they contain pretty useless crap.  I've seen reports from some of the big 5 consulting companies that were chalk full of it.  Why the hell would anybody bother with that?  I tend to make mine short and sweet with short entries listing briefly what I did.  You don't need an entire dissertation.  The code is in subversion so they can go see for themselves.  Just a quick line saying "fixed the web-service so that it authorizes users based on domain group membership".  That is all the customer needs.  If they want more they can email you and ask whatever questions they need.

 

I also raise flags this way.  "Having trouble getting the information about the ISAM file from the mainframe group" was responded to by the PM the next day with "who are you working with?  I've talked to their manager and he says they'll help."  However, give some thought to raising issues and risks because attentive managers will show up asking questions.  Absolutely raise risks, but carefully articulate what you see as a risk and be prepared to talk about it. 

 

My goal with status reporting is two fold: communicate with my client and document what they are paying me for.  Ok, they’re not really paying for the status report they are paying for my solution to their problem.  But as I said earlier – sometimes I go dark for a while and I like my client to know what I’m up to.  The more important aspect is the communication.  By telling them what I’m doing and point out problems that I see I engage them in conversation about the project.  It keeps the project alive and can keep it from crashing.

 

Hopefully, you do something for a status report.  Don’t be fancy.  Just read the news – short, simple and concise. Your client, employer, customer, parents, kids, next door neighbor’s dog will thank you. 

 

If they bother to read it. ;)

Posted Wednesday, September 24, 2008 8:52 AM by jakew | 0 Comments

This is cool

Was reading a post about Cross-site Request Forgeries at Coding Horror and noticed an ad at the bottom.  I don’t usually click ads, but it promised a free book.  Who can say no to a free book?  It’s almost as good as free cookies!  Anyway that took me to SmarBear Software’s web-site where I did the usual opt-in marketing thing.  But I started looking around at their stuff: Code Collaborator looks like a pretty cool product.  I’d like to play around with it.

 

However, what really stuck me as cool is that their marketing campaign worked on me.  They’re giving away a book, which is a cost to them, but by doing this I’m looking at their product.  I’ll end up playing around with it and if it does what they say it does I’ll recommend it to my clients.  I’m not sure of the math for the conversion, but I doubt the book costs that much print and I the banner ads are probably pretty cheap.

 

Really cool strategy.  I’ll be sure to use it in the future.

Posted Wednesday, September 24, 2008 8:39 AM by jakew | 0 Comments

Failure

Last year I set out to take over the world with a tool I had developed. It seemed like a great idea. Hell, it still might be. I had written tools like it for three or four previous clients, it addressed a fairly mundane problem that most IT organizations have.

So I had written this tool, tested it, debugged it, created an installer for it. I even wrote some docs explaining how to use it. Back in the early 90s this things would have been killer! So I got the product together pretty well. I created a web-site.

And then I was completely lost. There’s a web-site, it’s right there. Customers are going to be showing up and this is going to rock. I don’t need no stinking investors. Investors, who needs them? Angles, VCs and other type of investors are just headaches and they take 90% of your work and in the end you get nothing.

Well….I got experience. I didn’t need investors for that. Overall, I’m pretty ticked about this. Not because I didn’t sell anything (didn’t sell 1 copy, in fact I couldn’t even give it away). I ticked because of the way in which I failed.

I failed because I was afraid of failure so I did not try as absolutely hard as I could have. I made a few lame attempts at marketing. I spammed some people. I did a half-assed ad-sense campaign. But that was about it. I didn’t blog regularly (never really have), I didn’t focus on technical forums where the people who influence the buying decisions are. I didn’t show it off at every opportunity. In fact, I didn’t a pretty damn good job of keeping it a secret.

I didn’t fail because I needed money. There are plenty of ways to advertise on the internet that don’t cost a dime. Just a little time. Ok, maybe a lot of time. I can’t really say for sure having not invested the time.

So yeah – failure sucks. And as I just schooled myself – fear of failure only brings about one thing: FAILURE. I’ll fess up: I really don’t want to be that guy. Which guy? You know, that guy, the one who did that thing that was so miserable it’s surprising his wrists didn’t slash themselves. So in trying to avoid being that guy, you become him. It is sort of like riding a motorcycle. People wreck on bikes because they look at the thing they are trying to avoid and they automatically steer themselves in to it. It is called target fixation. You don’t want to be known as a failure so you avoid doing anything that might cause failure so you do nothing and become known as a failure. That worked well.

Here is the thing: failure in this fashion, the go hide in a corner and quietly wither away type, doesn’t hurt right away. It nags at you, it bugs you. It calls you up late at night to remind you that you could have done something. Almost anything would have been better. It is not a sharp pain like you get when you nearly amputate the tip of your index finger. That type of pain guarantees that you’ll do things differently next time. This pain is subtler, trickier. It tries to convince you that it is ok, to just take it. It tries to convince you to just live with it. Don’t try too hard, just keep you head down and do you time.

Seriously – if you are going to fail; fail spectacularly. Make sure there is a mushroom cloud that covers at least the surrounding twelve counties when you go down. Make sure everybody knows about it. Make it worthy of a YouTube video. Be that guy. The one who went down in a screaming ball of fire that took out three city blocks. They had to call out FEMA to clean up the mess.

So here I sit having failed through not trying. Time to try it another way.

If you care to see the corpse it is over there. If you want a copy let me know and I’ll send it over (email jakew at this domain: guerillaprogrammer.com). I’m going to use the source code as part of a class I’m putting together on Windows Workflow Foundation. Figure that if it didn’t make a good product it ought to serve as a great classroom example of how to do workflows, write custom actions and do a few other neat workflow related tricks.

Oh – in NLP it isn’t failure. It is feedback. The universe’s way of saying “well that sucked”.

Posted Wednesday, September 17, 2008 10:41 PM by jakew | 0 Comments

Learning to ask for help

Everybody should take pride in the work they do. Software developers spend a lot of time studying, training and practicing. So when we hit a tough problem we tend to grind on it. We’ll google, search MSDN, try bits of sample code, everything. Well, everything except ask people nearby for help.

I’m not entirely clear on the reasoning for this behavior. I’m not sure if it is a pride thing or something else. In many ways I lean toward something else. Specifically, people (everybody in general) don’t keep track of time. How many times have you set out to do something that will only take 5 minutes only to discover it took all day?

How do you stop the cycle so you don’t waste time? You can’t really learn everything there is to learn so studying harder isn’t the answer. Carrying around a stop watch won’t work either because how do you know you need to start it?

I don’t really think you can avoid the small time sinks we run in to through the course of the day. Fifteen minutes here, forty five there. It does add up, but it is generally manageable and good PMs are able to factor this in to their schedules. It’s the big two or three day sink that needs to be avoided. Things like status reports, daily scrums and time boxes can help bring them to light. Others on your team may not be able to solve the problem for you, but by raising the awareness of the problem you help set expectations and avoid surprises.

I hate being on a project that looks like it is on time but then during one meeting you discover that a critical feature isn’t done and needs about three weeks of work to be completed. My favorite line goes something like “yeah, we slipped 6months on the schedule last night”. Literally, you got to a status meeting on Monday and everything is good to go. On Tuesday the new architect starts asking questions and you discover that what appeared to be a safe and sane project is in fact way off schedule or worse – can’t even be measured.

Being up front about problems you are having on a project is a safer bet (but somewhat uncomfortable at times) than delaying notification. Yeah, it sucks telling your client that you are having a hard time with a project. It sucks worse losing the client because the project because nobody confronted the problems to get the project on track.

Posted Wednesday, July 09, 2008 5:16 PM by jakew | 0 Comments

CSS Level 3 & 4

This past weekend (31/05/08 & 01/06/08) I went to Barber in Birmingham Alabama to do levels three and four with California Superbike School. Last year in August I went to Mid-Ohio and did levels one and two.

My experience at Mid-Ohio was life altering. Kieth’s wild bunch did a great job introducing me to the track and were quite successful in getting me completely addicted to riding on the track. Nothing can compare to it.

After level one and two I did close to ten track days locally and gained a little bit more experience. Wanting to go faster and do it even better I eagerly signed up to do level three and four. I signed up way back in February and the wait for school was a drag. But the day finally arrived.

Before I get in to the school stuff I do want to mention the museum at Barber. It deserves its own post (and I’ll get to it). You really need a full day and perhaps two would be better. There are so many bikes that it is really overwhelming. Everything from bicycles with motors attached to real MotoGP bikes are on display. There are even a few cars (but we don’t really care about them). There is so much though that at a certain point you just blue screen and walk around zombie like. Zombie maker or not it is worth the risk of visiting. You also get a great view of turn 7.

Speaking of turn 7, I stood there for a long time watching Keith’s students doing their track drills wondering why they were going so slow. I even shot some video of them going around the turn (here). It looks like they are crawling. However, as you get closer to the ground level you see that the drop is pretty extreme and the corner is pretty tight. Then you actually get on the track and do it and it’s a pretty hairy corner. I loved it, but getting in to it fast wasn’t easy.

Level 3 school

Level 3 is all about how the rider interfaces with the bike. How you lock your body on so you are secure and able to hang off without upsetting the bike’s suspension. How to quickly move from one side of the bike to the other, again, without upsetting the bike’s suspension.

The coolest thing to me was the first drill – the hook turn. It is a really simple idea but the affect on my riding was huge. The idea is that if you move your body forward and down you will cause your bike’s front suspension to compression causing the bike to turn in more without increasing the lean angle. How is this useful? Say you enter a turn and you are sort of leaning off and you find yourself running wide. Without having to lean the bike more, just drop your shoulders forward and down.

In my case the change in the line was dramatic. It was fun to enter a turn essentially sitting straight up and down and then dropping my shoulders in as I passed the apex. Later this would have some interesting consequences, but not until level 4.

The next bit was about moving around on the bike. I hang off and it can be difficult to get from the right side to the left side quickly without upsetting the bike’s suspension. The rest of the day focused on this. Learning to move from one side to the other in a way that kept the bike stable and you in firm contact at all times. It turns out you can get from one side to the other very quickly and keep the bike rock solid. Just be ready to have some very sore legs.

I’m not going to go too much in to this. Go take the class. It isn’t really difficult to do, but I really think having the coaches along helps a lot. Go take the classes, they are worth every penny.

When I did level 2 last year I didn’t get to do the lean bike so I made a point of taking it for a spin. It was not what I thought it would be. If you see pictures of it you think that it will hold you up. It won’t. It has out riggers that have shocks that help stabilize the bike so you can lean it way over at low speeds, but they will not hold you up if you screw up. I didn’t. But I thought it would hold me up enough that I’d be able to drag my knee around the parking lot. I didn’t accomplish that. What I did accomplish was getting my body position right. The coaches moved my butt back so I wasn’t humping the tank. I’m a big guy (6’ 2) with long arms and legs. I’m also heavy at 200lbs, so the bike would really prefer that I keep my mass as far back as possible so the suspension can do its magic. My 848 is a lot like the ZX6 in form so the same position will work for it.

During my 3rd session one of the CSS coaches chased me around with the camera bike so I could see what I was doing. He noticed that I didn’t seem to have good reference points (more about that later) and when I move and seem to shimmy a bit, sort of funny once you notice it. I put the video on LV here.

For comparison I cut out a clip of the coach after he had finished videoing somebody else. The speed that he goes through the turns is cool to see. You can see it here.

Anyway, I was able to get my body position setup and the coaches sent me back out the track. They use the same bike in level 4 as a slide bike. In the slide bike exercise they have you actually spin up the rear wheel while the bike is leaned over. If not done properly, spinning the rear wheel while leaned over will lead to a high side – the bike chucks your squid ass up in the air and you get to do a Superman in to the pavement. The trick is to not whack the throttle closed. Instead you keep your body leaned off the bike and let the bike stand up while holding the throttle still. I didn’t get a chance to do this exercise – next year.

In my opinion, of all the levels, level 3 is where magic happens. I think the difference you will experience in your riding abilities from the morning to even will be mind blowing. During my 5th session I was railing the bike around the turns at a really fast pace. I ended up having to use most of 4th gear down the straights with only light braking in to most of the turns. Given what was revealed on Sunday, I’m not sure it would have been wise for me to go any faster.

Level 4

Level 4 is a big change of pace compared to the other levels. The way CSS is setup when you get to level 4 you have covered all the material. Now you take over and tell them what you need to work on. You are assigned an on track coach and you have a ‘consultant’ who works with you off track. My class ended up working with Dylan Code and Keith Code most of the day. I actually got a fair amount of attention from Keith because of my reference points (or lack there of).

Going in to class I wanted to work on Quick Turning and 3 stepping. Quick Turn is a level 1 skill, but it is really important because it helps you either use less lean angle or go faster (and sometimes both). It turned out that I wasn’t too far off on my quick turning and when I started doing it right it had a pretty big impact on my lines. Basically I started having to back off my lean angle (not turn so much) because I was on the apex too soon. That is actually cool b/c an alternative to not leaning so much is going faster. However, as we soon discovered – going faster might not be such a great idea just yet.

After the first session my coach said I was doing the quick turn very well so we moved on to the 3 step drill. The idea of the 3 step is to use 3 reference points going through a turn. The first reference point is where you turn it (quick turn), the second point is where you apex and the third point is where you are done with the turn (the exit). To do the three step, as you come up to the turn you identify your turn point, once you are confident you are going to hit it you turn your head and find your apex point while keeping the bike on its line going to the TP. In your peripheral vision you track your TP and when the bike reaches it you quick turn and get on a line that goes through your apex point (they don’t call it an apex point, I do). The third step is basically a repeat of the first two steps. Once you know you are going to reach your apex, find that exit point. All of this is essentially looking through your turn, but you are being very deliberate finding reference points to use to navigate your way through the turn.

Well, I discovered that I had turn in points, but that was it. So my three step was more like a step and a half. I was going really fast and having a blast. My knee pucks are nice and marked up, but this was actually a bad situation. Here is the problem – I was getting through the track by the seat of my pants. I just ‘knew’ where to do things. I had reference points, I just was not aware of them. Not being aware of them makes it easy to get rushed, stressed out and then have tunnel vision. Tunnel vision leads to off track excursions. Or worse. When we got off track my coach and I talked about this. Without me saying anything he was able to tell that I didn’t have reference points. We decided that more important than more quick turning or three stepping I needed to go back out and work on identifying reference points.

Then my consultant go a hold of me. This go around was the Guru himself. We started talking about what I was working on and in Keith’s fashion he started asking me questions. Based on the eye brows climbing up his forehead he didn’t like what I was saying. He was asking me about turn one. I was able to tell him all about it. How there is kitty litter on the outside and behind the kitty is a little parking lot. Behind that is a fence and behind the fence is some shrubbery. I was able to tell him about where the coaches would park their bikes at the top of the hill to wait on their Padawans to come around (or maybe take a well deserved break). I was able to tell him about how I was trying to make my line run wide so it would cross the second seam and then back out to the marker for the start of turn two. I didn’t tell him about the concrete rumble strip on the inside of turn 1 where I wasn’t apexing because I never looked at it. I could have told him about how there are divots in the side of the hill inside of turn 2 but I thought I should leave well enough alone at this point. He didn’t seem too impressed with my visual acuity.

Then he asked what I was using for my turn in reference points. He asked if I was using the yellow markers he had put on the ground. He really didn’t like my answer. He asked if I thought he didn’t know where to put them. Well, I sort of interpreted his writing to say that there wasn’t really a line and that any line that allows you to keep rolling on the throttle is a good line. My line achieved that. However, upon reflection I actually do know why the markers were placed where they were placed.

Anyway, the result of our conversation was that I really needed to work on getting reference points. We could make some other observations, but there is no reason to be rude.

The markers and the reference points have everything to do with how fast I was going and why I couldn’t really go much faster. What I started to experience on Saturday and on Sunday was that I was going fast enough to cause the corners to blend together. Turn two changed dramatically as I carried more speed out of turn one. Turn six and seven, eight and nine, ten and eleven, twelve into thirteen and then fourteen. As I went faster my line became more important. Just being able to keep rolling on the throttle became just the cover charge to the party. Knowing where I was and what I needed to do at that time became the rent to stay there. In order to go faster I needed reference points. Oh, and I needed to know how to brake and change gears.

Apparently you brake and then down shift. Don’t do it the other way around. I didn’t hurt anything b/c I generally capped myself at 13.5K and the ZX6 goes to 16K (shift light starts to flash at 14K). However, had I been trying to press things and was at 15K and down shifted without braking first – bad things could have happened. To me and the bike. Again – Mr. Code’s eyebrows are very expressive.

I already mentioned not getting to do the slide bike. That doesn’t mean I didn’t get to slide a bike though. It rained. I mean it really rained. What the F I was doing out on the track trying to collect reference points in the rain I have no idea – but I was out on the track. We started off in a light sprinkle so we were riding at a decent pace and I was doing my best to grind off my knee pucks. Then it opened up. I slowed down. I thought I had slowed down enough. But coming around turn four (nice left hand carousel turn) I felt the back tire start to give way. It probably only moved an inch, but it felt like it slid forever. I stood the bike back up and kept going. Then my coach took the lead and was point at reference points he was using. At the bottom of turn seven I felt the rear tire start to slide again. Again, no biggie stood the bike up. No worries. I’m lying. I’m getting a bit concerned and slowing down more. My coach is cool and slows down too. We keep on working. Coming around turn 13 it does it again. Three slides in five minutes is my limit. Unfortunately the pit out exit is behind me and they get real upset if you turn your bike around on the track so I have to finish the lap.

I slowed down to granny speed and waved other riders passed me. Yellow flags were out, which means no passing, but I figured that I was as far over and off the racing line that nobody would care. By the time I got back around to the pit lane there was plenty of traffic in front and behind me with the same idea.

My conclusion from my second go around with CSS is that I have a good handle on the mechanics of riding a sportbike around a race track pretty fast. What is now really clear is that until I get good at collecting good reference points and learning to connect turns together I don’t need to go any faster.

I really cannot recommend CSS highly enough. The program Keith has put together is amazing and I really believe that it works. His coaching staff does an amazing job. The off track staff keeps things running smoothly.

One thing to keep in mind with CSS though – it is not a track day. It really is a school. If you are paying CSS to just get track time then you are wasting your money. There are much cheaper ways to get track time. Sign up for the school – slow down and do the drills until you get them. The material isn’t really difficult, but you need to slow down so you can practice it.

It is also interesting to observe how many people are repeat level 4 students. In my group there were 15 level 4 students – 8 were first timers. I plan to repeat level 4 next year. Hopefully I won’t have a problem with reference points.

I’d also like to mention the eleven year old kid who was at the track doing level 4. Seriously – 11. Actually, he had just turned 11 on Friday. He was out on a 125cc GP bike and was killing the adults on their ZX6Rs. Watching him enter corners was jaw dropping. Because he weighed nothing and the bike weighed nothing he could hold a tighter line than the ZX6s. So he’d go railing through the inside of the turn while the adults wallowed around on the outside. I look forward to seeing this kid on the WSBK grind in about ten years if not sooner.

Posted Thursday, June 05, 2008 4:35 PM by jakew | 1 Comments

Falling off Bandura’s curve

In NLP one of the topics my class covered was called the Bandura curve. Albert Bandura was a physc who, like most physcs do, studied human behavior. Particularly he looked at how people’s performance compared to their expectations. What he found was that the two didn’t always sync up.

It goes along like this: You start doing something new and your performance sucks. No big deal you expected that so performance and expectation are in sync. You practice and you start doing better than expected. Say you win a game you expected to lose. Your performance exceeded your expectations. Naturally, you raise your expectations. You go out for another game expecting to win but you lose. You are out of sync. Worse because you’ve not actually improved, you expectations are what have been changing your, performance will stay roughly the same or even deteriorate.

The next part to the curve is a plateau. Eventually your performance will max out. You will simply not be able to do it any better no matter how hard you try. This is actually really dangerous because if you are maxed out there is only one obvious direction to go in – decreased performance. How do you avoid this? Change. You cannot reach the next ‘level’ of performance doing this the same way you were doing them before.

In one of the exercises we did we stood in a circle. The coach threw a ball to one person, that person threw it to another and so on until the ball had been touched by each person in the group and thrown back to the coach. Once we had that down we timed how long it took to throw the ball to 18 people in the group. It took us 21 seconds. Could we do it any faster? Yes, we tried again and did it in 19. We couldn’t get the ball around any faster than that. However, based on the rules we were given we rearranged ourselves so we were in order and we were able to pass the ball around in 7 seconds. Could we do it faster? Yes, we tightened up the circle and had one person hold the ball and rub the ball across the top of our hands. It took less than a second. I’m sure you’ll agree there is no way we could have thrown the ball around the circle to 18 people in less than a second. This is a prime example of the idea contained in the Bandura curve. Once your performance has maxed out you have to change the way you do things in order to achieve higher performance.

In many ways I’m on a plateau now. I’m about maxed out in terms of what I can do as a software developer. Or at least a software developer running Visual Studio on his workstation. In order to get more performance from myself I have to change the way I do things. I have to make decisions about how I want to deliver value to my customers. I can only deliver so many lines of code per day and the value of those lines is fairly fixed. If I want more I have to change what is being delivered.

And by the way – being on a plateau is not the most comfortable place to be. Whether you’re talking about professional development or personal things (like weight loss or exercise) plateauing is a fact of life. The trick is to not quit and find a way around it. Try different things, get help, but most of all – don’t quit.

Posted Tuesday, May 27, 2008 11:20 AM by jakew | 0 Comments

NHibernate - crash course (cont)

Forgot to mention that I've also not looked in to how NHibernate does its thing.  At the moment I'm too rushed to worry about that, but I think it is something I need to know before going to production.  Wouldn't you want to know too? 

Posted Wednesday, May 14, 2008 1:23 PM by jakew | 0 Comments

NHibernate – my crash introduction

 

I just started a new project with a new client. They have decided to use NHibernate for their data access layer. Having not used NHibernate or any of the current ORM tools this was a nice opportunity to learn something new.

NHibernate is framework that will manage persistence between your .NET objects and a back end database (SQL Server). It is an ORM tool like SubSonic, and ADO.NET Entities to name a few. Personally, I’ve avoided ORM frameworks in favor of treating a database like a database and an object like an object.

Part of the reason I’ve not bothered to learn any of the ORM frameworks is that they generally suck in my opinion. Yeah, they offer rapid application development, but I’ve not really seen anybody rave about their performance or scalability. Restaurant equivalent might be McDonalds – quick food, but they aren’t winning any awards from Zagats.

Given what an ORM tool does performance and scalability shouldn’t be a huge hurdle. In the end they all issue SQL queries against a DB. The issues crop up in design though. We want to program in an Object Oriented environment but databases are simply not OO. ORMs try to make databases look OO, but seriously – they are not. So that leaves you a choice – take the blue pill and play along with the ORM tool and pretend the DB suddenly became OO. Or take the red pill and live with having to make the translation manually.

Having lived in red pill land all this time I’m willing to give the blue pill a shot. Beside, I can always revert back to hand coding everything.

Anyway, what follows here is my introduction to NHibernate and the manner in which I’m using it.

Getting Started

First off you can grab the latest version of NHibernate from http://www.hibernate.org/. Hibernate is a Java framework that NHibernate was ported from and their web-site has a wealth of information for support. To get the actual stuff you need, click on the download link and then on the “NHibernate” download link which takes you to SourceForge. Once you’re on the actual download page get the msi. I’m using 1.2.1.GA. There is a 2.0 but it is in Alpha so I’d wait if you plan to take your stuff in to production anytime soon.

After you run the MSI you will have everything installed in Program Files. There are 3 files in the docs directory. Ignore the PDF because it duplicates the NHibernate .API.chm file (or is it the other way around?). The docs are ok, but I really think the intro stuff could be done better to make it easier for n00bs to ramp up.

After reading their quick start I almost gave up. I don’t care about Cats, my client already has a database and I need to get at it. I decided to write a simple sample application using Northwind as my source database. Just make a simple form that shows all the products in a listbox. Nothing complex for now.

Cheating

But before going on, let’s cheat a bit.

All database code is essentially the same stuff. Sure table names change, columns change, but we are always doing the same thing over and over. Sounds like an opportunity for a template. In previous episodes I talked about using the T4 template engine to do stuff. I seriously don’t have the time to be reinventing the wheel so I’m just going to start using CodeSmith.

Instead of having to write the entity classes and their DB mapping files go grab a codesmith template to help out: http://www.intesoft.net/nhibernate/. There are a few issues with this template because the author has not updated it in a very long time. However, it will do.

Run CodeSmith, open Simon’s template. You’ll see three templates – choose the one named “NHibernate.cst” and run it. Set your DB connection, which directory CodeSmith will write the files to and the other properties and then run the template. Viola! All of your entity objects are generated from the DB’s schema. It’s not all beer and skittles though – you’ve got to go in and clean up a few things first.

1. The XML namespace is wrong. The template generated one xml mapping file for each table in the database. The problem is that the namespace version needs to be 2.2 not 2.0. Just a quick search & replace job.

2. One-to-one mappings don’t work. All of the one-to-one mappings in the xml files are wrong. Go in and make the one-to-one element self closing, add a property-ref attribute whose value comes from the column tag below. Delete the column tag and the closing tag.

3. In many cases you will end up with properties that have the same name as the class. You’ll have to fix that.

4. The assembly name and the .NET namespaces need to be correct.

At this point you should be able to put all your stuff in to a project and compile it. Actually, I still had issues to address. In my opinion the template follows foreign keys too much leading to some odd class compositions. However, it is easy enough to remove the unneeded mappings and make the relationships look right.

Obviously you can go back and edit the template to fix a few of these issues (namespace, one-to-one) with very little trouble. Making the template chase foreign keys better and some of the other problems are a bit more challenging. Overall though I think investing the effort would be worthwhile if you are looking to cut down development time.

Configuration

NHibernate needs some configuration information to work. To get started grab the configuration information used in the quick start documentation (NHibernate.documentation.chm). You’ll have to change your connection string and the mapping information. There are several ways to tell NHibernate where to get its mapping file, my favorite right now is to embed the xml files as a resources and use the mapping tag to tell it the name of each resource and the name of the assembly with the resource. I tried just using the assembly tag but it didn’t work. I might have done it wrong so YMMV.

Once you have the configuration stuff done you can get down to actual coding.

Coding

The idea is that I don’t have to write any DB code. I just call some API, tell it what I want and it figures it all out for me. Overall NHibernate delivers. You have to setup a Session Factory object and then get a Session object. Once you have the session object you can start work. The first bit takes two lines:

clip_image002

Pretty easy. Then to get my products out of the database:

clip_image004

Just dump the products in to a listbox and we are done with this demo.

What wasn’t Covered

This is only a crash course that barely even scratches the surface. NHibernate will let you do all the CRUD operations. It will also call stored procedures, build queries so you aren’t always dragging the entire table back.

A simple query might be something like:

clip_image006

The funny bit here is that the “Id” thing is the Id property on my Product object. NHibernate will translate that to ProductID through the mapping file. I initially had some trouble with that, I was putting ProductID as the parameter because that is what the SQL where clause is going to use. NHibernate’s error message wasn’t very helpful for figuring this out, it took a few minutes of staring at the mapping file to see what was going on. It’s actually kind of cool.

I haven’t updated any of my objects and saved them back to the database. I’ve also not created a new record or deleted one. I’ll get to that stuff soon enough.

Wrap up

This should give you enough to get started using NHibernate. I’ll cover some more stuff as I go on. While I’m not agog at what it does, I’m lazy enough to just go with it. I could write a template to do my DAL the old way, but way? I already have a template that just needs some clean up? Also, DB stuff isn’t what gets me excited so why bother?

Where I really want to get to is using NHibernate for CSLA’s data access layer. There are plenty of templates for CSLA, so if I can get the two working together then I’ll really be smoking.

Posted Wednesday, May 14, 2008 1:21 PM by jakew | 0 Comments

Hands on Grinder 1

This is a really simple example of Grinder. In this case I’m just going to move a file from one directory to another and rename it in the process.

First, start the workflow designer and create a new workflow. Drag the file copy activity on to the workflow. In the properties area set the Source File Path to ${FULLPATH} and set the destination file path to c:\temp\test\output1\${FILENAME}_${CLIENTID}${EXT}. Now save the workflow and then build it.

clip_image002

Once the workflow has been built go to the configuration editor. Open the existing Configuration.xml file (it will be in Grinder’s folder under Program Files). Now right click on Workflows and select add workflow:

clip_image004

Give the workflow a name. Then click the ellipse button next to the strong name text box. This will let you select the workflow assembly you want. Because a single assembly can contain several workflows you will be asked to select the workflow in the assembly:

clip_image006

After you named your workflow and selected the workflow from an assembly click the update button. We are now ready to setup a file type.

Right-click File Types and select Add File Type. Give you file type a name. Specify the file pattern that will be used to pickup the files. For instance if you are going to process work documents with Grinder you would use *.doc as your file pattern. Then from the drop down select the workflow that will be used to process the files. After you have done that click update.

Now go to directories and add a new directory to monitor by right clicking and selecting Add Directory. Give the directory a name, choose the path (C:\temp\test\client1). Then select the types of files to find in the directory, you can choose as many as you like.

We also want to add a CLIENTID property to the directory so Grinder can use that information during processing (remember how we setup the FileCopy?). Click on properties and add a new property. In the properties form – first click add, then click on the new property. The change its name and value and click update. Then click the Update button at the bottom.

clip_image008

After you have added your property and closed the dialog click update to save the changes to the directory. Now save the configuration file.

We have now done everything we need to do in order to run our sample – mostly. First – create the directories you are going to be using (C:\temp\test\output1 and c:\temp\test\client1). If you just installed Grinder it will not be running yet. Either go to the services control panel and start it or use the Grinder Monitor to start it.

After Grinder starts it will eventually scan the directories for files to be processed. When that happens you will see the file *.docx you created disappear from the client1 directory. If you go look in the archive directory you’ll see it. You will also see it in the output1 directory renamed with the CLIENTID you entered.

This is probably the absolute easiest thing to do with Grinder. Hopefully though it give you a small inkling of what it can really do.

Posted Tuesday, April 29, 2008 5:21 PM by jakew | 0 Comments

Grinder tools tour

Grinder comes with 4 tools along with the service itself. Here is a brief description of each. I’ll go in to great depth soon.

Grinder Configuration Editor

This is the tool where all configuration for Grinder is done. You specify which workflows are available, what types of files are being processed, and which directory the files are to be picked up from.

Grinder Workflow Designer

The workflow designer is a basic workflow editor that will produce Workflows specifically for Grinder. It provides access to Grinder’s workflow activities.

Grinder Service Monitor

This is a simple diagnostic tool that allows you to stop and start the grinder service. It will also register and unregister the Grinder service with the Windows Service Manager.

Grinder Console

The Grinder console is a console version of the Grinder service. This allows you to run Grinder without installing it as a service.

Posted Tuesday, April 29, 2008 4:04 PM by jakew | 0 Comments

Grinder’s Macro language

In order to make workflows easier to write and more flexible, Grinder provides a library of macros that are used to substitute values inside workflow actions. When grinder is making the substitutions it will search for values in the following order:

  • Symbols
  • File Properties
  • Directory Properties
  • Service Properties
  • Environment variables

The format for a macro is ${macro}. For example ${FULLPATH}. Grinder will search for a macro named FULLPATH and substitute the value for ${FULLPATH}.

The following are the built in symbols:

Macro Description
GUID  Expands to a GUID
EXT The extension for the file being processed
FILENAME The filename without the full path for the file being processed.
WORKITEMFILENAME The name of the file being worked on.
FILENAMENOEXT The filename of the file being processed without the full path or the extension.
DIRECTORY The path for the current file being processed.
FULLPATH The full path to the file for the current file being processed.
RND Generate a random number between 0 and 1000
ARCHIVEPATH Path to the archive directory
DATE

Expands to the current date based on the supplied format string. For example – DATE(yyyyMMdd) will generate 20071008.

Date format macros:

yyyy

year, It will always be formatted with 4 digits, which

will cause an issue for the year 9999.

MM month. It will always be formatted with two digits
dd day. It will always be formatted with two digits
HH

hour in twenty-four format. It will always be formatted with two digits

mm minutes. It will always be formatted with two digits
ss

seconds. It will always be formatted with two digits.


The format string is the standard data format string used by .NET’s DateTime object. Any valid DateTime format string will work here.

As an example:

When setting up the File Copy action the source file would use ${FULLPATH} in order to get the path to the file being worked on.  To copy the file to a client directory and add a date time stamp you would use the following:  d:\clients\${CLIENTID}\${FILENAME}_${DATE(yyyyMMdd)}.${EXT}.

Using Grinder's configuration editor will allow you to associate macros like CLIENTID to a directory.  This provides the flexibility to move files around based on the file type, the directory is came in or other variables.

Posted Tuesday, April 29, 2008 3:57 PM by jakew | 0 Comments

Installing Grinder

Right now Grinder ships as a single MSI file with everything in it. The installation is pretty straight forward but there are two things to consider first: user account and archive directory.

Because Grinder runs as a Windows service it needs a user account. Further, because Grinder will be moving files around and deleting them it will need a user account that has been granted a few privileges. If the directories you are going to be monitoring are on the local machine and Grinder won’t ever have to access a remote directory then a local user account will work fine. However, if Grinder is going to be working in file shares on remote systems you will want to use a domain account instead.

Grinder needs an archive directory because on occasion bad things can happen. Part of Grinder’s defense strategy is to archive all file before processing them. This way if something bad does happen you can at least get the original file from the archive. The bad thing about this strategy is that if you are handling really big files your archive can get out of hand.

I’m going to assume we are installing Grinder on a development workstation. For the user account create an account named ‘sysop’. For the archive directory I use C:\temp\archive.

With those two details out of the way we can run the MSI. Click through the usual stuff (other than the EULA there aren’t any options). As part of the installation process Grinder will pop-up and ask you for the user account and archive directory. The installer will validate the user account before going on.

When the installer finishes the Grinder service will have been setup and be ready to run. It won’t be started yet though. You can do that through the Services panel applet or the Grinder Service Monitor.

Posted Tuesday, April 29, 2008 2:18 PM by jakew | 0 Comments

Getting back to Grinder

I’ve been a bad wanna-be entrepreneur and not done a good job promoting my products and services. Time to fix that oversight. Back in February I talked about my product Grinder. It is a service that processes files using Workflows. It is an ideal replacement for BizTalk’s file adapter. It is also useful for integrating applications with SharePoint libraries. Fundamentally though it is about replacing all those programs that get written that just watch a directory and then ‘do something’ to the files that are found.

Over the next few days I’m going to talk a lot about using Grinder and how it can be used. I’m also going to talk about how to write Workflow actions that can be written to extend the functionality of Grinder for your specific situation.

If you are interested in getting a copy of Grinder please contact me (jakew@guerillaprogrammer.com) and I will send you a copy to try out.

Posted Tuesday, April 29, 2008 1:58 PM by jakew | 0 Comments

More Posts Next page »