Capita ogni tanto di sbagliare a scrivere la password della connessione VPN, e il Mac non consente di cambiarla, ma continua a tentare di collegarsi con le stesse credenziali.
Oppure per qualche oscuro motivo il processo si blocca e non c’e’ verso di ricollegarsi senza riavviare la macchina.
Il risultato e’ quello di continuare a vedere una finestra che mostra il messaggio “VPN Connection. A configuration error occurred.Verify your settings and try reconnect”.

E’ frustrante!

Per fortuna e’ sufficiente terminare il processo che governa la connessione VPN.

Aprendo Activity Monitor, e’ sufficiente cercare il processo Racoon e terminarlo.

Non e’ necessaria la forzatura (kill -9), ma sono fondamentali i permessi di amministratore della macchina.
Il processo ripartira’ automaticamente al successivo tentativo di connessione

La grande novità introdotta con Ruby on Rails 3.1 è stata sicuramente l’asset pipeline. Grazie a questa è possibile  concatenare, minifizzare e scrivere gli asset in altri linguaggi come CoffeeScript, SASS e ERB, cosa già resa possibile da librerie esterne, alcune delle quali come per esempio Sprocket sono state integrate in ruby on rails 3.1 attraverso ActionPack che lo vede tra le sue dipendenze.

Queste le 3 importanti features della asset pipeline:

1) concatenare gli asset: riduce il numero di richieste che il browser deve fare per renderizzare una pagina.
2) minifizzare o comprimere gli asset. Per i CSS normalmente consiste nel rimuovere commenti e spazi.
3) codificare gli asset usando un altro linguaggio come SASS per i CSS e CoffeeScript per i javascript e ERB per entrmbi.

Nelle versioni precedenti di rails, tutti gli asset risiedevano in sottocartelle di public come images, stylesheets e javascripts. Con la asset pipeline la cartella di default per gli asset è diventata app/assets e i file presenti in questa cartella vengono serviti dal middleware Sprocket. Questo non impedisce di mettere gli asset ancora in public, è raccomandato metterli in app/assets se questi file devono essere pre-processati prima di essere serviti.

Gli asset possono essere messi in:
- app/assets –> sono gli asset propri dell’applicazione come immagini, file javascript o stylesheets
- lib/assets –> sono gli asset per le proprie librerie che sono condivise da tutta l’applicazione
- vendor/assets –> sono gli asset per entità esterne come per esempio plugin Javascript

Tutte le sottodirectory presenti in questi tre path vengono aggiunte al search path di Sprocket. Quando viene richiesto un asset esso viene ricercato all’interno di queste cartelle e, una volta trovato e processato, viene servito.
Sprocket è a conoscenza dei path attraverso config.assets.path che include i path standard più quelli aggiunti dai rails engines.
Sprocket usa i “file manifest” per determinare quali file devono essere inclusi e serviti. Questi “file manifest” contengono delle direttive – istruzioni che dicono a Sprocket quali file ha bisogno per creare un singolo file javascript o css.

Se si genera un controller (Es. ProjectsController) viene creato automaticamente un file app/assets/javascripts/project.js.coffee e app/assets/stylesheets/project.css.scss, grazie alla naming-convention è possibile caricare questi file in questo modo:

<%= javascript_include_tag params[:controller] %>
<%= stylesheet_link_tag params[:controller] %>

In generale, i file vengono richiesti usando i soliti helper di rails:

<%= stylesheet_link_tag "application" %>
<%= javascript_include_tag "application" %>

e si accede alle immagini nel consueto modo

<%= image_tag "rails.png" %>

Aggiungendo l’estensione ERB ad un file CSS è possibile scrivere per esempio

.class { background-image: url(<%= asset_path 'image.png' %>) }

L’estensione del file viene usata per determinare il pre-processore da usare.

Quando si crea un applicazione rails vengono creati automaticamente i file:
* app/assets/javascripts/application.js:

//= require jquery
//= require jquery_ujs
//= require_tree .

require_tree –> dice a Sprocket di caricare tutti i javascripts nella directory corrente
require jquery_ujs, require jquery –> dice a Sprocket di caricare i file jquery_ujs e jquery presenti da qualche parte nell’asset path. In questo caso sono dentro vendor/assets/javascripts.Nei file javascripts le direttive iniziano con //=

* app/assets/stylesheets/application.css

/* ...
*= require_self
*= require_tree .
*/

require_tree –> funziona come per i javascript ovviamente però carica i file css
require_self –> serve per includere il codice css (se) presente nel file

Per parecchi asset l’ordine di inclusione è importante come nell’esempio i css:

/* ...
*= require reset
*= require layout
*= require chrome
*/

Si possono avere tanti “manifest file” quanti ne servono, per esempio admin.js e admin.css manifest possono contenere JS e CSS usati per la sezione admin.

In Produzione
————-
In produzione in ogni filename viene inserito un fingerprint MD5 in modo da permettere al browser di cachare il file e può essere invalidato se il fingerprint cambia.
Di default si assume che gli asset siano precomplilati e serviti come asset statici dal webserver.

Esempio:
<%= javascript_include_tag "application" %>

<%= stylesheet_link_tag "application" %>

E’ possibile abilitare o disabilitare il fingerprint tramite config.assets.digest che è settato a true solamente per la produzione.
Esiste un task per precomplilare gli asset –> bundle exec rake assets:precompile
Capistrano ha una ricetta per complilarli in fase di deploy, basta aggiungere questo nel Capfile –> load ‘deploy/assets’
Il rake task genera un file che si chiama manifest.yml che contiene una lista di tutti gli asset i loro rispettivi fingerprint :
—
rails.png: rails-bd9ad5a560b5a3a7be0808c5cd76a798.png
jquery-ui.min.js: jquery-ui-7e33882a28fc84ad0e0e47e46cbf901c.min.js
jquery.min.js: jquery-8a50feed8d29566738ad005e19fe1c2d.min.js
application.js: application-3fdab497b8fb70d20cfc5495239dfc29.js
application.css: application-8af74128f904600e41a6e39241464e03.css

La location di default di questo file è quella specificata da config.assets.prefix, generalmente ‘/assets’, ma può essere cambiata specificando qualla nuova nella direttiva:
config.assets.manifest = ‘/path/to/some/other/location’. Se in case di compilation deli asset qualcosa doves non funzionare vine sollevata un eccezione AssetNoPrecompiledError. E’ possible in tutti i casi abilitare la compilazione a runtime degli asset config.assets.compile = true.

In produzione è spesso necessario un meccanismo di caching, specialmente se ci sono parecchie immagini nelle pagine.
Affinchè il caching funzioni è necessario che le immagini vengano inserite nella pagina usando l’helper di rails image_tag che permette al task assets:precompile di creare la versione dell’immagine con il fingerprint alla fine. Per tutte le immagini che vengono caricate tramite css, per esempio come background della pagina, è necessario che il file css abbia anche l’estensione scss, in questo modo sarà possibile utilizzare degli helper di sass come image_path e image_url che permettono al task di fare il suo lavoro. Un altro metodo è quello di utilizzare anche l’estensione erb per il css e usare l’helper di rails asset_path.

Rif. http://guides.rubyonrails.org/asset_pipeline.html

Piu’ che altro l’importanza di usare gli entity HTML nella maniera corretta.
Soprattutto nelle query string degli url, visto che Safari li interpreta in maniera inaspettata.
Tutti i browser convertono gli entity HTML completi, come &rsquo; o &amp;, ma Safari esegue la stessa operazione anche se non vengono completati (con il ; )
Cosi’ accade che se in un url viene usato il parametro
&lang=it
questo venga erroneamente convertito in
〈=it
Per ovviare al problema, e’ sempre buona norma utilizzare gli entity HTML corretti negli url, quindi &amp;lang=it
Altre entity che spesso vengono interpretate erroneamente sono &copy = -> ©= , o &section ->; §ion

http://htmlhelp.com/tools/validator/problems.html

Ovvero: come un buon divano ed evidentemente il cibo messicano, aiutano le buone idee.

Nell’ambito del progetto Enti e Tribunali per Gruppo Espresso, ci stavamo dibattendo nel solito annoso problema del CMS integrato nel sito, per la creazione/modifica delle pagine istituzionali e delle pagine personali di utenti premium. Dimenticavo di premettere che il progetto utilizza Rails 3.

Fin qui non abbiamo mai trovato soluzioni veramente soddisfacenti: abbiamo fatto vari tentativi con CMS vari (Radiant) o mettendo insieme a manina componenti (Liquid Template per MioJob ad esempio).

Ora ho provato a utilizzare BrowserCMS e RefineryCMS che supportano Rails 3 (al contrario di Radiant che è ancora fermo a Rails 2), ma sono tutt’altro che semplici da embeddare in un progetto gia esistente, e sono troppo potenti o troppo poco.

Alla fine, come sempre dedicando un po di tempo alla ricerca, è saltato fuori questo: https://github.com/twg/comfortable-mexican-sofa

che a parte ridefinire l’acronimo CMS in maniera simpatica, mi sembra essere esattamente quello che serve: l’ho appena installato senza molta fatica in un progetto Rails e ha tutto quello che serve:

• un editor WYSIWYG semplice (tinyMCE)
• un sistema di versioning delle pagine
• un meccanismo di Layout flessibile e completamente integrabile con l’applicazione
• meccanismi di scambio dati con l’applicazione primaria
• possibilità di authentication integrata con l’applicazione.

Insomma: a occhio sembra lui!

Ora lo proviamo veramente e vediamo se mantiene le promesse.

E per chi è curioso, qui c’è la storia di come è nato il nome

http://blog.twg.ca/2011/02/the-comfortable-mexican-sofa-vitamin-d-infused/

Come capire se il vostro Mac ha memoria sufficiente, se e’ necessario acquistarne ancora oppure se basta fare un po’ di pulizia.

Prima di spendere un sacco di soldi per acquistare nuova RAM, è più conveniente fare qualche tentativo per capire se e’ veramente necessario.
Per capire come OSX gestisce la memoria è possibile consultare l’articolo Gestione della memoria.

Se l’ActivityMonitor dice che avete meno di 100Mb di memoria libera, beh è possibile che la macchina cominci a swappare.
Come prima cosa lanciate il comando top da terminale, ed andate a dare un’occhiata al valore della memoria inattiva (Inactive Memory), se è elevato (oltre il 10% della RAM totale) si può provare a svuotarla con il comando purge.
In teoria dovrebbe liberare la ram inattiva, e darvi un po’ di respiro.
Se dopo qualche minuto, la situazione si ripresenta, è il caso di approfondire la ricerca.
Sempre dall’output del comando top bisogna analizzare il valore Pages Out.
Generalmente dovrebbe essere un valore piuttosto ridotto, mentre il valore tra parentesi (swap istantaneo) dovrebbe essere 0 o un valore molto piccolo, che significa che la macchina NON sta copiando molti byte dalla RAM al disco fisso.
Se il valore di Pages Out è elevato, ma il valore tra parentesi rimane prossimo allo 0, è probabile che qualche applicazione abbia avuto bisogno di risorse elevate, ma la situazione si è stabilizzata.
Se invece vi capita spesso di vedere il valore di swap istantaneo sempre alto, beh, mi spiace ma e’ arrivato il momento di acquistare un po’ di RAM