Software Engineering Radio - The Podcast for Professional Software Developers

In the first episode on Refactoring we talked about the basic ideas behind refactoring and some base principles why refactoring is a key part of software engineering. Now we move on to more complicated refactorings and discuss three major situations, their problems and possible solutions: advanced refactorings in large projects that can hardly be finished in a few minutes or hours and refactoring in larger teams. Also covered are the refactoring of published APIs and how merciless refactoring could be aligned with backward compatibility of published APIs, and refactorings that affect more than just code like for example database schemas.

In the first episode on Refactoring we talked about the basic ideas behind refactoring and some base principles why refactoring is a key part of software engineering. Now we move on to more complicated refactorings and discuss three major situations, their problems and possible solutions: advanced refactorings in large projects that can hardly be finished in a few minutes or hours and refactoring in larger teams. Also covered are the refactoring of published APIs and how merciless refactoring could be aligned with backward compatibility of published APIs, and refactorings that affect more than just code like for example database schemas.

This episode is an interview with Frank Buschmann, one of the pioneers of the pattern movement in Europe. Michael and Frank discuss how it all began: the first conferences on patterns and the first publications by the Gang-of-Four and the POSA 1 team. Frank then elaborates on the new volumes in the Pattern-Oriented Software Architecture book series - POSA 4 and POSA 5 - and gives some examples from the books. The episode concludes with a general discussion on software design and architecture, and best practices on software development.

This episode is an interview with Frank Buschmann, one of the pioneers of the pattern movement in Europe. Michael and Frank discuss how it all began: the first conferences on patterns and the first publications by the Gang-of-Four and the POSA 1 team. Frank then elaborates on the new volumes in the Pattern-Oriented Software Architecture book series - POSA 4 and POSA 5 - and gives some examples from the books. The episode concludes with a general discussion on software design and architecture, and best practices on software development.

Michael Kircher and Markus Voelter introduce the topic of software product line engineering. They motivate when and why product lines are important to consider and what makes them so special. Further, they introduce some key terminology, such as platform, core asset, feature model, commonality, and variability.

Michael Kircher and Markus Voelter introduce the topic of software product line engineering. They motivate when and why product lines are important to consider and what makes them so special. Further, they introduce some key terminology, such as platform, core asset, feature model, commonality, and variability.

In this episode, we're talking to Obie Fernandez about agile DSL development in Ruby. We started our discussion by defining what a DSL is, the difference between internal and external DSLs as well as the importance of the flexibly syntax of the host language in order to make DSLs worthwhile. We then looked at a couple of real world examples for DSLs, specifically, at Business Natural Languages. We then progressed to the main part of the discussions, which centered around the features of Ruby that are important for building DSLs. These include the flexible handling of parentheses, symbols, blocks as well as literal arrays and hashes. We then discussed Ruby's meta programming feautures and how they are important for building DSLs: instantiation, method_missing callback, class macros, top level functions and sandboxing. Features like eval, class_eval, instance_eval and define_method are also important for DSLs in Ruby, as well as using alias_method for simple AOP.

In this episode, we're talking to Obie Fernandez about agile DSL development in Ruby. We started our discussion by defining what a DSL is, the difference between internal and external DSLs as well as the importance of the flexibly syntax of the host language in order to make DSLs worthwhile. We then looked at a couple of real world examples for DSLs, specifically, at Business Natural Languages. We then progressed to the main part of the discussions, which centered around the features of Ruby that are important for building DSLs. These include the flexible handling of parentheses, symbols, blocks as well as literal arrays and hashes. We then discussed Ruby's meta programming feautures and how they are important for building DSLs: instantiation, method_missing callback, class macros, top level functions and sandboxing. Features like eval, class_eval, instance_eval and define_method are also important for DSLs in Ruby, as well as using alias_method for simple AOP.

In this episode, Arno and Michael take a look at Design by Contract, a programming technique formalized by Bertrand Meyer. The idea is that an interface is more than method signatures - it is also about specifying the expected behavior that implementations must provide. While some languages include direct support for this style of programming, it is a useful mindset when desiging interfaces even without such language features.

In this episode, Arno and Michael take a look at Design by Contract, a programming technique formalized by Bertrand Meyer. The idea is that an interface is more than method signatures - it is also about specifying the expected behavior that implementations must provide. While some languages include direct support for this style of programming, it is a useful mindset when desiging interfaces even without such language features.

This is another episode where we mainly announce topics related to the podcast itself.

This is another episode where we mainly announce topics related to the podcast itself.

In this Episode we talk about dynamic languages for statically-typed minds, or in other words: which are the interesting features people should learn when they go from a langauge such as Java or C# to a language like Python or Ruby. We used Ruby as the concrete example language. We started the discussion about important features with the concept of dynamically changing an object's type and the idea of message passing. We then looked at the concepts of blocks and closures. Next in line is a discussion about functions that create functions as well as currying. This lead into a quick discussion about continuations. Open classes, aliasing and the relationship to AOP was next on our agenda. We then looked considered a somewhat more engineering-oriented view and looked at the importance of testing and what are the best steps of getting from static programming to dynamic programming. Finally, we discussed a bit about the current (as of October 2006) state of dynamic languages on mainstream platforms.

In this Episode we talk about dynamic languages for statically-typed minds, or in other words: which are the interesting features people should learn when they go from a langauge such as Java or C# to a language like Python or Ruby. We used Ruby as the concrete example language. We started the discussion about important features with the concept of dynamically changing an object's type and the idea of message passing. We then looked at the concepts of blocks and closures. Next in line is a discussion about functions that create functions as well as currying. This lead into a quick discussion about continuations. Open classes, aliasing and the relationship to AOP was next on our agenda. We then looked considered a somewhat more engineering-oriented view and looked at the importance of testing and what are the best steps of getting from static programming to dynamic programming. Finally, we discussed a bit about the current (as of October 2006) state of dynamic languages on mainstream platforms.

In this Episode we discuss software architecture evaluation with Dragos Manolescu, an architect at Microsoft's patterns & practices group. We start off the discussion by trying to define what software architecture evaluation is and when and you want to evaluate an architecture in the system's lifecycle. We then make sure evaluators set the expectations for the evaluation process right - it is important to understand that architecture evaluation is typically not primarily a review of the technology decisions made for the architecture. We then discuss the kinds of notations that are useful for describing architectures, and which of these are especially helpful for the evaluator. Next we look at the core of the architecture evaluation task, namely, the integration of the various stakeholders and their views. We also discuss real reviews from reviews that are staged "for show" only. Next in the discussion is a brief look at the tools you can use for architecture evaluation, as well as a closer look at the various methods for achitecture evalualtion proposed by the Software Engineering Institute (SEI). We conclude the discussion by outlining how architecture evaluation fits into an agile development process. ... and finally, we briefly plug the PLOPD5 book, on which Dragos, Markus and James Noble have been working recently :-)