Tareas en un proyecto

Toda tarea completamente definida dentro de un proyecto debe tener definido:

• Un título que la defina lo suficiente para que, cuando se presente de manera independiente, se ubique de manera rápida y sencilla dentro del contexto del proyecto.  Además, deberá iniciar con un verbo en infinitivo, algo así como crear, desarrollar, modificar…
• Una descripción que permita entender lo que la tarea implica (en otro post definimos esto).
• Un único responsable, este puede cambiar en cualquier momento, pero siempre debe haber una sola persona como responsable.
• Una duración de tiempo estimada, que podría ser necesario ajustar cuando el responsable de la actividad cambie, dependiendo de cosas como la experiencia, habilidades, dominio del tema, etc.
• Un alcance claramente definido, esto podría incluirse dentro de la descripción, pero igualmente lo declaro como.
• Una definición de la forma en la que se validará que la tarea esté completa.

Más adelante, incluiré las razones por las que es importante incluir cada uno de los puntos anteriores

 

Este blog se muda

La nueva dirección para este blog es:

http://www.insesys.com.mx

Allí seguiré con las anotaciones que por aquí se muestran

10 puntos para tomar en cuenta en el web config

En esta dirección está el post original que ahora anexo en español tomado de aquí:

1. Custom Errors deshabilitado. En el archivo Web.config de nuestras aplicaciones ASP.NET la etiqueta custom Errors se encuentra comentada por defecto cuando creamos una nueva aplicación, esto deja el valor RemoteOnly por defecto. Sin embargo muchas veces cuando estamos probando el software en un servidor remoto hay ocasiones en las que por comodidad dejamos el valor en Off, esto permite a todos los usuarios que ingresan a las páginas de la aplicación enterarse de los errores que suceden en la aplicación, al momento de depurar. Sin embargo esto no es bueno al momento de desplegar, puesto que cualquiera puede también ver pedazos de código cuando hay alguna falla. Lo más adecuado es prender la opción, lo cual puedes aprovechar para mostrar errores más amigables al usuario, esto incluso te sirve para optimizar para buscadores ;-). Un ejemplo de cómo prender esta opción es el siguiente:
   <customErrors mode="On">
<error statusCode="404" redirect="default.aspx" />
</customErrors>
2. Dejar habilitado el seguimiento de la página. El seguimiento de página (tracing) normalmente se encuentra apagado, sin embargo también por cuestiones de depuración puede encenderse, la forma más sencilla es hacerlo en el archivo que estemos trabaando utilizando la etiqueta Trace en la declaración de página del formulario en el que estamos trabajando, sin embargo una buena práctica es hacerlo de modo sólo local (por si necesitamos que el seguimiento esté de todos modos encendido) desde el archivo Web.config y luego apagarlo al desplegar, hacerlo de esta manera encenderá el seguimiento en todos los formularios del proyecto y evitará que se nos olvide apagarlo, lo haces con la etiqueta trace de la siguiente manera:
   <trace enabled="true" traceMode="SortByTime" localOnly="true" />
3. Depuración habilitada. Tener esta opción habilitada, afecta al rendimiento de la aplicación, muestra errores más detallados y sólo debe encenderse mientras estamos desarrollando precisamente para el proceso de depuración, la forma correcta de desplegar es dejando en el archivo Web.config la opción de depuración apagada, otra buena práctica en el caso de las aplicaciones ASP.NET creadas con Visual Basic es dejar las opciones explicit y strict encendidas, de este modo hacemos código mejor construído (léase 100 veces: no garantiza que perfectamente construído, pero ayuda). La forma de configurar esto es de la siguiente manera:
   <compilation debug="true" strict="true" explicit="true"/>
4. Cookies suplantables. Los hackers pueden realizar ataques de XSS (Cross Site Scripting) cuando las cookies son accesibles del lado del cliente, intentan este tipo de ataques cuando se encuentran por ejemplo con saludos del tipo Hola ChicoDotNet en las páginas en la que se inicia sesión agregando su propio código del lado del cliente. Esto puedes dificultarlo fácilmente -valga la redundancia- cuando enciendes las cookies HttpOnly, esto se hace de la siguiente forma:
   <httpCookies httpOnlyCookies="true" />
5. Sesión sin cookies. Para hacer disponible una aplicación a los clientes que no aceptan cookies se tiene la opción de colocar la sesión en la URL, muchos las utilizan por defecto para no complicarse asignando a la etiqueta sessionState el atributo cookieless con el valor UseUri, sin embargo esto abre la posibilidad de suplantar a un usuario determinado visitando la dirección que contiene la sesión, esto puedes evitarlo almacenando la sesión en una cookie que expire pronto, pero queda el problema de los clientes que no aceptan cookies, para ellos necesitas enviar la sesión en la URL, ¿Cómo resolver eso?, enciende la autodetección, eso hará que los clientes que las acepten las usen y los que no las reciban en la URL, se hace con el siguiente código en Web.config:
   <sessionState cookieless="AutoDetect" />
6. No emitir cookies seguras. Las cookies seguras se emiten utilizando SSL, esto hace que la transmisión se realice en forma encriptada, para configurar SSL en IIS puedes ver el artículo en MSDN que te indica como hacerlo en IIS 6.0, en el caso de IIS 7.0 es mucho más sencillo como ya había mencionado anteriormente. Para la configuración de la transmisión de las cookies por medio de SSL utiliza el siguiente código:
   <authentication mode="Forms">
<forms requireSSL="true" />
</authentication>
7. Sesiones alargables. Para alargar el tiempo de expiración de una sesión se utiliza el atributo slidingExpiration de la etiqueta forms, esto da mayor tiempo a los hackers para suplantar a un usuario determinado, la recomendación es dejarlo como se indica a continuación:
<forms slidingExpiration="true" />.
8. Uso de cookies de autenticación por defecto. El nombre por defecto de una cookie de autenticación es .ASPXAUTH, una buena práctica es nombrar estas de manera distinta, por ejemplo utilizando un GUID, de esta manera evitamos que alguien que se firme en una aplicación del servidor y pueda modificar la cookie para firmarse en otra utilizando la primera cookie obtenida. Este valor se pondría en el lugar que indico a continuación:
   <authentication mode="Forms">
<forms name="{80aae8ec-cee2-46bc-ba57-eb89cd3db488}" requireSSL="true" />
</authentication>
9. Paso de variables por URL. El uso de Request.Querystring(«variable») para operaciones de negocios debe ser evitado, sobre todo si se trata de información sensible, se debe preferir el uso de variables de sesión o de ViewState, de otro modo cualqueir persona con algo de conocimientos de programación podría hacer ataques de XSS o de SQL injection.
10. Credenciales o cadenas de conexión en Web.config. Esto es lo más común de la lista, debe evitarse a toda costa el guardar usuarios y contraseñas en etiquetas credentials y cadenas de conexión o configuraciones de aplicación en Web.config sin antes cifrarlas adecuadamente. O. K., IIS evita la descarga de estos archivos de forma remota, pero ¿Qué me dicen de los del hosting? Hay que tener mucho cuidado con esto.

Código Samurai

Al ver este artículo me acordé de muchas situaciones curiosas desarrollando sistemas.
Aunque me gusta mas la versión en inglés, presento la versión en español para los que así lo prefieran.

Inglés: http://wilshipley.com/blog/2005/02/free-programming-tips-are-worth-every.html

Español:  http://zumodewiki.wordpress.com/2007/08/03/el-codigo-samurai-como-programar-mejor/

En resumen, puedo decir que hacen mucho énfasis en lo que la experiencia nos hace entender, la importancia de:
«Pensar y repensar» antes de tirar código.
Entender exactamente que estamos haciendo.
Hacer versiones del mismo proyecto, antes de hacer el proyecto final
Hacer código mantenible.
No dejar cosas para después. (Mi padre decía que no hay mañana y hasta ahora el mañana aún no llega, comienzo a pensar que tiene razón)
Programar pensando que las cosas alrededor de nuestro sistema puede fallar (red, bd, el usuario, etc…)

Hay muchas otras cositas escondidas que leyendo la versión en inglés seguro captarán.

Como ejecutar un comando msdos desde SQL

Existe un store procedure con el que se puede ejecutar una instrucción msdos desde sql. Se hace de esta forma:

exec master.dbo.xp_cmdshell ‘dir c:\ /b’

Esto nos entregará en forma de tabla el listado de la unidad c:\
De esta forma podríamos accesar archivos de un directorio y procesarlos de alguna forma en un store procedure:

set @query =’master.dbo.xp_cmdshell «dir c:\Directorio\ /b»‘
insert #x exec (@query)

Mas información útil en: http://www.insesys.com.mx

Como evitar el uso de cursores en Store procedures

Para evitar el uso de cursores se pueden crear tablas temporales con un campo identity.  Despues se puede usar esta tabla temporal para recorrerla en un ciclo usando el identity para identificar el registro que se requiere.   Un ejemplo de esto sería:

— Primero llenamos la tabla temporal  (#x) nuestra consulta principal
select identity(int,1,1) as ID, Campos into #x from Tabla

— Preparamos las variables que nos ayudarán con el barrido.
declare @maximo int
declare @cont int
declare @Campos char(10)
set @maximo = (select max(ID) from #x)
set @cont =0

— Seguimos con el ciclo que generará el barrido.
While @cont <= @maximo
begin
   set @cont=@cont+1
   set @Campos = (select Campos from #x where [id] = @cont)
   — Aquí se ponen las operaciones que sean necesarias.
end
— Listo!

Desarrollo de programas de .NET sin Visual Studio.

Un documento interesante:

http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art58.asp

Manejo de objetos con Javascript

Me encontré un documento muy interesante acerca del manejo de objetos con javascript, visto por un desarrollador: http://msdn.microsoft.com/msdnmag/issues/07/05/JavaScript/Default.aspx?loc=es

Mas información útil en: http://www.insesys.com.mx

Framework javascript para aplicaciones RIA

En la revista .code me encontré con esta recomendación:

http://openrico.org/rico/home.page

Es un framework para javascript bastante útil, está bastante interesante y es altamente probable que en un futuro proyecto utilice el drag & drop que este framework maneja

Es open-source y está en javascript.

Actualización:  Me encontré está página con algo semejante

http://script.aculo.us/

Función para validar que un string sea una dirección de correo

Hace un rato me llegó a mi correo una función con la que se puede validar que una cadena de caracteres cumpla con el formato de cuenta de correo. Como se que en algún momento la voy a ocupar la dejo aquí como referencia:

var emailfilter=/^\w+[\+\.\w-]*@([\w-]+\.)*\w+[\w-]*\.([a-z]{2,4}|\d+)$/i
function checkmail(e){
var returnval=emailfilter.test(e.value)
if (returnval==false){
alert(«Please enter a valid email address.»)
e.select()
}
return returnval
}

Mas información útil en: http://www.insesys.com.mx