Espero que os sirva

Estoy muy orgulloso de lo que vamos a hacer con Windows Azure - va a permitir un montón de nuevos escenarios para los desarrolladores. En los próximos meses voy a hablar un montón sobre esto – veremos lo que ofrece y cómo podemos aprovecharlo.

Charla de Windows Azure

Ántes de vacaciones hicimos un evento especial “Learn Windows zure”. Tenéis disponible una grabación de la charla que dí. Son unos 90 minutos hablando sobre Windows Azure, en la que vemos qué es y cómo funciona, y enseñamos un montón de demos y código sobre cómo programarla. Podéis ver la charla online, descargar las slides y los ejemplos:

En las próximas semanas y meses blogearé más, conoceremos más profundamente Windows Azure y veremos qué podemos hacer, y además aprenderemos a usarla.

Espero que sirva.

Scott.

Traducido por: Juan María Laó Ramos.

Artículo original.

Lo cierto es que a todos nos pasa, al menos a mi y termino escribiendo cosas como:

for (int i = 0; i < 100; i++) {
if (i == 42) { hagoAlgo(i); }
}

Lo más normal es haber escrito:

hagoAlgo(42);

Este anti-patrón tiene muchas formas. Por ejemplo:

foreach (string filename in Directory.GetFiles(“.”))
{
if (filename.Equals(“desktop.ini”, StringComparison.OrdinalIgnoreCase))
{
return new StreamReader(filename);
}
}

Buscamos el archivo que se llame “desktop.ini” y devolvemos el stream, sip, cuando lo más natural, una vez visto esto, es haber escrito algo así:

if (File.Exists(“desktop.ini”))
{
return new StreamReader(“desktop.ini”);
}

Por favor, tomémonos las cosas con más calma que luego pasa lo que pasa.

El problema es que esto es sólo una parte del código, si sumamos todas las “patochadas” que hacemos sin pensar resulta que tenemos un proyecto lleno de cosas como esta y terminamos preguntándonos ¿esto lo he hecho yo?. Pero aún peor cuando un compañero o tu mismo jefe ve este tipo de cosas.

Desde aquí pido mis más sinceras disculpas por escribir este tipo de cosas.

Y es que no me doy ni cuenta y llamo a esta forma de programar JITO (“Just In Time Obfuscation”).

Espero que os sirva.

Juan María Laó Ramos.

En otras palabras: debemos tener al menos una frecuencia de muestreo del doble de aquella frecuencia más alta de la señal origen.

Esto nos deja dos formas de evitar el aliasing:

1. Aumentar la frecuencia de muestreo
2. Tener menos detalles de la señal de entrada:

a) Suavizar (a.k.a. blur) la señal de entrada para eliminar las frecuencias altas.

b) Suavizar (a.k.a. filter) al vuelo a medida que vamos tomando las muestras.

La opción 2.a se suele aplicar como preprocesamiento, haciéndolo muy eficiente. Pero no es buena idea cuando necesitamos muestrear datos a diferentes frecuencias dependiendo de la situación (por ejemplo las texturas necesitan escalarse dependiendo de la distancia de la camara). Si pre-suavizamos la señal de acuerdo a la frecuencia más baja nunca podremos reconstruirla, el resultado será demasiado borroso cuando la reconstruyamos a altas frecuencias. Y si pre-suavizamos a alta frecuencia, tendremos problemas de aliasing cuando la reconstruyamos a baja frecuencia.

La opción 2.b se puede ajustar dinámicamente a la frecuencia, pero es muy costosa de implementar.

Una tercera opción es asumir que todo es digital y no entrar en esto. En algunas situaciones  es posible trabajar sólo con ecuaciones matemáticas, transformando una señal en otra aplicando transformaciones matemáticas a las ecuaciones que las describen. Esta solución evita de manera inherente la solución digital, evitando así producir cualquier aliasing, pero las matemáticas se vuelven muy complejas. No suele usarse esto, pero muchos renderizadores offline lo usan como RenderMan.

Bueno, ya está bien de teoría. En el próximo post veremos algo de práctica.

Juan María Laó Ramos.
Artículo original

Aquí tenéis la traducción:

Inspirado por una serie de twitts:

Scionwest- @shawnhargreaves @nickgravely Cómo va el post procesado en WP7? He visto a gente hacer efectos de Bloom y eso no es parte de WP7?

nickgravelyn – @Scionwest Los shaders no están disponibles, pero he visto ejemplos de post procesado muy inteligente con custom shaders. Teóricamente puedes hacerlo basándote en la CPU, pero también puedes usar blend states para conseguir efectos increíbles.

(Es un tema muy interesante y algún día volveré a él).

Me encontré a mi mismo pensando “bueno, seguro que puedes implementar bloom,ya que  el subconjunto de gráficos Reach de Windows Phone son Turing complete, así que podríamos hacer lo que queramos con el suficiente ingenio. Puede que no se fácil, eficiente o con sentido, pero todo es posible…”

Así que pensé ¿es realmente posible?

Podemos sumar y restar a traves de blend states, y realizar comparaciones con AlphaTestEffect, lo que parece ser suficiente para permitir crear algoritmos arbitrarios (al menos si ignoramos cosas mundanas como el tiempo y el espacio ¿Pero puedo “probar” que XNA en Windows Phone es suficiente para permitir una computación en la GPU Turing complete?

El juego de la vida de Conway ha probado ser una forma universal de máquina de Turing, así que me puesto a ver si puedo implementarlo en la GPU sin usar custom shaders.

A partir de la plantilla de Game por defecto, he declarado dos rendertargets para que mantengan el estado de la simulación:

    const int width = 256;
    const int height = 128;

    RenderTarget2D currentState;
    RenderTarget2D nextState;

Además otros dos objetos de ayuda:

    AlphaTestEffect alphaTestEffect;

    Texture2D singleWhitePixel;

Estos objetos los inicializo en el LoadContent:

    currentState = new RenderTarget2D(GraphicsDevice, width, height, false, SurfaceFormat.Color, DepthFormat.Depth24Stencil8);
    nextState    = new RenderTarget2D(GraphicsDevice, width, height, false, SurfaceFormat.Color, DepthFormat.Depth24Stencil8);

    alphaTestEffect = new AlphaTestEffect(GraphicsDevice);

    singleWhitePixel = new Texture2D(GraphicsDevice, 1, 1);
    singleWhitePixel.SetData(new Color[] { Color.White });

Para hacerlo más interesante, el juego de la vida debe ser inicializado a algo más que simples ceros. Este código (al final del LoadContent) hace una inicialización de los datos iniciales:

    Color[] initialData = new Color[width * height];

    initialData[3 + 1 * width] = Color.White;
    initialData[3 + 2 * width] = Color.White;
    initialData[3 + 3 * width] = Color.White;
    initialData[2 + 3 * width] = Color.White;
    initialData[1 + 2 * width] = Color.White;

    currentState.SetData(initialData);

Para un estado inicial más interesante, añadimos esto (ántes de la llamada currenState.SetData) para aleatorizar las células:

    Random random = new Random();

    for (int i = 0; i < 10000; i++)
    {
        initialData[random.Next(width * height)] = Color.White;
    }

El código del Draw es simple. Usa SamplerState.PointClamp para escalar el estado de la simulación ha pantalla completa, sin ningún filtro:

    SimulateLife();

    GraphicsDevice.Clear(Color.CornflowerBlue);

    spriteBatch.Begin(SpriteSortMode.Deferred, null, SamplerState.PointClamp, null, null);
    spriteBatch.Draw(currentState, GraphicsDevice.Viewport.Bounds, Color.White);
    spriteBatch.End();

Vale, esa era la parte repetitiva. Ahora ¿cómo vamos a implementar el método SimluateLife()? La wikipedia define las reglas como:

• Cualquier célula viva con menos de dos vecinos muere, está despoblada.
• Cualquier célula viva con dos o más vecnios vive hasta la próxima generación.
• Cualquier célula viva con más de tres vecinos muere, como si fuese por superpoblación.
• Cualquier célula muerta con exáctamente tres vecinos se convierte en célula viva, se reproduce.

Pero he creido conveniente reagruparlas de manera diferente pero equivalente:

• Regla 1: Si hay dos vecinos vivos, se mantendrá el estado actual de la célula.
• Regla 2: Si hay tres vecinos vivos, la célcula revive.
• Regla 3: En otro caso la célula se muere.

Ok, vamos a hacerlo, SimluateLife comienza dibujándose en le renderTarget nextState, y seteando el AlphaTestEffect para que sólo acepte píxeles con un alpha mayor de 128, por ejemplo: las células que están vivas:

    GraphicsDevice.SetRenderTarget(nextState);

    GraphicsDevice.Clear(Color.Transparent);

    Viewport viewport = GraphicsDevice.Viewport;

    Matrix projection = Matrix.CreateOrthographicOffCenter(0, viewport.Width, viewport.Height, 0, 0, 1);
    Matrix halfPixelOffset = Matrix.CreateTranslation(-0.5f, -0.5f, 0);

    alphaTestEffect.Projection = halfPixelOffset * projection;

    alphaTestEffect.AlphaFunction = CompareFunction.Greater;
    alphaTestEffect.ReferenceAlpha = 128;

Vamos a contar cuantos vecinos vivos tiene cada célula, acumulando este valor en un buffer (que se había limpiado con zeros). Hacemos esto dibujando la textura de simulación 8 veces, desplazando un pixel arriba a la izquierda, arriba, arriba y derecha, izquierda, etc. Usamos un blend state que prevenga de dibujar nada al buffer de color, ya que sólo estamos interesados en la generación de símbolos. Este código combina el AlphaTestEffect (que elimina los pixeles de los vecinos muertos) y el buffer de símbolos (que cuenta cuantos vecinos han pasado el test del alpha):

    spriteBatch.Begin(SpriteSortMode.Deferred, blendNone, null, stencilAdd, null, alphaTestEffect);

    spriteBatch.Draw(currentState, new Vector2(-1, -1), Color.White);
    spriteBatch.Draw(currentState, new Vector2( 0, -1), Color.White);
    spriteBatch.Draw(currentState, new Vector2( 1, -1), Color.White);
    spriteBatch.Draw(currentState, new Vector2(-1,  0), Color.White);
    spriteBatch.Draw(currentState, new Vector2( 1,  0), Color.White);
    spriteBatch.Draw(currentState, new Vector2(-1,  1), Color.White);
    spriteBatch.Draw(currentState, new Vector2( 0,  1), Color.White);
    spriteBatch.Draw(currentState, new Vector2( 1,  1), Color.White);

    spriteBatch.End();

Este código usa dos objetos de estado:

    static readonly BlendState blendNone = new BlendState
    {
        ColorSourceBlend = Blend.Zero,
        ColorDestinationBlend = Blend.One,

        AlphaSourceBlend = Blend.Zero,
        AlphaDestinationBlend = Blend.One,

        ColorWriteChannels = ColorWriteChannels.None,
    };

    static readonly DepthStencilState stencilAdd = new DepthStencilState
    {
        DepthBufferEnable = false,
        StencilEnable = true,
        StencilFunction = CompareFunction.Always,
        StencilPass = StencilOperation.Increment,
    };

Ahora tenemos nuestro rendertarget limpiado a cero (lo que significa que están todos muertos, así hemos implementado la tercera regla), mientras que stencil contiene un contador de las celdas vecinas vivas. Ahora vamos a dibujar una copia del estado de la simulación, usando la galería de símbolos para aceptar sólo aquellas células que tengan a dos vecinas vivas, implementando así la regla 1:

    spriteBatch.Begin(SpriteSortMode.Deferred, BlendState.Opaque, null, stencilDrawIf2, null);
    spriteBatch.Draw(currentState, Vector2.Zero, Color.White);
    spriteBatch.End();

El último pintado implementa la regla 2 renderizando en blanco (lo que significa que está vivo) aquellas células que tienen 3 vecinos:

    spriteBatch.Begin(SpriteSortMode.Deferred, BlendState.Opaque, null, stencilDrawIf3, null);
    spriteBatch.Draw(singleWhitePixel, viewport.Bounds, Color.White);
    spriteBatch.End();

Son necesarios dos objetos de estado:

    static readonly DepthStencilState stencilDrawIf2 = new DepthStencilState
    {
        DepthBufferEnable = false,
        StencilEnable = true,
        StencilFunction = CompareFunction.Equal,
        ReferenceStencil = 2,
    };

    static readonly DepthStencilState stencilDrawIf3 = new DepthStencilState
    {
        DepthBufferEnable = false,
        StencilEnable = true,
        StencilFunction = CompareFunction.Equal,
        ReferenceStencil = 3,
    };

Finalmente, la función SimulateLife quita el rendertarget, intercambia los dos rendertargets, reemplazando el estado actual con el nuevo que hemos calculado:

    GraphicsDevice.SetRenderTarget(null);

    Swap(ref currentState, ref nextState);

La función Swap es tan simple como:

 static void Swap<T>(ref T a, ref T b)
    {
        T temp = a;
        a = b;
        b = temp;
    }

¿Ha funcionado?

Chachán!

Traducido por: Juan María Laó Ramos

Artículo original.

• La macro assert llama a abort cuando ocurre una aserción.
• Por defecto, la función terminate llama a abort.

El estándar de C++ indica las condiciones bajo las que se llama a terminate, es una lista muy larga y no vamos a repetirla aquí. Para ver esa lista consulta tu copia favorita de estándares de C++ para verla. (la razón más común para este problema es que se ha lanzado una excepción y no se ha capturado).

Lo tenéis disponible en Desarrolloweb.com.

El índice completo lo podéis encontrar aqui.

Espero que os sirva.

Juan María Lao Ramos.

Dado un LCID en particular, ¿cómo podríamos saber dado un lenguaje determinado si se escribe de izquierda a derecha o de derecha a izquierda?

Una primera cosa que se nos podría ocurrir  es “hard-codear” la lista de los lenguajes que se escriben de derecha a izquierda, y si el lenguaje que nos interesa no está en la lista asumir que se escribe de izquierda a derecha. Esta técnica es muy frágil, ya que Windows va añadiendo soporte a nuevos lenguajes de forma regular, y si uno de esos es de derecha a izquierda, nuestra tabla se quedará desactualizada. Y además, hay lenguajes que no se escriben de ninguna de esas maneras. Por ejemplo, el chino y el japonés se escriben de arriba abajo.

Para saber programáticamente en qué direccion se escribe un lenguaje, llamamos a GetLocaleInfoEx con LOCALE_IREADINGLAYOUT.

Y ahora sólo toca esperar a que a nadie se le ocurra crear un lenguaje a base de palíndromos .

Juan María Laó Ramos.

La actualización MS11-100 está disponible a través de Windows Update, del Windows Server Update Service y como descarga en el centro de descargas de Microsoft.

La actualización resuelve un problema que permite realizar ataques de denegación de servicio (DoS) presente en todas las versiones de ASP.NET. No se han detectado ataques en ninguno de nuestros clientes usando este exploit, pero recomendamos que se aplique la actualización lo antes posible.Más sobre el problema de seguridad.

El 28 de Diciembre de 2011, en una conferencia sobre seguridad se describió un nuevo método para modificar las estructuras de datos de las tablas hash en frameworks web. Los ataques sobre este tipo de vulnerabilidad son conocidos como “hash collision attacks” (ataques de colisión hash).

Estos ataques intentan calcular una tabla hash en servidores con un gran número de elementos cuyas claves devuelven el mismo hash. Estas colisiones de claves reducen significativamente el rendimiento de las operaciones de la tabla hash, y con los suficientes elementos el servidor puede tardar minutos (incluso horas) en resolverlos. Esto bloquea el servidor web y no atiende a las peticiones de los usuarios, resultando en una denegación de servicio (haciendo que el sitio web se vuelva lento y no responda).

Estos ataques no son específicos de un lenguaje particular ni de un sistema operativo. Los ponentes en la conferencia mostraron cómo hacerlo usando peticiones HTTP sobre diferentes frameworks (incluido ASP.NET). Como estos ataques generar incidencias de denegación de servicios con pocas peticiones HTTP, hay una gran probabilidad de que sucedan estos ataques. Recomendamos a nuestro clientes que apliquen la actualización lo más pronto posible.

La actualización se publicó ayer 29 de Diciembre, con esta actualización no se podrán realizar este tipo de ataques. No habrá que modificar ninguna aplicación tras la actualización.

Aprende más

Podéis aprender más sobre esta vulnerabilidad en el Microsoft Security Advisory (2659883).

Si tenéis alguna pregunta sobre la vulnerabilidad o algún problema con la actualización, podéis postear vuestras preguntas en el foro de Security Vulnerability del sitio www.asp.net.

Para tener la última información, podéis seguir el twitter del equipo MSRC en @MSFTSecResponse.

Espero que sirva.

Scott.

Traducido por: Juan María Laó Ramos.

Artículo original

La cosa es que ya no podemos modificar las propiedades Volume ni IsMuted cuando lo que se está reproduciendo es contenido de Zune. Estos cambios han sido necesarios para que una aplicación no interfiera con la experiencia de reproducción de música (ya que Zune no tiene elementos en la interfaz gráfica para modificar el volumen ni para desactivarlo).

Podemos ver estos cambios usando sólo el emulador. Si ejecutamos el siguiente código, veremos que los valores asignados a Volume y IsMuted son ignorados mientras se está escuchando la música:

MediaPlayer.Play(new MediaLibrary().Songs);

MediaPlayer.Volume = .5f;

MediaPlayer.IsMuted = true;

Debug.WriteLine(“Volume: {0}, IsMuted: {1}”, MediaPlayer.Volume, MediaPlayer.IsMuted); 

Output:

Volume: 1, IsMuted: False

Este cambio afectará a aquellas aplicaciones que reemplacen al reproductor de Zune, para aplicaciones y juegos que reproducen su propia música hay un efecto colateral: Y es que como el usuario puede estar escuchando música cuando el juego arranca, si modificamos las propiedades de Volume y IsMuted en la música del juego, esos cambios serán ignorados.

Por ejemplo, un patrón común a la hora de reproducir sonidos puede ser como el código siguiente en el que cargamo el sonido, seteamos las propiedades y reproducimos el sonido:

Song song = Content.Load<Song>(“BackgroundMusic”);

MediaPlayer.Volume = 0.5f;

MediaPlayer.Play(song);

Teniendo esto en cuenta, lo que debemos hacer para poder modificar las propiedades de la música en nuestros juegos es reproducir primero, y modificar las propiedades después, asegurándonos así que esos cambios se van a aplicar a nuestros sonidos

Song song = Content.Load<Song>(“BackgroundMusic”);

MediaPlayer.Play(song);

MediaPlayer.Volume = 0.5f;

Si seguimos este patrón, nos aseguraremos evitarnos este “problemilla”.

Juan María Laó Ramos.