Ja natomiast dość szybko znalazłem ułatwienie dla siebie:

<?php
for( $i = 11000; $i < 12000; $i++ )
echo “http://images.templatemonster.com/screenshots/” . floor( $i / 100 ) .’00/’ . $i . “-b.jpg\n”;
?>

następnie
makaron@laptop:~/workspace/temp8$ php generate.php > files.txt
makaron@laptop:~/workspace/temp8$ wget -i files.txt

…i po kilku minutach mam wszystkie szablony z “grupy 11k” w katalogu, przeglądane szybko i wygodnie, z kasowaniem badziewnych i zapamiętywaniem (kopiowaniem do innego katalogu) wybranych.

Pomyślałem – przeglądanie jest OK, ale wyszukiwanie “podobnych” by się przydało… po 15 minutach był prosty skrypt, który analizował natężenie kolorów we wszystkich obrazkach i dane ich zapisywał do bazy. Po następnych 15 minutach była przeglądarka obrazków wyświetlająca od razu “pasek kolorów” (długość koloru w pasku odpowiada natężeniu [%udziałowi danego koloru w całym obrazku] koloru). Bardzo łatwo mogę znaleźć podobne obrazki, bądź obrazki o wybranych kolorach.

Dobrze, co dalej? Przydałaby się możliwość wybrania “układu” (nie mylić z grupą trzymającą władzę)… strony. Ale to niestety wymagałoby już ręcznego określenia na pewnym etapie (wszystkie metody automatyczne, które przyszły mi do głowy, niestety będą zawodne, a co najmniej niepewne).

Może ktoś z was ma pomysł, jak z obrazka odczytać układ (2kolumny / 3kolumny / nagłówek+2kolumny itd)?

notatka: poprawiłem błąd zer (powstały przy przepisywaniu)

Działanie skryptu jest bardzo proste (bash only), ale wymaga kilku narzędzi (dostępnych chyba w każdym uniksie): wget, sed, find. Wszystkie RSSy znajdujących się w “channels.txt” są pobierane do tmp/$num, następnie sedem każdy tag zawierający string “mp3″ przenosimy do nowej lini, grepujemy tylko linijki zawierające “mp3″. Pobieramy wszystkie http://.*mp3, których pliki nie są znalezione (przy użyciu find/basename). Proste, krórkie, logiczne :-) Dodatkowo pliki mp3 są przechowywane w katalogach “dziennych” (mp3/2008-08-23/), dzięki czemu możemy posłuchać wyłącznie nowo pobranych plików.

Nie znalazłem nic prostego i szybkiego na sieci (a pewnie za mało szukałem). Siadłem do pisania i po 30 minutach otrzymałem gotowe rozwiązanie pobierania plików z rapidshare. Uwaga: ponieważ skrypt pobierania był pisany na szybko i wyłącznie do momentu pierwszego poprawnego pobrania jest on dość chaotyczny i niepotrzebnie skomplikowany (obiecywałem sobie, że go uprzątnę, ale póki działa nie będę tego robił). Drugi plik jest “launcherem” pobierającym wszystkie pliki z listy zawartej w files.txt. Tyle o paczce, teraz o samym pobieraniu.

Skrypt jest chaotyczny, ale działający – przede wszystkim obawiałem się, że rapidshare będzie miał jakieś zabezpieczenia przed pobieraniem – ukryte javascript’y, ukryte obrazki, kombinacje i inne elementy utrudniające pobieranie “automatem”. Niestety nic takiego nie ma! …na szczęście :-) Skrypt używa zewnętrznego curl (/usr/bin/curl) do pobrania “ostatecznego” pliku, gdyż pobieranie w PHP nie ma sensu – a ja jestem zwolennikiem zasady, że należy wszystko robić najprościej jak się da. Pobieranie “stron” i symulowanie użytkownika jest wykonywane przy użyciu curl w PHP. Cały proces ma trzy etapy: pobranie strony z wyborem sposobu pobierania pliku, wywołanie formularza “Free”, i ostateczne pobranie pliku (po odczekaniu 92 sekund [max czasu odczekania jaki znalazłem na rs]).

To chyba wszystko co warto napisać o pobieraniu – w razie problemów/sugestii/nowych wersji plików proszę pisać w komentarzach :)

…postanowiłem napisać swój system rozpoznawania znaków. System bardzo prosty, ale jednocześnie bardzo skuteczny – opierający się na rozpoznawaniu wybranych elementów charakterystycznych dla znaków. Nie pozwala on co prawda na czytanie skanów, ale bez problemu rozpozna teksty drukowane na obrazkach.

W pierwszym etapie filtruję obrazki (usuwając wszelkie śmieci, które mogą zniekształcić obrazek), pozostałość (kiedy zostają już tylko litery)  robię cz/b, rozbijam na pojedyncze litery (zapomniałem dodać, że sprawdzam, czy litera nie jest przekręcona),  a te litery parsuję moim “OCR” (doszedłem do wniosku, że gdybym miał z miesiąc wolnego, mógłbym napisać “poważny” OCR, ale z pracy 3 dniowej też jestem zadowolony).

W pojedynczych literkach skupiam się na kilku charakterysytycznych cechach (ATM mówimy jedynie o literach drukowanych, małe literki pojawią się w wersji 2.0) – liniach prostych, skosach i zaokrągleniach – ścięciach. Okazuje się, że wcale nie jest ich tak dużo, oraz że litery różnią się znacząco od siebie. Po pierwszym filtrze zostaje nam ~2-6 liter, które trzeba dokładniej sprawdzić, po drugim zostaje max 3 (zazwyczaj 1), dla których porównujemy zapisane różnice (np. między D a O różnice są w prawym górnym i lewym dolnym rogu, różnica między F i E jest na dolnej kresce i dolnym prawym rogu – ale te różnice powinny zostać wychwycone już w pierwszych 2 etapcach i jedna z nich powinna zostać wykluczona).

System doskonale sprawdza się w przypadku liter drukowanych i “prostych” znaków – choć zapewne, jeśli sprecyzować dokładność sprawdzania (np. dla rogów mam sprawdzanie, czy jest prostokąt w pełni wypełniony, czy wypełniony “po skosie prawym (slash)”, “skosie lewym (backslash)” i która część skosu jest zapełniona.

Docelowo planuję jeszcze dodać (w przypadku, jeśli zostaną jakieś niepewności (G vs 6 – sprawdzenie, czy jest połączenie między kreseczką w środku) sposób porównywania właśnie typowych “niepewnych”.

System jeszcze nie dokończony, a już pojawił się nowy model sprawdzania litery – opływanie. Dla pojedynczej litery sprawdzamy jak wygląda jej kształt zamieniony na proste, w przypadku których koniec jednej jest początkiem drugiej (trudno to opisać, łatwo zobaczyć na rysunku, ale takowego akurat nie posiadam). Proste krótkie są później zamieniane na dłuższe (3 proste, których X zmienł się o 4px, a Y o 30 można śmiało zamienić na jedną długą z X początkowym pierwszego punktu, i końcowym ostatniego) – i te proste byłyby później porównywane. System ten, jest dużo bardziej skomplikowany, ale osiągnięty efekt może być dużo lepszy.

…a w trakcie pisania powyższego paragrafu, doszedłem do wniosku, że potrzebny mi będzie jeszcze system usuwania kapitalików przed parsowaniem liter…

Docelowo planuję trzy wersje językowe (jako, że mam dostęp do 2 tłumaczy, którzy będą mogli mi teksty tłumaczyć w miarę możliwości “na bieżąco”) – PL, EN i DE. Prócz komunikatów serwisu (interface’u), chciałem żeby serwisy były w miarę możliwości niezależne językowo (komentarze, tagi) a jednocześnie zsynchronizowane (skoro na jednym z nich zostaną podane określone tagi, to zapewne dla pozostałych te tagi również będą sensowne – część z nich będzie trzeba przetłumaczyć, to wszystko)… i tu się sprawa komplikuje. O ile napisanie takiego mechanizmu nie byłoby wielkim problemem, o tyle synchronizacja – panowanie nad wszystkim – na pewno będzie nastręczać problemów.

Jeśli do tego dodać “codzienną” pracę nad serwisem, może się okazać, że rewolucja językowa zjadła własnego webmastera i nic sensownego z niej nie wynikło. Oczywiści prócz problemów czasowych dojdą pytania/problemy techniczne – czy wersje językowe rozwiązać na subdomenach, czy na podkatalogach (serwisu, nie fizycznych – wszystko musi chodzić na jednym kodzie, jeszcze by tego brakowało, żebym musiał synchronizować pliki… albo bazy danych :D). Najlepiej rokującym jest rozwiązanie subdomenowe en.danceshaker.com, pl.danceshaker.com, de.danceshaker.com – tylko wtedy trzeba zrezygnować z ew subdomen dla tematów (jak to planowałem) – można to oczywiście obejść temat.en.danceshaker.com – tylko czy warto? Jestem przeciwnikiem stu tysięcy domen dla serwisów, których i tak nikt nie zapamięta, tylko po to żeby lepiej wyglądało w wyszukiwarce – wiem, efekt psychologiczny, ale prócz pieniędzy liczy się zdrowy rozsądek (dla mnie) – dlatego chcę tego uniknąć.

Zakładając, że decyduję się na subdomeny, nada pozostaje kilka problemów – jak choćby ocenianie, wyszukiwanie i inne – o których na razie nie będę wspominał.

Rozwiązanie – jak zawsze, przyjdzie w swoim czasie – przeglądajcie bloga, postaram się opisać.

Dodałem do każdego pliku odpowiednie svn:keywords – Revision, ale ręcznie nie zmodyfikowałem (jeszcze) wszystkich plików – jest ich zbyt dużo, a zanim powstanie system update’ów (którego pisanie zajmie min. miesiąc – po godzinach) zdążę wszystko uzupełnić. Tylko.. gdzie uzupełniłem, a gdzie nie? Oto jest pytanie! Skrypt zna odpowiedź :-)

Uruchamiamy z linii poleceń (jeśli występuje parametr, to musi być katalogiem) a na wyjściu otrzymujemy listę plików (katalogi są sprawdzane rekurencyjnie [DIR ]) z zaznaczeniem, czy posiadają Revision: (co będzie automatycznie zastąpione przez SVN) [ OK ], lub oznaczeniem, że nie posiadają [----].

Prosty i skuteczny sposób na upewnienie się, że pliki posiadają odpowiednie “stringi”. Można przemyśleć, czy nie sprawdzać w ten sposób innych rzeczy – nagłówków (GPL?), @package, @author? Istnieje dużo ciekawych pomysłów na wykorzystanie.

Planowanie pojedynczej wtryskarki przypomina problem plecakowy (uwzględnić maksymalnie długą produkcję, która daje najwyższą marżę netto), jednak problem główny polega nie tylko na upchaniu produkcji na każdą wtryskarkę, ale również najsensowniejsze ułożenie produktów na wtryskarkach, maksymalizację MN na każdej wtryskarce, jak również na całym zakładzie.

Mam za mało czasu, żeby wszystko opisać tutaj (teraz) – jeśli masz pomysł, jak zaplanować upchnięcie (prawie) wszystkich rzeczy w plecakach drużyny harcerskiej… napisz do mnie :-)

O ile pobieranie danych z accessa nie stanowi większego problemu (export z M$ acessa, lub mdb-tools), nie bardzo wiedziałem jak zabrać się za obiekty OLE (z drugiej strony, to dość poroniony pomysł, żeby pliki binarne trzymać w bazie danych – i nikt mnie nie przekona, że jest inaczej). Zapisywanie ręcznie nie ma większego sensu – jest czasochłonne i pracochłonne (czasochłonność maszyny jestem w stanie czasem zaakceptować – po to nakupowałem różnego rodzaju komputerów, żeby na siebie pracowały). Jak zawsze – o pomoc poprosiłem google – dość szybko dostałem sensowną odpowiedź: OLEtoDisk. Szybko i bezboleśnie eksportuje dane z tabel do plików – używając jako nazwy wybranej kolumny, pobierając informacje dotyczące typu przechowywanego obiektu. Szybkie i raczej bezproblemowe.

Niestety (miałem napisać na szczęście, bo cieszę się, że nie musiałem tracić czasu)  nie poznałem narzędzia dokładnie, nie mniej jednak – polecam wszystkim, którzy muszą męczyć się z wyciąganiem danych z mdb.

Napisałem więc prosty skrypt, który rozwiązuje mój problem. W zasadzie to jeden plik, który został skopiowany pod inną nazwą. Pierwszy przenosi wszystkie .svn (rekursywnie) do ../SVN/project/ (project zostaje zastąpione aktualnym katalogiem), drugi wykonuje operację odwrotną. Przywraca pliki na odpowiednie miejsce.

W ten prosty sposób pozbywamy się kopii, i możemy pracować nad aplikacją, a kiedy potrzebujemy “skomitować” zmiany, sprawdzić zmiany lub wykonać inną operację na svn, przywracamy je jednym poleceniem.

Skrypt jest na GPL. Jeśli wprowadzicie w nim zmiany, proszę o kontakt.