Ruby Meetups

El martes pasado tuvimos el Meetup de Ruby de Abril. Todos los meses nos juntamos -el segundo martes de cada mes- a conocernos, hablar de programación, Ruby, herramientas y demás.

Esta reunión fue bastante interesante. Hubo gente nueva que se sumó, y un comentario general que oí varias veces es que la comunidad local formada entorno a Ruby está buena y dan ganas de formar parte. Por ese lado creo que estamos haciendo un buen trabajo al destacar una de las características más importantes del lenguaje de programación Ruby: La comunidad.

No hubieron charlas preparadas como otras veces, así que improvisamos, lo que resultó en un intercambio excelente. En principio comentamos un poco sobre Heroku, qué es, para qué sirve, etc. Los temas de conversación se iban llevando segun preguntas o comentarios de los asistentes.

No tuvimos “oradores” definidos, mas bien “mostramos cosas”. Yo mostré ghpreview, una gema para tener un preview de archivos Markdown usando el formato exacto de GitHub. La idea fue alentar a la gente a colaborar con proyectos Open Source, mostrando lo fácil que fue modificar la gema ni bien salió para que funcionara en GNU/Linux. Hace un tiempo escribí un poco más al respecto (en inglés) en el blog de Neo.

Entre medio hablamos un poco el funcionamiento de GitHub, hicimos una demostración de cómo funcionan los Pull Requests (facilitando enormemente la colaboración entre desarrolladores), y alguna cosa más.

En eso llegó la pizza y comimos un poco, siempre acompañados de bebidas varias, e intercambiamos opiniones, conocimos gente nueva, y todo lo bueno de socializar en un evento de este tipo. Programadores: recuerden que es importante asistir a eventos técnicos de este tipo.

Ya con el estómago lleno, Martín Loy conectó su laptop al proyector y se animó a hacer una sesión de live coding espontánea. Su objetivo fue mostrar lo fácil que es entrarle a cosas nuevas en Ruby. Había escuchado hablar mucho de Sinatra, pero nunca lo había usado. Así que siguió el tutorial del sitio de Sinatra y mostró la fácil que es armar una aplicación web con Sinatra.

Otro tema que se discutió fue sobre los gemsets y RVM contra RBenv. Respecto a eso, justo hoy vi este artículo de Thoughtbot:
Using rbenv to manage rubies and gems
Puede ayudar en el debate

A modo de conclusión, personalmente estoy muy contento de cómo se vienen llevando estas reuniones. Está bueno saber que al menos una vez por mes nos juntamos con gente de otras empresas / ámbitos a compartir un rato de Ruby. Para el mes que viene aparentemente vamos a tener algunas charlas preparadas sobre bloques, lambdas y Procs en Ruby y alguna cosa más.

Recuerden que no es necesario saber Ruby para asistir. La idea es difundir un poco lo bueno de Ruby y cómo lo usamos, así que si usan otras tecnologías a diario, es una buena oportunidad para conocer un poco qué se hace con Ruby. Estén atentos al sitio de Ruby Meetups e inscríbanse si les interesa estar al tanto de las novedades.

Ruby Meetup – foto por @neo_uy

[Authorize]
public class AlertService : Hub
{
    public void Alert(string msg)
    {
        this.Clients.All.showAlert(msg);
    }
}

public class AlertService: Hub
{
    [Authorize]
    public void Alert(string msg)
    {
        this.Clients.All.showAlert(msg);
    }

    // Other hub methods
}

[Authorize(Users="fmercury,mjackson,fsinatra")]
public void Sing(string msg)
{
    // ...
}

[Authorize(Roles= "greatsingers")]
public void Sing(string msg)
{
    // ...
}

Video presentación de Desarrollando América Latina 2012, les recomiendo verlo para que se hagan una idea de qué se trata la hackatón, y les inspire participar en la edición 2013

Se muestran organizadores, segmentos de la hackatón y ganadores de todos los países participantes de la pasada edición:

Más info del evento en:

• Desarrollando América Latina
• @DesarrollaLatAm en Twitter

• Eventazo en Murcia: #TunodeYoxaml #YonodeTuxaml
  Gusenet

.Net

• Beware of Async Sub or Void
  Jim Wooley
• Understanding .NET Garbage Collection
  Just* team
• Owin, Katana and getting started
  Glav

Asp.net

• ElmahR – monitor errors in your app using a dashboard
  Gregor Suttie
• Making your existing ASP.NET MVC Web Site Mobile Friendly
  Suprotim Argwal
• Debugging ASP.NET Web API with Route Debugger
  Rick Anderson
• WebAPI Tip #7: Beautiful Message Handlers
  K. Scott Allen
• Hosting ASP.NET Web API in LinqPad
  Filip W.
• Using jQuery to POST [FromBody] parameters to Web API
  Dave Ward
• ASP.NET 4.5 Web Forms Features - Model Binding
  Dan Wahlin
• ASP.NET MVC- Creating Custom View Engine
  Mahesh Sabnis
• Tutorial Series on Model Binding with ASP.NET Web Forms
  Tom FitzMacken
• ASP.NET Web API Logging and Troubleshooting
  Pablo M. Cibraro (aka Cibrax)
• Monitor your ASP.NET Web API application using your own custom counters
  Aliostad

Data access

• A Notable Entity Framework Performance Eater: Casting nchar to nvarchar under the covers
  Julie Lerman

Html/Css/Javascript

• Body Border, Rounded Inside
  Chris Coyier
• CSS Masking
  Dirk Schulze
• jQuery- The Performance of DOM caching
  Sam Deering
• Introduction to Fabric.js
  Juriy Zaytsev
• Building Large, Maintainable, and Testable Knockout.js Applications
  Jonathan Creamer
• Angry Birds of JavaScript: Black Bird - Backbone
  Elijah Manor
• Mapping an Angular Resource Service to a Web API
  K. Scott Allen
• Getting started with AngularJS
  Kris Schultz

Visual Studio/Complementos/Herramientas

• Visual Studio 2012 Update 2 Now Available
  S. Somasegar

Windows 8/WinRT/WP

• Windows Phone. Técnicas para compartir código. 2º Parte
  Javier Suárez Ruiz

Otros

• The Collective Legal Guide For Designers (Contract Samples)
  Veronica Picciafuoco
• ¿Qué es un Microsoft MVP?
  Marc Rubiño

En los últimos años estamos viviendo un auge muy fuerte de Javascript, pasando de ser un lenguaje para hacer pequeñas manipulaciones en páginas web a ser una alternativa real para desarrollar aplicaciones de muy diversa índole.

Con el avance de smartphones y tablets, la necesidad de tener aplicaciones multiplataforma se hace cada vez mayor, y aprovechar para ello HTML5/JS/CSS3 es una alternativa habitual, lo que lleva a que al final casi todos acabemos expuestos de una forma a otra a Javascript.

Para algunos Javascript es un lenguaje feo, mal diseñado y lleno de comportamientos inconsistentes o, al menos, poco previsibles. Para otros es un lenguaje cómodo, flexible, con un buen equilibrio entre complejidad y potencia.

Sin entrar a valorar esos aspectos que pueden ser bastante subjetivos, creo que es una lástima que a veces nos olvidemos de todo lo que nos ha dado Javascript.

¿Qué ha hecho Javascript por nosotros?

Aunque nos empeñemos en ver sólo el código fuente y juzgarlo en base a eso, ni siquiera los mayores detractores de Javascript pueden negar su aportación al estado actual de la tecnología.

Javascript ha sido el gran habilitador de la nueva web. Una web en la que no sólo se consumen contenidos, sino que también se crean. Una web que es algo más que un repositorio de información, una web en la que existen auténticas aplicaciones que mejoran nuestra productividad.

Todas las plataformas cuentan con navegadores lo bastante avanzados como para ejecutar código Javascript moderno a una velocidad aceptable. En este sentido podríamos decir que ha tomado el relevo de Java y su JVM que nunca llegó a cuajar para aplicaciones de escritorio, aunque ahora esas antiguas aplicaciones de escritorio se hayan reencarnado como aplicaciones web.

Además se ha convertido en la lengua franca de internet. Tener disponible en cada sistema operativo una plataforma capaz de renderizar HTML y ejecutar código Javascript, ha hecho que aparezcan lenguajes de distintas características que pueden ser compilados a Javascript, permitiéndonos aprovechar automáticamente la ubicuidad del entorno de ejecución.

En lugar de tener que aprender un lenguaje de programación y unas librerías UI para cada plataforma, Javascript permite manejar los mismos conceptos en todas las plataformas; obviamente no ofrece todas las posibilidades que las alternativas nativas, pero no deja de ser una opción viable para muchos tipos de aplicaciones.

Lo mejor que ha hecho Javascript

Todos los motivos anteriores están muy bien, pero creo que ha hecho algo aún más importante en el mundo del desarrollo de software.

Somos muchos los que vivimos gran parte del tiempo en lenguajes como C# o Java, con su orientación a objetos, su tipado estático, sus completas librerías y sus potentes entornos de desarrollo, y tener que tratar con Javascript nos ha obligado a replantearnos ciertas cosas.

Tratar con un sistema de tipos dinámicos. No tener una única forma de hacer las cosas. Sustituir frameworks que tratan de cubrir todas tus necesidades por librerías ligeras y específicas. Tener que elegir tus propias herramientas en lugar de usar el entorno de desarrollo que decide un fabricante.

Son cosas que hace unos años la mayoría de programadores en .NET ni siquiera se planteaban, pero que poco a poco van calando en la comunidad de desarrollo y permite establecer un sano debate sobre la mejor forma de hacer cada cosa.

En realidad, estas características no son exclusivas de la filosofía de desarrollo de Javascript, muchas de ellas son compartidas por otros lenguajes como Ruby o Python. De hecho hay ideas que se ven hoy en día como algo natural en .NET que se popularizaron en esos entornos, como por ejemplo el uso de convenciones en lugar de configuración.

La diferencia es que el desarrollador habitual de .NET no necesitaba estar en contacto con esas plataformas, podía esperar a que alguien adaptase esas ideas a .NET (Castle MonoRail, Nancy) y limitarse a usarlas “desde este lado” sin llegar a comprender todo lo que había detrás de ellas.

Javascript es algo que te encuentras día a día y no queda más remedio que remangarse y tratar con él directamente. Aunque existan cosas como TypeScript, de momento su ecosistema es muy limitado y no puedes esconderte de Javascript.

Lo mejor de Javascript es que nos ha obligado a conocer otra forma de hacer las cosas.

No pretendo decir con todo esto que Javascript sea una maravilla, ni que los lenguajes dinámicos sean mejores que los estáticos, ni que haya que usar herramientas de línea de comandos y editores de texto en lugar de IDEs.

Lo importante es conocer alternativas que nos permitan evaluar mejor nuestras herramientas habituales y nos ayuden a tomar mejores decisiones. Da igual si al final vuelves al Visual Studio y C# convencido de que son las mejores herramientas del mundo, lo que importa es que ahora sabes que no son las únicas herramientas del mundo.

Posts relacionados:

1. Echo de menos la BCL: formato y parsing de fechas en Javascript
2. Mixins en Javascript

Compartir una carpeta con IIS para que esté accesible a través de una página web es algo sencillo y útil en determinadas ocasiones: basta con crear una carpeta virtual y habilitar el listado de directorios.

Lo malo es que IIS no nos ofrece muchas opciones para personalizar el formato del listado. Después de buscar un rato en Google no encontré ninguna alternativa que me convenciese, así que en 5 minutos me monté una solución casera.

El código importa, pero el contexto más

Para hacer esto no voy a usar node, ni compojure, ni rails, ni, dios me libre, PHP. Todos los IIS que tengo cerca tienen instalado .NET así que lo más lógico es usarlo y no tener que instalar nada más.

Además, no todos tienen la última versión, por lo que usar Razor queda descartado y eso nos lleva a WebForms (!).

Si le unimos que no quiero tener que abrir el Visual Studio para compilar nada y no me quiero complicar la vida desplegando más ficheros de lo necesario, llegamos a un código feo donde se mezcla todo.

De todas formas, por si ha alguien le sirve, aquí lo dejo.

El resultado

Para usarlo, sólo hace falta guardar el siguiente código como Default.aspx en la carpeta que queramos exponer vía web, convertir la carpeta virtual en una aplicación y permitir la ejecución de comandos.

OJO: esto es código de andar por casa, no hay control de errores, no está muy probado, … si lo quieres usar, allá tú.

<%@ Page Language="C#" AutoEventWireup="true"%>
<%@ Import Namespace="System.IO" %>



<%
    string workingFolder = Server.MapPath("~");
    string folder = string.IsNullOrEmpty(Request.Params["folder"]) 
                    ? workingFolder 
                    : Request.Params["folder"];

    if (!folder.StartsWith(workingFolder))
        throw new UnauthorizedAccessException(
            string.Format("Cannot access folder outside {0}", workingFolder));

    DirectoryInfo directory = new DirectoryInfo(folder);
%>
    
    
    
    * {
        font-family: Segoe UI, Tahoma, Verdana;
        font-size: 18px;
        color: #333;
    }
    body {
        margin: 25px auto;
        max-width: 960px;
    }
    h1 {
        font-size: 24px;
        padding-bottom: 12px;
        border-bottom: solid 1px #cecece;
    }
    ul {
        list-style: none;
        padding: 0px;
    }
    a {
        color: #000;
        text-decoration: none;
        border-bottom: 1px dotted #aaa;
    }
    a:visited {
        color: #aaa;
    }
    a:hover {
        border-bottom: 1px solid #000;
    }
    


    
<%=directory.FullName%>
    

    <%
       foreach (DirectoryInfo d in directory.GetDirectories())
       {
           %>
[ <%=GetFolderLink(d.FullName) %>"><%=d.Name%> ]
<%
       }

       foreach (FileInfo f in directory.GetFiles())
       {
           if (f.Name == Path.GetFileName(Request.Path))
               continue;
			   
           %>
<%=GetFileLink(f.FullName)%>"><%=f.Name%>
<%
       }
    %>
    

Posts relacionados:

1. IHandlerSelector'>Usando convenciones para mejorar IHandlerSelector

1. La situación actual

bundles.Add(new ScriptBundle(
        "~http://www.planetacodigo.com/bundles/jquery", // Bundle virtual path
        "http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.9.1.min.js" // CDN Path
    )
    .Include("~/Scripts/jquery-{version}.js"));

      ...
      @Scripts.Render("~http://www.planetacodigo.com/bundles/jquery")
   </body>
</html>

<script src="http://www.planetacodigo.comhttp://www.planetacodigo.com/bundles/jquery?v=UgyEMAYOuSB9Bb6HcOEVHpd6fIIp54yF086SRNVcdIY1"></script>

<script src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.9.1.min.js"></script>

2. Las novedades

var jquery = new ScriptBundle(
        "~http://www.planetacodigo.com/bundles/jquery", // Bundle virtual path
        "http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.9.1.min.js" // CDN Path
    )
    .Include("~/Scripts/jquery-{version}.js");

jquery.CdnFallbackExpression = "window.jQuery";
BundleTable.Bundles.Add(jquery);

<script src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.9.1.min.js"></script>
<script>(window.jQuery)||document.write('<script src="http://www.planetacodigo.com/bundles/jquery"><\/script>');</script>

BundleTable.EnableOptimizations = true;

Asp.net

• WebAPI Tip #5: Generating Links
  K. Scott Allen
• Per request error detail policy in ASP.NET Web API
  Filip W.
• ASP.NET WebAPI Tip #3: camelCasing JSON
  K. Scott Allen
• ASP.NET MVC Facebook Birthday App
  Rick Anderson
• How To Contribute to ASPNET Yourself
  Steve Smith
• Website Performance with ASP.NET: measuring, reduce time to first byte, make fewer HTTP requests. 
  Markus Greuel
• ASP.NET MVC Controller Dependency Injection for Beginners
  S. M. Ahasan Habib
• XSRF/CSRF Prevention in ASP.NET MVC and Web Pages
  Rick Anderson
• Building a Public HTTP API for Data
  Dino Esposito

Conceptos/Patrones/Buenas prácticas

• C is for cookie, H is for hacker – understanding HTTP only and Secure cookies
  Troy Hunt
• 97 Things Every Programmer Should Know
  O’Reilly
• When is Dependency Injection too Much?
  Alexandre Brisebois

Data access

• Firing an Entity Framework Database Initializer from within DbContext
  Rick Strahl

Html/Css/Javascript

• Ember.js - Client Side MVC Is Not Server Side MVC, Erase Your Brain
  Paul Cowan
• Angry Birds of JavaScript: Red Bird
  Elijah Manor
• 10+ jQuery Sticky Scroll Plugins
  Sam Deering
• Why All Those JavaScript Libraries?
  John Papa
• JS1K competition: create a cool JavaScript "application" no larger than 1k
  JS1K
• Basic JavaScript: Prototypical Inheritance vs. Functional Inheritance
  Jan Van Ryswyck
• Testing with CasperJS
  Vicenç García-Altés
• What's the CSS :scope pseudo-class for?
  Eric Bidelman

Visual Studio/Complementos/Herramientas

• Scriptcs: C# sin Visual Studio
  Juan María Hernández

Otros

• El secreto de la productividad
  José Manuel Alarcón

A cambiar el mundo

Una de las “actividades” surgidas de RubyConf Uruguay vino de la mano de Alan Cyment y Pablo Tortorella. Conocía a Alan porque fue uno de los coach en el curso de Scrum Master que hice en 2009. Pablo también es Agile Coach en Kleer, una de las empresas que sponsorearon la RubyConf, y el autor de esta obra de arte sobre RubyConf

Durante una lightning talk, Alan y Pablo plantearon cambiar el mundo en 5 minutos. Para esto, cada asistente debía encontrar un “compañero de ruta” que lo ayudara a cumplir ciertos objetivos que cambiarían el mundo.

En unos minutos había que definir algunas metas a futuro, basado en la experiencia de la conferencia. La primera para el lunes siguiente, la segunda para dentro de 2 semanas y la tercera para el 23 de setiembre (6 meses).

Mi primer objetivo para el lunes siguiente fue aplicar las medidas de seguridad de las que habló Bryan Helmkamp de Code Climate en su charla. Bryan habló sobre seguridad en aplicaciones Rails.

La herramienta que empecé a usar gracias a su charla es Brakeman, un analizador estático de seguridad para Rails. Instalarlo es bastante sencillo:

gem install brakeman

o podemos agregarlo a un Gemfile:

gem "brakeman", :require => false

Brakeman

Entonces usé por primera vez esta gema, y la agrego a mi “cinturón de herramientas” para Rails. Por suerte no encontré problemas mayores de seguridad en el proyecto en cuestión. De todas formas empezamos a usar Code Climate en este proyecto, y tenemos una nueva característica: Security Monitor, que nos avisa de riesgos de seguridad.

La participación de Alan, Pablo y Bryan en RubyConf Uruguay, en mi caso, ya rindió frutos. Excelentes personas que aportaron su grano de arena para que fuera una conferencia espectacular

Primer objetivo cumplido, el siguiente debería estar pronto para el lunes de la semana que viene, pero es un poco más ambicioso y todavía no empecé: Probar varias (y usar en algunos proyectos) de las gemas que comentó Soveran en su charla “sorpresa”, probar Padrino, probar mi código Ruby en JRuby y hacer deploy de alguna aplicación en Torquebox para conocer un poco de qué va la mano. Ampliaremos…

Hace poco terminaba el pequeño tutorial sobre compojure que he estado escribiendo y que me ha servido para hacerme una idea de cómo se desenvuelve un lenguaje funcional en aplicaciones “normales”.

Es cierto que he dejado sin cubrir partes importantes y necesarias en la mayoría de aplicaciones, como es el acceso a bases de datos (SQL o NoSQL), la autenticación y autorización, test unitarios, etc., pero creo que tengo la base suficiente como para empezar a buscar y valorar soluciones a cada uno de esos problemas por separado cuando llegue el momento.

Pese a esos aspectos que quedan en el aire, ha llegado la hora de hacer balance sobre lo que supone usar clojure para el desarrollo de aplicaciones web.

Las partes buenas

Sin duda, lo que más me ha gustado es la simplicidad y naturalidad con que encaja todo.

Para poder trabajar con compojure no hace falta comprender un montón de abstracciones y conceptos nuevos. Al final todo se reduce a definir funciones que reciben maps con las peticiones y devuelven maps con las respuestas.

Aquí además se nota mucho el uso de estructuras de datos sin esquema tan frecuente en clojure. Esto, unido a las opciones de desestructurado de clojure hace que sea muy sencillo obtener los datos que necesitamos de las peticiones para generar las respuestas.

Al trabajar con algo tan básico como funciones y maps, si necesitamos algo nuevo sólo necesitamos decorar nuestras funciones con middlewares como veíamos en el caso de recibir datos con JSON.

Esto además permite tratar todo de una forma mucho más homogénea si lo comparamos, por ejemplo, con ASP.NET MVC, donde el pipeline de proceso de peticiones es más complejo y debemos distinguir entre cosas como ActionFilters, HttpHandlers, Controllers, ModelBinders, ValueProviders, Results, etc., a la hora de decidir cómo implementar algo.

Otro aspecto que me ha gustado mucho es la forma en que se genera HTML usando Hiccup. Poder generar HTML usando el mismo lenguaje en el que estamos programando la aplicación hace que muchos de los problemas que hay que resolver con otros sistemas de plantillas directamente no existan en Hiccup.

Por ejemplo, el uso de controles/helpers para encapsular HTML es algo que se resuelve sencillamente creando una función que devuelva el HTML que necesitamos. Algo similar pasa con los layouts, no hace falta recurrir a nuevas abstracciones para resolver el problema porque estamos usando el mismo lenguaje en el que desarrollamos, por lo que las mismas técnicas que se usan para reutilizar código, las podemos aplicar en la generación de HTML.

Lo más parecido que he visto en C# son fluent builders para generar el HTML, pero aunque tienen la ventaja de tener tipado estático (y todo lo que ello conlleva a nivel de tooling), la sintaxis de C# mete demasiado ruido y acaban siendo poco legibles.

Las partes menos buenas

Nada es perfecto y hay algunas cosas que me han parecido más incómodas, algunas de ellas genéricas de clojure y otras específicas de algunas de las librerías que he usado.

Por una parte, la sintaxis hay veces que se hace un poco cuesta arriba. La simplicidad de conceptos que mencionaba antes tiene un coste: todo son funciones, todo son paréntesis. A veces se hace complicado seguir qué va dentro de qué, especialmente cuando se construyen estructuras complejas como las que se usan para generar HTML desde Hiccup.

Parte de esto se puede solucionar mediante tooling, pero tampoco es fácil. Parece que la forma canónica de escribir clojure es usando emacs y alguno de los cientos de configuraciones personalizadas para clojure, pero la verdad es que aprender a manejar emacs no es cosa de dos días y cuesta acostumbrarse, y no sólo por el paso de un IDE tipo Visual Studio a un editor más ligero, sino porque la filosofía de trabajo es bastante distinta.

Hiccup está muy bien y supone un cambio en la forma de pensar en la generación de HTML, pero si pretendes que te lo genere alguien que sepa diseñar páginas bonitas, se va a volver loco. De todas formas, que esto sea grave depende de cómo trabajes. La mayoría de las veces que he trabajado con diseñadores, no tenían acceso al código fuente y trabajaban “por libre”. Nos daban HTML y nosotros nos encargábamos de generarlo usando WebForms, Razor, o lo que tocase, por lo que puede que este punto no sería crítico.

En general, la documentación es un poco escasa y gran parte está repartida en posts e hilos de discusión desactualizados (como seguramente estarán estos posts dentro de unos meses). La parte positiva es que el código fuente tanto de compojure como de hiccup es bastante fácil de seguir, incluso aunque no seas un experto en clojure, como es mi caso.

Conclusiones

Desde mi época de estudiante siempre me ha atraído la programación funcional, pero nunca había intentado ponerla dentro de un contexto actual. Siempre la había percibido como algo académico y teórico, más enfocado a la experimentación y solución de problemas más “algorítmicos” que al mundo real.

Cuando desarrollo con C# hago bastante uso de las características funcionales del lenguaje (que no están mal), pero no dejo de estar en un entorno orientado a objetos con pinceladas funcionales. Al final lo que mandan son los objetos y la estructura de la aplicación está dictada por ellos.

Desarrollar la mini aplicación web del tutorial de compojure me ha permitido comprobar que realmente se puede llegar muy lejos con un lenguaje funcional en aplicaciones cotidianas. Me ha encantado la naturalidad y simplicidad con que se resuelven algunos problemas, sin necesidad de construir capas y capas de abstracción.

No hay posts relacionados.

Buenos días,

Nuestro distribuidor y gran amigo René Flores organiza una vez más un gran encuentro de usuarios de Xailer en Cancún, en el cual tendré el placer de poder presentar nuestra nueva versión de Xailer 3 y durante tres días revisaremos todas sus novedades, analizaremos los cambios que supone esta nueva versión, como afectará a sus propias aplicaciones y sobre todo veremos programación avanzada con Xailer. Desde la creación de controles de usuario, plantillas y asistentes, programación en la nube con WebDatasource, comunicaciones asíncronas y SQL avanzado. No obstante, me encantará oir vuestras sugerencias e incluirlas igualmente.

El sitio, Cancún, y el hotel, no puede ser mejores. Os animo a que vengáis. Lo pasaremos bien y además será muy productivo. Más información en el siguiente enlace:

http://www.blogger.com/comment.g?blogID=11070235&postID=5783582622724051840&page=0&token=1364556968242

Hasta pronto.

• AlertAppender: muestra las trazas usando la función alert del navegador.
• AjaxAppender: realiza una petición ajax al servidor enviando la traza generada en el navegador, con este appender podremos tener el registro de lo que sucede en los clientes. Se ha de indicar el path de la URL que procesará las trazas en el servidor.
• PopUpAppender: muestra las trazas en una ventana emergente en la que se pueden filtrar las trazas y en la que cada nivel aparece con un color distinto para reconocerlas más fácilmente.
• InPageAppender: muestra la misma consola del PopUpAppender pero de forma incrustada en el pie de la página.
• BrowserConsoleAppender: muestra los mensajes en la consola de depuración con los mensajes de javascript que incorporan los navegadores.

.Net  

• End-to-end Email Address Verification for Applications
  Vasudevan Deepak Kumar
• Splitting and Merging Pdf Files in C# Using iTextSharp
  John Atten
• Asynchronous models and patterns
  Florian Rappl

Asp.net

• Shopping cart with SignalR, ASP.NET Web API and Knockout.js
  Filip Woj
• Moving old apps from IIS6 to IIS8 and why Classic Mode exists
  Scott Hanselman
• WebAPI Tip #1 and #2: HttpStatusCodes and Overriding Conneg
  K. Scott Allen
• Database of HTTP status codes
  Samuel Ryan
• Using Require.js in an ASP.NET MVC application
  Jonathan Creamer
• Content Injector for ASP.NET MVC
  Peter Blum
• Glimpse 1.1 Released With Support for MVC 4
  Glimpse Team
• Content Negotiation with ASP.NET Web API
  Mira Javora
• Hacking Up A Glimpse Plugin
  K. Scott Allen
• An Introduction to Disqus (Pluggable Commenting System) with ASP.Net MVC 3
  Karthik A.

Azure / Cloud

• Windows Azure: New Hadoop service + HTML5/JS (CORS), PhoneGap, Mercurial and Dropbox support
  Scott Guthrie

Conceptos/Patrones/Buenas prácticas

• The Open-Closed Principle, in review
  Jon Skeet

Data access

• Demystifying LINQ
  James Hare
• Entity Framework Gotchas – Strategies for Orphaned Child Objects
  Kian Ryan
• GUIDs as fast primary keys under multiple databases
  Jeremy Todd

Html/Css/Javascript

• Superhero.js: collection of the best articles, videos and presentations
  SuperheroJs (vía @david_bonilla)
• Ember.js: Baby Steps
  Rob Conery
• Automatic Table of Contents
  Chris Coyier
• LESS: Preprocesador CSS con soporte en Visual Studio 2012
  Gisela Torres
• An Introduction to Meteor
  Stephen Walther
• A Quick Quiz using jQuery .data()
  K. Scott Allen
• Getting Into Ember.js
  Rey Bango
• Animating lists with CSS 3 transitions
  Steve Sanderson

Windows 8/WinRT/WP

• Windows Phone. Técnicas para compartir código. 1º Parte
  Javier Suárez

Otros

• Freedom to work
  Hadi Hariri

No es la primera vez que hablo de mi relación de mi amor/odio con los lenguajes de scripting. Son algo que considero imprescindible para crear esas pequeñas herramientas que mejoran tu flujo de trabajo, pero que se me resisten especialmente.

También he dicho que cada vez me da más pereza utilizar IDEs pesados, sobre todo cuando estoy experimentando con un lenguaje o resolviendo tareas sencillas, y que me gusta la forma en que se trabaja con otros lenguajes, como es el caso de Clojure con leiningen.

Por eso cuando me enteré del proyecto de Glenn Block para poder utilizar C# como lenguaje de scripting sin depender de Visual Studio, me pareció que merecía la pena dedicar un rato a echarle un vistazo.

¿Qué es scriptcs?

Lo mejor para entender scriptcs es leer el post de Glenn Block en el que explica los motivos que le llevaron a empezar el proyecto.

La idea de scriptcs es poder aprovechar Roslyn para compilar scripts escritos en C# y NuGet como gestor de dependencias. Con eso conseguimos montar un combo entre scriptcs y NuGet similar al de node.js y npm.

Con NuGet podremos instalar los paquetes que vayamos a utilizar y scriptcs se encargará de compilar “al vuelo” y ejecutar los scripts que escribamos.

¿Cómo se usa?

OJO: este proyecto es MUY nuevo, por lo que seguramente dentro de poco todo esto esté obsoleto. La información actualizada siempre la podrás encontrar en la web de scriptcs.

Para empezar a utilizar scriptcs sólo hacen falta dos cosas:

• Descargar el bootstrapper por línea de comandos de NuGet y añadirlo a alguna carpeta que esté en el path.
• Clonar el repositorio de scriptcs, compilar la solución y copiar los archivos resultantes a algún sitio accesible en el path.

Con esto ya podemos crear nuestro primer script. Creamos una carpeta y creamos dentro un fichero sample.csx:

using System;

Console.WriteLine("¡Soy un script simple!");

Como veis, no hay clases ni métodos (aunque se pueden añadir), sólo los using y el código. Ejecutarlo es muy sencillo:

scriptcs sample.csx

OJO: actualmente hay un bug en la rama master que hace que se genere un error si no hemos instalado ningún paquete con nuget y no existe la carpeta packages. Lo puedes evitar si creas a mano esa carpeta al mismo nivel que el script.

Si quieres añadir algún paquete, sólo tienes que instalarlo con nuget:

nuget install Nombre.Del.Paquete -o Packages

scriptcs lo detectará automáticamente y podrás usarlo desde tus scripts.

Un proyecto interesante

No es la primera vez que alguien intenta utilizar C# como lenguaje de scripting fuera del Visual Studio. Existen cosas como Snippet Compiler, CS-Script o incluso LINQPad. Usando System.CodeDom.Compiler es relativamente fácil hacer cosas similares (yo mismo hice algo parecido para Mono hace muchos años), pero la idea de usar Roslyn e integrarlo con NuGet abre muchas puertas.

Con Roslyn no estamos tan atados a la sintaxis habitual de C# y podemos adecuarla a un estilo más propio de lenguajes de scripting, y NuGet facilita mucho la gestión de dependencias sin necesidad de definir un archivo de proyecto en el Visual Studio.

La comunidad de desarrollo de C# está muy apegada a sus herramientas (es en lo que se ha centrado Microsoft siempre), por lo que esta filosofía de trabajo resultará extraña para muchos, pero en los últimos tiempos cada vez es más habitual trabajar con distintos lenguajes dentro de un mismo proyecto y acabar expuesto a otras formas de trabajo (estoy pensando fundamentalmente en node.js).

Tampoco creo que haya que verlo como algo excluyente, hay casos en que contar con todo un Visual Studio y sus múltiples utilidades de análisis estático, refactorización, gestión de proyectos, etc., es muy valioso, pero también es cierto que otras veces resulta excesivo.

En cualquier caso, me ha parecido un proyecto con un enfoque muy interesante y tengo ganas de ver hasta dónde es capaz de llegar.

No hay posts relacionados.

Tras el rediseño de la home, este fin de semana he hecho lo propio con este blog, que conociéndome iba a ser peligroso dejarlo pasar un par de semanas… Lo he hecho basándome en el diseño y hojas de estilo ya existentes, modificando algunas cositas para que se adaptara a la idea que tenía para el blog.

El proceso ha sido bastante rápido y sencillo, tan sólo 3-4 horas trabajando relajadamente sobre el theme de wordpress. Por consejo de Guillermo, en vez de empezar de cero o sobre alguno de los themes que ya tenía, me descargué uno generado basado en underscores. Al parecer un theme bastante utilizado como base por la comunidad de wordpress.

Aunque ya hacía mucho tiempo, el haber trasteado en varias ocasiones con los themes de wordpress es algo que me resultaba familiar. Enseguida empecé a recordar su estructura de ficheros y plantillas, a cambiar el css, a modificar los templates para que se ajustara a mi html y a lo que quería mostrar en la interfaz, a sustituir textos, etc.

Para haberlo hecho sin ayuda, con cositas mejorables y teniendo algunas dudas sobre si debería modificar algunos detalles, creo que no ha quedado del todo mal.

En fin, con esto creo que ya puedo dar por cerrado el tema del (más que necesario) re-diseño que tenía pendiente hacer.

Al fin puedo presumir de web .

• Se reduce la carga del servidor.
• La cantidad de datos devueltos es menor ya que el tamaño de la plantilla y los datos podrán ser menor que el html final generado por la combinación de ambos si una plantilla puede aplicarse varias veces sobre alguna lista de los datos.

Secciones

Secciones lista

Parciales

Compilación