Programación ++

Documentación interna de Codigo: Imprescindible.

2008-11-29T11:47:00.005+01:00

Buenas,

hacia tiempo que no actualizaba mi blog pero ya era hora!!

En el dia dia de la dura programación y despues de saber que el titulo que te ha costado 5 años conseguir tiene el mismo valor que un cuadro del Ikea, solo que firmado por el Rey, te encuentras con esto en un codigo que estás modificando:

/* Modificacion 20-Agosto-2004. Compruebo fecha de carga del nombre del

fichero contra el rango de fechas de vigencia de TABLA_1.

En caso de salirse del intervalo, hago como si el fichero no hubiera existido jamas.

Nota del programata: Este programa es una mierda, por mussshos parches que pongamos,

la estructura no vale pa ná, pdta: este programa me tiene frito,

mañana seguram tenga que cambiar alguna otra cosa...

Bueno, ahora es junio 2005, un año despues llega la nueva version, a ver que pasa...

jeje, soy yo otra vez, pero en abril del 2006, veo que el codigo sigue igual de retorcido.

Este comentario no tiene fin alguno, pero no veas lo que relaja. */

Con estas cosas normal que Zapatero nos quite el titulo, bueno... y lo bien que no lo pasamos!!!

Java Struts: Capa Vista - Creacción de un ActionForms

2008-02-28T16:52:00.004+01:00

nPasos para la creación de un ActionForms:

nLa clase ActionForms es Abstracta -> Creación de una subclase para obtener los datos del formulario.

nDentro de la subclase se debe definir un atributo por cada campo que se desea capturar del formulario HTML.

nAl enviar el formulario se crea una instancia de LoginForm y se completa a partir de los parámetro de petición. El marco Strut lo realiza haciendo coincidr cada nombre de parámetro de petición con el nombre de atributo de la subclase ActionForm:

package com.tutorial.struts.forms;
import javax.servlet.http.HttpServletRequest;
import org.apache.struts.action.*;
/**
* Bean de formulario para que el usuario se valide.
**/
public class LoginForm extends ActionForm
{
private String password = null;
private String email = null;
public void setEmail(String email)
{
this.email = email;
}

public String getEmail()
{
return (this.email);
}

public String getPassword()
{
return (this.password);
}

public void setPassword(String password)
{
this.password = password;
}

Java: Modelo Vista Controlador en Struts ( MVC )

2008-02-22T14:09:00.008+01:00

Una aplicación basada en Struts, tiene un componente básico llamado ActionServlet. Este es un servlet, que tramita las peticiones de los clientes delegando a un componente definido por el usuario por cada petición.

Este Servlet es el punto central del framework, aunque no es necesario que todas la actividad fluya a través de él. En una aplicación basada en Struts se pueden hacer peticiones a una JSP que contengan o no “tag libraries” de Struts, sin pasar por el Servlet ActionServlet.

El ActionServlet (controlador) de Struts captura y encamina las peticiones HTTP que llegan a la aplicación (toma la decisión de a dónde enviar la petición HTTP), a otros componentes de aplicación. Estos componentes pueden ser páginas JSP o instancias de una subclase de la clase org.apache.struts.action.Action que el propio framework suministra.

Cuando se inicia el Servlet ActionServlet, carga y analiza la información de un fichero que contiene la configuración de la aplicación para aplicar las características de Struts. Entre otras cosas, el fichero de configuración define las correspondencias que existen entre las peticiones HTTP que captura el Servlet controlador y las acciones que van a tratar esa petición.

Estas correspondencias son manipuladas como instancias de la clase org.apache.struts.action.ActionMapping

Backup en Oracle.

2008-02-09T18:34:00.000+01:00

El comando para invocar la utilidad para exportación de datos se debe lanzar desde la línea de comandos del sistema operativo. El comando es exp.
La sentencia es:

exp / buffer= 1048576 full= yes file= export.dmp log= export.log

Se exportará toda la información de un determinado usuario sobre un archivo de sistema
operativo (export.dmp), el cual se creará en el directorio desde el cual se esté lanzando el
comando. Para ello, se utiliza un buffer de 1 Mb.
Todas las secuencias se almacenan en un archivo histórico con el fin de visualizar al final
la operación, si todo ha terminado correctamente (export.log).
Uno de los métodos más cómodos para lanzar la operación de exportación es el comando
siguiente:

exp / parafile= parametro.txt

En el archivo parámetro.txt sería donde introduciríamos los parámetros de exportación. Con
este método, se podría realizar varios estándares de exportación de datos, creando varios
archivos de parámetros según el caso.

Parámetros de Exportación
Estos parámetros se pueden incluir en la misma línea de comandos del ejecutable de expor-
tación o dentro de un archivo de parámetros determinado (PARFILE):

BUFFER: Especifica, en bytes, el tamaño del buffer asignado para los accesos a los registros de un objeto.

COMPRESS: Este parámetro está indicado para el tratamiento de las cláusulas de almacenamiento de los objetos. Con el valor de COMPRESS= YES, la exportación calculará el espacio ocupado por cada uno de los objetos accedidos para que, con una importación posterior, todo este espacio ocupado por la información del objeto se agrupe en una única extensión.

CONSISTENT: Tiene la función de mantener la consistencia en la exportación de datos, en el caso de que éstos puedan ser modificados mientras la exportación se está llevando a cabo. Debe tener el valor CONSISTENT= YES.

CONSTRAINTS: Sirve para indicar el proceso que también exporte las constraints de las tablas.

DIRECT: Este parámetro indica el modo en el que se va a realizar la exportación de datos, convencional o directa.

FEEDBACK: Este parámetro sirve, básicamente, para realizar un seguimiento del número de filas que se van exportando.

FILE: Sirve para especificar el nombre del archivo binario donde la utilidad va a ir almacenando los datos exportados. La extensión por defecto es DMP, aunque se podría especificar otra extensión.

FULL: cuando está en yes, sirve para exportar toda la información de una base de datos.

GRANTS: Cuando está en yes, se exportará los permisos de los objetos en relación.

8. Procesamiento Paralelo en Oracle (III). Cómo se usa:

2008-01-30T23:57:00.000+01:00

En las sentencias CREATE/ALTER, puede indicarse el grado de paralelismo de sentencias DML con la cláusula PARALLEL (DEGREE d, INSTANCES i), siendo d e i números enteros positivos:

DEGREE:el número de CPUs

INSTANCES: nodos de base de datos distribuida

El número ideal de procesos esclavos paralelos que trabajan sobre una sentencia viene determinado por los siguientes factores:

Los valores DEGREE e INSTANCES, especificados en la cláusula PARALLEL o en el hint

El número de CPUs de la máquina y de instancias

El número de particiones a ser accedidas

El mínimo valor del parámetro FREELISTS (listas de transacciones libres) en la cláusula STORAGE de entre todos los índices globales a ser actualizados.

El número real de procesos está limitado por la disponibilidad de las instancias, y el mínimo se calcula a partir del parámetro PARALLEL_MIN_PERCENT. Las consultas se paralelizan cuando hay un hint en la sentencia SELECT o se ha especificado la cláusula PARALLEL para la tabla.

Cuando se acceden a varias tablas, se elige de todas ellas el hint o valores PARALLEL que definan un mayor grado de paralelismo, como referencia para el grado total de paralelismo de la consulta. El uso del paralelismo es fácil. Sin embargo, existen ciertas restricciones en su uso.

El soporte de las restricciones es limitado: si alguna se viola, la sentencia se ejecuta en serial (no da error).

7. Procesamiento Paralelo en Oracle (II). Operaciones que soportan Paralelismo

2008-01-29T00:19:00.000+01:00

Existe un alto grado de afinidad entre el paralelismo y el particionamiento en Oracle, pues se usa el mapeo partición-dispositivo. Este es un nuevo beneficio de las tablas particionadas.

Consulta paralela: soporta paralelismo dentro de una partición, pero se puede usar también en tablas no particionadas.

Nuevas opciones, paralelizadas por partición (no hay paralelismo dentro de cada partición):

INSERT... SELECT... con carga directa sobre tablas particionadas.
DELETE sobre tablas particionadas.
UPDATE sobre tablas particionadas.
INSERT... SELECT... con carga directa sobre tablas no particionadas.

Las operaciones paralelas siempre tienen un proceso maestro que coordina los procesos esclavos. El tipo de operación determina cuándo y cómo se paraleliza la operación. Existen tres métodos de paralelización:

Por rangos de rowid (sólo consultas paralelas): Se aplica a consultas de tablas particionadasy no particionadas. Proporciona paralelismo dentro de una partición: variosprocesos esclavos pueden estar accediendo a una partición

Por procesos esclavos (INSERT en tablas no particionadas): Se aplica sólo enROWID, las filas se distribuyen entre los procesos paralelos que insertan en sendos segmentos temporales. Posteriormente, se asigna a cada fila de los segmentos temporales un rowid, y se mueven a la tabla destino tras la HWM. Ejemplo:
INSERT...SELECT... sobre tablas no particionadas. Como las nuevas filas no tienen

INSERT /*+PARALLEL(TABLA1,3)*/ INTO TABLA2 SELECT * FROM TABLA1;

Por partición (sólo tablas particionadas): No hay paralelismo dentro de una partición para operaciones DML. Un proceso esclavo puede ser asignado a más de una partición para compartir recursos. Ejemplo, suponiendo que la tabla “pedido” está particionada:

UPDATE /*+PARALLEL(PEDIDO,3)*/ PEDIDO SET PENDIENTE = ʼFʼ;

Por defecto, el paralelismo está desactivado, pudiéndose hacer sólo consultas paralelas.

La sentencia ALTER SESSION ENABLE PARALLEL DML, que permite la ejecución paralela de DML ha de ser la primera de la transacción.

Cada operación PDML ha de terminar con COMMIT o ROLLBACK (si no, error). En una transacción, tras una DML en serie (salvo SELECT), se ignoran los hints o cláusulas paralelas, y se continúa en serial.

El nuevo atributo de V$SESSION, PMDL_ENABLED, permite consultar si una sesión tiene habilitada el PDML. V$PQ_SESSTAT da información de las sentencias PDML.

6. Procesamiento paralelo en Oracle.(I)

2008-01-20T21:40:00.000+01:00

Las operaciones DML paralelas aceleran el acceso a grandes tablas, cuando se modifican al menos un 1% de las filas.
Son útiles en entornos DSS o Datawarehouse, y en ciertas operaciones OLTP (OnLine Transaction Processing).
Muchas operaciones paralelas requieren tablas e índices particionados, excepto INSERT... SELECT...
La principal ventaja es el rendimiento: el paralelismo puede acelerar la velocidad de proceso de transacciones DML.

Por ejemplo, si en una tabla particionada en 3 particiones se ejecuta una sentencia del tipo

UPDATE PEDIDO SET PENDIENTE = 'F';

La modificación se aplica a todas las filas que cumplen dicha condición, las cuales hay que buscar en toda la tabla (suponiendo que no existe un índice por el atributo "pendiente").

Para mejorar el rendimiento, es posible usar directivas de paralelismo en la misma sentencia SQL:

UPDATE /*+PARALLEL(PEDIDO,3)*/ PEDIDO SET PENDIENTE = 'F';

En este caso, la modificación se realiza en paralelo en las tres particiones, reduciendo el tiempo de procesamiento a la tercera parte aproximadamente.

Con Parallel DML se ejecuta la sentencia como una simple transacción sobre una única sesión: El control de la atomicidad de la tranascción es máximo (commit/rollback único).
Otros beneficios que obtendremos con el procesamiento paralelo sera:

No es necesario tener multiples sesiones que ejecuten operaciones sobre los mismos datos.
Dividir el trabajo por rangos rangos conocidos de de rowid o por claves.
Coordinar de forma manual el trabajo en paralelo o multiples instancias.

5. Accede de modo eficiente a los datos en Oracle

2008-01-11T20:46:00.000+01:00

El plan de ejecución está constituido por las decisiones que el optimizador toma para acceder a los datos, y depende de la meta que tenga éste definida (all_rows, first_rows). Cuando se detecte que una sentencia SQL accede de manera ineficiente a los datos, es necesario corregirla. El 90% del ajuste de las sentencias SQL en nuestras aplicaciones se consigue con:

	Evitar sentencias ineficientes como: de acceso en árbol (CONNECT BY, START WITH), de agrupaciones con HAVING, o la cláusula DISTINCT.
	Evitar consultas basadas en vistas complejas, que pueden penalizar su eficiencia inadvertidamente.
	Evitar escaneos completos (full-table scan) de tablas grandes, añadiendo índices, y obligando al optimizador a usarlo mediante hints. Verificar el uso óptimo de los índices.
	Cachear en el keep buffer pool tablas pequeñas a las que se acceda frecuentemente a toda ella.
	Evitar concatenaciones con tablas que no requieren datos. Verificar el uso óptimo de las técnicas de join (nested loop, hash join, sort-merge join).

El camino que el optimizador elige para acceder a los datos tiene gran impacto en la eficiencia de la sentencia SQL. Por ejemplo, si el optimizador tiene como meta el mejor rendimiento total (all_rows) es probable que elija el recorrido de la tabla completa (full-table scan), en vez de un acceso por índice (index scan), y preferirá una concatenación del tipo sort-merge join (que da el resultado completo antes) a una nested loop (que puede devolver la primera fila antes).

4. El Optimizador de Oracle

2007-12-28T12:45:00.001+01:00

Oracle dispone de un elemento, llamado optimizador, que planifica la ejecución de las consultas a los datos. Es el elemento clave para que las consultas sean eficientes.

Puede funcionar de dos maneras:

Basado en reglas. En este caso, el proceso servidor elige el camino a los datos, examinando la SELECT, de acuerdo a un ranking definido mediante unas reglas internas. No se recomienda su uso, pues el plan de ejecución de la sentencia SQL no tiene en cuenta la distribución de los datos entre los bloques, y es habitual, por ejemplo, que se usen índices que están disponibles, pero que no devuelven la mayoría de las filas, ralentizando así las consultas. El diseñador del SQL ha de tener en cuenta este hecho y desactivar índices explícitamente o colocar las tablas en el orden adecuado en la cláusula WHERE, dependiendo de la distribución de los datos.
Basado en coste. Es el modo recomendado. Consiste en que el optimizador examina cada sentencia e identifica todos los accesos posibles a los datos. Después, calcula el coste para cada camino y elige el de menor coste. El cálculo se hace basado en el número de lecturas lógicas y, para ello, se utilizan las estadísticas generadas para las tablas e índices.

El parámetro que permite seleccionar el modo es OPTIMIZER_MODE. El valor CHOOSE es el defecto (coste). Otros valores son:

ALL_ROWS tiene en cuenta en tiempo de respuesta total.
RULE es para que funcione en modo regla.
FIRST_ROWS calcula los costes, minimizando el tiempo de respuesta inmediato.

Las estadísticas que usa el optimizador basado en costes se recopilan en dba_tables, dba_indexes, dba_tab_cols, etc., mediante los comandos ANALYZE TABLE/INDEX o con el procedimiento almacenado dbms_stats.gather_schema_stats.

Otros parámetros que afectan al optimizador:

DB_FILE_MULTIBLOCK_READ_COUNT: Si tiene un valor alto, el optimizador basado en costes reconoce que las lecturas multibloque son más baratas en coste que las lecturas secuenciales, tendiendo a realizar full-scan sobre las tablas.
PARALLEL_AUTOMATIC_TUNING: Si tiene el valor ON, paraleliza los full-scan.
SORT_AREA_SIZE: Si tiene un valor alto, es más probable que el optimizador decida realizar una ordenación del conjunto resultado, en lugar de un acceso por índice.
HASH_AREA_SIZE: Si tiene valor, el optimizador es más propenso a realizar hash-joins en vez de nested-loop o sort-merge.

3. GESTIÓN DE ESPACIO EN ORACLE. Creación de Tablespace

2007-12-19T11:26:00.000+01:00

El primer tablespace es el SYSTEM. Este tablespace debe estar disponible siempre durante el funcionamiento normal de la BD porque contiene el diccionario de datos. Después de la creación de la BD, se recomienda la creación de otros espacios de tablas para que los datos de los usuarios puedan ser separados de los del diccionario de datos. Incluso, si varias aplicaciones se van a ejecutar sobre la misma BD, es recomendable que sus datos estén separados.

Para crear un tablespace se puede utilizar el comando create tablespace:

SVRMGR> create tablespace nombre_tablespace
2> datafile 'nombre_fichero' size 50M online;

En el ejemplo anterior se ha creado un tablespace de 50 Mb. de tamaño. Cada espacio de tabla tiene un conjunto de parámetros de almacenamiento que controla su crecimiento:

	initial: tamaño de la extensión inicial (10k).
	next: tamaño de la siguiente extensión a asignar (10k).
	minextents: número de extensiones asignadas en el momento de la creación del tablespace (1).
	maxextents: número máximo de extensiones.
	pctincrease: Porcentaje en el que crecerá la siguiente extensión antes de que se asigne, en relación con la última extensión utilizada.
	optimal: Tamaño óptimo declarado para este tablespace.
	pctused: porcentaje de utilización del bloque por debajo del cual Oracle considera que un bloque puede ser utilizado para insertar filas nuevas en él.

2007-11-28T10:49:00.000+01:00

CREACIÓN DE USUARIOS EN ORACLE

El objetivo de la creación de usuarios es establecer una cuenta segura y útil, que tenga los privilegios adecuados y los valores por defecto apropiados. En Oracle se puede especificar todo lo necesario para abrir una cuenta con el comando CREATE USER.

Los parámetros que se le pueden pasar son:

PARÁMETRO	SIGNIFICADO
Username	Nombre del Usuario (Esquema).
Password	Palabra clave de la cuenta. Puede ser asociada directamente a una cuenta del sistema operativo.
Default Tablespace	Espacio de tablas por defecto en el que los objetos de este usuario serán creados. Esto no da al usuario derecho de crear objetos.
Temporary Tablespace	Es espacio de tablas en el que se almacenarán los segmentos temporales de las ordenaciones.
Quota	Espacio máximo que puede ocupar en un espacio de tablas.
Profile	Asigna un perfil al usuario. Los perfiles se utilizan para restringir el uso de recursos como el tiempo de CPU.

Ejemplo de creación de usuario en Oracle:

SVRMGR> create user mcp
2> identified by zerep
3> default tablespace users
4> temporary tablespace temp;

Si no se especifica un perfil, se aplica el perfil por defecto de la BD, que se llama DEFAULT, y tiene asignados todos los límites a UNLIMITED.

Si no se especifica una cuota, el usuario no puede crear objetos.

Administración de la Base de Datos Oracle: Fichero INI.ORA

2007-11-22T00:38:00.000+01:00

Los parámetros que determinan el tamaño y composición de una instancia están almacenados
en un fichero llamado init.ora.

AJUSTE DE PARÁMETROS. FICHERO INIT.ORA
Este fichero es leído durante el arranque de la BD y puede ser modificado por el DBA. Cualquier
modificación de este fichero no tiene efecto hasta la siguiente vez que se arranque
la BD.
C:\oracle\admin\dbicops\pfile\init.ora

PARÁMETROS
db_name = “dbicops”
db_files = 1024
db_block_size = 8192
control_files = (“C:\oracle\oradata\dbicops\control01.ctl”, “C:\oracle\oradata\dbicops\
control02.ctl”, “C:\oracle\oradata\dbicops\control03.ctl”)
db_block_buffers = 13498
shared_pool_size = 36860928
processes = 150
log_buffer = 32768
max_dump_file_size = 10240 # limit trace file size to 5M each
background_dump_dest = C:\oracle\admin\dbicops\bdump
user_dump_dest = C:\oracle\admin\dbicops\udump

ESPECIFICACIÓN DE PARÁMETROS
DB_NAME: indica el identificador de la BD que en este caso es ‘prueba’. Debe tener como
máximo 8 caracteres. Único parámetro obligatorio.
CONTROL_FILES: Este parámetro contendrá el nombre de los ficheros de control y su ubicación,
como, por ejemplo: /DISK1/control01.conç
DB_BLOCK_SIZE: Tamaño del bloque de datos de Oracle. Por defecto: 2K o 4K. Una vez
fijado no puede modificarse.
DB_BLOCK_BUFFERS: Especifica el número de buffers de la caché en la SGA. Cuanto más
grande, menos acceso a disco tendremos. Sin embargo, ocuparemos más memoria, y será
necesario realizar más swapping. Compromiso de eficacia y rapidez.
SHARED_POOL_SIZE: Tamaño en bytes del pool compartido. Por defecto: 3500000.
LOG_BUFFER: Número de bytes asignados al buffer de redo log en la SGA.
PROCESSES: Máximo número de procesos de SO que pueden acceder de forma concurrente.
Mínimo: 1 por usuario + procesos de arrancados con cada instancia.
DB_FILES: Número de ficheros que se podrán crear en una BD. Mín 1, máx depende del
SO.
LOG_FILES:Máximo número de ficheros de log.
MAX_DUMP_FILE_SIZE: Máximo tamaño en bloques de SO de los ficheros de traza.
BACKGROUND_DUMP_DEST: Ubicación de los ficheros de las trazas de los procesos.
USER_DUMP_DEST: Ubicación de los ficheros de traza de los usuarios.
CORE_DUMP_DEST: Ubicación de los ficheros de traza de los ficheros core.
ROLLBACK_SEGMENTS: Nombres de los segmentos de rollback.

Impresión directa con PCL

2007-11-14T17:40:00.000+01:00

Puede que alguna vez necesiteis hace impresión directa sobre la impresora utilizando PCL, os paso una página con la secuencia de comandos que necesitas para dar formato a tu impresion:

http://pcl.to/font_selection.html

Define un Host Array en estructura para Pro*C

2007-11-13T10:19:00.000+01:00

La forma mas eficiente de trabajar en Pro*C y realizar consultas en bloque es mediante Host Array. En los ejemplos de Oracle se muesta consultas en host array de uno o dos campos, pero lo habitual que consultar multiples campos accediento a varias tablas. La forma mas efeciente y comoda de consultar es agrupar cada una de los campos a consultar en una estructura, y definir un array de MAX_ELEMENTOS de dicha estructura.

En nuestro ejemplo vamos a consultar los siguientes campos en nuestra query: Dessrv, fecha, numero_srv, estado.

1.- Declaración de tamaños y estrctura:

EXEC SQL BEGIN DECLARE SECTION;
/* Definicion de tamaño de cada campo */
#define TAM_FECHA 10
#define TAM_DES_SERV 40
#define TAM_NUM 15
#define TAM_ESTADO 10
#define MAX_ELEMENTOS 500

/* Definicion de tipo para cada campo de la estructura */
typedef char TDesServ[TAM_DES_SERV + 1];
typedef char TFecha[TAM_FECHA + 1];
typedef char TNUM[TAM_IMSI +1];
typedef char TEstado[TAM_ESTADO +1];

/* Definición de tipo de cada campo de la estructura en Oracle */
EXEC SQL TYPE TDesServ IS STRING (TAM_DES_SERV + 1);
EXEC SQL TYPE TFecha IS STRING (TAM_FECHA + 1);
EXEC SQL TYPE TNUM IS STRING (TAM_NUM +1);
EXEC SQL TYPE TEstado IS STRING (TAM_ESTADO +1);

/* ___ Estructura de datos ___ */
typedef struct TEstrcutura{
TDesServr vDesServ;
TFecha vFecha;
TNUM vNUM;
TEstado vEstado;
}ESTRUCTURA;

/* Estructura de indices para eviar error de oracle en campo nulo */
typedef struct TindEstructura{
short indvDesServ;
short indvFecha;
short indvNUM;
short indvEstado;
}indESTRUCTURA;
EXEC SQL END DECLARE SECTION;

2.- Volcado de los datos sobre el host array:
EXEC SQL BEGIN DECLARE SECTION;
int iOraNumRegistros = MAX_ELEMENTOS;
ESTRUCTURA ptOraRegist[MAX_ELEMENTOS];
indESTRUCTURA ptOraIndRegist[MAX_ELEMENTOS];
EXEC SQL END DECLARE SECTION;

/* Inicalizacion de la estructura de orale */
memset((void *) ptOraRegist, 0, sizeof(ESTRUCTURA)*MAX_ELEMENTOS);
memset((void *) ptOraIndRegist, 0, sizeof(indESTRUCTURA)*MAX_ELEMENTOS);

/* Volcado de datos sobre el host array para MAX_ELEMENTOS */
EXEC SQL FOR :iOraNumRegistros
FETCH C_QUERY_INFO INTO :ptOraRegist:ptOraIndRegist;

3.- Acceso a los elementos de array:
Para acceder a cada uno de los elementos de array se accede a traves del indice del array:

ptRegist[Cont].vDesServ
ptRegist[Cont].vNUM

Siendo Cont una varable con los valores comprendidos entre 0 y MAX_ELEMENTOS -1

Empezamos!

2007-11-13T09:16:00.000+01:00

Hola a todos,

Hoy me he decido a poner en marcha un blog dedicado a la programación y todo lo que pueda entrar en ella. Soy Ingeniero en Informática y llevo trabajando en este mundo hace unos 7 años, por fín me he decidido por compartir mis experiencias, problemas, ofuscaciones etec....

Aunque todavía no he decidido muy bien el formato, guion etec.., pero lo que si que tengo claro es que compartiré mis experiencias y problemas de forma que pueda contribuir a que solventar problemas comunes o no tan comunes que te puede ahorar mucho tiempo en tu trabajo.

Espero cumplir mi objetivo y que me ayudeis tambien a conseguirlo con vuestros comentarios.

Gustavo.