Wednesday, December 31, 2003



I spend a lot of time in front of reflective surfaces (computer monitors and my TV), and so I occasionally catch a glimpse of myself when I don't mean to look at myself. Before I realize who I am looking at, my first impression is often that the guy looks pretty dull-witted, tired, and unhappy. I hope that's not how others see me.

There have been occasions when I am reading the C2 wiki, and suddenly realize I am reading something that I wrote myself long ago. Thankfully, the impressions I get from reading my own writing are more positive than those I get from looking at my face. Sometimes I cringe a little, and many of my opinions have changed dramatically, but that guy usually seems to be pretty smart and reasonable.

Who am I? What do other people think of me? Of those two questions, the first is more important, but I'm not too proud to admit that I care a lot about the second also. Self-knowledge and self-confidence are great, but if other people think I'm a ninny, maybe they're right. I don't know how to get an honest, objective assessment of myself, but the occasional unknowing glances in the mirror may be the truest view I can get of myself.

Ultimately, that's what this blog is all about: trying to get a look at myself and what I am doing, with a detached view. The writing itself clarifies my thoughts for me, and when I re-read these entries in the future, I hope to gain additional insights about who I was when I wrote, and how I am changing.

Tuesday, December 30, 2003



[Note: The Remoting.Corba project is "dead", and has not been active for several years. If you need .NET-CORBA interoperability, I recommend checking out IIOP.NET. Archived Remoting.Corba documentation is still available via The Wayback Machine.]

Remoting.Corba is an open-source .NET library that provides interoperability between the .NET Framework and CORBA servers/clients, using the .NET Remoting architecture.

I started this project to learn more about .NET Remoting and to apply my knowledge of CORBA. My basic goal was to be able to write .NET programs that interacted with CORBA-based applications using typical .NET Remoting code. For example, if a CORBA server supported this IDL:

interface Adder {
    long add_longs(in long arg1, in long arg2);
    double add_doubles(in double arg1, in double arg2);

then one could write a C# program that invoked the server, without need for an ORB, using code something like this:

// standard .NET Remoting stuff
using System;
using System.IO;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Messaging;

// Remoting.Corba
using Remoting.Corba.Channels.Iiop;

namespace MyExample
    // define .NET interface mapping for IDL interface
    interface Adder {
        int add_longs(int arg1, int arg2);
        double add_doubles(double arg1, double arg2);

    class App {
        // entry point
        static void Main(string[] args)
                // register IIOP channel with Remoting
                ChannelServices.RegisterChannel(new IiopClientChannel());

                // Use a standard CORBA stringified object reference for the server
                string ior = "corbaloc:iiop:localhost:9999/Adder";

                // create the proxy to the server object
                Adder server = (Adder) Activator.GetObject(typeof(Adder), ior);

                // execute some methods on the remote object
                Console.Out.WriteLine("1 + 2 = {0}", server.add_longs(1, 2));
                Console.Out.WriteLine("1.0 + 2.0 = {0}", server.add_doubles(1.0, 2.0));
            catch (Exception ex)
                Console.Error.WriteLine("Exception: " + ex.ToString());

The IiopClientChannel class from the R.C library takes care of generating and interpreting the CORBA IIOP (Internet Inter-ORB Protocol) messages and pumping them through the .NET runtime. There is also an IiopServerChannel class that can be used to implement CORBA servers using .NET Remoting.

It was pretty cool when it worked. The .NET Framework's Remoting architecture is very open, allowing programmers to plug in their own network protocols and messaging formats. I used some custom attributes to provide information needed by the CORBA engine that could not be gleaned via data types and reflection mechanisms.

Unfortunately, while the .NET Remoting architecture is open, it is not well documented. If all you want to do is send a SOAP message via some protocol other than HTTP (for example, via UDP, via message queues, via e-mail, etc.), then it is pretty easy to plug your own stuff in. But if you are doing anything more complicated, then you will quickly discover that the only way to figure out what's going on inside .NET is to look at the Rotor source code.

The project was valuable to me in that I learned a lot about .NET and C#. It was also gratifying to see other people using it and expressing interest in it. I was especially excited when it was mentioned in Don Box's Spoutlet, and when Miguel Icaza started playing around with it in Mono. It even got a few pages devoted to it in a Microsoft Press book!

I wrote this code during a period when I was not working any paying jobs, so I was always hoping I would find somebody willing to pay me to add features. There were a few nibbles, but users were generally able to add features themselves instead of hiring me to do so. I talked to some people at Microsoft and Inprise about potential deals, but nothing came of it.

I have put a few projects on SourceForge, but this was the first one where I got any significant contributions from other developers. Michael Sawczyn created an IDL compiler. Other developers did some bug fixing, refactoring, and feature additions. It never reached the "critical mass" needed to keep it going after I lost interest, but I think it was close.

I worked on R.C for a few months. I lost interest in it due to several factors:

We hit limitations of the .NET framework when trying to figure out how to map remote object references back to objects in the same process. The only way to do it was to use reflection to invoke private methods of internal .NET classes. That prospect triggered enough of an "Ewww!" response that I decided further work was only going to make me feel worse.

I used a wiki to distribute the "documentation" for the project. I liked how the wiki turned out, but there were few contributions to it from anyone except myself.

So what did I get out of Remoting.Corba? Obviously, I learned about .NET Remoting and some more about the internals of CORBA. I got practice writing C# networking code. I made some contacts in the industry. I wish I could have used R.C on a real project, but that might have taken the fun out of it.

Monday, December 29, 2003


My Failed Contracting Career

After my last permanent position, I took a few months off from work, and then tried to start a career as an independent consultant/contractor. After many years of hearing about the freedom enjoyed by consultants, and the exhorbitant fees they charged, I wanted to get my piece of the action. People encouraged me to give it a try, because I had many of the traits associated with independents: desire for variety, lots of knowledge, no trouble voicing my opinions, and no dependents who would go hungry if I couldn't find work.

My primary motivation was the desire to be independent. I wanted that whole be-you-own-boss thing. I wanted to be able to work less than 40 hours a week when I felt like it. I wanted to be able to choose which assignments to take. I wanted to be able to decide what new computer to buy and which development tools to use.

Unfortunately, this was mid 2002, and as all you people more clued into reality than me know, that was a bad time to try to start a contracting career. Established contractors were having trouble finding work. Those who were finding work had to charge fractions of what they used to charge.

The biggest reason I failed as a contractor was that I didn't have the business sense for it. I didn't know anything about marketing. I didn't know what my market niche would be. I didn't have a lot of contacts in the industry. I hoped I could just post my resumé on my web site, and jobs would start rolling in.

I did get a few calls, but most of them were for things that I wasn't really prepared to do. For example, my resume lists Oracle and OpenVMS. I was contacted by someone who needed me to provide training for employees who would be administering Oracle on an OpenVMS system. Ten years ago, when Oracle on OpenVMS was what I was doing, I may have been able to do it, but it had been so long that I didn't think I could do a reasonable job, so I had to pass. There were several other similar opportunities that I passed on as well.

In hindsight, I wonder if I should have taken a few of those jobs. I wouldn't have known what I was doing, but it would have been work and it could have led to something I knew better. I have never been comfortable claiming to be able to do things that I don't really know I can do. Other consultants don't have that problem.

I did manage to land a contract with a former employer. They did pay me well, but unfortunately only had a few hours of work per month for me to do.

Eventually, I gave up on the idea of being completely independent, and signed up with one of those organizations that hires people out as contractors. I got a good gig with them, but for no more money than I would have received as a permanent employee, and without security or benefits.

So, I gave up on contracting, and got a permanent job.

Will I ever go independent or start my own business again? Maybe. I think I do have a strong entrepreneurial streak, and a disdain for working at the direction of others. But I'm not going to try it again until I have a better idea about what products or services I will provide, and who will pay for them.

Sunday, December 28, 2003


New is Good?

Python is the coolest language ever.

I've never written a real Python program. But after reading the language spec and a few tutorials, and writing a few simple programs, I am fascinated with it.

Like many other programmers, I love to play with new things. Learning is fun. New challenges are fun. Unfortunately, we often confuse enthusiasm with evaluation. If we want to use something, it must be superior to all that junk we don't want to use anymore.

C++ is a horrible language. (Only Perl is uglier.) But when I am writing important code, I use C++ instead of the "new" languages. I hate it, but I know it well. It's limitations infuriate me, but I never get surprised. Other developers deride me for using MFC and the Visual C++ wizards, but I am more productive and less error-prone with those tools I've used for years than I would be with the "better" tools that I don't know.

Am I missing out by using old bad tools instead of new cool tools? Maybe, I don't know.

The distinction between "new" and "old" is not necessarily chronological. For the past few years, I have been writing Palm OS programs using Forth. Forth is certainly not a new language, having been around for decades, but it was new to me. I loved the way I could create programs with a relatively small amount of code. It was interesting to do all my programming and debugging on the handheld device, without benefit of a desktop-based cross-compiler and debugger. I remember the experience fondly, but I can't kid myself into thinking I was more productive with Forth than I would have been with a C compiler.

I once felt differently. In college and in my early professional years, I was constantly learning about new programming languages and other development tools. I'm sure that the study of all those things made me a better programmer. However, I also believe that concentrating on a couple of languages for many years has made me a better programmer than I would be if I flitted between languages constantly.

Ultimately, all development tools and technologies suck, and the new ones don't make things that much better. The hard part of software development is figuring out exactly what the program needs to do. The level of effort required to do that is independent of the programming language used. Being able to pick the right tool for the job is important, but usually the right tool is the one I know how to use most proficiently.

Python is the coolest language ever. I'll continue to believe that until I actualy have to use it.

Saturday, December 27, 2003


Welcome to My Blog

My name is Kris Johnson. For eleven years, I have been a computer programmer. For the first few years, I enjoyed it. Now, I've grown tired of it, but I don't have any other marketable skills and I don't want to move into management. So, I do what I can to improve my programming skills in the hope that I can work less hard. I also like to exchange ideas with others about how to make the programmer's life easier.

Writing is a great outlet for me. It helps me focus my thinking, and gives me a way to vent my frustrations. I also like to think that others benefit from reading what I write (although I've seen no evidence of that). For a while, I interacted with the community at the C2 wiki (a.k.a., "Ward's Wiki"). I learned quite a bit there. But that community has changed, and I don't think my writings will fit there anymore, so from now on I'll write here.

To avoid trouble, I'm going to refrain from writing about my current job. If I do write about my job, it will be disguised so much that nobody will know. However, most if not all of what I write will be about what I've learned about software development, and about what I still hope to learn.

I may also occasionally post an "off-topic" item such as a movie or book review, or just some odd thought I had while eating breakfast. But don't worry; I don't have that many thoughts.

I invite others to send comments or complaints about my writings to If you are a wiki kind of person, you may also want to leave messages for me at

To find out more about me, you can look at my resumé or my website. Links to a few C2 pages I am proud of can be found at

This page is powered by Blogger. Isn't yours?