Web


17
abr 12

SVG una tecnología en extinción

No Gravatar
SVG Logo

SVG Logo

Hace algunas meses atrás parte de algunas de las características que pensaba desarrollar en Celestic .. y que aún se encuentran pendientes, era crear una especie de pizarra que permitiera a multiples usuarios escribir o hacer anotaciones en tiempo real.. para ese entonces pensaba en solamente 2 opciones, canvas o svg.. incluso escribí algunas pruebas de diferentes librerías y al final estuve muy certa de utilizar RaphaelJS, eso sobre cualquier librería para canvas.

En ese momento, html5 no estaba muy difundido y las librerías de canvas estaban muy verdes para utilizar alguna, al final Celestic se detuvo un poco y decidí centrar el desarrollo en otro tipo de características.. Han pasado 3 años desde que tuve en mente si utilizar svn sobre canvas.. y hoy estoy a punto de cambiar de idea.

Las tecnologías cambian de la noche a la mañana, un día una nueva herramienta de desarrollo esta en la cima y otro día simplemente cae .. y lo peor es que nosotros nos preparamos tanto tiempo para aprenderlas .. que un día nos deja de servir y tenemos que empezar desde cero con algo totalmente nuevo.

La web cambia rápido .. ahora parece que flash ya no es una tecnología en la que valga la pena invertir.. hemos de aceptar que tuvo su gran momento, años de desarrollo y grandes comunidades dedicándose a perfeccionar los métodos de codificación.. para que al final no quede en nada.. “nada es eterno”.

Entonces creo que con SVG esta ocurriendo una situación similar.. los equipos de escritorio tienen soporte para SVG, los equipos móviles no lo tienen y si lo tienen es con especificaciones diferentes.. el SVG es una tecnología en extinción, los navegadores se estan especializando en pintar (render) canvas de manera muy rápida.. igualmente algunos browsers preparan su javascript para utilizar aceleración por hardware, lo que hace de canvas la nueva tecnología ideal para dibujar sobre la web.

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

10
abr 12

Habilidades a desarrollar en el 2012

No Gravatar
Developer skills

Developer skills

HTML5

El nuevo estándar en para desarrollo de sitios y aplicaciones web.. cargado de características que ayudan a mejorar la navegación y la experiencia de usuario tanto en componentes como en atractivo visual. La mayoría de los navegadores ya soportan html5 inclusive los navegadores para dispositivos móviles se puede decir que casi están al mismo nivel de los navegadores de escritorio.

Aplicaciones Móviles

Creo que esta moda aun no hay muchos desarrolladores adoptándola aunque si es muy importante por la cantidad de dispositivos móviles que se adquieren día a día.. Se puede empezar escribiéndo aplicaciones nativas con los SDK de iOS o Android ..  también se pueden desarrollar con frameworks que portan la aplicación a multiples plataformas.. o más sencillo que los demás escribir aplicaciones web que se adaptan al formato de los móviles.

Servicios Web basados en REST

A pesar de que REST no tiene un estándar y se continúa escribiendo una definición.. muchos servicios alrededor de la web utilizan este método para transportar información.. su sencillez y la falta de tipos de datos pueden ser un punto a tomar en consideración antes de elegirlo. Su implementación conlleva conocer los diversos tipos de peticiones y su consumo es tan simple que con pocas líneas se puede solicitar información a un servidor basado en REST.

Bases de Datos NoSQL

Se puso de moda a partir de que las redes sociales necesitaron manipular grandes volúmenes de información en tiempos muy cortos.. es importante considerar que NoSQL sería casi imposible utilizarlo para realizar consultas complejas, pero entre sus ventajas está la velocidad de respuesta ante millones de peticiones simultáneamente. Su uso implica aprender nuevos métodos para realizar búsquedas y está fuertemente ligado a la denotación JSON para su estructura y almacén de información.

JavaScript

Es el lenguaje para la web interpretado del lado del cliente por excelencia.. hace mucho tiempo parecía no valer la pena aprenderlo.. pero con la llegada de librerías como jQuery, Prototype o Mootools su desarrollo fue muy importante.. PhoneGap o Titanium que son frameworks o librerías para desarrollar aplicaciones móviles utilizan este tipo de lenguajes. Html5 está muy relacionado con javascript, inclusive se desarrolló Node.js que es un framework orientado a eventos para el motor javascript v8 de google.

Las pruebas unitarias

Este tipo de pruebas garantizan el funcionamiento correcto tanto desde el punto de vista estructural como funcional.. es parte de la difícil tarea de los arquitectos de software y a diferencia de las pruebas funcionales que se acostumbran llevar a cabo por los testers, en una temprana etapa de desarrollo de una aplicación, este tipo de pruebas permiten detectar errores en la lógica a desarrollar. La mayoría de frameworks en diferentes lenguajes ya incluyen sus propias implementaciones para realizar pruebas unitarias, no estaría mal aprender a utilizar un par de ellas.

UX/UI

Siempre este término ha estado relacionado con los diseñadores y hay diseñadores que creen que pueden crear interfaces atractivas, simples e intuitivas para los usuarios .. pero creo que ahí esta el error.. parte de desarrollar aplicaciones implica conocer cual es la mejor forma de utilizar los componentes o en que lugares sería mejor utilizarlos para los usuarios.. El uso de equipos móviles han logrado que muchos desarrolladores empiecen a dar pequeños saltos hacia este interesante mundo..

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

3
abr 12

RESTful API Frameworks en PHP

No Gravatar
REST vs SOAP

RESTful services

La semana anterior liberé la versión 0.4.0 de Celestic y una cosa que había prometido y que al final no logré hacer era escribir una API en REST para  utilizarla desde equipos móviles.. Bueno, al menos hay una versión preliminar pero decidí no subirla a los respositorios de código porque eran pruebas .. y es que durante varios días estuve investigando y probando herramientas para el desarrollo de esta API, al final no utilicé ninguno de estos frameworks y estoy escribiendo mi propia extensión para Yii la cual funcionará tomando datos de los modelos y exportando los resultados a json y xml..

Entonces al grano, esta es una lista de frameworks o librerías que podrían ayudarte a construir tu propia API en REST sobre PHP ..

FRAPI – Fue una de mis primeras opciones.. pero después de pocos minutos revisando como instalarlo y configurarlo lo abandoné porque al ver que tenía una parte de administración y otra de consumo me desanimé.. en realidad lo que buscaba era algo más simple.. Desde la interfaz de administración y también consola se pueden crear acciones (esto viene hererado del MVC donde solicitas a un controlador una accion específica que termina siendo un método a ejecutarse).

APIFY – Muy parecido a Frapi, incluso al descomprimirlo vemos una estructura de carpetas tipo MVC.. lo probé pero por alguna razón que aun desconozco nunca funcionó.. su documentación es muy escasa.. en realidad toma muchas cosas de Zend Framework y la librería base para crear REST se reduce a clases Request y Response.

Recess – No tuve oportunidad de probarlo a fondo, al igual que los demás utiliza el patrón de diseño MVC, su interfaz para el desarrollo del servicio esta basado en web a través del navegador. Creo que es de los mejores, pero tiene bastantes archivos y eso no me gustó mucho. Utiliza PDO y mapeo de basee de datos, punto negativo creo que son las consultas entre tablas anidadas.

Slim – No tuve ganas de probarlo, aunque a diferencia de los demás Slim no es un framework, sino más bien una librería o un set de librerías.. Me gustó cuando ví el código pero me desanimó el hecho de que utilizan sus propias rutas y la ausencia de activeRecords.

Tonic – También es una librería, es bastante simple para lo que buscaba y de las cosas que alcancé a probar pues de eso decidí mejor construir mis propias clases para generar REST, me dió la impresión de que me ahorra muy pocas cosas..

En general todos los frameworks y librerías son muy buenos para trabajar utilizando su propio esquema o estructura de carpetas.. Un punto negativo que tienen todos es que los que utilizan PDO y model mapping no es muy bueno con los join y las consultas complejas puede que sea un dolor de cabeza.. Ninguna utiliza un esquema de autenticación compleja como OAuth o al menos Basic Auth .. y si utilizan seguridad lo hacen mediante un parámetro extra que se envia por la url..

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

30
mar 12

La Web Tridimensional : WebGL

No Gravatar

WebGL Es una especificación estándar en desarrollo que permite mostrar gráficos tridimensionales acelerados por hardware en navegadores web sin necesidad de instalar software adicional al navegador (plug-ins).

En realidad es una API para javascript que permite usar OpengGL incorporado en los navegadores.[1]

WebGL utiliza un elemento de HTML5 llamado Canvas el cual permite mostrar gráficos 2D e imágenes de una manera dinámica, canvas consiste de una región dibujable definida en código HTML con los atributos de altura y espesor, el código javascript permite acceder a esa región a través de un conjunto completo de funciones de dibujo 2D, esto es lo que permite generar los gráficos dinámicamente. [2]

Esta especificación es gestionada por el consorcio de tecnología Kronos Group.

http://www.khronos.org/webgl/

Para comenzar hay unos muy buenos tutoriales para aprender a usar WebGL [3], que son referencia obligada para entender como funciona esta tecnología.

Para acelerar las cosas existe una biblioteca 3D en javascript llamada three.js, la biblioteca provee <canvas>, <svg> y render WebGL.[4] creada por mrdoob : https://github.com/mrdoob

demos

Demos de mrdoob

En esta biblioteca se incluyen funcionalidades para manejo de camaras (ortografica y perspectiva), funciones para manejar la geometria, el color, vertices, splines, matrices, luces, materiales, objetos (esqueletos, modelos, modelos animados, particulas, etc), renders (canvas, dom, svg, webgl), escenas, texturas y muchas otras mas : http://mrdoob.github.com/three.js/docs/48/#Camera

Y este es un ejemplo de un trabajo muy bueno usando esta tecnología Web3D.

http://www.ro.me/

Una cuestión interesante sobre WebGL es que es un estandar que ha sido adoptado para integrarlo en las nuevas versiones de los navegadores web de Google (chrome) y Mozilla (firefox) incluso de Apple (safari) pero no así en internet explorer de Microsoft pues menciona cuestiones de seguridad para no hacerlo. Por el momento WebGL sigue avanzado.

Nota:

“Los gráficos vectoriales escalables (svg) es una especificación para describir gráficos vectoriales bidimensionales estáticos o anímados en formato xml.” [5] 

Referencias:

[1]http://en.wikipedia.org/wiki/Canvas_element


[2]http://en.wikipedia.org/wiki/WebGL


[3]http://learningwebgl.com/blog/?page_id=1217


[4]https://github.com/mrdoob/three.js/


[5]http://en.wikipedia.org/wiki/Scalable_Vector_Graphics


[6]http://es.wikipedia.org/wiki/Khronos_Group

Imagen y demos:

http://mrdoob.github.com/three.js/


http://mrdoob.com/


http://alteredqualia.com/

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

27
mar 12

Consumiendo REST desde C#.NET

No Gravatar
Consumir RESTful en .NET

Consumir RESTful en .NET

Hace algunos días atras buscaba una forma decente y elegante de crear mi propia api utilizando RESTful para Celestic .. de esa forma fue que llegue a StackOverflow y muchas preguntas de usuarios necesitando código para consumir servicios basados en REST.. En este sitio todavía no colaboro por lo que no quize responder, ya pensándolo bien fue que decidí escribir este artículo.

Sé que hay otra manera de hacerlo.. pero para este ejemplo utilizaremos el objeto HttpWebRequest y HttpWebResponse, entonces comenzamos:

var postString = new {clave1:valor1, clave2:valor2};
byte[] data = UTF8Encoding.UTF8.GetBytes(postString);
 
HttpWebRequest request;
request = WebRequest.Create("http://localhost/ejemplo/api") as HttpWebRequest;
request.Timeout = 10 * 1000;
request.Method = "POST";
request.ContentLength = data.Length;
request.ContentType = "application/json; charset=utf-8";

Básicamente lo que se hace es instanciar de HttpWebRequest y setear algunos parámetros, entre ellos y mas importante el método (Method), la longitud de la petición (ContentLength) y el tipo de dato a enviar (ContentType). No pierdan de vista que estoy enviando postString que a su vez es un objeto tipo Json.

La mayoría de servicios basados en REST requieren autenticación básica.. y pues es una de las más fáciles de utilizar.. inclusive desde el navegador se puede hacer, lo único que se requiere es un usuario y una clave de acceso..

string credentials = Convert.ToBase64String(ASCIIEncoding.ASCII.GetBytes("usuario:clave"));
request.Headers.Add("Authorization", "Basic " + credentials);

Esto es como algunas páginas en internet que piden autenticación para entrar, donde puedes escribir la url y esperar a que aparezca el formulario de inicio de sesion o escribirlo directamente en la url.. de la forma: “usuario:clave@http://localhost/ejemplo/api”

Ahora lo siguiente y último paso es enviar los datos y obtener la respuesta..

Stream postStream = request.GetRequestStream();
postStream.Write(data, 0, data.Length);
 
HttpWebResponse response = request.GetResponse() as HttpWebResponse;
StreamReader reader = new StreamReader(response.GetResponseStream());
string body = reader.ReadToEnd();

Y para finalizar body es el contenido de lo que ha respondido el servicio, recuerden que la respuesta es tipo Json.. por lo que pueden interpretarla facilmente con javascript o hacer algo más complejo si desean parsearlo desde .NET.

Espero les sirva el código.. y si encuentran algun error, recuerden que el formulario de comentarios no muerde.. :D

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

13
mar 12

Aplicaciones moviles – nativas vs web

No Gravatar
Aplicaciones nativas vs aplicaciones web moviles

Aplicaciones nativas vs aplicaciones web moviles

Ya desde el año pasado había estado dando pequeños pasos y haciendo pruebas de desarrollo para iPhone y Android, tratando de conocer las fuerzas y debilidades de estas plataformas, conociendo el flujo de trabajo y tiempos que podría tomar desarrollar una aplicación. Después de mis pruebas obtuve resultados y en la comparación fue cuando noté que es realmente caro desarrollar aplicaciones nativas para cada plataforma (iOS, Android, BlackBerry o Windows Phone).

Ahora con el auge de las aplicaciones web, el uso extensivo de javascript, css y estándares web.. veo una gran ventaja el desarrollar aplicaciones móviles web en lugar de aplicaciones nativas. Sé que este tema en la red es un debate de nunca terminar, pero no se trata de comparar ambas formas de desarrollo diciendo que una es mejor que otra.. Algunas aplicaciones hechas específicamente para los dispositivos móviles podrían portarse a una aplicación web y otras quizás no.. todo depende de la naturaleza de la aplicación y si o no debe de interactuar con el hardware.

Entonces que diferencias existen entre una aplicación nativa y una aplicacion web móvil ?

Las aplicaciones nativas realizan tareas específicas que podrían ser el uso de la agenda, grabar o reproducir música, tomar fotografías o utilizar el hardware del equipo al máximo para tener el mejor rendimiento en una aplicación.. como por ejemplo los juegos que necesitan muchos recursos para ejecutarse y disponen en su totalidad del procesamiento del equipo para funcionar. En cambio una aplicación web móvil es una pieza de software que simplemente dá acceso a herramientas de seguimiento visual, donde no es necesario interactuar con el equipo, por ejemplo los manejadores de tareas o aplicaciones donde solo se necesite ingresar información y ver resultados.

Y que tan fácil puede ser desarrollar una aplicación web para los móviles que sea compatible con cualquier dispositivo ?

Existen aplicaciones tales como Sencha, PhoneGap, Titanium, Rhomobile, ParticleCode, CoronaSDK, Mosync, etc… que se desarrollan como aplicaciones web o con una sintaxis muy similar y que al final se traducen las diferentes plataformas móviles.. claro, esto con algunas diferencias porque mientras unas aplicaciones traducen todo el código a código nativo, otras simplemente  crean una aplicación web y la dejan en un contenedor nativo que sería casi un browser personalizado. Este tipo de aplicaciones se conocen como aplicaciones Híbridas ya que utilizan ciertas características físicas de los equipos pero son básicamente aplicaciones web.

A su vez, existen frameworks para desarrollo de aplicaciones web que igualmente emulan apariencia y comportamiento de las aplicaciones nativas, tales como son: The-M-Project, jQuery Mobile, Sencha Touch, jQTouch, DHTMLX touch, SproutCore, etc.. solo que este tipo de herramientas no nos permiten utilizar las características del equipo y son aplicaciones netamente web que se montan en un servidor de aplicaciones y se sirven como sitios web.

En cuanto a las dificultades que podemos tener al desarrollar aplicaciones móviles con estas herramientas, pues para empezar es difícil que  existe una curva de aprendizaje que quizás será menos pronunciada que aprender el lenguaje nativo para desarrollar aplicaciones pero es tiempo al final de cuentas, fácil hasta el punto en que se comienza a pensar en componentes o funcionalidades específicas que aunque se pueden desarrollar en las aplicaciones web, puede que sea más complicado hacerlo o adaptarlo para todos los dispositivos y es ahí donde esta el reto (pensando en equipos móviles o tablets).

Que forma para desarrollar aplicaciones es más segura ?

Definitivamente contestaría que las aplicaciones nativas son más seguras ya que la información nunca es enviada a través de internet y siempre se mantiene en el dispositivo.. aunque también pensando de otra manera diría que una aplicación que funciona local no almacena respaldos por lo que la información esta propensa a dañarse..

Y que puede ser más costoso mantener ?

Igualmente ambos tipos de aplicaciones tienen sus pros y sus contras.. por un lado las aplicaciones nativas viven en los dispositivos móviles lo cual no genera ningún tipo de costo adicional al desarrollo.. Mantener este tipo de aplicaciones implicaría que quienes hayan descargado una versión, vuelvan a descargar la actualización.. Por otro lado, las aplicaciones móviles tienen un costo de mantenimiento para quienes las desarrollan ya que por su naturaleza deben vivir en un servidor en internet lo cual genera un costo anual.. En cuanto a las actualizaciones es mucho más fácil para quienes las utilizan ya que no necesitan descargar nada adicional, ya que todo ocurre de manera centralizada.

Aplicaciones nativas, híbridas o web para móviles compiten actualmente en el mercado.. cada una con sus puntos en contra y a favor.. yo recomendaría siempre evaluar los alcances, los recursos, los costos y tomar como punto de partida una aplicación web que es multiplataforma, en caso de que los requerimientos sean superiores o se tenga dificultades para utilizar este tipo de aplicación.. entonces lo mejor es dar el salto hacia aplicaciones nativas.

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

28
feb 12

jQuery Mobile lo bueno y lo malo

No Gravatar
JQuery Mobile

JQuery Mobile

Desde mi blog la semana pasada hacía una reseña sobre 3 diferentes alternativas para desarrollar aplicaciones web para teléfonos móviles (iPhone, Android, Blackberry, Windows Phone, etc) .. al final decidí quedarme con jQuery Mobile por la sencillez y rápida curva de aprendizaje.. además que estaba trabajando en un prototipo de proyecto que no debía tomarme más de 3 días desarrollarlo. En fin, el propósito de este artículo es mostrarles de que manera funciona esta librería.. las carencias que encontré y las virtudes que pueden ayudar a escribir aplicaciones móviles en casi cuestión de horas.

Como funciona

Las aplicaciones web básicamente trabajan 2 capas que son el procesamiento de datos, algo que siempre ocurre del lado del servidor y la presentación de la información que es lo que el servidor regresa a los navegadores en un formato de meta etiquetas (html) .. pues bueno, jQuery Mobile agrega una capa extra que sería como una especie de manejador de eventos que se encarga de escuchar todas las pulsaciones que hacemos sobre los enlaces y botones de formularios para luego solicitar al servidor su proceso vía ajax .. La verdad es que la lógica de como funciona es muy simple porque todo ocurre mediante callbacks.. Si llegan a ver algunos ejemplos de como son estas aplicaciones desarrolladas con jQuery Mobile verán transiciones de entrada y salida entre las páginas y pues esto es el resultado de esas peticiones administradas vía ajax.. Y como todo lo que se hace con javascript, jQuery Mobile se puede parametrizar para que tenga el comportamiento que deseamos.

La tecnología que emplea

Es importante mencionar que esta librería y así he decidido llamarlo porque no creo que llegue al nivel de framework.. su uso esta basado totalmente en HTML5 .. ese nuevo estandar de desarrollo web que se está poniendo de moda.. y CSS3 que vienen a ser como el estilista del HTML5.. entonces si defino a jQuery Mobile diría que es una combinación de mucho HTML5 que utiliza inteligentemente metadatos en las etiquetas, canvas para dibujar algunos botones y CSS3 para administrar la capa visual (esquinas redondeadas, gradientes lineares, sombras y más)…

Una buena recomendación

Si estan interesados en empezar a desarrollar aplicaciones móbiles nativas, creo que antes deberían de entrarse un poco en el uso de este tipo de herramientas para desarrollar la visión del diseño de como son las aplicaciones móbiles, ya que la naturaleza de este tipo de aplicaciones requiere de otro tipo de destrezas relacionadas más que todo con usabilidad que al final es la parte visual y lo que más interesa a los usuarios. Con esto no estoy tratando de decir que las aplicaciones móbiles web son mejores que las nativas.. claro que no!! sería imposible hacer la comparación, pero en el caso de que se necesita escribir una aplicación en tiempo record que sea multiplataforma.. lo más obvio sería utilizar jQuery Mobile o cualquier otra herramienta para este propósito y bueno, eso sin mencionar que el costo monetario es mucho muy inferior.

Lo que hay que tener en cuenta

Es bueno recordar que las aplicaciones móbiles no deben ser complejar, el contenido debe invitar a los usuarios a navegar y al mismo tiempo a constuir un mapa de enlaces en la mente para que sepan como utilizarla casi inmediatamente. Eso significa que no se deben de pensar en interfaces complejas o en componentes que puedan confundir a quienes la usen. Jquery Mobile tiene como elementos básicos los componentes de formularios (input, select, checkbox, radio y button).. otros elementos serían las listas, barra de navegación y es todo.. igual que con jQuery hay desarrolladores externos que estan escribiendo plugins como por ej. datepickers o uploaders que son necesarios y no estan incluidos en la librería.

Utilizarlo con moderación

Creo que antes de decidir su uso o no.. deberían de tomar uno de los ejemplos de la página de ayuda y ver si es compatible con los dispostivos en los que pensarían utilizarlo.. por. ej. yo utilizo un Android 2.3 donde las imágenes y animaciones no son tan fluídas.. lo he probado en un iPhone 3GS y lo ví un poco torpe con las animaciones.. con el iPhone 4 se vé de maravilla al igual que con una tablet android con 3.0 y tampoco tuvo problemas..

Al final la aplicación que escribí es un ligero CRM con un enfoque hacia seguimiento de ventas.. si!! tarde 3 días en el desarrollo, aun es una versión beta y fue rápido hacerlo porque tras el código estuvo una arquitectura MVC.. si me animo quizás suba el código a github y luego al laboratorio de Qbit para que aprendan un poco sobre jQuery Mobile.

Y para finalizar el resultado final en un teléfono LG Optimus Black.. nada mal eh..!!

Mobile CRM

Mobile CRM

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

24
feb 12

Arreglando compatibilidad IIS6 y reporviewer con IIS7 Windows Server 2008

No Gravatar

Hace poco tuve unos contratiempos con una aplicación WEB desarrollada para funcionar con IIS6
pues en el servidor donde se quería instalar era una versión más actual corriendo IIS7 más concretamente en un Windows Server 2008.

Para empezar, el instalador de la aplicación web no se ejecutaba correctamente, pues no permitía terminar el último paso de la instalación. Y además los reportes elaborados con reporviewer tampoco se visualizaban correctamente.Así que a investigar un rato en internet para saber como resolver los problemas.
Y encontre lo siguiente:

Para instalar los componentes para la administración de compatibilidad IIS6.0 usando el administrador del servidor de Windows Server 2008 y corregir el error en el instalador de la aplicación Web.

    1. Primero hay que presionar en el botón Inicio.
    2. Dar clic sobre Herramientas Administrativas y luego en Administrador del servidor.

      CompatibilidadII6-01

      CompatibilidadII6-01

    3. En el árbol de navegación de la izquierda expandir “Funciones” y con el botón derecho dar clic sobre “Servidor web (IIS) y seleccionar agregar servicios de función.
    4. En la lista de Servicios de función desplazar la barra hacia abajo y localizar las opciones
      “Compatibilidad con la administración de IIS6”.
    5. Seleccionar los check boxes para:
      Compatibilidad con la metabase de IIS6.
      Compatibilidad con WMI de IIS6.
      Herramientas de scripting de IIS6.
      Consola de administración de IIS6.

      CompatibilidadII6-02

      CompatibilidadII6-02

    6. Presionar el boton “Siguiente>” luego presionar el botón “Instalar” y confirmar la instalación.
    7. Presionar el botón Cerrar y salir del asistente de Servicios de función.

      CompatibilidadII6-03

      CompatibilidadII6-03

La compatibilidad con IIS6 se encuentra instalada.

Visto en:

http://www.activexperts.com/support/network-monitor/online/ii6metabase/

Para corregir los errores de visualización en los reportes de reporviewer:

Primero se necesita instalar el paquete distribuible 2008 de reporviewer

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=6576

CompatibilidadII6-04

CompatibilidadII6-04

También puede ser útil darle un vistazo a esta página:

http://praveenbattula.blogspot.com/2010/03/fix-to-report-viewer-problems-in-iis-7.html

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

21
feb 12

How to Gridview con MVC Contrib para ASP MVC

No Gravatar
MVC Contrib

MVC Contrib

Como saben asp mvc 2 no tiene componentes visuales que nos ayuden a mostrar la información.. e ilógicamente eso es lo que más me ha gustado de este framework ya que eso nos permite tener el control total de las aplicaciones web.. a diferencia de webforms que se incluía código de más y era muy tedioso mezclar componentes propios que utilizaran ajax con su scriptManager y su updatePanel..

Entonces esta vez nos encontramos con el ya conocido problema de que asp mvc no tenemos un componente de tipo grid nativo.. por lo que básicamente tenemos 3 opciones para implementar uno.. la primera solución es hacerlo a mano.. escribiendo un tabla y vaciando todos los datos, creando paginación, agregando ordenamiento de registros por columnas y estilizándola porque siempre es necesario que se vea bonito.. la segunda opción es utilizar componentes ya escritos y comerciales por su puesto.. (Telerik, DevExpress, Ext, jqGrid) o la tercera opción que sería buscar alternativas de código abierto como MVC Contrib (CPOL) .. que esta última opción sería nuestra elección.

Entonces para empezar lo primero que se debe de hacer es descargar MVC Contrib de esta dirección http://mvccontrib.codeplex.com/releases .. es importante mencionar que MVC Contrib es una suite de componentes, pero en este ejemplo solamente utilizaremos el componente grid..

Una vez que hayamos descargado los archivos lo que necesitaremos será descomprimirlo, ubicar el archivo MvcContrib.dll y agregarlo como referencia a nuestro proyecto en Visual Studio.. Para poder generar un grid con datos necesitamos un modelo que luego será el contenedor de la información.. entonces lo siguiente es crear una clase de tipo modelo.. que en mi ejemplo sería lo siguiente:

UsuariosModel.cs

namespace MvcContribExample.Models
{
    public class UsuariosModel
    {
        public string nombre { get; set; }
        public string apellido { get; set; }
        public string deporte { get; set; }
    }
}

Listo.. ya tenemos nuestro modelo.. ahora vamos a trabajar con el controlador para manejar la primera petición a nuestra página y que automáticamente se cree el grid con datos.. entonces simplemente para generarlo damos clic derecho sobre la carpeta “controllers”, seleccionamos agregar y luego tomamos la opción “Controller…” —  como esto es un ejemplo muy básico no necesitamos que se genere nada.. asi es que la opción de agregar otros métodos no la requerimos..

HomeController.cs

using System.Collections.Generic;
using System.Web.Mvc;
using MvcContribExample.Models;
using FizzWare.NBuilder;
 
namespace MvcContribExample.Controllers
{
    public class HomeController : Controller
    {
        public ActionResult Index()
        {
            var listaRandom = Builder<UsuariosModel>.CreateListOfSize(20).TheFirst(1)
                .With(x => x.nombre = "Jack")
                .And(x => x.apellido = "Fiallos")
                .And(x => x.deporte = "Baloncesto")
                .Build();
            var model = (List<UsuariosModel>)listaRandom;
            return View(model);
        }
    }
}

Por ahí verán que estoy utilizando NBuilder (using FizzWare.NBuilder;).. pero no es necesario que ustedes lo tengan en su proyecto.. NBuilder lo que hace es generar una lista arbitrária de datos.. es muy útil para hacer pruebas.. al final lo que NBuilder genera es una lista que se debe convertir a (List[UsuariosModel]) que es lo que espera el grid.

Ahora que en nuestro controlador tenemos un método llamado Index .. necesitaremos una vista con el mismo nombre.. entonces en la carpeta Views crearemos otra carpeta llamada Home y dentro de ella una vista llamada Index..

Y una vez con la vista Index generada pegamos el código del grid.. que sería algo como lo siguiente:

Views/Home/Index.aspx

<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage" %>
 
<%@ Import Namespace="MvcContrib.UI.Grid" %>
<%@ Import Namespace="MvcContribExample.Models" %>
 
<!DOCTYPE html> 
<html> 
<head runat="server">
    <title>MVC Contrib Example, Ejemplo o como le quieran llamar</title>
</head>
<body>
    <div class="grid">
    <% Html.Grid((List<UsuariosModel>)Model)
       .Columns(column =>
       {
         column.For(c => c.nombre);
         column.For(c => c.apellido);
         column.For(c => c.deporte);
       }).Attributes(@class => "gridclass", @id => "gridview").Empty("Sin registros :(").Render();
    %>
    </div>
</body>
</html>

Y voilá.. habemus grid sin tener que escribir tanto código..  Ahora hay cosas extras que faltarían para tener un grid hecho y derecho.. como por ejemplo la paginación, ordenamiento datos por columnas y colorear las filas tipo zebra striped.. pero eso sería tema de otro artículo.. para adelantarme un poco.. yo utilicé los estilos de twitter bootstrap y agregué como estilo “zebra-striped bordered-table” .. además incluí jquery.tablesorter para permitirle al grid ordenarse por columnas.. algo de paginación con el mismo componente de MVC Contrib y ajax para paginar el grid sin recargar toda la página.

Espero les sirva para entender el funcionamiento de MVC Contrib, Nbuilder que no era parte del artículo pero que al final lo incluí para efectos de prueba y hasta casi un pequeño tutorial de ASP MVC. :D

Y porque no quiero dejar nada inconcluso.. dejo el código fuente que utilicé para el ejemplo.. MvcContribExample

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

14
feb 12

REST vs SOAP

No Gravatar
REST vs SOAP

REST vs SOAP

Aunque REST y SOAP son arquitecturas muy similares de intercambio de información entre aplicaciones web y de escritorio con servidores, antes de decidirse por uno de ambas es importante tener en cuenta las siguientes consideraciones. Trataré de ser objetivo en este artículo ya que hasta hace poco empecé a utilizar REST (4 meses), todo lo que aprendí sobre websvices esta basado en SOAP.

Primeramente hay que entender que REST esta basado en una arquitectura donde se identifican los recursos claves a consumirse.. veámoslo como una forma semántica de escritura ante la web donde hay métodos que al ser interpretados nos retornan información… Algo como por ejemplo utilizando el método GET del protocolo HTTP (digo GET porque también se puede utilizar POST, PUT, HEAD, DELETE, etc.. ) haría una petición de la siguiente manera: “http://servidor.com/api/proyecto/1/tarea/5″  .. donde api es el contenedor de mi webservice y lo que sigue sería equivalente a decir.. Del proyecto con identificador no. 1 seleccionar la tarea con identificador no. 5 y mostrar el resultado en formato json o xml.

Así de fácil es REST, mientras que SOAP es un poco más complicado por que lo que se consumen son métodos o funciones almacenadas igualmente en un servidor.. entonces si quisiera hacer lo mismo.. en SOAP tendría que escribir algo como lo siguiente: “http://miservidor.com/api/calcula” donde calcula contiene una definición de funciones (sumar y restar) que se pueden implementar mediante la creación de un objeto, un concepto de la programación orientada a objetos .. del uso de alguno de los métodos listados en el servicio calcula como respuesta obtendría una salida en xml con una definición del tipo de datos que respondió el servidor..

Si se fijan ambos tipos de conexión ya sea REST o SOAP se parecen mucho, ya que sirven para solicitar información a un servidor, pero distan de implementarse de una manera similar.. verán que REST es mucho más fácil y SOAP conlleva escribir un poco más de código..

En la actualidad muchos de los servicios que utilizamos a diario como twitter, facebook, fourquare, delicious, flickr, etc.. estan basados en REST por la facilidad de imlementación y la simplesa que se obtiene en los resultados.

SOAP ya que tiene una arquitectura de respuesta más compleja, es utilizado comunmente en corporaciones, hasta me atrevería a decir que la mayoría de empresas que utilizan sistemas basados en .NET o Java tienen sus servicios de comunicación basados en SOAP .. porque ha decir verdad es muy fácil implementar esos objetos y consumir esos métodos.. porque claro!! hay personas que ya hicieron todo el trabajo pesado de crear librerías que se usan casi con un par de líneas. Además que en estos lenguajes se tienen componentes visuales que se conectan casi de manera transparente a webservices basados en SOAP por lo que como dije.. ya todo lo interesante ya se hizo.

Entonces ya que tenemos una mejor idea de que hace REST vs SOAP podemos hacer comparaciones y obtener una conclusión..

REST

En lo que es genial

  • Es muy ligero, sus respuestas contienen exactamente la información que necesitamos.
  • Para los nosotros los humanos es muy fácil y simple de interpretar.
  • Es sencillo de desarrollar y no se necesita mucho código extra.
  • Es flexible en cuanto al tipo de respuesta que se necesita, ya que puede ser xml o json.
En lo que falla
  • Creo que la seguridad es un problema y puede llegar a ser una tarea muy difícil implementarla correctamente.
  • No hay un estándar en sus respuestas por lo que no se definen tipos de datos.
SOAP

En lo que es genial

  • Si trabajas con componentes y utilizas .NET o Java es muy sencillo de consumir.
  • El resultado que siempre es XML contiene una definición específica del tipo de dato, lo que hace del protocolo algo muy estricto.
  • Se dice que es más seguro porque su implementación siempre o la mayoría de las veces se hace del lado del servidor.

En lo que falla

  • Una vez implementado, si se desea cambiar algo en el servidor impacta de forma negativa en los clientes ya que estos tienen que hacer muchas modificaciones al código.
  • Las respuestas son demasiado complejas y difíciles de interpretar si no se tienen las herramientas correctas para hacerlo.

Conclusión

Creo que ambas arquitecturas de intercambio de información tienen sus nichos bien definidos, cuando se trata de aplicaciones públicas refiriéndome a servicios de uso masivo es mucho mejor utilizar REST por la sencillez en su implementación y respuestas, inclusive en clientes móviles es mucho más fácil utilizar REST. Por otro lado si se esta pensando en webservices para corporaciones donde se manejan datos complejos y se necesita una presición detallada en las respuestas se debe de utilizar SOAP, entornos de desarrollo como Visual Studio hacen que el desarrollo e implementación de SOAP sea sumamente sencillo sin tener que escribir código de más para interpretar respuestas.

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

Qbit Mexhico Blog is using WP-Gravatar