Monday, October 22, 2012

Nightmare Final

I have seen this and variations many places on the web but no credit for authorship. Too bad as this is awesome - pretty sure I had to take a test or two like this in collegge.

Good luck!

Instructions

Read each of the following fifteen questions carefully. Answer all the questions. Time limit: 4 hours. Begin immediately.

1. HISTORY

Describe the history of the papacy from its origin to the present day, concentrating especially, but not exclusively, on it social, political, economic, religious, and philosophical impact on Europe, Asia, America and Africa. Be brief, concise and specific.

2. MEDICINE

You have been provided with a razor blade, a piece of gauze, and a bottle of Scotch. Remove your appendix. Do not suture until your work has been inspected. You have 15 minutes.

3. PUBLIC SPEAKING

2500 riot-crazed aborigines are storming the classroom. Calm them. You may use any ancient language except Latin or Greek.

4. BIOLOGY

Create life. Estimate the differences in subsequent human culture if this form of life had developed 50 million years earlier, with special attention to its probable effect on the English parliamentary system. Prove your thesis.

5. MUSIC

Write a piano concerto. Orchestrate it and perform it with flute and drum. You will find a piano under your desk.

6. PSYCHOLOGY

Based on your knowledge of their works, evaluate the emotional stability, degree of adjustment, and repressed frustrations of each of the following: Alexander of Aphrodites, Ramses II, Gregory of Nicea, and Hammurabi. Support your evaluation with quotations from each man's work, making appropriate references. It is not necessary to translate.

7. SOCIOLOGY

Estimate the sociological problems which might accompany the end of the world. Construct and experiment to test your theory.

8. ENGINEERING

The disassembled parts of a high-powered rifle have been placed on your desk. You will also find and instruction manual, printed in Swahili. In ten minutes a hungry Bengal tiger will be admitted to the room. Take whatever action you feel appropriate. Be prepared to justify your decision.

9. ECONOMICS

Develop a realistic plan for refinancing the national debt. Trace the possible effects of your plan in the following areas: Cubism, the Donatist controversy, and the wave theory of light. Outline a method for preventing these effects. Criticize this method from all possible points of view. Point out the deficiencies in your point of view, as demonstrated in your answer to the last question.

10. POLITICAL SCIENCE

There is a red telephone on the desk beside you. Start World War III. Report at length on its social-political effects, if any.

11. EPISTEMOLOGY

Take a position for or against truth. Prove the validity of your position.

12. PHYSICS

Create a small rapidly rotating black hole. Investigate and report on its effects on the optoelectric properties of Seaborgium (element #106). Clean up your experiment after you've finished.

13. PHILOSOPHY

Sketch the development of human thought and estimate its significance. Compare with the development of any other kind of thought.

14. ASTRONOMY

Define the universe. Give three examples.

15. GENERAL KNOWLEDGE

Describe in detail. Be objective and specific.

Sunday, September 30, 2012

Friends don't let friends use Aero Peek with Alt Tab!

Hey! Windows Aero Peek! Ya I'm talking to you!


HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\AltTab
LivePreview_ms(REG_DWORD): 0

Just sayin!

Saturday, June 30, 2012


Recently I needed to use NetBeans to work on a project that needed HTTP access to a set of static files. The way I did it was to edit the embedded Tomcat server.xml like so:

    <Engine defaultHost="localhost" name="Catalina">
        <Realm className="org.apache.catalina.realm.LockOutRealm">
            <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
                   resourceName="UserDatabase"/>
        </Realm>
        <Host appBase="webapps" autoDeploy="false" name="localhost"
              unpackWARs="true">
            <Valve className="org.apache.catalina.valves.AccessLogValve"
                   directory="logs" pattern="%h %l %u %t &quot;%r&quot; %s %b"
                   prefix="localhost_access_log."
                   resolveHosts="false" suffix=".txt"/>
            <Context path="/sdk" docBase="z:/Data/Foo" />
            <Context path="/web" docBase="z:/web" />
        </Host>
    </Engine>

Enjoy!

Saturday, June 23, 2012

HowTo - get directory of executing bash script

    BASEDIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

HowTo - read a value from a Java Properties file in Bash

    # Reads property $2 from properties file $1 and echos the value. To call this method do:
    #
    #     V=$(getProp filename property)
    #
    function getProp () {
        # ignore lines with '#' as the first non-space character (comments)
        # grep for the property we want
        # get the last match just in case
        # strip the "property=" part but leave any '=' characters in the value

        echo `sed '/^[[:space:]]*\#/d' $1 | grep $2  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`
    }

Friday, June 8, 2012

Difficult Tasks

This is what is meant by "pulling a Brave Sir Robin" when assigned a difficult task... for the curious people.

Brave Sir Robin

Brave Sir Robin Ran Away
Bravely ran away away
When danger reared its ugly head
He bravely turned his tail and fled
Yes Brave Sir Robin turned about
And gallantly he chickened out
Bravely taking to his feet
He beat a very brave retreat
Bravest of the brave Sir Robin

Saturday, December 3, 2011

How to Win Friend and Influence People - Reloaded

Homage to Coffee

Without which code production world-wide would drop by 70%.









Tuesday, November 8, 2011

More Jargon File

Solving hard problems is a form of mental exercise. It stretches us and I find it very rewarding when I arrive at the solution.

Some problems, however, may be best left alone. There are days where I feel like the poor engineer cited below (emphasis added):


[Kidder] The Soul of a New Machine. Tracy Kidder. Avon. Copyright © 1982. ISBN 0-380-59931-7.

This book (a 1982 Pulitzer Prize winner) documents the adventure of the design of a new Data General computer, the MV-8000 Eagle. It is an amazingly well-done portrait of the hacker mindset — although largely the hardware hacker — done by a complete outsider. It is a bit thin in spots, but with enough technical information to be entertaining to the serious hacker while providing non-technical people a view of what day-to-day life can be like — the fun, the excitement, the disasters.

During one period, when the microcode and logic were glitching at the nanosecond level, one of the overworked engineers departed the company, leaving behind a note on his terminal as his letter of resignation: “I am going to a commune in Vermont and will deal with no unit of time shorter than a season.”

Saturday, May 21, 2011

Real Programmer - The Story of Mel

This was posted to USENET by its author, Ed Nather (utastro!nather), on May 21, 1983.


A recent article devoted to the *macho* side of programming made the bald and unvarnished statement:
   Real Programmers write in FORTRAN.

Maybe they do now,
in this decadent era of
Lite beer, hand calculators, and "user-friendly" software
but back in the Good Old Days,
when the term "software" sounded funny
and Real Computers were made out of drums and vacuum tubes,
Real Programmers wrote in machine code.
Not FORTRAN. Not RATFOR. Not, even, assembly language.
Machine Code.
Raw, unadorned, inscrutable hexadecimal numbers.
Directly.

Lest a whole new generation of programmers
grow up in ignorance of this glorious past,
I feel duty-bound to describe,
as best I can through the generation gap,
how a Real Programmer wrote code.
I'll call him Mel,
because that was his name.

I first met Mel when I went to work for Royal McBee Computer Corp.,
a now-defunct subsidiary of the typewriter company.
The firm manufactured the LGP-30,
a small, cheap (by the standards of the day)
drum-memory computer,
and had just started to manufacture
the RPC-4000, a much-improved,
bigger, better, faster --- drum-memory computer.
Cores cost too much,
and weren't here to stay, anyway.
(That's why you haven't heard of the company,
or the computer.)

I had been hired to write a FORTRAN compiler
for this new marvel and Mel was my guide to its wonders.
Mel didn't approve of compilers.

"If a program can't rewrite its own code",
he asked, "what good is it?"

Mel had written,
in hexadecimal,
the most popular computer program the company owned.
It ran on the LGP-30
and played blackjack with potential customers
at computer shows.
Its effect was always dramatic.
The LGP-30 booth was packed at every show,
and the IBM salesmen stood around
talking to each other.
Whether or not this actually sold computers
was a question we never discussed.

Mel's job was to re-write
the blackjack program for the RPC-4000.
(Port? What does that mean?)
The new computer had a one-plus-one
addressing scheme,
in which each machine instruction,
in addition to the operation code
and the address of the needed operand,
had a second address that indicated where, on the revolving drum,
the next instruction was located.

In modern parlance,
every single instruction was followed by a GO TO!
Put *that* in Pascal's pipe and smoke it.

Mel loved the RPC-4000
because he could optimize his code:
that is, locate instructions on the drum
so that just as one finished its job,
the next would be just arriving at the "read head"
and available for immediate execution.
There was a program to do that job,
an "optimizing assembler",
but Mel refused to use it.

"You never know where it's going to put things",
he explained, "so you'd have to use separate constants".

It was a long time before I understood that remark.
Since Mel knew the numerical value
of every operation code,
and assigned his own drum addresses,
every instruction he wrote could also be considered
a numerical constant.
He could pick up an earlier "add" instruction, say,
and multiply by it,
if it had the right numeric value.
His code was not easy for someone else to modify.

I compared Mel's hand-optimized programs
with the same code massaged by the optimizing assembler program,
and Mel's always ran faster.
That was because the "top-down" method of program design
hadn't been invented yet,
and Mel wouldn't have used it anyway.
He wrote the innermost parts of his program loops first,
so they would get first choice
of the optimum address locations on the drum.
The optimizing assembler wasn't smart enough to do it that way.

Mel never wrote time-delay loops, either,
even when the balky Flexowriter
required a delay between output characters to work right.
He just located instructions on the drum
so each successive one was just *past* the read head
when it was needed;
the drum had to execute another complete revolution
to find the next instruction.
He coined an unforgettable term for this procedure.
Although "optimum" is an absolute term,
like "unique", it became common verbal practice
to make it relative:
"not quite optimum" or "less optimum"
or "not very optimum".
Mel called the maximum time-delay locations
the "most pessimum".

After he finished the blackjack program
and got it to run
("Even the initializer is optimized",
he said proudly),
he got a Change Request from the sales department.
The program used an elegant (optimized)
random number generator
to shuffle the "cards" and deal from the "deck",
and some of the salesmen felt it was too fair,
since sometimes the customers lost.
They wanted Mel to modify the program
so, at the setting of a sense switch on the console,
they could change the odds and let the customer win.

Mel balked.
He felt this was patently dishonest,
which it was,
and that it impinged on his personal integrity as a programmer,
which it did,
so he refused to do it.
The Head Salesman talked to Mel,
as did the Big Boss and, at the boss's urging,
a few Fellow Programmers.
Mel finally gave in and wrote the code,
but he got the test backwards,
and, when the sense switch was turned on,
the program would cheat, winning every time.
Mel was delighted with this,
claiming his subconscious was uncontrollably ethical,
and adamantly refused to fix it.

After Mel had left the company for greener pa$ture$,
the Big Boss asked me to look at the code
and see if I could find the test and reverse it.
Somewhat reluctantly, I agreed to look.
Tracking Mel's code was a real adventure.

I have often felt that programming is an art form,
whose real value can only be appreciated
by another versed in the same arcane art;
there are lovely gems and brilliant coups
hidden from human view and admiration, sometimes forever,
by the very nature of the process.
You can learn a lot about an individual
just by reading through his code,
even in hexadecimal.
Mel was, I think, an unsung genius.

Perhaps my greatest shock came
when I found an innocent loop that had no test in it.
No test. *None*.
Common sense said it had to be a closed loop,
where the program would circle, forever, endlessly.
Program control passed right through it, however,
and safely out the other side.
It took me two weeks to figure it out.

The RPC-4000 computer had a really modern facility
called an index register.
It allowed the programmer to write a program loop
that used an indexed instruction inside;
each time through,
the number in the index register
was added to the address of that instruction,
so it would refer
to the next datum in a series.
He had only to increment the index register
each time through.
Mel never used it.

Instead, he would pull the instruction into a machine register,
add one to its address,
and store it back.
He would then execute the modified instruction
right from the register.
The loop was written so this additional execution time
was taken into account ---
just as this instruction finished,
the next one was right under the drum's read head,
ready to go.
But the loop had no test in it.

The vital clue came when I noticed
the index register bit,
the bit that lay between the address
and the operation code in the instruction word,
was turned on ---
yet Mel never used the index register,
leaving it zero all the time.
When the light went on it nearly blinded me.

He had located the data he was working on
near the top of memory ---
the largest locations the instructions could address ---
so, after the last datum was handled,
incrementing the instruction address
would make it overflow.
The carry would add one to the
operation code, changing it to the next one in the instruction set:
a jump instruction.
Sure enough, the next program instruction was
in address location zero,
and the program went happily on its way.

I haven't kept in touch with Mel,
so I don't know if he ever gave in to the flood of
change that has washed over programming techniques
since those long-gone days.
I like to think he didn't.
In any event,
I was impressed enough that I quit looking for the
offending test,
telling the Big Boss I couldn't find it.
He didn't seem surprised.

When I left the company,
the blackjack program would still cheat
if you turned on the right sense switch,
and I think that's how it should be.
I didn't feel comfortable
hacking up the code of a Real Programmer.



This is one of hackerdom's great heroic epics, free verse or no. In a few spare images it captures more about the esthetics and psychology of hacking than all the scholarly volumes on the subject put together.

[1992 postscript --- the author writes: "The original submission to the net was not in free verse, nor any approximation to it --- it was straight prose style, in non-justified paragraphs. In bouncing around the net it apparently got modified into the `free verse' form now popular. In other words, it got hacked on the net. That seems appropriate, somehow."]

From the jargon file

More Clarke & Dawe

Whale vs. Seismic Testing



Men & Women

Truth.

Wednesday, May 18, 2011

Knowing Where To Hit It

I was thinking of this story today and wanted to post it for everyones reading pleasure. It will make a lot of sense to the "gurus" in a software team. :)



One day in a large factory with a long assembly line a critical machine suddenly stopped working. This brought the entire assembly line to a halt and partially finished products were backed up all through the factory. The company that owned the factory was in a panic as they were losing thousands of dollars for every hour that the factory was shut down.

The chief mechanic was called in and he insisted that there was only one expert who he knew could correct the problem quickly so the expert was called in. When the expert arrived, he was a modest looking man in common work clothes carrying a small toolbox. He examined the halted machine for about ten minutes then removed a hammer from his toolbox. He struck the machine once with the hammer and suddenly the machine started running at full capacity. Goods started moving smoothly down the assembly line at full rate and the factory was back online.

The expert then presented the chief mechanic with a bill for $5000. “This is outrageous!” the mechanic exclaimed “5000 dollars to hit a machine with a hammer?” The expert replied “Oh, let me itemize that bill for you.” and presented the chief mechanic with the following itemized invoice:


  • Hitting machine with hammer ….…………$5.00
  • Knowing where to hit machine ….…$4995.00

Tuesday, September 23, 2008

The Horizontal Issues

I think I'm going to shift gears from talking about JavaScript and move up a couple levels to architecture. The ZJS project page will be the place to find my further ramblings in that area.

A recurring theme for me lately has been the ubiquity of what I'll call the "horizontal issues" that effect software systems. In particular servers, but most of these issues effect all software designs. While I want to focus on the architecture part of software for now, there is a similar commonality at the next level up as well: the business level. Maybe I'll get to those some day.

I call these issues "horizontal" because if you were trying to draw them in a block diagram, they tend to be drawn horizontally. The application logic tends to be drawn vertically as "higher level" subsystems.

So let's jump in with a non-exhaustive, unordered list:

  • Installation
  • Licensing
  • Configuration
  • Logging
  • Performance Monitoring
  • Data Management (user files, databases, etc.)
  • Alarms (User Notifications)
  • Authentication
  • Access Control
  • Auditing
  • User Management
  • Administrative Control (User Roles)
  • Clustering & Load Balancing
  • High Availability (HA)
  • Sign Up
  • Billing
  • Customization (themes, plugins, scripts, etc.)
  • Upgrades (installs, user data, configuration, customizations).
  • Testing Interfaces and Harness


As you can probably tell, each of these can be a massive effort. The problem is that for most software, few if any of them are optional. Most complex systems need something in each of these areas. Since these are not the core business concerns, however, they get minimal attention in favor of focusing on the "important" parts.

When you move from prototype/demo to a production system, you neglect these at your peril. While your users may not spend most of their time in these areas, many of them must be navigated before the "real work" can get started. The care and feeding of your software will also require that users interact with these various subsystems. The last thing you want is for the core competence of your software to be masked by user frustrations in these areas.

Implementing robust solutions to all of the above would be a massive development effort in its own right. So how can we as software engineers solve all these problems and still keep our project on schedule?

I'll start on that next time.

Monday, September 22, 2008

My famous wife

Details here. Ain't she cool?

I promise to get back to "on topic" subjects next time. Really.

And now for something completely similar...

Clarke and Dawe talk about the carbon scheme




Find more here.

Thursday, September 18, 2008

And now for something completely different...

with apologies to M.P.:

The Front Fell Off




Soaking up the Olympic Atmosphere




The Credit Crunch




OK, you've probably figured out that I think these guys are LOL hilarious. You can find more of their stuff by searching for "Clarke Dawe" on YouTube. I have not seen all their stuff, so there may be some material I wouldn't recommend. Watch at your discretion.

Tuesday, July 22, 2008

Introducing ZJS - The Z JavaScript library

I'm starting to get my act together for these little experiments: I started a project on Google Code called ZJS. I should get the files posted soon. There are a couple extras in there that I haven't written about yet, so we'll see how it goes. Hopefully I will find a few minutes some day soon to say a few words on the new additions.

Tuesday, April 8, 2008

Function.prototype Fun!

In my previous post I extended Function.prototype. Since functions are fundamental components of JavaScript, I thought it worth showing a few more extensions that have proven useful.
Function.prototype.bind = function (obj)
{
var method = this;
var f = function () { return method.apply(obj, arguments); }
return jscore.addMeta(f, { binding : "bind", target : method });
};

Function.prototype.bind2 = function (obj)
{
var method = this;
var f = function () {
var args = jscore.arrayCat([this], arguments);
return method.apply(obj, args);
};
return jscore.addMeta(f, { binding : "bind2", target : method });
};

Function.prototype.head = function ()
{
var method = this, first = jscore.arrayCat(arguments);
var f = function () {
var args = jscore.arrayCat(first, arguments);
return method.apply(this, args);
};
return jscore.addMeta(f, { binding : "head", target : method });
};

Function.prototype.tail = function ()
{
var method = this, last = jscore.arrayCat(arguments);
var f = function () {
var args = jscore.arrayCat(arguments, last);
return method.apply(this, args);
};
return jscore.addMeta(f, { binding : "tail", target : method });
};

Function.prototype.returns = function (ret)
{
var method = this;
var f = function () { method.apply(this, arguments); return ret; };
return jscore.addMeta(f, { binding : "returns", target : method });
};

Function.prototype.seal = function ()
{
var method = this;
var f = function () { return method(); };
return jscore.addMeta(f, { binding : "seal", target : method });
};

And the helper functions:
$namespace("jscore", {

addMeta : function (obj, meta)
{
if (!obj.$meta)
obj.$meta = {};
for (var n in meta)
obj.$meta[n] = meta[n];
return obj;
},

arrayCat : function ()
{
var ret = new Array(jscore.arrayLen.apply(null, arguments));
for (var i = 0, k = 0; i < arguments.length; ++i)
for (var a = arguments[i], n = (a ? a.length : 0), j = 0; j < n; ++j)
ret[k++] = a[j];
return ret;
},

arrayLen : function ()
{
var ret = 0;
for (var a, i = 0; i < arguments.length; ++i)
if (a = arguments[i])
ret += a.length;
return ret;
}

}); // jscore

While the basic goal of these methods is to help create closures more cleanly and efficiently, one of them has proven to be by far the most useful: bind.

If you haven't used closures before, you are really missing out on the power of JavaScript. But, if you have used closures, you've probably experienced their dark side: memory leaks, especially in IE.

This is a well known problem for IE, but these methods can help that situation. Even outside of IE, closures can hold on to objects that aren't needed, thus producing a resource leak or at least a less-than-desirable cost. The problem with closures stems from the fact that the closure implicitly keeps references to all variables in its lexical scope, whether it needs them or not. In other words:
function foo (x, y)
{
var a = [ ... ]; // lots of stuff
document.getElementById("bar").onclick = function () { ... }
}

In the above code, the onclick handler function captures a, x and y and holds on to them for its entire life. If the function doesn't need all of these objects, their persistence is wasteful. In this situation, head (or tail) can be used to reduce the bound variables to only what is needed. For example,
function clickHandler (x, y)
{
...
}
function foo (x, y)
{
var a = [ ... ]; // lots of stuff
document.getElementById("bar").onclick = clickHandler.head(x, y);
}

Now, the garbage collector can cleanup a, but clickHandler can still reference x and y. More importantly, this helps in IE in the following example:
function foo (x, y)
{
var a = [ ... ]; // lots of stuff
var el = document.getElementById("bar");
...

el.onclick = function () { ... }
}

The above code illustrates a classic memory leak situation in IE. The problem has already been well explained, but here's how head helps:
function clickHandler (x, y)
{
...
}
function foo (x, y)
{
var a = [ ... ]; // lots of stuff
var el = document.getElementById("bar");
...

el.onclick = clickHandler.head(x, y);
}

With this approach, neither clickHandler nor the closure function created by head keep a reference on the el variable. This removes the reference cycle and avoids the memory leak.

That is all nice, but bind has an even more useful feature. In fact it is this feature that inspired me to write these methods in the first place. It was only after some use that I decided to add the ability to store parameter values, because (to me) the most important was bind.

In my past work, programming in C++ was always complicated by the need to preserve the blasted this pointer. This is especially problematic when working with C API's that make no such accomodations for tracking state. Fast forward a bit. When I started programming in JavaScript, I noticed it felt a lot like C. I had functions, and I had data, but often enough I had no good way to write methods that were associated with an object.

The browser interface is full of places where this pointers are easily lost. Take setTimeout for example. It can call a function after a specified amount of time. Well and good, but where's my bloody this pointer?!? If setTimeout and its partner setInterval were alone, I may not have sought a general solution. Sadly, they are far from alone. Even in the above examples, the onclick event handler does not preserve any this pointer. Even worse, DOM elements call these handlers with themselves as the this pointer! Talk about frustrating, but I'll get back to events another time.

Once or twice I've had the need to connect a method that processed all provided arguments (like arrayCat and arrayLen) to a caller that would supply an extra parameter or two. You can imagine the confusion that caused! At first, I threw in a closure and then realized the error of my ways. OK, it was a memory leak that caused me to realize my mistake. So, there's a pair of methods that are unlikely to ever get more complex: returns and seal.

Together returns and seal fixed my memory leak. The seal method cuts off any supplied arguments that it receives and calls the bound function. The returns method took care of returning the proper value.

Of course, these are really cool in combination:
function foo ()
{
for (var i = 0; i < arguments.length; ++i)
...
};

function bar (x, y)
{
var el = document.getElementById("foobar");
var fn = foo.head(x, y).seal().returns(false);
el.onclick = fn;
};

Though highly dubious, this example illustrates chaining head, seal and returns. Together, these methods can go a long way to allowing arbitrary methods to be connected without playing with the fire of naked closures.

Lastly, these binding methods required a slight tweak to the getName method. This ensures that it will report its correct name as well as the real target method to which it is bound.
Function.prototype.getName = function ()
{
if (!this.$meta)
{
var name = this.name || this.toString().match(/function (\w*)/)[1];
name = name || "~anonymous~";
this.$meta = { fullname : name, name : name };
}

var s = this.$meta.fullname;
if (this.$meta.target)
s += "~"+this.$meta.binding+">" + this.$meta.target.getName();
return s;
}

Enjoy!