Selenium. Open source web application automated testing. This is going to be big.

http://w3future.com/html/beyondJS/

Curried functions, Number.times(), Array.foreach(), Template methods and a whole bunch of other STL/Smalltalk/Haskell craziness. In javascript. Mmm, javascript….

I think Amazon said it best (http://www.amazon.com/gp/aws/sdk/main.html?p=APIReference/RESTRequestsArticle):

REST allows you to make calls to AWS by passing parameter keys and values in a URL (Uniform Resource Locator). AWS returns its response in XML (Extensible Markup Language) format. You can experiment with AWS requests and responses using nothing more than a Web browser that is capable of displaying XML documents. Simply enter the REST URL into the browser’s address bar, and the browser displays the raw XML response.

Can you test your SOAP service with nothing more than a web browser?

Meerkat RSS feed – the javascript flavour is very cool.
http://www.oreillynet.com/pub/a/rss/2000/05/09/meerkat_api.html

Awesome use of javascript bookmarklets to search for books from amazon in your local library.

http://weblog.infoworld.com/udell/stories/2002/12/11/librarylookup.html

Its not a DecelerationHelper its a Brake.

Credit to Dan North and Mike Roberts for the conversation about how to rename Helper/Manager type classes to something more concrete. What ability or thing would the application lose if the Helper was deleted?

Cowboyd. Future Famous Author:

“So you’re going to give this jacket to me.”

“Yes yes. I gift. To you.”

“What do you want?” I said.

“Want? I want to give you a litle gift.”

“What do you want?” I repeated.

He did not respond at once, instead readying his proposal since it was obvious that was all I was waiting for. Then he said slowly “I give you a little geeft, you give me a little geeft.”

Finally. Christ it took this guy long enough to admit that it was at least some sort of transaction he was proposing. In retrospect I wonder if he was covering his ass in case I turned out to be part of the ultra-elite squad of undercover cops that hangs around in parking lots –Hatchling to nest. Hatchling to nest. Operation “check email and then fart around in the parking lot” was a raging success.

So, I used to think that javascript was evil and bad, and made for brittle websites that only worked in one browser. That danger is still present, but its not really the fault of javascript. Sticking to the ECMA and W3C DOM standards should avoid most of the pitfalls.

I’m more interested in Javascript as a language. Its a prototype-based OO language. Prototype based languages don’t have the concept of classes per se, you define types by instantiating objects and then attaching function definitions. Once your prototype object has all the behaviour you want, you can use it as a template to instantiate other objects of the same type. Functions can be defined either as global, or bolted to an object as methods. Functions can also be directly referenced as variables. Function parameters can either be named explicitly, or referenced by indexing into the arguments array. So although a function may state that it takes 2 arguments by saying ‘function foo(bar, baz)’, there’s nothing to stop you calling it with 20 arguments.

What is also very cool is that you can make HTTP requests directly in javascript, and refresh parts of the page independently. This makes it possible to build very interactive portal applications that can update the screen asynchronously without an obvious browser refresh.

The netWindows open source project has a bunch of very useful stuff, including a standalone signals & slots implementation for javascript, which is very handy for building event-driven pages.

Avi Bryant has graciously published some javascript that can selectively replace chunks of HTML based on an asynchronous server call.

The Oddpost guys even built a full fledged 3-pane email application (with drag and drop) inside a web browser. Shame they’re no longer taking subscriptions. I want one!

On pretty much every project, the subject of whether its feasible to perform unit testing (and indeed, TDD) at or near the user interface comes up. Over the last couple of projects the design that I find easiest to work has looked something like this:

public class SimpleView : ISimpleView {

private TextBox txtFirstname;
private Label message;
private Button okButton;

public string Firstname {
get { return txtFirstname.Text; }
set { txtFirstname.Text = value; }
}
public string Message {
set { message.Text = value; }
}

private void okButton_Clicked(object sender, EventArgs e)
{
controller.OkClicked();
}
}

public interface ISimpleView {
string Firstname { get; set; }
string Message { set; }
}

public class SimpleController {
private ISimpleView view;
public SimpleController(ISimpleView view) {
this.view = view;
}
public void OkClicked() {
string greeting = "Hello, " + view.Firstname + "!";
view.Message = greeting;
}
}

The general pattern is that any operation that requires the system to take action should be a method call to the controller, and that all the values from the view should be exposed on the interface. Widgets should not leak from the view into the controller. This approach allows for testing with NMock or JMock, as well as keeping the view classes so thin and logic-free that it is a simple task to peel off and replace with an alternative implementation (swapping thick client for web front end for example), or a test harness.

Don’t you hate in when people use their own blogs to remember links?

NMock Tutorial

Been thinking a lot about OO just recently, as you do. A lot of the practices I use get questioned when I demonstrate them, exactly as I would have done had the situation been reversed. Many of the questions are of the form ‘Isn’t this OO for OO’s sake?’, or ‘That seems like a lot of work, couldn’t we just use a Getter?’. What’s interesting is that the question of whether something is a lot of work depends very much on your perspective. I’m fairly lazy (aka. ‘pragmatic’) so I seek to find neat ways of reducing effort, but my perspective is usually a fairly wide one, so I’m usually thinking about ways of reducing effort over the life of a project and not just the code I’m typing at 2.30 on a tuesday. Its often the start of an interesting discussion when stuff I’m doing to reduce effort is queried as too much work. It is also be a hard thing to explain, when it does take demonstrably longer to write some code that doesn’t break encapsulation, as opposed to just adding a Getter. I’ve seen what happens to a system when all the objects in it have had their boundaries eroded by the addition of getters, and I remember wishing that there was another way to do it, which ultimately led me to considering the following approach, which I’ve worded as a ‘challenge’:

• Can you take any class in your system and instantiate it easily in a test harness? -Credit to Michael Feathers for this one.
• Can you write a system where none of the classes have Getters (or public properties in .net)?
• Do all your objects have only one constructor?
• Can you write a system where none of your objects take primitives (including string) as parameters to their public methods?
• Where a class accepts multiple parameters in its constructor, can you write it in such a way that none of them are primitives (or strings)?
• Can you do the above using TDD?

I’m not saying I do all this all the time, but it is a goal I try to keep in mind when developing. As an approach it leads to many more fine grained classes with names like ‘FirstName’, ‘Age’ etc that might otherwise have been represented with strings and ints, but it is a fascinating way to develop, and leads to some very interesting code. For example, lets say I want to take an object and render it out as HTML. Usually I immediately think of adding getters for all the fields that needed to be written. If you’re avoiding getters, then you end up with something more like ‘public void WriteTo(IRenderer)’. Which is also really easy to write a test case for, either with a mock object, or by having the test case implement the interface itself.