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.
In many cases configuring a new server is a repetitive task. Once the operating system is installed, we have to add accounts for administrators, install some basic packages, setup the application and secure everything. Even though there are some differences between servers designed for two different applications, certainly there will be some common things too. Especially in case of the same technology (not to mention exactly the same stack, like Symfony + nginx + MySQL).
For almost two years we’ve used Ansible at FINGO for preparing configuration of servers. This allowed us to spend more time on creative and interesting things, since the repetitive tasks were written once and now we can just include them from some common modules.
It was early Saturday morning when I entered the main lecture room at the Institute of Computer Science at the University of Wroclaw. Some of the 100 young people at the audience were still dozing, some pumping their veins with coffee, others immersed in their laptops. The oldest ones were in their thirties, some of them as young as 16 and 17. They were all about to take part in PIZZA – an annual programming competition hosted by the students of the Institute.
Every developer who has developed any webpage has the same problem: a change of primary color implies changes in many CSS files and careful find/replace operations for all occurrences of specific value.
Some of us are already using CSS pre-compiler libraries (like Less), which allows us using variables on CSS level in our code.
Less can be embedded strictly using client-side pre-compilation, without a need to compute it on application server (like PHP or ASP scripts), which would definitely make it easier to start using Less stylesheets in our project.