martes, 22 de abril de 2014

Data Binding con C# directamente en el Code Behind

Trabajar con Data Binding directamente en XAML es algo bastante trivial, aunque también puede dar algún que otro quebradero de cabeza. En cualquier caso, no es la única forma de hacerlo puesto que siempre podemos recurrir al data binding desde el code behind directamente.


Esto último quizás no sea muy recomendable cuando estamos trabajando con patrones de diseño como puede ser el MVVM por razones obvias propias del patrón, pero que no sea recomendable no significa que no podamos hacerlo o incluso que no sea conveniente hacerlo en determinados casos.


El enlace a datos en C# y desde el code behind lo podemos hacer de muchas formas, aquí voy a exponer una (a modo de concepto) que he utilizado recientemente.


El escenario es sencillo. Se tiene un control Grid al que queremos enlazar su propiedad Visibility con una propiedad de una clase de datos. Aquí podéis ver un extracto de código en donde se realiza la parte del DataBinding propiamente dicha:

 // Se crea la instancia de la clase Binding
 System.Windows.Data.Binding binding = new System.Windows.Data.Binding();
 // Se asigna la fuente de datos que contiene la propiedad a enlazar
 binding.Source = customersVM;
 // Se indica la propiedad que se va a enlazar de la clase de datos
 binding.Path = new PropertyPath("ShowCustomers");
 // Se indica el modo de enlace, en este caso TwoWay
 binding.Mode = System.Windows.Data.BindingMode.TwoWay;
 // En este caso, además se hace uso de un Conversor de Booleano a Visibility
 binding.Converter = new ViewModel.BoolToVisibilityConverter();
 // Además se utiliza un parámetro para el conversor
 binding.ConverterParameter = true;
 // Y finalmente se asocia el Binding con el grid
 grid.SetBinding(Grid.VisibilityProperty, binding);


Espero que le sea útil a mas de uno ... y de dos.

domingo, 13 de abril de 2014

Nivel Técnico en Cursos, Charlas, Material ... de Microsoft

Cuando realizamos un curso o asistimos a una charla, webcast, etc. de Microsoft, es muy importante tener en cuenta el nivel técnico indicado en cada uno de estos eventos. Y es importante, porque no es muy recomendable realizar un curso de nivel 400, si se tiene por ejemplo un nivel 100 sobre el tema que trata dicho curso.

Por esto, es necesario saber cuál es exactamente el estándar que define cada uno de estos niveles y actuar en consecuencia.

A continuación tenemos la definición de cada uno de los niveles (100, 200, 300 y 400):

Nivel 100: Este es el nivel de introducción y como tal se requerirá poca experiencia o ninguna. En este nivel se tratarán conceptos, funciones, características y beneficios sobre el tema en cuestión.

Nivel 200: Este es el nivel medio. Supone un conocimiento de nivel 100 proporcionando además detalles más específicos sobre el tema.

Nivel 300: Se trata de un nivel avanzado. Da por echo que se cuenta con el conocimiento de un nivel 200 y una comprensión en profundidad de las características en un entorno real, así como una sólida habilidad en programación. Proporciona una introducción técnica detallada de un subconjunto de características de producto/tecnología que van desde la arquitectura, rendimiento, migración, implementación o despliegue y desarrollo.

Nivel 400: El nivel de los expertos. Aquí se tratará con material de muy alto nivel técnico y como tal requiere un nivel profundo de conocimientos, así como experiencia y una gran comprensión sobre el tema. Proporciona interacción de experto a experto y trata temas especializados.


Pues nada, a partir de ahora cuando asistas a una charla o leas un documento en el que se incluya el nivel técnico requerido, ya sabrás de que se trata.

jueves, 13 de marzo de 2014

Y el DRON llegó como todo: Sin legislación clara para el usuario

Antes de nada una pequeña introducción para que se entienda que me lleva a escribir esta opinión.
 
Parece ser, que los productos llegan al mercado y por tanto a manos de sus usuarios sin antes existir una legislación clara que contemple todo lo relacionado con su uso o incluso su posesión. Solamente cuando ya existen miles/millones de usuarios se crean las leyes al respecto y si no existen, pues simplemente se ponen multas y listo. Eso sí, cuando ya se ha implantado la necesidad, cuando la gente ya es tecno-dependiente, cuando ya no hay "marcha atrás" posible.
 
Pongamos por caso los GPS (Sistemas de Posicionamiento Global). Primero lo compran millones de usuarios y posteriormente se prohíbe su manipulación en el vehículo. ¿No habría que informar antes? ¿No sería conveniente que en el momento de su adquisición se facilitase también la normativa correspondiente? Ahora sí, ahora se "ADVIERTE", pero primero no se hizo nada.
 
Y ¿Qué sucede con los teléfonos móviles? Otro tanto de lo mismo. Primero te lo compras, y luego cuando nos parece que es un peligro para el tráfico pues te multamos como lo uses.
 
¡Ojo! que veo muy bien que ninguno de estos aparatos se "manipule" durante la conducción, por los peligros que ello conlleva, algo que veo constantemente en la carretera. No van por ahí los tiros, van por dejar las cosas claras antes de poner estos aparatos en manos de los usuarios.
 
¡ HAY QUE APLICAR LA PREVENCIÓN  ANTES DE CREAR LA NECESIDAD, NORMATIVA ANTES DE QUE EL PRODUCTO LLEGUE AL MERCADO, INFORMAR AL USUARIO!
 
¡Sí, lo he dicho gritando! Pero es inevitable.
 
Pues bien, ahora llegan los DRONES. Cualquiera puede ir a la tienda y comprarse uno o si te gusta el tema, fabricártelo tu mismo.
 
Los problemas (entre otros) que yo veo son los siguientes:
 
  1. ¿No sería preciso disponer de un permiso o licencia para pilotar uno de estos "juguetes"?
  2. ¿No sería conveniente disponer de un "SEGURO" contra posibles accidentes?
  3. ¿No será necesario que exista una normativa que deje claro en qué zonas se pueden volar, cual es la edad mínima necesaria, cuales son los límites de distancia, altitud, etc.?
  4. ¿Si llevan cámara de foto/video, qué sucede con la privacidad de las personas?
  5. ... y de existir todo esto ¿Quién lo sabe?
 
Imaginad por un momento que alguna de estas noticias fuera cierta:
 
  • Un DRON se queda sin batería y se estrella contra la luna delantera de un conductor que iba a 120Km/h por la autovía o a 30Km/h por la transitada calle principal de una gran ciudad.
  • Una persona está disfrutando de un placentero sueño en su casa, cuando de repente un DRON choca contra su ventana.
  • Un DRON se estrella contra un niño que jugaba en la calle con sus amigos.
  • Un ciudadano, al ver que un DRON se encontraba enfocando con su cámara hacia el interior de su vivienda (concretamente la habitación de su hija pequeña), consigue golpearlo con el palo de la escoba y provoca su caída en picado, lo cual a su vez también provoca ciertos daños en la vía pública. Suerte que no pasaban peatones en ese momento. 
  • Se filtra el nuevo diseño de un "Producto A", antes de llegar al mercado. Al parecer un DRON consiguió imágenes del mismo, grabando desde el exterior de una de las ventanas de la empresa.
  • La cuestión es: si está prohibido colocar una cámara de vigilancia enfocando a la vía pública, ¿no debiera estarlo que un DRON con cámara, sobrevuele nuestras cabezas o nuestras casas? Y, en todo caso ¿Dónde queda nuestra privacidad?
Una cosa es que lo utilicen los cuerpos de seguridad del estado en determinadas circunstancias y como herramienta de apoyo y, otra muy distinta es que cualquiera pueda hacerlo. Con el tiempo, es más que probable que empecemos a escuchar problemas de este tipo. Eso sí, primero que la gente se compre los DRONES, luego ya "si eso" veremos lo que hacemos.
 
MI CONCLUSIÓN: Normativa, Licencia y Seguro contra daños, todo ello específico para los DRONES y similares e informando al usuario antes de su adquisición, ... ah sí y raciocinio de ser humano.

jueves, 5 de diciembre de 2013

Obteniendo la localización del teléfono (GPS) con C# en Windows Phone/ Windows 8 App

Con el fin de ahorrarme unas cuantas respuestas a correos electrónicos, voy a plasmar aquí un pedazo de código fuente en C# que sirve para obtener las coordenadas, posición o localización (como más os guste) de un dispositivo con Windows Phone 8 o aplicación de la tienda de Windows 8.

Obviamente es un código a modo de prueba de concepto, vosotros deberéis adaptarlo adecuadamente según la necesidad y por supuesto realizar las comprobaciones de errores pertinentes, más allá del Try/Catch de rigor.

using System;
using Windows.Devices.Geolocation;

namespace GPSTesting
{

public delegate void GeoCallback(double Latitud, double Longitud)

// Definición de la clase ... blah, blah, blah ...

public async void GPSCoordenadas(GeoCallback callback)
{
    try
    {
        Geolocator Localizador = new Geolocator();
        Localizador.DesiredAccuracy = PositionAccuracy.Default;
        Geoposition Posicion = await Localizador.GetGeopositionAsync();
       callback(Posicion.Coordinate.Latitude, Posicion.Coordinate.Longitude);
    }
    catch (Exception)
   {
        // ...
   }
}
}

¡Así de fácil! Que os aproveche.

Emulador de Windows Phone 8

Si tu intención es desarrollar aplicaciones para Windows Phone 8, una de las cosas que inevitablemente deberás conocer son los requisitos hardware/software que necesitarás.
 
A nivel de software, sin duda una de las soluciones más lógicas sería utilizar el SDK correspondiente, el Windows Phone SDK 8.0 y como no podía ser menos, el sistema deberá ser un Windows 8 Pro o superior.
 
Ahora bien, en la parte del hardware la cosa se te puede complicar un poco, debido a los requerimientos del sistema necesarios para poder ejecutar el "Emulador de Windowsl Phone 8". Cuando digo "requerimientos necesarios", en realidad lo que quiero decir es "Requerimientos OBLIGATORIOS".
 
A nivel de BIOS/CPU, tu equipo deberá soportar las siguientes características:
 
  • Virtualización Hardware (Hardware-assisted Virtualization)
  • Traducción de direcciones de segundo nivel (SLAT - Second Level Address Translation)
  • Prevención de ejecución de datos por Hardware (DEP - Data Execution Prevention)
 
Además, necesitarás:
  • 4 GB de RAM o más
  • Por supuesto 64 bits
  • Windows 8 Pro de 64 bits
 
A nivel de red:
  • DHCP
  • Configuración automática de DNS
 
Ya en el sistema operativo deberás activar Hyper-V y tu usuario deberá pertenecer a un grupo de administradores de Hyper-V para evitar problemas de permisos con el emulador.
 
De todo esto, es posible que una de las cosas que más te pueda provocar dolores de cabeza sea SLAT. En cualquier caso, para saber si tu equipo reúne las condiciones adecuadas, puedes hacer uso de la herramienta COREINFO de Mark Russinovich, que puedes descargar en Technet de Microsoft (los vagos aquí tenéis el enlace http://technet.microsoft.com/en-us/sysinternals/cc835722.aspx)
 
Una vez ejecutéis dicha herramienta y observéis los resultados que os muestra, no desesperéis a la primera de cambio, quizás tengas una última oportunidad de reunir los requisitos. Por ejemplo, entra en la BIOS de tu equipo y comprueba si la virtualización está activada.
 
Ni que decir tiene que si tu equipo no reune tales condiciones, la mejor opción es adquirir un móvil con Windows Phone 8 para hacer el testeo de tus aplicaciones, algo que sin duda, siempre es recomendable incluso utilizando previamente el emulador.
 
Nuevamente tocará invertir para ampliar infraestructura de desarrollo.

lunes, 27 de mayo de 2013

Policías y Ladrones - Crónicas de la 2

Aquí os dejo el vídeo de un documental emitido en la 2, en el programa Crónicas. Trata sobre la ciberdelincuencia o ciberdelitos, desde el punto de vista del Grupo de Delitos Telemáticos de la Guardia Civil, la Brigada de Investigación Tecnológica de la Policía y Profesionales del mundo de la Seguridad Informática.
 
Sin duda un documental muy interesante para CONCIENCIAR a todos aquellos escépticos o "ignorantes" -con todos los respetos del mundo-, que piensan que la seguridad informática no es para ellos, porque ¿Quién va a querer algo de mi ordenador? ¡Si yo no tengo nada que esconder ni que merezca la pena! La respuesta es muy sencilla ¿Quién querría entrar en tu casa y para qué? ¿Quién querría robar tu vehículo y para qué? ¿Quién querría secuestrarte y para qué? Si total, no eres un personaje público, famoso, millonario, etc.
 
Tened mucho cuidado con vuestros dispositivos electrónicos. Si estáis conectados a la red, ya corréis el riesgo y aunque "solo" sea para cometer un delito desde vuestro ordenador, teléfono móvil, etc. ya sois perfectos objetivos, aunque no creáis tener nada importante que proteger.
Por cierto, me permito daros un consejo, ahora que llega el verano recordad que no es recomendable que publiquéis en vuestros servicios de redes sociales y demás (Facebook, Twitter, Google+, Tuenti, WhatsApp, Line, etc) que os vais de vacaciones a las Maldivas desde el 15 de Junio al 1 de Julio, mas que nada, porque en cierto modo le estarás contando a los malos que "tu casa probablemente quede vacía".
 

sábado, 11 de mayo de 2013

Ingeniería Inversa de Firmware en un PIC 16Fxxx de Microchip

Como parece que no tengo mejores cosas que hacer, no se me ocurre otra forma mejor de pasar una tarde de Sábado que hacer un poco de Ingeniería Inversa a un microcontrolador PIC de la casa Microchip.
 
En esta ocasión se trata de un microcontrolador de la familia 16Fxxx (tipo 16F876, 16F84, etc.) cuyos opcodes tienen un tamaño de 14 bits. El mismo sistema será válido para otros microcontroladores de otras familias o incluso fabricantes, incluso aún cambiando la arquitectura del microcontrolador, la base esencial del análisis será similar en multitud de casos.
 
Siempre que se me plantea una situación similar, me gusta entender los entresijos de lo que tengo entre manos y, en la medida de lo posible intento empezar "a mano" o "a pelo" en el proceso de obtención de los Nemotécnicos ó, en definitiva las instrucciones en lenguaje ensamblador.
 
A continuación os muestro un pequeño pedacito de un firmware que he estado analizando, se trata del comienzo del mismo y, ni que decir tiene, que intentar analizar el funcionamiento de un programa observando tan solo estos números:

0F28CE00030E83128F00040890000A0891004F089200492B ...
 
es de paranóico/marciano, como poco. Si hay alguien en el planeta que observando esas ristras de números es capaz de interpretar la lógica que esconden, que me lo presenten, por favor.
 
En definitiva, cuando se trata de entender el funcionamiento de un software/firmware del cual no tenemos su código fuente, la cosa se complica bastante como para ponerse a leer números. Esto no funciona así, en su lugar, un primer paso consiste en transformar esos números en los citados Nemotécnicos que conformaran el programa en lenguaje ensamblador, sin duda, mucho más inteligible para el ser humano.
 
Incluso, en algunas circunstancias, se da un paso mas allá y se genera un código fuente en un lenguaje de más alto nivel o pseudocódigo, que podría ser utilizando nuestras propias palabras o basándonos en un lenguaje de programación estándar.
 
Bueno, no me quiero enrrollar más con palabrería así que, voy al grano.
 
La idea es bastante simple, extraemos el firmware de la memoria del microcontrolador o si se da el caso de la memoria externa en donde se encuentre alojado. Inicialmente se tratará de una ristra de ceros y unos, para finalmente obtener valores hexadecimales y por último los preciados nemotécnicos del lenguaje ensamblador equivalente.
 
Así, en el trozo del ejemplo anterior, el equivalente en código binario (0's y 1's) de los valores 0F28CE0003 sería:
 
111100101000110011100000000000000011

Si los agrupamos de 8 en 8 bits, lo podremos convertir fácilmente a valores hexadecimales equivalentes a 1 byte:

00001111 = 0x0F
00101000 = 0x28
11001110 = 0xCE
00000000 = 0x00
00000011 = 0x03

Y así con todo, pero bueno lo que quiero dejar en claro, es que nosotros inicialmente lo único que podemos "sacar" del microcontrolador serán "una corriente" de ceros y unos, los cuales agruparemos de 8 en 8 para formar bytes y poder representar más fácilmente los distintos opcodes en formato hexadecimal.
 
Una vez tenemos los valores en hexadecimal, la obtención de los nemotécnicos es relativamente sencilla, aquí es donde las cosas empezarán a cambiar de unas arquitecturas de microcontrolador a otras.
 
En el caso que nos ocupa de la familia 16Fxxx de Microchip, tenemos opcodes de 14 bits, lo que nos hace ver claramente que tendremos que tomar los valores de dos en dos bytes. Volviendo al ejemplo, los valores quedarían separados de la siguiente manera:

0F28 CE00 030E 8312 8F00 0408 9000 0A08 9100 4F08 9200 492B ...

Como os podeis imaginar, hacer todo este proceso a mano es una locura, aquí tan solo tenemos unos pocos opcodes, pero un firmware del mundo real, por ejemplo el que podemos encontrar en un mando a distancia moderno, el ordenador de abordo de un coche, una televisión, un teléfono móvil, etc se compone de miles/millones de opcodes. ¡Aquí tan solo estoy mostrando 12!
 
Pero claro, hacerlo de esta forma, te obliga a entrar de lleno en las tripas del microcontrolador a un muy bajo nivel. Entender la arquitectura del microcontrolador, su conjunto de instrucciones, interpretación de las tablas de opcodes, organización de la memoria, registros, etc, etc. Y esto es lo que a mi me gusta.
 
¡Seguimos!. Por último y de momento, el siguiente paso después de obtener los valores agrupados de dos en dos bytes, es convertirlos a sus opcodes equivalentes y, en el caso del ejemplo aquí los tenemos:

280F goto  0x00F  
00CE movwf memoria_4e   
0E03 swapf STATUS, W
1283 bcf   STATUS, 5
008F movwf memoria_0f   
0804 movf  FSR, W   
0090 movwf memoria_10   
080A movf  PCLATH, W
0091 movwf memoria_11   
084F movf  memoria_4f, W
0092 movwf memoria_12   
2B49 goto  ETQ_349


Ahí tenemos el pedacito de programa en lenguaje ensamblador mucho más fácil de interpretar, aunque todavía se puede mejorar y mucho. Además si observáis, hay varias cosas que os deberían llamar la atención. La primera es con los valores en hexadecimal, os habréis dado cuenta de que están "invertidos" los bytes con respecto a los originales del ejemplo. Bueno, esto tiene nuevamente que ver con la arquitectura del microcontrolador y como gestiona su memoria. En este caso, se almacenan con el valor menos significativo primero y el más significativo después lo que en informática denominamos como Little-Endian (su opuesto sería el Big-Endian), pero bueno, esto es otro tema.
 
Con el fin de mejorar todavía un poco más el código ensamblador generado, he añadido las direcciones de memoria en la primera columna, para ver claramente que el primer salto (goto) se hace a la dirección indicada por 0x0F, a la cual la he "etiquetado" como Inicio_00F. También se ve claramente que el programa inicia su ejecución en la dirección 0x04, etc.
 
Explicar aquí porque empieza el programa con esa primera instrucción de salto, tampoco es plan, pero por si os pica la curiosidad, tiene que ver con el vector reset (trocito de programa que ejecuta el microcontrolador cuando se produce una interrupción de tipo reset y bla, bla, bla).

Vector_Reset  org 0x000
        goto            Inicio_00f  ; 280F



Vector_Reset  org 0x000
 
04      movwf           mem_4e      ; 00CE
05      swapf           STATUS, W   ; 0E03
06      bcf             STATUS, 5   ; 1283
07      movwf           mem_0f      ; 008F
08      movf            FSR, W      ; 0804
09      movwf           mem_10      ; 0090
0A      movf            PCLATH, W   ; 080A
0B      movwf           mem_11      ; 0091
0C      movf            mem_4f, W   ; 084F
0D      movwf           mem_12      ; 0092
0E      goto            ETQ_349     ; 2B49


0F Inicio_00f

        ...


Como veis, se trata de un tema muy interesante que da mucho de sí. Podría estar horas y horas escribiendo sobre el tema hasta producir varios libros probablemente, pero como introducción para aquellos que os queráis animar, ya da!
 
Me consta que varías cosas de las que he hablado quedan en el aire, pero entenderéis que no es el objetivo de este post. Doy por supuesto, que los que estéis leyendo este post ya sabéis de que van todos esos detalles (código binario, conversión a hexadecimal, registros, organización de memoria, estructura de un opcode, etc.)
 
¡Menudo un rollo que he soltado! No se que será peor, si que yo lo escriba o que vosotros lo leáis, en fin, un saludo!