Administar objetos en Sql Server

A quien no le a pasado durante el  desarrollo del software  ,en la parte de base de datos llega un momento en que esta tanta la información que se almacenara y  empezamos a crear tablas,procedimientos almacenados,vistas,triggers,llaves primarias y foreanes pero al  final no sabemos que hemos creado o la cantidad exacta que existe de cada uno de  lo ya mencionado.

Bueno en esta entrada les dejare algunas consultas que puedes realizar en el manejador  de base de datos para tener una mejor administración en la creación de los objetos ya mencionados.

Cabe mencionar que para ejecutar la mayoría de las consultas es necesario contar con un usuario con la mayoría de los permisos en el manejar de la base de datos.

Fig1 Datos de Inicio de Session

Aquí las consultas para administrar los objetos creados en la base de datos.

--Consulta te permite ver las bases de datos dadas de alta en el manejador 
--de base de datos. 
select name from master.dbo.sysdatabases


--Consulta para mostrar todas las tablas creadas .
select name from sysobjects where type='U'


--Consulta para mostrar todas las vistas creadas .
select name from sysobjects where type='V'


--Consulta para mostrar los procedimientos almacenados creados
select name from sysobjects where type='P'


--Consulta para mostrar todas las llaves primarias creadas 
select name from sysobjects where type='K'


--Consulta para mostrar todas las llaves foraneas creadas 
select name from sysobjects where type='F'

Bueno pues son algunas consultas que debemos tener encuenta durante el desarrollo del software y despues de , si quieres ver mas información  de la consulta solo basta con cambiar "name" por  el  caracter "*"

Saludos...

Documental sobre Ciberguerra

Hace tiempo que la tecnología  a revolucionado al mundo y que da vez están mas presentes en nuestra vida y que han tenido un gran impacto dentro de la sociedad .

Alguna vez te has preguntado cual es el papel que juegan las nuevas tecnologías en nuestro entorno e aqui un documental sobre ciberguerra.

En portada - Amenaza Cyber

Un documental que tarata de explicar lo que ocurre en nuestro entorno espero y se  ha de su agrado 

Saludos..

Un motivo de cambio / SOLID

Siempre he pensado que el cambio no es tan malo, pero depende... es en esos momentos en que uno acude a la red: ¿El cambio es bueno o malo? ... el caso es que en ocasiones es mejor estar preparado.

Del mismo modo cambian los requerimientos y no siempre es tan sencillo solventar situaciones si no se realiza un buen diseño y una buena estructura.  Mi amigo de kinder garden  Robert C. Martin, quién publicó 5 principios básicos dentro de Principios de Diseño y Patrones de Diseño, nos dejó una manera de hacer amena esta situación.

No es un estándar y tampoco hay algo que nos obligue a diseñar nuestros programas bajo estos principios, sin embargo, el seguirlos o apegarnos lo más posible, nos llevará a un diseño fácil de mantener,  escalar, más legible, más organizado y por consecuencia de mejor calidad.

Principio de Única Responsabilidad (Single Responsibility Principle)

La primera letra del acrónimo -o mejor dicho acrónimo de acrónimos- SOLID (S: Single Responsibility Principle), es el primer principio descrito por mi amigo. Éste principio establece que una clase debe tener una única responsabilidad -un motivo por el cual existe esa clase- en el sentido de que solo debe de haber una razón por la cuál deba ser modificada, es decir, un solo motivo de cambio.

Si una clase tiene dos o más responsabilidades, es decir, se encarga de tareas que refieren a contextos diferentes, necesariamente llegada la necesidad de cambio asumirá más de un motivo por el cual pueda ser modificada y esto afectará a tareas que no tienen que ver con el origen de dicha clase.

Para no menear tanto "bla bla bla" entremos al detalle ;) ...  Les debo el ejemplo ;)

REST vs SOAP

Primero se debe tener claro que es cada cosa... escuchando alguna plática de gurús BPM con tu abuela, me di cuenta que hay cosas que creo están mal interpretadas, pero bueno me ha pasado nos pasa a todos.

No hay problema... el caso es que en ocasiones los términos pueden llegar a confundir y hacer que tomemos una opción inadecuada frente a x situación.

No me hagas pensar!

SOA (Service Oriented Architecture) es un concepto que refiere a un tipo particular de paradigma de arquitecturas de software.

Permite la creación de una arquitectura que se integra -o forma parte- de sistemas de información y/o aplicaciones que pueden llegar a ser bastante escalables, que permiten modelar todo el proceso de negocio de alguna organización, además es capaz de exponer e invocar servicios web, lo cual lleva a tener una rápida, práctica y, en general, una fácil integración de nuestra información. 

Para hacer analogía, la POO trabaja sobre aplicaciones construidas bajo un conjunto de librerías de clases -como podría ser un Framework-. Por el contrario, SOA se centra en sistemas que se construyen basándose en un conjunto de servicios independientes y autónomos.

¿Y con que se come ?

REST (Representational State Transfer) y SOAP (Simple Object Access Protocol) es como comparar peras y manzanas. Sin embargo, representan dos tipos diferentes -muy diferentes- para la implementación de una arquitectura SOA.

REST es un patrón de arquitectura construido bajo verbos simples que se adaptan bastante fácil con HTTP.

A diferencia, SOAP es un protocolo de mensajería basado en XML (mensajes SOAP con una estructura XML) que puede utilizarse por una variedad de protocolos de transporte, incluso el mismo HTTP.

¿Porqué son diferentes?

La principal diferencia entre el patrón REST y el protocolo SOAP, es la forma en la que se mantienen los diferentes estados por los que una aplicación pasa durante su vida. 

Con SOAP, el movimiento por los diferentes estados se realiza interactuando con un extremo único del servicio que puede encapsular y proporcionar acceso a muchas operaciones y tipos de mensaje. Por el contrario, con REST, se permite un número limitado de operaciones y dichas operaciones se aplican a recursos representados y direccionados por direcciones HTTP (URI). Los mensajes capturan el estado actual o el requerido del recurso. Por consecuencia, REST se integra bastante bien con aplicaciones Web donde se puede hacer uso de HTTP para tipos de datos que no son XML (o que no pueden serlo).

REST

1.- La arquitectura encaja de manera natural con HTTP.

2.- Necesario para clientes donde la capacidad es muy limitada (Escenarios JavaScript)

3.- No hay necesidad de Proxys (como en SOAP) para las conversiones y demás.

4.- Trata con acceso a recursos

REST - SOAP

5.- Operaciones remotas (una de las finalidades de los servicios web)

6.- Acceso a recursos remotos (más de lo anterior)

7.- Interoperable (otra de las finalidades de los servicios web)

SOAP

8.- El cifrado es a nivel de mensaje

9.- Dispone de ruteadores o intermediarios

10.- Reeegularmente (no creo que siempre) el envío de mensajes es confiable.

11.- Políticas de control (Diferentes perfiles)

12.- Basado en acciones

En resumen:

Ventajas de REST

• Está totalmente bajo especificaciones del protocolo HTTP, en donde todo actúa como un recurso, ni siquiera los servicios se escapan, se trata el mensaje igual como si fuera alguna imagen, uno o varios elementos HTML, etc. 
• No es tan estricto como SOAP, los datos pueden mantenerse estrictamente o de forma desacoplada, mediante la URI.
• Los recursos pueden consumirse fácilmente desde JavaScript (La mayoría de las aplicaciones que utilizan OpenId o el protocolo OAuth utilizan JavaScript para realizar llamadas con REST, por ejemplo twitter)
• Los mensajes son bastante ligeros, el rendimiento y la escalabilidad no deberían ser problema y cuando uno está acostumbrado a trabajar en "Internet", esto es de vida o muerte.
• REST no se queja, puede utilizar XML o JSON para el formato de los datos.

Desventajas de REST

• Si se trata de trabajar con objetos fuertemente tipados, tipo =P, en el código de servidor, es algo tedioso incluso difícil, pero esto también depende de otras situaciones.
• No creo (no lo sé) que funcione bien con aplicaciones de alto rendimiento y basadas en tiempo real. Por ejemplo, algún sistema para ingeniería industrial que arroje constantemente datos y mas datos para generar estadísticas.

Ventajas de SOAP

• Trabaja bien con datos, los mensajes y las comunicaciones están bien estructurados.
• Dispone de proxys fuertemente tipados.
• Funciona sobre diferentes protocolos, no solamente HTTP (como en REST) si no también sobre TCP, NamedPipes, MSMQ, etc. aunque el uso de estos no es tan bueno si se trata de estandarizar en Internet.

Desventajas de SOAP

• Los mensajes generados por SOAP no se pueden cachear (¿o si?)
• En JavaScript.. olvídate de SOAP.

¿Y entonces cuál?

No sé.. depende..

SOAP se ajusta muy bien para arquitecturas SOA implementadas dentro de aplicaciones con arquitecturas N-Layer. Además, SOAP gestiona aspectos de seguridad y direccionamiento mediante su implementación interna. También, funciona mucho mejor que REST con otro tipo de protocolos. Aunque, como comentaba, pierde "estandarización" pero si se trata dentro de una intranet donde los sistemas están controlados, creo que SOAP es la mejor opción.

Por el contrario, REST es normalmente mas adecuada para servicios distribuidos públicamente en Internet o en casos donde los consumidores son desconocidos (como el caso de implementaciones de OAuth).

REST es stateless por su naturaleza (HTTP), esto significa que cada petición individual enviada desde el cliente al servidor debe contener toda la información necesaria para entender la petición puesto que el servidor no almacenará datos de estado de sesión, o alguna mierd* cosa similar.

En definitiva, ambos protocolos permiten intercambiar datos haciendo uso de verbos y cada uno tiene sus desventajas frente al rendimiento y al ser escalables...

Al final, cada quien lo que se le antoje =P

FindControl en Asp.Net

Bueno pues después de varios intentos de poder asignarle un valor a un control  desde una MasterPage estuve investigando y llegue a poder hacerlo con el metodo FindControl de la clase System.Web.UI .

Básicamente lo que hace el método es buscar el control de servidor en el contenedor de nomenclatura actual con el parámetro especificado del id.

Cuando creamos controles en este caso asp.net todos por defecto deben de llevar un id.

Entonces el problema era que necesitaba asignarle un valor a un control de tipo TextBox pero el control no pertenecia a la  MasterPage sino  que era un control de una pagina que usaba la MasterPage para ello hice lo sigiuente :

 protected void Page_Load(object sender, EventArgs e)
    {
        //Buscando el control con ayuda del metodo FindControl
        Control txtMiControl = (TextBox)this.Page.Master.FindControl("MainContent").FindControl("txtNombre");

        //Validar que exista el control
        if (txtMiControl != null)
        {
            ((TextBox)txtMiControl).Text = "Hola Mundo";
        }
        else
        {
            
            //Enviar un mensaje de que el control no existe 

            this.lblMensaje.Text = "Control no encontrado.";
        }
    }

La estructura como tenia el control es la siguiente :

<%@ Page Title="" Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true" CodeFile="wfrmDemo.aspx.cs" Inherits="wfrmDemo" %>




    

Al final es cuestión de saber identificar que id usa tu control y donde esta situado , permitiéndote agregar  o modificar los valores de sus propiedades.

Saludos...

CiberAtaques

Después de haber leido el Foro de El Hacker me encanto el articulo sobre HoneyMap un mapa que muestra en tiempo real ciberataques en todo el mundo esto es atravez de los sensores 'honeypot' que simulan ser equipos vulnerables.

Después de analizar la IP ,de donde proviene el ataque, es publicada la posición en el mapa.

Fig.1 Mapa de CiberAtaques

Los puntos rojos mostrados en el mapa representan a los atacantes,mientras que los puntos amarillo son los objetivos.

Fig2.Los logs de los puntos rojos

Los mas interesante es que si pasas un buen rato viendo el mapa podrás darte cuenta de la evolución y de donde provienen mas ataques.

Saludos...

Re: Stored Procedures con parámetros

Nuestro compi de trabajo Angel Mario, en su blog, colgaba un artículo sobre como variar el uso de un montón de parámetros al condicionar una consulta de SQL.

Un montón de variables que se utilizarán para aplicar un filtro (where) a la consulta. Como ya lo mencionó en su artículo Stored Procedures con parámetros se genera un total de 2ⁿ variaciones.

Para hacerle segundilla a su artículo ;P , tenemos una manera de caer ante ver  la situación.

Utilizando las mismas tablas y parámetros de la consulta del artículo, tenemos:

SELECT * FROM bibroloperador WHERE

(BibliotecaId = @BibliotecaId OR @BibliotecaId IS NULL)

AND 

(RolId = @RolId OR @RolId IS NULL)

Se evalúa si el parámetro coincide con el campo o si el parámetro es nulo. El hecho de utilizar el operador OR nos ayuda a que la condición siempre será verdadera. Por lo tanto podrá realizarse la consulta al evaluarse el operador AND, ya que las dos sentencias siempre serán verdaderas. Esto produce que solo muestre resultados basados en el valor de (los) parámetro(s) que no sea NULL.

Quizá deberíamos evaluar cual es la mas óptima. Ya sea con "Sql dinámico", como lo mostraba Angel Mario en su artículo o de la manera en que lo presentamos aquí...

Probando con la consulta que mostramos aquí y la del artículo mencionado, respectivamente:

...pero bueno, esto realmente no nos dice mucho. Tendríamos que probar con tablas un poco mas grandes, variar los campos con índices, realizar búsquedas con campos sobre texto, etc, etc.

El asunto es que es otra opción mas a evaluar =)

Vayámonos todos!

GET vs POST

Hace poco un compi me dijo: "Si los datos son ligeros y pocos usa GET, si son pesados y demasiados usa POST" ... pero,  ¿Qué conio?.

GET y POST son "verbos" o métodos de petición (request methods), que a través del protocolo HTTP indican una acción a realizar en algún recurso que se haya identificado.

La primer diferencia entre estos dos métodos es el formato de codificación de datos, es decir, el formato de codificación enviado al recurso varia de acuerdo al método utilizado, pero no quiero mosquearme escribiendo de eso...

La recomendación (según estándares) es que se utilice GET si y solo si el proceso de formularios es idempotente... ¿ w t f ?!  

En nuestras bonitas matemáticas, la idempotencia es una propiedad que dada una acción en ocasiones repetidas se obtiene el mismo resultado que si se hubiera realizado una sola vez. En nuestro caso, no debe tomarse al pie de la letra, porque podríamos traducirlo como "El resultado de realizar muchas peticiones GET idénticas es el mismo que realizar un sola vez dicha petición"... pues no... El caso es que si la petición no causa efectos duraderos o "cambios de estado" (por ejemplo, almacenar información en una base de datos) excepto en la pantalla del usuario, deberíamos utilizar GET. Al contrario, si se desea realizar cambios duraderos, debería utilizarse el método POST.

Los navegadores por lo regular advierten al usuario que están por volver a procesar alguna solicitud "POST"  (normal que una página tenga un error y se intente regresar con el "volver" del navegador). Esto es realmente molesto, podría ocasionar un "cambio de estado", por ejemplo volver a realizar la transferencia de 1000 piedrólares de tu cuenta a la de tu abuela , o lo que sea.

Pero,  ¿La razón?

De la misma manera en que el estándar (el estándar es algo así como un todopoderoso) recomienda en que casos usar GET y en cuales utilizar POST, describe a todo detalle técnico la forma de envío de datos de ambos métodos. Sin embargo, no explica porque debe utilizarse uno y/o porque el otro... al rato termino, posteo de una vez al cabo nadie se va dar cuenta =)

Geolocalizacion en Facebook

Para muchos Facebook es  una de las redes sociales con mas impacto dentro de la sociedad moderna.
Con solo preguntarnos  ¿Quién no usa Facebook ?. Muchos de nosotros  la utilizamos para compartir ideas, fotos, vídeos etc...

La Geolocalización se compone de otros conceptos tales como  Georreferenciación y Geoetiquetado.


Georreferenciacioón : Define el posicionamiento con el que se define la localización de un objeto en un sistema de coordenadas.

Geoetiquetado (Geotagging): un proceso donde se agrega información geográfica en los meta datos de archivos (imágenes, vídeos,sitios,etc) que sirven para la Georreferenciación.


Entonces podríamos decir que la geolocalizacion es representar de manera gráfica y extensible la posición geográfica de un "algo" donde ese algo puede ser cualquier cosa persona, vehículo, imagen, etc...

Si bien es cierto cuando nosotros estamos en nuestro perfil pasamos muchas cosas por desapercibido pero no con esto quiero decir que la mayoría que usamos Facebook no lo notemos, pues bien cuando uno se conecta a su perfil este registra el lugar de donde haz iniciado sesión, el explorador que haz usado junto con el sistema operativo que haz utilizado para acceder a tu perfil.

Cada geolocalización cambiará dependiendo del sistema operativo y el explorador  utilizado, como se muestra

Esto también pasa con las publicaciones que hacemos

Pero te as de preguntar como es posible todo esto pues bien existen varias maneras de geolocalizarte una de ellas es tu dirección IP con la que te conectas a Internet.

Otra manera de es atravez del GPS(Global Positioning System) de tu móvil ,muchas veces dentro de nuestros dispositivos tenemos activo el GPS y esto conlleva a cuando realizamos publicaciones se indexen datos en imagenes,comentarios me refiero a  los datos de los datos que como ya mencione y el resultado es la Geoetiquetado.

La Triangulacion de ante nenas de redes de celulares que es la mas distribuida pero la menos usada por el costo y esto hace que no sea muy accesible (Red 3G).

Pues ya lo sabes si quieres que tu novia o novio  celoso(a) te encuentre fácilmente no olvides en encender el  GPS de tu celular.
Solo queda comentar que la privacidad es tuya y tu solo sabes con quien compartes tu geolocalizacion.

Saludos...