Problemi di coordinate sempre nuovi :(

Dunque, questa volta credo sia proprio colpa mia, che non ho capito il funzionamento delle tecnologie che ho deciso di utilizzare.

Quel fottuto transofrm matrix del tag <g> del svg non fa ciò che io pensavo. Sono stato tratto in inganno dal fatto che il browser inspector me lo evidenza come un elemento, con larghezza e altezza e una posizione, ma a livello di API è solo una scorciatoia per applicare modifiche ad un gruppo di elementi in un colpo solo. Niente di più.

Ma in quest’ottica non capisco che senso abbia dover specificare coordinate relative al tag <g> per poterci aggiungere una nuova immagine, visto che poi le sue proprie coordinate, all’interno del svg, continuano a cambiare ad ogni aggiunta / rimozione di un figlio.

In sostanza, il passaggio da coordinate dello schermo a coordinate del gruppo fallisce stupidamente, perché io mi affidavo alle x e y del matrix, che a differenza di quel che pensavo io non sono le coordinate ma solo l’equivalente di quanto è stato traslato il tag dal momento della sua creazione.

Quindi, che fare? L’illuminazione migliore avuta fino ad ora mi è arrivata stamattina al risveglio. Ad ogni aggiunta o rimozione sulla dashboard, tengo aggiornati due array che contengono tutte le coordinate x e y delle immagini presenti nel svg. In fondo il tag <g> come coordinate ha praticamente la minima x e la minima y tra tutte le immagini che contiene.

In questo modo lavoro su 2 array di numeri e non su un array di oggetti grossi come le immagini. Penso possa andare.

Ma questa volta prima di partire col codice voglio studiare bene l’argomento. Cercherò su internet altre possibili soluzioni per questo problema, e leggerò la documentazione.

Che palle le coordinate

e quanto vorrei ricordarmi matematica!

A quanto pare il calcolo delle coordinate durante lo zoom che credevo finalmente di aver archiviato, non l’ho archiviato manco per il cazzo. Ci ho lavorato tutta la sera e ora dovrebbe funzionare.

Stamattina ho avuto l’illuminazione di aggiungere alla dashboard (solo in modalità debug) un pallino al centro dello schermo con scritte accanto le coordinate assolute attuali. Perché non ci ho pensato prima non lo so.

E grazie a questo è stato subito evidente che il calcolo fosse sbagliato. Mi aspettavo valori di segno opposto e ordine di grandezza diverso. Boh, chissà come avevo fatto a validarlo in passato.

Ora “funziona” (meglio lasciare le virgolette, per evitare figure di merda future), ma ci sono evidenti errori di arrotondamenti. Se fisso il cursore in un punto, e faccio zoom out e in fino ai valori massimi e ai valori di partenza, le coordinate assolute calcolate alla fine non corrispondono alle coordinate assolute iniziali. Lo scazzo è di pochi px, tipo 1 ogni 10 mila di variazione di zoom, ma comunque vanno a sommarsi ogni volta che si zoomma.

Credo di poter risolvere impostando un valore fisso di decimali a cui arrotondare tutti i valori che ora hanno valore decimale periodico, perché ho visto che in js:

1.1363636363636365  –  1  =  0.13636363636363646.

Chissà perché ma le ultime due cifre non corrispondono… boh. Allora preferisco mozzare il valore per tutti a due decimali in meno.

E intanto non ho ancora lavorato al bug coordinate #1 …

I bug nascono dal fatto che di “coordinate” ne ho un fottio:

• assolute rispetto all’intera dashboard
• relative rispetto allo schermo, quindi anche al tag svg grande quanto lo schermo
• relative all’interno del tag svg

E coi nomi di tutte queste variabili mi devo essere impappinato.

Ora ho appena fatto un commit in cui ho fatto un po di pulizia e omogeneità tra i nomi di queste diverse coord, lato client e lato server. Nell’oggetto “draw” tengo solo le chiavi di cui ho bisogno.

Prima avevo x , y , w , h , minX , minY , coordX , coordY , e altre, e stava a me ricordarmi il significato di ciascuna. Ora so che lato client parlo di coordinate relative, e lato server di coordinate assolute, quindi sul server avrò una sola chiave x, che sarà la coordinata assoluta, e lato client una sola x che sarà la coordinata relativa.

I metodi che si trovano nel mezzo, che si occupano di inviare e ricevere, hanno il compito di effettuare la conversione.

La situazione attuale:

• su drag e zoom calcolo bene le nuove coordinate (assolute della dashboard, e relative dei disegni)
• su salvataggio disegno, lato server salvo le giuste coordinate assolute, e l’aggiunta diretta del disegno sulla dashboard avviene alle giuste coordinate relative
• su download dei disegni, questi vengono inseriti sulla dashboard a delle coordinate relative sbagliate.

Devo cercare cosa c’è di diverso negli input del salvataggio quando arrivano dall’editor o dal server. Ipotizzo che sia che non ho calcolato anche le coordinate relative del tag <g> dell’svg. Ho convertito da assolute della dashboard a relative dello schermo, ma non ho aggiunto lo spostamento del tag <g> rispetto allo schermo.

Credo

Si procede in direzione 1.0

Oggi un po di bestemmie per l’installazione dei driver Node per Mongo. Alla fine ci siam riusciti, e sono partito al lavoro per le query di insert e select dei disegni.

Ora salvataggio ok, recupero sempre a true. Purtroppo mi restituisce sempre tutti i disegni che ho nella collections, praticamente ignorando ogni filtro che provo a mettere.

E problemi nella visualizzazione sulla dashboard alle giuste coordinate; ma comunque il risultato del primo step è ben visibile ed ormai alle porte.

Presto sarà possibile salvare disegni in modo permanente!

Socket.io è il paradiso!

Cazzo ma perché ho perso tempo con php ???? Scemo chi lo usa ancora.

Tutti i problemi che ho cercato di risolvere in php qui sembrano gestiti di default. Cross-browser, identificazione immediata delle deconnessioni, trasmissione senza problemi di stringhe lunghe, gestione delle diverse comunicazioni con custom event.

Ho fatto un test pocciando a più non posso il mio schermo da 13 pollici, e lato server mi sono ritrovato un solo evento non spezzettato in pagine da 900K. Ho già integrato il nuovo Socket Node nel mio lato client, ed ho creato un server base che riceve le chiamate e risponde, senza però mettere o prendere niente da db.

Certo non è stato tutto tempo perso. Ho ripreso in mano php in profondità, e prima o poi potrebbe saltare fuori durante qualche interessante conversazione che conosco l’argomento WebSocket Php.

Ora non resta che imparare MongoDB! Al primo sguardo mi era sembra stia interessante, ma ora devo proprio metterci le mani!!

E VPS fu!

Configurazione di base terminata. Non ci capisco tendenzialmente un cazzo, ma comunque dovrei essere arrivato ad avere tutto il necessario installato sul mio vps, node e mongo inclusi!

Questa nuova strada mi ha portato via più di una settimana, in cui non ho scritto neanche una linea di codice e fatto neanche un commit. Da oggi si riprende! Finalmente in Node.

I prossimi giorni saranno molto interessanti :D

Caaaaazzo che figata i server.

Ho scoperto ed installato Centos Web Panel, che praticamente è tutto ciò che un pigrone come me può desiderare per gestitre il proprio server.

Si installa in automatico e gestisce ogni cosa on interfaccia grafica. Firewall, apache, database, utenti, ftp, cache, domini, ssh, DNS, cpu e memoria, ed ogni altra cosa utile. Tutta la configurazione server per quanto mi riguarda è fatta. Devo ancora capire come gestire diversi domini su un solo ip e fare la migrazione di quelli in mio possesso, ma per quello non c’è fretta.

Ho anche fatto la prima prova di server in ascolto in Node.js, e risulta raggiungibile già facendo IP:PORTA, quindi domani sarà il giorno di Mongo.DB e Socket.io . Installati e testati anche loro, poi si passa alla scrittura del WebSocket Server in Node ! Non vedo l’ora!

Bella, tutto cambia.

Mi sono reso conto che anche creare una versione php del websocket mi stava rubando via molto più tempo di quanto volevo dedicarci. Quindi lo scopo principale di quella strada, ossia farmi risparmiare provvisoriamente tempo, era fallita.

Ho comprato un VPS base su netsons, 9.5 euro al mese, 1 CPU 2GHz, 1 GB ram, 50 Gb hhd, 100 Mbit banda. Non male dai :D

Ma è tutto interamente da configurare a mano in ssh. Argomento stra interessante la configurazione server unix a terminale, ma completamente nuovo per me.

In ogni caso me ne sto uscendo abbastanza bene; ho scoperto il sito ServerMom.org, e se potessi gli darei un bacio con la lingua. Spiega davvero bene come fare ottime configurazioni passo passo. E ora ho Apache Php5 MySql, Node, Ftp. Il minimo per campare. Gli ultimi giorni di lavoro sono stati interamente dedicati a queste configurazioni, e zero codice.

Ora sono in procinto di mettere in piedi il mio primo Hello World in Node, e fatto quello mi lancerò nella creazione del WebService Node, ipotizzo con Socket.io

Anche questo passo non sarà semplice ne veloce, ma almeno non è tempo perso come in Php. Tutto quello che realizzo ed imparo adesso è tutto di guadagnato per il futuro del progetto.

Le bestemmie non finiscono maaaaaii!

NEWS:

• Ho capito come modificare la dimensione massima del buffer di lettura del server, ma comunque la dimensione dei frame non dipende da me. Ora ho impostato 4MB ma ogni frame al massimo è grande 600K durante i test.
• Ho visto che sul mac del lavoro e sul mio portatile il server WebSocket ha due comportamenti diversi. Ciò mi fa bestemmiare alquanto… mi copio un phoinfo() e il file php.ini del lavoro, e a casa li paragonerò coi miei, per vedere cosa cambia. Funziona meglio a lavoro.
• Sul mio mac, bloccate il flag di disconnessione a false fa funzionare la trasmissione fino ad un massimo di un solo frame (che risulta 128K), e impedisce il rilevamento delle disconnessione dei client.
• Sul mac a lavoro, con lo stesso identico codice, la trasmissione funziona bene senza limiti di dimensioni, e i frame sono di max 600K circa. Posso connettere tanti client in parallelo, ma solo finche nessuno di loro ha inviato un messaggio. Da quel momento in poi, quel client diventa il solo che può comunicare col server, e non vengono più rilevate (ne lato client ne lato server) le deconnessioni o connessioni. E se quel primo client si riconnette, il server si auto chiude con l’errore “Socket error: Connection reset by peer”.

Trovato il porco dio di problema !!
Non ho idea del perché, ma quel fottuto flag diventa false a random quando abbiamo più di circa 3k di dati. Più sono i dati, più spesso finisce erroneamente a false.

Eppure non è un problema di lunghezza dati. Se forzo lato server il flag a true, il socket non si disconnette mai e invia client->server e server->client tutti i dati interi.

Quindi bloccando la lettura del flag il problema sembra risolto.
Ma…. ma quello è il flag che permette al server di riconoscere così bene le deconnessioni dei client! Quindi i refresh pagina bloccano i client.

Devo scoprire cosa fa cambiare ad minchiam il flag, o altrimenti come andare a leggerlo solo quando non ho un messaggio buono.

E devo fare un test con flag sempre a true e messaggi di un mb, e vedere come vengono gestiti i frame.