ºÝºÝߣshows by User: MartinGoodwell / http://www.slideshare.net/images/logo.gif ºÝºÝߣshows by User: MartinGoodwell / Thu, 25 Oct 2018 11:31:15 GMT ºÝºÝߣShare feed for ºÝºÝߣshows by User: MartinGoodwell Smart Home - 10 Jahre danach https://de.slideshare.net/slideshow/smart-home-10-jahre-danach/120683573 2018-10techplauscherlsmarthome-181025113115
Technologieplauscherl 24. Oktober 2018 in Linz bei Dynatrace Ich bau mir meine Haussteuerung selber! ... 10 Jahre später Es gab noch keinen Raspberry Pi und der Strom war noch aus Holz. Zwar gab es KNX und Andere, die waren aber aus Preisgründen und mangels Offenheit keine Option für mich. Ich wusste ja damals schon, dass ich selber alles viel besser kann. Der Plan war klar: Java, 1-Wire und Lötkolben Was ich damals noch nicht wusste: Zehn Jahre später sollte davon nicht viel übrig sein...]]>
Technologieplauscherl 24. Oktober 2018 in Linz bei Dynatrace Ich bau mir meine Haussteuerung selber! ... 10 Jahre später Es gab noch keinen Raspberry Pi und der Strom war noch aus Holz. Zwar gab es KNX und Andere, die waren aber aus Preisgründen und mangels Offenheit keine Option für mich. Ich wusste ja damals schon, dass ich selber alles viel besser kann. Der Plan war klar: Java, 1-Wire und Lötkolben Was ich damals noch nicht wusste: Zehn Jahre später sollte davon nicht viel übrig sein...]]> Thu, 25 Oct 2018 11:31:15 GMT https://de.slideshare.net/slideshow/smart-home-10-jahre-danach/120683573 MartinGoodwell@slideshare.net(MartinGoodwell) Smart Home - 10 Jahre danach MartinGoodwell Technologieplauscherl 24. Oktober 2018 in Linz bei Dynatrace Ich bau mir meine Haussteuerung selber! ... 10 Jahre später Es gab noch keinen Raspberry Pi und der Strom war noch aus Holz. Zwar gab es KNX und Andere, die waren aber aus Preisgründen und mangels Offenheit keine Option für mich. Ich wusste ja damals schon, dass ich selber alles viel besser kann. Der Plan war klar: Java, 1-Wire und Lötkolben Was ich damals noch nicht wusste: Zehn Jahre später sollte davon nicht viel übrig sein... <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/2018-10techplauscherlsmarthome-181025113115-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> Technologieplauscherl 24. Oktober 2018 in Linz bei Dynatrace Ich bau mir meine Haussteuerung selber! ... 10 Jahre später Es gab noch keinen Raspberry Pi und der Strom war noch aus Holz. Zwar gab es KNX und Andere, die waren aber aus Preisgründen und mangels Offenheit keine Option für mich. Ich wusste ja damals schon, dass ich selber alles viel besser kann. Der Plan war klar: Java, 1-Wire und Lötkolben Was ich damals noch nicht wusste: Zehn Jahre später sollte davon nicht viel übrig sein...
from Martin Gutenbrunner
]]> 514 40 https://cdn.slidesharecdn.com/ss_thumbnails/2018-10techplauscherlsmarthome-181025113115-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 Old code doesn't stink - Detroit /slideshow/old-code-doesnt-stink-detroit/119640641 oldcodedoesntstink-detroit-181016195730
I've seen projects with shiny, new code render into unmaintainable big balls of mud within 2-3 years. Multiple times. But regardless of whether it's the code base as a whole that's rotten, or whether it's just the UI and User Experience that needs a major overhaul: the question on rewrite vs refactoring will come up sooner or later. Based on years of experience, and a plethora of bad decisions cumulating into epic failures, I'll share my experience on how to have a code base that stays maintainable - even after years. After this talk, you'll have more insight into whether you should refactor or rewrite, and how to do it right from now on.]]>
I've seen projects with shiny, new code render into unmaintainable big balls of mud within 2-3 years. Multiple times. But regardless of whether it's the code base as a whole that's rotten, or whether it's just the UI and User Experience that needs a major overhaul: the question on rewrite vs refactoring will come up sooner or later. Based on years of experience, and a plethora of bad decisions cumulating into epic failures, I'll share my experience on how to have a code base that stays maintainable - even after years. After this talk, you'll have more insight into whether you should refactor or rewrite, and how to do it right from now on.]]> Tue, 16 Oct 2018 19:57:30 GMT /slideshow/old-code-doesnt-stink-detroit/119640641 MartinGoodwell@slideshare.net(MartinGoodwell) Old code doesn't stink - Detroit MartinGoodwell I've seen projects with shiny, new code render into unmaintainable big balls of mud within 2-3 years. Multiple times. But regardless of whether it's the code base as a whole that's rotten, or whether it's just the UI and User Experience that needs a major overhaul: the question on rewrite vs refactoring will come up sooner or later. Based on years of experience, and a plethora of bad decisions cumulating into epic failures, I'll share my experience on how to have a code base that stays maintainable - even after years. After this talk, you'll have more insight into whether you should refactor or rewrite, and how to do it right from now on. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/oldcodedoesntstink-detroit-181016195730-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> I&#39;ve seen projects with shiny, new code render into unmaintainable big balls of mud within 2-3 years. Multiple times. But regardless of whether it&#39;s the code base as a whole that&#39;s rotten, or whether it&#39;s just the UI and User Experience that needs a major overhaul: the question on rewrite vs refactoring will come up sooner or later. Based on years of experience, and a plethora of bad decisions cumulating into epic failures, I&#39;ll share my experience on how to have a code base that stays maintainable - even after years. After this talk, you&#39;ll have more insight into whether you should refactor or rewrite, and how to do it right from now on.
Old code doesn't stink - Detroit from Martin Gutenbrunner
]]> 212 1 https://cdn.slidesharecdn.com/ss_thumbnails/oldcodedoesntstink-detroit-181016195730-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 Old code doesn't stink /slideshow/old-code-doesnt-stink/95207493 oldcodedoesntstink-180427080210
I've seen projects with shiny, new code render into unmaintainable big balls of mud within 2-3 years. Multiple times. But regardless of whether it's the code base as a whole that's rotten, or whether it's just the UI and User Experience that needs a major overhaul: the question on rewrite vs refactoring will come up sooner or later. Based on years of experience, and a plethora of bad decisions cumulating into epic failures, I'll share my experience on how to have a code base that stays maintainable - even after years. After this talk, you'll have more insight into whether you should refactor or rewrite, and how to do it right from now on.]]>
I've seen projects with shiny, new code render into unmaintainable big balls of mud within 2-3 years. Multiple times. But regardless of whether it's the code base as a whole that's rotten, or whether it's just the UI and User Experience that needs a major overhaul: the question on rewrite vs refactoring will come up sooner or later. Based on years of experience, and a plethora of bad decisions cumulating into epic failures, I'll share my experience on how to have a code base that stays maintainable - even after years. After this talk, you'll have more insight into whether you should refactor or rewrite, and how to do it right from now on.]]> Fri, 27 Apr 2018 08:02:10 GMT /slideshow/old-code-doesnt-stink/95207493 MartinGoodwell@slideshare.net(MartinGoodwell) Old code doesn't stink MartinGoodwell I've seen projects with shiny, new code render into unmaintainable big balls of mud within 2-3 years. Multiple times. But regardless of whether it's the code base as a whole that's rotten, or whether it's just the UI and User Experience that needs a major overhaul: the question on rewrite vs refactoring will come up sooner or later. Based on years of experience, and a plethora of bad decisions cumulating into epic failures, I'll share my experience on how to have a code base that stays maintainable - even after years. After this talk, you'll have more insight into whether you should refactor or rewrite, and how to do it right from now on. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/oldcodedoesntstink-180427080210-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> I&#39;ve seen projects with shiny, new code render into unmaintainable big balls of mud within 2-3 years. Multiple times. But regardless of whether it&#39;s the code base as a whole that&#39;s rotten, or whether it&#39;s just the UI and User Experience that needs a major overhaul: the question on rewrite vs refactoring will come up sooner or later. Based on years of experience, and a plethora of bad decisions cumulating into epic failures, I&#39;ll share my experience on how to have a code base that stays maintainable - even after years. After this talk, you&#39;ll have more insight into whether you should refactor or rewrite, and how to do it right from now on.
Old code doesn't stink from Martin Gutenbrunner
]]> 801 2 https://cdn.slidesharecdn.com/ss_thumbnails/oldcodedoesntstink-180427080210-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 DevOne - How to not fail with Azure /slideshow/devone-how-to-not-fail-with-azure/76859721 20170601-devone-170612092221
I made lots of mistakes in my carreer. Here's how the Cloud could have saved me from making them (it just wasn't there back then). ]]>
I made lots of mistakes in my carreer. Here's how the Cloud could have saved me from making them (it just wasn't there back then). ]]> Mon, 12 Jun 2017 09:22:21 GMT /slideshow/devone-how-to-not-fail-with-azure/76859721 MartinGoodwell@slideshare.net(MartinGoodwell) DevOne - How to not fail with Azure MartinGoodwell I made lots of mistakes in my carreer. Here's how the Cloud could have saved me from making them (it just wasn't there back then). <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/20170601-devone-170612092221-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> I made lots of mistakes in my carreer. Here&#39;s how the Cloud could have saved me from making them (it just wasn&#39;t there back then).
DevOne - How to not fail with Azure from Martin Gutenbrunner
]]> 122 3 https://cdn.slidesharecdn.com/ss_thumbnails/20170601-devone-170612092221-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 APIs in production - we built it, can we fix it? /slideshow/apis-in-production-we-built-it-can-we-fix-it/69402501 apisummit2016-161122113434
Operating APIs is complex. This talk introduces open source tools for monitoring, logging and call tracing of API based environments.]]>
Operating APIs is complex. This talk introduces open source tools for monitoring, logging and call tracing of API based environments.]]> Tue, 22 Nov 2016 11:34:33 GMT /slideshow/apis-in-production-we-built-it-can-we-fix-it/69402501 MartinGoodwell@slideshare.net(MartinGoodwell) APIs in production - we built it, can we fix it? MartinGoodwell Operating APIs is complex. This talk introduces open source tools for monitoring, logging and call tracing of API based environments. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/apisummit2016-161122113434-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> Operating APIs is complex. This talk introduces open source tools for monitoring, logging and call tracing of API based environments.
APIs in production - we built it, can we fix it? from Martin Gutenbrunner
]]> 292 2 https://cdn.slidesharecdn.com/ss_thumbnails/apisummit2016-161122113434-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 Pushing the hassle from production to developers. Easily /slideshow/pushing-the-hassle-from-production-to-developers-easily/67778490 devopsdays16ghent-fromopstodev-161028093731
In pre-production, there’s lots of tools that help optimizing your code: debuggers, CI/CD, load tests, etc. There’s even tools that automatically deploy them into production. Plus, engineers usually have a whole sprint as a time frame. Once you’re in production, things are a bit different and all that convenience is just not there for operators. They need to be able to pinpoint trouble spots within minutes. They have to identify the handful of bad requests out of thousands that allows for reproduction of the problem. And then, they are finally required to hand all that information over to the developers as convenient and as soon as possible. And nothing of that is automated. Performance monitoring, call-tracing and visualization are the concepts any developer should know about to be able to provide as much insight as possible into running systems. This session introduces open-source tools that allow devs and ops to work together much closer. To name just a few: * statsd / collectd * Zipkin * Spring-Cloud Sleuth * and some more For the sake of completeness and to also cover the Enterprise user-space, the main commercial vendors in that space will also be mentioned real quick. After that session, you’ll see new ideas popping up inside your head and already have all the knowledge you need to directly jump into planning and implementation.]]>
In pre-production, there’s lots of tools that help optimizing your code: debuggers, CI/CD, load tests, etc. There’s even tools that automatically deploy them into production. Plus, engineers usually have a whole sprint as a time frame. Once you’re in production, things are a bit different and all that convenience is just not there for operators. They need to be able to pinpoint trouble spots within minutes. They have to identify the handful of bad requests out of thousands that allows for reproduction of the problem. And then, they are finally required to hand all that information over to the developers as convenient and as soon as possible. And nothing of that is automated. Performance monitoring, call-tracing and visualization are the concepts any developer should know about to be able to provide as much insight as possible into running systems. This session introduces open-source tools that allow devs and ops to work together much closer. To name just a few: * statsd / collectd * Zipkin * Spring-Cloud Sleuth * and some more For the sake of completeness and to also cover the Enterprise user-space, the main commercial vendors in that space will also be mentioned real quick. After that session, you’ll see new ideas popping up inside your head and already have all the knowledge you need to directly jump into planning and implementation.]]> Fri, 28 Oct 2016 09:37:30 GMT /slideshow/pushing-the-hassle-from-production-to-developers-easily/67778490 MartinGoodwell@slideshare.net(MartinGoodwell) Pushing the hassle from production to developers. Easily MartinGoodwell In pre-production, there’s lots of tools that help optimizing your code: debuggers, CI/CD, load tests, etc. There’s even tools that automatically deploy them into production. Plus, engineers usually have a whole sprint as a time frame. Once you’re in production, things are a bit different and all that convenience is just not there for operators. They need to be able to pinpoint trouble spots within minutes. They have to identify the handful of bad requests out of thousands that allows for reproduction of the problem. And then, they are finally required to hand all that information over to the developers as convenient and as soon as possible. And nothing of that is automated. Performance monitoring, call-tracing and visualization are the concepts any developer should know about to be able to provide as much insight as possible into running systems. This session introduces open-source tools that allow devs and ops to work together much closer. To name just a few: * statsd / collectd * Zipkin * Spring-Cloud Sleuth * and some more For the sake of completeness and to also cover the Enterprise user-space, the main commercial vendors in that space will also be mentioned real quick. After that session, you’ll see new ideas popping up inside your head and already have all the knowledge you need to directly jump into planning and implementation. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/devopsdays16ghent-fromopstodev-161028093731-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> In pre-production, there’s lots of tools that help optimizing your code: debuggers, CI/CD, load tests, etc. There’s even tools that automatically deploy them into production. Plus, engineers usually have a whole sprint as a time frame. Once you’re in production, things are a bit different and all that convenience is just not there for operators. They need to be able to pinpoint trouble spots within minutes. They have to identify the handful of bad requests out of thousands that allows for reproduction of the problem. And then, they are finally required to hand all that information over to the developers as convenient and as soon as possible. And nothing of that is automated. Performance monitoring, call-tracing and visualization are the concepts any developer should know about to be able to provide as much insight as possible into running systems. This session introduces open-source tools that allow devs and ops to work together much closer. To name just a few: * statsd / collectd * Zipkin * Spring-Cloud Sleuth * and some more For the sake of completeness and to also cover the Enterprise user-space, the main commercial vendors in that space will also be mentioned real quick. After that session, you’ll see new ideas popping up inside your head and already have all the knowledge you need to directly jump into planning and implementation.
Pushing the hassle from production to developers. Easily from Martin Gutenbrunner
]]> 374 2 https://cdn.slidesharecdn.com/ss_thumbnails/devopsdays16ghent-fromopstodev-161028093731-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 101 - Leveraging on the power of JMX /slideshow/monitoring-101-leveraging-on-the-power-of-jmx/63809751 monitoringmetrics101-160707115258
While JMX is one of the oldest components of Java (JSR-3), few know about its actual power. This talk gives a short introduction on the basics of monitoring in general, what JMX is and how both, tech and business can benefit from a proper implementation. After this talk, you will know, how to export JMX metrics in your own projects, which common frameworks and libraries also provide JMX metrics and which tools for JMX monitoring are available. This talk contains content for Devs, Ops and Managers, as all of them can benefit from doing monitoring right.]]>
While JMX is one of the oldest components of Java (JSR-3), few know about its actual power. This talk gives a short introduction on the basics of monitoring in general, what JMX is and how both, tech and business can benefit from a proper implementation. After this talk, you will know, how to export JMX metrics in your own projects, which common frameworks and libraries also provide JMX metrics and which tools for JMX monitoring are available. This talk contains content for Devs, Ops and Managers, as all of them can benefit from doing monitoring right.]]> Thu, 07 Jul 2016 11:52:58 GMT /slideshow/monitoring-101-leveraging-on-the-power-of-jmx/63809751 MartinGoodwell@slideshare.net(MartinGoodwell) Monitoring 101 - Leveraging on the power of JMX MartinGoodwell While JMX is one of the oldest components of Java (JSR-3), few know about its actual power. This talk gives a short introduction on the basics of monitoring in general, what JMX is and how both, tech and business can benefit from a proper implementation. After this talk, you will know, how to export JMX metrics in your own projects, which common frameworks and libraries also provide JMX metrics and which tools for JMX monitoring are available. This talk contains content for Devs, Ops and Managers, as all of them can benefit from doing monitoring right. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/monitoringmetrics101-160707115258-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> While JMX is one of the oldest components of Java (JSR-3), few know about its actual power. This talk gives a short introduction on the basics of monitoring in general, what JMX is and how both, tech and business can benefit from a proper implementation. After this talk, you will know, how to export JMX metrics in your own projects, which common frameworks and libraries also provide JMX metrics and which tools for JMX monitoring are available. This talk contains content for Devs, Ops and Managers, as all of them can benefit from doing monitoring right.
Monitoring 101 - Leveraging on the power of JMX from Martin Gutenbrunner
]]> 959 4 https://cdn.slidesharecdn.com/ss_thumbnails/monitoringmetrics101-160707115258-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 Performance monitoring and call tracing in microservice environments /MartinGoodwell/performance-monitoring-and-call-tracing-in-microservice-environments perfmonitoringandcalltracing-160630220242
Performance analysis can easily be done with on-board tools of nearly any programming language. In microservice environments, the real challenge is not in single, high-performing services, but in resiliently running a complex ecosystem of many services.This talk will introduce open-source tools for analysis and call tracing. Concluding, we will briefly get to know Dynatrace Ruxit - a commercial alternative. After this session, the audience will know about how to get started in performance analysis and call-tracing and some according tools.]]>
Performance analysis can easily be done with on-board tools of nearly any programming language. In microservice environments, the real challenge is not in single, high-performing services, but in resiliently running a complex ecosystem of many services.This talk will introduce open-source tools for analysis and call tracing. Concluding, we will briefly get to know Dynatrace Ruxit - a commercial alternative. After this session, the audience will know about how to get started in performance analysis and call-tracing and some according tools.]]> Thu, 30 Jun 2016 22:02:42 GMT /MartinGoodwell/performance-monitoring-and-call-tracing-in-microservice-environments MartinGoodwell@slideshare.net(MartinGoodwell) Performance monitoring and call tracing in microservice environments MartinGoodwell Performance analysis can easily be done with on-board tools of nearly any programming language. In microservice environments, the real challenge is not in single, high-performing services, but in resiliently running a complex ecosystem of many services.This talk will introduce open-source tools for analysis and call tracing. Concluding, we will briefly get to know Dynatrace Ruxit - a commercial alternative. After this session, the audience will know about how to get started in performance analysis and call-tracing and some according tools. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/perfmonitoringandcalltracing-160630220242-thumbnail.jpg?width=120&amp;height=120&amp;fit=bounds" /><br> Performance analysis can easily be done with on-board tools of nearly any programming language. In microservice environments, the real challenge is not in single, high-performing services, but in resiliently running a complex ecosystem of many services.This talk will introduce open-source tools for analysis and call tracing. Concluding, we will briefly get to know Dynatrace Ruxit - a commercial alternative. After this session, the audience will know about how to get started in performance analysis and call-tracing and some according tools.
Performance monitoring and call tracing in microservice environments from Martin Gutenbrunner
]]> 2355 5 https://cdn.slidesharecdn.com/ss_thumbnails/perfmonitoringandcalltracing-160630220242-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 https://public.slidesharecdn.com/v2/images/profile-picture.png https://cdn.slidesharecdn.com/ss_thumbnails/2018-10techplauscherlsmarthome-181025113115-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/smart-home-10-jahre-danach/120683573 Smart Home - 10 Jahre ... https://cdn.slidesharecdn.com/ss_thumbnails/oldcodedoesntstink-detroit-181016195730-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/old-code-doesnt-stink-detroit/119640641 Old code doesn&#39;t stink... https://cdn.slidesharecdn.com/ss_thumbnails/oldcodedoesntstink-180427080210-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/old-code-doesnt-stink/95207493 Old code doesn&#39;t stink