La verdad es que no es algo que a uno le haga falta todos los días, pero a mi me hacía falta y me ha resuelto el problema.

En el ejemplo que hay en dicha página se usan las funciones getSelectionStart y getSelectionEnd. La primera nos dice donde está el cursor, mientras que la segunda nos dice dónde finaliza la selección (siempre y cuando getSelectionEnd devuelva un valor distinto a getSelectionStart).

A continuación teneis estas dos funciones:

function getSelectionStart(o) {
 if (o.createTextRange) {
   var r = document.selection.createRange().duplicate();
   r.moveEnd('character', o.value.length);
   if (r.text == '') return o.value.length;
   return o.value.lastIndexOf(r.text);
 }
 else {
    return o.selectionStart;
 }
}
 
function getSelectionEnd(o) {
 if (o.createTextRange) {
 var r = document.selection.createRange().duplicate();
 r.moveStart('character', -o.value.length);
 return r.text.length;
 } else {
   return o.selectionEnd;
 }
}

Entre ellos, Gonzalo dice:

Si habeis trabajado con desarrollo en base a tests no entiendo el comentario de que porque se llevan mal con el tiempo, la verdad.
Los tests ahorran muuuucho tiempo, tanto en la fase de depuración y estabilización de un proyecto como a la hora de añadir funcionalidad.
Y otro punto que los hacen críticos, los tests unitarios salvan proyectos que sin ellos estarían abocados al fracaso.

Me doy por aludido, puesto que creo que Gonzalo se refiere al comentario en el que digo:

Testeo y “tiempo razonable” no se suelen llevar bien

Así que en vez de un comentario he pensado que sería mejor poner este tema encima de la mesa, y compartir mis ideas sobre el testeo.

Realmente a lo que me refería es que muchas veces no es posible hacer un buen testeo o un testeo exhaustivo de una determinada funcionalidad en un tiempo razonable.

Mi opinión es que hacer más o menos tests depende siempre del tipo de proyecto. Por poner dos casos extremos, no es lo mismo hacerte un miniprograma para ti, que por ejemplo renombre todos los archivos de un directorio usando algún tipo de patrón, que por ejemplo hacer un programa que va a controlar la trayectoria de un misil.

No sólo depende del tipo de proyecto si no también de los plazos del proyecto y de los recursos con los que se cuente. No es lo mismo un equipo de un desarrollador, que un equipo con 5. Tampoco es lo mismo disponer de 7 meses para hacer un parser de XML, que disponer de 2.

Hay muchos elementos que influyen.

Volviendo a la discusión anterior, sobre que tests y tiempo razonable no se llevan bien, básicamente esto significa que si tu proyecto es de andar por casa, tus recursos son limitados o tu tiempo es escaso, probablemente puedas y debas posponer algunos tests.

Estoy de acuerdo con Gonzalo con que los tests traen muchos beneficios, pero esos beneficios, desde mi punto de vista son a medio y largo plazo. A corto plazo los tests beneficiosos son aquellos que te permiten ir desarrollando la aplicación y probando lo que tu crees que van a ser los casos más comunes.

Soy partidario de hacer tests desde el primer momento, de  hecho, en otro comentario mío se puede leer:

Mi opinión (al menos es lo que yo hago) es que hay que ir haciendo tests para probar las cosas conforme se desarrolle
[...]
cuando se encuentra un bug (o bien por uno mismo, o por un usuario), mi punto de vista es que hay que añadir un test-case que lo reproduzca

Se pueden escribir páginas y páginas sobre el testeo de software, sobre metodologias de programación, sobre si hay o no que llegar al 100% de cobertura de código… el caso es que escribir un buen artículo que cubra todos estos aspectos en un tiempo razonable, tampoco lo veo posible…

¿Haceis tests a menudo? ¿lo considerais perder el tiempo?

¿Cuales son vuestras prácticas habituales?

Como siempre, vuestras ideas y opiniones son bienvenidas en los comentarios y/o posts en vuestros respectivos blogs.

Es decir, los tests están para capturar y mostrar si hay algún bug, sin embargo cuando todos los tests pasan, no significa que la aplicación no tenga bugs, normalmente significa que no hay suficientes tests para capturarlos

Por otro lado, cuantos más tests haya se supone que mejor cobertura tendrá la aplicación y mas robusto será el software que hagamos.

Básicamente consiste en insertar unos valores semilla, y posteriormente ejecutar:

INSERT INTO t SELECT * FROM t;

Con lo cual se insertan de nuevo los elementos existentes en la iteración anterior. Claramente el crecimiento es exponencial (2ⁿ), y partiendo de un único campo en la base de datos, en tan solo 23 iteraciones se consiguen 8.388.608 datos (la verdad es que 8 millones de registros ya son registros).

Yo hasta ahora hacía iteraciones de sentencias insert en PHP… la próxima vez me lo replantearé

Realmente creo que buscando por internet se pueden encontrar puntos a favor y en contra sobre el uso espacios o tabs. Incluso hay discusiones sobre cuantos huecos se deben usar para indentar (al margen de si se usan tabs o espacios).

Vayamos por partes.

El propósito de la indentación (independientemente de si usamos tabs o espacios), sirve para que visualmente distingamos fragmentos de código, es decir, la indentación tiene el objetivo de facilitar la lectura de código.

Ahora voy a exponer mi punto de vista sobre las distintas opciones en cuanto al tamaño de la indentación:

• no usar indentación alguna: esto es perfecto si quieres que tu codigo sea ilegible por los demás humanos, e incluso por tí, despues de unas horas.
• usar 1 caracter de indentación: enhorabuena, no eres un completo desastre, pero aún te queda mucho camino por andar.
• usar 2 caracteres de indentación: esta es la opción que yo utilizo siempre que puedo. Dos caracteres te permite que cuando tienes una función con bastantes bloques anidados (no digo que esto pase muy a menudo, pero pasa), no acabes escribiendo en la linea 40. Además 2 caracteres son suficientes para distinguir bloques.
• usar 3 caracteres de indentación: esta opción no creo que la use mucha gente. Por lo general, los informáticos tenemos tendencia a buscar multiplos de 2.
• usar 4 caracteres de indentación: esta opción también me parece perfecta. No todo el mundo verá igual de claro la indentación con 2 caracteres, sobretodo si está en sus primeros años de escribir código, así que esta es la opción perfecta. Mucho mejor que los 8 caracteres que suelen venir por defecto en muchos editores.
• usar 5, 6 e incluso 7 caracteres: vale, esto me lo salto por lo mismo que he dicho respecto a los 3 caracteres. Es más, si usas 5, 6 o 7 caracteres, casi casi estás a la altura del que usa 1 caracter (sin ofender :p).
• usar 8 caracteres: esta es la opción por defecto en muchos editores. 8 caracteres son muchos caracteres. Demasiados caracteres. Nuevamente, si estás empezando a programar, me parece bien que respetes lo que dicen algunos editores, sin embargo, conforme pase el tiempo, te darás cuenta de que 8 es demasiado, que incluso quita claridad a tu código, y que para complir con el propósito de la indentación, es mucho más claro usar 4 caracteres que 8.
• más de 8 caracteres: C’mon!!!!! ¿de verdad hay alguien que use más de 8 caracteres? Creo que es algo que no he probado en la vida, y me atrevo a asegurar que si programas usando más de 8 caracteres de indentación, mejor que vayas buscando otro trabajo…

Tras todo esto, decir que estoy de acuerdo con cualquiera que elija 2 o 4 caracteres de indentación, pero si has elegido cualquier otra opción, es que aún te falta madurar. Probablemente no sea culpa tuya, aún estás verde, estás aprendiendo, pero por suerte has llegado a esta página, y te acabo de ahorrar tiempo de pruebas y miles de lineas de código escritas con distintos tipos de tabulación.

Aunque mañana voy a discutir si es mejor espacios o tabs, te pongo mi conclusión ya:

Usa 2 o 4 espacios para la indentación. Nunca uses tabs.

Una vez elijas una opción (2 o 4 espacios), se coherente y no cambies de indentación a mitad de un proyecto.

Lo que proponía Juanjo (de probarlo con el g++ optimizando a tope) me ha parecido buena idea, así que he hecho unas cuantas pruebas en C++.

Los resultados han sido interesantes

Para mi grata sorpresa, el g++ ha optimizado muy bien la función strlen. Sin embargo, no es capaz de optimizar “cualquier” función que tenga sus mismas características.

En el archivo test-strlen.cpp he realizado varias pruebas (más abajo están los fuentes descargables en un .tgz).

La primera prueba ha sido realizar un bucle con strlen, tal cual el código de PHP, y otro donde el strlen está fuera del bucle.

 // strlen dentro del bucle
 for (j = 0; j <= strlen (str); j++) {
    copy [j] = str[j];
 }
 
 /* [...] */
 
 // strlen fuera del bucle
 len = strlen (str);
 for (j = 0; j <= len; j++) {
    copy [j] = str[j];
 }

Ha resultado que el g++ ha optimizado muy bien el primer bucle, hasta el punto que ambos probablemente ejecuten el mismo código, no se aprecia diferencia.

Una vez hecho esto, me he dicho, voy a fastidiar un poco al compilador, así que he añadido una linea, que básicamente modifica str, que es la cadena que se le pasa al strlen, para que el compilador tenga que evaluar siempre el bucle:

 // strlen dentro del bucle, modificando str
 for (j = 0; j <= strlen (str); j++) {
    copy [j] = str[j];
    if (j == 1) str[j] = str[j-1];
 }

El caso es que ha funcionado, básicamente el compilador no lo ha podido optimizar, no obstante esto no me vale para ejemplificar lo que decía en el artículo anterior, porque el compilador ha hecho lo que tenía que hacer, y la variable ha sido modificada dentro.

He aquí los resultados de test-strlen:

Making the common mistake(not optimizable): 9.20
Making the common mistake(optimizable by the compiler): 0.00
Avoiding the common mistake: 0.00

Total, que he creado otro archivo de ejemplo, el test-custom-strlen.cpp cuyo objetivo es implementar una función equivalente a strlen y ver si el compilador es igual de inteligente.

Básicamente, en este archivo he creado 5 funciones, vease: custom_strlen, custom_strlen_const, custom_strlen_const2, strlen_wrap, strlen_wrap_const

/** this is a custom strlen function */
size_t custom_strlen (char *str)
{
  char *ptr = str;
  if (ptr == NULL) return 0;
  while (*ptr != '\0') ptr++;
  return (size_t)(ptr - str);
}
 
/** this is same as above, but telling the compiler we are not touching str*/
size_t custom_strlen_const (const char *str)
{
  const char *ptr = str;
  if (ptr == NULL) return 0;
  while (*ptr != '\0') ptr++;
  return (size_t)(ptr - str);
}
 
/** this strlen updates input string, no matter that is const */
size_t custom_strlen_const2 (const char *str)
{
  char *ptr = (char*)str;
  if (ptr == NULL) return 0;
  while (*ptr != '\0') ptr++;
 
  ((char*)str)[0] = 'a'; // update string
 
  return (size_t)(ptr - str);
}
 
/** this is a wrapper over strlen function */
size_t strlen_wrap (char *str) {
  return strlen (str);
}
 
/** this is a wrapper over strlen function with constant input */
size_t strlen_wrap_const (const char *str) {
  return strlen (str);
}

Y los resultados ha sido los siguientes:

using custom_strlen: 3.90
using custom_strlen_const: 4.05
using custom_strlen_const2: 4.04
using strlen_wrap: 0.00
using strlen_wrap_const: 0.00

Vamos, que el compilador, con -O3, no ha sido capaz de optimizar ninguna de mis funciones. Y el caso es que la función custom_strlen_const era candidata para ser optimizada igual que el strlen (función con un parámetro constante, internamente usa const para todo y no cambia el valor de nada).

Total, que sigo manteniendo la misma opinión que en el artículo anterior: si una función se va a evaluar siempre a lo mismo, mejor que esté fuera del bucle, porque no se sabe si el compilador o intérprete va a ser capaz de optimizarla o no.

También me gustaría decir que por lo general este tipo de cosas, normalmente, tampoco va a suponer ningún cuello de botella en ninguna aplicación, ni va a suponer tiempos abismales de ejecución, por lo que no es preciso prestarle mucha importancia; ahora bien, son pequeños detalles, que se van sumando y sumando, y oye, quizá no reduzcan los tiempos un 30%, pero un 5%…

Aquí teneis el archivo comprimido con los códigos fuentes de ejemplo. (descomprimir, ejecutar make y listo)

¿Alguien ve algo raro en el siguiente código?

<?php
for ($i = 0; $i < strlen ($string); $i++) {
    // whatever this loop does
}

A priori ¿Parece que todo está bien, no? Si te lo parece es que no eres consciente aún.

Es bien sabido que las condiciones de los bucles se evaluan tantas veces como iteraciones tiene el bucle, con esto no estoy descubriendo nada a nadie, sin embargo, si se mete un strlen para medir la longitud de la cadena en un bucle que se ejecuta tantas veces como caracteres hay, acabamos de elevar al cuadrado el tiempo de ejecución.

Tanto en C como en PHP, la función strlen necesita recorrer toda la cadena hasta encontrar el ‘\0′ para determinar su longitud, así pues, si la longitud es 20, strlen necesitará 20 iteraciones para determinar que la longitud es 20. El problema es que el bucle que estamos haciendo también tiene 20 iteraciones, y en cada iteración se ejecuta strlen, que consume otras 20 iteraciones (claro que en PHP esas 20 iteraciones se ejecutan en código máquina, y no en el interprete), por lo que tendríamos que el coste de ese bucle para una cadena de 20 caracteres es de 20*(20 + lo que hay dentro del bucle) = 400 + 20*lo que hay dentro del bucle.

El siguiente script (error común con los bucles) muestra un ejemplo de esto en PHP, donde dentro del bucle no se hace nada, y se puede observar como un bucle es mucho más lento que el otro.

Los resultados tras ejecutarlo en mi ordenador han sido:

strlen($sentence) =  12608 bytes
Making the common mistake: 3.02566313744 seconds
Fixing the common mistake: 0.958508968353 seconds

Creo que se puede apreciar claramente la diferencia

Finalmente, aunque he usado PHP para ilustrar el error, y concretamente strlen, si nos olvidamos de strlen y de PHP, esto es aplicable a otros muchos lenguages C/C++/Java/Pascal/PHP/Python/Perl/Ruby y un largo etcetera; y pasa en todos los lenguajes porque todos los lenguajes usan el mismo concepto, la condicion de salida del bucle se evalua en cada iteración. Quizás no ocurra cuando se utilizan cadenas, porque guardan la longitud en una variable, pero puede que pase al mirar la longitud de listas enlazadas, etc…

Conclusión: si en el bucle estás llamando a una función que siempre te va a devolver lo mismo, mejor guardalo en una variable y usa esa variable dentro del bucle, te ahorrará sorpresas

Enlaces interesantes:

• Back to basics, un excelente artículo de Joel (disponible en Español) donde reflexiona sobre algunas cosas directamente relacionadas con esto.

Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in ....

Ese error me ha salido mientras estaba programando… me ha parecido tan raro que es digno de ser posteado.

El caso es que buscando un poco por internet, en la wikipedia sin ir más lejos, hay una entrada sobre Paamayim Nekudotayim y donde básicamente se dice que ese nombre de token se corresponde con “::“, el que se usa para acceder a un método o variable de clase.

Es curioso la de nombres que se le ponen a los tokens, con lo fácil que hubiera sido llamarlo T_DOUBLE_COLON.

Ale, una vez resuelto el enigma, voy a ver si sigo programando un poco…