Changelog del release

Con ese changelog… debería ser el release de una major version, no una minor…

En fín, este sería el milestone de php que se conocera de acá en adelante con la frase “como cayó, quedó”.

Mi sincero y objetivo consejo: no usen los namespaces, así como están son al reverendo pedo, lo bueno es que pueden igual usar el keyword “use” para hacer name aliasing y achicar los nombres largos que ya venian usando.

Los “closures” al final quedaron como era de esperarse… no son más que syntactic sugar para la creación de functor objects anonimos. No resuelven el scope, se debe explicitar las variables que se copian al scope del functor.

Discusión en Foro 3DGames

En español:

FURIA NERD

¿Quién es un gamer? ¡¿Quién NO?!

Gracias a la Wii y juegos como Rock Band, lo que antes era un hobby de recluidos es ahora algo de las grandes masas.

Ahora está de moda jugar videojuegos, ¡somos un maldito objetivo MARKETINERO!

Pero con más gente jugando videojuegos ¿no deberíamos NOSOTROS conseguir más videojuegos que jugar?

NO.

En cambio recibimos versiones bastardas de los que una vez fueron clásicos. Un perpetuo easy mode lleno de quicktime events y mini-juegos.

¿Cuándo fue la última vez que jugaron un videojuego realmente genial?

Eso pense. Son pocos y muy CADA TANTO.

Es tiempo de cortar con esta MIERDA. Este mensaje es para ustedes TARADOS del auto aiming, del jugar con el equipo de los sueños, y del Wii bowling.

VAYANSE A LA MIERDA.

No sufrimos AÑOS como parias para que ustedes vengan a cagarla.

NOSOTROS nos memorizamos los ultra combos. NOSOTROS escribimos páginas y páginas de passwords.

NOSOTROS vencimos los Robot Masters, knockeamos a Tyson, y SALVAMOS A LA PUTA PRINCESA.

Sé lo que nosotros somos, y lo que ustedes NO.

Gamers.

En ingles:

NERD RAGE

Who’s a gamer? Who ISN’T?!

With the Wii and games like Rock Band, it’s opened what was once a reclusive hobby to the light of the teeming masses.

Now it’s trendy to like games, we’re fucking MARKETABLE!

But with more people playing games doesn’t that mean WE get more games to play?

NO.

Instead we’re getting bastardized versions of what were once classic games. A perpetual easy mode filled with quicktime events and mini-games.

When was the last time you played a truly great game?

Thought so. They are few and FAR between.

Its’ time for this BULLSHIT to stop. This is a message to you auto aiming, madden rostering, Wii bowling ASSTARDS.

FUCK YOU.

We didn’t spend YEARS as a social outcast to watch you assholes fuck this up.

WE memorized the ultra combos. WE wrote down pages of passwords.

WE defeated the robotmasters, knocked out Tyson, and SAVED THE FUCKING PRINCESS.

I know what we are, and you’re NOT.

Gamers.

Si no sabe que es la anunciocracia, usted seguramente no vive en la Argentina, o tal vez vive en una nube de pedo negando mirar lo que sucede alrededor. Digamoslo llanamente, un gobierno que se pasa haciendo anuncios para mantener a sus gobernados contenidos en una falsa sensación de bienestar, es una anunciocracia.

El colmo de la anunciocracia es cuando se empieza a anunciar que se van a hacer anuncios, como si hiciera falta…

La publicación propagandista oficial en formato de falso periódico, denominada bastante apropiadamente “El Argentino” (por lo mentiroso), titula hoy “Gobierno prepara semana de anuncios”… ¿hace falta? A menos que se venga el anuncio de que dejan el poder, no es gran noticia, más aún en una semana donde hay tanto más de que hablar: Obama, Guantánamo, referendo en Bolivia, sequías, secuestros, etc, elijan uno que todos estos temas son más importantes que saber que el gobierno sigue haciendo lo mismo de siempre, o mejor dicho, sigue diciendo que va hacer cosas.

Para hacerla corta, para un patrón de diseño de construcción, como por ejemplo el Singleton, conviene dejar fuera del alcance del resto del sistema el manejo de su construcción, o sea, siguiendo el ejemplo, para un singleton debería existir solo una única instancia, pero si otras piezas del sistema tienen acceso al constructor del singleton ¿quién te asegura que nadie intente crear una nueva instancia?

En general veo dos posiciones, la de los puristas que chequeen en runtime que el objeto no instanciado externamente, añadiendo un flag parche y causando una excepción si este flag indica que no se está instanciando el objeto como se debe. Y la otra posición es la de los que les importa un bledo, y si instanciaste el singleton es problema tuyo por no saber que no se instancian los singletons.

Ahora, existe una tercer postura, la mía =P

Volviendo a ponernos serios, no es realmente conveniente asegurarse que un singleton mantiene su cualidad de tener una única instancia haciendo la validación en runtime antes mencionada. Primero, ensucia el código, el flag parche no tiene otro propósito que ser un workaround para una condición del lenguaje. Segundo, estos problemas deberían detectarse siempre en la compilación, no hay razón para delegarlas al runtime.

Lo más interesante es que realmente se puede hacer singletons en actionscript 3 cuya construcción sea inaccesible para los otros componentes del sistema, y de esta manera controlar que se cumpla la condición de única instancia. Asimismo se puede aplicar otros patrones de diseño de construcción manteniendo inaccesible la construcción, aunque con algunas vueltas de tuerca.

Para esto lo que se hace es separar el patrón en 3 partes: la interfaz, la implementación y el acceso. Para el caso del Singleton tenemos una interfaz al objeto que es singleton, que es pública y abstracta, una implementación que es el objeto singleton en cuestión, que es privado, y el acceso que es la forma en que accedemos a la instancia singleton.

La interfaz es justamente implementado como un interface que expone los métodos y atributos del singleton. El interface nos abstrae de la implementación y no nos da acceso a la construcción del mismo. La implementación la declaramos como internal, de manera que es solo accesible desde dentro del mismo paquete, no solucionamos realmente el problema pero lo limitamos considerablemente (al paquete del singleton).

Finalmente queda la cuestión de como proveer el acceso a la instancia singleton. Una opción simple es tener una constante dentro del paquete para dicha instancia, pero esto puede ser complicado a la hora de ponerle nombres a los símbolos (porque en muchos casos resulta coherente usar el mismo nombre para la constante y para la interfaz). Otro opción es dar acceso al singleton desde otro clase, ya sea una que por el modelo de datos funcione como contenedor, o una clase de utilidad que solo cumpla la función de dar acceso a uno o más singletons.

En un proyecto en google code que tengo para este tipo de cosas, subí código para ejemplificar esto.

En el mismo se puede ver, por ejemplo, la implementación interna de un singleton de configuración, la interfaz que expone este singleton al resto del sistema, y el acceso a dicho singleton mediante una constante.

A primera vista puede resultar molesto tener que mantener estas tres partes por separado, pero a la larga uno empieza a notar los beneficios de resolver este tipo de situaciones desacoplando interfaz e implementación. Por ejemplo, si uno usa una IDE con code-hinting, al usar una interfaz en lugar de la implementación, la IDE te sugiere unicamente aquello expuesto por la interfaz, lo cual resulta sumamente útil para filtrar todo aquello que nos hubiera sugerido de haber usado la implementación y realmente no nos interesabe. Esto último sucede en especial con clases cuya herencia es bastante prolongada, y la IDE nos sugiere todo cuanto las sucesivas clases dieron en exponer como público.

Estos son los debates que surgieron:

Python 3

[Debate] Python

El mito del que acá quiero hablar es el mito de las promesas del lenguaje Python. El sitio dice:

Python is a dynamic object-oriented programming language that can be used for many kinds of software development. It offers strong support for integration with other languages and tools, comes with extensive standard libraries, and can be learned in a few days. Many Python programmers report substantial productivity gains and feel the language encourages the development of higher quality, more maintainable code.

Aunque los primeros argumentos son comprobables, lo último es solo un deseo que se puede ver en su redacción como se deslindan de tal afirmación (Many Python programmers report… igual no son muchos … es broma). Lo cierto es que la promesa de productividad carece de comprobación, y la promese de mejora en calidad y mantenibilidad de código es totalmente mentira.

Hasta acá llega la postura políticamente correcta de Python, en cualquier otro lugar los python adictos van a defender ad nauseam la belleza del lenguaje.

Primero debemos recordar que no hay lenguaje que pueda garantizar la mantenibilidad, la calidad y/o la legibilidad del código, en dicho sentido cualquier promesa es vana. Siempre que haya en la tarea de programar la necesidad de mano de obra humana, esta disciplina va a depender de las capacidades literarias y comunicadores de los mismos para hacer del código fuente una pieza estéticamente agradable, legible, comprensible, mantenible por sus pares.

Ahora un lenguaje puede ser diseñado favoreciendo o entorpeciendo dicha tarea. Python hace esto último. Esto se debe al error de creer que el minimalismo, la simplicidad y lo dogmático es la combinación ideal para la elaboración de código fuerte en el aspecto estético-literario. Error que deviene en no comprender que dicho aspecto requiere consideraciones del área de comunicación y de una parte del diseño gráfico. Comunicación sobre todo, que es la falencia más grave de los programadores.

El punto clave es comprender que el código fuente es una pieza literaria. Es “leída” por otros además del autor, y estos “lectores” no necesariamente comparten la total comprensión del lenguaje usado, pero sí una base común cultural de como están estructurados los lenguajes de programación (o sea, no debe ser obligatorio conocer el lenguaje para poder leer código fuente escrito en el mismo, pero sí ser programador).

El código fuente es “redactado”, tiene una puesta en página y condicionantes estéticos que modifican la lectura. Esto es importante contemplarlo porque es la razón por la cual fue una mala decisión que el lenguaje dependa del espacio en blanco para delimitar bloques. La causa de esto, en mi opinión, fue mezclar inadecuadamente el paradigma funcional con el imperativo. El paradigma funcional hace uso del espacio porque su abstracción se sitúa sobre el lenguaje matemático que hace uso del espacio para poner en página las definiciones, pero esto solo funciona bien con el lenguaje lógico-matemático. El paradigma imperativo no comparte estas condiciones.

Hay varios otros puntos que muestran lo falente e inconsistente del lenguaje Python en lo que se refiere al aspecto estético-literario, varios de ellos discutidos en el debate que mencione arriba. Tratare de dedicarle algún tiempo a explicar algún otro, como, por ejemplo, porque está mal elegido el keyword “def” para definir funciones, que es un problema de retórica/comunicación.

La regla general para los includes es, si el tipo que estas declarando depende de un tipo de dato que está en otro header, tenés que incluir dicho header en el header donde declaras el nuevo tipo de dato. Por ejemplo:


foo.hpp
| #ifndef __FOO_HPP__
| #define __FOO_HPP__
|
| class foo { ... };
|
| #endif
|
bar.hpp
| #ifndef __BAR_HPP__
| #define __BAR_HPP__
|
| #include "foo.hpp"
|
| class bar {
| private:
| foo foobar;
| ...
| };
|
| #endif
|


En este caso el compilador necesita saber como esta declarado foo para construir bar.

Pero, si usas solo punteros al otro tipo de dato, el include va en el .cpp y en el .hpp un forward declaration, siempre y cuando el .hpp solo contenga declaraciones (si usas templates fuiste). Ejemplo:


foo.hpp
| ...idem...
|
bar.hpp
| #ifndef __BAR_HPP__
| #define __BAR_HPP__
|
| class foo;
|
| class bar {
| private:
| foo *foobar;
| ...
| };
|
| #endif
|
bar.cpp
| #include "bar.hpp"
| #include "foo.hpp"
|
| ...
|


En este caso el compilador no necesita saber como esta declarado foo para construir bar, ya que un puntero siempre es lo mismo sin importar a que apunte (salvo para punteros a funciones), por eso en el .hpp le basta con saber que el nombre “foo” corresponde a una clase. Pero en el .cpp vamos a trabajar con la variable miembro foobar por lo que necesitamos saber como está declarado el tipo “foo”.

La idea es que, de esta manera, los que utilicen la clase “bar” tengan que incluir solo la declaración de la clase bar y olvidarse de “foo”. En un ejemplo trivial como este puede parecer inutil, pero a esto agregale que foo utiliza otras clases más y templates, y la carga de headers puede llegar a ser significativa. Y si bar es una clase de utilidad genera que se usa en otros varios lugares… el tiempo de compilación puede llegar a ser un poquito molesto… (igual el cuello de botella son los templates… bah… no se ahora… hace tanto que no toco C++).

Sobre la crueldad de verdaderamente enseñar ciencias de la computación

Lo postee en el foro de 3dgames y el comentario de un coforero me dio pie para un pequeño rant que aqui transcribo.

Mensaje original enviado por Dem0
¿Qué tan parecida es la visión de Dijkstra con, digamos, la carrera de Ciencias de la Computación en Exactas?

¿a Cs de las Computación en Exactas? La pregunta que deberías hacerte es ¿qué tan acertado estaba Dijkstra con respecto a las Ingenierías y las Tecnicaturas? En mi opinión estaba muy en lo cierto, y cae de sentado ejemplificarlo con las tantas ingenierías y tecnicaturas que institutos de dudada reputación en nuestro país han dado en promover, jactandose de dejar de lado la parte “dura” de nuestra disciplina o especializandose en mercados de atractivo comercial sin realmente comprometerse a enseñar el oficio como corresponde (por ejemplo, la tecnicatura en “programador de videojuegos” que en todo caso debería ser un posgrado).

Es triste ver como hay todavía individuos que insisten en comprender al software como una manufactura, o prefieren rasgar la superficie de la disciplina enseñando los tecnicismos, en lugar de introducir al alumno en el paradigma que le permita trabajar desde adentro del mismo, como profesional más que como técnico. Con esto último me refiero por ejemplo a quienes enseñan OOP enseñando como usar las herramientas del paradigma mas que dominando los fundamentos.

En cuanto al resto del artículo de Dijkstra, hay puntos en que estoy en desacuerdo. Su propuesta no es del todo alegre. Me parece que se equivocaba con respecto a la terminología como lugar donde se gesta la falla en el proceso de enseñanza. Muchos de los términos no son usados metafóricamente sino alegoricamente, o tal vez fueron usados de esta manera en su momento pero quedaron culturalmente aceptados y se convirtieron en alegorías o cambiaron su significado habiendo quedado perdida el vinculo original que las mantenía como metáforas. Por ejemplo, “bug” para referirse a errores de programa, “comportamiento” para referirse a las consecuencias funcionales de un programa, “mantenimiento” para referirse a la asistencia de incidentes y ajustes funcionales menores post-deploy, etc…

Creo que se ha avanzado sobre lo que Dijkstra considero como la mitad faltante en la formación de científicos de la computación, por lo menos en los lugares donde se considera a nuestra disciplina como tal. Me refiero a que se avanzo en lo que es pertinente a la especificación funcional. Programar no es simplemente el acto de escribir programas de computación, es todo lo que conlleva realizar dicho programa, desde relevar la especificación funcional, implementarlo, hacerlo parte de una base de conocimiento y procesos, y mantenerlo funcional y actualizado a los procesos que se busca automatizar (en el sentido: de crear el automata capaz de llevar a cabo el proceso).

Pero me parece que Dijkstra dejo de lado un tercer aspecto de nuestra disciplina que es tan importante como el resto: un programa es también una pieza literaria, una pieza de comunicación. Un programa tiene por lo menos tres aspectos: es ejecutado por una computadora, responde a una intención, y tiene una o más formas de ser “leído”.

Vamos por partes.

Punto uno. Google no es un gran y único dios clarividente, por un lado esta el googlebot, por otro lado esta el equipo anti-spam de google. El primero es un algoritmo, un programa, un proceso, un automata. El segundo es un grupo de personas.

Punto dos. El googlebot NO INDEXA CSS, no tiene idea sobre el, no le importa a su tarea. Si no me creen, fijense que es lo que se guarda en la cache de google (al hacer una búsqueda existe la posibilidad de ver la página encontrada según como la guardo el googlebot). Luego, si el googlebot no sabe nada del CSS, ¿cómo es que este pueda afectar a la indexabilidad de un sitio?

¿Por qué al googlebot no le importa el CSS? Al algoritmo le interesa los contenidos para indexarlos, la visualización no importa. Es más, cuanto mejor este armado el HTML para favorecer el procesamiento del contenido, ¡MEJOR! (es por esto que toda la movida de la web semántica empezó, porque google paga las cuentas y google dice: “mi bot entiende mejor el HTML estructurado con una orientación al contenido”).

Punto 3. Evitar la visualización del texto para poner en su lugar un bitmap del mismo en una tipografía visualmente más pertinente es uno de las técnicas más viejas en el toolbox del desarrollador web. Vean las plantillas de CSS Zen Garden y van a ver de que hablo. ¿Tiene sentido limitar la capacidad creativa de los profesionales de la web, y la experiencia que se le puede ofrecer al usuario, solo por “evitarse un problema” con google? NO. Por el contrario, google no quiere que hagamos eso (ver estas discusiones: Using CSS to hide text, Google Breaking It’s Own Quality Guidelines? – CSS).

Punto 4. Los que evaluan si hay o no textos ocultos es el equipo anti-spam, y acá no hay algoritmo que valga (los programas pueden ayudar pero las maneras que los spammers encuentran para engañar suelen requerir de un ojo humano que de el visto bueno antes de proceder con una falsa acusación). Acá es donde entre en rigor el tema del texto oculto. No se trata de evitar a toda costa usar CSS que oculte texto, sino de no usarlo de manera desleal.

Ver estos casos para hacerse una idea de cómo se detectan los casos de texto oculto y por qué se dan de baja del índice: Communication in other languages, Notifying webmasters of penalties.

Punto 5. Por sobre todo la usabilidad va primero. La web es para que la usen los usuarios, no para que google la indexe mejor. Hay que ponerse bien las prioridades: Accesibilidad > Usabilidad > Indexabilidad. Además no es la indexabilidad (o la optimización para buscadores) la que hace que una web aparezca primero en los buscadores, como todo negocio, si no hay promoción nadie se entera… menos google.

El primer indicio de que una investigación está mal hecha es que uno llega al resultando que estaba buscando (vease murphylogia aplicada a la investigación de campo).

El segundo indicio de que una investigación está mal hecha es el uso incorrecto de la terminología aplicada a su campo (¿¿¿”gamming”???).

El tercer indicio de una investigación está mal hecha es la falta de conocimiento del entorno estudiado: “Un chico que está muchas horas del día frente a una computadora es porque no tiene intercambio humano” (mmmm… ¿están al tanto que los videojuegos más jugados son de modalidad multiplayer online? juegos en donde el intercambio humano no solo es posible, es necesario…. creo que no).