Las bases de datos como problema.

Por la casa de una tia, rondaba 'Don pepe' quien era conocido en la colonia por ser bueno en los trabajos de albañileria que realizaba. Cuando alguien de la colonia necesitaba algo, el estaba ahi para construir una pared, poner piso, pintar, etc. Un buen dia, mi tia necesitaba un trabajo de instalacion de tuberia de gas, por lo que le pregunto a Don pepe si el podia instalarlo. Don pepe, supo con toda honestidad que no podia hacerlo, ya que nunca lo habia hecho y no aseguraba la calidad del trabajo. En momento la tia se sintio frustrada, por que tendria que llamar a alguien que no era de confianza, despues, sin embargo, penso que era lo mejor ya que si don pepe le hacia una mala instalacion, esta podia causar algo grave.

Esta entrada, la escribo un tanto con un tinte de pedrada, ya que tengo la fortuna de conocer de bases de datos y que implica usar una, asi como utilizarlas de la manera mas optima posible, o al menos lo que mi intelecto o google me permitan. Pero cuando alguien llega y me dice "Usar bases de datos es mas lento que usar archivos", me pongo a discutir de que en realidad no es el uso de base de datos lo que es lento, si no el como se utilicen. Sin embargo, en esta ocasion tomo la otra perspectiva y describo las bases de datos como problema.

El problema: el desarrollador de BD

Las bases de datos, a pesar de que son una solucion completa para el manejo de datos y de informacion tienen sus problemas, problemas que si no son bien manejados se vuelve un problema mayor que si se hubiera hecho de otra manera (archivos, por ejemplo).

El problema con las bases de datos, es la sobreestimacion que les tenemos; vemos a la base de datos como una solucion informatica, que nos va a solucionar nuestra vida en cuestion de organizacion de informacion - El equivalente a creer que un armario o closet haria mas ordenado nuestro cuarto. Por supuesto que nos hacen la vida mas facil si las sabemos utilizar.

Los principales inconvenientes

- Inconvenientes en la Administracion del sistema de BD. Cuando se crea una base de datos es necesario que exista la administracion del RDBMS, si esta no existe, por lo general la base de datos se satura de tal medida que el rendimiento de la misma (o incluso de la maquina en la que este la bd) puede caer. Para esto hay herramientas de administracion que hacen mas facil (a veces) la administracion de la BD. Los principales problemas que vienen con una mala administracion de la base de datos son:

• Baja del rendimiento del equipo: Cuando no se administra de manera correcta puede que el rendimiento se caiga por los suelos, tareas como limpieza de datos innecesarios, optimizacion y reparacion de tablas, son necesarias para que todo funcione lo mejor posible.
• Seguridad: Si no existe la administracion, mucho menos la administracion de la seguridad. Que pasa cuando un usuario puede ver los datos aunque no tenga permiso? esto obvio nos genera problemas.

- Inconvenientes en el Desarrollo de la BD. Este es el mayor inconveniente de la BD. Cuando es creada una base de datos, siempre se piensa que es lo que se necesita a nivel funcional, como solucionar los problemas urgentes, pero no se le dedica un momento a la Ingenieria de la base de datos, lo cual nos puede traer los siguientes problemas:

• Inconsistencia de datos: Diferencias en tipos de datos y como se almacenan.
• Duplicidad de datos: Datos duplicados o que pueden ser generados.
• Dificultades para acceso a información: Cuando se usa en exceso la generalizacion y segregacion de informacion, con lo cual es complejo obtener la informacion.
• Concurrencia: Que pasa cuando 2 datos son usados al mismo tiempo.

Entonces, Cuando no usar bases de datos?

Se recomienda no usar bases de datos en los siguientes casos:

• Cuando los datos que se usan son pocos: No tiene caso usar una base de datos, si solo se van a guardar textos cortos. Lo mejor es manejarlo con archivos.
• Si los datos nunca cambian.
• Cuando se necesitan datos en tiempo real: Tiempo real significa tiempo real! Es raro cuando se necesita una aplicacion en tiempo real, pero cuando se requiere, pues habra que darle la vuelta. Un sistema ERP, aunque se pudiera pensar que se necesita en tiempo real, no lo es, rapido: Si, tiempo real: No.
• Cuando no se cuente con el presupuesto: Por lo general se necesita, tanto software como hardware especial para tener buen rendimiento en una base de datos. Hay opciones libres y ligeras, como mysql. Sin embargo, si la base de datos es muy grande, se necesita una buena memoria y un buen procesador. Los servidores de hosting que proveen mysql generalmente son mas caros que uno que solo hostea archivos.
• Cuando no se cuenta con el conocimiento especifico: Cada BD tiene sus detalles y funciona de diferente manera, aunque sigan estandares como SQL, por lo que es necesaria la capacitacion. Y gerentes, entiendan: No es un capricho, es necesario! Desafortunadamente en las escuelas no hay la capacitacion necesaria para todos los RBDMS existentes, y cada uno tiene sus bemoles.
• No se cuenta con el costo para administrarla.

Como conclusión, puedo comentar que las bases de datos pueden ser un problema, cuando estas no se saben manejar, que sucede mucho. Cuando para ti, las bases de datos sean un problema busca soluciones; Pocas seran tan optimas y tan faciles como un DB, sin embargo las hay.

Saludos!

Malas Practicas en el desarrollo de sistemas

El problema con los árbitros es que conocen las reglas, pero no conocen el juego
Roberto Fontanarrosa.

El desarrollo de sistemas es algo bastante divertido, te enfrentas con problemas tan comunes y tan triviales, o a veces tan complicados y difíciles de resolver, que terminas volviéndote un tanto loco.

Como en todo, hay ciertas cosas que sabemos que se tienen que hacer, pero que por alguna u otra razón decidimos no hacer. Lo malo es que en estas decisiones nos llevamos entre las patas a algún pobre inocente, el cual, cuando le toca hacer su labor, termina sufriendo por que simples reglas no se siguen.

Estos son algunos errores comunes contra los que me he enfrentado.

1.- Inventar el hilo negro.

El hilo negro: Dícese de una hebra delgada, larga y de color negro, que se utiliza para coser. El hilo negro es una tecnología tan ancestral pero tan poderosa, que aun se utiliza en los trajes, vestidos, camisas, etc. El hilo negro es tan común y tan usado, que es difícil imaginar la vida sin su existencia.

¿Y que tiene que ver con el desarrollo?

Bueno, el hilo negro en realidad es un Mexicanismo, entiendase como una frase común de la cultura Mexicana. Decimos y hablamos del hilo negro como un artilugio muy viejo con lo que tenemos que hacer cosas novedosas.

En la programación pasa algo similar, generalmente nos enfrentamos con el problema de hacer cosas nuevas y de vanguardia, para lo que necesitamos técnicas, tecnología y herramientas no tan nuevas (como el hilo negro), por ejemplo un sistema de venta en linea, en el que utilizamos una base de datos. Tal vez la idea novedosa sea la tienda en línea, pero un sistema que almacene información en bases de datos no lo es tanto, y mucho menos lo que esto implica, consultas, operaciones, cálculos, etc.

Hay dos maneras de hacer esto, comenzando de cero (inventando el hilo negro) o consiguiendo hilo negro, el mismo que ha sido inventado, probado, depurado y lo mejor de todo, alguien ya sabe que hacer en caso de que algo no funcione. Para casi todos los lenguajes y entornos de desarrollo hay repositorios de clases o librerías las cuales nos ayudan a hacer tareas repetitivas y comunes: clases que hacen el manejo de bases de datos, sanitizacion de datos, validación de información, reporteadores, generadores de gráficas, efectos visuales, etc.

La mejor medicina para no inventar el hilo negro es la experiencia y el conocimiento de tu lenguaje.

2.- No pensar en el mañana.

¿Alguno vio volver al futuro? Bueno, una de mis escenas favoritas es cuando Marty y el doc se toman una foto en 1885 en el reloj del ayuntamiento. Este reloj se vuelve un icono de la ciudad y aparece en los años venideros y en la revoltura temporal de la trilogia.

Bueno, hay una realidad un problema con el desarrollo de sistemas: No van a durar tanto como un reloj en el ayuntamiento. Sin embargo debemos de pensar en el futuro de un sistema.

Me parece increible como todavia se utilizan sistemas que tienen tantos años como mi Madre, sobretodo en el ambito financiero o de correduria de bolsa. Son sistemas que se hicieron pensando en que durarian muchos años con vida.

Tal parece que actualmente no nos preocupamos por el ciclo de vida del software y muchas veces pareciera que nos preocupamos mas por sacar el proyecto o sistema a tiempo, mas que por hacerlo funcional y duradero, siendo que le podemos sacar mas provecho a un trabajo hecho a conciencia y bien cimentado, lo cual nos permitiria reducir costos de mantenimiento (muchas veces estos sobrepasan el costo del proyecto original).

Usabilidad, portabilidad, estandarizacion, modulizacion, etc., son un ejemplo de guias basicas que hay que seguir. Si tu haces un sistema que sea facil de usar, que sea ligero y se ejecute en la mayor parte de las plataformas, en el que implementes estandares de uso o de desarrollo, o en el que agregar modulos sea tan facil y menos doloroso, te garantizo que a futuro alguien te lo agradecera, ya sea quien lo usa o quien lo modifica.

3.- Programo luego pienso.

¿Cuantas veces te han dicho que dices las cosas sin pensarlas? En lo que a mi respecta me lo dicen cada lunes, martes, jueves y sabado. Digo cosas tales que despues de decirlas me quedo como 'oh oh' y despues viene el homeristico 'Douh' y despues me gustaria tener una maquina del tiempo para no decirlas.

Bueno, en lo que respecta al desarrollo, muchas veces nos dicen que tenemos que hacer algo, y sin siquiera pensarlo ya estamos codificando.

La codificacion debería de ser el 3er paso (claro según la metodología en cascada, la mas común):

• Análisis
• Diseño
• Codificacion
• Pruebas
• Mantenimiento

Muchas veces omitimos los dos primeros pasos y nos sentamos directamente a codificar, siendo que en ningún momento nos dimos a la tarea de analizar el problema o diseñar algoritmos para resolver los problemas.

Uno de los principales inconvenientes de esto, es que terminamos saltando u obviando problemas que pudieron haber surgido y resuelto en la etapa de diseño, y terminamos re haciendo trabajo. Otro inconveniente pudiera ser que terminamos haciendo sistemas poco mantenibles y mal hechos que después nos cuesta mas hacerle una corrección (nos lleva al punto anterior)

4.- ¿Y la documentación apá?

- Mijo, algun dia todo esto sera suyo
- Y la cheyenne apa

Cuando comencé a trabajar en esto del desarrollo, comence como un pragramador mas o menos idealista, que debia de documentar todo lo que hacía, pero me tope con una limitante: El tiempo vs la documentacion. Era una pelea a 9 rounds, las cuales las ganó el tiempo. Entonces me limite a programar sin documentar.

Cuando entré a una nueva empresa, lo primero que dije fue "Por que no hay nada documentado" y recordé al pequeño programador idealista, que no documentó su trabajo.

Creo que se sintió igual de frustrado el niño de la cheyenne, por que no pudo tener la herramienta que le haría mas fácil su trabajo. Así como yo no tuve la mía: La documentación.

La documentación es un caso particular en el desarrollo de sistemas, todos los que nos dedicamos a esto sabemos que hay que hacerlo, pero no lo hacemos. Muchas veces por que nos topamos con el mismo detalle, el tiempo. No nos damos el tiempo para documentar el trabajo. Esta es una malísima practica de desarrollo, y no para nosotros, si no para la persona que le damos resultados, por que el día que no estemos, alguien va a extrañar la documentación.

Para combatir esto, necesitamos mucha paciencia, y necesitamos educar a nuestros clientes (internos o externos), compañeros de trabajo o superiores, que es algo necesario. Algún día todo eso sera suyo y no sabemos que vaya a pasar, o si alguien se lleve información en su cabeza, si alguien no entienda lo que hicimos o alguna otra situación que tenga que ver con falta de información.

Hay que darnos el tiempo para documentar, hay que hacer incapie en este detalle. Si claro, toma tiempo y esfuerzo, pero paga a largo plazo, es una excelente inversión de tiempo.

5.- El lenguaje incorrecto en el momento incorrecto.

Si vas a china, habla chino. Me imagino llendo a china y tratando de preguntar donde esta el baño, creo que seria algo complejo para encontrar un simple sanitario.

En el desarrollo de sistemas, existen varios lenguajes, varios estilos de programacion y cada uno es mejor para algo, tiene un desempeño superior o es mas simple de trabajar bajo alguna condicion.

El caso tipico en aplicaciones para internet es el ya famoso asp vs php. Cada uno tiene sus pros y sus contras. Por ejemplo:

Es mejor utilizar asp en ambientes windows.
Php es mas rapido usando archivos bajo unix.
Asp tiene mejor integracion con SQL server.
Php se desempeña mejor con mysql.
Asp tiene muchos productos.
Php tiene mayor numero de soporte de usuarios.
Etc

¿Con que voy a esto?

Cuando tengas que hacer un desarrollo de sistemas, tienes que tener el suficiente conocimiento de que es lo que vas a hacer para tomar la mejor decision y hacerlo con la mejor herramienta. Un sistema puede ser una hoja de calculo en excel o una macro en word. No necesitas herramientas complicadas que despues sea un proyecto insostenible.

Un ejemplo es un sistema 'checador' (entradas y salidas). En donde trabajo alguien hizo un sistema de checador en php, muy bueno funcionaba genial, codigo de barras, reportes, facil y sencillo. Pero se le olvido que era un servidor con salida a internet. Despues de algun tiempo, algun vivales, se dio cuenta que podia checar desde casita sabiendo la ip del servidor, algo que una persona comun no sabe, pero sí, si es una persona que tenga conocimientos intermedios de informatica.

En este caso una solucion muy buena hubiera sido un sistema en visual basic, con una base de datos en access. No hubiera tomado mucho tiempo, hubiera sido facil de desarrollar y sin los problemas de tener el sistema publico en internet.

Hay que saber que vamos a hacer, y no querer hacer un sistema en Java cuando una hoja de calculo de excel pueda hacer lo mismo. Mucho depende claro esta de la persona que nos pide el trabajo, pero hay que saber aconsejar y darle asesoria para que no metan las cuatro patas y tu hayas sido complice del delito.

Mapas mentales.

Y ¿que esperabas?, ¿Qué en google earth apareciera un letrerote diciéndote donde esta el muelle de San Blas?
Conejo Mendoza.

Recuerdo una ocasión que íbamos a una fiesta de quince años de una prima. Íbamos tarde y para acabar con la paciencia de mi padre, un señor puntual y estrictamente correcto, no llevábamos ningún mapa y nadie conocía donde seria este evento social. Mi madre en ese momento dijo “ese tiene cara de gorrón, síganlo”. Efectivamente era un gorrón que iba al mismo evento social. Llegamos sin la ayuda de ningún mapa.

Este caso fue un golpe de suerte (o de instinto de gorron, tal vez), el que nos permitió llegar a la fiesta, no tan tarde y sin dar tantas vueltas.

Mapas mentales.

En muchas ocasiones no puedes recurrir a la suerte, ¿a que me refiero? Tu no puedes llegar con un cliente o con tu jefe a decirle que es lo que vas a hacer, sin tener una idea clara de que es lo que vas a realizar.

Un mapa es un documento que representa de manera grafica un area real o imaginaria. Veo a un mapa como una receta escrita de diferente manera, un tanto más grafica y más entendible, la cual nos permite llegar a nuestro objetivo de la manera más rápida y fácil.

¿Qué pasa entonces cuando quiero hacer una representación grafica de una serie de ideas? Pareciera que no es tarea para representar en un mapa. Pero lo es.

Mapa mental o conceptual es una técnica usada para la representación gráfica del conocimiento . Un mapa conceptual es una red de conceptos. En la red, los nodos representan los conceptos, y los enlaces las relaciones entre los conceptos en forma de flechas etiquetadas.

Cuando hay que ordenar una serie de ideas que tenemos en la cabeza, lo mejor que podemos hacer es dibujar estas ideas. Cuando eramos niños, nos gustaba dibujar, ya fuera una pared, un papel, un cuaderno, o hasta el mejor abrigo de papa. Es algo que todos aprendimos (bien o mal) cuando eramos niños.

El concepto de los mapas mentales, nace en la época de los romanos, en donde se pueden encontrar diagramas sobre temas en los que se plasmaban ideas filosóficas.

No es sino hasta alrededor de 1960 que el Dr. Allan Collins desarrolla un estudio sobre los mapas mentales, sobre como funcionaba el cerebro humano al crear ideas y como el uso de herramientas graficas podía ayudar a unir la parte grafica del cerebro con la parte lógica logrando así una mejor retención.[ref]

Creando un mapa mental.

En un mapa mental, se trata de representar una idea principal, ideas secundarias y como estas se conectan, facilitando asi el proceso creativo. La idea principal, como su nombre lo indica, es la que regira toda la idea, por ejemplo: Evitar la contaminación. Esta es una idea principal la cual nos da ideas sobre como lograr este objetivo. Esta idea, genera mas ideas, claro esta, ideas que apoyen o refuercen el argumento principal.

Fig. 2. Idea principal.

Una idea secundaria puede tener diferentes ramificaciones y estas a su vez pueden tener ramificaciones. Un ejemplo de ideas secundarias pueden ser: “Reducir Contaminantes” u otra pudiera ser “Reciclando para evitar desperdicios” Estas pueden tener miles de ramificaciones hasta que no exista ya ninguna idea subsecuente.

Fig. 3. Idea principal e ideas secundarias.

Este proceso nos sirve, ya que no se descarta ninguna idea y todo queda en un grafico que puede ser fácilmente entendido después.

Fig. 4. Ejemplo de mapa mental con iconografia de apoyo.

Mapas mentales en el desarrollo.

Los mapas mentales son una herramienta para generar ideas, ordenar ideas y nos sirve también para representar el verdadero despapaye que pasa en nuestra cabeza.

El desarrollo no solo es nuestro despapaye, por lo general es un proceso colaborativo el cual es un despapaye de 3, 5, incluso equipos de 40 o 50 personas. Un diagrama que nos ayude a poner en claro nuestras ideas es de mucha ayuda.

Generalmente este tipo de diagramas en el desarrollo son utilizados cuando se esta generando una idea, es decir, en la primera etapa del proyecto, cuando estamos recabando información sobre que se quiere hacer, que tareas se deben de tomar en cuenta o incluso para mostrar a tu cliente que es lo que se esta planteado hacer, o viceversa, cuando un cliente quiere explicarte que es lo que se necesita.

Pongamos el ejemplo para desarrollar un Portal de automóviles (mmm, algo trillado).

Nuestra idea principal: Automóviles.

A esta idea habrá que agregarle ideas de lo que puede hacer nuestro portal de automóviles:

Venta de automóviles.
Venta de seguros para automóviles.
Información de automóviles.

Y a cada una de estas ideas se le agregan ideas e ideas e ideas. Resultando algo asi:

Fig. 4. Ejemplo de mapa mental de portal de autos.

Un mapa mental no es muy útil cuando se quiere utilizar para modelar objetos, algoritmos, bases de datos etc. Para estos es mejor utilizar los modelos ya conocidos. Hay que recordar que cada uno de los diferentes estilos de diagramación son aptos para lo que fueron creados, no debemos de inventar ni mezclar estilos de diagramacion, ya que estan pensados con fines completamente diferentes.

Conclusión.

Si tienes un desorden de ideas en tu cabeza y quieres ordenarlas para hacer algo claro: usa un mapa mental, te ayudara en el proceso creativo, no en el tecnico.

Bug tracking.

Antes que otra cosa he de afirmar que Errar es de humanos, y desde que el hombre es racional, por ahí del 12.000 antes de cristo, el humano se ha equivocado tantas veces, que hemos aprendido hasta hace poco que estos errores nos pueden ayudar a evolucionar. De esto se trata este tema, de evolucionar.

Cuando estas en esto del desarrollo comienzas a darte cuenta de cuales son las cosas por las que te gusta y las que no te gusta pasar. En mi caso, siendo una persona un poquito ordenada (poquito en realidad), me gusta llegar temprano a mi trabajo, salirme a mi hora y que me dejen tomarme mi café a media mañana. Dentro de las que no me gustan están que me asignen mas trabajo del que puedo hacer (un mal de la clase proletariada), que me digan que ‘necesito dar mas’ (refiriendose a que quieren que me quede mas tiempo de a gratis sin pagarme horas extras) o que me digan ‘eso no esta funcionando como debe y ya se lo habia comentado a sutanito’, bien, a este ultimo ‘esto no esta funcionando’ se le llama Bug o error informatico, y al hecho que se lo hayan dicho a sutanito (quien por cierto no tiene nada que ver con el desarrollo del sistema) se le llama falla de comunicación (mas adelante explico como resolver esto).

Bugs

Es un rollo esto de los errores informáticos (o bugs) y es un tema tan largo, pero tan interesante que pudiera hacer un ensayo sobre los errores informáticos, la historia de los errores, los más famosos, los más costosos, los mas chistosos, etc. Lo voy a resumir un tanto:

“Un bug o error informático es el resultado de un fallo o deficiencia durante el proceso de creación de programas de ordenador o computadora (software). Dicho fallo puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y programación”

Foto del origen de la leyenda acerca del primer "bug" informático conocido

Entonces bien, El parrafo anterior (tomado de güikipedia) nos dice que un error no es más que una falla o falta de orden a la hora de estar desarrollando un programa. ¿Por qué cometemos estos errores? Puede ser una larga lista, por lo general se incluyen:

- Falta de comunicación.
- Descuido de parte del desarrollador.
- Falta de claridad en la funcionalidad de algo.
- Falta de información de objetivos.
- Carga de trabajo

No podemos hacer nada para evitarlos, vamos a cometer tantos errores, como humanamente posible podamos. El como evitarlos, es harina de otro costal, y como diria la abuela chole: “esa, es otra historia”. Lo que si podemos hacer, es aprender de ellos y mantener una estabilidad de nuestros sistemas.

Bugtracking.

Dicese de hacer un sistema en una base de datos, en donde se puedan registrar, revisar, reportear, o analizar bugs (o errores informaticos) lo que permita hacer un mantenimiento ordenado a un sistema. La güikipedia lo define asi:

“Un sistema de seguimiento de errores es una aplicación informática diseñada para asistir a los programadores y otras personas involucradas en el desarrollo y uso de sistemas informáticos en el seguimiento de los defectos de software”

Estoy actualmente en un equipo de desarrollo el cual estoy conformando (por cierto, si sabes programar en php y eres jalisquillo, contactame) y una de las herramientas que creo que nos pudiera facilitar la vida es un sistema bug tracking, para darle un poco de mas orden a este frankenstein y por lo menos tener un conocimiento claro de que es lo que se esta haciendo y como se está haciendo.

Un buen sistema de tracking de bugs deberia arrojar, minimo la siguiente información:
- Fecha reportada
- Severidad
- Comportamiento incorrecto
- Detalles de como reproducirlo
- Persona que lo dio de alta
- Quien le da seguimiento.

Con estos dato pudieramos tener un minimo de información con lo que pudieramos resolver un error, ya que nos ayudaria al menos a identificarlo (nota: muchas veces el problema es identificar el error, pero no quiere decir que el error sea facil de corregir)

¿Por qué es importante?

Una vez en un banner de una pagina de Internet lei: “Knowdelege is power, want more power?”. No recuerdo que vendian, pero lo que me quedo claro y por siempre grabado es que el conocimiento es poder.

Si tu tienes la información de por que estan sucediendo los errores, puedes tomar decisiones de manera mas acertada.

Por ejemplo, hablemos de un desarrollador a y uno b, el desarrollador a escribe 500 lineas de codigo, en las cuales hace 10 funciones. De esas 500 lines de codigo, tiene alrededor de 10 bugs reportados. 500 / 10 = 50. De una manera muy burda pudieramos decir que programador a tiene una efectividad de 50. Programador B programa menos, digamos 100 lineas pero de esas 100, solo tiene 1 error, digamos que tiene efectividad de 100. Con lo cual pudieramos pedirle a programador A que ponga mas atención. Obviamente este ejemplo es muy burdo y no toma en cuenta otros factores como complejidad de la programación, complejidad de funciones, etc. Pero este dato ya nos pudiera hacer pensar en revisar mas el codigo de A, etc.

En conclusión, mientras el hombre siga programando, va a seguir habiendo errores de programación, lo que uno tiene que buscar es en identificar el por que, lo que nos ayudaria bastante a mejorar.

Espero que este articulo les sea de interes, y de algo les sirva.

Les paso unas urls de sistemas que permiten hacer esto. Obvio después veran el xc bug tracking system.

Saludos!

La primera!

Bueno, este flamante, radiante y nuevecito blog que comienza su servidor, lo hago con mucho entusiasmo. La verdad que me tarde con esto del blog, ¿Por qué? No lo sé en realidad. Creo que fueron muchos factores, el cambio de trabajo el cargador de la lap, la falta de administración del tiempo, en fin. Pero estoy comenzando a hacer varios avances en cuanto a eso.

A este blog le puse dsrollo, por que se trata de ese rollo del desarrollo. Soy un egresado de la licenciatura de Sistemas de información y me encuentro trabajando en ese rollo del desarrollo web. Siempre me ha gustado el Internet y le veo un amplísimo potencial, desde una pagina informativa sobre algún tema, hasta un portal de publicidad de autos seminuevos.

Comienzo a entender que es lo que me gusta hacer y que es lo que no me gusta hacer. Esto después de haber tomado experiencia en varios ambitos y habiendo forjado una experiencia mas o menos considerable.

Bueno, este es un pequeño editorial a este blog el cual espero de dejar algo para un pobre tipo como yo que no tenga ni la más mínima idea de que es este rollo y que aprenda por mis errores.