Parallelism in Testing – To Be or Not To Be?

Today I would like to uncover the topic of parallel testing in context of test automation approaches: its potential benefits and possible scenarios.

So let’s dwell on the matter of test automation as we know it.  What can we call a common benefit on this regard?  The most obvious one can be referred to as “resource savings”.  How about we stop for a minute and try to define the tasks that are most frequently automated.  These can be – repetitive inputs, UI navigation, performance measuring, etc.  The next point would be the product areas which are eligible for the automation itself.  In case when one has to achieve 100% test automation coverage, he/she may claim – “It is possible to automate every bit of the program functionality!” – fine by me, but is it reasonable?  Is it worth spending hours of work to produce an automated test that will be run only once or twice, but can actually be tested manually in just a few minutes?  Don’t expect a unanimous answer, but in majority of such cases - resources spent are not worth results provided.  Another point that can be hard to overcome during the automation tests implementation is the maintenance of test cases.  This problem mostly affects products that tend to change frequently during the development process or during the product lifecycle. 

Speeding up MR Image Reconstruction with GeneRalized Autocalibrating Partially Parallel Acquisitions (GRAPPA)

This time we would like to share some details about realization of one of our projects in medical imaging.
Currently one of the bottlenecks in MR image reconstruction is speed improvement. Improving the speed of image reconstruction is difficult from algorithmic point of view. But it’s becoming more popular to improve algorithm performance using GPU.

Introduction

In magnetic resonance (MR) image reconstruction raw data measured from the scanner correspond to the Fourier coefficients of the target image, so the fast Fourier transform (FFT) is used for reconstruction. An important procedure called the density compensation is necessary in the very beginning to account for the non-uniform sampling. GeneRalized Autocalibrating Partially Parallel Acquisitions (GRAPPA) is a partially parallel acquisition (PPA) method which is used to reduce scan times. In this case only partial data is acquired and missing data is mathematically calculated from available data.

Subject for optimization

Original implementation was based on FFTW library for Fast Fourier transforms and adapted Singular Value Decomposition (SVD) algorithm from ACM Collected Algorithms for GRAPPA preprocessing. These two algorithms are the most computationally intensive parts of the whole image reconstruction. FFTW library is claimed to be the fastest CPU implementation using all possible optimizations like SSE2/3 and hyper threading, however it does not leverages the power of modern GPU cards. SVD algorithm was done on CPU as well. It is known to be badly parallelizable for small matrices, but in case of GRAPPA algorithm we have many image frames with same size which can be processed in parallel. Besides there are many intermediate steps which consume a lot of CPU and they can be easily parallelized on GPU.

Technical analysis

FFTW library performance is comparable with Intel MKL implementation. NVidia provides comparison for their CUDA based cuFFT library with MKL implementation (Figure 1):

Figure 1 Comparison of CUDA based cuFFT library with MKL implementation

According to this we should achieve up to 8-10x faster FFT processing  when using GPU accelerated cuFFT library from Nvidia. GPU accelerated SVD algorithm is also available, for example CULA library by EM Photonics. However, current CULA library implementation does not support batch mode, so we will need to process all image frames as a sequence. Brief testing showed that 64 image frames (256*256) are processed even slower than CPU based version. Since we haven’t found any good alternative to CULA library we decided to implement our own GPU accelerated version of SVD algorithm.

Implementation

FFT part of image reconstruction when using cuFFT library was straightforward, however we had to deal with image frames which does not fit into available GPU memory. We had to write algorithm to run FFT over portions of the large data frame with subsequent aggregation. Figure 2.1 below shows case when all data fits into GPU memory.

Figure 2.1 

Figure 2.2 illustrates the case when huge data is processed. Solid lines in figure below show measured performance, dashed lines show estimated time in case data fits into GPU memory.

Figure 2.2

Much more interesting was to implement GPU accelerated SVD algorithm with batch mode. All implementations we had found are focusing on maximum parallelization of a single SVD run, hence we had to change approach. Basically SVD algorithm consists of HouseHolder Reduction, QR Diagonalization and Back Transformation steps. All are iterative processes when next step depends on results from previous step. In case of small matrices each CUDA kernel can’t effectively utilize all parallel processing units of modern GPU. So we had to write kernels in a way when every iteration for all matrices is processed by a single kernel run. This way in case of 64 matrices with 128x128 size each we can process 64*128 elements at a time instead of 128. Figures 3.1 and 3.2 show performance comparison for CULA Library and our implementation. 

Figure 3.1

Figure 3.2

With more than 8 frames per batch our implementation shows much better performance comparing to sequential CULA calls, although it is not so efficient for a single frame.

Results

As a result we have developed a pure C++ library with a set of specialized functions which perform various stages of image reconstruction. It requires only CUDA runtime libraries and free cuFFT library provided by NVidia. In addition we have implemented lightweight C# wrapper for convenient usage. Also we have run a lot of benchmarks with various GPU cards and on different platforms. On test cases provided by customer we received up to 150x speedup comparing to original single-threaded CPU implementation. However significant part of received speedup was due to poorly optimized original code which was completely rewritten and ported to CUDA whenever possible. 

While it is usually understood what FFT stage does in image reconstruction, GRAPPA stage is not so obvious. Due to parallel acquisition of different frames arises distortion of acquired data which is effectively eliminated. Figure 4 shows visual representation of images before and after reconstruction. 

Figure 4 The image before the reconstruction (left), image after reconstruction (right)

Additionally, you can find a case-study on ELEKS website or download it in PDF. Stay tuned!

/by Volodymyr Kozak, Principal Developer, ELEKS R&D

ELEKS open-source projects directory

Even though ELEKS is a software development services company and we mainly develop proprietary software for our customers, we have our own open-source projects and contribute to projects maintained by other people and organizations. We are proud to be a part of the open-source community. Recently we have launched GitHub page where you can find a list of our projects and projects we contribute to: http://eleks.github.io/.
We are going to publish more open-source projects soon. Stay tuned!

20x performance for the same HW price: GPGPU-based Machine Learning at Yandex

Russian search-engine Yandex has disclosed some details about their machine-learning framework, FML. The most interesting detail is that it runs on 80 TFLOPS cluster powered by GPGPU. This is quite unusual application for GPU, as ML algorithms are usually hard to be paralleled. However they have managed to adapt their decision tree algorithm for high-level of parallelism. As a result Yandex has achieved more than 20x speed-up for the same hardware price.
They are going to upgrade their cluster to 300 TFLOPS. Yandex expects its cluster to be in the list of top 100 most powerful supercomputers in the world after that upgrade.

The end of the Javascript domination

The world is changed,
I feel it in the water,
I feel it in the earth.
I smell it in the air

The Lord of the Rings: The Fellowship of the Ring

Mozilla's ASM.js release last week created serious buzz in the programming community. Some people are excited by it, some criticize it, but almost everybody agrees that it may have significant impact on the future of the web.
I consider it as one more nail in monolanguage web's coffin. Today there are more than 200 languages and tools related to Javascript generation and this number is increasing every week. Of course, most of them are no more than amateur projects that are designed to solve some kind of Javascript problem. However, there is a clear trend. The reason of this trend is obvious: complexity of web client-side is increasing and Javascript is not always ready to support this complexity. Most of these tools have emerged over the last few years. Here are few of them I consider to be most important:

Language/Tool	Year of appearance
CoffeeScript	2009
Dart	2011
TypeScript	2012
Emscripten	2012
ASM.js	2013

What is really important is that three major browser vendors seems to be supporters of this movement: Google (with its Dart), Microsoft (TypeScript) and Mozilla (ASM.js). Together they hold 90% of browser market share and definitely have enough power and influence to change client-side programming landscape over the next few years.
I don't mean that Dart, TypeScript or some other language will replace Javascript completely. It will always be here, but it is hard to argue with the fact that Javascript is no longer the only client-side programming language in the web. It still dominates, but things are going to change over the next few years.
Any thoughts?

Game Localization: For Gamers by Gamers?

While revising our approach to games localization, we decided to ask for an opinion of people, who were not once observed spending their free evenings in virtual worlds loudly shouting at each other totally in oblivion of the existence of someone else finishing their job. Well, what we received back was the overview of nuances the gamers care about with the culminating quote: “For gamers by gamers”, meaning the gamers know better how and what to localize. (I subconsciously thought of doctors and their reaction to patient’s saying “I know better which medicine to take in my case”). But the guy might be right to some extent. This won’t be a translator who will consume the final product. To tell you the truth, when working as a translator I never came back to the work already done long time ago to reevaluate my performance. Life was always too short. Job's done, no feedback to implement, money paid – adieu! I did not care anymore.

But would it mean that the guy living more in his virtual life than in reality would do the localization better than me? I did spend 5 and half years in the university studying  languages. I did spend nights in my student years doing freelance translation.

The truth is in the middle, as always. At least I tend to think so. In the ideal world I would combine the guy’s passion for meaningful game dialogs and my passion to do this a right way. Thanks God, we live in the 21^st century. Obviously I am speaking about crowdsourcing, precisely about controlled crowdsourcing. Controlled in a sense that there is a dedicated person observing the deadlines, the progress and quality. The person who can step in choosing more proper option, who will ensure there are no grammar/style mistakes and finally who take the responsibility for the target translation quality.  This still allows the game developers to engage the community into the creation of their local product version. This still makes the localization cheaper. On the other hand, the process is being watched and in case of unpleasant or pleasant surprises, the producer is aware and is advised on the actions to take. I would feel safer if I were a game developer.

The traditional approach of engaging professional translators into games localization is still in place. And of course there are translators specialized precisely in the area of games, who are native in the target languages (we have been cooperating with many such guys, very proficient). This approach guarantees the quality and consistency but is more expensive. I would advise traditional approach for game developers willing to do localization, but who do not have their community yet or the establishment of such community is at inception stage.

by Katia Kosovan, Department Manager

Localization and QA unit

PhoneGap: An Unexpected Journey

This is a story of a web developer, who's a complete newbie in mobile world and who were given a task to research and develop a tablet application from scratch, re-using his experience in web technologies, i.e. using PhoneGap.

So, my friend, if you are like me - go on reading. This article will give you an intensive look at what PhoneGap is from a perspective of web developer.

Part 1. Theory

Chapter 0. What is PhoneGap?

I suppose you all have an idea of what it is, but I'd like to stick to a definition and point out couple of things. So, as they say,

PhoneGap is an open source framework for quickly building cross-platform mobile apps using Html, Css and JavaScript. 

And it is true(to certain extent). Lets take a deeper look:

Open Source - yes. you can delve into implementation details and even fix their bugs if you want to. But I wouldn't recommend doing so.

Framework - as you will see later, PhoneGap is just a little piece of javascript and platform specific language. There's not much mystery in it.

Quickly - this really depends. Read further to see the answer.

Cross-platform mobile apps - this is the thing that brings attention of clients and managers. It seems that you can simply write your code once and run on any device, saving tones of time and money. Unfortunately the truth is not so astonishing.

Html, Css and JavaScript - yes, yes and yes! we're here because of these cute little guys:) I personally love'em and was very glad to know that I can use them in mobile world.

Chapter 1. Origin

Anyway, how and why did people end up with a product such as PhoneGap? This is a nice one. Here the creators talk about their beliefs and, I must say, they are pretty original. Like these two:

The web solved cross platform.

The ultimate purpose of PhoneGap is to cease to exist.

By and large PhoneGap creators are web consultants and they purely believe that web technologies are perfect fit for writing cross platform solutions. Actually, I totally agree with this one. Just think - on how many devices you can run a browser, in which you can run your app? I have one even on TV!

Also they believe that creating PhoneGap will help standardize web technologies. And according to their beliefs, when there's no more need for PhoneGap(i.e. you can write native mobile apps with web techs without any frameworks) - their task is done. A brave goal, goal worth fighting for, imho, but a struggle won't be easy. Well, good luck for them!

Chapter 2. Implementation

As you may know, PhoneGap isn't the only tool that allows similar functionality. And there's a lot of noise about how these tools work(like this one) and I must say it looked like magic to me for a while. Honestly, I was a bit disappointed...but more on this later. Lets talk about more obvious things first.

So, we have our small html website. And we want it to become a mobile app. Also, we want it to use specific device feature, let it be camera. Where do we start from?

First, we need something to run our site, parse html, translate/compile js etc. In web we have browser. What do we have in mobile app? As you may know, a mobile app is just a piece of executable binary code, which special device knows how to behave with. But our web site is a piece of text! My iPhone doesn't know how to run it as app! The answer is WebView(the name depends from platform). So what is it? 

A WebView is kind of a built-in browser, that can be embedded into a mobile application and which knows how to run html-based web sites. Every platform has its own implementation of WebView, for example on Android you have android.webkit.WebView class, on iOS you have UIWebView, on Windows 8 you have 

Windows.UI.Xaml.Controls.WebView class etc. General pattern is that this built-in browser behaves almost the same as native browser for this environment, e.g. Safari on iOS. Unfortunately, almost...but more on that later.

So, first problem solved - we have our runtime environment. But how do we access a camera? None of popular web browsers has provided us with stable version of camera API, so it is doubtful that some built-in ones will. This is were tool like PhoneGap comes in handy. It gives you a javascript file which has declaration of pure js methods, which know how to access device's features. All you have to do to use it - is include it as a script in your html file, and voila!

Chapter 2.5. Implementation. Learning the Magic.

But for me this was still not enough. This place seemed like the most magic for me. How can javascript access native features, if on exact platform you have special language-specific API for that? Is there some kind of js-to native code translator? But how does the runtime translate js calls into Java code? into Objective C? And back?

Now, sit down kids, and listen carefully, as we're going to learn some magic!

First let me say - kudos to people who implemented PhoneGap, for their creativity and braveness.
As it turned out, js to native communication bridge implementation differs depending on platform, as you can see here(android) and here(ios). Furthermore, each platform has about 3-4 implementations, each fixing some bugs from another one. I can only imagine perplexity and frustration on brainstorming meetings while looking for new ways to handle new bugs in new hacks. Phew!

I won't cover all the ways of communication, but will give some tips.

Prompt

On Android, in WebChromeClient class, there is a way to intercept javascript's prompt message using method onJsPrompt from Java. This gives us a flat-footed way to send messages from js to Java and back(here it is).

You can also find an extended non-PhoneGap related sample here.

"WAT? This ain't magic, Gandalf!" - you say, and I would agree with you. Let's move on. But just let me enjoy this piece of comment with you

Since we are hacking prompts for our own purposes, we should not be using them for this purpose, perhaps we should hack console.log to do this instead!

Perhaps, you should!

JsObject

The WebView class exposes method addJavascriptInterface which lets you bind js calls directly to Java calls, with just a couple of conventions. This looks more right, as for me. Why didn't they use it all the time? well, here's a complete answer I guess. To wrap up - couple of compatibility bugs, as I mentioned before.

So, one could say - we solved the problem. We have runtime, we have communication with native API...did we miss something? Yes, performance. Most operations require some time to execute, and we don't want our GUI to freeze. That's why PhoneGap supports asynchronous model of communication. And as you can guess this creates some obstacles. How should we send messages back from Java to Js? 

Most of the work is done in NativeToJsMessageQueue.java class. The name actually speaks of itself. It's a thread safe queue of js messages to be invoked on js side. This guy's job is to deliver them. Internally he has 4 ways to do this, but I will tell you only about the default and the most hacky one.

OnlineEvent

As some of you may know, there's a thing called Online/Offline event in html5. Basically it's a way to tell your js code that user's device have connected/disconnected from Internet. I'm not sure if all browsers have agreed on the API yet, but there have been some efforts. Anyway, our lovely PhoneGap found a good use for this event! You getting there? Yes!

Bingo! Hack in a pure form:)

So, to sum up, PhoneGap has lots of ways of communication between native and js sides, each for a specific platform/version/situation. It is so, because mobile vendors didn't have an intention to let this happen on every platform same way. And this is what PhoneGap was meant to do. So this is the core part, and I must say, they wrapped the dirty job pretty good, so that the upper level doesn't have to worry about these details.

Chapter 3. Architecture

Generally speaking, PhoneGap has a plugin-based architecture. Each device-specific feature is a plugin, which consists of javascript and native sides. Js side should be as cross-platform as possible, whereas native side can be implemented only once, for 1 device. Nevertheless built-in plugins are developed for all of the most popular platforms, so no need to reinvent the wheel. I'm not going to tell how they should be built - there are tones of guides for this. 

What I would like to say is that this architecture, together with open source code, not only allows you to fix their bugs, but also allows you to tweak their plugins for you needs. And you can also built your own plugin, and support only on the platform you want. Maybe somebody will extend it to his needs. Maybe you will extend somebody's plugin for you platform. This approach makes Phonegap a very fast-growing and powerful community. Well done!

So, enough theory - let's feel how is it - to develop a mobile app with PhoneGap!

Part 2. Let's get to action!

Chapter 4. Installation

After few minutes of research I decided to run my first app on Android, as deployment process seemed to be very easy for a newbie, comparing to iOS(no need for licence, direct access to device, no VMs, as I use Windows etc).

So, first thing I done - went to official PhoneGap "Getting Started with Android" guide, which seemed like a perfect start. Oh, how far from essence was I...

After several hours of pain and suffering I found out that I was not the only one having problems with installation. As it turned out - there was a lot of tiny typos and mistakes in that guide(on Windows only, as they all seem to work on Mac), which a non-mobile developer wouldn't notice.

Important thing I realized is that most of the errors I got was Android-specific, not PhoneGap-specific. In Android context, PhoneGap is just a Java library, and piece of static contents - html css and js. All you need to run PhoneGap app when you have working android environment is to include this library in project and include js script in your static web-site.

Of course, in PhoneGap docs they should've warn web-developers about common pitfalls of installing Android environment, and test their guides better. But don't be angry at them - be angry at Android:)
So your main problem is setting up Android environment. Adding PhoneGap libraries is pretty easy. Just make sure you understand what's going on.

I was working with PhoneGap 2.2.0, maybe they fixed something for 2.4.0, but anyway this article was pretty useful for me. Although I recommend googling for newer versions.

Chapter 5. Development

And so I ran my "Hello, World!" with PhoneGap.
The code seemed pretty much like: on Java, and
on html side. pretty simple isn't it?

But it gets much more interesting when building something bigger then just a skeleton app. If you have ever dealt with Android emulator, you'd notice that it's extremely slooooow. It takes from 5 to 30 minutes(!!!) just to check if your changes applied correctly! And also it happens often that some part of build process fails for just really random reason. Don't believe? I wouldn't. But it happens.

"Ok", I thought, "then I can just develop and debug design and main functionality in browser and then simply move it into the app, there shouldn't be much difference, right?"
WRONG!
This approach lead me to a very unpleasant situation, where my beautiful, good looking, bug-free static website turned into an ugly monster when displayed as an app. Actually, randomly-broken-functionality ugly monster. But more on that later.

So, advice no1 - go get the device! (although on iOS build process seems less painful).

Now, when you've got the device your development process blooms in every way. After you made changes in code, it takes about 2-3 seconds to see them applied on device(just use right shortcuts) . I'd say it's feasible.

Of course, it wan't solve all your migration problems, but at least you will get them one by one and in time :)

So, the development process goes like this: you edit the code in Eclipse, when ready - press smth like ctrl+f11 to build and deploy app to a device, look at device to see the app and decide if you need to change smth more. And what if you got a problem and want to diagnose it? Well, let's talk about it.

Chapter 6. Debugging

Here I've got the bad news guys. There's no way to debug javascript code inside an app on a device as you've got used to. No f12, no f8, no "debugger;". But, everything's not lost, there are several ways to diagnose the problems.

debug in browser

It's not universal, but for debugging purposes you can open you app in browser and use beloved js debugger to find the problem. Although all phonegap-specific features won't work of course. It's not always easy to maintain your app both for device and for browser because of these things. Usually this approach is good at the beginnings, when you're building your main logic without dependencies on device-specific features, or when you're editing something unrelated to device.

console.log

PhoneGap environment gives you a way to transport debug messages from js to your Eclipse console via console.log() method.Although it's not a run-time debugger, this can come in handy sometimes. 

hehe, good old way, reminds me of debugging scripts on ie6. Code speaks of itself

weinre

weinre seems to be "official" PhoneGap debugger, according to url. It lets you navigate your html content as you dynamically update it. It has a similar interface to Chrome developer console, to give you impression that you're home:) Although it's a bit slower and less user-friendly then chrome debugger, it may save your day.

Let me put the magic out if weinre. Everything is pretty obvious - you put their script with your "unique" id into your html file(it's not unique - you just pick non-common description of your app to find it between all the others later). This script sends ajax requests with information about page html and all that stuff periodically to their server to specific url based on id you chose. Then you go to their server using your browser, specify your id and server periodically returns new information about changes in your original html document. Then weinre js logic displays the results in a friendly way. Easy as hell.

It's also funny to watch how many people currently use weinre with default id "anonymous" and expose all their data:) Yes, security IS the concern here, because all your logic is transported through third-party soft and publicly exposed to everyone who can guess you "unique" id.

And, as you may have guessed, your device has to be online in order to debug your app using weinre.

Chapter 7. Deployment

Deploying mobile apps is pretty different from deploying web apps. In web you usually had a web server with predefined ip address and/or DNS name, and users simply access you web site by typing your address in their browsers.

In mobile world people use things like AppStore and Google Play to download apps. And while putting an app to Google Play is pretty easy, AppStore may reject your app if it doesn't follow their guidelines. Knowing them and following them is another problem, but there's a conceptual concern going on on the internet about PhoneGap and AppStore. 

PhoneGap and AppStore

Thing is, one of the rules of AppStore is that you cannot use UIWebView to load remote website, as AppStore cannot control the content of this website and you can post whatever you want on it, including forbidden stuff. This takes us to a fair question - if PhoneGap is the website inside UIWebView, will AppStore accept our app?

The answer is not just yes or no. As PhoneGap officially says, apps built on PhoneGap are not banned on AppStore. Actually it makes sense, as PhoneGap app is not a remote website, but a local one and you cannot dynamically change its contents without going through AppStore. But this is not the final point. You sill have to follow Apple's guidelines. Apple has made a good clear statement about this:

If you’re coming from the web, you need to make sure that you give people an iOS app experience, not a web experience.

So you still have to know their guidelines and iOS app UX. Same with Android, Windows and other platforms you're targeting, although some of them may have weaker requirement for following them.

PhoneGap Build

To ease your deployment process PhoneGap introduced thing called PhoneGap Build. Its a cloud service, that lets you forget about transforming your html,css and js files into Android or iOS app file.

In other words, you can write code on any platform, in any IDE(don't bother with Eclipse, Visual Studio or Xcode), let PhoneGap Build handle build process for you, download apk, ipa or whatever file your platform uses, install it on your device(Android, iOS, iOS for adventurers) and see the result! Of course, it takes more then 2-3 seconds as opposed to Eclipse build. But still, when automated, this process can be pretty useful.

Also, I must note, that using PhoneGap Build is very intuitive and pleasant, good job done here.

Chapter 8. Experience

When it comes to reality, and you need to build some non-trivial app, deploy it to couple of devices, and then to maintain it later, you just think "never again". The fact is that there is soo much mysteries around these built-in browsers that you can hardly manage them all. I personally still didn't find an explanation to couple of bugs. And it can be a serious show-stopper for the business you're in. So expect surprises, they will come.


Another thing is that these browsers are usually slower. Why? Well, for example, on iOS Safari uses Nitro to compile javascript, which dramatically improves performance, but on built-in browser Nitro is turned off for security (and i guess political reasons). This was one of the reasons why facebook moved from html to native approach(btw here's a cool video about that).

Also, as I told before - you still have to know the guidelines of each platform and apply specific design for each of them, and it doesn't just mean that you turn rounded corners into square ones, it also means that you redesign your view drastically. Moreover, there are sooo many devices out there, each supporting/not supporting specific feature... Do you really think you can use "One size fits all" here?

So now cross-platform apps has weakened in their meaning. Functionality is still very similar, but a bit different. And this "bit" messes everything up. And here come the phrases like "By the time your app redraws its view on click, you can go cook a nice fresh lasagna", "PhoneGap is cross-platform. It doesn't work on all platforms the same way." or "Instead of dealing with N platforms you just have to deal with N+1", and its almost true.

Chapter 9. Conclusions

So, we've processed a whole bunch of information. Let's wrap it up.

The term "cross-platform mobile app" is a bit misunderstood. The application may work on any platform, but it won't, or at least shouldn't, be the same on all the platforms.

When using PhoneGap - you're trying to save time and money, and may even succeed, but remember that you're trading quality to gain this.

Building non-common solution with PhoneGap is a huge risk and will likely end up in a disaster.

Trying to build mobile app without knowledge of platform you target will end up in clumsy user experience.

PhoneGap is the best there is in its field. Don't try re-implementing it on your own, as you will face same major issues.

When Phonegap may come in handy:

• You're building near-trivial, common-purpose app with built-in controls and nothing extraordinary
• You're having time shortage and need to deliver some results asap.
• You don't have any Android or Java developer to build native app
• You need to support more than 2 platforms
• You need to support a platform so deprecated, that PhoneGap APIs are better then native.

Last word to say - respect to people who try to integrate web technologies into mobile devices. I understand  and share you goals, but unfortunately, and it's absolutely not your fault, the result is not satisfiable yet.

Cloud compute instances: it's not always about the horsepower

A short time ago we were consulting for one of our customers who considered migrating their application to the cloud. The system embodied a variety of computer vision algorithms, and one of the primary purposes of the back end services was detecting features in images and matching them against the feature database. The algorithms were both CPU- and memory-intensive, therefore one of our first steps involved benchmarking the recognition services on different Amazon EC2 instance types to find an optimal hardware configuration that could be efficiently utilized by the application.

So we launched a bunch of instances with varying computing capacity and gathered the initial results. To ensure complete utilization of hardware resources, we tried running 2, 4, 8, and even 16 benchmarks simultaneously on the same virtual machine.

So far, no surprises here. Obviously, Cluster Compute instances were no match for low-cost single-core workers. Also, we can clearly observe that performance was degrading significantly when the machine was running low on memory and the number of page faults was increasing (check out c1.xlarge with 4 and 8 concurrently running benchmarks).

On the other hand, to make the most out of the Cluster Compute instances, we have to load them heavily, otherwise we would be paying for idle time as a result of overprovisioned capacity. In many cases, providing enough load is a real issue: after all, not many tasks can make a dual-socket, 32-virtual-CPU machine cry. In our case, the only option was to launch more and more benchmarks simultaneously because running one benchmark wasn’t even close to reaching 100% utilization.

That got us thinking: what is the optimal configuration with respect to cloud infrastructure cost? In other words, how can we get the best bang for the buck in this situation? Taking the EC2 hourly rates into account, we built one more chart, and this time the results were much more interesting:

For our particular case, c1.medium and m3.xlarge instances, despite not having shown the best results with respect to running time, suddenly made it to the top 3 cost effective instance types, whereas powerful machines such as cc1.4xlarge and cc2.8xlarge displayed cost effectiveness only under a significant load.

Based on this simple case, three lessons can be learned:

• Measurability matters. If you possess concrete figures about the performance results of your application, you can choose a better deployment strategy to minimize operational expenses.
• Avoiding idle time on powerful machines with many logical CPUs can be difficult. Not all algorithms and implementations provide the necessary degree of parallelism to ensure efficient utilization of hardware.
• If fast processing time is not critical for your product, consider using multiple nodes operating on commodity hardware as an alternative to operating on single high-end servers.

Disruptor.NET

Disruptor is a framework for building high-performance applications that allows you to process large amount of messages concurrently without locks. It was initially invented by LMAX software development team members - Martin Thompson, Mike Barker and Dave Farley. It is said that with Disruptor you can achieve 100K transactions per second performance with less than 1 ms latency. I won't describe all Disruptor concepts as there are plenty of great articles about Disruptor in the Internet. My favorite ones are Martin Fowler's article, LMAX presentation at InfoQ and absolutely awesome series of blog-posts by Ruslan Cheremin (in Russian). Initially Disruptor is written with Java and released under Apache license. You can find source code along with some useful info and links on Github. There also is pretty good port to .NET CLR: disruptor-net (and today I'm going to tell more about it).

At the first glance Disruptor is yet another name for old good ring buffer. But if you look deeper there are several important features that make the difference. Well-written Disruptor-based applications can be incredibly fast. This speed is achieved by a great mix of high-level architecture choices and low-level optimizations based on deep knowledge of modern CPU and memory architecture. Almost all decisions by Disruptor authors were made in order to make applications cache-efficient, lock-free and GC friendly.

Today I'm going to show you how to write very simple Disruptor-based application. And just to make some difference with other introduction articles I'll use disruptor-net, so it will be Disruptor application written with C#. First of all, let's define the scope. Imagine there are lots of moving objects (e.g. cars). Each object has GPS installed on-board and sends its location via mobile network once per some period of time. We want to track the path of every single object. It is very important to log every single message to disk in order to have ability to restore all the movement history. We also want to aggregate the distance traveled by each object as well as the total distance traveled by all objects. Sounds like a very simple application, right?

Our moving object will have three properties: latitude, longitude and some unique ID. Something like that:

As I don't have a fleet of thousands moving objects with GPS sensors we will simulate their movement with very simple random simulator (see code on Github).

The simplest way to use disruptor in your .NET application is to install it via nuget package manager:

Let's create the Disruptor instance:

Here we pass factory method that preallocate the ring buffer with messages (do you remember that one of the main ideas of Disruptor is to reduce memory allocation?), set its size (1024, it must be a power of 2) and tell it to use default task scheduler. Now we need some handlers. Our handler graph will look like that:

Lets start with some simple persist handler that writes objects into text file, line by line:

As you can see it implements IEventHandler<T> interface. This interface has only one method void OnNext(T data, long sequence, bool endOfBatch). Disruptor call this method for each item in the ring buffer and pass the item as the first parameter. Second parameter is the sequence number for the item. Third parameter is the most interesting: as Disruptor allows batch processing it  indicates if current item is the last one in the batch. We use it in order reduce the number of flush calls - we call flush only when it is end of the batch. Leaping ahead, as ObjectPersistHandler is the slowest one in our pipeline, batch processing allowed us to achieve 2x performance boost in our benchmark. It looks like there is some cheating here, but in fact everything is ok - other handlers won't start processing before persist handler finish the batch, so there will be no situation when we process some message before it is stored to disk. Please note, we use simple string serialization here, in real-world application some more sophisticated serialization method will be used.
We have few other handlers: DistanceHandler, ConsoleLogHandler and AknowledgementHandler. First one is kind of business logic - it performs some distance calculation for objects:

I think this code is pretty straightforward, so no additional explanations are needed. The only thing you might notice here is that it doesn't use any locks or other synchronization primitives, as each handler is single threaded and doesn't share any mutable data with other handlers.

Aknowledgement handler actually tells simulator that we finished the processing and it is time to make next object move. In real world code there will be some kind of network message send where we will tell the client that its message was handled so it can send next one. After we move the object it is published into Disruptor using following code:

Please note, we do not store new object into the ring buffer, but copy its properties into the existing entry. It makes us sure that no data is shared between different threads and guarantee lower GC load.
The final thing we need to do is to configure disruptor to use our handlers. It could be done with fluent syntax like this:

Please note that 'Then()' method creates synchronization barrier, so we can guarantee that handlers will be executed strictly in required order. Console log handler and distance handler are included into one handler group, so they will be called in parallel threads.
The only thing we need is to start execution:

Let's measure the performance. On my work machine (Core i5@3.2 GHz, 8 GB RAM and regular spin HDD) I've got following results:

Of course in real-world app there will be some additional latency introduced by network communication, but still, 340K events per second is a pretty impressive throughput. Moreover, I think it could be much better in case we set the goal to achieve maximum possible performance here.

Disruptor gives you flexible way to create high-throughput and low-latency event processing applications. It is very simple but powerful tool with lots of great ideas inside and really good implementation. You can use .NET CLR port in case there are some reasons why you don't want to use original Java implementation.
As usual, you can find demo code on Github. Stay tuned!

Cloud computing: myths, fears and facts

Last time we were writing about Cloud Computing basics. Today we are going to discuss myths about cloud computing. Our main goal is to understand what is real and what is just a myth.

Lower cost 

Probably the most controversial topic about Cloud Computing is it's cost. On the one hand, vendors usually say cloud computing is cheaper then traditional IT. On the other hand, there are lots of examples when people count their cloud expenses, compare results with traditional infrastructure cost and get opposite experience. So, where is the truth?
Well, the truth is that Cloud is expensive but sometimes cheaper. How can it be? There are three basic principles of cost calculation when you are trying to determine cost of your cloud infrastructure:
1. Do correct TCO calculation.
2. Remember about workload patterns.
3. Do not forget about additional benefits of the Cloud.

Cloud cost is like an iceberg: you see only its top part and most its volume is hidden under water. People usually tend to calculate only hardware price when they are comparing cloud cost with on-premise infrastructure. However, total cost of ownership is much bigger than just a hardware price: you have to remember about staff salary, training, operations costs, risk management and lots of other things that cloud vendor do for you.
Another important thing you have to understand when you are considering cloud hosting for your application: workload patterns. There are several types of application workload that work best with the cloud:

Each of the patterns above utilize key property of the cloud: ability to scale up and down. Main difference with traditional IT here is in pay-per-use nature of the cloud: you don't have to pay for resources when you don't use them. With traditional IT you have to pay in advance for all resources you need and it is not so easy to get rid of them in case they are no longer needed.
And what if you have this:

Well, maybe it means cloud is not suitable for your case. Or you forgot about additional benefits of the cloud. What are these benefits?

Additional Benefits

First of all, cloud allows you to transfer your capital expenses to operational. Basically it means you don't have to pay in advance for your infrastructure. It is usually easier to pay money after you serviced your clients and got money from them than to pay in advance when you are still not sure if anyone will actually buy  your service.

Another great benefit of the cloud: faster time-to-value. With cloud you can shorten time, required for infrastructure setup from months to hours. It is very important for big enterprises, where IT services are often terribly slow. Sometimes it takes several months to buy and setup servers for some particular application. At the same time with the cloud it takes just several minutes to allocate resources and deliver them to development team. It means additional flexibility and agility for your business which automatically leads to competitive advantage.

And the last but not least: with cloud computing you can focus on your core business and don't care about IT infrastructure management. Let professionals do their part of job and focus on your part.

Fears

Cloud is still something new and unknown for lots of people. People are usually scared by new things and cloud is not an exception in this case. We are going to review most common fears about the cloud and determine whether they are real or not.

Security

Security is probably the most discussed thing about the cloud in the enterprise community. Businesses want to leverage cloud benefits, but they are worried about their data which sometimes is their biggest asset. How to make sure that data is secured in the cloud? Let's take a look at facts. Security risks in the cloud are pretty much the same as in your own data-center. Really. If you don't make some extraordinary efforts to secure your data center from unauthorized access, you have the same security as in the cloud. Moreover cloud providers continuously improve their security which probably means that your data center actually might be less secured. Simply because big vendors hire world's best security engineers and you usually don't.

Most vendors nowadays offer the customer different levels of security protection. You can setup virtual private clouds accessible only from your corporate network. You can use numerous encryption algorithms. You can have almost any type of security configuration you can imagine with modern cloud offerings. So, security is just a matter of right usage, not an actual issue of the cloud.

Data control lose

Some people are worried that they can lost access to their data in case of some catastrophic failure. It is true that it can happen, but let's look at the facts. In fact, the data in the cloud is replicated and geographically distributed, which means it is much safer than in most private data-centers. Just ask yourself, are you sure that the data in your data-center is replicated to several devices? And what about geographical distribution? What if there will be some natural disaster in the region where your data-center is located? Moreover, nowadays, if you lost the Internet connection it usually means lost data access is not your biggest problem. It is hard to underestimate importance of the Internet for modern international companies. In case they would lost the connection they could not operate at all. Data accessibility would not be biggest of their problems in such case.

Reliability

When Amazon data-center fails it looks like the whole Internet is down. Too many people host their sites on AWS and when it fails everybody notices that. Does it mean cloud is unreliable? Not at all. Important thing to remember: those guys who fail with Amazon don’t use geographical redundancy for some reasons. Amazon recommends to use it in case you want to deliver reliable service. It is not so hard to build reliable application hosted in the cloud and it is not a vendor problem if people don't do it. SLA is still 99.95% or so.

Additionally, imagine what would you do if such kind of failure happened in your data-center? With cloud you can have a mirror setup in another region or even in another vendor's cloud. It is hard to do have the same within your own data-center.

Performance

People often think that cloud computing is slower than traditional servers. There are various reasons of such opinion and some of them really make sense. People blame virtualization, but it is not the main reason of a slowness: vendors use hardware virtualization which means that for most operations they have the same performance as bare metal appliances. It is true that I/O latency is higher, but it matters only for high performance computing apps, not for most regular business software. It is also true that some of legacy applications could be slower after migration to the cloud. In fact, it is relatively easy to get good enough performance in the cloud if you think about it from the very beginning. It is just a matter of system architecture.

Legal regulations

There are some regulations that restricts some types of data to be hosted in a public cloud. Sometimes it simply means you need a mirroring to your private storage: just to have ability to provide government with physical access to your servers if it is required by some regulatory act. Some clouds are certified to be compliant with some regulations (e.g. there are plenty of HIPAA-compliant cloud storages). Sometimes there is no workaround and you have to use on-premise infrastructure for some part of your solution.

Conclusions

Cloud Computing is still new and evolving technology. It makes it interesting and attractive for engineers, but also there are plenty of missunderstanding and fears about it. Lots of people don't understand how it works, where it is applicable and when it makes sense to use them. High level of uncertainty leads to mistakes. Mistakes lead to disappointment. And disappointment produces fears. In fact, Cloud Computing is quite a nice technology which makes lots of things easier. You just have to understand how it works and what can you get with it. We hope this post brought you better understanding of Cloud Computing technologies.

We wish you Happy New Year and sweet winter holidays. See you in 2013!