martes, 12 de agosto de 2014

Administrando un proyecto : Toma 1


Mi ultima historia fue sobre algunos puntos que a veces no son tomados por los AP, claro todo fue desde el punto de vista del programador.


Bien pues, no sé si fue a raíz de ésa entrada o si realmente haya sido una buena coincidencia pero ahora me tocó administrar mi primer proyecto y acepté porque a lo mejor podría brindar un enfoque distinto a esas actividades, al menos en mi lugar de trabajo.


La primer semana fué tan abrumadora sobretodo porque se trata de un proyecto basado en otro proyecto ya viejo (vamos, una actualización) que carece de documentación, no dejaba de pensar “por donde empiezo” pero al final fue posible establecer un punto de partida, basándome en algunos puntos que ya mencione en la otra entrada, sugerencias de mis compañeros y por supuesto, lo aprendido en la escuela.


Creo yo que es una gran experiencia intentarlo y reforzar ese aprendizaje … aunque realmente deseo no dejar de lado la programación pues esa es mi pasión.


martes, 5 de agosto de 2014

Regresó StarUML!

staruml_logo_text_small

 

Star UML es una de esas herramientas que no he podido sustituir por algun otro software que sea gratis o libre porque son dificiles de usar o no son tan completos como lo es Star UML.

Algo que es triste (o lo era) es que el proyecto se abandonó por ahi del 2005 y desde entonces no habia recibido actualizacion alguna salvo un intento de rescate llamado White Star UML que le daba una interfaz un poco mejorada pero en el fondo era el mismo software.

Esta semana cheque el sitio para descargarlo y me topo con la sorpresa que si, un alma caritativa decidio darle seguimiento al proyecto y darle un lavado de cara completo junto con correcciones y mejoras que ya le hacian falta. Obvio, al estar en fase beta tiene sus errores y detalles, pero aun asi es una gran noticia y definitivamente me encanta.

Screenshot_1

 

Link: StarUML

 

 

sábado, 28 de junio de 2014

Django: Dividir view.py en multiples archivos

python_django

Los que ya conocen, y sobretodo los que apenas van aprendiendo a programar con django han de recordar que existe un archivo llamado views.py donde se definen, valga la redundancia, nuestras vistas o funciones que llamaremos a través de una URL mapeada desde otro archivo llamado urls.py.

El asunto es que en el tutorial de inicio  te proponen que , al igual que con modelos, se metan todas las vistas ahí dividiéndolos en classes o funciones.

Pero en lo personal estoy mas acostumbrado a hacer modular todo aquello que tiene una extensión muy grande y por ello me di a la tarea de googlearle un poco y encontrar la mejor forma de dividir los views en distintos archivos que , en mi caso, lo hice de acuerdo a que seccion o funcionalidad del sistema completo pertenecen.

  1. Para esto lo primero que vamos a hacer es borrar o renombrar el archivo views.py que crea django al inicializar la aplicacion por primera vez.

  2. En seguida creamos un directorio al mismo nivel que el archivo views.py llamado views.

  3. En el nuevo directorio vamos a crear un archivo vacío llamado __init__.py (recuerda que son dos guiones al inicio y al final), dicho de otra manera, convertimos la carpeta en un paquete.

  4. Finalmente en esa carpeta vamos a crear tantos archivos de views queramos con las funciones que requerimos.

  5. En las urls en lugar de llamar "views.nombreDelView" vamos a llamar la funcion con su ruta completa:
    "app.views.archivoview.funcion".


Al final nuestra estructura queda algo asi:

Screenshot_5

 

Y en las urls, por ejemplo llamamos de esta forma:

[code language="python"]

urlpatterns = patterns('',
url(r'^get_asentamientos/', "app.views.utils.obten_municipios", name="get_asentamientos")
)

[/code]

 

De ésta forma, a mi forma de ver, me es mas cómodo localizar un error en un view especifico dentro de un archivo especifico que en una lista de 10,15 o mas views definidos en el mismo archivo.

 

 

lunes, 23 de junio de 2014

Aqui huele a pescado podrido [Glassfish]

sparkz31.6

 

En donde laboro trabajamos principalmente Java para aplicaciones web que posteriormente se despliegan en un servidor glassfish.

La rutina de despliegue, a parte de aburrida, resulta hasta monótona porque son los mismos pasos: Compila, sube los jars, despliega... fin.

Pero  para una aplicación en particular, de hecho muy importante, ocurrio que no importa que hiciéramos obteniamos un "NamingNotFoundException" , que en breves palabras significa que la variable global de un bean no existía y por ende no se podía inyectar a otros beans.

Wut?

Que intentamos?, casi todo en realidad:

  1. Desplegarlo en otro servidor (pensando que el glassfish remoto estaba mal instalado)

  2. Cambiar la libreria de persistencia (de Hibernate a Toplink)

  3. Asignando manualmente un nombre a los beans remotos

  4. Creando un EAR (actualmente trabajamos modulos independientes).


Para esto llevabamos 3 semanas de investigacion y el tiempo se agotaba para entregar el proyecto.

Pero lo curioso es que desde netbeans era posible desplegar y hacer funcionar el proyecto, lo cual implicaba que a nivel codigo no era el problema, era un problema de despliegue.

Para nuestros proyectos usamos beans remotos cuyas interfaces y entidades se guardan en una libreria de classes el cual es comprimido en un jar y una de las soluciones que nos propusieron  era mover dicho jar a la carpeta lib/ext de la instancia de glassfish pero igual seguía habiendo problemas de despliegue.

Hasta que mientras le picaba a la consola de glassfish leí detenidamente una instrucción:

Captura de pantalla de 2014-06-23 12_11_37

 

A pesar de que los jar despliegan porque el servidor ya cuenta con la libreria de classes, resulta que el bean no encuentra dicha librería y por esa razón no se registra la sesión.

Asi que la solución al misterio que parecía no tener pies ni cabeza era copiar el mentado jar a la carpeta /lib/applibs  y especificar únicamente el nombre del jar de librerías al hacer el despliegue.

Cosas tan pequeñas pueden arruinarte el día, o en este caso.. casi un mes :/ . Pero por lo menos ha quedado bastante bien :)

domingo, 22 de junio de 2014

Primeros pasos con Django

django-logo-positive
Hoy después de mucho me reencuentro con django decidido formalmente a continuar con el desarrollo del primer proyecto de Focus Development.

Dado que perdi practica y algunos bookmarks dejaron de funcionar decidi mejor ir documentando algunas cosillas clave como en este caso los primeros pasos. Por razones que (te odio maldito ATI) no estan en mi control tengo que trabajar desde Windows, pero en linux es practicamente lo mismo salvo la instalacion de Python.

 

Creando un proyecto


Lo primero a hacer ya que has instalado django es crear tu proyecto, para ello te colocas en una carpeta desde una consola y escribes:

[code language="shell"]django-admin.py startproject [proyecto][/code]

Donde <proyecto> es el nombre de tu proyecto, sin los signos.

Este te creara la estructura de directorios y archivos de configuracion necesarios para comenzar a trabar en tu aplicacion.

Configurando la base de datos

Que es un proyecto web si base de datos?, en django lo saben y para ello la configuración de la bd no podría ser mas facil, en tu directorio de proyecto encontraras un archivo llamado settings.py

En éste si deslizas un poco el scroll encontraras las siguientes lineas:

[code language="python"]

# Database
# https://docs.djangoproject.com/en/1.6/ref/settings/#databases

DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite',
'NAME': ''
}
}

[/code]

... o algo similar

El objetivo es configurar estos parametros para tu base de datos, en mi caso como uso MySQL le digo que use el motor

correspondiente y agrego unos parametros que en sqlite no son requeridos, quedando de esta forma:

[code language="python"]

# Database
# https://docs.djangoproject.com/en/1.6/ref/settings/#databases

DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'baseDeDatos', //Nombre de la base de datos
'USER': 'admin',
'PASSWORD': 'password',
'HOST': '127.0.0.1',
'PORT': '666',
}
}

[/code]

 

Con esto ya podemos probar la conexión y de una vez configurar las tablas de sistema que almacenaran datos como el administrador de la aplicación usando el comando desde terminal:


[code]python manage.py syncdb[/code]


Si todo ha salido bien nos pedira que definamos las credenciales del administrador.

 Creando la aplicacion


Una cosa es el proyecto entero y la otra la aplicación que vamos a desplegar o mas bien, a  desarrollar.

Para crear la aplicación hacemos uso del comando:


[code] python manage.py startapp [aplicacion][/code]


 

Si los planetas se alinean seguire con algunas cosillas del modelo de datos donde defino llaves foraneas y llamado a tablas ya creadas.. Por el momento es todo! :)

 

lunes, 2 de junio de 2014

Exportar e Importar Bases de Datos en Informix

update Unas de las tareas más comunes al trabajar con bases de datos es el exportar copias de seguridad y restaurarlas en otro servidor, podria sonar engorroso pero en realidad es muy simple, desde una terminal como usuario del grupo informix :



Para exportar bases de datos creamos un directorio en el directorio base de informix, en mi caso lo llame backups

[code language="bash"]mkdir backups[/code]

Y exportamos la bd:

[code language="bash"]dbexport &amp;lt;bd&amp;gt; -o backups[/code]

Donde <bd> es la base de datos que deseamos exportar y  backups es la ruta de la carpeta que recien creamos.

 

Para importar copiamos nuestra carpeta backups o bien, en mi caso la creo en el nuevo servidor y pego el .exp de la base de datos y procedemos a importar:

[code language="bash"]dbimport &amp;lt;bd&amp;gt; -i backups [/code]

Donde <bd> es la base de datos que deseamos importar, es importante que NO este creada ya que no va a sobreescribir y nos arrojará un error y backups es la ruta de la carpeta donde estan ubicados los respaldos, no se agrega el nombre de la carpeta .exp, solo la carpeta que los contiene.

Y con esto habremos hecho copias completas de bases de datos :)

 

lunes, 14 de abril de 2014

Web GL : Internet Explorer vs Chrome

He de decir que me agrada el estilo de la publicidad que Microsoft le ha puesto a Internet Explorer, usando un personaje estilo animé en algunos cortos interesantes (pero exageradamente publicitarios)  y que ademas es quien "postea" en la fanpage.

Uno de los posts me llamo la atencion porque promocionan el soporte web gl en Internet Explorer usando un demo creado por un desarrollador independiente. Así que lo probé en IE y en Chrome y estos son los resultados:

[caption id="attachment_2230" align="aligncenter" width="479"]Chrome Internet Explorer[/caption]

[caption id="attachment_2231" align="aligncenter" width="509"]Internet Explorer Chrome[/caption]

Como es notable, aun le falta mucho trabajo a Internet Explorer, pero los resultados ya son pasables, no deja de ser interesante como Microsoft tuvo que dar el brazo a torcer y adoptar los estándares en lugar de tratar de imponer los suyos.