Nueva entrega recopilatoria de música scener esta vez remezclada
. La intro y la versión de fr08 me gustan mucho. Muy bueno también este otro de intros de 4kb, esta vez hecho por un español :).
Aprovecho para poner un enlace a las producciones de la euskal de este año, grande ASD.
7.28.2008
7.27.2008
El trabajo desde casa
Leo un artículo en el que dicen que google recomienda el trabajo desde casa y la verdad es que no puedo estar más de acuerdo, aunque con matices.
He vivido el trabajo desde casa desde varios frentes, con un jefe trabajando desde casa, con otros empleados trabajando desde casa y como trabajador desde casa :).
En general el tele-trabajo me parece mala idea como solución total, esto es, no funciona para nada si el trabajador está siempre fuera o si no trabaja en algo bastante aislado. Se producen malentendidos por IM, no tienes visión global cuando curras desde casa, no "sientes" como están las cosas y, lo peor, no tienes ningún tipo de actividad social (Cada día valoro más la parte social del programador).
Sin embargo, cuando estás en casa no tienes interrupciones de otros compañeros, estás muy centrado en tu trabajo, puedes emplear el tiempo de desplazamiento en dormir más, relajarme desyunando con el beneficio que esto aporta.
Yo apostaría por un perfil mixto, esto es, el empleado sabe cuando tiene que estar realizando una tarea de diseño y codificación muy concreta que requiere de concentración y cuando necesita estar gestionando tareas con otros compañeros. De hecho, 37signals recomiendan en getting real (una muy buena lectura, un día lo comento), al menos, trabajar 4 horas al día cada empleado por separado.
El problema es que el empleado debe ser muy serio, profesional y responsable ya que es muy fácil entretenerte "oliendo rosas", pero si sabe lo que tiene que hacer y cuando, son todo ventajas: La empresa gana productividad, el empleado gana tiempo (y dinero) y además el empleado siente que la empresa confía en él, lo cual es un plus de moral.
He vivido el trabajo desde casa desde varios frentes, con un jefe trabajando desde casa, con otros empleados trabajando desde casa y como trabajador desde casa :).
En general el tele-trabajo me parece mala idea como solución total, esto es, no funciona para nada si el trabajador está siempre fuera o si no trabaja en algo bastante aislado. Se producen malentendidos por IM, no tienes visión global cuando curras desde casa, no "sientes" como están las cosas y, lo peor, no tienes ningún tipo de actividad social (Cada día valoro más la parte social del programador).
Sin embargo, cuando estás en casa no tienes interrupciones de otros compañeros, estás muy centrado en tu trabajo, puedes emplear el tiempo de desplazamiento en dormir más, relajarme desyunando con el beneficio que esto aporta.
Yo apostaría por un perfil mixto, esto es, el empleado sabe cuando tiene que estar realizando una tarea de diseño y codificación muy concreta que requiere de concentración y cuando necesita estar gestionando tareas con otros compañeros. De hecho, 37signals recomiendan en getting real (una muy buena lectura, un día lo comento), al menos, trabajar 4 horas al día cada empleado por separado.
El problema es que el empleado debe ser muy serio, profesional y responsable ya que es muy fácil entretenerte "oliendo rosas", pero si sabe lo que tiene que hacer y cuando, son todo ventajas: La empresa gana productividad, el empleado gana tiempo (y dinero) y además el empleado siente que la empresa confía en él, lo cual es un plus de moral.
Fin de semana de descanso
Ayer estuve a ver kung fu panda, sesión de las 20:30, gran error, todo repleto de padres con niños esperando encontrarse una película de dibujos animados al uso. En España aún pensamos que una película de "dibujos animados" es necesariamente para niños.
La película me gustó bastante, quizás porque tengo alguna noción de como se hace y puedo valorar, aunque sea muy poco, el trabajo que lleva. Además, los comentarios de la tortuga son muy sabios :)
En una parte de la película un personaje le dice a otro "no lo sabes todo" y una de las niñas de atrás hizo una pregunta a su padre que me dejó pensativo:
"papa, qué es no saberlo todo?"
pregunta profunda y recursiva a su vez.
Aún estoy pensando por qué algunos se ven reflejados en el panda...
La película me gustó bastante, quizás porque tengo alguna noción de como se hace y puedo valorar, aunque sea muy poco, el trabajo que lleva. Además, los comentarios de la tortuga son muy sabios :)
En una parte de la película un personaje le dice a otro "no lo sabes todo" y una de las niñas de atrás hizo una pregunta a su padre que me dejó pensativo:
"papa, qué es no saberlo todo?"
pregunta profunda y recursiva a su vez.
Aún estoy pensando por qué algunos se ven reflejados en el panda...
7.24.2008
por que no me gusta java
Hace poco me decía una persona que por qué no me gustaba nada java y que pusiese las razones por las cuales no me gusta. Ahí voy.
Antes de empezar a programar en java había programado en C++ y en python y siempre pensé que java sería de un estilo a python, sobretodo debido a su fama de productivo. Además, siempre crei que el típico mito de lentitud en ejecución y el consumo de memoria no eran más que topicazos.
Lo cierto es que java es lento y chupa memoria, pero no menos que otros lenguajes dinámicos (la palma se la lleva ruby), pero no es por eso por lo que no me gusta. No me gusta porque es PESADO y ABURRIDO.
Estoy aburrido de tener una jerarquía de clases de 20 niveles para leer una petición HTTP de un servidor o de 6 ó 7 para leer un puñetero fichero. Lo que yo quiero leer es el fichero y punto, no quiero 500 líneas de traza cuando tengo un pete, quiero que me diga lo que ha pasado y punto, quiero crear una lista e iterarla, tener un hash de listas, tener un hash de listas de sets con unicodes e iterarlo sin tener que pararme a pensar en las declaraciones, quiero serializar sin tener que complicarme la vida con jerarquías, en resumen, quiero trabajar sin tener burocracia de por medio, sólamente poner lo que tengo en la cabeza y ya.
A pesar de eso hay que reconocer a java muchas cosas, las facilidades que da para hacer test unitarios, code coverage, rendimientos, consumos de memoria, etc, la calidad de los editores (eclipse se sale), que haya una empresa detrás manteniendo el API (esto lo considero muy muy importante), los servidores de aplicaciones, las herramientas como maven para resolver dependencias... la verdad es que se pueden hacer cosas muy buenas, por ejemplo hudson, todo un ejemplo de aplicación bien hecha, sencilla de usar, potente, extensible, con un interfaz rest claro. Si yo tuviese que hacer una aplicación con java, elegiría hacer una tan buena como esta. Además me gusta su dinamismo, en cuanto a que puedes llegar y cargar una clase según te plazca. No es tan potente como python o ruby, pero sí más que C++.
En resumen, lo bueno que tiene java no es el lenguaje, son las herramientas, empresas y en general todo el back-stage, que sinceramente es mucho, pero considero más importante que el desarrollador tenga "feeling" (vaya palabra mas estúpida) con lo que usa a tener que estar malgastando el tiempo en iterar una lista.
Antes de empezar a programar en java había programado en C++ y en python y siempre pensé que java sería de un estilo a python, sobretodo debido a su fama de productivo. Además, siempre crei que el típico mito de lentitud en ejecución y el consumo de memoria no eran más que topicazos.
Lo cierto es que java es lento y chupa memoria, pero no menos que otros lenguajes dinámicos (la palma se la lleva ruby), pero no es por eso por lo que no me gusta. No me gusta porque es PESADO y ABURRIDO.
Estoy aburrido de tener una jerarquía de clases de 20 niveles para leer una petición HTTP de un servidor o de 6 ó 7 para leer un puñetero fichero. Lo que yo quiero leer es el fichero y punto, no quiero 500 líneas de traza cuando tengo un pete, quiero que me diga lo que ha pasado y punto, quiero crear una lista e iterarla, tener un hash de listas, tener un hash de listas de sets con unicodes e iterarlo sin tener que pararme a pensar en las declaraciones, quiero serializar sin tener que complicarme la vida con jerarquías, en resumen, quiero trabajar sin tener burocracia de por medio, sólamente poner lo que tengo en la cabeza y ya.
A pesar de eso hay que reconocer a java muchas cosas, las facilidades que da para hacer test unitarios, code coverage, rendimientos, consumos de memoria, etc, la calidad de los editores (eclipse se sale), que haya una empresa detrás manteniendo el API (esto lo considero muy muy importante), los servidores de aplicaciones, las herramientas como maven para resolver dependencias... la verdad es que se pueden hacer cosas muy buenas, por ejemplo hudson, todo un ejemplo de aplicación bien hecha, sencilla de usar, potente, extensible, con un interfaz rest claro. Si yo tuviese que hacer una aplicación con java, elegiría hacer una tan buena como esta. Además me gusta su dinamismo, en cuanto a que puedes llegar y cargar una clase según te plazca. No es tan potente como python o ruby, pero sí más que C++.
En resumen, lo bueno que tiene java no es el lenguaje, son las herramientas, empresas y en general todo el back-stage, que sinceramente es mucho, pero considero más importante que el desarrollador tenga "feeling" (vaya palabra mas estúpida) con lo que usa a tener que estar malgastando el tiempo en iterar una lista.
7.23.2008
Los proyectos software son como cocinar un plato
- Salen mejor si los haces a fuego lento
- Conviene probarlos cada poco tiempo
- A veces hay que echarles un poco de sal
- Cuantas más veces lo haces mejor te sale, pero si lo haces muchas veces terminan por no gustar
- si te descuidas se quema y sabe mal
- Si lo sacas antes del horno estará crudo
- La receta debe evolucionar añadiendo nuevos ingredientes y quitando otros
- A nadie le gusta fregar lo ensuciado preparandolo
- Es mucho más fácil criticarlo que mejorarlo.
- Todo plato debe ir acompañado
- Y como no, después de comer lo cocinado debe haber postre y siesta :)
- Conviene probarlos cada poco tiempo
- A veces hay que echarles un poco de sal
- Cuantas más veces lo haces mejor te sale, pero si lo haces muchas veces terminan por no gustar
- si te descuidas se quema y sabe mal
- Si lo sacas antes del horno estará crudo
- La receta debe evolucionar añadiendo nuevos ingredientes y quitando otros
- A nadie le gusta fregar lo ensuciado preparandolo
- Es mucho más fácil criticarlo que mejorarlo.
- Todo plato debe ir acompañado
- Y como no, después de comer lo cocinado debe haber postre y siesta :)
7.17.2008
asserts en release
Tradicionalmente se ha dicho que los assert deben eliminarse en la compilación para release. La razón es la de siempre, la velocidad. Pongamos que en un bucle hacemos una comprobación:
for(int i = 0; i < len; ++i)
{
ASSERT(array[i] != NULL);
array[i]->method();
}
Es cierto que cada vuelta hará la comprobación y eso puede resultar caro computacionalmente (aunque en este caso con la predicción de saltos no habría agujeros en el pipeline para un funcionamiento normal). Este es un ejemplo simple, pero puede complicarse lo que se quiera.
Ahora, si miramos desde otro punto de vista, puede que no resulte tan caro. Si piensas el tiempo que te tiras buscando un error que se podría haber solucionado en poco tiempo viendo el rastro de asserts, seguro que no es tan caro.
Es cierto que en lenguajes como java, python, etc tienes los "stacktraces" que son un buen debugger, pero en C++ no es tan fácil y hay que andar con cuidado, sobretodo con punteros no válidos. Trabajando en un entorno de PC es fácil hacer debug, el entorno de desarrollo de lo pone en bandeja, ya que para cualquier pete enseguida te saca la típica ventana preguntándote si deseas debugear. En entornos como windows ce, donde no avisa al usar un puntero inválido, prácticamente es obligatorio poner unos cuantos asserts al comienzo de cada método.
En resumen, deja los assert en release :)
for(int i = 0; i < len; ++i)
{
ASSERT(array[i] != NULL);
array[i]->method();
}
Es cierto que cada vuelta hará la comprobación y eso puede resultar caro computacionalmente (aunque en este caso con la predicción de saltos no habría agujeros en el pipeline para un funcionamiento normal). Este es un ejemplo simple, pero puede complicarse lo que se quiera.
Ahora, si miramos desde otro punto de vista, puede que no resulte tan caro. Si piensas el tiempo que te tiras buscando un error que se podría haber solucionado en poco tiempo viendo el rastro de asserts, seguro que no es tan caro.
Es cierto que en lenguajes como java, python, etc tienes los "stacktraces" que son un buen debugger, pero en C++ no es tan fácil y hay que andar con cuidado, sobretodo con punteros no válidos. Trabajando en un entorno de PC es fácil hacer debug, el entorno de desarrollo de lo pone en bandeja, ya que para cualquier pete enseguida te saca la típica ventana preguntándote si deseas debugear. En entornos como windows ce, donde no avisa al usar un puntero inválido, prácticamente es obligatorio poner unos cuantos asserts al comienzo de cada método.
En resumen, deja los assert en release :)
7.14.2008
Cuanto daño ha hecho char*
Estoy remodelando una parte de agroguía y ya puestos estoy internacionalizando la aplicación. Lógicamente, cuando te pones a hacer las cosas, o las haces bien o no las haces, así que he empezado a tirar del hilo, eliminando todo lo no unicode que hubiese referente a mensajes de usuario.
Si ahora mismo tuviese que dar clase a cualquira sobre cualquier lenguaje de programación, lo primero que le explicaría es que hace unos años no se usaba unicode, se usaba una arcaica codificación llamada ASCII y que como mucho les llegaba para el alfabeto inglés. Bien es cierto que ascii sigue presente, pero menudo infierno.
Tengo unas 12 frases que internacionalizar, pero se está conviertiendo en un infierno, en parte por mi poca práctica, en parte porque nada estaba preparado para ello.
PD: es curioso, pero sin unicode el título de este post no podría haberse escrito correctamente :)
Si ahora mismo tuviese que dar clase a cualquira sobre cualquier lenguaje de programación, lo primero que le explicaría es que hace unos años no se usaba unicode, se usaba una arcaica codificación llamada ASCII y que como mucho les llegaba para el alfabeto inglés. Bien es cierto que ascii sigue presente, pero menudo infierno.
Tengo unas 12 frases que internacionalizar, pero se está conviertiendo en un infierno, en parte por mi poca práctica, en parte porque nada estaba preparado para ello.
PD: es curioso, pero sin unicode el título de este post no podría haberse escrito correctamente :)
7.11.2008
Stadium
Hoy toca autobombo, unkasoft ha presentado Stadium, un juego tipo track'n'field en el que solo necesitas un par de botones para jugar. En Unkasoft tenemos la mala costumbre de dar poca publicidad a lo que hacemos, ya sea por razones de secretismo absoluto, cosa que nunca entenderé o símplemente porque no tenemos tiempo *sic*, pero esta vez parece que hemos espabilado (pero poco)
El juego ha sido creado por Alberto Gonzalez (le conocerán de otros juegos como runaway2) como programador principal, diseño de Hugo Lanchares y diseño del apartado gráfico por Juanma Zarza. Ha participado más gente, pero esos fundamentalmente.
El juego es muy divertido, menudos piques hemos tenido en unkasoft (por cierto soy el puto rey en salto de longitud, 11 metros y pico), está muy bien equilibrado, tiene diferentes juegos que plantean varios retos, no solo es macharar el teclado. El apartado gráfico me parece muy apropiado, muy retro, todo se ve perfectamente y con buen acabado (como todo lo que hace juanma).
Otros análisis del juego por juanma y hugo y página de lanzamiento, compatibilidades y video in-game.
Personalmente las cosas que más me han gustado han sido los iconos de los botones, el confeti de cuano ganas (deberíamos publicar el códido del confeti :), la jugabilidad incluso en BASURAS como motorola V3, compatibilidad con blackberry de lo cual tenemos un poco de culpa félix y yo.
Cosas que me gustarían:
- Sabiendo como está el percal de mensajes a móviles, quizás debería haberse financiado la cosa con la publicidad in-game.
- Un making-off
- Multijugador bluetooth, aunque tiene un modo multi con el propio móvil.
- Ranking online. IMPERDONABLE. Teniendo infraestructura y experiencia con otros juegos (que no cito porque no sé si por condición de empleado puedo, juaz) me parece, sencillamente, un error grave ya que realmente habría incurrido en poco coste y la calidad hubiese sido mucho mayor.
NOTA: las opiniones que expreso en este blog NO son el calidad de trabajdor de unkasoft, son complemtamente personales.
7.06.2008
Meme de desarrollo de software
He visto en el blog de charles petzold un meme acerca de desarrollo de software, al cual recuerdo de cuando yo empezaba a programar algo en windows.
Me he tomado la libertad de tomar el meme, traducir las preguntas(así que puede haber errores) y lanzarlo:
- Cuántos años tenías cuando empezate a programar
Justo en primero de carrera, tendría entre 17 y 18, aunque aún tardaría un año y pico más en tener un PC propio :).
- Cómo empezaste a programar
Con las prácticas de programación de la carrera, aunque aún recuerdo haber tecleado algún programa en un spectrum.
- Cual fue el primer lenguaje que usaste
Si no recuerdo mal ensamblador del 8086, aunque casi a la par que C
- Cual fue el primer programa real que programaste
Real, real, que yo recuerde, quizás algún pequeño juego 2D.
- Qué lenguajes has usado desde que empezaste a programar
asm x86 y motorola 68000, C, C++, java (PUAG), python, C#, VB(S) y seguramente algún pinito en otros lenguajes como perl, ruby, shell y otros, aunque realmente solo considero que sé usar en condiciones C, C++ y python.
- Cual fue tu primera experiencia profesional
Fue en una empresa del metal (realmente fue un "compañero del metal"), comencé de grabador de datos e implementé un verdadero caos en VBS y python que terminó por funcionar. Me sentí orgulloso del trabajo, la verdad.
- Si tú hubieras sabido lo que sabes ahora cuando empezaste a programar, hubieras empezado a hacerlo?
Pregunta difícil. Si es a nivel personal, no dudaría, SI, es algo divertido y que plantea retos. Profesionalmente, lo dudo, quizás si dentro de unos años, pero ahora no. Trabajo mal pagado, mal considerado, poco comprendido y en que se requieren mucho más años para empezar en comparación con otros trabajos que he realizado. No pasa un mes sin que piense en irme a hacer otra cosa, aunque quizás no sepa... :_(
- Si tuvieras que decir una sola cosa de las que has aprendido a lo largo de los años a un nuevo programador, qué le dirías:
Le diría dos, Trabaja duro y nunca hagas caso a los que ten consejos.
- Qué es lo más divertido que has programado?
Pues no sé si algún que otro proyecto 3D en lo personal y en lo profesional me gustó mucho un trabajo que hice para controlar pivots, que por cierto aún no he terminado y aún no me han pagado. La relación hardware y software me ha llamado la atención siempre, quizás por ello he disfrutado mucho con agroguía, aunque últimamente no tanto.
- A quién le pasas el meme:
A todos los de mi trabajo: félix, JM, Antonio, Carlos, Jaime, Edu, Alberto y Alfredo (a ver si se anima el blog de unkasoft y nos quitamos un poco de presión), elvis (enhorabuena por el artículo en shaderx), vicente (anímate a mostrarte al mundo :P), a la gente de planet statos (venga zaelsius, aunque quieras ser project manager...).
Me he tomado la libertad de tomar el meme, traducir las preguntas(así que puede haber errores) y lanzarlo:
- Cuántos años tenías cuando empezate a programar
Justo en primero de carrera, tendría entre 17 y 18, aunque aún tardaría un año y pico más en tener un PC propio :).
- Cómo empezaste a programar
Con las prácticas de programación de la carrera, aunque aún recuerdo haber tecleado algún programa en un spectrum.
- Cual fue el primer lenguaje que usaste
Si no recuerdo mal ensamblador del 8086, aunque casi a la par que C
- Cual fue el primer programa real que programaste
Real, real, que yo recuerde, quizás algún pequeño juego 2D.
- Qué lenguajes has usado desde que empezaste a programar
asm x86 y motorola 68000, C, C++, java (PUAG), python, C#, VB(S) y seguramente algún pinito en otros lenguajes como perl, ruby, shell y otros, aunque realmente solo considero que sé usar en condiciones C, C++ y python.
- Cual fue tu primera experiencia profesional
Fue en una empresa del metal (realmente fue un "compañero del metal"), comencé de grabador de datos e implementé un verdadero caos en VBS y python que terminó por funcionar. Me sentí orgulloso del trabajo, la verdad.
- Si tú hubieras sabido lo que sabes ahora cuando empezaste a programar, hubieras empezado a hacerlo?
Pregunta difícil. Si es a nivel personal, no dudaría, SI, es algo divertido y que plantea retos. Profesionalmente, lo dudo, quizás si dentro de unos años, pero ahora no. Trabajo mal pagado, mal considerado, poco comprendido y en que se requieren mucho más años para empezar en comparación con otros trabajos que he realizado. No pasa un mes sin que piense en irme a hacer otra cosa, aunque quizás no sepa... :_(
- Si tuvieras que decir una sola cosa de las que has aprendido a lo largo de los años a un nuevo programador, qué le dirías:
Le diría dos, Trabaja duro y nunca hagas caso a los que ten consejos.
- Qué es lo más divertido que has programado?
Pues no sé si algún que otro proyecto 3D en lo personal y en lo profesional me gustó mucho un trabajo que hice para controlar pivots, que por cierto aún no he terminado y aún no me han pagado. La relación hardware y software me ha llamado la atención siempre, quizás por ello he disfrutado mucho con agroguía, aunque últimamente no tanto.
- A quién le pasas el meme:
A todos los de mi trabajo: félix, JM, Antonio, Carlos, Jaime, Edu, Alberto y Alfredo (a ver si se anima el blog de unkasoft y nos quitamos un poco de presión), elvis (enhorabuena por el artículo en shaderx), vicente (anímate a mostrarte al mundo :P), a la gente de planet statos (venga zaelsius, aunque quieras ser project manager...).
Suscribirse a:
Entradas (Atom)