July 28, 2014

Maestros del Web (Editorial)

“Search Experience Optimization” SEO para humanos, no robots

En los últimos años la optimización para los motores de búsqueda o SEO se ha centrado, en teoría, en mejorar el posicionamiento de un sitio en los buscadores, principalmente en Google, por medio de varias “estrategias” como el link building, el uso de keywords, de metatags y algunas otras acciones cuyo objetivo último es rankear los sitios en las primeras posiciones de los resultados de búsqueda. Pero ¿cuál es el significado real de esto?

La verdad es que esto quiere decir que los algoritmos de búsqueda se han focalizado en hacer los sitios más “SEO friendly”, lo que significa hacer una página web más accesible para los robots que para los usuarios. Pienso que nos estamos olvidando de algo mucho más importante: las páginas en internet están hechas por humanos y deberían servir para humanos, como lo manifiestan los de humanstxt: “somos humanos, no máquinas”.

SEO enfocado a los humanos, no a los robots

Los SEO experts son personas dedicadas a medirlo todo: cuántos usuarios entran a un sitio, cuál fue el porcentaje de rebote, si el usuario hizo o no una conversión, la duración en la página, pageviews y una gran cantidad de métricas que puede ser que estén bien para analizar el rendimiento de nuestro sitio, más ignoran el análisis de la experiencia de usuario.

Hacernos preguntas como: ¿nuestros usuarios están felices?, ¿encontraron lo que buscaban?, ¿lo pondrían en sus bookmarks?, ¿le contarían a un amigo sobre nosotros?, ¿su recorrido por la página fue agradable?, este tipo de preguntas nos ayudará a encontrar el punto de equilibrio entre la optimización para el robot y la optimización para nuestros usuarios.

La lucha de Google contra los resultados de mala calidad

http://zackwilliamson.com/wp-content/uploads/2012/04/penguin-panda.jpg

Es por eso que actualmente Google se ha dado a la tarea de mejorar los algoritmos de búsqueda y la experiencia del usuario, mostrando el contenido más relevante posible en las SERPs; este esfuerzo se ha visto en las últimas actualizaciones de sus algoritmos (Panda y Penguin) y con el lanzamiento de Hummingbird, que han tenido un gran impacto en los resultados de búsqueda: “no intentes ser natural, sé natural”, es lo que Google está tratando de decirnos y lo que en realidad deberíamos hacer.

Incluso Matt Cutts ha dicho que también se podría pensar en lograr la optimización de la experiencia y no sólo la optimización del “motor”, dejando entre líneas el mensaje de que tal vez el significado del SEO empieza a transformarse radicalmente:

Así que en mi opinión personal la mejor manera de abordarlo sería, ya sabes, pensar en ello en términos generales, o tal vez pensar en cómo podemos diferenciar las grandes cosas que la gente hace en su sitio para que sea más rápido, más accesible o ayudar a las personas con un keyword research, todo este tipo de cosas, el marketing de diferentes maneras

,dice Cutts.

Es la hora de actuar

Debemos entender el recorrido de un usuario en la página, hacer tests A/B y multivariable, aplicar un diseño adaptativo (responsive web design) —algo que es obligatorio para la web de hoy— crear contenido de calidad (long-form para blogs), hacer beta testers.

interfaces de usuario y experienciaEstas son solo unas pocas pues hay una gran cantidad de opciones para  optimizar nuestro sitio y que sea mucho más usable y accesible, para ofrecer una mejor experiencia de usuario ya que al final es él quien toma la decisión de comprar  o no las máquinas. Si no encuentra o no le gusta lo que ve, si no entiende cómo usar la página simplemente tomará la decisión de visitar otra, aunque haya dado con esta en el primer resultado de búsqueda.

Decía Jakob Nielsen decía que “la web es el último entorno entre el cliente y la compra, es el usuario el que tiene la capacidad de visitar cualquier cantidad páginas que quiera, nuestros competidores están a tan solo un clic de distancia”.

No nos sentemos a esperar a que nuestra página salga en las primeras posiciones de búsqueda sólo para generar tráfico, debemos pensar que la cantidad no siempre es calidad, lograr fidelizar a un usuario con una web y con una marca es un reto que debemos asumir, porque lo importante no es que vengan a nuestro sitio, sino que vuelvan en un futuro y se vayan de allí con la mejor experiencia posible.

¿Piensas que el SEO está bien enfocado? si no es así, ¿qué opinas tú de cómo se debería aplicar en la web de hoy?

Si quieres saber más sobre estos temas y convertirte en un gran profesional web únete a nuestros cursos.

by Santiago Eastman at July 28, 2014 04:42 PM

Variable not found

<Vacaciones>

Pues llegó la mejor época del año, prácticamente la única en la que algunos afortunados podemos alejarnos un poco de los mundos binarios y dedicarnos a otros menesteres seguro más importantes, como disfrutar de la familia y descansar, al menos unos días.

Variable not found quedará a la deriva hasta septiembre, cuando volveremos al ataque con las pilas cargadas y listos para afrontar la nueva temporada :)

¡Feliz verano, amigos!

by José M. Aguilar (noreply@blogger.com) at July 28, 2014 11:50 AM

July 24, 2014

Maestros del Web (Editorial)

Algunos rediseños cuestan un huevo, otros los dos

Esta es la historia de un equipo que con pequeños esfuerzos le da un nuevo empujón a un proyecto que agradece tu visita. Bienvenidos al nuevo Maestros del Web.

Propuestas de logo para el 2014

El logo es nuevo.

Capítulo 0.

Pequeño disclaimer: desde finales del año pasado, le dimos vuelta a los ingredientes. Mejorando.la es la principal razón por la que mucho talento humano hoy está reunido, creando cursos que enseñan habilidades prácticas a nuestra comunidad. Es la razón para levantarse temprano y acostarse tarde de mucha gente. @cristalab y @maestros se unieron para darle vida. Era el turno que el hijo se preocupará de cuidar y renovar a los padres.

Damos el primer paso.

Capítulo I.

Reunión de planeación. Vamos a rediseñar, programar un CMS con algunas ideas locas, como una base de datos descentralizada pegada a bitcoins, usar node.js de núcleo y preocuparnos mucho por publicar artículos en formato long-form. Nos fuimos a la profundidad de las conversaciones sobre el futuro de WordPress, lo cual está trayendo Ghost al ecosistema, y de paso analizamos a fondo Medium.

Pero principalmente todo quedó en darle like a un montón de artículos.

Bocetos de logos

Capítulo 2. El Logo.

Con libreta en mano, un gran creativo se puso en una tarea bien compleja, cambiar un logo con más de 15 años de historia. Les presento los bocetos de Alejandro Narváez. No se lo he dicho suficiente, pero gracias por cada trazo, cada propuesta, colores y aguante de tantas opiniones sobre la mesa. Hay nuevo logo, hay nuevo Maestros del Web.

Si no te gusta, le puedes contar a tu abuelita.

Capítulo 3. El formato.

No vamos a escribir siempre, pero vamos a escribir historias, ideas complejas y artículos largos. Para cuando tengas tiempo para venir a leer un rato. Hablaremos de tecnología, ofreceremos material de apoyo para quienes creamos webs y de vez en cuando seguiremos tendencias alocadas.

Aleyda, la editora hoy de Maestros, está a sus órdenes para que nos cuenten qué quieren leer. Sugerencias en 140 caracteres a @maestros o usa los comentarios, ya que estos están conectados a facebook. ¿Todos estamos en facebook hoy, cierto?

Capítulo 4. Responsive Design

Hace unos años una amiga me preguntaba en qué momento vale la pena rediseñar un sitio web. Recuerdo mi respuesta – Obviamente lo haces para refrescar contenidos, cuando estas arrancando una nueva etapa, para el lanzamiento de algo o simplemente para darte nuevas fuerzas para seguir constante con un trabajo -.

Hoy rediseña si no tienes un diseño responsive, o si entras a tu proyecto desde tu pantallita pequeña y se ve mal.

Maestros era horrible en móviles a pesar de muchos hacks y plugins que teníamos archivados. Eliminé todos esos plugins.

Capítulo 5. I hate plugins.

Si algo debo agradecer de la simplicidad que nos ha dado el mundo móvil, es que también con muchas plataformas de contenidos, hay grandes esfuerzos para regresar a lo básico. Menos plugins, más enfoque al contenido que es lo importante.

Capítulo 6. ¿Hay nuevo CMS o algo más?

Seguro que lo vamos a hacer, somos perseverantes. Queremos programar muchas cosas nuevas, pero renovar un proyecto no solo es trabajo técnico, es trabajo de equipo, de buenos contenidos, y hoy en día, de integración en muchos canales sociales. Hay gente épica que ha demostrado que puede renovar y volver a soñar como Josh Toplsky que hoy deja The Verge para ir a Bloomberg. Yo voy a leer Bloomberg en el 2015.

Mi sueño es que vos también nos leas a nosotros en el 2015.

Capítulo 7. Deploy.

Pronto más Maestros del Web. Aquí mismo.

Gracias a @freddier, @leonidasesteban, @leidymarmalade @unavacaverde, @linkstrifer, @betaromeo, @alejandrogm @Hell_McNamara y a @infranetworking.

Capítulo 8. Bienvenidos los aportes.

Te gustan los drones como a nosotros, tienes dogecoins en algún usb enterrado en el jardín, tu emprendimiento está usando alguna tecnología de forma particular y quieres contar la historia. O simplemente quieres examinar algún keynote particular de alguna gran empresa tecnológica de Silicon Valley. Hay espacio para colaborar escribiendo. Hay espacio para que opines aquí debajo.

Dale like o critícanos sin pena. Sino, ¿a qué venimos?

by Christian Van Der Henst S. at July 24, 2014 09:04 PM

July 23, 2014

Yukei

Automatizar tareas de traducción de WordPress con Grunt

Grunt es una de esas herramientas que al principio parece un poco intimidante, pero al empezar a utilizarla se hace cada vez más necesaria y adictiva.

Por si aún no lo conoces, Grunt es un programita hecho en javascript sobre node.js que permite automatizar una gran cantidad de tareas, y sirve especialmente para poner a punto la versión en producción de un sitio; por ejemplo: optimizar imágenes, compilar estilos desde LESS a CSS (o Coffeescript a javascript), ejecutar pruebas unitarias, minificar y concatenar estilos y scripts, etc.

Hace algunos posts escribí sobre algunas herramientas de localización para WordPress que ayudan a generar el catálogo de traducciones POT necesario para hacer un tema o plugin traducible a otros idiomas, y que es un excelente ejemplo de tareas en las que Grunt se luce.

Afortunadamente bradyvercher adaptó esas herramientas para trabajar como módulos de Grunt, por lo que podemos utilizar las mismas herramientas de localización “oficiales” de WordPress de forma automática con Grunt.

Definición del proyecto

El primer paso, si aun no tienes node.js es instalarlo en tu sistema — revisa las instrucciones para tu sistema operativo o pregúntale a tu buscador cómo hacerlo. Al instalar node, tendrás disponible en la línea de comandos el gestor de paquetes npm, que vas a necesitar para crear una definición de paquete de nuestro proyecto y así guardar la configuración de los módulos que vamos a usar con Grunt.

¿Todo instalado? ¿Listo? Ok, sigamos.

Lo siguiente es crear la definición de paquete, que podemos hacer de forma automatizada ejecutando npm init en la carpeta del proyecto. Se mostrarán varias preguntas y como resultado obtendrás un archivo package.json parecido a esto:

{
	"name": "tuproyecto.com",
	"version": "1.0.0",
	"description": "Sitio web del proyecto multilenguaje cachilupi",
	"main": "index.php",
	"repository": {
		"type": "git",
		"url": "https://github.com/felipelavinz/mi-repo.git"
	},
	"keywords": [
		"wordpress",
		"l10n"
	],
	"author": "Felipe Lavín Z. <felipe@yukei.net>",	
	"license": "propietary",
	"bugs": { "url": "https://github.com/felipelavinz/mi-repo/issues" },
	"homepage": "https://github.com/felipelavinz/mi-repo",	
	"devDependencies": {
		"grunt": "^0.4.5",
		"grunt-cli": "^0.1.13",
		"grunt-contrib-watch": "^0.6.1",
		"grunt-wp-i18n": "^0.4.5"	
	}
}

Instalar dependencias

Lo que hace este archivo es definir cuáles son los módulos y versiones de paquetes para node que tu proyecto va a utilizar, por ejemplo lo que puedes ver en la propiedad devDependencies, que si acabas de generar el archivo, probablemente no va a estar o bien está vacía.

Para definir los módulos que vamos a utilizar con npm, ejecuta el siguiente comando:

npm install --save-dev grunt grunt-cli grunt-contrib-watch grunt-wp-i18n

Este comando le indica al gestor de paquetes npm que instale los módulos señalados y que los guarde como dependencias del proyecto (la parte --save-dev). Los módulos que instalamos son:

  • grunt y grunt-cli, para ejecutar las tareas que vamos a automatizar con Grunt
  • grunt-wp-18n que es el plugin de Grunt que contiene las herramientas de traducción de WordPress. Ojo, que para utilizarlo vas a necesitar poder ejecutar scripts de php por línea de comandos (comprúebalo con php -a; si te aparece una consola interactiva estás ok).
  • grunt-contrib-watch que es un plugin para Grunt que permite vigilar cambios en archivos y carpetas. Es algo así como inotify que utilizaba para compilar archivos LESS automáticamente en Linux pero para Grunt

Obviamente, también podrías instalar otros plugins para realizar otras tareas.

Al instalar estos módulos y plugins con la opción --save-dev, el archivo package.json guardará la información de todo lo que le pedimos instalar a npm. El código de todo lo que instalamos quedará en la carpeta node_modules.

Si usas un sistema de control de versiones, es buena idea versionar package.json y excluir node_modules, ya que al clonar el repositorio puedes ejecutar npm install (sin más) y npm bajará e instalará todos los módulos que están indicados en package.json. Si no usas control de versiones… deberías.

Definición de la tarea de traducción

Finalmente, para poder utilizar Grunt necesitamos crear un archivo Gruntfile.js donde vamos a definir las tareas que se van a automatizar. En la documentación de Grunt hay información a fondo, pero puedes partir con lo siguiente (obviamente, ajustando la información de rutas donde corresponda):

module.exports = function(grunt){
	grunt.initConfig({
		makepot: {
			target: {
				options: {
					// la ruta al tema
					cwd: 'htdocs/wp-content/themes/mi-super-tema',
					// la carpeta dentro del tema donde se guarda el catálogo de traducciones
					domainPath: '/languages',
					exclude: [],
					mainFile: 'htdocs/wp-content/themes/mi-super-tema/style.css',
					// el tipo de proyecto; sería wp-plugin si es un plugin 
					type: 'wp-theme',
					// debe corresponder al dominio de traducción del tema
					potFilename: 'mi-super-tema.pot'
				}
			}
		},
		watch: {
			theme_translations: {
				// vigilar cambios en todos los archivos php del tema
				files: ['htdocs/wp-content/themes/mi-super-tema/**/*.php'],
				tasks: ['makepot'],
				options: {
					nospawn: true
				}
			}
		}
	});
	grunt.loadNpmTasks('grunt-contrib-watch');
	grunt.loadNpmTasks('grunt-wp-i18n');
	grunt.registerTask('default', ['watch']);
};

Con esto, vamos a tener disponibles las siguientes tareas:

  • grunt makepot que genera el catálogo de traducciones para el tema
  • grunt watch que va a vigilando cambios en los archivos PHP del tema y actualiza el catálogo de traducciones cada vez que guardas un cambio
  • Además, también puedes utilizar simplemente grunt para ejecutar la tarea anterior

Actualizar las traducciones

Con estas tareas de Grunt, el catálogo de traducciones (es decir, el archivo POT) siempre estará actualizado; para traducir los nuevos textos puedes utilizar poedit que es el cliente gráfico más popular para ello.

Para incorporar los nuevos textos, debes seguir los siguientes pasos:

  1. Abrir el archivo de traducciones, por ejemplo, htdocs/wp-content/themes/mi-super-tema/languages/en_US.po
  2. Importar los nuevos textos traducibles: ingreas al menú Catálogo y luego la opción Update from POT File (“actualizar desde archivo POT” o algo así).
  3. ¡Listo! Ahora sólo debes traducir los nuevos textos y guardar el archivo.

Tags: , , , , ,

Related posts

The post Automatizar tareas de traducción de WordPress con Grunt appeared first on yukei.net.

by Felipe Lavín Z. at July 23, 2014 01:30 PM

Programania

Accidental versus essential complexity

¿Cuántas veces te pasa que, al tener implementada la solución a un problema, te das cuenta de que el problema era mucho más fácil de lo que parecía y que ahora podrías implementar una solución mucho más sencilla? ¿Cuánta de la complejidad de una solución es inherente al propio problema y cuánta se produce por la propia solución planteada?

La complejidad intrínseca de un problema es difícil de abordar. No la has creado tú. Tienes que convivir con ella. No puedes actuar sobre ella a corto plazo. Es verdad que con el paso de los años, van surgiendo técnicas que ayudan a disminuirla. Pero sólo con el paso de las décadas se dan mejoras significativas.

La complejidad accidental de un problema es mucho más fácil de abordar. La has creado tú (o tu organización, o tu cliente…). Puedes actuar sobre ella a corto plazo y disminuirla de manera significativa.

La buena noticia es que casi toda la complejidad de lo que hacemos es complejidad accidental. Ocurre en los procesos que nos autoimponemos, en los análisis y diseños que hacemos y en el código que escribimos. Tenemos la certeza de que:

  • normalmente cuando planteamos un problema no llegamos al fondo del POR QUÉ o PARA QUÉ se está abordando ese problema. Lidiamos muchas veces con los efectos del problema en lugar de ir a la causa.
  • siempre que se plantea un proceso ligero, en pocos pasos, éste tiende a complicarse con el tiempo. Cada vez que ocurre una excepción que el proceso no contempla, se añade una nueva fase al proceso sin tener en cuenta que la mayoría de las veces que se ejecute, al no darse esa excepción, esa fase será una pérdida de tiempo.
  • cuando programamos, planteamos una serie de abstracciones en función de nuestro entendimiento del problema. Cuando solucionamos ese problema, adquirimos un entendimiento del mismo que se puede adquirir de ninguna otra manera que no sea, precisamente, hacer el acto de solucionarlo. Ese entendimiento nos hace ver que las abstracciones que planteamos no iban a la esencia y por lo tanto son demasiado complejas.
  • el diseño de interfaces es especialmente clave en estos casos. Las interfaces normalmente reflejan los procesos de negocio. Si el proceso es complejo, la interfaz es compleja. Si la interfaz es compleja, la programación que haya por detrás también.

En desarrollos iterativos e incrementales, si de base planteamos procesos, interfaces y código complejos, la complejidad del problema lo único que hará es crecer de manera exponencial.

Si uno es consciente de esto, puede actuar sobre ello. Por eso es importante establecer mecanismos que busquen la simplicidad y la esencia de las cosas. Una lista no exhaustiva sería:

  • pregúntate POR QUÉ y PARA QUÉ 5 elevando a la 5 veces. Usa técnicas de análisis de causa raíz.
  • plantea siempre la solución más sencilla que se te ocurra. Iterativamente, intenta reducirla al absurdo y usa a expertos para que le tiren piedras. Si no se cae, es la solución a implementar.
  • antes de automatizar procesos, replantea los procesos. Si automatizas la mierda, tendrás mierda automática.
  • refactoriza el código. Refactorizar es entender que generamos complejidad accidental y que una vez vista la solución existe una manera de hacer las cosas más sencillas. También es entender que no simplificarlo ahora, implica generar más complejidad en el futuro.

by Luis Artola at July 23, 2014 07:02 AM

July 22, 2014

Variable not found

#if DEBUG en Javascript (bueno, o algo así)

DebugHay veces que desde Javascript nos interesa ejecutar un código u otro en función de si la ejecución se está produciendo en un servidor de desarrollo o en uno de producción. Por ejemplo, en el primer caso suele ser interesante disponer de logs o herramientas de ayuda a la depuración, mientras que en el segundo lo normal es que queramos introducir código más eficiente y sin este tipo de condimentos.

En este post vamos a ver algunas técnicas muy básicas que nos permitirán ejecutar un código u otro en el lado cliente de aplicaciones ASP.NET MVC (o ASP.NET en general) en función del modo de compilación.

1. El lado servidor

En el lado servidor es bastante fácil de conseguir porque disponemos de directivas de compilación que nos permiten detectar si estamos generando los binarios en modo depuración:
// HomeController.cs
public ActionResult Index()
{
#if DEBUG
ViewBag.CompilationInDebugMode = true;
#else
ViewBag.CompilationInDebugMode = false;
#endif
return View();
}

@* Home/Index.cshtml *@
<p>Compilation in debug mode: @ViewBag.CompilationInDebugMode</p>
También podemos conocer en tiempo de ejecución si ASP.NET está compilando en dicho modo (compilation debug="true" en el web.config):
@* In a Razor view: *@
<p>ASP.NET debugging: @Context.IsDebuggingEnabled</p>
Normalmente esta última vía será la que utilicemos, pues es la que suele indicar si estamos ejecutando sobre un servidor de desarrollo o no, básicamente porque el cambio en el web.config del valor del parámetro debug a false es uno de esos pasos que nos han recomendado desde el principio de los tiempos al pasar una aplicación a producción. Y seguro que todos lo hacemos, ¿verdad? ;-)

2. ¿Y el lado cliente?

En el lado cliente, debido a la propia naturaleza dinámica del lenguaje Javascript, no existe una compilación en modo depuración; bueno, de hecho no existe ni siquiera compilación como tal ;-), por lo que tenemos que recurrir a algunos truquillos para conseguir emular este comportamiento.

2.1. Cargar scripts diferentes en función del modo de depuración de ASP.NET

Una posibilidad muy sencilla, y válida en algunos escenarios, es tener un archivo de script diferente para cada modo de compilación. De hecho, es empleada por muchas bibliotecas Javascript, que se distribuyen en forma de archivo .js para la versión de producción, normalmente ya compactada y minimizada, y .debug.js para la versión a utilizar durante el desarrollo.

Por ejemplo, supongamos que tenemos los dos siguientes archivos:
// File: Myscript.debug.js (development script)
function log(msg) {
console.log(msg);
}

// =====================================

// File: Myscript.js (production script)
function log(msg) {
// Nothing to do
}
Para cargar manualmente un archivo u otro en función del modo de compilación bastaría con hacer lo siguiente a la hora de referenciarlo:
<script src="~/scripts/myscript@(Context.IsDebuggingEnabled? ".debug": "").js">
</script>
Sin embargo, si utilizamos bundles es aún más sencillo: de serie, el sistema de bundling ya distinguirá entre las distintas versiones de forma automática basándose en la extensión de los archivos. Por ejemplo, continuando con el caso anterior, al añadir un bundle como el siguiente el mismo componente de optimización seleccionará el archivo myscript.debug.js cuando la depuración de ASP.NET esté activada, y myscript.js en caso contrario:
bundles.Add(new ScriptBundle("~/bundles/myscript").Include(
"~/Scripts/myscript.*"
));
La referencia desde la vista en este caso sería así de simple:
@Scripts.Render("~/bundles/myscript")

2.2. Detección inline del modo de depuración

Pero no siempre el grano es tan grueso como en el apartado anterior. Muy frecuentemente no nos interesará sustituir completamente un script por otro en función del modo de compilación, sino conocer simplemente el modo en el que estamos para tomar una decisión a nivel de código. Esto nos permitiría escribir código como el siguiente:
function doSomething() {
if (DEBUG_MODE) {
log("Entering doSomething()");
}
// ... Code
if (DEBUG_MODE) {
log("Exiting doSomething()");
}
}
Por tanto, nuestro problema se reduce a establecer esa constante DEBUG_MODE a un valor que evalúe a cierto cuando estemos ejecutando sobre una aplicación compilada en modo depuración y a falso en caso contrario. Y aplicando lo visto anteriormente, podríamos conseguirlo de varias formas.

Una, realmente sencilla de implementar, consistiría en introducir un conciso bloque de scripts antes de cargar las bibliotecas o scripts que usen este valor, por ejemplo en el encabezado del layout o página maestra del sitio web, más o menos con lo siguiente:

@* Razor Layout *@
...
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>My ASP.NET Application</title>
@Styles.Render("~/Content/css")
@Scripts.Render("~/bundles/modernizr")
<script>
window.DEBUG_MODE = @(Context.IsDebuggingEnabled? "true": "false");
</script>
</head>
...
Otra posibilidad sería establecer el valor de DEBUG_MODE en un script independiente del que tendríamos dos versiones, con extensiones .debug.js y .js, que respectivamente lo inicializarían a true y false, y usar cualquiera de las dos técnicas descritas anteriormente para cargar uno u otro en función del modo de compilación.

Publicado en Variable not found.

by José M. Aguilar (noreply@blogger.com) at July 22, 2014 11:55 AM

Programania

Un entorno productivo en pareja

IMG_1711

 

Ésta foto tiene ya un tiempo. Es de finales de 2013 (ya me cuesta publicar artículos, a ver si cojo un poco de inercia… :-P). En esa época a Guille y a mí nos cayó la primera versión de un potente software no-tan-big data, a hacer con AngularJS/Javascript, Elastic Search y AKKA, alrededor de un dominio que desconocíamos completamente y donde teníamos difícil encontrar a alguien que nos lo explicara, con una deadline inminente.

Si en un escenario aplica lo de typing is not the bottleneck, creo que es en éste. Con lo que decidimos que en lugar de estar levantándonos de nuestro sitio cada cinco minutos a preguntarnos cosas el uno al otro o tomar decisiones técnicas sin contrastar, íbamos a hacer todo el trabajo en pareja y favorecer el ancho de banda de la comunicación entre nosotros muy por encima del ancho de banda de tecleo.

En la foto se puede ver lo que para mí es un entorno ideal para trabajar el software:

  • un ordenador principal con dos teclados y dos ratones y espacio más que de sobra para estar cómodos y centrados frente a las pantallas.
  • un ordenador secundario. Esto es clave. En un escenario de incertidumbre máxima te atascas cada dos minutos y tienes que guguelear a mansalva. Si estás con un sólo ordenador, uno busca, y el otro tiene que andar aguantándose las ganas de buscar cosas distintas. Lo mejor es buscar en paralelo e ir comentando lo que se encuentra.
  • panel físico para gestionar el To Do. Según avanzábamos, íbamos redefiniendo una y otra vez el trabajo a hacer. Destruyendo post-its y creando unos nuevos con nuestra nueva visión de las tareas a realizar. Para nosotros era clave poder hacer esto sin los impedimentos de una herramienta electrónica como Jira, mucho más lenta. Máxime cuando la trazabilidad, en éste punto, no nos servía para nada.
  • pared pintable para discutir ideas y diagramar cosas. Tuvo mucho flow el poder discutir una idea, pintarla, e ir implementándola teniéndola siempre de referencia y pudiéndonos dar la vuelta en cualquier momento a discutir cualquier aspecto.

Es fácil enamorarse de ésta forma de trabajar. Y, al enamorarte, perder un poco la perspectiva. El sistema nos funcionó bien para su principal función: maximizar la información radiada y la comunicación entre nosotros como estrategia para abordar un producto de alta incertidumbre técnica y de dominio. Lo que no nos funcionó:

  • fuimos incapaces de mantener un sólo “to do” en el panel. Como éramos novatos en todo, aprendíamos una manera más decente de hacer las cosas cada media hora, y todo el código anterior nos parecía refactorizable (y lo apuntábamos al “to do”). Al final manteníamos el panel, un archivo todo.txt en el intellij, y las anotaciones //TODO:  en el propio código. Aunque planteábamos sesiones dedicadas sólo a fundirnos esas listas, no lo conseguíamos.
  • hacer pairing el 100% del tiempo trabajando a veces en jornadas de 10 horas es demasiado. Ya sé que esto, leído, puede sonar bastante evidente. Pero cuando estás dándolo todo, cansado, hay cosas de las que no te das cuenta. Por ejemplo, yo adquirí muchos conocimientos de “angularjs pasivo“. Como Guille es más rápido que yo pensando y empezó el proyecto manejando más de AngularJS, yo solía ser un mero espectador cuando encontrábamos una solución a un problema en JS. No soy manco: a veces se me ocurría la solución a mí… pero normalmente (especialmente cuando estábamos cansados) la implementaba él porque le suponía menos esfuerzo. Con lo que yo no terminaba de asimilar las cosas.

Lecciones aprendidas. Cómo y cuando hacemos pairing ahora:

  • hacemos pairing siempre que lo que nos impide avanzar es el conocimiento (ya sea técnico o de dominio).
  • hacemos pairing siempre que se va a tomar una decisión de diseño importante en la que se va a basar el proyecto (cómo vamos a organizar los componentes, si se va a usar tal o cuál patrón, estrategia de testeo, etc…)
  • siempre que hacemos pairing tenemos una lista preparada con el orden del día. Y sí: normalmente hacemos pairing de jornadas completas, preparando el entorno previamente para ser productivos y tener toda la información disponible y la posibilidad de tener discusiones productivas.
  • es importante no hacer pairing cuando quieres asimilar algo que has aprendido.

Como consecuencia de todo esto, en el último proyecto que hemos hecho juntos habremos hecho un día a la semana de trabajo en pareja. Al menos durante la fase principal del proyecto, acumulando en ese día las decisiones de diseño y la lista de cosas que queríamos aprender del otro. Inventándome la cifra, diré que habremos hecho un 10-15% de pairing.

¿100% o 15% de pairing? Para mí aquí ( como siempre) la clave es el contexto. Y el punto de vista desde el que analizar ese contexto, es el del conocimiento. Si analizo el proyecto en el que hicimos 100% de trabajo en pareja y soy sincero conmigo mismo, no creo que hubiéramos acabado antes ni mejor haciéndolo por separado. No creo que hubiera salido más barato ( argumento clásico en contra del trabajo en pareja). Sin embargo, si analizo el proyecto donde hemos hecho 10-15% de pairing, si que creo que más tiempo hubiera supuesto perder el tiempo. Y también sé que trabajar más por mi cuenta en AngularJS me ha hecho mucho más ágil e independiente.

 

by Luis Artola at July 22, 2014 07:16 AM

July 21, 2014

Variable not found

Enlaces interesantes 167

Enlaces interesantesAhí van los enlaces recopilados durante la semana pasada, espero que os resulten interesantes ;-)

.Net

ASP.NET

Azure / Cloud

Conceptos/Patrones/Buenas prácticas

Data access

Html/Css/Javascript

Visual Studio/Complementos/Herramientas

Cross-platform

Otros

Publicado en Variable not found

by José M. Aguilar (noreply@blogger.com) at July 21, 2014 02:26 PM

Programania

Panel Time Control

Éste es un pequeño apunte para recordar un panel que nos ha funcionado muy bien a Guille y a mí en un desarrollo que hemos hecho a presupuesto cerrado.

la foto

 

El panel es una especie de Story Map traspuesto. Cada columna es una entrega (diseñamos una estrategia con dos demos y una entrega final). Cada fila es un vertical de la aplicación (un “context boundary” que se diría en DDD).  La primera celda de cada fila contiene un glosario de términos del vertical y una lista de dudas o incertidumbre a ir aclarando.

No dimos color a los post-it´s. Distinguimos la funcionalidad del spike o tarea técnica poniendo de título al post-it “spike”. Viéndolo en retrospectiva hubiera estado bien darles un color de post-it distinto. Lo que si distinguimos fue el feedback/detalle descubierto en las demos(post-it amarillo), de la funcionalidad original (verde). Para visualizar si una funcionalidad estaba terminada, simplemente la tachábamos.

Para visualizar las horas que habíamos empleado (clave en éste proyecto a precio cerrado) usamos el post-it fucsia. Cada semana actualizábamos las horas, moviendo el post-it hacia la derecha proporcionalmente. De tal manera que era fácil ver si estábamos en el último tercio de horas y todavía en el segundo tercio de funcionalidades (vamos tarde), etc…

En definitiva, nos ha funcionado muy bien para controlar el release plan y controlar el tema económico. También para gestionar la incertidumbre del proyecto y el detalle de las funcionalidades.

Creo que éste panel no funcionaría en cualquier contexto. El panel obedece a un escenario donde no hay bugs (porque todo el trabajo diseñado es anterior a que se ponga en producción de verdad el software) y donde al estar dos desarrolladores es fácil saber quién está haciendo qué.

 

by Luis Artola at July 21, 2014 06:37 AM

July 17, 2014

Programania

Cynefin: ¿complejo o complicado?

Siguiendo un poco con la importancia de distinguir entre simple, complejo, complicado, etc… Es muy interesante el marco de decisión( o de análisis) Cynefin.

Cynefin_framework_Feb_2011

¿Cómo tomar decisiones o analizar un problema?

  • Si existe una relación clara entre causa y efecto, el escenario es simple. Puedes percibir la situación, categorizarla y, en función de la categoría, responder. Existen unas recetillas que te dicen en función de la categorización cuál es la mejor respuesta (best practices).
  • Si existe una relación entre causa y efecto, pero no está clara, el escenario es complicado. Requiere experiencia y análisis antes de actuar. Pueden existir unas buenas prácticas pero no una sola manera de hacer las cosas bien.
  • Si existe una relación entre causa y efecto, pero sólo eres capaz de establecerla a posteriori y, además, las consecuencias de lo que está ocurriendo no son predecibles, el escenario en el que te encuentras es complejo. La situación requiere probar varias cosas, coger feedback y actuar. La manera buena de hacer las cosas va emergiendo en función del feedback. No es conocida a priori.
  • Si no existe ninguna relación entre causa y efecto, ni siquiera analizando las cosas a posteriori, estás en una situación caótica. Probar para obtener feedback no sirve porque al repetir no necesariamente va a ocurrir lo mismo. La única posibilidad es dar un paso al frente, actuar y ver qué pasa. Aquí eres siempre un novato y no puedes extraer buenas prácticas en función de la experiencia.

Creo que en general nos movemos entre lo complejo y lo complicado. Y que es difícil saber cuando pararte a analizar bien las cosas y cuando no analizarlas tanto e intentar hacer algo para tener feedback rápido. Me gusta la manera en la que Cynefin enmarca todo esto.

Para un análisis muy bueno sobre Cynefin y Agilismo el post de Liz Keogh.. y ¡ojo a la respuesta de Jon Reffies!

 

by Luis Artola at July 17, 2014 06:38 AM

July 16, 2014

Yukei

Cómo usar un certificado SSL autofirmado de forma segura

Hace un par de publicaciones atrás, explicaba cómo configurar un certificado SSL autofirmado para la administración de WordPress, y señalaba la dificultad de comprobar la integridad de la comunicación entre el cliente y el servidor debido a que un certificado autofirmado no está validado por una autoridad de certificación comercial, como las que se incluyen entre los certificados aceptados por los navegadores más populares.

Aunque por una parte esto podría entenderse como una ventana abierta para ataques de man-in-the-middle, lo cierto es que es posible eliminar el riesgo de este tipo de ataques al utilizar un certificado autofirmado siguiendo un procedimiento relativamente sencillo.

Lo importante es comprender una diferencia fundamental en la forma en que funciona un certificado autofirmado con relación a uno comprado de una autoridad certificadora. Con ambos tipos, la comunicación entre el cliente y el servidor está encriptada, pero la manera en que validan la autenticidad del receptor del mensaje es fundamentalmente distinta.

¿Cómo se comprueba la identidad del sitio en un ceritificado autofirmado?

En un certificado adquirido de una autoridad de certificación, es ésta es la que valida la identidad del servidor, ya que aplica su firma sobre la petición de certificación que luego el navegador puede comprobar verificando su propia base de datos de certificados raíz.

De este modo, el navegador confía en que un sitio es quien dice ser ya que el certificado que éste te ofrece tiene una firma que corresponde con la firma del certificado raíz que ha verificado su identidad.

827d6a0701

En un certificado autofirmado no existe un tercero que valide el certificado, y por eso al intentar conectarnos por primera vez nos muestra la advertencia de “Esta conexión no es de confianza”.

Sin embargo la validación de un tercero no es estrictamente necesaria para aseverar la seguridad de la conexión, ya que se puede reemplazar por una cadena de confianza de persona a persona — en lugar de delegar la verificación de la identidad a un tercero, tienes que confiar en que la persona que te entrega el certificado pueda validar que corresponde al sitio del que dice ser.

Es decir, quien te entrega el certificado (o tú mismo, si fuiste quien lo creó) es quien te afirma que es un certificado válido para conectarse a un sitio.

Para poder asegurar que tu conexión con el sitio va a estar protegida, el paso final es instalar el certificado autofirmado en tu navegador, de modo que incluso en el primer intento de conexión, pueda verificar que el sitio al que supuestamente te estás conectando, corresponda realmente al sitio que te quieres conectar (es decir, eliminar el factor MITM).

Instalar el certificado autofirmado

En primer lugar, debes distribuír el certificado a las personas que se van a conectar al sitio en cuestión. Obviamente debes preferir un método seguro de hacerlo, ya sea personalmente o a través de algún servicio para compartir archivos. Si lo vas a hacer por correo electrónico, lo ideal sería que fuera firmado con PGP.

Si usas Firefox, debes ingresar a Preferencias → Avanzado → Certificados. Clickea el botón de “Certificados” y luego “Importar”.

configurar-certificado-ssl-autofirmado-firefox

Al seleccionar el archivo del certificado, se mostrará un diálogo que te preguntará si deseas confiar en el certificado. Debes seleccionar la opción de Confiar en esta CA para identificar sitios web y finalmente Aceptar.

Con Chrome, el proceso sigue los mismos pasos.

Con esto el certificado ya queda instalado y te puedes conectar seguramente al sitio web.

Tags: , , ,

Related posts

The post Cómo usar un certificado SSL autofirmado de forma segura appeared first on yukei.net.

by Felipe Lavín Z. at July 16, 2014 11:15 PM

Adseok

Google+ elimina la restricción del nombre real y ya se pueden usar seudónimos y nicks

Artículo Google+ elimina la restricción del nombre real y ya se pueden usar seudónimos y nicks publicado en Adseok SEO.

google-plus-logoGoogle ha anunciado por fin que elimina la obligación de utilizar el nombre real en Google+. Cuando Google + se lanzó hace tres años solo se podía utilizar el nombre real si querías utilizar la herramienta. Esto impedía a muchos webmasters crear una cuenta con el nombre de su web.

Parece que ahora ha decidido eliminar esta restricción disculpándose y agradeciendo a la comunidad que venía reclamando esta opción desde hace mucho tiempo. De momento algunas cuentas bloqueadas siguen bloqueadas. También ha establecido el límite de cambio de nombre cada 90 días.

Está por ver en qué afecta esto el funcionamiento de la red social, pero la eliminación de las fotos de autor en los resultados han podido acelerar este proceso.

No sabemos las razones exactas de este cambio de parecer, pero sabemos que la mayoría de la gente prefiere no usar su nombre propio y esto estaba creando un serio problema con los comentarios de YouTube que quizá se pueda solucionar con esta medida.

Artículo Google+ elimina la restricción del nombre real y ya se pueden usar seudónimos y nicks publicado en Adseok SEO.

by Adseok at July 16, 2014 03:09 PM

Google avisará al usuario cuando una web con flash no funcione en su dispositivo

Artículo Google avisará al usuario cuando una web con flash no funcione en su dispositivo publicado en Adseok SEO.

Puede ser frustrante para un usuario llegar a una página y que no funcione porque su dispositivo, en general el móvil, no tiene disponible dicha tecnología. Esto es habitual con Flash, que no funciona en iOS ni Android 4.1 o superior.

flash-serp-noteGoogle ha decidido que a partir de ahora mostrará al usuario una advertencia indicando que dicha página no funcionará en su dispositivo. Podemos ver un ejemplo en la imagen: “Uses Flash. May not work on your device. Try anyway | Learn more.”

Como alternativa a Flash, Google recomienda usar HTML5 y actualziar tus webs porque esta tecnología funciona en todo tipo de sistemas y dispositivos.

Además sugiere dos nuevos recursos para construir webs en HTML5:

  • Web Fundamentals: una fuente organizada para las mejores prácticas modernas
  • Web Starter Kit:un framework que soporta las mejores prácticas básicas de la web listo para usar

Web Fundamentals incluye las mejores prácticas para el diseño responsive, como no bloquear los css, js o imágenes con el robots.txt u otro sistema, ya que Google es capaz de acceder a estos recursos externos e interpretar qué versión de la web se está usando.

Para saber si Google está penalizando la versión móvil de tu web puedes utilizar Fetch and render en Webmaster Tools y ver cómo Google interpreta tu web.

Artículo Google avisará al usuario cuando una web con flash no funcione en su dispositivo publicado en Adseok SEO.

by Adseok at July 16, 2014 07:20 AM

July 15, 2014

Maestros del Web (Editorial)

Cómo convertir el tráfico de tu sitio web en ventas. Cinco estrategias

Las estrategias de mercado de sitios web basadas en visitantes únicos son el cáncer de este bonito mundo de Internet, una enfermedad que va en contra del espíritu de la creación de contenido de calidad y de estrategias sólidas que apunten a algo más que atraer visitas y números.

Después de todo Internet nos ha demostrado que si quieres atraer visitas a tu sitio nada mejor que un par de boobies, pero en realidad creemos que se pueden crear estrategias más inteligentes y sostenibles a largo plazo. En este post te enseñaremos algunas estrategias para convertir tu tráfico en ventas y así mostrarles a todos esos orgullosos de sus impresionantes cifras de tráfico que quizás a tu sitio no lo visitan tanto pero que sabes hacer cosas para que cada visita tenga un objetivo y se convierta en algo de utilidad para tu negocio.

¿Para qué sirve el tráfico de tu sitio?

El objetivo de una estrategia de content marketing es atraer visitas a un sitio web. Pero piénsalo, si eres el dueño de un centro comercial ¿quieres que se llene de gente que mira las vitrinas y eventualmente compra un helado o que la gente entre a comprar? Lo que quiero decir es que tener cantidades absurdas de tráfico no se traduce necesariamente en que la estrategia de marketing que estás desarrollando se exitosa: lo será (y podrás presumir) en el momento en que ese tráfico se transforme en conversiones, así como toda esta gente en el centro comercial significará algo cuando entren a los locales a comprar. Si los objetivos de conversión no se están cumpliendo puedes tener unas cifras de tráfico impresionantes pero -a menos que vivas estrictamente de la pauta y ni siquiera- todo lo que estás haciendo es perdido: estás perdiendo el tiempo con gente que entra a tu sitio muy seguido pero no hace nada más allá. Si es así seguramente eres el ÚNICO culpable. ¿Cómo arreglarlo?

Vamos a convertir visitas en clientes potenciales

Gracias al growth hacking, un conjunto de estrategias para utilizar la creatividad y ser mucho más ágil para atacar mercados, crecer y convertir sin gastar un montón de dinero en publicidad masiva, cualquier persona puede convertir la inversión que hace en atraer tráfico en ventas directas. Si sigues estas 5 técnicas de growth hacking tu vida puede ser mucho mejor, dejarás de presumir de todo ese tráfico que tiene tu sitio y al fin te servirá para algo: para aumentar tu tasa de conversión.

1. Estudia y conoce a tus clientes

Todo estudio de mercado tiene una sola palabra de fondo: NECESIDAD. Ya que toda estrategia de marketing online debe estar precedida por un proceso de planeación, es importante targetizar a los usuarios a los que se quiere llegar con un estudio de mercado. Esto significa: saber quiénes llegan a tu sitio y por qué motivos, qué buscan, qué quieren, qué necesitan o que podrían necesitar o … qué quieres que necesiten de ti ;) . Cuánto más tiempo dediques a estudiar a tu público objetivo tendrás mucho más datos y pistas para atacar el mercado directo a las necesidades. Estos filtros en el estudio de mercado para tener visitantes de calidad pueden ser aplicados al hacer la investigación de palabras clave. Como ya sabemos es importante optimizar nuestro contenido hacia keywords relevantes con una buena cantidad de búsquedas, sin embargo debemos conseguir palabras más específicas orientadas al público que sabemos que está listo para convertir en nuestro sitio web. Por ejemplo si tenemos un sitio web de venta de lentes de sol deberíamos apuntar a keywords como “dónde comprar lentes ray ban”, “lentes de sol ray ban a domicilio”, etc. Herramientas útiles para estudios de mercado: KeywordTool.io para conocer el lenguaje que utilizan los usuarios en el buscador. Busszumo ayuda a encontrar los temas más aceptados en redes sociales acerca de un cierto tema, autor o sitio web.

2. El landing page como bitácora de lo que quieres que tus clientes hagan

Es importante optimizar el sitio web para que cada una de las páginas a las que llegan tus usuarios tenga un objetivo, ya que una buena cantidad de ellos llegarán a las páginas internas y no solamente al inicio. Las páginas de aterrizaje (landing pages) son la mejor forma de personalizar por completo y brindarles la mejor experiencia. En las campañas de anuncios tenemos el control total para asignar una página por campaña si así lo deseamos, esto nos da la capacidad de moldear cada página según el tráfico objetivo. Se debe tener en cuenta que no todas las páginas deben tener como objetivo directo vender algo. Está bien que algunas cumplan con la función de captar posibles compradores como por ejemplo a través de listas de mailing, así indirectamente estaríamos capturando un cliente potencial al que podemos enviar una campaña dirigida a una página de aterrizaje optimizada para vender nuestro producto. Algunos tips para tener en cuenta a la hora de optimizar las páginas de aterrizaje:

  • Captar la atención del usuario con un encabezado claro y conciso.
  • No olvidar el objetivo, repetir los botones de llamado a la acción y los formularios de captación de emails.
  • Todo entra por los ojos. Las gráficas, imágenes y fotografías de apoyo importan más de lo que crees.
  • Mantener la página muy liviana, la regla acá es que menos es más, en lo que a elementos visuales se refiere.
  • No olvidar que las páginas de destino tengan opciones para compartir en sitios sociales.

Unbounce ofrece un servicio de construcción de landing pages para aquellos que no tengan conocimientos en programación o diseño. Tiene un editor con plantillas, ejemplos y la posibilidad de probar diferentes diseños.

3. No hacer tests A/B, hacer tests A/B/C y hasta D

Los tests A/B consisten en probar múltiples variaciones de un mismo diseño y a través de estas pruebas medir y analizar los resultados para constatar qué versión trae mejores conversiones. Captura de pantalla 2014-07-15 a la(s) 16.05.47 Los beneficios de probar los diseños de las páginas de un sitio web son inmensos, el análisis de los datos obtenidos por medio de los tests a/b permiten conocer de una manera más profunda a los usuarios y posibles clientes potenciales. El hack consiste en ir más allá del a/b y probar más de dos versiones, hay que tener en mente que siempre existe algo que puede mejorar, como si estuvieras siempre en beta. Hay que probar una y otra vez para combinar lo mejor de cada uno de los diseños y obtener cada vez un mejor resultado. Optimizely es una herramienta que te permite hacer tests sin necesidad de tocar una línea de código y con la posibilidad de medir todo lo que pasa en las páginas de aterrizaje.

4. En Internet tienes que ser el más rápido, optimiza la velocidad de carga de tu sitio

La velocidad de carga de un sitio web es un punto que tiene incidencia en factores como el SEO, la experiencia de usuario y por supuesto el ratio de conversión. Por cada segundo que tarda un sitio web en cargar hay una disminución del 7% en la tasa de conversión. La recomendación por parte de Google es que un sitio web cargue con la misma velocidad que se tarda el buscador en dar los resultados. Es un gran reto, pero si lo logras representa una enorme ventaja para tu sitio, por esta razón es una característica de tu sitio que debes atacar ya mismo. La velocidad de carga depende de varios factores: el peso de las imágenes, la caché, el servidor, etc. Google PageSpeed es una herramienta gratuita de Google que ayuda a determinar factores a atacar para disminuir el tiempo de carga.

5. Busca a tus clientes felices para que cuenten al mundo lo mágico que es tu producto

Apoyar el contenido de calidad con casos de estudio o testimonios (dependiendo del producto o servicio) puede ser el arma principal para conseguir clientes potenciales, si se utilizan en el camino correcto. La razón principal para hacerlo es ayudar al usuario a ganar credibilidad en tu producto. Los testimonios son una oportunidad increíble para demostrar la calidad del producto o servicio. El principal consejo es no crear testimonios falsos, no tenemos que explicarte por qué ¿cierto? Si tu producto es verdaderamente bueno seguro encontrarás muchas personas dispuestas a hablar de sus bondades, para mentir sobre las maravillas que hace lo que vendes ya tenemos las televentas. <iframe allowfullscreen="allowfullscreen" frameborder="0" height="480" src="http://www.youtube.com/embed/AHfDd7HCREg" width="640"></iframe> Es bueno conocer a los clientes actuales para tener su feedback y usar su testimonio, no hay que tener miedo de contactar a las personas que compran los productos o servicios y dedicarles 30 minutos en un café o, si las distancias lo impiden una conversación por skype, valerte de un motivador gratuito como un PDF con información especial del uso de los productos, un mes del servicio o algo que tenga valor para el cliente. Al publicar casos de estudio también se muestra el éxito del servicio de una manera directa. Es bueno que estén apoyados por métricas reales de los objetivos logrados y la satisfacción del cliente. Hay muchos caminos para convertir visitantes en clientes potenciales. Sin importar el tipo de servicio o producto que se tenga la clave está medir, analizar y aprender de la interacción de los usuarios con el sitio web y así brindar una excelente experiencia de usuario. Las ventas y las conversiones llegarán por añadidura, lo más importante es hacer todo este trabajo bien.

by Alejandro González at July 15, 2014 07:22 PM

Variable not found

Novedades de SignalR 2.1 (y III): progreso de acciones

image[2]La revisión 2.1 de SignalR ha incluido otra característica que puede ser interesante en determinados escenarios: la posibilidad de notificar al cliente del progreso de la ejecución de una acción invocada en el hub.

Aunque en los métodos que normalmente implementamos no tiene demasiada utilidad, sí puede ayudar a mejorar la interacción y experiencia de usuario cuando se trate de ejecutar métodos costosos como el siguiente:
public class GodsOfTheForest: Hub
{
[...]
public async Task<int> GetTheAnswerToLifeTheUniverseAndEverything()
{
for (var i = 0; i < 10; i++)
{
await Task.Delay(1000);
// Do something very important here
  }
return 42;
}
}
Hasta ahora, si desde el cliente llamábamos a este método del hub, sólo podíamos tomar el control cuando la llamaba finalizaba, bien obteniendo el resultado si todo había ido bien, o bien capturando el error producido. Por ejemplo, en Javascript lo conseguíamos con un código como el siguiente:
proxy.server.getTheAnswerToLifeTheUniverseAndEverything()
.done(function (result) {
console.log("The answer is: " + result);
})
.fail(function(err) {
console.log("Oops, something went wrong: " + err.message);
});

Notificación de progreso en SignalR 2.1

Para notificar el progreso de la ejecución en un método del hub, a partir de SignalR 2.1 tenemos que hacer básicamente dos cosas:
  • En primer lugar, añadir al método del hub un parámetro de entrada adicional de tipo IProgress<T>, que obligatoriamente debe ser el último del método. T es el tipo de dato que vayamos a utilizar para notificar el progreso al cliente; por ejemplo, si vamos a notificar un porcentaje, podríamos usar Progress<int>.
  • En segundo lugar, en el punto del código desde donde queremos realizar la notificación, invocar al método Report() del parámetro anterior suministrándole el valor de progreso deseado.
Pero seguro que queda más claro si lo vemos con un poco de código basándonos en el ejemplo anterior:
public async Task<int> GetTheAnswerToLifeTheUniverseAndEverything(
IProgress<int> progress)
{
for (var i = 1; i <= 100; i++)
{
await Task.Delay(1000);
progress.Report(i);
}
return 42;
}
De esta forma tan simple estaremos enviando al cliente el progreso de la operación :-) Por supuesto, podríamos enviar al cliente notificaciones de cualquier tipo, como en el siguiente ejemplo, donde usamos IProgress<string> para poder notificar con mensajes de texto:
public async Task<int> GetTheAnswerToLifeTheUniverseAndEverything(
IProgress<string> progress)
{
progress.Report("Just starting...");
await Task.Delay(1000);
progress.Report("Working hard...");
await Task.Delay(1000);
progress.Report("Almost done...");
await Task.Delay(1000);
progress.Report("One second to finish...");
await Task.Delay(1000);
progress.Report("Finished");
return 42;
}

Consumo desde clientes del hub

El consumo de los datos de progreso sería bastante simple desde nuestro cliente Javascript, simplemente usar este método progress() para especificar la función callback que recibirá los datos de progreso:
proxy.server.getTheAnswerToLifeTheUniverseAndEverything()
.progress(function (value) {
log("Progress: " + value + "%");
})
.done(function (result) {
log("The answer is: " + result);
});
Ah, y un detalle muy importante a este respecto: el uso de esta característica requiere la versión 1.7 o superior de jQuery, más que nada porque en el objeto Deferred que retornan las llamadas a las funciones del hub antes no existía el método progress() que estamos usando para recibir las notificaciones de progreso.

Desde clientes .NET es igualmente sencillo. Se han añadido sobrecargas al método Invoke() de forma que podemos indicar el código a ejecutar al recibir el progreso de la operación. El siguiente código muestra una llamada a un método que retorna un entero y cómo gestionar las notificaciones de progreso que nos llegan también en forma de número entero:
int result = await proxy.Invoke<int, int>(
"GetTheAnswerToLifeTheUniverseAndEverything",
(int progress) =>
Debug.WriteLine("Progress: " + progress + "%")
);
El primer parámetro genérico del método Invoke()es el tipo de datos que retornará la llamada al hub, como ha sido siempre hasta ahora, mientras que el segundo es el utilizado para notificar el progreso. Así, si los mensajes de progreso nos llegan en forma de cadena de caracteres, deberíamos usar:
int result = await proxy.Invoke<int, string>(
"GetTheAnswerToLifeTheUniverseAndEverything",
(string progress) => Debug.WriteLine(progress)
);
Bueno, pues con este post podemos dar por cerrada la serie sobre las novedades de SignalR 2.1. Hay algunas más, pero creo que no son tan interesantes como las que hemos ido viendo; si tenéis interés en conocerlas, podéis acudir al repositorio de Github de SignalR.

Publicado en Variable not found.

by José M. Aguilar (noreply@blogger.com) at July 15, 2014 03:18 PM