Este tema lo he debatido con colegas en varias ocasiones y creo que abordarlo aquí puede resultar interesante para algunos más que os estéis preguntando lo mismo a raíz de la tracción que, poco a poco, va tomando Blazor entre los desarrolladores web que trabajamos con el stack de tecnologías de Microsoft.
Voy a explicar mi punto de vista al respecto contemplando dos aspectos distintos, que creo que son los fundamentales para poder responder apropiadamente a esta pregunta:
- Si técnicamente sería posible reemplazar MVC por Blazor, esto es, si Blazor dispone de mecanismos suficientes para cubrir las necesidades de una aplicación que tradicionalmente se desarrollaría con MVC.
- Si la popularidad y difusión de Blazor podría llegar a alcanzar las cotas suficientes para convertirse en una alternativa completa y segura a MVC, en términos de madurez, estabilidad, soporte y tamaño de la comunidad. O en otras palabras, si Blazor como producto llegará a estar lo suficientemente consolidado como para poder reemplazar a MVC.
Vamos a analizar cada una de ellas.
Disclaimer: obviamente, todo lo que veréis a continuación son opiniones personales y, como tales, pueden ser discutibles. Si tenéis una opinión diferente, estaré encantado de leerla en los comentarios.
Publicado por José M. Aguilar a las 8:30 a. m.
Etiquetas: aspnetcoremvc, blazor, opinión
Y aunque suene a chiste, esta vez viene con retraso; hasta ahora, cada lanzamiento de la plataforma iba acompañado por la actualización del roadmap de la siguiente revisión del producto, es decir, nada más aparecer la versión X ya sabíamos hacia dónde se dirigirían los esfuerzos para la versión X+1. En esta ocasión hemos tenido seis meses (!) para asentar la v3 antes de empezar a pensar en la 4.
Ya hemos comentado en otras ocasiones que este ritmo no es fácil de digerir ni por la comunidad de desarrolladores ni por el mercado, e incluso supone un hándicap para la difusión y generalización del uso de la plataforma, pero bueno, es lo que hay.
Otro tema también bastante criticado es la facilidad con que MVC incrementa sus números de versión, cuando realmente las novedades ofrecidas en cada lanzamiento no parecen merecer tal distinción. Días atrás comentaba el amigo Eduard Tomás vía Twitter, y no puedo estar más de acuerdo, que MVC 3 probablemente podría haber pasado perfectamente por MVC 2.1. De hecho, si os fijáis, bastantes de sus novedades más destacables (como Nuget, Razor o los Helpers) poco o nada tienen que ver con el framework MVC en sí. Y quizás con la llegada de las tools update podríamos haberlo estirado hasta la 2.2, aunque en realidad se trataba de una mejora sobre las herramientas de Visual Studio.
No sé, a veces parece que se trata simplemente de una carrera para poder igualar la numeración de versiones con la plataforma, es decir, llegar a hacer coincidir el lanzamiento de ASP.NET MVC 5 con la propia plataforma ASP.NET 5 y la entrada por la puerta grande de HTML 5. Desde luego no sería mala cosa, al menos se relajaría un poco la actual fiebre de lanzamientos de releases que sufrimos ;-)
Pero bueno, disertaciones filosóficas aparte, la verdad es que la aparición de pistas sobre lo que incluirá una nueva revisión del producto siempre es interesante. En esta ocasión, bajo el ambicioso objetivo general de “hacer de ASP.NET MVC la mejor plataforma para la creación de aplicaciones ricas y modernas para la web”, el nuevo roadmap incluye las líneas maestras y características que, a día de hoy, están siendo consideradas para MVC 4 y vale la pena echarle un vistazo.
Aunque como bien se indica se trata de un documento muy preliminar y con toda seguridad sufrirá muchas modificaciones, ya se dejan entrever las herramientas que tendremos a nuestra disposición en unos meses, y que paso a comentar.
Y empezamos por recipes (¿recetas?), una de las novedades especialmente destacadas en el roadmap. Según se describe en éste, los recipes son cuadros de diálogo distribuidos a través de Nuget, que contienen tanto el interfaz de usuario como la lógica de generación de código que automatice determinadas tareas frecuentes y que actualmente no pueden realizarse de forma sencilla.
Un escenario descrito en el mapa de rutas podría ser la inserción de un grid Ajax. Actualmente debemos implementar la vista, acciones en el controlador que retornen datos de forma asíncrona, y sus correspondientes clases en el Modelo. El uso de un “recipe” en este caso podría ayudarnos a generar estos elementos de forma automatizada, atendiendo a los parámetros indicados a través de un cuadro de diálogo.
En cierto sentido, es similar a lo conseguido con la última actualización de herramientas para MVC3 en cuanto a la generación de andamiaje de escenarios CRUD; antes podíamos generar todos los elementos utilizando scaffolding, pero ahora se hace de forma integrada en el proceso de creación de controladores y desde el propio IDE.
Otro aspecto muy interesante de las recipes es que serán fáciles de crear gracias a su API simplificado. Obviamente, el objetivo no es otro que hacer que sea la propia comunidad de desarrolladores la que amplíe el “recetario” que vendrá de serie con el producto, de la misma forma que ocurrió con Nuget.
Como idea para incrementar la productividad, me parece muy acertada; de hecho, seguro ya que habíais echado en falta algo similar para simplificar la generación de código en vuestros escenarios habituales. Habrá que ver cómo se plasma en el producto para ver si realmente nos ayuda en nuestro trabajo, y cómo se enfocan algunas cuestiones como el soporte para las versiones Express (que supongo que existirá, pero habrá que verlo), las capacidades reales de generación de código de la herramienta, o la disponibilidad de utilizar las mismas funciones desde línea de comandos para los virtuosos del teclado.
En cualquier caso, sí es curioso que una de las principales novedades de MVC 4 vaya a ser algo prácticamente ajeno a la plataforma, como en su momento fue Nuget. Esto supongo que indica que, como en aquel caso, se trata de algo que probaremos primero los desarrolladores de MVC y que más adelante, si prospera la idea, podrán disfrutar desde otras plataformas.
Cambiando de tercio, también entra en escena de forma muy destacable el soporte para dispositivos móviles. Están previstos cambios simples en la plantilla inicial de proyectos MVC, la creación de nuevas plantillas específicas para proyectos de aplicaciones móviles con layouts, vistas y scripts (jQuery Mobile), o la creación de vistas específicas para estos dispositivos.
Por otra parte, el soporte para HTML5, ya tímidamente introducido en la reciente tools update, tomará ahora mayor fuerza, al incorporarse a nivel de controles de edición. De esta forma, se podrá aprovechar la potencia de la nueva versión del lenguaje de marcado para la creación de formularios con controles específicos para la introducción de fechas, valores numéricos, etc. No es nada que no pueda hacerse a día de hoy, pero sin duda es una buena noticia el traerlo ya de fábrica.
También los controladores asíncronos se van a ver beneficiados de una importante simplificación gracias al uso de las clases de procesamiento en paralelo y de las futuras mejoras de C# 5 (¡vaya, otra versión 5! ¿coincidencia?). Hasta ahora, el uso de la asincronía en las acciones, aunque eficaz, resultaba algo engorrosa; en MVC 4, el código de un controlador asíncrono podría ser tan limpio como el mostrado en el siguiente ejemplo:
public async Task<ActionResult> Index(string city) { var newsService = new NewsService(); var sportsService = new SportsService(); return View("Common", new PortalViewModel { NewsHeadlines = await newsService.GetHeadlinesAsync(), SportsScores = await sportsService.GetScoresAsync() }); }
MVC 4 también integrará mecanismos para comprimir y empaquetar archivos externos de scripts y hojas de estilo con objeto de minimizar el ancho de banda y, por tanto, los tiempos de descarga de los mismos. De nuevo, no es algo revolucionario porque hoy en día existen soluciones para ello.
Se pretende también mejorar la construcción de helpers Razor. En la versión actual, los helpers que introducimos en la carpeta
App_Code
son funcionalmente válidos, pero les falta integración con la plataforma. Por ejemplo, desde ellos no es posible acceder al contexto de la vista, y esto puede resultar bastante molesto.Y por cierto, respecto a Razor, comenta Phil Haack en su blog que de forma paralela se introducirán novedades en Razor y Webpages que podremos aprovechar desde MVC, como ocurre ahora, aunque no ha desvelado ninguna de ellas.
Por último, el roadmap recoge más novedades agrupadas como las siguientes, de las que se aportan únicamente los titulares:
- Soporte para la evolución de esquemas en Code First, de forma que las modificaciones en la estructura no afecten a los datos ya almacenados (EF Data Migrations).
- Mejoras en el soporte para pruebas funcionales y de integración. No se indica en qué dirección.
- Soporte para las WCF Web API.
- Mejoras en Ajax orientadas a reducir puntos de fricción actuales, aunque tampoco se indica en qué sentido.
- Mejoras en el cacheado de vistas y soporte para App Fabric Cache.
- Un nuevo atributo llamado
AreaAttribute
para mejorar la seguridad.
En cualquier caso, ya estoy deseando tener a mano alguna preview sobre la que poder ver estas ideas materializadas y poder opinar con mayor conocimiento de causa.
Enlaces:
- ASP.NET MVC 4 Roadmap
- Participar en la definición de MVC 4 (aportar sugerencias, votar propuestas, comentar…)
Publicado en: Variable not found.
Y todo se debía a la publicación, prácticamente de forma simultánea, de la primera beta de ASP.NET MVC 3, Nupack, y WebMatrix beta 2, que demuestra que la familia de tecnologías para Web sigue madurando y creciendo, y que existe alguna conspiración cuyo objetivo final es volvernos locos a todos ;-)
Vamos a comentar por encima qué nos traen estos lanzamientos.
ASP.NET MVC 3 Beta
Contra todo pronóstico, ASP.NET MVC 3 Beta rompe el patrón seguido en las versiones anteriores, en las que el ciclo de desarrollo prácticamente rondaba el año, y en cuya secuencia habían sido incluidas hasta el momento varias previews y algunas betas antes de llegar al producto final.En esta ocasión, la primera preview de ASP.NET MVC 3 apareció unos tres meses después de la versión 2, y la beta dos meses más tarde.
Como tiene que haber gente para todo, hay quien se queja de que esto puede significar que a Microsoft ha dejado de interesarle el feedback de los desarrolladores. En mi opinión, esto no tiene sentido, y no hay intención maquiavélica por detrás: simplemente, esta entrega no es tan compleja y amplia como la primera versión, donde se partía de cero, o su incremental hacia la versión 2. Aunque algunas de las novedades que se vislumbran son bastante interesantes, no se han introducido características realmente rompedoras o que requieran un gran tiempo de pruebas o una gran retroalimentación, y además, parte de ellas son compartidas con otros productos como WebMatrix.
Otro tema distinto, y creo que criticable, es la velocidad con la que se están sucediendo las distintas versiones del producto. Hace unos días comentaba vía Twitter que es difícil construir sobre una infraestructura que está en continuo movimiento; a veces las cosas hay que dejarlas reposar un poco para que asienten y calen los conceptos, se cree comunidad, software de referencia o documentación, que, desde mi punto de vista, son algunos de los handicaps actuales frente a la adopción del framework ASP.NET MVC por parte de los desarrolladores.
Pero bueno, en cualquier caso, para los que ya estamos enganchados a ASP.NET MVC, la llegada de una nueva revisión es siempre una buena noticia. La beta que podemos descargar hoy (ojo, sólo para .NET 4) ya incluye la mayoría de características que tendremos disponibles cuando aparezca la versión final, para la que, como se deja entrever en el roadmap del producto, podría faltar únicamente una release candidate, en la que aparentemente no serán incluidas muchas más novedades.
A modo de resumen, las características que a día de hoy parece que traerá el futuro ASP.NET MVC 3 son, principalmente:
- Mayor flexibilidad para el uso de motores de vistas alternativos a WebForms.
- El nuevo motor de vistas Razor, compartido por la tecnología WebPages. Eso sí, aún no está disponible intellisense en el editor de Visual Studio para estas vistas.
- Un soporte para inyección de dependencias muy mejorado respecto a las versiones anteriores.
- Registro de filtros globales durante la inicialización de la aplicación.
- Nuevos tipos de resultados (ActionResults) de uso común.
- Mejoras en el sistema de validación, soportando nuevos atributos, generación de scripts en cliente de forma más sencilla, y nuevas fórmulas para la inclusión de validación no intrusiva.
- Soporte para funcionalidades Ajax no intrusivas.
- Inclusión de capacidad de binding sobre JSON.
- Nuevas vías para enviar información del controlador a las vistas, de forma dinámica.
- Helpers para la realización de tareas de uso frecuente, como la generación de grids, charts, o manipulación de imágenes.
- Control individual sobre la validación de la petición (vaya, ahora que había encontrado un truquillo para conseguirlo).
- Incluye el gestor de paquetes Nupack, que comentaré algo más abajo.
Para conocer las novedades de la beta 2 respecto a la Preview, te recomiendo que leas el post de Eduard Tomás, escrito con el producto aún humeante, recién salido del horno ;-)
¿Nupack? ¿Eso qué es?
Otra de las grandes estrellas de la tarde del miércoles fue Nupack, un gestor de paquetes open source que está llamado a ser una herramienta imprescindible para los desarrolladores. La versión presentada es bastante preliminar, CTP1, pero funciona muy bien y es útil para empezar a conocerla.Por hacernos una idea rápida sobre el nuevo producto, podríamos considerar que Nupack es a librerías y componentes lo que Web Platform Installer a aplicaciones y plataformas. Se trata de un gestor de paquetes integrado en Visual Studio que permite obtener componentes open source (y, lo que es más interesante, las dependencias de éstos), e incluirlos en nuestros proyectos de forma muy sencilla.
Y con “incluirlos” no me refiero a descargarlos y dejarlos en un directorio para que nosotros hagamos el resto; Nupack lo descarga y extrae sobre una carpeta de uso interno, añade las referencias necesarias a nuestro proyecto, y, cuando es necesario, añade archivos y modifica educadamente los ficheros de configuración del proyecto.
Los paquetes disponibles en Nupack se obtienen de una serie de repositorios de software open source, por supuesto configurables. En estos momentos hay ya más de 70 paquetes entre los que se encuentran de uso más frecuente, aunque supongo que el número continuará aumentando.
Para añadir un componente a un proyecto basta con abrir el menú contextual sobre las referencias y seleccionar la opción “Add Package Reference”, que nos llevará a un cuadro de diálogo como el mostrado a continuación, que nos permite buscar e incluir los paquetes de forma más visual:
También podemos utilizar Nupack desde una línea de comandos incluida en Visual Studio (Package Manager Console). La siguiente captura muestra lo simple que resulta añadir un componente como T4MVC a un proyecto utilizando la consola:
Esta última fórmula, además de resultar muy cómoda, está diseñada para ser extensible, por lo que es posible descargar e instalar paquetes que amplíen sus funciones, como MvcScaffold, que añade a la consola órdenes para generar código de vistas más rápidamente que utilizando su equivalente GUI, y de forma similar a como se hace en otras plataformas como Ruby.
Nupack se incluye “de serie” con ASP.NET MVC 3 Beta, por lo que si has instalado éste último, ya podrás disfrutar de esta nueva herramienta. Si no, puedes descargarlo desde la página del proyecto Nupack en Codeplex.
Si quieres utilizar Nupack desde la consola de comandos, debes tener instalado previamente PowerShell 2.0. En caso de necesitarlo, puedes bajarlo, por ejemplo, con Web Platform Installer.
Un último detalle: Nupack, aunque se haya presentado así, unido a otros lanzamientos de la pila de tecnologías Web de Microsoft, no está ligado a éstas. Se trata de una herramienta independiente, de la que podremos sacar partido en todo tipo de proyecto.
En resumen, desde mi punto de vista se trata de una herramienta excelente, presente en otros ámbitos y tecnologías, y que ya venía haciendo falta a Visual Studio y los desarrolladores .NET. Si quieres saber más sobre el tema, no te pierdas el gran post de Scott Hanselman explicando su uso.
WebMatrix Beta 2
Hace unos meses, al aparecer la primera beta ya describí mis primeras impresiones sobre WebMatrix, por lo que no voy a extenderme demasiado ahora.Para los despistadillos, recordar que WebMatrix es un conjunto de herramientas y plataformas destinadas a crear aplicaciones basadas en el paradigma de “orientación a página” (como ASP clásico o PHP, entre otros), e incluye:
- IIS 7 Express, una edición reducida del servicio de publicación web.
- SQL Server Compact, un motor de datos capaz de ejecutarse en el proceso de la aplicación que lo utiliza, por tanto sin necesidad de instalar software alguno en servidor.
- Un entorno de desarrollo, compuesto por:
- un editor de texto plano bastante simplillo para crear y modificar las páginas,
- un diseñador de bases de datos,
- herramienta de generación de informes SEO del sitio,
- Integración con un extenso repositorio de software libre (.NET y PHP, principalmente), del que es posible descargar aplicaciones para personalizarlas o construir sobre ellas de forma rápida.
- Tecnología WebPages, un nuevo modelo de desarrollo sobre ASP.NET que permite la creación de sitios web utilizando el nuevo motor Razor.
Se ha incluido un gestor de paquetes basado en web, que permitirá añadir nuevos helpers y componentes al sistema. Para ello, basta con acceder desde el navegador a la carpeta “_Admin” en el raíz del sitio web; la primera vez nos solicitará la introducción de una contraseña que deberemos utilizar en adelante. Una superado este trámite, podremos instalar los paquetes desde la misma página:
También han sido añadidos nuevos helpers, renombrado algunos métodos y clases existentes, y se ha introducido validación de peticiones a nivel de campo, al igual que a MVC 3. En definitiva, cambios que podríamos considerar de menor calado.
Puedes leer más en el documento Readme de WebMatrix beta 2.
En fin, que…
… de nuevo nos encontramos ante una oleada de tecnologías y herramientas, algunas bastante destacables, a las que debemos ir haciendo hueco en nuestra mochila y a las que conviene ir echando el ojo de vez en cuando para poder seguirles el ritmo.Sin duda, diversión asegurada. :-)
Publicado en: Variable not found.
Además de estar casi totalmente de acuerdo con los puntos expuestos en su post, que enumero y comento a continuación, añadiré algunos más de propia cosecha de agentes irritantes.
- 10. Comentarios que explican el "cómo" y no el "qué". Tan importante es incluir comentarios en el código como hacerlo bien. Es terrible encontrar comentarios que son una simple traducción literal al español del código fuente, pues no aportan información extra, en lugar de una explicación de lo que se pretende hacer. Muy bueno el ejemplo de Kevin en el post original... ¿eres capaz de decir qué hace este código, por muy comentado que esté?
r = n / 2; // Set r to n divided by 2
// Loop while r - (n/r) is greater than t
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
} - 9. Las interrupciones. Sin duda, el trabajo de desarrollador requiere concentración y continuidad, y las interrupciones son las grandes enemigas de estos dos aspectos. Una jornada de trabajo llena de llamadas, mensajes o consultas de clientes, proveedores, jefes o compañeros puede resultar realmente frustrante, a la vez que la distracción que introduce suele ser una fuente importante de errores en las aplicaciones.
- 8. Ampliación del ámbito. Una auténtica pesadilla, sobre todo cuando se produce durante el desarrollo, consistente en el aumento desproporcionado del alcance de determinadas funcionalidades o características del software a crear. Es especialmente desmotivador si, además, no viene acompañado por el aumento del tiempo o recursos necesarios para su realización.
Kevin incluye en su artículo un ejemplo, algo exagerado pero ilustrativo, de sucesivas ampliaciones de ámbito que convierten un requisito factible en un infierno para el desarrollador; seguro que os recuerda algún caso que habéis sufrido en vuestras propias carnes:- Versión 1: Mostrar un mapa de localización
-- Bah, fácil, sólo tengo que crear una imagen; incluso puedo basarme en algún mapa existente que encuentre por ahí - Versión 2: Mostrar un mapa 3D de localización
-- Uff, esto ya no es lo que hablamos; tendré que currarme bastante más el diseño, y ya no será tan fácil partir de alguno existente... - Versión 3: Mostrar un mapa 3D de localización, por el que el usuario pueda desplazarse volando
-- ¡!
- Versión 1: Mostrar un mapa de localización
- 7. Gestores que no entienden de programación. Otro motivo común de irritación entre los desarrolladores es la incapacidad de gestores para comprender las particularidades de la industria del software en la que trabajan. Este desconocimiento genera problemas de todo tipo en una empresa y suponen un estrés terrible para el desarrollador.
- 6. Documentar nuestras aplicaciones. Lamentablemente, en nuestro trabajo no todo es desarrollar utilizando lenguajes y tecnologías que nos divierten mucho. Una vez terminado un producto es necesario crear guías, manuales y, en general, documentación destinada al usuario final que, admitámoslo, nos fastidia bastante escribir.
- 5. Aplicaciones sin documentación. A pesar de que entendamos y compartamos el punto anterior, también nos fastidia enormemente tener que trabajar con componentes o librerías partiendo de una documentación escasa o nula. Si lo habéis sufrido, entenderéis lo desesperante que resulta ir aprendiendo el significado de las funciones de un API usando el método de prueba y error.
- 4. Hardware. Especialmente los errores de hardware que el usuario percibe como un fallo de la aplicación son normalmente muy difíciles de detectar: fallos de red, discos, problemas en la memoria... por desgracia, hay un amplio abanico de opciones. Y lo peor es que por ser desarrolladores de software se nos presupone el dominio y control absoluto en asuntos hardware, lo que no siempre es así.
- 3. Imprecisiones. Aunque Kevin lo orienta al soporte al usuario, el concepto es igualmente molesto en fases de diseño y desarrollo del software. Las descripciones vagas y confusas son una causa segura de problemas, sea en el momento que sea.
Son irritantes las especificaciones imprecisas, del tipo "esta calculadora permitirá al usuario realizar sumas, restas, multiplicaciones y otras operaciones"... ¿qué operaciones? ¿divisiones? ¿resolver ecuaciones diferenciales?
Tampoco es fácil encajar un mensaje de un usuario tal que "me falla el ERP, arréglalo pronto"... A ver. El ERP tiene cientos de módulos, ¿fallan todos? ¿podríamos ser más concretos? - 2. Otros programadores. Como comenta Kevin, el malestar que provoca a veces la relación entre programadores bien merecería un post independiente, pero ha adelantado aspectos que, en su opinión, hace que a veces el trato con los compañeros sea insoportable:
- Personalidad gruñona, hostilidad
- Problemas para comprender que hay que dejar de debatir la arquitectura del sistema y pasar a realizar las tareas
- Falta de habilidad para mantener una comunicación efectiva
- Falta de empuje
- Apatía hacia el código y el proyecto
- 1. Tu propio código, 6 meses después. Sí, es frustrante estar delante de un código aberrante y darte cuenta de que tú eres el autor de semejante desastre. Y tras ello llega la fase de flagelación: ¿en qué estaba pensando cuando hice esto? ¿cómo fui tan estúpido? uff...
Este hecho, sin embargo, forma parte de la evolución tecnológica, personal y profesional; todos estos factores están en continuo cambio, lo que hace que nuestra forma de atacar los problemas sea distinta casi cada día.
Y hasta aquí la lista de Kevin en su post, ni que decir tiene que comparto sus reflexiones en la mayoría de los puntos. Por mi parte, añadiría los siguientes agentes irritantes que conozco por experiencia propia o de conocidos:
- Extra 1. Requisitos evolutivos, como una ampliación del ámbito del punto 8 ;-), que son aquellos que van cambiando conforme el desarrollo avanza y que obligan a realizar refactorizaciones, descartar código escrito, e introducir peligrosas modificaciones, afectando a veces por debajo de la línea de flotación del software. Más rabia produce, además, cuando se atribuyen una mala interpretación por parte del desarrollador de una especificación imprecisa.
- Extra 2. Problemas en el entorno. Nada más frustrante que cortes en el suministro eléctrico, cuelgues, problemas en el hardware, lentitud en los equipos de trabajo o de acceso a información... a veces parece que tenemos que construir software luchando contra los elementos.
- Extra 3. El "experto" en desarrollo de software. Clientes, gestores y otros individuos que utilizan frecuentemente, y sin conocimiento alguno de causa, expresiones como "Esto es fácil", "Una cosa muy sencilla", "¿Eso vas a tardar en hacer esta tontería?".... A veces no es fácil hacer entender que la percepción externa de la complejidad es absolutamente irreal, y suele ser una causa frecuente de desesperación para los desarrolladores.
- Extra 4. Usuarios corrosivos, que lejos de colaborar durante el desarrollo o la implantación de un sistema, aprovechan la ocasión para arremeter contra la aplicación, organización, jefes, compañeros, el gobierno, o lo que se ponga por delante. Es de justicia decir que muchas veces este comportamiento es debido a una mala gestión interna del proyecto, pero desde el punto de vista del profesional del sofware que sólo quiere realizar lo mejor posible su trabajo son una auténtica pesadilla.
En fin, que ya a estas alturas es fácil ver que hay bastantes cosas que fastidian a los desarrolladores, y seguro que podríamos añadir muchas más; algunas son evitables, otras son inherentes a la profesión y hay que aprender a convivir con ellas, pero en cualquier caso son un interesante motivo de reflexión.
¿Y a tí, qué es lo que más te fastidia?
Enlace: Top 10 Things That Annoy Programmers
Publicado en: www.variablenotfound.com.
Publicado por José M. Aguilar a las 11:58 p. m.
Etiquetas: desarrollo, opinión, productividad, programación
Me llamó la atención porque muchas de estas líneas son totalmente aplicables a otros ámbitos y colectivos, y por supuesto al mundo del desarrollo de software, dado que contiene perlas como: "Estudia, puesto que el Derecho evoluciona constantemente", o "Piensa, puesto que el Derecho se aprende estudiando pero se ejerce pensando".
Sin embargo, el que me hizo reflexionar fue el décimo:
10. AMA TU PROFESION. Trata de considerar la abogacía de tal manera, que el día en que tu hijo te pida consejo sobre su destino, consideres un honor para ti proponerle que se haga abogado.
Y es que la pregunta es: ¿estamos tan satisfechos de nuestra profesión como para aconsejar a un hijo, al que se supone que debemos desearle lo mejor del mundo, dedicarse a ella?
No son pocos los profesionales del desarrollo de software que, bien por circunstancias laborales, personales, falta de vocación u otros motivos, reniegan continuamente, y a veces no sin razón, de este mundillo. Y es que con mucha frecuencia se trata de un trabajo mal pagado, muy duro, con horarios imposibles, estrés continuo, necesidad de actualización de conocimientos frecuente, y escaso reconocimiento social.
Así está el patio como está. Cada vez más gente que huye dando el salto a otras profesiones, las matrículas en informática por los suelos, los ingenieros en continua protesta (;-)) ... en fin, un panorama nada alentador para el futuro.
A pesar de esto, yo soy de los que estarían encantados de que alguno de mis hijos (hijas, en este caso) se dedicara al mundo del desarrollo de software, siempre, eso sí, que consiguieran apasionarse por ello. Nunca se la recomendaría como una salida profesional más, pues creo que al igual que es una dedicación fascinante para el que le gusta, estoy seguro de que debe ser una auténtica pesadilla para el que no disfrute creando software.
Probablemente dedicándose a esto no conseguirán nunca hacerse ricas, ni famosas, ni llegar todos los días pronto a casa... pero bueno, tampoco siendo médicos, ni abogados, ni taxistas. Y, en cambio, tendrían por delante una profesión (y muchas veces hobby) donde volcar toda su creatividad y talento, la satisfacción de la investigación y aprendizaje continuos, de crear software que ayuden a otros a trabajar, estudiar o pasar buenos ratos de ocio... en fin, un universo de posibilidades.
¿Y tú, recomendarías a tu hijo que se dedicara al mundo del desarrollo?
Publicado en: www.variablenotfound.com
Publicado por José M. Aguilar a las 8:54 p. m.
Etiquetas: desarrollo, opinión, personal, reflexiones, trabajo