Sun sun = new Sun( 1982 );
sun.create( "SunSparc", "Solaris", "Java", "OpenOffice" );
sun.buy( "MySQL");
oracle.buy( sun, 2010 );
oracle.getPatents( sun );
oracle.fireStaff( sun );
oracle.eat( sun );
sun = null;
System.gc(); :o(
hoy me dí cuenta que me estoy poniendo vieja. Alguna charla de pasillo y este breve código (*) que presenta un montón de eventos que han sucedido desde que nací, me hicieron darme cuenta que el tiempo pasa... aún recuerdo haber sido conejito de indias (hace más de 10 años!!!) cuando se empezaba a usar java y haber visto varias máquinas de escritorio sun.
(*)- gracias a Mauricio por publicarlo, y porque me lleva ventaja :D
martes, 6 de abril de 2010
miércoles, 15 de octubre de 2008
sigo, frases célebres...
... o en este caso no tanto.
La ví en la firma de un post en un foro técnico (sobre linux).
Remember: amateurs built the ark... professionals built the Titanic
Se podrían discutir horas y horas por esta frase tan corta, pero a mí me hizo
reir mucho :D
La ví en la firma de un post en un foro técnico (sobre linux).
Remember: amateurs built the ark... professionals built the Titanic
Se podrían discutir horas y horas por esta frase tan corta, pero a mí me hizo
reir mucho :D
jueves, 1 de noviembre de 2007
frases célebres
acabo de leer una frase inspiradora, o por lo menos cuestionadora:
"cada vez que instalas un windows de onda, Dios mata un pinguino" - orasio dixit
simplemente dejo registro, para en algún momento ampliar...
"cada vez que instalas un windows de onda, Dios mata un pinguino" - orasio dixit
simplemente dejo registro, para en algún momento ampliar...
martes, 23 de octubre de 2007
Alberto Mendelzon Workshop 2007
El año pasado se realizó en Chile el primer Workshop en honor de Alberto Mendelzon,
un argentino que tuvo mucho que ver con la creación de la carrera de Computación en Uruguay.
Este año se repite el evento en Uruguay: el Segundo Alberto Mendelzon Workhop, desde hoy hasta el próximo viernes 26 de octubre.
Simplemente una gran oportunidad para conocer trabajos de investigación en el área de Base de Datos y la Web.
De paso nos sacrificamos y pasamos unos días en Punta del Este, disfrutando de la vista del Hotel Las Cumbres.
un argentino que tuvo mucho que ver con la creación de la carrera de Computación en Uruguay.
Este año se repite el evento en Uruguay: el Segundo Alberto Mendelzon Workhop, desde hoy hasta el próximo viernes 26 de octubre.
Simplemente una gran oportunidad para conocer trabajos de investigación en el área de Base de Datos y la Web.
De paso nos sacrificamos y pasamos unos días en Punta del Este, disfrutando de la vista del Hotel Las Cumbres.
jueves, 11 de octubre de 2007
Reflexiones sobre Testing
Actualmente estoy estudiando académicamente algunos conceptos de Testing. Como nadie está a salvo de cometer errores, asumimos que los programas que hacemos tienen errores. Entonces se desarrollan varios tipos de técnicas para descubrir esos errores lo más pronto posible y resolverlos de forma de dejar el programa lo más libre de errores posible.
En testing también hay áreas de trabajo para ver cómo se comportará un sistema si es sobrecargado e incluso si recibe ataques de seguridad. Estás son las áreas avanzadas y son realmente muy complejas.
Pensando en el proceso de desarrollo más simple:
1)- tenemos un Cliente que le dice a nuestro Analista el programa que quiere (en el medio el Analista tiene que comprender el lugar donde el cliente usará ese programa, organización, tareas, etc.).
2)- El analista escribe los Requerimientos (que valida con el Cliente) y se los da a un Arquitecto de Software (suponiendo que lo tenemos). Generalmente allí va la información de qué debe hacer el sistema. El Arquitecto hace la Arquitectura, el diseño de alto nivel.
3)- El Arquitecto entrega la Arquitectura y asiste al Programador para hacer el diseño de bajo nivel. A partir de este diseño el Programador implementa el programa.
4)- El Programador entrega el sistema al Testeador, que revisará que el sistema cumpla con los Requerimentos pedidos.
Sé que en casos pequeños este proceso es demasiado "idealizado". Es muy probable que los roles de Analista, Arquitecto, Programador y Testeador los realice la misma persona. En ese caso, probablemente se documente poco en el camino, y haya menos errores debido a que tiene todo el conocimiento. Pero, ¿Qué pasa cuando cada uno de estos roles los cumple una o varias personas? ¿Cuántas instancias de comunicación encontramos?
Independientemente de los errores que cada integrante de un equipo puede cometer en sus tareas, muchos de los errores en software provienen de fallas en comunicación entre las personas que participan en su producción. Ahora la gran pregunta es cuáles
y cómo detectarlos(o prevenirlos)?
En Testing están apareciendo los errores de software, y además de entregar un software libre de errores, la sistematización del testing nos permite aprender a tener menos errores. Eso es válido si reflexionamos sobre los errores que cometemos...
En fin... el tema puede ser muy largo... el día gris me puso reflexiva, aunque también colaboró este sitio que encontré por ahí:
Testing Reflections
En testing también hay áreas de trabajo para ver cómo se comportará un sistema si es sobrecargado e incluso si recibe ataques de seguridad. Estás son las áreas avanzadas y son realmente muy complejas.
Pensando en el proceso de desarrollo más simple:
1)- tenemos un Cliente que le dice a nuestro Analista el programa que quiere (en el medio el Analista tiene que comprender el lugar donde el cliente usará ese programa, organización, tareas, etc.).
2)- El analista escribe los Requerimientos (que valida con el Cliente) y se los da a un Arquitecto de Software (suponiendo que lo tenemos). Generalmente allí va la información de qué debe hacer el sistema. El Arquitecto hace la Arquitectura, el diseño de alto nivel.
3)- El Arquitecto entrega la Arquitectura y asiste al Programador para hacer el diseño de bajo nivel. A partir de este diseño el Programador implementa el programa.
4)- El Programador entrega el sistema al Testeador, que revisará que el sistema cumpla con los Requerimentos pedidos.
Sé que en casos pequeños este proceso es demasiado "idealizado". Es muy probable que los roles de Analista, Arquitecto, Programador y Testeador los realice la misma persona. En ese caso, probablemente se documente poco en el camino, y haya menos errores debido a que tiene todo el conocimiento. Pero, ¿Qué pasa cuando cada uno de estos roles los cumple una o varias personas? ¿Cuántas instancias de comunicación encontramos?
Independientemente de los errores que cada integrante de un equipo puede cometer en sus tareas, muchos de los errores en software provienen de fallas en comunicación entre las personas que participan en su producción. Ahora la gran pregunta es cuáles
y cómo detectarlos(o prevenirlos)?
En Testing están apareciendo los errores de software, y además de entregar un software libre de errores, la sistematización del testing nos permite aprender a tener menos errores. Eso es válido si reflexionamos sobre los errores que cometemos...
En fin... el tema puede ser muy largo... el día gris me puso reflexiva, aunque también colaboró este sitio que encontré por ahí:
Testing Reflections
martes, 18 de septiembre de 2007
Como instalar Postgres en Linux sin root
Hace un par de años trabajé en desarrollo en una máquina Linux, y realmente fui muy feliz :D Aunque todos mis compañeros directamente trabajaban con root, yo tenía mi propio usuario para trabajar y pasaba a root cuando tenía que instalar algo en particular. De todos modos mi usuario era parte del grupo root, así que mi vida era realmente fácil.
Debido a las vueltas de la vida, últimamente andaba medio oxidada en estos asuntos de instalaciones en Linux, pero en mi tarea docente, probando el ambiente en el que trabajan mis estudiantes, me tocó instalar Postgres en Fedora, con un usuario común y corriente. Justamente en la lista de correo de postgres hoy recibo un mail que dice "acaban de salir los RPM para Fedora y Red Hat". Bárbaro, pensé... instalo los rpm y listo!! pero no, porque los rpm los tiene que instalar root.
Entonces gracias a nuestro querido amigo Google encontré en el sitio
Web Experto un detallado tutorial de como instalar postgres en linux. Luego de leerlo a conciencia (a pesar de que las primeras instrucciones decían: cree el usuario postgres, cree carpetas en áreas del sistema), decidí que era suficientemente fiable, ajustando algunas cosas a mi ambiente.
Antes que nada comentar que logré tener éxito en mi instalación, la cuál está pensada para desarrollo, con lo que no es traumático que haya que levantar la base cada vez que se comienza a trabajar y se baja al terminarse los procesos del usuario.
Dicho esto paso a comentar las adaptaciones que hice al tutorial de Web Experto.
Preparación
Dado que Postgres correrá en la cuenta del usuario común que tengo, no necesito crear el usuario postgres.
Pero antes de continuar estableceremos algunas variables de entorno necesarias para el uso del servidor. En el directorio "home" del usuario editamos el archivo ".bashrc", si no existe lo creamos, y le agregamos las siguientes lineas:
PATH=$PATH:~/pgsql/bin
MANPATH=$MANPATH:~/pgsql/man
PGLIB=~/pgsql/lib
PGDATA=~/pgsql/data
LC_COLLATE=C
LC_CTYPE=C
LC_COLLATE=C
export PATH MANPATH PGLIB PGDATA LC_COLLATE LC_CTYPE LC_COLLATE
Aquí modifiqué las rutas para que estuvieran dentro de los directorios de mi usuario.
Lo primero que debemos hacer es conseguir los fuentes del software, los podemos bajar gratuitamente de http:/www.postgresql.org/
Una vez que tenemos el fuente, debemos descomprimirlo en un directorio desde donde lo compilaremos. En mi caso uso ~/postgres/ para bajar
En mi directorio de usuario
# cd
Creamos el directorio donde se compilará el software
# mkdir postgres
Creamos el directorio donde se instalara el software una vez compilado
# mkdir pgsql
Ya tenemos los directorios donde ubicaremos el cógido fuente a compilar y los binarios y demas archivos necesarios para el uso del serividor una vez que este compilado e instalado.
Ubicarnos en el directorio base (~/postgres)
# cd postgres
Finalmente debemos descomprimir el archivos con:
# tar xvfz postgresql-6.5.tar.gz
Con esto obtenemos un directorio llamado: postgresql-8.2.5 que es la base del árbol de directorios conteniendo el código fuente, la documentación y demás archivos necesarios.
Configuración
Previo a la compilación en si, se debe configurar el código fuente para nuestra plataforma en particular, en este proceso entra como factor de gran importancia la designación del directorio donde se instalará PostgreSQL, esto se hace mediante la variable "prefix".
# cd ~/postgres/postgresql-8.2.5/src
# ./configure --prefix=~/pgsql
Este script ajustará la compilación a nuestro ambiente, donde prefix es el directorio base donde se instalara el servidor una vez compilado, si obviamos este parámetro por defecto toma el directorio /usr/local/psql
Compilación
El proceso de compilación es idéntico a cualquier otro programa. En esta caso la documentación recomienda una secuencia algo distinta pero con el mismo resultado.
# gmake all >& make.log &
# tail -f make.log
Si todo salió como es de esperar, tail nos muestra la ultima linea del archivo de log, la que dice:
All of PostgreSQL is successfully made.
Ready to install.
Instalación de binarios
Procedemos ahora a instalar los binarios y archivos adicionales. Si ya nos encontramos en el directorio "~/pgsql/postgresql-8.2.5/src" pasamos directamente a la segunda línea de la secuencia.
# cd ~/pgsql/postgresql-8.2.5/src
# gmake install >& make.install.log &
# tail -f make.install.log
Luego de unos cuantos segundos en el monitor veremos la siguiente línea, esto nos indica que ya termino la instalación del servidor.
Thank you for choosing PostgreSQL, the most advanced open source database engine.
Nota: en mi instalación no apareció esta línea, pero sé que terminó exitosamente.
Instalación de la Documentación
Solo nos resta instalar la documentación, para ello debemos posisionarnos en el directorio "~/pgsql/postgresql-8.2.5/doc" y ejecutar:
# make install
Librerías
Dado que este paso de instalar las librerías para el sistema lo tenía que hacer root, directamente me lo saltee.
Creación de las bases de datos
El siguiente paso es crear las bases de datos básicas para el funcionamiento del servidor de SQL. Esto se hace con los scripts que quedaron en el directorio bin de instalación del postgres: ~/pgsql/bin
# initdb
Prueba
Bien, ahora vamos a ver si todo salio como es de esperar, primero vamos a lanzar el servidor de SQL de PostgreSQL
# postgres -D ~/pgsql/data &
Creamos la base de datos de prueba con la siguiente linea de comando:
# createdb
Finalmente nos conectamos al servidor con el cliente:
# psql
Luego de esto tendrán que seguir sus manuales de postgres (y psql) para crear sus usuarios de la base, sus bases de datos, etc...
Suerte!
Debido a las vueltas de la vida, últimamente andaba medio oxidada en estos asuntos de instalaciones en Linux, pero en mi tarea docente, probando el ambiente en el que trabajan mis estudiantes, me tocó instalar Postgres en Fedora, con un usuario común y corriente. Justamente en la lista de correo de postgres hoy recibo un mail que dice "acaban de salir los RPM para Fedora y Red Hat". Bárbaro, pensé... instalo los rpm y listo!! pero no, porque los rpm los tiene que instalar root.
Entonces gracias a nuestro querido amigo Google encontré en el sitio
Web Experto un detallado tutorial de como instalar postgres en linux. Luego de leerlo a conciencia (a pesar de que las primeras instrucciones decían: cree el usuario postgres, cree carpetas en áreas del sistema), decidí que era suficientemente fiable, ajustando algunas cosas a mi ambiente.
Antes que nada comentar que logré tener éxito en mi instalación, la cuál está pensada para desarrollo, con lo que no es traumático que haya que levantar la base cada vez que se comienza a trabajar y se baja al terminarse los procesos del usuario.
Dicho esto paso a comentar las adaptaciones que hice al tutorial de Web Experto.
Preparación
Dado que Postgres correrá en la cuenta del usuario común que tengo, no necesito crear el usuario postgres.
Pero antes de continuar estableceremos algunas variables de entorno necesarias para el uso del servidor. En el directorio "home" del usuario editamos el archivo ".bashrc", si no existe lo creamos, y le agregamos las siguientes lineas:
PATH=$PATH:~/pgsql/bin
MANPATH=$MANPATH:~/pgsql/man
PGLIB=~/pgsql/lib
PGDATA=~/pgsql/data
LC_COLLATE=C
LC_CTYPE=C
LC_COLLATE=C
export PATH MANPATH PGLIB PGDATA LC_COLLATE LC_CTYPE LC_COLLATE
Aquí modifiqué las rutas para que estuvieran dentro de los directorios de mi usuario.
Lo primero que debemos hacer es conseguir los fuentes del software, los podemos bajar gratuitamente de http:/www.postgresql.org/
Una vez que tenemos el fuente, debemos descomprimirlo en un directorio desde donde lo compilaremos. En mi caso uso ~/postgres/ para bajar
En mi directorio de usuario
# cd
Creamos el directorio donde se compilará el software
# mkdir postgres
Creamos el directorio donde se instalara el software una vez compilado
# mkdir pgsql
Ya tenemos los directorios donde ubicaremos el cógido fuente a compilar y los binarios y demas archivos necesarios para el uso del serividor una vez que este compilado e instalado.
Ubicarnos en el directorio base (~/postgres)
# cd postgres
Finalmente debemos descomprimir el archivos con:
# tar xvfz postgresql-6.5.tar.gz
Con esto obtenemos un directorio llamado: postgresql-8.2.5 que es la base del árbol de directorios conteniendo el código fuente, la documentación y demás archivos necesarios.
Configuración
Previo a la compilación en si, se debe configurar el código fuente para nuestra plataforma en particular, en este proceso entra como factor de gran importancia la designación del directorio donde se instalará PostgreSQL, esto se hace mediante la variable "prefix".
# cd ~/postgres/postgresql-8.2.5/src
# ./configure --prefix=~/pgsql
Este script ajustará la compilación a nuestro ambiente, donde prefix es el directorio base donde se instalara el servidor una vez compilado, si obviamos este parámetro por defecto toma el directorio /usr/local/psql
Compilación
El proceso de compilación es idéntico a cualquier otro programa. En esta caso la documentación recomienda una secuencia algo distinta pero con el mismo resultado.
# gmake all >& make.log &
# tail -f make.log
Si todo salió como es de esperar, tail nos muestra la ultima linea del archivo de log, la que dice:
All of PostgreSQL is successfully made.
Ready to install.
Instalación de binarios
Procedemos ahora a instalar los binarios y archivos adicionales. Si ya nos encontramos en el directorio "~/pgsql/postgresql-8.2.5/src" pasamos directamente a la segunda línea de la secuencia.
# cd ~/pgsql/postgresql-8.2.5/src
# gmake install >& make.install.log &
# tail -f make.install.log
Luego de unos cuantos segundos en el monitor veremos la siguiente línea, esto nos indica que ya termino la instalación del servidor.
Thank you for choosing PostgreSQL, the most advanced open source database engine.
Nota: en mi instalación no apareció esta línea, pero sé que terminó exitosamente.
Instalación de la Documentación
Solo nos resta instalar la documentación, para ello debemos posisionarnos en el directorio "~/pgsql/postgresql-8.2.5/doc" y ejecutar:
# make install
Librerías
Dado que este paso de instalar las librerías para el sistema lo tenía que hacer root, directamente me lo saltee.
Creación de las bases de datos
El siguiente paso es crear las bases de datos básicas para el funcionamiento del servidor de SQL. Esto se hace con los scripts que quedaron en el directorio bin de instalación del postgres: ~/pgsql/bin
# initdb
Prueba
Bien, ahora vamos a ver si todo salio como es de esperar, primero vamos a lanzar el servidor de SQL de PostgreSQL
# postgres -D ~/pgsql/data &
Creamos la base de datos de prueba con la siguiente linea de comando:
# createdb
Finalmente nos conectamos al servidor con el cliente:
# psql
Luego de esto tendrán que seguir sus manuales de postgres (y psql) para crear sus usuarios de la base, sus bases de datos, etc...
Suerte!
miércoles, 12 de septiembre de 2007
Software Freedom Day: 15 de setiembre
Cortita y al pie... aunque tenemos carteles a la vuelta no los leemos, así que dejo otro cartel más.
El 15 de setiembre se festeja a nivel mundial el Software Freedom Day : Día del Software Libre en criollo. Este día la comunidad del software libre lo toma para hacer difusión (o evangelizar :)
A veces se maneja el término "Software Libre" sin saber bien de qué se trata, he notado que la gente tiene el concepto de "el Software Libre es bueno porque no tengo que pagar licencias", lo que es cierto, pero no es todo el punto del Software Libre.
En Uruguay la Comunidad de Software Libre organiza una Jornada de Charlas y Actividades, con el apoyo de muchos grupos de usuarios y demás (que coincidencia, algunos son los presentados en mi anterior post).
La Jornada será en la Facultad de Ingeniería de la Universidad de la República, con el apoyo del Centro de Estudiantes de Ingeniería.
Dirección: J.Herrera y Reissig 565.
Horario: de 10 a 18hs.
El 15 de setiembre se festeja a nivel mundial el Software Freedom Day : Día del Software Libre en criollo. Este día la comunidad del software libre lo toma para hacer difusión (o evangelizar :)
A veces se maneja el término "Software Libre" sin saber bien de qué se trata, he notado que la gente tiene el concepto de "el Software Libre es bueno porque no tengo que pagar licencias", lo que es cierto, pero no es todo el punto del Software Libre.
En Uruguay la Comunidad de Software Libre organiza una Jornada de Charlas y Actividades, con el apoyo de muchos grupos de usuarios y demás (que coincidencia, algunos son los presentados en mi anterior post).
La Jornada será en la Facultad de Ingeniería de la Universidad de la República, con el apoyo del Centro de Estudiantes de Ingeniería.
Dirección: J.Herrera y Reissig 565.
Horario: de 10 a 18hs.
Suscribirse a:
Entradas (Atom)
