lunes, 28 de enero de 2013

Programa de cálculo de complejidad ciclomática

Artículo perteneciente a la sección de análisis estático de código 

Hola a todos,

Hace poco os expliqué como calcular la complejidad ciclomática y si recordais no era más que sumar el número de condicionales de nuestra función.

Pues bien, he hecho un programilla que precisamente hace eso, contar condicionales. Es muy sencillo y necesita muchas mejoras para realmente funcionar como debería pero es un buen inicio. Espero que os guste.




#include <stdio.h>
#include <stdlib.h>
#include <iostream>

int main(int argc, char *argv[])
{
FILE *fp;
long lSize;
char * buffer;
size_t result;
char *p, *p1, *p2;
int cont = 0;

fp = fopen("funcion.txt","rb");

if (fp == NULL) std::cout << "Falta fichero funcion.txt con el codigo a analizar" << std::endl;

//Obtenemos el tamaño del fichero
fseek (fp , 0 , SEEK_END);
lSize = ftell (fp);
rewind (fp);

// reservamos memoria para cargar el fichero
    buffer = (char*) malloc (sizeof(char)*lSize);
if (buffer == NULL) std::cout << "Falta memoria para cargar fichero" << std::endl;

// copy the file into the buffer:
    result = fread (buffer,1,lSize,fp);
if (result != lSize) std::cout << "Error en la lectura del fichero. Tamaño esperado : " << lSize << " Tamaño real: " << result <<std::endl;

p = (char *) memchr(buffer,'{',lSize);
while(1)
{
p1 = (char *) memchr(p,'i',lSize-(p-buffer) );

if (p1 == NULL) break;

if( ( *(p1-1) == ' ' ) || ( *(p1-1) == '\t' ) || ( *(p1-1) == '\n' ) )
if( *(p1+1) == 'f' )
{
if( ( *(p1+2) == ' ') || ( *(p1+2) == '(')  )
{
cont++;
}
}
p = p1+1;
}

p = (char *) memchr(buffer,'{',lSize);
while(1)
{
p1 = (char *) memchr(p,'c',lSize-(p-buffer) );

if (p1 == NULL) break;

if( ( *(p1-1) == ' ' ) || ( *(p1-1) == '\t' ) || ( *(p1-1) == '\n' ) )
if( *(p1+1) == 'a' )
if( *(p1+2) == 's' )
if( *(p1+3) == 'e' )
if( *(p1+4) == ' ' )
cont++;

p = p1+1;
}

std::cout << "Complejidad ciclomatica : " << cont << std::endl;

fclose(fp);
free (buffer);

system("pause");
return 0;
}


Nos vemos

LordPakusBlog

Analizador estático de código

Artículo relacionado con curso de programación
Artículo relacionado con referencias de programación
Artículo relacionado con la calidad del código

Hola a todos,

Este artículo no va a ser más que una unión de todos los artículos que haga sobre análisis estático de código. Espero que os guste.

Lista de links:

Programa sencillo para el cálculo de la complejidad ciclomática


LordPakusBlog

sábado, 26 de enero de 2013

Refactorización ( Refactoring)

Artículo perteneciente a la sección de calidad de código

Hola a todos,

Como supongo que ya habréis medio entendido en los últimos artículos (o tal vez ya lo sabíais anteriormente) el refactoring es el hecho de modificar la estructura interna del código sin cambiar ni su funcionalidad y su interficie de trabajo.  Es como si le hiciéramos la puesta a punto al coche, no modificamos su apariencia externa ni nos hace falta aprender nada nuevo para conducirlo, pero el producto (el coche) es de mejor calidad y más seguro.

Refactorizar no es más que la típica limpieza de código con unas cuantas normas que nos permitan tener el código estructurado y de acorde al resto del proyecto.

Cosas que NO se han de hacer al refactorizar:
- Refactorizar al final del proyecto: Este es el típico problema de la persona que no entiende bien el concepto de refactorizar. Refactoriza, si, pero no cuando debe. La refactorización se ha de realizar cada poco, al finalizar un módulo, al finalizar una función,etc... Si no, las posibilidades de introducir errores son enormes (aparte de que las ventajas de la refactorización no se pueden ver durante el desarrollo del proyecto).

- Refactorizar todo el código antiguo de golpe: Este también es un problema típico muy ligado con el anterior. Hemos aprendido las bondades de la refactorización y las queremos aplicar si o si a nuestros proyectos aunque tengamos un deuda técnica heredada de hace décadas  y lo queremos ya. Esto normalmente acaba en desastre. Si se quiere refactorizar código antiguo (que se debería) se ha de hacer poco a poco y con calma probando cada uno de los cambios minuciosamente

- Aumentar la complejidad para "mejorar" la mantenibilidad: Este problema es también muy usual, lo que por desgracia la persona que lo realiza lo tiene complicado para darse cuenta. Se basa en el concepto de reutilización de código al máximo nivel. Te encuentras con 20 funciones cortas y sencillas de funcionalidad parecida (pero no idéntica) y las unes todas en una sola función enorme y genérica que basa todo su funcionamiento en los parámetros que se le pasen. Normalmente estos "monstruos" acaban muriendo por su propio peso, pero de mientras nos pueden haber obligado a seguir una estructura de código para nada mantenible. Recordad, por encima de todo la complejidad ciclomática ha de ser baja.


Cosas que SI se deben hacer al refactorizar:
- Cambiar el nombre a las funciones y variables: Este es el gran olvidado o despreciado. Cuando se habla de refactorización todo el mundo piensa en el código, el algoritmo y la implementación pero descuida que los nombres usados para funciones y variables forman parte del código y son lo que en primera instancia nos permite entender el código. Una variable que se llame "a", o una función que se llame "Calculo" aunque no sean incorrectas, no nos aportan información , hecho fundamental para la comprensión del código.

- Mantener los comentarios: Si, los comentarios forman parte del código, y si, el proceso de refactorización también les afecta. Esto es importante tenerlo en cuenta por que mucha gente se olvida de ellos, refactoriza el código y deja los comentarios antiguos (o lo deja sin comentar por que "el código se ve muy claro"). Un código, por muy bueno que sea, necesita comentarios para facilitar la vida al que venga después.

- Eliminar variables y funciones que no se usen: Durante el proceso de refactorización hay ocasiones en que el código se simplifica de tal manera que hay funciones que se quedan "muertas". Son funciones correctas, pero que no son llamadas debido a que su funcionalidad se ha visto asumida por otra función. Por mucho que el código sea bueno, limpio,eficiente y correcto, si no se usa, es un estorbo en medio del código y se ha de eliminar. Tenéis que imaginaros que el código es el combustible de vuestro motor, cuando más combustible tengas más lejos llegarás, pero si llevas más combustible ( más peso) el rendimiento del motor y del combustible disminuirá.


Cosas que estaría bien hacer al refactorizar:
- Usar patrones de diseño: En muchas ocasiones (al menos a mi me pasa bastante) primero se programa y después nos damos cuenta que la estructura que hemos usado es muy parecida o quedaría mejor implementada mediante un patrón de diseño. Esto no quiere decir que todo el código tenga que ir con patrones de diseño, ni mucho menos, pero si se ven casos de manual, esta bien introducir el concepto de patrón para estandarizar código y facilitar el aprendizaje de código de terceras personas.

-Usar TDDanálisis estático de código: Lo pongo como opcional, pero realmente, hacer refactorización sin usar estas herramientas debería estar tipificado en el código penal como intento de suicidio :) . Si no tenemos algo donde agarranos mientras hacemos la refactorización se nos va ha hacer muy pesado mejorar el código con el agravante de que tal vez introduzcamos más problemas de los que arreglemos.

- Optimizar el rendimiento aunque no sea un requisito: Este punto es tremendamente opcional por que depende del proyecto en que se esté se deberá aplicar o no. La idea es sencilla, en el momento de trabajar en un proyecto es posible que no tengamos unos requisitos establecidos de memoria o velocidad, así que todo vale, pero tanto para los tiempos de prueba como para futuras funcionalidades es bastante recomendable que el código vaya siendo mejorado a nivel de optimización. Imaginemos que hacemos una función que compara strings de texto. No nos piden que se rápido por que solo se usará para comparar dos textos cortos. 2 años después, se nos pide comparar dos ficheros relativamente grandes, y como la funcionalidad de comparar cadenas de texto está más que probada se reaprovecha. 1 año después se decide que se tendrán que comparar dos librerías con centenares de ficheros y que se ha de hacer en tiempo real.... tenemos un problema no?  En resumen, un pequeño arreglo de velocidad en el momento de refactorizar nos puede permitir llegar o no a los requisitos de una futura implementación (y en todo caso siempre será más rápido y agradable probar la funcionalidad manualmente debido a que todo tardará menos)

Espero que os haya gustado y os haya servido

Nos vemos

P.D: Si os interesa el tema de la refactorización os recomendaria que conseguierais el libro de Martin Fowler (gurú de la calidad de código) que trata sobre el tema

LordPakusBlog

viernes, 25 de enero de 2013

Servidor de integración continua

Artículo perteneciente a la sección de calidad de código

Hola a todos,

Hace ya unos días que le hago hincapié al tema de la calidad del código, en parte por que me parece fundamental para llevar a buen puerto cualquier proyecto, en parte por que creo que es un tema donde los conceptos se entrelazan tanto que merece la pena explicarlo todo lo más seguido posible.

El servidor de integración tiene la funcionalidad de estar continuamente compilando los archivos del proyecto  y probandolos sin cesar, asegurando que si existe un fallo se encontrará cuanto antes sea posible. Esto significa que cada cierto tiempo nos enviará informes de en que situación está el proyecto y de que sería conveniente arreglar. En el fondo , cambia el paradigma típico de programación de diseño->programación->testeo final por el de : diseño->programación->testeo automático->refactoring->arreglo de bugs->testeo automático->........-> testeo final, permitiendo que el testeo final sea mucho más sencillo y fiable, aportándonos un software mucho más mantenible.

En uno de los últimos artículos os comentaba el tema de que os podíais montar vosotros mismo el servidor de integración, de hecho es una buena manera para reciclar hardware antiguo que ibais a tirar. Si quereis también podéis usar alguno de los múltiples softwares libres de integración que existen en la web: Jenkins, CruiseControl, Apache Ant, Apache Maven...hay muchas, si conocéis de alguna otra que creáis que puede estar bien compartir, hacedmelo llegar.

Ya para finalizar, solo deciros que por el hecho de estar "solo" en un pequeño proyecto personal no le tengáis miedo a usar un servidor de integración, solamente por probarlo ya vale la pena.

Espero que os haya gustado

Si el tema de la integración os ha picado siempre le podéis echar un ojo a los siguientes libros:


Nos vemos
LordPakusBlog

miércoles, 23 de enero de 2013

Herramientas de análisis estático de código

Artículo perteneciente a la sección de calidad de código
Artículo íntimamente relacionado con como mejorar la calidad del código

Hola a todos,

No hace mucho os comentaba el tema del análisis estático de código. Es decir, de utilizar programas que revisen por nosotros la estructura de código buscando posibles fallos medio-ocultos y zonas de código inmantenibles.

Depende del lenguaje que uséis tenéis más o menos opciones. En nuestro caso que casi siempre nos movemos dentro del ámbito de C/C++ tenemos dos opciones gratuitas muy claras:

Yasca : Es un analizador por linea de comandos que nos dará un report de los posibles fallos que tenemos en nuestro código. Es bastante completo y se le pueden añadir bastantes plugins para mejorar su funcionalidad.  Si queréis más información os lo podeis bajar y ejecutar yasca --help o bien ir probando que información os da con la siguiente linea de cmd:
                                   yasca       carpeta_con_codigo       -o    ficherodesalida.xml

cppcheck: Es un analizador un poco más complejo , con interficie gráfica que se complementa bastante bien con yasca. También se puede usar por linea de comandos y detecta errores que yasca no ve (y viceversa)

Si estas opciones se os quedan cortas, hay otras, seguramente mejores, pero son de pago (y no estamos hablando de software de 10 euros precisamente) así que prefiero no dar publicidad.

La gracia de estos dos softwares es que al poderse usar por linea de comandos se puede integrar con nuestras aplicaciones como nosotros queramos. Por ejemplo, ahora mismo podríamos ser capaces de tener un servidor svn con el código, del cual nos bajaríamos automáticamente el código , le pasaríamos las pruebas TDD que quisiéramos, le pasaríamos el análisis estático que nos gustase, lo compilariamos y finalmente podríamos enviar tanto el ejecutable final como el resultado de todas las pruebas por email para tener constancia de todo el proceso. Esto, señoras y señores, es un servidor de integración continua que nos permite mejorar la calidad de código hasta límites insospechados.


En fin, espero que os haya gustado y os haya servido

Nos vemos
LordPakusBlog

martes, 22 de enero de 2013

TDD: Test Driven Development

Artículo perteneciente a la sección de calidad de código
Este artículo es una especificación del artículo sobre como mejorar la calidad de código

Bibliografía recomendada para este tema:


Hola a todos,

Tal vez os suene, tal vez no, pero TDD es tal vez la metodología de trabajo más importante para conseguir una buena calidad de código. Sin ella, casi nada del resto de cosas que podamos hacer las podríamos hacer, al menos no de forma segura.  Si mejorar el código fuese hacer malabares sobre la cuerda floja encima de un monociclo con un mono que fuma en pipa encima del hombro (que en muchas ocasiones es lo que  acaba siendo :D ) TDD sería los arneses y  la red de seguridad.

La teoría es muy sencilla:
1. Escribimos los test que queremos que pase nuestro software (antes de escribir ni una sola linea de código!!!)
2. Implementamos un código lo más sencillo y corto posible (KISS) que cumpla con esos tests.
3. Probamos los test.
4. Si no se cumplen los tests volvemos al punto 2 y vamos reiterando hasta conseguir un ok de los test.
5. A medida que el código se va haciendo más grande implementamos test más complejos y estrictos para verificar correctamente el conjunto del sistema.
6. De vez en cuando refactorizamos el código y pasamos los tests para asegurarnos que todo sigue funcionando.

Largo pero sencillo no? Pues bien, este ciclo de trabajo es el que permite tener de forma regular código casi automantenido , dejándonos tiempo para implementar nuevas funcionalidades en vez de perder el tiempo parcheando código antiguo.

Si buscáis en la web hay muchas artículos como este que más o menos explican lo mismo y hablan de las bondades de las diferentes herramientas que se pueden usar para implementar TDD  (killrazor hizo hace un tiempo un artículo buenísimo sobre el tema), pero he encontrado a faltar ejemplos prácticos  para que la gente lo pueda entender. Espero que el siguiente ejemplo os sea de utilidad.


Vectores.cpp

void SumaVectores(int a[4],int b[4], int c[4])
{
     int i;
   
     for(i = 0 ; i < 4 ; ++i )  
     {
           a[i] = b[i] + c[i];
     }
}

void RestaVectores(int a[4],int b[4], int c[4])
{
     int i;
   
     for(i = 0 ; i < 4 ; ++i )  
     {
           a[i] = b[i] - c[i];
     }
}

void MultiplicaVectores(int a[4],int b[4], int c[4])
{
     int i;
   
     for(i = 0 ; i < 4 ; ++i )  
     {
           a[i] = b[i] * c[i];
     }
}


Vectores.h

void SumaVectores(int a[4],int b[4], int c[4]);
void RestaVectores(int a[4],int b[4], int c[4]);
void MultiplicaVectores(int a[4],int b[4], int c[4]);



main.cpp

#include "Vectores.h"
#include <iostream>

void main(void)
{
     int a[4] = {0,1,2,3};
     int b[4] = {0,0,0,0};
     int c[4] = {0,-1,0,-2};
   
     SumaVectores(a,b,c);
     MultiplicaVectores(b,a,c);
     RestaVectores(c,b,a);
   
     std::cout <<  "Resultado:" << c[0] << " " << c[1] << " " << c[2] << " " << c[3];
     system("pause");
}

Test.cpp
#include "Vectores.h"
#include <iostream>

FILE *fp;

void TEST_SumaVectores(void)
{
     int a[4] = {0,1,2,3};
     int b[4] = {0,1,2,3};
     int c[4] = {5,6,7,8};
     
     SumaVectores(a,b,c);
     
     if(a[0] != 5 || a[1] != 7 || a[2] != 9 || a[3] != 11)
             fprintf(fp,"TEST de suma de vectores incorrecta\n");
     
}


void TEST_RestaVectores(void)
{
     int a[4] = {0,1,2,3};
     int b[4] = {1,6,2,3};
     int c[4] = {5,4,7,2};
     
     RestaVectores(a,b,c);
     
     if(a[0] != -4 || a[1] != 2 || a[2] != -5 || a[3] != 1)
             fprintf(fp,"TEST de resta de vectores incorrecta\n");
     
}

void TEST_MultiplicaVectores(void)
{
     int a[4] = {0,1,2,3};
     int b[4] = {0,1,2,3};
     int c[4] = {5,0,7,2};
     
     MultiplicaVectores(a,b,c);
     
     if(a[0] != 0 || a[1] != 0 || a[2] != 14 || a[3] != 6)
             fprintf(fp,"TEST de multiplicación de vectores incorrecta\n");

     
}

void main(void)
{
     fp = fopen("Log.txt","w");
     
     fprintf(fp,"Iniciando test básicos de vectores\n");
     TEST_SumaVectores();
     TEST_RestaVectores();
     TEST_MultiplicaVectores();
     fprintf(fp,"Fin test básicos de vectores\n");
             
     fclose(fp);
}

compiler.bat
 echo OFF

echo *********Seteando variables del sistema para Visual Studio**********************
call "c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"

echo *******************************Compilando***************************************
cl /EHsc /c main.cpp
cl /EHsc /c Test.cpp
cl /EHsc /c Vectores.cpp

echo ******************************Ejecutando Tests Unitarios************************
link test.obj vectores.obj
call test.exe

echo ******************************Ejecutando****************************************
link main.obj vectores.obj
call main.exe

pause


Que hace todo esto?? Bueno, basicamente compilamos todos los archivos y hacemos dos linkados, uno con la versión buena, la que nos interesa y otro linkado con una versión de test cuya única funcionalidad es asegurar que todo funciona correctamente. Si encuentra errores lo pone en un log.txt.

Podréis observar que las pruebas son muy sencillas, normalmente las pruebas serían bastante más exhaustivas y con más niveles de complejidad, pero tal como está nos permitiría poder refactorizar las funciones de cálculo e implementarlas en ensamblador por ejemplo sin demasiados riesgos para el funcionamiento global.

En próximos capítulos iremos complicando cada vez un poquito más el tema para que veáis hasta donde se puede llegar.

Espero que os haya gustado

Nos vemos


LordPakusBlog


lunes, 21 de enero de 2013

Compilar y linkar varios archivos por linea de comandos




Hola a todos,

Hace poco publiqué un par de artículos (este y este otro) que hablaban sobre compilar un .cpp desde linea de comandos.

Hoy toca como se pueden compilar más ficheros y unirlos para generar un .exe

Lo único que hemos de hacer es decirle al compilador que no genere ningún .exe  para luego poder llamar al linkador para que nos una los .obj. en un solo ejecutable.

Lo veréis mejor con un ejemplo:

prueba.cpp
#include <iostream>

#include "OtroArchivo.h"

int main()
{
    std::cout << "Esto es una prueba de compiler de dos archivos" << std::endl;

FuncionDeOtroArchivo();

    return 0;
}

OtroArchivo.h
void FuncionDeOtroArchivo(void);


OtroArchivo.cpp
#include <iostream>

void FuncionDeOtroArchivo(void)
{
    std::cout << "Esto es la funcion del otro archivo" << std::endl;
}

compiler.bat

echo *********Seteando variables del sistema para Visual Studio**********************
call "c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"


echo *******************************Compilando***************************************
cl /EHsc /c codesvn\prueba.cpp
cl /EHsc /c codesvn\OtroArchivo.cpp
link prueba.obj OtroArchivo.obj


echo ******************************Ejecutando****************************************
call prueba.exe
pause


Si os fijáis respecto a los otros ejemplos lo único que hemos hecho es decirle al compilador (cl) la opción /c (para que no genere el .exe) y luego hemos usado el comando link para linkar los .obj


Para que me sirve todo esto?
Por ahora para aprender :D, ya que es verdad que tiene relativa poca aplicación práctica, pero es la base para poder montar nuestro propio IDE de desarrollo, nuestro propio servidor de compilación, nuestro propio sistema de compilación distribuida , etc...

Espero que os haya gustado y que os animéis a probarlo.

Nos vemos

LordPakusBlog




domingo, 20 de enero de 2013

Como mejorar la calidad del código

Artículo perteneciente a la sección de calidad del código
Artículo intimamente ligado al artículo   ¿que es la calidad del código?


Hola a todos,

Si habeís seguido los post de la sección de calidad de código ya teneís claro que es la calidad de código, como evaluarla  y por que es necesario mejorarla, pero.. como la mejoramos??

Este es un tema que se ha tratado en infinidad de ocasiones tanto por empresas como por particulares y grupos de software libre. El tiempo que tenemos para dedicar a un proyecto es limitado (ya sea por que forma parte de nuestro tiempo libre o por que conforma nuestra jornada laboral) y por lo tanto un recurso valioso a optimizar. Si estamos en una empresa cada hora de trabajo es dinero,  si programamos por ocio cada hora de dedicación que nos falta es una posibilidad de frustrarnos y abandonar el proyecto. Así que, está claro que a todos nos interesa.

Metodologías para mejorar la calidad del código:

- TDD: Test Driven Development (Desarrollo guiado por test), o lo que es lo mismo, primero hacer los tests y luego hacer programas que cumplan con esos test. Parece una tontería y una perdida de tiempo pero realmente lo que te permite es programar más tranquilo sabiendo que esos tests en cualquier momento te dirán si lo estás haciendo bien o no. Elimina en gran parte el problema de tocar una función que afecte a otras. Ya haré otro artículo para hablar de TDD más en detalle.

- Integración continua: Esto es la madre del cordero. Un servidor de integración continua (también llamado servidor de compilación) es un servidor que se encarga de bajarse el código del svn , compilarlo y aplicarle test. Los test básicos que aplicará será los que habremos definido en TDD, que serán sencillos y en segundos nos podrá dar un resultado pero también puede aplicar test más largos (por las noches por ejemplo) que aseguren estabilidad o casuísticas raras y complejas. Con esto gran parte de las pruebas que se tienen que hacer al software se harán automáticamente, pero no al final del desarrollo, sino en todo momento, descubriendo los fallos mucho antes.


- Análisis estáticoEl análisis estático es más o menos lo que es explique cuando os comenté que era la calidad del código. No son más que consejos y buenas prácticas de programación que nos permiten mecanizar la búsqueda de fallos en el código. Nos permiten dar una visión objetiva al código y se pueden ejecutar junto con los test de TDD en el servidor de integración continua.

- Refactorización: La refactorización del código no es más que limpiar el código, es decir, cambiar su estructura sin cambiar su funcionalidad. Este es un proceso peligroso (de ahí la necesidad de los test de TDD) pero necesario para la mantenibilidad. Le hemos de perder el miedo o la vagancia a tocar el código. Por mucho que el código funcione, si el análisis estático (por ejemplo) nos dice que tendremos muchos problemas de mantenibilidad hemos de invertir tiempo en mejorar el código, ya que si no, cuando menos nos demos cuenta todo el castillo se nos habrá caido encima.


- Programación por parejas:   Esta es otra cosa que parece una perdida de tiempo, pero que realmente va bastante bien, ya que cuando uno programa el otro revisa, y cuando a un problema no se le ve solución fácil, la otra persona puede aportar ideas en las que no habíamos ni caído  Adicionalmente ayuda mucho a la formación.  Obviamente si estás solo en casa es más complicado... :D

- Revisión de código: Está muy emparentado con la programación por parejas y los test. Sencillamente significa que una persona que no ha tocado el código se lo lea y diga su opinión. El svn de google , por ejemplo, permite hacer revisiones de código encima de lo que hay subido, permitiendo que la comunidad revise lo que se está haciendo.

- Plazos de entrega: Si estás trabajando para una empresa tranquilo que ya te darán plazos de entrega :D, si programas por ocio es muy recomendable que te marques tiempos de entrega propios (sin estresarte), en que puedas enseñarte a ti mismo y  a la comunidad lo que llevas hecho hasta el momento. Sobretodo, que funcione. Nada de cosas a medias. Mejor que no esté hecho,  a que esté casi hecho.

- No al "multitasking": Tanto en la vida profesional como en la del ocio es muy normal tener 84 cosas en la cabeza. Bien. Está más que demostrado que una persona puede hacer "bien" 2 cosas a la vez, no te pidas más. Si piensas en el motor de audio, gráfico, fisicas, IA y XML todo a la vez y vas saltando de un código a otro cada 5 minutos no acabarás nada, pero además lo que generes será basura. Es mejor centrarte en un tema (como mucho darle vueltas a otro de mientras) y ya está. Que por temas personales no puedes? No pasa nada, no lo hagas. Haz cosas más sencillas, diseña tests o dale vueltas a como diseñar el achilipú cuántico que te hará falta para tu juego, pero no programes con demasiadas cosas en la cabeza.

Espero que os haya gustado. Si se os ocurren más maneras de mejorar el código no dudeis en hacermelo saber.

Bibliografía recomendada para este artículo:


Nos vemos
LordPakusBlog

Complejidad ciclomática

Artículo perteneciente a la sección de calidad del código
Artículo íntimamente relacionado con : Que es la calidad de código?



Hola a todos,
Como supongo que habréis visto ya llevo unos cuantos posts relacionados con temas de mantenibilidad y calidad del código. La herramienta más utilizada (y a mi parecer fiable) para medir la mantenibilidad y calidad de un código es la complejidad ciclomática.

Definición:

La complejidad ciclomática es un concepto que se inventó Thomas McCabe en 1976 que se basa en contar el número de caminos independientes que hay un trozo de código. Cuantos más caminos, mas testeos se tienen que hacer para asegurar que funciona correctamente y más posibilidades hay que el lector de código se confunda. Esta medida tiene la gracia que es totalmente objetiva y por lo tanto puede realizarla un ordenador de forma repetitiva, no depende de la experiencia del programador ni de los gustos de la persona que hace la revisión de código.

Por si alguien todavía tiene dudas ya se han realizado unos cuantos estudios que demuestran que la complejidad ciclomática está íntimamente relacionada con el número de errores y la facilidad para detectarlos y resolverlos.  Con esto no estamos diciendo que un código con un alto valor de complejidad sea "malo", "ineficiente" o que no cumpla con los requisitos pedidos, sencillamente estamos diciendo que con un alto nivel de probabilidad ese código va a ser inmantenible.


Cuantificación de la calidad:

Ya sabemos que una complejidad alta es mala... pero... que significa alta? 10, 20, 100??
Depende de la experiencia, del tipo de producto, de las veces que se va a tocar a posteriori o del nivel de fiabilidad que se desee. Normalmente se establecen un conjunto de tramos para clasificar los programas.

Complejidad     Clasificación
1-10                Programa simple. Fácil de mantener
11-20              Programa medio. Algo más caro para mantener.
21-50              Programa complicado. El coste de mantenimiento puede ser muy elevado. Es                         recomendable refactorizar el código para bajarlo por debajo de 20.
50+                 Programa horrible. Borralo todo y vuelve a empezar. En serio, saldrás ganando dinero.


Como se calcula la complejidad?
La forma más fácil de calcular la complejidad ciclomática (es solo una aproximación, pero bastante buena) es sumar el número de condiciones del programa y el número de returns de la función. En el fondo es una medida muy próxima al número de caminos diferentes que tendrá nuestro software.


Ya para finalizar , para muestra un botón, no se si os acordareis de mi proyecto inicial LPGameEngine, pues bien, en su momento lo dejé medio abandonado por que me quitaba mucho tiempo implementar nuevas características. Ahora ya he visto que uno de los problemas que tenía es que la complejidad ciclomática se me disparaba (aparte de defectos en el diseño). A ver si puedo montarme una plataforma de desarrollo que me permita que el código sea más mantenible y me puedo volver a poner con el tema. Os mantendré informados.

Espero que os haya gustado

Si quereís profundizar un poco más sobre el tema de la complejidad ciclomática y del software en general tal vez os interese echarle un ojo a alguno de estos libros:

Nos vemos

LordPakusBlog


sábado, 19 de enero de 2013

Aportación de Mara Jade: Las 3R de la informática

Artículo perteneciente a la sección de Otros

Hola a todos,

MaraJade, una lectora del blog (supongo que con ese nombre es lectora :D ), me ha enviado un post que tenía preparado de hacia tiempo para que se lo publique.

El tema es bastante interesante , espero que os guste:

"

Cada dia se compran innumerables equipos electrónicos nuevos. Cada semana aparecen nuevos modelos, cada mes nuevas tecnologías y cada año nuevas tendencias.

Pero, ¿que pasa con todo aquel material electrónico que desechamos por que tenemos uno mejor? Al ser productos altamente tóxicos gran parte de los países industrializados lo envían a países del 2do y 3er mundo (como China y gran parte de África) donde se acumula en forma de basura electrónica, contaminante y sin ninguna solución a la vista.

Después de leer esto....¿¿Te has/han comprado nuevo hardware y no sabes que puedes hacer con el viejo?? Aquí tienes unos consejos.

Basándose en la regla de las 3 R, el hardware debería poderse Reducìr, Reutilizar y Reciclar. En el caso concreto del hardware hay más de uno que propone que sea la regla de las 4R donde la cuarta sea Reparar, pero no será tema de este artículo.

a) Reducción :
La industria del software y hardware actual instigan al consumidor a comprar más y más productos: nuevos teléfonos, ordenadores, sistemas operativos, etc. Esta espiral de consumo ya hace años que va en aumentando siendo la obsolescencia programada su principal caballo de batalla.

La única manera de combatir a este consumo desmedido es usar el sentido común, comprando productos que realmente necesitemos y alargando la vida útil de estos al máximo posible intentando optar por la reparación antes que por la nueva adquisición de dispositivos más modernos. También resulta adecuado optar por la minimización de los componentes para evitar los residuos grandes y poco gestionables.

b) Reutilización :
La reutilización se basa en que bien una misma persona o bien una tercera puedan sacarle provecho al hardware antiguo adaptando las prestaciones a las necesidades del momento.

Es muy normal que después de un cierto tiempo el ordenador se nos haya quedado “lento” y lo cambiemos. Ese ordenador viejo, normalmente aún funcionará solamente que más lento o con menos prestaciones que la flamante nueva adquisición. ¿Que podemos hacer?
  • Cambiar de utilidad: Un PC desfasado puede ser un servidor la mar de bueno.

  • Reaprovechar las piezas: En vez de tirar a la basura dos ordenadores “malos” podemos juntarlos para tener un ordenador “medio” y piezas de recambio para este, reduciendo así los residuos.
  • Dónalos: Hay muchas asociaciones juveniles, escuelas y ONGs que estarán más que contentas de recibir tus ordenadores antiguos. El hecho de que no les puedas dar utilidad de ninguna manera no significa que no haya otras personas que puedan usarlos.

c) Reciclaje :
El reciclaje de los equipos informáticos es un tema espinoso ya que por un lado es un proceso muy tóxico (no solamente en la industria encargada del reciclaje sino en todo el proceso de recolección de los residuos), pero a la vez es un negocio muy lucrativo ya que en la industria electrónica se usan gran cantidad de metales preciosos como el oro, la plata o el platino (se usan en los conectores de los procesadores debido a su gran conductividad y ductilidad).
Dicho esto, si la única salida que le queda a tu equipo viejo es el reciclaje tendrías que hacerlo de la mejor manera posible:
  • Acudiendo a un punto limpio. La mayoria de las ciudades medianas y grandes tienen uno y estos tienen como obligación recoger la basura electrónica. Si quieres saber donde puedes dirigirte puedes mirar el siguiente link

  • Acudiendo al fabricante. Desde hace unos años la legislación obliga a que las empresas de hardware se hagan responsables de todo el ciclo de vida del producto y esto conlleva que se hagan responsables del reciclado. No obstante, en ningún lugar se especifica que este servicio deba ser gratuito, así que informaos bien antes de pedir que el fabricante se quede tu producto viejo.
"

A mi me ha gustado, espero que a vosotros también. Si tenéis algún curso,tutorial o artículo que me querías enviar no dudéis en hacerlo.

Nos vemos

Que es la calidad del código?

Artículo perteneciente a la sección de calidad del código

Hola a todos,

Que es la calidad del código?

La calidad del código es aquello que hace que un proyecto sea viable mantenerlo o no.

Un proyecto sin calidad de código puede funcionar correctamente, realizar su cometido y hasta ser extremadamente eficiente realizando su funcionalidad, pero con el paso de los años nadie podrá entender ese código y se tendrá que reescribir ya que nadie será capaz de mantenerlo (ni tan siquiera su mismo creador).

No es objetivo de este post explicar como mejorar la calidad de nuestro código sino saber de donde viene los problemas. En otro post ya explicaré como se puede mejorar la calidad de forma drástica.


Formas más usuales de perder calidad de código:

- Variables o funciones sin comentarios:
Para ir bien, todas, absolutamente todas las variables y funciones deberían estar comentadas (ni que sean 3 palabras) ya que sin esa referencia de para que sirve cada cosa es complicado empezar a entender el código. Junto con los comentarios de código existen dos sub-factores más:
       - Código del cual no se mantienen los comentarios: A veces se modifica el comportamiento de una función y una variable y nos olvidamos de cambiar el comentario, haciendo que desde ese momento sea incorrecto y contraproducente para el mantenimiento.
      - Mala nomenclatura de variables y funciones: Tan importante como los comentarios son los nombres que les damos a las variables y funciones. Da igual que nomenclatura uses siempre y cuando sea siempre la misma.

- Variables o funciones definidas pero sin usar: Otra cosa que pasa en muchas ocasiones es que desarrollamos código que al final no se usará. Motivos por los que esto pasa hay muchos, pero eso no es el problema. El problema está en que da "miedo" borrar código antiguo, aunque no se use. Cuando una tercera persona tiene que leer el código se puede volver loco para saber que funciones o variables realmente se están utilizando y cuales no, empeorando la mantenibilidad.

- Variables con un scope muy superior al mínimo necesario: Pasa también bastante que por un motivo o por otro acabamos utilizando variables globales solamente en una sola función. De por si no es malo pero puede llegar a dar problemas de mantenibilidad al hacer copypaste por ejemplo.

- "Hardcodeos" de valores: En bastante códigos podreis ver seteos de variables con un valor fijo o hacer comparaciones con un valor estático  Esto no está mal de por si pero es bastante más recomendable utilizar define's o algún otro método para no tener valores hardcodeados. Si no, un cambio en estos valores puede volverse un pequeño infierno para buscar de donde venía y a donde iba.

- Usar indirecciones con más de 2 ordenes de separación (punteros triples, quadruples, etc... ). Usar más punteros y más complejos no hace que el código sea mejor. Hay ocasiones en que es necesario usar punteros sextuples (por decir algo), pero que sea necesario para el funcionamiento no significa que sea bueno para la calidad del código. Mi consejo es que si hace falta cambiéis de algoritmo pero nunca uséis más de dos niveles de indirección ya que eso imposible de seguir luego en el código.

- Código duplicado: Esta es la estrella  del espectáculo. Todos lo hemos hecho. Siendo novatos o más expertos y todos tenemos la certeza que en algún momento del futuro lo volveremos ha hacer. El copypaste es malo, muy malo y cuando nos hemos dado cuenta ya tenemos 100 bloques de 5 lineas que se podrían parametrizar en una función haciendo que todo el conjunto ocupase 10 lineas.. pero no lo hacemos por pereza. Esto se debe de evitar, ya que aunque los trozos de código normalmente son bastante sencillos se ha de intentar tener ni una sola linea de código de más de lo estrictamente necesario.

- Usar GOTO: Por suerte esta práctica está casi erradicada pero en los años 80-90 aún era habitual que los programadores usaran GOTO de forma usual. No nos engañemos, os pongan la excusa que os pongan, no hay ninguna justificación para usar el GOTO, por lo tanto intentad evitarlo. Pensad que es una instrucción que de por si viene cargada directamente por el diablo (cualquier fallo tonto nos puede enviar la ejecución de código a ves a saber donde)

- Funciones con demasiado código: Todos estaremos de acuerdo que las funciones más largas son las más complicadas de entender (normalmente). El problema es que es complicado marcar un límite a partir del cual se tiene que dejar de aceptar un código como bueno. He leido en más de un sitio que las funciones no deberían ocupar más de 200 lineas, yo soy bastante más estricto y creo que más de 20 o 30 es un error. A fin de cuentas, es un criterio personal, solamente sed consecuentes y estableceos un máximo de lineas que realmente os permitan entender el código como dios manda.

- Módulos con demasiadas funciones: De la misma manera que con el código, un archivo con demasiadas funciones no es demasiado legible. Cuantas? Depende. Yo nuevamente soy de la opinión de un máximo de 20 funciones por archivo, aunque es un tema que reside en vuestra capacidad de análisis de código, así que lo dejo a vuestra discreción (id probando hasta que veais que realmente podeis entender el código rápidamente)

- Demasiados bucles anidados: En bastantes ocasiones el código se lía  bastante. Y los bucles comienzan a anidarse uno encima de otro hasta que tenemos auténticos monstruos donde es imposible seguir la ejecución. En gran parte de las veces los bucles se pueden separar en funciones especificas o bien se puede replantear el algoritmo inicial.

- Complejidad ciclomática alta: La complejidad ciclomática es un tema tan extenso que permitiría hacer un articulo solo para el y aún me quedaría corto. A modo de resumen solo deciros que es una medida de cuan enrevesado es el código. Una complejidad ciclomática alta es sinónimo de código immantenible y de necesitar un altísimo número de test para verificar que el funcionamiento del código es correcto. En posteriores artículos hablaré más sobre el tema.

- Ausencia de test automáticos y revisiones de código: Si programas solo es muy normal que nadie te revise el código, pero ni que sea ese tu caso utilizar tests automáticos que te prueben unos mínimos a tu aplicación siempre te irán bien. Si no, tienes la posibilidad que los errores se te vayan acumulando y que los veas cuando ya sea demasiado tarde.

- Abuso innecesario de patrones de diseño: Este error es muy divertido por que afecta a gente que lleva años prorgamando más que a los novatos como tal. Cuando alguien que tiene experiencia en programación descubre lo que són los patrones de diseño, alucina. Le ve un potencial impresionante y se enfrasca a usar patrones de diseño para todo. Normalmente este situación acaba en un código ortopédico de mucha "belleza visual" pero poca utilidad práctica y además con unos tiempo s de producción horribles. Esto no quiere decir que los patrones de diseño sean malo, ni mucho menos. Son extremadamente útiles, pero se han de usar en la justa medida.

- No seguir la filosofía KISS : Se que esto parece muy dogmático, pero realmente, si no se sigue el principio KISS es bastante complicado que en un proyecto grande se consiga el código mantenible. Para más información mirad el artículo que hice en su momento sobre KISS.

- Demasiada deuda técnica: Si trabajamos con código antiguo, tocado por muchas manos o sencillamente al que se le ha dado más importancia a la velocidad de producción que a la calidad de esta, tenemos un problema. Para más información mirad el artículo sobre deuda técnica.

- Falta de objetividad en la evaluación de la propia calidad del código: De todas las cosas que he explicado esta es casi la única que es inevitable. El código es sangre de nuestra sangre y casi siempre le veremos con buenos ojos. Es por ello que es muy necesario automatizar el testeo de todas las características anteriormente citadas para que de una forma objetiva podamos analizar el código y decidir si estamos mejorandolo o no. Sin esto, es imposible que se pueda mejorar el código de nuestro proyecto.



Finalmente, si veis que en vuestros proyectos pasan demasiadas de las cosas que hay en esta lista: TRANQUILOS,QUE NO PANICO EL CUNDA!! :D. Hay maneras de solucionar estos problemas de manera automática que ya os iré posteando.

Espero que os haya gustado

Si os gusta el tema siempre le podéis echar un ojo a alguno de estos libros:

Nos vemos

P.D : Si creéis que falta algo poned un comentario explicándolo.
LordPakusBlog

viernes, 18 de enero de 2013

Compilar archivos bajados del svn mediante bat



Hola a todos,

Hay ocasiones en que nos puede interesar compilar desde un servidor o un ordenador de apoyo mientras nosotros trabajamos en nuestro PC.

Para ello la solución es montar un bat que al ejecutarse descargue el código del svn (servidor de código) y lo compile automáticamente.

Aquí os dejo un ejemplo sencillo de como implementarlo. Solo tenéis que copiarlo en un archivo que se llame por ejemplo compiler.bat y ejecutarlo.

Espero que os guste




echo OFF

echo **********************Descargando código del svn********************************
svn checkout http://lpgameengine.googlecode.com/svn/branches codesvn

echo *********Seteando variables del sistema para Visual Studio**********************
call "c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"

echo *******************************Compilando***************************************
cl /EHsc codesvn\pruebasvn.cpp

echo ******************************Ejecutando****************************************
call pruebasvn.exe
pause



En próximos capítulos hablaremos del tema de hacer lo mismo pero con proyectos más grandes y de forma automática.

Nos vemos

LordPakusBlog

El principio KISS

 Artículo perteneciente a la sección de calidad del código 

Hola a todos,

Hay una cosa muy curiosa entre los programadores y es que cuando aprenden algo nuevo se dedican a sobreutilizarlo hasta la saciedad, nunca mejor dicho.

Es muy típico que cuando un programador  de Java o C++  aprende lo que son las clases y la herencia lo usen para todo, incluso para que lo que no es necesario. Así pues , es bastante normal leer código de alguien novatín que tenga cosas del estilo de tener una clase Ferrari que hereda de la clase deportivo que hereda de la clase coche que hereda de la clase vehículo que hereda de la clase movil que hereda de la clase objeto que hereda de la clase...etc etc etc.  Esto no quiere decir que el uso de clase y de herencia sea malo, ni muchísimo menos, pero que hemos de usar la tecnologia en la justa medida de las necesidades de nuestro proyecto.

No es más mantenible un código cuantas más clases tiene, ni cuanta más abstracción soporta, un código es mantenible, cuando es corto, sencillo y fácil de entender y testear (a ser posible mediante tests automáticos). En esto se basa la filosofía KISS.

La palabra KISS es un acrónimo inglés que tiene dos acepciones:
 - Keep It Simple, Stupid! : Mantenlo sencillo, persona de pocas luces :D
 - Keep It Short and Simple : Mantenlo corto y sencillo.

KISS , como algunos piensan, no es una excusa para trabajar menos, o trabajar peor. Muy al contrario, en muchas ocasiones cuesta más hacer un código sencillo y corto que no un código largo y liado. El objetivo principal de esta filosofia es la mantenibilidad del código y por tanto, disminuir los costes de mantenimiento y ampliación del proyecto.

Como programo siguiendo la filosofia KISS??? Sencillo, ponte en la piel de un niño de 10 años. Lee el código.
Lo puedes entender??   Perfecto, otras personas que no sean tu, lo podrán entender.
No puedes entenderlo???  Vaya, aquí tenemos (o tendremos) un problema

La idea es hacerlo todo sencillo y claro sin miedo al futuro o a tener que tocar código después  Una de las excusas principales para no implementar KISS es: "Si lo hago todo  sencillo le faltarán funcionalidades futuras que seguro que harán falta y entonces será un embrollo volver a tocar código para implementarlo".  Las personas que dan esta excusa acaban comprendiendo más tarde o más temprano que si solo programan lo mínimo imprescindible para cumplir con la funcionalidad deseada obtienen un código funcional, sencillo y testeable, mientras que de la otra forma obtienen un código más difícil de testear, seguramente más ineficiente y con el añadido que gran parte de sus lineas de código no harán más que molestar ya que no se podrán haber testeado al no formar parte de los requisitos de la aplicación.

Conclusión, programar de una manera diferente a KISS es llevar a cuestas una gran bolsa con "porsiacasos" que cuando llega el momento de la verdad lo más seguro es que se tengan que volver a codificar ya que no cumplirán exactamente con los requisitos que se pidan en ese momento (si es que se llegan a pedir)


Espero que os haya gustado

Nos vemos
LordPakusBlog

jueves, 17 de enero de 2013

Compilar con visual studio por linea de comandos



Hola a todos,

Para una idea que tengo entre manos me hace falta poder compilar (con el compilador de visual studio) desde la linea de comandos y he pensado en haceros llegar el como hacerlo ya que a más de uno le puede interesar.

1. Antes que nada tendréis que tener instalado el visual studio (existe versión xpress gratuita).
2. Cread un carpeta donde tendréis el código y donde se generarán los resultados. (yo le he llamado prueba, la podeis poner y llamar como querais)
3. Dentro de esta carpeta cread un fichero que se llame prueba.cpp con el siguiente código:


#include <iostream>

int main()
{
    std::cout << "Esto es una prueba de compiler por linea de comandos" << std::endl;
    return 0;
}

4. Dentro de la misma carpeta cread otro fichero que se llame compiler.bat y que tenga lo siguiente:

echo OFF

echo *********Seteando variables del sistema para Visual Studio**********************
call "c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"

echo *******************************Compilando***************************************
cl /EHsc prueba.cpp

echo ******************************Ejecutando****************************************
call prueba.exe
pause

5. Guardad los ficheros y dadle dobleclick encima del icono de compiler.bat. Si todo ha ido bien se debería haber generado un prueba.obj, un prueba.exe y tendría que haber saltado la ejecución del prueba.exe

NOTA:
La llamada a vcvarsall.bat no sirve más que para setear variables de sistema que le hacen falta al compilador.
cl es el compilador de VC
/EHsc son los flags de compilación: en próximos capitulos explicaremos más flags.

Espero que os sirva y que os haya gustado.

Nos vemos

LordPakusBlog

miércoles, 16 de enero de 2013

Que es la deuda técnica ?

Artículo perteneciente a la sección de calidad del código

Hola a todos,

Hoy toca explicar un concepto bastante curioso del mundo de la programación. La deuda técnica. Si habéis seguido los tutoriales del  blog seguramente ya habréis programado en pequeños proyectos y os habréis encontrado con fallos que os han hecho perder mucho tiempo en resolverlos. A medida que los proyectos son más grandes estos fallos y cuellos de botella se hacen cada vez peores, de más difícil solución y lo que es peor, es más complicado detectarlos.

En los años 60 aparecieron los primeros casos de deuda técnica pero no fue hasta 1992 que  Ward Cunningham le acuñó nombre. La deuda técnica no es más que hacer las cosas mal, no tiene más explicación.La deuda técnica no es sino una forma de llamar a la situación en la que se decide programar rápido y mal para llegar a una fecha de entrega sin pensar en que eso después puede acarrear muchos problemas (a veces sencillamente puede ser falta de motivación o falta de capacidad para elaborar una solución mejor, depende de los casos.)

Los síntomas más claros de que nuestro proyecto tiene deuda técnica son:
- Complejidad en la programación
- Cuando alguien tiene que aprender como funciona, cada vez cuesta más.
- Es más complicado añadir funcionalidades al código (de hecho, hay cosas que es imposible implementar)
- Es más complicado encontrar los bugs y en muchas ocasiones la resolución de bugs comporta nuevos bugs.
- Un análisis a fondo del código demuestra que la modularidad del código es peor de la imaginada y que es muy posible que una nueva implementación de funcionalidades implique un fallo en cascada de todo el sistema.


No obstante, no todo es malo, y aunque tengamos proyectos con deuda técnica, todo se puede salvar.
Los pasos para salvar el proyecto son:
1. Dejar de incluir código "malo": Es decir, tenemos código podrido en el proyecto, ok , asumamoslo  pero no por ello incluyamos más código destructivo.
2. No se ha de hacer un gran refactoring. Es decir, intentar cambiar todo el proyecto a un nuevo enfoque para eliminar toda la deuda que tengamos de una sola tacada normalmente tiene solo un resultado: la muerte del proyecto. Así murió el navegador Netscape, por si no os lo creeis.
3. Incluir auto-tests en el código. El desarrollo de código mediante TDD ayuda, sino es TDD, tests de compilación y/o funcionamiento, algo que permita asegurar que el hecho de tocar un trozo de código no nos destruye el funcionamiento del resto del producto.
4. Paciencia. Mucha paciencia. Cuando pides un préstamo al banco, tienes una deuda. Y la tienes que pagar mes a mes durante muchos años. Con la deuda técnica pasa lo mismo. Se ha de ir "limpiando" el código pernicioso poco a poco, asegurándonos que no rompemos el funcionamiento del proyecto y usando métricas que nos permitan verificar que realmente estamos mejorando la calidad del código.

Si detectas que estás en una situación de deuda técnica y que ninguno de estos pasos ayuda, plantéate seriamente cancelar el proyecto o reiniciarlo aprovechando la experiencia del error cometido. A veces es mejor empezar desde 0 cuando llevas el 20% del proyecto realizado que no cuando llevas el 95% hecho.

En próximos artículos iré ahondando más sobre este tema.

Espero que os haya gustado.

Si este artículo os ha sabido a poco y quereis aprender un poco más sobre el legacy code y la deuda ténica tal vez podeis echarle un ojo a alguno de estos libros:

Nos vemos

LordPakusBlog

martes, 15 de enero de 2013

SEO: Como conseguir más tráfico web (II)

Hola a todos,

Hace ya un tiempo di cuatro reglas sobre como se podía mejorar el tráfico web en vuestro blog.(si queréis repasarlo tenéis un link aqui)

Y funcionan, al menos a mi, poco a poco me va aumentando el tráfico.

Si habéis seguido los puntos del primer capítulo solo tenéis que tener paciencia y esperar a que suban las visitas, no obstante, siempre podéis ayudar un poco a aumentar las visitas mediante los directorios. . Hay unas pocas normas básicas a seguir para no salir perjudicados con el tema directorios:

- Huid de lo fácil. La mayoría de los directorios viven de la publicidad así que se basan en intercambio de links. Tu das un link ellos te dan otro, ambos salen ganando, pero, tenéis  que ir a los directorios que pidan un mínimo de calidad. Si el directorio automáticamente ya os coloca en sus listas, sin haber ningún proceso de selección, no sugiráis vuestra url. Os interesa un mínimo de calidad sino queréis que los buscadores os penalizen.

- No paguéis. Un poco ligado con el anterior, hay muchos directorios que por un "módico" precio os incluyen en sus listas u os dan más peso, negaos a ello. Si los buscadores detectan que ese directorio se basa en la compra de links os penalizarán.

- Fijaos en que los enlaces de ese directorio sean do-follow. Hay muchas veces que los directorios ponen sus links como no-follow de forma que no os dan prácticamente tráfico pero os piden que los vuestros si que lo sean, con lo que saldréis perdiendo.

- Fijaos que en la categoría en la que os apuntéis no haya ya demasiados links. Es preferible apuntaros en una categoría un poco más rara de lo normal pero que haya menos links salientes que no poneros en una clasificación más "normal".

- No es obligado, pero siempre que podáis intentar que el directorio de enlaces permita enviar noticias y links a vuestros posts, ya que esto es lo que os podrá generar gran cantidad de tráfico.

Sin más os dejo con una lista de directorios que al menos a mi me funcionan:

Directorios de intercambio de links:
Directorio Webs / Blog  Directorio webs Directorio Web Gratis | Directorio web España 






http://www.boostersite.es


Directorios de envio de noticias:
tutoriales gratis


Ya vereís que con paciencia y trabajo ireis subiendo de visitas, los directorios solo os ayudarán un poco a sacarle más rendimiento a vuestros posts.

Espero que os haya gustado, nos vemos

lunes, 7 de enero de 2013

Historia de los sistemas operativos


Hola a todos,
Aquí os dejo una lista del timeline de los sistema operativos más importantes que han habido desde los inicios.

Si creéis que me dejo alguno decidmelo y lo incluiré

Nos vemos

Año
Sistema operativo
1956
SO para IBM 704. Secuencial.
1964
Inicio del desarrollo de Multics
1969
Se crea UNICS
1970
UNICS pasa a llamarse UNIX
1974
Aparece el CP/M
1977
Aparece el BSD
1980
Aparece el QDOS
1981
Aparece el MS-DOS
1982
Aparece QNX
1983
Aparece el Lisa OS y se inicia el proyecto GNU
1984
Aparece el Mac OS
1989
Aparece NeXTSTEP
1991
Aparece el kernel de Linux
1992
Aparece Windows 3.1 y Solaris
1995
Aparece Windows 95
1996
Comienza el proyecto ReactOS
1997
Aparece Symbian
1998
Aparece Windows 98 y KDE
1999
Se publica GNOME
2000
Aparecen Windows 2000 y Windows Me
2001
Aparece Windows XP
2002
Aparece Mac OS X
2003
Aparece Windows Mobile
2006
Aparece Windows Vista
2007
Aparece Android
2008
Aparece el iOS
2009
Aparece Windows 7
2012
Aparece Windows 8
Related Posts Plugin for WordPress, Blogger...