Simple wsgi apps without using a framework.

Using apache and mod_wsgi, serve a dirt simple app (useful for mocking services that havent been created yet by other programmers).

After installing mod_wsgi (sudo apt-get install libapache2-mod-wsgi)

Apache conf:

WSGIScriptAlias /webdir/ /filesys/dir/

With this you can call wsgi scripts in 'webdir' as localhost/webdir/test.py

python WSGI code for the file /filesys/dir/test.py:

def application(environ, start_response):
   response_body = '{"fake-json":"temp-output"}'
   status = '200 OK'
   response_headers = [('Content-Type', 'application/json'),
                       ('Content-Length', str(len(response_body)))]
   start_response(status, response_headers)

   return [response_body]

Done. No stupid framework needed for stupid simple apps.

Resolving "murrine_style_draw_box: assertion `height >= -1'"

Finally figured out how to stop this message from popping up after every key stroke if I've launched emacs from a terminal.

Modify the entry in /usr/share/themes/Ambiance/gtk-2.0/gtkrc from GtkRange::trough-under-steppers = 0 to GtkRange::trough-under-steppers = 1. Change Ambiance to whatever theme you are using.

Source: The Hack List

Some command line utils for git conflict resolution

Git has some nice utilities that can make dealing with conflicts much easier.

If after merging you just want to keep either the remote (theirs) or your own file (ours), you can checkout the file with either --ours or --theirs options as in:

git checkout --ours index.html
git checkout --theirs template.html

In order to look at the original files, git show :1:filename shows the common ancestor, git show :2:filename shows the HEAD version, and git show :3:filename shows the MERGE_HEAD version.



Sources:
Keep either file in a merge conflict

Article on Tabs vs Spaces

It's an old article (2000!!), but it's a good article.

http://www.jwz.org/doc/tabs-vs-spaces.html

DRY is more than just not repeating code.

DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation.

Given all this knowledge, why should you find one way to represent each feature? The obvious answer is, if you have more than one way to express the same thing, at some point the two or three different representations will most likely fall out of step with each other. Even if they don't, you're guaranteeing yourself the headache of maintaining them in parallel whenever a change occurs. And change will occur. DRY is important if you want flexible and maintainable software.

-- Dave Thomas

How to change auto-save-list directory in emacs

To change the auto-save-list directory in emacs, add the following to your .emacs:

;; Put auto-save-list somewhere else
(set 'auto-save-list-file-prefix "~/.trash/.saves-")

Ignore changes to a file in Git

Temporarily ignore changes to a file in git:

git update-index --assume-unchanged filename

To start tracking changes to the file again, run:

git update-index --no-assume-unchanged filename

source: http://gitready.com/intermediate/2009/02/18/temporarily-ignoring-files.html