<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-06-17 10:35 GMT+01:00 Matteo Scarpa <span dir="ltr"><<a href="mailto:matteoscarpa92@gmail.com" target="_blank">matteoscarpa92@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Sto cercando di scrivere un applicativo Android che recuperi da più  pagine web dei dati (sono orari visualizzati come html) che visualizza filtrando in base alle preferenze dell utente.</p></blockquote><div>Ok.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Per alleggerire l applicazione ho intenzione di fare uno o più url dove l app scarica i file in formato json o simile.</p></blockquote><div>I files sarebbero i files html o le preferenze dell'utente?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"> </p>
<p dir="ltr">Il lato server che fa il parsing lo farei in python perché lavora meglio del Java con i file html ma oltre a Beautifullsoup non conosco moduli per questo genere di cose.</p></blockquote><div><br></div><div>Allora, parliamoci chiaro. "Lavora meglio del Java con *" e' un'affermazione sufficientemente discutibile in generale. Di solito stai su Python per motivi come fai prima, lo trovi piu' mantenibile. Non perche' lavora meglio con X o Y. Cioe' occasionalmente c'e' anche caso che ci siano librerie che sono molto piu' convenienti da usare... da cui si arriva: "lavora meglio con i file html" vuole dire tutto e niente.</div><div><br></div><div>Ora, dimentichiamo un secondo il pezzo "ovvio" di cui ti stai preoccupando (ovvero il parsing). Pensiamo invece all'architettura di questo servizio.</div><div><br></div><div>Fondamentalmente questo e' un servizio web.</div><div>Allora tu avrai una serie di richieste che ti vengono dal device cui devi rispondere. Bene. </div><div>Bisogna a questo punto capire se le pagine che devi parsare sono un set finito oppure dipendono da quello che ti chiede l'utente.</div><div>Se sono un set finito (e dimensionato ragionevolmente), puoi pensare di parsarle offline (batch) e ficcare i dati da qualche parte. Sempre se questi</div><div>sono ragionevolmente piccoli, sei veramente fortunato. Sebbene non sia l'architettura ideale, puoi tranquillamente uscirtene con qualcosa di veramente semplice, tipo un set di cron che fanno il lavoro, ti popolano un qualche tipo di db e il tuo web service (Django-based?) legge la roba da questo db e siamo tutti contenti.</div><div><br></div><div>Ora, puo' *comunque* valere la pena di mettere su Celery (o qualcosa del genere) per farti da scheduler. In generale ti da delle decenti soluzioni di monitoraggio del tuo servizio senza le quali non puoi nemmeno pensare di andare in produzione. Celery ti porta a meta' strada. Se fai a mano (come sopra, devi fartele tu con i cron).</div><div><br></div><div>Ma io temo che questo non sia quello che devi fare. Io temo che quello che tu vuoi fare sia dinamicamente succhiarti la pagina su base di quello che ha richiesto l'utente, parsarla e cacargli indietro il json. Bene: sei sfortunato. Questa e' esattamente una cosa che Python fa *di merda*, a meno di non spostare la tua soluzione a livello architetturale.</div><div><br></div><div>Ora, perche' non puo' davvero funzionare (a meno di non dovere servire 3 richieste al giorno)?</div><div><br></div><div>Una parte del tuo workflow e' I/O bound (leggere la richiesta dell'utente, ottenere la pagina da un servizio remoto -- che puo' non rispondere, rispondere in ritardo e compagnia -- e poi dare indietro la risposta) e una parte e' CPU bound (parsare la pagina). Ah, il tutto puo' diventare molto divertente perche' Python a volte non rilascia memoria bene quanto dovrebbe, quindi avere un servizio che si succhia tonnellate di html e costruisce tonnellate di json in risposta non e' esattamente salubre. Si, di solito si dice al tuo app server di lasciare morire i worker dopo un po' di richieste: ma e' una pezza, non e' una soluzione.</div><div><br></div><div>Ora l'unica possibile soluzione sensata per questo problema e' una qualche declinazione di:</div><div>1. ricevi la richiesta</div><div>2. la ficchi in un qualche sistema di code</div><div>3. un qualche sistema di worker processa -- parsa -- e mette la risposta da qualche parte</div><div>4. servi la risposta</div><div><br></div><div>Ora... se fai tutto in modo sincrono, hai tanti dei problemi della soluzione di cui sopra. Diciamo che facendo cose sensate riesci comunque a ridurre il problema della dicotomia fra CPU-bound e IO-bound, dovresti anche riuscire a gestire cose come i retries (se la pagina non ti viene servita[0]). Ovviamente hai sempre il discreto problema dei timeout (tipo che il client tende ad incazzarsi dopo un po' che aspetta la risposta... e allora vai di hack tipo spedire un spazio ogni tanto hurray! -- e ovviamente non vuoi veramente tenere impegnato un worker del webserver a spedire spazi di tanto in tanto mentre sotto processi tutto). Quindi quello che vorresti fare e' spostarti in logica asincrona: e' anche relativamente facile visto che possiedi sia l'app sul device che il server.</div><div><br></div><div>La buona notizia e' che in tutto questo Celery e' una discreta soluzione al tuo problema di worker et similia. </div><div><br></div><div>La cattiva notizia e' che questo tipo di flussi si fanno davvero bene con altre tecnologie. Tipo Go. Ma anche Java se la cava parecchio bene. Tipo... il flusso che stiamo descrivendo sembra proprio pane per Hadoop. </div><div><br></div><div><br></div><div><br></div><div>--</div><div>[0] hint... se mantieni tu il servizio che hosta le pagine che devi parsare -- cosa di cui dubito -- valuta *parecchio* la questione dei retry. Possono causarti dolore inimmaginabile. Voglio dire... se le hostassi tu, potresti preparare un set di API che caca direttamente il JSON.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"> Ci sono alternative migliori? Sto sbagliando tutto? Esiste un modulo python che fa il parsing e lo esporta direttamente in json? <br></p></blockquote><div>Questa domanda mi fa un po' paura... come puo' esistere un coso che converte html in json? Mi spiego meglio... xml (e sigh, non necessariamente html e' xml) puoi vederlo come una struttura ad albero. Il che vuole dire che potresti certamente rappresentarla con json. Otterresti qualcosa di ben piu' orribile, piu' grosso e meno maneggevole. Quello che tu vuoi fare, e' estrarre specifici elementi da una pagina: e come puoi pensare che esista un coso che esporta esattamente le cose che servono a te?</div><div> </div></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>