informatica

Configurando GIT en Eclipse y CodeBaseHQ

Hace algunas semanas hablaba de CodeBaseHQ como repositorio GIT para nuestros proyectos. Como además de desarrollo web (xhtml+php+javascript+css) tenemos una parte del código (las recomendaciones y algunas herramientas) funcionando en Java, he querido configurar Eclipse, que es el entorno de desarrollo que utilizamos para desarrollar en Java, para que sea capaz de sincronizarse con CodeBaseHQ vía Git.
En su día ya encontré un plug-in para meter Git en Eclipse, y la cosa pintaba muy simple, pero al tratar de instalarlo me di cuenta que el plug-in está todavía en desarrollo y que no había ninguna release instalable directamente, así que como el proceso tiene algo de gracia, comento los pasos que hay que dar para poder sincronizarse con repositorios Git desde Eclipse.

1.- Instalar EGit, que es el plug-in de Git para Eclipse. Para este paso caben 2 opciones posibles:

1.1.- Bajarse los fuentes y exportarlos como plug-in. Este es el proceso que yo he seguido, pero no lo recomiendo, porque empiezan a saltar muchas dependencias y al final se tarda un buen rato. En el fichero EGIT_INSTALL dentro de los fuentes podéis encontrar el proceso de exportación como plug-in de Eclipse.

1.2.- Irse a la zona de instalación de software dentro de Eclipse (Help->Install New Software) y añadir el siguiente repositorio: http://www.jgit.org/updates. Con esto te permitirá seleccionar el plug-in Egit, instalarlo y al reiniciar Eclipse lo tendrás listo.

Como os comentaba anteriormente, lo mejor es seguir el segundo paso, mucho más limpio y se ahorra mucho tiempo.

2.- ¿Tenemos nuestro par de claves SSH creadas y operativas?

Como al final conectaremos por SSH, nos hace falta tener un par de claves SSH para conectarnos a CodeBaseHQ. En mi caso ya las tenía instaladas, ya que hice algunos commits desde línea de comandos, pero si no las tenéis instaladas podéis seguir este tutorial de CodeBaseHQ para tenerlas listas (el tutorial sirve para cualquier repositorio, no solo para CodeBaseHQ)

Yo instalé la clave en “~/.ssh”, pero si las dejáis en algún otro lado, acordáos de la ruta porque os tocará reconfigurar el Eclipse. Dentro de “Preferences->General->Network Conections->SSH2″, podemos elegir el directorio donde tenemos las claves, e incluso las propias claves en 2 cuadros distintos.

En este punto ya estamos listos para utilizar Git en nuestros proyectos Java. Supongamos que tenemos ya un proyecto Java en Eclipse y queremos compartirlo. Tenemos que seguir estos pasos:

3.- Seleccionamos el proyecto que queremos sincronizar, botón derecho y damos a “Team->Share Project”. Nos sale una nueva ventana donde seleccionamos “Git”. A continuación nos sale la configuración Git, seleccionamos el nombre del proyecto y posteriormente al botón “Create…” y luego a “Finish”. En este momento ya le hemos dicho a Git que el proyecto actual va a ser un repositorio Git.

4.- Ahora tenemos que añadir los ficheros ya existentes al repositorio. Para ello seleccionamos “Team->Add to Version Control”.

5.- Y hacemos el Commit de estos archivos “Team->Commit”. Ponemos el mensaje del commit, por ejemplo “Commit inicial” y damos a “Commit”.

En este punto ya tenemos el código en nuestro repositorio Git local (recordemos que Git es distribuido). Ya solo nos queda mandarlo a CodeBaseHQ:

6.- Como queremos mandarlo a CodeBaseHQ (o donde sea), seleccionamos “Team->Push-To”. Nos sale una ventanita donde tenemos que meter los datos del repositorio externo. En principio, en URI metemos los datos que nos proporciona el repositorio externo, que será algo del tipo “[email protected]:usuario/proyecto/repositorio.git” y Egit nos rellenará el resto de campos, salvo el protocolo, donde debemos elegir “git+ssh”.


Le damos a siguiente y en la nueva ventana solo tenemos que seleccionar “Add all branches spec” y luego a Finish. Se lanzará un proceso en el que se subirán todos nuestros cambios a CodeBaseHQ (o en su defecto a GitHub o cualquier otro repositorio que queramos utilizar).

¿Buscas trabajo en Informática o áreas relacionadas?

La crisis afecta hasta el sector de las TI, y yo lo noto en que a nuestros alumnos les cuesta más tiempo colocarse, o al menos encontrar un trabajo en el que se sientan más o menos a gusto. Lo bueno es que los nuevos tiempos nos brindan nuevas formas de encontrar empleo, y entre las nuevas tecnologías destaca Twitter, que puede ser utilizada a la perfección para encontrar empleos, mediante búsqueda de palabras clave.

Y aún mejor, hay gente que está haciendo una estupenda labor de recopilación de ofertas de trabajo en este sector y las publica en Twitter, y este es el caso de @currofile (Marina Zaliznyak). Si estás buscando trabajo en este área, o te gustaría ver “qué se cuece”, te recomiendo que sigas a @currofile a través del Twitter, no te arrepentirás.

Backup2Mail para automatizar los backups de tu Base de Datos

Cuando tienes una aplicación web que tira de base de datos (en nuestro caso MySQL), eres más consciente de la importancia de automatizar procesos como el backup de la base de datos, para poder recuperar toda la información en caso de un fallo grave del sistema. De todas formas, a día de hoy el estar a cargo de una base de datos es algo más habitual de lo que creemos, ya que muchos utilizamos blogs que están instalados en servidores propios y tiran de su propio MySQL. En estos casos, también conviene darse cuenta del problemón que se nos puede venir encima si perdemos los datos de la base de datos.
Si bien podemos hacer copias de seguridad de la base de datos de forma manual, ya bien sea utilizando el MySQLDump, o exportando desde el PhpMyAdmin, resulta más práctico el automatizar el proceso para que no acabe convirtiéndose en una mera buena intención más de año nuevo. Para automatizar el proceso tenemos muchas opciones, y en sitios como Noupe ya han dado cuenta de varias recopilaciones acerca de las herramientas que se pueden usar.

De todas las opciones posibles, yo me he acabado decantando por usar Backup2Mail, un pequeño script en PHP que podemos configurar con los datos de nuestra base de datos y nuestro correo y nos envía un backup de la base de datos (comprimido) a nuestro correo. Si metemos una invocación a este script desde el cron de nuestro sistema, conseguimos que cada X horas se nos envíe un volcado de la base de datos al correo. Yo por ahora lo tengo configurado para que me envíe la copia de seguridad 1 vez al día, para evitar generar tráfico excesivo a través del correo (nuestra base de datos ya pesa un poquito).

Usando CodeBaseHQ como repositorio GIT

Si bien hasta ahora hemos estado más preocupados en desarrollar Wipley y hemos dejado de lado algunas cosas, con la puesta en producción nos han surgido temas más relacionados con el cómo vamos a gestionar el proyecto a partir de ahora. Una de las necesidades que ya íbamos notando desde hace tiempo era el de disponer de un repositorio para poder desarrollar de una forma más organizada y con un control de versiones decentes.
Si bien después de una charla de Raúl Murciano, un crack en temas de desarrollo web, en las pasadas Jornadas de Conocimiento Libre, prácticamente me convenció para abondonar Subversion y coger GIT como control de versiones, el otro día me surgía todavía la duda, especialmente habiendo leído algunas bonanzas sobre Mercurial. Después de consultarlo en Twitter, la respuesta de @pabloformoso, me acabo de convencer por GIT. Cuando varios desarrolladores de primera te recomiendan algo, es que tienes que hacerles caso ;)

Viendo las alternativas de hosting con GIT para proyectos software, me quedaba todavía la duda de si elegir GitHub o CodeBaseHQ. Por un lado GitHub lo usan una gran variedad de grandes proyectos Open Source, y permite tanto gestionar proyectos Open Source como proyectos privados. Por otro lado CodeBaseHQ ofrece casi lo mismo que GitHub (aunque solo proyectos privados) pero añade funcionalidades interesantes para la gestión de proyectos como la gestión de milestones, ticketing para los bugs o mejoras, wikis, gestión del tiempo, etc.

Al final nos hemos decantado por CodeBaseHQ. Por un lado las funcionalidades adicionales resultaban bastante interesantes y nos evitan el tener que tener otro sistema independiente para la gestión del ticketing, por ejemplo, y por otro lado las comparaciones que hemos encontrado en Internet parecen apuntar a que CodeBaseHQ funciona un poco mejor que GitHub. Eso si, cuando liberemos alguno de los proyectos, utilizaremos GitHub, que para temas OpenSource tiene puntos muy interesantes, como el hecho de las cuentas gratuitas para los proyectos de código abierto, o la gran aceptación por parte de la comunidad.

MySQL atrapado en medio de la fusión Oracle/Sun

El tema ya lleva tiempo en el candelero, pues hace ya unos cuantos meses que Oracle anunció la compra de Sun, y todavía no se ha resuelto el tema. La compra de Sun por parte de Oracle es una gran operación, 7.400 millones de dólares, y desde el principio planteaba unas cuantas dudas acerca de algunas tecnologías de Sun. Si bien el futuro de Java ya no parece turbio, por el interés de Oracle de preservar el lenguaje y su ecosistema, MySQL no está corriendo tanta suerte, ya no por las decisiones de Oracle, si no porque los reguladores anti-monopolio europeos no ven con buenos ojos que Oracle se quede con una de las principales bases de datos Open Source del mercado.
La administración americana lo tiene más claro, ya que para ellos existe un buen número de bases de datos Open Source en el mercado, lo cuál permite que siga existiendo competencia en el mercado. Sin embargo, para europa el tema no está claro y solo verían con buenos ojos la fusión Oracle/Sun si MySQL se vendiera a una tercera empresa.

El tema va para largo, porque Oracle no quiere perder a una de las perlas de Sun en la absorción, y la Unión Europea no parece dispuesta a poner en peligro el mercado de las bases de datos con una posición todavía más dominante de Oracle. Desde mi punto de vista, sería muy positivo que MySQL se “independizara” de Oracle, ya que aunque Oracle pudiera mantener MySQL como una base de datos libre, no se asegura una continuidad en el desarrollo de MySQL, y se pondría en peligro una buena parte de la infraestructura de la Web, donde MySQL es una de las bases de datos más extendidas, especialmente en el inmenso, pero todavía emergente, mercado de las redes sociales.

¿Tienen sentido las arquitecturas de 128 bits?

En the Inquirer comentan que Microsoft está preparando una versión nativa de 128 bits para sus próximos sistemas operativos compatible con la plataforma de 64 bits actual, y en colaboración con Intel, AMD, IBM o HP, haciendo referencia a las arquitecturas Intel IA-64 e IA-128.
Al final del artículo, se postula que si bien la arquitectura de 128 bits tiene ventajas teóricas, no las tiene a nivel práctico por la falta actual de controladores y aplicaciones para 64 bits. Ahora bien, ¿realmente tiene sentido?

El gran inconveniente de las arquitecturas de 32 bits es que solo dejan direccionar 4GB de memoria RAM, por lo que limitan enormemente las capacidades de los ordenadores, en los que a día de hoy ya encontramos esos 4GB instalados por defecto casi de forma estandar. Con 64 bits, nos vamos a 16 exabytes (16 millones de terabytes o 16.000 GB). Desde luego, esta cantidad es más que suficiente para mucho tiempo, especialmente si tenemos en cuenta que según algunos estudios, Internet actualmente tiene un tamaño aproximado de 500 exabytes. Así pues, desde el punto de vista del direccionamiento de la memoria RAM (principal limitación de la arquitectura), no resulta necesario ampliar esta cantidad.

Ahora bien, si tratamos el tema desde el punto de vista del tamaño de los registros, así como del tamaño de las direcciones de memoria, la cosa cambia. Muchas aplicaciones, en particular las que se refieren a la criptografía, hacen uso de enteros de 128 bits, por lo que trabajar de forma nativa con este tamaño de registros implica un notable incremento en el rendimiento de algunas aplicaciones.

Así pues, cuando nos hablan de arquitecturas de 128 bits resulta un tanto ambiguo, y no queda claro cuál va a ser el soporte que pretende ofrecer Microsoft a los 128 bits. Muy seguramente lo que estén haciendo es dar soporte a registros de almacenamiento de 128 bits, pero trabajando con un direccionamiento a 64 bits.

Si bien una arquitectura de direccionamiento de 128 bits no va a tener sentido durante mucho tiempo, si que lo tiene que tanto los fabricantes de hardware como los desarrolladores de software trabajen de forma conjunta para soportar el trabajar con registros de un mayor tamaño, que permitan incrementar la eficiencia de los programas, especialmente cuando parece que hemos llegado a un punto donde a los procesadores les cuesta crecer en términos de velocidad y han de crecer en términos de paralelismo, ya bien sea con varios procesadores/cores, o con arquitecturas de un mayor número de bits. A este respecto, el que la arquitectura actual de 64 bits no esté 100% consolidada no debería ser un punto en contra, si no un aliciente ya que las variaciones sobre la arquitectura actual no implicarían tirar mucho software “a la basura”. Quedan unos añitos de cambios a nivel de arquitectura, y también de que los desarrolladores nos acostumbremos a desarrollar con los 64 bits de direccionamiento en mente, y con los bits que vengan a nivel de registro, ya que hasta la fecha no conseguimos sacarle un buen partido a las nuevas arquitecturas.

5 claves para no pifiarla al escalar

En esta interesante entrada de High Scalability, comentan 5 claves para que cuando tratemos de escalar nuestra base de datos no la acabemos pifiando. Parecen cuestiones simples, pero muchas veces las obviamos, y luego vienen las penas. Como siempre, todo es muy dependiente de tu aplicación en concreto, pero merece la pena tenerlas siempre presentes:

1.- No pienses síncronamente. Introduce comunicación asíncrona, paralelización y estrategias para lidiar con datos aproximados o un poco desfasados.

2.- No pienses de forma vertical. Escalar con máquinas cada vez más grandes no funciona. Intenta escalar de forma horizontal, y con arquitecturas asíncronas desde el principio, ya que te permitirá ir añadiendo más capacidad en función de la demanda.

3.- No mezcles transacciones con Business Intelligence. Las transacciones y las analíticas son inherentemente distintas. Separa distintos tipos de datos en distintas bases de datos. De hecho, para los temas de BI y Minería de Datos, necesitarás arquitecturas OLAP, mientras que para transacciones de datos más comunes te bastará con bases de datos relacionales (o no relacionales).

4.- Evita mezclar datos “calientes” y “fríos”. Los datos estáticos y aquellos que cambian muy rápidamente son inherentemente distintos. Separa también estos distintos tipos de datos en distintas bases de datos.

5.- No te olvides del poder de la memoria. Haz que tus datos estén accesibles en RAM mediante un particionado inteligente de los datos en los servidores.

Escalando Twitter

Hace ya un par de meses la gente de HighScalability publicaba un artículo muy interesante acerca de cómo la gente de Twitter se lo habían montado para ser capaces de escalar su plataforma para hacerla un 10.000% más rápida. El artículo es muy extenso, y merece la pena dedicar tiempo a leerlo a fondo (si uno está interesado en estos temas). Resumo alguno de los aspectos y últimas modificaciones de Twitter para lograr este objetivo.
Estadísticas iniciales
  • Sobre 350.000 usuarios (cuando comenzaron los problemas de escalabilidad). Los datos más recientes no se conocen a ciencia cierta, aunque tienen que andar por encima de los 10 millones de usuarios registrados.
  • 600 peticiones por segundo
  • 200-300 conexiones por segundo en media, con picos de 800.
  • MySQL atendiendo 2.400 peticiones por segundo
  • 180 instancias Rails, usando Mongrel como servidor web
  • 1 servidor MySQL (con 8 cores) y 1 esclavo para estadísticas e informes.
  • Más de 30 procesos para tareas rutinarias
  • 8 máquinas Sun X4100S
  • Rails tarda 200 milisegundos en procesar cada petición
  • El tiempo medio empleado por la base de datos está entre 50 y 100 milisegundos
  • Sobre 16GB de Memcahed
Plataforma
  • Ruby on Rails
  • Erlang
  • MySQL
  • Mongrel
  • Nagios
  • Google Analytics
  • AWStats
  • Memcached
Algunos pasos a tomar
  • Indexa todo, para cada atributo en una clásula WHERE de una sentencia SQL, mete un índice
  • Desnormaliza todo lo que puedas
  • “No seas estúpido”: si tu aplicación hace cosas muy complicadas, como consultas del tipo “…like ‘%#{search}%”, vas realmente apañado. Nada de joins complejos ni de recorrer grandes conjuntos de datos
  • Cachea todo lo que puedas, especialmente los accesos desde el API
  • Manten tu aplicación fácilmente particionable desde el principio
  • La mayoría de las cosas no dependen tanto del lenguaje, si no de la arquitectura del sistema
Un consejo menos técnico, pero no menos importante

Trata tu plan de escalabilidad como si fuera un plan de negocio; reúne un consejo de expertos para que te aporten ideas y consejos
Algunos pasos en la evolución del escalado de Twitter

Personalmente, el que ahora todo esté en RAM es uno de los aspectos que más me llaman la atención, aunque tiene sentido, sobre todo teniendo en cuenta el coste actual de la RAM, las posibilidades que abren las arquitecturas de 64 bits y, sobre todo, que realmente Twitter no maneja tantos datos (comparado con el volumen que gestionan redes sociales más completas como Facebook).

Los planes de Oracle para Sun

Gracias a un tweet de @alobbs me entero de esta página de la web de Oracle dirigida a los clientes de Sun, donde se puede ver esta imagen.


¿Hasta que punto es cierto este anuncio? Por lo que comentan, parece que la adquisición de Sun ha sido méramente su por negocio de hardware (que estaba en declive), para poder competir con IBM, no por barrer del mapa a su competencia Open Source (MySQL).

Sigo creyendo que con la adquisición de Sun, Oracle quiere recuperar parte del mercado perdido con MySQL. Esto no quiere decir que lo pueda rentabilizar, pero si al menos tenerlo controlado. Mejor ofrecer tu un servicio gratuito (y controlado) a tus clientes, que no que lo ofrezcan otros, sobre todo porque si se lo ofreces tu tienes las “armas” para reconducirlos.

Ahora bien, ¿hasta qué punto Oracle quiere competir en el mercado del hardware con IBM? Cada vez tengo menos claros los verdaderos objetivos de Oracle a este respecto, y realmente me estoy empezando a plantear si podría competir con IBM a todos los niveles.

1 2 3 4  Scroll to top