Como ya predijo el filósofo Arrabál, las cosas están cambiando.
Poco a poco, el sector del desarrollo del software se va haciendo un hombrecito. Desde luego este proceso no se ha postpuesto por falta de esfuerzos. La industria, cual madre concienciada, haciendo palanca a través de la Ingeniería del Software ha intentado estandarizar de muchas maneras el “artístico” proceso de crear software. Algunos de estos intentos han sido más forzados que otras (UML, CMMI, Métricas de calidad… ), pero casi todos han demostrado la misma poca efectividad.
Dichos intentos “encauzadores” de mama industria han quedado a medio camino por la misma razón: contaban con que el terreno sobre el que se apoyaban era firme, cuando realmente lo hacían sobre arenas movedizas. En relación a otras ciencias (y entornos productivo-económicos) el desarrollo de software avanza muy rápido.
Alcanzar esta velocidad de crucero implica que hay mucho que mejorar y obliga al sector a reinventarse contínuamente. La tecnología, los modelos de negocio, el alcance de la funcionalidad de las aplicaciones, la automatización de procesos, la integración y orquestación de unidades de negocio… todo está en expansión. Como todos sabemos, no se puede estandarizar lo que no deja de cambiar, por lo que los intentos realizados se han ido quedando anticuados antes de alcanzar su madurez.
Pero en ese reinventarse ha cambiado la prespectiva…
Un buen día nos damos cuenta de que estamos peleando contra la realidad. Nos liberamos y dejemos de atacar y evitar el cambio como un enemigo. Es una actitud provocada por el convencimiento que surge desde dentro de que no hay otra opción. Debemos asumir (cuanto antes mejor) el cambio como algo que está ahi, nos guste o no, no podemos evitarlo. ¡¡Todo cambia!!
En las metodologías “predictivas” se destinan gran parte de los recursos a ser capaz de predecir lo que se va a desarrollar en los próximos años. Por muy concienzudo que sea dicho estudio, el contexto varía, las necesidades del cliente cambian, surgen nuevas oportunidades y riesgos. El que mayor capacidad de cambio demuestre, contará con una ventaja competitiva significativa.
Por lo tanto, permitir que nuestro cliente marque el siguiente paso (o mejor dicho, pasito) a dar nos permite ajustar el camino a recorrer a las necesidades que sobre la marcha surgan, aportando un mayor valor al software y satisfacción al cliente, que es nuestro objetivo… ¿o no?
Publicado originalmente en Synergos
Andoni Arroyo es básicamente un informático...(creo que con eso se explica todo)
lunes, 27 de abril de 2009
miércoles, 15 de abril de 2009
.NET Framework 4.0 y C# 4.0 (1 de 5)
Podemos incluir las nuevas caracteristicas que se incluyen en C# 4.0 en cuatro grupos principales:
- Dynamic lookup
Nos permite escribir métodos, operadores, acceso a propiedades y campos y cualquier invocación a objetos que se salte la comprobación estática de tipos de C# resolviendose en tiempo de ejecución. (¿esto es bueno o malo...? ya hablaremos, pero lo bueno es poder elegir, no? ) - Parámetros con nombre y opcionales
A partir de C# 4.0 los parámetros puedrán ser especificados como opcionales, asignandoles un valor por defecto en la declaración de miembro. Por supuesto, cuando el miembro sea invocado, los argumentos opcionales pueden ser omitidos. Los de VB.net que dejen de sacar pecho, porque además cualquier parámetro podrá ser pasado por nombre en lugar de posición. (nada de opcionales al final...) - Caracteristicas especificas de Interoperabilidad con COM
La combinación de las dos mejoras comentadas anteriormente permiten hacer más cómoda la programación contra objetos COM. Además en el framework 4.0 se incluirán otras pequeñas características que mejorarán aún más esta "dura" experiencia. - Varianza y Contravarianza
Quien haya profundizado en la O.O. usando genericos se dará cuanta de lo necesaria que era esta caracteristica. Ahora C# admite "co y contravariance" (por ejemplo Lista de objetos<-> Lista de string). Además los tipos de la B.C.L. son actualizados para que tengan en cuenta esta característica.
Continuaremos profundizando en posteriores posts.
martes, 7 de abril de 2009
.NET Framework 4.0 y C# 4.0 (0 de 5)
Visual Studio 2010 y el .NET Framework 4.0 estarán pronto en beta y con ellos se incluirán nuevas características. Una de ellas, es la nueva versión del lenguaje de programación C# (4.0, que se dice pronto!!). Para ponernos un poco en situación voy a escribir una serie de post en los cuales reflejar las evoluciones más significativas del mismo.
Para hacer las cosas como se deben vamos a hacer un poco de historia:
El equipo C# comienza en 1998 con el objetivo de crear un nuevo lenguaje de programación simple, moderno, orientado a objetos y type-safe (seguridad de tipos) para la plataforma .NET.
Microsoft lanza la plataforma .NET y el lenguaje de programación C# en verano de 2000 con gran éxito puesto que a día de hoy es uno de los más usados.
Uno de los principales éxitos de C# ha sido las buenas fuentes en las que se basa ( C++, Java...) así como el continuo y rápido proceso de evolución que la gente del equipo responsable de Microsoft le aplican.
Con la versión 2.0 del lenguaje se incluye el soporte para genericos, metodos anónimos, iteradores, tipos parciales y tipos nulables.
En la siguiente versión, la 3.0 el lenguaje se centra en habilitar LINQ para lo cual requiere todo lo anterior y una serie de nuevas características:
- Variables locales de tipo implicito.
- Métodos de extensión. (se emplea para implementar los proveedores de LINQ de manera debilmente acoplada)
- Expresiones Lambda. (de esto ya hablaremos en otro post)
- Inicializadores de objetos y colecciones.
- Tipos anónimos.
- Arrays implicitamente tipados.
- Expresiones de consulta y árboles de expresiones.
Ahora que hemos conseguido un poco de prespectiva comenzaremos a hablar en el siguiente post de las novedades de C# 4.0.
Nota:
El nombre de C# es un guiño a modo siguiente evolución de C++. (C con 4 +)
C =>C++=>C++++
C =>C++=>C++++
martes, 24 de marzo de 2009
Renombrar un objeto de una base de datos desde el Server Explorer del Visual Studio
Por si alguno no se ha dado cuenta, les comento un pequeño truco muy útil.
Desde la venta del Server Explorer del Visual Studio no se pueden renombrar directamente ciertos objetos de la base datos con la que se está trabajando.
Por ejemplo, no se puede renombrar una tabla desde esta ventana.
Sin embargo podemos realizar esta tarea de manera muy sencilla a través de un Database Diagram.
Sin embargo podemos realizar esta tarea de manera muy sencilla a través de un Database Diagram.
Para ello si no tenemos ningún diagrama creamos uno nuevo y editamos las propiedades de los objetos desde la ventana de propiedades del Visual Studio.
Una vez terminadas las modificaciones, guardamos el diagrama y actualizamos el listado de objetos de la base de datos y listo, los cambios se han realizado.
Una vez terminadas las modificaciones, guardamos el diagrama y actualizamos el listado de objetos de la base de datos y listo, los cambios se han realizado.
Espero que les sea de utilidad.
Un saludo.
lunes, 12 de enero de 2009
Incluir UserControl de Windows.Forms en WPF
Hola a todos y Feliz 2009!!
En ocasiones nos puede resultar interesante incluir un control de usuario que ya tenemos desarrollado y funcionando en nuestra aplicación WPF. esta y otras características de integración entre ambos mundo de UI permiten ir adentranos en el mundo de WPF poco a poco realizando las migraciones por pasos puesto que ambas conviven sin problemas.
Pasos para incluir UserControl de Windows.Forms en WPF:
En ocasiones nos puede resultar interesante incluir un control de usuario que ya tenemos desarrollado y funcionando en nuestra aplicación WPF. esta y otras características de integración entre ambos mundo de UI permiten ir adentranos en el mundo de WPF poco a poco realizando las migraciones por pasos puesto que ambas conviven sin problemas.
Pasos para incluir UserControl de Windows.Forms en WPF:
- Incluir las referencias a:
-System.Windows.Forms.dll.
-WindowsFormsIntegration.dll.
Cae por (..Archivos de programa\Reference Assemblies\Microsoft\Framework\v3.0\) - Incluir la referencia al namespace desde el XAML.:
Integración
xmlns:wfi="clr-namespace:System.Windows.Forms.Integration;assembly=WindowsFormsIntegration"
Control de usuario
xmlns:my="clr-namespace:WindowsFormsControlLibrary1;assembly=WFCLTest" - Por fin incluir el tag WindowsFormsHost necesario para poder embeber a los controles. Sin este control como wrapped recibiriamos un error de compilación, puesto que el control de usuario de WinForm no es un 'UIElement'
Es posible también, (lo veremos en otro post) inclur un control WPF en un formulario Windows.
Un saludo.
Suscribirse a:
Entradas (Atom)