What Makes a ‘Machine’?

Paul Grenyer from Paul Grenyer


Defining what it is to be a machine is tricky to say the least. In everyday terms a machine is something man-made that performs an automated function. Computers are often referred to as machines but they are much more than the limited definition above. Perhaps, instead of trying to pin down exactly what a ‘machine’ is in the 21st century, it would be more pertinent to define what a machine is to us.

Isaac Asimov once described machines as ‘the true humanising influence’. In his mind machines would only be used to perform functions and carry out tasks that make life possible, leaving humans more time to do the things that make life worthwhile. Essentially through their ability to perform mundane but necessary actions, machines would allow us to indulge in every part of life outside basic functions, to allow us to enjoy what it is to be human. From a more modern writer’s point of view, machines have gone beyond their initial point of freeing us to taking us over. Stephen King focuses stories on machines gone mad in our increasingly automated world. In his film ‘Maximum Overdrive’, a classic Eighties trashy horror, any machine with moving parts becomes homicidal. Lawnmowers, Walkmans, vending machines and lorries are all affected by a passing comet’s radiation (don’t think about it too hard, it’s not meant to be taken seriously), come to life and start killing people. The only solution (spoiler alert) is to find a place where there are no machines, hide there and wait for the astrological phenomenon to pass. In the film our plucky heroes manage to find a sailing boat and a completely deserted island in the middle of a lake, but in reality finding a place without the presence of even the most basic machine would be practically impossible. In his book ‘Cell’, King uses the ubiquity of the mobile phone to reset the whole of humanity back to its animal instincts. Anyone who doesn’t have a cell phone at the time is soon killed and eaten by those that did. In his view technology and automation are so pervasive that they can plausibly (forgetting the green comet radiation) be used to cause global disasters affecting the whole of humanity. Not a virus or giant tidal waves, but machines we invented and built ourselves.

Conversely, anarchic cartoon South Park showed us that while we might think we don’t need machines, we still want them, especially when it comes to fulfilling mundane, everyday tasks. Characters in a recent episode complained that they were losing their jobs and being replaced by machines, but when given the chance to work as the electronic assistant ‘Alexa’ in the Amazon Dot device, they found the job so demeaning they quit. They realised that adding items to shopping lists and playing songs on demand were jobs that were beneath human beings and left Alexa to it. Who knew that technology would evolve to the point where an episode of South Park would prove a point made by Isaac Asimov nearly fifty years earlier?

Popular culture and plot devices aside, machines, of any kind, were created for a purpose – to make things better. Either to speed up processes, increase yield, reduce workload; to make things safer, quicker or more accurate. When we see a machine in this way, they become a tool to be used, rather than technology to be relied upon. We choose to use them, rather than to not be able to live without them. Rather than our future coming crashing down on us because of our reliance on our own creations, machines will hopefully become assistants to our way of life and give us more time to enjoy it. As Asimov said “It is machines that will do the work that makes life possible and that human beings will do all the other things that make life pleasant and worthwhile.”

Words: Lauren

Originally published: Naked Element

W.A.S.P. Reidolize The Crimson Idol

Paul Grenyer from Paul Grenyer

If I had to give someone an album which was an example of heavy hetal, The Crimson Idol would fulfil the criteria. It is the best heavy metal album by any band ever and the second best album by any band ever. It’s not thrash, progressive or power metal. It’s just heavy metal.

Right from the opening track it’s clear why WASP’s 1992 masterpiece is the ultimate heavy metal album. Line up changes have always plagued WASP and by the time of the Crimson Idol, long time guitarist Chris Holmes had left the band and only Blackie Lawless was left. Did it matter? No, Blackie writes everything anyway and on The Crimson Idol he played everything except drums and lead guitar.

The first thing you notice is the the drums. They’re different and significantly better and more intricate than on any other WASP album. Then there’s the lead guitar work. Chris Holmes is good, but he’s no Bob Kulick (brother of Bruce who played with KISS in the early 90s). Of course you’ve got that signature BC Rich guitar sound and when you combine all of this, Blackie Lawless's unmistakeable vocals and a heavy dose of the ‘higher you fly the further you fall’ concept album lyrics culminating in the The Idol, the best song with the best guitar solo ever, it makes for a magnificent album.

I’ve seen WASP several times, including them playing The Crimson Idol all the way through in Nottingham in 2007. The concern then was whether latest guitarist Doug Blair would be able to perform The Idol guitar solo live as well as Bob Kulick had on record. No worries there it turns out. So I was really looking forward to seeing it again in Norwich in 2017.

However, I’m increasingly of the opinion that Blackie Lawless and long time bass player Mike Duda are beyond giving a shit and just going through the motions. They barely move, Blackie spends quite a lot of time with his back to the audience and only speaks to us briefly in the encore which consists of just four songs. Neither smile. Blackie looks a mess. Mind you, so does most of the audience. Adding insult to injury and complete contempt for the audience, Blackie doesn’t switch to an acoustic guitar for The Idol. Playing those parts on electric guitar changes and degrades the song. Fortunately Doug Blair and new drummer Aquiles Priester are superb musicians and showmen throughout. The definition in the UEA LCR PA could have been better.

Doesn’t sound like I enjoyed it does? I did! It was fantastic. It was amazing to step back into my teenage years of 25 years ago. 2015’s Golgotha is the only good WASP album since 1995’s Still Not Black Enough and the title track was a fantastic bonus in the encore. WASP have consistently released albums over a long career. They don’t seem to be going anywhere soon, so if you get the chance, go and see them. You’re unlikely to be disappointed.



Pattern: Single CrUD Transaction

Paul Grenyer from Paul Grenyer

Software patterns have their roots in architecture. In 1978, Christopher Alexander published a book called ‘A Pattern Language: Towns, Buildings, Construction‘ (ISBN-13: 978-0195019193) about the patterns he’d discovered designing buildings. A pattern can be thought of as a tried and tested way of doing something which can be applied in different contexts.  Think about how the Observer or Visitor pattern is implemented across languages such as Java, Ruby and JavaScript, where the different language idioms dictate slightly different implementations of the same basic pattern.

Software Patterns became popular with the publishing of the Gang of Four book, “Design patterns: elements of reusable object-oriented software” (ISBN-13: 978-0201633610) in 1994. It contains a number of patterns, most of which every developer should know, even if it’s to know to avoid the likes Singleton. However, these aren’t the only patterns! Indeed, patterns are not created, they are discovered and documented. Whole conferences are dedicated to software patterns (http://www.europlop.net/), where delegates are encouraged to bring their pattern write-ups for appraisal by their peers and the experts.

In 2000 I joined the ACCU, a group for programmers who strive for better software. I was encouraged by another member to write for the group’s magazine, but I didn’t think I’d have anything to contribute that someone better hadn’t already thought of and written about. As I gained experience I found I had quite a lot to write about and to challenge.

In the same way you’d have thought that 23 years after the Gang of Four book most if not all of the software patterns had been discovered and documented. However, it appears not and I was very surprised to find that what I’m calling the “Single CrUD Transaction” pattern, although used by many, doesn’t appear to have been written up anywhere publically. I checked with industry experts and they weren’t aware of it being written-up either.

This is my first software pattern write up and where better to share it for the first time than Norfolk Developers Magazine?

Name

Single CrUD Transaction

Intent

To create, update and delete items in a datastore within a single transaction.

Problem

Sometimes it’s necessary to create, update and delete items in a datastore in a single transaction. Traditional web applications support create, update and delete in separate transactions and require the page to be reloaded between each action.

Modern web applications allow the items of a list to be created, updated and deleted in a browser without any interaction with the server or the underlying datastore. Therefore when the list is sent to the server side it must determine which items are new, which already exist and must be updated and which have been removed from the list and must be deleted.

One simple solution is to delete all of the items from the datastore and simply replace them with the list of line items passed from the browser to the server. There are at least two potential drawbacks with this approach:

  1. If the datastore (such as a relational database) uses unique, numerical ids to identify each item in the list, the size of the ids can become very big, very quickly.
  2. If the datastore (such as a relational database) has other data which references the ids of the items in the list, the items cannot be deleted without breaking the referential integrity.

Solution

The Single CrUD Transaction pattern gets around these drawbacks by performing three operations within a single transaction:

  1. Delete all of the list items from the datastore whose ids are not in the list passed from the browser to the server.
  2. Update each of the items in the datastore whose ids match ids in the list passed from the browser to the server.
  3. Create new items in the datastore for each item in the list passed from the browser to the server which do not yet have ids.
Each action is executed within a single transaction so that if any individual action fails the list is returned to its original state.

Applicability

Use the Single CrUD transaction pattern when:

  • Datastores cannot have new items added, existing items updated and/or items removed in separate transactions.
  • Creating new ids for each item in the list each time the datastore is modified is expensive or cumbersome.
  • Removing all the items of a list from a datastore and recreating the list in the datastore breaks referential integrity.

Advantages and Disadvantages

Advantages


  • Entire update happens within a single transaction.

Disadvantages


  • Three separate calls to the datastore within a single transaction.


On Share And Share Alike – student

student from thus spake a.k.

When last they met, the Baron challenged Sir R----- to a wager in which, for a price of three coins and fifty cents, he would make a pile of two coins upon the table. Sir R----- was then to cast a four sided die and the Baron would add to that pile coins numbering that upon which it settled. The Baron would then make of it as many piles of equal numbers of no fewer than two coins as he could muster and take back all but one of them for his purse. After doing so some sixteen times, Sir R----- was to have as his prize the remaining pile of coins.

Good Stories Assure the Architecture

Chris Oldwood from The OldWood Thing

One of the problems a team can run into when they adopt a more agile way of working is they struggle to frame their backlog in the terms of user focused stories. This is a problem I’ve written about before in “Turning Technical Tasks Into User Stories” which looked at the problem for smaller units of work. Even if the team can buy into that premise for the more run-of-the-mill features it can still be a struggle to see how that works for the big ticket items like the system’s architecture.

The Awkward Silence

What I’ve experienced is that the team can start to regress when faced with discussions around what kind of architecture to aim for. With a backlog chock full of customer pleasing functionality the architectural conversations might begin to take a bit of a back seat as the focus is on fleshing out the walking skeleton with features. Naturally the nervousness starts to set in as the engineers begin to wonder when the architecture is going to get the attention it rightly deserves. It’s all very well supporting a handful of “friendly” users but what about when you have real customers who’ve entrusted you with their data and they want to make use of it without a moments notice at any hour of the day?

The temptation, which should be resisted, can be to see architectural work as outside the scope of the core backlog – creating a separate backlog for stuff “the business does not understand”. This way can lead to a split in the backlog, and potentially even two separate backlogs – a functional and a non-functional one. This just makes prioritisation impossible. Also burying the work kills transparency, eventually erodes trust, and still doesn’t get you the answers you really need.

Instead, the urge should be to frame the architectural concerns in terms the stakeholder does understand, so that the business can be more informed about their actual benefits. In addition, when “The Architecture” is a journey and not a single destination there is no longer one set of benefits to aim for there are multiple trade-offs as the architecture evolves over time, changing at each step to satisfy the ongoing needs of the customer(s) along the way. There is in essence no “final solution” there is only “what we need for the foreseeable future”.

Tell Me a Story

So, what do I mean by “good stories”? Well, the traditional way this goes is for an analyst to solicit some non-functional requirements for some speculative eventual system behaviour. If we’re really lucky it might end up in the right ballpark at one particular point in the future. What’s missing from this scene is a proper conversation, a proper story – one with a beginning, a middle, and an end – where we are today, the short term and the longer term vision.

But not only do we need to get a feel for their aspirations we also need quantifiable metrics about how the system needs to perform. Vague statements like “fast enough” are just not helpful. A globally accessible system with an anticipated latency in the tens of milliseconds will need to break the law of physics unless we trade-off something else. We also need to know how those exceptional events like Cyber Monday are to be factored into the operation side.

It’s not just about performance either. In many cases end users care that their data is secure, both in-flight (over the network) and at rest, although they likely have no idea what this actually means in practice. Patching servers is a technical task, but the bigger story is about how the team responds to a vulnerability which may make patching irrelevant. Similarly database backups are not the issue it’s about service availability – you cannot be highly available if the loss of an entire data centre potentially means waiting for a database to be restored from scratch elsewhere.

Most of the traditional conversations around non-functional requirements focus entirely on the happy path, for me the conversation doesn’t really get going until you start talking about what needs to happen when the system is down. It’s never a case of “if”, but “when” it fails and therefore mitigating these problems features heavily in our architectural choices. It’s an uncomfortable conversation as we never like discussing failure but that’s what having “grown up” conversations mean.

Incremental Architecture

Although I’ve used the term “story” in this post’s title, many of the issues that need discussing are really in the realm of “epics”. However we shouldn’t get bogged down in the terminology, instead the essence is to remember to focus on the outcome from the user’s perspective. Ask yourselves how fast, how secure, how available, etc. it needs to be now, and how those needs might change in response to the system’s, and the business’s growth.

With a clearer picture of the potential risks and opportunities we are better placed to design and build in small increments such that the architecture can be allowed to emerge at a sustainable rate.

SE-Radio interviews Ron Lichty, must listen for development managers

Timo Geusch from The Lone C++ Coder's Blog

The Software Engineering Radio podcast has just published an episode with an interview with Ron Lichty. It is well worth a listen if you’re thinking about moving from development into management or already are amongst the development managers. Unfortunately there is only so much that can be packed into an hour’s worth of a podcast, […]

The post SE-Radio interviews Ron Lichty, must listen for development managers appeared first on The Lone C++ Coder's Blog.

Event: Burkhard Kloss on The Ethics of Software & Panel: Talking to the clouds

Paul Grenyer from Paul Grenyer


Event: Burkhard Kloss on The Ethics of Software & Panel: Talking to the clouds

When: 6 November 2017 @ 6.30pm

Where: Whitespace, 2nd Floor, St James Mill, Whitefriars, Norwich, NR3 1TN

RSVP: https://www.meetup.com/preview/Norfolk-Developers-NorDev/events/239616865

The Ethics of Software - some practical considerations
Burkhard Kloss
@georgebernhard

As Uncle Bob pointed out, software is everywhere, and without software, nothing works.

That gives us great power, and – as we all know – with great power comes great responsibility.

We have to make choices every day that affect others, sometimes in subtle and non-intuitive ways. To mention just a few:

  • What logs should we capture?
  • How does that change if we have to hand them over to the government?
  • Are our hiring practices fair? Are we sure about that?
  • Is there bias in our algorithms that unfairly disadvantages some groups of people?
  • Is the core function of our software ethical? How about if it’s deliberately misused?

I hope to raise a few of these questions, not to provide answers – I don’t have any – but to stimulate debate.

Burhard Kloss

I only came to England to walk the Pennine Way… 25 years later I still haven’t done it. I did, though, get round to starting an AI company (spectacularly unsuccessful), joining another startup long before it was cool, learning C++, and spending a lot of time on trading floors building systems for complex derivatives. Sometimes hands on, sometimes managing people. Somewhere along the way I realised you can do cool stuff quickly in Python, and I’ve never lost my fascination with making machines smarter.


Panel Discussion: Talking to the clouds

Conversational computing, the ability to talk to, an interact with a computer via voice, is becoming more and more prevalent. Most of us now have access to an intelligent assistant like Siri or Alexa, and how we interact with the devices is being defined. But are we going in the right direction. Should we be treating these devices as just "dumb computers", or should we speak to them as we do to other people?

Our panel of experts will discuss this topic with input from the audience as we look at one of the many areas where the question is not "can we?", but "should we?".

I think I’ve worked out why Uni is so stressful.

Samathy from Stories by Samathy on Medium

The study environment generates panic.

I’m back at University after taking a year out to work as a professional software developer.

I got back and instantly found everything so incredibly stressful.
Moreso than I felt before during my earlier years at University and certainly more than I’d felt at all during my work years.
It took me a couple of weeks, but I think I’ve figured out a few reasons why making the transition from professional work, back to being a student is so tough.

Fragmented days

The first, and possibly biggest issue I’m having is the fragmented days.

Most days during the week I have some lectures. Often, it’s two or more different modules on the same day, sometimes in different buildings.

The problem with this is that I spend the whole day wildly context-switching .
Not just switching between discrete tasks, like one might do at work, but entirely different mindsets, technologies, and problems.

I’ll be switching from thinking about my Concurrent and Real Time Systems course, its coursework, and the project I’m making for that. Then break for a couple of hours, during which I might have a meeting or spend time working on plans for the society I lead before switching into the next module’s session (maybe OpenSource Development for example) .

I spend the whole day never spending more than about two hours on a particular module or task before switching to another, never finishing anything before having to move onto another thing.

To exacerbate this is that I might also be moving my physical location as well as my mental one. Having to get up and move across campus for the next session when I haven't reached a good point of closure on the one I’m working on.

This way of working makes me feel like I never manage to finish things. I feel like the end of a particular piece of work is never in sight because I can’t work on it long enough at any one time to feel like I’ve achieved something or gotten closer to completion.

Taking your work home

Because I never manage to get anything substantial done during the working day, I have to bring my work home with me.

Taking one’s work home is a fundamental part of University life, as every student will know.
You are never finished, you’ve always got something you should be doing right now, instead of relaxing or seeing friends.

This results in whenever I’m not working towards my degree, I feel like I should be.
I feel like I’m wasting my time doing whatever else I’m doing because I should be working.

This leads to a lot of stress, because one can never relax properly when they’ve always got work on the mind.

Having to wait for the information

While this might not affect other students who have less prior knowledge and experience on their topic than myself, having to wait to be told things because of the plan the course leader set out is incredibly frustrating.

For the past year, I’ve been used to having the project brief set out and being released to go and produce the project (including, of course, doing all the planning and research needed before implementation).

At University, you know you’re going to have to do something but the lecturers hold off on telling you exactly what you need to be producing.
Instead, they tend to release a new piece of information every week. So no matter how much you already know, or how fast you got the work for this week finished, you’re not going to know what you need to do next until the next scheduled lecture.

This results in me knowing that there's a deadline in the future, but having no idea what I need to be doing to make sure that I manage to hit that deadline with everything finished.

In business, you get told what you’re doing and it’s up to you to plan your time and get done what you need to get done to make sure the project hits the deadline.
Yes, there are hold ups that you can’t always get around. But, because you know the whole scope of the project and what you need to get finished, there is normally something else you can work on so you’re not wasting time.

General stressful environment

A big factor that contributes to my general stress is feeling the stress of everyone around me.

University is so full of people who are in no way relaxed. People who are out of their depths. Lecturers reminding you of the deadlines so you don’t forget.

University just feels buzzing with stress-fuelled energy, and it doesn't help anyone.

Maybe it’s me?

But also, it might just be me.
I’m stressed already and I’m only a couple of weeks into term.
My deadlines feel like they’re on top of me, even though they’re all in November.
My society needs constant attention and planning (with help from a fantastic committee)
I moved back into my parents and had to store most of my stuff.
I need to plan my Final Year Project, somehow (I have no supervisor yet)
I’m speaking at some conferences soon.
I haven’t got any work, and not much money.
Soon I have to start proper work with Coventry Pride again.

So yeah, a lot on my plate and University is not helping much.

Thanks for reading this a-bit-of-a-rant post.

How to read water

Jon Jagger from less code, more software

is an excellent book by Tristan Gooley (isbn 978-1-473-61522-9). As usual I'm going to quote from a few pages:
One of the universal truths of human observation is that we see more of what we expect to see and less of what we don't expect to see.
Much of my work is not about teaching people to see things that are hard to see, but in showing them how to notice the things that hide in plain sight.
It did not take sailors long to work out that a ship that carries too much may be vulnerable in heavy seas, but sailors were rarely the ones to make the decision about how much cargo a ship could safely carry. The merchants making the profit would have had a different view to the deckhand, especially if the trader never set foot on the vessel. This led to a wrestle between greedy traders and cautious captains that lasted centuries. The first attempts to regulate how much a ship could carry go back over four thousand years to ancient Crete.
Samuel Plimsoll, a nineteenth-century English politician, realized that a low freeboard height can present a problem, but he also appreciated that it becomes the solution if we take a very keen interest in it. In other words, we can tell if there is too much cargo in the boat by looking much more carefully at how high the water rises up the side of the hull. And the easiest way to do this is by drawing a ruler on the side of the ship, calibrated according to an architect's or engineer's understanding of the boat. These lines, which became known as Plimsoll Lines, were such a simple and brilliant success that they became law and proliferated around the world.
From 1833, when the first tide tables were produced by the Admiralty, the emphasis shifted from looking, thinking and understanding, to depending on tables of others' measurements.
There is a stange truth in the profile of beaches: they have evolved in a physical sense to be a near ideal shape to defend themselves against the onslaught of the sea. This means that almost any attempt to engineer a 'solution' to what nature is trying to achieve has as much chance of backfiring as working.
Many sailors use little pieces of fabric, nicknamed 'tell-tails', that are tied to the sails and stays (the wires that give the mast stability), to offer a constant visual reminder of what the wind is doing.
Once the depth of the water is half the wavelength of the waves, it effectively cramps the motion of the waves and it is this that slows them down.
Sailors dislike precision almost as much as they like bureaucracy.
Rivers do not run straight for more than ten times their own width.
There will be an alternating combination of quick water and much slower water and this always happens in a certain way. The quick patches are knowns, perhaps onomatopoeically, as 'riffles' and the slower areas are known as pools. If there is no human tinkering with a river's flow, then there will be a riffle-pool sequence for every stretch of river that is fives times its width.
It is typical for the water at the sides of a river to be travelling at only a quarter of the speed of the water in the centre. The river is being slowed by two things at its sides; when it comes into contact with banks it is slowed by friction and it is also slowed by the shallowing at the sides.
A stream is just a river you can step over.
Swell is the name of the waves that have enough energy to travel beyond the area of wind.