Saltar al contenido

De Levelap a Stack Builders

mayo 21, 2014

.then().catch();

La semana que viene es mi última semana como parte del equipo de Levelap. Tras más de año y medio formando parte de dicho proyecto, ha llegado el momento de cambiar de aires, de enfrentarme a nuevos retos, y de aprender nuevas tecnologías y formas de trabajo.

Durante este año y medio me he sentido arropado, valorado y escuchado como en ningún otro lugar en el que he trabajado durante mi vida. Aunque los primeros meses fueron duros y costó cambiar la cultura de empresa existente, creo que hemos avanzado mucho en poco tiempo, y en la dirección correcta. No puedo más que agradecer a personas como Pablo Pazmiño y Rafael Meneses los buenos momentos que hemos pasado, lo mucho que he aprendido en el proceso, y la confianza que siempre han depositado en mí. Os echaré de menos, panas.

¿Y a dónde me dirijo? ¡Pues en una semana empiezo…

Ver la entrada original 91 palabras más

¿Crees que mi idea será viable? Tal vez, pero dame un segundo

abril 14, 2014

No te preocupes, seguro que más adelante sale

De un tiempo a esta parte suelen pasar por mis manos y por mi mesa variadas ideas y propuestas de negocio. Básicamente, en cuanto la conversación va algo más avanzada (normalmente rota ya la histeria inicial de guardar y almacenar eso de “la idea” bajo el miedo de “que alguien te la quite”), siempre aparece una cuestión clave…¿crees que mi idea de negocio será viable? y durante unos segundos quedo mirando al éter, meditando la manera y el lenguaje con el que articular mi respuesta.

A nivel general puedo decir que articular un verdadero modelo de negocio es un proceso arduo al que hay que dedicarle un cierto tiempo y un cierto esfuerzo. Son muchas variables a estudiar y muchos análisis que hacer. En base a la práctica, ahora ya sé que no hay conclusiones posibles (mucho menos del tipo “esto puede funcionar”, “esto no”) hasta que se ha realizado un trabajo muy, muy avanzado. Y seguirían siendo pistas.

Si en este momento todo está rodeado de mucha incertidumbre, mucho más a la hora de ir construyendo un negocio. Pero hay caminos medios y maneras de acotar, controlar y reducir esa incertidumbre. Y además ir haciéndolo de manera progresiva, para evitar encontrarse con un “gran fracaso” encima de la mesa.

Como no quiero aburriros demasiado, os explico un poco así a alto nivel el esquema ideal (bajo mi punto de vista) para empezar a trabajar. Esta sería mi recomendación base:

Fase-I: Coge la idea y juega con ella

Establecimiento de la idea principal de negocio (descripción lo más completa posible de la idea o de la propuesta). Esta fase es útil para conseguir el desarrollo más completo posible y comenzar a ponerla en contexto.

 

Fase-II: Empieza a desarrollarla y compararla
Análisis comparativo: Curva de Valor, Matriz ERIC, Embudo de trabajo. Estos son ejercicios para ir puliendo el proyecto en contexto y en esencia. Se suelen usar mucho para reducir el típico mensaje auto-limitante de “es que esto que estoy pensando ya lo hace mucha gente”, porque aquí jugamos a empezar a ver y medir cuales son las claves de los negocios parecidos y donde ponen ellos el foco y la diferenciación, para a partir de ahí empezar a pensar donde se pondrá el foco en nuestro proyecto propio.

 

Fase-III: Análisis y diseño de una posible arquitectura de negocio
Business Canvas Model: ejercicio muy cañero y muy didáctico para empezar a analizar cada apartado relacionado con el modelo de negocio, y sobretodo comprender las tres patas fundamentales: análisis de costes, análisis de fuentes de ingresos y propuesta de valor (lo que hace nuestro proyecto que no hacen los demás o bien el nivel de valor aportado con respecto al de los demás). Este ejercicio mola un huevo y da lugar al cierre de esta primera fase de trabajo, que debe proporcionar en conjunción con el punto 1 y el punto 2 un mapa bastante potente (cuanto más esfuerzo puesto en los ejercicios mejores resultados) de lo que quiero hacer, como he de hacerlo, cuanto me va a costar, como voy a obtener ingresos. Etc.
Solo a partir de cerrar este tercer punto y tener esta primera fase resuelta me atrevería a meditar si el proyecto vale la pena o no, la verdad. Con todos los datos y los mapas en la mano. Os prometo que no quiero aburrir xD

Descripción gráfica de la evolución neurótica

Así, en general

Yo no sé nada sobre vuestra idea ni el grado de desarrollo en el que está, pero os recomiendo sinceramente trabajar con esta secuencia a modo de algoritmo de trabajo porque el output que genera es brutal (si el trabajo está bien hecho). Por definir de una manera más concreta, os diré que para el punto 1 suelo trabajar con un manual de referencia, para el punto dos, con tablas de ejercicios y manuales para las actividades y para el punto 3 un manual que es la referencia sobre ese tema.

¿Un poco de resumen hasta aquí? no problem, aquí unas slides para sintetizar:

¿Crees que mi idea será viable? from David (davidjguru) Rodríguez

 

¿Por donde empezar? bien, os expongo unos ejercicios de base para ir modelando el punto 1. Estos ejercicios forman parte del manual “MBA Personal” de Josh Kaufman, un libro para formar en temas de empresa desde la óptica del auto-aprendizaje.

Ej.1 -> Decidir en que tipo de negocio estamos pensando

Es un ejercicio intuitivo, sin más ciencia que pensar un poco e ir dando respuestas, en este caso seleccionando la opción más parecida a nuestra idea. Dice el autor del ejercicio: “Para ofrecer un producto de valor a un tercero, hemos de hacerlo de forma tal que las personas estén dispuestas a pagar por él. Afortunadamente, la rueda ya está inventada El valor económico adopta en general uno de estos doce modelos estándar:”

Modelos estándar de un producto de valor:

  1. Producto. Cree un artículo, o una entidad, tangible y luego véndalo y distribúyalo por un valor superior a su coste.
  2. Servicio. Ofrezca ayuda o asistencia y luego cobre una cantidad por el bien.
  3. Recurso compartido. Cree algo valioso y duradero que puedan usar muchas personas y luego cobre una cantidad para garantizar su acceso.
  4. Suscripción. Ofrezca un bien de manera continuada y cobre una cuota periódica.
  5. Reventa. Adquiera algo de valor a un mayorista y véndalo a un minorista a un precio superior.
  6. Leasing. Adquiera algo de valor y deje que otra persona lo utilice durante un período determinado de tiempo a cambio de pagar una cantidad.
  7. Agencia. Introduzca y venda un producto o un servicio en nombre de un tercero, y cobre un porcentaje del precio de la transacción en concepto de retribución.
  8. Aportación de público. Capte la atención de un grupo de personas con determinadas características en común y luego venda el acceso al grupo, a través de la publicidad, a una empresa interesada en ese público.
  9. Préstamo. Preste cierta cantidad de dinero; luego, durante un período estipulado de tiempo, recupere el pago, que equivaldrá al préstamo original más una tasa de interés establecida.
  10. Opción. Ofrezca la posibilidad de emprender una acción determinada durante un período estipulado de tiempo por un precio.
  11. Seguros. Asuma riesgos, a cambio de una serie de pagos preestablecidos, de que quien suscribe una póliza de seguro pueda sufrir una desgracia y deba abonar las reclamaciones de ser así.
  12. Capital. Compre una participación de una empresa y luego cobre la parte correspondiente de las ganancias en concepto de pago único o dividendo activo.

Ej.2-> Diez maneras de evaluar el mercado

Ejercicio también intuitivo y nada determinante. Please, no os desaniméis en base al resultado que esto es solo un juego :-*

Tienes que puntuar del 0 al 10 los diez factores que aparecen a continuación considerando el 0 absolutamente desagradable y el 10 extremadamente atractivo. Si duda, sea conservador en su valoración.

  1. La urgencia. ¿Cuánto le urge al cliente poseer esto ahora mismo? (Alquilar una película antigua es un claro ejemplo de poca urgencia; ver el primer pase de una película la noche del estreno es un ejemplo de mucha urgencia, porque eso solo ocurre una vez.)
  2. El tamaño del mercado. ¿Cuántas personas compran de manera frecuentemente productos parecidos al suyo? (El mercado de las asignaturas-relleno de la universidad es muy reducido; el mercado de los remedios para el cáncer es enorme.)
  3. El precio del potencial producto. ¿Cuál es el precio máximo que un comprador estaría dispuesto a pagar por una solución? (Las piruletas se venden a 0,05 dólares; los portaviones, a miles de millones.)
  4. El coste de ganar un cliente. ¿Es fácil ganar un nuevo cliente? Como promedio, ¿cuánto costaría generar una venta, tanto en dinero como en esfuerzo? (Los restaurantes ubicados en autopistas interestatales muy transitadas gastan poco en atraer nuevos clientes. Los negociadores por cuenta del gobierno pueden gastar millones en conseguir grandes contratos por las adquisiciones.)
  5. El coste del lanzamiento del producto de valor. ¿Cuánto costaría crear y proveer el bien o servicio de valor ofrecido, tanto en dinero como en esfuerzo? (Enviar documentos vía internet es prácticamente gratis; inventar un producto y construir una fábrica cuesta millones de dólares.)
  6. La singularidad de la oferta. ¿Su oferta es especial comparada con las que compiten en el mercado? ¿Será fácil para los competidores potenciales copiar su idea? (Hay muchas peluquerías, pero muy pocas empresas que ofrezcan un viaje particular por el espacio.)
  7. La rapidez con que entra en el mercado. ¿Eres rápido creando algo para vender? (Ofrecer al vecino cortar el césped le llevará unos minutos; la apertura de un banco puede llevar años.)
  8. La inversión de capital. ¿Cuánto tendrá que invertir antes de estar preparado para vender? (Para ser una limpiadora lo único que necesita son varios productos de limpieza valorados a un módico precio. Para extraer oro, necesita varios millones para comprar el terreno y el equipo de extracción.)
  9. La capacidad de ventas. ¿Cuenta con alguna otra oferta relacionada que pueda presentar a los posibles compradores? (Los clientes que compran máquinas de afeitar también necesitan espuma y cuchillas de recambio. Por el contrario, si compra un frisbee (disco volador) no necesitará otro a menos que lo pierda.)
  10. El potencial perenne. Una vez creada su oferta, ¿cuánto trabajo adicional tendrá que hacer para seguir vendiendo? (El asesoramiento empresarial requiere dedicación a lo largo de un período; un libro se edita una sola vez y luego se vende repetidas veces tal como se editó en su momento.)

Cuando hayas terminado, suma tus respuestas. Si has obtenido 50 puntos o menos, cambia de idea: dirige tu energía y tus recursos en otra dirección. Si has obtenido entre 50 y 75 puntos, tu idea te permitirá pagar facturas, pero no conseguirás maravillas sin haber invertido una gran cantidad de energía y de recursos en el proyecto; ténlo en cuenta. Si la puntuación es de 75 puntos o más, tu idea promete mucho; pisa a fondo el acelerador.

Las imágenes están disponibles en Flickr bajo licencia Creative Commons (CC-BY-NC-SA) de los usuarios.

La de cabecera de este post es del usuario David Defoe https://www.flickr.com/photos/thetoad01/

La de presentación de este post es del usuario Riccardo Cuppini https://www.flickr.com/photos/cuppini/

Creando marca: desarrollo y evolución de Campabase

mayo 30, 2013
Marca definitiva de Campabase

Durante estos días ando reflexionando sobre Campabase. Con motivo del cierre de la experiencia del 18 y 19 de mayo en Sevilla, todo el equipo organizador anda comprometido a revisar y evaluar todos los aspectos posibles del proyecto, antes de pasar al diseño de la siguiente fase de trabajo.

Así que he comenzado a viajar atrás en el tiempo para ir recuperando multitud de aspectos de todo el trabajo realizado para el proyecto desde que un 2 de octubre de 2012 un grupo de amigos y compañeros nos sentásemos juntos a hacer un brainstorming de ideas nuevas para construir un proyecto común, con la necesidad de volver a reunirnos para articular algo que tuviese como base la intervención generadora de cambios. Ese fue el principio.

Hoy he rescatado unos documentos que registran la intensa actividad que hemos tenido a la hora de ir conceptualizando y definiendo la marca. Actas de reuniones, hilos de correos, grandes discusiones y un sin fin de imágenes que parecen demostrar que la historia se escribe a veces con pequeños trozos que vamos dejando por el camino.

En el registro de todo ese trabajo iterativo, diré que hemos aprendido muchísimo de lo que importa y lo que no a la hora de configurar un branding apropiado para un proyecto. Conscientes de la importancia fundamental que tiene el dotar de una marca representativa a un proyecto, nos pusimos a trabajar desde la base. Aquí anoto los sucesivos resultados: algunos (muchos) son de risa, pero al margen de mostrar nuestra incapacidad para manejar herramientas de diseño gráfico también se muestra la pasión puesta y la inocencia relativa de quienes quieren hacer cosas y buscan el camino.

Necesitábamos encontrar una identidad que tuviese la suficiente envergadura como para soportar su parte de responsabilidad en el desarrollo de la estrategia general del proyecto:

Estrategia Campabase

Como nos explicó Gem Romero de Bassat Ogilvy en aquella magnífica sesión que nos dio en el máster de Planificación estratégica, en resumen las marcas son colecciones de post-its que  llevamos en la cabeza y que la publicidad se encarga de ir instaurando. Las evocaciones casi inconscientes que aparecen al tener que tomar una decisión de compra vendrían entonces a ser como una reordenación mental de esos post-its que andan por la mente. Recomiendo este artículo de su blog para ilustrar mejor esta idea.

Lo segundo que hicimos (lo primero fue concretar la esencia y el espíritu del proyecto) fue realizar el “naming” o bautismo de la marca. Brainstorming puro y duro, y luego iterar para ir acercando conceptos que estuviesen relacionados. Algunos test de naming, como por ejemplo consultar con personas externas al proyecto que le funcionaba mejor y que recordaban más. De este trabajo resultó el concepto “Campabase”, pero la verdad es que manejábamos algunos más (suerte y alivio de que algunos no salieran ganadores):

naming_campabase

En definitiva, ¿qué debería transmitir nuestra marca? ¿a quien se dirige al hablar? Ahí empezó nuestro análisis. Consensuamos su misión, visión y valores, y nos pusimos a afinar el target. Con perfiles, con objetivos, con características, con datos y modelos de usuarios tipo:

Target de Campabase

Empezábamos a comprender con quien tendríamos que comunicarnos. Era un buen paso. Nos pusimos a analizar la relación valores-colores que deberíamos trabajar y nos salían cosas como esta:

“Tonos cálidos. Amarillo. Atardecer. Asociados a la tierra. Azul celeste. Verde botella. Turquesa/beige marrón. Tierra viva. Encontrar respuestas. Pureza. Cambio. Fluidez. Claridad. Tranquilidad. Fuerza. Amanecer. Raices. Iniciativa. Ocio/disfrute. Perseverancia.”

Bonita lista. Romántica y tal…pero hay que había que casarla necesariamente con el aporte de valor que tiene el proyecto. Así que a iterar y a ir restando hasta llegar a la mínima expresión de todo esto.

Tras sesiones muy largas de trabajo quedaba algo como esto (aviso de que el condicionamiento de que todos hayamos sido Scouts nos puede):

  • Incluir el verde entre los colores.

  • Las formas poco agresivas. Quizás, círculos y líneas curvas.

  • Tienda de campaña y algún símbolo relacionado con el emprendizaje, quizás, una tienda desde donde nazca algo parecido a un camino que lleva a una cumbre.

Y empezamos a cerrar posibles elementos gráficos:

Elementos gráficos de Campabase

Y seguimos jugando con las pizarras, los rotuladores y las ideas chifladas:

Más elementos gráficos de Campabase

Hasta que en pleno dislate, comenzamos a realizar ejercicios para plasmar el concepto (agárrense los cinturones). Por suerte no perdimos las ganas de seguir puliendo paso a paso:

Llegado el momento nuestro amigo José Luis tomó el timón de la construcción gráfica y consiguió crear lo que todos teníamos en la mente (loor al artista):

En una primera versión:

campabase_foto

En una segunda versión (se ha modificado un pequeño elemento, a ver si adivináis cual es):

 

Campabase_banner_entrada

 

¡Por fin teníamos el concepto! pero…¿esto quiere decir “marca”?…en principio, no. Hay una diferencia básica entre un proyecto-que-tiene-un-logo y una marca. La clave radica en la razón de existir. La marca tiene un sentido y vive en un contexto determinado. La marca para proyectarse en el tiempo debe vivir entre elementos culturales.

La clave es encontrar la “tensión cultural” que justificaría la existencia del proyecto y su marca. Técnicamente la marca no viene a resolver esa tensión por si misma, pero viene a instalarse en ella, a ayudar a relativizarla mediante su aporte de valor y su beneficio de uso. Había que definir la tensión cultural sobre la que surfea Campabase. Las grandes marcas son las que apoyan sus estrategias de comunicación y posicionamiento en tensiones culturales concretas e importantes para el usuario/público/cliente.

¿Recordáis la campaña de Dove a favor de “la belleza real”? Ese es el rollo. Surfear sobre una tensión cultural. Y para que el trabajo esté bien hecho hay que encontrarla, comprenderla, atarla en corto y profundizarla.  A esto dedicamos varias sesiones de trabajo, que en total sumaron unas quince horas de trabajo común en equipo. Realizamos el trabajo por fases.

En primer lugar tras la exposición teórica, un ejercicio para evaluar si habíamos comprendido bien los conceptos y las relaciones:

Primer ejercicio: detectar tensiones culturales (al menos cuatro) que las marcas estén usando para transmitir y posicionarse.

Luego jugar a detectarlas e identificarlas:
Segundo ejercicio: reunir al menos tres tensiones culturales fuera del campo de trabajo de las grandes marcas.

Y ya por fin comenzar a enfocarnos al contexto del proyecto Campabase:

Tercer ejercicio: ¿Sobre que tensión cultural surfeará toda la actividad y comunicación de Campabase?

Realizamos también otros ejercicios como la personificación de la marca (jugar a hacernos preguntas para definir su personalidad), que nos dejó resultados divertidos como estos:

Caracterización de la marca Campabase

Caracterización de la marca Campabase 2

También le dedicamos algunas horas al trabajo de análisis llamado “The Brand Wheel”, en la que vamos definiendo aspectos de la marca mediante el desarrollo de niveles en una sucesión de círculos concéntricos:

 

The brand wheel

 

Todo este trabajo nos proporcionó una buena base de partida para comprender el enfoque y el diseño de estrategias y tácticas a usar. Nos permitió perfilar la personalidad de Campabase, su lenguaje y sus interlocutores potenciales, su aspecto y su definición visual (Campabase como marca no tiene colores corporativos propios. Es una decisión de diseño creativo y según en que entornos puede generar shocks y debates bizantinos). Al margen de los manuales de identidad corporativa y de aplicaciones, este trabajo nos permitió definir otro manual más: el brand guardianship, la guía que debe observarse para la proyección de la personalidad de la marca y que describe los límites de lo posible en cuanto a la comunicación.

En estas slides está el guión de trabajo que seguimos. No son muy autocontenidas, pero dan pistas sobre como afrontamos el enfoque de la marca.

Queda todavía mucho trabajo por hacer para seguir profundizando en la personalidad y definición gráfica de la marca Campabase. Personalmente soy partidario de aumentar la simplicidad y seguir restando. Pero llegará. Hasta la fecha hemos conseguido sentar unas buenas bases y estoy seguro que lo seguiremos haciendo.

 

Si has llegado hasta aquí leyendo este post, debo suponer que el tema te interesa (y que tienes voluntad espartana). Así que me despido y me pongo a tu disposición. Espero que el relato os haya gustado. Para nosotros ha sido una enorme vivencia.

 

Un saludo a todos,

 

David.

 

Innovación en empresas: Pielfort

enero 27, 2013

Introducción

Hace unos días dentro de una conversación entre viejos amigos tocábamos el tema de la innovación tecnológica. Comenzamos por el frente de la administración pública con sus técnicas, sus recursos y sus despilfarros y luego pasamos a la parte de la empresa privada.

Básicamente comentábamos estadísticas sobre apuestas de innovación, cambios de paradigma y adaptación de nuevos modelos por parte de las empresas privadas.

Tocábamos los datos cuando alcanzamos un punto de la conversación en el que se desveló un curioso modelo mental. Uno de mis compañeros expresó algo así como que era normal que las compañías y empresas más grandes, con más recursos y más trayectoria fuesen más punteras en tecnología e innovación. Risas generalizadas. Tranquilamente le expusimos casos concretos donde grandes compañías nadaban en un indolente océano de analfabetismo digital ejemplar y al contrario, casos de pequeñas empresas familiares con limitados recursos que habían realizado todo un salto al vacío de manera intuitiva para integrar técnicas y tecnologías nuevas, transformando todo un modelo de negocio antiguo e hiperlocal.

¿De que hablo en concreto?

Por nuestras características (yo ya no sé donde están las claves, si en lo social, en lo cultural, en lo climático…) los sureños somos muy particulares a nivel empresarial. He vivido varias situaciones como las que comentaba hoy en clase Enrique Acosta empresarios con productos geniales que no comprenden las necesidad de crear una marca propia cuando consiguen colocar toda o casi toda su producción a nivel local. Si logran vender, ¿para que invertir en algo más? ¿qué necesidad tienen?. Lo curioso como apuntaba Enrique, con toda la razón del mundo es que mientras dialogas con ellos ves la marca italiana de sus zapatos, o el reloj suizo, o la marca inglesa de su jersey. Compran y consumen de manera global, están influenciados por el valor de las marcas y sus productos, pero se resisten a asumir la inevitabilidad de establecer una visión global para ventas en un contexto más amplio.

¿Excepciones?

Sí, tengo una muy clara y relativamente cercana. El caso de Pielfort. Pielfort como marca y Romerpiel como sociedad y empresa, configuran un ejemplo genial de que “lo pequeño” puede ser innovador, arriesgado y creativo.

La empresa se inició con las inquietudes de un artesano de la piel de Ubrique (Cádiz) que tenía la fotografía como hobby. A partir de cierto momento, comenzó a crear sus propios álbumes fotográficos aprovechando su experiencia en el tratamiento de la piel y empezó el movimiento.

Claves

Una de las claves está en la producción: respetan los procesos y principios de los viejos métodos artesanales. Piel de calidad y procedimientos que aseguran unos productos realmente geniales (aquí en la imagen con uno de mis álbumes. Este en particular me parece una verdadera obra de arte):

davidjguru y pielfort

Otra de las claves está en la llegada de la segunda generación. Sabemos que estadísticamente los puntos de inflexión en una empresa familiar suelen venir en torno a la segunda o tercera generación, en base a cuanto se abran las sucesivas ramas familiares (parece ser que a los primos no les gusta mucho trabajar unidos) o bien en cuanto a la necesidad de innovación cuando el modelo primario se sigue reproducciendo a pesar de los cambios de contexto sociales y técnológicos. En esto, la empresa vuelve a ser clave. Liderada por dos hijos con visiones modernas, actuales e internacionales, Pielfort es una marca que tiene en su experiencia haber trabajado con la Casa Real Española, la Casa Real de Marruecos, la familia Kennedy, futbolistas, cantantes, a través de sus fotógrafos
personales o recibiendo llamadas de trabajo de países donde no estaban publicitados.

Espectaculares son sus casos de trabajo en colaboración con Swarovski para crear un producto exclusivo y lujoso orientado a mercados internacionales, o su colaboración con el señor Harrison Funk uno de los fotógrafos más míticos de EEUU.

 

La estrategia

Yo tomé contacto con José David Romero (mánager de negocio internacional) hace algún tiempo para una pequeña consultoría que estableciese el marco de una buena estrategia digital. Comenzamos por el posicionamiento del sitio web que tenía la marca en aquel entonces, pero era Flash así que el SEO lo tenía complicado.

A partir de ahí entendí que como personas bien formadas y preparadas tenían claro que el futuro pasaría por Internet. Desde entonces se han desarrollado sus canales en Facebook, en Twitter, Youtube, Pinterest o Instagram, han renovado su sitio web con una nueva plataforma y se han adquirido grandes compromisos de cara a la comunicación externa de la marca con sus clientes y seguidores.

Ademas han ideado nuevas propuestas tecnológicas como la idea de proveer a sus clientes de modelos de álbumes digitales que pueden configurar a su gusto. Buena idea.

Una declaración de principios que a día de hoy no les falla: Según los datos que manejo, existen unas cifras globales de venta por un valor aproximado de 1,3 millones de euros al año en una red global que incluye actividad comercial en países como Estados Unidos, Reino Unido, Francia, Rusia, Emiratos Árabes, Venezuela o Alemania, bien por ventas directas o mediante relaciones comerciales con agentes locales. Increíble.

Un buen ejemplo de pensar de manera diferente, de ser creativos y trascender lo local para una globalidad en marcha. No todo en nuestra tierra posee una visión limitada.

Al César lo que es del César.

Nuestro primer Betabeers en Sevilla #BBsvq

junio 14, 2012

Ayer miércoles tuvo lugar el primer Betabeers aquí en Sevilla. Mis ganas eran muchas y desde hacía tiempo quería probar el formato. La cosa venía de atrás.

 

Para quien no lo conozca, este evento es una actividad mensual orientada al encuentro de personas enfocadas en el sector tecnológico: desarrolladores, maquetadores, diseñadores y algunos perfiles más.

 

Yo conocí personalmente a Miquel Camps, uno de sus fundadores, hace cosa de más de un año durante The Event en Cáceres. Presentó allí la magnífica idea de Axhim: un portal web (actualmente fuera de circulación) para preguntas y respuestas de manera libre y sin censura que se convertiría en un espacio abierto para el humor, las ideas y el troleo. Aquella locura simple y genial se convirtió en un agujero de horas para algunos de nosotros que participábamos de la comunidad con nuestras ideas críticas, humorísticas o directamente absurdas.

 

Axhim.com

 

Miquel Camps me transmitió cosas muy positivas desde el principio y la verdad que me cayó muy bien. Siempre sonriente, breve y divertido, empezamos a seguirle la pista por las cosas que hacía y donde las hacía. En eso apareció el evento Betabeers, que nunca pude disfrutar por limitaciones geográficas. Hasta que por fin ha llegado (o ha sido traido más bien, para hacer justicia al trabajo de sus promotores locales) aquí a nuestra tierra. Genial.

 

Logotipo de Betabeers

La sesión de ayer me encantó: nos reunimos un conjunto muy heterogéneo de personas del entorno tecnológico y se pareció mucho a estar entre amigos. Viejos conocidos, amigos, antiguos compañeros de armas en el mismo espacio, como una gran familia. Cada cual desde su escuela, pero casi todos practicando un buen Kung-Fu (como a Javi Baena y a mi nos gusta decir).  Estuvieron presentes los amigos de Wombytes (piratas como nosotros), los compañeros de BetyByte, otras empresas y buenos profesionales freelance. Además de la alegría de ver a antiguos compañeros como @nackd y @daniconil.

 

Las sesiones buenas casi todas. Me gustó el formato breve para ayudar al ponente a concentrarse en los puntos fuertes de su relato y obviar el resto. La fórmula es sencilla: si algo te resulta de interés, el momento de networking es el ideal para profundizar. A nivel de contenidos me gustaron casi todas. Ildefonso Montero en su blog hace una reseña sobre ellas, así que no las repetiré. Apenas decir que mi favorita fué la charla de Carmelo Zubeldia acerca del proyecto Guifi.net para construir una red libre, abierta y neutral. Al cierre de las sesiones, una ronda genial de presentaciones personales con mucho humor (quedará para la posteridad la presentación de @ewokcillo: “Hola, soy Diego y me conocen como Machito”. Buen karma.

 

Aquí he localizado las slides de Pepe Cano sobre su sesión de Ember.js. Y aquí las de Juan Vázquez sobre EasyData. Además la colección de imágenes de la sesión aquí.

 

Simplemente dar las gracias a la organización: a Jaime, a Juan y a Zazu por todo el trabajo realizado, por el seguimiento para cerrar las sesiones, por las ganas y su disponibilidad. Muy buena experiencia y muy buenas expectivas para el resto de sesiones.

En la carretera con Guadalinfo y Alcaldías 2.0

enero 25, 2012

He tenido una gran oportunidad en forma de propuesta: formar parte de los equipos que van recorriendo las provincias andaluzas para las sesiones de Alcaldías 2.0

Sesión de alcaldes 2.0 en Granada

¿Qué es Alcaldías 2.0? 

Una iniciativa surgida al abrigo de la red Guadalinfo: Una red formada por aproximadamente setecientos cincuenta telecentros enfocados a llevar la vida digital a las zonas rurales en Andalucía.

Dentro de esta iniciativa, un planteamiento añadido: impartir sesiones formativas sobre redes sociales y su potencialidad para mejorar las relaciones entre instituciones y ciudadanía.

A lo largo de las ocho provincias van reuniéndose los alcaldes de los municipios involucrados para charlar, escuchar y debatir en torno a la brecha digital, las nuevas tecnologías y la inclusión de las redes sociales como parte fundamental del juego democrático en la vida de las poblaciones.

Durante dos semanas, hemos ido a transmitir conocimiento e inspiración desde las capitales de las provincias a aquellos interesados en estas cuestiones.

Ya estamos en la segunda semana de trabajo y hemos estado en Almería. A estas horas voy preparando la sesión de mañana que se realizará en Málaga y veo en perspectiva toda la experiencia acumulada en las sesiones anteriores.

Cada sesión es distinta, hay matices diferentes y se producen debates sobre cuestiones específicas que están siendo muy enriquecedores

¿Mi cometido? Sencillo. Básicamente, bajar a la tierra todo el contenido que se está transmitiendo. Demostrar lo real, hablar de técnicas y herramientas.

Mis sesiones intentan ser dinámicas, participativas y sobre todo motivadoras. Una mezcla de experiencias e inspiración. Normalmente evalúo al principio el nivel del auditorio. Tras una presentación rápida, varias preguntas para ubicar el conocimiento y la experiencias que las personas tienen sobre las redes sociales y su uso.

Esto determina el punto de partida de la sesión y hasta donde podemos llegar con las limitaciones que el tiempo impone. No es sencillo, da la sensación que siempre se queda algo importante por decir, pero se compensa con todas las cosas que se preguntan.

Las lineas de mi intervención están siendo las siguientes:

  1. ¿Qué sabemos de las redes sociales? ¿Cuantas conocemos? ¿Cuantos tipos hay? ¿Hay reglas en ellas?
  2. La parte positiva de la experiencia: Objetivos por los que vale la pena estar en las redes sociales y beneficios que pueden obtenerse.
  3. La parte negativa de la experiencia: Problemas que se pueden tener. Riesgos que se corren. Gestión de las crisis. Técnicas y formas de afrontarlo.
  4. Comunicación y contenidos: Paradigmas Push y Pull, conversación, perfiles institucionales en la red. Cosas bien hechas y cosas mal hechas.
  5. Prevención, Detección y Acción: Guías de estilo para la comunicación. Herramientas de monitorización, control y alertas.  Toma de decisiones.
  6. Visión estratégica: Sentido de trayectoria. Objetivos y atomización de estos. Mediciones. Desviaciones. Acciones.

Estas son las patas de toda la sesión. Pongo aquí las trasparencias que estoy usando a modo de apoyo en las sesiones:

 

En resumen están siendo unas jornadas increíbles, y de todo lo que estoy recibiendo, destaco dos aspectos fundamentales:

  • La diferencia entre el trabajo en este tipo de proyectos dentro de un gran administración y una administración local. La adecuación de los recursos, la optimización del esfuerzo. Al final, noto que las personas quieren hablar y oír de canales, pero en realidad hay que aplicar mucho más esfuerzo en hacer comprender el cambio de cultura que supone la red. Ahí está la clave de trabajo para estas sesiones.
  • Las personas que estoy conociendo: desde los responsables de ayuntamientos, los dinamizadores (de centro y territoriales), alcaldes y por supuesto el equipo humano del proyecto Guadalinfo, con personas entregadas a la superación de la brecha digital.

Todavía quedan las sesiones de Málaga y Jaén, pero ya tengo la sensación de que cuando llegue a casa y me siente a pensar, sentiré que hemos hecho algo grande y útil. Puro orgullo. Además la satisfacción de conocer personalmente a CristinaVera, de la que volveré parcialmente enamorado (aunque ella no esté de acuerdo con el uso de la Netiqueta en las redes sociales) 😛

Y unos enlaces con algunas publicaciones en las que hemos ido apareciendo:

http://www.canalsur.es/portal_rtva/web/noticia/id/186381/noticias/tecnologia/alcaldes_reciben_formacion_en_web_20_para_el_dialogo_con_la_ciudadania

http://www.youtube.com/watch?v=XOztYmsHaW0
http://www.cordobainformacion.com/inicio.php?codigo=33077
Gracias a todos por el apoyo, la confianza y el cariño. Y a Guadalinfo por las imágenes que me permite tomar prestadas. Un abrazo. Seguimos en el camino.

Estrategia digital bajo el modelo SOSTAC

octubre 29, 2011
Con twitter y a lo locoEn el desvarío que suponen muchas veces los proyectos enfocados hacía la estrategia digital, a veces se dan situaciones de caos total.Es el caso de lo que yo llamo “con twitter y a loco”. Simplemente entidades (administración pública, empresa privada, marcas personales, etc) que aparecen a la búsqueda de algo que no terminan de encontrar.

Solo se sumaron al “hype” del fenómeno Social Media como hace unos años todos se sumaron al efecto web: querían una página web porque “había que estar ahí”. En esta nueva versión es algo parecido: “Tenemos página de facebook y cuenta en twitter, pero no sabemos muy bien que hacer con ello”. Mal.

No me hables de canales. Hablemos de objetivos, de tácticas, de visión estratégica que en cuanto se vaya concretando en acciones, se irán viendo bajo que canal deben implementarse. Pero eso se irá analizando. Antes que nada, vamos a poner orden, sistematización y algo de metodología en ello.

El modelo SOSTAC

Es un sistema de planificación estratégica inventada por un señor llamado PR Smith, bajo el concepto de sistema de planificación estratégica para proyectos y una clara orientación hacia el marketing. No es conocimiento libre (todo va bajo pago y copyright), pero bueno, si es útil, pues vamos a intentar compartir el conocimiento, ¿no? 🙂

Esta especie de propuesta para trazar planes plantea un conjunto de estados de bastante sentido común y que consta de una serie de fases/bloques de trabajo que organiza y segmenta bastante bien todo lo que requiere un plan estratégico para proyectos con cierta calidad.Veamos gráficamente en que consiste:
Modelo SOSTAC en plan casero

Como podemos ver, cada módulo establece una prioridad de trabajo y permite que se vayan realimentando, cada momento de la definición del proyecto puede enviar un feedback que sirva para modificar aspectos de otros módulos de los que depende.

Es un planteamiento que permite que el proyecto se mantenga vivo y exista una retroalimentación entre los bloques de trabajo.
Cada módulo ataca directamente a la resolución de las siguientes cuestiones:

1.-Análisis de la situación

Actualmente, ¿donde nos encontramos? ¿donde se encuentra nuestra competencia?

2.-Objetivos a alcanzar

En el corto, medio y largo plazo, ¿donde queremos estar? ¿qué queremos conseguir?

3.-Definición de estrategias

¿Qué vamos a hacer en general?

4.-Definición de tácticas

¿Cómo lo vamos a hacer?

5.-Acciones a implementar

En concreto, ¿quien va a hacer que y cuando?

6.-Control del desarrollo del proyecto

¿Cómo vamos a medir y con que métricas analizaremos el cumplimiento de los objetivos del proyecto?

Propuesta de fases de trabajo

Aquí va una organización posible para un proyecto de estrategia digital:

Fase I: Estudio de la estructura y contexto de la organización

Esta fase se orienta al estudio y análisis del contexto en el que se desarrolla el proyecto. El objetivo es trazar tres pilares fundamentales para este: de un lado el aspecto interno del proyecto, es decir, aquellos aspectos que sirven para comprender las necesidades por las que la compañía plantea la necesidad de una estrategia digital,  por otro lado el aspecto externo del mismo: el estudio del estado en el que se encuentra la compañía en el plano del entorno digital, y en tercer lugar se analiza el contexto competitivo de la compañia en la red, cotejando con otra entidades que posean un “core” de negocio similar.

Fase II: Diseño de la estrategia digital asociada a la compañía

Esta fase se orienta al planteamiento de objetivos de alto nivel, es decir, al terminar la fase debemos tener un “timing” de objetivos en cuanto a que los análisis deben satisfacer una visión de corto, medio y largo plazo sobre el proyecto, determinando en fechas aproximadas los hitos de supervisión del proyecto.

De igual forma en esa fase se abordarán la definición del planteamiento estratégico y táctico del proyecto, además de realizar la concreción de las acciones que se acometerán en los trabajos planeados.

Fase III

En esta fase del proyecto, se artícularán las acciones en base a hitos de trabajo y se realizará la definición de las métricas oportunas, es decir, los KPI que se mostrarán en un nuestro cuadro de mando del proyecto, de forma que empezaremos a tomar el pulso al rendimiento del proyecto, analizar el desvío y/o valorar la consecución de nuestros objetivos.

Fase IV

En esta fase, estaremos realizando las revisiones periódicas recogidas en la planificación del proyecto, revisando el avance de los KPI, proporcionando formación sobre gestión y crisis de reputación online, y rediseñando aquellos apartados que no cumplan los objetivos propuestos o cuyas acciones no resulten suficientemente afinadas.

Es una fase enfocada al desarrollo iterativo sobre el proyecto, volveremos sobre los objetivos de alto nivel, sobre las estrategias, tácticas y sus acciones asociadas y realizaremos evaluaciones críticas sobre su desarrollo.

Incluyo una representación visual de todos los trabajos que deben realizarse en el desarrollo del proyecto. Es parte de una consultoría que realizé personalmente para una compañía. Como se aprecia nada trivial. ¡Salud!

Trabajos asociados a estrategia digital

Actualización (04/01/2011)

Aprovecho para poner aquí una presentación sobre este tema que tengo preparada en Slideshare, creo que puede ser complementario.

Atacando la fase de visibilidad SEO de un proyecto

agosto 20, 2011

Introducción

A veces tenemos que trabajar con proyectos, en los que durante una primera fase, tenemos que ir directamente a conseguir visibilidad.

Puede ser un proyecto de tipo comercial, enfocado hacía el markting online, o por ejemplo un proyecto de corte político.

En los dos casos hay situaciones de partida donde no hay conseguida una mínima visibilidad. En el caso de proyecto de marketing online porque la marca no tenía presencia en la red o era muy pobre. No cabe de momento de hablar de objetivos de captación, ni de embudos de conversión, ni de usuarios cualificados o no. Simplemente buscamos que en esta fase del proyecto, la marca empiece a aparecer.

En la orientación política y/o institucional de otros proyectos es algo parecido. Tecleas el nombre del candidato o cargo público y antes que cualquier información positiva, aparecen titulares negativos y/o datos asociados a malas noticias o información sensacionalista. Hay que posicionar el proyecto, esa pata técnica que se podrá resolver con una u otra visión tecnológica, con una plataforma u otra, pero que de cualquier manera, tendrá que aparecer.

En este contexto, es de suma importancia conseguir un posicionamiento en los buscadores.

Basicamente queremos influir sobre el carácter orgánico del posicionamiento del proyecto.

 

¿Qué es el carácter orgánico?

En realidad, simplemente lo que queremos es posicionar el proyecto dentro del cuerpo de los resultados de búsqueda de un navegador sin necesidad de pagar al buscador para tener acceso a una posición destacada en los resultados de la búsquedas a los usuarios.

La optimización para buscadores afecta únicamente a los resultados de búsqueda orgánicos, no a los resultados pagados o patrocinados, como sería el caso de Google AdWords.

En nuestro caso, tenemos que cumplir una serie de pautas para conseguir un correcto posicionamiento en el contexto de los enlaces no patrocinados, es decir de una forma relativamente “natural” mediante técnicas éticas.

Diferencias entre ambos tipos de enlaces:

 

Posicionamiento orgánico SEO

 

Para influir sobre ello, además de técnicas más avanzadas, tenemos que preparar dos aspectos básicos de esta fase SEO.

 

Los robots de Google

El robot de Google, también llamado Googlebot o araña, son los robots usados por Google para descubrir páginas nuevas y/o actualizadas, con el objetivo de incluirlas en el índice de resultados de Google.

Utilizan un proceso de rastreo basado en algoritmos para determinar que sitios hay que rastrear, la frecuencia de rastreo y el número de páginas en buscar en cada sitio web.

Googlebot, al igual que el resto de herramientas de otros motores de búsqueda, intentará acceder al fichero robots.txt, un fichero que debe contener la información de valor sobre que zonas están accesibles y cuales no.

Aquí puedes encontrar material útil para definir un robots.txt.

 

El fichero sitemap.xml

Para realizar un correcto posicionamiento SEO orgánico, es necesario proveer a los motores de búsqueda un fichero llamado “sitemap.xml”. Este fichero proporciona una lista de páginas del sitio combinada con información adicional (frecuencia de cambios de contenidos, actualizaciones y nivel de importancia).

El fichero debe adecuarse a las normas y pautas de construcción del fichero sitemaps, cumpliendo satisfactoriamente el protocolo consensuado sobre ello.

 

El protocolo sitemap

El protocolo Sitemap se construye en base a etiquetas XML (Tags) incluidas en un archivo con codificación UTF-8.
Los valores de datos (por contraposición a las etiquetas mismas) deben utilizar códigos de escape para ciertos caracteres especiales, tal como se acostumbra en HTML.

Por ejemplo, las comillas dobles (“) deben ser reemplazadas por &quot; y los signos menor (<) y mayor (>) por &lt; y &gt; respectivamente.

Algo muy positivo es que actualmente las grandes compañías de motores de búsqueda (Google, Microsoft y Yahoo) han consensuado el protocolo en su versión 0.9 y este es aceptado en sus motores de búsqueda.

 

Contenidos obligatorios del fichero sitemap.xml

1. El archivo debe comenzar con una etiqueta de apertura <urlset> y terminar con una de cierre </urlset>
2. Especificar el protocolo estándar al que responde dentro de la etiqueta de apertura <urlset> (ver en el ejemplo siguiente)
3. Incluir una entrada <url> por cada dirección URL (que corresponderá a cada una de las páginas del sitio) como nodo XML padre
4. Incluir un nodo XML hijo <loc> para cada dirección URL (cada nodo XML padre <url>)

Ejemplo de archivo con contenidos obligatorios

<?xml version=”1.0″ encoding=”UTF-8″?>
<urlset xmlns=”http://www.sitemaps.org/schemas/sitemap/0.9″&gt;
<url>
<loc>http://www.misitio.com/</loc&gt;
</url>
<url>
<loc>http://www.misitio.com/contacto.htm</loc&gt;
</url>
</urlset>

 

Contenidos opcionales del fichero sitemap .xml
Cada nodo <url> padre puede contener (además del nodo <loc> hijo obligatorio) cierta información adicional útil para que el proceso de indexación se realice más inteligentemente. Los nodos opcionales, aunque importantes, son:

<lastmod>Fecha</lastmod>
Se refiere a la fecha de la última modificación de la página que figura en <loc>
Esta fecha debe expresarse en formado AAAA-MM-DD, por lo que el 8 de julio de 2006 será 2006-07-08.

<changefrec>Frec</changefrec>
Se refiere a que tan a menudo cambia la página que figura en <loc> y será un dato que indicará a la araña con qué frecuencia volver a visitar el sitio. Es un valor orientativo, por lo que no quiere decir que deba cumplirse forzosamente.

Frec puede tomar alguno de los siguientes valores: always (siempre, para páginas que cambian cada vez que se muestran. Típicamente, las dinámicas), hourly (a cada hora), daily (diariamente), weekly (semanalmente), monthly (mensualmente), yearly (anualmente) o never (nunca, típicamente para páginas archivadas).

<priority>Valor</priority>
Se refiere a la importancia que tiene la página que figura en <loc> respecto de las demás que componen el sitio. Es simplemente una manera de indicar prioridades relativas dentro del sitio, sin ningún efecto hacia el exterior del mismo.
Valor puede tomar valores entre 0 y 1. El valor por defecto es 0.5

Ejemplo de archivo con contenidos opcionales

<?xml version=”1.0″ encoding=”UTF-8″?>
<urlset xmlns=”http://www.sitemaps.org/schemas/sitemap/0.9″&gt;
<url>
<loc>http://www.misitio.com/</loc&gt;
<lastmod>2009-11-10</lastmod>
<changefrec>monthly</changefrec>
<priority>0.9</priority>
</url>
<url>
<loc>http://www.misitio.com/contacto.htm</loc&gt;
<lastmod>2009-12-01</lastmod>
<changefrec>yearly</changefrec>
<priority>0.3</priority>
</url>
</urlset>

 

Ubicación del archivo

El archivo XML debe alojarse en el servidor como un archivo más del sitio, con la salvedad de que puede contener las URL contenidas en el mismo directorio en que se encuentra o en otros contenidos en él.

Por ejemplo, si ubicamos el archivo sitemap.xml en el directorio referencia.com/prueba/ no podrá incluir URLs que se encuentren en referencia.com/
Por esta razón se recomienda colocar sitemap.xml directamente en el directorio raiz del sitio.

A partir de este punto solo queda enviar el sitemap a los buscadores, que generalmente disponen de una página específica para aceptarlo.

 

¿Algo más? ¡Mucho más! Pero sin duda creo que es una buena base de partida para el trabajo en esta fase. Espero que haya resultado algo útil y de fácil lectura.

Un saludo a todos, nos vemos en el próximo post y/o en las redes sociales.

 

Ciao!

Partes de un proyecto Web: SEO

julio 16, 2011

Introducción

Hoy en día, en el estado que se encuentra nuestro negocio y el tejido en el que nos desempeñamos todos los días, se hace cada vez más necesario el superar la visión puramente tecnológica de los proyectos en los que trabajamos.

Estamos en un mercado donde a nivel tecnológico se ofrecen aspectos parecidos, puedes competir con empresas que tienen al menos el mismo nivel tecnológico y por supuesto, incluso una experiencia todavía mayor, construida con mejores referencias y casos de éxito.

 

Es el momento de estar añadiendo capas a la implementación puramente tecnológica de los proyectos, de cubrir aquello que en principio queda fuera del alcance, pero se hace necesario aportar algo más a nuestras propuestas.

Podemos implementar enormes y usables portales web, con alto rendimiento, con una categorización de calidad sobre la información contenida y exhaustivas taxonomías para ello, que cumpla los estándares y sean verdaderos productos de calidad. Pero no basta, hay que llegar algo más lejos. Hay que añadirle más valor a tu propuesta, hay que intentar cubrir todas las partes del proceso y ser verdaderamente capaz de ello.

 

Hoy quiero escribir el primero de una serie de artículos sobre un bloque de trabajo que influye sobre nuestros proyectos enfocados a la web: el análisis y la mejora del SEO. Podemos implementar tu site, pero no vamos a quedarnos ahí. También trabajamos para proyectarlo en los resultados de búsqueda de los principales motores.

 

¿Qué es SEO?

SEO es un acrónimo de Search Engine Optimization, que hace referencia al el proceso de mejorar la visibilidad de una página web en los diferentes buscadores, como Google, Yahoo! o Bing.

SEO apunta a una serie de técnicas de análisis e implementación que buscan aumentar esa visibilidad de una forma llamada “manera orgánica”, es decir sin necesidad de pagar al buscador para tener acceso a una posición destacada en los resultados de la búsquedas a los usuarios.

 

Como conjunto de técnicas, es un grupo muy amplio de acciones diversas que se realizan enfocadas a este único fin. La naturaleza de las tareas abordan desde la optimización del espacio web (código), el diseño del sitio, la navegación interna por el espacio web o la adaptación del contenido propio que se muestra en el sitio.

 

Clasificación de técnicas SEO

A nivel introductorio, para ordenar las tipologías de técnicas SEO podemos usar dos clasificaciones con dos tipos cada una:

En base al entorno donde se opera

 

SEO On-site: Es el conjunto de acciones SEO acometidas en el interior del sitio web a optimizar. Acciones como por ejemplo: revisar el código fuente del sitio, mejorar el contenido HTML, enriquecer con keywords contenidos y código, eliminación de enlaces rotos, mejora de los enlaces internos y URL’s.

SEO Off-site: Son técnicas y métodos que no se aplican directamente a nuestro sitio web, pero tienen un gran impacto en como se desempeña nuestro sitio en los motores de búsqueda. El ejemplo más común es conseguir que nuestro sitio sea enlazado desde otros sitios (link building) en una forma adecuada.

 

En base a la legimitidad de las acciones

 

White SEO (SEO blanco): Son técnicas y métodos considerados por los motores de búsqueda como “legítimos” para conseguir que un website consiga un buen posicionamiento en los resultados de búsqueda.

Black SEO (SEO negro): Son técnicas y métodos que pueden llegar a dar buenos resultados, pero son considerados por los motores de búsqueda como malas prácticas (incluso “fraudulentas”) con el sólo propósito de conseguir un buen ranking sin que necesariamente el website tenga un contenido adecuado y relevante para los usuarios que hagan las búsquedas. Cuando los buscadores como Google detectan un sitio involucrado en estas prácticas, le aplican una penalización que implica que sus rankings sean afectados (devaluados) o incluso Google puede “banear” el sitio (borrarlo totalmente de su índice) por lo que la posibilidad de conseguir tráfico orgánico desde ese buscador será nula para ese sitio.

 

Una herramienta útil: Google insights

Google insights es una herramienta proporcionada por esta compañía para extraer información sobre comportamiento y tendencias basadas en keywords. Permite ubicar las consultas en cotas de tiempo y de espacio, localizándolas geográficamente. Además puedes delimitar las consultas a categorías concretas y naturaleza de la información.

 

Configuración de búsqueda de google insight

 

 

Permite además cotejar resultados entre varios términos y comparar gráficamente los resultados:

Gráfica comparativa de búsquedas en google insights

 

Y ofrece la posibilidad de mostrar geográficamente el origen de las consultas:

Representación geográfica de las consultas

Esta herramienta es muy útil para identificar palabras clave, y ayuda a realizar análisis mucho más exhaustivos sobre términos y tendencias.

Seguiré desarrollando estos conceptos y herramientas en el siguiente post. ¡Un saludo!.

Estructura de capas y datos en Drupal

junio 11, 2011

Bien, en este post me gustaría hacer una descripción conceptual sobre los elementos base de Drupal, el CMS o sistema gestor de contenidos que ultimamente ocupa mis días y base tecnológica de mis horas laborales.

Vamos a ver un sencillo esquema de conceptos que maneja Drupal, y pasemos a enumerarlos y describirlos:

 
Esquema estructural de capas y datos en Drupal

1.- En primer lugar tenemos el concepto de “Nodo” ¿qué es un nodo?

Un nodo es una unidad básica de información para Drupal. Usa un nombre genérico para determinar cualquier elemento útil a nivel de información dentro del CMS. Un nodo puede ser un artículo de una tienda virtual, un artículo de blog, y cualquier tipo de contenido que queramos mostrar en nuestro site.

Usados a modo de entidades genéricas, los nodos en Drupal son la base del sistema de información, la raiz del “pool” de datos.

En otro plano, los nodos no dejan de ser una abstracción sobre una serie de tablas de la base de datos que Drupal utiliza para la estructura del site. Maneja una serie de tablas que organizan la gestión de estos: node, node_type, node_access, node_revisions, y otras que asocian los nodos a funcionalidades asociadas del CMS como node_comment_statistics, para la información asociada a los comentarios realizados y sus estadísticas.

Con respecto a las tablas básicas, su gestión pertenece al propio Drupal, y en principio no tendríamos que hacer ningún cambio de magnitud sobre ellas.

Basicamente, los nodos tienen una serie de campos de información asociada tales como: Autor, Fecha, Título y Cuerpo del contenido. Además pueden ampliarse con otros campos e inclurso extenderse con funcionalidades que provean otros módulos de Drupal.

 

 
2.-Ahora los módulos de Drupal

Una característica básica de Drupal desde sus inicios es la de crearlo como un cojunto de piezas de lego. Es decir, la posibilidad de jugar con partes que puedan integrarse para ir configurando un site a nuestro propio gusto y añadiendo solamente aquellas funcionalidades que nos interesen tener disponibles.

Ahí reside la filosofía del módulo de Drupal. En la práctica son ficheros de código que incluyen funciones a modo de “hook”. Drupal realiza llamadas a estas funciones durante sus procesos. Esto supone una fortaleza de este CMS, ya que permite que no se altere la información y separa en dos capas la gestión visual de la información delegándolo en las funcionalidades asociadas a estos, mientras envía contenidos a los módulos para que estós realicen las modificaciones en las vistas de la información y abstrae de tener que actuar sobre el “core” del sistema.

El manejo de módulos es sencillo, basta con integrarlos dentro del directorio /modules y desde ahí ya podemos integrarlos en el sistema.

 

directorio de módulos de Drupal

Existen en la comunidad multitud de modulos disponibles para diversas funcionalidades a realizar en el site.

Buscar módulos de Drupal: http://drupal.org/project/modules

 

 

3.-Bloques y menús

Los bloques forman las regiones de interés dentro de nuestro site, es decir, la organización visual del contenido que mostraremos, los grupos de texto, las imágenes y la representación visual que tendremos en nuestro site. Se usan dentro de los layouts propios del theme que estemos usando en nuestro proyecto.

 

+Info sobre bloques (necesita actualización, pero la información es útil): http://drupal.org/documentation/blocks

 

4.-Permisos de usuario

En Drupal podremos crear todos los roles de usuarios que necesitemos y asignarles los permisos sobre las funcionalidades que estimemos oportunos. Lo normal será definir un rol y después activar mediante un listado de los módulos instalados que permisos tendrán, que podrán hacer y que no podrán hacer en nuestra plataforma.

A continuación dotaremos a esos roles de los usuarios específicos que podrán usar sus funcionalides asociadas.

 

Creación de roles de usuario en Drupal
5.-El Theme

Es el sistema que usa Drupal para dotar de aspecto visual a la plataforma. Es un conjunto de ficheros de configuración para crear la vista del contenido y su publicación. Pueden contener archivos de plantillas, hojas de estilo, scripts js y ficheros de información contextual .info

 

Y por último, el usuario. Ese señor que viene a visitar nuestro site : -)

 

¡Suerte con Drupal y hasta el próximo post!

 

 

Escribiendo para la web

mayo 24, 2011

Introito

De un tiempo a esta parte, me toca de vez en cuando hablar sobre blogs y escritura en la red. Bien sea por cuestiones de trabajo, por seminarios o talleres en los que participo. Y también directamente por preguntas de mis amigos. En resumen, llevo una época hablando sobre ello. Y hoy me apetece detenerme a organizar algunas pautas fundamentales. Que ustedes lo disfruten. Y disculpen si me pongo algo radical en algunos momentos. Es que quiero dar énfasis a ciertas ideas. 😉

Bien. Nos acercamos

Todo ha cambiado, y nuestra forma de leer también. La red ha revolucionado nuestro acceso a la información, y por el camino, ha tocado también nuestros métodos de procesarla. Ahora estamos en un entorno con millones de artículos interesantes, enlaces relacionados, información que compite con la tuya y/o la complementa. Y de una forma muy ágil.

Marcando el ritmo

No aburras. En serio. Concreta. Sintetiza. Organiza tus ideas y prepáralas bien. Tienes que estar más cerca de Augusto Monterroso[1] que de Marcel Proust[2]. Tú solo tienes diez segundos ¡solo diez! para ganar mi atención en el espacio web. Si en diez segundos como mucho no has conseguido atraerme o motivarme a que lea tu contenido, me voy. Sin más.

¿Pero las redes sociales no mataron a los blogs?

Sí y no. Las redes sociales dañaron a esos blogs rollo “Hoy voy a contar que me he cortado el pelo y luego he ido a hacer la compra”, ya que ahora, puedo saber eso siguiéndote en las redes. Pero el blog algo especializado, el de temáticas concretas, el que posee valor, el que aporta conocimiento al ser leído, ese NO.

Entonces, ¿qué plan?

Vale, no te pongas nervioso, vamos por partes.

1.-Ordena un poco tus ideas antes de ponerte a escribir, hazte un esbozo de lo que quieres poner en texto.

2.-Piensa siempre en la persona que va a leer: cuidado con frases hechas, modismos, expresiones coloquiales y otras cosas que se salgan del castellano más o menos oficial. 🙂

3.-Piensa siempre en la persona que va a leer: Plantea un trazado en forma de Z arístotélica. Es la forma en la que las culturas occidentales absorbemos información. De izquierda a derecha de arriba hacia abajo. Plantea el texto de forma que trazando esta figura podamos contextualizarnos.

4.-Piensa siempre en la persona que va a leer: Usa el estilo de pirámide invertida. Consiste en dejar claro al principio de que va tu contenido. Así, del tirón. El usuario ya sabe a que atenerse desde el primer párrafo.

5.-Piensa siempre en la persona que va a leer: Facilita la lectura todo lo que puedas, y dinamiza la estructura de tu contenido: ofrece negritas para un escaneo rápido de la información, ordena las ideas por parrafos independientes y con cierto sentido autónomo.

6.-Piensa siempre en la persona que va a leer: Frases sencillas. Sujeto, verbo, predicado. No complicar innecesariamente las frases. Un párrafo, una idea. Pensemos si podemos dividir en dos un párrafo de 6-8 líneas. Nielsen[3] recomienda usar menos del 50% del texto usado habitualmente en una publicación escrita.

7.- Piensa siempre en la persona que va a leer: Usa en la medida de lo posible, un lenguaje simple e informal. Es más adecuado que el elegante o formal, ya que la lectura es más rápida en el primer caso.

8.-Intenta ajustar el contenido marcándote como referencia unas trescientas palabras. Eso como una directriz básica. Si te sale algo muy tocho, corta en varios artículos.

9.-Ofrece información complementaria, da enlaces útiles, cita las fuentes en las que te basas y contextualiza lo mejor que puedas.

10.-Si también le tienes cariño al caracter SEO de tus contenidos, entonces usa en tu contenido alguna keyword de interés, pero sin abusar. Yo soy partidario de escribir para las personas, no para las arañas de google ;-).

¿Qué tal? Espero que el artículo haya sido breve, dinámico y sencillo. Un abrazo a todxs.

David.

[1]http://es.wikipedia.org/wiki/Augusto_Monterroso

[2]http://es.wikipedia.org/wiki/Marcel_Proust

[3]http://es.wikipedia.org/wiki/Jakob_Nielsen

Métricas útiles en twitter

mayo 6, 2011

En base al post anterior sobre análisis y detección de falsos positivos en twitter, y de cara a trabajar con métricas de cierta calidad, quiero escribir unas notas sobre algunos indicadores que pueden ser de utilidad para analizar la actividad en esta red social.

Algunas son simples y pueden obtenerse de forma directa, otras dependen de servicios externos con cálculos no publicados y las hay también que se obtienen manejando varias de los tipos anteriores.

Primero contextualizo: En ciertas etapas de un plan de trabajo orientado a estrategia digital/ marketing online, se hace fundamental el escuchar y observar.

Cuando tenemos solo un esbozo general de nuestro posible target y todavía es algo generado desde la visión estratégica, conviene analizar con el mayor detalle no solo los segmentos de nuestro futuro público objetivo, si no también todo lo concerniente a quien deseamos escuchar. ¿Cómo se comunican?, ¿qué dicen?, ¿qué topics manejan?, ¿qué información les interesa?.

Todo sea por discernir quienes y de que forma son verdaderos “stakeholders“[1] de nuestro proyecto.

Quisiera aclarar que a la visión puramente cuantitativa de las cosas es muy importante añadirle valoraciones cualitativas, y que las métricas tienen poco valor si no sabemos como interpretarlas, contextualizarlas bien, o simplemente adaptarlas según el caso a observar. Para no cansar demasiado, me quedo en conceptualizaciones y descripciones breves, próximamente escribiré sobre posibles valoraciones y uso ponderado de ellas.

Bueno, no divagaré más. Apunto y aclaro una serie de medidas y servicios útiles para sobrellevar todo este trabajo, que contra toda visión “cool” y de visibilidad, es más una recopilación de datos, rellenar muchas hojas de cálculo y preparar informes. En este post, métricas sobre la red social Twitter. Allá van.

1.-Número de followers

Número de seguidores del usuario. Es la cantidad de seguidores que el usuario tiene en su perfil de twitter. Todas las personas, entidades, y en definitiva cuentas que escuchan sus mensajes.

2.-Ratio de followers/followeados

Medida de la correlación entre seguidores y seguidos por el usuario. Una métrica cuantitativa expresada en un valor numérico de tipo real que representa el resultado de dividir el número de seguidores entre el número de seguidos.

3.-Índice de Retweets

Este es un índice que mide la propagación de tweets a través de otros usuarios. El retweet en si mismo, es la propagación a tu red de seguidores (primer nivel) de un tweet que viene de otro usuario seguido o no por ti (pueden hacerse retweets siguiendo un hashtag sin necesidad de seguir al autor).

El índice de retweets podríamos definirlo como un valor que asocia los retweets realizados por otros usuarios de un contenido propio o no (generado, transformado o distribuido por el usuario) dentro de un margen de tiempo.

4.-Índice de replies

Valorar el número de menciones en las conversaciones o mensajes público en @twitter. Conversar/ Reply/Mention : Para empezar una conversación/reply o referirse a alguien, tienes que escribir un twitt que contenga “@nombre”. Si ves el timeline de alguien, te darás cuenta de que hay muchos twitts que empiezan por @fulanito o @menganito. Esos twitts son parte de conversaciones. Es habitual contestar a alguien con un twitt que empiece por su nombre predecido de una @, aunque el @nombre puede estar en cualquier parte del Twitt.

5.-Índice de visitas a enlaces

Conteo de cuantos enlaces han sido pulsados y que cantidad de clicks se ha realizado.

Es importante conocer la cantidad de clicks realizados en nuestros enlaces. Por un lado para detectar el tráfico hacia otros sitios, por otro porque puede influir en el propio SEO del sitio particular del usuario y además, nos ayuda a conocer que tipo de contenidos son mas visitados por nuestros seguidores o por las redes de segundo o tercer nivel. Nos da información sobre la propagación y nos permite definir los contenidos de mayor interés para nuestro público objetivo.

6.-Índice de presencia en listas

Valorar la cantidad de listas en las que el usuario esta presente. Las listas son una de las funcionalidades más usadas en @twitter. Normalmente se pueden crear cuantas se quieran y tienen dos perfiles: públicas y privadas. Este valor es simplemente notificar en cuantas listas se encuentra presente el usuario. Su valor reside en que son fuentes de seguimiento “no oficial”, es decir, se puede seguir a un usuario sin seguirlo directamente (lo cual evita el conteo como follower) o bien se le puede seguir mediante su presencia en listas.

Además, ofrece un contexto cualitativo para obtener información sobre la reputación del usuario, en base a las listas creadas en base a una naturaleza temática.

7.-Índices de tweets favoriteados

La función de “favoritear” es importante en esta red. Añade un valor de registro a los mensajes a los que por distintas razones, queremos conservar disponibles y salvar de la quema de la corta caché de twitter. Sabremos mucho de los usuarios asomándonos al tipo de contenidos que suelen “favoritear”, pero sobretodo, nos interesa saber quien “favoritea” contenidos de los usuarios que estemos observando.[2]

8.-Índice Klout de influencia en Twitter

El índice klout maneja unas veinticinco variables y establece un cálculo con el que ofrece una valoración entre cero y cien para medir la influencia en twitter. Maneja conceptos muy interesantes como el alcance de tu red, la posibilidad de amplificación de los mensajes y las capacidades de la audiencia que te sigue. Sería interesante conocer las ecuaciones completas que maneja, pero al parecer ese debe ser su valor y permanece algo oculto. En cualquier caso y usándolo de forma conjunta a otras métricas, es un factor de interés a observar.[3][4][5]

9.-Índice de influencia absoluta

Una medida para identificar la influencia que genera cada mensaje frente a su audiencia. Basicamente, valora y entiende como bueno el hecho de aumentar seguidores con pocos mensajes. Viene a medir algo así como la popularidad. Bueno, ahí está. Para no usar de forma autónoma, sin duda.

10.-Influencia Relativa

Una medida para valorar la influencia de los mensajes enviados en un plazo de tiempo acotado, teniendo en cuenta la interacción que se genera entre los seguidores. Es decir, mide el impacto relativo de los tweets del usuario, en cuanto a replies y retuits que se generan en torno al mensaje. Asociado a la valoración de la capacidad de conversación, que es la clave de esta red.

11.-Índice de Broadcasting Reach and Influence

Es una medida nueva que que relaciona el número de seguidores y el promedio de seguidos por cada uno de ellos. En términos sencillos permite identificar la competencia de lectura. Se estima teniendo en cuenta el total de seguidores de los seguidores del usuario frente al número de seguidores del usuario.

12.-Índice de capital social

Promedio del tamaño de la red de los seguidores de primer orden (de los usuarios que siguen directamente). ¿cuantos seguidores tienen los seguidores?, esto viene a ser lo que podríamos llamar la red de segundo nivel.[6]

13.-Índice de compromiso

Es una medida para estimar el compromiso de la audiencia del usuario en cuanto a sus contenidos, mide la posibilidad de ser referenciado cada vez que se hace una entrada o Tweet. Se calcula teniendo el número de retweets en relación a los tweets.

14.-Valor de centralización

Valoración mezcla de cuantitativo y cualitativo. Representa de que forma se establece la red de seguidores. Juega entre los extremos de tener una red de pocos usuarios con mucha influencia o en una de muchos usuarios con poca influencia.

15.-Índice de velocidad

Número de tweets que el usuario envía al día (media de un plazo de tiempo acotado) con respecto al máximo de tweets que pueden lanzarse (mil). No quiere decir que exista calidad, valor o interés en los mensajes, pero existen varios estudios que asocian directamente un índice alto de velocidad con un aumento progresivo de seguidores.

+Info

[1]http://en.wikipedia.org/wiki/Stakeholder_(corporate)
[2]http://favstar.fm
[3]http://www.genbeta.com/web/klout-calculo-de-la-influencia-social-a-partir-de-twitter
[4]http://pulsosocial.com/2009/11/19/busca-los-influencers-en-twitter-con-klout
[5]http://klout.com
[6]http://export.ly
http://www.kaushik.net/avinash/2009/11/social-media-analytics-twitter-quantitative-qualitative-analysis.html
http://en.wikipedia.org/wiki/Twitter
¡Salud!

Cuidado con los falsos positivos

abril 12, 2011

En esto del trabajo en las redes, cuando se trata de medir y valorar hay que poner un poquito de atención. Si estás siguiendo tus KPI o simplemente estás estudiando posibles influenciadores para la proyección en las redes de un proyecto o producto, hay que ir con pies de plomo.

Se encuentra uno con cierto tipos de casos que conviene ubicar. Digamos que por ejemplo, si yo me pongo a seguir en twitter a veinte mil personas, apenas con algo de cortesía y una mezcla de followbacks y autofollows podrían seguirme al menos, unas cinco mil (solo un ejemplo, así, imaginando). Entonces yo paso por tu cuenta y veo y pienso “leñe este tio tiene cinco mil followers, debe tener capacidad de influenciación” -> FAIL.

Cada vez me impresionan menos las cifras de followers en twitter (creo que intentar impresionar con eso es de primero de twitter). Y lo digo totalmente en serio. Haciendo vida diaria en la red social te das cuenta de que eso realmente no tiene porque significar nada asociado de valor. De nada te sirven veinte mil seguidores, si cuando envías un enlace que está roto, nadie te lo dice. ¿sabemos el porqué? Porque nadie lo pulsa y mira el contenido.

Funcionan como “followers bobos” que solo se dedicarán a distribuir cualquier cosa que venga de ti, sin leerla, o analizarla, o criticarla debidamente. Nada.

¿y tus conversaciones en twitter? ¿tienes diez mil seguidores pero dialogas poco y además con los mismos? Oh, vaya eso es un poco raro…y si vas del rollo “2.0 ” y esas cosas, pues aquí algo pasa…

Súmese a lo anterior algunas prácticas un tanto…¿malintencionadas? ¿poco éticas? como por ejemplo, no hacer un RT directo, si no usar la forma “vía @usuario” que suele ir a final del tweet, en lugar del RT que va delante, para así figurar tú directamente junto al contenido, y que tus followers bobos te asocien a ti al contenido de forma inmediata. Tenemos poco a poco definido un verdadero caso de falso positivo a la hora de estimar sus capacidades a nivel de red (y no os podéis imaginar cuanta fauna deambula por twitter funcionando así 😉 )

¿qué hacemos? Pues hombre, lo ideal sería una suma de diversos análisis cuantitativos y cualitativos, que generen una visión lo más global y crítica posible sobre el objeto de estudio. Y del lado de las métricas, yo me planteo una serie de ellas que a diario y de manera combinada, no me suelen fallar mucho. Uso las siguientes, os haré una introducción:

  1. Número de followers
  2. Ratio de followers/followeados
  3. Índice de Retweets
  4. Índice de replies
  5. Índice de visitas a enlaces
  6. Índice de presencia en listas
  7. Índices de tweets favoriteados
  8. Índice Klout de influencia en Twitter
  9. Índice de influencia absoluta
  10. Índice de Influencia relativa
  11. Índice de Broadcasting Reach and Influence (BRAIN)
  12. Índice de capital social
  13. Índice de compromiso
  14. Valor de centralización
  15. Índice de velocidad

Y con todo ello, me preparo una tortilla bien ponderada por transcendencia parcial sobre el conjunto, que me sirve para obtener una visión más enfocada del sujeto/objeto de estudio.

Las describiré y las justificaré en próximos posts.

¡Un saludo a todos!

Yo te contaré que hacemos…

marzo 26, 2011

¿Hola? ¿Qué tal? , pues yo venía a contar hoy una pequeña reflexión al hilo de una conversación que hemos mantenido en Twitter entre @Nordic, @edinne y un servidor (@davidjguru).

Se generó al hilo de una idea sobre la cantidad de “expertos en Social Media” disponibles en la red social Twitter.

Tweet a tweet fueron apareciendo los elementos más básicos de las conversaciones en estos temas, aspectos recurrentes que suelen argumentarse siempre y expresiones muy oídas. También llegamos a conclusiones, como por ejemplo la necesidad de externalizar gestiones y servicios si estos no forman parte del core central de tu negocio. Esto es importante. La verdad es que la conversación fue bastante rica en ese sentido y no se salió de la delicadeza propia de quienes saben debatir dentro de estos canales.

Sin embargo a mi me gustaría pararme fuera del cuerpo de ideas útiles y de conclusiones de la conversación. Me gustaría detenerme en una expresión recurrente y repetitiva, algo manida bajo mi punto de vista y que podría caerse con un poco de esfuerzo.

¿Vendemos humo? ¿A que nos dedicamos?

Bueno, de verdad que será un placer el contaros a que nos dedicamos en el día a día, porque como mencioné en un tweet, ni @trasgu ni yo paramos de trabajar en la vida diaria, aquí en @emergya . Así que vamos a concretar.

La socialización en las redes pasa por procesos, al igual que en la vida real, no todos sabemos socializar, o hacerlo con la suficiente calidad en base al contexto donde debamos hacerlo.

Ahí entran en juego muchos factores: perfiles, actividad, conversación, branding, naming, y todos esas keywords de moda y muy 2.0. Pero no las voy a repasar todas, había dicho que iba a concretar.

Todo lo de socializar en las redes es solo una acción más dentro de algo más global que nosotros llamamos estrategia digital.

Preparamos planes de estrategia, definimos objetivos de alto nivel, trazamos tácticas y sus objetivos asociados e implementamos acciones concretas que ayuden a hacer avanzar la consecución de los objetivos.

Para empezar, realizamos un extenso análisis de necesidades.

Estudiamos la cultura de tu organización.

Realizamos propuestas adaptadas a las necesidades y fines observados.

Realizamos todo el plan de estrategia digital asociado a tus necesidades:

  • Naming
  • Branding
  • Estudio de tu target
  • Presencia en la red
  • Dinamización de tus contenidos
  • Formación en escritura para la web
  • Gestión de crisis de reputación
  • Desarrollo y mantenimiento de una comunidad online
  • Formación en como hacer un uso productivo de las redes sociales
  • Desarrollamos toda la capa tecnológica necesaria: plataformas, redes sociales, portales, blogs, etc.
  • Análisis SEO y SEM
  • Asesoramiento Social Media

Y además, controlamos todas las acciones mediante la definición de indicadores clave del desempeño (KPI en inglés) que estén preparados para recabar la información necesaria a las características del proyecto (no todos son iguales, ni tienen los mismos fines), básicamente para que pueda evaluarse la consecución de objetivos en el tiempo.

Bueno, todo esto (que es en si bastante sintético) es el esquema del tipo de tareas que solemos realizar en nuestra vida diaria. Todo aderezado por ingentes cantidades de documentación, de llamadas telefónicas, de correos electrónicos, de dimes y diretes, de pasos hacia adelante y otros tantos hacia atrás. Herramientas de análisis y seguimiento y sobretodo, mucha conversación para auscultar las necesidades de nuestros clientes.

¿Todavía te parece que vendemos humo?

Cuidado. Cada vez que acusas a un currante de este tipo de proyectos de vender humo, “dios mata a un gatito”

😉

¿Te ha llegado el mensaje? :-P

Proyectos de SocialMedia: el aspecto humano

febrero 21, 2011

Vemos que la expresión “Community manager” cada día está más en boga. Se suceden enlaces, tweets y post sobre este tema, pero en realidad, a los que trabajamos diariamente con ello, a veces nos falta algo menos de “dospuntocerismo” teórico y más bases prácticas basadas en la experiencia y el trabajo diario. Hoy quisiera publicar un esquema de trabajo que desarrollé en su momento para enfocar este trabajo de forma diaria.

 

En realidad, y al contrario de lo que solemos creer, pensamos que este tipo de trabajos se basa en “on”, pero hay mucho trabajo que hacer en modo “off “, de manera previa a la llegada a las redes sociales y su entorno, debemos realizar muchas tareas al margen de internet intentando conseguir una verdadera inmersión en el universo de nuestro cliente y el  “core” de su negocio.

En ese sentido va mi post de hoy, enfocado a ese trabajo relacional que tan bien encaja con las características de un buen “Community manager”.

 

En este tipo de proyectos, se hace fundamental el contar con responsables que tengan una serie de características.

 

En un proyecto de estrategia digital, es fundamental el comprender, interpretar y resolver las necesidades del cliente, tanto las explícitas (aquello que el cliente expresa facilmente y de forma clara), como las implícitas(aquello que el cliente no verbaliza, pero entendemos que está entre lineas o que forma parte del contexto del éxito del proyecto).

 

De cara a afrontar estas tareas con la mayor calidad posible, entonces recomendamos que sean asignadas a personas que al menos, contengan las siguientes características:

 

A nivel de comunicación:

 

Asertividad: En cuanto a estilo estratégico de comunicación, es muy importante. Consiste en una característica que nos hace comunicarnos de manera equilibrada, evitando las formas polares: por un lado la agresiva y por otro la pasiva.

Simplemente debemos buscar a la persona preparada y capaz de expresar sus ideas y convicciones de manera constructivas, escuchando activamente los otros puntos de vista, y sin necesidad, tanto de abandonarse a asumir las posturas contrarias que no comparta, ni a imponer su visión al resto.

Necesitamos esta cualidad para relacionarnos con el entorno, conducir el proyecto, y tener un canal de comunicación muy maduro con los clientes. Vamos a usar mucha comunicación, vamos a requerir muchas iteraciones sobre las ideas para ir modelando. Necesitamos obtener una satisfacción clara y explícita por parte del cliente.

 

Empatía: Entendida como la capacidad de comprender lo que nuestro interlocutor o nuestro entorno percibe y siente. Esta cualidad o valor es fundamental. Durante el desarrollo de nuestro proyecto necesitamos comprender de la manera más profunda posible una serie de factores de mucha importancia.

En concreto, queremos comprender la cultura interna del entorno del cliente, sus necesidades, las aspiraciones que maneja en torno al proyecto, las limitaciones que posee, y de todo ello tenemos que ser capaces de nutrirnos. Solo así podremos ir dos pasos por delante e ir ofreciendo soluciones a sus necesidades mucho antes que él mismo las plantee o las haya llegado a identificar.

 

Escucha activa: Debemos ser capaces de entender y comprender el mensaje desde el punto de vista del emisor, es decir, debemos estár atento en las conversaciones a los mensajes que se nos transmiten por encima de los que tenemos necesidad de emitir nosotros.

En este sentido, durante estos proyectos, no es más importante el hablar, si no el escuchar. Tenemos que sacar muchas lecturas para poder interpretar correctamente a nuestro cliente, y debemos poner todos nuestros sentidos en ello.

 

Observación: Tenemos que ser capaces de mirar, retener e interpretar todo aquello que escape del espacio del lenguaje verbal. Atendido a lo corporal, a lo físico y a lo conductual, podemos extraer muchas y muy ricas lecturas de la zona implícita del discurso del cliente.

Necesitamos establecer la relación entre lo que se dice y una serie de aspectos como:

  • Contacto visual
  • Gestos faciales (expresión de la cara)
  • Movimientos de brazos y manos
  • Postura y distancia corporal

 

Así podremos afinar mucho mejor a la hora de enfoncar nuestras propuestas y saber comprender con más calidad sus propias necesidades.

 

Definición e implicaciones de una estrategia digital

febrero 20, 2011

Definición

 

En si mismo, el concepto de estrategia denota un esquema de trabajo a implementar por una organización para alcanzar la consecución de los objetivos asociados a planes estratégicos.

 

La estrategia se ocupa del planeamiento y dirección de las campañas, así como del movimiento y disposición estratégica de las recursos a utilizar en el proceso.

 

Como cualquier forma de expresión en torno al concepto “Estrategia”,  podemos decir que la expresión “Estrategia digital” referencia a un conjunto de acciones encaminadas a conseguir un objetivo final, en este caso a través de los medios digitales, las nuevas tecnologías de la información, y usandolos como medios para conseguir dichos fines.

 

En un binomio fines-medios, la estrategia haría referencia a los planes de actuación para alcanzar esos fines, mientras que los objetivos son las metas a conseguir, todo en un contexto donde abundan los canales digitales.

 

Implicaciones


Al margen de todas las fórmulas repetidas y abstractas que solemos encontrar en la información disponible sobre estrategia digital, podemos concretar que una correcta asunción de una estrategia debe implicar, como mínimo(y por supuesto,  siendo modelados al tipo de proyecto y cliente), los siguientes aspectos:

 

  • Tener objetivos de negocio para tu actividad en medios digitales: hacer preguntar, atender a las personas, hablar de ventas, satisfacción del cliente, reducción de costes

 

  • Ser capaz de definir y poner en marcha iniciativas orientadas a la consecución de esos objetivos

 

  • Saber cómo medir los resultados: los clicks y páginas vistas no nos dicen ya casi nada

 

  • Retroalimentar la estrategia con los resultados obtenidos. Analizar periódicamente los resultados para extraer de ese análisis nuevos planes de acción. Quedarse en si tenemos más o menos tráfico es muy pobre. ¿Cómo potenciamos aquello que más aporta al negocio? ¿Como cambiamos lo que no funciona? ¿Dónde hay oportunidades y cuáles son las amenazas?

 

  • No tener miedo a equivocarse: el secreto del éxito está en medir, aprender y construir sobre lo aprendido. Experimentar en Internet es muy fácil, pero no todos se atreven.

 

  • Pensar en la comunicación de manera honesta: Preguntar, responder, debatir. No pensar en las personas como clientes, no actuar con una perspectiva de persuasión. Tener la capacidad de conversar asertivamente,  comprendiendo las necesidades del otro.

 

Malraux y los museos líquidos

noviembre 30, 2010

Un crucifijo románico no era originalmente una escultura,

la Madonna de Cimabue no era un cuadro,

tampoco la Palas Atenea de Fidias era una estatua.

 

André Malraux, el museo imaginario.

 

Hace poco pasé por una obra del legendario André Malraux que tenía pendiente de lectura: “El museo imaginario”. Después de pasar por “La condición humana” (la más importante para mi de toda su trilogía oriental) y por sus “Antimemorias”, llegó el turno de esta otra obra que me había sido siempre muy recomendada.

 

Fue Malraux un personaje increíble: arqueólogo, aventurero, brigadista internacional, piloto, escritor, revolucionario, ministro de cultura francés, un verdadero hombre de acción, que sin embargo, siempre mantuvo una estrecha relación con el arte.

 

Defendía en el museo imaginario que en realidad, cualquier museo físico aisla y separa la obra de su contexto y su cultura. Se obtiene la visión directa sobre el objeto de observación, pero se desacopla de un entorno igualmente rico y fuerte. Sería entonces una visión parcial, cortada del lugar primigenio donde fue creada, donde todavía no era una escultura, o una pintura.

 

Propone de varias formas que cada cual tenga en su disposición el configurar su propio museo, reuna su propia colección artística y la desplace donde le plazca: una especie de visión líquida sobre los entornos físicos que hace ya más de sesenta años dejó entrever para nosotros, que ahora vivimos en la época, sociedad, y en el arte más líquido que nunca se han conocido.

 

Plantea un museo alimentado por la técnica fotográfica donde cada cual organice su arte. No es trivial. Por ejemplo, en el Vaticano en 1980 se expuso la imagen fotográfica de una enorme pintura de Rafael. Era una reproducción fotográfica a escala 1:1. El sueño de Malraux se cumplía, la obra y su reproducción fotográfica alcanzaban una integración, y participaba de la sustitución de una sobre la otra. Y era coherente. Y llegaba al público. Y fue satisfactoria. En nuestra época, la red permite eso y mucho más.

 

Se crean nuevos espacios en la red, nuevas galerías virtuales, nuevas comunidades de creadores donde no existe espacio físico para ello.  Pensaba en todo ello cuando me llegó el contenido de los amigos de @ouieacrea, que presentaban un proyecto conceptualmente parecido al de Malraux: La caja abierta.

 

Un proyecto de espacio metafísico que contendrá diversas formas de expresión y contenidos.

Actualmente están participando de un concurso de apoyo a proyectos. Anoto el enlace. Vale la pena verlo:

 

http://regala.flowersinspace.com/projects/22

 

Orientación laboral en tiempos grises

octubre 22, 2010

Corren tiempos duros para los profesionales de la informática. Pero todavía más para los que están por llegar. Para las personas que han luchado durante varios años de forma constante por una formación que les pueda hacer alcanzar un empleo con cierta calidad.

El tejido empresarial se resiente, la calidad del empleo disminuye. Las contrataciones bajan o empeoran las condiciones de los contratos. E igual pasa con las becas, que son el primer escalón de esta dificil y dura escalera. No son tiempos fáciles, no.

Resultaría cómico, de no resultar tan triste, asistir a ponencias de las principales empresas del sector. Oír el mensaje que dan, a veces explícito y otras implícito. Ver como a un auditorio de personas que desean dar una salida profesional a tantos años de esfuerzo, se le dice, de alguna forma u otra, que la mejor opción en estos tiempos puede ser emprender. Que el mercado no podrá absorbernos a todos.  Claro, tampoco se dice que los bancos tampoco pueden  prestarnos a todos el capital necesario para emprender, pero eso es otra historia.

En realidad no era mi intención analizar todo esto en este post. Para ello, por ejemplo, ya el amigo Julio (@julitroll) plasmó su reflexión sobre la ceremonia de graduación que le tocó vivir:  http://julitros.wordpress.com/2010/10/17/reflexiones-sobre-una-ceremonia-de-graduacion

Quiero contextualizar, porque dentro de poco vamos a estar presente en unas jornadas de orientación laboral. Será en la ETSII de Sevilla el Jueves 28 de Octubre, de 12.00 a 14.00, y vamos a organizar una ponencia que esperamos que tenga un regusto distinto a lo que estamos viendo últimamente.

Queremos transmitir otras opciones, otras formas de entender el desarrollo de software, y en definitiva otro camino profesional. Queremos hacer llegar a los futuros profesionales cuales son las vías que se abren en torno a una carrera profesional enfocada al software libre, que perfiles se requieren, como (en el caso del software libre) es posible irse adecuando a estos perfiles por cuenta propia, que opciones existen, que se busca y que se ofrece a cambio.

Tal vez, en este estado de las cosas, podamos aportar un poco de luz en el panorama gris que estamos pintando a los futuros profesionales.

¿Qué más?, pues el esquema de lo que vamos a hacer, es sencillo y a la vez, complejo:

1.-Ofrecer el punto de vista del entorno laboral en las empresas con modelos de negocio basados en el software libre .
2.-Transmitir el perfil idoneo para las ofertas de empleo en  empresas orientadas hacia el software libre.
3.-Dar a conocer las habilidades y herramientas para conseguir adecuar el perfil .
4.-Hablaremos del caso de Emergya como consultora tecnológica enfocada al software libre.
5.-Informar de manera introductoria sobre herramientas basadas en software libre para la gestión de empresas (enfoque para emprendedores).

Hablaremos sobre aptitudes y actitudes, sobre el modelo de negocio en torno al software libre, del estado del arte de este en nuestro país, del futuro, y sobretodo, y para completar nuestra exposición, el caso real de una consultora tecnológica orientada al software libre y la viabilidad de su proyecto de negocio.

Y lo cierto es que afrontamos con mucha ilusión. No será una conferencia o una ponencia al uso. Nos hemos basado en el análisis de las cosas que no nos gustan a nosotros cuando somos publico asistente, de como sería la ponencia que nos hubiera gustado escuchar y vivir. Vamos a poner energía, vamos a intentar llegar a todo el mundo, con un mensaje claro de que quedan opciones y pueden alcanzarse.

Así que si os interesa, el día 28 de Octubre de 2010, el compañero y amigo Christian Espínola  (@penyaskito)  y un servidor (@davidjguru), estaremos explicando nuevas posibilidades para futuros profesionales.

Aquí teneis disponible la inscripción a las jornadas:

http://etsii.stagehq.com/events/449

Un saludo a todos, nos veremos por allí.

David.

Notas sobre virtualización

septiembre 6, 2010

Un poco de intro al tema de la virtualización.

¿Que es la virtualización?

Basicamente consiste en introducir una capa de abstracción entre el hardware de una máquina y su sistema operativo.

¿Para qué?

Por lo visto, según se lee por ahí, en realidad las máquinas que están funcionando por el mundo no aprovechan todas las capacidades hardware que tienen. El análisis de carga en muchos servidores ofrecen cifras bajas de aprovechamiento de las capacidades, y la virtualización puede encargarse de mejorar esto.

Además, existe la opción de que en una migración a software libre, se decidan mantener aplicaciones que no pueden ejecutarse desde un sistema Linux. Entonces virtualizar puede ser una buena opción para crear contenedores de aplicaciones que necesitemos.

¿Cómo lo afronta?

Esa capa de abstracción de la que hablamos antes y que en realidad es una capa software, pasa a gestionar los cuatro recursos básicos de cualquier máquina: CPU, RAM, disco duro y la gestión de red.

Reparte, distribuye y gestiona, bien de forma dinámica o bien mediante configuración previa, las capacidades hardware entre distinas máquinas virtuales instaladas en la máquina real y física.

Así, se consigue más rendimiento y una correcta optimización del uso de las capacidades.

Concepto: Máquina virtual

Es el software capaz de emular el funcionamiento de un ordenador sobre un sistema operativo ya instalado. Tiene asignados una serie de recursos, como por ejemplo, una cantidad de memoria RAM de la máquina física, y se limita a usar los recursos asignados, de forma que funciona independientemente dentro de las capacidades que tenga y los recursos que se le hayan asignado.

Esta máquina virtual tendrá la posibilidad de funcionar como una máquina física, con su propia BIOS, su arranque y los dispositivos que se le quieran incorporar.

Las más usadas suelen ser las máquinas virtuales de sistemas, enfocadas a ejecutar sistemas operativos completos (Vmware, Xen, VirtualBox, etc.) y las máquinas virtuales de procesos o de aplicaciones, enfocadas a la ejecución de aplicaciones (CLR, JVM, Zend, etc).

Virtualización por Hardware:

Consiste en primer lugar, en incorporar una serie de extensiones a la arquitectura del procesador para manejar instrucciones orientadas a facilitar las tareas de virtualización de software. En la gestión de los procesos del microprocesador, se incorpora ahora un nuevo nivel de ejecución para separar operaciones de virtualización del resto de instrucciones a ejecutar.

Cada gran compañía implementó sus sistemas de gestión de virtualización en sus procesadores. Por un lado, Intel con su tecnología VT→ ftp://download.intel.com/technology/itj/2006/v10i3/v10-i3-art01.pdf y por otro lado AMD con SVM→ http://developer.amd.com/assets/Virtualization%20for%20PDC%2008.pdf

¿Como saber si tu microprocesador soporta virtualización por Hardware?

Bueno, como parto del supuesto de que eres alguien honesto, con principios, con valores positivos y buena persona, entonces entiendo que usas Linux en cualquiera de sus variantes.

En mi caso, desde una Ubuntu Lucid Lynx, se puede lanzar el siguiente comando para ver que plan hay:

egrep ‘(vmx|svm)’ /proc/cpuinfo, bueno mejor egrep –color ‘(vmx|svm)’ /proc/cpuinfo por si aparecen muchos flags, poder diferenciar mejor el que buscamos.

Donde vmx es por si el procesador es Intel y svm si el procesador es AMD. Este comando devolverá una lista de flags, en varios módulos, en base al número de nucleos que tenga el procesador. Por ejemplo:

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm

Y la apariencia del flag indica que si, que hay soporte habilitado para la virtualización.

También es consultable desde la Bios del sistema la posibilidad de habilitarla o no, en el caso de que exista.

Opciones de software de virtualización

Opciones:

Software de virtualización Open Source

QEmu [1][2][3] para Windows, Solaris, Linux, FreeBSD, NetBSD, OpenBSD, Mac OS X, ZETA, BeOS

VirtualBox [4][5] Windows, Linux, Mac OS X

XEN [6][7][8] para Linux, Unix-like, BSD, OpenSolaris

OpenVZ [9][10] para Linux

KVM [11][12] para Linux

Software de virtualización gratuíto

VMWare Server para Windows y Linux

VMWare Player para Windows

Microsoft Virtual Server 2005 para Windows

Software de virtualización de pago:

Parallels Desktop para Mac OS X

Parallels Workstation para Windows y Linux

VMWare Fusion para Mac OS X

VMware Workstation para Windows y Linux

[1] http://en.wikipedia.org/wiki/QEMU

[2 ] http://es.wikipedia.org/wiki/QEMU_manager

[3] http://wiki.qemu.org

[4] http://en.wikipedia.org/wiki/VirtualBox

[5] http://www.virtualbox.org/

[6] http://en.wikipedia.org/wiki/Xen

[7] http://blog.xen.org/

[8] http://www.xen.org

[9] http://en.wikipedia.org/wiki/OpenVZ

[10] http://wiki.openvz.org/Main_Page

[11] http://www.linux-kvm.org

[12] http://es.wikipedia.org/wiki/Kernel-based_Virtual_Machine

La parte Non-Heap de la memoria en Java

julio 18, 2010

En concreto, me gustaría detenerme en el lado “no controlable” de la memoria de Java. Me refiero al definido como el espacio PermGen (Non-Heap). Este espacio, como marias comentaba en el post anterior, esta dedicado a cargar dinamicamente muchas clases diferentes. Pero detengámonos ahora en ello.

¿Que quiere decir la carga dinámica de clases?

En Java, existe la capacidad para que las aplicaciones cargen sus propias clases necesarias para su funcionamiento, es el llamado classLoader, una clase dedicada a la carga dinámica de clases Java (ojo, solo clases, ya que sus instancias se almacenan en la parte Heap de la memoria 😉 ).

Cuando, por ejemplo, una aplicación que está en despliegue se elimina, entonces su classLoader se elimina también, junto a todas las clases que ha manejado, y pasan a estar disponibles para el recolector de basura. Para recordar, diremos que el recolector de basura se encarga de retirar las clases que no esten referenciadas por ninguna otra clase. Para que se pueda eliminar la memoria ocupada por una clase en el espacio PermGen, es necesario además que se elimine el classloader la cargó.

¿Que plan?

Bueno el espacio asignado a esta parte de la memoria es fijo, no se realiza ningún cambio en cuanto a la asignación de tamaño mientras que la máquina virtual se este ejecutando. En concreto es de 64Mb para la jvm de Sun. Podemos modificar el tamaño de esta región con un parámetro de línea de comandos: -XX:MaxPermSize=XXXm. Podemos asignar por ejemplo, XX:MaxPermSize=128m para el tamaño máximo y XX:PermSize=128m para que la máquina virtual ya arranque con este tamaño y no tenga que reservar más espacio en tiempo de ejecución.

Pero eso no nos asegura que no estemos exentos de problemas.

Por ejemplo, tomemos un trozo de código absurdo como este:

public void creaObjetosSinFin() {
for (;;) {
List c = new ArrayList();
}
}

Por una parte, el método no deja de crear objetos indefinidamente, pero en realidad no genera ningún problema, no hay saturación del uso de la memoria. Si en ninguna otra parte del programa se intenta acceder a ellos, entonces el recolector de basura los interpreta como “inalcanzables” y deja de mantenerlos en memoria.

La movida para nosotros empieza cuando se hace referencia a objetos de nuestra aplicación desde fuera de esta. O cuando el classloader antiguo no se elimina correctamente.
Se produce entonces  lo que se llama una fuga de memoria (memory leak) y normalmente suele dar la famosa  java.lang.OutOfMemoryError: PermGen space failure. Lo que solemos hacer es reinstalar (quiero decir resdesplegarla en el directorio correspondiente) la aplicación, y el resultado es que tendremos las clases de la aplicación cargadas dos veces en memoria.

Es cuestión del número de recargas y de la memoria gastada por la aplicación el que se produzca la excepción  anterior. En este caso no basta con aumentar el tamaño máximo de la memoria, ya que esto sólo retrasaría el problema a unas cuantas reinstalaciones más.

Pero hay que diferenciar: aumentar la memoria será suficiente cuando el problema viene determinado por el despliegue de una aplicación que maneja gran cantidad de librerias (por ejemplo aplicaciones web con uso de librerías Spring e Hibernate). En otro caso de acumulación de classLoader, por ejemplo se plantean varias soluciones. Por un lado:

Se puede intentar que el garbage collector recicle la memoria PermGen. Para ello podemos activar el recolector de forma concurrente con los siguientes parámetros:

-XX:+UseConcMarkSweepGC
-XX:+CMSPermGenSweepingEnabled
-XX:+CMSClassUnloadingEnabled

Otra opción es investigar las posibles causas de la “fuga de memoria”, por ejemplo, localizando las referencias existentes a las clases que queremos eliminar.

Unos enlaces útiles:

Sun Virtual Machine Garbage Collection Tuning
Plugging memory leaks with weak references
Plugging memory leaks with soft references

Llega la !barraLibreCamp

junio 8, 2010
Notbarralibre_logo
Nos veremos en Granada:

Este jueves, día diez de junio de 2010. Nos veremos en Granada, en un evento openSource.
El evento en cuestión es una barcamp, que lleva por título “notarralibrecamp”. Este título hace referencia a la importancia de considerar el software libre no como una bebida que se ofrece gratis, si no como algo que esta realmente abierto y es libre de verdad.
Para un evento:

!notbarralibrecamp. De ahí deviene el juego de representarlo como !notbarralibre, ya que el símbolo -!- viene a ser una negación de lo que se indique detrás de el.
Iremos con los amigos delawen, mawi, fario, jojeda desde Sevilla y alguno más que posiblemente se deje caer por ahí…
Será un evento en el que los asistentes son participantes y son ponentes, al estilo de las desconferencias (ver nuestra querida #xdp). Se organizan sobre la marcha,en el terreno, de forma que el grupo decide que contenidos quiere recibir y se va organizando dinamicamente para ello.
Se parte de una pequeña organización esquemática como referencia y a partir el proceso se va modelando.
Para un enfoque:

El enfoque para este evento es el software libre: enseñanza, difusión, aplicaciones, metodologías, tecnologías, etc. En concreto hay registradas propuestas de compartir conocimiento sobre NoSQL, seguridad bluetooth, scrum, sistemas de información geográfica, Arch Linux y muchos más.
Con los objetivos de:

Así que aprovecharemos para desvirtualizar a muchas personas del entorno openSource, comer juntos, beber juntos, charlar, pasarlo bien y aprender mucho, todo lo que podamos, con verdaderas ganas de compartir y sobretodo escuchar.
Como objetivo añadido, algun@s queremos observar, medir y valorar la vivencia. Queremos preparar eventos de este tipo y particularmente nos interesa vivenciar todo el desarrollo.
Las pautas:

Por si te interesa el evento, aqui está la información. Inscríbete. Asiste. Participa. Y por supuesto, cumple las normas de una barcamp:
La primera regla del Barcamp es “Todo el mundo habla del Barcamp”.
La segunda regla del Barcamp es “Todo el Mundo postea y twittea, y facebookea…del barcamp”.
La tercera regla del Barcamp es “Si vas a presentar algo, pon tu nombre y el tema del que hablarás en el tablón de anuncios”.
La cuarta regla del Barcamp es “Introducciones de tres palabras”.
La quinta regla del Barcamp es “Tantas presentaciones a la vez como las instalaciones permitan”.
La sexta regla del Barcamp es “No hay presentaciones preprogramadas, no hay turistas”.
La séptima regla del Barcamp es “Una presentración durará el tiempo que necesite, o hasta que comience la siguiente en el tablón”.
La octava regla del Barcamp es “Si es tu primer Barcamp, DEBES presentar algo “.
Aqui un poco mas de información sobre el evento:


Calendario hispano de eventos abiertos (la fecha de la camp es la original que luego cambiamos 😉 )
http://libroblanco.com/calendario/calendar.php

Sistemas de control de versiones-IX: Workflow básico de svn

junio 2, 2010

//Prepara tu sistema
david@maquinon: ~$ sudo apt-get install subversion
david@maquinon: ~$ sudo mkdir /var/svn/
//Crea un proyecto de trabajo
david@maquinon:~$ sudo svnadmin create /var/svn/test

//Da permisos de trabajo
david@maquinon: ~$ sudo chown -R david: /var/svn/
//Mediante checkout, obten tu copia de trabajo
david@maquinon: ~$ svn checkout file:///var/svn/test

//Crea la estructura de trabajo recomendada
david@maquinon: ~$ cd test/
david@maquinon: ~/test$ mkdir trunk tags branches

//Añadirla al repositorio
david@maquinon: ~/test$ svn add trunk tags branches
//Realizar el commit de estos cambios
david@maquinon: ~/test$ svn commit -m ”Se ha creado la estructura básica”
//Genera un fichero de prueba en la copia local
david@maquinon: ~/test$ cd trunk
david@maquinon: ~/test/trunk$ vim fichero_prueba.txt

//Se añade el nuevo fichero a la copia local de trabajo
david@maquinon: ~/test/trunk$ svn add fichero_prueba.txt
//Se sube el cambio al repositorio
david@maquinon: ~/test/trunk$ svn commit -m “Subida del fichero de prueba”
//Obten la última version del proyecto
david@maquinon: ~/test/trunk$ svn up

//Obten la información de la evolución del proyecto
david@maquinon: ~/test/trunk$ svn log

//Comprueba los cambios entre dos revisiones
david@maquinon: ~/test/trunk$ svn diff -r 12:1234

//Unifica logs en un mismo archivo
david@maquinon: ~/test/trunk$ svn log -r 14 > mylog
david@maquinon: ~/test/trunk$ svn log -r 17 >> mylog
david@maquinon: ~/test/trunk$ svn log -r 19 >> mylog

//Comprueba el contenido de los logs
david@maquinon: ~/test/trunk$ cat mylog

//Haz un clean del repositorio
david@maquinon: ~/test/trunk$ svn cleanup /test/

Sistemas de control de versiones-VIII: Expresiones diarias con svn

junio 1, 2010

En este post quisiera ordenar algunas de las operaciones básicas que necesitamos conocer para un trabajo diario con svn. En concreto aquellos subcomandos (el comando propiamente dicho seguirá siendo svn) que forman parte de la cultura de trabajo con este VCS.

Con humor, ante todo.

“Haz un checkout del proyecto” -> Prepárate una copia local del directorio del proyecto. Descárgate desde el repositorio los contenidos con los que vas a trabajar hasta tu propio equipo.

Subcomandos: svn checkout URL,  svn co URL

Ejemplo: svn co file:///var/svn/myproject

Nota: Se puede hacer checkout de varios directorios y emplazarlos en distintos repositorios o bien en el mismo.

svn co URL URL PATH

“Hazte un update del proyecto” -> Actualiza tu copia de trabajo, es decir, actualiza el código del proyecto sobre el que estás trabajando y que tienes en tu poder. Haz tuyas las ultimas modificaciones que se hayan subido al repositorio.

Subcomandos: svn update,  svn up

Ejemplo: svn update nombre_de_fichero, svn up directorio

Nota: Se puede realizar una petición de una actualización a una revisión concreta, aunque sea antigua. Se puede hacer, por ejemplo, solicitar la revisión 30 (una revisión pasada del proyecto). Mediante el parámetro -r:

svn update -r30.

“Haz cambios al proyecto. Crea  un directorio. Añade un directorio. Borra un directorio. Mueve un directorio” -> Operaciones mas usuales en el día a día con el trabajo de un proyecto bajo svn. Añadir, borrar, mover, copiar. Forman parte de las operaciones más básicas.

Subcomandos:

1.-Crea un directorio: mkdir dir1

2.-Comprueba si el directorio está bajo el control de versiones: svn status PATH, svn stat PATH,  svn st PATH

3.-Pon el directorio bajo el control de versiones: svn add dir1

4.-Haz una copia de esta revisión: svn cp trunk dir1

5.-Borra ficheros en local y en el repositorio: svn delete myfile (luego en el commit del cambio, se borrará en el repositorio). svn delete -m”Borra tu fichero” repo/trunk/yourfile. Este último requiere parámetro -m con mensaje de log porque es inmediato y una vez solicitado funciona como un commit.

6.-Mueve directorios. svn move ruta/origen ruta/destino,  pero en realidad la operación consiste en cp + delete. Además svn no soporta mv entre copias locales de trabajo y repositorios URL. Así que sería mv + commit.

“Comitea tus cambios” -> Actualiza la copia existente en el repositorio con los cambios realizados en tu copia local. AKA “Sube tus cambios”.

Subcomandos: svn comit PATH svn ci PATH

Ejemplo: svn commit repo/trunk/myFile -m”Mensaje de log para la subida del cambio en este fichero” svn ci -m “Subida de cambios en el directorio local”

Nota: El mensaje de log es obligatorio para enriquecer el sistema de log de nuestro repositorio y manejar información contextual sobre que se hizo en que momento. Si no se añade, se abrirá un editor de texto (modo consola) o bien una ventana de escritura (modo de algún cliente gráfico o plugin de Eclipse) para anotar el mensaje necesario de la operación commit solicitada.

Sobre Hackers

mayo 31, 2010

You don’t do anything in life unless it’s for happiness…That’s my theorem of life… A simple formula, really: H = F³. Happiness equals food, fun, and friends.”  Woz[1].

Hoy me apetece reflexionar sobre conceptos Hackers[2 ]. Hace unos días el amigo y compañero Juanje me pasó varios enlaces sobre esta temática y revisité algunos textos que había leido hacía ya unos años. Asi que se me acumularon varias ideas, y me puse a escribir este post 😉 . Voy  a hacerlo en castellano. Me hastía escribir en inglés si no se trata especificamente de tecnología (y normalmente me parecen ridículos los castellanos hablantes que usan el inglés mas de lo apropiado). La única licencia que le concedo al idioma de la pérfida Albión será el de la cita del gran Woz que abre el post.

Crecimos con aquellas películas que hacían ver que el Hacker era una persona con capacidades para introducirse en un sistema y manipularlo. Crecimos con “Juegos de guerra” [3] o con “Tron” [4], por citar las más míticas, pero hubo muchas más que mostraban mentiras, engaños a usuarios para robar contraseñas y otros tipos de conducta negativa. Vimos como la prensa nos ofrecía modelos de conductas que consistían en que personas con un alto conocimiento tecnológico, se introducían en sistemas informáticos de grandes entidades y los dañaban. Falsificaban datos. Dañaban seguridades. Iban a la cárcel.

Casi todos, modelos equivocados.

En realidad, me da apuro manejar el término Hacker.  Yo desde luego no lo soy, pero además siempre me ha parecido muy rimbombante. Para mi, en mi experiencia, solo cabe hablar de hambre y sed de conocimiento, combinado con una convicción personal de compartir lo que se sabe, conectarlo con los demás, hacerlo trascender de uno mismo.

Por un lado siempre lo he interpretado como la humildad de saber lo que se es y lo que no se es,  no fingir,  no engañar,  mostrar lo que -no- se tiene, la capacidad de manifestarlo tal cual y el caminar a desarrollar más y más las capacidades propias. Esto es para mi la esencia. Un día la vi clara en este hayku:

“Para seguir el camino,

observa al maestro.

Sigue al maestro.

Camina junto al maestro.

Tienes que ver a través del maestro.

Y conviértete en maestro.”

Este mensaje me dio mucha mas claridad que la lectura de muchas obras y guiones. Tras él llegaron los manifiestos, las catedrales contra los bazares [5]  😉 y otras obras.

Es un camino, una cierta apuesta personal. No es mucho lo que se, pero lo ofreceré a tod@s, y  mientras me voy enriqueciendo y aprendiendo por el camino. Otras personas con un conocimiento infinito y muy profundo dejan que se marchite dentro. No lo imparten, no lo transmiten. Por convencimiento, por motivación o por incapacidad lo que saben solo en ellos queda. La cuestión es tomar el camino opuesto. Buscar lo contrario. Favorecer la libertad, compartir el conocimiento.

Asumir que llegará el momento en que nos veremos reducidos a un espíritu que estará contenido en un cuerpo. Y apostar por compartir.

Desconfiar de la autoridad. No de la autoridad nacida de la experiencia, de la sabiduría, de largas prácticas. No es la autoridad que se impone por sentido común ante un grupo por condiciones naturales de entrega personal. No es la autoridad ácrata que opina en base a la experiencia. No. Es la autoridad que se impone, que grita, que falta al respeto, que impide el silencio, que se arroga conocimiento y experiencia que no tiene. La de los malos modos que quiere evitar quedar en evidencia. La autoridad que se apura cuando teme que se conozca su ineptitud.

La autoridad que se sigue por coerción y no por verdadero respeto, esa es a la que hay que combatir.

Y a nuestra disposición, muchas herramientas: la blogosfera,  las redes, las listas de correos, los micro-bloggings, los eventos, los encuentros, y muchas más opciones. Para seguir adelante y crecer. Y de ese crecimiento generar un fruto por encima de generar un éxito.

Ese he decidido que será mi camino.

Un saludo a tod@s.

[1]http://es.wikipedia.org/wiki/Stephen_Wozniak

[2]http://es.wikipedia.org/wiki/Hacker

[3]http://www.imdb.com/title/tt0086567/

[4]http://www.imdb.com/title/tt0084827/

[5]http://biblioweb.sindominio.net/telematica/catedral.html

REM, Wine y Winetricks

mayo 25, 2010
/*
*
*@Intro
*/

Por un lado, REM es una herramienta para la gestión de requisitos y el modelado de estos en procesos de ingeniería de proyectos software, relacionando datos diversos como objetivos, actores, requisitos informativos y funcionales, también crea las matrices de trazabilidad necesarias y permite generar un documento único de análisis del sistema y editarlo.

Es una herramienta sencilla, gratuita y distribuida por la universidad de Sevilla desde el departamento LSI de la ETSII y creada por uno de los profesores del departamento: http://www.lsi.us.es/descargas/descarga_programas.php?id=3 y el único “requisito” es rellenar previamente un pequeño formulario web. Bueno y si vas a darle un uso no académico, mandar un correo al profesor para consultarle.

Por otro lado, Wine es una implentación libre de APIS Win para sistemas Unix, lo que quiere decir que permite cargar programas para varias versiones de Windows.
/*
*
*@¿Para qué?
*/
Yo había usado REM en mi proyecto fin de carrera hace unos años, y de repente ante un caso de modelado de requisitos se me ocurrió volver a usarlo. Sigue tal cual, en la misma versión 1.2.2 (me han chivado que esta previsto actualizarla no dentro de mucho) y con las mismas features. Me sirve así, no necesito ahora mismo nada más. Es un fichero pequeño, apenas un mega y medio, pero la cuestión es que está disponible para Windows (desde el 95 a XP), con lo que hay que plantear alguna solución.
¿Tirar de máquina virtual? -> No es para tanto, y me cansa demasiado…
¿Wine? -> ¡Si!. Un momento. Si no lo tienes,  mira primero la página del proyecto aqui y para instalarlo, simplemente haz:
$ sudo apt-get install wine
en la consola (en sístemas Debian based 😉 )

/*

*

*@¿Que plan?

*/

Le preparo un directorio ad-hoc:
$ mkdir rem_1.2.2 $
$ cd rem_1.2.2 $

y lo paso allí, lo descomprimo y lo lanzo, tirando del Wine que tengo en mi máquina (1.0.1):
$ unzip ~/REM_1_2_2.zip
$ wine SETUP.EXE

y todo debería ir bien, peeeeero…


/*
*
*@Instalando REM en Linux
*/

Al arrancar la instalación, aparece una ventana de error que dice que me faltan librerías para JET 4.0, el motor de bases de datos de M$, vaya plan…

Así que he encontrado una aplicación llamada winetricks que puede resolver estas cosas  🙂
Winetricks sirve para automatizar la instalación de las librerías necesarias. Es sencillo, simplemente tirar de wget para la descarga:

$ wget http://www.kegel.com/wine/winetricks

Permisos de ejecución y ejecutar:
$ chmod +x ./winetricks
$ sh winetricks jet40
$ wine SETUP.EXE

y así se resuelve el tema del JET 4.0 a la hora de lanzar la instalación de REM.
De todas formas es probable que tras esta instalación, surgan mas problemas porque se necesiten otras librerias. En concreto me siguió dando este error:

err:module:import_dll Library MFC42.DLL (which is needed by L”Z:\\home\\user\\.wine\\drive_c\\Archivos de programa\\REM 1.2.2\\bin\\REM_1_2_2.exe”) not found

err:module:import_dll Library MSVCP60.dll (which is needed by L”Z:\\home\\user\\.wine\\drive_c\\Archivos de programa\\REM 1.2.2\\bin\\REM_1_2_2.exe”) not found

err:module:LdrInitializeThunk Main exe initialization for L”Z:\\home\\user\\.wine\\drive_c\\Archivos de programa\\REM 1.2.2\\bin\\REM_1_2_2.exe” failed, status c0000135

y la ejecución fallaba, asi que una vez más:

$ sh winetricks vcrun6
$ sh winetricks mfc42
$ wine ~/.wine/drive_c/Archivos\ de\ programa/REM\ 1.2.2/bin/REM_1_2_2.exe

y sigue la instalación normalmente. Habría que ir repitiendo el procedimiento con winetricks para cada librería que se necesitase en la instalación, leyendo siempre el mensaje de error de la pantalla.

Por cierto si lanzamos winetricks sin parámetros:

ejecutar_winetricks_sin_param

aparecen en pantalla todas las librerías disponibles para la instalación:

ventana_install_librerias_winetricks

/*
*
*@Propinas
*/
He encontrado otras utilidades a instalar con winetricks para el mejor funcionamiento de la herramienta REM, las dejo por aquí por si le pueden servir a alguien:
  • Para ver la documentación que REM puede generar en formato HTML, hacer:

$ sh winetricks ie6 gecko msxml3

  • Si quieres acceder a winetricks desde cualquier parte muevelo a /usr/bin:

$ sudo mv winetricks /usr/local/bin

  • Si hay varios directorios con wine, se puede indicar a winetricks en cual quieres la instalación. Veamos que haciendo:

env WINEPREFIX=~/.winecarpetauno winetricks dotnet11
Y el efecto es que se instalaría la libreria dotnet11 no en .wine sino en .winecarpetauno.

  • Por cierto, en la instalación se dice, pero por si acaso, al final no te olvides de quitar el último caracter del fichero .xsl correspondiente, debería estar en la ruta: ~/.wine/drive_c/Archivos de programa/REM 1.2.2/xml/default/REM_TraceImage.xsl. Simplemente editarlo, borrar el último caracter y guardarlo de nuevo.
🙂  ¡ciao!

Ingeniería de software: tipos de requisitos-II

mayo 21, 2010

Sigo con el tema de los requisitos y algo de organización y tipificación de ellos. Ahora quiero pasar a montar una vista algo mas general para categorizarlos en el trabajo diario.

  • Requisitos en negativo: Es importante decir lo que el sistema no debe hacer, empleando requisitos “en negativo” que limiten el ámbito del sistema. Indican dónde no se deben emplear recursos. Son fundamentales para sistemas críticos. Es muy recomendable el mantener la distinción liveness/safety del conjunto de requisitos:
Liveness: Requisitos que dicen lo que el sistema debe hacer.
Safety: Requisitos que dicen lo que el sistema no debe hacer.
  • Requisitos Funcionales: Describen los servicios (funciones) que se esperan del sistema. Por ejemplo: “El sistema aceptará pagos con VISA”.
  • Requisitos No Funcionales: Restricciones sobre los requisitos funcionales. Por ejemplo: “El sistema aceptará pagos con VISA de forma segura y con un tiempo de respuesta menor de 5 segundos”. Se distinguen dos tipos de requisitos no funcionales:
  • Orientados al usuario:
Fiabilidad, Seguridad (security), Seguridad (safety), Usabilidad, Robustez, Disponibilidad, Rendimiento (Tiempo de respuesta, Capacidad, Throughput).
  • Orientados al desarrollador:
Disponibilidad, Portabilidad, Adaptabilidad, Testabilidad, Comprensibilidad. Pero esta distinción, muchas veces, resulta arbitraria: “El sistema aceptará pagos con VISA a través del protocolo SET”

Ingeniería de software: tipos de requisitos-I

mayo 21, 2010
Para tener una idea primaria e intuitiva del contexto de un proyecto de desarrollo de software, podríamos ver que todo problema software consiste en configurar una máquina para que ejerza unos efectos R en un dominio K. La conexión se realizaría a través de una interfaz que podríamos llamar S:
· Los efectos R son los llamados “requisitos”: Necesidades, metas, objetivos.
· El conocimiento del dominio K describe el contexto.
· La máquina (hw+sw) es la que realizará aquellos requisitos R, gracias a S, que describe la conexión con el dominio K.

En este caso, quiero detenerme en organizar varias ideas en torno a los tipos de requisitos que se podrían concretar. Ahí va mi organización de tipos:

  • Requisitos que definen efectos sobre el entorno: “El sistema mantendrá la temperatura de la caldera entre 70º y 80º.”
  • Requisitos muy generales: “El sistema mantendrá un registro de todos los materiales de la biblioteca, incluyendo libros, periódicos, revistas, videos y CDRoms.”
  • Requisitos funcionales: “El sistema permitirá a los usuarios realizar una búsqueda por título, autor o ISBN.”
  • Requisitos de implementación: “El interfaz de usuario se implementará sobre un navegador Web.”
  • Requisitos de rendimiento: “El sistema deberá soportar al menos 20 transacciones por segundo.”
  • Requisitos de usabilidad: “El sistema permitirá que los nuevos usuario se familiaricen con su uso en menos de 15 minutos.”

Debido a que hay tantos tipos distintos de requisitos, no es posible establecer una forma estándar de escribirlos. Tampoco es posible decir cual es “la mejor forma” de especificarlos. Todo depende mucho de quien los escribe, quien los va a leer, el dominio de la aplicación, etc.

Pero poco a poco vamos a ir generando ideas útiles para ayudar a comprender el mundo de los requisitos :). Un saludo a tod@s.

Revisión personal del encuentro #xdp-I

mayo 16, 2010

El día siete de Mayo tuvo lugar el primer encuentro #xdp, un evento ágil para programadores enfocado a las metodologías ágiles, y al desarrollo de software.

La iniciativa partió de una idea inicial de quedada sencilla para charlar, y a partir de una inciativa, se configuró un evento de tipo desconferencia[1]. Se generó un wiki para registro de asistentes, y mediante post en diversos blogs y twitteos se agitó el evento.

Ya el compañero penyaskito publicó hace unos días su visión sobre el evento en su blog. Pero yo ahora quisiera plasmar mi visión personal del evento del otro día, y anotar puntos que pudieran resultar de interés para otras experiencias similares.

Voy a ofrecer primero algunos datos sobre el evento:

Lugar: Cafetería Compañía Cubana. Avda Reina Mercedes 19 (enfrente de Fac. Arquitectura Técnica) .41012 Sevilla

Asistentes: 16 personas.

Nivel de asistentes: Multinivel. Desde programadores experimentados, o analistas funcionales, hasta estudiantes universitarios con poca experiencia en el mercado laboral.

Duración aproximada del evento: Unas tres horas. Desde las seis de la tarde (hora de la llegada de los primeros asistentes) hasta las nueve de la noche (cierre del evento).

Ahora pasaré a aspectos mas concretos. Para mas info sobre los temas, se puede consultar aqui.

Bajo mi propio punto de vista:

Aspectos positivos:

1.-La agilidad de la creación y la promoción del evento (apenas unos tres días), verdaderamente ejemplo de agilidad.

2.-La asistencia: conseguir dieciseis asistentes para un evento sin antecedentes parecidos, me parece una buena asistencia.

3.-La participación: Se asistió y se habló, quiero decir que los asistentes participaron activamente en los debates y conversaciones. No hubo “convidados de piedra”. No observé inhibiciones importantes a la hora de participar.

4.-El aprendizaje: Se transmitió conocimiento, se resolvieron dudas, se aprendieron cosas relacionadas con los objetivos del evento.

5.-Las relaciones interpersonales: Conocer nuevos compañeros, aprovechar para volver a ver a los ya conocidos, saber en que estamos trabajando todos.

6.-Predisposición general a repetir el evento.

7.-En general un nivel de satisfacción positivo en la relación objetivos-metodología-aprendizaje.

Puntos a mi entender que hay que mejorar:

1.-La escucha: Hay que escuchar mas, y mejor. Tener mas predisposición a escuchar que a  hablar.

2.-Maduración de una serie de directrices sobre este tipo de eventos:

2.1.-No pensar en “que puedo contar en el evento”, sino mas bien “que puedo aprender en el evento”

2.2.-Dejar fuera de la participación los “traumas” de la profesión. Todos los conocemos, todos tenemos millones de     experiencias en ese sentido, y nos hace perder tiempo para trabajar los objetivos.

3.-Tener mas cultura de debate: respetar mejor los turnos de palabra. Nos pisamos al hablar, no esperamos que nos den una idea para lanzar la nuestra,  con lo cual no la hemos incluido en nuestra reflexión y demostramos que no estábamos escuchando activamente.

4.-Un papel de moderación mas concreto, con funcionalidades bien definidas. En grupos de vida corta es muy recomendable, mientras el grupo vaya regulandose mejor, el uso de un moderador que da turnos de palabra, reenfoque los debates, cierre turnos, sintetize conclusiones y reoriente intervenciones personales cuando nos desviemos de los temas de debate.

En el plano personal, decir que la verdad es que me gustó mucho el evento y en términos generales pienso que fué muy útil.

Me gustaría aportar algunas ideas mas para mejorar el rendimiento de estos y que el aprendizaje fuera mayor y de mas calidad. Pero eso lo dejo para otros posts. Como pistas, algunas ideas que tengo en la mente:

1.-Definición del rol y funcionalidades de un moderador para #xdp

2.-Decálogo de “buenas prácticas” para una participación óptima en eventos #xdp

3.-Debatir la posibilidad de estructurar los contenidos en una relación hombre-tema

Un abrazo a tod@s.

[1]http://es.wikipedia.org/wiki/Desconferencia

Guía de desarrollo en OpenMeetings-II

mayo 13, 2010

Seguimos repasando el procedimiento para desarrollar sobre OpenMeetings.

4.-Prepara el código del proyecto

Hay que realizar una importación a tu equipo de los archivos del proyecto. En concreto, hay que hacer un checkout. ¿Tienes subversion instalado? ¿Sabes lo que es un checkout?, bueno si hay algún no a estas preguntas no importa, pásate primero por aqui y le echas un vistazo a algunas cosillas previas sobre subversion.

Seguimos. Ubícate mediante consola en la carpeta workspace del Eclipse que se ha instalado antes y pide el checkout del proyecto:

svn_checkout_openmeetings

También puede realizarse la descarga mediante Subclipse, un plugin de Subversion para Eclipse que permite manejar de manera gráfica los subcomandos de subversión. Si te interesa, pásate por aqui.

Esta orden descargará un directorio de un proyecto llamado “ROOT” con el código del proyecto openmetings en tu workspace. Esta directorio tiene la estructura de un “Dinamic web Project” para Eclipse y contiene también el servidor de streaming red5, todas las librerías y ficheros necesarios para la plataforma openmeetings.

A partir de aquí, desde Eclipse ->  menú File -> import Project from workspace -> tipo “Dinamic Web  Project” y ya queda abierto y disponible desde Eclipse.

5.-Prepara una base de datos

Openmeetings requiere de una base de datos para almacenar información sobre la plataforma, los usuarios, las salas, etc.

Así que para el correcto despliegue, instala, por ejemplo mysql (openmeetings no requiere de ningún motor en concreto, solo con la condición de que este soportada por Hibernate, que es el motor de persistencia que usa openmeetings 🙂 ). Simplemente hacer por consola:

sudo apt-get install mysql-server-5.1

Y esa instrucción ya instalará servidor, cliente y todas las dependencias que mysql requiera. En la instalación hay que dar una cotraseña para el usuario root de mysql. Para hacer las cosas algo mas sencillas, estos datos de acceso a mysql han de ser los que figuren en el mapeo objeto-relacional.

En concreto, quiero decir que hay que ir a Eclipse y buscar pulsando sobre el proyecto – haciendo Ctrl + May + r – y tecleando el nombre del fichero a buscar: hibernate.cfg.xml. Una vez delante y abierto en Eclipse, hay que mirar en las líneas doce y trece del fichero.

hbn_cfg_xml

Tenemos que asegurarnos que el usuario y password que están registrados en este fichero de configuración son los que se han declarado en la instalación de mysql, ya que si no la plataforma no podrá conectarse a la base de datos y no arrancará.

Por la creación de la base de datos no hay que preocuparse. En el mismo fichero hibernate anterior, en torno a la línea veinte, dentro del apartado <database settings>, ha de estar una información como esta:

<property name=”connection.url”>
jdbc:mysql://localhost/openmeetingseclipse?autoReconnect=true&amp;useUnicode=true&amp;createDatabaseIfNotExist=true&amp;characterEncoding=utf-8
</property>

Donde el atributo “createDatabaseIfNotExist” con valor puesto a “true” indica que en caso de no existir la base de datos, hibernate se encargará de crearla si los datos de acceso usuario – password son coherentes.

A partir de aqui, hay que añadir nuestra plataforma como proyecto web a Tomcat. Botón derecho sobre el servidor, opción add-remove y añadimos el proyecto “ROOT”. Botón derecho sobre Tomcat y pulsamos “start”, con lo cual queda inicializado.

A partir de ahí podemos desde el navegador ver la plataforma desplegada en http://localhost:8080/openmeetings


6.-Otros requisitos y recomendaciones

1.-Tener instalado el plugin de Flash en su ultima versión (10).

2.-Tener los drivers necesarios para el correcto funcionamiento del hardware de conferencia (micrófono y cámara), en caso de Windows. En caso de Linux, comprobar que el hardware es soportado por la versión del Kernel.

Guía de desarrollo en OpenMeetings-I

mayo 12, 2010

¿Necesitas desarrollar para OpenMeetings? ¿Te apetece?, ¿Te mola el tema de e-meetings?, bueno vamos a empezar a preparar el entorno de trabajo.

1.-Asegurate de tu instalación de Java

Haz java -version en tu consola.  Deberías ver algo parecido a esto:
java -version

En caso de no ver algo así, entonces directamente puedes probar a ir a :

http://java.com/es/download/installed.jsp

Y consultar el estado de tu instalación de Java. A partir de lo que te diga, entonces o bien sigues los pasos indicados ahí para instalarte el JDK o bien vas a consola y escribes esto:

sudo_apt_get_install_openjdk

Y así queda instalado el OpenJDK.

2.-Prepárate un IDE para desarrollar

Entrar en el directorio raiz y pasa a /bin. Allí realizar sudo mkdir packages y luego sudo chmod -Rf 777 packages.

Ahora tenemos un directorio llamado “packages” donde realizar la instalación del IDE.

Pasar al directorio creado en el apartado anterior, (cd /bin/packages) y una vez dentro descargar el IDE Eclipse para J2EE.

Opción 1: Mediante descarga web

Ir a http://www.eclipse.org/downloads y selecccionar la primera opción: “Eclipse IDE for Java EE Developers (189 MB)”.

Solicitar la descarga del fichero en formato tar.gz

En una conexión normal, suele durar entre diez y quince minutos.

Opción 2: Mediante wget

Realizar por consola :

wget http://d2u376ub0heus3.cloudfront.net/galileo/eclipse-jee-galileo-linux-gtk-x86_64.tar.gz
(Para 64 bits)

o bien:
wget http://d2u376ub0heus3.cloudfront.net/galileo/eclipse-jee-galileo-linux-gtk.tar.gz
Si tenemos arquitectura de 32 bits, pero casi seguro que por una (hardware) o por otra (software), al final tendremos que hacer la instalación para 32 bits.

Desempaquetar y renombrar:

tar xzvf eclipse-jee-galileo-linux-gtk*.tar.gz

mv eclipse eclipse3.5

Así que entrando en bin/packages/eclipse3.5 esta el fichero de arranque, llamado “eclipse” y ejecutable con un simple ./eclipse por consola.

Ahora configura mejor los valores de memoria asignados a Eclipse: por consola, entra al directorio de Eclipse. Edita el fichero eclipse.ini con tu editor preferido y modifica los valores asignados de memoria. En mi caso hago vim eclipse.ini y obtengo algo parecido a esto:

sudo_vim_eclipse_ini

Y vamos modificando la cantidad de memoria RAM asignada a Eclipse (lo que no quita que más adelante tengamos también que asignar memoria al proyecto que queramos desplegar ). Por concretar, Xms representa el valor mínimo asignado y Xmx el valor máximo permitido para la asignación de memoria.

3.-Colócale un servidor para el despliegue

Descargar el tomcat mediante wget (más rápido) y descomprimirlo en un directorio.

Una vez que hallamos descomprimido el archivo zip procederos a configurar el entorno de desarrollo de Eclipse, para lo cual vamos a crear un workspace con el nombre de “Tomcat”, una vez abierto el proyecto procederemos a configurar de la siguiente manera: Window–>Preferences

Ahora vamos a elegir del árbol la opción Server–>Installed Runtimes–>click botón Add.
eclipse_preferences_server_runtime

Procederemos a elegir la carpeta con el nombre de Apache>opción Apache Tomcat v5.5–>clic en botón next
Ahora vamos a elegir donde se encuentra Tomcat 5.5, para lo cual elegiremos la opción Browse y elegiremos la ruta donde se encuentra

tomcat_installation_directory
Recuerda que debes tener la versión del JDK 5.0 al menos, ya que una versión menor no permitiria seguir avanzando con la configuración.

Una vez que eliges donde esta instalado Tomcat 5.5 deberías hacer clic en el botón aceptar y después en el botón Finish y después click en el botón Ok

Ahora añadimos la vista de Servers. Window -> Show view -> Servers y se abrirá la pestaña con la vista de servidores.

Solo nos resta agregar un servidor: lo cual lo realizaremos estando en la parte de de Server botón derecho saldrá la opción new–>click en Server. Seleccionamos el nuestro y ya esta preparado para iniciarse y desplegar cosas 😛

vista_servers_tomcat

Al final obtendrás un Server para poder realizar el despliegue de los proyectos en Eclipse para un entorno de desarrollo.

Nota: En algunos casos la versión 5.5 de Tomcat me ha dado problemas, y a algunos miembros de la comunidad también. → descargar e instalar directamente la versión 6.0.29 que es la más segura.

Control de código Java con PMD-I

mayo 8, 2010

Siguiendo con la idea de probar herramientas para el control del código, hoy el viejo tio David os va a hablar sobre PMD. 🙂

1.-¿Que es PMD?

PMD es un proyecto openSource que sirve para realizar análisis de código Java .
En concreto, revisa código Java y localiza problemas(problems, errors) o advertencias(warnings) sobre el código. Busca posibles conflictos en el código tales como:

  • Optimización de estructuras if-else: Analiza la posible sustitución de estos estados por bucles while en nuestro código
  • Código “muerto”: variables, parámetros y métodos que no se utilizan
  • Código inalcanzable
  • Código susceptible de ser refactorizado
  • Código que no esta suficientemente optimizado
  • Estados varios (try/catch/finally/…) que no estan bien aprovechados o simplemente no se utilizan
  • Y por supuesto todos los posibles bugs de nuestro código
  • Mediante una herramienta llamada CPD (Copy-Paste detector, puede reconocer el código duplicado y reutilizado)

2.-¿Dónde está esa maravilla?

Esta herramienta forma parte de sourceForge y esta disponible desde aqui.
Para las distros Ubuntu y Debian-based, lo intenté localizar mediante ->apt-cache search pmd,   pero no está disponible en los repositorios 😦

3.-Mas características

PMD permite que un usuario se pueda montar un uso variado de la propia herramienta.
Por un lado, permite ser utilizado desde los principales IDES openSource: Eclipse y Netbeans.
También esta integrado con IDES menos populares a nivel de comunidad y no openSource como CodeGuide, JBuilder,JCreator, Intellij IDEA y JDeveloper.
Permite integración con BlueJ (un IDE diseñado especialmente para el aprendizaje de la programación bajo el lenguaje Java): http://www.bluej.org

Puede integrarse también con editores como Emacs,JEdit,  IDES alternativos como Gel, o también con Maven, Maven2,  TextPad y WebLogic.

Además, permite tanto el uso de normas predefinidas para la supervisión del código, como el que cada usuario permita y defina sus propias normas para cotejar su código.

4.-Instalación

Para usuarios de Linux, la instalación requiere tener instalado previamente un jdk óptimo, sirve cualquiera a partir de 1.4. Yo en mi caso tengo instalada la 1.6.0_0.  Entiendo que si quieres probar o usar PMD con código Java, es que ya tienes instalado el JDK (u OpenJDK, si eres algo más…masoquista…  😛  ). Consulta por consola java -version y ahí tendrás la información que necesitas.
Si no tienes Java instalado, puedes hacer esto en tu consola:

sudo_apt_get_install_openJDK

Y te instalas así la versión totalmente libre del JDK de Java, o bien te das una vuelta por la zona de descargas de java en  http://java.com/es/download/index.jsp y te lo descargas e instalas.

Bien, ahora que ya tenemos el Java ahí preparado, simplemente realizamos la descarga de los binarios (ya compilados si quieres evitarte una compilación) de la última versión disponible:
http://sourceforge.net/projects/pmd/files/

O bien prueba a usar wget con esta dirección: http://sourceforge.net/projects/pmd/files/pmd/4.2.5/pmd-bin-4.2.5.zip/download, que seguro que va mas rápido:

wget_pmd

Una vez descargado el zip, abrirlo con la herramienta unzip y comprobar los permisos, mas que nada por evitar problemas posteriores. Si no, pues un chmod -Rf 777 a toda la carpeta y listo 🙂

Bueno, y ahora mismo, lo que tenemos es, basicamente, PMD preparado para funcionar de forma autónoma y directa, sin integración con ningún editor ni IDE.
En siguientes entradas iremos viendo como usarlo.
Un abrazo a tod@s.
Si te motiva el rollo, deberías probar a venir a las #xdp. ¡Apúntate!

Posteo urgente: XDP

mayo 6, 2010

Hola a todos. ¿Sabeis que es xdp?

Pues basicamente es un evento ágil, dinámico y relativamente espontáneo. Un modo de desconferenciar[1]. XDP son las siglas de “Extreme Desconference for Programmers” que en inglés siginifica una desconferencia (ver [1]) extrema para programadores.

Y con la misma agilidad escribo yo este post. Y con la misma agilidad quedó planteado el tema. Simplemente a raiz de una propuesta de quedada en twitter entre ese niño prodigio del software y amigo@xflx, ese chiflado genial de Peñaskito (@penyaskito), el incombustible Fran Seva (@fran) y un servidor (en twitter @davidjguru), lo que empezó siendo una quedada para tomar algo y charlar, al momento y gracias  a Penyaskito ha quedado  transformado en un evento para desarrolladores. Un golpe de efecto genial y muy creativo, al que personalmente me rindo y me entrego, porque no hay riqueza sin diversidad y sinceramente, me encanta organizar cosas. Además, si entre algunas cosas más, hablaremos de metodologías ágiles ¿Que mejor que predicar con el ejemplo? 😛

Nos decía Adrian Belmonte (@belmontemartin) si cabría la posibilidad de cambiar la fecha del evento para asegurar su asistencia, pero ha quedado emplazado para la siguiente. Si estas en la misma situación no te preocupes, que seguro que habrá mas, sin duda alguna.

¿Qué ocurrirá? Quedaremos, charlaremos, nos pondremos al día, hablaremos de mil temas y crearemos identidad de grupo, buenas relaciones, contactos personales y sobretodo, nos enriqueceremos mucho de todos nosotros. Y ojalá que hayamos creado un nuevo monstruo en el sentido de que hayan mas XDP y se genere una dinámica de encuentros periódicos y una red cada vez mas tupida de relaciones entre los que con mayor o menor fortuna nos dedicamos a esto.

Os anoto algo mas:

La quedada será en la Puerta Principal Escuela Técnica Superior de Ingeniería Informática, en la Avenida Reina Mercedes s/n 41012 Sevilla, durante la tarde del Viernes 7 Mayo 2010, en concreto a partir de las 18:00h.

El sitio web del evento anda por aquí:

http://xdp.jottit.com


Razones por la que asistir:

1.-Te gusta la programación

2.-Trabajas en el mundo de la programación

3.-Una combinación de ambas (puede pasar, se han dado casos :P)

4.-Estas enamorad@ de alguno de los asistentes

5.-Quieres aprender cosillas molonas o hablar de alguna experiencia relacionada

6.-Únete a nosotros, y juntos dominaremos la galaxia.

7.-HOYGAN, KOMO PUEDO JAKEARME EL JOTMAIL. -> Tienes que venir, sin duda.

…Y podríamos crear mil razones. Tienes que venir. Aqui se esta fraguando algo con proyección de futuro. Tengo la intuición. No te lo pierdas, esto va a ser la semilla de algo mas trascendente. Te queremos en el evento.

¡¡NOS VEREMOS ALLÍ!!

[1]http://es.wikipedia.org/wiki/Desconferencia

Sistemas de control de versiones-VII: Empezando con subversion

abril 28, 2010

1.-Intro a svn

Subversion (en adelante svn) es un software para el control de versiones. Como ya sabemos, es centralizado, y fue iniciado por la empresa CollabNet en el año 2000. Esta compañía paga el sueldo de desarolladores a tiempo completo del proyecto, pero en si, svn tiene una licencia de uso Apache, así que cumple con las cuatro libertades del software libre.

Es utilizado en muchos proyectos importantes dentro de la comunidad openSource y además tiene mucha difusión en el ámbito de la empresa privada

2.-Características de svn

Entre sus características mas importantes, figuran:

Recoge la mayoría de características de CVS. Salvo algunas cosillas, como por ejemplo un útil tratamiento de tags y branches, aprovecha todo el funcionamiento de CVS.

El repositorio establece un único estado, es decir, se define un único número de versión que identifica un estado común  en un instante determinado para todo el proceso.

Permite la integración con Apache para el acceso, lo que también incuye aprovechar las capacidades de este servidor web.

Además trae su propior servidor svnserve, un servidor ligero y autónomo que usa un protocolo propio( svn://…) sobre una conexión TCP/IP. (Así que para accesos, Apache, svnserve y de forma local).

…Y estas son solo algunas…

3.-Partes de subversion

Subversion consiste en la suma de varias partes, en total ocho módulos que vienen a ser:

  • svn: La aplicación para vía de comandos
  • svnversion: Aplicación para informes de estado
  • svnlook: Una herramienta para inspeccionar un repositorio svn
  • svnadmin: Herramienta para administrar repositorios svn
  • mod_dav_svn: Plugin para publicar repositorios en red a través del servidor Apache
  • svndumpfilter: Programa para volcar contenidos de repositorios svn
  • svnserve: Servidor independiente para publicar en red, para ejecutar como un demonio o invocable vía ssh
  • svnsync: Utilidad para la sincronización de un repositorio sobre otro.


4.-Acceso a svn

Si ya tenemos el servidor svn instalado y preparado el acceso vía Apache (ver post anterior, instalación de svn), entonces es momento de empezar a currar con svn. Vamos a empezar fijando algunas ideas de buenas prácticas.

Para empezar, el acceso a svn puede realizarse de las siguientes formas:

Protocolo Acceso
file:/// Acceso directo al repositorio de forma local, vía navegador de archivos.
http:// Acceso vía el módulo webDav, para acceder a repositorios vía Apache.
svn:// Acceso a través del propio protocolo de svn para servidor svnserve.
https: Acceso vía webDav pero con encriptación ssl.
svn+ssh:// Acceso vía svnserve a través de tunel ssh.

¿Cual de ellas elegir?, bueno todo depende de las necesidades de acceso que necesitemos. Por ejemplo, si queremos encriptación o no de los datos, si preferimos un acceso mas ágil y menos seguro o uno mas lento y pesado y a cambio con mas seguridad. En general, por comentar, os diré algunas ideitas sobre los accesos a svn:

  • Usar el acceso http: Esta opción permite aprovechar todas las capacidades sobre autenticación que Apache trae. Además permite usar SSL (opción de acceso https). La configuración de esta parte es algo mas compleja que la del resto de accesos y se pierde agilidad con respecto a svnserve, por ejemplo.
  • Usar svnserve: Es rápido y sencillo de hacerlo funcionar (el protocolo que usa es mas rápido que pasar a través de webDav), pero a cambio este protocolo no es encriptado, lo que lo hace mas inseguro con respecto a otros disponible.
  • Usar el combo svnserve + ssh: Sigue siendo rápido y se aprovechan las capacidades de encriptación de ssh.

Con la opción de acceso  file:/// atención, porque no va a ser posible acceder mediante file:/// desde el navegador. El navegador normalmente muestra el contenido examinando el sistema de ficheros, peeeeeero, svn monta sus recursos, en un sistema de ficheros virtual, con el cual el navegador no saber muy bien como relacionarse. 😦

He estado bicheando la posible integración de svn como servidor con cherokee (el servidor web: http://www.cherokee-project.com ) y al parecer el tema no esta disponible. Por lo visto el módulo mod_dav_svn no ha sido adaptado para otras arquitecturas de servidores web que no sea Apache. Así que por el momento toca conformarse 😦 .

5.-Convenciones sobre tu repositorio

Fundamentalmente, existe una cierta convención de buenas prácticas sobre la estructura de directorios de un repositorio svn, lo que viene llamándose el layout del proyecto. Cada cual se monta el repositorio como se le antoja, pero lo normal (entendido como la frecuencia de uso), es crear la siguiente estructura:

Branches: Es el directorio donde almacenar versiones del proyecto que van a recibir cambios sustanciales o de importancia en el desarrollo. Es decir, puede usarse para alterar significativamente el contenido del código sin alterar el directorio principal (mas adelante, hechos y probados los cambios que sean, pueden fusionarse los contenidos). Normalmente se implementa una rama para trabajar con nuevas features o características de importancia para el proyecto.

Trunk: Es el directorio principal de nuestro repositorio, aquel que almacena el código fuente de nuestro proyecto en un momento determinado del desarrollo, viene a ser nuestra carpeta de desarrollo y ha de tener la calidad de estar probado y ser estable (trabajos realizados en los branches correspondientes).

Tags: Este directorio sirve para almacenar versiones de nuestro proyecto, congelaciones de versiones, etc. ¿Que se ha conseguido una versión estable? A un tag. ¿Que se ha implementado una función de importancia? A un tag. ¿Que hay que preparar un hito de entrega del producto para el cliente? A un tag.

¡Nos vemos en la siguiente entrega!

Sistemas de control de versiones-VI: Instalando subversion, 2ª parte

abril 21, 2010

En este post continuamos con la experiencia de instalar nuestro propio svn que plasmamos en el post anterior. A continuación veremos como hacerlo accesible vía Apache.

Segunda parte: Compartiendo el servidor svn mediante apache


6.-Preparar Apache

Una vez que tenemos nuestro repositorio de software, si queremos que este accesible para un equipo de desarrollo, entonces hay que ofrecer acceso al repo vía Apache, por ejemplo. Instalamos Apache y las librerías relacionadas con subversion:

sudo apt-get install apache2

sudo apt-get install libapache2-svn

A continuación arrancamos Apache:

sudo /etc/init.d/apache2 start

Y si todo ha ido bien, entonces desde el navegador, la dirección http://localhost, debe dar un mensaje de “It works!” como este.


apache_it_works!
7.-Accesos, propiedad y permisos

Funcionando ahora a través de Apache, mejor cambiamos el propietario de los repositorios. Con:

sudo chown -R www-data /var/lib/svn/test

Hacemos que el propietario sea ahora el usuario www-data.

Por otro lado, mejor no dejar el acceso público y abierto a nuestro repositorio, así que por razones de seguridad y control de acceso, vamos a configurar el acceso mediante contraseñas al servidor svn. Tecleando en primer lugar:

sudo htpasswd -c /etc/apache2/dav_svn.passwd us1

Estamos indicando mediante el parámetro -c que ha de crearse por primera vez el almacén de contraseñas. Una vez creado este, podemos seguir añadiendo usuarios, tantos como necesiten el acceso al servidor sin necesidad de especificar el -c. Ahora:

sudo htpasswd /etc/apache2/dav_svn.passwd us2

sudo htpasswd /etc/apache2/dav_svn.passwd usN

8.-Modificando DAV


¿Que es DAV?

Así, brevemente,digamos que DAV es un módulo de Apache que mediante una extensión del protocolo http, nos permite crear, mover, copiar y eliminar recursos y datos en un servidor web remoto. Necesitamos habilitarlo correctamente para poder manejar los repositorios y permitir que otros usuarios externos al servidor puedan manipular información.

(Ver http://httpd.apache.org/docs/2.0/mod/mod_dav.html)

Cambiamos la configuración del módulo DAV de Apache:

sudo vim /etc/apache2/mods-available/dav_svn.conf

(Vamos, vim o el editor que más te guste)

Tenemos que descomentar algunas líneas y modificarlas para que se adapten a nuestra estructura propia.

<Location /svn >

DAV svn
SVNParentPath /var/lib/svn

AuthType Basic
AuthName “Repositorios Subversion personales”
AuthUserFile /etc/apache2/dav_svn.passwd

< LimitExcept GET PROPFIND OPTIONS REPORT >

Require valid-user
< /LimitExcept >

< /Location >

9.-Para ir cerrando 🙂

Hay que reiniciar Apache para que detecte los cambios que hemos realizado. No es necesario reiniciarlo en cada creación de un repositorio, simplemente ahora que hemos modificado uno de sus archivos de configuración. Hacemos:

sudo /etc/init.d/apache2 restart

Y ya debemos tener el repositorio disponible remotamente. Si probásemos desde un navegador con la siguiente dirección:

http:// localhost/svn/test

o desde fuera de nuestra máquina con:

http://nombre_del_servidor_o_dir_ip/svn/test

Ya deberiamos obtener una ventana de vista general del repositorio de la siguiente forma:

Apache_svn_test

(Lo cual no nos permite trabajar con el repositorio, pero si comprobar que esta visible y cual es su estructura). En las próximas entregas iremos viendo como trabajar con nuestro propio repositorio.

¡Hasta la próxima!

Segunda parte: Compartiendo el servidor svn mediante apache6.-Preparar Apache

Una vez que tenemos nuestro repositorio de software, si queremos que este accesible para un equipo de desarrollo, entonces hay que ofrecer acceso al repo vía Apache, por ejemplo. Instalamos Apache y las librerías relacionadas con subversion:

sudo apt-get install apache2

sudo apt-get install libapache2-svn

A continuación arrancamos Apache:

sudo /etc/init.d/apache2 start

Y si todo ha ido bien, entonces desde el navegador, la dirección http://localhost, debe dar un mensaje de “It works!” como este.

7.-Accesos, propiedad y permisos

Funcionando ahora a través de Apache, mejor cambiamos el propietario de los repositorios. Con:

sudo chown -R www-data /var/lib/svn/test

Hacemos que el propietario sea ahora el usuario www-data.

Por otro lado, mejor no dejar el acceso público y abierto a nuestro repositorio, así que por razones de seguridad y control de acceso, vamos a configurar el acceso mediante contraseñas al servidor svn. Tecleando en primer lugar:

sudo htpasswd -c /etc/apache2/dav_svn.passwd us1

Estamos indicando mediante el parámetro -c que ha de crearse por primera vez el almacén de contraseñas. Una vez creado este, podemos seguir añadiendo usuarios, tantos como necesiten el acceso al servidor sin necesidad de especificar el -c. Ahora:

sudo htpasswd /etc/apache2/dav_svn.passwd us2

sudo htpasswd /etc/apache2/dav_svn.passwd usN

8.-Modificando DAV

¿Que es DAV?

Así, brevemente,digamos que DAV es un módulo de Apache que mediante una extensión del protocolo http, nos permite crear, mover, copiar y eliminar recursos y datos en un servidor web remoto. Necesitamos habilitarlo correctamente para poder manejar los repositorios y permitir que otros usuarios externos al servidor puedan manipular información.

(Ver http://httpd.apache.org/docs/2.0/mod/mod_dav.html)

Cambiamos la configuración del módulo DAV de Apache:

sudo vim /etc/apache2/mods-available/dav_svn.conf

(Vamos, vim o el editor que más te guste)

Tenemos que descomentar algunas líneas y modificarlas para que se adapten a nuestra estructura propia.

<Location /svn >

DAV svn
SVNParentPath /var/lib/svn

AuthType Basic
AuthName “Repositorios Subversion personales”
AuthUserFile /etc/apache2/dav_svn.passwd
< LimitExcept GET PROPFIND OPTIONS REPORT >

Require valid-user
< /LimitExcept >

< /Location >

9.-Para ir cerrando 🙂

Hay que reiniciar Apache para que detecte los cambios que hemos realizado. No es necesario reiniciarlo en cada creación de un repositorio, simplemente ahora que hemos modificado uno de sus archivos de configuración. Hacemos:

sudo /etc/init.d/apache2 restart

Y ya debemos tener el repositorio disponible remotamente. Si probásemos desde un navegador con la siguiente dirección:

http:// localhost/svn/test

o desde fuera de nuestra máquina con:

http://nombre_del_servidor_o_dir_ip/svn/test

Ya deberiamos obtener una ventana de vista general del repositorio de la siguiente forma:

(Lo cual no nos permite trabajar con el repositorio, pero si comprobar que esta visible y cual es su estructura). En las próximas entregas iremos viendo como trabajar con nuestro propio repositorio.

¡Hasta la próxima!

Sistemas de control de versiones-V: Instalando subversion, 1ª parte

abril 21, 2010

Vamos a pasar a algo mas técnico, mas de acción, que ya tenemos suficiente teoría (por el momento). Hasta que no pasemos a los sistemas de control distribuidos, haremos ahora parada y fonda. Vamos a practicar un poco. Vamos a montar nuestro propio repositorio subversion. Dividiremos la práctica en dos partes. Crear un servidor svn propio, y darle acceso mediante un servidor web Apache. Vamos al turrón.

El sistema operativo es Ubuntu 9.04 Jaunty Jackalope. Si, estamos en abril de 2010 y todavía me tengo que actualizar :P, pero bueno, en otras versiones de Ubuntu mas modernas, todo esto es igual.

Primera parte: Instalando servidor svn propio


1.-Instalamos los paquetes necesarios para svn. En concreto, tecleamos en consola:

sudo apt-get install subversion
sudo apt-get install subversionsubversion-tools

(Esto se puede poner en una línea para el intérprete de comando, pero yo soy así de ordenado) 😛

Si nuestros repositorios estan tan cual deben, entonces no habrá ningún problema. De todas formas, si tus repositorios no van, entra aqui: http://subversion.apache.org/packages.html y descargate los paquetes que necesites. Instala con dpkg -i por consola ;).

2.-Decidimos nuestra estructura base

Normalmente se asocia un directorio de svn a un proyecto, con lo que es frecuente, que tengamos mas de un rdirectorio. Vamos a crear una base a modo de directorio padre y dentro de el crearemos todos los subdirectorios que nos hagan falta para cada proyecto que tengamos que alojar.

Hacemos en consola: sudo mkdir /var/lib/svn (como directorio padre).

Y ahora vamos a crear un directorio para las pruebas: sudo mkdir /var/lib/svn/test

A continuación, tenemos que dar estructura de directorio svn al directorio creado. Se hace mediante el comando svnadmin y el subcomando create:

sudo svnadmin create /var/lib/svn/test

La combinación svnadmin create deberíamos teclearla en consola cada vez que queramos convertir un subdirectorio de la estructura básica de svn en repositorio. ¿Por qué? Este comando crea un conjunto de ficheros necesarios para almacenar la información sobre el control de versionado del código del proyecto (algo así como metainformación necesaria para svn) No es necesario aprender a manipular su contenido directamente. Para ello tenemos comandos y aplicaciones que se encargarán de mantener la información adecuadamente.

3.-Estructura de ficheros en svn

Por convenio, el repositorio destinado a almacenar un proyecto concreto, tendrá la siguiente estructura interna:

/branches
/trunk
/tags

Basicamente, aunque cada administrador del proyecto establece los matices necesarios sobre el uso de los directorios, en general, se usan de la siguiente manera:
trunk -> Línea de desarrollo principal del proyecto, llamado el tronco.
branch -> Ramificaciones que se van generando desde la línea principal.
tags -> Marcas de fase, congelación de versiones del proyecto, etc.

Hacer en consola:
sudo svn mkdir –message=”Preparando los directorios internos del proyecto…” \

/var/lib/svn/test/trunk
/var/lib/svn/test/tags
/var/lib/svn/test/branches


4.-Grupos de usuarios

Es importante establecer control sobre el acceso a nuestro servidor de subversion para evitar problemas sobre el contenido. Para ello es necesario establecer permisos y usuarios sobre nuestros repositorios. Vamos a crear un grupo de usuarios y a este grupo iremos añadiendo los usuarios que tendrán permisos para operar en nuestro repositorio.

Creamos un grupo:
sudo addgroup subversion

Damos propiedad y permisos sobre nuestro subversion:
sudo chown -R root:subversion /var/lib/svn/test
sudo chmod -R 770 /var/lib/svn/test

Con estas dos últimas líneas, hemos hecho que nuestro subversion sea propiedad del usuario root de la máquina y del grupo que hemos creado anteriormente. El propietario y los miembros del grupo declarado antes tienen libre acceso a manipular su contenido, pero el resto no puede realizar cambios sobre el repositorio. Esto se ha declarado en la segunda línea, mediante la cifra -770-.


5.-Usuarios en local

Teclear en consola:

sudo adduser usuarioBraulio subversion
sudo adduser usuarioJacinto subversion

Con estas instrucciones anteriores hemos añadido al grupo “subversion” a los dos usuarios que queremos admitir como usuarios de pleno derecho de nuestro repositorio local.

Con todo esto ya tenemos un repositorio accesible de forma local. Si desde nuestras herramientas de cliente “svn” queremos acceder a él deberemos referenciarlo como:

file:///var/lib/svn/test

En el siguiente post, acceso a svn mediante Apache. Proximamente.

Primera parte: Instalando servidor svn propio

1.-Instalamos los paquetes necesarios para svn. En concreto, tecleamos en consola:

sudo apt-get install subversion
sudo apt-get install subversionsubversion-tools

(Esto se puede poner en una línea para el intérprete de comando, pero yo soy así de ordenado) 😛

Si nuestros repositorios estan tan cual deben, entonces no habrá ningún problema. De todas formas, si tus repositorios no van, entra aqui: http://subversion.apache.org/packages.html y descargate los paquetes que necesites. Instala con dpkg -i por consola ;).

2.-Decidimos nuestra estructura base

Normalmente se asocia un directorio de svn a un proyecto, con lo que es frecuente, que tengamos mas de un rdirectorio. Vamos a crear una base a modo de directorio padre y dentro de el crearemos todos los subdirectorios que nos hagan falta para cada proyecto que tengamos que alojar.

Hacemos en consola: sudo mkdir /var/lib/svn (como directorio padre).

Y ahora vamos a crear un directorio para las pruebas: sudo mkdir /var/lib/svn/test

A continuación, tenemos que dar estructura de directorio svn al directorio creado. Se hace mediante el comando svnadmin y el subcomando create:

sudo svnadmin create /var/lib/svn/test

La combinación svnadmin create deberíamos teclearla en consola cada vez que queramos convertir un subdirectorio de la estructura básica de svn en repositorio. ¿Por qué? Este comando crea un conjunto de ficheros necesarios para almacenar la información sobre el control de versionado del código del proyecto (algo así como metainformación necesaria para svn) No es necesario aprender a manipular su contenido directamente. Para ello tenemos comandos y aplicaciones que se encargarán de mantener la información adecuadamente.

3.-Estructura de ficheros en svn

Por convenio, el repositorio destinado a almacenar un proyecto concreto, tendrá la siguiente estructura interna:

/branches
/trunk
/tags

Basicamente, aunque cada administrador del proyecto establece los matices necesarios sobre el uso de los directorios, en general, se usan de la siguiente manera:
trunk -> Línea de desarrollo principal del proyecto, llamado el tronco.
branch -> Ramificaciones que se van generando desde la línea principal.
tags -> Marcas de fase, congelación de versiones del proyecto, etc.

Hacer en consola:
sudo svn mkdir –message=”Preparando los directorios internos del proyecto…” \

/var/lib/svn/test/trunk
/var/lib/svn/test/tags
/var/lib/svn/test/branches

4.-Grupos de usuarios

Es importante establecer control sobre el acceso a nuestro servidor de subversion para evitar problemas sobre el contenido. Para ello es necesario establecer permisos y usuarios sobre nuestros repositorios. Vamos a crear un grupo de usuarios y a este grupo iremos añadiendo los usuarios que tendrán permisos para operar en nuestro repositorio.

Creamos un grupo:
sudo addgroup subversion

Damos propiedad y permisos sobre nuestro subversion:
sudo chown -R root:subversion /var/lib/svn/test
sudo chmod -R 770 /var/lib/svn/test

Con estas dos últimas líneas, hemos hecho que nuestro subversion sea propiedad del usuario root de la máquina y del grupo que hemos creado anteriormente. El propietario y los miembros del grupo declarado antes tienen libre acceso a manipular su contenido, pero el resto no puede realizar cambios sobre el repositorio. Esto se ha declarado en la segunda línea, mediante la cifra -770-.

5.-Usuarios en local

Teclear en consola:

sudo adduser usuarioBraulio subversion
sudo adduser usuarioJacinto subversion

Con estas instrucciones anteriores hemos añadido al grupo “subversion” a los dos usuarios que queremos admitir como usuarios de pleno derecho de nuestro repositorio local.
Con todo esto ya tenemos un repositorio accesible de forma local. Si desde nuestras herramientas de cliente “svn” queremos acceder a él deberemos referenciarlo como:

file:///var/lib/svn/test

Sistemas de control de Versiones-IV: El asunto BitKeeper

abril 13, 2010

En medio de esta introducción a los sistemas de control de versiones, hacemos parada y fonda para tratar un caso de los mas importantes en el desarrollo de estos sistemas.

¿Por qué?  Bueno, BitKeeper tiene la suficiente importancia en nuestro mundo como para dedicarle un post entero a ello. Veremos el porqué.

Vamos así, a lo rápido. BitKeeper es una herramienta para el control de versiones desarrollada por la emprese BitMover. Durante un tiempo, se usó como sistema de control de versiones del código de muchos proyectos de software libre, pero sin duda el mas importante fue el del Kernel de Linux.

Empezó siendo usado por el proyecto PowerPC en torno a 1999. Luego, en febrero de 2002,el creador de Linux Linus Torvalds decidió que BitKeeper era “la mejor herramienta para el trabajo” (literalmente, “Best Tool For The Job”)y comenzó a utilizarlo para administrar el núcleo principal, un caso que recibió mucha atención en las comunidades de código abierto.

BitMover, la compañía detrás de BitKeeper, fue fundada por Larry McVoy (también desarrollador de Linux), que originalmente pensó en BitKeeper para que Linus trabajase algo mas cómodo. Desde que Linus comenzó a utilizar la herramienta, el ritmo de desarrollo del núcleo Linux fue incrementando, ya se podían delegar mas tareas y concentrarse en otros aspectos.

Peeeero, la decisión tomada en 2002 para el uso gratuito (ojo que “free” no es igual a “free” 😉 ) de esta herramienta para el desarrollo del núcleo Linux fue un tema polémico. El fundador del proyecto GNU, Richard Stallman, expresó su preocupación por la propiedad de las herramientas que se estaban usando en el proyecto mas mítico de los proyectos libres.

Un veterano en el desarrollo del Kernel, Alan Cox, se negó a usarlo argumentando en contra su licencia propietaria y defendiendo la idea de que usarlo suponía ceder cierto control a un desarrollo propietario. No había elección, ya que no existía un sistema de control de versiones distribuido openSource para competir con BitKeeper. En la práctica todo esto implicaba que cualquier persona que quisiese formar parte de los desarrollos solo podía hacerlo desde una aplicación no openSource 😦 .

En medio de estas reflexiones y debates, empezaron intentos de alcanzar una solución para todos. Por un lado, BitMover empezó a implementar pasarelas que permitían la interoperabilidad entre los servidores Linux BitKeeper (gestionada por Bitmover) y desarrolladores que utilizaban CVS y Subversion.
De otro lado, empezaban los procesos de ingeniería inversa para estudiar las características del sistema distribuido propietario y poder ofrecer una alternativa libre.

Así, a los tres años de uso de BitKeeper (abril de 2005), tras años de discusiones, debates, “flamewars” de correos electrónico y acusaciones de violación de licencia incluida, BitMover anunció que dejaría de ofrecer una versión de BitKeeper de forma gratuita a la comunidad, dando como razón los esfuerzos de Andrew Tridge y de la compañia OSDL por realizar procesos de ingenería inversa que violaban la licencia. Así se puso en marcha el proyecto Git.

Torvalds quería un sistema distribuido que pudiese usar como BitKeeper, pero ninguno de los sistemas libres disponibles satisfacía sus necesidades, en particular sus necesidades de rendimiento. En un e-mail que escribió el 7 de abril 2005 empezó a describir el primer prototipo. El tres de abril de 2005 empezaba oficialmente el desarrollo de Git.

El resto es ya la historia del mismo proyecto Git y de los sistemas de control de versiones distribuidos y libres…

¡Nos vemos pronto!

FindBugs para Java desde Eclipse

abril 6, 2010

Estaba el otro día moviendome por la comunidad de temas java y entre enlace y enlace, llegué a este lugar: http://findbugs.sourceforge.net/ Así conocí FindBugs.

1.-¿Que es findbugs?

FindBugs es un  proyecto OpenSource de la universidad de Maryland, que se distribuye bajo licencia GNU Lesser y se encuentra alojado en sourceforge.
Este programa sirve para analizar código implementado bajo la especificación Java (si, código Java :P) y encontrar posibles bugs. De igual forma también es posible que realize búsquedas de bugs en código ya compilado para cualquier versión de Java. En general suele necesitar una versión de Java 1.5 o superior.

2.-¿Que plan?

Bueno, findbugs puede usarse de varias maneras para manejar nuestro código: Puede usarse desde la línea de comandos, bajo su propia interfaz basada en swing, como plugin de Eclipse, como plugin de Nerbeans, desde un script de Ant y bajo Maven.
Como vemos, varias opciones muy interesantes para trabajar con el. Yo, por mi parte, voy a centrarme en el uso vía plugin de Eclipse (que además los javeros somos así de comodones 😛 ).

3.-A descargar el plugin

Primero he intentado obtenerlo via los sitios de actualización de software para Eclipse. Peeeeeero, las direcciones que se proporcionan no funcionan. En concreto estas:

http://findbugs.cs.umd.edu/eclipse/

http://findbugs.cs.umd.edu/eclipse-candidate/

http://findbugs.cs.umd.edu/eclipse-daily/

y bueno, pues se obtiene esta bonita ventana dentro de Eclipse:

No se puede conectar al repositorio

Lo cual indica que no hay repositorio de software alguno en esas direcciones 😦

Así que vamos a la descarga desde sourceforge y a instalarlo a mano

http://sourceforge.net/projects/findbugs/files/findbugs%20eclipse%20plugin/1.3.9/edu.umd.cs.findbugs.plugin.eclipse_1.3.9.20090821.zip/download

Y comienza la descarga automática del material.

4.-Instalar el plugin

Pues nada, simplemente abrir el .zip que se ha descargado y exportar el contenido a la carpeta “plugins” de Eclipse…
Ahora iniciamos (o reiniciamos Eclipse si lo tenemos abierto ya) y vamos a confirmar que el plugin esta detectado por Eclipse. Para ello, vamos a Eclipse -> Help -> About -> Instalation Details -> Plugin (para mi versión de Eclipse).

En esa opción aparece el listado de plugins funcionando en nuestro Eclipse. La lista es normalmente larga, así que vamos a la letra F (este listado va por orden alfabético del nombre del plugin) y buscamos findBugs. Deberíamos encontrar algo así:

Vista de los plugins de Eclipse

Y esta es la señal que tenemos ya el plugin disponible desde Eclipse.

A partir de aqui empieza la experiencia con FindBugs propiamente dicha. 🙂

5.-Dandole caña al FindBugs

Ahora al pulsar botón derecho sobre cualquier contenido java (puede usarse findBugs en un proyecto, en un paquete java o en un fichero .java individual), aparece una opción para usar FindBug y extraer los bugs del código fuente.

Comienza la operación y al terminar, FindBugs nos ofrece una ventana con el cómputo de resultados y el tipo de este (errores, warnings, etc).

Resultado de búsqueda de FindBugs

Se nos ofrece también una opción de pasar a una vista FindBugs en el mismo Eclipse.
Además marca y especifica el tipo de error en una pestañana propia donde justifica el porqué de ese error.

Vista de FindBugs en Eclipse


6.-Opciones de configuración

FindBugs puede configurarse para adaptarse a las características que necesite el programador. Se configura pulsando con el botón derecho sobre un proyecto -> Propiedades -> FindBugs. Puede fijarse el nivel (bajo, medio, alto) de supervisión del código y activar/desactivar los tipos de errores que queremos observar. De igual forma, podemos configurarlo para que se ejecute en cada cambio realizado sobre un fichero java, automatizando su lanzamiento.

Configuración de FindBugs

7.- +Info

Página del proyecto FindBugs: http://findbugs.sourceforge.net/

Descarga del código: http://sourceforge.net/projects/findbugs/files/findbugs%20eclipse%20plugin/1.3.9/edu.umd.cs.findbugs.plugin.eclipse_1.3.9.20090821.zip/download

Manual: http://findbugs.sourceforge.net/manual/

Proyecto en googlecode para tutoriales de FindBugs: http://code.google.com/p/findbugs-tutorials/

Repositorio del código fuente de FindBugs: http://code.google.com/p/findbugs/source/browse/

Ampliando la información para el usuario: http://andrei.gmxhome.de/findbugs/index.html

Programación orientada a objetos (POO)-I: Introducción

marzo 24, 2010

En este apartado nos centraremos mas en el concepto de orientación a objetos, haciendo que resulte fácil e intuitivo.

La orientación a objetos consiste en un innovador paradigma de programación, que se basa, en síntesis, en modelar las situaciones, los componentes, las personas, y cualquier otro tipo de elemento, como un “objeto”.

Se considera que cualquier entidad puede tratarse como una unión de los conceptos en los que se basan los objetos: identidad + estado + comportamiento.

La identidad:

* Un objeto posee una identidad que caracteriza su propia existencia.
* Esta permite distinguir objetos de forma no ambigua (dos objetos diferentes con el mismo estado son distintos).
* Es un concepto abstracto sobre el objeto, no requiere ningún atributo.
* Equivaldría al DNI en las personas, a la matrícula de los coches, motos, etc.

El estado:

* Como la estructura interna de un objeto se define por un conjunto de atributos, el estado viene dado por los valores que toman esos atributos en un instante de tiempo.
* El estado cambia en el tiempo, al igual que un coche disminuye el combustible si se mueve, gasta sus neumáticos, etc.

El comportamiento:

* Agrupa todas las competencias del objeto, es decir, todo lo que puede hacer, sus acciones posibles y reacciones a tomar.
* Se describe mediante métodos, es decir, funciones que actúan como consecuencia de un impulso externo.

Así podemos ver que el estado y el comportamiento están relacionados: el comportamiento en un instante dado depende del estado actual, y el estado puede modificarse mediante el comportamiento (Así se empiezan a ver relaciones entre atributos y métodos en los objetos).

Espero que os guste este post introductorio, porque acabamos de empezar y vamos a llegar alto…

La EMEC a toro pasado

marzo 22, 2010

Hace ahora poco mas de dos semana se cerro en Málaga el evento EMEC [1]. Estas siglas son la abreviatura de “European Meeting and Events Conference” , lo que equivale a decir que durante varios días se han reunido en Málaga ni mas ni menos que lo mas fuerte de la industria del turismo de reuniones y congresos, los mayores expertos del sector a nivel europeo.

Es un buen momento para realizar a toro pasado una pequeña revisión sobre las vivencias del congreso. Viví el congreso de forma muy interesada, no iba a asistir personalmente pero conozco a varias personas que por el tipo de negocio que gestionan, requieren el estar presentes en encuentros de este tipo. Así que me busqué mis topos, me informé, localizé las ponencias, los contenidos, etc. Todo para ver algo que estaba intuyendo: que seguramente el software iba a ocupar un cierto lugar dentro de las sesiones.

Quería tener ese “feedback”, saber como se esta adecuando este sector de los negocios al desarrollo de nuevas tecnologías de comunicación, encuentro y reuniones. En general, este evento ha ido enfocado a realizar una evaluación del estado de esta industria en Europa en general y en el estado español en particular, el impacto económico de este tipo de negocio, pero también han tenido la lucidez (no todos los sectores industriales lo tienen) de ver por donde van los tiros en el mercado actual a corto y medio plazo, la integración progresiva con las nuevas tecnologías y como se van combinando en un momento en el que la situación económica global apuesta por reducir costes sobre este tipo de industria, sobretodo en algunos servicios concretos: ferias, viajes de incentivos, etc.

Además de dar forma a ideas nuevas, se han validado en este evento nuevas formas de negocio. En concreto han dado el pistoletazo de salida a conceptos como “e-meetings” es decir, a los encuentros que ocurren mediante herramientas digitales. Conscientes de que no puede darse la espalda al desarrollo tecnológico de una sociedad ni mucho menos luchar contra el, han decidido validarlo para comenzar a incluirlos en sus carteras de productos y servicios, no como un sustitutivo de las conferencias físicas y los encuentros entre personas, sino como un complemento a dichos eventos, integrado en el intercambio de ideas, experiencias y deseos.

El sector ha percibido que realmente no implica grandes costes, es altamente productivo, y muy eficaz. Así que poco a poco va madurando la opción de ofrecer una videoconferencia, organizar una charla, gestionar un debate o realizar un encuentro mediante este tipo de herramientas. Y con una inversión mucho mas reducida que traer personas desde muy lejos, alojarlas, mantenerlas, transportarlas, informarlas y prepararles una oferta de ocio en el lugar de destino. Todo ventajas.

Así que es posible que esto camine hacia delante con fuerza. Los profesionales del sector apuestan por su integración en el mercado, y hay herramientas disponibles muy maduras para desarrollos. Nosotros, los que apoyamos el software openSource, tenemos algunas herramientas para ofrecer a este segmento de mercado que nos mira con buena cara y ofrece expectativas de crecimiento: el proyecto openmeetings[2], la plataforma BigBlueButton[3] y DimDim[4] (en su edición openSource), son las tres principales que pueden servirnos para hacer llegar estos productos a nuevos clientes potenciales que ya han decidido en común apostar por los “e-meetings”. ¡A por ellos!

[1] http://www.mpiweb.org/Events/EMEC2010/home.aspx

[2] http://code.google.com/p/openmeetings/

[3] http://code.google.com/p/bigbluebutton/

[4] http://www.dimdim.com/community/opensource.html

Nota: si te suena este artículo, es que tal vez lo viste antes aqui:

http://universo.emergya.info/espacios/drodriguez/la-emec-toro-pasado

Sistemas de control de versiones-III: Un poco de historia

marzo 11, 2010

¡Hola amigos!, en este nuevo post, vamos a cambiar un poco el tercio.  Seguimos trabajando para adquirir una vista global sobre los sistemas de control de versiones, pero ahora, vamos a dar una visión sobre la historia de estos.

Para dinamizar un poco mas sobre el formato de los post, este de hoy me permito montarlo de una forma algo mas esquemática y gráfica. Espero que os guste y os resulte de interés.

Entrando un poco en harina, me gustaría ofrecer hoy un breve histórico sobre el control de versiones. Lo de histórico por hacer un poco de retrospectiva y ver la evolución de estos sistemas y breve porque realmente habría mil cosas que decir, que contar y muchos sistemas de los que hablar. He elegido los mas representativos, y preferentemente los sistemas openSource (salvo en el caso de TeamWare). Veamos la siguiente imágen, una cosita simple, hecha con el simpático Kivio…

visión de la historia del control de versiones

visión de la historia del control de versiones

Y ahora unas pinceladas sobre cada cual (prometo no enrollarme) 😉

[1] SCCS -> 1972.

Son las siglas de “Source Code Control System”, o sistema de control de código fuente. Fue desarrollado originalmente en los Laboratorios Bell en 1972 por Marc J. Rochkind.
Se considera el primer sistema de control de versiones oficial de la historia, ya que es la herramienta de control de versiones más antigua conocida. Sin rival hasta la llegada de RCS. SCCS basaba su gestión de las versiones en el procesamiento de ficheros individuales, además de cara a la concurencia, requería que cada uno de los desarrolladores del proyecto realizasen cambios en un momento determinado. Las versiones era protegidas mediante protecciones de seguridad a modo de bloqueo para el acceso del resto de desarrolladores, lo que originaba problemas de administración por olvido de retirar estos bloqueos.

http://en.wikipedia.org/wiki/Source_Code_Control_System

Haz clic para acceder a SCCS-Slideshow.pdf


http://sccs.berlios.de/

[2]RCS -> 1982.

Revision control system. Lanzado por en 1982 por Walter Tichy, un profesor alemán (entonces estudiante). Forma parte del proyecto GNU.  En principio se implementó como una alternativa gratuita a SCCS. Como en el caso de SCCS, RCS continuó con la misma problemática del acceso concurrente a los ficheros. Se trabajaba sobre un espacio compartido y se necesitaban bloqueos del fichero para impedir cambios concurrentes sobre el fichero.

http://en.wikipedia.org/wiki/Revision_Control_System
http://www.cs.purdue.edu/homes/trinkle/RCS/
http://www.gnu.org/software/rcs/rcs.html

[3]CVS -> 1986.

Concurrent versions system. Desarrollado por Dick Grune a mediados de los años ochenta. Este señor se basó en RCS para preparar esta versión “antigua” de CVS, creada a modo de un conjunto de scripts. Ya por fin un sistema de control de versiones permite a los desarrolladores trabajar simultaneamente de forma mas o menos independiente, pasando cada uno a trabajar sobre una copia del proyecto total que se iba sincronizando en el proyecto general.

Unos años mas tarde, en 1989, Brian Berliner cogió los scripts de Grune  y los reescribió en C, creando la versión moderna de CVS, ya con una arquitectura clara cliente-servidor. Así pasó a ser el sistema de control de versiones mas usado del mundo.

http://en.wikipedia.org/wiki/Concurrent_Versions_System
http://cvsbook.red-bean.com/
http://www.nongnu.org/cvs/

[4]TeamWare -> 1990

Sistema de control de versiones distribuido desarrollado a comienzos de los noventa Sun MicroSystems.  Al parecer se basa en la gestión de históricos a la manera de SCCS, pero con la diferencia de que cuenta con un número de características avanzadas que no se encuentran en los sistemas de control de versiones anteriores como RCS y CVS. En particular, se cuenta con una gestión de los fuentes algo mas avanzada que los anteriores, y permite actualizaciones atómicas de varios archivos, características que no aparecieron de forma madura hasta la llegada de Subversion.

http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare

[5]CVSNT -> 1998

Una versión de CVS enfocada a poder montar medianamente bien un servidor CVS en Windows.

http://en.wikipedia.org/wiki/CVSNT


…Continua en el siguiente post…

Sistemas de control de versiones-II: Justificación del uso

marzo 6, 2010
tags: ,

En este post quisiera dar el siguiente paso hacia una mejor comprensión de los conceptos básicos de los sistemas de control de versiones. Una vez sentadas unas pequeñas bases teóricas en el post anterior, para saber de que estamos hablando en este contexto, creo que debemos aproximarnos a la siguiente fase: muy bien, pero ¿Que gano al usar control de versiones?, una cuestión que apunta a:  ¿Por qué usar control de versiones?.

Pues bien, vamos a ver algunas razones para ello. De momento y de forma intuitiva, sin razonar demasiado se me ocurre lo siguiente:

Ubiquemos una empresa en su contexto. Toma materias, usa personal y genera un producto final. De alguna forma hay que proteger el producto final, durante todas sus fases dentro del proceso productivo. Desde el modelado de la materia prima hasta la salida al mercado, es lógico establecer algún control sobre los cambios realizados en el proceso.

Es normal entonces que en la naturaleza de este trabajo nuestro, vaya implícita la necesidad de salvaguardar lo mejor posible y con la mejor información nuestro software.

Tomemos dos ejemplos en contraposición, pero que marcan un punto de vista muy amplio sobre el uso de control de versiones:

Por un lado, empiezo a tirar lineas de código.

public class ClaseEjemplo{

private int valor ;

private String valorDevuelto;

Y de repente decido que ahora para la variable valor, no es suficiente con un tipo int (32 bits), necesito un tipo long (64 bits). Modifico el código de la clase:

public class ClaseEjemplo{

private long valor ;

private String valorDevuelto;

Y después de mucho tiempo programando cotejo los valores que voy a recibir y me doy cuenta que con int y 32 bits tenía suficiente. Como soy un tipo ahorrativo 🙂  quiero volver al caso inicial, donde la variable valor era de tipo int. ¿Que habría que hacer?

Bueno en este caso es trivial, por que realmente se trata solo de la asignación del tipo de una variable en una sola linea de código, pero imaginemos que el código a revertir fuese el de varias variables, o de una clase completa, o de una aplicación. Entonces el procedimiento sería encontrar ficheros de backup, localizar el archivo original y reemplazarlo o directamente reescribirlo. Realmente un proceso de trabajo sustancial. En cambio con un sistema de control de versiones solo tendríamos que decidir a que versión del código querriamos volver y ejecutar la acción, simple, ¿no?

Veamos un segundo ejemplo, este de tipo grupal. Un equipo de desarrolladores, tres o cuatro personas que desarrollan para el mismo proyecto. Necesitamos desplegar el proyecto, para lo cual tenemos que reunir todo el código de los cuatro y configurar la versión a desplegar del proyecto. A priori, necesitariamos:

Localizar ficheros de código de cada uno de los usuarios.

Consultar si se ha realizado alguna modificación en otros ficheros, y si las hay, actualizar ficheros.

Encontrar si algún desarrollador no ha tocado código que estuviese dentro de un módulo encargado a otro desarrollador, porque entonces habría que cohesionar el código, decidir con cual nos quedamos y fusionar las partes.

…y esto es solo por nombrar las mas importantes…

Si tuviesemos un VCS, entonces sería suficiente con ir a buscar al repositorio la última versión disponible (si es centralizado), o solicitar que se sincronicen los repositorios de cada desarrollador (si es distribuido). Un VCS eficaz alertaría de conflictos, nos daría una comparación y la posibilidad de realizar las fusiones que decidamos en el código.

Con estos dos casos, creo que se ilustra bastante bien el sentido del uso de los sistemas de control de versiones, pero por si acaso, vamos a enumerar de forma esquemática sus ventajas:

  1. Es una herramienta muy eficaz para el trabajo concurrente sobre un proyecto y permite manejar las diferencias entre múltiples versiones de su proyecto.
  2. Se puede llevar un registro del historial y de la evolución del proyecto. Por cada cambio, habrá un registro lo mas completo posible sobre el cambio realizado: quién lo hizo; por qué se hizo; cuándo se hizo; y de qué se trataba el cambio.
  3. Si se desarrolla en equipo, los sistemas de control de versiones facilitan la colaboración. Por ejemplo, cuando varias personas hacen cambios potencialmente incompatibles de forma casi simultánea, el programa le ayudará a identificar y resolver tales conflictos.
  4. Un VCS puede ser muy util en la corrección de errores. Si aplica un cambio que posteriormente se evidencia como un error, puede revertirlo a una versión previa a uno o muchos ficheros. De hecho, una herramienta realmente buena, incluso puede ayudarle efectivamente a darse cuenta exactamente cuándo se introdujo el error.

Así que creo que con todo este contenido de hoy puede justificarse sobradamente el uso de control de versiones.

¡Un saludo y hasta el próximo post!

Sistemas de control de versiones-I: Una introducción

marzo 3, 2010
tags: , ,

Quiero ir organizando un poco toda la información que manejo en torno a los sistemas de control de versiones, y poder unirla a mi experiencia personal, para formar un corpus formativo útil para quienes deseen formarse en estas materias.

Pero como es normal, antes de la implementación, me gustaría pasar por la especificación, 😛 quiero decir que primero habremos de sentar las bases teóricas mas importantes sobre la materia. He aprendido que, si los conceptos no estan claros, o la lógica o la secuencia de trabajo no esta bien madurada, la problemática resurge de nuevo. No cabe, bajo mi punto de vista comenzar desde tal sistema o este otro, sino mas bien empezar sentando las bases de lo que ha de ser la teoría de un sistema de control de versiones.

Para comenzar, vamos a definir términos necesarios ya desde el inicio:

Repositorio:

Como su propio nombre indica, es un lugar donde se guarda algo, donde se almacenan cosas. En el contexto informático, un repositorio es un lugar centralizado donde se puede almacenar -esto es, donde se accede, se guardan, se extraen, se consultan- elementos software. Los elementos software almacenados pueden ser, por ejemplo, los propios de bases de datos, código fuente de aplicaciones, paquetes de software para sistemas Unix, entre muchos formatos.

En general, los repositorios suelen contar con algunas medidas que los diferencia de simples dispositivos de almacenamiento. Es normal que cuenten con sistemas de Backup para copias de seguridad, que también dispongan de herramientas para el mantenimiento preventivo y correctivo, todo ello de cara a establecer medidas para que la información digital que almacenemos allí quede protegida y/o sea recuperable, formando un contexto seguro de almacenamiento.

Control de versiones:

En el ámbito de la informática, un control de versiones es un conjunto de medidas propicias a gestionar de la mejor forma correcta una versión, una revisión o simplemente la edición de la versión  uno de nuestros productos, gestionando (accediendo, consultando, informando, y modificando)  el estado en el que se encuentra en un momento dado nuestro producto software o simplemente nuestro proyecto.

Lo mas importante en el control de versiones es que implementen mecanismos lo mas eficientes posibles para la gestión de cambios, es decir, que tenga la capacidad de estructurar adecuadamente el histórico de cambios de un proyecto, las modificaciones y de información adecuada (desde que el software sea coherente, a información contextual, a metainformación) de cada fase.

Sistema de control de versiones:

Pues enlazando conceptos, un sistema para el control de versiones, así, de forma intuitiva, es una herramienta que permite gestionar las versiones por las que pasa un proyecto, e ir haciendo seguimiento de todos los pasos dados en el desarrollo o almacenamiento de nuestros archivos digitales.

Por definir un poco mejor, diremos que se pueden establecer dos tipos fundamentales: los distribuidos y los centralizados.

Los distribuidos: Representa un cierto cambio de mentalidad sobre el concepto de control de versiones.  Se suelen estructurar como un sistema de ficheros distribuidos, que puede tener (o no) un nodo central a modo de repositorio. Por decirlo de alguna forma, cada usuario en un momento determinado establece su “propio repositorio” (su clon), y cuando lo decida, establece la sincronización con el repositorio de cada usuario restante. Los mas conocidos son Git, Baazar y Mercurial.

Los centralizados: Un sistema de control de versiones centralizado es una estructura que establece un nodo central para albergar todo el código que esta a disposición de todos los usuarios. Se almacena en un único directorio, normalmente alojado en un servidor, y todos los desarrolladores que trabajen sobre ese código deben pedirle al servidor una copia para el trabajo local.

Estos establecen sus modificaciones, ya sean cambios, inclusiones o exclusiones sobre su copia local, y al final exportan sus copias locales al servidor, resolviendo las diferencias que pueda haber entre copia local y copia de servidor.

Los sistemas de control de versiones openSource más conocidos son CVS y Subversion.

+Info introductoria:

http://es.wikipedia.org/wiki/Control_de_versiones

http://www.chuidiang.com/chuwiki/index.php?title=Sistema_de_control_de_versiones



El ciclo de vida de un producto

febrero 24, 2010

El ciclo de vida de un producto o CVP, es un concepto que establece una serie de etapas o fases que deberían seguirse a la hora de desarrollar un producto software.

En definiciones de normas de organizaciones internacionales: “Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software” IEEE 1074

“Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso” ISO 12207-1

Se establecen un ciclo de siete etapas que son:

1.-Análisis: Proceso de investigación del problema a resolver con el producto software. En esta fase se define el alcance del problema, el universo de este, los usuarios del producto, sus roles, los límites, en definitiva, que requisitos se establecen de cara a la creación del producto.

2.-Diseño: En este proceso se aportan soluciones teóricas para la problemática encontrada en la fase de análisis, es decir, se plantea de que forma van a afrontarse los requisitos que ha de cumplir nuestro producto. Se define la tecnología a usar, se concretan los requisitos en módulos funcionales, en subcomponentes y se organizan las tareas a realizar.

3.-Desarrollo: La fase de desarrollo consiste en crear el código necesario que ha quedado establecido en la etapa anterior, se desarrolla en base a los esquemas proporcionados por la fase de diseño del sistema.

4.-Prueba: La fase de prueba tiene como objetivo la realización de test sobre el producto, para llegar a dar repuesta a nuestro compromiso al cliente de que sus requisitos se verán satisfechos por nuestro producto. Es la fase para comprobar que tanto los componentes como el sistema general cumplen los requisitos para los que fueron diseñados. Idealmente, deberían trabajar en este apartados personas al margen de todo el proceso de codificación del producto.

5.-Implementación: Etapa en la que se configura el producto para que pueda ser entregado y totalmente disponible y usable a nuestro cliente. También conocida en castellano como “la primera entrega al cliente” o “First Customer Ship” (FCS).

6.-Mantenimiento: En esta parte nos haremos cargo de aquellos problemas surgidos de cara al producto, preparar nuevas versiones con reparaciones de bugs o establecer acciones correctoras sobre deficits del producto.

7.-Fin de vida: Es la sección del ciclo en la que se establece el final del producto como tal en su versión actual, y se prepara al cliente y al mercado para la concienciación de que no habrá soporte para el producto tal cual lo conocian, preparando el lanzamiento de una nueva versión o un nuevo producto que ataque a los mismos requisitos.

Establecer el dominio del problema en las primeras fases de forma correcta es fundamental. Para ello se establece la elicitación u obtención de requisitos de las necesidades del cliente, y escribiendo una declaración de alcance que describa brevemente lo que el desarrollador debe resolver.

Historia de Java -IV: Nace Java

febrero 20, 2010

Mientras se desmantela FirstPerson, la NCSA (National Center for Supercomputing Applications) liberaba Mosaic, una aplicación que permitía a los usuarios acceder a Internet de forma gráfica, pudiendo acceder a cientos de sitios de Internet en la World Wide Web. El número de sitios web crecía día a día e Internet comenzaba a convertirse en un fenómeno.

En Junio de 94 Joy comienza el proyecto “Live Oak” con el objetivo de usar Oak para construir un “pequeño gran sistema operativo” y estudiar las posibilidades de negocio de Internet. Mientras Arthur van Hoff implementa el compilador de Oak en lenguaje Oak, reemplazando la versión de Gosling que se había escrito en C, Naughton y Jonathon Payne comienzan a escribir un navegador web similar a Mosaic escrito en Java, “WebRunner” (por la película Blade Runner) al que después se llamaría “HotJava”.

El 29 de Septiembre de 1994 se termina el desarrollo del prototipo de HotJava. Cuando se hace la demostración a los ejecutivos de Sun, esta vez, se reconoce el potencial de Java y se acepta el proyecto.

El 23 Mayo de 1995, en la conferencia SunWorld ’95, John Gage, de Sun Microsystems, y Marc Andreessen, cofundador y vicepresidente de Netscape, anunciaban la versión alpha de Java, que en ese momento solo corría en Solaris, y el hecho de que Java iba a ser incorporado en Netscape Navigator, el navegador mas utilizado de Internet.

Con la segunda alfa de Java en Julio, se añade el soporte para Windows NT y en la tercera, en Agosto, para Windows 95. En Enero de 1996, Sun crea JavaSoft para desarrollar la nueva tecnología y ese mismo mes aparece la versión 1.0 del JDK.

Pequeñas epifanías diarias

febrero 13, 2010

Hay ocasiones en los que una acción sencilla y rutinaria, da lugar a una situación casual que no nos esperábamos, pero que de alguna forma coincide con una necesidad o una situación en la que andamos inmersos. Y entonces decimos “¡Anda, coño!” y vivimos una pequeña epifanía personal y momentanea.

Metiéndome en harina, me dejaron en las manos un libro de temas clínicos, en concreto sobre clasificación de intervenciones de enfermería, que viene a ser algo así como un gran registro de protocolos de actuación para situaciones y objetivos determinados. Por lo que me habían explicado, venía a usarse cuando, ante una situación determinada, una vez concretado que demonios tenías delante se acudía a este tipo de libros para ubicar la situación y leer, a modo de “algoritmo”, el proceso de intervención en el caso.

Abrí el libro al azar, y fuí a dar (doy mi palabra) con algo que me interesa bastante y tiene mucho que ver con mi trayectoria personal: el trabajo y la gestión de grupos y equipos.

El epígrafe en particular, tenía como objetivo el definir como facilitar la administración de cuidados de alta calidad al paciente por parte de otras personas. ¿Y que?, ¿Que tendrá eso que ver con nosotros?, ¿Con el software?, ¿Con los equipos de personas?, ¿Con Eclipse?…

Pues allá van algunas ideas de las mas interesantes sobre este tema. Las anotaciones son mias, no pude evitar enriquecer mi lectura con notas al margen, ya que hubo muchas que me parecieron muy útiles para la vida diaria y el trabajo en equipo, de cara a mejorar los procesos. Tal vez a algún otro chiflado puedan interesarle:

  • Crear un ambiente de trabajo que valide la importancia de cada empleado para la organización. → Fundamental en todos los aspectos posibles, pero una importancia subrayada lo mas completa, sin parcialidades y que sea sincera en fondo y forma.
  • Reconocer las areas de dominio técnico del empleado. → Importante a varios niveles, permite establecer la ubicación de cara a los roles explicítos e implicítos, y la relación con la estructura.
  • Fomentar las comunicaciones francas → Es muy importante establecer una comunicación “oficial” clara y franca, con canales fiables, ya que, entre otras cosas, evita la aparición de canales alternativos, e información que no llega donde debería. La ausencia de este apartado incide directamente en el decremento de la confianza.
  • Determinar las oportunidades de participación en la toma de decisiones. → Clarificar, quien decide, sobre que proceso, de que forma y que se busca en la decisión.
  • Proporcionar una descripción del trabajo a todos los empleados nuevos. → Muy importante el ubicar a las personas, contextualizándolas con aquello que se espera de ellas, de su puesto, de sus tareas.
  • Compartir los métodos de evaluación utilizados con el empleado. → Normalmente las personas sueren tener interés en saber como se les evalua, que criterios se tienen en cuenta, el porque si o porque no de una decisión de evaluación externa.
  • Transmitir al equipo un sentido de propósito para el grupo de trabajo. → Potencia la unión, el sentido de la lucha conjunta, y según de que forma se plantee, puede ayudar a construir la cultura común del equipo, fundamental en su proceso de maduración.
  • Considerar el crecimiento del empleado en la asignación de tareas. → El crecimiento personal, la resolución de metas y/o ambiciones, la sensación de evolución, son motores motivacionales en la vida diaria.
  • Compartir información acerca de la organización y los planes futuros. → Resumiendo: información, información y mas informacón. Sincera, ágil, directa, abierta, de calidad, bidireccional. Información.
  • Escuchar las inquietudes y sugerencias de los empleados. → En el contexto de comunicaciones francas, sin que la transmisión de información personal se presuponga un handicap al desarrollo evolutivo personal.
  • Proporcionar formación continuada, si es necesario, para mejorar su rendimiento. → Para crecer, para avanzar, para ser mas eficaz, mas formación.

¿Que decir?, bueno realmente no es una información exclusiva del entorno clínico, ni mucho menos, pero me ha hecho sonreir el hecho de, que en contextos diferentes, en realidad, las bases de la investigación sobre la vida de los equipos sean las mismas. Además, me encanta relacionar temas que aparentemente no tienen nada que ver :). Espero que alguien disfrute de la lectura y la reflexión.

Un abrazo a tod@s.

La arquitectura de tres capas: Introducción

febrero 8, 2010

En el post de hoy quisiera entrar a un tema que nos queda cerca a aquellas personas que curramos a diario con aplicaciones web y programamos día a día en esa dirección.

En concreto, la programación por capas es una forma de programar bajo un objetivo principal: que las distintas lógicas presentes en la aplicación se separen y posean estructuras bien planteadas.

En general, suele plantearse esta visión sobre tres niveles o capas:

1.-La capa de presentación:  Esta capa se encarga de proveer una interfaz entre el sistema y el usuario. Basicamente, se responsabiliza de que se le comunique información al usuario por parte del sistema y viceversa, manteniendo una comunicación exclusiva con la capa de negocio que veremos a continuación.  Además dentro de esta capa entraría aquello que el usuario “ve” cuando se conecta a la aplicación.

2.-La capa de negocio: Es la capa que contiene los procesos a realizar con la información recibida desde la capa de presentación, las peticiones que el usuario ha realizado, y responsabilizadose de que se le envíen las respuestas adecuadas a la capa de presentación.
Podríamos verla como una capa intermedia, a medio camino entre la capa de presentación y la capa de datos, puesto que se relaciona con ambas y por supesto, procesa también la información devuelta por la capa de datos.

3.-La capa de datos: Por último, la capa donde se almacenan los datos. Mediante la capa de negocio, se puede encargar de ofrecer, modificar, almacenar, borrar y recuperar datos, mediante el gestor (o los gestores) de bases de datos que la aplicación requiera.

La técnica de programación en tres capas es óptima de cara a conseguir la mejor calidad acoplamiento-cohesión. ¿Que establece esta relación?

La cohesión es el parámetro que valora la facilidad con la que en una aplicación es posible reunir componentes o subsistemas en un sistema software mayor.

El acoplamiento es el parámetro responsable de evaluar las relaciones que se establecen entre partes, componentes o subsistemas de un sistema software mayor, de tal  forma que un nivel bajo de acoplamiento permitiría la reutilización de código existente en otro contexto, o reaprovechar funcionalidades ya definidas o modificadas, siendo negativo en caso contrario.

Como resumen de lo anterior, podemos asumir que ambos parámetros van encaminados a estructurar una relación ordenada entre las distintas capas y asegurarnos que se implementan con la mejor autonomía posible entre ellas. Podriamos asumir también que lo ideal es plantear un sistema donde se produzca un bajo acoplamiento y una alta cohesión entre sus partes.

“Confusiones” sobre el concepto de software libre

febrero 3, 2010

“Si lo del software libre se entiende como software gratuito, creo que en Microsoft y en otras compañías, se ofrece software que se puede utilizar de manera gratuita”

Ideas manipuladas e ideas tergiversadas por ladirectora de Microsoft Ibérica, en el programa ‘En días como hoy’ de RNE.

Ha sido una cuestión malintencionada, ella ha de saber que el software openSource  es software libre, pero no es una cuestión de gratuidad exclusivamente.

Aqui esta el enlace a la entrevista:

http://www.rtve.es/mediateca/audios/20100202/maria-garana-innovacion-tecnologica-espana-dias-como-hoy/682978.shtml

Tales ejemplos de manipulación de la información y los conceptos son ciertamente falaces y demuestran la verdadera naturaleza de este tipo de directivos.

Por si alguien tiene alguna duda, el software libre ha de ser un software que cumpla las siguientes libertades:

0.-Libertad de usar el programa para cualquier fin.

1.-Libertad de estudiar el programa y modificarlo para adaptarlo a tus necesidades (implicando acceso al código fuente).

2.-Libertad de distribuir copias del programa a quien decidas.

3.-Libertad de mejorar el código del programa y publicar esos cambios de cara a la comunidad (implicando acceso al código fuente).

Estas, y no otras, son las ideas en las que se basa el software libre. Que no quepa duda alguna sobre ello. Que no nos confundan.

La montaña y el trabajo en equipo

enero 12, 2010

La montaña, tierras altas de Escocia Desde pequeño, he vivido y crecido en entornos donde se potenciaba mucho el contacto con la naturaleza y el medio ambiente. Desde mi familia hasta las asociaciones por las que he pasado, en todos estos sitios se me ha inculcado un concepto que ha resultado para mi de los mas importantes aprendizajes en mi vida personal: la montaña.

Pero en concreto, quiero hacer una lectura sobre esto más relacionada con un concepto muy en boga actualmente: el trabajo en equipo, sobretodo cuando cada vez más se considera parte activa del éxito de una empresa y cada vez más se va instalando en la cultura interna del mundo empresarial.

Existe en el mundo del deporte de la montaña toda una cultura propia de elementos, detalles y componentes de gran utilidad para el desarrollo de dinámicas de grupos y técnicas de trabajo en equipo.

Desde mi experiencia, siempre he pensado que la montaña era la mejor metáfora sobre la vida en cuanto que representa aspectos muy reales sobre el desarrollo personal que hacemos en nuestra vida: objetivos, métodos de ataque hacia estos, retos, dificultades, problemática asociada, sacrificio y esfuerzo en aras de objetivos y trabajo en equipo. Esta es para mi una de las claves mas importantes: el trabajo en equipo.

Porque puede haber grupo donde no hay equipo, y equipo donde hay grupo. Entiendo el concepto de equipo como una entidad mayor donde se han establecido diversos aspectos fundacionales de la identidad del mismo: objetivos comunes, métodos consensuados, liderazgo y una fuerte cohesión. En la montaña, con algo de observación, podemos contemplar como se manifiestan aquellas conductas, tanto positivas o negativas de cara a la salud del equipo.

A nivel de liderazgo, podemos observar que tipo de liderazgo de establece, si este es de corte autoritario, democrático, asertivo, etc.

A nivel de conducta, se observan en los componentes el egoismo, el indivualismo, la asertividad, el respeto a los demás, la capacidad de superación, la empatía  y todos aquellos aspectos de la convivencia que un medio algo hostil hace aflorar.

Asimismo, podemos observar como concentradamente (en cuanto a tiempo, espacio e intensidad) se desarrollan los aspectos mas vitales para el ciclo de vida del equipo:

  1. La creación de una cultura de equipo propia, basada en un anecdotario común y concreto.
  2. La definición de los objetivos comunes, explícitos e implícitos, que han de abordar los miembros en conjunto.
  3. La creación de una metodología: como vamos a conseguir el objetivo.
  4. La creación de métodos de evaluación para ver de que forma y con que calidad hemos resuelto los planteamientos.
Montañas suizas

En la montaña se establece un caldo de cultivo inmejorable (bajo mi punto de vista) para desarrollar y evaluar el nivel de madurez de un grupo. Es posible ver muy claramente la estructura de roles que se crean (sin confundir posición de poder, rol y estructura). Es sencillo diferenciar al “sacerdote” (o quien se encarga de mantener la ortodoxia de los métodos), el “héroe” (que encarna todos los valores positivos de la entidad), el “padre” (persona que transmite directrices), solo por citar algunos clásicos en los niveles básicos de roles dentro de un grupo cualquiera.

Pero incluso se visualizan aspectos mucho mas allá: Quien no se detiene a ayudar al compañero (o viceversa), quien esta dispuesto a arriesgar al grupo por la búsqueda de un prestigio personal de liderazgo (y en el caso contrario), quien al comer se sirve el último cuando ya todos estan servidos. Toda una verdadera riqueza de detalles que permiten a alguien con cierta observación extraer un conjunto de ideas sobre los que realizar inferencias del comportamiento del individuo en el contexto de un equipo.

De mi experiencia en ese sentido he de decir que no he conocido mejor a alguien (para bien y para mal) que cuando hemos compartido una montaña, y que además, en el cien por cien de los casos las conductas observadas por mi o por el resto del equipo, han coincidido con las conductas demostradas fuera del campo de actuación de la ascensión de un pico.

De cualquier forma no hay que confundir tampoco al grupo con el equipo. Tal vez para un grupo no necesitemos ser tan ambiciosos, en el sentido que el grupo va a implicar una respuesta individual, frente a la colectiva del equipo, un reparto de tareas mas sencillo en lugar de uno mas integral para el equipo, y al final y determinantemente, de una cultura común cohesionadora mucho mas débil que en el caso del equipo.

En muchas ocasiones, no esta justificada la creación de un equipo, con un grupo es suficiente. Bajo mi punto de vista, solo la búsqueda de las cinco “c”  justifica el esfuerzo en tiempo y recursos para afrontar el proceso de creación de un equipo:

  1. Complementariedad.
  2. Coordinación.
  3. Comunicación.
  4. Confianza.
  5. Compromiso.

Todo ello se da en este sano y recomendable deporte, pero sin duda, y volviendo a mezclar lo emocional con lo analítico, la experiencia en la montaña es una de las mas puras que vivo en mi vida:

  • La montaña enseña que los problemas no son dificultades, sino retos a superar.
  • La montaña enseña a depositar toda tu confianza en tus compañer@s, y a asumir la responsabilidad que supone el que la depositen en ti.
  • La montaña enseña a ejercer un liderazgo responsable, maduro y preparado para escuchar a los compañer@s.
  • La montaña enseña que hay objetivos que requieren de un esfuerzo considerable, que hay que luchar por las cosas que se quieren, y va inculcándonos una suprema cultura del esfuerzo personal.
  • La montaña enseña que el verdadero placer no esta en la consecución del objetivo sin mas, sino en el camino hacia el, rico en aprendizaje.

En definitiva, hoy quería reflexionar sobre todo ello y relacionarlo con un campo que nos queda cerca: el mundo de los equipos. Yo, si de mi dependiera, saldría a la montaña con todos aquellos equipos en los que formase parte.

¡Un saludo y buena caza!


					

Historia de Java III: El proyecto FirstPerson

enero 5, 2010

En Agosto del 91 Oak ya corría sus primeros programas. El equipo trabajaba en un prototipo llamado Star7 (*7), un dispositivo parecido a una PDA, cuyo nombre venía de la combinación de teclas del teléfono de la oficina del Proyecto Green que permitía a los usuarios responder al teléfono desde cualquier lugar.

Después de mostrar a Scott McNealy y Bill Joy los prototipos de bajo nivel del sistema, continúan con el desarrollo, incluyendo su sistema operativo, Green OS; el lenguaje Oak, las librerias, alguna aplicación básica y el hardware, hasta que el 3 de Septiembre de 1992 se termina el desarrollo y con ello el Proyecto Green.

En la demostración para McNealy y Joy, aparecía un personaje creado por Joe Palrang que terminaría por convertirse en la mascota de Java, Duke.

Después de la demostración se decide crear una nueva empresa filial de Sun, FirstPerson, con sede en Palo Alto, para comercializar la nueva tecnología. Wayne Rosing, ex-jefe de Naughton en el grupo de trabajo de NeWs se une al proyecto desde SunLabs, asumiendo la dirección del equipo y de la nueva empresa.

Ahora que ya habían creado *7, quedaba la cuestión de qué hacer con él. El que había sido el mercado objetivo durante la concepción de *7, la electrónica de consumo, resultó no querer saber nada del nuevo producto porque disparaba los precios de los nuevos dispositivos. FirstPerson pasa de un desastre a otro sin encontrar un verdadero plan de negocio. El 15 de Marzo de 1993 Time Warner lanza un RFP (Request for Proposal) buscando una tecnologia para televisión por cable interactiva. FirstPerson se fija como nuevo objetivo el desarrollo de un sistema operativo para Time-Warner, pero cuando llega la hora de la verdad Time-Warner se decantanta por GDI, aún reconociendo que la tecnología de Sun era superior.

Tras el varapalo de Time-Warner se intenta vender *7 a 3DO pero después de meses de reuniones las negociaciones no llegan a buen puerto al exigir 3DO los derechos exclusivos de la tecnología. Como último recurso se presenta como alternativa a los ejecutivos de Sun el desarrollo de una plataforma de CD-ROMs multimedia basada en Oak pero la respuesta de estos no es favorable y se desmantela FirstPerson.

Reflexiones sobre nosotr@s

diciembre 29, 2009

A veces, creo que en esto del software libre falta algo mas de didáctica a la hora de divugar, pero en realidad lo observo en multitud de aspectos en la comunicación y la compartición del conocimiento. Es como si de alguna forma, y salvo excepciones, faltasen habilidades a la hora del trato con las personas, de explicar cosas, en definitiva, de hacer llegar a los demás la experiencias que ya tenemos.

Y en el fondo, la mejor manera de hacer llegar esta filosofía es comunicando bien y sobretodo poniendonos en el lugar de quien nos esta hablando, reflejando una duda, cuestionando algún aspecto u ofreciendonos un argumento de debate.

Comunicar bien es explicar bien, concretamente y de forma constructiva, pero también es escuchar. Realizar una verdadera escucha asertiva, equilibrada, en la que los interlocutores puedan comprenderse mutuamente y tener la agilidad suficiente como para situarse en la posición del otro y entender su mensaje (la cosa de la empatía).

Los creadores de proyectos de SL crean y administran listas de correos en las que no resuelven dudas por encima de ciertas trivialidades, en muchas comunidades se machaca, bien mediante la ironía o bien mediante el silencio al usuario que viene cuestionando algo o simplemente planteando una duda que al resto le parece trivial.  En ocasiones resultamos algo talibanes, radicales sin sensibilidad suficiente a la hora de responder a los demás, con lo que las personas se retraen a la hora de plantearnos mas cuestiones.  A veces casi nadie parece tener la mezcla suficiente de paciencia y capacidad didáctica necesaria para hacer llegar el conocimiento al usuario lego en la materia.

Y así, perdemos batallas, por que no las hacemos nuestras en el sentido de que grandes personas con altos, medios o bajos niveles de conocimiento no son suficiente habilidosos para transmitirlo, para motivar a los demás, para hacer de su experiencia un motor de cambio con el que aspirar a cambiar esta sociedad. Y la batalla perdida es la que no se hace.

Yo no quiero asumir que el SL solo sea un intento de colocar un ego personal y un afan de destacar mediante colaboraciones. Para mi esta cargado de la suficiente épica, de una verdadera carga histórica, de un avance de trascendencia en el modelo de relaciones de la sociedad y del acceso al conocimiento.

Y todos los que estemos sensibles a querer cambiar el mundo, a aquellos disconformes con el devenir de las estructuras sociales, que somos observadores críticos de las injusticias diarias, tenemos, sin duda, una oportunidad de mostrar nuestra posición a través del Software Libre. Al menos, es lo que intento transmitir a aquellos que me rodean, personas que aspiran al conflicto como motor de cambio.

Y con estas reflexiones me voy a la cama. Un abrazo a tod@s. Buenas noches.

Seleccionando cinco comandos

diciembre 28, 2009

Estaba el otro día meditando sobre el uso que hago actualmente de mi sistema operativo y se me ocurrió reunir en un post aquellos comandos que, por alguna razón u otra, estan ultimamente en mi dia a dia. Hay muchos mas e incluso algunos usados con mas frecuencia, pero he elegido estos por pura simpatía. Sin talibanismo, sin acritud, y con mucho sentido del humor alla van:

VIM: El comando del editor gráfico consolero mas potente que he probado. Tiene una curvilla de aprendizaje curiosa pero es bastante gracioso.

Lo suelo usar para crear y editar achivos, modificar cadenas de ficheros properties y programar código java en ficheros .java. Incluso los uso para cotejar versiones de ficheros con la utilidad diff.

sudo vim /etc/init.d/openoffice

Este caso en concreto fue la última vez que lo use, para editar un script de arranque de un servicio que me esta dando algunos dolores de cabeza debido a temas de fichero .pid

+info:

El sitio web del bicho:

http://www.vim.org/

Un poco de teoría en castellano:

http://es.wikipedia.org/wiki/Vim

Una introducción suavecita:

http://www.emezeta.com/articulos/manual-para-aprender-a-utilizar-vim

Una chuleta para usar a diario:

http://tnerual.eriogerg.free.fr/vimqrc-es.html

SCP: Es un comando que permite copiar ficheros entre dos máquinas. Usa ssh para transmitir información y es tan seguro como el mismo ssh. Usa los métodos de auntenticación y la parametrización de ssh.

scp -P 8893 /home/ruta del archivo/fichero usuario@maquina.remota: home/destino

(parametrizado con el puerto 8893)

Yo lo uso para paso de ficheros a máquinas remotas . Es un comando bastante potente que permite una parametrización muy rigurosa en cuanto a puertos a usar, protocolos, permisos, e incluso ancho de banda para la operación de copia.

+info:

Definición teórica en castellano:

http://es.wikipedia.org/wiki/SCP

Sitio Man del comando:

http://linux.die.net/man/1/scp

Ejemplos en la sintaxis del comando:

http://www.hypexr.org/linux_scp_help.php

SVN: comando para manejar el sistema de control de versiones Subversion. Es una utilidad muy potente que se maneja con sus propios subcomandos. Lo uso, logicamente, para el control de versiones de los proyectos. Hacer chekouts de proyectos, actualizar copias locales, modficr código y subir contenido, comprobar el estado del proyecto, realizar merge de contenido, revertir cambios y versiones, etc.

En concreto, haciendo cosas como:

svn commit -m “Documentación de usuario” –username nombre

El detalle del parámetro –username es importante de cara a reflejar que usuario hace el commit. Si no, por defecto, se almacena el primer usuario que accedió y esa información no es real. 😉

+info:

El svn book:

http://svnbook.red-bean.com/nightly/en/index.html

Una referencia, asi, básica con ejemplillos:

http://blog.jorgeivanmeza.com/2008/10/comandos-basicos-de-svn

Una guía rápida:

http://chernando.eu/doc/svn/

MYSQLDUMP: es el comando que estoy usando ultimamente para copias de seguridad de mis bases de datos. Lo uso para asegurar los datos antes cambios entre entornos de desarrollo y pre-producción.

A usar dentro del interprete de mysql:

mysql> mysqldump –add-drop-table -u root -p nombredelabasededatos >/home/ruta/nombredelfichero.sql

y se extrae un fichero de extensión .sql con todos los datos existentes en la base de datos.

+info:

referencia mysqldump en el sitio de mysql:

http://dev.mysql.com/doc/refman/5.0/es/mysqldump.html

Introducción sencilla:

http://www.desarrolloweb.com/articulos/1202.php

HISTORY: Este es el comando de después de las vacaciones. Vuelves, te pones delante de la máquina y dices ¿Como estaba yo haciendo esto?, ¿Que comandos use?

Pues nada:

history |grep ssh

…y ver el listado de acciones que existen asociadas al comando.

Si buscas un número concreto de acciones, puedes poner:

history 30 (con las 30 últimas acciones).

+info:

Como configurar bashrc para que history muestre además fecha y hora:

http://mfernandez.es/wordpress/2009/08/18/history-con-fecha-y-hora/

¡Que ustedes lo disfruten!

Historia de Java II: La relación con C++

diciembre 26, 2009

El lenguaje C++ fue un intento de tomar los principios comentados en el  post anterior y emplearlos dentro de las restricciones de C. Todos los compiladores de C++ eran capaces de compilar programas de C sin clases, es decir, un lenguaje capaz de interpretar dos estilos diferentes de programación. Esta compatibilidad (“hacia atrás”) que habitualmente se vende como una característica de C++ es precisamente su punto más débil.

No es necesario utilizar un diseño orientado a objetos para programar en C++, razón por la que muchas veces las aplicaciones en este lenguaje no son realmente orientadas al objeto, perdiendo así los beneficios que este paradigma aporta. Así Java utiliza convenciones casi idénticas para declaración de variables, paso de parámetros, y demás, pero sólo considera las partes de C++ que no estaban ya en C.

Las principales características que Java no hereda de C++ son:

1.-Punteros: Las direcciones de memoria son la característica más poderosa de C++. El inadecuado uso de los punteros provoca la mayoría de los errores de colisión de memoria, errores muy difíciles de detectar. Además, casi todos los virus que se han escrito aprovechan la capacidad de un programa para acceder a la memoria volátil (RAM) utilizando punteros. En Java, no existen punteros, evitando el acceso directo a la memoria volátil.
2.-Variables globales: Con ellas cualquier función puede producir efectos laterales, e incluso se pueden producir fallos catastróficos cuando algún otro método cambia el estado de la variable global necesaria para la realización de otros procesos. En Java lo único global es el nombre de las clases.
3.- goto: Manera rápida de arreglar un programa sin estructurar el código. Java no tiene ninguna sentencia goto. Sin embargo Java tiene las sentencias break y continue que cubren los casos importantes de goto.
4.-Asignación de memoria: La función malloc de C, asigna un número especificado de bytes de memoria devolviendo la dirección de ese bloque. La función free devuelve un bloque asignado al sistema para que lo utilice. Si se olvida de llamar a free para liberar un bloque de memoria, se están limitando los recursos del sistema, ralentizando progresivamente los programas.

Si por el contrario se hace un free sobre un puntero ya liberado, puede ocurrir cualquier cosa. Más tarde C++ añadió new y delete, que se usan de forma similar, siendo todavía el programador, el responsable de liberar el espacio de memoria. Java no tiene funciones malloc ni free. Se utiliza el operador new para asignar un espacio de memoria a un objeto en el montículo de memoria. Con new no se obtiene una dirección de memoria sino un descriptor al objeto del montículo. La memoria real asignada a ese objeto se puede mover a la vez que el programa se ejecuta, pero sin tener que preocuparse de ello.

Cuando no tenga ninguna referencia de ningún objeto, la memoria ocupada estará disponible para que la reutilice el resto del sistema sin tener que llamar a free o delete. A esto se le llama recogida de basura. El recolector de basura se ejecuta siempre que el sistema esté libre, o cuando una asignación solicitada no encuentre asignación suficiente.
5.- Conversión de tipos insegura: Los moldeados de tipo (type casting) son un mecanismo poderoso de C y C++ que permite cambiar el tipo de un puntero. Esto requiere extremada precaución puesto que no hay nada previsto para detectar si la conversión es correcta en tiempo de ejecución. En Java se puede hacer una comprobación en tiempo de ejecución de la compatibilidad de tipos y emitir una excepción cuando falla.

Historia de Java

diciembre 23, 2009

En Diciembre de 1990 un ingeniero de Sun llamado Patrick Naughton enviaba un correo electrónico a Scott McNealy, CEO de Sun Microsystems, explicándole las razones de su marcha para trabajar en NeXT, una empresa fundada por Steve Jobs después de “renunciar” en Apple, cuyo objetivo era crear el computador perfecto, y que mas tarde sería comprada por Apple junto con el sistema operativo desarrollado, NeXT Step, para crear su nuevo sistema operativo.

Naughton era jefe de proyecto de la sección gráfica en un grupo dedicado a unir NeWS (Networked/extensible Window System), un sistema de ventanas de Sun inventado por James Gosling y basado en PostScript, con X11 (X window System versión 11), lo cual significaba que tenían que soportar “tres toolkits, tres sistemas de ventanas, tres arquitecturas hardware diferentes, dos interfaces de usuario y dos versiones de sistemas operativos diferentes”.

Como respuesta, Bill Joy le ofrece continuar en Sun trabajando en algo nuevo, uniéndose a un nuevo grupo para desarrollar una nueva tecnología. Un grupo con total autonomía respecto de la línea directiva de Sun y completamente secreto. Así nace el llamado Proyecto Stealth.

El 15 de Enero de 1991 Bill Joy, Andy Bechtolsheim, Wayne Rosing, Mike Sheridan, James Gosling y Patrick Naughton se reunen en Aspen, Colorado. El grupo quiere anticipar hacia donde se dirijirá la computación. Discuten sobre que les gusta y que no les gusta de varias tecnologias y al final llegan a la conclusión de que al menos una de las tendencias futuras será el acercamiento de sistemas digitales y electrónica de consumo. Se marcan como objetivo desarrollar un entorno único que pudiera ser utilizado por todos los dispositivos de electrónica de consumo.

Con el objetivo marcado, los miembros del Proyecto Stealth, que mas tarde se pasaría a llamar Proyecto Green, comienzan a trabajar el 1 de Febrero de 1991 en una pequeña oficina de Sand Hill Road en Menlo Park. Se divide el trabajo con Naughton dedicado al sistema gráfico “Aspen”, Gosling dedicado a identificar el lenguaje de programación a utilizar en el proyecto y Sheridan dedicado al desarrollo de negocio.

En un principio se considera C++ como lenguaje a utilizar, pero tanto Gosling como Bill Joy lo encontraron inadecuado. Gosling intentó primero extender y modificar C++ resultando el lenguaje C++ ++ — (++ — porque se añadían y eliminaban características a C++), pero lo abandonó para crear un nuevo lenguaje desde cero al que llamo Oak (Roble), según la versión mas aceptada, por el roble que veía a través de la ventana de su despacho.

Oak debía ser independiente de la plataforma, dado el gran número de modelos en el mercado, por lo cual se optó por un lenguaje interpretado. Además el nuevo lenguaje debía ser robusto y a la vez sencillo para evitar errores por parte del programador que pudieran llevar al cuelgue del sistema. Esto motivó que se eliminaran las características que hacían el código más propenso a errores, como la herencia múltiple.

El resultado fue un lenguaje que tenía similitudes con C, C++ y Objective C y que no estaba ligado a un tipo de CPU concreta. Mas tarde se le cambiaría el nombre de Oak a Java, por cuestiones de propiedad intelectual, al existir ya un lenguaje con el nombre Oak. Se supone que le pusieron ese nombre mientras tomaban café (Java es también el nombre de un tipo de café, originario del este de Asia, de la isla del mismo nombre), aunque hay algunos que afirman que el nombre deriva de las siglas de James Gosling, Arthur Van Hoff, y Andy Bechtolsheim.

La salud de Java

diciembre 20, 2009

Bueno, revisitando el índice TIOBE ( http://www.tiobe.com ), para Diciembre de dos mil nueve, Java se encuentra en la posición número uno de la tabla. Volvemos a descubrir que el lenguaje Java sigue gozando de muy buena salud y buenas perspectivas de futuro.

Ranking tiobe para diciembre de 2009

Ranking Diciembre 2009

Algunos no se muestran de acuerdo con el rankin de TIOBE, siempre es fuertemente criticado por aquellos que argumentan que sus métodos de cálculo favorece a unos lenguajes y a otros no, etc.

Pero es cierto que al menos intentan minimizar el margen de error y de falsos positivos. ¿Que método es el empleado?, para los que no conozcan este índice, decirles que se establece intentando reflejar el “estado de salud” de distintos lenguajes, en cuanto a uso, ofetas de empleo, etc.

Este índice otorga 100 puntos entre todos los lenguajes de programación existentes (excluyendo a aquellos que susceptibles de parecerlo, no lo son por cuestiones de estructuras lingüísticas: HTML, XML, SQL, etc).

Los puntos otorgados a cada lenguaje depende  de varios factores a estudiar: por un lado se establecen los ratios de consulta sobre los motores de busquedas mas usados ( Google, Google Blogs, MSN, Yahoo!, Wikipedia y YouTube), además se valora el número de ofertas de trabajo que para dicho lenguaje se encuentren en portales como Monster y otros, y teniendo en cuenta el número de libros editados y vendidos acerca de cada  lenguaje.

En base a todo este conjunto de datos (de fácil acceso mediante pago de 1500 $ USA), es como se establece el ranking de los lenguajes de TIOBE.

Una herramienta útil y curiosa que nos ayuda a tener una percepción de las lineas de proyección del mercado de la tecnología.

En este otro sitio: http://langpop.com/ se establecen gráficas de diversos sitios en la red sobre el uso de lenguajes de progración. Al final, sin ponderados en una gráfica donde se establece el primer lugar para Java en la red. (Última gráfica, de nombre “Normalizaed Comparison”).

Como extra además, Java esta en el primer lugar en el ranking de Sourceforge sobre el  número de proyectos desarrollados en un determinado lenguaje. En abril del 2005 superó a C, y en noviembre del 2005 a C++.

Así que, como se ve, cerrando el año dos mil nueve tenemos motivos para alegrarnos, por que Java sigue liderando en tecnología de desarrollo y eso es bueno para los profesionales que estamos relacionados con esta tecnología.  😉

Fuentes:

Página web de TIOBE: http://www.tiobe.com

Ranking de TIOBE: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

(Con FAQ al final de la página donde refutan algunos de los argumentos mas comunes en contra de sus resultados)

Lenguajes populares: http://langpop.com/

Hibernate y Openmeetings-III

diciembre 16, 2009

A continuación, es util que conozcamos la clase HibernateUtil.java. Es la clase encargada de proporcionar operaciones para el manejo de las sesiones de hibernate que se necesiten. Puede encontrarse en la siguiente ruta, dentro del código fuente (carpeta “src” ) del servidor:

org.openmeetings.app.hibernate.utils

Seguidamente, los ficheros hibernate de configuración para cada bean. Estos ficheros de nombre bean.hbm.xml, son los ficheros responsables de establecer la relación entre cada clase bean Java y el mapeo entre este y la base de datos.

Se encuentran en la siguiente ruta del código fuente del servidor: org.openmeetings.app.hibernate.beans, donde dentro de la carpeta bean aparece cada clase Java y su correspondiente fichero bean.hbm.xml. A su vez, cada bean.hbm.xml ha de quedar registrado en el fichero de configuración de hibernate (hibernate.cfg.xml) de la siguiente forma:

<mapping resource=”org/openmeetings/app/hibernate/beans/adresses/Adresses.hbm.xml”/>

y es asi como se estructura a nivel básico toda la relación entre hibernate y openmeetings.

Hibernate y Openmeetings -II

diciembre 9, 2009

Imaginemos que queremos realizar cambios en openmeetings. Queremos implementar nuevas features en la aplicación o añadir algún tipo de modulo funcional.

Para ello, tal vez necesitemos modificar o incluir algunos aspectos nuevos en la base de datos de la aplicación. Openmeetings, como ya dijimos en el anterior post, estructura la relación aplicación-base de datos mediante hibernate, que es una implementación de la JPA  (Java Persistence API), así que tendremos que pasar obligatoriamente por hibernate para implementar aspectos nuevos o modificar aspectos ya existentes. Vayamos conociendo el planto de situación de Hibernate en openmeetings

En la ruta:   red5fromscratch/webapps/openmeetings/conf/

Podemos encontrar los siguientes archivos para la configuración de hibernate:

any_hibernate.cfg.xml

hibernate.cfg.xml

install.xml

mysql_hibernate.cfg.xml

om_ldap.cfg

postgres_hibernate.cfg.xml

Que representan una serie de variantes de formatos de configuración de hibernate, pero solamente de cara a los dialectos. Realmente todos reproducen el mismo mapeo objeto-relacional dentro de las etiquetas <mapping></mapping> ya que no hay diferencias en las tablas de la base de datos y se necesita el mismo mapeo para todas las opciones.

Los cambios entre los archivos se deben a la declaración de los dialectos a usar dentro de las etiquetas: <property name=”dialect”></property>

Realmente no son necesarios tantos ficheros, con elegir el motor de base de datos a usar, con solo un fichero .cfg.xml destinado a recoger el dialecto, el mapeo y el resto de información a declarar sería suficiente.

Como se indica en cada etiqueta de mapeo, los siguientes recursos se ubican en app/hibernate/beans/ donde podemos localizar agrupados por carpetas los ficheros de extensión hbm.xml junto a cada bean (ficheros homónimos de extensión.java) encargados de concretar el mapeo y las operaciones.

Paralelamente, se establece en una carpeta contigua un fichero de extensión .java que contiene a la clase HibernateUtils, que nos facilitará obtener una sesión de Hibernate. En esta clase es donde indicamos dónde está nuestro fichero de configuración de hibernate: el fichero hibernate.cfg.xml.

Por último, en el fichero hibernate.properties se indican algunos parámetros de ayuda a la configuración de la persistencia de objetos.

Sobre la configuración de Hibernate:

Necesitamos los siguientes recursos: Tener instalado una base de datos, en nuestro caso PostgreSQL, todo el material de código necesario de red5 y openmeetings:

http://dl.fancycode.com/red5/0.6.3/debian/red5_0.6.3-1_all.deb

http://openmeetings.googlecode.com/files(nombre de la versión elegida)

En openmeetings, los datos de configuración de los ficheros son los siguientes:

-Para hibernate.cfg.xml, en nuestro caso, usamos:

<!– User / Password –>

<property name=”connection.username”>username</property>

<property name=”connection.password”>password</property>

<!– Database Settings –>

<property name=”connection.driver_class”>org.postgresql.Driver</property>

<property name=”dialect”>org.hibernate.dialect.PostgreSQLDialect</property>

<property name=”connection.url”>jdbc:postgresql://localhost/openmeetings</property>

<property name=”hibernate.connection.CharSet”>utf8</property>

<property name=”hibernate.connection.characterEncoding”>utf8</property>

<property name=”hibernate.connection.useUnicode”>true</property>

Estan dando el cante

diciembre 9, 2009

Quieren mas, no cabe duda.

No les basta con sus chalets, o con sus segundas viviendas en la playa, no. Es lo que tiene el capitalismo, que a todo acaba imputando un valor de mercancia. Decía una de ellos: “Nos estamos muriendo de hambre”, sin sonrojo, sin vergüenza, con mirada valiente. Debemos ser nosotros, entonces, los que no entendemos nada.

Apuestan por un modelo de negocio que ya NO sirve, que no es adecuado, entonan esa canción, como hace poco los banqueros de “soy neoliberal, mientras me haga rico, cuando pierda que papa estado venga a ayudarme” de estribillo tan pegadizo ultimamente. Si.

Quieren mas. No luchan por el arte, no luchan por el respeto a los nuevos valores, no defienden mas oportunidades para los jovenes artistas que empiezan ahora. No. Defienden el modelo de siempre, el que ellos ya han aprendido, el que consiste en negociar con sus discográficas, sus ventas, sus royalties, sus promociones, etc. Defienden sus status quo actual, que para ellos es el de toda la vida. No quieren cambios. No quieren aprender cosas nuevas, no quieren aprender a desenvolver su trabajo con los nuevos medios y las nuevas redes.  Es un tema de industria, de modelo de negocio, de patrón de consumo. Pero ¿El mercado no se regulaba a si mismo?…pues se esta regulando.

Es una  vergüenza, o al menos a mi me lo resulta. Es cierto que tienen derecho a proteger sus autorías. O a influir de alguna forma en el flujo de su trabajo por las redes, pero los tiempos estan cambiando, y ellos y ellas solos defienden algo que ya esta perdido de antemano.

Me pareció una vergüenza. Creo que estaba fuera de contexto, que el debate no debería ir por ahí, pero creo que industria y negocio obligan.

Siempre les queda sacarse el carnet del partido de la ceja. Al menos aspirarán a algún funcionariado, o a ser directores de algún instituto cervantes en algún pais lejano.

Hibernate y Openmeetings

diciembre 8, 2009

Bueno, hace ya tiempo que empezé a hacer movidas con openmeetings. Esto, para quien no lo conozca, es un proyecto basado en software libre de plataforma virtual para videoconferencias y gestión de documentos, usuarios, entidades, etc. Aqui teneis la URL del proyecto: http://code.google.com/p/openmeetings/

El caso es que tuve que realizar modificaciones y realizar cambios, añadir nuevas “features”, etc, etc. Poco a poco fui consciente de que no resultaba tan sencillo implementar y desarrollar para dicha plataforma, además de que la comunidad en torno al proyecto no maneja mucha información ni experiencia avanzada, el “creador-unico-pilar-base-del-proyecto-y-señor-que-tiene-una-empresa-dedicada-a-instalar-openmeetings”, es decir, el creador de todo el sistema openmeetings no resulta ser un señor demasiado dispuesto a ayudar cuando la información necesitada va mas allá de cuestiones básicas de instalación, así que hoy quiero empezar a publicar contenido sobre esto. En concreto, la relación entre hibernate y openmeetings, ya que openmeetings se apoya en tecnología Java del lado del servidor, y se usa una implementación de la JPA para la persistencia de datos, hablo,  en concreto, de hibernate.

Así que, investigando sobre este caso claro de matrimonio de conveniencia, llegue a documentar la relación entre ambos. Y me fué bastante util, la verdad. Mirando ahora en perspectiva, pienso que es un caso de uso sencillo de hibernate en una aplicación media que puede servir para introducir al neófito en la materia en los aspectos mas básicos de openmeetings.

Doy por empezada la serie “Hibernate y Openmeetings”. Que ustedes lo disfruten.

¡Hola Mundo!

diciembre 8, 2009

¡Hola Mundo! por fin se va acercando la oportunidad de un mismo lugar para todos mis contenidos.

Han sido muchos los sitios que han almacenado información mia, detalles, apuntes, post diversos, etc. Y ahora empieza una nueva etapa: todo localizado en el mismo entorno, con una homogeneización mas util de los contenidos y el formato.

Que ustedes disfruten, empieza el camino. Buena caza.

A %d blogueros les gusta esto: