Es una aplicación que vale 399€ y que no tiene versión en español. Pero el problema es su extrema lentitud (en mi caso, después de tres horas de empezar la creación de un proyecto que contiene unos 340 ficheros PHP, más CSS y algún HTML, el proceso estaba en el 5%)  y sus constantes bloqueos trabajando con servidor FTP. Si la usas en ficheros locales funciona bien, pero claro eso vale para entornos de test, pero no para hacer cambios para sistemas en un servidor remoto.

Después de probar algunas recomendaciones: desactivar el analizador semántico, cambiar la librería base de PHP 5.3 a PHP 5.2, forzar UTF-8, etc. No he notado ninguna mejoría.

Este error está siendo criticado en los foros de la propia empresa. Y yo por mi parte, tendré que dejar este Zend Studio 7 en la nevera hasta que alguna actualización lo solucione. Una pena, porque el producto promete.

La aparición de los ultraportátiles y los teléfonos o “dispositivos tipo iphone” con conexión a Internet en cualquier lugar y una menor potencia de cálculo que cada vez son más habituales, van a acelerar el proceso de implantación de herramientas de ese tipo.

Las aplicaciones sobre SAAS (software como servicio) basadas en la nube y los productos de desarrollo para la creación de estas aplicaciones de software son la temática de Saasmania, un blog que he descubierto hace poco, pero que sigo para estar al día sobre este tema.

Me parece un blog muy recomendable, con buen contenido, hasta el momento sin publicidad y profundidad en los artículos (para empezar os recomiendo el de las predicciones para 2009).

Buena suerte.

Son charlas con gente de bastante nivel, hasta ahora gente como Tony Lucas de Amazon, hablando de Amazon Web Services, Adam Gross de salesforce.com hablando de cloud computing, Edwin Aoki de AOL, etc.

En cualquier caso, para los que no vamos a acudir, en la página del evento hay vídeos, podcasts, en incluso transcripciones por RSS.

Vía el blog de Joel Spolsky.

El único requerimiento que tenía es que la base de datos debía ser SQL Server porque ya se utilizaba en producción. A partir de aquí podía decidir sistema operativo, servidor web y lenguaje sin ningún problema.

Hace un tiempo desarrollé con Ruby on Rails y fue la primera opción que valoré pero la descarté porque si en un futuro necesitaba escalar es más complicado que con PHP y los resultados de velocidad de respuesta que hice en su momento me decían que era más lento.

Así que me dije: Apache+PHP, y como en el equipo de pruebas ya tenía instalado uno sobre Windows configuré PHP y me decidí a probar cakePHP antes que el framework de Zend.

Pues bien mi experiencia de momento es bastante mala. Supongo que toda esa gente que está encantada con cakePHP estará usando MySQL, porque desde luego con SQL Server para mí, ha sido un desastre. Os cuento:

1. Configuro una base de datos de prueba.
2. Asigno permisos y modifico el fichero de configuración de cake PHP.
3. Creo una tabla de pruebas.
4. Voy a la página de inicio y veo el mensaje de conexión Ok, pero aparece un error de lectura de la tabla del motor de base de datos donde se almacenan las tablas: INFORMATION_SCHEMA.TABLES.
5. Después de buscar soluciones a este problema y no encontrarlas, pongo un mensaje en Google groups, al fin y al cabo se supone que la ventaja de este tipo de software “Open source” es que tienes una comunidad que lo apoya.
6. Después de dos meses recibo un día en mi e-mail la solución y el problema está en que en elfichero mssql_dbo.php hay un error y en una comparación textual no se ha incluído el texto en idioma español. La solución está aquí (gracias seven).

En fin, no me parece correcto por parte de los programadores de cakePHP que ese tipo de comparación afectada por el idioma aparezca en un fichero que realiza las operaciones básicas de interacción con la estructura de la base de datos. Todavía no sé bien de la complejidad de cakePHP, ni estoy seguro de que esto se pueda separar correctamente, pero un error de este tipo porque la comparación del mensaje de SQL Server está en italiano e inglés y no en español, italiano e inglés; de entrada no parece hablar bien del framework y da que pensar si habrá otros problemas de este tipo con el idioma más adelante en un desarrollo.

En cualquier caso, emocionado, actualizo el fichero en cuestón y lo pruebo: este error se soluciona, pero aparecen otros. Esos os los contaré en mi siguiente entrega de este post.

Pues bien, yo estoy usando ahora la pantalla de mi portátil (15″) con un monitor 19″ panorámico y me pregunté si realmente era más efectivo, porque me parecía evidentemente que era más cómodo. Mi metodología ha sido la siguiente:

1. Prueba A: desarrollo de aplicación de escritorio.

• Trabajo: crear un formulario enlazado con base de datos consultado en 4 tablas diferentes y con un grid en maestro-detalle.
• Aplicaciones: Visual Basic 6. Utilizo un formulario estándar con 3 ADO Datacontrol y un grid que es TrueDBGrid versión 8. La base de datos es SQL Server 2005.
• Ventanas:
  • Visual Basic 6
  • Programa en ejecución
  • EMS SQL Manager como front-end de SQL Server.
• Tiempo de desarrollo con dos monitores: 46 minutos.

2. Prueba B: desarrollo web

• Trabajo: crear un página web que contiene un formulario con 240 listas desplegables (80 filas con 3 columnas con una lista en cada celda de una tabla) y que debe actualizar una base de datos mediante Ajax con el valor con el valor que el usuario selecciona. Hay que mostrar la lista actualizada desde la base de datos y junto a ella la fecha/hora de actualización por parte del usuario.
• Aplicaciones: Zend development studio 5 para editar los ficheros sobre un sevidor con Linux. La base de datos es MySQL versión 4.3. El framework de Javascript es Prototype.
• Ventanas:
  • Zend Studio.
  • Firefox.
  • php-myAdmin, como front-end de MySQL.
• Tiempo de desarrollo con dos monitores: 79 minutos.

¿Cuál ha sido el tiempo que he ahorrado con respecto al uso de un solo monitor?. Pues bien, básicamente como la cantidad de código no me obligaba a hacer demasiado scroll en ambos casos, el tiempo de mejora iba a estar en el salto entre aplicaciones, así que grabé las sesiones de trabajo en vídeo y conté los cambios de ventana.

En la prueba A cambié de ventana 38 veces, y en la prueba B, 93 veces. Ahora sólo quedaba calcular cuánto tiempo había ahorrado a tener 1 ventana en cada monitor, y después de varias pruebas lo cifré en 3 segundos. Eso significaría que en cambios de ventana, ahorré 1 min. 54 seg. en la prueba A y 4 min. 39 seg. en la prueba B.

Si a esto le añadimos que durante el trabajo reduces errores al poder, por ejemplo, ver los nombres de los campos de la base de datos mientras desarrollas, o hacer una traza del código mientras ves los resultados del programa en ejecución y añadimos 2 min. para la prueba A y 1 min. para la B, los resultados quedarían así:

Es decir, no llega ni más ni menos que al 8%. Que significa eso que por cada jornada de trabajo de 8 hrs. ganaríamos unos 40 minutos y unas 13 hrs. al final del mes, eso significa jornada y media aprox. Evidentemente esto no llega a lo que que el informe de Pfeiffer Consulting decía, pero bueno, al precio de los TFT del momento, se justifica más que de sobra el comprar un segundo monitor.

Además hay que contar factores como el cansancio visual que se reduce con monitores de mayor tamaño o la ergonomía, al no tener reducir los movimientos de ratón, no cambiar la vista de distancia focal al mover el puntero hacia la zona inferior del monitor y volver al centro, etc.

En resumen, si no lo teneis ya, mi consejo es que tengais un segundo monitor (o quien sabe, un tercero…). ¿Qué os parece la idea?

P.D.: Continuará…