L B Paine Ltd

Clojure tutorials with klipse

2016-03-23T11:45:51+00:00

I’ve attended London Clojure Dojo today, and an overwhelmingly appealing option was something with klipse.

So here’s an attempt.

Note that each clojure block is editable. And will instantly evaluate as you type (just that sexp). A single repl is shared by all the blocks on this page. You need to modify a block to run the block.


(+ 1 4)

Define a function that doubles it’s argument.

(defn dble [n] (* n 2))

Call the function from above!

(dble 3)

How do I do string interpolation? You don’t, just call str on a list

(str "Something " "about " "the " "way")

(defn hello [name] (str "hello, " name))

(hello "john")

A clojure function will evaluate to it’s last item

(defn broken-hello [name] "hello, " name)

(broken-hello "john")

How about conditionals?

(defn hate-john [name] (if (= name "john") "Go away john" (str "Hello, " name) ))

(hate-john "john")

(hate-john "jerry")

True and false

Truthy things

(= true true)

(= false true)

(= false false)

(= false nil)

(= nil nil)

A single quote before parens says “Don’t treat this list as a function call, it is really a list!”. An empty list is ‘()

(= '() '())

Vectors are like arrays in other languages, but without the horrific mutability stuff. You want them instead of lists when you want fast-indexing to the middle of the datastructure. Empty Vectors are ‘[]. Note that we’ve already seen vectors above, clojure uses them for parameter lists in functions!

(= '[] '[])

Let’s compare a non-empty list to a non-empty vector

(= '[123 456 789] '(123 456 789))

On the friction between agile and traditional approaches in software delivery

2016-03-23T11:45:51+00:00

I’m an Agile pragmatist.

What do I mean by that? I find that for practically every piece of software I’ve ever written, or seen written, agile practices will deliver a solution that is a better fit for the customers needs, with something valuable in a shorter timeframe, and with happier developers than a ‘traditional’ Big Upfront Design (BUD) approach, e.g. waterfall.

But, and it’s an important but, I’m not ruling out that there’s a class of problems where BUD has it’s place.

What is that place?

To answer that, let’s take a side to to Value Stream Mapping Simon Wardley at QCon 2015 gave a talk that touched on this very topic. An introduction to value stream mapping, I wish you could have seen it, or that they had made the full 40 minute talk public, you will have to make do with this 13 minute flash talk from OSCON 2014. It managed to be funny, insightful, and enlightening in just one talk.

The evolution of technologies

One of the key takeaways for me from that talk was that all technologies go through an evolutionary process. Overtime they will move from Genesis, through custom built to product, and eventually, to commodity. He uses the example of light sources:

We started out with a candle - eventually we get Edison’s light bulb, but that requires custom installers, and eventually we get to LED downlighting that you can install yourself.

We also had it with electricity itself, 3 thousand years ago the Egyptians had begun exploring electricity with Seleucian jar type things (a myth, apparently), then with Tesla and Edison we get the shift to commodity electricity to the wall through Westinghouse.

The point he made that I found so compelling was that on the left, in emergent technology, agile fits brilliantly – we’re dealing with the unknowns, the unknown-unknowns – but over on the right, as things become commoditized, we have more certainty, predictions/estimations are more reliable. Those traditional project management approaches like Waterfall and PRINCE2 make sense in this space. All the steps are known, and it’s just a matter of following them until you’re done.

10 years ago Jeff Atwood was blogging on this very topic in “Is software Development like Manufacturing”. While I’m a huge fan of the realisations and improvements that have come LEAN, misapplying project management from manufacturing to discovery/engineering pursuits on the left of the graph is a long-standing problem.

Variability is the enemy in manufacturing; in software, it’s the reason we get up in the morning. Every worthwhile software development project is a custom one-off job for a unique problem.

Requirements are the bread and butter of manufacturing; in software, we rarely have meaningful requirements. Even if we do, the only measure of success that matters is whether our solution solves the customer’s shifting idea of what their problem is.

– Jeff Atwood

Patrick Mockridge — CEO of engzig.com — touches on the same topic though a little more tongue-in-cheek.

I think a lot of discomfort in software development comes from the friction in the interaction between these two worlds. In the traditional camp you’ve got business managers, possibly from an operations background, used to performing actions such as getting a trade to settled. And in the other you’ve got ideological ‘agile’ developers who can be resistant to estimating anything.

Frequently the business managers become project managers, or sponsors of projects to replace some, or all of the process they’re used to performing. Never mind the potential for conflict-of-interest (“we’re automating their jobs!”), if you’re lucky enough to have one that buys into the development effort, in my experience it’s likely that they think software development fits the mould of widget stamping. Because they’re used to performing to measurable targets, and motivating their people to achieve them, they think software development can be hurried the same way.

Simon Wardley shows us that some activities we class as Software Development may have evolved to occupy that product or commodity side of the chart, these are the places where the ‘software laborer’ can exist. It’s the rote, copy/paste expansion of functionality on systems were those functions haven’t been made so simple the user can click themselves. However, these are unlikely to be positions we want continue to occupy if we want strategic business advantage.

This is where I believe it’s important to do cost/benefit analysis of any improvement, and apply it to a value stream (different to a value chain map!) — Checkout the amazing work done by GDS for the Criminal Justice System — But having done that analysis, don’t consider your plan set in stone.

The other important thing to realise is that the distance between genesis and commodity can be huge. I’ve seen the difficulty/amount of work involved in bridging that gap under-estimated time and again. A solution to that is to accept it’s not necessary to do that bridging yourself. Choose carefully and open-source where you can to build a community and the evolution will occur given time. Spend your effort on building the novel.

My approach: agile pragmatism, and the agile as the application of scientific method to software development

2016-03-03T12:48:00+00:00

Agile pragmatism

Ideologies are bad, m’kay? Instead aim for strong opinions, weakly held

Blindly adhering to any methodology without adapting is not a good thing. There are no truths handed down from on-high, just the best thing we know right now.

Agile is the scientific method

I tend to view agile done well as the application of the scientific method to software development. Not just the writing of the code, but the whole process around it.

For any piece of code you’re about to write:

Think (form, alter, refine or reject hypothesis)
Now think how to measure it
‘Write’ your test (create your experimental protocol)
Execute test - see it fail
Write the code
Execute tests - see them pass
Refactor
Goto beginning

The feedback loop is the key similarity, and the thing that distinguishes either from a ‘classic waterfall’ approach. In practice, in both applied science (say Medical Research), and coding, people seem to forget the ‘think’ step. And when formulating tests, sometimes they seek to prove their hypothesis, rather than seek to prove it wrong. I guess that’s human nature.

It’s remarkable; when I’m pairing with a dev — maybe they’re new to TDD, maybe they’ve been going through the motions for years — how much of a revelation they find my suggestion of testing the negatives, of proving yourself wrong. It’s a mindset shift, but it’s a powerful one.

Does this slow you down? It depends on your timescale, your familiarity with the approach, and the complexity of the test necessary to prove your hypothesis. On a short timescale of between writing the functioning code, and seeing the results from a run - it doesn’t necessarily payoff - as is the case with much TDD. As you get better at formulating meaningful tests, exploring the boundaries and the negatives, and the failure modes, you’ll find your pace accelerates due to the harness(es) you have built.

Once you adopt the approach, and practice, it becomes seconds nature. You’ll begin to feel uncomfortable without a solid testing approach (I almost said Framework, but you can adopt the approach without the framework). You don’t need a framework, because for somethings you do you may not need the regression tests that would grow out of it. You were just doing exploratory testing to establish what should be added to the regression set.

The key is continual feedback. And perpetual refinement. Also, don’t be afraid to reject long held hypothesis if something is proven to fit the problem better (I should write something on committing the Sunk Cost Fallacy - and institutional inertia).

Change just one thing

The other thing I always try to limit myself to: Change just one thing!

In any given development cycle, change just one thing. This can be a difficult habit to get into. We want to feel productive. Plenty of developers are mighty smart, they are confident in their abilities. They’ll try and tackle a ‘couple of things’. I don’t mean features - though I’ve seen that too. I mean in unit testing, did you just add something that forces you to introduce an if? Then only add the code for one branch: No matter how simple it seems to do the other branch. Focus only on the behaviour you’re driving with tests.

Summary / Conclusion / tl;dr;

Agile development done well IS the scientific method applied
Testing pays off sooner than you expect
Don’t just test the positive cases, come up with the negatives

I Nabbed the scientific method picture here, via wikipedia ↩

Digging a hole

2016-03-02T21:03:37+00:00

There’s a tale of how to dig a hole.

If you watch a professional dig a large hole they don’t just dig straight down. They build themselves a little set of steps. First one step, then they’ll stand on that one to dig the next, and so on until they reach a depth they’re aiming for, and they’ll dig away the steps.

Don’t be afraid to dig away your steps (intermediate tests) once they’ve got you where you’re going. Developers are often reluctant to delete code, even if it was code they just wrote themselves.

If you’re afraid of losing something worthwhile, commit it to version control. The delete it.
If it was code written by someone else:
- is it obvious this test is now not worthwhile? Delete it.
- is the original developer still available to you? - chat to them about the purpose of the tests. Is that purpose still necessary. Then delete it.
- are they not here? What are you afraid of? Delete it.

I am NOT advocating deleting tests willy-nilly. I’m talking about trivial, starter tests that have outgrown their usefulness. Stuff like:

Constructor tests (by the time you’ve got a test harness you’ll have made test constructors that define this behaviour)
Exploratory tests

Once they’ve been committed, let them go.

People will be able to find them in the future with

git log -S"<magic line of code that I had committed 6 months ago>"

My new series: coding, refactoring, and TDD as the application of the scientific method

2016-02-24T11:31:09+00:00

Over the last several years, a large part of my role has been mentoring more junior developers. They have frequently encouraged me to blog about my approaches, and I’ve finally decided to give into the pressure.

So, I’ll be starting a series of posts about the sorts of code-smells, and organisational-smells I’ve seen in the wild, the approaches I might take to fix them, and why I’d use those approaches. I expect that largely it will be an effort for me to crystallize my thinking, and also prove a useful resource when I’m next teaching a concept - I won’t have to jump to a whiteboard, I’ll just be able to point to something here.

Almost everything you’ll read here owes a huge debt of gratitude to the Master Craftsmen:

Michael Feathers — Refactoring Legacy Code
Martin Fowler Refactoring Buy the book!
Uncle Bob Martin — Everything, everywhere, but Clean Code is a great start
Andrew Hunt And Dave Thomas Pragmatic Programmer
Roy Osherove — [The art of unit testing] (old but good!)

I’m in no way suggesting you should only buy these from Amazon, but they’re a very convenient source.

Development Musings

23 Mar 2016 » Clojure tutorials with klipse
23 Mar 2016 » On the friction between agile and traditional approaches in software delivery
24 Feb 2016 » My new series: coding, refactoring, and TDD as the application of the scientific method

Fun with webcam mics and skype

2013-06-01T21:53:29+01:00

Just spent some time troubleshooting my parents skype connection with me.
They could hear me, I couldn't hear them. They had this problem intermittently with some people.
After messing around with updating drivers, trying different mics etc, a quick google for logitech e3500 found this link:
http://forums.logitech.com/t5/Video-Chat-Applications-Non/E3500-microphone-not-working/td-p/326579

and the useful message:

I've just had a client with a similar E3500 volume problem. After some experimenting it appears that if the input volume is set above 90-95% the E3500 microphone stop recording. So long as the input volume remains below 90% it works fine.

I can not be sure if this is new behaviour or started following recent updates.

I shall continue looking for other information about this issue.

Setting the mic levels to less than 90 and ALSO changing the skype settings from auto level and setting them lower, and then re-setting to auto and suddenly there's sound. Marvellous.

It's a wonderful vintage ball pics

2011-12-04T08:35:20+00:00

tallnottom's photostream on Flickr.