Este capitulo habla de los procesos de desarrollo del Estatuto del proyecto (el documento que define el proyecto), del plan de gestión del proyecto, su ejecución, su monitorización, su gestión de cambios y su cierre.
Se hace incapie en el comité de expertos para validar los cambios, aunque no indica que sea obligatorio dicho comité.
Me recuerda un poco a ITIL, aunque con ITIL se definen diferentes tipos de cambios y cuales han de ser validados por el comité.

A partir del siguiente capitulo el libro va a hablar en cada capítulo de los procesos que conforman cada área de conocimiento. Todos los procesos tienen en comun unos inputs, unas herramientas y unos outputs, siendo los outputs de algunos procesos los inputs de otros.

Este capitulo es tambien un poco introductorio. Se centra en un rol de PM y cuales son sus atribuciones, habla del project expediter, con el que me siento identificado, y creo que el 99% de los “encargados de equipo” que trabajan en charcuteras.

Habla de una clasificación de las organizaciones con respecto a las diferentes funciones que puede tener un PM dentro de estas.

Comenta que en los supuestos del examen se asume que se trabaja en una organización Matricial.

Enumera los tipos de restricciones que tiene un proyecto

En este capitulo  se habla de que existen 42 procesos, que se pueden clasificar de dos formas diferentes, o bien por grupos de proceso o bien por areas de conocimiento.

Se indican los roles de Stakeholder, que es todo aquel que participa/afecta el proyecto y de Project Manager, indicando en que areas se enfoca.

Muestra que es un proyecto, diferenciando de un proceso. El proyecto tiene un comienzo y un fin definidos, y el proceso no.

También jerarquiza los projectos en programas (un conjunto de proyectos relacionados entre si, que pueden ser gestionados guntos generando algún beneficio) y porfolios (un conjunto de proyectos y programas enfocados hacia un mismo objetivo).

ikoni

Algunos recursos para estudiar:

También me he enterado de que el examen cambia el 31 de Agosto de este año, espero que para esas fechas no tenga que estudiar algo completamente diferente  :(

online poker newsMe acuerdo hace años, cuando conocí a la primera persona que tenía en su casa un ordenador, la admiración (y parte de envidia) que sentía hacia él. Creo recordar hacerle alguna pregunta estúpida y con cara de fascinación del tipo: “¿el ordenador te hace los deberes?”. Eran otros tiempos y otras preocupaciones.

Y creo recordar que la respuesta de este agraciado era algo así como: “si antes le has metido las respuestas sí”, jejejeje. A lo que yo no veía mucho sentido, para que meterle las preguntas primero para que luego te las dijera, si ya las podías poner entonces directamente tu mismo si las sabías en tu cuaderno de deberes…

Pero bueno, era una primera lección de lo que nos permiten hacer los ordenadores. Y es que sacar el máximo rendimiento a nuestro ordenador depende, en muchas ocasiones, de tener las herramientas adecuadas que nos ayuden a maximizar nuestro tiempo y minimizar nuestro esfuerzo. Por ello, rodearse de las aplicaciones que nos hacen más fácil el día a día, ya sea en el trabajo, o en casa, es una cuestión vital para aprovechar nuestro ordenador.

Recientemente he ido ampliando estas herramientas que escuchas o te encuentras por casualidad, y que una vez que las pruebas, no puedes vivir sin ellas (y no, no hablo de drogas ni de apple). Y por ello, quería compartir con todos ustedes las siguientes herramientas que me facilitan tanto mi trabajo profesional como mi uso cotidiano con el ordenador. Espero que ustedes colaboren en los comentarios y añadan aquellas que son sus imprescindibles.

Aquí va mi lista de software y utilidades imprescindibles:

• Dropbox. De este servicio ya hemos hablado anteriormente y de como obtener más espacio. Nos permite sincronizar una carpeta de nuestro disco duro para tenerla accesible vía web, o mediante otro ordenador.

• ClipX. Se trata del sustituto perfecto para el portapapeles por defecto que viene con Windows. Básicamente, permite seleccionar el número de “cosas” que almacena en el portapapeles, para luego acceder a ellas. Y como “cosas” comprende desde simple texto hasta imágenes. Tiene algunos atajos de teclado realmente estupendos, como el de abrir la url copiada en un navegador, o buscar en google el texto del portapapeles.
• Launchy. Esta aplicación rastreado los directorios y menús que le indiquemos (por defecto el menú inicio de nuestro usuario y del usuario por defecto) para lanzar las aplicaciones de una forma rápida e intuitiva, sin tener que ir navegando por el menú de Inicio en busca de ellos.
• Foxit Reader. El sustituto ideal al pesado y lento Acrobat Reader. Es rápido, abre documentos en pestañas y funciona de maravilla.
• Image Resizer. Programa que se integra en el menú contextual de Windows y que sirve para modificar el tamaño de una o varias imágenes a la vez. Ideal para enviar copias de nuestras fotos por internet a menor escala y tamaño. En principio era un programa de Microsoft para Windows XP, pero también hay clones para Windows Vista y Windows 7.
• LogMeIn. Este es uno de los últimos servicios que me han recomendado y que le encuentro muy interesante. Se trata de un sistema para acceder de forma remota y mediante un navegador web a otro ordenador remoto, en el que hayamos instalado dicho servicio. Ideal para acceder desde el trabajo a casa (o viceversa) o para dar soporte técnico en remoto.

Espero que les gusten mis propuestas, todas ellas GRATUITAS. Y espero también leer sus programas preferidos y que recomiendan para el uso diario del PC.

recomendado, Software, software imprescindible, utilidades

Los web services son servicios que se ofrecen de forma independiente a la tecnología en la que se han desarrollado. Son realmente una forma de intercambiar información, de pedir algo sin tener en cuenta el lenguaje de programación, para dar un servicio de forma independiente. Solo hace falta saber cómo invocar al servicio.

Dentro de las novedades de los web services, he descubierto hace poco los servicios REST(ful). Se basan en HTTP para intercambiar información y no necesita encapsulado extra para ello. Es más ligero, menos engorroso, pero al mismo tiempo tiene más limitaciones. Aquí podeis ver algo de información al respecto. En resumen, en vez de hacer peticiones encapsuladas en un sobre SOAP para solicitar un servicio para lo que es necesario el wsdl, en los REST las peticiones se hacen mediante el protocolo http, con GET, POST… sin necesidad de encapsularlo.

Recientemente he tenido que investigar si utilizar AXIS2 o Jersey para implementar un servicio web del tipo RESTFUL. Para ello he hecho lo siguiente:

Axis2:
Normalmente se utiliza en forma de aplicación independiente, un war que se despliega completamente dentro de nuestro servidor de aplicaciones, pero para agilizarlo, lo que he hecho yo ha sido descomprimir el war y copiarme solo las librerias necesarias que son las siguiente para un servicio REST.
|       axiom-api-1.2.9.jar
|       axiom-impl-1.2.9.jar
|       axis2-adb-1.5.2.jar
|       axis2-clustering-1.5.2.jar
|       axis2-jaxws-1.5.2.jar
|       axis2-kernel-1.5.2.jar
|       axis2-transport-http-1.5.2.jar
|       geronimo-stax-api_1.0_spec-1.0.1.jar
|       geronimo-ws-metadata_2.0_spec-1.1.2.jar
|       httpcore-4.0.jar
|       neethi-2.0.4.jar
|       woden-api-1.0M8.jar
|       wstx-asl-3.2.9.jar
|       XmlSchema-1.4.3.jar

Las librerías como no, van en WEB-INF/lib
Después, he modificado el web.xml de mi aplicación para que me coja el servlet de Axis que me va a redirigir a los servicios web que implemente con el siguiente código:

En mi caso, el parámetro load-on-startup tiene su sentido, y también tiene su sentido que tenga el valor tres, pero es opcional.
Una vez descrito el servlet de Axis2, me he generado un servicio mediante una clase java que por ejemplo puede tener esta pinta:
public class SimpleService {

public String hola(String value) {
return “hola” + value;
}
}

También tengo el archivo axis.xml con la configuración por defecto pero añadiendo que puede servir servicios rest que por defecto creo vienen desactivados. Se puede ver la configuración en la web de axis2. Aquí mi linea para configurar los servicios REST en axis2 (primero el parametro de desactivar REST comentado y a continuación el parametro de activar REST).

y por último el descriptor del servicio, el service.xml donde le digo realmente donde y como se ejecutan los servicios:

Bueno, en este punto, me falta por describir donde va cada cosa:web.xml donde siempre, dentro del directorio WEB-INF
axis2.xml donde lo hayas configurado dentro del web.xml mediante una ruta absoluta o bien por defecto en WEB-INF/conf
services.xml dentro de WEB-INF/services
clase java con el servicio, en el paquete que se le haya descrito.

Y ya está! No hace falta wsdl porque en este caso, aunque axis2 necesita del descriptor, lo genera automáticamente. Si se quiere definir el método de entrada como POST o GET hay que hacerlo en el wsdl, aunque por defecto te lo genera como POST (y al mismo tiempo, si no hay get, también funciona como get)
Llamada GET de ejemplo en un navegador:
http://localhost:9082/MyWebApp/services/SimpleService/hola?value=Pepe
En la pantalla aparecerá Hola Pepe
wsdl, por curiosear
http://localhost:9082/MyWebApp/services/SimpleService/hola?wsdl

Ejemplo de un cliente en java:
public static void main(String[] args) {

Client client = new Client();
WebResource webResource = client.resource(“http://localhost:9082/MyWebApp”);
String response = webResource.path(“services”).path(“SimpleService”).path(“hola”)
.queryParam(“value”, “Pepe”).get(String.class);
System.out.println(“Response: ” + response);
}

Nota: MyWebApp es el nombre de la aplicación web donde he metido el Axis2 a funcionar.

En resumen: necesitmoas unos 6 megas en librerías para que funcione lo más light posible.
La información va empaquetada por debajo como SOAP aunque nosotros utilicemos una llamada web.
No hace distinción entre GET y POST, me explico, si pones un servicio descrito como POST pero no hay GET, y haces una llamada mediante http como un GET, al no encontrar el get, va a ir al POST
Los parámetros de entrada tienen que coincidir en nombre con los definidos en las funciones del web service.

Por otro lado tenemos JERSEY:
Está preparado únicamente para web-services del tipo REST, no es posible utilizar encapsulamiento SOAP, es más limitado en este aspecto pero como yo quiero utilizar REST, me vale me sobra.
Primera diferencia, todas las librerías necesarias pesan un único mega.
Segunda diferencia: cuidado con las versiones, a partir de una de ellas se han compilado utilizando java 6 y puede dar problemas. Yo he utilizado la 1.0.2 porque me vale y me sobra y necesito librerías compiladas en java5.
Una vez tengo las librerías, configuro el servlet de jersey para que me coja luego los servicios web mediante la siguiente configuración

Veis que es todo igual, solo cambia la clase del servlet.
Cuando tenemos las librerías y el servlet, solo nos queda la clase java que va a ser el servicio web y aquí es donde va toda la configuración ya que no necesita ni service.xml, archivo de configuración extra ni wsdl (ni siquiera lo genera automáticamente, no es necesario)
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.QueryParam;

@Path(“/hola”)
public class SimpleService {

}

Cosas importantes
1. @Path(“/hola”) – Es el path que hay que poner para invocar al servicio web. En nuestro caso, dada la configuración de Jersey sería algo así como
http://servidor:puerto/services/hola?nombre=Pepe
2. @GET – Identifica al método que será accesible mediante una petición http GET
3. @Produces(“text/plain”) – devolverá texto plano
4. @QueryParam(“nombre”) – se mapea mediante este parámetro el valor de los parametros de entrada al metodo del servicio web. En nuestro ejemplo se cogerá de la uri el paámetro con el nombre ‘nombre’, y su valor (es decir, ‘Pepe’) se le pasará como parámetro de entrada al método hola en el parámetro palabra. Es decir, los parámetros de la uri no tienen que llamarse igual que los parámetros de los métodos del web service, ya que se configura el mapeo en el mismo método:
Cosas importantes: cada clase de un servicio web, tiene definido solo un path, una ruta para llegar a el, que es a nivel de clase, no a nivel de método como podía pasar con axis. Por tanto, en cada clase solo se puede definir un método de entrada de tipo GET y un método de entrada de tipo POST (o un método que sea para ambos) pero nunca se podrá dentro de la misma clase configurar dos métodos de entrada diferentes para el mismo tipo de petición, ya sea post o get.
Se puede apreciar lo ligero que es, es mucho más sencillo.
Además no genera nunca un wsdl, no le es necesario.
No se encapsula la petición bajo SOAP, va directamente mediante http.
Url para solicitar el servicio:
http://localhost:9082/MyWebApp/services/hola?nombre=Pepe

Ejemplo de cliente para este web service de Jersey
public static void main(String[] args) {

System.out.println(“Response: ” + response);
}

Nota: MyWebApp es el nombre de la aplicación web donde he puesto Jersey a funcionar.
Diferencias muy importantes:
- Axis2 necestia una configuración más completa y sirve para mas cosas que aplicacioes RESTFUL mientras que Jersey solo sirve para RESTFUL pero no hace falta casi configuración.
- Jersey pesa 1 mega, y Axis, capando las librerias para que solo utilice las necesarias para restful, 6megas
- Jersey no encapsula las peticiones HTTP en un envelope SOAP mientras que Axis si, en este aspecto, axis funciona en restful simulando que lo hace, pero por debajo funciona como SOAP aunque sea transparente para el usuario
- Axis necesita de wsdl aunque bien es verdad que lo autogenera si no lo tiene. Jersey no necestia wsdl
- Jersey no necesita service.xml, la configuración va toda en la clase java mientras que Axis si que necesita el service.xml
- Jersey solo permite definir un web service por clase, configurándolo directamente en la clase java. Solo se puede poner un punto de acceso para cada tipo de petición http. Axis permite configurar todo eso al gusto en los archivos de configuración pero no filtra peticiones por el tipo de petición http que sea. Es decir, una petición get, si no está del todo definido y no hay petición get configurada, puede entrar por el método post. Tal vez con una buena configuración y un wsdl escrito a mano correctamente no pase, pero podría pasar si no se hace bien.
- Jersey se come el nombre del metodo. En este aspecto no le da importancia y solo utiliza la configuración de la clase java mediante etiquetas predefinidas de forma que si un servicio web se define con el path “/hola“, la limitación de acceso a los metodos que tiene dentro solo se podrá hacer por tipo de petición http, bien GET bien POST.
- Los nombres de los parámetros de los métodos del web service deben coincidir con los parámetros de la uri para axis (cosa normal para web services), aunque no es necesario para jersey ya que se pueden configurar. También se puede describir de donde se quiere recoger los datos en jersey, bien de la uri, del contenido de la petición post…
- Axis no me ha dado problemas con java 5, mientras que jersey tiene cada una de sus versiones compiloada solo en una versión de java siendo las últimas java6. Hay que tener cuidado con eso.
- Jersey tiene algún bug en alguna versión anterior, y como cada versión está compilada solo en una versión de java, hay que tener mucho cuidado con cual se utiliza.

Mi opinión, si te es suficiente Jersey (si solo necesitas web services REST), utiliza Jersey, sobre todo ahora que viene el invierno (tachan! chiste malo), es mas fácil de configurar, menos pesado, mas fácil para empezar con el… Axis es mucho más potente pero también necesita mucha más configuración y control sobre lo qué estás haciendo.

Hace poco que me he sacado la certificación, y ahí os dejo los esquemas que me hice por si le pueden valer a alguien. Son un poco menos cutres que los de java, jeje.

Hace poco me han regalado un libro en el que viene un ejercicio consistente en apuntar las tareas que haces a lo largo del día. De lo que me he dado cuenta al realizar este ejercicio es que soy un adicto al email, no pasan mas de 10 minutos y ya tengo la necesidad de mirar mis cuentas, incluso la de mi cárnica, a la que solo llega spam. Va a ser verdad lo que dice mi hermano, que soy un adicto al ADSL.

He estado navegando un poco por Internet, y he visto que existe una lista para tratar de controlar esta adicción, la lista se compone de 12 puntos/pasos, en casi todos los sitios en español he visto que fue Marsha Egan quien desarrolló la lista (curiosamente ninguno comenta los pasos, pero la mayoría dedica las mismas palabras a la noticia.). Finalmente he encontrado la lista en ingles, la cual os dejo a continuación traducida y con algunos retoques.

Del libro hablaré cuando lo termine, pero a día de hoy me esta gustando mucho.

1. Admitir que tienes un problema.
Admitir que el correo te esta controlando y alejarse de la necesidad de comprobar el correo cada 10 minutos.

2: Reconocer los síntomas.
Incapacidad de centrarte en otras tareas, falta de tiempo, necesidad de tener la bandeja de entrada vacía.

3. Asumir la responsabilidad
Si no envías tantos correos tal vez no se recibas tantos.

4. Practicar la regla de Tres
Si has chequeado tres veces la bandeja de entrada esperando un correo que no llega tal vez sea el momento de realizar una llamada.

5. No poner en copia al universo
Piensa dos veces antes a que gente vas a poner en CC. Si ellos responden, ¿qué va a pasar?

6. Apagar la campanilla
Lo más parecido a la campana del perro de Paulov es un icono parpadeante en la barra de tareas. Eliminalo.

7. Ralentizar la respuesta
Contestar los mensajes en el momento de recibirlos crea la expectativa de que siempre respondes rápidamente.

8. Dejar que el software haga su trabajo
Utiliza filtros de spam y reglas para que los correos entrantes se organicen automáticamente en carpetas.

9. Conseguir ayuda de otras personas
Involucra a otros en la conquista de tu adicción.

10. Consultar los mensajes una única vez
Si no es relevante, bórralo. Si no es así mételo en una carpeta y planifica la respuesta.

11. Establecer intervalos regulares para revisar el correo
Consulta el correo a las horas en punto.

12. Tener tiempos sin conexión
Designa un día a la semana, completamente libre de correo.

Hace algo más de 2 años que conozco la página web de Bookcrossing, y tenía ganas de utilizarla, pero no encontraba el tiempo para ello.

¿Como se podría definir esta página?, pues se la podría definir como una biblioteca global o la biblioteca 2.0, o la biblioteca p2p. Pero lo más seguro es que estas definiciones no resuelvan las dudas de nadie y le den más halo de misterio a todo esto. Quizás la mejor manera de saber que es consista explicar como funciona el bookcrossing.

En el bookcrossing, una persona deja un libro en la calle o en algún sitio de forma pública para que alguien se lo encuentre, lo lea y lo deje en otro lugar, repitiendose de nuevo el ciclo. Todo esto tiene el soporte de un sitio web el cual registra los libros que se han liberado (según la terminología de Bookcrossing) con un código de identificación único el BCID, y cada persona que encuentra y lee el libro se conecta al sitio web para indicar donde se ha encontrado el libro y que le ha parecido.

La idea me parece simplemente genial y ya he encontrado un par de sitios “oficiales” donde liberar mi libros. La única pega a todo esto se la veo al sitio web, aunque puede parecer que este traducido a varios idiomas, en cuanto pinchamos a un enlace de la versión en español nos sale un pop-up en ingles. Lo del ingles tiene un pase (a pesar de los años que lleva funcionando la web), pero lo del pop-up es algo que debería prohibirse y perseguirse por la policía de Internet. Otra pega es que la navegación no es muy intuitiva.

La terminología utilizada en el Bookcrossing es muy sencilla, solo hay que aprenderse las palabras “liberar”, “jungla” y “de caza”. Donde liberar es la acción de dejar un libro, la jungla se define como el sitio donde se encuentra un libro liberado a la espera de que alguien lo recoja, y de caza hace referencia a la acción de ir a buscar libros. No os cuento nada más por si sentís curiosidad indaguéis un poco en el sitio web.

Debido a mi cambio de residencia dispongo de mucho tiempo para leer en el tren, y me estoy leyendo unos cuantos libros que tenía atrasados, pero el primero que quería liberar es este tiene el BCID 348-7107821, espero que si alguien se lo encuentra lo disfrute y lo vuelva a liberar.

¿Que opinará la ministra de todo esto?¿Ayuda a fomentar la cultura o por el contrario la destruye?

Mira que he aprendido hoy!!