The startup world is getting active in the new year. Here you have a few options for the upcoming two months:

This article aims at answering a set of core questions about software architecture, providing answers that come from modern software architecture thinking. Its inspiration came from:

• Conversations with Rebecca Wirfs-Brock and Simon Brown
• Architecting the eventrix.co product, running “Architectural Katas”
• Countless conversations with architects and developers at international conferences
• Conversations with participants to architecture workshops

Architecture description languages (ADLs) are formal languages that can be used to represent the architecture of a software-intensive system. As architecture becomes a dominating theme in large system development, methods for unambiguously specifying architecture will become indispensable. By architecture, we mean the components that comprise a system, the behavioral specifications for those components, and the patterns and mechanisms for interactions among them. Note that a single system is usually composed of more than one type of component: modules, tasks, functions, etc. An architecture can choose the type of component most appropriate or informative to show, or it can include multiple views of the same system, each illustrating different componentry.

There are many times when starting a new project as a monolith makes sense, especially in very lean projects where the requirements and the product are not entirely clear from the beginning. In such a project, the domain and domain models shift and change a lot as the application pivots, and the requirements evolve. As the project and product mature, hopefully, their domain takes shape and settles, becoming more stable. By now, some parts of the domain will be more active than others. This is the stage where micro services bring advantages, allowing the development teams to focus on smaller areas that are more manageable, easier to handle, test, and deploy. But that aspect also adds a bit of overhead as all these different domains require focus to integrate and automate. At the beginning of a project, almost all areas of the application evolve requiring continuous integrations and deployments. At that moment, there is no real benefit in splitting them. Considering that the requirements might be too fragile and, as a result, the domain model of the application might be quite volatile, micro services add to the overhead, as some may disappear or shift considerably.

You’re starting a website. How should you go about it? Is a Content Management System (CMS) necessary or even worth it? There’s a lot of mutually opposed and inconsistent information on the subject and truth be told, there’s no definitive answer to these questions. There are very pertinent pros and cons for going with or without a CMS. This article is not an exhaustive presentation on the matter, nor does it try to come with final answers. It’s a simple depiction of a feasible alternative to the plethora of similar solutions out there.

We have over the last 12 months starting to look extensively in how we can leverage AI / Deep Learning to help improve OpenStreetMap and today we want to provide a few details about how we envision the future of making maps and also share more on what we are already doing. We see the emergence of self-driving vehicles as a game-changer and one key requirement for those vehicles are accurate and up-to-date maps. Currently commercial map providers map every region around every 12-24 months – in a costly process with a high precision and high cost vehicle, our goal was to achieve maps that are updated on a minutely basis and with key streets covered at least once every day. This is the goal we set out to solve with OSM in supporting to make it ready for this use-case.

Let's take a look at Azure Functions, from a developer perspective. In this paper, we will write an Azure Function that adds the GPS coordinates of a picture as watermark. If you want to jump to the code, without any other explanations, than feel free to check the GitHub repository

Behavior Driven Development (BDD) was first introduced by Dan North as a way to explain Test Driven Development to some customers who needed to apply TDD in their project (see [1] for details). It is a set of collaboration practices designed to help build the right software and to provide real value for the users (in contrast to its better-known brother, Test Driven Development, whose main goal is building the software right). BDD proposes an approach for minimizing the inherent misunderstanding which arises when the information is passed from one stage to another stage of the software development process (from client to business analysts, then to programmers and testers). It is accomplished by defining real examples as a result of the collaboration of all stakeholders involved in the project. BDD is not an integral software development methodology on its own (it does not try to address all the areas of this domain), so it should be supported by other methodologies, like Agile, Test Driven Development or Domain Driven Development.

Today’s applications are undoubtedly sophisticated and rely on many technologies to do what they do. As developers we focus more on the technical implementation of the software, starting from what language, framework or tool we use for the implementation. This happens because developers are problem solvers and enjoy this part of the job. But, the truth is that a system that doesn’t solve the business need is of no use to anyone, no matter how pretty it looks or how well-architected it is implemented. When we think about a project, there are many things which can delay that project: for example bureaucracy, unclear objective, lack of resources and so on.

What not so many people know, especially in Romania, is that Bosch stands for much more than refrigerators and drilling machines. For example, the main theme for us this year is: Simply Connected. What does this stand for? It stands for intelligent and connected solutions split across four categories: Connected Mobility, Smart Home, Smart City and Industry 4.0. The company offers not only a variety of products, but also a variety of solutions, which help consumers lead convenient, efficient and secure lives. In this article, I want to briefly present one solution, developed within our Industry 4.0 Project for which developers from our Engineering Center in Cluj contributed to a great extent: TraQ – Tracking Quality.