viernes, 10 de julio de 2009

Cars and bytes

Imaginemos que te gusta conducir.

Imaginemos que tienes "pasta" para gastar en un coche. Hablamos de bastante "pasta".

Imaginemos que puedes decidir entre tres opciones:
  1. McLaren SLR. 650 caballos, 3,6 segundos de 0 a 100 Km/h.

  2. BMW M6. 507 caballos, 4,6 segundos de 0 a 100 Km/h.

  3. Aston Martin V8. 420 caballos, 4,9 segundos de 0 a 100Km/h.
De todos es conocida la marca McLaren, gasta millones anualmente en mantener un equipo de renombre en la F1. Además es un Mercedes, la máxima expresión de clase junto a la máxima potencia, y te da la imagen que quieres proyectar.


BMW es mundialmente conocida también y además goza de cierta imagen ventajosa en un sector importante de la sociedad. No es tan potente ni tan rápido, pero a las mujeres les encanta.

En cambio el Aston Martin, aunque conocido en los círculos de adictos al motor y con renombre entre los entendidos, de cara al público en general no es todo lo que quizás desearías de una inversión como esa.

Con los datos que tenemos la decisión está clara: McLaren SLR.

Pero resulta que, además de ser bastante más caro de principio, el mantenimiento del cacharro es brutal, y el consumo no te cuento...

Bueno..., quizás el BMW M6.

Tiene potencia, es rápido, ligas que no veas..., pero cuando lo pruebas te das cuenta de que por encima de 160Km/h las sensaciones no son Uffff!!!

Le falta algo que no sabrías decir muy bien qué es, pero que está ahí y te deja ese sabor de boca extraño.

Además, tiene tanta tecnología punta integrada que sólo para ponerlo en marcha y elegir la modalidad de conducción deportiva en el ordenador de a bordo tardas más de tres minutos, tiempo en el que cualquiera de los otros dos rivales ya está a varios kilómetros de distancia.

Bien, pues entonces sólo me queda el Aston Martin V8.

No es tan potente como los otros, no tiene la misma aceleración, ni te da la misma imagen porque para la gran mayoría es desconocido.

Pero tiene algo que no tienen los demás: los caballos que tiene los entrega de una forma salvaje desde el principio, si le pisas a fondo yendo a 160Km/h te oyen en tres kilómetros a la redonda, y para disfrutar de todo eso sólo has de poner la llave en el contacto y pisar el acelerador.

Así de simple.

Te gusta conducir?

Life is soft!!!

domingo, 5 de julio de 2009

Plantillas V6

Las plantillas empresariales V6 son aplicaciones básicas funcionales, punto de partida para cualquier personalización a realizar a un cliente.

Seguro que a ningún cliente le viene bien una plantilla tal cual, pero nuestro trabajo es precisamente adaptarla a sus necesidades.

Una plantilla empresarial V6 es como una moto GP; corre y es buena, pero hay que hacer la puesta a punto para cada carrera en cada circuito.


No hay dos circuitos iguales, como no hay dos clientes con las mismas necesidades.

Las plantillas empresariales V6 son un buen punto de partida para cualquier circuito, ya que lo que hacen lo hacen bien. Ahora, si para este circuito necesito correr más en recta, deberé adaptarla plantilla para eso, o si lo que necesito es más tracción en la salida de las curvas, deberé adaptar la plantilla nuevamente.

Las plantillas no son soluciones finales (ójala encuentres el cliente cuya problemática sea resuelta por la plantilla; instalar y cobrar), si no un buen punto de partida para cualquier personalización posible.

Lo primero que os van a pedir los clientes sobre las plantillas es la adaptación a multiempresa, multialmacén, tallas y colores, números de serie, etc.

Si tomamos como punto de partida las plantillas empresariales Velneo V6, gran parte del trabajo ya lo tenemos hecho, y el resto está explicado en los vídeos de tu zona Velneo directo.

Life is soft!!

sábado, 4 de julio de 2009

Copia de seguridad remota


Hace más de un año comenté cómo planeaba y ejecutaba las copias de seguridad en el vServer.

Dije además que enviaba las copias de seguridad a otros servidores remotos para salvaguardar la información de una forma más efectiva, hoy veremos cómo.

Supongamos el caso más sencillo; un vServer y una sola aplicación.

Supongamos también que en el servidor hemos programado una sola tarea de copia de seguridad de la aplicación que cada día a la misma hora machaca la copia del día anterior.

Para acabar de definir el escenario necesitaremos otro vServer en otro lugar que llamaremos remoto, con un recurso compartido (nombre asignado a una carpeta física en disco) al que tiene acceso y control total el usuario SDV.

Ya lo tenemos todo.

Veamos cómo conseguir que nuestra copia de seguridad diaria se copie también en el equipo remoto.

Soy muy amigo de las tablas de configuración y suelo tener en cada aplicación una tabla CFG con un sólo registro conteniendo datos redundantes como la ip-pública del servidor donde publico la aplicación, alias que le pongo a la aplicación, nombre del usuario SDV, su contraseña, etc. Siempre viene bien poder tenerlos a mano dentro de algún proceso y así parametrizo el proceso usando los datos de CFG en vez de tenerlos declarados dentro del proceso. Es mejor cambiar datos de una tabla que editar el proceso si alguno de estos datos cambian.

Así pues declaro una tabla CFG con los siguientes campos: ip pública del servidor remoto, nombre del usuario sdv remoto, contraseña del usuario sdv, nombre del recurso compartido remoto (donde voy a guardar la copia de seguridad remota), y senda completa (senda, nombre y extensión) del archivo vcs que voy a mandar.

Si estos datos suelen ser siempre los mismos, incluso podemos ponerlos como contenido inicial de los campos, en el proceso ONINIT-MAP-SERVER cargamos la tabla CFG por el índice Código, vemos si no hay registros (if !n) y hacemos un Alta directa en la tabla CFG.

Si la tabla CFG es de un sólo registro, para su edición lanzamos un proceso que carga la tabla CFG por el índice Código, selecciona ficha por posición 1, lee la ficha seleccionada y añade como retorno el formulario de edición de la tabla.

Para capturar la senda completa del archivo vcs que voy a mandar uso un proceso como el siguiente:


El proceso con origen una ficha de la tabla CFG, presenta el diálogo para seleccionar un fichero, si aceptan el diálogo y han indicado una ruta, me la guardo ( fAjustaSenda convierte las barras \ en dobles barras \\ ).

Como vamos a enviar periódicamente información entre servidores preparo una tabla de ENVIOS. En esta tabla anotaremos los datos de cada envío; servidor remoto a donde se envía, usuario y contraseña que usamos para ello, fecha y hora del envío, y su resultado como booleano, así como la fecha y hora de finalización para controlar cuánto tardamos.

Ahora sólo queda hacer un proceso no-privado para poder programarlo como tarea en vServer.

En este proceso sin origen cargamos la tabla CFG para tomar los datos que necesitamos del registro 1; ip pública del servidor remoto, nombre del usuario sdv, su contraseña, carpeta remota donde hacer el envío, y de la senda del archivo a enviar nos quedamos con su nombre y extensión (fExtraerNombreExtDeSenda) que luego usaremos añadiéndole un prefijo.

A continuación en el proceso damos un Alta directa en la tabla ENVIOS, anotando en el Pre los datos necesarios, y quedándonos en el Post con el Código del registro de envío.

Preparo además una variable local fecha para guardar la Fecha del envío formateada AAMMDD para añadirla como prefijo al nombre y extensión del archivo que mandamos en el servidor remoto, así no machacaré las copias de seguridad del servidor remoto cada día, si no que las iré guardando todas, todas, todas, con su fecha en el nombre.

Sólo queda componer en el proceso la vrl-destino, es decir, en qué carpeta del servidor remoto vamos a guardar y con qué nombre la copia de seguridad, en qué servidor y con qué usuario y contraseña, mandarlo, y en función del resultado apuntarlo en la tabla ENVIOS.

Y eso es todo amigos.

Sólo queda programar como tarea en el servidor este proceso para que se ejecute cada día tras la copia de seguridad y ya está. Nuestros datos doblemente a buen resguardo.

Os propondría variaciones sobre el tema como tener varios registros en la tabla de configuración, es decir, distintos servidores a los que mandar la copia, o bien todos los días a todos, o cada día a uno, e incluso mandar copias de diferentes carpetas origen (lunes, martes, miércoles, etc...).

Usando una táctica similar se puede mandar también el mapa relativo a la copia de seguridad, archivos de configuración de vServer, etc.

Life is soft!

jueves, 2 de julio de 2009

Velneo V7, la herramienta

Hace mucho tiempo que la V7 de Velneo está disponible, al principio como betas privadas para niveles 4, y finalmente como betas públicas que todos podemos disfrutar, pero hasta ahora no había dicho nada respecto de la herramienta. Por qué?

Soy desarrollador Velneo especializado en web, y los clientes de Gestión que atiendo resuelven su problemática con V6.

Mi tiempo "profesional" (en mi trabajo) lo sigo dedicando 250% a desarrollos V6 que es lo que nos funciona y da de comer.

Mi tiempo "libre" (mis noches en vela) lo sigo dedicando al I+D radical y a la web.

Como V7 de momento no sirve web, ni con el módulo para Apache, ni con un servidor web propio Velneo como hace V6, pues tampoco le dedico el tiempo necesario.

De todas formas, como nivel 4, he podido asistir a los diferentes seminarios y tallerres de V7, y he podido ir probando las diferentes betas privadas que se han publicado.

En sus primeras betas privadas V7 me pareció conceptualmente impecable y tangiblemente inoperante, ya que, comparandola con V6 era un paso atrás. Era como si de un entorno totalmente asistido para el programador pasásemos a un entorno totalmente espartano donde el programador debía volver a tener que hacerlo todo manualmente; instancias de cajas en el servidor, formularios, rejillas, etc...

Las espectativas eran muy buenas, ya que el concepto de caja y herencia brindan unas posibilidades espectaculares, pero en la realidad faltaba mucho de lo que ya estábamos acostumbrados a disfrutar en V6; facilidad y rapidez de desarrollo.

Además, mi gozo en un pozo, dejaba de servir web, no había funciones remotas, el refreco secundario no estaba implementado, etc...

Con la apertura al público de las betas, la herramienta ha ido madurando poco a poco e incorporando nuevas posibilidades; informes, asistentes, nuevos objetos visuales, docks, layouts, etc.

Una de las últimas incorporaciones me vino al pelo: funciones remotas, además funcionan entre V6 y V7.

Esto me posibilitaba hacer web en V7 de la siguiente forma; bd en V7 y web en V6, comunicación de ambas mediante funciones remotas, y a servir.

Otra de las posibilidades era usar el vWebClient integrado en un navegador web, pero el problema es que consume licencias concurrentes.

De todas formas seguiré esperando nuevas betas de V7 con la esperanza de volver a tener un servidor web Velneo propio, ni con Apache ni con nada intermedio.

Si además se soluciona el refresco secundario y algún que otro fleco, creo que ya estaría en disposición de poder acometer un desarrollo comercial en V7, ya que a falta de eso, las pruebas de rendimiento en remoto son muy satisfactorias gracias al protocolo VATP mejorado y los sockets envolventes.

Si ya podemos licenciar V7 y desarrollar al menos al nivel acostumbrado (y mejor en muchos otros aspectos) de V6, ya podemos vender aplicaciones V7.

Si se cumplen estas condiciones ya podré decir que Velneo V7 es la herramienta.


Ferrari California
Life is soft!