Para la mayoría de la gente, los programadores somos gente rara.
Ante el primer descuido nos encuentran trabajando a la madrugada.
Muchas veces el que nos ve trabajar no puede determinar si estamos paveando o a punto de descubrir una forma 300% más eficiente de realizar lo que nos encargaron.
Solamente a un programador le puede parecer que 256 es un lindo número redondo.

Hoy me encontré con este artículo y me pareció muy similar a como veo la forma de trabajar de un programador.

El artículo original se titula Don’t wake up the programmer! y está en inglés, así que lo traduje y lo posteo acá.

¡No despiertes al programador!

El trabajo de un programador es prácticamente soñar.

Suena gracioso, o simplemente errado, ¿no?

Bueno, si querés ponerte en los zapatos de un programador y comenzar a entender su trabajo desde adentro, este es un concepto que necesitas seguir: simplemente debés imaginar que el programador está durmiendo mientras trabaja.

El producto del trabajo de los programadores es un sueño, la visión de la noche de sueño, la fantasía.
El sueño está escrito en un lenguaje especial para que un aparato electrónico continúe su existencia cuando el programador está despierto o pasó a soñar otro sueño.

Lo normal es pensar que el programador simplemente toma una tarea o ejercicio, escribe algún programa y la tarea está solucionada. La verdad es que nunca funciona de esta forma.

Tomemos como ejemplo un laberinto:
El programador tiene la tarea de crear un algoritmo para encontrar la salida del laberinto. Cuando un programador esta trabajando en esta tarea, no es el dedo de dios señalándole el camino a una niñita perdida en un gran laberinto. Tampoco es la niñita, ni las paredes del laberinto. Para poder resolver la tarea el programador debe convertirse en el laberinto, las paredes del laberinto, la niñita perdida y todo lo demás que aparezca junto con la tarea. No es una forma de decir. El programador está -literalmente- durmiendo y soñando todo eso en su mente.

Cuando mirás trabajar a un programador efectivamente estas mirando a una persona dormir y soñar.

Continuá leyendo el resto de este post »

Hace unos días encontré un paper que explica como crear efectos de iluminación cáustica sobre objetos no brillantes.

Cáusticas:
Las cáusticas se forman cuando múltiples rayos de luz convergen en un mismo punto. Esto ocurre en presencia de objetos reflectivos o refractivos que causan que los rayos de luz se desvíen de su camino original de propagación y converjan en una región común.

Por lo tanto, para obtener cáusticas precisas, uno debe trazar los rayos de luz desde su origen y seguir sus caminos a través de las superficies refractantes y fuera de las superficies reflectivas.

Eventualmente los fotones se depositan en superficies cercanas difusas, llamadas recipientes, formando así las cáusticas.

El paper se titula "Caustics Mapping: An Image-space Technique for Real-time Caustics".

Es un pdf de 670KB, está en ingles (por supuesto) y los autores son Musawir Shah, Jaakko Konttinen y Sumanta Pattanaik.

El contenido esta realmente bueno. Está muy bien explicado y no utiliza un lenguaje extremadamente complicado.

En mi caso, hace por lo menos 2 años que no meto mano en un engine 3D moderno, e igualmente cacé la idea bastante rápido.

Algunos videos

Demostración de refracción debajo del agua.

A continuación mas videos y un análisis del algoritmo

Por regla general, el programador es muy hincha pelotas con la apariencia de su código.

Indentación: ¿Espacios o tabs? ¿Cuantos espacios o tabs?

Sintaxis: ¿La llave de comienzo de una función va en una nueva línea? ¿Formato camelCase o guión bajo?

Combinación de colores: ¿Fondo negro o blanco? ¿Comentarios que se destaquen o que apenas se vean?

El tema de la indentación y sintaxis lo dejo para otro post.

Para ayudar con la cuestión de la combinación de colores encontré un sitio muy útil:

Vim Color Scheme test.

Este sitio presenta mas de 300 paletas de colores para el editor de textos Vim (permite descargar el archivo de configuración de colores para ese programa) pero puede servir de modelo para configurar cualquier otro editor.

Las paletas de colores están divididas en dos grupos: fondo oscuro y fondo claro, y en cada grupo hay variantes de alto y bajo contraste.

Hay gente que usa fondo claro porque de otra forma termina con la vista destruida en pocos minutos, y otra gente jura y perjura que con fondo negro y letras verdes puede estar horas sin que se le canse la vista.

En mi caso particular, hace tiempo vengo usando un tip que me viene funcionando muy bien:

Usá una paleta de colores acorde a la iluminación ambiente.

Si detrás del monitor tenés una ventana o una pared clara y bien iluminada, usá colores claros.

Si trabajas en penumbras, usá colores oscuros.

Cuanto menos contraste haya entre el ambiente y la pantalla, menos vas a forzar la vista.

Siguiendo esa regla, el resto es puramente una cuestión de gustos.

Y sobre gustos no hay nada escrito, dijo una vieja, y usaba amarillo sobre azul en TurboPascal.

PD: Si tenés algún otro tip sobre iluminación o colores, mandalo!