Linux: reinicio de emergencia SysRq

Recomendaciones para cuando se nos quede completamente colgado nuestro sistema linux.

Ni siquiera el Ctrl+Alt Barckspace reinicia el entorno gráfico. ¿Qué podemos hacer?.

Aquí lo importante es prevenir daños mayores, sobre todo ocasionados al disco duro y el sistema
de archivos y apagar correctamente el ordenador para minimizar los posibles daños.

La secuencia de teclas se denomina SysRq y está implementada en el kernel (por lo cual deberia estar presente en todas las distribuciones). Esta secuencia sirve para casos de emergencia en un sistemas Linux que ha dejado de responder.

Pulsa:
Alt+Imprimir pantalla y mientras las mantienes pulsadas debes pulsar estas teclas "R" "S"
"E" "I" "U" y "B" (sin soltar Alt+Imprimir pantalla)

R: devuelve el control al teclado.
S: sincroniza.
E: manda a los procesos la señal term.
I: manda a los procesos la señal kill.
U: desmonta los sistemas de ficheros.
B: reinicia el sistema.

Mientras pulsas las teclas no vas a oír ni ver nada. Parecerá que el sistema sigue colgado, pero no es así. En un momento, el kernel termina todos los procesos, cierra los puertos, librerías , archivos, etc. De esta manera, podrás apagar el ordenador mucho más seguro que desconectarlo directamente de la corriente o dejar el botón de "power" apretado.

Tomado de Revista Libre Papirux2

XP Xtreme Programming: reglas

Reglas del XP

Planning

1. User stories are written (o Casos de Uso).
2. Release planning creates the schedule.
3. Make frequent small releases.
4. The Project Velocity is measured.
5. The project is divided into iterations.
6. Iteration planning starts each iteration.
7. Move people around.
8. A stand-up meeting starts each day.
9. Fix XP when it breaks.

Designing

1. Simplicity (mantener las cosas simples siempre ayuda!!!).
2. Choose a system metaphor.
3. Use CRC cards for design sessions.
4. Create spike solutions to reduce risk.
5. No functionality is added early.
6. Refactor whenever and wherever possible (muy importante!!).

Coding

1. The customer is always available.
2. Code must be written to agreed standards.
3. Code the unit test first (<- TDD).
4. All production code is pair programmed.
5. Only one pair integrates code at a time.
6. Integrate often.
7. Use collective code ownership.
8. Leave optimization till last.
9. No overtime.

Testing (http://www.agiledata.org/essays/tdd.html)

1. All code must have unit tests.
2. All code must pass all unit tests before it can be released.
3. When a bug is found tests are created.
4. Acceptance tests are run often and the

Hibernate: relaciones con annotations

Ejemplo de anotaciones uni y bidireccional en many-to-one

Tomando en cuenta q hay dos clases (tablas en BD) user y correo de la siguiente forma:

Lo basico:

Tabla USER	Tabla CORREO
ID (id) NAME (name) PWD (password)	ID (id) MAIL (mail) USER_ID [relacion]

La clase User tendra propiedades id, name, password
La clase Correo tendra propiedades id, mail

Las anotaciones, ademas de los campos arriba mencionados son como sigue:

Bidireccional User --- Correo (User y Correo saben de la existencia del otro)

class Correo {
@ManyToOne(fetch..)
@JoinCloumn(name="USER_ID")
privateUser usuario;
}
class User {
@OneToMany (cascade..,fetch..,mappedBy="usuario")
Set correos;
}

Unidireccional User --> Correo (User sabe q correos tiene pero Correo no sabe nada de User)

class Correo {
/**** no existe ningun atributo 'usuario' ****/
}
class User {
@OneToMany (cascade..,fetch..)
@JoinColumn(name="USER_ID")
Set correos;
}

Unidireccional User <-- Correo (Correo sabe a q user corresponde pero User no sabe nade de Correo) class Correo {
@ManyToOne(fetch..)
@JoinCloumn(name="USER_ID")
privateUser usuario;
}
class User {
**** no existe ningun atributo 'correos' ****
}

NOTA:
mappedBy hace referencia al nombre de atributo del otro lado
* @JoinColumn.name hace referencia al nombre de la tabla en la BD (no el atributo)
* los nombres de las tablas y sus campos aqui se indican en mayusculas, pero las clases Java y sus elementos siguen el mismo esquema q cualquier clase Java.