“Thou shalt not kill -9”

Using bash for fun and profit.

Over the last few weeks I have attempted to refresh my memory and hone my skills in bash scripting.

Having missed the opportunity to take a course in Unix & Software Tools at University, a decision I regret almost daily, I decided recently to start a couple of projects to refresh my self confessed ‘average’ knowledge of bash and learn some more.

I now use the command line every day. It is a necessary and vital tool on the toolbelt of any developer, but is quite often overlooked and very rarely used to its full potential. My initial knowledge of the bash shell came from the bare necessities required at University to list, copy, move and delete files. It was only through joining Boppl that I began to use the command line for slightly more ‘complex’ tasks such as accessing our API and version control using git. However, I was evermore aware that this still constituted nothing more than a basic understanding of scripting in bash. The solution to this was attempting to learn harder techniques through a couple of ‘harder projects’.

The projects I chose were both work related, as my job can have some tedious and repetitive command line commands. I can only speak about one of these in depth as I wish to keep Boppl’s inner workings a closely guarded secret.

Problem 1: Build Scripts

As mentioned, I will not go into great detail with this project. In summary, it comprised mainly of automating some build scripts in bash and meant the cleanup surrounding builds was performed and ensured project assets were present and formatted correctly.

This closed source project, amongst other things, gave me interaction with sed, a stream editor utility that can be used to manipulate text.

A simple, and possibly crude, example of its use is a simple ‘find and replace’ script:

sed -e "s/android:versionCode=\".*\"/android:versionCode=\"${VERSION}\"/g" $FILE

This was used to replace version codes within files ($FILE) and replace them with a predefined version ($VERSION).

Due to the project’s nature, further usage will not be discussed.

However, these scripts will likely be moved to an ant script at a later date - as is normal in Android Development.

Problem 2: Color Scheming

It was becoming an increasing problem that generating and choosing some appropriate colours for some app assets was leaving people undecided with what colours were working best.

“We need a more yellowy-green”

I felt that site’s such as Adobe’s Color CC were taking me a little too long to find multiple colours that may meet requirements despite it’s clear UI. What I wanted to do was automate the process, have a colour scheme and then be able to parse it to generate a list of analogous colours that could be used elsewhere and still fit with the scheme.

My spla.sh open-source project was the result of this. Through a simple bash script, spla.sh can give a list of monochromatic colours for a single hex RGB encoded colour.

e.g. ./spla.sh "#120E23" returns #110E22 #1F183C #2C2255

The project is still in active development and does have a few critical bugs that beed ironing out but for the most part works well. (If you are interested in helping out, please make a pull request or drop me a message!)

The basic algorithm I created first extracts the numeric RGB components from the colour string: r=$((0x${COLOR:1:2})) g=$((0x${COLOR:3:2})) b=$((0x${COLOR:5:2}))

and then converts this into a hue-saturation-value (HSV). A modification value is applied and then the resulting HSV is converted back into RGB space. This is repeated multiple times until a list of colours is formed.

Issues Found

With this being my first major attempt at programming something vaguely useful in bash, it was inevitable that I would run across issues.

I have decided to catalogue the major ones I faced in hope that they may prove useful to others in the future:

Future of the project

The project was a steep learning curve and is for the time being ‘still active’. Meaning if I learn any new tricks and tips about bash, I will endeavour to add them to the project if they are applicable. I will also be taking pull requests should anyone wish to contribute and/or bug fix.

I won’t be adding any more functionality to it in the near future. But I may port the code and algorithm to another language in the future. (Haskell or Python are strong contenders for this)

So what’s up next?

What do I have in the works? Well first and foremost, in the near future I will be aiming to attend more meetups - particularly The London Android Meetup, London Dev-Ops and DS London. I would actively encourage anyone that has never attended one to try it out. People are usually extremely friendly! It’s an excellent chance to talk to some really interesting people, see what people in your field are doing and maybe even a chance get invited to join some cool projects. (If you don’t like people, there is also on occasion pizza and beer!)

Secondly, I am attending the Droidcon conference at the end of this month (Oct 2014). It is Europe’s largest Android Developer conference and a huge opportunity to see some talks from major players in the ‘Android world’. I have attempted to compile the list of talks I plan to go to and so far chosen:

A real smörgåsbord of Android subjects, that hopefully will live up to the excitement I feel when I read about them.

I shall attempt to blog about the talks and conference in the future.

Thanks for reading.

As always, if you like what I do, have an idea I can help with or find numerous bugs in my code - please visit my github, or tweet me @EdGeorge92. I am always interested in new cool projects and learning where I have gone wrong!