LukeJL
2017-06-13 19:46

Zeruję swoją znajomość CSS. Uczę się natywnego grida. Wsparcie jest dość duże: http://caniuse.com/#feat=css-grid a możliwości spore https://css-tricks.com/snippets/css/complete-guide-grid/

LukeJL

to będzie kolejna zmiana w sposobie jaki piszę layouty. Pisałem już tabelki, "layouty na divach" (zabawa z position, display, float), używałem flexa, responsywny grid z Bootstrapa, a teraz to. No ciekawe, czy wreszcie okaże się to używalne czy znowu za rok wymyślą coś lepszego.

czysteskarpety

trochę sporo pisania, długie klasy, wsparcie takie se, ja zostanę przy sprawdzonych rozwiązaniach, szkoda mi czasu na to

onemangamedev

Ja teź na razie zostaję przy fleksie. Zapewnia mniej więcej tę samą funkcjonalność, ale jak najbardziej popieram. Potrzeba nam ludzi, którzy będą przecierać szlaki :)

vpiotr

Wymyślają takie cuda bo nie wiedzą jak używać dobrego sprawdzonego VCL-a :)

grzesiek51114

@LukeJL: rychło wczas. Wreszcie człowiek przestanie dostawać białej gorączki pozycjonując itemy w divach. Widzę tutaj bardzo podobne podejście do pozycjonowania elementów jak w gridzie w WPF'ie. Nareszcie intuicyjne, bo czasami zależności w css było tyle, że się odechciewało. Może polubię się na nowo z css :)

PS: Może i powstało do tej pory coś jeszcze co pozwala na łatwe pozycjonowanie elementów na stronie ale jako, że jestem starym dziadem, który odszedł od webu to mogę nie być tego świadom :P

LukeJL

może sensowny system layoutu pozwoliłby wreszcie na powrót WYSIWYG i zrobienie Delphi do HTMLa (czyli masz formę i wrzucasz komponenty). W Delphi się super programowało.

LukeJL

z drugiej strony pierwsze wrażenie moje jest takie, że ten grid w CSS jest dość skomplikowany, ale zobaczymy
.

vpiotr

@LukeJL: nawet było coś takiego (Delphi for PHP, RadPHP), ale nie widziałem tego w działaniu: http://www.jomitech.com/images/screenshots/c4phplitedsnlg.png

LukeJL

Od czasu do czasu pojawiają się w webie różne pomysły na wskrzeszenie RAD czy WYSIWYG, ale żaden się póki co nie przebił do mainstreamu. A moim zdaniem to jest kluczowe. Nie chodzi o to, żeby był sobie WYSIWYG bo jako proof of concept to masę rzeczy takich jest, tylko bardzo słabe, albo jeśli nawet fajne, to raczej zabawki nienadające się do profesjonalnej pracy. Popularność rozwiązania natomiast sprzyjałoby po pierwsze temu, żeby się to rozwijało, dwa, że mogłaby się zrobić moda na takie rozwiązania - co sprawiłoby, że coraz więcej narzędzi by takich powstawało i jedne od drugich by kopiowały najlepsze pomysły - i w końcu zrobiono by coś co nadaje się do profesjonalnej pracy.

LukeJL

Chociaż niby do Reacta się coś pojawiło, kilka nawet - Deco i coś jeszcze, jakieś React Studio - nie próbowałem ich jeszcze. Ale z drugiej strony... jakoś nie pałam chęcią do tooli pod jeden framework. Sam kiedyś chciałem zrobić IDE do Angulara jedynki - dobrze, że nie zrobiłem, bo w międzyczasie stał się modny React - a Angular jedynka jest skazany na powolne wymarcie. Tzn. zrobienie czegoś pod konkretny framework na pewno jest o wiele łatwiejsze niż zrobienie uniwersalnego narzędzia - ale z drugiej strony np. za rok React może przestać być modny i co wtedy? Bez sensu trochę.

LukeJL

moim zdaniem core takich aplikacji powinien wspierać jedynie co najwyżej HTML/CSS/JS, a wsparcie frameworków powinno być w pluginach (być może oficjalnych pluginach zrobionych przez twórców - ale chodzi mi o oddzielenie wsparcia frameworka od samego programu, na poziomie architektury i designu - a nie uzależnianie się od tego, że akurat dzisiaj jest modny React i zakładanie, że zawsze tak będzie).

furious programming

@LukeJL: jeśli ciągle będziesz myślał o „modzie” to nigdy nic nie wybierzesz.

LukeJL

Tu nie chodzi o wybór. Myślę, że można równocześnie wybrać modną technologię (np. React) a jednocześnie pisać aplikacje w sposób, który nas zabezpieczy przed tym, że kiedyś dana technologia przestanie być modna (nawet właśnie w ten sposób, żeby oddzielić to jakoś od rdzenia apki).

LukeJL

w ogóle ludzie za dużo myślą o wyborze technologii a za mało o separation of concerns (w kontekście projektów, aplikacji) czy o ogólnej umiejętności programowania (w kontekście kariery).

LukeJL

bardziej krótkowzroczni albo entuzjastyczni, bo zauważyłem, że ktoś może programować z 10 lat, jednak może nie myśleć o tym co będzie za pół roku czy rok, tak jakby umiał coś zakodować, żeby działało, ale był pozbawiony umiejętności wyczuwania potencjalnych problemów. No i entuzjazm też przeszkadza - to raczej dotyka mniej doświadczonych programistów - którzy np. się jarają jakimś konkretnym frameworkiem, ale jeszcze się nie sparzyli, więc są gotowi postawić wszystko na jedną kartę, na jeden framework, na jedną technologię i są gotowi nawet się kłócić o to, czy lepszy jest React czy Angular (sam taki byłem, zanim nie zrozumiałem, że wszystkie frameworki są do d**y. Warto ich używać wtedy, kiedy to rozwiązuje jakiś problem, ale nie warto ich stawiać na piedestale).

członek zarządu

Jeszcze bym dołożył czas - jeśli ktoś ceni czas i robi jakąś aplikację dla realnych użytkowników, to zmieniają się priorytety z "jaka słit technologia, muszę się jej nauczyć" na "jak tu szybko zrobić, żeby userów zadowolić"

LukeJL

no ale takie podejście "jak tu szybko zrobić, żeby userów zadowolić" też jest niedobre, bo się wprowadza spaghetti code do projektu tylko po to, żeby zrobić ficzer chciany przez userów. Moim zdaniem lepiej podchodzi do tego taki JetBrains, gdzie masz bardzo dobre wsparcie usera (np. niedawno ankietę wypełniałem na temat tego co sądzę o Webstormie i nawet się nie spodziewałem - a dostałem na tę ankietę odpowiedź na to, jak mogę rozwiązać swój problem z Webstormem. Inna sytuacja to piszę sobie coś na Twitterze w nurcie hejtu na Webstorma, który miał iść w eter - a tu też nagle się odzywa ktoś z Jetbrains i próbuje mi poradzić. Co prawda nie udało mu/jej się doradzić - ale doceniam troskę o usera. Natomiast pod kątem developmentu to Webstorm się toczy o wiele bardziej wolno (niektóre bugi/request ficzery leżą od dawna i są ignorowane, ale to standard), jednak stabilnie, ciągle coś dodają z każdą wersją i sprawiaja, że użytkownicy są coraz bardziej zadowoleni z ich produktu (czyli łączą szybki PR/pomoc techniczną z bardziej powolnym acz stabilnym developmentem).

LukeJL

nie używam obecnie Webstorma, ale szanuję takie podejście. To nie jest coś na zasadzie "userzy chcą/klient zamówił to robimy w tydzień byle jak jakiś ficzer" (jak to się zdarza w wielu firmach), nie jest to też coś w rodzaju "musimy gonić targety i zmieniać co kilka miesięcy GUI, żeby przyciągnąć/utrzymać userów" -- czyli taktyka Facebooka/Apple/Google'a, gdzie co chwila musi być radykalna zmiana w czymś, nawet na gorsze, żeby tylko była.

członek zarządu

Spaghetti code tez robia niedoświadczeni ludzie :P Normalnie ogarniety developer nie napisze kodu poniżej poziomu przyzwoitosci. Moze nie rpzewidzi roznych corner casów... ale da się to potem ogarnąć. Nie ma sensu dodawanie tego co chcą userzy za każdym razem, ale robienie dobrze userom jest generalnie celem developmentu apki :P Z tym, że userzy nie zawsze wiedzą co dla nich najlepsze (w danym momencie).

LukeJL

widocznie nie jestem ogarniętym developerem, bo sam piszę czasem spaghetti kod, jak chcę na szybko zaprototypować jakieś rozwiązanie ;) chociaż w miarę możliwości staram się nie commitować spaghetti kodu (a jeśli commituję, to potem dokonać jakiegoś refactoru, albo w ogóle napisać od nowa ładniej).

LukeJL

zresztą myślę, że każdy dość duży projekt zawiera w sobie elementy spaghetti code albo big ball of mud czy innego rodzaju entropii xD

członek zarządu

No to też zależy od progu bólu, ale nie warto tak robic :P Ale chcialem dodać, że ja np. nie mam nic do hacków w kodzie/architekturze jeśli to nas powstrzymuje przed deploymentem. Ale to takie pitu pitu, kazda sytuacja jest inna :P

LukeJL

Powiem tak - mając kilka godzin można zakodować baaaaaaaaardzo wiele i czasem lepiej zakodować, i zobaczyć jak coś będzie wyglądało w praktyce i potem podjąć decyzję "co dalej" niż te kilka godzin stracić na bezowocnych dyskusjach na spotkaniu typu "ja bym zrobił to w ten sposób", "a ja nie", "a ja uważam, że to jest ficzer na 5 story pointów a nie na 1", "a ja myślę, żeby użyć Angulara do tego a nie Reacta"

LukeJL

ja jestem zwolennikiem testowania pomysłów w praktyce i potem podejmowania decyzji co dalej (czasem pewien ficzer w ogóle okazuje się złym pomysłem na starcie i w ogóle należałoby zrobić kompletnie inaczej). Niestety dużo programistów woli zamiast prototypować to prowadzić godzinami dyskusje "tak czy nie", snuć hipotezy na temat tego, czy lepiej będzie zrobić X czy Y, albo też masę czasu spędzać na definiowaniu tasków w issue trackerze i robieniu estymacji... zamiast po prostu coś zakodować i dyskutować już o kawałku kodu, który istnieje (no dobra, czasem się spotkałem z tym, że się robi tzw. spike'i i to jest okej, ale mam wrażenie, że to jest dość rzadką praktyką)

LukeJL

z tymi issue trackerami to oczywiście nie dotyczy tylko programistów, a różnych managierów.

Desu

Tak jeszcze à propos tego spaghetti. Ja do niedawna starałem się wszystko zrobić od razu super i byłem mało produktywny. Zauważyłem, że mimo to, że obmyślałem design kilka godzin, a czasami dni, to i tak koniec końców był on w 90% przypadków do d**y. Kończyło się to tym, że z braku zrozumienia tematu nie byłem w stanie przewidzieć pewnych rzeczy, które wychodziły w trakcie pracy nad ficzerem. Nie można obmyślić dobrego desingu, jeżeli się czegoś wcześniej nie robiło (albo jest to bardzo trudne). Teraz koduje byle działało (oczywiście z zachowaniem dobrego nazewnictwa itp. staram się nie tworzyć syfu on purpose, ale duplikacji mówię zdecydowane czemu nie). Robię to w ramach eksperymentu z TDD. Później jak zyskam wiekszą wiedzę na temat ficzeru, zbiore uwagi od managementu to refaktoruje. Dużo łatwiej jest przemieszczać już działające klocki, mając wiedzę, którą się zdobyło podczas tworzenia spaghetti. W spaghetti nie ma nic złego, ale wazne żeby nie pominąć ostatniego kroku - refaktoryzacji i oczywiście testów automatycznych. Także @członek zarządu częściowo masz rację. Im więcej doświadczenia ma deweloper, tym mniejszą ma potrzebę tworzenia spaghetti, bo ma większe doświadczenie w tworzeniu różnych ficzerów, ale nie oznacza to, że doświadczeni deweloperzy go nie tworzą. Bo nawet na największego koksa znajdzie się ficzer, którego jeszcze nie robił i wtedy trudno uniknąć spaghetti.

LukeJL

No dokładnie. Jak dla mnie programowanie to jest jeden wielki research i budowanie sobie w głowie modelu myślowego "co się sprawdza", "co się niesprawdza", "w jaki sposób można połączyć dwa elementy ze sobą", "jakie problemy mogą wystąpić", "ile czasu zajmie zrobienie danej rzeczy", "jakie podejścia do całościowej architektury są dobre, a które okazały się nieskuteczne" itp. i dopiero potem jak programista/programiści mają taki model myślowy w głowie to mogą zrobić coś porządnie. Dlatego tyle frameworków (w JS to np. Angular, Phaser, React) musi zostać przepisywanych potem na nowo bo teamy które piszą frameworki dopiero się uczą jak powinno się je robić, budują sobie know how.

czysteskarpety

a na końcu i tak się wszystko sprowadza do ceny i terminów :)

vpiotr

@Desu: spaghetti kończy się w momencie gdy musisz supportować własny kod. Gdy działasz w organizacji w której do swojego kodu wracasz za 5 lat, a menadżer pyta się kiedy skończysz zaraz po tym jak wystartowałeś task, to robisz "aby działało". Spaghetti leży tuż obok techniki CP na tablicy szkodliwości pracy w IT dla developera.

LukeJL

fakt, często spaghetti wiąże się z dużą rotacją programistów - gdzie brzydki jak cholera kod modułu X został napisany przez "kolegę, który już tu nie pracuje" - wtedy zwykle już nie drążę dalej, choć zastanawiam się, czy to spaghetti code było przyczyną dla którego kolega, "już tu nie pracuje" (zwolniony za brzydki kod?), czy może raczej tak jak mówisz - ludzie świadomie kładą lachę, bo wiedzą, że i tak po nich przejmie projekt ktoś inny i będzie się męczył (chociaż pamiętam, że kiedyś wyblame'owałem gościa, który naprawdę koszmarny kod pisał i potem się okazało, że gościu jest... seniorem w innym projekcie. Min. dlatego nie wierzę w seniorów).

tdudzik

@LukeJL: dlatego w outsourcingu w ogóle jest tragedia. Duża rotacja programistów i projektów powoduje że jakoś jest naprawdę słaba. Często też zatrudnia się słabych ludzi bo nie przywiązuje się uwagi do rekrutacji, a tych co są się nie szkoli. Fajnie gdyby każdy brał odpowiedzialność za to co robi i wziął sobie do serca zasadę scoutów, nawet jeśli przyszedł do projektu na tydzień.