Migrar de Indy9 a Indy10 en Codegear C++

Hace algunos años que utilizo este componentse desde que empecé a trabajar con el viejo Borland C++ Builder ( Indy8 ). El problema es que, cuando quieres actualizarte a Indy10, te encuentras con que en esa versión han reorganizado la mayoría de las clases y han reescrito parte de los interfaces… además la documentación clara escasea y más aún los ejemplos en C++.

En mis periplos para traducir clientes y servidores escritos en Indy9 tuve que consultar gran variedad de foros y recursos on-line, pero hubo uno que me resultó especialmente útil ya que enumeraba los principales cambios de una versión a otra.

Por si resulta de utilidad a alguien, dejo aquí el  resumen de diferencias principales:

• POP3->MaxLineLength  ahora es Pop->IOHandler->MaxLineLength 
• wsOK movido, ahora se usa IdIMap4  
• Pop3.Connect(Timeout) se divide en dos nuevos comandos ( ya no permite indicar timeout en el constructor ), ahora se usa Pop3->ConnectTimeout = TimeOut; y Pop3->Connect() 
• StoredPathName desaparece, camgiado TIdAttachment to TIdAttachmentFile
• POP->Capture(Dest) ahora es POP->IOHandler->Capture(Dest) 
• Parámetros de OnWork y OnProcessWork cambiados, cambiado el parámetro const int a int64 ( no const)
• EIDSocketError desaparece , usar IdStack 
• CommaSepaeratedToStringList desaparece, ahora se usa IdGlobalProtocols
• TIdText desaparece, añadido IdText
•  Dentro de TIdTCPServer los eventos OnConnect y OnExecute cambian sus parámetros TIdPeerThread a TIdContext ( un concepto distinto )

Quien quiera puede leer el artículo original aquí ( he añadido algúa nota que no aparecía en él ): Artículo original ( en inglés )

Supresión de errores en PHP empeora el rendimiento

Cualquier desarrollador PHP sabe que el rendimiento no es el punto fuerte e este lenguaje, no obstante la comunidad ha ido aportando grandes mejoras versión tras versión ( precompilado, optimización, etc ).

No es cuestión de derrochar recursos porque sí... es bueno estar abiertos a esos pequeños tips que nos enseñan con poco esfuerzo a ahorrar preciosos ciclos de reloj que en un proyecto grande pueden significar la diferencia entre algo razonable y algo insoportable.

Y he aquí la curiosidad: el magnífico sistema de supresión de errores en PHP ( incluir una arroba "@" antes de la instrucción que se desea silenciar )  es un auténtico caníbal silencioso de CPUs.  En algunos artículos acusan a esta directiva de provocar hasta un 40% de retardo adicional.

En este otro enlace muestran una sencilla prueba de 10.000 iteraciones con y sin prefijo "@", el resultado parece muy claro, hasta 10 veces más lento:

0.010571002960205 microsegundos con supresión de errores ( @instrucción )
0.002446174621582 microsegundos en ejecución normal

Desde que conozco esta información, como es de esperar, he eliminado la supresión de errores de mis algoritmos, no he percibido la diferencia de forma subjetiva, pero no pongo en duda lo que parece claro.

Y ahora queda una duda ¿qué hacemos con los posibles errores que pueden surgir si no hacemos uso de la supresión de errores?. Creo que sólo hay una respuesta... aplicar un control de errores más estricto prestando especial atención a las excepciones inesperadas en instrucciones básicas. Las buenas prácticas lo requieren.

Cuidado con las contraseñas

El otro día un compañero me pasó este enlace a una aplicación que busca hashes MD5 en varias bases de datos. Ya había visto sistemas de este tipo, pero la verdad es que esta vez me impresionó por la cantidad de cadenas que indexa (me desveló combinaciones como m00nwalker ,marta16 ó enunlugardelamancha ).

Si alguien consiguiera extraer miles de passwords de algún portal o red social (como ocurrió hace poco en linkedin) y los procesara con una herramienta de este calibre ( o más potentes, algo probable en el futuro) seguro que podría desenmascarar entre el 10% y el 20% de las claves, y eso son muchos fraudes en potencia.

¿Qué podemos hacer para que nuestros datos estén a salvo? Yo recomendaría al menos seguir estas sencillas buenas costumbres:

• Usar claves distintas para cada web (o al menos distinguir entre dos o tres distintas), así si nos roban una clave no podrán acceder a todas nuestras cuentas.
• Combinar mayúsculas, minúsculas y números intentando usar algún truco mnemotécnico para no olvidarla, pero no ser muy evidentes ( por ejemplo pEPit000, 30m30NA, etc... )
• Si el sistema lo permite, añadir símbolos ( "_" "-" "@" )
• Cambiar las claves cada cierto tiempo es una excelente costumbre.
• Destruir cookies al cerrar una sesión, sobre todo usando un ordenador público o una conexión WIFI poco segura.

Muchas de estas medidas pueden parecer incómodas, pero es muy sencillo de cumplir y nos puede evitar más de un dolor de cabeza.  La verdad es que como desarrollador he comprobado por mí mismo la cantidad de usuarios que utilizan claves del tipo "micasa" ó "123456" quedando totalmente expuestos al primer hackercillo de fin de semana. Estas claves son el equivalente a guardar la llave del coche en el parabrisas o la de casa debajo del felpudo.

Url del buscador MD5:
http://www.tmto.org/pages/passwordtools/hashcracker

Usar servidor proxy para cambiar ip externa

Si desarrollas aplicaciones cliente-servidor necesitarás realizar pruebas emulando un entorno real... En la realidad el cliente debería estar en una parte del mundo lejana al servidor.
Cuando hacemos pruebas con el servidor y el cliente en la misma red local, incluso aunque usemos la Ip externa, el router nos redireccionará por red interna de forma transparente, y eso tirará por tierra nuestro intento de emular ese entorno real.

Para solucionarlo podemos usar Proxifier, una excelente aplicación que permite conectar con cualquier servidor proxy y así salir con otra IP ( excelente también para quien quiera, por ejemplo, navegar de forma anónima ).


- Descarga e instala la aplicación (click aquí ).

- Busca una lista de servidores proxy gratuítos

- Ejecuta el programa y ve a Profile > Proxy Servers

- Añade ahí el servidor que prefieras.


Así de fácil estaremos conectados mediante el proxy remoto y tendremos una IP pública distinta, pudiendo probar nuestras aplicaciones en un entorno parecido al real.

Codegear XE : Compilar sin librerías dinámicas

Hoy en un foro de C++ Builer que suelo visitar he encontrado una duda muy habitual de cualquier programador que empieza con este IDE.

Cuando genera una aplicación win32 el compilardor por defecto lo hace usando librerías dinámicas, de tal forma que ese ejecutable queda muy liviano pero no funcionará en ninguna máquina si no se adjuntan dichas librerías ( ningún Windows las trae de serie ).  El resultado es que la aplicación no se ejecuta y a cambio nos obsequia con una colección de molestos mensajes pidiendo nosecuantas librerías .bpl

Normalmente queremos generar ejecutables que funcionen de forma autónoma, por lo menos en producción. Para ello debemos modificar las siguientes opciones:

- Project > Options > C++ Linker > ( Desmarca la opción "Link with Dynamic RTL" )

- Project > Options > Packages > ( Desmarca la opción "Build with runtime packages" )

Así el ejecutable resultante aumentará de tamaño considerablemente, pero funcionará
en todas las plataformas windows sin necesidad de librerías especiales de builder.

Restringir puertos por ip en linux

Una de las principales cuestiones cuando administras un servidor web basado
en linux es discriminar accesos a puertos para establecer una política
de seguridad adecuada.

Muchas veces necesitamos discriminar accesos por ip. Por ejemplo, quiero
que el servicio MySQL (normalmente puerto 3306) sea accesible sólo por aplicaciones
locales pero también desde la ip de mi servidor de backups...

Hay muchas maneras de hacer esto en linux, la mas sencilla mediante iptables.
Aquí pongo un ejemplo de restricción de puerto sólo para ip local (127.0.0.1) y
para una supuesta ip de servidor de backups (sustituir con nuestra ip).

iptables -A INPUT -s {ip-servidor-backups} -p TCP --dport 3306 -j ACCEPT
iptables -A INPUT -s 127.0.0.1 -p TCP --dport 3306 -j ACCEPT
iptables -A INPUT -s 0.0.0.0/0 -p TCP --dport 3306 -j DROP

Dudas resueltas: C++ FAQ

Mi trabajo me obliga a compaginar muchas tareas y roles distintos (si estás en el sector del desarrollo de aplicaciones esto te resultará familiar).

Por esa razón cuando toca picar código es necesario tener siempre a mano información de consulta rápida para el lenguaje o la disciplina de turno.  Es vital si tu cabeza está en varios asuntos a la vez y además necesitas producir código aceptable en cortos periodos de tiempo.

Hoy he encontrado una página fantástica para añadir a mi colección, se trata de un FAQ de C++ al que he llegado de casualidad.  Me ha parecido una lista muy completa, bien explicada y además está ilustrada con cientos de ejemplos.

Enlace en inglés: C++ FAQ (click aquí)