•  

    pokaż komentarz

    2 lata programujesz i już chcesz uczyć innych? Ja mam 12 na karku i nadal uważam, że da się zrobić więcej w kontekście optymalizacji.

  •  

    pokaż komentarz

    Jak będziesz miał 40 lat doświadczenia to też wszystkiego nie będziesz umiał. Ucze tego co potrafię :)

    •  

      pokaż komentarz

      @nieinformatyk: Hehehe :) a jaką masz pewność, że w pewnym momencie nie przekażesz innym błędnych praktyk? Nie pytam złośliwie, raczej przez pryzmat własnego doświadczenia, bo gdybym dziś napisał taką aplikację jaka pisałem mając 1-2 lata doświadczeń wyrzucono by mnie na zbity pysk z wszelkich poważnych zleceń :)

      Błędne nawyki, niewłaściwie wypracowane metodologie pracy i brak dogłębnej wiedzy dot. wydajności. Najprostszy przykład to choćby porównanie wydajności EXISTS do JOIN. Takich kwiatków jest całe multum i niestety :) większość programistów dowiaduje się o nich dopiero w momencie kiedy napisali aplikację, która okazała się być niewydajna. NAJGORSZE jest to, że początkowo wszystko jest ok. Wszystko działa. Mija miesiąc, rok, dwa, w bazie pojawia się zaledwie 200 000 rekordów i system pada. Programisty już dawno nie ma w pobliżu, a klient zostaje z koniecznością wydania niebotycznych pieniędzy na optymalizacje i wdrażanie się w kod obcego programisty :)

      Masę takich sytuacji ratowałem i z doświadczenia wiem, że jest MULTUM ludzi, którzy potrafią "programować" czyli postawić wordpressa, a nawet napisać autorskiego CMS'a, ale znaleźć takich, którzy potrafią docenić różnicę w czasie generowania rezultatu programu po stronie serwera na poziomie zaledwie 200 ms jest obłędnie ciężko :)

      Wiesz co jest moim zdaniem największym absurdem jeśli chodzi o połączenie baz z aplikacjami? To, że praktycznie ŻADEN kurs programowania nie zaznacza wyraźnie, że generalnie NIE POWINNO SIĘ korzystać z baz danych jeśli nie jest to konieczne, ponieważ sam proces łączenia z nimi jest niewydajny, ilość slotów dostępnych do połączeń po stronie aplikacji jest ograniczona. Prosty przykład. Masz aplikację z danymi przechowywanymi w bazie. Ustawienia, komunikaty formularzy, komunikaty systemowe, treści statyczne, ustawienia języków, ustawienia walut itd. Takich tabel masz powiedzmy 10-15. MUSISZ przechowywać dane w bazie po to, by od strony administracyjnej dało się je przeglądać, przeszukiwać i wydajnie obrabiać. Więc robisz tabele, nabijasz danymi, robisz moduły administracyjne.

      Koniec końców okazuje się, że w tych tabelach masz po kilkaset rekordów max, czyli znikome ilości. KAŻDY user wchodzący na stronę odpala multum połączeń z bazą, a że baza kolejkuje zadania im więcej jest użytkowników tym bardziej spowalnia cała infrastruktura. ŻADEN kurs jaki jeszcze do niedawna istniał w polskiej sieci nie mówił, ze bazy są spoko, ale w tej sytuacji NIE MOGĄ być wykorzystywane do obsługi aplikacji, że każda aktualizacja choćby ustawień powinna oczywiście nadpisywać rekordy w bazie, ale powinna też aktualizować stosowne pliki konfiguracyjne i to z nich powinna korzystać część kliencka. Efekt? Zmniejszenie obciążenia bazy prawie do zera, zwiększenie szybkości generowania strony przez serwer z 900 ms do 150 ms, zmniejszenie zapotrzebowania na RAM, procesor i ilość slotów połączeń dla użytkowników i baz.

      Rozumiesz do czego zmierzam? Istnieje subtelna różnica między umiejętnością wykonania złożonego zapytania do bazy, a umiejętnością wyważonego projektowania baz, korzystania z nich wtedy kiedy są konieczne i TYLKO wtedy.

    •  

      pokaż komentarz

      @deathcoder: Z jednej strony jestem pełen podziwu Twojej wiedzy i wytrwałości w budowaniu swojej ścieżki kariery - 12 lat to sporo jak na dzisiejszą sytuację :) Fajnie, że poświecasz swój czas na to by przedstawić swój, dużo szerszy i wzbogacony dużym doświadczeniem punkt widzenia. Im trudniejsze zagadnienie do analizy tym mniej osób potrafiących to zrobić - pełna zgoda.

      Z drugiej strony skwitowałbym Twóją wypowiedz jednym słowem - perfekcjonizm. Zawsze jest coś do poprawy, zawsze znajdzie się ktoś lepszy od Ciebie i zawsze będziesz mógł zrobić coś lepiej niż robiłeś do tej pory. Gdyby tak podchodzić do życia to świat by nie szedł do przodu, bo nikt nie podejmowałby się żadnego zadania.

      PS. Ten Twój drugi akapit do złudzenia przypominał "Najlepsze praktyki PL/SQL" Steve Feuersteina. Trafiłem czy wniosek po 12 latach pracy?

    •  

      pokaż komentarz

      @nieinformatyk: Nie znam tej książki, ale ja nie wymyślam niczego nowego, na to o czym piszę wpadło już z całą pewnością wielu znakomitych programistów mądrzejszych ode mnie. Niewiele książek technicznych czytałem w życiu. Jestem samoukiem stąd nauczenie się wielu rzeczy zajęło mi więcej czasu niż np. ludziom pracującym w korporacjach, gdzie mieli do pomocy starszych i mądrzejszych od siebie. Z drugiej jednak strony miałem dzięki temu czas na to, by szukać mniej oczywistych rozwiązań, co według mnie się opłaciło.

      Wiesz perfekcjonizm, o którym piszesz to dość zdradliwa historia. Często spotykam się z historiami pod tytułem: programista zapoznaje się z cudzym kodem i za cholerę nie potrafi podejść do tego obiektywnie. Neguje pewne rozwiązania nie dlatego, że są złe, ale dlatego, że on zrobiłby to inaczej. Ocena cudzego kodu to w pewnym sensie wchodzenie do głowy innego programisty, rozkminianie jego toku myślenia, zastanawianie się dlaczego tak, a nie inaczej coś skonstruował i czy faktycznie jet to błędne. W ten sposób można zrobić cuda nawet z nie swoim kodem. Przykład: aplikacja, szereg modułów do optymalizacji sumarycznie zamknięty w 35 000 linii kodu. Po optymalizacji powstaje Ci z tego 5 000 linii kodu. Powiesz przesada? To zależy :) parę lat temu zacząłem pisać dla klienta prostą aplikację. Miała być mała. 20 modułów na krzyż. Po 3 latach zrobiła się z tego tak wielka kobyła, że nie dawaliśmy rady z kosztami rozwoju. Tzn. dopisywanie kolejnych modułów było tak drogie (czasochłonne), że nieopłacalne. Tak się dzieje, gdy piszesz aplikację na żywca bez planu (bo klient upiera się, że tak chce) i pisząc moduł nie planujesz tego w jakim kierunku się on rozwinie, robisz tylko taką jego formę jakiej aktualnie oczekuje klient. To jest murowana katastrofa.

      Istotnie zawsze jest coś do poprawy, ale mi nie chodzi o perfekcjonizm, a konkretne potrzeby klienta. Dopóki pracuje się na bazach, które mają relatywnie małą ilość wywołań (zapytań) albo mają relatywnie niewielką ilość danych nawet mało wydajny kod jest ok. To zmienia się w sytuacji, w której obsługujesz system realizujący kilkadziesiąt tysięcy zamówień miesięcznie, a to i tak nie jest duża baza. Jeśli w takim systemie wyświetlenie prostej (z pozoru) tabeli dla klienta kończy się koniecznością zestawienia danych z 20 tabel zaczynasz główkować jak tę liczbę zmniejszyć nie obniżając ergonomii.

      Poza tym wiesz :) prosta kalkulacja. Zdjęcie 150 KB. Pracujesz parę godzin i poprawiasz optymalizację tak by bez obniżenia jakości zdjęcie kompresowało się do postaci 140 KB. Ktoś powie: ooo perfekcjonista. A ja powiem. 1 000 000 odwiedzin miesięcznie. 10 KB oszczędności. 10 milionów KB czyli ponad 9,5 GB transferu mniej. Mało? To dotyczy tylko jednego zdjęcia. Zdjęć w serwisie jest np. 500 z czego średnio 50 wyświetlanych jest te 1 mln razy. Co oznacza zysk na transferze na poziomie 476 GB miesięcznie. A to już jest wartość o którą warto powalczyć.

    •  

      pokaż komentarz

      @deathcoder: A czy zatrudniłbyś sam siebie 12 lat temu będąc świadomym swoich ograniczeń? Podejrzewam, że tak, bo błędy, niedoskonałości Twojego kodu byłyby na akceptowalnym poziomie. Mając na mysli perfekcjonizm nie miałem na myśli niechlujstwa i ignorowania zaleceń, ale braku akceptacji swoich ograniczeń. Kiedyś usłyszałem, że jedyną osobą a którą powinienes się porównywać jesteś Ty sam z wczoraj. Głęboko w to wierzę i tak podchodze do wielu rzeczy.
      Wiadomo, że mały błąd może przejawiać później poważne problemy. Czym innym jest jednak akceptacja faktu, że w chwili obecnej takich błędów się nie dostrzega. Na początku trzeba nauczyć się rozwiązywać zadania na wiele sposobów (join, exists, in) a optymalizacja to nie czas na zastanawianie się czy to da się w ogóle zrobić, tylko w jaki sposób to wykonać. A do tego musisz znać funkcjonalności, których możesz uczyć bez kilkunastoletniego doświadczenia.
      Co do książek i samorozwoju. Bardzo ostrożnie podchodzę z tego powodu do wartościowania umiejętności programisty na podstawie stażu pracy. Jeśli ktoś przez 20 lat pracował w jednej firmie to śmiem twierdzić, że osoba, którą ma 10 lat doświadczenia, ale pracowała w 3-4 różnych branżach może mieć większe pojęcie :)
      Oczywiście, bardzo prawdopodobne, że jesteś ode mnie dużo bardziej świadomym i "lepszym" programistą. Nie umniejszałbym tylko innym ze względu na fakt, że mają mniejszy staz pracy. Wszystko zależy jak szybko się uczysz.

    •  

      pokaż komentarz

      @nieinformatyk: Oracle Certified Professional pozdrawia. ( ͡° ͜ʖ ͡°)

    •  

      pokaż komentarz

      @deathcoder: dokładnie jest tak jak napisałeś. Sam kiedyś zajmowałem się tym tematem. I pisałem nieraz od nowa cały kod danej procedury. Bo stary był tak gówniany, że na wygenerowanie raportu dobowego, potrzebował prawie 30 godz.(!!) ( ͡° ͜ʖ ͡°)
      Wszystko przez durne zapytania co chwilę do bazy i łączenie całych tabel przed odfiltrowaniem tylko potrzebnych danych.
      Po któreś tam optymalizacji, mój programik robił ten raport w 15 min. ( ͡° ͜ʖ ͡°)

    •  

      pokaż komentarz

      @deathcoder: Treści statyczne jak ustawienia, waluty, ogólnie konfigi zbierasz z 15 tabel i zapisujesz do pliki configa w katalogu chronionym, później go dolaczasz do skryptu a dane z niego wlaczasz jako stałe zdefiniowane. Pomogłem?

    •  

      pokaż komentarz

      KAŻDY user wchodzący na stronę odpala multum połączeń z bazą

      @deathcoder: To nie do końca tak działa - po pierwsze, nie znam osobiście przypadku gdy 1 użytkownik powoduje uruchomienie więcej niż jednego połączenia do bazy, bo we współczesnych architekturach DI wykorzystuje się singletony.
      Po drugie nie znam przypadku w którym to samo połączenie do bazy, byłoby większym problemem, niż źle napisane zapytanie, lub braki istnienia 3 postaci normalnej.
      Używając narzędzi typu Gatling, raczej spotykaliśmy się z problemami Select N+1, albo innymi fragmentami braku wydajności, ale pierwszy raz słyszę/czytam o problemach ilości połączeń.
      Pliki konfiguracyjne - serio? Przecież bazy powstały między innymi po to, aby poradzić sobie z problemami lockowania plików i zarządzania nimi. Przecież jeżeli naprawdę zależy Ci na skalowalności oraz prędkości, to ładujesz te rzeczy albo do pojedynczej tabeli, albo w jakimś key-value store.
      Nie znam projektu w obszarze Big Data, który zalecałby używanie plików i unikanie baz danych i stosowanie ich "TYLKO" wtedy gdy to konieczne.

    •  

      pokaż komentarz

      @deathcoder: tak czytam twoje komentarze i mam pytanie... jesteś w stanie jakoś potwierdzić swoje 12 lat doświadczenia?

    •  
      RicoW via Android

      0

      pokaż komentarz

      @nieinformatyk Wygląda na to, że oboje macie rację, względem swojej perspektywy.

    •  

      pokaż komentarz

      12 lat to sporo jak na dzisiejszą sytuację

      @nieinformatyk: 12 lat to bardzo malo, jezeli nie znasz ludzi z takim doswiadczeniem to stawiam ze pracujesz w gowno firmie od niczego.

      Obecnie caly czas licze ze spotkam czlowieka z xp 60+ bo goscia ktory ma 50 lat doswiadczenia w branzy juz spotkalem i nawet z nim pracowalem.

    •  

      pokaż komentarz

      jakoś potwierdzić swoje 12 lat doświadczenia?

      @ineedadollar: 12 lat xp maja obecni trzydziestoparolatkowie. To jest raczej obecnie najpopularniejsza ilosc dowiadczenia.

    •  

      pokaż komentarz

      12 lat to bardzo malo

      To jest raczej obecnie najpopularniejsza ilosc dowiadczenia.

      @FortunaHej: No k?%@a rzeczywiście, daj pan jakieś dane potwierdzające twoje mocne słowa, szczególnie to, że 12 lat to najpopularniejsza "ilość" doświadczenia ( ͡° ͜ʖ ͡°)

    •  

      pokaż komentarz

      @deathcoder: I całe Twoje podejście obala popularna dziś architektura mikroserwisów, gdzie baza jest per usługa. Najgorsze co w swojej 10 letniej pracy fullstacka trafiłem to zahardkodowane dict'y (do tego TY namawiasz, mówiąc że tabelka z 20 rekordami jest bez sensu) Zamiast wrzucić do jednej bazy i używać to: 5 różnych API ma 5 różnych dictów w kodzie. Rozjazd utrzymania tego w jednolitej działającej formie jest tak czasochłonne że zatrudnia się 2 extra programistów za 40k brutto zamiast za 2k dostawić do klastra bazodanowego node'ów. :) Punkt widzenia zależy od tego po której jest się stronie developmentu

    •  

      pokaż komentarz

      @nieinformatyk: to prawda, mam ok 20 lat doświadczenia z Oracle, 12 lat doświadczenia z MS SQL i cały czas odnoszę wrażenie, że brak mi wiedzy więc ciągle się uczę :). Szanuję za chęć pomocy innym :)

    •  

      pokaż komentarz

      @leszekwl: nie nadchodzi taki moment, że masz wrażenie, że nic nowego w tej technologii Cię nie zaskoczy i zaczynasz robić coś innego?

    •  

      pokaż komentarz

      @nieinformatyk: Nie nie zatrudniłbym siebie sprzed 12 lat. Wiesz dlaczego? Ponieważ prawda jest taka, że nauka programowania to proces bardzo czasochłonny i pełen błędów popełnianych "po drodze". Przykre realia tego rynku są takie, że na gównianych (niedoświadczonych) programistów trafiają przede wszystkim ludzie z małym zasobem gotówki i wiedzy w zakresie IT. I to jest fajny układ, bo oni dostają gównianą, ale jako tako działającą tanią aplikację, a programista zyskuje możliwość dokształcania się. Nie zmienia to faktu, że dziś kiedy chcę oferować klientom wyłącznie wysokiej jakości produkty nie mogę sobie pozwolić na zatrudnienie kogoś po kim nie da się nawet poprawić, bo błędy wieku że tak to nazwę dziecięcego programistów są tak poważne, że sięgają fundamentów pisanych przez nich aplikacji.

      Kwestie porównywania i to pitolenie mówców motywacyjnych pod tytułem porównuj się tylko ze sobą zostawiam dla tych, którzy nie do końca kumają jak działa rozwój. Rozwój to stawianie sobie celów niemal nieosiągalnych. Ćwiczysz na siłowni, obierasz sobie cel: podnieść 200 kg, ale dziś podnosisz ledwie 120 więc na dzień dzisiejszy cel jest nierealizowalne, ale abstrakcyjne cele dają możliwość błyskawicznego nabywania wiedzy.

      Jeśli weźmiesz pod uwagę to, że ja programistą zostałem tak naprawdę przez przypadek zrozumiesz o czym mówię. Lubię pisać - magiczny realizmu, proza poetycka. Miałem kiedyś bloga jeszcze za czasów serwisu eblog.pl. W pewnym momencie do każdego bloga zaczęli dołączać bardzo nachalne reklamy, których nijak nie dało się wyłączyć. Nauczyłem się programować wyłącznie po to, by stworzyć swój własny blog bez reklam. Na forum.php.pl zadawałem masę pytań, w pewnym momencie zacząłem dyskutować, propoonwać rozwiązania. Pewien gość mający firmę mnie zauważył. Zapytał mnie czy projektuję aplikację zawodowo, a ja na jego maila spojrzałem jak na pytanie idioty, który podchodzi do piekarza i prosi o 10 kg gwoździ :). Ale zaczęliśmy gadać, dostałem pierwsze zlecenie mając jednocześnie w planach wyjazd do UK. To były jeszcze czasy baaaaardzo wysokiego kursu Funta i wyjazd nawet na głupi zmywak był jak żyła złota. Z drugiej strony dostałem się na studia informatyczne we Wrocławiu. Ani jedno ani drugie nie wypaliło. Z wyjazdu do UK zrezygnowałem, bo uznałem, że wygląda na to, iż w PL znajdę dość dochodowe zajęcie, a na studia nie poszedłem, bo szkoda mi było marnować czas, wolałem te wszystkie godziny poświęcić na naukę programowania.

      Nie uważam się za Bóg jeden raczy wiedzieć jak dobrego programistę, ale uważam, że jest to wzorcowy przykład tego jak talent rodzi się sam z siebie w pewnym sensie. Dzięki temu robię dziś to, co lubię, a nie to co sobie zamierzyłem na etapie wyboru kierunku na studiach. :)

      Boli mnie dziś tylko to, że na rynku jest całe mrowie pseudoprogramistów. Znam sporo takich, którzy wiedzą i potrafią więcej niż ja, pracują w technologiach, których ja zupełnie nie kumam, ale przynajmniej wiem, że kiedy coś robię to w ramach technologii, którą się posługuję jestem w stanie zrobić coś naprawdę dobrego. NIE LEPSZEGO od innych, ale na tyle dobrego, by na moich rozwiązaniach firmy mogły opierać cały swój plan biznesowy mając obroty na poziomie kilku milionów zł miesięcznie. To mi wystarczy, by wiedzieć, że dobrze robię to, co robię i że nie muszą mnie ruszać komentarze pod tytułem OOOOOoo ty to powinieneś zająć się nodem itd. Przyglądałem się tej technologii i odpuściłem ze względu na to, że nie jest dostępna na większości serwerów współdzielonych, od których zaczynają małe firmy. Nie chcę pracować w korporacji, bo w cale nie dostanę tam dużo większych pieniędzy niż teraz, a bedę za to poganiany batem, by robić w czymś czego np. nie czuję.

    •  

      pokaż komentarz

      @maque: Nie zrozumiałeś tego, co napisałem mam wrażenie :) SESJA jest jedna, połączeń jest wiele. Każde osobne zapytanie kierowane do bazy nazywam połączeniem, ponieważ serwer PHP potrzebuje czasu na to, by zlecić zpaytanie, poczekać na odpowiedź, przetworzyć to postaci dla siebie zrzumiałej i wypluć do zmiennej. To jest powód, dla którego wykorzystanie triggerów i funkcji MySQL zamiast wykonywania multum zapytań po stronie PHP dramatycznie przyspiesza działanie aplikacji.

      Nie jesteś w stanie za pomocą jakichkolwiek metodologii łączenia się z bazą uzyskać równie krótkiego czasu wykonywania kodu jeśli porównujesz pobieranie danych z bazy vs pobieranie danych z plików konfiguracyjnych. Dostęp do systemu plików jest po prostu szybszy.

      Zrób sobie eksperyment. Odpal sobie gołą kopię Zend Frameworka (np. w 1 odsłonie) bez użycia bazy danych na przeciętnych serwerze współdzielonym, gdzie masz plik konfiguracyjny w formacie JSON zawierający pi razy drzwi 200 ustawień. Drugi plik zawierający 50 tekstów komunikatów, Trzeci plik zawierający treści statyczne. Czwarty plik zawierający treści komunikatów systemowy. Piąty plik, w którym masz ustawienia wykorzystywanych języków. Szósty plik, który zawiera ustawienia walut.

      Wyobrać sobie, że Twoja aplikacja odwołuje się do tych plików w kilkudziesięciu miejscach, jest na tyle złożona, że nie możesz określić dla każdej podstrony jednolitego zestawu ustawień, które mają zostać użyte, w związku z czym w tablicy są wszystkie jak leci.

      I teraz skonstruuj obok tego drugą aplikację, która bezie robiła to samo, ale wszystkie informacje będą pobierane z bazy danych.

      Czas wykonywania skryptu skoczy Ci prawie dwukrotnie. Dlaczego? Bo PHP się z bazą danych nie lubi w znaczeniu takim, że potrzebuje czasu na dogadanie się z nią. Każde zapytanie to osobny proces nawet jeśli jest to wykonywane w ramach jednej sesji z bazą danych, to wywołań bazy danych będziesz miał tu multum.

      Tego rodzjau rozwiązania są powszechnie stosowane między innymi w bardzo dużych aplikacjach mających miliony odsłon. Jest to na tyle daleko posunięte, że cachuje się całe podstrony po to tylko by zupełnie wyeliminować konieczność nie tylko łączenia z bazą, ale renderowania kodu. Masz profil użytkownika, poszczególne jego elementy są cacheowane po to by nie obciążać bazy danych. Stosuje się również serwery lustrzane itd. Całe multum narzędzie całkowicie eliminujących konieczność jakiegokolwiek generowania strony.

      Bo tak na zdrowy chłopski rozum pomyśl. Skoro ustawienia po stronie panelu administracyjnego aktualizujesz parę razy w roku, masz powiedzmy 1 000 000 odwiedzin miesięcznie czyli 12 000 000 odwiedzin rocznie. Jeśli masz dane w bazie każdy użytkownik odświeżając stronę powoduje wykonanie kompletu zapytań. Zatem na 12 000 000 odwiedzin masz powiedzmy średnio dziesięć odsłon na użytkownika. Daje to sumarycznie 120 milionów zapytań, które są kompletnie do niczego niepotrzebne.

      Są oczywiście wbudowane w PHP metody uzyskania takiego cachea ale kontrola nad nim jest prawie zerowa i wymaga dodatkowego nakładu czasu.

      Baza danych z samej swej natury GENIALNIE sprawuje się z obróbką dużych ilości danych, dlatego nie da się cacheować wszystkiego w taki sposób jak to opisuję. I TAK to nie jest popularna opinia :) ja to wiem :) ale testowałem swoje możliwości i nie da się tego obiektywnie przebić, bo baza danych NIGDY nie zwróci Ci tablicy z danymi równie szybko jak zrobi to system plików na dysku - zwłaszcza kiedy jest to SSD. Nie przebijesz tego żadnym rozwiązaniem.

      W moim przypadku wszystkie ustawienia są ZAPISYWANE do bazy danych i z niej pobierane na poziomie panelu admina. Możesz sortować, przeszukiwać itd. ale zewnętrzna część aplikacji z tego nie korzysta. Dlatego, przeciętna strona potrzebuje około 180-190 milisekund na wygenerowanie tego co jest przesyłane do przegląarki, a ja w swoim autorskim CMSie który właśnie kończę zszedłem do poziomu 40-60 ms NA WSPÓŁDZIELONYM serwerze.

      Wiesz co to powoduje? Przeciętny klient korzystający z tego rozwiązania będzie musiał przesiąść się na VPS'a kilka razy później niż przewiduje to norma. To jest dla niego czysty zysk, a raczej obniżenie kosztów funkcjonowania jego firmy.

    •  

      pokaż komentarz

      @maque: Dodam jeszcze, że pisanie wydajnej aplikacji nie jest po to, by Tobie jako programiście było wygodnie i przyjemnie. Bardzo często ergonomię i wydajność przy bardzo dużych aplikacjach stawia się daleko ponad komfortem pracy programisty. Zdarzają się nawet klienci na tyle ogarnięci, że potrafią to zrozumieć i często proszą mnie o pewne rozwiązania, ja im mówię ok mogę to zrobić, będzie szybciej, ALE wdrażanie jakichkolwiek zmian do danego modułu będzie bardziej czasochłonne. Często mimo wyraźnego poinformowania ich o tym decydują się na to.

    •  

      pokaż komentarz

      @Starkwind: Popularna? Pokaż mi który z usługodawców hostingowych oferuje to w wersji wpsółdzielonej, od której zaczyna się większość biznesów. Klientów, którzy od razu startują od serwera dedykowanego jest mało (biorąc pod uwagę ogół klientów). Fajna technologia ale niestety póki co jeszcze bardzo niszowa.

    •  

      pokaż komentarz

      @szopa123 optymalizacja swoje, ale czy na pewno dane z tabeli nie trafiły po pierwszej feralnej próbie do ramu i dzięki temu było szybciej?

    •  

      pokaż komentarz

      @FortunaHej: Nie jest to mało. 12 lat oznacza, że taki programista sięga czasów Internet Explorera w wersji 6, czyli czasów, w których CSSa do danej aplikacji pisalo się 3 razy pod Explorera, pod Firefoxa i pod Operę osobno, a wiele problemów obchodziło się wytrychami.

      Nie oznacza to, że programowanie zaczęło się 10-15 lat temu, ale oznacza to, że w praktyce 10-15 lat temu zaczęły dopiero rodzić się współczesne technologie. W tamtych czasach PHP nie można było nawet nazwać w pełni obiektowym językiem programowania, a jakiś czas później MySQL było porzucane na rzecz PostgreSQL ze względu na wydajność.

      W praktyce ktoś kto ma 10-15 lat w zakresie projektowania aplikacji webowych przebrnął przez niemal całą historię tej dziedziny informatyki.

    •  

      pokaż komentarz

      @ineedadollar: Jasne, że tak, pytanie tylko po co? Chcesz możemy sobie pogadać o tym jak Internet Explorer w wersji 6 (czyli właśnie 12 lat temu) sprawiał, że pisząc aplikację internetową k?$#owało się na lewo i prawo. Mając obok Firefoxa i Operę, które całkiem nieźle radziły sobie ze standardami Internet Explorer był kulą u nogi, któa zatrzymywała całą branże w miejscu.

      Ja miałem taką zasadę, że w umowach z klientami podawałem, że zobowiązuję się dosotsować porpawne wyświetlanie aplikacji do najpopularnieszych przeglądarek stanowiących powyżęh 5% statystycznych użytkowników według GEMIUSa. Wyobraź sobie szczęsliwość na mojej twarzy kiedy po raz pierwszy zobaczyłem, że IE6 ma mniej niż 5%.

      Choć i tak nie było różowo :) bo IE 7 ze swoją pieprzoną zgodnością wstecz w cale nie był szczególnie lepszy, ale już dawał większe pole manewru.

      Możemy sobie pogadać o PHP w wersji 4 który trudno było nazwać obiektowym językiem programowania, o np. bardzo innowacyjnej jak na tamte czasy usłudze KEI.PL - oferowali bardzo ciekawą formę partnerstwa. Kupowałeś duży hosting i odsprzedawałeś go fragmentarycznie swoim klientom.

      Możemy też pogadać o programowaniu obiektowym, którego za cholerę nie potrafiłem zrozumieć do momentu, w którym przyszło mi napisać pierwszą dużą aplikację :)

      Możemy też pogadać o moim wujku, który był wydawcą jednej z pierwszych książek o DOSie w Polsce :)

      Zaczynałem od Windowsa 3.11 :) DSJ na dosa wymiatało :) oooojjj :)

    •  

      pokaż komentarz

      że każda aktualizacja choćby ustawień powinna oczywiście nadpisywać rekordy w bazie, ale powinna też aktualizować stosowne pliki konfiguracyjne i to z nich powinna korzystać część kliencka

      @deathcoder: Tu się zgodzę, gdy ruch wzrasta to pojawia się wiele ciekawych zagadnień z wydajnością i wtedy autor aplikacji zmuszony jest do optymalizacji. Praktycznie każdy kto stworzył aplikację/stronę, która zrobiła się popularna, spotyka się z tym tematem. Co do kwestii jak to najlepiej robić - dyskusji się nie podejmuję. Dla mnie wystarcza gdy zrobione jest to czytelnie i dobrze działa.

      Niemniej jednak korzystając z okazji że taki temat pojawił się w rozmowie wspomnę, że dziś praktycznie każdy popularny framework oferuje co najmniej kilka sposobów na zmieszczanienie zapytań do bazy danych a nawet zmniejszenie ilości odczytów plików, które są potrzebne do złożenia strony. Tutaj znowu na temat czy robić to samemu czy korzystać z framework'a - dyskusji się nie podejmuje. Najważniejsze gdy programista robi swoje dobrze i czytelnie.

      A na zakończenie już tak bardzo technicznie na podstawie framework'a Django. W szybkiej pamięci podręcznej możemy przechowywać widoki (czyli np rezultaty zapytań do bazy danych, rezultaty działania pętli itp), całe szablony lub fragmenty szablonów, czy ręcznie wybrane pojedyncze dane. Ta pamięć podręczna może być realizowana na kilka sposobów. W bazie danych (czasami ma to sens), w pliku (to rozwiązanie podobne do stosowanego przez kolegę) oraz w pamięci RAM (bardzo szybko).

      W ten sposób niektóre strony możemy trzymać w całości w pamięci RAM i odświeżać je tylko co X minut, inne w 90% trzymać w pamięci RAM a jedynie 10% ich budować na podstawie bazy danych (np belka górna z zalogowanym użytkownikiem) itp. Dalej,... można tworzyć dedykowane serwery do mechanizmów realizujących cache, do treści statycznych (czyli np plików z obrazkami - odciążając serwer główny)... fajny temat :) Kolega to z pewnością wie, uhh a ja się rozpisałem ale jak już, to wkleję jeszcze link'a do opisu mechanizmów Django (inne framework'i mają podobnie), może się ktoś zainspiruje: http://docs.djangoproject.com/en/2.1/topics/cache/
      http://rk.edu.pl/pl/przyklad-keszowania-w-django-memcached-i-megiteam/
      Co do tematu - używać framework'a czy robić wszystko we własnym zakresie, do dnia dzisiejszego nie mam jednoznacznego przekonania. Widzę zalety obu podejść. Gdy dobrze znamy framework to możemy pisać świetne aplikacje ale to się dotyczy również dobrej znajomości czystego języka i wypracowania sprawnych metod.

      I tak na koniec, znacie jakieś sensowne tłumaczenie słowa "framework"? Uśmiałem się jak ktoś zaproponował "ramo-szkielet" (。◕‿‿◕。)

    •  

      pokaż komentarz

      ponieważ serwer PHP

      @deathcoder: A kto pisał o PHP i MySQL? SQL nie ogranicza się do tych dwóch technologii. Argumentacja na podstawie tego jak działa pod spodem PHP w stosunku do wykorzystania baz danych jako takich, zupełnie mnie nie przekonuje.

      Nie jesteś w stanie za pomocą jakichkolwiek metodologii łączenia się z bazą uzyskać równie krótkiego czasu wykonywania kodu jeśli porównujesz pobieranie danych z bazy vs pobieranie danych z plików konfiguracyjnych

      Nope. Istnieją takie technologie jak connection pool. Że nie wspomnę o cache zapytań i ich wyników na poziomie bazy danych vs odczyt z pliku. O bazach klastrowanych i LB nawet nie będę się tu rozpisywał.
      Nie słyszałem też aby ktokolwiek w Big Data porzucał HBase na rzecz zwykłego HDFS i trzymania tam danych timeseries.

      Ponadto wspomniałem, że można użyć rozwiązań key-value. Jeżeli potrzebujesz szybkiego wyciągania danych konfiguracyjnych, to wrzucasz je do redisa, albo nawet do Azure table storage.

      Baza danych z samej swej natury GENIALNIE sprawuje się z obróbką dużych ilości danych

      Wydaje mi się że zapominasz o pojeciach "cold storage" i "hot storage"

      bo baza danych NIGDY nie zwróci Ci tablicy z danymi równie szybko jak zrobi to system plików na dysku - zwłaszcza kiedy jest to SSD. Nie przebijesz tego żadnym rozwiązaniem

      Baza danych to jest system plków (at the end of the day). Zależy od danych. Jeżeli zwracasz to co jest, tak jak jest - czyli musisz zwrócić dokładnie taką samą ilość wyników, bez filtrowania, wyszukiwania, łączenia... Ale to nie jest ten case, bo przecież chodzi o zwracanie konkretnej ilości danych. Jak masz miliard danych liczbowych, a potrzebujesz zwrócić 1000 na podstawie różnych filtrów, to raczej na zwyklych plikach wydajnosci bazy danych nie osiagniesz (zakładając dane relacyjne).

      Wspomnę jeszcze tylko o tym artykule http://www.troyhunt.com/i-wanna-go-fast-why-searching-through-500m-pwned-passwords-is-so-quick/ - tak, można przyspieszyć pobieranie danych przerzucając się na pliki (które są wciąż pobierane poprzez połączenie z serwerem plików) ale Troy zrobił to tylko dlatego, że jego dane nie zmieniają się często (np, co pół roku) i nie są relacyjne (jeden hash, jeden wynik). Patrząc na rozwiązanie AT, jakichś strasznych problemów z performance nie miał.

      A na koniec najważniejsze - baza danych daje Ci model, który możesz wersjonować, śledzić, testować. Na poziomie kilkuosobowego zespołu i wdrażania różnych zmian, brak takiego modelu to po prostu masakra jeżeli chodzi o wdrażanie, testy, o code review nie wspominając.

    •  

      pokaż komentarz

      @deathcoder: nie wiem gdzie pracujesz, ale w "moim świecie" nikt nie zajmuje się projektowaniem modelu danych i jego optymalizacją dłużej niż jest to potrzebne.
      Albo wogóle się go robi.
      5 minut, 2h, może i tydzień albo dwa.
      To, że Twoje zapytanie zadziała optymalnie przy 200K rekordów a jeszcze lepiej przy 200mln naprawdę nie jest istotne.
      Aplikację należy "dowieźć". Ma działać nawet wolno i w miarę bez błędów. Potem się można bawić w optymalizację, zmiany modelu etc.
      W dobie bigdata, mikroserwisów i load balancerów czy vm-ek, które można powołać do życia w minuty, jakaś rzeźba modelu miesiącami i zapytań do tego to kamień łupany i kompletna strata pieniędzy.
      Znam mnóstwo systemów gdzie nawet indeksy zakłada się po wdrożeniu produkcyjnym.

    •  

      pokaż komentarz

      @deathcoder: Jak już większość napisała, pracujemy w zupełnie innych projektach i firmach wszyscy moi znajomi programiści tak samo. Nikt nie będzie zajmował się optymalizacją zapytań na początku. Problemy sukcesu rozwiązuje się jak jest sukces. Wcześniej jest to bez sensu. A często problem sukcesu rozwiązuje się za pomocą load balancera z kilkoma instancjami aplikacji, a nie za pomocą optymalizacji SQL'a po prostu ta pierwsza rzecz jest szybsza i tańsza w realizacji. Podniosłeś też problem że początkujące startupy nie mają dedyków. Ja wychodzę z założenia, że jeśli kogoś nie stać zapłacić 2-3 tys. zł miesięcznie za serwer to tym bardziej nie stać go na programistę z doświadczeniem

    •  

      pokaż komentarz

      @fujiyama: Nie tworzysz tego miesiącami :) jeśli masz programistę, który tworzy spore ilości aplikacji wystarczy stworzyć szkielet :) podam Ci to na prostym przykładzie :) niemal wszystkie moduły w serwisach webowych mają po stronie panelu admina tabelę. Tabela z użytkownikami, administratorami, treściami, ustawieniami, walutami, językami i czym tam jeszcze. Każdy typ danych to tabela. Tabela = sortowanie / stronicowanie itd.

      Na przestrzeni lat zorientowałem się na przykład, że niezwykle często zdarza się, że klient chce moduł x i ja w praktyce mam gotowy podobny moduł, mogę go wykorzystać, ale większość czasu zajmuje mi jego konfigurowanie, a potem podczas testów jakieś ilości czasu poświęca się na jego dopieszczenie - klient mówi, że chce żeby taka a taka kolumna była wyświetlana itd. Najbardziej czasochłonne były do tego wyszukiwarki, gdzie przy bardzo skomplikowanym module ich stworzenie zajmowało czasem sporo czasu, no bo masz formularz wyszukiwania, fragment kodu który waliduje ich poprawność, inny fragment który przetwarza je na zapytania jeszcze inni który module samą zawartość formualrza (opcje w selektorach itd.)

      No i mając gotowy moduł i tak musiałem kupę czasu spędzać nad konfigurowaniem moduły. W rezultacie zrobiłem coś, co sprawia, że niemal każdy moduł służący do zarządzania danymi z określonej tabeli tworzę w godzinę / półtorej. Taki moduł ma mozliwość stornicowania sortowania, wskazywania aktywnych kolumn i ich kolejności, przeszukiwania, wykonywania globalnych operacji itd.

      Stworzyłem klasę JS oraz kilka klas PHP, które działają tak, że po stronie klasy PHP definiujesz za pomocąszeregu metod jakie kolumny zawiera tabela, a reszta dzieje się sama. Klasa JS na podstawie przyjętych danych umożliwia wyświetlenie tabeli, udostępnia stronicowanie i sortowanie po każdej z kolumn, udostępnia wyszukiwarkę podstawową, zaawansowaną i nagłówkową, pozwala na wybranie (przez użytkownika) aktywnych kolumn oraz ich kolejności, pozwala na multisortowanie (sortowanie po wielu kolumnach), zaznaczanie rekordów wraz z ich zapamiętywaniem po przejściu na następną stronę i wykonywania na nich globalnych operacji, daje możliwość tworzenia szablonów widoków (ustawiasz sobie aktywne kolumny sortowanie i kryteria wyszukiwania a następnie zapisujesz to jako widok predefiniowany). KAŻDA z tych opcji jest konfigurowalna, samo stronicowanie może być wyświetlane pod tabelą, nad tabelą, w kilku formach, pełnej, rozszerzonej itd. czyli możesz włącząć wyłączać opcję wyboru ilości rekordów na stronie itd. Jeśli do tego dodasz funkcjonalność edycji rekordów z poziomu tabeli robi Ci się z tego kombajn. Jest na tyle konfigurowalny że możesz za pomocą tego modułu wyświetlić prostą nieaktywną tabelę gołą jako nagłówek + rekordy, jak również potwora do zarządzania wynikami wypluwanymi przez join kilku tabel.

      Na podstawie tej klasy PHPowej, która definiuje zestaw kolumn i ich włąściwości inna klasa PHP tworzy formularz wraz z walidacją. Inna klasa PHPowa na tej podstawie generuje cały proces aktualizacji / usuwania / dodawania rekordów.

      W praktyce moja rola w tej chwili sprowadza się do zadeklarowania zestawu danych + skonfigurowania domyślnych ustawień tabeli.

      Dodaj do tego jeszcze fakt, iż ten system obsługujący tabel ma wbudowany moduł eksportu importu danych i to w na tyle zaawansowanej postaci, że eksportując dane sam decydujesz jakie kolumny i w jakiej kolejności, a importując również określasz do czego maja być poszczególne kolumny przypinane.

      Jeśli weźmiesz dodatkowo pod uwagę fakt, że tabela podczas wyszukiwania czy sortowania / przechodzenia na inną stronę nie odśiweża strony tylko komunikuje się z serwerem poprzez AJAXa i pobeira dane za pomocą JSON, rezultat jest taki, że mam prosty moduł, który obsłuży nawet najbardziej złożone dane w bazie i pozwoli je w niesamowicie ergonomiczny sposób prezentować użytkownikowi, a jednocześnie ma bardzo duża wydajność, bo nawet przy kilku milionach rekordów na serwerze współdzielonym daje sobie radę.

      To co stworzyłem pokazuje, że wielu klientów zupełnie niepotrzebnie płaci za serwery VPS lub dedykowane. PO CO płacić 2000 zł miesięcznie za serwer skoro można za te 2000 zł wyjechać na wycieczkę zagraniczną np.?

      To nie jest kwestia tego czy klienta stać na serwer za 2000 miesięczie, czy nie. Pytanie brzmi PO CO ma go kupować skoro może mieć programistę, który pozwoli mu tego uniknąć? Ja wiem, że nowe technologie są fajne, wiem, że znajdzie się tu wielu, którzy wiedzą więcej niż ja, bedą rzucać pojęciami, z którymi nie miałem nawet kontaktu.

      Przypomina mi się tu pewna sytuacja na niemieckiej autostradzie :) zapierniczam 170 swoją starą skodą Fabią z 2001 roku. Zadowolony, że daje radę. Wyprzedzają mnie sportowe Porshe, Audi, samoróbki i inne takie. I w pewnym momencie widzę jak jedno z nich wyprzedza mnie i zjeżdżą na prawy pas, a następnie za nim wyskakuje stara Łada z mocą pod maską rzędu 2-3 krotnie większą niż ten który mnie wyprzedził.

    •  

      pokaż komentarz

      @fujiyama: @fujiyama: Uważam, że programista, który perfekcyjnie zna swoje środowisko jest w stanie napisać bardziej wydajną aplikację niż programista znający najnowsze technologie który twierdzi: to ma tylko działać, niech się klient martwi.

      Co więcej ja nie mówię o tym, że programista ma każdy kod pisać idealnie. Dobry programista to taki który potrafi sobie stworzyć narzędzia umożliwiające jednym rzutem tworzenie wydajnej aplikacji. Jeśli masz coś do tworzenia formularzy, tabel, wyszukiwarek, podstron tekstowych co działa PERFEKCYJNIE obsłużysz tym niemal każdą aplikację internetową.

      Tu nie chodzi o dyskusję na temat tego kto jest lepszym programistą i ktra technologia jest lepsza. Chodzi o dyskusję o tym, czy jako programista masz czas na to by olać klientów mając PEWNOŚĆ, że ich aplikacje działają rewelacyjnie i wyjechać na tydzień na wakacje :) czy nie dasz się temu zawodowi zjeść, a o to bardzo łatwo. Znam wielu programistów, który gonią za nowinkami technologicznymi, a ja się ich pytam: kiedy ostatnio realnie odpoczywali... a no nie pamiętają nawet.

    •  

      pokaż komentarz

      @deathcoder: "KAŻDY user wchodzący na stronę odpala multum połączeń z bazą" a to dlaczego?, mam w sofcie jedno otwarte połączenie, to skąd multum do bazy? Na serwerze też widze jedno połączenie od tej instancji.

      "baza kolejkuje zadania im więcej jest użytkowników tym bardziej spowalnia cała infrastruktura." niby dlaczego? Wszystko zależy, co tam się dzieje, jak jest pełno odczytów to leci z cache. Do tego serwer używa wszystkich rdzeni cpu. Poza tym przy odpowiednim dozowaniu tranzakcji i zapytaniach blokuje sie wąskie obszary.

      "każda aktualizacja choćby ustawień powinna oczywiście nadpisywać rekordy w bazie, ale powinna też aktualizować stosowne pliki konfiguracyjne" jakie pliki konfiguracyjne?

  •  

    pokaż komentarz

    Które standardy SQL zamierzasz pokryć?

  •  

    pokaż komentarz

    Kolejny "kurs" programowania w formie wideo. Zakop. Po prostu NIE.

    •  

      pokaż komentarz

      @S0Cool: W jakiej formie życzyłbyś sobie kursu? Blog?

    •  

      pokaż komentarz

      @nieinformatyk Dowolny tekst pisany. Nauka programowania (zresztą jakakolwiek nauka) wymaga skupienia uwagi. To nie to samo co oglądanie wesołego kitku. Jeśli temat jest nowy i trudny, w tekście wystarczy wrócić wzrokiem kilka linijek wstecz. Na filmie trzeba kliknąć wstecz na pasku odtwarzania - i nigdy nie trafić. Żeby się przyjrzeć kodowi, trzeba pauzować. Twórca zdecydował, że trzy sekundy mi wystarczą i koniec. A pomyślałeś o możliwości kopiowania kodu? Z wideo? A w przypadku tematu łatwego przelecę po artykule wzrokiem w kilkanaście sekund wyłapując to co ewentualnie jest warte uważnego przeczytania. Oszczędzam mnóstwo czasu.
      Ja wiem, że łatwiej zarobić na YT, ale przytoczone powyżej różnice dyskwalifikują wideo jako formę nauki programowania. Oczywiście są dziedziny, gdzie YT się sprawdza. I to nawet w dziedzinach ścisłych np. kanał numberphile. Ale zwróć uwagę, że to jest opowieść o ciekawostkach, a nie nauka czym się różni SELECT od UPDATE.

    •  

      pokaż komentarz

      @S0Cool: akurat dużo łatwiej napisać artykuł niż nagrać video. Czasochłonność tworzenia kursu w formie filmików przynajmniej w moim przypadku jest dużo większa. Trzeba zrobić plan odcinka, nagrać ekran, potem głos, potem złożyć to w całość. Pracuje właśnie nad blogiem :)

    •  

      pokaż komentarz

      @nieinformatyk O tym nie pisałem. Tylko o tym, że na YT łatwiej zarobić :)

    •  

      pokaż komentarz

      @S0Cool: aa to sorka, niedoczytałem. Ku Twojemu zadowoleniu na razie nic nie zarabiam, nie mam żadnych reklam na kursie :)

    •  

      pokaż komentarz

      @nieinformatyk Ależ ja Ci życzę jak najlepiej. Zarabiaj na czym chcesz. I nie mam nic przeciwko zarabianiu na YT. Tylko jestem zdania, że łatwość nakręcenia filmiku i zarobienia na reklamach powoduje, że coraz więcej treści powstaje w formie filmów, nawet te, które się do tego nie nadają. Po prostu ja nie uczę się z filmów bo to nie działa. I dałem temu wyraz. Ale może ja jestem starej daty. A raczej na pewno jestem. Mój certyfikat z MSSQL jest starszy niż Youtube.

    •  

      pokaż komentarz

      @S0Cool: Dzięki Twojemu kometarzowi, widze większy sens tworzenia bloga. Dotychczas tego nie zauważałem, bo ja zdecydowanie wole video, jeśli zaczynam się czegoś uczyć. Co innego nauka trudniejszych zagadnień, wtedy liczą się konkrety, resztę sam sobie doczytam. Pozdrawiam.

    •  

      pokaż komentarz

      @nieinformatyk: Osobiście mam takie same odczucia jak @S0Cool: Do nauki - tylko artykuły. A video ma swoje plusy jak chcesz sobie przypomnieć coś co już umiesz albo po prostu spędzić czas odrobinę bardziej produktywnie, niż na portalu ze śmiesznymi obrazkami, ale nie na tyle żeby nabyć jakąś nową, konkretną wiedzę ( ͡° ͜ʖ ͡°)

When You Should Spend the Holidays with Your Ex — and When You Shouldn't | Watch movie | BMW Emblem 82mm Haube Logo für Vorne Hinten Motorhaube Heckklappe Kofferraum