�ݺ�ߣshows by User: BrianTroutwine1

�ݺ�ߣshows by User: BrianTroutwine1 / http://www.slideshare.net/images/logo.gif �ݺ�ߣshows by User: BrianTroutwine1 / Thu, 26 May 2016 21:59:27 GMT �ݺ�ߣShare feed for �ݺ�ߣshows by User: BrianTroutwine1 (Moonconf 2016) Fetching Moths from the Works: Correctness Methods in Software /slideshow/moonconf-2016-fetching-moths-from-the-works-correctness-methods-in-software/62445327 ufiffjehqtafemsogh8o-signature-494aac54aad5d0ee19721f4acf1f2cb28b9e2f5131c41c38046d03c9e129445c-poli-160526215928
We live in a nice world. There’s a wealth of historical thought on achieving correctness in software–shipping code that does only what is intended, not less and not more–and there are a whole bunch of methods available to us as practitioners. Some of these are hard to apply, some are easy. For instance, case testing is widely used and considered standard practice. Property testing is understood to exist but not widely used. The application of advanced logics? Way out there. If you look around you’ll find a lot of software fails a lot of the time. Why is that? In this talk I’ll give an overview of the methods for producing correct systems and will discuss each in its historical context. With each method, we’ll keep an eye out for present applications and the difficulty of doing so. We’ll discuss why there’s so much buggy software in the world. I expect there will be talk of spaceships a bit. By the end of this talk you ought to be able to make reasoned decisions about applying correctness methods in your own work and have a good shot at building better software.]]>
We live in a nice world. There’s a wealth of historical thought on achieving correctness in software–shipping code that does only what is intended, not less and not more–and there are a whole bunch of methods available to us as practitioners. Some of these are hard to apply, some are easy. For instance, case testing is widely used and considered standard practice. Property testing is understood to exist but not widely used. The application of advanced logics? Way out there. If you look around you’ll find a lot of software fails a lot of the time. Why is that? In this talk I’ll give an overview of the methods for producing correct systems and will discuss each in its historical context. With each method, we’ll keep an eye out for present applications and the difficulty of doing so. We’ll discuss why there’s so much buggy software in the world. I expect there will be talk of spaceships a bit. By the end of this talk you ought to be able to make reasoned decisions about applying correctness methods in your own work and have a good shot at building better software.]]> Thu, 26 May 2016 21:59:27 GMT /slideshow/moonconf-2016-fetching-moths-from-the-works-correctness-methods-in-software/62445327 BrianTroutwine1@slideshare.net(BrianTroutwine1) (Moonconf 2016) Fetching Moths from the Works: Correctness Methods in Software BrianTroutwine1 We live in a nice world. There’s a wealth of historical thought on achieving correctness in software–shipping code that does only what is intended, not less and not more–and there are a whole bunch of methods available to us as practitioners. Some of these are hard to apply, some are easy. For instance, case testing is widely used and considered standard practice. Property testing is understood to exist but not widely used. The application of advanced logics? Way out there. If you look around you’ll find a lot of software fails a lot of the time. Why is that? In this talk I’ll give an overview of the methods for producing correct systems and will discuss each in its historical context. With each method, we’ll keep an eye out for present applications and the difficulty of doing so. We’ll discuss why there’s so much buggy software in the world. I expect there will be talk of spaceships a bit. By the end of this talk you ought to be able to make reasoned decisions about applying correctness methods in your own work and have a good shot at building better software. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/ufiffjehqtafemsogh8o-signature-494aac54aad5d0ee19721f4acf1f2cb28b9e2f5131c41c38046d03c9e129445c-poli-160526215928-thumbnail.jpg?width=120&height=120&fit=bounds" /> We live in a nice world. There’s a wealth of historical thought on achieving correctness in software–shipping code that does only what is intended, not less and not more–and there are a whole bunch of methods available to us as practitioners. Some of these are hard to apply, some are easy. For instance, case testing is widely used and considered standard practice. Property testing is understood to exist but not widely used. The application of advanced logics? Way out there. If you look around you’ll find a lot of software fails a lot of the time. Why is that? In this talk I’ll give an overview of the methods for producing correct systems and will discuss each in its historical context. With each method, we’ll keep an eye out for present applications and the difficulty of doing so. We’ll discuss why there’s so much buggy software in the world. I expect there will be talk of spaceships a bit. By the end of this talk you ought to be able to make reasoned decisions about applying correctness methods in your own work and have a good shot at building better software.

(Moonconf 2016) Fetching Moths from the Works: Correctness Methods in Software from Brian Troutwine

]]> 1180 5 https://cdn.slidesharecdn.com/ss_thumbnails/ufiffjehqtafemsogh8o-signature-494aac54aad5d0ee19721f4acf1f2cb28b9e2f5131c41c38046d03c9e129445c-poli-160526215928-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Getting Uphill on a Candle: Crushed Spines, Detached Retinas and One Small Step /slideshow/getting-uphill-on-a-candle-crushed-spines-detached-retinas-and-one-small-step/55328297 5p4dyu3otngy8iurl8vl-signature-eeeb483a46063e2c7b39b08c665d1b98101fa6e8a76ecbb69a007311e66f74fb-poli-151120092529-lva1-app6892
Looking back through history, we often view NASA’s early mission in terms of “getting to the Moon”, discussing how this or that program served the purpose of answering Kennedy’s challenge. This is wrong-headed. In this talk I will discuss aeronautics research beginning with the Writght Brothers and ending with the first Shuttle launch in 1981. We’ll see how NASA is an organization whose primary mission is basic research and development in aeronautics for the benefit of the public at large and space exploration. We’ll see how the Lunar Program was a focusing of research to a practical, political aim which built off decades of basic research and necessarily side-lined other programs. It’s my aim to convince you that Moonshot projects cannot be considered independently of their organizations and its history.]]>
Looking back through history, we often view NASA’s early mission in terms of “getting to the Moon”, discussing how this or that program served the purpose of answering Kennedy’s challenge. This is wrong-headed. In this talk I will discuss aeronautics research beginning with the Writght Brothers and ending with the first Shuttle launch in 1981. We’ll see how NASA is an organization whose primary mission is basic research and development in aeronautics for the benefit of the public at large and space exploration. We’ll see how the Lunar Program was a focusing of research to a practical, political aim which built off decades of basic research and necessarily side-lined other programs. It’s my aim to convince you that Moonshot projects cannot be considered independently of their organizations and its history.]]> Fri, 20 Nov 2015 09:25:29 GMT /slideshow/getting-uphill-on-a-candle-crushed-spines-detached-retinas-and-one-small-step/55328297 BrianTroutwine1@slideshare.net(BrianTroutwine1) Getting Uphill on a Candle: Crushed Spines, Detached Retinas and One Small Step BrianTroutwine1 Looking back through history, we often view NASA’s early mission in terms of “getting to the Moon”, discussing how this or that program served the purpose of answering Kennedy’s challenge. This is wrong-headed. In this talk I will discuss aeronautics research beginning with the Writght Brothers and ending with the first Shuttle launch in 1981. We’ll see how NASA is an organization whose primary mission is basic research and development in aeronautics for the benefit of the public at large and space exploration. We’ll see how the Lunar Program was a focusing of research to a practical, political aim which built off decades of basic research and necessarily side-lined other programs. It’s my aim to convince you that Moonshot projects cannot be considered independently of their organizations and its history. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/5p4dyu3otngy8iurl8vl-signature-eeeb483a46063e2c7b39b08c665d1b98101fa6e8a76ecbb69a007311e66f74fb-poli-151120092529-lva1-app6892-thumbnail.jpg?width=120&height=120&fit=bounds" /> Looking back through history, we often view NASA’s early mission in terms of “getting to the Moon”, discussing how this or that program served the purpose of answering Kennedy’s challenge. This is wrong-headed. In this talk I will discuss aeronautics research beginning with the Writght Brothers and ending with the first Shuttle launch in 1981. We’ll see how NASA is an organization whose primary mission is basic research and development in aeronautics for the benefit of the public at large and space exploration. We’ll see how the Lunar Program was a focusing of research to a practical, political aim which built off decades of basic research and necessarily side-lined other programs. It’s my aim to convince you that Moonshot projects cannot be considered independently of their organizations and its history.

Getting Uphill on a Candle: Crushed Spines, Detached Retinas and One Small Step from Brian Troutwine

]]> 1069 14 https://cdn.slidesharecdn.com/ss_thumbnails/5p4dyu3otngy8iurl8vl-signature-eeeb483a46063e2c7b39b08c665d1b98101fa6e8a76ecbb69a007311e66f74fb-poli-151120092529-lva1-app6892-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 The Charming Genius of the Apollo Guidance Computer /slideshow/the-charming-genius-of-the-apollo-guidance-computer/54692622 wj17z3vfregpyf8lrwrn-signature-1c7a655fe99cdf2416680d27d80b1684f27d545764e3a1b9225c6793cbee327d-poli-151103151304-lva1-app6892
The Apollo Project was the first flight system to deploy with a digital, general-purpose computer made of integrated circuits at its core: the Apollo Guidance Computer (AGC). It was a complete research project: no IC computer had run consecutively for more than a few hours, sophisticated programming techniques were unknown and the interactive human/computer interface had to be invented and made to appeal to astronauts opposed to machine interference in flight operations. In this talk I'll give the historical context for the AGC, discuss its initial design and the evolution of this design as the Apollo Project progressed. We'll do a deep-dive on the machine architecture and note how tight integration with a special-purpose vehicle admitted incredibly sophisticated behaviour from a primitive machine. We'll further discuss the human/computer interface for the AGC, how the astronaut's flight roles dictated the computer's role and vice versa. Motivating examples from select Apollo flights will be used. Throughout, we'll keep an eye on lessons to be gleaned from the experience of engineering the AGC and how we can adapt these lessons to modern computer systems in mission-critical deployments.]]>
The Apollo Project was the first flight system to deploy with a digital, general-purpose computer made of integrated circuits at its core: the Apollo Guidance Computer (AGC). It was a complete research project: no IC computer had run consecutively for more than a few hours, sophisticated programming techniques were unknown and the interactive human/computer interface had to be invented and made to appeal to astronauts opposed to machine interference in flight operations. In this talk I'll give the historical context for the AGC, discuss its initial design and the evolution of this design as the Apollo Project progressed. We'll do a deep-dive on the machine architecture and note how tight integration with a special-purpose vehicle admitted incredibly sophisticated behaviour from a primitive machine. We'll further discuss the human/computer interface for the AGC, how the astronaut's flight roles dictated the computer's role and vice versa. Motivating examples from select Apollo flights will be used. Throughout, we'll keep an eye on lessons to be gleaned from the experience of engineering the AGC and how we can adapt these lessons to modern computer systems in mission-critical deployments.]]> Tue, 03 Nov 2015 15:13:04 GMT /slideshow/the-charming-genius-of-the-apollo-guidance-computer/54692622 BrianTroutwine1@slideshare.net(BrianTroutwine1) The Charming Genius of the Apollo Guidance Computer BrianTroutwine1 The Apollo Project was the first flight system to deploy with a digital, general-purpose computer made of integrated circuits at its core: the Apollo Guidance Computer (AGC). It was a complete research project: no IC computer had run consecutively for more than a few hours, sophisticated programming techniques were unknown and the interactive human/computer interface had to be invented and made to appeal to astronauts opposed to machine interference in flight operations. In this talk I'll give the historical context for the AGC, discuss its initial design and the evolution of this design as the Apollo Project progressed. We'll do a deep-dive on the machine architecture and note how tight integration with a special-purpose vehicle admitted incredibly sophisticated behaviour from a primitive machine. We'll further discuss the human/computer interface for the AGC, how the astronaut's flight roles dictated the computer's role and vice versa. Motivating examples from select Apollo flights will be used. Throughout, we'll keep an eye on lessons to be gleaned from the experience of engineering the AGC and how we can adapt these lessons to modern computer systems in mission-critical deployments. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/wj17z3vfregpyf8lrwrn-signature-1c7a655fe99cdf2416680d27d80b1684f27d545764e3a1b9225c6793cbee327d-poli-151103151304-lva1-app6892-thumbnail.jpg?width=120&height=120&fit=bounds" /> The Apollo Project was the first flight system to deploy with a digital, general-purpose computer made of integrated circuits at its core: the Apollo Guidance Computer (AGC). It was a complete research project: no IC computer had run consecutively for more than a few hours, sophisticated programming techniques were unknown and the interactive human/computer interface had to be invented and made to appeal to astronauts opposed to machine interference in flight operations. In this talk I'll give the historical context for the AGC, discuss its initial design and the evolution of this design as the Apollo Project progressed. We'll do a deep-dive on the machine architecture and note how tight integration with a special-purpose vehicle admitted incredibly sophisticated behaviour from a primitive machine. We'll further discuss the human/computer interface for the AGC, how the astronaut's flight roles dictated the computer's role and vice versa. Motivating examples from select Apollo flights will be used. Throughout, we'll keep an eye on lessons to be gleaned from the experience of engineering the AGC and how we can adapt these lessons to modern computer systems in mission-critical deployments.

The Charming Genius of the Apollo Guidance Computer from Brian Troutwine

]]> 52383 101 https://cdn.slidesharecdn.com/ss_thumbnails/wj17z3vfregpyf8lrwrn-signature-1c7a655fe99cdf2416680d27d80b1684f27d545764e3a1b9225c6793cbee327d-poli-151103151304-lva1-app6892-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 How to Make Systems That (Probably) Won't Fall Over /slideshow/2015-lambda-conf-faulttolerance-on-the-cheap/48527978 r2a6fbacs2gsuzxcureq-signature-1f1b1cbe410f274bddf509fd32d89f21d42ff167cb9c3d33c1809f32c7bc7e96-poli-150524005544-lva1-app6891
Building computer systems that are reliable is hard. The functional programming community has invested a lot of time and energy into up-front-correctness guarantees: types and the like. Unfortunately, absolutely correct software is time-consuming to write and expensive as a result. Fault-tolerant systems achieve system-total reliability by accepting that sub-components will fail and planning for that failure as a first-class concern of the system. As companies embrace the wave of "as-a-service" architectures, failure of sub-systems become a more pressing concern. Using examples from heavy industry, aeronautics and telecom systems, this talk will explore how you can design for fault-tolerance and how functional programming techniques get us most of the way there.]]>
Building computer systems that are reliable is hard. The functional programming community has invested a lot of time and energy into up-front-correctness guarantees: types and the like. Unfortunately, absolutely correct software is time-consuming to write and expensive as a result. Fault-tolerant systems achieve system-total reliability by accepting that sub-components will fail and planning for that failure as a first-class concern of the system. As companies embrace the wave of "as-a-service" architectures, failure of sub-systems become a more pressing concern. Using examples from heavy industry, aeronautics and telecom systems, this talk will explore how you can design for fault-tolerance and how functional programming techniques get us most of the way there.]]> Sun, 24 May 2015 00:55:43 GMT /slideshow/2015-lambda-conf-faulttolerance-on-the-cheap/48527978 BrianTroutwine1@slideshare.net(BrianTroutwine1) Fault-tolerance on the Cheap: Making Systems That (Probably) Won't Fall Over BrianTroutwine1 Building computer systems that are reliable is hard. The functional programming community has invested a lot of time and energy into up-front-correctness guarantees: types and the like. Unfortunately, absolutely correct software is time-consuming to write and expensive as a result. Fault-tolerant systems achieve system-total reliability by accepting that sub-components will fail and planning for that failure as a first-class concern of the system. As companies embrace the wave of "as-a-service" architectures, failure of sub-systems become a more pressing concern. Using examples from heavy industry, aeronautics and telecom systems, this talk will explore how you can design for fault-tolerance and how functional programming techniques get us most of the way there. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/r2a6fbacs2gsuzxcureq-signature-1f1b1cbe410f274bddf509fd32d89f21d42ff167cb9c3d33c1809f32c7bc7e96-poli-150524005544-lva1-app6891-thumbnail.jpg?width=120&height=120&fit=bounds" /> Building computer systems that are reliable is hard. The functional programming community has invested a lot of time and energy into up-front-correctness guarantees: types and the like. Unfortunately, absolutely correct software is time-consuming to write and expensive as a result. Fault-tolerant systems achieve system-total reliability by accepting that sub-components will fail and planning for that failure as a first-class concern of the system. As companies embrace the wave of "as-a-service" architectures, failure of sub-systems become a more pressing concern. Using examples from heavy industry, aeronautics and telecom systems, this talk will explore how you can design for fault-tolerance and how functional programming techniques get us most of the way there.

Fault-tolerance on the Cheap: Making Systems That (Probably) Won't Fall Over from Brian Troutwine

]]> 2370 7 https://cdn.slidesharecdn.com/ss_thumbnails/r2a6fbacs2gsuzxcureq-signature-1f1b1cbe410f274bddf509fd32d89f21d42ff167cb9c3d33c1809f32c7bc7e96-poli-150524005544-lva1-app6891-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Monitoring Complex Systems: Keeping Your Head on Straight in a Hard World /slideshow/erlang-factory-berlin-monitoring-complex-systems-keeping-your-head-on-straight-in-a-hard-world/42877590 rlkmzgnrsimqh3s7hmm1-signature-820b6eaea8d8e6f84813c6e807f4831f8ada63670b88bfcc28c29b17ab2a1546-poli-141219122037-conversion-gate02
This talk will provide motivation for the extensive instrumentation of complex computer systems and make the argument that such systems. This talk will provide practical starting points in Erlang projects and maintain a perspective on the human organization around the computer system. Brian will focus on getting started with instrumentation in a systematic way and follow up with the challenge of interpreting and acting on metrics emitted from a production system in a way which does not overwhelm operators’ ability to effectively control or prioritize faults in the system. He’ll use historical examples and case studies from my work to keep the talk anchored in the practical. Talk objectives: Brian hopes to convince the audience of two things: * that monitoring and instrumentation is an essential component of any long-lived system and * that it's not so hard to get started, after all. He’ll keep a clear-eyed view of what works and is difficult in practice so that the audience can make a reasoned decision after the talk. Target audience: This talk would appeal to engineers with long-running production employments, operations folks and Erlangers in general.]]>
This talk will provide motivation for the extensive instrumentation of complex computer systems and make the argument that such systems. This talk will provide practical starting points in Erlang projects and maintain a perspective on the human organization around the computer system. Brian will focus on getting started with instrumentation in a systematic way and follow up with the challenge of interpreting and acting on metrics emitted from a production system in a way which does not overwhelm operators’ ability to effectively control or prioritize faults in the system. He’ll use historical examples and case studies from my work to keep the talk anchored in the practical. Talk objectives: Brian hopes to convince the audience of two things: * that monitoring and instrumentation is an essential component of any long-lived system and * that it's not so hard to get started, after all. He’ll keep a clear-eyed view of what works and is difficult in practice so that the audience can make a reasoned decision after the talk. Target audience: This talk would appeal to engineers with long-running production employments, operations folks and Erlangers in general.]]> Fri, 19 Dec 2014 12:20:37 GMT /slideshow/erlang-factory-berlin-monitoring-complex-systems-keeping-your-head-on-straight-in-a-hard-world/42877590 BrianTroutwine1@slideshare.net(BrianTroutwine1) Monitoring Complex Systems: Keeping Your Head on Straight in a Hard World BrianTroutwine1 This talk will provide motivation for the extensive instrumentation of complex computer systems and make the argument that such systems. This talk will provide practical starting points in Erlang projects and maintain a perspective on the human organization around the computer system. Brian will focus on getting started with instrumentation in a systematic way and follow up with the challenge of interpreting and acting on metrics emitted from a production system in a way which does not overwhelm operators’ ability to effectively control or prioritize faults in the system. He’ll use historical examples and case studies from my work to keep the talk anchored in the practical. Talk objectives: Brian hopes to convince the audience of two things: * that monitoring and instrumentation is an essential component of any long-lived system and * that it's not so hard to get started, after all. He’ll keep a clear-eyed view of what works and is difficult in practice so that the audience can make a reasoned decision after the talk. Target audience: This talk would appeal to engineers with long-running production employments, operations folks and Erlangers in general. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/rlkmzgnrsimqh3s7hmm1-signature-820b6eaea8d8e6f84813c6e807f4831f8ada63670b88bfcc28c29b17ab2a1546-poli-141219122037-conversion-gate02-thumbnail.jpg?width=120&height=120&fit=bounds" /> This talk will provide motivation for the extensive instrumentation of complex computer systems and make the argument that such systems. This talk will provide practical starting points in Erlang projects and maintain a perspective on the human organization around the computer system. Brian will focus on getting started with instrumentation in a systematic way and follow up with the challenge of interpreting and acting on metrics emitted from a production system in a way which does not overwhelm operators’ ability to effectively control or prioritize faults in the system. He’ll use historical examples and case studies from my work to keep the talk anchored in the practical. Talk objectives: Brian hopes to convince the audience of two things: * that monitoring and instrumentation is an essential component of any long-lived system and * that it's not so hard to get started, after all. He’ll keep a clear-eyed view of what works and is difficult in practice so that the audience can make a reasoned decision after the talk. Target audience: This talk would appeal to engineers with long-running production employments, operations folks and Erlangers in general.

Monitoring Complex Systems: Keeping Your Head on Straight in a Hard World from Brian Troutwine

]]> 2019 2 https://cdn.slidesharecdn.com/ss_thumbnails/rlkmzgnrsimqh3s7hmm1-signature-820b6eaea8d8e6f84813c6e807f4831f8ada63670b88bfcc28c29b17ab2a1546-poli-141219122037-conversion-gate02-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Let it crash! The Erlang Approach to Building Reliable Services /slideshow/let-it-crash-the-erlang-approach-to-building-reliable-services/41269108 ihsxk3krsqii1wjctsza-signature-bdf4b6e9aea020413bdbb63d28232decb4af4c85ddd1d0333fd7bf372d0d53d7-poli-141107125545-conversion-gate01
In this talk, using the Erlang hacker's semi-official motto "Let it Crash!" as a lens, I'll speak to how radical simplicity of implementation, straight-forward runtime characteristics and discoverability of the running system lead to computer systems which have great success in networked, always-on deployments. I will argue that while Erlang natively implements many features which aid the construction of such systems--functional programming language semantics, lack of global mutable state, first-class networking, for instance--these characteristics can be replicated in any computer system, as a part of initial design of new systems or the gradual evolution of an existing project. I'll discuss common design patterns and anti-patterns, using my own work at AdRoll and project experience reports from a variety of fields--both successes and failures--to advance my argument. This will be a very practical talk and will be accessible to engineers of all backgrounds.]]>
In this talk, using the Erlang hacker's semi-official motto "Let it Crash!" as a lens, I'll speak to how radical simplicity of implementation, straight-forward runtime characteristics and discoverability of the running system lead to computer systems which have great success in networked, always-on deployments. I will argue that while Erlang natively implements many features which aid the construction of such systems--functional programming language semantics, lack of global mutable state, first-class networking, for instance--these characteristics can be replicated in any computer system, as a part of initial design of new systems or the gradual evolution of an existing project. I'll discuss common design patterns and anti-patterns, using my own work at AdRoll and project experience reports from a variety of fields--both successes and failures--to advance my argument. This will be a very practical talk and will be accessible to engineers of all backgrounds.]]> Fri, 07 Nov 2014 12:55:45 GMT /slideshow/let-it-crash-the-erlang-approach-to-building-reliable-services/41269108 BrianTroutwine1@slideshare.net(BrianTroutwine1) Let it crash! The Erlang Approach to Building Reliable Services BrianTroutwine1 In this talk, using the Erlang hacker's semi-official motto "Let it Crash!" as a lens, I'll speak to how radical simplicity of implementation, straight-forward runtime characteristics and discoverability of the running system lead to computer systems which have great success in networked, always-on deployments. I will argue that while Erlang natively implements many features which aid the construction of such systems--functional programming language semantics, lack of global mutable state, first-class networking, for instance--these characteristics can be replicated in any computer system, as a part of initial design of new systems or the gradual evolution of an existing project. I'll discuss common design patterns and anti-patterns, using my own work at AdRoll and project experience reports from a variety of fields--both successes and failures--to advance my argument. This will be a very practical talk and will be accessible to engineers of all backgrounds. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/ihsxk3krsqii1wjctsza-signature-bdf4b6e9aea020413bdbb63d28232decb4af4c85ddd1d0333fd7bf372d0d53d7-poli-141107125545-conversion-gate01-thumbnail.jpg?width=120&height=120&fit=bounds" /> In this talk, using the Erlang hacker's semi-official motto "Let it Crash!" as a lens, I'll speak to how radical simplicity of implementation, straight-forward runtime characteristics and discoverability of the running system lead to computer systems which have great success in networked, always-on deployments. I will argue that while Erlang natively implements many features which aid the construction of such systems--functional programming language semantics, lack of global mutable state, first-class networking, for instance--these characteristics can be replicated in any computer system, as a part of initial design of new systems or the gradual evolution of an existing project. I'll discuss common design patterns and anti-patterns, using my own work at AdRoll and project experience reports from a variety of fields--both successes and failures--to advance my argument. This will be a very practical talk and will be accessible to engineers of all backgrounds.

Let it crash! The Erlang Approach to Building Reliable Services from Brian Troutwine

]]> 5332 13 https://cdn.slidesharecdn.com/ss_thumbnails/ihsxk3krsqii1wjctsza-signature-bdf4b6e9aea020413bdbb63d28232decb4af4c85ddd1d0333fd7bf372d0d53d7-poli-141107125545-conversion-gate01-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Automation With Humans in Mind: Making Complex Systems Predictable, Reliable and Humane /slideshow/automation-with-humans-in-mind-making-complex-systems-predictable-reliable-and-humane/40817653 1qh0b3gwr6qw3kan6ecq-signature-074c46e188b13cc334307f2462b5e74751870fe655557f9586439a399a3df937-poli-141028082233-conversion-gate02
I believe that our current approach to designing software systems is driving society in a bad direction. In particular, I believe we are creating a society predicated on automation which is oriented to be serviced by humans or, requiring no service, is simply in control of humans. Ignoring the dystopian overtones of this, I argue that this is a technically flawed approach, that such automation is less reliable, less flexible and less robust through time than a system designed with humans as the controlling party in mind. I will argue--with a mix of personal experience, reference to academic literature and historical examples--that complex systems designed with human control in mind are more lasting through time, more technically excellent and just generally more useful. I will further argue that a re-orientation toward human supremacy in computer systems is especially important as we begin to tightly couple western civilization's technology to the internet, being the Internet of Things. I'll talk a bit about the political and social implications, as well, after I've made a purely technical argument.]]>
I believe that our current approach to designing software systems is driving society in a bad direction. In particular, I believe we are creating a society predicated on automation which is oriented to be serviced by humans or, requiring no service, is simply in control of humans. Ignoring the dystopian overtones of this, I argue that this is a technically flawed approach, that such automation is less reliable, less flexible and less robust through time than a system designed with humans as the controlling party in mind. I will argue--with a mix of personal experience, reference to academic literature and historical examples--that complex systems designed with human control in mind are more lasting through time, more technically excellent and just generally more useful. I will further argue that a re-orientation toward human supremacy in computer systems is especially important as we begin to tightly couple western civilization's technology to the internet, being the Internet of Things. I'll talk a bit about the political and social implications, as well, after I've made a purely technical argument.]]> Tue, 28 Oct 2014 08:22:33 GMT /slideshow/automation-with-humans-in-mind-making-complex-systems-predictable-reliable-and-humane/40817653 BrianTroutwine1@slideshare.net(BrianTroutwine1) Automation With Humans in Mind: Making Complex Systems Predictable, Reliable and Humane BrianTroutwine1 I believe that our current approach to designing software systems is driving society in a bad direction. In particular, I believe we are creating a society predicated on automation which is oriented to be serviced by humans or, requiring no service, is simply in control of humans. Ignoring the dystopian overtones of this, I argue that this is a technically flawed approach, that such automation is less reliable, less flexible and less robust through time than a system designed with humans as the controlling party in mind. I will argue--with a mix of personal experience, reference to academic literature and historical examples--that complex systems designed with human control in mind are more lasting through time, more technically excellent and just generally more useful. I will further argue that a re-orientation toward human supremacy in computer systems is especially important as we begin to tightly couple western civilization's technology to the internet, being the Internet of Things. I'll talk a bit about the political and social implications, as well, after I've made a purely technical argument. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/1qh0b3gwr6qw3kan6ecq-signature-074c46e188b13cc334307f2462b5e74751870fe655557f9586439a399a3df937-poli-141028082233-conversion-gate02-thumbnail.jpg?width=120&height=120&fit=bounds" /> I believe that our current approach to designing software systems is driving society in a bad direction. In particular, I believe we are creating a society predicated on automation which is oriented to be serviced by humans or, requiring no service, is simply in control of humans. Ignoring the dystopian overtones of this, I argue that this is a technically flawed approach, that such automation is less reliable, less flexible and less robust through time than a system designed with humans as the controlling party in mind. I will argue--with a mix of personal experience, reference to academic literature and historical examples--that complex systems designed with human control in mind are more lasting through time, more technically excellent and just generally more useful. I will further argue that a re-orientation toward human supremacy in computer systems is especially important as we begin to tightly couple western civilization's technology to the internet, being the Internet of Things. I'll talk a bit about the political and social implications, as well, after I've made a purely technical argument.

Automation With Humans in Mind: Making Complex Systems Predictable, Reliable and Humane from Brian Troutwine

]]> 6412 6 https://cdn.slidesharecdn.com/ss_thumbnails/1qh0b3gwr6qw3kan6ecq-signature-074c46e188b13cc334307f2462b5e74751870fe655557f9586439a399a3df937-poli-141028082233-conversion-gate02-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Monitoring Complex Systems - Chicago Erlang, 2014 /slideshow/monitoring-complex-systems-chicago-erlang-2014/39393898 chicagoerlang-monitoringcomplexsystems-140922153538-phpapp01
Imagine being responsible for monitoring 100 servers. Now imagine 1000. Each server has 100 different things to keep track of. What do you pay attention to and what do you ignore? What is important? In this talk Brian will show how Erlang can be used to capture more information without compromising clarity — i.e. to keep track of the forest without loosing site of the trees!]]>
Imagine being responsible for monitoring 100 servers. Now imagine 1000. Each server has 100 different things to keep track of. What do you pay attention to and what do you ignore? What is important? In this talk Brian will show how Erlang can be used to capture more information without compromising clarity — i.e. to keep track of the forest without loosing site of the trees!]]> Mon, 22 Sep 2014 15:35:38 GMT /slideshow/monitoring-complex-systems-chicago-erlang-2014/39393898 BrianTroutwine1@slideshare.net(BrianTroutwine1) Monitoring Complex Systems - Chicago Erlang, 2014 BrianTroutwine1 Imagine being responsible for monitoring 100 servers. Now imagine 1000. Each server has 100 different things to keep track of. What do you pay attention to and what do you ignore? What is important? In this talk Brian will show how Erlang can be used to capture more information without compromising clarity — i.e. to keep track of the forest without loosing site of the trees! <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/chicagoerlang-monitoringcomplexsystems-140922153538-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /> Imagine being responsible for monitoring 100 servers. Now imagine 1000. Each server has 100 different things to keep track of. What do you pay attention to and what do you ignore? What is important? In this talk Brian will show how Erlang can be used to capture more information without compromising clarity — i.e. to keep track of the forest without loosing site of the trees!

Monitoring Complex Systems - Chicago Erlang, 2014 from Brian Troutwine

]]> 2309 2 https://cdn.slidesharecdn.com/ss_thumbnails/chicagoerlang-monitoringcomplexsystems-140922153538-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Erlang, LFE, Joxa and Elixir: Established and Emerging Languages in the Erlang Ecosystem /slideshow/erlang-lfe-elixir-and-joxa-oscon-2014/37301498 erlanglfeelixirandjoxa-oscon2014-140723190059-phpapp01
This is a talk comparing the language philosophies of Erlang, LFE, Joxa and Elixir: the languages which target the erlang virtual machine (BEAM). ]]>
This is a talk comparing the language philosophies of Erlang, LFE, Joxa and Elixir: the languages which target the erlang virtual machine (BEAM). ]]> Wed, 23 Jul 2014 19:00:59 GMT /slideshow/erlang-lfe-elixir-and-joxa-oscon-2014/37301498 BrianTroutwine1@slideshare.net(BrianTroutwine1) Erlang, LFE, Joxa and Elixir: Established and Emerging Languages in the Erlang Ecosystem BrianTroutwine1 This is a talk comparing the language philosophies of Erlang, LFE, Joxa and Elixir: the languages which target the erlang virtual machine (BEAM). <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/erlanglfeelixirandjoxa-oscon2014-140723190059-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /> This is a talk comparing the language philosophies of Erlang, LFE, Joxa and Elixir: the languages which target the erlang virtual machine (BEAM).

Erlang, LFE, Joxa and Elixir: Established and Emerging Languages in the Erlang Ecosystem from Brian Troutwine

]]> 8588 14 https://cdn.slidesharecdn.com/ss_thumbnails/erlanglfeelixirandjoxa-oscon2014-140723190059-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Instrumentation as a Living Documentation: Teaching Humans About Complex Systems /slideshow/instrumentation-as-a-living-documentation-teaching-humans-about-complex-systems/34419273 writethedocs-may2014-140507220356-phpapp01
Instrumentation of Complex Systems is necessary and addresses the issues of static documentation of said systems. Instrumentation is flawed, flaws which are resolvable with an intentional kind of documentation. Given at Write the Docs, Portland OR 2014.]]>
Instrumentation of Complex Systems is necessary and addresses the issues of static documentation of said systems. Instrumentation is flawed, flaws which are resolvable with an intentional kind of documentation. Given at Write the Docs, Portland OR 2014.]]> Wed, 07 May 2014 22:03:56 GMT /slideshow/instrumentation-as-a-living-documentation-teaching-humans-about-complex-systems/34419273 BrianTroutwine1@slideshare.net(BrianTroutwine1) Instrumentation as a Living Documentation: Teaching Humans About Complex Systems BrianTroutwine1 Instrumentation of Complex Systems is necessary and addresses the issues of static documentation of said systems. Instrumentation is flawed, flaws which are resolvable with an intentional kind of documentation. Given at Write the Docs, Portland OR 2014. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/writethedocs-may2014-140507220356-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /> Instrumentation of Complex Systems is necessary and addresses the issues of static documentation of said systems. Instrumentation is flawed, flaws which are resolvable with an intentional kind of documentation. Given at Write the Docs, Portland OR 2014.

Instrumentation as a Living Documentation: Teaching Humans About Complex Systems from Brian Troutwine

]]> 4478 14 https://cdn.slidesharecdn.com/ss_thumbnails/writethedocs-may2014-140507220356-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 10 Billion a Day, 100 Milliseconds Per: Monitoring Real-Time Bidding at AdRoll /slideshow/10-billion-a-day-100-milliseconds-per-monitoring-realtime-bidding-at-adroll/32007581 erlangfactory2014-monitoringtalk-140306151206-phpapp01
This is the talk I gave at Erlang Factory SF Bay Area 2014. In it I discussed the instrumentation by default approach taken in the AdRoll real-time bidding team, discuss the technical details of the libraries we use and lessons learned to adapt your organization to deal with the onslaught of data from instrumentation.]]>
This is the talk I gave at Erlang Factory SF Bay Area 2014. In it I discussed the instrumentation by default approach taken in the AdRoll real-time bidding team, discuss the technical details of the libraries we use and lessons learned to adapt your organization to deal with the onslaught of data from instrumentation.]]> Thu, 06 Mar 2014 15:12:06 GMT /slideshow/10-billion-a-day-100-milliseconds-per-monitoring-realtime-bidding-at-adroll/32007581 BrianTroutwine1@slideshare.net(BrianTroutwine1) 10 Billion a Day, 100 Milliseconds Per: Monitoring Real-Time Bidding at AdRoll BrianTroutwine1 This is the talk I gave at Erlang Factory SF Bay Area 2014. In it I discussed the instrumentation by default approach taken in the AdRoll real-time bidding team, discuss the technical details of the libraries we use and lessons learned to adapt your organization to deal with the onslaught of data from instrumentation. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/erlangfactory2014-monitoringtalk-140306151206-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /> This is the talk I gave at Erlang Factory SF Bay Area 2014. In it I discussed the instrumentation by default approach taken in the AdRoll real-time bidding team, discuss the technical details of the libraries we use and lessons learned to adapt your organization to deal with the onslaught of data from instrumentation.

10 Billion a Day, 100 Milliseconds Per: Monitoring Real-Time Bidding at AdRoll from Brian Troutwine

]]> 8808 7 https://cdn.slidesharecdn.com/ss_thumbnails/erlangfactory2014-monitoringtalk-140306151206-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Monitoring with exometer at AdRoll /slideshow/monitoring-with-exometer-at-adroll/30711585 monitoringwithexometeratadroll-140201195854-phpapp01
Presentation slides given at Erloung Bay Area, January 2014. The deck is a brief introduction to the Erlang library exometer and gives an overview of my work at AdRoll to increase monitoring and insight of the running real-time bidding system. ]]>
Presentation slides given at Erloung Bay Area, January 2014. The deck is a brief introduction to the Erlang library exometer and gives an overview of my work at AdRoll to increase monitoring and insight of the running real-time bidding system. ]]> Sat, 01 Feb 2014 19:58:54 GMT /slideshow/monitoring-with-exometer-at-adroll/30711585 BrianTroutwine1@slideshare.net(BrianTroutwine1) Monitoring with exometer at AdRoll BrianTroutwine1 Presentation slides given at Erloung Bay Area, January 2014. The deck is a brief introduction to the Erlang library exometer and gives an overview of my work at AdRoll to increase monitoring and insight of the running real-time bidding system. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/monitoringwithexometeratadroll-140201195854-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /> Presentation slides given at Erloung Bay Area, January 2014. The deck is a brief introduction to the Erlang library exometer and gives an overview of my work at AdRoll to increase monitoring and insight of the running real-time bidding system.

Monitoring with exometer at AdRoll from Brian Troutwine

]]> 2469 6 https://cdn.slidesharecdn.com/ss_thumbnails/monitoringwithexometeratadroll-140201195854-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 https://cdn.slidesharecdn.com/profile-photo-BrianTroutwine1-48x48.jpg?cb=1523390087 Erlang developer on the real-time bidding team. The AdRoll RTB system is a firm real-time system running in Amazon's EC2 environment and services approximately 10 billion bidding events per day, about 500,000 a second on average. My primary focus has been monitoring and analysis of the running system, with an eye toward improving performance of the running systems and detecting run-time faults before they develop into serious issues. http://troutwine.us https://cdn.slidesharecdn.com/ss_thumbnails/ufiffjehqtafemsogh8o-signature-494aac54aad5d0ee19721f4acf1f2cb28b9e2f5131c41c38046d03c9e129445c-poli-160526215928-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/moonconf-2016-fetching-moths-from-the-works-correctness-methods-in-software/62445327 (Moonconf 2016) Fetchi... https://cdn.slidesharecdn.com/ss_thumbnails/5p4dyu3otngy8iurl8vl-signature-eeeb483a46063e2c7b39b08c665d1b98101fa6e8a76ecbb69a007311e66f74fb-poli-151120092529-lva1-app6892-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/getting-uphill-on-a-candle-crushed-spines-detached-retinas-and-one-small-step/55328297 Getting Uphill on a Ca... https://cdn.slidesharecdn.com/ss_thumbnails/wj17z3vfregpyf8lrwrn-signature-1c7a655fe99cdf2416680d27d80b1684f27d545764e3a1b9225c6793cbee327d-poli-151103151304-lva1-app6892-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/the-charming-genius-of-the-apollo-guidance-computer/54692622 The Charming Genius of...