Diario de Programación

De este post del foro, sale un ejemplo curioso de java. Fíjate en el siguiente código

public static void main (String [] args) {
   Integer a = 100;
   Integer b = 100;

   System.out.println(a == b);
}

Pues bien, este ejemplo da como resultado "true". Si cambias los valores de a y b (pero manteniéndolos iguales), verás una cosa curiosa. Para valores entre -128 y 127, el resultado es "true". Para valores fuera de ese rango, el resultado es "false".

El motivo podemos encontrarlo en este post sobre Auto-Boxing del Weblog de Victor Ramirez. Teóricamente las instancias de Integer que se crean de forma más o menos automáticamente en esas asignaciones deberían ser distintas y el == debería dar siempre "false". Pero por eficiencia, el compilador reaprovecha instancias de estas clases, de forma que cuando se hace este tipo de conversión (de un tipo primitivo a un objeto Integer, Boolean, o lo que sea), se tiene que == da "true" en los siguientes casos:

• Siempre en los Boolean y en los Byte
• Entre -128 y 127 en los Short e Integer
• Entre u0000 y u007F en los Character.

Una curiosidad que puede dar muchos quebraderos de cabeza a un programador novato que no tiene muy controlada la diferencia entre el método equals() y el ==.

Nuestros proyectos suelen ser de larga duración (dos años los que menos) y cuando empezó la crisis a nuestro departamento no le afectó mucho, teníamos proyectos y trabajo para alrededor de dos años. Pero dos años después empezamos a sufrirla, los proyectos están terminándose y durante este período no se han contratado más. Así que andamos buscando trabajo en otros departamentos de la empresa y van cayendo algunas cosas, y proyectos que no son "como siempre".

El banco automático de pruebas que me cayó en su día es uno de esos proyectos de otros departamentos. Su duración prevista era de unos tres meses y debo tenerlo terminado en Julio. Mi parte de software va bastante bien, pero el banco lleva mucho hardware (instrumentación electrónica, conectores, cables, aparatos variados, incluso un "armario" para montarlo todo) y creo (sé seguro) que todo eso van a retrasarse. Supongo que tengo trabajo de integración con todo ese hardware al menos hasta Septiembre. El lenguaje de programación para el banco lo elegí yo y pensé en LabWindows/LabView, pero visto el corto plazo y que el protocolo SCPI de control de instrumentación es bastante simple, decidí hacerlo en java.

Y pasado Septiembre … ya me tienen buscado otro proyecto. Este es en .NET, así que me toca aprender un lenguaje nuevo. Espero sólo un par de cosillas:

• Que me metan en el proyecto a un nivel de "currito", de forma que pueda programar y aprender .NET. No sé qué me han comentado de requisitos y zarandajas varias, así que me veo más con el Word que con el .NET. Bueno, en ambos casos es Microsoft.
• Que el proyecto dure lo suficiente (fecha prevista Septiembre de 2011) como para aprender bien .NET. Supongo que podré hacer cosas en .NET en cuestión de semanas, pero sé por experiencia que pueden pasar años hasta que aprendes a hacer las cosas correctamente y ni aún así, siempre estás aprendiendo. De hecho, esta frase "
  Sigo pensando todo de nuevo mil veces y todavia encuentro mejores maneras de hacer lo mismo. Creo que ya tenemos todas las soluciones al igual que lo creia 8 años atras" del blog de Lucas Ontivero creo que refleja perfectamente lo que quiero decir.

Ya me veo añadiendo un apartado en algún sitio de esta web sobre .NET

La aplicación de bicis a la carta que le estoy haciendo al de la tienda de bicis todavía no está en marcha, falta básicamente subir un catálogo de piezas y clasificarlas (depende más de él que de mí), aparte de arreglillos/añadidos que vaya haciendo. De todas formas, ya he empezado a amortizarla.

El otro día se me ocurrió dejarle la bici a mi hija de 13 años y se ve que se le cruzó un árbol en el camino y se dio contra él. Un rasguño en el brazo, uno de los cables del freno a la porra, tirita a la niña y la bici a la tienda.

Pues nada, le ha cambiado el cable del freno, la probó, le cambió también los cables de los cambios, un buen engrase, la ha tratado con cariño y me ha hecho un buen descuento: no me ha cobrado. Voy a tener que ir poniendo alguna cosa más en la web.

Cuando empezó la crisis, debe ir ya para dos años, noté una bajada importante en los ingresos de google adsense. No sé si la gente se anunciaba menos, pagaba menos por los anuncios o se hacían menos clicks porque la gente no estaba muy por la labor de comprar. 

Desde entonces, el número de visitas ha ido subiendo más o menos de forma constante, pero los ingresos se han mantenido igual de bajos. Así que el otro día, en un rato de aburrimiento, decidí investigar sobre cómo se podían mejorar estos resultados. Me encontré, por supuesto, con los típicos consejos estándar de jugar con los colores de los anuncios, sus posiciones en la página, etc, etc. Pero investigando un poco más, encontré dos puntos que son realmente importantes.

Temática de la página

Google adsense paga por click en un anuncio y de acuerdo a lo que el anunciante esté dispuesto a pagar por ese click. Este punto es posiblemente el más importante. Es más probable que la gente haga click en nuestros anuncios si viene a nuestra página con intención de comprar algo. Y nos pagarán más por ese click si el anuncio es sobre algún tema donde se maneje dinero en serio.

Por ejemplo, si nuestro sitio va sobre hipotecas, móviles, coches o turismo, es muy posible que la gente que caiga en nuestra página esté mirando precisamente una hipoteca para comprarse un piso, cambiar de móvil, de coche o irse de vacaciones. Por ello, los anuncios de google adsense de nuestra página, que son relativos al contenido de la página, tienen grandes posibilidades de resultarle interesantes al visitante y que haga click en ellos. Además, como son sectores que manejan dinero y con fuerte competencia, es muy posible que los clicks en esos anuncios se paguen bien.

Pero, ¡pobre de mí!, ¿qué pasa si el sitio es sobre java?. Los que acaban en esta página suelen ser estudiantes o gente recién incorporada al trabajo que todavía no tienen mucha experiencia en programación. Normalmente buscan resolver alguna duda o problema de java y no tienen intención de comprar nada. Encima, los posibles anuncios sobre temática java suelen ser herramientas/IDEs de java, casi todos gratuitos, o cursos de java. Nada que mueva grandes cantidades de dinero o por lo que los anunciantes estén dispuestos a pagar mucho por click.

Así que lo más importante de todo es principalmente la temática del sitio. Eligiendo una temática adecuada y consiguiendo no pasar desapercibido en los buscadores, se pueden conseguir ingresos importantes con relativa facilidad. El problema de los temas de dinero es que hay mucha competencia, por lo que salir adecuadamente posicionados en los buscadores puede ser una tarea difícil.

Burro grande, ande o no ande

En este tema, afortunadamente, si he podido jugar y en un par de semanas he comprobado un aumento apreciable (pero no espectacular) en los ingresos.

El consejo que he leído es que si google adsense permite tres anuncios, pongamos los tres anuncios. Cuantos más anuncios tengamos en la página, más fácil que uno interese al visitante. Y que el anuncio sea lo más grande posible, en concreto la caja grande de 336×280. Esta caja es la que estadísticamente tiene más porcentaje de clicks.

Así que lo he aplicado, no en este blog, pero sí en otras partes del sitio. Y aunque me da la impresión de que pueden molestar un poco (ocupan demasiado sitio), sí es cierto que los ingresos han aumentado alrededor del 50%,

Y google sigue loco

Y aunque no tiene que ver con el tema de los ingresos, sigo viendo que google cada vez está más loco. Ahora los ingresos se pueden ver en la interfaz antigua de google adsense, en la interfaz nueva de google adsense e integrados con los informes de google analytics. Pues bien, cualquier parecido de los ingresos mostrados entre las tres interfaces es pura casualidad. Es más, dentro de una misma interfaz obtengo resultados distintos según quiera ver los resultados de los 3 últimos meses o de los 12 últimos meses.

Google analytics me indica que no se ha mostrado ningún anuncio de google ni se ha obtenido ningún ingreso en los dos últimos días en la chuwiki. En los gráficos que muestra se ve una línea más o menos horizontal con una bajada brusca a cero en los dos últimos días. Google adsense dice que sí y de hecho los resultados son los habituales, no ha habido ningún cambio en estos dos últimos días, todo sigue normal. No sé, quizás se deba a que ahora google muestra también anuncios de otras compañías de anuncios y estos no se contabilicen igual en las dos herramientas.

En la interfaz vieja de google adsense, si consulto los pagos de los tres últimos meses, sale en la primera línea un "saldo pendiente de meses anteriores", que curiosamente se suma en toda la columna, pero no en la de pagos. El resultado es que si según eso me deben X€, me pagan "X-saldo pendiente de meses anteriores"€ y siempre está ese saldo pendiente. Si ahora en la misma interfaz consulto 12 meses de pagos, ese saldo pendiente es cero y todo cuadra bien. Esto sí tiene pinta de ser un "bug" o, al menos, no encuentro una forma de explicarlo.

Y entre la interfaz vieja y la nueva suele haber diferencias no muy grandes en los euros. Lo achaco a que quizás una interfaz y otra miren el cambio de día a distintas horas (una en la española y otra en la americana, por ejemplo) y la diferencia se deba quizás a que aunque en ambos casos midan periodos de tiempo iguales, lo hacen con desfase de unas horas. En cualquier caso, despista.

Tampoco he visto grandes "revuelos" por todo esto en blogs o foros, así que me imagino que serán cosas mías.

Todos nuestros sistemas se parecen, unos llevan determinados módulos, otros no. Por eso, siempre he estado pensando la forma de hacerlos modulares de forma que sea fácil quitar o poner módulos de un sistema a otro, cada uno con su configuración. Cuando me puse a pensar en ello llegué a la conclusión de que sería buena idea hacer que cada módulo fuera un jar, independiente de los otros. Luego, en un sistema, es cuestión de instanciar y configurar aquellos módulos que nos interesen, trayendo sólo los jar necesarios.

Puesto que los módulos interaccionan entre ellos y cuando uno de ellos quiere hacer algo normalmente necesita datos de otro módulo, o a veces cuando un módulo genera algo necesita avisar a los otros para que sigan el proceso, también me puse a pensar en ello. Una especie de mecanismo de suscripción de eventos, de forma que en algún sitio cerca del main, donde se instancian y configuran módulos, también se hicieran suscripciones a determinados eventos de un módulo y se avisara de ellos a los otros módulos.

Afortunadamente, antes de ponerme a codificar algo como esto, se me ocurrió investigar por internet y me encontré con los contenedores de inversión de control y en concreto con Spring Framework. Aunque el framework está muy pensado para aplicaciones web, está bien diseñado y puedo bajarme y usar sólo el núcleo, lo que me permite a través de ficheros XML instanciar los distintos módulos, configurarlos y hacer que se vean unos a otros. También me proporciona un sistema de publicación y suscripción de eventos entre módulos. Justo lo que quería.

Así que como suelo hacer en estos casos, cogí a un grupo de gente afín a mis ideas peregrinas, les conté lo fácil y bien que podiamos usar Spring Framework en nuestras aplicaciones y lo usamos en uno de los proyectos que empezaban. La experiencia fue buena y todos quedamos bastante contentos en general, así que decidimos ir aplicándolo a más proyectos.

Pero al empezar a usarlo en más proyectos e involucrar a más gente, empecé también a encontrar más oposición y otros puntos de vista. Un compañero mío más crítico que yo con las innovaciones comentó que "Spring no es más que una forma "friky" de hacer news". No obstante, él también andaba buscando una forma de configurar con ficheros sus módulos, ya que se ve repitiendo código de configuración prácticamente igual de un proyecto a otro.

Y el otro día sucedió algo que me ha hecho empezar a dudar de la utilidad de Spring Framework, al menos usando sólo el núcleo y en aplicaciones de escritorio. Este compañero en uno de los proyectos en los que tiene cierta responsabilidad me dijo que se estaban instanciando en Spring dos módulos iguales con configuración distinta, pero que habían cambiado los requisitos y debíamos eliminar uno de ellos y cambiar el otro por un tercero distinto. Nos pusimos a ello.

Borrar uno de los módulos es fácil, sólo hay que ir borrando las referencias en los ficheros XML y en algunos sitios muy concretos del código. Cambiar el otro fue algo más complejo, buscarlo para reemplazarlo, cambiar nombre de clases, parámetros a inicializar, buscar referencias para ver si son compatibles, etc, etc. Una vez que creímos todo estaba hecho, arrancamos la aplicación y nos saltan un par de errores, nos habíamos equivocado en el paquete de una de las clases de un bean de Srping Framework. Más cambios, nueva prueba y nuevo fallo. Esta vez, a la tercera fue la vencida y todo funcionando. Pero mi compañero hizo el comentario que me metió la duda en el cuerpo: "Si en vez de hacer los news y la configuración en ficheros XML los hubieramos hecho en código, todo esto habría cantado en el mismo IDE. Prefiero ver los errores mientras escribo que verlos después arrancando la aplicación".

Y tiene razón, hacer news y configurar en XML tiene la pega de que errores que se verían inmediatamente mientras escribes en el IDE (un new de una clase que no existe por ejemplo, o la llamada a un set para configurar algo) no los vemos hasta que arrancamos la aplicación.

Hay un plugin para eclipse que permite ver si lo que escribes en el XML de Spring es correcto (las clases existen, los métodos existen, etc), pero no lo tenía instalado y lo de que hayan cogido Spring los de SpringSource, me da "mal rollo", parece que se quieren dedicar a cobrar por dar cursos y que este tipo de plugins o incluso las descargas están cada vez más escondidas previo registro.

Instalaré el plugin, miraré la posibilidad de hacer un test de JUnit que verifique que un XML de Spring es correcto y a ver qué pasa. De todas formas, empiezo a pensar que sólo para hacer news no merece la pena. Me queda el tema de los eventos al que sí sacamos partido….

 Llevamos ya varios años usando maven y nos hemos acostumbrado a él. Recordamos ahora cómo teníamos antes los proyectos y nos asombramos de la mejora conseguida. Sin embargo, no todo es bueno con maven, tiene sus pegas.

Ventajas de maven

Hay principalmente tres grandes cosas que hemos conseguido con maven y sin las que ahora no seríamos capaces de trabajar.

La primera es que ahora todos nuestros proyectos están organizados igual. Esto, por supuesto, puede conseguirse con disciplina y sin necesidad de maven, pero en grupos numerosos de desarrolladores es más fácil de conseguir si la herramienta te obliga a seguir una estructura o al menos, si te obliga a hacer un esfuerzo importante si te quieres salir de esa estructura. Se acabó el  hacer scripts de compilado, el preguntar a otro cuando cambias de proyecto dónde están las cosas, el dejar ficheros o iconos por cualquier lado. Ahora cualquiera puede pasar de un proyecto a otro y sabe manejarse por la estructura sin ningún problema.

La segunda gran ventaja son los jar. Al dejar todos los jar de los proyectos en un repositorio centralizado (usamos nexus) y usar versiones SNAPSHOT de maven, todos tenemos siempre disponibles los últimos jars. Antes era necesario que cada uno compilase los jar que  necesitara o se los pidiera a alguien que los tuviera, o que alguien se acordara de meterlos en el sistema de control de versiones. Eso ya no es necesario, maven/nexus se encarga de que todos tengamos siempre los últimos jars.

Y la tercera gran ventaja es la herramienta de integración continua (Hudson), que todas las noches saca los fuentes del sistema de control de versiones, los compila y pone los jars en nexus. Al ser hudson el encargado de meter los jar en nexus, estos siempre están actualizados y siempre está disponible la última versión para todo el mundo. Y al ser hudson el que compila en un servidor separado, eliminamos por un lado los típicos errores de código que sólo compila en el PC del desarrollador Fulanito porque inadvertidamente ha puesto un path suyo local en algún sitio, o se ha olvidado de meter algo en el sistema de control de versiones. Este Hudson nos sirve además para obtener de él las versiones de instalación tanto para el entorno de producción como para pruebas. Ya no dependemos de que alguien tenga todo lo necesario para generar estas versiones y de que ese alguien esté.

Pegas con maven

Pero no todo son ventajas. La gran y enorme pega de maven es su dependencia de que haya internet o al menos red, para acceder al servidor de Hudson. Los problemas con la red suelen ser relativamente frecuentes: se va el servidor de nexus por el motivo que sea, se cae algún proxy o router, etc, etc. En esos casos, se nos queda un poco parado el tema de compilado. Sí, maven tiene una ejecución off-line, pero no funciona todo lo bien que debiera. Si le falta algo, se empeña en ir a buscarlo a través de la red.

Y esta dependencia de la red se nos hace especialmente grave cuando vamos a instalaciones del cliente en los que no hay internet ni, por supuesto, acceso a nuestro nexus. Si queremos llevarnos un entorno de desarrollo para depurar, corregir algún bug y compilar en las instalaciones del cliente, nos obliga a llevarnos toda una copia de repositorios, o montar el proyecto de forma totalmente independiente de maven. Hay comandos de maven que ayudan a hacer toda esta copia, como dependency:go-offline, pero hay que acordarse de hacerlo.

Es bastante molesto también el tema de plugins de maven. A veces y sin saber el motivo, maven decide que debe actualizar plugins a versiones más modernas. En la mayoría de los casos esto no afecta demasiado, pero a veces si coincide con algún tipo de problema de red o el estar off-line, nos hace imposible compilar.

En fin, desde luego las ventajas compensan con creces los inconvenientes y ni se nos pasa por la cabeza dejar de usar maven, pero a veces algunos problemas misteriosos pueden tenerte de pelea con ellos toda una mañana.

 Soy aficionado a salir en bicicleta los domingos y llevo varios años haciéndolo. Pero a diferencia de otros muchos aficionados, no soy en absoluto aficionado a la bicicleta en sí misma. Cuando llego de uno de mis paseos, la cuelgo en la terraza y me olvido de ella hasta el siguiente Domingo. No la engraso, ni la limpio, ni la miro. En cuanto tengo cualquier problema más allá de un pinchazo, suelo llevarla a una tienda de bicis de barrio. El dueño es muy amable y se ha ganado mi confianza desde la primera vez que fui por la tienda, después de llevarme un cabreo con los del Decathlon.

En cierta ocasión vi que la tienda tenía una página web, así que en una de mis visitas se lo comenté. El dueño me dijo que no andaba muy contento con los que se la habían hecho y que si yo sabía algo de eso, que le hiciera un presupuesto para llevarle yo la página web. Bueno, no es lo mío, sólo llevo la mía por hobby, tampoco soy autónomo así que no podría darle factura y encima soy vago. Una cosa es "jugar" con mi página web cuando tengo ganas y otra es comprometerme a algo. Así que lo dejé correr. De esto debe hacer ya cerca de dos años.

Pero hace poco volví a visitar la web y vi cosas que no me gustaron nada. Enlaces internos rotos, fotos que no salen y la página muy parada, en dos años apenas había nada nuevo. Así que le envíe un correo al dueño diciéndole que podía arreglarle la página y que siempre que fueran cosas puntuales y sin mucho trabajo, no le cobraría. Me conformaría con algún descuento/regalo en los arreglos que me fuera haciendo en la bici. Vaya, un trueque. Así que quedamos para un café … y me llamaron la atención varias cosas.

Lo primero es "hacer negocios" con gente de un negocio totalmente distinto al tuyo. Si le pregunto con quién tiene contratado el dominio y el hosting o cómo accede al panel de control, pues pone la misma cara que cuando él me comenta a mí que en una bici a medida se seleccionan unos treinta tipos de piezas y que la junta de la trócola no forma parte de ellas.

Y por otro lado, yo iba con mi idea de arreglarle un poco la página, ponerle un os-commerce para que tuviera un carrito de la compra o incluso un foro en el que la gente pudiera preguntarle on-line si tiene tal o cual pieza, cuánto tardaría en conseguirla o el precio. Pues bien, no tiene tiempo para atender el foro adecuadamente y lo del os-commerce le da igual porque casi todas las tiendas de bicis tienen y el que compra on-line al final se va al más barato, que suele ser alguna gran superficie. El lo que quería es algo que muy pocas tiendas de bicis tienen y es que un cliente pueda hacerse una bicicleta a medida, eligiendo las piezas del catálogo y hacer el pedido sobre ello. Es más, tampoco quiere que esa aplicación esté abierta al público en general, sino que sólo puedan acceder ciertos usuarios a los que él dé de alta y que hayan pasado previamente por la tienda, es decir, clientes conocidos.

Así que me pareció entretenido y a ello me he puesto. Llevo ya un par de semanas a ratos libres desempolvando mi php y me he creado un proyecto de bicis a la carta en GitHub, donde he subido una primera versión, más o menos funcional, pero todavía con faltantes y algunos ideas pendientes. A la vuelta del verano le llevaré mi bici para que le haga una revisión general por debajo del barro que tiene acumulado desde el invierno.

Por cierto, entiendo que sólo le interesen esos pocos clientes conocidos que "suelen" comprarle bicis a medida. Jugando con la aplicación y un catálogo real, haciendo bicis de forma aleatoria, no me ha bajado ningún precio de los 2000 €.

 Una pequeña estupidez. Cuando empezamos a teclear algo en google para buscarlo, se nos abre un desplegable con las frases que más hay en la web, de forma que si vamos a buscar lo "normal", lo tenemos más fácil. Pues bien, si vamos tecleando "tengo 1….", vemos que las preocupaciones de la gente de diez años para arriba van todas por el mismo lado

Lo que me gustaría saber es si realmente hay tanta gente que busca "tengo 13 años y mi papa me pego porque me arrestaron por borracha stoy muy molesta". Creo que google a veces se lía un poco con tanto dato.

Visto en Emezetablog.

Allá por Noviembre del año pasado comentaba que había superado el límite de tráfico (20 Gigas de transferencia mensual) de mi sitio web. Como comentaba, me apresuré, quizás demasiado, a ampliar el plan de hosting al siguiente, con un límite de 30 Gigas.

Pues bien, este mes pasado de Mayo mi tráfico mensual ha superado los 28 Gigas y las estadísticas de google analytics dicen que la cosa sigue subiendo. De todas formas, en Julio y Agosto suele caer mucho, ya que imagino que la mayoría de las visitas son estudiantes y programadores recién salidos incorporados al trabajo.

Así que de nuevo me apresuré. En su momento blaxter me aconsejó dinahosting, pues allí me he ido a mirar. Por algo menos de lo que estoy pagando ahora, me dan 90 gigas de transferencia mensual y, por supuesto, más disco, bases de datos, correos, subdominios, etc. Buscando opiniones veo que en general son buenas y es considerado un hosting serio. Nuevamente me apresuré a no pensar y contratar un plan de hosting con ellos. Y ya puestos, un dominio nuevo: chuidiang.org.

Rápidamente migré la chuwiki (que se lleva cerca de un tercio del tráfico) al nuevo dominio y un par de drupales que tenía para jugar, pero ya me está dando pereza migrar el resto, así que seguro que me voy a tirar pagando dos hosting unos cuantos meses. Y encima con el verano al llegar.

Aprovecho aquí para comentar también mi escasa experiencia (un par de días) con dinahosting. En cuestión técnica todo muy bien, incluso me ha asombrado algún detalle. Los "peros" son todos más cosas de gustos propios míos que problemas reales, así que no me hagáis mucho caso.

Me ha gustado la rapidez con la que se puso el tema en marcha. Me di de alta en dinahosting, puse los datos de mi banco … y en menos de cinco minutos recibo el correo de que está el dominio y el hosting en marcha. Y efectivamente, así es.

Dan acceso ssh, pero no conseguía entrar, así que mandé un correo al soporte y en media hora me contestaron. Era una chorradilla y ya puedo acceder al ssh, cosa que me encanta puesto que si estás acostumbrado a los comandos unix, te permite mucha más velocidad a la hora de andar rebuscando por los ficheros, moverlos y en general, hacerles perrerías.

En cuanto a los "peros":

No me ha hecho gracia tener que pagar el año completo de un solo golpe. Quizás hay alguna opción de pago mensual, pero no la he visto y parece que hace más daño pagar 150 € de golpe que 10 € + IVA al mes (el resto es el dominio). Tampoco me ha hecho mucha gracia tener que registrarme ANTES de contratar el hosting, pero bueno, es una tontería mínima, porque al final acabas registrado lo mismo.

Las passwords tampoco me hacen gracia. En la de acceso a mi panel de control y en las de bases de datos no permiten caracteres que no sean letras y números. Yo tengo la manía de meter caracteres "raros" (dentro de los primeros 128 caracteres ascii estándar) en la password y no me ha dejado. Sin embargo, en la de ftp y ssh sí lo permiten. Esto me ha supuesto un ligero contratiempo al migrar los drupales, que no guardan la password en claro en ningún fichero php, sino que la guardan encriptada, y no he podido poner en la base de datos la misma password que tenía antes. Me las he tenido que ingeniar para poner una nueva password en base de datos, conseguir su encriptación y reemplazarla en el php de drupal.

El panel de control tampoco me gusta demasiado, quizás por estar acostumbrado a cPanel, quizás por algunos detalles. No tiene posibilidad de navegar por los directorios/ficheros, por lo que la única forma de subir o editar ficheros es a través de ftp o ssh. A veces es útil subir un fichero concreto o editarlo ahí mismo. También es útil subir un zip y desempaquetarlo desde ahí mismo. Con dinahosting tienes que subir el zip con ftp y luego entrar con ssh para desempaquetarlo. También veo algo lenta de carga del panel de control y de las distintas aplicaciones que hay en él: sale hasta barra de progreso y todo. La creación de subdominios no es complicada, pero tampoco es trivial como lo es en cPanel.

Y en cuanto al problemilla con el acceso al ssh…. la documentación de dinahosting pone que la password es la misma que la de acceso al panel de control. Pues no, el de soporte me dijo que era la misma que para ftp y así era.

Así que nada, a llenar el nuevo sitio lo antes posible y a por los 90 Gigas.

CORREGIDO: Bueno, al final lo que comento aquí es cierto, me ha pasado, pero ha sido culpa mía. Los <form> que comento tienen un <select> con varias <option> y se me había olvidado cerrar los <select>. Corregido eso, todo funciona correctamente. Así que me castigaré a mi mismo a usar internet explorer durante un mes.

 No recuerdo dónde leí a alguien que le daba este nombre, "el maligno" a internet explorer. Cualquiera que se haya peleado un poco con CSS y se haya preocupado de que su página web se vea bien en los distintos exploradores, estará de acuerdo en lo apropiado del nombre. De todos es conocida la manía de Microsoft de saltarse los estándares y de interpretarlos libremente, por decirlo de forma fina.

Pues no solo con CSS es el problema. Estoy haciendo una paginilla web para un amiguete y me he encontrado otro problema con los formularios <form>. No sé muy bien el motivo (aunque lo intuyo) y desde luego no funciona bien con internet explorer, pero sí con chrome y fifefox.

El problema es el siguiente. En una misma página index.php tengo varios formularios <form>, cada uno con campos distintos y cada uno con su propio botón de submit. Todos ellos hacen submit a la msma página index.php, menos el último de ellos que hace submit a otra página pedir.php

La primera diferencia de internet explorer ( versión 8 ) con los otros navegadores es que cuando pulso submit, la página receptora tiene acceso a todos los campos de todos los formularios en $_POST (uso method="post"), mientras que en firefox o chrome sólo tengo acceso a los datos del formulario sobre el que he pulsado el botón submit. Bueno, no me representa un especial problema porque como he comentado, todos los campos de los formularios son distintos, pero intuyo que puede ser un problema si hubiera campos con el mismo nombre en distintos formularios.

Y la segunda diferencia, esta sí más puñetera, es que el botón submit del último formulario, el que supuestamente reenvía a una página pedir.php, no lo hace. Ese submit en internet explorer envía a la misma página que todos los demás, index.php. En firefox y chrome funciona bien, cada submit envía a su página. Esto posiblemente está relacionado con el problema anterior. Es posible que si internet explorer considera los varios formularios <form> como un único mega-formulario, quizás no admita que varios <form> tengan atributos action distintos. No he probado a poner el action en cada submit concreto.

Este último problema lo he solucionarlo usando un poco de javascript

<input type="submit" onclick="this.form.action=’pedir.php’;this.form.submit()" …

que básicamente es decir cual es el action con javascript y no dejarle al internet explorer que lo interprete a su peculiar forma.