design-nation.blog/es

Varias veces hemos citado a 37signals en el blog. En este caso lo hago acerca de una cuestión que se plantea uno de los miembros en el blog.

Cuándo y cómo aprender cosas nuevas.
Bueno, es obvio que para aprender un lenguaje nuevo, el cómo es fácil. Ordenador, café, una pantera rosa, Desmond Dekker de fondo, y …programar. ( Vale, el café no tiene porque ser necesario ).

El cuándo es un poquito más complejo, pues además lleva implícito el dónde.

Partimos de la premisa de que somos programadores porque nos gusta programar

Con esto en mente, podemos pensar que el mejor sitio es en casa, pero eso implica llegar a casa y ponerse a tirar código después de haber estado escribiendo líneas todo el día en el trabajo.

Como digo, me gusta programar, y sí puedo dedicar parte de mi tiempo libre a hacerlo, pero una parte mínima.
También me gusta hacer fotos, ver buenas series o películas, pasear, leer el periódico, leer un libro, y otras muchas cosas que no puedo hacer la mayor parte del día porque estoy programando, …en el trabajo.

La otra opción es forzar en la medida de lo posible a utilizar nuevas herramientas o nuevos lenguajes en nuestros desarrollos profesionales.

Me gusta más la segunda. Lo cierto es que nunca se aprende tanto como cuando tienes X días para hacer algo que ni siquiera sabes si se puede hacer. Es cierto que en esos días se puede llegar a pasar mal - llegaré a tiempo, seré capaz- pero se aprende, y cuando se obtiene el resultado, la satisfacción es enorme. La mente está activa, el cuerpo está activo. La rutina no es rutina. Como decía César hace una temporadilla,

Una de las mejores sensaciones que se pueden tener cuando se gana uno la vida como programador es la de estar frente a un proyecto que hay que sacar adelante con una tecnología de la que no se sabe nada. Lo malo es que esa sensación se da tan pocas veces...

Volviendo al post que ha originado esta sesuda reflexión, en uno de los comentarios, Dr. Meter afirma

At some point, while there will be new approaches and paradigms, you learn to trust your expertise in core logic and programming principles and realize that new languages are more about syntax than anything else. It’s inevitable that the language you’re using now will be replaced (probably in 5 years or less), and you just have to have the confidence that you can adapt your skills.

Bajo mi punto de vista, tiene razón, y además esta opinión enlaza por otro lado con algo que ya hemos comentado por aquí.

A fin de cuentas, cuando sabes el porqué de las cosas, el cómo siempre es más fácil.

Publicado por Javier Tardaguila a las 12:07 PM | Enlace permanente | Comentarios (0)

Desde que me dedico a esto, me ha ocurrido mil veces.

Hoy me ha vuelto a ocurrir..

Situación. Se quiere modificar una sección y se nos pide que se envíen varias pruebas de diseño en jpg para valorarlas. Se envían cinco.

La contestación es: “nos quedamos con la quinta, pero… esto que está alineado a la izquierda, lo alineáis a la derecha, a esto otro le quitáis el borde, a esto le aumentáis el tamaño de letra, a esto le ponéis un fondo clarito, a esto le modificáis el interlineado, esto que tenga un borde discontínuo y a esto otro le ponéis un bullet que sea una imagen de…” etc…

Conclusión: no se quedan con la quinta, se quedan con la sexta. Que evidentemente ni siquiera es mezcla de las cinco anteriores. No es ni más ni menos que lo que querían desde un principio y pretendían que adivinásemos tras leer la frase “queremos unos pequeños cambios”.

¿Porqué gustará tanto hacer trabajar por trabajar? ¿Porqué no se puede decir “quiero esto así y así” a la primera?.

En muchas ocasiones, tengo la sensación de que numerosos puestos de trabajo se justifican por quienes los ocupan, basándose en el número de e-mails enviados, y en la cantidad de trabajo baldío generado.

Publicado por Javier Tardaguila a las 11:14 AM | Enlace permanente | Comentarios (10)

No las doy yo, las dan aquí. Pero, desde mi punto de vista, razón no le falta.

Sinceramente, en los últimos años he pasado más tiempo peleándome con Subversion que utilizándolo para mejorar mi proceso de desarrollo. Lo que me parece decir mucho sobre una herramienta cuya única razón de ser es precisamente, facilitar el proceso de desarrollo...

Publicado por Cesar Tardaguila a las 08:29 AM | Enlace permanente | Comentarios (7)

Apple liberó a primeros de agosto un SDK para el desarrollo de plugins para iPhoto. El SDK está disponible en el Developer Connection (es necesario login para la descarga, pero es suficiente con tener una cuenta gratuíta). El SDK por fin documenta la API de exportación, pero, como suele ocurrir en estos casos, hay un par de aspectos un poco oscuros.

Para intentar hacerme una idea de cómo puede ser el desarrollo de un plugin de este tipo, he realizado una prueba de concepto que me va a resultar de utilidad. Se trata de un plugin que exporta de una a un número indeterminado de imágenes con los siguientes condicionantes:

• Si la imagen está en formato apaisado, debe exportarla con una anchura de 800 píxeles.
• Si la imagen está en formato retrato, debe exportarla con una altura de 600 píxeles.
• En todo caso, el nombre de la imagen resultante debe seguir la siguiente plantilla: incan-nombre.jpg, donde nombre es el nombre original de la foto cuando fue importada a iPhoto.
• La imagen debe poder exportarse con o sin metadatos, siendo la exportación con metadatos la por defecto.
• La calidad de la exportación debe poder variar, aunque por defecto se eporta a la máxima.

¿Por qué estas condiciones? Porque son las que deben cumplir las imágenes de mi fotoblog.

La documentación del SDK es clara y, aparte de la descripción de la API incluye un ejemplo completo de desarrollo de un plugin algo más complejo incluso que el que yo he programado. Sin embargo, hay un par de aspectos del proceso que me apetece reseñar, por no quedar demasiado claros.

La arquitectura del plugin es bastante sencilla. Por un lado, se construye una vista, que debe ser una subclase de NSBox que adopte el protocolo ExportPluginBoxProtocol. Esa vista sólo deberá implementar un método:

-(BOOL) performKeyEquivalent: (NSEvent * ) anEvent

Ese método simplemente debe notificar al plugin cuándo se debe comenzar el proceso de exportación, normalmente tras comprobar que se ha producido una pulsación en la tecla intro, enter o la que se desee declarar.

El meollo de la lógica del plugin, no obstante, está en la clase que se declare como controlador del mismo, que debe adoptar el protocolo ExportPluginProtocol.

En realidad, la documentación es bastante adecuada, excepto en la parte en la que detalla la estructura ImageExportOptions, estructura utilizada para pasar al método que realiza la exportación final. Según la documentación, tanto el ancho como el alto son de obligatoria declaración.

Bien, pues según parece, al exportar en modo landscape basta con declarar el nuevo ancho. Sin embargo, al exportar en portrait es necesario dar ambas dimensiones, por lo que hay que calcular en qué proporción modificar ambas.

Si alguien está interesado en el código fuente del plugin, puede descargarlo del repositorio de subversion:

svn co http://svn.liadorasoft.com/incanplugin

El código es prácticamente el mismo del ejemplo del SDK, con las modificaciones necesarias para cumplir con los requisitos antes detallados (nombre de imagen exportada y dimensiones de la misma)

Publicado por Cesar Tardaguila a las 09:11 AM | Enlace permanente | Comentarios (0)

Estaba leyendo un articulillo de Coding Horror, ( no es la primera vez que aparece por aquí ) acerca de tener nuestras aplicaciones con un menú simple.

En realidad, el artículo no es tanto sobre el menú de la aplicación, sino sobre la aplicación en sí. Sobre la gran cantidad de opciones que suelen tener los programas, opciones para que el usuario configure el mismo según sus gustos.

Y no he podido evitar recordar el capítulo de Getting Real que trata sobre el tema. "Avoid Preferences".

Preferences are a way to avoid making tough decisions. Instead of using your expertise to choose the best path, you're leaving it in the hands of customers. [...]

Preferences are also evil because they create more software. More options require more code. And there's all the extra testing and designing you need to do too. You'll also wind up with preference permutations and interface screens that you never even see. That means bugs that you don't know about: broken layouts, busted tables, strange pagination issues, etc

Y si las opciones son menos, el programa es simple ( más simple ), y por tanto el código es simple.

Y se cierra el círculo. Keep it simple.

PD: Sí. Hay ocasiones, muchas ( quizás menos de las que pensemos ) en las que hay que dejar elegir al usuario. Como todo en esta vida, se trata de saber qué y cuando. Y como todo en general, es eso, lo que distingue al buen programador/diseñador del resto. ( Aplicable a casi cualquier ámbito de la vida )

PD2: Sí. Como todos por aquí ( imagino ), también me las he visto y deseado para añadir mil posibles opciones de configuración a programas. Opciones que eran "imprescindibles" y que jamás nadie usó.

PD3: Me repito si, pero la realidad es que algo simple, puede convertirse en imprescindible. Precisamente por eso, porque es simple.

Publicado por Javier Tardaguila a las 11:32 AM | Enlace permanente | Comentarios (0)

Hace ya unos años que algunos de los proyectos desarrollados en ActionScript han alcanzado un nivel de complejidad tal, que obligan al desarrollador a utilizar todo el arsenal de herramientas que hasta no hace tanto sólo estaban al alcance de los desarrolladores de aplicaciones empresariales.

La figura clásica del flashero, la de un perfil mixto entre programador y diseñador, generalmente incluso de un perfil más cercano al diseño, que se pasa a la programación al quedársele pequeña la línea de tiempo, empieza a no tener cabida más allá del clásico estudio de diseño, del sitio donde "se hace web" como apoyo al trabajo en papel.

El flashero, hoy por hoy, debe conocer y dominar los mismos conceptos que conocen y dominan los que programan contra servidor: separación de la lógica de la aplicación por capas, por supuesto programación orientada a objetos de la de verdad, utilización apropiada de patrones de diseño, minimización de las líneas de código maximizando la generalización...

Sin embargo, el mercado sigue sin reconocer esa valía. Un flashero sigue cobrando menos que un perfil equivalente que, por ejemplo, programe en Java, siendo capaz de resolver problemas de complejidades conceptuales similares y utilizando recursos y artificios similares.

Y no sólo el mercado, sino lo que es más sangrante, los que en su día fueron flasheros de esos que colocaban el código en botones, y que ahora son los que lanzan a otros a realizar proyectos imposibles en plazos inalcanzables, son los mismos que protestan cuando el código resulta de una arquitectura "compleja" para sus limitados conocimientos.

Hace años que la realidad del desarrollo en flash ha cambiado. Sin embargo, esa realidad sigue sin querer ser vista por muchos.

Publicado por Cesar Tardaguila a las 09:54 AM | Enlace permanente | Comentarios (7)