Ya se puede descargar el primer service pack para el visual studio 2008, aunque hay problemas con Expression Blend y el sdk del Silverlight.

 A parte de muchas mejoras para el entorno de programación orientado a bases de datos y desarrollo web, tenemos mejoras en el MFC, con componentes tipo office (me surge la duda de si incluye el feature pack del que hablamos ayer). Se ha mejorando el trabajo en equipo, con más opciones para el servidor de control, de gestión de proyecto, etc.  De todos modos,  la mayoría de las mejoras son para .net, ado, diseñador de formularios, etc.

 Este es el sitio oficial de microsoft sobre el vs2008 sp1.

La siguiente familia de procesadores de intel se llamará Nehalem . Entre sus características principales está la inclusión de los controladores de memoria integrados, que permitirán comunicarse con la memoria más eficazmente en un entorno de hasta 8 cores (dispondrá de hasta 4 canales directos para acceder a la memoria), a parte de ser el fin del FSB, para entrar en el nuevo sistema QuickPath para conectar los dispositivos con el procesador. Tambien estoy leyendo que podrá ejecutar varios hilos por ciclo en cada core, ya que retoma el concepto de hypherthreading. El resultado tendremos que verlo a finales del 2008 para la gama alta, y durante el 2009 par la gama doméstica.

Ya se ha anunciado el chipset que soportará esta nueva familia de procesadores, el intel X58, que soportará tripe canal DDR3, y hasta cuatro tarjetas PCIe 2.0... todo un bicho del multiproceso.

 Gracias a la lista de correo de codepixel, os pongo este enlace en la web sobre novedades de MFC .

 Se trata del Feature Pack 2008 que actualiza las MFC con novedades interesantes de GUI. Entre ellas destacamos los menus de tipo Office, las tab windows que podemos encontrar en programas como el Visual. En general, la lista de mejoras de MFC es bastante extensa y merece la pena echarle un vistazo para mejorar los guis realizados con esta librería (muchos de esos controles sólo estaban disponibles a traves del .net)

 Tambien tenemos un par de videos relacionados. Este nos trata sobre el Tech Report 1 de c++ , que son novedades que microsoft va a incluir en el futuro  (como tablas hash, y smart pointers). Se trata de una especie de boost, que se llamará tr1 (de echo, hay cosas como tr1::smart_ptr ). El tipo no dejar de parecen un friki algo flipadillo, sobre todo con esa lata en la mano...

 En este otro , se nos habla de las novedades que podremos ver el en visual 2008, en el Feature Pack que nombramos.

 A mi continuamente me asaltan dudas de que librería utilizar para hacer un GUI. Que las MFC tengan este tipo de mejoras (supongo que vendrá el codigo fuente incluido) me parece muy positivo. Otra cosa es intentar hacerle competencia a la boost... creo que cosas como el boost::shared_ptr deberia de entrar en el standard lo antes posible.

 Hay varios movimientos actualmente en el mundo de la copia privada de contendio. Y bastante contradictorios.

 Empresas como electronic arts, que saca el battlefield heroes gratuitamente, va a hacer más esfuerzos en comprobar online la validez de los videojuegos Se van a comprobar cada 5 dias, y además, solo dejará reinstalarlo 3 veces, para que no puedas revenderlo. Nada menos.

 Por otro lado, los representantes de derechos online de medio mundo parece que no han dado todavía al DRM por muerto . Eso sí, quieren cambiar alguna cosa, pero no dicen nada concreto, solo que debe de ser "transparente" al usuario para que este no se entere.

 Eso sí, el DRM para los demás, porque estos días la comunidad de artistas está revuelta con la nueva ley de propiedad intelectual , que permite usar cualquier contenido online si es "imposible" encontrar al autor. Y esto incluye a las corporaciones, que podrán usar fotos que encuentren en internet o cualquier cosa que encuentren sin estar debidamente registrada. Ahí es nada.

 O sea, que lo que quiere el mundo es que si tienes abogados potentes, puedas vivir de los derechos, y si no, aprovecharte de todo lo que hay en internet para vender. Porque si la musica no se pudiese descargar gratis... habría tantos reporductores de mp3 en el mundo? el mercado sería tan grande?

  Es un tema de todos modos, espinoso. Porque sólo los grandes sacan ventas de sus juegos. Los demás, a fabricar gratis la mayoria de las veces.. y eso es, al menos, insostenible.

Los chicos de la empresa Corsair, que fabrica y vende memorias, han sacado un estudio realmente impactante . Han medido el rendimiento de un ordenador con 2Gb y otro con 4Gb... y han "descubierto" que es más rápido. Vaya! quién lo diría? Y yo que pensaba que lo de la memoria estaba resuelto con meter más disco curo y un pen usb "turbo"

  Las estadisticas son demoledoras: el cambiar de tarea va 11 veces más rápido! carai! han descubierto que la memoria virtual es más lenta que la ram!

  Lo curioso es que el crysis corre a la misma velocidad! no se si será igual de rápido, o igual de lento... porque parece que el crysis engulle recursos de forma brutal.

 De todos modos, echadle un ojo porque al menos explica cosas de cómo funciona el win64 en la gestión de meoria (algo por encima) y siempre puede ser interesante, a part, un benchmark es un benchmark :)

Echadle un ojo a esta librería para opengl . Simplifica cosillas que siempre son tediosas, como cargar niveles del quake y demás.

Leyendo la documentación, parece bastante sencilla.  Más o menos soporta las clases base de un motor de render simple: camaras, luces, objetos pintables, un minimo soporte para GPU y shaders, etc. Esta librería puede ser util para comprender una implementación simple del tutorial de driver gráfic o que publicamos en codepixel hace poco tiempo.

De todos modos, una clase como RenderList:sorter, en una implementación que se dedica a pintar, no lo acabo de ver...

Leyendo los futuros papers que están aceptados para siggraph, me he fijado en este sobre las sombras suaves para tarjeta. El paper es bastante matemático, y se basa principalmente en utilizar "convolution shadow maps". Mirandolo así sin entrar en detalle, el algortimo hace un blur al shadow map usando un filtro, una convolución (de ahí el nombre Convolution shadow map o CSM). El problema es calcular el radio de ese filtro, que depende de la distancia de lo que oculta la luz. El problema se complica porque pueden existir varias cosas que bloqueen el objeto. Asi que intentamos calcular una distancia media de los objetos, sampleando varios shadow map y filtrando el resultado. El paper explica cómo realizar esos cálculos.

 El paper usa mapas de entorno HDR para iluminar. Se explica una forma de descomponer un cube map en distintas area lights, de donde iremos generando los shadow maps para iluminar. Asi que podremos usar esta tecnica para una iluminación muy suave.

 La técnica es costosa de desarrollar, pero rápida de renderizar en una tarjeta. Tiene fallos, pero son los comunes en estos algoritmos (por ejemplo, se considera que la distancia de los "bloquers" son constantes para todo el filtro del shadow map).

Acabo de escribir esto en linkedin, a la respuesta de "qué hace que un proyecto salga correctamente (en inglés). Os lo pongo aquí a ver que os parece.

By far... robustness is KEY for a success project. And robustness is hard to predict in advance, the project needs some experience and feedback.

I assume that you are the real leader of the team, not only the supervisor... my top ten list (in no special order):

1) A process cannot be implemented if the process is not well defined previusly. So, the process and production pipeline should be tested as soon as possible. You will need an expert in the process that you will implement.

2) Develop with facts, not with with abstract ideas. Software arquitects enjoy desinging very common classes, extensible, etc, but they forgot the target soon. So, the interface/methods/etc should be as much realistic as possible.

3) Many small pieces with simple task. At the end, everything goes to linux philosophy... If the pieces are easy, any programmer will be able to optimize that piece, and he will understand it soon. It is hard to get huge robust applications, but it is easy with small code. Complex solution are signals of weak engenieer skills.

4) Be ready to kill your babies. If facts tell you that the key ideas are wrong... they are wrong. If facts are telling you that it is complex, then simplify it.

5) A robust system is the result of a long term process. It must be tested, and the team must be ready to identify what is going bad and well. A couple of days using the system is NOT a test. Only under pressure, a pipeline and a project will be really tested. Dont try to improve the system if you didnt test it before under pressure. If your system works under pressure, it is a complete success, and users will love the solution, because they will need it to solve their problems.

6) Always, always, always you will find many ways to develop the same thing. Facts will tell you which one is better.

7) Refactoring must be done AFTER the process has been tested. There is nothing bad in a 2.0 version, doing exactly the same that the previus one, but designed with all the requisites really clear.

8) "it works" is only a part of the answer. You should ask: how much time do I need to change it? how many resources do i need to mantain the code? how much time in documentation? how much time in user training? is the release time long? If your software "works" but users need huge training, and a big manual, you are wasting their time.

9) Everybody in your team must understand the process. Everybody must understand where are the key issues, so, they will pay more attention to the key parts of your code. They will help the project with ideas, because, they know the process better than nobody else.

10) "In theory" is not enough. Reallity is always more complex, and under pressure, users and delevelopers have not time to waste with your system. So, hacks appear everywhere, bypassing the "theory". It always happens, so, be ready for that.”

En este enlace podremos hacer un seguimiento de los trabajos que se presentarán en el próximo siggraph 2008. La mayoria no tienen enlace todavía, pero no os preocupeis, porque intentaré ahcer un seguimiento en codepixel de las novedades más interesantes (al menos en cuanto a iluminación global).

 Multidimensional Adaptive Sampling and Reconstruction for Ray Tracing tiene un titulo interesante, además, los investigadores tienen un buen background y buenos profesores en la materia.

  Quizas de Modeling Anisotropic Surface Reflectance with Example-Based Microfacet Synthesis podramos sacar un nuevo tipo de shader anisotropico.

Los chicos de NVIDIA están publicando que la CPU está muerta, y que el futuro es de las GPU´s. Bueno, tenemos que enmarcar todo esto en el entorno de la batalla nvidia/intel/amd. La realidad parece ir por ese camino, con gpu´s cada día más vectoriales y más potentes. Desde luego, ahora mismo nvidia tiene una posición muy dominante en el mercado, y la competencia va a tardar tiempo y dinero en conseguir disputarle el trono.

 Pero podemos afirmar que el futuro será así? Pues yo creo que no. AMD y ATI lo están pasando mal, y tienen unos problemas serios de financiación, y hay dudas por la solvencia de la empresa a corto plazo. Pero el caso de intel es bastante distinto. Intel está tambien muy fuerte, con unos buenos resultados y una plantilla que ya ha sufrido los recortes previos a la crisis. Ahora mismo, es una máquina de generar dinero.

 Intel tiene conocimiento y músculo para fabricar chips de forma masiva, que es lo que el mercado de consumo necesita. NVIDIA podrá sacar muchas GPU´s, pero apostaría a que Intel los fabrica más baratos y a mayor ritmo. Y al final, intel ha ganado la batalla de los dual/quad core precisamente por esa ventaja.

 Pero la batalla que creo más prometedora para Intel es la de la fusión CPU/GPU. Intel puede hacer varias cosas que le den mucha ventaja frente a nvidia. Por ejemplo, en el tema de la sincronización. Intel puede hacer instrucciones para sincronizar datos en la GPU sin pasar por el bus de datos, etc. Tambien puede hacer sistemas para que el "scheduler" del sistema operativo tenga en cuenta de forma más optima el proceso de la GPU. Por no hablar de la posibilidad de unir vía hardware el proceso de GPU/CPU.

Realmente no sé lo que quiere decir nvidia con lo de que la cpu está muerta. Sólo lo entiendo como una forma de desprestigiar a Intel, pero lo que creo que acabará pasando es que aparezca el coprocesador vectorial, en general, y esto puede ser más factible de la mano de intel que de nvidia.

En gamedev han puesto una noticia a este motor de terrenos 3D , que ahora tiene soporte para directx 9. Lo potente es que usa "clipmaps" para mostrar texturas enormes en pantalla (fundamental en simuladores de vuelo). Los clipmaps se basan en que una textura, por muy grande que sea, se va a ver como máximo el tamaño de la pantalla. Por loq ue no es necesario cargarla entera en memoria. Tambien tiene algo muy importante para un motor 3D, las herramientas para exportar/importar y poder incluirlo en un pipeline de producción. A esto le añadimos renderizado de agua, y de hierba y que está disponible para la xbox360.

Estaba leyendo un libro de intel sobre optimización, sobre cómo optimizar los procesos aprovechando el multicore. Y se plantea una pregunta:

"cuál es la mejor forma de paralelizar un compresor de gzip? podemos hacer que cada thread comprima una parte del fichero, o que cada thread abra un fichero?"

 Dicho así, no me parece sencillo de responder de forma obia. Una forma de sacar una conclusión es llevar el tema al extremo. Pensemos, por ejemplo, qué pasaría si tenemos 5000 threads? La segunda opción se vuelve un poco más complicada, porque nuestro programa intentaria abrir instantáneamente 5000 ficheros, y el sistema operativo sufriría un fuerte golpe en rendimiento.

   Esto me hace pensar en la metodología de llevar al extremo las cosas. Sobre todo, porque en el mundo de la animación, haciendo una película, normalmente el extremo es lo normal. Tenemos millones de polígonos, millones de rayos, millones de texturas, millones de pelos, millones de ficheros, etc. Si existe algun cuello de botella, o si existe algun punto abierto a desbordarse, probablemente lleguemos a encontrarlo pronto. Suele ser cuestión de tiempo que lleguemos al extremo de las cosas.

 En la empresa,  este suele ser una buena receta para el desastre. Muchas veces el chavalín de turno se curra un script que, en laboratorio, y con medidas controladas, funciona correctamente, pero cuando "entra en producción", puede crear muchos problemas. Producción es el ejemplo de llevar todo al extremo. 

   Por cierto, otro sitio donde encontré este mismo razonamiento fue el último libro de Alan Greenspan, hablando sobre economía. Él lo utiliza para saber si una reforma o una nueva regulación puede ser bueno. Reducir los impuestos es bueno? preguntémonos qué pasa sin impuestos. Reducir la regulación es bueno? preguntémonos qué pasa sin regulación... y este tipo de pensamientos nos ayudará a razonar mejor y sacar conclusiones más claras.

 Los precios afectan al quadcore Q6700 para uso doméstico de tecnología 65nm, que corre a 2,6Mhz con 4MB de cache L2 y un bus de 1066 MT, que pasa de unos $500, a $266. Para el que esté perdido, este es el micro de los primeros quadcores que salieron, no los más modernos de 45nm que es la serie Q9000, y un bus de 1333MT. Por ejemplo, el moderno Q9300 vale también $266, es de 45nm, pero tiene menos cache (3Mb). Aunque por un poco más ($316) tenemos el Q9450 que tiene 6Mb de cache.

  En servidor, el Xeon 3085 dualcore a 3Ghz de 65nm baja el precio a los $188. Este es el más caro de la antigua gama conroe.

  Otro que baja es el Core 2 Duo E6850 a 3.00 GHz (4 MB L2, 1333 MHz FSB). Este es el dualcore de 65nm para escritorio más potente, quedando en $183

  Por abajo, en la gmaa económica, El Celeron Dual E1200 queda en unos $45. El Dual core E2200 en unos $65. Estos son versiones para gama baja, con menos cache y velocidad que el resto.

  Aparecen modelos para el Dual Core, el E8300 con 8Mb de cache, a 2,8Ghz, por $163, y el  E7200 con 3Mb de cache y 2,5Ghz, por $133.

  Vamos, que hay procesadores bastante potentes en toda la gama de precios, sobre todo para quien queira comprar un dual core o un celeron (en quadcore no veo que tengamos tantas ventajas ya que los nuevos Q9000 son grandes micros).  Aunque de todo esto, tendremos que ver cuanto queda en euros. 

El mar muerto es un inmenso lago que recibe el agua del rio Jordan. El lago no se desborda porque pierde agua mediante evaporacion. La unica forma que tiene el agua de salir es mediante evaporacion, ya que no tiene salida a otro mar. Siglos y siglos de evaporacion, fueron dejando atras las sales que el rio introduce en el mar, multiplicando la salinidad. La vida es imposible en ese mar, excepto en determinados momentos, cuando grandes lluvias meten mucha agua dulce, y permite alguan forma de alga, pero solo temporalmente.

 He leido un articulo que habla de ese efecto en las empresas de tecnologia cuando crecen. En principio los programadores y la gente cualificada se trata a todos por igual, y los procedimientos son identicos para todos. Pero la realidad es que no todos son iguales. Los buenos profesionales suelen serlo porque disfrutan de lo que hacen, y tienen muchas ganas de hacer cosas. Y suelen ser los que reciben buenas ofertas para cambiar de empresa, para mejorar en su carrera, etc. En las empresas grandes, .la burocracia, los procedimientos, y sobre todo, el status quo imperante, impiden que los buenos puedan desarrollarse. Asi que poco a poco, en la empresa se evaporan los mas dinamicos, y quedan los que se acomodan mejor a la empresa, a losporcedimientos, etc. Asi, los problemas de la empresa suelen empeorar, ya que los que quedan son los mas pesados, y los que se van suelen ser los que le daban frescura. Al cabo de un tiempo, la empresa ha perdido vigor, juventud, vida, y queda un "mar muerto" incapaz de sacar tecnologia puntera y sobre todo, de atraer a nuevos talentos.

 No conocia que esto tuviese un nombre, pero realmente estuve pensando en una larga lista de empresas que conozco, y casi todas son hoy en dia "mares muertos". Empresas que ya casi nungun colega tiene en mente para ir a trabajar ahi dentro, y que suelen conseguir solo gente junior sin experiencia (que no es malo) pero que son incapaces de sacar a delante un proyecto que ilusione a la gente cualificada. Otras empresas estan en vias de conseguir algo parecido.

 Y hoy en dia, el mercado de profesionales realmente validos esta estrechandose.  Existe el fenomeno, cada vez mas asequible, de los cazatalentos, que usan redes como linkedin para buscar profesionales que quieren mejorar sus condiciones. Y esos cazatalentos se preocupan de que realmente mejores tus condiciones, porque ellos cobran mas si tu cobras mas. Con lo que es dificil para una empresa que un profesional muy valido, y con un minimo de aspiraciones, aguante un tiempo en la empresa.

 Por otro lado, cada dia cuesta mas encontrar gente cualificada. Hablando con responsables de varias empresas de animacion/programacion, vemos que el nivel de lo que llega es muy bajo. Solemos culpar de llo a la educacion, pero comienzan a escucharse voces de alerta sobre ese topico. Por ejemplo, hay que valorar si determinadas politicas de seleccion (listas enormes de requisitos tecnicos, experiencia en alguna tecnologia arcana, etc) no seran un primer filtro para perder muchas posibilidades. Tambien, es obio que ya no hay el desempleo que habia antes, sobre todo en la gente que tiene una experiencia y una capacidad demostrada, asi que "pescar" en la competencia, se vuelve cada dia mas necesario.

 Y por mucho que un departamento quiera auto convencerse de que no pasa nada cuando gente valida se marcha, que todo sale adelante, no es cierto. Pienso en algunas empresas que conozco, y creo que sera imposible para ellas alcanzar el nivel de otras, y por tanto, sera imposible que algun dia saquen ventaja, y la "burbuja" desaparecera. Puede que saquen el trabajo que tienen asignado, puede que mantengan los clientes que mantienen, o puede que continue el sistema que consiguio que alcancasen cierto nivel, pero sin profesionales con ideas y conocimientos profundos de lo que se debe de hacer, nunca se podra estar un paso por delante de los demas.

 Creo que el ejemplo es google. Es la gran esponja de profesionales del mundo. Sabes que si tienes a un megacrack en tu equipo, acabara llendo para alli si no lo cuidas con esmero. Y ellos han acabado con yahoo, estan fuertes en el resto de negocios, y mantienen beneficios mientras los demas lo pasan fatal.

 Por cierto, creo que esto no pasa solo en tecnologia. Creo que muchasgrandes organizaciones sufren de lo mismo. Se me viene a la mente la administracion publica. Por ejemplo, muchos chicos estan en la facultad hasta que aparece algo mejor, o mucha gente de la administracion se va a la privada si son realmente buenos... quien queda? los mas comodos con el sistema establecido... y asi funciona.

En este enlace , se nombran varios puntos que un buen programador debería de tener en cuenta a la hora de programar en equipo. Muchos son estéticos, pero interesantes a la hora de escribir código.

 Todos se pueden resumir en "escríbe código claro y facil de entender". No es ninguna novedad, pero muchas veces se olvida... se olvida?

 Yo creo que no se olvidan estos principios. Los programadores son por naturaleza, bien estructurados en la cabeza. Muchas veces, son (somos) dejadillos, es cierto, pero no se hacen hacks por gusto.

 La mayoría de los hacks surgen porque el sistema que usamos (librería, os, framework, lo que sea) tiene un límite de flexibilidad. Todo sistema acaba degenerando, irremediablemente. Siempre se le pide a un sistema algo para lo que no estaba diseñado, y los buenos programadores encuentran una forma de hacerlo que nadie había pensado antes (un hack). Al final, todo suele ser un gran hack, y esa es la señal clara de que hay que reescribir el sistema. Eso me ha pasado en innumerables ocasiones, y la mayoria de las aplicaciones/framworks que hay en las empresas han degenerado en algo asi, por el propio concepto de la empresa.

 Entonces, si tienes que pinchar código a una llamada que sabe dios cómo has encontrado, que te permite conectar tu sistema para que puedas meter eso que te han pedido... cómo vas a ser claro y conciso? cómo no va a ser todo un "rollo" que solo el programador conoce? donde estan los principios en ese caso?

 A mi siempre me ha gustado mas pensar en el "tao de la programacion ", algo dificil de explicar... quizas este pasaje os sirva para reflexionar:

El programador del Príncipe Wang estaba codificando. Sus dedos bailaban sobre el teclado. El programa compiló sin un mensaje de error, y el programa corrió como viento ligero.

"¡Excelente!," exclamó el Príncipe, "¡Tu técnica no tiene fallas!"

"¿Técnica?," dijo el programador, girándose hacia su terminal, "Lo que yo sigo es el Tao -- mas allá de toda técnica. Cuando al principio empecé a programar yo podía ver el programa completo en un bloque. Después de tres años ya nunca más vi ese bloque. En vez de eso, usé subrutinas. Pero ahora no veo nada. Todo mi ser existe en un vacío sin forma. Mi sentidos estan ociosos. Mi espíritu, libre para trabajar sin un plan, sigue su propio instinto. En resúmen, mi programa se escribe así mismo. Es verdad, a veces hay problemas y dificultades. Las veo venir, me freno, observo silenciosamente. Entonces cambio una sola linea de código y las dificultades se desvanecen como nubes de humo. Entonces compilo el programa. Me siento erguido y dejo que el gozo del trabajo llene mi ser. Cierro mis ojos por un momento y entonces cierro mi sesión."

El Príncipe Wang dijo, "¡Ojalá todos mis programadores fueran tan sabios!"