4 bits blog

Siguiendo un poco con la tónica de mi último post, hace unos días (no recuerdo dónde, lo siento) comentaron un framework llamado PulpCore para el diseño de applets Java con interfaces de usuario bonitas.

El lema de PulpCore, para que veáis lo claro que lo tienen, es “Java applets that don’t suck.” lo que traducido al español sería “Applets Java que no apesten.”.

Y es que yo siempre había opinado que los applets habían sido el peor invento relacionado con Java y la web, pero desde hace poco han ido cobrando importancia por el hecho de que Sun quiere resucitarlos para usarlos junto a su JavaFX para la creación de apliaciones RIA (otro de esos términos tan usados actualmente, como web 2.0).

La verdad que yo siempre había dudado de que fuera buena idea resucitarlos, pero si los resucitan haciendo algo parecido a lo que hace PulpCore, creo que sería un acierto por parte de Sun para quitar clientela a sus rivales, aunque habría que decirles a los genios de Sun: “¿Por qué han tenido que hacer algo así terceras personas?”

Hoy voy a tocar un tema algo espinoso para muchos de los que nos dedicamos a programar, y es si además de preocuparnos de programar bien tenemos que atender a factores externos como el diseño de la interfaz de usuario.

Normalmente, en mi opinión, un programador no debería hacer nada relacionado con el diseño de una aplicación, es decir, si es una aplicación de escritorio, el programador no debería porque saber como hacer la interfaz gráfica, o si es una aplicación web, no debería porque saber como va a ser la web. Para ello se debe tener a gente especializada en diseño de interfaces gráficas, se podría decir que serían personas que supiesen algo de diseño y de programación. De este modo cada uno podría dedicarse a hacer lo que mejor sabe, y de una manera eficiente.

Pero como el mundo no es un lugar ideal, o porque estamos desarrollando una aplicación por nuestra cuenta, los programadores debemos tener cuidado con aspectos del diseño de las interfaces de usuario, sobre todo lo que yo suelo decir es que debemos tener un poquito de buen gusto. Y es que muchas veces encuentras verdaderas mierdas hechas por ahí, que funcionan muy bien, pero que su aspecto es tan lamentable que hecha para atrás, y aún así hay gente que opina que no está mal.

Y es que las cosas entran por los ojos, y algo que queda feo para el 95% de los mortales, es algo feo. Por eso desde aquí os hago hincapie en que dediquéis un poco a dejar las cosas bien, y que no mezcléis colores raros (como texto amarillo sobre fondo blanco), que no cuesta nada.

Recientemente, ^Diamond^ me proponía que hiciéramos algo similar a lo que hace él en Gaussianos: Proponer juegos para su resolución (algo del estilo de Bits en el ring, pero más matemático quizá).

Esta mañana me ha llegado la inspiración para ver si el tema os motiva en forma de post gaussiano: Serie numérica que espera explicación. La serie está al alcance de cualquiera, además que en los comentarios ya se ha comentado cómo resolverla. Pero lo que nos interesa en 4bits es ver hasta que punto es programable y hasta dónde llega.

Entonces…

Necesitamos programas que realicen esta serie (y que lo hagan correctamente). No se requiere ningún lenguaje en concreto, pero se agradecería un ejecutable (para Linux, Windows o ambos) junto al código fuente. Si alguno se interesa ya os indicamos la forma de enviarlo. El premio está por ver, ahora mismo está entre un mondadientes y una palmada en la espalda ;)

Java tiene algunas cosas bastante raras, y eso no es una excepción a la hora de crear interfaces gráficas. Por ejemplo, cuando pones RadioButtons en Swing, a menos que le digas explíticamente que quieres agruparlo con otro, se comportan independientemente entre ellos. Para agruparlos necesitaremos un código similar al siguiente

//Vamos a suponer que las funciones devuelven los tipos que queremos
JPanel panel = getJPanel();
panel.add (getRb1 ()); //RadioButton1
panel.add (getRb2 ()); //RadioButton2
panel.add (getRb3 ()); //RadioButton3
//Agrupamos los radioButton
ButtonGroup bgRadios = new ButtonGroup ();
bgRadios.add(getRb1());
bgRadios.add(getRb2());
bgRadios.add(getRb3());

Con esto los 3 RadioButtons (JRadioButtons para ser más exactos) añadidos al panel se comportan exactamente como sería de esperar: Cuando se activa uno, desactiva el que estuviera activado.

En SWT la cosa cambia bastante. Por defecto, todos los RadioButton (Button con estilo Radio) de un panel quedan agrupados para funcionar así. Pero no es oro todo lo que reluce. Sólo funciona a nivel de interfaz; si por código activamos uno de los botones, tendremos que asegurarnos de desactivar los anteriores. Esperemos que IBM corrija esta peculiar feature que más pareciera un clamoroso bug.

Si bien, parafraseando a cierto personaje de cierta película, un programador no necesita más que la línea de comandos, son muchas las herramientas nacidas para facilitarnos la (en ocasiones) tediosa tarea de revisar miles y miles de líneas de código. Lo más avanzado o, más correctamente, completo en este aspecto son los entornos de desarrollo (IDE por sus siglas en inglés), que simplifican y automatizan un montón de tareas para que nosotros nos centremos en lo básico: una buena algoritmia.

Pues bien, ayer he visto por casualidad una inmensa lista con IDEs para diversos lenguajes (en inglés) con una breve descripción, enlace a sus respectivas páginas y tal. Para elegir el que más os guste.

Vía Anieto2k