Jak zapewne większość się zorientowała, jestem z natury podejrzliwym pesymistą, który zawsze szuka drugiego dna. Tak też jest z zaskakującym ruchem firmy Microsoft, produkującą systemy z rodziny Windows, które postrzegane są przez młodych, bądź tych bardziej fanatycznie nastawionych, jako wrogowie Linuksa. Mianowicie Microsoft sponsoruje imprezę Linuksową. Na pierwszy rzut oka wygląda na to, że twórcy Windows chcą wkupić się w środowisko OpenSource. Moim zdaniem MS chce sprawdzić czy łatwo się Linuksowcy sprzedadzą swojemu "wrogowi".
UWAGA SPOILER KSIĄŻKI SREBRO STEVENA SAVILE
Ale mam też ciekawą teorię, dużo ciekawszą. Za "dobre wyniki w nauce, bardzo dobre zachowanie oraz ogromne zaangażowanie w życie klasy i okazaną pomoc [podwójna spacja] w roku szkolnym 2009/2010" otrzymałem książkę Stevena Savile'a pod tytułem "Srebro". Ta książka opowiada o pewnych złych ludziach "sykariuszach", których taktyką było zaprzyjaźnić się z ofiarą, a następnie zaatakować z skutkiem śmiertelnym i wołać dla niepoznaki o pomoc dla ofiary, jak by to zrobił prawdziwy przyjaciel. Microsoft też próbuje się zaatakować podobną taktyką.
2010-08-15
Qt Creator - on_nazwaObiektu_sygnal
Dzisiaj odkryłem kolejną fajną rzecz w origranue Qt Creator. Mianowicie, gdy mam obiekt w formularzu z desingera, który np. nazywa sie loadButton i jest typu QPushButton, więc ma sygnał clicked(), mogę napisać w sekcji slots "void on_loadButton_clicked()", a Qt sam mi podłączy sygnał do slotu. Dzięki tej "sztuczce" łatwiej mi rozwijać swoje mikro projekty.
Wpis króciutki, ponieważ to co chciałem napisać nie mieściło się na blipie. Takie wpisy będą oznaczane specjalnym tagiem "miniblog", a linki do nich będą na blipie.
Wpis króciutki, ponieważ to co chciałem napisać nie mieściło się na blipie. Takie wpisy będą oznaczane specjalnym tagiem "miniblog", a linki do nich będą na blipie.
2010-07-30
Obiektowe boom i puchnący kod
Niektórzy wiedzą, że jestem już w zaawansowanym stadium osobistego projektu żartobliwie nazwanego "JAVATAR", który polega na poznaniu JAVA w stopniu pozwalającym, na napisanie przeciętnej aplikacji. Co prawda mam już niewielkie opóźnienie, ale nie i tym będzie dzisiejszy wpis.
W czasie nauki C++ często zauważałem jak wychwalano obiekty. Rzeczywiście, często ułatwiają prace, ponieważ operowanie na nich jest "wygodniejsze i bardziej intuicyjne". Podejrzewam, że ten pogląd bierze się stąd, że programista pod jedną nazwą ma dostęp do funkcji, zwanych metodami i danych. Mi, osobiście, się to jednak nie podoba, ponieważ daje złudny obraz obiektu, jako danych i kodu w jednym miejscu. W rzeczywistości jednak są to stare, dobre funkcje z wskaźnikiem na stukture w pierwszym, niewidocznym dla programisry argumencie. Myśle, że fakt, iż kod nie jest bezpośrednio połączony z danymi, jest istotny, jednak często nasi nauczyciele, nie ważne czy to są ludzie, czy kursy lub książki, "zapominają" nas o tym poinformować. Może przyczyną takiego stanu rzeczy jest to, że cała magia OOP nagle znika? Doświadczony programista zaraz by zwrócił uwagę na "przewspaniałą" możliwość dziedziczenia. Niestety, to tylko doklejanie kolejnych pòl do struktury i wywołanie metody o innej nazwie. Przeciążone funkcje też nie są magiczne, suma(int, double) to sumaid, a suma(int, int) to sumaii. Nie, nie twierdze, że obiektowość jest zła czy nie potrzeba, ponieważ z pewnością ułatwia zarządzanie zasobami ludzkimi i kodem projektu. Na kilku spotkaniach ustalane są podstawowe obiekty, ich interfejsy, oraz zależności, a później można przejść do tego, do czego programiści są stworzeni, czyli do klepania kodu w własnym zakresie. Do tego system szablonów skutecznie ułatwia pisanie uniwersalnych i łatwiejszych w zarządzaniu, więc też utrzymaniu, projektów.
Kazdy się z pewnością domyśla, że im mniejszy jest kod (mniej ma linijek), tym łatwiej nim zarządzać, jednak twórcy JAVA chyba o tym zapomnieli. Samo OOP wymaga napisania dodatkowego kodu dla każdej z klas i zachowując "dobre maniery" programowania obiektowego (np. dodawanie set i get dla zmiennych do których użytkownik ma określony dostęp) okazuje się, że kod, który powinien zajmować 2kB, nagle zajmuje 6 kB. W przypadku większych projektów pewnie tak tego nie widać, ale nawet przy założeniu, że kod urośnie o 30% mnie przeraża. Nie chodzi mi tutaj o to, że kod musi być przeciskany przez wolne łącza lub zajmuje dużo miejsca na dysku, zawsze może być skompresowany, ale o to, że programista, który dołącza się do projektu musi przeczytać prawie o 1/3 kodu więcej, by ogarnąć całość programu i systemy nim rządzące. W rzeczywistości jest to duża strata czasu, na którą pewnie niektórzy się nie godzą i nie czytają całego kodu, więc z pod ich palców wychodzą znaczki, które robią to, co już ktoś inny napisał. Kod jeszcze bardziej puchnie, a gdy taka sytuacja się zdarza to już po krótkim czasie dochodzi się do tego, że trzeba przepisać kod. Jednak komu chce się przepisać aplikacje, która ma miliard linii kodu? Dla firmy jest to nie do pomyślenia, ponieważ zatrzymuje rozwój całej aplikacji, stwarza nowe miejsce dla błędów i nie gwarantuje, że stare się nie powtórzą.
Całkiem inną rzeczą, która mnie w JAVA irytuje jest to, że nie ma szablonów funkcji, ani, sądząc po podstawowym api JAVA, żadnych mechanizmów pozwalających na wykorzystanie tego samego kodu w nieco innej sytuacji. Powstae niezdrowa sytuacja, w której trzeba przeciążyć funkcje dla każdego typu podstawowego osobno. Jest to szczególnie denerwujące gdy w naszej obsłudze któregoś z typów wkradnie się malutki błąd, którego zauważenie często zajmuje sporo czasu. Jeszcze musi być odzielna wersja dla obiektów... Nagle oskazuje się, że niepotrzebnie trzeba napisać o połowę więcej kodu.
W JAVA nie da się też przeciążać operatorów, co w przypadku np. BigDecimals. Nie dość że jest bardzo nieintuicyjne, to jeszcze sprawia, że kod jest mniej przejrzysty i bardziej zagmatwany. Człowiek widząc "a > b" szybciej zorientuje się o co chodzi niż składnia wywołująca "compareTo", której szczerze jeszcze nie rozumiem...
W czasie nauki C++ często zauważałem jak wychwalano obiekty. Rzeczywiście, często ułatwiają prace, ponieważ operowanie na nich jest "wygodniejsze i bardziej intuicyjne". Podejrzewam, że ten pogląd bierze się stąd, że programista pod jedną nazwą ma dostęp do funkcji, zwanych metodami i danych. Mi, osobiście, się to jednak nie podoba, ponieważ daje złudny obraz obiektu, jako danych i kodu w jednym miejscu. W rzeczywistości jednak są to stare, dobre funkcje z wskaźnikiem na stukture w pierwszym, niewidocznym dla programisry argumencie. Myśle, że fakt, iż kod nie jest bezpośrednio połączony z danymi, jest istotny, jednak często nasi nauczyciele, nie ważne czy to są ludzie, czy kursy lub książki, "zapominają" nas o tym poinformować. Może przyczyną takiego stanu rzeczy jest to, że cała magia OOP nagle znika? Doświadczony programista zaraz by zwrócił uwagę na "przewspaniałą" możliwość dziedziczenia. Niestety, to tylko doklejanie kolejnych pòl do struktury i wywołanie metody o innej nazwie. Przeciążone funkcje też nie są magiczne, suma(int, double) to sumaid, a suma(int, int) to sumaii. Nie, nie twierdze, że obiektowość jest zła czy nie potrzeba, ponieważ z pewnością ułatwia zarządzanie zasobami ludzkimi i kodem projektu. Na kilku spotkaniach ustalane są podstawowe obiekty, ich interfejsy, oraz zależności, a później można przejść do tego, do czego programiści są stworzeni, czyli do klepania kodu w własnym zakresie. Do tego system szablonów skutecznie ułatwia pisanie uniwersalnych i łatwiejszych w zarządzaniu, więc też utrzymaniu, projektów.
Kazdy się z pewnością domyśla, że im mniejszy jest kod (mniej ma linijek), tym łatwiej nim zarządzać, jednak twórcy JAVA chyba o tym zapomnieli. Samo OOP wymaga napisania dodatkowego kodu dla każdej z klas i zachowując "dobre maniery" programowania obiektowego (np. dodawanie set i get dla zmiennych do których użytkownik ma określony dostęp) okazuje się, że kod, który powinien zajmować 2kB, nagle zajmuje 6 kB. W przypadku większych projektów pewnie tak tego nie widać, ale nawet przy założeniu, że kod urośnie o 30% mnie przeraża. Nie chodzi mi tutaj o to, że kod musi być przeciskany przez wolne łącza lub zajmuje dużo miejsca na dysku, zawsze może być skompresowany, ale o to, że programista, który dołącza się do projektu musi przeczytać prawie o 1/3 kodu więcej, by ogarnąć całość programu i systemy nim rządzące. W rzeczywistości jest to duża strata czasu, na którą pewnie niektórzy się nie godzą i nie czytają całego kodu, więc z pod ich palców wychodzą znaczki, które robią to, co już ktoś inny napisał. Kod jeszcze bardziej puchnie, a gdy taka sytuacja się zdarza to już po krótkim czasie dochodzi się do tego, że trzeba przepisać kod. Jednak komu chce się przepisać aplikacje, która ma miliard linii kodu? Dla firmy jest to nie do pomyślenia, ponieważ zatrzymuje rozwój całej aplikacji, stwarza nowe miejsce dla błędów i nie gwarantuje, że stare się nie powtórzą.
Całkiem inną rzeczą, która mnie w JAVA irytuje jest to, że nie ma szablonów funkcji, ani, sądząc po podstawowym api JAVA, żadnych mechanizmów pozwalających na wykorzystanie tego samego kodu w nieco innej sytuacji. Powstae niezdrowa sytuacja, w której trzeba przeciążyć funkcje dla każdego typu podstawowego osobno. Jest to szczególnie denerwujące gdy w naszej obsłudze któregoś z typów wkradnie się malutki błąd, którego zauważenie często zajmuje sporo czasu. Jeszcze musi być odzielna wersja dla obiektów... Nagle oskazuje się, że niepotrzebnie trzeba napisać o połowę więcej kodu.
W JAVA nie da się też przeciążać operatorów, co w przypadku np. BigDecimals. Nie dość że jest bardzo nieintuicyjne, to jeszcze sprawia, że kod jest mniej przejrzysty i bardziej zagmatwany. Człowiek widząc "a > b" szybciej zorientuje się o co chodzi niż składnia wywołująca "compareTo", której szczerze jeszcze nie rozumiem...
2010-07-24
Nie chęci, a poświęcenie się liczy
Kto nie zna powiedzenia "Chcieć to móc"? Chyba każdy to słyszał przynajmniej jeden raz w życiu, ale kto się na tym głębiej zastanawiał?
Chęci to podstawa, jednak moim zdaniem nie są najważniejsze. W sumie twierdze, że same chęci nie mają żadnej mocy. Wiele ludzi chce coś zmienić, jednak nie zmieniają nic, ponieważ brakuje im ważnego czynnika, który nazywam poświęceniem. Chęci są tak jakby zapłonem do tego, by działać, jednak sukces zależy od poświęcenia, ponieważ tylko w przypadku gdy ktoś (jednostka, grupa, twór prawny) jest w stanie poświęcić swoje środki, jak np. czas, pieniądze lub energie, tylko wtedy może się zbliżać do osiągnięcia sukcesu.
Dowodem na to, że mam racje jest coraz bardziej znaczacy sukces OpenSource nad rozwiązaniami komercyjnymi. Dla przypakładu, twórcy Linuksa i naprawdę ogromnej ilości oprogramowania na ten system, nie biorą pieniędzy za to, co robią, jednak ich rozwiązania są często wydajniejsze od tych, które napisali programiści za pieniądzę. Twórcy oprogramowania, którzy programują z pasją poświęcają znacznie wiecej energii na swoje projekty niż Ci, którzy poświęcają jak najmniej energii w zamian za płacę, która często jest jedynym motywatorem.
To jak jesteśmy w stanie się poświęcić zależy od naszej motywacji, wewnętrznej i zewnętrznej. Twórcy otwartego oprogramowania są motywanie głównie wewnętrznie, poprzez idee OS lub chęć "zabłyśnięcia", przynajmniej tak mi się wydaje, zaś ich koledzy zajmujący się programowaniem komercyjnym są motywani pieniądzem. Jak świat niekoniecznie informatyczny pokazuje, idea jest dużo mocniejszym czynnikiem od pieniądza, ponieważ w historii ludzie buntowali się dla "wolności" by znów zostać "zakutymi w kajdany systemu" albo przykład bliższy nam, współczesnym ludziom, terroryści. Moim zdaniem ludzie, mocno wierzący w jakieś ideologie, są tak samo zmotywowani jak Ci, co mocno wierzą w swoich Bogów. Z resztą, słysząłem stwierdzenia które, sądząc po użytych słowach i składni zdania, jednoznacznie stawiały ideologie na wysokości Bogów innych osób. Wiem też, że pieniądze również mają swoją moc, szczególnie gdy ich suma jest duża, jednakże wydaje mi się, że ich siła maleje. Niestety, nie mam okazji sprawdzić tego w praktyce, jednak obserwuje takie zachowania wśród ludzi ze środowiska. Osoba kierująca się ideą jest w stanie poświęcić jej swoje życie, zaś osoba, która robi coś dla pieniądza, tylko 8h przez 6 dni w tygodniu...
Dobrym przykładem, właściwie aktualnie jedynym przychodzącym mi do głowy jest Richard Mattew Stallman. Sam był w stanie przez pewien czas konkurować z potężnymi firmami, które miały sztaby programistów, ale historia jego heroicznego boju zasługuje na własny wpis.
Podsumowując, chęci bez poświęcenia są niczym, potrzebny jest też poświęcenie. Moim zdaniem "Chcieć to móc" jest przekłamane, gdyż leniwe osoby uszczuplały to powiedzenie, ponieważ ludzie lubią skróty myślowe. Być może kiedyś te słowa brzmiały podobnie do "Będąc zdolnym do wielkiego poświęcenia osiągniesz sukces."?
Chęci to podstawa, jednak moim zdaniem nie są najważniejsze. W sumie twierdze, że same chęci nie mają żadnej mocy. Wiele ludzi chce coś zmienić, jednak nie zmieniają nic, ponieważ brakuje im ważnego czynnika, który nazywam poświęceniem. Chęci są tak jakby zapłonem do tego, by działać, jednak sukces zależy od poświęcenia, ponieważ tylko w przypadku gdy ktoś (jednostka, grupa, twór prawny) jest w stanie poświęcić swoje środki, jak np. czas, pieniądze lub energie, tylko wtedy może się zbliżać do osiągnięcia sukcesu.
Dowodem na to, że mam racje jest coraz bardziej znaczacy sukces OpenSource nad rozwiązaniami komercyjnymi. Dla przypakładu, twórcy Linuksa i naprawdę ogromnej ilości oprogramowania na ten system, nie biorą pieniędzy za to, co robią, jednak ich rozwiązania są często wydajniejsze od tych, które napisali programiści za pieniądzę. Twórcy oprogramowania, którzy programują z pasją poświęcają znacznie wiecej energii na swoje projekty niż Ci, którzy poświęcają jak najmniej energii w zamian za płacę, która często jest jedynym motywatorem.
To jak jesteśmy w stanie się poświęcić zależy od naszej motywacji, wewnętrznej i zewnętrznej. Twórcy otwartego oprogramowania są motywanie głównie wewnętrznie, poprzez idee OS lub chęć "zabłyśnięcia", przynajmniej tak mi się wydaje, zaś ich koledzy zajmujący się programowaniem komercyjnym są motywani pieniądzem. Jak świat niekoniecznie informatyczny pokazuje, idea jest dużo mocniejszym czynnikiem od pieniądza, ponieważ w historii ludzie buntowali się dla "wolności" by znów zostać "zakutymi w kajdany systemu" albo przykład bliższy nam, współczesnym ludziom, terroryści. Moim zdaniem ludzie, mocno wierzący w jakieś ideologie, są tak samo zmotywowani jak Ci, co mocno wierzą w swoich Bogów. Z resztą, słysząłem stwierdzenia które, sądząc po użytych słowach i składni zdania, jednoznacznie stawiały ideologie na wysokości Bogów innych osób. Wiem też, że pieniądze również mają swoją moc, szczególnie gdy ich suma jest duża, jednakże wydaje mi się, że ich siła maleje. Niestety, nie mam okazji sprawdzić tego w praktyce, jednak obserwuje takie zachowania wśród ludzi ze środowiska. Osoba kierująca się ideą jest w stanie poświęcić jej swoje życie, zaś osoba, która robi coś dla pieniądza, tylko 8h przez 6 dni w tygodniu...
Dobrym przykładem, właściwie aktualnie jedynym przychodzącym mi do głowy jest Richard Mattew Stallman. Sam był w stanie przez pewien czas konkurować z potężnymi firmami, które miały sztaby programistów, ale historia jego heroicznego boju zasługuje na własny wpis.
Podsumowując, chęci bez poświęcenia są niczym, potrzebny jest też poświęcenie. Moim zdaniem "Chcieć to móc" jest przekłamane, gdyż leniwe osoby uszczuplały to powiedzenie, ponieważ ludzie lubią skróty myślowe. Być może kiedyś te słowa brzmiały podobnie do "Będąc zdolnym do wielkiego poświęcenia osiągniesz sukces."?
2010-02-06
Od jakiegoś czasu nosze się z napisaniem gry. Początkowe założenia były naprawdę ambitne, bitwy w kosmosie, na pokładzie statków, na planetach... W czasie równoległej walki kosmicznej i abordarzu uszkodzenia statków miały być nanoszone na arene abordarzu, a wszelkie dokonania na pokładzie, przenoszone na gre w kosmosie. System uszkodzeń miał być również skomplikowany, nie dość, że każde pomieszczenie statku miało odzielną atmosfere (z popękanego kadłuba uciekało by powietrze), to byłaby możliwość wyłączenia, na przykład, reaktora statku, co by go wyłączało praktycznie z bitwy, chyba że miałby inne źródło energii, lub załoga odbiła by pomieszczenie gdzie reaktor się znajduje i włączyła go ponownie (a włączenie reaktora, gdy konsola sterująca jest zniszczona wiązałoby się z ryzykiem przeciążenia i BOOM). Ale to za dużo kodzenia, po drugie grafika brak.
Wersja druga pomysłu, to gra www, podobna do starego OGame, bo grafika żadnego znaleźć nie mogę, jednak bardziej rozbudowana (5 surowców, rasy, atmosfery, niszczenie i przejmowanie planet, losowe wydarzenia), jednak chyba i ona nie wyjdzie, bo plan skomplikowany, a ilosc jezykow webotwórczych też spora...
2010-01-10
Reaktywacja
Byc moze w koncu uda mi sie powrocic do starego bloga. Nie pisze juz na hack.pl, wlasciwie to w ogole przestalem cokolwiek publikowac. Jednak ferie sie zblizaja i zamierzam cos naskrobac. Wiecej napisze jak skonfiguruje nowy (a moze wlasciwie stary?) system. Powrot do Debiana.
Subskrybuj:
Posty (Atom)