Establishing a reliable continuous delivery and deployment process is often very important as it might greatly reduce the length of time needed for the validation and verification of the software product. This is also true for Android projects, especially the ones aimed at short time to market.
Do you think a web dashboard which communicates directly with Amazon Redshift and shows tables, charts, numbers - statistics in general,can work well? We believe it can, as long as the dashboard is used by a few users. As this was our case, we have decided to give it a go.
Let us assume we work diligently. But does it also mean we work effectively and efficiently? Do we spend eight, seven or (at least) six or five hours a day working conscientiously on our projects? And if someone asked whether we come into work with the intention to do our job best, would our answer be always YES?
Is there always a good moment to code? Have you ever asked yourself this kind of question? Have you ever felt that maybe you should take a break instead of writing a code, but you choose to code?
It was pleasure for us to take part in Summer Course “DisAPPear in Gdańsk”. Many thanks to Board of European Students of Technology for inviting us. We could share our knowledge with incredibly clever minds who came to Poland from different European countries. Hopefully, we managed to reveal some secrets about mobile app development to them.
I’ve been an iOS developer for some time now and most of my previous posts were touching the aspects of iOS platform. However, I have to admit something… I’ve been having an affair with React-Native and what is even “worse” — I feel really good about it.
Today you can find Bright Inventions at Trójmiejskie Targi Pracy and this marks a significant milestone for us. We are now getting really serious about growing our team here and inviting next bright developers to join us. I would like to use this occasion to share a few words with you, our potential next great hire.
When you meet Redux for the first time, it often seems a bit overwhelming at first. However, if you want to work with redux effectively, you have to understand how it works, and what are its core elements. State… Actions… Reducers… Store… In today’s post I’d like to introduce you to Redux in not so techy way, so that you grasp the idea of how it works.
It is pretty well known what a backward compatibility means for our APIs - once something was deployed to production and used by the users, we may not change its behavior or break its contracts. It’s far less obvious what a forward compatibility is, even though it is equally important for our APIs longevity and maintainability.
LUKE: Master, moving stones around is one thing. This is totally different! YODA: (irritated) No! No different! Only different in your mind. You must unlearn what you have learned. LUKE: (focusing, quietly) All right, I’ll give it a try. YODA: No! Try not. Do or do not! There is no try. How many times in your life of a professional developer have you tried to do something despite the fact that you knew that you would not succeed? How many times have you tried to finish a project earlier just because your manager asked you to, but from the beginning you knew you would not meet a new deadline? How many times have you promised to add hundred of new features to your demo in two weeks although it would normally take two months? We do it. Let us face it. We do it all the time - we promise things that we cannot achieve. We promise to do something even though it is beyond our capacity. And all this happens because we told someone that we would give it a try. Yet trying is not always enou...