Google Tech TalksJuly, 25 2007ABSTRACTThis talk begins with an overview of software development at Adobe and a look at industry trends towards systems built ...
Z tego co widziałem to współczesne frameworki js opierają się na śledzeniu zmiennych w modelach i reakcji na to. Html/css jest już deklaratywny. Problemem był tylko model. To się zmieniło. Teraz dodali jeszcze jakąś izolację i szablonowanie części drzewa DOM.
Frameworki przyszłości starają się przenieść najczęściej używane wzorce do znaczników HTML.
Deklaratywne tworzenie interfejsu to także Swift UI. Przełomem było tu raczej oglądanie na żywo zmian w kodzie. I to, że deklaratywny kod UI stał się tym samym językiem co logika. Oczywiście wymaga to odpowiednio ekspresywnego języka.
Nie wiem czemu rozwój oparty na przybliżeniu nie jest ci bliski. Sam deklarowałeś, że dobrze jest widzieć wynik działania jak najszybciej. A potem dążyć do jego ulepszania.
Na wschodzie często zamiast rekrutacji jest intensywne szkolenie. Ale za to wymogi formalne są wtedy wysokie. Osobiście wolę śledzić kogoś karierę i działanie i zaproponować mu posadę. Ale w oczach innych to strata czasu.
Czytałem i oglądałem dużo o nowych rozwiązaniach w C++. Osobiście nie stosowałem. Więc nie mam zbyt wiele na ten temat do powiedzenia. Bo to co pokazano nie robiło zbyt dużego wrażenia. Większe wrażenie robiło na mnie starodawne tworzenie typów dla każdej “jednostki fizycznej” i interakcje między nimi za pomocą operatorów.
Nie wiem czemu rozwój oparty na przybliżeniu nie jest ci bliski. Sam deklarowałeś, że dobrze jest widzieć wynik działania jak najszybciej. A potem dążyć do jego ulepszania.
Takie podejście jest poprawne na etapie tworzenia software’u.
Jako developer chcę zobaczyć jak najszybciej wynik, bo łatwiej wtedy znaleźć i poprawić błędy.
Ja mam na myśli przypadki, w której produkcyjna wersja ma wyciętą obsługę pewnych stanów, bo “taka sytuacja nie powinna wystąpić w praktyce”.
Clownstrike też nie powinien wystąpić w praktyce.
Pamiętam jak dziadek z Microsoftu opowiadał historię o debugowaniu stosu USB w Windows.
Mieli jakiś wózek z różnymi urządzeniami podpiętymi do huba i podłączali go losowo do komputera pracowników. W pierwszych wersjach często kończyło się to BSODem i poprawianiem sterownika.
Na tym polega dbałość o szczegóły i jakość software’u. Nieważne, że w praktyce klient prawdopodobnie nie ma 64 urządzeń podłączonych do portu USB.
Pamiętam tę historię. Nie widzę tu dbałości o szczegóły. Raczej widzę, że wózek z donglami był przybliżeniem działania. Dbałość bym widział gdyby kod działał. Coś jak opowieść pana od portowania NT na x86-64. Kiedy zanieśli płytę do AMD i wszystko zadziałało na realnym sprzęcie.
Przypomniałeś mi, że podobny problem z USB stał się exploitem pewnej konsoli.
Z tego co widziałem to współczesne frameworki js opierają się na śledzeniu zmiennych w modelach i reakcji na to. Html/css jest już deklaratywny. Problemem był tylko model. To się zmieniło. Teraz dodali jeszcze jakąś izolację i szablonowanie części drzewa DOM.
Frameworki przyszłości starają się przenieść najczęściej używane wzorce do znaczników HTML.
Deklaratywne tworzenie interfejsu to także Swift UI. Przełomem było tu raczej oglądanie na żywo zmian w kodzie. I to, że deklaratywny kod UI stał się tym samym językiem co logika. Oczywiście wymaga to odpowiednio ekspresywnego języka.
Nie wiem czemu rozwój oparty na przybliżeniu nie jest ci bliski. Sam deklarowałeś, że dobrze jest widzieć wynik działania jak najszybciej. A potem dążyć do jego ulepszania.
Na wschodzie często zamiast rekrutacji jest intensywne szkolenie. Ale za to wymogi formalne są wtedy wysokie. Osobiście wolę śledzić kogoś karierę i działanie i zaproponować mu posadę. Ale w oczach innych to strata czasu.
Czytałem i oglądałem dużo o nowych rozwiązaniach w C++. Osobiście nie stosowałem. Więc nie mam zbyt wiele na ten temat do powiedzenia. Bo to co pokazano nie robiło zbyt dużego wrażenia. Większe wrażenie robiło na mnie starodawne tworzenie typów dla każdej “jednostki fizycznej” i interakcje między nimi za pomocą operatorów.
Takie podejście jest poprawne na etapie tworzenia software’u.
Jako developer chcę zobaczyć jak najszybciej wynik, bo łatwiej wtedy znaleźć i poprawić błędy.
Ja mam na myśli przypadki, w której produkcyjna wersja ma wyciętą obsługę pewnych stanów, bo “taka sytuacja nie powinna wystąpić w praktyce”.
Clownstrike też nie powinien wystąpić w praktyce.
Pamiętam jak dziadek z Microsoftu opowiadał historię o debugowaniu stosu USB w Windows.
Mieli jakiś wózek z różnymi urządzeniami podpiętymi do huba i podłączali go losowo do komputera pracowników. W pierwszych wersjach często kończyło się to BSODem i poprawianiem sterownika.
Na tym polega dbałość o szczegóły i jakość software’u. Nieważne, że w praktyce klient prawdopodobnie nie ma 64 urządzeń podłączonych do portu USB.
Pamiętam tę historię. Nie widzę tu dbałości o szczegóły. Raczej widzę, że wózek z donglami był przybliżeniem działania. Dbałość bym widział gdyby kod działał. Coś jak opowieść pana od portowania NT na x86-64. Kiedy zanieśli płytę do AMD i wszystko zadziałało na realnym sprzęcie.
Przypomniałeś mi, że podobny problem z USB stał się exploitem pewnej konsoli.
Ale przynajmniej mieli świadomość, że problem z USB istnieje i podjęli jakieś działania, zamiast zamiatać go pod dywan.
Istniały inne problemy o których nie mówili. Potem i tak przepisali ten stos na jakiś inny język.
Masz rację. To więcej niż firmy które wcale nie robią realnych testów albo nawet nie robią prototypu i badań.