Build Stuff'16 Lithuania

I’ll talk about scalability and fault tolerance features of distributed Erlang. In particular, what makes it so good for large scale distributed applications on commodity hardware, where devices are inherently non-reliable and can disappear and re-appear at any moment.

The talk is based on experience of leading research on developing Scalable Distributed Erlang (SD Erlang -- a small extension of Erlang for distributed scalability) and integrating Erlang in robotics. So, I’ll share rationale behind design decisions for SD Erlang, lessons learned, advantages, limitations, and plans for the further development. And talk about benefits of Erlang in distributed robotics, initial findings, and plans.

As the microservice train thunders into town, it is bringing with it an old enemy - the Remote Procedure Call. Libraries like Thrift are being used for client-server communication and no one seems to be looking back to the past to understand why we ran screaming from RPC last time. Drawing on bitter experience of DCOM, .NET remoting and Web Services, and his very British desire for a decent cup of tea, in this talk Ian Cooper will explain the anti-patterns of RPC and look at the alternatives which will ensure your system stays stable and he gets a decent brew.

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.

I've been working with Elm professionally for most of the year and it has proven itself to be a remarkably simple way to build applications targeted at the web browser in a safe and maintainable manner.

In this talk we'll very quickly skim over the language itself before taking a tour into the common patterns of usage we have discovered as well as some useful libraries that have ended up being an integral part of each of our applications.

This is not a theoretical talk, there will be tangible examples and some discussion of the pitfalls of using this technology - but hopefully together we can help prevent any more raw JS being forced on the world...

Have you ever tried to extract a relationship among the data that your documents carry? Sometimes document-oriented model does not provide us an appropriate structure to collect how the data is related and we need a graph. Manual replication from MongoDB to Neo4j may be painful to be done. This talk will present a tool called neo4j-doc-manager (written in Python, based on mongo-connector project!), that allows you to grab MongoDB events and mirror them to any other database.

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?

Just like traditional applications development, machine learning involves writing code. One aspect where the two differ is the workflow. While software development follows a fairly linear process (design, develop, and deploy a feature), machine learning is a different beast. You work on a single feature, which is never 100% complete. You constantly run experiments, and re-design your model in depth at a rapid pace. Traditional tests are entirely useless. Validating whether you are on the right track takes minutes, if not hours.
In this talk, we will take the example of a Machine Learning competition we recently participated in, the Kaggle Home Depot competition, to illustrate what "doing Machine Learning" looks like. We will explain the challenges we faced, and how we tackled them, setting up a harness to easily create and run experiments, while keeping our sanity. We will also draw comparisons with traditional software development, and highlight how some ideas translate from one context to the other, adapted to different constraints.

Finding developers with a good understanding of CQRS and Event sourcing, either new hires or existing internal resources is a core challenge. This talk will cover methods we have found on how to develop existing and new talent into effective CQRS-ES engineers. In 2.0 we build on methods for overcoming resistance and 'rules' to keep incompatible approaches at bay, and cover new training approaches we have found work to guide developers into learning how to think and solve problems using message based and CQRS approaches.

In 1991 Erik Meijer, Maarten Fokkinga, and Ross Paterson published "Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire." This paper is a classic one, widely recognizable in the FP community. Constructs described - known as recursion schemas - have real world applications. Strictly speaking, explicit recursion is the ‘goto’ of pure functional programming. Recursion schemas provide same level of sanity as loops did for structural programming back in the day.Over the years a lot of the progress have been made. Papers like "Recursion schemes from comonads" by Tarmo Uustalu, Varmo Vene & Alberto Pardo or "Unifying Structured Recursion Schemes" by Ralf Hinze, Nicolas Wu & Jeremy Gibbons - pushed the concept forward.This talk is about generalization of a very specific recursion schema (called catamorphism) over fixed point data type. After providing introduction the concept of catamorphism, we will jump straight to fix point data types trying to solve some real-world problems. Code examples are in Scala. Code examples use Matryoshka - which is an open sourced project design to generalize folds, unfolds, and traversals for fixed point data structures in Scala.

Building a service/Microservice is itself
easy. Scaling it on the cloud is not that hard either but operating,
maintaining and iterating a production large scale service is not just
about linearisation. As Cockcroft points out, telemetry and monitoring
is the most important aspect of building Microservices We discuss 5
patterns that any serious Microservice should have: - Canary (an
endpoint reporting health of underlying dependencies) - IO monitor
(measuring all calls from Microservice to external dependencies) - A
circuit breaker - An ActivityId-Propagator - An exception and short
timeout retry policy Apart from the Microservice buzzword, there is a
saddening lack of understanding of what a successful Microservice
architecture requires in terms of monitoring and telemetry. MTR in
case of a Microservice can be much more than a monolith if these 5
patterns are not in place.

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?

In 2014 the Angular team decided to start from scratch to implement a new framework for modern web development. This new framework would support only greenfield browser and native mobile applications. They decided to call it Angular 2. The only thing this new framework has in common with the first version of Angular is the core team that started the development of the framework.
In this session we will cover the core features of Angular 2, how to setup the development environment, so you can get started easily, and how you can use Angular 2 to start creating rich Single Page Applications.

When we talk about scaling, we usually mean up (bigger machine) or out (more machines). However, there is another alternative, which is changing our workload in a way that makes it inherently more parallelizable and then taking advantage of specialized hardware that's very good at handling that sort of thing. Most of us have exactly this type of hardware just sitting in our computers, doing very little most of the time. I'm talking, of course, about the GPU. General-purpose computing on the GPU (GPGPU) is no longer the domain of pure academic research. It is being used in real-world applications such as image processing and face recognition, cryptography, big data analysis, and Bitcoin mining. In this session we will examine the available GPGPU frameworks, learn how to integrate C++ AMP and OpenCL into regular .NET and Java applications, how to debug mixed .NET and GPGPU code in Visual Studio, and how to use the Aparapi framework to seamlessly mix regular CPU and GPGPU code in Java. We’ll even look at using GPGPU from server and client-side JavaScript with WebCL. We will discuss the kinds of tasks that can benefit from graphics card processing, how best to parallelize workloads, and what some of the performance trade-offs are.

You've spent time and effort to build a website, and you must verify that it works correctly. Especially the UI, which is arguably the most important part of any software - at least to the user. But you might be tired of manually testing webpages, as that is a tedious and error prone process. Have you ever asked yourself if there must be an easier way? If you have, you're in luck, as there are many ways to do so, including one called WebDriver that you'll learn about. In this session, you'll learn how to write a few lines of code that can replace all the manual Web UI testing that you or your QA people have been doing.  Save yourself and your testers time and money by automating the process of testing user interfaces. You'll learn how to write a UI test one time that will run again and again, testing web pages so you can confidently make changes and maintain the code. We'll discuss how to automatically fill in forms, navigate, and do anything that the user might do, but automatically, with no user involved! UI automation tests are a great way to help ensure a higher quality of your software.