internetowy śmietniczek kj

Z cyklu tajemnice tego świata: karty SD

2011-02-19T00:02:00.002+01:00

Udało mi się dzisiaj dowiedzieć, czemu karty pamięci Kingstona są tak dobrze wspierane. Otóż producent udostępnia ich specyfikację na swojej stronie za darmo wbrew oficjalnej organizacji (zwanej szumnie SD Association) pobierającej za świadczenie uprzejmości dostępu do dokumentacji drobne 1000 USD rocznie.

Niech ich szlag!

2010-08-18T20:09:00.004+02:00

Znowu o muzyce, a raczej o jej braku. Wchodząc sobie na filmik (raczej slajdowisko z muzyką) na YouTube, umieszczony pod adresem: YouTube otrzymałem informację:

"Ten film wideo zawiera treść od partnera Sony Music Entertainment, który zablokował go w Twoim kraju na mocy praw autorskich."

Teraz puenta: powyższy link prowadzi do nagrania Nokturnu Es-dur op.9 cz. 2 autorstwa Polaka - Fryderyka Chopina, wykonywanego przez innego Polaka (pochodzenia żydowskiego) - Artura Rubinsteina, a ja siedzę sobie przed komputerem w Polsce i czytam, że banda Japończyków mi odcięła dostęp do tej muzyki.

Wydajność Django

2010-07-24T15:34:00.003+02:00

Najwyższa pora zastanowić się, jak to jest z tą wydajnością w Django. Dla przykładu stworzymy sobie prostą aplikację, która będzie miała za zadanie jedynie generować tymczasowe dane. Dla ułatwienia generujemy tylko i wyłącznie prosty kod html, bez korzystania z szablonów. Naszym celem będzie sprawdzenie wydajności samego Pythona w charakterze szybkości obsługi żądania, wpływ zapytań do bazy danych na wydajność, a wreszcie - przyspieszenie dzięki użyciu memcache. Testy przeprowadzimy na serwerze www wbudowanym do Django. Będziemy mierzyli parametry pracy Django dla 1000 zapytań.

Zadanie 1: widok zwracający statyczny html. Kod funkcji:


def test(request):
        return HttpResponse('<html>Hello!</html>')

Uruchamiamy serwer oraz testujemy:


Total transferred:      152000 bytes
HTML transferred:       19000 bytes
Requests per second:    961.41 [#/sec] (mean)
Time per request:       1.040 [ms] (mean)
Time per request:       1.040 [ms] (mean, across all concurrent requests)
Transfer rate:          142.71 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     1    1   0.8      1      22
Waiting:        0    1   0.8      1      21
Total:          1    1   0.8      1      22

Wydajność rzędu ok. 960 req/s jest jak najbardziej dobra. Dla porównania, serwer bochnianin.pl nie wytrzymała najazdu 60000 wejść na dobę (przy założeniu, że ruch koncentruje się max. 8h w ciągu doby, daje to zaledwie ~3 req/s). Jesteśmy zatem 300x do przodu.

Zadanie 2: Widok odwołujący się do bazy danych (jedno zapytanie). Kod funkcji:


def test(request):
        wal = Waluta.objects.get(pk='USD')
        return HttpResponse('<html>Hello! - %s</html>' % wal.nazwa)


Total transferred:      173000 bytes
HTML transferred:       40000 bytes
Requests per second:    130.48 [#/sec] (mean)
Time per request:       7.664 [ms] (mean)
Time per request:       7.664 [ms] (mean, across all concurrent requests)
Transfer rate:          22.04 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       1
Processing:     6    8   1.4      7      19
Waiting:        4    7   1.4      7      18
Total:          6    8   1.4      7      19

Ilość obsłużonych żądań na sekundę spadła z magicznych okolic 960 req/s do ok. 130 req/s, co jest jednak nadal bardzo dobrym rezultatem. Pamiętajmy jednak, że jest to wynik dla zaledwie jednego prostego zapytania. Teraz będzie ciut trudniej - w kolejnym przykładzie zapytań będzie więcej, a także dojdzie łączenie relacją typu wiele-do-wielu. Zobaczmy, jak sprawdzi się Django.

Zadanie 3: Widok pobierający z bazy danych więcej informacji, łączenie wiele-do-wielu. Kod funkcji:


def test(request):
        wal = Waluta.objects.get(pk='USD')
        wartosc = WartoscWaluty.objects.get(waluta=wal)
        kurs = wartosc.kurs
        return HttpResponse('<html>Hello! - %s</html>' % kurs)

Wyniki:


Total transferred:      182000 bytes
HTML transferred:       49000 bytes
Requests per second:    91.41 [#/sec] (mean)
Time per request:       10.940 [ms] (mean)
Time per request:       10.940 [ms] (mean, across all concurrent requests)
Transfer rate:          16.25 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     9   11   1.4     11      25
Waiting:        8   10   1.3     10      24
Total:          9   11   1.4     11      25

Zwiększenie ilości zapytań do bazy danych spowolniło działanie aplikacji o ok. 40 reg/s. Czy to dużo? Dla porównania - standardowo Wordpress generuje ok. 6 req/s. Pamiętajmy jednak, że w naszym przypadku serwujemy bardzo mało danych, a sama aplikacja jest niezwykle prymitywna, nieporównywalna rozmiarowo z Wordpressem. W podanym przeze mnie linku, autor chwali się, że dzięki użyciu mechanizmu cache, udało mu się przyspieszyć aplikację do ok. 395 req/s. Spróbujmy i my. Użyjemy Memcache.

Zadanie 4: Dodajemy cache. Kod funkcji:


@cache_page(60*15)
def test(request):
        wal = Waluta.objects.get(pk='USD')
        wartosc = WartoscWaluty.objects.get(waluta=wal)
        kurs = wartosc.kurs
        return HttpResponse('<html>Hello! - %s</html>' % kurs)

Cache ustawiony jest na 15 minut. Test:


Total transferred:      338000 bytes
HTML transferred:       49000 bytes
Requests per second:    605.64 [#/sec] (mean)
Time per request:       1.651 [ms] (mean)
Time per request:       1.651 [ms] (mean, across all concurrent requests)
Transfer rate:          199.91 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     1    2   1.2      1      33
Waiting:        1    1   1.2      1      32
Total:          1    2   1.2      1      33

Wróciliśmy do trzycyfrowego wyniku, osiągając wynik ponad 605 req/s! To ponad 200 req/s szybciej niż najbardziej przyspieszony Wordpress. Kluczowe pytanie: czy my tak naprawdę potrzebujemy aż tak szybkiego softu? Policzmy, zakładając, że serwujemy 8 godzin na dobę naszą stronę z maksymalną szybkością 605 req/s, to w ciągu miesiąca (30 dni) mamy: 522720000 (słownie: pół miliarda) wejść na miesiąc! Sądzę, że taką wydajność muszą mieć serwisy kalibru YouTube. Jeśli zaś nie użyjemy mechanizmu cache i spróbujemy działać przy szybkości 80 req/s, to okaże się, że nadal możemy obsługiwać ilość wejść na poziomie 69120000 (czyli ponad 69 milionów odsłon), co nadal jest doskonałym wynikiem.

Konkluzja: dla szybkości działania serwisu, oprócz sprawności samego oprogramowania generującego kod html ważna jest także przepustowość łącz, efektywność baz danych, siedzących "pod spodem" oraz specyfika systemu operacyjnego, na którym to wszystko działa. Mój mały test pokazuje tylko zmiany wydajności frameworka Django w zależności od ilości zapytań do bazy danych oraz zastosowanych optymalizacji. W zestawieniu [jak dla mnie] brakuje tylko jednego elementu: testu wydajności Django, uruchomionego na interpreterze pochodzącym z projektu unladen-swallow. Wtedy też otrzymalibyśmy miarodajne przełożenie w postaci wzrostu [lub spadku ;)] ilości obsłużonych żądań na sekundę.

Python - problemy

2010-07-04T11:30:00.004+02:00

Tym razem kilka słów o niedoskonałościach Pythona, które powodują, że zostaje on nieco w tyle za chociażby Javą. Zacznijmy od tego, że Java dysponuje bardzo zaawansowaną maszyną wirtualną. Umożliwia ona współbieżne wykonywanie kilku wątków. Dla przykładu zademonstruję program, który zgodnie z wszelaką logiką powinien wykonywać się współbieżnie. Zakładamy, że oba wątki nie korzystają ze wspólnych danych i nie potrzebujemy tutaj żadnych blokad, które mogłyby być przeszkodą do wykonywania współbieżnego.


#!/usr/bin/env python

from threading import Thread

class moj_watek(Thread):
        def __init__(self):
                Thread.__init__(self)

        def run(self):
                a = 1
                while(1): a+=a/2

watek = moj_watek()
watek.start()
b = 1
while 1: b+=b/2

Po uruchomieniu programu chcielibyśmy, aby nasz kod był równolegle wykonywany na dwóch procesorach (tyle mam w laptopie). Przypatrzmy się zatem, co się dzieje w komputerze po uruchomieniu programu:

Widzimy, że procesory są używane tylko w ok. 50%, chociaż dwa wątki powinny zajmować cały czas obu procesorów. Dlaczego? Python ma w sobie wbudowaną blokadę - tzw. Global Interpreter Lock (GIL). Dobry opis tego problemu w języku polskim można znaleźć tutaj: "Python, wątki i GIL. Fakty i mity."
Problem jest o tyle poważny, że obecnie współbieżność programów w Pythonie uzyskuje się tworząc wiele procesów. Oczywiście ten sposób jest bardzo uciążliwy (powolność IPC, problem z przekazywaniem otwartych deskryptorów gniazd i plików etc.). Jednym z celów wersji 3.2 jest zmodyfikowanie GIL-a tak, aby zamiast zliczania instrukcji kodu bajtowego Pythona opierała się na pomiarze czasu, co pozwoliłoby uniknąć problemów opisanych tutaj: Inside the Python GIL.

Z drugiej strony mamy jeszcze inne implementacje Pythona niż standardowy CPython. Warto tutaj wspomnieć o Jythonie, czyli o implementacji Pythona w Javie. Tutaj wielowątkowość w żaden sposób nie jest problematyczna, a pojęcie globalnej blokady interpretera fizycznie nie istnieje.

Jeszcze jedna sprawa. Python po kilkunastu latach istnienia doczekał się w końcu własnego JIT-a, bazującego na LLVM. W wersji 3.3 wysiłki projektu Unladen Swallow zostaną zintegrowane z oryginalnym CPythonem. Dokładny opis zamieszczony jest tutaj: integracja Unladen Swallow. Co prawda nie osiągnięto założonego, pięciokrotnego przyspieszenia, jednak sami autorzy przyznają, że potencjał technologii JIT jest tak duży, że nawet nie zbliżyli się do jej pełnego wykorzystania. Miejmy więc nadzieję, że wysiłek pracowników Google, autorów LLVM oraz twórców Pythona pozwoli w końcu mocno przyspieszyć ten jakże efektywny dla programisty język.

Profiler dla Pythona

2010-06-04T16:29:00.002+02:00

Dzisiaj nieco tekstu technicznego. W swojej pracy miałem styczność z jboss-profilerem, czyli programem napisanym w Javie, a umożliwiającym podgląd efektywności napisanego kodu. Profiler ten, oprócz standardowych informacji o czasie wykonywania poszczególnych funkcji udostępniał dane o ilości alokacji poszczególnych obiektów. W Pythonie mamy co prawda cProfiler, który także generuje dane o czasach wykonania poszczególnych funkcji, jednak nie udostępnia on informacji o ilości instancji danego obiektu oraz rozmiarze pamięci zajmowanej przez obiekt. Oto moje rozwiązanie, czyli profiler monitorujący za pomocą modułu Garbage Collectora liczbę zaalokowanych i nie zwolnionych obiektów w pamięci:


import sys
import os
import gc
import types
import inspect
import atexit

def check_allocations():
    dt = {}
    #gc.collect() jeśli byśmy chcieli info tylko o obiektach żyjących
    for obj in gc.get_objects():
        try:
            if dt.has_key(obj.__class__.__name__):
                instances,number,size,typ,bi,module = dt[obj.__class__.__name__]
                number+=1
                size+=sys.getsizeof(obj)
                if obj not in instances:
                    instances.append(obj)
                dt[obj.__class__.__name__] = (instances,number,size,typ,bi,module)
            else:
                dt[obj.__class__.__name__] = ([obj],1,sys.getsizeof(obj),type(obj),inspect.isbuiltin(obj),obj.__module__)
        except AttributeError as e:
            pass
    return dt

def run():
    data = check_allocations()
    print '\n\nCurrent allocations'
    print '\t%40s | %9s | %9s bytes | <<%s>>' % ('Class name', 'number', 'size', 'module')
    print '\t-----------------------------------------------------------------------------------'
    for key in data:
        instcs,number,size,typ,bi,module = data[key]
        if module == '__main__':
            print '\t%-40.40s | %9d | %9d bytes | <<%s>>' % (key, number, size, module)
            for inst in instcs:
                print '\t    -> %14.14s 0x%016x | %9s | %9s bytes | <<%s>>' % ('id', id(inst),' ',sys.getsizeof(inst),'---')

    print gc.garbage
    print '\n\n'

def main():
    import os, sys
    from optparse import OptionParser
    usage = "profiler.py scriptfile"
    parser = OptionParser(usage=usage)
    parser.allow_interspersed_args = False
    
    if not sys.argv[1:]:
        parser.print_usage()
        sys.exit(2)
    (options,args) = parser.parse_args()

    sys.argv[:] = args

    if len(sys.argv) > 0:
        import __main__
        dict = __main__.__dict__
        
        sys.path.insert(0, os.path.dirname(sys.argv[0]))
        gc.set_threshold(0)
        gc.set_debug(gc.DEBUG_SAVEALL)
        try:
            exec 'execfile(%r)' % sys.argv[0] in dict, dict
        except KeyboardInterrupt as ki:
            pass
        atexit.register(run)
    else:
        parser.print_usage()

if __name__ == '__main__':
    main()

Kompletny kod jest dostępny tutaj.

Powyższy kod ma obecnie tylko i wyłącznie wartość demonstracyjną, może służyć do badania małych skryptów. Jeśli chcielibyśmy podglądać większe programy, warto w funkcji run ustawić filtrowanie modułów na te, które chcemy monitorować.

Korzystanie z mojego profilera jest analogiczne do tego z cProfilera:


python -m profiler monitorowany_skrypt.py

Miłego korzystania ;)

Zachód słońca nad Bochnią

2010-01-02T23:09:00.002+01:00

Jaworzyna Krynicka w sylwestrową noc

2010-01-02T15:22:00.001+01:00

Rynek w Bochni

2009-12-25T21:31:00.003+01:00

Miłego oglądania:

Muzyka z "Polskich dróg"

2009-09-09T00:40:00.004+02:00

Pielęgnując dobry zwyczaj przeszukiwania YouTube w poszukiwaniu dobrej muzyki, wyniesiony z liceum dokopałem się najpierw do muzyki z filmu "Polskie Drogi" autorstwa nieżyjącego już niestety Andrzeja Kurylewicza:

Chwilę później natrafiłem na ten sam utwór w wykonaniu Pata Metheny'ego:

Dla zainteresowanych udostępniam nuty: polskie_drogi.pdf. Dodatkowe ogłoszenie: nuty są w niskiej jakości - gdyby ktoś chciał je przepisać chociażby za pomocą LilyPond i ew. dodać wersję na gitarę, to serdecznie zapraszam.

Miodek (18+)

2009-09-06T21:52:00.007+02:00

Dzisiaj coś miłego dla podniebienia, czyli techniki wyrobu alkoholu na potrzeby własne (a jakże) ze słodkawego, lepkiego, żółtego, pracowicie przez pszczoły przyniesionego miodku.

Do rzeczy.

Na początek musimy przygotować drożdże winne. Możemy je kupić w sklepach zielarskich, ja osobiście polecam drożdże "Tokaj" - u mnie się po prostu sprawdzały. W Bochni można je kupić na przeciwko "Groty" koło szybu Sutoris. Zanim zestaw przerobowy trafi do dymiona musimy owe drożdże uruchomić. Gotujemy wodę, rozpuszczamy w niej 2 łyżeczki cukru i małą szczyptę pożywki dla drożdży po czym studzimy do temp. ok 30º C. Musimy uważać, gdyż drożdże są bardzo wrażliwe na wysoką temperaturę i za pomocą wrzątku możemy je po prostu zabić, a to niestety uwaliłoby cały misterny plan przerobienia miodu na alkohol. Wsypujemy drożdże do butelki (może być np. po piwie) i zalewamy ostudzoną pożywką. Odstawiamy na dzień lub dwa. Jeśli drożdże pracują, tj. w butelce widać bąbelki dwutlenku węgla, który jest intensywnie wydzielany w czasie pracy drożdży, to możemy przejść do konkretów. Bierzemy się za przygotowanie materiału na wino.

Po pierwsze miód. Nie musi to być miód najlepszej kategorii, bo i tak pierwsze, co z nim zrobimy, to zmieszamy z wodą i zagrzejemy do ok. 70º C. Ilość potrzebnego miodu zależy od tego, jaki chcemy zrobić trunek. Osobiście polecam trójniaczek (1:3) oraz czwórniaczek (1:4), a ponieważ zwykle trudno jest się zdecydować, który lepszy, to robię trójniaczkowaty czwórniaczek (1:3.5). W takim przypadku na kilogram miodu potrzeba 3.5 litra wody. Jeśli mamy do dyspozycji dymion 40-sto litrowy, to potrzebujemy ok. 9-10 kg miodu. Odradzam na początek robić miody słodkie, tj. stosunek 1:2 czy 1:1.5. Są one trudne do poprawnego zrobienia i trzeba bardzo długo czekać, aż do końca sfermentują.

Oprócz miodu potrzeba przypraw: goździki, imbir, chmiel, pieprz, kwasek cytrynowy (lub sok z cytryny - jak kto lubi). Wszystkie te zioła, poza kwaskiem, owijamy w kawałek czystej gazy i wrzucamy do zmieszanego z wodą miodu i podgrzewamy do 70º C, usuwając przy tym pojawiajacą się pianę. Możemy stworzyć np. jeden taki pakunek i po prostu przerzucać go z garczka do garczka w miarę przygotowywania kolejnych porcji. Ilość przypraw powinniśmy sami dobrać w/g własnego gustu. Nie będę tutaj nic nikomu sugerował. Ważna uwaga: nie zagotujcie tego czasem! Po zagrzaniu magicznego wywaru musimy pozostawić go do ostudzenia - najlepiej do temp. ok. 40-50º C. Jeśli na raz wlejemy rozgrzaną wodę z miodem, to możemy zniszczyć dymion! Po przelaniu całości do dymiona i ostudzeniu do temperatury ok. 30º C możemy wlać drożdże, dodać kwasek cytrynowy i dosypać resztę pożywki dla drożdży. Dymion zatykamy korkiem ze specjalną rurką do fermentacji. Rurka powinna być wypełniona wodą tak, aby mógł przez nią uciekać dwutlenek węgla, a do dymiona nie mogła dostać się żadna muszka owocówka. Jeśli nie odprowadzimy CO₂, to może się okazać, że za parę tygodni będziemy musieli nasze dzieło sprzątać ze ścian pomieszczenia, w którym stał dymion. Natomiast, jeśli do naszego dzieła dobiorą się muszki owocówki, to zamiast wina otrzymamy... ocet.

I czekamy... Przez pierwszy miesiąc potrwa najintensywniejsza fermentacja. W dymionie pojawi się piana i będą się wydzielały duże ilości dwutlenku węgla. Dobrze by było, gdyby dymion znajdował się w stałej temperaturze od 26 do 28º C. Nie powinno świecić na niego także Słońce. Po skończonym procesie fermentacji możemy zacząć powoli zlewać wino. Przygotowujemy drugi dymion i do niego za pośrednictwem np. rurki paliwowej zlewamy naszą radosną twórczość. Na dnie dymiona w którym trwała fermentacja znajdzie się duża ilość syfu z miodu. Po to stosujemy wężyk, żeby ten syf można było wywalić. Zlewać nasze wino będziemy jeszcze 2-3 razy. Za każdym razem pozbywając się osadu. W momencie, gdy nasze wino będzie całkowicie przezroczyste, możemy je rozlać do butelek i zacząć powoli konsumować.

Smacznego!

Bitwa o Bochnię

2009-09-05T19:46:00.008+02:00

Zdjęcia nie wymagają komentarza.

Z aparatem po Krakowie

2009-08-20T22:32:00.005+02:00

Tym razem ograniczymy się z tekstem do minimum. Miłej zabawy przy oglądaniu zdjęć.

Kraków, scena kameralna Teatru Starego przy ul. Starowiślnej, schody prowadzące na piętra budynku.

Schody

Tym razem zaciekawił mnie układ schodów w budynku Teatru Starego. Spirala od góry oświetlona półprzezroczystym dachem, barwiącym światło na charakterystyczny, żółtawy odcień. W zaistniałej sytuacji aparat nie upierał się, aby za pomocą balansu bieli "wybielać" rzeczywiste kolory.

Widok na Rynek Główny

Czerń i biel oraz wszystkie odcienie szarości

Lekko przepalony obraz ludzi na tle Sukiennic. Warto też zwrócić uwagę na kształty ułożone z kostki.

Widok na Kościół św. Barbary z Rynku głównego.

Ładne kolorki i błąd kadrowania

Ładnie podświetlona promieniami słońca fasada budowli. Mało ludzi na pierwszym tle i kawałek dachu Kościoła Mariackiego z lewej strony zdjęcia.

Fototułaczka po Bochni - część 2

2009-08-05T15:23:00.002+02:00

Czytając poprzednią część wpisu poświęconego fotograficznym wędrówkom po Bochni i okolicach można zadać sobie pytanie: skąd w ogóle wziął się taki pomysł? Przygotuj sobie coś do picia i jedzenia, bo to kawałeczek historii.

Pierwszy poważniejszy kontakt z fotografią miałem w III klasie gimnazjum. Wtedy to udało mi się zdobyć działający, przeszło trzydziestoletni aparat Zenit 12 XP. Mała, czarna puszka z dokręcanym z przodu obiektywem przywieziona przez moją babcię z nieistniejącego dziś ZSRR przeleżała w garażu mojego wujka ponad 10 lat. Na pierwszy rzut oka nic szczególnego. Od strony technicznej także nie zachwycał. Dysponując zaledwie prostym światłomierzem oraz czasami otwarcia migawki o wartościach 1/30s, 1/60s, 1/125s, 1/250s oraz 1/500s plus tryb bulb (migawka otwarta tak długo jak długo trzymasz wciśnięty spust) nie pozwalał na wiele. Jednak miał tą miłą właściwość, że dużo wymagając wiele uczył. Wszystkie parametry zdjęcia należało ustawić własnoręcznie, a swój wybór potwierdzić za pomocą światłomierza. Oprócz tego człowiek nie miał zbyt wiele wolności - tylko jedna kombinacja czasu i przysłony dawała poprawnie naświetlone zdjęcie, a to z kolei uniemożliwiało zabawy z głębią ostrości. Z tamtego okresu pozostał mi w pamięci rozmiar wizjera. Wielki, jasny, czytelny, na którym ustawianie ostrości było proste, wygodne i precyzyjne. Muszę przyznać, że brakuje mi tego w dzisiejszym sprzęcie nastawionym na działanie w trybie autofocus.

Mając już aparat mogłem w końcu robić zdjęcia. Pierwszy wydatek: klisza. Dziesięć złotych na najtańszą fototaśmę i w drogę. Pozostawało pytanie: kiedy się w to bawić? W dzień człowiek ma dużo obowiązków i zajęć, pozostaje zatem noc. Na dodatek zdjęcia nocne, głównie dzięki wyeksponowaniu za pomocą sztucznego oświetlenia, są zdecydowanie bardziej efektowne. Mając już wszystko, co do szczęścia potrzebne którejś nocy wyruszyłem z Zenitem w plecaku na ulice Bochni, aby próbować cokolwiek uchwycić. Od tego się zaczęło, potem były długie eksperymenty z aparatem cyfrowym - wtedy prostym kompakcikiem, aby w końcu dotrzeć do nieco egzotycznego aparatu średnioformatowego, za pomocą którego udało się nam zrobić kalendarz. Ciepłe przyjęcie moich prac oraz zabawa, która zawsze towarzyszyła wszystkim wędrówkom zachęciła mnie do dalszego rozwijania zainteresowań i unowocześnienia posiadanego zaplecza sprzętowego. Jaki będzie skutek? Ciężko dzisiaj ocenić, a jakiekolwiek sensowne wnioski będzie można wyciągać dopiero za kilkanaście lat.

Napisałem, że wycieczkom towarzyszyła dobra zabawa. Zrobienie każdego zdjęcia pochłaniało kilkanaście minut, w czasie których należało znaleźć dobry obiekt do zdjęcia, umiejętnie go wykadrować, ustawić wszystkie potrzebne parametry aby w końcu nacisnąć spust migawki i zrobić zdjęcie. Gdy chodziłem sam, zabawa polegała głównie na tym, że człowiek ruszał się na świeżym powietrzu oraz podziwiał piękno swojego miasta. Gdy chodziłem z jakimś towarzystwem, to koncentrowaliśmy się na zrobieniu jak najlepszego zdjęcia.

Fototułaczka po Bochni - część 1

2009-08-05T01:34:00.008+02:00

Środa, godzina 1:35.

Właśnie wróciłem z nocnego spaceru po Bochni i zabieram się za pisanie tego wpisu. Przez ponad dwie godziny tułałem się po rodzinnym mieście z aparatem w plecaku i statywem w ręku, szukając czegoś ciekawego do fotografowania. Przez ostatnie dwa tygodnie nazbierało się parę fotografii, niektóre z nich umieszczone zostały na Wikimedia Commons i reklamują Bochnię. Jednak zdecydowana większość moim zdaniem nie nadaje się do internetowej encyklopedii, a lepszym miejscem jest umieszczenie ich na blogu wraz z krótkim komentarzem. Zatem do dzieła. Przy każdym zdjęciu znajduje się zbiór argumentów za i przeciw umieszczeniu go na Wikimedia Commons. Wpis można potraktować jak ilustrowany przewodnik "czego unikać na zdjęciu" szczególnie wysyłanym na Wikipedię.

Tablica w I LO upamiętniająca nauczycieli prowadzących tajne nauczanie w okresie II wojny światowej.

Co jest źle?

Niezbyt porywające ujęcie

Odbicie aparatu i mnie samego w tablicy

Słaby temat na zdjęcie - nawet jeśli ma ono trafić do encyklopedii

Co jest dobrze?

W miarę dobrze ustawiony aparat - zdjęcie trzyma pion

Balans bieli sprawił, że tablica ma naturalne kolory

Tablica jest ustawiona w doskonałym miejscu na zdjęciu

Obelisk poświęcony pamięci malarza Marcina Samlickiego. Znajduje się on niedaleko miejsca jego śmierci.

Co jest źle?

Napis na tablicy jest mało czytelny z tej perspektywy, z kolei w kadr niepotrzebnie wdarła się roślinność w lewym dolnym rogu zdjęcia

Zdjęcie można było wykonać o innej porze roku i/lub dnia

Co jest dobrze?

Perspektywa wymuszona przez tło. W tym przypadku drzewo, niebo i niskie domki na linii horyzontu rażą mniej niż blisko położone blokowisko

Kapliczka na Murowiance.

Co jest źle?

Lecące piony, widoczne chociażby na liniach bocznych drzwi

Zdjęcie ma znikomą wartość informacyjną

Co jest dobrze?

Tryb czarno-biały dodał zdjęciu nieco powagi

Komin przy szybie Campi.

Co jest źle?

Zdjęcie komina kopalnianego z takiej perspektywy na Wikipedii? Litości...

Trochę fikuśnie wyszła ostrość, która koncentruje się na bliżej położonej części komina

Użycie tutaj trybu czarno-białego jest akurat przesadą. Naturalny kolor komina w połączeniu z kontrastującym kolorem nieba byłby ciekawszą kombinacją.

Co jest dobrze?

Perspektywa zbieżna podkreśla rozmiary budowli i sprawia, że odbieramy ją jako coś potężnego w stosunku do oglądającego

Chrzcielnica w kościele św. Pawła w Bochni

Co jest źle?

Błąd kadrowania. Za dużo posadzki na dole, za mało miejsca nad krzyżem. Akurat jest to wina mojego wzrostu (a raczej jego braku)

Zdjęcie ma za duży kontrast. Mogłoby być trochę "delikatniejsze"

Zła pozycja do robienia zdjęcia. W tym przypadku korzystniej byłoby wykorzystać ławki za chrzcielnicą jako tło.

Co jest dobrze?

Aparat ustawiony prostopadle do ścian. Efekt: brak lecących pionów

Chyba pierwszy raz do końca zapanowałem nad kolorystyką zdjęcia w trudnych warunkach oświetleniowych (kościelny półmrok)

Kaplica Matki Boskiej w kościele Św. Pawła w Bochni.

Co jest źle?

Witraż się lekko zgiął

Zdjęcie kończy się niemal na samym klęczniku

Postać Maryi jest niepokojąco nieostra. Wygląda na to, że aparat skoncentrował się na ścianie z tyłu

Co jest dobrze?

Kolorystyka. Może niektórych razić, ale co do jednego jestem pewien: użycie tutaj trybu czarno-białego byłoby zbrodnią

Czytelność zdjęcia. Chyba nikt nie ma wątpliwości co przedstawia zdjęcie (w przeciwieństwie do komina, który na pierwszy rzut oka jest trudny w interpretacji)

Środa, godzina 3:35

Po małej dawce grafiki czas na kilka zdań tekstem. Na początku warto wyjaśnić skąd idea robienia zdjęć o tak nieludzkiej porze jak chociażby 1:00 w nocy. Otóż noc całkowicie opróżnia miasto z ludzi i samochodów. Dzięki temu w ogóle da się zrobić zdjęcia pewnym miejscom, które przez cały dzień są czymś zasłonięte. Dla osób, które nie lubią ciemności, a zdjęcia wolą pstrykać przy świetle dziennym, polecam poranki (zwłaszcza w lecie). O 5:00 rano nie ma tłoku, a jest już jasno. Kolejnym powodem jest światło. Podświetlanie tematu fotografii po pierwsze usuwa całe, nieraz zbędne, tło, a oprócz tego jest efektowne.

Jak ja robię zdjęcia dla Commons?

Lista zasad, którymi warto kierować się, robiąc zdjęcia na potrzeby np. encyklopedii.

Starajmy się, aby zdjęcia jak najdokładniej przedstawiały rzeczywistość. Najlepiej, gdy zdjęcie niewiele różni się od tego, co widzimy własnymi oczami. W tym punkcie warto też wspomnieć o wszelkiego rodzaju efektach specjalnych. HDR jest ciekawą techniką, ale lepiej używać ją w sytuacjach ekstremalnych, np. fotografując ciemne wnętrze z oknem przez które wpada światło. Nie przesadzajmy z saturacją jeśli w rzeczywistości nie będzie można zobaczyć tych kolorów gołym okiem w żadnych warunkach oświetleniowych.

Odpuśćmy poprawki. Nie wymazujmy żadnych elementów na zdjęciu i nie dodawajmy niczego, co burzy stan rzeczywisty. Zdjęcie jako takie nie wymaga także ramki czy też innej oprawki. Tego typu dodatki są potrzebne dopiero po wywołaniu zdjęcia do postaci papierowej.

Pilnujmy jakości. W dobie wszechobecnych aparatów w telefonach komórkowych musimy pamiętać, że wyższą jakość obrazu możemy uzyskać ze starego analogowego aparatu na kliszę formatu 35mm niż z większości aparatów w telefonie, a nawet dużej części aparatów kompaktowych. Jeśli nie posiadasz profesjonalnej cyfrowej lustrzanki, a koniecznie chcesz się bawić w fotografię, to zainwestuj w tani, używany sprzęt analogowy, naucz się nim robić zdjęcia, a dopiero później szukaj czegoś bardziej zaawansowanego. Pamiętajmy też o tym, że niektórzy ludzie chcieliby zrobione przez nas zdjęcia powiesić chociażby na ścianie u siebie w domu. Dbajmy o to, aby nasze zdjęcie wyglądało tak samo dobrze w formacie 15x10cm jak i dwa razy większym.

Nie niszcz tego, co fotografujesz. Żaden człowiek nie lubi, gdy z odległości zaledwie 1 metra ktoś strzela mu bez opamiętania fleszem po oczach. Większość zabytków, zwłaszcza obrazów jest bardzo wrażliwa na ostre światło, które może go niszczyć. Jeśli tylko Twój aparat ma funkcję wymuszenia braku błysku, to używaj jej wszędzie tam, gdzie użycie flesza nie jest niezbędne.

Zostaw coś w zamian. Fotografowałeś kogoś? Może chciałby otrzymać swoje zdjęcie? Zaoferuj mu to, a następnym razem z pewnością będzie z radością dla Ciebie pozował, zwłaszcza, gdy spodoba mu się Twoja praca. Fotografujesz w zabytkowych miejscach, które potrzebują pieniędzy na remonty i utrzymanie? Jeśli tylko możesz zostawić nawet drobną sumę, to zrób to, aby także i inni mogli w tym miejscu robić zdjęcia po Tobie.

Zaskakuj! Zdjęcie nie musi być nudne. Ciekawa kompozycja zdjęcia, niekonwencjonalne ujęcie oraz inne elementy, jakimi możesz przyciągnąć uwagę oglądającego są dobre o ile tylko nie powodują utraty wartości dokumentalnej.

Canonier

2009-07-14T20:33:00.003+02:00

Początek tego wpisu poświęcę na krótki opis zakupu obiektywu do mojego aparatu, który wbrew pozorom wcale nie był czynnością prostą. Czwartek, 9 lipca. Na terenie Krakowa odwiedziłem dwa sklepy zajmujące się profesjonalnym wyposażeniem dla fotografów. W obu poinformowano mnie, że "obiektywu nie ma i nie wiadomo kiedy będzie". Przyznam się szczerze, że pierwszy raz w życiu na terenie mojego kraju zdarzyła mi się taka sytuacja, że przychodzę z kieszeniami wypchanymi kasą, a sprzedawcy jakoś się tym nie interesują. Trudno, szukamy dalej. Wieczorem odnajduję sklep w Sopocie, oferujący ten sprzęt 200 PLN taniej. W piątek (10 lipca) dowiaduję się, że i tam sprzętu nie ma i nie wiadomo, kiedy będzie. W międzyczasie szybki telefon do Warszawy, a później 4 kolejne do Krakowa. Efekt: Foto Nova - sprzętu brak, Saturn w galerii krakowskiej także. Ciekawostka: sprzęt ma Media Markt, ale droższy o drobne 400 PLN, co szybko leczy mnie z idiotycznego skądinąd pomysłu zakupów tamże. Odwiedziny na Allegro - jest obiektyw w tej samej cenie, co w Sopocie. Sprzedawca utrzymuje, że sprzęt jest na stanie. Ponieważ jest to zakup przez Allegro więc rozpoczynam śledztwo w sprawie wiarygodności sprzedawcy. Szybko natrafiam na forum, gdzie sprzedawca de facto sam podważa własną wiarygodność, co wstrzymuje mnie od zakupu od niedzieli. W niedzielę, po krótkich konsultacjach decyduję się na zakup. Przesyłka jest ekspresowa - obiektyw we wtorkowe południe jest już podpięty pod mój aparat i mogę zaczynać zabawę w zdjęcia.

A teraz odnośnie samego obiektywu: zakres ogniskowej wynoszący od 17 do 40mm po pomnożeniu przez 1.6 daje typowy standardowy zoom (nawet określiłbym go jako szerokokątny). Maksymalny otwór przysłony na poziomie F/4 nie jest jakoś szczególnie porywający. Wykonanie obiektywu nie budzi jakichkolwiek zastrzeżeń. Obiektyw miło leży w ręce, sprawia wrażenie solidnego. Niemiłą rzeczą jest rozmiar osłony przeciwsłonecznej, ale to akurat da się zmienić gdy tylko znów zacznę cierpieć na nadmiar gotówki. Obiektyw ma kilka ciekawych cech, które prędzej czy później mi się przydadzą. Oto niektóre z nich: całkowite uszczelnienie przed wodą i kurzem (tylko filtr trzeba dokupić), autofocus typu USM - tutaj zaczyna się historia. Otóż aparat wziął do ręki mój wujek zaczął się nim bawić a ja wpadłem w panikę, bo "autofocus nie działa". Dźwięk wydawany przez obiektyw w trakcie ustawiania ostrości jest tak cichy, że stojąc 1.5 obok nie byłem w stanie go wychwycić. Ponoć wszyscy ludzie przesiadający się z obiektywów nieposiadających USM na obiektywy weń wyposażone dają się tak nabierać. Wracając do tematu, obiektyw ma słuszną masę i gabaryty, co umila pracę - dzięki temu aparat jest lepiej wyważony i ręce jakoś mniej się telepią. Jakość zdjęć - nieporównywalna ze wszystkim, co miałem w rękach. Nie zauważyłem nigdzie śladu aberracji chromatycznej, choć dokuczała mi trochę niska rozdzielczość obiektywu. Pomimo tego drobnego szkopułu, zdjęcia można ocenić na 5+.

A teraz idę pstrykać dalej - pa ;)

Django

2009-06-09T00:42:00.007+02:00

Dzisiaj oderwę się od spraw przysprzętowych i co nieco poopowiadam o frameworku do tworzenia stron internetowych w języku Python. Mowa będzie oczywiście o Django.

Trochę historii

Python jako język programowania powstał na początku lat 90. Został dość dobrze przemyślany, a reguły gramatyczne wprost wymuszają na programiście pisanie czytelnego kodu. Do tego, podobnie jak np. Ruby, jest językiem wysoce wymownym¹, dzięki czemu można bardzo łatwo tworzyć w nim nawet duże projekty. Pierwsze spotkanie z nim nastąpiło kilka lat temu. Na początku nie wzbudził mojej większej sympatii, lecz dzisiaj jest językiem używanym przeze mnie niemal do wszystkiego.

Pierwsze strony www tworzyłem oczywiście w PHP, jednak widząc, jak wielki nakład pracy trzeba wkładać w napisanie nawet najprostszej strony www szukałem rozwiązań alternatywnych. Początkowo spotkałem się z frameworkiem Ruby on Rails. Sprawiał on wrażenie eleganckiego, jednak to, co mnie bardzo zniechęciło, to jego szybkość działania. Podobno do dziś sam interpreter Rubiego oraz cały framework poczyniły znaczny postęp i dzisiaj wręcz zachwycają szybkością działania. Jednak nie lubiąc specjalnie czekać na takie przełomy zdążyłem się przekwalifikować, poznać moc Pythona oraz zasmakować Django. I zostałem przy nim.

Do rzeczy

Zacznijmy od tego, że w Django nie tworzymy serwisów www w taki sposób, jak czyniliśmy to przy użyciu PHP. Serwer www nie uruchamia tutaj poszczególnych plików z rozszerzeniem .py jak czyni to w przypadku w/w rozwiązania. Można śmiało zaryzykować stwierdzenie, że w Django tworzymy cały program komputerowy. Jednak wprowadzimy tutaj nieco inne nazewnictwo. Kompletny kod serwisu zawarty jest w projekcie, czyli zbiorze aplikacji. Czym zatem jest aplikacja? Jest moduł, swego rodzaju "cegiełka" z której budujemy projekt. Moduły są przenośne między projektami², więc raz dobrze napisany moduł może być przez nas używany w wielu różnych projektach. Każdy moduł składa się z następujących składowych:

pliku views.py - czyli kodu napisanego w języku Python zawierającego funkcje, odpowiadającego w pewnym przybliżeniu pojedynczemu plikowi .php.

pliku urls.py - w nim zawarte są informacje jak ma wyglądać url, prowadzący do określonej funkcji z pliku views.py

pliku models.py - tutaj zawarte są definicje klas, które dzięki ORM są reprezentowane w bazie danych jako tabele. Dzięki temu w aplikacji pojedynczy wiersz danych z tabeli jest reprezentowany jako instancja klasy. Piszemy cały czas w Pythonie i nie przejmujemy się wcale kodem SQL, który ukryty jest w ORM>

Są to oczywiście tylko wybrane pliki - może być ich znacznie więcej i mogą przechowywać inne, bardziej zaawansowane elementy. Pytanie tylko: gdzie podział się kod html?

Kod html ukryty jest w tzw. szablonach, czyli plikach, gdzie zawarty jest szkielet html strony. Ponadto kod ten zawiera znaczniki, które są uzupełniane przez ładowarkę szablonów wartościami, które generuje kod zawarty chociażby w pliku views.py. Połączenie kodu html ze zmiennymi z plików views.py daje nam już kompletny kod html z treścią.

Dlaczego to jest takie dziwne?

Zauważmy, że dzięki takiemu "rozbiciu" elementów frameworka, ludzie pracujący nad samym kodem poszczególnych aplikacji nie muszę przejmować się wcale kodem html i css. Oni po prostu udostępniają pewnego rodzaju API, z którego korzystają później twórcy szablonów tworząc odpowiedni kod html, css oraz całą otoczkę graficzną. Zatem ekipa programistów może nie mieć zielonego pojęcia o html-u, a graficy w ogóle nie muszą znać Pythona, aby móc wspólnie łatwo i szybko stworzyć kompletny serwis. Do tego, ani jedni ani drudzy nie muszą znać nawet SQL-a, gdyż ORM załatwia za nich wszystko.

Brzmi zachęcająco, ale...

Użycie tego frameworka jest kłopotliwe z trochę innych względów. Oto niektóre problemy:

nierozwinięty hosting pod projekty

kłopotliwa konfiguracja na komputerze developera

Ponadto, korzystając z Django trzeba być dość dobrym programistą i dobrze znać Pythona. Użycie Django wymusza na nas pisanie kodu w określony sposób, bez swoistych "improwizacji" znanych z PHP. W zamian dostajemy stabilny framework, rozpowszechniany na bardzo liberalnej licencji (BSD), który umożliwia szybkie tworzenie projektów.

Do czego zachęcam?

Do spokojnego zapoznania się z frameworkiem. Dostępna do niego bardzo bogata dokumentacja z pewnością ułatwi pierwsze kontakty. Dla osób, które koniecznie chcą stosować serwer Apache dodam, że sam stosuję Nginx i bardzo go sobie chwalę (głównie za szybkość).

Do czego nie zachęcam?

Do szybkiego zniechęcenia się. Naprawdę warto poświęcić trochę czasu na poznanie języka i całego frameworka.

Ciekawostki

W Django dostępny jest bardzo elegancki i potężny panel administratorski, który może obejmować swoim zasięgiem każdą aplikację w projekcie. Jest to bardzo wygodne rozwiązanie, które odciąża programistę, zajętego tworzeniem kodu pod "front" serwisu od myślenia o sprawach związanych z kwestiami administracyjnymi. Panel administratora jest także dość łatwo modyfikowalny oraz umożliwia stosowanie mechanizmu uprawnień.

Django, a właściwie sam Python udostępnia bardzo elegancki mechanizm przechwytywania błędów. Można za jego pomocą przechwytywać nawet błędy składniowe. Dzięki temu można o wszystkich błędach w działaniu serwisu informować drogą np. mailową administratorów.

Sam framework oferuje ciekawe podejście do backupu danych. Można je zrzucić chociażby do prostego pliku XML. Oczywiście jest ono mało przydatne w przypadku działającego serwisu, jednak w pracach developerskich potrafi bardzo umilić życie. Dzięki temu samemu mechanizmowi programiści tworzący aplikacje mogą udostępniać dane startowe, zawierające "niezbędne minimum" dla funkcjonowania danej aplikacji w obrębie projektu.

Framework umożliwia łatwe tworzenie aplikacji wielojęzycznych. Moduły aplikacyjne mogą zawierać pliki tłumaczeń na wiele różnych języków, jednak muszą być one tworzone przez człowieka. Niemniej jednak, bardzo ułatwiają tworzenie wielojęzycznych projektów.

Przypisy

Wymowność języka rozumiem tutaj jako ilość kodu potrzebnego do osiągnięcia jakiegoś konkretnego efektu. Im ta ilość mniejsza, tym język jest wymowniejszy.

A przynajmniej dobrze napisane aplikacje powinny być przenośne.

Walczymy z m-spamem

2009-04-28T10:18:00.007+02:00

W ostatnich dniach do białej gorączki doprowadziły mnie firmy, których głównym celem jest zarabianie pieniążków na idiotach korespondujących za pośrednictwem sms-ów z komputerami tychże firm na tematy najczęściej... seksualne. Jako że wczoraj otrzymałem od któregoś z komputerów takiej firmy sms-a, w którym ta maszyna przedstawiała się jako "28-latka bez zobowiązań", to postanowiłem, delikatnie mówiąc, ukrócić proceder. Powstał z tego kod: sms.py.


import inbox, appuifw, e32, re

app_lock = e32.Ao_lock()
box = inbox.Inbox()

def spam_message(adr, cont):
 if re.match('[0-9]{4,5}', adr): return True
# if 'pln' in cont.lower(): return True
 return False

def message_received(msg_id):
 box = inbox.Inbox()
 sms_text = box.content(msg_id)
 address = box.address(msg_id)
 print "Received new sms"
 if spam_message(address, sms_text): 
  box.delete(msg_id)
  appuifw.note(u"Deleted sms from: " + address,"info", 1)

def exit_key_handler():
 app_lock.signal()

appuifw.app.exit_key_handler = exit_key_handler
box.bind(message_received)

print "Waiting for new SMS messages.."
app_lock.wait()
print "sms-filter closed"

Jeśli macie telefon z Symbianem, to zainstalujcie odpowiednią wersję PyS60 i możecie cieszyć się tym programikiem do woli. Dla nieznających języka Python krótkie wyjaśnienie. Program reaguje na każdą wiadomość, którą otrzymuje wasz telefon. Następnie ocenia, czy nadawcą sms-a jest numer 4-ro lub 5-cio cyfrowy (najczęściej takie numery służą do rozsyłania spamu). Uwaga: sms-y pochodzące z bramek smsowych także będą usuwane! Jeśli chcecie przerobić program pod siebie, to PROSZĘ BARDZO. Kod jest na licencji beer-ware.

Fotograficzne obserwacje

2009-04-03T01:18:00.004+02:00

Obiecałem niedawno podzielenie się dalszymi obserwacjami dot. mojego aparatu, więc słowa dotrzymuję. Oto dalsze obserwacje:
- wymagania dot. obiektywu niestety się potwierdzają - posiadany przeze mnie "kitowy, plastikowy" EF 90-300 F4.5/5.6 daje niezbyt ostry obraz. [Z racji braku pod ręką obiektywu standardowego 50mm F/1.8 lub F/1.4 nie przeprowadziłem testów porównawczych.]
+ szybkość i precyzja działania bardzo umila fotografowanie. Naprawdę brakowało mi tego w Zenicie.
+ Aparat jest dość dobrze wyważony, nie męczy człowieka w trakcie pracy.
+ W porównaniu do 50D moja 40D ma zdecydowanie lepszą jakość zdjęć przy wysokich ISO (powyżej ISO 1600).

Za niedługo będzie okazja przekonać się, jak działa połączenie EOS 40D z EF 17-40 F/4 L. Zapowiada się niezwykle interesująco ;-).

No to się porobiło

2009-03-15T23:02:00.004+01:00

Dożyłem czasów, w których drugi telefon, który używam w swoim życiu jest szybszy od pierwszego komputera, którego używałem. Co gorsza, telefon ów umożliwia uruchamianie programów napisanych w Pythonie. Bez jakiejkolwiek prekompilacji. Ot tak, czysta interpretacja pliku tekstowego. Żeby było weselej mam do dyspozycji konsolę interpretatora. Aż zatęskniłem za Commodore 64.

Mojemu wujkowi, w ciągu pięćdziesięciu paru lat życia świat stanął na głowie dobre kilka razy. Ja właśnie doświadczyłem pierwszego przewrotu: 2.4 kg brutto laptopa jest w tym momencie równie funkcjonalne programistycznie, co 0.1 kg zwykłej komórki. Jest i plus całej sytuacji: będę mógł produkować soft do obliczeń na potrzeby sprawozdań z fizyki na bieżąco w trakcie laboratoriów :P.

Podsumowując: komórka umożliwia mi zrobienie praktycznie takich samych rzeczy, do których potrzebowałem dotychczas dobrego kawałka komputera. Nie chcę wiedzieć, co będą mogły urządzenia moich dzieci...

Studia? Niezła rzecz!

2009-01-27T21:09:00.003+01:00

Jestem na półmetku pierwszego roku, a to uprawnia mnie do napisania kilku refleksji nt. studiów. Cóż zatem mogę powiedzieć?

Po pierwsze: na studiach wcale nie jest jakoś super ciężko. Nie można leżeć do góry tyłkiem, ale z drugiej strony - nie zarywam nocy nad matematyką (chociaż mógłbym a wręcz powinienem chcieć to robić). WDI jest prostsze niż prowadzący groził. Algebra, dzięki świetnemu prowadzącemu ćwiczenia była całkiem bezbolesna, analiza i elektronika także. Co ciekawe, każdy z tych przedmiotów przynosił nie tylko wiedzę z danej dziedziny. Oprócz tego była to także bardzo ciekawa lekcja życia wśród innych ludzi, głównie starszych i lepiej wykształconych. Nikt na siłę nie wciskał studenta do kanału, a z drugiej strony - swoją wiedzą i stosunkiem do nas nabywał szacunku z naszej strony.

Czego się dowiedziałem? Otóż wiem już, co ludzie z wyższym wykształceniem wspominają z okresu swoich studiów.

Optymalizacje C

2008-12-11T00:51:00.007+01:00

Dzisiaj omówię problem optymalizacji. Jako przykład podam projekt ze studiów - szukamy 10-cio cyfrowych liczb Armstronga (a dokładnie jednej takiej liczby ;)). Dodam jeszcze, że aby usprawnić proces poszukiwań nieco zawężyliśmy zakres poszukiwań. Podam 4 przykłady kodów źródłowych z komentarzem i czasami wykonania.

Skupmy się zatem na samym kodzie. Zaczniemy od programu najwolniejszego. Wdi3 ma tą przykrą własność, że ma zarówno zbyt dużo odwołań do pamięci, jak i zbyt wiele pętel. W głównej pętli, sprawdzającej kolejne liczby wykonujemy pętlę, która sumuje 10-te potęgi cyfr. Jest to zupełnie niepotrzebne. Wdi2 pozbywa się dodatkowej pętli, jednak zauważamy tutaj zbyt wiele odwołań do pamięci. Eliminujemy tę wadę w programie wdi1. I z punktu widzenia algorytmicznego nie pozostaje nam już nic innego do poprawy. Spójrzmy teraz na osiągi programów, pracujących od zakresu 4600 000 000 do poszukiwanej liczby.


kjopek@student:~ (150) > time ./wdi3
Start at: 4600000000
4679307774
9.95u 0.00s 0:10.04 99.1%
kjopek@student:~ (151) > time ./wdi2
Start at: 4600000000
4679307774, 4679307774
8.68u 0.00s 0:08.72 99.5%
kjopek@student:~ (152) > time ./wdi1
Start at: 4600000000
4679307774, 4679307774
8.02u 0.00s 0:08.07 99.3%
kjopek@student:~ (152) >

Wygląda cudnie - udało nam się obniżyć czas wykonania tego samego programu z poziomu ponad 10 sekund do niewiele ponad 8 sekund. A czy dałoby się go obniżyć jeszcze bardziej? Algorytmicy pewnie powiedzą, że nie, jednak mamy jeszcze małą sztuczkę w zanadrzu. Otóż procesor bardzo nie lubi odwołań do pamięci. Spróbujemy zatem dwie najczęściej powtarzające się zmienne umieścić w rejestrach procesora. W przypadku architektury AMD64 (i EMT_64T) będzie to łatwe - dysponujemy przecież 8 nowymi rejestrami ogólnego przeznaczenia. Wdi.c jest kolejnym stopniem optymalizacji. Co otrzymujemy?


kjopek@student:~ (153) > time ./wdi
Start at: 4600000000
4679307774, 4679307774
3.30u 0.00s 0:03.35 98.5%
kjopek@student:~ (154) >

Efekt mówi sam za siebie. Po analizie kodów tych wszystkich programów nasuwa się parę pytań, np. dlaczego w programie, wykonującym dwukrotnie więcej odwołań do pamięci oraz dodatkową pętlę czas wykonania jest dłuższy tylko o 2 sekundy, podczas gdy prosta optymalizacja przeniesienia zmiennej do rejestru skraca czas o 2/3?

Wszystkie próby wykonywane były na serwerze student.agh.edu.pl, przy użyciu kompilatora GCC 3.4.3 z opcją -m64. System: Solaris 10, 4 procesory Opteron 875 Dual Core 2.2 GHz, 16 GB RAM-u.

Odkrywanie tajemnic 40-stki - c.d.

2008-11-11T22:15:00.004+01:00

Składając się coraz bardziej do dalszego tworzenia pewnego autorskiego portalu, doszły mnie ciekawe newsy o możliwości mojego świeżo zakupionego aparatu. Otóż przystawka WFT-E3 umożliwia podpięcie do niego zewnętrznego dysku, a także odbiornika GPS przez USB! Jest to o tyle przyjemne, że byłoby to bardzo ciekawe urozmaicenie funkcjonalności serwisu, dodające dokładne miejsce na kuli ziemskiej, gdzie dana fotografia została zarejestrowana.

Jednak, jak każde rozwiązanie i to ma swoje minusy: cena WFT-E3 oscyluje wokół 3000 PLN, za które z pewnością miałbym świetnej klasy obiektyw.

Co nam pozostaje? Dwa wyjścia: jedno polega na noszeniu ze sobą niezależnego odbiornika GPS i dopisywaniu danych do gotowych plików. Tutaj zamieszczam opis tagów EXIF, jakie mogą się przydać:
exif 2.2.

Druga opcja to arcymistrzostwo elektroczniczno-programistyczne, polegające na użyciu wbudowanego gniazda USB do transmisji danych. Jednak to raczej na pewno nie wypali, po pierwsze dlatego, że komunikacja USB jest hierarchiczna, a aparat jest tylko "odbiornikiem" i nie może pełnić funkcji hosta, a po drugie - nie za bardzo wiadomo jak poprawić firmware i oprogramowanie aparatu.

Wniosek: za 3000 PLN miałbym około 1115 butelek mojego ulubionego piwa. Nie zamienię tego na durnowatą opcję dodawania do zdjęcia informacji o położeniu.

Canon w rękach kj

2008-11-10T01:19:00.006+01:00

Po długim oczekiwaniu połączonym ze zbieraniem pieniędzy udało mi się zakupić w końcu cyfrową lustrzankę. Oceniając plusikiem i minusikiem, po krótkim i mało wnikliwym teście wyszło, co następuje:
- przy czułości powyżej ISO 800 aparat jest średnio użyteczny bez funkcji odszumiania. Dotyczy się to tylko długich czasów naświetlania. Przy krótkich czasach naświetlania wszystko jest w granicach rozsądku.
+ nocna sesja przy czułości ISO 100 - 200 pokazała, że aparat nie szumi przy niskich czułościach i długich czasach naświetlania
+ aparat bez problemu współpracuje z polskimi lampami błyskowymi z lat 70.
+ wygoda użytkowania aparatu jest niesamowita (wliczamy w to tempo działania)
- wymaga obiektywu. Dobrego obiektywu. Drogiego i dobrego obiektywu (mówimy o Zoomie). No, chyba, że temu, którego akurat mieliśmy zaszkodził piasek z plaż Chorwacji.
+ liczba opcji konfiguracyjnych jest na przyzwoitym poziomie (- do tego stopnia, że można się w nich zgubić)
- za 2300 PLN oczekiwałem większych rewelacji. Live view to fajny bajer, ale bajer. Może tak w tej cenie lepiej byłoby dopieścić matrycę?
+ 10 mpix za tą cenę to przy tym rozmiarze matrycy rozsądna kombinacja ceny, możliwości i jakości (na 9 mpix powstawały wydruki 70x50 cm o wysokiej jakości)
- najciekawsze jest to, że jedną z głównych wad tego aparatu przy użyciu statywu jest pozycja wyłącznika, który przy szerokiej podstawie mocującej do statywu czasami bywa trudnodostępny
+ 1000 zdjęć na baterii i 1300 zdjęć na karcie to rozsądna ilość
+ masa zbliżona do Zenita bardzo umila migrację na cyfraki
- pod względem jakości zdjęć średnioformatowy Kiev nadal pozostaje poza zasięgiem Japońskich elektryków
+ ekonomicznie Kiev nadal pozostaje poza zasięgiem budżetu kj
+ autofokusa, nawet przy nienajlepszym oświetleniu nie można się doczepić
- rozstawienie przycisków może nie być najwygodniejsze dla osób o małych dłoniach (+ to niech sobie kupią coś mniejszego)
- domyślnie włączona funkcja automatycznego czyszczenia matrycy opóźnia start (+ da się to wyłączyć)
+ profil korpusu spodobał się moim dłoniom. Plastik i guma są przyjemne w dotyku, aparat nie zniechęca do używania. Magnezowy korpus daje miłe poczucie solidności aparatu. Nie będę jednak używał tego sprzętu do oceny jakości wykonania płyt chodnikowych.
+ joystick wbrew wielu recenzjom wcale nie okazał się taki niemiły.
+ ekran LCD oddzielony jest jakąś plastikową szybką od użytkownika - nie zgniecie się tak prędko, jak kompakcik mojej kuzynki
- zdążyłem się kilka razy zaplątać w pasek na szyję. Problemy były przejściowe i niegroźne, chwilowe połączenie ze statywem węzłem paskowym przyjemne może nie było, ale nie pozostawiło trwałych uszkodzeń ciała i psychiki
- dla osoby, która nie używa Canonowskich lustrzanek na co dzień przyzwyczajenie się do rozkładu przycisków zajmuje chwilę. Dłuższą chwilę (powyżej 2h).
+ Nobel w dziedzinie ergonomii należy się wynalazcy podświetlenia górnego ekranu LCD. W nocy to rzecz nieoceniona.
+ cokolwiek by to nie było, Picture Style umiejętnie używane daje świetne efekty
- dlaczego Canon stworzył mocowanie EF? M42 by nie wystarczyło?
+ chwała Bogu, gorąca stopka się nie zmieniła od zeszłego tysiąclecia
+ trzy opcje dostosowywalne do użytkownika, dostępne z pokrętła to dobry pomysł (- szkoda, że trzy, a nie pięć)
- Canon chwali się, że to ma jakieś uszczelnienia przed wilgocią. Uszczelnień nie odnaleziono. Zaryzykuję stwierdzenie, że dla aparatu zabójcze mogłoby być zwykłe pokropienie wodą. Ze względów ekonomicznych, testu nie przeprowadzę.
+ Wizjer okazał się większy, niż się obawiałem.
+ Czułość pokazana w wizjerze to także niegłupi pomysł.
+ Tryb A-dep to mądra sprawa.
+ Może to standard w lustrzankach, ale mocowanie statywu na osi obiektywu powoduje, że przykręcenie 740 gramowej lustrzanki jest prostsze, niż pół kilo lżejszego PowerShota, o lekko zdecentralizowanym położeniu gwintu.

Jak mi się coś jeszcze przypomni, to napiszę.

Zdjęcie Teachers'a z zawartością wykonane zostało przez pijącego Damiana Bukowskiego niepijącym Canonem.

kj wybiera Pythona

2008-09-22T23:04:00.010+02:00

Przy tworzeniu wielu stron www developerzy często używają języka PHP. Ja także go używałem, znam dość dobrze jego składnię. Jednak będąc głównie programistą spotkałem się także z różnymi innymi językami, z których dwa także dość często używane są do pisania stron internetowych. Mowa o językach Ruby i Python. Wybór między nimi to jak dla mnie kwestia raczej bardziej polityczna, w dodatku zależna od aktualnych ustawień edytora. Nasuwa się jednak pytanie: dlaczego nie PHP? Spróbujmy zatem oprzeć się na pewnych przykładach.

Przykład pierwszy: kilka potencjalnych wartości zmiennej.
PHP:


if ($zmienna == 'jedna wartość' || $zmienna == 'druga wartość' || $zmienna == 'trzecia wartość') {
wykonaj_cos();
}

Brzmi znajomo, a teraz przykład w Pythonie:


if zmienna in ['jedna wartość', 'druga wartość', 'trzecia wartość']:
  wykonaj_cos()

Python - PHP 1:0.

Przykład drugi: filtracja tablicy (w Pythonie także listy).
PHP:


#!/usr/bin/env php
$t = Array(1,2,3,4,5,6,7,8,9,10);
$nowa_t = Array();
foreach ($t as $el) {
        if ($el % 2 == 0) {
                $nowa_t[] = $el;
                }
        }

Python:


#!/usr/bin/env python
t = [1,2,3,4,5,6,7,8,9,10]
nowa_t = [v for v in t if v % 2 == 0]

Python - PHP 2:0

Przykład trzeci: prosta pętla z przeskokiem o 2.
PHP:


#!/usr/bin/env php
for ($i=0;$i<10;$i+=2) {
  echo $i."\n";
  }

Python:


#!/usr/bin/env python
for i in range(0,10,2):
  print i

3:0.

Przykład czwarty: pomocny interpreter.
PHP:


#!/usr/bin/env php
help():

Fatal error: Call to undefined function help() in /home/kj/- on line 2

Python:


#!/usr/bin/env python
help()

Welcome to Python 2.3!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://www.python.org/doc/tut/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics".  Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".

4:0...

Przykład piąty: tempo działania.
PHP:


#!/usr/bin/env php
for ($i=2;$i<1000;$i++) {
        $found = 0;
        for ($n=2;$n<$i;$n++) {
                if ($i % $n == 0) {
                        echo $i." = ".$n.'*'.$i/$n."\n";
                        $found = 1;
                        break;
                        }
                }
        if ($found == 0) {
                echo $i." is a prime number\n";
                }
        }

oraz wyniki:


# time php test1.php > test.txt
real    0m0.137s
user    0m0.110s
sys     0m0.017s

Python:


#!/usr/bin/env python
for n in range(2, 1000):
     for x in range(2, n):
         if n % x == 0:
             print n, '=', x, '*', n/x
             break
     else:
         # loop fell through without finding a factor
         print n, 'is a prime number'

oraz wyniki:


# time ./test1.py > test1.txt 
real    0m0.188s
user    0m0.148s
sys     0m0.012s

Chwilowy koniec testu. Mam nadzieję, że podane argumenty wyjaśniły dlaczego kj wybrał akurat Pythona. Nie będę porównywał Rubiego z Pythonem, gdyż jak już wspomniałem wcześniej - jest to wybór, który ciężko jednoznacznie uzasadnić technicznie ;).

Gdy sieciówce brak adresu

2008-09-15T18:19:00.003+02:00

Zapewne każdy informatyk wie o tym, że każda karta sieciowa ma swój własny, unikalny adres, zwany MAC. A przynajmniej mieć powinna. Okazuje się bowiem, że współczesna technika i dążenie do uproszczenia sprzętu spowodowała, że nie jest to już takie oczywiste. Dość często odwiedzam polskie forum użytkowników M0n0walla. Spotkałem się na nim z dość ciekawym problemem. Otóż współczesny dostawca Internetu bardzo często identyfikuje swoich klientów właśnie na podstawie adresu MAC sprzętu sieciowego. Wydaje się to słuszne, jednak zdarza się i taki sprzęt, który tego adresu potrafi... nie posiadać. Mowa tu o CDCE (Communication Device Class Ethernet), czyli swoistej "przejściówce" z USB na ethernet. Może to się wydawać śmieszne, ale tak to wygląda. Sterownik tego urządzenia w systemach NetBSD i FreeBSD w bardzo ciekawy sposób go inicjalizuje. Próbuje odczytać adres MAC z urządzenia (poprawne i pożądane zachowanie), a gdy to mu się nie uda adres MAC staje się kombinacją losowej wartości pochodzącej z licznika czasu systemu operacyjnego, stałej liczby 0x2a oraz id urządzenia (zwykle 0). Taka kombinacja daje teoretycznie unikalny adres MAC. Jednak taki sposób ustawiania adresu MAC dyskwalifikuje użycie go w sieciach, gdzie adres MAC jest podstawowym sposobem autoryzacji. Pojawia się więc problem: co z takim fantem zrobić? Jednym z moich pomysłów było stworzenie łatki, która przypisuje urządzeniu statyczny adres. Pojawia się jednak problem: co w przypadku, gdy w jednej domenie kolizji pojawią się dwa takie urządzenia? Aby rozwiązać ten problem należy zastanowić się nad rozbudowaniem łatki w możliwość ustawiania adresu mac np. za pomocą mechanizmu sysctl. Proponuję pomyśleć nad innymi sposobami rozwiązania tego problemu ;).

Magia liczb całkowitych

2008-08-24T14:14:00.003+02:00

Pisząc niedawno mały program obliczający sumę kontrolną dla danego ciągu znaków zostałem nie miło zaskoczony pewnym ograniczneniem języków skryptowych (w moim przypadku - Python i Ruby). Oba te języki traktują liczby całkowite jako liczby ze znakiem i w żaden sposób nie idzie ich tego zachowania oduczyć. Z tego też powodu np. prosta negacja daje bardzo dziwne efekty:

>>> ~4
-5

Chyba nie o to chodziło. Znalazłem rozwiazanie, za pomocą SWIG skonstruowałem moduł napisany w języku C, w którym z łatwością mogłem używać typów bez znaku i to w nim zaimplementowałem obliczanie sum kontrolnych dla danego ciągu znaków. Szkoda tylko, że pomimo wszystkich swoich zalet języki skryptowe potrafią także dość mocno ograniczać swobodę programisty.

Open Source i społeczność

2008-07-25T22:43:00.003+02:00

Społeczność Open Source chlubi się m.in. tym, że potrafi szybko reagować na zaistniały problem. Na ile szybko? Wczoraj dane mi było się samemu o tym przekonać...

Z problemem tym miałem już do czynienia - budując router na podstawie procesora Geode GX1 wraz z typowym dla niego otoczeniem oraz na dystrybucji m0n0wall, spotkałem się z odmową zamontowania dysku (w moim przypadku 32-megabajtowego Compact Flasha). Wynikało to ni z tąd, ni z owąd z pewnej niedogodności. Dokładniej podsystem PCI nie mógł uwierzyć, że inicjalizowany sprzęt istnieje i należy mapować go w taki sam sposób, jak inne urządzenia ATA. Dodajmy jeszcze, że kontroler oparty jest na chipie Cyrix 5530. Problem udało mi się rozwiązać dzięki liście dyskusyjnej FreeBSD. Podano tam także łatkę, którą należało zaaplikować, aby system poprawnie uruchomił dysk. Mi się udało, jednak kilka tygodni później niemal identyczny przypadek przydarzył się kolejnemu użytkownikowi m0n0walla. On jednak nie był w stanie samodzielnie przebudować jądra systemu, a co gorsze - chciał go aktualizować, co z pewnością pociągałoby za sobą konieczność każdorazowego bawienia się z jądrem. Postanowiliśmy problem zgłosić odpowiednim siłom. Autor m0n0 jeszcze tego samego dnia odpowiedział, stosowna łatka została dodana, a ja otrzymałem zapewnienie, że będzie obecna w kolejnych wydaniach systemu.

Tak oto, w ciągu jednego dnia kolejny produkt Open Source zyskał, a przy tym zyskali jego użytkownicy.

Techniczny Chopin

2007-10-25T22:26:00.002+02:00

Po obejrzeniu na YouTube Artura Rubinsteina grającego Polonez as-dur F. Chopina (op. 53) doszedłem do wniosku, że skoro on umie, to ja na pewno też się nauczę. Za mną stoi przecież 16 lat namiętnego obmacywania klawiatury komputera. Nie wziąłem pod uwagę, że za wykonawcą tego poloneza stoi 70 lat równie namiętnego obmacywania klawiatury pianina. No ale do idiotów świat należy. Dorwałem stosowne nuty, po czym usiłowałem wyczytać z nich główny motyw całego utworu. Po pół godzinie prób i błędów znalazłem poszukiwany fragment i zabrałem się za analizę. Pierwsza nuta, druga. No, po 3 godzinach miałem już 2 nuty potrzebne do zagrania pierwszego akordu... Na jedną rękę oczywiście. Ale jest postęp. Drugi dzień przyniósł 4 kolejne akordy, które zebrały się w jeden takt. Kolejny dzień i pierwszy takt był oczywisty na obie ręce. Pozostawało go tylko odpowiednio zagrać, co oczywiście nie było już takie proste. Dobrze, że nasłuchałem się tego utworu wcześniej, dzięki czemu, nie patrząc w nuty mogłem spróbować odegrać melodię. I nawet się udało. W sumie liczyłem na więcej, ale i tak było nieźle. Tak minął wieczór dnia trzeciego. Dzień czwarty przyniósł kolejne odkrycie - otóż pianino ma pedały, które potrafią cuda czynić! Mało tego, w nutach zawarte są informacje kiedy i jak długo te pedały należy wciskać. Pod wieczór dnia czwartego okazało się, że pierwszy takt, grany z odpowiednim naciskaniem pedałów brzmi prawie, jak na filmie. Jak się później okazało "prawie" spowodowane było moją niewiedzą o tym, że bemole przy kluczu odnoszą się... do całej linijki utworu. Po 3-godzinnej korekcie polonez brzmiał zupełnie poprawnie. Kolejne dni upływały na ćwiczeniu kolejnych taktów, wyłuskiwaniu pojedynczych nut a także na ćwiczeniu... do-re-mi-fa-sol-la-si-do i to w obie strony. Cóż - jakoś nie miałem przyjemności wyćwiczyć tego wcześniej. Po 3 tygodniach nauki wydaje mi się, że zarówno Chopin, jak i sproszkowany Rubinstein przewracają się w grobach na odgłos mojego pianinowania...

Pecet 15 lat temu (2)

2007-08-27T23:45:00.002+02:00

Pora na drugą część przemyśleń. Tym razem odsuniemy się nieco od sprzętu, a przejdziemy bliżej oprogramowania.
Ostatnie obserwacje wykazują, że (podręcznikowy wręcz) stos TCP/IP systemu FreeBSD jest ok. 4-krotnie szybszy od stosu Windowsa. Jeśli weźmiemy pod uwagę, że medium testowym była sieć radiowa, różnice mogą być jeszcze większe. Jednak wracając do tematu - czy po 15 latach faktycznie nastąpiła poprawa?
Instalacja Windowsa 3.11 potrafiła zabrać bite 5 godzin. Instalacja 386/BSD cały dzień. Czy dzisiaj jest lepiej? Okazuje się, że Windows XP instaluje się stosunkowo szybko, tj. poniżej 1 godziny. FreeBSD w zależności od ilości dodatkowego oprogramowania i medium instalacyjnego - od 15 minut do 5-6 godzin. Ale przecież nie sama instalacja się liczy. Współczesne systemy operacyjne mają znacznie większe możliwości w tworzeniu abstrakcyjnych obiektów, przeznaczonych do magazynowania dużych ilości danych (woluminy logiczne), przyspieszania działalności komputera (ciekawe algorytmy planujące, szybki przydział pamięci). Jednak coraz więcej aplikacji, działających w przestrzeni użytkownika jest dosłownie "nabajerowana". Owocuje to tym, że owe oprogramowanie ma nieziemskie wymagania sprzętowe i po prostu muli. Pod tym względem nadal siedzimy w epoce kamienia łupanego. Dobrym przykładem jest tutaj nowy system Microsoftu - Vista. Co ciekawe - rozwiązanie Open Source - Beryl wymaga zdecydowanie mniej a jest przy tym znacznie bardziej spektakularne. Microsoft usiłował odgapić rozwiązanie od Apple i mu znowu nie wyszło. Ale cóż. Z drugiej strony coraz szybszy sprzęt teoretycznie powinien rekompensować powolność oprogramowania, niejednokrotnie pisanego w językach skryptowych (nawet w Visual Basicu). Jednak takie podejście nadal trzyma nas - użytkowników pecetów w miejscu. Zamiast przyspieszać w zasadzie stoimy w miejscu, a przyrost mocy obliczeniowej zajmują wodotryski. Widać jednak i pozytywne strony tych 15 lat. Oprogramowanie tworzone mądrze wykorzystuje praktycznie każdy procent przyrostu mocy obliczeniowej, a dodawane nowości są w 100% funkcjonalne - nie ma miejsca na wodotryski.
Patrząc na dzisiejszy rynek software napawa mnie nadzieją, że rozwój nadal będzie oznaczał zwiększenie funkcjonalności, a nadmiar wodotrysków będzie tylko i wyłącznie wyśmiewany...

Web 2.0 kontra Internatuta

2007-08-26T23:40:00.002+02:00

Skończyły się piękne czasy, gdy strona www wyglądała tak, jak przeciętny dokument, wydrukowany na kartce papieru. Web 2.0 zaczyna wymuszać inne spojrzenie na wygląd strony. Nie liczy się, czy jest ona nabajerowana do granic możliwości (i przyzwoitości), lecz czy jest ona dostępna, użyteczna i dostosowana do potrzeb osób niepełnosprawnych. Problem polega też na tym, że treść i wygląd strony muszą być od siebe odseparowane - dokument (x)html jest tylko nośnikiem danych, podczas gdy pliki css zawierają informacje o wyglądzie strony. Kolejnym problemem jest połączenie "sztywnego" szablonu z bardzo uniwersalnym programem, który w zasadzie powinien tylko w ów szablon wstawić stosowną treść. Do tego trzeba pilnować, aby (z racji optymalizacji) unikać nadmiernych pętel, etc. Wszystko pięknie, ale pojawia się problem: po co to wszystko? Przecież przeciętny użytkownik Internetu coraz bardziej obniża swój poziom intektualny. Nie próbuje zrozumieć, jak to wszystko działa i czy ta strona jest lepsza technicznie od innej.
Lenistwo?
Brak zdolności technicznych?
Brak zdolności detektywistycznych?
Nie, to nie to. Po prostu ludzie przyzwyczaili się, że wszystko, co ich otacza ma im pomagać bez względu na swoją budowę. Czy wobec takiego podejścia ludzi warto się wysilać, konstruując poprawne technicznie strony, zgodne z zaleceniami, dostępne i użyteczne? Chyba jednak nie możemy tak postąpić - zawsze może się zdarzyć, że to my będziemy potrzebować stron, stworzonych dla osób niepełnosprawnych. Dlatego też starajmy się tworzyć wszystko jak najlepiej, pomimo tego, że czasami będzie to trudne i męczące.

Pecet 15 lat później

2007-08-25T20:57:00.001+02:00

Prawdziwie świadomą przygodę z komputerami zaczałęm koło 4 roku życia. Nie była ona początkowo zbyt spektakularna, lecz po tych piętnastu latach mogę już podzielić się swoimi spostrzeżeniami odnośnie komputerów, których (prawie) wszyscy używamy.
Początki były trudne - statycznie ustawione przerwania, których zwykle było za mało, ciągłe konflikty, masa sterowników, ograniczenia BIOS-u. Jak donosi archiwalny już "PC World Komputer" ze stycznia 1994 roku instalacja BSD/386 zajęła redakcji calutki dzień. Problemy mnożyły się dosłownie wszędzie: a to nie działa cd-rom, a to z kolei niewłaściwa konfiguracja dysku i niefortunny podział partycji blokują możliwość korzystania z komputera. Instalacja sterowana ręcznie przez specjalistów z BSDI oraz od producenta komputera.
Nieprawdopodobne?
Ja jednak postawię dziwne pytanie: czy jest lepiej? Zarzucicie mi zapewne, że takie pytanie jest pytaniem retorycznym i tylko idiota mógłby je zadać. Jednak postaram się zaprezentować nieco inne spojrzenie na tą kwestię.
Czym jest dzisiejszy komputer? Na pewno szybkim urządzeniem. Współczesna technologia tak rozpędziła komputer domowy, że niegdyś mógłby być on uważany za niesamowite urządzenie obliczeniowe. Jednak moc obliczeniowa nie rozwiązuje wszystkich problemów. Pomimo, że magistrala PCI jest de facto standardem, zdarzają się sytuacje, gdy np. karta sieciowa działa ze we wszystkich gniazdach, poza jednym na płycie głównej komputera. W 1994 roku narzekano na brak sterowników do sprzętu w systemach Uniksowych. Ten problem nadal jest największą bolączką użytkowników. Na szczególne wyróżnienie zasługują tutaj 3 grupy sprzętu:

karty graficzne
karty radiowe
modemy wewnętrzne

O ile w przypadku kart graficznych producent rzeczywiście może zasłaniać się tajemnicą technologiczną, to postawa dwóch pozostałych grup jest dla mnie niewytłumaczalna. Dlaczego do jasnej cholery nie można znaleźć informacji, jak działa modem wewnętrzny? Czy w czasach szerokopasmowego dostępu do Internetu "tajniki" transmisji danych przez analogowe łącza telefoniczne jest aż tak ważną i istotną informacją? Żeby było weselej tzw. "postęp" wspomógł producentów w tworzeniu urządzeń, które praktycznie nic nie robią! W dawnych czasach karta sieciowa była tak skonstruowana, że sterownik miał za zadanie praktycznie skopiować gotowe dane z karty sieciowej do podsystemu obsługi sieci w systemie operacyjnym. Obliczanie sumy kontrolnej, odrzucanie pakietów adresowanych do innych urządzeń, usuwanie danych protokołów najniższych rzędów - to wszystko realizował sprzęt, odciążając procesor komputera oraz programistę, tworzącego sterowniki. Dzisiaj karta sieciowa praktycznie nie robi nic. Odbiera dane i wywołuje przerwanie, aby kod sterownika zrobił wszystko za nią. Programiści dostają szału, gdy sterowniki niejednokrotnie są dłuższe, niż znacznie bardziej istotne elementy systemu operacyjnego. I na co nam to wszystko? Czy cała ta "rewolucja" z PCI, USB i innymi spowodowała tylko utworzenie nowych problemów? Czy zwiększenie mocy obliczeniowej komputerów idące w parze z przerzucaniem na CPU większości obliczeń jest rozsądnym rozwiązaniem? Nasze komputery mogłyby działać szybciej, gdyby procedury obsługi przerwań w popularnych urządzeniach były krótsze. Ale co z tego, skoro i tak 200 kolejnych megaherców rozwiąże sprawę? Jednak przeskok o taką częstotliwość nie zmieni jednej rzeczy. Czasu spędzanego przez programistów, usiłujących uruchomić urządzenie pod innym systemem niż Windows, przed ekranem komputera. Przekonałem się o tym sam, przesiadując 2 godziny nad poprawieniem sterownika do radiówki, która przecież mogłaby działać i bez mojej pracy. Gdybyśmy przez te 15 lat poszli choć dwa kroki w przód.