Duże firmy nie są autorytetem. Byłyby gdyby istniała zasada, że kapitał generuje optymalne rozwiązania. Albo jeśli konsumenci by takie wybierali i konkurencyjnie takie wygrywały. A jest wręcz przeciwnie. Opłacają się dość specyficzne rozwiązania. Optymalne są tworzone raczej przez utalentowane jednostki. Oto poszlaki.
spoiler
Ktoś kiedyś napisał:
“Czasami myślę, że największą tajemnicą w tej branży jest to, że 2 osoby mogą wyprodukować więcej niż nawet największe firmy. Jedyną rzeczą, która zapewnia bezpieczeństwo pracy wszystkich, jest to, że nikt nie może dokładnie zidentyfikować, które 2 osoby.”
Odnośnie spoilera - myślę, że dużym firmom niespecjalnie zależy na retencji takich utalentowanych osób. Taniej jest stworzyć środowisko/kulturę pracy, która pozwala przeciętnym pracownikom dostarczyć akceptowalny kod.
To wymaga stworzenia szeregu procedur, które dla eksperta byłyby jak kula u nogi.
Pamiętam akcję w jednym z projektów. Przeznaczenie produktu powodowało, że kluczowym czynnikiem było szybkie uzyskanie odpowiedzi z serwera.
Połączenie musiało być jednak zabezpieczone, więc programiści wymyślili swój własny sposób szyfrowania/uwierzytelniania.
Po jakimś czasie okazało się, że projekt kiepsko się skaluje. Zacząłem analizować, jaka jest przyczyna i oczywiście okazało się, że problem jest ten mechanizm szyfrujący.
Poszedłem z tym do kierownika i spytałem, czemu nie użyć jakiejś gotowej, sprawdzonej biblioteki.
Dostałem odpowiedź, że pełna kryptografia z certyfikatami będzie jeszcze wolniejsza.
Ta teoria śmierdziała mi na kilometr, więc napisalem przez jeden weekend prototyp na najzwyklejszym TLS 1.3 z OpenSSLa i uzyskałem kilkanaście razy lepszą wydajność.
Oczywiście wiedziałem, że nie zostanie to nigdy wdrożone do projektu, ale miło było widzieć zdziwienie na twarzy kierownika, jak zobaczył wydajność nawiązywania połączeń.
Firmy oferują często przestarzałe produkty, które kompetentny 2-3 osobowy zespół mógłby w kilka miesięcy przepisać do znacznie lepszej postaci. Problem w tym, że wymagałoby to wyciągnięcia odpowiednich osób z kieratu i przekazania im sporej autonomii, co jest nie do pomyślenia dla większości kadry kierowniczej.
Odnośnie skalowalności frameworku, istotnym kryterium jest moim zdaniem to, czy kilkanaście zespołów może jednocześnie wprowadzać zmiany w tej samej aplikacji utrzymując jedynie minimalną komunikację.
Wydaje mi się, że założenia przyjęte przez Iced mogą to komplikować.
No i sam dostarczyłeś anegdoty, że kapitał nie wygenerował optymalnego rozwiązania. Ty w zaciszu stworzyłeś lepsze. Lepsze przegrało konfrontację z zastanym. Gdzie z matko popełniliśmy błąd?
Nie wiem czy chciałbym używać aplikacji w której kilkanaście zespołów dokłada coś od siebie do GUI. To przypomina raczej największe porażki FLOSS w których nie wiadomo gdzie wcisnąć kolejną opcję. Nawet pan z Adbe mówił, że zajmuje się tym jedna osoba. Potem pojawia się taki hit jak Procreate z minimalnym interfejsem, wręcz analogową obsługą i wszyscy są zachwyceni. Jego zespół to początkowo cztery, a po dziesięciu latach czterdzieści osób.
Nie zamierzam używać Iced. Raczej lubię analizować ciekawe API. Zdziwiłeś mnie tym kryterium skalowalności.
Nie wiem czy chciałbym używać aplikacji w której kilkanaście zespołów dokłada coś od siebie do GUI.
Nie używasz Windows / Office?
Nawet pan z Adbe mówił, że zajmuje się tym jedna osoba.
Zajmuje się tym jedna osoba w zespole, ale samych zespołów jest wiele. W każdym z nich jest ~20 programistów.
Podejrzewam, ze dzisiaj pracowników może być jeszcze więcej (albo było, przed falą zwolnień).
Wydaje mi się, że cała dyskusja wynika z tego jak sobie wyobrażamy takie zespoły. Nie wiem czy widziałem jakiś dobry. Zawsze to jakiś kompromis wynikający z różnych nadmiernych specjalizacji.
Zauważ, że świat odszedł od wizualnego układania GUI. Potem od jakiś specjalistycznych języków do GUI. Teraz skupia się na tym, że można robić GUI za pomocą języka w którym piszesz aplikację.
Iced opiera się na podobnych zasadach do React.
Duże firmy nie są autorytetem. Byłyby gdyby istniała zasada, że kapitał generuje optymalne rozwiązania. Albo jeśli konsumenci by takie wybierali i konkurencyjnie takie wygrywały. A jest wręcz przeciwnie. Opłacają się dość specyficzne rozwiązania. Optymalne są tworzone raczej przez utalentowane jednostki. Oto poszlaki.
spoiler
Ktoś kiedyś napisał:
Odnośnie spoilera - myślę, że dużym firmom niespecjalnie zależy na retencji takich utalentowanych osób. Taniej jest stworzyć środowisko/kulturę pracy, która pozwala przeciętnym pracownikom dostarczyć akceptowalny kod.
To wymaga stworzenia szeregu procedur, które dla eksperta byłyby jak kula u nogi.
Pamiętam akcję w jednym z projektów. Przeznaczenie produktu powodowało, że kluczowym czynnikiem było szybkie uzyskanie odpowiedzi z serwera.
Połączenie musiało być jednak zabezpieczone, więc programiści wymyślili swój własny sposób szyfrowania/uwierzytelniania.
Po jakimś czasie okazało się, że projekt kiepsko się skaluje. Zacząłem analizować, jaka jest przyczyna i oczywiście okazało się, że problem jest ten mechanizm szyfrujący.
Poszedłem z tym do kierownika i spytałem, czemu nie użyć jakiejś gotowej, sprawdzonej biblioteki.
Dostałem odpowiedź, że pełna kryptografia z certyfikatami będzie jeszcze wolniejsza.
Ta teoria śmierdziała mi na kilometr, więc napisalem przez jeden weekend prototyp na najzwyklejszym TLS 1.3 z OpenSSLa i uzyskałem kilkanaście razy lepszą wydajność.
Oczywiście wiedziałem, że nie zostanie to nigdy wdrożone do projektu, ale miło było widzieć zdziwienie na twarzy kierownika, jak zobaczył wydajność nawiązywania połączeń.
Firmy oferują często przestarzałe produkty, które kompetentny 2-3 osobowy zespół mógłby w kilka miesięcy przepisać do znacznie lepszej postaci. Problem w tym, że wymagałoby to wyciągnięcia odpowiednich osób z kieratu i przekazania im sporej autonomii, co jest nie do pomyślenia dla większości kadry kierowniczej.
Odnośnie skalowalności frameworku, istotnym kryterium jest moim zdaniem to, czy kilkanaście zespołów może jednocześnie wprowadzać zmiany w tej samej aplikacji utrzymując jedynie minimalną komunikację.
Wydaje mi się, że założenia przyjęte przez Iced mogą to komplikować.
No i sam dostarczyłeś anegdoty, że kapitał nie wygenerował optymalnego rozwiązania. Ty w zaciszu stworzyłeś lepsze. Lepsze przegrało konfrontację z zastanym. Gdzie z matko popełniliśmy błąd?
Nie wiem czy chciałbym używać aplikacji w której kilkanaście zespołów dokłada coś od siebie do GUI. To przypomina raczej największe porażki FLOSS w których nie wiadomo gdzie wcisnąć kolejną opcję. Nawet pan z Adbe mówił, że zajmuje się tym jedna osoba. Potem pojawia się taki hit jak Procreate z minimalnym interfejsem, wręcz analogową obsługą i wszyscy są zachwyceni. Jego zespół to początkowo cztery, a po dziesięciu latach czterdzieści osób.
Nie zamierzam używać Iced. Raczej lubię analizować ciekawe API. Zdziwiłeś mnie tym kryterium skalowalności.
Tu jeszcze jeden projekt w iced do analizy: https://agourlay.github.io/ruxguitar-tablature-player/
Nie używasz Windows / Office?
Zajmuje się tym jedna osoba w zespole, ale samych zespołów jest wiele. W każdym z nich jest ~20 programistów.
Podejrzewam, ze dzisiaj pracowników może być jeszcze więcej (albo było, przed falą zwolnień).
Wydaje mi się, że cała dyskusja wynika z tego jak sobie wyobrażamy takie zespoły. Nie wiem czy widziałem jakiś dobry. Zawsze to jakiś kompromis wynikający z różnych nadmiernych specjalizacji.
Zauważ, że świat odszedł od wizualnego układania GUI. Potem od jakiś specjalistycznych języków do GUI. Teraz skupia się na tym, że można robić GUI za pomocą języka w którym piszesz aplikację.
Chyba lepiej byłoby gdybyś podawał przykłady które podziwiasz. Przy których mówisz “jak dorosnę chciałbym zrobić takie coś”.