Maybe Technology

#Occupy

2011-11-20T14:04:00.000Z

"We have nothing else cheap left to exploit. We are completely in danger from lack of culture. We were all trained up to be consumers...throw away the past, the future will take care of itself, catch the latest thing and suck it up." -- Vivienne Westwood, addressing Occupy activists (http://www.bbc.co.uk/news/uk-england-london-15806945)

"There is no doubt in 1933 that the collapses of the older systems which we witness are probably irrevocable. Sir Auckland Geddes, the British Ambassador to the United States of America, foresaw them when he said in 1920: 'In Europe, we know that an age is dying. Here it would be easy to miss the the signs of coming changes, but I have little doubt that it will come. A realization of the aimlessness of life lived to labour and to die, having achieved nothing but avoidance of starvation, and the birth of children also doomed to the weary treadmill, has seized the minds of millions.'" -- Science and Sanity, p. 49, Alfred Korzybski

What does 'human' mean? What differentiates human from animal? Alfred Korzybski suggested we classify life on Earth as follows:

Plants: static, synthesize sunlight and other chemicals in order to grow. Hence we define them as 'chemical-binders'.
Animals: like plants, they synthesize chemicals to grow, but also have the ability to move around. This movement in 'space' differentiates plants from animals and hence we define them as 'space-binders'.
Humans: like plants, synthesize chemicals to grow, and like animals move around in space. Humans add to this the ability to learn from previous generations - one generation can start from where the previous left off. This ability to transmit knowledge across time leads to the definition of humans as 'time-binders'.

Korzybski argues first in Manhood of Humanity, and later in Science and Sanity, that this definition of humans as 'time-binders' describes functionally what humans actually do. One only needs to look around to verify the claim. The presents from the past rest all around us.

The time-binding capacity of humans means that I can learn from Korzybski, despite the fact that he died 60 years ago. I can learn from Einstein, despite the fact he died 60 years ago. I can learn from Aristotle, despite the fact that he died 2000 years ago. Civilization arises because of the time-binding capacity. Imagine a world where every generation starts afresh, unable to use the fruits of the previous generations' efforts. We would still be living in the trees, picking flies off each other.

"NYPD & Brookfield have taken the People's Library again. and we love you all." -- https://twitter.com/#!/owslibrary/status/136970287601291265

By building a People's Library, the Occupiers in NY implicitly recognized the uniquely human capacity of time-binding. Bringing together books in that way honours the time-binding capacity that defines humans. What does destroying them signify?

So far, the mass media has focused on the occupation of 'space' in cities all around the world. But this space-binding activity is incidental to the more important time-binding activities, the creation and propagation of memes.

OWS Teach-In with Douglas Rushkoff from Douglas Rushkoff on Vimeo.

Pepper spray doesn't work against ideas. You can't kettle a meme. Animalistic, space-binding tactics may work in the short-term, but in the long-term, human-nature, the time-binding capacity, will assert itself.

To live life as a human means to live life in order to learn and progress, not simply to labour and die. To live a life of culture, rather than consumerism. To exercise the uniquely human time-binding capacity.

Literate Programming with Marginalia

2011-08-14T13:10:00.000+01:00

Here is the source code of the project I'm working on at home, formatted by Marginalia: http://neillalexander.github.com/rtm-clj/uberdoc.html.

I love it. Having something so beautifully formatted really motivates me to write comprehensive documentation. I'll be using it in all my Clojure projects from now on.

The set up was fairly straightforward, so I won't go through it in depth here. Once I had it working, I wanted to find an easy way to publish the updated documentation, and make it easily readable on-line. The solution was GitHub pages, and git submodules.

Here's what I did:

Set up a project page for the project using instructions at http://pages.github.com/.

Added that branch as a submodule of the main source code in the docs directory.

git submodule add git@github.com:NeillAlexander/rtm-clj.git docs
cd docs
git checkout gh-pages

Created index.html which redirects to uberdoc.html
Back up to the parent directory and run 'lein marg'

Running 'lein marg' creates a new version of uberdoc.html in the docs directory, which is actually the gh-pages branch of the overall project. Pushing the change therefore makes it available at http://neillalexander.github.com/rtm-clj/uberdoc.html

Simple Arity Checking Using Higher Order Functions

2011-08-13T00:59:00.000+01:00

As a learning exercise I'm writing a little command line tool to connect to Remember the Milk using Clojure. The idea is that the tool is a mini shell (or repl) which reads commands, executes them, and prints the result.

The commands are written as simple Clojure functions. When I type something at the command line, the command is looked up in a map and, if found, executed, passing the rest of the arguments.

For this to be safe I need to check the arity of the function matches the number of commands entered at the command line.

For example:

When I type 'help' then all the available commands are returned:

rtm> help
(echo exit help)

If I type help with an argument, then it still works, because help is multi-arity, and has an implementation that takes an argument:

rtm> help command
Help for command

If I type help with more than one argument, the arity check kicks in and refuses to call the function:

rtm> help won't work
help: wrong number of args
Help for help

It took a bit of thinking to work out how to do this, but I eventually came up with the following solution.

;; higher order functions rock!
(defn arity-check
  "Returns a function that evaluates to true if the arity matches the count"
  [arglist]
  ;; special case - if arglist is of zero length then no need to check for & args
  (if (= 0 (count arglist))
    #(= % 0)
    (let [arg-map (apply assoc {}
                         (interleave arglist (range 0 (count arglist))))]
      ;; if & args found then number of args is >= the position of the &
      ;; otherwise it's just a simple size comparison
      (if ('& arg-map)
        #(>= % ('& arg-map))
        #(= % (count arglist))))))


;; this builds a collection of functions, one for each of the arglists
;; which evaluates to true if the number of args matches the arity of the
;; arglist. it then applies each function in turn against the size of the
;; args, and determines if any of them returned true. if at least one of
;; them returned true, then we can safely do the call
(defn arity-matches-args
  "Returns true if the args match up to the function"
  [f args]
  (let [arity-check-fns (map arity-check (:arglists (meta f)))]
    ((set (map #(% (count args)) arity-check-fns)) true)))

The arity-check function takes an arglist, as returned from the meta-data of a function. This is a higher order function which returns a function that evaluates to true if the number passed in is assignment compatible with the arity of the arglist.

e.g. if the arglist is [x] then 1 argument is expected. If it is [x y] then 2 arguments are expected. If it is [& args] then any number of arguments >= 0 are expected. If it's [x & args] then any number of arguments >= 1.

The arity-matches-args function calls the arity-check for each of the arglists in the meta data of the function, and stores them in a sequence, arity-check-fns. It then calls every one of those functions passing in the number of arguments in args, and generates a set of the results, which will be either true, false, or nil. It then uses the set as a function to see if it contains true. If it does then at least one of the arglist arities matches the number of arguments that have been entered.

There is probably an easier way to do this...but I'm still proud of this solution. It opened my eyes to the power of higher order functions

The source code is at https://github.com/NeillAlexander/rtm-clj

Will Clojure Ever Be 'Finished'?

2011-08-06T10:24:00.004+01:00

Clojure, as a Lisp dialect, is an extremely malleable language. The lack of syntax lends itself to creating domain specific languages. The built-in meta-programming (macros) means that anyone can add new language features. In contrast, adding new language features to Java requires a lengthy process of negotiation and compromise via the JCP.

If you give someone Fortran, he has Fortran. If you give someone Lisp, he has any language he pleases. -- Guy Steele

Will we hit a point where Rich and the Clojure/Core team regard the core language as complete? In other words, will Clojure hit a stage where it is rich enough (no pun intended) that there is no further work required, other than to write new libraries? This seems plausible to me, and perhaps even desirable.

I'd be interested to hear Rich Hickey's view on this.

Update (18th November): at the Clojure / Conj last week, I had the opportunity to put this question to Rich. He broadly agreed with the point, saying that the core language is basically done, and that the remaining work is mostly around the edges.

Lazy Sequences

2011-07-31T14:08:00.000+01:00

I like this a lot:

;; define a function with a side effect to show when it is called
(defn square [x]
  (do
    (println (str "Processing: " x))
    (* x x)))

;; define map-result which is result of calling square for every item in the list
(def map-result (map square '( 1 2 3 4 5 6 7 8)))

First time, enough of the lazy sequence is evaluated to generate the result:

practical-clojure.chpt5> (nth map-result 2)
Processing: 1
Processing: 2
Processing: 3
9

The next time, with the same args, the previous calculation was cached, so nothing to evaluate:

practical-clojure.chpt5> (nth map-result 2)
9

The next call it needs to evaluate a couple more of the lazy sequence:

practical-clojure.chpt5> (nth map-result 4)
Processing: 4
Processing: 5
25

And again, this is cached:

practical-clojure.chpt5> (nth map-result 4)
25

This is possible because a sequence looks like:

first --> (rest)
first --> (first --> (rest))
first --> (first --> (first --> rest))

Rest is only evaluated when it is required.

Auto Save a File in Emacs

2011-07-31T09:36:00.000+01:00

Download http://www.litchie.net/programs/real-auto-save.html to .emacs.d, and then:

;; real auto-save - forces auto save mode
(require 'real-auto-save)
(add-hook 'text-mode-hook 'turn-on-real-auto-save)
(add-hook 'muse-mode-hook 'turn-on-real-auto-save)
(add-hook 'slime-mode-hook 'turn-on-real-auto-save)
(add-hook 'emacs-list-mode-hook 'turn-on-real-auto-save)
(setq real-auto-save-interval 5) ;; in seconds

Fixing Git Remote Reference

2011-07-31T08:09:00.000+01:00

Did a 'git pull' and saw this:

Your configuration specifies to merge with the ref 'master'
from the remote, but no such ref was fetched.

A quick bit of googling turned up http://stackoverflow.com/questions/4297795/configure-git-so-that-git-pull-instead-of-git-pull-origin-master, which indicated I needed to edit my .git/config file to contain this:

[branch "master"]
remote = origin

The remote = origin line was missing, therefore git didn't know where to pull from.

Auto Complete in Clojure

2011-07-30T12:13:00.001+01:00

This is awesome. My one concern about switching from Eclipse to Emacs for Clojure was losing the handy auto-complete stuff in Eclipse. I no longer have that concern:

Install the auto-complete mode (M-x package-install, auto-complete if using ELPA).

Download ac-slime from here: https://github.com/purcell/ac-slime

Here is the config required to set it up:

;; auto complete
(require 'auto-complete-config)
(add-to-list 'ac-dictionary-directories "~/.emacs.d/ac-dict")
(ac-config-default)
(setq ac-delay 0.5) ;; eclipse uses 500ms

;; configure auto complete to work in slime
(add-to-list 'load-path "~/.emacs.d/ac-slime")
(require 'ac-slime)
(add-hook 'slime-mode-hook 'set-up-slime-ac)
(add-hook 'slime-repl-mode-hook 'set-up-slime-ac)

Counterclockwise Eclipse Plugin

2011-07-05T21:48:00.000+01:00

I'm going to run with Counterclockwise for now, since I'm already very comfortable with Eclipse. Having had a quick play with it this evening it seems to do everything I want, and will only get better.

The list of key bindings is defined at: http://code.google.com/p/counterclockwise/wiki/EditorKeyBindingsFeatures

Balanced brackets only seem to work in strict mode on Ubuntu.

Unfortunately Ubuntu 11.04 has some system key bindings which interfere with the Counterclockwise bindings:

Shift-Alt-Up: bound to Compiz scale windows. Install compizconfig-settings-manager, run "ccsm", and find Scale under Window Management, and disable the key binding.
Ctrl-Alt-T: launches a terminal in Eclipse. Disable via System -> Preferences -> Keyboard Shortcuts

Cljr

2011-07-03T22:15:00.000+01:00

Well this is new: https://github.com/liebke/cljr. A very simple way to move from zero to a working Clojure REPL. All it took was:

wget http://incanter.org/downloads/cljr-installer.jar
java -jar cljr-installer.jar
export PATH=/home/neill/.cljr/bin:$PATH
cljr repl

Clojure Revisited

2011-07-03T22:06:00.000+01:00

In the first half of 2010 I did a bit of programming in Clojure, using it to write a simple debug proxy for SOAP. Although I wrote many lines of Clojure code for that project, by the end I had the nagging feeling that I hadn't written idiomatic Clojure code.

And so, to stop that feeling from nagging, I am going to try to approach Clojure once again with beginners mind. My weapon of choice for this new assault is The Joy of Clojure. I have high hopes that this will help my understanding of the language to move up a level. I hope to be thinking in Clojure by the end of it. And I'm going to record the journey for posterity here.

Reverse Incremental Search in Bash

2011-04-30T09:00:00.026+01:00

I learned a new trick this week. Reverse incremental search through bash history using the up key. This blog post outlines it nicely:

http://codeinthehole.com/archives/17-The-most-important-command-line-tip-incremental-history-searching-with-.inputrc.html

Using these bindings, I can type 'git', then hit the up-arrow to search back through all the recent git commands I've used. This is a really quick way to improve productivity at the command line.

For future reference, just in case the above linked blog entry disappears.

In ~/.inputrc:

"\e[A": history-search-backward
"\e[B": history-search-forward
"\e[C": forward-char
"\e[D": backward-char

In ~/.bashrc:

export HISTSIZE=1000000
export HISTFILESIZE=1000000000

Make it Work First...

2011-04-28T09:00:00.002+01:00

==========
Pragmatic Thinking and Learning (Neill Alexander) (Hunt)
- Highlight Loc. 1277-83 | Added on Saturday, April 23, 2011, 10:06 AM

Author Anne Lamott is an advocate of purposefully creating a shitty first draft. That is, it's better to complete a shitty first draft than to never complete a perfect one. In her book Bird by Bird: Some Instructions on Writing and Life, Lamott explains the dangers of perfectionism: "Perfectionism is the voice of the oppressor, the enemy of the people. It will keep you cramped and insane your whole life, and it is the main obstacle between you and a shitty first draft. I think perfectionism is based on the obsessive belief that if you run carefully enough, hitting each stepping-stone just right, you won't have to die. The truth is that you will die anyway and that a lot of people who aren't even looking at their feet are going to do a whole lot better than you, and have a lot more fun while they're doing it."
==========

Make it work first, then make it better.

Deliberate Practice

2011-04-26T09:00:00.001+01:00

==========
Pragmatic Thinking and Learning (Neill Alexander) (Hunt)
- Highlight Loc. 1067-69 | Added on Friday, April 08, 2011, 08:16 PM

Skills and abilities that you constantly use and constantly practice will begin to dominate, and more of your brain will become wired for those purposes. At the same time, lesser-used skills will lose ground. "Use it or lose it" is perfectly accurate in this case, because your brain will dedicate more resources to whatever you are doing the most.
==========
Pragmatic Thinking and Learning (Neill Alexander) (Hunt)
- Highlight Loc. 1070-73 | Added on Friday, April 08, 2011, 08:16 PM

Perhaps this is why musicians practice scales incessantly; it's sort of like refreshing dynamic RAM. Want to be a better coder? Practice coding more. Engage in deliberate, focused practice as described in the sidebar (here…). Want to learn a foreign language? Immerse yourself in it. Speak it all the time. Think in it. Your brain will soon catch on and adapt itself to better facilitate this new usage.
==========

Over the last couple of years the majority of my personal programming time has gone into 2 largish applications; Sponge and Meditation Helper. The main aim of the first project was to write something substantial in Clojure, and the second to do the same for Android. Both were fun projects to work on. However, I have now decided to change my approach.

Instead of embarking on another application, I am instead using my personal programming time to practice scales. I am writing toy classes to learn apis, libraries etc that I haven't had much experience with, or that I want to learn in more depth. I want to improve as a programmer, and the only way to do that is practice, practice, practice.

Unknown Unknowns

2011-04-24T09:00:00.000+01:00

==========
Pragmatic Thinking and Learning (Neill Alexander) (Hunt)
- Highlight Loc. 376-89 | Added on Thursday, April 07, 2011, 07:58 AM

When you are not very skilled in some area, you are more likely to think you're actually pretty expert at it. In the paper "Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments" [AUOIHDIROOILTIS] , psychologists Kruger and Dunning relate the unfortunate story of a would-be thief who robbed a bank in broad daylight. He was incredulous at his prompt arrest, because he was under the impression that wearing lemon juice on your face would make you invisible to security cameras. The "lemon juice man" never suspected that his hypothesis was, er, suspect. This lack of accurate self-assessment is referred to as second-order incompetence, that is, the condition of being unskilled and unaware of it. This condition is a huge problem in software development, because many programmers and managers aren't aware that better methods and practices even exist. I've met many younger programmers (one to five years of experience) who never have been on a successful project. They have already succumbed to the notion that a normal project should be painful and should fail. Charles Darwin pegged it when he said, "Ignorance more frequently begets confidence than does knowledge." The converse seems to be true as well; once you truly become an expert, you become painfully aware of just how little you really know.
==========

Baby Steps

2011-04-22T09:00:00.001+01:00

==========
Practices of an Agile Developer (Neill Alexander) (Hunt Subramaniam)
- Highlight Loc. 1850-55 | Added on Monday, April 04, 2011, 07:24 AM

When you're driving on a long trip, does it make sense to hold the wheel firmly in one position, stare straight ahead, and then just floor the gas for a couple of hours? Of course not. You have to steer. You have to be constantly aware of traffic. You have to check your gas gauge. You have to stop for fuel, food, and other necessities, and so on.[30] Don't code for hours, or even minutes, without stopping to make sure you're on the right path---by testing what you produce. Instead, code in short increments. You'll find that coding in increments helps you refine and structure the code as you go along. The code is less likely to become complicated or messy; you build the code based on the on-going feedback from writing and testing in increments.
==========

At university, there were people who used to code and code and code and code and code and code and code and code...

Then they'd hit the compile button and wonder why they had so many errors. A lot of them thought programming was 'too hard' because of this.

Commenting Code is like Eating Peas

2011-04-20T09:00:00.006+01:00

==========
Practices of an Agile Developer (Neill Alexander) (Hunt Subramaniam)
- Highlight Loc. 1786-88 | Added on Monday, April 04, 2011, 07:19 AM

Code will always be read many more times than written, so the little extra effort that is required to document your code when writing it will pay you back handsomely in the end.
==========

When I was a kid, I used to leave my vegetables until last. At the end of my dinner I'd be sitting there with an enormous mound of peas, with my mother breathing down my neck, demanding that they be finished before I could leave the table.

I hated peas.

When I was at university learning how to program, there were people in my class who used to leave commenting code until the end. They used to write their entire computer program, then go back at the end and add comments, because they'd lose marks if they didn't provide any.

They hated writing comments.

What I didn't understand as a kid was that peas aren't so bad when you eat them in combination with the rest of your food. In fact, now I think they are delicious. I wouldn't like to eat a giant mound of them by themselves though.

ORM is a Solved Problem

2011-04-18T09:00:00.012+01:00

==========
Practices of an Agile Developer (Neill Alexander) (Hunt Subramaniam)
- Highlight Loc. 864-66 | Added on Friday, April 01, 2011, 08:47 AM

For instance, if you have a hankering to develop your own persistence layer, remember Ted Neward's remark that "object-relational mapping is the Vietnam of computer science." You can spend more time and effort building only what you need to build for your application---the domain or application-specific stuff.
==========

This made me laugh, because I built a persistence layer for a project, then realized after the fact that I should just have used Hibernate. It was a valuable lesson.

The thing is, at one point during the project I was talking to the project manager who expressed his concern at the length of time it was taking to complete the work. I said to him, "Don't worry, I'm not trying to re-implement Hibernate!". Shortly after that conversation I realized that I was, in fact, trying to re-implement Hibernate. It all started very naively - I implemented a solution using Spring JDBC, and then saw an opportunity to extract some higher level abstractions. That process continued to the point that I found myself writing a DSL that would enable me to express the various object relationships, and map them to the database structure.

Hmmm. Object relational mapping you say. That rings a bell.

Object-relational mapping is a solved problem. There are multiple solutions out there. Pick one and use that. Even if you need to learn it from scratch, it will still be quicker than writing your own version.

Rooting for the Underdog

2011-04-16T15:59:00.000+01:00

I installed Cyanogen 7 onto my HTC Desire this week. Along the way I changed the partition table to free up some space for applications. I now have a phone running the very latest version of Android, and space for plenty more apps.

The ability to customize my phone in this way is very important to me. I will never buy a phone that does not allow me to have root access, or that prevents me from installing ROMs with mechanisms such as signed bootloaders. I didn't know about any of this stuff when I jumped from the good ship Apple (see Operation Bad Apple). I bought an HTC Desire because it seemed like the best Android phone at the time. Had I known about custom ROMs and rooting, I probably would have gone for the Nexus One, because for a while it wasn't possible to get full root access to the Desire. It was only when Alpharev came along that this became possible.

Which is why this link is so important - http://unrevoked.com/rootwiki/doku.php/public/root_friendly. It's a list of phones that are amenable to rooting. You'll notice all the newer HTC phones appear in the "poor choices" category. That's because HTC have started signing the boot partition, making it impossible to install custom ROMs. In my eyes, in the space of a year, HTC have move from being the plucky underdogs who need to be supported. to the dicks that need to be ignored. Although I am very impressed with my HTC Desire, there is no way I will be buying any of the newer HTC phones.

Meanwhile, Sony Ericsson have announced that all their new phones in the Xperia range will have unlockable bootloaders. They even provide a web-site to enable you to unlock the bootloader (see http://unlockbootloader.sonyericsson.com/). This is fantastic news, and is likely to win Sony Ericsson a lot of hardcore Android fans. You'll note that the new Sony phones appear in the "root friendly" section of the unrevoked list.

Hopefully this is a sign of things to come, and more manufacturers will follow Sony's lead. If I were in the market for a new phone right now, I'd probably go for the Sony Arc. This kind of enlightened behaviour from phone manufacturers needs to be encouraged.

Context Matters

2011-04-16T09:00:00.012+01:00

==========
Practices of an Agile Developer (Neill Alexander) (Hunt Subramaniam)
- Highlight Loc. 373-75 | Added on Friday, April 01, 2011, 07:53 AM

There is no absolute best, only better. Despite the popularity of the term, there is no such thing as "best practices," only better practices in a particular situation.
==========

In General Semantics we talk about non-elementalism i.e. don't split verbally what cannot be split in actuality. The classic example is talking about 'space' and 'time' as opposed to space-time. Another example might be 'body' and 'mind' as opposed to the organism-as-a-whole.

Everything has a context and must be evaluated in relation to that context.

Speak Up!

2011-04-14T09:00:00.009+01:00

==========
Practices of an Agile Developer (Neill Alexander) (Hunt Subramaniam)
- Highlight Loc. 329-32 | Added on Friday, April 01, 2011, 07:49 AM

We all have some good ideas and some bad ideas, and everyone on the team needs to feel free to express them. Even if your idea is not fully taken up, it may help shape the solution. Don't be afraid of being criticized. Remember, everyone who became an expert started somewhere. In the words of Les Brown, "You don't have to be great to get started, but you have to get started to be great."
==========

Even if the idea that you come up with isn't adopted, it may trigger someone else in the room to come up with a better idea. And that may in turn trigger someone else. Inspiration comes from the funniest places.

I've read a few Edward de Bono books in my time where he talks about using nonsense words to trigger lateral thinking e.g. foo a bike with square wheels might lead someone to think about active suspension in a bike.

Dealing with Problems

2011-04-12T09:00:00.008+01:00

==========
Practices of an Agile Developer (Neill Alexander) (Hunt Subramaniam)
- Highlight Loc. 206-11 | Added on Thursday, March 31, 2011, 09:02 AM

You may not believe this, but not everyone always has the outcome of the project as their top priority. Not even you. Consider your first, "default" reaction when a problem arises. You might inadvertently fuel the problem by saying things that will complicate things further, by casting blame, or by making people feel defensive. Instead, take the high road, and ask, "What can I do to solve this or make it better?" In an agile team, the focus is on outcomes. You want to focus on fixing the problem, instead of affixing the blame. Blame doesn't fix bugs.

==========
Practices of an Agile Developer (Neill Alexander) (Hunt Subramaniam)
- Highlight Loc. 221-24 | Added on Thursday, March 31, 2011, 09:03 AM

On an agile team, the situation is different. If you go to an agile team member with a complaint, you'll hear, "OK, what can I do to help you with this?" Instead of brooding over the problem, they'll direct their efforts toward solving it. Their motive is clear; it's the outcome that's important, not the credit, the blame, or the ongoing intellectual superiority contest.
==========

Compass

2011-04-10T09:00:00.012+01:00

I read about the Compass Project in the book Modular Java. When I next need to add search functionality to a Java application I will definitely be checking it out.

Over Learning

2011-04-08T09:00:00.000+01:00

==========
Pomodoro Technique Illustrated (Neill Alexander) (Noteberg)
- Highlight Loc. 646-56 | Added on Sunday, March 27, 2011, 12:49 PM

Never switch activities in the middle of a Pomodoro. If you finish an activity halfway through a Pomodoro, spend the rest of the time over-learning. For example, if I finish early, I review what I have done, I repeat what I have learned, I see whether I can enhance my work, or I note new conclusions on paper---until the kitchen timer rings. Over-learning is when we continue to study or practice even after attaining proficiency. Malcolm Gladwell argues that this is necessary if we want to be really good at something: "Once a musician has enough ability to get into a top music school, the thing that distinguishes one performer from another is how hard he or she works. That's it. And what's more, the people at the very top don't work just harder or even much harder than everyone else. They work much, much harder.".[32] So, you're not allowed to impulsively switch activities in the middle of a Pomodoro. In fact, just having the option to switch in the middle is a recurring disturbance. You can't just stop in the middle of a Pomodoro and take a break either. Then you will lose the rhythm. And since the stopped Pomodoro was shorter, it will not be compatible---in terms of tracking---with other Pomodori.
==========

I hadn't heard or read the phrase 'over-learning' prior to reading this book. It makes sense, and is something I am looking to adopt to improve my technical / programming skills.

The Pomodoro Technique is, 1 week later, proving to be a useful addition to my personal productivity.

Double Trouble

2011-04-06T09:00:00.001+01:00

==========
Backgammon For Dummies (Chris Bray)
- Highlight on Page 78 | Loc. 989-91 | Added on Monday, March 14, 2011, 07:33 AM

In a game you may make up to 30 decisions about how to move your checkers, but you’re likely to make only two or three doubling of decisions, so taking the time to get them right is worth it. As Paul Magriel said, in his 1976 book Backgammon, ‘Good checker play will never compensate for serious errors of judgement in doubling.’
==========
Backgammon For Dummies (Chris Bray)
- Highlight on Page 99 | Loc. 1245-49 | Added on Monday, March 14, 2011, 08:06 AM

One of the keys to winning backgammon is to double when you have a strong threat, not after you’ve executed that threat perfectly. Remember, your opponent has to have some chance of winning in order to take your double. Winning just one point when you may have won four (via a doubled gammon) won’t make you rich, or leave you satisfied. Of course, sometimes you double and your opponent turns the game around and wins it. You just develop the knack of living with that possibility. If certainty is what you seek, backgammon is probably not for you. If, however, you want excitement, you’re playing the right game!
==========

I have come to the conclusion that backgammon is a solved problem. For any particular roll of a dice there is a statistically best move you can make. Neural net based backgammon bots have proved this. However, you can play a match making the best moves all the way and still lose due to bad dice luck.

So I'm putting my short-lived online backgammon career behind me.