Kto zyskuje a kto traci?

Tak jak zapowiadałem - ten wątek jest po części rozwinięciem tego wątku:
https://4programmers.net/Forum/Nietuzinkowe_tematy/367302-java_java_i_co_dalej?page=1
Niestety będzie dużo czytania, ale to efekt tego, że starałem się żeby to było zrozumiale opisane.

Chciałem opisać tutaj coś, co wydaje mi się, że nie dla wszystkich zajmujących się oprogramowaniem jest takie oczywiste.
To "coś" to pewnego rodzaju zależności i wiążące się z nimi wymagania oraz ich rezultaty.

Skupiając się może najpierw na wymaganiach odnośnie softu a już bardziej może konkretnie na aplikacjach z GUI
to te wymagania stawiane są co zrozumiałe przez usera końcowego..
Jeśli user zażyczy sobie czegoś to ta aplikacja musi mu tego dostarczyć. Teraz patrząc już z punktu widzenia programisty
to te wymagania idą od najwyższych warstw softu (GUI), poprzez pośrednie (libki), drivery i firmware (najniższa warstwa) aż do sprzętu.

Przykład: user ma telefon z androidem i klika na wybrany filmik w YT. To kliknięcie usera jest przekładane na masę requestów w kolejnych poziomach softu poniżej GUI. Finalnie pewne requesty muszą trafić do sprzętu, bo trzeba przecież jakoś pobrać dane filmiku z netu np. przez wifi, uruchomić w sprzęcie odtwarzanie dźwięku i obrazu userowi.

Upraszczając GUI odwołuje się do jakichś libek graficznych, dźwiękowych i sieciowych a te z kolei do driverów, drivery czasami do firmware a te do sprzętu.
Czyli jest tak, że te wymagania są stawiane przez GUI a wszystko co poniżej musi być podporządkowane tym wymaganiom.

I teraz popatrzmy na wymagania na kolejnych poziomach idąc od najwyższego:

• GUI musi tylko zapewnić userowi user-friendliness i fun
• warstwy poniżej GUI czyli np. biblioteki muszą zapewnić GUI łatwy dostęp do netu, obrazu i dźwięku
• drivery + ewentualnie firmware muszą zapewnić szybki, wydajny dostęp do surowych danych i funkcjonalności sprzętowych
• sprzęt ma zapewnić fizyczny dostęp do pewnych zasobów

A teraz o zależnościach (tu idziemy w drugą stronę czyli od dołu do góry):

• jeśli sprzęt będzie wolny (używanie wolniejszego wifi, wolniejszego procka, pamięci, etc) - wszystko co powyżej będzie wolne
• jeśli drivery + ewentualny firmware będą źle napisane i będzie wolno działać to libki nic na to nie będą w stanie poradzić i będą wolniej działać
• jeśli libki będą źle napisane to GUI będzie wolniejsze
• jeśli GUI będzie źle (np. nieoptymalnie) napisane user będzie niezadowolony

Wniosek nr 1:
Najwięcej zależy od sprzętu, drugie w kolejności są firmware i drivery, dalej libki a na samym końcu GUI.

Wniosek nr 2:
Co do GUI są stawiane najmniejsze wymagania, a najgorzej ma tutaj sprzęt, drivery i firmware więc im niżej (im bliżej sprzętu) tym większa presja i odpowiedzialność na osobach odpowiedzialnych za ich obsługę.

Jak to się przekłada na oczekiwania wobec programistów?
Programista GUI może, ale nie musi starać się zbytnio o wydajność i redukcję zasobożerności swojej apki i jemu tylko wystarczy wiedzieć jak używać dostarczonych mu libek.

Programiści low-level: czyli od firmware, driverów i niektórych libek:
taki programista musi wiedzieć jak gadać ze sprzętem, jak gadać z wyższą warstwą (libki) i jaki to dalej ma wpływ na wyższe warstwy softu aż do GUI. Czyli musi wiedzieć prawie wszystko o sofcie, nawet o tym co ma się dziać w GUI.

Wniosek nr 3:.
Im niżej tym więcej trzeba wiedzieć, więcej pracy poświęcić i bardziej trzeba się starać.

A teraz popatrzmy może na wpływ decyzji osób decyzyjnych. Takie osoby zwykle kierują się tylko:

• $$$ w swojej kieszeni
• numerkami w excelu
• wyglądem apki

Apka ma fajnie wyglądać, dawać userowi fun, ma być tanio i szybko napisana i wrzucona na rynek.
Wszystko pozostałe musi być temu podporządkowane.

Efekty:
Ci od GUI mają wolną rękę co do wyboru języka i środowiska programistycznego. A jeśli przyjrzymy się uważniej to konkretne rezultaty są takie:

• język + środowisko wymagające coraz więcej pamięci => potrzeba więcej RAM i SSD żeby to przechowywać => elektronika potrzebna do tego zużywa więcej prądu
• lagujące język + środowisko => potrzeba szybszego CPU (więcej gigaherców i rdzeni) => większe zużycie prądu
• dłuższy czas startu apki spowodowany koniecznością załadowania większej binarki, bibliotek, etc => większe zużycie prądu

Skoro większy pobór prądu to krócej podziała nam telefon na pojedynczym ładowaniu baterii.

Typowy użytkownik wywnioskuje tylko że trzebaby już kupić nowszego fona bo ten nowszy będzie miał pojemniejszą baterię i być może wytrzyma dłużej na niej.

Żeby sprostać wymaganiom użytkownika producent zrobi tak:
weźmy może nowszą, pojemniejszą baterię ale no nie bądźmy zacofani więc weźmy nowszy sprzęt, więc i weźmy nowszy język, nieważne że jeszcze bardziej zasobożerny niż poprzedni.

I co? I tu się chyba zapętlamy. Wygląda to na samonapędzającą się spiralę oczekiwań, zależności i konsekwencji.

Jakieś konstruktywne refleksje w związku z tym?

Niektórym się może wydawać, że ich sprawa nie dotyczy...
Niektórym programistom może wydawać się, że oni nie mają żadnego wpływu na nakręcanie tej spirali...
Niektórym może się wydawać, że jeśli oni mają komfort w pracy i nie muszą się o zbyt wiele starać jak np. o optymalizację kodu to przecież nic złego się nie stanie...
Niektórym programistom może się wydawać, że jeśli oni mają się dobrze, mają swobodę w wyborze zasobożernych rozwiązań to inni programiści nie mogą przecież przez to mieć przerąbane...
Niektórym się wydaje, że to ja jako twórca apki z GUI jestem najważniejszy bo to dzięki mnie user ma odpowiedni UX...
Niektórym może się wydawać, że tylko ja jako twórca okienkowej apki się liczę a cała reszta nie ma znaczenia...

No tak. Wydaje im się. Źle im się wydaje.

Rezultat jest taki, że to, że jednym zapewnia się komfortowe warunki pracy to w rezultacie powoduje to, że inni mają przerąbane.

A teraz jeszcze z punktu widzenia usera końcowego np. takiego smartfona.
Czy aby na pewno z wydania na wydanie kolejnych wersji telefonów te telefony trzymają się wyraźnie dłużej na baterii pomimo coraz pojemniejszych baterii?
Czy taki smartfon da radę wytrzymać np. 2 tygodnie na jednym ładowaniu?

Proponuję przemyśleć pewne rzeczy na bazie tego to co tu powyżej napisałem.

Ale jeśli to jest w jakikolwiek sposób nadal niezrozumiałe to mogę opisać to w jeszcze bardziej łopatologiczny sposób.

Większość ludzi jest szalenie niekompetentna - myślisz ze typowy frontend programista się zastanawia nad driverami? Czasem nawet seniorzy np. React, nie mają pojęcia że ich apka działa przez przypadek - ale działa, nikt za mniejsze zużycie cpu nie zapłaci - chyba że sprawa się rypnie, i nie da się używać na telefonie, czy przy 2x większej ilości danych chodzi 100x wolniej...

To zabrzmi śmieszne, ale bez studiów CS nie powinno się móc wytwarzać software komercyjnie - lub po zdaniu egzaminu ze złożoności obliczeniowej.

A wszyscy PM czy inne managery, bez zdania egzaminu z tematyki zarządzania projektem i metodyk tworzenia oprogramowania.

takie podejście jest promowane ponieważ producenci sprzętu chcą napędzać sprzedaż

Programiści low-level: czyli od firmware, driverów i niektórych libek:
taki programista musi wiedzieć jak gadać ze sprzętem, jak gadać z wyższą warstwą (libki) i jaki to dalej ma wpływ na wyższe warstwy softu aż do GUI. Czyli musi wiedzieć prawie wszystko o sofcie, nawet o tym co ma się dziać w GUI.

Fałsz.

On wystawia API - jakieś podstawowe operacje z których warstwy wyżej korzystają.

Niższe warstwy nie wiedzą nic o warstwach wyżej, o ile nie są to specyficzne przypadki gdzie wystawi się jakieś specyficzne API dla jakiegoś konkretnego przypadku.

Weźmy przykład z kompilatorów - ktoś piszący optymalizator na podstawie języka pośredniego nie musi nic wiedzieć nt. losowego języka który generuje język pośredni.

język + środowisko wymagające coraz więcej pamięci => potrzeba więcej RAM i SSD żeby to przechowywać => elektronika potrzebna do tego zużywa więcej prądu

to też chyba nie zawsze jest prawdą.

Już na starcie wyciągasz błędne wnioski, bo podzieliłeś programistów na "tych odzyskać GUI" oraz "tych od aplikacji" - co już od początku jest niepoprawne.

Ci programiści powinni grać do jednej bramki i całościowo dbać o jakość aplikacji.

Koniec końców wszystko jest wyważeniem koszt/zysk. Końcowy klient wcale nie chce dopłacać do efektywności/szybkości a do ilości featerow. I dotyczy się to także programistów np kwestia ide i jakie są popularne.

Schadoow napisał(a):

Koniec końców wszystko jest wyważeniem koszt/zysk. Końcowy klient wcale nie chce dopłacać do efektywności/szybkości a do ilości featerow. I dotyczy się to także programistów np kwestia ide i jakie są popularne.

Pewnie jest to wyważenie koszt/zysk, ale klienci końcowi, czy choćby nawet nie-programiści zaangażowani w firmie w tworzenie produktu, często dostają fałszywe informacje na temat wysokości tego kosztu i zysku. Stykałem się z sytuacjami, że programista zrobił rozwiązanie, które było 100-krotnie wolniejsze, niż by być mogło, przy porównywalnym stopniu skomplikowania (czyli bez niskopoziomowych optymalizacji) i pretensje o to, że jest wolne, zbywał tekstami w rodzaju "nie warto się bić o te 20% wydajności".

Zwykle osiągnięcie 50% maksymalnej wydajności, nie jest istotnie droższe niż osiągnięcie 0.5% maksymalnej wydajności. Gdyby klienci dostawali pytanie, czy chcą 100-krotnie szybciej działający program, za 20% wyższą cenę, to z pewnością rozkład odpowiedzi byłby zupełnie inny niż na pytanie, czy chcą o 20% szybszy za 10-krotnie wyższą cenę.

WeiXiao napisał(a):

Programiści low-level: czyli od firmware, driverów i niektórych libek:
taki programista musi wiedzieć jak gadać ze sprzętem, jak gadać z wyższą warstwą (libki) i jaki to dalej ma wpływ na wyższe warstwy softu aż do GUI. Czyli musi wiedzieć prawie wszystko o sofcie, nawet o tym co ma się dziać w GUI.

Fałsz.

On wystawia API - jakieś podstawowe operacje z których warstwy wyżej korzystają.

Niższe warstwy nie wiedzą nic o warstwach wyżej, o ile nie są to specyficzne przypadki gdzie wystawi się jakieś specyficzne API dla jakiegoś konkretnego przypadku.

Weźmy przykład z kompilatorów - ktoś piszący optymalizator na podstawie języka pośredniego nie musi nic wiedzieć nt. losowego języka który generuje język pośredni.

Popatrz - pisałem o programistach low-level - że to oni muszą wiedzieć jak gadać z:

• ze sprzętem
• z warstwą wyższą (czyli jak zwrócić tej wyższej warstwie dane, jak jej zasygnalizować asynchronicznie np. że nadeszły nowe dane, wyjątki, etc)

czyli z sąsiadującymi - od góry i od doły warstwami.
Nie pisałem nic, że taki programista tworzy zawsze sobie jakieś API, które jest w stanie sobie przeskoczyć np. najbliższą sąsiadującą warstwę i przekazać dane powyżej.
A ogólnie to, że taki low-levelowiec musi praktycznie wiedzieć prawie wszystko o sofcie, nawet o tym co ma się dziać w GUI to chodziło mi przykładowo o sytuację, kiedy pojawia się jakiś problem gdzieś wysoko, powyżej zakresu bezpośredniej odpowiedzialności takiego low-levelowca. W takim przypadku i tak i tak taki programista musi wiedzieć co się dzieje w każdej warstwie pośredniej, jak np. takie surowe dane, których on dostarcza bezpośrednio ze sprzętu - jak takie dane są później przetwarzane i czy nie ma tu przypadkiem jego winy a jeśli nie to kto inny zawalił. Stąd moje stwierdzenie o wpływie na wyższe warstwy softu.
I to nie tak że "tak mi sie wydaje" - tylko tak mój zespół ma na codzień i nawet kiedy np. taki android ma problem z czymś na wysokim poziomie to i tak i tak muszę uruchomić w całości takiego androida, odpalić wysokopoziomowe testy i zobaczyć co się dzieje na kolejnych wyższych od sprzętu warstwach softu.

Nadal fałsz?

język + środowisko wymagające coraz więcej pamięci => potrzeba więcej RAM i SSD żeby to przechowywać => elektronika potrzebna do tego zużywa więcej prądu

to też chyba nie zawsze jest prawdą.

Tu chodziło przykładowo o to, że zwykle języki+środowisko nie zwijają się w swojej funkcjonalności tylko rozwijają - więc potrzebują większego nośnika danych, a więc większej ilości tranzystorów do przechowania informacji a co zwykle za tym idzie większego poboru energii. Wiem, że elektronika nie stoi w miejscu i też powstają nowe technologie produkcji półprzewodników, ale radziłbym zastanowić się nad tym jaki jest bilans. High-level soft sobie wymaga coraz więcej, sprzętowcy i low-levelowcy dają z siebie coraz więcej - a smartfon ile trzymał na jednym ładowaniu baterii tyle nadal trzyma. Poza tym zauważ, że od wielu lat możliwości podnoszenia gigahareców już nie idą tak do przodu jak dawniej. Nie da się bez końca przyciskać sprzętowców i low-levelowców żeby to oni dostarczyli nam jak najwydajniejsze pod względem szybkości i energooszczędności rozwiązania. A taki spec od GUI nie ma żadnego umiaru w tych żądaniach - jego nikt nie przyciska.

Radzę się zastanowić.

Riddle napisał(a):

Już na starcie wyciągasz błędne wnioski, bo podzieliłeś programistów na "tych odzyskać GUI" oraz "tych od aplikacji" - co już od początku jest niepoprawne.

Ci programiści powinni grać do jednej bramki i całościowo dbać o jakość aplikacji.

Jeśli możesz rozwinąć myśl z pierwszego zdania - może będę w stanie ustosunkować się do niej.

@Troll anty OOP: dolicz sobie koszt wyszkolenia pracownikow do tego. Zwykle to jedt właśnie ten case

20% szybszy za 10-krotnie wyższą cenę

Prowadzenie SH które wytwarza oprogramowanie IMO nie należy do najprostszych rzeczy i często musisz się godzić z duża liczba mało kompetentnych osób.

Ogólnie zgadzam się ze nie warto bić się o 20% szybsze rozwiązanie. Ważniejsze jest łatwość utrzymania itd.

@userek_jakis:

A ogólnie to, że taki low-levelowiec musi praktycznie wiedzieć prawie wszystko o sofcie, nawet o tym co ma się dziać w GUI to chodziło mi przykładowo o sytuację, kiedy pojawia się jakiś problem gdzieś wysoko, powyżej zakresu bezpośredniej odpowiedzialności takiego low-levelowca. W takim przypadku i tak i tak taki programista musi wiedzieć co się dzieje w każdej warstwie pośredniej, jak np. takie surowe dane, których on dostarcza bezpośrednio ze sprzętu - jak takie dane są później przetwarzane i czy nie ma tu przypadkiem jego winy a jeśli nie to kto inny zawalił. Stąd moje stwierdzenie o wpływie na wyższe warstwy softu.

Prawie wszystko o sofcie = wiedzieć jak wywołać low level code z high level code? I ewentualnie zdebuggować?

To że ktoś jest JIT Compiler Engineer w v8 jeszcze nie oznacza że jest dobrym frontend developerem

W takim przypadku i tak i tak taki programista musi wiedzieć co się dzieje w każdej warstwie pośredniej, jak np. takie surowe dane, których on dostarcza bezpośrednio ze sprzętu - jak takie dane są później przetwarzane

To chyba jest coś, co powinni ogarnąć architekci/komitet/projektanci ktokolwiek, ale nie programista?

Programista implementuje specyfikacje, standard, whatever, a nie go projektuje, czy się mylę?

Wiem, że elektronika nie stoi w miejscu i też powstają nowe technologie produkcji półprzewodników, ale radziłbym zastanowić się nad tym jaki jest bilans. High-level soft sobie wymaga coraz więcej, sprzętowcy i low-levelowcy dają z siebie coraz więcej - a smartfon ile trzymał na jednym ładowaniu baterii tyle nadal trzyma. Poza tym zauważ, że od wielu lat możliwości podnoszenia gigahareców już nie idą tak do przodu jak dawniej. Nie da się bez końca przyciskać sprzętowców i low-levelowców żeby to oni dostarczyli nam jak najwydajniejsze pod względem szybkości i energooszczędności rozwiązania. A taki spec od GUI nie ma żadnego umiaru w tych żądaniach - jego nikt nie przyciska.

Ta branża nigdy nie stawiała na efektywność, niestety :P Spójrz na systemy operacyjny, języki programowania, kompilatory (C++), desktop environments, cross-platformowość, przeglądarki - brak efektywności, wszystko to "to samo", implementowane i klejone ze sobą N razy, a efekt i tak jest taki, że później jeżeli soft nie jest maintainowane przez rok i dalej będzie działać to jest to właściwie cud :D i to wszystko aby kotka wyświetlić w przeglądarce

Z drugiej strony - sprzęt konkuruje ceną i wydajnością, a ludzie robiący GUI konkurują czym? featuresami? atrakcyjnością dla userów? ceną?

Wszystko sprowadza się do kasy, jakby były "incentives" do optymalizowania, to by to robili

Faktem jest, że możliwości dla użytkownika są dostosowywane do możliwości unowocześnianego sprzętu. Osobiście wolę lepiej prezentujące się GUI niż korzystać z dawnych rozwiązań.

Można jeszcze powiedzieć, że możliwości GUI w zakresie ‘ficzerów’ pochodzą od ograniczeń użytkowników. Na przykład korzystam z menedżera okien Fluxbox, który umożliwia dowolne konfigurowanie menu tekstowego. Chciałbym, żeby w nowoczesnym menedżerze okien też była taka możliwość, ale tutaj – dowolnego konfigurowania menu graficznego. Czasem to jest uniemożliwiane przez ograniczenia użytkowników, którym wystarczyłoby umieszczenie stałych lokalizacji w menu podług wizji projektanta.

Osobną kwestią są kompetencje programistów.

Poza tym nie wiem, w czym jest problem. Tak jak @WeiXiao napisał: biblioteki mają jakieś API. A dodam jeszcze, że sterowniki mają jakiś program utrzymywania stanu sprzętu. To się wyraźnie rozgranicza. Pozostaje kwestia takiej budowy sprzętu, by był wydajny do zastosowań, ale tak też jest rozwijany z lepszym bądź gorszym skutkiem.

WeiXiao napisał(a):

@userek_jakis:

A ogólnie to, że taki low-levelowiec musi praktycznie wiedzieć prawie wszystko o sofcie, nawet o tym co ma się dziać w GUI to chodziło mi przykładowo o sytuację, kiedy pojawia się jakiś problem gdzieś wysoko, powyżej zakresu bezpośredniej odpowiedzialności takiego low-levelowca. W takim przypadku i tak i tak taki programista musi wiedzieć co się dzieje w każdej warstwie pośredniej, jak np. takie surowe dane, których on dostarcza bezpośrednio ze sprzętu - jak takie dane są później przetwarzane i czy nie ma tu przypadkiem jego winy a jeśli nie to kto inny zawalił. Stąd moje stwierdzenie o wpływie na wyższe warstwy softu.

Prawie wszystko o sofcie = wiedzieć jak wywołać low level code z high level code? I ewentualnie zdebuggować?

Prawie wszystko o sofcie = prawie wszystko o sofcie od warstwy styku ze sprzętem (Hardware Abstraction Layer) idąc do góry czyli aż do GUI, czyli wszystkimi warstwami softu. Tworzeniem samego GUI nie musi umieć się zajmować, tak samo warstw pośrednich powyżej HAL-a, natomiast musi umieć się "wkręcić" w dowolną z tych warstw, chociażby po to żeby zweryfikować poprawność swojej własnej implementacji albo żeby wskazać w której z tych warstw jest problem.
A to dlatego, że czasami pewne błędy wychodzą dopiero kilka warstw wyżej - i niektórych problemów nie da się zauważyć w warstwach pośrednich. Po prostu przykładowo warstwy pośrednie nie są świadome tego, że np. obraz się przycina, blokuje albo dźwięk przerywa, etc.

Dodatkowo często trzeba przechodzić po stosie softu z góry (GUI) na sam dół (np. HAL) a potem w drugą stronę - bo tego wymaga debugging, a potem weryfikacja czy opracowany bugfix działa na każdym z poziomów poprawnie i czy nie spowoduje jakichś regresji.

Co prawda nie zawsze jest tak, że trzeba od samego dołu do samej góry - ale często się tak zdarza.

To że ktoś jest JIT Compiler Engineer w v8 jeszcze nie oznacza że jest dobrym frontend developerem

W takim przypadku i tak i tak taki programista musi wiedzieć co się dzieje w każdej warstwie pośredniej, jak np. takie surowe dane, których on dostarcza bezpośrednio ze sprzętu - jak takie dane są później przetwarzane

To chyba jest coś, co powinni ogarnąć architekci/komitet/projektanci ktokolwiek, ale nie programista?

Programista implementuje specyfikacje, standard, whatever, a nie go projektuje, czy się mylę?

Zakładając, że dana warstwa softu zajmuje się tylko swoją działką, za którą jest odpowiedzialna, to może nie być świadoma, że np. te dane które jej się wydawały za poprawne - po przekazaniu ich powyżej - tam zostaną już uznane za nieprawidłowe. Przykład: ramka ethernetowa na poziomie sterownika może wyglądać poprawnie, bo CRC się niby zgadza, długość payloadu poprawna, więc przekazuje ją do kernela. Kernel tę ramkę w kolejnych handlerach obsługi stosu ISO/OSI pozbawia określonych nagłówków, może robić dekompresję, weryfikuje sumy kontrolne, sprawdza różne inne rzeczy i zakładając, że wszystko ok pcha tę ramkę user-space'owej aplikacji. Aplikacja dostaje już tylko zwykle użyteczne dane z tej ramki. Tutaj apka zakłada, że skoro otrzymała dane to wszystkie wcześniejsze, pośrednie warstwy pozytywnie oceniły na swoim poziomie tę ramkę - więc może zająć się już obsługą tych danych - czyli np. zażadać znowu od warstw niższych wyświetlenia tych danych jako obraz albo odtworzenia jako dźwięk. Ale to tak trochę upraszczając.

Czyli inaczej - każda warstwa softu zwykle świadoma jest poprawności danych na swoim poziomie. Natomiast low-levelowiec musi umieć się odnaleźć na każdym z tych poziomów zarówno w celu zaimplementowania feature'a jak i w celu zdiagnozowania problemu.

Co do tego jaki są interakcje między architektem, projektantami a programistą to tutaj tylko mogę wypowiedzieć się jak nasz zespół pracuje. Jest dostępna cała specyfikacja techniczna dla developerów opracowana dla nich przez projektantów i architektów. Na jej podstawie implementuje się określone feature.
Zwykle ta dokumentacja jest dosyć dobrze napisana - ale czasami są wątpliwości i wtedy dopiero kontaktujemy się z architektem. Szczególnie, kiedy wszedł nowy feature i jego implementacja jest świeża i nie dokońca jeszcze przetestowana.

Czyli tak - potwierdzam to co napisałeś z tymi zależnościami architekt/projektant vs developer. U nas tak to działa.

Wiem, że elektronika nie stoi w miejscu i też powstają nowe technologie produkcji półprzewodników, ale radziłbym zastanowić się nad tym jaki jest bilans. High-level soft sobie wymaga coraz więcej, sprzętowcy i low-levelowcy dają z siebie coraz więcej - a smartfon ile trzymał na jednym ładowaniu baterii tyle nadal trzyma. Poza tym zauważ, że od wielu lat możliwości podnoszenia gigahareców już nie idą tak do przodu jak dawniej. Nie da się bez końca przyciskać sprzętowców i low-levelowców żeby to oni dostarczyli nam jak najwydajniejsze pod względem szybkości i energooszczędności rozwiązania. A taki spec od GUI nie ma żadnego umiaru w tych żądaniach - jego nikt nie przyciska.

Ta branża nigdy nie stawiała na efektywność, niestety :P Spójrz na systemy operacyjny, języki programowania, kompilatory (C++), desktop environments, cross-platformowość, przeglądarki - brak efektywności, wszystko to "to samo", implementowane i klejone ze sobą N razy, a efekt i tak jest taki, że później jeżeli soft nie jest maintainowane przez rok i dalej będzie działać to jest to właściwie cud :D i to wszystko aby kotka wyświetlić w przeglądarce

Z tym wyświetleniem finalnie kotka na ekranie - no właśnie to była jedna z takich refleksji, na które liczyłem, że czytający wpadną po lekturze tego co napisałem.

Ale się napisałem :)

@userek_jakis:

Zakładając, że dana warstwa softu zajmuje się tylko swoją działką, za którą jest odpowiedzialna, to może nie być świadoma, że np. te dane które jej się wydawały za poprawne - po przekazaniu ich powyżej - tam zostaną już uznane za nieprawidłowe. Przykład: ramka ethernetowa na poziomie sterownika może wyglądać poprawnie, bo CRC się niby zgadza, długość payloadu poprawna, więc przekazuje ją do kernela. Kernel tę ramkę w kolejnych handlerach obsługi stosu ISO/OSI pozbawia określonych nagłówków, może robić dekompresję, weryfikuje sumy kontrolne, sprawdza różne inne rzeczy i zakładając, że wszystko ok pcha tę ramkę user-space'owej aplikacji. Aplikacja dostaje już tylko zwykle użyteczne dane z tej ramki. Tutaj apka zakłada, że skoro otrzymała dane to wszystkie wcześniejsze, pośrednie warstwy pozytywnie oceniły na swoim poziomie tę ramkę - więc może zająć się już obsługą tych danych - czyli np. zażadać znowu od warstw niższych wyświetlenia tych danych jako obraz albo odtworzenia jako dźwięk. Ale to tak trochę upraszczając.

Czyli inaczej - każda warstwa softu zwykle świadoma jest poprawności danych na swoim poziomie. Natomiast low-levelowiec musi umieć się odnaleźć na każdym z tych poziomów zarówno w celu zaimplementowania feature'a jak i w celu zdiagnozowania problemu.

No ok, tutaj to brzmi sensowniej że jakiś Audio / Video Software Engineer musi mieć większy ten przekrój, ale raczej nie generalizowałbym tego na każdego "low levelowca"

Na pewno jest wielu takich którzy nie muszą wychodzić na wyższe warstwy i wystarczy im manipulowanie bitami w pamięci hardwareu na podstawie specki.

WeiXiao napisał(a):

@userek_jakis:

Czyli inaczej - każda warstwa softu zwykle świadoma jest poprawności danych na swoim poziomie. Natomiast low-levelowiec musi umieć się odnaleźć na każdym z tych poziomów zarówno w celu zaimplementowania feature'a jak i w celu zdiagnozowania problemu.

No ok, tutaj to brzmi sensowniej że jakiś Audio / Video Software Engineer musi mieć większy ten przekrój, ale raczej nie generalizowałbym tego na każdego "low levelowca"

Na pewno jest wielu takich którzy nie muszą wychodzić na wyższe warstwy i wystarczy im manipulowanie bitami w pamięci hardwareu na podstawie specki.

Tak, zgadzam się z obydwoma powyższymi zdaniami. Byłem w roli i tego low-levelowca w systemach bare-metal embedded i tego, który musi się odnaleźć m.in. w androidzie. To drugie jest zdecydowanie trudniejsze i bardziej wymagające. I właśnie ten mój wątek dotyczył tego drugiego przypadku.

Ja nie widzę żadnego problemu, można pozbyć się całej tej abstrakcji bezpieczeństwa i znacząco zwiększyć osiągi i zminimalizować zużycie energii.

Ale są inne ważne cechy prócz szybkości wykonania, wielkości programu.
Można pozbyć się tego całego sandboxowania i pozwalać uruchamiać obcy kod z internetu bezpośrednio na procesorze, a nie w przeglądarce.

Ja bym powiedział, że jest bardzo dużo różnych czynników wartych wzięcia pod uwagę dążąc do optymalizacji danego procesu.
Jeśli problem jest mocno widoczny to powstają potem alternatywne technologie, które je rozwiązują.

Możesz stworzyć technologię, która rozwiąże dany problem w efektywniejszy sposób.
Chciało by się wiedzieć wszystko, ale nawet jak naczytasz się jak coś działa i samemu to zaimplementujesz to zauważysz, że zrobiłeś tylko prostego PoC, a wiele istniejących jest znacznie bardziej rozbudowana i zaawansowana niż się wydaje.

No bo zrobić proste gui w opengl to nie problem, ale zrobić je jako uniwersalne narzędzie, wieloplatformowe, do tworzenia na wielu systemach i dające odpowiednie poziomy abstrakcji, a abstrakacja też może wpływać na wydajność.

@userek_jakis: jestes na poczatku swojej drogi w IT prawda?

Po to wlasnei robi sie kontrakty miedzy uslugami i specyfikacje API.

WhiteLightning napisał(a):

@userek_jakis: jestes na poczatku swojej drogi w IT prawda?

Nie powiem tu mnie trochę rozbawiłeś :) Skąd taki wniosek?
Zdaję sobie sprawę, że jest wiele osób na tym portalu, które są dłużej tutaj zarejestrowane ode mnie ale przecież to nie musi oznaczać, że te osoby są jakoś dalej w swojej karierze w IT ode mnie.
Nie oceniajmy ludzi po długości... stażu na 4p.

Po to wlasnei robi sie kontrakty miedzy uslugami i specyfikacje API.

Tutaj nie bardzo się orientuję, jaki jest cel podsumowywania moich postów w tym wątku w taki sposób. Zupełnie jakbym zaprezentowal jakąś zupełną indolencję, brak wiedzy i przemyśleń. Nie jest może tak, że ten wątek powstał po to, żeby pokazać innym jak działają pewne rzeczy?

Zauważ, że sam już nawet sugerowałem to, że mój opis jest "łopatologiczny", ale nie interpretuj tej łopatologiczności opisu w tym wątku jako bycie początkujacym.
Ta łopatologiczność opisu miała właśnie na celu trafienie do ludzi, którzy z pewnymi rzeczami mogli się nie spotkać w swojej karierze i żeby łatwiej im było je zrozumieć.

userek_jakis napisał(a):

Niestety będzie dużo czytania, ale to efekt tego, że starałem się żeby to było zrozumiale opisane.

Niech zgadnę - jesteś jednym z tych co mają uczulenie na latex?

Wniosek nr 1:
Najwięcej zależy od sprzętu, drugie w kolejności są firmware i drivery, dalej libki a na samym końcu GUI.

Dwa pierwsze wymagane, reszta zależy od poziomu znudzenia developera.

Wniosek nr 2:
Co do GUI są stawiane najmniejsze wymagania, a najgorzej ma tutaj sprzęt, drivery i firmware więc im niżej (im bliżej sprzętu) tym większa presja i odpowiedzialność na osobach odpowiedzialnych za ich obsługę.

Bywa to problematyczne jak sprzęt produkują w Azji a firmware piszą w US. Po co komu sprzęt który nie działa wg. specyfikacji (czyli zazwyczaj nie działa w ogóle)? Strach pomyśleć skąd oni brali ludzi do tej roboty jak firmware leżał w ROMie.

Rezultat jest taki, że to, że jednym zapewnia się komfortowe warunki pracy to w rezultacie powoduje to, że inni mają przerąbane.

Ci którzy mają wybór mają komfort zawsze. Mieć wybór to znaczy mieć możliwości. Tym którzy wyboru nie mają zostają słowa pocieszenia.

No tak. Wydaje im się. Źle im się wydaje.

Powtórzę za mistrzem który dostał raka: Nie jesteś odpowiedzialny za świat którego sobie nie wybrałeś. Cmentarze są pełne ludzi którzy mieli rację.

Proponuję przemyśleć pewne rzeczy na bazie tego to co tu powyżej napisałem.

Z całego wywodu wartościowe jest jedno

• modularyzacja komponentów/osobna kompilacja powoduje ograniczenia w możliwości automatycznej optymalizacji kodu maszynowego jeśli chodzi o whole-app-optimisation. Bo akurat najwydajniejsze rozwiązania (działające na ziemniaku) to zazwyczaj programy kompilowane statycznie od poziomu styku firmware po GUI. Z wiadomych przyczyn nie stosuje się tego nigdzie poza wyspecjalizowanymi urządzeniami.

Tak, tak ten od GUI nic nie musi robić, wszystko robią za nich specjaliści, a ci od GUI to tylko psują swiat.

Z mojego doświadczenia najtrudniej jest spiąć wszystkie klocki w działająca całość i to jeszcze przyjemna do użytkowania.

Dla innego najcięższa będzie komunikacja z kilkoma tranzystorami, dla innego spinanie setek serwerów w działająca całość.

viader napisał(a):

Tak, tak ten od GUI nic nie musi robić, wszystko robią za nich specjaliści, a ci od GUI to tylko psują swiat.

To zdanie sprawia wrażenie drwiny z iluśtam argumentów, zależności, konsekwencji i wniosków czyli chyba całego procesu wnioskowania który podałem.
Szkoda że nie podałeś swoich argumentów merytorycznych na obronę swojego punktu widzenia.

Tak, tak ten od GUI nic nie musi robić(...)

A wiesz że nawet możnaby w to uwierzyć biorąc pod uwagę to, że niektórzy na tym portalu pisali że mają po 2-ch albo i 3-ch klientów na OE?
I to niekoniecznie siedząc dłużej niż 8 godzin dziennie?

Z mojego doświadczenia najtrudniej jest spiąć wszystkie klocki w działająca całość i to jeszcze przyjemna do użytkowania.

Ale że niby ci od GUI spinają wszystko w całość? To miałeś na myśli?

Schadoow napisał(a):

Łatwiej jest lecieć w c**** na backendzie niż na froncie bo tego nie widać :p.

Czy aby na pewno?
Przyjrzyjmy się takiej sytuacji:

Frontendowiec: utworzenie jakiegoś okienka, wrzucenie parę widgetów do niego. Jakby co to jest co pokazać, że zostało coś zrobione. Ok 30 minut roboty minęło więc teraz pora na CS-ka albo następnego klienta na OE.
Backendowiec: kilka godzin pracy, której "pan w krawacie" w ogóle nie ogarnia.

Przychodzi "pan w krawacie" i chce zobaczyć efekty pracy jednego i drugiego. Mam pisać dalej?

Kilkakrotnie byłem świadkiem takiego podsumowania: "pracujecie, pracujecie a efektów nie widać" i bynajmniej nie dotyczyło ono frontendowców.

userek_jakis napisał(a):

viader napisał(a):

Tak, tak ten od GUI nic nie musi robić, wszystko robią za nich specjaliści, a ci od GUI to tylko psują swiat.

To zdanie sprawia wrażenie drwiny z iluśtam argumentów, zależności, konsekwencji i wniosków czyli chyba całego procesu wnioskowania który podałem.
Szkoda że nie podałeś swoich argumentów merytorycznych na obronę swojego punktu widzenia.

Bo drwię, ewidentnie pracę przy GUI upraszczasz do poziomu stronek pisanych przez licealistów na zaliczenie Informatyki.

Zacznijmy jednak od podstaw, skoro chciałbyś trochę merytorycznych argumentów.

Mamy różne rodzaje platform dla tworzenia GUI będącym interfacem dla przeciętnego zjadacza chleba:

1. Strony webowe
2. Aplikacje desktopowe natywne tylko na Windowsa/MacOS/Linuksa lub cross-platformowe
3. Aplikacje mobilne natywne tylko na iOS/Android lub cross-platformowe
4. Aplikacje na system embedded - pralka, lodówka, odkurzacz, kasy, itd

Oraz:

1. Aplikacje posiadające dostęp do Internetu i delegujące logikę na backend.
2. Aplikacje nieposiadające dostępu do Internetu, lub nie delegujące logiki na backend.

Teraz pochodzę z świata mobilnego, więc resztę będę opisywał na podstawie aplikacji mobilnych dla jednego systemu Android.

1. Kwestia driverrów: nie możesz korzystać bezpośrednio z driverów ponieważ tworzysz aplikację na 24 tysiące różnych modeli urządzeń, z różnymi sterownikami. Zapomnij o bezpośrednim używaniu driverów.
2. Korzystasz w takim razie z bibliotek systemowych, biblioteki systemowe nie potrafią przewidzieć w jaki sposób setki tysięcy aplikacji GUI będzie pisane, więc starają się oddawać największe możliwości jakie są w stanie, pamiętając, że masz mnóstwo urządzeń. Niestety drogą kompromisu często konfiguracja tych bibliotek jest daleka od ideału pod twoją aplikację.
3. Wydawałoby się, że to rozwiązuje problem, ale okazuje się, że na każdą bibliotekę do każdego medium masz 3 alternatywne biblioteki. Dodatkowo niektóre biblioteki działają ze sobą nieźle, inne są kompletnie niekompatybilne. Także na początku drogi musisz się zagłębić już w te miejsca, które miały być dla Ciebie według Twojej teorii już gotowe. Musisz przeanalizować jakie biblioteki najlepiej radzą sobie z sprzętem, mają najmniej błędów i będą rozwijane w przyszłości.
4. Okazuje się, że możliwości bibliotek w porównaniu do tego co widzimy na rynku w istniejących aplikacjach są śmieszne. Trzeba stworzyć samemu wydajne komponenty graficzne, ładnie się animujące oraz wybijające na rynku się stylem by nie pozostać z tyłu za konkurencją.
5. Biblioteka systemowa na jakims urzadzeniu dziala niepoprawnie i niezgodnie z dokumentacja? Userow to nie obchodzi, musisz to naprawic na już.
6. Komunikacja sieciowa popełnisz jakiś błąd przy komunikacji i twoja aplikacja nie działa jak należy? Lepiej byś wyłapał to przed puszczeniem na prod, bo trafi do kilku milionów osób, a czas propagacji bugfixa to najmniej 2 tygodnie. Dotyczy to oczywiście każdego rodzaju błędów.
7. Marketing uwielbia pushe, oczywiście ma możliwość wysyłania pushy do danej grupy odbiorców, ale po co tyle myśleć jak możesz wysłać do 100%. Kilka milionów userów dostających w tej samej chwili pusha, może wygenerować ruch sieciowy ubijający infrastrukturę, trzeba dobrze obsłużyć ten przypadek jako ten programista GUI.
8. Dodatkowo trzeba zadbać o bezpieczeństwo danych klientów, nie możemy pozwolić by ktoś mógł w łatwy sposób przeczytać nr bankowy klienta, podszyć się pod klienta, czy też w nieautoryzowany sposób używać systemu z którym się komunikujemy. A oczywiscie nieudaczni programisci GUI pisza systemy dla klientów bankowych, mObywateli, lekarzy itd.
9. Backend, który wszystko robi za apke mobilną i działa, jeśli tak jest to jest świetnie. Typowo jednak bywa tak, że apka ma się łączyć z X systemami, każdy ma mieć inną autoryzację, szynę danych i ich format bo w sumie nie ma czasu na napisanie tego dla aplikacji mobilnych, a z resztą to mogą być nawet systemy zewnętrzne od partnerów naszej firmy.
10. Backend nie działa? Był fuckup backendu na prodzie? Firma, którą obsługujesz w jakiś sposób zdenerwowała klienta. Bądź pewien, że wystawi ci negatywną ocenę na twoją aplikację na sklepie i nie będzie wnikał jak mocno wina aplikacji.
11. Backend i monitoring, przykłady fuckupów

• mając miliony userów i access token ważny 2 dni nie widać żadnych requestów po access token, kto by tym się przejął, niech programista GUI sobie monitoruje swoje GUI
• backend myślący, że można powiązać token oAuth z adresem IP i unieważnić token jeśli IP się nie zgadza (wylogowanie masowe klientów), zabezpieczenie nieudokumentowane i dzialajace tylko na prodzie, i oczywiscie niezgloszone przez nikogo z backendu bo mechanizm dziala dobrze
• backend myslacy, ze nie musi obslugiwac IPv6 bo maszyny w infra stoja na IPv4, a tu sie okazuje, ze Orange w Polsce na SIM ma tylko IPv6 i u tych klientow apka nie dziala, tez oczywiscie backend nic nie wie o tym problemie

Mógłbym długo, właściwie każdy argument z pierwszego posta jaki podałeś można bardzo łatwo obrócić w drugą stronę. Widać, że nie pisałeś, żadnej większej aplikacji dla klientów.

userek_jakis napisał(a):

Schadoow napisał(a):

Łatwiej jest lecieć w c**** na backendzie niż na froncie bo tego nie widać :p.

Czy aby na pewno?
Przyjrzyjmy się takiej sytuacji:

Frontendowiec: utworzenie jakiegoś okienka, wrzucenie parę widgetów do niego. Jakby co to jest co pokazać, że zostało coś zrobione. Ok 30 minut roboty minęło więc teraz pora na CS-ka albo następnego klienta na OE.
Backendowiec: kilka godzin pracy, której "pan w krawacie" w ogóle nie ogarnia.

Przychodzi "pan w krawacie" i chce zobaczyć efekty pracy jednego i drugiego. Mam pisać dalej?

Kilkakrotnie byłem świadkiem takiego podsumowania: "pracujecie, pracujecie a efektów nie widać" i bynajmniej nie dotyczyło ono frontendowców.

Nie wiem jak u Ciebie to działa, u mnie pan z krawatem zatrudnia specjalistę dbającego o to by praca szła wydajnie.
Dzięki czemu ten frontendowiec nie może wykpić się 1 okienkiem, ponieważ specjalista dokładnie wie ile czasu mogły zabrać jakie czynności i nie ma możliwości by wmówić, że coś co zajęło pół godziny trwało 8 godzin. Jeśli taka osoba się trafia w moim zespole to proszę o zmianę takiej osoby w moich zespole, ponieważ działa na szkodę pozostałych osób pracujących.

Ale oczywiscie tez odbije pileczke, mam znajomego, ktory sie chwalil jak to instalowal certyfikaty do SSL'a przez pol godziny, ale trackowal to zadanie przez 2 tygodnie, bo pan z krawatem poskąpił na specjaliste i nie mial pojecia o co chodzi. Takze to wszystko kwestia tego, czy pan z krawatem umie znalezc kogos kto wyegzekwuje wydajnosc, czy nie umie.

viader napisał(a):

userek_jakis napisał(a):

viader napisał(a):

Tak, tak ten od GUI nic nie musi robić, wszystko robią za nich specjaliści, a ci od GUI to tylko psują swiat.

To zdanie sprawia wrażenie drwiny z iluśtam argumentów, zależności, konsekwencji i wniosków czyli chyba całego procesu wnioskowania który podałem.
Szkoda że nie podałeś swoich argumentów merytorycznych na obronę swojego punktu widzenia.

Bo drwię(...)

Hm... może ja też powinienem zacząć?

Bo drwię, ewidentnie pracę przy GUI upraszczasz do poziomu stronek pisanych przez licealistów na zaliczenie Informatyki.

Skąd ten wniosek? Nigdzie nie pisałem przecież o jakichkolwiek stronkach...

Zacznijmy jednak od podstaw, skoro chciałbyś trochę merytorycznych argumentów.

Mamy różne rodzaje platform dla tworzenia GUI będącym interfacem dla przeciętnego zjadacza chleba:

1. Strony webowe
   (...)
   Oraz:
2. Aplikacje posiadające dostęp do Internetu i delegujące logikę na backend.
3. Aplikacje nieposiadające dostępu do Internetu, lub nie delegujące logiki na backend.

Byłem tego świadom już wcześniej...

Teraz pochodzę z świata mobilnego, więc resztę będę opisywał na podstawie aplikacji mobilnych dla jednego systemu Android.

1. Kwestia driverrów: nie możesz korzystać bezpośrednio z driverów ponieważ tworzysz aplikację na 24 tysiące różnych modeli urządzeń, z różnymi sterownikami. Zapomnij o bezpośrednim używaniu driverów.
2. Korzystasz w takim razie z bibliotek systemowych, biblioteki systemowe nie potrafią przewidzieć w jaki sposób setki tysięcy aplikacji GUI będzie pisane, więc starają się oddawać największe możliwości jakie są w stanie, pamiętając, że masz mnóstwo urządzeń. Niestety drogą kompromisu często konfiguracja tych bibliotek jest daleka od ideału pod twoją aplikację.
3. Wydawałoby się, że to rozwiązuje problem, ale okazuje się, że na każdą bibliotekę do każdego medium masz 3 alternatywne biblioteki. Dodatkowo niektóre biblioteki działają ze sobą nieźle, inne są kompletnie niekompatybilne. Także na początku drogi musisz się zagłębić już w te miejsca, które miały być dla Ciebie według Twojej teorii już gotowe. Musisz przeanalizować jakie biblioteki najlepiej radzą sobie z sprzętem, mają najmniej błędów i będą rozwijane w przyszłości.

A w jaki sposób to co opisałeś tutaj odbiega od tego co ja opisałem?
Poza tym, że trzeba się pobawić w testowanie i research jak używać tego co napisali ci od niższych warstw?

5. Biblioteka systemowa na jakims urzadzeniu dziala niepoprawnie i niezgodnie z dokumentacja? Userow to nie obchodzi, musisz to naprawic na już.

Naprawić? Grzebać w źródłach tych bibliotek? Czy raczej zworkaroundować je na swoim poziomie (warstwie) bez schodzenia na niższy poziom?

4. 6. ... 11. (...)

Tutaj opisane są jakieś historyjki i przypadki.
Ale spróbuję.

Potrzebujesz komunikacji sieciowej? Jest już dostępna w niższych warstwach API. Ale ktoś inny przecież musiał ją napisać.
Potrzebujesz obsłużyć zagadnienia związane z szyfrowaniem? Są dostępne. Ktoś je już napisał.
Musisz odtworzyć dźwięk? Dajesz np. ścieżkę do wav-a. Dźwięk jest odtwarzany.

Mógłbym długo, właściwie każdy argument z pierwszego posta jaki podałeś można bardzo łatwo obrócić w drugą stronę. Widać, że nie pisałeś, żadnej większej aplikacji dla klientów.

Wiem że mógłbyś długo ale tu nie chodzi o ilość i wymienianie wszystkich możliwych przypadków (corner case'ów, etc) które komuś przyjdą do głowy.
Mnie naprawdę nie interesuje ile ktoś potrafi gadać tylko treść wypowiedzi. Konkretna treść.

Sorry, ale ogólnie to trudno się odnieść do tak mało konkretnego postu. Dużo napisane, ale tak jakoś mało treściwie.

Ale żeby nie było - jak chcesz możesz napisać kolejnego posta, doprecyzować. Masz szansę.
Możemy powymieniać się argumentami.

userek_jakis napisał(a):

Hm... może ja też powinienem zacząć?

No to drwij kolego, ja nie będę dopytywał, dosyć sprawnie drwinę umiem rozczytać.

Skąd ten wniosek? Nigdzie nie pisałem przecież o jakichkolwiek stronkach...

Bardzo mało napisałeś o GUI, a dużo o wszystkim innym, traktując tak pobieżnie ten temat sprowadzasz go do najprostszych form.

A w jaki sposób to co opisałeś tutaj odbiega od tego co ja opisałem?
Poza tym, że trzeba się pobawić w testowanie i research jak używać tego co napisali ci od niższych warstw?

Skupiasz się na użytkowaniu, a do tego daleka droga. Na początku musisz wybrać zestaw bibliotek pasujących do siebie, dodatkowo najlepszych na rynku. By coś dobrze ocenić trzeba mieć wiedzę daleko wykraczającą poza podstawy użytkownia. Research nie polega tylko na tym jako to użyć, ale też na tym w jaki sposób została dana rzecz napisana, czy jest dobrze rozwijana i otestowana, czy cieszy się popularnością.

Naprawić? Grzebać w źródłach tych bibliotek? Czy raczej zworkaroundować je na swoim poziomie (warstwie) bez schodzenia na niższy poziom?

Pewnie, że tak, jeśli błąd jest w bibliotece, a biblioteka jest opensource to zawsze można ściągnąć jej źródła i ją poprawić do czasu, aż autorzy biblioteki nie ogarną. Tak robiłem na przykład przy bibliotece ML Kit. Wiem, pewnie będziesz w szoku, że programiści GUI są na tyle kompetentni by zrobić taką akcję.

Potrzebujesz komunikacji sieciowej? Jest już dostępna w niższych warstwach API. Ale ktoś inny przecież musiał ją napisać.
Potrzebujesz obsłużyć zagadnienia związane z szyfrowaniem? Są dostępne. Ktoś je już napisał.
Musisz odtworzyć dźwięk? Dajesz np. ścieżkę do wav-a. Dźwięk jest odtwarzany.

Użyjesz biblioteki oficjalnie rekomendowanej przez system Android? No to powodzenia, bo jej obsługa jest w cholerę toporna. Użyjesz standardu z community typu OkHttp + Retrofit, super, do momentu, aż nie musisz postawić lokalnego serwera. Stawiasz lokalny serwer? No to musisz poszukać jakiejś jeszcze innej biblioteki, ale napisać samemu od zera, bo typowo na mobile mało kto stawia serwery i takich bibliotek dedykowanych bardzo nie ma.

Szyfry to swietny tez temat, bo na Androidzie masz kilka sposobów by zapewnic bezpieczeństwo:

1. Używasz szyfrowania z systemu, ale dostepnego dla staszych Androidow -> mniejsze bezpieczenstwo
2. Uzywasz szyfrowania z systemu, ale z KeyStorem dostepne dla nowszych Androidow -> spoko, ale odcinasz starsze i nie masz pelni kontroli nad wersja openssla szyfrujaca
3. A moze sam skompilujesz sobie OpenSSL'a i poszyfrujesz to co potrzeba

Dźwięk to znowu temat rzeka, bo możesz sobie użyć kolejny raz czegoś systemowego, a możesz też sobie skompilować bibliotekę typu OpenAL natywnie i wystawić bindingi do odtwarzania.

Wiem że mógłbyś długo ale tu nie chodzi o ilość i wymienianie wszystkich możliwych przypadków (corner case'ów, etc) które komuś przyjdą do głowy.
Mnie naprawdę nie interesuje ile ktoś potrafi gadać tylko treść wypowiedzi. Konkretna treść.

Sorry, ale ogólnie to trudno się odnieść do tak mało konkretnego postu. Dużo napisane, ale tak jakoś mało treściwie.

Ale żeby nie było - jak chcesz możesz napisać kolejnego posta, doprecyzować. Masz szansę.
Możemy powymieniać się argumentami.

W sumie podobne wrażenie mam z całym twoim pierwszym postem, jest to tak błędne i rozmyte, że ciężko konkretnie odpowiedzieć.
Jedno co wiem to, że starasz się wytworzyć jakąś iluzję, że ci od GUI to już nic zaawansowanego i trudnego nie robią, wszystko mają dostarczone i jeszcze nie umieją używać tych rzeczy.
I tu się grubo mylisz :P

Jak chcesz jakiś temat konkretnie omówić to dawaj, mogę ci na przykład poopowiadać o tym jak się naprawia błędy w bibliotekach pisanych przez inne osoby :P

userek_jakis napisał(a):

Hm... może ja też powinienem zacząć?
No to drwij kolego, ja nie będę dopytywał, dosyć sprawnie drwinę umiem rozczytać.

Naprawdę? Mogę?

Skąd ten wniosek? Nigdzie nie pisałem przecież o jakichkolwiek stronkach...
Bardzo mało napisałeś o GUI, a dużo o wszystkim innym, traktując tak pobieżnie ten temat sprowadzasz go do najprostszych form.

Starałem się podać przekrój, pokazać zależności, wymagania i konsekwencje.
Niestety wyciąłeś sobie kawałek (jeden element z całej układanki) - GUI - z całego kontekstu opisanego przeze mnie i na nim się skupiłeś.
A ja pisałem o porównaniu między warstwami. I nigdzie nie napisałem, że ci od GUI nic nie robią tylko że oni mają relatywnie najłatwiej i najmniej na głowie.
Najłatwiej - czyli względnie a nie bezwzględnie (łatwo).
Najłatwiej nie oznacza łatwo.

A w jaki sposób to co opisałeś tutaj odbiega od tego co ja opisałem?
Poza tym, że trzeba się pobawić w testowanie i research jak używać tego co napisali ci od niższych warstw?

Skupiasz się na użytkowaniu, a do tego daleka droga. Na początku musisz wybrać zestaw bibliotek pasujących do siebie, dodatkowo najlepszych na rynku. By coś dobrze ocenić trzeba mieć wiedzę daleko wykraczającą poza podstawy użytkownia. Research nie polega tylko na tym jako to użyć, ale też na tym w jaki sposób została dana rzecz napisana, czy jest dobrze rozwijana i otestowana, czy cieszy się popularnością.

Taki ktoś od GUI zejdzie do poziomu driverów albo firmware podczas debuggingu?
Czy raczej zdebugowanie jakiegoś problemu niżej nie zostanie oddelegowane do kogoś od low-level?

Naprawić? Grzebać w źródłach tych bibliotek? Czy raczej zworkaroundować je na swoim poziomie (warstwie) bez schodzenia na niższy poziom?

Pewnie, że tak, jeśli błąd jest w bibliotece, a biblioteka jest opensource to zawsze można ściągnąć jej źródła i ją poprawić do czasu, aż autorzy biblioteki nie ogarną. Tak robiłem na przykład przy bibliotece ML Kit. Wiem, pewnie będziesz w szoku, że programiści GUI są na tyle kompetentni by zrobić taką akcję.

Do samego dołu - do driverów, firmware, do sprzętu?

Użyjesz biblioteki oficjalnie rekomendowanej przez system Android? No to powodzenia, bo jej obsługa jest w cholerę toporna. Użyjesz standardu z community typu OkHttp + Retrofit, super, do momentu, aż nie musisz postawić lokalnego serwera. Stawiasz lokalny serwer? No to musisz poszukać jakiejś jeszcze innej biblioteki, ale napisać samemu od zera, bo typowo na mobile mało kto stawia serwery i takich bibliotek dedykowanych bardzo nie ma.

Szyfry to swietny tez temat, bo na Androidzie masz kilka sposobów by zapewnic bezpieczeństwo:

1. Używasz szyfrowania z systemu, ale dostepnego dla staszych Androidow -> mniejsze bezpieczenstwo
2. Uzywasz szyfrowania z systemu, ale z KeyStorem dostepne dla nowszych Androidow -> spoko, ale odcinasz starsze i nie masz pelni kontroli nad wersja openssla szyfrujaca
3. A moze sam skompilujesz sobie OpenSSL'a i poszyfrujesz to co potrzeba

I znowu próbujesz uciec w jakieś historyjki.

Dźwięk to znowu temat rzeka, bo możesz sobie użyć kolejny raz czegoś systemowego, a możesz też sobie skompilować bibliotekę typu OpenAL natywnie i wystawić bindingi do odtwarzania.

Co to jest jak nie research gotowych rozwiązań?

Dźwięk powstaje sam z siebie?
A nie poprzez odwołania do warstw niższych a finalnie do sprzętu?
Programista GUI sam potrafi odpowiednio przekopać się do HW żeby wygenerować dźwięk?

W sumie podobne wrażenie mam z całym twoim pierwszym postem, jest to tak błędne i rozmyte, że ciężko konkretnie odpowiedzieć.

Błędne? Rozmyte?

Jedno co wiem to, że starasz się wytworzyć jakąś iluzję, że ci od GUI to już nic zaawansowanego i trudnego nie robią, wszystko mają dostarczone i jeszcze nie umieją używać tych rzeczy.

Mój post nie powstał po to żeby stwarzać jakiekolwiek iluzje a już tym bardziej iluzje rozmyte.

wytworzyć jakąś iluzję(...) wszystko mają dostarczone

No nie iluzja - przecież mają dostarczone wszystko przez innych.

nic zaawansowanego i trudnego nie robią

Jeszcze raz: chodziło o porównanie z niższymi warstwami. A ty tu używasz określeń bezwzględnych ("trudnego").

nie umieją używać tych rzeczy

Nic takiego nie napisałem.

Ogólnie to dużo nadinterpretacji i przeinaczeń w tych Twoich postach. Starasz się stworzyć jakieś iluzje?

Jak chcesz jakiś temat konkretnie omówić to dawaj, mogę ci na przykład poopowiadać o tym jak się naprawia błędy w bibliotekach pisanych przez inne osoby :P

No dobrze jak tam chcesz. Opowiedz może w takim razie jak zdebugowałeś i naprawiłeś jakikolwiek błąd schodząc z poziomu GUI aż do poziomu styku ze sprzętem.
I który bit w którym rejestrze musiałeś ustawić lub skasować żeby naprawić błąd. I dlaczego. Nie musisz schodzić na poziom tranzystorów (tych "kilku tranzystorów" tak jak pisałeś) i pokazywać - o ten tutaj właśnie przeszedł w aktywny stan pracy.
Ile stron specyfikacji technicznej przeczytałeś i skąd ją miałeś? W jaki sposób sprawdziłeś i zapewniłeś, że ta poprawka nie popsuje nic innego w pozostałych częściach systemu albo innych aplikacjach?