The number seven is interesting, and not just because there are no uninteresting numbers. For one reason or another the number has taken on a mystical quality in various cultures, not least in the office where it now surely holds the distinction of being the ‘most said number of the year’. Incidentally, we are not in general numerologically inclined, but hexakosioihexekontahexaphobes will be pleased to hear that there will probably not be another maintenance release after 6.6.5, despite what would have been the serendipitous proximity of Hallowe’en, the perfect date to unleash it.

There seems to be a certain memorable quality conferred on any set of seven things, and as such seven has become the de facto target for the quantity of a would-be interesting collection. Science, literature and life are littered with examples – Wonders of the Ancient World, colours of the rainbow, deadly sins, to name but a few. 

I am a fan of puzzles. These can be various sorts of puzzles, although the ones that really get my attention are the sort that are generally only found in a so-called “puzzle hunt”. To the uninitiated, these are strange variations on the traditional puzzle – they contain no instructions, and there is always an answer (usually a single word or phrase) as opposed to just a puzzle in a solved state. It turns out that sets of seven is a relatively common theme for these puzzles. Here are two examples (one from a puzzle hunt that is ongoing):

Li Ven Se Tt Le

Quadratum

The point is, for me working from start to finish on LiveCode 7 was in many ways similar to the process of solving a puzzle hunt. In fact, it probably ought to be similar in precisely seven ways, so lets see if I can shoehorn this section into a thematic format. I present a Buzzfeed style list:

Why working on LiveCode 7 is similar to solving a puzzle hunt. 

1. There is a way in

Since there are no instructions, the best puzzles tend to have an early hook to bring you into the world it inhabits. This can be any number of things, perhaps it has the presentation of a traditional puzzle such as a crossword, or perhaps it has some basic questions to answer, images to identify, facts to gather. Sometimes all you have is a pun in the title.

At the beginning of the refactoring project, my main task was to separate evaluation and execution in LiveCode syntax. Every function, command, operator, control structure, and constant in the language of LiveCode has a syntax class which is responsible for resolving expressions or performing actions in the appropriate way. We wanted the resolution of  subexpressions to be completely distinct from the execution. 

 In the first cases I encountered, this could be as easy as simply creating a new function in the engine, cutting a section of the syntax class implementation, and pasting it into the new function. Of course even in a simple case, one needs to read what is actually happening to make sure it is the correct thing to do. This was my way in; learning about LiveCode syntax and how it works; being brought into its world.

Here is an example of one of the more simple refactoring tasks. At the other extreme, refactoring the chunk object was completed with approximately 20 commits. 

2. It consists of a multitude of multi-stage processes

Another thing that distinguishes puzzle hunt style puzzles is the fact that they are generally multi-stage puzzles. There is rarely just one thing to do to get the answer. Sometimes it is not clear how many things will have to be done to complete the puzzle. The analogy here is clear – the many tasks necessary for the completion of the refactoring project all tended to break down into multiple subtasks. On a number of occasions, the details of the later stages of a task were not revealed to us until we had to do them. Of course, like some puzzles, this means that some stages of the project were fairly epic. Some lasted days, others weeks, still others months. That is to be expected, I suppose, when dealing with something on this scale. But the fact that the work would apparently have taken one person almost a decade to complete still boggles my mind. 

Usually a puzzle hunt will try and have a wide variety of puzzle types, testing many areas of skill: linguistic, logical, mathematical, artistic and musical puzzles abound. There is a certain polymathic requirement when dealing with the LiveCode engine too. While most of the engine is written in C++, parts of it are in Objective C, and parts of it are in Java, and when you are supporting many different platforms that means dealing with different APIs from all the operating systems. Just like a puzzle hunt, you have to be prepared to acquire a new skill just for one specific task. You often find yourself becoming an expert in rather strange areas. Like Roller coasters and knot theory. 

3. Organisation is paramount

The elements of the refactoring project that went the most smoothly were of course those for which we had been able to dedicate a good amount of time to planning and tracking. The trail of spreadsheets and documents in my Google Drive is longer than my virtual arm. This also relates in part to the previous point. The more subdivided the task, the easier the documentation of progress, and the better documented the progress, the more that progress is a boon to the project as a whole.

 I and the rest of my puzzle team have frequently found that a suitable organisation of the information gathered is sufficient to spark the next idea, or to unstick oneself. I’m trying to get the phrase “Sometimes it takes looking at different data on three laptop screens to work out how to solve a 3d maze and apply those directions to a Rubik’s cube (last page)” into general usage, but I’m not sure it will catch on.

Refactoring is in itself just a form of organisation. The codebase now is far more readable than it was before; which of course was one of the motivations for undertaking the project in the first place. It is important for people to be able to contribute to an open source project, and clearly the easier it is to understand what is already there, the easier it is to contribute. 

4. It involves looking at a lot of unfamiliar Unicode codepoints

And sometimes understanding them

And sometimes knowing how they are made up

And sometimes switching to different keyboard layouts

 Changing LiveCode’s internal string representation to accommodate Unicode has taught me untold amounts about the scripts used in various countries around the world. The integration of the text shaping library Harfbuzz (so that scripts such as Arabic, Khmer, and Devanagari look as they should on Android devices), amongst other things, resulted in an input source list that looks like this:

On one occasion, such keyboard switching had me completely locked out of my Ubuntu virtual machine, due to not being able to switch to English layout without logging in, but also not being able to actually type any of the characters in my password without switching to English layout. 

5. It requires concentration and attention to detail

Sometimes this is attention to small details in situations where there is not much information. Or in the case of this puzzle, extreme attention to detail (warning: attempting to solve the latter puzzle is a surefire route to madness). Other times it is a case of not trying to understand everything that you’re looking at, just the relevant parts. Like this. The aforementioned chunk object is so fundamental to LiveCode that even a slight mistake in refactoring it caused the LiveCode IDE equivalent of the blue screen of death (which happens to be a white rectangle with the “revLibURL” button on it).

 When replacing c-strings with MCStringRefs in the code, it was frequently the most efficient strategy to merely ensure that the behaviour was identical to what it was before, without completely understanding what the function was doing as a whole. 

6. It sometimes feels like it will never be finished

Getting stuck is a fact of life. Even more so a fact of puzzle hunts. Puzzles have a phase known as ‘extraction’, whereby the answer is obtained using all of the information that has been gathered and worked out. This can be as simple as using some numbers to index some words, or an acrostic that appears after sorting alphabetically. Other puzzles have more intricate extractions mechanisms, and some of the most beautiful involve iteration of procedures from previous parts of the puzzle. In any case, extraction can be very difficult, and it is therefore a very common place to get stuck.

Likewise, the period of time between being “basically” finished with LiveCode 7 and actually being finished felt like an eternity. I say actually finished, obviously there are some things to clean up, some residual bugs and so on. But we’re putting away the syntax caravan, and work is already underway on the widgets and themes project that will form the basis of LiveCode 8. In fact, I would like to get the phrase “putting away the syntax caravan” into general usage to mean almost finished. “How’s that novel coming along?” “Well, it’s not done, but I’m putting away the syntax caravan, if you know what I mean.” “No, I don’t know what you mean, Ali. Stop saying that.”

7. There are many ‘aha’s

The ‘aha’ or lightbulb moment is probably the reason why people who do these puzzles do them. It can be quite exhilarating, the joy of discovery, and is certainly quite addictive. One of the closest real-world experiences to the idealised puzzle ‘aha’ is solving a programming problem. There is a huge amount of satisfaction that comes from finishing off anything, particularly if it has involved an element of mystery, triumph over adversity, and especially if it is completely and utterly epic in scale. The refactoring project ticks all these boxes as far as I’m concerned. And there were ‘aha’ moments in spades. 

Caveat: Why working on LiveCode 7 is not at all similar to solving a puzzle hunt

I mentioned before that there is always an answer to a puzzle hunt puzzle. There is also usually a ‘metapuzzle’, which involves using all the answers to all of the individual puzzles in the hunt. Well, here’s where the analogy completely breaks down. There is not single phrase answer to the LiveCode engine. Like a more traditional puzzle, the best we can say is that it is in a more ‘solved’ state than it was when we started. But that is still deeply satisfying, and a goal I’m happy to have spent my first two years working towards.

Solutions:

Quadratum

Please Remain Seated

Contortionist

English Expectations

Cryptograf

Symphony from the Old World

Circulus In Probando

Team Statistics

and finally

The LiveCode Engine

For the past month I’ve been delving deep into the LiveCode IDE, with the purpose of preparing the product to be localised, so that strings in the UI are in the users’ language of choice. Simultaneously, I have been learning a new programming language myself. 

One of the newest members of the LiveCode Development team, I joined in September fresh out of University looking forward to immersing myself in the world of software development, and picking up a new programming language to boot. I was excited to learn LiveCode, and seeing how well I’d be able to pick it up – as surely that’s the point, after all. 

After a day of settling in and getting myself set-up and ready to work, I began my first project, localising the IDE. Initially, the project required me to trawl through reams of LiveCode script, looking for strings that would need translating, making a note of these strings and passing these strings through a dummy function. The dummy function just returned the strings in all capitals, making it easy to see what had been “translated” and what hadn’t. Ultimately, the localisation function would return the string in the user’s selected language, but for now the project just required that the IDE was prepared for translation and everything that would need eventual translating was documented. 

The first stage of the project, while laborious, was an excellent learning curve for me. I was able to get in to the nitty-gritty of the product, see LiveCode being put to use and begin to write a small amount of LiveCode script of my own. I also got to see the ups and downs of changing the IDE through the IDE – a challenge in and of itself – instantly being able to see changes made or managing to break the IDE with one typo! It also highlighted how the product wasn’t designed with localisation in mind, as I came upon obstacles to translation such as images with English text in them.

The next stages, which I am working on now, involve me preparing the strings for translation, creating a tool for the translators and writing the localisation function. It was in these stages of the project that I was really able to start writing my own LiveCode script. Not only was I able to start doing this with relative ease, with some questions for specific situations, I quickly found myself able to fire off script in LiveCode as if I were writing some text in English. Having done a bit of programming at University and an internship in mobile development, I am not a complete novice when it comes to programming. However, I was impressed at how natural programming in LiveCode felt and I’m pleased to be part of a project that is making the product more accessible to budding developers around the world. 

Encouraging Children to Code

Another three unlikely suspects to combine into a JoJo Blog Post about coding? Well, maybe not! 

Who: Facebook, HRH Prince Andrew the Duke of York and Peter Capadli, the most recent appointment to play the notorious Time Traveller, Dr. Who! 

Why: To encourage children to learn to code of course! 

See it now? Not quite? OK, I shall explain..  

There is a growing revolution in the UK and Europe to encourage children to code and to raise awareness of the capacity for children to code from a much younger age. The ideal is that all children will have access to tools to allow them to develop programs and apps, making the digital world an integrated part of their everyday life, in a way that suits them. 

The discussion of coding is far more prevalent now than it ever was and it is easy to see why. By capturing young minds we set a path for the future and by educating them and providing them with the right tools, we support them in their journey. 

Many businesses are striving to be a part of this revolution, so why are these particular people standing out in striving to support this cause? Well in a sea of articles, these are the ones that most interested me.. and after all it is MY Blog Post, so I thought I would share!

Facebook has joined forces with other industry influencers (including Microsoft and Rovio) and has formed a coalition to launch a pan-European online platform to drive participation in coding.

In September, coding in English schools was made mandatory for all children aged between 5 and 16 years old. Particularly interesting then is to hear that 3 young coding enthusiasts from the UK have beaten off European competition to win the gaming contest. 

The Kodu Kup is where teams from the UK faced competition from Portugal, Finland, Norway, Belgium, Greece, Lithuania and Estonia to battle to a Dragons’-Den style final, complete with selling pitch! 

One of the most enlightening statements I read came from one of the Team Winners, Alfie, who felt that the team work involved and playing to its strengths was key to their success. He said:

Speaking recently at the TeenTech Awards, presented at Buckingham Palace, HRH Prince Andrew said there needs to be a “culture of enterprise” to help young people turn technology ideas into commercial products and suggested that coding would be a key part of skills required. 

The Prince is patron of the Awards, which encourages young people to “recognise that science and technology are the basis of how we are going to be prosperous in the future”. The Awards competition which aims to encourage teenagers to get involved in inventing and designing was developed by science television presenter Maggie Philbin and backed by actor Stephen Fry and Top Gear presenter James May. 

Of course you’re screaming.. get to the good bit – WHY is Dr. Who involved??

 It was announced at the beginning of September that the British Broadcasting Corporation (BBC) had published computer programming study guides, quizzes and other support materials on its Bitesize site to coincide with the newly introduced computing curriculum in England. They have also revealed details of several programming themed children’s programs set to air late autumn.

 Uh-huh.. Dr Who???

Well my favourite initiative – as I am a total Dr Who geek*.. yes, you may laugh – was announced yesterday.

In an article featured in the Technology section, the BBC unveiled the launch of their new Dr Who game, in which you take control of a ‘friendly’ Dalek and navigate a series of challenges. Rather than just your standard game, the challenges involve you solving different problems using coding, to move onto the next level. 

The online game, aimed at 6-12 year olds, is voiced by Peter Capaldi, the Doctor himself and was written by Doctor Who TV series writer, Phil Ford. 

The game will be available to play for free on the CBBC website from Wednesday October 22 and I know I am going to be giving it a bash.. will you? 

Have you seen any interesting articles, blog posts or competitions lately, aimed at getting children into coding? Do share!

*JoJo Hernandez is our Finance Director, Fashion Lover & self confessed *Whovian! 

If you like to tinker with maths and are looking for more exotic operators, for example to calculate the Factorial or the Fibonacci series, then this is something you are going to have to implement yourself in LiveCode. But there is no need to despair, this can be done pretty much with a single line, wrapped in a function definition.

MATHS HAZARD – You may skip the following paragraph if you are not a friend of mathematical definitions.

The Factorial of a non-negative number n can be defined as the product of all of its positive integers that are less than or equal to n, with the Factorial of 0 returning 1. The operator for Factorial is denoted by an exclamation mark (!), allowing us to write the operation as follows: n!

The following example demonstrates how Factorial is calculated for the number 6:

6! = 1*2*3*4*5*6 = 720

Now this does not seem to be too much of an issue to implement or write, but how do you go about writing a function in LiveCode that does all the heavy lifting for you, so that you do not have to write a long sequence of multiplications?

Well, there are fundamentally two algorithmic approaches you could consider. These are iteration and recursion. They both operate in quite different ways and have advantages and disadvantages.

Let us look at the iterative approach first, as this is possibly the programming paradigm most people are familiar with. 

We create a function that takes an argument for which we are calculating the Factorial product. This function then cycles through all the positive integers that are less than or equal to the initial argument and multiplies all of these integers together. The function result is the Factorial result.

function factI x
  local tProduct = 1
  local tCounter
  repeat with tCounter = 1 to x
     multiply tProduct by tCounter
  end repeat
  return tProduct
end factI

Now in order to implement this algorithm we need two local variables and a repeat loop. This keeps track of the result as it is being updated through each iteration of the loop. But what if you really do not want to be bothered with local variables and loops and keeping track of data?

Well, meet recursion. Recursion can remember all the data that is specific to an instance of a function call. This means that we can pretty much throw most of the code away that we use in the iterative approach. Yes, we do not need local variables and we do not need a repeat loop. In fact, we can calculate the Factorial of a number with a single line of code in a function.

A recursive implementation usually contains some kind of condition check so it knows when to stop and when to call itself. This has been implemented in the following code using an “if then else statement”. If we are below a certain value stop, otherwise call the function again, but with a changed argument.

function factR x
  if x < 2 then return 1 else return factR (x - 1) * x
end factR

Now that was not too painful, but what is actually going on here that allows us to write code that is so much shorter?

Consider calculating 6! and let us expand how factR calls itself at each recursive level:

Level 1: factR(6)
Level 2: (factR(5) * 6)
Level 3: ((factR(4) * 5) * 6)
Level 4: (((factR(3) * 4) * 5) * 6)
Level 5: ((((factR(2) * 3) * 4) * 5) * 6)
Level 6: (((((factR(1) * 2) * 3) * 4) * 5) * 6)
               (((((1 * 2) * 3) * 4) * 5) * 6) = 720

Note: The parentheses demonstrate the execution order at each level and are not intended to be interpreted in a mathematical sense. The commutative law applies.

So this gives us a total of 6 calls to the function factR for 6! 

Another number sequence we mentioned in the beginning is that of Fibonacci. This sequence received its name from Leonardo of Pisa who published the historical mathematics book “Liber Abaci” around 1202. Leonardo of Pisa was also know by the name Fibonacci.

This Fibonacci number sequence starts: 1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,. . .

 This sequence has fascinated mathematicians for centuries and reveals remarkable patterns that are very much linked to natural structures, such as the formation of shells, branches and even the arrangement of the seeds in sunflowers. My particular interest is the use of the Fibonacci numbers for the close approximation of the Golden Ratio.

A Fibonacci number is generated by calculating the sum of the previous two numbers in the Fibonacci sequence. This operation is quite different to that used to derive the Factorial number sequence, never the less, it is possible to also wrap this into an iterative and recursive implementation.

Calculating the Fibonacci numbers iteratively requires additional local variables, compared to calculating the Factorial numbers. We step through all of the Fibonacci numbers and create the next ones by adding the previous two numbers together.

function fibI x
  local tFirst = 1, tSecond = 1
  local tCounter, tSum
  repeat with tCounter = 3 to x
     put tFirst + tSecond into tSum
     put tSecond into tFirst
     put tSum into tSecond
  end repeat
  return tSecond
end fibI

 In order to implement this algorithm we need four local variables and a repeat loop. As with the Factorial calculation, this keeps track of the result as it is being updated through each iteration of the loop.

The recursive approach can again do away with local variables and the repeat loop, creating the implementation as follows:

 function fibR x
  if x < 3 then return 1 else return fibR (x-1) + fibR (x-2)
end fibR

 Now I am not going to demonstrate how the recursive levels are expanded here and would like to leave this for the reader to explore. What I would like to add is that calculating the Fibonacci number for 6 calls fibR a total of 15 times.

Now recursion (or meta programming as it is sometimes referred to) is great as it can really reduce your code and hide a lot of the complexity, but beware. Some algorithms are better suited to recursion than others, and recursion can be computationally more expensive than iterative approaches. For example, calculating 20! calls factR 20 times, and that is great. Calculating the Fibonacci number of 20 calls fibR a staggering 13529 times.

Ah, the good ol’ Android Emulator….Many a support request has come in regarding this, mainly to complain of how dog slow it can be especially in comparison to the iOS simulator.

The main reason for the speed difference between both is that the Android “Emulator” is physically emulating the software and hardware of actual devices whereas the iOS “simulator” is only simulating the iOS operating system and has full access to all of the system resources (e.g. CPU, GPU etc)

With the above in mind, an Android Emulator is good if you’re starting with Android development or if you are in a pinch but ideally testing your application on a physical device gives you the best experience and doesn’t leave you wanting to pull your hair out.

With that being said, there is an alternative “Emulator” that I have used in the past and it has also recently been brought to our attention via support (Thanks Fulvio), which provides far superior performance compared to Google’s “out of the box” Emulator.

The software in question is Genymotion and is available to download from:

http://www.genymotion.com/

There are many versions available, but the Free version should provided you with everything you need to get testing your apps at super speed!

Now, its not a simple case of installing Genymotion and off you go, there are few things required in order to make this emulator work with a LiveCode built Android App. In order to save you from throwing your computer off the wall, I will now go through the GenyMotion setup step-by-step 🙂

Here we go:

1. The first thing you will want to do is download Genymotion and install it on your system.  

2. Genymotion runs an emulator within a Virtual machine with Virtualbox being the software that it uses for this purpose. So, the next thing to do is head over to https://www.virtualbox.org/ then download and install the latest release of Virtualbox.

3. We are now at a stage where we can run the Genymotion executable, so let’s do this.

Once launched, it will present you with the following screen. Select “yes”:

4. You will now be presented with the “Virtual Device Creation Wizard”. In order to create a new device, you will need to sign in with your Genymotion account. After you have signed-in, you will be presented with a list of emulator copies of all of the latest Android Devices.

5. For simplicity, I am going to create an emulator using the first option of “Custom Phone- 4.4.1-API 16 768 x 1280”. So I select this, and press “Next”. This then allows me to name my emulator, I leave the name as its default value and press “next” again. This will then proceed to download this emulator for use:

If all goes as expected, a “The virtual device has been successfully created” message screen will appear:

6. After the device is created, press “Finish”. This will take you back to the “Your devices” screen. From here, you can select your device and press “Start”:

7. After around 10 seconds of loading ( Retina MacBookPro), the emulator is up and running and oh my…..is it fast!

8. Now fire up LiveCode, and if you already have this setup for Android development and have a stack open which has its deployment platform set to Android, you should see the Genymotion emulator in the list of “Test Targets”..so good, so far 🙂

9. Now…try to deploy your stack to the emulator… uh oh….”Houston, we have a problem”

The error that occurs in the emulator is due to the incompatible architecture that a LiveCode built Android APK uses. LiveCode builds ARM based Android standalones (as around 99% of Android devices use this architecture) whereas, Genymotion is built on x86 architecture.

Don’t worry, I haven’t strung you along and there is a solution to this which involves installing an ARM translation library. All of this is explained in the following XDA developer post-

http://forum.xda-developers.com/showthread.php?t=2528952

With the main steps we need being 1 – 4

So basically, you have to download the ARM translation installer zip, drag it onto the Genymotion emulator, accept the flash and restart the emulator after the flashing has finished. (to restart, simply quit the emulator and re-launch)

10. Now if everything has went as planned, you should now be able to deploy to the emulator from within LiveCode 🙂

TAADAA! Here we have Sheepherder running in Genymotion with the performance being on par with any physical device.

Thats it! I hope you find this useful when it comes to testing your LiveCode Android Apps along with making  your Android development a more enjoyable,fun and stress free experience 🙂

Please let us know how you get on in the comments below or if you have any other emulator related tip/tricks

Building LiveCode 

We have been very busy in the RunRev office this period. Among all the other things we are doing, we are producing Release Candidates for both LiveCode 6.7 and 7.0. In the meantime, we are fixing some bugs that were introduced  as a result of the iOS 8 release. These fixes will be contained in LiveCode 6.6.4, and then rolled up to 6.7 and 7.0. They include updates in various parts (engine code, IDE code, dictionary entries, release notes etc).

When everything is ready, all these different pieces have to be brought together to a complete product, and nicely packed within an installer. This is done through the process of building. After building the installers are uploaded to http://downloads.livecode.com/livecode/ webpage, but are not immediately accessible to the public. At this point, they are thoroughly tested, not only by RunRev developers, but also sometimes by some of our most experienced community members. Once we make sure that everything works as expected, the installers become public and are available for all the users to download.

The first time I did a build was for LiveCode 6.7 DP5, and since then I have done most of the 6.7 builds. In this post. I will briefly describe you the process of building, as I first experienced it.

I was really surprised to find out that for building LiveCode, we use … LiveCode(!),  for a significant percentage of the process. Theoretically, it is possible for 100% of the process. However, in order to resolve more easily merging conflicts between the various bugfixing or feature branches, we use some other tools as well.  

The LiveCode stack that is used contains facilities for building LiveCode engines, docs, notes, installers, and server engines for all platforms. It looks like this:

 (I have slightly changed the location of the buttons to fit the width of this post!)

The first thing to do is make sure that all pending and already reviewed pull requests are merged  into the develop branch of the main LiveCode GitHub repository. If not, we have to merge them, and resolve conflicts, if any. After that,  the develop branch is ready to start building from. Note that the develop branch is used only for LiveCode 6.7 builds. For other LiveCode versions, different branches are used.  

Then, using the above stack, we generate the public key in the Environment stack. This is used to sign the LiveCode app, and is needed for the commercial license activation.

The next step is the actual build of the LiveCode engines, for both the community and commercial version, for each platform. We use Xcode for MacOS and iOS, a top level Makefile (that references Makefiles in each relevant folder) for Linux, Visual Studio for Windows, and a script that builds all the binary components and necessary Java support for Android. Alternatively, we could just use the above stack, select all platforms (apart from Linux x64) and click Build Engines button. However, it is easier to track down and fix any errors that may occur if you follow the first approach. 

Next, in case there are updates in the IDE, we have to get them from the LiveCode SVN repository. Apart from the updates in the IDE code, we must make sure we get the newest IDE-related bugfix notes, if any. The notes have to be put in a separate folder, so as to be exported automatically into the release notes. At this point, the hard work is done. The remaining part is just clicking buttons on the above LiveCode stack.

So, we go back to our stack, and click Build Docs and then Build Notes button. Afterwards, we select Community from the drop-down menu, tick Windows, Linux and Mac OS X and click Build Tools (this creates the installers) and then Build Server. Next, we do the same for Commercial. 

Now, everything is ready and all we need to do is upload the binaries to the RunRev server. We use FileZilla for that. Finally, we press the Archive button, to make them appear in the download page.

It was very interesting to be involved in the whole building cycle. Special thanks to Michael for always being there to help 🙂

My Before, During and After LiveCode Journey: From Zero to Not-Yet-Hero

Before LiveCode
I was always interested in creating “things” for the World Wide Web, even though I never sat in a single formal class on how it is done. This ambition of mine was really daunting, ambitious and downright stupid to say the least. I always asked the question “How did they do it? Can I also do this?”

? ? ? ? ? ? ? ? ? ?

Beginning with websites, I started to teach myself basic raw HTML coding. I even had in the mid 90’s a tourism promoting website, hosted on servers in the USA, for the Region/Province I lived in. Then smart phones hit our lives with a huge bang! I downloaded and played around with various mobile apps and again the question “How do they do these things?” popped into my thoughts. I started to follow my tried and tested HTML method of learning which in short was……..read, watch Youtube videos, analyse code, try things on my computer/laptop………but soon I realised there was a “monster” by the name of Javascript standing between me and possible mobile app development.

 I jumped into various platforms (the ones that let you drag and drop things into your app and by some magic stroke your app is there). I tried a few, had small successes here and there but I still did not understand how I made it happen. This understanding part was very important for me. I also joined coding groups in town, but I could not escape the “Monster”. The “friendly” services and assistance (as per website sales propaganda) invited me to email and assistance will be rendered to me chop-chop. I realised very soon that the internet route returning assistance to me via a return email is blocked and in many cases remained blocked for a considerable time. My hopes were (again) dashed in finding answers to and knowing and understanding “How they do it. How do they develop these app-things for smart phones?” This quest for knowledge (specifically for app design) has been coming on a long, long time……probably 4-5 years. But by nature I am not a quitter, I don’t give up until proven beyond any doubt that “Steve, you are defeated. Accept it and move on with your life.” 

Then one evening around October 2013 I stumbled upon another promising solution to my quest. This time it was called LiveCode. I thought for a while before I downloaded the free Community version, but I never let my hopes and aspirations go through the Roof of Optimism. I told myself “Steve, you were here before. Don’t get your hopes up. Somewhere in this dark tunnel of your ambition to code a mobile app (without the monster JavaScript) will be some unknown, unanticipated curve ball.”

During LiveCode
I started my LiveCode Community Edition journey on the usual path……read blogs, opinion pieces, tutorials, watched Youtube videos etc. On one video I even heard the CEO, Mr Kevin Miller of RunRev proclaim very boldly that “Our primary goal/purpose as a company is that everyone can code….” I thought to myself: “Mmm, a very bold, a very ambitious statement, but if he/RunRev lays that claim so confidently I must test his belief that EVERYONE can code.” I am after all part of “everyone” and I should be able to do it. By the beginning of December 2013 I decided to part with USD 500,00 and spoil myself with this LiveCode thing (Commercial Edition) as a Christmas gift. But in my neck of the woods USD 500.00 is a little fortune. So discussions and negotiations with the family started on and off. I got mostly the NO answer. At one stage I thought, I will never win this. One question put to me that kept my head very busy and which I must answer convincingly to the family was “Why don’t you use the Community version, learn it, get comfortable with it, ensure that there will be no surprises down the road.” Eventually the resistance on the part of the family was melted by the Christmas spirit…….some members even decided to contribute towards the USD 500.00. To my pleasant shock and surprise, joy and my strong belief in the Christmas spirit I saw in digital white and black that “for a limited time only” my Christmas gift was only USD 249.00! I jumped into action.

Early January 2014 I got in touch with RunRev via a very helpful, true customer service oriented angel called Heather Laine. I started the process of foreign currency purchases via my bank, ran into a few hiccups and regulations. Heather guided a lot and, one day, in the third week of January I returned home from the bank a very happy, proud and excited potential owner/subscriber of the LiveCode-thing that may hopefully be the realisation to my desire, namely to produce an app by myself, without the Javacode-Monster blocking my way. I was ready to test Kevin Miller’s belief and theory that “Everyone can code.”

Soon, once a week, on Wednesdays I found myself in “class” under a very pleasant andextremely helpful Neil Roger. My gosh, I haven’t been in class for more than a quarter of a century! Thanks to our country’s excellent communications capabilities I was able to participate when I had to travel outside town end even outside the country. I once attended a class from Kenya. I was hooked, optimistic and firmly believing that “Everyone can code.” Then my sinister side kicked in and I told myself (in no uncertain terms) that soon and very soon you will hit nasty surprises and curve balls, because this customer experience is truly out of this world and you will surely sooncome back into this world with a spectacular bang. I decided to enjoy the ride, get as much knowledge about LiveCode as possible and anticipate the spectacular “down to earth” service crash. I am still waiting……..and waiting…

I was so excited and truly, in a very short space of time, on my way to develop mobile apps. I wanted to meet these people and I nearly did. I had a planned journey to London, but, in short it was cancelled at the very last moment. I even had appointments set up to visit a school where LiveCode is taught to high school kids. I promised myself that I will fulfil the wish to visit RunRev in Edinburgh, Scotland. I will do it….

My LiveCode first baby steps were amazing. In a very short space of time I was truly confident that I, like everyone else, can code. I remained glued to my screen reviewing Elanor Buchanan’s video lessons. I deciphered the code, understanding as a non-coder how it works, tested a few ideas and after a week or two I excitingly realised: Wow, I can truly code. I can give birth to app ideas on my smart phone with the help of midwife LiveCode. I told and showed the Coding Group what I had achieved in a very short space of time. The Greek speakers of the Group (javascript as a language is very Greek to me) could not believe their eyes and ears. We now have a separate Non-Java coding group going within the bigger Coding Group.

As from next year the Coding Group wants to start with a bunch of school kids (especially girls) to get them interested in coding as a hobby. Hopefully the hobby will grow into a desire to formally study software engineering. We are confident that our small steps will benefit the community and country and also change lives. In the meantime we popularise the idea of apps to solve everyday community challenges.

I have, in the meantime, subscribed to LiveCode until January 2016. I have yet to deploy an app in the store, but that is not a priority for now. The priority is to conquer the English-like language, increase my (and other’s) self confidence and hopefully add value to the future of some very disadvantaged kids in my neck of the woods. I take small steps every day and make giant leaps on the big idea of facilitating coding for everyone.

I am still amazed that, after years of producing nothing in terms of mobile apps, I now have sample apps (a local radio, citizen ID number verification, mySQL backend apps) on my smart phone. As a person I feel a real sense of achievement. My earlier nightmares of mobile app development have turned into very real and nice dreams…..thanks to LiveCode.

My LiveCode journey is not over. I want to achieve all my short term goals and long term aspirations, share with others what I have learned in the last few months and just enjoy the ride. I am slowly but surely getting there and, by the way, I am also slowly but surely getting to the age of 60 which is just a number between your birth and where you are today.

After LiveCode
The chapter on “After LiveCode” cannot be written yet as I am still in the “during” phase. It is a very exciting phase that I don’t want to leave for now. I must still learn and read a lot.

Happy LiveCoding………..

Steve Bezuidenhout
Windhoek (Namibia)
Africa