Por un lado, liadillo jugando al poker y desarrollando mi nuevo blog, enfocado exclusivamente a mis inicios en este nuevo hobby. Obviamente, no es para sustituir al actual, ya que éste, es más para contar cosas genéricas sobre mi vida (aunque lo hago poco), o técnicas (desarrollo y demás historietas).

Además, también quiero cambiar de nuevo este blog. Jamás debí dejar Drupal. Cuando se rompió mi viejo blog, debí reconstruirlo de nuevo sobre Drupal, y no cambiar a Wordrpress. Mi blog de poker, está construido sobre Durpal, y es una gozada incorporar cambios, en cambio, aquí, sudo la gota gorda sólo en pensar que tengo que actualizar, y que para poder meter dos tonterías, he tenido que tocar la plantilla a mano. Si bien, no son cosas difíciles, sobre todo, para alguien que trabaje todos los días con Wordpress, para mí, es una simple herramienta más, en la que no quiero centrarme, es sólo un punto de apoyo. Además, mi idea era que la publicidad no molestase tanto, pero el banner de la izquierda, cada vez va a peor. Qué coñazo.

Por otro lado, sigo en mi aprendizaje de la plataforma Velneo. Puede ser la herramienta definitiva donde asiente mi enorme trasero. Últimamente, dedico más tiempo en leer el fabuloso y gigantesco manual en perfecto castellano, que a desarrollar en sí, pero, mira, lo leido, ahí está, y si no fuese porque la formación es bastante cara (cara respecto a mi economía obviamente, porque sería algo bien pagado), no me lo pensaría ni dos veces en asistir una semanita a un curso intensivo. Además, las características de la nueva versión 7, que estará disponible para mediados de este año que entra, lo hacen algo más que apetecible. De momento, aprendo en la versión 6, de gratuita descarga. Velneo puede estar limitado en ciertos aspectos, por su concepción, pero podemos ampliar sus horizontes a base de DLL’s, y ahí es donde entra de nuevo en mi vida Lazarus/Freepascal. Si bien mi experiencia en desarrollo se basa más en aplicaciones de gestión y parecidos, hace mucho que no toco Object Pascal, y encima, nunca he desarrollado una DLL, aunque ésto, es como montar en bicicleta. De hacer falta, sería cuestión de documentarme, y echar unas cuantas horas y ya está. Cada vez me doy cuenta, que mi vida, de una manera u otra, siempre orbita al mejor lenguaje y mejor plataforma con la que he trabajado en mi vida, Delphi (Lazarus en su versión opensource).

Tengo algún proyectillo que otro en mente, pero de momento, me estoy centrando más en la lectura. Como no, InciGest, el maravilloso software de Gestión de Incidencias, que jamás vió la luz, y que se ha recomenzado en 3 lenguajes distintos, vuelve de nuevo en su 4º renacer, pero esta vez, bajo Velneo, jejeje. Ya veremos si coge o no forma, de momento, ando ahí construyendo tablas :D Como siempre, os mantendría informados :D

En fin, que como podréis observar, por ahí sigo, dándole vueltas a la vida tecnológica, nos leemos.

ShareThis

En mi hazaña, tropecé con una herramienta, Velneo, que me puse a ojear, y que es el tema principal de este post.

Por lo que me he podido enterar, Velneo, es la evolución de Velázquez Visual. Según la definición de su propia web:

Velneo es una plataforma completa de desarrollo de aplicaciones empresariales con base de datos integrada y con un catálogo de plantillas (ERP, CRM, Contabilidad…) de código abierto FLOSS.

Puesto tienen una versión gratuita de libre descarga, le he hecho un hueco en mi disco y me he dispuesto a instalarla. He echado una ojeada a la documentación existente (porque cuando la documentación está, es mejor leerla), y la verdad es que me está abriendo bastante los ojos, y me está encantando.

Básicamente, en Velneo, nos preocupamos por crear nuestra estructura de datos, y lo demás, es coser y cantar, teniendo asistentes que nos facilitarán nuestra cotidiana vida.

Obviamente, es un resúmen que desmerece mucho, puesto apenas hablo de las muchas ventajas que le estoy viendo a esta plataforma, pero, hay muchísima información online de gente con mucha más experiencia que yo, que usa Velneo a diario para sus proyectos, y que explican mucho mejor que yo estos detalles.

Igualmente, pasados unos días de cacharrear con ella, os contaré que tal, y si puedo colgaré algún video.

Un saludo

ShareThis

Al parecer, Germán Arduino, y su compañía Arsol, y en colaboración con IGO Software (que proveen los recursos gráficos y audio), está desarrollando una aplicación multimedia sobre cultura y sitios históricos de Extremadura (España), para la Consejería de Cultura de la Junta de Extremadura (ciudad que apoya fuertemene el software libre, y usa Squeak para la educación)

Podéis la noticia más extendida (en inglés) en el blog de Germán.

Desde aquí, mi enhorabuena por el proyecto ;)

ShareThis

El otro día, en Yonkis, ví un mini artículo sobre un nuevo cubo de Rubik que han sacado, llamado Mirror Blocks. En él, se puede ver un video de su desembalaje, así como su funcionamiento.

Como hombre caprichoso que soy, y que nunca ha tenido un cubo de rubik, decídi buscar información sobre éstos “cacharritos”, y como no, el Sábado, me acerqué a Toys’r'us a comprarme un 3×3x3 como el de la imágen, que costó 15€ aproximadamente si no recuerdo mal.

En mi búsqueda de información, tropecé con la web Rubikaz, que casualmente, es de un paisano, donde tratan distintas soluciones a los distintos modelos, técnicas y demás parafernalias, además de tener un foro donde poder consultar y preguntar dudas. No creo que haga falta decir, si os registráis en sus foros, como en todas las comunidades, que uséis el buscador antes de hacer preguntas que seguramente ya estarán resueltas.

Quedé asombrado por lo grande que este mundillo (existe hasta una World Cube Association) y cantidad de información, enlaces que estudiar, distintas modalidades de torneos, cubos para montar tú mismo, etc..etc..etc….

De momento, gracias a Rubikaz y un par de videos que miré por YouTube, para aclarar conceptos, lo resolví una vez, y las otras siempre lo hacía todo bien a excepción de la última cara, aunque también es verdad, era porque confundí  (algo tan obvio) “arista” con “vertice” y siempre deshacía la última cara.

Ahora queda aprender bien la resolución para novatillos, y una vez esté controlada, pasar al modo experto para conseguir resolverlo en poco tiempo.

Algunos diréis que soy un gandúl por haber mirado soluciones antes de intentar resolverlo por mi mismo, y ahí, debo deciros, que tenéis toda la razón del mundo, pero es que mi cabeza no está para pensar tanto últimamente :P

P.D.: Es un maldito vicio el cubito de las narices. Es que no lo solté en toda la tarde, ahí, erre que erre con él. La verdad es que me hacía falta un vicio (que ya los tengo, pero otro más) fuera del ordenador…y del tabaco…y de las mujeres..que no me hacen caso……

ShareThis

Este tutorial está escrito por Fernando Arroba (a.k.a. Notxor)

INTRODUCCION

Esto es un tutorial sobre programación orientada a objetos. Su objetivo es que como me sugirió G.L. aprendamos a pensar en modo objetos. Hasta ahora, y por lo que me ha contado el amigo G.L., está acostumbrado a pensar en modo Delphi (tan pernicioso como el modo BASIC). Éste modo consiste en considerar que el fichero del formulario también es la clase del modelo; o dicho de otro modo, meten en el mismo saco el modelo, la vista y el controlador… Al final, una mala política de diseño que se traduce en sistemas que al crecer se hacen imposibles de gobernar.

Vamos a hacer un ejemplo, desde el principio. Partimos de la más absoluta ignorancia sobre el tema elegido. Ésto no es cierto del todo, siempre tenemos una idea aproximada de en qué consiste una tarea o el trabajo del vecino, pero debemos huir de estas ideas (llamémoslas prejuicios) para hacer un análisis correcto de lo que quiere el cliente o de en qué consiste la tarea que estamos analizando.

En un mensaje de nuestras conversaciones sobre lo humano y lo divino, G.L. me decía lo siguiente:

Uno de los problemas que yo veo es que los libros no reflejan casos reales. Me explico. Está muy bien que me digas que si en el shell de Ruby pongo 2+2 me devuelve 4, pero eso lo convierte en una calculadora costosa en memoria.

and so on.
“

PRIMERA APROXIMACION
No es mucha información, pero retomamos lo que tenemos hasta ahora y vamos planteando una posible solución. Esta solución es parcial (muy parcial, debido a la escasa información) pero ya nos permite el poder presentar a nuestro cliente un primer esquema sobre el que poder trabajar.

Lo primero que haremos será descubrir posibles clases que se dan en el ámbito de trabajo del que estamos hablando. Para ello, lo que suelo hacer es tomar esas pocas frases e ir subrayando los sustantivos.

Nuestro cliente (que dispone de distintas empresas o delegaciones de distintos servicios), requiere de una aplicación donde poder registrar todas las incidencias de sus clientes en las distintas empresas. Estas incidencias, deben ser asignadas a un técnico, el cual recibirá un correo con los detalles de ésta.

El gerente, solicitará al personal de administración correspondiente, los siguientes informes.
- Informes Incidencias realizadas dentro de un rango de fechas (completadas, en curso, facturadas etc..).
- Informes de productividad de técnicos.

En esta primera aproximación se ven los siguientes adjetivos… candidatos a formar nuestras clases:

• Empresa: aparece 4 veces.
• Cliente: aparece 3 veces.
• Hoja de trabajo: aparece 3 veces.
• Incidencia: aparece 3 veces.
• Informe: aparece 3 veces.
• Técnico: aparece 3 veces.
• Aplicación: aparece 1 vez.
• Correo: aparece 1 vez.
• Delegación: aparece 1 vez.
• Estado: aparece 1 vez.
• Factura: aparece 1 vez.
• Gerente: aparece 1 vez.
• Hora de trabajo: aparece 1 vez.
• Material: aparece 1 vez.
• Personal Admón.: aparece 1 vez.
• Servicio: aparece 1 vez.

¿Cómo se relacionan estas clases?
Lo primero que observamos es que podemos agregar conceptualmente esos sustantivos (candidatos a convertirse en clases) en distintos grupos. Por ejemplo, nos encontramos varios actores del sistema, como son los clientes, los técnicos, los administrativos, el gerente, todos ellos sustantivos que se refieren a personas que o bien interactuan con el sistema o bien deben realizar algún tipo de acción. En este apartado habrá que clarificar qué acciones llevan a cabo cada uno de esos actores. Por ejemplo, el cliente puede perdir un servicio de mantenimiento de forma telefónica, o rellenando un formulario web, o enviando un e-mail, o de cualquier otro modo. Por tanto, o el sistema es lo suficientemente flexible para admitir todos los modos o debemos indicar a los clientes cuál es el modo correcto de iniciar una incidencia. También debemos aclarar, y estos son sólo ejemplos, si el técnico debe rellenar algún tipo de documento en papel, o mediante la aplicación, o por sms, o por e-mail, o si se le pasa esa información o documento a algún administrativo que es el que lo hace. O por ejemplo, el gerente pide informes a la aplicación, o a los administrativos, o a los técnicos…

Por otro lado, también nos encontramos otro grupo de clases que podríamos llamar de documentación, como es la hoja de trabajo, los informes, la factura, el correo. Debemos aclarar quién genera la hoja de trabajo o la factura, de qué partes están compuestas, cómo se remiten, a quién se remiten, cómo se guardan…

El último grupo de clases es los que pueden ser, bien sinónimos de algún otro y que podrían entrar perfectamente en otro grupo, como es el servicio e incidencia, delegación y empresa, o bien forman parte de otra clase como es el estado. De este grupo hay que averiguar si efectivamente debemos tratar estos adjetivos como sinónimos o bien hay algún matiz con el suficiente peso para tratarlos por separado.

No hace falta decir que es una conversación con nuestro cliente el método más sencillo de averiguar todos estos datos. A dicha reunión conviene aportar cierta documentación que consistirá básicamente en devolverle al cliente información elaborada sobre la que él nos ha dado. Podemos aportar, por ejemplo el siguiente diagrama:

Click para ampliar

A aquellas personas que lean esto y tengan conocimientos previos de UML les resultará un gráfico demasiado simple. Es cierto, es muy simple, tanto que hasta nuestro cliente lo entendería (que es de lo que se trata). Habría que realizar un gráfico para cada relación que observemos en el texto. En el gráfico anterior propongo las dos más evidentes, pero hay más. Sin embargo, en la siguiente reunión me interesa hablar sobre todo de la estructura de administración de la empresa cliente y del proceso que sigue una incidencia desde que se informa hasta que se soluciona. Otros posibles temas para reuniones posteriores serían, por ejemplo, los presupuestos y facturaciones que deberá hacer el sistema.

En este punto, cabe aclarar que una de las fuentes de error más comunes es la semántica. En determinados ámbitos, las palabras tienen significados que no tienen porqué coincidir con lo que entendemos el resto de las personas y puede darse la situación de que empleando la misma palabra el analista y el cliente se estén refiriendo a conceptos totalmente distintos. Es recomendable que nos adecuemos al lenguaje que utiliza nuestro cliente y nos aseguremos que hemos comprendido correctamente el concepto tras él.

Este tutorial está escrito por Fernando Arroba (a.k.a. Notxor)

Nos vemos en la segunda parte ;)

ShareThis

Al lío. De esa conversación, surgieron un par de cuestiones, que se convirtieron en la decisión de Fernando, de hacer un tutorial de POO(u OOP, como más rabia os dé), , que si bien, es genérico, los ejemplos serán aplicados en código Ruby, aprovechando que estamos en su aprendizaje. Este tutorial, recreará un ejemplo pedido por un cliente, mostrando así el modelado de un sistema real y demás fases necesarias para su creación. Este “sistema real” será un software de control de incidencias.

Se recrearan hasta las preguntas que le haremos al cliente, así como las respuestas o dudas que éste pueda hacer, así como el modelado de los objetos, de la BBDD, o del GUI.

Puesto no quiero mezclar, lo postearé ahora en una nueva entrada.

Espero que sea de vuestro agrado, y esperamos vuestras críticas.

ShareThis

Según puedo leer en la lista de correo de Aida, la web de Squeak ha sido migrada de ¿smallwiki? a Aida/Scribo, a falta de unos pequeños retoques.

El diseño se mantiene (una lástima, porque a mi personalmente no me gusta, pero será el siguiente paso una vez finalizada la migración), pero el salto era algo necesario para el correcto mantenimiento de la web.

Scribo es un CMS construido sobre Aida que está cogiendo popularidad gracias a su sencillez, y la sencillez de Aida.

Enhorabuena a Janko y Nico por el gran trabajo que están realizando.

ShareThis

La idea tras SqueakSVN, es, ofrecer los beneficios de la programación colaborativa y control de versiones que ofrece SVN, sin salir de un entorno productivo como Squeak.

Monticello, si la memoria no me falla, y sin saber con exactitud como trabaja el nuevo Monticello 2, siempre guarda una copia comprimida completa del proyecto en cada commit.
SqueakSVN, mantiene un arbol, donde la clase es un directorio, que contiene a su vez un par de directorios más, class e instance, y a lo largo de esta jerarquía, guarda en archivos los métodos de instancia y clase, variables, etc… De ésta manera, podemos guardar (o cargar) sólamente la modificación de un método, o protocolo, sin tener que grabar (o cargar) el paquete completo.

Podéis ver un video explicativo de su funcionamiento, la mar de interesante, así como descargar el código fuente.

ShareThis

Por desgracia, no se puede descargar así como así a traves de iTunes por ejemplo. En la web de iSqueak, hay instrucciones para enviar por correo el UUID de tu iPhone/iPod y pedir una VM para tí, a no ser, que dispongas del SDK, y puedas tú mismo compilarlo.

Este proyecto, se llevó el tercer puesto en los ESUG Innovation Awards

Y yo sigo preguntándome. Para cuando una VM realmente funcional, y rapida, en PocketPC’s?

ShareThis

En este capítulo, secuestran a un integrante del equipo, Nick Stokes. En el lugar de los hechos, pegado a su chaleco, que encuentran en el suelo, detectan una fibra con olor a alcohol.

Reunidos en el laboratorio, Catherin (si no recuerdo mal), comenta que en la fibra, se detectan restos de Éter (usado para dormir al CSI desaparecido). Warrick, criticaba:
- Éter? Pero si eso ya no se usa.

A lo que Grissom contesta:
- Cada uno usa lo que sabe.

Como he dicho antes, no tiene nada que ver con el tema, pero mi mente enfermiza, asoció esa frase al mundo de la programación (no al sexo, mal pensados).

Como algunos sabrán, mi amigo Notxor y yo estuvimos un tiempo en una cruzada en la búsqueda del Santo Grial, y del entorno de programación perfecto. Pero, obviamente, ésto no existe.

¿Qué hace un lenguaje mejor que otro? Pregúntale a un programador habitual de Python, qué opina de programar en Ruby y viceversa. Pues independientemente, en mi humilde opinión (aunque para algunos pueda estar equivocada), a más del 85% de programadores, les sirve cualquier lenguaje a sus propósitos. Python, Ruby, VB, Cobol, C/C++, Object Pascal, Haskell, Erlang……

Practicamente, con cualquier lenguaje, puedes tener ODBC, RDBMS, librerías para uso de OpenGl, acceso a ficheros, desarrollo aplicaciones web (Cobol en este campo ya no lo sé), desarrollo de aplicaciones de escritorio, generación de informes, independientemente de su antigüedad (obviamente si continúa teniendo algún tipo de soporte o avance).

No todo lo nuevo es bueno, Ni lo bueno, tiene que ser nuevo. La experiencia, es un grado, y una de las máximas de la informática es, si funciona, no lo toques.

Qué es lo que PYloquesea o informesGEMS sea mejor que QReport de Delphi 7? y viceversa? Es mejor Python porque tiene PyGame? o porque es la moda? porque Delphi tiene GlScene con un desarrollo totalmente visual basado en componentes. (esto no es una guerra Delphi<>Python, es un ejemplo solo)

Lo que quiero decir, es, que a día de hoy, mucha gente (entre los que me incluyo) se dedica a probar y probar lenguajes nuevos cada vez, e incluso atreverse a criticar (no me incluyo, a veces :D) en el que desarrollan los demás.

La conclusión a la que quiero llegar, es sencilla. No podemos criticar a un programador, lenguaje, base de datos, porque haga las cosas de una u otra forma, o por su antigüedad, porque puede, que a su manera, haga grandes cosas. Se debe tener muy en cuenta la experiencia que el director en cuestión tenga sobre esa herramienta.

A mi, personalmente me gusta mucho Smalltalk, la gente le suena haber oído hablar de él, como algo viejuno. Es raro y distinto a todo lo demás, pero en cambio, es totalmente basado en objetos que se envían mensajes, puedes desarrollar juegos, librerías de creación de PDF, control de versiones, desarrollo web, servidor web propio empotrado, accesibilidad a todo el sistema. Es de los pocos lenguajes con Traits de serie, y continuations y mucho más. Es el lenguaje perfecto para una buena productividad (cambios a tiempo real sin necesidad de recompiláción) y es un lenguaje que lleva perfeccionándose desde hace 30 años, pero en cambio.

En fin, que siempre que hablo de Smalltalk me pierdo. La conclusión de este post de autoconvicción, es, que el mejor lenguaje de programación, el mejor entorno de desarrollo, es aquel en el que más cómodo te encuentres, y no siempre hace falta estar a lo que los demás dicen que es lo último, lo que dicen que es lo mejor, o lo que más se usa, porque nosotros ya sabemos qué es lo mejor, para nosotros mismos, y no nos lo tiene que decir nadie.

Cada uno usa lo que sabe.

ShareThis