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

Make mouse pointer disappear with unclutter

Add the following line to .xsession to make the mouse pointer go away after a set number of seconds:

unclutter -idle 1 -noevents &

Revert a file in Git

To revert a file with uncommitted changes to the current version in the repo do:

git checkout -- filename

source: http://norbauer.com/notebooks/code/notes/git-revert-reset-a-single-file

Get a list of files that have changed between revisions in Subversion

svn diff -r REVNO:HEAD --summarize

source: http://muffinresearch.co.uk/archives/2008/09/15/svn-tip-get-list-of-files-changed-between-revisions/


Macs

You don't use a mac if you know what you're doing. You use a mac if you don't know what you're doing and you just want someone who does know what they're doing to configure a machine with all the basics set to the most popular settings.

Whole Trackpad as a scrollwheel

Update: The below is all crap. Turns out the best way to do it is to simply set up in your bashrc a call to synclient setting LeftEdge and RightEdge = 0

synclient LeftEdge=0
synclient RightEdge=0

--------------------------------------------------------------------------------------
Using synclient -l to display all values, find the value of LeftEdge and then set the value of RightEdge to the same value in LeftEdge in your xorg.conf under the 'InputDevice' section:

Section "InputDevice"
Identifier "Synaptics Touchpad"
Driver  "synaptics"
Option  "SendCoreEvents" "true"
Option  "Device" "/dev/psaux"
Option  "Protocol" "auto-dev"
Option  "SHMConfig" "on"
Option  "HorizEdgeScroll" "0"
 Option  "RightEdge" "1752"
EndSection

Source: http://ubuntuforums.org/showthread.php?t=886449

Interuptable Programmer

Source


I’m 37, and I’ve been a (professional) developer for 16 years. You would have thought that in that time, I’d have figured out an effective work style which delivered the desired outcomes (code cut, products shipped etc) without causing detrimental knock-on effects – but, sadly, you’d be wrong. I think the style in which I practiced my craft for the first 15 years of my career was much the same as every other enthusiastic developer: you put a ton of hours in. 12-16+ hour days, evening and weekend coding marathons, pizza in the keyboard, crunch times, 3am debugging sessions where you just can’t go to bed because you can feel the source of that bug just beyond your fingertips, dammit, desperate last-minute sprints to deadlines where you manage to slot that last piece in, Jack Bauer-like, just before the world goes to hell. If you’re in the demographic I’m talking about, you’re nodding sagely, and probably grinning a little too, reminiscing on past trials and glories. This sort of crazy dedication is respected in our circles, and is pretty much expected of any developer who has claimed to earn their stripes.
But, it turns out this kind of thing is not good for your health – who knew? Those of you who know me or keep up with my blog know that I’ve been dragged kicking and screaming away from my old ways, because of back issues that I initially ignored, then tried to cope with using token accommodations, and finally succumbed to in a big way. Being self-employed, this was a major problem. Crawling out of the pit I dug for myself took a long time and a lot of frustration – I read quite a few productivity books on the subject to try to find answers on how to keep working, and in the end found that the answers you mould for yourself tend to be the best ones. I’d like to share one of the things I learned along the way.
But I’m ‘In The Zone’!!
So, I want to talk about the biggest problem I encountered: concentration periods. I can’t sit at a desk for longer than about an hour at a time now; if I don’t get up and walk around, do some gentle stretching etc, at least this often, I’ll pay for it badly once I do move, and probably over the next few days too. I also can’t realistically work more than a standard 8 hour day without pain any more. The problem with this was that, as a programmer, the style which I developed over 15+ years involved getting gradually ‘Into The Zone’ and coding for very long periods at a time, uninterrupted. This is a common theme among coders, who like to shut themselves away for hours at a time, wear headphones to avoid distractions, have ‘quiet times’ and so on – and it’s also why we tend to react really badly when interrupted. Programming requires concentration, and concentration seems to run on a valve system – it takes time to warm up, and once it’s going, you don’t want to turn it off because starting it up again is a major hassle.
I thought there was no way around this, and had begun to resign myself to just being less productive because of it. However, over the last 6  months in particular, I’ve discovered that, far from being an intractable problem, this ‘slow warm up, long uninterrupted focus time’ approach is to a large degree a learned behaviour, and it’s possible to re-train yourself to cope with things differently. It’s a little like when people learn to adopt polyphasic sleep patterns – it’s not that you can’t do it, it’s just that when you’ve become accustomed to doing things a certain way, changing that is initially very, very hard. But it’s not impossible, given the right amount of motivation and time to adjust.
So, my goal was to acclimatise myself to many shorter work chunks during the day instead of a few very large ones, while still maintaining productivity. The key to this was to learn how to get back ‘In The Zone’ in the shortest time possible – much like the way polyphasic sleepers train themselves to achieve REM sleep more quickly. I’m mostly there now, or at least way better at it than I was, so, what techniques did I use to make this transition?

1. Embrace interruptions
   This is less of a technique and more of a deliberate psychological adjustment which cuts across all the practical approaches I’ll cover next. Instead of being the typical coder who avoids interruptions at all costs, you need to accept them, and learn to manage them better. It’s hard – you have to try to set aside years of resisting interruptions and initially, until you adjust, you’ll feel like you can’t get enough done. Many people will probably want to give up, unless there’s something specific motivating them to push through it – for me, daily pain was a great motivator. My main message here is that the transition is just a phase, and that it is possible to be an interruptable programmer who still gets things done. But you have to learn not to fight against it, hence why this is the first point.
2. Maintain context outside of your head at all times
   Much of the problem with interruptions is that of losing context. When you’re in that Zone, you’re juggling a whole bunch of context in your head, adjusting it on the fly, and maintaining and tweaking connections between issues constantly. Interruptions make you drop all that, and it takes time to pick it all up again. My answer to this was to externalise as much as possible, on as many levels as possible:
   1. Maintain a running commentary on your current task
      I am my very own chronicler. I write notes on what I’m doing all the time, whether it’s adding a comment line to a ticket, committing frequently and writing detailed commit notes (you do use a DVCS to make light commits more practical, right? ;)) scribbling a drawing on (ordered) pieces of paper. This really isn’t that onerous, and in fact externalising your thoughts can often help you clarify them. Basically the guide is that roughly every 30 minutes, I should have generated some new piece of context which is stored somewhere other than my head. If I haven’t, then that’s context I’d have more trouble re-building mentally if I’m interrupted. It doesn’t take much time to do, and it has other benefits too such as recording your thought & decision process.
   2. Ruthlessly ignore tangental issues
      You might have noticed that in the last bullet, I used the words ‘current task’, singular. Not ‘tasks’. There is no such thing as having more than one ‘current task’ – there is only the one task you’re actually working on, and distractions.
      We probably all use bug trackers / ticket systems to track bugs and feature requests, but when you’re working on a ticket, it’s very common to spot a new bug, or identify an opportunity for improvement, or think of a cool new feature. How many of us go ahead and deal with that right away, because it’s in the area we’re already in, or it’s ‘trivial’, or it’s a cool idea that you want to try right now?  I know I did – but I don’t any more; any tangental issues not related to what I’m currently doing get dumped into the ticket system and immediately forgotten until I’m done with the current task, regardless of their size, relevance or priority. It sounds simple and obvious, and this might even be official procedure in your organisation, but I challenge most coders to say that they actually do this all the time. The benefit is that even the tiniest of distractions add an extra level of context that you have to maintain, which is then harder to pick up again after an interruption.
      For this to work, you need a ticket system which is fast, lightweight, and doesn’t require you to be anal about how much detail you put in initially. You need to be in & out of there in 30 seconds so you can offload that thought without getting distracted – you can flesh it out later.
   3. Always know what you’re doing next
      This is one from GTD (‘Next actions’), but it’s a good one. When you come back from a break or interruption, you should spend no time at all figuring out what you need to be doing next. Your ticket system will help you here, and so will the running commentary that hopefully you’ve been keeping on your active task. If you’ve been forced to switch gears or projects, so long as you’ve maintained this external context universally, you should have no issue knowing what the next actions on each item are. The important thing is to have one next action on each project. If you have several, you’ll have to spend time choosing between them, and that’s wasted time (see the next section on prioritisation). At any one time, you should not only have just one current task, but one unambiguous next action on that task. Half the problem of working effectively is knowing what you’re doing next.
3. Prioritise Negatively
   I mentioned next actions in the previous section, but how do you decide what comes next? A lot of time can be frittered away agonising over priorities, and I used to struggle with it; I would plan on the assumption that I wanted to do everything on the list, and I just needed to figure out which I needed to do first. I discovered that I could cut the amount of time I spent on planning, and also get better, less ambiguous priorities by inverting the decision making process – to assume a baseline that I wouldn’t do any of the tasks, and assessing the negative outcomes of not doing each one. So instead of ‘which of feature A or B is more important to have?’, it became ‘Let’s assume we ship without feature A and B. What are the issues caused by omitting them in each case?’. It might appear to be a subtle difference, but having to justify inclusion entirely, rather than trying to establish a relative ordering assuming they all get done eventually, tends to tease out more frank evaluations in my experience.
4. Recognise the benefits of breaks
   Much of the above is about limiting the negative aspects of taking breaks, but the fact is, that they have many work-related benefits too. I’m willing to bet that all coders have stayed late at work, or late into the night, trying to fix a problem, only to find that they fix it within 15 minutes the next day, or think of the answer in some unlikely place like the shower. The reason for this is very simple – extended periods of concentration seem productive, and can be on operational / sequential thinking, but for anything else such as creative thinking or problem solving, it’s very often exactly the opposite. Not only do tired minds think less clearly, but often the answer to a problem lies not in more extensive thinking down the current path which you’ve been exploring in vain for the last few hours, but in looking at the problem from a completely different perspective. Long periods of concentration tend to ‘lock in’ current trains of thought, making inspiration and strokes of genius all too rare. Creativity always happens when you’re not trying, and it’s an often under-appreciated but vital element of the programming toolbox. Interrupting that train of thought can actually be a very good thing indeed.

There’s more I could talk about, but that’s quite enough for now I think. I hope someone finds this interesting or useful

The Last of the 8s (Strange Adventures in Math)

Today I learned that I am one of the last of the 8s... I was born in 1978 and this year has a unique property that 19+78 = 97 the middle two numbers of the year 1978. Nifty. What other years have this?

Well assuming that we're just looking for years between 1000 and 10,000, we can write some python code to figure that out:

for i in range(1000,10000):
a = i/100
b = i%100
c = (i-(i/1000)*1000)/10
if (a+b == c):
  print(i)

This produces something kinda cool... but that I don't really understand:

1208
1318
1428
1538
1648
1758
1868
1978
2307
2417
2527
2637
2747
2857
2967
3406
3516
3626
3736
3846
3956
4505
4615
4725
4835
4945
5604
5714
5824
5934
6703
6813
6923
7802
7912
8901

That's 8 years that end in 8, 7 that end in 7, 6 that end in 6 etc down to one year that ends in 1 (8901). But where are the 9's? They're in adding the first value and the last value together. 36 of them (9*4?).. There's some other patterns in there as well. I'm sure there's a whole dissertation in mathematics that's been written on this, but I'm not even sure where to start searching for more info about it (it's the Loblaw principle... named after it's founder, Bob Loblaw..)

Alex Martelli on python vs ruby

From comp.lang.python

Erik Max Francis wrote:
> "Brandon J. Van Every" wrote:

>> What's better about Ruby than Python? I'm sure there's something.
>> What is it?

> Wouldn't it make much more sense to ask Ruby people this, rather than
> Python people?

Might, or might not, depending on one's purposes -- for example, if
one's purposes include a "sociological study" of the Python community,
then putting questions to that community is likely to prove more
revealing of informaiton about it, than putting them elsewhere:-).

Personally, I gladly took the opportunity to follow Dave Thomas'
one-day Ruby tutorial at last OSCON. Below a thin veneer of syntax
differences, I find Ruby and Python amazingly similar -- if I was
computing the minimum spanning tree among just about any set of
languages, I'm pretty sure Python and Ruby would be the first two
leaves to coalesce into an intermediate node:-).

Sure, I do get weary, in Ruby, of typing the silly "end" at the end
of each block (rather than just unindenting) -- but then I do get
to avoid typing the equally-silly ':' which Python requires at the
_start_ of each block, so that's almost a wash:-). Other syntax
differences such as '@foo' versus 'self.foo', or the higher significance
of case in Ruby vs Python, are really just about as irrelevant to me.

Others no doubt base their choice of programming languages on just
such issues, and they generate the hottest debates -- but to me that's
just an example of one of Parkinson's Laws in action (the amount on
debate on an issue is inversely proportional to the issue's actual
importance).

One syntax difference that I do find important, and in Python's
favour -- but other people will no doubt think just the reverse --
is "how do you call a function which takes no parameters". In
Python (like in C), to call a function you always apply the
"call operator" -- trailing parentheses just after the object
you're calling (inside those trailing parentheses go the args
you're passing in the call -- if you're passing no args, then
the parentheses are empty). This leaves the mere mention of
any object, with no operator involved, as meaning just a
reference to the object -- in any context, without special
cases, exceptions, ad-hoc rules, and the like. In Ruby (like
in Pascal), to call a function WITH arguments you pass the
args (normally in parentheses, though that is not invariably
the case) -- BUT if the function takes no args then simply
mentioning the function implicitly calls it. This may meet
the expectations of many people (at least, no doubt, those
whose only previous experience of programming was with Pascal,
or other languages with similar "implcit calling", such as
Visual Basic) -- but to me, it means the mere mention of an
object may EITHER mean a reference to the object, OR a call
to the object, depending on the object's type -- and in those
cases where I can't get a reference to the object by merely
mentioning it I will need to use explicit "give me a reference
to this, DON'T call it!" operators that aren't needed otherwise.
I feel this impacts the "first-classness" of functions (or
methods, or other callable objects) and the possibility of
interchanging objects smoothly. Therefore, to me, this specific
syntax difference is a serious black mark against Ruby -- but
I do understand why others would thing otherwise, even though
I could hardly disagree more vehemently with them:-).

Below the syntax, we get into some important differences in
elementary semantics -- for example, strings in Ruby are
mutable objects (like in C++), while in Python they are not
mutable (like in Java, or I believe C#). Again, people who
judge primarily by what they're already familiar with may
think this is a plus for Ruby (unless they're familiar with
Java or C#, of course:-). Me, I think immutable strings are
an excellent idea (and I'm not surprised that Java, independently
I think, reinvented that idea which was already in Python), though
I wouldn't mind having a "mutable string buffer" type as well
(and ideally one with better ease-of-use than Java's own
"string buffers"); and I don't give this judgment because of
familiarity -- before studying Java, apart from functional
programming languages where _all_ data are immutable, all the
languages I knew had mutable strings -- yet when I first saw
the immutable-string idea in Java (which I learned well before
I learned Python), it immediately struck me as excellent, a
very good fit for the reference-semantics of a higher level
programming language (as opposed to the value-semantics that
fit best with languages closer to the machine and farther from
applications, such as C) with strings as a first-class, built-in
(and pretty crucial) data type.

Ruby does have some advantages in elementary semantics -- for
example, the removal of Python's "lists vs tuples" exceedingly
subtle distinction. But mostly the score (as I keep it, with
simplicity a big plus and subtle, clever distinctions a notable
minus) is against Ruby (e.g., having both closed and half-open
intervals, with the notations a..b and a...b [anybody wants
to claim that it's _obvious_ which is which?-)], is silly --
IMHO, of course!). Again, people who consider having a lot of
similar but subtly different things at the core of a language
a PLUS, rather than a MINUS, will of course count these "the
other way around" from how I count them:-).

Don't be misled by these comparisons into thinking the two
languages are _very_ different, mind you. They aren't. But
if I'm asked to compare "capelli d'angelo" to "spaghettini",
after pointing out that these two kinds of pasta are just
about undistinguishable to anybody and interchangeable in any
dish you might want to prepare, I would then inevitably have
to move into microscopic examination of how the lengths and
diameters imperceptibly differ, how the ends of the strands
are tapered in one case and not in the other, and so on -- to
try and explain why I, personally, would rather have capelli
d'angelo as the pasta in any kind of broth, but would prefer
spaghettini as the pastasciutta to go with suitable sauces for
such long thin pasta forms (olive oil, minced garlic, minced
red peppers, and finely ground anchovies, for example - but if
you sliced the garlic and peppers instead of mincing them, then
you should choose the sounder body of spaghetti rather than the
thinner evanescence of spaghettini, and would be well advised
to forego the achoview and add instead some fresh spring basil
[or even -- I'm a heretic...! -- light mint...] leaves -- at
the very last moment before serving the dish). Ooops, sorry,
it shows that I'm traveling abroad and haven't had pasta for
a while, I guess. But the analogy is still pretty good!-)

So, back to Python and Ruby, we come to the two biggies (in
terms of language proper -- leaving the libraries, and other
important ancillaries such as tools and environments, how to
embed/extend each language, etc, etc, out of it for now -- they
wouldn't apply to all IMPLEMENTATIONS of each language anyway,
e.g., Jython vs Classic Python being two implementations of
the Python language!):

1. Ruby's iterators and codeblocks vs Python's iterators
and generators;

2. Ruby's TOTAL, unbridled "dynamicity", including the ability
to "reopen" any existing class, including all built-in ones,
and change its behavior at run-time -- vs Python's vast but
_bounded_ dynamicity, which never changes the behavior of
existing built-in classes and their instances.

Personally, I consider [1] a wash (the differences are so
deep that I could easily see people hating either approach
and revering the other, but on MY personal scales the pluses
and minuses just about even up); and [2] a crucial issue --
one that makes Ruby much more suitable for "tinkering", BUT
Python equally more suitable for use in large production
applications. It's funny, in a way, because both languages
are so MUCH more dynamic than most others, that in the end
the key difference between them from my POV should hinge on
that -- that Ruby "goes to eleven" in this regard (the
reference here is to "Spinal Tap", of course). In Ruby,
there are no limits to my creativity -- if I decide that
all string comparisons must become case-insensitive, _I CAN
DO THAT_! I.e., I can dynamically alter the built-in string
class so that
a = "Hello World"
b = "hello world"
if a == b
print "equal!\n"
else
print "different!\n"
end
WILL print "equal". In python, there is NO way I can do
that. For the purposes of metaprogramming, implementing
experimental frameworks, and the like, this amazing dynamic
ability of Ruby is _extremely_ appealing. BUT -- if we're
talking about large applications, developed by many people
and maintained by even more, including all kinds of libraries
from diverse sources, and needing to go into production in
client sites... well, I don't WANT a language that is QUITE
so dynamic, thank you very much. I loathe the very idea of
some library unwittingly breaking other unrelated ones that
rely on those strings being different -- that's the kind of
deep and deeply hidden "channel", between pieces of code that
LOOK separate and SHOULD BE separate, that spells d-e-a-t-h
in large-scale programming. By letting any module affect the
behavior of any other "covertly", the ability to mutate the
semantics of built-in types is just a BAD idea for production
application programming, just as it's cool for tinkering.

If I had to use Ruby for such a large application, I would
try to rely on coding-style restrictions, lots of tests (to
be rerun whenever ANYTHING changes -- even what should be
totally unrelated...), and the like, to prohibit use of this
language feature. But NOT having the feature in the first
place is even better, in my opinion -- just as Python itself
would be an even better language for application programming
if a certain number of built-ins could be "nailed down", so
I KNEW that, e.g., len("ciao") is 4 (rather than having to
worry subliminally about whether somebody's changed the
binding of name 'len' in the __builtins__ module...). I do
hope that eventually Python does "nail down" its built-ins.

But the problem's minor, since rebinding built-ins is quite
a deprecated as well as a rare practice in Python. In Ruby,
it strikes me as major -- just like the _too powerful_ macro
facilities of other languages (such as, say, Dylan) present
similar risks in my own opinion (I do hope that Python never
gets such a powerful macro system, no matter the allure of
"letting people define their own domain-specific little
languages embedded in the language itself" -- it would, IMHO,
impair Python's wonderful usefulness for application
programming, by presenting an "attractive nuisance" to the
would-be tinkerer who lurks in every programmer's heart...).

Alex Martelli

Coach Johnny D's quote..

Our deepest fear is not that we are inadequate.
Our deepest fear is that we are powerful beyond measure.
It is our light, not our darkness, that most frightens us.
Your playing small does not serve the world.
There is nothing enlightened about shrinking so that other people won't feel insecure around you.
...We are all meant to shine as children do.
It's not just in some of us; it is in everyone.
And as we let our own lights shine, we unconsciously give other people permission to do the same.
As we are liberated from our own fear,
our presence automatically liberates others.

Marianne Williamson via Coach Johnny D

List just the files that have changed in git.

To show the files that have changed between two revisions:

git diff --name-only foo bar

To show the files that changed for a particular commit:

git show --pretty="format:" --name-only *commit-sha*

Change Gnome login background/theme

1.When logged out, hold down CTRL+Alt+F1
2.Type export DISPLAY=:0.0 and press ENTER
3.Type Sudo -u gdm gnome-control-center and press ENTER
4.Hold down CTRL+Alt+F7
5.Gnome Control Center will appear. Press ''Apperance'' and choose a picture.
6. Close the window and log in

Epic Pub Crawl Remembered

Almost a year ago, we had an end of soccer party on a Saturday which turned into an epic pub crawl (my first ever). It was myself, JR, Jay, and Josh Jetson (seriously). We started drinking at Venice Beach Wines, then made our way to the beach where we got lunch. I remember seeing the smoke from the Station fire that was raging in the hills behind Pasadena while we were walking along the shore. From there we made our way back to Abbot-Kinney where we stopped at the Otheroom and hung out drinking various beers for about 5 hours. People we knew stopped by and eventually Enos showed up and we had a great time just chatting about random stuff. We were there so long that Jay took off and got some sandwiches for us all for dinner. From there we wandered over to Roosterfish, a gay bar with cheap drinks and got drunk on wiskey... we were basically there alone since it was still early in the evening (9pm). After that we continued on to The Brig where we continued drinking various stuff (PBR!.. for sheer trendiness) until around midnight when we decided to head for home. But first we stopped at one of the taco trucks that had showed up and grabbed some tacos. On the way home was basically when I realized that I was really drunk. I was walking along fuzzy headed and couldn't stop hiccuping. We got to Jay's place and continued drinking and chatting.

A pub crawl, starting at 11am and ending at 3am in Venice beach. It was the most fun I think I've ever had and all we did was talk, eat and drink.

Adding backgrounds to directories in LS_COLORS

To add backgrounds to the directories in the output of ls, in .bashrc add:

export LS_COLORS='di=01;34;47'

Quicklaunch ballistic space cannon

Invisible Flying Spaghetti Monster In My Garage...

The Dragon In My Garage

by Carl Sagan
"A fire-breathing dragon lives in my garage"

Suppose (I'm following a group therapy approach by the psychologist Richard Franklin) I seriously make such an assertion to you. Surely you'd want to check it out, see for yourself. There have been innumerable stories of dragons over the centuries, but no real evidence. What an opportunity!

"Show me," you say. I lead you to my garage. You look inside and see a ladder, empty paint cans, an old tricycle -- but no dragon.

"Where's the dragon?" you ask.

"Oh, she's right here," I reply, waving vaguely. "I neglected to mention that she's an invisible dragon."

You propose spreading flour on the floor of the garage to capture the dragon's footprints.

"Good idea," I say, "but this dragon floats in the air."

Then you'll use an infrared sensor to detect the invisible fire.

"Good idea, but the invisible fire is also heatless."

You'll spray-paint the dragon and make her visible.

"Good idea, but she's an incorporeal dragon and the paint won't stick." And so on. I counter every physical test you propose with a special explanation of why it won't work.

Now, what's the difference between an invisible, incorporeal, floating dragon who spits heatless fire and no dragon at all? If there's no way to disprove my contention, no conceivable experiment that would count against it, what does it mean to say that my dragon exists? Your inability to invalidate my hypothesis is not at all the same thing as proving it true. Claims that cannot be tested, assertions immune to disproof are veridically worthless, whatever value they may have in inspiring us or in exciting our sense of wonder. What I'm asking you to do comes down to believing, in the absence of evidence, on my say-so. The only thing you've really learned from my insistence that there's a dragon in my garage is that something funny is going on inside my head. You'd wonder, if no physical tests apply, what convinced me. The possibility that it was a dream or a hallucination would certainly enter your mind. But then, why am I taking it so seriously? Maybe I need help. At the least, maybe I've seriously underestimated human fallibility. Imagine that, despite none of the tests being successful, you wish to be scrupulously open-minded. So you don't outright reject the notion that there's a fire-breathing dragon in my garage. You merely put it on hold. Present evidence is strongly against it, but if a new body of data emerge you're prepared to examine it and see if it convinces you. Surely it's unfair of me to be offended at not being believed; or to criticize you for being stodgy and unimaginative -- merely because you rendered the Scottish verdict of "not proved."

Imagine that things had gone otherwise. The dragon is invisible, all right, but footprints are being made in the flour as you watch. Your infrared detector reads off-scale. The spray paint reveals a jagged crest bobbing in the air before you. No matter how skeptical you might have been about the existence of dragons -- to say nothing about invisible ones -- you must now acknowledge that there's something here, and that in a preliminary way it's consistent with an invisible, fire-breathing dragon.

Now another scenario: Suppose it's not just me. Suppose that several people of your acquaintance, including people who you're pretty sure don't know each other, all tell you that they have dragons in their garages -- but in every case the evidence is maddeningly elusive. All of us admit we're disturbed at being gripped by so odd a conviction so ill-supported by the physical evidence. None of us is a lunatic. We speculate about what it would mean if invisible dragons were really hiding out in garages all over the world, with us humans just catching on. I'd rather it not be true, I tell you. But maybe all those ancient European and Chinese myths about dragons weren't myths at all.

Gratifyingly, some dragon-size footprints in the flour are now reported. But they're never made when a skeptic is looking. An alternative explanation presents itself. On close examination it seems clear that the footprints could have been faked. Another dragon enthusiast shows up with a burnt finger and attributes it to a rare physical manifestation of the dragon's fiery breath. But again, other possibilities exist. We understand that there are other ways to burn fingers besides the breath of invisible dragons. Such "evidence" -- no matter how important the dragon advocates consider it -- is far from compelling. Once again, the only sensible approach is tentatively to reject the dragon hypothesis, to be open to future physical data, and to wonder what the cause might be that so many apparently sane and sober people share the same strange delusion.

--- Excerpt from The Demon-Haunted World

Fade out of focus windows in xmonad with xcompmgr and transset

Assuming that you have xmonad already installed on an ubuntu (or other debian based) machine:

• Install xcompmgr and transset:

sudo apt-get install xcompmgr transset

• Add the following to your .xprofile:

xcompmgr -c&

• Add the following to your xmonad.hs:

import XMonad.Hooks.FadeInactive
myLogHook :: X ()
myLogHook = fadeInactiveLogHook fadeAmount
where fadeAmount = 0.4 --or 0xdddddddd etc
main = xmonad defaultConfig { logHook = myLogHook }
-- replace defaultConfig with your config class (ie gnomeConfig if you're using gnome+xmonad)

• Restart your x session (logout)

• Done

Sources:
http://serverfault.com/questions/29866/using-compiz-with-xmonad

http://hackage.haskell.org/packages/archive/xmonad-contrib/0.8/doc/html/XMonad-Hooks-FadeInactive.html

http://wiki.archlinux.org/index.php/Xcompmgr

Alex Martelli is a python encyclopedia..

http://www.aleax.it/python_mat_en.html

Gnome + Xmonad

From http://markhansen.co.nz/xmonad-ubuntu-lucid
Here’s how to run XMonad as a drop-in replacement for gnome’s default window manager (Metacity):

Install XMonad. Open a terminal and enter:

sudo apt-get install xmonad

Configure XMonad to interact happily with gnome. Make a file ~/.xmonad/xmonad.hs, and put in it:

import XMonad
import XMonad.Config.Gnome
main = xmonad gnomeConfig

Compile this config file by typing xmonad --recompile at the terminal.

Tell gnome to use xmonad instead of metacity. At the terminal, enter:

gconftool-2 -s /desktop/gnome/session/required_components/windowmanager xmonad --type string

Log out and log back in and you're done.

NOTE: To revert back to Metacity from XMonad, at the terminal, enter:

gconftool-2 -s /desktop/gnome/session/required_components/windowmanager gnome-wm --type string

Blogging for more than a year..

It's been more than a year since I started this blog. Wow. When I started the blog, I was working on finishing off the Shopgreen site, a site that was very well tested and laid out, but got no love (it really was kind of a dry project) from the higher ups.

A year ago today, I had just started on the CNN Trivia project for Red. Wait scrap that, I was waiting to get started on the trivia project and still working on shopgreen site while waiting for the 'producer' to figure out what to do. That project pretty much soaked up my time from July until it eventually finished after some delays in October, but was still ready for the re-launch of the Cnn site.

After that project I basically sat around for 3 weeks until I was let go the week of thanksgiving. Thanks, assholes. After that, I was annoyed with the whole prospect of having to work for another crappy non-engineering company and took the month of December off.

I started looking again in January, and with no work and no interviews beyond one at the beginning of the month, I started to get worried about paying to bills and actually applied for unemployment. But the interview earlier in the month panned out and I was able to tell the employment office that I didnt need unemployment after all.

February started with OpenID.. a crappy configuration hell project which made me doubt my skills as a python programmer due to bug after frustrating bug, most of which were in the repoze.who openid implementation. But at least I learned a ton about wsgi.

March brought the end of the OpenID project as it turned out OpenID didnt really provide what the tech lead wanted after all. At the end of the month I started on the Asset Admin project which entailed finally having to give up avoiding javascript/html/css. I've actually become rather good at it, but I'm still not entirely enthused about having to work on js/html projects.

In April I finished the first portion of the Asset Admin, the Playlist Editor, but due to work overload on the tech lead, it was never released. I completely rewrote Playlist Editor 5 times due to having to learn js/jquery at the same time, but in the end I was proud of the result. At the end of April I started on the second part of the Asset Admin, the Media Picker which was basically a continuation of what I had learned from Playlist Editor.

During May I continued working on the Media Picker, updating Playlist Editor as I learned more javascript/jquery tricks. Around this time I took the plunge into really understanding CSS. I got the two sub projects looking pretty good. I finished Media Picker and started on the last piece, the Asset Editor towards the middle of the month. I worked hard to make it so that the Asset Editor could be used anywhere (with Playlist Editor or Media Picker) and still look the same (no shifting of images or changing of heights).

But in June, the whole backend project which the Asset Admin was an administrative front end for was basically canceled through a decision by the parent company to allow serving of media through youtube and facebook etc. Everyone scrambled around looking for work until we started work on the current project which I'm not too keen on working on, the dashboard project, which is basically just a nice display of a bunch of CEO porn (aka random statistics about various things that are applicable to the company).

Non work related, I played soccer! From February '09 to August '09, I played soccer with the team we had at Red. Not since I was 17 in high school had I last played, but I was still one of the better players on the team. Surprisingly, one of the most artsy guys at the office was the best player on the team. We played for two seasons in which I had the most goals for our team the first season (3: headed the ball over the defender then blasted it in, the penalty kick, and the loose ball calm shot) but only got one second season (left footed shot!) That being said, we were a pretty sorry bunch with more than half the team having never played soccer before. Most scores were around 8-0 or some such.

In August, for the end of soccer party, I got drunk for the first time during an epic 14 hour pub crawl. Just a bunch of guys from the soccer team talking and drinking. Good times.

In October, the trainer I had been working out with for the past year finally opened his own gym. I trained with him in the gym as he was still building it; before the pull up bars were up, before the rubber mats were down. Previously we had been working out at one of those small gyms that big apartment complexes provide as an incentive to move in, but nobody really uses. And before that we were at some place in Monrovia which was owned by some guy who reminded me of a shorter smaller version of Mitch.

In November I got drunk for the second (and probably last) time during another pub crawl for JR's birthday. Wasn't as great as the first time as I ended up getting sick at the end of the night and had to crash at JR's place.

In December I did almost absolutely nothing.

In January I managed to find a job while continuing to save tons of money.

In February, my gf got a roborovski hamster (Hammie). A neurotic and seemingly suicidal hamster that is bascially crippled by fear. After a few weeks of having the hamster hurl itself from great heights to escape us, the gf got a second hamster. This one is a much more hamster-y hamster which we named 'Cookie'. Cookie lets us pet her and is very aware of heights and is generally adorable.

In April, for my birthday, the gf bought a second damn dog on complete impulse, chopped all her beautiful hair off, put on 15lbs, and was a complete bitch. The three weeks after my birthday she was basically the most unfriendly and bitch that I've ever known her to be. On several occasions I was bound and determined to call it quits, but I remained calm and kept telling myself that she was just going through some rough times. She eventually came out of it.

And so there's a year.

Windows Key remapping

So today I wanted to remap more than just capslock -> lctrl. I searched around a bit to try and find scan codes for registry hacks but didnt find much. I did find, this little tool, which is great but you need to make sure that you're editing boot mappings and not user mappings.

Go to Mappings-> Show and select 'Boot Mappings' to ensure that you're editing the right keys.

The "Big Lebowski" Office Management Method

Keesey: We'll just let stuff happen, man

jbum: "go with the flow"

Keesey: It'd be beautiful, you dig?

jbum: if a meeting wants to happen, it'll happen, dude

jbum: otherwise, it wasn't meant to be

Keesey: free your calendar and your mind will follow

wickedSA: the "big lebowski" office management method

Suppression.

"There are many hypotheses in science which are wrong. That's perfectly alright. It's the aperture to finding out what's right. Science is a self correcting process. To be accepted, new idea's must survive the most rigorous standards of evidence and scrutiny.

The worst aspect of the Velikovsky affair is not that many of his ideas were wrong or silly or in gross contradiction to the facts. Rather, the worst aspect is that some scientists attempted to suppress Velikovsky's ideas.

The suppression of uncomfortable ideas may be common in religion or in politics, but it is not the path to knowledge and there is no place for it in the endevour of science. We do not know beforehand where fundamental insights will arise from about our mysterious and lovely solar system and the history of our study of the solar system shows clearly that accepted and conventional idea's are often wrong and that fundamental insights can arise from most unexpected sources."

- Carl Sagan: "Cosmos" Ep.4 - Heaven and Hell. It's on Netflix.

The Tedious Questions..

Q: In SQL what does 'Group By' do?

A: The GROUP BY statement is used in conjunction with the aggregate functions(avg, sum, etc) to group the result-set by one or more columns. Note that only the columns used by the GROUP BY statement can be used in the SELECT statement.

fred| 100
bob| 100
fred| 400

SELECT Customer,SUM(OrderPrice) FROM Orders
GROUP BY Customer

fred| 500
bob| 400

Disable Ease of Access in windows 7

Finally found a command that will completely disable Ease of Access in windows 7. On the command line, run

cacls %windir%\system32\utilman.exe /C /D Everyone

and hit Y when prompted. This will remove the functionality behind that stupid button on the windows screen and will stop the stupid ease of access dialog from popping up when you're typing in your password to the login page.

How to ask (and answer) a question

Asker (1): Heys, is the requirement that the service provider 'client' part be in a wsgi module?
Asker (2): I've got my test stuff running in a tornado instance simply for ease of development (dont have to setup/configure apache... simple yes, but still dont have to do it)
Answerer (1): i want to wrap wsgi things with it, in a wsgi serving framework -- sounds like it'd be a wsgi middleware of some sort
Answerer (2): tornado is completely different
Answerer (3): we're not gonna redo everything to use tornado
Answerer (4): you don't need apache for anything
Asker (3): ok, that's why I was asking

So the above is a recent q/a session that took place a few moments ago in the real world. There are a number of problems with this q/a session. We'll start with the asker first.

Asker line 1 is fine. It asks the question 'is it a requirement that something be done in a certain way'. Asker line 2 is trouble. It's adding potentially confusing details to the question which the answerer has to evaluate and determine if to ignore it or not.

Answerer line 1 is a perfect answer to line 1, but as we can see in answerer line 2, the answerer picked up on details in asker line 2 which were extraneous to the actual answer. This is common for people who are very detail oriented and don't let needless details slide. In doing this though, answerer is now making assumptions about asker and briefly discussing Tornado and Apache, which the asker didn't ask about. This is even more of an issue on the internet and potential flame bait when it comes to online discussions since asker can become annoyed that the answerer has assumed that asker doesn't know what tornado is or what apache is needed or not needed for and respond with inflammatory comments such as 'that wasnt what I asked, asshole' or some such.

This simple example illustrates the reason that brevity is not only the soul of wit, but the key to good communication. Ask simple questions, give simple answers, ignore needless details when required (either answering or asking).

New Year's Python Meme

So I'm a bit late to the party, but there's meme going around python developers to discuss what they've done/discovered in the past year in a q/a manner. So here's mine.

1. What’s the coolest Python application, framework or library you have discovered in 2009 ?

Would have to be Twisted. I've avoided Twisted for a while now since I was always told that it'd hurt your head if you tried to get into it and that it wasn't very pep8 friendly, but it turns out it has some pretty good tutorials (the Finger tutorial) and that a lot of the stuff is useful right off the bat (such as the chatserver).

Non-Python:
The Lua language. It's not that it's all that cool, it's just another language and not as nice as python, but it's pretty cool in that it lets you create mods for games pretty quickly (in this case Demigod.. which is a great game that needs some help at this point).

2. What new programming technique did you learn in 2009 ?3. What’s the name of the open source project you contributed the most in 2009 ? What did you do ?
New programming technique would have to be constructor patterns that I learned from a very good Flash developer and the Refactoring book that he introduced me to. I mainly learned it by working through the refactoring example with my girlfriend on a automation project she had for her work.

The open source project I contributed the most to would have to be the PIL and python-payflowpro and only in the sense that I submitted bug reports (tho I submitted work around code for the issue with PIL).

For 2009, I worked entirely on two large web projects. One an online trivia game, and the other a credit offset reseller site. The credit offset site was fantastic in that the code was completely developed with TDD and had about 10-15 tests per function. I didn't start a single class or function without having the test code written beforehand. The trivia game had the potential to be fun, but I had to make accommodations for stupid managers and constant changes to what was wanted. I simply should have said 'No' more often, but it's hard to do when your excited and want to make everything cool.

4. What was the Python blog or website you read the most in 2009 ?

I read Planet Python which is an aggregation blog of a bunch of well known Python bloggers... so I guess I've been reading lots of blogs. Also, lots of StackOverflow.

5. What are the three top things you want to learn in 2010 ?

3 things for python in 2010?

1. Hadoop and map/reduce. I'm already familiar with the concepts, but I'd like to get some actual experience with it
2. pyGTK and pyGame. I'd really like to get into gui programming.. even tho cli rules.
3. Ctypes.. I've been meaning to read up or do a tutorial on ctypes for a long time.

Non-Python:

1. How to make mods for games (in particular, Demigod). For a long time I've played games and kept notebooks on what was cool, what was stupid and what I would do differently in the hopes that I would eventually learn how to create a mod of a game. I've been investing a lot of time in games and there's a lot of stuff that I'd like to tweak. Demigod is very open to modding with the Lua language so I'd like to finally start and complete a mod for a game.
   

Decemeber 2009: my month of quiescent perseveration

We repeat ourselves. The mind perseverates. The road is rutted and grooved, and beside the road are familiar ditches.
-- Eric Maisel