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!

GAME LOCALIZATION FOR WINDOWS PHONE 7

Have you ever noticed how serious gamers seem to have their own unique language and culture? From old-school Zelda and MMORPG World of Warcraft to Halo and Half-Life, virtual universes are where today’s hardcore gamers spend several hours a day; many have even grown up in these alternative worlds. So what does this mean for your effort to release your game in new language markets?

There’s a host of game localization success stories out there and your game can join their ranks. By sensitizing yourself to localization elements in your personal gaming endeavors and with little bit of our help, you’ll be ready to conquer the hearts of gamers around the world.

In order to re-create your in-game experience for players in other countries, you’ll want to work with linguists, translators, voice talent and testers who have extensive experience playing games (whether for console, computer, mobile device, etc). Ideally, they’ll also be familiar with your game genre and have an appreciation for the unique setting and terminology. When this isn’t possible, look for linguists who are experienced in transcreation (or copy re-creation) and cultural peculiarities specific to both your regional markets and gamer demographics.

To make things a little bit more clear for those who don’t have much experience in this area, take a look at a small demo game developed using Microsoft XNA framework and Visual C# for Windows Phone 7. 

Dive into the Cloud: brief technology introduction

Cloud Computing is one of the most speculated terms in IT industry last couple of years. We call "cloud" lots of things, sometimes absolutely different. We're starting the series of posts, dedicated to large set of technologies somehow related to Cloud Computing. We start our journey from the very beginning: let's define cloud and understand what does it mean.

Historical excursus

Cloud sounds like something very new. But history tends to be cyclic: if something is happening there is probability that it was already happening before. Before we start, let's get back in time and see if cloud is really something new, or it is just something very old and known. We will travel in time for more than hundred years, to 1882. This year Thomas Edison, one of the most famous inventors of the 19th century, launched Edison Electric Light Station - first ever public electric power plant. You might be wondering, how does it related to Cloud Computing? Well, let's take a look how people used electricity before first power plants were launched. 

Thomas Edison

It was quite a big challenge to have electric power at that time. If you need electricity in 19th century you have to buy steam-powered electricity generator. You also have to buy coal for it. And don't forget to hire someone to feed it with coal and repair the generator if it is broken. And yeah, if it is broken - you just don't have electricity at all. And what is really awkward: you have to find place for it and then suffer from it's noise and stink. Sounds like not a very nice perspective, right? 

And here comes Edison. His company offered people to pay for electricity, produced somewhere far away from their houses and delivered to them via wires. There is no coal. There is no workers. Finally, there is no stink and noise. We could only imagine how those victorian gentlemen were standing in queues shouting "Sir, could you please take my money?". Nowadays, we would say that it was massive win of Edison's startup. 

If you compare Cloud Computing with traditional in-house IT infrastructure you will probably find out that computing power is very similar to electricity. With traditional infrastructure you have to buy servers. You also have to pay for electricity. You have to hire system administrator. Nothing works if server is broken. Finally, server room is very noisy place. The only difference: servers don't stink. Usually. In case you use clouds you don't care about all of these problems. You just pay money and service provider does all the job for you. 

Definition

Cloud Computing is quite a fuzzy term. Lots of people mean very different things when they talk about cloud technologies. One might be wondering, why does it happen? It is like in the ancient story about blind men and an elephant:

Once an elephant came to a small town.  People had read and heard of elephants but no one in the town had ever seen one.  Thus, a huge crowd gathered around the elephant, and it was an occasion for great fun, especially for the children.  Five blind men also lived in that town, and consequently,  they also heard about the elephant.  They had never seen an elephant before, and were eager to find out about elephant.

Then, someone suggested that they could go and feel the elephant with their hands.  They could then get an idea of what an  elephant looked like. The five blind men went to the center of the town where all the people made room for them to touch  the elephant.

Later on, they sat down and began to discuss their experiences.  One blind man, who had touched the trunk of the elephant, said that the elephant must be like a thick tree branch.  Another who touched the tail said the elephant probably looked like a snake or rope.  The third man, who  touched the leg, said the shape of the elephant must be like a pillar.  The fourth man, who touched the ear, said that the elephant must be like a huge fan; while the fifth, who touched  the side, said it must be like a wall.

They sat for hours and  argued, each one was sure that his view was correct.  Obviously, they were all correct from their own point of view, but no one was quite willing to listen to the others.  Finally, they decided to go to the wise man of the village and ask him who was correct.  The wise man said, “Each one of you is correct; and each one of you is wrong.   Because each one of you had only touched a part of the elephant’s body.  Thus you only have a partial view of the animal.  If you put your partial views together, you will get an idea of what an elephant looks like.”

The moral of the story is that each one of us sees things exclusively within one’s point of view.  We should also try to understand other people’s points of view.  This will enable us to get a proper perspective on different  situations and events.

What can we learn from this ancient story? One's understanding of something is highly dependent on theirs perception of the thing. Those people who use SaaS say that Cloud is SaaS. Those who use VMware products say that Cloud is Virtualization. Those who use Apple products say that Cloud is synchronization service for their mobile devices. All of them are right. Cloud could be very different. But we need some kind of definition just to be on the same page when we talk about it. There are several of them, but here at ELEKS we usually use only one, called OSSM:

• On-demand: resource is already setup and ready to be deployed
• Self-service: customer chooses what they want, when they want it
• Scalable: customer can choose how much they want and ramp up if necessary
• Measurable: there’s metering/reporting so you know you are getting what you pay for

You can use mnemonic phrase "Cloud is OSSM" (read it like 'awesome') to remember.
Let's try to apply it to several popular "clouds":
1. Amazon EC2. When you ask about new virtual machine it is ready to be deployed. It is completely self-service. You can choose how many instances do you want. And of course there are lots of reporting that allows you to measure usage. Passed.
2. Dropbox. When you ask about additional storage it is ready to be allocated for you. You can do it by your own. You can buy more space in case you want it. And you can see how much space do you really use. Passed.
3. Virtual server farm operated by your IT staff. If they have enough servers they are ready to deploy your VM on-demand. Usually you can't allocate new VM by yourself, you have to ask your IT guys to do it. It could be scalable, but usually it is not measurable: you don't have access to list of all your VMs and don't understand how they are used. Failed.

Basic vocabulary

There are few buzzwords that are usually used within same context with the cloud. We need to clarify them before we proceed to next topics about the cloud. 

Service models

SaaS. PaaS. IaaS. [Software|Platform|Infrastructure]-as-a-Service. What does it mean? What is a cloud and what is not? Well, technically you can build any of these in way it wouldn't be OSSM. But I wouldn't recommend you to do it.

Let's take a look at IT infrastructure. We can imagine it as technology stack with network layer at the bottom and applications at the top. Difference between traditional IT, IaaS, PaaS and SaaS is in management responsibilities between you and your vendor:

In traditional IT you manage everything, starting with network and finishing with apps. When you use some IaaS cloud service (think Amazon EC2) vendor does all hardware management for you. But you are still responsible for all software layers: operating system, database, frameworks, runtimes etc. PaaS is higher level option where vendor provides you with fully configured platform that runs your applications (usually it means you have to adtopt your apps somehow, but cost of adoption usually is not so big). SaaS is top-level service option: vendor manages all components of your IT stack. People usually tend to compare all three models, but we won't do it. All three models are useful, they just have different goals and user audience. 

Basically, IaaS is an option for system administrators (or operations team) who don't want to deal with hardware. With IaaS they can just create virtual infrastructure, programmatically configure it and have fun. PaaS is an option for software engineers that don't want to deal with system administrators. PaaS allows them to deploy their apps to abstract platform that incapsulates all the stuff, related to hardware, configuration and other things. And, finally, SaaS is cloud for end-users: they just got their software working and ready to use, without any involvement of IT stuff or developers. 

Hosting models

Another kind of buzzword usually used with the cloud is hosting models. People talk about public, private and hybrid clouds. What does it mean? 

Public cloud is a cloud infrastructure made available to the general public or a large industry group and owned by an organization selling cloud services. Private cloud is cloud infrastructure operated solely for an organization. It may be managed by the organization or a third party and may exist on premise or off premise. And finally, hybrid cloud is any combination of private and public clouds working together. Very simple, right?

Conclusions

Cloud computing is one of the most interesting areas of IT nowadays. Cloud market is growing very fast and producing new opportunities for businesses one by one.
Electric power analogy is very nice for better understanding of the future of the cloud computing. Almost no one have their own power generators nowadays. Same thing will happen with computing once: people will have thin terminals (e.g. mobile devices) that will be used for accessing massive computing facilities in the cloud.
Using OSSM definition you can check whether service is really cloud or you are victim of aggressive marketing that attach cloud label to anything in order to sell it. You can better understand key properties of cloud services when you build them.
Different service models allow you to manage only those parts of your IT stack you want to manage. With public, private and hybrid clouds you can share infrastructure with other people, own it completely or use some combination of the above.
See you next time. Stay tuned!

Android vs. iOS: UI/UX Differences

Challenge

Create application that supports both platforms (iOS and Android) and has a similar functionality optimized for interaction design principles and users expectations unique to each platform.

Environment

The important thing to keep in mind is that iOS and Android environments are based on unique for each platform guidelines, user interaction architecture and design patterns. There is a number of iOS and Android similarities in look and behavior of various UI components like

• information structure; 
• basic UI elements (sliders, checkboxes, tabs, text boxes, fields etc.); 
• list-based navigation; 
• majority of gesture touch controls (excluding “tap and hold” gesture, which is commonly used to reveal contextual bar with options or enter a data selection mode).

However the number of differences is worth paying attention to. Below you may find a short overview of the core design peculiarities that should help better understand differences in the design approach for both Android and iOS.

1. “Back” navigation. 
In iOS applications “back” option is placed in the upper-left corner of the navigation bar. It is used to navigate backward within the defined screens in the application however it is not used to navigate backward across the entire device.
In Android devices there are two types of “back” actions: “up and “back”. “Up” is placed in the upper-left corner of the top bar and is used to navigate up the application’s information hierarchy. In contrast, “back” option is presented as a button on the physical device that allows navigating backward across the entire device.

Back navigation in GMail for Android and Dropbox for iOS

2. Top navigation. 
In iOS applications tab navigation is placed at the bottom of the screen. In addition, according to iOS guidelines there are no more than 5 tabs displayed at a time.
In Android applications tabs are recommended to be placed at the top of the screen. Besides scrollable tabs are allowed to be used in case there are more tabs than can fit in the viewable screen width.

Top navigation in Google Play and Dropbox for iOS

3. Switching between various data views.
In iOS applications switching between views of the single set of data is typically done through the bar divided into segments.  Each segment is responsible for one view.
In Android applications switching between views is done through the UI control “spinner”. This control is presented like a drop-down list of options. “Spinner” is usually placed at the top action bar.

Switching between data views in Google Calendar for Android and iOS Calendar

4. Search.
In iOS applications the searching UI control is placed at the top of the screen mainly.
In Android applications several searching options are available:

• “search bar” at the top of the screen that is similar to the iOS approach. However the bar is hidden until the user clicks on the search icon;
• “search widget” that can be placed anywhere within the application interface. Coomonly it is used within the application’s action bar at the top of the screen.

Search in Google Play and Foursquare for iOS

5. Actions. 
In iOS applications can be accessed through the toolbar that contains action buttons, through the action button that is in the upper-right corner hand side of the navigation bar or through the buttons within the interface screen.
In Android applications it is recommended to display actions in the action bar at the top of the screen. If there is any need in displaying more actions than can fit on the action bar, either an action overflow icon appears on the action bar for devices that don’t have a hardware “menu” button, or the user accesses additional actions by pressing a hardware “menu” button on devices where there is one. Android applications may also use contextual action bar. A contextual action bar is a temporary action bar that overlay the app's action bar for the duration of a particular sub-task.

Actions in GMail for Android and GMail for iOS

6. Screen sizes and resolutions. 
iOS phones, for instance, come in two screen sizes and three resolutions (including the latest iPhone 5).
Android devices are represented by a lager list of screen sizes and screen resolutions. This issue has a significant impact on the layout while designing the application.

Summary

It may appear as the straightforward idea to create one application for both platforms however important issue to consider is that interface elements of both platforms are not the same.
Though application’s core features and functionality may be the same on both platforms application’s interface should follow specific for each platform guidelines. Therefore to meet user expectations and ensure smooth user experience application’s design should be adapted to the unique platform design patterns and respect native UI standards.

by Iryna Pantel, UX Designer

Why use Exploratory Testing?

Why Do We Need Exploratory Testing?

• At times, it helps in revealing many unknown and un-detected bugs, which is very hard to find out through normal testing.
• As it covers almost all the normal types  of testing, it helps improving our productivity in terms of covering the scenarios in scripted testing and those which are not scripted as well.
• It is a learn and work type of testing activity where a tester can learn more and understand the software if he/she was not able to reveal any potential bug.
• Although disliked by many, helps testers in learning new methods, test strategies, and also think out of the box and attain more and more creativity.

Advantages of Exploratory Testing:

• It can uncover bugs, which are normally ignored (or hard to find) by other testing strategies.
• It helps testers learn new strategies, expand the horizon of their imagination that helps them in understanding and executing more and more test cases, and finally improve their productivity.
• It helps tester in confirming that he/she understands the application and its functionality properly and has no confusion about the working of even a smallest part of it, hence covering the most important part of requirement understanding.
• As in case of this testing, we write and execute the test cases simultaneously. It helps in collecting result-oriented test scripts and shading a load of unnecessary test cases which do not yield a result.
• Exploratory testing covers almost all types of testing, hence tester can be sure of covering various scenarios once the testing is performed at the highest level (i.e. if the exploratory testing performed, it can ensure that all the possible scenarios and test cases are covered). 
  
  
  by Andriy Skop, QA Project Lead