Noticias javaHispano.org

miércoles, 22 de octubre de 2008

Google liberó el código fuente de Android

Google ha hecho público hoy el código fuente de Android, su plataforma para móviles basada en Linux. Tal y como habían previsto, el anuncio ocurre el mismo día en que T-Mobile lanza el G1, el primer teléfono móvil con Android.


“Hoy es un gran día para Android, la Open Handset Alliance y la comunidad open-source”, anuncia Google en su página oficial. Como prometido, la plataforma para dispositivos móviles se convierte en software libre.

“Todo el trabajo que hemos derrochado en la plataforma móvil está ahora disponible, de forma gratuita, como el Android Open Source Project”, señala Dave Bort en el anuncio oficial. “Android no es sólo una pieza de hardware; es una plataforma completa de software que se puede adaptar a todo tipo de configuraciones de hardware”, añade.

La idea de Google es que esta apertura del código haga que Android evolucione rápidamente y gane nuevas aplicaciones, y de paso ahorrarse en dinero en el desarrollo del software.

Es un gran paso para el desarrollo de aplicaciones para este terminal móvil que será un duro competidor con el iPhone de Apple, y si no tiempo al tiempo...aunque siempre habrá 2 líneas como en los PC's con los Mac.

La gran ventaja que tiene Google sobre Apple es el acuerdo empresarial con fabricantes de móviles, que permitirá que esos móviles sean buenos en sí y ya veremos cómo va creciendo la parte de software de los mismos.

Curioso también el hecho de que el código fuente no esté disponible para Windows... ¿será cuestión de tiempo o una postura firme de Google hacia el open source?

Gartner identifica cuatro claves que transformarán la industria de software

He leido este articulo en un e-zine y me parece un aspecto a tener en cuenta por las empresas para saber por dónde nos movemos y cuales son las tendencias en los próximos años, aunque ya sabemos cómo cambia esto en cuestión de meses.

Aquí lo transcribo:

Soluciones novedosas de software transformarán no sólo la industria sino la utilización de los aplicativos, según Gartner. El software se focalizará en distintos escenarios como usuarios, aplicaciones Web y aplicaciones SOA. Asimismo, éstos se ofrecerán mediante los nuevos modelos de cloud computing y SaaS. Estos cambios alterarán significativamente la industria de software en cuatro aspectos clave.

1. Emergencia de nuevas tecnologías y la convergencia de tecnologías existentes

– el mercado de TI ha alcanzado un periodo acelerado de innovación y cambio que afecta los modelos de distribución y entrega. Las tecnologías centradas en SOA ahora incluyen la gestión de procesos de negocio, la portabilidad de dispositivos y los contenidos mashup. Por el 2010, los mashup serán el modelo predominante para la creación de aplicaciones corporativas.

Los mashup permiten crear aplicaciones al momento y abren la posibilidad de una nueva clase de aplicaciones desechables con la capacidad de resolver temas como la agregación de contenidos y la flexibilidad personal con accesos a datos internos y externos.

2. Cambios en los usuarios de software y la demográfica de soporte

– los cambios de cómo, cuándo y dónde trabaja la gente, así como las nuevas modalidades en Internet están propiciando cambios fundamentales en la estructura de negocio. Por el 2015, ninguna empresa podrá crear o sostener una ventaja competitiva si no integra herramientas de colaboración y de dinámicas sociales.

La oportunidad para el negocio está en comprender el efecto de la individualización en el negocio, los procesos críticos, la innovación y la colaboración. Las preferencias del usuario determinarán el 50 por ciento de las adquisiciones de software TI.

3. Cambios revolucionarios en la utilización y consumo de software

– por el 2010, SOA formará parte del 80 por ciento de las nuevas aplicaciones críticas y procesos de negocio. El entorno de aplicaciones del futuro será más granular, incisivo y fluido para habilitar desarrollos más rápidos. Durante el 2008 y 2009, las organizaciones deben rediseñar sus procesos, políticas de gobierno y disciplinas para iniciar esta transición. Con mayor frecuencia, el mercado aprovechará las nuevas plataformas Web, software como servicio (Saas) y otros servicios TI.

4. El mercado de software estará dominado por mega-proveedores que soportan ecosistemas masivos
– los mega-proveedores de software ya han demostrado su valía e influencia en el espacio empresarial. Éstos intentarán dominar las arquitecturas empresariales mediante la integración de los productos de proveedores más pequeños. En efecto, los mega-proveedores tendrán los recursos y los proveedores pequeños tendrán la iniciativa y el incentivo.


martes, 21 de octubre de 2008

10 trucos de Subversion para controlar tu código


1. Usa status para encontrar tu...estado


Con Subversion, si quieres encontrar lo que has modificado ejecutas svn status. Este comando compara los ficheros en tu copia de trabajo (working copy) con aquellos en las areas administradas por Subversion (esos molestos directorios .svn), evitando así la necesidad de un acceso a la red de ida y vuelta:



$ svn status
D fish.c
A shrimp.c
M anemone.c


Ten en cuenta que fish.c está previsto que sea borrado, shrimp.c está previsto que sea añadido, y anemone.c ha sido modificado.


Ahora, por defecto, svn status sólo muestra los ficheros que son interesantes (como aquellos que han sido añadidos, modificados o borrados). Si quieres ver la información de todos los ficheros de tu copia de trabajo, utiliza la opción --verbose


  $ svn status --verbose

44 23 sally README

44 30 sally INSTALL

44 35 harry trout.c

D 44 19 ira fish.c

A 0 ? ? shrimp.c

M 0 ? ? anemone.c

44 36 harry things/rocks.txt


La primera columna representa lo mismo, pero la segunda muestra la revisión de trabajo del elemento. Las tercera y cuarta columnas muestran la revisión del último cambio del elemento y quién la realizó.


Si quieres saber qué ficheros se actualizarán la próxima vez que ejecutes svn update, utiliza la opción --show-updates en el comando svn status


  $ svn status --show-updates --verbose
* 44 23 sally README
44 30 sally INSTALL
* 44 35 harry trout.c
D 44 19 ira fish.c
A 0 ? ? shrimp.c
M * 44 32 sally anemone.c
44 36 harry things/rocks.txt

Puedes ver que los ficheros que serán actualizados son los marcados con un *.


2. Recuerda, puedes mover cosas


He visto personas pasando mucho tiempo en reuniones decidiendo la estructura de directorios y el lugar de los ficheros en un proyecto, pero con Subversion puedes mover ficheros y directorios con total libertad:


  $ svn move foo.c bar.c

A bar.c

D foo.c

Ahora bar.c ha sido marcado para ser añadido y foo.c ha sido marcado para ser borrado. (Así es como Subversion representa un movimiento de ficheros. svn commit Enviará tus cambios al servidor.)

Puedes mover ficheros y directorios directamente en el servidor mediante las URL's:


  $ svn move -m "Move a file" http://svn.red-bean.com/repos/foo.c \
http://svn.red-bean.com/repos/bar.c



Esto realiza el movimiento de foo.c a bar.c en el servidor directamente.


3. Etiquetar y crear ramas mediante copia


En Subversion, las operaciones de rama (branch) y etiquetado (tag) se hacen como copias:


  $ svn copy -m "Tag rc1 rel." http://svn.red-bean.com/repos/trunk \
http://svn.red-bean.com/repos/tags/1.0rc1



Has creado una etiqueta de tu línea principal de desarrollo o troncal (indicada como trunk en términos de Subversion). Si en realidad quieres crear una rama, copia la linea troncal de desarrollo en el directorio branches (ramas), es así de sencillo. Y en Subversion, etiquetar y crear ramas es así de rápido.


En Subversion, etiquetas y ramas son sólo rutas copiadas en el árbol del repositorio. Por convención, las etiquetas se encuentran bajo la ruta /tags y las ramas bajo /branches.


Subversion necesita solo copiar un unico nodo directorio para hacer una copia, lo cual no es realmente rápido, pero ocupa muy poco espacio en el repositorio--no importa el número de ficheros incluidos en la rama o etiqueta. ¡La comunidad de Subversion los llama "cheap copies" ("copia barata") por una buena razón!


No estás limitado a etiquetar todos los ficheros en la misma revision en Subversion: Si necesitas hacer una etiqueta o rama "revision-mezclada", siempre puedes copiar una copia de trabajo en una URL:



$ svn copy -m "Mixed branch." . http://svn.red-bean.com/repos/branch/1.2-mixed

Vete a Branching and Merging para una descripción más extensa de cómo hacer ramas y etiquetar.



4. "Revert" en vez de "delete and update"



Subversion almacena una copia original de cada fichero en el directorio .svn de tu copia de trabajo, de manera que puedes hacer esto:


  $ svn revert I-made-a-boo-boo.txt
Reverted 'I-made-a-boo-boo.txt'


Esto viene bien si no tienes una conexión de red en un momento dado.



5. No temas a tu sistema de control de versiones



Por defecto, ciertos sistemas de control de versiones que no mencionaré (como CVS) traducen los finales de línea (de CR [Unix] a CRLF [Windows] y viceversa) y expanden palabras reservadas (como $Id$) en tus ficheros. Esto es muy útil hasta que subes al repositorio un fichero binario y CVS, en un alarde de generosidad, convierte tu fichero en algo incomprensible.


Subversion nunca hará nada sobre tus datos salvo que tú se lo pidas explícitamente.

Repitamos de nuevo:



SUBVERSION NUNCA HARÁ NADA SOBRE TUS DATOS A MENOS QUE SE LO PIDAS.

Puedes añadir cualquier fichero binario a tu repositorio de Subversion y no tener que hacer nada especial para que Subversion no destruya tu fichero. Sin embrago, si añades un fichero de texto (un fichero .java o .c, por ejemplo), podrías querer que Subversion controle la transformación del fin de linea automáticamente por ti. Esto se hace usando las propiedades de Subversion.



En este caso, tendrás que asignar a la propiedad svn:eol-style el valor native:



  $ svn propset svn:eol-style native halibut.c


y subir tu cambio al repositorio.



Puedes aprender de tu cliente de Subversion para añadir ciertas propiedades a tus ficheros automáticamente--lee la sección de Automatic Properties y su configuración para más información.




6. Log, log, log tu log



El comando log de Subversion proporciona datos útiles y compactos basado en un commit atómico de Subversion. Por ejemplo:


$ svn log
------------------------------------------------------------------------
r3 | sally | Mon, 15 Jul 2002 18:03:46 -0500 | 1 line

Added include lines and corrected # of cheese slices.
------------------------------------------------------------------------
r2 | harry | Mon, 15 Jul 2002 17:47:57 -0500 | 1 line

Outline sandwich fixins.
------------------------------------------------------------------------
r1 | sally | Mon, 15 Jul 2002 17:40:08 -0500 | 1 line

Initial import
------------------------------------------------------------------------


Cada entrada del log muestra el número de revisión de la entrada, el autor, la fecha, el número de líneas en la entrada de log (para ayudar en el análisis de la salida de svn log), y el mensaje de log en sí mismo. Si quieres ver las rutas que cambiaron en la salida de tu log, pasa la opción --verbose:

$ svn log --verbose ------------------------------------------------------------------------ r3 | sally | Mon, 15 Jul 2002 18:03:46 -0500 | 1 line Changed paths: M /trunk/sandwich.txt

Added include lines and corrected # of cheese slices.
------------------------------------------------------------------------
r2 | harry | Mon, 15 Jul 2002 17:47:57 -0500 | 1 line
Changed paths:
M /trunk/sandwich.txt

Outline sandwich fixins.
------------------------------------------------------------------------
r1 | sally | Mon, 15 Jul 2002 17:40:08 -0500 | 1 line
Changed paths:
A /trunk/sandwich.txt

Initial import
--------------------------------------------------------------------



En los ejemplos anteriores, habrás notado que no hemos pasado ningún fichero o directorio específico (llamados targets) al comando de log. Si ejecutas svn log sin especificar targets (objetivos), Subversion presupone que te refieres al directorio de trabajo actual. Subversion usa una revision de incio de 1, y la revision de trabajo de tu directorio de trabajo actual como la revision final. (Puedes saber cuál es esta revision de trabajo usando svn status -v, como mencionamos anteriormente.)



Y ahora una pequeña nota: Si subes un cambio de un fichero e inmediatamente ejecutas svn log, no verás el mensaje de log de tu commit reciente. Esto es debido a que la "revision de trabajo" de tu directorio de trabajo no ha sido actualizado (subir un fichero no actualiza inmediatamente tu directorio de trabajo o cualquier otro fichero). Si ejecutas svn update y a continuación svn log, verás el mensaje de log "perdido".



Lee http://svnbook.red-bean.com/en/1.5/svn.tour.history.html y http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.log.html para más información sobre el uso de svn log.




7. Deshacer rápidamente un commit erróneo



Supón que tienes una copia de trabajo de /trunk y descubres que el cambio que hiciste en la revisión 303, que modificó oyster.c, es erróneo por completo--nunca debería haberse subido al repositorio. Puedes usar svn merge para "deshacer" el cambio en tu copia de trabajo*, y entonces subir la modificación local al repositorio. Todo lo que necesitas hacer es especificar una diferencia inversa usando svn merge:


  $ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk
U oyster.c

Usa svn diff para verificar que el cambio es correcto, y entonces súbelo al repositorio.



Para más información, lee Undoing Changes


* Es decir, restaura la última versión de tu repositorio a su estado anterior; Subversion todavía tendrá el commit "malo" en el repositorio. Siendo un sistema de control de versiones, el trabajo de Subversion es recordar todo lo que le hayas enviado.




8. Recuperar elementos eliminados



Si borras un fichero de tu repositorio y quieres "resucitarlo" a la última versión del respositorio, la forma más fácil es con svn copy desde una revisión anterior a su eliminación a tu copia de trabajo. Usa svn log -v para encontrar la revisión donde fue borrado, y entonces haz tu copia:


 $ svn copy --revision 807 \
http://svn.red-bean.com/repos/trunk/perch.c ./perch.c

Para más detalles, mira Resurrecting deleted items.




9. Cambia a una rama sin crear una nueva copia de trabajo



Como Subversion trata las etiquetas y las ramas como rutas normales en el repositorio, puedes ejecutar svn update para actualizar tu copia de trabajo al nombre de la rama con la que quieres comenzar a trabajar. Introduce el comando svn switch.


svn switch actualiza tu copia de trabajo para apuntar a un nuevo árbol en el repositorio--es decir, el árbol de una rama en vez del árbol troncal.


Esta es la manera que Subversion tiene para mover una copia de trabajo a una nueva rama.


  $ svn switch http://svn.red-bean.com/repos/branches/vendors-with-fix .
U myproj/foo.txt
U myproj/bar.txt
U myproj/baz.c
U myproj/qux.c
Updated to revision 31.

Para más detalles, ver Traversing branches.



10. Visualizar o montar tu repositorio



Si tu repositorio Subversion está instalado a través del servidor Apache HTTP Server (es decir, accedes a él mediante una URL que comienza con http), Subversion te da un par de regalos muy sabrosos:



Primero, puedes acceder desde cualquier navegador web al repositorio de Subversion y navegar como quieras através de la última revisión del repositorio.



tips1-top10-browse.jpg



Segundo, si usas un sistema operativo que conozca el protocolo DAV, puedes montar tu repositorio de Subversion en tu escritorio (sólo lectura):



tips2.jpg



tips3-top10-mount.jpg



Además de ser conveniente para ver el contenido de tu repositorio, es útil para compartir ficheros con usuarios distintos a Subversion.