Good Old Plain Programming
GOTO Oslo has partnered with DFDS to gather a group of tech pioneers and game-changing coders and put them all on a big boat. This inaugural conference will give attendees the opportunity to spend two days on a cruise from Copenhagen to Oslo and back with the experts who shape our industry and radically improve the way we look at software. Over the course of the trip, we’ll dive into core technical concepts and explore what quality code looks like in 2020 and beyond.
Whatever you’re working with — frontend, backend, mobile, cloud services, microservices, events, machine learning, maybe even upcoming technologies like quantum computing — it’s all based on solid fundamentals like programming languages, testing skills, scalability, stability and a focus on the end user.
Expect a journey packed with keynotes, sessions and masterclasses designed to deliver a blend of eye-opening ideas and the practical skills needed to write software you can be proud of. There will also be plenty of occasions for speakers and attendees to rub shoulders during social events and networking breaks.
Custom group packages and private meeting rooms are available so you can take your next team building on the water and call in the experts for advice and inspiration along the way.
We know that agility means working with customer focus and short feedback loops. We also know the methodologies to choose from and the cultural and personal issues related to making this work. But often, when a company introduces agility, they forget to support the developers in their day-to-day job. How do they actually implement CD, pair programming, testing and architecture in agile development?
The next generation of Agile may not be called Agile at all - it will just be implicit that agility is part of software development. It all comes together: Agile, DevOps, Chaos Engineering and building effective teams. So, what do we need to get there? What can we do now to move beyond the existing methods and give our agility a boost?
Microservices promise faster development, deployments, scaling and all the goodies you always wanted but never had. It’s all about outcomes, and the way your organization is structured has a tremendous impact on those outcomes. It’s easy to say “Conway’s Law” and then move on swiftly, but that’s not enough. Yes, a core characteristic of organizations successfully running microservices is that teams are organized around business capabilities, but there is so much more to discuss: How do we define a microservice? What does a microservices architecture require? How do we withhold or even increase your current level of security when moving to a fine-grained distributed architecture?
But microservices themselves are the easy part. The really difficult choices revolve around everything that surrounds the microservices systems as they are designed, built, run, managed, evolved, stressed and even retired in production. We must consider how to manage and optimize the processes, practices, people and technologies when migrating from a monolithic system to a Microservice Architecture.
On average, it takes a company 8 months to figure out it has been hacked. In a world where innovation and deployment is expected at an ever-increasing pace, security is often neglected. Security requires time, and this time is often not prioritized, imposing a challenge when new vulnerabilities are discovered and exposed every day.
As developers we are responsible for implementing state-of-the-art security in our systems, making it a first class citizen in all system architecture, but how do we build inherently secure and maintainable code and infrastructure to protect our data and identities? How do we equip ourselves with tools to withstand intrusive and adversarial attacks and prepare for unforeseen security risks?
Software Architecture is as important as ever. Newer distributed architectures like event-driven, microservices and serverless are increasing in popularity and adoption but much of the world still runs smoothly because of solid application architectures. These cohesively coupled monoliths often solve problems in the simplest way and might be the right choice for some organizations. But it still critical for architects to understand how to take existing applications and migrate them to microservices or other service-based architectures.
Understanding these different technologies, trade-offs and practices can directly impact an organization’s long-term success. Today’s software architects must design, implement and deploy solutions that are both effective and versatile for our changing world of software. Which technologies and practices can help or hinder when dealing with legacy enterprise architectures? How can architects create hybrid architectures that take advantage of both application and distributed architectures?
Choosing a programming language is one of the most crucial decisions when developing software - the choice can influence the way you and your team think about your problem domain and how you model it.
It can also be overwhelming, daunting or even impossible to understand all of the new programming languages coming up. Is this new language just hype, or will it actually help our team to be more productive?
As developers, we need to be aware of the languages topping the hype curve and focus on the production-ready ones that provide real functionality. We also need to understand the exciting updates to older languages like Java and how ones like C++ are still incredibly important in a newer era.
In many ways, Continuous Delivery extends Agile development principles to production and operations but implementing Continuous Delivery is hard. So many tools claim to “implement Continuous Delivery” but in reality, it requires both technology and organizational improvements.
How can we embrace an evolutionary architecture paradigm and a more iterative approach to improving the design of our enterprise systems? How can we evolve into a more high performing organizations trying to always get better? And what patterns should we adopt to increase throughput, stability and quality as we deploy software more frequently?