ricicliamo!

allora, fate conto che bisogna tenere sincronizzati due sistemi di database. Uno basato su Sap e l’altro Oracle. Il primo è il “master” e il secondo è il “client”. Il master pubblica, tramite un web service SOAP, una tabella piuttosto importante, in pratica la lista di utenti dei sistemi. Ho scritto un bel programmino java che ogni quattro ore va ad invocare il web service, legge la tabella e la importa nel database client. Tutto sembra funzionare per bene.
Qualche settimana fa, hanno aggiunto agli attributi degli utenti un campo “DataCessazione”, che significa che l’utente da un certo momento in poi non è più attivo.
Ancora tutto bene.
Adesso, lato “master”, hanno ben pensato che, se un utente non è più attivo, si può anche riutilizzare la sua chiave primaria per un altro nuovo utente !!! che teschioni!
Quindi adesso sul “master” ci sono una cinquantina di utenti “nuovi” che hanno chiavi primarie di utenti “vecchi”. Io sul “client” mi rifiuto di “riutilizzare” così gli utenti vecchi, perchè sennò tutti i dati storici mi si impapocchiano.
Ecco come due sistemi sincronizzati sono di fatto desincronizzati. Almeno finchè i furboni cambieranno idea sul riciclo… “dopo il vetro, le lattine e la plastica, è ora di riciclare le chiavi primarie!!!”

“per dipingere una parete grande…”

“…ci vuole un pennello grande!” diceva quel tale…
ma oggi ne ho sentita una ancora meglio: il mio collega R. sta lavorando su un form di un’applicazione. inserisce un bottone “Esegui”. passa il suo capufficio C., guarda il form e dice:

Quel bottone, fallo più grande. Così sembrerà che faccia pià roba…

e uno poi dice che non ci sono più gli sviluppatori di una volta… =)

ancora numeri

ma stavolta è una cosa grossa: il numero della BBBBestia!
[Vulvia mode ON]Lo sapevate? sui tutti codici a barre europei, c’è scritto il numero 666. non l’avete visto? ah, perchè è scritto in binario… ah, non starete mica pensando che il Satanasso non capisce il binario, vero? Sapevàtelo, su Rieducational Channel![Vulvia Mode OFF]
Insomma, i codici a barre hanno tre barre (appunto) di controllo, all’inizio, a metà e alla fine. servono per delimitare la lettura, ovviamente. la sequenza di controllo è | | (Barra-Spazio-Barra): se Barra=1 e Spazio=0 sta cosa si legge 101 che in base 2 vale 6.
[EDIT]:e bon che sono un informatico… 101, come mi segnala un utente e non la mia mente bacata, in binario è 5, non 6! in realtà leggono BarraBarraSpazio->110->6
Ora, visto che ce ne sono tre di sequenze di controllo, si può leggere addirittura 101 101 101 [EDIT] come sopra 110 110 110
. aiuto! orrore! raccapriccio! è il numero 6 6 6!!! anzi no, perchè il numero 101101101, se proprio vogliamo, in decimale è 365 [EDIT]438. bon. a parte l’evidenze stronzata, un consigliere svizzero sta facendo una denuncia penale per vietare l’uso dei codici a barre siffatti perchè

“in particolare, [il numero] offende o può offendere la sensibilità religiosa di cattolici, evangelici-riformati, ortodossi e dei fedeli di tutte le altre confessioni cristiane minori.”

cosa ne penso io: ma andate a cagare…[EDIT] e quasi quasi ci vado anch’io che non so fare i conti…

come chiudersi fuori da soli…

stamattina ho fatto il mio primo danno. sto lavorando sul mio schema di database in un’istanza di oracle. il mio user ha grant di administer database trigger perchè ho bisogno di creare un logon trigger del tipo

create or replace trigger user_logon_trigger 
    after logon on database
begin
  my_package.do_something();
end;

Insomma ricreo lo schema (trigger compreso), faccio logout-login. Non va, non riesco ad entrare.
Nel frattempo non si collegano nemmeno i miei tre colleghi, che aspettano di lavorare su altri schemi sulla stessa istanza. Il trigger sembra invalido, e caccia fuori tutti gli utenti.
Non vi dico i casini per recuperare il DBA, che non riusciva nemmeno lui a loggarsi, e alla fine fare un reboot della macchina.
Stavolta, il DBA fa riavviare il db modificando in init.ora la variabile

_system_trig_enabled = false

che permette di far partire il db senza trigger. bon. riabilitiamo il trigger e vediamo se tutto gira. Sì, gira tutto.
Tempo 5 minuti ed è di nuovo tutto TFU (Totally Fucked Up come dice il mio omonimo).
Alla fine si svela l’arcano: nel pacchetto my_package ho lasciato un dbms_pipe.send_message() che mi serviva per debug. Questa simpatica utility va a scrivere in un buffer i messaggi. Ma se il buffer non viene “svuotato” leggendolo, il buffer si riempie. E riempie la memoria dell’istanza oracle. Non sapete quanto… finchè implode tutto e non si riesce nemmeno a collegarsi…
Quindi, oggi ho imparato che: si può escludere l’attivazione di un trigger per un determinato utente:

create or replace trigger user_logon trigger
  after logon on database when user not in ('sys', 'system', 'pippo')
begin
  ...
end;  

Poi ho imparato che è meglio tenersi amico il DBA.
e che le cose di debug si fanno sull’istanza di debug.
e che dbms_pipe è una mer@a.

backup & utilities – 2

sto usando da qualche tempo, un ottimo script php, phpmysqlautobackup, per fare il backup del database dei siti che gestisco.
questo script esporta, zippa e spedisce a un indirizzo email configurato, il contenuto del database. poi basta aggiungere un piccolo cronjob per attivarlo e il backup è fatto. ottimo!
un piccolo problema è che nella sua versione originale
lo script gestisce il backup solo se il database gira su “localhost”.
allora ho dato un occhio al codice e ho preparato una piccola patch per aggiungere il supporto al backup di un server diverso.
in run.php aggiungete

  $mysql_hostip = "numero.ip.del.server.database";   

e in /files/config.inc.php

  $cfg['servers'][$i]['host'] = $mysql_hostip;

così sarà risolto il problema.
lo sviluppatore ha inserito questa mia proposta nel forum di sviluppo: Backup a remote database – how to set the ip address. e forse la includerà nelle prossime versioni del progetto. clap clap! bravo DaVe! (anche lui si chiama Dave!!!!! 😀 )

memoria condivisa

da quando ho cominciato lavorare a tempo pieno con eclipse, pl/sql Developer e tomcat con 3 o 4 webapps caricate contemporaneamente, il computer ha cominciato a soffocare, con solo 512Mb di Ram. allora via con l’upgrade!
il mio capufficio chiama il servizio sistemistico e richiede ancora 512Mb per la mia macchina. passa quasi un mese e si presenta l’ometto. purtroppo ha disponibile solo un banco da 256Mb, e bon, che si monti lo stesso. piuttosto che niente, meglio piuttosto.
il computer comincia a respirare e io a lavorare senza crash continui.
la richiesta del mezzo giga è ancora attiva. passa un’altro mese, anzi quasi due, e si presenta un’altro ometto: “di chi è il computer HDS43X?” “mio!” “devo installare un banco di Ram” “Aleeeeee!”. si sentono suonare le trombe, sventolano le bandiere, la gente in piazza fa festa.
ora vediamo in uno pseudocodice Java come si è svolta questa operazione di alta tecnologia:

Memoria memoriaVecchia, memoriaNuova;
Tecnico ometto = new Tecnico();
ometto.smontaMemoria(memoriaVecchia);
int quantaMemoriaVecchia = memoriaVecchia.getMegaByte(); 
  // è 256Mb!
int quantaMemoriaNuova = memoriaNuova.getMegaByte(); 
  // è 512Mb!
if (quantaMemoriaVecchia < quantaMemoriaNuova) {
  try {
    ometto.montaMemoria(memoriaNuova);
  } catch (TipoMemoriaNonSupportato t){
    if (memoriaVecchia instanceof DDRAM &&
        memoriaNuova instanceof SDRAM) {
          Divinita dio = God.getInstance();
          // Dio è un singleton Ahahahahaahahaaaa! =) 
          throw new Bestemmia(dio);           
    }
  } finally {
    ometto.rimonta(memoriaVecchia);
    ometto.exit(fromOffice);
  }
}

e così aspetterò ancora un altro mese...