Are architects supposed to be the smartest people on the team, making all the important decisions for developers to fill in the blanks? Certainly not.

Rather, architects make everyone else smarter, for example by sharing decision models or revealing blind spots. Architects also communicate across many organizational layers by using models and metaphors. This talk reflects on two decades working as an architect, ranging from the executive penthouse to the serverless engine room.

Making the right decisions for a mobile project involves lots of trial and error before you find a good path. Wouldn’t it be nice if you had a map for REAL APPS and not just Hello World?

In this session, we will compare frameworks and approaches based on the kind of mobile project you are doing, and walk through what the actual code looks like to accomplish basic tasks for each one. We will cover native, hybrid, and mobile web approaches for enterprise-level solutions.

We all rely on asymmetric encryption every day, both as developers and consumers. It’s what keeps our web traffic safe, what lets us sign our git commits, and what powers almost every single authentication flow.

Most of us will know the names of the most commonly used asymmetric encryption algorithms, RSA and ECDSA. But how many of us know how they actually work? What are their drawbacks and limitations, and where are they vulnerable?

As soon as you even mention the words real time and browser everyone’s minds immediately go to WebSockets. And I get it, WebSockets are cool, flexible and can be used for almost anything. From updates to how far away your bus is, to downloading a stream of messages in chat applications to syncing your current state for collaboration when multiple people work on the same document.

But there exists other technologies that do the same thing. Things that have just as good browser support (maybe even better), demand less from the network setup of the server, and is a lot easier to understand how works.

Software is complicated. Machine learning, microservice architectures, message queues… every few months there’s another revolutionary idea to consider, another framework to learn. And underneath so many of these amazing ideas and abstractions is text. When you work in software, you spend your life working with text. Some of those text files are source code, some are configuration files, some of them are documentation. Editors, revision control systems, programming languages - everything from C# and HTML to Git and VS Code is based on the idea of “plain text files”. But… what if I told you there’s no such thing?

Cascading Style Sheets. CSS. The language everybody loves to hate. Everything’s global, there’s no control flow, there’s no error messages… in fact, some people say it isn’t even a real programming language.

But CSS isn’t just about making websites look pretty. It’s one of the fundamental building blocks of the open web, and it’s continuously evolving. Modern CSS has variables, grids, flexboxes, animations, view transitions… when it comes to layout, accessibility, interaction and validation, CSS can do all kinds of things you thought you could only do with JavaScript.

Software and technology has changed every aspect of the world we live in. At one extreme are the ‘mission critical’ applications - the code that runs our banks, our hospitals, our airports and phone networks. Then there’s the code we all use every day to browse the web, watch movies, create spreadsheets… not quite so critical, but still code that solves problems and delivers services.

But what about the code that only exists because somebody wanted to write it? Code created just to make people smile, laugh, maybe even dance? Maybe even code that does nothing at all, created just to see if it was possible?

As more developers apply Command/Query Responsibility Segregation to their projects, many find that it INCREASES the complexity of their systems rather than decreasing it, often without any performance benefits either. Join Udi for a look at where you should, and more importantly SHOULDN’T be using CQRS in your projects.

CQRS can be a powerful architectural approach when applied to the right problems, but it can also introduce additional models, infrastructure, and coordination that increase the complexity of a system.

One of the goals of building microservice-based architectures is to reduce the complexity of individual components. In doing so, some of that complexity shifts from individual services towards interservice communication. You may have bumped into the terms orchestration and choreography in your research on the topic. While the web offers a vast range of articles that carefully outline the pros and cons of each pattern, the real challenge is left to the reader: deciphering which pattern best fits your specific use case by understanding which arguments apply to your use case and weighing only the relevant ones in your decision.