Vim speed is not really the point

Posted on by

500px-Vimlogo.svg

I am a Vim user. And a Vim fan.

I was fiddling around for some time, you know, just knowing the basics, because it is convenient to do small changes on servers without having to worry about installing anything. Just the basics, insert mode, some search, save,

and a couple more things. Then, around two years ago, I decided to give it a try as my main editor, after watching a presentation of a co-worker (my boss, actually) about how to use Vim (he has been using Vim for around 20 years)

At the beginning, it is quite difficult, to be honest. You have to relearn everything about editors. But I was doing OK after one or two weeks, so I kept using it. I was also forcing myself into improving my usage, reading about it and learning tricks…

Then, after a while of using it and read a lot of instructional material (I cannot recommend “Practical Vim” by Drew Neil strongly enough. It’s a FANTASTIC book), everything started to make sense. Let’s be serious, the problem with Vim is not exactly that is “difficult” per se, it’s that it is so alien to any other text edition experience, that you have to forget everything that you know about how to edit text. That’s why I don’t agree that the Vim learning curve is a myth. Because, when we first heard of Vim, we already have 10+ years of using things like Word, NotePad or Gmail to write text. We need time to assimilate how to edit text “the Vim way”. And that takes time to assimilate, as your muscular memory works against you.

And, yes, the Vim way is awesome. But it is awesome not for the reason that usually someone will think at the start. There is the perception that Vim is awesome because is fast. It is not.

Continue reading →

80 chars per line is great

Posted on by

Probably the most controversial part of PEP 8 is the limit of 80 characters per line. Well, is actually 79 chars, but I’ll use 80 chars because is a round number and the way everybody referes to it.

Capture all the experience

Capture all the experience

There are a lot of companies where the standard seems to be “PEP8, except for the 80 chars line restriction”. On GitHub projects, which in general follow PEP8 (it seems to be a very strong consensus), that’s typically not found. In explicit code guidelines, the restriction could be increased (100, 120) or even removed at all. The usual reason for that is stating that we are not programming in VT100 terminals any more, and we have big, high-resolution screens. This is true, but I’ve found that that limitation, combined with the use of whitespace in Python, makes the code much more compact and readable.

It seems that, naturally, Python code tends to occupy around 35-60 characters (without indentation). Longer lines than that are much less frequent. Having suddenly a line much longer than the rest feels strange and somehow ugly. Also, having the mandatory indentation whitespace increase the line width is a good visual way of minimising the nested loops in your code and suggesting, in a subtle way, to refactor anything that is indented more than about four times.

For example, compare this:

Continue reading →

Great female participation on PyCon US 2013

Posted on by

This picture is AMAZING

This picture is AMAZING

I have read that around 20% of PyCon attendees were women. I’m sure I’ve seen it on more places I can’t find at the moment, but is at least here.

This is fantastic news, a great success for the PyCon, the Python community, and specially groups like PyLadies and Lady Coders. The opening statements of Jesse Nollan is a must see.

As I have previously expressed some concerns in this blog about whether requiring a Code of Conduct is the best approach, I’d like to say that I was wrong and it seems that had a positive impact. The CoC is also currently under review, and I’m sure it will be improved. It has also been used with great care, as the PyCon blog shows, which is also something to kudos.

There has also been special programming tracks for kids, which is awesome.

Of course, that is not the end of the road, and there is still much to do, but it is very encouraging. Keep on the good track!

Say NO to web pages adapted to iOS

Posted on by

I really really don’t understand why there are people that think it’s “better” to replace a perfectly good web look and feel for a stupid “adaptation” to iOS with sliding pages and different layout.

I mean, c’mon, If your page does not have a good design to start with, why not changing that? For both web clients and iOS devices. I remember when there the wordpress plugin for iOS was activated by default and all the blogs changed totally their appearance for a kind of “magazine” that, yes it looked good, but was much more difficult to read.
I get to have a responsive design to adapt the web to some sizes (like a mobile device), but changing fundamentally how your site looks and is designed is totally pointless…

There is one thing that is even worse. Apps that wraps a web site, removing all the functionality of the web browser for a stupid and independent, limited app. And even worse, they will constantly will bother you with reminders to download and install a pointless app.

No, just don’t. It is totally stupid. Work on your web page, get a great design, and make easy for the people wanting to read it, well, easy. After all they’re the ones interested in you….

PD: I think the Android ecosystem is similar. The same applies.

Google Reader as a “Be careful with the cloud” tale.

Posted on by

20130321181637!Google_Reader_logoI have been hit by the recent “readerpocalipse”. I use Google Reader daily heavily, and it is THE main access I use to consume information on Internet. I am taking a look at alternatives, and I (and everyone else that used it heavily) will survive. But I am worried about what impact can this have in the perception and operations of cloud services, specially by Google, but also in general.

During the last years, we have seen a lot of cloud services that the perception has been “this is going to be available forever”. Of course, we knew that it was not necessarily the case, something catastrophic can happen, like the company going out of business. But, in general, if it was from a big, profitable and established company (like Google) and it has a critical mass of followers, the feeling was that maybe it was not going to be upgraded, or could have availability problems, but it will be still there. We awake yesterday in a different scenario.

This is going to make me change my perception of cloud services. From now on, I’ll add an extra care when choosing a service, and that will probably make me use them less that I was doing it before. Specially if I start using it a lot, I’ll try to evaluate more seriously plan B’s and ‘what ifs’. Probably that’s a good thing, as I was probably being a little naïve about all this. I was keeping some minimum backups “just in case”, but I will now probably take everything more seriously and try to store less things in “the cloud”.

Internet y el fetichismo de los números

Posted on by

Una cosa que no he entendido muy bien de la “cultura internetera” es esa reivindicación tan fuerte de los “followers”, los “likes” y la difusión mal entendida.

Y de todos, todos los colores

Y de todos, todos los colores

Vale, en cierta medida, si tu blog lo siguen 10.000 y no 10, llega a más gente y (se supone), es más interesante. Sin embargo, especialmente en España, se llega a casos ridículos al querer utilizar los números como arma arrojadiza ante cualquier situación… O, al menos, se justifica todo a través de ello…

¿Que no me gusta lo que has dicho en Twitter? Hago un unfollow que además lo canto a los cuatro vientos: “¡Eh! Que te fastidias que tu contador de seguidores baja, eh, ¡que lo sepas!”

¿Que te peleas con alguien? Sacas a colación el número de seguidores, las visitas a tu página web o el número de reproducciones de un vídeo.

Por no hablar de compañias que “venden” seguidores, tanto en Facebook como en Twitter. ¿Qué valor tiene un seguidor comprado?

Un caso claro es el hecho de mandar todo a Menéame, a pesar de que tus anteriores artículos los hayan puesto a caldo. El caso es que te lea gente, aunque sea una audiencia totalmente distinta a la que (en principio) debería ser tu target… Sinceramente, la audiencia media de Menéame (y otros sitios por el estilo) está tan llena de trolls, que yo nunca pienso que merezca la pena enviar nada, y mucho menos promocionarlo activamente, como hace mucha gente.

Creo que estamos locos. Nos estamos dejando llevar por querer ver “quién la tiene más larga” y no por “quién está más satisfecho con sus relaciones”. El número de seguidores / lectores de tu blog / etc es el tamaño de tu audiencia, pero es mucho más importante la CALIDAD de esa audiencia… Que nos olvidamos de que una visita, sin más, no implica nada. Puede ser alguien a quien no le aportas absolutamente nada (y, por tanto, irrelevante), o, en el peor de los casos, alguien que te pone a caldo sin motivo…. Especialmente si no vendes nada, como suele ser el caso (aunque, incluso si vendes, el hecho de que las visitas que tengas sean “de calidad” puede ser muy importante para tus conversiones)

Algo de promoción con cabeza no está de más, y es necesario. Pero creo que estamos sacando todo de madre y nos estamos poniendo el énfasis en el lado equivocado de las cosas.

GitHub for reviewing code

Posted on by

A couple of weeks ago we started (in my current job) to use GitHub internally for our projects. We were already using git, so it sort of make sense to use GitHub, as it is very widespread and used in the community. I had used GitHub before, but only as a remote repository and to get code, but without much interaction with the “GitHub extra features”. I must say, I was excited about using it, as I though that it will be a good step forward in making the code more visible and adding some cool features.

One of the main uses we have for GitHub is using it for code reviews. In DemonWare we peer-review all the code, which really improves the quality of the code. Of course, peer-review is different from reviewing the code in an open software situation, as it is done more often and I suspect than the average number of reviewers is lower in most open source projects. We were using Rietveld, which is a good tool, but probably not stellar when you start using it. The main process was, write code, submit it to Rietveld, ask for reviewers, check and discuss comments, update the code and repeat the process; and wait for approval for the reviewers to submit the code to the remote repo.

What can I say? I am quite disappointed with the result. It seems that the tools for code review in GitHub are not great, to put it lightly. Not great at all.

I guess that my disappointment is big because I though that, as GitHub is so used in the open source community, the review tools should be very good, as open source is all about checking and reviewing code that anyone can send. But the fact is that the review tool itself is pretty limited.

Continue reading →