Mostrando entradas con la etiqueta Puntos extras. Mostrar todas las entradas
Mostrando entradas con la etiqueta Puntos extras. Mostrar todas las entradas

jueves, 14 de julio de 2011

Interfaces poco "bonitas"

Buscando información para esta entrada, me encontré con una pagina que da su punto de vista del porque es importante las interfaces grafías titulado "El UI no se puede dejar para después", lo leí y coincido con el lector varias cosas por las que el software deja de funcionar es por su mala interfaz gráfica y nos muestra una serie de pasos para que todo salga con éxito.

Aquí la pagina


Todos los artistas del mundo en una misma pagina
---------------------------------------------------------------

y... a donde le pico?
-----------------------------------------------------------------------------
Esta persona estaba muy cansada o en realidad no sabia diseñar.
--------------------------------------------------------------------------------------------


Esto me recuerda al juego "donde quedo la bolita"
-----------------------------------------------------------------------------------------


Sin duda ahí mas paginas como estas, pero lo menos se hubieran inspirado en otras con un buen diseño. artículo original


lunes, 4 de julio de 2011

Interfaces en java

¿Concepto de Interface?

El concepto de Interface lleva un paso más adelante la idea de las clases abstractas. En Java una interface es una clase abstracta pura, es decir una clase donde todos los métodos son abstractos (no se implementa ninguno). Permite al diseñador de clases establecer la forma de una clase (nombres de métodos, listas de argumentos y tipos de retorno, pero no bloques de código). Una interface puede también contener datos miembro, pero estos son siempre static y final. Una interface sirve para establecer un 'protocolo' entre clases.

¿Porque utilizar interfaces?

Para revelar la interfaz de un objeto de programación (funcionalidad del objeto) sin revelar su ejecución.
- Este es el concepto de encapsulación
- La puesta en práctica puede cambiar sin afectar el que llama a la interfaz.

Para que las clases no relacionadas implementar similares métodos (comportamientos).

Declaración y uso

Una interface se declara:
       interface nombre_interface {
tipo_retorno nombre_metodo ( lista_argumentos ) ;
. . .
}

Por ejemplo:
       interface InstrumentoMusical {
void tocar();
void afinar();
String tipoInstrumento();
}

Y una clase que implementa la interface:
       class InstrumentoViento extends Object implements InstrumentoMusical {
void tocar() { . . . };
void afinar() { . . .};
String tipoInstrumento() {}
}

class Guitarra extends InstrumentoViento {
String tipoInstrumento() {
return "Guitarra";
}
}

La clase InstrumentoViento implementa la interface, declarando los métodos y escribiendo el código correspondiente. Una clase derivada puede también redefinir si es necesario alguno de los métodos de la interface.

REFERENCIAS

http://www.arrakis.es/~abelp/ApuntesJava/Interfaces.htm

http://www.cpe.eng.cmu.ac.th/wp-content/uploads/javainterface.pdf

Sistemas de casos fallidos

Ahi en CIOInsight un artículo acerca de la experiencia de una persona en la resolución de proyectos con riesgo de fracaso y en el que aporta algunas sugerencias sobre qué camino seguir y cuál no (explicando un proyecto que no pudieron rescatar). Seguro que más de uno se siente identificado como bombero o paracaidista de proyectos, que es justo lo contrario de lo que pretende defender el autor. Algunas pistas incluyen seguir contando con el equipo de proyecto existente en la medida de lo posible, evitar hacer al equipo realizar un esfuerzo extra buscando formas de trabajar más inteligentes y productivas o elegir las batallas que se pueden ganar o los proyectos cuya solución se puede abordar.

La siguiente gráfica muestra una presentación con los resultados de una encuesta, acerca de las razones que llevaron a cancelar proyectos IT.


Las principales causas de cierre de proyectos 1) el cambio de necesidades de negocio, 2) la incapacidad del proyecto de cumplir las expectativas prometidas, 3) cambio en las prioridades, 4) sobrepasar el presupuesto y 5) que el proyecto no estaba alineado con el negocio.

Un ganador se compromete; un perdedor hace promesas.


REFERENCIAS

http://www.businessweek.com/managing/content/may2008/ca20080529_123818.htm

http://www.cioinsight.com/c/a/Management/Why-IT-Projects-Get-Killed/