Jun 27, 2012
apachetop
sudo apachetop -f logs/apache_access.log
Labels:
apache,
apachetop,
performance,
profiling
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
https://github.com/akheron/multipy - Install multiple Python versions locally
Labels:
environment,
installer,
python,
python versions,
pythonbrew,
version
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.
Labels:
threading
Jun 21, 2012
Data Structures
weakref - module allows the Python programmer to create weak references to objects
Labels:
psl,
standard library
Jun 20, 2012
Multiple Inheritance Best Practices
Multiple inheritance should be avoided: It can be replaced with some
design patterns.
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
Labels:
decorator
Jun 18, 2012
Schema-less in Django with Postgres
http://www.craigkerstiens.com/2012/06/14/schemaless-django/
hStore is a column type within Postgres.
hStore is a column type within Postgres.
Labels:
hstore,
nosql,
postgre,
schemaless
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?
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.
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 15, 2012
Jun 14, 2012
Jun 13, 2012
Бритва Оккама
«Бритва О́ккама» или «лезвие Оккама» — методологический принцип, получивший название по имени английского монаха-францисканца, философа-номиналиста Уильяма Оккама (Ockham, Ockam, Occam; ок. 1285—1349). В упрощенном виде он гласит: «Не следует множить сущее без необходимости» (либо «Не следует привлекать новые сущности без самой крайней на то необходимости»). Этот принцип формирует базис методологического редукционизма, также называемый принципом бережливости, или законом экономии.
Labels:
Бритва Оккама,
принципы разработки
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
Labels:
decorator
Jun 9, 2012
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.
Labels:
syntax highlighting
Jun 6, 2012
Prevent slowness and fail gracefully
interruptingcow
from interruptingcow import timeout
with timeout(20.0, RuntimeError):
run_something_that_might_take_long()
Jun 4, 2012
Jun 1, 2012
Subscribe to:
Posts (Atom)