Aplikacje webowe a przetwarzanie danych statystycznych

Question

Witam,

Jestem na VI semestrze Informatyki i Ekonometrii, co za tym idzie zbliża się czas pisania inżynierki. Wymóg uczelni co do pracy inżynierskiej na tym kierunku jest taki, że musi być w niej zawarta część informatyczna oraz statystyczna/modelowanie danych itp. Z racji na to, że na co dzień siedzę w webówce(głównie laravel i vue) to przez lenistwo chciałbym dostosować to co umiem pod inżynierkę.

Do głowy przyszły mi dwa pomysły:

Pierwszy z nich to napisane aplikacji pokroju e-wizyta, np umawianie wizyt online do przychodni(webówka - część informatyczna), gdzie zbieramy dane od pacjentów i na ich podstawie generujemy raporty(statystyki). Przykładowe dane do gromadzenia:

Wiek pacjenta

• Płeć
• Miejsce zamieszkania (wieś, miasto do 10 000 mieszkańców, miasto do 100 000 mieszkańców, miasto do 250 000 mieszkańców, większe miasto)
• Rodzaj wizyty (konsultacja, badanie, szczepienie, itp.)
• Rodzaj ubezpieczenia zdrowotnego (publiczne, prywatne)
• Występowanie chorób przewlekłych
• Typ lekarza/specjalisty, do którego umawiana jest wizyta
• Liczba osób w gospodarstwie domowym pacjenta
• Liczba wcześniejszych wizyt w przychodni w ciągu roku
• Czy pacjent korzysta z usług opieki zdrowotnej w innych placówkach
• Preferowany sposób płatności za wizytę
• Liczba zarejestrowanych przypadków danej choroby w określonym obszarze geograficznym
• Częstość występowania określonych objawów lub dolegliwości wśród pacjentów
• Wybór kanałów komunikacji przez pacjentów (telefon, e-mail, aplikacja mobilna)
• Częstotliwość korzystania z recept papierowych vs. elektronicznych
• Liczba przypadków nagłych wizyt medycznych vs. umówionych wizyt planowych
• Preferowany sposób odbioru wyników badań (osobiście, online)
• Pytanie o ocenę nawyków żywieniowych
• Wpływ czynników środowiskowych na zdrowie pacjentów
• Stopień dostępności usług medycznych w różnych obszarach geograficznych

Martwi mnie trochę obliczanie danych statystycznych, znalazłem libke która ma kilka funkcji związanych ze statystyką, jednak przez to, że nigdy nie miałem do czynienia z pisaniem tego typu rozwiązań to nie jestem pewien czy w ogóle sam zamysł takiej aplikacji jest realny.

Moim drugim pomysłem jest porównanie Reacta i Vue pod względem performance'u. Zamysł byłby taki, aby stworzyć np forum internetowe, jako backend wykorzystać Laravela + Inertie, dzięki czemu tworzenie frontu odpowiednio w Vue i Reactie będzie bazowało na dokładnie tym samym backendzie i systemie routingu, różnica będzie tylko na froncie - czyli to na czym de facto mi zależy. Pytanie które miałbym w tym przypadku to jakie dokładne parametry tych frameworków można mierzyć i przy pomocy jakich narzędzi? Czy zwykłe devtoolsy + react/vue tools zapewniają wszystkie dane które warto byłoby uwzględnić w takiej analizie?

Oczywiście zadając to pytanie nie mam na celu wyciągnięcia gotowego przepisu na temat pracy, jest to bardziej rozeznanie w temacie, żeby potem nie obudzić się z ręką w nocniku. Chętnie również wysłucham innych pomysłów na połączenie webówki i statystyki.

Comments

Chcesz mierzyć wydajność czyichś narzędzi? Sam pomysł brzmi jakbyś kompletnie olał część związaną ze statystyką. Dochodzi kwestia RODO i innych wymagań, ale znowu kwestia uczelni i wymagań promotora. 

Moim drugim pomysłem jest porównanie Reacta i Vue pod względem performance'u. Zamysł byłby taki, aby stworzyć np forum internetowe, jako backend wykorzystać Laravela + Inertie, dzięki czemu tworzenie frontu odpowiednio w Vue i Reactie będzie bazowało na dokładnie tym samym backendzie i systemie routingu, różnica będzie tylko na froncie - czyli to na czym de facto mi zależy. Pytanie które miałbym w tym przypadku to jakie dokładne parametry tych frameworków można mierzyć i przy pomocy jakich narzędzi? Czy zwykłe devtoolsy + react/vue tools zapewniają wszystkie dane które warto byłoby uwzględnić w takiej analizie?

Ten akapit jest kompletnie od czapy imo. Skupiasz się na narzędziu, nie problemie. Pytanie jakie powinieneś sobie zadać, to jaki problem chcesz rozwiązać. 

---

Chcesz mierzyć wydajność czyichś narzędzi? Sam pomysł brzmi jakbyś kompletnie olał część związaną ze statystyką.

Okey, ale np można byłoby mierzyć czasy pomiędzy rozpoczęciem rendeorwania komponentów a zakończeniem ich renderowania na stronie(czyli de facto ile komponent się renderuje) i na na podstawie takich danych obliczać podstawowe wartości statystyczne - jakieś średnie, odchylenia standardowe itp i na podstawie tych wartości wyciągać jakieś wnioski(a to o to też chodzi w analizie statystycznej), np jeżeli odchylenie standardowe czasów renderowania komponentów byłoby mniejsze dla Vue, to oznacza, że mierzone wartości są bliżej średniej, czyli dla Vue nie ma aż tak dużego znaczenia czy renderowany komponent jest "duży", czy "mały". Inną opcją jest mierzenie liczby rerenderów i porównanie podejścia sygnałowego(Vue) z podejściem reaktywnym(React) - więc chcąc nie chcąc coś tych statystyk się pojawia.

Ten akapit jest kompletnie od czapy imo. Skupiasz się na narzędziu, nie problemie. Pytanie jakie powinieneś sobie zadać, to jaki problem chcesz rozwiązać. 

Chcę podejść do problemu wyboru frameworka pod kątem wydajności narzędzia. Frameworków jest wiele, jedne bardziej popularne, inne mniej, jednie lepiej zoptymalizowanie, inne nieco gorzej. Różne frameworki korzystają z różnych podejść, chociażby co do reaktywności, więc problem wyboru narzędzia do pisania projektu istnieje.

Przeglądając otwarte repozytoria tematów prac z poprzednich lat, które znalazłem w internecie od czasu do czasu pojawiały się tematy porównywania narzędzi, np Analiza i porównanie popularnych silników gier 2D. Zatem prace w podobnej tematyce powstają - stąd mój pomysł na napisanie czegoś w tym stylu.

Oczywiście jeżeli zauważasz jakieś błędy w moim toku myślenia z chęcią ich wysłucham.

---

Okey, ale np można byłoby mierzyć czasy pomiędzy rozpoczęciem rendeorwania komponentów a zakończeniem ich renderowania na stronie(czyli de facto ile komponent się renderuje) i na na podstawie takich danych obliczać podstawowe wartości statystyczne - jakieś średnie, odchylenia standardowe itp i na podstawie tych wartości wyciągać jakieś wnioski(a to o to też chodzi w analizie statystycznej), np jeżeli odchylenie standardowe czasów renderowania komponentów byłoby mniejsze dla Vue, to oznacza, że mierzone wartości są bliżej średniej, czyli dla Vue nie ma aż tak dużego znaczenia czy renderowany komponent jest "duży", czy "mały". Inną opcją jest mierzenie liczby rerenderów i porównanie podejścia sygnałowego(Vue) z podejściem reaktywnym(React) - więc chcąc nie chcąc coś tych statystyk się pojawia.

Czyli benchmark narzędzi dostępnych na rynku. W tym przypadku dwóch wybranych przez Ciebie. Generalnie moim zdaniem temat do przyjęcia o ile postawisz problem. Póki co go nie widzę, a praca inżynierska opiera się na schemacie problem->rozwiązanie. Jak zdefiniujesz przypadek/przypadki testowe, to temat będzie miał sens. Jeżeli rzucisz ogólnym tematem "który framework jest lepszy/szybszy", to za 5 sekund przyjdzie ktoś i podważy Twoją pracę. 

Chcę podejść do problemu wyboru frameworka pod kątem wydajności narzędzia. Frameworków jest wiele, jedne bardziej popularne, inne mniej, jednie lepiej zoptymalizowanie, inne nieco gorzej. Różne frameworki korzystają z różnych podejść, chociażby co do reaktywności, więc problem wyboru narzędzia do pisania projektu istnieje.

I to jest git. Ta część z danymi pacjentów wydaje mi się kompletnie od czapy biorąc w jakim stylu i tonie napisałeś swoje chęci co do wyboru pracy. Bo widać, ze mocno kierujesz się w stronę narzędzi, a nie problemu stricte matematycznego gdzie narzędzia są tylko dodatkiem. 

Analiza i porównanie popularnych silników gier 2D. Zatem prace w podobnej tematyce powstają - stąd mój pomysł na napisanie czegoś w tym stylu.

Kwestia "jakości" promotora. Zgodnie ze sztuką praca inżynierska powinna rozwiązywać problem. Musisz go zdefiniować na przykład jako wymaganie, które jest potrzebne w aplikacjach typu e-pacjent czy cokolwiek innego. Problem to duża ilość danych(wstępnie przygotowanych lub też nie) i sposób ich wizualizacji. 

 

Samo podejście jest mi znane z moich czasów studenckich gdzie zdecydowana większość za bardzo skupiła się CZEGO użyje, a nie JAK. I w ten sposób powstawały mierne projekty, które były idealnym przykładem overengineeringu. Kwestia czy na tym Ci zależy. 

---

@mb-dir, Zdecyduj się co jest daną, którą wprowadzasz do systemu  w ramach jego używania a co jest wynikiem statystycznym generowanym przez system po jakimś czasie na podstawie zebranych danych. Np. masz punkt

• Liczba zarejestrowanych przypadków danej choroby w określonym obszarze geograficznym

To ma być wprowadzane czy obliczane przez system?

Jeśli to drugie to nigdzie w innych pozycja nie masz nic o konkretnej chorobie (diagnoza ?) a o miejscu zamieszkania wiesz tylko jak duża miejscowość.

Podobnia z objawami - masz jakąś statystykę (częstotliwość) ale nie masz objawów zgłaszanych przez konkretnego pacjenta w czasie jednej wizyty.

I jeszcze podobnie z receptami - jest jakaś statystyka, a nie ma jaką recepte dostał pacjent. itp.

---

@tkz, 

Samo podejście jest mi znane z moich czasów studenckich gdzie zdecydowana większość za bardzo skupiła się CZEGO użyje, a nie JAK. I w ten sposób powstawały mierne projekty, które były idealnym przykładem overengineeringu. Kwestia czy na tym Ci zależy.

Ten fragment zmienia mój punkt widzenia o 180 stopni, bo przyznam, że nie byłem tego świadom. Oczywiście na uczelni też nikt tego tak nie ujął. I teraz widzę, że zarówno pomysł na porównanie narzędzi, jak i apke dla przychodni lekarskiej, może i mają sens i da się je obronić, ale były błędnie sformułowane. Dzięki śliczne za te odpowiedzi, teraz nieco łatwiej będzie mi rozmawiać z promotorem. Raz jeszcze dzięki!

---

@Oscar, tbh na potrzeby pisania mojego postu wpisałem jakiekolwiek statystyki, które kojarzyły mi się z działaniem systemu zdrowia, po to aby dać kontekst mojego pomysłu, ale faktyczne widzę że nie wszystko ze sobą trybi. Oczywiście gdybym się decydował na pisanie czegoś takiego uzgodniłbym z promotorem kwestie jakie dane mają być zbierane -> jakie statystyki mają być generowanie. Nie mniej jednak that's a good point