YOW! and AWS partner to bring you three speakers…and an access to AWS Summit!

We are partnering up with Amazon Web Services to deliver Development for the Cloud at our next Sydney YOW!Night on 12 April. This special event offers a great line-up of the tech industry’s most prominent subject matter experts, whom will share some of the latest ground-breaking technologies in Machine Learning and Microservices, which is enabling developers to be at the fore-front of change and transformation in today’s business landscape.

Download Slides 

ABOUT THE TALKS

Artificial Intelligence, Machine Learning, Data Analytics, Virtual and Augmented Reality and IoT By Glenn Glore

Glenn Gore, Chief Architect for AWS, will talk about how Artificial Intelligence, Machine Learning, Data Analytics, Virtual and Augmented Reality and IoT are changing the world around us. Never before have developers been in such an empowered position to spear-head and influence change and transformation in their respective organisations with the ease of access to these technologies. With so much change and innovation occurring at an increasing pace, Glenn will share how you can get started today and take your creative ideas and turn them into functioning services quickly and easily by leveraging the power of the cloud.

Atlassian’s voyage with AWS Services By Roaan Vos

Around 4 years ago, Atlassian started its voyage into developing solutions around and on top of AWS services. Various teams had been building their own stacks and processes, making the usual mess. A few proactive people in engineering services decided to clean some of it up by standardising on the 12 factor app and building the Micros platform to support it. This talk is about some of the challenges they faced and solved in getting 500+ developers building and deploying 700+ services to AWS, from managing the cloudformation stacks to automated database backups. The resulting solution enables developers to get a new service to staging in hours and into production inside a week, including all compliance and operational requirements.

Exploring Cloud Computing Services with Alexa By Drew Firment

The future of cloud development will be driven by “functions as a service” that can’t be performed by server-based infrastructure or platform services. A simple and engaging way to explore cloud computing services and the new concept of event driven “serverless” functions is by developing a custom Alexa skill. It’s a fun and engaging entry point into the API-driven world of cloud computing and emerging serverless architecture patterns. Let’s walkthrough a quick demo of how to get started with building your own Alexa skill with serverless!

Videos

ABOUT THE PRESENTERS

GLENN GLORE

As the head of Architecture for Amazon Web Services, Glenn is responsible for managing a regional team, creating architectural best practices and working with customers on how they use the cloud for business transformation. In this role, Glenn oversees architectural best practices across APAC, regional input into the AWS roadmap and supporting customers that are making strategic investments with AWS.

 

DREW FIRMENT

 Drew Firment is a managing partner at A Cloud Guru which provides online cloud computing education to over 500,000 students across 160 countries. Drew is recognized by Amazon as both an AWS Community Hero and Alexa Champion for his to efforts to build learning communities and improve diversity in the industry.  In his prior role as Director of Cloud Engineering at Capital One, Drew helped migrate the early adopters of AWS and founded their cloud engineering college. As the Dean of Cloud Computing, he earned a patent for measuring cloud adoption and maturity, and pioneered the intersection of strategy, governance, engineering, agile, and education.

 



Program

5:30 pm   Welcome networking with refreshments

6:00 pm   Presentations followed by Q&A

THANK YOU TO OUR YOW! NIGHT SPONSORS

YOW! Night Partner

YOW! Gold Community Sponsor

YOW! Gold Community Sponsor

User group Partner

APIs : From Good to Great

These days, with so many tools, frameworks, and platforms on the market, just about everyone can build and deploy an API on the Web. And most of those APIs are pretty good. But they’re rarely great.

It turns out Great APIs don’t rely on any single format, library, or platform — they are defined by key attributes and principles employed when the API is designed, built, and deployed. And these principles hold true whether your API is based designed to use SOAP, REST, CRUD, Reactive, or Graph/Query technology. Greatness is within reach for everyone.

Download Slides 

Building Evolutionary Architectures

An evolutionary architecture supports incremental, guided change across multiple dimensions.

For many years, software architecture was described as the “parts that are hard to change later”. But then microservices showed that if architects build evolvability into the architecture, change becomes easier. This talk, based on my upcoming book, investigates the family of software architectures that support evolutionary change, along with how to build evolvable systems. Understanding how to evolve architecture requires understanding how architectural dimensions interact; I describe how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; I cover how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; I cover how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.

Demystifying functional programming and what that means for learning & teaching

Did you ever wonder: Is functional programming hard? Do you have to be a math whiz? What about the jargon? This talk has answers.

Functional programming is sometimes perceived to be unapproachable, with unfamiliar jargon, obscure concepts, and bewildering theories. This seems counter to its main aim, namely to simplify programming and to make programming more widely accessible. In this talk, I like to argue that there is nothing inherently unapproachable or complex in functional programming, at least not beyond the complexity inherent in programming in general. Instead, we need to critically analyse our teaching strategies and ensure that they are appropriate for a broad range of developers. In my experience, the most common pitfalls are (1) to start with abstract concepts instead of with concrete examples and (2) confusing the historic development of a concept with a pedagogically appropriate teaching strategy. A good example of the latter problem is any attempt to explain the use of functors and monads in functional programming by appeal to category theory. Explaining an unfamiliar idea with an even more alien idea is generally a futile endeavour.

We avoid the first problem by leading with concrete examples, which we use to infer recurring patterns of computation and to motivate more abstract language features — for example, by demonstrating how higher-order functions facilitate the removal of duplicate code. We avoid the second problem by focusing on the concrete computational reasons for using a particular concept or language feature; that is, we place the why before the how. For instance, in sample code that requires maintaining shared state, a state transformer monad helps us to remove error-prone plumbing code.

Nevertheless, we have to acknowledge that moving from imperative, object-oriented programming to functional programming requires more effort than learning yet another object-oriented language. The key here is to clearly distinguish new concepts from known ideas that are just presented differently. Some concepts simply have different names (such as structs versus product types), some have different syntax (such as functional application without parenthesis in Haskell), and some are expressed differently (such as while loops versus tail recursive functions). In all cases, we can help learners by establishing a correspondence between the known and the superficially new.

Putting all of this together, teaching and learning functional programming is surprisingly straight forward. Still, we can do even better. Given the importance of working from examples and for students to experiment by quickly exploring a design space, ideas from live programming tighten the feedback loop and provide a distinct improvement for teaching over the classic REPL (read-eval-print loop) introduced with Lisp. I will demonstrate these improvements using Haskell playgrounds in the Haskell for Mac IDE, but the same applies to Swift playgrounds in Apple’s Xcode IDE and the Swift Playgrounds iPad app.

The material presented in this talk is informed by the experience that Gabriele Keller and I accumulated over a decade of teaching Haskell in a variety of courses at UNSW (University of New South Wales) to thousands of students spanning from absolute beginners to experienced developers in postgraduate courses. We experimented with a variety of approaches and performed student surveys to refine our approach over time. We wrote a textbook providing an introduction to computing for first years students and more recently an online Haskell tutorial including screencasts that feature live coding.

Visit NIGHT PHOTOS Here!

Demystifying functional programming and what that means for learning & teaching

Did you ever wonder: Is functional programming hard? Do you have to be a math whiz? What about the jargon? This talk has answers.

Functional programming is sometimes perceived to be unapproachable, with unfamiliar jargon, obscure concepts, and bewildering theories. This seems counter to its main aim, namely to simplify programming and to make programming more widely accessible. In this talk, I like to argue that there is nothing inherently unapproachable or complex in functional programming, at least not beyond the complexity inherent in programming in general. Instead, we need to critically analyse our teaching strategies and ensure that they are appropriate for a broad range of developers. In my experience, the most common pitfalls are (1) to start with abstract concepts instead of with concrete examples and (2) confusing the historic development of a concept with a pedagogically appropriate teaching strategy. A good example of the latter problem is any attempt to explain the use of functors and monads in functional programming by appeal to category theory. Explaining an unfamiliar idea with an even more alien idea is generally a futile endeavour.

We avoid the first problem by leading with concrete examples, which we use to infer recurring patterns of computation and to motivate more abstract language features — for example, by demonstrating how higher-order functions facilitate the removal of duplicate code. We avoid the second problem by focusing on the concrete computational reasons for using a particular concept or language feature; that is, we place the why before the how. For instance, in sample code that requires maintaining shared state, a state transformer monad helps us to remove error-prone plumbing code.

Nevertheless, we have to acknowledge that moving from imperative, object-oriented programming to functional programming requires more effort than learning yet another object-oriented language. The key here is to clearly distinguish new concepts from known ideas that are just presented differently. Some concepts simply have different names (such as structs versus product types), some have different syntax (such as functional application without parenthesis in Haskell), and some are expressed differently (such as while loops versus tail recursive functions). In all cases, we can help learners by establishing a correspondence between the known and the superficially new.

Putting all of this together, teaching and learning functional programming is surprisingly straight forward. Still, we can do even better. Given the importance of working from examples and for students to experiment by quickly exploring a design space, ideas from live programming tighten the feedback loop and provide a distinct improvement for teaching over the classic REPL (read-eval-print loop) introduced with Lisp. I will demonstrate these improvements using Haskell playgrounds in the Haskell for Mac IDE, but the same applies to Swift playgrounds in Apple’s Xcode IDE and the Swift Playgrounds iPad app.

The material presented in this talk is informed by the experience that Gabriele Keller and I accumulated over a decade of teaching Haskell in a variety of courses at UNSW (University of New South Wales) to thousands of students spanning from absolute beginners to experienced developers in postgraduate courses. We experimented with a variety of approaches and performed student surveys to refine our approach over time. We wrote a textbook providing an introduction to computing for first years students and more recently an online Haskell tutorial including screencasts that feature live coding.