Are we unprofessional?

From Uncle Bob's Clean Code, discussing the pressures that professionals get to deliver unacceptable quality:

What if you were a doctor and had a patient who demanded that you stop all the silly hand-washing in preparation for surgery because it was taking too much time? Clearly the patient is the boss; and yet the doctor should absolutely refuse to comply. Why? Because the doctor knows more than the patient about the risks of disease and infection. It would be unprofessional for the doctor to comply with the patient.

Ouch! What a great metaphor! It really hurts, but it is also a brilliant invitation to get vocal when one needs to get vocal.

A button to make it simpler to paste notes: urls

I often paste links to Lotus Notes documents (mostly mail messages) in my tiddlywikis. Creating a toolbar button that puts the notes: url in a field makes it simpler. Unfortunately, LotusScript does not provide a way to access the clipboard, so you have to manually select the text and copy it there.
Create a new toolbar button and paste this code inside:

dn := @Subset(@DbName; 1);
linkType:= "Document";
nsfPath := @WebDbName;
qualifiedHost := @If(@Length(dn) = 0; ""; @DbLookup("":""; dn:"names.nsf"; "($ServersLookup)"; dn; "SMTPFullHostDomain"));
dbUrl := "Notes://"  + qualifiedHost+ "/" + nsfPath;
viewUrl := dbUrl +  "/";
docUrl := viewUrl + "/" + @Text(@DocumentUniqueID);
docTitle := @If(@IsAvailable(Subject);Subject;@IsAvailable(Title);Title;@IsAvailable(FullName);FullName;@Name([CN];@Author));
clipboardTxt := "[[" + docTitle + "|" + docUrl + "]]";
@Prompt([OkCancelEdit]; "TiddlyWiki link"; "Copy the text below to the clipboard."; clipboardTxt)

I posted this long ago in my intranet blog, and looks that can also be useful outside. The code was adapted from something that Jonathan Feinberg, of Wordle fame, wrote for a then young and great Dogear, a bookmarking service that ended up being one of the key components of Lotus Connections.

Pushing agility from the business side?

Pushing agility from the business side?, originally uploaded by -Xv.

A possible scenario:

1. IT happy with status-quo: Big Design Up Front and Waterfall.
2. Stakeholders accept non-agility as a fact of life.
3.Tell stakeholders that they are entitled to learn, to defer
decisions until the have more info, to change their opinion. That some
of their competitors use those right to their advantage.
4. Stakeholders will push agility upon IT

Just in case it helps Ferran Rodenas to get some idea to break the status-quo

Some notes about troubleshooting

From Why Programs Fails: A Guide to Systematic Debugging:

Some terminology: from defects to failures

1. The programmer creates a defect.
2. The defect causes an infection (the program state differs from what the programmer intended)
3. The infection propagates
4. The infection causes a failure (an externally observable error in the program state).
   

Debugging can be decomposed into seven steps:

Track the problem in the database
Reproduce the failure
Automate and simplify the test case
Find possible infection origins
Focus on the most likely origins:
Known infections
Causes in state, code, and input
Anomalies
Code smells
Isolate the infection chain
Correct the defect

Note the TRAFFIC mnemonic.

Opinion ON:

That's nice theory. Unfortunately, the complexity of IT has teached us that computers are non-deterministic beasts. The first thing that we do in case of a problem is restart the system, hope that the problem will go away, and be able to keep doing our job. And it often works.

But we, software developers and support technicians, need to un-learn our hide the symptoms urge. If we suspect that there is some defect in the code (and trust this old software developer, you can be confindent that it very likely that there is one), our goal should always be to find the defect, instead of changing things so that the defect is not executed or the infection does not end up causing a failure. Leaving that defect unfixed is very likely to cause pain in a future situation. À la programming by coincidence.

Some advice

• avoid corrective actions before the issue is understood. Before the failing code is identified, you should only use temporary corrective actions to help you frame the problem. I'm guilty of having neglected this rule lots of times, and requested customers to just upgrade the code to see if the issue goes away.
  
• when possible, use tools that minimize the infection propagation (that, crash as soon as possible). On Windows, I was recently introduced to pageheap and I'm in love with. More on it another day.
• defects come from source code: give support technicians access and knowledge to read the source code. Support people and developers should change seats quite often.
  

Certificate-based logon to zOS

DCAS (zOS Communications Server's Digital Certificate Access Server) has come to my rescue. From the docs:

The DCAS can be used by providers of logon and single sign-on services where access to z/OS-based applications is needed. The DCAS is a TCP/IP server that enables clients to connect over the network and obtain a passticket and z/OS user ID from RACF.

Clients that connect to DCAS must use the SSL protocol (DCAS supports SSL Version 3). Client authentication is performed.

Clients can request a user ID and passticket for an application. The client sends an x.509 certificate. DCAS converts the x.509 certificate to a valid user ID, which is returned. The x.509 certificate must have been mapped to a valid user ID in RACF

It's the second time in a few months that DCAS is the solution to the problem that I'm working on; unfortunately, I had forgotten about the first time, so it has taken my a while to get rescued. Not a complete waste of time: if learned a few things about PKI and RACF.

The first time it was about a service to generate passtickets (strings that can be used as passwords for a short while). Despite my recommendation, the customer's choice was to not use DCAS and code it from scratch; go figure.

Now it is about authenticating to RACF from a application that uses a smartcard reader. I'm looking forward to code the smartcard-based RACF logon, since working with smartcards has been in my wish list for very long.

And since google and DCAS don't seem to be big friends, I'm posting this.

DRAE restful

Esto es http://rae.es/chulo ! Y es que, la URI es lo suyo.

sprintf_s() is not snprintf()

You are compiling some legacy code with Microsoft Visual Studio. You get a warning telling you
warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead.
Of course! So you just change that dangerous sprintf() for a sprintf_s(). The IDE tells you about an additional buffer size parameter, so you may wrongly end up thinking that you are getting the equivalent to Unix's snprintf() or the old MSV _snprintf().

Nope. If you read the docs, you'll learn that sprintf_s() is not truncating the string, but instead invoking the run-time invalid parameter handler, and usually terminating the program. Far better than letting a buffer overflow happen, but maybe not what you were expecting.

Happy Stop Software Patents Day!

The problems with software patents go far beyond those trivial patents that get linked from time to time.

Usual disclaimer (stolen from Read This Blog!) applies here specially: IBM has its opinions and plans; I have mine. Any resemblance between the two is coincidental

Falta chico con experiencia

Uno ya se va acostumbrando a que el papel del programador no se valore mucho, incluso por gente que se supone mejor informada, pero esta perla me ha hecho reir:

Falta chico con experiencia en programación PHP, AJAX, MySql, sistemas, etc. También precisamos un diseñador gráfico manejando bien Photoshop y Flash. Interesados enviar CV con datos completos, teléfono de contacto y horario para llamar. Si cumples el perfil puedes tener una entrevista de inmediato.

SuperHappyDevHouseBarcelona polls

Baby steps towards having a hackathon event that combines serious and not-so-serious productivity with a fun and exciting party atmosphere: SuperHappyDevHouseBarcelona... two polls:

• Would you be interested in an event of this kind?
• How about a beer/coffee next week to get things started?
  

SuperHappyDevHouseBarcelona? Why not?

SuperHappyDevHouse is a non-exclusive event intended for creative and curious people interested in technology. We're about knowledge sharing, technology exploration, and ad-hoc collaboration. Come to have fun, build things, learn things, and meet new people. It's called hacker culture, and we're here to encourage it.

I've been wanting to attend to something similar to SuperHappyDevHouse since I first heard about it years ago, thanks to an intranet post by Tessa Lau telling how much she enjoyed one.

It shouldn't be too hard to find a handfull of people in Barcelona interested in a hackathon event that combines serious and not-so-serious productivity with a fun and exciting party atmosphere. Summer nights are nice, and probably there are higher chances to find available venues. Mmm...

Next actions:

• get first reactions from fellow hackers (and hopefully draft co-organizers)
  
• explore some venue candidates. I don't have high hopes of finding one that allows a dusk-dawn event (the format of the first editions), but a shorter/earlier hackaton would also be cool.

Debugging Emergency Kit

The image above is the hand-out of the last talk I gave. Rubber ducks have long been known as one of the most effective debugging devices [1].

Very often, while debugging, you *know* that you are almost there. The problem is that, before you notice, the morning has gone by with you being "almost there". If you don't really get there after a couple of quick and dirty iterations and want to avoid wasting a morning "almost there", it is very useful to make explicit the steps that everyone takes while debugging: enter your notebook and the scientific method (quoting from Andreas Zeller's Why Programs Fail: A Guide to Systematic Debugging)

1. Observe a failure
2. Invent a hypothesis consistent with the observations
3. Use the hypothesis to make predictions
4. Test the hypothesis by experiments and further observations
   • If the experiment satisfies the predictions, refine the hypothesis
   • If the experiment does not satisfy the hypothesis, create an alternate hypothesis
     
5. Repeat steps 3 and 4 until the hypothesis can no longer be refined
   

Keeping a written track of the steps is the key here. The advice is quite obvious, but we often forget about obvious things that work very well [2].

[1] This is not the only surprising ability of rubber ducks: http://en.wikipedia.org/wiki/Rubber_duck#Oceanography
[2] I'm writing this post after a most ineffective "almost there" afternoon

dreamer, coder, hacker

Diagram by Paul Downey (of the Web Is Agreement fame), based on (I think) an idea by Y!'s Spo0nman/Pankaj

Happy Geek Dad

Stumbled upon Jason R. Briggs' Snake Wrangling for Kids:

"Snake Wrangling for Kids" is a printable electronic book, for children 8 years and older, who would like to learn computer programming. It covers the very basics of programming, and uses the Python programming language to teach the concepts. Examples are presented for Windows, Mac OS X and Linux.

You are flying! How?

Read the rest of the strip

Yay! Barcelona Python Meetups are here!

Back from the first Barcelona Python Meetup Group event. The event was good, with two talks:

• Maik Röder, based on the Eight tips to start with Python. Maik added an additional tip (use PyFlakes, a faster PyChecker) and asked the attendants for our own tips: IPython (a great shell that I should be using again) proved to have many fans! I mentioned my love for ctypes.
• Ramon Navarro Bosch, on Design Patterns in Python. Ramon recommended us Alex Martelli's Google TechTalk video on the topic.
  

If the event was good, the post-event (beers, croquetas and bravas) with Maik was great and I'm bringing home lots of food for thought. Most of the talk was about Funittest (Making it easy to go from use case to functional test). Maik uses daily a high level Test Driven Development flow:

• write the functional test, to get aligned with the user's needs/customer value,
  
• write unit test, that can be driven faster and focus in the approapiate level of abstraction
• write the code

My impression is that his ideas have lots of commonalities with Fit and Fitness, and the story-based-testing that they advocate. Maik said that Funnitest's theoretical foundation can be grasped in The Braidy Tester articles; I'm adding them to my to-read list...

Beyond functional testing, the programmer's flow, the business-technical gap, Barcelona, Sevilla, tele-working... an intriguing an promising idea: the I-told-you-that-this-was-a-wrong-decision year-end bonus.

We make mistakes

Everyone makes mistakes. Some times we are aware of them, some times we are not: looks like putting the blame of mistakes in someone or something is part of our nature. It's a pity, because we let pass by lots of learning opportunities.

Flickr picture by srslyguys

We software engineers are lucky enough of being faced in our trade with lots of mistakes that we cannot blame in any one but ourselves. Of course, some mistakes allow allocating blame on our customer, our team, our tools... My teammates often hear me cursing loudly Bill Gates or Linus Torvalds, but they know I'm jocking: we are experienced enough to know that select isn't broken. When writing code, you rarely can put the blame on someone/something else unless you are a pathological liar; that's good.

I would like to think that having to face our daily mistakes helps us weaken our blame-someone-else voice in other areas of our life, but, honestly, I don't have any evidence about it. But, just in case, I'd like my kids to learn the we make mistakes, we learn from them lesson/mindset, and this has been one of the main drivers in getting our new home pet, a Lego Mindstorms NXT Robot.

Why interpreted programming languages suck

XUL templates and tabs

I had some problems using XUL templates to populate a tabbox using a RDF data source: the tabs were created, but switching tabs did not work. Avoiding the use of inline templates and moving the template outside of the tabbox element solved this. Looks like the tabbox was confused by the <tabs> and <tabpanels> elements inside the <template> node.

<template id="tabTemplate">
    <tabs>
        <tab uri="rdf:*" label="rdf:http://multirunner.blah/rdf#name"/>
    </tabs>
    <tabpanels>
        <tabpanel uri="rdf:*">
            <label value="rdf:http://multirunner.blah/rdf#name"/>
        </tabpanel>
    </tabpanels>
</template>  
<tabbox id="rdftabbox" 
        datasources="rdftabs.rdf" 
        ref="http://multirunner.blah/tabs" 
        template="tabTemplate" /> 

Virtual gaming, leadership and agile software development

As I was reading the excellent Virtual Worlds, Real Leaders by seriosity and IBM's Global Innovation Outlook (GIO) team, I was struck with the similarities of the leadership attributes that they found in MMORPGs (Massively multiplayer online role-playing games) and those that are familiar to me from working in agile software development projects.

I'm quoting two summaries that appear in the report:

Online gaming environments facilitate leadership through:
1. Project-oriented organization
2. Multiple real-time sources of information upon which to make decisions
3. Transparent skills and competencies among co-players
4. Transparent incentive systems
5. Multiple and purpose-specific communications mediums

In fast moving distributed environments, leadership can be:
1. A temporary phenomenon
2. Task-oriented
3. Dynamic and constantly changing

Doesn't this make you think about how the daily scrum/stand up meeting and collective code ownership provides "transparent skills and competencies among co-players"? About how the leading roles in an agile team changes constantly among team members depending on the task at hand? About the fluid communications in the noisy room where the team is sitting?