eGospodarka.pl

eGospodarka.plGrupypl.comp.programming › Web development
Ilość wypowiedzi w tym wątku: 8

  • 1. Data: 2020-05-18 22:19:32
    Temat: Web development
    Od: Maciej Sobczak <s...@g...com>

    Trochę mało tu wątków tego typu.

    Chciałem zapytać szanowne grono, czy uprawiacie taką aktywność świadomie *bez* użycia
    popularnych frameworków. Pod pojęciem "świadomie" rozumiem, że wiecie o ich istnieniu
    a może nawet je znacie, ale pomimo tego podjęliście decyzję, żeby ich nie używać
    (może właśnie dlatego, że je znacie).

    Chciałbym to skonfrontować z ogólnym obrazem rynku, gdzie pojęcia "web development"
    oraz "framework do JSa" wydają się być powszechnie tożsame.

    Po stronie serwerowej też mógłbym zapytać, czy ktoś z Was praktykuje web development
    wykorzystując języki natywnie kompilowane, czyli np. C++ - tzn. nie jako dalszy w
    szeregu komponent back-endu, tylko jako wiodące (albo jedyne) rozwiązanie. Wiem o
    kilku takich serwisach i sam kiedyś taki zrobiłem, ale chciałbym wiedzieć, czy te
    koncepcje są jeszcze praktykowane.

    --
    Maciej Sobczak * http://www.inspirel.com


  • 2. Data: 2020-05-19 11:30:17
    Temat: Re: Web development
    Od: Mateusz Viste <m...@x...invalid>

    2020-05-18 o 13:19 -0700, Maciej Sobczak napisał:
    > Chciałem zapytać szanowne grono, czy uprawiacie taką aktywność
    > świadomie *bez* użycia popularnych frameworków.

    Do poważnych rzeczy? Nie. Ale jeśli chodzi o jakiś prosty serwis
    informacyjny dla firemki lub samorządu, tj. coś, co można naskrobać w
    kilkunastu linijkach php, to jak najbardziej. Tutaj dwa luźne przykłady
    moich ostatnich prac:
    https://abibio.fr/
    http://soay.fr/

    > Po stronie serwerowej też mógłbym zapytać, czy ktoś z Was praktykuje
    > web development wykorzystując języki natywnie kompilowane, czyli np.
    > C++ - tzn. nie jako dalszy w szeregu komponent back-endu, tylko jako
    > wiodące (albo jedyne) rozwiązanie.

    Raz mi się zdarzyło, niejako dla eksperymentu:
    http://poludnitsa.sourceforge.net/

    Gdybym miał znów coś takiego robić, to użyłbym gołego php.

    Dodam, że ja absolutnie nie jestem żadnym "web developerem", zdarzy mi
    się czasem coś popełnić, ale to raczej w ramach wieczornej rozrywki.

    Mateusz


  • 3. Data: 2020-05-19 22:32:30
    Temat: Re: Web development
    Od: Maciej Sobczak <s...@g...com>

    W dniu wtorek, 19 maja 2020 11:30:21 UTC+2 użytkownik Mateusz Viste napisał:

    > Do poważnych rzeczy? Nie.

    A dlaczego? Bo w ogóle nie robiłeś "poważnych rzeczy", czy te poważne koniecznie
    robiłeś/robiłbyś z frameworkami?

    To jest pytanie o granice stosowalności tego pomysłu - tzn. nie-frameworkowego
    web-developmentu.
    Oczywiście można sobie porozważać, że w odpowiednio dużym projekcie, praktykowanym
    odpowiednio długo, przez sam fakt refaktoryzacji istniejącego kodu jakiś framework
    mógłby się spontanicznie sam wyłonić a skoro tak, to czemu od razu nie zacząć z
    istniejącym już frameworkiem. Ale wtedy kolejnym pytaniem byłoby, czy w takim
    projekcie warto mieć własne rozwiązanie, naturalnie dopasowane do projektu, w ramach
    którego powstało, czy też obce, do którego trzeba od poczatku naciągać projekt.

    (teoretycznie można ten argument zastosować do każdego frameworku lub biblioteki, nie
    tylko w tej dziedzinie)

    Czyli: bierzemy HTML+CSS+JS (bo powiedzmy, że się uzupełniają i żadnego z tych trzech
    nie może zabraknąć) i... tylko tyle, przynajmniej po stronie klienckiej. Czy jest
    granica stosowalności tego podejścia i dlaczego jest właśnie tam?

    > > Po stronie serwerowej też mógłbym zapytać, czy ktoś z Was praktykuje
    > > web development wykorzystując języki natywnie kompilowane, czyli np.
    > > C++ - tzn. nie jako dalszy w szeregu komponent back-endu, tylko jako
    > > wiodące (albo jedyne) rozwiązanie.
    >
    > Raz mi się zdarzyło, niejako dla eksperymentu:
    > http://poludnitsa.sourceforge.net/
    >
    > Gdybym miał znów coś takiego robić, to użyłbym gołego php.

    Eksperyment się nie udał? Czy udał się, ale dostarczył argumentów przeciw?

    --
    Maciej Sobczak * http://www.inspirel.com


  • 4. Data: 2020-05-19 23:01:28
    Temat: Re: Web development
    Od: Mateusz Viste <m...@x...invalid>

    2020-05-19 o 13:32 -0700, Maciej Sobczak napisał:
    > > Do poważnych rzeczy? Nie.
    >
    > A dlaczego? Bo w ogóle nie robiłeś "poważnych rzeczy", czy te poważne
    > koniecznie robiłeś/robiłbyś z frameworkami?

    Nie jestem web deweloperem, ale zdarzało mi się zarządzać
    takimi projektami - w praktyce zawsze kończyło się na jakimś Symfony,
    CakePHP czy innym NodeJS.

    > To jest pytanie o granice stosowalności tego pomysłu - tzn.
    > nie-frameworkowego web-developmentu.

    Granica - w moim skromnym mniemaniu - jest tylko jedna: koszt.

    > Ale wtedy kolejnym pytaniem byłoby, czy w takim projekcie warto mieć
    > własne rozwiązanie, naturalnie dopasowane do projektu, w ramach
    > którego powstało, czy też obce, do którego trzeba od poczatku naciągać
    > projekt.

    Z (mojej) praktyki raczej wynika, że jest wręcz odwrotnie - przy jakimś
    in-house potworku szybko okazuje się, że ten potworek nie umie tego
    albo tamtego (bo w początkowych specyfikacjach tego nie było), i trzeba
    strugać go na bieżąco, dodawać wyjątki, itd. Natomiast gotowiec ma ten
    etap z reguły już za sobą. Korzystają z niego rzesze programistów w
    bardzo wielu projektach i dzięki inkrementalnym ulepszeniom daje radę,
    jednocześnie zapewniając spójne API, przemyślane nazwy
    klas/funkcji/zmiennych, itp.

    > Czyli: bierzemy HTML+CSS+JS (bo powiedzmy, że się uzupełniają i
    > żadnego z tych trzech nie może zabraknąć) i... tylko tyle,
    > przynajmniej po stronie klienckiej. Czy jest granica stosowalności
    > tego podejścia i dlaczego jest właśnie tam?

    Koszt. Dlaczego? Bo wymyślanie koła na nowo kosztuje. Jeśli robisz to w
    ramach hobby to spoko - ale w biznesowym świecie mało który klient
    (z tych których znam przynajmniej) zgodzi się opłacać takie
    przedsięwzięcie. Bo frontend ma działać, być gotowy na wczoraj, i ma
    być tanio (tj. taniej niż konkurencja, przy tych samych wymaganiach).

    > Eksperyment się nie udał? Czy udał się, ale dostarczył argumentów
    > przeciw?

    Udał się w sensie, że zapewnił mi rozrywkę na kilka wieczorów.

    Argument przeciw jest taki, że kompilowanie dziada za każdym razem
    kiedy chcę go wgrać na nową platformę (+instalacja gcc +ew. walki z
    linkerem) jest po drugim razie... nużące. Plik PHP natomiast wystarczy
    wrzucić i po prostu działa. Do tego C nie proponuje wielu
    "oczywistych" (w świecie web) usprawnień, które w PHP są niejako od
    zawsze - i wraca leitmotiv odkrywania koła na nowo (tak głupie rzeczy
    jak np. "odczytaj wartość pola z formularza"). No i PHP jednak dużo
    potrafi wybaczyć, a w C jedna literówka potrafi zakończyć się core
    dumpem. W trakcie pracy dużo łatwiej zlokalizować problem z logów php
    aniżeli analizować wypis z gdb. W końcu po coś te technologie "webowe"
    ktoś wymyślił. :)

    Mateusz


  • 5. Data: 2020-05-20 08:07:17
    Temat: Re: Web development
    Od: Roman Tyczka <n...@b...no>

    On Tue, 19 May 2020 13:32:30 -0700 (PDT), Maciej Sobczak wrote:

    >> Do poważnych rzeczy? Nie.
    >
    > A dlaczego? Bo w ogóle nie robiłeś "poważnych rzeczy", czy te poważne koniecznie
    robiłeś/robiłbyś z frameworkami?
    >
    > To jest pytanie o granice stosowalności tego pomysłu - tzn. nie-frameworkowego
    web-developmentu.
    > Oczywiście można sobie porozważać, że w odpowiednio dużym projekcie, praktykowanym
    odpowiednio długo, przez sam fakt refaktoryzacji istniejącego kodu jakiś framework
    mógłby się spontanicznie sam wyłonić a skoro tak, to czemu od razu nie zacząć z
    istniejącym już frameworkiem. Ale wtedy kolejnym pytaniem byłoby, czy w takim
    projekcie warto mieć własne rozwiązanie, naturalnie dopasowane do projektu, w ramach
    którego powstało, czy też obce, do którego trzeba od poczatku naciągać projekt.
    >
    > (teoretycznie można ten argument zastosować do każdego frameworku lub biblioteki,
    nie tylko w tej dziedzinie)
    >
    > Czyli: bierzemy HTML+CSS+JS (bo powiedzmy, że się uzupełniają i żadnego z tych
    trzech nie może zabraknąć) i... tylko tyle, przynajmniej po stronie klienckiej. Czy
    jest granica stosowalności tego podejścia i dlaczego jest właśnie tam?

    Jest wiele powodów by nie robić tego w ten sposób. Goły HTML, JS i CSS
    oznacza, że trzeba narąbać tony (istniejącego już) kodu, który załata wiele
    braków i niedoróbek tej golizny. Wymyślając te swoje ficzery tworzysz de
    facto kolejnego frameworka, z tym, że nikt poza Tobą i Twoim zespołem go
    nie zna. Zatrudnij teraz do zespołu nowego developera i każ mu to
    zrozumieć, rzeźnia. Dodatkowo musisz pisać dokumentację. Używając
    frameworka open source masz produkt rozwijany za darmolca przez
    setki/tysiące developerów, udokumentowany, wytestowany na olbrzymiej
    liczbie platform i środowisk, autonaprawiający się (bugi naprawia core
    team). Dodatkowo, gdy potrzebujesz zmienić kogoś w zespole lub nawet cały
    zespół to szukasz developerów znających X, Y lub Z i masz niemal od strzału
    gotowego programistę, który widzi kod i rozumie co się w nim dzieje.
    Ponadto popularne frameworki mają masę dodatkowych narzędzi wspomagających
    typu pluginy do edytorów, powiązane biblioteki rozwiązujące problemy nie
    ujęte w samym frameworku, itd. Masz też często literaturę na ich tenat.
    Oraz olbrzymią bazę społecznościową, gdzie możesz zadawać pytania i niemal
    od ręki dostawać pomoc.

    --
    pozdrawiam
    Roman Tyczka


  • 6. Data: 2020-05-20 20:46:05
    Temat: Re: Web development
    Od: Maciej Sobczak <s...@g...com>

    > Jest wiele powodów by nie robić tego w ten sposób.

    A jednak pobawię się w adwokata diabła i spróbuję znaleźć kontr-argumenty.

    > Goły HTML, JS i CSS
    > oznacza, że trzeba narąbać tony (istniejącego już) kodu, który załata wiele
    > braków i niedoróbek tej golizny.

    Np. jakich braków i niedoróbek? Myślałem, że kolejne standardy tychże były
    opracowywane właśnie z myślą o usprawnieniach. Rozumiem, że 20 lat temu czegoś mogło
    tam nie być, ale czego tam nie ma w 2020 roku?

    > Wymyślając te swoje ficzery tworzysz de
    > facto kolejnego frameworka,

    Tak. Prawdę mówiąc każdy projekt, jeśli jest właściwie i na bieżąco refaktoryzowany,
    wyłania coś, co ma szensę istnieć odrębnie. To może być jedna funkcja pomocnicza, a
    może być framework. Albo cokolwiek pomiędzy.

    > z tym, że nikt poza Tobą i Twoim zespołem go
    > nie zna.

    Ale za to ja i mój zespół znamy go w 100%.

    > Zatrudnij teraz do zespołu nowego developera i każ mu to
    > zrozumieć, rzeźnia.

    Z moich doświadczeń wynika, że nowy developer najwięcej problemów ma ze zrozumieniem
    dziedziny problemu, czyli przedmiotu realizowanego projektu. Ogarnięcie się w samym
    kodzie i rozwiązywanie kolejnych wyzwań przez analogię z istniejącym kodem jest
    najmniejszym problemem.

    > Dodatkowo musisz pisać dokumentację.

    Od kiedy pisanie dokumentacji jest złe? :-)

    > Używając
    > frameworka open source masz produkt rozwijany za darmolca przez
    > setki/tysiące developerów,

    Z pierdylionem rzeczy, których nie potrzebuję, ale które muszę zintegrować, i
    zapłacić za nie pamięcią, pasmem, itp.

    > Dodatkowo, gdy potrzebujesz zmienić kogoś w zespole lub nawet cały
    > zespół to szukasz developerów znających X, Y lub Z i masz niemal od strzału
    > gotowego programistę,

    I tu mam przeciwne spotrzeżenie. Ilość dostępnych frameworków oznacza, że ten
    ekosystem jest niesamowicie sfragmentowany, więc pula "talentów" jest mniejsza, niż
    mogłaby być, gdybyśmy celowani w bardziej podstawowe rozwiązania. Konkretnie: jak byś
    nie liczył, ilość developerów znających jakiś wybrany framework do JSa jest mniejsza,
    niż ilość developerów znających JSa.
    A to oznacza, że developer znający framework X sam siebie uzna za bardziej
    wyjątkowego (i słusznie), przez co będzie droższy. Czyli developer od frameworka X
    będzie droższy, niż developer od JSa.
    I teraz mam zatrudnić cały zespół takich jednorożców?

    To samo dotyczy wymiany zawodnika na innego.

    Jeszcze gorzej, jak się nam projekt zestarzeje, po tym jak wszystkich zaskoczył i
    niestety odniósł sukces. Wtedy okaże się, że poszukiwanie developera znającego jakiś
    niemodny już framework będzie podobne do szukania programisty np. COBOLa.

    Jeśli mówimy o kosztach, to właśnie teraz o nich mówimy.

    > Ponadto popularne frameworki mają masę dodatkowych narzędzi wspomagających
    > typu pluginy do edytorów,

    Których nie potrzebuję jeśli nie używam frameworków? Czyli frameworki rozwiązują
    problemy, których nie mam, jeśli ich nie używam? :-)
    Albo i nie rozwiązują. Co jeśli mój ulubiony edytor nie jest ulubionym edytorem
    młodzieży pasjonującej się jakimś "nowoczesnym" frameworkiem?

    > Masz też często literaturę na ich tenat.

    Znowu - nie potrzebuję jej, jeśli tych frameworków nie używam.

    > Oraz olbrzymią bazę społecznościową,

    Ale sfragmentowaną bardziej (a przez to mniej dostępną), niż bazę społecznościową
    bardziej podstawowego stosu.
    I przy bardziej podstawowym stosie mogę tej bazy społecznościowej potrzebować mniej.

    To jak w końcu? Co jest tańsze?

    Czy ktoś ma podobne obserwacje?

    --
    Maciej Sobczak * http://www.inspirel.com


  • 7. Data: 2020-05-21 12:42:33
    Temat: Re: Web development
    Od: Roman Tyczka <n...@b...no>

    On Wed, 20 May 2020 11:46:05 -0700 (PDT), Maciej Sobczak wrote:

    >> Jest wiele powodów by nie robić tego w ten sposób.
    >
    > A jednak pobawię się w adwokata diabła i spróbuję znaleźć kontr-argumenty.
    >
    >> Goły HTML, JS i CSS
    >> oznacza, że trzeba narąbać tony (istniejącego już) kodu, który załata wiele
    >> braków i niedoróbek tej golizny.
    >
    > Np. jakich braków i niedoróbek? Myślałem, że kolejne standardy tychże były
    opracowywane właśnie z myślą o usprawnieniach. Rozumiem, że 20 lat temu czegoś mogło
    tam nie być, ale czego tam nie ma w 2020 roku?

    Owszem, jest tych braków coraz mniej, ale są, a po drugie nie w każdej
    przeglądarce wszystko dsziała identycznie, dlatego stosuje się tzw.
    polyfille i biblioteki ujednolicające interfejs, podam dwa przykłady:
    https://underscorejs.org/
    https://github.com/axios/axios

    Podobnie np. z HTML i CSS, szybciej i wygodniej buduje się stronę na
    Bootstrapie, niż w gołym kodzie - choć to ostatnio jest już prawie
    niepotrzebne.
    Niemniej, gdy znasz np. Bootstrapa to czytając HTMLa z użytymi klasami BS
    od razu wiesz jak to się zachowa, a gdy masz zamknięte wynalazki to musisz
    szukać źródeł i ryć.

    >> Wymyślając te swoje ficzery tworzysz de
    >> facto kolejnego frameworka,
    >
    > Tak. Prawdę mówiąc każdy projekt, jeśli jest właściwie i na bieżąco
    refaktoryzowany, wyłania coś, co ma szensę istnieć odrębnie. To może być jedna
    funkcja pomocnicza, a może być framework. Albo cokolwiek pomiędzy.
    >
    >> z tym, że nikt poza Tobą i Twoim zespołem go
    >> nie zna.
    >
    > Ale za to ja i mój zespół znamy go w 100%.

    No... albo tak albo nie... a na końcu okazuje się, że pod presją czasu,
    product managera lub czegokolwiek ten wasz framework to potworek o dwunastu
    głowach i sześciu ogonach, którego tak naprawdę nikt już nie ogarnia. A
    dokumentacja? ...eee... no nie pisaliśmy, bo każdy znał na 100% ;-)

    >> Zatrudnij teraz do zespołu nowego developera i każ mu to
    >> zrozumieć, rzeźnia.
    >
    > Z moich doświadczeń wynika, że nowy developer najwięcej problemów ma ze
    zrozumieniem dziedziny problemu, czyli przedmiotu realizowanego projektu. Ogarnięcie
    się w samym kodzie i rozwiązywanie kolejnych wyzwań przez analogię z istniejącym
    kodem jest najmniejszym problemem.

    Zależy o jakim poziomie mówisz, bo ten z samego dołu developer to klepacz
    kodu, nie zna i nie musi znać dziedziny, on ma zadanka w tablicy agilowej i
    koduje.

    >> Dodatkowo musisz pisać dokumentację.
    >
    > Od kiedy pisanie dokumentacji jest złe? :-)

    Kto twierdzi, że złe? Jest kosztowne.

    >> Używając
    >> frameworka open source masz produkt rozwijany za darmolca przez
    >> setki/tysiące developerów,
    >
    > Z pierdylionem rzeczy, których nie potrzebuję, ale które muszę zintegrować, i
    zapłacić za nie pamięcią, pasmem, itp.

    Jeśli wybierzesz nieodpowiedni framework to tak.

    >> Dodatkowo, gdy potrzebujesz zmienić kogoś w zespole lub nawet cały
    >> zespół to szukasz developerów znających X, Y lub Z i masz niemal od strzału
    >> gotowego programistę,
    >
    > I tu mam przeciwne spotrzeżenie. Ilość dostępnych frameworków oznacza, że ten
    ekosystem jest niesamowicie sfragmentowany, więc pula "talentów" jest mniejsza, niż
    mogłaby być, gdybyśmy celowani w bardziej podstawowe rozwiązania. Konkretnie: jak byś
    nie liczył, ilość developerów znających jakiś wybrany framework do JSa jest mniejsza,
    niż ilość developerów znających JSa.
    > A to oznacza, że developer znający framework X sam siebie uzna za bardziej
    wyjątkowego (i słusznie), przez co będzie droższy. Czyli developer od frameworka X
    będzie droższy, niż developer od JSa.
    > I teraz mam zatrudnić cały zespół takich jednorożców?
    >
    > To samo dotyczy wymiany zawodnika na innego.
    >
    > Jeszcze gorzej, jak się nam projekt zestarzeje, po tym jak wszystkich zaskoczył i
    niestety odniósł sukces. Wtedy okaże się, że poszukiwanie developera znającego jakiś
    niemodny już framework będzie podobne do szukania programisty np. COBOLa.
    >
    > Jeśli mówimy o kosztach, to właśnie teraz o nich mówimy.

    To powiedz mi czym się różni znalezienie programisty do dobrego,
    udokumentowanego i przetestowanego frameworka, który dziś już nie jest w
    pierwszej piątce od znalezienia programisty do autorskiego, zamkniętego i
    dużo mniej dopracowanego frameworka pisanego w firmie?

    >> Ponadto popularne frameworki mają masę dodatkowych narzędzi wspomagających
    >> typu pluginy do edytorów,
    >
    > Których nie potrzebuję jeśli nie używam frameworków? Czyli frameworki rozwiązują
    problemy, których nie mam, jeśli ich nie używam? :-)

    To czy potrzebujesz to Twój wybór, osobisty. Ja mówię o tym, że są
    narzędzia bardzo przyspieszające i organizujące pracę w danym frameworku,
    bo ku temu zostały stworzone. Nie mam na myśli narzędzi, które utrudniają
    pracę czy bez których nie da się frameworka używać.

    > Albo i nie rozwiązują. Co jeśli mój ulubiony edytor nie jest ulubionym edytorem
    młodzieży pasjonującej się jakimś "nowoczesnym" frameworkiem?

    Wtedy nie masz takich narzędzi, czyli dokładnie tak jak z autorskim
    frameworkiem.

    >> Masz też często literaturę na ich tenat.
    >
    > Znowu - nie potrzebuję jej, jeśli tych frameworków nie używam.

    Z kolei używając swojego nawet jeśli jej potrzebujesz to nie masz.

    >> Oraz olbrzymią bazę społecznościową,
    >
    > Ale sfragmentowaną bardziej (a przez to mniej dostępną), niż bazę społecznościową
    bardziej podstawowego stosu.
    > I przy bardziej podstawowym stosie mogę tej bazy społecznościowej potrzebować
    mniej.

    Nawet mocno pofragmentowana jest o kilka rzędów większa niż Twój zespół i
    wszyscy znajomi programiści.

    > To jak w końcu? Co jest tańsze?
    >
    > Czy ktoś ma podobne obserwacje?

    No właśnie, ktoś coś?

    --
    pozdrawiam
    Roman Tyczka


  • 8. Data: 2020-05-21 21:03:09
    Temat: Re: Web development
    Od: Maciej Sobczak <s...@g...com>

    > Owszem, jest tych braków coraz mniej, ale są, a po drugie nie w każdej
    > przeglądarce wszystko dsziała identycznie, dlatego stosuje się tzw.
    > polyfille i biblioteki ujednolicające interfejs, podam dwa przykłady:
    > https://underscorejs.org/
    > https://github.com/axios/axios

    Pojedyncze biblioteki są bezpieczniejszym rozwiązaniem, niż framework, który z natury
    narzuca więcej. Ja nie mam problemu z bibliotekami.

    > Niemniej, gdy znasz np. Bootstrapa to czytając HTMLa z użytymi klasami BS
    > od razu wiesz jak to się zachowa, a gdy masz zamknięte wynalazki to musisz
    > szukać źródeł i ryć.

    Ale ja nie chcę mieć zamkniętych wynalazków, skoro ustaliliśmy, że ostatnio (i z
    biegiem czasu) wszystko co potrzeba, jest w standardzie.

    > No... albo tak albo nie... a na końcu okazuje się, że pod presją czasu,
    > product managera lub czegokolwiek ten wasz framework to potworek o dwunastu
    > głowach i sześciu ogonach, którego tak naprawdę nikt już nie ogarnia. A
    > dokumentacja? ...eee... no nie pisaliśmy, bo każdy znał na 100% ;-)

    Jest takie ryzyko. Ale ja widzę, że to samo dzieje się z zewnętrznymi frameworkami.
    Gdy autorzy już ich nie ogarniają, to powstaje nowy framework. Jeszcze fajniejszy. I
    pozbawiony wad poprzedniego frameworka!

    To nie jest tak, że zewnętrzne rozwiązania się nigdy nie degradują. Degradują się a
    nawet z tego powodu wychodzą z użycia. ActiveX? Applety? Flash? To są oczywiste
    archaizmy, ale świat frameworków niebezpiecznie przyśpieszył i do tej grupy dołączają
    frameworki, które jeszcze niedawno były cool.

    > Zależy o jakim poziomie mówisz, bo ten z samego dołu developer to klepacz
    > kodu, nie zna i nie musi znać dziedziny, on ma zadanka w tablicy agilowej i
    > koduje.

    Ja pracowałem w miejscach, gdzie jednak "ten z samego dołu" musiał wiedzieć, co
    koduje. Bo by bez tej wiedzy po prostu nie zakodował. I ta wiedza jest zwykle
    trudniejsza, niż znajomość frameworka.

    > > Od kiedy pisanie dokumentacji jest złe? :-)
    >
    > Kto twierdzi, że złe? Jest kosztowne.

    Policzmy. Nie za bardzo mam na czym liczyć poza moim projektem YAMI4, ale skoro go
    mam, to policzmy. Lubię pisać "prozę" i nigdy nie słyszałem zarzutu, że moja
    dokumentacja ma jakieś braki, więc uważam, że to właściwy przykład. Otóż w tym
    projekcie dokumentację robi Doxygen z odpowiednich komentarzy w kodzie, których
    jest... 5%, jeśli liczyć ilość linii. To jest wartość obiektywna, którą potrafię
    zmierzyć - ale jest jeszcze odczucie subiektywne, że ta część dokumentacyjna się
    zmienia najrzadziej (np. tam się nie robi optymalizacji, nie poprawia algorytmów, nie
    debuguje, itd.), więc wysiłek w relacji do całości jest pewnie rząd, jeśli nie dwa,
    wielkości mniejszy.

    I to jest ten "koszt". Czyli żaden koszt.
    Prawdziwym kosztem jest ten właściwy kod a nie dokumentacja. I tylko ten właściwy kod
    może być motywacją do tego, żeby go nie pisać i postawić na istniejący framework.

    > > Z pierdylionem rzeczy, których nie potrzebuję, ale które muszę zintegrować, i
    zapłacić za nie pamięcią, pasmem, itp.
    >
    > Jeśli wybierzesz nieodpowiedni framework to tak.

    Słusznie. A skąd mam wiedzieć, czy jest odpowiedni?
    Zwykle wygląda to tak, że tworząc zespół do kodu, którego jeszcze nie ma, zatrudniam
    pierwszego jednorożca, który wybiera framework. Potem on odchodzi z zespołu (albo
    awansuje - na jedno wychodzi) a reszta się męczy z konsekwencjami jego wyborów z
    wczesnego etapu projektu.

    Więc skąd mam wiedzieć, że mój pierwszy zatrudniony jednorożec wybierze odpowiedni
    framework?

    > To powiedz mi czym się różni znalezienie programisty do dobrego,
    > udokumentowanego i przetestowanego frameworka, który dziś już nie jest w
    > pierwszej piątce od znalezienia programisty do autorskiego, zamkniętego i
    > dużo mniej dopracowanego frameworka pisanego w firmie?

    Tym, że w drugim przypadku zatrudniam programistę do standardowego stacku, bo z jego
    punktu widzenia właśnie to zobaczy w firmie. A to, że część kodu w projekcie zostanie
    wydzielona przez refaktoryzację do osobnego bytu (i czy w ogóle to nastąpi), to jest
    szczegół, który w ogóle nie musi przeszkadzać w rekrutacji.

    Natomiast w pierwszym przypadku muszę napisać w ofercie pracy, że szukam programisty
    do frameworka X. I tym ogłoszeniem od razu zniechęcam tych, którzy tego frameworka
    nie znają. Czyli ograniczam target, a przez to zwiększam koszt.

    > >> Oraz olbrzymią bazę społecznościową,
    > >
    > > Ale sfragmentowaną bardziej (a przez to mniej dostępną), niż bazę społecznościową
    bardziej podstawowego stosu.
    > > I przy bardziej podstawowym stosie mogę tej bazy społecznościowej potrzebować
    mniej.
    >
    > Nawet mocno pofragmentowana jest o kilka rzędów większa niż Twój zespół i
    > wszyscy znajomi programiści.

    Nie, bo moja docelowa społeczność to standardowy stack. Ta społeczność jest zawsze
    największa. Ja nigdy nie zapytam na grupie dyskusyjnej, czy ktoś wie, jak się coś
    robi w moim własnym frameworku. Natomiast w przypadku cudzego frameworku już bym może
    musiał pytać.

    Czyli dalej nie wiemy, co się bardziej opłaca.

    --
    Maciej Sobczak * http://www.inspirel.com

strony : [ 1 ]



Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: