Presentation: 18/02/2014 @ 07:30AM
Perfion · Niels Jernes Vej 8 · DK-9220 Aalborg · Denmark
Tlf Michael Coxeter 31 14 38 84
In this session we will look at re-factoring some code that produces and outputs prime numbers.
There will be focus on finding buried the classes hidden with the the functions and extracting them as first class citizens.
This re-factoring will attempt to result in a number of small well named classes filled with small well named functions, as was described in the previous presentation
Clean Code → Functions
Monday, February 10, 2014
Clean Code → Functions
Presentation: 11/02/2014 @ 07:30AM
Perfion · Niels Jernes Vej 8 · DK-9220 Aalborg · Denmark
Tlf Michael Coxeter 31 14 38 84
How big should a function be? 20 Lines? A screenful? Is there a way to know if your functions are the right size?
Object Oriented Design involves the art of breaking applications into classes. But have you found all the classes in the design of your application? Is there a way to know?
Functions are supposed to do "One Thing", do it well, and do it only. But what is "One Thing". Is there a way to tell if your functions are obeying that rule?
The answer to all these questions is yes! And not just with some fuzzy hand-waving platitudes either. There are fool-proof and unambiguous answers to these questions.
In this episode Uncle Bob (UB) shows you, in no uncertain terms, how to tell if your functions are the right size. He'll show you how to be certain that you've found all the classes in your design. He'll show you where they go to hide, and how to dig them out. And he'll show you what "One Thing" really means, and how to make sure your functions are doing one and only one thing.
This episode is loaded with code; but it's no screencast! Oh you'll see some screencasts, but not in the ordinary way -- not hardly. UB controls these screencasts -- he controls the audio, the video, the speed, and the magnification. He narrates and summarizes and points out the highlights. You'll see what you need to see, without waiting for the typing. In fact, UB compresses two hours of screencasts into three sessions totalling about twenty minutes. So it's a wild ride.
On that ride you'll learn why function size is so important to Object Oriented Design, and also just to plain old good programming. You'll learn the craftsman's way of writing and refactoring functions.
Perfion · Niels Jernes Vej 8 · DK-9220 Aalborg · Denmark
Tlf Michael Coxeter 31 14 38 84
How big should a function be? 20 Lines? A screenful? Is there a way to know if your functions are the right size?
Object Oriented Design involves the art of breaking applications into classes. But have you found all the classes in the design of your application? Is there a way to know?
Functions are supposed to do "One Thing", do it well, and do it only. But what is "One Thing". Is there a way to tell if your functions are obeying that rule?
The answer to all these questions is yes! And not just with some fuzzy hand-waving platitudes either. There are fool-proof and unambiguous answers to these questions.
In this episode Uncle Bob (UB) shows you, in no uncertain terms, how to tell if your functions are the right size. He'll show you how to be certain that you've found all the classes in your design. He'll show you where they go to hide, and how to dig them out. And he'll show you what "One Thing" really means, and how to make sure your functions are doing one and only one thing.
This episode is loaded with code; but it's no screencast! Oh you'll see some screencasts, but not in the ordinary way -- not hardly. UB controls these screencasts -- he controls the audio, the video, the speed, and the magnification. He narrates and summarizes and points out the highlights. You'll see what you need to see, without waiting for the typing. In fact, UB compresses two hours of screencasts into three sessions totalling about twenty minutes. So it's a wild ride.
On that ride you'll learn why function size is so important to Object Oriented Design, and also just to plain old good programming. You'll learn the craftsman's way of writing and refactoring functions.
Monday, February 3, 2014
Register for the ReSharper Webinar
ReSharper is doing a Webinar, showing some secrets in the 8.1 version - hurry and register:
http://blog.jetbrains.com/dotnet/2014/01/29/live-webinar-resharper-secrets-with-igal-tabachnik-february-13th/
http://blog.jetbrains.com/dotnet/2014/01/29/live-webinar-resharper-secrets-with-igal-tabachnik-february-13th/
Monday, January 27, 2014
Clean Code → Names++
Presentation: 28/01/2014 @ 07:30AM
Perfion ∙ Niels Jernes Vej 8 ∙ DK-9220 Aalborg ∙ Denmark
Tlf Michael Coxeter 31 14 38 84
Despite the scenery, Uncle Bob never lets up on driving each point home so they become part of your daily discipline.
He begins with the exhortation that names are not just a convenience for the programmer. They are the most powerful tool that programmers have to communicate with each other.
Then he dives into a discussion on how to use names to Reveal Your Intent and Avoid Disinformation.
From one code example to the next (showing up in the most unlikely places) you'll see Uncle Bob point out examples of bad names and good names. He'll explain why the good names are good, why the bad names are bad, and how to improve them.
Uncle Bob will tell you how encoding schemes like Hungarian Notation began, and why youdon't want to be using them in the twenty-first century. He'll go on to stress the importance of choosing names that make your code read like well written prose.
Finally, Uncle Bob will tell you about The Scope Rule which will guide you in choosing function, class, and variable names of the appropriate length for the scope that contains them.
Perfion ∙ Niels Jernes Vej 8 ∙ DK-9220 Aalborg ∙ Denmark
Tlf Michael Coxeter 31 14 38 84
Despite the scenery, Uncle Bob never lets up on driving each point home so they become part of your daily discipline.
He begins with the exhortation that names are not just a convenience for the programmer. They are the most powerful tool that programmers have to communicate with each other.
Then he dives into a discussion on how to use names to Reveal Your Intent and Avoid Disinformation.
From one code example to the next (showing up in the most unlikely places) you'll see Uncle Bob point out examples of bad names and good names. He'll explain why the good names are good, why the bad names are bad, and how to improve them.
Uncle Bob will tell you how encoding schemes like Hungarian Notation began, and why youdon't want to be using them in the twenty-first century. He'll go on to stress the importance of choosing names that make your code read like well written prose.
Finally, Uncle Bob will tell you about The Scope Rule which will guide you in choosing function, class, and variable names of the appropriate length for the scope that contains them.
Thursday, January 2, 2014
Better Software — No Matter What
Presentation: 02/01/2014 @ 07:30AM
Some development practices improve software quality, regardless of the domain of the application, the language in which it's written, the platform on which it runs, or the users it is intended to serve.
This seminar explores fundamental principles, practices, and standards that improve software quality, no matter what the software does, how it does it, or whom it does it for.
Video
Scott Meyers: Better Software — No Matter What
This seminar explores fundamental principles, practices, and standards that improve software quality, no matter what the software does, how it does it, or whom it does it for.
Video
Monday, December 16, 2013
Video Store Refactor
Presentation: 17/12/2013 @ 07:30AM
This is the famous "Video Store" example from Martin Fowler's wonderful book: Refactoring.
In this hour-long screencast, Uncle Bob (UB) takes it apart one step at a time.
In the end, he will transform this code from a single large function in a group of otherwise empty classes, into a nicely partitioned object oriented design.
UB will tear this code apart, and turn it inside out. He'll use a wide-range of refactoring in order to chop the code up and drag the fragments into the classes that need them.
In the process the tests will be cleaned up, the Single Reponsibility Principle will be enforced, three new classes will be created and populated, and the result will be a much cleaner module. You don't want to miss this one!
Video Store
This is the famous "Video Store" example from Martin Fowler's wonderful book: Refactoring.
In this hour-long screencast, Uncle Bob (UB) takes it apart one step at a time.
In the end, he will transform this code from a single large function in a group of otherwise empty classes, into a nicely partitioned object oriented design.
UB will tear this code apart, and turn it inside out. He'll use a wide-range of refactoring in order to chop the code up and drag the fragments into the classes that need them.
In the process the tests will be cleaned up, the Single Reponsibility Principle will be enforced, three new classes will be created and populated, and the result will be a much cleaner module. You don't want to miss this one!
Wednesday, November 13, 2013
People, Process, Tools – The Essence of DevOps
Presentation: 19/11/2013 @ 07:30AM
DevOps is about making software better – by bringing everyone involved in software closer together, including (but not limited to): domain experts, rchitects, developers, designers, testers, security and operations. This session takes you through the DevOps culture, focusing on people, process and tools (in that order). You’ll learn how to get the conversation started between the teams, how to bring the teams closer together, and how to ultimately become one team (we’re all in this together)! Understanding DevOps is about focusing on what’s important: building and delivering the best software you can.
Video
Richard Campbell
People, Process, Tools – The Essence of DevOps
DevOps is about making software better – by bringing everyone involved in software closer together, including (but not limited to): domain experts, rchitects, developers, designers, testers, security and operations. This session takes you through the DevOps culture, focusing on people, process and tools (in that order). You’ll learn how to get the conversation started between the teams, how to bring the teams closer together, and how to ultimately become one team (we’re all in this together)! Understanding DevOps is about focusing on what’s important: building and delivering the best software you can.
Video
Subscribe to:
Posts (Atom)