Delivery

Pe De steffy82iancuLasă un comentariu

Ce trebuie să conțină pachetul de livrare pentru o aplicație APEX?

După ce s-a terminat partea de dezvoltare, testare, implementare pe PROD și corectarea eventualelor bug-uri care au ajuns pe PROD, se livrează aplicația. Livrarea trebuie să marcheze finalul contractului de prestări servicii de dezvoltare și efecutarea ultimei plăți.

Practic, se livrează următoarele:

-toate scripturile .SQL de creare a obiectelor bazei de date (tabele, view-uri, proceduri, funcții, pachete, joburi, grant-uri)

-scriptul de instalare al aplicației

-toate linkuri-le, parolele si detaliile conexiunii la baza de date

-scurt video cu funcționalitățile aplicației sau document word – manualul utilizatorului

-training utilizatori

– descriere completă a task-urilor pentru mentenanță și predarea către persoana care va asigura suportul. Recomand ca persoana care se ocupă de mentenanță și suport să fie un angajat intern al companiei pentru care a fost dezvoltată aplicația. Astfel, costurile se reduc semnificativ.

În nici un caz livrarea unei aplicații nu înseamnă doar accesul la aplicație. (nume utilizator și parolă).

Vorbim aici de aplicații făcute la comandă pentru care s-au plătit serviciile de dezvoltare. Este vorba despre aplicații dezvoltate exclusiv pentru un anumit client. Nu este vorba despre aplicații la care avem acces pe baza unui abonament lunar și care sunt accesate de mai mulți clienți (software as a service).

Bold APEX

Pe De steffy82iancuLasă un comentariu

În acest post, voi explica cum putem marca cu bold textul dintr-un item de tip Display Only dar și textul dintr-o coloana din interactive grid.

Pentru a marca ca bold un item de tip Display Only trebuie să utilizăm CSS: style=”font-weight: bold” în secțunea Advanced.

Pentru a marca ca bold o coloana dintr-un interactiv grid, folosim HTML Expression în secțiunea Column Formatting: <b>#REQUEST_EXTID#</b> unde REQUEST_EXTID este column name.

Release package

Pe De steffy82iancuLasă un comentariu

Un proces prost definit înseamnă pierdere de timp și frustrare. Înseamnă implicarea mai multor oameni decât este necesar și o mulțime de email-uri.

De exemplu, procesele de change management și release management pentru o aplicație APEX ar trebui să fie simple și clare.

Lucrurile ar trebui să funcționeze așa:

  • se strâng, se analizează ( tehnic, cost, beneficiu, impact ) și se prioritizează noile cerințe
  • se definește release package, se dezvoltă și se testează
  • se definesc roluri și responsabilități ( cine, ce va face )
  • se definește fluxul de lucru și ce e de făcut în diverse situații

Toate persoanele implicate trebuie să cunoască fluxul, responsabiltățile proprii dar și ale celorlalți. Simplu, nu?

Am lucrat pentru o companie mare în care procesele erau respectate și totul mergea bine de la cap la coadă. Nu mi-am dat seama atunci cam cum ar fi dacă procesele nici măcar nu sunt definite, însă acum da, știu cum e:

  • este mai greu să gestionezi versiunile aplicației
  • primești mail-uri care îți solicită să rezolvi probleme pe care nu le poți rezolva pentru că nu ai acces pe server
  • în cazul în care sunt erori în release package nu le poți corecta pt că nu ai mediu de testare
  • analistul de business vrea implementarea cât mai repede, DBA-ul nu poate face implementarea pt că sunt erori în pachet și dezvoltatorul nu poate corecta erorile pt că nu are un mediu unde să poată testa pachetul de implementare ca și când ar fi executat de DBA.

Users!

Pe De steffy82iancuLasă un comentariu

Lucrez la o aplicație Oracle APEX de masterdata management. Practic, utilizatorii încarcă un fișier excel, aplicația îl procesează și înregistrează datele în baza de date. Aplicația arată frumușel, are un dashboard, are partea de upload fișier și procesare fișier; în plus mai are și niște rapoarte.

Toate bune și frumoase, dezvolt eu aplicația, urmează un ciclu de testare-modificare și în final, aplicația ajunge la utilizatori pentru o primă evaluare.

Apar niște cerințe suplimentare, printre care și: atunci când aleg fișierul pt upload, nu vreau să folosesc butonul de Browse ci să fac drag and drop.

Pentru mine, cerința aceasta, de drag and drop file în loc de browse file este o definiție tipică a cuvântului utilizator. Aveți alte exemple de cerințe venite de la utilizatori care merită menționate?

Oracle Autonomous Database

Pe De steffy82iancuLasă un comentariu

Mi-am propus să vă arăt cât de ușor este de folosit Oracle Autonomous Database. Asta și pt că am aflat că de curând au lansat pentru dezvoltatori opțiune Always free.

În filmulețele de mai jos prezint toți pașii de urmat pentru a putea dezvolta o aplicație APEX folosind Oracle Autonomous Database. Avem access la toate tool-urile necesare și nu trebuie să ne facem griji pentru partea de admnistrare baze de date (Oracle spune că Oracle Autonomus Database este prima bază de date self-driving, self-securing, self-repairing).

Opțiunea always free care este dedicată personelor care vor să invețe despre depozite de date, baze de date operaționale sau machine learning. Oracle pune la dispoziție in the cloud infrastructura de care avem nevoie fie că vorbim de baze de date pentru raportare, baze de date operaționale sau machine learning .

Practic, trebuie că ne deschidem un cont aici.

Deși always free înseamnă well … always free, Oracle solicită la creare contului detaliile cardului. Bănuiesc că datele contului sunt necessare pt situația în care dorim să facem upgrade și să folosim serviciile cloud nu doar pt a învăța sau pentru a prezenta un prototip, dar și pentru a rula o aplicație aflată în producție sau care aduce un beneficiu material. Oracle mai specifică faptul că s-ar putea ca o mică suma să fie extrasă din cont și înapoiată apoi…

Acum, câteva filmulețe despre pașii pe care i-am urmat:

  1. am creat contul dar a fost un proces greu din care am învățat următoarele:
  • Oracle solicită adresa și apoi și datele cardului bancar. Țara pe care o completăm la adresă trebuie să corespundă cu țara pe care este înregistrat cardul bancar.
  • trebuie să așteptăm cam 3-5 minute după creare contului pentru mailul de confirmare de la Oracle – de verificat și folderul Spam; nu primim notificare că trebuie să verificăm mailul.
  • trebuie să ne conectăm cu adresa de email și parolă, nu cu username și parolă (cel puțin pentru mine nu a mers cu username și parolă)
Oracle Cloud Free Tier la prima vedere

2. am făcut un tur ca să văd cam care sunt serviciile de care pot beneficia și am creat o baza de date de test

Oracle Cloud Free Tier – prezentare generală servicii

3. am setat tool-urile necesare pentru a dezvolta o aplicație APEX

Oracle Cloud Autonomous Database – setare tool-uri pt Oracle APEX

4. am mai explorat puțin și ce avem la dispoziție pentru machine learning

Exceptând partea de creare cont, totul a mers mult mai rapid decât mă așteptam. O surpriză este faptul că avem access la partea de machine learning . Astfel, putem folosi datele pe care le avem deja și putem folosi diverși algoritmi putem a afla data insights, pentru a face estimări mai bune sau pentru a ușura munca utilizatorilor.

SELECT-ROMINFO a devenit oficial partener Oracle

Pe De steffy82iancuLasă un comentariu

Suntem foarte bucuroși să vă anunțăm că în sfârșit am devenit parteneri Oracle!

Am lucrat de la început cu diferite tehnologii Oracle, specializarea noastră fiind dezvoltarea de aplicații Oracle APEX și migrare de date folosind PL/SQL.

Statutul de membru Oracle înseamnă practic că avem o colaborare mai strânsă cu Oracle și putem dezvolta, vinde și implementa soluții Oracle 1-click printre care și Oracle Database Standard Edition 2.

Un avantaj extrem de important pt noi este că obținem vizibilitate în rețeaua de clienți și parteneri Oracle fiind listați în Oracle Solutions Catalog și în Oracle Cloud Market. În plus, putem beneficia de reduceri la diferite training-uri oferite de Oracle, reduceri pentru soluții implementate pe platformele Linux și Oracle VM Support.

Filling gaps

Pe De steffy82iancuLasă un comentariu

Orice companie care folosește o bază de date și diferite sisteme operaționale de tip ERP sau CRM, are nevoie de aplicații custom made care să umple golurile lăsate de implementările tool-urilor venite la pachet.

Câteva exemple de goluri care sunt umplute de APEX: import/export de fișiere între diferite medii, utilizare servicii web care citesc datele dint-un mediu și le inserează în altul, rapoarte care nu sunt oferite în standard de tool-urile de ERP sau CRM, mici aplicații interne care sunt folosite de diverse departamente (aplicații de HR, aplicații de gestionare master data, aplicații de tracking diferite produse, aplicații folosite pentru data visualisation)

Multe companii folosesc Oracle Application Express (Oracle APEX) pentru partea de raportare. Practic, își construiesc un tool de BI pornind de de la zero. Procedând așa, avem mai multe avantaje:

  • economisim timpul analiștilor de business care în loc să se ocupe de elaborarea efectivă a rapoartelor (adună date, verifică corectitudinea lor, prezinta frumos datele în raport) , se vor ocupa de interpretarea datelor, de identificarea diferitelor pattern-uri, de îmbunătățirea proceselor de business.
  • tool-ul de BI va fi ușor de folosit și rata de adopție printre utilizatori va fi crescută. Asta pt că utilizatorii sunt implicați de la început în definirea tool-ului pe care îl vor folosi.
  • îmbunătățim procesele de business pentru că practic definind indicatorii de performanță (KPI) și rapoartele de excepții, vedem unde se pierde timp cu acțiuni repetitive care pot fi automatizate.

Un alt avantaj al dezvoltării de aplicații Oracle APEX este acela că aceste aplicații trebuie definite de la zero împreună cu cineva de la business. Prin urmare, toate eforturile sunt îndreptate către rezolvarea problemei de business și nu către cum anume procedăm din punct de vedere tehnic. Dezvoltarea efectivă a aplicației este foarte ușor de făcut și extrem de rapid, astfel încât aplicația poate fi folosită de utilizatori imediat și apoi îmbunătățită incremental conform cerințelor acestora.

Old systems

Pe De steffy82iancuLasă un comentariu

În prezent lucrez pe un proiect nou și sunt abia la început. Este vorba de un sistem vechi de gestiune a stocului de articole dintr-un supermarket. Baza de date este Oracle, interfața este in Java și procedurile Oracle sunt rulate sub Unix…

Zilele astea am încercat să înțeleg de ce avem valoarea X într-o anumită coloană…buuun, destul de simpul, nu?… task standard pt un dezvoltator PL/SQL… Caut eu frumos în toate pachetele (vreo 30) și triggerii care folosesc tabela mea, încerc să înțeleg codul care a fost inițial scris (de altcineva) acum vreo 10 ani și corectat în ultimii 3 ani, ok, identific pachetele în cauză și gata, credeam că am rezolvat: aici facem insert, aici facem update, super.

Dar nuuuu, ei bine, mai există numeroase alte programe care apelează într-o anumită ordine procedurile mele și se pare că persoana care știe cam tot istoricul și tot fluxul ETL este în vacanță… Of course, documenție puțină…

Mă întreb oare: ar fi fost mai bine să avem tot fluxul de date reprezentat vizual într-un tool de ETL ca Pentaho sau ODI?

Development cycle

Pe De steffy82iancuLasă un comentariu

Cât de mult țineți la respectarea procedurilor? Pentru voi, care este diferența între cum ar trebui să lucrăm și cum lucrăm de fapt când dezvoltăm un produs software?

Ce ați face în următoarea situație? Tocmai ce ați implementat pe PROD un nou release package. Aveți o eroare care necesită hot fixing pe PROD și soluția este deja implementată pe mediul de testare dar nu a fost inclusă în versiunea curentă de release package și nici testată suficient.

Cum ar trebui să acționeze programatorul, arhitectul, project manager-ul? Ar trebui să acționeze exact la fel pentru toate erorile similare sau ar trebui să acționeze diferit în funcție de cine solicită corectarea erorii? Contează dacă clientul știe despre eroare sau nu?

Cred că toată lumea ar raspunde aici, sigur că da, contează cine știe despre eroare… Ar trebui să nu conteze, nu? Ar trebui să urmărim procedurile definite pentru fiecare situație în parte. Doar că, e o diferență între cum ar trebui sa fie lucrurile, teoretic, și cum sunt ele aplicate în practică.

Wardrobe

Pe De steffy82iancu1 comentariu

Ieri m-am gândit la şifoniere, la şifoniere de date…

Pe proiectul actual, colegii mei nu vor sa implementeze logica clasică de DWH în care ţinem istoricul modificării datelor (pt incremental load) cam aşa:

ID, coloane tehnice(batch_id, load_date), coloana1…coloanan, valid_from, valid_to, current_flag, is_deleted, last_seen_date… 

Motivul este: pierdem mult timp pentru a construi ceva. Alt motiv nespus este ca e de muncă.

Soluţia propusă de ei este să păstrăm copii ale tabelelor(snapshot) pentru fiecare zi. OK, asta este o tehnica destul de folosită, insă doar in anumite cazuri.

Utilizând soluţia cu snapshot propusă de colegii mei, DOAR DACA NE TREBUIE (cerut de business, negociat, trecut prin faza că asta nu se poate), well, ATUNCI şi DOAR ATUNCI, construim ceva care este similar cu logica clasică de mai sus…ceva care să ne permită să analizăm datele cu uşurinţă.

Până atunci, păstrăm datele în “snapshot” pt că spaţiul nu este o problemă…

…ca in şifonierul unora dintre noi….avem multe haine, ştim că sunt acolo dar nu prea le găsim şi când le găsim ne dăm seama că nu mai sunt potrivite….