Martin Fowler on Refactoring @ RubyRogues

I stumbled on a Ruby Rogues podcast yesterday, which had Martin Fowler as the guest. I really enjoyed the discussion on Refactoring (the noun, the verb and the book!)

Martin clarified in the podcast that refactoring (the verb/process) is a sequence of very small refactorings, while you keep making sure that you can run the test suite always. A refactoring (noun) is a change where you change the structure of the code without any externally observable changes, with the intent of making it easier to understand and cheaper to change in future.

I also really liked the metaphor of a 'healthy code base'. Refactoring is, then, the process of keeping healthy – exercise, speaking metaphorically. You can stack up all the exercise you need to do, until you get really unfit. Refactoring, similarly, needs to be done regularly, to keep the code base healthy. This lets you go faster, in the future.

I also really liked the advise about trying to push back the mental contexts you build, while trying to debug/understand some code that is not very clear, by refactoring the code to make it clearer. Code needn't be one big chunk of cryptographic text. Code is writing. It should be clear and understandable. Or, at least we should strive to make it so!

The discussion, as always on this podcast, was very lively, pleasant and enjoyable! Enjoy!

Learning about Spaced Repetition, SuperMemo, Org-drill, et al.

I have been reading a bunch of articles on the SuperMemo site (including the original thesis of P. A. Wozniack, the creator of SuperMemo). I initially started off trying to understand the algorithms SM2,5 and 8 which org-drill implements, but reading the articles has given me a lot of general background and theory on how memory works, and why SuperMemo is as effective as it is (for those who stick with it). This blog post is an attempt to summarize and capture what I have read in all those articles, and not get lost in them. I would recommend reading the thesis and the suggested reading there, yourself, but if you really don't want to – this blog post + the summary in here, and here would be a good alternative.

  • Memory works by repetition. Each time you recall a fact, the time it takes for the memory to fade increases. Spaced repetition is the idea of repeating items, just when you are about to forget them – trying to optimize the time spent on learning, as well as the retention of learned material.
  • Prioritization of the items we need to learn is key to being able to stick to Spaced repetition. Beginners tend to be over-enthusiastic about the technique and fill up their system with stuff that they don't really care about. Applicability of the knowledge you are trying to gain, is a good test for whether or not it goes into your system.
  • Each version of SuperMemo comes with a slightly modified (on most occassions, improved!) algorithm. SM2, SM5, … refer to these algorithms. Org-drill currently supports only sm2,5 and 8. It may be worth looking at sm15/16 and seeing if it can be implemented and is worth doing. In any case, using any of these is way better than not using Spaced repetition at all.
  • Understanding what we are trying to learn goes a long way in helping memory. It is, therefore, good to start with basic material. People have been surprised by how easily the advanced stuff fell into place, once they had the basics covered.
  • Keep items in the system simple. Stick to the minimum information principle. Keeping it simple, doesn't mean you leave out on learning the complex stuff; instead break it into simpler components. Simpler items has the following advantages:
    • Simple is easier to remember.
    • Simpler items are easier to schedule. You get more resolution to figure out what the problem areas are.
    • Simple makes brings in redundancy automatically. And redundancy is good for memory, just like it is for managing hardware failure.
  • Keep learning fun! Don't make review sessions a chore. Think about the material you are reviewing. Edit/delete/improve items based on your reviews, then and there. Stay active.
  • It is useful to add a link to the source of the items added to your system, considering that you wish to use the system over a long period of time (ideally, the rest of your life!)
  • Prioritize, add examples, appeal to your emotional state, link to existing knowledge, use images. Anything else that works for you! Use all of these techniques, that work well and you probably already use in everyday life, in the items you add to your system, to make them easier to recall.
  • Being physically fit and healthy is important for being so mentally. Exercise, sleep, eat well, avoid caffeine.
  • Try incremental reading, as an input source of items into your memory system.

Simple org-clock and gnome/pidgin integration

See update below

I have been trying to get back to using org-mode and its clocking functionality, more often than not. I used to use it a lot, a few years ago, and haven't been using it, since I had been in my last job.

To help with it, I decided to integrate clocking in and out with changing status on Pidgin, and turning notifications on and off in Gnome. Here's a few lines of code that does this for me.

(defadvice org-clock-in (after pc/org-clock-in (&optional select start-time))
  "Turn gnome notifications off."
  (dbus-send-signal
   :session
   "org.gnome.SessionManager"
   "/org/gnome/SessionManager/Presence"
   "org.gnome.SessionManager.Presence"
   "SetStatus" 2)
  (shell-command "purple-remote setstatus?status=unavailable"))

(defadvice org-clock-out (after pc/org-clock-out (&optional switch-to-state fail-quietly at-time))
  "Turn gnome notifications back on."
  (dbus-send-signal
   :session
   "org.gnome.SessionManager"
   "/org/gnome/SessionManager/Presence"
   "org.gnome.SessionManager.Presence"
   "SetStatus" 0)
  (shell-command "purple-remote setstatus?status=available"))

Update <2014-11-01 Sat>

@baali tried to use my code, and it turns out it didn't work for him, because I forgot to mention that (ad-activate 'org-clock-in) needs to be run, after the defadvice code. I have no idea how it worked for me, without doing that. May be because I have defadvice for other functions?

Also, while debugging this, I found that defadvice is a deprecated way of doing this, and add-function is the way to go now. But, instead of advising the function, I decided to make use of org-clock-in-hook.

Here is the new code.

(defun pc/turn-off-notifications ()
  "Turn gnome notifications off."
  (dbus-send-signal
   :session
   "org.gnome.SessionManager"
   "/org/gnome/SessionManager/Presence"
   "org.gnome.SessionManager.Presence"
   "SetStatus" 2)
  (shell-command "purple-remote setstatus?status=unavailable"))

(defun pc/turn-on-notifications ()
  "Turn gnome notifications back on."
  (dbus-send-signal
   :session
   "org.gnome.SessionManager"
   "/org/gnome/SessionManager/Presence"
   "org.gnome.SessionManager.Presence"
   "SetStatus" 0)
  (shell-command "purple-remote setstatus?status=available"))

(add-hook 'org-clock-in-hook 'pc/turn-off-notifications)
(add-hook 'org-clock-out-hook 'pc/turn-on-notifications)

Making PyCon India better (for myself)

I've ranted before about PyCon not meeting my expectations, and I even skipped going to the last PyCon. Somehow, I hoped that it would be better this year, but no such thing happened.

  • I should strictly not attend any talks, at the next conference I am at. Even if the topic seems interesting, I should refrain from attending any talks, unless I know that a speaker is entertaining.
  • I should be going there to meet old friends, meet a few new people, and mostly hacking on my stuff. May be aim to show something at the lightning talks at the end of second day, based on what I did during the rest of the event.
  • Participate more actively in open spaces, and may be initiate or suggest some myself. Sprints for bug fixing, adding new features to a project may be a good way to get new developers to start contributing to FOSS projects. It would be even better to be in touch with folks before the event, and use this opportunity to iron out kinks.

I think the talks could be improved drastically. A lot1, 2 has been said, already. Here's a summary of how I see it.

  • Beginner/Novice talks doesn't mean bad talks. A talk with a good narrative, that drives home a point, that may be familiar to most of the audience, would still make a good talk. I don't mind reading a good blog post/book on a topic I already know, because there is joy in reading/listening to "good" stuff.
  • Talks cannot be judged by titles or an abstract. Taking inspiration from PyCon US, we could
    • Ask for a video recording of a previous talk or a short home-made recording of the speaker presenting some topic.
    • Ask for a granular outline 3 along with rough timing information, instead of just an abstract.
    • Have a bunch of resources 4, 5, 6 available for speakers to improve on their proposals/accepted talks.
    • Have a bunch of 20 or 30 minute talks, and very few longer (45 min) talk slots.
    • Encourage speakers to try connecting their laptops and iron out "presentation" kinks on the day before their talks/lunch/other allotted times. Technical issues like fonts being too small, mics not working, adjusting the volume/other settings for the speaker, etc. can and should be fixed before hand.
    • The talk review committee could also take notes from attending some of the talks, and compare it against their notes when they accepted the talk, to improve the talk selection process. Some of it could be valuable feedback for the speakers too.

Learning to use Org-drill

Org-drill is an Org-mode extension that provides spaced-repetition and flash-card functionality. It has a wonderful documentation on Worg, but somehow I couldn't get myself to read the whole document, and setup org-drill, until now.

The setup is quite straight forward, once you have org-mode along with the contrib packages. Just (require 'org-drill), and you are all set! To add a new card, all you need to do is add a :drill: tag to the items you wish to "Org-drill". You can start a review session with simply M-x org-drill. You will be shown flash cards, and you can rate how correct and comfortable you were, in answering the questions. Based on your responses, the cards are scheduled for review. Start another review session, whenever you need one!

What I could only understand once I got myself to read the whole document was that:

  • The default scope of a drill session is the current file. But, you can start sessions with scopes like current tree, current directory, or a specified list of files. This is super-useful!
  • The review sessions are not automatically scheduled, based on when you schedule failed flash-cards. Scheduling the review for a card only sets a due-date for them, and effects, what you are asked in your next session.

Cram mode and incremental reading are also things I want to try, as I go along.

Happy Learning!

Bookmarks [2014-10-10]

Recurse Center, 2014-08-28

All good things must come to an end, and so did our batch! We got our Hacker School t-shirts, and had a super fun picnic at Prospect Park.

Recurse Center, 2014-08-27

  • I spent the whole of yesterday just working on the LED-bot.
  • Spent some time cleaning up meta-stuff about the project, making it a real package, adding a setup.py, added LICENSE & AUTHOR files, etc.
  • I found it really frustrating that there's no good/standard way to remove duplication of information between pip's requirements.txt and install_requires
  • We got the bot running on the Beagle Bone, but it turned out to be too slow. After some playing around with trying to get rid of Python for-loops, I was able to use PIL's image.tobytes and some image cropping to get the data to be sent to the LEDs, and it sped up the display quite a bit.

Recurse Center, 2014-08-26

  • I spent most of the day refactoring the code for the LED Bot, and am happy with the way it looks right now.
  • My talk at Hack and Tell went OK. I was distracted by live_reveal not displaying properly on the smaller resolution, and not being able to mirror screens!
  • There were a bunch of interesting talks presented by the others. http://comparea.org, Taxis and Rainbows were the most interesting ones for me.

Recurse Center, 2014-08-25

  • I spent some time cleaning up my gitqus code. I plan to try it out on a "real site" today, and do a little polish of the UI.
  • I worked with Dana and Marcus fixing a bunch of issues with the HS LED Screen. I might work on it for a little bit today, doing a little more clean-up of the architecture.
  • The Monday talk was Mary live coding a space invaders game. It was a fun talk, that was very well planned.
  • During the walk to the talk, Bert, Maia and I were talking about the idea of a School where projects were the atom of the curriculum, instead of courses.
  • I'll spend some time preparing my talk for tonight's hack-and-tell.