Explore YOW! West 2015
No talks match your criteria.
Try selecting different options or show all talks.
It looks like there are no talks uploaded yet.
Check back again later.
Command Query Responsibility Segregation (CQRS) is an important architectural pattern for enterprise applications. It involves the separation of the command (or write) side of the application from the query (or read) side of the application and then only guaranteeing eventual consistency of the query side. It offers a number of important benefits for more complex and collaborative applications. This presentation will give a quick introduction to and overview of CQRS within a Domain Driven Design (DDD) context.
CQRS applications can also benefit, in many circumstances, from the use of Event Sourcing (ES), wherein events produced from the actions of commands are persisted rather than the actual state of the application. This presentation will give an introduction to and overview of CQRS using Event Sourcing, with some of the libraries and frameworks that help create CQRS/ES applications, and a few ways to persist these events in regular data stores or a custom-build third-party event store.
Finally, the presentation will consider whether events are the ultimate and most timeless way to persist application state (without actually persisting application state). The ability to construct and reconstruct data stores on the read side enables post-hoc optimisations of data representation for queries. The ability to change paradigms on the application write side means that the data representation is perhaps even more powerful and timeless than relational data stores.
This session will demonstrate how to use the new features of C# 6 to simplify your code and reduce clutter. We’ll talk about what makes the new “Elvis” operator special, and also demonstrate the power of “Roslyn”, the new compiler-as-a-service.
Spreadsheets are the bane of people’s lives in many organisations and - for better or for worse - businesses continue to rely on them very heavily, even for critical parts of their day to day operations. In my presentation I will discuss how the following technologies can be utilised to build neat solutions to help automate these workflows.
Scala’s Streams and Case classes
The Apache POI project
It will begin by talking about how we’ve ended up here in the first place - a case in point is within large financial organisations which have critical risk models (accounting for billions of dollars on their balance sheets) that still reside within huge and highly complex spreadsheets!
Following a brief overview of a typical spreadsheet model, I will demonstrate how one can interact with them programmatically with the excellent Apache POI library. I then go on to breakdown how by utilising stream processing and case classes in Scala one can provide really neat solutions to replace these manually managed spreadsheets with fully automated and concise, functional solutions.
Finally, I will illuminate how one can assist with the end to end validation process, via the magic of BDD - which can help articulate all is behaving as expected.
For most programmers, regular expressions are a riddle wrapped in a mystery inside an enigma shrouded in line-noise. So most sensible programmers either don’t use them at all (and are thereby forced to reinvent worse wheels…badly), or else they fall back on an “evolutionary programming” approach: find an existing regex that looks like it might do, then randomly permute its “genome” over and over again until it appears to work.
In this talk, we’ll go back to basics and discover that regexes mostly aren’t what you think they are, mostly don’t work the way you were taught they did, and mostly shouldn’t be created the way everyone tells you to.
More usefully, we’ll also talk about what regexes really are, how they actually work, and see how normal programmers can make use of their existing software development skills to construct correct and efficient regexes…without selling their souls or losing their minds.
Even the simplest web application has so many vectors of attack, it’s no wonder most people forget at least one. Web applications aren’t stand-alone; they are built upon frameworks, upon platforms, upon core libraries, each of which could suffer from vulnerabilities you’re not only unaware of, you’re statistically unlikely to discover them all. Consider, for example, last year’s OpenSSL “Heartbleed” Bug.
We hear about security vulnerabilities every week, now it’s time to experience them. Find out what the leading concerns are, and the not so common ones too, and experience live demonstrations of how these attacks play out.
This presentation aims to arm you with the mindset, tools and resources to minimise the opportunities for attack, and to reduce the fallout when they succeed. From cross-site scripting and session hijacking to brute force and man-in-the-middle attacks, you’re expected to cover all your bases so the bad guys can’t use a single one.
Have you designed / developed a system using the “best practices” of the last few years? Are these acronyms familiar - ORM, SOA and DDD? If so there’s every chance that when your system makes it to production, it’s going to suffer.
In this session, I will investigate this often forgotten life of a system - when it’s deployed into the real world and the original developers move on to pastures new. It’s a collection of my experiences from the last 9 months working very close to a live system which I designed a few years ago using the then, best practices.
We will consider issues which are often overlooked or not thought about in too much detail at the development phase like performance, concurrency, scalability and deployment. We’ll see ways we can track problems down, sometimes before the end users even see them. We will think about how to deal with them or even side-step them. And we will consider how we may have avoided them by taking different architectural paths early on.
By the end of the talk I’m hoping you’ll see that delivering a system to production is just the beginning of it’s life, and have some ideas on how to keep it happy and healthy whilst it grows!
Agile borrowed from the JIT manufacturing processes originally at Toyota. The Agile Manifesto itself summarized the key aspects brought into programming from JIT.
Original Agile processes like eXtreme Programming (XP) brought breathtaking speed of delivery to a waterfall world. But Agile has not stood still. From XP’s original (and aggressive) 23 week iterations, we now see individual programmers pushing new functionality to live systems several times a day!
Acceleration drives changes to an organization’s processes and skills, just as the original shift to Agile from waterfall. Organizations reluctant to address such changes, however, inhibit the acceleration. Indeed, their attempts to accelerate often result in lower morale and flawed delivery; these failures drive conservative (and destructive) attitudes against change.
In this talk, we will address a myriad of drivers for faster delivery:
● Available technologies, including Cloud, languages, and new frameworks ● Shift toward active monitoring rather than onetime acceptance testing ● Refined, lighter processes consistent with shorter cycles ● Architecture that is faulttolerant rather than provably perfect ● Shift toward trying ideas rather than firm requirements ● Reduction in role specialists ● Reduction in delivery team size
For each of these drivers, we will describe teams that have taken these steps and the corresponding accelerated delivery.
In my consultancy, I’ve come to realize that most clients/teams I’ve coach don’t care too much about the theory.This presentation, therefore, takes a standpoint in the practical parts.I will also mimic my experience with most teams I’ve introduced kanban too, and do the introduction in small iterations.This means that the presentation also is a template for anyone that will need to introduce kanban to others.
Dread. And countless other choice words come to mind when you’re looking at that massive two thousand lines of code in that one function.You wouldn’t consider touching it with a ten-foot pole, but you have no choice.It has to be done. Your dread now morphs into stress.That stress multiplies when anticipating your deployment to production.Heaven forbid you have to rollback your change! Three year plans of, “let’s rewrite the entire thing” doesn’t usually work when business relies on the software to make money. So then how do you dismantle this monolith?
In this session, see how using Event Driven Architecture you can transform this monolithic mess into something clean, something small, something a lot more manageable.You can don’t have to make sweeping changes to that legacy stuff every time you need to introduce a feature.Instead write clean code completely on the outside.Break your monolith down, one micro brick at a time. It’s about time.
Keming Labs was commissioned by a client in the energy sector to design and build a custom heavy equipment inspection tool. The tool was designed with Harel Statecharts and implemented with ClojureScript running on an Android device.
In this talk, Kevin will discuss this approach; in particular, how explicit immutable data yielded fast, on-device prototyping, easy-to-implement visual testing tools, and improved cohesion between developers, designers, and the end customers.
Monitoring monolithic applications integrating with single databases is a well-understood problem. But who writes monolithic applications these days? Who would even dare in the face of the all-conquering wave of microservices popularity?
Yet effective monitoring of a large fleet of decoupled microservices is a different kettle of fish entirely. And whilst an organisation may have the development savvy needed to build these fine-grained services, this competence does not always provide the necessary operational nous to monitor them in production.
Correlation ids, synthetic transactions and circuit breakers are all concepts those struck with microservice-fever are going to have to master to ensure the benefits of this architecture are not outweighed by the complexity of the associated support infrastructure.
This presentation will use the event stream processing tool Riemann (riemann.io) to demonstrate how typical microservice monitoring patterns can be implemented to provide simple and effective monitoring.
Last year Apple announced a brand new programming language as a modern replacement for the venerable Objective-C. Swift makes a very interesting study in language design - influenced by modern statically-typed languages with an emphasis on safety and speed, but (almost) seamlessly compatible with the unsafe, dynamic, weakly-typed OO language it needs to co-exist with.
Sam will run through a brief introduction to the language, highlighting some of the design choices and tradeoffs made, and show how to use the language features to write better code.
Tiny little apps on your wrist! WatchKit is the SDK for developing apps for the new Apple Watch. This presentation will cover a variety of information to help you create great WatchKit apps, including:
* The architecture of WatchKit apps
* What functionality is and isn’t possible using WatchKit
* Communication and data sharing between Apple Watch and the iPhone
* Tips and tricks for great WatchKit app performance
The presentation will be useful both for newcomers who are looking for a head start in developing WatchKit apps, as well as developers with some WatchKit experience who are interested in sharpening their skills.
HBF has a vision to create a unique community where Members are renowned for being healthier, happier people. HBF delivers this in part, through a range of web based and mobile health tools to allow members to track and monitor their wellness, and by capturing insights from these services alongside broader member data. This case study will present how three solutions originating through experimental innovation days within the HBF IT developer community, applied new technology to local opportunities, to create true member value and a shift in thinking and capability. Examples include the development of a pilot application using Google Glass for HBF Fitness; an application for members to upload their wearables data into an integrated service to record and compare data and receive rewards and incentives; and the use of rapid data discovery and interactive visualisation tools to bring HBF’s data to life.
The maker culture, it’s a place where minimum viable product simply isn’t cool enough, where manufacturer security holes are useful and where your skills as a developer are a membership card.
Learn how to get started coding against the devices in your home and see how your existing developer skills and tools can be used to improve the way you interact with the physical world. We’ll dive into real world examples of bringing a residential A/C and a typical domestic wireless doorbell into the Internet of Things using a netduino and the .net microframework. Along the way we’ll discover some pitfalls for experienced developers and a heads up for dealing with the iGeneration prankster.
Functional Programming, like Object Oriented and Structured Programming, is a quite radical departure from previous programming practices. Like these two previous changes in approach, change is gradual and faces significant resistance.
While the ideas around functional programming are becoming more widely accepted, actually adopting the techniques in old-school imperative teams and code bases presents significant challenges technically, culturally and politically. Exploiting the full potential of FP does require experience, and when the imperative experience vastly outweighs that of FP, importing experience can be enormously beneficial.
This talk is about experiences introducing functional programming across a large organisation; what works and, perhaps more importantly, what doesn’t. It looks at some specific patterns and anti-patterns that should be considered for people wanting to transform any organisation that has significant existing program assets and software engineering teams. It will help form and present discussion and arguments to achieve meaningful change.
Setting up a shared infrastructure environment is a challenging task, changing an existing one without breaking anything even more and one that traditional testing methods often have trouble supporting.
Behaviour Driven Infrastructure (BDI) is one of many tools that can help us change the way we approach testing of infrastructure changes. Supported by a real-life case study I will shed some light on what the future might hold in this area and expose some ways in which BDI might help fill the gaps.
Remote working in our industry is becoming more prevalent everyday. Geography is no longer a constraint in setting up a work function in an organisation.In 2010 REA Group, together with ThoughtWorks China, set up an offshore delivery centre.This centre works extremely effectively using REA Agile processes.
I have been building remote teams in Xi’an for the past 2 1/2 years. As a Technical Lead,I have detailed hands on experience and specifics that I will share with the audience on what has worked well for us as well as what hasn’t worked so well. This case study will provide a recipe for working with remote agile teams effectively. In particular I will cover:
• Remote team composition • Essential technology • Core practices • Asynchronous versus Synchronous communication • Common Challenges • Building a successful culture • Tips and tricks for remote working
This is the era of mobility. Application development teams in enterprise IT are gearing up to produce the mobile apps their customers require.To meet the time-to-market demands of mobile users, most mobile apps are developed using Agile and lean development processes.However, quite often, it seems testing slows down the development process and defeats the purpose of Agile development.The ever-increasing demand from the business,the diverse nature of the platforms & frequent releases of mobile operating systems make our current testing framework, designed using the traditional tools & methodologies, unfit to cope with these challenges.The big question is, how can we tackle these challenges? Should we sacrifice testing for the sake of speed? Or, should we design a test framework which will be closely integrated with the development process, providing an instant feedback on the functionality & performance of our mobile app after any new code is checked in.Here in this case study, we intend to demonstrate our test framework, designed using some commercial & open source tools, and showcase how we use this framework to test our mobile API and our app on real-time devices.
The presentation will be structured with the flow of an agile environment in mind.We will demonstrate how we tackled the challenges of mobile development by having close knit team of individuals – we call them solution engineers.We do not segregate the team depending on particular disciplines like development & testing.Testing in the team now starts before development begins.The test scenarios are drafted & the automated API tests are created.The unit & the integration tests (API tests) are executed after every code drop.Once we get the build ready, the app gets automatically installed on the real-time devices & the user interface tests are triggered.As the test pyramid suggests, we increased the test coverage in the unit & integration layer, reducing the number of user acceptance tests which run through the user interface layer & are expensive to maintain.
We know the “right thing” to do is to work together, to remove bottlenecks, to automate, automate, automate. But when the status quo is finger-pointing, mistrust, blame, and over-exhaustion from increasingly complex manual releases, it seems impossible to find a way to climb out of the downward spiral. How did an IT department turn this around to become a harmonious department with common goals and over 10x faster cycle times?
Winning the hearts and minds needed for lasting DevOps change requires something more than just great automation. This is the story of how Wotif found a way to incentivise a DevOps transformation across an entire IT department, resulting in cycle times measured in hours instead of weeks/months. While this journey involved technology such as DropWizard, Puppet & ZooKeeper, Matt (dev) and Alexandra (ops) extract principles that they hope can be applied to any organisation at grassroots and leadership levels using existing toolchains to support not only the best ideas of the present but also the legacy of the past and the unknown innovation of the future.
Twelve BDD Anti-Patterns: Stories from the Trenches about how NOT to do Behaviour Driven Development
Behaviour Driven Development is a powerful collaboration technique that can empower teams to deliver higher value features to the business faster and more effectively. But although Behaviour Driven Development is based on a number of simple principles, it can go dramatically wrong in a myriad of different ways.
In this talk we discuss twelve BDD anti-patterns we frequently encounter in real-world BDD projects, anti-patterns that can dramatically reduce the effectiveness of BDD as a practice, and that can even cause BDD adoption to fail entirely. Looking at everything from insufficient collaboration practices to poor use of test automation tooling, from teams that test too much to teams that forget the most important scenarios, we will look at the many different ways that BDD can go wrong, and how it should be done.
We will use real-world examples to illustrate each of these anti-patterns. You will learn how to spot these issues in your own projects, and more importantly how to avoid them in the first place.