Author Archives: Lauri

ODP.NET application crash with DateTime parameters

I spent some time yesterday debugging a crashing console application – a proof of concept for a wrapper library I’m writing around an Oracle database. I had successfully read values from the DB – writing that code took all of five minutes – and then tried a MERGE statement.

(Side note: this is the first time I’ve written a merge statement. In fact, while I did know of MySQL’s “REPLACE INTO”, I had no idea that such a thing existed.)

I played around with the statement in TOAD for a while, to make sure it was correctly written, typed it into my editor, added parameter placeholders, added the arguments for the parameters and ran the application. It flashed on the screen and then disappeared.

Which was a bit weird, seeing as it ended with a Console.ReadLine() call. I re-ran the app just to make sure I didn’t accidentally press anything, and the same thing happened. Meanwhile, looking at the results on the TOAD side of things, the value was definitely updated.

I was a bit tired, so it took me a while to notice that the process exit code was 0x80000003 – nonzero, so some sort of error was being reported. Still, even asking the debugger to break on all Win32 errors yielded nothing. And between the statement being executed and the crash, ProcMon reported that all operations the application performed were successful.

I was too tired to make sense of it, so I went home and took a fresh set of eyes with me today. I began to narrow the issue down to a single parameter. At which point I began to get NRE’s instead of crashes. And the stack traces contained references to the special handling of DateTime parameters.

I was doing this:

command.Parameters.Add(new OracleParameter("curdate", DateTime.Now));

Figuring that DateTimes were a special case, I chose this constructor overload instead:

command.Parameters.Add(new OracleParameter("curdate", OracleDbType.Date,   DateTime.Now, ParameterDirection.Input));

After which I re-ran the app, and like magic, everything worked.

Now, realizing that Oracle has more than one way of representing the data contained in a System.DateTime, I understand how there might be a code path or two dedicated for the handling of DateTimes. What I don’t get is that it’s possible for the most common overload of the OracleParameter constructor to result in not an exception, but a full-on application crash.

Anyway, I hope this post saves someone else the trouble. Smile

Fixing broken tools

What sucks about open source is that when something breaks, there’s no guarantee that it will get fixed. What seriously rocks, though, is that you can do it yourself.

As an example of the latter, we’re using dotless for a project at work. I didn’t do much with it, apart from setting up the HttpHandler and letting our frontend developers loose on it. After a few days, though, they ran into an issue: editing an imported less file would not cause the root file to be evicted from the cache.

I figured this was an omission in the caching mechanism, and downloaded the sources from GitHub. When I finally got everything right so that debugging was an option, something weird happened – the path parsing seemed to break, and our includes no longer worked the way they used to.

I dove into the issue, thinking that I’d have to fix it in order to be able to debug the cache issue. When I finally understood enough of the codebase to write the correct tests and make them pass, I suddenly noticed that cache invalidation worked again.

Weird.

Except, not so much when I finally figured it out. The path parsing bug led to imports like “/foo/bar” resolving to “foo/bar”. That in itself was bad enough, mind you, but since the cache code passed the same paths to the CacheDependency constructor, the net result was a cache dependency to a nonexistent file!

The docs for CacheDependency state the following:

“If the directory or file specified in the filename parameter is not found in the file system, it will be treated as missing. If the directory or file is missing when the object with the dependency is added to the Cache, the cached object will be removed from the Cache when the directory or file is created.”

That’s great, but in this particular case, I never want to watch for a file that might get created, so I would have been better served with an error. Smile

Anyway, after this little excursion in yak shaving it made sense that fixing path resolution also fixed the cache.

I contributed my changes as a fork on GitHub in the hopes that it will benefit others as well. Also, it would be nice if my changes were merged upstream, so I wouldn’t have to maintain my own fork. Smile with tongue out 

(I’m fairly sure I botched the Git operations somehow, though – I get that Git is awesome, but boy does it come with a learning curve.)

Anyhow, the important thing is that now our frontend developers don’t have to work with broken tools.

Including indirect, optional dependencies in builds

So I’m writing an application that uses NHibernate as its data access layer. I’m also writing a bunch of integration tasks, and a console driver for them. I’ve written the tests, and I’m ready to fire up the real thing from the console.

The first thing that happens is that my application dies. “Could not load file or assembly NHibernate.ByteCode.Castle”.

Well, bugger.

The weirdness starts when I look at my project’s dependencies. It doesn’t depend directly on NHibernate either, but the assembly gets copied to the output folder. So do most of NHibernate’s dependencies. But not this one. Why is that?

NHibernate comes with a set of byte code providers. While this may seem overkill, I get that people may already be using such a library, and forcing consumers to include yet another one is a no-no. So the dependency to a byte code provider is not a hard dependency. This means that in order to include it in our Visual Studio builds, we need to perform some trickery.

Fortunately, the trickery is rather simple. First, reference the chosen byte code provider in the project that has the NHibernate reference. At this point you may feel compelled to already test the results – don’t bother, they’ll be equally disappointing. Since the reference isn’t actually used anywhere, the build process will skip it.

Instead, what you need to do is add a compile-time reference – that is, directly use a class included in the assembly. Here’s what I did:

    #pragma warning disable 169
    // This reference ensures that we always get NHibernate.ByteCode.Castle.dll
    // as an indirect reference in other projects.
    private static readonly Type proxyFactory = typeof (NHibernate.ByteCode.Castle.ProxyFactory);
    #pragma warning restore 169

(The pragma does away with the compiler warning about an unused field.)

Of course, you can always accomplish the same thing with build scripts, this felt like a workable compromise. As a bonus, I don’t have to worry about this every time I reference this project.

What’s in a Name?

Last week I wrote about the company we’re starting. There was a bit missing from the announcement, though: the name.

“There are only two hard things in Computer Science: cache invalidation and naming things.”

Phil Karlton

When we were setting this company up, we were told that a configuration like ours – four people starting a software development shop – is not typical for a startup.

When we announced our plans, pretty much everyone told us, that with a group like this, we are set up for success. That is to say, we’re not average software developers.

Paul Graham talks a lot about startups. He has this to say:

“If you do everything the way the average startup does it, you should expect average performance. The problem here is, average performance means that you’ll go out of business. The survival rate for startups is way less than fifty percent. So if you’re running a startup, you had better be doing something odd. If not, you’re in trouble.

Startups shouldn’t be like typical companies. As Jouni alluded in a blog comment, we want that to be reflected in the name as well. We’re willing to seem atypical, unusual. A bit offbeat.

Introducing: Offbeat Solutions.

We’ve put together the best team we could imagine, and we most definitely march to our own beat.

“We are dreamers, shapers, singers, and makers. We study the mysteries of laser and circuit, crystal and scanner, holographic demons and invocation of equations. These are the tools we employ, and we know many things.”

— Technomage Elric, in Babylon 5 episode “The Geometry of Shadows”

Any time you need an experienced team of highly skilled software professionals, contact us. Offbeat Solutions is happy to rise to the challenge.

My Biggest Career Move Yet

What a summer it has been. I took one of the most interesting vacation trips I’ve ever had – a three-week InterRail romp through Europe. We met interesting people, spent approximately 4 000 km on trains and drank a lot of beer. I don’t think I’ve spent that long without really thinking about work since I got started.

Getting really relaxed and out of work-mode was a really good idea. You see, before we left, I had made some plans, and I’ve been acting on the plans since I came back.

I’m switching jobs again. But this time both the reasons and the new job are a bit different: I’m setting up shop with Sami Poimala, Jouni Heikniemi and Riikka Heikniemi. My very own company, something I’ve been dreaming about for years now.

Exciting times!

 

So what’s the plan?

Well, since you asked, the long-term plan looks a lot like this:

Pinky and The Brain

 

 

However, that’s going to take some time to achieve, so the near-term plan looks more like this:

Will code HTML for food

 

In all seriousness, though, when you put the right people together, good things tend to happen. And I can’t think of a more fitting group of people to accompany me.

Chad Fowler says that when you play music, you should always strive to surround yourself with players that are better than you.

I think I just did. Smile

I’d like to thank all my soon-to-be-ex-coworkers at Sininen Meteoriitti. It’s been a brief, but fun ride together, and I won’t forget any of you any time soon. If you miss me terribly, you can always have someone make a pot of bad coffee and listen to some Eduard Khil!

 

Stay tuned for the next installment.

Post Haste

Meh, so I screwed up with Live Writer, and instead of using an earlier post as a template, I overwrote the old post. Fortunately Google Cache found the old post, but I had to do some updating to fix links that didn’t quite work, and it’s possible that RSS subscribers have been seeing random weirdness. :-(

Chapter 7: A Tool for Developing Self-Awareness

(This is part 7 in a series of posts where I document my progress through reading Becoming a Technical Leader: An Organic Problem-Solving Approach by Gerald Weinberg, answering the questions at the end of each chapter)

1. How many reasons have you thought of already for not starting a learning journal?

None, really, since the blog posts I write qualify as one.

2. If you have a journal of any other writing you did in the past, take it out and review it.

“What do you notice first? What personal changes does it measure? Are you depressed or elated that you’ve changed so much, or are you depressed or elated that you haven’t changed very much? If you don’t have any records of your own past, aren’t you sorry you can’t measure your progress?”

I tend to think whatever I did in the past sucked. Turns out that while my knowledge (especially of the “shit you know you don’t know” variety) has expanded, my writing was just as good (or bad, whichever way you want to look at it) back then. :-)

3. Once a day for the next week, do some familiar task in the following way:

“As you do each step of the task, say to yourself (out loud if possible): ‘Now I’m doing such-and-such.’ For instance, you might say, ‘Now I’m opening the drawer to get a pair of socks. Now I’m choosing a color. Now I’m matching the one blue sock with its partner. Now I’m closing the drawer. Now I’m sitting down close to my shoes to put on my socks. Now I’m putting on my right sock.’ You may pause at any time to ask yourself questions such as, ‘Why am I putting on my right sock first?’”

I tried this on a small-scale production deployment – I kept saying what I was doing out loud, to a microphone. I was recording a log of what I was doing, and the things that affected my decision making.

The first obvious effect was that others in the office looked at me real funny. The second was the more interesting one.

Every now and then someone comes to me asking for instructions. Typically it involves a programming or sysadmin task, and I find myself unable to articulate the exact steps, or the things I do to determine my next action. Thinking out loud while doing things made that possible.

This tied in nicely with something else: I was discussing the nightmarish 17h production deployment with our CTO, and he kept asking me questions about why we made various decisions. Eventually I was forced to admit that I couldn’t remember. That prompted an idea that we should maintain a log of some sort when we do these things.

4. Which shoe – right or left – do you put on first in the morning?

“Promise yourself a five-dollar present if you can put the other one on first tomorrow. Put a note on the breakfast table so you’ll be reminded to check your bet after your shoes are on. Keep doing this until you succeed.”

(On a side note, I’m also reading through “Pragmatic Thinking and Learning – Refactor Your Wetware”, and it proposes similar exercises.)

Left. On the first day I remembered this later in the day. On another day I was already putting the first shoe on, when I caught myself. :-)

5. What are your legs and feet doing right now?

Moving to a beat and shuffling restlessly.

6. Set some personal development goal for yourself for the coming year.

“Note in your journal your reactions as you set this goal, and note your progress toward that goal in your journal.”

I already have – I want to learn to give presentations. I’m way behind on my progress, but my first presentation is coming up in a week or so. :-)

7. Read at least one autobiography of someone you admire.

“Note in your journal those parts that are particularly surprising to you, and those parts that move you most.”

The only autobiographic book I’ve read, and am likely to read, is Obama’s “Dreams from my Father”. While I might not personally admire Obama – I don’t have that sort of a connection to him, since he’s not “real” to me – I do admire him somewhat.

The surprising part was his addiction. I didn’t see that coming. The most moving bit was his own sense of self-worth, or lack thereof, when he was doing volunteer work.

8. As you read this book, write the answers to these questions in your journal

That might just be what I’m doing here. :-)

 

Previously: Chapter 6: The Three Great Obstacles to Innovation  Next up: Chapter 8: Developing Idea Power

Post Crunch Mode

The previous weekend was a disaster.

I’ve been taking part in a project, immersing myself in SharePoint to better learn it. We had a production deployment deadline on the Friday, just before last weekend. It didn’t exactly go as planned – some bits weren’t as finished as we thought, others were altogether missing. I worked a 14-hour day on Friday, and then we came back on Sunday. That was even worse. We began working around one in the afternoon, and I got to bed around 6:15 in the next morning, after a mad 17-hour dash to force the thing together by sheer willpower.

I slept about five hours, then went back to work for a nominal four hours. On Tuesday, I was at the office for a full day, but I felt like my brain was drained. I was barely functioning. The same was true on Wednesday, at which point I decided to take Friday off altogether. Thursday was a national holiday, so all together it meant four days of rest, which did me a world of good. In addition to that, I went to TEDx Helsinki on Wednesday at noon, so it was a rather light week. Still, I kept feeling the effects of the all-nighter for a long time.

I’ve been reading “Pragmatic Thinking and Learning”, and I came across a passage that described this phenomenon rather well:

“Not only are you less creative when battling the clock, but there’s a sort of after effect: a time pressure ‘hangover’. Your creativity suffers on the day you’re under the gun and remains depressed for the next two days as well.”

Yeah, I can attest to that.

The twisted bit is, our work culture rewards this kind of behavior. There’s generous overtime pay, the appreciation of superiors, acknowledgement of the heroics by peers and what have you. It’s all geared towards working under time pressure. That is, towards working less effectively. Not to mention the time wasted recovering.

(Mind you, I’m not talking about timeboxes – it’s a good idea to limit the time you allocate for a single activity – but real time pressure is a different beast altogether.)

It’s curious, how after reading my “Slack” and “Peopleware”, I’m still just as susceptible to being pulled in as I ever was.

We can do better than this. The madness needs to stop.

Chapter 6: The Three Great Obstacles to Innovation

(This is part 6 in a series of posts where I document my progress through reading Becoming a Technical Leader: An Organic Problem-Solving Approach by Gerald Weinberg, answering the questions at the end of each chapter)

1. Knowing what you had for dessert is an application of general self-awareness to the question of health.

“How aware are you of your own health and how it affects your leadership style? How do you feel right now? Take an inventory of your physical condition, and describe how it currently affects your performance as a leader.”

I’m in poor shape, although I’ve been worse. I feel tired, and I’ve got all sorts of aches and pains all over the place. On occasion, it plays merry hell with my ability to focus, and I’m sure that if I were healthier, I’d also seem happier, which would certainly have a positive effect on people around me.

2. Poor health is an obstacle to innovation and just about everything else.

“How is your long-term health affected by your career? What is your health going to be like in the future? If you have a hard time answering that question, what makes you think your health is not under your own control? What are you doing to keep it under your own control? How will it affect your career in the future?”

Stress and longer work days affect the way I eat – the more tired I am, the less likely I am to prepare a proper meal. Instead, I tend to opt for a pizza. In the future, I’m going to go for less stress and a healthier diet. Keeping that in mind might affect the choices I make, career-wise.

3. In answering the previous two questions, did you respond that your health was “no problem”?

“What does that tell you about yourself?”

No, I didn’t. It tells me I’m not fooling myself. :-)

4. Do you know your IQ?

“Do you let other people know? Does knowing your IQ affect your ability to lead? How?”

Not accurately, but I’ve done the Mensa online test, so I’ve got a rough idea. I don’t let other people know, because I’m fairly sure it would only serve to provoke feelings of either superiority or inferiority in others, neither of which seems beneficial. It’s been quite a while since I last thought about my IQ before reading this question, so I can safely say it doesn’t affect my ability to lead in the least.

Come to think of it, I tend to assess people based on their performance, attitude, competence and suchlike, instead of any perceived ‘intelligence’.

5. Do you like to take tests?

“If you knew you were assured of doing well, would you like to take a test? What if you were assured of doing poorly? What if you had to take the test, but were never to find out how well you did? What do these questions have to do with leadership style?”

Yes, I do. If I knew I’d do perfectly, I wouldn’t bother . In every other case, I’d do it just to confirm whether the assurances would hold.

If I wouldn’t have the chance to process how well I did, I wouldn’t see the point either.

If this says anything about my leadership style, it’s that I base my work on feedback.

6. Find some multiple choice quiz and go through it in the following way:

“Instead of picking one answer, take each answer in turn and give a good reason why that could be the answer. Then give a good reason for some answer that isn’t among the choices.”

7. Next time you’re in a meeting and several ideas are brought up, apply the technique of the previous question.

“That is, make sure you give a good reason to the meeting’s participants to explain why each idea could be the solution you’re seeking. Then offer at least one more.”

Both of the questions above ask me to do something, but not report the results. Instead of posting the answers, I’m going to go with what the exercise made me think.

In the multiple choice question, I felt like I was exploring the possibilities. It was the same with the meeting, except for one detail: with the other participants, it kind of made me feel like I couldn’t actually answer the question, for a while. Eventually, I did pick an option and put my (considerable) weight behind it, though.

 

Previously: Chapter 5: But I Can’t Because…  Next up: Chapter 7: A Tool for Developing Self-Awareness

1 2 3 4 5 14