In my attempts to learn game development I thought I better give pixel art a go.

I used the AMAZING web app Piskel for my first efforts. As a non-artist and knowing nothing about pixel art before starting, I found Piskel to be the perfect place to start. Check it out here

Piskel

Piskel is an online pixel art creation tool. It has an amazing selection of tools and options to get you up and running creating your first pixel art attempts quickly and intuitively. While I am defintely NOT an expert, I found I could get something together pretty quickly.

You get the usual sort of tools that you would expect from a simple drawing package; line tools, shape tools, selections etc. Though Piskel really came in to its own for me though in its layers and frames.

In each frame you can set layers as you would in other drawing programs. I found this to be massively useful when atempting to animate my pixel art. Once you are happy with a frame and ready to create a new one you have a few options to speed up the process. You can clone a previous frame, flip it, crop it etc. These might not seem impressive to someone who knows what they are taling about but I found them massively helpful.

My first attempts

As I’m sure I’ve said already, I am not an artist, so unsurprisingly my first attempts were not the most successful.

I was trying to make a character for a game I’m working on and I think I may have started out a little too ambitiously.

However, it is so quick and easy to start and make a new project in Piskel it really doesn’t matter if you are rubbish like me.

Animation

For me, the thing that makes Piskel stand out so much was the built in animation tools.

You have the ability to create frames to build up animation which is great. But Piskel will also preview the animation for you automatically. You can even set the number of frames per second in your preview.

I found these tools to be very helpful to keep my designs on track so I didn’t have to keep exporting them and turning them in to animations within Unity.

Once you are happy with your animation you can then export it in various formats such as a GIF or as a sprite sheet. Since I was importing mine in to Unity I went with the sprite sheet option. On importing in to Unity I found no problems at all.

I’ll do another post about how to use the sprite sheet in unity another time.

Amazing

I can’t recommend Piskel enough. For someone totally new to pixel art like me, it was really daunting on how to go about getting started. However Piskel’s easy to use interface let me concentrate on trying to make something cool rather than learning a new piece of software.

Go try it!

Here’s how and why I built my last app following lean principles - Practice makes Perfect

The app

My new app “Practice makes Perfect” is designed to be a tool to be used when learning a new skill. There is a theory that puts forward, if you practise something for 10,000 hours you become an expert in that skill. Practice makes Perfect, aloows you to keep track of your practise sessions by recording each one and totalling up your overall time practising time.

I came up with the idea for the app while learning my own hobbies. While playing the banjo I was wondering how long I had been learning it for overall.

Why build a personal project following lean principles?

To some it might sound strange to build a personal project following lean principles. I’m the developer and the client who will be signing off of designs and functionality. Why not just build the whole thing right?

True, one of the feedback loops is removed, but the others are still there and other constraints such as budget were very important to me on the project.

Is there interest?

One of the most important pieces of feedback I wanted to get early was, would anyone else find an app like this useful?

The quicker I got the core mechanic of the app out and getting feedback from it would tell me if this was a good idea for an app or not.

Budget

This was a personal project being built in my own time, so while there wasn’t a team of developers/designers/product owners to pay for, it was costing me the most precious resource, my time.

It didn’t take me too long to get the core of the app working but I felt I had to do at least a little design work before I could release the app. Trying to make it a minimum likeable product at least.

If the app recieves any interest at all, I would be happy to extend the budget (my time) on this project, but until then, I’ve set a budget, met it, and now waiting for feedback.

Holding back

Not going over budget was actually surprisingly difficult. During the initial build I had lots of ideas for extra features on the app. For example, the ability to add evidence of your practice sessions, such as images and video. I think this is a good idea, but doing that would have extended the budget to get it released. If anyone starts using the app then I can justify increasing the budget.

Another example of waiting to see if new features are needed is the ability to remove practice sessions and skills. As soon as anyone is using the app this seems like an important feature to add. However, if no one is adding and skills or practice sessions, there is no need to be able to remove them!

Feedback

I’ve already recieved some feedback on the app. Mainly that I need to learn how to promote an app without any budget!

Another piece of feedback that I got early from releasing quickly was that the icon I just generated in Android Studio isn’t the best. Not the most constructive piece of feedback in the world, but it’s a learning I can apply to this app or at least take in to my next project.

Next steps

It’s still early days in the app store but it’s not looking like Practice makes Perfect will be reaching the top of the app store anytime soon.

As such, I’m really glad that I set myself a budget, stuck to it, and got some learning from releasing. Spending more time now adding features isn’t likely to increase the take up rate of the app so it doesn’t seem wise to build those extra features yet.

The most likely next step for the app would be start trying to gain some qualitative data on how/why someone would be looking for an app like this in the app store. People who hear about the app agree it’s a good idea but now I need to understand what would convince them to download it. If you would like to try Practice makes Perfect, download it here.

If I can’t come up with a plan to increase downloads then I’m ok dropping the project where it currently is. Thanks to the lean approach not a lot of time/money has been wasted and learnings were made, so if the idea ends here, I’m not overly invested in it.

Recently I had the opportunity to take part in a debate of trunk based development vs branching. Here’s how it went.

What is trunk based development?

In trunk based development all developers work only from the trunk or master. No branches are created for feature development or releases. You work on master and release from master.

Other factors may influence exactly how this is implemented though. For example, depending on the team size and composition, you may create short lived branches for peer reviews or pull requests. However, it is important that the spirit of trunk based development is still observed and these branches are short lived.

For more information on trunk based development, here is a great website explaining it in much more detail.

My arguments for trunk based development

XP principles

When pulling together my arguments for trunk based development it occured to me that this sort of source control strategy supports several of the XP principles.

Collective ownership

Since when following trunk based development, every commit should be going to the master branch which in turn will be checked out by every member of the team and break the build for everyone if there is anything wrong, collective ownership sort of just happens. If you leave broken tests, you aren’t just affecting yourself, you are affecting the whole team. This quickly promotes care and attention to the work and others in the team.

Continuous integration

You should set your continuous integration pipeline to be built from commits to the master branch. If these commits are coming from every member of the team and going through continuous integration, you should always be in a position where a release to live is possible.

Small releases

By working in branches you are working against the principle of small releases. Even if you keep those branches relatively small you are going against the spirit of small releases. If commits need to be gathered together in a branch for something like a feature, then by definition these are bigger releases.

In an ideal world, each commit would be going straight to live through your continuous integration pipeline, in turn ensuring small releases. However, even without automated deployment, avoiding feature branches is a great way to avoid large releases.

Sustainable pace

By avoiding the large releases and gaps between deployments, trunk based development can definitely support a sustainable pace of development. The ideal is small incremental commits that you would always be happy for to go to live.

Presentation example

To highlight the point we compared using Google slides to Microsoft powerpoint if there was more than one person preparing a presentation.

Using Google slides that saves every small change to a shared document helps promote collaboration and communication. Compared to where if more than one person were working on the same Powerpoint presentation they would each keep their own copy, or branch, of the presentation. This could result in there being bigger gaps between each contributor seeing what the others are doing, resulting in confusion when the multiple presentations needed to be combined.

The rebrand problem

One argument I have been presented with before is what I call the rebrand problem. The argument goes, when you are doing a big change such as rebranding a website then you need to do that work on a branch as you don’t want to block releases for that amount of time.

However I would argue this is the wrong approach. Firstly I would be looking to carry out some prefactoring on my code. Make changes that may not have any direct changes to the end user but that make the code more flexible and easier to change. For example, making sure all colours in the app are managed in one place, by using Sass variables for example.

Although I would prefer to avoid large changes altogether and deliver the work incrementally. For example, looking at Amazon’s front end changes over the years, I would say the design has evovled incrementally rather than large step changes.

Conclusion

Overall I would say that there are some instances where trunk based development can help, such as when you are supporting multiple versions on an app. However, I would imagine that if a branching strategy is helpful, then there are likely to be further underlying issues that you should also be addressing.

The Five Whys technique is a tool to help in root cause analysis and I thought it might be a good excercise to try out in a retro.

What is it?

If you want to get to the root cause of the problem, you ask yourself why something has gone wrong. Then to that answer, you ask why again. The theory is, once you have repeated that process five times you will have a better understanding of the root cause of the problem.

Not all questions will have a single answer, and this is fine, but then you should ask why to each subsequent answer. This is why I find it helpful to document a Five Whys excercise as a tree diagram

via GIPHY

As with any tool or technique, it’s not perfect. It may not give you a silver bullet answer and it relies upon the people involved to think of the causes and not the symptoms but anything that can help you think and frame a problem is good for me.

How it went in a retro

To start I had everyone write post it notes of things they felt could have gone better since the last retro. Then we each had two votes to decide on which post it we would discuss. That point was then the basis for our Five Whys activity.

It was really interesting putting Five Whys in to practice. The questions very quickly started giving more than one answer. As a team we decided which branch we wanted to follow and keep questioning. It was surprised how much information came out when the conversation was guided by the Five Whys technique.

Once we had got to the fifth why I felt that the actions we were taking away were focused, small, and addressing the root cause of the problem. While they might not fully resolve the initial problem, as they are only addressing one of possibly many root causes, I feel having a small focused action that will be a step towards solving the problem is a good thing.

The response from the team after the session seemed pretty positive. I think it was helpful to frame the conversation around the model. Or at the very least, sometimes it’s good to try new retro formats to keep things interesting.

If anyone else has any good ideas for retros, please let me know. It would be great to hear some new ideas.

I’m not an expert about the Android Debug Bridge (adb) at all, however this issue cost me a couple of hours to resove the other day so I thought I would write this to remind myself if it happens again.

What is adb

The Android Debug Bridge is a command line tool that lets you interact with both virtual and physical android devices.

For example you can press the power button on the device via the command line.

For more information on adb, check out the Android docs.

What was my problem

When trying to attach a phone to debug via USB I wasn’t getting the prompt to trust the computer’s RSA key fingerprint. This meant that the device was not being authorized in adb. As such, debugging and running Espresso tests was impossible.

After trying the usual switch things off and on again and trying a different wire I was still having no luck.

How I fixed it

I read that if the RSA key for adb is not correct then the device will not be able to trust the computer and won’t connect.

Regenerating the keys is easy by following the following steps

Delete the old keys

For Macs the keys are found in;

~/.android/adbkey
~/.android/adbkey.pub

On Windows they are found;

C:\Users\{username}\.android\adbkey
C:\Users\{username}\.android\adbkey.pub

Call the adb commands

If you don’t have adb added to your path, you will need to call adb from the right location;

For Macs;

~/Library/Android/sdk/platform-tools

For Windows;

C:\Users\{username}\AppData\Local\Android\sdk\platform-tools

Once the keys are deleted, calling the below commands will stop the adb server, restart it, and regenerate the keys.

adb kill-server
adb devices