Java conference with English roots. Continuing mega review
We with mpryakhin , my colleague from CleverDATA, managed to go to the British capital for a Java conference - Jax London 2017. Last week you read about Chaos Engineering, lambda expressions, catastrophic bugs and Continuous Delivery Java applications in containers .
And here, in the second part of the review, you will find a story about how to build a career according to your own plan, and not how you have to; how to use metrics to optimize the work on the new functionality. You will also learn about the intricacies of building highly loaded event processing systems and find useful links for working with Ethereum smart contracts using the Java API.
')
At many technical conferences, it is customary to open the day with a report that does not cover the technical side of our professional life, but helps to comprehend those things that escape from attention in the daily routine.
Many consider these reports uninteresting or irrelevant topics of the conference, but, in my opinion, they are among the most valuable, as they allow everyone to change the focus, to think about what has been going on in language for a long time, but it has not been realized. New thoughts, ideas and approaches are in fact exactly what many are going to foreign conferences for.
This report covers one of the most important aspects of our professional life - building a career path. How to approach this question, what actions to perform? As a rule, most of the councils in this area are rather vague and it is sometimes difficult to imagine how you can apply them in your life.
I am sure that there are a lot of books, manuals, methodologies, reports and other materials on this topic, with part of which many of us have already been acquainted, but this report was somehow especially remembered and deposited in my mind.
The author proposes to look at your professional career as if it were a staircase in which each of the steps is our current or former work. The construction of a career is directly related to the way this ladder looks, and the reasons why new steps appear on it.
A source
A large company can offer an employee a lot of career building options, interest him with millions of different KPIs. But it happens that an employee, moving up the career ladder by several positions, is disappointed. Because he built his career in accordance with the KPI, which was the goal of the company, and not with his own plans. And then he will have to go down a couple of steps down.
Hence the conclusion: periodically it is worth slowing down and evaluating our activity from the point of view of our long-term goals, to understand how our current actions help us in achieving our goals and whether the goals require adjustments based on the experience we gained as they are achieved.
The choice of the next job is influenced by many aspects: the success of the company, social bonuses, the size of the team and its average age. All this is very important, but it is not always a guarantee that we will get some development in this company.
It is worth considering the strategic moments: the company's position on the market (both local and international), its goals and ambitions, the business domain in which the company operates, and the most important aspect is a team of specialists, of which you will become a part.
Unfortunately, many technical specialists make their choice towards a particular place of work only on the basis of short-term improvements in their social position, which the company will bring to them, but remain completely or partially ignorant of its global goals and are not acquainted with the team.
Often, the choice is made with the help of a team of recruiters, whose main task is to close the vacancy, and not to deal with your development. The help of recruiters is undoubtedly necessary, but the initiative must first come from us - based on our interest in a specific business domain and the desire to work with the best people in order to develop in accordance with long-term goals.
Sandro Mancuso's other reflections are in the video of his report .
When developing software, we sometimes become so interested in the idea that everything else ceases to exist for us. The idea is seen as a burning torch, we pull hands to it. It seems that success is already very close, but suddenly the earth leaves from under our feet, the burning torch turns out to be an inaccessible star, and we are left alone with our product and the question “What went wrong?”
Oh well. In life, everything is not so pretentious. But how many times it happened that when solving a new, long-awaited, complex and interesting task, we retreat into ourselves and only after a couple of hours (days, and you won’t believe it, I saw that even weeks all depend on the size of your organization and your guilt ) Scrum-master reminds that it is time to explain what exactly you are doing and when to expect a result.
At this stage, we understand that there is no time for reflection, and great goals and thoughts are postponed until the next time, we begin to work hard.
Such cases are not uncommon in teams and companies of any level and profile. It does not always depend on the experience or professionalism of the technical specialists working for them. It is often the reason for the lack of understanding of the place where you are now, the way to go, and the final goal, which may not be so obvious if you look at it more closely.
So, part of the time that we devote ourselves to the task, we spend not quite as expected initially, but it is not always clear where exactly it goes. And when we do not understand something well, the easiest way is to start collecting some information about our activities. Here metrics help us. More information about all this, we were told by the specialists of the company Electric Cloud.
This figure shows a scientific approach to working with one or another observation. I am sure that he is familiar to many and is actively used constantly, because in fact there is nothing innovative in it. This is only a sequence of logical actions that are guaranteed to lead us to an understanding of what we observe.
The focus here is to give a sequence of operations and not to try to skip some steps, because each of them helps us to better understand the issues and more consciously go to the final goal.
But back to the metrics, or rather their types:
Most of us will face the optimization of the development / testing process and the introduction of new functionality, and here we will come to the aid of the types of metrics from the first group.
As a rule, any process of developing a new feature can be reduced to the next set of development stages (pipeline).
Picture is clickable:
So, we have five stages of the development of a model project:
In case your process has not yet been split into similar parts, perhaps this will be the first step towards more conscious control over the development and implementation time of the feature.
After the process is divided into separate pieces, we can measure the time of each of them and find out which steps it takes us the most time. Further, having a certain set of observations and the diagram above, we can make a number of improvements and use the pipeline to assess the quality of the impact of our changes on the entire development process.
Thus, we get the opportunity to iteratively adjust the process of developing and delivering new features, like a sports car engine, under optimal working conditions. In the future, this will help us win the race for the best product.
Do not forget that the implementation of each feature pursues the specific goals of your company. The following can serve as metrics for these goals.
The product must meet the goals of your customers / users. Here the metrics are as follows.
We use part of the described approaches when developing our product (1DMP). The most pleasant thing is that, having a part of these metrics on hand, we can quantitatively and qualitatively evaluate certain changes that we make in the process of developing / implementing and maintaining our product. This allows us to fine-tune the process with each iteration and move faster to the goal.
More details on this topic can be found in the video speakers .
The last report of this day promised to tell us about the subtleties, nuances and approaches used in the construction of high-loaded event processing systems. Description of the report was full of many terms: relatively recent (reactive design patterns, actor model), and more fundamental, used by many, but no less interesting (DDD, CQRS, Event Sourcing).
In many articles, the use of one approach or another in the context of various tasks provokes fierce disputes, which further fuel interest in these topics.
The report was built on the principle “from simple to complex” and the main goal was to understand all these terms and understand what should be used in what situations and what should not be used.
Everyone knows the problem of scaling a typical information system with increasing load. As a rule, the bottleneck is the database server, which does not scale well with intensive recording.
One of the common solutions to the problem of slow writing to the storage is to add an intermediate buffer between the service and the final storage. Thus, we can continue to scale our application horizontally and to a lesser extent depend on the speed of adding data to the repository.
This solution has one big disadvantage. As soon as we added the intermediate buffer, we lost the guarantee that two operations performed from the client’s point of view consistently reach our database in the same sequence, i.e. system consistency may be compromised.
So, we have some source of events, the sequence of which matters. We want to continue to scale horizontally, but the consistency of the data and the transactionality of their changes are important for us. DDD (Domain-Driven Design) to help us.
The basic idea of ​​this principle is to create a business domain, within which you can guarantee the consistency of data. In the simplest form, this can be information about the user and the status of his account. Further, each input request always passes through only one process (aggregator) that serves the data of this user only.
If the action requested by the user is feasible from the point of view of the business logic of our domain model, the process changes its state and generates an event that characterizes the change made, which is recorded in the transaction log.
Thus, if something happens to the process, its state can always be restored from this log. By the way, the model of actors is just very relevant when designing systems of this type.
So, the incoming request has been processed, an event has been generated on the basis of it and recorded in the transaction log. But what if you want to present the results of incoming events in some new form, different from the state of the process? (For example, for building statements.)
The CQRS approach (command-query responsibility segregation) comes to the rescue, from the name of which it is clear that the writing and reading processes are separated in different angles. Since the system has a complete log of events born during the impact of users on it, it will not be difficult to re-read this log in any form optimized for the reading task.
But do not forget that the system is distributed between different instances of the application, which may be located on different servers. This adds the overhead of routing a request to the desired application instance, where a process is available that processes requests to this domain object. In turn, this leads to increased sensitivity of the system to repartitioning.
It is necessary to make a reservation that the use of this approach is justified only if their order of receipt is important for processing requests, and the source of requests ensures their consistency. A good example of requests, the order of which is important, is the withdrawal / replenishment of bank account funds.
In some cases, the source of requests cannot guarantee the sequence and order of requests, for example, IoT sensors of devices and signals that they send. Part of the time, these devices can be offline or in power saving mode (they buffer information in themselves and periodically send it to the server).
Also a good example would be various mobile games that provide their basic functionality if the device is offline. When it appears, they send statistics about the player to the server for subsequent accounting in game mechanics. In this case, the processing of the incoming request is reduced to its basic validation and recording in a large analytical repository for further analytics. This allows you to get rid of state storage in the service and scale the request processing service in a standard way horizontally. This approach is known as Weak Write onsistency.
Further, the received events are analyzed by various tasks, which build these events in the necessary sequence and on the basis of this make certain decisions.
More details on this topic can be found in the video report .
So, the third day of the conference passed completely unnoticed by us. The main part of the reports left behind. The head was full of thoughts, and the issued notebooks were written with notes. We spent the rest of the evening in one of London's pubs over a glass of good ale and a piece of delicious steak.
In the course of the seminar, Conor spoke about the main milestones in the development of blockchain technologies. The report turned out to be quite detailed, and it was interesting to learn that one of the trends in the blockchain world, which many corporations are already working on, is the construction of a distributed private blockchain. In addition, some of the technological solutions have already taken shape in the library and framework, and gathered under the umbrella of the Hyperledger Foundation, formed with the participation of the Linux Foundation in 2015.
During the seminar, we learned about the basic principles of blockchain operation on the example of the Etherium network. The code base of the seminar was based on the open library web3j , which is a bridge between smart contracts written in Solidity and the Java machine.
Workshop participants completed the following tasks:
Since all materials of the seminar are publicly available on github , everyone can just as well go through this seminar and understand all the nuances of Ethereum smart contracts using Java API.
In public access there was a video with content similar to the seminar.
We still remember this trip with mpryakhin with great pleasure. When preparing the review, we reviewed materials and reports more than once and never ceased to be surprised: each time we paid attention to something new that we did not notice while sitting in the audience. A trip to the conference, especially for such a long, always a great event in the life of the developer. We hope that our review will be useful to you. Conference slides are available here .
And here, in the second part of the review, you will find a story about how to build a career according to your own plan, and not how you have to; how to use metrics to optimize the work on the new functionality. You will also learn about the intricacies of building highly loaded event processing systems and find useful links for working with Ethereum smart contracts using the Java API.
')
Third day. Professional growth in the right direction and control of the development process using metrics
At many technical conferences, it is customary to open the day with a report that does not cover the technical side of our professional life, but helps to comprehend those things that escape from attention in the daily routine.
Many consider these reports uninteresting or irrelevant topics of the conference, but, in my opinion, they are among the most valuable, as they allow everyone to change the focus, to think about what has been going on in language for a long time, but it has not been realized. New thoughts, ideas and approaches are in fact exactly what many are going to foreign conferences for.
"The Long Road" by Sandro Mancuso
This report covers one of the most important aspects of our professional life - building a career path. How to approach this question, what actions to perform? As a rule, most of the councils in this area are rather vague and it is sometimes difficult to imagine how you can apply them in your life.
I am sure that there are a lot of books, manuals, methodologies, reports and other materials on this topic, with part of which many of us have already been acquainted, but this report was somehow especially remembered and deposited in my mind.
The author proposes to look at your professional career as if it were a staircase in which each of the steps is our current or former work. The construction of a career is directly related to the way this ladder looks, and the reasons why new steps appear on it.
A source
A large company can offer an employee a lot of career building options, interest him with millions of different KPIs. But it happens that an employee, moving up the career ladder by several positions, is disappointed. Because he built his career in accordance with the KPI, which was the goal of the company, and not with his own plans. And then he will have to go down a couple of steps down.
Hence the conclusion: periodically it is worth slowing down and evaluating our activity from the point of view of our long-term goals, to understand how our current actions help us in achieving our goals and whether the goals require adjustments based on the experience we gained as they are achieved.
The choice of the next job is influenced by many aspects: the success of the company, social bonuses, the size of the team and its average age. All this is very important, but it is not always a guarantee that we will get some development in this company.
It is worth considering the strategic moments: the company's position on the market (both local and international), its goals and ambitions, the business domain in which the company operates, and the most important aspect is a team of specialists, of which you will become a part.
Unfortunately, many technical specialists make their choice towards a particular place of work only on the basis of short-term improvements in their social position, which the company will bring to them, but remain completely or partially ignorant of its global goals and are not acquainted with the team.
Often, the choice is made with the help of a team of recruiters, whose main task is to close the vacancy, and not to deal with your development. The help of recruiters is undoubtedly necessary, but the initiative must first come from us - based on our interest in a specific business domain and the desire to work with the best people in order to develop in accordance with long-term goals.
Sandro Mancuso's other reflections are in the video of his report .
Measuring the DevOps: The Key Metrics for the Matter by Anders Wallgren
When developing software, we sometimes become so interested in the idea that everything else ceases to exist for us. The idea is seen as a burning torch, we pull hands to it. It seems that success is already very close, but suddenly the earth leaves from under our feet, the burning torch turns out to be an inaccessible star, and we are left alone with our product and the question “What went wrong?”
Oh well. In life, everything is not so pretentious. But how many times it happened that when solving a new, long-awaited, complex and interesting task, we retreat into ourselves and only after a couple of hours (days, and you won’t believe it, I saw that even weeks all depend on the size of your organization and your guilt ) Scrum-master reminds that it is time to explain what exactly you are doing and when to expect a result.
At this stage, we understand that there is no time for reflection, and great goals and thoughts are postponed until the next time, we begin to work hard.
Such cases are not uncommon in teams and companies of any level and profile. It does not always depend on the experience or professionalism of the technical specialists working for them. It is often the reason for the lack of understanding of the place where you are now, the way to go, and the final goal, which may not be so obvious if you look at it more closely.
So, part of the time that we devote ourselves to the task, we spend not quite as expected initially, but it is not always clear where exactly it goes. And when we do not understand something well, the easiest way is to start collecting some information about our activities. Here metrics help us. More information about all this, we were told by the specialists of the company Electric Cloud.
This figure shows a scientific approach to working with one or another observation. I am sure that he is familiar to many and is actively used constantly, because in fact there is nothing innovative in it. This is only a sequence of logical actions that are guaranteed to lead us to an understanding of what we observe.
The focus here is to give a sequence of operations and not to try to skip some steps, because each of them helps us to better understand the issues and more consciously go to the final goal.
But back to the metrics, or rather their types:
- the effectiveness of the process of developing and implementing features;
- the impact of features on customer satisfaction;
- the impact of features on the product and our business;
- employee satisfaction.
Most of us will face the optimization of the development / testing process and the introduction of new functionality, and here we will come to the aid of the types of metrics from the first group.
As a rule, any process of developing a new feature can be reduced to the next set of development stages (pipeline).
Picture is clickable:
So, we have five stages of the development of a model project:
- development;
- testing;
- deployment;
- implementation;
- escort.
In case your process has not yet been split into similar parts, perhaps this will be the first step towards more conscious control over the development and implementation time of the feature.
After the process is divided into separate pieces, we can measure the time of each of them and find out which steps it takes us the most time. Further, having a certain set of observations and the diagram above, we can make a number of improvements and use the pipeline to assess the quality of the impact of our changes on the entire development process.
Thus, we get the opportunity to iteratively adjust the process of developing and delivering new features, like a sports car engine, under optimal working conditions. In the future, this will help us win the race for the best product.
Do not forget that the implementation of each feature pursues the specific goals of your company. The following can serve as metrics for these goals.
- The cost of attracting a new client. If new features are relevant for the market, environment, they are updated in a timely manner and the number of bugs is quite small, then the degree of loyalty of your customers increases, your popularity grows in the market and, as a result, the cost of attracting a new client decreases.
- Profit. Everything is quite simple here: an increase in the number of clients, a decrease in the costs of maintenance.
- Market share. It is always useful to soberly assess the environment.
The product must meet the goals of your customers / users. Here the metrics are as follows.
- Product Satisfaction. Continuous collection of feedback allows you to identify many nuances that can affect both the development process and the alignment of the process of communication with customers.
- The benefits of features. Our ideas, unfortunately, do not always coincide with the needs of the business domain for which we design our solution, and the value of the product lies not only in its quality, but also in the ability to dynamically adjust and hear the needs of the market. Therefore, if some of the features do not bring the expected benefits, this is a good marker for their revision.
- Usability features. Often the user can not appreciate our idea, because it is something new, something that nobody has done before us, and the business has never seen it anywhere. Often, people are quite conservative and skeptical about everything new, but if we collect information on usability, we can conduct timely seminars on such functionality, and thus help our clients' businesses achieve the best results through the use of new functionality.
There is a rule in Google: if the impact of changes cannot be assessed in terms of business value, such changes are impractical. Because of this, everything around is covered with metrics.
We use part of the described approaches when developing our product (1DMP). The most pleasant thing is that, having a part of these metrics on hand, we can quantitatively and qualitatively evaluate certain changes that we make in the process of developing / implementing and maintaining our product. This allows us to fine-tune the process with each iteration and move faster to the goal.
More details on this topic can be found in the video speakers .
"Scaling Event Sourcing for the IoT and mobile" by Lorenzo Nicora
The last report of this day promised to tell us about the subtleties, nuances and approaches used in the construction of high-loaded event processing systems. Description of the report was full of many terms: relatively recent (reactive design patterns, actor model), and more fundamental, used by many, but no less interesting (DDD, CQRS, Event Sourcing).
In many articles, the use of one approach or another in the context of various tasks provokes fierce disputes, which further fuel interest in these topics.
The report was built on the principle “from simple to complex” and the main goal was to understand all these terms and understand what should be used in what situations and what should not be used.
Everyone knows the problem of scaling a typical information system with increasing load. As a rule, the bottleneck is the database server, which does not scale well with intensive recording.
One of the common solutions to the problem of slow writing to the storage is to add an intermediate buffer between the service and the final storage. Thus, we can continue to scale our application horizontally and to a lesser extent depend on the speed of adding data to the repository.
This solution has one big disadvantage. As soon as we added the intermediate buffer, we lost the guarantee that two operations performed from the client’s point of view consistently reach our database in the same sequence, i.e. system consistency may be compromised.
So, we have some source of events, the sequence of which matters. We want to continue to scale horizontally, but the consistency of the data and the transactionality of their changes are important for us. DDD (Domain-Driven Design) to help us.
The basic idea of ​​this principle is to create a business domain, within which you can guarantee the consistency of data. In the simplest form, this can be information about the user and the status of his account. Further, each input request always passes through only one process (aggregator) that serves the data of this user only.
If the action requested by the user is feasible from the point of view of the business logic of our domain model, the process changes its state and generates an event that characterizes the change made, which is recorded in the transaction log.
Thus, if something happens to the process, its state can always be restored from this log. By the way, the model of actors is just very relevant when designing systems of this type.
So, the incoming request has been processed, an event has been generated on the basis of it and recorded in the transaction log. But what if you want to present the results of incoming events in some new form, different from the state of the process? (For example, for building statements.)
The CQRS approach (command-query responsibility segregation) comes to the rescue, from the name of which it is clear that the writing and reading processes are separated in different angles. Since the system has a complete log of events born during the impact of users on it, it will not be difficult to re-read this log in any form optimized for the reading task.
But do not forget that the system is distributed between different instances of the application, which may be located on different servers. This adds the overhead of routing a request to the desired application instance, where a process is available that processes requests to this domain object. In turn, this leads to increased sensitivity of the system to repartitioning.
It is necessary to make a reservation that the use of this approach is justified only if their order of receipt is important for processing requests, and the source of requests ensures their consistency. A good example of requests, the order of which is important, is the withdrawal / replenishment of bank account funds.
In some cases, the source of requests cannot guarantee the sequence and order of requests, for example, IoT sensors of devices and signals that they send. Part of the time, these devices can be offline or in power saving mode (they buffer information in themselves and periodically send it to the server).
Also a good example would be various mobile games that provide their basic functionality if the device is offline. When it appears, they send statistics about the player to the server for subsequent accounting in game mechanics. In this case, the processing of the incoming request is reduced to its basic validation and recording in a large analytical repository for further analytics. This allows you to get rid of state storage in the service and scale the request processing service in a standard way horizontally. This approach is known as Weak Write onsistency.
Further, the received events are analyzed by various tasks, which build these events in the necessary sequence and on the basis of this make certain decisions.
More details on this topic can be found in the video report .
So, the third day of the conference passed completely unnoticed by us. The main part of the reports left behind. The head was full of thoughts, and the issued notebooks were written with notes. We spent the rest of the evening in one of London's pubs over a glass of good ale and a piece of delicious steak.
Advice to those who flew to London not only for the sake of the conference
The conference program turned out to be intense, and we did not want to miss anything interesting, so only evening time remained for exploring the city. A walk in the evening or at night in London leaves the most vivid impressions.
After ten in the evening, the streets are slowly becoming empty, lanterns come on, filling everything around with a warm yellow light, and in the windows of houses you can see living rooms full of books. All this creates the feeling that you are walking in warm slippers through the pages of the works of Arthur Conan Doyle or Charles Dickens, it tunes you in a special way.
Only, please, if you walk in October, do not forget to put on a windbreaker and grab an umbrella. One evening, when we left the hotel, the sky was full of stars and the moon shone brightly, and closer to the middle of our walk a light rain began. This did not spoil our excursion, but under the umbrella it would be more pleasant.
We walked past Madame Tussauds, along the famous Notting Hill, saw real English parks, and came to the conclusion that we should definitely come here in the future to have more time to get acquainted with the cultural heritage of England in the daytime.
After ten in the evening, the streets are slowly becoming empty, lanterns come on, filling everything around with a warm yellow light, and in the windows of houses you can see living rooms full of books. All this creates the feeling that you are walking in warm slippers through the pages of the works of Arthur Conan Doyle or Charles Dickens, it tunes you in a special way.
Only, please, if you walk in October, do not forget to put on a windbreaker and grab an umbrella. One evening, when we left the hotel, the sky was full of stars and the moon shone brightly, and closer to the middle of our walk a light rain began. This did not spoil our excursion, but under the umbrella it would be more pleasant.
We walked past Madame Tussauds, along the famous Notting Hill, saw real English parks, and came to the conclusion that we should definitely come here in the future to have more time to get acquainted with the cultural heritage of England in the daytime.
Day four. Blockchain using java
"Developing Java Applications on the Blockchain with web3j" by Conor Swensson
In the course of the seminar, Conor spoke about the main milestones in the development of blockchain technologies. The report turned out to be quite detailed, and it was interesting to learn that one of the trends in the blockchain world, which many corporations are already working on, is the construction of a distributed private blockchain. In addition, some of the technological solutions have already taken shape in the library and framework, and gathered under the umbrella of the Hyperledger Foundation, formed with the participation of the Linux Foundation in 2015.
During the seminar, we learned about the basic principles of blockchain operation on the example of the Etherium network. The code base of the seminar was based on the open library web3j , which is a bridge between smart contracts written in Solidity and the Java machine.
Workshop participants completed the following tasks:
- got yourself a test wallet;
- connected to the test network;
- wrote the simplest smart contract and published it in Ethereum Blockchain;
- wrote a small service that interacts with a published smart contract.
Since all materials of the seminar are publicly available on github , everyone can just as well go through this seminar and understand all the nuances of Ethereum smart contracts using Java API.
In public access there was a video with content similar to the seminar.
Finally
We still remember this trip with mpryakhin with great pleasure. When preparing the review, we reviewed materials and reports more than once and never ceased to be surprised: each time we paid attention to something new that we did not notice while sitting in the audience. A trip to the conference, especially for such a long, always a great event in the life of the developer. We hope that our review will be useful to you. Conference slides are available here .
By the way, in LANIT there are open vacancies for Java developers.
Source: https://habr.com/ru/post/346984/
All Articles