Archivo de March, 2007

Ordenador nuevo

Los datos más remarcables:

Intel Dual Core 2 E6400 2.16Ghz

Chipset 975X

2 Gb 800 Mhz

XFX nVidia 7600 GT

Me lo he comprado por varias razones, a cada cual más absurda: Porque me apetecía, porque llevo tres años currando en el portatil, … Y alguna no tan absurda pero absurdizada: Porque quiero aprender cosas que requieren de una buena máquina.

Arranca (tiempo total desde que pulsas ON hasta que puedes pusar Inicio en WinXP) en solo 25 segundos.

Lo triste vino el domingo, que me ví programando en PHP con el Textpad, y varios compromisos que me atan -de momento- sin dejarme tiempo para hacer “esas otras cosas nuevas”, y me sentí tan absurdo usando el 10% de su memoria … cada vez me pagan mejor por mi tiempo, y paradógicamente, cada vez se me hace más cuesta arriba atarme a proyectos en mi tiempo de ocio, echo de menos ser libre y programar lo que me de la real gana.

March 12th, 2007 by admin

Anti copy&paste

Just because code is on the Internet doesn’t mean you should cut and paste it into your production system.

Do you chew gum you find on the street?

Give code you find on the ‘NET the same amount of attention you’d give advice scrawled on a public bathroom wall.

Scott’s Rule of Programming – Rule# 0x3eA

March 8th, 2007 by admin

Sobre cómo hacer logs en tus aplicaciones

Fue un tema de reflexión que expuse en su día en los foros de planeta código pero como ahora tengo mi propio blog, pues lo pongo aquí también. La cuestión es tener unas reglas sobre qué información se almacena en el log y cuando usar cada nivel.

Sobre los niveles, venía a poner lo siguiente:

- Debug: Solo te sirve a tí, y ahora.

- Info: Conviene saber que esta sucediendo. Ej. Cuanto tiempo tomó tal proceso (para evitar que se desmadre).

- Warn: No es cómo se esperaba, pero nada ha fallado.

- Error: Falló.

- Fatal: No solo falló, sino que jamás debía haber fallado.

Sobre qué información debería aparecer, venía a decir lo siguiente:

1. Las acciones se loguean lo más inmediatamente posible después de la declaración de la función.

1.1. Puedes alejarlo de la declaración si necesitas recopilar algún dato (a parte de los parametros de entrada) para mostrarlo.

1.1.1. Si ese proceso tiene la más mínima posibilidad de fallar, loguea la entrada a la función, y posteriormente el dato obtenido.

2. Todas las líneas deben acabar con un caracter (en mi caso he elegido el punto) para evitar confusiones entre frases vagamente redactadas y valores que se han convertido a string como cadena vacía.

3. Cuando se vuelcan cadenas que pueden tener comillas, se vuelcan entre los caracteres 0171 y 0187 (“«”, “»”) para saber dónde comienzan, dónde acaban, y evitar confusiones de comillas más habituales.

Ejemplos de los casos:

2.

logger.debug(“Se edita la subfamilia” & sSubfamilia)

Si no existe un punto al final de la frase, y sSubfamilia es una cadena vacía, entonces leerías “Se edita la subfamilia” y no sabes si hace referencia a la subfamilia de la que has hablado previamente, o a un valor que debería haber aparecido y no aparece.

3.

«Se ejecuta “SELECT * FROM t_Cosas WHERE sNombre=’” & sQueCosa & “‘”»

Y la verdad que llevo un tiempo haciendolo y hasta ahora me parecen unas pautas muy válidas.

Muchas gracias por su atención, y hasta la próxima.

March 8th, 2007 by admin