Frank Carver's musings about software and life
I can honestly say that I was astonished by this. A continual, unrelenting, stream of rhythm and rhyme for over two minutes which weaves in and out of a fantasy scenario of mockingbirds as recording devices while making references to a slew of TED talks from the same conference.
Of all the talks I have watched so far, this is the only one I want to watch again, straight away. I can’t offer higher praise than that.
Definitely back to the kind of talk which TED is famous for: Ric Elias: 3 things I learned while my plane crashed. Ric gives a razor-sharp view of his near-death experience, and the things he took from it. They are the same kinds of things that often occur to people facing their end, but it still feels as if we all need to be reminded. Savour every moment, don’t put things off, there’s no room for negativity, and be the best parent you can..
This was a bit of a surprise. Among all the worthy talks I didn’t realise that there are also comedy routines, songs and other stuff in the TED archive. I found Ze Frank’s stand-up routine pretty funny, although not really as “nerdcore” as it could be be – there is typically more nerd comedy in an episode of “Big Bang Theory”.
In this case reading the comment stream did not seem to add much. Many of the commenters don’t seem to like his humour, and unlike some of the other talks there’s not much development of the ideas in the presentation to be done. Fun, but not thought-provoking.
I’ll admit I am doing a bit of catching up here, having missed a day or two, but I’ll be back on track soon.
For day five I chose VS Ramachandran: The neurons that shaped civilization. This talk introduces the idea of “mirror neurons”, elements of the brain which trigger when observing other people’s behaviour, and goes on to imply that the existence and sophistication of this brain biology is what enabled the spread of human learning and the development of culture. As far as that goes I generally agree. Later in the talk he gets a bit metaphysical, deducing from some mirror neuron behaviour in cases of amputated or anaesthetised limbs that all people are linked.
Today’s talk was another short one, this one about 3.5 minutes. The idea was interesting – a relatively low cost cooling unit that “charges” itself in a cooking fire, then can be used to keep a big drum container cool for 24 hours.
Pitched at storing vaccines away from power, and also preventing food decay and disease it seems to address a need, but (as the comments point out) there are economic and financial issues as well as an apparent lack of progress in the intervening four years. This idea may not be a “go-er” after all. Shame.
Another pretty much random choice of a talk to watch, this one Charles Limb: Building the musical muscle) surprised me because it was not what I expected. From the title I expected something a bit more about the psychology of music or the brain’s perception of music, but what I got was a fairly detailed talk about cochlear implants as an approach to restoring hearing loss.
The main thrust of the talk was to demonstrate that while even the best current implants can greatly improve perception of speech, they fail miserably at all aspects of music – to the extent that many implant users find music co uncomfortable that they prefer not to listen to it.
Overall, I’m sure I learned something about the current state of hearing restoration surgery and its limitations, but this talk was not one which inspired me to think differently.
So, pretty much at random I chose another TED talk video to watch. This time it was John Bohannon: Dance vs. powerpoint, a modest proposal.
I found the talk interesting, thought-provoking, and decidedly tongue-in-cheek (the reference to Swift in the title gives that away). Although the apparent premise (use dancers instead of powerpoint) has many flaws, the underlying theme is fascinating. Hard science and dance are traditionally seen as so far apart as to be completely incompatible, yet here is a presentation which successfully conveys some quite complex physics with no diagrams or equations, just a few well chosen words and some moving bodies.
I am left with echoes of a discussion earlier today on the subject of whether software development can be art. The same sense of unexpected juxtaposition evokes interesting and thoughful perspectives which may lead to innovation. For me, that is the true value of this talk.
One my video site I have just completed Vlomo. Vlomo is one of the many “every day in November” challenges, along with NaNoWriMo, NabloPoMo, Movember and so on.
The end of November can be a bit of a let-down, though. One way or another the challenge is over.
While discussing this with a colleague recently, we hit on the idea of watching one of the TED talk videos each day in December, and blogging about it. This is a great idea both for learning and for getting back into the practice of reflective blogging.
I have decided to label this challenge “TEDcember”, and I will be using this tag in tweets and blog posts. Feel free to join in!
So, with all that in mind, Steve chose Matt Cutts: Try something new for 30 days as a first talk to watch, and then blogged about it. I was already running a little behind, so (on the premise that it is an appropriate starting point I watched the same one.
Guess what. This is my blog about it.
The talk was obviously motivating. After all I’m sitting here trying something new for 30 days, just as suggested. Two bits of the talk struck me particularly strongly, though. The first was the way that the speaker was happy to admit that his NaNoWriMo novel was rubbish, but that the process of producing it was valuable. This is something which I have found again and again during vlomo. The second stand-out point was the aggregate value of multiple such challenges. It’s so easy to concentrate on one challenge at a time and miss the big picture. The very act of continuing to take on month-long challenges, especially ones which are outside a normal “comfort zone” develops confidence and a sense of worth, even for the challenges which don’t work out.
And that’s the real reason why I felt compelled to roll off Vlomo and into TEDcember. To keep up the momentum of personal development. Let’s see how we get on…
The guys at ebay have released ql.io, which seems to be a way of using SQL-like queries to fetch and join data (typically in the form of JSON, it seems) from multiple web APIs to generate quick “mashups”.
See ql.io.
I can’t help thinking that there are a lot of hidden issues around API compatibility and conflicts, as well as the complexity of specifying increasingly tricky business processes, though. All these issues have been encountered in the XML workflow and process modelling world.
This certainly looks an interesting way to get started quickly with quite a broad class of mashup applications, though.
Gojko Adzic is usually good value. Here’s his suggestions and tips for presenters.
Agile software development places a lot of emphasis on prioritisation of work and elimination or deferral of anything which is not needed right now. An obvious advantage of this is that important stuff gets done quickly, but a less obvious disadvantage is that deferred work can pile up like snow before a snowplough. For a long-running project, the effort to keep “pushing” these deferred activities can become a significant task in its own right.
The Pragmatic Programmers wrote:
Don’t Live with Broken Windows
Fix bad designs, wrong decisions, and poor code when you see them.
While this is fine as a principle, there will still be times when edge-cases, uncommon modes of operation, laborious work-rounds and generally less valuable aspects of a system should be deferred, even though there is a sense that they will need to be improved later. The question arises of how to best represent and remember these issues so that they are not accidentally lost.
Some development IDEs and other tools incorporate in-code annotations such as TODO or FIXME, and almost every programming language supports comments, where such notes may be paced for more manual processing. These can, however, be tricky to find if you don’t already know where to look, and an apparently obvious note can quickly lose context and usefulness as developers move to focus on other work.
Mark Needham recently wrote of his experiences with a ‘window fixing’ wall.
A project I worked on recently tried a section of a card wall for “issues”, but these languished in a fog of “somebody else’s problem”. We got rid of that and replaced it with a section to collect issues for the next retrospective, but even that has become less used as the project progresses.
Inspiration for a solution might come from another post from mark Needham: “Pain Driven Development.” Although this article emphasises other aspects of agile process, the essence of the idea seems to be that the things that actually get done are the things which cause the most “pain”. Perhaps if we can find a way to convert theoretical “broken windows” and other incomplete work to a sense of “pain”, they will naturally be addressed as part of the normal intuitive prioritisation process.
Has anyone managed this?
It’s a common pattern, an enterprise software solution has a body of code, managed by version control, verified by continuous integration and eventually delivered to some deployment system. If that were the whole picture things would be relatively straightforward. Tests pass? deploy it!
Unfortunately there is often also a database in the mix. This complicates things. Decisions about how many databases to use in the development process, how to ensure that development workspaces, test systems, and live deployments always use an appropriate database, and how to ensure that database changes and code changes don’t break each other occupy an increasing amount of time and energy.
Tom Czarniecki discusses one path through some of these issues. His suggestions do introduce some potential extra complexity in the code, though.
Zero-downtime deployments « No One Is Perfect.
An inspiring video/slide presentation all about how to do innovation. Lots of great ideas, well worth a watch/listen
A business needs to be really careful about extravagant claims, such as a service billed as “files forever” …
Sometimes I can’t resist the urge to grumble to colleagues when confronted with systems developed in a way I would not have chosen. Maybe I just need A change in attitude.
On the other hand, often the frustration comes from knowing that there is a better way, and I’m not sure that learning to love legacy code is that easy.
I’ll say up front that I have some major issues with the idea of estimation in agile processes. There are plenty of alternatives to traditional time/manpower estimation which are at least as useful in delivering real, useful results.
However, if you are working in a context which values estimation, Adrian Wible has some interesting points about whether it is wise to re-estimate incomplete stories each iteration
Adrian’s Tech Blog: The case against iteration based re-estimation.
Thinking of giving up trying because nothing seems to make a difference? Jason Yip has an interesting article about how a feeling of helplessness is easily learned, but can be overcome, even in software development.
Sorry to any of you who got a warning from Google about malicious software download. My server was hacked by a relatively dumb robot which put a malware distribution script at the top of some of the static html files. I assume you will be happy to know that I have cleaned out the infection and re-secured the server.
Again, apologies.
I really like the idea of GitHub Pages, and the way that it helps to manage the documentation for a project, bringing it in line with the same practices and tools used to manage the software development process. Of course, I would have been slightly happier if GitHub had chosen to use my own broadly-equivalent site-generation tool “Site Grinder” rather than Jekyll, though 
Most of the example sites linked from GitHub use html or textile for page layout, but I quite like Markdown, and wanted to use that instead. According to the Jekyll documentation, markdown is supported, but it took several attempts to get GitHub pages to recognize and transform my Markdown encoded project home page. The trick was to ignore the implication in the Jekyll documentation about file extensions. Example textile files have a “.textile” extension. Example HTML files have a “.html” extension, and so on. However, Markdown files only seem to work if they have a “.md” extension. Other common possibilities such as “.mkd” or “.markdown” are not recognised, and result in the raw file content being passed to the browser.
It’s been a long time coming, but I have finally decided that the master source code of the Stringtree and Mojasef Java libraries will now be hosted at GitHub rather than Sourceforge. I have been using git to manage the rest of my software for a long time now, but my two main projects have kept their place in subversion at Sourceforge. From now on, if you want the latest source code for either of these projects, please get it from github.
This move has several major advantages. The first is that you can now use GitHub’s “social coding” features to fork and modify the Stringtree and Mojasef code (and I’m always happy to discuss changes and improvements). The second advantage, and the one which tipped me over, is the ability to use git’s clever “submodule” support to include up-to-date Stringtree and Mojasef source code in other projects.
In the short term I will also be keeping the svn repositories up to date with significant changes. For now they are also the best place to find example code which uses Stringtree and/or Mojasef, but I plan to move all the examples over to GitHub in time.
Please let me know if you have any issues or questions about this move.