Category: Uncategorized

The temperatures were getting higher and higher as the second quarter of our 2015 BHAG race was closing. Now that summer has just begun, all forecasts say it’s going to be even hotter. Luckily, Espeo is ready to welcome it with a big smile. The spring has definitely been a busy period for us but we didn’t let grass grow under our feet. Here’s a brief summary for those who have been following our ambitious last year undertaking (Espeo BHAG, Episode 1) with interest.

A transparent matrix as a precious guideline on our way

Espeo success is people: those who make our team now and those who will in the future. That’s why we do not want a sheer chance to rule who we hire and what happens to the people who are already on board. In the recruitment and talent management job good intuition and reflexes are very important, for sure, but as the company grows it needs well proven processes and some automatization. Achieving comparable results is getting more and more difficult if one addresses things intuitively as they come along. If you care about keeping the sense of fairness and ensuring comparability of results over time on a bigger scale, it’s even more challenging. That’s why we needed to introduce some change.

I admit, the works were time-consuming, as the system developed for about half a year and took several shapes before it finally turned into what it is today. Again, it turned out that balance is the best solution. Before we stroke it right, we roamed a bit. Our first approach was too centralistic, not engaging ordinary team members in a sufficient degree. When we realized that, we exaggerated in the opposite direction, which didn’t produce optimum results either.

Today, having achieved the golden medium which seems to answer all present business and technical needs of Espeo, we have 10-elements’ competency matrix which makes the processes of recruitment and periodic appraisal go smooth and efficient. It also makes everyone calmer and more confident that the evaluation is fair and objective, always according to the same factors. We feel we are now able to recruit exactly who we need, track our employees’ skills’ development and to remunerate it properly.

Be paid for your competencies

Here again, similarly to the above, before we introduced the new system, remunerations were based more on intuition and individual negotiation rather than on something that could provide 100% objectivity, a sense of fairness, transparency and order. Sadly, it also generated a lot of unnecessary negotiation and didn’t ensure much foreseeability – neither to the employees, nor to the employer. As we developed, it turned evident that we couldn’t afford what had not disturbed anybody’s dreams when the team had been small.

Again, the evolution of the final remuneration system was time consuming and frazzled the nerves and patience of many. Anyway, the effort was worthwhile, as today we may sincerely and openly say that Espeo has a fair and transparent remuneration system, which means every person with similar level of skills (including wide range of technical and soft skills demonstrated to both colleagues and clients) receives the same basic salary and agents like the period of service or additional roles are also extra rewarded.

The system also helps us to regularly update the salaries when employees acquire new skills, roles or the next year goes by. It makes it easier to plan the remuneration budget and provides valuable information to candidates and employees concerning the future levels of their remuneration. Being able to manage competencies and remuneration easily let us also decide to introduce another meaningful change and start paying salaries to Espeo intern developers, which pays us back with better quality internship candidates.

Some sport plus an apple a day keeps our worries away

We’ve been saying a lot about how much balance is important for us and how this approach determines Espeo’s success. To keep the ball rolling we’ve introduced some next employees’ pleasures like free fresh seasonal fruit every day for everybody in our Poznań office. The first cycle of squash league was played, the champions were revealed and the new one was opened. Those who don’t find satisfaction in hammering the wall can still play football or train running which is motivated by the Espeo Running Team’s regular starts under the emblem “Running is like coding. Not as boring as it looks”.

It is easier to run a marathon in a team relay

To sum up, we have a timid impression that our BHAG (to become the best Polish IT employer until the end of 2020) is doing well. Running a whole marathon individually is very difficult (and not many of us completed it last April), but if you divide it into smaller stages and approach it with a reliable team it can be fun, which we experienced in June starting in XLPL Eikiden relay race and finishing it with a great result.

As for present, we have just recharged our batteries during canoeing team building integration trip last Thursday and we are getting ready for yet another relay race in September (Poznań Business Run) which surely will be a good opportunity for another summery of Espeo’s ideas and efforts to succeed in our own marathon of becoming the best IT employer in Poland.

author: Małgorzata Pietraszewska

While working on a mobile application in Espeo I came across a strange error.

It appeared sometimes when I tried to sign in with Google Account. Typically, when you first log in to Google Services, you see the screen generated by Google with a request for access, e.g. for offline access.

Then another view is displayed, informing that signing in is in progress. After a moment you are signed in.

When you do it for the first time, there will be UserRecoverableAuthException thrown. This is how you should handle it according to official documentation:

catch (UserRecoverableAuthException e) {
// Requesting an authorization code will always throw
// UserRecoverableAuthException on the first call to GoogleAuthUtil.getToken
// because the user must consent to offline access to their data.  After
// consent is granted control is returned to your activity in onActivityResult
// and the second call to GoogleAuthUtil.getToken will succeed.
startActivityForResult(e.getIntent(), AUTH_CODE_REQUEST_CODE);
}

Then you should also handle onActivityResult() method:

onActivityResult(int requestCode, int resultCode, Intent data) {
(...)
final Bundle extra = data.getExtras();
mAuthToken = extra.getString("authtoken");
(...)
}

This way you can get the authorization code, which can be replaced with the access token on the server side.
GoogleAuthUtil.getToken (MyActivity.this, account, scopes) returns only the authorization code, and not the correct access token. It is safer, because Android code is easy to extract. Retrieving access token is a task for the server.

When UserRecoverableAuthException is handled this way, application will return proper authorization code regardless whether the exception is thrown or not.

This solution worked perfectly on every device but one. One particular
Samsung Galaxy was throwing UserRecoverableAuthException in loop, so the signing in screen was shown repeatedly, rendering use of the application impossible. It turned out, that “don”t keep activities” option was enabled in developer options in this device.

What is this function actually for?

If your device needs memory it destroys activities which are not visible. So you have to consider that your activity can be recreated any time. “Don”t keep activities” option is there to simulate your application when your device needs memory and destroys your backstack activities. But the order of destroying Activities is not random – the previous activity being not available when your app is in the foreground is the rarest of rare use cases, almost impossible on newer devices.

What happens when it occurs anyway?

First we should consider what startActivityForResult() function actually does. You use this function to launch an activity for which you would like a result when it finishes. When this activity exits, your onActivityResult() method will be called with the given requestCode.

So we send an intent to start Google-provided sign in Activity, result of which is sent back to our Activity. But, our Activity does not exist any more! It was killed, because it had not been in foreground.
Our Activity”s state will be restored, and UserRecoverableAuthException will be thrown again and again.
That is why method onActivityResult() will never be invoked.

Even though this situation is highly unlikely there”s an approach that you should always take when handling situations like this, because every Activity that is not on the foreground can be killed any time.

To handle signing into Google with “don”t keep Activities” option enabled, you can for example use boolean variable, which persists information whether current Activity was killed before, and if it was, you won”t call signing in function again and let the onActivityResult() function to be called and handle response. Here”s a code example:

@Override
public void onRestoreInstanceState(Bundle savedInstanceState) {
super.onRestoreInstanceState(savedInstanceState);
mUserRecoverableThrown = savedInstanceState.getBoolean(RECOVERABLE_FLAG);
}
@Override
protected void onSaveInstanceState(Bundle outState) {
super.onSaveInstanceState(outState);
outState.putInt(SAVED_PROGRESS, mSignInProgress);
outState.putBoolean(RECOVERABLE_FLAG, mUserRecoverableThrown);
}

And at the point where downloading token AsyncTask was executed, you must first check whether the Activity was not already killed with UserRecoverableAuthException thrown:

if (!mUserRecoverableThrown) {
getProfileInformation();
}

To sum up, always test your application with the option “don”t keep activities” – it should also work fine in a situation in which all the other activities have been killed.

It is worth to disable it again after testing – apparently many developers forget about this option, and some of the popular apps installed on your phone may not work properly.
So if your device suddenly starts behaving strangely (often during signing in to apps) – check if the option is enabled.

author: Iga Stępniak

Finland Sustainable Business Partner for Poland – today’s seminar is organized on the occasion of the State Visit of the President of the Republic of Finland to the Republic of Poland. The seminar will be attended by:

• H.E. Sauli Niinistö President of the Republic of Finland
• H.E. Bronisław Komorowski President of the Republic of Poland
• Mr. Jan Vapaavuori Minister of Economic Affairs of Finland
• Mr. Janusz Piechociński Deputy Prime Minister, Minister of Economy of Poland
• Mr. Petteri Orpo Minister of Agriculture and Forestry of Finland.

The President of the Republic of Finland is accompanied on his visit to Poland by a Finnish high level delegation. The Delegation includes representatives from several Ministries, Organizations and Business Sectors, such as Energy, Cleantech and IT.

Finland, known for its High Technology, Cleantech Solutions, Quality Education and Advanced R&D, is one of the innovation leaders in Europe. The country is regularly ranked internationally among the world’s top performers in numerous surveys and studies. Finnish companies have built up an excellent track record in a variety of fields and have proven to be a long term and stable partner for Polish enterprises.

Finland is a major business partner for Espeo Software. Espeo is based on Finnish roots and style of cooperation. The software house has learnt a software development style in Finland. Espeo is a combination of the Finnish attachment to agile methodologies and attention to usability with the Polish software development spirit and talent.