Algo que no debería faltar en mi blog, es un clásico pero…

101 Ejemplos de código en Visual Basic.Net

En los siguientes links estan disponibles 101 ejemplos de Visual Basic.net 2003 y Visual Basic.Net 2005 para todos aquellos programadores o desarrolladores que desean aprender cada día más y más.

Espero que estos ejemplitos les pueda ayudar a todos los que necesiten alguna ayudita o esten aprendiendo a programar en .Net

• 101 Ejemplos de Código en Visual Basic 2003
• 101 Ejemplos de Código en Visual Basic 2005

El futuro lenguaje de programación: “D”

“D” es un lenguaje de programación de uso general desarrollado por Walter Bright cuya primera versión apareció en 1995, resultado de décadas de investigación y experiencia de programadores expertos en muchos lenguajes.Es de un nivel más alto que C++, pero conserva la capacidad de escribir código de alto rendimiento y de interconectar directamente con él los APIs de un sistema operativo o el hardware. Además se comporta bien con programas de gran escala con un millón de líneas, que desarrollan equipos de programadores.

D es fácil de aprender, proporciona muchas funciones para ayudar al programador, y cumple bien con la tecnología agresiva de optimización del recopilador. Es un lenguaje compilado, no interpretado. Es un lenguaje práctico para programadores que necesitan conseguir un trabajo finalizado rápidamente, con un código fácil de entender.

C++ es el lenguaje al que D aspira a sustituir. Es un lenguaje evolucionario, no revolucionario y en un principio puede parecer que no aporta demasiado sobre C++, Pero no son las características generales sino los detalles de las mismas los que marcan la diferencia. En primer lugar D conserva todas las características de expresividad de C++ (cosa que ni C# ni mucho menos Java consiguen en su afán por hacerse lenguajes más accesibles), pero con una sintaxis y unas construcciones mucho más sencillas y lógicas. Además, otro de los puntos fuertes de C++, su rendimiento, también se ve reflejado en D (en algunas ocasiones incluso superado.)

Por otro lado D cuenta con muchas otras mejoras e incluso características de las que C++ no dispone, las cuales se enumeran a continuación. Al contrario de lo que pasa con Java o C#, estas características no suponen una pérdida apreciable de rendimiento para D en comparación con C++:

• Gestión automática de memoria (recolección de basura)
• Delegados, funciones anidadas y funciones literales
• Sobrecarga de operadores y propiedades sin sobrecargar al programador
• Estructuración: Módulos y paquetes
• Propiedades
• Programación genérica muy mejorada
• Programación por contratos
• Mantenibilidad y fiabilidad
• Compilación condicional sin sucios preprocesadores
• Compatibilidad con C sin cargar con C
• Arrays asociativos

Entre otras. Para información avanzada consultar enlaces externos.

Ventajas

• Lenguaje más intuitivo y fácil de aprender que C, C++ o Java, con gran cantidad de mejoras respecto a estos.
• Compatibilidad con los binarios de C (no C++).
• Lenguaje compilado (no se ejecuta en una máquina virtual, como Java).
• Garbage collector o recolector de basura (sistema que libera la memoria dinámica cuando ya no se necesita, como Java, pero con posibilidad de desactivarlo si se desea mayor control).
• Elimina parte de la complejidad de sintaxis de C++.

Inconvenientes

• Aún no se considera terminado, por lo que puede haber cambios en la especificación. Sin embargo, ya es lo suficientemente estable como para usarse en entornos de producción, y la versión 1.0 fue lanzada el 2 de enero de 2007.
• La única documentación es la especificación oficial.

La Web 3.0, ¿futura realidad o ficción?

La Web 3.0 ha entrado ya en el debate sobre el futuro de internet como la próxima etapa del sector. Aunque algunos expertos advierten que su antecesora, la Web 2.0, todavía no se ha consolidado.

En plena expansión de la Web 2.0,la actual corriente de negocios en internet basada en la aportación de contenidos por los usuarios y la generación de ofertas híbridas a partir de combinar datos de diferentes web, un nuevo fenómeno ha irrumpido en el sector: la Web 3.0. Un término que divide a los expertos entre quienes la sitúan como la próxima etapa del negocio y quienes creen que es sólo un nombre usado por los medios de comunicación, cuyo origen parecen disputarse The New York Times y Gartner.Pero, la Web 3.0 no acaba de tener un significado claro, si bien ya se define como red semántica en la medida que los resultados de las búsquedas aportan significado. Para algunos teóricos es el triunfo del mundo virtual y de la inteligencia de las máquinas. Bajo estas nuevas tecnologías, se produciría una reordenación de todas las comunidades virtuales de tal manera que el usuario podría tener acceso a la información de todas ellas, que a su vez le llegaría de forma ordenada. ‘El éxito total sería que la máquina dijera al final sí amo’, bromeaba Ricardo Baeza-Yates, director de investigación de Yahoo en Europa, en un seminario esta semana sobre Web 2.0.

José Antonio del Moral, director general de la consultora Alianzo, señala que en la Web 3.0 (término que califica de ‘abstracto’) se produciría una unificación de las comunidades sociales para lograr que el usuario tuviera una sola identidad en internet. Otros expertos afirman que la Web 3.0 traería la revolución final del móvil como medio fundamental de acceso a internet por delante del ordenador personal.

En cualquier caso, la Web 3.0 no está consolidada, e incluso recibe críticas. Stewart Butterfield, fundador de Flickr, cree que es sólo una forma de hablar de algo que no se sabe que es: ‘Podríamos hablar de 4.0, 5.0, 6.0… pero no tendría sentido’.

Este debate teórico se produce en un momento de generalización de su antecesora, la Web 2.0, de la que cada día se siguen planteando dudas sobre su rentabilidad. La mayor parte de los expertos apuesta por la publicidad como principal fuente de ingresos de las redes sociales y los blogs, que convertirían el número de visitas como reclamo para atraer a los anunciantes.

Este acercamiento a la publicidad les puede convertir en rivales de los medios de comunicación. Y éstos quieren hacer valer el poder de sus marcas como defensa. Parece que lo logran. Un informe de la Newspaper Association of America señala que los periódicos de EE UU aumentaron sus ingresos publicitarios originados por sus webs un 23% en el tercer trimestre (638 millones de dólares). Claro que, los periódicos quieren apoyarse en firmas de internet para ganar anuncios, y los ejemplos más claros son las alianzas firmadas por Google y Yahoo con grupos de diarios en EE UU.

En este contexto, muchas firmas de la Web 2.0 están en plena búsqueda de financiación. ‘No es fácil porque el modelo de negocio no está claro’, señalan fuentes del sector, quienes también tienen dudas sobre cual podrá ser la rentabilidad final que grandes firmas online como Google y News Corp. podrán extraer de las millonarias compras de Youtube y MySpace, respectivamente.

Quizá aún sea pronto, pero en medios financieros ya se ha aludido a la existencia de una burbuja, eso sí, menor a la del año 2000. Desde luego, todavía hay voluntad por acudir a la Web 2.0. Por ejemplo, el Gobierno de Taiwán aprobó esta semana un plan de subvenciones para empresas de internet por un importe de nueve millones de euros. Y no será el último. Lo que sí ha logrado introducir la Web 2.0 son revolucionarias formas de trabajo. Por un lado, el imparable crecimiento de blogs. Por otro, la llegada de los Mashups, herramientas que permiten reunir en una misma página los contenidos de distintas webs, o el crowdsourcing, técnica empresarial acuñada por el gurú Tim O’Reilly, por la que las compañías recurren a los usuarios para que realicen ciertas tareas. Sin duda, una revolución.

Crowdsourcing

Navegando encontre una nueva palabra,con un gran significado para los amantes de la Web.

Crowdsourcing es un término acuñado por el escritor Jeff Howe y el editor Mark Robinson de la revista tecnológica Wired magazine.

Así como en el outsourcing los trabajos son enviados a empresas externas para abaratar costos en mercados más baratos como India o China, lo que el crowdsourcing hace es proponer problemas y recompensas a quien o quienes solucionen el problema propuesto. Crowd es el término en inglés de multitud y sourcing refiere a la obtención de materia prima ya que source es el término en inglés de fuente, en este caso un proyecto.

Crowdsourcing intenta reemplazar contratos selectivos, entrenamientos y fuerzas de trabajo con la participación masiva de voluntarios y auto-organización. Aunque no es una idea nueva, se está volviendo bastante popular y utilizado por empresas como Boeing, Dupont y Procter & Gamble que buscan solucionar sus problemas de forma masiva a través de InnoCentive por ejemplo.

Wikipedia es el más conocido proyecto crowdsourcing de código abierto, pero hay muchos otros tipos de trabajo crowdsource:

PATRONES GRASP (Patrones de Software para la asignación General de Responsabilidad).Parte II

En la tecnología de objetos un Patrón es una descripción de un problema y la solución, a la que se le da un nombre, y que se puede aplicar a nuevos contextos.

Los patrones GRASP describen los principios fundamentales de diseño de objetos para la asignación de responsabilidades. Constituyen un apoyo para la enseñanza que ayuda a entender el diseño de objeto esencial y aplica el razonamiento para el diseño de una forma sistemática, racional y explicable.

En cuanto a las responsabilidades UML define una responsabilidad como “un contrato u obligación de un clasificador”.

Las responsabilidades están relacionadas con las obligaciones de un objeto en cuanto a su comportamiento.

Básicamente, estas responsabilidades son de los siguientes dos tipos:

Conocer:

* Conocer los datos privados encapsulados.
* Conocer los objetos relacionados.
* Conocer las cosas que puede derivar o calcular.

Hacer:

* Hacer algo él mismo, como crear un objeto o hacer un cálculo.
* Iniciar una acción en otros objetos.
* Controlar y coordinar actividades en otros objetos.

GRASP Se pueden destacar 5 patrones Principales que son:

Experto.
Creador.
Alta cohesión.
Bajo acoplamiento.
Controlador.

Y 4 patrones GRASP adicionales que son:

Fabricación Pura.
Polimorfismo.
Indirección.
No hables con extraños.

Nombre del patrón	Problema	Solución
Expert – Experto	¿Cuál es un principio general para asignar responsabilidades a los objetos?	Asignar una responsabilidad al experto en información – la clase que tiene la información necesaria para la realización de la asignación.
Creator – Creador	¿Quién debería ser el responsable de la creación de una nueva instancia de alguna clase?	Asignar a la clase B la responsabilidad de crear una instancia de clase A si se cumple uno o más de los casos siguientes: B agrega objetos de A B contiene objetos de A B registra instancias de objetos de A B utiliza más estrechamente objetos de A. B tiene datos de inicialización que se pasarán a un objeto de A cuando sea creado (por tanto, B es un Experto con respecto ala creación de A). B es un creador de los objetos A.
Low Coupling – Bajo Acoplamiento	¿Cómo soportar bajas dependencias, bajo impacto del cambio e incremento de la reutilización?	Asignar una responsabilidad de manera que el acoplamiento permanezca bajo.
High Cohesion – Alta cohesión	¿Cómo mantener la complejidad manejable?	Asignar una responsabilidad de manera que la cohesión permanezca alta.
Controller – Controlador	¿Quién debería ser el responsable de gestionar un evento de entrada al sistema?	Asignar una responsabilidad de recibir o manejar un mensaje de evento del sistema a una clase que representa una de las opciones siguientes: Representa el sistema global, dispositivo o subsistema. Representa un caso de uso en el que tiene lugar el evento del sistema a menudo denominado <nombre del caso de uso> Manejador, <nombre del caso de uso> coordinador, <nombre del caso de uso> Sesión. •Utilice la misma clase controlador para todos los eventos del sistema en el mismo escenario de caso de uso. •Informalmente, una sesión es una instancia de una conversación con un actor. Las sesiones pueden tener cualquier duración, pero se organizan a menudo en función de casos de uso (sesiones de cas

¿Que paso con el SqlConnection, el OleDBConnection y los XConnection, XAdapter en VS2005?

¿Quién no ha usado el SqlConnection, SqlAdapter, SqlDataReader?. ¿quién, no los uso desde el caja de herramientas?. Pero, ¿dónde estas estos controles en VS2005?
En principio iba a responder solo con los pasos, por unos pendientes que tengo, pero no puedo evitarlo voy hacer un how to, no tan detallado, pero con algunos pantallazos.

En este caso usaré Visual C# Express y SQL Express, sobre Windows Vista RC2. ¿por qué?, por que esas versiones estan al alcance de todos por ser gratuitas . Y obviamente son aplicables a las versiones superiores.

Ahora que estuve instalando SQL Express, me percate de una opción interesante, no se, si no la vi antes (en las versiones beta), o no tenía, y es la posibilidad de hacer una instalación avanzada.

Con una instalación avanzada, podemos configurar el nombre de instancia, en mi caso es .\miSQLExpress, pero si no tienen planeado instalar una versión superior de SQL, pueden usar la instancia por defecto, y para que, al conectarse solo pongan el nombre de equipo, (local), localhost, o sólo “.”.

Ah por cierto trabajaré con Adventure Works, la cuál se puede descargar desde esta página: SQL Server 2005 Samples and Sample Databases (July 2006).

Vamos a los pasos, supongo que ya tienen instalado AdventureWorks, Managment Studio Express, SQL Express, y C# Express:

1. Creo mi aplicación Windows con C#.
2. Agrego un nuevo conjunto de datos: dsAdventure.xsd.
3. Ahora agrego una nueva coneción a mi base de datos, puedo escoger entre Access vía OleDB o SQL:

4.- En el caso de los que han cambiado el nombre de la instacia por defecto (SQLExpress), el mio por ejemplo, al agregar la conexión hay que probarla, si obtenes error, hay que hacer clic en propiedades avanzadas, y cambiar el nombre de la instancia (por defecto viene con SQL Express), indepientemente que instancia le hayas puesto de nombre a tu servidor de base de datos. Ah por cierto se usará el modelo attach DB, en el cuál para la conexión no es necesario el nombre del server y la db, sino el archivo mdf, que esta dentro de la carpeta Data de MSSQL.

5.- Ahora arrastro una nueva tabla desde la conexión agregada, nos pedira agregar una conexión local dentro del proyecto, hacemos clic en SI o YES, depediendo del idioma de la instalación del Csharp Express (como se han habrán podido dar cuenta, tengo al versión en espaniol):

6.- Como pueden apreciar ahora el objeto a parte del dataset es el TableAdapter, que yo lo veo como un DataAdapter tipificado:
7.- Lo que es interesante es que que las consultas generadas de Insert, Update, Delete, y Select, la podemos cambiar por Store Procedures, además podemos personzalizar más el TableAdapter, agregando métodos de búsqueda, etc.
8.- Ahora a lo nuestro agregar la data, para esto abrimos el formulario, y mostramos los orígenes de datos, si no esta, lo hacemos desde el menú Data, Show DataSource, y en espaniol, Datos, Mostrar Orígenes de Datos:

9.- Ahora cambiamos la vista a Detalles, y arrastramos ProductCategory al formulario:
10.- Antes de que digan wow…., ejecuten, no lo piensen tanto, no miren el código, solo ejecuten..
11.- Ahora si, digan wow… :

Ahora si, espero que todo haya quedado claro?, no prueben el update .

A los que probaron el update habrán notado que no hace update, en este punto deberían comerzar a silvar, y a pedir su plata. Pero tranquiloss…., todo esta bajo control, no hubiera publicado el post, si previamiente no hubiera soluciado esto, aunque tome varias horas, aunque no coma, aunque no…; según la regla Nº13 del manual buen programador, si vas hacer algo, hazlo bien, sino, mejor no lo hagas . Y nada, vamos, primero les explico que ha pasado, y después les explico como solucionarlo.

El problema se presenta, por el quicktranslate que hice de este post, que al momento de decir SI en el mensaje de arriba que les dije que pulsarán SI, lo que hace es adjuntar el archivo mdf a nuestro proyecto. ¿pero, eso es lo que debía hacer?. Aja, pero el problema es que la conexión agregada se queda referenciada a la ruta del archivo original (la carpeta Data de MSSQL). Y resumidamente ese es el problema.

La solución, “cuanto más tiempo te demore un problema, mayor es el éxtasis alcanzado al solucionarlo“:

1. Tenemos que cambiar la cadena de conexión dentro del archivo de configuración de la aplicación, app.config, y en el datatable ProductCategory, esto lo hacemos desde el diseñor del dataSet. Lo reemplzamos por la actual ruta del archivo *.mdf adjuntado dentro de nuestra aplicación.
2. Ejecutar nuevamente.
3. Modificar un registro, ej., cambiar el nombre de la categoría a bicicleta.
4. Cerrar.
5. Volver a ejecutar.
6. Y por último decir wow…:

Con una versión de SQL, NO Express, no deberíamos tener este problema.

Cabe resaltar que esta, es una demo básica, nosotros podemos usar StoreProcedures, podemos extender la funcionalidad del TableAdapter dentro de una capa de Negocio, usando WebServices, y todo el tipo de cosas arquitectónicas que se les ocurran.

De más esta decir sobre todo lo que ha generado, los controles, la presentación, validaciones del tipo de dato, asignación del autonumerico, entre otras… es, siendo cualitativos, espectacular; y cuantitativos, es productivo.

Programadores…

Puntos a tener en cuenta cuando uses AJAX

Si estas pensando en usar masivamente AJAX para tu proyecto,te recomiendo la lectura de este articulo.
Navegando encontre este artículo que me pareció muy bueno,ahora lo publico en mi blog para ustedes tambien lo lean,y aunque esta un poco largo es muy bueno su contenido.

Errores en el uso de AJAX en una aplicación web Usar AJAX por ser “AJAX”
Sabemos que AJAX es una novedad y que a los desarrolladores nos encanta jugar con lo último, pero ante todo AJAX es una herramienta, no un juguete. Muchas de las implementaciones que encontramos usando AJAX no son realmente necesarias para mejorar la usabilidad o la experiencia del usuario, sino unicamente experimentos para comprobar qué puede hacer AJAX o empeños de ponerlo donde realmente no se necesita.

Hacer inservible el botón de volver atrás
El botón de retroceder (del navegador) es muy util en la navegación de una interfaz web. Desafortunadamente, no se lleva muy bien con las aplicaciones Javascript. Mantener la funcionalidad asociada a este botón es una de las razones para no realizar una aplicación completemante basada en Javascript.

Sin embargo, se debe tener en cuenta que un buen diseño web debe poner al alcance del usuario todo lo que necesita para navegar correctamente por el sitio y nunca depender de los botones o controles existentes en el navegador.

No mostrar inmediatamente señales del progreso de una operación
Si algo en lo que hacemos click lanza una acción mediante AJAX, la aplicación debe dar pistas visuales de que algo está ocurriendo (ya que el navegador no lo hará ).
Un ejemplo de esto, es la etiqueta roja que aparece en la esquina superior derecha en Gmail mostrando el texto “loading”, cada vez que la interacción con el servidor se hace mediante AJAX.

No pensar en la gente desconectada (offline)
A medida que los limites de las aplicaciones web se van superando, se va haciendo más patente la posibilidad de mover todas las aplicaciones a la web. La disponibilidad es mejor, el modelo de acceso desde cualquier parte del mundo es genial, el mantenimiento y la configuración realmente faciles, la curva de aprendizaje de la interfaz de usuario es pequeña.
Sin embargo, la gente que dispone de malas o lentas conexiones a la red o que simplemente no desean estar conectados tambien deben tener su sitio. Simplemente porque la tecnología avance no significa que las personas esten preparadas y deseando ir a su mismo ritmo.
El diseño de aplicaciones web debe considerar al menos el acceso offline (desconectado). Con GMail es POP (con lo que puedes descargartelo en tu cliente de correo de escritorio y leerlo offline), Backpackit tiene integracion con SMS, por poner algunos ejemplos. En el mundo empresarial, sus servicios web.

No me hagas esperar
Las tabs de Firefox, me permiten administrar varias “esperas” a sitios web y normalmente solo tengo que esperar para la navegación en una página.
Las aplicaciones AJAX combinadas con una conexion/ancho de banda/latencia pobre , pueden presentar un enorme problema de tiempos de espera al movernos por su interfaz, ya que cada vez que hago algo tengo que esperar la respuesta del servidor. Que Dios me ayude si tiene que llegar hasta el disco del servidor antes de que yo pueda continuar…

Enviar de forma insegura información sensible
La seguridad en las aplicaciones AJAX está sujeta a las mismas reglas que la de cualquier otra aplicación web, excepto que al poder comunicarse de forma asíncrona con el servidor, pueden tender a estar hechas con código frágil y poco seguro. Es muy importante que todo el tráfico que envía/recibe nuestra aplicación sea comprobado para que la seguridad no se vea comprometida.

Asumir que el desarrollo AJAX sólo es para una plataforma
El desarrollo AJAX es multiplataforma. De hecho funciona con el motor javascript del IE, con el motor de Mozilla, con el motor de Safari y con otros que pueden convertirse en fuertes opciones.
No es suficiente programar siguiendo los estándares Javascript (sobre todo sabiendo que existe IE), se debe probar la aplicación en el máximo número de plataformas posible.
En el desarrollo con Javascript nos encontramos con un serio problema: la implementación defectuosa del motor de JS de Internet Explorer (aunque existen herramientas para ayudar). Pero cualquier desarrollador ya estará acostumbrado a lidiar con este tipo de problemas (tambien con CSS por ejemplo)

Olvidar que la aplicación puede estar siendo usada por varias personas a la vez
Cuando se desarrolla una aplicación web es necesario tener en cuenta que va estar siendo usada por más de una persona a la vez. Si la información que se muestra se almacena dinámicamente en una base de datos, asegurate que esto no te crea “problemas”.

Demasiado código, hace que el navegador sea lento
AJAX trae una nueva forma de hacer aplicaciones javascript mucho más interesantes, pero desafortunadamente esto a veces tambien significa “más código funcionando”.
Más código funcionando significa más trabajo para el navegador, lo que provoca que en muchas webs con uso intensivo de Javascript, especialmente las mal programadas, necesites la última CPU del mercado para poder navegar por ella.
De hecho, el problema de uso de CPU realmente ha sido un limite para la funcionalidad de Javascript en el pasado y el hecho de tener CPUs más potentes en la actualidad, no significa que el problema haya desaparecido.

No tener un plan para aquellos que no usen o habiliten Javascript
Según las estadísticas de de uso de navegadores de W3 schools el 11% de los visitantes a una web, no disponen de Javascript. Así que si tu aplicación web depende por completo de esta tecnología, parece ser que potencialmente has perdido a una décima parte de tu audiencia.

Hacer parpadear o cambiar partes de la página de forma inesperada
La A de inicio de AJAX viene de la palabra “Asynchronous” (asíncrono). El problema con los mensajes asíncronos es que pueden ser confusos cuando se muestran de forma inesperada.
Los cambios asíncronos en la página deben ocurrir en zonas bien definidas y deben usarse con buen criterio. Los efectos y parpadeos deben estar limitados a esas áreas y deben tener un sentido.
Desde luego lo que no tiene mucho sentido es que volvamos a los tiempos de la etiqueta “blink” de html y a las “webs parpadeantes”.

No usar enlaces que pueda pasar a un amigo o añadir a favoritos
Otra característica fantástica de los sitios web es que puedo pasar su URL a otra gente para que puedan ver exactamente el mismo contenido que yo. Tambien puedo guardar en mis favoritos la URL para regresar posteriormente.
Javascript, y por lo tanto AJAX, trae grandes problemas a este modelo de uso. Al generar dinámicamente la página con Javascript en vez de desde el servidor, la url no necesariamente apunta al mismo contenido, y no puede ser usada para lo que estamos acostumbrados.
Esta es una característica que no se debe perder y de hecho muchas aplicaciones AJAX incluyen “permalinks” (urls especialmente generadas) que solucionan este problema.
Algunos toolkits (como por ejemplo dojo), incluyen facilidades para conseguir esto.

Realizando operaciones por lotes de forma asíncrona
AJAX permite que la edición de campos de un formulario se realice de forma inmediata, pero esto puede acarrear muchos problemas.
Por ejemplo, desmarco una lista de “check boxes”, cada una de las cuales es enviada de forma asíncrona al servidor. Pierdo mi habilidad para saber el estado en el que se encuentran los cambios en las “checkbox” y el aluvión de indicaciones de cambio de cada checkbox puede ser molesto y desconcertante.

Mover la posición vertical en la página y hacerme perder la situación donde me encontraba
Otro problema de insertar texto en una pagina de forma dinámica es que puede afectar al scroll. Me encuentro felizmente leyendo un artículo o moviendome por una enorme lista, y una petición Javascript asíncrona decide de repente cortar un párrafo justo encima de lo que estoy leyendo, haciendome perder la posición. Obviamente esto es algo molesto y me hace perder el tiempo intentando volver a encontrar la posición donde estaba.
Pero evidemente esta es una forma bastante estúpida de programar una página, tenga o no AJAX.

Inventar nuevos “estándares” de interacción con la interfaz
Un gran error que es fácil cometer con AJAX es: “haz click en esta cosa nada obvia para conseguir nada obvio como resultado”. Los usarios de una aplicación pueden darse cuenta de que cuando haces click y mantienes pulsado sobre este div, lo puedes arrastrar y dejar permanentemente en esta otra posición, pero eso no es algo que esté por defecto en la experiencia común de los usuarios. De esta forma se incrementa el tiempo y la dificultad para aprender a usar una aplicación, lo cual es un punto muy negativo para la misma.

Blockear el acceso a la información a nuestras amigas las arañas
Las aplicaciones AJAX que cargan una gran cantidad de texto sin recargar la página pueden ser un gran problema para los motores de búsqueda.
Volvemos al mismo problema que con la URL y el botón atrás. Si los usuarios pueden llegar a través de los motores de búsqueda el texto de la aplicación debe estar de alguna manera disponible para que lo lean las arañas (spiders) de los buscadores.

Conjuntos de caracteres
Uno de los grandes problemas al usar AJAX es la carencia de este de soporte para juegos de caracteres. Siempre deberías establecer el juego de caracteres a usar en el servidor así como codificar todos los datos usados con Javascript. Usa ISO-8859-1 si tu aplicación sólo usa inglés o español, o UTF-8 si usas caracteres especiales como æ, ø y å.
Nota: Hoy en día es buena idea usar siempre el juego de caracteres utf-8 ya que soporta un gran variedad de idiomas.

Cambio del estado con enlaces (peticiones GET)
La gran mayoría de aplicaciones AJAX tienden a usar simplemente el método GET cuando realizan peticiones con XMLHTTPRequest.
Sin embargo, los estándares W3C dicen que el método GET debe ser usado únicamente para obtener datos y el POST únicamente para enviar datos.
Aunque esto no representa una diferencia notable para el usuario final, estos estándares deben seguir siendo usados para evitar problemas con los robots o programas como por ejemplo el Google Web Accelerator.

No trasnferir los cambios locales a otras partes de la página
Al darte AJAX/Javascript tal control sobre el contenido de la página, es fácil enfocarse demasiado en una pequeña zona del mismo y perder la imagen de la página global.
Un ejemplo de esto, es el título de Backpackit. Si cambias el título de una página de Backpackit, inmediatamente se reemplaz el título, incluso en la zona de la derecha, pero no cambian el contenido de la etiqueta title en el head de la página.
Con AJAX debes tener siempre en mente el modelo completo de la página aunque los cambios sean pequeñs y localizados.

Aviso de errores
En una aplicación tradicional de lado servidor, dispones de visibilidad para cada excepción, puedes guardar registro de cada evento o estadística o incluso guardar y ver (si lo deseas) el HTML que el navegador está mostrando.
Con las aplicaciones en el lado cliente, puede pasar que no tengas ni idea de que algo ha ido mal si desconoces cómo programar correctamente y guardar esas excepciones (errores) que se producen remotamente (en el navegador del cliente) en tu servidor.

Retorno de la inversión
A veces AJAX puede incrementar de forma espectacular la usabilidad de una aplicación (un buen ejemplo puede ser la forma de votar usando estrellas en Netflix), pero lo más común es ver ejemplos de caras aplicaciones en lado cliente (rich-client applications) que realmente no mejoran lo que seria su correspondiente versión en HTML simple.

Imitar el comportamiento de navegación del navegador de forma errónea
Un ejemplo de esto es el sistema de paginación que ofrece en su pagina inicial Blinklist.
Cuando haces click, ves que se carga otra página de link, AJAX reemplaza el número de página. Pero si estás acostumbrado a la experienca de uso del navegador, probablemente esperes aparecer en la parte superior de la página cuando pulses el botón de siguiente, algo que la aplicación Javascript no hace.
De hecho, BlinkList se anticipa a esto e intenta contraactuar manipulando tu scroll para llevarte a la parte de arriba de la página. Pero es muy lento, por lo que si intentas bajar, no te deja.
Pero una vez más, esta es una forma muy estúpida de programar una página tenga o no AJAX.

Otra herramienta más
Parece que todo el mundo ha olvidado que AJAX es simplemente otra herramienta más entre todas las que tenemos para el desarrollo web. Puedes usarlo o no y puedes usarlo mal o bien, como cualquier otra.
La regla 80/20 siempre es valida para las aplicaciones (si eres capaz de cubrir el 80% de lo que tus usuarios quieren y necesitan entonces tienes una aplicación viable) y si pierdes un 11% de tu audiencia porque no activan el soporte javascript de su navegador, entonces deberás preguntarte si el cambiar tu aplicacion te va a permitir capturar ese 11% o quedarte con el 89% que lo usa actualmente y cambiar a algo distinto.
Las aplicaciones web deben beneficiarse de todos los trucos que las permitan funcionar de forma más rápida y eficiente. Si usar javascript en una parte, AJAX en otra y ASP por detras ayuda a conseguirlo, entonces hagamoslo.
Espero sus comentarios sobre el tema.Saludos!!

Críticas a la Orientación de Objetos

A continuación se presentan algunas consideraciones respecto a cómo el MOO es presentado mayoritariamente en la literatura. Muchos autores afirman incluso la conveniencia de usar orientación a objetos en el modelado conceptual. Estas afirmaciones serán analizadas críticamente en las siguientes secciones.

1. Naturalidad.- La esencia del paradigma de la orientación a objetos y más específicamente, del MOO, es la visión de la realidad compuesta por objetos. Frecuentemente se afirma que esta visión es “más natural” que una visión funcional o comportamental. Por ejemplo, en el ámbito de la ingeniería de negocios, algunos autores, sugieren utilizar el modelo de objetos para diseñar negocios dada esta aparente naturalidad que facilitaría la comunicación
2. Encapsulamiento .-
   
   En Informática existe una fuerte tendencia a forzar la realidad modelada a una conceptualización originada de la construcción de software. Por ejemplo, el MOO se sustenta en el encapsulamiento que propone separar los aspectos externos de los internos. Los aspectos externos son cono-cidos por otros objetos, en cambio los aspectos internos son de conocimiento exclusivo del objeto propietario. De esta forma, los objetos son autocontenidos y no comparten ningún tipo de dato que no sea solicitado en las colaboraciones con otros objetos. La cuestión es la siguiente: ¿tiene sentido encapsular en el nivel de abstracción requerido en elmodelado conceptual? Dado que la mayor ven-taja del encapsulamiento se revela en la fase de implementación, ¿qué beneficios se podrían esperar
   del encapsulamiento en el modelado conceptual? ¿encapsular en el modelado conceptual no representaría introducir prematuramente rasgos de implementación?.
3. Continuidad Estructural.-

   La continuidad estructural, en las sucesivas fases del ciclo de vida orientado a objetos, es comúnmente indicada como una ventaja. El gap semántico1se vería dismi-nuido: por ejemplo, los objetos identificados en el dominio del problema serían mapeados directa-mente en los objetos especificados en el dominio de la solución durante el diseño. Lo mismo sucede-ría con estos objetos al ser mapeados en los objetos codificados de la implementación. Se puede afirmar entonces, que el MOO sería ventajoso si tanto el diseño como la implementación fueran también conducidos bajo este mismo paradigma. Sin embargo, el beneficio de la continuidad estructural no debería tener el costo de colocar el MOO más cerca del diseño orientado a objetos. El modelado conceptual, en la perspectiva de la ingeniería de requerimientos, debe ser orientado al problema (realidad) y no a la solución concreta (implementación orientada a objetos).

4. Transición al Diseño.-

   La confusión existente entre lo que es el análisis y el diseño orientados a objetos, es decir, la poca claridad en los límites entre estas dos fases es indicada en la literatura. El principio de la ingeniería de software de que el análisis debe ser declarativo con relación al diseño, es decir, que describe qué debe hacer el sis-tema en contraste con el diseño que establece cómo ha de hacerse, no ocurre en la orientación a objetos. En la práctica, los modelos orientados a objetos del análisis son sólo menos detallados que los del diseño o sólo constituyen el “centro” del modelo de diseño; así la pretensa declaratividad no es alcanzada. De esta forma, el MOO puede entenderse como un diseño preliminar, porque una vez que los requerimientos son entendidos, éstos se organizan en un modelo que sirve como estructura interna del sistema a ser diseñado.La orientación a objetos debe ser considerada entonces como una decisión de diseño e implementación y no como una decisión de modelado conceptual o de análisis de requerimientos.Por lo anterior, los términos análisis y orientación a objetos en realidad se contraponen. La noción de análisis como descomposición y examen crítico con el fin de aumentar la comprensión no alcancalza con las ideas de síntesis (encapsulamiento de atributos y operaciones en los objetos) y de alter-nativa de diseño e implementación de la orientación a objetos.Una forma de resolver este problema es creando mecanismos que permitan postergar el en-capsulamiento tanto cuanto sea posible. En otras palabras, modelar el dominio del problema fuera del paradigma de la orientación a objetos, con suficiente poder de expresión y flexibilidad para poder derivar modelos orientados a objetos con relativa facilidad, si la implementación desea ser realizada bajo este paradigma. De esta forma, el modelado concluye antes de introducirse el encapsulamiento, punto en el cual comienza el diseño orientado a objetos3.En este sentido, el modelo de casos de uso (use case), propuesto por Jacobson, puede utilizarse previo a la construcción de modelos de objeto. Un modelo de casos de uso representa una manera específica de usar el sistema: a través de la ejecución de alguna parte de su funcionalidad. Cada caso de uso describe un escenario completo de eventos iniciados por un actor (o papel de usuario) y especifica la interacción que ocurre entre el actor y el sistema. Corresponde así a una visión externa del sistema, que no se construye bajo el paradigma de la orientación a objetos.

Conclusiones 

Bajo los argumentos aquí presentados, el MOO debe ser considerado como una alternativa más para hacer frente al análisis de sistemas, con una fuerte restricción impuesta a priori de implementar orientado a objetos. Con el fin de obviar esta restricción se sugiere modelar usando técnicas que posterguen el encapsulamiento, es decir, que permitan modelar fuera del paradigma de la orientación a objetos y que, eventualmente y si así se desea, sea posible realizar un mapeamiento a un modelo de objetos, momento en el cual se iniciaría el diseño orientado a objetos. Esta evolución del pensamiento sobre el MOO, se ve reflejada en la reciente propuesta de utilizar el modelo de casos de uso como conductor del proceso de desarrollo de software orientado a objetos, es decir, un modelo no orientado a objetos sirve como guía o marco para el resto de los modelos orientados a objetos.En el caso de optar por un análisis orientado a objetos, se debe estar consciente de que en realidad se está construyendo un modelo de diseño inicial o preliminar del sistema. Los términos para el análisis orientado a objetos se contraponen a los del diseño orientado a objetos, se reconocienda en ambos el carácter de diseño.