Bo Ferri
Slides of presentations of talks I visited @ GoToCph 2015 (incomplete)
On August 5th 2012, NASA landed its most capable robotic geologist on the surface of the Red Planet. The Mars Science Laboratory (MSL) mission landed a 2000 lb rover, the size of a compact car, to explore the planes of Mars. The rover, aptly named Curiosity, will search for organic compounds, characterize the climate and geology, and continue the search for life. One of the most challenging aspects of the mission, from an engineering perspective, was safely landing the rover on the surface. The entry descent and landing (EDL) system used a heat shield to accommodate its hypersonic entry conditions, followed by a supersonic parachute, and eight retro rockets for the powered descent phase. For its final terminal descent, a maneuver called the sky crane was used where the rover was lowered on tethers for touchdown. The talk will describe the motivation for Mars Exploration and how the MSL EDL engineering challenges were tackled with computational modeling and cutting edge experimental techniques.
Great software and great usability are a powerful combination. During this talk you will get an insight into why usability is important to software developers and why companies all around the world invest millions into it.
There will be a lots of real-life examples of how usability improves user engagement and turns decent programs or apps into excellent ones. We will discuss about good practices and minor things you can do right away to improve your user interface.
You will not leave home with theories and things you can’t use, but with real-life examples and an action plan. My goal is also to convince you that usability is worth investing money into.
Erik challenges the basic ideas on Scrum & Agile and how developers should be developing code for the future. In the next decade every business will be digitized and effectively become a software company. Leveraging software, and, in general, computational thinking, to make a business responsive to change using a closed-loop feedback system will be crucial to surviving in this new world where business = data + algorithms. Erik discusses feedback theories, continuous improrovment examples, and how traditional companies are turning into software companies. Ideas for this keynote are outlined in this blog post: http://queue.acm.org/detail.cfm?id=2685692
The data deluge from IoT, weather and financial trading data sources means companies and developers must adopt new approaches to ensure they can not only manage, but also benefit from these time series forms of big data. We will walk you through best practices on the technology landscapes involved – from optimizing NoSQL database for the time series use case and integrating with Apache Spark. Analytics from time series data will play an increasingly vital role in identifying patterns and generating business insight.
Few tools and artifacts survive more than a few years in my toolbox before I replace them with something I have found to be more effective. Story Mapping is however the exception and for the last 5-6 years it has been my weapon of choice when trying to find the most valuable things to do first and align multiple stakeholders towards a common vision. Originally inspired by Jeff Patton’s 2008 blog “The new backlog is a map”, my approach has of course changed considerably since I first started using it, but still much of the core remains the same.
In this talk I will present my experiences with Story Mapping. The cross-breed version I am using right know and why I think it is such a powerful tool to help you better understand what you are trying to achieve, prioritize your business needs and not the least get to market faster with much better alignment between the stakeholders involved. Though primarily used in the Agile world I have found it at least as effective in the world of more traditional stage gate governance models, since no matter the method it forces you to identify what is truly important to your users and the importance of alignment and prioritization.
No matter if you are a fan of traditional waterfall stage gate approaches or a true agilist this session should provide some explicit tools and practices that will make you think twice before you start planning your next project or product release
“We are what we repeatedly do. Excellence, then, is not an act, but a habit.” - Aristotle
You have been doing agile for a few years now. With a regular cadence you have retrospectives and a lot of problems and great improvement opportunities are raised but you don't seem to really improve. Let us put your retrospectives on steroids. Start using Toyota Kata!
Building on the power of habits, Toyota Kata will help you build a daily continuous learning and improvement culture, a kaizen culture.
In this session, you will be introduced to the two main Kata* of the Toyota Kata, the Improvement Kata and Coaching Kata. You will learn how the Improvement Kata and Coaching Kata can become your “muscle memory” for continuous learning and improvements in your organization. These daily habits or routines will help you to strive towards your state of awesomeness in small experiments focused on learning. The Improvement Kata will form the habits of doing small daily experiments focused on learning and improving. The Coaching Kata will form the habits of the agile leaders for creating a culture of continuous improvement, adaption,
and innovation.
In this session, Toyota Kata will be taken out of the manufacturing context and put it into the knowledge work context. You will learn how you can start applying the Improvement Kata and Coaching Kata in a software development context as a compliment or a replacement of the agile retrospective.
Time to stop collecting problems and start forming new habits of learning and improving!
(*) Kata means pattern, routine, habits or way of doing things. Kata is about creating a fast “muscle memory” of how to take action instantaneously in a situation without having to go through a slower logical procedure. A Kata is something that you practice over and over striving for perfection. If the Kata itself is relative static, the content of the Kata, as we execute it is modified based on the situation and context in real-time as it happens. A Kata as different from a routine in that it contains a continuous self-renewal process.
Learning Outcomes:
Programming language design is not just about type theory and grammars. For evolving a mature programming language like Java, it is about finding ways to add capabilities while maintaining compatibility, both with existing code and with the expectations and mental models of 9 million or so Java developers. In this talk, Java Language Architect Brian Goetz looks at some of the challenges and lessons of steering Java through major evolutionary changes.
A domain model built on the principles of functional programming already has the goodness of immutability, compositionality and modularity. In this talk we demonstrate how to make functional domain models reactive, i.e. how to make them more responsive, elastic, resilient and scalable. We start with a sample use case implemented using FP in Scala and use the power of the type system to make the functions reactive without compromising on compositionality. We show several patterns of being reactive while designing domain models and discuss their pros and cons. Finally we talk about the streams model that help implement reactive domain behaviors using typed composable APIs, principled failure management and resilient distribution across clusters.
The conventional assumptions that we make about the design of our software systems don’t really meet the demands of the 21st century. 21st century problems are not well served by 20th century software architecture.
The hardware profile has changed, the business demands have changed the scale of the systems has changed. How do we cope?
The Reactive Manifesto identifies some common themes in high performing systems. Some of the highest performing systems in the world are grounded in a few basic principles. What are these principles and what does it mean for the systems that we build and the way in which we build them?
With Big Data becoming more and more the norm in many companies, there is added complexity not only to the systems logging and storing the data, but also to the logic of and reasoning of the end user. The business user would often like to dig deeper into the data, whereas the developer wants to make sure that the data is optimized for easy management. What and who should determine the trade-off? Our goal has been to try to create a development environment that allows for making that distinction on a case by case basis. However with rapid growth and continued increased popularity this remains to be a challenge and prioritization is a constant obstacle. Front-end and reporting is the last step facing the end-user, and many times the decisions affecting the interface were made several steps upstream. Today we have aggregation in the data warehouse, intermediate cubes as well as aggregation in the reporting tools. In order to manage the many variations of business needs, as well as levels of aggregations layer that our different requests contain, we have strived to make our development environment the constant. It is standardized enough to create stability, yet flexible enough to allow for creativity. I would like to speak a little about how we view the challenges of our Big Data and how we systematically address them in order to provide our end-users with the right information at the right time.
