Tras la chorrada alla vamos, a luchar contra lo inluchable. El comienzo de esta practica habla sobre la sobrecarga de procesos de un PC, para lo cual partimos de un par de ejemplos, uno que imprime “Dong!” casa segundo y otro que imprime “Ding!” cada vez que pulsamos Intro. Al tratar de realizar ambos a la vez, falla, ya que sobrecarga los recursos y necesita más tiempo para ello. Pensamos que si el retardo del “Dong!” era aumentado, el programa se ejecutaria correctamente. Nos equivocamos, como de costumbre, y seguia yendo mal.

El segundo ejercicio parece fácil, te habla sobre como la CPU reparte el tiempo de ejecución de las tareas según el número de “threads” de los que la tarea se componga. La verdad que este ejercicio no lo hemos entendido bien, no entendemos la utilidad de esto, asi que si alguien se quiere dignar a comentarnos algo se lo agradeceriamos… si no tocara tirar de tutoria…

En el ejercicio 3 habla del peligro de tener multiples tareas a la vez, el llamado “multithreading”. En el ejemplo de los unos y ceros se ve a la perfeccion, ya que van apareciendo de manera aleatoria, sin ningun orden, ya que ambas tareas coinciden en el tiempo y se impone la una a la otra cada vez, sin, a nuestro parecer, un motivo. Creemos que en la clase “RaceConditionSolved” mediante la clase Runnable a traves del objeto “eventDispacherRunnable”, el cual añade al final del main, lo que hace que se hagan 3 métodos, el write1, el write2, y eventDispacher, por lo cual no existe mezcla ya que el último retarda la ejecución de los otros métodos. Algo así entendimos.

Del último ejercicio, tras un buen rato mirando… no hemos sacado nada en claro, asi que no comentamos nada….

La verdad que esta práctica no se nos dio bien, pero es que no entendemos bien el porque de querer separar tanto las cosas, cuando en teoria, en java, las cosas se ejecutan en un orden, el cual puedes definir tu al realizar el programa. Sin más os dejamos hasta la proxima semana. Esta semana no dejaremos frase, si no una pequeña reivindicación…

RAUL SELECCION!!!! (Aprovechando que dan la lista el viernes, a ver si entra Aragones aqui y lo ve xD)

Ejercicio 1

No los vamos a resolver, son simplemente de añadir o cambiar cosas para ver las diferencias en la ventana que aparece al compilar y ejecutar. Lo principal era aprender a usar los métodos para variar aspectos de Frame’s, Label’s y Panel’s. Aquí descubrimos la mayor virtud del API, recordad que las clases en Swing empiezan siempre por “J”. Para ello comenzamos con el entrañable “Hello World”.

Los métodos más importantes respecto a los Frames (ventana en sí) fueron (todos a partir del objeto frame.* ):

setDefaultCloseOperation() : Este método te permite realizar hasta 4 operaciones distintas, en este caso fue “EXIT_ON_CLOSE”, para cerrar la ventana que aparecía.

setSize(int width, int height) : Para dar el tamaño a nuestra ventana, primero el ancho y luego el alto.

setVisible(boolean b) : Este es el método más importante (o eso creemos), ya que si “b” es false, la ventana no se mostrará, tiene que estar obligatoriamente en true

En cuanto a Label (etiqueta), a partir del objeto label.* :

setOpaque(boolean b) : Otro parecido a setVisible() pero que lo que hace es que puedas cambiar el color de la etiqueta, “volviendola opaca” por así decirlo, ya que por definición es transparente.

setBackground(Color bg) : Da color a la etiqueta, a partir de una serie de colores que puedes importar: red, blue, green… o a partir de coordenadas que des (el negro es 000000 y el blanco FFFFFF por ejemplo)

Respecto a Panel, existen dos métodos (tengo mis dudas pero creo que ambos pertenecen aquí):

getContentPane() : Para meter el contenedor o “Panel” dentro de la ventana o “Frame”

add(label) : Para añadir al “cosas” al contenedor, en este caso una etiqueta o Label.

En cuanto a la clase HelloWorldGUIDelayed, el efecto que causa es un retardo en la aparición de la ventana, y al cambiar SystemExit(1) por SystemExit(0) lo que hace es bloquear la aparicion de la ventana.

Ejercicio 2:

El ejercicio comienza pidiendo crear una clase “HelloWorldGUIDeaf” que omita usar el método del manejador de ventanas que explica la teoria. Quitando el método setDefaultCloseOperation(), no existe ninguna modificación, al ejecutar aparece la misma ventana y se cierra “clickeando” en el aspa como siempre.

La clase “HelloWorldGUIUndecorated” crea un cuadro gris sin bordes ni nada en donde esta colocada nuestra etiqueta “Hello World”. Para comprobarlo hay que instanciar el método setUndecorated(true) a Frame… Una cosa, hay que colocarlo antes de setVisible()!!!

Por ultimo, el uso del “Look&Feel” no se muestra claramente, ya que a nosotros nos sale siempre el decorado por defecto de Java xD.

Ejercicio 3:

Vamos a crear nuestra ventana con fondo negro y tamaño máximo y letra blanca. Lo primero sin problema, ya lo hicimos en la primera parte de la práctica usando setOpaque(true) y setBackground(Color.black) habiendo importado previamente la clase java.awt.Color; la segunda parte, es decir el tamaño máximo nos llevo más problemas, ya que no encontramos ningún método, y tiramos por la cuenta de la vieja… si la resolución es de 1024 x 768, probemos así y… Eureka!! salio bien!!

Aquí está lo más adelantado a lo que hemos llegado, ni sale el texto blanco, ni centrado ni nada, pero tras incontables horas es lo más avanzado que hemos logrado y estamos muy orgullosos… asi que os toca verlo xD. Pulsando en la imagen, aparecera en grande y podreis observar esta chapuza/obra de arte en todo su esplendor

Os dejamos amigos, no sin dejar nuestra frase habitual…

Frase de la semana: A caballo regalado, ya tenemos un caballo Variación de la frase hecha en mi pueblo, muestra que lo importante es la intención en los regalos, no realmente su valor como tal…

Nosotros queriamos crear un 4 en raya, es decir, un Conecta 4. Todo empezo bien, al pensar nuestra idea quedo algo sencillo y que no daría ningún problema… una matriz para hacer el tablero… un par de bucles for para los turnos y la comprobación de si existia un 4 en raya, los char para las fichas…

Total, que tanto Dani como yo eramos felices, pero a poco que empezamos a ver que aparecían cosas tipo herencia y pensamos… malo…, luego algoritmos, colas, pilas… y salvese quien pueda. Fuimos a trancas y barrancas hasta llegar a lo que tenemos hasta ahora:

Son cuatro clases, con las que mas o menos hemos implementado pero que nos dan algun pequeño fallo como la llamada a un método de distinta clase o la herencia en si, pero no nos lo explicamos ya tras haber estado mirandolo durante largos ratos y ver que son iguales que los ejemplos… pero a nosotros no nos saldra por ser alumnos y a los “profes” si por eso, porque son “profes”

En fin, fue una experiencia buena, porque intentabas crear algo con una utilidad mas o menos amena, no como los clasicos archivos para almacenar gente y demas cosas que hacemos. Ahora valor y al toro, que la parte grafica ya no se nos resiste!!!

Saludos cordiales a todos y hasta la proxima (es decir mañana, buffff…)

Pues bien, en la práctica 6 manejamos colas y pilas utilizando memoria estática (arrays). Ahora, el objetivo principal de la práctica 7 es comprender el funcionamiento de la memoria dinámica y las posibilidades que nos aporta en java. Básicamente tendremos que coger todas las partes donde utilizamos arrays en la practica 6 y sustituirlas por una nueva forma de plantear el problema, utilizando estructuras dinámicas. Por lo menos todo el código ya está escrito, aunque me temo que en este caso, había que usar el cerebro un poco más de lo normal.

Desde luego para afrontar las cuestiones deberíamos de tener claro que los tamaños van a ser dinámicos con lo cual no tendremos que preocuparnos de definirlos con anterioridad pudiendo meter lo que queramos.

Una de las principales ventajas de la memoria dinámica es que no ocupa recursos ya que no tiene que prevenir reservando memoria que cree que va a necesitar de modo que aprovecha mejor la memoria.

Saludos y hasta otra amigos!!

Frase de la semana: El hombre ha de fijar un final para la guerra. Si no, la guerra fijará un final para el hombre. John F. Kennedy

Muy buenas queridos lectores. Vaya con el tetris, los arrays, las colas, pilas, videojuego, prácticas…. Nos está empezando a doler la cabeza. Poco a poco se nota como esto ya no es tan fácil y que es esencial manejar bien los conceptos dados en clase y desenvolvernos bien en el API porque sino….

Pues bien, en la práctica 6 manejamos colas y pilas utilizando memoria estática (arrays). Ahora, el objetivo principal de la práctica 7 es comprender el funcionamiento de la memoria dinámica y las posibilidades que nos aporta en java. Básicamente tendremos que coger todas las partes donde utilizamos arrays en la practica 6 y sustituirlas por una nueva forma de plantear el problema, utilizando estructuras dinámicas.

Tenemos que tener claro que los tamaños van a ser dinámicos con lo cual no tendremos que preocuparnos de definirlos con anterioridad de modo que podremos meter lo que queramos. Relaccionado con esto último, una de las principales ventajas de la memoria dinámica es que no ocupa recursos ya que no tiene que prevenir reservando memoria que cree que va a necesitar de modo que aprovecha mejor la memoria.

Esta semana, la práctica trataba sobre pilas y colas y en ello andamos liados. Esta enfocada hacia la creación de un Tetris, no entero, su algoritmo sin la parte gráfica.

Lo primero que hicimos es atacar a las piezas, lo cual vimos más fácil ya que creimos que se podia hacer mediante char ya que las piezas tienen forma parecida a diversas letras… la “L” , la “I”, y demás…

Utilizamos un sistema de coordenadas “x” e “y” para saber donde colocar cada pieza :

//Variables de coordenadas

private int x;

private int y;

//Inicio a 0, ya que no hay ningun lugar para las piezas en el inicio

public Pieza() {
x = 0;

y = 0;

}

//Método para mover las piezas

public void mover(int x, int y)
{
this.x = x;
this.y = y;
}

Luego creamos una cola a modo de “contenedor” para así almacenar las piezas creadas anteriormente, con sus límites incluidos (es decir, avisos por si la cola está llena y quiero introducir algo, si está vacia y quiero sacar algo… ). Esto lo logramos ver a nivel teórico, ya que en el práctico nos enrevesamos un poquito y no nos dejaba aplicar el método desencolar de manera correcta, os le colgamos aquí a ver si veis el fallo que tiene…

//Creamos nuestro contenedor llamando a los objetos de la clase Pieza.

public Pieza elementos[];

//Constructor (para crear nuestro contenedor y poder maniobrar con él)

public Contenedor (int elementosTotales) {

elementos = new Pieza (elementosTotales);

}

// Método desencolar (creemos que aquí está el fallo)

public void desencolarPieza() {

int primerElemento;
Pieza elemento = elementos[primerElemento];
return elemento;
}

A partir de aquí no pudimos seguir más, pero os dejamos una respuesta a la pregunta de si se puede usar la Programación Orientada a Objetos (POO). La respuesta es que sí, ya que las piezas son consideradas objetos.

Esperemos haber servido a alguien de ayuda, nos despedimos hasta la semana que viene. Un saludo a todos.

Frase de la semana: Cuando quieras que otro no hable, calla tú primero. Lucio Anneo Séneca

El concepto de polimorfismo es claro protagonista en esta práctica. En ella se muestra el funcionamiento y el uso de la sobrescritura de métodos que aplicaremos a la hora de tratar la interfaz que nos proponen.

EJERCICIO 1

Nos piden explicar como java es capaz de invocar a un método u otro dependiendo del elemento del array.

str += miembros[i].toString();

Pues bien, es sencillo: mediante += la sentencia anterior incrementa la posición del array permitiendo el acceso al método toString().

La clase object es la clase base raiz de cualquier jerarquía de clases de java.
El método toString() de la clase Object devuelve la cadena siguiente:

getClass().getName() + ‘@’ + Integer.toHexString(hashCode());

que en castellano quiere decir, el nombre de la clase donde el objeto está instanciado seguido del símbolo ‘@’ y un número entero propio hexadecimal e inmutable (hashCode) indicando el valor del objeto.

Respecto a la frase “It is recommended that all subclasses override this method.” , esta indicación se refiere a que el método toString() nos da una representación muy sencilla de la información contenida en la clase, y esto facilita su comprensión.

EJERCICIO 2

Está parte de la práctica trata de la creación de ficheros para almacenar interfaces. Como ya os explicamos en nuestra segunda práctica (algo más abajo de esta página, ahora no vamos a repetirnos muchos, no queremos soltar un ladrillo que nadie lea),  para crear un fichero en el que almacenar cualquier tipo de datos usabamos el constructor  public File(String pathname){…} y capturamos las excepciones mediante throws Exception {…}

EJERCICIO 3

Por fin llegamos a la parte interesante, ahora podremos dar forma y color a nuestros jueguecitos y no solo jugar en blanco y negro en el MS-DOS de turno…

Pequeños detalles que hemos ido completando:

–> Cambiar todas las variables de public a final, razonamiento, muy sencillo, mi rectángulo es mio y no quiero que nadie lo modifique, por ello le damos valor de constante.

–> Llamamos a la clase Color del API de Java (nuestra Biblia) para así poder implementar las variables colorBorde y colorFondo.

–> Investigamos como crear el rectángulo llegando a la conclusión de que lo mejor era usar el método setBounds(int x, int y, int height, int width) para dar las coordenadas del rectángulo, su altura (height) y su anchura (width). Luego lo coloreamos de color rojo y nos quedo este ejercicio resuelto.

Los demás no hemos podido resolverlos por falta de tiempo, pero ojeándolo por encima, vimos que eran necesarios cambios muy pequeños.

 Nos despedimos con nuestra habitual frase celebre del día: Con mil cañones por banda, se hundió el barco por sobrecarga Un imitador de José de Espronceda.

 Aunque sea a destiempo colgaremos los códigos por si a alguien le vienen bien…

 Clase miembro:

public class Miembro { 

    protected String nombre; 

   protected int modificadores = 0;

          this.modificadores = modificadores;

    public String toString() {

public class Atributo extends Miembro { 

      public Atributo(String nombre, int modificadores, String tipo ) {

            this.tipo = tipo;

     public String toString() {

public class Metodo extends Miembro {

       Parametro[] parametros = null;

              this.tipoRetorno = tipoRetorno;             this.parametros = parametros;

        public String toString() {

                return null;

Os escribimos en la más cruel desesperación, se nos está atragantando esta práctica, un poquito bastante por ser suaves.

 En esta práctica tratamos básicamente el concepto de herencia, característica esencial de la programación orientada a objetos. Utilizaremos las clases de la práctica anterior, (atributo.java, método.java y constructor.java) con el fin de aplicar herencia entre ellas. Lo que hay que hacer está claro, pero el problema viene cuando tenemos que implementar el método toString ya que no sabemos si lo estamos haciendo bien o no.

Implementamos los constructores y los métodos toString() de atributo.java, metodo.java, constructor.java, acorde con el enunciado de la práctica y siguiendo el mismo patrón para todos los constructores. Como ejemplo, el constructor de Metodo.java:

public Metodo(String nombre, int modificadores, String tipoRetorno, Parametro[] parametros) {

El método toString de la clase Metodo nos está “Tocando los Weblogs”, como dice el título de nuestro blog, y lo peor de todo es que la solución sera una cosa sencilla, pero estamos desquiciados ya, hemos probado de todo, con un bucle for que recorriera el array parametros, pero luego no sabiamos como introducirlo dentro del return; también usando la sentencia parametros[i];y la que más nos convenció de todas, el uso de la sentencia Modifier.toString( modificador ); ……pero no sabemos como usarlo… Conclusión: Ó esto es muy difícil ó somos unos zotes. Nos inclinamos por la segunda, si alguien pudiera resolvernos la duda, nos haría sentirnos muy humillados y al mismo tiempo felices.

 Y después queda nuestra segunda gran duda, no entendemos la “definición” del método java.lang.reflect.Field; es un inglés muy técnico para nuestras capacidades.

 Bueno amigos, os dejamos por esta semana, lamentando no poder servir de ayuda y tener que ser ayudados… pero esperemos que otra semana seamos nosotros los que os ayudemos.

Un saludo a todos

Postdata: Creemos que sería interesante poder disponer de las soluciones de cada práctica, aunque fuera con un margen de 10 o 15 días para evitar trampas al redactar los blogs, pero ahora mismo, las realizamos con nuestra mejor intención y no sabemos si están perfectas, regulares, o son un desastre…

Frase semanal: Cuando un millonario pasa a mejor vida… sus herederos también Steve McCallaghan

Segunda practica realizada y algunas dudas aunque en rasgos generales creo que algo hemos avanzado debido a que la gran mayoría de los apartados los entendimos…

EJERCICIO 1.

Para empezar, tratamos las carpetas que nos pedía el ejercicio 1 y en los siguientes apartados de este ejercicio no hubo problemas ya que se limitaba saber utilizar los métodos pow() y sqrt() de la clase Math y la clase java.lang.Random para generar un numero aleatorio.

EJERCICIO 2.

El ejercicio 2 ya nos comenzó a plantear serias dudas tanto en aserciones como en trazas de definición, que fueron resueltas por el profesor de prácticas, lo primero, no entendiamos la diferencia entre poner “System.out” o “System.err” ya que ambas se mostraban por pantalla. Al final concretamos que la diferencia básicamente era que “System.err” además de imprimir el mensaje por pantalla (solo si añades “System.err.PRINTLN”) te da la posibilidad de redirigirlo a otro punto. Es lo que hemos llegado a entender y nos parece lógico, pero no estamos al 100% seguros de su veracidad por eso nos gustaría saber si hay más gente de acuerdo con esto. Los conceptos de traza de depuración y aserción con las explicaciones de la práctica nos quedaron bastante claros.

EJERCICIO 3.

Os lo resolvemos a continuacion para que podais comparar con los vuestros. Nosotros lo hemos probado y funciona, eso si, tienen que estar archivo a copiar y el programa en el mismo directorio…

import java.io.*;

public class Cp{

public static void main(String args[]) throws IOException {
//pedir los ficheros de fuente y destino
String fuente, destino;
System.out.println(“Introduce el fichero fuente:”);
BufferedReader teclado = new BufferedReader(new InputStreamReader(System.in));
fuente = teclado.readLine();
File src = new File(fuente + “.txt”);
System.out.println(“Introduce el fichero destino:”);
destino = teclado.readLine();
File dst = new File(destino + “.txt”);

Cp cp1 = new Cp();
cp1.copy(src,dst);
System.out.println(“fichero copiado”);
}

void copy(File src, File dst) throws IOException {
InputStream in = new FileInputStream(src);
OutputStream out = new FileOutputStream(dst);

// Transfer bytes from in to out
byte[] buf = new byte[1024];
int len;
while ((len = in.read(buf)) > 0) {
out.write(buf, 0, len);
}
in.close();
out.close();
}
}

Ahora os lo explicaremos brevemente porque nos parece bastante interesante ya que estamos utilizando un programa hecho por nosotros que interactue con ficheros que tengamos:

Como en todas las prácticas de java, nos dan una estructura en este caso del método el (copy), y a partir de ahí tendremos que añadir código, consultando hasta la saciedad el API. (API = diccionario de java).

El método “copy” realiza la siguiente función: copia los datos de un fichero a otro. Lo que debiamos hacer era hallar el camino para duplicar el fichero.

Pasos que seguimos para realizar el programa:

1. Para capturar los nombres del fichero que se quiere copiar (fuente) y el que será copiado (destino) utilizamos la clase BufferedReader. (Recordad lanzar excepciones al introducir datos por pantalla)

2. En el API consultamos como crear el fichero y llegamos a la conclusión de usar el siguiente constructor: public File(String pathname). En este ejercicio crearemos el fichero fuente como File src = new File(fuente + “.txt”); y el fichero destino como File dst = new File(destino + “.txt”);

3. Para hacer la prueba probamos a meter Cp.java en Mis Documentos y crear el archivo prueba.txt en la misma carpeta. Compilamos y ejecutamos el programa introduciendo como fichero fuente “prueba” y como fichero destino “pruebaSuperada”. Aparecerá en el mismo directorio el archivo “pruebaSuperada.txt”.

EJERCICIO 4.

Básicamente era un ejercicio de tratamiento de excepciones con las estructuras try y catch.

Esto es todo amigos, esperamos haber servido de ayuda. Lo único negativo es que no hemos conseguido hacer el ejercicio 5, el ahorcado, ya que tenemos problemas a la hora de plantearlo. Un saludo

Frase de la semana: “Siempre recordare esa noche en la cual Mike y yo nos compenetramos para meter 70 puntos entre ambos” Stacey King (Después del partido Cleveland-Bulls en el que Jordan metio 69 puntos).