We are not living in the Stone Age any more, we are social human beings and we should be also social engineers. It was long time ago when a project was a one-man show, so we have to learn to collaborate, we have to learn how to work in mixed-skills teams and how to share ideas and solutions in order to have a successful life as code writers. According to Tudor Girba1, as developers we spend about half of our working time reading code. Why reading code? Because the current code bases are growing every day, and with each task we have to implement,we will end up reading code more than actually writing it.

SAP Solution Manager is an application lifecycle management (ALM) platform provided by SAP, which helps you implement, maintain, run, and adopt all enterprise applications - even non-SAP software - while supporting business innovation, business continuity, and operations.

One of the first decisions most projects face, regardless of the development landscape or technology, is "Which development methodology should be used? What fits better for our application and landscape?" This topic gets more and more attention and it's currently a subject of debate. There are many articles debating if the developers creativity is not restricted by adopting standard steps to be followed. This comes up as since the chosen methodology determines how the project's development is organized. The two most known methodologies are Waterfall and Agile. Although SAP has ASAP for ERP implementation, in SAP software development Waterfall and Agile are both famous. The article will draw some ideas around the way of choosing the best fit for the developed software in SAP world.

”Your mind is for having ideas - not for holding them!” In his book, "Getting Things Done", David Allen starts off from a simple premise - we could say that productivity is directly proportional to our ability to relax. When we feel overwhelmed by how much we have to do it’s difficult to focus on ensuring that life and work are moving in the direction you want to go. That's why it's important to plan our daily tasks before working on your big-picture life planning. I have thus discovered GTD – David Allen, a "bottom-up" approach to productivity. The goal is to establish a sense of comfort and control over the work that we have to do, to help us organize our daily tasks as much as possible, in order to have space to concentrate on our big goals.

The artificial intelligence field is strongly connected with Big Data technologies. One of its areas deals with the study of natural language. Computers can be taught to recognize certain patterns in the processed texts and, based on them, they can automatically classify sentences, phrases or even full documents in predefined groups. Using open source instruments, one can easily configure such a project, capable of classifying text, based on a prior automatic learning phase, using a preset input data.

How managing large projects differs from the projects that are spun up in general in IT companies. There are 5 angles that need to be considered when talking about different project sizes and we are going to dive in each of them. I will gladly share the challenges I've met while leading a large project for the first time. The project I refer to is a migration of 300 components to a new platform, which spans over 16 months, which involves 30+ development teams, and which costs >9 M.

Besides the official Docker documentation, there are several good sources on the Internet where you can read about how to kick-start your dockerized environment on your project, including Stack Overflow Docker tag, official Docker images for MySQL, and Postgres. Unfortunately, there aren't so many places where one can read about the failures in setting up Docker in various common use cases. You may wonder "why would anyone be interested in such a thing?" I think the value of such stories lies in the fact that we discover how such solutions work by trial and error, many times - pretty much the same method applied by a 2nd grader. Do you find yourself in a similar situation? You probably do, so the ideas from here will bear some value to you.

It's time to be honest with ourselves and admit that we do not treat our frontend code the same way we treat our backend code, and this shows. When we talk about our code, we talk about applying the rules of clean code, about keeping it simple, about writing unit tests. Yet, when it comes to writing our frontend code, we knowingly skip all those rules that we usually self-impose.

Change represents the focal point of various studies, books, articles and conferences from all fields of inquiry. Undoubtedly, our personal and professional life is more dynamic than ever, being filled with unforeseeable challenges day by day. The world around us changes at a high rate as part of (mega)- and (mini) revolutions across several walks of life. Agile is also about change, more precisely about the changes that teams have to deal with. Agile values and principles focus on the benefits and speed of change. Agile represents a major change, both for the teams which want to implement a particular Agile methodology and for the ones which are constantly evolving.

The brisk rise of modern social media led to the development of tracking tools, which have as unique purpose the monitoring of the written content published on social networks sites. These software products become inefficient when they are applied on tasks which are rich in visual content, with too little or inconsequential written information.