Crónica del Life Is Soft 2011

12. November 2011 00:26 by Oscar.SS in Información, Personal  //  Tags: ,   //   Comments (9)

Ayer tuve la suerte de poder asistir al "Life Is Soft 2011" que este año se ha celebrado en la ciudad Asturiana de Gijón. Creo recordar que hacía más de 25 años que no visitaba esta ciudad y la verdad la he encontrado muy bonita y limpia. Ni siquiera el día nublado y tímidamente lluvioso han estropeado los bellísimos paisajes naturales o la espectacular arquitectura de sus edificios emblemáticos.

Patio de la Universidad Laboral En cuanto al evento en sí, se ha celebrado en el Teatro Principal de la Universidad Laboral. Nunca había visitado el centro universitario de Gijón y sinceramente tengo que decir que me ha causado una agradable impresión. Es un edificio espectacular, bien cuidado y acondicionado.

La temática del Life Is Soft no es esencialmente técnica. Está más dirigida a todo lo que ocurre alrededor, e incluso después, del proceso de codificación. Como vender el software, el equipo humano, diseño y todo aquello que muchas veces los técnicos (me incluyo por supuesto) no damos la debida importancia. Pero la tiene, sobre todo si realmente pretendes hacer de tu código un negocio. Por lo menos a mí, me ha parecido interesante empaparme de estos conceptos más globales y externos al código que evidentemente mueven nuestra industria.

La dinámica de Life Is Soft ha sido una sorpresa agradable en cuanto a su ejecución. Los ponentes se sucedían unos detrás de otros con solo 12 o 15 minutos para comunicar sus experiencias y "penas". Y como director de la línea del tiempo, haciendo las veces de maestro de ceremonias, se encontraba Mario Conde. Este tipo de ejecución, al estilo de los monólogos televisivos, ciertamente son muy ágiles, entretenidas y creo yo más comunicativas si cabe. Mejor quedarte con una sola idea en 15 minutos que un par de bostezos en 1 hora.

A continuación os resumo muy brevemente algunas de las presentaciones por si es de vuestro interés.

¿Cómo ser rentable en una empresa de software?

Santiago Cabaleiro apunta que el éxito del software está en focalizar. Focalizar en el cliente (o el usuario), saber realmente cual es su necesidad o que es lo que más valora. Por otra parte focalizar en lo que mejor hace tu empresa y de estas habilidades focalizar en las que hacemos mejor que la competencia. Hay que pensar a largo plazo y para mantener el foco durante un largo periodo es necesaria implicación, indicadores (métricas) e ingresos periódicos.

 

Playa de San Lorenzo Las personas trabajando a gusto damos lo mejor

La presentación de Lola Calvo tengo que reconocer que ha sido una bocanada de aire fresco. No recuerdo ningún evento de software, ni de ningún otro tipo, ya sea técnico o empresarial, en los que se hiciera una sola mención al equipo humano que evidentemente se encuentra detrás de todo lo que hacemos. Desde luego para una empresa conseguir y retener un buen equipo humano con talento es vital, pero para nosotros, sentir que la empresa tiene en cuenta a las personas y no solo a los números, es decisivo.

Aunque parezca mentira, apuntaba que las empresas debería tener en cuenta conceptos como respeto, confianza, que ofrece la empresa (captación), economía, familia (tiempo libre), salud, las necesidades de las personas cambian con el tiempo (desarrollo), esfuerzo por retener el talento, etc.

¿A que parece una utopía?, y seguramente lo sea. Si encuentro una empresa de software que realmente tiene en cuenta solo la mitad de estos factores...¡me caso con ellos!

 

Evolucionamos en tecnología para innovar en software

Hablando de los rápidos y continuos cambios tecnológicos que sufrimos los que trabajamos con software, David Gutiérrez aconseja intentar ser el más adaptado, no el más grande. Siempre que sacamos una nueva versión de producto aumentamos la funcionalidad, comenta que es preciso también quitar funcionalidad para una mejor adaptación.

 

Diseño

Y como no podía ser de otra forma el diseño también estuvo presente. Bueno, no hay mucho que comentar sobre esto, es evidente que si el destino final de tu software va a ser usado por personas, debe tener un aspecto bonito y también usable. Nicolás Osuna comentó un dato que me pareció curioso: según Apple y Google si un campo no es utilizado por al menos el 80% de los usuarios hay que eliminarlo.

 

Ponencia de José Manuel AlarcónLa venta de software

Finalmente el destino de todo software es la venta, ya sea económicamente o a cambio de otros intereses o servicios. Cecilio Labrada habló sobre un modelo clásico de ventas, AIDA, que naturalmente yo no conocía pero me pareció curioso.

 

¡No hagas eso! Los dos errores más graves en las PYME tecnológicas a la hora de vender

Un regalo muy valioso los dos consejos de José Manuel Alarcón sacados directamente de su experiencia profesional como empresario.

Falta de diferenciación. Las PYME deben de competir en el ámbito de la especialización olvidándose de conceptos como solución integral. Es un error, sobre todo cuando se empieza, intentar abarcarlo todo. ¡Especialízate y concreta!

Competir en precio. Cuando una PYME se intenta posicionar con precios bajos condiciona muchos sus márgenes y obtiene un mal posicionamiento por marketing. Además tus competidores directos siempre pueden hacer lo mismo y en cuanto a las empresas grandes tienen mayor pulmón financiero para resistir la guerra de precios.

 

Marketing online: Redes sociales

Sobre las redes sociales y las empresas, personalmente lo extendería también a las personas, Fernando Maltrana nos habló de su importancia pero también de su conveniencia en según qué casos.

Resumiendo mucho redacto los puntos claves que se comentaron. Estrategia (hay que tener un objetivo), audiencia (contar y escuchar), autenticidad, privacidad (¿le interesa a todos lo que publico?), constancia y equilibrio (no abrumar), coherencia y tráfico medible.

 

Con estas vistas me desperté yo!! Fear Uncertainty and Doubt

Marcos Eguillor nos presentó un concepto de estrategia comercial que me sorprendió bastante. No porque no me lo esperaba, más bien porque sea una estrategia reconocida, estudiada y medible. Por lo que yo entendí, que tampoco soy ningún experto, es una estrategia comercial que utilizan grandes empresas cuando su negocio está perdiendo. Estas empresas implantan esta estrategia para sembrar el FUD.

 

¡¡Despierta!!

Bueno, bueno...como colofón final (disculpen el pleonasmo) Alfonso Gutiérrez hizo un llamamiento, quizás poco ortodoxo pero muy valiente debo añadir, a la motivación en esta época de crisis. A salir de esta prisión que es el miedo y sus barreras mentales. A luchar contra toda la información negativa actual que nos acecha. A no ser víctimas del pesimismo colectivo.   Una frase: Sé tú mismo, todos los demás ya están cogidos, Oscar Wilde. Un mensaje: ¡¡Despierta y sigue soñando!!

 

Resumiendo

Un evento dinámico, entretenido, ágil, con energía transmisora, que no deja indiferente y del que me llevo cosas aprendidas y otras a considerar. Pero como no podía ser de otra forma también hubo un par de charlas un poco peñazo. Fijaros que curioso, creo que fueron precisamente las presentaciones que se excedieron de los 12 o 15 minutos.

Objetos en JavaScript

9. November 2011 19:51 by Oscar.SS in Desarrollo Web  //  Tags:   //   Comments (0)

Los desarrolladores que venimos de lenguajes OO podemos encontrarnos con algunos detalles desconcertantes a la hora de trabajar con objetos JavaScript, dado que estos objetos difieren bastante de los conceptos que estamos acostumbrados a tratar. En primer lugar vamos a dar una definición más o menos formal y después veremos algunos ejemplos que explicarán mejor esta definición.

"Los objetos de JavaScript son colecciones de propiedades cada una con un nombre y un valor. Este valor puede ser otro objeto, por lo tanto, podemos decir también que los objetos JavaScript son contenedores para otros objetos JavaScript".

 

Crear objetos

En JavaScript no disponemos del concepto de clases, como tal, que nos permitan crear un contenedor o firma para nuestros objetos. En JavaScript los objetos se crean dinámicamente bajo demanda. Veamos unos ejemplos.

//Creamos un objeto Cliente
var cliente = new Object();

//Le creamos dínamicamente sus propiedades y le asignamos valores
cliente.nombre "Pedro García";
cliente.direccion "Calle San Juan, 3, 5º B";
cliente.fechaNacimiento = new Date(1975323);
cliente.empleoActual "Soldador";

Como podemos observar, en primer lugar creamos una instancia de Object y a continuación creamos sus propiedades asignándoles un valor. El añadir propiedades a un objeto se puede hacer en cualquier punto de nuestro código siempre que lo necesitemos. Es decir, un objeto JavaScript no tiene un conjunto de propiedades y método predefinidos como si lo tienen gracias a las clases los lenguajes OO. Esta elasticidad es muy potente dándonos plena libertad sobre las características de nuestros objetos.

Mencionar también que no disponemos de un compilador que nos avise de errores por lo que es muy importante escribir bien el nombre de las propiedades. Por ejemplo, supongamos que en algún punto de nuestro código necesitamos cambiar el domicilio de nuestro cliente.

cliente.dirección "Plaza Castilla, 4, 12º Izq";

Fijaros bien en que el nombre de la propiedad ahora tiene un acento. Lo que hemos conseguido con este error es que se creen dos propiedades con valores diferentes en nuestro objeto Cliente, una propiedad "direccion" y otra propiedad "dirección". Esto nos puede volver locos cuando tratemos de recoger el valor de la propiedad y descubramos que no se ha cambiado y en su lugar se han creado dos propiedades parecidas...¡mucho cuidado!

 

Objetos como contenedores de otros objetos

Cuando dimos la definición de un objeto JavaScript dijimos que se comportaban como contenedores de otros objetos. ¿En el ejemplo anterior de nuestro Cliente esto no ha sido así?. Desde luego que si, realmente hemos creado un objeto Cliente que contiene 3 instancias de String y una instancia de Date. Quizás lo veamos más claro con un ejemplo de código.

//Creamos un objeto para almacenar los valores de la dirección de nuestro cliente
var direcClient = new Object();
direcClient.calle "Castillo de Candanchú";
direcClient.numero "23";
direcClient.piso "5º B";

//Creamos un nuevo cliente y le asignamos el objeto direcClient a la propiedad direccion
var cliente = new Object();
cliente.nombre "Sergio Rodriguez";
cliente.direccion direcClient;
cliente.fechaNacimiento = new Date(1975323);
cliente.empleoActual "Progamador de los buenos";

//Accedemos a los valores de la dirección
var suCalle cliente.direccion.calle;

De hecho, si realmente los objetos son colecciones, ¿que nos impide recorrer el objeto como si de un Array se tratara?. No nos lo impide nada en absoluto. Veamos.

            for (var item in cliente) {
                
alert("Propiedad: " + item + "\nValor: " + cliente[item]);
            
}

La variable item en cada iteración mantiene una referencia al nombre de cada propiedad del objeto. O dicho de otro modo, en cada iteración la variable almacena una cadena de texto con el nombre de la propiedad. Veamos un par de resultados de ejecutar el código anterior.

Creo que ahora queda más claro eso de que los objetos son colecciones de propiedades que contienen otros objetos. Es importante comentar dos aspectos de esta característica.

En primer lugar, el nivel de anidamiento de objetos no tiene límites, podremos anidar tantos objetos como necesitemos para representar nuestro modelo. Y en segundo lugar, comentar que las funciones de JavaScript también son objetos y por lo tanto también pueden estar contenidas dentro de las propiedades de otros objetos. Pero esto lo veremos más adelante con detenimiento.

 

Expresiones como nombres de propiedades

Hasta ahora hemos visto que los nombres de las propiedades de nuestros objetos JavaScript son identificadores normales y corrientes. ¿Pero qué sucede si necesitamos identificadores más complejos?. Como por ejemplo "Empleo Actual", o "empleo.Actual", o "El empleo de este cliente", etc.

En este caso podemos utilizar una expresión como una propiedad del objeto de la siguiente forma.
 
nombreObjeto[expresión] = valor de la propiedad;
 
Esto es muy útil cuando a priori no conocemos el nombre de la propiedad, por ejemplo porque será suministrado por el usuario en un campo de texto. Veamos un ejemplo.
 
//Definimos unas cadenas que representarán nuestros nombres de propiedades
var nombrePropiedad "Empleo" "actual" "del" "cliente!!";

function 
GetNombrePropiedad() {
    
return "Nombre del cliente";
}

//Creamos la propiedades en el objeto y le asignamos valores.
var cliente = new Object();
cliente[GetNombrePropiedad()] "Raquel Gutierrez";
cliente[nombrePropiedad] "Doctora";

//Desde otro código accedemos a los valores de las propiedades
var nombreCliente cliente[GetNombrePropiedad()];
var 
empleoCliente cliente[nombrePropiedad];

 

Notación JSON para definir objetos

La sintaxis que hemos utilizado hasta ahora para definir objetos y asignar valores a las propiedades es muy familiar para los programadores de cualquiera de los lenguajes de la familia .NET y especialmente para los de C#. Pero JavaScript va mucho más allá y nos permite definir objetos con la sintaxis JSON a modo de literales de objetos.

var cliente =
    
{
        nombre: 
"Nuria Perez",
        fechaNacimiento: 
new Date(19731213),
        empleoActual: 
"Ingeniera",
        direccion: 
            {
                calle: 
"San Pascual",
                numero: 
23,
                piso: 
"3 C"
            
}
    }
;

 Esta es una forma mucho más compacta de escribir y definir código de objetos y desde luego también es más intuitiva sobre todo, si como en el ejemplo, tenemos objetos anidados.

 

El objeto window

El objeto window es el objeto más alto en la jerarquía del navegador, todos los demás objetos, ya sean nativos de JavaScript o creados por nosotros, cuelgan del objeto window, el cual será único para cada ventana o pestaña del navegador.

Cuando en JavaScript definimos una variable fuera del cuerpo de cualquier función, solemos decir que es una variable global. Pues bien, en realidad lo que estamos haciendo es crear una propiedad en el objeto window y asignarle un valor.

De hecho, a mí personalmente me gusta mucho más la notación que se aprecia en la imagen a la hora de recoger el valor de la variable o propiedad del objeto window. En funciones con muchas líneas de código, si hacemos referencia al objeto window, queda más claro que variables son de ámbito de la función y cuales son globales.

Por cierto, fijaros bien en el intellisense de la imagen anterior, en la declaración de la función sucede exactamente lo mismo. Lo que estamos haciendo en realidad al definir un método o función es asignárselo al objeto window. ¡Todo cuelga del objeto window!

 

Recent Comments

Comment RSS

Month List