Last week I attended a practical course in astronomy at the Dr. Remeis Astronomical Institute in Bamberg. The course took nearly two weeks, where the groups had to do some experiments and write protocols afterwards. It was not only work, but we also took a few great pictues.

Booth pictures were shot with an 40cm Schmidt-Cassegrain telescope. The first one ist the M101 (also called Pinwheel Galaxy). It was taken with an raw CCD camera with 11 Megapixel. We've done 4 pictures (Luminance, Red, Green, Blue) in total (plus some calibration pictures), which took nearly 2 hours. The ready assembled picture is really good (be aware that you cannot see M101 with your bare eye, because it is too dark). The second one was done with the EOS Camera of a friend (rupran) and shows (surprise) the moon.

UPDATE: I've also found through wikipedia, some Hubble Images of M101

If you edit a LaTeX document and keep you .tex files in a Git Repository, it is really hard to use git-diff useful, because in normal human readable text your document isn't structured in lines, but in sentences. Therefore it is useful to have a word-diff, where you can see which words have changed. This is especially useful if you ignore the 80-column rule.

[alias]
        wdiff = diff --color-words
        wshow = show --color-words
[core]
        pager = env LESS= less -XR

With this you get an git wdiff command, which performs a word-diff. The pager entry is needed for long lines, because git-diff sets the LESS environment variable to FRSX, which prohibits line breaks within the pager.

Inspired by the defadvice[^1] mechanism in Emacs, which allows you to add some functionality to an already defined function. Such an advice contains code, which is executed every time before or after the original function is called. So your added functionality is executed without any further modifications in the existing source code. This is especially useful if you want to give the user a simple method to enable or disable a certain functionality without (big) impact on performance.

Because i needed this functionallity for a project i remembered these advices in emacs and implemented the behaviour in python, which was really straight-forward. I will just show a short example of the usage. The full source code is at [^2]. I will not do an overall source code discussion, if you have questions just put them in the comments.

class CallLogAdvice(Advice):
    def before(self, args, kwargs):
        print "-> Args: %s, KWArgs: %s" %( args, kwargs)
        args[2] += 1
        return (args, kwargs)
    def around(self, func, args, kwargs):
        print "-> Calling %s with %s, %s" % (func,args, kwargs)
        return func(args,kwargs)
    def after(self, ret):
        print "-> Return-value: %s" % ret
        return ret

@AdviceManager.advicable
def func1(a, b ,c):
    print "In Function:",a, b, c
    return a + b + c

advice = CallLogAdvice("__main__.func1")
func1(1,2,3)
print
advice.enable()
func1(1,2,3)

First the advice itself is defined. Every advice must inherit from the class Advice, which provides the mechanisms to register the advice at the AdviceManager. The advice has three user definable methods: before, around, and after. They are respectivly called in the life cycle of the function call. They can modify the arguments, wether the function is actually called and manipulate the return values.

Every function that should be advicable must be marked as so, because it is wrapped by the AdviceManager in a helper function to provide the advice funtionallity. Here func1 is marked advicable. Afterwards an advice is instanciated, which should advice func1. __main__ is needed here because i defined the function in the main-package. You have to give the package path to the advice (or the function object itself).

Afterwards the function is called two times. First withthe advice disabled secondly with the advice enabled:

In Function: 1 2 3

-> Args: [1, 2, 3], KWArgs: {}
-> Calling  with [1, 2, 4], {}
In Function: 1 2 4
-> Return-value: 7

As you can see the advice methods are called at the correct phases and can manipulate the arguments.

This might be a very useful tool for adding cross cutting constraints to existing code. It is also thinkable to mark all methods and functions as advicable (hint: metaclasses). I also want to mention two much more powerful concecpts which are closly related to such advices. The first is the common lisp object system CLOS and aspect-oriented programming (like in AspectC++[^3]). This are much more powerful tools for modeling cross-cutting constraints.

[^1]: http://www.gnu.org/software/emacs/manual/html_node/elisp/Advising-Functions.html

[^2]: advices.py

[^3]: http://www.aspectc.org/

In Javascript objects and associative arrays are almost exchangeable as you can access an object attribute either with the []-operator or the .-operator, which is really useful for make your code much more readable (personal opinion!):

var foo = object();
foo["name"] = 23; 
foo.name = 23;

I really like this idiom in javascript, because when using the dot notation you have to put the key literally into the code and you cannot use a variable as accessor key. And i really started to miss this feature in Python, so i dug into the Python documentation and found the __getattr__ mechanism[^1]. And so i implemented a Javascript style dictionary (dictionary is the python notation for an hashed associative array):

class JSdict(dict):
    def __getattr__(self, name):
        return self[name]
    def __setattr__(self, name, value):
        self[name] = value
    def __delattr__(self, name):
        del self[name]

The JSdict class inherits from the standard dict-type to get all the normal dict methods (like the []-operator). Addionally to that __getattr__ is implemented to provide read access to the dictionary's content via the dot-notation. __getattr__ is only called, when the key is not provided by the class type (e.g. .keys() is not overriden). Similar to this __setattr__ and __delattr__ are also implemented. Now to a short example how this JSdict may be used:

d = JSdict()
d["foo"] = 23
d.bar    = 42
print d # {'foo': 23, 'bar': 42}

del d.bar
print d # {'foo': 23}

Additional: If you want to override every attribute lookup within an object (e.g. to override .keys() in this case) you may use __getattribute__[^2], but there you have to handle every attribute lookup, except that for __getattribute__ itself. Of course implementing this inefficient, makes your attribute access very inefficient, because it is called very often.

[^1]: http://docs.python.org/reference/datamodel.html#customizing-attribute-access

[^2]: http://docs.python.org/reference/datamodel.html#more-attribute-access-for-new-style-classes