Showing 35 result(s)

Install GraalVM and Native-Image on an M1 Mac (Java11)

This is a quick guide on installing GraalVM on your M1 Mac – this guide also works for x86_64 Macs also.

This will install GraalVM for Java11 – different Java versions are available here: https://github.com/graalvm/graalvm-ce-builds/releases


Install GraalVM using Homebrew

brew install --cask graalvm/tap/graalvm-ce-java11

export JAVA_HOME=$HOME/Library/Java/JavaVirtualMachines/graalvm-ce-java11-22.0.0.2/Contents/Home

Give GraalVM permission to run

xattr -r -d com.apple.quarantine /Library/Java/JavaVirtualMachines/graalvm-ce-java11-22.0.0.2

Install using sdkman

SDKMAN is a brilliant tool, you can install it here: https://sdkman.io/install

sdk install java 22.0.0.2.r17-grl

export JAVA_HOME=$HOME/.sdkman/candidates/java/22.0.0.2.r17-grl

Install native-image plugin

Firstly update your path

Brew version:

export PATH=/Library/Java/JavaVirtualMachines/graalvm-ce-java11-22.0.0.2/Contents/Home/bin:"$PATH"

SDKMAN version:

export PATH=$HOME/.sdkman/candidates/java/22.0.0.2.r17-grl/bin:"$PATH"

You can now install the native-image plugin via the gc command.

gu install native-image

Install CloudFoundry on an M1 Mac (arm64)

Install Rosetta 2

/usr/sbin/softwareupdate --install-rosetta --agree-to-license

Install Homebrew under Rosetta 2 (/usr/local/Homebrew)

arch -x86_64 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Tap Cloudfoundry

arch -x86_64 /usr/local/Homebrew/bin/brew tap cloudfoundry/tap

Install CloudFoundry

arch -x86_64 /usr/local/Homebrew/bin/brew install cf-cli@7

Further thoughts on pairing during software development! (Part 2)

While being a Lead/Senior Developer on several agile development teams, I’ve seen the ups and downs of pair programming. I’ve tried to introduce pairing into new teams with different levels of success – so I thought I’d write down some of the experiences I’ve had – and the potential was of working that can make pair programming less painful.

In August 2020 I wrote an article about Some thoughts on pairing during software development. Where I talked about :

  • Pairing should not be forced. Processes, routines or schedules don’t work.
  • Pairing works best when it is natural, encouraged but not mandatory

Now, a year and a half on (sorry I’m terrible at this blogging thing), and after changing jobs and a few teams in between – I thought I’d continue and write about some other points regarding pairing in Software Development.

To me, pairing while coding can be rather intensive, and can take real dedication and effort to keep on task. So here are some points on maintaining focus and optimising pair programming time!

Pairing works when both engineers are not multitasking

It sounds pretty straightforward. How can someone work on one piece of work, while also working on another? It’s hard to dedicate your full attention to one task if another is also taking your time and effort.

In reality, trying to dedicate your full attention to a task isn’t going to happen. You will often get distracted by a question from a colleague or an email notification taking your attention away. Let’s not forget the daily standups, tech meetings, and retrospectives – all diverting your full attention from the store/task you are working on.

Acknowledging that your concentration while pairing will not always be at its best, is the first step to pairing effectively. Knowing that both developers may be randomly interrupted by a Slack message or a phone call from someone is unavoidable. Knowing what to do when it happens is how to avoid it spoiling the velocity and focus on the task at hand.

You can’t stop interruptions

Just a side note before I begin – there is no way to stop interruptions or random events from taking your attention away from the task you are working on. Don’t try to stop interruptions – you’ll never succeed. A few years ago I worked for a company where I felt the majority of my day was being asked questions or interrupted by colleagues asking for help with their own tasks. I found that my own tasks were suffering and deadlines were starting to slip, so I attempted to cut out the interruptions (which may have involved hiding in meeting rooms, working in the kitchen, or trying to put processes in place). I spent far too much time trying to eliminate the interruptions than the time I was spending answering the questions/helping someone. Just take it as a compliment that your colleagues come to you when they need help!

Prioritise your pairing partner?

So, you happily pair programming away when someone walks up to your desk (if you’re physically back in the office) and ask if you have a ‘minute’ (why is it never a minute?). If you’re polite, you might be inclined to offer that help, which sadly means you are context switching and taking your attention away from the pair. This is where you need to prioritise your other pairing partner and put them first above other colleagues while you’re working on the same story/ticket. It’s not fair to your pairing partner or to the story/task as a whole if you suddenly drop your level of focus to context switch and work on another task.

I always try to say to the colleagues asking questions or causing the interruption if we could possibly arrange another time and ensure I keep my attention to the pairing task. Of course, be polite and say that you’re currently working on something with another developer and will get back to them as soon as possible.

Exceptions to this might be if a colleague is asking you a question about the current story/ticket you are pairing on – if that is the case, grab your original pairing partner are form a huddle (a session where more than two developers work on a task). You can always split back off after the question/problem has been resolved.

Ceremonies and meetings

If you work on an Agile team, you’ll be used to attending regular ‘meetings’ (sorry agile purists) such as Standups, Backlog Refinements, Planning, Retrospectives, etc. Hopefully, you and your pairing partner will have these similar ceremonies in your calendar – so can easily drop tools on your pairing story/task and attend them together. This is good practice to maintain attending these ceremonies, and resume pairing when you can.

Dealing with meetings that only one individual from the pair needs to attend is a little more challenging. Meetings like one-to-ones with Line Managers or Practice/Role meetings can distract the pair from the task at hand. I recommend you agree on what to do in these circumstances. I personally think it’s OK for the person that is not attending the meeting to continue working on the task, and then do a review of what has been done once the pairing resumes after the meeting.

One alternative is to ask yourself ‘Do I need to attend this meeting? Would it be more beneficial to continue pairing?’ – you can always consider rearranging the meeting for a better-suited time. This goes well with my first point – prioritise your pairing partner where possible.

Take regular breaks, coffee == code.

Schedule coffee and rest breaks throughout the day. Having time blocked out for a break from pairing helps to divide time into ‘We are pairing’ and ‘I’m going to respond to that important email’ sessions or just simply ‘I need a break, my brain needs a rest’.

Set a time limit on the break time – don’t say ‘Let’s have a break’ then not resume pairing until an hour later. Don’t leave the break time open-ended. On teams I’ve led or worked on, I’ve found if someone says ‘I need a coffee’ – we all agree to take a break, and resume in 10 minutes. It is then polite to make sure you are back and ready to resume at the set time. Don’t leave your pairing partner waiting around or continuing the work without you.

With that being said, don’t be scared to say you need a break! Pairing on a hard task can leave you feeling like your brain is fried. Regular five or ten-minute breathers can be very productive in solving that annoying problem you’ve been having with the Unit Test, NullPointerException, or <Insert other common problem here>.

Keep at it, rome wasn’t built in a day.

Good pairing won’t just happen overnight. It’ll take several weeks or months for developers to slip into the mode of ‘I’m going to take on this new story/task and find a pairing partner’ – without being persuaded or bribed (a scrum master once offered me biscuits in reward for pairing). As I said in my previous article, whatever you do – Don’t force it!


So if you’re planning to introduce pair programming, or are already on your journey, hopefully, there are some small takeaways from this article. Please leave a comment and let me know how pairing is going, or being done on your team – I always love to hear how other teams do it!

I plan to write about tooling/remote pairing in the next installment… Hopefully, this won’t take me a year and a half to write this time.

black trash bin with full of trash

NPM: Maximum call stack size exceeded

You may have cloned a project and tried running ‘npm install’ only to find the following error message:

error Maximum call stack size exceeded

There’s multiple ways I’ve found to fix this:

The Safe ways:

Force clear the NPM cache:

npm cache clean --force
npm install

Rebuild:

npm rebuild
npm install

Remove node_modules:

rm -r node_modules
npm install

The Nuclear way:

rm package-lock.json
rm -r node_modules
npm install

As always, I hope this fixes your problem!

Some thoughts on pairing during software development! (Part 1)

Over the past few months, I’ve been pairing (pair programming) with other Software Engineers when working on stories during our sprints. It’s been fun, and the first time in a while I’ve enjoyed and felt rewarded while ‘pairing’. While I’m sitting in the sun, on a beach in Wales enjoying our holiday with my family, I look back and consider it hasn’t all been plain sailing…

My first exposure to pair programming came as I was working on a team that was writing API’s for some of our business services. It was a relatively new formed team with a range of mid to junior level Software Engineers, a Business Analyst, a Product Owner, a QA tester and a Scrum Master.

We’re sitting around a table in the office’s shared kitchen (there’s never a decent sized meeting room when you need one) for our bi-weekly retrospective. The lead Software Engineer had joined us, and we are discussing the usual ups and downs of the last sprint.

We had discovered that the current block of work we had was a set of rather similar tasks. Each developer was picking up a new story ready for development that would be a small task, but all on a similar part of the micro-service. It was found that during committing the code into source control, that software engineers were overwriting or change the same chunk of code. This meant lots of merge conflicts and code reviews taking longer.

So trying to address this issue, the team had decided in the Retrospective that developers should be teaming up with each other and working on the chunk in parallel.

Ok let’s give pair programming a go now the team is mature enough” says the Lead Software Engineer.

Over the next few weeks and months, we attempted to introduce pair programming into the team, with some challenges. As I’ve later moved onto other teams, I’ve seen some sort of pattern to how teams adopt pair programming.

There’s some thoughts I’ve had on pairing which may help:

Pairing should not be forced. Processes, routines or schedules don’t work.

So it’s week one of our team attempting to pair programme. How should we approach this? “We have four developers on our team, so let’s rotate” one engineer suggests.

Ok, but when do we know when to change pairs?” asks another.

After a relatively lengthy discussion, it was decided that the following ‘rules/guidelines/suggestions’ would be introduced.

  • Developers should switch pairs once a story is completed.
  • If a pair has been together for more than two days, they must switch.
  • One developer must remain on the story from start to finish.
  • Nobody should work on a story on their own.

Ok, it was a little flakey. But it offered what we thought some ground rules for pairing to take off and work… How very wrong we were!

It turns out that even though we liked the idea of pairing when it came down to it, the first few weeks were incredibly hard. We had been used to independently working on our separate tickets. When ‘forced’ to work with another human being with a separate way of working, a different way of tackling a problem or even an alternative biological clock (toilet breaks, and caffeine pitstops) it is incredibly hard.

I personally found keeping my train of thought almost impossible. With many interruptions and events during the day which would take our focus off pressing keys and coding.

It wasn’t working! Not only was it rather frustrating for the developers, but the ‘rules’ we had come up with were not working. The nature of different stories being completed at separate times meant some developers were waiting around. Waiting for another pair to finish and unable to pick up a new story to work on – We had created dependencies between stories without realising it!

We tried to adapt the rules and even printed out a schedule that hung above our Kanban board. We could see which pairs were currently together, and developers waiting for a new partner.

Eventually, due to frustration and general lack of interest, the pairing stopped, and we naturally drifted back into flying solo! Much to the Scrum Master’s disappointment. In a last ditched effort, the Scrum Master regularly walked around the office trying to find developers not pairing. ‘Strongly’ encouraging them to relocate to another developers desk and pair. Which then started to cause other pain points, like feeling Micromanaged.

Forcing pair programming doesn’t work. If anything it turns the developers against the idea and we will then try our utmost to avoid it.

Pairing works best when it is natural, encouraged but not mandatory

If you’re reading this thinking ‘how should I introduce pairing into my team‘ this is my suggestion.

Don’t have any rules/suggestions/enforced ways of working… Let it be natural. Takedown the printed schedule. Delete the list of ‘rules’ you have. Certainly do not walk around the office asking why a developer is not in a pair!

Just go ahead, walk up to another developer and say something along the lines of “Is it OK if I sit with you and learn about what you’re working on?

I’m speaking for myself, but Developers are very proud of their work (I know we shouldn’t be protective of our code, but show me a developer who isn’t proud of their work, and I’ll eat my keyboard).

Asking the above will hopefully put the other developer into a mode where they want to show you what they’ve been working on, and open the door to further conversation. Sit with them. Don’t try and take over, kindly ask them to explain what they’re doing. Why they decided to take that approach, and what their train of thought is.

Hopefully, after a while, they may feel comfortable with you being there, and you may be able to offer suggestions, praise their work or help with that question they just Googled. But remember, you are in their territory. Don’t take over, and certainly don’t say they are doing something wrong. You will just rattle their cage and will not gain their trust (Yes this is like taming a Lion).

Eventually, you should have built up that level of trust with the developer that you can ask the following question, something along the lines of “I really enjoyed working alongside you with that Story, could we possibly try to work on the next one together?” You should offer to ‘drive’ this time.

Over time, you should find it easier to work alongside each other. So you can start to build on those foundations. Offer to take turns coding, writing a test, or contacting someone to find an answer to a question. I find writing tests together is really beneficial. You can help each other to spot the pitfalls or that bit of information missing from the Story.

When you feel like you’re walking, it’s then time to run… If you’ve been sharing a computer and taking turns driving, you may want to take it up a gear and install some sort of screen sharing software (like slack, teams etc). Basically a piece of software that you can see each other’s screens and control if needed. In the remote world we now exist in (COVID-19), this is must for pairing, but back in a physical office space, it might not be always needed (remember to do whatever feels natural).

Based off experience, both members of the pair need to offer to take turns. Don’t just sit back and watch the other developer. Get involved, even if you don’t know how to write the test, refactor the method, or create that builder pattern – offer to take control and work together to achieve the goal.

I’m not saying this will lead to amazing results, or it will work for all developers, but it’s worked for me. Especially when you join a new team, or start a new piece of work. It can work with a junior or senior developer, as long as you are humble and accept it may take time to form that trust in the pairing relationship.

You’ll encounter problems, you’ll get frustrated that the other developer may not have understood you. You will get annoyed when your idea isn’t implemented as you’d have liked. This is all part of the process, and as you keep pairing, you’ll overcome these little problems.

What you’ll get is a high performing, focused pair, taking stories across the board in record time. When the story first gets picked up, it will be understood quicker, code reviews will be quicker (as the story has technically been under review the whole time as the developers discuss the implementation) and will move to ‘Done’ faster.

In part two, I’ll talk about:

  • Pairing works when both engineers are not multitasking or context switching and can focus 100% of their time to the task.
  • Both Engineers should start and finish the task together. Breaks in between are of course beneficial.
  • Engineers can join the pair, but not replace anyone from the original pair.
  • Both engineers should be given equal credit.
  • Pairing remotely can seem hard, but is actually feasible and often works better than physical pairing.
  • Is it just Software Engineers who can pair? No.

Link to Part 2: Further thoughts on pairing during software development!

Penny Saving Challenge using Starling Bank, Lambda and Node

I came across a money-saving Challenge called the ‘1p Challenge‘. Basically you save an amount of money based on the day number in the year.

For example, on January the 1st, you would save 1p. Towards the end of the year, say day 365, you would save £3.65

As you can imagine, this starts saving small but eventually ramps up so you will save around £667 over the year.

The problem is, it’s incredibly hard to manage yourself. Finding the time or remembering to transfer funds into another account every day is a challenge. So, like most things in my life, I decided to automate it.

I recently moved over to Starling Bank. It’s an online-only bank which has an amazing app to control your money. It also allows access for developers to an API.

Inside the Starling App, there is a concept of ‘Spaces’. These are pots of money you can use to save for things (Holidays, Life Events etc). Basically, when you move money into a ‘Space’, it’s removed from your current balance, and added to the ‘Space’ – it’s like a separate savings account. This is perfect, as I can set up a ‘Space’ called the ‘Penny Challenge’ and move money into each day…

Now, people who know me closely will know when it comes to technology, I will automate anything that I don’t like doing (lazy)! So, this is how I automated saving money…

Setting up a Starling Bank Account

If you don’t have a Starling Bank, there are obviously many other banks out there. But I chose Starling due to them providing a usable API. I know Monzo and other banks also offer APIs, so feel free to shop around.

Once I set up the account (and started using it as my main current account), I set up a new space called ‘Penny Challengee’

Starling Developer Account

To access the Starling API, you’ll need a Developer Account. It’s a pretty straight forward signup process. Once you’ve signed up, make sure you link the Developer Account to your Starling Bank account (Settings -> Accounts)

Next, you’ll need to get a Personal Access Token. This is basically your authentication token (AccessToken) when accessing the API.

When choosing the permissions, make sure you select the following:

  • savings-goal-transfer:create

Creating the application

Luckily enough, the developers at Starling provide a nice Developer SDK for you to use out of the box – hosted on GitHub. This was a great place to start.

Using Node, you can easily get started with just the following:

const Starling = require('starling-developer-sdk');

const client = new Starling({
  accessToken: '<INSERT TOP SECRET TOKEN HERRE>',
});

client.account.getAccounts(); // Lists all available accounts.

After playing around for a while, seeing what information I could get from the API. I started to create something which would move money from my current balance into the ‘Penny Challenge Space’.

Here’s the method which performs that move.

client.savingsGoal.addMoneyToSavingsGoal(
    {
      accountUid,
      savingsGoalUid,
      transferUid,
      amount,
      currency: 'GBP',
    },
  )
    .then(({ data }) => console.log(data))
    .catch((err) => console.log(err));

You’ll notice there’s a few parameters which are required.

  • accountUid : The Account UUID (from .getAccounts())
  • savingsGoalUid : The Savings Goal UUID (from .getSavingsGoals())
  • transferUid : Randomly generated UUID (I used uuid package v4)
  • amount : The amount in minor units (1 = 1p, 100 = £1)
  • current : The currency your account is using.

Getting the current day and working out the amount to save

Ok great, using the Starling API I can move money into the ‘Penny Challenge Space’. Now, I need some logic to work out the amount which needs to move, based on the day of the year.

I spent more time than I want to admit creating a method which took the current date, compared it with the 1st January, and returned the number of days in between. It was horrible and hacky, before even mentioning it didn’t take into consideration the fact that it was a leap year… Who knew working with dates is so hard?

So why reinvent the wheel? It turns out momentjs have already figured this issue out and solved it! I’ll use their package…

const moment = require('moment');

const amount = moment().dayOfYear();

This returns a value between 1 – 366. This is perfect as I can use that value as the amount (minor unit). I’ll then pass this to the addMoneyToSavingsGoal() method.

Perfect! That works, it moves the amount into the correct SavingsGoal based on the day of the year. Now I need some way to trigger it to run each day automatically…

Lambda

I decided to use AWS Lambda to trigger the money transfer each day. I could have easily used something like a Cron Job to achieve this. But hey… AWS Provides a Free Tier, so I might as well use it!

Therefore, I created a new Lambda Function. You’ll need to package your node application into a ZIP file and upload it using the AWS-CLI. Here’s a nice guide on how to do that.

Make sure you wrap your code to export the event:

exports.handler = async (event) => {
// Code here
};

CloudWatch

To trigger the Lambda script, you will need to set up a CloudWatch Rule using a Schedule. I personally set a cron expression, but you can also use the ‘Fixed rate of’ setting. Both achieve the same outcome.

So that’s it! Every morning at 9 am, CloudWatch will trigger the Lambda script to move money into the ‘Penny Challenge Space’ in Starling based on the current day of the year. Job done!

Putting it all together

Here’s the code for the app.

Setup Node:

$ npm init
$ npm install starling-developer-sdk
$ npm install uuid
$ npm install moment
$ touch index.js

index.js

const Starling = require('starling-developer-sdk');
const uuidv1 = require('uuid/v4');
const moment = require('moment');

const accountUid = '<UUID for Account>';
const savingsGoalUid = '<UUID for Savings Goal>';

const client = new Starling({
  accessToken: '<TOP SECRET PERSONAL TOKEN>',
});

exports.handler = async (event) => {
  const amount = moment().dayOfYear();
  const transferUid = uuidv1();

  return client.savingsGoal.addMoneyToSavingsGoal(
    {
      accountUid,
      savingsGoalUid,
      transferUid,
      amount,
      currency: 'GBP',
    },
  )
    .then(({ data }) => ({
      statusCode: 200,
      body: JSON.stringify(data),
    }))
    .catch((err) => ({
      statusCode: 500,
      body: JSON.stringify(err),
    }));
};

ZIP & Deploy to AWS Lambda

$ zip functionName.zip .
$ aws lambda update-function-code --function-name MyLambdaFunction --zip-file fileb://functionName.zip

As always, my blog posts are just brain dumps of things I’ve been working on in my spare time. But I hope this is useful for those looking to achieve the same thing.

I have to give credit to Andrew Barber (a fellow Scouter) – as I was scrolling through his GitLab when I came across this ‘1p Challenge’ – He’s written his own version which uses a cron job! We both seem to have gone about solving the problem in a similar way (using moment).

Thanks,

Dano!

Convert a private key .ppk to .pem on Mac OSX

If you’ve used putty to generate your private key, you may need to convert it to a PEM file instead

Firstly install putty via Homebrew

$ brew install putty

Then convert the file

$ puttygen privatekey.ppk -O private-openssh -o privatekey.pem

Install the key by moving the file to ~/.ssh

$ mv privatekey.pem ~/.ssh

GitLab CI: failed to dial gRPC: cannot connect to the Docker daemon. Is ‘docker daemon’ running on this host?

The latest docker:dind has breaking changes. Here are two fixes if you are enchanting issues with GitLab CI and your runners.

Fix 1: GitLab CI Config

Add the following to your .gitlab-ci.yml

variables:
    DOCKER_TLS_CERTDIR: ""

Fix 2: Change runner config

Alternatively, another fix is to change the runner:

$ nano /etc/gitlab-runner/config.toml

Modify to mach the following (specifically environment and volumes)

[[runners]]
  environment = ["DOCKER_DRIVER=overlay2","DOCKER_TLS_VERIFY=1","DOCKER_CERT_PATH=/certs/client"]
  [runners.docker]
    image = "docker:dind"
    privileged = true
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache","/certs"]

Then restart the gitlab runner

$ service gitlab-runner restart

I hope at least one of these fixes resolves your issues.

Nginx Proxy WordPress Configuration

If you need to proxy your WordPress blog via Nginx. This is the configuration I have recently used.

Update <server-name> with your intended domain name. <ip-address> and <port> with the WordPress servers details.

server {
        server_name <server-name>;

        gzip on;
        gzip_min_length 10240;
        gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;
        gzip_disable "MSIE [1-6]\.";

        add_header Cache-Control public;

        location / {
                proxy_set_header X-Real-IP  $remote_addr;
                proxy_set_header X-Forwarded-For $remote_addr;
                proxy_set_header Host $host;
                proxy_pass http://<ip-address>:<port>;
        }
}

Test Nginx Configuration

To test your Nginx configuration files, run the following command:

nginx -c /etc/nginx/nginx.conf -t

It will indicate if your configuration file syntax is correct.

Configuration Check Failure

root@proxy:/etc/nginx/sites-enabled# nginx -c /etc/nginx/nginx.conf -t
nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /etc/nginx/sites-enabled/test01:2
nginx: configuration file /etc/nginx/nginx.conf test failed

Configuration Check Success

root@proxy:/etc/nginx/sites-enabled# nginx -c /etc/nginx/nginx.conf -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful