Se a qualcuno di voi sono servite delle immagini satellitari, sicuramente siete corsi su gmap, ma l'impossibilità di scaricare le immagini direttamente porta a notevoli problemi, ci sono diversi workaround per risolvere, come andare a stampare il monitor, salvare l'immagine, ritagliarla; se però ci servono mappe che non stanno s di un unica pagina? Qui iniziano i problemi e le perdite di tempo, si passa a sctampare diverse immagini, attaccarle assieme, cosa non certo comoda, soprattutto per avere immagini su grandi formati.
Di recente mi è servito ottenere un immagine da stampare su di un cartellone (A2) per una scuola, quindi serviva un immagine molto grande, all'incirca 50MPx per avere una risoluzione decente per la stampa, per fare questo (odiando perdere tempo per stare li a fare le diverse operazioni a mano), mi sono inventato una serie di script che fanno queste operazioni, vediamo come usarli e ottenere il risultato finale.
A chi capita di relaizzare siti, dopo la fase iniziale di produzione e prima configurazione non può tralasciare al seconda fase, ma non meno importante, di messa a punto del sistema. Per fare questo uno strumento che non può mancare è FireBug con l'accoppiata di YSlow.
Dopo l'installazione di base lanciandolo sul nostro sito vediamo che se abbiamo usato un buon sistema di pubblicazione, allora otterremo un discreto punteggio già di partenza, una installazione di prova ha rilevato che è possiblile raggiungere come base un punteggio di circa 77 punti. Vediamo ora come portare il nostro punteggio (e quindi la velocità percepita dagli utenti) a livelli ben più alti.
Precedentemente abbiamo visto come usare gedit come IDE per velocizzare lo sviluppo di codice,gedit come IDE per Drupal, e come alcuni suoi plugin possano risultare particolamrnete comodi, come per esempio la validazione del codice per Drupal.
Non meno inportante è l'utilizzo di un sistema di versioning dei file per permetterci di coordinarci con altri (e anche conn noi stessi).
Spesso capita di dover sviluppare codice, a volte anche in colaborazione con altri, in ogni caso avere un reposotory in cui memorizzare i file risulta un ottima soluzione. Il perchè risulti comodo averlo potete immaginarlo, in ogni caso vediamo i motivi per cui ritengo che un repository in cui memorizzare i file risulti comodo, se non fondamentale.
Inizio dicendo che esistono diversi sistemi per il versioning dei file (creazione di copie di file man mano che vengono fatte modifiche), tra questi i principali e più utilizzati sono gli storici:
A cui si stanno aggiungendo in questo periodo i più moderni
Non ho alcuna intenzione di dire GIT è meglio di SVN che meglio di CVS (opps, l'ho detto), stilare classifiche o altro, semplicemente mostrarvi la comodità di utilizzare uno strumento di questo tipo.
Dopo la pubblicazione del precedente articolo sull'autocompletamento in gedit, grazie ai consigli ricevuti da numerose parti, ho portato avanti alcune correzioni e ampliamenti delle funzionalità di autocompletamento, e sopratutto ho creato un nuovo tipo di liguaggio di scripting definito in gedit, in modo da non mischiare queste impostazioni con quelle predefinite di PHP come era precedentemente.
Come abbiamo visto in un articolo precedente gedit è un editr che ci permette di scrivere codice per Drupal in maniera estremamente semplice, ma perché limitarci a questo? Come sapete per poter pubblicare codice sul CVS ufficiale di Drupal è necessario che il codice che produciamo rispetti una serie di regole; spesso risulta comodo fare in modo che il controllo di queste regole di sintassi venga svolto in maniera automatica. Vediamo come è possibile farlo e come integrare questa funzionalità in gedit.