Es una de las noticias tristes de fin de año, y es que desde el 1 de febrero de 2008 Netscape dejará de recibir soporte. Y qué mejor forma de decirle adiós al mejor navegador de todos los tiempos que escribiendo este post desde mi Netscape Navigator 9. Desde su primera versión Mosaic Netscape 0.9 hasta el actual Navigator 9, este navegador ha vivido momentos de gloria y decepción, pero creo que muy pocos dudan de estar ante uno de los mejores en la navegación web.

Pero no es un final tan amargo, ya que gracias a Netscape asistimos al nacimiento de Mozilla, la gran alternativa opensource al monopolio de Internet Explorer, y el nuevo Firefox 3 (aún en Beta) nos ayudará un poquito a no echar tanto de menos al potente navegador de la N. Le debemos mucho a Netscape por su aportación a la navegación por internet y a sus servicios a través de la web, podremos seguir conviviendo con parte de la herencia de Netscape en su portal AOL, y recibiremos actualizaciones del navegador hasta la mencionada fecha del 1 de febrero, pero a partir de entonces sólo nos quedará su recuerdo y todo su legado.

¡Netscape, nunca te olvidaremos!

Tras el “upgrade” de muchos usuarios de Mac OS X Tiger (10.4) a Leopard (10.5), los kernel panics en el arranque se convirtieron en el error de moda para todos aquellos usuarios que teníamos instalado el Cisco VPN Client 4.9.01(0050) o inferior. No eran casos aislado. Todo parecía solucionarse con la inmediata nueva versión por parte de Cisco, la 4.9.01(0080).

Efectivamente, en multitud de instalaciones limpias¹ de Leopard , todos los problemas con el cliente de conexión de Cisco desaparecieron. Pero usuarios, como un servidor, seguían teniendo problemas. En mi caso seguía teniendo los panics malditos y no podía arrancar mi MacBook Pro sin hacerlo en modo seguro, hasta que desinstalaba el cliente.

Unos días de la última actualización del cliente VPN a la 4.9.01(0100) y la esperanza de solucionar los problemas apareció en mí. Unos minutos después desapareció completamente… seguía sin poder arrancar mi Mac OS X con el Cisco VPN instalado. Era hora de mirar logs, googlear más profundamente, y ver lo que estaba pasando.

Los logs no lo dejaban claro, pero me parecía ver una relación entre el arranque de los interfaces de Parallels y el “cuelgue” sistemático del sistema operativo al arrancar el cliente Cisco. Hmmmm, interesante, googleemos las relaciones de Parallels y Cisco. La solución es bien sencilla. Aunque el error no era el mismo me solucionó el problema: simplemente editar /System/Library/StartupItems/CiscoVPN/CiscoVPN (los cambios en negrita):

........

StartService ()
{
    #disable fw0
    /sbin/ifconfig fw0 down

    if [ -d $CISCO_VPN_DIR ]; then
        ConsoleMessage “Starting Cisco Systems VPN Driver”
        kextload $CISCO_VPN_DIR
    fi
}

……

Todo empezó a funcionar a la perfección. En definitiva, deshabilitar el interfaz de red fw0 en el arranque del cliente Cisco, para evitar los conflictos que pudieran estar pasando. De todas formas esta solución es simplemente para evitar el pantallazo: Error 51: Unable to communicate with the VPN subsystem. Pero en el caso de mis panics también funcionó.

Probablemente mi problema residía en tener una versión antigua de Parallels, aunque decidí posteriormente por desinstalarlo completamente y dejar como sistema único de virtualización VMWare Fusion, debido también al desuso que estaba sufriendo Parallels en mi sistema.

Moraleja: Si estás sufriendo panics con las últimas versiones del Cisco VPN Client compatible con Leopard, limpia tu Mac OS X de cualquier resto que haya dejado Parallels. Y si es necesario tenerlo instalado, reinstálalo desde cero y deshabilita el interfaz fw0 si sigues con más problemas.

1. Instalaciones realizadas desde cero, sin actualización desde Tiger [↩]

Aprovechando los últimos posts de Javi sobre programación y entornos de desarrollo en Java, y mi experiencia actual en este mundillo, dejaré aquí algunas referencias de JDeveloper de Oracle para desarrollo de Aplicaciones Web y otras funcionalidades, trabajando sobre Mac OS X. Para todos aquellos que no hayáis oído sobre JDeveloper, simplemente comentar que es un entorno de desarrollo y despliegue de aplicaciones Java y Web Services, con una perfecta integración para desarrollar con conexiones sobre bases de datos y otras funcionalidades.

La última versión final de JDeveloper es la 10.1.3.3, completamente gratuita bajo las condiciones de licencia del OTN¹, aunque para los más atrevidos está ya disponible para descargar la versión 11g Technical Preview 2, con multitud de nuevas funcionalidades y mejoras.

JDeveloper es una aplicación Java 100%, por lo que su instalación no requiere de complicados métodos de instalación de paquetes binarios ni nada por el estilo. Una simple descompresión .zip nos crea un árbol de directorios con el ejecutable y recursos… ¡y listos!. En Mac OS X directamente es un paquete autocontenido .app, donde se encuentra toda la estructura del mencionado directorio. Gracias a esto JDeveloper es completamente cross-platform, al igual que otros entornos de desarrollo familiares. El único requisito que puede ser más complicado es tener listo nuestro sistema para funcionalidad completa con Java. De todas formas la documentación de Oracle de JDeveloper está bastante bien para no dejar cabos sueltos.

Llevo ya un mes “cacharreando” con este entorno de desarrollo y la verdad es que cada vez me gusta más, sobre todo para las exigencias de mi trabajo (conexiones a Base de Datos Oracle, despliegue para OC4J, entornos Web Services, etc…). La plataforma sobre la que trabajo es Mac OS X y de momento no he tenido ningún problema para trabajar con ello. Ahora, tras las indicaciones de Javi sobre Java 1.6 y Mac OS X, me queda por probar la funcionalidad de JDeveloper con la última versión de Java, cosa que haré en breve.

Pero buscando recursos por internet, me encontré con un tutorial del Apple Developer Connection muy interesante sobre el uso de JDeveloper 10g en Mac OS X. Es un tutorial donde usando una conexión a una base de datos² se crea una sencilla aplicación web en java para conectarse al esquema indicado y trabajar sobre él. Es un paso a paso muy ilustrativo para aquellos que somos iniciados en el mundillo JDeveloper sobre Mac OS X.

Recomiendo a todos aquellos interesados en el mundo de las aplicaciones web, que prueben esta útil herramienta de desarrollo, y si trabajáis sobre aplicaciones o entornos Oracle, más aún.

1. Oracle Technology Network [↩]
2. Los esquemas que usa son los de ejemplo incluidos en la Oracle Database 10g [↩]

Ayer mismo, tras tenerlo dos semanas en el limbo de los drafts por falta de tiempo para terminar de escribirlo, publiqué finalmente Your Java just went bad? Try a Soylatte!. En ese interludio, Fabrizio Giudicci, el autor del tutorial acerca de cómo hacer que Netbeans utilice el JDK 1.6 proporcionado por Soylatte, publicó un proseguimiento de su artículo inicial con instrucciones más sencillas para la versión 3 de Soylatte.

El caso es que en los comentarios al texto de Fabrizio he encontrado una solución mucho más elegante y obvia¹, para utilizar Netbeans 6 en Cocoa y poder compilar aplicaciones Java con el JDK 1.6. Lo que hay que hacer es instalar Soylatte como Framework de Mac OS X y configurar Netbeans para decirle que hay una nueva plataforma.

Asumiendo que habéis seguido los pasos del artículo primigenio, lo que habría que hacer ahora es bien sencillo:

• Copiar la distribución de Soylatte a donde residen los frameworks de desarrollo en Mac OS X:

  $ sudo mkdir -p /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte.1.6.0/Home
  $ sudo cp -R soylatte16-i386-r3/* /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte.1.6.0/Home
  

• Descargar nuevamente Netbeans 6. En principio sería posible deshacer los cambios que hicimos para que utilizase las X11 y Swing, pero es más sencillo simplemente reinstalarlo (al menos en mi caso)
• Desinstalamos la instalación previa de Netbeans 6 arrastrando la carpeta Netbeans que hay en /Applications a la papelera², e instalamos el Netbeans 6 que nos acabamos de bajar.
• Arrancamos Netbeans 6 y añadimos SoyLatte como nueva plataforma, yendo a Tools > Java Platforms > Add Platform... y seleccionando el directorio Home del nuevo framework.

Pretty easy, huh?

1. Los matemáticos dirían trivial, y los físicos evidente, pero como no se me ha ocurrido a mí me abstendré de utilizar ninguno de los dos términos [↩]
2. Mucho ojo con no despistarse y cargarse otras versiones de Netbeans que pueda haber instaladas. Igualmente no recomiendo borrar el directorio de preferencias de Netbeans, por conservar las personalizaciones que hayáis podido hacer [↩]

Ésta foto la tomamos este verano David y yo en el parking de Infinite Loop 1 en Cupertino, los Headquarters de Apple en California:

Es una pena que en las matrículas españolas no se admitan vocales, ¿verdad?

O de cómo instalar el JDK 1.6 en Mac OS X y sacar provecho de él configurando el nuevo y crujientito Netbeans 6 para que lo use por defecto¹. (Update: Tal vez queráis echar un vistazo también antes de hacer nada de lo que aquí se dice al post Otro Soylatte más (en taza de loza esta vez))

Últimamente hemos estado hablando algo en Venera7 acerca de JRuby on Rails y su conveniencia para los entornos empresariales. Una de las razones que lo hacen idóneo para ese tipo de despliegues es una cuestión de rendimiento, el cual mejora siempre con la última release del JDK. Así pues, siempre que sea posible, lo mejor será utilizar el JDK 1.6 junto con la última versión estable del compilador JRuby, que debería venir incluida con la última versión de Netbeans 6.

Si nuestra plataforma de desarrollo favorita es Mac OS X, desgraciadamente la versión oficial del JDK de Apple no avanza lo rápido que a los desarrolladores les gustaría, y a estas alturas de Leopard aún andamos con la versión 1.5 pese a que ya lleva un buen rato ahí fuera. Afortunadamente, siempre hay gente como Landon Fuller, que se ha currado un espectacular porting del JDK 1.6 de OpenBDS a Mac OS X y lo ha bautizado como SoyLatte². ¡Ya podemos disfrutar de las últimas mejoras en el JDK en nuestro Mac!

La instalación del nuevo JDK es muy sencilla. He seguido los siguientes pasos en mi Macbook Pro Intel que deberían funcionar en cualquier ordenador Apple sin problemas:

1. Primero me descargué la última versión en binario de Soylatte de la página oficial del proyecto. En mi caso no soy tan afortunado de tener un procesador a 64bit, así que pese a tener Leopard tuve que optar por la versión de 32.
2. Una vez descargado, deescomprimí el archivo tar.gz y lo arrastré a la carpeta /usr/local.
3. Para que Mac OS X reconozca por defecto el nuevo JDK, lo único que hay que hacer es añadir la ruta correcta a nuestro PATH. Para que el cambio sea permanente hay que hacerlo en el fichero .bash_profile que está en el home del usuario con el que habitualmente nos logamos al sistema. Además, nos aseguramos de que en la sesión actual estamos haciendo uso de él y de que funciona. Utilizando nuestra aplicación de terminal favorita (terminal o iterm son dos buenas opciones), hacemos un poquito de trabajo con la linea de comandos:

   $ echo "export PATH=/usr/local/soylatte16-i386-r3/bin:$PATH" >> ~/.bash_profile
   $ export PATH="/usr/local/soylatte16-i386-r3/bin":$PATH
   $ java -version Java(TM) SE Runtime Environment (build 1.6.0_03-p3-landonf_28_nov_2007_00_17-b00) Java HotSpot(TM) Server VM (build 1.6.0_03-p3-landonf_28_nov_2007_00_17-b00, mixed mode)
   

Bien, si hemos llegado hasta aquí todo está preparado para meterle mano a Netbeans 6.

Elegir un JDK específico en Netbeans es trivial; es una característica básica del IDE el poder seleccionar la versión del JDK con la que estamos trabajando. Sin embargo, para hacer funcionar Netbeans con Soylatte, hay que utilizar Swing bajo X11. No es tan bonito ni tan rápido pero, ¡funciona!

El autor de tamaño logro es Fabrizio Guidici, que en su blog detalla cómo hacer la configuración. Yo simplemente la estoy siguiendo en mi Mac con las últimas versiones disponibles y añadiendo mis propios comentarios.

Los pasos para hacer la configuración son los siguientes:

1. Obviamente, descargar e instalar la última versión de Netbeans 6. En el momento de escribir este artículo la versión final ya estaba disponible, así que es la que he usado. Lo mejor en ir a la página principal para obtener la más reciente.
2. Yo hice la instalación de Netbeans por defecto, así que el paquete debería estar en /Applications/NetBeans. Los paquetes de aplicación son navegables, así que me referiré al directorio sobre el que trabajaremos como $NETBEANS. Por comodidad, lo mejor es asignar a la variable el valor del directorio, así que en un terminal hacemos:

   $ export NETBEANS = /Applications/NetBeans/NetBeans 6.0.app/Contents/Resources/NetBeans
   

3. Editamos el fichero $NETBEANS/bin/netbeans con nuestro editor favorito (por ejemplo, vi) para quitar un par de lineas que dan problemas con Soylatte³. Las lineas a borrar son:

   -J-Xdock:name=NetBeans \
        '"-J-Xdock:icon=$progdir/../nb6.0/netbeans.icns"' \
   

4. Para terminar, especificamos la ruta a Soylatte en el fichero $NETBEANS/etc/netbeans.conf, editándolo y alterando el valor de la opción netbeans_jdkhome para que diga:

   netbeans_jdkhome=/usr/local/soylatte16-i386-r3
   

   Antes de guardar y salir, necesitamos hacer un cambio más en el mismo fichero para que se utilice el Look & Feel Swing en vez de Acqua, ya que si no Netbeans 6 tampoco conseguirá arrancar:

   netbeans_default_options=".... existing options.... --laf com.sun.java.swing.plaf.gtk.GTKLookAndFeel -J-Dswing.aatext=true"
   

Y eso es todo, ya podemos arrancar nuestro Netbeans 6, que lanzará el servidor X para poder funcionar. La selección de menús no va particularmente rápida, pero por lo demás el IDE es funcional.

Coda

Si bien usar Soylatte es una bocanada de aire fresco para los desarrolladores Java en Mac OS X, aún está el problema de tener a Apple con una estrategia menos que clara en lo que respecta a Java.

Java es una plataforma muy viva y crítica para cualquier desarrollo Enterprise. Son muchos los programadores que, atraidos por las ventajas de Mac OS X, en su momento se hicieron switchers. El problema es que el soporte a Java en Apple es cada vez peor (el caso de la falta de JVM en el iPhone es un flagrante ejemplo de ello). Es como si Apple ya se creyese con la suficiente fuerza como para descartar completamente a toda una plataforma y comunidad de desarrolladores y forzar una revolución en la plataforma de elección de la mayoría. El hecho de esta falta de soporte oficial está dañando la imagen de Mac OS X como alternativa viable, y está empezando a verse una vuelta a Windows de los desarrolladores Java.

Está claro que Java nunca será Cocoa en el entorno Mac OS X, pero no es tampoco el objetivo. El soporte de Mac OS X como plataforma de desarrollo Java tiene que mejorar porque la comunidad está ahí, la demanda existe y además los desarrolladores Java han sido hasta ahora grandes impulsores de la alternativa Mac.

La solución se ha demostrado sencilla. Si una sola persona puede solucionar el problema en su tiempo libre, una compañía debería hacerlo instantáneamente. Y si no, la opción es sencilla: ¡que Apple le haga una oferta a estos chicos!

1. El crédito del por qué de este artículo se lo tienen que llevar Nando y Mario de EGE, por mantenerme al tanto de tan estupenda noticia [↩]
2. De ahí el título en inglés; era mucho más fácil hacer la broma de esa manera. [↩]
3. Se trata de los parámetros de Mac OS X utiliza para poner el nombre del menú principal y el icono de la aplicación [↩]

Algo más de cinco meses de existencia del iPhone y todavía no ha conquistado Europa. ¿Lo hará cuando llegue a España? Hmmm… pero… para entonces ya tendremos Android o algún GPhone en el punto de mira, ¿no? Es ahí donde me planteo la pregunta del millón: ¿iPhone o GPhone? Aunque la respuesta pueda ser difícil para algunos, a mí me resulta muy fácil responder y decantarme por la versión de Google. Planteo mi punto de vista.

Apple ha conseguido lanzar un producto “revolucionario” en muchos aspectos. La integración de varios dispositivos en uno, el magnífico interfaz multitouch, un diseño útil y elegante, y “embeber” un Mac OS X en el teléfono, son grandes ventajas y aciertos en un mundo tan díficil como el sector de la telefonía móvil. Pero ahí se queda este nuevo gadget, digamos que esas son sus ventajas competitivas. ¿Eso es todo?

No, eso no es todo. El iPhone es un dispositivo con un lanzamiento a lo grande, arrasando en el mercado americano gracias a su revolucionario hardware… Sí, lo he dicho bien: Hardware. Hay que reconocer que el Mac OS X que ofrece el nuevo teléfono de Apple está bien, pero ha decepcionado a gran parte de los usuarios del dispositivo, sobre todo a aquellos que hemos manejado el Mac OS X de los Mac durante tiempo. Pero el verdadero problema es una visión de futuro.

¿De verdad nos vamos a creer que nadie más va a ofrecer un teléfono parecido al iPhone?

A mí no me cabe la menor duda de que aparecerán. Y creo que será entonces cuando el iPhone reciba lecciones de software. Creo que el señor Steve Jobs no estudió muy bien la historia de los teléfonos móviles en Europa y su evolución. Aquí, en el Viejo Continente, la revolución llegó de la mano de Nokia. ¿Fue gracias a esos “ladrillos” de la marca finlandesa, tan pesados como el monedero de mi abuela? No, señor Steve, fue el software de esos ladrillos quien revolucionó ese mundo, esos menús tan intuitivos, visuales y bien pensados para el manejo de cualquier usuario, cuando ningún otro fabricante lo ofrecía.

Pero esa facilidad de manejo la encontramos en el iPhone, dirán muchos. ¡Cierto, un gran interfaz!… Pero retrocedamos a la 2ª Revolución de Nokia, cuando nadie apostaba 0,03€ (o lo que es lo mismo, un duro) por el relanzamiento de los dispositivos, al tener todas las marcas un interfaz y operativo relativamente parecido. Lo volvió hacer con software, siendo Nokia en Europa el fabricante que más apostó por la tecnología Java y el desarrollo “open” para sus terminales móviles. Y esta vez el resto de fabricantes no tardó en responder y subirse al tren de Java, actuando con rapidez y no quedándose atrás.

Y precisamente el último conato de 3ª revolución, iniciada por Apple y su iPhone, es totalmente distinta. Aquí el software es muy cerrado, con una ligera intención de ofrecer un SDK de desarrollo a ciertas esquinas del mundo, pero cerrado. En la era de las aplicaciones, la productividad y optimización, Apple decide limitar las capacidades del software de su “revolución”, y no proporcionar la capacidad de aceptar funcionalidades nuevas a su dispositivo. ¡Qué gran error!

Menos mal que alguien se da cuenta de esto y unos chicos en Mountain View, CA, deciden apostar de nuevo por el mundo del software en la tecnología móvil. Estos chicos, precisamente de Google, detectan el gran error de Apple y deciden apostar de nuevo por el software y el desarrollo open para la nueva revolución. Dejemos a los fabricantes que ofrezcan hardware de última tecnología y nosotros les proveemos de una plataforma abierta, flexible y adaptable a sus dispositivos - pensarían en Google - . ¡Tocado, iPhone!

Puedo equivocarme, pero a mí me da que las cosas no pintan bien para el futuro del iPhone si siguen con su actual filosofía. Las espectaculares ventas del iPhone en EEUU están cegando a los encargados del desarrollo del dispositivo y siguen luchando contra la historia, quien nos demostró que las plataformas móviles cerradas y los contratos de exclusividad no ofrecen un buen futuro en Europa. Y peor aún cuando no son capaces todavía de ofrecer últimas tecnologías hardware de conexión móvil, como 3G o la nueva HSDPA.

Ahora todos deseamos un iPhone, pero no sé si esto será así cuando aparezca un GPhone o un Android Based Phone decente. Desde luego no lo creo si no cambian el rumbo del teléfono-iPod. Si todo sigue igual, preferiré Android, y si no, les daré las gracias a las magistrales lecciones de software.

¡Por fin un plugin decente demo Wordpress para el iPhone! WPhone es instalar y listo: al logarse en la página inicial de Wordpress aparece la opción de mobile login, y todo el interfaz de administración se muestra à la iPhone. Tiene algún pequeño fallo pero en general es mucho más usable que lo que había hasta ahora.

Como prueba, he escrito esto desde un iPhone con conexión GPRS en la cola de un vuelo a Lisboa, por ponérselo un poquito difícil.

Ahora sólo faltaría que el maldito cacharro tuviera cortar y pegar para poder poner URLs, hacer una edición de texto decentemente, y que no hubiera tanta gente en los aeropuertos los lunes por la mañana.

Hoy me he dado cuenta de algo muy curioso en mi MacBook Pro. Siempre noté que el ventilador de mi portátil se activaba cuando tenía la toma de corriente conectada y le daba algo de “caña” al equipo. Evidentemente me parecía algo normal. Pero estos últimos días había algo que no me gustaba mucho.

Cuando salta el salvapantallas del Mac OS X Leopard, el ventilador se activa y gira a altas revoluciones, o por lo menos el sonido así lo indica. La verdad, no me parece normal que cuando se activa el salvapantallas (supuestamente el sistema está, en cierta medida, más inactivo en lo que a pantalla se refiere) el equipo se caliente más de lo normal y necesite que los ventiladores refrigeren la placa.

Investigando un poco conseguí adivinar el rendimiento en CPU de mi salvapantallas al activarse. Tuve que hacerlo conectándome en remoto desde otro equipo, porque evidentemente, si lo hacía desde el MacBook Pro el salvapantallas se desactivaba. Es tan sencillo como hacer un ssh desde otro equipo en la misma red y una vez dentro del Mac OS X hacer un top desde el terminal.¡Voilá! ¡¡Mi salvapantallas me consume un 60% de CPU!! What the hell??…

¿Es normal? Pues a mí desde luego no me lo parece. No entiendo que una característica enfocada a mejorar el rendimiento de la pantalla me caliente demasiado el equipo. Mi salvapantallas, el Arabesque del Leopard, no es tan “saver” como en principio debiera, ya que, aunque “salve” mi pantalla, no puedo decir lo mismo de mi procesador. Al final tuve que cambiar a un salvapantallas más simple… ¡qué remedio!