Parse Is Winding Down: It’s Time to Move On

April 13, 2016

Parse Is Winding Down: It's Time to Move On

Last January, the popular cloud‑based backend provider Parse announced that 2016 will be its last operational year, with service ending January 28, 2017. Thousands of users were surprised by the news: Parse appeared a successful venture, and its unexpected closure has thrown more than a few development teams into panic mode.

Parse was bought by Facebook in 2013, and with Facebook’s endless funds at its disposal the company should have been solid. Apparently this wasn’t the case. The situation is similar to StackMob, another mBaaS (mobile backend‑as‑a‑service) which was acquired by PayPal two years ago and met a similar fate.

Want to know more about server-side for mobile apps? Read our post What is The “Server‐side” of Mobile Applications, and Why Do I Need It?

At the risk of sounding cruel, the HireRussians team is almost glad this happened. Not because Parse was a bad service — quite the opposite in fact. But just like any other technical solution, Parse had its limitations. However, because Parse was so effective, users sometimes forgot about these. In fact, Parse’s success was so huge that it actually became a detriment. Users began looking at Parse as a flawless, limitless service that could fulfill every requirement. Unfortunately this wasn’t the case. For example, one of Parse’s most common drawbacks was that it limited users to no more than a thousand results from a query. Not a problem for a simple app, but a big issue for more complex apps with larger databases. In fact, this limit could easily become a nightmare, resulting in loss of information and necessitating the redevelopment of large parts of an application.

To be honest, there are only two cases where our developers would have recommended Parse:

  • If the app is really simple and the database isn’t likely to become more complicated
  • If the aim is to develop a prototype (i.e. for an investor showcase), with the application undergoing significant redevelopment to support complex functionalities during a second phase

In all other instances, risking Parse’s limitations simply isn’t worth the reward.

First though, the positive: the Parse team has done an excellent job with “end of service” support, providing customers with guidelines and tools to help them migrate to a new backend. Users are supposed to start migrating by the end of April, so you should begin evaluating your options if you haven’t already done so.

And now the negative: to help customers transition to the new backend, the Parse team released two tools: a migration tool for data transfer to any self‑hosted MongoDB database, and Parse Server, an open‑source backend with which to run the Parse API on your own server. Sounds painless, right? Nope. Unfortunately, Parse Server does not support several of the functionalities Parse itself supports. If your app simply stores data or user‑sessions and authorizations, you won’t have a problem. But if you use all of Parse’s functionalities, you might find yourself in the unenviable position of having to redevelop a huge chunk of your app.

To summarize, Parse users have two options:

  1. Implement Parse Server on a self‑hosted server, with the knowledge that Parse Server is not equivalent to Parse functionality‑wise
  2. Redevelop your app using custom server‑side

The best choice is probably to redevelop the app using custom server‑side: for some cases it might be even cheaper than option 1 and it’s the only logical conclusion if the app cannot be scaled to work on Parse Server. Of course, there’s a third option: find a BaaS solution that covers the same features as Parse. However, this tricky road is paved with potential issues — for example another unexpected, Parse‑like shutdown.

If you’re dealing with iOS development, we think CloudKit is the safest route. It’s native Apple technology, so it’s not going anywhere as long as Apple is around. Alas, as with any other backend service, CloudKit has some truly puzzling restrictions — for instance, you can’t use logical disjunction in queries. But hey, nobody’s perfect.

When it comes to cross‑platform cloud‑based backend solutions, an industry leader is still being sought. A dozen or so services are touting themselves as desirable Parse alternatives, but very few can actually back up this claim. Some are automatically disqualified due to lack of functionalities, and others pretend to be BaaS when in fact they’re only providing IaaS (Infrastructure as a Service). Unike “true BaaS”, IaaS pretty much provides you only with computing resources in the form of a virtual server, but other than that you’re on your own, starting with deployment and finishing with app maintenance.

If you’re up for a challenge and you don’t mind a little risk, we suggest you check out AnyPresence and Backendless. Both enjoy positive buzz in the dev community.

In sum, Parse’s story is yet another reminder of the risk associated with third‑party components. But it’s not all doom and gloom, because HireRussians team is here to throw you a lifeline. If you’re looking to rescue your project(s) from Parse or any other dearly‑departed third‑party service, contact us. We’re ready, willing, and able to provide a stronger foundation for your future development business!

iBeacon: A Technology You Should Care About

March 25, 2016

By now you’ve probably heard about iBeacon and how it brings proximity and context marketing into the off‑line world.

Introduced by Apple in 2013, iBeacon (based on Bluetooth Low‑Energy protocol) quickly became the next big thing in the tech world. And unlike some “next big things”, this one was no flash in the pan. On the contrary, its popularity only increased until in 2015 another tech giant, Google, hopped on the bandwagon and presented its own version of iBeacon: Eddystone.

Two titans of the tech world battling it out. Compelling, no? Let’s dive in and break down how this mysterious, uber‑popular Bluetooth LE technology works and why it provides such huge opportunities — especially for marketing.

What is iBeacon?

The name iBeacon perfectly captures this technology’s raison d’etre – indeed, it’s a “beacon” for all of your mobile electronic devices: smartphones, tablets, and everything in‑between. But instead of functioning like a beam of light emitted by a lighthouse, iBeacon uses a Bluetooth signal to help a device within a certain range know what’s around, and creates push‑notifications for stores and retailers within the device’s range.

In other words, whenever you pass a Starbuck’s, iBeacon is what makes your phone buzz with the push‑notification, “Hey, come in and try our new almond milk caramel frappuccino with a cherry on top!”

Is your “marketing success‑sense” tingling? It should be!

How does iBeacon work, and how does it differ from regular push‑notifications?

iBeacon: a technology you should care about

If you wondered what’s inside this stunningly-designed beacon by Estimote — that’s what it looks like

iBeacon’s simple construction is the product of its single function: to send Bluetooth signals containing a universally‑unique identifier (UUID). When a mobile app is developed, UUIDs can be integrated and associated with certain places, i.e. “Anderson’s bookshop in the mall”, or “Clara’s Boutique at the corner of Main Street and 1st Avenue”.

The moment you enter the iBeacon’s range, your device receives its UUID. The device’s operating system then checks whether any of your installed applications are familiar with this UUID. If you have an Anderson’s or a Clara’s app on your phone, the operating system fires it up in the foreground and allows it to create a push‑notification for you, i.e. “Clara’s is one mile away and they’re having a shoe sale today!”

If you’d prefer to avoid iBeacons altogether, you needn’t worry about your device being invaded by push‑notifications at every block. That’s because your device’s operating system “ignores” any and all beacons until you install an app that’s relevant to a particular beacon and its UUID.

We know what you’re thinking: why do we need all of this iBeacon Bluetooth hocus‑pocus if we already have GPS, geolocation, and regular push‑notifications? Well, here’s the thing: for those technologies to run push‑notifications the same way iBeacon does, the application would need to constantly run in the foreground. You may be ok with this, but your phone won’t be. Any app that’s always in the foreground will zap your battery life in a blink, especially with geolocation turned on. Also, geolocation has its limits. It’s very precise outdoors, but not so much indoors.

With iBeacon, the application starts only when needed, i.e. within a certain proximity of a beacon, so the battery isn’t nearly as affected. Also, Bluetooth LE (Low Energy), which iBeacon is based on, isn’t the same Bluetooth that drained your battery life like a parched vampire a few years ago. The technology has advanced leaps and bounds since then, and this is called “Low Energy” for a reason. For an idea of the beacon’s impact on your device’s battery, see this graphic by Aislelabs, a Toronto‑based company providing data analysis services.

iBeacon: a technology you should care about

Beacon’s impact on battery drain by Aislelabs

Use cases

Beacon technology, whose considerable upside includes indoor/outdoor accuracy, low battery consumption, and relatively cheap hardware, has proven itself to be extremely useful in numerous scenarios. The first one that comes to mind is, of course, marketing. Location‑based push‑notifications can enhance the customer experience by providing information on location‑specific deals and discounts, offering product recommendations, and alerting a customer when an order/item is ready for pickup.

Beacons are also a powerful tool for creating push‑notifications based on proximity to points of interest. For example, if a museum curator places beacons near several museum exhibits and tunes the beacons’ range so they don’t intersect, an overview of the museum’s exhibits will be pushed to your device’s screen when you’re in range.

Here’s another idea: to use beacons for creation of an Ingress‑like game, in which you have to virtually “capture” points of interest by interacting with them in the physical world.

Beacons are also quite handy for indoor navigation. A great example is Estimote Indoor Location, an SDK created by Estimote, one of the world’s leading beacon manufacturers. Estimote Indoor Location allows for mapping a physical space and determining a person’s location in real‑time.

Another great use for beacons is in crowded areas, where information on the number of people in congested “beacon zones” can be provided to the server‑side of an app. This information can then be analyzed and used to develop faster alternatives for app users wanting to avoid long queues.

And these scenarios are just a start. The possibilities for beacons are limited only by the imagination.

What alternatives exist to Apple’s iBeacon?

Since 2013, when Apple unveiled iBeacon technology, many companies have co‑opted the idea and entered the “beacon business”. In 2015 Google extended beacons’ functionality so that devices using Google’s Eddystone protocol could broadcast three different information packages instead of just the one UUID. The first package type, Eddystone‑UID, functions just like an iBeacon’s UUID. The second one, Eddystone‑URL, is a compressed URL link that seeks to trigger a push event not in an application, but in the operating system itself. Instead of “pushing” a notification Eddystone‑URL “pushes” your device into following the link, which could take you to a promotional website or even prompt the installation of an app.

The third package type is a sensor telemetry package called Eddystone‑TLM. This tracks and transmits statistics on the beacon’s health (battery life, temperature, etc.) to a beacon operator. Access to this type of information is very useful, especially if you have a significant amount of beacons running.

iBeacon vs. Eddystone

Due to its proprietary nature, iBeacon is only compatible with iOS devices, even though it’s technically compatible with any device that supports Bluetooth LE.

While iBeacon technology’s main aim is to provide a more seamless interaction with digital devices in physical spaces, Eddystone goes further in the attempt to unlock beacons’ untapped potential by adding URL broadcasting, a great new tool with lots of potential for location‑based advertising and statistics monitoring, which solves one of the main problems encountered by users who manage numerous beacons.

However, “more” doesn’t always equal “better”, and in this case offering a wider features range doesn’t necessarily mean it’s best for the end‑user. From a skeptical point of view, Eddystone’s ability to push URLs directly into a device’s operating system, thereby bypassing the requirement of a dedicated application being pre‑installed, might make people feel like they’re losing control over their device and the content they receive. On the bright side, this might only be a problem for Android users since this powerful feature can be shut down by other operating systems whose users are keen to avoid the technology’s “intrusive” side.

For instance, using the Eddystone‑URL feature on an iPhone will require you to pre‑install Google Chrome, despite Eddystone being open‑source, cross‑platform, and compatible with any device that supports Bluetooth LE technology.

When it comes down to it, choosing between iBeacon and Eddystone is pretty much the same as choosing between iOS and Android. It’s all about personal preference, what you like and what you don’t.

Ok, I’ll bite. How much do these beacons cost and how do they differ from each other?

Beacons are available in a wide array of costs and technical characteristics. The price varies between $10 per piece for the cheapest option up to $30 — $40 for a beacon from a recognizable brand.

A beacon’s range depends on its transmit power. A range of 70 meters is possible (not counting beacons specifically developed for long‑range broadcasting), but the average range is about half that. Transmit power and signal emission rate can be adjusted via the beacon’s settings, but be warned that these parameters will affect battery life. A good rule of thumb is the smaller the range and rate, the lower the battery drain.

Depending on your settings, battery‑powered beacons can last from one month to two years on a “coin” cell battery. If you plan on maxing out your beacon’s potential, you might consider a USB‑ or AC‑powered beacon, provided there’s an outlet at the exact spot where you want the beacon placed. If not, it could be tricky.

Let’s wrap it up

Day by day, the online world merges ever tighter with the physical. Beacons are another powerful tool with which to intermingle mobile devices and physical actions, making technology even more essential to our daily lives.

At HireRussians, we love working with all kinds of new hardware, and we’re excited and grateful to be working on a few current projects that involve beacons. Bringing our clients’ cutting‑edge ideas to life is what we do best, and beacon technology is definitely cutting‑edge!

We believe beacons have much untapped potential, and in the coming years we expect further expansion of their built‑in functionality, along with a large number of new use cases. If you have an upcoming project that involves beacons, congratulations — this is a great time to begin employing this handy technology to help grow your business. And who knows, maybe the solution we help you develop will be the one to change the world’s perspective on augmented reality!

What is web security all about? An ultimate guide to web security for non-programmers.

September 4, 2015

“If you can’t stand the heat, stay out of the kitchen.”
Harry S. Truman

Over the last few years there’s been a huge fuss over vulnerabilities in web applications. However, even though almost every internet user knows about the Heartbleed vulnerability discovered in 2014, their knowledge of web security concepts is limited to things like, “I know my password should be long and complicated.” Greater concerns are left to the antivirus software professionals.

Unfortunately, the “ignorance is bliss” approach isn’t good enough to prevent a user’s data security from being compromised. And while you might not care on a personal level — after all, it’s only your data you’re worried (or not) about — taking a negligent attitude towards web security on a business level can be extremely harmful for web‑based businesses, especially when you’re responsible for your customers’ safety.

A malefactor who breaches a certain access level can send spam on your behalf or host illegal content on your server, leaving you to deal with abuse reports. Or, by learning the payment system’s binding, said malefactor can refund all of your orders and erase one month’s profits. And these are only two examples of the havoc that can ensue when security is compromised.

To realistically see the possible outcomes and learn how to avoid them, we need to start from square one and understand what “web security” really means.

This term has various interpretations — but omitting the details, we can say that web security is a combination of three aspects of the so‑called “CIA triad”: confidentiality, integrity, and availability. In other words, web security is about ensuring that data is kept in the hands of authorized users, and that it’s accurate, complete, and available whenever needed.

Let’s start with the triad’s first component — confidentiality.


How can an unauthorized person gain access to your information? The most obvious way was mentioned earlier: weak passwords. Honestly, the number of websites hacked due to having the same administrator login and password is so huge that it’s funny — in sad way.

The other big problem is the lack of proper access control — in other words, improper interpretation of the roles within a chain of command, resulting in a user who gets access to information that should be restricted from him.

Often times this happens if the protection of sensitive functionality components (i.e. the admin panel) isn’t based on employee access level but rather is just hidden in the application code without any visible access. In other words, instead of properly verifying that the user trying to access the admin panel actually has admin rights, the web application assumes that the fact he knows the admin panel’s URL is enough for him to gain entry.

This is an amateur mistake, one that happens because the application’s business logic wasn’t clear during development. In the presence of ambiguity, developers have no choice but to write filters for the roles (i.e. which users have access to which application areas) at development’s end, creating the possibility that some vulnerabilities were overlooked because the filters implemented late; possibly by two different developers. Therefore, it never hurts to confirm that the authorization module used throughout the application is easy to analyze, and that access is denied by default and restricted to whitelisted names only.


Once you’ve confirmed that users can only access the areas they’re authorized to, the next step is to ensure your service is available to the user whenever he needs it. Which means you’ll need to start thinking about the types of malcontents that can limit access.

Availability’s arch‑enemy is the nefarious DDoS (Distributed Denial of Service) attack. This attack’s aim is to overload the website with automated queries, thus denying real users’ access to the service. From June 11–13, 2014, hackers froze Evernote in this fashion, leaving users to question whether they should continue using a service that was susceptible to such a debilitating hack.

And here’s something really scary: every web resource is vulnerable to DDoS attacks. However, how many resources it would take to initiate an attack is another story.


If confidentiality issues arise because of user error or developmental negligence, then integrity, as well as availability, becomes another hackers’ milieu.

By integrity we primarily mean the malicious substitution of data. For example, a hacker replacing a customer’s bank account number with his own.

Integrity‑related vulnerabilities are extremely tricky because it can be hard to tell whether your website was hacked. For example, an e‑store owner might still receive her customers’ credit card payments, but the related info is also automatically forwarded to the malefactor. This is common in cases of industrial espionage and data theft.

While some systems such as WordPress provide tools for tracking changes by comparing current files with the files in the online directory, this still won’t guarantee your safety.

Some conclusions

You (as a user or as an owner of an internet‑based business) must come to terms with the fact that every web service can be hacked. And even if your code is extremely secure, there’s still the possibility of men in black masks breaking in and stealing your actual server.

An ultimate guide to web security for non-programmers - Data breaches infographics

To distract a bit from our serious topic, look at this beautiful infographics on world’s biggest data breaches by Information is Beautiful

Ah, but all is not lost. If the data’s value is less than the cost required for a hacker to obtain it, you can consider your service adequately protected. After all, no one will pay thousands of dollars to hack your personal webpage.

Taking a methodical development approach and paying attention throughout, and using proven, secure anti‑hacking technologies will provide you with a web application that’s secure from most common attacks.

There will always be aspects you can’t control — for example, your host’s vulnerability. The best thing you can do to ensure your own security via your host is to turn your code into something unreadable by obfuscating the libraries and encoding web configurations. This will protect you from standard hacking tools, i.e. reflectors.

If you’re struggling to decide which technology to choose, here’s some advice: choose a recent (but not the newest!) technology; and if possible, choose an open‑source one. The first suggestion will provide you with secure, out&‑of‑the‑box methods, and the second allows you to see the changes made to the technology. Two big negatives of closed systems are: 1) you have no information regarding the system’s encryption and storage, and 2) no knowledge of whether your information will be passed to a third‑party.

Before we dive into more details, let’s summarize our current web security checklist:

  1. Project requirement analysis is an important development step in terms of application security. Hence your provider must have a complete understanding of your security requirements prior to development.
  2. Dedicate enough time for security development in accordance with your project’s requirements. This may increase the final cost, but in the end you’ll get a better, safer product. Of course, it’s possible to rework the code later, but no one can promise that it will be cheaper or as effective.

    — If possible, avoid storing sensitive user data (SSN, credit card numbers, etc.) on your side. Shifting this responsibility to a third‑party and using the APIs of payment providers is preferable. If it’s absolutely necessary that you store this data yourself, then invest significant time in encryption algorithm development and allow this data to be decrypted only for specific back‑end procedures.

  3. For projects that don’t require a particularly custom approach, pursue out‑of‑the‑box solutions that are available inside frameworks, and CMS supported by large communities. This will reduce development costs — and besides, there’s no need to reinvent the wheel.

    — Use only time‑tested, community‑backed third‑party components when developing your web application(s) most important parts. Researching these components will increase development time, but you’ll be spared any unpleasant surprises down the road. If third‑party components are lacking, write the most important parts from scratch.

    — Most recent solutions (MVC, in particular) contain tools for defeating some of the most common vulnerabilities.

  4. Ensure that your configurations are secure. Many vulnerabilities can be avoided with proper website configuration.

Still unclear how all of this works? Let’s consider some common maladies:

DDoS attacks

DDoS attacks are based on your web servers’ structure. If we omit the hardware details, web servers can be represented as a set of processes sleeping in the background. When a query reaches the servers, one of the processes wakes up, starts working on the request, and goes back to sleep when the client receives the query’s result. The problem is that the number of processes is limited by server configuration, i.e. a server can only handle a limited number of queries simultaneously.

In a perfect world, this wouldn’t matter. But in the real world, some queries can linger for a long time; sometimes forever. This usually happens when the query is fairly complex or has links to internal objects, which leads the process into infinite recursion.

Let’s return to our earlier statement: every web resource is vulnerable to DDoS attacks. The only differentiator is the number of resources a malefactor needs for an attack.

Unfortunately, serious bottlenecks, advanced searches, or a noticeable amount of calculations make it easier for DDoS attacks to freeze a website. This is how hackers typically stage a DDoS attack. They create bots which overwhelm servers with a huge amount of requests. And the more complex these requests are, the less resources are needed for attack.

This is where the struggle between a hacker’s and a server setup’s resources begins. To effectively resist attacks, we either have to increase capacity (i.e. the number of processes in our web server), or optimize performance. The first option is usually cheaper. However, at a certain point maintenance of the server becomes more expensive than reworking the code. A cluster of 30–50 servers is already difficult and costly to maintain.

SQL injections

Even though the SQL injection attack has been around for over a decade, it’s still one of the most common attacks.

Here’s how it works: a malefactor locates an input area on your website — for example, the login and password form. Instead of the expected text, the hacker enters an SQL command containing special symbols. If your application doesn’t filter input characters, your web server will run the input as a command and the malefactor will be able to perform direct queries to the server’s database and bypass network security features. The hacker will be able to execute arbitrary commands on the target server: reading the contents of tables, deleting, editing, or adding data… the possibilities are limited only by the malefactor’s imagination.

In late January 2014, this is exactly how more than 20,000 Bell Canada customer records were stolen, including usernames, plaintext passwords, and credit card data.

Once in possession of logins, email addresses, and passwords, the aggressor is likely to hack a large number of your clients on other websites, because let’s be honest: it’s most likely that the same password will match the same email on other sites. Moreover, possessing email access opens a ton of possibilities for the hacker. For example, he could be possibly hack the user’s PayPal account. Sound crazy? Check out this story:

Unfortunately, even if you don’t store passwords but hash them (i.e. you perform some irreversible calculations on the password to obtain a unique string) and store the hashes, it’s of little help. Although theoretically it would be almost impossible to guess the plaintext password even with the hash, it could still be done by brute force, i.e. by a using dictionary attack, even if you add salt to the hashes (i.e. you combine your hash string with another arbitrary string, making deciphering more difficult). This is another reason to rethink your passwords. The longer and more random, the better.

The fact that a malefactor possesses a strong desire and the resources to decipher and steal data doesn’t mean we should make it easier for him.

What’s the best protection?

Each technology has its own methods for SQL injection prevention. However, they’re all based on the same principles: input constraint and validation, and usage of functions that treat input as a literal value so the SQL server doesn’t see it as executable code.

Also, you should avoid displaying detailed error information in the user database. Don’t let an attacker learn the database structure, the field names, essences, stored procedures, etc.

Error messages allow attackers to better understand the database structure and suggest which commands and scripts are best to implement. For example, the error message may tell the malefactor that his SQL query has the correct database name, but the wrong number of fields.

In the case of SQL injections, there are technologies which protect against such vulnerabilities by default — for example the ADO.NET Entity Framework, in which creating SQL queries is handled by a built‑in library.


Cross‑site scripting, or XSS, is a strong second in the “hacker’s preference” rankings. XSS is actually one of the specific code injection types. However, unlike SQL injection, whose attacks are aimed directly at the database, XSS’ purpose is to ensure that a malicious script embedded in a web page activates itself on the user’s computer. And once it activates, an attacker can access various websites through the user’s authentication or authorization and set about stealing data.

At first glance it seems that to implement a malicious script in a web page, a hacker would first have to bypass the web server’s security. Unfortunately, it can be done much easier than this, which explains XSS’ popularity amongst hackers.

Today’s web resources are filled with constantly changing content that’s often “pulled” from external sources (for example, a Skype plug‑in which highlights the number in the text and turns it into the button that the user can click to start a call. To do this, the plug‑in inserts a piece of html code which does not actually interfere with the site but still might steal the user’s cookie). Thus, in comments to any article on a popular web page there may be hidden a script that, if not pre‑filtered by the server, will run in the browser of each page visitor.

What’s the best protection?

The best protection is to follow this advice: don’t trust any input data from unreliable sources.

During development, pay special attention to input data validation. Although it won’t provide airtight protection against XSS, it will at least help eliminate the most obvious security holes. A simple check of whether the input contains special HTML characters allows you to protect against blatant attacks. Also, it can help in case the input contains some syntax constructions, i.e. URL. Here, as a validation, developers can check the input’s beginning: submitted URLs should begin with http or https. JavaScript is a bad idea.

After validation, you should focus on input escape. This is an important step for allowing users to enter text that includes special characters. Escaping replaces special characters with their entities, which prevents attackers from leveraging the input field to create potentially dangerous HTML tags like script, frame, etc.

But what if it’s still necessary to enable the input to contain java scripts, images, CSS, etc. — in other words, the very information that could potentially allow an XSS attack? In this case you can use Content‑Security Policy (CSP), which provides an HTML header that declares trusted and approved content sources. When using CSP, a user’s browser will load only page content that comes from trusted sources.

Another recommendation (which of course, can’t fully protect against cookie theft but at least makes it more difficult) is to install an additional flag, “HTTPOnly”, which allows you to restrict access to cookie scripts from the client side.

Also, some technologies (for example, ASP.NET) offer built‑in protections against XSS. You should research these.

CSRF — Cross‑Site Request Forgery

CSRF tricks the authenticated user of the web application into running a malicious script that performs actions on behalf of a legitimate user. For example, a CSRF script sends the web application a password change request, and after a successful user authentication the web application fulfills the request.

Another scenario: the malefactor emulates a login form from the user’s bank and leaves a link to it somewhere. Usually the link looks similar to the URL of the bank’s website page:\login vs.\login, attempting to confuse the user into entering her username and password because she thinks she’s authorizing something legitimate. The entered data is transmitted to the original website, allowing the user to log in there, but in the process the malefactor steals the data. The user, now logged into her normal website, has no idea her data was stolen.

What’s the best protection?

To protect against CSRF, developers can use a variety of techniques including a random token for each session validation request, or random field names in the various web application forms.

Tokens work like this: on our page we place a hidden field where a random ID is created. If our application doesn’t’ receive this ID because someone’s trying to log in from the outside, the application issues an alert.

In some technologies there are built‑in mechanisms for implementing anti‑forgery tokens (MVC). In other cases, this mechanism must be implemented manually or via third‑party solutions.

ASP.NET MVC includes its own set of built‑in helper methods whose unique markers, transmitted with each request, protect against CSRF attacks. These helper methods not only use a mandatory hidden field in the form, but also the cookies’ value, which makes request forgery very difficult.

If you predict CSRF attacks on your application, you should also make sure that the site is not allowed to be put into the frame.

Errors in business logic versioning

Careful consideration of business logic is important in order to preserve your data’s confidentiality and integrity.

Errors when dealing with complex objects, unaccounted competitiveness — these are typical problems associated with business logic.

For example, two managers simultaneously try to modify the same user. One finished editing and saved the result, while the second overwrites the changes and erases the first manager’s work. The same thing applies when an e‑store user adds goods to his basket from two different computers: home and work, for example. Eventually he might discover that his checkout page is a mess: some goods are not visible, the total sum is wrong, etc.

An identical scenario could occur if two managers simultaneously make two invoices with different serial numbers. Even though both will be sent, only one will be visible in their history.

What’s the best protection?

Just manage your application flow from beginning to end. That’s it.

Sensitive data leakage

This vulnerability appears after the website has been hacked, i.e. the attacker already has critical access (for instance, the database or administrator password). To prevent sensitive data leakage, the web application should properly deal with the data and provide it with optimum protection at every level.

An ultimate guide to web security for non-programmers -  Hacked data price infographics

Hacking your database could be quite profitable. Source: Information is Beautiful

If private user data is stored in plaintext or is transmitted through unsecure communication channels, your application is definitely vulnerable; and also if the application uses obsolete cryptographic algorithms or persistent cryptographic keys.

What’s the best protection?

First of all, use SSL to protect sensitive data transmissions.

Secondly, use a strong encryption algorithm. For password storage, use specially‑developed algorithms like bcrypt, PBKDF2, or scrypt.
If there is no direct need for storing sensitive data, avoid it. For credit card payments, you should redirect the user to the payment system or bank page. If it’s impossible to avoid storage, encrypt the data and allow access for specific back‑end procedures only.

Similar to SQL injections, you should avoid providing error information and the causes, and instead redirect the user to a specially created error page.

In sum…

Whether in the real world or the online one, you can never be 100% safe. However, real life‑threats (falling space debris, an escaped tiger, etc.) don’t stop us from going outside. Instead, if we just act responsibly, we can usually protect ourselves from danger. The same thinking applies to our online life.

During web application development, we recommend making a habit of consistently asking yourself whether you are:

  • Being vigilant during development
  • Not overlooking the business logic layer
  • Using secure passwords
  • Providing access to the right people

Forewarned is forearmed, and awareness is critical to safe passage online. As long as you strive for optimum security and consciously steer clear of potentially dangerous situations, everything will be a‑ok!

Rates of Top IT Outsourcing Providers

July 9, 2015

Ever wondered how much does the hour of the outsourcing developer cost? We figured it out for you.

We looked through top–40 Elance providers in the ‘IT and Programming’ section with publicly visible minimal rate. That’s how the distribution of the top Elance providers by rate intervals and by countries turned out to look like (click to zoom):

Top Elance providers hourly rates

The limits of perfection: where pixel-perfectionists need to stop and think

January 8, 2014

The implementation of pixel-by-pixel design for mobile applications: what is it, why is it so expensive and can you do without it?

An attractive design is paramount to ensuring your application will be popular. Regular users are often unable to evaluate code quality, advanced functionalities or the complexity of the algorithms that bind everything together. However, their appreciation for clean, sharp design is significant — to a point. Let’s talk about that point. Where is it exactly? And on a related note, why is pixel-by-pixel design for mobile apps so expensive, and why it is it not always necessary?

Below are two identical screenshots of the standard iPhone interface using iOS7. At least, they look identical, right?

Pixel by pixel mobile design - compare two screens

Fig. 1. Are these two screens really identical?

You don’t see the difference? No worries — most people can’t.

The two pictures aren’t duplicates — and truth be told, the effort needed to implement these two interfaces differs greatly. The left screen’s pixel-by-pixel implementation requires 2 – 4 hours of work, while the right screen’s pixel-by-pixel implementation could require more than 1,000 man hours. No joke!

“Pixel perfection” lacks an official technical definition, but it can be summarized as “implementing an application code design that gives almost every single pixel some degree of consideration.” The contrast of every border is sharp, the space between each content module is exceptionally proportional and the weight of every font is perfect. On the web, a “pixel perfectionist” will strive for a ridiculously consistent experience across every device, every browser, every screen resolution.

Pixel-by-pixel implementation means that every element of the initial graphic mockup has been translated with a 100% degree of accuracy into the final product. So when a client provides us with a mockup of his/her ideal application, an understanding of what “pixel-by-pixel design implementation” really means is paramount, since the expression is not as self-explanatory as it sounds.

A countless number of issues can arise when programming the application from a custom design aimed at pixel perfection. As such, using native components is often a much safer path.

As part of our efforts to explain pixel-by-pixel design’s many implications, we’ve divided the relevant mobile app design customization tasks into three groups, listed in order of complexity:

Group I. Natural adjustments: initial app branding

We call this group “natural” because some design suggestions are officially encouraged within Apple’s or Google’s design guidelines. These customizations are part of the brand identity that the makers of iOS or Android hope to see adopted in all the applications running on their respective devices. Such adjustments are usually well-documented and widely-used.

Guidelines include directions for large objects’ alignment, text alignment, basic text formatting (font family, weight, color and size), colors and margins, and padding of objects.

Pixel by pixel mobile design - table elements customization

Fig. 2. Natural adjustments: customization of elements in a table

Pixel by pixel mobile design - alert buttons

Fig. 3. Natural adjustments: alignment of “buttons” (labels)

Important note: at first glance the two buttons in Fig. 3 appear to be different elements; however, they’re actually two parts of a single solid element that implies settings for both appearance and position. Thus, if a client wants to customize their look (e.g. the text on the label needs to be upside down), then our intervention in the structure of standard iOS components is required, adding an extra level of complexity to the implemented design.

Group II. Complex-though-predictable adjustments

Extra time and effort is required to align smaller objects like right arrows or table icons (see the illustrations below). Though such changes are complex, requirements can be met on a predictable schedule so that initial design and final design coincide perfectly.

Pixel by pixel mobile design - arrows

Fig. 4. In-depth adjustments: arrow alignment

Pixel by pixel mobile design - table icons

Fig. 5. In-depth adjustments: customizing icons within a table

Since it’s assumed by default that we use standard iOS components and designs, clients should clearly indicate their desire for pixel-by-pixel implementation during the project’s planning phase.

Group III. Unpredictable adjustments: working with standard iOS components and font rendering

The most difficult, time-consuming and expensive scenario is when we have to deal with font rendering and letter spacing. We call these adjustments “unpredictable” because we must modify an operating system’s standard components.

The majority of these requests can be handled by an experienced developer. The only thing required from the customer is their acknowledgement that such tasks are on a totally different level of complexity, in that they require very specific programming know-how and much more development effort.

A customer must be absolutely certain that these design customizations are a must; otherwise, it could be an expensive and unnecessary hit to their budget. Often such tasks call for custom iOS app designs where all elements (buttons/labels, fonts, line spacing, indent, kerning and gradients) are unique. Developers can alert the client as to which design aspects are the most difficult and expensive to achieve, and suggest ways for modifying the mockup in order to reduce costs.

Let’s take a second look at Fig.6 for subtle differences:

Pixel by pixel mobile design - navigation bar

Fig. 6. Unpredictable adjustment: fonts in navigation bars (standard on top, custom on the bottom)

As you can see, the “Settings” button on the custom screen is slightly wider than the standard version. Also, the width of the “back” button on the navigation controller couldn’t be tuned with the standard component, so a custom button had to be used, which increased development time by a few hours.

The second noticeable difference is in the caption kerning (namely, the interval between letters). The kerning couldn’t be tuned in the default label components, so to modify its appearance a developer had to implement his own text output component based on a low-level text rendering function. This type of operation can add 20 – 30 hours of programming time for a single line label, 50 – 80 hours for multiline labels and 200 – 300 hours for multiline formatted labels.

If we take an even closer look at Fig. 1 (named Fig. 7 below), we can see the difference in text rendering:

Pixel by pixel mobile design - font rendering

Fig. 7. Unpredictable adjustment: differences in text rendering

This example is rather obtuse, but the lesson is that pixel-by-pixel design implementation requires a developer to consider every detail. If we promise a client this level of implementation, then visual coincidence is no longer a secondary detail.

The development of a custom font rendering component may take dozens of hours in a simple case, and up to 1,000+ hours for more complex cases.


With all of these thoughts in mind, you can now see why design implementation estimates vary wildly, depending on small differences in approach that aren’t even evident to most users.

Most of our “real-life” projects include tasks from categories I and II, and sometimes a task such as “custom button width” from category III; hence our work is, for the most part, deliverable in a reasonable amount of time. However, problems can arise when there are many small design components to be customized, such as button width, arrow level, color shading of standard components, label positioning, gradients, animation duration, active button areas, etc. Taken individually, each of these tasks is simple to implement — but one project may include many such tasks.

At HireRussians, we tend to know whether a customer needs pixel-by-pixel design implementation, or if the design is unintentionally complicated — and we always alert our customers to the obstacles and costs implications of complex implementations.

Some issues can arise when we’re asked to estimate implementation of a “nearly-standard” mobile app design. If the customer doesn’t explicitly state their desire to make standard elements non-standard, we usually prepare the estimate for the easiest case, and count them as standard. That said, a good thing to keep in mind is that it’s not always easy for a developer to notice non-standard design elements in mockups provided by the client, especially when the differences to standard design-elements can be quantified in a handful of pixels. For this reason, our developers won’t include any customization in the initial estimate, unless the customer clearly indicates that customization should be included.

The price/design ratio for the three aforementioned groups is illustrated in the graph below:

Pixel by pixel mobile design - price-to-design graph

Fig. 8. Price/design ratio showing the influence of design elements on price

At a certain point the price grows faster than its ratio to design: in other words, being a pixel perfectionist could cost you an arm and a leg. :)

The ideal way to create a pixel-perfect, custom-designed mobile application is to ask your developers to work iteratively: start with an app that matches the original mockup at an acceptable level, and then keep improving the interface on subsequent releases. After all, every honest developer takes prides in doing their best to come as close as possible to the original design without increasing the development costs.

In closing, you might be familiar with the saying, “A painting is never finished”. Well, in our opinion, neither is an application or a website.

Note: though this article’s illustrations are based on iOS interfaces, its conclusions are valid for all mobile platforms since they all use standard components.

Adaptive Layout, Responsive Design and Adaptive Design

June 24, 2013

If your business is web‐connected, you’re probably aware that digital media’s “buzzwords du jour” are “responsive” and “adaptive web design”. And, if you’re like most people, you’re probably wondering what these terms mean, how they’re different, and why everybody is so keen on using them.

Preconditions for the matter at hand

Back in the old days, when the “worldwide web” was still learning to crawl, you could only design with HTML and every desktop pc had the same screen resolution: 640 × 480. What a difference 18 years makes. Today, we have CSS, HTML5, JavaScript tools and, according to Wikipedia at least 146 different resolutions for computers and handhelds.

Which brings us to our first two questions: what are the current trends for Internet access, and should you consider mobile traffic when working on the web?

Between 1990–2011, worldwide mobile phone subscriptions grew from 12.4M to 6B+. Today, 55% of mobile owners access the mobile web (Pew Research Center, 2012). Since it’s predicted that mobile internet usage will overtake desktop internet usage by 2014 (Microsoft Tag, 2012), you should definitely care about your mobile web presence and the response from your mobile‐enabled customers.

Illustration from

Illustration from Microsoft Tag

To be successful online, you should a) ensure that your website performs well at any resolution; b) maximize your site’s performance on different platforms, and c) design your site with the idea of mobile touchscreen controls in mind, since users like having the same web options and opportunities, regardless of the device they’re using. So whether it’s a 27″ iMac with lightning‐fast broadband, a WiFi‐enabled iPad, or a “tiny” smartphone display using 3G or the Edge Network, it doesn’t matter. Your web application must make the grade.

And this is where adaptive layout, responsive design and adaptive web design come into play as the most common and effective approaches to making your web application accessible to any user.

Adaptive layout as a response

Employing an adaptive layout is the most common way to personalize a user’s web experience, depending on their device. An adaptive layout is characterized by defined layouts for different resolutions with the help of Media Queries*. The technology these queries use allows the web page to use different CSS style rules based on the characteristics of the device the site is being displayed on. Using an adaptive layout requires defining several resolution values and creating a corresponding style sheet or style rules for each. The end‐result is that resizing the window does not change the layout. For each screen resolution type, a unique user interface is created that differs from the others in terms of functional/information block size and arrangement.

When creating an adaptive layout for your website, the first thing you should do is define a set of required supported resolutions according to your target audience’s needs. Also, you should consider the following statistics for the most popular screen resolutions worldwide:


Here’s a list of screen resolutions that could be supported by an adaptive layout:

  1. Regular cell phone — 240 × 320
  2. Smartphone (iPhone) — 640 × 960
  3. iPhone 5 — 640 × 1136
  4. Tablet (iPad) — 1024 × 768
  5. iPad 3, 4 — 2048 × 1536
  6. Common TFT (equivalent to iPad 1, 2) — 1024 × 768
  7. HD — 1366 × 768
  8. “Huge” screens (i.e. the iMac 27”) — 2560 × 1440

* Note: Since Media Queries is a CSS3 module, it is not supported in old browsers such as IE8 and lower. But don’t panic! Other scripts can be used (i.e. Respond.js) that make min-width and max-width work in IE6, 7, 8 and other browsers lacking support.

Nota bene: Be sure not to confuse “adaptive layout” with “adaptive design”, as they are two completely different things.

Responsive design as a response

Responsive design is an extension of adaptive layout, and includes fluid grids and flexible images, together with Media Queries. It also requires having defined layouts for different resolutions. Within each layout, the design is liquid and responds to the changing window size by resizing the relative elements’ width.

Responsive design was first suggested in 2010 by Ethan Marcotte, who defined it as having three technical ingredients:

  • Fluid grids
  • Flexible images
  • Media Queries

Fluid grids are important for making a website look nice across multiple screens, but problems arise when they’re used with banner ads and videos, since these design elements are not fluid. When adding them, pay close attention to their actual size.

The term “responsive web design” itself can be confusing, since the design is not “responsive” to varying display sizes, browsers, etc. Rather, it “responds” via a fluid grid with flexible images, rather than by changing layouts. Nevertheless, the term came into being three years ago, and the aforementioned three ingredients became the term’s official meaning. When you get down to it, what we would intuitively call a “responsive web design” is actually an “adaptive web design”.

Adaptive design as a response

Adaptive design responds to different user conditions by adapting the website’s entire layout and functionality. Adaptive design is not just about screen size — it’s about accounting for the performance capabilities of every single device, a web browser of users, and rearranging the information. It means that you should consider things like browser window size, browser limitations, device performance, device functional potentialities (i.e. touchscreen and geo‐location support), etc.

Adaptive design’s main purpose is to ensure that visitors have a great experience, regardless of what device they’re using.

The technique of creating an adaptive design is often associated with the principles of progressive enhancement. Progressive enhancement implies that you start designing user experience “at the bottom rung” (i.e. an ordinary mobile phone browser), and then enhance the experience step-by-step: from classic browsers to modern JavaScript‐enabled browsers/touchscreen devices to 27″ iMac displays, browsers with the latest version of WebKit and lightning‐fast broadband. In other words, technology is applied in layers:

  1. Text layer — HTML
  2. Audio/Visual layer — HTML and CSS
  3. Interactive layer — HTML, CSS, JavaScript, Flash, and even Java applets
  4. Enhanced layer — everything under the WAI–ARIA (Web Accessibility Initiative — Accessible Rich Internet Applications) specification

Each of these layers creates different experiences, and each one should be treated with equal importance.

By following the progressive enhancement approach and applying modern technologies in an intelligent (layered) way, you can craft fault‐tolerance applications and deliver amazing user experiences.

Note: By contrast, an approach called “graceful degradation” (which was popular in the halcyon days of the semantic web) used an application’s premium version as the starting point for design and then built shiny, “fool’s gold” versions of it for those unfortunate users who had old browsers with JavaScript turned off. We believe this approach to be clearly inferior, thus we won’t say anything more about it.

You could consider “adaptive design” as a combination of “responsive design” and “progressive enhancement”. HireRussians is a supporter of this theory, and the following illustration outlines our interpretation of it:


To make your web application “adapt” to a user’s capabilities (in terms of both form and function), start by asking yourself two questions:

  • What key takeaway would I like users to gain from my website (information, pictures, video, audio, etc.)?,/li>
  • Who is my target audience and what are their browsing habits?

If you understand your website’s value to your users, and by extension the content they want to access, you should design an experience that is available to and usable by anyone, regardless of location, device, or program capabilities.

Knowing your users’ browsing habits will help you define crucial technical requirements. Do your users use devices with touchscreen displays? If so, make your image carousel swipe‐able, in addition to featuring “previous” and “next” buttons. Can their device recognize their location? If so, add a “Use Current Location” button to your site, in addition to a store‐finder form. Does their browser support HTML5 canvas? If so, replace a static image with a canvas element. You can also organize content blocks depending on a user’s device, or even use different content sets for different devices. The customization possibilities are limited only by the amount of “user research” you possess, and the available technology.

In sum, adaptive design is characterized as having defined layouts and functionalities for different resolutions and devices. As such, resizing the window doesn’t change the layout.

Techniques you may consider when designing adaptive web applications:

  • Media queries
  • Fluid grids
  • Flexible images
  • Progressive enhancement
  • Using different layouts and design elements, depending on the user’s device
  • Adapted content blocks

For an even better understanding of adaptive design, HireRussians’ UI Designer created this adaptive design wireframe for a food web store (example only):


In real life

Having worked on hundreds of web projects for clients worldwide, we understand the reasons for not wanting to build responsive or adaptive websites. And though we believe that adapting your design is essential these days, we feel that we should mention the “cons” so that you can weight them against the “pros”:

    Con #1: It’s expensive to design and develop several layouts to account for various functionalities.

In truth the cost increase is negligible, and very reasonable considering the return. Also, an adaptive or responsive approach is even more affordable if you decide to develop native apps for several mobile platforms.

To be honest, there are some cases when implementing adaptive or responsive design could be a monumental task, and thus become expensive, i.e. when retrofitting a large corporation’s existing web system with unique navigation, custom CMS and i-framed content all at once. But even in such difficult cases, a compromise can still be found; one which still keeps the user top-of-mind and delivers a quality experience. Later in this article, we’ll take a closer look at an example of a “compromise approach” to adapting an existing website.

    Con #2: My web content is not easy to adapt.

This is a very common lament, especially from existing website owners, and it stems from their belief that much of their content was created some time ago, and not always accurately implemented. But what is “web content”, really? The answer, of course, is it’s your website’s texts, images, videos, audios and forms, all of which can be styled with CSS. Therefore, you just need to give some thought to how you’d like your content to respond.

    Con #3: There isn’t enough support on common browsers.

True, there are some support issues with media queries in old browsers like Internet Explorer 7. But as we mentioned above, there are valid workarounds, like Respond.js.

    Con #4: My website looks ok on a mobile browser.

Thanks to Apple’s Safari, almost any website works just fine on a mobile device. But think about the last time you had to use “zoom” on a site just to be able to read its text on your iPhone. Wouldn’t it be much easier to browse an adapted 640‐pixel‐wide webpage? Also, you’ve surely seen websites that are hard to navigate due to dodgy touch control. With adaptive design, all of these issues can be accounted for and improved upon.

    Con #5: I already have a mobile app for my website.

Awesome! But have you seen the research performed by the Pew Research Center, which shows that 60% of tablet users prefer reading news on the mobile web rather than via an app, while only 23% get their news mostly through apps — with 16% using both equally?

    Con #6: It’s difficult to maintain an adapted website.

In some situations, it conceivably could take a little more time to make web changes; for example, when adding a new illustration you must make sure it has a consistent, high-quality look on different screen resolutions. However, in our experience we’ve never encountered an impossible maintenance task. Updating an adapted or responsive website simply requires the web owner to test it appropriately.

What approach should I choose for my web project?

There’s no doubt that starting a new web project with a progressive enhancement mindset coupled with adaptive design is a great way to go. With such an approach, you can finally design around user experience, and not just pictures and CSS.

But what to do about existing sites which were designed and developed in the days of yesteryear, before all of these modern technologies appeared and which already have an audience and users? What’s the best way to adapt these?

In a perfect world where time and money are immaterial, you would have several options for making an existing website friendlier for millions of devices and screens:

  • Building native apps is an obvious solution, since having apps for the major mobile platforms is better than having no apps at all. However, you won’t be able to build for every app store; also, bear in mind the Pew Research Center info about users preferring to read the Internet via the mobile web rather than via an app. Additionally, stand-alone apps will increase the amount of updating and maintenance required. Taking all of this into account, we don’t believe that native apps are a universal panacea for adaptation, but they are one of many ways to better engage users.
  • You could develop a separate mobile version of your site. However, this would result in additional maintenance and a large amount of development work. Also, do you know if your users would respond positively to a modified mobile version of your site? Before investing in mobile version development, get to know your users’ behavior and expectations.
  • Lastly, you could “throw out” your old site and design a new, adaptive site from the ground-up. This is a great option, though it would take a veritable Jedi to balance your daily work tasks with development of a new system. In this case, instead of waiting for Obi‐Wan Kenobi to appear, it would be great to have a development team you could turn to so you can focus on what’s most important — growing your business.

It’s very rare that an existing business has the luxury of creating a brand-new web presence that includes every device-agnostic technique, along with native apps for different platforms. That’s why there’s always a compromise when dealing with existing websites. Often the following approach is the way to go: maintaining the code and content that’s been powering the site, while adapting the site using media queries and “fluiding” the site — that is, making it as vertical as possible to provide for handy access from phones and other items with tiny screens. This path allows HireRussians to update a client’s content all in one place, while maintaining just one code and database. And of course, it also cuts down on development expenses.

The key point is that making your site adaptive is not always time and money‐consuming; you just need to pick the right approach for your specific needs, and proceed in a holistic manner since time and money aren’t limitless. Keep moving and don’t stop improving! That’s this article’s theme.

The Bottom Line

Thanks to our vast web development experience, we understand the need to raise awareness amongst our customers and ensure that their sites are as adaptive as possible. We believe that mobile traffic’s rapid growth will trigger a wave of website redesigning/updating, simply because the concept of adaptability is becoming a must-have for every web business.

Discovering Southeast Asia

April 4, 2013

Only a few months have passed since our last voyage into uncharted business waters, and here we are, supercharged for a new journey and busy packing! Next up are Hong Kong and Singapore, where we’ll search for new opportunities, new partners and some real, honest-to-goodness snake soup.

The questions we’d like answered (aside from confirming whether snake soup is indeed the elixir of eternal life) are related to what’s going on in these two key Asian hubs’ IT industries. The plan is so simple, we can only chuckle: we’re going to meet with our customers, friends and potential partners and ask them point-blank for their feedback. Foolproof!

On the way to Hong Kong

Way to Hong Kong

In Hong Kong we visited the Science Park, strolled the Avenue of Stars and rode a double-decker bus for the first time! We also enjoyed a fantastic four-hour long walk with Dennis, who acted as a cordial cicerone and gave us the opportunity to peer into the heart and soul of this amazing city.

Meeting with Dennis

Meeting with Dennis

We’ll spare you the rest of our touristic impressions. Suffice to say, for someone coming from Siberia, both Hong Kong and Singapore, with their skyscrapers, cars, malls and parks, were simply breathtaking.

On the promenade

Hong Kong views

Science Park neighborhood

Science Park neighborhood

The week after meeting Dennis was spent in Singapore, where we managed to cram seven business meetings into a tight schedule, on top of visiting a musical festival in Esplanade and enjoying ocean views on world-renowned Sentosa Island.

Singapore first impressions

Singapore first impressions


Our Asian mission was an unqualified success. Not only did we return to Russia with many fond memories, but we also managed to visit with our partners and clients and better understand their needs, culture and business habits. It’s one thing to talk over the phone and via email, but meeting someone face-to-face, on “their turf” so to speak, takes a relationship to a whole new level.

A big “Thank You!” to everyone who assisted with the trip and helped in expanding our business in Asia. Undoubtedly, HireRussians and its partners will both benefit from the strong relationships forged during this brief-but-intense experience in the Far East.

And regarding snake soup — talk to us in sixty years :)

London: The Place to be

December 5, 2012

About 15% of our customers hail from the UK, also known as the country of Shakespeare, the Sex Pistols and a long‐reigning Queen. In a way, Sibers and the UK have been strategic allies for what feels like centuries. English clients are smart, dedicated and confident: they always know what they want and what the fair price is. Also, communication is always a cinch: we’ve never had to explain anything twice, and all involved parties make their unique contributions to a smooth process and relevant results.

With the above in mind, it was a no‐brainer to finally make a long‐delayed visit to London in order to meet the majority of our customers in person and be inspired by their business ideas. A chronicle of our adventure follows…

First meeting with London

First meeting with London

Been there, done that. Or not?

This isn’t the first time we’ve traveled abroad this year. Previously, we took a business trip to Australia, where we visited the CeBIT conference and met with our Australian clients. This time around, organizing the trip was even easier, thanks to all of our partners who helped us collect the necessary documents and visas. It might sound unusual to Europeans and US citizens, but a bit of bureaucracy is a small price to pay to enjoy these vistas:

Photo from one of corporate trips of HireRussians' team

Photo from one of corporate trips of HireRussians’ team

Meeting with Clients and Partners

After the Australian trip, we learned an important lesson: pre‐planned meetings are the way to go. Life is unpredictable, and scheduling meetings ahead of time provides the flexibility needed for the inevitable rearrangements that crop up. It wasn’t easy, but in the end we created a very useful (and stress‐reducing) agenda.

During our two weeks in London, we booked 20+ meetings. Our schedule was tight, but we managed to keep things under control. In fact, while attending conferences and various points of interest a few bonus meetings took place almost accidentally. In honor of our hectic stay, we created a collage using some of the contacts we made. Check it out!

Business card collection

Business card collection

Lest you think this trip was all hugs, kisses and teddy bears, our meetings weren’t just about accepting our customers’ compliments and sharing our expertise — no, we also touched on some areas where we as a company need to improve.

Meeting with our client Julian

Meeting with our client Julian

We also discussed many new plans, projects and possibilities, but if we had to pinpoint the highlight of the trip, it would definitely be the business and personal relationships we created/strengthened. Gaining a better understanding of our clients’ personalities and needs trumps profit any day.

Conferences and Locations

November 19‒22, 2012
London International Conference on Education (LICE–2012)

LICE is an international conference dedicated to the advancement of theories and practices in education, promoting collaborative excellence between scholars and professionals. LICE’s aim is to provide an opportunity for bridging the knowledge gap between research and practice, and promote research esteem and the evolution of pedagogy.

We attended LICE mainly to gauge the relevance of our eLearning solutions and compare them to teachers’ actual needs. Presentations were made by teachers from 20+ countries and a wide range of issues were discussed, in areas ranging from nurse training to pedagogical career‐building. We spoke with teachers and professors and discussed their eLearning area needs; lucky for us, most of them were interested in accessing our applications.

Despite the fact that some of our software features were welcomed with genuine excitement, we came away from the conference with a slew of new ideas for needs we hadn’t thought of before, such as a real‐time system for ensuring how many people attend lectures, and how many of them correctly understand the material.

November 26, 2012
Mobile Monday London

Mobile Monday is a great initiative where the mobile technology community comes together to network and discuss key industry issues, as well as share experiences and ideas. At MM, asking questions is mandatory. True story: our delegate was so overwhelmed by people’s curiosity that he literally didn’t have time to take off his jacket before being engaged in conversation.

November 20‒21, 2012
IT in Housing Exhibition

From November 20‒21, the UK’s largest housing technology exhibition took place in the Olympia Conference Centre, London.

The IT in Housing Exhibition is the perfect opportunity for delegates and exhibitors to keep up appearances. 300+ decision makers, 200 delegates and 80 exhibitors (some of whom, i.e. IBM, are extremely prestigious) contribute to the home technology and improvement field. Vlad Labetsky, our man on the ground, managed to strengthen our existing partnerships and create some new ones by showcasing Sibers’ solutions to hundreds of visitors. All in all, the Exhibition was definitely a useful learning experience.

November 26‒28, 2012
Techhub helps startups get better faster.

TechHub is a unique environment where technology start‐ups can ramp up faster. TechHub nurtures an international network of like‐minded, tech‐focused entrepreneurs, providing a space where they can work, meet, collaborate, network, learn or just have fun. Getting the right people together is always the best way to make good things happen. At Techhub we learned about the teams and processes behind “start‐upping”. People of all ages were there, from teenagers developing their first website to experienced developers in the age 25‒30 range. Heck, there were even some thirty and fortysomethings who’d left the finance sector to start their own business. Thanks to initiatives like TechHub, tomorrow’s tech stars have a chance to shoot for the moon.

Travel Tips

For a Siberian, London’s weather is comfortable and warm; one big plus is that in London you don’t need a wide range of seasonal clothes. In Russia, and Novosibirsk in particular, people always have a special winter outfit, as well as one for spring, summer and autumn. And though Vlad hates to bring this up, while he was in London his hometown was “enjoying” a nippy −40°C.

For music lovers, London is a veritable Mecca. Good music and musicians are everywhere: in the streets, in storefronts and in all the pubs (as a matter of fact, many pubs have an “open mic” policy). While we were there the streets were decorated for Christmas, which only enhanced the city’s positive energy.

Last but not least, in London you don’t need — and probably don’t even want — a car. They’re absolutely useless: cars entering the city center must pay a fee, there’s a stunning lack of parking lots, and unless you’re a professional stunt driver, the roads are difficult to navigate. In short, trains/the underground is the way to go for visitors and residents.

London Street View

London Street View

Walking through London

Walking through London

Beautiful building

Beautiful building


Our UK experience was priceless. We learned a ton about our clients, strengthened our long‐lasting relationships and outlined next steps for new partnerships. Attending the aforementioned conferences provided an external point‐of‐view of our place in the technology and outsourcing world, and offered useful tips for polishing our future approach. We learned about solutions offered by other companies, and shared with them our 15 years’ experience in commercial development.

London: The Place to be

London: The Place to be

London is a very favorable environment for start‐up creation: not only is the City is the best place to be when it comes to funding, but the talent pool it attracts is incredibly vast. We won a number of new projects in London which are already in development, and a few more that we’re discussing with newly‐acquired clients.

So where to next? Singapore, perhaps? It’s quite warm there this time of year — or any time of year, for that matter.

What is The “Server‐side” of Mobile Applications, and Why Do I Need It?

November 30, 2012

HireRussians Mobile Team Leader
By Sibers Mobile Team Leader
Igor Chertnekov

When we speak of “mobile apps”, we visualize little bundles of awesomeness with which we love to play, fiddle and interact with. It’s hard to believe then that behind these apps is a complex server-side architecture developed by an experienced team of mobile developers, .NET specialists, PHP or Java coders. By the end of this article, we hope you’ll be more informed about the reasons why certain mobile applications cannot exist without a server‐side component.

There’s a lot of ground to cover on this topic, but for the purpose of this article we’ll limit ourselves to answering the most important questions, such as:

  • What does “server‐side” mean when it comes to mobile applications?
  • When is server‐side needed, and what apps require it?
  • What server types are available, and which one is the “programming language of choice” for each situation?
  • How long does it take to build the server‐side part of an application?
  • Server‐side as a 3rd‐party service?
  • What are the limitations of mobile apps, and what are the differences between iOS and Android-based devices?

Let’s begin by imagining mobile apps like islands: they often appear completely isolated, but most of them have an underwater connection with the mainland — allowing, for example, a constant supply of fresh water. In a similar way, mobile applications need to communicate with a server in order to return complex results to the screen of your (limited — no offense) mobile device.

Imagine a mobile apps like an island


The server-side of a mobile application

The server‐side of a mobile app is, in short, a software program running on a remote server. The main reasons why a mobile app may need server‐side are:

  • To store and ensure users’ access to common data
  • To ensure interaction between devices

Generally speaking, the server‐side part of an app performs operations that require access to services, information and functionalities not available in your mobile device. Such data includes, for example, data and image processing, storage, complex calculations, parsing and synchronizing. Server‐side also enables developers to backup data, make an application more secure, and function as the central unit in a network of a number of devices with the same app installed.

Let’s say you want to share a picture with another user. Wifi networks only work within a range of about 100m; Bluetooth devices can be separated by no more than 10 meters; and direct interaction is often impossible due to internet providers’ policies. However, all of these limitations can be bypassed by an application with server‐side backend.

Server-side prevents mobile device overload

When we use server‐side technology, we can improve the performance of a mobile app by moving the most intensive calculations to the server. We’re talking memory and pure processing power: consider, for example, an application that displays a list of restaurants and cafés in your surroundings. A comprehensive database of such places could weigh up to 1500Gb — an amount of space no current mobile device can handle. However, if we move the database to the server, we can shrink the mobile application size to something around 40Mb, which is definitely more acceptable.


Imagine now a stand‐alone mobile application that enables users to discover nearby gas stations. If a new gas station becomes available, the developer has two options: either release an update for each operative system, or simply add the new information to a shared database. After synching with the server, all users will receive info about the new gas station, regardless of their app version.

Research indicates that users update their apps every six months on average — and so with information needing to be refreshed frequently, using server‐side is a no‐brainer.

When do you need server-side?

Server‐side is compulsory for the following application types:

  • Apps exchanging data between devices
  • Search, booking and reservation systems
  • Blogging apps
  • Financial tools, organizers, news and information applications, shopping, productivity, social applications
  • Coupon and discount apps
  • Voice‐recognition apps or apps with other advanced media functionalities

Now, what apps don’t require server‐side? Any of the following, for example:

  • Single‐player games
  • Editors (audio, video, text or photo)
  • Calculators, converters
  • eReaders

Server‐side is also recommended when you need to keep data secure, or share it/sync it across multiple devices. Typical examples are fitness, dietary or blood pressure-logging apps.

Choosing the right programming language

Before choosing a language for the server‐side, you should have a clear idea of your app’s functionalities. Each language (PHP, Java, ASP.NET, etc.) has an already‐developed set of components that can make your choice easier: for example, if you’re building an application with CMS functionalities, then server‐side should use PHP because there’s a ready-made range of solutions related to handling CMS with PHP. When dealing with big databases or serious mathematical calculations, it would be better to choose Java or ASP.NET, as these perform better when addressing these types of needs.

Which one to choose?


How long does it take to deploy server‐side?

Depending on the project, creating server‐side can be a time‐consuming task. If we’re talking about a game that stores simple leaderboards, deployment can be done rather quickly. Conversely, the server‐side for multiplayer experiences often requires many man‐hours. Banking apps are even more taxing; their server‐side might take years to build due to the various measures required for implementation in order to grant secure access.

The fundamental question you need to ask yourself is this: what is my application’s purpose? The more advanced the data operations involved, the longer server‐side deployment will usually take.

Ready‐to‐use 3rd‐party server solutions

Let’s examine the practice of 3rd‐party server‐side providers for mobile apps. The idea behind a 3rd‐party’s “universal solutions” is for you to avoid the pain of building a customized app from scratch. However, there are serious downsides: these solutions only work well if you use them as remote data storage, and flexibility is generally poor. This means no customized design and a bunch of limitations — not to mention non-requested (and potentially annoying) advertisements.

On the other hand, custom servers allow you to build anything your heart desires, with hardly any limitations except for your own app’s innovativeness.

Servers for iOS and Android: what’s the difference?

Are there different requirements for the server‐side of iOS and Android? The short answer is “yes”. For example, one of Apple’s requirements relates to video streaming bit-rate: when streaming any video from a server, a low‐def 64 Kb/s video stream for slow internet connections must be provided. However, Google does not have a similar requirement for Android. Bear in mind that each platform — including Windows Phone and Blackberry — has its own specificities, and these must be accounted for when designing an app.

What’s the difference?


We hope this article has broadened your understanding of why developers insist on server‐side deployment. Getting it perfect is often essential for world‐class applications: hidden from view, servers perform most of the “dirty work” on behalf of your application, promptly returning the updated results requested by the user. And at the end of the day, that’s the difference between a happy, engaged user and a frustrated (ex) customer.

Visiting CeBIT Australia 2012

May 25, 2012

In 2002 the world’s largest trade show and ICT event known as CeBIT opened a branch in Australia and thus, the first CeBIT Australia was held.

CeBIT Australia 2012 - main entrance

CeBIT Australia 2012 — main entrance

This year Sibers’ employees attended the CeBIT Australia event personally, participating in the conference program and visiting the Exhibition floor. Vlad Labetsky, Sibers Outsourcing Consultant and VP of the Australian office, together with Alexey Burlakov, Sibers Senior Software Architect, met all the 30,000 people who visited CeBIT face to face (hehe!)

Alexey Burlakov and Vlad Labetsky at Darling Harbour, Sydney

Alexey Burlakov and Vlad Labetsky at Darling Harbour, Sydney

During the three day event visitors took part in Workshops, The Opening Ceremony, and the ICT Celebration Dinner.

CeBIT Australia 2012 - lunch time

CeBIT Australia 2012 — lunch time

CeBIT Australia 2012 - Sibers at exhibition floor

CeBIT Australia 2012 — Sibers at exhibition floor

CeBIT Australia 2012 - ICT Celebration Dinner

CeBIT Australia 2012 — ICT Celebration Dinner

Vlad and Alexey visited CeBIT during their month long stay in Australia, where they meet Sibers’ customers and partners. Our representatives will continue to be in Sydney and Melbourne, available for meetings, through the 17th of June.

Welcoming Sydney, Australia

Welcoming Sydney, Australia