Wstęp do programowania zorientowanego obiektowo w PHP5…
- Dodano: 19 października 2008
- Wprowadził: nightmo
- Komentarze: 45
Choć temat można w różnych formach napotkać na różnych serwisach, tym razem spotkacie się z wersją indywidualną, przedstawiającą podstawy OOP w języku PHP. Pomijając opisanie głównych pojęć i pobocznych terminologii tego zakresu, znajdziecie tu także skrupulatny opis całej problematyki oraz teoretyczne przykłady.
Każdy kto dotychczas miał jakiś podstawowy kontakt z PHP i chciałby poszerzyć swoją wiedzę o aspekty obiektowego programowania w piątej odsłonie tego języka jest tutaj bardzo mile widziany. Słyszane przez Was dotychczas wyrażenia, czy zwroty staną się po tym artykule zrozumiałe. Obiekt? Metoda? Kapsułkowanie? Właściwości statyczne? To tylko część aspektów z którymi się tutaj zapoznasz. A wszystko to przez proste, ale zarazem skrupulatne tłumaczenie zmuszające czytelnika do przeanalizowania tego co czyta i wypróbowania swojej wiedzy w praktyczny sposób. Masz wolny wieczór? Zrób sobie kawę, wejdź, odpal jakiś edytor przeznaczony do tworzenia kodu i spędź miło kilka chwil z nowym dla siebie zagadnieniem…
Więcej informacji: http://m1chu.eu/webmastering/wstep-do-pr...owo-w-php5
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
45 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
kapsułkowanie? a co to jest?
ja słyszałem tylko o enkapsulacji.
Enkapsulacja to z kolei jakiś koszmarek językowy. Kolejny dowód na to, żeby pojęcia infromatyczne zostawić do tłumaczenia nie-informatykom :>
Kapsułkowanie to mi się kojarzy z pakietami i przesyłaniem danych w sieci
Enkapsulacja to jest koszmarek, choć jako słowo brzmi nawet znośnie. Częściej jednak używa się pojęcia hermetyzacji.
Sam artykuł jest w miarę, choć według mnie za dużo kodu, a nieco za mało teorii (tak!), no i trochę nie nadaje się na newsa. No i to PHP, jakby nie było ;P
a slyszales moze o kwerendach/zapytaniach? albo o widokach/perspektywach?
w przypadku informatyki w polsce w wielu przypadkach na danym terenie/uczelni uzywa sie danych sformulowan…
Kapsułkowanie to synonim enkapsulacji. Nie bądźmy aż takimi purystami językowi (skrajności są "beee"!
)
boze, co za belkot! kapsulkowanie, metody i wlasciowsci "statyczne". bla bla bla. co ma w ogole wspolnego klasa z programowaniem obiektowym, poza tym, ze wystepuje w kilku popularnych jezykach oop? o_O
Mam wrażenie, że chciałbyś coś dopowiedzieć, ale tego nie zrobiłeś.
Hermetyzacja, klasy (niezależnie od tego, w jaki sposób je definiujemy) – a co za tym idzie dziedziczenie, polimorfizm, abstrakcje – to filary OOP.
Pewnie, wiele razy się słyszy programowanie zorientowane obiektowo != programowanie obiektowe ale osobiście uważam, że to drugie nie ma sensu bez tego pierwszego.
Lubię krytykę. Konstruktywną. Ale takżę tą opartą na "jestem zajebisty, a ty lamo nic nie umiesz" – czyli bez rzeczowych argumentów (bo można się z niej pośmiać). Hermetyzacja, czy dziedziczenie to jedne z cech charakteryzujących obiektowość języków programowania. Podobnie jak obiekt jest ich podstawą, a grupy obiektów tworzą klasy. Z resztą już genobis ładnie opisał o co chodzi. Nie jestem teoretykiem, więc żadnych wykładów nie będę tu dalej robił.
Proszę Cię tylko, jeśli masz się w podobny sposób ośmieszać (rzucając takimi cynicznymi tekstami bez podparcia swoich tez), albo nie wiesz o co chodzi to nie pisz lepiej nic.
Sorry, jako odpowiedź dla softa miałbyć poprzedni post.
nieprawda. oop to dekompozycja problemu na "obiekty" i ich interakcje. w ujeciu imperatywnym obiekty to nosniki stanu programu, a te "interakcje" to sekwencje operacji przeksztalcajacych stan.
hermetyzacja czy enkapsulacja, to istotne skladowe modularyzacji oprogramowania, ktora nie ma kompletnie nic wspolnego z obiektowoscia. jesli "klasa" czy typ jest podstawowa jednostka modularyzacji w danym jezyku (jak to ma miejsce np. w php5), to moze to wygaldac jakby jedno mialo zwiazek z drugim. a nie ma. przyklad: clos (obiektowy system common lispa) nie ma enkapsulacji, mimo iz _jest_ rozpoznawany jako jeden z jezykow obiektowych. z kolei formy hermetyzacji posiadaja ada, czy modula, ktore z kolei obiektowe nie sa… (no, ada 95 juz jest). hermetyzacja to cecha modularyzacji, albo szczegol implementacyjny konkretnego jezyka obiektowego. to nie cecha obiektowosci per se.
klasy to jedna z mozliwych realizacji obiektowosci. ale swietnie radza sobie bez niego typowo obiektowe jezyki jak self, cecil, newtonscript czy generalnie programowanie obiektowe oparte na prototypach – chocby w jezykach takich jak javascript, czy lua (w oparciu o tablice asocjacyjne i domkniecia). co za tym idzie dokladnie w takim samym stopniu dziedziczenie ma niewielki zwiazek z programowaniem obiektowym. dziedziczenie jest jedna z mozliwych i dostepnych w obiektowych jezykach programowania metod specjalizacji i reuzywanai kodu. innymi moze byc klonowanie i modyfikowanie prototypow, dynamicznie definiowane role jak w niektorych obiektowych bazach danych i pewnie inne tez (nie znam wszystkich jezykow…).
i generalnie kazdy z twoich "filarow" to cechy implementacji konkretnych jezykow obiektowych wywodzacych sie z simuli. obiektowosc w jezykach nawiazujacych do smalltalka wyglada nieco inaczej. w eiffelu jeszcze nieco inaczej. w objective camlu jeszcze inaczej… programowanie obiektowe to nieco wiecej, niz ucza na prostych kursach programowania w wyzszych szkolach gotowania jaj na twardo…
WoW, widzę, że teorię dotyczącą obiektowości poszczególnych języków masz gdzieś w notatkach. Gdybyś zakuł to na blachę to byłbyś świetnym wykładowcom na AGH – tam takich uwielbiają. Tylko moje teorie się liczą, tylko nazewnictwo którego ja używam jest poprawne. Wszyscy inni mogą się wypchać. Proponuję zacząć robić karierę naukową na jakimś uniwerku – szybko będziesz sławny.
serdecznie wspolczuje wykladowcom z agh studentow, ktorzy maja problemy ze zrozumieniem 4 akapitow tekstu…
o matko! naprawde nie dociera do ciebie, ze to nie jest kwestia nazewnictwa? naprawde niczego nie zrozumiales z powyzszej wypowiedzi? nazewnictwo to kwestia wtorna. nazwij sobie hermetyzacje jak ci sie podoba, chocby "buziaczkowanie"… istotne jest to, ze hermetyzacja, dziedziczenie itp. wynalazki nie sa cechami programowania obiektowego. sa jedynie cechami kilku popularnych jezykow.
Cóż, tym razem Twój komentarz jest bardziej merytoryczny, tym niemniej nie wiem, czy mam ochotę prowadzić dyskusję w tym tonie. Jednak (w miarę) krótko odpowiem.
Z większością wymienionych przez Ciebie języków nie pracowałem, jednak np. JavaScript zdążyłem w pewnym stopniu poznać i… co z tego, że formalnie nie ma klas, jeśli tę samą funkcjonalność można uzyskać za pomocą nawet wspomnianych przez Ciebie prototypów. I, wyobraź sobie, dziedziczenie i hermetyzacja TEŻ są jak najbardziej dostępne. Oczywiście nie jest to w JS specjalnie wygodne, dlatego też wszystko wskazuje na to, że przyszłe wersje JS będą również obsługiwały klasy jako takie (składnia upodobni się nieco do Javy, czy raczej ActionScriptu).
Akurat reuzywanei kodu osiągane jest przede wszystkim przez zastosowanie kompozycji, wzorców projektowych, itd. a dziedziczenie jedynie pozwala na ich użycie (i nie jest na to jedynym sposobem).
Ogólnie mylisz pojęcia, hermetyzacja i enkapsulacja to to samo, a ich zasadnicze znaczenie nie polega na "modularyzacji", ale na wydzieleniu i ukryciu zmienności implementacji. Wreszcie – to o czym piszę, to nie cechy implementacji konkretnych jezykow obiektowych lecz właśnie coś co jest, lub powinno być od języka niezależne i dostępne dla każdego współczesnego języka OOP. Może właśnie to, że brakuje tego wymienionym przez Ciebie językom (choć jeśli znasz je tak jak JS, to też nie musi być prawdą) sprawia, że są używane raczej w specyficznych zastosowaniach.
Co, masz jakieś kompleksy?
programowanie obiektowe jest mozliwe nie tylko w jezykach do tego projektowanych, ale w niemal kazdym jezyku. czasem jest mniej, lub bardziej meczace, ale nadal pozostaje moliwe. czyste c nie jest jezykiem obiektowym, ale przyklad glib/gobject pokazuje ze "jednak da sie".
podobnie jest z forthem, podobnie jest z … assemblerem.
@genobis:
Częściowo zgoda. Ale co ma wspólnego hermetyzacja (ukrywanie implementacji jak wyjaśniłeś) z paradygmatem obiektowym? Nadal nic. Czyli nie zbiłeś argumentu.
Paradygmat obiektowy polega na tym, że program jest rozumiany jako zbiór obiektów (obiekt = stan + zachowanie) wchodzących ze sobą w interakcje. Koniec. Taka jest __ogólnie przyjęta definicja__ i nie mąć.
A dziedziczenie? Ot, jedna z opcjonalnych cech języków OOP, a nie żaden filar OOP. W języku zorientowanym obiektowo można pisać programy czysto proceduralnie wykorzystując dziedziczenie. I nie są przez to z automatu "obiektowe" (zresztą jak większość skryptów PHP czy frameworków MVC do PHP). BTW. SPICE i VHDL są szeroko używanymi językami obiektowymi, nie posiadającymi dziedziczenia.
"programowanie obiektowe jest mozliwe nie tylko w jezykach do tego projektowanych, ale w niemal kazdym jezyku. czasem jest mniej, lub bardziej meczace, ale nadal pozostaje moliwe. czyste c nie jest jezykiem obiektowym, ale przyklad glib/gobject pokazuje ze “jednak da sie”."
Zobacz jak wygląda VFS w Linuksie i powiedz, że to nie jest programowanie obiektowe.
to nie jest ta sama funkcjonalnosc. ta funkcjonalnosc jest podzbiorem i szczegolnym przypadkiem funkcjonalnosci wynikajacej z zastosowania prototypow.
sorry, nie ma klasy – nie ma dziedzieczenia. fakt ze cos na pierwszy rzut oka przypomina dziedziczenie, albo w praktyce pozwala uzyskac efekt m.in. jak dziedzieczenie, nie zmienia faktu, ze z punktu widzenia semantyki jezyka nie jest dziedzieczeniem. w tym jezyku nie mozna zbudowac grafu czy drzewa relacji generalizacja-specjalizacja na typach:
- obiekty skopiowane z prototypu maja wlasciwosci typowe dla prototypu.
- zmodyfikowane obiekty skopiowane z prototypu mozna od biedy uznac za jego specjalizacje.
- kopie tych obiektow moga zachowywac czesc wlasciwosji prototypu.
- problem polega na tym, ze ten prototyp mozna zmodyfikowac, ale jego zmienione wlasciowosci nie "przenosza sie" magicznie na obiekty potomne.
nie zachodzi zatem relacja dziedziczenia…
do obiektowosci i programowania obiektowego mozna podchodzic w rozny sposob. jednym z nich jest model pochodzacy z simuli, innym z selfa. proby programowania w jednym, w sposob, w jaki programuje w drugim, czesto sie udaja. tylko ze sa bez sensu…
nie, to ty mylisz. hermetyzacja jest elementem modularyzacji. a ty przyzwyczailes sie, ze w popularnych jezykach programowania klasa jest jedna z jednostek, lub podstawowa jednostka modularyzacji programu. byc moze tak jest fajnie, albo byc moze tak powinno byc. co nie czyni z hermetyzacji magicznie filaru obiektowosci. hermetyzacja, podobnie jak np. polimorfizm jest kwestia calkiem do obiektowosci ortogonalna…
Myślę, że po prostu piszemy o trochę różnych rzeczach
Pewnie, na poziomie języka jako takiego może nie być dziedziczenia, hermetyzacji, itd. Skoro jednak efekty te są do uzyskania i można je w ten sposób wykorzystywać… cóż, Ty twierdzisz, że w takiej sytuacji nie można ich nazywać dziedziczeniem i hermetyzacją, ja z kolei jestem zdania, że można sobie na to pozwolić (nawet jeśli nimi fizycznie nie są). Tutaj się nie zgadzamy, jednak jest to już raczej właśnie kwestia nazewnictwa.
Pewnie, mogą się z tym wiązać pewne problemy (wspomniana przez Ciebie modyfikacja prototypu), ale jeśli ktoś decyduje się pracować w takim modelu, czy też z jego elementami… cóż, dość rzec, że przy programowaniu i tak dobrze wiedzieć, co się pisze
Ty uważasz, że próby przeniesienia jednego modelu (czy jego elementów) do drugiego są bez sensu, ja jestem zdania, że jeśli jest to dobrze użyte, może dać fajne efekty.
To prawda, przyzwyczaiłem się, że w popularnych językach programowania klasa jest jedną z ważniejszych jednostek modularyzacji programu. News/artykuł jest na temat PHP5, który na tym właśnie modelu się opiera, więc uważam, że odniesienie się do niego było jak najbardziej na miejscu. Potraktowałem go trochę jako "jedyny słuszny", powiedzmy, że to mój błąd. Jednak jest on na tyle elastyczny, że jego elementy mogą być z dobrym skutkiem zastosowane również poza nim. Z mojej strony koniec dyskusji, co prawda ciekawej, ale w sumie niewiele wnoszącej do tego akurat tematu.
Pozdrawiam
Z mojej strony koniec tematu także (pomimo, że w większości byłem biernym "słuchaczem"). Jest pytanie, jest odpowiedź – nastawiona na zagadnienie poruszane w tym artykule. Bez skrupulatnych analiz całej problematyki programowania obiektowego, które już bez wnikania mniej lub bardziej poprawnie starałeś się teoretycznie zaprezentować. Chwała Ci za to, pomimo Twoich zgryźliwości (charakteru się nie wybiera, ale można go kreować – tak jakbyś nie wiedział ;]).
Nie próbuj mi proszę wmawiać, że na podstawie tego co napisałem nie potrafię czytać ze zrozumieniem, pomimo że względnie trudno czyta się tekst z sprzecznościami (bynajmniej nie dlatego, że użyłeś kilku pozornie niebanalnych słów, ale przez dyskretne zaprzeczenia z których możliwe, że nawet nie zdajesz sobie sprawy) ;]
Nie mniej jednak pozdrawiam i życzę miłego wieczoru.
PS: ten post nie ma być formą ataku i nie świadczy o tym, że się z Tobą nie zgadzam (w sporej części tego co napisałeś). Bardziej jest przykładem skromnej walki z nadgorliwością względem poruszanego problemu ;D
Jakbym słyszał wykładowce od OOP z AGH "jest wiele tłumaczeń i definicji, ale obowiązują moje". Jakie to ma znaczenie? Jeśli gość pisze poprawnie kod, tylko używa mniej popularnych tłumaczeń, to jego sprawa. Who cares? Napisał ciekawy artykuł, ale państwo czepialscy oczywiście muszą zacząć wytykać jakieś mało znaczące błędy w tłumaczeniach angielskich wyrazów. Przeanalizujcie kod i wytknijcie błędy jakie autor w nim popełnił – no chyba, że nie potraficie, bo cienkie bolki potrafią się doczepić tylko do tłumaczeń…
Dzięki za miłe słowa. Taka z reguły Polaków mentalność, żeby zbluzgać. Na szczęście nie wszystkich. A jeśli już ktoś chce coś zrobić, to niech to robi próbując pomóc – argumentując i pokazując co można zrobić lepiej. Nikt nie jest doskonały (i każdy popełnia błędy), ani ja, ani Wy i chętnie czy to tu, czy to u siebie w komentarzach poczytam o Waszych konstruktywnych propozycjach.
"Jedynie chamstwa nie zniosę" hahaha
No dobrze. Ale dlaczego z osnews robi się od pewnego czasu drugi wykop? Jak dla mnie ten art to spam który w dodatku powiela treść której jest na pęczki. Mam nawet na biurku wydrukowany identyczny w treści art z webinside sprzed jakichś 2 lat. Jak już chcesz coś napisać to chociaż wstawiłbyś tutaj całą treść na x licencji.
Jest takie stare powiedzenie "nie chcesz, nie czytaj". Poki co nie ma na OSnews zalewu 100 newsow na godzine, takze jesli kilka takich tekstow zostanie dodanych to naprawde nikomu korona z glowy nie spadnie.
Ivo nie ma tu ani jednego zdania skopiowanego z Webinside. Proszę pokaż mi ten art, który jest identyczny z tym co napisałem. To, że wybrałem taką, a nie inną kolejność opisywania podstaw tego zagadnienia nie znaczy, że je skąś skopiowałem. Niektóre informację, których kiedyś tam uczyłem się korzystając z innych serwisów mogą być podobne. Ale to tylko pewne pozostałości w moim umyśle z tego co nabyłem, nic więcej. Więc proszę mnie nie oskarżać o plagiat, bo tekst pisałem sam.
Wykorzystanie programowania obiektowego w języku takim jak PHP, gdzie skrypt obsługuje żądanie, kończy się i wszystko zapomina, jest dość sztuczne i "na siłę". Poza szpanem "programuję obiektowo w PHP, jestem cool" nic to nie wnosi. A w rzeczywistości to jest programowanie strukturalne, w którym pierwszy argument wywołania funkcji jest przed kropką zamiast za nawiasem.
Nie zgodzę się. Nie jestem fanem PHP, jednak możliwość programowania obiektowego jest trudna do przecenienia nawet przy małych projektach. Pewnie, że w modelu żądanie-odpowiedź trudno mówić o pełnym wykorzystaniu obiektowości, jednak wiele jej cech świetnie się sprawdza w PHP.
O jakiej kropce mówisz?
w malych projektach w php to nie jest programowanie obiektowe, tylko strukturalne, z uzyciem klas jako jednostek modularyzacji kodu. owszem, w php to jest lepsze niz brak modularyzacji, jednak nie czyni kodu obiektowym.
pewnie o strzalce…
Pomyłka, miało być '->'.
Ale jakie zalety wynikające z obiektowości?
Bo ja widzę głównie zalety wynikające z hermetyzacji tudzież paru innych fajnych, choć w PHP nieco spartaczonych mechanizmów jak np. rzucanie wyjątków. Próby pisania w sposób obiektowy kończą się koszmarnym spadkiem wydajności (ciągłe tworzenie wszystkich obiektów przy każdym żądaniu – zupełnie bez sensu). Szczególnie, że wykonywanie kodu w PHP jest dosyć powolne w porównaniu z innymi językami, tak gdzieś 50x-100x wolniej niż kompilowane.
Jak chcesz pisać obiektowo i mieć sensowną wydajność, to jedyny w miarę sensowny wybór to Java lub .NET.
Wiem, dlatego pracuję w Javie
Jak pisałem wyżej, miłośnik PHP ze mnie żaden, tym niemniej czasem zachodzi konieczność jego użycia i wówczas wolę obiektowość, tudzież "obiektowość" PHP5. Powody? Właśnie te wymienione już przez was, czyli głównie modularyzacja kodu + wyjątki. Że spartaczone – może i tak, ale lepszy wróbel w garści…
I tak właśnie wygląda mój kod w PHP, szablony, struktury danych jako obiekty, kilka klas narzędziowych (dostęp do bazy danych, sesja) i możliwie krótki kod strukturalny który tym zawiaduje.
Spadek wydajności jest, ale PHP i tak jest całkiem szybkie, jak na to jakie… jest.
Wydajność i JAVA? Wydajność i platforma .NET? W pierwszym nie piszę, ale miałem okazję używać kilku programów pisanych w niej – może miałem pecha, ale te akurat były cholernie toporne. A .NET sam w sobie pomimo, że z wersji na wersję jest lepiej/dynamiczniej rozwijany to nadal aplikacje w nim pisane są "ciężkie". I w żadnym wypadku nie próbuję tutaj dowieść wyższości PHP. Po prostu wypadałoby nie rzucać tylko teoretycznymi, "mądrymi" frazesami, a popatrzeć jak to z praktycznego punktu widzenia wygląda (ze strony użytkownika).
nightmo, cała dyskusja jest na temat aplikacji internetowych (czy tam intranetowych), działających po stronie serwera. Zgadzasz się z tym czy nie, te technologie są bardzo potężne.
A ślamazarność Javy to stereotyp, z którym nawet nie chce mi się dyskutować. JVM długo wstaje i ma apetyt na pamięć, a Swing jest trochę przymulasty, co nie znaczy, że Java jako taka jest mało wydajna. Szczególnie, na dobrym serwerze (albo i w klastrze).
A to sorry genobis. Można się tu ciut pogubić, zważając na to, że odniosłem się sam w tamcie do OOP w PHP5, a nastała tu wielka wrzawa w odniesieniu do nastu języków. Nie wiadomo po co. My fault
@soft – mądrze piszesz, ale nie jedz więcej chipsów nad klawiaturą.
"Masz wolny wieczór? Zrób sobie kawę, wejdź, odpal jakiś edytor przeznaczony do tworzenia kodu i spędź miło kilka chwil z nowym dla siebie zagadnieniem…"
Matko, jaki normalny człowiek mając wieczór wolny od pracy (zapewne pracy przed komputerem) chce "spędzić miło kilka chwil" z PHP zamiast iśc na spacer z dziewczyną / skoczyć z kumplami na piwo / zrobić cokolwiek konstruktywnego?
Myślę, że całkiem sporo.
Nie wiem czy do końca normalnych.
No i niekoniecznie z PHP.
Ale Django rządzi
to rozumiem ze kolejna wersja osnews juz nie bedzie na wordpressie
michuk: skoro juz mowa o wolnych wieczorach i programowaniu objektowym, to moze bys wzial sie z zona za hmmm… programowanie klas potomnych, dziedziczacych po rodzicach, jak i po prototypach tych klas
a nie tylko pieprzenie i pieprzenie o linuksach, ołpensorsach i tego tam
jak bedziesz mial zapracowana zone, dziecko w wieku szkolnym, kumpli ktorzy po dwoch piwach zaczynaja biadolic o swoim ostatnim rozwodzie (kredycie, pogrzebie matki…), to docenisz urok wieczoru spedzonego samotnie przed klawiatura komputera…
Lepiej być nienormalnym.
"Matko, jaki normalny człowiek mając wieczór wolny od pracy (zapewne pracy przed komputerem) chce “spędzić miło kilka chwil” z PHP zamiast iśc na spacer z dziewczyną / skoczyć z kumplami na piwo / zrobić cokolwiek konstruktywnego? "
Coz moze byc bardziej konstruktywnego niz wieczor poswiecony na autosamorozwoj wlasny?
To nie rozwój własny, ale bycie homo informaticus. Larwa pozbawiona mięśni (bo albo śpi albo siedzi przed kompem), bez zainteresowań, bez horyzontów wychodzących poza komputery. Sam często preferuję wypoczynek przed kompem, ale 1) nie zawsze 2) nie uważam tego za najwyższą (a na pewnie nie za jedyna) formę samodoskanalenia.
Dziewczyna i kumple od piwa jako jedyna alternatywa dla kompa. To chyba najlepiej obrazuje horyzonty homo informaticusów. Sport, muzykowanie (jeśli jest odrobina talentu), rysowanie (jeśli jest odrobina talentu), matematyka i łamigłówki (jeśli jest odrobina talentu) turystyka, działalność społeczna, języki obce,…
Syndrom homo informaticusa najpiękniej objawił się podczas dysksji na temat laptopów w szkole. Dla HI rzecz się sprowadziła do obaw jaki tam będzie system i jakie standardy będą wspierane, bo samą ideę laptopa uznał za bezdyskujnie słuszą! Ludzie, nie chcę nikogo pouczać, ani obrażać, ale jak czasem czytam niektóre (NIEKTÓRE) posty, to mam wrażenie, ze nie piszą ich prawdziwi fachowcy, a autystyczne maniaki z tyłkiem przyspawanym do krzesła.
Rysowanie – czemu nie? Gimpy / Photoshopy w dłoń i do roboty.
Nie każdy wieczór spędza się z dziewczyną, czy z kumplami na piciu. Niekiedy trzeba zrobić coś innego ;] Choć niekoniecznie musi to być PHP… każdy robi co lubi
No, można np. spędzić wieczór pijąc z dziewczyną.
big league register you’ve pick up