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”.