“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:

  • Bash does not use floating point math

    Annoyingly, bash supports only integer operations. In retrospect, this should have been a sign that attempting to create an algorithm heavily dependant on floating point mathematics would be a bad idea in this chosen language! Nevertheless, through the use of bc, a command line calculator tool, floating point math can be achieved somewhat. The main caveat being a loss of accuracy through the need to choose the precision (i.e. number of decimal places).

    e.g. Code like t=$(echo "scale=4; $val*(1-(1-$f)*$sat)" | bc) may cause some loss of accuracy due to the scale value only being 4.

  • Rounding is important

    Unfortunately, I overlooked the importance of rounding errors in the algorithm and at several key stages have converted from a floating point to an integer without taking into account rounding. For example my code would produce 0.99999 -> 0 which is quite clearly a huge loss of accuracy. It is for this reason, I believe, that the algorithm can often produce some unexpected results. I have yet to work on or find a solution to this.

  • Bash does not have a ternary operator

    The ternary operator is one of my more commonly used ‘tricks’ of the trade. I use it frequently in other languages I code in. However, it became clear that bash does not have a ternary operator. This led me to create large if-else structures in the code, that took away from some of the prettier bash ‘one-liners’.

    Simple code such as var h = (r==minRGB) ? 3 : ((b==minRGB) ? 1 : 5); took multiple lines.

    Only in the last few days have I found a solution in bash that would reduce this code above to the following bash: [[ $r = $minRGB ]] && h=3 || ([ $b = $minRGB ]] && h=1 || h=5) - However, this uses string comparison and not integer comparison. (The -eq operator may be of better use in this case)

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:

  • Dear developers, design details matter - Juhani Lehtimaki
  • Introduction to Android Wear: A Glimpse Into the Future - Cyril Mottier
  • Reversing Engineering Android applications (and protecting them) - Enrique López Mañas
  • If I can, you can too: Animations for developers - Lucio Maciel
  • Fighting application size with ProGuard and beyond - Eric Lafortune

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!

Ed


About Ed George

A 22 year old developer from Oxfordshire and graduate of the University of Nottingham.


FOLLOW ME


FEATURED GITHUB PROJECTS

© Copyright 2014-2018