The Developer Day | Staying Curious

Archive for June 2010

Jun/10

26

Expert Python Programming Book Review

Expert Python Programming BookI’ve finished reading Expert Python Programming written by Tarek Ziade. This book is written for Python developers who wish to go further in mastering Python. Expert Python Programming covers a range of topics such as generators, meta programming, naming standards, packaging, continuous integration, writing documentation, test driven development, optimizations and design patterns. Even non Python developers will find this book useful since it covers best practices which are well suited to other programming languages.

There’s a sample chapter available which covers the topic of documentation. We all know how frustrating it is to write documentation. It’s boring, often it feels pointless and it tends to get out of date. The 7 rules of technical writing presented in the book changed my mind. It’s actually one of my personal favourite chapters in the book.

The first chapter of the book is very friendly and covers installation of many Python flavours, packaging tools such as EasyInstall and setuptools, prompt customization and choices of editors.

While the first chapter is very easy going the second chapters dives deep into syntactic intricacies of Python with it’s iterators, generators, decorators and context providers. If the second chapter won’t make your head spin then the third one on class level Python best practices certainly will. Author of the book does a great job at explaining the pitfalls of multiple inheritance, inconsistent super usage, Python’s method resolution order and finally meta programming which allows to change classes’ and objects’ definitions on the fly.

The rest of the book is a lot less confusing but nonetheless rewarding. Chapter four gives some very good advice on naming standards, building API’s and tools that ease might help along the way. Chapter five explains how to create python packages, distribute and deploy them.

What I really like in every book is examples. One example can explain more than a thousand words could. The examples in the second and third chapters are very valuable and help greatly to understand the concepts explained. The book goes even further and provides a complete example of a small application called Atomisator. This example is implemented following the best practices of previous five chapters.

Chapters eight and nine will be very interesting to team leads which explain distributed version control systems such as Mercurial, continuous integration and managing software in an iterative way.

Another very important topic on Test Driven Development or TDD is presented in chapter eleven. I cannot emphasize enough how valuable test driven development is. Though even today it’s not a widely adopted practice and not a well understood one either. This book will try to convince you why you should be doing TDD and if you’re already convinced it will present you with tools that you can use to do TDD. I was very interested to find out about the available unit testing framework alternatives. Further an interesting idea on doc testing is described which while seems a little exotic may be a very efficient way to keep your documentation up to date.

Reading further there’s a great chapter on optimization which describes general principles of optimization and various profiling techniques. Measuring performance may prove difficult on different hardware such as local development machines and stage servers. I was very intrigued to find out about pystones and the general concept behind it which helps to deal with the problem described.

Together with optimization techniques, various profiler tools which you never knew of, the book describes some generic optimization solutions available. Some are well known such as the Big-O notation, some are less known such as Cyclomatic Complexity. I think this book explains the concepts behind multi threading, multi processing and caching very well. Making an informed decision whether to use threads or multi processes for your Python application may as well mean if it’s going to be successful or not.

And finally the last chapter talks of design patterns. While it’s not the most mind blowing chapter of the book it provides some very interesting details why Python doesn’t have interfaces or how certain GoF patterns can be implemented in a Python specific way.

Conclusion

Should you read this book? My answer is yes. Especially if Python earns your bread and butter. Not only you will know the syntactic intricacies of python it will introduce you to many must know concepts of software development. Even if you’re not a day to day Python developer but you do write an occasional Python script or application by all means read the book and read the first six chapters. I will go even further and recommend this book to non Python developers. Simply because it explains concepts that every developer should understand. And as an extra it is always interesting to learn new ideas and to see how things can be done differently.

, , Hide

Jun/10

22

DDD Resources / Papers / Presentations

Jun/10

21

What is DDD or Domain Driven Design?

Domain Driven Design can be described as a philosophy based on domain modelling. More accurately it may be be described as a very large body of patterns and pattern language in its own right. The term Domain Driven Design or DDD was coined by Eric Evans the author of the book Domain-Driven Design: Tackling Complexity in the Heart of Software also known in the DDD community as the “blue book”.

Understanding the DDD philosophy

The Domain Driven Design philosophy states:

  • Most software projects should focus on business domain
  • Complex domain designs should be based on a model

To understand the meaning of these statements one has to understand the meaning of domain and model.

Domain is a sphere of knowledge, influence or activity. The subject area to which the user applies a program is the domain of the software. In other terms if you work for a bank then banking is your domain.

Model is a system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain. For example a map is a model designed to solve a specific problem. A treasure map shows how to find a treasure, a political map shows the borders of countries. A model is a simplification. It is an interpretation of reality that focuses on the problem at hand and ignores the extraneous detail.

Models are designed to be useful to solve domain specific problems. For example in the past the universe was viewed in a geocentric way where the universe revolves around Earth. Heliocentric model is another astronomical model in which the Earth and planets revolve around a stationary Sun at the centre of the universe. Even though geocentric model is not realistic it is a valid model in it’s own right designed to solve a problem – the human desire to be in the centre of everything. It’s not a useful model when it’s used to compare planet movements.

Domain Driven Design advocates designing software systems to reflect the domain model in a very literal way, so that the mapping is obvious, also revising the model continuously and modifying it to be implemented more naturally in software. To tie the implementation to a model well requires tools and languages that support a modelling paradigm, such as object-oriented programming.

A well mapped implementation of a model usually expresses an object model that incorporates both behaviour and data. A decomposed domain model consists of common building blocks: entities, aggregates, value objects, services and factories.

Essential Principles of DDD

The greatest value of a domain model is that it provides a ubiquitous language that ties domain experts and technologists together. Ubiquitous language is a language structured around the domain model and used by all team members to connect all activities of the team with the software. It’s a shared, versatile language between team members and domain experts. A well designed model speaks to the developers through the ubiquitous language. It’s important to understand that a change in the model is a change in the language and vice versa.

When multiple models are in play on a large project it’s beneficial to define bounded contexts where these models apply. A bounded context is a linguistic boundary marking the applicability of distinct models. Usually a subsystem or work owned by another team. For example in a typical e-shop web application a sales reporting application could be defined as a separate bounded context.

Every domain consists of subdomains. For example a very common subdomain is billing. Such a subdomain is usually not the driving part of the domain and therefore not as important. It is harsh reality that not all parts of the design are going to be equally refined therefore priorities must be set. DDD suggests distilling the core domain by distinguishing it from other generic subdomains and applying the top talent to work on it.

Conclusion

DDD helps projects to develop a strong internal language, define clear context boundaries, and focus on the core domain. Domain Driven Design brings structure and cohesion into domain modelling which are much appreciated features of any software project in existence. The blue book has been released six years ago and since then it influenced many developers. Yet I feel it hasn’t reached it’s momentum. One can only hope it will reach widespread adoption.

Update: I’ve added a list of available DDD resources such as papers and video presentations.

, , Hide

Find it!

Theme Design by devolux.org