Technology Still Sucks

Technology is all around us, we have seen it evolve greatly and even seen it reach a level of refinement that has set a new standard for design and usability but make no mistake, it has a long way to go. I don’t want to sound like an ungrateful child but technology still sucks.

I held out as long as I could but yesterday I finally gave in and went back to the iPhone. I had been using a Galaxy SII, thats right, a phone that is several years past its prime. Why did I keep using this cruddy old phone for so long you ask? Well first lets keep things in perspective. These devices are on an upgrade cycle that is ridiculous and its the height of first-world whining to complain about your ”old phone” when, for goodness sake, it gives you the internet in your pocket with what not-so-long-ago would have been subject to export controls as a supercomputer. After much goading and teasing from coworkers and friends I have switched to an iPhone 5S but it wasn’t the peer pressure that did it. I knew of the superiority of iOS as a platform and the level of quality in the apps vs the offerings for Android. I am even a die-hard Mac user and very familiar with and deeply appreciate the attention to design and usability that Apple brings to their products. But with all of that I still stuck with Android, I had different needs that it just so happened an Android product fulfilled. I’ll get to those in a second but what got me to switch back was that I was simply fed-up with constantly dead batteries and the crappy Micro-USB port that lasted, on average, 4 months before going bad. Thats it! Thats all that it was. I would happily be using a Samsung Galaxy SII if the damn battery would not get drained so easily, and yes this is a new battery, and if the USB port actually worked in a reliable fashion. The last straw might have been that time I got a flat tire and had to walk to a gas station at night in the dark of winter with a dead phone. But it wasn’t. The last straw was simply the culmination of so much putting-up-with-it. I was driving home and trying to charge my phone once again, and once again as seemingly always the USB port was being finicky. As I drove I fidgeted on and off with trying to get the phone into just the right position to take a charge. It would blip on telling me it was working, then I would set it down and the simple change in tension on the cable was all it took to break the connection and stop the charging process. I would have liked to call Christine and tell her I was on my way but instead I spent 30+ minutes of a 3.5hr drive fidgeting in this way. Finally I gave up and left my phone for dead. You can imagine this can get infuriating after a while. At some point I thought back to all the time I have spent, with this very problem, all the money I have spent to “build out my charging infrastructure.” Cables and chargers wherever I go, at work, in the car, in the bedroom, in the living room, in my laptop case, backup batteries, etc. I even have the phone replacement plan that I have used multiple times with different phones to deal with this very issue. I could have used the replacement plan once again but no, it was time to move on.

So Apple fanboys-and-girls will be saying “see we told you so” but not so fast. I am impressed with the clean pixels of iOS for sure, and hopefully this phone will retain it’s charge better. But I had my own reasons for using Android that took those things into account. It’s not like I’m somehow unaware of what it’s like to use an iPhone. I’ve designed interfaces for them, I’ve developed web apps for them I know what they are like, I used a 3G for over a year, I still use an iPad Mini. So it was always annoying when iOS users would patronize me with their automatic reactions against my clunky Android phone as if the only consideration of technology is if it scrolls smoothly or has the best games and cleanest design. For me those are nice to haves but ultimately I did few things on my phone, text, call, maps, hip-chat, and web browsing. Notice I’m not a big gamer or app user. Most of all I read a lot of web pages on the phone mostly from Hacker News. I often did this while I walked my dog or eating lunch. So a larger screen was very nice to have and simply not available in iOS land. Another related factor that was huge for me on Android is that the browsers can actually reflow text. On Android you don’t need to constantly scroll horizontally to read. This was a huge deal for me as I read lots of web pages on my phone and interestingly this is a problem that every iOS user doesn’t even recognize. Their answer is to double tap to zoom to the text. This often leaves you with small text, you can then rotate the phone horizontally to get something bigger but that often is not good enough either and it can be annoying to hold a phone like that. So you end up zooming in to a scale that does not hurt your eyes. It’s so odd, I see everyone scrolling back and forth, left and right, their thumb constantly moving the page just to read the words. And this is supposed to be good design? Web pages are built with something called “HTML” that allows for multiple screen sizes using an advanced technology called “text wrapping.” Apple has been hostile to the web since the inception of iOS but this is kind of ridiculous. The fact that iOS users don’t even notice this problem and that they all behave in this odd way without knowing it is just one example of how, even when it sucks, we conform to technology and don’t think about it. In my case I conformed to shitty battery life but at least I could also play Flash video in the browser. Yea I now Flash sucks but it’s all over the place so it was really handy to be able to just hit the play button on any given page and know that it would work.

This is why technology still sucks, big time. You have these arbitrary boundaries of platforms that for a million stupid reasons can’t accomplish the most fundamental, basic chore like keeping a charge or wrapping text or playing a video and you are supposed to just accept this without question. Perhaps there was a phone out there with all the features I needed? But did it have WiMax-4G? yeah you heard me WiMax. I stuck with Android first because a few years ago I was living on my own and to save money I tethered my Evo 4G to get my home internet. I was on Sprint and found out the 4G coverage by my house was great. I could get 12Mbps down and 1Mbps up. This was perfect for what I needed. I could watch Netflix in HD on my laptop over my phone! It was a great deal except for the fact that I needed to use some annoying software called PDA Net. At the time you could not get 4G on an iPhone so this was a huge upgrade from the original iPhone 3G I was using. Better camera, better OS features, many that would eventually come to iOS7, and I was saving at least $45 a month on home internet. I was living in the future! Only problem, tethering sucks, oh yeah and the crappy Micro-USB port was the bane of my existence, constantly failing and disconnecting me from the internet. I went through several cords and phones during that time. This is why I switched to the Galaxy SII. I still needed a WiMax phone but was fed up with the USB port going bad. Well no relief there. In fact I think I was better off with the original Evo 4G in that regard.

Now I don’t need to tether and the battery issue is a bigger problem because enow that I live with Christine, she and I need to be in touch more frequently. But I still love the web and am not a big app user. It really annoys me to be stuck downloading an app to read Hacker News with different word-wrapping and larger font just to have it pop up a browser that can’t wrap text dynamically when I click on an article. Now as we look to a future of wearables and an internet of things I shudder to think how these same kinds of issues are going to leave us adapting to a host of new and broken technologies. What will be the Google Glass version of “cant wrap text” or the iWatch version of “can’t play flash video” or the self-driving car version of “crappy USB-port.” More importantly when these issues do arise, whatever they happen to be, will we adapt our behavior to work around these problems, will we even recognize our behavior as such an adaptation and what kind of idiots will we look when we do?

Advice to a developer in training

I’m a self trained front-end engineer. I started out in fine arts and design and now combine both creative and technical skills in my daily work. Everyone learns differently so what works for me may not work for you but heres some advice to new developers in training based on my experience.

I remember sitting in my university computer lab back in the late 90s trying so hard to figure out JavaScript with no idea what I was doing. It was mostly playful curiosity that kept me going. Learning on my own this way was a long and hard road but it forced me to figure out how to pick this stuff up in my own way. This is a good thing.

Side-projects, side-projects, side-projects! 

Work on something interesting and it will challenge you. The fact that it’s interesting will provide the motivation to push through those hard times when you have to pick up a new skill or concept or figure out a hard debugging issue. When you’re finished you’ll have something for your portfolio and the experience gained will be more valuable than simply being told how to do it.

Have a place to get industry news and follow it frequently

I recommend http://news.ycombinator.com/ and http://www.smashingmagazine.com/. There are many more, these kinds of resources should provide you with ample new ideas that will stretch your skills and mind simply by reading about something new.

You need people to talk shop with

Develop connections with people who are also interested in the same things and keep in touch with them. I constantly learn from my friends and coworkers. Find people at meet-ups, BarCamps, local user groups, co-working spaces. DO THIS.

Become a curator of your own resource library

It may simply be a list of great websites you frequent, it may be something more structured  like videos on lynda.com, books are just as much a mixed bag as the net. Finding and learning from great resources is an essential skill to develop.

Read official docs

For example the jQuery docs are excellent. Go to the API docs and other good references first before scouring the net for a tutorial.

Read lots of source code, learn from other projects.

No much to add to that, just do it.

Motivation + good resources makes a huge difference

I remember trying to learn c and 3d programming and being stumped for a while. Eventually I gave up. I wasn’t motivated enough, but a few years later I became OBSESSED with 3d terrain rendering algorithms. Something I knew NOTHING about. I found a few good books, read white-papers, 80% went right over my head. I plowed through anyway. Eventually I found the resources I needed to learn. One was called 3DBuzz.com by far some of the best instructional videos I’ve ever used.

The long march

When you do this stuff professionally you won’t be able to count on a class or some program to teach you something that will probably be very specific that you have a tight deadline on. Which will happen frequently. This is an industry of OJL (On the Job Learning) This is where fear forces you to bear down and just figure it out yourself. But that doesn’t mean you’re on your own. You should cultivate a group of peers you can go to for advice, never neglect that resource. I guarantee there are excellent resources for almost any problem you will run into and you’ll need to cultivate that ability to identify what you know, what you need to know and what, of the mountains of resources out there, are worth your time. This skill comes with experience.

A good developer embraces this as the way things are, a large part of your skill-set as a professional will be figuring out how to pick up new things. That said once you have a good foundation and a few successes under your belt in picking things up, as well as a few nightmarish death-marches to solve an impossible problem or two, these things will come more easily. I promise.

Also this is very much a craft profession, it can take a good decade to become a great programmer, a master craftsman (or woman) if you will. You need to learn multiple languages and most importantly make lots and lots of mistakes. This is a long march not a sprint not even a marathon, so don’t get discouraged. Have a growth mindset every setback and brick wall is actually an opportunity in disguise to jump ahead along that path to become a master at your profession.

I hope that helps.

Inventions, Patents, Openness and Security on the Web – Part 1

When I was a kid I was taught about all the great American inventors and dutifully idolized them all. When people would ask me what I wanted to be when I grew up I would answer some combination of painter, inventor and monster truck driver. Fundamentally I am a tinkerer who comes from a long line of tinkerers. I grew up hanging out in my grandpa’s workshop watching him fix vacuum-tube radios and TVs and I spent a good amount of time in my dads mechanic shop watching him and the other mechanics work on engines and transmissions all day long. The environment of my childhood was rich with all the pieces of stuff needed to make my imagination run wild with notions of building robots and go-carts and who knows what else. INVENTIONS!

But soon I would realize that my dreams were bigger than my abilities or my budget so my inventions were limited to the page or Legos. It wasn’t long before computers started invading my world and my imagination with new blank canvases waiting for fresh creativity. First I was making pictures on the computer, pixel by pixel, then with shapes and layers and photos. Soon I was making animations, 2d and 3d. Then the internet came along and I was building interactive web pages, then servers and databases and applications. By the time I got out of high school I was starting to do some real programming and that was when I realized it. This is where I can finally do some serious inventing.

Inevitably when you start talking about inventions the idea of patents come into play. As a child I thought that one day if I were a successful inventor, as did all my childhood idols, I would have many patents to my name and they would make me wealthy. But as I grew into becoming a web developer as a young adult I realized the world changing power of open collaboration. It was obvious to me that the positive social values and the ultimate effectiveness exhibited by open source software projects like linux or community driven efforts like wikipedia were long-term trends that would inevitably beat out the traditional closed models. Of that I had no doubt.

I also come from a family of small business owners and being one myself has always been a personal dream. It has been clear to me for many years that I have the lucky opportunity to achieve both of my dreams within my current profession. So in 2010 by the time the movie Social Network was released I had already been long down the road of seeking to find a business problem and a software problem that I thought would be worthwhile. I can’t tell you how many horrible ideas I’ve had, but I have had a few that were worth digging into and one that I even thought was worth patenting. All along the way, at various points and in various ways, life impinges it’s limitations on such efforts and I must admit I’m a bit of a distracted driver when it comes to the road I’m going down at any given moment in my life. A die-hard entrepreneur would say that if I were truly serous I’d take my shot and quit my job and go full time on whatever business I was trying to build. That may be true but when I look back at all of my ideas so far there are none that I think are worthy either because they are not solving a meaningful-enough business need or they are not very creative. But for the remainder of this post I’d like to talk about that one fairly decent idea I have that I initially tried to patent, mainly as investor-bait and have since decided to share.

In the summer of 2011 I was deep into the process of developing a service that was much like a mix between Parse.com and Twitter with a payment mechanism built in. An api for building mobile and web apps where people could buy virtual goods within the system and get paid for their own virtual goods. The problem I was running into was that OAuth seemed to be a weak point in the security. People are perfectly happy using OAuth for social networking but for something involving money? Furthermore OAuth was designed for the web and hastily put into use in the mobile context without careful thought. Its not like this is easy stuff, and I’m certainly no security expert, but sometimes its the fool who asked the obvious questions that all the experts take for granted. It was this search for answers to such very simple questions that was helping me to build an understanding of how web security works that was much deeper than what I had known before.

So to explain the solution first I need to explain what I learned and identified as a problem. The trustworthiness of each operation that happens on the web is subject to threat from any one small part of a very complex and interconnected system that includes everything from an oversight on a line of source code in the client application to the password salting process or data logging practices on the app server all the way up to security of the user’s computer and the developers computer and the security of computers running the application to the servers hosting the source code and those developers computers and everything in-between. For example if the client doesn’t force the use of https and verify that the certificate is valid the chain of trust is very weak, man in the middle attacks are then very easy. If the user’s computer is compromised in the first place a key logger or malicious software could be logging keystrokes, stealing passwords. If the user has re-used passwords (likely) they have increased the threat that some other system they use will become compromised and serve as a gateway for hackers into the system you are building. If the password gets logged in plain text on the server because it was sent over a GET request you have a serious data leak. If the database is somehow stolen, the passwords are salted yes, but with modern password recovery tools and the power of cloud computing hackers have the ability to crack a large portion of those paswords automatically in short order. There are literally hundreds if not thousands of such chinks in the armor. Really it can hardly be called armor at all it’s more like underwear because for the most-part what people call security is about doing just enough to cover their ass. “I did my part, see passwords are hashed.” Really? Well your ass is covered isn’t it? Feel safe with your reflective underwear then do you?

Confounding the problem is that the system is opaque, you can’t simply look at a system and know if its secure, you can’t easily know if all the holes have been patched or even how many potential holes there are in the first place. It’s a pains-taking process that costs time and money. No doubt it’s a jungle out there to be sure but maybe there is hope. Lets say you do patch the holes and you do more than just cover your ass. At that poing for the most-part, hacks happen through the application layer and through social-engineering. Now we have a manageable scope and a world where we can begin to form what I’ll call the chain of trust.

The chain of trust starts with a ceremony of secrecy. This is the account creation process where a user sets their password. From the perspective of any system this is the foundation of what it knows to be truth. If it can’t trust that a user account is associated with one individual that keeps their unique secret then all bets are off. Next is the trust that the client environment is secure. Beyond the scope of the application itself this is out of the purview of your average developer. The key here being that the client application act as if it lives in a hostile environment, that means not storing auth codes and secret keys in the source code, not storing passwords on the client etc. Next in the chain of trust is the network connection to the server that authenticates the user. This of course needs to be secured over TLS with a valid certificate, as do all other network connections. Next in the chain is the server environment. This is where apportioning the least authority possible to a process and a machine are very important as are good key management practices and properly provisioning machines using things like Amazon’s IAM service. Lets say we do all this correctly then at this point we have a sold chain of trust built essentially on a few key components, encryption and the protection of secret keys, the provision of least authority to any piece of the system at a given moment, oh and that pesky user’s password. This is the point where I was in the summer of 2011 trying to build a kind of mobile application data API not unlike Parse.com or Twitter with a twist.

There are multiple parties involved in the service I was working on. There would be the application developer that would use my API to simplify their lives. There is the user that would download said application onto their device that would simplify their lives. And there was my service that needed to store the data securely and hand it out to just the right people that would greatly complicate my life. The twist in my system comes from the fact that it was intended to keep the user in control of how their data got used. Even though the data was built up using the third party application, that third party would not have access to the data outside of what the user agreed to. Also my system would limit an application’s access to a user’s data based on a profile of each application. Most applications would have access to a bucket only it could see. Other scenarios of shared access would require user approval and would be subject to a kind of DRM contract that could include some kind of payment to the user for access to their data and users could always revoke access. I essentially wanted to put DRM into the hands of the users so they could take ownership of their data and let it out as they saw fit but make it simple enough to be viable.

There is a problem with this of course, where does the user account originate and live? Well it would need to be under my roof and that severely hampers the user experience as perceived by an app developer. “Oh hey go to this completely unrelated place to create your user account so you can then use our app. Thanks!” Not an easy sell. But this is essentially the world we live in now, login with Twitter or FaceBook or Google is essentially this. But generally those are very well known services and often applications will provide the option to log in by creating a new account outside of those services, one specific to the application you are dealing with. I would have the benefit of neither.

To be continued in a forthcoming part 2 including a new approach to mobile authentication.

loot.js $dom

Something I’m pretty happy with out of my loot.js project is the $dom function. I saw this post on Hacker News by Neil Jenkins about a dom constructor $el funciton that used a css selector to define the tag class and id, an object to define other properties on that tag and an array for the children. I thought this was awesome and started using it but wanted to eliminate the function calls for each node and also wanted to be able to store a complex dom structure and later use it with the function. This lead me down the path of something much like hiccup, although I didn’t learn about hiccup until after I had nearly finished $dom it seems to be very similar. One final requirement I had was that I wanted to be able to produce dom structures AND output htmlText in node.js without using jsdom, I will explain how this works later in the post.

Here is a sample of using loot.js to build dom structures.

define a tag with css style selectors

$dom("div");
$dom("div#someId");
$dom("div.someClass");
$dom("div#someId.someClass.someOtherClass");
<div></div>
<div id="someId"></div>
<div class="someClass"></div>
<div id="someId" class="someClass someOtherClass"></div>

optionally add some properties

$dom("input", {type: "text", value:"foo"});
<input type="text" value="foo">

innerText and innerHTML

$dom("div", "some inner text");
$dom("div", "<p>some inner html</p>");
<div>some inner text</div>
<div id="someId"><p>some inner html</p></div>

child nodes can be defined by nesting the syntax in an array

$dom("ul", [
	"li", "this is some inner text"
]);
<ul><li>this is some inner text</li></ul>

still works fine with properties

$dom("select", {name: "mySelect"}, [
	"option", {selected: true}, "this is some inner text"
]);
<select name="mySelect"><option selected="selected">this is some inner text</option></select>

if it looks like a valid html tag/selector it will become a sibling, otherwise it is treated as text and will become inner text for the prior node

$dom("ul", ["li", "li", "li"]);
1
<ul><li></li><li></li><li></li></ul>

the space in the 3rd li will actually force it to become innerText to the 2nd li

$dom("ul", ["li","li"," li"]);
<ul><li></li><li> li</li></ul>

the sibling/inner text rules can combined

$dom("ul", [
	"li", "first item",
	"li",
	"li", "third item",
	"li",
	"li", "fifth item"
]);
<ul><li>first item</li><li></li><li>third item</li><li></li><li>fifth item</li></ul>

To facilitate storing these dom structures in variables and then passing them into the $dom function you can wrap everything in an array and pass that one item into the function. These will produce equivalent output.

// two arguments
$dom("ul", ["li","li"," li"]);

// one argument
var myList = ["ul", ["li","li"," li"]];
$dom(myList);

Dom nodes are also valid values.

var li = document.createElement("li");
$dom("ul", [li, li.cloneNode(), li.cloneNode()]);

There is an imperfect check to determine if a given string is a tag or innerText. First it checks for a valid, leading tag name from the following list.

//tags list derived from http://www.w3schools.com/html5/html5_reference.asp
var validTags = "a abbr acronym address applet area article aside audio b base basefont bdi bdo big\
		blockquote body br button canvas caption center cite code col colgroup command datalist\
		dd del details dfn dir div dl dt em embed fieldset figcaption figure font footer\
		form frame frameset h1 h2 h3 h4 h5 h6 head header hgroup hr html i iframe img input ins keygen kbd\
		label legend li link map mark menu meta meter nav noframes noscript object ol optgroup\
		option output p param pre progress q rp rt ruby s samp script section select small source\
		span strike strong style sub summary sup table tbody td textarea tfoot th thead time title\
		tr track tt u ul var video wbr";

I say this is imperfect because it is possible that you will want to use one of these words as an individual innerText value, and that will not work. Unless you add something to it like an html tag, some whitespace, or more words a singular string from the list will become a dom node.

From this point I started using $dom and added partials and some other helper functions to build web pages with.

$part("docsPage", function(data) {
	return $dom([
		"<!DOCTYPE html>",
		"html", [
			"head", [
				"title", data.title,
				$part("headInclude"),
				"link", {type: "text/css", rel: "stylesheet", href: "/css/docs2.css"},
				"link", {type: "text/css", rel: "stylesheet", href: "/js/prettify/solarized.css"}
			],
			"body", {id: data.pageId}, [

				"div.midNoise", [

					$part('headerInclude'),

					"div.container.span17", [
						"div.row", [
							"div#nav.span3.overlay", data.index,
							"div#doc.span13", data.content
						]
					]
				],


				$part('footerInclude'),

				$part('bottomInclude'),

				$js("/js/prettify/prettify.js"),

				$js("/js/bootstrap-scrollspy.js"),

				$js("/js/docs.js")

			]
		]
	]);
});

somewhere else in the codebase
the $render function renders the partial we defined above by referencing it with the same name.

app.get( "/docs", function(req, res) {
	res.writeHead(200, {"Content-Type": "text/html"});
	res.end($render("docsPage", {
		title: 				"mySite.com",
		pageId: 			"docsPage",
		pageTitle: 			"API Docs v0.1"
	}));
});

whaaaa!? This is pure JavaScript not a templating language. Do you know nothing…

I’ve always felt like templating languages were annoying and still far from some unknown best solution. How many ways will we redefine how to do iteration in some foreign templating language syntax? You hear a lot about how templating systems should be simple and understandable by non-technical persons like designers, whatever that means. If you can understand Adobe Illustrator you should be able to figure out some JavaScript. Also these things end up creating their own complexity that can rival that of a full-blown programming environment. Or there are the warnings of putting too much business logic in your view code and hence we need dumbed down templates to force ourselves to abstain from going hog-wild with the full power of code in the view. Well fooey to all that! I don’t reject these things because the are wrong, I reject them because I don’t want to use them. I’d rather use something in my own projects that keeps me in the code and I’ll use my own judgement as to where to put business vs view stuff thank you very much.

better support for iterator return values

I just added new functionality to the $dom instruction parser to play nicer with inline functions like $map that return a data-structure. First lets look at how you could use $map before.

var colors = ["red", "green", "pink", "blue"];

var colorList = $dom([
	"ul", $map(colors, function(color) {
		return $dom(["li", color])[0];
	})
]);

The $map will return an array which is perfect for defining the children of our ul, but what to return from the iterator? Well in the old way above one thing you could do is another call to $dom or some other node constructor. In our case we use $dom and since it returns an array of nodes you need to pull out the node from the array. This is one thing that $part took care of for you. Otherwise the parser will choke on the inner arrays expecting to first see either a selector or a dom node. But now all of that is irrelevant :-)

Now if the first item in an array is another array that will be a signal to the parser to expand the contents of the inner array and treat it as if it didn’t exist.

var colors = ["red", "green", "pink", "blue"];

var colorList = $dom([
	"ul", $map(colors, function(color) {
		return ["li", color];
	})
]);

In the process the following structure is produced.

var colorList = $dom([
	"ul", [
		["li", "red"],
		["li", "green"],
		["li", "pink"],
		["li", "blue"]
	]
]);

Seeing an array as the first child the parser then concats all the inner arrays together and all is right with the world.

var colorList = $dom([
	"ul", [
		"li", "red",
		"li", "green",
		"li", "pink",
		"li", "blue"
	]
]);

This also applies to objects. In $loot the $map function and it’s friends work on objects transparently, rather than calling $map($values(myObject), iterator) you can just do $map(myObject, iterator). The iterator never needs to change in most cases and the difference is in the return value, the latter returns an object with the same keys as the original object but the values are those returned from the iterator function. This is one of those experimental features of $loot.js


var items = {
	one: "item one",
	two: "item two",
	three: "item three"
};

$dom([
	"ul", $map(items, function(val, key) {
		return ["li."+key, val];
	})
]);

The resulting output would look like this.

$dom([
	"ul", {
		one: ["li.one", "item one"],
		two: ["li.two", "item two"],
		three: ["li.three", "item three"]
	}
]);

Seeing an array as the first value in the object the parser treats it not as attributes for the ul but as a map of children. It concats the array values and Voilà!

$dom([
	"ul", [
		"li.one", "item one",
		"li.two", "item two",
		"li.three", "item three"
	]
]);

string mode

FInally I mentioned at the beginning of this post that if you want to switch to string mode you can do that. $dom uses tow other apis, $node and $doc which present the minimal set of functionality for $dom to do its thing with nodes or strings it is basically a tiny, very limited mock dom api. To turn on string mode in the browser just call $doc.useRealDom(“false”); you can switch it back by calling it again with true. In node or any other environment without a document object it will default to the mock dom and the useRealDom method has no effect. You have to be careful with this however because depending on the state of the system some code may work while other code may not. Clearly this is not the optimal solution to this idea of supporting both dom nodes and html strings but it works for now.

but is it fast?

Short answer, NO!

I’ll post some benchmarks but suffice to say its a couple orders of magnitude slower than many of the templating solutions out there. A compiler for this system would need to somehow allow for all the things you can do in javascript while pulling out the static bits as a precompiled template. I’ve begun looking into that but it would require some serious ast parsing. That said there are probably plenty of gains to be had, I have not spent any time optimizing this yet. But when you consider the overhead of the browser and its ability to simply update the dom, the bottleneck is not this $dom parser but the browser itself. So sure you can use some templating language that can build you a million complex tables in a second or two but it will take many times longer for the browser dom to catch up so in practice $dom is viable in the browser for that reason. On the server even if you have a fast templating engine the best bet is to cache heavily if you have lots of server load. In situations where you are sensitive to performance of non-cacheable stuff then you should not use this code otherwise I think its ok.

Loot.js

My latest side project has been Loot.js

There are plenty of rough edges: views are basically a joke right now, it’s bloated, one of the coolest functions $dom, is slow, but still very useful!

So what is it? Well it’s basically a bunch of functions I like to use as globals prefixed with $ eg. $id, $each, $async, $map, $dom, etc…

Please don’t tell me how wrong-headed this approach is and how baaaaad very very bad globals are. I know, I know, I’m doing it anyway!

There are lots of pieces that I have taken from projects I like such as underscore.js and async.js among others. My contributions with this “lifted” code are largely in modifications and integration of these functions for example the $async function and it’s ilk use the underscore iterator $each, which is actually hardly the underscore iterator anymore. It has been modified heavily as have all the functional type functions to iterate over objects as well as arrays. So this is very much experimental, I’m not trying to create the next great library or framework. God knows we have enough frameworks fighting to get a fraction of the attention Backbone gets.

But thats not all I have done here, there is a really nice pub sub system in there, $speak. I’m pretty proud of it, the performance is great the functionality is rich enough yet the implementation is fairly simple. There are object creation helpers as with any of these things, $new helps you do prototype inheritance, $mixin, and $extend respectively copy owned or all properties to one object from another. There is a nice little object $cache, and object pools with $recyclable, there are VERY basic models and much more!

This is also a testbed for some experimentation with a different approach to generating html and dom structures. This is expressed in the $dom function that can take a json structure of essentially nested arrays and generate an html string or a dom structure out of it. This is very cool, you can basically have json representations of dom and treat it as a data structure, iterate over it perhaps, WHO KNOWS WHAT CRAZINESS YOU COULD DO WITH IT. There are also partials with the $part function. So you can generate templates and nest structures. I think this is fun. Is it a fast templating system? HECK NO. Optimization is not something I have spent time on. I’m just happy to see tests passing.

So head over to github to check it out and let me know what you think. There are lots of tests, a couple performance comparisons with big name frameworks and a good bit of code samples and documentation in the readme.md

https://github.com/andrewluetgers/loot

The civil rights battle of the 21st century.

The new avant-garde is made of hackers, amateurs, makers, DIYers and entrepreneurs. If only we all knew how revolutionary and politically charged what we do really is. There is a tsunami of technological, cultural and political revolution brewing. Even after all we have seen in the arab spring, the occupy movement and the battle over SOPA/PIPA it’s clear that we are in the early stages of a longer term war. Thanks to a wide gamut of technological forces the balance of power has shifted dramatically in favor of the masses over the masters. Its what makes this moment so unstable for both established powers and established freedoms. The open question is if we will accept the role of rightful creators of our own world or will we be contented to stay disengaged, small-minded and apathetic like the rest of the sheeple out there. Decades from now when our time has passed will we look back and see a flurry of creative destruction heralding a brighter future or will we instead lament the crescendo of controls, limits, gate-keepers and dictators? Make no mistake, this is the civil rights battle for the 21st century and it will require a similar amount of organization, effort and determination that was needed in the 20th century. The fate of this cultural upheaval is now within our hands, we need only grasp it firmly and not let it be given away by idiots or taken by crooks. We mustn’t let go of it now that we have it and now that we do, we must recognize how insanely huge this moment is. When they realize we aren’t about to let go of this thing, they will try to wear us down. If that doesn’t work they will try to co-opt us. Sadly I can see both of these strategies being successful. Lets not let that happen. Lets own our future rather than give it away. It’s time for the new avant-garde to unite and show the world what the future will look like by making it now. Otherwise we will be hoodwinked into a future of share-cropping for a few massive plantation owners as a bunch of contented, small-minded, apathetic, suckers.

Why the rampant fanboyism around CoffeeScript worries me

note: this is a work in progress only 2/3 done. More to come soon!

It is good! We are saved!

Since 2009 when the world was introduced to CoffeeScript it has steadily gained momentum and in recent months its starting to seem like its become the inevitable progression from current day JavaScript to “the future is here” language of the Gods. By the title of my post you can probably guess I’m, shall we say, dubious of all the sappy love poems that are being written about CoffeeScript. I had been at first interested, then trepidatious and now at times almost seething about all the hype and yes rampant fanboyism growing around CoffeeScript.

But why? Why must I be the lone grump at the party?

That’s what this whole epic post is about so let me first say I’m not trying to be a troll here. I actually have some serious points to make and the first one is we should rightly give huge recognition to Jeremy Ashkenas, CoffeeScript IS a thing of beauty. It works, its a whole new language and yet it compiles down to plain old JS and it lets us try out some cool new language features and syntax, awesome right? And most importantly it is helping many programers love what they do and yes be productive. Even the royalty of JavaScript have nothing but praise: the God/Creator of JavaScript Brendan Eich had this to say when sharing the stage with Jeremy at this years JS Conf in Portland.

“It helps to have things like CoffeeScript out there it isn’t overriding, it doesn’t tell us what we must do but its suggestive, and if we want to pave that cow path we can, and I’m in favor.”

Or how about my personal idol, Doug Crockford when asked about CoffeeScript after his excellent talk on code style at this years TXJS conference in Austin.

“I think CoffeeScript is clearly good stuff. CoffeeScript is elegant it sort of takes the good parts, removes all of the stupid awful syntax that were inherited from the wrong languages, replaces it with something that is small and elegant and expressive. CoffeeScript is really great. And CoffeeScript is having a big influence on the ECMA Script committee….. CoffeeScript is definitely in the right direction and I would like to see future languages looking more like CoffeeScript than like C.”

So what do I really think? I think CoffeeScript’s big selling point of increased productivity is completely bogus because it optimizes for typing fewer characters vs readability when it should do the opposite.

Don’t be that guy

Clearly I had better be careful, I’m treading on very thin ice here… but I can’t hold it back any longer to be totally honest. I hate this designer language bullshit. Ahhh that feels better. Damn I thought this wasn’t about hating, but there I said it. It really is nothing personal against all the people that love CoffeeScript, but I get the feeling that CoffeeScript is just some hipster code for people that like the idea of being great programmers and super efficient at what they do but really don’t have the need for it. But that’s just one jerk’s opinion so go on loving it and using it for all I care.

OK now that I’ve purged the demons lets discuss the actual arguments I have. You may be surprised to note that, in fact, there are many common criticisms of CS that I’m going to skip right over. I have no intention of retreading the old complaints of the “leaky abstraction” argument, or the “compile step is a pain” argument, or the “debugging is a pain” argument, or the “output JS is less than perfect” argument. These complaints, weather valid or not, do not concern me. Moreover this post really isn’t about CoffeeScript at all, it goes way deeper than that. Its about the influence of CoffeeScript on the JS community and the direction of the ECMA Script standard itself. So here are my three arguments.

If you didn’t catch that, what I’m saying is that the following is not attempting to be a CoffeeScript hit-piece its about the direction of JavaScript. 

  1. Stripping characters from the syntax is a false solution to increased productivity
  2. Overly terse syntax can make code harder to scan and understand.
  3. JavaScript as a compile target weakens and fragments the community

Ultimately I think the ongoing pursuit of a more perfect programming language is a noble one. Despite the good intentions there are some very disheartening tendencies I see coming out of the ECMA Script standards body and I don’t want to see the language spec itself turned into a dumping ground for “whats hot now in language design.” Broad assumptions about productivity and what the JS community need and want are being made in ECMA Script discussions for the next JS veriosn after ES5. This is where I start to get seriously concerned. So lets address this head on.

What really matters here anyway?

Ultimately the best thing about JavaScript is its amazing community but I’m concerned its getting distracted trying to fix things that are not broken with shiny new syntax and cute language features. (yeah I know you’ll mention all the bad parts of JS now) It feels like all so much newness for newness sake. Rather than diddle with our keywords and curly braces I’d rather see the JS community focus on solving real world problems through the power of our code and our collaborative energies. Lets quickly peek at an example of what I’m talking about, shall we. Take a look at the Github profiles of LearnBoost and its employees. If you know anything about the node.js community then you’ll agree these guys are titans. In particular check out visionmedia (TJ Holowaychuk) a new idol of mine. TJ is a machine! Ask yourself if your organization has been as productive as LearnBoost or if you’ve created 1% of the value that TJ has for the js community and his company. I guarantee whatever the percentage you come up with is, futzing around with the language is not going to make it go up. Note: as far as I can tell TJ is a pretty big CoffeeScript skeptic as well.

Lets unpack our assumptions that are propping up the strong emotions we have around some feature or syntax. Ultimately all this is about being more productive so lets find the best way forward for this conversation that puts the focus where it needs to be. Helping developers ship good code often. (Just a preview: Surprise, surprise, the language and its syntax are not key factors here.)

But Maybe I’m Wrong

Perhaps in a few short years, or months at this rate, someone will come by this blog post (yeah right Ive had all of 5 visitors) and think “ohh how quaint, there once was a day when lesser programmers thought so highly of their decrepit old ways as to question the perfection that is CoffeeScript which has freed humanity from toil and is clearly right and good. Praise be to Eich, Amen.”

Well I guess I’ll just have to be that guy then. I just hope I don’t sound like I’m trying to sell and old outmoded technology like this dude.

Check yo self

Before I get to the three arguments lets first do a little meta-cognition just to check ourselves. We should always be the first ones to point out our own foibles. By always reminding ourselves how we commonly stray from sound reasoning we can hopefully, more often than not, catch ourselves in the act. This is also for those who would suggest that I’m being ignorant or biased in some way that in fact I’m actually trying really hard not to be. Here are three points I have seriously considered over the past week while I’ve been writing this.

First Head Check: - This study found people have a bias to truly creative ideas. The studies’ findings include:

  • Creative ideas are by definition novel, and novelty can trigger feelings of uncertainty that make most people uncomfortable.
  • People dismiss creative ideas in favor of ideas that are purely practical — tried and true.
  • Objective evidence shoring up the validity of a creative proposal does not motivate people to accept it.
  • Anti-creativity bias is so subtle that people are unaware of it, which can interfere with their ability to recognize a creative idea.
So clearly by this point it looks like I’m just biased to a truly creative, new idea. But I would argue that this is not whats upsetting me. Read on.

Second Head Check - Programmers love the language they know and everything else sucks.

Programmers have peculiar, near-religious emotions about programming language preferences. There is a constant battle between programmers of all stripes and the arguments are all over the board. “This language is better than that because of x, y, z.” “Here are ten reasons why your language sucks.” Etc. Etc. In one of his talks I recall Douglas Crockford bringing some great perspective to this incessant fracas. Sorry I can’t find the specific video so I’ll summarize.
  • Moore’s Law means doubling in performance every 2 years or so.
  • Software is not ruled by Moore’s Law, its ruled by Murphy’s Law.
  • We see leaps in software performance in roughly 20 year increments.
  • Part of this is due to the generational nature of language preference.
  • Programmers (and everyone else) are biased to what they know and love and reject new ideas (see first head check).
  • So it takes a whole new generation of programmers to legitimize a new language.  A generation that is not encumbered by prejudice and preference of an old inferior language.
I could simply be falling into this nasty trap. JavaScript is my favorite language for well over a decade. Its what I think about all day, its what I dream in. That makes me all the more likely to defend it out of emotion rather than reason. But although I’ll recognize that I do have strong emotions about this matter I assure you they are because of objective reasoning about productivity. There’s far more to meaningful productivity gains to be had in this world than what you could maybe get from some new language-feature soup in a stripped down syntax.

Third Head Check- We all want to feel like we are in control and know what is best.

Have you ever worked with that manager or colleague or fellow student that just had to take ownership of everything? You show them something great and new and they have to start hating it right away and put their little fingerprint on it before its good enough. And by fingerprint I mean repeated blows from a sledge hammer. People like this are roadblocks to innovation and getting good work done efficiently. They must feel threatened, disrespected for not being consulted, and from their perspective their valuable knowledge and skills are needed. Ultimately they get their way, preventing change for a multitude of off the wall reasons. They get their way or else there’s high drama and who has time for that? So now innovation has been stifled (or in their minds a fire has been put out) and hey they feel better and “now we can ship!”

Could that be me? God I hope not, those people are really annoying. But resistance to change is natural. If things changed all the time we would just be stuck in perpetual adjustment to the new conditions. And sometimes lack of change is a very good thing. (some people call it stability) One of the best things to happen to JavaScript was the dominance of Microsoft in the browser-wars and the following half decade of nearly zero innovation from them. It left the stage ripe for a dusty and ignored technology, XML HTTP requests, to herald in a new age of software on the web. But we should be farther ahead by now and yet we’re still futzing around with essentially the same web 2.0 widgets. Take a close look. The drastic changes in syntax CoffeeScript brings to the table looks like mere chipping at the edges when you think about what really needs to change to give us the next 20 year cycle of software innovation. Douglas Crockford argues its about distributed computing with the Actor Model and a stronger security framework. I totally agree about the need for better security and better distributed computing. I don’t care how terse your syntax is, its not going to have an effect on these problems.

So head checks complete, lets (finally) get right into the arguments

First Argument: Stripping characters from the syntax is a false solution to increased productivity.

In fact my second argument below is that removing the characters makes the code harder to scan and quickly understand, thus making you less efficient. But lets look at this whole myth of “terse code is more productive because you have to type less.” When did this motive arise in the JS community? I have noticed in a few older videos Douglas Crockford and Brendan Eich asking the audience what they would like to replace the function keyword with. “how about the florin?” Doug asks for people to raise hands. He gets few bites on his various ideas and then relents and asks “no change?” This elicits a big response. What the hell? Where did this crap come from. When did anyone ever have a problem with typing the word function? And now they want to use -> instead because its soo much shorter. Well haaang on there. It jsut so happens that typing “function” is not very hard to do. In fact most IDEs will auto-complete it for you. And yet this is a big deal in the new Harmony discussions? Heres Brendan talking again from the JSConf video I liked to above.

“On more thing that I think I have to talk about because I talk about it at every talk I give which is function syntax. Im still paying for usings 8 letter key words in 1995 I think I took it from awk and ahh heh I shoudnt have done that, I should have used fn and we would have been past this becasue probably two letters is short enough. Um and were using fn in rust at mozilla. But its hard to change and the idea that you would use of a greek lamda which is an actual unicode identifier allowed in ES3 and ES5 or the florin which Doug Crockford suggested but didnt really champion, those don’t really ring true. Then there was a proposal to use hash but I think we want hash for something else and I have kind of come to realize, to be very frank, that CoffeScript has already done the right thing, C# has done this. So I am proposing for the next ECMA Script meeting, and wish me luck becasue it is not a sure thing, that we just standardize this. That what people really want is very sweet short function syntax without that leading key-word and the arrow form in CoffeScript gives us that…”

And then theres this gem.

“It matters becasue keystrokes matter and you see this over time you see people gravitating to lighter syntax you see productivity mattering in the long run even if it is a small win.”

I have a question for every single group of product developers that have a great idea about “what people really want.”

Hey Brendan Eich, I’M TALKING TO YOU

My question is can you prove it? I have a very strong suspicion that of course you can’t prove it. You have two crappy languages that use it and thats enough of an excuse? All to do what? Scratch an itch youve had for a long time to make the language more terse to save on 6 keystrokes? There are actually valuable scanability and readability benefits to having the whole word there my friend and the fact that a vocal minority and a few language dictators such as yourself on the ECMA TC39 panel have a Jones to shorten the function keyword into an obtuse abstraction is a hairs breath away from changing the dot operator to do concat like in php or something stupid like that. THERE IS NO FREAKING REASON TO DO IT. You have given no real reason, just the off hand remark implying (and I paraphrase) “of course its obvious that EVERYONE wants this because it will make us all SOOO much more PRODUCTIVE.” Admit it Brendan you can never give a good reason for switching function to -> let alone one that would warrant changing the worlds most popular and widely used programming language to be less readable. This is because there is no good reason. Its just your language-designer tastes that are waaaay too, well, designer. You’re picking out the European orange leather couches and all we want is the damn roof to stop leaking and the foundation shored up.

In your own blog you call for dialogue intend to listen to the JavaScript community and its “natural leaders”

“JS developers and implementors on TC39 must learn from one another and “meet in the middle”. The Harmony goals are good. But developers may do only what can be done in library code, or reach for CoffeeScript or another language on top of JS. And TC39 may over-invent.

The better way is a dialog between JS developers, especially natural leaders among them such as @jashkenas, and TC39 members.”

How convenient, it must simply by a wonderful coincidence that you happen to be promoting CoffeScript style syntax and Jeremy Ashkenas makes your short list of “natural leaders” in the JavaScript community. I wonder what the jQuery team thinks about all your proposals, or what the node.js committers think about your proposals or what other (I would argue) greater leaders in the js community think about changing the function key word or paren-less syntax. Well have you asked them? I think you already know and are only hilighting the person that agrees with you the most.

OK im done ranting at invisible Brendan Eich now (as if hes going to read this) :-)

Edit: the “invisible” comment was not trying to make Brendan out to be an absente landlord of the language, in fact he is extremely open and available and should be commended for being so.

I am not the only one that is concerned about the direction of JS with all the new Harmoy proposals and the things that are being pushing beyond that. I think I have some bakckup on this in the form of Ryan Dahl. If there is anything like a natural leader in the JS community he is certainly one of the most influential right now. And he counts one of the most vital portions of the JS community as his army. So i was very heartened when Ryan Dahl ripped into the ECMA Scipt committee at node conf.

“I wish ECMA Script woudnt be so ahhh “fancy pants” about adding all these features. We need 64 bit integers, please do that first. Then think about proxies in like ten years or like after we’re all dead. (applause) JavaScript does not need more features it just needs a couple of small things fixed.”

Thankfully Brendan was sitting in the audience for this very panel discussion and eventually got up on stage himself to address the matter.

“Everey tool has edges you need to smooth out so theres more work to do on JavaScript usability. When you look at how its used in Node its a bit different than how its used in the browser. Theres some overloap but looking at Node makes me think more about binary data and even 64 bit ints. It makes me think more about um.. getting rid of the spaghetti monster. The client has solved that a long time ago and it doesnt nest as deep I think, the logic doesnt chain as deep.”

Ok it sounds like Brendan Eich can come around to logic and reason. Cool.  We’ve established why they seem so hard up to change syntax, they assert with no evidence that everyone wants it and that it makes us more productive to type less. You’ve got my feelings on the whole everyone wants this BS. Lets address the really important thing here. EVEN IF everyone wanted it, it would still be the wrong thing to do. That is because it will do nothing positive in the way of productivity if anything it will certainly reduce readability and thus lower productivity.

“So what is it that productivity stems from if not typing less?” I’m so glad you asked we can finally get to something actually important. (I told you we’d get here)

This is a very well studied subject matter. But we needn’t go far for good insight, Douglas Crockford has a absolutely fantastic talk on code quality that really hammers it home.

“Programmers don’t understand how they spend their time. They think its mostly typing programs. Mostly they are having technical conversations with collegues or in meetings or staring at the screen puzzeling over the code and problems they have to deal with.

Programmers tend to be skeptical of process improvements that might require more keystrokes.

I turns out that programmers really arent spending much time typing their software. But thats where we look for stuff, “I want an IDE with autocomple so I don’t have to type so much, I’ll go so much faster that’ll really improve my productivity.” I think those particular improvement in productivity are negligible. That’s not where the time is being spent. Programming is now a social activity.

The simplest thing we can do to enhance the value of our codebase is to make our programs more readable. Our ability to read our programs is the thing what gives the codebase value.”

Amen to that!

Updates:

On Harmony syntax changes: I had a short twitter conversation with Brendan Eich and he made it clear that although he wants -> function syntax it is not making its way into Harmony.

On feedback: So at this point in the process I thought I’d air out what I had so far by posting on the node.js mailing list. Interestingly enough Jeremy Ashkenas caught wind of this article and posted my rant on Hacker News. From the comments I’ve been getting most people disagree with me, several making good arguments. This was by far the funniest comment on HN by TrevorBurnham “…made me wonder momentarily if the essay was a work of post-modern art, subversively advertising the benefits of CoffeeScript through an implausible flourish of logorrhoea. If so: Well done, sir.” Ouch! Well what can I say it’s a hasty rant that became a big blog post. I don’t claim to be a language designer or a professional tech blogger. Im just one opinionated jerk that is apparently woefully wrongheadded about this subject. Well lets get this over with shall we.

 Second Argument: Overly terse syntax can make code harder to scan and understand.

“What?” You are probably crying out in wild eyed disbelief. “How can it be harder to read if it has fewer characters.” I know what you’re thinking. “It conveys the same data in a cleaner package so we can scan more code, see more of whats going on with less scrolling and fewer eye catching distractions like semicolons and curly braces. Its the epitome of readability!”

Well, some people call curly braces and parens “noise”, but I call them punctuation. I suppose you could consider punctuation marks in a book noise as well. I also think that the word “function” is a better signifier of a function than the more abstract tokens such as -> or #. Is all of this just a matter of subjevtive opinions, individualistic esthetic tastes? I think a large ammount of it is but there has to be something concrete that makes us wince at java or objective-c when compared to JavaScript. I think it is a matter of how easy or hard it is to quickly comprehend the problem and solution embodied in the code. Reading and understanding source code is one of the most important and time consuming activites that programmers perform. So we should optimize for readability.

The basic fact is that we can argue this until we are all blue in the face becasue we have no objective way to grade one language or another. Hence we have what seems to be a resonable if automatic, positive response to reductions in syntax. The assumption is that if one language is easier on the eyes as it strips away boilerplate and verbose syntax then it follows that another must be better as even more things get stripped away. Now, to be clear, I am speaking purely in terms of the visual effect of the language on our ability to comprehend the code as written. There is an unquestioned assumption that less syntax is, esentially, always better, with apparently no point of diminishing returns. This view implies that the visual nature of code is that it gets more readable as it gets more terse. Well, I’d like to question those assumptions. Because they imply the point of code is to take up as littel space as possible but thats bogus. I think the point of code is to enable people to clearly express and understand a range of complex computational processes. Hopefully that computational process is solving an actual problem and so it should help you understand the nature of the problem and the nature of the solution employed. Thats a lot of responsibility and I think the visual/spatial nature of code is essential to fully succeeding at that task.

I think some code will help express the point.

// #6 Filter list of numbers into two categories.
// from http://ricardo.cc/2011/06/02/10-CoffeeScript-One-Liners-to-Impress-Your-Friends.html
passed = []
failed = []
(if score > 60 then passed else failed).push score for score in [49, 58, 76, 82, 88, 90]

// roughly equivalent in js
var passed = [],
    failed = [];
[49, 58, 76, 82, 88, 90].forEach(function(score) {(score > 60 ? passed : failed).push(score)});

// or more verbose js with more visual/spatial structure
var passed = [],
    failed = [],
    score,
    scores = [49, 58, 76, 82, 88, 90],
    cutoff = 60,
    i = scores.length;

while (i--) {
    score = scores[i];
    if (score > cutoff) {
        passed.unshift(score);
    } else {
        failed.unshift(score);
    }
}

Of couse anyone can pick a piece of code to make a point about one language or another. So the above code is purely to express the concept that there can be meaningful spatial information present in code.

This is a murky subject but there is some research in the area. In my short research I did find some interesting papers that address the spatial nature of learning to program[1], code navigation[2], spatial cognition[3], code scanning patterns[4], and An Eye Tracking Study on camelCase and under_score Identifier Styles[5]. There is good evidence to correlate cognitive spatial capability with ability to learn programming.  There are common explanations of how programmers comprehend code. All of the papers refer to various concepts of building mental models that are spatial in nature.

There are also notions of Beacons which are…

“sets of key features that typically indicate the presence of a particular data structure or operation in source code… Meaningful variable and procedure names have been described as Beacons. The swap operation has been shown to be a Beacon and to be beneficial in comprehension as well. ” [4]

I have to concede that this is a purely academic discussion at this point. But it need not be. Language developers should seek methods of validating their theories and motivations as they develop the spec. The studies I cite point to some interesting avenues like gaze-tracking to get deeper insight into the process of reading code and building a mental model of it. This technique is really hot right now and I think it can have some value to language designers.

However much of this scientific approach to things sounds good but the results may be very context specific. It’s clear language design is very much and art and a science.

None-the-less I believe we need to improve our understanding of the visual effect of a language and its syntax on our ability to efficiently build a working, mental model of the program as we read the code. I’m self-trained in programming, my education is in, of all things, fine art and design. The design background serves me well in the world of web design. But part of it beacons to point out that the visual effect of code, indented, with its various syntax hilighted tokens exists every bit as much as a visual entity as a textual one. I think this aspect of code is well worth discussing and researching more. I have a colleague that meticulously picks the colors for his light on dark theme for intelliJ. Its a thing of beauty. I don’t think there is a developer out there that would argue the value of syntax hilighting. The colors obviously help us to see the structure of the code more clearly and thus build that mental model of what we’re dealing with. I argue that so too the effects of syntax and key-words by their very shape, and the visual patterns that emerge in a page of code, plays a similar role. It can help us to build an understanding of the code purely by means of visual cues.

A great way to test this theory for yourself is to spend some time reviewing code samples over at Rosetta Code.

The site exhibits solutions to specific problems in as many languages as possible. This is a fantastic resource to get a feel for the relative visual qualities of various languages. Look at the code as a visual structure, gaze at it and try to see the meaning of the code first with an eye toward the spatial relationships then by reading it intently. As you read it think of that mental model you’re trying to build of how the code works. Is the visual structure of the code doing you any favors or is it adding a layer of complexity to things. If the two reinforce each other I think that is a sign of a better piece of code. It will probably be easier to understand and maintain long after it is initially written. Now remember this is not purely about syntax, its about the visual quality of a piece of colorful, very structured text. Take a look at the csv to html translation problem on rosetta code.

This is a very strait-forward problem with a very simple solution. Go ahead and compare your favorite languages, the JavaScript example was submitted by yours truly :-) Its based it on the CoffeScript example with some modifications. Lets look at two samples.

So what criteria makes one solution more comprehendible, in less time, than another? Obviously familiarity with the language plays a huge role. You can clearly argue that lines of code and clean syntax have a fairly profound impact. But once you get beyond that I think other aspects become important as well. I think the visual/spatial characteristic of the code as it is written can make a meaningful impact our ability to chunk up a program’s logic and constituent parts into a working mental model of the software. Code is written for people not machines. If it were then we’d all be typing out binary or assembly. But as Doug Crockford says “we’re not trying to be E.E. Cummings here.”

Argument 3: JavaScript as a compile target weakens and fragments the community

introducing the asap js loader library

Here it is a very early version of asap on github

The overly creative readme.txt says it all. Reproduced here cus I don’t want to do any more typing.

————————————————————————————————————————————————————————————————-

Here at readme.txt we love finding out just who it is were reporting on, in that vein we sat down with asap.js on the 1st of April 2010 to delve deep into his unique predilection for loading javascript early and fast. Lets cut right the transcript.

RM: So is this a joke or what, it is April 1st?
ASAP: No. I really am a new js loader! I know its stupid right? We already have two great loaders in LABjs and RequireJS I would not be surprised if there are a ton more.

RM: Interesting, both of those js loaders were profiled on the hugely popular Ajaxian.com blog. Is this just a pathetic attempt to get on Ajaxian?
ASAP: YES! Well actually I only learned of LABjs after I was initially written as a little helper for my creator, furthermore I was birthed into a more functional version 0.2 on March 17th one day before the Ajaxian post on RequireJS. You can imagine how deflated I was in both instances… but alas here I am :-) Don’t hate me cus I’m beautiful.

RM: There, there… nobody hates you asap. Tell me more about yourself. What really turns you on?
ASAP: Well you need to include me in your page, in the head or the bottom of the page. I like being at the bottom personally. Then I’ll do all the rest of the work to load all your code and fire off the required init functions when the page and the code are ready.

RM: I’m looking at your source code here and it looks like you’ve implemented a cute little ajax get method, and your domReady event is basically the exact same thing jQuery uses?
ASAP: Well it may sound ironic but I didn’t want to reinvent the wheel. Heh, well it is nice to use my get method to load code in an asynchronous way. I’ll load it via AJAX if I can and build a script tag with it, otherwise I’ll load the js in a slower synchronous manner (setting the src on a dynamic script tag) for compatibility sake. Either way I’ll prevent the js from blocking other page resources from loading. Loading code as soon as possible while maintaining script eval order is what I do!
One last thing, the domReady event can be used but it is recommended that users pass thier callbacks into my codeReady method, that will fire after both domReady AND all the code is eval’d.

RM: Isnt it true that RequireJS can actually load code faster than you?
ASAP: Yes they have a good system but it I think you’re thinking of the feature that requires you to package your code ahead of time so that it doesn’t eval out of order, usually that code will be on your own server and in that case you can just use AJAX to load it anyway. So in that case I don’t think its any faster.

RM: I see you weigh in at a measly 5k when minified.
ASAP: Roughly, yes I’m a few bytes larger than LABjs and a few k smaller than RequireJS, but when I talk k’s I’m only talking AFAIK k’s. OK?

RM: Cool, whats next? Give us a taste of the real asap at work.
ASAP: OK here’s a couple code samples :-)

		//simple array notation syntax...

		asap.require([
			"js/libs/jquery-1.4.2.min.js",
			"js/simple.js"
		]).codeReady(function(){
			simple.init();
		});

		// object notation providing a local root

		asap.require({
			root: "http://www.mysite.com/",
			files: [
				"http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js",
				"js/simple.js"
			]
		}).codeReady(function(){
			simple.init();
		});

RM: Aren’t there problems with debugging code when its loaded with ajax, no line numbers?
ASAP: Good point, that’s why there are three ways you can force asap to use the slower dynamic script attachment method when you want to debug and get nice line numbers in your debug console.

The first two require you to edit the file, you can:
* pass a true boolian into the require call as the second parameter using any syntax or,
* you can add a debug property with a value of true in the object notation form

but my favorite way to jump into debug mode:
* add the param asap=debug to your url

RM: Looks good asap! Now if only Dion and Ben would would give you the time of day you might be forced to create some serious tests.
ASAP: Its true I need some robust tests to verify my code correctness and functionality across all platforms…. there is a reason I’m version 0.3.

End of interview…

Aaaaand that wraps it up for this edition of readme.txt check back again when we review yet another thing we came with.

making of the wax reduction voxelizer part 2: power transmission

Added collars to hold the z-axis lead screws in proper alignment. Used hot glue for now.

I was able to find six of these sweet sprockets for dirt cheap at none-other than AX-MAN. I cant believe how lucky I am to have an AX-MAN just a couple miles down the road from my house.

I was able to get the y-axis linked up with my fancy new, very hard to find, ANSI 25 roller chain. Made a nice chain stabilizer out of the thick strip of plastic from some broken Sony headphones. Lesson learned... Its nice to buy locally but next time Ill just order the roller chain online from smallparts.com and save about 50% after shipping :-(

Complete noob’s guide for budding web developers

So you wanna make websites huh?

Hmm that’s nice but web sites are soo over… its all about web applications these days. Whats the difference you ask? Well one is a program the other is a document. That said, its a great time to become a web developer, the skill set is becoming more valuable and important every day and if you’re a self starter the education is completely free for the taking.  But before you dive in ask yourself why you want to jump into the world of the web as yet one more of its makers, of which there are legion…. is it Fame? Fortune? The perks? Dreams of changing the world? Lets break it down…

Money? Well the money can be great if you’re good and it can be equally pathetic if you don’t find a niche or you’re slow to pick up the material. Like anything I suppose I wouldn’t buy into any advice that says its better or worse than any other profession like lawyer, nurse, architect, sales rep etc. I would also advise staying away if you don’t like staring at a computer all day or think you’ll get rich working from home 4 hrs a day.

Fame? Its available to some degree… lets face it you are most likely not going to become the creator of the next Facebook (and how famous is that guy anyway?) but there are always innovators and productive creators gaining admiration of their peers. That could be you too! That kind of community recognition is fun to strive for and certainly not out of reach.

Perks? What perks? The work can be mentally stimulating if you have a the mind for it, and it provides great opportunity for pretty wide open creativity. On the down side it can be very monotonous, tedious and down right infuriating. If anything you’ll become the go-to person for anyone you know for their web-centric ambitions. This can be a burden… before you start taking on such work you’ll have to learn how to  properly price your services to fend off the people with big ideas and meager budgets, or you could be in for serious frustration.

Changing the world? Well here we finally get to dig in deep don’t we? The web is pervasive, it touches so many lives and its quickly becoming the basis for all modern software. The web has become the playground, testing grounds and proving-grounds of modern user interfaces and complex, networked, multi-user applications. It has been so successful that the world has certainly been and is still under swift change because of it. The web as a platform is fertile ground for innovation… That said many argue that the web has reached its plateau in terms of true innovation and that the rest of the change we see happen on the web will be incremental not transformative. I don’t dispute that, however I would argue that there are plenty of problems that lie in wait to be solved in a more effective and efficient way, the trick is to find the problems that need solving and that has little do with coding web pages.

OK so that’s a pathetic review of a pretty broad concept… “web developer” is a catchall term, it encompass a whole professional sector, but nonetheless it is an intro.  So what am I talking about if not a whole professional sector? Specifically client-side web application development. The stuff that actually gets sent over the inter-tubes, loaded into your web browser and seen and used by the end user. That leads to a bevy of technologies,  many with acronyms…. HTML, PNG, CSS, Flash, AJAX, JavaScript. “Client” refers to the Client in the traditional Client-Server architecture of the web and specifically the web browser software is generally the client we most often deal with. Other clients could for example be widget platforms that use the same technologies as web browsers to create their interface ie. HTML, CSS, JS. Sorry to say however, you won’t get off that easy, to really do the work you’ll most likely need to familiarize yourself with the server end of things which brings in more programming and databases as well.

So now it looks like you’ll basically need to be a jack of all trades, a graphic designer, a copy writer (often overlooked), a programmer, and a database manager. You’ll need to know many different applications, many languages of different flavors, markup, scripting and programming. That, for the most-part, is true but you’ll eventually find out what you’re really good at and specialize in that. There are generally a couple directions to go, I generally think of them as “the design guru”, “the engineer”, and “the coder”.

The design guru is basically a graphic arts nut that would be just as happy designing magazine spreads, drawing comics or designing web sites . This is someone who brings their unique creative flair to the process of designing for the web. That generally means they spend most of thier time producing mock-ups in Photoshop and or Illustrator and turning them into HTML + CSS. The more experienced become proficient with JavaScript or Flash and know enough about the server end of things to modify a WordPress or Drupal template.

The engineer is someone who has pursued Computer Science as a career path, learned Java in school, is well versed in Object Oriented Programming and has focused on developing the “backend” of  web applications, the account management, database queries, serving up the content and processing data submitted from forms. They understand HTML, CSS and JavaScript but tend to look at it with derision as its a loose and messy jumble of technologies as compared to “real” programming. Update: I just read this and honestly that is how it used to be but now with the advent of real applications in the browser the code for things like Google maps and Docs require serious engineering skills. Point is, weather on the client in the form of JavaScript or on the server in the form of some other language, most of the effort is directed at advanced Object Oriented Programming.

The coder is someone who has their feet firmly planted in both the design and programming worlds finding a zen-like balance in every aspect of their work, “I could program this awesome new feature or just fake it with Photoshop and a couple CSS tricks… hmm.” Here the coder would debate the immediate time-savings of an effect vs. the beauty of  a programmatic solution that could be re-used. These are often challenging decisions to the coder because they embrace the yin and the yang.  The coder is skilled with Photoshop but cares little for Illustrator, knows Javascript and PHP front-words and back but avoids the world of Java for the most-part. These preferences stem from the coders need for expedience. They cover so much territory and must economize by learning one server-side language so they learn the most common. They don’t have time to pick up Illustrator and since Photoshop is ideal for creating web graphics and site mock-ups why bother?

So what kind of web developer do you think you will become?

Alright, enough chit-chat! Lets dive in and get prepared to start making this stuff.

Here’s an overview of what you’ll need.

  • A quick preview of what it is that were talking about
  • The confidence and ability to learn on your own
  • A firm grasp of the core concepts and all the software it implies
  • A collection of top notch resources
  • A good code editor
  • Photoshop
  • Familiarity with industry best practices
  • Knowledge of the pitfalls so you don’t fall into them

I will provide some details for each of the above as a starting point with a mind toward the coders middle way approach, throwing all aspects of the process from back-end to front-end, from code to design, all roughly at the same time. Insane you say? No, this is just the reality of it, you will always need to grow your skills incrementally all at once. If you don’t learn how to do that now you’ll have a much harder time in the future learning whatever new combination of technologies it will take to get your job done 5, 10, 15 years from now. Learning many integrated technologies all at once is in itself a key skill for the web developer and is exemplified by the coder’s middle way. May the force be with you young padawan learner.

First a quick preview

Before we get into more conceptual bits lets take a quick look at the actual subject matter in light-form, so we are all on the same page. Lets say we have some text and a few pictures we want to turn into a basic web page.

This is the text:

A view from above

Atlantis astronauts carried out five back-to-back spacewalks to fix and upgrade the 19-year-old Hubble Space Telescope, adding five to 10 years to Hubble’s the observatory’s lifetime. Scientists hope to begin beaming back the results by early September.

Here are the pictures:



Lets see what the html looks like.

<html>
	<head>
		<title>A view from above</title>
	</head>
	<body>
		<h1>A view from above</h1>
		<p>Atlantis astronauts carried out five back-to-back spacewalks to fix and upgrade the 19-year-old Hubble Space Telescope, adding five to 10 years to Hubble's the observatory's lifetime. Scientists hope to begin beaming back the results by early September. <a href="http://www.komonews.com/news/photos/45855337.html">Full article</a></p>
		<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_1-150x150.jpg" />
		<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_2-150x150.jpg" />
		<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_4-150x150.jpg" />
		<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_5-150x150.jpg" />
		<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_7-150x150.jpg" />
		<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_20-150x150.jpg" />
	</body>
</html>

now load up the page to see how it renders.

OK now lets style it up a bit with some simple CSS.

/* remove browser default padding */
html, body, h1, p, img {
	padding: 0;
	margin: 0;
}

/* use a reversed color style with arial fonts */
body {
	background: #000;
	padding: 24px;
	font-family: arial, sans-serif;
	color: #ddd;
}

h1 {
	font-size: 24px;
	font-weight: bold;
	color: #fff;
	margin-bottom: 1em;
}

/* put the text in a box */
p {
	border: solid 1px #555;
	background: #333;
	padding: 1.5em;
	margin-bottom: 1.5em;
}

img {
	padding: 0;
	margin-right: 1.5em;
	margin-bottom: 1.5em;
	border: solid 1px #333;
}

The CSS can be written right into the page using a style tag but in this case I’ll save it as a separate file and add in a link to it by adding the following line to the head section of the HTML.


<link type="text/css" rel="stylesheet" href="simplepage2.css">

Take a look at the new page to see the CSS do its thing.

Lets make this page more interactive by adding in links to the high resolution versions. Ill do this by wrapping the images in “a” or anchor tags. These are the things we commonly call links. For this example we have to style the image links differently than the text links. To facilitate this we wrap the group of images in a div with an id, then in the CSS we can key off that id to style just those links.

<html>
	<head>
		<title>this is the title</title>
		<link type="text/css" rel="stylesheet" href="simplepage3.css">

	</head>
	<body>
		<h1>A view from above</h1>
		<p>Atlantis astronauts carried out five back-to-back spacewalks to fix and upgrade the 19-year-old Hubble Space Telescope, adding five to 10 years to Hubble's the observatory's lifetime. Scientists hope to begin beaming back the results by early September. <a href="http://www.komonews.com/news/photos/45855337.html">Full article.</a></p>

		<div id="imageLinks">
			<a href="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_1.jpg" target="_blank">
				<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_1-150x150.jpg" />
			</a>

			<a href="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_2.jpg" target="_blank">
				<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_2-150x150.jpg" />
			</a>

			<a href="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_4.jpg" target="_blank">
				<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_4-150x150.jpg" />
			</a>

			<a href="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_5.jpg" target="_blank">
				<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_5-150x150.jpg" />
			</a>

			<a href="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_7.jpg" target="_blank">
				<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_7-150x150.jpg" />
			</a>

			<a href="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_20.jpg" target="_blank">
				<img src="http://www.andrewluetgers.com/wp-content/uploads/2010/02/090522_shuttle_large_20-150x150.jpg" />
			</a>
		</div>

	</body>
</html>

The css gets modified slightly the following code replaces the existing rule for img.

/*================= rules for the imageLinks section ==================*/
/*
 now that we have the images wraped in a div with the "imageLinks" id
 we can easily style just the elements within.
*/

#imageLinks a {
	/*
	 "a" is an "inline" element (treated like text) by default and images
	 are "block" element so for proper rendering of images as links we tell
	 the a to be like an image, not text, this also solves some rendering
	 oddities but we also have to float the images left so they line up
	 like before rather than stack on top of each other in a single column.
	*/
	display: block;
	float: left;

	/*
	 moved the margin here to the a instead of the img becasue the margins on
	 the img became clickable which was odd.
	*/
	margin-right: 1.5em;
	margin-bottom: 1.5em;
}

#imageLinks img {
	border: solid 1px #333;
}

Version three with links to high-res images.

This is a very simple web page but now you have an idea of what we’re dealing with.

The confidence and ability to learn on your own

Remember I said that the education was free… well that all depends on what type of learner you are and how good you are a finding the right materials. Trust me its out there and I’ll point you in the right directions but you’ll eventually have to be careful to avoid outdated or altogether bad advice. Buyer beware. Furthermore If you can’t thrive in this type of learning environment… by the seat of your pants, grab it off the web and try it right now… then I would question your interest in web development. The field changes so fast you have to learn new things this way, every day. Its key.

A firm grasp of the concepts and software, Ok here we go…

Think of the stack of technologies it takes to get a situation where a user can log into a site like Facebook. That stack begins with servers usually in a data-center managed remotely by Information Tech dudes. Those servers run some key software you’ll need to be familiar with, namely the Linux operating system running Apache HTTP server, MySQL server and PHP. This is the most common server configuration and it is often called the LAMP stack. Thankfully you can get the stack setup on your own computer for development and learning purposes with ease. On the mac go get MAMP in Windows go get XAMP. Note that I will not tell you how to set up software and configure it. RTFM. Look it up.

Get that installed and working and you have the server stuff done for now :-)

Next think about what you actually are looking at in a web browser, pictures, text, links, a page that has some sort of layout and design to it. It all gets sent over the internet as text files and image files. That’s it! human readable text files and pictures. Well I’m leaving out things like flash which is more complicated but for now that’s all you care about, readable text documents and pictures. The web is wide open for all to see that’s why its been so successful and that why its awesome. You could get by with notepad and a free image editor… you’d be better off with other software but it would suffice.

Right about now you’re thinking wow this is really simple… well hang on.

So the web browsers like Internet Explorer, Firefox or Safari for instance all follow the specs (more or less) of the W3C which specifies how all this stuff works namely HTML, CSS, and JavaScript is specd out by ECMA. By the way don’t follow those links and expect to learn much, the W3C docs, just like any spec, are painful to read. So when a user clicks a link to a website from Google the server serves up just the HTML document, the browser reads that document and goes through an amazing series of file requests and contortions until plain text and some images turn into, Facebook, Flickr, Google Maps, CNN etc.

How all that happens is what books are written about, it takes many years to understand all the intricacies of it all but I believe I can explain the concepts concisely… lets see. Imagine four parts of a web site, the textual information or content, the pictures, the arrangement and design of the text and pictures and the interactive behavior of the site. The text/content is the HTML, think of that as the page. When you select “view -> Page Source” in Firefox what you see is the HTML source code. The page requests resources it needs and the browser goes and gets those individual documents to help produce the final product. It will load images, and something called a Cascading Style Sheet. The CSS file defines how the page should look, it also can cause other images to get loaded. Finally external files that contain programmatic code, JavaScript, that defines interactive behavior of the page is loaded. Once loaded in the browser the JavaScript code is executed and it has access to everything, it can change the document by adjusting the style, changing content, adding in new content from other servers and much more. All of this happens within a couple seconds.

How does the HTML define such complex pages as are on the web, how does the CSS style the page, how does the JavaScript produce applications like Google maps…  Its all about the browser and the thing it turns all these files into, the DOM or Document Object Model. At this point you should Install Firefox and the Firebug plugin. Familiarize yourself with Firebug and the DOM, use the Firebug debugger to browse the HTML CSS and JS, then look at it the way the browser looks at it, browse the DOM structure of the site in the DOM tab. Take a look at document -> childNodes -> 1 -> childNodes ->2 etc. Keep following childNodes deeper and deeper in. You’ll see it reflects the structure of the HTML. In the programmatic world of JavaScript everything you see in the DOM tab of Firebug  is available for use. Because the browser turns the text files into these objects, code can be written to modify the page and the attributes of its content. To get a really good handle on it take a look at the “Theory of the Dom” videos by Douglas Crockford over at the YUI Theater.

That’s basically it for core concepts… what I have not covered are the bulk of what you will be learning and that is Object Oriented Programming (OOP), syntax and APIs. Object Oriented Programming is not so complex as you may think, especially since we’re dealing with JavaScript in the browser which is much simpler than say C++ or even Java on the server. Syntax is the rules for how to write a functional HTML, CSS or JavaScript document. Put a comma or an angle bracket or a quote in the wrong place and the page breaks, that’s Syntax. API stands for Application Programming Interface, this is arguably the most common day to day knowledge a coder can have and is often not fully retained but understood through documentation and convention. Everything has an API they are essentially the features available for use. The DOM provides a vast API for programming in JavaScript. Its important to make the distinction between the API and the language. JavaScript is the language, “document.childNodes” is part of the JavaScript DOM API exposed to the JavaScript code thanks to the browsers implementation of the W3C Spec that defines the DOM.

So how about we see some of this JavaScript I keep talking about? Getting back to our example code lets make the page more dynamic using JavaScript. How about loading the the high-res image into the page rather than redirecting the browser to the file. First we’ll modify how the links work by causing the browser to run our code and prevent the default link behavior. That new code will need to create a new image tag using href from the clicked link as the src arrtibute of the new image. We then put that new image into the page. The JavaScript is similar to the CSS in that you can put the code right into the html itself but again I will save it out to a separate file and load it in by adding the following line just before the closing body tag.

<script language="javascript" type="text/javascript" src="simplepage4.js"></script>

First I’ll show you just the code without comments or log messages. Then we’ll go through the actual file that gets run in the browser, it has lots of comments and several logging messages for firebug. If you don’t follow it completely that’s alright this is just a preview but the comments should explain things pretty well.


var imageLinksLoader = {

	init: function(imageLinksDivID) {
		var imageLinksDiv = document.getElementById(imageLinksDivID);
		imageLinksDiv.onclick = function(event) {
			event = event || window.event;
			var target = event.target || event.srcElement;

			if(target.tagName == "IMG") {
				imageLinksLoader.loadLargeImage(target.parentNode.href, imageLinksDivID);
			}

			return false;
		};
	},

	loadLargeImage: function(url, id) {
		var myImg = document.getElementById("largeImage");

		if(!myImg) {
			myImg = document.createElement("img");
			myImg.id = "largeImage";
			myImg.src = url;
			document.getElementById(id).appendChild(myImg);
		} else {
			myImg.src = url;
		}
	}
};

imageLinksLoader.init("imageLinks");

Alright now lets go through it, below I’ve added in comments and logging messages for firebug so you can see how the code runs in the browser.

/*
 I'll be placing several log messages throughout this code so that you can see how things happen by
 looking at the firebug console. If a user does not have firebug installed calling the console.log
 command will cause an error to prevent that from happening we will check to see if console exists,
 if not we will make a fake log function that does nothing.
*/
if(!window.console) {
	window.console = {
		log: function() {
			return false;
		}
	};
}

console.log("the javascript is being initially evaluated (run) by the browser");

/*
 grouping chunks of code:
 lets creat our "namespace", thats a fancy name for saying the container for our code.
 This is not a requirement of the language just a good thing to do.
*/

var imageLinksLoader = {

	/*
	 init is the first bit of code we will run, it is a function that will make the links
	 (when clicked) run our code and will also prevent their default behavior.
	*/

	init: function(imageLinksDivID) {

		console.log('imageLinksLoader.init was called with the parameter "' + imageLinksDivID + '" passed in');

		// grab the item with the provided id, save it in a temporary variable
		var imageLinksDiv = document.getElementById(imageLinksDivID);

		/*
		 a note about assumptions:
		 our code will assume that there are only links that link to other images inside that div.
		 This is an important assumption and right now its obvious but at some point months later
		 you will be editing your html and forget, so document it. Its very important to document
		 your code. Its best to write code that is insulated from such assumptions but you can
		 never totally avoid them.
		*/

		/*
		 adding the event handler:
		 using a nice trick called event delegation we will attatch an event listener to the
		 div it will listen for click events that happen inside it, the oldschool way to do
		 this would be to attatch an event handler to each link, boo too mucch work.
		*/

		// the browser passes an event object as the first parameter we will call it "event"
		imageLinksDiv.onclick = function(event) {

			// with event delegation you can get at the thing that was clicked through event.target
			// that is true except for in Internet Explorer so first we jump thourgh a couple hoops

			// IE doesn't pass in the event object
			event = event || window.event;

			//IE uses srcElement as the target
			var target = event.target || event.srcElement;

			console.log("saw a click on " + target.tagName);

			/*
			 if we clicked an image grab the href from its parent link then call our loadLargeImage
			 function passing it the value of the href which should be the lare image url and the id
			 of the div we want to put it in
			*/
			if(target.tagName == "IMG") {
				console.log("imageLinksDiv.onclick fired");
				imageLinksLoader.loadLargeImage(target.parentNode.href, imageLinksDivID);
			}

			return false; // this line prevents the browser default click behavior
		};
	},

	/*
	 pass in the url of an image and the id of a div and it will get appended to that div
	*/
	loadLargeImage: function(url, id) {
		console.log("load large image from " + url + " into the div " + id);

		// if we already have an image loaded that is the image to use if not create a new image object
		var myImg = document.getElementById("largeImage"); // returns false if we have not loaded a large image yet

		if(!myImg) {
			// looks like no large image added yet creat it and add it to the DOM
			console.log("creating new image object");
			myImg = document.createElement("img");
			myImg.id = "largeImage";

			// set the src of the image object... it will begin loading immediately
			myImg.src = url;

			// and append it to the div
			document.getElementById(id).appendChild(myImg);
		} else {
			console.log("loading a different large image");
			// looks like image was already created so just update its src
			myImg.src = url;
		}
	}
};

// little will happen until we call our init function and tell it what div to work with by passing in the id
console.log("calling the imageLinksLoader.init function to kick everything off");
imageLinksLoader.init("imageLinks");

Actually pretty simple but it encapsulates many principals that are fairly advanced. But enough talk go try it out and don’t forget to turn on firebug and pull up the console tab to see the logs.

Now that I have you thoroughly scared

Let me assure you this is insanely easy to get started with. You’re editing text files not calculating rocket trajectories. Remember the HTML and CSS examples, its pretty damn simple stuff. When it comes to syntax this is going to become obvious because you’ll be working from example and will quickly pick up how to write HTML, CSS and JS simply by looking at a few examples. Then once you get the syntactical pattern you have to know what you have available in your toolkit, the API. Great news on that front as well, it is all very clearly laid out in simple descriptions all over the web called “API Documentation” and I’ll provide several such resources. Finally when you use a proper code editor it holds your hand the entire time, helping you learn by telling you the instant your syntax gets messed up or showing you all the appropriate API features you could use at any given point. It is almost too easy to dive into web development. Lets not forget there have been so may that had to learn all this without the benefit of the now accumulated wisdom of the professional community, the amazingly helpful tools like Firebug and the Safari Inspector, real coding tools or the amazing panoply of educational resources or understanding of the bugs or the help of libraries like jQuery that simplify the JavaScript to an unbelievable level. You benefit from millions of man hours of hair pulling and painful development and documentation. Basically you’re standing on the shoulders of giants.

Develop a collection of top-notch resources

I’ll get you started but you should always be on the lookout for new sources of examples, tutorials, best practices, industry trends, reference material, inspiration and good ideas with a strong eye towards exceptional quality vs quantity. Finally there are tons of advanced tutorials and examples of new “better” ways to do this or that, you’re just starting out, stick to the basics to begin with and when you have a firm grasp on them then slowly branch out to try something more complex and interesting.

The Basics

  • w3schools.com – “Because time is valuable, we deliver quick and easy learning. At W3Schools, you can study everything you need to learn, in an accessible and handy format.”
  • developer.mozilla.org/en/Web_Development – When it comes to reference material you can’t do any better than Mozilla’s Developer center. Got a question about a specific feature of html, css or javascript? Just Google it followed by MDC for quick access to Mozilla’s documentation. eg. “javascript array mdc”, “css background mdc”
  • csszengarden.com – The  one and only, classic, learn by example, temple of “separation of content and design”. From the site: “There is clearly a need for CSS to be taken seriously by graphic artists. The Zen Garden aims to excite, inspire, and encourage participation. To begin, view some of the existing designs in the list. Clicking on any one will load the style sheet into this very page. The code remains the same, the only thing that has changed is the external .css file. Yes, really.”

JavaScript:

PHP:

Photoshop:

Becoming a Master:

  • alistapart.com – “A List Apart explores the design, development, and meaning of web content, with a special focus on web standards and best practices.”
  • boagworld.com – “Boagworld is the web design blog of Paul (the Wurzel) Boag who lives in the heart of rural Dorset. He produces a weekly podcast with Marcus (pop star) Lillington on all things relating to building and running websites. They also run web design agency- Headscape.”
  • net.tutsplus.com – A great collection of tutorials, screencasts and articles covering a wide range of web development topics.
  • smashingmagazine.com – Graphics, Inspiration, Coding, Design, Photoshop, WordPress, Tutorials, Wallpapers, Icons, CSS.
  • css-tricks.com – Another excellent web design community, a great resource for, tutorials, screen-casts and code samples.
  • ajaxian.com – keep up with the latest and greatest in web application development

The above represents a minuscule cross section of the best resources available yet alone they open up a huge world. Keep looking and learning every day. It’s a good idea to set up a feed reader like Google Reader to more efficiently scan through all your resources every day.

Your IDE is your best friend

IDE stands for Integrated Development Environment. Why waste time learning an IDE that is not going to grow with you… Go ahead and dive into the real thing right away. Go get Aptana Studio which is based on the amazing Ecliplse IDE. Like it says, its “the leading IDE for web development” and its FREE! Once you have it installed get to know your new home, kick the tires, wade through all the preferences and menus. Then go watch some of the training videos (avoid the ones about plugins.) Some day someone will tell you to switch to a different IDE for x, y and z reasons. This is fine but start out here with a real IDE and when that time comes around you’ll have a better idea of what features you care about.

Intro to Aptana Studio from Aptana, Inc. on Vimeo.

Photoshop, just get it already…

One of the tools that you absolutely can not skimp on is Photoshop. Now there are proponents of GIMP and other free software, a search for “Photoshop alternative” will expose many such would-be replacements of this essential tool. But they don’t come close, not by a million miles. That applies especially to anything with Photoshop in its name that is not Photoshop CS or later, that means no Photoshop Elements, no Photoshop.com. By hook or by crook you gotta get the real thing. Some people are content to scour the web for hacked downloads through bittorrent. I’m sure you could find it but I’m sure you’ll probably contract a virus in the process… I suggest AVG for that (virus protection) but better yet get your hands on the real thing, yup just pony up, then there is no concern about viruses or breaking the law.