lunes, 19 de febrero de 2018

Configuración emulador MegaN64 Android para jugar Zelda Majora Mask

Hola chicos, hoy vamos analizar el excelente emulador de Nintendo 64, llamado MegaN64, para Android, con diversas opciones gráficas. Quise bajarlo ya que tenía muy buena nota 4.6 a la fecha actual (Febrero 2018) y me dio por jugar un clásico como lo es The Legend of Zelda: Majora's Mask.


Lo principal aquí son los Plugins. El acceso a ellos es por acá:

Por defecto, viene configurado asi:

Tomaré una parte donde hay algunos efectos gráficos variados, la parte de los Goron.

1. gles2n64

Si usamos el Plugin gles2n64 adaptación del GLN64 v0.4.1 se ve con varios problemas de renderizado: el techo se ve con rayas y el agua del río se ve mal. Si logra verse el efecto del vapor del agua. El hada se ve correctamente.

También el plugin tiene unas opciones. Intenté cambiar algo pero no mejoró en absoluto. Dejé marcado el filtro 2XSaI que en general mejora el pixeleado.

2. gles2rice

Ahora usaremos el Plugin gles2rice adaptación de Rice Video v6.1.0(b).

Aquí notamos los peores errores. Se ve pésimo la niebla. El río se ve gris. Muchas fallas. Injugable.


En las opciones, tiene bastantes cosas, intenté cambiar algo pero no mejoró.

3. gles2glide64

Ahora usaremos el Plugin gles2glide64 adaptación de Glide64 Final décimo aniversario. Este es el mejor de los 3, las texturas se muestran muy bien, efecto del agua, el hada, el río, etc. Se ve correcto la pintura del techo en la cueva y no rayas.


Este plugin no tiene opciones extras. Solo se selecciona y punto.

Opciones generales

En las opciones generales, lo único que recomiendo hacer es bajar la Opacidad de la barra de acciones a 20% o 15%.

Veredicto

Simplemente usa gles2glide64 y baja la opacidad de los botones y podrás jugar este gran juego sin problemas.
¡nos vemos!

jueves, 11 de enero de 2018

Algo distinto: Ruta del diente - Melipilla (actualizándose constantemente)

Este post es un poco distinto al resto. Con mi polola, nos hemos puesto la tarea de visitar todos restaurantes de Melipilla, Chile, lugar donde vivimos, con tal de hacer una ruta de la comida, disfrutar y ponerle una nota al final.
El resultado de lo que llevamos nos sorprendió y si van a "Meli" como le digo yo, les puede servir.

Marzo 2016 - Dragón de Oro

Serrano 380, Melipilla, Región Metropolitana

Buena atención, tranquilo, limpio.
Pedimos Carne Mongoliana, 2 arroz, 1 bebida y 1 trago.

Gasto total: $28.000

NOTAS
Ella: 8/10
Yo: 7/10

Requiere re-evaluación...pronto.

Diciembre 2016 - El Cuervo

Merced 666, Melipilla, Región Metropolitana

Es un pub rockero, para el bajón o para partir, buena música, público más bien masculino, mesa de pool, todos vestidos ropa oscura, tranquilo.
Que pedimos casi siempre: Dos Shop de medio Torobayo apenas $2500, porción para dos de papas fritas $2500. Es muy económico. Recomendable si te gustan los bar donde solo suene Gun's o Metallica. Recomendable: si.

Gasto total: $10.000

NOTAS 
Ella: 6/10
Yo: 7/10

Enero 2017 - Izy Snack Bar & Restaurante => ¡El mejor hasta el momento!

San Agustín 421, Melipilla, Región Metropolitana

Ideal para hacer una previa, o picar. No tienen parrilladas. Buena música de fondo, agradable lugar. Muy buena atención.
Pedimos tabla roll queso, mango sour, dos mojitos.

Gasto total: $31.800

NOTAS 
Ella: 9/10
Yo: 9/10

Marzo 2017 - La Leyenda

Pardo 415, Melipilla, Región Metropolitana

Muy caro para dos. Por fuera lindo, se ve mucha madera como algo rústico. Por dentro diseños mezclados modernos, rústicos. Pedí limpiar mantel cubre mesa por migas, mantel de abajo blanco sucio. Comimos parrillada para dos, dos pisco sour, dos jugos naturales de piña: recomendable SOLO si a ambos gustan las carnes y solo las carnes. El sabor es bueno y la carne a punto. Recomendable: si.

Gasto total: $35.600

NOTAS 
Ella: 7/10
Yo: 6/10

Abril 2017 - Barruetos

Serrano 417, Melipilla, Región Metropolitana

Local se ve normal, ni top, ni básico. Atención es normal, muy poca comida para el precio.
Pedimos una tabla y 2 pizzas individuales y 4 pisco sour. Lo encontramos caro para lo que comimos. Recomendable: no.

Gasto total: $28.670

NOTAS 
Ella: 6/10
Yo: 5/10

Abril 2017 - Osake Sushi Bar

Arturo Prat 763, Melipilla, Región Metropolitana.
Fono: 228313845 para pedir y luego ir a buscar, entregas en general demoran 30 min aprox.

El local se ve limpio. Tiene pequeños adornos orientales. La atención es excelente.  Quizá falta ambiente más íntimo (en el 2do. piso se logra eso perfecto), muy estrecho a veces cuando se llena, faltó música de fondo ya que sonaba más el teléfono ya que tiene para llevar. Recomendable: si, pero en el 2do. piso.

Primera visita
Pedimos: Ceviche reineta, Rolls 16 piezas pollo crema palta, Ebi Cheese palta camarón queso. Advertencia: El Ceviche es para 2 personas o una persona con mucha hambre ya que es el doble de lo que sirven en un local cuico en Las Condes.

Gasto total: $17.400

NOTAS 
Ella: 8/10
Yo: 8/10

Segunda Visita
Venimos ya que quedamos con hambre luego de ir a El Mirador de Popeta. La atención fue excelente. Quizá el mejor ceviche que he comido en los pocos locales que he visitado.
Pedimos: 2 Ceviches de Reineta, 2 jugos mangos exquisitos (el mejor jugo natural que he probado junto a uno de Chirimoya del Domino), un vaso vino tinto y Torta Rocher exquisita.

Gasto total: $21.500

NOTAS 
Ella: 8/10
Yo: 8/10

Fotos

Valores del Cebiche

Carta para compatir, recomiendo si eres novato Principiante 2, a $8.900.

Carta de los postres

Ceviche Mixto Palta: $5.100

Torta Rocher: $3.200

Suspiro Limeño: $2.800

Enero 2018 - El Mirador de Popeta

Sector de Popeta, Ruta G60, pasado Camino los Guindos, Melipilla, Región Metropolitana

Sobrevalorado. Venimos acá por las buenas notas que tenía en Google y Trivago. Está alejado de la ciudad, solo se llega en auto. Sólo se puede pagar en efectivo. Abren de 9 a 15 hrs y de 21 a 23 hrs. Por el calor me dijeron. Extraño.
Las mesas son chicas, dos personas sentadas uno al lado de otro tiene que sacar la pierna para le pasillo.

Es caro. El pan de cortesía estaba duro. Las papas fritas con extra-sal. No había ceviche en un restaurante especializado en pescados y mariscos. Quedamos con hambre y fuimos a Osake.
Pedimos: 4 empanadas muy chicas de camarón queso por $4.500. Plato típico es una Reineta Mirador con salsa champiñon vale $5.900. Una Reineta Reineta en Pil-Pil de camarones (congrio no había) valía $7.800, sin embargo el mejor sabor de la noche. Una porción papas fritas chica a $3.900, buen sabor, botella de Vino blanco de 500cc a $4.800, jugo mango $2.000. Recomendable: no.

Gasto total: $32.000

NOTAS 
Ella: 5/10
Yo: 6/10

Fotos


El restaurante que más bien es una "casona"


La carta


Porción de empanadas de queso camarón


Reineta en Pil-Pil de camarones


Reineta Mirador con salsa de champiñones



Pendientes


Ibiza

Sybaris

Bocados

Kionga

Pastas ditoti

Sakana Shushi

Parrilladas Argentina

Peruana Calle Arza

Antica Roma, en Vicuña Mackena 841, con Hurtado

Blueys

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í:

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.

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

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.

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.
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.

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 :)

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.

Capítulo 4: Aristocracia, Democracia y Diseño de Sistemas


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


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.
El primero de los puntos anteriores es un peligro real y será tratado en el próximo capítulo. Las otras dos son ilusiones, así de simple. Como hemos visto anteriormente, la implementación es también una actividad creativa de primer orden. La oportunidad de ser creativo en la implementación no disminuye significativamente al trabajar cuando se entrega una especificación externa y la creatividad puede incluso ser mejorada por esa disciplina y el producto total seguramente será mejor. La última objeción es una que tiene que ver con tiempos y ajuste de fase. Una respuesta rápida es abstenerse de contratar implementadores hasta que las especificaciones estén completas. Esto es lo que se hace cuando se construye un edificio. En el negocio de sistemas informáticos, sin embargo, el ritmo es más rápido y uno quiere comprimir el calendario tanto como sea posible. ¿Cuánto puede superponerse la especificación y la construcción?

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).