Andy Crouch - Code, Technology & Obfuscation ...

Online vs Offline Shopping

Woman Looking At Food On Market Stall

Photo: Unsplash

This is a very opinionated piece. If I offend I do not mean to but you have been warned.

The high street as we know it will not survive.

The writing has been on the wall for a long time. But, I still hear people moaning about the impact that technology is having on the sector. How shops are not as good as they used to be and how they are more expensive and how few of them there are.

I hate shopping and I am a technologist. I am probably the worst person to comment on this. I love the way that technology has opened up choice and reduced cost. As a consumer, they are the two most important factors when I need to shop. Online retailers get that by:

  • Not having a physical presence on the high street. They limit themselves to warehouses (which are mostly automated as far as they can be). This reduces overheads.

  • They are (mostly) cheaper than the high street. Reduced overheads, bulk buying and automation all lead to savings for the customer.

  • They are available 24/7. I can shop when I want or need to. I am not limited by retailers opening hours. (Which in the UK is still governed by the church. Really, people, it is a 24/7 economy in 2018!)

No matter how much high street retailers can buy in bulk, they do not automate and they have overheads. Those overheads are for staff and premises. I am surprised that none of the big UK supermarkets has experimented with Robotics. This appears to be the answer to the staff issue. Automate the restocking process and having self-serve tills would reduce their wages bill. I am not convinced that they would actually pass on the savings to customers. I am sure the shareholders would have something to say about that. They are always looking at the short term annual profit rather than longer-term survival.

The Self service tills are a good case in point. All UK Supermarkets and a lot of the high street shops now offer them. They allow a customer to take their purchases to a till to scan and pay for them. They have been going in one form or another in the UK for about 10 years and they are still awful. I mean they really suck. If I was the designer of these things I would cringe that I made them so bad. They are slow, prone to go wrong and panic. As soon as it is not possible to determine what needs to be done it summons a human. They are unable to verify for age restrictions and so most shops have to have a cashier on hand per 4 self-serve tills. That’s right, someone designed a solution to cashiers and it still requires a cashier. Let that sink in.

The other point worth considering on self-serving tills is that you do not save money as a customer. The company makes you scan your own goods. They effectively making you a cashier for the duration of the transaction. Yet who profits? Not the consumer but the retailer. Even though they do not pay someone to help complete your transaction you still save no money. Again, let that sink in.

I have a lot more to say about choice and cost but this piece is turning into a rant which was not it’s purpose.

Next to choice and price, I and a lot of other shoppers value time. Time is limited for people. They would prefer to spend it when not working with their families and friends. Here also retailers get it so very wrong. Why on a Tuesday night at 6 pm do they have only 3 tills open (out of 24)? Their overheads once again. Evening pay is more expensive than during the day.

The trouble is that no one has looked to change things from within the industry. It is taking Amazon to rethink the shopping experience. A technology company. Their shop in Seattle has no cashiers and no tills. That’s right. You walk in with an app on your phone and pick up what you want and walk out. Your goods are just charged to your Amazon account. No time wasted waiting, No trying to ensure a badly designed machine is weighing your cookies right. Just in and out. I know of at least 3 UK supermarkets that are working on similar technology. But, I wonder whether their extended technology development cycles will be their downfall. Will Amazon make it’s expected entry into the UK market? Will it just be what we have all been waiting for?

I know it will be for me.

I’d love to hear your thoughts on retail and the impact that technology is having. Please share them with me via twitter or email.

Talking Or Walking Away - Approaches To Maintaining Productivity

Frustrated Woman Biting Pencil

Photo: jeshoots.com - Unsplash

Sometimes it is best to walk away.

I am not talking about ending a long relationship or changing job. I am talking about that situation where you work on a problem for so long you don’t see a way out. We have all been there.

As developers, our entire career is about solving problems. As our experience grows we become better and faster at solving them. You start to get to a point where you feel like nothing can stop you. Then every once in a while you hit a problem. A configuration that doesn’t work, code that you just can’t get to compile or a query that returns wrong data.

Through experience, I have found the best thing is to walk away from that problem and come back to it. The longer you sit and focus on it, trying any solution Google has to offer, your brain gets agitated. The more agitated you get the more frustrated you get. Your frustration changes and clouds your thinking. The alternative to walking away is to talk to someone about it sooner rather than later.

A member of my team expressed feelings of anxiety and worry this week to me over being stuck on a deployment issue. They had been trying to get a deployment to work on a cloud provider we do not normally use. They had spent a few days on the issue not getting anywhere and requested some help. The solution doesn’t matter here. What concerned me was that they told me they felt they were failing in their job by not solving it on their own. That my opinion of them would be reduced and that people might even start to discuss them in a negative light. None of these points was valid. No one else even probably knew what that developer was working on for starters. No one else would probably have been able to solve the issue anyway. These feelings all stemmed from the frustration of spending 5 days trying to solve the issue. This had reduced their feelings about their skills and the way they felt perceived by others.

The problem is actually worse for remote developers who work on their own. They have no one on had to recognise they are struggling or who they could talk to. And that is the key solution to most problems. I picked up on the issue through our stand up process (Slack-based rather than physical). Sometimes it’s not a someone that can help it can be a something.

A suggestion in the Pragmatic Programmer book is to use Rubber Duck debugging in situations like this. This idea comes from the story of a developer who would carry a Rubber Duck around. When that developer got stuck they would sit and describe, line by line, the code to the duck. Often the act of describing it would allow that developer to discover the issue and solve it. This can often be the best way to solve an issue whether using a rubber duck or not. Talk someone else through the issue. I am not insulting my wife when I say that I have described problems to her in detail. She has no (or little) idea about what I am saying. It is the act of describing the issue that lets your brain offload, focus and process.

Next time you are stumped I suggest you try either method.

If you would like to discuss this topic further then please message me via twitter or email.

Google Duplex

Robot

Photo: Unsplash

Google unveiled Duplex today, an AI-based system for conducting natural conversations. Showcased at their annual IO conference, the demo caused quite a divided opinion.

Here is a sample of it booking a hair appointment.


It as caused quite an outpouring of opinion especially from people that believe it to be too creepy. They seem fine with synthetic Google Assist style voices but not a realistic human voice. They do not like the added imperfections and phrasing that humans produce when in conversation. A lot of the articles that are against the technology argue that as it would be hard to distinguish the voice from a human

This seems to be at odds with the excitement every time Boston Robotics release another video. Their Atlas robot is now doing backflips. Something distinctly human and unimaginable even a few years ago.


I guess people warm to the robots as they can see that it is a robot. They are not attempting to make the robot look human and so we do not feel threatened. But, what is not lost on me is how few people realise how advanced things have got. Boston Robotics released a video showing their dog like robot calling a friend to open a door. A lot of people laugh along without realising they are watching advanced AI in action. What would happen if that went bad?

This is actually the point that I think differentiates the Boston Robotic robots from Duplex. People can see the robots and perceive no threat. Duplex calling you up has no visual element. They are dealing with the unknown.

Still, it must surely be the aim of some to create the most human-like robot with the AI and voice of a human. This is the direction that technology has been pushing for the last few decades. What happens then? How would the human race react to indistinguishable robots? Are the likes of Elon Musk and Sam Altman right to warn of the consequences?

I’d love to hear your thoughts on this subject so please share them with me via twitter or email.

Git Commit Message Etiquette

Man Looking At Programming Code On Screen

Photo: Unsplash

Git has now been a de facto tool for developers. It has powered the awesome adoption of OSS and was the second well-known project from Linus Torvalds.

One of the things I look out for when looking at a projects repo is the standard of the git commit messages. It can sometimes tell you a lot about the developer(s) and the culture of the project.

It is easy to not give a great deal or thought to the commit messages you add to commit your code. This is especially true when committing in a high frequency as highlighted in the xkcd cartoon:

Xkcd Git Commit Comic

Now while your code should be self-documenting, your git commit log should explain what was done and when. It can be used to provide context to the commits and should be read like a history book of your project.

But, sometimes in the real world, we don’t care enough or are in a rush. Commit messages such as the following (taken from a project I am involved in) offer no value:

Examples Of Bad Git Commits

If we take the first log entry, I have so many questions. What method? Why are we now returning an empty list? What was returned before? That line was all that was included in the commit message. There was no extra content providing any insight. In order for me to see what was done, I need to diff the change. That takes time and I will still not be any wiser on why it was done.

I am not going to rehash how to write awesome commit messages or why it is important. Chris Beams has written the only article needed on it and I try to follow his recommendations.

Examples Of Good Git Commits


Examples Of Good Git Commit Message

The impact is your git log becomes a useful resource. This is even more important when your project grows or people move on. Knowledge is power and as developers, we need to know why things may have been done in a certain way. Git log should be your answers.

Let’s make a point of cleaning up our commit messages and calling out people that leave bad ones. Yes commit 227b4e11ae0824cc3a6508a990d99b4dbbed8f11 in the dotnet core repo, I am talking about you!

I’d love to hear your thoughts on this subject so please share them with me via twitter or email.

Amendment - Updated the example bad dotnet core example as when I saw it I thought back to this article.

Date.parse() With Server Side Strings

JavaScript Code In Editor

Photo: Unsplash

JavaScript date and time parsing is harder than it should be. This is especially true when parsing strings returned from server-side calls. The main problem at present is the fact that Date.parse() is implementation dependent. This means that what works in Chrome will fail spectacularly in all other browsers.

The simplest way to ensure that it works as you expect is to return your strings in ISO 8601 compliant format such as:

"yyyy-MM-dd"

or

"yyyy-MM-ddThh:mm:ss"

This will parse a date or a date and a time correctly. All times are treated as UTC. The topic of time zones and offsets is beyond the scope of this simple post. But, if you need to return a time with an offset then you want:

"yyyy-MM-ddThh:mm:ss +0300"

This will give you a Date object with the time set to 3 hours ahead of the specified time.

It’s funny how often date time string parsing confuses even experienced developers. If you need a thorough reference then the best I have found on this subject is here.

If you know of some good references on this subject or have any thoughts then please share them with me via twitter or email.