Komórkowy SPAM

Witam wszystkich, którzy tutaj trafili - jeśli tutaj jesteś to najprawdopodobniej padłeś ofiarą próby oszustwa, naciągactwa lub czegoś podobnego.
W dniu dzisiejszym otrzymałem SMS od numeru 6654 o treści "Zablokowane wiadomosci! Masz nieodebrana wiadomosc glosowa! Aby dowiedziec sie wiecej jak ja odsluchac wyslij SMS WALL ODBIERZ na numer 92550 (30,5 pln)".
Po spojrzeniu na dokument http://www.playmobile.pl/resources/pdf/Numery_Specjalne.pdf stwierdziłem, że numer 6654 nie jest tam zarejestrowany natomiast numer 92550 już jest i to na firmę Teleaudio Sp. z o.o.
W związku z powyższym skontaktowałem się z BOK (biurem obsługi klienta) swojego operatora i zgłosiłem fakt otrzymywania niechcianej informacji handlowej o charakterze naciągactwa drogą elektroniczną.
Zostałem poinformowany, że sprawa zostanie przekazana prokuraturze.
Artykuł prawny, który chyba jest z tym skojarzony: ustawa z dnia 18 lipca 2002r. o świadczeniu usług drogą elektroniczną (Opracowano na podstawie: Dz.U. z 2002 r. Nr 144, poz. 1204, z 2004 r. Nr 96, poz. 959, Nr 173, poz. 1808, z 2007 r. Nr 50, poz. 331, z 2008 r. Nr 171, poz. 1056, Nr 216, poz. 1371, z 2009 r. Nr 201, poz. 1540.).

Jeśli otrzymujesz podobny SPAM na komórkę to:
1. Zgłoś się do operatora aby nie otrzymywać podobnych wiadomości - prawdopodobnie w Twojej umowie znajduje się zgoda na otrzymywanie takowych lecz przysługuje Ci prawo do zrezygnowania ze SPAMu.
2. Zweryfikuj od kogo jest ten SPAM (link powyżej) i, skoro już zrezygnowałeś/zrezygnowałaś z otrzymywania w pierwszym punkcie, wyślij odpowiedniego maila na adres kontaktowy podany w tymże dokumencie. Uważaj na słowa - Twój mail może również zostać wykorzystany jako dowód na to, że to Ty coś nie tak robisz (np. straszysz "uczciwego" przedsiębiorcę typu Teleaudio Sp. z o.o.).
3. Zgłoś nadużycie do swojego operatora - oni powinni to skierować do prokuratury.
Powodzenia

Torchlight - Diablo I ?

W dniu dzisiejszym odpaliłem grę Torchlight. Niby kiepska grafika i nic innowacyjnego. Interfejs też niezbyt czytelny. Jednak ta gra ma kilka zalet:
- Nowe Diablo I
- Muzyka jak w Diablo I
- Miodność
- RPG
- Troszkę zapożyczeń z WoW
Jak i wad:
- Brak możliwości obracania kamery
- Wątpliwa czytelność interfejsu
- Brak realizmu... ale może to zaleta?
Ogólnie - polecam. Chyba sobie ją kupię - na razie gram w demko ze steam'a :)

Windows 7 RC1

Dzisiaj wrzucę na ruszt windowsa 7. Zapewne w necie znajduje się więcej informacji na ten temat (jak również obrazki :D ).
Zalety Windows 7:
- jądro podobne do visty
- poprawiona obsługa sterowników względem visty
- poprawiona kontrola bezpieczeństwa (UAC) - ale nadal dalego do ideału (takim ideałem był dla mnie zawsze program Tiny Personal Firewall)
- w końcu Microsoft pomyślał o użytkownikach i poprawił interfejs użytkownika zamiast marnować czas na ładny jego wygląd
Wady Windows 7:
- większe wymagania niż XP (kwestia sporna)
- zapewne cena
- ikonki w tray'u doprowadzają mnie do wściekłości

Czy warto? TAK :)

Dobra rada

Czytając dzisiaj dokumentację wpadłem na proste stwierdzenie - proste, ale bardzo wartościowe:
Jeśli spodziewasz się wyjątku - obsłuż przyczynę a nie wyjątek.

Co mnie wkurza w systemie plików

Witam,

Dzisiaj chciałbym napisać, co mi nie odpowiada w popularnych systemach plików - mam tutaj na myśli te, z którymi się na co dzień spotykam (windows, solaris, linux - przeważnie fat,ntfs,ext2/3,reiserfs). Z tego co się orientuję, to ograniczenie leży po stronie systemu, a raczej logiki systemu plików.

Otóż chciałbym stworzyć jakąś aplikację - kod źródłowy miałby leżeć w /src. Plik główny miałby się nazywać main.src. Ale kod miałby się odwoływać do deklaracji a implementacje byłyby położone w main.src/implementacja.src.

Otóż popełniam w mojej logice 2 poważne błędy:

1) Nazwa pliku... czym ona jest?

2) Jeśli mówimy, że coś jest w jakimś większym kontenerze to jest to plik w katalogu.

Moim zdaniem dostęp logiczny do obiektu odbywający się po jego nazwie jest błędny (dobrym rozwiązaniem jest HTML, gdzie obiekty mają swoją nieunikalną nazwę i unikalny ID). To jest błąd leżący w założeniach tego, jak wyglądają systemy plików.

Błędem jest również założenie, że mogę mieć plik i katalog o tej samej nazwie - tego zrobić nie mogę. Dostęp odbywa się po nazwie (nie po ID) więc otwierając c:\windows otwieram.... no właśnie... obiekt o nazwie c:\windows.

Jak ja to widzę...

System plików powinien się składać z fizycznych "grup danych" zawierających wiele jednostek logicznych powiązanych ze sobą w jakiś użyteczny sposób. Wewnątrz takiej grupy powinny istnieć obiekty logiczne posiadające własne unikalne identyfikatory (unikalność powinna być zapewniona w obrębie jednego systemu plików, t.j. w obrębie partycji logicznej, lub też w obrębie grupy danych). Niezależnie od tego powinna istnieć struktura logiczna opisująca nasze obiekty logiczne. Powinna zawierać grupy obiektów określając je po ich identyfikatorach. Problem: Jak identyfikować grupy obiektów? Najlepiej chyba aby miały formę "tagów" przypisywanych do obiektów logicznych (tyle, że atrybut nie byłby przypisany do pliku ale plik do atrybutu).

Problem: Oznaczałoby to zupełnie nowe podejście do plików - odwołanie do kontenera danych odbywałoby się poprzez podanie unikalnego identyfikatora systemu plików(obiektów?)+identyfikatora obiektu (który jest unikalny w obrębie systemu plików). Alternatywnie możnaby się odwoływać do jakiejś grupy obiektów w celu otrzymania ich listy.

Do tego dorzućmy ochronę - system un*xowy się sprawdził - więc można tego użyć.

Zaleta: Możnaby tworzyć kilka obiektów o tych samych nazwach.

Wada: Duża ilość grup.

Wada: Nazwa obiektu musiałaby być gdzieś osobno trzymana.

Wada: Nie wspomniałem o fizycznych danych - to byłaby oddzielna warstwa.

Podsumowując:

Widzę system danych jako 3 warstwy: warstwa fizyczna (zbliżona do obecnej), warstwa logiczna trzymająca dane oraz warstwa logiczna opisująca dane.

Warstwa fizyczna:

Bloki, cylindry, sektory, itd. pogrupowane w większe grupy fizyczne. Grupowanie możnaby np. wykonać względem szybkości dostępu do danych i ryzyka utraty danych. Odwołanie do danych może się odbywać poprzez podanie ID grupy+numeru jednostki alokacji.

Warstwa logiczna odpowiedzialna za trzymanie danych:

Zależna od warstwy fizycznej.

Każdy obiekt logiczny posiada rodzica. Każdy obiekt logiczny może posiadać dzieci. Tak oto załatwiliśmy strawę kontenerów obiektów (katalogów/folderów).

Każdy obiekt posiada właściciela.

Każdy obiekt posiada opis uprawnień dla właściciela (niech to będzie x bitów).

Możnaby jeszcze dodać standardowe atrybuty trzymane w tej warstwie - chociaż to już jest ryzykowne.

Warstwa logiczna opisu danych:

Zawiera grupy z ich nazwami, właścicielami oraz uprawnieniami (x bitów). Właściciel powinien tutaj stanowić grupę użytkowników.

Zawiera listę ID obiektów logicznych powiązanych z daną grupą.

Tagi możnaby podzielić na konfigurowalne przez użytkownika oraz przypisane na stałe do obiektów (to już niestety odejście od standardowego podejścia do plików).

Potencjalne problemy:

Dane dzielone między 2 i więcej bloki logiczne/fizyczne.

Przykładowy dostęp do plików gry XYZ:

Pobierz pliki posiadające tag XYZ => lista ID.

Pobierz pliki posiadające tag 'grafika' pomiędzy otrzymanymi ID.

Pobierz zależności rodzic/dziecko obiektów i pobierz dalej dane jak w standardowo używanych systemach plików.

Przykładowe wyszukanie dokumentów przez użytkownika:

Wyszukaj pliki które są moje i które zostały ściągnięte aplikacją "przeglądarka".

Dodatkowo szukaj plików o jakiejś nazwie.

Jeśli ktoś przypadkiem to czyta to jestem ciekaw czy będą do tej wizji jakieś uwagi :)

Jak pisać dobre oprogramowanie?

Dziś troszkę o standardach i zasadach tworzenia dobrego oprogramowania. Zadziwiające jak niewielu ludzi je zna.

1. Jeśli używasz daty - zawsze używaj formatu daty zgodnego z ISO-8601. Jeśli nie znasz normy to nie wiesz jak zapisywać daty. Norma podaje również powody dla których należy z niej korzystać. I jest międzynarodowa. Po prostu - przeczytaj, ucz się i nie popełniaj błędów które inni popełnili.
2. Jeśli tworzysz programowanie w językach wysokiego poziomu - używaj wzorców projektowych. Nie wiesz czym one są? To jakby zasady gramatyczne. Możesz znać litery nie umiejąc pisać. Możesz nawet umieć pisać nie znając gramatyki/ortografii (i robić błędy). Możesz też używać wzorców programistycznych/projektowych.
3. Myślisz że wiesz coś na pewno? Poczytaj standardy - zapewne zmienisz zdanie. Poczytaj standardy - warto.
   
4. Jeśli coś robisz - staraj się to robić dobrze. Nie najlepiej jak jest to możliwe - ale najlepiej jak możesz w danej sytuacji.
5. Myślisz że coś robisz dobrze... więc sprawdź czy ktoś nie robił tego tak samo przed tobą. I nie popełnił tych samych błędów, które właśnie zamierzasz popełnić.
   
6. Nie traktuj tych porad jako wiedzy absolutnej - ja się ciągle uczę nowych rzeczy.
   

Dynamiczne definiowanie typów w PL/SQL

Ostatnio natknąłem się na pewien paskudny problem. Chciałem zdefiniować procedurę korzystającą z DBMS_UTILITY.FORMAT_CALL_STACK. Ta funkcja stworzona przez Oracle zwraca typ VARCHAR2(2000) (przynajmniej tak mi się wydaje). Zgodnie z dokumentacją Oracle tak ma właśnie być.

A teraz zastanówmy się nad definicją typów jakiej powinno się używać w PL/SQL:

nazwa tabela.kolumna%TYPE;

Zapewnia to elastyczność jeśli typ tabela.kolumna się zmieni (np. zmienimy go z VARCHAR2(10) na CLOB). Ale... przecież nie wiemy jak się odwołać do tego typu - Oracle nie daje nam tej informacji!

Wniosek: Kod Oracle nie jest elastyczny. Każdy programista PL/SQL jest skazany na nieelastyczność ponieważ korzysta z nieelastycznej bazy danych.