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.
Flickr, https://flic.kr/p/oDe4AT, cropped
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.
Our names are Justyna Setlak, Szymon Matwijów and Julian Pszczołowski. We are students who did an internship in Fingo during 2016 summer holidays.
Our task was to create a server whose API one can use to authenticate and authorize users – something like login in with Facebook – and a web app to manage the server comfortably.
We were using .NET Core 1.0.0, .NET Framework 4.6.1 and Jenkins as a continuous integration tool, which was building, testing and publishing the code. It was really a surprise to us that we had to work in ASP.NET Core 1.0.0 instead of an earlier version.
Let’s call it Application X* (the software is real, but I changed the name).
When a few years ago our developers first looked at the existing code of Application X, they were not exactly happy. It wasn’t the cleanest they’ve seen. It was far from the standards they got used to. PHP was polluted with HTML and MySQL queries. The names of variables were not in English, but in the client’s native language. The project tracking solution used by the client’s dev team so far was clunky and the development methodology was in it’s infancy.
These were some of the challenges we faced after we decided to take over the development of Application X. So, what happened?
Laravel supports various cache drivers out of the box. One of them is Redis. I am not going to describe Redis with it’s features and advantages here, it’s not the purpose of this document. The only important point in scope of this document is that Redis supports tags. Feel free to google a bit what is „cache tagging”.
I remember that day – we all had a big laugh.
About 5 years ago, the corporation I worked for announced the “zero e-mail program”. The global policy was meant to do exactly what it said – make our inboxes obsolete. Back then it seemed like a joke. The rumors said we would be using a hybrid of Facebook and Skype, invented specifically for businesses.
As we kept sorting out the tens of e-mails that were cc’d to us last night without any specific reason, sarcasm filled our rooms. We refused to take the whole idea seriously. It often happens when low-level employees are presented with a bold managerial vision. They are the soldiers on their front-line, and they know that their assault rifles will not be swapped for plasma guns, even when the president says so. Not in their life.