HP - ordinamento box candidati

nelsonmau commented 11 years ago

ciao, uno dei temi urgenti è l'ordinamento in HP dei box candidati. In questo momento sono in ordine alfabetico ( @paolomainardi correggimi se sbaglio).

Proposta in due step: 1) ordinamento random: subito implementabile? dà l'idea del movimento 2) ordinamento in base a logiche che interagiscono con le api di twitter (es.: in base al numero di followers, e/o al numero di reply o messaggi ricevuti, altro...)

@andypanix riesci a impostare al volo tu intanto l'ordinamento random? ne vale la pena? (prometto che non me lo rimangio :P)

gaspa commented 11 years ago

@paolomainardi non ho capito che intendi: dal DB non si puo' randomizzare. O la togliamo o la si mette nel model a valle della query (e quindi quando hai già l'array). Stai dicendo di toglierla proprio?

paolomainardi commented 11 years ago

@gaspa esatto, l'idea è il db è già pronto per fare sorting sui vari campi, basta teoricamente passargli dei parametri (ora sono hardcoded come vedi, ma l'implementazione sul modello c'è).

Dunque, non passo nessun parametro, scelgo rando "nome, cognome, partito, circoscrizione" e "asc, desc" dunque ho un effetto "random" ma rimanendo sempre sul modello.

Che ne pensi ? Esatto il random da array lo toglierei proprio, è giusta come idea, ma è un implementazione aggiuntiva che va a mettersi in mezzo tra il DB e il Controller che è un po' un anomalia a livello di architettura.

gaspa commented 11 years ago

ok, allora mi rimangio l'affermazione sul model: faccio tutto nel controller, tanto il model ha già il parametro che organizza i dati come vuole l'utente. Sego la roba in lib/ e aggiungo la parte tweet/follower.

paolomainardi commented 11 years ago

@gaspa Ok, il template è già predisposto per la stampa di queste variabili, se vedi nei blocchetti utenti ci sono delle parti commentate, usiamo quelle.

paolomainardi commented 11 years ago

@gaspa Si, il controller va modiicato solo per leggere i parametri dalla query infatti, però farei un po' di validazione per non passare al sorting cose non supportate, limiteri il dominio ad alcuni campi da sortare, vedi tu quali possono essere validi.

stefanoduri commented 11 years ago

non mi è chiaro come pensate di fare per combinare randomizzazione e paginazione.

Una paginazione deve riferirsi a un insieme di item fisso, da cui pescare quelli individuati dai parametri di pagina (cioé progressivo pagina e n. item/pagina)
Se si vuole garantire a ogni utente una paginazione corretta questo insieme deve essere necessariamente unico e immutabile a livello di sessione
Basandosi su un ordinamento fisso "cablato" nel db (indice su una key, ad es.) è sufficiente una query per pagina e non c'è bisogno di utilizzare nient'altro che il db. Se si vuole utilizzare un criterio random, per definizione a ogni query avrò un risultato diverso

In sintesi: se vuoi solo la paginazione non ci sono problemi. Se vuoi solo la randomizzazione puoi realizzarla in vari modi. Se le vuoi tutte e due è inevitabile creare un array/utente Con un approccio del tipo che illustravo (poco elegante, è chiaro) questo array viene generato una sola volta (1 query su tutto il db), randomizzato, salvato e poi utilizzato per effettuare 1 query per pagina, come se avessi a disposizione un indice. Non mi viene in mente nessun'altra soluzione.

paolomainardi commented 11 years ago

La randomizzazione non può esserci, ma deve esserci un Sorting su DB, li si potrebbe implementare la scelta random su cosa fare sorting se nulla è passato.

Fatto questo, la paginazione va implementata senza avere la conoscenza di quale sorting sia attivo o no.

stefanoduri commented 11 years ago

eh no, almeno dovrai memorizzare a livello di sessione su quale variabile o gruppo di variabili hai fatto il sorting, mica puoi farlo casuale a tutte le pagine.

gaspa commented 11 years ago

due cose: 1) meglio è parlarne nella issue relativa? 2) ho fatto due conti, nella mia installazione (non ho aggiornato il dataset):

public/avatars/* --> 5.1M
data.json --> 348K

ora, non si puo' spedire il singolo json della richiesta e poi fare in maniera "deferred" solo gli avatar? mi sembra che eviti troppa complicazione.

paolomainardi commented 11 years ago

@stefanoduri Questo è vero, nel caso di una scelta random avrebbe sicuramente senso tenere in sessione.

Anche se personalmente la visualizzazione "casuale" su ogni pagina non è che mi piaccia molto, avrebbe più senso appunto esporre dei link per fare il sorting su determinati valori "Nomi, Tweet, Ciroscorizione" ecc. Cosa che è già supportata, basta completare l'implementazione come dicevo sopra.

@gaspa Non ho ben capito, gli import di utenti ed avatar sono di fatto separati ora, a cosa ti riferisci ?

gaspa commented 11 years ago

@paolomainardi mi sto riferendo alla paginazione, non all'import. Cercavo di fare due conti su quanto possa essere pesante caricare l'intera pagina di twitantonio e quale sia il collo di bottiglia: evidentemente gli avatar.

paolomainardi commented 11 years ago

@gaspa Gli avatar non dovrebbero essere un problema perchè sono caricati in lazy loading mentre si scrolla, mentre la HP è di oltre 3,1MB, cosa inaccettabile da Mobile. Vedi qui: https://github.com/spaghetti-open-data/twitAntonio/blob/master/public/javascripts/application.js#L24 Comunque vero parliamo qui: #57

gaspa commented 11 years ago

ah, fantastico, il lazy me l'ero perso. piuttosto: c'è un 500K solo di un'immagine... pero' non capisco, è un'avatar? Mi sembra una dimensione assurda, per 48x48 pixel:

logo_ridotto1_normal.jpg
Dimensions 48 × 48
File size  546.97KB
MIME      typeimage/jpeg
URLhttp://a0.twimg.com/profile_images/2206831747/logo_ridotto1_normal.jpg

Screenshot from 2013-02-01 14:58:31

paolomainardi commented 11 years ago

Done.

spaghetti-open-data / twitAntonio

HP - ordinamento box candidati #60