Que paseis todos feliz Navidad y próspero año nuevo.
24 dic 2010
15 dic 2010
La solución a las crisis empiezan por cambiar uno mismo.
Recientemente he encontrado en navegapolis una conferencia muy interesante acerca del entorno y nuestro papel como celula de esa comunidad. Es realmente interesante la visión acerca de pensar en que invertimos nuestro esfuerzo. La pregunta que cada uno debe hacerse es ¿realmente el esfuerzo (ya sea de trabajo o económico) va destinado a tus propios principios?.
La conclusión es cuando quieras cambiar tu entorno, hay que empezar por uno mismo.
En la conferencia habla siempre de bancos y economía, pero se puede aplicar a cualquier campo trabajo, desarrollo de proyectos y gestión de equipos.
La conclusión es cuando quieras cambiar tu entorno, hay que empezar por uno mismo.
En la conferencia habla siempre de bancos y economía, pero se puede aplicar a cualquier campo trabajo, desarrollo de proyectos y gestión de equipos.
30 nov 2010
Envianos un audio para el podcast 100 de javaHispano
La próxima semana publicaremos el número 100 de javaHispano. Para dicho número, nos gustaría nos envieis audios de 1-2 minutos hablando, opinando, valorando o incluso criticando acerca del podcast. Puede quedar bastante bién.
Esta semana estoy preparando el podcast que consistirá en un recopilatorio de momentos interesantes del podcast. Anticiparos que durará 3-4 horas.
Podeis enviar vuestro audio a jorgesub arroba gmail punto com.
Mucho animo. Esperamos el tuyo.
Gracias y saludos,
Jorge Rubira
Esta semana estoy preparando el podcast que consistirá en un recopilatorio de momentos interesantes del podcast. Anticiparos que durará 3-4 horas.
Podeis enviar vuestro audio a jorgesub arroba gmail punto com.
Mucho animo. Esperamos el tuyo.
Gracias y saludos,
Jorge Rubira
21 nov 2010
La neurociencia será un campo a tener en cuenta para los programadores - Opinión

Recientemente he visto un capítulo de Redes que me ha gustado mucho sobre el efecto del ejercicio en la mente. De hecho, la búsqueda de la eficiencia mental es un tema que me interesa mucho porque la programación, así como cualquier trabajo creativo, es una cuestión intelectual y mental.
Desde hace pocos años se está hablando de la neurociencia como una disciplina que se está investigando cada vez más en la que se están descubriendo cosas interesantes como las zonas que utilizamos ante diferentes estimulaciones o la posibilidad incluso de leer y plasmar en una pantalla lo que se está pensando (figuras sencillas como cuadrados o circulos, claramente).
A medida que este campo avance, los trabajos que sean plenamente creativos irán siendo más eficientes, minimizando en gran medida, casos de depresión que se presentan por un stress continuado ocasionado por las presiones y la carga de trabajo (no material).
Aquí teneis varios recursos, videos y audios que me han parecido interesantes:
El primero a destacar es este donde hacen pruebas con ratas en las que algunas hacen ejercicio y otras no.
http://www.ivoox.com/deporte-para-cerebro-mas-sano-redes-72-audios-mp3_rf_426045_1.html
El segundo que me parece interesante es este donde jovenes inventigadores hablan de su trabajo y cual es el objetivo en la actualidad (prioridades en el tratamiento de enfermedades y problemas mentales y fármacos).
http://www.youtube.com/watch?v=wb_KJ2MhmQo
Un tercer número, también sería otro capítulo de Redes:
http://www.ivoox.com/pon-forma-tu-cerebro-redes-69-audios-mp3_rf_403409_1.html
Un cuarto final es un tanto filosófico y un tanto introduccion y teórico. Pero digno para estar en esta lista:
http://www.ivoox.com/neurociencia-cognitiva-mente-cerebro-computacion-audios-mp3_rf_417961_1.html
Si conoceis algún audio o video sobre estos temas, se agradecerá vuestros links ya que es un tema que me interesa mucho.
Saludos y que los disfruteis.
Desde hace pocos años se está hablando de la neurociencia como una disciplina que se está investigando cada vez más en la que se están descubriendo cosas interesantes como las zonas que utilizamos ante diferentes estimulaciones o la posibilidad incluso de leer y plasmar en una pantalla lo que se está pensando (figuras sencillas como cuadrados o circulos, claramente).
A medida que este campo avance, los trabajos que sean plenamente creativos irán siendo más eficientes, minimizando en gran medida, casos de depresión que se presentan por un stress continuado ocasionado por las presiones y la carga de trabajo (no material).
Aquí teneis varios recursos, videos y audios que me han parecido interesantes:
El primero a destacar es este donde hacen pruebas con ratas en las que algunas hacen ejercicio y otras no.
http://www.ivoox.com/deporte-para-cerebro-mas-sano-redes-72-audios-mp3_rf_426045_1.html
El segundo que me parece interesante es este donde jovenes inventigadores hablan de su trabajo y cual es el objetivo en la actualidad (prioridades en el tratamiento de enfermedades y problemas mentales y fármacos).
http://www.youtube.com/watch?v=wb_KJ2MhmQo
Un tercer número, también sería otro capítulo de Redes:
http://www.ivoox.com/pon-forma-tu-cerebro-redes-69-audios-mp3_rf_403409_1.html
Un cuarto final es un tanto filosófico y un tanto introduccion y teórico. Pero digno para estar en esta lista:
http://www.ivoox.com/neurociencia-cognitiva-mente-cerebro-computacion-audios-mp3_rf_417961_1.html
Si conoceis algún audio o video sobre estos temas, se agradecerá vuestros links ya que es un tema que me interesa mucho.
Saludos y que los disfruteis.
5 nov 2010
Ley de Registro Civil, el hijo tendrá los apellidos de los padres ordenados alfabéticamente - Experimento práctico
Introducción:
Recientemente se ha publicado una noticia acerca de una modificación que se está fraguando en España en la Ley de Registro Civil en el que para igualar el hombre a la mujer el nombre de los apellidos se pondrán de manera ordenada alfabéticamente (en caso de no ponerse de acuerdo).
http://www.diariovasco.com/20101104/mas-actualidad/sociedad/apellidos-alfabetico-201011041307.html
http://www.meneame.net/story/llamazares-avisa-variable-alfabeto-puede-traer-consecuencias/1
Sin embargo, es curioso que ciertos políticos que han redactado la ley no se hayan dado cuenta de que a medida que pasen generaciones la probabilidad de tener los mismos apellidos será muy alta en el caso de aplicarse con habitualidad. Por ello, me ha parecido interesante realizar un algoritmo para comprobar a que velocidad, (en generaciones), perderiamos los apellidos que tenemos.
El algoritmo:
Aquí teneis el algoritmo. Es algo muy sencillo. Hay dos constantes para configurar el número de personas de muestra y el número de apellidos. Los apellidos vamos a tratarlos como enteros para generarlos aleatoriamente más facilmente. En cada generación, cada pareja genera dos nuevas personas y estas fallecen. Se guarda en una matriz cuantos apellidos tanto en el primer apellido como en el segundo hay de cada. Finalmente se visualiza el resultado en csv para poder hacer gráficas a través de un Excel:
import java.util.ArrayList;
public class Apellidos {
public static int PERSONAS_POR_GENERACION=1000;
public static int TOTAL_APELLIDOS=300;
private int ape1;
private int ape2;
public Apellidos(int ape1, int ape2){
this.ape1=ape1;
this.ape2=ape2;
}
public static void main(String arg[]){
int contApellidos[][]=new int[20][TOTAL_APELLIDOS];
ArrayList<Apellidos> personas=new ArrayList<Apellidos>();
//Se insertan apellidos aleatorios
for (int n=0;n<PERSONAS_POR_GENERACION;n++){
int nApe1=(int)(Math.random()*TOTAL_APELLIDOS);
int nApe2=(int)(Math.random()*TOTAL_APELLIDOS);
Apellidos nuevo=new Apellidos(nApe1, nApe2);
personas.add(nuevo);
}
//Cada pareja tienen dos hijos y cuando muere una generación (1000 personas)
for (int n=0;n<20;n++){
for (int m=0;m<PERSONAS_POR_GENERACION;m+=2){
Apellidos hombre=personas.get(m);
Apellidos mujer=personas.get(m+1);
for (int i=0;i<2;i++){
personas.add((int)(Math.random()*(personas.size()-1000))+1000,
new Apellidos(
Math.min(hombre.ape1, mujer.ape1),
Math.max(hombre.ape1, mujer.ape1)
)
);
}
//Contamos los apellidos de la gente que va a fallecer para así ver la linealidad de la generación inicial
contApellidos[n][hombre.ape1]++;
contApellidos[n][mujer.ape1]++;
}
for (int m=0;m<PERSONAS_POR_GENERACION;m++){
personas.remove(0);
}
}
//Visualización de la cantidad de apellidos para cada generacion
for (int m=0;m<TOTAL_APELLIDOS;m++){
for (int n=0;n<20;n++){
System.out.print(contApellidos[n][m] + ";");
}
System.out.println();
}
}
}
Resultados:
En la primera generación, claramente tendríamos todos los apellidos:

En la segunda generación se empizan a ver las primeras consecuencias en los últimos apellidos:

En la generación tercera:

En la generación cuarta:

Finalmente en la simulación, en la generación 12 ya eran todos los apellidos eran iguales y sigue una progresión de valor(generacion)=valor(generacion-1)*2 hasta que llega al 50% que va bajando el ritmo de crecimiento ya que se empiezan a juntar parejas con el mismo apellido. Ver gráfica:

Conclusión:
La desaparición de los apellidos se concentrarían en uno único de manera que en varias generaciones todos tendríamos el mismo apellido.
Conclusión 2:
Harían falta más matemáticos y estadísticos y personas de ciencias exactas ejerciendo como políticos. ;)
ACTUALIZACION: Dado el feedback recibido, aclarar que la ley tal y como define el primer link que pongo, se aplica en caso de discusión. Este sería el caso en el que se aplica de manera habitual. He modificado la noticia para aclarar este hecho.
Recientemente se ha publicado una noticia acerca de una modificación que se está fraguando en España en la Ley de Registro Civil en el que para igualar el hombre a la mujer el nombre de los apellidos se pondrán de manera ordenada alfabéticamente (en caso de no ponerse de acuerdo).
http://www.diariovasco.com/20101104/mas-actualidad/sociedad/apellidos-alfabetico-201011041307.html
http://www.meneame.net/story/llamazares-avisa-variable-alfabeto-puede-traer-consecuencias/1
Sin embargo, es curioso que ciertos políticos que han redactado la ley no se hayan dado cuenta de que a medida que pasen generaciones la probabilidad de tener los mismos apellidos será muy alta en el caso de aplicarse con habitualidad. Por ello, me ha parecido interesante realizar un algoritmo para comprobar a que velocidad, (en generaciones), perderiamos los apellidos que tenemos.
El algoritmo:
Aquí teneis el algoritmo. Es algo muy sencillo. Hay dos constantes para configurar el número de personas de muestra y el número de apellidos. Los apellidos vamos a tratarlos como enteros para generarlos aleatoriamente más facilmente. En cada generación, cada pareja genera dos nuevas personas y estas fallecen. Se guarda en una matriz cuantos apellidos tanto en el primer apellido como en el segundo hay de cada. Finalmente se visualiza el resultado en csv para poder hacer gráficas a través de un Excel:
public class Apellidos {
public static int PERSONAS_POR_GENERACION=1000;
public static int TOTAL_APELLIDOS=300;
private int ape1;
private int ape2;
public Apellidos(int ape1, int ape2){
this.ape1=ape1;
this.ape2=ape2;
}
public static void main(String arg[]){
int contApellidos[][]=new int[20][TOTAL_APELLIDOS];
ArrayList<Apellidos> personas=new ArrayList<Apellidos>();
//Se insertan apellidos aleatorios
for (int n=0;n<PERSONAS_POR_GENERACION;n++){
int nApe1=(int)(Math.random()*TOTAL_APELLIDOS);
int nApe2=(int)(Math.random()*TOTAL_APELLIDOS);
Apellidos nuevo=new Apellidos(nApe1, nApe2);
personas.add(nuevo);
}
//Cada pareja tienen dos hijos y cuando muere una generación (1000 personas)
for (int n=0;n<20;n++){
for (int m=0;m<PERSONAS_POR_GENERACION;m+=2){
Apellidos hombre=personas.get(m);
Apellidos mujer=personas.get(m+1);
for (int i=0;i<2;i++){
personas.add((int)(Math.random()*(personas.size()-1000))+1000,
new Apellidos(
Math.min(hombre.ape1, mujer.ape1),
Math.max(hombre.ape1, mujer.ape1)
)
);
}
//Contamos los apellidos de la gente que va a fallecer para así ver la linealidad de la generación inicial
contApellidos[n][hombre.ape1]++;
contApellidos[n][mujer.ape1]++;
}
for (int m=0;m<PERSONAS_POR_GENERACION;m++){
personas.remove(0);
}
}
//Visualización de la cantidad de apellidos para cada generacion
for (int m=0;m<TOTAL_APELLIDOS;m++){
for (int n=0;n<20;n++){
System.out.print(contApellidos[n][m] + ";");
}
System.out.println();
}
}
}
En la segunda generación se empizan a ver las primeras consecuencias en los últimos apellidos:

En la generación tercera:

En la generación cuarta:
Finalmente en la simulación, en la generación 12 ya eran todos los apellidos eran iguales y sigue una progresión de valor(generacion)=valor(generacion-1)*2 hasta que llega al 50% que va bajando el ritmo de crecimiento ya que se empiezan a juntar parejas con el mismo apellido. Ver gráfica:
Conclusión:
La desaparición de los apellidos se concentrarían en uno único de manera que en varias generaciones todos tendríamos el mismo apellido.
Conclusión 2:
Harían falta más matemáticos y estadísticos y personas de ciencias exactas ejerciendo como políticos. ;)
ACTUALIZACION: Dado el feedback recibido, aclarar que la ley tal y como define el primer link que pongo, se aplica en caso de discusión. Este sería el caso en el que se aplica de manera habitual. He modificado la noticia para aclarar este hecho.
31 oct 2010
Videotutoriales Solo Programadores (Compilation)
Inicialmente, en este blog iba a publicar los videotutoriales uno a uno con sus respectivas presentaciones. Sin embargo, me he topado con falta de tiempo para ello y la web donde se albergaban ha dejado de funcionar. Por ello, he subido todos ellos a un servidor de compartir ficheros y he pensado en hacer una compilación de todos ellos en este post. Así que aquí teneis todos los videotutoriales que hice cuando estaba en la época de colaboración con Solo Programadores. Espero que los disfruteis.
135-El juego del fugitivo (Java SE)
136-Conversor de divisas (Java SE)
137-Buscando la pareja (.NET)
138-Aprendiendo ingles (Flash)
139-Gráficas dinámicas con PHPLot (PHP)
140-Patos al agua (Java3D)
141-Boxeo en el móvil (Java ME)
142-Matamarcianos con Laszlo y Eclipse (Laszlo)
143-Algoritmo minimax (Java EE)
144-Pong3D con Java3D (Java 3D)
145-Bolera virtual (Java SE)
146-Introducción MyMobileWeb (Java EE)
147-JavaCup (Torneo de futbol virtual)
148-Solo Pilotos (Game Maker)
149-Juego de coches (Java ME)
151-Agenda de citas (Java SE)
152-Juego JavaScript
153-Introducción a CakePHP (PHP)
154-Busqueda de soluciones IA (Java SE)
155-Chat con Java (Java SE)
156-Juego del trilero (Java SE)
157-Autoexamen (C#)
158-Menu arts (Java SE)
159-El juego del ahorcado (SharpDevelop)
160-Disco duro remoto (PHP)
161-Tiro a la diana (Java SE)
162-Busca las minas (Java SE)
164-Tragaperras (Java SE)
165-SP Tetris (Java SE)
166-SP Pang (Java SE)
167-Batalla naval (Java SE)
168-Interacción J2ME+J2EE+J4ME (Java ME+Java SE)
169-Ritmico. (Java SE)
135-El juego del fugitivo (Java SE)
136-Conversor de divisas (Java SE)
137-Buscando la pareja (.NET)
138-Aprendiendo ingles (Flash)
139-Gráficas dinámicas con PHPLot (PHP)
140-Patos al agua (Java3D)
141-Boxeo en el móvil (Java ME)
142-Matamarcianos con Laszlo y Eclipse (Laszlo)
143-Algoritmo minimax (Java EE)
144-Pong3D con Java3D (Java 3D)
145-Bolera virtual (Java SE)
146-Introducción MyMobileWeb (Java EE)
147-JavaCup (Torneo de futbol virtual)
148-Solo Pilotos (Game Maker)
149-Juego de coches (Java ME)
151-Agenda de citas (Java SE)
152-Juego JavaScript
153-Introducción a CakePHP (PHP)
154-Busqueda de soluciones IA (Java SE)
155-Chat con Java (Java SE)
156-Juego del trilero (Java SE)
157-Autoexamen (C#)
158-Menu arts (Java SE)
159-El juego del ahorcado (SharpDevelop)
160-Disco duro remoto (PHP)
161-Tiro a la diana (Java SE)
162-Busca las minas (Java SE)
164-Tragaperras (Java SE)
165-SP Tetris (Java SE)
166-SP Pang (Java SE)
167-Batalla naval (Java SE)
168-Interacción J2ME+J2EE+J4ME (Java ME+Java SE)
169-Ritmico. (Java SE)
Etiquetas:
Screencast,
Solo Programadores,
Videotutoriales
24 oct 2010
Java Jive 1940s
Mmm, escuchando esta canción me recuerda a algo familiar. Para el deleite de a los que les gusta lo clásico.
Aquí la letra:
http://www.bluesforpeace.com/lyrics/java-jive.htm
Aquí la letra:
http://www.bluesforpeace.com/lyrics/java-jive.htm
13 sept 2010
13 de septiembre - Dia del programador
No lo sabía pero gracias "Fires" acabo de descubrir que hoy era el día del programador.
http://proyectosbeta.blogspot.com/2010/09/feliz-dia-del-programador.html
Para celebrarlo ha solicitado que escribamos alguna anécdota en el siguiente post.
http://proyectosbeta.blogspot.com/2010/09/celebremos-el-dia-del-programador-con.html
y como tenía tiempo libre, así lo he hecho. ¡Que curioso que sea el día 256 = 2^8.
Es una historia que le puede pasar a cualquiera pero en esta ocasión con final inesperado. Y en general se saca una moraleja de todo ello de la cual me ha dejado marca (por vivirla a través de compañeros).
Borrar algo de manera irreversible siempre es un trauma. Es mayor aún cuando lo que has borrado lleva mucho trabajo o no es tuyo. Pues bién aquí una anecdota que le paso a un compañero.
1. Se realiza una nueva instalación en un cliente.
2. Durante una semana, el cliente se dedica a introducir los datos maestros.
3. A la semana le piden a un técnico que mire ciertas cosas y modifique otras el caso es que derrepente se oye.
- "Noooo!!". Exclama el técnico.
- "¿Que pasa?". Preguntamos el resto
El técnico palido no contesta.
- "¿Ocurre algo?". Le insistimos.
- "He borrado la tabla de productos". Dijo con voz cabizbaja.
- "¡¿Que me dices?! Pero, ¿estas en serio?". Preguntamos.
- "Si, si. He ido a hacer una cosa y he lanzado un borrado sin querer".
- "Y ¿Había muchos registros?". Preguntamos.
- "¡Hombre!, Pues no sé. Pero si el cliente ha estado trabajando durante toda la semana para meter los productos ... Datos tenía que haber". Dijo el hombre más pálido todavia.
El caso es que el tema se tuvo que comunicar al gerente para ver que se hacia.
Finalmente, se decidió comunicarse al cliente. De esto se iba a encargar el propio gerente/responsable.
- "Ya verás como se arma gorda". Dijo el técnico.
(A los 5 minutos)
- Gerente: "Oye! Que ya está comunicado".
- "¿Y que ha dicho?". Preguntó el técnico.
- Con una cara de no me lo puedo creer el responsable dijo. "A dicho que: 'mejor porque así los vuelve a meter y aprende a utilizar la aplicación' ".
- "Suspiro de todos con cara de estupefacción".
---------
Hasta aquí la historia que acabo con final feliz. Sin embargo, lo normal es que una cosa así acabe mal. Por ello sigo las siguientes reglas:
- Siempre que se pueda usar un control de versiones y hacer commits.
- Si puedo, nunca borro nada, siempre renombro la vieja versión o la versión a borrar.
- Si no puedo renombrar me hago una copia de lo que tiene antes de trabajar.
- Si no puedo copiar porque son muchos datos o no se puedan copiar por diferente indole, miro lo que voy a ejecutar si esto puede ser catastrófico durante 30-60 segundos antes de lanzarlo.
- Incluso aún siguiendo esas reglas me he llevado algún susto de pulsar la tecla que no debía sin intención, aunque nunca he pasado una situción como la de mi compañero (por suerte). ¡Siempre he tenido una copia de lo borrado accidentalmente!.
Es muy costoso insertar registros, código o información y muy fácil de borrarla.
Feliz día del programador :)
http://proyectosbeta.blogspot.com/2010/09/feliz-dia-del-programador.html
Para celebrarlo ha solicitado que escribamos alguna anécdota en el siguiente post.
http://proyectosbeta.blogspot.com/2010/09/celebremos-el-dia-del-programador-con.html
y como tenía tiempo libre, así lo he hecho. ¡Que curioso que sea el día 256 = 2^8.
Es una historia que le puede pasar a cualquiera pero en esta ocasión con final inesperado. Y en general se saca una moraleja de todo ello de la cual me ha dejado marca (por vivirla a través de compañeros).
Borrar algo de manera irreversible siempre es un trauma. Es mayor aún cuando lo que has borrado lleva mucho trabajo o no es tuyo. Pues bién aquí una anecdota que le paso a un compañero.
1. Se realiza una nueva instalación en un cliente.
2. Durante una semana, el cliente se dedica a introducir los datos maestros.
3. A la semana le piden a un técnico que mire ciertas cosas y modifique otras el caso es que derrepente se oye.
- "Noooo!!". Exclama el técnico.
- "¿Que pasa?". Preguntamos el resto
El técnico palido no contesta.
- "¿Ocurre algo?". Le insistimos.
- "He borrado la tabla de productos". Dijo con voz cabizbaja.
- "¡¿Que me dices?! Pero, ¿estas en serio?". Preguntamos.
- "Si, si. He ido a hacer una cosa y he lanzado un borrado sin querer".
- "Y ¿Había muchos registros?". Preguntamos.
- "¡Hombre!, Pues no sé. Pero si el cliente ha estado trabajando durante toda la semana para meter los productos ... Datos tenía que haber". Dijo el hombre más pálido todavia.
El caso es que el tema se tuvo que comunicar al gerente para ver que se hacia.
Finalmente, se decidió comunicarse al cliente. De esto se iba a encargar el propio gerente/responsable.
- "Ya verás como se arma gorda". Dijo el técnico.
(A los 5 minutos)
- Gerente: "Oye! Que ya está comunicado".
- "¿Y que ha dicho?". Preguntó el técnico.
- Con una cara de no me lo puedo creer el responsable dijo. "A dicho que: 'mejor porque así los vuelve a meter y aprende a utilizar la aplicación' ".
- "Suspiro de todos con cara de estupefacción".
---------
Hasta aquí la historia que acabo con final feliz. Sin embargo, lo normal es que una cosa así acabe mal. Por ello sigo las siguientes reglas:
- Siempre que se pueda usar un control de versiones y hacer commits.
- Si puedo, nunca borro nada, siempre renombro la vieja versión o la versión a borrar.
- Si no puedo renombrar me hago una copia de lo que tiene antes de trabajar.
- Si no puedo copiar porque son muchos datos o no se puedan copiar por diferente indole, miro lo que voy a ejecutar si esto puede ser catastrófico durante 30-60 segundos antes de lanzarlo.
- Incluso aún siguiendo esas reglas me he llevado algún susto de pulsar la tecla que no debía sin intención, aunque nunca he pasado una situción como la de mi compañero (por suerte). ¡Siempre he tenido una copia de lo borrado accidentalmente!.
Es muy costoso insertar registros, código o información y muy fácil de borrarla.
Feliz día del programador :)
6 sept 2010
Obama bajará los impuestos a las empresas que inviertan en tecnología y ciencia - Opinión
Recientemente ha aparecido en meneame la siguiente noticia:
http://www.abc.es/20100905/economia/obama-empresas-201009051941.html
Aquí hay que analizar dos puntos muy importantes. La primera es la importancia de la ciencia y la segunda en las ayudas económicas a esta.
¿Como de importante es la ciencia?.
Hace poco ví un video de porque es importante la ciencia.
http://amazings.es/2010/08/29/por-que-es-importante-la-ciencia/
Como bién dice, si mirais a vuestro alrededor, todo lo que nos rodea es ciencia. Me parece sorprendente que tengamos acceso a un montón de información, cachivaches electrónicos moviles que muestran mejores gráficos que las videoconsolas de hace 10 años, la capacidad de plasmar en papel un documento que tienes en pantalla con total perfección, etc.
Realmente me maravillo más cuando miro una memoria MicroSD y pienso la cantidad de cosas que caben allí en esa fina capa que parece que vaya a romperse o salir volando si soplase el viento. Inovar en ciencia es hacer más barato y mejor lo que ya haciamos.
¿Como de importante es apoyar ciencia?.
Pues aquí está el punto malo y tiene que ver con la condición humana. Apoyar a la ciencia es sumamente importante pero hay que definir ¿que es la ciencia?. Pues la ciencia es hacer pruebas, trastear, sacar conclusiones, equivocarse, mejorar y finalmente obtener un conocimiento que te permite hacer algo más rápido.
Entonces, ¿que ocurre cuando se suvenciona la ciencia y el estado paga una suvención si trabajas en un proyecto?. Pues que no se consigue nada o poco, principalmente porque las empresas no desean los objetivos si no la suvención. Y es muy habitual encontrarse con chanchullos de todo tipo inventandose proyectos y trabajos inexistentes para obtener cualquier tipo de ingreso económico con el mínimo esfuerzo. Crear ciencia puede ser precisamente pinchar un XXXXX en un palo y decir que has inovado porque has intentando hacer algo diferente.
Por ello, es interesante la propuesta de Obama. No se trata de pagar suvenciones para que hagan invocación. Se trata de facilitar los costes administrativos o financieros a quienes quieran intentarlo. Pero si el producto es malo, tendrá perdidas de todas formas.
http://www.abc.es/20100905/economia/obama-empresas-201009051941.html
Aquí hay que analizar dos puntos muy importantes. La primera es la importancia de la ciencia y la segunda en las ayudas económicas a esta.
¿Como de importante es la ciencia?.
Hace poco ví un video de porque es importante la ciencia.
http://amazings.es/2010/08/29/por-que-es-importante-la-ciencia/
Como bién dice, si mirais a vuestro alrededor, todo lo que nos rodea es ciencia. Me parece sorprendente que tengamos acceso a un montón de información, cachivaches electrónicos moviles que muestran mejores gráficos que las videoconsolas de hace 10 años, la capacidad de plasmar en papel un documento que tienes en pantalla con total perfección, etc.
Realmente me maravillo más cuando miro una memoria MicroSD y pienso la cantidad de cosas que caben allí en esa fina capa que parece que vaya a romperse o salir volando si soplase el viento. Inovar en ciencia es hacer más barato y mejor lo que ya haciamos.
¿Como de importante es apoyar ciencia?.
Pues aquí está el punto malo y tiene que ver con la condición humana. Apoyar a la ciencia es sumamente importante pero hay que definir ¿que es la ciencia?. Pues la ciencia es hacer pruebas, trastear, sacar conclusiones, equivocarse, mejorar y finalmente obtener un conocimiento que te permite hacer algo más rápido.
Entonces, ¿que ocurre cuando se suvenciona la ciencia y el estado paga una suvención si trabajas en un proyecto?. Pues que no se consigue nada o poco, principalmente porque las empresas no desean los objetivos si no la suvención. Y es muy habitual encontrarse con chanchullos de todo tipo inventandose proyectos y trabajos inexistentes para obtener cualquier tipo de ingreso económico con el mínimo esfuerzo. Crear ciencia puede ser precisamente pinchar un XXXXX en un palo y decir que has inovado porque has intentando hacer algo diferente.
Por ello, es interesante la propuesta de Obama. No se trata de pagar suvenciones para que hagan invocación. Se trata de facilitar los costes administrativos o financieros a quienes quieran intentarlo. Pero si el producto es malo, tendrá perdidas de todas formas.
2 sept 2010
¿Que hará este código? - Parte 1
Este es un ejemplo que ví hace tiempo que me parece muy curioso.
Antes de nada, no vale probar la aplicación, debeis adivinarlo y razonar la respuesta. A ver si acertais que haría este algoritmo escrito en java y por qué.
class A{
}
class B extends A{
}
class Principal{
public void ejecutar(A obj){
System.out.println("Clase A");
}
public void ejecutar(B obj){
System.out.println("Clase B");
}
public static void main(String arg[]){
(new Principal()).ejecutar(null);
}
}
Las opciones que teneis es:
a) Visualiza: Clase A
b) Visualiza: Clase B
c) No compila.
d) Error en tiempo de ejecución (Exception).
Suscribirse a:
Entradas (Atom)