Iteratia

Grafana - Dashboard for displaying metrics. Suitable for visualizing big data processing applications. Configurable to any set of arbitrary metrics. Open source!

Iteratia.com

Twitter

Facebook

Google+ Page

Even if you are working on a small short-term project, it is very useful to conduct at least one code review to improve the quality of the final result. At the same time, a code review is of paramount importance in long-term development, especially for large enterprise projects, because accumulating code imperfections can lead to disaster. In this article, we'll talk about our experience in organizing the code review process with the help of the Review Board.

Professional development is unthinkable without a regular review of all the updates and changes to the code, which are necessary to detect and correct errors that were overlooked during the development process.

First, this allows us to prevent injection of unwanted changes into the live version of the code; second, it improves the quality of the software product in general; and, finally, it enables developers to improve their skills. It should also be noted that the development team significantly increases the degree of co-ownership of the code thanks to regular discussions.

In large projects, any arbitrary developer cannot be aware of all the details of the project code, because each person is responsible only for a certain part. However, everybody gets to know some general information about the code, as the process of discussion allows each developer to get acquainted with the full codebase. Ultimately, this reduces the risks associated with the possibility of retiring the key developers.

The benefits of introducing a mandatory "Code Review," as one of the tools of quality control, are beyond any doubt. However, do not forget that the review itself requires compliance with certain rules. SmartBear company, in its blog, recounts 11 main points that are worth paying attention to during the code review.

Review less than 200–400 lines of code at a time.

Aim for your inspection rate to be less than 300–500 LOC/hour.

Allow enough time for a proper, slow review, but not more than 60–90 minutes.

Authors should annotate source code before the review begins.

Establish quantifiable goals for the code review and capture metrics to improve your processes.

Checklists substantially improve results for both authors and reviewers.

Verify that defects are actually fixed.

Managers must foster a good code review culture in which finding defects is viewed positively.

Beware of the “Big Brother” effect.

The Ego Effect: At least do some code review, even if you don’t have time to review it all.

Lightweight-style code reviews are efficient, practical, and effective at finding bugs.

Moreover, in one of its infographics entitled, "Code Review Solutions," SmartBear provides some statistics speaking in favor of the Review: the review process costs only 5–10% of the total cost of the whole software project, which is relatively inexpensive; however, finding and fixing bugs at the later stages of software development can be up to 2400% more expensive than correcting the same bugs at the initial stage of development.

In one of its scientific publications, the University of Maryland argues that the process of Review allows developers to find, on average, half of all the bugs in the code.

Today, many different version control systems (VCSs) are used as a central repository for project code (according to the DevProd Report prepared by RebelLabs, the most popular of which are Mercurial, Git, SVN, and CVS). Concerning the order of conducting the code review—either before or after committing it into the VCS—there are 2 main types of code review:

Post-Commit Review: When a senior developer checks code after it falls into the VCS, and, if necessary, makes some corrections—either writes directly in the code what must be corrected or uses special tools, which allow him to view the existing code and post comments to certain lines;

Pre-Commit Review: When changes are reviewed before they are committed into the VCS. In this type of review, the developer prepares all the changes that he is going to introduce in the code, he then sends them to a senior developer for verification, and only after they are reviewed and discussed, the approved changes will be added into the live version of the code.

The Pre-Commit Review approach is effective because it allows you to keep only already checked code in your main repository. However, when using this approach, developers should be prepared for the fact that possible lengthy discussions in the verification process may delay the code getting into the repository.

Modern VCSs rarely support the Pre-Commit Code Review, which is why developers often use third party multifunction programs for these purposes such as, for example, Atlassian Crucible. However, there is a great alternative to such cumbersome programs—Review Board. This program was developed by VMWare team; it is written in Python, it is a very lightweight product, and it can be easily integrated with different free and paid VCSs. The main feature of this program is that setting it up for a particular project takes minimal time, unlike similar heavy programs, which may demand weeks of preparation for a certain project. Moreover, Review Board is available to everyone free of charge—something that cannot be said about, for example, Atlassian Crucible, which, as seen on its official website, the price of the program is rather high.

Review Board is quite easy to use; the main working object here is a review request, which contains a usual diff with the changes, a description of the meaning of these changes, and the indication of reviewers; it also provides a number of helpful optional fields.

Dashboard of “Review Board”

The work with review requests is similar to processing incoming and outgoing messages: a reviewer receives a request for checking the changes from a developer, the reviewer then sends his review back to the developer (which can be interpreted as a response), and the author of the request, in turn, may extend the discussion by leaving comments to the received review. After validating and approving all of the changes, the review request is considered closed and the requester is entitled to inject all his changes into the live version of the code (VCS).

Comment options.

This program allows the reviewer to enter comments at any line of the code being reviewed via a special pop-up form. The option to assign a comment to multiple code lines at once is also supported; it is useful when you need to provide additional context for the discussion. You can use the Markdown markup language in the comments.

Another interesting option is the ability to open issues while reviewing code. While looking through the code under review, a reviewer can leave comments as suggestions or minor improvements. Some of those comments may be critical and require correction before sending the code into the VCS. To mark such critical moments, the reviewer can insert a tick next to the text notes to open an issue. The author of the review request can conveniently browse through all the critical issues and mark them as "fixed" as they are corrected.

Special plugins for integration of Review Board with different IDEs exist; the most popular are ReviewBoard Plugin For NetBeans, A plugin for IntelliJ IDEA to interact with Review Board, and ReviewBoard plugin for Eclipse.

As you can see, Review Board contains all the necessary functions and proves to be quite simple and easy to use.

We are convinced that the introduction of code review has a highly positive impact on both the quality of the code and the general involvement of the team in all aspects of the project. In order to get real benefit from this without increasing the bureaucracy, it is essential to choose the right tool and configure the processes. With the help of Review Board, you can quickly and easily set up the process of code review, whether for small projects or large enterprise systems.

Twitter

Facebook

Google+ Page

Nice mobile app marketing analytics tool: https://count.ly/

Countly is the only open source mobile analytics application. It collects data from mobile phones, and visualizes this information to analyze mobile application usage and end-user behavior. All reports and charts are shown in real-time! With Countly, you never have to rely on several hours old statistics.

Iteratia.com

Twitter

Facebook

If office politics are destroying your career   - maybe you chose the wrong company.

You do not have to spend your talent and hone your skills on the political games. This is a work in vain compensating for the shortcomings of the organization. Just imagine how much energy could be spent on creation instead. It is an unaffordable luxury nowadays.

If you feel that learning the rules and adaptation burn up too much energy - find a better use of your talent in another organization.

Iteratia.com

Twitter

Facebook

Orion IDE 6.0 (the web based IDE from the Eclipse Foundation) was updated. Among a great number of enhancements now it allows editing Markdown. Starting with that update, Orion IDE becomes a mature product, which can be seriously considered as a nice alternative for IDEA or Eclipse in web development. Try the latest version here.

Iteratia.com

Twitter

Facebook

A couple of years ago, Iteratia company was approached by a client with a request to undertake the development of his new project, the main idea being to create a system of online auctions. Our team, having huge experience in dealing with tasks in the field of software development, started to work on this issue without any reason for doubt - despite not knowing that in a short time our client’s idea would become an extremely well-chosen direction from an investment viewpoint and would require much more effort to maintain system stability under high loads.

At the beginning, everything was implemented using the classic scheme. The logic of the system was divided into three components:  users - web server - database. People entered our system, examined various auctions, made different bids, and all of these actions were recorded in our database. After the launch of the project in this state, our customer started an active advertising campaign of this Internet resource. Eventually, he requested that we create a chat system for the users to communicate online. The initial solution took our developers no more than one night, and the new feature was introduced to the system. However, after a couple of hours, it was evident that the interest in the resource was growing at such a rate that the entire system started to slow down terribly - an influx of active users, active instant messaging and a constant flow of bids - which literally hit the site like an avalanche.

An idea quickly emerged on how to fix it - physically separate the chat server from the main system; in other words, we just needed a separate computer with powerful software capable of surviving high chat loads. After studying world-renowned chat systems, we concluded that eJabberd written in Erlang could perform this task effortlessly.

This server is designed in such a manner that it can withstand large loads (it can cope with a huge number of concurrent connections). After writing a Chat bot and launching it as a separate module on another server, we ended up with an excellent performance of the chat system, which seriously reduced the load on the whole auction system. The main task of the Chat bot was to accept messages from users, filter them according to certain criteria (against rude words and flood), and send them back to the users. The decision to physically separate the chat server using eJabberd enabled us to resolve the issue with the online chat, which for a time was a problem for the whole project.

Almost immediately, it was decided to apply the already tried and tested technology to the bids - those, in essence, were the same online messages from users, but not with some arbitrary content - rather, with a full set of data (user ID, auction number, the amount of bid, time of bid etc.). So, another separate eJabberd server was launched, a Bidding bot. The key point in choosing the software for the Bidding bot was the fact that eJabberd, based on the XMPP protocol, provides support for many of the necessary features - delivery of confirmation messages (informing the user that his bid has satisfied all the criteria and was accepted), message queues (the time when these bids were committed is extremely important when accepting the bids), and the ability to archive messages.

Another highlight choosing eJabberd was that the XMPP protocol does not rely upon the existence of a single central server - it is an example of naturally distributed architecture. These systems are the most sustainable - in case one of the servers fails, the other ones redistribute the extra load among themselves, so the system continues to function normally. Similar systems are also easily scalable - adding (if necessary) additional servers allows the system to handle extremely high loads. We utilized this golden opportunity later by means of adding more physical servers to distribute the load, and this in turn, greatly improved the system's resilience.

We were so pleased with the achieved effect, that we have created another module called Info bot that has been deployed onto yet another separate server. This bot automatically updates information about the bids made on the pages of all active users present on the site.

The original structure described above has significantly changed. The scheme in the beginning was simple:

Users - Web Server - Database

Now it looks like this: 

Users – [Chat Bot | Info Bot | Bidding Bot | Web Server] - Database

The web server is now only responsible for the static content of the site. The decision to use the Jabber server “untied” us from our web server. Now, the dedicated separate modules contain all the necessary logic, without using either the web server or the database, and that of course influenced the performance of the entire system.

At the final stage of the project, we obtained an extremely powerful system for running online auctions. The system can store up to 10M of auctions in the database - already held, active and planned - providing the ability to run up to a few thousand active auctions simultaneously, with over 10K of active users taking part in those active auctions, and the minimum guaranteed time of page loading not exceeding 1-2 seconds. In addition, the system supports up to several thousand chats with over 10K of possible participants.

As we completed this project, large advertising campaigns generating huge loads on the system became a regular case. It was a very productive and rewarding experience for us; the successful implementation of such a large number of fully justified non-standard solutions in one project led to excellent results for the whole system.

Source: Iteratia.com

Twitter

Facebook

Rather a long time ago, Iteratia Corporation received an order to develop an unusual client-server application. It was assumed that the server would hold a huge number of simultaneous connections with desktop clients and perform exchanges of data between them, and later in this article, we'll talk about the issue of the server. Our company has extensive experience in writing classic Web applications; however, in this case, we realized that the traditional approach, which we regularly use for solving such kind of tasks, would be inappropriate.

The traditional approach involves using Java Servlet-containers suitable for working with HTTP-requests, which are certainly very comfortable, but not always highly efficient. The first thought that comes to mind when you need to increase the performance of client-server's interaction is to completely abandon the use of HTTP. In our case, the client communicates with the server to exchange small amounts of data, and our main priorities are maintaining performance and stability. For such tasks, the use of HTTP does not make sense because of its redundancy. For this reason, we decided to use another communication protocol of a lower level—TCP/IP.

At first glance, Java NIO is the best solution from the viewpoint of performance, but this framework requires the implementation of low-level code for working with sockets and data transformation, which entail significant developmental costs. Therefore, we needed a framework that would "hide" the work of Java NIO but with a versatile and convenient API.

Unfortunately, to date, there are few such ready-made frameworks - according to articles on the Internet, discussions on IT forums, and test reports - and the invariable leaders in this area for quite some time have been Apache Mina and Netty. And, if the first framework, we have already had an opportunity to try out, then about Netty, we have only heard positive reviews and intriguingly high benchmarks figures. As it turned out, Netty is better documented than Mina and is accompanied by detailed practical examples of how to implement a particular feature - that is why it was simple enough to master this framework. Overall, the success of these two frameworks was probably justified by the fact that they were both founded by developer, Trustin Lee. Here are his own words about these two frameworks.

Netty is a framework that supports multiple simultaneous connections and processes them asynchronously. The major advantages of this framework are its high performance, open source, and versatility, which means it supports most protocols of the client-server connection “out of the box," ranging from low-level protocols TCP / IP and UDP, up to contemporary WebSocket. The work with this framework gave the developers complete freedom, allowing us to solve transport problems of any complexity. No wonder that, in the end, our choice fell on Netty.

General information about Netty

For our customer's web application, we have developed our own communication protocol, trying to minimize the size of each message exchanged between the client and the server. And the most resource-demanding task was the writing of a class of encoders and decoders for the handlers of messages on both the server and client. Only some time after publishing the web application, we came across Google Protobuf framework, which solves exactly this issue, that is, it encodes and decodes the messages without assistance; you just need to describe the structure of all the messages in a special format and generate message classes for your programming language. Eventually, we decided not to move our application to Protobuf, but we nevertheless noted that in subsequent similar projects, Protobuf would certainly save us a considerable amount of time, especially as Netty supports Protobuf "out of the box".

Speaking about the productivity of solutions based on Netty, it should be mentioned that Netty channel handlers should perform only the logic that is directly connected with encoding-decoding the data. When the handler produces a message, all further actions on it should already be made in a separate flow - any blocking of the handler's flow not only inhibits execution of the handlers of other channels, but could also potentially lead to a loss of control over the channel. This simple rule will help you to get maximum performance results when utilizing Netty.

As a result of using Netty in our application, we have achieved an impressive performance; on the server with a 4-core processor and 16 GB of RAM, Netty easily handles thousands of simultaneous open connections, loading the processor by not more than 50% at its peak. This has not only saved us from the problems with the support of the live application, but has also reduced the costs of the hardware.

So, as Netty is so good, why do not we also apply this framework to our web development? Instead of the traditional web server, we could implement the server based on Netty, which is ideal for fast work with a large number of asynchronous requests to the server, and, as it supports them “out of the box”, we could use both AJAX and WebSocket requests right away, resulting in a more powerful server than the traditional one. So what do you think about this suggestion? Is it something you would consider? We’d be interested to hear your thoughts!

Source: Iteratia.com

Twitter

Facebook

Newly acquired by IBM - "Cloudant Company" (enterprise level CouchDb) added support of declarative queries and indexes. To create an index sufficient to list the fields. This method supports indexes based on multiple fields, as well as nested. Selector objects are used for selection: you need to specify by which fields you want to filter. Combination operators (and, or, not, nor, all, elemMatch) and condition operators (comparison, type checking, the array checking, regex) are also supported. Additional features of the selection are sorting and limitation of the list of the return fields. It is also promised to support full text indexes and geospatial indexes in future. Tutorial   Example Documentation

Iteratia.com

Twitter

Facebook

With the growth of popularity of web applications, supporting them inevitably begins to demand more and more resources. The first priority measures to cope with the increasing load include optimizing the algorithms and architecture of the application. But, what if all that can be optimized is already optimized, and the bottleneck is caused by the performance of the database? The solution is to resort to more complex techniques such as parallelization. This article discusses parallelization and, more specifically, the problem of configuring master-slave database replication.

Leading a project for a European customer, Iteratia company provides full support of an online service that we developed a couple of years ago. In a nutshell, this resource is a directory of data with a rather simple structure and a large volume of information.

The amount of data in the database of this online service has grown from a few thousand to more than 10 million records within 2 years. Such a rapid development of the resource led a code that worked fine with the initial number of records in the database to work ten times slower as the number of records increased to about a million. Moreover, the operating speed was degrading even faster than the speed at which the database was growing. In addition to slowing down the time of executing the requests, the number of requests was also growing; more search engines were displaying links to our service, more users were being directed to the service pages and, more page views were being served. Immediate measures were taken to eliminate the effects of the increased load - the programmers optimized the code taking into account expected traffic growth.

This solution improved the situation for some time, but this method of "optimization" has its limits. All subsequent steps of rewriting the code began to demand more and more resources (both time and money), while the system performance increased less and less. Therefore, when code optimization was no longer possible, and the speed of the database continued to fall with its growth, the need arose to find other ways to solve the problem. Our programmers were engaged in finding the solution while the database size continued to grow to 3 million records.

The next step after the code optimization was to improve the capacity of our equipment. The database was moved to a separate, powerful server. However, the growing traffic meant that even this solution was not enough. Each subsequent acquisition of more productive hardware became exponentially more expensive, while the incremental performance of the system was still insignificant. We inefficiently spent a lot of money and inevitably reached the need for parallelization.

While the issue of web server parallelization can be solved quite simply, in the case of a database, it is all a little more complicated. We can almost infinitely distribute the load and cope with the slow work of web servers by launching more and more identically configured machines and balancing the incoming traffic between them, but the bottleneck in this whole scheme is still the database. No matter how many web servers we have - 1, 5, or even 10 - all of them send queries to the same database deployed on a single server.

An effective solution in such a situation is parallelization of the work with the database, an integral part of which is data replication - the synchronization mechanism of multiple copies of an object. As the data is updated on the master server, all copies of the data on the slave servers must be updated at the same time, so that only one version of the data is represented for all users at any time.

Manufacturers of modern DBMS’s offer ready-made replication solutions, but in any working system can possibly introduce "errors" leading to system instability. A failure in the hardware, a long break in the network connection, and various failures and malfunctions in the operating system can all lead to a failure of the data replication entailing desynchronization and requiring immediate action to remove the source of problem and eliminate its consequences.

In other words, the replication process needs to be constantly monitored. If a problem is detected, programmers need time to find the source of a failure, remove and resynchronize the data, and restart the replication, which can take many hours when dealing with large databases. Most importantly, during such failures, a certain amount of incoming requests will not be served, which is absolutely unacceptable for a high-demand online resource.

In addition to data replication, another quite important issue is the organizing of data backups. First of all, this task requires significant effort on the part of the database administrator (accompanied by money to pay him). In order to get rid of some of the routine tasks, administrators automate the creation of backups as much as possible with the help of scripts. However, the reliability of such "helper" programs is questionable because such things are written "for himself" without thorough error handling and proper testing procedures. Any failure of such small utilities can lead to disruption of the entire system of backups. In other words, the system of backups, just like database replication, requires careful monitoring. Finally, performing backups using the built-in DBMS commands of a full data dump may conflict with the entire service because of the data blockage needed for the period of its copying, like, for example, what happens in the popular DBMS PostgreSQL.

Most large systems that deal with similar loads to us have dedicated DBA staff consisting of highly qualified employees to do all that work. We also tried to go down this route, but the organization of such a process takes time and requires a considerable amount of money, so we were faced with the question of how to optimize the cost of server maintenance.

The solution that allowed us to avoid the potential problems described above was to delegate data replication and backup to the service scalr.com. With a high degree of reliability, for a relatively modest fee, it provides database scalability and backup automation services, and it is faster, safer and, most importantly, cheaper than any specialist. This is user-ready software, developed by highly qualified programmers specifically for solving such a class of tasks and tested by thousands of users. Services of the scalr.com system are already used by more than 7,000 companies, among which, giants such as Oracle, Nokia, Samsung, and Walt Disney can be seen.

With the help of this service, you can create a so-called "server farm": All the client has to do is specify the desired minimum and maximum number of servers and the schedule of the backups. Then the right amount of servers is allocated, the user is provided with DNS endpoints, and everything else is done automatically. They make backups and restore everything as needed; if a server fails, they copy the data, launch a new one, and add it to the list of load distribution. At the minimum rate, the service costs only $100 per month, which, in fact, is less than a day’s pay for even the least professional system administrator, who does the same things with less reliability. This system is fully automated.

So, how does it work? The whole system is based on the Amazon Cloud, so you do not need to buy your own servers. It does, in fact, mean that the scalr.com service is suitable only for those customers who already have their system deployed on Amazon servers (like us) or those who are ready to move it there; otherwise, DBMS connection delays will be too high. In addition, not all the typical replication scenarios are supported. For example, you cannot make a strong main server and a small cheap “Hot Standby” solely for the purpose of a live backup, because scalr.com produces an identical hardware configuration for all the servers in the farm.

Such limitations suggest that the ready-made solution that Scalr.com provides is not ideal. Some specific requirements of the system may not suit a particular user. Nevertheless, the automated service is a simple and effective solution that will work in many cases.

In our case, problems of replication and backups imposed by parallelization of the work with the database have been safely and effectively solved by the transition to scalr.com’s services. Scalr has enabled us to use the user-ready reliable automated solution for those two tasks, reduce our monetary and time expenses that could be much higher in the case of alternative solution development, and it has allowed us to forget about regular monitoring and tuning of the servers. This now gives us confidence in the high availability of our online service.

Source: Iteratia.com

Twitter

Facebook

Alternative for Arrays and Objects. Advanced Java Script collection library with open source license. The library contains a big list of collections, starting with List and Deque and up to MultiMap and Least-Recently-Used-Removed-Set. There is also an exciting WeakMap for Browser and Node.JS https://github.com/drses/weak-map The library provides a common collection interface GenericCollection with useful methods: iterator(), forEach(), map(), filter(), any(), flatten(), clone() and so on. The selection wizard on the collection's web page helps to find a suitable collection for specific tasks using simple questions. Check it all here.

Iteratia.com

Twitter

Facebook

Did you know that you don’t need to pay big money for “website support and maintenance”? Read on to learn how to understand if website developers are creating a support burden for you and why it is better to avoid any “hacks”.

Programming skills can be compared to those of car repairs/tuning. Imagine that you are in a good car service center. If they install proprietary parts in your car and do a good job at fastening everything, hardly anyone will notice that a car element has been replaced. Equally, if a layman installs a non-original part and fastens it badly, leaving hammer marks on the car body and overturning the threads, this part of the car will likely rear its ugly head soon enough and a more qualified engineer will tell you that it was a botched job, done by a hack worker.

There is an idea of “stubs” in programming - when a developer does not implement a feature completely (e.g. omits input data verification or downloaded file size/type check) and just leaves a stub and a comment in code like this:

// here goes data verification

return true;

At worst, he doesn’t leave any comment at all.

In such a case, some malevolent people will easily be able to crack the website created by “hack workers”. Unfortunately, ignoring such problems can be a disaster, as someone could copy or delete all the data from the DB using an SQL injection attack. You can see list of important web application security weaknesses with their descriptions and consequences here.

It is doubtful that you will get any compensation for your losses. Most likely, you will get just lame excuses mentioning so-called hackers. If in this situation you turn to competent developers, they will offer to create your website from scratch, and they would be right to do so, because there is no point replacing one defective bolt and waiting for another one to fall out or even for the entire part to crash. Just correctly install a proprietary part and forget about unexpected surprises.

There is also an idea of “hacks” in programming. Returning to the car service analogy, hacks can be compared to winding the details with wires or duct tape instead of installing them properly in the right place with the right fasteners. For some developers, this kind of programming is their usual “style” - they will wire the engine to the car and set the price of the "car monthly support”, because you’ll have to change the wire every week.

So, let us consider how it looks in the terms of website code:

Did you know that you don’t need to pay big money for “website support and maintenance”? Read on to learn how to understand if website developers are creating a support burden for you and why it is better to avoid any “hacks”.Lack of separation to the parts - a change in one piece of code leads to a change in the entire project;

Mixing the logic of processing with the display of the data - a change in the display  leads to a change in the structure of the database;

Absence of a single configuration file - it is difficult to find and change the configuration parameters; the values can be duplicated;

Code duplication - it is difficult to correct all duplicated mistakes, you can easily forget to fix them in some places.

In fact, a high quality website does not need to be supported; it works normally without any intervention. All other regular payments to developers are only worth it if you are planning to implement some functional changes, for example, once a month.

Source: Iteratia.com

Twitter

Facebook

Simple and beautiful domain names (such as, for example cars.com and potato.com) have always received attention from people interested in earning money on the World Wide Web. Such an address provides enormous commercial potential for a variety of reasons.

First, beautiful domain names ensure a considerable amount of constant traffic without spending on advertising and promotion (because the domain name is simple, and people tend to enter concepts they are interested in with ".com" and ".net" suffixes). Second, attractive domain names are likely to be bought by large companies at prices up to hundreds of thousands of times greater than their face value. Third, popular addresses have a high possibility of being used as an advertising platform, and there are many more reasons.

However, quite a few owners of such domains choose to lend their addresses to companies using the Pay Per Click (PPC) advertising model for various reasons. In other words, companies advertise their websites on someone's domain by paying a fee to the owner of the resource. Clearly, for the majority of domain owners, it is a fairly simple way to ensure small earnings - there’s no direct involvement of the owner in the process and no liabilities or additional effort. At the same time, there is a possibility of a significant increase in income from proper use of such a "beautiful" domain.

For example, suppose you own “tables.com”, and you want to earn more than the 10% -15% of the revenue that usually comes from a PPC company by utilizing tables.com as a basic advertising platform. Creating your own business and eliminating the PPC intermediary is a viable solution - several pretty simple steps will give you an opportunity to utilize your domain name more profitably. According to our experience, there are already several projects where this approach has been successfully implemented.

Step 1. Creation of database.

The upper left corner of the page "tables.com" contains a list of various types of tables, which is a very useful feature of the site in general, but the ads presented in each category do not match the name of the category at all. For example, in the picnic tables section, we see references to programming courses, links to furniture stores, a reference to some office furniture - everything but references to companies selling picnic tables - and that is totally irrelevant advertising.

Our idea is to make the ads in these categories more relevant, using tables.com as an example, not by merely inserting direct links to other sites, but by providing only a text description of those companies (production, history, location) without any direct contact information (like telephone, fax, or e-mail addresses). The main entry point for contacting those companies will be the toll-free number of your website's operator, who will direct calls to the end-client’s company of choice. The operator must record all the calls because later you will need this data to justify the customer’s necessity to utilize your website for advertising his products. Besides, you have to detect the user's geolocation with the help of his IP address and offer him the most relevant set of companies (according to his city, neighborhood, and street), thereby increasing chances for conversion.

Step 2. SEO optimization and driving the website to the top position.

At this stage, your "beautiful domain name" has to be placed in the leading position of search engines in order to attract the greatest amount of users interested in your subject, i.e. the tables in our example. This can be easily achieved in the foreseeable future and does not pose a serious problem, so let's proceed to the next step.

Step 3. Sales managers of your website's services.

This step is the most important step of the whole project. The basic idea is to hire professionals who will call all the companies in the categories on the website, recite some introductory material, attract their attention, and finally sell them your website's advertising services. The trick is that your website is not just a new advertising platform that asks for money from a client. By that time, your domain has already proved its effectiveness as a tool by transferring a certain number of calls from your site to the companies on the list. This is where the calls logged in step 1 come in to play - at this point, the collected call statistics can be used as the main arguments in favor of the effectiveness of your advertising platform. In other words, the result of free advertising has been already obtained; this is the number of users who became clients of a certain company with the help of your website. And, the main thing is that you offer this company not to “try using your website's advertising services”, but rather to continue or discontinue the ongoing advertising, which has already produced some tangible results. In addition to the standard advertisement, a lot of extra services can be added for a fee, such as special placement at the top of the list of companies, a direct link to the company website (instead of just a text description with no contact), and a demo showing off the company's products in the ad with the current prices.

Why are we telling you all that? Actually, we have already developed several of our customers’ domains in this way, and Iteratia company therefore already has a clear idea of all the steps required to set up an advertising resource of that kind. The scope of this idea can span from washing machines to equipment for transportation of petroleum products. The only prerequisite is having a short domain name that already provides some traffic (and it does not matter how it actually achieves that).

Source: Iteratia.com

Twitter

Facebook

More than half a year ago Hadoop was updated to version 2.2 introducing the new "YARN" engine. The main problem of Hadoop 1.0 is the single JobTracker, which used to be a bottleneck in large clusters. Now Hadoop 2.2 uses a new approach for managing resources in a cluster labeled "YARN": the workload of a single JobTracker is spread among the ResourceManager (track application) and many ApplicationMasters (track tasks). Another benefit of "YARN" is the ability to support different job types: MapReduce, Giraph, Storm, and so on. Hadoop evolved from a mere MapReduce job runner into a platform able to run different distributed applications. Read more at IBM developerWorks . 

Iteratia.com

Twitter

Facebook

It is difficult to deny the fact that today, almost the entire population of developed and developing countries are dependent on mobile phones and various gadgets. Modern mobile applications allow users to accomplish a wide range of emerging challenges - image processing, weather forecasts, music recognition, and access to social networks. However, few people have thought about how the millions of applications get into the so-called "app stores" (Apple App Store, Google Play), from where users can download them to their mobile phones. This process is known as the publishing of applications. This article will shed light on some interesting features of Apple's policy for publishing applications in the App Store.

We first became familiar with the App Store quite some time ago, but since that time, Apple's policy in the sphere of publishing applications has been constantly undergoing changes.

It all started when our developers, creating their first applications for the Apple platform, faced the mandatory acceptance procedure for the products they planned to publish in the App Store. This procedure includes several successive steps of verifying the application according to the criteria developed by Apple. In contrast to Google Play, where the published products immediately get into the store without any verification, the App Store, in addition to automatic review, has special Apple teams to verify every application and every update. These criteria are described in full on the website for the developers of iOS applications. Moreover, Apple does not provide any guarantees as to the time period within which the application will be checked or when the final decision about its further destiny will be given - be it either a green or red light. Every year the number of criteria Apple uses to check new applications is growing and the criteria themselves are becoming more stringent, because modern craftsmen find various ingenious ways to circumvent the existing rules. Quite honestly, it does not make sense to list all of the criteria in this article, because you can review them in detail on Apple’s website for developers. Nevertheless, I think it's worth telling a couple of interesting cases from our experience related to the publication of applications in the App Store. Maybe after reading this story, you will be able to draw your own conclusions and be ready for any such possible turns of events in the future.

Last spring, Iteratia Corporation was approached by a fairly large bank with a request to develop an application providing some basic reference information - a regular bank's annual report, to be implemented as an application for iPad, with a search option on the page, and the possibility of opening the necessary topics, etc. Not seeing any possible difficulties in accomplishing the task, we signed the contract, started to work, and the application was written with ease. We were ready to publish it in the App Store in just a few days. However, after some time, we received a rejection notification from Apple with clarification stating that according to a certain point in their rules, our product could not be considered a fully functional application, and as it belonged to the section of ordinary e-books, it should have gone to the dedicated store. There was no limit to our surprise because our bank already had a similar application in the App Store that only contained the report for the previous year. According to Apple’s policy, links to existing published applications (analogs) cannot serve as arguments in an appeal against the refusal to publish an application. In other words, our application was rejected, even though Apple had accepted an analogous application for publication one year earlier.

Faced with this problem and after consultation with the client, our developers decided to extend the functionality of the application to avoid another rejection by Apple. After a few meetings and a brainstorming session, a set of additional functions were chosen for implementation in this application, including a map of the bank’s branches, videos, a news block, and so on. As a result, the project was approved and published in the App Store. It was concluded that, at the stage of creating the technical specification, the developers should immediately explain the possibilities of the platform to the customer in order to avoid possible future problems at the review stage.

Another interesting case happened to us last winter. Apple refused to publish not an application itself, but a small update for an app. During that period, our client was actively conducting an advertising campaign of his product, and as one of the advertising tools, he wanted to utilize the mobile application previously created for him. In the new update, we added the ad unit containing the terms of the campaign and the possible prizes for participating. The essence of the advertising was as follows “buy 3 units of product X and get a 10% discount”. It turned out that Apple prohibits the inclusion of information about any prizes in campaigns in applications because the user may perceive it to be information provided by Apple itself. In this way, the App Store protects Apple against possible claims by the users.

As you can see, there can be only one of two possible outcomes after checking your application - either publication or denial. However, do not forget that Apple's verification process is carried out by living humans trying to be loyal to the developers. There are cases when the team of testers at a certain stage of testing may need additional information (such as test accounts for the social network, for example), and of course they will ask you for that information before making a final decision on the application.

Finally, I would like to give a word of advice about publishing applications in the App Store when you have to meet a fixed date for launching a project in a limited amount of time. Apple has a special form for expedited consideration of the application (all verification steps are the same as in the standard test procedure), but the answer in this case is usually given in just 1 or 2 days. You have to realize, however, that a really good reason is needed to go for it, and you will likely be given only one chance to use such a "convenient and fast" way to test applications - this is in order to avoid users abusing the system for expedited reviews. In other words, you will need more than just a good reason to be given a second attempt.

The number of such cases is constantly increasing - new projects, changes in publishing policies, applications tested by different Apple teams - that is why any developer of iOS applications has stories and experiences of his own, which may be truly unique. We hope that our experience will help you in the future to circumvent possible obstacles.

Source: Iteratia.com

Twitter

Facebook

Here's some interesting statistics about the world of Java: - What technologies are used? (Maven, Eclipse, Java 7) - What technologies the developers want to master? (Gradle, IntelliJ IDEA, Scala, Java 8) - What types of projects are the most popular? (71% go for WebApps) RebelLabs' presentation provides more insight into these topics.

Iteratia.com

Twitter

Facebook

Experiencing a decreased performance of Internet services caused by a rapid increase in the number of users is a very common problem. The owner of any online resource dreams about a soar in popularity of his project, but often the sudden emergence of frenzied fame can be a shock to the whole system because the small margin of possible load causes its performance to fall inexorably. We would like to tell you about a similar case based on our own experience.

An interesting online service in the piggybank of our projects allows multiple users to edit the same document at the same time. At the initial stage of the project, the time for creating the server was severely constrained by the customer, so our developers built the server quickly, not really delving into optimizations. However, over time, the number of users of the service grew rapidly and our guys faced a performance problem - a lot of customers and a lot of documents being edited - and very soon, the server would likely fail trying to process all the requests. So, the goal was set to split the server into several components, which would each take a part of the computational load.

Making it so that one server catered for one half of the customers, and a second server catered for the other half was not an option, because the customers had voiced their intention to edit the same documents simultaneously. In that case, the complexity of solving the issues of synchronization would nullify the gains from such parallelization. Splitting all the documents across the servers was also not possible, because the user within a single session could run multiple documents, which would mean he would need to connect to each server separately and therefore have an n-fold number of server connections open in his browser at the same time. Such a solution runs the risk of reaching the limit to the number of connections, decreasing productivity, and violating the rather important principle that the client part of our server does not need to know about such implementation details. In other words, we wanted the user to utilize our service without any inconveniences, rather than having to deal with any limitations of the browser and the poor performance of the server. We therefore used a non-standard parallelization approach.

The first step to solving this problem involved the launch of a group of servers solely responsible for processing the documents. These servers guaranteed integrity and data consistency, processed transactions, and stored the entire history of changes. Our programmers created a special server working as a balancer for this group - it knew which server was processing which particular document and ensured that another server would not take over the processing of the same document, as long as the first one was operating normally. The only possible single-point-of-failure in the system at that point was that this node has to work permanently.

The second step was to launch a group of servers solely responsible for connectivity with the user’s browsers. Depending on the type of browser, the following three different types of connection could be used: a web socket (if the browser supported that technology), flash (if the browser did not support web sockets), or Ajax long polling (if the browser did not support the two previously mentioned connection methods). Otherwise, the task of the group boiled down to determining the appropriate server for editing, sending a certain command to that server, and forwarding the received response back to the client (that is, providing the Transport Server function). Nginx was set up as a balancer for the server group, connecting to the client's browser and maintaining the connection. As a solution was not present as a ready-to-use product in any of the available sources, our programmers were forced to create one of their own.

In its simplest form, our implemented solution can be represented by the following scheme:

As seen in this chart, each user connects through the HTTP-Balancer (performed with Nginx) to one of the transport servers. The transport server with the help of Documents-Balancer determines the editing server, which works with the specific document the user wants and connects to it. That is, two different users from two different transport servers can connect to the same editing server for simultaneous editing of the same document. Conversely, one user from one transport server can connect to multiple servers for simultaneous editing of multiple documents. In that way, both users and documents are divided across separate servers, significantly reducing the load on the entire system.

Eventually, we managed to get what we wanted; we increased the performance of the entire system thanks to the ability to scale. Adding a few more servers gave a very good stock for a possible load, and we can now serve a much larger number of users. Barriers to the growth of the customer base were removed, and as it now maintains only a single connection, utilizing the service is no longer a burden on the user's browser.

Source: Iteratia.com

Twitter

Facebook