Cattleya aclandiae

La Cattleya aclandiae è sicuramente una delle cattleye più gettonate presso i collezionisti e gli appassionati. È ritenuta una delle Cattleya più difficili da coltivare sopratutto se la si vuole tenere in casa senza l’ausilio di una serra. Stimolato dalla bellezza del fiore e da questa rinomata difficolta di coltivazione ho deciso di prenderne una per tentare l’impresa di avere una fioritura casalinga.

La pianta è arrivata a casa 5 anni fa ed era davvero piccola come vedete dalla foto.

IMG_1303

Dopo aver fatto ambientare la piccola pianta, il vaso è di circa 5 cm di diametro, in casa per qualche mese l’ho posta su zattera. Poiché la difficoltà di coltivazione di questa pianta è dovuta principalmente alla scarsa resistenza delle sue radici ai ristagni d’acqua, è consigliabile anche in casa la coltivazione su zattera di sughero con le radici libere e ben arieggiate.

La coltivazione su zattera senza serra è impegnativa, non lo nascondo, in questi 5 anni ho annaffiato questa pianta anche più volte al giorno nelle calde giornate estive. L’ho portata con me anche in vacanza per non fargli mancare le giuste cure.

Ama il caldo e la luce che deve essere abbondante e diffusa perché, come moltissime orchidee, con il sole diretto si scotta. La crescita è veloce e costante durante tutto l’anno. Nella letteratura presente su internet ci sono pareri discordanti circa un periodo di riposo con poche annaffiature durante i mesi invernali. Personalmente ho notato che la pianta se annaffiata costantemente cresce tutto l’anno producendo nuovi pseudobulbi anche in inverno. Per fiorire la pianta deve crescere fino ad avere gli pseudobulbi lunghi più di 10 cm. Nel mio caso ci sono voluti ben 5 anni. Gli pseudobulbi non hanno la spata, tipica di altre Cattleya, il bocciolo del fiore  nasce e si sviluppa insieme allo pseudobulbo e alle foglie ed è facile intuirne la presenza perché mentre lo pseudobulbo cresce, all’altezza dell’attaccatura delle foglie è ben visibile un rigonfiamento dovuto al bocciolo.

Tutte le mie cure sono state ripagate quest’estate.

IMG_3737

 

Phalaenopsis amboinensis

La Phalaenopsis  amboinensis è stata una delle prime specie di Phal che ho acquistato circa 5 anni fa nel maggio del 2010. Ecco come si presentava al momento dell’acquisto:

phal_amboinensis1

Negli anni la pianta è cresciuta molto ma non ha mai fiorito. Ci ha provato ogni anno emettendo in primavere qualche stelo che non ha mai prodotto boccioli. In questi anni ho provato di tutto, l’ho tenuta molto umida o molto secca, il riposo invernale, al caldo e al freddo ma nulla, la pianta sempre uguale, foglie grandissime radici sane ma niente fiori. A luglio 2014 sono stato sul punto di privarmene cercando uno scambio con una altra specie, poi non trovando lo scambio decido di fare un ultimo tentativo.

Cercando in rete informazioni sulla specie mi imbatto in un sito dove viene indicato che per la corretta coltivazione è necessario uno sbalzo termico fra il giorno e la notte, altrimenti la pianta non fiorisce. Questo tipo di condizione è assai difficile in casa mia, infatti le temperature casalinghe non oscillano fra notte e giorno, in particolare in estate la variazione è davvero minima, forse un solo grado. Che fare? Decido di spostare la pianta all’esterno sul terrazzo dove sicuramente ho un maggiore sbalzo termico fra la notte e il giorno. Il problema è il sole così colloco la pianta fra le fronde di un leccio, raccolto anni fa e destinato a diventare bonsai ma mai lavorato. Dopo qualche giorno, con mio grande stupore, ecco che i due steli,  ormai  fermi da mesi riprendono a crescere e verso la fine di luglio ecco 2 boccioli. I boccioli crescono lentamente  e verso la fine di settembre ecco 2 splendidi fiori. Missione compiuta, anche l’unica Phal che non era mai fiorita ora lo è.

phal_amboinensis3

phal_amboinensis2

Phalaenopsis hainanensis

La Phalaenopsis hainanensis è una orchidea originaria della cina nella regione dello Hainan. È una pianta epifita di piccole dimensioni, una miniatura direi, che vive nelle regioni montuose fino a 1900 mt di quota. Si differenzia dalle altre Phal per via delle foglie caduche. Infatti durante l’inverno, se le temperature scendono sotto i 14 °C, le foglie cadono. Nella primavera successiva la pianta emetterà nuove foglioline e lo stelo con i fiori.

Da segnalare che questa pianta è purtroppo segnalata nella Red List dell’ IUCN come specie Critically Endangered  (endangered species vuol dire specie gravemente a rischio di estinzione).

La coltivazione in casa non è affatto problematica, io la coltivo davanti la mia Orchifinestra come le altre Phal in un vasetto con il bark. In inverno non la pongo in un luogo più fresco e in questo modo non perde tutte le foglie ma in ogni caso non si può certo definire una pianta dalla folta chioma. Di solito ha 1 o 2 foglie qualche volta 3. La pianta è con me da 3 anni circa, la prima fioritura è avvenuta la scorsa estate (estate 2014) i primi fiori si sono aperti verso la fine di luglio. Il fiore è bellissimo da prima si preseta giallo-verde per poi tendere al giallo-arancio nel tempo. Purtroppo ora trovo una sola foto spero di farne altre alla prossima fioritura.

phal_hainanense

 

Si vola con lo Sbach 342

Anno nuovo modello vecchio!

E così ho deciso di iniziare a riscrivere su questo blog  sempre più landa desolata di vecchi ricordi. Perché non ho scritto più?

Boh! Non lo so non mi andava!

Ma torniamo al titolo, si vola con lo sbach! He si! In questi anni di assenza ho ripreso un’attività, forse l’unica che davvero mi prende al 100%, che è quella del modellismo radiocomandato aereo. <<Ma come?>> – direte voi – <<non ce ne hai mai parlato?>> È vero, lo so, non ho mai parlato perché questa attività in un certo senso mi lega a mio padre. È lui che mi ha insegnato e che mi ha trasmesso questa passione. Quando il nostro rapporto è finito, malamente, io ho rimosso un po’ tutto di mio padre compreso il modellismo e mi sono dedicato ad altro e quanto altro! Ma alla fine le passioni vere prima o poi riemergono e non puoi opporti. Devi seguirle perché ti rimettono in pace con il mondo. Beh le foto parlano da sole…

Lion, Apache lento dopo l’aggiornamento

Finalmente oggi ho trovato la soluzione ad un problema piuttosto fastidioso che si era verificato con l’aggiornamento  di Lion, una strana, stranissima lentezza del web server apache. Come vedremo non è poi colpa di apache ma all’inizio a me sembrava colpa sua.

Prima di tutto specifico però come è configurato il mio ambiente di sviluppo web, io ho appunto apache come web server per il test in locale dei siti in via di sviluppo ed utilizzo i vitualhost di apache per identificare  siti locali con il suffisso .local, quindi ad esempio ho www.slweb.local. Ho poi nel file /etc/hosts l’indicazione per risolvere www.slweb.local nell’indirizzo ip locale del mac. Quindi per testare la versione locale di questo sito digito sul browser www.slweb.local.

Il file /etc/hosts, durante la risoluzione dei nomi, viene consultato prima del DNS e per questo motivo è molto rapido e soprattutto permette di ignorare il DNS per il TLD .local. Ma vi è un problema, a quanto pare Os X 1.7 utilizza il TLD .local per alcuni servizi bonjur e questo provoca il rallentamento nella risoluzione dei nomi .local contenuti nel file /etc/hosts. Ecco spiegato il motivo per cui ogni volta che richiedevo una pagina .local il web server apache impiegava oltre 5 secondi per rispondere!

Il modo più semplice per ovviare a questo problema è quello di non usare .local per i siti locali ma un’altra estensione come .dev.

Ho cambiato tutti i virtualhost e il file /etc/hosts con .dev al posto di .local e adesso è tutto super veloce, come prima.

Creare file di specifiche dimensioni.

Spesso per fare i test di upload/download delle applicazioni web è necessario disporre di file che abbiano precise dimensioni. È possibile creare questi file, molto semplicemente con il comando unix dd, disponibile sia in Linux che in Mac Os X. La sintassi  per creare un file da 1Mb è la seguente:

dd if=/dev/urandom of=filetest_1mb bs=1048576 count=1

Poichè il file è riempito di valori random anche comprimendolo non si ha perdita di dati, rimane delle stesse dimensioni!

gzip filetest_1mb

Produce il file compresso filetest_1mb.gz di 1 Mb esatto.

Il data package di Ext Js 4 – part 1

Il data package di Ext Js 4 è stato completamente riscritto ed introduce moltissime novità. Al centro del data package troviamo Ext.data.Model. Il Model non è altro che la rappresentazione di un certo tipo di dati trattati nella nostra applicazione. Ad esempio un applicazione per la gestione dei clienti ed relativi ordini avremo sicuramente un model che rappresenta il cliente ed un model che rappresenta l’ordine. Il model quindi è essenzialmente composto da un elenco di valori (campi) e alcune informazioni su di essi. Per comprendere meglio definiamo il model Cliente per la nostra applicazione:

Ext.define('Cliente', {
  extend: 'Ext.data.Model',
  fields: [
     { name: 'id_cliente', type: 'int' },
     { name: 'nome', type: 'string' },
     { name: 'cognome', type: 'string' },
     { name: 'email', type: 'string', vtype: 'email' },
     { name: 'telefono', type: 'string' }
  ]
});

Il Model, viene utilizzato unitamente a Ext.data.Store per visualizzare e modificare i dati all’interno della nostra applicazione. Attraverso lo Store è inoltre possibile compiere diverse operazioni come l’ordinamento, la ricerca etc.  Per visualizzare l’elenco dei clienti in un grid panel,  dobbiamo, quindi, definire un Store:

Ext.create('Ext.data.Store', {
    model: 'Cliente',
    proxy: {
        type: 'ajax',
        url : 'clienti.json',
        reader: 'json'
    },
    autoLoad: true
});

In questo Store abbiamo definito un un proxy di tipo AJAX, che carica i dati dall’url specificata in formato json e li interpreta tramite il reader definito. In Ext js 4 possiamo definire svariati tipi locali o remoti di Ext.data.Proxy.

Nell’esempio precedente abbiamo definito il Proxy all’interno dello Store, Est Js 4 ci offre anche un’altro approccio, ovvero la possibilità di definire il Proxy all’interno del Model:

//definisco un modello con il relativo proxy
Ext.define('Cliente', {
  extend: 'Ext.data.Model',
  fields: [
     { name: 'id_cliente', type: 'int' },
     { name: 'nome', type: 'string' },
     { name: 'cognome', type: 'string' },
     { name: 'email', type: 'string', vtype: 'email' },
     { name: 'telefono', type: 'string' }
  ],
  idProperty: 'id_cliente'
  proxy: {
        type: 'ajax',
        api : {
            create  : 'createCliente.php',
    	    read    : 'elencoClienti.php',
    	    update  : 'updateCliente.php',
    	    destroy : 'deleteCliente.php'
        },
        reader: {
             type: 'json',
             root: 'dati'
        },
        writer: {
            type: 'json',
            writeAllFields:true,
            root : 'data',
            encode: true
        }
    }
});

// Uso il proxy definito nel model
Ext.create('Ext.data.Store', {
    model: 'Cliente'
});

Questo approccio offre due vantaggi. Il primo è evidente, tutti gli store che useranno il Model Cliente leggeranno i dati dallo stesso Proxy, non dovremo così definire un Proxy in ogni Store. Il secondo è meno evidente ma altrettanto interessante; possiamo caricare e salvare i dati senza l’uso di un Store.

Prima di vedere come compiere le operazioni sui dati vediamo bene il significato delle varie configurazioni del Model Cliente.

   idProperty: 'id_cliente'

La configurazione serve ad indicare qual’è il campo che identifica univocamente il record, di default questo valore è id se come nel nostro Cliente si è usato un campo diverso da id, si deve necessariamente specificare quale campo riveste la funzione di id, in questo modo il Proxy verificando la presenza di questo valore sarà in grado di stabilire se si tratta di un nuovo record oppure di una modifica ad un record esistente, eseguendo la chiamata ajax corretta.

api : {
   create  : 'createCliente.php',
   read    : 'elencoClienti.php',
   update  : 'updateCliente.php',
   destroy : 'deleteCliente.php'
}

La configurazione api consente di indicare al Porxy quali sono le url da chiamare per ogni singola operazione CRUD (Create, Read, Update, Destroy), se state usando un back end che è in grado di riconoscere le operazioni restful (PUT, POST, GET, DELETE) potete tralasciare api ed usare la configurazione url insieme a la configurazione type: ‘rest’.

reader: {
   type: 'json',
   root: 'dati'
}

Il reader è quello che si occupa di leggere i dati, in questo caso abbiamo specificato che il tipo di dati è json e che i dati veri e propri sono dentro l’array dati. Questo reader si aspetta una risposta json di questo tipo:

{"success":true, "message":"Dati caricati correttamente", "dati":[{record 1},{record 2},...,{record n}]}

Ed infine:

writer: {
   type: 'json',
   writeAllFields:true,
   root : 'data',
   encode: true
}

Il writer si occupa di definire il modo in cui operano le richieste di scrittura sul server remoto. In particolare stiamo indicando che i dati inviati devono essere di tipo json, che bisogna inviare sempre tutti i dati writeAllFields:true (se il framework remoto supporta l’aggiornamento solo dei campi modificati, è possibile saltare questa configurazione che di default è false) e infine che i dati saranno codificati dentro il parametro data dell’azione POST, in php avremo quindi:

$dati = json_decode($_POST['data']);

Come abbiamo detto, possiamo compiere delle operazione sui dati senza l’ausilio dello Store, vediamo:

// Prendiamo un riferimento al modello Cliente
var Cliente = Ext.ModelMgr.getModel('Cliente');

var stefano = Ext.create('Cliente', {
    nome: 'Stefano',
    cognome: 'Perinetti',
    email : 'stefano@prova.com',
    tel: '+39000000000'
});

//Possiamo salvare stefano senza l'uso di uno Store, perché abbiamo definito nel Model tutto il necessario
//per questa operazione
stefano.save({
    success: function(stefano) {
        console.log("Stefano salvato! id_cliente =  "+ stefano.getId());
    }
});

In questo esempio abbiamo creato un nuovo cliente e abbiamo salvato i suoi dati sul server remoto utilizzando un’istanza del Model Cliente senza l’ausilio di uno Store. Da notare che il metodo Ext.data.Model.save() compie due azioni, la prima è di scrittura e la seconda di lettura per ottenere l’id generato probabilmente dal server remoto. Nell’operazione di lettura che avviene su quanto restituito dalla chiamata POST per il salvataggio dei dati sul server, deve quindi essere incluso l’intero record appena salvato con il suo id all’interno dell’array (root: ‘dati’) definito nel Proxy reader. In breve save() si aspetta una risposta simile:

{"success": true, "message":"Record salvato correttamente.", "dati":{"id_cliente":123, "nome":"Stefano" ...}}

Ci sono ancora molte cose da analizzare sul data package vedremo nella seconda parte di questo articolo.