Posted on

New website and chips, please

Products, the Universe and Everything from Products, the Universe and Everything

At Riverblade we know how to celebrate finishing a project

If you are reading this you might have noticed that the Riverblade website has undergone a bit of a redesign.

This is something we've been working on for a little while in the background, and we think it's probably now at least good enough to let loose on the world. We hope that you find the new responsive website to be an improvement on the old one.

Template aside, the design and implementation was done in-house, so it's entirely our own work and therefore any bug/content fixes should be relatively quick (as an aside, we did contract out a redesign a while back, but we never released it because we weren't happy with the design the external consultancy produced).

Along with the new design, we've also moved most of the content to a new domain (riverblade.co).

We've tried to make all of the redirects automatic, but needless to say if you discover any broken links, typos etc. please do let us know.

(and in case you are wondering: we have indeed been known to celebrate finishing a project with Prosecco and fish and chips).

Posted on

Pennies From Heaven – baron m.

baron m. from thus spake a.k.

Sir R-----, my good friend! Come shake the snow from your boots and join me by the hearth for a draught of warming spirits!

And will you also join me in a wager whilst you let the fire chase the chill from your bones?

Fine fellow! Stout fellow!

I have in mind a game that reminds me of my raid upon the vault of Heaven, which I mounted in order to make amends to the Empress for my failure to snatch the Amulet of Yendor from the inner circle of Hell.
Posted on

Keybase chat bot in 10 lines of bash

Andy Balaam from Andy Balaam's Blog

I’ve been getting very excited about keybase.io recently, not least because it offers secure conversation, and you can have bots.

I wrote a quick bot to simulate Arnold Schwarzenegger which I thought I’d share to demonstrate how easy it is. It is based on the keybase command line tool (which comes with the desktop client as standard) and jq, the brilliant command-line JSON manipulator.

For this to work, you need to have the keybase command installed and working, and you need jq.

Here’s the bot:

#!/bin/bash
CHANNEL=mychannel
keybase chat api-listen | while read L; do
{
    OUT=$(jq --raw-output 'select(.type == "chat")|select(.msg.content.text.body|startswith("!arnie "))| .msg.content.text.body | "*" + ltrimstr("!arnie ") + "*"' <<< "$L")
    if [ "${OUT}" != "" ]; then
    {
        keybase chat send "${CHANNEL}" "${OUT}"
    }; fi
}; done

and here's it working:

andy> !arnie Do eet do eet now!!!
andy> Do eet do eet now!!!

Note: here the bot is pretending to be me. To do this nicely, you will want a different account for the bot, but you get the idea.

Obviously, I am now working on a comprehensive bot framework in Rust. Watch this space.

Posted on

An (agile) coach’s dilemma

Allan Kelly from Allan Kelly Associates

iStock-521796758s-2019-02-13-14-54.jpg

I’d never met the team before. It was a small company in Cornwall and the big boss man was away on holiday that week. They took me upstairs to the meeting room. We talked for about an hour and I could tell there was something on their mind.

Eventually one of them asked:

“we have this question we’ve been talking about for ages we’d like you to help with.”

This was it, the $64,000 question.

“Ask” I said.

“Well… should we be using source code control?”

To some of you this might sound funny, to others shocking, but believe me, on average I meet one team a year who don’t use source code control. On this day I had two voices, one in each ear.

The voice in my left issue said:

“You are only a coach, you are here to help them make their own decisions. Talk about their goals, what they want to achieve, find out if they think source code control could help them. Let them explore why it might be the wrong choice.”

The voice in my other ear said:

“Jesus Christ…”

On the one hand the (agile) coach is there to help the team reach their best. The coach isn’t there to tell them what to do, the people – the team – are the experts in what they do, and they are self-organising. The coach is there to help them unlock their superhero powers.

On the other hand: the coach has done this before. If they are any good they have not only worked with many teams before and read many reports in books and blogs but they wrote the reports, their teams are in the case studies. The team may well be experts in Java, JavaScript, inertial navigation, limb-replacements or whatever but the coach is the expert in agile. The coach is there to teach.

If you’ve read about coaching in other contexts you might recognise this as a question of non-directive coaching v. directive coaching. Agile, and agile coaching has never really come to terms with that differentiation.

As a coach you have next to no authority, all you can hope is that the coachees come to respect you and trust you enough to follow your suggestions. But then, maybe you shouldn’t be suggesting anything?

But if you claim to know anything – about coaching, about agile and heaven forbid software development – is it right to hold back on them when you know the answer? Isn’t it dishonest not to say what you know – or at least sincerely believe – to be true?

And if you can see what they need to do, don’t tell them but work to help them see that answer, well… thats just manipulation isn’t it?

When do you allow free will and when do you railroad?
When do you unlock self-knowledge and when do you teach?
When do you let people take decisions you can see are mistakes?
When do you know facts that will help? And when are you just full of the same biases as everyone else?

Take the documentation question: classically trained developers who have never worked in high-performing teams commonly see documentation as the answer to so many questions:

Question: How do we make sure requirements are clear?
Answer: Documentation

Q: How do we help new recruits find their way around the system?
A: Documentation

Q: How do we keep track of the code design?
A: Documentation

Q: How do we agree which bugs to fix?
A: Documentation

Q: How do we communicate with customers?
A: Documentation

Some people just don’t know what they don’t know.

I too was trained that documentation was the answer to these questions and more, I too saw the lack of documentation as a major problem when I started work somewhere new. It took time (and Railtrack PLC) for me to realise documentation wasn’t the answer, it was John Seely Brown and Julian Orr who help me to realise documentation was a problem, and it took Capers Jones to make me see the cost of documentation.

But should I impose my view of documentation on a team? – should I even be making them see the world as I do?

Ultimately the team are self-organizing. They have the right to document, or not to document, and they can decide to ditch the coach. (Being an agile coach can be a high risk profession.)

Ultimately they are allowed to self-organize long (seated) morning meetings. They are allowed to reject TDD, BDD, CD, CI and just about every other agile practice.

And you know what? They could be right.

Coaches need to be self-aware and with that self-awareness comes self-doubt. Just because a team doesn’t follow the normal rule book doesn’t mean they are wrong. They could have a better solution. They could have a solution that works better in their context.

Back in Cornwall, I paused for a few moments while the angels on my shoulders argued their case. Then I said:

“Put it like this, without source code control I wouldn’t get out of bed in the morning.”

With that question settled I moved onto the issues. What problems would it create? Why wouldn’t you use source code control? What is the worst that could happen? What difference would big boss man see?

Arse about face really but it worked. The following morning I walked into their office and found them checking everything in.

Eight years later that small company has grown more than 20 fold: would they have done that if I had answered differently? Might they have done even better? Did I make a difference or was it all them?

But I still face dilemmas like that everyday I’m “coaching”.

Like this post?

Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

The post An (agile) coach’s dilemma appeared first on Allan Kelly Associates.

Posted on

Offer of free analysis of your software engineering data

Derek Jones from The Shape of Code

Since the start of this year, I have been telling people that I willing to analyze their software engineering data for free, provided they are willing to make the data public; I also offer to anonymize the data for them, as part of the free service. Alternatively you could read this book, and do the analysis yourself.

What will you get out of me analyzing your data?

My aim is to find patterns of behavior that will be useful to you. What is useful to you? You have to be the judge of that. It is possible that I will not find anything useful, or perhaps any patterns at all; this does not happen very often. Over the last year I have found (what I think are useful) patterns in several hundred datasets, with one dataset that I am still scratching my head over it.

Data analysis is a two-way conversation. I find some patterns, and we chat about them, hopefully you will say one of them is useful, or point me in a related direction, or even a completely new direction; the process is iterative.

The requirement that an anonymized form of the data be made public is likely to significantly reduce the offers I receive.

There is another requirement that I don’t say much about: the data has to be interesting.

What makes software engineering data interesting, or at least interesting to me?

There has to be lots of it. How much is lots?

Well, that depends on the kind of data. Many kinds of measurements of source code are generally available by the truck load. Measurements relating to human involvement in software development are harder to come by, but becoming more common.

If somebody has a few thousand measurements of some development related software activity, I am very interested. However, depending on the topic, I might even be interested in a couple of dozen measurements.

Some measurements are very rare, and I would settle for as few as two measurements. For instance, multiple implementations of the same set of requirements provides information on system development variability; I was interested in five measurements of the lines of source in five distinct Pascal compilers for the same machine.

Effort estimation data used to be rare; published papers sometimes used to include a table containing the estimate/actual data, which was once gold-dust. These days I would probably only be interested if there were a few hundred estimates, but it would depend on what was being estimated.

If you have some software engineering data that you think I might be interested in, please email to tell me something about the data (and perhaps what you would like to know about it). I’m always open to a chat.

If we both agree that it’s worth looking at your data (I will ask you to confirm that you have the rights to make it public), then you send me the data and off we go.

Posted on

Performance of Java 2D drawing operations (part 3: image opacity)

Andy Balaam from Andy Balaam&#039;s Blog

Series: operations, images, opacity

Not because I was enjoying it, I seemed compelled to continue my quest to understand the performance of various Java 2D drawing operations. I’m hoping to make my game Rabbit Escape faster, especially on the Raspberry Pi, so you may see another post sometime actually trying this stuff out on a Pi.

But for now, here are the results of my investigation into how different patterns of opacity in images affects rendering performance.

You can find the code here: gitlab.com/andybalaam/java-2d-performance.

Results

  • Images with partially-opaque pixels are no slower than those with fully-opaque pixels
  • Large transparent areas in images are drawn quite quickly, but transparent pixels mixed with non-transparent are slow

Advice

  • Still avoid any transparency whenever possible
  • It’s relatively OK to use large transparent areas on images (e.g. a fixed-size animation where a character moves through the image)
  • Don’t bother restricting pixels to be either fully transparent or fully opaque – partially-opaque is fine

Opacity patterns in images

Non-transparent images drew at 76 FPS, and transparent ones dropped to 45 FPS.

I went further into investigating transparency by creating images that were:

  • All pixels 50% opacity (34 FPS)
  • Half pixels 0% opacity, half 100%, mixed up (34 FPS)
  • Double the size of the original image, but the extra area is fully transparent, and the original area is non-transparent (41 FPS)

I concluded that partial-opacity is not important to performance compared with full-opacity, but that large areas of transparency are relatively fast compared with images with complex patterns of transparency and opacity.

Numbers

Transparency and opacity

Test FPS
large nothing 90
large images20 largeimages 76
large images20 largeimages transparentimages 45
large images20 largeimages transparent50pcimages 34
large images20 largeimages transparent0pc100pcimages 34
large images20 largeimages transparentareaimages 41

Feedback please

Please do get back to me with tips about how to improve the performance of my experimental code.

Feel free to log issues, make merge requests or add comments to the blog post.

Posted on

Performance of Java 2D drawing operations (part 2: image issues)

Andy Balaam from Andy Balaam&#039;s Blog

Series: operations, images

In my previous post I examined the performance of various drawing operations in Java 2D rendering. Here I look at some specifics around rendering images, with an eye to finding optimisations I can apply to my game Rabbit Escape.

You can find the code here: gitlab.com/andybalaam/java-2d-performance.

Results

  • Drawing images with transparent sections is very slow
  • Drawing one large image is slower than drawing many small images covering the same area(!)
  • Drawing images outside the screen is slower than not drawing them at all (but faster than drawing them onto a visible area)

Advice

  • Avoid transparent images where possible
  • Don’t bother pre-rendering your background tiles onto a single image
  • Don’t draw images that are off-screen

Images with transparency

All the images I used were PNG files with a transparency layer, but in most of my experiments there were no transparent pixels. When I used images with transparent pixels the frame rate was much slower, dropping from 78 to 46 FPS. So using images with transparent pixels causes a significant performance hit.

I’d be grateful if someone who knows more about it can recommend how to improve my program to reduce this impact – I suspect there may be tricks I can do around setComposite or setRenderingHint or enabling/encouraging hardware acceleration.

Composite images

I assumed that drawing a single image would be much faster than covering the same area of the screen by drawing lots of small images. In fact, the result was the opposite: drawing lots of small images was much faster than drawing a single image covering the same area.

The code for a single image is:

g2d.drawImage(
    singleLargeImage,
    10,
    10,
    null
)

and for the small images it is:

for (y in 0 until 40)
{
    for (x in 0 until 60)
    {
        g2d.drawImage(
            compositeImages[(y*20 + x) % compositeImages.size],
            10 + (20 * x),
            10 + (20 * y),
            null
        )
    }
}

The single large image was rendered at 74 FPS, whereas covering the same area using repeated copies of 100 images was rendered at 80 FPS. I ran this test several times because I found the result surprising, and it was consistent every time.

I have to assume some caching (possibly via accelerated graphics) of the small images is the explanation.

Drawing images off the side of the screen

Drawing images off the side of the screen was faster than drawing them in a visible area, but slower than not drawing them at all. I tested this by adding 10,000 to the x and y positions of the images being drawn (I also tested subtracting 10,000 with similar results). Not drawing any images ran at 93 FPS, drawing images on-screen at 80 FPS, and drawing them off-screen only 83 FPS, meaning drawing images off the side takes significant time.

Advice: check whether images are on-screen, and avoid drawing them if not.

Numbers

Transparency

Test FPS
large nothing 95
large images20 largeimages 78
large images20 largeimages transparentimages 46

Composite images

(Lots of small images covering an area, or a single larger image.)

Test FPS
large nothing 87
large largesingleimage 74
large compositeimage 80

Offscreen images

Test FPS
large nothing 93
large images20 largeimages 80
large images20 largeimages offscreenimages 83

Feedback please

Please do get back to me with tips about how to improve the performance of my experimental code.

Feel free to log issues, make merge requests or add comments to the blog post.

Posted on

Throwing mud at a wall

Allan Kelly from Allan Kelly Associates

iStock-515277657small-2019-02-6-18-44.jpg

Throwing mud at a wall is a metaphor I use again and again. As a description of what I do and as a metaphor for creating change in organizations.

When you throw mud at a wall most of it falls off immediately. Some will stick for a little while then falls off. A little sticks permanent. Perhaps too little to see. So you throw some more and the same thing happens. Sometimes it looks like no mud has stuck but actually a little bit has even though you cannot see it.

Every time the mud falls off it is sad, even depressing but you have to keep throwing. Thats all you can do really.

You keep throwing, the more mud that sticks the better the chances that more will stick next time. Gradually, slowly, sometimes imperceptibly the mud builds up. As long as you can maintain your energy, stamina and resolve, you keep trying.

It can be depressing. Sometimes you can stay positive and you give up. Perhaps you move on to another wall.

In this blog, in my books, in my tweets (thankfully vastly reduced recently) I throw mud. Yes, I am a mud slinger, some people think I doing it with bad intentions. But my intentions good, I see a world that needs to think differently.

And when I’m hired to help companies I see it much the same way. I throw a lot of ideas at people, I suggest lots of changes, I throw mud at a wall and most of my ideas fall off. Much of what I suggest gets ignored. No matter how much I talk I have no authority, people are free to ignore me.

Some places I’m very successful, some less so. When I’m inside a company I try to be a bit more directed with my mud throwing, and I limit the ideas I’m throwing. But still it is a question of stamina and resolve. Some places are just more receptive to new ideas than others.

And actually, this is my model for all organizational change. To my mind, all us “change agents” (yes I hate the term too) can do is make suggestions. Throw ideas at people, if they like the ideas, if they think the idea might help then they might adopt it. But they don’t have to. It is hard to force change on people, if you try they may say they will change, they may go through the motions but sooner or later – when your back is turned – the mud will fall off.

Individuals have free will. Most of them want to work as best they can. So if some “agile coach” turns up with an idea workers don’t think will work they are free to ignore it.

I’m not a great believer in authority: just because you are blessed with the title “Manager” (or “Director” or “Executive” or even “President”) doesn’t mean people will fall your orders immediately and without question.

The best way of getting your mud to stick, getting your ideas and changes adopted is to help people understand how such changes will benefit them as individuals. Benefit them in the work they do, the quality of their life-work balance and the pride they feel in work.

Conversely, there are some people, even some organisations, who are totally unreceptive to mud. They go out of their way to avoid it. It is hard enough throwing mud which doesn’t stick, but when people don’t want it to stick, well, I’m probably better off going elsewhere.

Like this post?

Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

The post Throwing mud at a wall appeared first on Allan Kelly Associates.

Posted on

CppOnSea

Frances Buontempo from BuontempoConsulting

CppOnSea 2019

Phil Nash organised a new conference, CppOnSea, this year. I was lucky enough to be accepted to speak, so attended to two conference days, but not the workshops.


There were three tracks, along with a beginners track, run by Tristan Brindle, who organises the C++ London Uni, which is a great resource for people who want to learn C++. I'll do a brief write-up of the talks I attended.


The opening keynote was by Kate Gregory, called "Oh The Humanity!" She made us think about the words we use. For example, Foo and Bar trace back to military usage, hinting at people putting their lives on the line. Perhaps we need better names for our variable and functions. We are not fighting a war. What about one letter variable names? 'k. Nuff said. What about errorMessage? If you call the helpMessage instead, how does that affect your thinking?
Kate was also talking about trying to keep the code base friendly, to increase confidence:



I went to see Kevlin Henney next. I have no idea how to summarise this. He covered so many thing. What does structured programming really mean? By looking back to various uses and abuses of goto, By highlighting the structure in various code snippets, he was emphasising some styles make the structure and intent easier to see.

I saw Andreas Fertig next. Inspired by Matthew CompilerExplorer's Godbolt, he has created https://cppinsights.io/. Try it out. It unwraps some of the syntactic sugar, so you can see what the compiler has created for, say, a range based for loop. This can remind you where you might be creating temporaries or have references instead of copies or vice versa, without dropping down into assembly. Do you know the full horror of what might be going on inside a Singleton?

This led to an aside about statics and the double checked locking pattern. His headline point was the spirit of C++ is "you pay only for what you use", so be clear about what you are using. The point isn't that the new language features are expensive. They are often cheaper than old skool ways of going things. Just try to be clear about what's going on under the hood. Play with the insights tool.

Next up, I saw Barney Dellar, talking about strong types in C++. His slides are probably clear enough by themselves, since they have thorough speaker notes. My main note to myself says "MIB: mishap investigation board", which amused me. He was talking about the trouble that can happen if you have doubles, or similar, for all your types, like mass and force:

double CalculateForce(double mass);

It's really easy to use the wrong units or send things in in the wrong order. By creating different types, known as strong types, you can get the compiler to stop you making mistakes. Use a template with tags, you can write clear code avoiding these mistakes.

Next up was a plenary talk by Patricia Aas on Deconstructing Privilege. She's given the talk before, so you'll be able to find the slides or previous versions on YouTube. Her take is that privilege is about things that haven't happened to you. Many people get defensive if you say they have been privileged,  but this way of framing the issue gives a great perspective. Loads of people turned up and listened. Maybe surprising for a serious geek C++ conference, but the presence of https://www.includecpp.org/ ensured there were many like minded people around. If you are privileged, listen and try to help. And be careful asking intrusive questions if you meet someone different to you.

After quite a heavy, but great talk, I was "in charge" of the lightning talks. Eleven people got slots. More volunteered, but there wasn't time for every one:

Simon Brand; C++ Catastrophes: A Poem.
Odin Holmes; volatile none of the things
Paul Williams; std::pmr
Heiko Frederik Bloch; the finer points of parameter packs
Barney Dellar;imposter syndrome or mob programming
Matt Godbolt; "words of power"
Kevlin Henney; list
Neils Dekker; noexcept considered harmful???
Patricia Aas; C++ is like JavaScript
Louise Brown; The Research Software Engineer - A Growing Career Path in Academia
Denis Yaroshevskiy; A good usecase for if constexpr


My heartfelt thanks to Jim from http://digital-medium.co.uk and Kevlin "obi wan kenobi" Henney for helping me switch between powerpoint, power point in presenter mode and the pdfs, and getting them to show on the main screen and my laptop. No body knows what was happening with the screen on the stage for the speaker. If you ever attend a conference, do volunteer to give a lightning talk. Sorry to the people we didn't have time for.

Day one done. Day two begun.First up, for me, after missing my own talk pitch, was Nico Josuttis. Don't forget his leanpub C++17 book. It's still growing. He talked about a variety of C++17 features. The standout point for me was the mess you can get into with initialisation. He's using {} everywhere, near enough. Like

for (int i{0}; i<n; ++i)
{
}

Adding an equals can end up doing horrible things.

Much as I wanted to go see Simon Brand, Vittorio Romeo and Hana Dusikova (with slide progression by Matt Godbolt) next, I had a talk to do myself. I managed to diffuse my way out of a paper bag, while reminding us why C's rand is terrible, how useful property based testing can be, using some very simple mathematics: adding up and multiplying. This was based on a chapter of my book, and you can download the source code from that page if you want, even if you don't buy the book. I used the SFML to draw the diffusing green blobs. Sorry for not putting up a list of resources near the end.

I attempted to go to Guy Davidson's Linear algebra talk next, but the room was packed and I was a bit late. I heard great things about this. In particular, how important it is to design a good interface if you are making libraries.

My final choice was Clare Macrae's "Quickly testing legacy code". This was my unexpected hidden gem of the conference. She talked about approval testing. This compares a generated file to a gold standard file  and bolts straight into googletest or Catch. It's available for several other languages. It generates the file on your first run, allowing you to get almost anything, provided it writes out a file you can compare, under test. Which then means you can start writing unit tests, if you need to change the code a bit. Changing legacy code to get it under test, without a safety hardness is dangerous. This keeps you safer. Her world involves Qt and chemical molecules visualisations. These can be saved as pngs, so she can check she hasn't broken anything. She showed how you can bolt in custom comparators, so it doesn't complain about different generated dates and does a closer than the human eye could notice RGB difference. Her code samples from the talk are here.  I've not seen this as a formal framework before. Her slides were really clear and she explained what she was up to step by step. Subsequently twitter has been talking about this a fair bit, including adding support for Python3.

Matt "Compiler Explorer" Godbolt gave the closing keynote. Apparently, the first person Phil Nash has met who;s first conference talk was a keynote. He also had some AV issues:


If you've not encountered the compiler explorer before, try it out. You can chose which compiler you want to point your C++ code at and see what it generates. You need a little knowledge of the "poetry" it generates. More lines doesn't mean slower code. His tl;dr; message was many people spread rumours about what's slow, for example virtual functions. Look and see what your compiler actually does, rather than stating things that were true years ago. Speculative de-virtualization is a thing. Your compiler might decide you only really have one likely virtual function you'll call so checks the address and does not then have the "overhead" it used to years ago. He also demonstrated what happened to various bit counting algos - most got immediately squashed down to one instruction, no matter how clever they looked. How many times have you been asked to count bits at interview. Spin up Godbolt and explore.This really shows you need to keep up to date with your knowledge. Something that was true ten years ago may not longer hold with new compiler versions. Measure, explore, think.

There was a lovely supportive atmosphere and a variety of speakers. People were brave enough to ask questions, and only a few people were showing off they though they new something the speaker didn't.

I'll try to back fill links to slides as I get them. Thanks to Phil for arranging this.

Did I mention I wrote a book?