Witam! Temat moze troche dziwny, ale siedze juz 2 dni i kminie co moglbym napisac... Chodzi mi o jakis spory projekt, zebym mogl nowa wiedze teoretyczna sprawdzic w praktyce. Skonczylem wlasnie tutrial Xiona:
http://xion.org.pl/productions/texts/coding/megatutorial/
Macie jakies pomysly co moglbym napisac? Moze to byc tez program sieciowy bo winsocka z grubsza ogarniam, winapi. Teraz zainteresowalem sie seria filmikow "reversecraft" + assemblerem ale chyba na to za wczesnie. Dzieki z gory :)
Napisz prosty serwer www. Jak skończysz, to zawsze będziesz mógł go rozbudować żeby nie był prosty.
OK, moze jeszcze jakies propozycje? Projekt moze byc trudny, na miesiac-2miesiace kodzenia(z moimi umiejetnosciami ;p) najwiecej dałoby sie przy nim nauczyc.
A może zamiast jednego projektu zrobić dużo małych? Mylnie zakładasz, że zrobienie czegoś dużego daje duże doświadczenie. Prawda jest taka, że często wyrabia się przy tym złe nawyki.
Lepiej np. wejdź na spoj.pl i zacznij rozwiązywać kolejne problemy. Możesz nawet ten sam problem rozwiązać na kilka sposobów: całkowicie obiektowo (aż do przesady), proceduralnie, z jak największym użyciem funkcji bibliotecznych albo z jak najmniejszym. Na duże projekty przyjdzie czas. Jeszcze Ci przyjdzie no głowy dziwny pomysł na zrobienie programu do grafiki, pochwalisz się na forum i Cię wszyscy wyśmieją. Były już takie sytuacje ;)
Na 2 miesiace to nie jest, raczej na kilka dni ale:
Aplikację klient-serwer pozwalajacą na zdalne korzystanie z shella w modelu n:m (tzn uruchamiasz demony na N komputerach a potem możesz do części tych demonów podłączyć się za pomocą M aplikacji klienckich i wywoływać jakieś komendy shella i odbierać ich wyniki). Rocket science to oczywiście nie jest (wystarczą sockety + wątki + jakieś exec()/popen()), ale można coś ciekawego zrobić.
Hmm: klient poczty umożliwiający wysyłanie wiadomości na adresy zawarte w pliku *txt + załączniki..
Zrób jakiś prosty Continuous Integration dla programów w C++ pod GCC, z komunikacją poprzez wymyślony przez siebie protokół oparty na Protocol Buffers od Google'a.
Co do spoja, troche sie bawilem - glownie w łatwych. No propozycji mam sporo, zaraz je przemysle i ew poprosze o jakies wskazowki na poczatek ;p
edit
@Wibowit niestety nie mam pojecia co to w ogole jest, jak to dziala, a i google niewiele mowi.
@mto9 Pomysl niezly w sumie, tylko to bedzie chyba za maly projekt.
@Shalom Ciekawa propozycja ;). Czyli np odpalam serwery na 2 kompach a z 10 innych moge podlaczyc sie do nich i kazdy z tych 10 komputerow moze wywolywac komendy shella nawet na tym samym kompie? Pytam bo tak to zrozumialem ;p
Okej, dostalem pare ciekawych propozycji ale dobrego nigdy za wiele :) Pozdro
Karolaq napisał(a)
A może zamiast jednego projektu zrobić dużo małych? Mylnie zakładasz, że zrobienie czegoś dużego daje duże doświadczenie. Prawda jest taka, że często wyrabia się przy tym złe nawyki.
To ostatnie stwierdzenie mi się nie podoba, choć nie jestem pewien, czy jestem w stanie je formalnie obalić. Pomysł z całkiem małymi zadankami takimi jak SPOJ też mi się nie bardzo podoba, tj. je też można sobie robić, ale one dają coś innego niż większy, praktyczny projekt "prawdziwej aplikacji".
Złe nawyki... A czy mniejsze projekty ich nie wyrabiają? Może to jest tak, że na uczelni kodujemy małe rzeczy, gdzie olewanie zasad jak DRY czy SRP/reszta SOLID aż tak bardzo nie daje się we znaki. Jeśli kod ma kilkaset linii, to zła architektura i metoda Copy'ego & Pasta jeszcze nas nie paraliżują.
Nawet o tych niewielkich fragmentach kodu można powiedzieć, że są złe, ale dopiero gdy piszemy coś (relatywnie) większego stosując te same, złe zasady co w małych projektach, dotyka nas prawdziwa tragedia. W teoretycznie końcowym etapie kodowania, dodawanie nowych funkcjonalności idzie nam koszmarnie wolno, nie możemy się połapać we własnym kodzie i większość czasu zżera nam naprawianie bugów i ogarnianie tego wszystkiego. A mówię tu o pierwszych "większych projektach", tj. np. takich na kilka tysięcy linii kodu! Co z prawdziwymi aplikacjami, które mają grube dziesiątki czy setki tysięcy linii (lub więcej)?
Nie powiedziałbym, że pisanie dużych aplikacji uczy złych nawyków. Raczej: uwidacznia złe nawyki, które wynieśliśmy z mniejszych programików.
Znamy to powiedzonko: "człowiek uczy się na błędach". OK, może i się troszeczkę uczy, ale... lepiej uczy się na sukcesach. Sukces daje więcej informacji niż porażka. Porażka mówi tylko, że coś zrobiliśmy źle. Rzadziej: co zrobiliśmy źle. Jeszcze rzadziej: jak to poprawić. To nie tak, że w aplikacji na tysiące linii popełnimy jeden błąd projektowy, bo wybraliśmy A zamiast B. Wtedy na drugi raz moglibyśmy wybrać B i byłoby git, ale w praktyce może są jeszcze alternatywy C, D...X, a może błąd jest zupełnie gdzie indziej.
Dlatego napisanie gównianego kodu na parę tysięcy linii też nam niewiele daje.
Co byłoby moim zdaniem cenniejsze?
Napisanie nieco większego kodu niż ten mały, choć może nie takiego, o jakim wcześniej myśleliśmy. I skupienie się na jakości. Na sprawieniu, by nasz kod był przyzwoity. Nie musi być idealny, ale niech będzie niezły.
Można sobie kupić książkę "Refaktoryzacja" Martina Fowlera. Albo "Czysty kod" Roberta C. Martina. Albo "Kod doskonały" Steve'a McConella. Przeczytać i spróbować zastosować jak najwięcej zasad do naszego kodu. Użyć testów jednostkowych. Koniecznie systemu kontroli wersji ( ;) ). Planować kod. Refaktoryzować, funkcja po funkcji, klasa po klasie, a nie zaczynać pisać całą aplikację od nowa.
Tego na studiach ludzie uczą się chyba najmniej, a -- jak na ironię -- umiejętność utrzymywania jakości kodu w praktyce jest być może najważniejszą cechą profesjonalnego programisty (jakość to też poprawność, ale nie tylko).
Ja na studiach i tak jeszcze należałem niby do osób zainteresowanych inżynierią oprogramowania (mającą zapewnić jakość kodu), ale do końca nie rozumiałem jej wagi. Jeśli czegoś żałuję to tego, że dopiero po studiach kupiłem w/w książki (i wiele innych) i zacząłem naprawdę dbać o jakość mojego kodu.
Może to dobry pomysł na projekt? W ten sposób można pisać praktycznie dowolną aplikację. Ja radzę, by skupić się na jakości.
Aha: co do tego, czy lepiej pokazać potencjalnemu pracodawcy większą aplikację, czy małe rzeczy np. ze SPOJ-a, to zgadzam się z tym, że lepiej większą. Ale gdy mi pokazują swoje projekty, zawsze jestem bardzo zainteresowany tym, jak wygląda sam kod. Obecność np. testów jednostkowych -- w miarę przyzwoitych -- byłaby sporym plusem. Podobnie jak np. średnia długość funkcji bliska 5 linijkom, a nie 50.
Hej!
Ja bardzo chętnie Ci podpowiem co nieco bo widzę, iż niektóre osoby mają odmienne zdanie ort! mojego. Nie ma w tym absolutnie nic złego, ale dzięki temu będziesz mógł porównać obie strony medalu.
Szczególnie ort! się do posta autorstwa Karolaq, gdyż pisał on o mnie w zdaniu:
"Jeszcze Ci przyjdzie no głowy dziwny pomysł na zrobienie programu do grafiki, pochwalisz się na forum i Cię wszyscy wyśmieją. Były już takie sytuacje ".
O tym chwilkę później pomówimy.
Napisałeś, że ukończyłeś tutorial. Tak naprawdę to bardzo mało, aczkolwiek jeśli opanowałeś większość ważnych elementów jak np. obsługa listy lub stosu, opanowałeś programowanie obiektowe na sensownym poziomie oraz widzisz pewne zalety (ale także wady) wzorców projektowych, wiesz co to UML oraz wiesz jak rozpisać sobie projekt na kartce lub w programie do tego przeznaczonym to śmiało możesz pisać duży projekt. No właśnie pytanie podstawowe: "Czy nie za wcześnie?".
NIE. Ludzie mają tendencję do bania się. Boją się pokazać to co zrobili, boją się, że nie dadzą rady, boją się, że zajmie im to dużo czasu, boją się, że przejdzie im zapał, boją się odpowiedzialności.
To jest absolutnie normalne, ja np. zawsze przed nowym projektem (i zawsze staram się by projekt był duży, a dlaczego o tym pomówimy później) czuję lęk. Ktoś mądry jednak powiedział kiedyś, że programiście najtrudniej jest zacząć. Później już się leci jak z górki, mimo, że na każdym kroku można napotkać problemy. To jest absolutna prawda, gdy już programista się przełamie to bez problemu ruszy dalej. I to będą piękne chwile - zaręczam.
Dlaczego staram się by projekt był duży?
To jest kwestia dwuczłonowa. Nie jestem super doświadczonym programistą, więc pewnie starsi trochę mnie poprawią. Zapewne będą też tacy co absolutnie wyśmieją ort! sposób. Ich problem, ja uważam go za prawidłowy i zresztą nie tylko ja, ale także autorzy książek dotyczących tematyki programowania.
Kwestia dwuczłonowa - co przez to rozumiem?
Przed każdym dużym projektem należy rozbić go na diagramach UML oraz na pewnych wykresach. Ułatwia to bardzo całą sprawę mimo, że początkujący mają tendencję do ignorowania UML-i i innych pomocy. Ja również to ignorowałem jeszcze kilka lat temu.
W tym momencie wyjdzie na jaw, co ort! projekt ma do zaoferowania i jakie trudności napotkamy podczas jego tworzenia. W tym momencie przechodzimy do - jak to ja nazywam - pierwszego ort! projektu. Piszemy po prostu snippety (małe kawałki kodu wykonujące określoną czynność). W ten sposób udowodnimy sobie, że newralgiczny i trudny element projektu potrafimy wykonać. Robimy tak, ponieważ bez tego w trakcie kodzenia może okazać się, że po 4 miesiącach prac nie umiemy ruszyć dalej. Pisząc mały kawałek kodu przed rozpoczęciem sensownej pracy będziemy posiadali małą ściągę i ewentualną pomoc, która nie raz uratuje z opresji. Naprawdę to bardzo ważne i bez tego nie warto pisać nic dużego bo prędzej czy później napotkamy ciężar, którego nie da się przeskoczyć tak łatwo.
Po napisaniu snippetów (zazwyczaj ich nie jest, aż tak dużo - każdy duży projekt, albo średni posiada zazwyczaj tylko kilka trudnych elementów) można przejść do realizacji zadania i po prostu pisać program. Technik pisania jest tyle, że nie ma sensu wymieniać ich ani jakiejś sensownej zalecać. Tym bardziej, że zaraz znajdą się wyznawcy czegoś innego i się zacznie "rozmowa".
No właśnie, ale skoro tak to wygląda to czemu user Karolaq napisał ostrzegając Cię:
Jeszcze Ci przyjdzie no głowy dziwny pomysł na zrobienie programu do grafiki, pochwalisz się na forum i Cię wszyscy wyśmieją. Były już takie sytuacje
To o mnie chodzi, gdyż jestem autorem oprogramowania photoMake 2.0. Program ów był pisany przeze mnie oraz na <ort>bieŻąco (Boże, widzisz takie błędy i nie grzmisz)</ort> podawane były informacje o nim na forum (jakie są funkcje, jakie mamy możliwości w nim itd.)
Po ukończeniu prac umieściłem program na razie tylko na forum. O matko Boska... co to się działo. Jeden przez drugiego wymyślał coraz to lepsze odzywki, oraz teksty. Najczęściej nie miały one:
a.) nic wspólnego z programem
b.) były typowym hejtowaniem, które nie miało na celu polepszenie mojej działalności, a jedynie wyśmianie jej i polepszenie samopoczucia pewnego nieudacznika.
Z tego też powodu ludzie NIEZMIERNIE boją się pokazać swoją pracę bo boją sie wyśmiania. Zastanów się jednak i pomyśl: skoro Ty czujesz, że program jest fajny i dobrze zrobiony to czemu ktoś miałby Cię wyśmiać? Odpowiedź jest prosta - bo Cię nie lubi i jest zazdrosny, że Ty umiesz się zabrać do pracy i zrobić coś o czym on może tylko pomarzyć.
Mocne słowa prawda? Taka jest jednak prawda i uświadomiły mi to pewne osoby w momencie, gdy program ujrzał szerszą publikę. A osoby owe były zarówno grafikami jak i programistami.
Pisząc program musisz przygotować się na to, że nie spodoba się on co najmniej 25% ludzi, którzy go zobaczą. To jest takie minimum, które ja sam sobie zawsze wyliczam i nim się absolutnie nie martwię. Skąd akurat 25?
To wynika z różnych obserwacji zarówno mojej pracy jak i innych. Zawsze znajdzie się ktoś kto będzie chciał pobluzgać i dowartościować się. Popatrz na forum onetu. Wypowiadają się tam istni idioci, jeden przez drugiego przekrzykuje się i wyzywa, miesza często politykę w sprawy totalnie z nią nie związane.
Należy zrozumieć, że w sieci jest mnóstwo osób, które w życiu prywatnym są po prostu nieudacznikami, albo nic sensownego nie osiągnęli mimo, że bardzo by tego chcieli. To nie jest żadna fikcja, tylko prawda. Mnóstwo ludzi w sieci w ten sposób próbuje zwrócić na siebie uwagę tylko dlatego, że w życiu nie mają okazji tego zrobić. Ich wiedza lub wygląd zewnętrzny nie sprzyjają zabłyśnięciu i osoby takie stają się w sieci zupełnie kimś innym.
Po czym poznać takiego hejtera?
Przede wszystkim działa strasznie na nerwy :) Pewien facet o nicku Rock powiedział, że jeden hejter potrafi zepsuć tak humor, że 100 przyjaciół go nie poprawi. Z tym trzeba sobie radzić - po prostu nie przejmować się.
Hejterzy to nie osoby wymieniające wady oprogramowania itd. To osoby, które piszą często z przekleństwami kompletnie coś co ma Ciebie zdenerwować, a nie ma sensu. Np: "Weź się schowaj z tym programem". Bywają takie np opinie o napisanym oprogramowaniu. Nie ma w tym zdaniu ani krzty krytyki, jest tylko obraza i brak argumentów. Tym charakteryzują się hejterzy.
jak sobie z nimi radzić?
Na forum 4programmers sobie z nimi nie poradzisz, gdyż to forum ma możliwość pisania przez niezalogowanych gości (między innymi dlatego na tym forum już mnie nie ma, a jedynie wypowiadam się w tym topciu i o piractwie). Na każdym innym forum po prostu blokuj danego użytkownika. Tyle w temacie - po co ma Cię wkurzać i irytować skoro nic nie wnosi do tematu? Taka osoba <ort>niechce</ort> by Twoje dzieło stało się lepsze tylko chce zepsuć Ci humor, poprawiając swój w ten sposób.
Taki wampir trochę.
Blokować hejterów i tyle. Nie ma sensu wysłuchiwać i patrzeć na to jak ktoś robi z siebie idiotę. Tym bardziej, że takie posty mieszają sie pomiędzy postami sensownymi, gdzie ktoś napisał np o wadach produkcji i co należy poprawić.
Właśnie - nie należy mieszać hejterów z osobami wymieniającymi wady. Co innego, gdy ktos napisze: "Według mnie za mało program oferuje, przydałoby się dodać to i to i to i to" itd. a co innego gdy ktoś napisze: "Wypierd... z tym programem".
Jest różnica prawda? Niestety jako autor oprogramowania i ogólnie jako osoba, która swoje dzieła musi pokazywać światu, musisz przygotować się do tego, że na swojej drodze spotkasz mnóstwo hejterów. Aczkolwiek w późniejszym okresie hejterowi się nudzi ta zabawa i nagle okazuje się, że jest mnóstwo fanów danej produkcji.
Tak było też ze mną. Postanowiłem nie słuchać pewnych osób na tym forum tutaj i umieściłem program na stronie głównej produkcji starając się o to by aplikacja znalazła się w renomowanych miejscach w sieci. Baa do dziś cały czas pojawiają się nowe możliwości.
Program znalazł się na stronie dobreprogramy.pl, gdzie został wyróżniony poprzez napisanie specjalnego newsa:
http://www.dobreprogramy.pl/PhotoMake-2.0-latwa-obrobka-zdjec,Aktualnosc,29147.html
Program ów został wysoko oceniony przez użytkowników (dużo wyżej niż się spodziewałem). Aplikacja znalazła miejsce na wielu portalach z oprogramowaniem (wystarczy wpisać w google: "photomake 2.0"), a ja do dziś od czasu premiery otrzymuję coraz więcej maili. Maile owe dzielą się na:
"Rozmawialiśmy w gronie osób trudniących się amatorsko obróbką zdjęć i jesteśmy zgodni w uznaniu, że jak na " jednoosobowy zespół " napisał Pan bardzo interesujący program budzący podziw dla jego twórcy.
Ogromnym plusem PhotoMake 2.0 - jest znakomicie opracowane przez Pana " wsparcie techniczne " - jest zrobione solidnie i przejrzyście , co przekazuję Panu w imieniu swoim i swoich znajomych ( z ich upoważnienia ). "
"Mnie kojarzy się Pana program z Paint.Net i jak na na Pana samodzielą pracę jest wyposażony w duże możliwości edycyjne .
Niestety - mam zastrzeżenia co do pewnych jego funkcji.
1 . To przy otwieraniu programu " od ręki ' pełny ekran i strona powitalna .
Przy pierwszym uruchomieniu programu - jest to dobre rozwiązanie - ale przy każdym kolejnym , to jest już bardzo irytujące , czy jest taka możliwość żeby można raz zrobione ustawienia zatwierdzić na stałe.
2 . Sprawa " bocznych " programików ( przepraszam za taką nazwę ), powinne przy starcie w moim odczuciu - być przyklejone do tła programu - tak samo jak konkretna fotka ,a nie gdy przesuwam program - wszystko zostaje mi na monitorze i zaczynam się denerwować szukaniem potrzebnych rzeczy ."
Zauważ, że dziwnym trafem nie ma maili od hejterów. Jednak, gdy pojawisz się publicznie od razu się jacyś znajdą. osoby te po prostu chcą być zauważone.
Mam niezmierną satysfakcję, że napisałem duży projekt i się w 100% udał i Tobie także radze pisać duże projekty (jeszcze mała wzmianka o tym dlaczego tak radzę będzie poniżej).
Program jak się okazuje jest na tyle fajny, że pojawi się niedługo na okładce i na płycie pewnego czasopisma (jeszcze nie czas by wymieniać nazwę) oraz w lutowym numerze innego.
Czego chcieć więcej. Uśmiech z mojej twarzy nie schodzi i pragnę tworzyć jeszcze więcej takich i lepszych programów. W ten sposób osiąga sie ogromną, wręcz maksymalną satysfakcję z tego co się robi.
Jeszcze słówko czemu większy program jest lepszy od małego. A raczej czemu duży projekt jest lepszy od małego.
Przy dużym projekcie czasami następuje chwila, która nas nawet ZMUSZA do stworzenia małego miniprojektu. To są właśnie te ort! ort! jedno trudne zagadnienie. W ten sposób nabywamy doświadczenie i uczymy się nowych rzeczy. Jednak co z tego, że stworzymy 15 snippetów trudnych zagadnień skoro żadne z nich nie ma sensownego zastosowania?
Dopiero duży projekt uczy człowieka jak skorzystać z nabytej wiedzy. Podczas pisania dużego projektu nauczysz się łączyć ze sobą fragmenty danej produkcji, a to wcale nie jest takie łatwe by połączyć wszystko tak by ze sobą współgrało i jeszcze było elastyczne w razie dodawania nowych funkcjonalności.
Duży projekt uczy kontroli nad całością. Uczy tego w jaki sposób kontrolować swój kod na dużą skalę.
W małych projektach nie ma zbytniego sensu nawet starać się pisać estetycznie bo i tak wszystko widać. mały projekt poza tym nie osiągnie większego sukcesu, zaś duży taką możliwość ma.
na koniec pamiętaj: nie martw się hejterami, bo gdy człowiek coś zrobi o czym inni mogą tylko pomarzyć i ort! zazdrośni, hejterzy pojawią się bardzo szybko. Ignoruj ich i banuj jeśli masz taką możliwość. Skup się na własnej pracy i na tym by ulepszyć swoje produkcje. Słuchaj uwag i rad innych, ale nie słuchaj hejterów. Oni nie chcą dla Ciebie dobrze tylko dla siebie.
No i na koniec dodam tylko byś dobrze się zastanowił czy aby na pewno masz wystarczające umiejętności te, które wymieniłem na początku.
A rada jaki program napisać? Może przeglądarka graficzna? Jest dość prosta do zrobienia, a można ją ładnie ulepszać z czasem.
Pozdrawiam. Więcej w topicu ani na forum nie <ort>napisze,</ort>
Dodam tylko ze mam za soba sporo projektow, to nie jest tak ze zaczalem programowac 2 miesiace temu, przeczytalem kurs i chce nie wiadomo co napisac ;). po prostu wczesniej bylem glupi i pisalem programy bez OOP'u bo nie chcialo mi sie czytac kursow... Napisalem m.in pare botow do gier html(ktorymi handlowalem na allegro - same pozytywy), klient IRC z wbudowanym botem do wyszukiwania meczy(dla graczy CS, ten juz w OOP), klienta GG(jeszcze jak bawilem sie w delphi :d), program wykradajacy hasla(sciagajacy konkretne komorki pamieci, wysylajacy zawartosc na maila z konfiguratorem do ustawiania adresow komorek) oczywiscie tylko w celach naukowych! I wiele innych malych programikow... jednak prawdziwe programowanie zaczalem po przeczytaniu kursu ;p
Edit
Chyba ruszam z projektem Shaloma jutro ;). Moze macie jeszcze jakies pomysly?
Dobrze zrozumiałeś to co opisałem. Chodzi o takie narzędzie które umożliwia (np. adminowi) wykonywanie tych samych poleceń na wielu komputerach jednocześnie, tylko przy dodatkowym założeniu że takich adminów może też być kilku :)
@arasso12
skoro masz już całkiem spore doświadczenie i chciałbyś nauczyć się dobrych nawyków programowania i umiejętności radzenia sobie z dużymi projektami, to polecam dołączyć do jakiegoś dużego otwartego projektu. Zgadzam się z tym co napisał bswierczynski na temat dużych projektów. Generalnie jest tak, że projekt jest albo dobrze, albo źle prowadzony, a jego rozmiar nie ma tu znaczenia. Jedyne na co ma wpływ rozmiar projektu, to na to, że przy większych projektach złe nawyki bardziej dają się we znaki niż w mniejszych.
Z takich otwartych, dużych projektów proponuję projekt Chromium:
http://dev.chromium.org/Home
Wada tego projektu jest taka, że potrzebujesz dobrego sprzętu: co najmniej 4GB RAMu, im więcej rdzeni procesora tym lepiej i parę GB wolnego miejsca na dysku. Poza tym, zanim mógłbyś przystąpić do projektu, czeka Cię przebicie się przez kilka ton dokumentacji, ale to jest charakterystyczne dla każdego dużego projektu prowadzonego w profesjonalny sposób.
Zalety są takie, że możesz programować na Windowsie, Linuxie, Macu, masz wybór między SVNem, a Gitem, możesz programować w gcc, w Visualu Studio, a nawet w wersji Express Visuala.
Zdobyta wiedza na pewno będzie nieoceniona, a poza tym będziesz miał szansę pochwalić się znajomym, że daną funkcjonalność w Chrome, to Ty napisałeś :)
Ale jeśli nawet nie czujesz się na siłach żeby dołączyć do projektu, to i tak warto ściągnąć źródła i podłubać w nich, w celach edukacyjnych żeby dowiedzieć się jak tworzy się przeglądarki internetowe.
To bylaby dobra opcja, tylko jeszcze nie dla mnie ;/. Nie mam tyle czasu na przebijanie sie przez tony dokumentacji, szkole(IIIkl Technik Informatyk) itp. Poki co bede kodzil cos na wlasna reke, ruszam z propozycja Shaloma ;)