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.
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 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.
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.
Pues ya sólo falta probar la instalación por completo generando el modelo para la aplicación e intentando conectar a la misma. Lo primero será, por tanto, generar el modelo.
Como puede verse en la siguiente imagen, la estructura del proyecto es clara y bien organizada. Cada cosa está en su sitio.
El siguiente paso, es generar el controlador:
Para tener una aplicación mínimamente funcional, en la que están implementadas ya las cuatro operaciones básicas (alta, baja, modificación y consulta) tan sólo hay que editar el controlador de mi aplicación, regalo_controller.rb, y añadir una línea:
¡Y ya está!. Alta, baja, modificación y consulta, en dos minutos. Sobre decir que ahora es cuando debe comenzar el trabajo de verdad, pero ya tenemos un prototipo visible, a los pocos minutos de comenzar el desarrollo. ¿Somos ágiles o no?.
Para comenzar a introducir registros, hay que atacar la url http://localhost/test/regalo/new, y comenzar a toquetear:
Resumiendo: he instalado Rails (media hora más o menos), he instalado MySQL (un poco más largo, por los problemas con las herramientas de administración, pero en total ha sido una hora), he compilado el binding para MySQL (varias horas de google y unos minutos de resolución) y he realizado la primera iteración del desarrollo propiamente dicho (¡cinco minutos!).
Ahora empieza lo bueno...
Este paso ha sido el de resolución más corta, pero el de investigación previa a la solución más larga. Dicho de otra forma, horas de google, para encontrar una solución que se tarda un minuto en aplicar.
Por ahora, he instalado Ruby on Rails y MySQL en el ordenador, y he creado la base de datos con la tabla que voy a necesitar.
Ahora tengo que configurar la aplicación RoR para que utilice MySQL. Para ello, hay que editar el fichero correspondiente: /Users/ctarda/RoR/TestBlog/config/database.yml
Ahora viene la parte complicada. Si yo generase (como así hice) el modelo de aplicación en este momento, e intentase ejecutarla, obtendría un error ya que tal y como está todo, Rails no es capaz de conectar con la base de datos. ¿Por qué?. Porque no hay ningún binding para MySQL instalado.
Para instalar el binding, tendría que cambiar a la carpeta /usr/lib/ruby/gems/1.8/gems/mysql-2.7 y compilarlo (sudo make; sudo makeinstall). El problema es que no compila, y devuelve un error "can't find ruby headers".
Tras horas, repito, horas de google, encontré este post en el que explican brevemente que mi problema puede venir por la combinación Mac OSX 10.4.3 y XCode 2.2. La solución pasa por vincular las cabeceras del Ruby universal a las del ruby para powerpc. Sí, para mí también es chino. Y siento no poder ser más conciso en este punto, pero para mí tanto el problema como la solución al mismo están bordeando el mundo de la "magia".
El caso es que una vez aplicado ese parche ( cd /usr/lib/ruby/1.8/powerpc-darwin8.0;
sudo ln -s ../universal-darwin8.0/*), ya sí he podido compilar el binding de MySQL.
Ahora ya puedo comenzar el desarrollo en sí. Pero en el siguiente post.
La instalación de MySQL debería haber sido un paso más de la preparación del entorno, sin mayor importancia en teoría, pero al final ha sido la única parte verdaderamente dolorosa del proceso. En realidad, no ha sido la instalación en sí, sino la puesta en marcha de la base de datos y su integración con el RoR.
Continuamos con la instalación del entorno de desarrollo en el punto en el que nos quedamos en el post anterior.
El primer paso será descargar el instalador de MySQL, y ejecutarlo.
Si se quisiera que la base de datos se arrancara automáticamente al arrancar el sistema, habría que ejecutar también el instalador de MySQL Startup Item, que se incluye en el paquete.
Como indica la documentación, para que la instalación se pueda realizar, es necesario que exista en el sistema un usuario que se llame mysql, usuario que parece ser ya existe a partir de la versión 10.4.2 de Mac OSX, por lo que en mi caso, no ha sido necesario crearlo.
Una vez instalada la base de datos, habrá que arrancarla:
Si se quisiera parar:
A partir de este punto supongo que todo lo que voy a contar hay que tomarlo con precaución. Me explico. Las herramientas propias de MySQL para administrar la base de datos, como MySQL Administrator no han funcionado nada bien. Tampoco CocoaMySQL. Utilizando el administrador he podido crear usuarios de la base de datos, pero no tablas, y utilizando CocoaMySQL sólo he podido conectarme a la base de datos con el usuario anónimo. Doy por hecho que los problemas vienen por algún error en el proceso que voy a describir. Si alguien lo ve claro, por favor, que deje un comentario explicando cómo se debería hacer correctamente.
Bien, retomamos el proceso tras la instalación y el arranque de la base de datos. El primer paso va a ser crear el usuario root de MySQL:
Tras varios intentos, he conseguido arrancar MySQLAdministrator y conectar a la base de datos como root. Momento que voy a aprovechar para crear un usuario para los proyectos RoR (el usuario será ruby, y el password rails, impresionante despliegue de originalidad):
A continuación, creo el esquema para mi proyecto, que he llamado wishlist. Y creo la tabla para los datos, tabla que he llamado regalos. No he sido capaz de crear la tabla utilizando ninguna de las herramientas para administrar MySQL, por lo que después de muchos intentos, he terminado por ir a la solución rápida pero segura: logarme "a mano" en mysql desde el terminal (como el usuario rails), y crear la tabla haciendo un CREATE TABLE.
Para que la aplicación RoR pueda acceder sin problemas a los datos de la tabla, ésta debe tener una clave primaria (ojo, es importante hacerla AUTO_INCREMENT). La estructura de la tabla será:
Es importante fijarse en el nombre de la tabla: regalos. En el próximo post veremos el porqué de la importancia de ese nombre. Pero antes de eso, tendremos que configurar Rails para que pueda conectar con la base de datos MySQL. Y eso sí que ha sido un grano en el culo...
No sé muy bien cuánto hay de moda en Rails. Se habla mucho de lo rápido que puede ser el desarrollo utilizando este framework, de lo buena que es su implementación del modelo-vista-controlador, de lo sencillo que es el lenguaje... demasiadas cosas como para no probarlo.
Por eso, he decidido desarrollar una aplicación sencilla escrita en Ruby on Rails. La aplicación me va a permitir administrar mi lista de regalos para navidad. No la lista de los regalos que yo voy a hacer, sino de los que quiero que me hagan (así que, quien corresponda, que vaya tomando nota...). El desarrollo, no podría ser de otra manera, va a ser iterativo, de forma que comenzaré por hacer lo mínimo imprescindible para poder dar visibilidad, y a partir de ahí pretendo ir enriqueciendo la aplicación con todo lo que necesitará tener: autentificación de usuarios, AJAX (pensé que nunca escribiría ese palabro en este blog), regalos asignados a miembros de una lista de "regaladores" que también sea administrable... El paquete completo, por decirlo de alguna forma.
Pero lo primero que hace falta es un entorno de desarrollo. En este caso, la máquina en la que va a estar corriendo el servidor va a ser mi adorado Mac Mini (1.42 GHz y 512 MB RAM; Mac OSX 10.4.3). El servidor web a utilizar pretendo que sea el Apache que está instalado en el sistema, en vez del servidor propio de Rails, porque por una parte me siento cómodo configurando el Apache, y por otro lado no he leído cosas muy buenas de WEBrick (que así se llama). Además, el ordenador tiene instaladas las XCode Developer Tools (versión 2.2), requisito indispensable para que el "tinglado" funcione (y posteriormente, un grano en el culo a la hora de hacer el binding con la base de datos, como se verá).
Comenzamos. Abróchense los cinturones, y todas esas cosas.
Lo primero que hay que hacer es descargar algún paquete con Ruby on Rails, como por ejemplo este paquete, realizado por Tony Arnold. Por cierto, el procedimiento de instalación es muy similar al explicado en este post del propio Tony Arnold.
Una vez descargado el paquete, hay que proceder a instalarlo:
Posteriormente, hay que actualizar las gems:
Hay que tener en cuenta que el usuario con el que se está logado normalmente no tiene permisos suficientes para actualizar las gems. De ahí el tener que hacer un cambio temporal de usuario al root (sudo), que pedirá la contraseña de dicho usuario.
El proceso de actualización de las gemas es sencillo aunque el feedback del mismo puede considerarse más bien escaso. Como para muchas otras cosas, vigilar el uso de CPU suele dar más pistas sobre lo que está pasando que el propio feedback del proceso. Por cierto, hay que aceptar todas peticiones que se hacen durante el proceso de actualización. Calculo que, en mi caso, la actualización se realizó en unos 5-6 minutos.
Bien, una vez actualizadas las gemas, creamos una aplicación de prueba (no tan de prueba en este caso, ya que es sobre la que voy a realizar el desarrollo). Si todo se genera sin problemas, se podrá suponer que vamos por el buen camino:
Como se puede ver en la imagen, creo una carpeta llamada RoR en el raiz de mi usuario, y posteriormente, tras cambiar a esa carpeta, genero una aplicación llamada TestBlog (mal nombre, lo sé, pero ya no tiene remedio). Una vez concluya la generación de archivos (son bastantes) se podría arrancar el servidor "incorporado" de la siguiente forma:
Cosa que yo no voy a hacer, ya que, como ya he dicho con anterioridad, pretendo que el servidor a utilizar sea el Apache que incorpora el sistema. Pero antes de configurar Apache para que mi aplicación Rails funcione correctamente, hay que dar los permisos necesarios a la misma.
El problema es que Apache es un proceso propiedad del usuario www, pertenenciente al grupo www, por tanto tendré que asignar los archivos de mi aplicación a ese grupo. Igualmente, tendré que asignar permisos de escritura a los logs:
Esto empieza a ir por buen camino. Ahora hay que configurar Apache. Lo primero que habrá que hacer es añadir el módulo fast_cgi al archivo de configuración (/etc/http/httpd.conf):
También hay que incluir los Aliases de la aplicación (en la sección <IfModule mod_alias.c>):
Ahora, hay que editar el fichero .htaccess de la carpeta donde esté instalada la aplicación Rails (en mi caso /Users/ctarda/RoR/TestBlog). La línea:
debe cambiar a (nótese el cambio de cgi a fast cgi)
Además, hay que añadir estas líneas:
Ya estamos terminando. Sólo falta arrancar Apache:
y atacar la aplicación generada:
Si has llegado hasta este punto, enhorabuena (por aguantar despierto sobre todo). Ya has configurado Apache como servidor para tus aplicaciones Ruby on Rails. Pero por ahora no hemos creado más que el esqueleto de una aplicación que, obviamente, no hace nada de nada.
Para poder seguir avanzando, tendremos que instalar una base de datos, y comenzar a desarrollar nuestra aplicación. La base de datos que he elegido ha sido MySQL (porque es la que está instalada en el servidor de "producción" que voy a utilizar). Y con esa elección es donde han comenzado los problemas, problemas que veremos en el siguiente post, pero que se resumen con la siguiente frase: el paquete que he instalado no incluye un binding para MySQL, binding que no puedo instalar por un fallo en la configuración de las XCode Tools 2.2.
Pero eso lo veremos en el siguiente post.
Mac OSX incorpora "de serie" tanto una instalación de Apache, como una versión un poco pasada de php, la 4.3.11.
El caso es que, más o menos actualizado, php está incluído en la instalación del sistema, por lo que en determinadas circunstancias, y para salir de un apuro (como es mi caso hoy), puede venir bastante bien.
El archivo de configuración de Apache por defecto tiene comentados tanto la carga del módulo php, como la extensión de los archivos php. Por tanto, vamos a ver cómo editarlo desde el terminal.
En primer lugar, hay que abrir una sesión del terminal (la aplicación se encuentra en /Aplicaciones/Utilidades/Terminal. Una vez abierta, hay que ir a la carpeta en la que se encuentra instalado Apache:
cd /etc/httpd
A continuación, hay que editar el archivo httpd.conf, pero hay que tener en cuenta que el propietario de dicho archivo es el usuario root del sistema, por lo que para poder editarlo (cambiando los cambios, claro), habrá que hacerlo de la siguiente forma:
sudo pico httpd.conf
Lo que preparará la edición del archivo http.conf con el editor de archivos pico. Pico pedirá la introducción de la contraseña del root, contraseña que, una vez introducida, permitirá modificar y guardar los contenidos de ese archivo.
Ahora, hay que buscar (Ctrl+W) la línea:
#LoadModule php4_module libexec/httpd/libphp4.so
Y eliminar de la misma la almohadilla, que es el carácter que indica que esa línea es un comentario
A continuación habrá que hacer la misma operación con la siguiente línea:
#AddModule mod_php4.c
Hay que eliminar la almohadilla. A continuación, hay que indicarle a Apache que la extensión php es válida. Eso se hace añadiendo dicha extensión a la siguiente sección del archivo:
<IfModule mod_dir.c>
DirectoryIndex index.html
</IfModule>
Modificándola de la siguiente forma:
<IfModule mod_dir.c>
DirectoryIndex index.html index.htm index.php
</IfModule>
Ahora ya sólo falta cerrar y guardar el archivo (Ctrl+O para guardar, y Ctrl+X para salir), y arrancar Apache, lo que se puede hacer desde el panel de preferencias del sistema, en la sección de "Compartir" (activando "compartir web" ), o directamente en el terminal:
sudo apachectl start
Posteriormente, para detener Apache basta con introducir la siguiente orden:
sudo apachectl stop
O, para reiniciarlo:
sudo apachectl restart
¿El resultado?. Si se coloca un archivo con extensión php y una llamada a phpinfo( ) en la carpeta web de mi usuario, se obtiene lo siguiente:
Gran parte del proceso viene mucho mejor explicado aquí, aunque utilizando BBEdit. Ni la mitad de geek que utilizando el terminal
Que no es más que un Safari Bookshelf pero aparentemente alojado en los servidores de Apple, y que promete estar orientado a libros de interés para desarrolladores centrados en el Mac.
Yo todavía no tengo muy claro si me gusta o no la idea de comprar cosas que realmente no compras sino que alquilas, pero ésa es otra discusión.
Smart crash reports es una aplicación que se apoya en el CrashReporter de Apple.
Por un lado, permite a los programadores registrar sus aplicaciones contra ella, de forma que cuando una aplicación falle en el ordenador de un usuario que tenga Smart Crash Reports instalado, se enviará una copia del log del crash tanto al desarrollador como a Apple.
La aplicación es gratuita, tanto para el usuario como para el desarrollador. Si de verdad apoyas a los programadores independientes de aplicaciones para Mac OSX, es casi obligatorio instalarlo.
Apple ha lanzado el Developer Transition Resource Center, que es un punto de entrada a toda la documentaciÛ que puede afectar a los desarrolladores en relaciÛn con la transiciÛn a los procesadores Intel.
Entre otros documentos, se incluye una guÌa sobre cÛmo portar proyectos desde CodeWarrior a XCode, o varios documentos sobre optimizaciÛn de Binarios Universales.
Dudo mucho de la utilidad real de este "invento" a la hora de desarrollar un MIDlet en Mac OSX. Por un lado, la instalación de las herramientas necesarias no es especialmente sencilla ( aunque tampoco hay que ser un gurú del Unix ), por otro el desarrollo en sí no recibe mucha ayuda ( ni siquiera code-hints ), y el testeo y debugeo tampoco es particularmente fácil. Eso sí, poderse, lo que es poderse, se puede.
También quiero quedar claro que yo no he inventado nada, sino que he seguido las instrucciones que he encontrado en otros sitios ( el link puede requerir registro, por si acaso, también se puede seguir este link ), aunque sí he tenido que añadir mi granito de arena al proceso de instalación.
Veamos, pues, cómo desarrollar MIDlets con XCode.
Continuar leyendo "[J2ME] Desarrollo de MIDlets en Mac OSX" »
Localization suite es un set de tres herramientas que facilitan el trabajo de localizar las aplicaciones Cocoa en varios idiomas.
Aunque el soporte multi-idioma del framework es bastante bueno, no siempre es fácil mantener las distintas versiones locales actualizadas, sobre todo si se van produciendo nuevos releases con frecuencia.
Por cierto, la suite es gratuita.
Hay dos cosas que nos gustan particularmente en design-nation: los dados, y las aplicaciones para Mac OSX. AsÌ que hemos desarrollado una pequeÒa aplicaciÛn ( lo has adivinado, un dado ) con la finalidad de enseÒar aunque sea por encima cÛmo es el proceso de desarrollo en el Mac. Lo haremos utilizando XCode y escribiendo cÛdigo en Objective-C
En todo caso, como casi cualquier otro tutorial sobre XCode que se pueda escribir, el nuestro queda oscurecido por el que hay en el Apple Developer Connection. LÈelo!
Pero antes, echa un vistazo al resultado final:
Continuar leyendo "Desarrollo de una aplicaciÛn para Mac OSX: dado" »
HabÌa oÌdo hablar ( o mejor dicho, habÌa leÌdo algunos artÌculos ) sobre Core Data, el nuevo framework para desarrollar aplicaciones Cocoa que ha visto la luz con la nueva versiÛn del sistema operativo Mac OSX.
Pero despuÈs de leer los artÌculos publicados la semana pasada en CocoaDevCenter, sÛlo puedo decir una cosa: °Yo quiero Core Data!
Bueno, el post no es exactamente eso, pero no me he podido resistir a ponerle ese tÌtulo.
Como reciente switcher, acabo de pasar por el proceso de investigaciÛn de aplicaciones para la plataforma nueva, y la verdad es que los posts del tipo "øQuÈ hay en mi dock?" me han ayudado bastante a descubrir muchos programas que ahora me resultan imprescindibles.