¿Qué es la programación orientada a eventos?

La herramienta principal que nos ofrece WordPress para construir nuestras propias extensiones, ya se trate de plugins o themes, es un conjunto de funciones al que comúnmente se llama Plugin API.

Esta API está basada en el ya mencionado paradigma de Programación Orientada a Eventos, o Programación Basada en Eventos (en inglés, Event-oriented programming o Event-driven programming). Es combinable con otros paradigmas populares, como el estructurado, el orientado a objetos y el funcional, y tiene unos conceptos fundamentales muy sencillos.

Este paradigma es extremadamente útil cuando necesitamos que un proceso se ejecute en algún punto determinado, pero tenemos un acceso limitado al código que se encuentra en ese punto. Al trabajar con WordPress es casi inevitable usar el paradigma, porque no podemos modificar libremente el código que descargamos sin perder lo que hayamos hecho cuando necesitemos actualizar la versión. Si ya trabajaron con jQuery, probablemente hayan visto el paradigma de eventos al usar los métodos trigger() y bind().

El paradigma de eventos dicta que, en ciertos lugares puntuales de nuestro programa, van a ocurrir determinados eventos o “sucesos”. Estos eventos, por sí mismos, no hacen nada. Podríamos decir que son simples contenedores, porque solamente van a empezar a tener algún efecto sobre nuestra aplicación cuando les asignemos procesos, es decir cuando indiquemos que al ocurrir un determinado evento tiene que ejecutarse un proceso determinado.

Normalmente, vamos a tener en alguna parte de nuestro código la ejecución de un evento con un nombre determinado. Supongamos que tenemos un evento llamado mesa_servida.

<?php
evento( 'mesa_servida' );

Por otra parte, vamos a necesitar que, al ocurrir ese evento, también se ejecute un proceso. Vamos a suponer que, al ocurrir el evento mesa_servida, queremos que se procese la función sentarse_a_comer(). Para eso, necesitamos que la función haya sido declarada antes de que ocurra el evento.

<?php
function sentarse_a_comer() {
    echo 'a comer!';
}

evento( 'mesa_servida' );

Sin embargo, ese código por sí mismo todavía no hace nada. Para que la función se procese en el momento en el que se ejecuta el evento, necesitamos asignar la función al evento.

<?php
function sentarse_a_comer() {
    echo 'a comer!';
}

asignar_proceso( 'mesa_servida', 'sentarse_a_comer' );

evento( 'mesa_servida' ); // Se imprime "a comer!"

De esta manera, al usar asignar_proceso() con el nombre del evento como primer parámetro y el nombre de la función como segundo parámetro (lo cual se llama callback), indicamos que, al ocurrir el evento mesa_servida, va a procesarse el código declarado dentro de la función sentarse_a_comer. La función asignada a un evento es lo que dentro de este paradigma se suele llamar hook.

El importante notar que, al menos en PHP, no es necesario que la función exista antes de asignarla a un evento, pero sí tiene que haber sido declarada antes de que el evento ocurra. La misma asignación también tiene que hacerse antes de que ocurra el evento. De esta manera, el siguiente código es equivalente al anterior:

<?php
asignar_proceso( 'mesa_servida', 'sentarse_a_comer' );

function sentarse_a_comer() {
     echo 'a comer!'; 
}

evento( 'mesa_servida' );

Ahora bien, conociendo los conceptos fundamentales de la programación orientada a eventos, podemos ver de qué manera WordPress nos permite aplicarlos para construir nuestras extensiones. Para esto, WordPress nos ofrece dos diferentes tipos de eventos: acciones y filtros.

Acciones

Uno de los dos tipos de eventos ofrecidos por WordPress se llama Action, o acción. El propósito de las acciones es permitir la ejecución de procesos propios durante la carga de una página. Algunos ejemplos de estos procesos pueden consistir en modificar información de la base de datos, enviar un mail, registrar nuevos tipos de contenido, imprimir cierta información en pantalla, etc.

La interacción básica entre eventos y procesos es muy similar a los ejemplos que acabamos de ver. Las acciones se ejecutan por medio de la función do_action(), mientras los hooks se registran usando add_action().

<?php
add_action( 'mesa_servida', 'sentarse_a_comer' );

function sentarse_a_comer() {
    echo 'a comer!';
}

do_action( 'mesa_servida' );

Sin embargo, este uso básico a veces puede resultar un poco limitado. Por ejemplo, es posible que queramos añadir un segundo hook a mesa_servida, y necesitemos especificar cuál de ellos va a ejecutarse primero. Supongamos que introducimos la función comer(), y queremos que se ejecute inmediatamente después de sentarse_a_comer().

<?php
add_action( 'mesa_servida', 'comer' );

function comer() {
    echo 'comiendo ...';
}

add_action( 'mesa_servida', 'sentarse_a_comer' );

function sentarse_a_comer() {
    echo 'a comer!';
}

do_action( 'mesa_servida' );

Con este código, la función comer() siempre se va a ejecutar antes de sentarse_a_comer(). Si no tenemos la posibilidad de cambiar la ubicación de la asignación de add_action( 'mesa_servida', 'comer' ), necesitamos encontrar una manera de hacer que comer() se ejecute después de sentarse_a_comer(). Para este tipo de necesidades, la función add_action() admite un tercer parámetro llamado $priority, en el cual se especifica un valor numérico. Los hooks con valores menores van a ser ejecutados con anterioridad a los hooks con valores más altos, y el valor por defecto es 10. Teniendo esto en cuenta, podemos modificar nuestro código de esta manera.

<?php
add_action( 'mesa_servida', 'comer', 20 );

function comer() {
    echo 'comiendo ...';
}

add_action( 'mesa_servida', 'sentarse_a_comer', 10 );

function sentarse_a_comer() {
    echo 'a comer!';
}

do_action( 'mesa_servida' );
// Se imprime "a comer!"
// Se imprime "comiendo ..."

Puede pasar, también, que dentro de las funciones que usamos como hooks necesitemos algún tipo de información contextual con respecto al momento en el que se ejecuta la acción. Supongamos que dentro de sentarse_a_comer() necesitamos evaluar cuántos comensales vamos a tener.

<?php
add_action( 'mesa_servida', 'sentarse_a_comer', 10 );

function sentarse_a_comer( $comensales ) {
    if ( $comensales < 5 ) {
        echo 'a comer!';
    } else {
        echo 'acá hay demasiada gente, Roberto!';
    }
}

$comensales = 10;

do_action( 'mesa_servida' ); // Se imprime "a comer!"

De alguna manera necesitamos hacer que ese número de comensales declarado en el mismo contexto de ejecución de do_action( 'mesa_servida' ) llegue a la función sentarse_a_comer(). Para esto podemos adjuntar a do_action() todas las variables que queramos, y en add_action() especificar, en un cuarto parámetro llamado $accepted_args, el número de parámetros que va a recibir nuestro hook.

<?php

add_action( 'mesa_servida', 'sentarse_a_comer', 10, 1 );

function sentarse_a_comer( $comensales ) {
    if ( $comensales < 5 ) {
        echo 'a comer!';
    } else {
        echo 'acá hay demasiada gente, Roberto!';
    }
}

$comensales = 10;

do_action( 'mesa_servida', $comensales ); // Se imprime "acá hay demasiada gente, Roberto!"

El valor por defecto de $accepted_args es 1, por lo cual, si vamos a tener un solo parámetro, podemos incluso no especificar este valor.

<?php
add_action( 'mesa_servida', 'sentarse_a_comer', 10 );

function sentarse_a_comer( $comensales ) {
    if ( $comensales < 5 ) {
        echo 'a comer!';
    } else {
        echo 'acá hay demasiada gente, Roberto!';
    }
}

$comensales = 10;

do_action( 'mesa_servida', $comensales ); // Se imprime "acá hay demasiada gente, Roberto!"

Sin embargo, podemos pasarle a do_action() tantos parámetros como necesitemos en nuestra función, pero siempre especificando la cantidad en add_action(), en caso de que sea más de uno.

<?php
add_action( 'mesa_servida', 'sentarse_a_comer', 10, 2 );

function sentarse_a_comer( $comensales, $comida ) {
    if ( $comensales < 5 ) {
        echo 'A comer!';
    } else {
        echo 'Acá hay demasiada gente, Roberto! Tenemos solamente ' . $comida;
    }
}

$comensales = 10;
$comida     = 'Fideos con pesto';

do_action( 'mesa_servida', $comensales, $comida ); // Se imprime "acá hay demasiada gente, Roberto! Tenemos solamente fideos con pesto"

Sabiendo cómo opera este tipo de evento, también podemos agregar hooks a las acciones nativas de WordPress. Por ejemplo, podemos mandarle un mail al administrador del sitio cada vez que se publique un nuevo post. Para esto, definimos la función que envía el mail, y se la asignamos como hook a la acción publish_post.

<?php
add_action( 'publish_posts', 'avisar_amigos' );

function avisar_amigos() {
    $amigos = 'juan@example.org,pedro@example.org';
    mail( $amigos, 'Actualización de blog', 'Acabo de actualizar mi blog: http://blog.example.com' );
}

Una vez que activemos este nuevo plugin y publiquemos un nuevo post, vamos a poder ver que llega un nuevo mail a la casilla de correo del administrador.

Noten que no estamos llamando directamente a do_action( 'publish_posts' );. Esto es porque ese llamado se va a estar haciendo en algún lugar del código de base de WordPress, que llamamos Core. WordPress cuenta con una lista bastante larga de acciones propias a las que podemos asignar nuestros propios hooks, que nos pueden servir a manera de guía.

Filtros

El otro tipo de eventos que nos ofrece WordPress son los Filters, o filtros. Este tipo de eventos ya no pone tanto el foco en la ejecución de procesos, como pasa con las acciones, sino en la manipulación de datos internos de la aplicación. Por ejemplo, un filtro puede ser utilizado para cambiar el valor de una variable, o modificar el valor de retorno de una función. Usos típicos de los filtros pueden ser activar o desactivar ciertas características de la aplicación, modificar alguna parte del HTML que se va a imprimir, cambiar valores de configuración o alterar consultas a la base de datos.

Una característica importante de los filtros es que siempre tienen un valor de retorno, a diferencia de las acciones. Debido a esto, los filtros siempre están asignados a una variable, a una evaluación o a un valor de retorno de una función o método.

Teniendo en cuenta esta diferencia, su uso es muy similar al de las acciones. En algún punto de nuestro código vamos a tener un llamado a la función apply_filters(), que es equivalente a do_action(). Los parámetros que va a recibir esta función son el nombre del evento y el valor que va a tener por defecto.

<?php
$comensales = apply_filters( 'cantidad_de_comensales', 10 );

Ahora bien, antes de que ese código se ejecute, necesitamos definir cuáles van a ser los filtros que se asignen al evento. Esto podemos hacerlo a través de la función add_filter().

<?php
add_filter( 'cantidad_de_comensales', 'nueva_cantidad_de_comensales' );
function nueva_cantidad_de_comensales( $comensales ) {
    if ( viene_ramon() ) {
        $comensales++;
    }
    return $comensales;
}
$comensales = apply_filters( 'cantidad_de_comensales', 10 );

De esta manera, al momento de definirse la variable $comensales, el valor por defecto (10) se le va a pasar a la función nueva_cantidad_de_comensales(), y va a sumar 1 en caso de que Ramón venga (dando por resultado 11). Noten que antes de finalizar la función que opera como filtro siempre necesitamos devolver un valor; de lo contrario el valor que estemos filtrando va a terminar siendo null.

Los filtros, al igual que las acciones, pueden recibir prioridad de ejecución ($priority) y número de argumentos ($accepted_args) como tercer y cuarto parámetro, respectivamente.

<?php
add_filter( 'cantidad_de_comensales', 'descartar_vegetarianos', 20, 2 );

function nueva_cantidad_de_comensales( $comensales, $comida ) {
    if ( 'asado' === $comida && viene_jose() ) {
        $comensales --;
    }

    return $comensales;
}

add_filter( 'cantidad_de_comensales', 'nueva_cantidad_de_comensales', 10, 1 );
function nueva_cantidad_de_comensales( $comensales ) {
    if ( viene_ramon() ) {
        $comensales ++;
    }
    return $comensales;
}

$comensales = apply_filters( 'cantidad_de_comensales', 10, $comida );

De esta forma, el primer filtro a ejecutarse va a ser nueva_cantidad_de_comensales(), por más que se haya declarado en segundo lugar. No necesitamos especificar la cantidad de argumentos para ese filtro, porque el valor por defecto es 1, y solamente necesitamos la primera variable, $comensales. En segundo lugar se va a ejecutar la función descartar_vegetarianos(), que va a restar un comensal en caso de que la comida sea asado y venga José. Al asignar este filtro sí especificamos que vamos a recibir dos parámetros, ya que necesitamos las variables $comensales y $comida, que se están pasando al filtro por medio de apply_filters().

Al igual que pasa con las acciones, también tenemos muchos filtros que vienen con WordPress por defecto. Uno de ellos es the_content, que se aplica al contenido de cada post o página antes de ser impreso. Supongamos que queremos modificar levemente este contenido. Para eso podemos hacer algo así:

<?php
add_filter( 'the_content', 'modify_post_content' );

function modify_post_content( $content ) {
    if ( is_single() ) {
        $content = '<p>Esto es un post.</p>' . $content;
    }

    return $content;
}

Una vez que guardemos este código en nuestro plugin y refresquemos cualquier página correspondiente a un post, vamos a ver el texto que agregamos en nuestra función inmediatamente arriba del resto del contenido.

Remover eventos del registro

Algo que podemos llegar a necesitar mientras desarrollamos nuestras propias extensiones es que ciertas acciones o filtros se dejen de ejecutar. Por ejemplo, podemos querer desactivar alguna funcionalidad nativa de WordPress, o de un plugin de terceros, o que alguna de nuestras acciones o filtros solamente se ejecuten en determinados contextos. Para lograr eso, WordPress nos ofrece cuatro funciones:

• remove_action()
• remove_filter()
• remove_all_actions()
• remove_all_filters()

Cuando asignamos un filtro o una acción a un evento, WordPress lo guarda en una lista, más específicamente en la variable global $wp_filters, donde también queda el detalle de sus prioridades y la cantidad de argumentos que acepta. Lo que nos permiten estas funciones es remover de esa lista los procesos que necesitemos.

Por ejemplo, supongamos que tenemos dos eventos, una acción y un filtro, y a cada uno de ellos queremos asignarle una función.

<?php
add_action( 'my_action', 'my_action_callback', 10, 1 );

function my_action_callback() {
    echo 'Hello world!';
}

add_filter( 'my_filter', 'my_filter_callback', 10, 1 );

function my_filter_callback( $value ) {
    return 'some other value';
}

do_action( 'my_action' );

$my_value = apply_filters( 'my_filter', 'some value' );

Sin embargo, en algún punto en el futuro vamos a necesitar que esas funciones que asignamos dejen de ejecutarse, pero por las características de nuestra extensión no podemos remover ni las asignaciones ni las declaraciones de funciones. No podemos simplemente remover código. En ese punto es donde necesitamos usar estas nuevas funciones de las que venimos hablando.

<?php
add_action( 'my_action', 'my_action_callback', 20, 1 );

function my_action_callback() {
    echo 'Hello world!';
}

add_filter( 'my_filter', 'my_filter_callback', 20, 1 );

function my_filter_callback( $value ) {
    return 'some other value';
}

remove_action( 'my_action', 'my_action_callback', 20 );
remove_filter( 'my_filter', 'my_filter_callback', 20 );

do_action( 'my_action' );

$my_value = apply_filters( 'my_filter', 'some value' );

De esta manera logramos que las funciones que asignamos previamente con add_action() y add_filter() dejen de ejecutarse.

Para usar correctamente remove_action() y remove_filter() necesitamos tener en cuenta dos cosas: en primer lugar, tienen que ser llamadas después de que los callbacks hayan sido asignados, pero antes de que se ejecuten las acciones. En segundo lugar, ambas funciones reciben un tercer parámetro, que es equivalente a la prioridad con la que se asignaron previamente los callbacks que ahora estamos removiendo del registro. Este parámetro no es obligatorio, y su valor por defecto es 10. Si no lo especificamos, tenemos que asegurarnos de que la prioridad del callback también sea 10, o que tampoco esté especificada.

Por último, tenemos las funciones remove_all_actions() y remove_all_filters(). Estas nos permiten remover todos los callbacks que hayan sido asignados a una acción o filtro determinados, sin necesidad de especificar más que el nombre del evento. Por ejemplo, podemos suponer que tenemos dos callbacks asignados a una acción y otros dos callbacks asignados a un filtro.

<?php
add_action( 'my_action', 'my_action_callback', 10 );
add_action( 'my_action', 'my_other_callback', 20 );

function my_action_callback() {
    echo 'Hello world!';
}

function my_other_action_callback() {
    echo 'Hello again!';
}

add_filter( 'my_filter', 'my_filter_callback', 10, 1 );
add_filter( 'my_filter', 'my_other_filter_callback', 20, 1 );

function my_filter_callback( $value ) {
    return 'some other value';
}

function my_other_filter_callback( $value ) {
    return 'some other different value';
}

do_action( 'my_action' );

$my_value = apply_filters( 'my_filter', 'some value' );

Podemos remover muy fácilmente todos los callbacks para cada evento haciendo algo así:

<?php
add_action( 'my_action', 'my_action_callback', 10 );
add_action( 'my_action', 'my_other_callback', 20 );

function my_action_callback() {
    echo 'Hello world!';
}

function my_other_action_callback() {
    echo 'Hello again!';
}

add_filter( 'my_filter', 'my_filter_callback', 10, 1 );
add_filter( 'my_filter', 'my_other_filter_callback', 20, 1 );

function my_filter_callback( $value ) {
    return 'some other value';
}

function my_other_filter_callback( $value ) {
    return 'some other different value';
}

remove_all_actions( 'my_action' );
remove_all_filters( 'my_filter' );

do_action( 'my_action' );

$my_value = apply_filters( 'my_filter', 'some value' );

Tenemos que tener en cuenta que ambas son funciones para usar con mucho cuidado, ya que no es muy común querer remover todos los callbacks para un evento. Sin embargo, es bueno saber que contamos con ellas, y suelen ser muy útiles mientras estamos desarrollando nuestras extensiones, particularmente con fines de testing.

Conclusiones

Un buen manejo y comprensión de la Plugin API permiten agregarle a WordPress cualquier tipo de funcionalidad que pretendamos. Pero más allá del trabajo que podemos hacer con WordPress, dominar el paradigma de programación orientada a eventos puede abrirnos muchas puertas en el mundo del desarrollo de software en general, y en particular en el desarrollo web, donde se demuestra cada vez más útil, siendo adoptado por muchos otros proyectos open source, como jQuery, Drupal o Symfony.

The post Entendiendo la Programación Orientada a Eventos appeared first on Andrés Villarreal.

I did some digging, and it became apparent that PHP couldn’t obtain SSL certificates while using both Git and cURL. Finally, after some googling around, this article did the trick.

The post PHP on macOS Sierra can’t access SSL data appeared first on Andrés Villarreal.

Using Inheritance with WordPress

Carl Alexander always write awesome stuff. In this article he talks about some fundamental concepts of OOP, and shares tips on how we could apply them while developing plugins and themes.

The Case for WordPress Certification

A pretty detailed blog post advocating for the creation of a standard and widely recognized certification for WordPress developers as a way to formally validate their knowledge. It points some of the approaches that have being already taken on the matter, as well as how other open source projects deal with it.

Interview Humiliation

Basically, how to suck and not suck during the process of interviewing candidates for an open position at your company. It’s focused on tech-related positions, but I think it applies to any other profile too.

The Evolution of a Software Engineer

An oldie but still a goodie. I think the title itself is a great description. Some of the comments are great too.

10 Things Not To Do In PHP 7

A great list of a few bad practices that are more frequent than they should be. I’d like to note that all of them can be avoided even when working with PHP 5, but as the language becomes more and more mature and professional we need to work harder to eradicate them.

The Tech Talent Shortage Is A Lie

The premise of the article is that there are a lot of great people working in tech out there, but they probably won’t want to work for you if you don’t care about building a tech-friendly culture inside your company. I don’t agree with all the article, but I think it has a lot of interesting points.

Find a widget’s current sidebar context

This is a personal favorite of mine, and I love this kind of solutions. It’s a great way to obtain the context where a widget is being processed, and alter the widget’s behavior based on that context.

The Single Biggest Mistake Programmers Make Every Day

Damn good article about the practice of some principles of simplicity, such as KISS, DOT, and other non-acronym ones. It’s a little more specific about the programming language that I would like (though I’m not a JavaScript guy, so it’s OK), but still great.

The post Useful Articles for Developers appeared first on Andrés Villarreal.

Esto de por sí no sería algo alarmante, salvo por el hecho de que la lectura continuada de artículos de autoayuda es un obvio indicativo de que no nos estamos autoayudando un carajo. O bien hay algo que no está funcionando bien de lo que proponen nuestras lecturas, o no estamos funcionando bien nosotros mismos. A lo mejor preferimos gastar nuestro tiempo leyendo artículos sobre como mejorarnos a nosotros mismo por sobre tomar las riendas de nuestras vidas y mejorarlas de verdad. O quizás al intentar poner en práctica lo sugerido, nos damos cuenta de que no es para nosotros; no por una racionalización ad hoc que nos excuse de hacer el esfuerzo, sino porque los resultados son pobres y no nos generan el placer prometido.

Tal vez no sea autoayuda lo que necesitamos. Después de todo, gran parte del género se basa en aconsejar prácticas que le sirvieron a alguien, pero que no tienen por qué servirle a los demás. Sobre todo porque no muy lejos va a aparecer alguien recomendando lo contrario para obtener lo mismo, o algo completamente distinto. No habría tantos gurúes de la vida si alguno tuviera la posta definitiva. Así como no habría tantos diseñadores si lo considerado estéticamente aceptable consistiera en un conjunto reducido de características; como no habría tantos programadores si se pudiera resolver todo con un único lenguaje; y como no tendríamos tanta diversidad musical si fuera posible que todos nos conformáramos con un mismo género.

A lo mejor lo que nos vendría bien es dejarnos de joder y tomar las riendas de nuestras vidas de una vez por todas. Dejar de buscar las soluciones en otros, sobre todo cuando en el fondo sabemos bien lo que necesitamos y cómo conseguirlo. Simplemente estamos demasiado asustados como para atrevernos a hacer algo por nuestra propia cuenta, y nos ocultamos ese hecho haciéndonos los giles y fingiendo cierta comodidad con el hecho de que otros hayan pasado por algo parecido y lo hayan superado. Esperamos que otros nos expliquen lo que sentimos, lo que tememos, por qué estamos tristes, por qué no podemos terminar lo que empezamos ni alcanzar lo que queremos. Como si no quisiéramos aceptar que está bien buscar la felicidad, y que muchas veces nos merecemos mucho más de lo que nos permitimos.

No existen los elíxires de la felicidad, ni instantánea ni eterna. Hay que lograrla con esfuerzo, sabiendo que es efímera, y que en cuanto se vaya hay que salir a remar y a buscarla hasta abajo de las piedras para encontrarla de nuevo, a veces a la vuelta de la esquina. Lo que funcionó para otros no necesariamente va a funcionar para nosotros. Y tampoco es que nos hagamos cada día más jóvenes y tengamos todo el tiempo del mundo.

The post A veces hay que parar con la autoayuda appeared first on Andrés Villarreal.

You created a Child Theme, inheriting a number of page templates from the parent theme. The thing is, maybe you don’t want some of those page templates. You don’t want your users to select it, or you’re not gonna support it, or it’s not fully compatible with the modifications you’ve made, or you just simply don’t like it. Whatever the reason is, you’d like to remove it from the dropdown in the page editor when creating a new page.

Before WordPress 3.9, there were some bizarre and pretty much complicated things to accomplish this. However, wlth the introduction of the theme_page_templates filter, it has become a really easy task to do.

So let’s say you want to remove a page template called “Full Width”, and the corresponding file is named template-full-width.php. In order to do this, you just need to add some code like the following in the functions.php file of your Child Theme:

<?php
add_filter( 'theme_page_templates', 'child_theme_remove_page_template' );
/**
* Remove page templates inherited from the parent theme.
*
* @param array $page_templates List of currently active page templates.
*
* @return array Modified list of page templates.
*/
function child_theme_remove_page_template( $page_templates ) {
    // Remove the template we don’t need.
    unset( $page_templates['template-full-width.php'] );

    return $page_templates;
}

So that’s it. Hope it helps

Further reading

• theme_page_templates (in French)
• WordPress Core changeset 27297

The post Quick Tip: How to Disable Page Templates in Child Themes appeared first on Andrés Villarreal.

Mi mayor motivación para verla es el hecho de que el espacio, y especialmente Marte, tienen mucho que ver un proyecto en el que estoy trabajando (del cual ya voy a hablar más adelante), en donde se toca mucho el tema de la lejanía como forma de escape, pero también como camino a la alienación. Sin embargo, no me encontré con tantos dilemas psicológicos o existenciales como con cosas que tienen que ver mi trabajo o mi vida cotidiana, y con la forma en que las encaro o debería encararlas. Y también creo que más allá de mí, esas cosas son aplicables a casi cualquier persona a la que le importa algo de lo que hace.

Ya desde el momento en el que se despierta en un Marte desierto y sin ningún otro ser humano alrededor, Mark Watney se presenta como una persona proactiva, con una actitud avasallante al momento de buscar soluciones a un problema. Durante la película se lo ve hacerse una intervención quirúrgica menor, hacer crecer vegetación en un planeta poco apto, fabricar agua, crear un sistema de recarga para un vehículo destinado a viajar durante pocas horas, idear un sistema de comunicación efectivo con un lenguaje limitado, etc. Algunas son cosas que requieren conocimiento teórico, y otras requieren tiempo, pero todas requieren actitud.

Sin una buena predisposición a resolver problemas, nos condenamos a la resignación. Las soluciones de Watney no siempre son excelentes; algunas de las cosas que hace no funcionan de la mejor manera posible, otras se rompen o son destruidas por una falla humana o un factor ambiental. También se frustra, insulta, discute, y tiene miedo. Pero siempre vuelve, nunca deja de intentar, acepta las recomendaciones de quienes conocen ciertas cosas mejor que él, incluso aunque a veces no esté de acuerdo. Y eso es lo que termina dando resultados, es lo que lo hace volver a la Tierra. La constancia, la entereza de continuar de acuerdo al plan todos los días, y la humildad para cambiar de planes cuando el anterior falló.

Un programador puede conocer muchísimo acerca de las herramientas que maneja: lenguajes, programas, patrones, librerías, etc. Pero ni el conocimiento teórico ni el práctico son suficientes si no se está dispuesto a desafiar lo que conocemos, a buscarle otra vuelta de tuerca a esas situaciones complicadas en las que estamos, a cuestionar lo que estamos haciendo en lugar de seguir construyendo soluciones ad hoc para un planteo defectuoso. Sin predisposición estamos condenados al estancamiento. Pero por sobre todo, necesitamos saber reconocer cuándo hace falta salir de nuestros propios cuestionamientos para empezar a poner en práctica esas ideas superadoras, por más que aún no sean perfectas. De hecho, probablemente nunca lo sean, pero sí pueden ser mejoradas y vueltas a cuestionar progresivamente, conforme avanza nuestro trabajo. Si tenemos ese tipo de actitud y persistimos en ella de manera constante, por poco intuitivo que suene, podemos quedarnos tranquilos sabiendo que nunca vamos a alcanzar esa perfección que buscamos, y que es eso justamente lo que nos permite mejorarnos día a día.

The post Programación, predisposición, constancia appeared first on Andrés Villarreal.

Todos los desarrolladores alguna vez estuvieron muy entusiasmados por empezar un nuevo proyecto determinado. Les parecía muy emocionante, y les representaba un desafío que estaban ansiosos por encarar. Pero a muchos les pasó algo que también es bastante común: a medida que el proyecto avanzaba (o no avanzaba) se encontraron con que se sentían cada vez más desmotivados, con que perdían las ganas, y con que ese proyecto que tanto les interesaba al principio se terminó convirtiendo en una carga. El trabajo se extendió, imprevisiblemente, por meses, incluso por años. Hasta que un día decidieron abandonarlo, o lo terminaron con una calidad que no los conformó. O sí los conformó, pero ya estaban tan alejados emocionalmente que perdieron esa satisfacción que da un trabajo bien hecho.

Este post va a tener como punto central una pregunta: ¿hasta qué punto nosotros mismos, como desarrolladores, somos responsables de que nos pase esto?

Un poco de historia personal

En el 2008 empecé una carrera universitaria, en simultáneo con mi primer trabajo importante en programación. Hace alrededor de un año abandoné esa carrera, mientras mayo de este año me encontró co-organizando y dando una charla en el evento más grande que haya tenido nuestra comunidad local en años. Yo veo estos dos hechos como diferentes caras de la misma moneda.

Podría pasar mucho tiempo hablando de mis idas y vueltas con la carrera, de mis postergaciones, mis excusas, mis sesiones de terapia sobre el tema, pero el punto importante es que, en algún determinado momento, mucho antes de dejarla, ya me había dejado de interesar, de apasionar. Y gran parte de ese interés y esa pasión se habían ido hacia mi trabajo.

Por alguna razón, con el desarrollo web me fue bien. Para 2010 ya trabajaba en un lugar mejor que en donde había empezado, dirigía mi sector, y hasta me llamaban para dar clases y capacitaciones. Pero no podía evitar sentirme un poco un outsider, un fraude. Mi trabajo me llevaba a rodearme de gente con estudios formales en desarrollo, e incluso a estar a cargo de algunas de esas personas. Yo nunca había estudiado nada relacionado con desarrollo, no había hecho un solo curso. Todo lo que sabía lo había aprendido a medida que lo necesitaba usar para algún proyecto, o buscándolo por curiosidad. Es una forma totalmente válida de aprender cosas, pero aún así me sentía en desventaja.

Por esto mismo, cada tanto sentía que necesitaba poner el freno y pararme a ordenar un poco lo que ya sabía, a aprender sobre esos puntos que se me escapaban en medio del apuro por terminar algo, o a tratar de entender relaciones entre varios conocimientos dispersos. Me pasaba noches enteras en vela tratando de aprender algunas cosas de las que había escuchado hablar y no entendía, o tratando de encontrar la mejor manera de aplicar lo que ya sabía. Cada vez que hacía esto, sentía que podía volver a trabajar con un conjunto de habilidades reforzadas. Si pasaba mucho tiempo sin hacerlo, sentía que me estancaba, que mis proyectos se demoraban, que bajaba la calidad de mi trabajo, y todo esto me hacía sentir más abrumado, muy poco preparado, un completo fiasco.

Todos nos creamos una imagen de nosotros mismos frente a todo lo demás. A partir de esta sensación de inseguridad, de este deseo de ser competente, y ante la falta de conocimiento y de preparación, me creé para mí mismo la imagen de alguien comprometido y reflexivo, y me puse a trabajar a partir de ahí para que el resto llegara a su debido tiempo. No sé si esto es algo admirable, ni siquiera sé si es realmente así como se me ve, pero es la manera que elegí para encarar mi trabajo.

Es un error creer que uno es el único al que le pasa algo. Con el tiempo me encontré con muchos colegas que se sentían parecido, incluso teniendo esa preparación que a mí me faltaba. Entonces, si no se trata tanto de una cuestión de conocimientos formales, algún otro tipo de conocimiento nos debe estar faltando para no sentirnos disconformes con lo que somos y con lo que hacemos. Hay algo que se nos escapa. Hay algo que nos separa del éxito al que aspiramos, de nuestros objetivos. Yo creo que es algo que no se aprende en ningún lado, sino que más bien se incorpora a través de la práctica.

Mucho de lo que aprendemos en algún punto nos puede servir de algo, lo podemos reutilizar. Lo que estaba estudiando, y que es algo que todavía me apasiona, es filosofía. Creo que la filosofía tiene una relación muy cercana con el mundo del desarrollo, y con la programación en particular. Y acá vamos a tratar de retomar una noción filosófica muy antigua para intentar aplicarla a nuestro trabajo diario.

El método socrático

Sócrates murió en el año 399 a.C., condenado por “pervertir” a los jóvenes de Atenas con sus ideas innovadoras. Lo que sabemos de él nos llegó a través de testimonios de algunos de sus contemporáneos, como su alumno Platón, quien lo usó como personaje principal en la mayoría de sus obras.

A través de estas obras, Platón muestra cómo Sócrates habla con diferentes “autoridades” respetadas acerca de algún tema puntual: políticos, jueces, generales, artistas, etc. Sócrates les hace preguntas para profundizar en el tema del que ellos saben, hasta llegar al punto en el que la supuesta autoridad ya no sabe qué responder. A partir de ahí, se ponen a buscar juntos la respuesta. Este método de investigación, el método socrático, sienta las bases primordiales de la investigación social y científica tal como la conocemos hoy en día. Pero lo que yo considero interesante del método es que también es aplicable a nuestro mundo interior.

Método Socrático

El título del post es engañoso a propósito. No se trata de psicología en el sentido más formal que tiene hoy, sino en el sentido originario de las palabras que componen el término psicología:

• ψυχή (psyché): Originalmente, soplo, hálito o aliento que exhala el ser humano al morir. Más tarde, alma, espíritu, mente.
• λóγος (lógos): Palabra, discurso, razonamiento, argumento.

Esto tiene que ver con un principio fundamental del método socrático: si bien es posible acceder a ciertos conocimientos más o menos avanzados, para eso antes tengo que conocerme a mí mismo. ¿Por qué? Porque porque yo mismo, a la vez que deseo algo, soy también una herramienta para obtener eso que deseo.

Si lo que sigue parece sacado de un libro de autoayuda, es porque ese es un poco el objetivo. La palabra autoayuda se aplicó de manera genérica a tantos productos comerciales con tan poco contenido útil que perdimos gran parte de su significado. Gracias al marketing y una cierta élite intelectual, casi cualquier persona con dos dedos de frente desprecia el género de autoayuda, simplemente porque está catalogado así y no por lo que realmente dice. Creo que vale la pena rescatar este significado de autoayuda como algo que nos sirve para mejorarnos a nosotros mismos, sin que esto implique estar comprando humo.

Problemas

En base a mi experiencia en desarrollo, y comparándola con las experiencias de varios colegas del área, todos ellos programadores o gente que trabaja muy cerca de programadores, agrupé una serie de problemas que considero bastante importantes en cinco categorías: Inteligencia, Relaciones, Justificaciones, Resultados y Soluciones. No es una lista exhaustiva, e incluso tuve que dejar algunos ítems afuera en beneficio de la brevedad, pero creo que sirve para tener un buen pantallazo general de nuestras falencias y cómo tratarlas.

Inteligencia y soberbia: Yo C++ que vos

Hay un mito acerca de los programadores. Se dice que, para ser un programadores, tenemos que ser muy inteligentes, estar en pésima forma física, ser muy malos para las relaciones personales, y tener más de 30 años y seguir viviendo con nuestros padres.

Estas cosas no son malas de por sí, y algunos podemos coincidir con esa descripción (porque los estereotipos existen por algo), pero no nos representa como grupo ni como individuos. No habla de cómo es cada uno en su vida cotidiana. Cualquier programador diría que esta descripción es errónea. Pero seguramente pocos cuestionen la inteligencia que se nos adjudica. Esa parte del mito sí elegimos creerla. ¿Quién quiere admitir que no es tan inteligente?

En nuestro tiempo la inteligencia tiene un lugar que no merece. Se muestra a los exitosos como seres súper inteligentes, que nunca se equivocaron. El exitismo deja el proceso de lado, como si no importase. La inteligencia no es mas importante que la voluntad, que ser expeditivo, que ser constante.

Santiago Bragagnolo

La realidad es que los programadores no son necesariamente más inteligentes que la gente de otras áreas. Quizás tengamos una habilidad un poco mayor al promedio para resolver procesos lógicos, pero eso es esperable, porque estamos entrenados para eso. La resolución lógica no es lo único que hace a la inteligencia, ahí están en juego muchos otros factores. Diseñar, planear, vender, difundir, son cosas tan complejas como lo que hacemos nosotros, y la media de los programadores comete tantas estupideces y toma tantas pésimas decisiones en su desempeño diario como cualquier otro mortal.

Mantener esta actitud de creernos superiores es peligrosa. Nos cerramos a nuestros colegas, incluso a otros programadores. No es difícil entender por qué pasa esto: una de las maneras más sencillas de validarse a uno mismo es desmerecer lo que hace otro. Si alguien hace algo que consideramos de calidad inferior, o con una herramienta distinta, para nosotros es objeto de burla o de crítica. Porque es tan incapaz que no puede hacer las cosas bien (como nosotros) o porque su solución al problema es distinta de la nuestra. Creemos que lo que hacemos es mejor que lo que hacen los demás, porque necesitamos esa validación que nos demuestre que no somos un fraude, que estamos a la altura de lo que el mito pretende de nosotros. No le prestamos mucha atención al hecho de que los métodos y los errores de otros pueden ser oportunidades para aprender algo.

Como desarrollador es interesante poder aprender no solo de nuestros errores, sino también de los de los demás.

Tomás Cot

Esta es una de las partes más difíciles del proceso de autoconocimiento. Todos tendemos a querer que las cosas nunca cambien, a rechazar todo lo que rompe con nuestra concepción del mundo y nos saca de nuestra zona de comfort. Nuestras ideas, nuestras creencias, lo que pasa en nuestro mundo interior, al igual que lo que hacemos en el mundo exterior, son hábitos, son costumbres. Y los hábitos y costumbres son difíciles de cambiar. Por eso aceptar nuestros errores nos cuesta tanto como cambiar de marca de papel higiénico.

Lo interesante de los modelos mentales es que a partir del momento en que tenemos uno definido, el universo nos brinda suficiente evidencia de que esa es la forma en que funciona. Reconocemos y tenemos en cuenta la evidencia positiva, y creamos excusas cuando la evidencia no se corresponde con nuestro modelo.

Tina Su, How to make profound and lasting change

Confiar demasiado en lo que creemos saber nos vuelve descuidados. Evitamos seguir reglas que nos digan cómo hacer algo en base a nuestras preconcepciones de cómo hay que hacerlo. Creemos que estamos haciendo las cosas bien porque las estudiamos, sabemos un montón de datos y conocemos los lenguajes que usamos. Descartamos y subestimamos herramientas porque suponemos que sabemos resolver algo por nuestra cuenta, por más que nos lleve más trabajo. No salimos de lo que ya sabemos, de nuestra zona de comfort, y la falta de novedad nos vuelve poco creativos y limita nuestra capacidad de resolver problemas. Después nos extrañamos, como si fuera culpa de otro, de que perdimos el entusiasmo por proyectos en los que inicialmente habíamos puesto un montón de energía.

Este descuido nos hace poco solidarios. No nos preocupamos por qué tan comprensible y mantenible es nuestro código. No pensamos de qué manera otros pueden llegar a interactuar con lo que escribimos. No se nos cruza por la cabeza hacerlo accesible a principiantes. Pero nos creemos mejores que quienes no son capaces de entenderlo o integrarlo, cuando no estamos haciendo un trabajo necesariamente mejor que el suyo. Lo único que nos salva de considerarnos unos idiotas a nosotros mismos es que conocemos los pormenores de nuestro trabajo: sabemos por qué hicimos algo de la manera en que la hicimos; pero al no saber acerca del contexto en el que trabaja otro programador, optamos por la opción fácil y lo tildamos de idiota.

En lugar de ridiculizar al que no sabe, si sabemos tanto, deberíamos enseñarle a hacer las cosas de una manera más eficiente, más acorde a las prácticas recomendadas de la herramienta que usemos. Algo que hace a WordPress único en su tipo es que cuenta con una comunidad enorme de gente con esta actitud solidaria y proactiva. Gente que intenta ayudar al resto de la comunidad por medio de difusión de buenas prácticas, soporte en foros, colaboración en el Codex, y un ambiente de buena voluntad generalizado en el que, normalmente, trabajar es muy placentero. No voy a presentarlo como algo que es todo color de rosas, pero los factores menos agradables no impiden que la comunidad se siga desarrollando en una relativa armonía. Acá tenemos algo que es invaluable, y que generalmente no advertimos: la posibilidad de aprender, ayudar, enseñar, dar y recibir ayuda sin importar el nivel de experiencia ni el perfil que tengamos, y es un ambiente sumamente propicio para desarrollar nuestras habilidades.

Este hombre cree que sabe algo, mientras que no sabe nada. Pero yo, que igualmente no sé nada, tampoco creo saber algo.

Platón, Apología de Sócrates

Algunos de ustedes quizás conozcan a Sócrates como el que dijo “solo sé que no se nada”, pero esto es una mala interpretación de varios diálogos. Lo que si habría dicho es que no es posible saber nada con absoluta certeza, por más seguro que uno esté de lo que cree saber. Entonces, este proceso por el que necesitamos pasar no se trata tanto de admitir que somos unos ignorantes, o de creer que no sabemos ni aprendimos nada. Aprendemos, sabemos un montón de cosas, pero eso no significa que tengamos la verdad absoluta sobre nada, y que necesitamos un cierto cuestionamiento sobre lo que hacemos para aprender a identificar en qué estamos fallando y corregirnos.

Relaciones y distancia: El problema son los otros

Lo que hacemos nos encanta, y estamos horas con eso, y hablando de eso, y juntándonos con gente que hace también eso. Está genial, siempre y cuando cuidemos las relaciones con profesionales de otro tipo, y especialmente con usuarios finales, que son para quienes trabajamos, y muchas veces ni siquiera nos preocupamos por entenderlos.

Ricardo Aiello

A veces nos relacionamos de formas negativas con la gente que trabaja con nosotros. Esto se traduce en un cierto maltrato, a veces más explícito, a veces menos, hacia los que hacen otro tipo de trabajo. Otras veces nos alejamos de los demás y elegimos no relacionarnos con ellos, nos desconectamos. Con frecuencia nos creemos incomprendidos, sin siquiera cuestionarnos qué estamos haciendo para que el resto nos comprenda.

Con el tiempo desarrollamos una jerga técnica demasiado complicada de entender para quienes se dedican a otra cosa. Esto acorta nuestra comunicación con la gente con la que tenemos que trabajar, nos rehusamos a entenderlos, y nos damos el lujo de hacerlos sentir mal porque “no están a nuestra altura”. No vemos las cosas desde su perspectiva, y perdemos la capacidad de abstracción de la experiencia del usuario en favor de la implementación que nos resulta más cómoda a nosotros. Al igual que nos pasa con otros programadores, no sabemos cómo trabajan a diario nuestros colegas de otras áreas, cómo interactúan con sus aplicaciones, qué necesitan para hacer su trabajo más eficiente. Terminamos creando productos que son técnicamente funcionales al 100%, pero complicados de usar y difíciles de entender. Y si alguien encuentra complicado usar lo que desarrollamos, el problema es suyo, no nuestro. El problema son siempre los otros.

Se da un gran problema cuando eso que hay que programar pasa solamente por los programadores, con una influencia externa reducida. La influencia externa es uno de los pilares de la innovación, y si no está presente en un proyecto, tarde o temprano ese proyecto se estanca.

Por limitaciones o por encasillamiento, a veces se limita el diseño o la innovación en un proyecto. Por ende, el problema también deriva en programadores que no intentan investigar más allá, salir de su lugar cómodo y buscar nuevas maneras de hacer y resolver las cosas. Podría resumirse en la no creatividad, cuando en realidad el trabajo de un programador es tan creativo y creacional como el del diseñador.

Mailén Knoblovits

A nivel macro, esto también impacta en WordPress como herramienta. Es algo muy positivo que haya tantos programadores comprometidos en el desarrollo de la plataforma, pero la cantidad de influencia desde otras áreas se termina viendo opacada por tantos programadores, y no se está escuchando gran parte del feedback que nos llega de otras áreas. Esto hace que los programadores tengan demasiada influencia en el desarrollo de la plataforma, y que se favorezcan las herramientas orientadas a otros programadores en detrimento de la interfaz y la experiencia del usuario. No estoy diciendo que no haya habido mejoras notables en los últimos tiempos, pero podría haber habido muchas más. Y tampoco es malo que haya cada vez más herramientas para programar, pero no por eso se debería descuidar la experiencia.

Para Sócrates, la manera de afrontar este problema de estar tan ensimismado es el diálogo con otras personas. Que el otro funcione como un espejo de lo que somos y nos devuelva una imagen que quizás no es la que esperamos, pero que podamos tener la suficiente entereza para aceptar esa imagen, aunque no coincida con nuestras expectativas, y no dejarnos avasallar por esa realidad. Esto fue justamente lo que no pudieron soportar los que lo condenaron. No es sencillo, porque a veces nos perdemos en las palabras muy rápido, nos ensimismamos en las discusiones y las prolongamos más de lo debido, hasta que pierden el sentido. Necesitamos no llegar a ese punto; lo ideal sería llegar a un punto en común a partir del cual se pueda seguir trabajando, aunque todavía exista lugar para el cuestionamiento. Si algo no quería Sócrates, eso era que la historia de la filosofía se convirtiera en una sucesión de eternas discusiones que nunca llegaran a nada. Se suponía que la filosofía debía llegar a construir algo, y eso no ha pasado con la gran mayoría de los filósofos, quienes nunca salieron de atrás de su escritorio. De la filosofía han salido sistemas políticos, revoluciones, movimientos artísticos, muchas cosas. Pero eso lo generó una minoría que supo salir del lugar común de la discusión por la discusión misma. En el mundo del desarrollo no estamos en un lugar muy distinto. Por supuesto que se lograron muchas cosas, pero se podría haber logrado mucho más con el potencial que hay disponible.

Justificaciones y excusas: Era joven y necesitaba el dinero

Estamos llenos de excusas. En general las damos por haber estimado mal algún plazo, o por los malos resultados de un trabajo. Algunas ejemplos de estas excusas son: “tenía poco tiempo”, “lo hice solo por la plata”, “no me gustaba el proyecto”, “el cliente pagaba poco”, “había pocas directivas”, “había muchas directivas”, “los requisitos no estaban claros”, “lo diseñó otro”, “el programador anterior usó un patrón horrible”, “no me gustaba el framework”, “no me gustaba el lenguaje”, etc. Probablemente muchos de nosotros hayamos recurrido a más de una de esas excusas en diferentes oportunidades.

El problema no es tanto la excusa en sí misma. En nuestra vida cotidiana damos montones de excusas todo el tiempo para muchas cosas. No haber regado las plantas, no haber sacado a pasear al perro, olvidarse de comprar la leche. Si nos volvemos completamente autocríticos con nosotros mismos, toda nuestra realidad se desmorona. Necesitamos las excusas para no cuestionarnos innecesariamente todos nuestros errores. Nadie puede vivir bien si se cuestiona todo lo que hace. El problema empieza cuando damos excusas sistemáticamente sobre las mismas cosas. El tema es que la barrera entre la excusa y la justificación válida suele ser muy difusa. ¿Cómo reconocemos las excusas? ¿Cómo cambiamos las excusas por la realidad?

Pero respecto a nosotros, conforme a nuestro principio, […] es preciso morir aquí o sufrir cuantos males vengan antes que obrar injustamente.

Platón, Critón

El proceso de cambio es difícil, y es normal que no nos guste. Requiere reconocer nuestras falencias, nuestras miserias, hacernos cargo de que nuestros actos tienen consecuencias. Lidiar con nuestras propias derrotas personales. Sócrates fue condenado por ir en contra de las costumbres atenienses, y hay pocas cosas tan difíciles de cambiar como las costumbres. Él ya las había cambiado para sí mismo, pero una gran mayoría no estaba dispuesta a hacerlo. Tuvo la posibilidad de escapar, pero sabía que la condena era un posible resultado de sus actos, y decidió afrontarla porque era parte de un conjunto de reglas que él ya había aceptado de antemano. Llevar este idealismo a la programación sería un poco absurdo, pero sí quisiera que esto sirva como una invitación a intentar aprender a sobrellevar esas pequeñas derrotas con la frente en alto, y no con negación, culpa o vergüenza.

Necesitamos preguntarnos si las estimaciones que damos, o los proyectos que encaramos, no son más expresiones de deseo que algo que estemos seguros de poder cumplir en tiempo y forma. A lo mejor nos encantaría terminar algo para determinada fecha y con un cierto estándar de calidad, nos emocionamos con la idea de tenerlo hecho, y dejamos de considerar varias eventualidades que pueden llegar a surgir. O nos creemos tan buenos en lo nuestro que creemos que no va a haber problema en hacerlo, pero más adelante nos encontramos con que tenemos que inventarnos una excusa para no sentirnos unos fracasados.

Todos hicimos malas estimaciones en algún momento, ya sea por nuestra cuenta u obligados por alguien, y por más que mejoremos, no vamos a estar exentos de hacerlas en el futuro. Si en un momento dado no supimos cómo resolver algo, está todo bien: no llegamos a este punto sabiendo todo. El punto actual es el resultado de montones de errores, y vamos a seguir cometiendo muchísimos a medida que mejoremos. Una vez que tenemos esto asumido, la realidad termina siendo más simple de lo que parece al momento de buscar excusas. Ya no necesitamos buscar razones para perdonarnos a nosotros mismo aquello que no le perdonamos a los demás. De hecho, ya ni siquiera nos hace falta juzgar tan duramente a los demás. En lugar de sentirnos unos incomprendidos, una vez que nos comprendemos más a nosotros mismos también podemos educar mejor a quienes intentan imponernos plazos y requisitos inalcanzables, defender mejor nuestras razones.

Resultados y conformismo: A mí me anda

Muchas veces, cuando creamos soluciones para salir del paso y que solamente funcionan para nuestro caso particular, nos estamos excusando por no querer ir un poco más allá, aprender más, dar algo más de nosotros, pero no por el otro o para el otro, sino para nosotros mismos y por la calidad que va a tener nuestro trabajo en el futuro. Corremos el riesgo de convertirnos en máquinas de resolver problemas puntuales, totalmente carentes de especialización, e incapaces de manejar otras plataformas o lenguajes distintos de los que ya conocemos muy por encima.

En este caso, estamos en una situación paralela a esos interlocutores de Sócrates que, al ser interrogados con una profundidad cada vez mayor, llegan a un punto en el que no saben qué más responder, porque todo lo que creían saber parece insuficiente para responder a un problema complejo acerca de eso en lo que se supone que son expertos. Es elección nuestra profundizar en busca de respuestas, aunque eso requiera cuestionar todo lo que sabemos, o seguir inmersos en la duda.

El hecho de que WordPress sea sencillo de usar no implica que haya que atarlo con alambre.

Serafín Danessa

WordPress ofrece una vía de entrada al desarrollador tan sencilla que requiere muy poco conocimiento previo de programación para extenderlo. Esto es, al mismo tiempo, bueno y malo: no significa que solamente tengamos que ocuparnos de que las cosas que hacemos funcionen, que haya que ignorar las buenas prácticas o la coherencia interna. Si bien WordPress nos saca de encima el trabajo pesado de infraestructura, también nos deja hacerlo si lo necesitamos, y seguramente necesitemos hacerlo en algún punto en el que construyamos algo medianamente complejo. Necesitamos profundizar si queremos ofrecer trabajos de mejor calidad, más rápidos, más eficientes, más fáciles de mantener, y que incluso nos lleven menos tiempo de desarrollo. Tenemos muchos “implementadores” en el ecosistema, gente que sabe modificar y crear themes y plugins sencillos, que conoce las bases de la programación en PHP y JavaScript, y con muy buena preparación en HTML y CSS. Y ya son tantos que la competencia dentro de ese perfil es cada vez mayor, y cada vez se los busca menos. Cada vez se requiere un conocimiento no necesariamente mayor, pero sí más profundo, más especializado, más intensivo que abarcativo. Y la mayoría de los implementadores cuenta con los recursos, pero por alguna razón no profundizan en la plataforma, y por lo mismo no se especializan ni crecen. Sería muy bueno ver a varios implementadores con un deseo genuino de convertirse en programadores avanzados, no solamente orientados a WordPress, sino en un sentido general.

Soluciones e ideales: Lo irreal de lo definitivo

Los sectores de marketing de las empresas de informática vienen taladrando en las cabezas de todos la palabra “solución” desde hace tanto tiempo y con tanta intensidad que para muchos de nosotros ya suena a algo vacío y que se dice para tratar de convencer a alguien de comprar algo que no necesita. La solución se vende como definitiva, y cuando aparece una mejor, resulta que es todavía más definitiva que la otra.

En este contexto el término “solución” tiene una connotación un tanto inmoral, o cuando menos engañosa. Los programadores creemos estar más allá de ese discurso de marketing, porque trabajamos en paralelo a esa área, creemos conocer cómo opera, y creemos saber que la solución ideal no existe, que solo hay soluciones relativas. Sin embargo, muchas veces terminamos comprando este discurso, aunque no nos demos cuenta.

Es muy común, cuando dominamos una herramienta, querer usarla para todo. Abundan implementaciones de WordPress para crear patrones MVC, sistemas de deployment complejos, de backup, de versionado, e incluso paneles de control para servidores. Algunas tienen más aceptación y éxito que otras, pero hay una enorme porción de la comunidad que nunca se puso a pensar si algo así es realmente una buena idea. WordPress no fue pensado para resolver ciertos problemas porque justamente no existe forma óptima de resolverlos a través de WordPress, la solución tiene que darse en otro nivel. Decir que un método es mejor que otro simplemente porque lo usamos o nos gusta más es negarnos a analizar de manera práctica un problema concreto. No todo puede solucionarse usando los mismos procesos.

Hace un tiempo me prestaron un taladro, y después de colgar un par de repisas quería hacerle agujeros hasta a la heladera. La emoción por el juguete nuevo es comprensible, pero pensar que una única herramienta que resuelve un conjunto de problemas específicos también va a poder resolver cualquier otra cosa que yo quiera que resuelva, eso ya es absurdo. Mi herramienta favorita no me va a solucionar todos mis problemas solamente porque es mi favorita. Nada me impide usar el taladro para poner clavos, pero probablemente un martillo sea más eficiente.

Es difícil decir que una manera es la mejor forma de hacer algo en programación. El criterio tiene bastante importancia para poder hacer las cosas de la mejor manera posible, y llevarlas a la realidad al mismo tiempo.

Juan Francisco Aldasoro

Necesitamos reforzar mucho más esta idea de que no existe una solución definitiva entre nuestros colegas, jefes y clientes; dejar de lado la distinción entre mejor y peor, bueno y malo, y adoptar una perspectiva en la que co-existen conjuntos de soluciones más o menos adecuadas para problemas determinados, de entre las cuales necesitamos elegir las que se integren con mayor naturalidad al contexto en el que estamos trabajando.

Un gran ejemplo de esto es WordPress mismo como plataforma. Muchos ven como un defecto imperdonable el hecho de que WordPress aplique y permita aplicar varios enfoques distintos para la resolución de problemas. Algunas cosas se resuelven usando OOP, otras con funciones, y otras con programación lisa y llanamente estructurada. No hay un único método o patrón de resolución dictado por una inteligencia magnánima para extender o modificar funcionalidad, sino que se permite al programador aplicar el método que le resulte más cómodo a la hora de hacer lo que planea hacer. Y si bien esto puede ser una puerta de entrada a las malas prácticas, también aporta a que el programador novato se introduzca rápidamente en un framework con pocas restricciones, a partir de lo cual puede (o no) ir mejorando su trabajo. Esta flexibilidad es una de las mayores fortalezas de WordPress, es un voto de confianza en que el programador puede encontrar la mejor solución por su propia cuenta, pero también el reconocimiento de que no todos los problemas pueden ser tratados de la misma manera.

De esto se desprende algo que puede ser tan fascinante como terrorífico: la realización del ideal puro no existe. Sócrates, a través de sus interrogatorios, intentaba llegar a una definición general que se pudiera aplicar a todos los casos particulares, pero tenía bien presente que, en el mundo real, ninguno de los casos particulares iba a cuadrar de manera exacta con la definición general. Sin embargo, no por eso se debía dejar de mirar a la definición general como punto de referencia. Casi toda la filosofía que vino después de él se trató de las infinitas posibilidades que hay para entender y tratar esta relación entre la definición y lo definido. Lo que muchos tienen claro es que, por más que la perfección no exista, aún deberíamos seguir apuntando a lo más similar a esa perfección que podamos, y acercarnos cada vez más cuando se presente la posibilidad.

Conclusiones

Para terminar quisiera aventurar una respuesta a la pregunta inicial: ¿hasta qué punto nosotros mismos somos responsables de que nos pase esto? Mi respuesta es: hasta el punto en el que dejamos que nos pase. Es totalmente tautológico, críptico, pero creo que la respuesta definitiva es distinta para cada uno. Hay que aprender a reconocer la particularidad de cada iteración a partir de ese autoconocimiento que vamos desarrollando.

Necesitamos romper muchas ataduras que nosotros mismos nos creamos. Para ser mejores, pero no con respecto a los demás, sino con respecto a nosotros mismos. Creo que, de alguna manera, podemos aplicar todo esto a nuestra vida en general, no solo a nuestro trabajo. Esta charla apunta a programadores porque es el sector que mejor conozco, pero creo que esto es aplicable también a otras áreas. Los diseñadores, los analistas, los project managers, seguramente también pueden encontrar puntos en común con todo esto. No se trata de estigmatizar al programador con todos estos problemas, sino de superar lo que venimos haciendo a partir de la exploración personal, y eso está al alcance de cualquiera. La manera que encontremos para hacerlo depende de cada uno, no hay una solución definitiva para esto.

Hay una falsa concepción de WordPress como una herramienta limitada, insegura y mal construida, y eso es algo en lo que todos tenemos que trabajar más para cambiar, porque los que tuvimos oportunidad de evaluar y comparar varios sistemas diferentes en profundidad sabemos que este no tiene nada para envidiarle a los demás. No me refiero a cambiar esa concepción para mostrar que somos mejores que otros, ni que estamos a la altura de alguien más, porque acá no estamos compitiendo con nadie. Hablo de cambiar esta concepción para que se sume más gente a este proyecto, para que esta comunidad crezca, y para que eventos como este sean algo cada vez más común, para hacer cosas que nos reporten un beneficio a todos en conjunto.

Si algo bueno tiene esta comunidad es que está llena de gente común, como cualquiera de nosotros. Y el orgullo que esas personas sienten por eso es lo que las hace particulares. Yo realmente disfruto mucho de estar trabajando todos los días entre toda esta gente. Por eso esto es más un conjunto de reflexiones sobre cosas que nos pasan a muchos que un discurso de un tipo que pretende decirle a los demás lo que tienen que hacer con su vida. No es mi intención hablar desde una posición de superioridad. Por eso también quería compartir un poco de mi historia.

No me considero el mejor poniendo en práctica todo esto; de hecho lucho contra todos estos problemas a diario. La mente del ser humano es paradójica y, en los últimos años, mientras trataba de ser tan honesto conmigo mismo en lo que respecta al trabajo, no lo estaba siendo con lo relacionado a mi carrera académica. Como pasa con muchos proyectos abandonados, la forma en que manejé mi carrera en filosofía no fue algo sobre lo que haya reflexionado lo suficiente en el momento en que tendría que haberlo hecho, cuando todavía me importaba. Necesitamos aferrarnos a las cosas antes de que dejen de importarnos.

Creo que somos un puñado de nenes con tanto miedo a vivir y sufrir que jugamos a ser grandes. Y lo que es peor, nos olvidamos de que estamos jugando.

– Santiago Bragagnolo

La sabiduría no se da de golpe, y la experiencia no es solo producto de los años. Cuando estaba en la secundaria yo era un adolescente bastante tímido y retraído, muy inseguro. Una idea que me tranquilizaba era que un día iba a ser un adulto y que ya no me iba a sentir así, como si mágicamente todo lo que me hacía dudar de mí mismo fuera a desaparecer. Hoy tengo 30 años, y todavía espero que eso pase algún día. Como muchos otros, estoy tratando de convivir día a día con mis inseguridades, con costumbres que intento cambiar, en lugar de dejar que simplemente me paralicen.

Espero que mi experiencia pueda ser útil.

The post Psicología del Programador: Conociéndose a Sí Mismo appeared first on Andrés Villarreal.

Y si bien es cierto que los críticos a veces pueden estar en lo cierto, y en otras ocasiones ser un hato de imbéciles, es estúpido confiar en que nuestra forma de hacer las cosas es infalible. Siempre va a haber al menos un caso en el que nuestros métodos fallen, que nuestra propuesta de solución no se adapte las necesidades de la situación. Se nos va a presentar la dicotomía entre hacer una excepción mientras perdemos consistencia con respecto a lo que venimos haciendo, o conservar nuestra solución aunque esté lejos de ser la más óptima posible.

Sea cual sea el camino que elijamos, y ya sea sencillo o complicado, podemos encontrarle un cierto costado productivo: nos puede servir para replantearnos la manera en la que venimos haciendo las cosas.

Sabemos lo difícil que es pararse a hacer replanteos a veces, y también es cierto que no podemos vivir entre replanteos. No hace falta ser programador para saber esto; podemos deducirlo de cualquier relación problemática que hayamos tenido alguna vez con cualquier persona. Pero si de vez en cuando nos detenemos en el problema antes de poner manos a la obra, podemos evaluar cuáles son las cosas que necesitamos mejorar, las que siguen funcionando, o si hace falta modificar nuestro enfoque en algo o por completo.

Pero lo realmente importante acá es seguir, no quedar paralizados en la duda. Los contratiempos son obstáculos, pero sabemos que tarde o temprano los vamos a poder sobrepasar, incluso aunque no lo hagamos de la mejor manera posible, o pese a que nuestra propia solución no nos convenza. Nos vamos a deprimir, a desmoralizar, y a pensar que somos unos inútiles, o que los demás son unos idiotas. Pero una vez que nos hayamos tomado el tiempo suficiente para sentirnos mal, necesitamos volver a lo que estábamos haciendo, y tener en cuenta que en el futuro vamos a tener que seguir replanteando enfoques para poder seguir construyendo.

Ni lo que somos ni lo que hacemos es una cadena interminable de errores. En todo caso, algunas cosas nos salieron bien y otras mal, y lo que necesitamos es ser honestos con nosotros mismos al respecto de lo que nos sirve de lo que hicimos y lo que no. Solamente teniendo presente lo que funciona y evitando repetir lo que no nos da resultados podemos seguir nuestro trabajo con vistas a hacerlo cada vez mejor, y a ser cada vez menos infelices.

Cuando un sistema está repleto de trabajo irreflexivo, hecho a las apuradas, y con un mantenimiento solo destinado a resolver problemas ocasionales, termina convirtiéndose en una montaña de malas decisiones. Eventualmente va a llegar a un punto en el que se vuelva inmantenible o inmanejable, y eso solamente se va a poder resolver con un replanteo completo del sistema. Es inevitable que nos pase en algún punto, pero creo que es deseable que ocurra lo menos posible. Y suele ocurrir cuando no se reflexiona acerca del hecho de que un sistema que cumple ciertos requisitos importa más que la manera en que se llega a esos requisitos. También cuando confiamos demasiado en nuestra experiencia, en nuestro sentido común o en nuestra mera intuición, sin ninguna autocrítica acerca de nuestro trabajo o nuestra forma de entender ciertas cosas.

The post El problema de la autovalidación appeared first on Andrés Villarreal.

I’ll skip my point of view about the way the update was managed by the Core team, and I won’t dare to say that there’s a “wrong” way to use shortcodes, since I think that any provided tool should be used in any possible way that’s allowed by its internal logic. I’m just gonna stick to talk about a practice that can help to prevent some issues with the Shortcode API.

What do I mean with this? I know for a fact (because I published a couple of plugins and people often ask me about this) that a lot of developers write shortcodes right inside their template files. For example, I’m used to see things like this inside templates:

<div id="post-content">
    <?php do_shortcode( '[shortcode arg1="value1" arg2="value2"]' . get_the_content() . '[/shortcode]' ); ?>
</div>

For most cases, something like that will work fine. That’s something that both the Shortcode API and the templating system allow to do, so it’s OK to do it. But you need to keep in mind that this is an approach that comes with a lot of possible issues, the most important being that PHP files are not so easy to be updated as posts are (at least for non-tech-savvy users) in case the way of parsing shortcodes changes (as it happened in 4.2.3). There are other issues, and I’m gonna mention some of them, but I think this one should be our main focus.

What has a lot more sense in the context of templates is to just not use shortcodes at all, and just leave them for the post editor. Inside PHP files we have a lot more control over the output we’re generating, and we should take advantage of that as much as we can (and as long as our code doesn’t end up being a mess). By using shortcodes inside templates we lost a lot of control and internal consistency, since shortcodes are not exactly logic, and not exactly markup. They fall in the middle of both categories, and that’s great while we are generating content, but not while we’re defining how that content is gonna be served to the user. Shortcodes are just a quick front-end for internal functionality that allows to manage that functionality without having to write actual code, but often there’s not really a good reason to use them while we’re actually coding something.

Shortcodes actually work as “masks” for functions and class methods that are defined somewhere within the code of our application, being that a plugin, a theme or the WordPress Core itself. These functions and class methods are accessible and working code that we can use and handle directly instead of using the shortcodes that call them. This way we can get rid of all the parsing-related problems we could step into while using shortcodes, and keep internal consistency inside our PHP files at the same time.

So, how can you know what functions should be used? Functions become shortcodes by calling register_shortcode(). If you have a shortcode called [shortcode], you should look for the line that registers it with register_shortcode(). So you’re gonna find something similar to this in some part of your application:

register_shortcode( 'shortcode', 'my_shortcode_handler' );

The first parameter is the name of the shortcode, and the second one is the name of the function that handles it. So inside your template files, as they’re written using PHP, you can use that function instead of parsing the shortcode with do_shortcode(). If you look for the declaration of my_shortcode_handler(), you’ll find something like this:

function my_shortcode_handler( $attr, $content ) {
     // some PHP code ...
}

Notice that the first parameter, $attr, is the list of arguments that you’re passing to the shortcode, while the second, $content, is whatever you put inside the opening and closing tags. So we can refactor our template this way:

<div id='post-content'>
    <?php echo my_shortcode_handler( array( 'arg1' => 'value1', 'arg2' => 'value2' ), get_the_content() ); ?>
</div>

By doing this, we make sure the function always receives what we need to be processed without worrying for possible modifications to the Shortcode API that don’t support the current implementation of our shortcode.

There are, however, moments when a call to a shortcode can indeed be a good solution to a problem. For example, when we’re working with a shortcode that can be overridden by many plugins, and/or we don’t really care about what function is the one that’s operating behind the it. We just need the markup printed by the shortcode, whatever that markup is. Such can be the case of [gallery], which we may want to use to show a gallery for our plugin or theme without caring about other plugins that may be redefining or extending the shortcode. We just want it to be displayed with the markup and styles of the current gallery functionality, so it’s OK to do something like this:

$image_ids = array( 20, 38, 24, 78, 93 );
?>
<div id='post-gallery'>
     <?php echo do_shortcode( '



' ); ?>
</div>

In this case, we sacrifice some internal consistency in order to get a very specific functionality, and that’s fine for some situations. However, as every recommended practice, the decision about how it should be applied depends on every particular context, but I think it’s always good to know the possible alternatives that we can count on, and have them present when we need to make decisions.

The post Why Using Shortcodes Inside Templates Isn’t Always a Good Idea appeared first on Andrés Villarreal.

Los problemas más típicos tienen que ver con cómo manejar el código que producimos nosotros mismos y que producen otros programadores, con cómo se relaciona una pieza de código con otra, qué rompe con nuestros esquemas, qué cosas necesitamos crear a medida para que algo que no cumple con ciertos parámetros aún pueda ser integrable con lo que hacemos, qué cosas necesitamos reescribir o descartar por completo, cuándo es necesario dejar de usar algo a lo que le pusimos muchísimo empeño, etc. Tiene que ver tanto con cuestiones técnicas o prácticas como psicológicas o emocionales. Con la manera en que vemos el mundo, con qué tanto pensemos que tenemos que amoldarnos al mundo, o que el mundo tiene que amoldarse a nosotros. Tiene que ver con el tipo de decisiones y perspectivas que tomamos en nuestra vida diaria por fuera de nuestra actividad de programadores. Es un error creer que aprender a programar solamente consiste en aprender un conjunto cerrado de reglas cuya aplicación no varía ni depende de factores externos a la programación misma.

Mucha gente tiene el preconcepto de que la programación es un arte complicado. Quizás porque hay que lidiar con cálculos, condiciones, diferentes tipos de entidades y datos, distintos lenguajes y tecnologías, mensajes de errores que a veces resultan incomprensibles, etc. Todos esos son factores mecánicos, de fácil comprensión, porque son muy parecidos o tienen que ver con cosas que aprendimos durante los primeros años de nuestra educación. Incluso existen casos de gente que aprende a programar mientras aprende a leer, y no son necesariamente genios, sino que crecieron en un contexto en el que la programación era un factor familiar, como quienes aprenden a tocar un instrumento en sus primeros años.

Una vez que aprendemos estos conceptos primordiales, los incorporamos a nuestra vida cotidiana muy rápidamente, e incluso contamos con herramientas que nos lo facilitan si no somos tan memoriosos u ordenados como para retenerlos a perpetuidad. Una vez pasado el preconcepto de que todo es tan difícil y que incorporamos los conceptos básicos es que aparecen los verdaderos problemas, los que pueden resultar terribles o interesantísimos de resolver, y es ahí donde empieza el verdadero trabajo del programador, que no implica problemas muy diferentes de los de la vida cotidiana.

The post Programar no es (tan) complicado appeared first on Andrés Villarreal.