In these last 4 years, A LOT of things happened, and 99 (this is the hundredth) posts were written and published here. I still wish to keep writing on this blog for years to come, and to celebrate the mark of 100 posts, I compiled a list of “the best” posts until now. Actually, the list consists of posts that I find the most personally memorable, or “famous” (by number of readers). There they go (in ascending chronological order):

• Why I DEFEND online piracy:
  http://joaopizani.hopto.org/2009/04/pirat

• The very beginning of my interest in Haskell (the programming language):
  http://joaopizani.hopto.org/2009/05/haskell-start

• A humble explanation of why I think that the P vs. NP problem is interesting:
  http://joaopizani.hopto.org/2009/10/p-np

• Just got a scholarship from the german govt. to study German in Germany:
  http://joaopizani.hopto.org/2009/10/winterkurs-2010-dusseldorf

• Pathetic attempt at writing poetry in German SOME PEOPLE liked it, though:
  http://joaopizani.hopto.org/2010/06/deutsch-die-grunde

• Final project of an elective course taken during my bachelor in Computer Science. One of the coolest project I ever developed:
  http://joaopizani.hopto.org/2010/07/guitar2midi

• The peak of my enthusiasm about SSH and everything remote-access related. How to work around firewalls:
  http://joaopizani.hopto.org/2011/02/ssh-over-ssh

• Summary of several very useful “tricks” that I use in daily life at the shell:
  http://joaopizani.hopto.org/2011/04/shell-magic

• My B.Sc thesis (for dummies :P):
  http://joaopizani.hopto.org/2011/04/tcc

• Just got a scholarship to take part in the Utrecht Summer School in Functional Programming – The Netherlands (my future graduate school):
  http://joaopizani.hopto.org/2011/05/buitenland

• Hilarious commit comments in my bachelor thesis’s SVN repository:
  http://joaopizani.hopto.org/2011/07/tcc-logs

• How was life during the 3 weeks as a Summer School student in Utrecht, 2011:
  http://joaopizani.hopto.org/2011/09/utrecht-leven

• My completely random musical taste (no ordering or explanation):
  http://joaopizani.hopto.org/2011/09/muziek1

• Playing with music synthesis “from scratch” using Haskell:
  http://joaopizani.hopto.org/2012/01/haskell-synth

• Conway’s “Game of Life”, with a GRAPHICAL simulation interface, implemented in Haskell:
  http://joaopizani.hopto.org/2012/01/haskell-kata-game-of-life

• Experimenting with Android x86 inside VirtualBox:
  http://joaopizani.hopto.org/2012/02/android-ics-virtualbox

• A completely digital AM transmitter using Arduino:
  http://joaopizani.hopto.org/2012/04/arduino-am

• I am going to study for a master’s degree in The Netherlands, YEAHHHHH!:
  http://joaopizani.hopto.org/2012/06/sol-iustitiae-ilustra-nos

• A thank you note for Alan Mathison Turing, forefather of this science which I study and love so much:
  http://joaopizani.hopto.org/2012/06/alan-mathison-turing

• A simple-to-use but effective spreadsheet template to manage your personal finances:
  http://joaopizani.hopto.org/2012/08/personal-finance-spreadsheet

• My humble rtorrent config file, organized and self-contained:
  http://joaopizani.hopto.org/2012/08/rtorrentrc

• GNU Screen for the win:
  http://joaopizani.hopto.org/2013/03/screenrc-ftw

• An Embedded Domain-Specific Language for ants in Haskell:
  http://joaopizani.hopto.org/2013/03/haskell-ants-edsl

• A great Vim workflow distribution, modular, documented and self-contained:
  http://joaopizani.hopto.org/2013/03/modular-xplatform-vim-cfg-with-lasers

• My master’s, the “oficial” reason of why I came to The Netherlands:
  http://joaopizani.hopto.org/2013/03/msc

Having already written here on the blog about how daily life goes around here, and about some nice things I have been doing on my free time, I feel the time has come to finally talk about why “officially” I am here: the time has come to talk about my master’s degree program in Computing Science at Utrecht University.

More specifically, I will try to explain exactly what the hell I am studying and I intend to do in the (close) future… The official name of the program I am following is “M.Sc in Computing Science”, with a specialization in the “Programming Technology” study track. The program takes an average of 2 years to be completed, and is a research master’s, which means it is supposed to prepare the student for academic research. Here in The Netherlands there is a very clear difference between “professional” degree programs (which usually take 1 year) and research programs (taking 2 years). Our study track (Programming Technology) includes courses on topics such as functional programming, the implementation of programming languages and environments, optimization, compilers, etc. That is, everything which “underlies” programming languages and the environments on which they run.

To give you a detailed view of what I am studying / will study, nothing better that a diagram showing all the courses I have taken / will take:

In the Experimentation Project (INFOEPCS) and during my thesis, my intention is to do research related to massively parallel programming in a functional style, or the high-level synthesis of hardware using a functional approach. At least, that’s what I WANT. There is, however, still a lot of talking to be done with the concerned professors during the following months… :)

Now that we are talking about time, I will try to explain how the academic calendar works here in Utrecht: Each course is offered during a period of time called a “block”. Each block lasts for (on average) 11 weeks, and each academic year is divided in 4 blocks. And again, an image is worth 1000 words, so there you have it: my academic calendar, with the “schedule” of all the 8 blocks that comprise my master’s program:

As you can see, we have very few free weeks around here… :P Of course, there is summer vacation (6 weeks) and a little Christmas break (10 days). But besides that, there is NO BREAK between any two blocks. There are some “retake” weeks, in the middle of the blocks, in which you can retake exams you eventually missed in the previous block, but those weeks are in THE MIDDLE of a block, which means that most teachers just keep giving you the normal workload as always…

Even so, with all this, I can’t really complain. The work is hard but, at the end of the day, I like what I am doing. The courses and all projects require a lot of effort, but they are also inspiring :) I am keeping a “repository” here in the blog with the files of all courses I have already taken in the master’s program (1st and 2nd blocks), exactly as I did with my bachelor’s.

Among all the work I have done for all courses until now, I can highlight two projects as the most interesting:

• Generic Pandoc: Final project of the “Generic Programming” course. It involved a case study on how to apply generic programming techniques in Haskell to improve Pandoc.
• Haskell Ants EDSL: Final project of the course “Advanced Functional Programming”, consisted of designing and implementing a Domain-Specific Language (embedded in Haskell), to take part in a Ant Colony Simulation competition. I wrote a post here on the blog about this one.

So, that’s all for now! Until the next block(s)!

This video is part of a project created by the University if Canterbury (New Zealand) and also sponsored by Carnegie Mellon and Google, and that had as its (initial) goal to show children (around 10-13 years old) what Computer Science is REALLY all about. They have developed a nice series of activities that instigate the curiosity of the children and make them understand the fundamental concepts of, among others: binary codes, compression, sorting, searching, human-computer interaction, information theory and public-key criptography.

I was VERY enthusiastic about the whole idea, and also a bit jealous of those kids: they had a more deep and INSPIRING class on Computer Science than several CS bachelor students get from their lecturers! This video also inspired me and reminded me once more of an old dream: teach Computer Science to schoolchildren. So, there you have it, the AWESOME “CS Unplugged” video:

Around June 2012 I wrote a post here describing my very own Vim config “distribution”, that was the result of several months of DAILY, intensive use (and tuning and refactoring) of this editor. This distribution is completely modular and self-contained. Besides, I try to follow closely the principle of “graceful degradation”. But, what does that all mean?

• Self-contained means that, by using Vim with this config distribution will not “spill over” files all over your filesystem. They will ALL be in a SINGLE directory. To clean everything up, just delete that single place. Also, you can move the distro wherever you want, you can put it on a thumbdrive and use it on any computer.
• Modular means easier to understand and adapt/improve, both for me and for other people. The “distro” is made of a consistent and small choice of plugins, along with files containing “reasonable defaults” for these plugins.
• Graceful degradation means that I try to do the most that I can, but imposing as little requirements on your system as possible. If something can’t be enabled, it just stays out of the way, with no annoying errors. Also, the defaults try to be as non-invasive as possible. The most frequent an action is, the simplest it should be to perform it.

So the good news is that since last summer this vim distribution improved a lot, and I consider it now stable and useful enough to be interesting to the general public of programmers using Vim for work and fun, as well as for beginners who want to see this awesome editor in full glory…

So without further ado, it’s pointless to repeat here what is already being said in the README file, hosted on the GitHub repository of the project. Go there, follow the instructions, have some fun, see if you like it and send me some criticism/suggestions :)

I developed this project together with my colleagues Liewe Thomas van Binsbergen and the portuguese guy with the longest name I’ve ever seen: João Miguel Queiroz de Ataíde Agorreta de Alpuim. As a final project for the course, each “team” of students had to submit an entry to a competition that involved the simulation of ants searching for food in an environment. This “task” was also the one selected for the programming contest of the International Conference on Functional Programming in 2004…

The official task description defines an assembly language for the ants, and that the ant colonies of the two teams will fight in “rounds” in a championship (with random maps chosen for each round); in each round the goal is to collect the most food possible at your anthill after a certain amount of time. The championship was run in a simulator, and the following animated gif shows how a small part of a simulation might look like:

In this example, our team is the “red” team, and we are competing agains the all-time winner (in blue). Even though in this particular example we are losing by a long shot (there is little food in our hill), we weren’t so bad when competing with our classmates…

Anyways, the project (uploaded to GitHub) is not about ant assembly, but about Advanced Functional Programming, so you might ask “What the hell does this all have to do with Haskell?”. The answer is simple: our real task was to implement an Embedded Domain-Specific Language (EDSL) in Haskell, allowing to express with a high level of abstraction the strategies we wanted our ants to follow. The “deliverables” of the project, thus, were twofold:

• Ant EDSL library: A high-level API, made of fundamental strategies and of combinators allowing the user to build more complex strategies from simpler ones.
• The strategies themselves: Using the developed API, we needed to hand in two strategies (ant assembly files), that would take part in the championship against the rest of the class.

Our EDSL was developed with a layered architecture, where the the evaluation of user-accessible functions in the API resulted in a value of type AntImperative, that was then converted (compiled) to proper ant assembly. This paradigm of EDSL is called “deep-embedded”. In the following figure, you can have an idea of how the project is structured:

Also, here it goes one of the basic strategies we submitted for the contest, so that you can have an idea of how it “feels” to write strategies in our EDSL:

This particular strategy was based in the fact that ants born in the hill’s corners (each anthill had 6 corners) would draw “highways” with pheromones, that would mark a quick way for other ants to go back home whenever needed. Besides this, ants that found food would also leave a “trail” of pheromones leading to the highways, and these trails would consist a kind of “local roads”.

Finally, as a prize for your pacience in reading this post until here :), you can take a look at the slides that we prepared for the presentation of the project (click on the image to start the download):
presentation-ants-edsl-afp2012

That’s it! As soon as I have another cool project to show you guys, I will tell more about it here… See you soon! :)

Well, while the “core” of these customizations remains the same, some things changed in the last months: I organized and factored the configuration even more, published it on GitHub with a very nice README file and also added some new functionalities…

Some of the keyboard shortcuts were improved, some were added, but the biggest additions are related the Screen’s multiuser mode: something which is very useful for remote pair-programming sessions. So, there you have it, take a look at the simple instruções and start using Screen in a much more efficient and comfortable way :)

PS: To be able to unleash all the power of all the customizations, you need to be running a reasonably recent version of Screen. Unfortunately, most Linux distros are unreasonable, and still ship very old versions of Screen… If you use some Debian-based distro, you can download the recent Screen .deb package (from Debian Unstable). In the case you use Arch Linux, there is a recent Screen package on AUR.

Just the smart people will get it:

Just because “ones = 1 : ones” was too much of a boring example…

I am VERY excited with the whole experience, as you all probably already know, and can’t wait to board that plane. On the other hand, however, I am going to miss my family and old friends a lot, I am going to miss everything that we experienced together in Brazil, specially in those last days here.

I will ALWAYS remember fondly all my experiences on this land. I don’t WANT to forget my roots. Even if I WANTED, though, I could not… I am what I am because of you, I do what I do and think what I think because of all we lived together and all the ideas we exchanged…

See you in the next posts, already on dutch land! Au revoir! Até mais! Tot ziens!

PS: This is the result of emptying my room :P

As malas – The suitcases – De Koffers

My idea is to use an OLD laptop that I have lying around as a dedicated seedbox, running 24/7. So, I was looking for a robust, powerful and configurable torrent client (able to run months without having to reboot), but at the same time, this client needed to use little CPU power and memory. Fortunately, I found this FANTASTIC BitTorrent client: it’s called rTorrent, was developed in pure C++, geared towards performance and reliability, and is a nice console application.

After a lot of googling and a lot of trial-and-error, I was able to come up with a very nice rTorrent config file (.rtorrent.rc), that satisfies all my requirements for an awesome torrenting setup. These requirements are:

• Periodical speed throttling: Download and upload speeds are adjusted depending on the time of day, to not overload my work bandwidth
• Close after reaching seed ratio: Removes a torrent download from the active queue after it has reached a certain seed ration (for example, 200%)
• Start downloads based on the contents of a directory with torrent files: Monitors a specified directory looking for the addition of files with the *.torrent extension and starts the corresponding downloads
• Separation between active and finished downloads: Stores files BEING DOWNLOADED in a specific directory (“content-in-progress”) and moves finished ones to another (“content-finished”)

This config file (rtorrent.rc) is available at GitHub, and you can download it from here. After downloading the file, do the following to complete the setup:

mv [where-you-downloaded-rtorrentrc] ~/.rtorrent.rc
mkdir ~/torrent

# Option 1) If you dont have a current download directory structure
mkdir ~/torrent/{session,metafiles-{in-progress,finished},content-{in-progress,finished}}

# Option 2) If you already have favorite places to store in-progress and finished downloads
mkdir ~/torrent/{session,metafiles-{in-progress,finished}}
ln -s [in-progress-path] ~/torrent/content-in-progress
ln -s [finished-path] ~/torrent/content-finished

Anyways, if you want to know more in-depth what the lines in this file do, I will now make a review of each of this config file’s “sections” :)

THe first line in the file tells us in which directory rTorrent stores its internal “session”. This directory should never be deleted while rTorrent is running.

Now we define the directory where rTorrent should keep downloaded data while it’s being downloaded.

The following lines define minimum and maximum limits for the number of peer connections while downloading or seeding. I obtained these numbers by “emprirical” observation suring months of usage, and they work very well in my network (with a bandwidth of about 10MB/s).

The next configuration establishes that after we reach a certain “seed ratio” (in this case, 200%), the torrent should be automatically closed and removed from rTorrent’s list. This is so that you can collaborate with the spirit of file-sharing, but NOT INDEFINITELY :) Besides, new downloads are not initiated with too little free disk space:

What follows are miscellaneous settings (enables DHT, cryptography, defines port range), and there’s nothing VERY special about them. The only setting which you should pay attention to is “port range”. You must set this option to a range which is open (forwarded) in case you are behind a router nas/firewall.

Now for a vey important section in the file: we define an automatic upload/download speed throttling, depending on the time of the day. The settings which follow are the ones which I LIKE THE MOST. In my case, I want the bandwidth occupation to be smaller in the MORNINGS and EVENINGS (that’s when I am most likely at home and using the computer).

Almost done now; we say to rTorrent that it should monitor a certain directory (“~/torrent/metafiles-in-progress”) for the addition of files with extension “*.torrent”. Files added to this directory will cause the start of a corresponding download in rTorrent:

And finally, the last lines in the config file ensure that INCOMPLETE (only incomplete) downloads have their data files removed, whenever the corresponding .torrent metafile is removed (or when the download is removed from the list in rTorrent). Besided, finished downloads are moved to a special directory (called “content-finished”), while the metafile itself is archived for posterity, under “metafiles-finished”.

So that’s all, buddies! From now on, with rTorrent installed and configured in my seedbox, I just need to throw any .torrent file inside the “metafiles-in-progress” directory, and leave all the rest of the work with rTorrent. It will ensure that I keep being fair to the community (by ensuring a miniamal seed ratio) and then put all finished downloads in a special folder, ready for me to use them :)

If you want to get, use and adapt this configuraton file I have just shown, go again to the beginning of the post, download the file and follow the instructions…