Turbo Charging the Android Emulator

by Neil Roger on October 15, 2014 12 comments

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:

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

Screen Shot 2014-10-15 at 10.02.38.png

n.b a quick signup is needed in order access the downloads page. It’s worth it…trust me 🙂

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.

Screen Shot 2014-10-15 at 10.14.16.png

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

Screen Shot 2014-10-15 at 10.20.05.png

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.

Screen Shot 2014-10-15 at 10.24.11.png

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:

Screen Shot 2014-10-15 at 10.26.47.png

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

Screen Shot 2014-10-15 at 10.33.37.png

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

Screen Shot 2014-10-15 at 10.36.41.png

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

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 🙂

Screen Shot 2014-10-15 at 10.46.06.png

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

Screen Shot 2014-10-15 at 10.55.23.png

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)

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

Screen Shot 2014-10-15 at 11.01.29.png

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

by Panagiotis Merakos on October 13, 2014 6 comments

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:

PanosBlogPostOctober2014

(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 LiveCode Journey

by Steve Bezuidenhout on October 3, 2014 11 comments

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

Head In The (Word) Clouds

by Ali Lloyd on September 12, 2014 26 comments

The word “cloud” was much in evidence at the RunRevLive Conference this year. This was primarily because of LiveCloud, a cloud database for LiveCode, whose aesthetically pleasing t-shirts were donned in abundance, and whose capabilities were amply demonstrated by the official conference app. This pervasiveness stood in stark contrast to that of the San Diego sky, which staunchly refused to have anything whatsoever to do with clouds for the whole week-and-a-bit.

So perhaps it was with those LiveCloud t-shirts in mind that I, whilst putting the finishing touches to the demo stack to accompany my talk and contemplating compelling use-cases for the trueWord chunk, decided to code a word cloud creator.

Well, I say ‘decided to code’; first I checked if anyone had done one already that I could steal. No dice. Then, in case anyone else had even thought about it, I threw the question out to some of the team: “How easy would it be to get LiveCode to make word clouds?” We weren’t sure, and I needed something by the morning. So I gave it a go.

Initially I attempted to define an algorithm for word placement, keeping track of the current border and repeatedly traversing it to find the next available space. This quickly got too complicated, with many additional considerations to do with overhangs and such- a more heuristic approach was necessary.

The idea of a word cloud is not only that the size of a word is related to its frequency, but also that the distance of the word from the center is, on the whole, inversely related to frequency. So once you have the words in frequency order, the ideal path on which to try and position them is a spiral.

The spiral equation can be written parametrically as x = tsin(t), y = tcos(t), which means that at a given time t, the distance from the origin of a point on the spiral is also t, since x&#0178 + y&#0178 is t&#0178(sin&#0178t + cos&#0178t) = t&#0178. So when we search for positions to place words, we can search along the spiral for the next available position, knowing that we are uniformly increasing the distance from the center as we vary the angle.

Here’s the code for returning the location on the spiral at time pTime:

function spiralLoc pTime
   local tX, tY
   put pTime * sin(pTime) into tX
   put pTime * cos(pTime) into tY
   
   return (tX & comma & tY)
end spiralLoc

When following this strategy, we need a way of testing whether words are overlapping. Initially I had thought about taking a snapshot of a field containing the text and changing the alpha value of all the white pixels so that they would be transparent. Then I’d have an image to use for hit testing using LiveCode’s intersect command. It was pointed out to me, however, that the import snaphot command includes transparency data if you use the …of object form, and so this was as simple as the following:

on snapshotField pWord
   set the opaque of field pWord to false
   set the showborder of field pWord to false	
   import snapshot from rectangle (the rect of field pWord) of field pWord with effects
end snapshotField

Then to test if we can place a word, we just use LiveCode’s intersect command to check whether it intersects any previous word at the proposed position:

function canPlace pNum, pTime
   // we can always place the first word
   if pNum is 1 then return true
   if imageIntersects(pNum) is false then return true
   return false
end canPlace

We now have essentially all the ingredients for a LiveCode word cloud creator. First of all, a handler to generate the list of frequencies:

function listFrequencies pText
   local tArray, tList
   repeat for each trueWord tWord in pText
      add 1 to tArray[tWord]
   end repeat
   repeat for each key tKey in tArray
      put tKey & comma & tArray[tKey] & cr after tList
   end repeat
   sort tList descending numeric by item 2 of each
   return tList
end listFrequencies

Then a handler to create the image for a given word. The pWeight parameter is the frequency of the given word divided by the frequency of the most frequent word.

on createImage pWord, pWeight
   set the textSize of the templateField to pWeight*kMaxSize
   create field pWord
   set the text of field pWord to pWord
   set the height of field pWord to the formattedHeight of field pWord
   set the width of field pWord to the formattedWidth of field pWord
   snapshotField pWord
   delete field pWord
end createImage

Repeating this for each of the words we are using to create the cloud gives us the set of images to place. We then try to place each image horizontally (and if that fails vertically) on the spiral path:

on placeWord pNum
   local tVertical, tTime
   put 0 into tTime
   repeat while tTime < kLimit
      if sFilledTimes[tTime] is empty then 
         set the angle of image pNum to 0         
         set the loc of image pNum to spiralLoc(tTime)
         if canPlace(pNum) then
            put true into sFilledTimes[tTime] 
            exit placeWord
         else
            set the angle of image pNum to 90         
         end if
         if canPlace(pNum) then
            put true into sFilledTimes[tTime] 
            exit placeWord
         end if
      end if
      add kIncrement to tTime
   end repeat
   put ("couldn't place word" & pNum) after msg
end placeWord

Watch the placement routine in action in this slightly annoying gif

These handlers together give a relatively pleasing word cloud, although I wanted to make a few simple tweaks to improve it. First of all, word clouds tend not to be circular but elliptical, so I introduced a flattening factor of 0.5 to the spiral equation. Also I felt the word sizes were not contrasted starkly enough, so I used the square of the weights instead. Sometimes words were being placed too close together, requiring a small white outer glow on the text to make such words fail the intersection test. Initially coding them as constants, I allowed the user to input various parameters like maximum font size, spiral flatness, maximum number of words, minimum word length, etc.

Here is the word cloud of this blog post!

What’s more, this being LiveCode 7.0, I was able to put text of all sorts of different languages into the text input box and everything worked exactly as expected. Here’s one with some sample text from various languages.

A Unicode compatible word cloud creator in under 160 readable lines – not many other languages can boast that sort of economy. What’s more, it only took a few hours to achieve something which by all accounts is distinctly non-trivial.

Many thanks to Ben and David who came up with some useful suggestions while I was coding this. If you can come up with any improvements, particularly to speed, I would be interested to hear them in the comments. Perhaps surprisingly, taking a snapshot of the group each time instead of looping though all previous images to find the intersection seems to slow things down.

Download my word cloud stack here.

prMac – FmPro Migrator 7.34 Enhanced with FileMaker 13 to LiveCode Conversion

by Jana Doughty on September 2, 2014 No comments

Koch Island: Fractal Basics with LiveCode

by Hanson Schmidt-Cornelius on August 22, 2014 11 comments

Have you ever thought it would be possible to create something that had an infinitely long edge in a confined area? Yes, it is theoretically possible. Math’s is full of this kind of stuff and even thinking about the very basics of this can be great fun.

Let us consider a little island that was discovered in 1904, not by an explorer or seafarer Helge von Koch, but the Swedish mathematician with that name. This island is a mathematical idea and is considered to be one of the first fractals. It starts out as a very basic geometric construct, an equilateral triangle, which is a triangle with equal angles and equal sides. This triangle is then reshaped by dividing each line into three equally long segments and then replacing the middle segment with another equilateral triangle. The base line of that new triangle is then removed, leaving a line with a pyramid in it. The algorithm can then be applied repeatedly on the new shape, again splitting each line segment into three segments and replacing the middle one with an equilateral triangle and then removing the base line of that new triangle. After only a few iterations, it becomes apparent that the curve surrounding the island becomes increasingly longer. In fact the length of the curve increases by one third at each iteration. At the same time, the island does not appear to grow excessively and take up much more area.

Now this is all great as a mind model and we can get the principal behind the process, but what is with the infinitely long edge in the confined area that we mentioned in the beginning? Well, we could consider drawing this kind of island on a sheet of paper and think about what that would entail. From a mathematical point of view, we can represent this, we have symbols to represent infinity and the LiveCode logo has one of these infinity symbols hidden in the fifth and sixth letters, but if we really wanted to draw such an island we would have to consider what infinite really means to us in the real world.

Regardless of how fast we could replace the line segments, if it took anything longer than infinitely quick, then it would take us infinitely long to draw the island. So that is a possible showstopper. Our pen would have to be able to draw lines that are very, very thin, in fact we would have to be able to draw lines that are infinitely thin. This would then also have an impact on visibility, as lines that are infinitely thin are hard to see or measure.

These circumstances are restrictive, but it should not stop us from considering such exercises and allow us to have fun with these kind of ideas that we can partially visualize with computers. The following LiveCode scripts allows you to draw what can only be considered the tip of the iceberg of Koch island.

You can create your LiveCode Koch Island generator as follows:

1. Create a new stack.

2. Create a button “New” and place script “New” into the button script.

3. Create a button “Iterate” and place script “Iterate” into the button script.

You now have your infinitely long island curve generator that draws the first few stages of this fractal. The code is intentionally short for the blog here and shortcuts were taken in order to get here. If you want to explore this concept in more detail and see how far you can dig into the fractal, then consider updating at least the following three areas:

1. Increase the accuracy by preventing rounding from real to integer numbers at each cycle.

2. Calculate the exact height of each new pyramid with a more accurate constant. You can get the exact value by using Pythagoras.

3. Filter out duplicate point entries from “the points of graphic “island””.

Hope you have fun with this simple fractal example!

********** Script “New” **********

on mouseUp
   if there is no graphic "island" then new graphic "island"
   set the style of graphic "island" to "polygon"
    set the points of graphic "island" to "100,100" & cr & "300,100" & cr & "200,273" & cr & "100,100"
 end mouseUp

********** Script “Iterate” **********

on mouseUp
   local tLastPoint, tCurrentPoint, tCurrentIsland, tNewIsland
   put empty into tLastPoint
   put empty into tNewIsland
   put the points of graphic "island" into tCurrentIsland
   repeat for each line tCurrentPoint in tCurrentIsland
      put calculateSegment (tLastPoint, tCurrentPoint) after tNewIsland
      put tCurrentPoint into tLastPoint
   end repeat
   put line 1 of tCurrentIsland after tNewIsland
    set the points of graphic "island" to tNewIsland
end mouseUp
 
function calculateSegment pP1, pP5
   local tP2, tP3, tP4, tTran, tHeight
   if pP1 is empty then return empty
   split pP1 by comma
   split pP5 by comma
   put pP1[1] - pP5[1] into tTran[1]
   put pP1[2] - pP5[2] into tTran[2]
   put pP1[1]-tTran[1]/3 into tP2[1]
   put pP1[2]-tTran[2]/3 into tP2[2]
   put (pP1[1]-tTran[1]/2) - tTran[2]/2.886 into tP3[1]
   put (pP1[2]-tTran[2]/2) + tTran[1]/2.886 into tP3[2]
   put pP5[1]+tTran[1]/3 into tP4[1]
   put pP5[2]+tTran[2]/3 into tP4[2]
      return pP1[1] & comma & pP1[2] & cr & tP2[1] & comma & tP2[2] & cr & tP3[1] & comma & tP3[2] & cr & tP4[1] & comma & tP4[2] & cr 
end calculateSegment

Are Conferences a Waste of Time?

by Heather Laine on August 20, 2014 5 comments

We live in a digital age. I can sit at my computer all day and talk to people on the other side of the world, by email, chat or Skype. Online webinars make it possible to share training or ideas with larger groups of people without anyone leaving the comfort of their own office. Given that this is so, why do I need to get on a plane and fly 5,189 miles to San Diego, with all the jet lag, expense and inconvenience, in order to spend 4 days live with a group of people who are all as excited about LiveCode as I am?

Of course you know that I’m not going to conclude that conferences are a waste of time. The clue is in that sentence “spend time with a group of people who are all as excited about LiveCode as I am”. But why not? How can we justify the huge investment of time, trouble and expense that live conferences represent? Besides the obvious opportunities for training and learning in formal sessions at these events, I think there are three areas where live conferences just cannot be replaced by digital events.

1) Personal interaction.

Accept no substitutes. You will always learn more in a face to face conversation with someone than you will over the phone/Skype. You can read their body language, pick up subtle nuances you would otherwise miss, not to mention that the conversation is going to flow far more smoothly that it does when you have to ask them to repeat every other sentence or reconnect three times when your Skype connection dies… As a moderator of several email lists I can tell you that an interaction via email can go pear shaped at the touch of an ill judged key. You just know that the group of people now engaged in a blazing flame war would get on like a house on fire if they were all sitting together in a bar, talking, instead of typing things at each other they will later regret.

2) Networking.

There is a saying, “It’s not what you know but who”. You don’t know who you don’t know. You may find interesting people to interact with on forums, or during an online course, but there is just no better way to connect with the right people for you, your work, your educational needs or your business than attending a conference focussed on your area of interest. Unless you stay in your room and hide for the entire 4 days, you will meet interesting people who can help you at RunRevLive.14!

3) Inspiration.

Life is not all about 1’s and 0’s. Yes, the mundane day to day tasks have to be done, plans need to be carried out, code must get written and so on and so forth. But where is your next big idea going to come from? A change of scene, a change of pace, and a new group of inspiring people to talk to might result in something you currently haven’t even begun to dream up. Technically, we could hold a conference in Dundee, in the rain, in a concrete/tin shed on an industrial estate somewhere. I suspect that a) not many people would come and b) it would not have the same inspiring atmosphere and potential as a conference held in beautiful surroundings with good weather, good food and plenty to see and do.

Our next conference venue?

Personally, I’m hugely looking forward to seeing you all again, catching up on the gossip, meeting old friends and making new ones, and adding San Diego 2014 to my bag of happy memories. As far as whether it is worth it to attend goes, I’ll let an attendee from last year sum it up. He told me:

“That one to one meeting I just had with your developer was worth the entire cost of the conference to me! Thank you so much.”

Have you been to one of our conferences? Or another conference? How did you find the experience, was it worth it to you?

HTML5: Next Steps

by Kevin Miller on August 8, 2014 9 comments

reprinted from revUp

Well, what an exciting ride that was! Thank you so much to everyone that helped make HTML5 deployment for LiveCode a reality. Together we made the total and we’re setting the wheels in motion.

Community Powered

This truly was a community driven project. From the first survey indicating the depth of feeling for HTML5 deployment, to the last pledge that put us over the line, its been you the users, powering the campaign all the way. It was a fascinating study in crowdfunding, and you might want to check out this blog post for a deeper analysis of what goes into a successful crowdfunded project. I feel privileged to work with such a dedicated, creative and enthusiastic community. Thank you all. You have entrusted us with this project, and we will work hard to bring you what you’ve asked for: an HTML5 capable version of LiveCode we can all be proud of.

Team Driven

I’ve thanked the community for your contribution. Thanks are also due to our small but dedicated marketing team that ran the campaign, engineered the page, raised awareness, answered your questions, and processed all the pledges. The last day especially was intense in terms of managing the last minute rush of queries and pledges. The upside of running the campaign on our own site instead of on Kickstarter was the additional flexiblity this allowed us, but this did mean we had to meet all the technical challenges ourselves. A very big Well Done to Steven, Heather and especially Arnaud for creating the highly complex webpage, making all the last minute changes demanded of him and keeping it up and running successfully through some very challenging traffic spikes.

Ramping it up

What’s next? We have some major plans to put into motion. Making the campaign total means we will secure the matchfunding, so we are now ploughing through the necessary paperwork and red tape for that. The HTML5 Dev Team needs put into place, trained and briefed. We’re working hard to ramp it all up. It’s a long runway, with our projected delivery date July/August next year, but thanks to you we are getting started! We’ll bring you more information in the coming weeks.

Why HTML5?

I’ve discussed the importance of this additional deployment platform a lot over the last few weeks. Being able to run your app straight in the browser, using the same natural language and drag/drop interface to create it widens the scope for LiveCode projects to a whole new audience. Schoolchildren gain greater accessibility, phone apps can be deployed without going through the app stores and the long tail of niche platforms that LiveCode doesn’t currently address can be supported via the browser. No plugin and no app to install removes barriers to adoption. Anywhere you can run an HTML5 capable browser, you will be able to run your app.

I’m really looking forward to the huge potential opened up by LiveCode HTML5!

Turbo Charging the Android Emulator

Building LiveCode

My LiveCode Journey

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

? ? ? ? ? ? ? ? ? ?

Head In The (Word) Clouds

prMac – FmPro Migrator 7.34 Enhanced with FileMaker 13 to LiveCode Conversion

Koch Island: Fractal Basics with LiveCode

Are Conferences a Waste of Time?

1) Personal interaction.

2) Networking.

3) Inspiration.

HTML5: Next Steps

Recent Posts

Recent Comments

Looking for LiveCode FileMaker?

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

? ? ? ? ? ? ? ? ? ?

1) Personal interaction.

2) Networking.

3) Inspiration.

Recent Posts

Recent Comments

Tags