Últimamente tenemos bastantes problemas con varios de nuestros servidores, porque el tráfico está aumentando considerablemente. Así que hemos tenido que hacer unos traslados a toda prisa y, como en otras ocasiones, vamos a incluir aquí los métodos utilizados a modo de repositorio por si a alguien le sirve  de algo.

El problema, era que en el servidor antiguo teníamos Directadmin como panel de control y en el nuevo, Plesk. Tras buscar un poco, vimos que no estaba nada claro utilizar el panel de control para exportar e importar los sitios. Por lo que finalmente, preferimos hacerlo desde la consola.

Importar y exportar por ssh utilizando SCP

Hay muchas formas de utilizar SCP para conectar dos servidores y pasar datos de uno a otro. Pero en este caso, lo que vamos a hacer es conectar por ssh con el nuevo servidor, desde ahí, crear la carpeta de destino y seguidamente, importar los datos a ésta nueva carpeta desde el servidor antiguo.

scp -rp USUARIO(ej. root)@IP_DEL_HOST:/ruta_completa/de/la/carpeta/en_el_servidor/antiguo/public_html ./

-r Copia el directorio completo recursivamente

-p Preserva tiempos de modificación, modos y tiempos de acceso del archivo original

Si sólo incluyes el usuario y la IP del host, te solicitará la contraseña al ejecutar.

En este caso, estamos posicionados en la carpeta de destino del servidor nuevo (hemos llegado allí con cd ..) Por eso, en el destino, ponemos sólo ./

Mientras que en el origen ponemos la ruta completa desde la raiz del host, hasta la carpeta que queramos importar.

Sincronizar usando rsync

En este caso, no nos ha servido esta opción, pero la incluímos también para referencia. Esta opción es útil si se quiere mantener dos servidores sincronizados con el mismo contenido:

rsync -avz -e ssh USUARIO(ej. root)@IP_DEL_HOST:/ruta_completa/de/la/carpeta/en_el_servidor/antiguo/public_html ./

Ambos servidores deben de estar preparados para aceptar la conexión. Lo más interesante de esta opción, es que tras la primera importación, cada vez que sincronice sólo descarga los archivos modificados o nuevos.


Importar Base de datos MySql grande

El principal problema para importar una base de datos MySql, es que si el archivo de importación es bastante grande, el PhpMyAdmin se encuentra con las limitaciones de subida http. Al final, lo más sencillo, es exportar la base de datos (Por ejemplo, desde el PhpMyAdmin), subirla mediante FTP (mejor SFTP) al servidor nuevo y luego abrir la consola e importar ese archivo al MySQL desde la línea de comandos:

mysql -u USUARIO_BASE_DE_DATOS -p NOMBRE _BASE _DE_DATOS < ./archivo_a_importar.sql

Esto lo ejecutaremos habiéndonos posicionado con cd .. en el mismo directorio del archivo_a_importar. Al ejecutarlo, nos pedirá la contraseña del usuario de la base de datos, ya que no la hemos incluido en el comando.


¿Algún truco más? Utiliza los comentarios de abajo si quieres aportar algo.

Llevo mucho tiempo dándole vueltas a esto, así que para ayudarme a aclarar mis propias ideas, he decidido escribir este pequeño post.

Salida y declive de Facebook en bolsa... ¿Quien lo iba a decir? Pues si alguien vivió lo que fue Terra en España, seguramente ese alguien podría haber intuído que estas cosas pueden pasar. En su momento se habló mucho de la burbuja de las puntocom, etc, etc... Pero, ¿realmente era una burbuja? ¿Por qué entonces era una burbuja y no lo es ahora?

Según lo veo yo (sin ninguna base científica para afirmarlo), hay dos tipos de grandes corrientes en la Industria. La que se beneficia de la Moda y/o la obsolescencia, y la que pretende evitarla a toda costa. Facebook, sería evidentemente del segundo tipo.

¿Qué es lo que más valoramos de Facebook? La posibilidad de comentar cosas con nuestros "amigos de Facebook", comentar fotos, estar en contacto con gente que físicamente está lejos de nosotros... Como viene demostrando Google+, no es nada dificil de replicar. De hecho, existen muchos sistemas de código abierto que emulan con bastante facilidad lo que viene a ser el sistema estandar de red social. Sin embargo, Facebook se lleva el gato al agua con los usuarios y eso es en definitiva lo que nos mantiene dentro. Si mis amigos están ahí, voy a quedarme. Al menos por el momento.

¿Pero que ocurre si Apple, la mayor compañía del mundo actualmente, decide comerse esa parte del pastel? ¿Y si Google, otra gran empresa del mundo online, decide hacer lo mismo? Se monta la tormenta perfecta para Facebook.

Por su parte, Google ya lo intentó y lo sigue intentando con Google+, pero tiene una desventaja frente a Apple. Su "capa de hardware" por encima de Facebook (dígase Android) es abierto, y por tanto, tiene las manos atadas para perjudicar a Facebook descaradamente.

Sin embargo, podemos observar como Apple acaba de eliminar la app de Youtube del iOS 6, también ha cambiado la app de Google Maps por una versión propia. Y por otro lado, está introduciendo la posibilidad de que los usuarios comenten las fotos de sus contactos via iCloud, así como poniendo en marcha el sistema de mensajería iMessage (tiembla What's Up). La gran diferencia en este caso, es que Apple puede hacer lo que quiera. Incluso podría no aceptar la app de Facebook en su App Store alegando, por ejemplo, que Facebook no cumple a rajatabla con los derechos de autor.

Ese sería el golpe final, pero Apple no lo puede asestar porque podría volvérsele en contra. Si el iPhone no tuviera Facebook, probablemente mucha gente no se compraría el iPhone. Pero, ¿y si Facebook pasa un poco de moda?

Para mi, esa es la gran pregunta. ¿Qué pueden hacer para no pasar de moda? ¿Cómo pueden evitar que la gente se canse de su logo, de sus colores, de sus "Me gusta"? Es una red social. Socialmente, todo lo relacionado con el marketing está sujeto a las modas. ¿Es un producto o es un servicio? ¿Lo consumimos o nos consume?


Jorge Tarazona
Director de Portfolio Multimedia









Este pequeño post me lo envío a mi mismo, en plan regreso al futuro, para la próxima vez que tenga que buscar y reemplazar en muchos sites a la vez, dentro de un mismo servidor Linux (y base de datos MySql):


Búsqueda sencilla en carpetas recursivas desde el directorio donde estás situado y filtrando sólo archivos PHP:


Se ejecuta desde línea de comandos, por ssh o telnet, por ejemplo. Te devuelve la ruta de los archivos encontrados una a una. Si tiene que buscar en muchos archivos se queda un poco frito hasta que responde o finaliza. Si no responde puede ser o por haber cometido una errata o porque tenga muchos archivos en los que buscar. No puede buscar cadenas con saltos de línea (creo) porque grep va línea a línea. Si se queda frito podemos cancelar con CTRL+C.


Buscar y reemplazar en carpetas recursivas filtrando sólo archivos PHP:

Se ejecuta igual que el ejemplo anterior, pero no devuelve los resultados. Tendrás que comprobar que haya cambiado los archivos a mano. Se podría completar buscando de nuevo la cadena completa. En un servidor con 30 usuarios aprox tarda sólo unos segundos.



Buscar y reemplazar en una base de datos MySql:


Por ejemplo, se puede ejecutar desde el PhpMyAdmin. La condición de ejemplo sólo haría el buscar y reemplazar en los registros que incluyeran la CADENA A BUSCAR DE CONDICIÓN en el CAMPO indicado. Es decir, la cadena a buscar de la condición es diferente a la que utilizamos para el buscar y reemplazar (por no liar). La condición es opcional.












Como la mayoría de desarrolladores sabemos, el sistema de la App Store, la documentación y demás historias alrededor son bastante peliagudos. En los últimos días, nos hemos tenido que pelear a base de bien para sacar adelante un proyecto cuyos plazos eran muy ajustados. Y aunque la programación no tenía fisuras, lo cierto es que ha sido toda una experiencia. Así que para que no se nos olvide y a la vez, dejar constancia por si a alguien le puede servir esta experiencia, vamos a enumerar algunos de puntos más conflictivos:


- Guardar datos en /Library/caches NO en /Documents

Desde la salida de iOS5 y iCloud, Apple ha cambiado la forma de gestionar las carpetas de datos. Ahora, todo lo que está en /Documents se sube a iCloud para tenerlo disponible en la nube. Si tu app guarda datos para ser vistos a posteriori offline, se supone que lo tienes que guardar en /Library/caches. Pero atención, en estados de poca memoria, dicha carpeta se vacía aleatoriamente. Apple, da la posiblidad de marcar cada archivo que no quieras que se elimine, pero sólo desde la versión 5.1, con lo cual, todos los que usen tu app con la 5.0 correrán el peligro de que los datos descargados se borren. El problema: que si lo guardas en /Documents, te rechazarán la app (aunque en la documentación no quede nada clara la obligatoriedad)

Ejemplo de método para marcar los archivos:

- (BOOL)addSkipBackupAttributeToItemAtURL:(NSString *)path
{
    const char* filePath = [path fileSystemRepresentation];
   
    const char* attrName = "com.apple.MobileBackup";
    u_int8_t attrValue = 1;
   
    int result = setxattr(filePath, attrName, &attrValue, sizeof(attrValue), 0, 0);
    return result == 0;
}


- Mejor suscripciones no automáticas

Es uno de los mejores sistemas para facilitar la venta, pero hay algunas cosas muy importantes a tener en cuenta. Para que el artículo no se haga demasiado largo, resumimos y si acaso, en los comentarios podemos debatir más...
Las suscripciones automáticas se miran con lupa. Puede llegar a ser una agonía, porque cada revisión con rechazo puede llevar una semana y no lo suelen poner fácil. Una opción que a nosotros nos pareció más adecuada es la suscripción automática junto con un script que detecte cuando esté llegando el final de la suscripción. De este modo, podemos avisar al usuario que la suscripción se está acabando y que puede renovar. Lo que es mucho más amigable para el usuario y menos duro para ser aceptado por Apple.


- Gestión de productos de In app purchase

Luego, el proceso para subir "In-App purchases" es toda una historia y de ahí, la verdadera razón del artículo. Realizar las pruebas es el primer escollo. Es necesario: 
- Subir una primera app con nombre irreal a iTunes Connect
- Subir un artículo a In-App Purchase desde Manage In-App Purchases.
- Rechazar la app por el desarrollador (autorechazarla).
- Crear un usuario de pruebas desde Manage users

Cuando ya tenemos la app lista y la subimos, tenemos que poner un producto, con su ID correspondiente. Uno de los problemas, es que si la app es rechazada, no te volverán a dejar poner el mismo ID, porque el sistema indica que el ID ya está en uso. Pero una de las cosas más extrañas, es la cantidad de información contradictoria que existe sobre el formato de los ID's de producto. En la mayoría de sitios, indica que hay que ponerlos con el prefijo del app bundle. Sin embargo, en nuestro caso, el ID de producto es un sólo número entero (1, 2, 3 ...) y funcionan perfectamente.


- Todo bien, pero el producto devuelve un error

Finalmente, tenemos la app aceptada, el producto inicial funcionando, pero tenemos que subir otro producto. Aunque cabría esperar que el producto lo aceptaran rápido, NO es así. Puede tardar varios días fácilmente. Luego, si buscamos en Google, veremos que también hay múltiples opiniones contradictorias sobre la revisión de este producto. En nuestro caso, sabemos fehacientemente que el producto en si, NO ha sido revisado antes de ser aceptado. Sólo revisan el título, la descripción y la imagen representativa que subes.

Pero lo mejor está por llegar... Te aceptan el producto, recibes el mail de aceptación y sin embargo, el sistema te devuelve un error: Error en la compra. No se puede conectar con la App Store. Concretamente en el log de la app: "Invalid Product ID" o ID de producto inválido. Si tenemos dudas con nuestra app, puede ser que montemos la de dios, intentando volver a subirla o modificando cosas que en realidad estaban bien. (Bueno, esperemos...) Lo más seguro es que sea sólo cuestión de esperar, ya que las App Stores no van todas al unísono y aunque te hayan aceptado el producto, enviado el mail, y en la de EEUU esté disponible, es posible que en la de Europa o España, NO. Por eso, es importante tener en cuenta que una vez recibes el mail, pueden pasar unas cuantas horas hasta que esté disponible en la tienda de tu país.

Esto es todo por ahora. En realidad, subir una app es siempre una odisea y estas son sólo varias cuestiones concretas de nuestra última app, pero esperamos al menos contribuir a clarificar un poco estos asuntos.

Jorge Tarazona
Director de Portfolio Multimedia








Hace un par de meses que Google lanzó Google+, su intentó más decidido de plantar cara a Facebook. Desde su comienzo, se está hablando mucho sobre si será una verdadera competencia para Facebook y si realmente nos aporta algún valor añadido respecto a lo que ya existía en este ámbito.

Si vemos el asunto con cierta distancia, comprobamos que al final es una lucha por la hegemonía de nuestro tiempo en internet. Simplificando al máximo, yo diría que Yahoo! perdió su lugar cuando decidió (¡quién sabe por qué!) incluir un enlace a Google al final de sus resultados de búsqueda, cuando no encontrabas lo que querías. Google, ha conseguido mantenerse en la cima a base de ofrecer simplicidad, pero llegó un punto en que el usuario ya estaba preparado para algo más avanzado. Entonces, aparece Facebook y se come de un plumazo ese pastel. Sin duda, el mayor éxito de Facebook es no haber necesitado demasiado el "salir bien en Google", es decir, su modelo ha utilizado la viralización entre usuarios muy por encima del SEO y ahí Google ha tenido muy poco que hacer. Tras varios intentos casi fallidos, parece que por fin han decidido meterse en el juego social hasta las últimas consecuencias. Así que, al menos los que trabajamos en esto, tenemos la obligación de meternos a experimentar.



Por mi parte, nunca he sido un usuario muy enfrascado en las redes sociales. Me metí en Facebook porque me encargaron programar una red social y aunque sabía bien lo que era y cómo funcionaba, no quería dejar de lado la parte del usuario. Es un servicio que me parece muy útil, pero siempre tengo cierto recelo sobre mi privacidad. El saber cómo funcionan por dentro estas cosas, no sirve precisamente para tranquilizar en este sentido... De cualquier forma, últimamente mis ideas sobre privacidad están evolucionando y creo que todos debemos de empezar a gestionar nuestra identidad online de un modo mucho más estratégico. (Ya hablaremos de ello). Llevo en Google+ un mes aproximadamente y aunque la sensación inicial es buena, todavía no tengo claro si el valor añadido que se ofrece al usuario final es suficiente.



La principal diferencia entre Facebook y Google+ desde su lanzamiento ha sido el concepto "círculos", con el que Google se apuntó el tanto de ofrecer un mayor control sobre la privacidad a sus usuarios. (La verdad es que parece un chiste) Pero poco a poco, las plataformas están replicándose. En Facebook ya han sacado la posibilidad de acotar la publicación de los posts, así como el concepto "Subscriptores" que viene a ser el "seguir" clásico de Twitter que ya adopto G+ desde su inicio. Vamos, que la actividad en las oficinas de ambos gigantes, debe de ser frenética, porque cada día nos presentan cosas nuevas. Ahora llega la API de Google+. Lo cierto, es que tras probarla unas horas, me da la impresión que por el momento es más un RSS que una API, porque sólo ofrece datos públicos y no da ninguna posibilidad de publicar en nombre del usuario, integrar la aplicación en la plataforma o acceder al sistema de amistades o círculos. Entonces, ¿por qué la han sacado tan pronto?. Supongo que era necesaria. Esta guerra está provocando una necesidad de novedad constante y no tengo nada claro que sea realmente beneficioso para nadie. Como decía antes, Google siempre ha ganado por la sencillez de sus productos, pero ¿realmente está siguiendo esa premisa con Google+? ¿Es Google+ un servicio más sencillo que Facebook? ¿Por qué la mayoría de mis amigos no se han movido y no parece que se vayan a mover de Facebook?

Como es bien sabido, las guerras no benefician a nadie y al final todos salen en mayor o menor medida un poco trasquilados. Google es un buscador. ¿Qué digo? Es el buscador. Pero con esta apuesta, está negándose en cierto modo a si mismo. Está dejando entrever que él mismo piensa que el modelo buscador puede estar agotándose y esto, aunque gane, sería casi como comenzar desde cero para ellos. En Facebook, por otro lado, deben de estar preocupados, por el poder del contrincante, pero por otro lado muy contentos, porque están peleando en su propio terreno y por ahora, llevan mucha ventaja.


Jorge Tarazona
Director de Portfolio Multimedia

<<

1  2

... 2 Página/s

Siguiente Página>

>>