Build Stuff'16 Lithuania

With the rise of many new types of databases in the last decade, the present-day architects have powerful solutions for building modern software systems. These databases solve specific problems and have many advantages. But using and integrating these database also has pitfalls and can be challenging to put in practice. In this talk you learn about different types of databases and their use-cases and solutions to integrate them. You also hear about the strengths and the weaknesses of combining several type of databases in the same system, a practice called Polyglot Persistence.

Architecture isn't just the static "shape" of your software. It's the set of decisions that define it, enabling — or inhibiting — change, evolution and improvement over time.

 

It is also the decisions about how you verify, deploy, version, manage and monitor an application. Each of these decisions is a trade-off: there are no Best Practises. Some decisions can have a huge forward impact, and it isn't always obvious which ones! In this talk Dan offers several strategies to help you improve your architecture decision-making. He won't tell you whether to prefer stability or uncertainty, DRYness or coupling, latency or throughput, manual or automated testing.

The beautiful thing about software engineering is that it gives you the warm and fuzzy illusion of total understanding: I control this machine because I know how it operates. This is the result of layers upon layers of successful abstractions, which hide immense sophistication and complexity. As with any abstraction, though, these sometimes leak, and that's when a good grounding in what's under the hood pays off. The second talk in this series peels a few layers of abstraction and takes a look under the hood of our "car engine", the CPU. While hardly anyone codes in assembly language anymore, your C# or JavaScript (or Scala or...) application still ends up executing machine code instructions on a processor; that is why Java has a memory model, why memory layout still matters at scale, and why you're usually free to ignore these considerations and go about your merry way. You'll come away knowing a little bit about a lot of different moving parts under the hood; after all, isn't understanding how the machine operates what this is all about?

Surprise! Your app is totally jacked up!

No one anticipated #npmgate. Though unlikely to happen again, npm’s unpublish loophole is a clear reminder of the meaning of “free as in puppy” when it comes to open source reuse. It’s an excellent opportunity to have a conversation about coupling, dependency management, responsible engineering and open source citizenry.

In this talk, I’ll share techniques for managing dependencies in your Node.js applications at several levels: third party, architectural/design, and implementation. I’ll demonstrate several tools you can incorporate into your testing practice, continuous deployment pipeline and development workflow. Lastly, we’ll examine proven object-oriented patterns and functional composition techniques that help us control coupling in the code we own.

Applications in the movies deploy and scale with the touch of a button, with no concern for cloud infrastructure or even CPU architecture. Is that really science fiction, or have we been doing it wrong all along? What can we learn from sci-fi movies—and the sources that inspired them—about building applications today? Is it possible to build apps that deploy, scale, and self-heal on any infrastructure?

Once upon a time, when the web was young, phones were dumb and people still thought progressive JPEGs were a pretty neat idea, there were people who called themselves... THE WEBMASTERS. They were brave, they were bold. Armed with a 56k modem and a stack of O'Reilly books, the webmasters were fearless in their ongoing quest, driven by a humble vision - to connect the entire world together. Using Netscape Navigator. Of course, that was a long time ago, and nobody really believes the stories any more. Some say the webmasters are gone. Some say they never existed in the first place - it was just a bunch of marketing people with delusions of grandeur. But a few, a select few, believe they changed. They evolved. They learned new skills, they embraced new technology... and the Legend of the Full Stack Developer was born. The history of software development is rich with tales of extraordinary individuals, whose knowledge of their own systems was absolutely unrivalled. But here in 2016, in a world where distributed systems, machine learning and autoscaling cloud systems are ubiquitous and the average web app uses three JavaScript frameworks, four server-side languages and six different kinds of caching technology, does it really make any sense to talk about full stack developers? Are we clinging to outdated paradigms, nostalgic for the simple days when one person really could know all the answers - or does overspecialisation represent a genuine threat to the established discipline of software development? And if it does - should we be resisting it, or embracing it as a change that's long overdue?

Code is a not an asset. Technology is not the solution to your company problems. And engineering for engineering's sake is not the answer. As engineers, we tend to focus a lot of our time thinking about "how?". How to solve this problem? How to structure code? How to name this method? We forget to ask "why?" and ponder the usefulness and greater impact of what we're doing. We don't work in silos. What we do affects our users. But not only that. It also affects our teammates and other developers in our organisations. Let's talk about why, having aforementioned things in mind, we should aim to write less code. Use less and more mature technologies. And don't do engineering for engineering's sake.

Service discovery and configuration has been an operational issue since Service Oriented Architecture became popular. With the advent of Microservices the problem has become even more acute. Previous solutions included technologies such as UDDI and load balancing, but this presented issues with scaling. Consul from HashiCorp claims to make this easy, but what technologies and principals did they use to build Consul that allow them to make that claim? In this session I will examine the 2 of the main pieces of research used to underpin Consul, the SWIM and RAFT protocols, and how they tackle the problems suffered by more traditional solutions, and also discuss how some design decisions in Consul make it far easier to integrate unobtrusively than previous technologies.

Most of us are familiar with the architectural style known as REST, but even experienced developers often find it difficult to translate REST's architectural principles into running code. In this talk, we'll explore the elements of REST related to hypermedia and the principle of "hypermedia as the engine of application state" (HATEOAS) - we'll talk about why they matter, and when you might want to implement them in your own systems. We'll look at some of the tools that exist to help you design, deliver and debug your HTTP APIs, and we'll do some hands-on coding to show you how to implement lightweight, flexibile hypermedia patterns in your .NET web applications using the NancyFX HTTP framework and the HAL hypermedia application language.

Traditionally we consider web sites to be working in an online mode only. If the Internet connection drops, the entire web site stops functioning. Mobile applications, however, change this perception as connection is considered unstable and applications should take necessary measures for good user experience. Now we are able to create web sites that react on changes in the Internet connection and provide certain functionality offline. AppCache, IndexedDB and File API are few of the mechanisms to allow us to store the application and its data in the browser. However, now we have some questions to think about: Who is the master of the data - the client or the server? What data should we download in advance? How do we handle updates of the application? In this talk I will give overview of how web applications can go offline and which precautions we should take.