Mostrando entradas con la etiqueta novedades. Mostrar todas las entradas
Mostrando entradas con la etiqueta novedades. Mostrar todas las entradas
martes, 24 de enero de 2017
Probablemente muchos recordaréis que cuando comenzaron a verse las primeras previews de ASP.NET Core, por entonces aún llamado ASP.NET vNext, una de las novedades más sorprendentes que pudimos descubrir fue la aparición de un nuevo archivo de proyecto, llamado project.json, que sustituiría al vetusto .csproj (o vbproj).La comunidad se entusiasmó bastante con la idea porque el nuevo archivo de proyecto era bastante más simple y liviano que el tradicional .csproj, daría menos problemas con los sistemas de control de código fuente, era fácil de leer y de editar sin necesidad de disponer de Visual Studio o un IDE completo, y por tanto era muy portable entre plataformas. Y encima usaba el formato JSON, que sin duda resultaba mucho más cool que XML. ¿Qué más podíamos pedir?
Antes de continuar, permitidme un inciso: aunque conceptualmente todo lo que vamos a contar es cierto en este momento (enero/2017) y probablemente seguirá siéndolo, el tooling aún está en desarrollo y, por tanto, algunos detalles todavía podrían cambiar.
martes, 17 de enero de 2017
Como sabemos, para invocar a un view component e incluir la vista parcial que retorna en el interior de otra vista, debemos utilizar desde ésta el helper @Component.Invoke() o su alternativa asíncrona @Component.InvokeAsync(), por ejemplo de la forma que vemos a continuación:<div class="cart">
@await Component.InvokeAsync(
"ShoppingCart",
new { showImages = false, showButtons = false }
)
</div>
@Component.Invoke() es el mismo para todos los view components, ni el entorno ni el compilador pueden ofrecernos ayuda en nombres o parámetros, ni validar que la llamada sea correcta. Cualquier fallo se detectará exclusivamente en tiempo de ejecución.Asimismo, está claro que el código de las vistas es más legible y fluido si en lugar de utilizar sintaxis imperativa, como son las llamadas a helpers, se utiliza un enfoque declarativo, esto es, si utilizamos etiquetas como los célebres tag helpers.
miércoles, 28 de diciembre de 2016
Sin duda, el equipo de marketing de Microsoft es conocido por su gran habilidad y creatividad a la hora de nombrar los nuevos productos que la fábrica de Redmond va lanzando al mercado. Pero no sólo eso, también son realmente buenos sabiendo cuándo hay que hacerlo para conseguir captar la atención y elevar el hype.
Ya lo demostraron meses atrás con el renombrado de toda nueva pila de tecnologías relacionadas .NET, cuando decidieron cambiar de ASP.NET 5 a ASP.NET Core, una idea que sirvió para centrar las expectativas del producto y entusiasmó a los autores de contenidos (blogs, podcasts, libros, cursos, presentaciones, etc.), sobre todo por lo oportuno de tan estratégico movimiento.
Y el renombrado de la suite de desarrollo por excelencia ya se estaba haciendo de esperar, aunque esta vez no nos ha pillado desprevenidos. De hecho, más o menos era un secreto a voces e incluso había algún leak donde se había adelantado la noticia: Visual Studio 2017 se llamará finalmente Visual Studio Core 1.0, rompiendo así con la tradición de versionarlos según el año de aparición, como se lleva haciendo desde el año 2003.
Ayer mismo se publicó la Release Candidate 2, en la que ya figura el nuevo nombre del producto. También es posible descargar ya las actualizaciones de componentes y herramientas de terceros (como JetBrains, Telerik, Component One, DevExpress y otros) con adaptaciones a estos cambios, así como acceder a documentación y materiales actualizados.
Como consecuencia de este cambio, y dado que existe un parecido razonable del nuevo nombre con el popular Visual Studio Code, éste último pasará a denominarse Code Studio Visual, eliminando así toda posibilidad de confusión entre ambos productos, pero manteniendo al mismo tiempo el "aire" de familia entre ellos.
La nueva versión disponible a día de hoy, versionada como 2.0, ya hace efectivo este cambio, como podéis ver en la captura de pantalla adjunta.
Pero la oleada de renombrados en la organización no queda aquí, pues lo mismo ocurre con los servicios para desarrolladores en la nube. Con objeto de hacer más sencilla la adopción de la nueva nomenclatura, los servicios conocidos como Visual Studio Online, que luego pasaron a denominarse Visual Studio Team Services, pasarán ahora a llamarse Visual Studio Core Team Online Services, dejando así más patente su relación con la familia de productos y su enfoque de plataforma completamente online.
Aunque algo más adelante, también se verán afectados los servicios generales en la nube, lo que hasta ahora conocíamos como Microsoft Azure, que pasarán a denominarse Microsoft Cloud Core Services. Sin duda, todo un acierto el eliminar la palabra "Azure", que al fin y al cabo no dice nada, y comunicar más claramente dónde se encuentra la aportación de valor del producto, como ya hacen otros proveedores como Amazon, IBM o Google.
Según Patrick Iñuelas, product manager de Microsoft Naming Core Team (la división de marketing encargada de poner en marcha estos cambios) están ahora trabajando en el próximo paso, que es renombrar Xamarin a Silverlight Core, en palabras textuales, "porque tenemos el nombre de dominio disponible".
¿Y mi opinión respecto a todos estos cambios? Pues, por supuesto, absolutamente favorable. Los nombres anteriores sonaban ya algo añejos y a los jóvenes desarrolladores les sonaba a algo “legacy”; es lógico que cada cierto tiempo haya que hacer un reboot para poner los contadores a cero y comenzar de nuevo. En cuanto a los nombres elegidos, creo que son totalmente acertados porque son fáciles de recordar, tienen gancho, y se alinean correctamente con la tendencia "Core" de los últimos tiempos, dando una imagen mucho más fresca y moderna de los productos.
Publicado en Variable not found.
Ya lo demostraron meses atrás con el renombrado de toda nueva pila de tecnologías relacionadas .NET, cuando decidieron cambiar de ASP.NET 5 a ASP.NET Core, una idea que sirvió para centrar las expectativas del producto y entusiasmó a los autores de contenidos (blogs, podcasts, libros, cursos, presentaciones, etc.), sobre todo por lo oportuno de tan estratégico movimiento.Y el renombrado de la suite de desarrollo por excelencia ya se estaba haciendo de esperar, aunque esta vez no nos ha pillado desprevenidos. De hecho, más o menos era un secreto a voces e incluso había algún leak donde se había adelantado la noticia: Visual Studio 2017 se llamará finalmente Visual Studio Core 1.0, rompiendo así con la tradición de versionarlos según el año de aparición, como se lleva haciendo desde el año 2003.
Ayer mismo se publicó la Release Candidate 2, en la que ya figura el nuevo nombre del producto. También es posible descargar ya las actualizaciones de componentes y herramientas de terceros (como JetBrains, Telerik, Component One, DevExpress y otros) con adaptaciones a estos cambios, así como acceder a documentación y materiales actualizados.
Como consecuencia de este cambio, y dado que existe un parecido razonable del nuevo nombre con el popular Visual Studio Code, éste último pasará a denominarse Code Studio Visual, eliminando así toda posibilidad de confusión entre ambos productos, pero manteniendo al mismo tiempo el "aire" de familia entre ellos.La nueva versión disponible a día de hoy, versionada como 2.0, ya hace efectivo este cambio, como podéis ver en la captura de pantalla adjunta.
Pero la oleada de renombrados en la organización no queda aquí, pues lo mismo ocurre con los servicios para desarrolladores en la nube. Con objeto de hacer más sencilla la adopción de la nueva nomenclatura, los servicios conocidos como Visual Studio Online, que luego pasaron a denominarse Visual Studio Team Services, pasarán ahora a llamarse Visual Studio Core Team Online Services, dejando así más patente su relación con la familia de productos y su enfoque de plataforma completamente online.
Aunque algo más adelante, también se verán afectados los servicios generales en la nube, lo que hasta ahora conocíamos como Microsoft Azure, que pasarán a denominarse Microsoft Cloud Core Services. Sin duda, todo un acierto el eliminar la palabra "Azure", que al fin y al cabo no dice nada, y comunicar más claramente dónde se encuentra la aportación de valor del producto, como ya hacen otros proveedores como Amazon, IBM o Google.
Según Patrick Iñuelas, product manager de Microsoft Naming Core Team (la división de marketing encargada de poner en marcha estos cambios) están ahora trabajando en el próximo paso, que es renombrar Xamarin a Silverlight Core, en palabras textuales, "porque tenemos el nombre de dominio disponible".
¿Y mi opinión respecto a todos estos cambios? Pues, por supuesto, absolutamente favorable. Los nombres anteriores sonaban ya algo añejos y a los jóvenes desarrolladores les sonaba a algo “legacy”; es lógico que cada cierto tiempo haya que hacer un reboot para poner los contadores a cero y comenzar de nuevo. En cuanto a los nombres elegidos, creo que son totalmente acertados porque son fáciles de recordar, tienen gancho, y se alinean correctamente con la tendencia "Core" de los últimos tiempos, dando una imagen mucho más fresca y moderna de los productos.
[Actualizado 30/12] Nota para despistados: pues no, no es una noticia real, simplemente se trata de una broma por el 28 de diciembre, día de los inocentes en España. Visual Studio 2017 seguirá llamándose así, Azure no cambiará de nombre, y tampoco Xamarin... al menos de momento ;D
Publicado en Variable not found.
martes, 22 de noviembre de 2016
Como sabéis, hace unos días se presento en el evento Connect() la primera revisión de ASP.NET Core, versionada como 1.1.0.A continuación desgranaremos un poco qué se incluye en esta entrega, pero gracias al uso de versionado semántico, sin entrar en más detalles ya podemos saber que esta nueva versión añade características adicionales y mejoras compatibles hacia atrás, por lo que no tendríamos que preocuparnos por romper algo si actualizamos a ella (¡al menos en teoría, claro! ;)).
martes, 28 de junio de 2016
¡Por fin! Tras un desarrollo muy largo y convulso, ayer se presentaron las respectivas versiones 1.0 RTM de .NET Core, ASP.NET Core y Entity Framework Core, junto con actualizaciones de una serie de productos relacionados.La verdad es que hace tan sólo unos años, presentar la nueva versión de ASP.NET en la conferencia Red Hat DevNation habría resultado una auténtica osadía y probablemente habría acabado con tomates volando hacia el escenario. Pero esto es agua pasada, y este simple gesto es una prueba más de que realmente las cosas han cambiado en Microsoft.
Con el lanzamiento de la versión 1.0 de la infraestructura .NET Core y el conjunto de frameworks basados en ella (ASP.NET, MVC, Entity Framework), iniciamos una nueva época en la que aquél sueño de desarrollar o ejecutar fácilmente aplicaciones .NET en cualquier plataforma es ya una realidad, y con todo el soporte y las bendiciones del gigante de Redmond. Escenarios antes impensables, como desarrollar desde Mac para desplegar en Linux, o crear nuestras aplicaciones en Windows y explotarlas desde un contenedor Docker, son ya posibles.
Estamos ante un reboot en toda regla: todos estos frameworks han sido construidos desde cero teniendo en mente conceptos actuales que ni siquiera existían cuando empezaron a gestarse las versiones iniciales de .NET o ASP.NET "clásicos": la nube, alto rendimiento, escalabilidad, APIs, múltiples dispositivos y plataformas, contenedores, microservicios etc. Y creados usando principios y buenas prácticas que tampoco eran los habituales antaño: inyección de dependencias, clases con responsabilidades limitadas, modularidad, componibilidad, abstracciones basadas en interfaces, pruebas unitarias…
miércoles, 1 de junio de 2016
Va un post rapidito, sólo para informar de un pequeño cambio que ha introducido ASP.NET Core RC2, recientemente lanzado, relativo al nombrado de variables de entorno de sistema operativo.Desde RC2, los nombres de las variables de entorno de sistema operativo que permiten configurar ciertos aspectos, como definir si el entorno de ejecución es "Development" o "Production" usan ahora el prefijo "ASPNETCORE_":
No es la primera vez que cambia, de hecho creo recordar tres o cuatro prefijos diferentes a lo largo de la vida del producto desde sus primeras betas, así que espero que esta sea la definitiva :)
Publicado en Variable not found.
martes, 24 de mayo de 2016
Como sabéis, hace unos días se lanzaron las respectivas versiones Release Candidate 2 de .NET Core y los frameworks ASP.NET Core y EF Core.Los detalles ya los comentamos en un post anterior, ahora vamos a centrarnos en ver algunos cambios importantes que llaman la atención cuando empezamos a jugar con esta nueva entrega de ASP.NET Core.
lunes, 9 de mayo de 2016
Hace un par de días, Scott Hunter, Program Manager de .NET en Microsoft, desvelaba las fechas de aparición y otros detalles sobre las próximas releases de ASP.NET Core, de las que no teníamos noticias desde el pasado mes de febrero, momento en que decidieron retrasar los lanzamientos previstos.
Veamos cómo queda ahora la cosa.
martes, 9 de febrero de 2016
Pues a estas alturas, no son pocos los posts que hemos ido publicado por aquí sobre características que cambian o desaparecen en el salto a las nuevas tecnologías "core", pero no se vayan todavía, aún hay más ;)En esta ocasión, comentaremos muy brevemente una gran ausencia en las vistas Razor: la directiva
@helper, que no estará disponible en la primera versión de ASP.NET Core MVC.<Disclaimer>Aunque en una Release Candidate las cosas no deberían cambiar, ya han demostrado bastantes veces que sí que cambian, por lo que algo de lo que digamos aquí podría no ser cierto en la versión final del producto</Disclaimer>
Esto no es un tema reciente: hace ya bastantes meses, la implementación que había era bastante incompleta y no encajaba bien en la nueva arquitectura, por lo que tras algunos debates y reuniones de diseño, se decidió que lo mejor era eliminar esta directiva.
martes, 29 de septiembre de 2015
Desde la creación de MVC, los helpers han sido piezas fundamentales en la composición de nuestras vistas. Llamadas como las habituales Html.ActionLink() o Html.TextBoxFor() nos han permitido durante años crear interfaces de forma sencilla y productiva, pues se trataba de métodos muy reutilizables capaces de ejecutar lógica de presentación y generar bloques de HTML por nosotros (o CSS, o incluso Javascript).De hecho, los helpers han sido la fórmula recomendada para crear componentes reutilizables de generación de código de marcas en las páginas de nuestras aplicaciones MVC y son muy utilizados tanto por el propio framework como por componentes visuales de terceros. Pero esto no implica que fuera una solución perfecta o exenta de problemas…
martes, 22 de septiembre de 2015
Desde la llegada de Razor, hace ya bastante tiempo, usamos en ASP.NET MVC el archivo _ViewStart.cshtml de las carpetas de vistas de nuestra aplicación para introducir código de inicialización de éstas. Era un buen lugar para establecer propiedades como el Layout de forma genérica, sin tener que hacerlo en cada una de las vistas que se encontraran por debajo en el árbol de directorios en el que se definía.En ASP.NET Core MVC 1.0 se le ha unido un compañero llamado _ViewImports.cshtml, cuya finalidad y funcionamiento es parecido al tradicional ViewStart, porque se procesa antes de ejecutar una vista e igualmente afecta a todas las vistas que se encuentren por debajo de este archivo en el árbol de directorios, aunque aporta algunas diferencias bastante interesantes. Comentamos a continuación los aspectos más destacables.
martes, 21 de abril de 2015
Seguro que ya todos conocéis la fórmula mágica mediante la cual podemos activar la compilación de vistas en versiones de ASP.NET MVC anteriores a la 6. Los que no sepáis de qué os hablo, podéis echar un vistazo a este vídeo que publiqué en el blog de CampusMVP hace algún tiempo: VIDEO: Activar la compilación de vistas en ASP.NET MVC.
Muy resumidamente, el asunto consistía en editar manualmente el archivo de proyecto de Visual Studio, con extensión .csproj, y establecer el contenido del tag <MvcBuildViews> a true.
martes, 10 de marzo de 2015
Hemos comentado en algunas ocasiones que, aparte de la entrada de ASP.NET Core y los cambios en la infraestructura que ello implica, el nuevo MVC incluye también algunas novedades bastante interesantes. Ya estuvimos viendo hace algún tiempo los filtros asíncronos, y hoy vamos a centrarnos en una nueva directiva que podremos utilizar en nuestras vistas Razor a partir de la llegada de la próxima versión del framework.La novedad en cuestión consiste en la capacidad de añadir a las vistas propiedades cuyo contenido será cargado en tiempo de ejecución usando el motor de inyección de dependencias de ASP.NET 5. o dicho de otra forma, se trata de una implementación de inyección de dependencias en las vistas, componentes en los que hasta ahora eso no era posible, al menos de forma directa y sencilla.
Vamos a verlo en detalle, pero antes, recordad: a día de hoy ASP.NET Core MVC sigue todavía en el horno, y puede que algunas de las cosas que cuente por aquí no sean del todo ciertas para la versión final.
martes, 24 de febrero de 2015
Nota [05/10/2015] - Hay una versión actualizada de este post.
La inyección de dependencias ha sido un tema recurrente en Variable not found desde hace bastante tiempo, y dadas las grandes novedades incluidas en ASP.NET 5 al respecto estaba deseando hincarle el diente y publicar algo sobre el tema.Para los perezosos, podríamos resumir el resto del post con una frase: ASP.NET 5 viene construido con inyección de dependencias desde su base, e incluye todas las herramientas necesarias para que los desarrolladores podamos usarla en nuestras aplicaciones de forma directa, en muchos casos sin necesidad de componentes de terceros (principalmente motores de IoC que usábamos hasta ahora). Simplemente, lo que veremos a continuación es cómo utilizar esta característica ;)
Pero permitidme una nota antes de empezar: si no sabes aún lo que es inyección de dependencias, el resto del post te sonará a arameo antiguo. Quizás podrías echar previamente un vistazo a este otro, Desacoplando controladores ASP.NET MVC, paso a paso, que aunque tiene ya algún tiempo, creo que todavía es válido para que podáis ver las ventajas que nos ofrece esta forma de diseñar componentes.
Ah, y recordad: todo lo que vamos a ver podría cambiar conforme vaya avanzando el desarrollo del producto, pero más o menos son cosas que parecen relativamente estables desde hace algún tiempo.
martes, 17 de febrero de 2015
Hace sólo unos días comentábamos la próxima desaparición del Global.asax a partir de ASP.NET Core y su sustitución por la clase StartupY en esta ocasión hablaremos sobre la desaparición del Web.config, el célebre archivo de configuración que lleva con nosotros desde los inicios de ASP.NET. Nacido en momentos en que se pensaba que XML era la panacea y muy ligado al denostado System.Web, ha sido útil durante años para configurar aspectos relativos a la compilación y ejecución de las aplicaciones web en el servidor, así como el “sitio oficial” para introducir de settings como cadenas de conexión y otros valores configurables de nuestros sistemas.
Pero, antes de continuar, un disclaimer: ASP.NET Core está aún en desarrollo, y parte de lo que se diga aquí puede no ser del todo cierto mañana mismo, aunque posiblemente los conceptos fundamentales sí lo serán. O eso espero ;)
martes, 10 de febrero de 2015
Hace poco hablábamos del destierro del Global.asax en ASP.NET Core, y de cómo la clase Startup, siguiendo la convención establecida por este framework, era el lugar elegido para introducir código de inicialización.Pero además del código personalizado que podamos introducir, es donde, por defecto, se configuran aspectos tan importantes como los middlewares que guiarán el proceso de las peticiones, o la inyección de dependencias incluida de serie en el framework.
En este post vamos a estudiar un poco más a fondo la clase de inicialización de ASP.NET Core, y comenzaremos viendo qué vamos a encontrar en ella, y las convenciones a las que hay que ceñirse para que el entorno pueda inicializarse correctamente.
martes, 3 de febrero de 2015
El célebre Global.asax ha estado con nosotros durante más de diez años, y, junto con el Web.config y algunos otros, ha sido uno de los archivos que encontrábamos siempre en la carpeta raíz de toda aplicación web basada en ASP.NET.Durante lustros lo hemos usado para introducir código de inicialización de nuestras aplicaciones y para tomar el control en distintos momentos del proceso de las peticiones: al recibirse una solicitud, al retornar la respuesta, al comenzar una sesión, al finalizarla, al autenticar las peticiones… en fin, que es fácil echarlo de menos cuando abrimos o creamos nuestra primera aplicación ASP.NET Core.
Pero como ya hemos comentado por aquí en alguna ocasión, con ASP.NET Core nuestro entrañable Global.asax desaparece para no volver, en primer lugar porque la propia clase
HttpApplication, donde se originan esos eventos en los que introducíamos nuestro código, es parte inseparable de System.Web, y ya sabemos que uno de los principales objetivos de ASP.NET Core es desligarse por completo de este pesado lastre. Pero hay algunos motivos estructurales más, que veremos a continuación.
domingo, 28 de diciembre de 2014
Por mi trabajo, suelo “husmear” en el código de muchas aplicaciones creadas por equipos de trabajo en empresas de todo tipo y nacionalidad, y os puedo asegurar que existe un denominador común en todas ellas y que seguro reconoceréis en vuestro propio código: los desarrolladores escribimos como nos viene en gana.No es poco frecuente ver aplicaciones con faltas de ortografía que un niño de primaria calificaría como graves. Y notad que no hablo sólo de las etiquetas, mensajes y otros elementos visuales que van a parar a los atónitos ojos de nuestros usuarios, sino también de lo que hay por detrás, en el código fuente.
A nivel de código, las denominaciones internas en clases, métodos o variables, textos en comentarios o incluso los mensajes en check-ins en el control de código fuente, son habitualmente terribles. Claro, sabemos que eso no lo va a leer nadie, o al menos nadie de fuera de nuestro entorno, y bajamos la guardia hasta límites que rozan la ilegalidad. Mezclamos idiomas sin ningún criterio (¿quién no ha escrito alguna vez un método
GetFacturas(), obtenerResources () o una variable lineasCount en su base de código?), cometemos atropellos ortográficos, gramaticales y otros tipos de aberración de forma impune, escudados en que no hay que prestar atención a esos detalles porque es sólo código.Y lo peor es que esta actitud de desidia es contagiosa. Cuando entras en un proyecto donde todo está escrito sin ningún tipo de miramiento, lo normal es que continúes en esa línea, haciendo que la barbarie sea cada vez mayor y, a su vez, más contagiosa en el futuro. Y cuando comiences otro proyecto, llevarás la costumbre de hacerlo así y continuarás extendiendo esta práctica ad eternum.
Pero, ah, amigos artesanos del código, esto se va a acabar.
Las próximas versiones de Visual Studio corregirán drásticamente esta tendencia, incluyendo la revisión ortográfica como parte del proceso de compilación. Además, como comentó S. Somasegar en una reciente entrevista,
“esta característica no podrá ser deshabilitada; en caso contrario ya sabemos lo que ocurriría, y va en contra de la firme apuesta de Microsoft hacia un mundo que se comunique mejor”Y la cosa va muy en serio. Para dar mayor formalidad a esta necesaria iniciativa, Microsoft ha firmado un acuerdo con distintas academias responsables de definir y actualizar la mayoría de idiomas del mundo, como la National Commission on Language and Script Work (国家语言文字工作委员会) de China, la Real Academia Española (RAE), Academy of the Arabic Language (مجمع اللغة العربية), la Royal Galician Academy, o Council for German Orthography (Rat für deutsche Rechtschreibung) por citar sólo algunas. De estas instituciones obtendrá los diccionarios actualizados que serán utilizados por las herramientas del gigante de Redmond para comprobar que estamos escribiendo como debemos. En el caso del inglés es distinto porque no existe un organismo regulador, pero se atenderán a las guías oficiales publicadas por los países donde es la lengua oficial.
En Visual Studio tendremos disponibles propiedades a nivel de proyecto y de cada archivo (de código, recursos, diseñadores, etc.) en el que indicaremos el idioma en el que debe realizarse la comprobación.
Por supuesto, también ha sido actualizado intellisense para alternativas a las palabras que vayamos escribiendo e incluso un menú de sinónimos, de la misma forma que Microsoft Word:
Para los casos en que el idioma pueda cambiar dentro del propio archivo o incluso en distintas secciones de éste, se han añadido directivas
#pragma que pueden usarse en cualquier punto. Por ejemplo, en el siguiente código se han detectado dos errores de compilación para la porción escrita en español, en un comentario y en el nombre de un método:
Por supuesto, las comprobaciones atienden al camel casing, es decir el nombre del método
ObtenerFactura() se entenderá correcto, mientras que Obtenerfactura() no lo será. Otra ventaja colateral de esta característica es que dejaremos de utilizar nombres de variable sin sentido como “s”, “xyz”, tendiendo a que realmente se refleje su intencionalidad como “saldo” o “coordenadasTridimensionales”. Se está estimando, sin embargo, excluir las variables de tipo índice obvias como la típica “i” en un bucle for por razones históricas.Las mismas directivas y propiedades se aplicarán en las comprobaciones de cadenas de texto, recursos (.resx) y diseñadores de la aplicación. De esta forma, podremos estar seguros de que los textos que lanzamos a los usuarios habrán superado un nivel mínimo de calidad, que falta hace en muchas aplicaciones:
En fin, creo que es una iniciativa absolutamente necesaria para mejorar la calidad interna de nuestro código y, como extensión, de nuestras aplicaciones, y me gustaría felicitar a Microsoft por haber tomado esta controvertida decisión. Seguro que traerá mucha polémica, pero estoy convencido de que es por el bien de la humanidad.
Aunque en principio esta nueva característica sólo estará disponible para Visual Studio 2015, no se descarta la creación de extensiones para todas las versiones de Visual Studio, comenzando en la 2005. Está previsto incluso su introducción en el proyecto Omnisharp para poder aplicarlo en entornos de desarrollo más allá de Visual Studio, lo que abriría su uso a otras plataformas como Mac o Linux, y de la posibilidad de desarrollar plugins oficiales para Git, Mercurial, Subversion, TFS y sistemas de integración continua que permitan automatizar estas comprobaciones.Se avecina un año maravilloso donde los sistemas de control de código fuente podrán rechazar un commit o check-in por tener faltas de ortografía, o en el que en nuestra mesa, junto a clásicos como C Programming language o Code Complete , podremos encontrar el diccionario de la real academia de la lengua española.
¡Feliz escritura de código!
[Actualizado 30/12]
Nota para despistadillos: obviamente no es real, se trata simplemente de una broma del Día de los Inocentes. Así que tranquilos, podemos seguir dando patadas al diccionario impunemente en nuestro código :-DDD
Nota para despistadillos: obviamente no es real, se trata simplemente de una broma del Día de los Inocentes. Así que tranquilos, podemos seguir dando patadas al diccionario impunemente en nuestro código :-DDD
Publicado en Variable not found.
martes, 16 de diciembre de 2014
Como ya hemos visto por aquí en alguna ocasión, hace tiempo que MVC soporta controladores asíncronos, permitiendo la implementación de acciones muy eficientes desde el punto de vista de la utilización de los recursos del servidor.Sin embargo, en cuanto pretendíamos llevar a los action filters la misma filosofía nos encontrábamos con que la infraestructura no estaba preparada, es decir, no teníamos una forma clara de introducir llamadas asíncronas en el cuerpo de los filtros. Como consecuencia, todas las tareas que se realizaban en su interior eran puramente síncronas y dejaban bloqueados los hilos destinados a procesar peticiones mientras se completaban las operaciones, lo cual es especialmente un despilfarro cuando se trata de tareas de entrada/salida.
Afortunadamente esto parece que va a terminar con ASP.NET Core MVC, que soportará ya esta solicitada característica. Pero ojo, que Core MVC está aún en desarrollo, por lo que todo lo que cuento a continuación puede cambiar.
Pero empecemos desde el principio, viendo qué ha cambiado por abajo para que sea posible crear filtros con código asíncrono en su interior. Quizás sea una lectura un poco densa, pero creo que es interesante para comprender cómo funcionan las cosas por dentro.
miércoles, 3 de diciembre de 2014
Aunque aún en beta e inmersa en un intenso proceso de desarrollo, la próxima versión de ASP.NET MVC está tomando forma en los hornos de Microsoft, y, sin ser definitivas, ya se pueden ver cuáles serán las novedades principales que la acompañarán. En futuros posts iremos entrando en mayor detalle, pero de momento vamos a echar un vistazo desde una cierta distancia para tener la idea general sobre dónde estamos y la evolución que vamos a encontrar en las nuevas versiones de tecnologías y plataformas, de forma que podamos ver en qué nos afectará como desarrolladores y, en definitiva, para qué tenemos que irnos preparando.
Disclaimer: estamos aún en una fase en la que algunas cosas pueden cambiar y aún no existe información exhaustiva de muchos detalles, por lo que pueden existir ausencias o imprecisiones. Pero bueno, digo yo que el grueso será más o menos correcto ;-)
