Acabo de enterarme de que Id Software y la empresa IGA Worldwide están desarrollando en conjunto el juego Quake Live, que vendría a ser algo así como un Quake en versión navegador, en el que todo el mundo podría jugar GRATIS (aunque ya han confirmado que incluirá publicidad) a través de un navegador web, siendo totalmente MULTIPLATAFORMA. Se acabó eso de andar montando clientes y parches desde Linux para echar unos tiros al Quake. Se abre el Firefox (por supuesto) se entra en www.quakelive.com y a pegar tiros!! XD
Ahora mismo el juego aún está en fase Beta, de modo que la web solo muestra un pequeño formulario para entrar a formar parte del equipo betatester. Acabo de apuntarme, de modo que si me seleccionan y tengo oportunidad de probarlo ya contaré mis peripecias XD
Un saludo y me voy a dormir que son las 3 de la madrugada jajaja
Bona nit!!
Mostrando entradas con la etiqueta Darwan. Mostrar todas las entradas
Mostrando entradas con la etiqueta Darwan. Mostrar todas las entradas
domingo, 24 de febrero de 2008
martes, 29 de enero de 2008
Música a tu gusto
Hace un par de semanas conocí un proyecto muy interesante, se trataba de Pandora, una radio online bastante peculiar, que consiste en decirle el nombre de un grupo o de una canción que te guste y la radio se encarga de sacarte canciones de estilo similar, a las que puedes ir diciendo "me gusta/no me gusta", para que la radio vaya conociendo tus gustos. Lamentablemente hace algún tiempo que no está disponible, y mi mono de música me arrastró a buscar algo similar.
Cuál fue mi sorpresa al encontrarme con otra web con temática prácticamente idéntica. Se trata ni más ni menos que de Last.fm, una radio que había oído comentar en varios sitios, pero nunca me decidí a probar. Básicamente funciona igual que Pandora, le dices un grupo musical y te saca canciones del mismo estilo. Además tiene una funcionalidad añadida que a mi me encanta, te descargas su software (para poder escucharla sin tener que tener el navegador abierto) e incorpora plugins para los principales reproductores multimedia (Windows Media, Winamp, etc.) y mientras escuchas tu música propia (un mp3 de Green Day por ejemplo), el programa de lastfm recoge la información y la agrega a tu perfil de gustos, de modo que aunque no estés escuchando la emisora, está reconociendo que tipo de música te gusta según lo que escuchas.
Cuál fue mi sorpresa al encontrarme con otra web con temática prácticamente idéntica. Se trata ni más ni menos que de Last.fm, una radio que había oído comentar en varios sitios, pero nunca me decidí a probar. Básicamente funciona igual que Pandora, le dices un grupo musical y te saca canciones del mismo estilo. Además tiene una funcionalidad añadida que a mi me encanta, te descargas su software (para poder escucharla sin tener que tener el navegador abierto) e incorpora plugins para los principales reproductores multimedia (Windows Media, Winamp, etc.) y mientras escuchas tu música propia (un mp3 de Green Day por ejemplo), el programa de lastfm recoge la información y la agrega a tu perfil de gustos, de modo que aunque no estés escuchando la emisora, está reconociendo que tipo de música te gusta según lo que escuchas.
lunes, 7 de enero de 2008
Una partidita?? ;)
Viendo NoPuedoCreerQueLoHayanInventado me encontré esta chulada.
El Proyecto GAMEOVER consiste en reproducir juegos clásicos como el Pong, el Space Invaders o el Tetris con personas y StopMotion. Os dejo algunos de sus videos y judgad vosotros mismos.
Tetris:
Pole Position:
Space Invaders:
Pong:
El Proyecto GAMEOVER consiste en reproducir juegos clásicos como el Pong, el Space Invaders o el Tetris con personas y StopMotion. Os dejo algunos de sus videos y judgad vosotros mismos.
Tetris:
Pole Position:
Space Invaders:
Pong:
Etiquetas:
cachondo,
Darwan,
Pole Position,
Pong,
Space Invaders,
Tetris,
Videojuegos
miércoles, 19 de diciembre de 2007
Como construir un condensador de Fluzo

Si habéis visto Regreso al Futuro, recordaréis que en el interior del Delorean había un aparato llamado El condensador de Fluzo, que era el que permitía los viajes en el tiempo. Pues bien, trasteando por la web he encontrado un link muy interesante, en que describe paso por paso (en inglés) cómo construir un condensador de Fluzo. Dejo el esquema aquí para que le echéis un vistazo.
Estoy por ponérselo a mi Citröen a ver si funciona jajaja
Flux Capacitance Time Travel Circuit
(c) John Bajak 1990
^
/ |
+-------o o----/\/\/\/---+------+-------+
| S1 | | | |
| G1 | | \
+ --- + | --- --/-> G2
----- B1 ----- XXX P1 \
--- C1----- --- |
----- | | o
| | | \ G3
| | | o
+-------------------------+------+-------+
B1 27 volt source
C1 1200 uF 50V electrolytic
P1 piezoelectric transducer (value uncritical)
S1 charging switch (SPST)
G1 25-ohm rheostat (future control)
G2,G3 switch (SPST) and 1M-ohm potentiometer for past control
El link completo aquí
Etiquetas:
cachondo,
Condensador de Fluzo,
Darwan,
Regreso al Futuro
lunes, 10 de diciembre de 2007
Mas alto pero no mas claro...
Me ha hecho gracia eso de "Todas las copias de seguridad del mundo", acompañado de la bandera pirata y de "2 juegos de regalo". Vamos, que se puede decir mas alto pero no más claro jajajaEso si, "sin perder la garantía original de Nintendo" XD
PD:Me he fijado que hasta han mantenido el "TM" en el logo de la wii, que monstruo XD
domingo, 2 de diciembre de 2007
España, el único país donde arrasa la PS3
Lo que se lee a veces por ahí. La wii arrasa en todos los países, la XBOX 360 la sigue de cerca, y la PS3 no se come un torrao en ningún sitio... excepto en España. Como siempre, nuestro país al revés del mundo.
Wii arrasa en ventas, XBOX 360 se mantiene, Playstation 3 sólo triunfa en España
Wii arrasa en ventas, XBOX 360 se mantiene, Playstation 3 sólo triunfa en España
martes, 27 de noviembre de 2007
12 señales de que eres un mal programador
Visto en Barrapunto
1. Java es todo lo que necesitas.
No ves la necesidad de usar ningún otro lenguaje, ¿por qué no se puede hacer todo con Java? No te importa ver código en Python o Ruby que logra en 10 lineas lo que llevaría varias hojas de código Java. Además, seguramente las nuevas características de la próxima versión del lenguaje lo arreglaran de todas formas. (Esto es aplicable a casi cualquier lenguaje, pero ocurre que entre la comunidad Java parece estar más extendida esta forma de pensar)
2. El término "enterprisey" (NT: se trata de un término sarcástico utilizado para designar productos complejos más allá de lo necesario) no te suena a broma.
"Enterprise" no es sólo una palabra, es una filosofía, una forma de vida, un camino a la iluminación. Cualquier cosa que pueda ser escrita, desplegada o actualizada con un trabajo mínimo es descartada como un juguete que no "escalará" para futuros usos. Mientras tanto la mayor parte del trabajo real en tu oficina se hace enviando hojas de cálculo en Excel mientras esperan a que termines de construir tu nueva visión corporativa.
3.Te opones férreamente a las funciones/métodos de más de 20 líneas de código.
(o 30 o 10 o cualquier otro número) Lo siento, algunas veces una función larga es justamente lo que necesitas. Normalmente las funciones cortas son más sencillas de entender, pero algunas veces se pueden expresar más fácilmente en una sola función más larga. El código no debería hacerse más complejo sólo para adecuarse a criterios arbitrarios.
4. "¡OH DIOS MÍO! ¡PATRONES!"
Los desarrolladores que buscan constantemente la forma de aplicar patrones a cualquier problema de código con el que se encuentran están añadiendo una complejidad innecesaria. Lejos de ser algo que busques, deberías sentirte mal cada vez que tienes que utilizar un patrón de diseño, significa que estás escribiendo código que hace las cosas más complicadas y que puede ser de dudosa utilidad. Pero, ¡ey!, tu código tiene patrones, bien por ti.
5. Los ciclos de CPU son un recurso precioso y tu estilo de programación y lenguaje reflejan esas creencias.
Hay montones de problemas en los que tienes que tener muy en cuenta el consumo de CPU (modelado/simulación, procesado de señales, kernels de sistemas operativos, etc), pero no es tu caso. Para la mayor parte de los desarrolladores de software sus principales problemas de rendimiento están relacionados con las bases de datos y la entrada/salida. El único efecto de optimizar tu código para mejorar el uso de CPU será disminuir en 2 milisegundos el tiempo necesario para la próxima consulta a la base de datos. Mientras tanto el desarrollo de la aplicación se hace más lento, no puedes hacer frente a los nuevos requerimientos y te encuentras con problemas serios de calidad. Pero al menos estás ahorrándote montones de ciclos de CPU… eventualmente.
6. Piensas que ninguna función/método debería tener más de un return.
Esta la he oído alguna que otra vez, y normalmente la razón que me dan es que el código es más sencillo de analizar. ¿Según quién? Yo encuentro más fácil de leer un código más simple, y normalmente el tener más de un return simplifica el código.
7. Tus usuarios son estúpidos. Realmente estúpidos.
Simplemente no puedes creer lo estúpidos que son, olvidándose constantemente de hacer las cosas más sencillas del mundo y cometiendo errores tontos al usar tu aplicación. Nunca has considerado que quizás es tu aplicación la que es estúpida porque eres incapaz de escribir software decente.
8. Te enorgulleces enormemente del gran volumen de código que escribes.
Ser productivo es bueno, desafortunadamente escribir montones de líneas de código no es lo mismo que ser productivo. Los usuarios nunca comentan "Guau, este programa puede ser difícil de usar y estar lleno de errores, pero al menos sé que hay un montón de código por debajo." En lugar de ser productivo, generar toneladas de mal código retrasa a los demás desarrolladores y en el futuro su mantenimiento constituirá una pesada carga.
9. Copiar y pegar es genial, te ayuda a escribir código desacoplado.
Defiendes tu uso del copy paste con extraños argumentos sobre desacoplar código y eliminar dependencias, mientras ignoras el aumento del tiempo de mantenimiento y los problemas de duplicación de errores. A esto se le llama "racionalizar tus acciones".
10. Piensas que la gestión de errores consiste en capturar todas las excepciones, registrarlas, y continuar como si nada.
Eso no es gestionar errores, eso es ignorar errores y es el equivalente semántico al "on error next" de VB. Sólo porque hayas registrado el error en algún sitio no significa que lo estés tratando. Tratar errores es algo duro. Si no sabes qué hacer exactamente cuando te encuentras con un cierto error, simplemente deja que la excepción se propague y que un nivel más alto del código lo trate.
11. Modelas todo tu código en UML antes de escribirlo.
El modelado entusiasta de UML se lleva a cabo normalmente por aquellos que no escriben demasiado código, sino que se consideran arquitectos de software. Las herramientas de modelado atraen más a aquellos que piensan que el código se puede escribir en una sala de conferencias manipulando pequeños gráficos. Los gráficos no son el diseño, y nunca serán el diseño, para eso está el código.
12. Tu código borra datos importantes.
Escribiste un cierto código que se supone que debe sobrescribir los archivos de la aplicación con otros nuevos, pero se vuelve loco y borra todos los datos del usuario.
1. Java es todo lo que necesitas.
No ves la necesidad de usar ningún otro lenguaje, ¿por qué no se puede hacer todo con Java? No te importa ver código en Python o Ruby que logra en 10 lineas lo que llevaría varias hojas de código Java. Además, seguramente las nuevas características de la próxima versión del lenguaje lo arreglaran de todas formas. (Esto es aplicable a casi cualquier lenguaje, pero ocurre que entre la comunidad Java parece estar más extendida esta forma de pensar)
2. El término "enterprisey" (NT: se trata de un término sarcástico utilizado para designar productos complejos más allá de lo necesario) no te suena a broma.
"Enterprise" no es sólo una palabra, es una filosofía, una forma de vida, un camino a la iluminación. Cualquier cosa que pueda ser escrita, desplegada o actualizada con un trabajo mínimo es descartada como un juguete que no "escalará" para futuros usos. Mientras tanto la mayor parte del trabajo real en tu oficina se hace enviando hojas de cálculo en Excel mientras esperan a que termines de construir tu nueva visión corporativa.
3.Te opones férreamente a las funciones/métodos de más de 20 líneas de código.
(o 30 o 10 o cualquier otro número) Lo siento, algunas veces una función larga es justamente lo que necesitas. Normalmente las funciones cortas son más sencillas de entender, pero algunas veces se pueden expresar más fácilmente en una sola función más larga. El código no debería hacerse más complejo sólo para adecuarse a criterios arbitrarios.
4. "¡OH DIOS MÍO! ¡PATRONES!"
Los desarrolladores que buscan constantemente la forma de aplicar patrones a cualquier problema de código con el que se encuentran están añadiendo una complejidad innecesaria. Lejos de ser algo que busques, deberías sentirte mal cada vez que tienes que utilizar un patrón de diseño, significa que estás escribiendo código que hace las cosas más complicadas y que puede ser de dudosa utilidad. Pero, ¡ey!, tu código tiene patrones, bien por ti.
5. Los ciclos de CPU son un recurso precioso y tu estilo de programación y lenguaje reflejan esas creencias.
Hay montones de problemas en los que tienes que tener muy en cuenta el consumo de CPU (modelado/simulación, procesado de señales, kernels de sistemas operativos, etc), pero no es tu caso. Para la mayor parte de los desarrolladores de software sus principales problemas de rendimiento están relacionados con las bases de datos y la entrada/salida. El único efecto de optimizar tu código para mejorar el uso de CPU será disminuir en 2 milisegundos el tiempo necesario para la próxima consulta a la base de datos. Mientras tanto el desarrollo de la aplicación se hace más lento, no puedes hacer frente a los nuevos requerimientos y te encuentras con problemas serios de calidad. Pero al menos estás ahorrándote montones de ciclos de CPU… eventualmente.
6. Piensas que ninguna función/método debería tener más de un return.
Esta la he oído alguna que otra vez, y normalmente la razón que me dan es que el código es más sencillo de analizar. ¿Según quién? Yo encuentro más fácil de leer un código más simple, y normalmente el tener más de un return simplifica el código.
7. Tus usuarios son estúpidos. Realmente estúpidos.
Simplemente no puedes creer lo estúpidos que son, olvidándose constantemente de hacer las cosas más sencillas del mundo y cometiendo errores tontos al usar tu aplicación. Nunca has considerado que quizás es tu aplicación la que es estúpida porque eres incapaz de escribir software decente.
8. Te enorgulleces enormemente del gran volumen de código que escribes.
Ser productivo es bueno, desafortunadamente escribir montones de líneas de código no es lo mismo que ser productivo. Los usuarios nunca comentan "Guau, este programa puede ser difícil de usar y estar lleno de errores, pero al menos sé que hay un montón de código por debajo." En lugar de ser productivo, generar toneladas de mal código retrasa a los demás desarrolladores y en el futuro su mantenimiento constituirá una pesada carga.
9. Copiar y pegar es genial, te ayuda a escribir código desacoplado.
Defiendes tu uso del copy paste con extraños argumentos sobre desacoplar código y eliminar dependencias, mientras ignoras el aumento del tiempo de mantenimiento y los problemas de duplicación de errores. A esto se le llama "racionalizar tus acciones".
10. Piensas que la gestión de errores consiste en capturar todas las excepciones, registrarlas, y continuar como si nada.
Eso no es gestionar errores, eso es ignorar errores y es el equivalente semántico al "on error next" de VB. Sólo porque hayas registrado el error en algún sitio no significa que lo estés tratando. Tratar errores es algo duro. Si no sabes qué hacer exactamente cuando te encuentras con un cierto error, simplemente deja que la excepción se propague y que un nivel más alto del código lo trate.
11. Modelas todo tu código en UML antes de escribirlo.
El modelado entusiasta de UML se lleva a cabo normalmente por aquellos que no escriben demasiado código, sino que se consideran arquitectos de software. Las herramientas de modelado atraen más a aquellos que piensan que el código se puede escribir en una sala de conferencias manipulando pequeños gráficos. Los gráficos no son el diseño, y nunca serán el diseño, para eso está el código.
12. Tu código borra datos importantes.
Escribiste un cierto código que se supone que debe sobrescribir los archivos de la aplicación con otros nuevos, pero se vuelve loco y borra todos los datos del usuario.
domingo, 25 de noviembre de 2007
Cubos de Rubik
Curioseando por Youtube me he encontrado esto. Un chaval que resuelve un cubo de rubik de 10x10x10 despues de examinarlo durante 8 horas y 23 minutos. Interesante programa. Me pregunto cual será.
En un enlace desde el mismo video encontre este otro, aún mas bestia. 20x20x20, con contador de movimientos y de tiempo.
Y este último como frikada. Un rubik normal de 3x3x3 en 10.56 segundos. Si parpadeas no lo ves XD
En un enlace desde el mismo video encontre este otro, aún mas bestia. 20x20x20, con contador de movimientos y de tiempo.
Y este último como frikada. Un rubik normal de 3x3x3 en 10.56 segundos. Si parpadeas no lo ves XD
sábado, 24 de noviembre de 2007
Frases raras del gcc
Ahhhhhh(suspiro)... el gcc, ese compilador de C tan querido por los usuarios de linux...
Sí, sí, hasta que te suelta una frase de las suyas.
Aquí hago una pequeña recopilación de las que más gracia me hicieron de las MUCHAS frases raras que me soltó cuando estudiaba C.
-las literales de cadena en múltiples líneas están deprecadas
Y ESO QUE SIGNIFICA??
-la declaración de `tam' obscurece un parámetro
`tam' no conoce las linternas, verdad?
-\202 Parásito en el programa
AAAAARGH!!! KASPERSKYY, SALVAMEE!!! Ah, no, si sólo faltaba un ; que susto...
-apuntador deferenciado a tipo de dato incompleto
Y yo que culpa tengo que el dato me saliera jorobado?? Eso es discriminación, oiga.
-tipos en conflicto para `eleccion'
Si es que ya decía yo que un dato palestino y uno israelí no se iban a quedar quietos...
Sí, sí, hasta que te suelta una frase de las suyas.
Aquí hago una pequeña recopilación de las que más gracia me hicieron de las MUCHAS frases raras que me soltó cuando estudiaba C.
-las literales de cadena en múltiples líneas están deprecadas
Y ESO QUE SIGNIFICA??
-la declaración de `tam' obscurece un parámetro
`tam' no conoce las linternas, verdad?
-\202 Parásito en el programa
AAAAARGH!!! KASPERSKYY, SALVAMEE!!! Ah, no, si sólo faltaba un ; que susto...
-apuntador deferenciado a tipo de dato incompleto
Y yo que culpa tengo que el dato me saliera jorobado?? Eso es discriminación, oiga.
-tipos en conflicto para `eleccion'
Si es que ya decía yo que un dato palestino y uno israelí no se iban a quedar quietos...
miércoles, 21 de noviembre de 2007
Un nuevo pringao se une al equipo!!
Bueno, pues tras las súplicas de Alberto, jejeje, he decidido unirme a contribuir ligeramente en este blog.
Algo de información sobre mi persona....
Soy informático, al igual que Alberto.
Tengo 22 años, y estudio programación.
Intentaré postar cosas curiosas que encuentre de vez en cuando. Nos vemos!!
Algo de información sobre mi persona....
Soy informático, al igual que Alberto.
Tengo 22 años, y estudio programación.
Intentaré postar cosas curiosas que encuentre de vez en cuando. Nos vemos!!
Suscribirse a:
Entradas (Atom)