Al parecer Gmail lleva caido por un buen tiempo.
2/24/2009
We're aware of a problem with Gmail affecting a number of users. This problem occurred at approximately 1.30AM Pacific Time. We're working hard to resolve this problem and will post updates as we have them. We apologize for any inconvenience that this has caused.
Es bastante frustrante no poder leer los correos cuando realmente necesitas hacerlo. Creo que es tiempo de replicar los mails en otros servidores. 🙂
El cuento empieza luego de que un amigo me preguntó si sabía algo de Graffiti -- un CMS de pago desarrollado en .NET, puesto que su empresa tenía planes en adquirir unas cuantas licencias del mismo.
El hecho es que mientras charlabamos intenté convencerle para que usen WordPress en su lugar, pero las principales razones que me dió para haber descartado esa opción era que a) WordPress tenía un largo historial de problemas de seguridad en comparación al otro y b) que por el mismo hecho de estar desarrollado en .NET la aplicación era más segura.
Cuando participaba en ciertos foros de discusión relacionados a .NET, solía ser fácil encontrar ese tipo de opiniones en relación a la seguridad[1] de ASP.NET, es por este motivo que me animé a comentar esta anécdota, puesto que posiblemente sea de útil para alguien que recién comienza -- naturalmente tendría que pasar por alto mi terrible forma de redactar y ortografía. 😀
Regresando al tema lo que le dije fue que los problemas de seguridad existen, más allá de lo buenos que sean los programadores o de que los lenguajes que utilicen sean dinámicamente o estáticamente tipados y que el número de problemas reportados generalmente está en relación a la popularidad del software.
Finalmente, para reforzar lo que había dicho, daba la casualidad que hace algo menos de un año, había encontrado un problema grave de seguridad que todavía afecta a la última versión de Graffiti y que permite tomar el control del sitio en cuestión de segundos. Ahora me pregunto, ¿habré ganado algún usuario más de WordPress? 😀
1. No digo que este tipo de opiniones solamente vengan de parte de algunos desarrolladores .NET, sólo comento mi experiencia.
Recuerdo haber cometido un error similar alguna vez. Lo interesante de este tipo de cosas es que en muchos casos no son detectados durante la etapa de desarrollo. En mi caso, apareció mientras hacíamos un demo a los clientes. 😀
Llevo utilizando XSLT dos días y aunque con ese nivel de experiencia no estoy en posición de decir mucho al respecto, debo comentar que hay cosas que sorprendentemente resultan todo un problema al momento de querer implementarlas.
Para dar cierto contexto a lo que diré en adelante, el proyecto en el que llevo trabajando (como ayudante o stagiaire si lo prefieren) empezó a finales del año pasado y por más que considere que XSLT en este caso en particular no sea la mejor opción, por el momento estoy obligado a usarlo.
En fin, la parte en la que estoy trabajando tiene que ver con la conversión de un automata finito determinista1 a otro equivalente en el que se incluye operaciones a realizar en función a las transiciones y estados. La siguiente imagen ilustra un tipo de transformación:
Parte de "Synthesizing Enforcement Monitors wrt. the Safety-Progress Classification of Properties"
Por clara y relativamente sencilla que parezca esa regla, me está costando implementarla en XSLT. Por ejemplo el hecho de que las variables en este lenguaje se comporten como constantes hace que muchas veces tenga que hacer concatenaciones o funciones (templates) recursivas, lo que porsupuesto hace más feo y largo el código.
1. En realidad me refiero al Automata de Street.
Desde que dejé el trabajo, mis actividades han cambiado lo suficiente como para no haber escrito casi nada en el blog. Es decir, si antes pasaba gran parte del tiempo viendo y escribiendo código en C# o PHP, desde hace algún tiempo he tenido que volver a usar java -- un lenguaje al que al principio me costó volver a adaptarme debido a ciertas diferencias y peculiaridades que este último tiene (ejm. generics).
Cuando utilizaba C#, la herramienta más efectiva para programar en ese lenguaje, en mi opinión porsupuesto, era la combinación de Visual Studio y Resharper. Actualmente, cada vez que ejecuto Eclipse, algo que sin duda extraño de esa época, es esa facilidad de hacer las cosas en el menor tiempo posible.
Es por eso que me gustaría que aquellos que utilicen Eclipse me regalen un poco de su tiempo para recomendarme algún plugin. Plugins que por ejemplo agreguen más opciones para hacer refactoring, para la navegación y lectura de un proyecto existente de manera un poco más efectiva o que en general permitan trabajar un poco más rápido.