MVC for the client side web is very simple
Model:
<body>
<h2>Food List</h2>
<div id="food">Apple</div>
<input type="text" id="foodToAdd" /><button id="AddFood" text="add"/>
</body>
View:
body { background-color:#000;font-family:serif;color:#ff00ff; font-size:1em }
#food { border: 1 solid black; }
Controller:
<script>
$(function() { $("#AddFood").click(onAddFoodClicked);
});
function onAddFoodClicked(ev) {
var currentlist = $("#food").text();
var foodToAdd = $("#foodToAdd").val();
$("#food").text(currentlist + "," + foodToAdd);
$("#foodToAdd").val("");
}
</script>
See?
Must reads for new programmers
Iris Classon has a nice post up listing her top ten books to read this year.
The Little Schemer - It's not about the Scheme language at all, it's about teaching recursive thinking. Once you "get it", it changes the way you think about programming.
Code by Charles Petzold - Explains how computers work by starting with Boolean arithmetic and working towards RAM and video cards. Short read, but essential in today's throw-away culture.
Don't Make Me Think - I've bought this book 3 times, every time someone borrows it they keep it. Essential if you are doing ANY kind of UI or UX work.
Test-Driven Development: By Example - Nice and practical. Resolves a lot of the questions that surround TDD like "How much should I test?" and "What should I test?". Shows how TDD is less about the tests and more about the design of your code.
Writing Secure Code (2nd Edition) - You won't work for me or with me if you don't own this unless there is a threat involved.
Clean Code - Robert Martin - An excellent book for learning to recognize bad software.
Working Effectively with Legacy Code - Michael Feathers - Useful refactoring techniques combined with useful testing patterns. As a programmer, new or veteran, most of your time will be spent working on code you didn't write.
Software Craftsmanship is a misnomer
"Software Craftsmanship" is a misnomer in that craftsmen(people? PC much?) craft items that are meant to last while software is meant to become obsolete.
Discuss among yourselves, be civil. 
First try with TypeScript
Microsoft released TypeScript (TS). This is another language that is a super-set of JavaScript and compiles to POJ (Plain Old JavaScript). It includes several features proposed in ES6 "Harmony" including optional typing and class/module support. It also includes support for interfaces.
Here is their "Hello World" example.
//POJ
function greeter(person) {
return "Hello, " + person;
}
var user = "Jane User";
document.body.innerHTML = greeter(user);
//TypeScript
function greeter(person: string) {
return "Hello, " + person;
}
var user = "Jane User";
document.body.innerHTML = greeter(user);
The idea is that TS can compile POJ as well as TS code. I decided to give the new language a spin by converting my Bootstrap.js project over to TS. Bootstrap uses a lot of common JS idioms, but it also is missing a few features like AMD support and support for new HTML5 attributes. Plus it does have to do some type checking of optional arguments. So my hope was that TS would allow me to easily add those features and remove some of the need for type checking.
The first thing I wanted to do was created the global var that would hold my bootstrap function. It includes some private variables that are closed over and parses some optional arguments. This isn't the entire code, but it's the part I wanted to convert first since all of the other code should port over pretty easily.
var bootstrap = (function() {
var itemsLoaded = []; //maintain a list of items we have already loaded to prevent duplicates
var bootstrap = function() {
var args = arguments;
if(args.length == 0) return;
var scriptSrc = "";
//figure out if we were passed a script URL, a config object, or an array of script URLs
var src = args[0];
if(typeof src === "string") {
scriptSrc =src;
} else if(typeof src == "object" || typeof src == "array") {
processConfigObject(src);
}
var head = document.head || document.getElementsByTagName("head")[0];
var scriptId = args[1] || "script" + Math.floor(Math.random() * 1234);
var loaded = false;
var scriptTag = null;
var callback = callback = args[2] || null;
//... lots of code here
return (window.bootstrap = window.$b = bootstrap);
}())
My first attempt looked like this:
That produced this JS code when I compiled:
That code is pretty funky. First of all, the variables which were previously closed over and private are now just in the function with the scope implied since they are function parameters.
Ok, I'm not sure exactly what I'm doing. I'm coding in one window with the TS language spec open in another window. Hardly ideal, but TS is supposed to target two kinds of developers. 1) Those that know C# but aren't familiar with JavaScript 2) Those that know JavaScript but want some type safety and easy to create structure. I'm both! (well, I don't really care too much about type checking at compile time but it would be nice if the compiler could build some of it in at runtime for me).
The first thing you notice is that all of the type checking is done at compile time. That's what we all want right? No, sometimes we also need to check types at run-time because we want to either know what variables really are as opposed to what we think they contain or because we want to do different things based on whether or not a variable contains a certain type. Consider the following code in Bootstrap, which is pretty idiomatic JavaScript code I think. It's a common pattern used to allow a variable number of option parameters to be passed to a function.
var bootstrap = function() {
var args = arguments;
if(args.length == 0) return;
var scriptSrc = "";
//figure out if we were passed a script URL, a config object, or an array of script URLs
var src = args[0];
if(typeof src === "string") {
scriptSrc =src;
} else if(typeof src == "object" || typeof src == "array") {
processConfigObject(src);
}
var head = document.head || document.getElementsByTagName("head")[0];
var scriptId = args[1] || "script" + Math.floor(Math.random() * 1234);
var loaded = false;
var scriptTag = null;
var callback = callback = args[2] || null;
First, I check to make sure that at least SOME arguments were passed to the function. Then I check to see if the first argument passed is a string. If it is, the rest of the program uses that string as the source of the JavaScript file to be loaded dynamically. But, if it's an array or an object, I assume it is a configuration object. I use optional configuration objects in BootStrap to allow users to specify multiple JavaScript files to be loaded with a single call. Then I check to see if an id to use for the script tag to be inserted was passed, if not I assign a random number as the id. Lastly, I check to see if a callback was passed. I don't check to see if the callback is a function or not because I'm allowing the user to shoot their self in the foot if they want.
Note, that in TypeScript, even though the class constructor parameters are annotated with types and some are marked as optional, there is no type checking at all and I still have to manually assign the optional value using the short-circuit feature of the || operator
So that means that the only way you can get the benefit of type checking in TypeScript is to write ALL of you code in TypeScript. This means that integrating TypeScript with legacy JavaScript applications is pretty worthless.
One other annoying thing is the need to declare transient variables for stuff that isn't available until runtime. This is supposed to ensure that you call built in DOM methods or methods on other JS objects correctly. What it means is you end up with lots of compiler warnings telling you that "head" is not a property or method of "document".
Which brings me to the final annoying thing: the compiler itself.
First it processes the script file from the top down. As soon as it finds an error, it stops processing and reports the error. It does not try to parse the entire script file and report all of the errors to you. So that means you get to play whack-a-mole with the compiler. It finds an error, reports it to you, you fix it, then it finds the NEXT error. Rinse and repeat. Also, there is no distinction between compiler errors and compiler warnings. You just have to check the size of the output file. If it's 0, that was an error.
I don't see myself using TypeScript in it's current form. I know JavaScript well enough and the supposed benefits of TypeScript aren't really a benefit to someone who knows JavaScript. Looking at it from the perspective of a C# developer who doesn't really know JavaScript, it's not really C-Sharp-ey enough to help out someone who doesn't know JavaScript very well and, in the case of private and optional variables and parameters, it can actually confuse them.
One final note. The way that TypeScript was developed and released was very disappointing. They worked on it in secret without getting the JavaScript community as a whole involved from the start. Then just dumped it on us as if to say, "BEHOLD! We have solved all your problems!". Typical old school Microsoft. It's great that the spec is now open and the source has been released under an Apache license though. But really, TypeScript doesn't address any of the real problems that JavaScript has. Type checking isn't a problem in JavaScript, Type COERCION is a problem is JavaScript. Numbers are still floats in JavaScript. The DOM is still a mess without jQuery or another library. Scope is still confusing and must be managed carefully. All the TypeScript team had to do is open a copy of "JavaScript: The Good Parts", turn to the section titled "The Bad Parts" and think, "Ok, how can we fix these?"
P.S. I never did figure out how to replicate this line in TypeScript.
return (window.bootstrap = window.$b = bootstrap);
Linus Torvalds on Git
Taken from "Linus Torvalds goes off on Linux and Git" and presented without comment.
Git has taken over where Linux left off separating the geeks into know-nothings and know-it-alls. I didn’t really expect anyone to use it because it’s so hard to use, but that turns out to be its big appeal. No technology can ever be too arcane or complicated for the black t-shirt crowd.
...You’ll spend a lot of time trying to get your head around it, and being ridiculed by the experts on github and elsewhere. I’ve learned that no toolchain can be too complicated because the drive for prestige and job security is too strong. Eventually you’ll discover the Easter egg in Git: all meaningful operations can be expressed in terms of the rebase command. Once you figure that out it all makes sense. I thought the joke would be obvious: rebase, freebase, as in what was Linus smoking? But programmers are an earnest and humorless crowd and the gag was largely lost on them.
Edit: The originating post is marked as 'satire'. I missed this at first, but after I read it in that context it was obvious. Still, some of the points in the quote ring true to me even if Linus didn't say them.
Is it really all broken, or is just just broken in a different way?
Everything is Broken and Nobody's Upset
If things are this broken for people who live and breath all this stuff, imagine how broken it is for the average Joe who doesn't have the skill or confidence to understand why software sucks.
The average Joe/Jane doesn't run into this stuff because the average Joe/Jane doesn't have quite the volume of email that Scott does. Nor do they have the enormous social graph that Scott does.
I'm not going to whitewash his entire point by saying he's an edge case, because some of the problems he points out aren't a problem of scale. Some of them, like Chrome 19 and VS, I can't reproduce. Which means nothing and is the exact reason Google and Microsoft will give him for not fixing the problem.
The question for Scott and others is: Has software gotten WORSE? Or does software just suck in different ways?
Ad
.NET HTTP Abstractions group
|
| Subscribe to .NET HTTP Abstractions |
| Visit this group |
Tags
O’Reilly Blogger Review Program
Books I’ve worked on
Contributors
Links
Herding Code Podcast
- Herding Code 166: Tomasz Janczuk on Edge.js 5/16/2013
- Herding Code 165: Mark Seemann on AutoFixture and Unit Testing 4/30/2013
- Herding Code 164: OWIN and Katana with Louis DeJardin 4/22/2013
- Herding Code 163: Sticker Tales and Building Windows Store apps with Damien Guard and Robert Sweeney 4/10/2013
- Herding Code 162: Whacha doin, Goodbye Google Reader, scriptcs and Lightning Round! 3/25/2013