Splahs


“Spla.hs vs Spla.sh”

Learn Me a Haskell

As I mentioned in a previous blog post, I have been recently experimenting with Colour Algorithms in bash.

In that post I discussed, at some length, the hiccups I faced and how Bash was not the wisest of choices.

[…] 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!

Whoops! As I later suggested, another language could be used to make a more comprehensive tool.

I touched upon Haskell at University in two excellent modules taught by Graham Hutton, author of the language’s de facto book ‘Programming in Haskell’ and Laurence Day, a good friend of mine as well as Graham’s PhD student. I am afraid I cannot admit to being especially excellent at Haskell (I believe I gained a first class mark in the introduction module but then slipped quite poorly to a Third in the advanced module a year later), but always enjoy a challenge and happen to know the rough syntax and enough of the basics to put a few basic tests together. It was for this reason that spla.sh became spla.hs and I began the rewrite in Haskell. (Spla.hs - Github Repo)

The Haskell Rewrite

For those that are not familiar with Haskell as a language, I shall provide you a brief summary, although I urge you to go check it out for yourself.

Haskell is a functional programming language that differs from more conventionally used languages such as C, Java, etc. It is statically typed and can be used to provide some of the most elegant looking code imaginable through concise functions that rely heavily on mathematical principles such as recursion and curried functions. It encompasses a completely different programming paradigm and way of thinking to what is often seen as ‘the norm’ in programming and is a powerful tool when used correctly.

Rewriting spla.sh in Haskell has been fun. Despite the project not being completed (as of writing), I have once again fallen in love with functional programming. I hope I can use this love to write some interesting functions in the near future. However I cannot romanticise too much over the writing as challenges, as always, presented themselves.

The Challenges

  • Unreadable Code

    Haskell can provide some excellent functionality concisely which (sometimes) leads to powerful functions at the expense of human-readability. One such example is the group function within spla.hs that takes a list of objects and groups the list into a ‘list of lists’ with the individual lists being of a set length.

    For example:

> group 2 [1..10]

[[1,2],[3,4],[5,6],[7,8],[9,10]]

The source of this polymorphic function is as follows:

group :: Int -> [a] -> [[a]]

group _ [] = []

group n l

| n > 0 = (take n l) : (group n (drop n l))

| otherwise = group (abs n) l

  • Possibilities (and lots of them!)

    Haskell like many programming languages has excellent standard and external libraries (known as modules) available that can perform many specific tasks. However, with such extensive libraries and seemingly interchangeable syntax, it was difficult to find the right way to write certain functions. “To lambda or not to lambda, that is the question.”

  • More conversion issues

    As I mentioned previously in my spla.sh post, I was finding issues when converting to a colour space and then immediately taking that result and converting it back. I initially thought this was an error in rounding but have now come across the same issue once more. This is still under investigation.

> hsvColorToRGBColor . rgbColorToHSVColor $ RGBColor(255,19,45)

RGBColor (255,20,47)

Forwards…

The project is on going and I don’t want to spoil what I am going to add (Just check the issues page on GH!)

If this is your cup of tea, check out the project on Github and lets paint the world in Haskell.

Thanks for reading.

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!

Yours recursively,

Yours recursively,

Yours recursively,

Ed


Authored by Ed George.
Published on 15 October 2014.


Bash


“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


Authored by Ed George.
Published on 06 October 2014.


Initial Builds


Pi-Racey: An Initial Build

My pi-Racey project has been keeping me busy the last week. It has progressed significantly in this time, as described below.

Initial Research

The initial research for the project, as mentioned previously, pointed me in the direction of an example project by the tech company Kaazing.

This project used the popular Raspberry Pi Java library Pi4J to provide an interface to the Pi’s GPIO pins. It also used web sockets to communicate between the Pi and a remote in the form of a website.

As mentioned in my last post, web sockets could potentially be problematic due to there being no guarantee of reliable WiFi in an area where the car should be useable.

This led me to research other possibilities of wirelessly controlling the car.

  • Infrared: Commonly used in television remotes and other devices but requires device and sender to be in each other’s line of sight.

  • Original Remote Control: The original remote control of the car could be modified so it’s signals are picked up and handled by the Raspberry Pi instead of the original receiver. However, this could be difficult and require a detailed electronics knowledge.

  • Bluetooth: Arguably, the most sensible option available. Bluetooth’s max range is around 100m and is present in many devices, such as mobile phones, that could allow easy connectivity to provide control to the vehicle. It was for this reason I decided that Bluetooth would be used to control pi-Racey.

Bluetooth Options

Through the use of a Bluetooth USB adapter, the Pi is able to use the Bluetooth wireless exchanging standard.

Following the Kaazing project, I searched for a Bluetooth library that could be used with Java and Pi4J. This led to BlueCove, an open source JSR-82 implementation of Bluetooth written in Java.

The library provides a bridge between the application layer of the Java VM and the Bluetooth stack/controller and can be used to pair devices, as well as send messages between each device.

However it was clear from the beginning that the library, despite providing a potential solution, was complex and would make a relatively simple task (i.e. pair a device) a lot of spaghetti code that is difficult to understand for anyone unfamiliar with the library.

For this reason, I considered other options.

Wiimote

Through some further research, I discovered the CWiid project, a collection of Linux tools written in C for interfacing to the Nintendo Wiimote on Linux platforms.

A Wiimote

The Wiimote is a wireless peripheral for the Nintendo Wii games console that uses Bluetooth to allow the device to be used as the console’s remote. It has a number of buttons and a directional pad that could be utilised to control the car.

The main advantage of using a Wiimote is the CWiid library makes the connection between the Wiimote and any Bluetooth adapter used with the Pi and can easily interface with the buttons on the remote.

To continue the project, I decided to scrap the use of Java and Pi4J and move to Python as the python-cwiid and python-dpi.gpio libraries allow easy programming with both the Pi’s GPIO and an external Bluetooth Wiimote.

Setup

To start testing on the Pi, the system will require multiple libraries and drivers. These can be easily installed through the following commands:

$ sudo apt-get update

$ sudo apt-get upgrade

Update packages and packages list

$ sudo apt-get install --no-install-recommends bluetooth

Install bluetooth drivers to allow communication to bluetooth devices, such as the Wiimote

The parameter ensures only the bare essentials of the bluetooth driver is installed

$ sudo apt-get install python-cwiid

Install the CWiid Python library

$ sudo apt-get install python-rpi.gpio

Install the Python Raspberry Pi GPIO library

Once a compatible Bluetooth adapter has been plugged into the Pi, the status of the Bluetooth service can be tested through the use of sudo service bluetooth status - This should return a message of [ ok ] bluetooth is running. which indicates Bluetooth is running correctly. Should any other message appear, the Pi should be restarted.

Once Bluetooth is running correctly on the device, the Wiimote can be visible to the Pi. This is easily completed using hcitool.

Whilst pressing the 1 and 2 buttons simultaneously on a WiiMote, run hcitool scan on the command line to view all visible bluetooth devices. A device found that uses the name of “Nintendo RVL-CNT-01” indicates a Wiimote is visible.

Finally, a test script can be used to test out the Wiimote and the GPIO’s working in harmony.

Test Results

Using this Python script (wii_connect.py), I was able to create a simple test along with a simple bicolour LED circuit. Pressing the A button creates a red light and pressing the B trigger shows a green light.

The video below shows this test in action

See the Wiimote in Action

Finally…

I shall detail the next few stages soon. There is still plenty of coding to complete and many electrical component to add.

For more updates please visit the pi-Racey website, or tweet me @EdGeorge92.


Authored by Ed George.
Published on 20 April 2014.


Piracey


Pi-Racey: On Your Marks…

Working at Boppl has, over the last 10 months, led to some exciting opportunities for me but the latest in-office challenge has brought the best of the techy/geeky sides out in all of us.

The challenge, presented to us by our CEO, was as follows:

With a budget of £200, create the best remote control car you can subject to the following rules:

  1. No pre-built Cars - Cars must be in the form of kits
  2. Images of the cars being built must be submitted to show you were the sole creator of your vehicle
  3. All cars must cost less than £200 (Half of which will be subbed) and all parts must be sourced from the UK
  4. All cars must be electric. Petrol cars or other engines are not allowed.
  5. You have 3 months (roughly) to complete your car
  6. (More rules can be added at any time)

The competition will compose of a series of tests that will put the cars up against each other and test numerous factors of the cars design. These tests are TBC, as are any prizes.

Many of the team went for the approach of purchasing professional looking kit RC cars such as Dark Impact to enter the competition. Clearly these cars can be upgraded through the purchase of components to replace their counterparts found in the kit. This allows cars to have faster motors, bigger wheels or even larger batteries. However, this approach did not suit me. I wanted to do something different and enter the challenge in my own unique way. Pi-Racey was my idea.

Pi-Racey - The Concept

Having recently purchased a Raspberry Pi and tinkered with electronics using the Pi’s GPIO, I wondered how I could compete by using a Raspberry Pi to control an electric remote controlled car.

Through some initial research I came across a sample project from Kaazing that used web sockets to control a remote controlled car via a RaspPi and a website. I decided that I would use this project as a guide and ask if I could compete using this method.

The main issue with this approach would be the almost certain breaking of Rule 1, as the car would likely require to be pre-built to house the Pi and the components correctly. I requested that my car should be exempt from this rule and permission was granted on the grounds that idea was a novel solution.

This mini-blog will document my progress over the next few months in the completion of my car, that I have named pi-Racey.

Unique Constraints

The Kaazing project, as a guide, should help provide the basics of how to build the car through multiple additional components. But I imediately noted some unique constraints that will mean pi-Racey will require the Kaazing project to be modified. Such constraints include:

  • Wi-Fi: There is no gaurentee the location the tests will be held will have Wi-Fi and therefore web sockets may not be a valid solution
  • Electronic Expertise: I have only a very basic knowledge of electronics and curcuit building whilst this project will contain a lot of moderately complex electronics
  • Time & Money: Subject to the rules - I only have limited time and money to complete this
  • Experience: I have never attempted a project such as this previously. I am not sure where to start, where to source materials and whom to ask advice from!

I am hoping that in the upcoming months, these issues are addressed and I am looking forward to seeing how these affect the project.

Goals

The goals of the project are simple:

  1. Win. - However unlikely this may be, I want to produce the best car I can and add a new spin to the competition.
  2. Produce a fully functioning Raspberry Pi controlled RC car.
  3. Make any source code for the project open source under the MIT License and release it on my GitHub.

What next?

The competition has only just begun. I shall attempt to post regular updates on how the project is going.

For more updates please visit the pi-Racey website, or tweet me @EdGeorge92.


Authored by Ed George.
Published on 16 April 2014.


Breedr Intro


Background

It is no secret, to those that know me, that I have an unhealthy obsession. An obsession that has consumed much of my free time since the late 90’s and that will no doubt to continue well into my adulthood. The obsession I refer to is, of course, the crazy world of Pokémon. To some it is a childhood memory, but to millions it is as big now as it has ever been in its near 20 year existence. It has a well established online community that continues to grow year by year.

The latest Pokémon games (X & Y), the first non-spin off Pokémon games partially in 3D, have boosted the franchise to new levels. Increasing numbers are becoming interested in the more advanced concepts and mechanics within the games. These include the breeding mechanic, EV training and shiny hunting.

It is the breeding mechanic that interested me primarily and led to the concept of Breedr.

An Introduction

Breeding is a simple concept within the game:

Pokémon breeding is a method of obtaining a new Pokémon by producing and hatching an Egg. The new Pokémon will inherit certain traits from its parents and this can be controlled through the use of breeding items. Movesets, Abilities, Capture Ball and IVs can all be passed down.

However, the mathematics behind the scenes are slightly more advanced.

The Breedr project was born from my interest in these mathematics and Android development. Very few “Breeding” apps exist for the platform and the overall quality of existing apps is extremely poor. It became my goal to create an app that is both useful for “breeders” and visually appealing.

The app will provide key information to breeders to help them make more informed decisions about their breeding strategy based on their overall goals.

(I will discuss specific features in future, but for the time being I will be keeping these private.)

The Future

The app has been in development for a number of months on an extremely part time basis. Unfortunately, due to other commitments, the app has not progressed especially far in this time and this schedule will continue ‘ad interim’.

I can reveal that the app will support devices running Android 1.6+, meaning nearly 100% of Android devices currently in use around the world will be able to run the application. I wanted to make the app accessible globally and target both older players as well as younger players of the games.

Furthermore I can also reveal that I intend to release the application for FREE. The current plan is that app will also contain no advertising. I am a firm believer in free software and believe that an application such as Breedr, despite having a huge target audience, should allow users a great user experience and provide a great service without bombarding users with intrusive advertising.

My stance on this may one day change, but at this time of writing I believe that it is highly unlikely to be the case in the distant future. I may look into the in-app payment route for additional features, but one of my key goals is to keep the app accessible to all.

It should be noted that no iOS release is currently in the works. Depending on the success of Breedr, an iOS version may be created.

Get Involved

The project has just begun and with no release date or timeframe for the completion of the project, I may struggle to find enough time to dedicate to Breedr.

I would welcome and be so grateful for any help from Graphic Designers, Programmers, Web Developers etc. on this project as I believe the end product could be widely used and successful in the community.

Please do not hesitate to contact me at esm@hotmail.co.uk if you wish to get involved.

More information will be released shortly.


Authored by Ed George.
Published on 27 March 2014.


Boppl Android Out Now


After months of development I am proud to announce the launch of my debut application Boppl. The app allows users to order food and drink at selected venues using a mobile device.Ordering with Boppl allows you to spend more time with friends, rather than waiting for service or in a line. It also lets you order your next round of drinks, even on your way to the next bar.

alt text

Check it out.


Authored by Ed George.
Published on 03 March 2014.


Breedr


This is a test post.


Authored by Ed George.
Published on 22 February 2014.



About Ed George

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


FOLLOW ME


FEATURED GITHUB PROJECTS

© Copyright 2014