Good environment variable values during iPhone development

Directly from GHUnit, a small note about which environment variables to set while developing for the iPhone.

Environment Variable:                 Default:  Set to:
NSDebugEnabled                           NO       YES
NSZombieEnabled                          NO       YES
NSDeallocateZombies                      NO       NO (or YES)
NSHangOnUncaughtException                NO       YES
NSAutoreleaseFreedObjectCheckEnabled     NO       YES

Actually, I keep forgetting them, so I hope this will be useful to me.

Here an example that shows how to set those environment variables.

Setting iPhone development variables in XCode

Affidabilità dei sistemi informatici bancari

Stavo lavorando in una banca ad un porting verso tecnologie attuali di un sistema esistente da qualche anno. Nell’ambito di tale progetto dovevo realizzare un modulo del sistema il cui compito era sostanzialmente quello di estrarre da DB dei record con un campo data maggiore o uguale alla data di odierna, eseguire alcune elaborazioni e scriverli in un file da inviare ad un sistema a valle per una successiva elaborazione.

Il campo che conteneva la data era un campo CHAR di 8 caratteri e ci era stato assicurato che tutte le date erano nel formato YYYYMMDD. In questo modo per selezionare i record con una data maggiore di quella odierna si poteva sruttare l’ordinamento alfabetico e ad esempio scrivere una condizione del tipo

data >= '20052310'

Facendo qualche test mi sono però accorto che in realtà nel db c’erano record con date nel formato DD/MM/YY. La condizione restituiva perciò anche record con valori pari ad esempio a “23/12/98″, “20/10/89″ ed in generale qualsiasi data il cui giorno fosse maggiore o uguale a 20. Questo perchè, in ordine strettamente alfabetico, “23/12/98″ segue “20052310″. I record che avrebbero dovuto essere stati estratti erano qualche decina, invece la presenza delle date nel formato inatteso, ne faceva salire il numero a qualche centinaio.

Dopo un consulto con un programmatore che lavorava alla manutenzione del sistema decidemmo di lasciare i dati scorretti sul DB ma eliminarli nella query di selezione. E quindi in dettaglio la condizione diventò…

data >= '20052310' AND data not like '__/__/__'

Tutto sembrava andare per il meglio, il file contenente i risultati divenne molto più corto e l’elaborazione successiva ne avrebbe certamente giovato.

Mi pareva comunque strano come per i sette o otto anni precedenti il sistema a valle avesse elaborato ogni giorno centinaia di record inutili senza che sollevare il minimo problema.

In fase di test un file campione genenrato dal nuovo sistema doveva essere caricato dal sistema successivo. Il giorno del test ricevetti una telefonata ed il tecnico all’altro capo del filo mi disse che il test era fallito poichè alcuni record contenuti nel file non trovano riscontro nei dati di altre tabelle. Pronto ad affrontare una noiosissima sessione di debug mi accorsi che nel file prodotto non trovavo minimamente traccia dei record errati a cui si era riferito il tecnico.

Dopo una ricerca trovai i record incriminati nel file che era stato prodotto non dal nostro nuovo sistema ma dal vecchio sistema correntemente in produzione. Insomma, per una svista, il tecnico aveva sottoposto a test non il file prodotto dal nuovo sistema, ma quello prodotto quotidianamente, ormai da anni, dal sistema in produzione. E ci aveva trovato pure degli errori!