Mam moralnego kaca. Programuję od blisko 7 lat, pisałem wiele przedziwnych rzeczy - jedne wymagały wydajności, inne modułowości. Programowanie obiektowe daje niesamowite możliwości, mało kto wyobraża sobie bez niego współczesne systemy. Wszystko jednak mam wrażenie idzie w stronę gorszą niż Java - wzorce projektowe idą w kierunku wszędobylskich obiektów. O ile teoria "wszystko jest obiektem" brzmi pięknie to już jej realizacja w sposób wydajny jest prawdę mówiąc niemożliwa.
Doskonały przykład zbędnego overheadu stanowią proste gettery i settery zawierajace w swoim ciele wyłączenie return/przypisanie do prywatnego pola klasy. Chroni to wyłączenie przed podaniem złego typu argumentu ale wprowadza dość spory narzut w przypadku konstrukcji wywoływanych tysiące razy. A właściwie po co one powstają? No tak, co by progrmistę (!) ochronić przed wysypaniem kodu... no do cholery, czy nawet tutaj trzeba prowadzić za rączkę?
Do czego to do cholery zmierza? Chyba do hello world napisanego w 11 klasach (bo przecież każdy znak powinien mieć swój obiekt!).
Problem z Magento i wieloma innymi serwisami tkwi w tym, że to nie są projekty budowane przez jednego programistę który pracuje tylko na swoim komputerze lokalnie i na serwerze live. Przy dużych serwisach pracuje przynajmniej kilku programistów i każda zmiana potencjalnie może ubić serwer na którym działa sklep który w ciągu minuty odwiedza setki uzytkowników. Ten overhead ma na celu takie zabezpieczenie aplikacji, żeby przez zupełny przypadek programista nie wygenerował strat na setki tysięcy (dowolnej waluty).
Twój przykład z utworzeniem tabelki w bazie i prostym zapytaniem. Oczywiście, prościej ją utworzyć w bazie w phpMyAdminie, wrzucić zapytanie do widoku i działa. Ale normalnie to zrobisz to na serwrze lokalnym -> póżniej musisz to przenieść na instancję deweloperską (tworzenie nowej tabelki w PMA na serwerze deweloperskim) -> później na instancję testową (tworzenie nowej tabelki w PMA na kolejnym serwerze) -> póżniej na live (tworzenie nowej tabelki na serwerze live). Ok, jeśli to Ty jesteś jedyną programistką w projekcie i element jest zaakceptowany przez klienta natychmiast po jego utworzeniu. Ale co jeśli to inny programista zrobi merge twojej gałęzi z serwerem live i nie będzie wiedział o tabelce? Wysypie stronę :D Albo klient zaakceptuje tę rzecz po miesiącu, a Ty już nie będziesz pamiętała, że trzeba jeszcze utworzyć
Miało być o Pasie Planetoid między Marsem a Jowiszem, ale wyszło, że wpis będzie o punktach libracyjnych, zwanych też punktami Lagrange'a.
Jest to bardziej fizyka niż czysta astronomia i ciekawostki, ale pozwala nam to na wyjaśnienie kilku zjawisk, takich jak np. Trojańczycy goniący Greków. Czym więc jest ten punkt Lagrange'a (wolę tę nazwę niż punkt libracyjny)?
Wyobraź sobie satelitę geostacjonarnego. Zapewne wiesz co to jest. Satelita, który znajduje się stale nad jednym punktem na naszej planecie. Satelity GSM, telewizyjne i wiele innych korzystają właśnie z dobrodziejstw tej orbity. To teraz wyobraź sobie satelitę badawczego. Nasz mały kolega został wysłany z ważną misją obserwacji Słońca, a imię mu nadali SOHO. Został on wysłany na orbitę okołosłoneczną (czyli już nie okrąża Ziemi, a naszą gwiazdę). Ale chwila, chwila... Skoro okrąża Słońce to w jaki sposób nie jest nigdy przez nie zakrywany? Przecież znajduje się na innej orbicie, a jak mówi nam trzecie prawo Keplera (trochę matematyki teraz): T1^2/a1^3=T2^2/a2^3, czyli, ułamek złożony z czasu obiegu ciała wokół Słońca (T) i jego średniej odległość od Słońca (a) [oczywiście w odpowiednich potęgach], dla dwóch różnych ciał jest zawsze taki sam. Więc, jeśli ciało posiada inną orbitę, to musi też poruszać się po niej z inną prędkością. Oznaczałoby to, że albo Ziemia będzie szybsza od satelity, albo satelita od Ziemi. Niezależnie od wyniku, będzie musiał nastąpić moment, kiedy Słońce stanie między naszym dzielnym kolegą, a centrum dowodzenia u nas (obraz literowy: SOHO-------SŁOŃCE---------ZIEMIA -> jak widać Słońce zasłania nam widoczność). A nie możemy sobie na to
Chciałbyś zacząć przygodę z programowanie, ale nie wiesz jaki język programowania wybrać? Ten wpisy jest dla Ciebie.
Nie słuchajcie ludzi, którzy mówią, że język X jest lepszy. To nie jest i nie może być prawdą. Języki zwykle mają bardzo konkretne zastosowania i w nich są niezastąpione. Fakt, że C++ jest szybszy nie ma znaczenia, jeżeli chcemy napisać stronę internetową.
Moskwa. Zima. Śnieg. Chłopczyk rzuca śnieżkami. Nagle - brzęk tłuczonego szkła. Wybiega stróż, prawdziwy stróż - o surowej minie, z miotłą i goni chłopca. Chłopiec ucieka przed nim i myśli:
- Po co? Po co mi to wszystko? Po co mi ten cały image dziecka ulicy, te śnieżki, ci koledzy... Po co? Przecież odrobiłem już wszystkie lekcje i mógłbym leżeć w domu na łóżku i czytać książkę mego ulubionego pisarza - Ernesta Hemingwaya...
Hawana. Ernest Hemingway siedzi w swym pokoju, w ogromnej willi, dopisuje ostatnie zdanie kolejnego romansu i myśli:
@NapalInTheMorning: No ja się nie chwalę. Rozbawił mnie dowcip, bo zwykle te wrzucane tutaj znam i są słabe, ale przyznaję, że dwie z tych postaci są mi obce. Zaplusowałem, ale nie chciałem tym samym sprawiać wrażenia, że sądzę "ho ho ho, wybitny kawał, bo są intelektualiści i tłuszcza nie zrozumie xD". Podejrzewam, że nikogo to nie obchodzi, ale miałem potrzebę rozgrzeszyć się przed samym sobą.
To uczucie, gdy mój stary kod dali do refaktoryzacji jakiemuś studentowi z PWR W-8 xD Kod tak bardzo #!$%@?, a rok pracy też tak bardzo #!$%@? xD Żałuję trochę, bo spoko interfejsy miałem rozplanowane a studenty go #!$%@?ły przypadkiem, bo nie wiedzieli co to SOLID xD Śmiecham, bo szef płacze, a ja zamknąłem SourceTree i przeglądam mirko, a studenci dostają #!$%@?, a ja se siedzę przed kompem i #!$%@? jestem architektem oprogramowania
Doskonały przykład zbędnego overheadu stanowią proste gettery i settery zawierajace w swoim ciele wyłączenie return/przypisanie do prywatnego pola klasy. Chroni to wyłączenie przed podaniem złego typu argumentu ale wprowadza dość spory narzut w przypadku konstrukcji wywoływanych tysiące razy. A właściwie po co one powstają? No tak, co by progrmistę (!) ochronić przed wysypaniem kodu... no do cholery, czy nawet tutaj trzeba prowadzić za rączkę?
Do czego to do cholery zmierza? Chyba do hello world napisanego w 11 klasach (bo przecież każdy znak powinien mieć swój obiekt!).
Ehh...
Problem z Magento i wieloma innymi serwisami tkwi w tym, że to nie są projekty budowane przez jednego programistę który pracuje tylko na swoim komputerze lokalnie i na serwerze live. Przy dużych serwisach pracuje przynajmniej kilku programistów i każda zmiana potencjalnie może ubić serwer na którym działa sklep który w ciągu minuty odwiedza setki uzytkowników. Ten overhead ma na celu takie zabezpieczenie aplikacji, żeby przez zupełny przypadek programista nie wygenerował strat na setki tysięcy (dowolnej waluty).
Twój przykład z utworzeniem tabelki w bazie i prostym zapytaniem. Oczywiście, prościej ją utworzyć w bazie w phpMyAdminie, wrzucić zapytanie do widoku i działa. Ale normalnie to zrobisz to na serwrze lokalnym -> póżniej musisz to przenieść na instancję deweloperską (tworzenie nowej tabelki w PMA na serwerze deweloperskim) -> później na instancję testową (tworzenie nowej tabelki w PMA na kolejnym serwerze) -> póżniej na live (tworzenie nowej tabelki na serwerze live). Ok, jeśli to Ty jesteś jedyną programistką w projekcie i element jest zaakceptowany przez klienta natychmiast po jego utworzeniu. Ale co jeśli to inny programista zrobi merge twojej gałęzi z serwerem live i nie będzie wiedział o tabelce? Wysypie stronę :D Albo klient zaakceptuje tę rzecz po miesiącu, a Ty już nie będziesz pamiętała, że trzeba jeszcze utworzyć