Hoy he ido más lejos, y lo he instalado en el servidor que tengo en Dreamhost, y como es un servidor en una empresa externa, por paranoia de la seguridad de mis datos, no he usado mi cuenta de Dropbox, sino que he creado otra cuenta, y le he compartido la carpeta que me interesa. De esta forma, si hubiera algún tipo de fuga de datos en Dreamhost, como mucho solo accederían a los contenidos de esa carpeta. Además, de paso, me he ganado otros 250Mb por el referral de invitar a esa otra cuenta

Para el caso de la instalación dentro de un VPS de Dreamhost sería muy complicado, sino fuera gracias a Marc Abramowitz, porque Dropbox está compilado con glibc 2.4, y el VPS solo tiene glibc 2.3.

Marc se ha currado unos scripts en Python que recompilan la librería glibc 2.4 y los combina (o algo así) con los de Dropbox, con lo que al final es posible ejecutar Dropbox. Dichos scripts descargan automáticamente las librerías y la última versión de Dropbox disponible. Los detalles del cómo: aquí.

Por otro lado, la forma estándar de realizar este tipo de instalación viene documentada en la wiki de Dropbox y no tiene gran dificultad:

How To Install Dropbox In An Entirely Text Based Linux Environment:

http://wiki.dropbox.com/TipsAndTricks/TextBasedLinuxInstall#HowToInstallDropboxInAnEntirelyTextBasedLinuxEnvironment

Es muy recomendable instalar también el cliente oficial CLI (command line) tal y como menciona en el artículo anterior. Es muy probable que el script falle porque requiere python 2.6,  por lo que o actualizar el python del sistema y arriesgarte a que algo deje de funcionar (¡esto no pasa con Perl! ) o hacer lo que yo hice que es bajarme otra distribución de Python 2.6, he instalarla en otra ubicación. Yo he usado ActivePython de ActiveState y he modificado los scripts para que usen esa versión.

Por otro lado, si se trata de un servidor es muy conveniente desactivar el LAN Sync del Dropbox, porque no es plan que cada pocos segundos esté haciendo broadcast buscando otros clientes de Dropbox. Esto también está explicado en el artículo de la wiki anterior, y los datos del script que hay que utilizar para ello en este artículo: http://wiki.dropbox.com/DropboxAddons/DisableLanSync

Por último, si se desea que siempre esté arrancado el cliente de Dropbox en el servidor, hay que añadir manualmente la entrada en el crontab para que se ejecute con el arranque de la máquina, o más fácil usar el cliente CLI de dropbox y teclar: dropbox.py autostart

DISCLAIMER: en los enlaces de Dropbox he puesto mi referral, si alguien quiere darse de alta a través de ese enlace, ambos ganamos 250Mb gratuitos en cada cuenta.
 

Así es como he acabado con el Python, me rindo, sigo con mi querido Perl. Y no es que Python no sea bueno, es que ya definitivamente creo que estoy viejo para aprender y tengo que sacar cosas de mi lista de procrastinación

]]> http://www.zurco.org/python-usage/feed/ 0 http://www.zurco.org/gaps-de-conocimiento-y-areas-funcionales/ http://www.zurco.org/gaps-de-conocimiento-y-areas-funcionales/#comments Sun, 07 Sep 2008 14:53:28 +0000 Antonio http://www.zurco.org/?p=87 Mi tiempo es muy limitado (como el de cualquiera), y entra en contraposición con todos los proyectos y conocimiento que me gustaría desarrollar y adquirir. Es el destino del procrastinador

Desde hace unos meses me pica el gusanillo de programar una aplicación para el iPhone, cuestión que requiere aprender Objetive-C y las APIs específicas de Cocoa, y por otro lado también llevo intento aprender a programar en Python, como alternativa a las soluciones a las que hasta la fecha he usado, siendo éstas PHP para entornos web, y Perl para scripting en general.

Si bien es cierto que me gusta mucho Perl, ya he leído lo suficiente de Python, para reconocer su superioridad, y su amplio espectro de aplicación, sustituyendo totalmente al combo del PHP+Perl (y otros más probablemente).

El problema con el que me encuentro es que a día de hoy ya tengo un "expertise" en PHP y Perl que me va a costar conseguir con Python, y en cierta forma, las áreas funcionales del desarrollo para web y para scripts las tengo cubiertas, por lo tanto, se podría decir que el aprendizaje en Python es opcional, y una mejora.

Por otro lado, en el área de desarrollo para iPhone - y casi por similitud en Mac OSX - no tengo ni la base mínima.

Entonces, pensando en un esquema de un árbol de soluciones o áreas funcionales, que tienen que ser cubiertas con distintos "approachs", aunque éstos no sean los más apropiados u óptimas, me he autoconvencido para postergar mi aprendizaje de Python y enfocar los esfuerzos a Objetive-C y Cocoa.

De esta forma, dentro del marco que "todo me atrae", cubro más áreas funcionales, y experimento en áreas distintas. Aunque siempre llegará alguien que me dirá, "quién mucho abarca poco aprieta"

Por esa razón me he lanzado a comprar la estupenda tercera edición de "Learning Python" de Mark Lutz y editado por O'Reilly. Espero que con este libro el aprendizaje se me haga menos duro

Llevo leídas un poco más de 50 páginas y lo cierto es que no me arrepiento porque la lectura es muy fluida y cada uno de los conceptos es explicado de forma generosa, por lo que aparentemente de momento promete bastante. De hecho, algunos detalles de Python que desconocía me han sorprendido, como la portabilidad de los byte codes entre cualquier plataforma, y la facilidad para distribuir versiones paquetizadas de tus aplicaciones en Python, algo que sin embargo, en Perl requiere productos de terceros y hasta la fecha todos comerciales.

Cada día estoy convencido de que la decisión de evolucionar de Perl a Python ha sido la decisión correcta, y eso que aun no se hacer nada más del típico "Hello World!"

¡Estoy hasta emocionado!, como le decía a mi amigo Marino por el IM.

Lo cierto es que ya he subido mi primera "aplicación" - el Hello World! de rigor - a http://antonio.appspot.com y todo con una sencillez singular.

Para poder empezar a desarrollar e incluso subir aplicaciones es necesario descargarse el SDK del Google App Engine, que te instala todas las herramientas necesarias, el servidor local para las pruebas y la utilidad para actualizar las aplicaciones entre otras.

El proceso de subir una aplicación ya creada es trivial, como se puede observar:

iMac-24:GoogleAppEngine antonio$ appcfg.py update helloworld/

Loaded authentication cookies from /Users/antonio/.appcfg_cookies

Scanning files on local disk.

Initiating update.

Cloning 1 application file.

Uploading 1 files.

Closing update.

Uploading index definitions.

Sirva como advertencia que a día de hoy no es posible eliminar ni cambiar el nombre o identificador de las tres posibles aplicaciones que te permiten crear, por lo que piensa los nombres dos veces. Yo me he dado cuenta más tarde, cuando tras intentar gastar una broma a mi amigo porque no "pudo" registrar una con su nombre (lo intentó con 'Marino' en vez de 'marino' probablemente), me he encontrado con que no es posible ni dar de baja la aplicación actual ni transferirla. En teoría en el futuro se podrá, por lo que por ahora si quiere ver algo en http://marino.appspot.com, será trabajando como desarrollador subcontratado mío

Note: As of this writing, there is no way to delete an application in App Engine. This ability will be added soon. During this preview period, you can register up to 3 application IDs. If you do not want to use one of your allotted application IDs for the tutorial, you can just read this section, and refer to it later when you are ready to upload your first application.

Hello,

Thanks for signing up to try Google App Engine!  Your account has been activated, so you can begin building applications!

Oleeeee!

De hecho, una de las ventajas de ser de los primeros es que ya he podido registrar mi propia aplicación sin ningún tipo de nombre raro: Antonio's App

Está claro que tendré que ponerme las pilas con el Python

Y ¿qué es Google App Engine? Es la plataforma de Google que ahora está disponible para que los desarrolladores web generen sus aplicaciones sobre la misma infraestructura sobre la que Google ofrece su buscador. El modelo es muy similar al que ya está ofreciendo Amazon con su plataforma de Amazon Web Services, solo que en mi opinión, Amazon tiene que empezar a preocuparse ante este nuevo player.

Si bien es cierto, que este tipo de soluciones no eran exclusivas de Amazon, ya que existen otros proveedores que ofrecen soluciones similares, por ejemplo Mosso.

De todas formas, si sigues interesado en lo que ofrece Google App Engine te recomiendo la lectura de este artículo de Linotipo: El futuro es distribuido: Google App Engine, en él podrás encontrar más detalles sobre este nuevo servicio de Google explicado por un experto en el mundo web.