nullcheck

Thursday, November 20, 2008

digital daddy

Well, it's been an embarissingly long time since my last post and all I can say is that I am sorry. I have been swamped with life changes: moving, house construction, new dog, plus the ever present increadible amounts of work. But, there really is no excuse, so there you have it.

Anyway, what finally got me off my ass to make a post was a very touching evening I spent with my daughter.

It's already winter here in the Catskills. Snow has been flurrying all week, the ground is hard, the air is crisp, and at night, the stars blaze in a perfectly clear sky. So after dinner, Lucia and I cozied up by a roaring fire and I taught her HTML. (this was before the whole family gathered around the TV to watch the second installment of Brian Greene's "The Elegent Universe" on Nova. Yes, I think we qualify as a nerdy family).

Anyway, this is what she created (with my help), excerpted for blogger compatibilty:

hello

homeschooling is the best and schools are the worst

The blonde one is Lucia, for those who don't know us, she is 8 and dropped out of school after kindergarten. We haven't looked back since.

The source:

<html>
	<head>
	<script language="javascript">

	function clickMe(){
	var value = document.getElementById("lunick").value;
	alert(value);

	};


	</script>
	</head>
	<body bgcolor="red">
	<a href="http://luciastories.blogspot.com/"> hello
	<img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhNYANfJxkyvTwLgTMuFtEWOOX71Lqwm6AKYKetLnJ4kckoZRF6ICyrjQ2CYIC9vbBsvz4yU6wv9Q4OAFas3EXVW9rZoBEPybYsTZe5v6vCmcAMJK6G9G4dfOUcOXOWtie3QjID0KI7YBPc/s400/Photo+6.jpg"></a>

	<input id="lunick" type="text"></input>
	<button onclick="clickMe();">lucia</button>


	<p style="font-size:30px;font-style:italic;color:blue;">
	homeschooling is the best and schools are the worst
	</p>
	</body>
	</html>

I started with explaining how when you go to a website, your computer calls another computer up, and that computer gives your computer a document, which the browser reads and uses as instructions to draw the page. Those instructions may look funny at first but we can look at them and read them ourselves.

Personally, I think the above is probably the most important thing about the web. I certainly would never have been drawn back to computers after an awkward start with BASIC and LOGO as a child if it wasn't for View Source culture. I had to hold back the tears as I showed Lucia how you can right click on any webpage select "View Source" and see how its put together.

Obviosuly, I am not going to keep an 8 year old's attention going with lofty waxing on the beauty of http, so I quickly moved on to tags. I knew I would start with the <img/> tag, which has immediate gratification and introduces URLs and then move to the all important <a> tag. From there we went to text, then forms and some simple javascript, touching on the nature of data and functions. We then started a choose your own adventure type program, I'll let you know when its in beta.

Reflecting on this later, I realize that the most important thing for me was that Lucia really got something positive about what I do. Since I started working from home full time in June, it has really been underscored for me just how archane and bizarre my job is to the rest of my family - and especially my daughter. Tonight, she got to experience software as a creative act. And it was a good reminder for me too that software development is not just answering email, writing documents, conference calls, and all matter of other things kids intuitively hate, it can be about things kids inherently love: invention, creativity, and play.

Monday, March 24, 2008

AJAX Who?

The AJAX World conference in New York last week clearly marked to me that we have long driven past a turning point in AJAX and are somewhere on the eastside of the Gartner hype cycle curve. There were many telltale signs: almost no vendors, no recruiters from Google, largely shallow presentations, and a sparse and low energy audience. Poor timing (sandwiched between St Patrick’s and Easter) and economic turmoil further emphasized the message that the AJAX hype has passed. (Jeremy Geelan however was chipper as always)

Yes, AJAX is no longer and I say good riddance. I hope the day will soon come when we can just talk about javascript and browser capabilities without having to resort to tacky buzzwords. We are entering the “Post-AJAX” world, which just means that the distinction between what is AJAX and what is not is not worth making anymore. This may be bad for people who run conventions, but it is generally good for everyone else, because quiet times are usually productive times. Let’s not forget that AJAX itself was born out of the lull (i.e. recession) between 2000 and 2003, when nothing much seemed to happen because people were, well, writing a lot of really good code. So, in a post-AJAX world, we might expect to see a few key things happen:

Consolidation of AJAX frameworks: the AJAX hype fueled the productization (usually as open source) of dozens of javascript frameworks (most of them in-house frameworks started sometime between 2000 and 2003), most of these will die off or merge into others in the coming year or two.
Browser improvements: the next generation of browsers already show marked improvements. These will get digested in the coming years, and at the same time, older browsers (IE 6!) will be safely flushed out of the mainstream. This glacial migration of browsers is one of the key limiting factors in web innovation.
Mainstreaming in the enterprise: we’ll see the results of the current general mainstreaming of things like mashups and AJAX into the enterprise (meaning internal corporate sites and premium corporate software). We’ll know when its actually happening because people will stop talking about it.
Maturation, Standardization, and Consolidation of RIAs: as RIA frameworks mature, there simply wont be any rational for supporting 3+ proprietary systems.
Maturation of Mashups: significant improvements will drive the mashup ecosystem. A lot of this will simply be filling in the gaps in available content.

It’s a fairly safe prediction that post-AJAX innovation will focus mainly on leveraging the resources of the "mashup ecosystem". This is the golden promise that we have been hearing about from AJAX, and that initiatives such as SMash (from OpenAjax Alliance), and Douglass Crockford's various proposals are trying to address. Not all of the pieces of the puzzle are in place yet for the browser-based mashup to become the killer application it is hyped to be, but just as DHTML needed a few years of quite for the pieces to come together into AJAX, Mashups may need the same here and now.

Saturday, February 23, 2008

obsolete skills

I came across this Wiki of obsolete skills on SlashDot: http://obsoleteskills.com. It is a pretty diverse list, including Assembly Language programming and darning socks for example.

I seem to have a pretty healthy helping of these skills, and some of them make me feel pretty darn old. Blowing the dust out of a Nintendo Cartridge? I may not have any experience in that, but I sure know how to blow the dust out of a Colecovision cartridge.

(yes, and seeing the Ladybug cartridge at the ready like that brings a pang to my heart)

I am such a dinosaur that I also know how to change vacuum tubes (and I question that being obsolete. To paraphrase Steve Albini: when it comes to music, give me Analog or give me Death!) and the ribbon on a Selectric typewriter, clean VCR heads, adjust vertical and horizontal hold, use an old-style cable box to hack into the Playboy channel, and a whole slew of other undoubtedly outmoded technical skills. Hell, I can even play 36 versions of Pong and Hockey. There's something to put on a resume right next to "can use the Card Catalogue" (sorry kids, you'll have to Google that one).

Saturday, February 2, 2008

RIAs vs AJAX

*Excerpted from a recent email for AJAX World conference

There is currently a lot of hype about a supposed battle between RIAs and AJAX. In my humble opinion, the whole business is greatly misconstrued. Here is what I think are some of the misconceptions:

That there is such a thing as "AJAX". AJAX, is a made up term that was created to sell people on DHTML, which was a made up term to sell people on what you can do in the browser using just HTML and javascript. So, “AJAX” is not a platform, a RIA, or a new technology.
That RIAs are anything new. RIA might as well be named “Reactionary Internet Applications”. No paradigm shift has been introduced. They represent a qualitative improvement over Applet and ActiveX control solutions of past years. (Likewise, Adobe AIR and WPF are qualitative improvements on traditional desktop installs.)
That there is a choice to be made between AJAX and RIA. Just about any RIA will be embedded in an HTML page that uses javascript to communicate with it. Some RIAs will even make use of HTML and javascript as content (a selling point of Adobe AIR), so the only question is whether to use an RIA or not for a particular problem. If you are working on a web application, you are using HTML and javascript.
That RIAs are going to rise up and squash “AJAX”. This would mean that RIAs would render browser based applications obsolete as anything other then a launching pad for RIA content. The ramifications would be (among other things):
- Literally hundreds of millions of web pages of content would have to be transformed into RIA content
- The cost of creating content on the web would, for the first time ever, go up rather then down, as the means of creating content became locked behind proprietary systems with much higher learning curves then HTML and javascript.
Besides all of that, there is also the simple fact that the browser has historically evolved to fill the gaps that RIA solutions provide, and it will continue to do so. Basically, anything that RIAs are doing exclusively today, will be in the native browser domain some point in the future, and that future is often closer then you think. For example, look at the dojo charting and vector graphics packages.

That the debate is at all related to innovation in Web Software. I can’t think of any real paradigm shift in web development that has hinged on a distinction between using Flash or Silverlight or JavaFX vs Javascript, while many of the innovations in the past 8 years have been related to the openness and document structure of browser-based development. Google maps wouldn’t have been much different if it had used Flash (as Yahoo maps in fact does) to do the map drawing. What is important to note about the Maps and subsequent Mashup explosion that came out of that, was that it was achieved by exposing aJavascript API that was scriptable in the browser. The mapping component could be Flash, Silverlight, or anything else, but the way you talk to it is with javascript and where it lives is in the DOM. Likewise, it is hard to imagine document and hyperlink based collaboration patterns such as Wikis and Blogs emerging in a world that is completely dominated by RIAs.
That the limitations of browser based applications are a bad thing. Limitations have a lot of benefits. Most software is overbuilt by a wide margin which increases cost, stifles innovation, and frustrates end-users. Web applications have been so successful at delivering inexpensive software because of the limitations of the browser rather then in spite of them. Google has proved over and over again that people want simple and clear interfaces without a lot of moving parts, yet the writing on the wall is ignored over and over again.

So there you have it. Please, feel free to use Flash, Flex, Air, Silverlight, JavaFX, or even Applets or ActiveX wherever you find it needed, but please, lets stop debating RIA vs Browser-based HTML and javascript as if it were an apples-to-apples comparison.

Thursday, December 20, 2007

Decrementing vs Incrementing

A while back, I had read some things about how decrementing loops in javascript were faster then incrementing, especially in IE. (see http://www.moddular.org/log/javascript-loops) The main point being that it is faster to compare to 0 then any other number. As a result, I had implemented some decrementing loops in my own code (loop unrolling seemed too heavy handed) but haven't been too compelled to make a habit of it. Today I decided to investigate this again, since I had some lingering doubts about if any of this made a difference at all... So, here it is.

My test code consists of the following:

var limit = 1000000;
function testi(){
var n = 0;
for (var i = 0; i < n =" i;" n =" 0;" i =" limit;"> 0; i--)
n = i;
}

time1 = new Date().valueOf();
testi();
time2 = new Date().valueOf();
document.write("time incrementing (" + limit + " times) = " + (time2 - time1) + "
");

time1 = new Date().valueOf();
testd();
time2 = new Date().valueOf();
document.write("time decrementing (" + limit + " times) = " + (time2 - time1) + "
");

Fairly straight forward. I can change the limit value and check to see what the differences are for different size loops. I compared in Firefox 2 and IE 7. And I found the following.

At a million loops in FF and IE, decrementing is usually twice as fast as incrementing (~220ms vs ~440ms). But how important is a 200ms baseline difference when you are doing a loop a million times? Presumably, whatever you are doing inside of that loop will most likely eclipse the difference.*
If we decrease the loop to 100,000, the difference in IE becomes ~20ms decrementing vs ~40ms incrementing. And Firefox, surprisingly, shows the same results.
At 10,000 loops, Firefox wavers between 0 and 10 ms for either incrementing or decrementing. As does IE.
At 1,000 loops, we are in 0ms land for both IE and FF.

So, we see that at a million, decrementing saves us some time -- especially in IE. When we drop down to 100,000, the differences between the browsers disappear, and while decrementing seems to be twice as fast, the ~20 ms difference is tiny in the grand scheme of things. At 10,000, the differences incrementing and decrementing in both browsers disappears entirely.

One problem with decrementing loops I have found is that they don't behave the same as incrementing loops. If you are looping through an array, you end up going through it backwards. This is sometimes a problem, if for example you are executing a string of functions stored in an array, and you want to ensure that the first one in is executed first. A simple way to fix this, is to find the index by subtracting your decrementing index from your limit. But does putting this simple bit of math into the loop corrodes any performance gains we made by decrementing in the first place? To find out, I substituted the n = i; assignment in the decrementing loop function with a n = limit - i; assignment. I found that:

In Firefox (at 1 million loops), the cost of decrementing rose to ~550ms vs ~440ms for incrementing. Erasing any gains and adding cost. In IE, the time for decrementing increased beyond the time for incrementing.
Below 1 million loops, decrementing lost all of its advantage (at best being equal) when the compensating math was implemented.

In conclusion, it seems that decrementing loops are more efficient, but only when the loops are extremely large. This advantage pales next to whatever else you might be doing in an extremely large loop. Above all, decrementing is counter-intuitive and requires compensating math when used with loops that are order dependent (or might be order dependent), and this compensation nullifies any gains that decrementing gives in the first place. As with many optimization tricks, it seems that the cure is worse then the symptom.

*Strangely, in Internet Explorer only, if I reverse the order of the loops and execute the decrementing function first (at a million loops), decrementing takes ~210ms and incrementing takes anywhere from 900 to over 2000 ms. This is a big difference, and I haven't been able to figure out the source of the disparity.

Wednesday, December 19, 2007

Always Eat Alone (sometimes)

A friend of mine recently read the book Never Eat Alone, and since he's been singing the praises of networking. Yes, networking is important.

I have always seen the value in networking, but I get a little cranky when networking gets all of the attention at the expense of well... being alone. Being alone is really important.

I recall a networking buff extolling the virtues of practicing small talk at every possible opportunity, like when your in a cab. When I'm alone in a cab with a non-talkative driver, I see it as an opportunity to think and reflect. Maybe I am just a misanthrope, but I actually like, and require, time alone with my thoughts.

Since I began working in France, one of the customs that has stuck out is lunch. In the office I work in, everybody takes about a full hour for lunch, and almost always in a group. In my office in New York, it is normal to eat alone at your computer in about 10 minutes, eating socially is the exception for most.

Part of the difference is due to the fact that in France, lunch is generally the main meal of the day -- so having a sandwich for lunch would be like having a sandwich for dinner in the US. Another reason, is that in France, eating is considered a social activity and not just an unfortunate biological function. I have to say that, in general, I am much more partial to the French attitude then the American.

However, I still do miss eating alone sometimes.

Anybody who does creative work (which I count software development as), must find a balance between being alone and being social. We need time alone to think and to create, and we need time with people to communicate ideas, share our work, and get a break from being alone. Going between the two requires a shift in gears that can take time. So, taking an hour break for a social lunch, can easily add up to an hour for lunch plus an hour afterwards getting back into the mindset you were in before lunch.

So, when you eat alone, you are free to work on the problem you failed to solve before lunch, to catch up on your reading, to think about something entirely different, and you can preserve your mindset. Consider of this the next time you feel a pang of shame as you hunker down in front of your computer with a sandwich. Don't let the networking people guilt you into going out for lunch everyday. You have nothing to be ashamed of (as long as you keep the mustard off of the keyboard).

Questions for Review

As the end of the year draws near, it is review time at my company again. Here are some questions that I wish appeared on the review (oh well, they are good for my own personal reflection anyway):

What risks have you taken this year?
How much code have you eliminated?
What tasks have you eliminated?
How many people have you pissed off and why?
How many projects did you start up that failed? (if you have a lot of failed start ups, thats a good thing)
Who did you meet this year?
How many design documents did you write?
What new hobbies/interests that have nothing to do with your job do you have?