HTC contraataca contra las demandas de Apple con la ayuda de Google

Supongo que a estas alturas no es ninguna noticia para nadie que en el último año las demandas por temas de patentes entre las plataformas móviles (sobre todo entre Android, iPhone y Windows Phone) no han parado de incrementar. Para poner este problema en contexto, os recuerdo una noticia que habíamos publicado recientemente donde explicábamos que Microsoft gana cinco veces más dinero con Android que con Windows Phone 7 por las licencias de las patentes.

En esta guerra de las patentes, Google (y Android por extensión) comenzaron desde una posición muy débil, ya que Google tiene muchas menos patentes que sus rivales (Apple y Microsoft). Por ello en los últimos meses Google ha estado intentando reforzar su portafolio de patentes, destacando en este sentido la reciente compra de la división de movilidad de Motorola. 

Está claro para cualquier observador que el "canijo y enclenque" Google lleva un tiempo "metiéndose esteroides y yendo al gimnasio" para poder competir en igualdad de condiciones con sus rivales en el "ring de las patentes".

Pues bien, parece que el primer asalto en este ring ha comenzado. Ayer HTC (uno de los principales fabricantes de terminales móviles Android) ha demandado a Apple por violar modo de patentes,patentes que HTC compró la semana pasada a Google. Hasta ahora, todas las acciones relativas a patentes en el ecosistema de Android había sido más bien defensivas, y Google no había jugado un papel relevante en ellas. 

Parece que esto está comenzando a cambiar. Los esteroides y el gimnasio están comenzando a dar sus efectos, y Google va a dejar de sólo recibir golpes y los va a comenzar a dar.

Por más que yo odie las patentes, este movimiento por parte de Google/HTC es positivo para Android. Si el ecosistema de Android no se defiende, cada vez los terminales basados en este sistema operativo tendrán que pagar más licencias por patentes, lo cual va a inflar su precio (os remito de vuelta a la noticia sobre Microsoft), lo cual será negativo para esta plataforma.

Traducción al castellano de la documentación de Grails 2.0

Desde el grupo y lista de correo de Grails en castellano estamos buscando gente para traducir la documentación de la última versión de Grails, la 2.0. Por ahora somos siete voluntarios, y cada uno nos hemos comprometido a traducir una parte, pero todavía necesitamos más gente para acabar en un tiempo prudencial.

Hemos creado un wiki con instrucciones y una hoja de cálculo compartida donde cada traductor puede reservarse una serie de artículos a traducir, de manera que podemos saber en cualquier momento cuánta gente hay traduciendo, qué esta traduciendo cada uno y cuánto queda pendiente.

¿Cómo participar?

Solo tienes que pedir acceso a la hoja de cálculo en la lista de correo de Grails en castellano, y reservar una serie de artículos. En cuanto seamos suficientes (lo estamos discutiendo en la lista), empezaremos todos con la traducción.

• Hoja compartida en Google Docs con todas las secciones a traducir y la gente que se ha apuntado: Grails Doc ES en Gogle Docs
• Hilo abierto en la lista de Grails en castellano sobre la traducción: thread/3593af20b664880d
• Wiki con instrucciones: https://jottit.com/ukt8u
• Repositorio Git oficial para contribuir en la traducción: Grails-doc en Github

Oracle Enterprise Java Developer Day

El próximo jueves 22 de septiembre Oracle organiza en Madrid, España un evento gratuito orientado a los desarrolladores. Para dicho evento, Oracle ha pedido la colaboración de javaHispano, que estará representado allí a través de Alfredo casado (acasado), quien impartirá una de las charlas.

El evento está orientado hacia desarrollo con Java EE 6, especialmente (aunque no exclusivamente) con soluciones de Oracle. Debajo de estas lineas tenñeis la nota de prensa anunciando el evento

 Nota de prensa

Tenemos el placer de invitarle a una sesión técnica el próximo: Jueves 22 de Septiembre Hotel NH Príncipe de Vergara Príncipe de Vergara, 92 en Madrid Se trata de una jornada eminentemente práctica en la cual tendrá la oportunidad de intercambiar experiencias con otros expertos tanto de otras entidades como de Oracle, y en la que profundizaremos en los aspectos siguientes: La moderna y ligera plataforma Java EE 6, con la productividad que proporciona, particularmente, cuando se integra con otras tecnologías comerciales y open source. Las implantaciones líderes de Java EE6 / EE6 Web Profile Casos de uso de Memory Grid, el nuevo paradigma para el procesamiento de transacciones extremas Cómo encaja todo esto con Maven, Hudson, EclipseLink Como es evidente, la jornada estará enfocada hacia Java EE6 y el valor que aportan las aproximaciones basadas en estándares, especialmente, a los desarrolladores, en áreas como las que reseñamos seguidamente: Seguir las buenas prácticas, minimizando el esfuerzo de codificación XML Empleo de APIs más sencillas, abiertas y estándares, no propietarias Menos dependencias Plain Old Java Objects (POJO) – un modelo simple y probado de programación Modelo basado en anotaciones, inyección y reutilización Reducción o eliminación de la necesidad de los descriptores para el despliegue Libertad de elección para el IDE y el estilo de desarrollo API tradicional para los desarrolladores con más experiencia Fecha Jueves, 22 de Septiembre de 2011 9:00 a.m. – 2:00 p.m. Lugar  Hotel NH Príncipe de Vergara Príncipe de Vergara, 92  Madrid Haga click aquí para poder inscribirse Al tratarse de una jornada eminentemente práctica es necesario que el participante traiga su ordenador personal que cumpla con los siguientes requisitos: Hands on Lab general requirements Hands on Lab software requirements Laptop with DVD Drive Any operating system 3.9 GB free disk space for VirtualBox appliance 2GB RAM+ in your machine VirtualBox 4.1+ software 9 GB of disk space for VirtualBox image Ponemos a su disposición imágenes preconfiguradas del desarrollo de VirtualBox para que las descargue e instale VirtualBox 4.1 antes de asistir a la jornada. Haga click aquí Si tuviera algún problema con el registro mande un email a: marta.rodriguez.casanova@oracle.com o llame al teléfono: 91 626 75 47

Agenda 9:00 – 9:30 Registro 9:30 – 10:15 Explorando Java EE 6 D. Alvaro Sánchez-Mariscal Líder del Grupo de Desarrolladores de CUORE 10:15 -11:00 Desarrollo Moderno y Ligero con Java EE 6 D. Alfredo Casado javaHispano 11:00 – 11:20 Café 11:20 – 12:00 Una introducción técnica al desarrollo de caché en memoria (in-memory data grid) D. Enrique Martín Sales Consulting Snr Manager - FMW Oracle Ibérica 12:00 – 12:45 Hands on Lab 1: Desarrollo con Eclipse, Maven y Hudson para Oracle Weblogic Server D. Jesús Guerra Principal Sales Consultant Oracle Ibérica 12:45 – 13:30 Hands on Lab 2: Desarrollo de un ejemplo completo Java EE 6´ D. Manuel Hurtado Principal Sales Consultant Oracle Ibérica 13:30 – 14:00 Ruegos y Preguntas 14:00 Cóctel Con la Colaboración de:

¿Cuánto le cuesta a tu empresa que tengas un equipo lento?

En este fantástico post se hace un análisis que yo mismo he estado tentado a hacer en más de una ocasión. Cuantiza cuánto tiempo está perdiendo una empresa porque los desarrolladores de la empresa tienen máquinas no todo lo potentes que deberían.

El autor explica que él y otros nueve compañeros desarrolladores de la empresa están usando unas máquinas que, si bien no son muy antiguas (Intel core 2 duo CPU a 3GHz con 3.1 Gb de RAM con dos monitores) no son todo lo potentes que a ellos les gustarían. A pesar de que han hecho todo lo posible para mejorar el rendimiento de la máquina (incluyendo cosas como desactivar el antivirus o desactivar efectos visuales de Windows) cuando ejecutan alguna tarea tienen que simplemente "esperar" durante un rato a que las cosas sucedan.

Durante toda una semana, él y otro compañero se sentaron en sus puestos de trabajo con cronómetros y cronometraron cuánto tiempo se pasaban cada día "esperando" sin hacer nada delante del ordenador. Los resultados de ambos fueron bastante similares: unos 40 minutos al día.

Empleando la estimación (conservadora desde mi punto de vista) de que cada minuto de trabajo cuesta 0,75 libras (y ojo, estamos hablando de lo que cuesta a la empresa el minuto de trabajo, no de lo que cobra el programador). Supongamos que con un equipo más potente esos 20 minutos perdidos al día se reducen a la mitad; esto quiere decir que cada día de trabajo la empresa pierde 15 libras por culpa del tiempo que cada programador se pasaba "esperando".

Teniendo en cuenta que a día de hoy uno puede comprarse un equipo de última generación para desarrollo por unas 1000 libras, esto quiere decir que en sólo 33 días la empresa habría recuperado la inversión en ese nuevo equipo (que al menos tendrá una vida útil de dos años).

El estudio y los resultados a mí me parecen totalmente realistas y correctos. A una empresa le conviene invertir en que sus desarrolladores tengan buenos equipos (y por supuesto, con al menos dos monitores). No hacer esto ocasiona pérdidas económicas para la empresa.

¿Cuántos de vosotros creéis que actualmente tenéis equipos menos potentes de lo que necesitais? ¿Creéis que ese blog post os podría ayudar a convencer a vuestros jefes de que os compren equipos más potentes?

Oracle retira la licencia Linux para distribuir su JDK

Es una noticia que ya sucedió hace 10 días, y hasta ahora no había entrado en mi radar, aunque creo que es relevante. A final de agosto, Oracle anunció que la licencia que permitía a las distribuciones de Linux empaquetar con la propia distribución el binario de su JDK (el de licencia comercial, no del OpenJDK) sería retirada, y el proyecto jdk-distros de Java.net sería discontinuado.

Esto quiere decir que a partir de Java 7 las distribuciones de Linux no pueden empaquetar el JDK propietario de Oracle. Los usuarios finales podrán instalarlo (como se hace en Windows, por ejemplo) por su cuenta descargándolo desde la página de Oracle. Pero no será posible empaquetarlo en la distribución.

Según Oracle, el motivo para esto es que el OpenJDK ha alcanzado un nivel de madurez que lo convierte en una opción perfectamente viable y ese sería el JDK que deben emplear estas distribuciones.

Este argumento no tendría ningún problema si ambos fuesen completamente equivalentes. Yo puedo dar fe de que en Java 6. El OpenJDK 6 tenía un rendimiento considerablemente inferior al rendimiento del JDK propietario de Sun/Oracle, especialmente en aplicaciones Swing (lo que hacía algunas de mis aplicaciones simplemente inutilizables bajo Linux con el OpenJDK). Además el OpenJDK aunque cumple con la especificación Java, no tiene tantas herramientas de desarrollo (herramientas del estilo de jarsigner o keytool) como el de Oracle.

De esto puedo dar fe en el caso de Java 6. Sobre el OpenJDK 7 no tengo experiencia en mis propias carnes, pero uno de los mantenedores de Debian afirma (y yo le creo basándome en experiencia previa) que algunos de estos problemas (sobre todo relacionados con aplicaciones de escritorio) persisten.

Aunque el problema no es muy grave en la práctica (sigue siendo posible instalar manualmente el JDK de Oracle si se quiere) no entiendo qué se debe este paso de Oracle. ¿Qué problema habría con qué las distribuciones de Linux sigan empaquetando algo que es gratuito y que los usuarios pueden instalar por su cuenta?

¿Qué opináis acerca de este movimiento de Oracle?