[pyar] scrapyando páginas con javascript

[Gonzalo Martinez]

Yo hice unos cuantos Scrappers utilizando la opción 2 y no tuve problemas.
Levantar todo un Browser no me pareció copado nunca.

Además de esa manera capaz que le encontrás un patrón y si no necesitás
llenar ninguna variable de sesión o cookie podes llegar a hacer la llamada
Ajax directamente sin hacer el primer requests.

Suerte con eso!


El 19 de marzo de 2014, 19:00, Pablo Gabriel Celayes <pablocelayes en gmail.com
> escribió:

>
> Paso a detallar un poco más
>
> 2014-03-19 18:43 GMT-03:00 Ramiro Morales <cramm0 en gmail.com>:
>
> Yo diría que esto depende de una combinación de:
>>
>> a) Con que frecuencia y escala tenga que hacer el proceso de captura de
>> datos.
>>
> Hay que mantener datos de los próximos 30 días, sobre unas 20 ciudades con
> alrededor de 2000 hoteles cada una. O sea, una vez por día hay q tirar los
> datos de ayer, y agregar los de dentro de 30, los del medio se reutilizan.
> Igual lo de las 20 ciudades es a futuro, por ahora tengo que hacer una
> nomás.
>
>
> b) Que tan intensivo en recursos sea el proceso asociado a una solución
>> tipo 3.
>>
> Una vez renderizado todo el javascript, es liviano trae un par de campos
> nomás y los escribe a una db.
>
>
>
>> c) Cuanto tiempo le lleve hacer una ingeniería inversa manual como la
>> de la opción 2
>>
> Nunca hice, así que me es difícil estimar, pero supongo que una o dos
> tardes de reniegue.
>
> d) Con qué frecuencia estima que van a cambiar la implementación y
>> cuan future-proof quiere hacer la solución.
>>
> En principio es un prototipo para un laburo freelance que estoy haciendo,
> ni siquiera sé si a futuro lo seguiré manteniendo yo. Ahora, del lado de
> Booking me imagino que el layout debe cambiar con frecuencia.
>
>
>>
>> No decartaría la opción 3 con algo como PhantomJS y/o CasperJs que por
>> ahi te dan algunos dolores de cabeza (porque tiene sus limitaciones o
>> bugs medio locos) pero que si te funciona por ahi ayuda a que futuras
>> adaptaciones no sean tan laboriosas. Por ahi hay que sopesar que no
>>
>> siempre a futuro va a  haber un dev que pueda hacer la ingeniería
>> inversa de 2.
>>
>> --
>> Ramiro Morales
>> @ramiromorales
>>
>
> Gracias!
>
>> _______________________________________________
>> pyar mailing list pyar en python.org.ar
>> http://listas.python.org.ar/listinfo/pyar
>>
>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>>
>
>
>
> --
>  *ıl**l**ıl**l**ı* ρąβℓ๏ *ıllı**lı*
> We are the problem. And we should provide the *solution*.
>
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>



-- 
Gonzalo Martinez
*PampaTI - Innovación en tecnologías de la información*
*www.pampati.com.ar <http://www.pampati.com.ar>*
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140319/230046e4/attachment.html>