A estas alturas hay suficiente entusiasmo alrededor de la Beta de Windows 7, que aun blogs criticos con Microsoft y fans de Apple y Google como ALT1040 estan hablando positivamente de dicha version, la cual tiene sus inconvenientes como el excesivo numero de versiones, pero nada…. es definitivamente refrescante el ver cuan bien va quedando el nuevo producto el cual entre otras cosas introduce el modelo “cinta” a aplicaciones como Wordpad y Paint, asi como 3 nuevos juegos.

El caso es que al final las personas y sobre todo las empresas estan decidiendo resistir y aguantar con su Windows XP, no instalar Windows Vista y esperar al lanzamiento de Windows 7, que con todo lo que tiene promete al menos dos cosas fundamentales: una mejor experiencia de usuario y un mejor rendimiento que Windows Vista.

En ese contexto es algo sorprendente lo que dice Gavriella Schuster Senior Director de Microsoft en The Windows Blog, en concreto recomienda que las empresas deben iniciar o continuar con sus planes de despliegue de Windows Vista, pues dicha accion facilitara la llegada de Windows 7.

Si, definitivamente soprendente, pues al margen del costo de las licencias, el esfuerzo tecnico de hacer dos despliegues uno tras otro seria excesivo de gestionar, en ese sentido dicho consejo no es precisamente valido.

Se menciona como factor para proceder de esa manera, la verificacion de compatibilidad de aplicaciones, y si, es cierto que las empresas deben de ser conscientes de los cambios que Vista introdujo (y que seran mantenidos en Windows 7) como la problematica virtualizacion que tantos dolores de cabeza puede dar al instalar un programa,  pero claro… el ser consciente de esa realidad y de los ajustes que hay que tener para desarrollar aplicaciones compatibles con Vista y 7, no implica tener que hacer dos despliegues consecutivos, antes bien “solo” implica tener maquinas (reales o virtuales) donde ir testando los desarrollos que se vayan haciendo.

En todo caso creo que las empresas seran lo suficientemente prudentes (mas en un entorno de crisis) y no haran caso de esta recomendacion.

Y yo.. de momento dudo si instalar Windows Server 2008 o la Beta de Windows 7.

Es ironico que cuando se pide a los usuarios abandonar y actualizar su Internet Explorer 6, ya que como comenta uno de los responsables de la remodelacion de Libertad Digital dicho browser impide el visionado correcto de los sites modernos, aun debamos de toparnos con sites programados con tecnologias antiguas y no compatibles.

Todo empezo hace unos dias, tenia que efectuar una compra por Internet, y como parte final del pago, debia validar mi tarjeta de credito mediante una pasarela conectada con mi banco, todo bien, pero al llegar a la pantalla de validacion el boton para hacer el paso siguiente no funcionaba, malo malo, se veia el boton pero ignoraba mis clics, entonces procedi a ver los mensajes que tenia la consola del Firefox, y ahi estaba, el sitio hacia una llamada en JavaScript al temido document.all, como se puede ver:

Para quien no lo recuerda, document.all fue una especie de "llave maestra" que se introdujo en Internet Explorer 3, a fin de "facilitar" de manera directa un acceso directo a los diversos elementos DOM que conforman una pagina HTML (especialmente los elementos de un formulario), esta caracteristica junto con otras como los behaviours no fueron implementadas por los demas browsers, lo que me hizo en algunos proyectos retocar bastante JavaScript a fin de evitar que la pagina solo fuera usable en las versiones de Internet Explorer.

Es que soluciones hay, y en su momento la solucion era usar un acceso totalmente cualificado como "form1.combo1....", pero la solucion standard soportada tanto por Opera, Firefox e Internet Explorer es getElementById, por lo que sorprende que algo tan conocido no sea usado en un site de tanta importancia como una pasarela de pago electronico, esta claro que al final tuve que deshacer todo lo avanzado y utilizar una sesion de IE 8 para poder hacer la operacion, con la consiguiente perdida de mi tiempo como usuario, todo por una mala decision de los programadores de 4B que optaron por usar algo no standard.

Y claro, no habra quien me diga que si me quejo por esto y no reclamo a los fabricantes como en el caso de ShowModalWindow por no incluir dicha funcionalidad, en vez de quejarme con los progamadores del sitio, muy simple: en el caso de ShowModalWindow el problema era (ya no, pues Firefox 3 ya soporta ShowModalWindow :) )que habia una funcionalidad de IExplorer sin ningun mecanismo alterno de implementacion en los otros browsers, mientras que en el caso de document.all se trata del hecho de usar una manera no estandar de acceder a un recurso, ya existiendo mecanismos comunes y compatibles para lograr el resultado.

Espero que cada vez sean menos los desarrolladores web que hace uso del infame document.all.

A pesar de las opiniones en contra, sigo creyendo que es malisima idea usar MS Word como editor grafico, si algunos me diran que es lo mas simple, que no hay que hacerse complicaciones y todo eso, pero experiencias recientes no me han hecho sino insistir en este tema.

Como dije, una de las razones por las que se realizan capturas de pantalla es para documentar errores que se encuentran en las aplicaciones, pues bien esa tarea de documentacion y reporte es facilitada enormemente mediante el uso de Team Foundation Server, herramienta sobre la cual nuestro amigo El Bruno se explaya frecuentemente para alivio nuestro, al usar dicha herramienta nos es posible describir textualmente la situacion que nos afecta como usuarios y de ser necesario, incluir un archivo adjunto para complementar dicha descripcion.

El problema se presenta cuando, como testeadores, revisamos el bug encontrado y vemos que se ha adjuntado un documento de Office, generalmente Word, el cual presenta un pequeño inconveniente: la apertura de archivos pasa por Internet Explorer (como me explico el Bruno, el abrir un archivo desde Team Explorer invulcra el invocar Web Services) por lo cual se hace necesario verificaciones de seguridad, y siendo que potencialmente un documento de Office podria contener contenido peligroso, las aplicaciones no hacen sino que cumplir su rol preguntando hasta 3 veces el usuario y password que tengamos en el TFS, todo comprensible desde el punto de vista tecnico (a pesar de lo irritante que pueda ser el retipear a cada rato) hasta que nos percatamos de dos pequeños detalles:

• Los archivos JPG al no ser contenido potencialmente peligroso se abren directamente en el Internet Explorer.
  
• La mayoria de los archivos de Office adjuntos solo incluian una captura de pantalla y ningun contenido adicional.
  

Queda claro que si no se va a usar los documentos de Office para algo de veras importante, como una especificacion funcional por ejemplo, no tiene sentido seguir usandolo para captura de pantallas pudiendo usarse el ya comentado Irfanview o el clasico Paint, el cual ha sido muy remodelado en Windows 7.

Hasta hace menos de dos horas, el site de la Casa Blanca correspondia a la administracion saliente, parece ser que con la juramentacion se puso online un nuevo servidor con contenido totalmente nuevo, tan asi que los enlaces que hasta hace un momento funcionaban como http://www.whitehouse.gov/mrscheney/ ya no funcionan, asi como el historico de noticias de la administracion Bush.

Como no podria ser de otra manera, el nuevo site empieza con un post en su blog.

Asi estaba hace menos de 24 horas:



Y ahora recibimos esto, si queremos entrar a la pagina anterior:


Un detalle curioso comentado por Enrique Dans es que el site de la administracion Obama esta sujeta a una licencia Creative Commons Attribution 3.0, en vez de a copyright como el de la administracion saliente, buen punto a favor de ellos, por mas que Jomra le de a dicha licencia poco valor. Actualizacion: Aunque por lo que aclaran los comentaristas, legalmente todo contenido publicado por el gobierno de USA no esta sujeto a copyright, siendo que la CC se aplica al contenido de terceros utilizado ahi, salvo indicacion en contrario.

Por cierto, el nuevo site esta basado en ASP.NET!!! :)

Habra que seguir en sintonia para ver si el nuevo website representa algo mas que un cambio estetico y de contenido, sino tambien de funcionalidad.

Actualizacion 21-1-2009: Acabo de leer que el archivo robots.txt ha pasado de tener mas de 2400 lineas a tener solo una, lo cual en parte tiene sentido puesto que el site ha sido remodelado por completo y como acabamos de ver muchas URLs simplemente ya no existen, pero ojo: es conveniente que el robots.txt bloquee resultados de busquedas internas, asi como contenido duplicado, por lo que quiero creer que conforme el site vaya alcanzando cierto trafico dicho archivo estara actualizado adecuadamente.

La URL de una Web es algo importante en terminos del trafico que se reciba o se desea recibir, lejos estan los dias en que los sites tenian una estructura del tipo www.miproveedor.com/minegocio o www.miproveedor.com/myrurlcomercial.htm, esta claro como comentamos hace tiempo que el dominio es la puerta en que tus clientes o visitantes llegan hacia ti, por lo que hacer un uso adecuado de el es muy importante, y no caer en los errores cometidos por Bancoval (leer cita anterior).

Este fin de semana amen de la masacre en Palestina, la expectativa por la llegada de Obama, hubo otro acontecimiento informativo, la mudanza del popular blog UterodeMarita.com a Utero.pe, probablemente a fin de dar un sabor mas "local" a su visitado site. Pero dicha mudanza se ha producido carente de cierta planificacion, me explico:

El visitante usual (o suscrito via RSS) se entero de la "mudanza" gracias a una nota de despedida indicando su nuevo site, y el que llegue por enlaces externos vera debajo del banner una nota que dice "¡ALTO! AHORA ESTAMOS EN HTTP://WWW.UTERO.PE".

¿Que problema hay? me diran mis 4cats, el publico esta avisado y nadie se perdera, pues si, pero la verdad es que obliga a actualizar feeds, retocar links, etc etc... y no es para nada transparente como cuando hubo las transiciones de Firstcom a ATT y luego a Telmex, o sobre todo cuando Tim se convirtio en Claro, en este ultimo caso la mayoria de los enlaces siguieron funcionando lo cual facilito la adaptacion de los usuarios a la nueva URL.

¿Que se podria haber hecho en este uterino caso?, muy simple: asegurar que los controladores de dominio de .pe se redigieran a los servidores donde esta alojado uterodemarita.com, de esta manera se mantendria el contenido actual, mas aun: es perfectamente posible (y no muy complicado) configurar los servidores para que cualquier request de tipo uterodemarita.com/paginax.html se redireccione y el visitante reciba utero.pe/paginax.html.

Como se ve, soluciones hay todo es cuestion de pensarlo un poco, lo cual ademas permite ahorrar en terminos de hosting y no pagar dos veces, no?

Procesos por lotes (o batch) por lo general son los que involucran una fuente (generalmente temporal) de datos que tienen que ser procesados y/o integrados en una repositorio de destino. Generalmente se hace periodicamente o cuando se alcanza cierto volumen que justifique el realizar el proceso.

No toca aca discutir las cuestiones tecnicas de dichas tareas, que si se hace con transacciones o no, performance (solo debo comentar que por performance a veces no se trabaja con integridad referencial), si se va contra mainframe o no, sino el ir un poco mas alla de la racionalidad detras de la decision de usarlas, para lo cual me remitire a dos ejemplos que conozco de primera mano.

1) Para el que no lo sabe en España existe una Ley de Proteccion de Datos, que entre otras cosas permite al ciudadano el decirle a una empresa X que no quiere seguir figurando dentro de sus archivos (sobre todo si no eres cliente), en el caso que nos ocupa un usuario habia pedido a la empresa X dicha baja en la base de datos a fin de no seguir recibiendo publicidad, todo ok hasta ese momento, pero resulto que a poco de haber hecho esa solicitud recibio comunicacion publicitaria por parte de X, con lo que el usuario en cuestion denuncio a X por violar la citada Ley, que habia pasado? simple que la informacion sobre las bajas no era procesada automaticamente sino que se guardaba en un repositorio temporal, el cual era volcado periodicamente a la Base de Datos principal a fin de dejar constancia de las bajas (y supongo que tambien las altas) producidas, resultando que la comunicacion esa habia sido hecha en el intervalo entre la solicitud y el volcado respectivo, con el consiguiente perjuicio para X al haber violado la ley (pero no intencionadamente debo decir).

Eventualmente el procedimiento cambio aunque no se si para realizar las bajas en tiempo real o solo para incluir una advertencia al usuario acerca de que la baja no es automatica.

2) Estoy afiliado a Openbank, realizando practicamente todas mis operaciones via Internet o por Telefono, tan asi que en mas de 7 años solo he ido 4 veces a sus oficinas, el caso es que en ciertas ocasiones he necesitado realizar operaciones (via tarjeta o cajero) de monto mayor al limite de proteccion que tiene el banco, llegando a hacerlo por telefono en pleno establecimiento comercial, lo cual era procesado automaticamente, lo cual me parecia una ventaja en ciertas ocasiones; pues bien hace unos meses llame para realizar dicho procedimiento y me dijeron que lo hacian pero que tendria vigencia a partir del dia siguiente, ¿por que? porque habian cambiado sus procedimientos y en lugar de efectuar las ordenes y movimientos en tiempo real ahora se efectuaban en lotes entre las 10pm y la medianoche. Consecuencia directa: que el acceso a la web se vuelve mas lento en esa franja horaria y se pierde un servicio que resultaba muy conveniente para los clientes del banco, pero no solo ese servicio, sino tambien los pagos y transferencias, de hecho este lunes llame a la 10:20pm para ordenar una transferencia a otro banco, diciendome que dicha transferencia se haria efectiva hoy miercoles en la mañana, pero al final al verificar en la web resulta que la "Fecha valor" es .... mañana!!, ahora vete tu a saber si el banco destino lo hara efectivo inmediatamente, al final resulta que los envios de dinero que hago a Peru llegan antes que una transferencia dentro de España.

Son estos casos de uso evidente de procesos por lotes, se justifican sus posibles beneficios frente a los serios inconvenientes causados? lo dudo mucho.

Pero, siendo asi, ¿existen situaciones en la que sea necesario el usar procesos por lotes?, si, pero creo que en el escenario tecnologico actual solo cuando sea estrictamente necesario, osea cuando se trate de consolidar sedes remotas y la conexion no sea tan eficiente y sea necesario esperar a acumular operaciones para luego transmitirlas de manera comprimida (y espero que encriptada), luego se me dira que tambien podria ser necesario cuando el costo de la transaccion sea muy alto, pero antes de optar por ese camino habria que pensar si no es peor degradar la performance en el momento en que deciden ejecutarse de golpe todas esas transacciones, teniendo el añadido de que si tu negocio es online y supuestamente 24x7 uno no puede permitirse ese lujo.

Alguna otra idea para un escenario tolerable para los procesos en lotes? No, no me refiero a procesos de facturacion, nominas/planillas o informes periodicos, sino a movimientos cuyo registro afectan de un modo u otro las operaciones del dia a dia de la organizacion y/o la satisfaccion de los clientes/usuarios.

Hace unos meses decidi hacer un experimento en casa, se trataba de combinar (y asi practicar) el uso de SQL Server 2008, Windows Presentation Foundation y... LINQ to SQL. El proyecto consistia en meter en una Base de Datos el grueso de mi coleccion de MP3, sus posiciones relativas al Ranking de Doble9, y mediante LINQ (en vez de T-SQL) efectuar las respectivas consultas.

Pues si, el experimento ha funcionado bien a efectos de las consultas, no tanto a nivel de WPF, pues.... como buen ingeniero a veces fallamos en la parte de la estetica y la funcionalidad, pero el caso es que mejor hubiera sido al reves (al menos ya lo tengo todo en SQL Server) pues hoy gracias a Directions on Microsoft me vengo a enterar que Microsoft ha decidido reemplazar LINQ to SQL por el ADO.NET Entity Framework, que si.. que seguira funcionando pero no se beneficiara de las innovaciones que vaya desarrollando Microsoft.

En parte tiene sentido el movimiento, cuando empece con mis primeras pruebas una de las primeras cosas que intente fue ver si era capaz de conectarse a Oracle, lo cual... no era posible, y por ahi salian las recomendaciones de que eso debia de hacerse mediante el Entity Framework, y claro.. entre trabajar un API que solo te permite conectarte a una BD (por mas de que sea la mejor) y otra mas abierta... las cosas caen por su peso.

LINQ to SQL debuted with LINQ in the .NET Framework 3.5 in 2007. LINQ is a set of APIs and programming language features that enable data access queries to be written in programming languages such as C# and Visual Basic, rather than treated as text data. LINQ simplifies data access code and enables the developer to use the Visual Studio tools, such as the compiler and IntelliSense command completion, to help write queries. At its launch, LINQ supported a variety of data sources, including in-memory data objects and XML documents, and the Microsoft C# team had built a stopgap LINQ connector to SQL Server—LINQ to SQL.

However, when LINQ to SQL shipped, the Microsoft data access team had already begun work on the ADO.NET Entity Framework, a more general data access technology that provides LINQ connectivity to SQL Server and other database management systems, including Oracle and IBM DB2. When the Entity Framework was introduced with the .NET Framework 3.5 SP1 in July 2008, LINQ to SQL became largely redundant.
.......
Microsoft has begun publishing documentation for migrating applications from LINQ to SQL over to the Entity Framework. Migration is manual, and both application-side LINQ code and data access code might have to change. Furthermore, the Entity Framework itself is due for major changes, some designed to simplify migration from LINQ to SQL and address requests from LINQ to SQL developers. Consequently, developers who have existing LINQ to SQL applications might want to wait for the next version of the Entity Framework, due in late 2009 with the .NET Framework 4, before attempting a migration.

Creo que sera buena idea estar pendiente de las betas para saber como va evolucionando el Entity Framework, asi que ... mi experimento sigue sin terminar ;)

Es curioso a lo que puede llevar la ley del minimo esfuerzo, no? Como parte del trabajo en informatica es usual que pidamos o se nos envien capturas de pantalla (pantallazos) para saber lo que esta ocurriendo en ese instante (errores, mensajes, estados), hasta ahi todo correcto, total pulsar Print-Screen y sus variantes, para luego pegar, es algo muy sencillo.

Lo que ya es desconcertante es el fenomeno de que cuando me envian dicho pantallazo lo que me mandan es un archivo de Microsoft Word (un .doc o .docx), en lugar de un sencillo .jpg o .bmp, y claro... eso complica la apertura, no deja hacer previews, te obliga a cargar un programa de por si pesado, etc etc...

Vamos, el Word no es un programa con el cual manejar imagenes, no por el hecho de que podamos colocar graficos en nuestros documentos tenemos que usarlo para capturar imagenes, sorprende mas aun que sean personas de nuestro mundillo (especialista de redes y especialista en SAP) quienes pequen de esta manera, aunque claro no se puede estar en todas y a veces te puede caer la necesidad de saber como usar Powerpoint por primera vez en tu vida.

La solucion? simple... usar el clasico y tradicional Paint que esta en nuestra carpeta de Accesorios, o si queremos algo mejor siempre podremos usar Irfanview que es muy funcional ademas de gratuito. Asi que ya saben.... la proxima vez que quieran mandar un pantallazo, peguen la imagen en un editor grafico como los mencionados y no usen el Word, ok? :D