This is the U-1206. It was the peak of submarine technology at the end of the Second World War. Right now it lies at 70 metres depth slightly North West of England.
You might say this is an impressive feat for a submarine to be submerged that long. Alas, it is isn’t by design but aided by lots of bullet holes caused by allied aircraft.
The reason is advancing technology for the convenience of maintainers without testing it properly.
You see, the U-1206 was the first submarine to be equipped with a flushable toilet instead of a septic tank. Cleaning out the tank means having to ascend. Ascending for submarines is bad as it makes them an easier target for aircraft. So, German engineering ingenuity prevailed and the U-1206 got a toilet that can flush whatever goes into it out into the ocean, making it Mother Nature’s problem.
On 14 April 1945, 24 days before the end of the war and 8 days after the submarine got into commission things went wrong.
Captain Karl-Adolf Schlitt used the facilities and ran into the issue of getting rid of a captain’s log. The toilet wouldn’t flush.
So he called in an engineer to fix it. This one deduced that it must be a valve that’s closed and released one of them in the wall, promptly flushing the compartment with a mix of fresh sea water and other things. This would be bad enough, but the flooding also unearthed another design flaw: the toilet was located above the batteries of the submarine. Water – let’s call it that – seeped through the ceiling onto the batteries and caused a shortage and the release of Chlorine Gas. The submarine had to make an emergency ascend, got spotted by Allied Aircraft and sunk. Three people died, 46 got captured.
Just a reminder that using state of the art technology to release your shit as fast as possible out into the world is not a good idea. Especially when people handling that technology haven’t been properly trained on it.
Posted in General | Comments Off on A lesson from history for Software Engineers, Product Owners and CEOs
With the fate of Goo.gl in the balance and many URL shortening/redirection services being either expensive or spammy, I wondered if I could find a free/cheap way of achieving the same. So I got myself a short domain (CLXI.org) and looked at using a GitHub repo with pages to redirect URLs. Turns out, this is pretty straight forward.
However, this is a simple server redirect – like you would do on your own server. The user won’t be notified and has no chance to cancel the redirect. If that is what you want, you are done. I wanted to give people more options.
Building an own redirect with preview
Instead of creating lots of markdown files in the root folder I use a /go/ folder to store them. In GitHub pages the best way to do that is to create a collection. I created a folder called `_go` and added it to the `_config.yml` file:
collections:
go:
output: true
collections:
go:
output: true
Make sure to set the `output` to `true`.
This now allows me to add lots of markdown files there. In order to make them look differently and provide more control over the redirection, I created a template file. To this end, create a `_layouts` folder and add a `redirection.html` in there. The final template has a lot of features we don’t need to cover here, but the main trick was to make the HTTP redirection a variable both in time – the {{page.delay}} bit – and in the URL to send folks to ({{page.goto}}):
I choose the `redirect` layout, the `goto` URL as mine and a delay of ten seconds.
This is as far as meta redirects get us. I also wanted to add a preview progress bar and a chance to cancel the redirect. One of the annoying bits about a meta redirect is that you can’t cancel it. HTML rules supreme and even removing it with JavaScript won’t make a difference.
Adding a chance to cancel the redirect and other fancy bits
To get more granular control, I use JavaScript instead to redirect. This could break, but it gives the user more options.
The script is no magic and I pipe in the data from the frontmatter:
let countdown = document.getElementById("countdown");
let bar = document.getElementById("progressBar");
let full = bar.max;
let delay ={{page.delay}};
let interval = setInterval(()=>{
delay--;
countdown.textContent= delay;
bar.value= full - delay;if(delay <=0){
window.location.href="{{page.goto}}";
clearInterval(interval);}},1000);
document.querySelector("button").addEventListener("click",()=>{
clearInterval(interval);
document.querySelector("section").innerHTML= `
<h1>Redirect Cancelled</h1><p>You can close this page now or go to
<a href="{{page.goto}}">{{page.goto}}</a> yourself.
</p>`;});
let countdown = document.getElementById("countdown");
let bar = document.getElementById("progressBar");
let full = bar.max;
let delay = {{page.delay}};
let interval = setInterval(() => {
delay--;
countdown.textContent = delay;
bar.value = full - delay;
if (delay <= 0) {
window.location.href = "{{page.goto}}";
clearInterval(interval);
}
}, 1000);
document.querySelector("button").addEventListener("click", () => {
clearInterval(interval);
document.querySelector("section").innerHTML = `
<h1>Redirect Cancelled</h1>
<p>You can close this page now or go to
<a href="{{page.goto}}">{{page.goto}}</a> yourself.
</p>`;
});
And that’s that, now you can see the place the link is going to and you can cancel if you want to. Both in dark and light mode. Here’s the progress bar in action:
Cancelling the redirect (this time showing the light mode):
Feel free to fork, add comments and improve on GitHub!
Posted in General | Comments Off on Using GitHub Pages as a URL shortener / redirection service
Currently I am editing >600 presentations of the WeAreDevelopers World Congress to release the videos at the end of the month. This is frustrating and painstaking work, as both presenters and moderators didn’t quite follow some simple ideas that make a talk a good recording.
Conference organisers spend a lot of time and money on recording, hosting, transcribing and describing recordings of talks. And for you as a presenter, you do benefit from a great recording of the session. You reach a lot more viewers that way and other conference organisers do watch recordings to pick speakers for their event. You also add longevity to your session and reach people that may have picked a talk that was in parallel to yours.
That’s why it is important to avoid a few things on stage if you want to benefit from all that effort. Here are some I encountered. And, yes, I also made these mistakes many times both as a presenter and as a moderator. But I learned from them.
Don’t hyper-date your presentation
Almost every presenter commented on the time of day or location of the stage. “Thank you all for showing up this early” and similar fillers. This needs to be cut as it doesn’t make any sense in an online recording. It takes away precious time from your presentation and is the job of the stage moderator. Their job is to get the audience excited, ask them to do the things they need to do – for example put on headphones for translation – and set the mood. You have half an hour to deliver a lot of content. Don’t waste it on current, hyper-local events.
Skip the “questions” slide
Unless you have an online form or discussion channel where people can submit questions later that you also answer, do not add a “questions slide”. It is the job of the stage moderator and conference organiser to provide the infrastructure and collection for questions and answers. A much more useful thing is to end with a “thank you” slide with resources and ways to contact you. Say thanks, enjoy the applause and wait for the moderator to tell you if there were questions. If there is no time, point out the ways to contact you if people have questions. Almost every presenter started asking if there is still time for questions whilst showing their thank you slides. This is ruining them. Trust the moderator and conference organisers and wait it out.
Don’t reference “side shows” in the main talk
Your company will most likely have you promote their other sessions at the event, their booth or promotional bits like raffles. These should come after the thank you slide or before the intro/first content bit to make it easier to cut those when they aren’t relevant any longer.
Don’t reference other talks and happenings without a resource
Unless your job is to deliver a closing keynote that wraps up the event with a neat bow, referencing other talks or happenings at the event is only confusing for people who consume your recording later. If you reference other talks – and you should – have a resource link for people to look it up. It is frustrating for viewers to get a reference to something they can’t access.
Don’t do a “is this thing on?”
Almost every presenter fiddles with their presentation computer when the talk time has already started and many do a “can everybody hear me” bit to make it worse. Good conferences give you enough time to set up before your talk and test your slides. Use that time and show up early to ensure your setup works. That the audience can hear you is the job of the stage crew. What would you do if people say “no, we can’t hear you”? If you want to make sure, do it before you start your presentation and add a pause. “Excellent, so we can get started then…”, a two second break to take a sip of water and you’re off to the races…
Limit audience interaction to before and after the presentation
“Hey, how is everybody doing?” is the job of the moderator. “How many of you are Java developers?” is great info, but unless you do change your talk on the fly for the audience it is also pretty useless. Conference organisers allow you to set the intended audience of your talk in the call for papers, so you should know who came.
Audience interaction is great to keep a talk more lively and you should use it. “How many of you have seen this before? Good, that’s most of you” is OK in a recording, if you also say the result of the interaction. “Can anyone tell me what this is? Yes, it is a capybara stroller, well done!” also works when you give the solution. If you just ask questions into the ether and people watching the recording have no idea about the outcome, that is a waste.
Avoid “killing the ramp”
In radio, the ramp is the part of a song that is audio only before the lyrics kick in. As every second in radio means money, DJs often speak over that part to get some more program info in. Studio equipment shows you a countdown for each song when the lyrics start and a common rookie mistake is to talk too long and speak at the same time as the singer. This is called “killing the ramp”. At many events, the conference organisers will have an intro animation with your name and some music. Often presenters are too gung-ho and go on stage and start talking over these. Don’t do that. Enjoy the efforts the event crew put together to show your name in sparkling letters, take a break and then start talking.
Make pauses at obvious editing points
Make sure to have an obvious start and end to the content that you want recorded and distributed and don’t say anything for a few seconds at these breakpoints. This can be tough as you are hyped up on stage and silence seems painful. But it isn’t. Breaks are as much a part of the skill of presenting as speaking is. You can even make it easier by taking a sip of water during these breaks. This would even allow the editor to recognise these as a hint that things are getting started or have finished. In short, you want to avoid any double sound recording. So when people clap, don’t say anything. When there is sound or a video playing, doubly so.
In summary: Trust the process and concentrate on your presentation
Professional conference organisers will have a process and even a stage plan. They will provide you with moderators to rally and organise the audience for you and to run the Q&A. If you want something extra promoted, like a raffle or your booth, ask them to help you with that.
You will have stage technicians and stage managers that help you set up and test your equipment. Help them do their job by showing up for rehearsals and arrive with enough time to spare before your talk to get mic-ed up.
If you interact with these folks and ask them all the questions that worry you about the tech and process side of things you don’t need to waste any precious time of your presentation allotment on things that will have to be edited out afterwards.
Posted in General | Comments Off on Things not to do as a presenter if you want a great talk recording