Work on Forehand app started

I have just started working on the new app called Forehand. It’s going to be an app for table tennis players willing to stay up to date with table tennis news and to develop their skills. There are 2 versions of Forehand app coming: iOS and Android one. I put a placeholder landing page at forehand.app already. I’m aiming to release the app on both platforms in June this year.

EasierSelfies is live

My new iOS app has been approved by Apple and is live in the App Store. It’s EasierSelfies. Thanks to this app you can take selfies much easier and quicker than with the default iOS camera. I noticed while travelling with a friend that it’s hard to take a selfie with an iPhone because of its camera button’s position and I decided to create an app with a movable take photo button.

Code reviews – how to approach them

We do it (almost) every day, we review someone else’s code and our code is being reviewed by our colleagues. It might be a bit tricky for junior developers to get used to it at the beginning though. Let’s write down some useful tips about code reviews.

  1. We do it to improve a codebase.

    A main purpose of a code review is to get a feedback on your code from a colleague from the team. The is no developer who writes perfect code, we all sometimes miss something, forget to test some edge case or commit some unneeded code. This is why code review is helpful – you get someone else looking at the same code, someone who approaches code in a bit different way, who tests different cases, someone who didn’t spend on your branch 4 last days and looks at it with a fresh mind.

  2. Try to teach, not blame.

    Blaming someone because of not perfect (in your opinion) code doesn’t help anyone. It destroys that code author’s day, it destroys your day too. Try to phrase your comments in a way you would like to get feedback too, the way it can be useful, full of knowledge. I think it often sounds nicer when you use plural form rather than a singular one while requesting some changes: for example “Can we move it to a class level?” rather than “Can you move it to a class level?”. It shows that the author of the code is not left alone, that you are trying to improve this code with them.

  3. Link documentation pages, blog posts.

    Different developers have different opinions how particular code could be improved, changed. There are many cases when it’s just subjective, there are a few different opinions and none of them is the only “right” one. On the other hand, there are certain well known patterns, that experienced developers just use automatically. Less experienced developers might not know about them. While trying to suggest such options try to give a link to documentation page, blog post or similar. It may have one nice side effect – author of the code may save this link in their notes, keep it for the future and learn quicker.

I think I will conclude the post at this point. Feel free to add your own tips in comments. Happy code-reviewing πŸ™‚

My new app – DMProjects

I published a new iOS app called DMProjects a few weeks ago. It lets you organise any event / project you can imagine. Simply create a Board, add Tasks and keep track of them.

You can find it on the App Store: https://apps.apple.com/us/app/dmprojects/id1458999518.

I’m planning to release an Android version of this app in the nearest future as well πŸ™‚

Postcardful is live!

I just published my second iOS game – its name is Postcardful πŸ™‚

In Postcardful you are a traveler. You need to collect as many postcards as possible before you lose all 5 lives. Be careful, the planes aren’t your friends, better to avoid them. You can compete with your friends as well. Just keep an eye on a leaderboard.

You can download the game from the App Store using the following link: https://itunes.apple.com/gb/app/postcardful/id1439739100.