Alphasite

Estos últimos días he estado probando la beta de Stackoverflow, un nuevo website fundado por Jeff Atwood y Joel Spolsky.

Lo primero es lo primero, han hecho un trabajo excelente tanto en implementación como en planteamiento.

Stackoverflow esta planteado como una comunidad de desarrolladores en particular y gente del mundo del software en particular.

El sistema se basa en preguntas y respuestas. Alguien hace una pregunta y la gente de la comunidad responde. Evidentemente aún está en beta por lo que hay muchas cuestiones de concepto que aún se están discutiendo pero básicamente el funcionamiento es ese.

Ahora bien, a eso la gente normal le llamaría "foro", si no fuera por el sistema de votaciones y puntuación que tiene incorporado. Me explico, cada entrada, tanto las preguntas como las respuestas, pueden ser votadas por los propios usuarios de la comunidad. Cada usuario puede emitir un máximo de 30 votos positivos por día y 10 votos negativos por día y cada voto le proporciona a quien lo recibe 10 puntos de reputación.

Acabo de leer el artículo Check in Early, Check in offen de Jeff Atwood acerca de la metodología de uso del control de versiones para el desarrollo de proyectos.

Aunque coincido con los artículos de Jeff en muchas ocasiones, esta es una de las situaciones en las que no lo hago.

En primer lugar, como por otro lado suele pasar con este tipo de artículos, las reflexiones que hace son demasiado genéricas y sobre caso demasiado simples como para poder extraer verdaderas conclusiones sobre ellos.

Hacer check in pronto y a menudo. Suena bonito, parece un concepto adecuado pero hay muchas cosas que quedan fuera del análisis, cosas que en un proyecto pequeño con dos o tres desarrolladores no tienen importancia pero que en grandes proyectos pueden dar verdaderos dolores de cabeza.

Últimamente TheAlphasite está un poco parada (más de lo habitual), quizá os hayais dado cuenta.

No es que haya perdido impulso, es que estoy preparando a su sucesora.

Stackframe.net (que así se llamará) será muy parecida a esta página pero estará en inglés y en español. Tendréis todos los artículos que hay disponibles aquí también allí, y otros nuevos.

El objetivo es convertir esa página en lo que esta tenía que haber sido y permitirme dedicarle más tiempo, más recursos y más ganas para publicar tanto noticias como cualquier cosa que se me vaya ocurriendo, así como permmitir que preguntéis cualquier duda que tengáis para obtener aclaraciones o un artículo completo explicando algún concepto o duda que no tengáis claro.

Aún le queda un tiempo para estar lista, pero espero que este arriba antes del verano (o a la vuelta como muy muy tarde)... En cuanto esté lista os avisaré (y poco después redirigiré todo el tráfico de este sitio hacia stackframe.net

Está disponible para descarga la herramienta Microsoft Source Analysis para C# que permite el análisis de nuestro código fuente para adaptarlo a los estándares de calidad que rigen dentro de la propia Microsoft.

La herramienta es similar a FxCop pero aplicada directamente al código fuente (mientras que FxCop afecta a ensamblados directamente).

Microsoft Source Analysis viene configurada con unas 200 reglas (que no se pueden editar) y que afectan cosas como la disposición de los elementos del código (corchetes, espacios, etc), la presencia o no de documentación, el espaciado de lineas, el nombrado de los elementos así como algunas otras cosas. Su objetivo primordial es mejorar la estructura y presentación del código para mantener unas regla que lo hagan lo más legible posible.

Personalmente FxCop me parece mucho más completo y además utilizan reglas distintas que en algunos casos pueden llevar a conflicto. No obstante son herramientas distintas con propositos distintos y algunas de las cosas de este Source Analysis estriba en cuestiones de layout (por ejemplo te recomiendo que un comentario de código debería estar precedido de una linea en blanco (para mejorar la legilibilidad del código), te avisa de la falta de documentación de los métodos o te avisa de las secciones de código que son poco "legibles", por lo que su ámbito es distinto y FxCop, q trabaja con ensamblados, nunca podrá dar información de ese estilo.

Podéis descargarlo aquí.

De un tiempo a esta parte se ha oye el concepto de "programación colaborativa" entre varios programadores de forma que varios programadores trabajen simultaneamente sobre el mismo fragmento (o fragmentos) de código.

La idea detrás del paradigma consiste en que dos pares de ojos ven mucho más que uno y por tanto, aunque la productitividad de dos programadores trabajando será siempre mucho menor que la productividad de ambos por separado, la calidad del código producido será muchisimo mayor, lo cual debería llevar a un código más mantenible, más organizado, más elegante y más seguro.

En los últimos tiempos parece que los movimientos de las grandes compañías, especialmente Microsoft y Google tienden a intentar acercarse cada vez más a la tecnología web de una forma o de otra.

No es para menos, el mercado potencial de internet es muy superior a cualquier otro mercado que se haya dado hasta ahora, basta con mirar a Google, cuyo negocio es únicamente internet para darse cuenta de eso. Cada vez nos encontramos con más acercamientos por parte de montones de empresas para ofrecer diversos servicios alrededor de la web, muchas de ellas con un enorme éxito. Ahí tenemos Twitter, Facebook, Blogspot...

Sin embargo, últimamente parece que se empieza a hablar de un "universo web", Google Docs, Microsoft Office Live, Piccasa, etc ... y empieza a implantarse por aquí y por allá la idea de "sistemas operativos web", a saber donde llegaremos. La absurdez del asunto asusta, que uno pueda hacer algo no quiere decir que lo que haga este bien hecho y tenga sentido, no porque el correo electrónico online sea algo extremadamente útil va a pasar lo mismo con una suite ofimática en linea.

He estado leyendo una entrada en el blog de Sasha Goldshtein titulada "Design for Performance Up-Front" que hace una reflexión muy interesante. Pego y traduzco:

If a user clicks a button and the application crashes, it's a problem. If a user clicks a button and the application takes 5 seconds to respond when it should be unnoticeable, it's a problem. It's the same problem.

Si un usuario hace click en un botón y la aplicación da error, es un problema. Si un usuario hace click en un botón y la aplicación tarda 5 segundos en responder cuando ese tiempo no debería notarse, es un problema. Es el mismo problema.

Parallel Extensions es un framework de Microsoft, aún en desarrollo para facilitar el desarrollo de aplicaciones concurrentes. Recientemente acaban de sacar la primera CTP (comunity tecnology preview) que está disponible para descarga y han solicitado feedback y comentarios en sus foros.

El funcionamiento es el común de una biblioteca, pero la implementación incorpora optimizaciones para mejorar el rendimiento de las aplicaciones multihilo liberando al programador de la tarea. Internamente se encarga de "decidir" si un trabajo debe ser ejecutado en un hilo separado o si se debe ejecutar en el propio hilo que invoca la llamada. Internamente está organizado en una serie de hilos, parecido al thread pool de .NET pero con ciertas optimizaciones, ya que existen una serie de colas internas en las que se insertan los trabajos (es algo más complicado que eso pero baste la simplificación), permitiendo que determinados hilos se "roben" las tareas entre ellos para mejorar la ocupación general de la CPU y por tanto el rendimiento del programa.

Hace bien poco he leido un interesante artículo (en inglés) llamado "The empty try block mystery" que describe algunas secciones de código presentes en el código fuente del .NET Framework y que son similares a lo siguiente:

y que responde a la pregunta ¿porque diablos iba alguien a declarar un bloque try finally estando el try vacío? Pues vamos a explicarlo, en español ;)