Kategorie: Best Practices

The Hitchhiker’s Guide to Python!

This handcrafted guide exists to provide both novice and expert Python developers a best practice handbook to the installation, configuration, and usage of Python on a daily basis.This guide is opinionated in a way that is almost, but not quite, entirely unlike Python’s official documentation. You won’t find a list of every Python web framework available here. Rather, you’ll find a nice concise list of highly recommended options.

Quelle: The Hitchhiker’s Guide to Python! — The Hitchhiker’s Guide to Python

Interesting Google IO 2011 Sessions

Since I finally found the opportunity to have a look at some Google IO 2011 sessions, here are some links to sessions I can recommend:

Android Development Tools:
Shows some neat tips & tricks for using new (and old) features of the ADT plugin for Eclipse

Android Protips: Advanced Topics for Expert Android App Developers
Provides a lot of great tips and some patterns for common problems, e.g. keeping backward compatibility while still using new features, doing battery efficient data updates, etc.

Memory management for Android Apps
Background information about the garbage collector, memory management in the Dalvik VM and how to find memory problems by using the Eclipse Memory Analyzer

Building Aggressively Compatible Android Games
A good high-level summary of how to make apps compatible for many devices.

Why and How to Document your Software Architecture

Coding the Architecture provides a very nice slide set giving a very good high level overview of why and how to document your software architecture in a practical way. As I wrote, it is a slide set and therefore only provides very short summaries on the different aspects. Nevertheless, it provides some good suggestions which topics should be covered and how to document them.

Key takeaways:

  • Software architecture documentation should be complementary to the code and describe what the code itself doesn’t. For example, it’s really hard to identify things like architectural principles, operational aspects and how security works from just the code itself.
  • Keep it short and useful
  • What it should contain:
    • Explanation of the software structure
    • The architectural principles and constraints
    • Development and deployment technologies and platforms
    • A justification of how the architecture satisfies the requirements

You can find the slide set here.

BTW: Coding the Architecture contains a lot of useful resources for software architects.

97 Things Every Software Architect Should Know

In this truly unique technical book, today’s leading software architects present valuable principles on key development issues that go way beyond technology. More than four dozen architects — including Neal Ford, Michael Nygard, and Bill de h ra — offer advice for communicating with stakeholders, eliminating complexity, empowering developers, and many more practical lessons they’ve learned from years of experience. Among the 97 principles in this book, you’ll find useful advice such as:

  • Don’t Put Your Resume Ahead of the Requirements (Nitin Borwankar)
  • Chances Are, Your Biggest Problem Isn’t Technical (Mark Ramm)
  • Communication Is King; Clarity and Leadership, Its Humble Servants (Mark Richards)
  • Simplicity Before Generality, Use Before Reuse (Kevlin Henney)
  • For the End User, the Interface Is the System (Vinayak Hegde)
  • It’s Never Too Early to Think About Performance (Rebecca Parsons)

To be successful as a software architect, you need to master both business and technology. This book tells you what top software architects think is important and how they approach a project.

You can find the 97 things for free here.

Dependency Injection using Unity

A nice high-level overview of  the technique of Dependency Injection using Microsofts Unity framework can be found in the May release of the MSDN magazine.

These principles include maintaining separation of concerns, using abstraction to implement loose coupling between layers and components, implementing service location capabilities, and managing crosscutting concerns such as logging and security. While these may seem to be desirable but unrelated aims, one technique can help you to apply several design principles easily. The Dependency Inversion principle implies separation of concerns through abstractions rather than concrete implementations. In terms of design patterns, you can achieve this by applying the Inversion of Control (IoC) pattern and its related pattern, Dependency Injection (DI).

The theory is simple enough. Instead of specifying at design time the actual concrete type that each class or component will use to perform some activity or process, you arrange for these classes or components to retrieve the appropriate object from a container that you previously configured with type maps and registered types.

Dependency Injection is great for achieving loose coupling of components. There are a lot of tools available that can be used for injecting dependencies. A list of such tools can be found on the Wikipedia page as well as on the Clean Code Developer Tools page.

Professional Software Development

What defines a professional developer? The initiative „Clean Code Developer“ (german only, english version using Google Translate) tries to facilitate a common understanding of this question. It has started to collect principles, rules and best practices for better software.

They see as basic principle for becoming a professional developer to be self-conscious about your work and always try to improve yourself as well as to adhere to some common best practices and working principles. Trying to lead developers to more professionalism, they have also collected a lot of concrete recommendations for the day to day work. To make it easier to follow these practices and rules, all recommendations are grouped by a so-called grade system. So you can start with the easy ones and get to the maybe not so easy to follow rules later.

Even if you don’t agree to all suggested practices and principles, the side is definitely worth a read since you will find a lot of good practices concentrated on one location. Additionally, they also maintain a link list for useful tools and frameworks.

You can find the Clean Code Developer initiative here.

The most important thing about optimization is analysis

You can’t fix a problem by simply trying different solutions to see if they work. In order to fix a problem, you have to understand the problem first.

So, please, if you’re a developer, don’t assume saving a couple of CPU cycles here or there will solve the problem. And if you’re a manager, don’t assume some new hardware will solve the problem. Do some analysis first. Finding out if disk I/O, memory, CPU cycles or single threading is the problem is really not that hard if you spend a little time thinking about it and benchmarking various things. And in the end, you’ll have a much better overview of the situation and the problem, and you’ll be able to come up with specific solutions which will actually work.

And that’s how you save money.

via Electricmonk.nl | Log.

Turn off your step-thru debugger

A good point and definitely contains some trues:

„If you get in the habit of using a debugger,“ my mentor pointed out, „you’ll get lazy. A certain part of your brain shuts off, because you expect the debugger to help you find the bug. But in reality, you wrote the bug, and you should be able to find it.“

Still stunned, I asked: „What do you do when you have a really nasty bug?“

He said something I’ll never forget. „I make the machine tell me where it is.“

Make the machine tell you where the bug is. What a wonderful piece of advice. It’s the essence of troubleshooting, whether you’re trying to fix a car that won’t start, trace an electrical fault, or debug a piece of software.

via assertTrue( ): Turn off your step-thru debugger.

Writing better commit messages

If you and your team are in the habit of writing good commit messages, it can save everyone a tremendous amount of time and effort. Other developers can very quickly see what you’ve done. It’ll also save tons of time tracking down commits from the past when you need to find them. A good commit message serves exactly two purposes: it gives other developers an explanation of the commit, and it gives some documentation for future searching.

Read one for some good rules on writing commit messages.

via lbrandy.com » Blog Archive » Writing better commit messages.

Use Threads Correctly = Isolation + Asynchronous Messages

Here are the key things to know about threads:

* Threads are for expressing asynchronous work. The point of being asynchronous is to let the units of independent work in the application all run at their own speeds and better tolerate each other’s latency.

* Threads are a low-level tool. Threads are just „sequential processes that share memory,“ and that kind of freewheeling anything-goes model doesn’t provide any abstraction or guard rails to make good practices easy and bad practices hard. As aptly criticized by Edward Lee in his paper „The Problem with Threads“ [2], threads let you do anything, and do it nondeterministically by default.

* „Up-level“ them by replacing shared data with asynchronous messages. As much as possible, prefer to keep each thread’s data isolated (unshared), and let threads instead communicate via asynchronous messages that pass copies of data. This best practice inherently encourages writing threads that are event-driven message processing loops, which gives inherent structure and synchronization and also improves determinism:

via Dr. Dobb’s | Use Threads Correctly = Isolation + Asynchronous Messages | März 16, 2009.