Moveable Modal and a different kind of 'Modal' form

October 13, 2006

When one form in an application is modal: you can't *move* the underlying forms around.

This is a shame -- because often you need to see something in an underlying form, to help you decide what to enter into the current form.

It's okay that you can't interact with the client area of the underlying forms... but it would be good if you could move the underlying forms around.

It's a tricky problem though: it would be hard to let you move one of those non-modal forms around without giving them focus...

The top-most modal form would need to be 'always on top' for the application, so that while moving underlying forms around, you can't "lose" the form you are supposed to be working on. Anyway. That is my feature request for today.

And here's another idea that i had about modal forms...

There is such a thing as 'modal for the application' -- meaning that 'of all the forms in this application, the modal one will have focus'.

And there is the rather brutal concept of 'modal for the system' meaning that nothing else can be done on that machine until this form is taken care of.

What about: "Modal for the organisation" meaning that every machine in a company is locked until that one form has been taken care of. The form might appear on everyone's machine, or just on one person's machine. I haven't figured out the specifics. I is just ideas rat.

And of course there should be "Modal for the internet" meaning that nothing can occur on the entire internet until a particular question has been answered.

And finally, "universal modal" -- meaning that the entire universe is frozen at absolute zero with not a single molecule so much as jiggling, until a particular form has been taken care of.

(Note this shouldn't be the default behaviour for many application)

(Also, this reminds me of a quote from (Leo Tolstoy? Henry Miller?) -- "We have not yet decided the question of the existence of god, and you wish to eat!?")

comments

Unlikely to fill Gmail account before I die

October 12, 2006

google, movie, security,

i've just done some quick maths.

In two years of using gmail, i've ended up with 212 mb.

If my email usage remains constant (just say) and I live another fifty years, i can expect to have about 5.512 gigs of data in my gmail account when i die, fat and happy, aged sixty-five ;-).

Gmail have been steadily growing the size of my gmail account. It started at 1 gig capacity, soon doubled to 2 gig, and now it's crept up to 2.773 gig.

I don't have to do the math to know that within 50 years it will have doubled again.

So at my current email consumption rate, i won't run out before death sets in.

Consider though that the amount of data we send around will probably grow in a non-linear fashion. If we assume that gmail's capacity will grow in an equivalent way then i won't run out in my lifetime.

Then again, a more likely possibility is that the cost of transmitting data falls in a different way to the cost of storing data, and then we'd end up in a situation where, for example, it's cheap to email a thousand movies to your friend, but not so cheap to store those thousand movies at the other end. Or vice versa.

Ah who can tell. One things for sure. I'll be leaving behind a lot of data when i die. terrabytes of crap. terracrap.

What will happen to all that terracrap? does someone just kill your account? is it eaten by the ether? do your descendents have to comb through your terracrap, slowly piecing together your life, following the thread of threatening emails you sent to your insurance company and so on?

What about all the beta's i've signed up for? Who will know all the passwords when i die? Must get them put into my will.

Enough melancholy thoughts for a Friday. Happy Code is good code.

comments

Goodbye DLL Hell, hello Security Hell.

October 05, 2006

blog, security, visual basic,

Too busy to blog, just wanted to share that phrase.

(This is in belated response to news that the only development environment fully supported on Vista will be VB 6.

Wow.

comments

Is 'Agile' a religion? (or merely a cult)

September 30, 2006

agile, amazon, blog, google, html, it industry, tdd,

The ever-entertaining Steve Yegge (see also) put out an instantly notorious blog post last week, Good Agile, Bad Agile in which he says that Agile is a new age religion. My attention span waned before I completed the article, but it got me thinking: is it really a religion? Or is it merely a cult?

Back in high school i was taught that there are six dimensions to a religion, to wit:

doctrinal
ritualistic
experiential
ethical
mythical
social

And if you lack any of those aspects, you're a cult, at best.

So how does Agile stack up? Cult or Religion?

(continues...)

Let's look at Ninian Smart's 'six dimensions of religion' one at a time.

doctrinal :: Yep! books galore, and prescriptions aplenty.
ritualistic :: Yes! Many rituals, from stand up meetings to pair programming, even refactoring can be seen as a ritualised behaviour.
experiential :: Indeed! Strong emphasis on members experiencing benefits by following the rituals and doctrines (i.e. not just an academic topic).
ethical :: Definitely! see the agile manifesto
mythical :: Maybe. Agile is full of stories, but are they myths? I'll address this below.
social :: Definitely! Emphases on interaction, collaboration at every level. Many conferences, lectures and social gatherings.

Is there a 'Mythology' in Agile?

This is bound to be a touchy subject. The more I've looked into the meaning of the word 'myth' the more I've seen conflicting opinions. Can anything ever match all of these conflicting definitions? Are there any stories in the Agile world that qualify as myths?

(The following definitions are picked up from google. I've emphasized some of the more subjective terms)

"an artificial history attempting to give a traditional meaning to a current issue"
"An improvable story, almost always including incredible or miraculous events, that has no specific reference point or time in history"
"A narrative in which some characters are superhuman beings who do things that 'happen only in stories'"
"An ill-founded belief, usually based on limited experience, given uncritical acceptance by members of a group, especially in support of existing or traditional practices and institutions."
"stories drawn from a society's history that have acquired through persistent usage the power of symbolizing that society's ideology and of dramatizing its moral consciousness"

I don't know enough about Agile to say if it meets some, none or all of those definitions. It's up to you then: Does Agile have a shared set of myths? If so, it's a religion. If not, it's a cult. I don't see any third option.

comments

Annotating Your Code with Simple Tests

September 26, 2006

blog, color, css, html, linguistics, methodology, microsoft, tdd, tools, visual basic,

Another idea: what if you annotated your functions with notes that say exactly what the most interesting edge cases are for that function.

Basically at the top of each method you could specify a few test cases. And only where you really need them. It's kind of a minimalists approach to test driven development.

Here's an example function -- leap year. With a few deliberate bugs in it.

continues...

    /// <summary>
    /// Is Year a leap year?
    /// </summary>
    /// <param name="Year">The year in question</param>
    /// <returns>
    /// true if year is a leap year. false otherwise
    /// </returns>
    private bool IsALeapYear(int Year)
    {
        return (Year % 4 == 0); 
    }

Now the weird thing about 'leap years' is that every hundred years we skip a leap year. And every four hundred years we skip skipping a leap year.(I think that's it?) Anyway -- this means that a few simple tests will pick up the most common mistakes.

    /// <summary>
    /// Is Year a leap year?
    /// </summary>
    /// <param name="Year">The year in question</param>
    /// <returns>
    /// true if year is a leap year. false otherwise
    /// </returns>
    /// <testCase Year="2000" return="true"/> (a standalone test case)
    /// <testCase Year="1900" return="false"/> (another  standalone test case)
    /// <testCase Year="1996" return="true"/> (a few more normal cases)
    /// <testCase Year="2003" return="false"/> (a few more normal cases)
    /// <testCase Year="1973" return="false"/> (and so on...)
    private bool IsALeapYear(int Year)
    {
        return (Year % 4 == 0); 
    }

So in the sample above we've used XML Comments to indicate some very simple tests that would find the most common mistakes in such a function.

We then run some nifty little tool that inspects our code comments, generates the test code, runs it, and tells us how we went. "Oh we failed for this value? Better check out my code..."

(Note, i've used XML Comments rather than 'code attributes' [i.e. the code decorations you wrap in square brackets for C#, or angle brackets for VB.net] so that the units tests wouldn't need to be shipped with your assembly.)

Part of me is screaming though, saying "That's so obvious!! Why can't we do that today!! That should be built into all languages!!" And I'm certain that other, smarter devs, have described this exact same system before. There's probably a university course on it somewhere. A lecture circuit ad so on)

(Quick shout out -- I'm using the excellent GhostDoc here (as I do everyday). And using Copy Source as Html. What a tool!)

Setup/Tear Down

Two aspects (intentional pun ;-) of Nunit are the setup and tear down for the test and test-fixture.

The idea of the snippet above is that the 'PreparePerson' function is called, and the test is then performed on the output of that function -- or something like that. In the same scope as that function, maybe. It's a bit of a stretch and requires a little bit of magic.

Tear down (i.e. a function that gets called after a test has run) would be specified in the same way.

Moving past that -- what if you have a bunch of tests that all require one function to be run first (this is more like a test-fixture setup in Nunit). Maybe you could do something like this:

More Complex Cases...

What if you wanted to write bigger test fixtures that wrap around more than one method?

In that case, i guess you've moved beyond the type of testing that this approach could suit. You could use nunit i guess, or mbUnit or some other integration suite style test.

Here's something else... say if you started with some simple tests as shown above, and then needed to do some more complex test, using NUnit. Well, there's no technical reason you couldn't have a right click option that refactors the tests above into their own Nunit test fixtures, say.

Thought Game: Duplicate Driven Programming

September 26, 2006

[code], games, linguistics, methodology, tools, visual basic,

Here's an idea i had once. An idea too crazy to implement, but still an idea that's worth the time it takes to think about it.

Imagine a new programming paradigm: Duplicate Driven Programming.

continues...

In order to produce a piece of software, you don't write unit tests, like in test-driven development, and you don't sit programmers together, like in pair-programming. Instead you have two different teams who, write the exact same software as each other, independently. They probably even write it in two different but similar languages, C# and VB.net being a suitable pair.

And the code is the same from an outsider's point of view: the same functions, the same classes. They somehow share all of that interface information, and agree on that bit. But the inner workings of their functions are completely independent.

Some kind of software tool then automatically develops test cases for the two pieces of code, and determines correct output based not on some user's specification, but based on equality between the two code bases.

If AddNumber(3,7) returns 11 in one code base but it returns 12 in the other code base, then a warning is raised. An email is sent to the developer of each version of the function, something like "Somebody's got this wrong". Maybe you don't get to see what the answer was for the other guy's code. You only get to verify your own function.

Anyway, like I said, whacky idea.

While writing this down... I had a different and maybe not quite so whacky idea about verifying the output of your code.

I wrote it up last night and it'll appear in a moment.

comments

Realtime CSS Editor -- with thanks to SquareFree.

September 25, 2006

css, editor, html, microsoft, toolbar, tools,

Today i've seen a revival in popularity of the SquareFree Html Editor, which is a nifty instant way to craft some html.

Some time ago I built a CSS Editor using the code from it, but never told anyone about it. Well, why not share, i guess. It's located here:

> > Realtime CSS Editor< <

It's inspired by Nick Bradbury's excellent Top Style (lite)

Personally I now use the 'developer toolbar' plug in for mozilla. But top style lite was a weapon of choice for a few years there.

comments

The Truth About Lisp

September 24, 2006

html, [ruby], coffee, blog, microsoft, UX, linguistics, google, ideas rat, functional,

In which the truth about lisp is revealed, and some alternatives are enumerated.

Learning lisp will alter your life.

Your brain will grow bigger than you ever thought possible.

You will rewrite all of your applications in just a handful of lines

Society will shun you. You will shun society.

You will become disatisfied with everything and everyone around you.

Lisp is so simple to learn that you can learn lisp in just a few minutes. I just learnt it now while I was waiting for a bus.

Lisp is so simple that you can implement it in any language in just a few pages of code. This might never happen though, because once you've learnt lisp you'd never want to write anything in any language other than lisp, so you wouldn't bother implementing lisp in any language other than lisp.

Lisp can be fully implemented in lisp in just a handful of lines. I just implemented lisp in lisp, fully, while i was hopping onto a bus and paying for my bus ticket all at the same time.

When you become a lisper, you will laugh at jokes that no one else thinks are funny. You will know things that cannot be expressed in ordinary imperative language.

You will think people are idiots when they state things like "Hi, how are you?" because a lisper simply doesn't need to use such verbose constructs. Lisp abstracts away those patterns of interaction and makes them completely irrelevant. The proper way to greet a fellow lisper is just a tiny nod of the chin, and about a tenth of a wink from your left eye, then point at your tin foil hat. They will know what you mean. if they don't know what you mean then they are not a true lisp programmer and they don't matter anyway.

Lisp was invented a long time ago, before java, before C, before fortran, before computers, before people, before the earth was built. the universe itself is a lisp program so trivial that no true lisper would even bother implementing it.

Lisp is so elegant that the very fact that you know even the first thing about it will qualify you for a season as principal dancer of the royal ballet. You will go out on stage in your little tutu and just scribble a few round brackets in the air with your toe. People will gasp in wonder. Unless they don't know any lisp. If they don't know any lisp then they are idiots and they don't matter.

Only lispers have a true definition of fun. Maybe ML programmers too. All of today's languages are based on fortran and lisp. The bad bits fortran, the good: lisp.

If you're good enough to use lisp, you'll soon be frustrated with lisp. Lisp is not an adequate lisp. By the time my bus had made it two blocks I'd written some simple lisp macros that were so powerful they made lisp completely obsolete and replaced it with a new language. Fortunately, that new language was also called lisp. And i was able to prove, mathematically, that the new lisp i'd created was both far superior to lisp in every conceivable way, but also exactly equivalent to lisp in every possible way. I was very excited by this. But also found it very boring.

Reddit is proof that lisp is really powerful. Paul Graham originally wrote reddit, in lisp, on the back of a napkin while he was waiting for a coffee. it was so powerful that it had to be rewritten in python just so that ordinary computers could understand it. Because it was written in lisp it was almost no effort to rewrite the entire thing, and the rewrite was completed in-between two processor cycles. Paul Graham himself was completely written in lisp, by an earlier version of himself, also written in lisp, by an earlier version of lisp. It's lisp, paul graham, lisp, paul graham, all the way down.

Because we've reached the limits of moore's law, the computers of the future will have many-core processors and all our programs will need to be written in a combination of haskell and lisp, that will itself be so powerful that the computers of the future will not be able to implement any of our ideas without creating time-travelling algorithms that borrow processing power from other computers that are further into the future. This sounds difficult, but in lisp it isn't difficult at all. in haskell this is a built-in feature and the way you implement it is just a no-brainer to any one who knows lisp or haskell.

After that, the computer of the future will be called The Lisputer. It's speed will be measured using the Lispunit, which is a measure of how many simultaneous arguments about the inadequacy of lisp can be proposed and defeated by an infinite number of lisp pundits without any actual decisions being made. Today's computers run at just under one lispunit. The Lisputer will run at lisp Lispunits, where lisp is a fundamental maximum constant of the universe that can't be expressed using ordinary imperative numerals. Suffice to say that it ends with an infinite number of closing parentheses.

Anyway. i read an article about lisp on the bus today. Top article. All the articles on lisp are really full on -- my brain starts to explode out my ear. This one, lisp is sin, was by Sriram Krishnan, in which he talked about doing C# for work, but Lisp for fun. And he touched on some of the ways in which C# is moving toward lisp.

Here's some of the technologies that the commentors at that article suggested as possible substitutes for a lisp addict:

Also, one person suggested porting the python libraries to lisp.

Curious for its absense: Ruby (see article Why Ruby is an acceptable lisp, and steve yegge's response: 'lisp is not an acceptable lisp')

(p.s. first person to write a comment that says "Paul Graham did not write reddit" deserves a lollipop.)

comments

Transparency In Vista

September 20, 2006

microsoft,

Have you seen the great transparency feature in vista? It's excellent -- it even works in notepad, check it out...

transparency in vista

(contributed by a source who wishes to remain anonymous.)

comments

How to be a programmer

September 14, 2006

[code], google,

    
   intellisense 
        ||
        \/
       code >>> compile >>>>> run >>>> success ;-)
        /\         ||          ||         
        ^^         \/          \/
        ^^      errors       errors 
        ^^          \\       //
        ^^           \\     //
        ^^             google
        ^^              ||
        \\              \/
         \<<<<<<<  copy N paste

;-)

Updated: can be animated!

comments