Links for 16-Mar

Which is more beautiful -- OO or FP?

Effective Powershell (free e-book).

PowerShell -- enabling "dir -a:d" in V2.

An alternative to the where T : new() constraint (updated with lambdas).

Managed code and the worst exceptions.

StyleCop 4.3.1.3 release and ReSharper plugin.

Links for 27-Nov

Bumper DLR bundle -- IronRuby α2, IronPython2 RC2...

OO F# -- encapsulation & comparison with C#.

Unit Testing -- neat idea for GUIs, frameworks for JavaScript.

SAML tokens with Geneva.

Geolocation services.

Links for 12-Mar

SOLID rules for OO Design

Calling JavaScript from Silverlight 2 -- and thereby, AJAX...

One application instance at a time -- the .Net 3.5 way 

Hiding System.Object members from Intellisense -- sometimes a useful decluttering

Have you updated your Windows SDK recently? 

Links for 31-Oct

Disliking the Object Oriented Approach -- hammers and nails

Too much of a good thing -- not every function should be a method

Why hide information?

Languages inside languages -- say what you mean.

Links for 18-Oct

The static gateway pattern -- an improved Singleton without all that pattern's global variable dependency entanglement.

Using Java classes from JRuby (the other way round awaits the second compiler)

A scriptless CSS slide-show -- impressive.

Links for 3-Oct

Inheritance is evil, and must be destroyed: part 1 (and barely scratching the surface)

Software is Hard 

Thou Shalt Have One Exit Point Per Subroutine -- A Monkey Cage Conundrum

Links for 5-Jul

Patterns I Hate #1: Singleton -- Global variables in OO clothing

The links in the comments to this post make it, well, suitable for singleton instantiation for today's links.

Links for 8-Jun

Is Object-Oriented Programming the problem? 

Developer Patterns -- a rejoinder

The High Cost of Management Indecision

Designing for informavores -- the berry-picking model of information acquisition

Making Wii-friendly pages -- designing for the game console's browser

HTML 5 and Accessibility

Links for 20-May

The flood continues …

Solving FizzBuzz using compiler error messages -- or another example of how to use C++ templates as a functional programming tool

Redefining Professionalism for Software Engineers

JavaScript hijacking -- Interesting post and comment thread on poor idioms to use within AJAX/JSON type programming

Sandboxing JavaScript using <iframe> -- a technique to mitigate injection attacks

Hard-core customisation of Visual Studio 2005 -- here used to suppress the auto-generation of #region tags around automatic interface generation (which are a nice idea in theory, but soon turn into undocumentation in practice). Thinking of which

Avoiding Undocumentation -- an oldie, but a goodie

loglibrarian: How I Learn New Things These Days

UAC is for developers 

Don't have a COW, man? What Haskell teaches us about writing Enterprise-scale software -- It's surprising what light a functional language, with immutable values can cast on a problem

Optimizations That Aren't (In a Multithreaded World) -- however... (Damned if you do, damned if you don't...)

The "Yes is No" problem -- with dynamic languages, what you see in the source may not be what you get at run-time

Pick a license, any licence

Breaking 104 bit WEP in less than 60 seconds

CSSVista -- Live editing tool for CSS in Firefox and IE simultaneously

Concurrency Crisis -- Is vanilla OO the right tool for handling inherently concurrent systems?

Less programming -- more skill?

Ruby Threads considered worthless -- mainly because they are interpreter-level (aka green) thread, not ones known to the OS (though that does not apply to JRuby which uses the Java threading library instead.

JavaScript framework for Google Maps

More on HTTP.SYS and its security implications -- a must-read

Free icon sets

PPK on HTML5

Firefox as an IDE

Web 2.0 Accesibility

Typography -- compose to a vertical rhythm

The Language of Accessibility -- build it in, don't build barriers

Prioritizing Web Usabilty -- Jakob Nielsen's latest book

Ruby code that will swallow your soul  -- some of the tricks that that Evil Ruby (Extends Ruby's semantics by accessing its internals from pure Ruby code) can enable

Pattern matching with Ruby -- no, not regexes; but something much more fun

SoftCoding -- A dailty WTF essay piece that spots a problem but doesn't quite draw the lesson from it -- the lesson being that Abstraction is somewhat like Optimization.

What if web apps worked like pin-ball machines? -- an interesting view of web idiom

Markup as Craft -- aiming for maintainability and usability

Guidelines for creating better mark-up 

InfoCards and Identity Stability

CardSpace and Unique IDs 

Agile Project management and Competitive Advantage

From Abstraction to Zipf

What does Barbara Liskov have to say about Equality in Java? -- same reasoning applies in C#

Architect's notes for Varnish -- a different look at storage paradigms

The truth about Lisp

Token Description Service for Cardspace

Walking, talking and quacking in Java -- Duck typing and interfaces

When in doubt, make it public

Mount ISO as CD with a MSFT tool -- self extracting .zip with readme.

[Now playing - Uninstall]

Responsibility Driven Design

The classical approach to object based analysis and design is the process of taking your problem or solution statement and picking out the nouns (objects) and verbs (methods). The objects that emerge are considered as data, with a bunch of associated methods to operate on those data members.

As a method of organising your problem into code this works; but it can make the code more cumbersome that it could be. A common point at which this sort of problem arises is the point where two or more objects interact through a given verb, and it's not obvious where to put the verb. And then when it comes to implement, side effects or necessary pre-conditions for doing whatever verb have to be considered.

And finally, when we are coding a verb -- an algorithm -- associated with one object, we are working at a level below the object design, where things start to become purely procedural again -- this can lead to code (which I am sure that we have all seen examples of) such as :

class ObjectUser {
    void doSomethingWithData() { // return and argument lists immaterial
        // do some stuff
        bool switch = someObject->getSomeState();
        if(switch)
            // do something not involving this
        else
            // do something else also not involving this
        // do some more
    }
}

where we inspect the state of one object to do something without making any reference to the calling object's state.

This sort of code, once it exists, is amenable to refactoring, moving the if/else code into a new method on the class to which someObject belongs. You may even find that after doing this, the whole need for the public getSomeState() method may vanish. Even if someObject is of a class we don't own, specialising or wrapping it can still be a good move. We have a whole book (and web-site) on how to do that with code.

But, wouldn't it be nice to get the same effect ahead of time, during the analysis and design stages?

Responsibility driven design is one technique that can help with this.  Rather than the historic data+algorithm approach for looking at objects, the approach is to look at objects for their roles within the system and their responsibilities in making it work. It also helps us focus not on the static anatomy of the system (such as inheritance paths), but rather on the dynamic behaviour of the objects in their context, and emphasises the encapsulation part of object design.

In this approach an object is defined by what it knows, and what services it performs. Those services may be performed by passing parts of the tasks to other objects that this first object knows about; but the clients need not know about that. All they need to see is an interface, describing the services.

Thinking about or objects this way, we can take a rough partition of the system into objects -- perhaps a noun and verb model -- and start to assign roles : does this object know things? coordinate activities? perform services? interface with things beyond the system? Then we can perform what is in effect a dry run through the model, based upon known use cases. This will show up those cases where an object may actually need to know things not initially available to it.  It will also reveal where objects are being asked to do too many different things (and occasionally, those doing too little to justify themselves).

Objects that have more than one focus of responsibility are candidates for being broken up. Tasks that are not strictly related to their responsibility should be moved to objects for whom they are better suited.

After a couple of iterations -- which may be done on the fly, while running through the use cases -- the changes should settle down; and the web of interactions simplified.

With your objects defined by their roles (interfaces), and the unnecessary interactions untangled, the design is also readied for test driven development -- you have interfaces for mock objects to follow, and have reduced the amount of work that a mock will have to perform.

Related links

http://www.wirfs-brock.com/Design.html -- Rebecca Wirfs-Brock's site, pretty much the last word on the subject

http://www.cs.colorado.edu/~kena/classes/6448/s05/lectures/lecture04.pdf and http://www.cs.colorado.edu/~kena/classes/6448/s05/lectures/lecture05.pdf -- two lectures (presentations in .pdf form) as a high-level overview of Responsibility Driven Design

Links for 18-May

A bit of a catch-up:

CardSpace and decrypting Tokens

An Approach to Composing Domain-Specific Languages in Ruby

Giles Bowkett: The Business Case For Firefox

Bitwise Magazine:: What’s Wrong With Ruby?

New mailing list: HTML 5 Help

swfIR: swf Image Replacement

Five Principles to Design By

Debugging a Service on Windows Vista

The One Important Factor of programming languages

Lazylist implementation for Ruby

What Colour do you like your Objects? Pink or Blue?

Actions, Not Words

Are Web Interfaces "Good Enough"?

Your Code: OOP or POO? 

Creating User Friendly 404 Pages

Graphic designers misunderstanding Web standards

XSS bestiary

Remove empty lines from a file using Powershell.

Why <video>?

W3C's new HTML blog

Web Typography Sucks -- presentation and links to web typography resources.

Alpha release of Adobe's Apollo cross-platform runtime.

Keep your cookies straight when using ADFS

Is Your Software Team Sticky? -- do they share a coherent vision?

Primary Keys: IDs versus GUIDs

IE 7 does not resize text sized in pixels -- or any other absolute size *sigh* : Squelching what might become an urban myth

Miscellanea

How times change - I had to explain yesterday to a 7-year-old boy what smoke signals were.

During the last month, I've been doing some recruiting - and it's terrifying how many people out there are trying to earn a living in software engineering without any idea of what polymorphism is about, or the notion of time-complexity of algorithms, let alone design skills that have any nod towards the notion that software objects should have well defined interfaces and responsibilities. And this is not an age related thing, either. Though eventually we did find a couple of suitably qualified candidates, one mid 20s, one early 40s, who are now with us.