« Noviembre 2005 | Inicio | Enero 2006 »
Gus Mueller, el hombre detrás de Flying Meat, uno de los desarrolladores independientes de aplicaciones para Mac OSX más respetados, cuenta su historia en un post en el que desarrolla siete conceptos que considera básicos para llegar a alcancar el sueño de poder trabajar para uno mismo.
Una buena lectura para estas fechas, en las que se formulan tantos buenos propósitos.
Phillip Chu da las que entiende son las siete reglas principales para ser un programador efectivo. Habrá que ponerlo en la lisa de buenos propósitos para año nuevo...
El próximo jueves 19 de enero, como presentación oficial del portal generacionmac.com, especializado en el diseño y desarrollo de aplicaciones bajo plataformas Mac, se celebrará en Madrid el evento “Generación Mac: el futuro de la creación” con el mecenazgo de la Escuela Superior de Negocios y Estudios Internacionales – ESNE.
Este evento, dirigido a cualquier usuario Mac novel o profesional, es de carácter abierto y gratuito y tendrá lugar en las instalaciones de ESNE Madrid de 18h a 21h.
Debido a que el número de plazas es limitado, es necesaria inscripción previa a través del teléfono 91 555 25 28 o en el correo electrónico madrid@esne.edu, indicando sus datos personales y de contacto.
Los sufridos asistentes se tendrán que tragar un ladrillo de una hora titulado "¿Tienes media hora libre? desarrolla una aplicación con Core Data", a cargo de su seguro servidor. No digan que no estaban avisados.
Más información, en ESNE
El player de FlashLite 2 ya est· disponible en la tienda online de Macromedia (mejor dicho, de Adobe) a ocho euros (+ IVA).
A˙n no hay documentaciÛn, ni es posible generar contenido especÌfico para FlashLite 2, pero se puede empezar por ir probando las aplicaciones desarrolladas para la versiÛn anterior del player.
El anuncio semi-oficial est· en la web de Bill Perry.
Por cierto, la lista de dispositivos soportados es "selectiva": Nokia modelos 3230, 6260, 6620, 6630, 6670, 6680, 6681, 6682, 7610, N70, y N90.
A disfrutar el juguete...
Cada día que pasa es un día menos para la salida de FlashLite 2.0. Mosaic, la revista del Graduado Multimedia de la UOC se ha querido adelantar al feliz alumbramiento con un artículo en el que se repasa el estado actual de FlashLite, sus perspectivas de futuro, y se compara con los otros dos pesos pesados de la movilidad: C++ y J2ME.
¿La conclusión final?: va a ser necesario empezar a tomar en serio a FlashLite.
No hay mucho más que añadir.
Ahora mismo no recuerdo quién fue el que dijo que lo más difícil a la hora de intentar enseñar algo era encontrar un buen ejemplo.
Pues si lo que se quiere es aprender SQL, puede recurrirse a un muy buen ejemplo: GalaXQL, un tutorial que enseña SQL permitiendo manipular las estrellas de la galaxia.
Vía The Farm
El Apple Developer Connection ha abierto una nueva sección titulada Business & Marketing for the Mac Developer, en la que proporciona, entre otras cosas, unas FAQS sobre marketing (cómo conseguir llamar la atención sobre la aplicación, a quién enviarle copias de prueba, etc ).
Una lectura interesante, más aún al hilo del post anterior
En el MacWorld de diciembre Fernando García pasa lista a unas cuarenta y pico aplicaciones para Mac que, o bien son gratuitas, o bien tienen precios más que ajustados.
Entre las aplicaciones enumeradas están Audio Hijack Pro, Audacity, NVU, Mercury, Comic Life, Impression, Snapz Pro x, Keyword Assistant...
Un buen recordatorio de que no siempre lo mejor es lo más caro. De hecho, en un Mac, probablemente sea al contrario, ya que la mayoría de las aplicaciones que más pueden aumentar la productividad de un usuario están desarrolladas por programadores independientes.
Pero ¿por qué?. ¿Es que los desarrolladores que realizan aplicaciones para Mac OSX son mejores que los demás?. Pues, la verdad, no lo creo. Pero sí que puede haber una serie de factores que ayuden al éxito de los programadores independientes en esa plataforma.
Las herramientas de desarrollo.
No creo que haya ningún entorno de desarrollo con el que se facilite tanto el proceso de construcción de una aplicación (y ya he pasado por unos cuantos) como con el conjunto formado por XCode e Interface Builder.
Con todas las dosis de vudú necesarias para un manejo realmente productivo de Interface Builder, con todas las extrañezas y complejidades de Objective-C, con todos los dolores que me ha producido el aprender a realizar un manejo de memoria eficiente y seguro, con todas las complicaciones inherentes a cualquier desarrollo de software, me sigue pareciendo que las herramientas que Apple nos da a los programadores están a una distancia sideral de las que proporciona la competencia.
Por la cuenta que les trae, obviamente, ya que no hay plataforma que pueda sobrevivir si no hay aplicaciones que corran en ella, pero lo cierto es que yo no he encontrado *aún* nada igual.
El mercado está abierto
Desde la transición a Mac OSX, Apple ha apoyado a los desarrolladores independientes, y no sólo ofreciendo un muy buen entorno de desarrollo gratuitamente, sino apoyando a cualquier programador o empresa con un producto de calidad.
Sí, es cierto, Photoshop es la aplicación estrella de la plataforma, pero si pensamos en aplicaciones de ofimática, ya no está tan claro que la mejor opción sea, por dar nombres, el Office de Microsoft.
En general, el mercado está muy abierto, no hay ninguna aplicación que domine plenamente su segmento, por lo que todo el mundo puede intentar "dar la campanada". Tan sólo hace falta una buena idea, algo de talento, y ganas de trabajar.
En realidad, el mayor competidor para un programador de éxito va a ser Apple. Se puede morir de éxito siendo fagocitado por la casa madre. Y si no, que se lo digan a los chicos de Konfabulator
Los usuarios de las aplicaciones
No es que los usuarios de un Mac sean seres superiores que hagan que por el mero hecho de utilizar una aplicación, ésta vaya a ser un éxito. Pero lo que sí es cierto es que la relación de un maquero con su máquina suele ser bastante más estrecha que la del usuario de Windows con su PC.
En general, con todo lo injusto que puede ser generalizar, el maquero suele valorar que las aplicaciones tengan algo especial, algo que haga que la experiencia de utilizarlas tenga cierta riqueza. Más aún si la aplicación le permite divertirse con su ordenador, o sentir que está haciendo algo especial u original con él. Lo cual es algo abrumadoramente subjetivo, pero que crea un vínculo entre el usuario y la aplicación y que se puede comprobar en algo tan sencillo como que Panic Software ¡vende camisetas!.
Por tanto, sí se puede afirmar que se valora al desarrollador independiente. En realidad, lo primero que se va a valorar en un producto va a ser su funcionalidad, como no podría ser de otra manera, pero el hecho de que ese producto haya sido realizado por un sólo programador o por una empresa pequeña también va a pesar en la fidelidad del usuario hacia la aplicación.
Todo esto me lleva a pensar una vez más que, a lo mejor, el viejo sueño de trabajar en mi propia aplicación pueda ser factible en un entorno en el que se acepta y se valora el hecho de ser una "one man company". Tal vez haya que empezar a cerrar una versión 1.0 de alguna aplicación y lanzar la caña con el anzuelo...
En el post anterior de la serie, vimos cómo crear el modelo de la aplicación (en nuestro caso una clase que modele el objeto de negocio "regalo"), dejando que fuera el propio framework el que mapeara en ese objeto la estructura de la tabla previamente creada en la base de datos.
Dicho de forma un poco menos "rimbombante", al generar la clase Regalo, ActiveRecord se encarga de crear los objetos de negocio correspondientes (en este caso Regalo) y hacer todo lo necesario para que ese objeto sea persistente, conectándolo con la tabla regalos. Para ello, es necesario que el nombre que se le va a asignar al modelo sea el singular del nombre que tiene la tabla en la base de datos. Es decir, que si la tabla se llama regalos, el objeto de negocio se deberá llamar Regalo. Si la tabla se llamara coches, el objeto de negocio se debería llamar Coche. Siempre y cuando queramos que la creación del modelo sea automática, claro está.
Pero Rails es un framework cuyo punto fuerte no es precisamente la internacionalización, por lo que es posible que sea necesario configurar la aplicación para definir la correspondencia entre un sustantivo singular y su plural. Por, ejemplo, y sin probarlo, se me ocurre que camiones / Camion podría ser problemático.
Esa definición de las correspondencias entre un singular y un plural se puede realizar en el archivo environment.rb, que se encuentra en la carpeta config de la aplicación. En ese archivo hay una sección, que por defecto está comentada, en la que se pueden añadir tantas pluralizaciones como se considere necesario, utilizando para ello la clase Inflector (en realidad un singleton de la misma). Por ejemplo:
En todo caso, ¿sería ésta la mejor solución posible?. Bueno, la filosofía detrás de RoR consiste, entre otras cosas, en dar más importancia a la convención que a la configuración. Por tanto, siempre sería preferible evitar (no sólo por cuestiones metafísicas, sino también por comodidad) el tener que realizar configuraciones complejas para las aplicaciones.
Entonces, ¿cuál sería la convención?. Pues en general, se podría considerar lo siguiente:
Visto, por supuesto, de forma muy simplificada, y obviando que la convención se puede (y se debería) extender a algunos nombres más, como el nombre de las columnas de una tabla, y el nombre que se utiliza para presentar esas columnas cuando se hace scaffold, por ejemplo.
De todas formas, en caso de duda, no está mal utilizar una herramienta como el "pluralizador" de nuby on rails, que genera una posible colección de nombres a partir de uno dado.