Ayer me llego mi portatil nueva y como todo “niño” con juguete nuevo me metí inmediatamente a quitarle y colocarle cosas que necesito, entre ellas VS2008, lamentablemente a media instalación obtuve un error muy extraño que decia:

Installation of Visual Studio 2008 Fails while installing Web Authoring Component

Indicando un poco mas de informacion tal como sigue:

There were errors during setup.
Although the components were installed successfully, some setup errors were detected.

View error log

For information on known setup issues, see the Microsoft Visual Studio readme file, readme.htm, located at the root of the installation source.
For Knowledge Base articles on Visual Studio setup issues and solutions, see KB article 319714, HOW TO: Troubleshoot Visual Studio .NET Installation, at http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q319714.
To find help from other Visual Studio users, try the following newsgroups:
Visual Studio Setup
Microsoft Product Support
For details about this setup failure, see the setup log files.

Ingrese a la pagina que se adjunta y también a los logs de instalación descubriendo que era un problema con mi versión de Office 2007 previamente instalada. Decidí consultar en internet y encontré varios recursos que hablan de problemas similares, estos son:

http://blogs.msdn.com/joy/archive/2008/08/01/installation-of-visual-studio-2008-fails-while-installing-web-authoring-component.aspx

http://social.msdn.microsoft.com/Forums/en-US/vssetup/thread/15c14d44-592a-420c-9c2a-75c5803e9f18/

Pero finalmente encontré dos soluciones

1. Aplicar esta pequeña secuencia de pasos:

• Click on the Start menu, choose Run, type regedit and click OK
• Locate the following registry value: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion]
  ProgramFilesDir
• Remove the trailing backslash from this ProgramFilesDir registry value
• Close regedit and reboot the computer
• Re-run Web Authoring Component setup from <VS install path>\WCU\WebDesignerCore\WebDesignerCore.exe
• Look at %temp%\SetupExe(*).log and verify that installation succeeded this time
• Re-run Visual Studio 2008 setup to complete installation

2. La otra era desinstalar Office 2007, Instalar VS2008 e Instalar nuevamente Office 2007.

Saludos

Bueno aquellos que aun creemos algo en IE y específicamente en IE7 nos gusta ver herramientas como las que les presento, si no la conocen. IE7Pro es un conjunto de add-ons o add-ins (no se por que se complican si es que hay diferencia) que brindan muchas funciones que quizá podríamos encontrar en Firefox pero que son un poco mas complicadas encontrar en IE, pero aquí están, los que mas me gustan:

• Gestos de ratón, pueden hacer algunas tareas con solo “dibujar” la acción con el mouse
• Guardar la pagina como imagen, dale que es una utilidad que me hacia falta cuando documento algo.
• Corrección de Ortografía, eso, corrige la ortografía cuando escriben algo en el browser, no es la gran maravilla pero a mi me ayuda en mi ingles HAU. :D

Aprovechando este post, expreso mi esperanza de que IE8 tenga un modelo de creación de add-ins mas documentado que el pobremente IE7, o quizá alguien conoce algún recurso que sea completo?

Link: http://www.ie7pro.com/

Bueno un abrazo.

Ahora que estoy trabajando un poco mas con Visual Studio 2008, me di cuenta que mi instalación tenia un pequeño problema, que por no decir otra cosa lo calificaría como molestoso, sucede que el panel de proyectos recientes, siempre aparecía vacio, esto quiere decir que cada vez que abría el VS tenia que buscar una y otra vez el proyecto en el que estoy trabajando, la primera, la segunda y hasta la tercera vez aceptable pero me canse, busque una solución y encontré esto:

Esta característica esta vinculada a como se manejan los documentos recientes en Windows y por alguna mendiga razón, los flags que controlan esto contenían un valor diferente al que deberían tener. Las siguientes entradas del registro, deben ser colocadas en 0 (cero) y el problema se soluciona.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoRecentDocsMenu

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoRecentDocsHistory

Saludos

Curioseando por ahi, por la necesidad, encontré que es posible utilizar LINQ to Objects en el framework 2.0/3.0, de la mano de Joseph Albahari, solo se necesita el bridge que les adjunto y Visual Studio 2008.

La verdad que considero por demás una razón de sobra, el hecho de tener LINQ y justificar con esto la migración de muchos proyectos que aun usan VS2005. Por mi parte estoy recomendando al proyecto en el que estoy trabajando y si los convenzo de migrar aunque sea inicialmente solo de entorno usando este bridge ya estará dado el primer paso para hacer luego la gran migración.

El Link: http://www.albahari.com/nutshell/linqbridge.aspx

Antes que nada, muchísimas felicidades a todos Uds. colegas y lectores de esta maravillosa comunidad, después de laburar más de lo normal y luego de unas merecidas vacaciones, vuelvo a las andadas, escribiendo las cosas que suben a mi cabeza.

En esta ocasión deseo compartir con Uds. algunas de mis percepciones de cómo está evolucionando el desarrollo de software hoy en día. La verdad que se me hace muy complicado empezar a enfocar esta entrada, esto es debido a que muchas de las cosas que han ocurrido en el pasado, han influido enormemente en cómo se hace el software hoy, además que existen una infinidad de temas de los que quizás están pensando, voy a tocar, sin embargo dando algunas vueltas he decidido escribir de dos temas importantes: Donde va el desarrollo con .NET y que pasa o pasará con SOA.

Cada día recibimos noticias acerca de cómo Microsoft va moldeando un nuevo y más versátil Framework, creo que ya varios escribieron sobre eso en la comunidad, pero lo que ocurre mas alla de la vista de Microsoft es otra historia, en esa otra visión vemos a una comunidad que ha adaptado .NET como una alternativa confiable y ha construido software sobre esta plataforma, pero si miramos mas detenidamente, ella está formada creciente y recientemente, por personas que vienen de usar J2EE y que me gusta llamarlos "los conversos" sean estos voluntarios u obligados, estas personas están dia a día aportando a la plataforma viejas ideas (de su antiguo mundo J2EE) y exportando estas hacia .NET.

Existen mucho software que seguramente se les viene a la mente al leer esta frase, entre ellos JUnitàNUnit, Hibernate à NHibernate, CruiseControlàCruiseControl.Net, Struts à NStruts y muchos otros y cuando digo muchos son realmente muchos, algunos de ellos con poca actividad otros sin crecimiento otros con mucho mas y pueden encontrar más en este sitio, pero el común denominador es que nos invaden ideas viejas J y no me malinterpreten, no digo que este mal, solo me sorprende la cantidad de cosas que se están reinventando, en nuestra plataforma favorita. Esta tendencia, sin lugar a dudas no va a detenerse, ha de ir sentando raíces para quedarse y en muchos casos para transformar radicalmente el Framework .NET. Debemos admitir que J2EE ha estado en el negocio del desarrollo "profesional" un poquitín más que .NET y de ahí que esta comunidad conversa ha de traer ideas frescas y novedosas para nosotros, pero ya digeridas en esa otra realidad, una de ellas y la que mas me ha llamado la atención es la implementación de un recientemente conocido (para mí) patrón arquitectural llamado "Naked Objects" la traducción podría resultar desconcertante, así que prefiero dejarlo en ingles J, este patrón que personalmente lo he visto implementarse de manera intuitiva en productos como el uruguayo Deklarit o el publicitado y nunca bien apreciado Genexus, en ambos casos la idea de un modelo de objetos que guía el desarrollo está fuertemente arraigada, con sus matices y variaciones y ya venía madurando, con bastante éxito debo decir, por la cantidad de usuarios que pueden contarse en ambas herramientas, quizá algunos discrepen conmigo de la pureza de la implementación de Naked Objects en estas herramientas y es justamente ese mi punto, la idea de implementar este patrón ha ido merodeando la cabeza de muchas personas y me incluyo entre ellas y como todos podemos afirmar, la implementación de un patrón es diferente de implementación a implementación.

En J2EE se ha realizado un esfuerzo un tanto diferente, digamos que "desde cero" siguiendo lo aprendido del largo camino de evolución de este patrón ha creando un producto llamado Naked Objects Framework, que siguiendo lo explicado anteriormente ha tenido su hermano mellizo llamado Naked Objects.NET (nombre bastante original) que a diferencia del anterior es un producto comercial, lamentablemente añadiría, aunque existe una versión gratuita, es bastante limitada.

¿Que nos permite hacer este producto? Básicamente sentarnos a modelar y generar a partir de este modelo, generar las diferentes capas que componen nuestra aplicación, incluida la necesaria capa de presentación, ventanas y controles incluidos. El modelo lo controla todo, incluyendo las modificaciones, la teoría que nos guía es que los requerimientos son expresados y volcados en el modelo, cuando un requerimiento cambia, por ende el modelo ha de cambiar y esto disparará la serie de cambios en las diferentes capas de la aplicación. La esperanza de los creadores de estos productos es una premisa del patrón, que indica, que al existir una correspondencia de 1:1 entre la interface de usuario y el modelo, se obtiene una mayor calidad en el diseño orientado a objetos y mayor agilidad de desarrollo.

Sin embargo, a este punto voy a permitirme discrepar de esta tendencia, como les comente anteriormente conozco los productos que han implementado este patrón y he utilizado los mismos, no a gran escala pero si lo suficiente para observar sus fortalezas y limitaciones. Entre sus fortalezas sin lugar a dudas esta lo que he mencionado anteriormente, son herramientas ideales para desarrollo ágil, nos ayudan a pensar mas en orientación a objetos y a abstraernos de los detalles de la implementación, pero, se encuentran limitadas ante requerimientos de alta interacción, es decir frente a interfaces (hablemos mas directamente) que deben ser programadas con altos niveles de interacción entre componentes o con el usuario, no digo que no puedan utilizarse o realizarse cosas complejas, solo que nos limita la complejidad que agregan para realizar estas tareas. En ningún punto y bajo ninguna circunstancia deseo desmerecer o minimizar la utilidad de estas herramientas, solo darles el lugar que creo que deben tomar y es el de ser herramientas de apoyo y no centrar toda nuestra expectativa del desarrollo en ellas.

Bueno, a donde va todo este discurso, una parte está destinada a aquellas personas que creen que lo que existe en .NET es totalmente original y a mostrarles una interesante realidad, nada es original todo es evolución por decirlo menos J, otra parte destinada a aquellos que mira a herramientas como Genexus con total orgullo y expresar un comentario que hace bastante quería hacerlo y una otra parte a reafirmar el hecho de que las herramientas de terceros y tarde o temprano las herramientas incluidas en el framework.NET, vendrán de nuestro vecino J2EE como lo han estado haciendo, esto quizá, es algo que ya todos sabíamos, bueno no todos, lo novedosos es que ahora que lo percibo y escribo, deseo que se apuren a traer más cosas de allá para acá J, obviamente existen un creciente número de cosas que van de aquí para allá también pero eso es tema de otra entrada.

Se me hizo extensita esta entrada por lo que decidí dividirla en una segunda parte que estaré publicándola el fin de semana, donde veré un poco de lo que es y será SOA, siempre de acuerdo a mi modesta percepción.

Saludos.

Un día, no muy lejano, en nuestro país, nos encontraremos en la situación que está atravesando la profesión informática o ingeniería de sistemas en España, seremos capaces de unirnos y crear un solo frente para ese momento?

Los colegios de profesionales ni tan siquiera están perfectamente articulados entre sí, aunque conozco que se ha conformado una directiva nacional, mas me parece aun un simple saludo a la bandera, que una realidad palpable y con las políticas que este gobierno esta tomando, de impedir la afiliación de los profesionales a sus respectivos colegios de profesionales, esta matando un punto de unión importante. Estoy también de acuerdo que algunos, de los colegios que agrupan profesionales tampoco son de lo más populares, al obligar a pagar altas sumas de inscripción, mantenimiento de membresia y para colmo los beneficios los "huelen" solo algunos si es que hay beneficios. En fin es un tema muy complicado, pero de algo estoy seguro, la unión hace la fuerza y por el momento creo que no podríamos enfrentarnos a retos como el que vive España.

http://www.huelgainformatica.es/

http://www.elmundo.es/navegante/2008/11/06/tecnologia/1225986773.html

Sé que lo que voy a comentar y mostrar puede causar incomodidad, fundamentalmente porque voy a hacer "propaganda involuntaria" a un producto comercial, pero antes de decir el nombre que espero solo mencionarlo una única vez, en toda la entrada, quiero aclarar, que no trabajo para esta empresa, en ningún sentido y que mi intensión no es venderles una copia del mismo, solo es argumentar en base a dicho producto, las opiniones que voy vertiendo.

Primero contarles, que he trabajado, con varios productos de control de código o control de versiones (como lo llamare indistintamente), desde el CVS, pasando por SVN, arribando misteriosamente a Visual SourceSafe (gajes del oficio) y finalmente entrando al increíble y vasto mundo de Team Foundation System. En todas estas experiencias, cada una de ellas mejor que la otra, bueno, no tanto SourceSafe comparada a SVN pero si en lo que se refiere a su integración con Visual Studio, obviamente algo que SVN deja mucho que desear, por muy Tortoise o Visual SVN, que se use J, esta experiencia me ha expuesto a diferentes formas de trabajar en equipo, desde equipos pequeños de 3 personas (desarrolladores) hasta un equipo de más de 25 programadores (mi actual laburo), cada uno de ellos con diferentes problemas desde la comunicación hasta extrañas rencillas personales y en todos ellos un denominador técnico común, la existencia de errores de compilación en el código que se sube al control de versiones.

Les describo un escenario, que seguramente es común, en muchos lugares; supongamos que estamos en el escenario más pequeño donde 3 programadores trabajan sobre una cantidad de archivos, que seguramente tampoco es muy enorme,

1. El programador A inicia su día y como sería lo más recomendable, realiza un get-latest de toda la solución, antes de empezar su jornada, comienza editando unos archivos y porque le parece innecesario comenta un método en un archivo, el método no está siendo utilizado en ningún lugar, para que alguien deja un método sin uso!!! (Check-out) Y en la clase que él ha programado, pero sin darse cuenta que este método es importante para el programador B.
2. El programador B que estuvo trabajando toda la madrugada, sin editar ese método ni el archivo, programo otras clases confiando en la existencia del método, hace get-latest antes de hacer chekin y procede a subir sus cambios al servidor, todo compila para mi (dice el programador B)
3. El programador A, 5 segundos después del programador B, hace checkin si hacer get-latest porque está trabajando también desde su casa, su perrito cachuchin se murió esa noche, no está de humor para esperar a recuperar la solución entera de nuevo!!, hace unos minutos hizo get-latest que pudo haber pasado, y repite todo compila para mi (dice el programador A)

En este escenario ya existen problemas de compilación con el código que está en el control de versiones; puede analizarse el problema desde diferentes puntos de vista, entre ellos.

• Es culpa del programador A, porque no cumple con la norma de get-latest antes de hacer checkin, opinión valida, pero la defensa del programador A también es válida, el puede argüir hace x minuto(s) hizo get-latest y todo estaba bien
• Falta de comunicación, entre programadores, quizá hubiese bastado que el programador A, le avise al programador B que iba a hacer ese cambio, pero nuevamente, en entornos de alta concurrencia y exigencia, el averiguar quién es el dueño de una línea de código puede representar minutos valiosos.

Las soluciones van de la mano quizá, de los problemas que se encontraron:

• Incrementar el nivel de comunicación de las políticas de construcción (build), como ser get-latest al principio de las ediciones, get-latest antes de hacer checkin
• Incrementar el nivel de comunicación entre programadores.
• Dividir la solución en trozos más manejables evitando interferencias mutuas.

En fin puede encontrarse diferentes formas más, de encarar, este problema y créanme que aplique muchas de ellas con éxitos parciales y yo catalogo a estas soluciones en reactivas y proactivas, todas las que incluyen hacer algún procedimiento manual, comunicativo, de partición o arreglo, son reactivas, porque tarde o temprano caerán en alguien reaccionara para resolver el problema de ese archivo en el control de código y créanme que esto se vuelve una bola de nieve y cuando hay más de dos programadores involucrados hay varios más adicionalmente parados porque no pueden compilar la solución entera, hasta que arreglen el problema. La solución proactiva que encontré, quizá al leer esto alguno me de otra proactiva, es algo que en mis días y noches de trabajo pensé…. En estas fases:

• ¿Por qué no compilar la solución antes de hacer checkin?, bueno eso ya estaba en la norma, del papel, no funcionaba.
• ¿Por qué no, obligar a todos a hacer get-latest antes de hacer checkin? Es algo que es simple de poner en la norma pero no todos la pueden cumplir, hay algunos que tienen trabajo remoto, problemas de ancho de banda, etc., tampoco funcionaba.
• ¿Por qué no, dejar que el servidor de integración continua haga las dos cosas anteriores por mí?
• Un momento para que suceda esto tengo que enviar todos los cambios que haya hecho yo, al servidor, el los debe recibir, obtener versión (get-latest) de todo, unirla a mis cambios, compilar, si es exitosa la compilación recién hacer checkin por mi e informarme de esto…..uffff

¿Esta idea estaba correcta? Decidí averiguar mas y encontré que mis ideas locas estaban sustentadas en un libro de patrones de integración continua, que creo que algunos de los miembros de los equipos de Microsoft u otros fabricantes de herramientas de integración continua, no lo hojearon y mencionan como Private Builds (Construcciones Privadas), sin embargo el concepto no correspondía exactamente al que yo tenía en mente, hasta que me encontré con Team City.

Este motor o servidor de integración continua, muy a pesar de mi querido TFS Build, había implementado una característica llamada Pre-test commit o Remote Private Build, que concuerda con todas mis expectativas, a tal punto que inmediatamente pude, es decir en cuanto tuve la oportunidad en mi nuevo laburo, instalamos y pusimos en producción esta idea experimental, a esto debo agradecer enormemente el apoyo recibido por parte de Andrés Gonzales y Dulfredo Rojas, sin quienes mis ideas y expectativas de probar esas "teorías", solo hubieran quedado en eso.

Antes de pasar a explicar los beneficios del Pre-test Commit y como afecto esto a nuestra compañía, déjenme decirles que esto lo comente personalmente con dos personas de Microsoft, una de Argentina y otra de Perú, de las cuales me abstengo de dar nombres para evitarme problemas, pero que se que son lectores míos y con todo respeto, ambos quedaron totalmente sorprendidos de que existiese una herramienta similar.

La siguiente imagen muestra unas estadísticas de su uso, sobre las cuales voy a ir dando las bondades que obtuvimos:

Antes de la puesta en producción, nuestra tasa de Builes o construcciones exitosas del producto, con suerte llegaban al 30%, en el grafico pueden observar que paulatinamente pasan los meses y las tasas de construcción automática exitosas, se van estabilizando e incrementando, hoy alcanzamos un poco más del 80%, esto quiere decir que el código que está en el servidor, prácticamente es estable en compilación, antes los programadores tenían miedo hacer el get-latest, hoy es una práctica mucho más segura, el incremento paulatino se debe fundamentalmente al tiempo de adaptación que tuvieron los programadores y el tema de hacer olvidar a todos ellos la frase: "Compila para mi" o "compila en mi equipo (computadora)"

Pasemos al segundo, grafico, que me permitirá resolver otra de las preguntas que puede que algunos estén haciéndose, cuán rápido puede ser el proceso de hacer remote prívate Builes, y este grafico muestra que en promedio nuestros Builes ya sean personales o normales tardan 2 minutos, nuestra solución tiene algo más de 70 proyectos (ya se vamos a particionar la solución " src="smilies/veryhappy.gif"> )y el compilar en una maquina local tarda entre 10 a 15 minutos, una solución Windows Forms y muchos chiches mas, la solución de compilación que compila en nuestro servidor de integración continua está basado en Nant y con algunas optimizaciones. Algunos podrán preguntarse y porque no MS-Build y la verdad la respuesta es que mis pruebas las programe inicialmente en Nant por simplicidad y luego el migrar todo a Ms-build pues nos tomara un cachito pero estoy consciente que funcionara bien

El ultimo grafico, muestra una característica que tiene este servidor de integración continua y es el encolamiento de solicitudes de build, que aunque no está asociado directamente al Pre-test Commit les da una idea de que en promedio tenemos 2.5 minutos de encolamiento, hay días pésimos y otros maravillosos, pero ya tenemos pensado agregar un segundo servidor que disminuirá enormemente este tiempo.

La herramienta de por si tiene varias características, entre ellas que soporta muchos lenguajes scripts de construcción automática como Nant y MS-Build entre otros, soporta diferentes controles de versiones, CVS, Perfore, SVN, etc., se conecta e integra perfectamente a Visual Studio, escala perfectamente, aunque tenemos algunas dudas que seguramente las solucionaremos pronto, tiene interfaces de notificación y configuración para todos los gustos, en fin ingresen a la pagina y podrán encontrar mucha información.

Quizá la más grande cuestión que queda es, ¿porque no TFS Build? Y principalmente porque no tiene la característica de Pre-test Commit, que es la principal razón por la que escogimos este servidor.

Dos recomendaciones una a Microsoft como a otros fabricantes tales como CruiseControl, implementen esta característica, realmente eleva los niveles de productividad, en ambientes de alta concurrencia, pues es un método pro-activo, al impulsar al programador a tomar la responsabilidad de pensar en un "build sano" y permitiría que un servidor de integración continua, haga algo más que hacer Builes y mi última recomendación a los programadores (usuarios finales), los métodos reactivos tarde o temprano fallan, tomen uno proactivo.

Lo conversaba con mi colega Andrés Gonzales y otra idea genial seria que Microsoft, aceptaría en el TFS la posibilidad de intercambiar su motor de control de código, por otro como CVS (nooo que dije), algo así como su proxy con SVN pero mucho más nativo, esto abriría enormes posibilidades, pero este comentario, es harina de otro artículo.

Un abrazo y si les gusto quizá me dan una idea de donde más explicar algunos detalles.

Saludos

La idea de tener que trabajar diariamente sobre un visual studio, que demora demasiado en cargar, no es precisamente la mas agradable de las ideas y es lo que generalmente me ocurre últimamente en la oficina, pues eso, que Visual Studio demora demasiado en todo, desde abrirlo, cargar el proyecto, compilar mi solución, ejecutar la depuración y hasta en ocasiones (frecuentes) se pasma, se muere o se cuelga como decimos por estos rumbos. Esto es realmente frústante, pues la el 40% de una hora de trabajo la paso viendo pasar el reloj de arena o la barra de progreso o lo que yo le llamo, teniendo tiempos muertos, que me gustaría aprovechar en hacer otras cosas, si estuviese en mi casa :D.

En fin la verdad es que esto esta colmando poco a poco mi paciencia así que estuve pensando y actuando obviamente, para lograr mejores resultados y esta es una primera parte de la serie de acometidas que busco escribir, para compartir con Uds. mis pesares y exitos al mejorar mi relación con Visual Studio.

Desafió de mejorar la velocidad de carga

Si bien mi velocidad de cargar VS no es exagerada, se toma su tiempito, aproximadamente un minuto, lo mejor que puedo recomendar para este caso es:

• Desactivar los add-ins que no vas a necesitar, muchos se quejan de lo que Resharper les hace a su VIsual Studio, si no lo vas a utilizar, fuera
• Dirigete a la opción Tools --> Import and Export Settings y selecciona Reset All Settings, veras como mejora la velocidad de carga de tu VS.
• Desactiva las animaciones de herramientas, en esta opción Tools --> Options --> Enviroment --> General --> (Animate enviroment tools)

• Si consideras que no pierdes demasiado, desactiva el seguimiento de cambios, Tools --> Options --> Text Editor --> (Navigation Bar)
• Nuevamente, si no estas creando un proyecto donde construyes controles y no necesitas que estos se actualicen automaticamente en el ToolBox, desactiva esta opcion, escogiendo Tools --> Options --> Windows Forms Designer --> (AutoToolBox Populate) en False

• Una ultima sugerencia, esta quizá es como poner la tranca cuando el caballo ya salió, pero no esta demás, da relevancia a la velocidad que tiene tu disco duro, como lo indica ScottGu en su blog, maldición a la hora que me pongo a investigar. " src="smilies/veryhappy.gif"> En el link mencionado, encontraras algunas recomendaciones adicionales que hace el autor.

Pronto la siguiente parte, donde analizare algo de las ingentes cantidades de memoria que se come VS y como paliar en algo este problema.

Saludos

Estimados lectores

Se que me he perdido algunas semanas, casi un mes sin escribir "nada", pero tengo dos poderosas razones.

Una, el laburo, indiscutiblemente, me estaba consumiendo excesivo tiempo, incluso del personal, pero creo que ya se esta acomodando la situacion.

La otra razon es que .... los he estado traicionando, jejeje en el buen sentido de la palabra, escribiendo en otro blog, cual otro blog???!!!! pues uno al que me invitaron a escribir personas de España y de lo que antes se conocia como Microsoft Iberoamerica, confirmado por eminentes personalidades de esos lares y nuevamente les repito, me brindaron la oportunidad y el honor de expandir mis rumbos de autor y llegar un poco mas lejos que solamente nuestro querido Pais. La comunidad en cuestion se llama Geeks.ms y mi blog nuevo, lo pueden encontrar aqui.

Los articulos los seguire publicando en ambos blogs, con mas exclusividad los articulos tecnicos, pero obviamente seguire manteniendo esta pagina que me identifica, siempre y cuando no ocurra alguna catastrofe financiera en mis arcas personales.

Las anteriores semanas estuve ya escribiendo y preparando algunas cosas que ire sacando en ambos blogs, de manera paralela, como siempre.

Muchas gracias por todo su apoyo y por los mails de interes ante la ausencia de articulos por aqui.

Saludos