The declarative style of a Makefile (or substitute your own language-of-choice’s implementation of *akefiles) lends itself well to scientific processes, where a reproducible method is crucial. I recently found this out when analysing some data, which consisted of the following: compile the source code of the programs I was using use these programs on the same data plot some summary plots show the plots With the declarative style of Makefiles I could rely on the latest results no matter what changed in the analysis path, for example the plot scripts used in step 3.

So IPython has updated to version 2.0. The full changelog can be found here and to summarise the key points: interactive widgets for the notebook directory navigation in the notebook dashboard persistent URLs for notebooks a new modal user interface in the notebook a security model for notebooks I want to discuss a few of these and my thoughts on how they make IPython notebook finally an incredibly powerful tool for research, more so than before, and how I may be finally switching from simple scripts to using the notebook full time (with a major caveat!

I was trying to play with PyMC3 and as per usual with code under heavy development the tutorials were out of date, and the code wouldn’t run. When I say “out of date” in fact the code ran but no valid numbers were produced. The API seemed to be consistent though. I managed to get the tutorial to run by installing the following: Theano==0.6.0 pymc==3.0 scipy==0.13.3 PyMC3 was installed from git from the pymc3 branch as follows:

So I’ve done some very dickish things as a darkwraith in Dark Souls, mostly involving firestorm. I’m certain my stories are not the worst but they’re probably some of the worst things I’ve done! I’m leaving this here as a confessional of sorts, but also a great place to leave my invasion stories. Some context: these stories were probably performed on my SL1 dickwraith character, using a +5 chaos battle axe for max damage.

So I’ve been playing with Puppet and Chef for server provisioning. The two technologies attempt to fill the same, or at least similar tasks: managing system configuration. With Vagrant, testing these two systems has become extremely easy. Vagrant supports both methods for server provisioning and the turnaround time for the tests is extremely short. I have tried for quite a while to run chef on a system, to no avail. I’ve often found that an unexpected crash puts end to my testing, whereas the first times I tried puppet I achieved success.

Git quick is a simple shell command I’ve written for quicker one line messages. It allows committing like g q A simple commit message Note the lack of quotes. Some things I’ve used to make it quicker: alias git to g in my zshrc alias q to quick in my gitconfig file put the git-quick script into my path somewhere The script The script really can’t be much simpler:

I started having trouble with vim crashing for me. I’m on OSX with homebrew and rbenv, and it crashed when editing Ruby files. I would get a segmentation fault. After some googling which was not particularly fruitful, the solution I came up with was: switch to the system ruby rbenv shell system uninstall vim completely with homebrew brew uninstall vim reinstall vim from head brew install --HEAD --override-system-vi vim This seems to have fixed the problem, though I do not know if it was switching to the system ruby or installing from head.

So I’ve been watching a lot of OO refactoring screencasts and reading posts and I’m able to say I’ve implemented some of the advice I’ve heard. Life’s all about learning eh? So the main example I want to talk about here is Null objects. Null objects In dynamic languages, and Ruby in particular1 the concept of the lack of something needs to be encapsulated. For example: you’re wrapping the database and no entry exists; what to you return?

Ok so after my previous post, I was feeling pretty excited about Ruby. I talked about its power and flexibility and the exciting things that could come from it. I also talked of Ruby’s scariness, it’s ability to terrify new programmers and potential for difficulties. I’ve found one particular example which I’m sure shouldn’t be allowed. I can see the intention and how in experienced hands it is amazing, but I can’t unsee it’s potential for misuse.

So I’ve been trying Ruby recently, partially trying to add some substance to my CV, and partially out of curiosity. I used to be a complete python snob; I didn’t understand why anyone wouldn’t use python. It is a dynamic language so no more manual memory management (though there are plenty of advantages cough cough); duck typing deserves its own special place in hell but it is bloody convenient; the amazing standard library which is great for system administration; and many other things.