Jun 27, 2012

apachetop

sudo apachetop -f logs/apache_access.log

Install multiple Python versions locally

https://github.com/utahta/pythonbrew - Pythonbrew is a program to automate the building and installation of Python in the users $HOME.
https://github.com/akheron/multipy - Install multiple Python versions locally

Jun 26, 2012

Stackless

Stackless Python is an enhanced version of the Python programming language. It allows programmers to reap the benefits of thread-based programming without the performance and complexity problems associated with conventional threads. The microthreads that Stackless adds to Python are a cheap and lightweight convenience which can if used properly, give the following benefits:
  • Improved program structure.
  • More readable code.
  • Increased programmer productivity.

Jun 21, 2012

Data Structures

weakref - module allows the Python programmer to create weak references to objects

Jun 20, 2012

Multiple Inheritance Best Practices

Multiple inheritance should be avoided: It can be replaced with some
design patterns.
  • super usage has to be consistent: In a class hierarchy, super should be used everywhere or nowhere. Mixing super and classic calls is a confusing practice. People tend to avoid super, for their code to be more explicit.
  • Don't mix old-style and new-style classes: Having a code base with both results in a varying MRO behavior.
  • Class hierarchy has to be looked over when a parent class is called: To avoid any problems, every time a parent class is called, a quick glance at the involved MRO (with __mro__) has to be done.

The common patterns for decorators are:

  • Argument checking 
  • Caching 
  • Proxy 
  • Context provider

Coroutines

http://pypi.python.org/pypi/greenlet
http://pypi.python.org/pypi/multitask

Jun 17, 2012

Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce


Levels of Testing
  • Acceptance: Does the whole system work?
  • Integration: Does our code work against code we can't change?
  • Unit: Do our objects do the right thing, are they convenient to work with?
Unit and integration tests support the development team, should run quickly, and should always pass. Acceptance tests for completed features catch regressions and should always pass, although they might take longer to run.

Refactoring is not the same activity as redesign, where the programmers take a conscious decision to change a large-scale structure.That said, having taken a redesign decision, a team can use refactoring techniques to get to the new design incrementally and safely.

We have objects sending each other messages, so what do they say? Our experience is that the calling object should describe what it wants in terms of the role that its neighbor plays, and let the called object decide how to make that happen. This is commonly known as the “Tell, Don’t Ask” style or, more formally, the Law of Demeter. Objects make their decisions based only on the information they hold internally or that which came with the triggering message; they avoid navigating to other objects to make things happen. Followed consistently, this style produces more flexible code because it’s easy to swap objects that play the same role.

We also prefer not to change third-party code, even when we have the sources. It’s usually too much trouble to apply private patches every time there’s a new version.Test code should describe what the production code does. That means that it tends to be concrete about the values it uses as examples of what results to expect, but abstract about how the code works. Production code, on the other hand, tends to be abstract about the values it operates on but concrete about how it gets the job done.


A better alternative is to name tests in terms of the features that the target object provides. We use a TestDox convention (invented by Chris Stevenson) where each test name reads like a sentence, with the target class as the implicit subject


We try to move everything out of the test method that doesn’t contribute to the description, in domain terms, of the feature being exercised

Literal values without explanation can be difficult to understand because the programmer has to interpret whether a particular value is significant (e.g. just outside the allowed range) or just an arbitrary placeholder to trace behavior (e.g. should be doubled and passed on to a peer)


One solution is to allocate literal values to variables and constants with names that describe their function.


The assertions and expectations of a test should communicate precisely what matters in the behavior of the target code


The code to create all these objects makes the tests hard to read, filling them with information that doesn’t contribute to the behavior being tested. It also makes tests brittle, as changes to the constructor arguments or the structure of the objects will break many tests. The object mother pattern [Schuh01] is one attempt to avoid this problem. An object mother is a class that contains a number of factory methods [Gamma94] that create objects for use in tests.

Another solution is to use the builder pattern to build instances in tests, most often for values. For a class that requires complex setup, we create a test data builder that has a field for each constructor parameter, initialized to a safe value. The builder has “chainable” public methods for overwriting the values in its f ields and, by convention, a build() method that is called last to create a new instance of the target object from the field values.1 An optional refinement is to add a static factory method for the builder itself so that it’s clearer in the test what is being built.

We think a bit harder about what varies between tests and what is common, and realize that a better alternative is to pass the builder through, not its arguments; it’s similar to when we started combining builders.


If, for example, a collaboration doesn’t work properly and returns a wrong value, an assertion might fail before any expectations are checked. This would produce a failure report that shows, say, an incorrect calculation result rather than the missing collaboration that actually caused it


Allow Queries; Expect Commands


There are two ways a test can observe the system: by sampling its observable state or by listening for events that it sends out. Of these, sampling is often the only option because many systems don’t send any monitoring events


Put the Timeout Values in One Place





write events to log file and assert is it contains p.318


A sample-based assertion repeatedly samples some visible effect of the system through a “probe,” waiting for the probe to detect that the system has entered an expected state. There are two aspects to the process of sampling: polling the system and failure reporting, and probing the system for a given state. Separating the two helps us think clearly about the behavior, and different tests can reuse the polling with different probes.

Jun 13, 2012

Бритва Оккама

«Бритва О́ккама» или «лезвие Оккама» — методологический принцип, получивший название по имени английского монаха-францисканца, философа-номиналиста Уильяма Оккама (Ockham, Ockam, Occam; ок. 1285—1349). В упрощенном виде он гласит: «Не следует множить сущее без необходимости» (либо «Не следует привлекать новые сущности без самой крайней на то необходимости»). Этот принцип формирует базис методологического редукционизма, также называемый принципом бережливости, или законом экономии.

Jun 11, 2012

Naming conventions in decorators

def decorator_name(whatevs):
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            pass # sweet decorator goodness
        return wrapper
    return decorator
http://stackoverflow.com/questions/10957409/python-naming-conventions-in-decorators

Jun 7, 2012

Syntax highlighting

pygments - a generic syntax highlighter for general use in all kinds of software such as forum systems, wikis or other applications that need to prettify source code.
highlight.js - highlights syntax in code examples on blogs, forums and in fact on any web pages. It's very easy to use because it works automatically: finds blocks of code, detects a language, highlights it.

Jun 6, 2012

Jun 4, 2012

South

Fake migration to zero
./manage.py migrate myapp --fake zero
Common Pitfalls with Django and South

Cynic

Cynic - Test harness to make your system under test cynical

http://vimeo.com/43375697

Backbonejs django generic view

backbonejs-django-generic-view