Para obtener el dato desde VFP basta este pequeño bloque:

En PHP podriamos hacer algo como:

Según Wikipedia, FastCGI es un protocolo para interconectar programas interactivos con un servidor web. FastCGI es una variación de la ya conocida Common Gateway Interface (CGI o Interfaz Común de Entrada); El principal objetivo de FastCGI es reducir la carga asociada con el hecho de interconectar el servidor web y los programas CGI, permitiéndole a un servidor atender más peticiones a la vez.

Esto es útil en diversos escenarios:

• Supongamos que estas realizando un proyecto en el que constantemente creas, modificas y eliminas archivos, añades recursos, carpetas, etcétera.
• Tu carpeta de música es actualizada constantemente con nuevas canciones, portadas de discos, nuevas metatags…

Una vez que lo que hay ahí se vuelve importante, querrás respaldarlo y haras una copia de ello. Pero con el paso del tiempo necesitaras actualizar esta copia y tendrás problemas para recordar lo que haz cambiado desde la última vez, y respaldarlo todo cada vez puede ser un proceso que tome mucho tiempo.

Create Synchronicity es la solución para mantener una copia de tus archivos segura en otro sitio (una USB, otro disco local o en la intranet).

Si no conoces spotify y no sabes que es la función radio, checalo en agseso.

La licencia básica de TokuDB es gratuita y permite administrar hasta 50 GB de datos (antes de compresión). Para bases de datos más grandes, la licencia Standard cuesta 1000 USD (anuales) por cada 100 GB, hasta 5 TB.

Solo esta disponible para Linux.

Desde el “Antiguo y abandonado blog de Ricardo Galli” es posible descargar el código fuente (GPL) para generar los mapas de acceso web que funcionaban en ese blog.

Poco a poco fui concentrando en una sola cuenta todos mis mensajes, evitando tener que ir a las diferentes bandejas de entrada a leerlos, aunque mantenia mis propios servicios de correo en los dominios que poseía, hasta ahora.

Pero vayamos por partes. La primera vez que compre un dominio fue a mediados de 2001 para un negocio que tenia entonces y el sitio duro lo mismo que el negocio… pasaron unos años antes de que me decidiera a incursionar de nuevo en esto y en diciembre de 2006 compre trozosdecodigo.com junto con algunos otros nombres para diferentes proyectos que tenia entonces. En estos años he desarrollado algunos sitios, media docena de proyectos han visto la luz y han muerto al demostrar ser inviables mientras algunos dominios han estado durmiendo el sueño de los justos por más tiempo del que deberían.

Como consecuencia natural de mi actividad web ocasionalmente necesito algún correo para un dominio en particular, y con el tiempo son cada vez más.

A mediados de 2009 me vi en la necesidad de contratar mi primer servidor dedicado (hasta ese momento me bastaba con el uso de espacios compartidos) para tener más libertad a la hora de desarrollar, pero al final del día resulto contraproducente ya que, al haber yo contratado un servidor administrado, estaba a merced del soporte de la compañía de host para realizar cualquier tarea de mediana importancia. Finalmente, un año y casi tres mil dolares después decidí migrar todo a la nube y ver que pasaba… y no paso nada, salvo que me ahorre casi 200 dolares al mes.

Ahora tengo configurado un pequeño servidor con lo que necesito, y a la hora de hacer pruebas o enfrentar requerimientos especiales simplemente monto otro servidor para eso y lo uso lo justo.

La parte negativa de todo esto es el correo electrónico, ya que cada vez que te cambias de servidor hay que reconfigurar todo y las migraciones son tediosas y en ocasiones provocan que pierdas mensajes importantes, además de que cada servicio requiere cierto mantenimiento (aunque sea mínimo). Como complicación adicional, no acabo de conocer completamente el panel de control que estoy usando, por lo que la configuración de IMAP y POP3 para mis correos no acaba de quedar en mi servidor base, lo que representa una pequeña incomodidad que me obliga otra vez a entrar en varias cuentas cada día (justo como era hace casi 5 años).

Ante este inconveniente, he decidido alojar mis correos electrónicos en Apps de Google, en su versión estándar que es ideal para pequeñas organizaciones que no requieren muchas cuentas.

Los pasos a seguir para hacer esto son simples:

1. Crear una cuenta en Apps de Google
2. Acreditar la propiedad del dominio mediante la creación de un registro CNAME
3. Configurar 7 entradas MX hacia los servidores de correo de Google (si existe la opción de configurar el host, dejarlo en blanco)
4. Configurar una entrada CNAME al subdominio en que quieras revisar tu correo
5. Configurar una entrada SPF que herede la configuración de Google [v=spf1 include:_spf.google.com ~all]
6. Se pueden validar la entrada SPF con esta herramienta y los registros DNS en general con esta.

Una vez configurado todo, tengo una cuenta de gmail bajo mi propio dominio, y la próxima vez que necesite migrar un sitio solo me preocupare por mantener en algún lugar mis registros DNS (si muevo mi servidor).

…ahora que lo he migrado completamente a la nube…