Development

What is JSON?

JSON (JavaScript Object
Notation – Notación de Objetos de JavaScript) es un formato ligero de intercambio
de datos. Leerlo y escribirlo es simple para humanos, mientras que para las
máquinas es simple interpretarlo y generarlo. Está basado en un subconjunto del
Lenguaje de
Programación JavaScript
, Standard ECMA-262 3rd
Edition – Diciembre 1999
. JSON es un formato de texto que es completamente
independiente del lenguaje pero utiliza convenciones que son ampliamente
conocidos por los programadores de la familia de lenguajes C, incluyendo C,
C++, C#, Java, JavaScript, Perl, Python, y muchos otros. Estas propiedades
hacen que JSON sea un lenguaje ideal para el intercambio de datos.

JSON es un subconjunto de
la notación literal de objetos de JavaScript que no requiere el uso de XML.

La
simplicidad de JSON ha dado lugar a la generalización de su uso, especialmente
como alternativa a
XML en AJAX. Una de las supuestas
ventajas de JSON sobre
XML como formato de
intercambio de datos en este contexto es que es mucho más sencillo escribir un
analizador semántico de JSON. En JavaScript, JSON puede ser analizado
trivialmente usando el procedimiento
eval(), lo cual ha sido
fundamental para la aceptación de JSON por parte de la comunidad de
desarrolladores Ajax, debido a la ubicuidad de JavaScript en casi cualquier
navegador web.

En la
práctica, los argumentos a favor de la facilidad de desarrollo de analizadores
o del rendimiento de los mismos son poco relevantes, debido a las cuestiones de
seguridad que plantea el uso de
eval() y el auge del
procesamiento nativo de XML incorporado en los navegadores modernos. Por esa
razón, JSON se emplea habitualmente en entornos donde el tamaño del flujo de
datos entre cliente y servidor es de vital importancia (de aquí su uso por
Yahoo, Google, etc, que atienden a millones de usuarios) cuando la fuente de
datos es explícitamente de fiar y donde no es importante el no disponer de
procesamiento XSLT para manipular los datos en el cliente.

Si bien es
frecuente ver JSON posicionado contra XML, no es infrecuente el uso de
JSON y XML en la misma aplicación. Por ejemplo, una aplicación de cliente que
integra datos de
Google Maps con datos
meteorológicos en
SOAP hacen necesario
soportar ambos formatos.

Cada vez hay
más soporte de JSON mediante el uso de paquetes escritos por terceras partes.
La lista de lenguajes soportados incluye
ActionScript, C, C#, ColdFusion, Common Lisp, E, Java, JavaScript, ML, Objective CAML, Perl, PHP, Python, Rebol, Ruby, y Lua.

En Diciembre
de 2005
Yahoo! comenzó a dar soporte
opcional de JSON en algunos de sus
servicios web

El término
JSON está altamente difundido en los medios de programación, sin embargo, es un
término mal descrito ya que en realidad es solo una parte de la definición del
estándar ECMA-262 en que está basado Javascript. De ahí que ni Yahoo, ni Google
emplean JSON, sino LJS. Una de las cualidades intrínsecas de Javascript
denominada LJS (Literal Javascript)facilita el flujo de datos e incluso de
funciones, para la cual no requiere la función
eval() si son datos los que
se transfieren como en el caso de xml. Todo lo referente a transferencia de
datos en todos sus tipos, incluyendo arrays, booleans, integers, etc. no
requieren de la función
eval(), y es precisamente en eso en
donde supera por mucho JavaScript al XML, si se utiliza el LJS y no la
incorrecta definición de JSON.

Uso de JSON

En teoría, es
trivial analizar JSON en JavaScript usando la función
eval() incorporada en el
lenguaje. Por ejemplo:

miObjeto = eval('(' + json_datos + ')');

En la
práctica, las consideraciones de seguridad por lo general recomiendan no usar eval
sobre datos crudos y debería usarse un analizador JavaScript distinto para
garantizar la seguridad. El analizador proporcionado por JSON.org usa
eval() en su función de
análisis, protegiéndola con una expresión regular de forma que la función sólo
ve expresiones seguras.

YAML es un superconjunto
de JSON que trata de superar algunas de las limitaciones de éste. Aunque es
significativamente más complejo (
[1]), aún puede
considerarse como ligero. El lenguaje de programación
Ruby utiliza YAML como el
formato de
serialización por defecto. Así pues, es posible manejar JSON con bastante sencillez.

YAML es un formato de serialización de datos legible por humanos inspirado en lenguajes
como
XML, C, Python, Perl, así como el formato para correos
electrónicos especificado por el
RFC 2822. YAML fue propuesto
por
Clark Evans en 2001, quien lo diseñó
junto a
Ingy döt Net y Oren Ben-Kiki.

YAML es un acrónimo recursivo que significa "YAML Ain’t Another Markup
Language (en castellano, "YAML no es otro
lenguaje de marcado"). A comienzos de su
desarrollo, YAML significaba "Yet Another Markup Language"
("Otro lenguaje de marcado
más") para distinguir su propósito centrado en
los datos en lugar del marcado de documentos. Sin embargo, dado que se usa
frecuentemente XML para serializar datos y XML es un auténtico lenguaje de
marcado de documentos, es razonable considerar YAML como un
lenguaje de marcado ligero.

YAML fue
creado bajo la creencia de que todos los datos pueden ser representados
adecuadamente como combinaciones de listas,
hashes (mapeos) y datos
escalares (valores simples). La sintaxis es relativamente sencilla y fue
diseñada teniendo en cuenta que fuera muy legible pero que a la vez fuese
fácilmente mapeable a los tipos de datos más comunes en la mayoría de los
lenguajes de alto nivel. Además, YAML utiliza una notación basada en el
indentado y/o un conjunto de caracteres Sigil distintos de los que se usan en
XML, haciendo que sea fácil componer ambos lenguajes.

· 
Los contenidos en YAML se describen utilizando el conjunto de caracteres
imprimibles de
Unicode,
bien en
UTF-8
o
UTF-16.

·  La estructura del documento se
denota indentando con espacios en blanco; sin embargo no se permite el uso de
caracteres de tabulación para indentar.

JSON
está constituído por dos estructuras:

  • Una
    colección de pares de nombre/valor. En varios lenguajes esto es conocido
    como un objeto, registro, estructura, diccionario, tabla hash,
    lista de claves o un arreglo asociativo.

  • Una
    lista ordenada de valores. En la mayoría de los lenguajes, esto se
    implementa como arreglos, vectores, listas o sequencias.

En JSON, se
presentan de estas formas:

Un objeto
es un conjunto desordenado de pares nombre/valor. Un objeto comienza con
{ (llave
de apertura)
y termine con } (llave de
cierre)
.
Cada nombre es seguido por
: (dos puntos) y los pares
nombre/valor están separados por
, (coma).

Un número
es similar a un número C o Java, excepto que no se usan los formatos octales y
hexadecimales.

Una cadena
de caracteres
es una colección de cero o más caracteres Unicode, encerrados
entre comillas dobles, usando barras divisorias invertidas como escape. Un
carácter está representado por una cadena de caracteres de un único carácter.
Una cadena de carateres es parecida a una cadena de caracteres C o Java.

Los espacios
en blanco pueden insertarse entre cualquier par de símbolos.

Exceptuando
pequeños detalles de encoding, esto describe completamente el lenguaje.

JSON vs XML:

XML, es un lenguaje de
intercambio de información estructurada desarrollado por la
W3C, con la poposición de
ser un estandard entre diferentes plataformas, desde bases de datos, editores
de texto,…

Es una
tecnología sencilla y fácil de entender, además se aplica un razonamiento
lógico a su estructura.

<menu id="file" value="File">
  <popup>
    <menuitem value="New" onclick="CreateNewDoc()" />
    <menuitem value="Open" onclick="OpenDoc()" />
    <menuitem value="Close" onclick="CloseDoc()" />
  </popup>
</menu>

Por otro lado
JSON está pegando fuerte
en la programación web debido a
las ventajas que
ofrece
sobre el XML.

JSON es un subconjunto de
la notación literal de objetos de Javascript pero no requiere el uso de
Javascript.

A simple
vista, la facilidad que conlleva el uso de JSON en comparación con la
laboriosa tarea de recorrer un XML, por ejemplo para
trabajar con Ajax, es uno de los
motivos por los cuales los desarrolladores están volcando sus esfuerzos en esta
herramienta de intercambio de datos.

{"menu": {
  "id": "file",
  "value": "File",
  "popup": {
    "menuitem": [
      {"value": "New", "onclick": "CreateNewDoc()"},
      {"value": "Open", "onclick": "OpenDoc()"},
      {"value": "Close", "onclick": "CloseDoc()"}
    ]
  }
}}
 
XML ejemplo:
 
<widget>

    <debug>on</debug>

    <window title="Sample Konfabulator Widget">

        <name>main_window</name>

        <width>500</width>

        <height>500</height>

    </window>

    <image src="Images/Sun.png" name="sun1">

        <hOffset>250</hOffset>

        <vOffset>250</vOffset>

        <alignment>center</alignment>

    </image>

    <text data="Click Here" size="36" style="bold">

        <name>text1</name>

        <hOffset>250</hOffset>

        <vOffset>100</vOffset>

        <alignment>center</alignment>

        <onMouseUp>

            sun1.opacity = (sun1.opacity / 100) * 90;

        </onMouseUp>

    </text>

</widget>
 
El mismo ejemplo en JSON
 
{"widget": {
    "debug": "on",
    "window": {
        "title": "Sample Konfabulator Widget",

        "name": "main_window",

        "width": 500,

        "height": 500
    },

    "image": {
        "src": "Images/Sun.png",
        "name": "sun1",

        "hOffset": 250,

        "vOffset": 250,

        "alignment": "center"
    },

    "text": {
        "data": "Click Here",
        "size": 36,
        "style": "bold",

        "name": "text1",

        "hOffset": 250,

        "vOffset": 100,

        "alignment": "center",
        "onMouseUp": "sun1.opacity = (sun1.opacity / 100) * 90;"
    }
}}

Como
problemas, los desarrolladores experimentados encuentran que la utilización de
eval() para para analizar JSON
es algo delicado y puede atentar la seguridad del sitio.

var http_request = new XMLHttpRequest();
 var url = "http://example.net/jsondata.php";
 // Esta URL debería devolver datos JSON
 
 // Descarga los datos JSON del servidor.
 http_request.onreadystatechange = handle_json;
 http_request.open("GET", url, true);
 http_request.send(null);
 
function handle_json() {
  if (http_request.readyState == 4) {
    if (http_request.status == 200) {
      var json_data = http_request.responseText;
      var the_object = eval(”(” + json_data + “)”);
    } else {
      alert(”Ha habido un problema con la URL.”);
    }
    http_request = null;
  }
}

Obsérvese que
el uso de XMLHttpRequest en este ejemplo no es compatible con todos los
navegadores, aunque existen variaciones sintácticas para
Internet Explorer, Opera, Safari, y navegadores basados en Mozilla.

También es
posible usar elementos
<iframe> ocultos para
solicitar los datos de manera asíncrona, o usar peticiones
<form
target="url_to_cgi_script" />
. Estos métodos eran los más
habituales antes del advenimiento del uso generalizado de XMLHTTPRequest.

Si bien los
defensores de JSON a menudo notan que éste es más abreviado que XML, obsérvese
que los dos ejemplos tienen unos 190 caracteres cuando se eliminan los espacios
en blanco. Además, el uso de compresión GZIP para enviar los datos al navegador
puede reducir la diferencia de tamaños entre ambos formatos. De hecho, cuando
se usa GZIP sobre los ejemplos anteriores el ejemplo en XML es más pequeño por
6 bytes. Si bien esto no es concluyente, muestra que es necesario experimentar
con el conjunto de datos a tratar para determinar qué formato será más
eficiente en términos de tamaño. JSON no es siempre más pequeño que XML.

El beneficio
de JSON, entonces, no es que sea más pequeño a la hora de transmitir, sino que
representa mejor la estructura de los datos y requiere menos codificación y
procesamiento.

XML goza de
mayor soporte y ofrece muchas más herramientas de desarrollo (tanto en el lado
del cliente como en el lado del servidor). Hay muchos analizadores JSON en el
lado del servidor, existiendo al menos un analizador para la mayoría de los
entornos. En algunos lenguajes, como Java o PHP, hay diferentes
implementaciones donde escoger. En JavaScript, el análisis es posible de manera
nativa con la función
eval(). Ambos formatos carecen de un
mecanismo para representar
grandes objetos binarios.

Con
independencia de la comparación con XML, JSON puede ser muy compacto y
eficiente si se usa de manera efectiva. Por ejemplo, la aplicación
DHTML de búsqueda en BarracudaDrive recibe los listados
de directorio como JSON desde el servidor. Esta aplicación de búsqueda está
permanentemente consultando al servidor por nuevos directorios, y es
notablemente rápida, incluso sobre una conexión lenta.

Los entornos
en el servidor normalmente requieren que se incorpore una función u objeto
analizador de JSON. Algunos programadores, especialmente los familiarizados con
el lenguaje
C, encuentran JSON más
natural que XML, pero otros desarrolladores encuentran su escueta notación algo
confusa, especialmente cuando se trata de datos fuertemente jerarquizados o
anidados muy profundamente.

Hay más
comparaciones entre JSON y XML en esta
página de ejemplo (en inglés).

Por estos
motivos y algunos más,
se plantean debates y se intenta decidir cual es la forma correcta
de intercambiar información
.

Development

Writing Quality Code – La calidad del software y el código fuente

Siempre he
sostenido que la calidad del software empieza por la calidad del código fuente.
Basta observar unas cuantas líneas de código de un proyecto, de unos cuantos
archivos de código elegidos al azar para saber mucho sobre la calidad
del proyecto en general. Es impensable que con código de mala calidad se
pueda construir buen software. Microsoft tiene gente investigando sobre la
relación que existe entre la calidad del software y la calidad del código
fuente y sobre la importancia del código fuente de calidad.

Hay dos
interesante videos en los que se trata el tema:

En el primero,
Khaled El Eman, de la Universidad de Otawa, habla sobre el retorno de la
inversión del código fuente de calidad
. Es curioso como se puede llegar
a cuantificar en unidades monetarias la calidad del código en los proyectos.
Además este autor tiene un libro que parece interesante sobre el tema del video
The
ROI from Software Quality
.

En el software, la
calidad, no es opcional

El problema
que se presenta es que existen empresas, donde  sus jefes no perciben la calidad como algo
importante, es más importante para ellos tener un mayor número de características
que un software de mayor calidad. El razonamiento es simple, la
calidad no se puede poner en un anuncio o en una oferta. Esta mentalidad podría
ser razonable para muchos productos, pero no lo es para el software.
Trataré de explicar el por
qué.

Si tu
produces, por poner algo simple, bolígrafos, puedes decidir que tu segmento del
mercado es el de los bolígrafos baratos, de baja calidad. Y sin duda te puede
ir muy bien, no todo el mundo necesita un pluma Du Pont, para firmar su
hipoteca. Tendrás un motón de clientes que solo ven en el momento de la compra
de un bolígrafo su precio, y que además en el momento de la compra no van a
evaluarlo a fondo. Además, reducir la calidad, en el caso de la gran mayoría de
los productos manufacturados, tiene el efecto directo de abaratar los costos de
producción. Muchos de los directivos actualmente al mando de empresas que
construyen software han sido formados en sectores ajenos a la informática, una
industria muy nueva, y a menudo caen en el error de pensar en la producción de
software desde los parámetros habituales en otras industrias. Este es un error
habitual, la producción de software es muy diferente, es un proceso creativo no
un proceso manufacturero.

La principal
diferencia cuando ‘fabricamos’ software es que la calidad no es
opcional, no puedes elegir fabricar software de baja calidad y rebajar el
precio
.
Ese enfoque no funciona por varios motivos:

Primero:
Puedes hacer bolígrafos de baja calidad que hagan su labor aceptablemente, pero
no puedes hacer software de baja calidad que funcione y cumpla su misión
aceptablemente. Además, los usuarios cada vez son menos tolerantes con los
errores en las aplicaciones. Pensemos en cómo ha evolucionado la calidad del
software que todos tenemos en común, el sistema operativo. Todos recordamos las
pantallas azules de la muerte de Windows NT, alguna vimos en 2000 y luego llego
Windows XP y la mejora fue notable. Lo mismo ha ocurrido en otros sistemas
operativos, como Linux, donde cada vez es más difícil ver un Kernel Panic. Al
ser el sistema operativo el software que todos usamos, es el que se convierte
en patrón
de calidad

Con Windows
95 no era importante que nuestros programas ‘cascasen’ con cierta frecuencia,
el usuario estaba acostumbrado a que el sistema operativo fallase y era más o
menos permisivo con nuestros fallos. Con la mejora de la calidad de los sistemas
operativos el usuario está subiendo el listón de la calidad y si queremos
seguir vendiendo nuestro software más que el de la competencia la calidad del
mismo se está convirtiendo en un factor vital.

Segundo:
Antes de comprar un software o contratar la realización del software con una compañía
de desarrollo, el usuario comparará a fondo. Y a menudo el precio no es el
factor principal. Nunca venderemos un software si el instalador de nuestra demo
falla con solo ejecutarlo con un usuario que no es administrador, por m
ás
barato que sea, el usuario no se va a tomar un segundo más en seguir
evaluando nuestro software. Ni venderemos un proyecto de desarrollo si a los oídos
del comprador llega una mala experiencia de una empresa que nos contrato con
anterioridad, por  más económica que sea
nuestra oferta. Solo centrándonos en la calidad lograremos evitar este tipo de
problemas. Nadie recuerda quien hizo un buen software, pero nadie olvida quien
hizo uno que no funciona correctamente porque lo sufre a diario.

Tercero: Quizá
el factor más importante y menos evidente es el de  añadir calidad a nuestro software, al
contrario de lo que puede parecer a primera vista, reduce los costes de
desarrollo y acorta los plazos. La reducción de costes se produce con un
adecuado proceso de desarrollo, que tenga la calidad del software como un
factor central, y se descubren antes los errores. Y los errores, de cualquier índole,
son más costosos cuanto más tarde se descubren, además estos coste se
incrementan siguiendo una función exponencial. Descubrir que nuestra Arquitectura
no es capaz de gestionar el número requerido de transacciones por segundo, es
infinitamente más costoso de corregir si se descubre durante las pruebas de
aceptación que durante la revisión de la arquitectura. La reducción del tiempo
de desarrollo se produce porque es mucho más fácil construir software sobre
software estable que sobre software que no es estable. Hoy en día todos los
procesos de desarrollo de software son en mayor o menor medida iterativos e
incrementales. Es imposible construir un incremento de funcionalidad si la base
de ese incremento no es estable.

Dicho esto,
es curioso ver las situaciones paradójicas que se dan en cuanto a la calidad en
los proyectos y las empresas de desarrollo de software.
Existen empresas con grandes carteles en recepción del estilo "La
calidad es nuestra esencia"
o "La calidad al servicio
del cliente
" y con todas las certificaciones habidas y de por haber de
‘calidad’ que no tienen ni un solo especialista en calidad del software, ni un
solo especialista en probar aplicaciones. ¿Se imaginan una empresa industrial,
que se tome en serio el mantenimiento de sus maquinas, sin un solo experto en
mantenimiento?, pues esto es la norma en las empresas de desarrollo, dicen
preocuparse por la calidad pero no cuentan con un solo experto en el tema. Y
no, lo desarrolladores, no son expertos en calidad y pruebas. ¿Por qué se dan
estas paradojas en el desarrollo de software?

"La
manera más rápida y económica de desarrollar software es hacerlo bien".

Creo que
mientras quien este al mando de las empresas de desarrollo no hayan sido
previamente desarrolladores la situación no cambiará. Construir software es
algo radicalmente diferente a construir cualquier otro producto, pero los
gestores ser resisten a verlo. Por eso seguimos sufriendo intentos fallidos de
formalizar el desarrollo de software, como RUP
o CMMI, sin dejar parcela a la
creatividad. Se tiende al olvidar que desarrollar software es esencialmente ‘diseño’
y no ‘construcción’. Cada línea de código que escribe un desarrollador en una
decisión de diseño.

La crisis de
software se da en dos puntos:

-el
programador conformista (nunca se pregunta como optimizar o mejorar lo que hace,
solo si funciona, dejémoslo así).

-el jefe que
sabe más chatear que de arquitectura de software.

Temas Relacionados:

Guidelines for Conducting Design and Code Reviews

Proporciona
varias técnicas para realizar la revisión del diseño y del código a fin de
descubrir errores y supuestos incorrectos solicitando a sus homólogos que
revisen el código.

Guidelines for Writing Secure Code

Describe
técnicas y estrategias para escribir código seguro.

Guidelines
for Checking in Quality Code

Muestra
instrucciones para comprobar el código de maneras diferentes a fin de
garantizar que incorpora lo que estaba previsto en el diseño de calidad.

Guidelines for Debugging

Proporciona
varias instrucciones para encontrar defectos de código.

Guidelines
for Using Code Analysis Tools

Proporciona
varias instrucciones para utilizar las herramientas de análisis de código.

Detecting
and Correcting C/C++ Code Defects

Describe cómo
detectar y corregir defectos de código utilizando la herramienta de análisis de
código para C/C++.

Detecting
and Correcting Managed Code Defects

Describe cómo
detectar y corregir defectos de código utilizando la herramienta de análisis de
código para código administrado.

Code Analysis Check-in Policies

Describe cómo
crear directivas de protección personalizadas asociadas con las protecciones de
control de código fuente de Team Foundation.

Code Analysis for Managed Code Overview

La
herramienta de análisis de código para el código administrado analiza los
ensamblados administrados y muestra información sobre dichos ensamblados, como
las infracciones de las reglas de programación y diseño estipuladas en las
Instrucciones de diseño de Microsoft .NET Framework.

 Integración del entorno de desarrollo integrado
(IDE)

Para que el
uso de la herramienta de análisis resulte más cómodo a los desarrolladores,
éstos pueden seleccionar Habilitar análisis de código en
las Páginas de propiedades del proyecto.

Desde las
páginas de propiedades se puede tener acceso, además, a otras opciones para
incluir o excluir reglas, así como para tratar las reglas como advertencias o
errores. Cuando la herramienta está habilitada, registra las advertencias en la
Lista de errores durante el proceso de generación.

Supresión en el código fuente

Con
frecuencia resulta de gran utilidad indicar que una advertencia no es de
aplicación; de este modo, se informa al desarrollador (y a otras personas que
puedan revisar el código más adelante) de que se ha investigado ya una
advertencia y que se ha suprimido u omitido.

La supresión
de advertencias en el código fuente se implementa mediante atributos
personalizados. Para suprimir una advertencia, agregue el atributo SuppressMessage al código fuente como se muestra en el
ejemplo siguiente:

[SuppressMessage("AdventureWorks.Rules",
"AW14441")]

Public class MyClass

{

    // code

}

Integración
de Team System y Team Build

Puede
utilizar las características integradas del sistema de generación para ejecutar
la herramienta de análisis como parte del proceso de generación.

Conclusión:

Utilice las
herramientas de análisis de código.

Realice una
revisión de seguridad.

Valide todos
los datos introducidos por los usuarios.

Valide
perfectamente todos los parámetros de las interfaces de programación de
aplicaciones (API) exportadas.

 Utilice las API criptográficas de Windows.

Escriba pruebas unitarias.

Conozca cómo
recuperar una pila dañada.

Se debe evitar

Las
saturaciones del búfer.

Las
características sin una especificación.

Suponer que
las pruebas encontrarán todos los errores.

Se
recomienda

Revise todos
los defectos de seguridad anteriores de la aplicación.

Revise todas
las rutas de acceso a errores.

Escriba las
pruebas unitarias antes de escribir el código.

Escriba
código portable a otras plataformas.

Recorra paso
a paso todas las rutas de acceso de código en un depurador.

Aprenda a
depurar aplicaciones multiproceso.

Aprenda a
realizar depuraciones remotas.

Aprenda a
depurar en servidores activos.

Analice el
código que se está desarrollando.

Realice el
seguimiento de las advertencias

No se
recomienda

Privilegios
de administrador para que se ejecute la aplicación.

Informática e Internet

26 DE ENERO ENCUENTRO CON ESPECIALISTAS MICROSOFT 2008

ENCUENTRO CON ESPECIALISTAS MICROSOFT
2008

SistemasUNI tiene el agrado de
invitarlos al “Primer encuentro con especialistas

Microsoft 2008” a realizarse el Sábado
26 de Enero a las 10:00AM – 05:00PM, en el Auditorio de la Facultad UNI FIIS ,
Av. Túpac Amaru 210 – Rimac – Alt. Puerta 5 de la UNI Teléfonos: Directo:
3813851 – 3824832 – Central 4811070 Anexos: 569-408

Ha llegado el día en el que los
profesionales desarrollen todo su potencial, un evento diseñado en función a
sus necesidades específicas, ven y comparte  excelentes presentaciones de
temas de actualidad en el campo del Desarrollo y la Ingeniería de Software, realizadas
por EXPERTOS que trabajan día a día con la tecnología y  los temas que
expondrán.

Solamente contenido de alto nivel, todo
el conocimiento que se puede esperar de Trainers y consultores 
profesionales con amplia experiencia en los temas que nos mostrarán. Este
evento está dirigido a profesionales del software en general: jefes de
proyectos, analistas de sistemas, desarrolladores,  consultores,
arquitectos, ingenieros de software y público interesado.


Agenda del Evento:


10:00
AM-11:00AM – Overview Visual Studio 2008

En febrero será una fecha importante para Microsoft. Ese día será cuando se
lance oficialmente Windows Server 2008, SQL Server 2008 y Visual Studio 2008,
aplicaciones en su mayor parte destinadas a las empresas y que marcan un ciclo
importante de actualizaciones. En esta charlaveremos la novedades de Visual
Studio 2008, revisaremos la integración de ASP.NET AJAX y AJAX Extenders, como
el soporte para WPF & SilverLight.

Expositor: Alonso Morales Salazar(MCP, Microsoft
Application Developer MCAD, MCTS) Consultor de Sistemas con más de 6 años de
experiencia en tecnologías Microsoft. Ha desarrollado sistemas informáticos
relacionados con la gestión administrativa de empresas desde hace más de 10
años. Ha utilizado diferentes herramientas de desarrollo y tecnologías, desde
programación en Clipper con redes Novell, Visual Basic,.Net Framework 1.0 y
.Net Framework 2.0
 
11:00-AM-12:00PM
– Nuevas tendencias en el Acceso a datos

Las Tendencias significativas en la tecnología y la industria han cambiado de
una manera fundamental la manera en que se desarrollan las aplicaciones. Las
aplicaciones de línea de negocio (Line of Business – LOB) que se construían
hace 10-20 años como monolitos alrededor de un sistema de gestión de bases de
datos relacionales deben ahora conectarse con otros sistemas y producir y
consumir datos desde las más disímiles fuentes. Los procesos de negocio han
dejado de ser semi-automatizados y ahora son autónomos. Las Arquitecturas
Orientadas a Servicios (Service Oriented Architectures – SOA) introducen nuevos
requisitos de consistencia y coordinación. Los servicios de datos de más alto
nivel, como la generación de informes, minería de datos, análisis,
sincronización e integración compleja han dejado de ser cosas esotéricas y
ahora se utilizan comúnmente.A la llegada del lanzamiento de Visual Studio 2008
Conoceremos las tendencias tecnológicas para el acceso y explotación de datos
desde los lenguajes de programación hacia  los repositorios de información
,analizaremos la evolución de las tecnologías de acceso a datos, los retos,
nuestro escenario actual y tecnologías como ORM, LinQ, ADO.NET Entity
Framework, ADO NET Data Services (Conocido como Astoria)


Expositor: Carlos Chávez Villafuerte(MCT, MCP,
MCAD, MCSD .NET, MSF Practitioner, MCTS, Oracle Implementation Champion en
PeopleSoft, Comptia CTT+). Consultor de Sistemas con más de 10 años de
experiencia, especialista en Tecnologías Microsoft. Carlos trabaja actualmente
como Arquitecto de Software en el TACP (Touring y Automovil Club del
Peru)  y como Microsoft Certified Trainer [MCT] en el  CPLS de la
Universidad Nacional de Ingeniería.Carlos es también difusor de Tecnologías
Microsoft a través de eventos en comunidades de usuarios. Su campo de
investigación es la Ingeniería de Software y la implementación de buenas
prácticas y patrones en diseño en la construcción de software de
calidad.Expositor:

Expositor: Juan Pablo MestasMicrosoft Andean
Speaker, Orador Regional INETA, Culminis Speaker, MCTS Web, MCTS Win, MCTS SQL
2005, MCAD .NET, MCP, DCE2005 5 Estrellas, SCJP J2SE, ITIL FoundationConsultor
en Sistemas con varios años de experiencia en el desarrollo e implementación de
soluciones empresariales, sobre las plataformas Java y .Net, enfocándose en las
tareas de arquitectura, el uso de patrones de software, buenas practicas y
guías del Secure Development Lifecycle (SDL).  Actualmente su enfoque
principal esta en la Arquitectura de Soluciones distribuidas, bajo el modelo
propuesto por SOA, utilizando  WS-*, WCF, WF y participa como consultor en
la mejora de procesos para la entrega de servicios TI, bajo el marco de ITIL.
Miembro del Microsoft Andean Speaker Framework, Orador Regional de INETA y del
programa Culminis Speaker, participando como expositor frecuente en eventos
profesionales y académicos, sobre Tecnologías Microsoft, especializandose en la
plataforma .Net y el Desarrollo con SQL Server

12:00PM-01:00PM
Diseño Físico de un Servidor de Base de Datos SQL Server 2005

El diseño físico de un servidor de base
de datos requiere tomar en consideración muchos aspectos y asegurarse que cada
decisión del diseño se integre correctamente con las demás. La primera sección
se enfoca en el diseño del almacenamiento de los archivos de datos en el
servidor. La segunda sección se enfoca en el diseño físico del hardware del
servidor, ésta incluye puntos como discos, interfaces, buses y niveles de RAID.

Expositor: Alan Ferrándiz Langley Analista
desarrollador de sistemas, especialista en SQL Server y desarrollo Web con ASP
NET.
Alan es miembro del IEEE (Institute of Electrical and
Electronics Engineers) y cuenta con las siguientes certificaciones
internacionales: Microsoft Certified Trainer (MCT) desde el año 2003, MSF
Practitioner, Microsoft Certified Application Developer (MCAD), Microsoft Certified
Solution Developer (MCSD), Microsoft Certified Database Administrator (MCDBA),
Microsoft Certified Technology Specialist MCTS (SQL Server 2005), Microsoft
Certified IT Professional MCITP (SQL Server 2005 Database Developer &
Database Administrator), CIW Certified Instructor, CIW Certified Professional,
Master CIW Designer, IBM XML Certified Developer.

 

01:00PM-02:00PM 
RECESO

02:00PM-03:00PM
Windows Vista Deployment tools and technologies

La nueva versión de Windows, denominada "Windows Vista", es un sistema
operativo  que tiene un gran potencial y está pensado para ofrecer una
experiencia más segura, más fiable y de mayor potencial; los usuarios pueden
utilizar los equipos con mayor eficacia y confianza.Windows Vista establece un
nivel de confidencialidad en tu PC y tu habilidad de tener la mayoría de ello,
introduce claras formas de organizar y usar la información.En esta charla se
mostrará todo el potencial de Windows Vista así como sus características mas
novedosas. 


Expositor Renato Alcantara Q.Es Microsoft
Certified Trainer [MCT] y (MCT MCSA, MCSA +S ,MCSE ,MCSE +S, MCTS: Windows
Vista)Consultor de Sistemas con mas de 3 años de experiencia en el campo de
Diseño, Implementación y Administración de Redes Microsoft, actualmente se
desempeña como Ingeniero de Infraestructura. labora en el CPLS de la
Universidad Nacional de Ingeniería (UNI-FIIS).

03:00PM-04:00PM
– Desarrollo de Aplicaciones Móviles con los Mobile Application Blocks de
P&P


El Mobile Client Software Factory de
patterns & practices es una colección de MobileApplication Blocks, guías al
desarrollador y y herramientas que facilitan a los desarrolladores móviles
abordar escenarios complicados como la sincronización de datos, trabajar
desconectado de una red, la autenticación y la encriptación de datos. Las
aplicaciones que construya utilizando el MCSF están construidas generalmente en
base al Mobile Composite UI Application Block (Mobile CAB). El Mobile CAB es
relativamente difícil de adoptar, pero puede utilizar los otros application blocks
independientemente del Mobile CAB en todos sus desarrollos de aplicaciones
móviles.


Expositor: Ricardo Daniel Masabel Avendaño (MCP,
MCTS Windows Mobile Mobile 5.0 Application) Consultor de Sistemas con 3 años de
experiencia en .NET. Actualmente trabaja desarrollando aplicaciones de soporte
a negocios utilizando tecnología .NET 2.0 (2005). Ricardo Es especialista
certificado en aplicaciones móviles como MCTS Windows Mobile, Microsoft
Certified Professional y MCP en desarrollo de Aplicaciones Web y Windows, ambos
con VB .NET. Interesado en temas relacionados a buenas prácticas de
arquitectura, diseño y desarrollo .Actualmente se encuentra enfocado en el
desarrollo de aplicaciones WinForms de tipo Smart Client y también es difusor
de tecnologías Microsoft a través de eventos en comunidades de usuarios.
 
04:00PM-05:00PM
– Diseño Avanzado Olap en Analysis Services 2005

En esta charla se abordarán las mejoras
que nos brinda Analysis Services 2005 con respecto al diseño avanzado Olap,
como son el diseño y optimización de agregaciones, uso del query log para la
optimización basada en el uso, implementación de acciones estándares, reportes
enlazados y drillthrough.


EXPOSITOR: Nicolás Fernando Nakasone Roque(MCTS
SQL SERVER 2005 Business Intelligence) Es consultor e instructor en
Inteligencia de Negocios. Expone regularmente sobre Metodologías de
Datawarehouse, Datamart y Datamining en eventos y Talleres en Universidades e
Institutos Tecnológicos. Ha desarrollado importantes implementaciones de
Inteligencia de Negocios, desempeñándose como Arquitecto de Datawarehouse y
ETL, Datamart-Olap y Datamining Percepton Multilayer – Redes Neuronales tanto
en el sector gubernamental como privado.


05:00PM-5:15PM  CIERRE DEL EVENTO

Development

Programming the web.config File Using C#

The Configuration API in ASP.NET 2.0

The configuration API of ASP.NET 2.0 adds a great level of
flexibility in that it allows us to add or edit a configuration file seamlessly
in ASP.NET. The WebConfigurationManager class in the System.Web.Configuration
namespace has the OpenWebConfiguration method that can be used to open the
configuration file of the application as a Configuration object for reading
from or writing to the configuration file. The virtual path to the
configuration file is specified to this method as a parameter. The following
code snippet displays all the keys of the appSettings section of the web.config
file:

 

Configuration configuration = WebConfigurationManager.OpenWebConfiguration("~");

 AppSettingsSection
appSettingsSection =

  (AppSettingsSection)configuration.GetSection("appSettings");

 if (appSettingsSection !=
null)

  {

   foreach (string key in
appSettingsSection.Settings.AllKeys)

    {

      Response.Write(key);

    }

  }

 

The following method can be used to modify a specific key —
value pair of the web.config file — programmatically using C#:

 

public void Modify(string key, string value)

{

Configuration configuration = WebConfigurationManager.OpenWebConfiguration("~");

AppSettingsSection appSettingsSection =
(AppSettingsSection)configuration.GetSection("appSettings");

   if (appSettingsSection != null)

   {

       appSettingsSection.Settings[key].Value =
value;

       configuration .Save();

   }

}

 

The following method can be used to delete a specific key
in the web.config file programmatically using C#:

 

public void Remove(string key)

{

Configuration configuration =
WebConfigurationManager.OpenWebConfiguration("~");

AppSettingsSection appSettingsSection =
(AppSettingsSection)configuration.GetSection("appSettings");

  if (appSettingsSection
!= null)

  {

     appSettingsSection.Settings.Remove(key);

     configuration .Save();

  }

}

 

Conclusion

Even if modifying a web.config file programmatically can
be a handy solution in some situations, it is not recommended to do so
frequently in a Web application, as any change in the web.config file will restart
the Web server and refresh the cache entries.

Development

Carga de archivos en ASP.NET 2.0 – tips

Limitaciones de tamaño de archivos

Quizás no lo note, pero existe un límite para el tamaño de los archivos que se pueden cargar mediante esta técnica. El límite predeterminado para los archivos que se cargan en el servidor con el control FileUpload es alrededor de 4 MB. No se puede cargar nada que supere ese límite.

Una de las grandes virtudes de .NET, no obstante, es que suele ofrecer alguna forma de superar las limitaciones. Por lo general, se puede modificar la configuración predeterminada. Para cambiar el límite de tamaño, debe realizar algunos cambios en el archivo web.config.comments (ubicado en la carpeta de configuración de ASP.NET 2.0, C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG) o web.config de su aplicación.

En el archivo web.config.comments, busque el nodo <httpRuntime>, que es similar a éste:

<httpRuntime

 executionTimeout="110"

 maxRequestLength="4096"

 requestLengthDiskThreshold="80"

 useFullyQualifiedRedirectUrl="false"

 minFreeThreads="8"

 minLocalRequestFreeThreads="4"

 appRequestQueueLimit="5000"

 enableKernelOutputCache="true"

 enableVersionHeader="true"

 requireRootedSaveAsPath="true"

 enable="true"

 shutdownTimeout="90"

 delayNotificationTimeout="5"

 waitChangeNotification="0"

 maxWaitChangeNotification="0"

 enableHeaderChecking="true"

 sendCacheControlHeader="true"

 apartmentThreading="false" />

En este nodo ocurren muchas cosas, pero la configuración que se encarga del tamaño de los archivo que se cargan es el atributo maxRequestLength. El valor predeterminado es 4096 kilobytes (KB). Simplemente modifique el valor para aumentar el tamaño límite. Si desea poder cargar archivos de 10 megabytes (MB) en el servidor, configure el valor maxRequestLength en 11264, lo cual significa que la aplicación permitirá cargar archivos de hasta 11.000 KB.

Este cambio en el archivo web.config.comments aplica la configuración a todas las aplicaciones del servidor. Si desea aplicarla sólo a la aplicación con la que está trabajando, aplique este nodo en el archivo web.config de su aplicación reemplazando la configuración del archivo web.config.comments. Asegúrese de que este nodo se encuentre entre los nodos <system.web> del archivo de configuración.

Otra configuración involucrada en la limitación de tamaño de los archivos es el valor del atributo executionTimeout del nodo <httpRuntime>

El valor del atributo executionTimeout es la cantidad de segundos de carga permitidos antes de que ASP.NET la termine. Si permitirá cargar archivos más grandes, deberá incrementar este valor además del de maxRequestLength.

Una desventaja de aumentar el tamaño permitido es que hay piratas informáticos que atacan servidores enviándoles una gran cantidad de solicitudes. Para protegerse de esto, puede reducir el tamaño permitido o, de lo contrario, descubrirá cientos y hasta miles de solicitudes de 10 MB en el servidor.

Validación en el cliente de los tipos de archivos que se pueden cargar

Existen varios métodos para controlar los tipos de archivos que se pueden cargar en el servidor. Desafortunadamente, ninguno es infalible para protegerlo de la carga de archivos malintencionados. Sin embargo, existen pasos para simplificar un poco este proceso de permitir que los usuarios finales carguen archivos.

Un buen método es utilizar los controles de validación ASP.NET incluidos de forma gratuita con ASP.NET. Estos controles permiten realizar comprobaciones de expresiones regulares en los archivos cargados para ver si la extensión está permitida.

Esto es ideal para los exploradores que permiten el uso de controles de validación por parte de los clientes ya que obliga al cliente a realizar la comprobación y el archivo no se carga en el servidor si la firma no está permitida. En el listado 3 se muestra un ejemplo de uso de los controles de validación para llevar esto a cabo.

 

  Nota:

Aquí no se explica el uso de controles de validación. Consulte Validating ASP.NET Server Controls (en inglés) para obtener una explicación completa de los controles de validación y cómo utilizarlos en las páginas de ASP.NET.

 

Esta sencilla página de ASP.NET utiliza controles de validación para que el usuario final sólo pueda cargar archivos .mp3, .mpeg o .m3u en el servidor. Si se trata de otro tipo de archivo, un control Validation inicia una excepción en la pantalla. Esto se muestra en la figura 4.

 

 

Los controles Validation no son un método infalible para controlar qué archivos se cargan en el servidor. No es demasiado difícil sortear este sencillo modelo de seguridad. Basta con modificar la extensión de un archivo para que se lo acepte y se cargue en el servidor.

Validación de tipos de archivos en el servidor

Acaba de ver una forma sencilla de agregar controles de servidor de validación ASP.NET en su página de ASP.NET para que el cliente valide las extensiones de archivos (en forma de texto). Ahora veamos cómo realizar una operación similar en el servidor. Esto se muestra en el listado.

Listado 4. Comprobación del tipo de archivo en el servidor

 protected void btnUplaod_Click(object sender, EventArgs e)
    {
        StringBuilder sbServerPath = new StringBuilder(280);
        StringBuilder sbInfo = new StringBuilder(870);

        if (fuCustom.HasFile)
        {
            #region hasfile
            string fileExt = Path.GetExtension(fuCustom.FileName);

            sbServerPath.Append(Server.MapPath(VirtualPath));
            sbServerPath.Append(fuCustom.FileName);

            if (fileExt == ".mp3" || fileExt == ".mpeg")
            {
                try
                {
                    fuCustom.SaveAs(sbServerPath.ToString());
                    sbInfo.Append("File Name: ");
                    sbInfo.Append(fuCustom.PostedFile.FileName);
                    sbInfo.Append("<br>");
                    sbInfo.Append(fuCustom.PostedFile.ContentLength);
                    sbInfo.Append(" Kb <br>");
                    sbInfo.Append("Content Type: ");
                    sbInfo.Append(fuCustom.PostedFile.ContentType);

                    lblInfo.Text = sbInfo.ToString();
                }
                catch (Exception ex)
                {
                    lblInfo.Text = "Error: " + ex.Message;
                }
            }
            else
            {
                lblInfo.Text = "Only .mp3 and .mpeg files allowed!";
            }
            #endregion
        }
        else
        {
            lblInfo.Text = "You have not specified a file.";
        }
    }

 
Ahora, al utilizar el método GetExtension del espacio de nombres System.IO.Path, puede básicamente llevar a cabo la misma operación. Es importante señalar que esto no evita que el usuario final pueda modificar la extensión del archivo y cargarlo en el servidor de alojamiento.

Carga simultánea de varios archivos

Hasta aquí, hemos visto buenos ejemplos de cómo cargar un archivo en el servidor sin grandes inconvenientes. Ahora veamos cómo cargar en el servidor varios archivos de una misma página.

Microsoft .NET Framework no posee una función que permita cargar varios archivos desde una página de ASP.NET. De todas formas, con un poco de trabajo se puede lograr fácilmente al igual que en el pasado al utilizar .NET 1.x.

La clave es importar la clase System.IO en su página de ASP.NET y luego utilizar la clase HttpFileCollection para capturar todos los archivos enviados junto al objeto Request. Esto permite cargar todos los archivos que uno desee de una misma página.

protected void btnFileUploads_Click(object sender, EventArgs e)

{

StringBuilder sbServerPath = null;

HttpFileCollection uploadedFiles = Request.Files;

StringBuilder sbInfo = new StringBuilder(780);

for (int i = 0; i < uploadedFiles.Count; i++)

{

HttpPostedFile userPostedFile = uploadedFiles[i];

sbServerPath =

new StringBuilder(280);

sbServerPath.Append(Server.MapPath(VirtualPath));

try

{

if (userPostedFile.ContentLength > 0)

{

sbInfo.Append(

"<u>File #");

sbInfo.Append(i + 1);

sbInfo.Append(

"</u><br>");

sbInfo.Append(

"File Content Type: ");

sbInfo.Append(userPostedFile.ContentType);

sbInfo.Append(

"<br>");

sbInfo.Append(

"File Size: ");

sbInfo.Append(userPostedFile.ContentLength);

sbInfo.Append(

"kb <br>");

sbInfo.Append(

"File Name: ");

sbInfo.Append(userPostedFile.FileName);

sbInfo.Append(

"<br>");

sbServerPath.Append(

Path.GetFileName(userPostedFile.FileName));

userPostedFile.SaveAs(sbServerPath.ToString());

sbInfo.Append(

"Location where saved: ");

sbInfo.Append(Server.MapPath(VirtualPath));

sbInfo.Append(

Path.GetFileName(userPostedFile.FileName));

}

}

catch (Exception ex)

{

lblInfo.Text =

"Error: " + ex.Message;

}

}

}

 

 usuario final puede seleccionar hasta cuatro archivos y hacer clic en el botón Cargar archivos, que inicializa el evento btnFileUploads_Click. Utilizar la clase HttpFileCollection con la propiedad Request.Files permite controlar todos los archivos cargados de la página. Cuando los archivos se encuentran en este estado, puede hacer lo que quiera con ellos. En este caso, las propiedades de los archivos se examinan y se escriben en la pantalla. Finalmente, los archivos se guardan en la carpeta Uploads del directorio raíz del servidor. En la figura 5 se ilustra el resultado de esta acción.