Luxoft Training

News technology websites are constantly inundating us with articles about various security and data breaches leading to the loss of mountains of sensitive information. Today’s programmer not only has to develop good software solutions but he must also make sure that these solutions are as secure as possible to counteract the negative effects of hacking.

When working with tasks, there is often a problem: we have a set of input data and for processing each element we use a long-running operation.

Last time we looked at the idiom that allows you to process results in the order of task completion, not in the order of launching. But we skipped one interesting moment there. Let’s say we all have the same weather service and we want to obtain the results for every city as quickly as possible. Does this mean that we can take all the cities in the world and send thousands of requests at the same time? The forecast service may think that the client has gone mad and may try to throttle the requests that exceed a certain limit (by the way, this throttling is one big pain in the ass for all cloud services, both for the authors of the services and the customers).

In this article, we'll review some strategies for allocating responsibilities in large teams. Most Project Managers, in charge of developing a large application or system, have to coordinate several teams responsible for developing certain modules of the application. Therefore it is important to develop work flows that do no overlap in terms of functionality.

In the first part of our article we talked about the most frequent allocations of responsibilities for project teams. But there are better strategies to improve responsibility.

A couple of years ago I made a short series of notes on the patterns of behavior: Technical Debt, Refactoring Syndrome and The Second-System Effect. The time has come to discuss another subject, probably the most famous and popular pattern of behavior: the Not Invented Here (NIH) syndrome.

Testing as a profession is gaining popularity and becoming more desirable. More and more people are willing to retrain and become IT specialists, because this area is developing and the highly paid work of the tester seems to be the most accessible. Indeed, it is easier to retrain as a tester than, for example, as a programmer. But over the past ten years the "entry threshold" in the profession has grown significantly. Yet it is still feasible to do so without going through many years of training.

Customers often believe that when it comes to enterprise applications, usability does not matter. They will still make their employees use the software, no matter how convenient and easy to understand it is.

Scrum is simple, but not easy. It’s very similar to a poker game with very simple rules, but it is not very easy to play and win. During this one hour webinar we will provide you with an overview of Scrum so that you get a general idea of what it is and its main elements.

Without going into details the majority of project roles are quite clear from the title the person has. The project manager manages the project. The developer develops software. The tester tests it. But when it comes to analysts some questions constantly arise: "What is the difference between a business analyst and a system analyst?" or "Is a system analyst different from a requirements analyst?". Similar questions arise for those who are looking for work associated with analysis in IT and recruiters who pick candidates for these sort of jobs.