Monitorizare gratuită pentru ambulanțe, măști și ventilatoare donate pentru medici

monitorizare gratuita

Servicii de monitorizare, în mod gratuit pentru ambulanțe de stat

Observăm o #solidaritate incredibilă între mediul privat și mediul de stat, date fiind circumstanțele actuale cauzate de COVID-19. Nu puteam să rămânem indiferenți la mișcarea globală determinată de această situație și ne-am alăturat ei prin sprijinirea comunităților locale.

TrackGPS, divizia de monitorizare de flotă a AROBS, bate cotul (conform noilor prevederi de siguranță) cu toate ambulanțele de stat din portofoliu, oferindu-și serviciile de monitorizare în mod gratuit, pe întreaga perioada a urgenței naționale. Mai mult decât atât, unități medicale din mai multe orașe au primit donații din partea AROBS, pentru a ajuta pe cei din prima linie în lupta cu virusul.

De ce necesită ambulanțele monitorizare?

De fiecare dată când o persoană necesită serviciile ambulanțelor, cei mai critici factori țin de timpul de reacție și durata rutei. Prin servicii de monitorizare se asigură nu doar cea mai eficientă rută ci și autovehiculul proxim.

De altfel, să nu uităm de organizare. În fiecare domeniu în care timpul de reacție este strâns legat de șansele de supraviețuire a unei persoane, organizarea este vitală. Prin centralizarea informațiilor despre ambulanțe, deciziile sunt bazate de date fixe, astfel rata de succes a unei intervenții crește considerabil.

Câte ambulanțe

Aceste servicii eficientizează munca a peste 1400 ambulanțe de stat, adică cel puțin 3000 de cadre medicale. Pe perioada urgenței naționale, efortul acestor echipe va fi completat cu cea a specialiștilor Track, care își vor folosi tot know-how-ul tehnic pentru a fi de ajutor.

Instituțiile medicale, acum, trebuie să își concentreze toate resursele pentru lupta colectivă împotriva pandemiei.

Suntem cu ei.

#solidaritate

Măști speciale FFP2 donate medicilor

Uneori un simplu obiect poate face diferența în a-ți asigura sănătatea și protecția, precum un igienizant sau o mască. Luând în considerare nevoia copleșitoare de echipemente medicale determinat de valul COVID-19, nu puteam decât să ne mobilizăm și să contribuim cu ce ne stă în putere.

Ca urmare a acestei decizii, 50.000 de măști FFP2, în valoare de aproape 235.000 euro,  au fost achiziționate în scopul de a fi donate de către AROBS  comunităților  în care compania are filiale.

16.000 de măști au fost deja livrate către mai multe spitale și unități medicale de primire a pacienților:

  • Spitalul Clinic Municipal Clujana,
  • Spitalul de Recuperare Cluj,
  • Spitalul Clinic de Pneumoftiziologie Leon Daniello Cluj-Napoca (și secția de chirurgie a acestuia),
  • Ambulatoriul de Specialitate Stomatologie al Spitalului Clinic Județean,
  • Institutului Oncologic „Prof. Dr. Ion Chiricuţă”,
  • Spitalul Municipal Campia Turzii,
  • Spitalul Municipal Dej,
  • Spitalul Municipal Gherla,
  • Spitalul Municipal Huedin,
  • Spitalul Municipal Turda.

 

ARAD

  • Spitalul Clinic Județean de Urgenta Arad,
  • ISU Arad.

 

Mureș

  • Spitalul Clinic Județean Mureș,
  • UPU SMURD Mureș,
  • Serviciul public de Ambulanță Mureș.

 

Maramureș

  • Spitalul de Pneumoftiziologie “Dr. Nicolae Rusdea” Baia Mare,
  • Serviciul de Ambulanţă Judeţean Maramureş,
  • Spitalul de Boli Infecțioase și Psihiatrie Maramureș.

 

Iași

  • Spitalul Clinic de Pneumoftiziologie Iaşi.

48 de aparate Hypnus non-invazive donate pentru pacienții bolnavi

Pentru pacienții care manifestă deja simptome avansate ale virusului, reapirația poate deveni aproape imposibilă. Prin urmare, AROBS a donat 48 de ventilatoare speciale Hypnus Anti Coronavirus non-invazive pentru tratamentul pacienților, către unități medicale din mai multe orașe ale țării.

Acestea pot fi vitale în tratamentul aplicat cât și în creșterea ratei de supraviețuire a pacienților. Aparatul dispune de funcții care permit deopotrivă monitorizarea mai multor pacienți concomitent.

Distribuția aparatelor s-a făcut în funcție de necesitatea ridicată și deja se află la mai multe spitale importante din țară:

  • Spitalul de Pneumoftiziologie “Dr. Nicolae Rusdea” Baia Mare
  • Spitalul Clinic de Pneumoftiziologie Iaşi
  • Spitalul Clinic Județean Mureș
  • Spitalul Clinic Judetean de Urgenta Arad
  • Spitalul Județean de Urgență ”Sf. Ioan cel Nou” Suceava.

Despre TrackGPS

TrackGPS este soluția de monitorizare flote numărul 1 din România.

Când vine vorba de servicii publice, trebuie să notăm că aceste servicii stau la baza funcționării societății. Importanța lor este indubitabilă.

Pentru ca aceste servicii să funcțiuneze într-un mod eficient, astfel toată societatea, au nevoie de soluții de management și monitorizarea complexe. De soluții ca acces real-time despre locația exactă a vehiculelor.

TrackGPS, o soluție AROBS contribuie activ în timp de urgență la buna funționarea a societății.

Află mai multe despre alte soluții AROBS, aici.

Sau, vezi articolul în Forbes România.

Pentru consultanță, lasă un mesaj!

Citește cele mai noi postări de blog

Urmărește-ne pe social media

QA automation- pastile greu de înghițit

software testing services

QA automation- pastile greu de înghițit

Subiecte ale acestui articol: servicii de testare software, QA automation, QA testing în software development. 

Despre autor: Răzvan Vușcan este QA Automation engineer pe divizia noastră de Travel&Hospitality Software 

Ideea acestui articol mi-a venit după mai multe experiențe și lecții învățate de-a lungul timpului, făcând  QA automation pentru servicii software în travel. Majoritatea aplicațiilor web au un impact mare asupra gestionării unui software de călătorie. Când am început pentru prima dată, eram dornic să învăț, să explorez, dar și să încerc să fac totul ca la carte.  M-am gândit că trebuie să automatizez totul și am simțit că limbajul de programare și instrumentele folosite la acea vreme (Java și Selenium Webdriver) sunt biletul meu către succes. Cel puțin pentru că aproape toată lumea le folosea. Chiar credeam că sunt cele mai potrivite pentru automation testing și nu aveau concurență vreo altă aplicație web. Și teoria mea a funcționat …pentru o vreme. 

Procesul serviciilor de testare software 

 Apoi vremurile s-au schimbat. Serviciile de testare software au devenit mai complexe, iar principalele aplicații web de călătorie la care am lucrat la început, au început să se îndepărteze de structura lor monolitică.  Acelea scrise folosind limbaje de programare convenționale, cum ar fi Java sau .Net. Limbile de scripting precum Javascript au început să câștige din ce în ce mai mult teren. Interfețele utilizatorului erau mai rapide, fluxul convențional care ducea utilizatorii de la o pagină la alta se îndrepta către aplicații cu o singură pagină, care erau toate încărcate pe aceeași pagină în mod asincron. 

Desigur, acest lucru complica lucrurile și am simțit că instrumentele pe care le-am folosit deveneau prea pretențioase pentru noile interfețe de utilizator. Testele deveniseră neplăcute, deoarece nu puteau suporta încărcarea corectă a evenimentelor sau sincronizarea animațiilor și apelurilor. 

Așa că, inițial, am început să găsesc soluții tehnice la aceste probleme. Întrucât la vremea respectivă făceam doar QA automation testing pentru software de gestionare a călătoriilor și nici o testare manuală, nu îmi puteam permite să implementez tot felul de piese de logică pentru a face față problemelor tehnice din cadrul testului. Dar mentenanța începea să devină un coșmar. Simțeam că nu ajung nicăieri. Ulterior, am început să înțeleg mult mai bine cadrul testului și am început să folosesc mult mai mult limbajul de programare decât pentru scrierea testelor. 

Am construit chiar mai multe cadre noi de la zero pentru a experimenta diferite teorii și abordări. De asemenea, am lucrat mult mai mult la conductele de integrare continuă, încercând să le grăbesc, să le împart pentru a deveni mai eficiente și a genera rapoarte mai bune cu un timp de transformare rapid. 

Nu vă uitați rădăcinile  

Dar, pe măsură ce am avansat pe această cale de developer/ ca DevOps, mă îndepărtam de rolul meu inițial de tester. Soluțiile mele tehnice deveneau din ce în ce mai complexe. De exemplu, Mă concentram prea mult asupra modului de a scrie logica pentru a ocoli o problemă de încărcare, în loc să accept doar că, probabil, pagina / codul este anormal de lent și  ar fi bine să vorbesc cu developerii să se uite la bug și să găsească o comună. 

Așa că acesta a fost momentul meu de ”aha!”: petreceam prea mult timp să găsesc soluții prea complicate la probleme evidente de utilizare care ar putea deranja pentru un utilizator, precum și să fac prea multă mentenanță pe framework-ul procesului de testare automată și a conductelor de integrare continuă. 

Ceva trebuia făcut. Așadar, am început să fac niște introspecții. Am început prin a-mi revizui sistemul de valori și a-mi da seama de ce vreau să fiu tester în primul rând. Mi-am amintit că lucrurile ar trebui să fie alb-negru când vine vorba de testare: fie este o eroare, fie nu. Desigur, următorul pas a fost să revizuiesc testele automate din software-ul de travel la care lucram. Am observat că acestea deveniseră prea lungi și prea complexe, luând prea mult timp pentru a funcționa așa că trebuia să găsesc o soluție. Pe scurt, mi-am dat seama că, de multe ori, erau din start predispuse la eșec pentru că în loc să se ruleze de la început la sfârșit, se opreau foarte des întâmpinând probleme. Așa că a trebuit să-mi dau seama de o soluție de fragmentare a acestor teste care au devenit mamuți, în biți atomici independenți, care se concentrează pe testarea unui singur lucru. 

Fii deschis la nou 

În cele din urmă, cel mai greu a fost să recunosc că instrumentul de testare și limbajul de programare pe care îl foloseam nu se potriveau nevoilor menționate mai sus. Aplicații: Interfațele utilizatorului erau acum transformate prin puterea ” React” sau ”Angular”. Lucruri precum GWT sau Drupal au fost abandonate în favoarea primelor două. Așadar, am avut nevoie să găsesc un instrument de testare care să funcționeze bine cu apelurile asincrone de JavaScript pe o pagină web, pentru a petrece mai puțin timp făcând întreținere și mai mult timp făcând scripturi de test pentru proiectul dat al serviciilor de testare software. 

În cele din urmă, am găsit ceva care a funcționat pentru mine: NightwatchJs, care este un cadru de test de la un capăt la altul scris în NodeJs. Curba de învățare nu a fost atât de dificilă și trecerea de la Java și Selenium Webdriver nu este la fel de dureroasă cum mă așteptam inițial. Mi-a plăcut mult faptul că Nightwatch era ușor de integrat cu Cucumber și putea oferi rapoarte de testare scrise într-un text care poate fi citit de om, pe care orice utilizator l-ar înțelege. 

De asemenea, a acceptat caracteristici împărțite în scenarii descriptive cu pași clari. 

În total, un cadru de testare puternic, dar ușor de utilizat și de menținut, ceea ce mi-a permis să mă concentrez mai mult pe scrierea testelor de la un capăt la altul pentru interfața cu utilizatorul, dar a avut și potențialul de a scrie teste de strat API, din cauza scrierii în Nodejs. 

Lecția 

Cred că cea mai mare lecție pe care am învățat-o a fost că uneori trebuie să renunți și să o iei de la capăt, în loc să rămâi blocat folosind un singur instrument de testare sau limbaj de programare. 

Cel mai bun instrument pentru meserie nu este întotdeauna ceea ce folosește masele. Așadar, nu vă fie teamă să căutați ceva mai potrivit pentru proiectul dvs., deoarece am încercat să îl găsesc pe cel potrivit pentru software de gestionare a călătoriilor, în cazul meu. Dacă ajungeți să pierdeți prea mult timp cu soluții tehnice sau să faceți întreținere, atunci ar trebui să vă regândiți la abordare și să analizați direcția pe care o urmați înainte de a fi prea târziu. 

Pentru consultanță, lasă un mesaj!

Urmărește-ne pe social media