Sleeping on an office floor

We're finally finishing up a real death march project. Several times over the two week crunch period, I along with several others had to pull all-nighters. It was an unfamiliar experience for me. A different life/career experience, but not something I want to start doing every quarter.

One night I fixed a showstopper bug in some inherited code. More on that later. Anyway I was just on standby if anything broke in my module. At around 1:30 AM I could barely stay awake. So I decided to grab a nap during the lull. In our office there was once a lot more people, so there is an empty upstairs area where there used to be a manager's office that is now vacant. I went up there and layed down on the carpet floor. I rolled up my jacket underneath my head to lay on. It was comfortably warm upstairs.

The sysadmin has a work area just outside the vacant office. There is a server there. The server creates a pleasant droning sound. Listening to the server droning, I was able to fall asleep for a good hour.

I awoke around 2:30 feeling much better. I had a thought when I woke up to sleep another hour and check on the testers downstairs then. But virtue got the best of me and I went downstairs to check how things were going. They were just getting frazzled about some new error. Luckily this time it was a configuration problem in a simulator and not a software error. I pointed out what they needed to change and they fixed the configuration and continued testing. Good thing I went back downstairs when I did.

You'd be surprised when you're that tired how comfortable the carpet floor of a vacant office can be.

Oracle PL/SQL function to convert dotted-quad IP address to number

This snippet is an Oracle PL/SQL function that will convert an IP address from dotted-quad format (like 66.102.15.100) to the corresponding numeric value. This can be useful in a table where an IP address is entered by the end user in the familiar dotted quad format and a trigger is used to keep the numeric value of the IP address in synch. For the application, just use a regular expression to validate the IP address entered by the user.

FUNCTION dottedQuadToNumber (dottedQuad IN VARCHAR2)
RETURN NUMBER AS
BEGIN
  RETURN (
    (substr(dottedQuad,
            1,
            (instr(dottedQuad, '.', 1, 1) - 1))
            * 256 * 256 * 256
    ) +
    (substr(dottedQuad,
            instr(dottedQuad, '.', 1, 1) + 1,
            instr(dottedQuad, '.', 1, 2) -
            instr(dottedQuad, '.', 1, 1) - 1) * 256 * 256
    ) +
    (substr(dottedQuad,
            instr(dottedQuad, '.', 1, 2) + 1,
            instr(dottedQuad, '.', 1, 3) -
            instr(dottedQuad, '.', 1, 2) - 1) * 256
    ) +
    (substr(dottedQuad,
            instr(dottedQuad, '.', 1, 3) + 1)
    )
  );
END dottedQuadToNumber;


Oracle PL/SQL function to convert numeric IP address to dotted-quad

This snippet is an Oracle PL/SQL function that will convert an IP address from numeric format to the corresponding dotted-quad string.

FUNCTION numberToDottedQuad(dottedQuad IN NUMBER)
RETURN VARCHAR2 AS
    item NUMBER;
    part1 VARCHAR2(3);
    part2 VARCHAR2(3);
    part3 VARCHAR2(3);
    part4 VARCHAR2(3);
    divisor NUMBER;
BEGIN
    item := dottedQuad;

    divisor := 256*256*256;
    part1 := TRUNC(item / divisor);
    item := MOD(item, divisor);

    divisor := 256*256;
    part2 := TRUNC(item / divisor);
    item := MOD(item, divisor);

    divisor := 256;
    part3 := TRUNC(item / divisor);
    item := MOD(item, divisor);

    part4 := item;

    -- piece them together for the result
    RETURN part1 || '.' || part2 || '.' || part3 || '.' || part4;
END numberToDottedQuad;


gosub and design patterns

I started programming in BASIC on the Commodore 64 back when I was in Jr. High. At the start I used the GOTO statement to control program flow.

After a few months I was excited because I found out about this useful command called GOSUB. The GOSUB command allowed me to reuse blocks of code and the system would conveniently return control back to the calling point when the GOSUB block was done.

Later on in university I took the intro to programming in Pascal. An early topic in the course was "subroutines", expressed in Pascal using procedure and function. When they were talking about subroutines I immediately recognized this as GOSUB.

So "subroutine" can be considered a design pattern. It's a generic way of doing things that can be reused in many contexts. With GOSUB, I was using the subroutine design pattern without knowing about the formal label for it.

I've never read Design Patterns. I don't really plan to. A number of people I work with have. I've never seen anything in their code that is startling that makes me think I'm missing something important. My theory is that it's like with GOSUB. I already use the stuff, I just don't have the special labels for it.

If I ever lose my job and am out of work I'll have to read it so that I can be considered "competent" by the shops where it's a big deal.

Casey

The genX'ers may remember Bill Casey from the 80's. He was the CIA director for Ronald Reagan. Casey was involved in some way in the Iran Contra scandal. Unfortunately shortly after the scandal broke Casey died suddenly.

After Casey's death, suddenly everyone was blaming Casey for everything about Iran contra. It was convenient to lay it on Casey. He was involved in it. And since he was dead he couldn't defend himself.

I've seen and heard about this Casey effect in some high tech offices. Basically there's someone who was at least somewhat important for some time. That someone may have made some mistakes along the way or been disliked by some. That person is eventually fired or quits and is no longer around.

After he's gone and can't defend himself, he then becomes a Casey. Every problem, failure, screwup and lost sale is blamed on him. This blaming can go on for a while. A friend of mine is an electronics engineer in BC. He said there was a Casey in his office. That guy was blamed for stuff that happened after he left that he wasn't involved with.

I suspect the Casey effect is not limited to just high tech.

Fixing the UI EJB Disconnect

Where I work we use Java/J2EE with the "beans and screens" model. We use JSP/struts for the user interface, backed by business layer EJBs. The business layer EJBs are backed by a database abstraction layer. We don't use entity beans - regular business layer EJB is verbose and overhead enough, thank you. We do quick HTML mockups of the UI screens before formal JSP development begins.

The beans and screens model works pretty well. Business logic is well separated from presentation. We have some solid EJB developers and some solid UI developers. I haven't done any UI myself, and that doesn't really bother me.

What can happen with beans and screens is the “UI EJB disconnect” problem. What happens is the EJB developer goes off and implements some methods as he sees fit. The UI developer later on attempts to wire the UI screens to the EJB methods. What I've seen is that the EJB developer doesn’t seem to know what signatures he needs to create. The UI developer often doesn’t have the methods that are needed to build the screens. This disconnect causes lost time on the UI side thrashing around looking for methods to build screens. Time is lost on the EJB side creating methods that are not used, and scrambling to put methods in quickly for UI requirements.

This situation is not ideal and should be resolved. The UI people should not have to thrash around looking for methods to build a screen (since the screen layout is known from the mockup). The EJB people should not be blindsided by unexpected UI method requirements.

To me it is a communication issue. Instead of going off and implementing signatures as he sees fit (trying to guess what the UI will need), it would be better if the EJB developer was told what signatures he needs to implement. This would also be communicated to the UI developer so when he codes a screen it is known in advance what the backing EJB calls will be.

The use of metaprogramming can fix the UI EJB disconnect. This is a top down approach to EJB specification where a metaprogrammer brokers the conversation between the UI and EJB developers. When one developer will need an EJB call to be provided by another developer, the metaprogrammer specifies to both developers the call signature and describes how to implement it. It is the metaprogrammer's job to anticipate the EJB calls that will be needed in advance and specify them before the client programmer gets to the point of needing to call them.

I tried this technique on a project where I was the team leader with around six developers working for me. It worked pretty well. There were no instances of a client developer being stuck needing an EJB call from someone else that hadn’t been specified yet. The UI developers seemed to like it. One thing that's important is to have fast turnaround of stub methods on the EJB side. When the metaprogrammer gives an EJB developer a method signature to create, the EJB developer needs to be required to put in place the signature and a stub implementation right away. The actual full implementation can be done later. This will avoid a situation where the EJB developer is given a signature to create, but doesn't get around to it in time, and the client developer is ready to call the stub signature that hasn't been created yet - causing delays for the UI client developer.

You may be reading this and thinking "Why not just fully specify all the EJB signatures up front as part of the design phase? Then it will be ironed out before coding starts and you won't have this problem." That's a good question. In an ideal world this would be a nice way to do it. Where I work the schedules are compressed, and doing that type of full design up front would end up consuming the entire development cycle and not leave any time to implement the code.

Also some shops are not fans of "big design up front", realizing that the built system typically differs substantially from the original feature set and design. In a more agile environment you need to be able to move quickly with short development cycles focusing on releasing new working features. So you need to advance the product in a way that is technically sound, yet requires little overhead.

Python: it's just better

I just did a utility in Python where I took the content from a large table from a technical manual in Word and displayed it on a GUI in a tree view. I just exported the Word table to a delimited text file and the Python script parsed the text file and built up the content for the tree view. It was not too difficult.

That's the thing with Python. Everything just seems easier and faster. With Python you'll be trying to do something, then you'll find the way to do it in Python is just ridiculously easy.

Python is better because it addresses the programmer impedance issue. When I work on a technical problem, I like to solve the problem in my mind, then just type up the solution using the editor. With other languages, programmer impedance occurs when I have to translate how I think about the solution in my mind to how I express that solution using a programming language. With Python it is generally one-to-one how the solution in my mind maps to statements in Python. So the impedance is eliminated or at least massively reduced.

Here's an example. I once had a situation where I needed to "select an item from the set at random".

In Python that can be expressed as random(set). No impedance.

In say, Java I have to translate. I have to do something like
get the size of the set
get a random integer x between 0 and set size - 1
get item x from the set
print the code and read it carefully checking for off by one errors

That's an example of the impedance. By the time I obtain the random item in Java I've lost my flow and have to spend time getting momentum back. In Python with no impedance I don't lose my train of thought.

I'm not picking on Java. I like Java. I've worked with Java and C/C++. I consider Java better than C/C++. I consider Python better than Java.

I've read some people who say that the programming language doesn't matter. What's important is that there be a vast standard library. This may be true when comparing Java to C/C++. For me what makes Java compelling compared to C/C++ is the vast standard library, built in GC, platform independance, built in threading.

However looking at the modern language landscape with Java, C# and Python, the things that gave Java an advantage over C/C++ are just commodities today. Any modern language will have the large standard library, OO, GC, multi platform, and threading out of the box.

So some other commentators got it wrong. It is about the language. And Python is just better. Besides fixing the impedance issue, Python also eliminates the compile cycle. That alone yields a significant developer productivity increase.