DEV Community: Juha Autero

Executable Specifications

Juha Autero — Mon, 29 Jun 2020 10:06:22 +0000

I've been listening to Greater Than Code episode 188 "Going Off the Rails with Damien Burke". It had lots of important discussion and I recommend you to listen it.

While looking at the episode notes, I read Damien Burke's essay "Specifications not Tests". I think his text misses one point. It's called "Test Driven Development" because those specifications are written as tests. They are not only testable, but also executable.

unexpected char: 0xFFFF

Juha Autero — Mon, 23 Dec 2019 06:15:56 +0000

Since I didn't find anything useful Googling, I decided write this short note.

When you get "unexpected char: 0xFFFF" from your Jenkinsfile (or any Groovy script), it basically means "Parse Error: Unexpected End of File". This is because Groovy's parser is implemented with Antlr that uses Unicode noncharacter U+0FFFF (link to pdf) to signal end of file.

In my case the problem was that I hadn't quoted a string. In retrospect the issue is obvious. When specifying environment variables, the values has to follow Groovy syntax i.e. strings need quotation marks unlike in shell.

PizzaTimer: Starting the project

Juha Autero — Wed, 23 Oct 2019 08:09:32 +0000

I wanted to learn to write mobile applications and decided to look into React Native. I also think that I eat pizza too often and decided to write an app that tells me how long it has been since I ate pizza. Or rather, when I can eat pizza again. (I'm thinking of trying to limit it once a week.)

Getting first React native project created was easy following the instructions, but then I run into a snag. I like TDD and wanted to setup
mocha for unit tests. Unfortunately there has been recent changes in both mocha and babel. None of the instructions seemed to work. Finally, I decided that I don't know enough modern JS development with ES2015 style imports and transpilers and gave up. I was going to look into Flutter next but never got around to it.

That is the problem with instructions that just explain what you should do without telling why. If things don't work you have no idea what you did wrong or how to start debugging your configuration.

Yesterday I looked at my code again and found the babel link above. I replaced 'babel-preset-es2015' with 'babel-preset-env' and run mocha with '--require @babel/register' and things worked!

Code is available at GitHub. (I would use Liquid tag, but it doesn't support repositories that don't have ReadMe.)

Starting a Journal

Juha Autero — Mon, 14 Oct 2019 05:18:46 +0000

I'm trying to return to work using work trial and need to find an employer that would need a part-time worker and is willing to support my re-habilitation. In order to motivate myself I have decided to start a journal to keep track of my learning. If only feedback is if I find a job or not, I will not learn much.

I will write about software development technology and practices here.
I will write about business side in my linkedin

You Can't Write Carrier Grade Software in Go

Juha Autero — Sun, 28 Jul 2019 02:45:10 +0000

because it doesn't have assert.

What is professional software development?

Juha Autero — Tue, 30 Apr 2019 20:41:23 +0000

Have you heard of The Joel Test? It's simple list of 12 yes or no questions. No, wait!Don't follow that link! It's almost 20 years old and bears almost no relevance to modern software development. Who does daily builds in the world of CI/CD? Instead of spec and schedule you have backlogs and sprints. I have sometimes thought about writing new version of Joel Test for agile world.

I've been thinking about this because a bit over month ago I started working with a small team and their tools and practices remind me of people developing web sites in early 2000s starting with the fact that they use Java and PHP. I'm left to wonder are they unprofessional or am I setting my standards too high?

One of the problems is that web created a lot of developers that have never used an IDE or a debugger. How many people using Vim have configured it to get code navigation to work instead of just using grep from command line? Do people even know how to use debugger? Did you know that there actually is debugger for PHP? And you can use it from Vim?

I think you either develop software in a project that works on a specification towards a release or you implement items from product backlog using sprints or Kanban. Anything else is just too unplanned to be professional. I think too many developers think project plan or product backlog is just bookkeeping for managers and not a way to organise day-to-day work. This has two consequences. Firstly, it disconnects the plan or the backlog from the actual work turning them
into a piece of fiction that gives only illusion of control. Secondly, developers have to use some other way to organise their work. Most likely they don't organise it at all and the result is "it's ready when it's ready".

// Detect dark theme var iframe = document.getElementById('tweet-1117858830136664067-867'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1117858830136664067&theme=dark" }

What if you don't have CI/CD process or observability tooling? What if your test automation hasn't been run in ages and therefore they all fail? I've been venting about things that bother me. What do you consider as a minimal level of software engineering?

Attacking phone through BT headset

Juha Autero — Fri, 29 Mar 2019 12:12:36 +0000

I sometimes have these security research project ideas. They are too long to rweet and I'm not on security forums where to post them. Since this is my software engineering blog, I will post them here.

As I was charging my Bluetooth headset, I remembered how you shouldn't use unknown USB ports to charge your devices or at least use charging cable that doesn't have USB pins connected. In this case I was using USB charger connected to wall socket. If I don't trust that charger, I shouldn't use it at all. (Interesting side note: If you don't trust Huawei, why do you trust cheap Chinese bulk manufacturers?)

But it's just a headset, right? What use attacker could possibly have by compromising it? Well, the headset interacts with phone through bluetooth. It could attack the phone by using vulnerability in its bluetooth stack. That could be an interesting project. Write a PoC that uses vulnerability in headset's USB stack to inject code that uses vulnerability in phone's BT stack to inject code into phone.

I would use cheap headset because you probably need to take it a part to find out the hhardware and software it uses. Cheap headsets also are more likely to have poor security.

Scrum, Backlog, Product Owner and Project Plan

Juha Autero — Mon, 20 Nov 2017 01:43:16 +0000

At my new workplace our team has recently started doing scrum. Our scrum master got his training just this week. When he came back we started discussion about what we are doing "wrong" and how we could improve. I commented how the idea of scrum is to have a prioritised backlog and team selects the most important tasks from it at sprint planning to work with during the sprint. I had some more thoughts about it and decided to write my first post.

In theory things are pretty straightforward. At the beginning of a sprint team selects from prioritised backlog items that it is going to work on next sprint. During the sprint team only works with those items. At the end of the sprint team reviews with product owner which items got done during the sprint. Product owner owns the backlog and has absolute power over it. They can re-prioritise backlog between every sprint in any way they want.

There was discussion about how there is too much work and how to communicate customers that there is only so much work the team can get done in a sprint and overwork will eventually backfire. In the end, that is PO's problem, not team's. Team should only avoid overcommitting and make sure that they get tasks they have committed to done. This "single wringable neck" approach gives PO complete control over communication to business side, which is very powerful if used correctly.

Problem is that usually business is used to traditional Waterfall projects and are trying to work in framework of schedules and deadlines. This creates situation where unstoppable force meets with immovable object, a singularity where neither rules of waterfall or agile apply.

Software development is traditionally illustrated with "iron triangle" of scope, resources and time.

Idea is that you can set two of three corners and third one then adapts to the changes in the project. Changing resources is hard because adapting to new resources creates additional load. That gives rise to Brooks' law:"Adding people to late project makes t even later". Traditional waterfall projects set the scope and then try to estimate time by planning a schedule. Since the requirements are not usually completely understood at the planning phase, the estimates never hold and project is delayed.

Scrum turns that idea around. Time is set by having fixed sprints and scope is then adjusted by changing priorities of items in backlog. Deadlines hold, you just don't know what will be done when it comes. By keeping the backlog in priority order you can always be sure that at least most important things are completed.

These two approaches are incompatible. That is probably the most common reason for failure of agile. The whole organisation has to adapt to the idea that scope is not set in stone, but timetable is.