Voy a publicar en elkorcho por entregas y bajo Creative Commons, un trabajo que hice en 2011 para la universidad con dos compañeros mas, sobre Computación Cuántica, y para el que tuve que aprender lo básico de física cuántica. Quede tan maravillado con el tema y lleno de inquietudes cósmicas, que creo conveniente compartirlo con todos, y quien sabe, a lo mejor al igual que yo, alguien aprende algo que no sabía:
En la actualidad, a medida que evoluciona la tecnología aumenta la escala de integración: más transistores en menor espacio, lo que implica microchips más pequeños que, a su vez, se traduce en mayor velocidad de proceso. Basada en esta realidad, la Ley de Moore, que es más bien una observación empírica que una ley, estableció que cada dieciocho meses (y posteriormente se modificó a cada veinticuatro) se duplica el número de transistores contenidos en un circuito integrado (los chips dividen por dos su tamaño, al tiempo que duplican su capacidad).
Pero Moore igualmente vaticinó que llegará un punto en el que sencillamente no sea posible que se siga cumpliendo por problemas de espacio, ya que hay un límite atómico para el tamaño de un transistor. También predice que la tecnología actual habrá de ser sustituida por otro paradigma diferente que permita seguir progresando de manera similar.
Actualmente se están desarrollando transistores de 28 nanómetros, pero el problema radica en que por cada transistor y sus interconexiones tienen que circular electrones, y estos se comportan como partículas cuánticas, y si los canales por los que viajan no son lo suficientemente grandes, tienden a su comportamiento como ondas y saltan de un canal a otro, corrompiendo la información (efecto túnel).
Por otro lado, recordando a grosso modo cómo funciona la computación digital, nuestros ordenadores permiten el paso de la corriente eléctrica o, por el contrario, la interrumpen. Traducido a un lenguaje más manejable para los humanos, estos dos estados (encendido y apagado) se corresponden con dos valores posibles, 1 y 0, que determinan, además, la cantidad de información mínima con que trabaja un ordenador. A esto le llamamos bit. Si, por ejemplo, utilizamos tres bits para almacenar información, y dado que cada bit sólo puede tomar un único valor en un momento determinado (o es 0 o es 1), contemplando todas las posibles combinaciones de esos tres bits podemos representar como máximo ocho valores distintos. ¡Esto ya lo sabíamos!
Pero, ¿qué pasaría si nuestro pequeño almacén de información pudiera tomar simultáneamente varios valores distintos? ¿Y si nuestro bit pudiera valer 0, 1 y combinaciones de estos a la vez?..... Pues que estaríamos ante un nuevo concepto de computación.
miércoles, 29 de agosto de 2012
miércoles, 22 de agosto de 2012
Rehab - Rehabilitación
Ya ha pasado más de la mitad del verano, de hecho solo me quedan 3 o 4 fines de semana libres antes de volver a clase (y sumirme de nuevo en una espiral de trabajo+estudios+no dormir+no divertirse durante los siguientes 9 meses), y aunque no he parado de trabajar, las 4 o 5 semanas con jornada intensiva se han agradecido.
Y es que estar en casa a las 17 de la tarde es una gozada, pese a que he tenido que ponerme al día con los gadgets, las actualizaciones y los ordenadores y no lo he disfrutado tanto como quería, ha sido genial.
Ya he recuperado 4 kilos, y he cambiado mi rutina de ejercicio diario para trabajar tanto piernas como brazos, e intentare mantenerla durante las clases para luchar contra la inactividad física de los informáticos y el tiempo que no perdona (que en unos meses me caen los 30...).
Y es que estar en casa a las 17 de la tarde es una gozada, pese a que he tenido que ponerme al día con los gadgets, las actualizaciones y los ordenadores y no lo he disfrutado tanto como quería, ha sido genial.
Ya he recuperado 4 kilos, y he cambiado mi rutina de ejercicio diario para trabajar tanto piernas como brazos, e intentare mantenerla durante las clases para luchar contra la inactividad física de los informáticos y el tiempo que no perdona (que en unos meses me caen los 30...).
Por fin he conseguido quedar con mis nenas de conteos, y a parte de estar todas maravillosamente guapas, nos pusimos al día de las penas y alegrías (por desgracia más penas que alegrías), y lo pase muy bien.
He completado una frikimeta que tenía pendiente desde hace varios años. Gracias a mi Súper Fricolega Alfa Cristian, y a que en los últimos años han doblado todas las que faltaban, hemos podido realizar un marathon completo (en 3 domingos) de todas las películas de animación del estudio Ghibli. Y ha sido maravilloso. Algunas súper sorpresas como Ponyo, otras sorprendentemente bonitas como Recuerdos del ayer, Susurros del Corazón, Mi vecino Totoro o las mas normales pero buenas de Arrietty, Porco Rosso, Nikki la aprendiz de bruja, y los mega peliculones de La Princesa Mononoke, El Castillo Ambulante, el Viaje de Chihiro, el Castillo en el Cielo o Nausicaa del valle del viento. Ha sido glorioso, genial y digno de mención y recuerdo. Tardaremos unos cuantos años, demasiados en poder volver a ingerir 5 películas nuevas en castellano del mágico estudio Ghibli...
Por fin hemos conseguido terminar el Project Zero IV para Wii, que nos quedo a medias desde el año pasado, y aunque se nos hizo un poco tedioso, tuvo un buen final y dejo buen gusto. Empezamos el Silent Hill Downpour, iremos por más de la mitad, y pese a sus problemas de framerate, sus poco variados enemigos y su ausencia de videos, nos está gustando bastante, tiene mucha exploración, muchas misiones secundarias, la historia aparenta estar muy bien y la vas descubriendo poco a poco según lo mucho que quieras investigar y leer (cosa que me encanta) y por el momento va genial. Espero que en las 3 sesiones que nos quedan podamos acabarlo porque no quisiera dejarlo colgado durante 9 meses...
Sin pensar mucho en la factura del aire acondicionado o los carísimos arreglos del coche, seguiremos aprovechando el tiempo que nos quede, para coger con fuerzas otro año de universidad y extrañas asignaturas relámpago.
¡Id por la sombra!
He completado una frikimeta que tenía pendiente desde hace varios años. Gracias a mi Súper Fricolega Alfa Cristian, y a que en los últimos años han doblado todas las que faltaban, hemos podido realizar un marathon completo (en 3 domingos) de todas las películas de animación del estudio Ghibli. Y ha sido maravilloso. Algunas súper sorpresas como Ponyo, otras sorprendentemente bonitas como Recuerdos del ayer, Susurros del Corazón, Mi vecino Totoro o las mas normales pero buenas de Arrietty, Porco Rosso, Nikki la aprendiz de bruja, y los mega peliculones de La Princesa Mononoke, El Castillo Ambulante, el Viaje de Chihiro, el Castillo en el Cielo o Nausicaa del valle del viento. Ha sido glorioso, genial y digno de mención y recuerdo. Tardaremos unos cuantos años, demasiados en poder volver a ingerir 5 películas nuevas en castellano del mágico estudio Ghibli...
Por fin hemos conseguido terminar el Project Zero IV para Wii, que nos quedo a medias desde el año pasado, y aunque se nos hizo un poco tedioso, tuvo un buen final y dejo buen gusto. Empezamos el Silent Hill Downpour, iremos por más de la mitad, y pese a sus problemas de framerate, sus poco variados enemigos y su ausencia de videos, nos está gustando bastante, tiene mucha exploración, muchas misiones secundarias, la historia aparenta estar muy bien y la vas descubriendo poco a poco según lo mucho que quieras investigar y leer (cosa que me encanta) y por el momento va genial. Espero que en las 3 sesiones que nos quedan podamos acabarlo porque no quisiera dejarlo colgado durante 9 meses...
Sin pensar mucho en la factura del aire acondicionado o los carísimos arreglos del coche, seguiremos aprovechando el tiempo que nos quede, para coger con fuerzas otro año de universidad y extrañas asignaturas relámpago.
¡Id por la sombra!
domingo, 1 de julio de 2012
Reemplazo nocturno
Ahore ÉL duerme en esa cama con ese GusyLuz.
Y amamanta a los demás peluches...
PD: No me extraña que el cerebro artificial de Google se haya dedicado a ver fotos de gatitos por toda la red, son tan monos...
domingo, 17 de junio de 2012
viernes, 11 de mayo de 2012
Resumen Java Tema Pruebas y Calidad del Software
Las pruebas buscan errores y verifican que el programa cumple lo esperado y lo hace bien.
Son costosas en tiempo y recursos.
Hay que probar:
Que haga lo esperado y no haga cosas inesperadas.
Se buscan Situaciones anormales y fallos.
Entradas de datos correctas e incorrectas.
Probar primero partes pequeñas y luego las grandes.
Hay que documentar los casos de prueba, que parámetros recibe, qué debería devolver y que devuelve en cada caso.
Debería realizarlas automáticamente una aplicación o un usuario ajeno, no el propio programador.
Cada vez que se corrige un fallo hay que volver a probarlo todo.
-VERIFICACIÓN: Cumple la especificación?
-VALIDACIÓN: Cubre la necesidad del cliente?
INSPECCIÓN DE SOFTWARE: Análisis técnico del código, las especificaciones y los diagramas para comprobar que sea lo estipulado.
Puede hacerse en todas las fases del desarrollo, y en partes incompletas al ser estático.
(errores de compilación, código no alcanzable, variables no inicializadas o sin uso, bucles infinitos)
PRUEBAS DE SOFTWARE: Ejecutar el programa con datos ficticios y analizar las salidas.
Solo pueden hacerse trás la fase de construcción y requieren planificación porque es dinámico.
-De Integración:
Sistema/Subsistema = funcionan juntos el sistema y componentes?
*Tienen que ser incremental, se añade algo, se prueba, y repetir todo el proceso.
Descendente> 1º estructura, luego los componentes
Ascendente> 1º las funcionalidades pequeñas y luego se agrupan
Rendimiento = fiabilidad y respuesta ante la carga de trabajo, buscar sobrecargas
Entrega y aceptación = cumple los casos de uso y requerimientos?
Los resultados a las entradas son los esperados?
Forzar todos los errores y desbordamientos
-Unitarias o de componentes, son correctos y funcionan cada clase o cada módulo?
Descendente> el control es el programa principal, se crean módulos colaboradores falsos, probar y sustituir por el real.
Ascendente> crear un monitor de prueba para examinar los módulos de nivel mas bajo, probar y sustituir por el módulo superior real, y volver a probar (regresión)
-De Sistemas Ori.Obj: es correcto y útil el esquema de clases? Probar: todos los atributos y métodos de cada clase.
Clases> comprobar que hacen lo definido.
*Basadas en escenarios = probar los casos de uso mas comunes, después los menos, y luego los excepcionales.
*Basadas en Subprocesos = en cadenas de eventos.
DOCUMENTACION:
Para la organización y mantenimiento del código hay que documentarlo, indicando información sobre las funcionalidades, parámetros y resultados.
Precediendo de /** COMENTARIO */ las clases, interfaces, métodos o atributos, con la herramienta (javadoc *.java -private –d javadoc) generamos la documentación en html automáticamente. Son heredables.
-Etiquetas: @param, @return, @throws, @exception, @author, @version.
Son costosas en tiempo y recursos.
Hay que probar:
Que haga lo esperado y no haga cosas inesperadas.
Se buscan Situaciones anormales y fallos.
Entradas de datos correctas e incorrectas.
Probar primero partes pequeñas y luego las grandes.
Hay que documentar los casos de prueba, que parámetros recibe, qué debería devolver y que devuelve en cada caso.
Debería realizarlas automáticamente una aplicación o un usuario ajeno, no el propio programador.
Cada vez que se corrige un fallo hay que volver a probarlo todo.
-VERIFICACIÓN: Cumple la especificación?
-VALIDACIÓN: Cubre la necesidad del cliente?
INSPECCIÓN DE SOFTWARE: Análisis técnico del código, las especificaciones y los diagramas para comprobar que sea lo estipulado.
Puede hacerse en todas las fases del desarrollo, y en partes incompletas al ser estático.
(errores de compilación, código no alcanzable, variables no inicializadas o sin uso, bucles infinitos)
PRUEBAS DE SOFTWARE: Ejecutar el programa con datos ficticios y analizar las salidas.
Solo pueden hacerse trás la fase de construcción y requieren planificación porque es dinámico.
-De Integración:
Sistema/Subsistema = funcionan juntos el sistema y componentes?
*Tienen que ser incremental, se añade algo, se prueba, y repetir todo el proceso.
Descendente> 1º estructura, luego los componentes
Ascendente> 1º las funcionalidades pequeñas y luego se agrupan
Rendimiento = fiabilidad y respuesta ante la carga de trabajo, buscar sobrecargas
Entrega y aceptación = cumple los casos de uso y requerimientos?
Los resultados a las entradas son los esperados?
Forzar todos los errores y desbordamientos
-Unitarias o de componentes, son correctos y funcionan cada clase o cada módulo?
Descendente> el control es el programa principal, se crean módulos colaboradores falsos, probar y sustituir por el real.
Ascendente> crear un monitor de prueba para examinar los módulos de nivel mas bajo, probar y sustituir por el módulo superior real, y volver a probar (regresión)
-De Sistemas Ori.Obj: es correcto y útil el esquema de clases? Probar: todos los atributos y métodos de cada clase.
Clases> comprobar que hacen lo definido.
*Basadas en escenarios = probar los casos de uso mas comunes, después los menos, y luego los excepcionales.
*Basadas en Subprocesos = en cadenas de eventos.
DOCUMENTACION:
Para la organización y mantenimiento del código hay que documentarlo, indicando información sobre las funcionalidades, parámetros y resultados.
Precediendo de /** COMENTARIO */ las clases, interfaces, métodos o atributos, con la herramienta (javadoc *.java -private –d javadoc) generamos la documentación en html automáticamente. Son heredables.
-Etiquetas: @param, @return, @throws, @exception, @author, @version.
Resumen Java Tema Análisis y Diseño Orientado a Objetos
Ingeniería del Software: Se buscan soluciones mediante sistemas efectivos en calidad y coste, con un ciclo de vida ordenado en etapas:
1º-Planificación y Especificación
2º-Análisis de requisitos
3º-Especificación Funcional
4º-Diseño
5º-Codificación y Pruebas
6º-Implantación y Mantenimiento.
FASES:
1º-Planificación: captar las necesidades del cliente. Plantear Casos de Uso (que acción -> que reacción), [nombre, actores, importancia, descripción]. Sirve como contrato.
2º-Analisis: traducir el problema en soluciones y decidir como llevarlo a cabo. Ampliar Casos de uso. Punto de vista externo.
3º-Funciones: crear el Diagrama de Clases con los objetos y roles, sus atributos y relaciones. Punto de vista interno.
4º-Diseño: estructurar las soluciones, definir Diagrama de Clases detallado, las estructuras de datos y la interfaz.
5º-Construcción: Escritura del código en iteraciones repetibles de subconjuntos para ir completando partes, probándolas y corrigiéndolas.
6º-Instalación: puesta en marcha del sistema, y formación a los usuarios.
UML (Unified Modeling Languaje)
Es una notacion visual para representar diagramas, orientado a Objetos (con entidades, relaciones, atributos y operaciones). Nos da una perspectiva del sistema. Representan fases o etapas.
-Diagrama de Casos de Uso, muestra casos de uso, actores y sus relaciones:
ACTOR: Elemento externo al sistema que interactúa con el. Rol(es) del usuario.
CASO DE USO: Unidad funcional coherente realizada por el sistema (acción-reacción).
EXTEND: el que apunta aumenta el comportamiento del Apuntado.
INCLUDE: el que apunta incluye la función del apuntado.
-Diagrama de Clases muestra clases(nombre, atributos y operaciones), interfaces(sin inplementación) y sus relaciones. Es estático.
Asociaciones pueden ser entre 2 clases (binarias) o mas. Cardinalidad (0,1,n)...(0,1,n)
AGREGACIÓN: TODO <>--- PARTE
COMPOSICIÓN: 1 <#>--- n Pertenencia.
HERENCIA: PADRE <|--- Hija
Trucos:
subrayar los nombres, ver que relaciones tienen para plantear Clases.
buscar "es", "tiene", "consta de" para hallar las Relaciones.
las descripciones contendrán Atributos.
los verbos indican las Operaciones, y la información que intercambian son los parámetros.
1º-Planificación y Especificación
2º-Análisis de requisitos
3º-Especificación Funcional
4º-Diseño
5º-Codificación y Pruebas
6º-Implantación y Mantenimiento.
FASES:
1º-Planificación: captar las necesidades del cliente. Plantear Casos de Uso (que acción -> que reacción), [nombre, actores, importancia, descripción]. Sirve como contrato.
2º-Analisis: traducir el problema en soluciones y decidir como llevarlo a cabo. Ampliar Casos de uso. Punto de vista externo.
3º-Funciones: crear el Diagrama de Clases con los objetos y roles, sus atributos y relaciones. Punto de vista interno.
4º-Diseño: estructurar las soluciones, definir Diagrama de Clases detallado, las estructuras de datos y la interfaz.
5º-Construcción: Escritura del código en iteraciones repetibles de subconjuntos para ir completando partes, probándolas y corrigiéndolas.
6º-Instalación: puesta en marcha del sistema, y formación a los usuarios.
UML (Unified Modeling Languaje)
Es una notacion visual para representar diagramas, orientado a Objetos (con entidades, relaciones, atributos y operaciones). Nos da una perspectiva del sistema. Representan fases o etapas.
-Diagrama de Casos de Uso, muestra casos de uso, actores y sus relaciones:
ACTOR: Elemento externo al sistema que interactúa con el. Rol(es) del usuario.
CASO DE USO: Unidad funcional coherente realizada por el sistema (acción-reacción).
EXTEND: el que apunta aumenta el comportamiento del Apuntado.
INCLUDE: el que apunta incluye la función del apuntado.
-Diagrama de Clases muestra clases(nombre, atributos y operaciones), interfaces(sin inplementación) y sus relaciones. Es estático.
Asociaciones pueden ser entre 2 clases (binarias) o mas. Cardinalidad (0,1,n)...(0,1,n)
AGREGACIÓN: TODO <>--- PARTE
COMPOSICIÓN: 1 <#>--- n Pertenencia.
HERENCIA: PADRE <|--- Hija
Trucos:
subrayar los nombres, ver que relaciones tienen para plantear Clases.
buscar "es", "tiene", "consta de" para hallar las Relaciones.
las descripciones contendrán Atributos.
los verbos indican las Operaciones, y la información que intercambian son los parámetros.
Resumen Java Tema Ficheros y Persistencia
A través de un flujo (Stream): I/O, leer/escribir, Read/Write, ya sea a un fichero, a una red o a memoria. java.io
Los Streams se abren, se utilizan y SIEMPRE se cierran con .close(). Pueden producir excepciones catch(IOException ioe)
File sirve para manejar archivos, obtener información o crearlos, pero no es un flujo. exist(), isFile(), isDirectory().
RandomAccessFile(fichero, r/rw) permite acceder a una posición concreta y empezar a leer/escribir una cantidad concreta de bytes: seek(), getFilePointer(), length(), mark(), reset(), writeDouble(), readDouble().
Con las hijas de Reader y Writer se pueden manejar Bytes (8bits) o caracteres (16bits).
Con InputStream y OutputStream bytes para datos binarios (imágenes, sonidos, videos).
InputStreamReader y OutputStreamReader para caracteres unicode (16bits) desde o hacia bytes.
FileReader (leer) y FileWriter (escribir) para ficheros de caracteres.
-BufferedReader lee caracteres y texto desde un flujo; readLine(), close()
BufferedReader br = new BufferedReader( new FileReader("ejemplo.txt") );
while ((cad = br.readLine()) != null) System.out.println(cad);
-BufferedWriter escribe caracteres y texto a un flujo en paquetes reduciendo el número de accesos; writeLine(), flush(), close()
BufferedWriter bw = new BufferedWriter( new FileWriter("salida.txt") );
bw.write(cad1);
bw.newLine();
bw.write(cad2);
bw.flush();
-PrintWriter facilita la escritura de valores primitivos y datos con print() y println()
PrintWriter salida = new PrintWriter( new BufferedWriter( new FileWriter("salida.txt") ) );
salida.println(cad1);
salida.println(cad2);
FileInputStream lee bytes desde un archivo
-InputStreamReader traduce los bytes que lee del flujo a caracteres con cierta codificación (€,ñ,í,ó):
BufferedReader br = new BufferedReader( new InputStreamReader( new FileInputStream("ejemplo.txt") , "ISO-8859-1") );
SERIALIZACION: Guardar o leer un objeto entero en disco.
La clase que se vaya a serializar tiene que implementar la interfaz "Serializable".
-ObjectOutputStream escribe los objetos en un fichero en datos binarios con writeObject(objeto):
ObjectOutputStream oos = new ObjectOutputStream( new FileOutputStream("fichero.dat") );
oos.writeObject(objetoaguardar);
oos.close();
-ObjectInputStream siempre hay que hacer un cast al tipo de fichero correcto que recuperemos con readObject():
ObjectInputStream ois = new ObjectInputStream( new FileInputStream("fichero.dat") );
ClaseDestino recipiente = (ClaseDestino) ois.readObject();
Los Streams se abren, se utilizan y SIEMPRE se cierran con .close(). Pueden producir excepciones catch(IOException ioe)
File sirve para manejar archivos, obtener información o crearlos, pero no es un flujo. exist(), isFile(), isDirectory().
RandomAccessFile(fichero, r/rw) permite acceder a una posición concreta y empezar a leer/escribir una cantidad concreta de bytes: seek(), getFilePointer(), length(), mark(), reset(), writeDouble(), readDouble().
Con las hijas de Reader y Writer se pueden manejar Bytes (8bits) o caracteres (16bits).
Con InputStream y OutputStream bytes para datos binarios (imágenes, sonidos, videos).
InputStreamReader y OutputStreamReader para caracteres unicode (16bits) desde o hacia bytes.
FileReader (leer) y FileWriter (escribir) para ficheros de caracteres.
-BufferedReader lee caracteres y texto desde un flujo; readLine(), close()
BufferedReader br = new BufferedReader( new FileReader("ejemplo.txt") );
while ((cad = br.readLine()) != null) System.out.println(cad);
-BufferedWriter escribe caracteres y texto a un flujo en paquetes reduciendo el número de accesos; writeLine(), flush(), close()
BufferedWriter bw = new BufferedWriter( new FileWriter("salida.txt") );
bw.write(cad1);
bw.newLine();
bw.write(cad2);
bw.flush();
-PrintWriter facilita la escritura de valores primitivos y datos con print() y println()
PrintWriter salida = new PrintWriter( new BufferedWriter( new FileWriter("salida.txt") ) );
salida.println(cad1);
salida.println(cad2);
FileInputStream lee bytes desde un archivo
-InputStreamReader traduce los bytes que lee del flujo a caracteres con cierta codificación (€,ñ,í,ó):
BufferedReader br = new BufferedReader( new InputStreamReader( new FileInputStream("ejemplo.txt") , "ISO-8859-1") );
SERIALIZACION: Guardar o leer un objeto entero en disco.
La clase que se vaya a serializar tiene que implementar la interfaz "Serializable".
-ObjectOutputStream escribe los objetos en un fichero en datos binarios con writeObject(objeto):
ObjectOutputStream oos = new ObjectOutputStream( new FileOutputStream("fichero.dat") );
oos.writeObject(objetoaguardar);
oos.close();
-ObjectInputStream siempre hay que hacer un cast al tipo de fichero correcto que recuperemos con readObject():
ObjectInputStream ois = new ObjectInputStream( new FileInputStream("fichero.dat") );
ClaseDestino recipiente = (ClaseDestino) ois.readObject();
Suscribirse a:
Entradas (Atom)


