07 May 2015
In today's world of rapid changes, only those companies that become aware of such changes in a timely manner, and react to them, have a chance to succeed. Constant learning has become a part of our everyday life. In order to expand their horizons and gain new knowledge, our colleagues spent two days in Budapest, attending the Craft Conference on April 23rd and 24th. Below is a brief description and links to the lectures that left an impression on them.
In cases of large projects it is getting more and more difficult to maintain a well-known structure "presentation (UI) - business (application) - data (DAL)" so there has been a quest in order to facilitate such maintenance. One of the possible approaches to solving this problem appeared in the form of so-called "micro-services". Instead of horizontal partitioning of the project (presentation/business/data), vertical partitioning of the project is performed by decomposition of the project into smaller self-functional parts which leads to the concept of micro-services, which may or may not contain horizontal division. It should be noted that these micro-services are independent of each other, that they perform sufficiently small (basic) functions and that they can be concantenated (as console commands connected by pipe). This concantenation provides freedom of combining micro-services in many ways, thus enabling the performance of a more complex work, and at the same time it may provide flexibility to the system to adapt rapidly to market changes through simple reordering of micro-service concantenation.
Dan North and Jessica Kerr - Complexity is Outside the Code - video
When writing tests ceases to be simple, it is usually an indicator that something within the project is not right. The reasons for this may be wrong project structure, illegible/complex code, poor design etc. Writing (and performance) of tests is one way of detecting defects in the design or implementation of the project. Via application of knowledge (mindset) gained from the world of functional programming, identifying such errors often becomes trivial, since the same problems are observed from a new (additional) point of view, so the defects can be found more easily under this new light.
Alvaro Videla - Writing testable code (a functional programming point of view) - video
In order to increase productivity and final product quality, companies throughout the world are trying to develop a specific culture (way of thinking and behavior of employees) within the company, with the aim to provide optimal working conditions to their employees. There are numerous ways in which that aim is achieved by those companies, and some of the most interesting ones were mentioned in the course of this lecture.
Sven Peters - Coding Culture - video
One of the most interesting lectures, at which it was discussed about how the Agile approach is applied today, in comparison to just 10 years ago, when it was created. Apart from the main problems in the form of incomprehension of the essence of Agile approach within project development by the management, proper applications were also discussed, as well as some of the alterations in the Agile Manifesto document.
The most interesting part of this lecture was the one with an attempt to explain how software engineering, at the time of its conception, was mistakenly compared to construction engineering, since it was intuitively logical that these two fields represent an analogy. For many years, people have been implementing such assumptions and developing their own projects, without much critical reflection on this "analogy". With an increase of complexity of software projects, certain problems that do not exist in construction engineering have arisen, which has led to the idea that perhaps software engineering may be more comparable to something else. By comparison to surgery, many more similarities have been discovered, quite unexpectedly, and that very moment marked this lecture as one of the most interesting.
Dan North - Beyond Features: Rethinking Agile Planning and Tracking - video
With the increasing complexity of today's applications, it is no longer enough just to buy more powerful hardware (since the price of the latest and most powerful hardware increases exponentially), but it is necessary to commence the breakdown of the application into several smaller independent services that can be run individually on weaker hardware. This provides a possibility of horizontal scaling of the application, i.e. the possibility of using a larger number of weaker hardware on which individual services are performed, whereas the entire collection of such hardware functions as the original monolithic application. In this way, the price of application performance is reduced drastically, and the maintenance of the application becomes easier due to the modularization of the application.
Randy Shoup - From the Monolith to Microservices: Lessons from Google and eBay - video
The majority of today's large-scale applications have a standard structure dominated by "horizontal 3-tier architecture". However, such application structure may correspond to the existing ways of thinking, but in some trivial cases it has been giving quite poor results, such as the arrival of new members in the development team. At that time, even the simplest questions such as "What is this application about?", "What is this application supposed to do?" or "Which is the fastest way of locating the part of the code that I should change?" become quite difficult to be answered in a simple manner. In this lecture, Sandro Mancuso showed one of his projects in which he tried to combine Domain-driven design, MVC and CQRS in order to achieve better application structuring, which would result in a consequence that the answers to all of the said questions become apparent and clear at the very beginning, even to the new team members.
Sandro Mancuso - Interaction Driven Design - video
Today's systems for versioning source code are usually used only for storing source code backup during the development of an application. However, various interesting data which often point to the hidden problems or deficiencies within the application can be found through simple analysis of the history of source code changes. During this lecture, some of the easily generated statistical information was shown, which as a result may provide very precise guidelines on what should be done in order to improve the quality of the application.
Michael Feathers - The Hidden Dimension Of Refactoring - video
Once the decision is made with regard to writing an API for a system, the most common mistakes are found in such decisions whose making did not include a sufficient amount of willingness/time/money to hold them sustainable for a longer period of time. This means that the decisions are usually made rapidly and in accordance with the needs of the market, but the consequences of such decisions are not observed for a longer period of time, which usually causes the deprecation of such API and the commencement of writing of a new version of the same API, with an inevitable loss of a certain part of clients, who are simply unwilling to make such dramatic changes in their code. Certain ways of proper performance of things at the very beginning, and that bring advantages and ease of maintenance for a longer period of time, were also explained in this lecture. It is interesting that the answer of the lecturer to the question "Today, is there any public API that is completely RESTful" was that so far he had seen only 2 (Google Buzz and Google Data) and that both of them were outdated, which indicates an insufficiency in testing of the software engineering field, which many people take for granted.
Adewale Oshineye - Why Is An API Like a Puppy? -
During the development of an application, it often occurs that the designed architecture of such application slowly goes into the background, while numerous classes enter into the foreground (in the form of structured packets), and whose number often grows so quickly that, at one point, the entire structure of the application cannot be kept in mind any longer. The matter is further complicated by the popular Agile approach to developing applications that most IT companies are trying to adopt, because they've heard that it's something modern and good, which basically brings frequent additional changes in the application (as a response to market demands). All of this causes changes over time in the originally designed architecture of the application, and the problem increases if the diagram of such architecture is not maintained regularly and the current source code of the architecture is not followed. One of the possible solutions is structuring applications in a way that facilitates the job of writing a new tool, which could automatically generate application architecture, solely on the basis of its source code.
Simon Brown - Software Architecture as Code - video
Of course, these are just some of the useful lectures that have left an impression on our colleagues. We shall try to implement the above ideas in our company, and through organizing various knowledge sharing events, we shall attempt to share the experience with the community. It was our greatest pleasure to be a part of this conference and we are looking forward to the next year.