Categories
Uncategorized

Open Source Language Roundtable Webcast: Wednesday, July 22nd

oscon_language_roundtable

O’Reilly’s conference on Open Source, OSCON, takes place this week in San Jose, California. One of the events taking place at OSCON is the Open Source Language Roundtable, the abstract for which appears below:

We all have our favorite languages in our tool-belt, but is there a ‘best’ overall language? If anyone can hash that out, it will be the members of this roundtable discussion, some of the stars of the open source language space. This wide-ranging session, hosted and moderated by the O’Reilly Media editorial staff, and broadcast live on the web, will try to identify the best and worst features of each language, and which are best for various types of application development.

The roundtable will me moderated by O’Reilly Media’s James Turner and will cover the following languages, listed below with the corresponding panelist:

  • Java: Rod Johnson (SpringSource)
  • Perl: Jim Brandt (Perl Foundation)
  • PHP: Laura Thomason (Mozilla)
  • Python: Alex Martelli (Google)
  • Ruby: Brian Ford (Engine Yard)

You can catch this roundtable even if you’re not going to be at OSCON because O’Reilly is webcasting the event. It takes place this Wednesday, July 22nd at 10pm EDT (7 pm Pacific) and is expected to run 90 minutes. It costs nothing to catch the webcast and you’ll even be able to ask the panelists questions via chat, but you’ll need to register.

Categories
Uncategorized

Damian Conway’s Talk, “The Missing Link”: Monday July 27th in Toronto

Damian Conway

Although I’m not a terribly big fan of the Perl programming language, I am a big fan of one of its best-known contributors and advocates, Damian Conway. There’s nothing quite like a Damian Conway presentation, which is equal parts pop culture, deep science, software engineering and Monty Python’s Flying Circus. I make it a point to see him whenever he comes to Toronto, and that’s happening next Monday, July 27th to the Bahen Centre for Information Technology at University of Toronto to give another amusing, enlightening and most importantly, free talk. This one’s called The Missing Link, and here’s the abstract:

What do:

  • watching trees grow,
  • debugging debuggers,
  • Greek mythology,
  • code that writes code that writes code that writes code,
  • the hazards of LaTeX, successful failures,
  • the treacherous Vorta,
  • objective syntax,
  • anti-stacks,
  • Danish mind-control,
  • active null statements,
  • synthetic standup,
  • and the prospect of certain death

…all have in common?           

Watch as Damian Conway weaves them together into a new and improbably useful module that demonstrates the awesome power and beauty of Perl 5.10.

Even if you’ll never write a line of Perl in your life (which, IMHO, isn’t necessarily a bad thing), you’d do well to catch a Damian Conway presentation. His guided tours of his way-out-in-left-field thinking about life, the universe, programming and everything will turn your brain upside down, give you some good laughs, make you think about coding differently and might even make you a better developer.

Once again, the details:

  • When: Monday, July 27th at 7:00 p.m.
  • Where: Bahen Centre, University of Toronto (40 St. George Street), room 1160 (the major lecture theatre on the ground floor)
  • How much? Free!

Show up early to make sure you get a good seat. I’ll see you there!

Categories
Uncategorized

The “Name My Floater” Contest

floater

Over on my personal blog, The Adventures of Accordion Guy in the 21st Century, I’m holding a “name my floater” contest. Get the back story, think up a name, win a gift certificate!

Categories
Uncategorized

DimeCast.Net’s SOLID Screencasts

This article also appears in Canadian Developer Connection.

Brick with the word "SOLID" beneath it

Following up on the previous article about the SOLID principles for object-oriented design, Steve Bohlen pointed me to a series of screencasts on DimeCasts.net covering each SOLID principle:

The screencasts are each about 12 minutes long, a perfect length for a “learning snack”.

Categories
Uncategorized

Boo-Effing-Hoo

Parody of the "You Find It, You Keep It" graphic: "You watch our ads / You throw a hissy fit"with the Apple logo.

(Click the image to get the story.)

Categories
Uncategorized

FutureRuby Talk: “Artisanal Retro-Futurism and Team-Scale Anarcho-Syndicalism” [Updated]

Update: There’s a link to a video of the same talk given at an agile conference earlier this year. See the end of the article for details.

Here are my notes from the FutureRuby presentation titled Artisanal Retro-Futurism and Team-Scale Anarcho-Syndicalism by Brian Marick.

Sticker: "Artisanal Retro-Futurism and Team-Scale Anarcho Syndicalism"

  • This talk is about economies and (dis-economies) of scale
  • The idea behind this talk got started around 2000 – 2001, when I visited agile projects and people on the teams would say things like “This is the best project I’ve ever worked on! Why do it any other way?”
  • Then, two years ago, I talked to someone who’d been doing Scrum for a year and he said “At least my job doesn’t suck as much as it used to.”
  • Hearing stuff like this, people like me – the Agile Old Guard – we get distressed. We’d much rather hear what people used to say
  • The problem is that the economies of scale that drive corporations to be larger and make more money are also diseconomies for the people working within them
  • I will differ from what Nathaniel [Talbott] said in his presentation. I believe that even the wage-slave can know “joy-in-work”
  • What used to be present in Agile projects that’s gone missing in new ones? I’ll tell you what it is: it’s Artisanal Retro-Futurism and Team Scale Anarcho-Syndicalism!
  • "Yes it’s true, not everybody immediately grasps what I mean."

 Techno-anarchy

  • First, let’s consider what “anarcho-syndicalism” is
  • Consider an agile team. The see themselves as alone in a dangerous place, where no one else is offering any help.
    • It would be nice if a “daddy” swooped in and help save them from the mean people
    • The are problems with this approach: it’s pathetic, and it often doesn’t work
  • Here’s a story for you to illustrate things:
    • An agile team was made to work in cubicles, like the rest of the company
    • Agile methods aside, cubicles are the "single worst arrangement of humans and objects in space for the purpose of developing software"
    • The team proposed changing their workspace to an open one
    • Furniture Police turned them down
    • In response, the scrum-master went to the office over the weekend. She disassembled the cubicles and changed the office layout to an open one. On Monday, she declared to the Furniture Police that “If the cubicles come back, you will have to fire me.”
    • They gave in
  • Anarcho-syndicalism is a political/economic/trade union movement
  • It peaked in 1923, and was crushed by the U.S. government in 1924
  • “Anarcho” comes from “anarchy” — they wanted to see government go away
  • “Syndic” refers to a trade union – they wanted to replace corporations with trade unions, or more simply, they wanted to see corporations go away
  • Anarcho-syndicalism has these principles
    • Worker self-management:
      • Workers decide how to control factory
      • They’re not fans of hierarchy in general
      • The aforementioned “Cubicle Incident” is an example
    • Direct action:
      • It’s about not waiting for “daddy” to swoop in and save you
      • It’s about taking action – doing something and then saying to anyone who disagrees “What are you going to do about it?
      • There was a difference of philosophies in the labour movement over direct action:
        • Some believed that they should elect/influence/bribe elected officials to pass laws to ban the burning down the houses of people on strike
        • Other believed in a more direct form of direct action: beat up or kill the people who tried to burn down the houses of people on strike
    • Worker solidarity:
      • This is the one principle that wasn’t followed in the cubicle incident
      • The scrum master could’ve been fired
      • Under worker solidarity, the entire team would’ve said “You’ll have to fire us all!”
      • (That’s okay, though: “Scrum masters are not hard to come by” – you’ve seen the courses: "Two days, $2000, you can be a scrum master!")
  • I invert the anarcho-syndicalist flag
    • I do it to reflect something the original anarcho-syndicalists didn’’t care about: team scale
    • I believe that teams should band together more
    • Sometimes it’s "our cursed individualism" that gets in the way, the need to be the Ayn Rand hero — we’d be a lot more effective if we could get past that
    • I am advocating teamsmanship
    • We need more power in the hands of the team to counterbalance the power in the corporation
    • Remember, power can be used for good, evil…or stupid
    • If the team is completely inwardly-focused, they will do stupid things
      • Completely inwardly-fcoused teams devolve into fighting over things like who gets the workspace with the most light
  • There needs to be a manifesto for software craftsmanship, to move from journeyman to master

Plate of artisanal cheeses

  • Let’s now consider what “artisanal” is
  • It’s all about the cheese
  • As an artisanal cheesemaker, I care about cheese
  • I want to make really good cheese for really good people who will enjoy the cheese
  • I care about the cheese!
  • The interests of the executives in an organization are not necessarily aligned with the owners (shareholders) or the pesky customers
  • The teams working on a software project for an organization often care more about the project than the organization’s executives do – in the software field, they are the artisanal cheesemakers
  • We – as metaphorical artisanal cheesemakers — care about the cheese, which means “we should get away with the things we want to get away with” because these things help us get our work done

Retro-futuristic cityscape

  • Now let’s consider what “retro-futurism” is
  • The future ain’t what it used to be
  • Look at all the old science magazine articles about the future: flying cars, cities underwater and on the moon and robots that clean the house. Only one of them came true!
  • "We have 60 years of envisioning the future, and all we got for it was the Roomba"
  • The unfulfilled promises are now part of popular culture: “Where’s my jetpack?"
  • Retro-Futurism is about having optimistic images of the future
  • The spirit of retro-futurism is in Infinite in All Directions by Freeman Dyson
    • Chapter 2 is pretty good
    • The book is really good at conveying a sense of possibility
    • It says that you keep finding new things when you go in the small direction, towards the sub-atomic, but you also find new things in the big direction too, towards the universe
    • You also find new things as you go outward and see the interesting complexity of life and social organization
    • It says that there’s no end to what a curious scientist could discover
    • It is permeated with a spirit of hopefulness
  • As for you and me:
    • We’re limited in most directions
    • I want to us to try to convert ourselves to infinite in all directions””
    • Holding conferences like FutureRuby is one way to do this
    • One way not to do this is to listen to people like me
      • I once had a …vigorous debate…Ron Jeffries about test-first programming
      • It was about what programmers would rather do – would they rather write tests or new code? I kept saying that “test-first is never going to work”
      • I also said: ”In two years, you’re going to ask yourself whatever happened to all those unit tests? They’ll be gone — it’s just the way the world works!”

Painting: "Liberty" (from the French Revolution)

  • As programmers, we’re used to working within constraints
  • The context in which we work makes agile hard – we need to change the context
  • Remember, you drive the context, not the other way around!
  • I’m asking you to be scrappy in defense of producing the cheese you care about, to do what you can to do the best work you can, to make the best software you can, as enthusiastically as you can. I’m asking you to practice Artisanal Retro-Futurism and Team-Scale Anarcho-Syndicalism
  • How do you do it?
    • By getting back to your workplace?
    • By harnessing the (useful) madness of crowds
    • By proselytizing the good word of Artisanal Retro-Futurism and Team-Scale Anarcho-Syndicalism
    • By visiting Arxta.net, the “global headquarters of the movement”

See the Video!

There is a video available – while it’s not the presentation Brian gave at FutureRuby, but one he gave at an agile conference earlier this year, it’s pretty much the same.

Categories
Uncategorized

The SOLID Principles, Explained with Motivational Posters

This article also appears in Canadian Developer Connection.

SOLID Seems to be Everywhere These Days

solid

Robert C. “Uncle Bob” Martin first gathered the object-oriented design principles that would eventually go under the acronym SOLID almost fifteen years ago, but the SOLID principles have been making the rounds lately.

Before I talk about the SOLID principles, let me show you where the concept has been popping up in the past few months…

SOLID at Conferences

At the Microsoft TechEd conference in May, Steve Smith gave a presentation on applying the SOLID principles to developing applications with the ASP.NET MVC framework. At around the same time, the GeeCon conference in Krakow, Poland had a couple of presentations on SOLID: Bruno Bossola gave a talk on the SOLID principles and  Lee Brandt gave a talk on spotting SOLID code “in the wild”.

SOLID at User Groups

A number of user groups have had recently presentations on SOLID, such as:

Stack Overflow on SOLID

SOLID was the topic of a recent argument that took place over a series of podcasts earlier this year:

SOLID in Blogs

SOLID has also been spotted in a number of blogs:

Will There be a Presentation on SOLID at TechDays Canada 2009?

Mmmmmmmaybe…

And Now, The Principles and Posters

The folks at LosTechies.com have created a series of Creative Commons-licenced posters that illustrate the SOLID principles. I took the posters, cleaned up the typography a little and posted them below under the same Creative Commons licence. Below each poster is an explanation of the corresponding SOLID principle. Enjoy!

Single Responsibility Principle

single_responsibility_principle

The “S” in SOLID is for Single Responsibility Principle, which states that every object should have a single responsibility and that all of its services should be aligned with that responsibility. “Responsibility” is defined as “a reason to change”, and Wikipedia does a pretty good job of explaining it:

As an example, consider a module that compiles and prints a report. Such a module can be changed for two reasons. First, the content of the report can change. Second, the format of the report can change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules. It would be a bad design to couple two things that change for different reasons at different times.

Open-Closed Principle

open-closed_principle

The “O” in SOLID is for Open-Closed Principle, which states that software entities – such as classes, modules, functions and so on – should be open for extension but closed for modification. The idea is that it’s often better to make changes to things like classes by adding to or building on top of them (using mechanisms like subclassing or polymorphism) rather than modifying their code.

Liskov Substitution Principle

liskov_substitution_principle

The “L” in SOLID is for Liskov Substitution Principle, which states that subclases should be substitutable for the classes from which they were derived. For example, if MySubclass is a subclass of MyClass, you should be able to replace MyClass with MySubclass without bunging up the program.

Interface Segregation Principle

interface_segregation_principle

The “I” in SOLID is for Interface Segregation Principle, which states that clients should not be forced to depend on methods they don’t use. If a class exposes so many members that those members can be broken down into groups that serve different clients that don’t use members from the other groups, you should think about exposing those member groups as separate interfaces.

dependency_inversion_principle

The “D” in SOLID is for Dependency Inversion Principle, which states that high-level modules shouldn’t depend on low-level modules, but both should depend on shared abstractions. In addition, abstractions should not depend on details – instead, details should depend on abstractions.

Bonus Reading Material on SOLID

In addition to the LosTechies.com posters, they’ve also produced a book covering the SOLID principles in detail. Go and download Pablo’’s Solid Software Development [1.4 MB PDF] now!