MetaTest

The client appeared without a clear understanding of the future product. Instead, he stated goals he wanted to achieve. The company management was sure that employees should continuously take psychological tests. There were only some example tests and a desire to get graphical reports afterward.

There was a need in access roles and levels, for example, the heads of departments should have control over testing process deadlines of their subordinates. For example, “The whole department should take the psychological type test by the end of November.”

testing process

The system seemed to need several roles with tasks and privileges. We agreed on implementing Access Control List (ACL) pattern where users have roles and roles own resources. Thus it was easy to add new resources and roles during development of the project.

When we delivered MVP, the client decided to change the project audience. Instead of being used inside one company, it had to be a cloud product for many companies. Thanks to ACL pattern, it was easy enough to rearrange access levels and to add the “Cloud administrator” role.

By that time we had an extensive understanding of the project roles and goals.

Editors created tests and reports for users and administrators. Staff officers managed employees database, sent invitations and controlled the process of test taking. Summary reports were available after all of the staff members had finished the tests.

 For notification purposes, we added a personal messaging system. Now the administration could send test invitations to single people or whole departments easily. We also sent a copy via e-mail. If that was the employee’s first invitation, we created a new account for him.

personal messaging system

About reports. They had to be extremely flexible with different types of graphs and with the support of statistical math functions. For example, one can show personal motivation question answer only for people that scored 10 points more than average or filter people that are working in a company for more than a year.

graphical report

We could solve that by writing code for each specific report type. But we decided to write a unique report creation language, so-called DSL (Domain Specific Language). We used Twig templating engine as a base. Twig is a complete language with conditions, cycles and variables, but it is safe and is working in a sandbox environment.

Then we added functions for graph plotting, tables and statistics calculation. Also, we connected the app data to the report script (user data, answers, scores, averages, dispersion).

DSL-based report template

Then we created the logo and UI design, added some extra features like quizzes on the homepage and banner rotation functionality. As a result, we got a stable and user-friendly product. All thanks to nice initial requirement gathering and agile development process.

Tagfly

The customer wanted to create a tour booking aggregator with blogging functionality. He insisted on having flexible Pinterest newsfeed, tagging, categorization and search functionality in the blog area.

We created a special syntax to describe feed rules for categories. It was simple enough for users and quite feature rich to achieve customer goals. Here is an example of feed rules in the “France” category

feed output rules and feed itself

The performance was critical in tour search. We minimized number of API requests and created flexible caching system. Site fulfills queries according to a broader search request and caches them. Then user filters search results for a specific region, hotel, comfort level; then information is updated in less than a second.

tours search

Unfortunately API was not suitable for such an approach. It limited the number of tours, which we could get in a single request. That’s why if you give a broad request to it, part of the results doesn’t come out.

After fixing many bugs in provider’s API, after tons of support emails and hours in skype, we managed to create an algorithm where we split the broad request into subrequests and set up the caching so everything worked well then.

A similar problem was with getting the final price from API. It was important since payment gateway was automated and there were no phone calls from managers between tour search and payment itself. Users from different countries should be charged differently for a visa, fuel surcharge and even for hotel and flight. API had no input parameters for such thing, so we created our own database to consider all this stuff. Thus we got full and accurate pricing precise enough to send the user a bill. 

accurate pricing

Everything else was a piece of cake. We connected payment gateways, did some UI design and tested everything. Then we created landing page editor for marketing purposes where landing pages are built from website content.

«TagFly» was an exciting project both for us because we solved challenging engineering tasks, and for the users, because they can travel more easily now.

homepage

Playmusics

The customer wanted to create an online musical library - a mashup of VK.com social network and LastFM. The most obvious way to organize search was to create a semantic database of artists, albums, tracks and connections between them. Querying that DB allowed us to find the right track and to search for an mp3 file in VK later. To keep semantical data fresh we had to configure replication between our server and MusicBrains service or a similar one. That was the right way, but after estimating semantical DB size (around 100Gb) and replication problems, we came to a simpler solution.

Quality of VK search API is questionable, and VK database is not semantical. It's just a list of tracks uploaded by users. There were lots of duplicates and misprints. But we decided to take this "dirty" output and to filter it through LastFM API. Also, we removed duplicates, fixed typos with our algorithm. If we could not find track author in LastFM, we listed the track under "Other" category. Thus we got the almost semantic grouping without having our own semantic database. To minimize the number of requests and to improve performance we implemented several cache levels: for popular requests and artist data.

with semantic database

schema we implemented

About UI design. The whole website is a music player. Current playlist, search results, user playlists are all shown in one manner to make UI clean and intuitive.

search results

create a new playlist

loaded playlist

We created MVP and deployed the website. Traffic increased, and we found out that VK API wasn't a good fit. It had undocumented flaws and limits that were much lower than announced. Modular architecture that we always used was a great helper; it allowed us to rewrite the search module without touching the rest of the code. We replaced API with HTML parsing of search page in VK. Thus we preserved the whole initial schema, making service completely functional.

So we managed to create a service built on top of public APIs with caching to improve performance. It was crucial to write several prototypes to choose the optimal solution. Modular architecture approach helped us a lot, and when the external server went down, we had rewritten faulty module only.