(Haz clic sobre la imagen para agrandarla)
viernes, 22 de septiembre de 2017
Configuración correcta del plugin de video ePSXe 1.9.0 para Tales of Destiny 1 y 2 de PSX
Hola a todos. Este será un post corto, ya que sólo colocaré la configuración de video en el ePSXE 1.9.0 que yo uso para jugar los grandiosos juegos de PSX Tales of Destiny 1 y 2 traducidos al Español por el gran grupo de Tales Translations.
La configuración varía un poco con respecto a la del Chrono Cross. Tiene el filtro 2xSaI que elimina los pixeles del os bordes.
(Haz clic sobre la imagen para agrandarla)
El Tales of Destiny 1 se ve así, más estilizado:
El Tales of Destiny 2 se ve así:
(Haz clic sobre la imagen para agrandarla)
miércoles, 30 de agosto de 2017
The State of C# en Español (El estado de C#)
Traducción al español del excelente paper llamado The State of C# publicado por Progress (los dueños del producto Telerik), el 25 de agosto de 2017. Tiene algo de publicidad a su producto estrella, hay que admitirlo, pero tiene muchas cosas interesantes de C#, del mercado, de Visual Studio y de las últimas características en la versión 7.0. Escrito por originalmente por Kevin Griffin. Traducido por Hernaldo González.
Al comienzo del año 2000, Microsoft públicamente anunció sus planes para su .NET Framework, el cual era una serie de librerías administradas. Este nuevo framework, sin embargo, necesitaba un nuevo lenguaje. Se le llamó en un inicio "Cool", C# había nacido.
C# fue originalmente diseñado para ser abierto, pero bajo estándares. Cada versión de C# es aprobada no sólo por Microsoft, sino por ECMA International y la International Organization for Standardization (ISO). ¿Qué quiere decir esto para el desarrollador? Cualquiera puede hacer un compilador de C# para sus sistemas operativos. El Mono Project, el cual es una implementación tipo código abierto del compilador C# y del .NET Framework, es el perfecto ejemplo del C# estándar en acción.
C# ha tenido 5 revisiones importantes desde su versión 1.0 en el año 2002. En este tiempo ha tenido varias mejoras importantes como: generics, métodos y tipos anónimos, propiedades automáticas, expression trees, dynamics, métodos asíncronos y compilación como servicio. No es una lista detallada, pero es para ver como C# fue creciendo a través de los años.
Ahora, si eres ingeniero informático, analista de sistemas y vas en el último año de la carrera o estás recién egresado y estás buscando el norte en la industria de la informática, la pregunta que deberías hacerte a ti mismo es: "¿Debería aprender C# para tenerlo dentro de mi portafolio de conocimientos"?
¿Qué hay de los otros lenguajes de la lista? Mientas muchos desarrollan en JavaScript, Android o Java, ninguno de ellos cae en la categoría que los desarrolladores les encanta trabajar con ellos. En cambio C# si.
¿Qué tal el sueldo promedio de un desarrollador C#? Un desarrollador en un trabajo horario de oficina full time, gana 95 mil dólares al año (N. Del T. que en pesos Chilenos serían 5 millones mensuales, wuau, cambio al 25 de agosto 2017). A menudo en este sueldo se incluye que también sabe JavaScript y otros cosas. La única forma de ganar más, digamos unos 105 mil dólares al año (5.6 millones mensuales Chilenos) requiere que el desarrollador sepa tecnologías basadas en la nube como Reac o Redis.
Si hablamos de un desarrollador front-end, el sueldo promedio baja a 75 mil dólares al año (3.9 millones mensuales Chilenos). Lo que si, la encuesta no indica si es un desarrollador Web o también incluye aplicaciones de escritorio.
Un desarrollador C# especializado en los datos y con conocimientos de Machine Learning (N. Del T. Librerías que simulan el pensamiento humano como aplicaciones predictivas o de reconocimiento de caras en imágenes), puede ganar hasta 85 mil dólares al año (4.5 millones mensuales Chilenos). Los mismos números aplican para un desarrollador Android cuyo lenguaje principal es C#. Incluso lo que gana un desarrollador iOS o un desarrollador Android, no se diferencia mucho de lo que gana un desarrollador C# que implemente para ambas plataformas usando Xamarin.
Actualmente se puede usar para diversos lenguajes como Visual Basic, C/C++, F#, C#, Python, Ruby, HTML, JavaScript y otros.
Esta variedad de lenguajes soportados es posible gracias al sistema de plugins que tiene el editor. Permite que un desarrollador de Microsoft, o incluso de la misma comunidad, desarrolle complementos que funcionen correctamente con los subsistemas de Visual Studio.
Hay muchas características de Visual Studio que hace que los desarrolladores no se vayan. En primer lugar, está el editor de código de clase mundial. A medida que codificas, a menudo eres asistido directamente por Visual Studio a través de una función llamada Intellisense. Esta función analiza el código después de cada pulsación de tecla y, a menudo, puede proporcionar el autocompletado de variables y métodos. Esta previsión inteligente está diseñada específicamente para el lenguaje que estás desarrollando, lo que significa que Intellisense C# e Intellisense CSS son experiencias diferentes que resuelven el mismo tipo de problema. Las herramientas de depuración que tiene integradas te ayudan a reducir problemas específicos, y permiten por ejemplo, hacer un "paso a paso" de las líneas código.
¿Habrá una característica que le falte a Visual Studio que haga que mejore tu experiencia de desarrollo?
Hay un gran grupo de proveedores en la industria que desarrollan herramientas para aumentar y mejorar la experiencia de desarrollo usando Visual Studio. Por ejemplo, Telerik de la empresa Progress es el creador de JustCode, una extensión de Visual Studio que hace que la codificación sea más rápida y fácil añadiendo más inteligencia y accesos directos al editor de código de los que ya vienen por defecto en el IDE.
En versiones antiguas de Visual Studio debías incluso pagar por su uso, o podías usarlo sólo si estabas suscrito a MSDN. Desde Visual Studio 2015, Microsoft estrenó Visual Studio Community Edition, una versión gratuita de Visual Studio que a la vez permite usar cualquier plugin que desees instalar. A diferencia de los anteriores Visual Studio Express, cualquier aplicación creada por un desarrollador individual ahora puede ser usada de forma comercial.
Visual Studio es el Roll Royce de los entornos de desarrollo. El gran obstáculo que alegan algunos desarrolladores es que es una herramienta poderosa pero sólo para desarrollar aplicaciones que funcionan en Windows. El mercado actualmente está lleno de herramientas que permiten desarrollar para Linux u OSX.
En una conferencia del año 2016, Microsoft anunció el editor Visual Studio Code. Visual Studio (VS) Code puede ser usado para codificar para que funcione en un ambiente Windows, OSX o Linux.
Aunque sea una herramienta más liviana, VS Code soporta varias cosas que tiene Visual Studio. Tiene un editor con estilos de colores según el lenguaje, ¡soportando C#, C++, F#, Elixir, Docker, Python, Ruby and otros!
VS Code no ofrece un Intellisense completo que si encontrarías en Visual Studio. Sin embargo, VS Code proporciona una robusta funcionalidad de code completion para varios lenguajes.
Para los desarrolladores que trabajan con C#, Node.js y Python, hay soporte de depuración incorporado adicional.
Al combinar la ligera arquitectura que posee y el soporte multiplataforma, VS Code es una excelente herramienta para que un desarrollador comience con C#.
Por último, si ya eres fan de otro editor que no sea VS Code, asún estás con suerte. Los desarrolladores de Microsoft junto con muchos colaboradores externos, han construido un plugin increíble llamado Omnisharp. Con Omnisharp, puedes inyectar Intellisense de Visual Studio directamente en el editor de tu preferencia.
Actualmente, Omnisharp es compatible con Atom, Brackets, Emacs, Sublime Text y Vim. También es el motor que potencia las características de code completion de VS Code.
El objetivo subyacente a todas estas herramientas, independientemente de cuál de ellas elijas utilizar, es que si eres un desarrollador que trabaja con C# y .NET Framework, tu experiencia sea inigualable.
¡De ningún modo! Con toda esa inversión de tiempo y energía en C#, no hay límite para el número de plataformas que podrás desarrollar. A continuación, cubriremos algunos de los entornos más comunes que los desarrolladores de C# pueden implementar.
La creación de aplicaciones para Windows siempre ha sido un elemento básico para el desarrollador de C#. Al principio, nuestras aplicaciones se escribieron utilizando Windows Forms (WinForms). WinForms, combinado con las potentes herramientas de diseño dentro de Visual Studio, permite a un desarrollador rápidamente previsualizar la apariencia de una aplicación. La lógica de negocio para las interacciones de los controles se hizo simplemente mediante el uso de eventos.
WinForms también podía ampliarse aún más mediante el uso de suites de terceros, como Telerik WinForms. Estas suites de control ofrecen una amplia variedad de características que faltan en los controles de base proporcionados por defecto. Los controles tales como grids, gráficos y más, podrían fácilmente demorar meses de desarrollo a un equipo de desarrolladores si lo hicieran desde cero, e incluso así, estos controles no serían tan ricos en funciones como lo que se obtiene con la UI de Telerik para WinForms.
Un efecto secundario de tener un flujo de trabajo que se inicia con la etapa de diseño como es en WinForms, es que las aplicaciones comenzaron a crearse con ese mismo look & feel. El término "gris acorazado" fue muy conocido en toda la industria porque reflejaba cómo se veían todas las aplicaciones de WinForms. Desviarse de la norma era difícil, incluso con la ayuda de herramientas de terceros.
Con el lanzamiento de C# 3.0, Microsoft anunció el Windows Presentation Foundation, o WPF. Esto hizo repensar el proceso de construcción de aplicaciones centradas en Windows. En lugar de un enfoque centrado en el diseño, los desarrolladores podrían construir las interfaces de usuario con un nuevo lenguaje llamado XAML.
Las aplicaciones construidas con WPF seguían usando C# tras la cortina. Sin embargo, los desarrolladores ahora tenían la capacidad de construir interfaces más robustas tan fácilmente como si fuera HTML.
Aquellos que querían una experiencia de diseño similar a WinForms podría utilizar Blend, una herramienta de diseño similar a Photoshop, pero especializada en la generación de XAML. Al igual que con WinForms, un desarrollador que no quería reinventar la rueda podía utilizar una de las asombrosas suites de control de terceros disponibles, como la UI de WPF.
La liberación de Windows 10 abrió un nuevo mundo de oportunidades para los desarrolladores de Windows. Windows ya no es sólo un sistema operativo de escritorio. Se puede ejecutar en escritorios virtuales, pero también sobre dispositivos Windows Mobile, Xbox One y Hololens.
Con la llegada de Universal Windows Platform (UWP) se creó un entorno en el que un desarrollador podía crear una única aplicación que podía ejecutarse de forma nativa en Windows 10, pero también con unos pocos ajustes, realizar implementaciones para Windows 10 Mobile y Xbox One. Debajo de la alfombra, hay un potente subsistema accesible a través de C#, C++, Visual Basic y JavaScript. Las tecnologías de WPF y XAML se combinan fácilmente.
Ahora, volvamos nuestra atención al módulo Web, más conocimo como ASP.NET. En los últimos años, ha habido tres revoluciones por el lado de ASP.NET.
En los primeros días de .NET y WinForms, Internet estaba todavía en su infancia. El concepto de constriur una aplicación comercial basada en la web era relativamente nuevo, y las herramientas no estaban diseñadas para manejar aplicaciones en esta escala.
¿Cómo una compañía enfocada en desarrolladores como Microsoft toma millones de programadores con conocimiento de WinForms y patrones de diseño similares y los convierte en desarrolladores web? La respuesta está en el nacimiento y la liberación inicial de ASP.NET WebForms.
Cualquier desarrollador que tuviera experiencia con WinForms podría traducir rápidamente esas habilidades a la web. Después de todo, era similar a WinForms, una aplicación WebForms se iniciaba con un diseño y el control se hacia mediante el uso de eventos (event handlers).
Su núcleo fue, una vez más, C#.
La web ha madurado mucho desde el inicio de WebForms. En 2007, ASP. NET se convirtió en la versión inicial de ASP.NET MVC, una implementación del patrón Model View Controller construido en la capa superior de ASP.NET. Los desarrolladores que querían un entorno más puro para crear aplicaciones web podrían usar ASP.NET MVC, así podían crear aplicaciones que no tuvieran esa sobrecarga de ASP.NET WebForms.
Hubo una falla fundamental en la creación de aplicaciones ASP.NET: su estrategia de deploy se centró únicamente en el uso de Internet Information Services (IIS) sobre un servidor Windows. El hosting basado en Windows es a menudo más costoso de configurar y mantener frente a Linux o sistemas operativos similares. El ecosistema de ASP.NET era principalmente para la empresa, que podía pagar los costos de licencias, o para sitios de bajo tráfico que podrían funcionar eficientemente dentro de ambientes compartidos.
A finales de 2015, ASP.NET pasó por otro "renacimiento" con la introducción de ASP.NET Core (y .NET Core framework).
A diferencia de su predecesor, ASP.NET Core es opensource, una plataforma abierta que rearma el cómo funciona ASP.NET. Todavía estamos en los primeros días de esta plataforma, pero imagina ser capaz de construir una aplicación web completa en ASP.NET que se puede implementar rápida y fácilmente a Windows, Linux o incluso OSX sin ningún cambio de código.
Actualmente, los únicos idiomas soportados en ASP. NET Core son C# y F#, mientras que Visual Basic ya lo es desde el inicio.
Sabemos que C# es bueno para aplicaciones web y de escritorio, pero todos sabemos que para móviles no es buena ¿cierto?
Como dijimos anteriormente, con Universal Windows Platform, puedes generar aplicaciones para Windows 10 Mobile con unos simples cambios en la configuración. Ahora si miramos el mercado estadounidense vemos las ventas del año 2016 para Windows Phone y estás apenas alcanzan el 3% del total. La mayoría de las ventas las tiene iOS y Android.
Una falla en la industria es que si quieres desarrollar aplicaciones iOS, necesitas aprender Objective-C o Swift. Si deseas desarrollar aplicaciones para Android, necesitas saber Java.
En febrero de 2016, Microsoft compró Xamarin, un framework para la construcción de aplicaciones iOS y Android sobre la capa superior de la Plataforma Mono.
El truco de Xamarin es que puedes construir para Android nativo, iOS nativo e incluso aplicaciones nativas de Windows usando la misma base hecha en C#. Ninguna otra plataforma puede presumir de dichas características. No siquiera las soluciones móviles multiplataforma como PhoneGap o WebView, donde la experiencia es un simple shell a la cual las aplicaciones son inyectadas. Xamarin ofrece a los desarrolladores acceso a la misma apariencia y la sensación que los usuarios de iOS y Android esperan ver.
Entonces, recapitulemos todas las plataformas que un desarrollador de C# podría encontrarse en el mercado. En primer lugar, para el tipo escritorio, puede trabajar en aplicaciones Windows Forms, Windows Presentation Foundation y la nueva Universal Windows Platform. La siguiente es la web, donde una aplicación podría ser construida con ASP.NET WebForms o ASP.NET MVC. Los desarrolladores más astutos ahora pueden incluso usar ASP.NET Core, lo que les permite trabajar no sólo en Windows, sino en Linux u OSX. Por último, el mercado móvil se alcanza mediante el uso de Xamarin para crear aplicaciones móviles multiplataforma que comparten una base de código común escrita en C#.
¿Cuáles son algunas de las principales características que ha tenido en 15 años de innovación? Si ya eres un desarrollador de C#, las sabrás de memoria.
Algo tan simple como Generics, Partial Types y Nullable types no existían hasta la versión C# 2.0. En la versión C# 3.0 se introdujeron Extension Methods, Expression trees, Lambda expression y otras cosas. Estas características permitieron que existiera LINQ (Language Integrated Query), una característica que cambió bastante la forma en que los desarrolladores de C# trabajaban la data.
C# 4.0 cambió radicalmente la forma en que los desarrolladores usaban los tipos, introduciendo dynamic types a un lenguaje de tipo estático. Métodos asíncronos se agregaron en C# 5.0, lo que proporcionó a los desarrolladores una forma de construcción de aplicaciones más eficientes, permitiendo que las tareas largas de ejecución fueran asíncronas.
Por último, en C# 6.0, vimos el compilador Roslyn (Compilador como servicio), que proporciona un compilador C# a los desarrolladores para que se utilizara en tiempo de ejecución. También proporciona herramientas de análisis de código y potencia muchas de las características del desarrollador integradas en Visual Studio.
Esta lista no es la más completa, pero proporciona un amplio panorama de cómo C# ha madurado a lo largo de los años. Si eres nuevo en C#, tómate el tiempo para revisar en detalle esta lista de características.
Es importante tener en cuenta que los siguientes ejemplos y conceptos están todavía en revisión. Su contexto y sintaxis aún se está desarrollando, y no hay garantía de que estas características no se cambien o eliminen en el futuro.
Out Variables (Variables de salida)
La palabra out no es nueva en C#. Si declaras una variable dentro de un método que tenga un parámetro con un out, estás indicando al compilador que estás esperando que el método setee ese valor en tiempo de ejecución.
El ejemplo anterior puede ser refactorizado en este:
Pattern Matching (Coincidencia de patrones)
En C# 7.0 se da un fuerte énfasis en la característica de Pattern Matching. Básicamente consiste en que C# permite buscar algún patrón o ámbito para realizar cierta operación. Como verás más adelante también permite extraer un valor si coincide con el patrón definido.
El siguiente ejemplo muestra claramente como funciona Pattern Matching con la instrucción Switch:
En el primer case, si Persona coincide con el objeto CEO, hará el match y retornará el handler respectivo. En una instrucción evaluaremos si es manager pero a la vez tiene un departamento "sales", entonces llamaremos a una función. Cuando se usa when se evalúa contra el objeto salesManager recién generado. En la siguiente condición queremos evaluar si el objeto es sólo un manager.
Aquí hay dos escenarios. El caso más común es usar el case default, donde tenemos un objeto que no coincide con ninguno de los patrones anteriores. Al final, también hay un caso null que asegurará que el objeto pasado tenga un valor, y lanzará una excepción ArgumentNull cuando esto suceda.
Is-Expressions (Expresiones IS)
Basándonos en la explicación anterior acerca de variables out, podemos usar variables de patrón para crear variables a demanda dentro de un bloque de código.
Como sabemos, el mayor problema con TryParse es que se debe definir la variable antes de la llamada al método TryParse. En C# 7.0, esto ya no es necesario. Puede crear la variable a demanda si el método TryParse retorna True.
Tuples (Tuplas)
En C# 3.0 se agregó el tipo de referencia Tuple<>. ¿Qué es una Tupla? En pocas palabras, una Tuple es una colección de valores.
Imagina el ejemplo anterior donde cargamos la información de una persona. Hay varias formas en que podemos devolver los datos de un método:
Sin embargo, ¿qué pasa si el tipo Persona es descartable? Vas va a recuperar datos, utilizarlo y tirarlo. Crear el tipo Persona para un solo método es un poco engorroso.
El segundo ejemplo utiliza el tipo genérico Tuple<> para recuperar la misma información. ¿Cómo sería la llamada a LoadPerson?
No hay mucho que intuir porque Item1 y Item2 son tan explicativos como "a" o "b".
Con C# 7.0 vamos a tener acceso a Tuplas reales de una manera más cercana a lenguajes funcionales como F#. La firma de método LoadPerson() se refactorizaría así:
Archiva de esta característica como "útil pero algo loco". ¿Cuántas veces has creado un literal numérico y tuvo que contar el número de dígitos para asegurarse de que introdujo el número correcto?
Por ejemplo:
Los nuevos "separadores de dígitos" de C #7.0 te permiten hacer lo mismo, excepto que, en lugar de usar una coma, puedes usar el underscore.
Throw Exceptions
Escribir código defensivo a menudo significa generar un montón de excepciones. En C# 7.0, hay algunos nuevos ajustes en donde puedes lanzar una excepción.
Por ejemplo, considera este método existente:
Una de las excepciones más comunes lanzadas en las aplicaciones .NET es la Null Reference. ¿Cuál es el problema? Los tipos de referencia en C# son nullables por defecto. Esta condición previa causa que los desarrolladores aseguren su código a prueba de balas para evitar que se esté tratando de acceder a una variable que potencialmente podría ser null en tiempo de ejecución.
Para tipos de valores, como int o DateTime, no es posible que el valor sea nulo a menos que las definas como un tipo Nullable.
Ok...pero romperías 15 años de código C#.
Como alternativa, ¿qué pasaría si pudiéramos declarar explícitamente que un tipo de valor sea "no null?" En C# 7.0, el operador "!" se usará para indicar que una variable no puede ser null.
La última versión, C# 7.0, se encuentra en revisión. Se jacta de un conjunto de nuevas características diseñadas para hacer el código más fácil de leer y escribir.
StackOverflow, el recurso más confiable para desarrolladores de Internet en la actualidad, nos dice que C# es una de las cinco plataformas tecnológicas más importantes del mundo. Además, si miramos la encuesta de las tecnologías que los desarrolladores les encanta usar, sólo C# está en ambas listas. Ni siquiera con Java, que también se le considera uno de los mejores lenguajes de la industria, se puede decir que les encanta a los desarrolladores. Finalmente como guinda de la torta, un desarrollador que se especializa en C# puede, en promedio, ganar entre 85 a 95 mil dólares al año.
C# es una triple amenaza: es amado, es demandado y se paga bien.
Tampoco un desarrollador C# se limita a una vida construyendo las famosas ventanas grises de Windows. Como hemos comentado anteriormente, C# te permite crear aplicaciones de Windows en la nueva Universal Windows Platform, o puede usarse para construir aplicaciones más antiguas con Windows Forms. Los desarrolladores web pueden ahora crear sitios completamente funcionales que se ejecutan en Windows Server, Linux u OSX. Xamarin es un framework para que los desarrolladores C# construyan código de forma compartida y que está orientado a la creación de aplicaciones móviles nativas.
Las aplicaciones de clase mundial necesitan entornos de desarrollo de clase mundial. Durante más de 15 años, Visual Studio ha sido el Cadillac de los IDE. Con características como Intellisense, un sorprendente depurador y un rico ecosistema de add-ons, Visual Studio continúa impulsando el concepto de lo que un IDE debería ser.
Los desarrolladores que no necesitan todo el poder de Visual Studio, o quieren una experiencia similar en OSX o Linux, pueden usar Visual Studio Code. Es de código abierto y multiplataforma. Te ofrece una increíble experiencia de codificación en un pequeño paquete. Si ya tienes un editor y no te convence cambiarte, entonces puedes usar el complemento Omnisharp que te permite usar la experiencia Intellisense de C# en casi cualquier otro editor.
¿Es una buena decisión usar C#? La evidencia anterior habla maravillas sobre la viabilidad a largo plazo del lenguaje, el gran ecosistema de herramientas de desarrollo y los diversos nichos donde pueden aplicarse tus conocimientos. No importa si estas orientado a desarrollo de escritorio, web, móvil, C# es una apuesta segura para los próximos años.
Resumen
Imagina que eres un desarrollador en los años 90. Tienes una variedad de herramientas a tu disposición: C++, Java, Delphi, Visual Basic, FoxPro y otros. Sabemos que cada uno de esos lenguajes tiene cosas muy buenas, pero también sus propias fallas.Al comienzo del año 2000, Microsoft públicamente anunció sus planes para su .NET Framework, el cual era una serie de librerías administradas. Este nuevo framework, sin embargo, necesitaba un nuevo lenguaje. Se le llamó en un inicio "Cool", C# había nacido.
C# fue originalmente diseñado para ser abierto, pero bajo estándares. Cada versión de C# es aprobada no sólo por Microsoft, sino por ECMA International y la International Organization for Standardization (ISO). ¿Qué quiere decir esto para el desarrollador? Cualquiera puede hacer un compilador de C# para sus sistemas operativos. El Mono Project, el cual es una implementación tipo código abierto del compilador C# y del .NET Framework, es el perfecto ejemplo del C# estándar en acción.
C# ha tenido 5 revisiones importantes desde su versión 1.0 en el año 2002. En este tiempo ha tenido varias mejoras importantes como: generics, métodos y tipos anónimos, propiedades automáticas, expression trees, dynamics, métodos asíncronos y compilación como servicio. No es una lista detallada, pero es para ver como C# fue creciendo a través de los años.
Ahora, si eres ingeniero informático, analista de sistemas y vas en el último año de la carrera o estás recién egresado y estás buscando el norte en la industria de la informática, la pregunta que deberías hacerte a ti mismo es: "¿Debería aprender C# para tenerlo dentro de mi portafolio de conocimientos"?
Carrera de un desarrollador C#
En la encuesta anual de StackOverflow del año 2016, situó a C# como el 5to lenguaje que deberías conocer. Además se les consultó a los usuarios que lenguaje les encantaba, cuales conocían y cuales quisieran usar. Si miras el lenguaje que más les encantaba, temían o querían trabajar (Most Loved, Dreaded, and Wanted) y cual consideraban muy tecnológico (Top Tech), C# estaba en ambos listados del top.¿Qué hay de los otros lenguajes de la lista? Mientas muchos desarrollan en JavaScript, Android o Java, ninguno de ellos cae en la categoría que los desarrolladores les encanta trabajar con ellos. En cambio C# si.
¿Qué tal el sueldo promedio de un desarrollador C#? Un desarrollador en un trabajo horario de oficina full time, gana 95 mil dólares al año (N. Del T. que en pesos Chilenos serían 5 millones mensuales, wuau, cambio al 25 de agosto 2017). A menudo en este sueldo se incluye que también sabe JavaScript y otros cosas. La única forma de ganar más, digamos unos 105 mil dólares al año (5.6 millones mensuales Chilenos) requiere que el desarrollador sepa tecnologías basadas en la nube como Reac o Redis.
Si hablamos de un desarrollador front-end, el sueldo promedio baja a 75 mil dólares al año (3.9 millones mensuales Chilenos). Lo que si, la encuesta no indica si es un desarrollador Web o también incluye aplicaciones de escritorio.
Un desarrollador C# especializado en los datos y con conocimientos de Machine Learning (N. Del T. Librerías que simulan el pensamiento humano como aplicaciones predictivas o de reconocimiento de caras en imágenes), puede ganar hasta 85 mil dólares al año (4.5 millones mensuales Chilenos). Los mismos números aplican para un desarrollador Android cuyo lenguaje principal es C#. Incluso lo que gana un desarrollador iOS o un desarrollador Android, no se diferencia mucho de lo que gana un desarrollador C# que implemente para ambas plataformas usando Xamarin.
Herramientas
La herramienta más conocida por los desarrolladores de C# es el IDE Visual Studio. Es importante saber que que Visual Studio no está limitado solo a C#, de echo, cuando se estaba creando, Visual Studio se usaba para desarrollos de Visual Basic o C/C++.Actualmente se puede usar para diversos lenguajes como Visual Basic, C/C++, F#, C#, Python, Ruby, HTML, JavaScript y otros.
Esta variedad de lenguajes soportados es posible gracias al sistema de plugins que tiene el editor. Permite que un desarrollador de Microsoft, o incluso de la misma comunidad, desarrolle complementos que funcionen correctamente con los subsistemas de Visual Studio.
Hay muchas características de Visual Studio que hace que los desarrolladores no se vayan. En primer lugar, está el editor de código de clase mundial. A medida que codificas, a menudo eres asistido directamente por Visual Studio a través de una función llamada Intellisense. Esta función analiza el código después de cada pulsación de tecla y, a menudo, puede proporcionar el autocompletado de variables y métodos. Esta previsión inteligente está diseñada específicamente para el lenguaje que estás desarrollando, lo que significa que Intellisense C# e Intellisense CSS son experiencias diferentes que resuelven el mismo tipo de problema. Las herramientas de depuración que tiene integradas te ayudan a reducir problemas específicos, y permiten por ejemplo, hacer un "paso a paso" de las líneas código.
¿Habrá una característica que le falte a Visual Studio que haga que mejore tu experiencia de desarrollo?
Hay un gran grupo de proveedores en la industria que desarrollan herramientas para aumentar y mejorar la experiencia de desarrollo usando Visual Studio. Por ejemplo, Telerik de la empresa Progress es el creador de JustCode, una extensión de Visual Studio que hace que la codificación sea más rápida y fácil añadiendo más inteligencia y accesos directos al editor de código de los que ya vienen por defecto en el IDE.
En versiones antiguas de Visual Studio debías incluso pagar por su uso, o podías usarlo sólo si estabas suscrito a MSDN. Desde Visual Studio 2015, Microsoft estrenó Visual Studio Community Edition, una versión gratuita de Visual Studio que a la vez permite usar cualquier plugin que desees instalar. A diferencia de los anteriores Visual Studio Express, cualquier aplicación creada por un desarrollador individual ahora puede ser usada de forma comercial.
Visual Studio es el Roll Royce de los entornos de desarrollo. El gran obstáculo que alegan algunos desarrolladores es que es una herramienta poderosa pero sólo para desarrollar aplicaciones que funcionan en Windows. El mercado actualmente está lleno de herramientas que permiten desarrollar para Linux u OSX.
En una conferencia del año 2016, Microsoft anunció el editor Visual Studio Code. Visual Studio (VS) Code puede ser usado para codificar para que funcione en un ambiente Windows, OSX o Linux.
Aunque sea una herramienta más liviana, VS Code soporta varias cosas que tiene Visual Studio. Tiene un editor con estilos de colores según el lenguaje, ¡soportando C#, C++, F#, Elixir, Docker, Python, Ruby and otros!
VS Code no ofrece un Intellisense completo que si encontrarías en Visual Studio. Sin embargo, VS Code proporciona una robusta funcionalidad de code completion para varios lenguajes.
Para los desarrolladores que trabajan con C#, Node.js y Python, hay soporte de depuración incorporado adicional.
Al combinar la ligera arquitectura que posee y el soporte multiplataforma, VS Code es una excelente herramienta para que un desarrollador comience con C#.
Por último, si ya eres fan de otro editor que no sea VS Code, asún estás con suerte. Los desarrolladores de Microsoft junto con muchos colaboradores externos, han construido un plugin increíble llamado Omnisharp. Con Omnisharp, puedes inyectar Intellisense de Visual Studio directamente en el editor de tu preferencia.
Actualmente, Omnisharp es compatible con Atom, Brackets, Emacs, Sublime Text y Vim. También es el motor que potencia las características de code completion de VS Code.
El objetivo subyacente a todas estas herramientas, independientemente de cuál de ellas elijas utilizar, es que si eres un desarrollador que trabaja con C# y .NET Framework, tu experiencia sea inigualable.
Plataformas
¿Qué hemos visto hasta ahora? C# es un lenguaje basado en estándares donde sus características han crecido exponencialmente en los últimos 15 años. Combina eso con un conjunto de herramientas de desarrollo de clase mundial y te estarás preparando para una gran carrera de desarrollo centrado únicamente en Windows, ¿correcto?¡De ningún modo! Con toda esa inversión de tiempo y energía en C#, no hay límite para el número de plataformas que podrás desarrollar. A continuación, cubriremos algunos de los entornos más comunes que los desarrolladores de C# pueden implementar.
Escritorio
WinForms también podía ampliarse aún más mediante el uso de suites de terceros, como Telerik WinForms. Estas suites de control ofrecen una amplia variedad de características que faltan en los controles de base proporcionados por defecto. Los controles tales como grids, gráficos y más, podrían fácilmente demorar meses de desarrollo a un equipo de desarrolladores si lo hicieran desde cero, e incluso así, estos controles no serían tan ricos en funciones como lo que se obtiene con la UI de Telerik para WinForms.
Un efecto secundario de tener un flujo de trabajo que se inicia con la etapa de diseño como es en WinForms, es que las aplicaciones comenzaron a crearse con ese mismo look & feel. El término "gris acorazado" fue muy conocido en toda la industria porque reflejaba cómo se veían todas las aplicaciones de WinForms. Desviarse de la norma era difícil, incluso con la ayuda de herramientas de terceros.
Con el lanzamiento de C# 3.0, Microsoft anunció el Windows Presentation Foundation, o WPF. Esto hizo repensar el proceso de construcción de aplicaciones centradas en Windows. En lugar de un enfoque centrado en el diseño, los desarrolladores podrían construir las interfaces de usuario con un nuevo lenguaje llamado XAML.
Las aplicaciones construidas con WPF seguían usando C# tras la cortina. Sin embargo, los desarrolladores ahora tenían la capacidad de construir interfaces más robustas tan fácilmente como si fuera HTML.
Aquellos que querían una experiencia de diseño similar a WinForms podría utilizar Blend, una herramienta de diseño similar a Photoshop, pero especializada en la generación de XAML. Al igual que con WinForms, un desarrollador que no quería reinventar la rueda podía utilizar una de las asombrosas suites de control de terceros disponibles, como la UI de WPF.
La liberación de Windows 10 abrió un nuevo mundo de oportunidades para los desarrolladores de Windows. Windows ya no es sólo un sistema operativo de escritorio. Se puede ejecutar en escritorios virtuales, pero también sobre dispositivos Windows Mobile, Xbox One y Hololens.
Con la llegada de Universal Windows Platform (UWP) se creó un entorno en el que un desarrollador podía crear una única aplicación que podía ejecutarse de forma nativa en Windows 10, pero también con unos pocos ajustes, realizar implementaciones para Windows 10 Mobile y Xbox One. Debajo de la alfombra, hay un potente subsistema accesible a través de C#, C++, Visual Basic y JavaScript. Las tecnologías de WPF y XAML se combinan fácilmente.
Web
Ahora, volvamos nuestra atención al módulo Web, más conocimo como ASP.NET. En los últimos años, ha habido tres revoluciones por el lado de ASP.NET.
En los primeros días de .NET y WinForms, Internet estaba todavía en su infancia. El concepto de constriur una aplicación comercial basada en la web era relativamente nuevo, y las herramientas no estaban diseñadas para manejar aplicaciones en esta escala.
¿Cómo una compañía enfocada en desarrolladores como Microsoft toma millones de programadores con conocimiento de WinForms y patrones de diseño similares y los convierte en desarrolladores web? La respuesta está en el nacimiento y la liberación inicial de ASP.NET WebForms.
Cualquier desarrollador que tuviera experiencia con WinForms podría traducir rápidamente esas habilidades a la web. Después de todo, era similar a WinForms, una aplicación WebForms se iniciaba con un diseño y el control se hacia mediante el uso de eventos (event handlers).
Su núcleo fue, una vez más, C#.
La web ha madurado mucho desde el inicio de WebForms. En 2007, ASP. NET se convirtió en la versión inicial de ASP.NET MVC, una implementación del patrón Model View Controller construido en la capa superior de ASP.NET. Los desarrolladores que querían un entorno más puro para crear aplicaciones web podrían usar ASP.NET MVC, así podían crear aplicaciones que no tuvieran esa sobrecarga de ASP.NET WebForms.
Hubo una falla fundamental en la creación de aplicaciones ASP.NET: su estrategia de deploy se centró únicamente en el uso de Internet Information Services (IIS) sobre un servidor Windows. El hosting basado en Windows es a menudo más costoso de configurar y mantener frente a Linux o sistemas operativos similares. El ecosistema de ASP.NET era principalmente para la empresa, que podía pagar los costos de licencias, o para sitios de bajo tráfico que podrían funcionar eficientemente dentro de ambientes compartidos.
A finales de 2015, ASP.NET pasó por otro "renacimiento" con la introducción de ASP.NET Core (y .NET Core framework).
A diferencia de su predecesor, ASP.NET Core es opensource, una plataforma abierta que rearma el cómo funciona ASP.NET. Todavía estamos en los primeros días de esta plataforma, pero imagina ser capaz de construir una aplicación web completa en ASP.NET que se puede implementar rápida y fácilmente a Windows, Linux o incluso OSX sin ningún cambio de código.
Actualmente, los únicos idiomas soportados en ASP. NET Core son C# y F#, mientras que Visual Basic ya lo es desde el inicio.
Mobile
Sabemos que C# es bueno para aplicaciones web y de escritorio, pero todos sabemos que para móviles no es buena ¿cierto?
Como dijimos anteriormente, con Universal Windows Platform, puedes generar aplicaciones para Windows 10 Mobile con unos simples cambios en la configuración. Ahora si miramos el mercado estadounidense vemos las ventas del año 2016 para Windows Phone y estás apenas alcanzan el 3% del total. La mayoría de las ventas las tiene iOS y Android.
Una falla en la industria es que si quieres desarrollar aplicaciones iOS, necesitas aprender Objective-C o Swift. Si deseas desarrollar aplicaciones para Android, necesitas saber Java.
En febrero de 2016, Microsoft compró Xamarin, un framework para la construcción de aplicaciones iOS y Android sobre la capa superior de la Plataforma Mono.
El truco de Xamarin es que puedes construir para Android nativo, iOS nativo e incluso aplicaciones nativas de Windows usando la misma base hecha en C#. Ninguna otra plataforma puede presumir de dichas características. No siquiera las soluciones móviles multiplataforma como PhoneGap o WebView, donde la experiencia es un simple shell a la cual las aplicaciones son inyectadas. Xamarin ofrece a los desarrolladores acceso a la misma apariencia y la sensación que los usuarios de iOS y Android esperan ver.
Entonces, recapitulemos todas las plataformas que un desarrollador de C# podría encontrarse en el mercado. En primer lugar, para el tipo escritorio, puede trabajar en aplicaciones Windows Forms, Windows Presentation Foundation y la nueva Universal Windows Platform. La siguiente es la web, donde una aplicación podría ser construida con ASP.NET WebForms o ASP.NET MVC. Los desarrolladores más astutos ahora pueden incluso usar ASP.NET Core, lo que les permite trabajar no sólo en Windows, sino en Linux u OSX. Por último, el mercado móvil se alcanza mediante el uso de Xamarin para crear aplicaciones móviles multiplataforma que comparten una base de código común escrita en C#.
Quince años de innovación y de nuevas características
Hasta ahora, hemos hablado mucho del estado actual del ecosistema de C#. Hay fácilmente 15 años de plataformas y sistemas construidos sobre C#. Sin embargo, aún no ha alcanzado su límite. Más bien, toda esta innovación es posible porque C# continúa madurando y creciendo como un lenguaje.¿Cuáles son algunas de las principales características que ha tenido en 15 años de innovación? Si ya eres un desarrollador de C#, las sabrás de memoria.
Algo tan simple como Generics, Partial Types y Nullable types no existían hasta la versión C# 2.0. En la versión C# 3.0 se introdujeron Extension Methods, Expression trees, Lambda expression y otras cosas. Estas características permitieron que existiera LINQ (Language Integrated Query), una característica que cambió bastante la forma en que los desarrolladores de C# trabajaban la data.
C# 4.0 cambió radicalmente la forma en que los desarrolladores usaban los tipos, introduciendo dynamic types a un lenguaje de tipo estático. Métodos asíncronos se agregaron en C# 5.0, lo que proporcionó a los desarrolladores una forma de construcción de aplicaciones más eficientes, permitiendo que las tareas largas de ejecución fueran asíncronas.
Por último, en C# 6.0, vimos el compilador Roslyn (Compilador como servicio), que proporciona un compilador C# a los desarrolladores para que se utilizara en tiempo de ejecución. También proporciona herramientas de análisis de código y potencia muchas de las características del desarrollador integradas en Visual Studio.
Esta lista no es la más completa, pero proporciona un amplio panorama de cómo C# ha madurado a lo largo de los años. Si eres nuevo en C#, tómate el tiempo para revisar en detalle esta lista de características.
¿Qué hay de nuevo en C# 7.0?
Ahora, cambiemos el enfoque y hablamos de lo que viene a nivel de código. Respondamos la pregunta: "¿Qué hay de nuevo en C# 7.0?"Es importante tener en cuenta que los siguientes ejemplos y conceptos están todavía en revisión. Su contexto y sintaxis aún se está desarrollando, y no hay garantía de que estas características no se cambien o eliminen en el futuro.
Out Variables (Variables de salida)
La palabra out no es nueva en C#. Si declaras una variable dentro de un método que tenga un parámetro con un out, estás indicando al compilador que estás esperando que el método setee ese valor en tiempo de ejecución.
public void TestMethod()
{
string fullName;
GetPersonName(“Kevin”, “Griffin”, out fullName);
}
Comúnmente, el problema es que tienes que declarar la variable antes de hacer la llamada al método con out. En C# 7.0, está el concepto de variables out, lo que te ahorrará un par de pulsaciones de teclas ya que declarará la variable en línea.
El ejemplo anterior puede ser refactorizado en este:
public void TestMethod()
{
GetPersonName(“Kevin”, “Griffin”, **out string fullName**);
}
En paralelo, si no sabes el tipo del parámetro, puedes cambiar el tipo del parámetro por var.
Pattern Matching (Coincidencia de patrones)
En C# 7.0 se da un fuerte énfasis en la característica de Pattern Matching. Básicamente consiste en que C# permite buscar algún patrón o ámbito para realizar cierta operación. Como verás más adelante también permite extraer un valor si coincide con el patrón definido.
El siguiente ejemplo muestra claramente como funciona Pattern Matching con la instrucción Switch:
switch(person)
{
case CEO ceo:
CallCeo(ceo);
break;
case Manager salesManager when (salesManager.Department == “Sales”):
CallSalesManager(salesManager);
break;
case Manager other
CallManager(other);
break;
default:
WriteLine(“Standard employee”);
break;
case null:
throw new ArgumentNullException(nameof(person));
}
Recorramos la instrucción Switch paso a paso. El objeto "Persona" se validará con la instrucción Switch y vamos a evaluar dicho objeto de forma distinta dependiendo del tipo y datos que contenga el mismo.
En el primer case, si Persona coincide con el objeto CEO, hará el match y retornará el handler respectivo. En una instrucción evaluaremos si es manager pero a la vez tiene un departamento "sales", entonces llamaremos a una función. Cuando se usa when se evalúa contra el objeto salesManager recién generado. En la siguiente condición queremos evaluar si el objeto es sólo un manager.
Aquí hay dos escenarios. El caso más común es usar el case default, donde tenemos un objeto que no coincide con ninguno de los patrones anteriores. Al final, también hay un caso null que asegurará que el objeto pasado tenga un valor, y lanzará una excepción ArgumentNull cuando esto suceda.
Is-Expressions (Expresiones IS)
Basándonos en la explicación anterior acerca de variables out, podemos usar variables de patrón para crear variables a demanda dentro de un bloque de código.
public void LoadPerson(object age)
{
if (age is int ageInt || (age is string ageString &&
int.TryParse(ageAsString, out ageInt)))
{
// ageInt contains a value.
}
}
Mirando el código, tenemos un caso donde la "edad" de una persona puede entrar en nuestra aplicación como un string o integer. Si la edad es integer, inmediatamente caerá en esta condición. Pero, si edad es un string, tendremos que realizar una conversión utilizando el método int.TryParse.
Como sabemos, el mayor problema con TryParse es que se debe definir la variable antes de la llamada al método TryParse. En C# 7.0, esto ya no es necesario. Puede crear la variable a demanda si el método TryParse retorna True.
Tuples (Tuplas)
En C# 3.0 se agregó el tipo de referencia Tuple<>. ¿Qué es una Tupla? En pocas palabras, una Tuple es una colección de valores.
Imagina el ejemplo anterior donde cargamos la información de una persona. Hay varias formas en que podemos devolver los datos de un método:
public Person LoadPerson(){}
public Tuple LoadPerson(){}
El primer ejemplo devuelve un fully qualified type (N. del T. el objeto completo) y dependiendo del caso, esto es perfectamente aceptable.
Sin embargo, ¿qué pasa si el tipo Persona es descartable? Vas va a recuperar datos, utilizarlo y tirarlo. Crear el tipo Persona para un solo método es un poco engorroso.
El segundo ejemplo utiliza el tipo genérico Tuple<> para recuperar la misma información. ¿Cómo sería la llamada a LoadPerson?
public void Foo()
{
var person = LoadPerson();
var fullName = $"{person.Item1} {person.Item2}";
}
Para un sencillo Tuple de dos valores, estamos empezando a desviarnos del camino de la legibilidad. ¿Qué se supone refleja el elemento 1 o el artículo 2? ¿Es su nombre y apellido respectivamente? ¿Podría ser el nombre y la dirección? ¿Ciudad o país?
No hay mucho que intuir porque Item1 y Item2 son tan explicativos como "a" o "b".
Con C# 7.0 vamos a tener acceso a Tuplas reales de una manera más cercana a lenguajes funcionales como F#. La firma de método LoadPerson() se refactorizaría así:
public (string firstName, string lastName) LoadPerson(){};
Observa la nueva sintaxis del tipo de retorno. El tipo de retorno Tuple actúa de forma similar al patrón utilizado para declarar los parámetros de una función. Por último, si deseas crear una Tuple en línea, se puede hacer mediante el uso de la nueva palabra clave.
return new (string firstName, string lastName) {firstName = "Kevin", lastName = "Griffin"};
Separador de dígitos
Archiva de esta característica como "útil pero algo loco". ¿Cuántas veces has creado un literal numérico y tuvo que contar el número de dígitos para asegurarse de que introdujo el número correcto?
Por ejemplo:
long Gigabyte = 1048576;El número se ve aparentemente inofensivo, pero si se te olvida poner un dígito estarías en problemas. Normalmente, si alguien escribiera este número a mano, sería representado como 1,048,576. Las comas ayudarían a dictar la posición de los dígitos.
Los nuevos "separadores de dígitos" de C #7.0 te permiten hacer lo mismo, excepto que, en lugar de usar una coma, puedes usar el underscore.
long Gigabyte = 1_048_576;El compilador ignorará los underscore en tiempo de construcción.
Throw Exceptions
Escribir código defensivo a menudo significa generar un montón de excepciones. En C# 7.0, hay algunos nuevos ajustes en donde puedes lanzar una excepción.
Por ejemplo, considera este método existente:
Public string GetName (persona persona)
{
if (person.Name == null)
throw new Exception("Name not found");
return person.Name;
}
Con los nuevos cambios que dijimos, ese método puede ser rápidamente refactorizado en:
public string GetName(Person person)
{
return person.Name ?? throw new Exception("Name not found.");
}
Non-Nullable Reference Types (Tipos no nulos)
Una de las excepciones más comunes lanzadas en las aplicaciones .NET es la Null Reference. ¿Cuál es el problema? Los tipos de referencia en C# son nullables por defecto. Esta condición previa causa que los desarrolladores aseguren su código a prueba de balas para evitar que se esté tratando de acceder a una variable que potencialmente podría ser null en tiempo de ejecución.
Para tipos de valores, como int o DateTime, no es posible que el valor sea nulo a menos que las definas como un tipo Nullable.
int? intCouldBeNull; DateTime? nullableDateTime;¿Qué pasa si los diseñadores de C# simplemente cambian los valores predeterminados? Todos los tipos de referencia ya no serían null por defecto, entonces tendrías que setear explícitamente una variable que pueda ser null.
Ok...pero romperías 15 años de código C#.
Como alternativa, ¿qué pasaría si pudiéramos declarar explícitamente que un tipo de valor sea "no null?" En C# 7.0, el operador "!" se usará para indicar que una variable no puede ser null.
string! nonNullableString; Person! nonNullablePerson;Utilizando el operador "!", le estamos diciendo a C# que nonNullableString y nonNullablePerson, por lo tanto, NUNCA deben ser null. En el caso de que se pase un valor null, esto debería causar un error o una advertencia del compilador.
Fundación estable, carrera estable
Si eres nuevo en la industria o un profesional experimentado, tienes la gran oportunidad de decidirte por alinearte con diferentes tecnologías que vayan contigo. C# ha mostrado a través del tiempo para ser no sólo una plataforma estable, sino un lenguaje que ha madurado y crecido a lo largo de los años para adaptarse a las cambiantes necesidades de los desarrolladores.La última versión, C# 7.0, se encuentra en revisión. Se jacta de un conjunto de nuevas características diseñadas para hacer el código más fácil de leer y escribir.
StackOverflow, el recurso más confiable para desarrolladores de Internet en la actualidad, nos dice que C# es una de las cinco plataformas tecnológicas más importantes del mundo. Además, si miramos la encuesta de las tecnologías que los desarrolladores les encanta usar, sólo C# está en ambas listas. Ni siquiera con Java, que también se le considera uno de los mejores lenguajes de la industria, se puede decir que les encanta a los desarrolladores. Finalmente como guinda de la torta, un desarrollador que se especializa en C# puede, en promedio, ganar entre 85 a 95 mil dólares al año.
C# es una triple amenaza: es amado, es demandado y se paga bien.
Las aplicaciones de clase mundial necesitan entornos de desarrollo de clase mundial. Durante más de 15 años, Visual Studio ha sido el Cadillac de los IDE. Con características como Intellisense, un sorprendente depurador y un rico ecosistema de add-ons, Visual Studio continúa impulsando el concepto de lo que un IDE debería ser.
Los desarrolladores que no necesitan todo el poder de Visual Studio, o quieren una experiencia similar en OSX o Linux, pueden usar Visual Studio Code. Es de código abierto y multiplataforma. Te ofrece una increíble experiencia de codificación en un pequeño paquete. Si ya tienes un editor y no te convence cambiarte, entonces puedes usar el complemento Omnisharp que te permite usar la experiencia Intellisense de C# en casi cualquier otro editor.
¿Es una buena decisión usar C#? La evidencia anterior habla maravillas sobre la viabilidad a largo plazo del lenguaje, el gran ecosistema de herramientas de desarrollo y los diversos nichos donde pueden aplicarse tus conocimientos. No importa si estas orientado a desarrollo de escritorio, web, móvil, C# es una apuesta segura para los próximos años.
martes, 4 de julio de 2017
5 errores clásicos en un archivo web.config de .Net
Hola a todos. Me pareció interesante este post que leí en Internet, no está de más recordar cosas básicas. Vamos directo al grano :)
Configuración Vulnerable:
<configuration>
<system.web>
<customErrors mode="Off">
Así se ve, todo el detalle:
Configuración Segura:
<configuration>
<system.web>
<customErrors mode="RemoteOnly">
Así se vería ahora, mucho más seguro a cara del usuario:
Si no lo dejas así se verá la versión específica del Framework, el tipo de excepción por ejemplo si dice SqlException no sería muy lindo ya que se vería la versión del SQL, versión de IIS u otros detalles.
Algunos usan mode="On" y usan una página específica de errores con el atributo "defaultRedirect", ambas son válidas opciones, como se ve abajo:
<customErrors mode="On" defaultRedirect="ErrorGenerico.aspx"/>
<customErrors mode="RemoteOnly" defaultRedirect="ErrorGenerico.aspx"/>
Configuración Vulnerable
<configuration>
<system.web>
<trace enabled="true" localOnly="false">
Configuración Segura:
<configuration>
<system.web>
<trace enabled="false" localOnly="true">
Cuando está activo <trace> pero para usuarios remotos (localOnly="false") cualquier usuario puede ver el detalle de los request recientes simplemente ejecutando la página "trace.axd": http://mistio.com/trace.axd
Si está así es una verdadera mina de oro para un atacante. Se verán cookies, tiempos de ejecución, estado de la sesión, headers de los request, variables QuerySrings, etc.
Si quieres depurar un error, lo habilitas, pero sólo para verlo desde el mismo servidor (entrando al servidor):
<trace enabled="true" localOnly="true">
Configuración Vulnerable:
<configuration>
<system.web>
<compilation debug="true">
Configuración Segura:
<configuration>
<system.web>
<compilation debug="false">
Al activar muestra información muy peligrosa a un Usuario atacante como por ejemplo la línea con error, el stack trace y una parte del código fuente incluso.
Configuración Vulnerable:
<configuration>
<system.web>
<httpCookies httpOnlyCookies="false">
Configuración Segura:
<configuration>
<system.web>
<httpCookies httpOnlyCookies="true">
Con esto las cookies creadas en el servidor se pueden leer desde allí y no con scripts del cliente con JavaScript o VBScript. Si por código está activada "httpOnlyCookies = false", pero el Web.Config está en True, este último manda y tendrás el sitio seguro.
Configuración Vulnerable:
<configuration>
<system.web>
<sessionState cookieless="UseUri">
Configuración Segura:
<configuration>
<system.web>
<sessionState cookieless="UseCookies">
El estado de la session se puede manejar por URL y no por Cookie, por ejemplo si la URL cambia de http://myserver/MyApplication/default.aspx a http://myserver/MyApplication/(123456789ABCDEFG)/default.aspx. En este caso "123456789ABCDEFG" representa el token actual de sesión. Una diferente navegación al sitio genera una totalmente diferente token de sesión mostrando la url por ejemplo as http://myserver/MyApplication/(ZYXWVU987654321)/default.aspx.
Esto es práctico pero inseguro ya que con Fiddler o un sniffer se puede rastrear esa parte de la URL y un atacante habilidoso podría hacer mal uso del token.
La más eficiente forma para proteger de un sniffer es usar "UseCookies" o sencillamente setear "false". Pero no por URI. Ahora si usas "UseCookies" es obvio que dependes que el usuario tenga permitido el uso de cookies en su navegador.
¿Qué hacer con los que no permiten el uso de cookies en su navegador? En ese caso, desde el ASP.NET 2.0. se puede poner el atributo "cookieless" en "AutoDetect", por lo que la aplicación guardará el estado de la session en la Cookie solo si está activado en el navegador. Si no lo está, lo dejará en la URI. Ahora, entre los ataques más fáciles de realizar para un atacante, el de la URL es más vulnerable, por lo tanto, recomiendo usar "UseCookies".
Post original: https://dotnetstories.wordpress.com/2007/10/13/the-worst-5-mistakes-in-the-webconfig-file/
1. Custom Errors en Off
Cuando desactivas los custom errors como se ve abajo, ASP.NET mostrará en pantalla los errores detallados a aquellos usuarios que vean la página que muestra dicho error.Configuración Vulnerable:
<configuration>
<system.web>
<customErrors mode="Off">
Así se ve, todo el detalle:
Configuración Segura:
<configuration>
<system.web>
<customErrors mode="RemoteOnly">
Así se vería ahora, mucho más seguro a cara del usuario:
Si no lo dejas así se verá la versión específica del Framework, el tipo de excepción por ejemplo si dice SqlException no sería muy lindo ya que se vería la versión del SQL, versión de IIS u otros detalles.
Algunos usan mode="On" y usan una página específica de errores con el atributo "defaultRedirect", ambas son válidas opciones, como se ve abajo:
<customErrors mode="On" defaultRedirect="ErrorGenerico.aspx"/>
<customErrors mode="RemoteOnly" defaultRedirect="ErrorGenerico.aspx"/>
2. Dejar activo el Tracing para aplicaciones Web
La característica de trace es muy útil para depurar un error, pero si es vista por un usuario que quiere atacar a tu sitio Web sería desastroso.Configuración Vulnerable
<configuration>
<system.web>
<trace enabled="true" localOnly="false">
Configuración Segura:
<configuration>
<system.web>
<trace enabled="false" localOnly="true">
Cuando está activo <trace> pero para usuarios remotos (localOnly="false") cualquier usuario puede ver el detalle de los request recientes simplemente ejecutando la página "trace.axd": http://mistio.com/trace.axd
Si está así es una verdadera mina de oro para un atacante. Se verán cookies, tiempos de ejecución, estado de la sesión, headers de los request, variables QuerySrings, etc.
Si quieres depurar un error, lo habilitas, pero sólo para verlo desde el mismo servidor (entrando al servidor):
<trace enabled="true" localOnly="true">
3. Dejar activado Debug
Se debe trabajar en etapa de desarrollo como deploy en True, pero luego desactivar. Ojo que Visual Studio 2005 lo activa por defecto cuando le das F5 y luego en el Deploy, es muy común copiar ese mismo Web.Config a producción olvidando quitar el "debug=true".Configuración Vulnerable:
<configuration>
<system.web>
<compilation debug="true">
Configuración Segura:
<configuration>
<system.web>
<compilation debug="false">
Al activar muestra información muy peligrosa a un Usuario atacante como por ejemplo la línea con error, el stack trace y una parte del código fuente incluso.
4. Cookies accesibles por el lado del cliente
En Internet Explorer 6.0, Microsoft introdujo una nueva propiedad llamada "HttpOnly". Esta opción permite crear un cookie pero ella sólo será posible leerla o verla desde el servidor y no por el cliente con JavaScript por ejemplo. Se puede setear cookie a cookie por código pero lo mejor es setear todo el sitio con Cookie seguras:Configuración Vulnerable:
<configuration>
<system.web>
<httpCookies httpOnlyCookies="false">
Configuración Segura:
<configuration>
<system.web>
<httpCookies httpOnlyCookies="true">
Con esto las cookies creadas en el servidor se pueden leer desde allí y no con scripts del cliente con JavaScript o VBScript. Si por código está activada "httpOnlyCookies = false", pero el Web.Config está en True, este último manda y tendrás el sitio seguro.
5. Dejar el Session State por URI y no por Cookies
En la versión 1.0 de ASP.NET, no había forma de decidir como transmitir el token de session entre request cuando la aplicación necesita mantener el estado de la sesión, este siempre se almacenaba en una cookie. Los usuarios que no aceptaban el uso de cookie no podía usar la aplicación, así que en ASP.NET 1.1, Microsoft agregó soporte para un token de sesión en base a la URI. Esto a la vez, es más inseguro ya que se ve en pantalla el token:Configuración Vulnerable:
<configuration>
<system.web>
<sessionState cookieless="UseUri">
Configuración Segura:
<configuration>
<system.web>
<sessionState cookieless="UseCookies">
El estado de la session se puede manejar por URL y no por Cookie, por ejemplo si la URL cambia de http://myserver/MyApplication/default.aspx a http://myserver/MyApplication/(123456789ABCDEFG)/default.aspx. En este caso "123456789ABCDEFG" representa el token actual de sesión. Una diferente navegación al sitio genera una totalmente diferente token de sesión mostrando la url por ejemplo as http://myserver/MyApplication/(ZYXWVU987654321)/default.aspx.
Esto es práctico pero inseguro ya que con Fiddler o un sniffer se puede rastrear esa parte de la URL y un atacante habilidoso podría hacer mal uso del token.
La más eficiente forma para proteger de un sniffer es usar "UseCookies" o sencillamente setear "false". Pero no por URI. Ahora si usas "UseCookies" es obvio que dependes que el usuario tenga permitido el uso de cookies en su navegador.
¿Qué hacer con los que no permiten el uso de cookies en su navegador? En ese caso, desde el ASP.NET 2.0. se puede poner el atributo "cookieless" en "AutoDetect", por lo que la aplicación guardará el estado de la session en la Cookie solo si está activado en el navegador. Si no lo está, lo dejará en la URI. Ahora, entre los ataques más fáciles de realizar para un atacante, el de la URL es más vulnerable, por lo tanto, recomiendo usar "UseCookies".
Post original: https://dotnetstories.wordpress.com/2007/10/13/the-worst-5-mistakes-in-the-webconfig-file/
martes, 6 de junio de 2017
El Mítico Hombre-Mes (The Mythical Man-Month) capítulo 4 en español
¡Hola! Ya que muchos me han pedido seguir con la traducción del libro The Mythical Man-Month: Essays on Software Engineering, me he dado el tiempo y he avanzado con la traducción del Capítulo 4. Sin más blah-blah, aquí les va.
NOTA: En este capítulo se habla mucho de implementador, considérenlo en la actualidad como el rol de un desarrollador (.Net, Java, Mobile, PHP, u otro).
The Mythical Man-Month : Essays on Software Engineering.
Esta gran iglesia es una obra de arte incomparable. No existe confusión ni ambigüedad en los principios que establece.
Es el cenit de un estilo, el trabajo de artistas que entendieron y asimilaron todos los éxitos de sus predecesores, en plena posesión de las técnicas de su tiempo, pero fueron usados sin exhibición indiscreta ni hazañas gratuitas de habilidad.
Jean d'Orbais fue sin duda quien concibió el plan general del edificio, un plan que fue respetado, al menos en sus elementos esenciales, por sus sucesores. Esto es una de las razones de la extrema coherencia y unidad que posee la estructura.
Guía de la Catedral de Reims
Fotografía de Emmanuel Boudot-Lamotte
Frente a éstos, la unidad arquitectónica de Reims se encuentra en el glorioso contraste. La alegría que despierta al espectador proviene tanto de la integridad del diseño como de cualquier otra excelencia en particular. Como dice la guía, esta integridad se logró con la abnegación de ocho generaciones de constructores, cada uno de los cuales sacrificó algunas de sus ideas para que el conjunto pudiera tener un único diseño. El resultado proclama no sólo la gloria de Dios, sino también SU poder para salvar a los hombres orgullosos.
Ahora si hablamos de los sistemas de programación, a pesar de que no han tardado siglos en construirse, reflejan una desunión conceptual mucho peor que la de las catedrales. Por lo general, esto no surge de una sucesión en serie de diseñadores maestros con "diferente mano", sino de la separación del diseño con las muchas tareas hechas por muchos hombres diferentes.
Afirmaré que la integridad conceptual es la consideración más importante en el diseño de sistemas. Es mejor que un sistema omita ciertas características y mejoras anómalas, con tal que refleje un conjunto de ideas de diseño, a tener una que contenga muchas ideas buenas pero independientes y no coordinadas.
En este capítulo y en los dos siguientes, examinaremos las consecuencias de este tema en la programación de un diseño de sistema:
Pero estos servicios tienen un precio: las descripciones externas de un sistema de programación es de diez a veinte veces mayor que la descripción externa de ese mismo sistema de computación. El usuario encuentra muy fácil especificar alguna nueva función en particular, pero hay mucho más para elegir, y muchas más opciones y formatos que se deben recordar.
La facilidad de uso se mejora sólo si el tiempo ganado en la especificación funcional es mayor al tiempo perdido en el aprendizaje, en el recordar algo y el uso de manuales. Con los sistemas de programación modernos esta ganancia supera el costo de que el usuario aprenda más, pero en los últimos años parece haber disminuido la proporción entre la ganancia y el costo de aprender por parte del usuario (Nota del traductor: esto hay que verlo desde el punto de vista del año en que se publicó el libro, 1975, ahora sabemos que existen las aplicaciones minimalistas como Google, Facebook o Apps Mobile, donde todo es más simple para el usuario) a medida que se agregan funciones cada vez más complejas. Por ejemplo, me asombra la facilidad de uso de la IBM 650, incluso dejando afuera ensamblador u otro software que posea.
Debido a que la facilidad de uso es el propósito, esta relación entre la función y la complejidad conceptual es la última prueba del diseño del sistema. Ni la función o simplicidad por sí solas, definen un buen diseño.
Este punto es ampliamente mal entendido. El SO/360 es aclamado por sus constructores como el mejor jamás construido, porque indiscutiblemente tiene muchas funciones. La función y no la simplicidad, ha sido la unidad de medida por excelencia de sus creadores. Por otro lado, el Sistema de Compartición del Tiempo del PDP-10 es aclamado por sus creadores como el más fino, debido a su simplicidad y la escasez de sus conceptos. Sin embargo, en cualquier caso, su función no está ni siquiera al nivel de la de OS/360. Si hablamos que la facilidad de uso sea el criterio, cada uno de ellos se ve desequilibrado, alcanzando sólo la mitad de la meta real.
Para un nivel dado de función, sin embargo, ese sistema es el mejor en el cual uno puede especificar las cosas con la mayor sencillez y facilidad que se puede. En todo caso, la simplicidad no es suficiente. El lenguaje TRAC de Mooers y Algol 68 alcanza una sencillez dada por conceptos distintos. Sin embargo, no son sencillos de manejar. La expresión de las cosas que uno quiere hacer a menudo requiere combinaciones no evolucionadas e inesperadas de una función base. No basta con aprender los elementos y las reglas de la combinación, uno debe también aprender el uso idiomático, toda una sabiduría de cómo los elementos se combinan en la práctica. La simplicidad y la franqueza proceden de la integridad conceptual. Cada parte debe reflejar las mismas filosofías y el mismo equilibrio de desiderata. Cada parte debe incluso utilizar las mismas técnicas en sintaxis y nociones de la semántica. La facilidad de uso, entonces, dicta una unidad de diseño, dicta la integridad conceptual.
En el mundo de la programación, sin embargo, dice que la construcción del sistema necesita muchas manos. Hay dos técnicas disponibles para resolver este dilema. La primera es una cuidadosa división del trabajo entre arquitectura e implementación. La segunda es la nueva forma de estructurar los equipos de implementación de programación discutidos en el capítulo anterior. La separación entre el esfuerzo arquitectónico y la implementación es una forma muy poderosa de conseguir integridad conceptual en proyectos muy grandes. Yo mismo he visto que se usó con gran éxito en la computadora Stretch de IBM y en la línea de productos de computadoras System/360. Pero la he visto fallar con las aplicaciones del SO/360.
Por la arquitectura de un sistema, me refiero a la especificación completa y detallada de la interfaz de usuario. Para una computadora este es el manual de programación. Para un compilador es el manual del lenguaje. Para un programa de control son los manuales para el idioma o lenguajes usados para invocar sus funciones. Para todo el sistema es la unión de los manuales que el usuario debe consultar para hacer todo su trabajo. El arquitecto de un sistema, como el arquitecto de un edificio, es el agente del usuario. Su trabajo consiste en llevar el conocimiento profesional y técnico al más puro interés del usuario, en contraposición a los intereses del vendedor, del fabricante, etc. La arquitectura debe ser cuidadosamente diferenciada de la implementación.
Como Gerrit Blaauw dijo: "la arquitectura dice lo que sucede, la implementación dice cómo se hace que suceda". Él da como ejemplo simple un reloj, cuya arquitectura consiste en la cara, la correa y la perilla. Cuando un niño ha aprendido esta arquitectura, puede decir el tiempo tan fácilmente de un reloj de pulsera como de una torre de iglesia. La implementación, sin embargo y su realización, describen lo que sucede en el interior de los muchos mecanismos y controles que el reloj tiene.
En un computador System/360, por ejemplo, una arquitectura de computadora única se implementa de manera muy diferente en cada uno de los nueve modelos. Por el contrario, una única implementación, el flujo de datos del Modelo 30, la memoria y el microcódigo, sirve en diferentes momentos para cuatro arquitecturas diferentes: un System/360, un canal multiplex con hasta 224 subcanales lógicamente independientes, un canal selector y un ordenador 1401.
La misma distinción es igualmente aplicable a los sistemas de programación. Existió un estándar estadounidense para el Fortran IV. Era una arquitectura para muchos compiladores. Dentro de esta arquitectura era posibles muchas implementaciones como text-in-core o compiler-in-core, fast-compile, compilación rápida u optimización, sintaxis directa o ad-hoc. Del mismo modo cualquier lenguaje ensamblador o lenguaje de control admitía muchas implementaciones del ensamblador o scheduler.
Ahora podemos hablar de la cuestión profundamente emocional que es la aristocracia versus la democracia. ¿No son los arquitectos una nueva aristocracia, una élite intelectual, preparada para decir a los pobres ejecutores mudos qué deben hacer?, ¿no ha sido todo el trabajo creativo secuestrado para esta élite, dejando a los implementadores sólo como engranajes en la maquinaria?, ¿no se conseguirá un mejor producto obteniendo las buenas ideas de todo el equipo, siguiendo una filosofía democrática, en lugar de restringir el desarrollo de especificaciones a unos pocos?
En cuanto a la última pregunta, que es la más fácil. Ciertamente no afirmaré que sólo los arquitectos tendrán buenas ideas arquitectónicas. A menudo una idea fresca proviene de un implementador o de un usuario. Sin embargo, estoy convencido según mi experiencia y también lo he intentado demostrar, que la integridad conceptual de un sistema determina su facilidad de uso.
Las características o ideas que no se integren con los conceptos básicos de un sistema es mejor dejarlas de lado. Si aparecen varias ideas importantes pero incompatibles, se desecha todo el sistema y se empieza de nuevo en un sistema integrado, pero con diferentes conceptos básicos.
En cuanto a la carga aristocrática, la respuesta debe ser sí y no.
Sí, en el sentido de que debe haber pocos arquitectos, su producto debe durar más tiempo que el de un ejecutor, y el arquitecto se encuentra en el centro de las fuerzas que debe resolver en última instancia en interés del usuario. Si un sistema debe tener integridad conceptual, alguien debe controlar los conceptos. Es una aristocracia que no necesita disculpas.
No, porque la creación de especificaciones externas no es un trabajo más creativo que el diseñar las implementaciones. Es sólo un trabajo creativo diferente. El diseño de una implementación, dada una arquitectura, requiere y permite tanto la creatividad de diseño, como de ideas nuevas y de brillantez técnica, tanto como el diseño de las especificaciones externas. De hecho, la relación costo-rendimiento del producto dependerá en gran medida del implementador, así como la facilidad de uso depende en gran medida del arquitecto.
Hay muchos ejemplos en otras artes y oficios que indican que la disciplina es buena para el arte. De hecho, el aforismo de un artista afirma: "la forma es liberadora". Los edificios peores son aquellos cuyo presupuesto era demasiado grande para los propósitos que se usarán.
La producción creativa de Bach apenas parece haber sido sofocada por la necesidad de producir una cantata de forma limitada cada semana. Estoy seguro de que la computadora Stretch habría tenido una mejor arquitectura si hubiera sido más restringida; las restricciones impuestas por el presupuesto del System/360 Modelo 30 eran en mi opinión totalmente beneficiosas para la arquitectura del Modelo 75.
Del mismo modo, observo que si la arquitectura la entrega un proveedor externo, esta mejora sin obstáculos el estilo creativo del grupo de implementación. Se centran de inmediato en la parte del problema que nadie ha tratado y las invenciones comienzan a fluir. En un grupo de implementación sin restricciones, la mayor parte del pensamiento y el debate van hacia las decisiones arquitectónicas y la implementación correcta se hace corta.
Este efecto, que he visto muchas veces, es confirmado por R. W. Conway, cuyo grupo en Cornell construyó el compilador PL/C para el lenguaje PL/I. Él dijo: "finalmente decidimos implementar el lenguaje sin cambios y sin mejoras, porque los debates sobre el lenguaje habrían tomado todo nuestro esfuerzo".
A esto el director de arquitectura dijo que si yo le daba toda la responsabilidad al equipo de implementación, el resultado no sería de hecho a tiempo, sino que también estaría tres meses atrasado y de calidad mucho menor. Lo hice, y así fue. Tenía razón en ambos aspectos.
Además, la falta de integridad conceptual hizo que el sistema fuera mucho más costoso de construir y cambiar, y yo estimaría un año más al tiempo de depuración.
Muchos factores, por supuesto, entraron en esa decisión equivocada, pero era abrumador el tiempo de no hacer nada con los 150 hombres.
Cuando se propone que un pequeño equipo de arquitectura escriba todas las especificaciones externas para una computadora o un sistema de programación, los implementadores plantean tres objeciones:
Como señala Blaauw, el esfuerzo creativo total implica tres fases distintas: arquitectura, implementación y realización. Resulta que estos pueden de hecho ser comenzados en paralelo y proceder simultáneamente.
En el diseño de computadoras, por ejemplo, el implementador puede comenzar tan pronto como tenga suposiciones relativamente vagas acerca del manual, ideas algo claras sobre la tecnología y objetivos bien definidos de costo y desempeño. Puede comenzar a diseñar flujos de datos, secuencias de control, conceptos de deploy, etc. El implementador diseña o adapta las herramientas que necesitará, especialmente el sistema de mantenimiento de registros o sistema de automatización.
Mientras tanto, en el nivel de realización (N. del T: en el caso de un nuevo sistema IBM): los circuitos, tarjetas, cables, marcos, fuentes de alimentación y memorias deben ser diseñadas, refinadas y documentadas. Este trabajo se desarrolla en paralelo con la arquitectura y la implementación.
Lo mismo ocurre en la programación del sistema. Mucho antes de que las especificaciones externas estén completas, el implementador tiene mucho que hacer. Con algunas aproximaciones en cuanto a la función del sistema que se incorporará finalmente en las especificaciones, él puede proceder. Debe tener objetivos bien definidos de espacio y tiempo. Debe conocer la configuración del sistema en la que debe funcionar su producto. Luego puede comenzar a diseñar límites de módulos, estructuras de tablas, desgloses de paso o fase, algoritmos y todo tipo de herramientas. Igualmente, a veces debe comunicarse con el arquitecto.
Mientras tanto, a nivel de realización hay mucho que hacer también. La programación también tiene una tecnología. Si la máquina es nueva, se debe hacer mucho trabajo en convenciones de subrutinas, técnicas de supervisión, algoritmos de búsqueda y clasificación.
La integridad conceptual requiere que un sistema refleje una sola filosofía y que la especificación vista por el usuario fluya de unas pocas mentes. Sin embargo, debido a la división real del trabajo en arquitectura, implementación y realización, esto no implica que un sistema lleve más tiempo construir. La experiencia demuestra lo contrario, que el sistema integral va más rápido y toma menos tiempo para probar. En efecto, una amplia división horizontal del trabajo se ha reducido drásticamente al usar una división vertical del trabajo y el resultado es una comunicación radicalmente simplificada y una mejor integridad conceptual.
NOTA: En este capítulo se habla mucho de implementador, considérenlo en la actualidad como el rol de un desarrollador (.Net, Java, Mobile, PHP, u otro).
The Mythical Man-Month : Essays on Software Engineering.
Capítulo 4: Aristocracia, Democracia y Diseño de Sistemas
Es el cenit de un estilo, el trabajo de artistas que entendieron y asimilaron todos los éxitos de sus predecesores, en plena posesión de las técnicas de su tiempo, pero fueron usados sin exhibición indiscreta ni hazañas gratuitas de habilidad.
Jean d'Orbais fue sin duda quien concibió el plan general del edificio, un plan que fue respetado, al menos en sus elementos esenciales, por sus sucesores. Esto es una de las razones de la extrema coherencia y unidad que posee la estructura.
Guía de la Catedral de Reims
Fotografía de Emmanuel Boudot-Lamotte
Integridad conceptual
La mayoría de las catedrales europeas muestran diferencias en el plan o el estilo arquitectónico si hablamos de piezas construidas en diferentes generaciones por diferentes constructores. Los constructores posteriores fueron tentados a "mejorar" los diseños de los primeros, para reflejar tanto los cambios en la moda como las diferencias en su gusto individual. Así, la pacífica arquitectura normanda contradice al estilo gótico, y el resultado proclama tanto la soberbia de los constructores como la gloria de Dios.Frente a éstos, la unidad arquitectónica de Reims se encuentra en el glorioso contraste. La alegría que despierta al espectador proviene tanto de la integridad del diseño como de cualquier otra excelencia en particular. Como dice la guía, esta integridad se logró con la abnegación de ocho generaciones de constructores, cada uno de los cuales sacrificó algunas de sus ideas para que el conjunto pudiera tener un único diseño. El resultado proclama no sólo la gloria de Dios, sino también SU poder para salvar a los hombres orgullosos.
Ahora si hablamos de los sistemas de programación, a pesar de que no han tardado siglos en construirse, reflejan una desunión conceptual mucho peor que la de las catedrales. Por lo general, esto no surge de una sucesión en serie de diseñadores maestros con "diferente mano", sino de la separación del diseño con las muchas tareas hechas por muchos hombres diferentes.
Afirmaré que la integridad conceptual es la consideración más importante en el diseño de sistemas. Es mejor que un sistema omita ciertas características y mejoras anómalas, con tal que refleje un conjunto de ideas de diseño, a tener una que contenga muchas ideas buenas pero independientes y no coordinadas.
En este capítulo y en los dos siguientes, examinaremos las consecuencias de este tema en la programación de un diseño de sistema:
- ¿Cómo se puede lograr la integridad conceptual?
- ¿No implica esto tener una élite o aristocracia de arquitectos y por otro lado una horda de ejecutores plebeyos cuyos talentos creativos e ideas son suprimidas?
- ¿Cómo se mantiene a los arquitectos a la deriva en el mar de especificaciones imposibles de implementar o que son muy costosas?
- ¿Cómo se asegura que cada detalle insignificante de una especificación de arquitectura se comunique al ejecutor, correctamente entendido por este, y que se incorpore con precisión en el producto final?
Lograr la integridad conceptual
El propósito final de un sistema de programación es hacer que una computadora sea fácil de usar (para el punto de vista del usuario). Para ello, proporciona lenguajes y diversos servicios que en realidad son programas invocados y controlados por características del lenguaje.Pero estos servicios tienen un precio: las descripciones externas de un sistema de programación es de diez a veinte veces mayor que la descripción externa de ese mismo sistema de computación. El usuario encuentra muy fácil especificar alguna nueva función en particular, pero hay mucho más para elegir, y muchas más opciones y formatos que se deben recordar.
La facilidad de uso se mejora sólo si el tiempo ganado en la especificación funcional es mayor al tiempo perdido en el aprendizaje, en el recordar algo y el uso de manuales. Con los sistemas de programación modernos esta ganancia supera el costo de que el usuario aprenda más, pero en los últimos años parece haber disminuido la proporción entre la ganancia y el costo de aprender por parte del usuario (Nota del traductor: esto hay que verlo desde el punto de vista del año en que se publicó el libro, 1975, ahora sabemos que existen las aplicaciones minimalistas como Google, Facebook o Apps Mobile, donde todo es más simple para el usuario) a medida que se agregan funciones cada vez más complejas. Por ejemplo, me asombra la facilidad de uso de la IBM 650, incluso dejando afuera ensamblador u otro software que posea.
Debido a que la facilidad de uso es el propósito, esta relación entre la función y la complejidad conceptual es la última prueba del diseño del sistema. Ni la función o simplicidad por sí solas, definen un buen diseño.
Este punto es ampliamente mal entendido. El SO/360 es aclamado por sus constructores como el mejor jamás construido, porque indiscutiblemente tiene muchas funciones. La función y no la simplicidad, ha sido la unidad de medida por excelencia de sus creadores. Por otro lado, el Sistema de Compartición del Tiempo del PDP-10 es aclamado por sus creadores como el más fino, debido a su simplicidad y la escasez de sus conceptos. Sin embargo, en cualquier caso, su función no está ni siquiera al nivel de la de OS/360. Si hablamos que la facilidad de uso sea el criterio, cada uno de ellos se ve desequilibrado, alcanzando sólo la mitad de la meta real.
Para un nivel dado de función, sin embargo, ese sistema es el mejor en el cual uno puede especificar las cosas con la mayor sencillez y facilidad que se puede. En todo caso, la simplicidad no es suficiente. El lenguaje TRAC de Mooers y Algol 68 alcanza una sencillez dada por conceptos distintos. Sin embargo, no son sencillos de manejar. La expresión de las cosas que uno quiere hacer a menudo requiere combinaciones no evolucionadas e inesperadas de una función base. No basta con aprender los elementos y las reglas de la combinación, uno debe también aprender el uso idiomático, toda una sabiduría de cómo los elementos se combinan en la práctica. La simplicidad y la franqueza proceden de la integridad conceptual. Cada parte debe reflejar las mismas filosofías y el mismo equilibrio de desiderata. Cada parte debe incluso utilizar las mismas técnicas en sintaxis y nociones de la semántica. La facilidad de uso, entonces, dicta una unidad de diseño, dicta la integridad conceptual.
Aristocracia y democracia
La integridad conceptual a su vez dice que el diseño debe proceder de una mente, o de un número muy pequeño de mentes concordantes.En el mundo de la programación, sin embargo, dice que la construcción del sistema necesita muchas manos. Hay dos técnicas disponibles para resolver este dilema. La primera es una cuidadosa división del trabajo entre arquitectura e implementación. La segunda es la nueva forma de estructurar los equipos de implementación de programación discutidos en el capítulo anterior. La separación entre el esfuerzo arquitectónico y la implementación es una forma muy poderosa de conseguir integridad conceptual en proyectos muy grandes. Yo mismo he visto que se usó con gran éxito en la computadora Stretch de IBM y en la línea de productos de computadoras System/360. Pero la he visto fallar con las aplicaciones del SO/360.
Por la arquitectura de un sistema, me refiero a la especificación completa y detallada de la interfaz de usuario. Para una computadora este es el manual de programación. Para un compilador es el manual del lenguaje. Para un programa de control son los manuales para el idioma o lenguajes usados para invocar sus funciones. Para todo el sistema es la unión de los manuales que el usuario debe consultar para hacer todo su trabajo. El arquitecto de un sistema, como el arquitecto de un edificio, es el agente del usuario. Su trabajo consiste en llevar el conocimiento profesional y técnico al más puro interés del usuario, en contraposición a los intereses del vendedor, del fabricante, etc. La arquitectura debe ser cuidadosamente diferenciada de la implementación.
Como Gerrit Blaauw dijo: "la arquitectura dice lo que sucede, la implementación dice cómo se hace que suceda". Él da como ejemplo simple un reloj, cuya arquitectura consiste en la cara, la correa y la perilla. Cuando un niño ha aprendido esta arquitectura, puede decir el tiempo tan fácilmente de un reloj de pulsera como de una torre de iglesia. La implementación, sin embargo y su realización, describen lo que sucede en el interior de los muchos mecanismos y controles que el reloj tiene.
En un computador System/360, por ejemplo, una arquitectura de computadora única se implementa de manera muy diferente en cada uno de los nueve modelos. Por el contrario, una única implementación, el flujo de datos del Modelo 30, la memoria y el microcódigo, sirve en diferentes momentos para cuatro arquitecturas diferentes: un System/360, un canal multiplex con hasta 224 subcanales lógicamente independientes, un canal selector y un ordenador 1401.
La misma distinción es igualmente aplicable a los sistemas de programación. Existió un estándar estadounidense para el Fortran IV. Era una arquitectura para muchos compiladores. Dentro de esta arquitectura era posibles muchas implementaciones como text-in-core o compiler-in-core, fast-compile, compilación rápida u optimización, sintaxis directa o ad-hoc. Del mismo modo cualquier lenguaje ensamblador o lenguaje de control admitía muchas implementaciones del ensamblador o scheduler.
Ahora podemos hablar de la cuestión profundamente emocional que es la aristocracia versus la democracia. ¿No son los arquitectos una nueva aristocracia, una élite intelectual, preparada para decir a los pobres ejecutores mudos qué deben hacer?, ¿no ha sido todo el trabajo creativo secuestrado para esta élite, dejando a los implementadores sólo como engranajes en la maquinaria?, ¿no se conseguirá un mejor producto obteniendo las buenas ideas de todo el equipo, siguiendo una filosofía democrática, en lugar de restringir el desarrollo de especificaciones a unos pocos?
En cuanto a la última pregunta, que es la más fácil. Ciertamente no afirmaré que sólo los arquitectos tendrán buenas ideas arquitectónicas. A menudo una idea fresca proviene de un implementador o de un usuario. Sin embargo, estoy convencido según mi experiencia y también lo he intentado demostrar, que la integridad conceptual de un sistema determina su facilidad de uso.
Las características o ideas que no se integren con los conceptos básicos de un sistema es mejor dejarlas de lado. Si aparecen varias ideas importantes pero incompatibles, se desecha todo el sistema y se empieza de nuevo en un sistema integrado, pero con diferentes conceptos básicos.
En cuanto a la carga aristocrática, la respuesta debe ser sí y no.
Sí, en el sentido de que debe haber pocos arquitectos, su producto debe durar más tiempo que el de un ejecutor, y el arquitecto se encuentra en el centro de las fuerzas que debe resolver en última instancia en interés del usuario. Si un sistema debe tener integridad conceptual, alguien debe controlar los conceptos. Es una aristocracia que no necesita disculpas.
No, porque la creación de especificaciones externas no es un trabajo más creativo que el diseñar las implementaciones. Es sólo un trabajo creativo diferente. El diseño de una implementación, dada una arquitectura, requiere y permite tanto la creatividad de diseño, como de ideas nuevas y de brillantez técnica, tanto como el diseño de las especificaciones externas. De hecho, la relación costo-rendimiento del producto dependerá en gran medida del implementador, así como la facilidad de uso depende en gran medida del arquitecto.
Hay muchos ejemplos en otras artes y oficios que indican que la disciplina es buena para el arte. De hecho, el aforismo de un artista afirma: "la forma es liberadora". Los edificios peores son aquellos cuyo presupuesto era demasiado grande para los propósitos que se usarán.
La producción creativa de Bach apenas parece haber sido sofocada por la necesidad de producir una cantata de forma limitada cada semana. Estoy seguro de que la computadora Stretch habría tenido una mejor arquitectura si hubiera sido más restringida; las restricciones impuestas por el presupuesto del System/360 Modelo 30 eran en mi opinión totalmente beneficiosas para la arquitectura del Modelo 75.
Del mismo modo, observo que si la arquitectura la entrega un proveedor externo, esta mejora sin obstáculos el estilo creativo del grupo de implementación. Se centran de inmediato en la parte del problema que nadie ha tratado y las invenciones comienzan a fluir. En un grupo de implementación sin restricciones, la mayor parte del pensamiento y el debate van hacia las decisiones arquitectónicas y la implementación correcta se hace corta.
Este efecto, que he visto muchas veces, es confirmado por R. W. Conway, cuyo grupo en Cornell construyó el compilador PL/C para el lenguaje PL/I. Él dijo: "finalmente decidimos implementar el lenguaje sin cambios y sin mejoras, porque los debates sobre el lenguaje habrían tomado todo nuestro esfuerzo".
¿Qué hace el implementador mientras espera?
Es una experiencia muy humillante el cometer un error multimillonario, pero a la vez es memorable. Recuerdo claro la noche que decidimos cómo organizar la escritura real de especificaciones externas para el OS/360. El gerente de arquitectura, el gerente de implementación y yo estábamos debatiendo el plan, el cronograma y la división de responsabilidades. El director de arquitectura tenía 10 hombres buenos. Afirmó que podrían escribir las especificaciones y hacerlo bien. Tomaría diez meses, tres más que el tiempo comprometido. El gerente de implementación tenía 150 hombres. Afirmó que podría preparar las especificaciones, con la coordinación del equipo de arquitectura; sería bien hecho y de forma práctica, y él podría hacerlo en el los tiempos establecidos. Ahora, si el equipo de arquitectura lo hiciera como dijimos, sus 150 hombres estarían girando en sus asientos durante diez meses.A esto el director de arquitectura dijo que si yo le daba toda la responsabilidad al equipo de implementación, el resultado no sería de hecho a tiempo, sino que también estaría tres meses atrasado y de calidad mucho menor. Lo hice, y así fue. Tenía razón en ambos aspectos.
Además, la falta de integridad conceptual hizo que el sistema fuera mucho más costoso de construir y cambiar, y yo estimaría un año más al tiempo de depuración.
Muchos factores, por supuesto, entraron en esa decisión equivocada, pero era abrumador el tiempo de no hacer nada con los 150 hombres.
Cuando se propone que un pequeño equipo de arquitectura escriba todas las especificaciones externas para una computadora o un sistema de programación, los implementadores plantean tres objeciones:
- Las especificaciones serán demasiado ricas en función y no reflejarán consideraciones prácticas de costo.
- Los arquitectos tendrán toda la diversión creativa y excluirán la ideas de los ejecutores.
- Los implementadores tendrán que sentarse ociosamente a esperar que las especificaciones vengan desde un embudo estrecho que es el equipo de arquitectura.
Como señala Blaauw, el esfuerzo creativo total implica tres fases distintas: arquitectura, implementación y realización. Resulta que estos pueden de hecho ser comenzados en paralelo y proceder simultáneamente.
En el diseño de computadoras, por ejemplo, el implementador puede comenzar tan pronto como tenga suposiciones relativamente vagas acerca del manual, ideas algo claras sobre la tecnología y objetivos bien definidos de costo y desempeño. Puede comenzar a diseñar flujos de datos, secuencias de control, conceptos de deploy, etc. El implementador diseña o adapta las herramientas que necesitará, especialmente el sistema de mantenimiento de registros o sistema de automatización.
Mientras tanto, en el nivel de realización (N. del T: en el caso de un nuevo sistema IBM): los circuitos, tarjetas, cables, marcos, fuentes de alimentación y memorias deben ser diseñadas, refinadas y documentadas. Este trabajo se desarrolla en paralelo con la arquitectura y la implementación.
Lo mismo ocurre en la programación del sistema. Mucho antes de que las especificaciones externas estén completas, el implementador tiene mucho que hacer. Con algunas aproximaciones en cuanto a la función del sistema que se incorporará finalmente en las especificaciones, él puede proceder. Debe tener objetivos bien definidos de espacio y tiempo. Debe conocer la configuración del sistema en la que debe funcionar su producto. Luego puede comenzar a diseñar límites de módulos, estructuras de tablas, desgloses de paso o fase, algoritmos y todo tipo de herramientas. Igualmente, a veces debe comunicarse con el arquitecto.
Mientras tanto, a nivel de realización hay mucho que hacer también. La programación también tiene una tecnología. Si la máquina es nueva, se debe hacer mucho trabajo en convenciones de subrutinas, técnicas de supervisión, algoritmos de búsqueda y clasificación.
La integridad conceptual requiere que un sistema refleje una sola filosofía y que la especificación vista por el usuario fluya de unas pocas mentes. Sin embargo, debido a la división real del trabajo en arquitectura, implementación y realización, esto no implica que un sistema lleve más tiempo construir. La experiencia demuestra lo contrario, que el sistema integral va más rápido y toma menos tiempo para probar. En efecto, una amplia división horizontal del trabajo se ha reducido drásticamente al usar una división vertical del trabajo y el resultado es una comunicación radicalmente simplificada y una mejor integridad conceptual.
miércoles, 5 de abril de 2017
Diccionario Chileno WPA/WPA2 con más de 500 millones de combinaciones de palabras
Hola a todos, hoy les traigo algo distinto. Algo que no encontré en la WEB, así que lo creé yo mismo: un Diccionario WPA y WPA2 chileno, actualizado al 11/04/2017 con más de 540 millones de combinaciones (exactamente 543.056.781) de palabras con números y símbolos básicos. Descomprimido pesa más de 8 GB. Bajar aquí (aprox. 300 MB).
En mi equipo el programa estima que demorará 20 hrs en probar todo el diccionario. Esto depende de su CPU, RAM y calidad de su Tarjeta de Video.
Generador de diccionario (Binario)
DicGenerator.exe: bajar aquí.
Diccionario base "MiDic.dic" para usar con el programa DicGenerator.exe
El diccionario base en primera instancia lo encontré en este sitio y pesa apenas 4 MB. Lo mejoré, le puse números y otras combinaciones.
Bajar desde aquí nuevo diccionario mejorado, con muchas más palabras y que puedes ampliar si quieres para usar con el programa. Modo de uso: Lo descomprimes y dejas MiDic.dic en la misma carpeta que DicGenerator.exe, luego ejecutas el programa.
Código fuente del programa para generarlo o ampliarlo
Usar Visual Studio 2013 o superior. Está escrito en C#. Bajar desde aquí código fuente por si quieren agregarle más palabras, letras, símbolos o lógica (ojo no es una maravilla de código, lo hice en 3 hrs).
En mi equipo el programa estima que demorará 20 hrs en probar todo el diccionario. Esto depende de su CPU, RAM y calidad de su Tarjeta de Video.
Generador de diccionario (Binario)
DicGenerator.exe: bajar aquí.
Diccionario base "MiDic.dic" para usar con el programa DicGenerator.exe
El diccionario base en primera instancia lo encontré en este sitio y pesa apenas 4 MB. Lo mejoré, le puse números y otras combinaciones.
Bajar desde aquí nuevo diccionario mejorado, con muchas más palabras y que puedes ampliar si quieres para usar con el programa. Modo de uso: Lo descomprimes y dejas MiDic.dic en la misma carpeta que DicGenerator.exe, luego ejecutas el programa.
Código fuente del programa para generarlo o ampliarlo
Usar Visual Studio 2013 o superior. Está escrito en C#. Bajar desde aquí código fuente por si quieren agregarle más palabras, letras, símbolos o lógica (ojo no es una maravilla de código, lo hice en 3 hrs).
miércoles, 8 de marzo de 2017
HTTP versus HTTPS versus HTTP/2
Hola gente informática, llevo mucho tiempo sin postear algo. Este es la traducción del excelente post original y comentado en algunos puntos por mi: https://www.tunetheweb.com/blog/http-versus-https-versus-http2, espero les guste.
Esto es contra intuitivo ya que sin duda hay cargas extras sobre HTTPS que normalmente se aplican encima de la capa HTTP. Así que cada vez que alguien pasa por este sitio, se pregunta cómo puede ser. Bueno, la razón no es debido al mismo HTTPS, sino que ese HTTPS usa HTTP/2.
De hecho, en el sitio, se menciona en la parte inferior, "el texto en HTTP/1.1 se compara con HTTPS HTTP/2 encriptado", pero no es tan obvio. El objetivo de la página (supongo) es mostrar las mejores condiciones de HTTP en comparación con las mejores condiciones para HTTPS y como HTTP/2 es sólo compatible con los navegadores que usan HTTPS, ahí tienen el argumento de la comparación.
Ahora estoy seguro que esto es falso por varias razones:
Así que en un intento de hacer un test real, he hecho una prueba similar para comparar HTTPv1.1 con HTTPS (sobre HTTPv1.1) y luego con HTTP/2 (que utiliza HTTPS). Puedes ejecutar esta versión de esta prueba con 36 imágenes más reales. También he creado una versión con 360 imágenes aquí. Le sugiero es que repitas las pruebas varias veces para tener una idea de cuánto tiempo se tarda, y probablemente verás algo como esto para la prueba de 36 imágenes:
Y similarmente sucede con el test de 360 imágenes:
Nota del traductor, agregué abajo la imagen de HTTP VS HTTPS y vs HTTP2:
Lo que inmediatamente se ve es que HTTP es bastante similar a HTTPS. Ocasionalmente es más rápido y ocasionalmente es más lento. Extrañamente se ve más a menudo que HTTPS es ligeramente más rápido que HTTP. No estoy seguro si esto es sólo suerte o algún efecto de almacenamiento en caché. Tal vez mi navegador web, red o servidor web maneja mejor el HTTPS, o tal vez es sólo una coincidencia. De cualquier manera, los números están separados sólo unos pocos puntos porcentuales. O tal vez HTTPS es realmente es más rápido que HTTP :-)
Lo que podemos ver es que HTTPS no causa ningún impacto al rendimiento en sitios web pequeños, como ha sido declarado por la mayoría de los expertos desde hace algún tiempo. Esto podría variar, por supuesto, si usted está ejecutando el sitio en un hardware realmente viejo (me refiero en el cliente o en el lado del servidor) o tiene un sitio web que usa mucho tráfico (por ejemplo, streaming de vídeo), pero para la mayoría de nosotros sería difícil notar el impacto de rendimiento con HTTPS. Hay un pequeño impacto al momento de redirigir a HTTPS (que se puede remediar con HSTS), y otro pequeño impacto al tratar con la sesión HTTPS (que se puede corregir con una buena configuración de HTTPS y podría incluso mejor cuando TLSv1.3 sea más popular). Estos factores son medibles si se utilizan herramientas como http://www.webpagetest.org, pero a la mayoría de los usuarios no le importa medir esta latencia inicial ya que luego no se ven retrasos. Si hay malas conexiones de red (por ejemplo, una mala señal móvil) estos viajes de ida y vuelta causarán más problemas, pero cuando pase eso, tendrás un desempeño malo a nivel general de todos modos.
El otro punto obvio es que HTTP/2 es mucho más rápido que HTTP o HTTPS, aunque sólo está disponible usando HTTPS. Este fue el punto engañoso que sentí de https://www.httpvshttps.com, ya que no fue HTTPS el que causó el buen desempeño, sino que fue HTTP/2, incluso en un sitio más pequeño de 36 imágenes. Por supuesto, el sitio de 360 imágenes sigue siendo un ejemplo extremo y no vas a ver un 91% de mejora simplemente encendiendo HTTPS, incluso usando HTTP/2 para la mayoría de los sitios. Sin embargo incluso el sitio más pequeño de la imagen 36 ve una mejora enorme del 70% en HTTP/2, mucho más de lo que habría esperado.
También es impresionante ver las mejoras de descarga de HTTP/2 debido a la compresión del header. En la página de 360 imágenes el tamaño total de la página es 382kb, es idéntico en HTTP y HTTPS, pero cae a un impresionante 265kb en HTTP/2 ¡una mejora del 30%!:
Ahora, estas imágenes son pequeñas y la mayoría de los recursos que carga un sitio web probablemente son mayores, por lo que la mejora de la compresión de header puede ser menor al 30%, pero sigue siendo buena.
HTTPS en particular es una tecnología bien establecida ahora y con iniciativas como Let's Encrypt nunca ha sido más fácil ni más barato obtener un certificado HTTPS para su sitio web. Hay muchas razones para usar HTTPS y se va a hacer cada vez más difícil mantener un sitio HTTP con navegadores web que están apuntando sus características para sitios que usan HTTPS. Si no estás usando HTTPS, entonces debes mirar de qué se trata ahora ahora. Estas pruebas demuestran que el impacto en el rendimiento no es ni siquiera algo notable en la mayoría de los sitios. El movimiento puede ser tedioso, especialmente para los sitios más grandes con un montón de código y páginas legadas, pero esto se hace una sola vez y cuanto antes se inicia mejor será.
HTTP/2 no está listo al 100% los SO y servidores web, pero en poco tiempo lo estará. La especificación HTTP/2 sólo se publicó oficialmente en mayo de 2015, y ya pasado un año casi todos los navegadores web soportan HTTP/2 y muchos servidores web también lo soportan. HTTP/2 será el futuro de la web y si usted tiene la oportunidad de usarlo, entonces juegue, estas pruebas demuestran lo mucho más rápido que puede ser, sin ningún cambio en el propio sitio web. Puedes consultar el post sobre cómo configurar HTTP/2 para Apache si quieres más información sobre eso.
¿Estás de acuerdo? ¿No mucho? Escribe abajo tus comentarios.
Introducción
Todos sabemos que rendimiento de HTTPS ya no es una barrera para su implementación en los sitios web. Incluso hay sitios como https://www.httpvshttps.com que muestran que HTTPS es mucho más rápido que HTTP.Esto es contra intuitivo ya que sin duda hay cargas extras sobre HTTPS que normalmente se aplican encima de la capa HTTP. Así que cada vez que alguien pasa por este sitio, se pregunta cómo puede ser. Bueno, la razón no es debido al mismo HTTPS, sino que ese HTTPS usa HTTP/2.
De hecho, en el sitio, se menciona en la parte inferior, "el texto en HTTP/1.1 se compara con HTTPS HTTP/2 encriptado", pero no es tan obvio. El objetivo de la página (supongo) es mostrar las mejores condiciones de HTTP en comparación con las mejores condiciones para HTTPS y como HTTP/2 es sólo compatible con los navegadores que usan HTTPS, ahí tienen el argumento de la comparación.
Ahora estoy seguro que esto es falso por varias razones:
- No está claro que sean pruebas similares ya que la única diferencia es que una sección solo son HTTPS. Se muestra que el hecho implícito de ser HTTPS es la razón por la que es más rápido cuando no lo es.
- Es un ejemplo extremo que un sitio web HTTP/2 sea muy bueno cargando 360 imágenes casi idénticas. Cuando los sitios web siempre van creciendo en cantidad de imágenes y ninguno carga 360 imágenes casi idénticas desde mismo dominio. De modo que el único problema serían las latencias en el cual HTTP/2 tiene mejoras sustanciales. La mayoría de los sitios web cargan una cantidad de recursos de varios dominios y algunos de esos recursos (especialmente CSS y Javascript) toman tiempo en procesarse, mientras que las imágenes pequeñas tienen un tiempo de procesamiento insignificante.
- HTTP/2 incluye compresión del header así los request se ven más pequeños en HTTP/2. De nuevo, la mejora aquí se ve ya que carga un montón de pequeños recursos todos casi iguales.
- HTTPS no significa de forma automática HTTP/2 incluso lo contrario es así. De hecho, hace poco se retrocedió un paso en la disponibilidad de HTTP/2. Tomará un tiempo hasta que HTTP/2 esté disponible en todos los SO clásicos y servidores web comunes, por lo tanto decir que HTTPS es lo mismo que HTTP/2 no me calza mucho. Decir que CDN como CloudFlare ofrece su servicio con HTTP/2 es cierto pero no quiere decir que le sirva todo el mundo.
- Esta ignora el pequeño impacto en el rendimiento en la conexión inicial de un sitio con HTTPS como si fuera el mismo rendimiento cuando se carga un HTML. Ahora bien, esto es difícil de medir con precisión, sobre todo porque sólo se puede medir una vez por sesión, y es pequeño (unos pocos cientos de milisegundos), pero es algo que la gente nota al pasar de HTTP a HTTPS.
- ¡No hay razones para hacer trucos como estos! HTTPS y HTTP/2 son grandes tecnologías que tienen muy buenos beneficios, lo que nos invita a utilizarse en todo lo posible. Meter trucos falsos como estos, sólo nubla la visión y te pone en duda sus ventajas.
Así que en un intento de hacer un test real, he hecho una prueba similar para comparar HTTPv1.1 con HTTPS (sobre HTTPv1.1) y luego con HTTP/2 (que utiliza HTTPS). Puedes ejecutar esta versión de esta prueba con 36 imágenes más reales. También he creado una versión con 360 imágenes aquí. Le sugiero es que repitas las pruebas varias veces para tener una idea de cuánto tiempo se tarda, y probablemente verás algo como esto para la prueba de 36 imágenes:
Y similarmente sucede con el test de 360 imágenes:
Nota del traductor, agregué abajo la imagen de HTTP VS HTTPS y vs HTTP2:
Lo que inmediatamente se ve es que HTTP es bastante similar a HTTPS. Ocasionalmente es más rápido y ocasionalmente es más lento. Extrañamente se ve más a menudo que HTTPS es ligeramente más rápido que HTTP. No estoy seguro si esto es sólo suerte o algún efecto de almacenamiento en caché. Tal vez mi navegador web, red o servidor web maneja mejor el HTTPS, o tal vez es sólo una coincidencia. De cualquier manera, los números están separados sólo unos pocos puntos porcentuales. O tal vez HTTPS es realmente es más rápido que HTTP :-)
Lo que podemos ver es que HTTPS no causa ningún impacto al rendimiento en sitios web pequeños, como ha sido declarado por la mayoría de los expertos desde hace algún tiempo. Esto podría variar, por supuesto, si usted está ejecutando el sitio en un hardware realmente viejo (me refiero en el cliente o en el lado del servidor) o tiene un sitio web que usa mucho tráfico (por ejemplo, streaming de vídeo), pero para la mayoría de nosotros sería difícil notar el impacto de rendimiento con HTTPS. Hay un pequeño impacto al momento de redirigir a HTTPS (que se puede remediar con HSTS), y otro pequeño impacto al tratar con la sesión HTTPS (que se puede corregir con una buena configuración de HTTPS y podría incluso mejor cuando TLSv1.3 sea más popular). Estos factores son medibles si se utilizan herramientas como http://www.webpagetest.org, pero a la mayoría de los usuarios no le importa medir esta latencia inicial ya que luego no se ven retrasos. Si hay malas conexiones de red (por ejemplo, una mala señal móvil) estos viajes de ida y vuelta causarán más problemas, pero cuando pase eso, tendrás un desempeño malo a nivel general de todos modos.
El otro punto obvio es que HTTP/2 es mucho más rápido que HTTP o HTTPS, aunque sólo está disponible usando HTTPS. Este fue el punto engañoso que sentí de https://www.httpvshttps.com, ya que no fue HTTPS el que causó el buen desempeño, sino que fue HTTP/2, incluso en un sitio más pequeño de 36 imágenes. Por supuesto, el sitio de 360 imágenes sigue siendo un ejemplo extremo y no vas a ver un 91% de mejora simplemente encendiendo HTTPS, incluso usando HTTP/2 para la mayoría de los sitios. Sin embargo incluso el sitio más pequeño de la imagen 36 ve una mejora enorme del 70% en HTTP/2, mucho más de lo que habría esperado.
También es impresionante ver las mejoras de descarga de HTTP/2 debido a la compresión del header. En la página de 360 imágenes el tamaño total de la página es 382kb, es idéntico en HTTP y HTTPS, pero cae a un impresionante 265kb en HTTP/2 ¡una mejora del 30%!:
Conclusión
HTTPS y HTTP/2 son dos grandes tecnologías y todos los sitios web corrientes deberían ser conscientes de ellos y buscar implementarlos si no se utilizan todavía. Mi intención de este artículo no fue para probar que HTTPS todavía tiene problemas de rendimiento, ni para soplar sitios web de otros, nada más fue para obtener algunos números tras pruebas de rendimiento que no se explican allí.HTTPS en particular es una tecnología bien establecida ahora y con iniciativas como Let's Encrypt nunca ha sido más fácil ni más barato obtener un certificado HTTPS para su sitio web. Hay muchas razones para usar HTTPS y se va a hacer cada vez más difícil mantener un sitio HTTP con navegadores web que están apuntando sus características para sitios que usan HTTPS. Si no estás usando HTTPS, entonces debes mirar de qué se trata ahora ahora. Estas pruebas demuestran que el impacto en el rendimiento no es ni siquiera algo notable en la mayoría de los sitios. El movimiento puede ser tedioso, especialmente para los sitios más grandes con un montón de código y páginas legadas, pero esto se hace una sola vez y cuanto antes se inicia mejor será.
HTTP/2 no está listo al 100% los SO y servidores web, pero en poco tiempo lo estará. La especificación HTTP/2 sólo se publicó oficialmente en mayo de 2015, y ya pasado un año casi todos los navegadores web soportan HTTP/2 y muchos servidores web también lo soportan. HTTP/2 será el futuro de la web y si usted tiene la oportunidad de usarlo, entonces juegue, estas pruebas demuestran lo mucho más rápido que puede ser, sin ningún cambio en el propio sitio web. Puedes consultar el post sobre cómo configurar HTTP/2 para Apache si quieres más información sobre eso.
¿Estás de acuerdo? ¿No mucho? Escribe abajo tus comentarios.
Suscribirse a:
Entradas (Atom)