As a software house’s client, you should be prepared to go through a process of estimating the cost and time needed for developing an app. While this seems straightforward and most of the estimation work is done by the software house’s team, there are many areas which you should approach with mindfulness. To be successful, within budget, and on time, it is best to work closely with the development company.
Here is a 9-step guide that will help you and your provider work better together.
User Experience (UX) and User Interface (UI) are among the most complicated, misused and misinterpreted terms in software development. In the last few years as an industry, we’ve been focusing on responsive and intuitive designs of interfaces in the contexts far beyond mobile apps. Non-responsive and unintuitive designs have been rightly ditched. That is why good UX is so important. The product must be well-designed if it is to attract users. In addition, to satisfy the user, a friendly and simple look is essential.
The terms UX and UI designs often go hand in hand, and are often confused. So what do they have in common and what are the differences? In both cases the aim is the same – to help the product succeed. But can it be achieved by focusing only on one of the areas?
A few weeks ago my workmate asked me a question: “How does the Spring Framework handle a self-invocation on a creation of beans?” He was thinking about a situation like this one:
Recently I have been working on some code in which I was using ThreadLocal variables. This give me possibility to chew over the ThreadLocal variables concept again. The basic idea of this approach is quite simple. Every thread has its own copy of a ThreadLocalMap. When you ask for the value of the ThreadLocal variable it will search for this value in the ThreadLocalMap variable instance of the current thread.
The larger a project, the harder it is to test the code, and with most of the tests being functional – we have to face the problem: we finalize the task, the user story, or close the entire sprint and we have to wait for the tests for hours. This process can be vastly accelerated, even in legacy applications from the era of the PHP 4.
Above all, it is worth introducing unit tests into the new code – extract dependencies outside the code and test what is actually being developed. The tests are supposed to check our logical code, not the library or ORM. The introduction of unit tests is, however, a long-term step that does not give immediate results, which is why I’d like to show you what can be done on top of that.
Firstly, it must be said that one could write a book about the subject and still barely scratch the surface, so I’ll keep this article very brief and only touch upon the practical aspects based on my own experience – assuming a more difficult scenario, when the project has a lot of tests using the MySQL database.
Individual investor diagnosing, profiling and training in banks has been traditionally done through interviews or pen-and-paper questionnaires. Hypothekarbank Lenzburg AG has decided to take a leap into algorithmic gamification to better understand their customers and prepare truly tailored offers for them.
The “why” part
I am sure that if you’ve not been using docker so far, you’ve heard about docker and most probably you’ve read about it. It’s been a very popular topic for at least few years now. So I assume you have at least some knowledge about it.
I don’t want to describe the architecture of docker. There have been thousands of articles, webinars and screen casts about it.
We’ve recently had a spike in our sprint to check out blockchain technology. The goal was to assess it and check potential use in our FinTech scenarios rather than implement anything. We obviously started with bitcoin – blockchain’s No 1 implementation.
There are many resources on the Web explaining how it works (starting with their WIKI). It requires some time to understand it but it’s not a rocket science. One of our younger team members managed to go through it without problems and effectively explained it to the rest of the team.
Can it get more exciting than that?
This autumn we teamed up with our new client, the London-based Munich Re Digital Partners (MRDP), to work on a sophisticated API that is revolutionizing on-demand insurance.
MRDP is a business venture that aims to change the way insurance is offered on PCs and mobile devices. While there are many InsurTech start-ups offering new ways to bring insurers and customers together, they often focus on the frontend and UX. MRDP offers them the back-end technology and helps them develop their disruptive products more effectively. The project we work on will also be a vehicle for AI-based capabilities.
FINGO was chosen as the nearshoring partner for the project because of our expertise in building large APIs with global exposure and heavy traffic loads. Currently our shared London/Wrocław team consists of 5 developers and 2 DevOps engineers and is set to grow in the beginning of January 2016.
At FINGO we promote a culture of maturity and lasting relationships. This helps us build better software and deliver value for our clients in the long run.