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!!!

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!!

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!

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.



Life is soft!

Malas prácticas empresariales

A lo largo de los años he ido conociendo a muchos vDesarrolladores, y un perfil típico de desarrollador Velneo ha venido siendo lo que yo denominaba "tirador solitario".

Un tirador solitario suele ser un desarrollador sin estudios específicos sobre programación, emprendedor, muy trabajador y autodidacta.

Este perfil tiende a, por su propia naturaleza, trabajar para sí mismo como autónomo o a formar su propio proyecto empresarial.

Estudiando los peligros a que un emprendedor se enfrenta en sus primeras experiencias como empresario incipiente, he encontrado unos casos que me gustaría compartir con vosotros; las malas prácticas empresariales.

Una mala práctica empresarial es una actuación de una empresa que va contra la ética o la moral, y podemos citar como ejemplos las siguientes:

Prácticas engañosas

Pueden ser desde una promoción de venta donde no se especifican con claridad los requisitos para poder disfrutar de ella, hasta el anuncio del precio de un producto o servicio sin mencionar costes adicionales inherentes al mismo.

Productos de mala calidad

Este caso puede darse incluso con productos que a primera vista cumplen los requisitos esperados, pero que cuando son analizados más a fondo o se hace uso de ellos ponen de manifiesto sus carencias básicas.

Información falsa

En este caso una empresa publicita un producto indicando características que en realidad no posee.

Promesas no cumplidas

Como cuando una empresa llega a un acuerdo con sus clientes para entregar un producto en una fecha determinada, sabiendo o no si podrá cumplir los plazos, y llegada la ocasión no cumple.

Venta bajo presión

Cuando el departamento comercial de una empresa, con el fin de vender un producto o servicio a cualquier precio, presiona y prácticamente obliga a comprarlo, insistiendo contínuamente para que se realice la compra, incluso mintiendo al decir que es una oferta especial, que está a punto de agotarse el producto o el plazo de compra, o que hay otros interesados en el mismo.

Publicidad no solicitada

El típico spam, bombardeo de correos electrónicos o llamadas telefónicas no deseadas.

Discriminación

Se da cuando una empresa discrimina a algunos clientes por pertenecer a una categoría diferente a la de los clientes habituales de la misma.

Injerencia interempresarial

Incluso hay casos en los que una empresa no dudará en intentar fichar algunos elementos clave de otras organizaciones, o intentará a través de coacción y amenazas, forzar la política de gestión de otras empresas en su propio beneficio.

Si eres emprendedor o estás pensando en serlo, ten cuidado con los tiburones e intenta tener presentes estas malas prácticas empresariales para saber reconocerlas a tiempo, poder evitarlas o actuar legalmente contra ellas si se dan.

Un saludo,

El principio de Peter

Cada día que pasa estoy más de acuerdo con el principio de Peter que dice algo así como:

Un indivíduo dentro de una organización empresarial tiende a ocupar el puesto donde su ineptitud se ve maximizada

Un saludo,

XHTML(ii)

Siguiendo con nuestra introducción al mundo XHTML, veremos hoy un elemento importante e imprescindible en el mundo del hipertexto; los hiperenlaces.

Los hiperenlaces conviven con nuestros documentos en la red desde sus inicios ya que son parte fundamental de su finalidad: enlazar recursos en la red; páginas, documentos, archivos, etc.

Antes de intentar comprender la esructura formal de los enlaces en la web, debemos entender el concepto URL (identificador único de recurso).

Una URL digamos que es la clave única en la red para acceder a un recurso, como por ejemplo una imagen alojada en nuestro servidor.

Está compuesta por tres partes:

• Protocolo. Normalmente http://, o https:// para los entornos seguros, o ftp://, etc.
• Servidor. Nombre de dominio o ip pública del servidor que sirve el recurso, como por ejemplo velneo.es
• Ruta. Ruta interna al servidor que lleva hasta el recurso compartido y servido, como por ejemplo /cgi-vel/alias-aplicacion/imagen.jpg para un archivo imagen.jpg dentro de la carpeta raiz de la aplicación con ese alias servida por un vServer.

Existen dos tipos de url: absoluta y relativa.

Una url absoluta contiene las tres partes comentadas; protocolo, servidor y ruta.

Una url relativa prescinde de alguna de las partes anteriores. Por ejemplo, si ya estamos en el documento http://midominio.com/cgi-vel/alias-aplicacion/index.pro, para acceder al proceso portada.pro de la misma aplicación, la url podría ser simplemente portada.pro en lugar de http://midominio.com/cgi-vel/alias-aplicacion/portada.pro

Xhtml define toda una serie de reglas para acceder por ruta relativa a recusos compartidos: si el origen del enlace y el destino se encuentran en el mismo directorio, si el destino se encuentra en el nivel superior, en un nivel inferior, muy lejos, etc, pero como nosotros trabajamos en Velneo, nuestras páginas web siempre van a tener una ruta relativa: proceso-destino.pro, ya que nuestras páginas xhtml siempre las vamos a componer por proceso.

Veamos pues como es un elemento enlace.

ENLACE (<a></a>)

Un enlace es un elemento en línea y dispone de los siguientes atributos, entre otros:

• name, para poder referirnos a un enlace por su nombre único.
• href, para indicar la url del recurso enlazado.
• type, para indicar al navegador sobre el tipo de elemento enlazado; imagen (image/gif), documento (text/css o application/rss+xml), etc.
• rel, para indicar la relación entre el documento actual y el enlazado, muy útil a la hora de indicar a Google si debe seguir e indexar el contenido enlazado o no.
• hreflang, para indicar el idioma del recurso enlazado (es-ES para español de españa, o es-AR para español de Argentina, por ejemplo).
• charset, para la codificación del recurso enlazado (utf-8 o iso-8859-1, por ejemplo).

Veamos algunas aplicaciones de estos atributos.

El atributo name se suele utilizar para lo que se conoce como "anclas" o "anchors".

Si tenemos un enlace del tipo <a name="punto1"></a> dentro de un documento podemos generar un enlace a él de la siguiente forma <a href="#punto1"></a>, como por ejemplo para acceder desde una tabla de contenidos al principio de una página "larga" hasta el Punto 1 dentro de la misma página.

Si el origen del enlace está en la página index.pro, por ejemplo, y el destino está en la página faq.pro en el ancla con name="faq1", el enlace sería <a href="faq.pro#faq1"></a>.

El atributo rel se suele utilizar por ejemplo para decirle al robot de Google si debe seguir un enlace e indexar el contenido del documento enlazado, cuestión muy importante en el trabajo SEO de una web.

Si indicamos el atributo rel="noindex, nofollow", le estamos diciendo al robot de Google que no siga el enlace y que no indexe el contenido del documento enlazado, tema muy interesante si no queremos que páginas "inútiles" como el contactar o condiciones de servicio resten importancia al resto de páginas de nuestra web con contenidos frescos e interesantes que sí queremos que Google indexe.

Dentro de la cabecera de nuestro documento encontraremos unos tipos de enlaces especiales como por ejemplo:

• <link rel="stylesheet" type="text/css" href="/css/estilo.css" />, para hacer referencia a la hoja de estilos css que se utiliza para renderizar el documento xhtml
• <link rel="shortcut icon" href="/favicon.ico" type="image/ico" />, para hacer referencia al icono de nuestra página web que se mostrará en la barra de direcciones del navegador web o en el enlace al ser añadido a favoritos.
• <link rel="alternate" type="application/rss+xml" title="Canal RSS" href="/feed.xml" />, para hacer referencia al documento xml donde publicamos periodicamente las actualizaciones de nuestra web.
• <script type="text/javascript" src="/js/javascript.js"></script>, para hacer referencia al archivo que contiene la definición de las funciones javascript que usaremos en nuestro documento.

Me gustaría comentar un par de tipos de enlace cuyo uso está desaconsejado:

• Los enlaces <a href="mailto:cuenta@dominio.com">correo</a>, que abren el programa asociado en el equipo al envío de correo electrónico y componen un nuevo correo indicando en el Para, la dirección indicada. Su uso está desaconsejado debido al mal uso de la web de robots malintencionados que recolectan emails que aparecen en webs y los inundan de spam, y más desaconsejado está el intento de incluir el Asunto del mensaje o parte del contenido, pasando los parámetros subject o body en el enlace, ya que esto es una violación de seguridad.
• Los enlaces por javascript. Un enlace sin destino y con un comportamiento onclick que abra una url no es un enlace. Un usuario normal puede tener dificultades para seguirlo, y no digamos un usuario ciego como Google que no ve el javascript asociado ni el enlace compuesto en la función.

Y hoy hasta aquí. En la próxima entrega seguiremos con las Listas, un elemento muy, muy, muy útil para menús de navegación usando un poco de css.

Hasta entonces,

Life is soft!

vTerminator

Esta tarde he asistido al seminario de novedades de V7 y he podido ver el nuevo sistema de licenciamiento de vServerV7: vActivator.

Con vActivator puedes comprar puestos para tus vServers V7.

Aprovecho la ocasión para anunciar el próximo lanzamiento al mercado mi primera aplicación V7: vTerminator.

En estos tiempos de crisis, donde lo más normal es que tengas un impagado de algún cliente en mantenimiento que sigue haciendo uso de sus licencias de acceso a vServer, vTerminator es la aplicación que velará por tu economía.

vTerminator vigila los impagados de clientes, y con la lógica de los booleanos (ha_pagado = si/no) y el uso de las funciones remotas, desactiva las licencias de los clientes que no pagan y los deja sin servicio.

Ta, tan, Ta, tan, ta, tan!!!

Volveré!

Próximamente en Velneo OpenApps.

Cumpleaños, Picadillos y Seguridad web

Hasta ahora un problema recursivo de Velneo en la web son los formularios por método post, de no ser que hagas uso intensivo del plugin vPost para su envío.

Los problemas que he ido encontrando a lo largo de los años han sido: el proxy-caché de Telefónica, los antivirus que trastean con los paquetes TCP de forma "transparente", y últimamente el navegador Opera.

Las soluciones hasta ahora eran obvias: que no te mienta tu proveedor de internet y que tu antivirus "transparente" lo sea de verdad, pero para Opera no he encontrado solución sin utilizar vPost.

Con vPost y Opera aún experimento algunos problemas pero estoy en ello.

Como al parecer era un problema de protocolo me instalé un analizador de tráfico de red para poder ver los paquetes que viajaban entre el navegador Opera y el vServer. Analizando los paquetes pude ver que el navegador sí envía la información por post al vServer, pero usando el protocolo http1.1 en lugar del http1.0 que es el que soporta vServer.

El problema parece estar ahí y la solución debe ser vPost.

Ya que estaba mirando paquetes, vi que el formulario (nombre de usuario y contraseña) estaba mandando la contraseña como texto plano en el paquete, ya que no estaba en una conexión segura https.

Si necesitamos un entorno seguro lo que debemos hacer es montar un Apache intermedio haciendo proxy inverso delante del vServer.

Una buena solución para evitar que las contraseñas se manden en plano es encriptar la contraseña en el cliente con javascript antes de hacer el envío del formulario. En el servidor comparamos la contraseña encriptada recibida con la guardada en la base de datos y validamos.

Para ello tenemos dos opciones en la base de datos: guardar la contraseña encriptada, o guardarla como texto plano.

Por razones de seguridad; si alguien obtiene acceso indebido al servidor y a las tablas de datos, o entra un ladrón a la oficina y se lleva el disco duro, deberíamos guardar siempre las contraseñas encriptadas en la base de datos ya que así, aunque obtengan las contraseñas no podrán usarlas por estar encriptadas y no haber vuelta atrás.

Llegados a este punto mi principal preocupación pasa a ser la posible vuelta atras: es posible desencriptar las contraseñas?

Los algoritmos de encriptación suelen basarse en obtener resúmenes, hash o "picadillos" de la cadena original.

Usando algoritmos estandard de encriptación como md5 o sha, en teoría no es posible, aunque estos algoritmos presentan un problema: como su dominio es infinito (las posibles cadenas a encriptar) y su resultado sí es finito (cadenas de n bits de longitud) tienen posibles colisiones.

Una colisión es encontrar dos cadenas que encriptadas tengan el mismo resumen.

Es fácil encontrar una colisión?

En principio no es fácil, pero en los últimos años hay ejemplos publicados de colisiones md5; dos pdf's diferentes con el mismo md5, o incluso un equipo chino que dice hallar colisiones sha en tiempos muy inferiores a los estimados en teoría.

Para encontrar colisiones se usan tablas rainbow que son gigantescas tablas de cadenas originales con su hash, resumidas y vueltas a encriptar, resumidas de nuevo y vueltas a encriptar, etc.

La búsqueda de hashes de forma recursiva sobre estas tablas permite la obtención de colisiones en tiempos muy inferiores a la fuerza bruta.

Qué ocurre si encontramos colisiones? Que el algoritmo de encriptación queda debilitado y su uso para fines seguros queda en entredicho.

Ahora, no es lo mismo buscar dos cadenas cualquiera que tengan el mismo hash, que buscar otra cadena que tenga el mismo hash que una dada.

Aquí es donde entra a jugar el cumpleaños.

Cuál es el número mínimo de personas que deben reunirse en una habitación para que la probabilidad de que dos de ellas cumplan años el mismo día sea mayor del 50%?

Si definimos probabilidad de que suceda algo como el número de casos favorables dividido por el número de casos posibles, y si definimos como probabilidad del caso contrario como 1 - p, siendo p la probabilidad del caso positivo, preguntémonos cuál es la probabilidad de que las personas reunidas en una habitación no cumplan años el mismo día.

Para la primera persona la probabilidad sería 365 días posibles entre 365 días disponibles.

Para la segunda persona la probabilidad sería de 365 - 1 días posibles (los 365 del año menos la fecha del cumpleaños de la primera) entre 365 días posibles.

Para la tercera sería 365 - 2 entre 365, etc. Es decir,

p = (365/365) * ((365 - 1)/365) * ((365 - 2)/365)* ... * ((365 - n + 1)/365)

o sea,

p = (365!)/((365^n)*((365 - n)!))

Así pues, la probabilidad de que dadas n personas reunidas en una habitación, dos de ellas cumplan años el mismo día es 1 - p, y con n=22 ya obtenemos una probabilidad del 50,7%

Para 30 personas la probabilidad es más del 70%, para 40 casi del 90% y para 60 más del 99%

La probabilidad de que dada una persona en el grupo hallar otra que cumpla años el mismo día es mucho menor,

p = 1 - ((364/365)^n)

Necesitaríamos un grupo de 253 personas para que esa probabilidad sea mayor del 50%

Así las cosas, para una función criptográfica de 128 bits, para encontrar una cadena que tuviese el mismo hash que otra deberíamos probar 2^128 valores, pero para encontrar dos cadenas cualquiera que diesen el mismo hash sólo deberíamos probar 2^64 valores.

Son números grandes, pero a día de hoy, con los medios tecnológicos disponibles; PS3, portátiles más potentes que mi equipo de sobremesa para desarrollo, el cloud-computing, la computación distribuida, redes p2p, no sería descabellado dedicar ciertos esfuerzos a romper esas contraseñas si la información reservada que hay detrás puede suponer mucho, mucho, mucho dinero.

Tras tener todo esto en cuenta decidí que si la información que guardo detrás del formulario de nombre de usuario y contraseña por método post fuese lo suficientemente sensible y crítica, la guardaría en un entorno seguro https, pero como no es así no voy a hacer nada.

Además, quién va a querer perder el tiempo para obtener esa información y qué le va a aportar?

Nadie y nada.

Un saludo,

Estándares web

Mis inicios como desarrollador web fueron bastante penosos: terminaba mis estudios de ingeniería en la universidad, vivía entre casa de mis padres y el piso compartido de estudiantes de mi novia y sus compañeras, y curraba en una "empresa" haciendo lo necesario; Photoshop, 3dStudio, Premier, AutoCad...

La "empresa" se llamaba Valenciana de Servicios Completos. Os podéis imaginar que hacíamos prácticamente cualquier cosa que se pudiera vender (no penséis mal, no tan completos...).

Así que cuando mi jefe me dijo: "Ahora vas a hacer webs. Aquí tienes un libro (era algo así como html para torpes) y aquí el programa para hacerlas (FrontPage). Al tajo!", pues me puse a ello.

Por cómo me habían modelado el cerebro en la universidad, cabezón y cuadriculado, la forma de hacer webs de la herramienta me venía al pelo: tablas para la maquetación, tablas para texto, tablas para imágenes, para espacios en blanco, para contener botones y menús, para contener tablas que a su vez contenían más tablas...

Usando esa táctica constructiva desarrollé muchísimas webs durante muchos años, y cobraba por ello.

A lo largo de esos años intenté formarme continuamente; hice cursos de Flash, de DreamWeaver, de ASP, y básicamente me autoformé leyendo sin cesar libros y páginas y más páginas en internet sobre el tema web (aún no existían los blogs!!!).

Al principio las webs eran poco más que texto e imágenes gif, luego la cosa se fue complicando con javascript, actionscript, frames, sonido, animaciones, vídeo, etc, y a la vez crecían en tamaño y complejidad.

Por entonces ya sentía que algo no andaba bien, ya que trabajar en webs grandes utilizando plantillas de página que se repetían en cada página no me parecía una forma eficiente de realizar el trabajo, y menos de mantenerlo, ya que cada cambio de diseño implicaba recorrer todas y cada una de las páginas para aplicarlo. Las plantillas no eran dinámicas.

El descubrir DreamWeaver MX que podía conectar la web a una base de datos supuso un gran avance en este aspecto, ya que con una página base podía mostrar infinitas páginas tirando de tablas de la bd.

Por aquel entonces empecé a conocer algo que llamaban CSS y básicamente servía para definir tipos de letra, tamaños y colores en un archivo único externo que permitía mantener esos aspectos de forma muy cómoda, pero eso sólo era la cáscara superficial.

El día que descubrí el modelo de cajas y el posicionamiento por CSS cambió mi vida: eso era!. Mi sentimiento inicial había encontrado la respuesta definitiva.

Lo tenía todo:

• una base de datos para proporcionarme los contenidos
• una forma de estructurar esos contenidos (html)
• una forma de mostrarlos (el css)

Ahora sólo faltaba comprender y dominar el css, la herramienta definitiva.

Desde entonces llevo estudiando todos y cada uno de los días css sin parar.

Qué tiene que ver esto con los estándares web? Creo que bastante.

Los estándares web los dictan una comisiones de expertos del World Wide Web Consortium (W3C), y cuando digo expertos quiero decir expertos: son los autores originales de la web y sus alumnos aventajados, la gente que inventó y diseñó los protocolos de comunicaciones de redes, la gente que inventó internet, los lenguajes que organizan la información en la web.

Ellos estudian y dicen (recomiendan) cómo es y cómo será la web, dicen cómo hay que construir los navegadores de internet para que puedan leer e interpretar correctamente la información que se transmite por la red.

Crean estándares que todos deberíamos utilizar y respetar: tú, yo, el vecino, Internet Explorer, Firefox, Opera...

Lo que al principio son recomendaciones, terminan siendo al final estándares que aplican los desarrolladores de software para internet, y si desarrollas webs sería muy interesante conocer esas recomendaciones y aplicarlas para que así tus contenidos web puedan ser mostrados en la mayoría de navegadores web y llegar a más y más gente.

El aplicar estándares al desarrollo web tiene muchas ventajas, la primera es la eficiencia: los estándares recomiendan separar el contenido (html) de la forma (css) y los comportamientos (javascript), y el tener organizadas de esta forma las cosas te permitirá reutilizar mucho código, y así aumentar tu eficiencia.

La segunda ventaja es la facilidad de mantenimiento. Teniendo así separadas las cosas es muy fácil hacer un cambio global en toda la web tocando sólo el css o la estructura html.

La tercera gran ventaja es la compatibilidad con diferentes dispositivos. Usando estándares es mucho más fácil hacer que mi web sea accesible a diferentes navegadores en diferentes sistemas operativos y diferentes dispositivos; pc's, teléfonos móviles, pda's, etc.

La cuarta ventaja yo la consideraría casi como una verdadera obligación por parte de todos y cada uno de nosotros: accesibilidad.

La Constitución Española no lo dice así pero casi: nadie será discriminado por su condición. Así que no hacer una web accesible a todos debería ser casi considerado como un ejercicio de irresponsabilidad democrática.

Hay gente que no puede dominar un ratón, así que porqué no facilitarle la navegación a través del teclado? Hay gente con dificultades visuales, así que porqué no proporcionar contenido alternativo textual que explique las imágenes, las tablas, los menús? Hay gente que no puede ver tu web y usa lectores de voz para ello, así que porqué no facilitarles el acceso a tus contenidos?

Hay gente que navega sin javascript activado, sin poder reproducir flash, sin css. Piensa en los teléfonos móviles.

Decirle a un usuario "Este sitio usa frames y tu navegador no los soporta" o "Este sitio está diseñado para 1024x768" es casi como decirle a alguien "Lo siento, con silla de ruedas no pasas".

Si todo esto no te convence, seguro que hay un usuario ciego al que no le quieres negar la entrada a tu sitio web: Google.

Piensa en cómo "ve" Google tu sitio y te darás cuenta de que es ciego. No quieres hacer tus contenidos accesibles a Google? Seguro que sí. Pues los estándares web nos ayudan a hacer nuestros sitios accesibles a más usuarios.

La última ventaja de usar estándares es que es mucho más fácil aplicar técnicas SEO (optimización para motores de búsqueda) a nuestros sitios con todas las ventajas que ello conlleva.

A pesar de todas estas ventajas habrá gente que quiera argumentar:

• No tengo medios. Falso! En internet hay miles de sitios ofreciendo recursos formativos gratuitos de la mejor calidad.
• Es por la política de empresa. Mal vamos si la empresa no quiere llegar a cada vez más usuarios.
• No lo necesito, sigo haciendo las cosas como siempre y me siguen pagando. No quieres ser más eficiente? No quieres facilitarte el mantenimiento de tus sitios web? No quieres ganar lo mismo en menos tiempo? No quieres ganar más en el mismo tiempo? Afortunadamente ya hay muchas empresas buscando desarrolladores web formados en estándares. Te quieres cerrar las puertas?
• Los navegadores web no soportan los estándares. Ese tiempo ya pasó. Afortunadamente todos los navegadores soportan cada vez en mayor medida los estándares.

Llegados a este punto espero haber conseguido explicar la importancia de los estándares, su uso y ventajas, y espero haber despertado ese gusanillo en vosotros para que empecéis a aprender y aplicar estándares web en vuestros desarrollos.

Un saludo,

XHTML (i)

Antes de intentar cosas complejas en el entorno web deberíamos preocuparnos de entender mínimamente las bases del lenguaje que vamos a utilizar para desarrollar documentos web, así que vamos a comenzar por entender el XHTML y sus peculiaridades.

La primera duda que nos puede surgir al intentar desarrollar algo en web es; "HTML o XHTML?"

Veamos las diferencias.

Tanto uno como otro surgen del SGML; HTML es "hijo" de SGML y XHTML es "nieto" de SGML, ya que su "padre" es XML, este sí, descendiente directo de SGML.

Vemos entonces que son de la misma familia, pero que cada uno pertenece a una rama diferente y por tanto tiene sus características y peculiaridades diferentes y específicas.

Ambos son lenguajes de "etiquetas" (tags) pero sus reglas no son las mismas; HTML es mucho más relajado en cuanto a normativa sintáctica y nos permite hacer cosas mal, pero XHTML hereda de su "padre" XML una cierta manía "formal" e impide hacer mal muchas cosas que HTML permite.

La principal diferencia entre ambos lenguajes es la siguiente; XHTML separa el contenido de la forma y HTML no lo hace.

En XHTML definimos los contenidos, la forma se la dará el CSS aplicado, mientras que en HTML la forma y el contenido están mezcladas de forma confusa e inconsistente.

Esta es la principal característica que nos hará decidirnos por un lenguaje u otro; necesito generar contenidos dinámicos independientes de la forma, o me da igual?

HTML incluye entre sus etiquetas muchas destinadas a dar forma a sus contenidos; fuente, tamaño, negrita, cursiva, etc.

XHTML sustituye esas etiquetas por otras destinadas a dar sentido a sus contenidos; titular, subtitular, destacado, etc.

Es una aproximación muy diferente: en el caso del XHTML decimos si un contenido es un titular, subtitular, cuerpo normal, si debe ser destacado, etc, mientras que en HTML estamos diciendo que ese contenido va en fuente Arial Negrita de 14, en Cursiva, etc. Es muy diferente.

Al diseñar en HTML estamos mezclando conceptos; los contenidos y su representación, mientras que al diseñar en XHTML dividimos el problema en dos partes muy diferenciadas, por una parte definimos los contenidos y su significado, y por otra parte definimos su representación (CSS).

Nosotros, como diseñadores de soluciones Velneo, contamos con la misma dicotomía en nuestro sistema; por una parte la bd (contenidos), y por otra la apariencia (objetos visuales), así que adoptaremos XHTML + CSS como nuestro modelo de desarrollo web.

Las etiquetas (tags) que vamos a poder utilizar son las siguientes:

a, abbr, acronym, address, applet, area, b, base, basefont, bdo, big, blockquote, body, br, button, caption, center, cite, code, col, colgroup, dd, del, dfn, dir, div, dl, dt, em, fieldset, font, form, frame, frameset, h1, h2, h3, h4, h5, h6, head, hr, html, i, iframe, img, input, ins, isindex, kbd, label, legend, li, link, map, menu, meta, noframes, noscript, object, ol, optgroup, option, p, param, pre, q, s, samp, script, select, small, span, strike, strong, style, sub, sup, table, tbody, td, textarea, tfoot, th, thead, title, tr, tt, u, ul, var

Aparte de estas existen otras propias del HTML, ya obsoletas, y cuyo uso queda prohibido de ahora en adelante, y son:

applet, basefont, center, dir, font, isindex, menu, s, strike, u

No son muchas etiquetas, y su uso nos hará acostumbrarnos a todas y cada una de ellas hasta dominarlas completamente.

Veamos cuál va a ser nuestra unidad mínima de trabajo: el ELEMENTO.

Un elemento está compuesto por:

• Una apertura de etiqueta
• Ninguno o más atributos
• Un texto
• Un cierre de etiqueta

Ejemplo:

<p class="estandard">Texto del párrafo</p>

donde

• <p> es la apertura de etiqueta
• class="estandard" es un atributo
• Texto del párrafo es el texto contenido entre la etiqueta de apertura y la de cierre
• </p> es el cierre de etiqueta

Aquí quiero comentar unas diferencias muy notables entre HTML y XHTML:

• en HTML estamos acostumbrados a abrir etiquetas, pero puede ser que no a cerrarlas. XHTML obliga a cerrar siempre una etiqueta que se abre.
• en HTML puede ser que funcionen etiquetas mal anidadas (ej; <p><a href="www.loquesea.com">loquesea.com</p></a>), pero XHTML nos obliga a seguir un orden estricto a la hora de cerrar etiquetas; el mismo por el que se han abierto pero a la inversa, en nuestro ejemplo (<p><a href="www.loquesea.com">loquesea.com</a></p>).
• tanto los descriptores de etiqueta como sus atributos como los nombres de los atributos van en minúsculas. Aquí vemos que el editor HTML de Velneo es eso, un editor HTML que no XHTML.
• los valores de los atributos van entre comillas, no como en HTML.

Inciso. Si el editor HTML de Velneo no es ideal, cuál deberíamos usar?

• Word NO. Word inserta una serie de etiquetas "basura" que fundamentalmente engordan nuestros documentos y lo hacen no compilante, ilegible e inservible.
• Dreamweaver. Se puede usar con conocimiento de causa, es decir, debemos conocer XHTML y saber eliminar toda la basura que introduce el programa en nuestros documentos.
• FrontPage NO. Hablamos de editores HTML, por favor...
• Alguno gratuito. Lo mismo que con Dreamweaver, con conocimiento de causa y con la escoba preparada.

El editor ideal HTML es nuestro cerebro, nuestros conocimientos de XHTML y nuestras manitas, que junto con un editor de textos como por ejemplo el Bloc de notas de Windows, nos permitirán confeccionar documentos estructurados, compilantes, legibles, usables y corectos.

Una vez entendida la unidad mínima de trabajo, el ELEMENTO, veamos su clasificación.

Los elementos se clasifican en:

• Elementos en línea (a, abbr, acronym, b, basefont, bdo, big, br, cite, code, dfn, em, font, i, img, input, kbd, label, q, s, samp, select, small, span, strike, strong, sub, sup, textarea, tt, u, var)
• Elementos de bloque (address, blockquote, center, dir, div, dl, fieldset, form, h1, h2, h3, h4, h5, h6, hr, isindex, menu, noframes, nos-cript, ol, p, pre, table, ul, además de dd, dt, frame-set, li, tbody, td, tfoot, th, thead, tr)

Los elementos button, del, iframe, ins, map, object, script, pueden ser considerados tanto como en línea como de bloque dependiendo de las circunstancias.

Una vez vistos estos conceptos básicos pasemos a la parte fundamental: estructurar nuestros documentos.

Todos nuestros documentos tendrán siempre tres secciones básicas y fundamentales:

• Inicio y fin de documento. Viene determinado por las etiquetas <html> y </html>. Irán siempre (salvo determinadas especificaciones que veremos más adelante) al principio y fin del documento.
• Cabecera. Encerrada entre <head> y </head>. Aquí definiremos elementos como el Título del documento, metainformación sobre el documento, links a documentos css o javascript, etc.
• Cuerpo. Encerrado entre <body> y </body>, que define el contenido de nuestro documento y supondrá entorno a un 90% de nuestro documento.

Como el 90% del trabajo lo tenemos en el cuerpo del documento veamos cómo MARCAR correctamente nuestros contenidos para darles sentido semántico.

PÁRRAFOS (<p></p>)

Un párrafo es, como hemos visto, un elemento de bloque y como tal ocupa por defecto la anchura disponible en la ventana del navegador.

No tiene atributos específicos pero se le pueden asignar toda una serie de atributos básicos, de internacionalización y de eventos.

Por similitud con un documento Word, diremos que un párrafo es aquello comprendido entre el inicio de una línea de texto y un "Intro".

Inciso. Word es quizás el editor de textos más utilizado del planeta y por ende el peor utilizado también. Cuando empezamos a escribir un texto con Word, tecleamos letras y espacios hasta llegar a un punto y aparte. Esto es un párrafo. Muchos usuarios introducen "Intros" adicionales para separar un párrafo del siguiente, pero esto no se hace así: hay una propiedad del documento llamada separación entre párrafos que se usa para tal fin. No hay que introducir "saltos de línea" o "párrafos en blanco" para separar párrafos, basta con definir la separación entre párrafos y Word ya sabe lo que tiene que hacer cuando pulsamos "Intro".

Un párrafo empieza por <p> y termina </p>.

TÍTULOS DE SECCIONES (<h1></h1>, <h2></h2>, <h3></h3>, <h4></h4>, <h5></h5> y <h6></h6>)

Es habitual que el contenido de nuestro documento se estructure a su vez en secciones de mayor o menor importancia. Para indicar los títulos de dichas secciones usaremos las etiquetas h, siendo h1 la de mayor importancia, reservada normalmente para el Título de la sección, h2 para el subtítulo, y así sucesivamente para subsecciones del documento de cada vez menor importancia dentro del mismo.

Cualquier navegador web interpreta de por sí estas etiquetas destacándolas del resto de texto del documento otorgándoles ciertas características de tamaño de fuente y negrita o cursiva.

También son elementos de bloque al igual que los párrafos.

Con estas dos simples etiquetas ya podemos estructurar nuestro contenido en secciones de mayor o menor importancia, y a su vez dividir el texto dentro de cada sección en párrafos. Básico pero fundamental.

Ahora veamos cómo marcar el texto dentro de cada párrafo o sección para indicar que va en negrita, cursiva, es una anotación, una corrección, una cita a otro documento, etc.

ÉNFASIS (<em></em>) y MÁS ÉNFASIS (<strong></strong>)

Son elementos en línea a diferencia de los dos anteriores y se utilizan para destacar un texto respecto del resto.

• <em></em> indica que el texto encerrado tiene mayor importancia que el resto y los navegadores lo suelen representar en cursiva.
• <strong></strong> indica que el texto encerrado es de la mayor importancia dentro del documento y los navegadores lo suelen representar en negrita.

Inciso. Elementos de bloque y elementos en línea. La principal diferencia entre unos y otros es cómo ocupan el espacio dentro del documento; los elementos de bloque provocan el salto de línea (empiezan en nueva línea) y ocupan el ancho disponible independientemente de su longitud, mientras que los elementos en línea no provocan salto de línea y ocupan el ancho necesario para mostrar su contenido.

MODIFICACIONES (<ins></ins> y <del></del>)

Para indicar las diferentes modificaciones introducidas en un documento disponemos de estas dos etiquetas.

• <ins></ins> se emplea para indicar la inserción de nuevo contenido en el documento.
• <del></del> se emplea para indicar el borrado de cierto contenido.

Ambas etiquetas disponen de dos atributos específicos que son:

• cite="url". Para indicar la fuente explicativa de la modificación.
• datetime="fecha". Para indicar la fecha y hora de la modificación.

Los navegadores suelen representar las inserciones como texto subrayado y los borrados como texto tachado.

Ambos son elementos en línea.

CITAS TEXTUALES (<blockquote></blockquote>)

Este elemento se utiliza para incluir citas textuales de otros documentos en el actual.

Dispone del atributo cite="url" para indicar la referencia al texto original citado.

Los navegadores suelen representar este elemento con un cierto margen a la izquierda.

Es un elemento de bloque.

AUTOR CITADO (<cite></cite>)

Este elemento se utiliza para declarar el autor de una cita. La diferencia con blockquote es que mientras esta contiene la cita en sí, cite denota al autor de la cita.

Es un elemento en línea.

ABREVIATURAS (<abbr></abbr>), ACRÓNIMOS (<acronym></acronym>) y DEFINICIONES (<dfn></dfn>)

Son elementos en línea con el atributo title="texto" que se usan para abreviaturas, siglas y definiciones de palabras "extrañas" usadas en el documento y así poder indicar su significado.

Los navegadores las suelen representar como texto subrayado por puntos, y suelen mostrar un texto alternativo al situar el ratón sobre ellas (el indicado en el atributo title).

SALTO DE LÍNEA (<br />)

La etiqueta <br> es un tanto especial. Sirve para forzar un salto de línea en nuestro documento.

Es una etiqueta vacía y como tal debe abrirse y cerrarse consecutivamente, pero para evitar tener que escribir <br></br> se abrevia como <br />.

Debemos limitar su uso a ocasiones bastante especiales y no abusar; seguro que lo que queremos hacer se puede hacer de otra manera mucho mejor.

Inciso. Los espacios en blanco sobrantes dentro de un documento (tabulaciones, espacios en blanco consecutivos) son ignorados por HTML salvo que indiquemos lo contrario. Para introducir un espacio en blanco debemos recurrir a la entidad &nbsp;

TEXTO PREFORMATEADO (<pre></pre>)

Hay veces que debemos mostrar un texto dentro de un documento "tal cual se ha escrito", con todos sus espacios, tabulaciones, saltos de línea, etc (por ejemplo un objeto texto de la bd de Velneo). Para estos casos especiales usaremos la etiqueta <pre>.

Es un elemento de bloque cuyo ancho no se ajusta a la ventana del navegador, así que puede forzar la aparición del scroll horizontal en nuestras páginas.

Los navegadores suelen representarlo con un tipo de letra de ancho fijo.

CÓDIGO (<code></code>)

Cuando dentro de un documento hemos de representar código html o de otro tipo que haga uso de las entidades específicas de HTML usaremos la etiqueta <code>.

Es similar a <pre> con la salvedad de que no respeta los espacios en blanco y es un elemento en línea.

LISTAS ORDENADAS (<ol></ol>) y NO ORDENADAS (<ul></ul>)

Cuando hemos de representar en nuestro documento una sucesión de elementos ordenados (numerados de alguna forma) o sin orden aparente, usaremos las listas.

Cada elemento de una lista irá encerrado entre <li> y </li>.

Son elementos de bloque y los navegadores suelen representarlas indentadas y usando números para los elementos de una lista ordenada, y viñetas gráficas para las lista no ordenadas.

Inciso. Este tipo de elementos, veremos más adelante que nos servirá para definir nuestras estructuras de navegación (menús) usando un poco de CSS.

Y por hoy hasta aquí!

En la próxima entrega veremos cómo introducir tablas, imágenes, enlaces y otros elementos útiles dentro de nuestros documentos.

Life is soft!!

Fondo pantalla 004

Trasteando en flickr la otra noche me topé con algunas fotos de Velneo.

Me llamó la atención una de ellas (esta), porque es bastante profesional y la pose "mola mazo".

Esa pose me recordaba algo y no sabía muy bien el qué. Rebusqué entre mi colección de fotos hasta que lo encontré. Lo vi claro al momento y ni corto ni perezoso me puse a ello con el potochof.

Aquí dejo el resultado; un nuevo fondo Velneo con el X-taff directivo al completo.


Vaya con el mayor respeto y cariño. Entiéndase bien, eh?

Life is soft!!

Chrome

La gente de Google son los más listos y oportunos del planeta, y gracias a ello aglutinan al mayor número de usuarios posible.

Un estudio del comportamiento del usuario estandard de internet reveló que la inmensa mayoría de ellos pensaban que Google era internet; su página de inicio era Google y para acceder a un dominio.com lo buscaban literalmente en el famoso buscador; no lo escribían en la barra de direcciones del navegador, lo buscaban en Google y pinchaban sobre el resultado de la búsqueda.

Esto ha llevado a Google a la omnibarra de direcciones que completa automáticamente las url's según tus últimas visitas o búsquedas en Google.

Saben y almacenan tus costumbres de navegación, de forma que te las pueden mostrar en una página especial con tus webs más habituales o una sugerencia de búsqueda en Google.

Muy listos.

Fruto del uso que la gente ha ido haciendo del buscador Google, han sabido optimizar y simplificar la experiencia del usuario, llegando a decisiones de diseño como el que las pestañas estén a un nivel superior e independiente, cada una con sus propios controles de navegación.

La decisión más potente y arriesgada de Google con su navegador Chrome ha sido incluir las Gears como código abierto y libre, para que cualquier otro navegador comercial las pueda usar y adoptar como propias, de forma que con el tiempo todos los navegadores sean como Chrome.

Al haberlo desarrollado desde cero cuando ya están establecidos los estándares de la web para los próximos años, se han asegurado una fiabilidad que los va a posicionar en lo más alto muy rápidamente, y han aprovechado para instaurar una nueva política con los plugins de navegador que cualquiera deberá cumplir en sus futuros desarrollos si quiere funcionar con Chrome o sus derivados, es decir, con cualquier futuro navegador.

Muy oportunos.

Punto y aparte, la campaña de publicidad del navegador; el cómic al respecto me parece fantástico y muy acertado. Explica todo de todo del nuevo navegador, siendo una herramienta muy potente a la hora de convencer a los desarrolladores en el uso y disfrute de las capacidades del navegador.

La mayor alianza actual del navegador es con Java V8, el nuevo motor de java optimizado que soluciona de forma brillante temas de optimización y rendimiento. No tiene rival.

A nivel de seguridad parece ir un paso por delante del resto al considerar cada pestaña de navegación como un proceso independiente, dando mayor estabilidad a la herramienta, y el haber hecho un espacio de memoria de ejecución independiente por pestaña, resuelve la estabilidad del resto de pestañas en ejecución, impidiendo la interacción de unas con otras; que un proceso de pestaña da problemas? se mata esa pestaña y el resto del navegador sigue funcionando, la memoria reservada para esa pestaña se libera y el navegador sigue funcionando de manera eficiente, no importa cuántas horas o pestañas abiertas mantengas.

Muy listos.

La experiencia de usuario que he podido reunir en este tiempo es muy positiva; "es sencillo, con todo lo necesario y nada más", perfecto.

Por ahí tienen ganado al usuario, y por otra parte, con el V8, las Gears y el código abierto, tienen ganado en poco tiempo al mercado de desarrolladores.

En fín, mi más sincera enhorabuena a Google por su exitosa incursión en el mundo del software de navegación. Si hasta ahora para el 90% de los usuarios internet era Google, a partir de ahora TODOS pensarán lo mismo.

Life is soft!!!

Google & Velneo (ii)

Desarrollas aplicaciones web?

Usas bibliotecas javascript como jQuery, prototype, script.aculo.us, MooTools o dojo?

Si es así y no quieres perder la cabeza manteniendo las versiones usadas en todos tus proyectos, Google ha sacado un nuevo servicio en GoogleCode que sirve las últimas versiones de todas estas bibliotecas.

Sólo necesitas enlazar con ellas a través de tu APIkey y Google te las sirve, además comprimidas, de forma que su carga está optimizada, y tus páginas liberadas de un gran peso.

Aquí os dejo el enlace

http://code.google.com/apis/ajaxlibs/

Life is soft!!!

Google & Velneo

Hace tiempo que no posteo nada, y es que estoy tan ocupado desarrollando soluciones de gestión empresariales y web con Velneo V6 que no tengo casi tiempo para más.

Esta noche he sacado un hueco y me gustaría comentar mis últimas experiencias de desarrollo en Velneo V6 integrando soluciones Google.


Está claro que Velneo V6 deja bastante que desear a nivel gráfico, informes, conectividad, etc, pero he descubierto que se lleva muy bien con Google para paliar esas deficiencias.

A nivel de informes, la herramienta que incorpora Velneo V6 es bastante limitada, pocos objetos y poco configurables. Desde hace tiempo intento inculcar en la comunidad el concepto de informes html en Velneo. Son informes xhtml+css lanzados desde la aplicación.

Este tipo de informes son al fin y al cabo como cualquier página web lanzada desde Velneo; un proceso accesible web, que como tal tiene acceso a todas las tablas de la aplicación para componer un informe sin limitaciones impuestas por el origen del proceso; ningún origen, cabecera, líneas, da igual, estamos en un proceso y podemos hacer lo que queramos.

En el proceso podemos cargar datos de una tabla, de otra, de muchas..., componemos el html resultante a base de componentes html, y el resultado se devuelve como Añadir retorno texto.

La maquetación corre a cargo del css que da forma al xhtml generado, y ya tenemos un informe (página html) que se previsualiza siempre y se puede imprimir a gusto del usuario.

Los informes nativos Velneo disponen de gráficos, rejillas de histórico, etc, para su composición, y a nivel de gráficos encontré muy gratificante el API de GoogleCharts.

Es un API gratuita, sólo hay que tener una cuenta Google, y se ataca de forma muy sencilla:

1. Recopilas los datos a representar
2. Los escalas y trasladas en función del número de datos y la codificación correspondiente
3. Eliges el tipo de gráfico
   
4. Rellenas datos accesorios; ejes, rótulos, títulos, tipos de punto, línea, etc
5. Mandas la petición a GoogleCharts y te devuelve un png del gráfico solicitado
6. Este png se inserta como img dentro del informe html y a correr

Una de mis ocupaciones anteriores consistía en desarrollar soluciones GIS personalizadas usando MapInfo. Es un entorno muy profesional y especializado que necesita de técnicos formados para su mantenimiento.

Hace años integré MapInfo con Velneo, pero era una solución muy cara a nivel de licencias de desarrollo. Investigando GoogleCode encontré el API de GoogleMaps y GoogleEarth, gratuítas igualmente, que permiten mandar un formato KML a Google, que no es más que un formato XML con los datos a representar gráficamente en el mapa, y recibes un formáto gráfico mapa de GoogleMaps o GoogleEarth interactivo que muestra tus datos en el mapa.

Su uso es tan sencillo como el de GoogleMaps y no son necesarios técnicos especialistas para su mantenimiento ya que representa automáticamente lo que hay en la base de datos y para ello sólo es necesario rellenar un formulario de alta o modificación.

Y es todo gratuíto mientras sea público.

Así surgió mi primer GIS con Velneo. GoogleMaps se encarga de representar los datos de Velneo en el mapa, y si lo quieres más espectacular le encargas la tarea a GoogleEarth.

A nivel de conectividad a la hora de compartir documentación, GoogleDocs nos permite generar documentos "Word", "Excel", "PowerPoint" en la nube y compartirlos con los usuarios autorizados.

Hay API's disponibles para todo ello en GoogleCode, fáciles de estudiar e implementar en Velneo y que dotan a nuestras aplicaciones de nuevas funcionalidades con un costo realmente bajo: GRATIS.

Así sigo ampliando las capacidades de la herramienta de desarrollo que elegí hace años, Velneo, de la cual aún no he encontrado el techo (esto no lo puedo hacer), y sigo dando años de vida a soluciones V6, utilizado código abierto y gratuíto, en este caso el de Google.

Life is soft!!!

vTiger

Siempre se ha dicho que Velneo peca de una interfaz de usuario muy pobre y puede que sea así.

Disponemos de pocas posibilidades a la hora de hacer un interfaz vistoso, con muchos efectos y colores, pero si nos esmeramos usando esas pocas posibilidades podemos obtener algo bastante al gusto del usuario.

Cuando miro ahora alguna de mis primeras aplicaciones me parecen francamente horribles, en cuanto al interfaz de usuario al menos; fuentes poco acertadas, colores demasiado llamativos, disposición de elementos poco pensada, etc, en definitiva, una mala experiencia para el usuario.

El interfaz y la usuabilidad de las aplicaciones es un tema muy importante, y más ahora que viene la V7 multiplataforma y vamos a poder entrar en el mercado de usuarios acostumbrados a otro aspecto para sus aplicaciones; linux, mac, etc.

Si nos lo proponemos, con una cuidadosa preparación y unos pocos elementos podemos ir adaptando el aspecto de nuestras aplicaciones hacia ese nuevo mercado que se nos abre.

El siguiente ejemplo es un formulario V6 hecho a partir de una captura de pantalla del OSX-Tiger, tratado con mucho mimo con Photoshop para que no pese, y ejecutado con la V6 en un Windows 2000 Professional.


Usa los colores básicos del OSX-Tiger, fuentes similares, botones al estilo Mac y disposición de elementos similar al OSX-Tiger, para no despistar al usuario Mac.

Así que, aunque no podemos hacerlo todo, sí que podemos hacer bastantes cosas para que el usuario tenga una experiencia agradable y no se encuentre perdido en nuestras aplicaciones Velneo.

Life is Soft!!!

Usabilidad web

Como mi especialidad dentro de Velneo es hacer webs, la usabilidad es un tema que me preocupa sobremanera.

Un buen amigo me ha dejado un libro de Steve Krug titulado "No me hagas pensar".


Es un libro sobre usabilidad web muy fácil de leer, por la sencillez con la que cuenta un trabajo tan complicado a veces, por el lenguaje desenfadado y directo que utiliza, y por lo corto, claro , bien estructurado y por las ilustraciones gráficas que muestra. Es usable.

El trabajo de Steve Krug consiste en ver un sitio web y deducir si es fácil de manejar, redactar un informe con los problemas que presenta el sitio, sugerir posibles soluciones, y ayudar al equipo de diseño web a resolver los problemas e implantar las soluciones. Además le pagan por ello!!!

El libro está lleno de buenos consejos que luego parecen de lo más obvio y trivial, pero que no lo serían si no te los dijese alguien. Así es la usabilidad web.

Me gustaría dejaros aquí, a modo de extracto, algunas perlas que podemos encontrar en el libro:

• No me hagas pensar. El título y resumen perfecto del libro.
• Si algo es complicado de utilizar, simplemente no lo uso demasiado. Un comentario de la mujer de Steve.
• Elimina la mitad de las palabras en todas las páginas, luego prescinde de la mitad de lo que haya quedado.
• Hay que evitar los interrogantes del usuario: dónde estoy? por dónde empiezo? dónde está ...? qué es lo más importante? por qué lo han llamado así?
• Los usuarios no leen las páginas, simplemente les echan un vistazo. No hay que crear literatura de calidad si no una valla publicitaria que se verá a 100 Km/h.

Cinco claves básicas:

1. Jerarquía visual (h1, h2, h3, elementos similares agrupados, bloques englobados)
2. Uso de las convenciones (déjà vu, familiaridad tranquilizadora)
3. División en zonas claramente definidas (esto son las cosas que se pueden hacer en el sitio, esto son los links y esto es lo que me quieren vender)
4. Sobre qué se puede hacer click (el usuario quiere hacer click, dejemos bien claro sobre qué puede hacer click)
5. Minimizar el ruido visual (todo es ruido visual hasta que se demuestre lo contrario)

• Al usuario no le importa el número de clicks que tenga que hacer si hacerlo es sencillo y le ofrece la confianza continuada en que está en el buen camino.
• Omítanse las palabras innecesarias. Esto conlleva además una reducción de ruido visual, realza el verdadero contenido y permite ver más de un sólo vistazo.

El resto del libro profundiza más en aspectos técnicos detallados sobre cómo poner en práctica estos consejos, pero eso ya os lo dejo a los expertos en usabilidad.

Que usted lo use bien!

Betatester V7

Para celebrar la apertura al público en general de la zona de betatesters de V7 el próximo 19 de Mayo de 2008, y aprovechando que hace mucho tiempo que no hacía un fondo de pantalla Velneo, aquí os dejo el que he realizado para la ocasión.


Espero que os guste ( sobre todo la beta de V7 ;-D ).

Life is soft!

Errores en Velneo

Contrariamente a lo que puede sugerir el título de esta entrada del blog, no voy a denunciar un error o bug de Velneo como entorno de desarrollo, voy a exponer un error de programación en el que ya he caído más de una vez, así a vosotros os servirá de experiencia y a mí de recordatorio para no volver a repetirlo.

Un Cargar Lista por un índice de tipo Palabras o Trozos de palabras, resolviendo el índice por alguna de sus partes no funciona.

No es que no funcione, es que parte el motor.

Life is soft!

I had a dream

Anoche tuve un sueño, un sueño que no puedo olvidar.

Soñé que tenía delante de mí una herramienta capaz de enlazar con esta tabla de este Oracle, con esta de este SQLServer y con esta otra de MySql.

Una vez en mi proyecto podía establecer entre ellas las relaciones a que estoy acostumbrado en Velneo; aquí un puntero a maestro, aquí una actualización y aquí un puntero indirecto real.

Soñé que podía hacer un formulario de edición diciendo; de esta tabla, con estos campos, chas!, ya los tengo.

Ahora el aspecto del formulario que tire de este CSS para aplicaciones, chas!, ya tiene aspecto.

Soñé que ponía en marcha mi aplicación, me salía el formulario y podía buscar sobre cualquier campo del mismo sólo con poner algo en un campo y darle a buscar, chas!, rejilla de resultados.

Soñé que en tiempo de ejecución podía modificar el aspecto de las rejillas y los informes para sacarlos como más me convenía según el caso.

Y lo más fuerte, la parte donde el sueño casi pasa a ser una pesadilla; ahora lo quiero en la web, y chas!, sin hacer nada mi aplicación de escritorio se renderizaba en la web tal cual.

Será un sueño?, una quimera?

Será V7?

Espero con ansias que sí.

Life is soft!