Me ha aparecido un problemica, quiero saber que día de la semana es una fecha X.

Pues bien, hay una funcion en VB (aplicable a asp y vbscript), llamada:

Weekday(date, [firstdayofweek])

Si miramos la ayuda vemos que nos pone: Returns a whole number representing the day of the week, que traducido del marciano viene a decir que devuelve un número representativo del día de la semana.

Pero tiene truco!, ya que ese numero que devuelve depende del segundo atributo, por ejemplo: Weekday(”1/12/2005″, 1) nos devolvera 5, osea, jueves ya que el 1 en la función representa al Domingo, el 2 al lunes,… y como el 1 de la función representa al domingo, pues del domingo al jueves hay… 5 diícas, por lo que si ponemos WeekDay(”1/12/2005″,2) nos devolvera…. 4!, ya que parte del segundo dia de la semana que es lunes, y del lunes al jueves hay… 4 diícas (Lunes+martes+miercoles+jueves=4).

Ah! si se omite el atributo [firstdayofweek] coge por defecto el valor de la variable vbSunday, que es 1.

• vbUseSystemDayOfWeek = 0 (el del sistema)
• vbSunday = 1
• vbMonday = 2
• vbTuesday = 3
• vbWednesday = 4
• vbThursday = 5
• vbFriday = 6
• vbSaturday = 7

Buenas a todos, desde hace ya como cosa de 1 o 2 meses, he empezado a programar en C# porque si programaba en VB.NET, como también programo a menudo en VB6, me estaba dando cuenta que no estaba realizando código 100% .NET, debido a que seguía utilizando funciones de VB6 en .NET, etc., etc. Eso si mi cambio no ha venido dado porque diga que C# es mejor que VB.NET ni nada por el estilo, sino por obligarse a uno mismo a no tener vicios de VB6 en .NET, aparte y lo más importante para ello es, que el cambio ha venido porque también se algo de Java y entonces la similitud con C#, me ayudo a verlo con mejores ojos. Bueno al grano que me estoy yendo por las ramas.
Ayer estaba intentando abrir en ADOB.Recordset, sin más para hacer unas pruebas de rendimiento con VB6 y una dll hecha en .NET expuesta en modo COM, estaba continuamente fallándome el siguiente método, porque ni me compilaba.
Rs.Open();
Entonces yo me preguntaba, porque me estará fallando este puñetero método sin VB.NET o VB6 tira hacia delante. Bien mirando un poco me fije que el Rs.Open(), tiene una serie de parámetros, que aunque no los necesite pasar porque lo creo desde cero, C# me obliga a ponerlos. Entonces listo de mí dije, pues ale, te paso lo siguiente, con todos los parámetros asignados y con null, que no tiene valor:
Rs.Open(null, null, ADODB.CursorTypeEnum.adOpenDynamic, ADODB.LockTypeEnum.adLockOptimistic, 0)
Así el compilador lo dejo pasar, obviamente, el ya se cree que tiene todos los parámetros, pero al ejecutar cual fue mi sorpresa, que dicha sentencia fallo, me decía algo así como error en los tipos, pues bien falla, porque se cree que el parámetro 1 tiene valor y no ha sido omitido como se puede, debido a que está especificado como opcional.
Pues bien, haciendo simplemente un F1 en menos de un minuto di con la solución “Type.Missing”, es para especificar que un parámetro opcional no tiene valor, entonces la sentencia me quedaría de la siguiente manera:
Rs.Open(Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing)
Así si que funciona correctamente, pero C#, como eres con el tema de no dejar pensar al compilador, lo quieres todo estrictamente, pero eso me gusta mucho, ya que me ayuda a detectar muchisimos fallos de primeras.
En fin que me vuelvo a ir por las ramas, a ver después de explicar como pasar parámetros que son opcionales a un procedimiento, ahora vamos a intentar poner un parámetro opcional en una función de C#.
Después de intentarlo, el compilador da el siguiente error:
“No se permiten especificadores de parámetros predeterminados”
Así que ya sabéis en C# no se pueden poner parámetros como opcionales en un procedimiento o función, eso si, si realmente lo queremos así, nos podemos basar en la sobrecarga y punto.
Os paso un link de una página donde pone lo que es de una forma en VB.NET es igual en C#, por si alguien se atreve a venirse al lado de C#.
http://www.harding.edu/USER/fmccown/WWW/vbnet_csharp_comparison.html
Un Saludo y hasta otra

Hola Holita,

Vamos ahora con una forma de realizar un escaneo de puertos a través de una máquina Zoombie..

Iddle Scaning

Este tipo de escaneo de puertos está pensado para evitar que el equipo escaneado detecte fácilmente quien es el verdadero origen del escaneo. Para ello se usa una máquina zombie que es la que hablará directamente con el objetivo del escaneo de puertos. Sea A el equipo que quiere realizar el escaneo, B la máquina zombie que se utilizará para realizar el Iddle Scanning y C la máquina a escanear.

Para que se pueda realizar este tipo de escaneo es necesario que el equipo B cumpla que sea predecible el número ID de fragmentación IP (IPID) que se utiliza (el algoritmo) y en segundo lugar que el volumen de tráfico que reciba sea relativamente bajo porque si no puede dar falsos positivos.

Para ello A pide a B una conexión y predicen los dos siguientes IPID. Después envía una petición SYN a C con la dirección IP spoofeada con la de B, es decir, construye un paquete de petición de conexión a C como si lo enviara B.

Si C tiene el puerto abierto entonces devolverá un mensaje SYN+ACK a B y este (B), al no haber enviado un paquete SYN previamente, devolverá un paquete RESET a C.

Si C tiene el puerto cerrado entonces devolverá un mensaje RESET y B, suponiendo que es un error lo desechará.

Una vez realizado esto, A se conectará a B y observará el IPID, si este ha subido en 2, entonces tenía el puerto abierto, de lo contrario, puerto cerrado.

Lógicamente puede haber falsos positivos, además no todas las máquinas son predecibles y siempre queda el rastro del verdadero escaneador en los logs de B.

El próximo sobre Scaneo de Puertos UDP.

Bies malignos!

Hola a todos de nuevo, después de haber cambiado mi servicio que estaba basado en WebService, de la prueba de rendimiento entre la versión 1.1 y 2.0 como describí en artículo anterior, y pasarlo a que se basará en Remoting, he realizado una prueba de estrés entre las dos aplicaciones web, la que tira contra los WebService y la que tira contra Remoting y el ganador del combate ha sido Remoting, pero no con tanta diferencia como yo me esperaba, ya que en un artículo que leí hace tiempo, eso si se refería al Framework 1.1, la diferencia era abismal, a favor del Framework 2.0, hay que decir que la comunicación Soap ha sido mejorada y que la comunicación de Remoting, yo la hago segura, así que también eso pierde rendimiento, pero al final Remoting gana.
Pero Remoting no sólo gana en rendimiento, también gana en facilidades para el programador, a la hora de pasar objetos entre un Servicio y otro, claro que para dicha facilidad no sólo es Remoting, sino que las listas genéricas también ayudan, así que quien no las conozca que se las estudie, ya que una vez que te acostumbres a ellas no habrá forma de dejarlas.
A todo esto que me estoy yendo por las ramas, voy a intentar resumen con una frase cuando utilizar WebService o Remoting. Supongamos que tenemos un bollicao que no lo vamos a compartir con nadie más y que a ti el bollicao que más te gusta es sólo de cacao, pues bien, te vas a comprar un bollicao de cacao y leche, por si algún día lo compartes con alguien, si ya sabes de antemano que nunca va a ser así. Pues con los WebService pasa lo mismo, si vas a compartir Servicios, lógicamente WebService, sino, piénsatelo dos veces, porque si lo que quieres es buen rendimiento Remoting será tú solución.
Así que la siguiente vez que programes en Servicios, piensa que es lo que quieres, comunicación conection people o los quieres para tí solitos, eses es el dilema.
Un Saludo

Otra cosica del spread, jeje. Resulta que despues de haber dado de alta una historia en un formulario, al volver a dar de alta otra cosa, (ya sabes, metes el código, y se te activa la parte de datos, donde está el spread) el scroolbar del spread se me quedaba tonto, es decir, se queda como se ha quedado anteriormente (es un spread con muuuuuuchos campos, pa variar), por lo que aunque la primera celda del spread tenga el foco, en pantalla no se ve, teniendo que mover el scrool del spread para ver la celda, lo que no mola. Es un engaño visual, porque el foco está correctamente situado.

De cara a que en diseño veas el campo que tiene el foco no tienes más que usar lo siguiente:

Me.Spread.ShowActiveCell(verticalPosition, horizontalPosition)

Donde:

verticalPosition: New vertical position of cell
horizontalPosition: New horizontal position of cell

¿Que hace el ShowActiveCell?

Según la ayuda del spread, This method scrolls the spreadsheet so that the active cell appears in the specified position of the display. For example, you may wish to move the active cell to the center of the component display, que, traducido del marciano, viene a decir que te muestra en pantalla la celda que está activa y donde tu le digas, en función de los dos parámetros.

Hay varios métodos relacionados, como el ShowCell, ShowRow, ShowColumn,… que ya comentaremos más detenidamente otro día, que me han llamado la atención, y porque al final he utilizado el ShowColum, pues se atiene mejor a lo que yo quería, …ya me conoceis :p

Hola a todos,
En este post voy a explicar, de la forma más breve posible, una prueba que he realizado con las versiones 1.1 y 2.0 de .NET.
Tenía una aplicación web, con tecnología 1.1, que junto con una capa de Negocio se comunica con un Servicio que corre en COM+ a la base de datos. La comunicación entre las distintas capas era a través de DataSets.

Por otro lado he creado la misma aplicación web, pero todo con tecnología 2.0, y he cambiado lo siguiente, en vez de que la capa de negocio se comunique con un Servicio que corre en COM+, lo haga con con un Service que corre con WebService y este a su vez se comuniquen con la base de datos.

En la siguiente imagen, lo primero perdón por como se ve la imagen, no he conseguido ponerla mejor, se muestra brevemente las arquitecturas empleadas en el ejemplo:

Pues bien el resultado de las dos pruebas es claramente superior el de la tecnología 2.0 puede que no este del todo correcto, ya lo sé, que se podría mejorar seguro que si, de echo la siguiente prueba va a ser que el Servicio en vez de ir con WebService vaya con Remoting, pero en fin, lo importante es haber mejorado el rendimiento de la versión 1.1. A continuación paso a exponer una serie de acciones que he ido implantando en la versión 2.0, para acabar consiguiente ese mejor rendimiento:
- He cambiado la comunicación entre el Servicio y la capa de negocio, para que entre ellos se pasen colecciones genéricas, en vez de DataSets, ya que los Generics, esto está contrastado en muchos artículos, tiene mejor rendimiento que no utilizarlos, y los DataSets, aparte parece que carga más cosas de las que vemos.
- La comunicación de las Reglas de Negocio con el WebService es con Soap 1.2, que se supone que es más eficiente que la versión 1.1, esto es una de las mejoras en la versión 2.0 de .NET.
- La comunicación de la aplicación web con las reglas de negocio, se hace atrevas de objetos, porque hemos demostrado que atrevas de DataSets era menos eficiente.
- La aplicación web al correr en la versión 2.0 de .NET, da mejor respuesta al usuario y parece que es más eficiente que la versión 1.1.

Bueno con esto lo voy a dejar por hoy, espero que hayáis comprendido el ejemplo y veáis los beneficios de pasar del .NET 1.1 al 2.0.
El día que tenga la misma prueba con Remoting ya comentaré los resultados.
Espero que os haya gustado, Un Saludo

NavarraDotNet no para! Según acaban de anunciar en su web, ya está ultimado el evento de la UPNA, que se realizara el 25 de Enero

Será en el edificio El Sario, donde la UNED, detras de la UPNA (la línea 5 de la villavesa os deja en la puerta), y nos hablarán de lo siguiente:

• ASP.NET AJAX Web Development
• Desarrollo de juegos con DirectX / XNA.
• Windows Workflow Foundation
• Desarrollo de la capa de negocio con Windows Communication Foundation
• Construcción del cliente rico con Windows Presentation Foundation

Los ponentes serán:

• David Salgado Bermejo, Development Advisor Microsoft Ibérica
• Carlos Segura Sanz, MVP Microsoft Office SharePoint Server, miembro de NavarraDotNET
• Iñaki Ayucar, Proyecto Simax, miembro de NavarraDotNET

Entrada gratuita previo registro, quien quiera saber más aquí esta toda la información

Vía mail me llega el siguiente aviso desde el CES (Centro de Excelencia Software), que os lo pongo tal y como me ha llegado:

CONVOCATORIA PARA CUBRIR VACANTES EN EL DISEÑO E IMPLANTACIÓN DE UNA PLATAFORMA SOFTWARE PARA DESARROLLAR Y MANTENER SERVICIOS INTERACTIVOS A TRAVÉS DE LA TELEVISIÓN DIGITAL TERRESTRE.

Los Centros de Excelencia Software de Navarra se inauguraron el 31 de octubre de 2006. Se desglosan en el Centro Java y Open Source y el Centro Microsoft .NET, respectivamente.

La titularidad de los mismos corresponde a NGA (Navarra de Gestión para la Administración, S.A) y su gestión se ha encomendado a CEIN (Centro Europeo de Empresas e Innovación de Navarra).

Uno de los servicios que desean ofrecer dichos centros es el desarrollo de proyectos piloto en los que se favorece el aprendizaje a través de la participación.

Es por ello que el Centro Java y Open Source, en su función de difusión tecnológica convoca a todas las empresas navarras del sector TIC con el fin de favorecer el aprendizaje del estándar MHP para su participación en el proyecto piloto:

DISEÑO E IMPLANTACIÓN DE UNA PLATAFORMA SOFTWARE PARA DESARROLLAR Y MANTENER SERVICIOS INTERACTIVOS A TRAVÉS DE LA TELEVISIÓN DIGITAL TERRESTRE.

Bases, contacto y condiciones de participación en www.cesnavarra.net, en el apartado de Servicios.

Otra cosica que me ha pasado. Por X razones tenía que meter un campo memo de una tabla en un informe de crystal, con la peculiaridad de que tenía que ir precedido por un texto fijo, y finalizado con la ciudad y la fecha, usea otro texto “medio” fijo.

Tenía dos posibilidades, o bien meter esas dos líneas desde vb direstamente en el campo (cosa que no me mola una mierda) o bien currarmelo en el Crystal. La opción 2 sin duda, además, pense, me curro una fórmula, donde hago algo tal que asi: texto + campo memo + texto. To feliz lo intento y… “los campos memo no pueden utilizarse en fórmulas”, mecagüensupu…

Lasai, hay solución, así que le doy la vuelta, si no puedo meter el campo memo en una fórmula, quizás me deje meterlo en un texto… y voila! funciona (v 8.0.1.0 del Crystal), quedando perfectamente diseñado.

¿Que qué es eso de meterlo en un texto? Tu pon una label en tu informe, luego añade un campo de la tabla en el informe para arrastralo poniendolo encima del label de texto, así, el crystal te los une, convirtiéndolos en una sola entidad.

Hola, hola

En el último post que puse, de hace más de un mes, vimos algunos tipos de escaneos para detectar puertos TCP abiertos, en concreto los que se hacen con SYN y con SYN + ACK.

En este post quiero poner como se realiza el descubrimiento de puertos con otro par de métodos.

Escaneo de FIN

Cuando un servidor recibe un paquete de FIN por un puerto que no está abierto, este asume que es un error del proceso de conexión del cliente y le manda una respuesta Reset, mientras que si el puerto está abierto, se asume que es un paquete perdido y se desecha silenciosamente.

Los escaners que emplean esta técnica realizan peticiones a los puertos y esperan respuestas RESET, en el caso de no recibirla se asume que en esa petición hay un puerto abierto. Este tipo de escaneo tiene un alto índice de falsos positivos debido a las latencias de la red, a que en algunas implementaciones TCP/IP no se devuelven peticiones RESET para puertos cerrados y porque simplemente los firewalls estén configurados para cortar las respuestas.

Escaneo de XMAS y NULL

Estas dos técnicas son similares a la realización de un escaneo de FIN, en el primer caso, la técnica de XMAS, se envían peticiones con todos los bits de los flags activados (ACK, FIN, RST, SYN, URG, PSH), vamos, como si se iluminara un árbol por navidad (Xmas) y en el segundo caso, la técnica NULL, se apagan todas. Los puertos que están cerrados responden con un mensaje RESET mientras que los que están abiertos desechan el paquete que es tomado como un error y no contestan. Al igual que el escaneo de FIN tienen un alto índice de falsos positivos.

Otros Escaneos y establecimiento de conexión

Para descubrir puertos TCP existen otras técnicas, como el escaneo de ACK o enviar mensajes fragmentados. La mayoría de ellas suelen estar cortadas por los firewalls y/o parcheadas por el sistema operativo. Otra de las curiosidades que existe para escanear puertos es utilizar las opciones de FTP, que permiten, en algunos casos, enviar ficheros de un servidor de origen a un tercero a través del servidor ftp. En este caso se realiza transmisión de ficheros a puertos y se miran los errores. Esto se conoce como un abuso y casi todos los servidores han capado esas opciones.

Al final, lo que está claro es que si un puerto está abierto, pues está abierto y deja establecer conexiones con lo que hacer las fases de conexión y desconexión puede perderse dentro de un log enorme. El problema son los fallos de conexión con puertos raros que si que generan alertas que llaman la atención del administrador. En muchos casos las alertas son por fallos producidos en una unidad de tiempo (5 fallos de puerto cerrado desde la misma IP en 3 segundos) o por fallos consecutivos (5 fallos en números de puertos consecutivos). Para ello, en muchos casos se busca hacer poco ruido, probar los escaneos con espacio de tiempo entre peticiones, e incluso, con listados aleatorios de puertos.

En el próximo la detección de puertos UDP y luego ya pasamos a las herramientas.

¡Bies malignos!