voglio fare un po' il punto della situazione (la mia ovvio). E' forse questo il termine che piu' si avvicina alla mia condizione nell'uso quotidiano di questo sistema operativo: impasse.
E' in atto un cambiamento, ma cio' che piu' mi preoccupa e' che non si capisce assolutamente nulla di dove si vuole andare a parare, ne' di cosa e perche' cambiare.

Uno dei punti "deboli" di linux (lo so si deve scrivere GNU/Linux, lasciamo perdere i francesismi, quindi anche le precisazioni su cosa e' e cosa non e' un desktop environment) e' sempre stata la sua interfaccia grafica, che a dispetto dei grandi discorsi sulla user experience - al punto che sembra che solo gli sviluppatori del pinguino sappiano cosa sia e forti di questo pretendono una qualche autorita' nel campo - e' ancora li' il problema, bello grosso, lo riassumo in una lista del tutto personale e opinabile:

- kde: troppi giocattoli; cursori animati e transizioni stucchevoli non riescono a farmelo digerire, sembra voler compiacere chiunque tranne chi ci deve lavorare. Una cosa che mi irrita parecchio e' che ad ogni release vengono annunciate MIGLIAIA di bug fix, da qui si capisce che [forse] le cose che funzionano sono meno di quelle che NON funzionano, poi c'e' la spiccata tendenza al sensazionalismo per cui ad ogni minimo cambiamento corrisponde un cambio di versione importante.

- Canonical unity: e' una delle cose credo piu' inutili che potesse fare quell'azienda e qui so che c'e' chi lo apprezza molto, ma non e' il mio caso. Ribadisco che ho rispetto per chi lavora e per chi persegue degli obiettivi. Il punto e' che almeno a me questi obiettivi non sono chiari, oggi fanno una cosa domani un'altra, il Mark di tanto in tanto fa un po' il guru della situazione ma senza convincere. Alla fine della fiera unity e' per me un ostacolo, un'inutile distrazione, tra l'altro ha grossi problemi a funzionare in sessioni remote, ne risulta che una macchina che ha solo quel DE e' piu' ostica da controllare di quanto dovrebbe, paradossalmente la situazione era migliore un paio d'anni fa, non so quindi in cosa consista questo progresso di cui Canonical sembra voler fare da portavoce. Sulla dockbar di sinistra stendo un velo pietoso.

- Gnome shell: purtroppo anche questo per me e' inutilizzabile, troppo incentrato su un discutibile "equilibrio" tra utente desktop e device touch. Avendo due monitor full hd non so che farmente di icone e lettering giganti, box arrotondati stile anni '90 e blur/drop-shadow messi li' un po' ad minkiam. Uso molte finestre e terminali, che evidentemente contraddicono l'idea per cui l'utente "medio" di gs debba fare una cosa per volta.

- Gnome fallback: e' cio' che ho usato fino a poche settimane fa, come ripiego, fallback appunto. In sintesi l'ho reputata una regressione forzata che mi ha permesso di "sopravvivere" fino ad oggi. Parlo di regressione perche' sono saltate funzionalita' anche importanti, come interi menu (riacquistati, rilocalizzati poco per volta grazie a pazienza e qualche pezza della provvidenza), schemi colore assurdi e ballerini, qualche "collosita'" di mouse e tastiera.

- xfce: questo mi e' parso interessante, lo uso nelle sessioni remote. Si pensera' che io sia un conservatore, magari si', ma cio' che mi preme di piu' e' che le cose funzionino BENE, anziche' cosicosi' nel migliore dei casi.

- mate: eh con questo mi sono un po' ripreso il desktop. Non e' perfetto ma e quanto piu' vicino all'uso quotidiano/efficiente a cui sono abituato.

Non sono contrario ai cambiamenti, anzi mi interessano e spero che i DE si evolvano, solo che la direzione, se cosi' la vogliamo definire, e' troppo confusa, scomposta.
Si vuole guardare ai dispositivi touch, fare il verso ad android, cercando di arrivare ad un punto di bilanciamento col passato/presente, ma di questo non dovrebbero farne tutti le spese.

Jaco

Geany, uno degli editor piu' simpatici che mi trovo spesso ad usare, e' recentemente passato a 1.22, plugghi compresi.
Notizia lieta e a cui ho subito dato seguito compilando con piacere.

Jaco

bloggo OT.

ieri ho avuto la sventura di veder morire il mio monitor principale, un bell'esemplare di samsung 245b col quale lavoro da qualche anno e con cui mi sono sempre trovato bene, per non dire il mero valore per sostituirlo con qualcosa del genere.
Detto fatto il display si e' oscurato, anche se il pulsante di alimentazione sembrava indicare un corretto funzionamento (la luce blu si accendeva).
Superato lo sconforto iniziale e prima di pensare alla discarica, ho voluto approfondire che tipo di problema poteva essere (lampada, inverter di solito sono i primi responsabili), senza escludere la sezione di alimentazione, che pero' NON pareva coinvolta visto il comportamento del pulsante di accensione.
Insomma, fatta qualche ricerca, dopo un quarto d'ora ho trovato l'ennesimo forum in cui se ne parlava e si puntava proprio alla sezione alimentazione.
Smontato il monitor e la board di alimentazione, sostituito un gruppo di tre resistenze (68ohm 1/2w 5%) e verificato che effettivamente una di esse era saltata interrompendo quella parte di circuito, rimontato il tutto e' tornato a funzionare.

Valore mezzo euro si e no, anzi gratis dalla mia cassetta dei componenti, il monitor e' tornato alla luce.

Che dire ... thanx to internet forums!

Jaco

qui di seguito una piccola guida, spero utile a chi vuole configurare un servizio amf in symfony2. Per chi non ha idea di cosa si tratti, amf e' un protocollo binario supportato dal flashplayer che permette di mantenere i tipi di dato e scrivere web application con un marcia in piu' rispetto alle classiche chiamate http/rest, specie se i dati in transito sono parecchi.

ingredienti:

- symfony2
- zend2
- Tecbot AMFBundle
- JSMSerializationBundle
- AmfBundle-Sandbox, per testare il tutto: contiene codice d'esempio e un'app flex da compilare.

Tutto questo materiale si trova su github ma non e' necessario visitare i singoli repository, bastera' indicarli nella propria configurazione di test.

Il mio punto di partenza e' stato eclipse, che ha un un plugin molto utile per la stesura di progetti symfony.

Creato un nuovo progetto symfony2 senza vendors.

Come probabilmente sapra' chi lavora con questo framework, c'e' da impostare il permessi in cache, io ho ubuntu e per farlo uso l'utility setfacl.
Controllate qui per ulteriori dettagli.

prime modifiche alla configurazione, modificare il file deps:

[metadata]
    git=http://github.com/schmittjoh/metadata.git
    version=1.1.0

e deps.lock:

metadata 1.1.0

la versione che avevo io era la 1.0.0 e non e' adatta, genera errori.

modificare ancora il file deps per includere i repository extra:

[Zend]
  git=https://github.com/zendframework/zf2.git
  target=/zend
  
[JMSSerializerBundle]
    git=git://github.com/schmittjoh/JMSSerializerBundle.git
    target=bundles/JMS/SerializerBundle

[AMFBundle]
    git=https://github.com/tecbot/AMFBundle.git
    target=../src/Tecbot/AMFBundle

a questo punto si e' pronti per installare le librerie, occhio che verra' giu' un paio di centinaia di mb percio' pazienza.
Positionarsi nella cartella del progetto con la shell e dare:

$ php bin/vendors install

si avra' una cartella vendor con le librerie, in src si avra' il bundle AMF

modificare app/autoload.php:

...

    'Metadata'          DIR.'/../vendor/metadata/src',
    
...
		'Zend' 						  DIR . '/../vendor/zend/library',
		'Tecbot'					  DIR.'/../src',		
		'Acme' 						  DIR.'/../src',		
));

scaricare e scompattare da qualche parte il bundle amf sandbox

copiare src/Acme/AmfBundle in /src/Acme nel proprio progetto

IMPORTANTE, la cartella AMF ivi contenuta va rinominata in Amf, errori come questo sono probabilmente legati al fatto che quest'applicazione di prova e'un po' datata rispetto al bundle amf.
Dal momento che quella cartella aveva un nome tutto in maiuscolo, vanno anche corretti i namespace nei pochi file php che vi troverete, ad esempio:

// DemoService.php
namespace Acme\AmfBundle\Amf;

use Acme\AmfBundle\Amf\VO\MessageVO;
...

e via cosi' per MessageVO.php

Modificare app/AppKernel.php

...
            new JMS\SecurityExtraBundle\JMSSecurityExtraBundle(),
        		
        		new Acme\AmfBundle\AcmeAmfBundle(),
        		new Tecbot\AMFBundle\TecbotAMFBundle(),
);

in questo modo al bootstrap di symfony si avranno i bundle incaricati di gestire amf

modificare app/config/config.yml

io ho scelto di inserire direttamente qui delle direttive, se preferite, potete importare il file amf.yml dalla sandbox.

...

tecbot_amf:
  # Services
  services:
    DemoService: AcmeAmfBundleemo

  # Class mapping
  mappings:
    MessageVO: Acme\AmfBundle\Amf\VO\MessageVO   

Si puo' capire che queste fanno riferimento alla classe da poter invocare via amf e il ValueObject che andra' a mappare. Dato che sitamo parlando di banali test, quelle classi sono ridotte all'osso.

Modificare app/config/routing.yml

_demo:
    pattern:  /someapp
    defaults: { _controller: AcmeAmfBundleemo:index }

techbot_amf:
  resource: "@TecbotAMFBundle/Resources/config/routing.yml"

La prima route e' poco rilevante, invocandola si avra' in risposta l'indexAction giusto per testare che l'app e' configurata.
La seconda route e' molto piu' significativa: il file routing.yml di Tecbot ha una route per l'endpoint a /gateway
Naturalmente la si puo' editare a piacere.

prima di fare un qualsiasi test consiglio di svuotare la cache, sempre da una shell nella cartella di progetto:

$ php app/console cache:clear
$ php app/console --env=prod cache:clear 

se si prova direttamente dal browser l'endpoint, si ricevera' in risposta: Symfony Amf Endpoint
Se non compare, rivedere la configurazione. Inizialmente puo' essere necessario del tempo, penso dovuto al caching di classi di libreria di zf2 e sf2.
Per testare l'app io ho configurato un vhost per cui il link in questione da me e':

http://sym.local/gateway

In una forma piu' grezza potrebbe essere:

http://localhost/myproject/web/app.php/gateway

Se tutto e' OK, e' ora di passare a flex.

Fare riferimento alla sandbox, cartella flash.

modificare il file src/acme/utils/Config.as

...
        public static const GATEWAY : String = "http://localhost/amf.php"; // inserire il proprio endpoint
...

a questo punto si potra' compilare, io uso direttamente il compilatore, se puo' interessare, e' questa (posizionarsi in src):

$ mxmlc AcmeAmfDemo.mxml -debug=true -benchmark=true ...
... -static-link-runtime-shared-libraries=true --target-player=11 -library-path+=../libs -output ../deploy/AcmeAmfDemo.swf

copiare il file AcmeAmfDemo.swf nella cartella web del proprio progetto.
Ricordo che stiamo facendo dei banali test, e' chiaro che in prospettiva di sviluppo serio, ci si prendera' cura del templating e della corretta gestione degli oggetti flash nel codice di pagina.

A questo punto dovremmo essere pronti per testare il tutto, aprire il browser e inserire l'url del file swf appena ottenuto, il mio e' questo:

http://sym.local/AcmeAmfDemo.swf

potrebbe essere:

http://localhost/myproject/web/AcmeAmfDemo.swf

il tutto consiste in un campo testo in cui scrivere un messaggio di test, fare il submit e quindi ricevere una risposta elaborata dal bundle AcmeAmfBundle

Happy hacking with actionscript & php.

Jaco

giro un link segnalato da Giorgio Natili. C'e' una prima release candidate di flex prodotta dalla community di spoon, supportata da apache.
Da quanto vedo e' ancora incompleta, penso perche' Adobe non ha ancora passato del tutto i sorgenti e perche' occorrera' ancora tempo per assimilare tutto il malloppo di librerie e integrazioni varie.

Jaco