For the 6th year in a row, Startup Weekend Cluj has become a place where young people meet to exchange ideas, learn about entrepreneurship and build their own business. A weekend filled with energy, discussions & feedback sessions with mentors has ended with the final presentations and winners of the 2017 edition. Out of the 97 participants, 33 have pitched their ideas and, after the voting, 15 ideas were selected to get to the next stage.

The last few years have seen a great change in people’s mentality about software and the way they use it. This change has been brought upon us by the omnipresence of smartphones, the advent of cloud-based computing and, lately, by the Internet of things (IoT). Combine this with the ever-increasing competition of software companies on a relatively slow-growing market, and you get to the point where we are now. Nowadays, people expect to have ever-improving software on their devices, with the newest features in the shortest time possible. There is an upside to all of this: People are willing to cut you some slack when it comes to small glitches and problems in your software, knowing that you will fix them in the next release. So, now comes the point I want to discuss. How do you live up to the expectations? In our opinion, the answer is implementing Continuous Delivery for your projects.

In 2012, Steve Ballmer, Microsoft CEO, familiarized all of us, and the Microsoft fans of the things developed in the past 30 years in particular, with the company’s mission: „a computer on every desk and in every home”. Of course, the path to this declared mission began with the launch of the revolutionary and controversial Windows 8 platform, which was designed to be present on all devices, from desktop to laptop, to mobile phones, tablets and XBOX consoles. Microsoft had to wait another two years until Bill Gates decided to fill in the „Founder and Technology Advisor” position, to fire the former CEO, replacing them with Satya Nadella, the former manager of the Cloud platform and technology division. Due to this welcomed change, Microsoft brings the new company vision to the entire worlds: „Our mission is to empower every person and every organization on the planet to achieve more!”, Satya Nadella CEO Microsoft.

The first time I gave a talk titled “Enterprise flight into DevOps space”, was in late 2014 at DevConFu conference. After that, I delivered the presentation several times during 2015 at various conferences in Europe. For some time, I considered it a “closed topic” and did not really want to expand on it, until I was asked to deliver it again in 2016, and then again in 2017.  Enterprise is a word that is highly abused. Most people associate it with slow inefficient processes. Nobody wants to be there! At the same time, when I ask the audience: “How many of you work in enterprise?” — over 95% raise their hands. Somehow, human nature makes us prefer simple models of the world, even though, we, of course, totally understand that the world is way more complicated. Still, we are easily trapped into selecting good vs evil, being a start-up vs being an enterprise, developing microservices vs struggling with a monolith. Are most of us really on the evil/wrong side? Probably, not.

In today's ever changing world, it's next to impossible to know exactly what customers would want the product to be. Every day, we see new companies coming up with new products and services but have you ever wondered why most of the companies are not able to make it? The biggest reason many businesses fail is that businesses build unwanted products. Building a product exactly the way people want is tough and that is why only half of all establishments survive five years or longer according to the 2016 statistics. This ambiguity towards what customers need can be resolved only by identifying their problems systematically very early in the Product Development Life Cycle. That literally means we need higher customer engagement well before we actually have any product or service for them. Rapid Prototyping is one of the effective ways to do just that. We build prototypes of the products and put that in the hands of the potential customers to gauge their interest into our vision and this will eventually help us build world class products with higher success rates.

Published in Issue 56 Read more

APIs have become very important in a world of interconnected applications. APIs have improved a lot in the past years, especially due to the JSON + REST standards. But there’s still a more subtle lesson to be learned about them that is a hit and miss: APIs are user interfaces too. It’s in the acronym: Application Programmable Interface. Interface for what? For other software systems. But who writes those systems? Developers. So it’s really a user interface for developers who work with your application. Since APIs are user interfaces, we should apply UX principles and techniques to make them easier to use. Here are 5 of them.

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.