¿Y si todo es una engañifa?

Cuando entré en la universidad tenía una visión de lo que era ser científico e investigar, y con los años esa visión se ha tornado en algo muy distinto. En vez de explicar yo mismo cuál es el problema de esta transformación, recomiendo la lectura de dos artículos que lo explican muy bien:

¿Y si la ciencia no es eso que tú crees?:

http://sociedad.elpais.com/sociedad/2013/12/11/actualidad/1386797483_412515.html

Por qué revistas como ‘Nature’, ‘Science’ y ‘Cell’ hacen daño a la ciencia:

http://sociedad.elpais.com/sociedad/2013/12/11/actualidad/1386798478_265291.html

Este último lo podéis leer en inglés:

How journals like Nature, Cell and Science are damaging science:

http://www.theguardian.com/commentisfree/2013/dec/09/how-journals-nature-science-cell-damage-science

Y por otro lado, recientemente Elsevier publicó una explicación sobre sus avisos “takedown”: si detectan que has publicado en tu web un artículo que ha sido publicado con ellos, te envían un aviso para que lo retires:

A comment on takedown notices (with update):

http://www.elsevier.com/connect/a-comment-on-takedown-notices

Un principio básico de la ciencia es el compartir los resultados y sin embargo hay gente que te prohíbe que lo hagas. El sistema está totalmente pervertido…

La velocidad de PHP

¿Existen formas mejores o peores de escribir el código en PHP?

Claro, pero todo depende del punto de vista. A veces, el código más rápido de escribir no es el más fácil de entender o el más rápido de ejecutar (eficiente) o el más fácil de mantener. El concepto de “el mejor código” depende de cómo se mida lo de mejor.

Si lo que queremos medir es el tiempo de ejecución, en The PHP Benchmark nos aclaran algunas dudas.

¿Es más rápido echo o print?

¿Es más rápido isset() o empty()?

¿Es más rápido for() o while()?

¿Es más rápido foreach(), for() o while(list() = each())?

¿Es más rápido switch() o if/elseif/else?

Muy, pero que muy interesante.

 

¿Se puede decir que quien escribe esto sabe programar?

Hace tiempo escribí la entrada No está mal, funciona, en la que mostraba la actitud de algunos alumnos a los que sólo les importa que su código funcione, no se molestan en pensar si el código está realmente bien o mal.

Para que lo entienda todo el mundo, es algo parecido a “excrivir un testo con faltas de hortografia”. Se entiende, ¿verdad? Pues está bien, diría alguno de mis alumnos.

Recientemente, mis alumnos (tercer curso) tenían que escribir un código en PHP para permitir el acceso de un usuario a la parte privada de una aplicación web: el típico login con nombre de usuario y contraseña. Más de un alumno (¿un 20%?) escribió lo siguiente o algo parecido:

$sentencia = "SELECT * FROM Usuarios";
$resultado = mysqli_query($link, $sentencia);
while($fila = mysqli_fetch_assoc($resultado)) {
 // $_POST["user"] y $_POST["password"] provienen del formulario de login
 if($fila["User"] == $_POST["user"] && $fila["Password"] == $_POST["password"]) {
   $_SESSION["Id"] = $fila["Id"];
   $_SESSION["Name"] = $fila["Name"];
 }
}
if(!empty($_SESSION["Id"])) {
 // Redirección página principal parte privada
}
else {
 // Redirección página principal parte pública
}

No nos fijemos en que no hay ninguna comprobación de los posibles errores que pueden ocurrir… eso es muy importante, pero no es lo que quiero destacar. ¿Cuál es el problema principal de este código?

Para un ojo educado en la programación, el código anterior es como “ber uvo escrito sin ache y con ube”.

¿Cómo competir con esto?

Recientemente recibí este correo:

Quería aprovechar la ocasión para hacerle una pregunta que me ronda por la cabeza. A partir, de los anteriores videos y usando el framework de Bootstrap realice pruebas diseñando una página Web. Tras esto, y en el punto en el que debía incorporar código para la validación de los usuarios contra la BD, cargar noticias, es decir, darle funcionalidad me surgió la siguiente duda. Existen herramientas como Joomla basadas en templates que automatizan todo el desarrollo de páginas Web añadiendo módulos sobre las plantillas que hacen mucho del trabajo que debemos realizar a la hora de desarrollar una Web, ¿Cómo competir con esto?, Cual es su opinión sobre este tema. (Al final el usuario valora lo que ve no lo que hay detrás)

¿Cómo competir con esto?

Esta es una cuestión que me plantean incluso mis alumnos alguna vez, ¿por qué estudiar HTML, CSS, JavaScript y PHP? ¿Por qué no estudiar un gestor de contenidos como Joomla, Drupal o WordPress? Se pueden hacer webs mejores, en menos tiempo, etc.

En primer lugar, tanto en mis clases en la universidad como en el curso iDESWEB, yo lo que enseño es a desarrollar aplicaciones web. Lo que yo enseño te permitiría crearte tu propio framework, como Codeigniter o Symfony, o incluso tu propio gestor de contenidos como Joomla, Drupal o WordPress. Aunque existan esas herramientas, también tiene que existir alguien que cree y mantenga esas herramientas. Por tanto, aprender a programar con HTML, CSS, JavaScript y PHP es necesario, hace falta gente que sepa.

Un gestor de contenidos no es la panacea, no es la solución para todos los problemas. Desgraciadamente, mucha gente aprende algo y se cree que eso es la solución para todo. El one size fits all pocas veces existe en ingeniería. Sí, existen plugins para los gestores de contenidos que te permiten hacer muchas cosas sin tener que bajar a bajo nivel, sin tener que programar, pero otra vez volvemos a lo mismo: alguien tiene que programar esos plugins. Y muchas veces el plugin no se adapta exactamente a lo que necesitas y tienes que implementar ciertas modificaciones o adaptaciones.

Un gestor de contenidos es muchas veces matar moscas a cañonazos. En la entrada sobre efectividad en la Wikipedia lo explican muy bien:

La efectividad es la capacidad de lograr un efecto deseado, esperado o anhelado. En cambio, eficiencia es la capacidad de lograr el efecto en cuestión con el mínimo de recursos posibles viable.
Ejemplo: matar una mosca de un cañonazo es eficaz (o efectivo: conseguimos el objetivo) pero poco eficiente (se gastan recursos desmesurados para la meta buscada). Pero acabar con su vida con un matamoscas, aparte de ser eficaz es eficiente.

Con los conceptos de eficaz y efectivo llegamos a la madre del cordero: un gestor de contenidos, como Joomla, Drupal o WordPress, consume muchos recursos. ¿Cuántos? Muchos… Una vez encontré una página web en la que se comparaba el tiempo de mostrar un mensaje como “Hello world!” con un HTML estático, con un PHP que ejecuta echo “Hello world!” y con WordPress que tiene una entrada que muestra “Hello world!”. La diferencia de consumo de recursos y de tiempo de ejecución era abismal entre WordPress y las otras dos opciones.

Desgraciadamente, no puedo encontrar esa página otra vez, pero sí que conozco algunas páginas que hacen la misma comparativa pero a nivel de frameworks de PHP (ya hablé de ello en ¿Es lento PHP?):

Por ejemplo, en el último tenemos:

  • Apache static file: 2991.65 Requests/sec with a time per request of 0.334ms.
  • PHP on Apache: 2518.25 requests/sec with a time per request of 0.397.
  • Symfony: 32.21 requests/sec with a time per request of 31.048ms.
  • CakePHP: 34.90 requests/sec with a time per request of 28.657ms.

Solamente utilizar un framework de PHP añade una penalización brutal al tiempo de ejecución. No digamos ya el uso de un gestor de contenidos…

Sí, el tiempo de ejecución de un framework o de un gestor de contenidos se puede mejorar, se puede optimizar, pero en el fondo, siempre existirá una diferencia importante.

Volviendo a la pregunta que se me planteaba, “¿cómo competir con esto?” y “al final el usuario valora lo que ve, no lo que hay detrás”, eso forma parte de los requisitos que se tienen que tener en cuenta a la hora de afrontar un trabajo. ¿El cliente quiere algo exclusivo, único, que sea eficiente, seguro, hecho a medida? Lo veo difícil con un gestor de contenidos.

Esto me recuerda los tres tipos de trabajos que se pueden hacer:

  • Un buen trabajo rápido (no saldrá barato).
  • Un trabajo barato y bueno (no será rápido).
  • Un trabajo barato rápido (no será bueno).

trs-tipos-de-trabajo

Está claro que en el segmento de las webs a 300€ en una semana, plantearse un desarrollo a medida realizado desde cero es un sinsentido. En ese segmento, una web realizada con un gestor de contenidos es una muy buena opción. Pero para alguien que está dispuesto a gastarse varios miles o varios cientos de miles de euros, lo que se pueda hacer con un gestor de contenidos seguramente no le será suficiente.

En realidad, todo esto no es un problema exclusivo del desarrollo web. El mismo problema aparece en otros contextos y se podría encuadrar en problemas que existen en la sociedad actual, como por ejemplo la McDonaldization.

¿Soy un buen programador?

Esta es una pregunta que seguramente todo programador se hace a lo largo de su vida más de una vez (yo diría que por lo menos una vez por año). Desgraciadamente, el vertiginoso ritmo de la informática origina un “estado de ansiedad” que te hace pensar que no sabes nada, lo cual, en realidad, es verdad. Pero una vez que se asume eso, el siguiente “estado de ansiedad” lo causa la sensación de que tu amigo o compañero de trabajo sí que sabe, lo cual, en realidad, es mentira.

En el artículo Overcoming Impostor lo explican muy bien. Dos párrafos que definen muy bien la causa de este problema y de otros problemas de la informática:

There are two characteristics of coding that can make programmers feel like they’re really struggling, when actually they could be doing just fine. The first thing with programming is that you’re almost guaranteed to have to learn new things as you’re doing it. The rate at which technology is changing is incredible. This can have the effect that one is constantly feeling behind, and that there is an ever-growing amount of stuff to learn.

The second characteristic that’s somewhat unique to programming is that it consists of near constant failure. Unlike learning other skills where one can expect to be reasonably competent after sufficient practice, programming largely consists of constantly failing, trying some things, failing some more, and trying more things until it works. One of the biggest differences between experienced and novice programmers is that experienced programmers know more things to try. Watching people who are just starting to code made me realize how extremely defeating this phenomenon can be.

El lenguaje que usarás todavía no se ha inventado

Once you learned the big ideas, they thought, and this is my experience also, learning another programming language isn’t a big deal; it’s a chore for a weekend. I tell my students, “the language in which you’ll spend most of your working life hasn’t been invented yet, so we can’t teach it to you. Instead we have to give you the skills you need to learn new languages as they appear”.

Traducción:

Una vez que has aprendido las grandes ideas, pensaban, y esta es mi experiencia también, aprender otro lenguaje de programación no es un gran problema, es una tarea para un fin de semana. Yo les digo a mis estudiantes, “el lenguaje que emplearás durante la mayor parte de tu vida laboral no se ha inventado todavía, así que no podemos enseñartelo. En su lugar tenemos que darte las habilidades que necesitas para aprender nuevos lenguajes según vayan apareciendo”.

Brian Harvey, Why Structure and Interpretation of Computer Programs matters.