Hoy en día es extraño encontrar una aplicación web que no haga uso de AJAX, unas lo hacen de manera inteligente y otras no tanto. Vamos a ver qué podemos hacer para reducir un poco(en caso de no haberlo hecho ya) la carga que deben soportar nuestros servidores.

El consejo básico es simple: es preferible que el contenido dinámico sea generado en el lado del cliente con Javascript a que el trabajo lo hagan nuestras máquinas. Es claro que no siempre se podrá hacer eso, pero por lo general sí, como ejemplo tenemos datos que se actualizan periódicamente o que se estructuran de forma tabular o en listados.

La justificación del consejo radica en 2 puntos, en primer lugar podemos reducir el tiempo de CPU en el servidor consumido por petición, en segundo lugar podemos reducir el ancho de banda usado si enviamos datos como JSON en vez de contenido HTML pregenerado. Así dicho suena creíble, pero tenemos que comprobarlo (me fijaré en el caso concreto de PHP).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

 
// Codigo que sirve petición con JSON
$link = mysql_connect('xxx', 'xxx', 'xxx');
 
mysql_select_db('xxx');
 
$dbresult = mysql_query('SELECT nick, passwd, name FROM json');
 
$outresult = array();
 
while ($outresult[] = mysql_fetch_row($dbresult));
array_pop($outresult);
 
echo json_encode($outresult);
 
mysql_close($link);
 
?>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

 
// Codigo que sirve la petición con HTML
 
$link = mysql_connect('xxx', 'xxx', 'xxx');
 
mysql_select_db('xxx');
 
$dbresult = mysql_query('SELECT nick, passwd, name FROM json');
 
while ($row = mysql_fetch_row($dbresult)) {
    echo '

Antes de hablar sobre como se procesa la petición en el lado del cliente haré algunas observaciones. Aunque en este código no está, añadí código para medir cuantos milisegundos tardaba cada script en ejecutarse. Para aumentar la fiabilidad de las pruebas conté solo el tiempo que se tarda en procesar el resultado de la consulta a la base de datos y enviarla. Así pues excluyo el acceso a la base de datos y el cierre de la conexión de las medidas efectuadas, que son las siguientes (había 200 registros en la base de datos):

• Petición servida en JSON (10 muestras):
• Número de bytes enviados: 18830
• Pico de memoria consumida: 305128 bytes ~ 297.976 Kb
• Tiempo mínimo: 0.62799 ms
• Tiempo máximo: 1.2610 ms
• Tiempo medio: 0.9064 ms
• Desviación típica: 0.1436 ms
• Petición servida en HTML (10 muestras):
• Número de bytes enviados: 23854
• Pico de memoria consumida: 100008 bytes ~ 97.664 Kb
• Tiempo mínimo: 0.7529 ms
• Tiempo máximo: 2.4579 ms
• Tiempo medio: 1.2909 ms
• Desviación típica: 0.4956 ms

Lo más destacable de estas medidas es el número de bytes enviados, con JSON podemos ahorrar (como mínimo) un 21.06% de ancho de banda. Digo como mínimo porque en este ejemplo el código HTML generado es más bien austero, ya que no incorpora clases CSS ni identificadores para facilitar el manejo del DOM.

El segundo dato nos muestra la cantidad máxima de memoria consumida durante la petición procesada. Como era esperable, la primera versión del código consume más memoria debido al array que va construyendo y a la cadena JSON que ensambla finalmente a partir de la lista generada. En este punto hay que tener en cuenta que, si somos listos, esto no tiene por qué suponer un gran problema ya que ese mismo array podríamos (y de hecho es recomendable) guardarlo usando (por ejemplo) Memcached de forma que ahorramos posteriores consultas a la base de datos.

Respecto a los otros datos tengo que decir que no son significativos en lo tocante al asunto JSON vs HTML, pues la comparativa no es del todo justa. Sin embargo, lo que sí podemos ver es qué supone usar repetidas veces la primitiva echo frente a un solo uso. Por un lado aumentan los tiempos de ejecución, y por otro aumenta la dispersión de las medidas (ver desviación típica), lo que puede tocar un poco las narices cuando queremos hacer cálculos de cara a escalar nuestra infraestructura.

Otra versión del código que genera HTML es la siguiente:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

 
$link = mysql_connect('xxx', 'xxx', 'xxx');
 
mysql_select_db('xxx');
 
$dbresult = mysql_query('SELECT nick, passwd, name FROM json');
 
$outresult = '';
 
while ($row = mysql_fetch_row($dbresult)) {
    $outresult .= '

Los datos que arroja esta versión son los siguientes:

• Petición servida en HTML (2ª versión, 10 muestras):
• Número de bytes enviados: 23854
• Pico de memoria consumida: 126432 bytes ~ 123.469 Kb
• Tiempo mínimo: 0.3531 ms
• Tiempo máximo: 0.8111 ms
• Tiempo medio:  0.5435 ms
• Desviación típica: 0.1577 ms

Podemos extraer algunas conclusiones más de esta tercera lista de cifras. En primer lugar se nos podría ocurrir adoptar el mismo enfoque para la generación de JSON, es decir, olvidarnos de construir un array y pasar a construir un string directamente (de hecho obtendríamos mejores resultados, pues la cadena JSON es más corta que la cadena HTML). Si no vamos a usar más esos datos en un lapso de tiempo breve parece lo más acertado, pero si tenemos planeado acceder a ellos otra vez puede que sí nos convenga construir la lista como en el primer ejemplo de código.

Un detalle interesante es que teniendo un array probablemente sea más rápido generar un texto JSON con la función json_encode que concatenando strings en un bucle. El problema que tenemos (en este caso) es que el driver nativo de MySQL para PHP no permite obtener una lista con todas las filas directamente, y consecuentemente nos vemos forzados a construirla nosotros (que es menos eficiente que usar un método nativo de PHP programado en C, y de ahí que el tercer ejemplo rinda mejor que el segundo).

Tengo que admitir que no conozco por qué no hay un método nativo de PHP para obtener en forma de array todos los resultados de una consulta a una base de datos MySQL, pero creo que, en caso de no haber razones de peso... puede ser una buena jugada implementar en C una extensión del lenguaje que haga precisamente eso para ahorrar un valioso tiempo de ejecución.

En el lado del cliente las diferencias no han sido estadísticamente significativas para mi ejemplo, aunque es de esperar que los tiempos de descarga sean menores con JSON, mientras que los de proceso sean menores con HTML. El tiempo total dependerá de la potencia de cómputo del cliente y del ancho de banda de la conexión, por lo que algunos usuarios saldrán beneficiados mientras que otros puede que tarden algunos milisegundos más en obtener la página web completamente renderizada.

Sin más rodeos, resumen rápido: JSON permite reducir el ancho de banda consumido en más de un 21%, hacer un solo echo reduce el tiempo de ejecución (la reducción puede sobrepasar fácilmente el 50%, en el caso del ejemplo es un 57.89%) y la dispersión estadística de esos mismos tiempos (lo que nos puede ayudar a realizar mejores cálculos para escalar la plataforma o puede servir para que los balanceadores de carga tengan datos más fiables con los que trabajar).

Como apunte final solo quiero destacar que es importante realizar experimentos y comprobar los hechos por uno mismo, pues la tecnología evoluciona constantemente y es probable que ciertas afirmaciones no se puedan sostener en el tiempo. Además me he dejado algunas técnicas en el tintero, como usar los métodos ob_start y ob_end_clean, que nos permiten aprovechar el buffer de escritura para evitar la necesidad de concatenaciones. Espero que viendo la extensión del artículo comprendáis que no lo haya comentado en profundidad. Espero que os haya sido útil .

• com.blogspot.elblogdepicodev.tapestry.pages
• com.blogspot.elblogdepicodev.tapestry.components
• com.blogspot.elblogdepicodev.tapestry.mixins
• com.blogspot.elblogdepicodev.tapestry.base

La aplicación: W.I.Z.A.R&D

La aplicación que vamos a implementar se llama WIZARD (Weapon Inventory for Zombie Apocalypse Research & Development) y es una aplicación muy sencilla que nos ayuda a seleccionar las mejores armas para sobrevivir a un apocalipsis zombie. Su interfaz de usuario se compone de tres pantallas:

Pantallas de W.I.Z.A.R&D

La primera pantalla muestra una lista con las armas que tenemos seleccionadas para sobrevivir al apocalipsis zombie e incluye el peso total de nuestro inventario. Al pulsar sobre un arma se accederá al a segunda pantalla, donde podremos introducir los datos que hemos recogido de ese arma.

También podremos añadir nuevas armas pulsando sobre el botón Añadir, con lo que se mostrará un cuadro diálogo como el de la tercera pantalla. Por último, podremos eliminar armas pulsando sobre el botón de eliminar que aparece a la derecha de cada arma de la lista.

Queda claro con esto que los ejemplos de aplicaciones siguen sin ser lo mío, pero para jugar un poco con jQuery Mobile y Knockout nos puede servir.

Como vimos en la introducción del tutorial, para representar cada pantalla (vista en terminología MVVM) jQuery Mobile usa elementos div con el atributo data-role="page". De momento vamos a centrarnos en cómo implementar cada pantalla con jQuery Mobile, sin emplear Knockout ni enganchar eventos de navegación para conocer mejor algunas características de jQuery Mobile.

La lista de armas

El código de la pantalla principal de W.I.Z.A.R&D es el siguiente:

	

		
W.I.Z.A.R&D
		Añadir
	
	

		

			

				Martillo
				
			
			
		
	
	

		
Peso Total: 3.45 kgs.
	

Cosas a tener en cuenta:

• La página queda contenida en un div con el atributo data-role="page". El id que asignamos al div es importante porque será lo que nos permita identificar la página y navegar hasta ella.
• Cada parte de la página tiene asignado su propio rol. Así tenemos la cabecera (data-role="header"), el contenido (data-role="content") y el pie (data-role="footer").
• Para mostrar una lista de elementos existe el rol listview. jQuery Mobile es además lo bastante listo para formatearla para que quede bonita y colocar el icono de eliminar a la derecha.
• Usando atributos data-* de HTML5 se pueden controlar más cosas, como la posición, el icono o incluso el tema.

Lista de armas. No está mal para lo fácil que ha sido.

Un factor a tener en cuenta es que toda la personalización que hace jQuery Mobile de los elementos html se realiza sólo al mostrar la página por primera vez, por lo que si añadimos dinámicamente nuevos elementos habrá que indicar a jQuery Mobile que reaplique la personalización. Veremos ejemplos de esto en la siguiente parte del tutorial.

Una cosa que resulta un poco confusa es que a veces para cambiar el aspecto o la posición de algo hay que usar atributos data-*, como el data-position="fixed" que aparece en el footer, y otras veces se usan clases css, como el ui-btn-right del botón de Añadir del header.

Modificar un arma

jQuery Mobile permite mantener las distintas páginas, es decir los distintos divs con el atributo data-role="page", en varios archivos y cargarlas a través de peticiones AJAX. Sin embargo, en este caso, y para mantener las cosas simples, todas las vamos a colocar en el mismo fichero html. El código correspondiente a la página de edición de un arma es éste:

	

		Back
		
Martillo
	
	

		

			

				Peso
				
			
			

				Munición
				
					Ilimitada
					Escasa
					Abundante
				
			
			

				Efectividad cuerpo a cuerpo
				
TODO
			
			

				Efectividad a distancia
				
TODO
			
		
	

No tiene mucho de especial. De momento con este código no se muestran las estrellitas para calificar el arma, eso lo haremos más adelante con Knockout.

Lo más reseñable es que para añadir un botón para volver a la página anterior sólo hay que añadir el atributo data-rel="back" al enlace y jQuery Mobile se encargará de todo.

Añadir un nuevo arma

Este es un caso un poco especial porque esta vista queremos mostrarla como un diálogo en lugar de como una página normal. Para ello usamos el siguiente código:

	

		
Añadir Arma
	
	

		Nombre:
		
		

			
Cancelar
			
Aceptar
		
	

Para crear el diálogo debemos marcar el div con rol data-role="dialog". De esta forma jQuery Mobile lo tratará como diálogo y le dará otro aspecto. Se supone que el diálogo debe estar siempre en un fichero html distinto, pero lo cierto es que en este ejemplo está todo en el mismo fichero html y funciona correctamente.

En este caso estamos haciendo uso de clases css de jQuery Mobile para colocar los botones de Cancelar y Aceptar uno al lado del otro en lugar de uno encima de otro. Para ello se usa la siguiente estructura:

	
Cancelar
	
Aceptar

Al englobar ambos botones en un fieldset con la clase ui-grid-a jQuery Mobile monta un grid que nos permite colocarlos en línea.

Para apreciar la diferencia entre usar un data-role="dialog" y un data-role="page", nada mejor que una captura de pantalla:

Así son los diálogos. Nada que ver con las páginas.

Por donde seguimos

Lo que tenemos de momento no son más que unas cuantas páginas estáticas e inconexas entre las que ni siquiera podemos navegar. En la próxima parte del tutorial introduciremos Knockout en la aplicación para tener un ViewModel con el que interactuar y hacer la cosa un poco más interesante.

De todas formas, si quieres ver el código completo del tutorial lo puedes encontrar ya en su repositorio de github.

Compartir enlace:

Posts relacionados:

1. Tutorial jQuery Mobile + Knockout (I): Sentando las bases
2. Tutorial node.js + express + jquery (II): Generando vistas con Jade
3. Tutorial node.js + express + jquery (I): Creando la aplicación

http://kpilibrary.com/

public class Friend
{
    [Required, StringLength(50)]
    public string Name { get; set; }
 
    [Range(0, 120)]
    public int Age { get; set; }
}

Validación manual de objetos

• el objeto a validar,
• un contexto de validación (que debemos crear previamente),
• una colección de ValidationResult en la que almacenaremos los errores,
• y, por último, si deseamos validar todas las propiedades (indicando true), o por el contrario preferimos parar el proceso en cuanto se detecte el primer error (false).

    private IEnumerable<ValidationResult> getValidationErrors(object obj)
    {
        var validationResults = new List<ValidationResult>();
        var context = new ValidationContext(obj, null, null);
        Validator.TryValidateObject(obj, context, validationResults, true);
        return validationResults;
    }

    var friend = new Friend { Age = -1, Name = "" };
    var errors = getValidationErrors(friend);
    foreach (var error in errors)
    {
        Console.WriteLine(error.ErrorMessage);
    }

    [Required(ErrorMessage="Please, enter the name")]
    public string Name { get; set; }

¿Y si los metadatos están en otra clase?

    // This class has been generated by a tool
    public partial class Friend
    {
        public string Name { get; set; }
        public int Age { get; set; }
    }
 
    // Let's associate the buddy class FriendMetadata
    [MetadataType(typeof(FriendMetadata))]
    public partial class Friend
    {
        
    }
 
    // Buddy class
    public class FriendMetadata
    {
        [Required]
        public string Name { get; set; }
 
        [Range(0, 120)]
        public int Age { get; set; }
    }

var descriptionProvider = new AssociatedMetadataTypeTypeDescriptionProvider(
     typeof(Friend), 
     typeof(FriendMetadata)
                          );
TypeDescriptor.AddProviderTransparent(descriptionProvider, typeof(Friend));

private static void registerBuddyClasses()
{
    var buddyAssociations = 
        from t in Assembly.GetExecutingAssembly().GetTypes()
        let md = t.GetCustomAttributes(typeof(MetadataTypeAttribute), false)
                .FirstOrDefault() as MetadataTypeAttribute
        where md != null
        select new { Type = t, Buddy = md.MetadataClassType };
 
    foreach (var association in buddyAssociations)
    {
        var descriptionProvider = 
            new AssociatedMetadataTypeTypeDescriptionProvider(
                association.Type, association.Buddy
            );
        TypeDescriptor.AddProviderTransparent(descriptionProvider, association.Type);
    }
}

private static void registerBuddyClassesUsingConventions()
{
    var allAssemblyTypes = Assembly.GetExecutingAssembly().GetTypes().ToList();
    var buddyAssociations =
        from t in allAssemblyTypes
        let buddy = allAssemblyTypes
                    .FirstOrDefault(other => other.Name == t.Name + "Metadata")
        where buddy != null
        select new { Type = t, Buddy = buddy };
 
    foreach (var association in buddyAssociations)
    {
        var descriptionProvider =
            new AssociatedMetadataTypeTypeDescriptionProvider(
                association.Type, association.Buddy
            );
        TypeDescriptor.AddProviderTransparent(descriptionProvider, association.Type);
    }
}

¿Y si quiero usar IValidatableObject?

public class Friend : IValidatableObject
{
    public string Name { get; set; }
    public int Age { get; set; }
 
    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
    {
        if (Name.Equals("albert", StringComparison.CurrentCultureIgnoreCase))
        {
            yield return new ValidationResult("I don't like Alberts!");
        }
    }
}

    private static IEnumerable<ValidationResult> getValidationErrors(object obj)
    {
        // First, data annotations
        var validationResults = new List<ValidationResult>();
        var context = new ValidationContext(obj, null, null);
        Validator.TryValidateObject(obj, context, validationResults, true);
 
        // Second, validate using IValidatableObject
        var validatable = obj as IValidatableObject;
        if(validatable!=null) 
            validationResults.AddRange(validatable.Validate(context));
 
        return validationResults;
    }

    var friend = new Friend { Age = -1, Name = "albert" };
    var errors = getValidationErrors(friend);
    foreach (var error in errors)
    {
        Console.WriteLine(error.ErrorMessage);
    }

En el siguiente link lo nuevo que se presento en el Service Update de Noviembre

http://blog.sonomapartners.com/2012/01/whats-new-in-the-microsoft-dynamics-crm-november-2011-service-update.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+typepad%2Fsonoma+%28Sonoma+Partners+Microsoft+CRM+Blog%29&utm_content=Bloglines

Las únicas diferencias a tener en cuenta son dos:

• Se añade una propiedad aChecked que sirve tanto para establecer qué elementos están seleccionados cuando se crea el control y para obtener la lista de elementos que se han seleccionado.
• El evento OnChange( oSender, nIndex, lChecked ) añade un nuevo parámetro lChecked que informa si el elemento que acaba de cambiar está seleccionado o no.

En el ZIP se incluye la DLL y la librería para Xailer 2.5

.Net

• Introducing Dragonfly – another .NET HTTP server
  
  Louis DeJardin
• Inside the Concurrent Collections: ConcurrentQueue
  
  Simon Cooper
• Using Async for File Access C# Team
• Aggressive Inlining in the CLR 4.5 JIT
  
  Sasha Goldshtein
• What is the defining characteristic of a local variable?
  
  Eric Lippert
• C#/.NET Little Pitfalls: Stopwatch Ticks are not TimeSpan Ticks
  
  James Michael Hare
• Inside the Concurrent Collections: ConcurrentStack
  
  Simon Cooper

Asp.net

• Adding rich Selector support for MVC
  
  Matt Hidinger
• Solving Real-world Theming Challenges with MVC4 and Sass
  
  Harvey Kandola
• Javascript and CSS Minifying/Bundling with the Microsoft.Web.Optimization Nuget package
  
  Maxime Rouiller
• Validaciones propias en ASP.NET MVC
  
  Eduard Tomás
• The flowchart of the IE rendering modes
  
  Chun Liu
• POP Forums v9.2 posted to CodePlex, with new languages, post voting and the scoring game
  
  Jeff Putz
• ASP.NET Response.Redirect
  
  Annie Luxton
• Fix: the value ‘x’ is not valid for Foo in ASP.NET MVC
  
  Code Inside Team
• Web Deploy – config Transformation
  
  Marc Rubiño
• Cómo simular otros navegadores para probar desarrollos Web
  
  José Manuel Alarcón
• 10 Things ASP.NET Developers Should Know About Web.config Inheritance and Overrides
  
  Jon Galloway
• Cómo obtener rutas absolutas en ASP.NET
  
  José Manuel Alarcón
• Push con SingalR
  
  Marc Rubiño
• Tracking API usage with Google Analytics
  
  Maarten Balliauw
• MVC – get some help
  
  Gregor Suttie

Azure / Cloud

• Release de SQL Azure Import/Export
  
  Ibon Landa
• Making Windows Azure Drive Letter Persistent
  
  Shawn Cicoria
• Getting Started with Windows Azure
  
  Scott Guthrie

Conceptos

• Gof – Singleton
  
  Sebis

Data access

• What do you want to see in Entity Framework?
  
  Julie Lerman
• HeidiSQL: Windows based interface for managing MySQL and Microsoft SQL databases
  
  Ansgar Becker
• RaptorDB - The Key Value Store V2
  
  Mehdi Gholam
• OraPoco: Trabajando contra Oracle
  
  Javier Torrecilla
• Why Entity Framework vNext will be EF5 and nothing else
  
  Diego B. Vega 

Html/Css/Javascript

• From jQuery to JavaScript: A Reference
  
  Jeffrey Way
• Some Thoughts On Functional JavaScript
  
  Derick Bailey
• Find the jQuery Bug #2: Point of No Return
  
  Elijah Manor
• JavaScript for C# developers: coercion
  
  Julian M. Bucknall
• Modernizr–Ejemplo práctico 2 : Utilizando Border Radius, elemento date y atributo required
  
  Gonzalo Pérez
• Server-Sent Events
  
  Remy Sharp
• Using HTML5 Web Storage in ASP.NET
  
  Bipin Joshi
• Creando objetos y aplicaciones configurables en Javascript
  
  Carlos Benítez
• 10 Excellent Free Rich-Text Editors
  
  jQuery4u
• SOLID JavaScript- The Dependency Inversion Principle
  
  Derek Greer
• Easing Functions in CSS3
  
  Kirupa Chinnathambi
• How Wikipedia uses HTML5 to save bandwidth
  
  Jef Claes
• The Top 10 Javascript MVC Frameworks Reviewed
  
  Gordon L. Hempton
• Using CSS3 Transitions, Transforms and Animation
  
  Rich Bradshaw

Visual Studio/Complementos

• Importing / Exporting Templates and Patterns in ReSharper 6.1
  
  Hadi Hariri
• C# + ReSharper = Awesome: Tip #8 – Extract Class From Parameters
  
  Alvin Ashcraft
• C# + ReSharper = Awesome: Tip #7–Move String to Resource
  
  Alvin Ashcraft's
• StyleCop v4.7.6.0 disponible
  
  Jorge Serrano  

Otros

• Breaking CAPTCHA with automated humans
  
  Troy Hunt
• Let's make TCP faster
  
  Yuchung Cheng
• El "Cargo Cult" de las pequeñas empresas
  
  José Manuel Alarcón
• El efecto Mateo y su influencia
  
  José Manuel Alarcón

Igual que en el anterior tutorial, quiero dejar claro que esto es sólo una pequeña introducción a dos librerías que me parecen útiles. No se trata de un catálogo de buenas prácticas y habrá muchos puntos que puedan (y deban) ser mejorados.

En este caso vamos a crear una pequeña aplicación web para dispositivos móviles usando jQuery Mobile y Knockout. Como creo que es importante conocer las bases para poder entender lo que estamos haciendo, antes de empezar a implementar nada vamos a presentar a nuestros nuevos amigos.

jQuery Mobile

jQuery Mobile es un framework que nos permite crear aplicaciones para dispositivos móviles. Por tanto, está optimizado para su uso con pantallas de pequeño tamaño e interfaces táctiles encargándose de ajustar el interfaz de usuario de los controles estándar html para que sean más atractivos y manejables en un entorno móvil.

Se ejecuta por completo en el lado cliente, en este caso, el browser del dispositivo. Para emplearlo, debemos añadir lo siguiente a nuestra página web:

Podemos usar la versión descargada o enlazar directamente a una versión online, tal y como explican en la su página de descarga.

jQuery Mobile se basa en la asignación de roles a los distintos elementos html para atribuirles determinadas funciones dentro de la aplicación. A partir de estos roles, se ajusta el aspecto del elemento. Para asignar los roles a los elementos se usa el atributo data-role:

Una aplicación desarrollada con jQuery Mobile se estructura alrededor del concepto de página. Una página no es más que un div que tiene asignado el rol page, como en el ejemplo anterior. En un único documento html podremos tener varias páginas simplemente añadiendo varios divs con el atributo data-role="page", y jQueryMobile se encargará de mostrar en cada momento únicamente el div correspondiente a la página que esté activa.

Además del rol usado para marcar las páginas, existen otros roles muy útiles como header, footer, etc. que permiten representar otros elementos dentro de la página, o listview, button, etc. que se usan para crear controles con los que el usuario puede interactuar.

Si quieres conocer en profundidad las opciones que ofrece jQuery Mobile, te recomiendo que consultes su documentación.

Knockout

Knockout es una librería diseñada para aplicar cómodamente el patrón MVVM en aplicaciones javascript. Al igual que jQuery Mobile se ejecuta por completo en el browser por lo que deberemos incluirla en el código de nuestras páginas:

Para poder trabajar con Knockout es fundamental conocer el patrón Model-View-ViewModel. Resumiéndolo (mucho) podríamos decir que se basa en organizar la aplicación en torno a 3 conceptos:

• Model. Es el modelo completo de la aplicación, donde reside la lógica de negocio y todas esas cosas importantes. Knockout no se mete en esta parte y puedes implementarla como quieras. Lo más habitual es que resida en un servidor y la aplicación se comunique con él a través de AJAX.
• View. La vista, dedicada únicamente a mostrar información. No contiene ningún tipo de lógica, ni siquiera lógica relacionada con el interfaz de usuario, porque para eso está la última parte del trío.
• ViewModel. El modelo de presentación, que se encarga de adaptar el modelo de la aplicación a las necesidades de la vista y contiene además toda la lógica relacionada con el interfaz de usuario, como por ejemplo cuándo se debe habilitar un control o qué hay que hacer cuando se pulsa un botón.

Knockout nos ofrece una manera muy sencilla de enlazar View y ViewModel a través de data binding. Este data binding se hace de forma declarativa usando atributos data-bind:

Las posibilidades que ofrece Knockout para realizar el data binding son de lo más variado y podéis consultarlas en la documentación de Knockout.

Para que funcione esto del data binding es fundamental poder detectar los cambios en los valores de los controles para propagarlos al ViewModel, pero también es necesario poder detectar los cambios en el ViewModel para propagarlos a la vista. En este aspecto Knockout cuenta con su propia implementación del patrón observer, a través de funciones como ko.observable.

¿Cuándo empezamos?

En el siguiente post veremos cómo es la aplicación de ejemplo que vamos a hacer en este tutorial y prepararemos la estructura de páginas de jQuery Mobile que vamos a tener.

Compartir enlace:

Posts relacionados:

1. Tutorial node.js + express + jquery (III): Usando jQuery
2. Tutorial node.js + express + jquery (IV): Conclusiones y próximos pasos
3. Tutorial node.js + express + jquery (I): Creando la aplicación

Javascript un lenguaje interpretado, del lado de cliente, que en sus inicios se usaba en las paginas web para crear efectos de copos de nieve y tonterías de ese tipo. Ahora es el lenguaje sin el cual Gmail no fuera posible, facebook solo seria una galería de fotos aburrida y un twitt seguiria siendo el sonido que algunos creen que hacen los pájaros. Javascript se convirtió en un lenguaje muy importante. Pero, sigue manteniendo muchas cosas que aun no se ajustan al nuevo capricho de los desarrolladores actuales:Syntactic Sugar.

Syntactic Sugar se ha hecho muy popular sobre todo (según como lo veo) gracias a Ruby, y es que eso de escribir código sin puntos y coma, corchetes, llaves y paréntesis innecesarios es una buena idea y hay muchos que piensan que esas ideas es bueno llevarlas a otros lados.

y así fue como nació CoffeeScript,un lenguaje de programación que se escribe bonito y genera Javascript de toda la vida.

Instalación

Para instalar Coffeescript, necesitamos primeramente instalar Node.js y npm, una vez ya lo hallas hecho solo ejecuta en tu terminal favorita

npm install -g coffee-script

(El parametro -g es para indicar que es una instalación global que estara disponible para todos los usuarios de tu sistema operativo)

Hola Mundo

Hagamos una prueba para identificar que todo esta instalado correctamente, y de paso explicar como compilar javascript, abre un editor de texto de tu eleccion y escribe.

square = (x) -> x * x

Guarda tu archivo como hola.coffee (Si, .coffee es la extensión de los script CoffeeScript)

y luego ejecuta

coffee -c 'hola.coffee'

Inmediatamente veras un archivo javascript que se genero con el siguiente código

square = function(x) {
return x * x;
};

y ya tienes un archivo .js de toda la vida que puedes usar sin problema en tus aplicaciones web.

Ahora bien el comando -c es el que nos sirve para compilar nuestros archivos .coffee y convertirlos en Javascript, claro que se vuelve tedioso estar corriendo ese comando por cada vez que escribo y/o modifico en mi archivo, asi que para evitarnos la fatiga de esa tarea, ejecuta

coffee --watch --compile hola.coffee

Y ahora cada vez que modifiques tu programa Coffeescript, este auto-mágicamente generara el compilado.

Un ejemplo practico

Tengo un archivo javascript de un viejo bookmarklet que hice hace un tiempo, como en ese momento no conocia CoffeeScript pues lo hice a Javascript duro y maduro. ¿Porque no lo migramos a algo mas elegante y comentamos las partes mas interesantes? Nada como un ejemplo practico para aprender mejor las cosas, o alguien aprendio a andar en bicicleta por internet??

(Que hace el bookmarklet?…elimina el teclado virtual de la siguiente pagina y permite al usuario utilizar nuevamente el teclado convencional, un banco de mi país penso que era buena idea, a mi me pareció incomodo, así que lo quite )

El código original lo puedes encontrar aquí

var ifr = false;

var formName = 'loginForm';

#Comentarios

ifr = off

formName = 'loginForm'

Variables

El script empieza definiendo unas cuantas variables,en CoffeeScript para definir variables no es necesario usar la palabra reservada var y en terminos generales los punto y coma no son requeridos.

Comentarios

Los comentarios no son compilados a javascript y se escriben anteponiendo #

Booleanos

Ademas cuando tenemos alguna variable de tipo booleana, podemos utilizar alguno de los alias que el lenguaje nos ofrece para este caso podemos sustituir el false con off o no, para true se utilizan yes o on.

var $ = function(idname) {
var doc = ifr ? window.frames.working.document : document;
return doc.getElementById(idname) ||
doc.getElementsByName(idname)[0] || '';
};

$ = (idname) ->
doc = if ifr then window.frames.working.document else document
doc.getElementById(idname) or
doc.getElementsByName(idname)[0] or ''

Funciones

Las funciones se definen siguiendo la estructura nombre = (parametros entre parentesis) -> [cuerpo de la funcion] sino existen parametros se omiten los parentesis, la palabra reservada return se omite, al igual que en Ruby, la ultima sentencia que se ejecuta es el valor que la funcion devuelve. Los parametros pueden tener valores por defecto parametro='valor'.

Sentencias condicionales

Para definir un if corto (condicion?true:false) se utiliza un lenguaje mas natural if condicion then true else false. Es de notar que las llaves y paréntesis tampoco son necesarios.

Operadores Lógicos

Los operadores logicos tambien tienen alias, para el caso de || se puede sustituir con or

for (var i=0; i<usuario.length; i++){
var caracter = usuario[i];
k = k + $(caracter).value;
}

var letras = new Array();

for (var i=32; i<170; i++){

letras[i] = String.fromCharCode(i);

}

for caracter in usuario
k = k + $(caracter).value

letras = (String.fromCharCode(i) for i in [32..169])

Sentencias repetitivas

El clasico de toda la vida for se abrevia, ya no necesitamos conocer la longitud del arreglo a iterar, ni definir alguna variable auxiliar,CoffeeScript se encarga de todo eso.

Arreglos

Para crear un arreglo basta utilizar nombre = [] aunque para el ejemplo que tenemos creamos un arreglo a partir de una sentencia for y un rango.

Rangos

En el código del bookmarklet necesitaba obtener todas las letras del alfabeto, para lograr eso lo hice con la funcion fromCharCode, que me pide un numero para devolverme el carácter que le corresponde, la opcion en Javascript es crear un loop (for) que inicie en 32 y termine en 169, en CoffeeScript podemos hacer eso haciendo uso de los rangos [inicio..final] . Los rangos son utilizados en las sentencias repetitivas y en la definición de arreglos. Es de notar que si existen dos puntos consecutivos entre los valores de inicio y final significa que el valor inicial es incluido dentro del rango, si vemos tres puntos consecutivos (…) significa que el extremo final del rango es excluido.

El resultado final

Y finalmente!! mi Javascript bookmarklet migrado a CoffeeScript

#declaracion de variables
ifr = no;
formName = 'loginForm';
#funciones
iisIframe = ->
window.location.href=='https://www.pcbac.com/PotalaPersonal/home.do';
window.iisIframe = iisIframe

#Ojo con los espacios es importante!!!
$ = (idname) ->
doc = if ifr then window.frames.working.document else document #if else
doc.getElementById(idname) or
doc.getElementsByName(idname)[0] or ''

window.$ = $;

createHTMLElement = (id,type) ->
_parent = $(id).parentNode
_parent.innerHTML = ''
_input = document.createElement 'input'
_input.setAttribute 'type', type
_input.setAttribute 'id', id
_input.setAttribute 'name', id
_input.setAttribute 'size', '32'
_input.setAttribute 'autocomplete', 'off' #los parentesis no son necesarios
_input.setAttribute 'class', 'notfocussed'
_input.setAttribute 'onblur', if ifr then 'parent.copyText(this);' else 'copyText(this);'
_parent.appendChild _input
return #coloco esto para que mi funcion no retorne nada

window.createHTMLElement = createHTMLElement

copyText = (caja) ->
usuario = caja.value
k = ''
for caracter in usuario
k = k + $(caracter).value

if caja.id=='usernameA' or caja.id=='claveActual' then $('Field1ValueHidden').value = k
if caja.id=='passwordA' or caja.id=='nuevaClave' then $('Field2ValueHidden').value = k
if caja.id=='confirmacionNuevaClave' then $('Field3ValueHidden').value = k

return

window.copyText = copyText;

ifr=iisIframe()
if ifr then formName='cambioClaveForm'
firstRowSplit = $(formName).charFirstRowhidden.value
secondRowSplit = $(formName).charSecondRowhidden.value
thirdRowSplit = $(formName).charThirdRowhidden.value
firstRowSplitMi = $(formName).charFirstRowhiddenHMi.value
secondRowSplitMi = $(formName).charSecondRowhiddenHMi.value
thirdRowSplitMi = $(formName).charThirdRowhiddenHMi.value
firstRowSplitMa = $(formName).charFirstRowhiddenHMa.value
secondRowSplitMa = $(formName).charSecondRowhiddenHMa.value
thirdRowSplitMa = $(formName).charThirdRowhiddenHMa.value

firstRow = firstRowSplit.split '|'
firstRowMi = firstRowSplitMi.split '|'
firstRowMa = firstRowSplitMa.split '|'
secondRow = secondRowSplit.split '|'
secondRowMi = secondRowSplitMi.split '|'
secondRowMa = secondRowSplitMa.split '|'
thirdRow = thirdRowSplit.split '|'
thirdRowMi = thirdRowSplitMi.split '|'
thirdRowMa = thirdRowSplitMa.split '|'
todo = []
for i in [firstRow.length - 1..0] by -1 #empezar en -1
todo[firstRow[i].toLowerCase()] = firstRowMi[i];todo[firstRow[i]] = firstRowMa[i];
for i in [secondRow.length - 1..0] by -1
todo[secondRow[i].toLowerCase()] = secondRowMi[i];todo[secondRow[i]] = secondRowMa[i];
for i in [thirdRow.length - 1..0] by -1
todo[thirdRow[i].toLowerCase()] = thirdRowMi[i];todo[thirdRow[i]] = thirdRowMa[i];

for m in [0..2]
todo[$(formName).number1[m].value] = $(formName).number1[m].alt;
todo[$(formName).number2[m].value] = $(formName).number2[m].alt;
todo[$(formName).number3[m].value] = $(formName).number3[m].alt;

todo[$(formName).number4.value] = $(formName).number4.alt;

for m in [0..9]
todo[$(formName).button4[m].value] = $(formName).button4[m].alt;

for m in [0..10]
todo[$(formName).button5[m].value] = $(formName).button5[m].alt;
todo[$(formName).button10[m].value] = $(formName).button10[m].alt;

letras = (String.fromCharCode(i) for i in [32..169])

for letra in letras
input = document.createElement 'input'
input.setAttribute 'type', 'hidden'
input.setAttribute 'id', letra
input.setAttribute 'value', todo[letra]
$(formName).appendChild input

if !ifr
createHTMLElement('usernameA','text')
createHTMLElement('passwordA','password')
else
createHTMLElement('claveActual','password')
createHTMLElement('nuevaClave','password')
createHTMLElement('confirmacionNuevaClave','password')

$(if ifr then formName else 'forma1').getElementsByTagName("table")[0].getElementsByTagName("tr")

[if ifr then 14 else 8].style.display = 'none'

CoffeeScript es mucho mas

Lo que utilice de CoffeeScript para migrar mi bookmarklet no es ni la décima parte de todo lo que este lenguaje nos ofrece, hay mas temas que tratar pero, no caben en un articulo introductorio, espero haber logrado inculcar un poco de curiosidad para que sigas adelante en el estudio de CoffeeScript. Si ese es tu caso, dejo a tu disposición documentación para dar el siguiente paso

Un curso de CoffeeScript en EscueladeCodigo, completamente gratis, ¿te parece buena idea?

ArchLinux

Lo que dice el título, ¿y si juntamos un grupo de usuarios ArchLinux en un mismo espacio física esporádicamente y nos unimos a trabajar con algun(os) objetivo(s) en común?

En un principio pensé que la mejor forma de convocar a los usuarios a unirse en grupo era crear una lista de correo, un blog, o algo así. Pero eso son solo herramientas, preferí empezar sin mucha ambición con este post (gracias al principio de KISS). Los invito a dejar un comentario si quieren sumarse a la iniciativa. Hay que ver si hay más interesados, y después entre los que seamos vemos qué se arma

Se me ocurren varias razones de por qué esto es una buena idea. Una buena parte de lo positivo de ir a una reunión de personas técnicas (hackatón, conferencias y demás) es conocer a otras personas con los mismo intereses. Ni que hablar que las charlas suelen ser bastante interesantes. Si nos entretenemos leyéndonos por foros, redes sociales y blogs, mejor la vamos a pasar conversando mientras tomamos alguna cerveza y comemos alguna pizza.

A continuación listo algunos objetivos/ideas/razones más que me vienen en la cabeza sin caer en nada muy ambicioso.

• Aprender a empaquetar aplicaciones y buscar alguna aplicación que podríamos enviar a AUR. Es un conocimiento que viene bien, y seguramente todos han toqueteado algún PKGBUILD en algún momento. De repente sale algo interesante.
• Ayudar con la traducción de la wiki, si alguien tiene algo de tiempo libre para aportar al proyecto, esta es una buena manera. (más ideas acá)
• Dar a conocer cosas interesantes que hayamos logrado, scripts, personalizaciones, etc. Ayudar con algún problema particular que algun usuario pueda tener con el sistema.
• “Evangelizar” a usuarios de otras distros, ayudarles a darse cuenta que ArchLinux es la mejor distribución de GNU/Linux
• Comprar camisetas de ArchLinux. Al ser muchos, podemos conseguir un buen precio para mandar a hacer camisetas de Arch.
• DRY: No repetirnos. No hay que reinventar la rueda, crear más wikis y demás información repetida. Creo que si en algún momento armamos alguna representación virtual del grupo en internet, habría que limitarse al tema de las reuniones y demás posibles organizaciones que podamos llevar a cabo. Nada de reescribir o copiar y pegar todo el conocimiento que tan bien documentado está en la wiki de Arch.

Si hay convocatoria, coordinamos una fecha y me comprometo a conseguir un lugar para reunirnos por primera vez y ver qué sale. No hay mucha idea o compromiso, simplemente juntarse a ver qué sale.

Para finalizar el post, los dejo con un texto de la wiki:

En Biología, mutualismo es una interacción entre dos organismos en que ambos organismos obtienen beneficio. Este principio puede también ser aplicado a miembros proactivos y motivados de la comunidad de ARCH que quieren estar involucrados y contribuir a su distribución favorita GNU/Linux. Esta participación beneficia no solo a los miembros de la comunidad y sus compañeros Arches, pero también a todos los fans potenciales de Software libre y de codigo abierto

En el mundo del diseño web últimamente está muy de moda el Responsive Web Design, que podríamos traducir como diseño sensible o más bien como “diseño que responde bien”. Se trata de intentar diseñar las páginas web para que se adapten correctamente a distintas resoluciones y formatos de pantalla, y es algo que hoy en día cobra una importancia especial con la gran variedad de dispositivos que se usan para navegar por internet.

Para conseguir esto, siempre existe la opción de desarrollar distintas versiones del sitio web adaptadas a cada formato que queramos soportar, pero eso implica un trabajo adicional que no siempre merece la pena y además supone un problema cuando aparecen nuevos formatos que no teníamos previsto.

El responsive design aprovecha las características de CSS3 y media queries para aplicar distintos formatos en función de las características del dispositivo que está accediendo a la página.

Una forma muy extendida de implementar esto es estructurar la página a partir de un grid y maquetar la información ajustándola a ese grid:

Estructura de una página basada en un grid de 7 columnas

Una vez que tenemos la información estructurada, aplicando las técnicas CSS adecuadas es relativamente fácil conseguir adaptarlo al tamaño de pantalla del dispositivo:

Ejemplo de web adaptada a distintas resoluciones

En este ejemplo se ve como al reducir el ancho de la pantalla, el contenido se reformatea reduciendo el tamaño de las columnas del grid, llegando incluso a apilar las columnas para pasar a un formato completamente vertical apto para teléfonos móviles. Se puede comprobar fácilmente accediendo a la página y redimensionando la ventana del navegador.

Para ayudarnos a implementar esto, existen muchos frameworks CSS para responsive design que nos facilitan bastante la vida. Algunos están basados en grids fluidos, en los cuales la anchura de las columnas se ajusta automáticamente al tamaño de la pantalla, y otros en grids fijos, que mantienen constante la anchura de las columnas pero varían el número de columnas en función del tamaño de la pantalla. Entre los frameworks más conocidos están:

• Less framework
• 1140 CSS Grid
• Foundation
• Skeleton
• Semantic Grid System

Personalmente me parece una idea bastante buena, pero hay puntos que no acaban de gustarme. Me parece que se sacrifica parte del contenido semántico del documento en favor de la maquetación, algo que ya ocurría hace unos cuantos años con el abuso de las tablas. Ahora parece que, mientras se usen divs en lugar de tablas, todo vale.

Por otra parte, casi todos estos sistemas utilizan clases CSS que no tiene valor semántico, sólo tienen valor para formatear la información. En un mundo ideal, las clases CSS que aparecen en el documento HTML no deberían definir el cómo (formato) sino el qué (intención), deberían ser algo declarativo.

Por ejemplo, si en una página queremos marcar el importe total de una compra, deberíamos marcarlo como y luego asignar en la hoja de estilo a la clase total-amount una fuente negrita, más grande o lo que queramos. Con este tipo de frameworks se fomenta más usar algo de la forma , penalizando la estructura semántica del documento. Es lo mismo que ocurre al utilizar otros frameworks de diseño web como jquery-ui o jquery-mobile.

Una excepción a esto es Semantic Grid System, que intenta no manchar el documento html con sus clases CSS. Para ello, aplica sus estilos mediante mixins con LESS, SCSS o Stylus.

En cualquier caso, las ventajas que aportan el uso de este tipo de frameworks son considerables, por lo que a veces resulta mejor ser más pragmático y aprovecharlos. A fin de cuentas, lo que realmente importa es aportar valor al usuario/negocio, y para ello estos frameworks pueden ser de mucha ayuda.

Compartir enlace:

No hay posts relacionados.

Via Pablo Jimeno

Para evitar tener que reproducir otra vez cada uno de los pasos para llegar al error usaremos este plugin que añade una nueva opción al menú Ver del IDE que permite mostrar la información de error completa o resumida así como borrar el archivo del disco cuando ya no es necesario.

Desde la vista error.log es posible copiar la información del error al portapapeles en el mismo formato en que se está mostrando, completa o resumida, para, por ejemplo, enviarla por correo:

El archivo para descargar: ErrorLog

El plugin sólo funciona con Xailer 2.5 y Xailer 2.5.1

Oil Rush

El excelente juego de estrategia naval en tiempo real Oil Rush (clic en el enlace para leer mi reseña) está disponible en su versión 1.00. Aquellos que lo preordenamos lo podemos descargar ya desde Unigine Online Store.

Se está trabajando en versiones para Steam, Desura y Ubuntu Software. Éstas estarán disponibles en uno o dos días.

La versión 1.00 nos trae el tan esperado modo de campaña para un jugador. Pre ordené el juego en marzo del año pasado, y desde entonces he ido viendo cómo evoluciona poco a poco con cada nueva versión. Ahora me toca el turno de hacer la campaña y ver qué han estado preparando los desarrolladores para nosotros…

Es un juego bastante importante en lo que respecta al mundillo de videojuegos en plataformas GNU/Linux. Fue construido sobre el motor Unigine que da la oportunidad de realizar unos gráficos 3D impresionantes, corriendo de forma nativa en nuestro querido sistema.

Con suerte el juego tenga éxito, así lo espero. Esto abriría más el mercado de videojuegos en GNU/Linux, dándole la publicidad necesaria a su motor para que otras compañías lo tengan en cuenta a la hora de desarrollar sus juegos.

Ya estoy descargando esta nueva versión, y más tarde tendré la oportunidad de probarlo. Ahí les contaré qué me pareció. Mientras les dejo algunas fotos de versiones anteriores para que se hagan una idea de los excelentes gráficos del juego:

Oil Rush 0.66

[View with PicLens]

Oil Rush 0.82

[View with PicLens]

• “Putting Dependency Injection on the map” contiene tres capítulos introductorios, útiles para poner en contexto el patrón y las ventajas que conlleva su uso y describir los conceptos fundamentales utilizados: dependencias, tipos, tiempo de vida, intercepción, contenedores, y muchos otros.
• “DI catalog” es una completa relación de patrones de uso de la inyección de dependencias, antipatrones o malos usos que podemos hacer de la misma, y refactorizaciones que podemos utilizar para solucionar escenarios frecuentes.
• “DIY DI” describe técnicas asociadas a la ID, como la composición de objetos, la gestión del ciclo de vida, y la intercepción de llamadas.
• “DI containers” es un completo bloque donde se describe el uso de los principales contenedores disponibles para la plataforma .NET: Castle Windsor, StructureMap, Spring.NET, Autofac, Unity y MEF.

Gracias a los plugins de grails liberados a la comunidad, podemos aprovechar el esfuerzo hecho por otros desarrolladores y reutilizar el trabajo que han hecho. El sistema de plugins de grails da múltiples puntos de extensión para la plataforma: permite añadir comandos nuevos a la CLI, servicios, clases de dominio, extender dinámicamente algunos comportamientos… En el taller sacaremos partido del sistema de plugins de grails para reutilizar trabajo entre distintas de nuestras aplicaciones, veremos algunos ejemplos y desarrollaremos un plugin a modo de ejemplo.

Básicamente, mostraremos de forma práctica como reutilizar código en nuestros proyectos del día a día, más allá de liberar plugins que sólo tengan sentido ser liberados para el resto de la comunidad.

Este año volverán a ser 2 días de charlas y talleres, un eventazo a un precio de risa. Como podéis ver en la agenda, hay buena cantidad y calidad de ponentes, incluida alguna rockstar internacional entre ellos.

Cualquiera que trabaje o le interesen tecnologías alrededor de los ecosistemas Spring, Grails o Groovy debería asistir a este evento; o también a quienes les interesan cosas relacionadas con Mongodb, Scala, ElasticSearch, RabbitMQ o incluso temas de cloud computing.

Pero seguro que lo mejor está por los pasillos, durante los cafés y las comidas… o, por descontado, en la fiestaca del jueves .

Nos vemos en el Spring I/O!

• mediante conexiones persistentes, la opción de menor nivel, que proporciona mecanismos de notificación de conexión y desconexión de clientes, así como para recibir y enviar mensajes asíncronos a clientes conectados, tanto de forma individual como colectiva.
• mediante el uso de “hubs”, que ofrece una interfaz de desarrollo mucho más sencilla, con una integración entre cliente y servidor que parece pura magia, y que seguro será la opción más utilizada por su potencia y facilidad de uso.

1. En el lado servidor, implementaremos un servicio (endpoint) SignalR, que es el que procesará las conexiones y desconexiones de clientes, y enviará información actualizada por las conexiones abiertas.
2. Registraremos este endpoint durante la inicialización de la aplicación, asociándole una URL de acceso a las funcionalidades del servicio.
3. En el lado cliente implementaremos la conexión con el servicio, capturaremos la información que nos vaya enviando y la mostraremos en la página en forma de log.

1. Implementación del endpoint

    public class VisitorsService : PersistentConnection
    {
        protected override void  OnConnected(HttpContextBase context, string clientId) { ... }
        protected override void  OnDisconnect(string clientId) { ... }
        protected override void  OnReceived(string clientId, string data) { ... }
        // [...]
    }

• tomar el control en el momento en que se produce una nueva conexión (método OnConnected), momento en que enviaremos al resto de clientes un mensaje con información sobre el cliente conectado y el total de conexiones activas.
• tomar el control en el momento en que se produce la desconexión de un cliente (método OnDisconnect()), para notificar al resto y actualizarles el número de clientes conectados.

1.1. Notificando a los clientes las nuevas conexiones

    protected override void OnConnected(HttpContextBase context, string clientId)
    {
        var clientDescription = getClientDescription(context);
        _clients.TryAdd(clientId, clientDescription);
 
        string text = clientDescription + " arrived.";
        var msg = new NotificationMessage(text, _clients.Count);
        Connection.Broadcast(msg);
    }

public class NotificationMessage
{
    public NotificationMessage(string message, int onlineUsers)
    {
        OnlineUsers = onlineUsers;
        Message = message;
    }
 
    public string Date
    {
        get { return System.DateTime.Now.ToLongTimeString(); }
    }
    public string Message { get; set; }
    public int OnlineUsers { get; set; }
}

    private static ConcurrentDictionary<string, string> _clients =
        new ConcurrentDictionary<string, string>();
 
    private static string getClientDescription(HttpContextBase context)
    {
        var browser = context.Request.Browser.Browser + " " +
                        context.Request.Browser.Version;
        var name = context.Request.IsAuthenticated ?
                    "User " + context.User.Identity.Name :
                    "IP " + context.Request.UserHostAddress;
        return name + " (" + browser + ")";
    }

1.2. Notificando a los clientes las desconexiones

    protected override void OnDisconnect(string clientId)
    {
        string text, clientDescription;
 
        if (_clients.TryRemove(clientId, out clientDescription))
            text = clientDescription + " is leaving.";
        else
            text = "Unknown user leaving.";
 
        var msg = new NotificationMessage(text, _clients.Count);
        Connection.Broadcast(msg);
    }

1.3. Algunas observaciones adicionales

• desde el cliente, una vez se ha realizado la conexión, realizar un envío de datos al servidor, algo similar a un “ping”,
• en el método OnReceived() del servidor, capturar el mensaje enviado desde el cliente y responderle de forma directa con la información que nos interese hacerle llegar, que podría ser un mensaje de bienvenida y, como en otras ocasiones, el número de usuarios conectados: 

      protected override void OnReceived(string clientId, string data)
      {
          var msg = new NotificationMessage("Hi!", _clients.Count);
          Send(clientId, msg);
      }

2. Registro de ruta

    public static void RegisterSignalrConnections(RouteCollection routes)
    {
        routes.MapConnection<VisitorsService>("Visitors", "VisitorsService/{*operation}");
    }
 
    protected void Application_Start()
    {
        RegisterSignalrConnections(RouteTable.Routes);
        [...]
    }

3. Implementación del cliente web

<script src="@Url.Content("~/Scripts/jquery.signalR.js")" type="text/javascript"></script>

Nota: si queremos dar soporte a clientes antiguos que no soportan deserialización JSON de forma nativa (por ejemplo, IE7), será necesario descargar desde Nuget la biblioteca de scripts json2.js y referenciarla en la página antes de la carga de SignalR.js. En caso contrario, se lanzará una excepción con el error:



“SignalR: No JSON parser found. Please ensure json2.js is referenced before the SignalR.js file if you need to support clients without native JSON parsing support, e.g. IE<8” 

<h2>Log</h2>
<div id="log"></div>

• iniciar la conexión con el endpoint,
• tras ello, enviar un “ping” para recibir el mensaje de bienvenida (recordad lo que os comentaba previamente de que el broadcast no se recibe por el cliente que inicia la conexión),
• mostrar en el log la información recibida del servidor.

<script type="text/javascript">
    $(function () {
        var conn = $.connection("VisitorsService");
        conn.received(function (data) {
            var text = data.Date + " - " + data.Message + " " +
                data.OnlineUsers + " users online.";
            
            $('#log').prepend("<div>" + text + "</div>");
        });
 
        conn.start(function () {
            conn.send("ping");
        });
    });
</script>

• en la variable conn obtenemos una referencia hacia el endpoint, identificado por el nombre de la conexión persistente, en este caso, VisitorsService.
• sobre ella, definimos la función received(), que será invocada cuando el servidor envíe información. El parámetro que recibe la función anónima es la información enviada desde el servidor, que, recordaréis, en este caso se trataba en objetos de tipo NotificationMessage. Dado que la serialización y deserialización se realizan de forma automática, podemos acceder directamente a sus miembros, como podéis ver en el código para montar el mensaje e introducirlo en el log.
• por último, iniciamos la conexión invocando al método start() de la conexión. Observad que este método admite un callback que será llamado cuando la conexión se haya establecido, momento que aprovechamos para enviar el “ping” al servidor que nos permitirá recibir el mensaje de bienvenida.

Recientemente he padecido un caso claro de esto usando la API de consultas QueryOver de NHibernate. QueryOver está diseñado como una implementación del patrón Query Object aprovechando expresiones lambda para hacer static reflection y conseguir así que el API sea type-safe y refactor friendly.

QueryOver intenta abstraer el acceso a la base datos, pero a la vez trata de mantener toda la potencia del SQL, por lo que en cuanto las consultas se complicando un poco acaba siendo un lío y la ganancia que tenemos por ser type-safe y refactor friendly no compensa la pérdida de legibilidad.

Veamos un ejemplo concreto bastante simpe. Supongamos que tenemos el típico modelo de clientes y pedidos y queremos lanzar una consulta para obtener el número de pedidos y el importe total pedido por cada cliente. La implementación con QueryOver es algo así:

Customer customer = null;
var stats = s.QueryOver()
    .JoinAlias(x => x.Customer, () => customer)
    .SelectList(lst => lst
                            .SelectGroup(() => customer.Id)
                            .SelectGroup(() => customer.Name)
                            .SelectSum(x => x.Total)
                            .SelectCount(x => x.Id))
    .List();

El resultado es bastante feo. Para poder hacer el equivalente al inner join de forma type-safe, tenemos que declarar una variable de tipo Customer que usamos únicamente como alias para usarla luego en las expresiones lambda. Además, para construir la lista de columnas a devolver se usa un builder (lst) que simplifica un poco las cosas pero no acaba de resultar claro.

Si la misma consulta la lanzamos con el equivalente HQL, el lenguaje de consultas de NHibernate, tenemos:

var stats = s.CreateQuery(@"select c.Id, c.Name, sum(o.Total), count(o.Id)
                            from Order o right join o.Customer c
                            group by c.Id, c.Name")
             .List();

Para cualquiera que esté acostumbrado a manejar SQL, está claro que la consulta resulta mucho más legible. Es cierto que no es type-safe no refactor friendly, pero en mi opinión la legibilidad lo compensa.

Parece que nuestra tendencia natural como desarrolladores es siempre abstraerlo todo, pero a veces hay que tener cuidado porque puede que estemos causando más problemas de los que solucionamos.

Compartir enlace:

No hay posts relacionados.

¿Que es GitHub?

¿Necesitas alojar tu proyecto en algun repositorio Git que no sea en tu computadora? ¿No quieres perder tu tiempo configurando un servidor remoto como repositorio de Git? Entonces GitHub es para ti, un sitio web donde todos tus proyectos que utilicen Git estaran bien resguardados.

Seria muy injusto decir que GitHub solo es un simple sitio web para guardar repositorios Git. Porque la verdad es que es mucho mas que eso,es una “red social” donde los desarrolladores compartimos nuestro codigo fuente con otros. Todos los repositorios en GitHub son open source (todos los que no son de pago) asi que podemos descargarlos, clonarlos,enviar parches, corregir el codigo de otro, que otros nos envien sus cambios, etc, etc.

De esa forma no solo compartimos nuestro código, sino que lo exponemos a una audiencia de profesionales (como nosotros) para que lo puedan evaluar, corregir y mejorar

Para empezar, registrate en GitHub

Ingresa a https://github.com/plans , elige el plan gratuito, llena el formulario (bastante simple no tendras problemas) y ya estas registrado!

Mi primer repositorio

Vamos a estrenarnos dentro de GitHub, para eso ya debemos tener correctamente configurado Git, ¿No lo has hecho?? Tomate unos minutos para leer este articulo antes de continuar

Crea un nuevo repositorio

GitHub es tan bueno con nosotros, que inmediatamente despues de crear el repositorio nos indica como debemos proceder, asi que hagamos lo que dice

Sube el código

Antes que nada, crea en tu computadora la carpeta donde tendras el código fuente, abre una terminal y escribe

 mkdir Hola-Gato

y muevete dentro de la carpeta recien creada

 cd Hola-Gato

inicializa el repositorio Git

 git init

Los repositorios en GitHub tienen un archivo muy importante, el README, dentro de este archivo se colocan instrucciones que quieres que los desarrolladores lean desde que entran a ver tu repositorio, asi que no olvidemos crearlo. Utiliza Markdown para escribir en el.

touch README

Ahora que ya tienes un archivo en tu repositorio, lo agregamos

git add README

y ejecutamos nuestro primer commit

git commit -m “Primer commit en el proyecto”

Hasta este momento todo lo que hemos hecho, seria como cualquier proyecto en el que usemos Git, todo local, para relacionar nuestro código fuente con el repositorio remoto que recien hemos creado en GitHub debemos ejecutar lo siguiente

git remote add origin git@github.com:escueladecodigo/Hola-Gato.git

y finalmente subimos el codigo a GitHub

git push -u origin master

Ahora cuando demos en el enlace Continue veremos algo como lo siguiente

Ahora ya tienes tu primer repositorio en GitHub, listo para que cualquiera lo vea, lo clone, haga forks, te envié mejoras, etc, etc. Solo llénalo un poco con tu código, no creo que un repositorio con un solo archivo README sea muy llamativo para otros desarrolladores

GitHub cuenta con tantas funcionalidades; resaltado de sintaxis, seguir desarrolladores, clonar repositorios, etc, etc. Por el momento dejare que tu curiosidad trabaje un poco y explores todo lo que Git junto con GitHub puede ofrecerte. En artículos posteriores iremos desglosando cada una de esas opciones, conociéndolas bien y sacandoles el máximo provecho posible. Así que no te pierdas los próximos artículos, te ayudaran no solo a conocer Git sino a usarlo como un ninja!

Disculpa, pero esta entrada está disponible sólo en English.

Disculpa, pero esta entrada está disponible sólo en English.