miércoles, 30 de diciembre de 2009

startup lessons

Y combinator (Paul Graham's company, and hacker news hoster) publishes a list with links that talk about startups. Many of them are Graham's past articles (worth reading nonetheless).

I've quickly scanned the list, and some of the articles linked, and it seems quite interesting, so worth pointing it here.

As I don't have anything else to add, I'll just post an image I saw yesterday at #perl6 channel @freenode. It's funny and, maybe can add information if you are deciding what language will you base your startup on.

It's a pity there's no perl there.

martes, 29 de diciembre de 2009

Binary search and dumb compression in Common Lisp

In my quest to learn lisp, I've been alternating scheme and common lisp readings and lectures.

I find scheme really enlightening, but quite difficult to write in it. Maybe it's because I haven't officially reached the set! chapter in SICP, and I still find difficult to write (so) functional code.

The point is that I finished this book and then, I started Paul Graham's ANSI Common Lisp. I've been really enjoying this reading, because it shows you interesting things (from an experienced programmer point of view) from the very beginning.

During the first 3 or 4 chapters, threre are some code examples, that I've tried to write on my own (maybe grasping a bit on graham's code when I got stuck, but well)

First, here's a compress/decompress lists lisp code. When entered a list like (0 0 0 1 2 1 1 0 4 4), compress returns a list of atoms or lists themselves, that contain the number of repetitions and the value to repeat: ((3 0) 1 2 (2 1) 0 (2 4)) . It's nice to see that at such low level point, being able to ask for a type of a given element gives us enough power to code this in a very simple way. I don't even want to think how I'd code it in java/c++.

Decompress does obviously the reverse operation

The binary search is just what its name says. Does a binary recursive search on an already sorted vector (array of 1 x N dimension).

I'm getting very fond of 'cond'. It takes the best things of both if and switch/case worlds. A switch-case like syntax, with powerful conditionals (not just comparing with '=')

That's all for now. Sorry for the crappy gists code listings. it seems github doesn't know much about common lisp (syntax nor indenting).

Btw, I've received my SICP copy in dead-tree format, so I'll probably spend some time with scheme when I finish Ansi Common Lisp.

Oferta de trabajo

Aquí voy a trabajar yo.

viernes, 25 de diciembre de 2009

Programmers, improving productivity and salaries

Hello dear reader,
Today you'd better be prepared for a mashup post of several sites and articles about programming (in the most generic sense of the word), improving your programming skills, and what people think about how to divide the programmers set into two subsets: good ones, and bad ones {disjoin,complete}. Lots of links, yeah. It all depends on the time/willingness at your disposal.

Learn to program
Learning to program is not an easy thing, nor something that can be achieved in 21 days (see Peter Norvig Teach yourself programming in 10 years). But the nice thing about programming is that you can learn by practice, and start with babysteps, and improving little by little, learning about new paradigms(lisp,Io,haskell are nice tools for that), reading highly recommended books (you can get lots of them legally for free on the internetz), or joining a Opensource Project to learn from others.

Little by little, I feel how I get the knowledge, sometimes through slow readings, and sometimes with sudden "OH FUCK!, AHAHA!". This moments when your brain 'clicks' (mostly in functional programming) are priceless. I hope to have achieved a good level of programming skills in a couple of years. For the moment: keep learning.


Keeping the interest for something is very difficult nowadays, with so many potential distractions (beer,friends,girls).

What can keep you motivated to keep learning? I've no f*cking idea. For me, it's a mix of several things:

  • Keeping in touch with good hackers. This really pushes me to keep learning. I've found it priceless. After someone told me about Barcelona Perl Mongers, I joined them, there I met great programmers (now friends), and we could even start collaborating. Nowadays I'm at Barcelona.PM , GTSmalltalk and flibug.
  • Collaborating in some project is good to keep hype on something.
  • Open a new project to play with it.Even if it's nothing serious, but you'll get in touch with git/mercurial, and can try things as you learn elsewhere.
  • Be humble. Keep reminding yourself that everything you do, can be improved. Having a (false) feeling of superiority makes you lower the bar. However, of course, if you think you did something well, you can give yourself a cookie, pat your shoulder and show the code to your friends :)
  • IRC. yeah, ircing on freenode has teached me lots of things.
  • Keep it fun. please
Listen to the masters
Masters are so for a reason. foreach problem you may have now, they have "been_there_done_that", so listening to what they have to say it's very valuable.

I'll just paste some links, about guidelines to improve your coding. They tend to be very general (and language agnostic), from the well known "comment code", to "follow idioms". For me, knowing the idioms of a language has been a great improvement to feel more self confident when writing and reading code. Reading reddit and hacker news from time to time can show you new people to follow. (ALERT!: Addictive)

there are guidelines that can be splitted in small chunks and read a paragraph on a daily basis. I've been doing this for some time, and I think it's very useful. I've doing this TipOfTheDay style reading with "Perl Best Practices" and "Pragmatic programmer" too.

Other are more like checklists. Anyway, there are lots of similar lists.
Hire programmers
Here are some essays about recognizing a good programmer. It's interesting how most points in theese latter essays match with the points on the upper links in this thread. I guess we're on the right track.

UPDATE (09/12/30): In HN there has been linked a site with a programmer competency matrix according to knowledge of a given programmer. I don't know how useful or fair it is, but it matches quite good with my ideas. I'm glad to be between level 1 and 2 (mostly 2, and hey, there's level 0 ;) ) and I am in some level 3 situation, or will be in couple months (estimated time). I think it also leaves it misses some other important points, and eventually, real productivity can only be measured after the work is done. Mind you it's not easy to measure productivity (see "office enabler" below)


But, do great programmers (that can be 10x more productive than average ones) earn that proportional money? Clearly no. Read the complete article by John D.Cook.
It reminds me of the "office enabler" role I talked about last august.

martes, 22 de diciembre de 2009

1984. You never pushed that.

Rewriting history is one of those things we all would want to do at least once in our lives.

Well, unfortunately, I don't have a solution for that, but in the computer world, you know... we even have ctrl-z !

But when things are uploaded to external server or repository, it's not that easy. Until git.

I accidentally pushed a 600Mb file to a git repo that (luckily) never changed, but when I cloned the repo, I had to wait for several minutes until git downloaded the 30+ Mb file (git, or at least github compress files).
git filter-branch -f --index-filter 'git update-index --remove filename' HEAD
git push --force --verbose --dry-run
git push --force
With just theese lines, you can pretend you never uploaded it. The only thing to keep in mind is that you should work on a up to date working copy.

Now you could even convince Winston Smith in room 101 that a given file never existed.

Scared? Yeah, you should be.

domingo, 20 de diciembre de 2009

Dos hablando

- Es una pena que las mejores cosas de la vida, sean ilegales...
- Lo dices por las drogas?
- Nono, lo digo porque lo pienso de verdad.

viernes, 18 de diciembre de 2009

git clone and pull remote branches

I thought that when I pushed/pulled branches in git, I only acted on the active branch (unless I specified it).

Well, that is not (entirely) true.

The problem is that when I clone a repo, I can't specify a given branch, and git only seemed to fetch the master branch.

When you clone a repository, you fetch all branches, with all the history (I thought that happened in hg but not in git, well anyway).

What happens then, if I don't see other branches than 'master'?
git branch
And you'll only see master branch. Other branches are hidden. To see them you should type:
git branch -a

So your branches are effectively there. To use any of them, you should
git checkout -b local_branch_name origin/remote_branch_name
I think what that line does is create a new branch and filling it with the fetched branch with that name, and bind the pull and push paths to the remote ones.

Another way?

In other sources, I've found that simply pulling with:
git pull origin Branch_name
will do the same, but, when I tried it, it downloaded/extracted the files, but without changing to the branch name.


Now the question is:

What happens if I modify two branches, and then just "git push" ? will it push both branches? That's what I'll try in next days, and after a bit of experimenting, I'll post back.

Btw, here are a couple of links you can read for a bit more info.

domingo, 13 de diciembre de 2009

info is power

In planet emacs, I discovered that there's a version of SICP in info format.

If you don't know what's SICP, it is a computer science book about programming fundamentals, that teaches you how to think about programming, and algorithms in general.

I'm reading it little by little because there are many deep concepts that I need to interiorize with some extra time and rereads. The book is freely available in html format. There are other sites that offer a pdf version, but this info version at http://www.neilvandyke.org/sicp-texi/ , sounds like a great option, because I'll be able to read it in any info pager, without relying on slow pdf viewers, or having to be online and use a browser.

after downloading the sicp.info.gz file , I installed it moving the file to a info suitable place (/usr/share/info and /usr/info are good places for vectorlinux).

To make it available from info's top menu, you should add a link line in the 'dir' file, or you can use intall-info.

As I had my info 'dir' file somewhat outdated, that's what I did to rebuild the whole dir:
for i in $(ls /usr/info/*) do install-info $i /usr/info/dir
now, when I type "info" in my command line, I get a 2362 line info index and among library infos and so, there's
* SICP: (sicp). Structure and Interpretation of Computer Programs

Sorry, no puns, no music links, no OMFGWTFORLYFAIL links today.

jueves, 10 de diciembre de 2009

ǝʌısuǝɟɟo ʇsod sıɥʇ puıɟ I

Once upon a time, not in the west but in a far far not-very-reputable-site that I visit (too) often, I saw a few comments with letters flipped upside down.

After doing some copypastes, I decided to write a 10 line script to translate normal text to flipped text.

I had to deal with unicode chars (I never had to do this before), and I came with this little script, that isn't awesome nor cool, but it can make some friends happy (Txor), and adds -Ofun to programming.

miércoles, 9 de diciembre de 2009

mapping through many lists, perl vs lisp

Last night (or this if you prefer), I was reading about lisp mapcar function, and I mentally mapped it to perl's map. (More precisely, I was reading exactly page 224 (or 232) of This book)

In fact, they do quite the same, but mapcar (that is a specialized form of lisp's map) seems a bit more flexible because it can deal with many lists at once (perl's map can't, at least by default).

First we start with a usual applicative programming case:

For example, generating a list with the square of each element in another list.

perl version looks like this:

my @squares = map { $_ * $_ } @mylist;
map { $_ * $_ } (1..10);

lisp version. As lisp does not have the equivalent to (1..10), we can build a list builder by range :
(defun range (a b)
(loop for i from a to b collect i))
(range 1 10) => (1 2 3 4 5 6 7 8 9 10)
(mapcar #'(lambda (x) (* x x)) (range 1 10)) => (1 4 9 16 25 36 49 64 81 100)
That's the full interaction we have to do with lisp. define range function, test it, and then use mapcar. Notice that common lisp (unlike scheme) is a lisp-2, so has a namespace for variables and another for functions, so we have to provide the sharp quote, that refers to the function.

So far so good.

But when things get trickier is when you want to evaluate a function that takes two parameters and you want to get the parameters from two lists.

lisp mapcar can do it by default. (nice, eh?)
(mapcar #'+ '(1 2) '(2 1)) => (3 3)
Doing this in perl is not that straight, but it is possible, and you know, TIMTOWTDI:

A nice trick is doing a little mind change , and shift the point of view. You can take the index as the iterator, and get something like:

map { $a[$_] + $b[$_] } 0..$#a ;
Btw, remember that if you feed 2 or more lists to map, it will append them and treat as if only one list was entered.

There are other ways to get the map functionality, using some List::MoreUtils functions.

For example, if you only want to operate on two lists, you can use pairwise:
pairwise {$a + $b} @a , @b ;
There's also each_array, that builds an iterator , and with it, you can browse N arrays step by step.

As a last hacky resort, you could use zip (or mesh, they are the same) to build a new list like (11,21,31,12,22,32....) (I hope you get what I mean) , and then use natatime.

Want more perl ways to do it? Check that stackoverflow thread.

Plenty of options, yes, I know. For me, I stick with good old map {..} 0...$#a ;

As always, thanks to #emacs-es'ers for patiently answering my Offtopic lisp questions.
And thanks to Larry for the language that makes programming -Ofun.
And remember, comments allowed, even encouraged. :-)

domingo, 6 de diciembre de 2009

Common Lisp "beginner" books

Instead of writing my final degree project, I've spent the afternoon reading about lisp, and I found out that to learn lisp (in fact, to learn any language), it better to get a book and read it throughtfully than read a bit from here and a bit from there.

Maybe it's because I've already read a bit from here and a bit from there, now I can read 3 or 4 chapters in a row from a book.

Anyway, I'm going to put here a couple of them that seem specially good:

Ansi Common Lisp : Not free, but you can get the first two chapters for free from paul's site. Reading the first 100 lines conviced me about it. great style of writing and going right to the point.

Successful lisp: Free. Great (at least the first 3 chapters) Very well explained, and with good and well thought examples and code listings

sábado, 5 de diciembre de 2009

search in multiple buffers in emacs and vim

Want to look for a word in a number of buffers?

No problem, emacs can do it with a simple command (the problem is remembering hundreds of "simple commands" :/ )

emacswiki gave me the solution .

The command is multi-occur.

It lets you select in which buffers you wanna perform the search.

My use case though was knowing in which irc channels appeared a given user.

Then, the command is:
  C-u M-x multi-occur-in-matching-buffers
it lets you write a regex for buffers to search, so I wrote "#.*" , and then the word.

As simple as it can get.

Thinking how I'd do it in vim, normally I'd do a normal grep (using ack) or vimgrep, but as emacs can map buffers to non-files, grep wouldn't work.

Vim offers quickfix window that can be easily combined with both grep and vimgrep, and one can download theese two plugins. AFAIK none of theese plugins can search in some but not all opened buffers.

Any other vim solutions are very welcome.

viernes, 4 de diciembre de 2009

Perl December

Yay! It's december. At first, this doesn't seem that exciting, but every perl hacker knows a few facts related to december.

  1. Advent Calendars are here again
  2. Christmas is near.
This week I've been coding some perl, and revisited some practices/modules I've been some time without using.

I'll try to explain some of them, that I found particularly useful.

Starting a project

Although this is a small app, and could be thought as a script, following the "always code as if you uploaded the code to cpan", I used Module::Starter with Module::Install. I could have used Dist::Zilla, that seems to be more DWIM-ISH , but well, I already had the "magic" module-starter line, so

module-starter --module=My::App --author="Raimon Grau" --email="raimonster@gmail.com" --builder=Module::Install

Object oriented perl.

I used a simple OOP interface. As noone at $work follows the perl world , I decided not using Moose, and used plain OOP. I used a bit of sugar with Class::Accessor, so attributes accessors and mutattors could be autogenerated.

use base 'Class::Accessor';
__PACKAGE__->mk_accessors(qw/attr1 attr2/);

When there is some error, for example, opening a file (it may not exist), I couldn't just die (dying from a lib is not nice), nor warn, so I used Carp module, to get more informative info about when the code errs.

Testing and Pod Coverage

I did some tests to validate my code (at least some basic things), and also ran Pod coverage (module-starter added the test automatically).

In vanilla OOP perl, you can't write private methods (at least, easily), but there's a convention of methods begining with '_' being private helpers.

Pod::Coverage, a tool that ensures you write documentation for all your methods, also follows this convention, so you can leave _functions uncommented. Great way to guide you to best practices. There's also more sophisticated ways to use it.


Having to manipulate CSV files, I had a few options, but ended using Text::CSV__PP.
I needed only basic features so everything went ok with this.


Having to deal with paths and files typed by users is annoying because of trailing '/'. For example, you can easily end with a path like "/home/user//this/isa/pathFile".

Perl provides File::Spec::Functions::catfile to sanitize those cases. Great finding.

To dump structures, I've used Data::Dump, that, prints the smaller output (linewise).

Meanwhile, I've been enjoying both lhp and pp2 Casiano's courses. Seriously, I think it's jewel in the crown on spanish perl courses.

That's all for this post.

Remember, be nice, and fight for your rights. Well, fight for theese rights too. And theese.

miércoles, 2 de diciembre de 2009

A ver como me levanto mañana

Hay días que me voy a dormir pensando que todo es una mierda, y en comprarme un arma que me extinga. Hay otros que pienso que podría haber estado peor.

Hoy es de los segundos.

A ver como me levanto mañana.

martes, 1 de diciembre de 2009

Better perl dumps than Data::Dumper with xxx::yyy

Sometimes I feel like I don't have a path to follow in the perl world. There's always more and more to learn, and one can't seem to explore all similar modules to do a given task.

For example, some time ago, I posted about Data::Dumper::Perltidy, a way to better format D::D output.

Since then, I've been exploring some other options to do similar things, and today, as I had to start a new project at $work, I decided to give a stab at those other Dumper modules.

I Dicovered a few other modules to dump data, that can also be used for marshalling.

Data::Dump :Really small output, arrays are joined in a single line (if it fits)

Data:Dumper::Concise : Nice options for Data::Dumper, it prints sub codes, and prints \n in strings with newlines instead of the newline char. When its output is evaled, it delievers the same code and data (sub code is there!)

Data::Dump::Streamer :Highly configurable dumper. I haven't tested it. From what I've read, it seems to be the most complete dumper, ideal for complex things, but overkill for simple dumps.

Data::Inspect: Quite small output, very simple to use, and inspired in ruby's p and inspect functions. It has support for printing complete objects.

I haven't pasted examples as you can find them in the cpan page of every module.

Btw, writing perl at $work is great and makes me feel more productive than any other language/task I have to use/do. I'll try further Data::Dump, and Data::Dumper::Concise, and see how does it feel.