Cuando has perdido el password de root de tu máquina GNU/Linux y no sabes como recuperarlo estas en problemas. Aquí tienes una pequeña guía sobre que puedes hacer para hacerte con el control de tu máquina.

En ella explico diversas métodos que podrías emplear. Como sabes muchas cosas pueden ir mal debido a las enormes posibilidades de configuración que ofrece este sistema operativo. No te desesperes si al emplear alguno no te funciona pasa al siguiente método. Si todo sigue sin funcionar escribe un comentario en esta entrada, quizás podamos ayudarte.


Continua leyendo "Como recuperar el password de root en GNU/Linux"

Un patrón de diseño (en programación orientada a objetos, POO) es una descripción de diversos objetos y clases preparados para resolver un problema de diseño general aplicado a un contexto específico. Un patrón de diseño identifica las instancias y clases que participan en dicho patrón además de sus papeles, sus relaciones y sus responsabilidades para llevar a cabo la tarea a resolver. Cada patrón de diseño se centra en resolver un problema particular en la POO. Describe cuando se puede aplicar, si puede ser aplicado desde el punto de vista de las limitaciones del diseño y las consecuencias tanto positivas como negativas que tiene su utilización.

Pongamos un ejemplo: MVC (model-view-controller) consiste en 3 tipos de objetos. El modelo son los objetos de la aplicación (lógica de la aplicación), la vista es su representación a los usuarios y el controlador define la manera en el que la interfaz con el usuario (generado por la vista) reacciona ante la introducción de datos por parte del usuario. Dentro de MVC hay varios patrones de diseño que pueden ser empleados para facilitar el desarrollo de este tipo de arquitectura.

Por ejemplo la relación vista-controlador es un ejemplo del patrón de diseño "Strategy". Strategy es un objeto que representa un algoritmo. El patrón es útil en realidad cuando pretendes reemplazar este algoritmo estática o dinamicamente cuanto tienes varias variantes del algoritmo o cuando el algoritmo tiene una estructura de datos compleja que quieres encapsular.

MVC usa otro patrón de diseño "Factory Method" para especificar la clase controladora por defecto para una vista y "Decorator" se puede emplear por ejemplo para añadir scroll a una vista. Pero la principal relación en MVC es dado por los patrones "Observer", "Composite" y "Strategy"

Antes de describir alguno de ellos defino brevemente los parámetros que se emplean para describir los patrones de diseño:

Nombre del patrón y clasificación, intención (¿Que hace este patrón?) ,otros nombres por los que también es conocido, motivación (escenario que ilustra su funcionamiento), aplicabilidad (en que escenarios es válido), estructura (representación gráfica de las clases involucradas y diagramas de interacción para ilustrar secuencias de peticiones y colaboraciones entre objetos), participantes (clases, objetos y sus responsabilidades), colaboraciones (como los participantes pueden colaborar en sus responsabilidades), consecuencias (¿Cómo el patrón realiza su cometido?¿Cuales son los compromisos a tener en cuenta al aceptar esta solución?), implementación (dificultades, riesgos, pistas o técnicas a tener en cuenta a la hora de implementar el patrón), ejemplo de código, usos conocidos y patrones relacionados.

Nombre: Observer
Clasificación: Behavioral Patterns
También conocido como: Dependents, Publish-Subscribe, Event-Observer
Motivación: Un problema muy común al particionar un sistema en una colección de clases cooperativas es la necesidad de mantener la consistencia entre objetos relacionados pero sin tenerlos fuertemente acoplados ya que esto reduce su reusabilidad. El patrón define un sujeto y uno o varios observadores de este suejto. Todos los observadores son notificados si el sujeto lleva a cabo un cambio de estado (evento).
Aplicabilidad:
- Cuando un objeto cambia y esto requiere el cambio de varios objetos y se desconoce el número de objetos que necesitarán este cambio
- Cuando una abstracción tiene dos aspectos, una dependiente de la otra. Encapsular estos aspectos te permite variarlos y reusarlos independientemente
- Cuando un objeto tiene que notificar a otros objetos sin hacer asunciones sobre su naturaleza. En otras palabras no se quiere que estos objetos esten fuertemente acoplados
Estructura: Diagrama de clases


Participantes:
- Subject (conoce sus observers que pueden ser uno, ninguno o varios y proporciona un interfaz para registrar y desregistrar observadores)
- Observer (define un intefaz para actualizar que debe ser llamado cuando el subject cambia de estado)
- ConcreteSubject (almacena el estado de interes para los objetos ConcreteObserver y les envia notificaciones cuando su estado cambia)
- ConcreteObserver (Mantiene referencia al objeto ConcreteSubject, almacena estado de manera consistente con el del objeto ConcreteSubject e implementa interfaz de actualización para las notificaciones)
Colaboraciones: ConcreteSubject notifica a sus observadores sobre un cambio que podría hacer el estado de los observadores fuera inconsistente con el suyo propio. Después de ser informado el observador del cambio en el sujeto. El observador podría requerir informacion al sujeto para conciliar su estado
Consecuencias: El patrón observer te permite cambiar sujetos y observadores de manera independiente de manera que se pueden rehusar ambos. Puede violar la separación en capas de tu aplicación pues los observadores pueden pertenecer a capas diferentes de la del sujeto. Las actualizaciones en el sujeto pueden generar un coste desconocido pues no se sabe cuantos ni cuales observadores pueden estar registrados al sujeto.
Implementación: Temas conflictivos: mapear subjects a observers y observers a más de un subject. ¿Quien dispara la actualización? 2 opciones, el propio subject cuando cambia de estado o hacer a los clientes responsables de enviar la notificacion.
Ejemplos de código: Symfony event dispatcher
Usos conocidos: Cualquier interfaz de usuario GUI implementado empleando OOP como KDE
Patrones relacionados: Mediator, Singleton


Espero que os sea de utilidad. No puedo acabar si pasar la referencia a la biblia de los patrones de diseño creado por el Gang of Four (sus 4 autores)

Design Patterns. Elements of Reusable Object-Oriented Software - Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides - Addison Wesley (GoF- Gang of Four)

Sin comentarios...

Es bastante sencillo cuando trabajamos con subversion u otros tipos de repositorios incluir en nuestra cópia de trabajo ficheros que no debemos subir al repositorio, como compilaciones, ficheros de prueba, ficheros del sistema operativo, logs, etc. Para que subversión los ignore tenemos diversos métodos.

Todos estos métodos modifican la propiedad svn:ignore

1) Editar directamente la propiedad para un directorio en concreto


$ svn propedit svn:ignore ./ruta_ficheros_a_ignorar


A continuación podemos indicar los ficheros a ignorar dentro de la ruta especificada permitiéndose el comodín '*'. Así para ignorar todos los ficheros dentro del directorio basta con indicar


*


Puedes crear una lista de ficheros, uno por linea, por ejemplo:


*.out
data.log
*.tmp
test_*


2) Otro método consistiría en editar el archivo global ~/.subversion/config

Busca la sección [miscellany] dentro de este fichero y cambia la propiedad global-ignores para ignorar los archivos que no deseas subir al repositorio. Hay que emplear un espacio como separador entre "ficheros" en lugar de poner uno por línea como hacíamos antes. Así:


global-ignores = *.out data.log *.tmp test_*


Esto ignorará todos los ficheros que sigan este patrón en todos los repositorios que emplees en tu máquina local

3) Un último método sería empleando el comando propset de subversion


$ svn propset svn:ignore *.tmp .


El punto final indicaría que es el directorio actual en donde deben ignorarse los fichero son extensión tmp

Podemos especificar un fichero donde tengamos todas las reglas para ignorar ficheros con el modificador -F, así:


svn propset svn:ignore -F ignore.txt .


Recuerda además que si empleas propset y propedit debes ejecutar un commit para que todo el mundo ignore estos ficheros. Ten esto en cuenta a la hora de definir lo que no quieres versionar.. svn:ignore es una propiedad; metadatos en el repositorio que también son versionados. Cada objeto dentro de subversion (ficheros, directorios, enlaces etc) puede tener esta u otras propiedades. Para saber que propiedades tiene un objeto en concreto en nuestro repositorio o copia de trabajo basta ejecutar:


$ svn proplist /ruta_objeto


¿Quieres participar en la creación de un juego online? Ahora puedes apuntarte al desarrollo de un nuevo juego de estrategia online multijugador. La temática es muy sencilla y para ser sinceros ya muy trillada. Diriges una pequeña raza nativa de un pequeño sistema solar en una remota región de la galaxia. Tu civilización ha alcanzado ya el punto tecnológico en el que la colonización de otros sistemas solares ya no es una quimera. Pero otras civilizaciones alienígenas podrían estar esperando ahí fuera (y lo estarán) para acabar con tu especie y lograr la supremacía.

El juego esta basado en diferentes partidas donde se juega sobre un tablero tridimensional, un mapa estelar. Podrás construir naves, investigar nuevas tecnologías, colonizar nuevos mundos y conquistar sistemas solares rivales para alcanzar la victoria.

El juego está en un estado alpha de desarrollo pero (espero) es completamente jugable. El juego se desarrolla en turnos, cada turno dura una hora y cada jugador deja unas ordenes específicas para su raza. Las ordenes necesitan varios turnos(horas) para completarse por lo que no es necesario estar conectado permanentemente. Sólo en determinados momentos conviene estar alerta ante acontecimientos vitales (batallas, conquistas, colonizaciones etc).

Hay que tener en cuenta que cada partida involucra a 10 jugadores en un mapa estelar de 100 estrellas. Todos los jugadores entran al mismo tiempo en la partida (se espera a que la partida tenga 10 jugadores antes de empezarla). Los mejores jugadores serán aquellos que acumulen más partidas ganadas. No se nada de cuanto puede durar una partida, aunque calculo que podrían llegar a unas 6 semanas o más. Cada usuario registrado puede unirse hasta a 3 partidas simultáneamente.

Casi me olvido para apuntaros id a: juego online novanebula
Os dejo algunas capturas de esta versión a ver si os convencen para uniros:

---

---

Como dice su lema 'serious monkyes. serious engine.' nos encontramos ante una API de alto rendimiento para la generación de escenas gráficas en 3D realmente maduro. Sólo hay que echarle un vistazo a su sección de películas y demos que da cuenta de las posibilidades actuales de su motor gráfico. jMonkeyEngine es un proyecto de código abierto bajo licencia BSD que comenzo allá por el año 2003. Actualmente acaban de sacar la alpha de la versión 3 del engine.

Para poder empezar a desarrollar basta con descargase las librerías jar del proyecto. Actualmente lo mejor es hacerlo a través de las versiones nocturnas aunque puedas encontrarte con alguna versión más o menos estable el producto está bastante acabado.

Ahora sólo tienes que descomprimirlo (descarga .zip) he importar jMonkeyEngine3.jar y la carpeta lib que se encuentra en el zip dentro de tu proyecto. También tienes los javadoc y el código fuente en el archivo zip y en la página web de jMonkeyEngine puedes ver tutoriales explicativos para poder comenzar a hacer tus pinillos en el mundo 3D.

Happy coding!

Mysql tiene asociadas dos horas horarias, una es global y otra por conexión. Su valor por defecto coincide con la zona horaria del servidor donde mysql esté en ejecución. Esto se corresponde con el valor de timezone SYSTEM. Para poder saber el valor de zonas horarias en una conexión basta con lanzar esta consulta:

mysql> SELECT @@global.time_zone,@@session.time_zone,NOW();

La primera columna es el time_zone de nuestro servidor y el segundo el de nuestra conexión. La tercera columna de la fecha y hora actuales de acuerdo con el valor de timezone de nuestra conexión (si, la 2ª columna)

Para poder modificarla según el manual online de mysql basta con ejecutar:

mysql> SET time_zone = timezone;

Siendo timezone una cadena que se debe corresponder con una zona horaria instalada en nuestro sistema. Sin embargo si ejecutas esta consulta es muy probable que te de un error, diciendo que desconoce esta zona horaria.

Por ejemplo

mysql> SET time_zone = 'UTC';
1298 Unknown or incorrect time zone: 'UTC'

Como es esto posible, ¿mysql no sabe nada sobre esta zona horaria universal?. En mi sistema GNU/Linux (Debian). Las zonas horarias están a modo de archivo (filosofía UNIX) en /usr/share/zoneinfo. Y de un rápido vistazo se puede ver que, como no, UTC es una de las zonas horarias definidas.


Continua leyendo "Como cambiar la zona horaria de mysql por conexión"