Robus's devblog

W przypływie nudy, a w zasadzie po obejrzeniu filmu The Social Network pokusiłem się o stworzenie takiej samej strony. Kwestia o tyle ciekawa, że w filmie pokazane były ‘niezabezpieczone serwery’ jako źródło zdjęć. W rzeczywistości wystarczy kilkadziesiąt linii kodu i troche pomysłowości aby gwizdnąć zdjęcie główne każdej opolanki na naszej klasie… A jakoże nie wszyscy mają ‘nadające się’ zdjęcia ustawione jako główne, to używamy face recognition w postaci OpenCV do filtracji. Oto i efekt:

Z braku pomysłów na coś ciekawszego znowu zainteresowałem się tematem naszej klasy. Z pomocą tym razem przyszedł mi skrypt JSON przez jaki NK pobiera znajomych. Okazuje się, że da się sprawdzać jaki ktoś ma status na NKtalku. Kilkanaście minut pisania, kilka minut czekania i efekt całkiem ciekawy… Read the rest of this entry »

Znalazłem ostatnio całkiem fajną bibliotekę – ScrapeMark. Ułatwia mi pracę pod tym względem, że gdy sam układałem ekspresje regularne były one dosyć sztywne, czyli wystarczyło zmienić w HTMLu styl i już wszystko się sypało.

Tutaj mogę śmiało ekspresję ułożyć tak:

<a>{{ text }}</a>

A zwróci mi wyniki (bez HTMLu) dla każdego z tych:

<a class="xyz"><img src="somewhere">Costam</a> -> Costam
<a href="gdziestam" style="font-style:bold;">Tu i tam </a> -> Tu i tam

Ubolewam tylko nad jedną rzeczą…
Read the rest of this entry »

W końcu wziąłem się do roboty i spróbowałem pozyskać więcej numerów gg i coś z nimi zrobić. Jak już pisałem w “O sobie” często coś ciekawego można znaleść w róznych kolumnach. Oczywiście info nie ogranicza się tylko do numerów GG (bardzo popularne są też maile), ale numery postanowiłem przeszukać najpierw. Skrypcik do wyszukiwania wyglądał więc tak:

Read the rest of this entry »

Po raz kolejny dostałem po łapach za moją niekonsekwentność. Zwykle projekty staram się jak najszybciej doprowadzić do jako-takiego działania, po to żeby:

1. Projekt mógł już działać podczas kiedy ja wciąż zajmuje się developingiem
2. Wstępnie już mieć bazę do testów
3. Móc już conieco się przyjrzeć praktyce, a nie projektować kolejnych funkcji na teorii

Takiego podejście może byłoby i owocne, ALE:

1. Trzeba już na początku mieć dobre pojęcie o tym co mamy zamiar zrobić (I wziąć to pod uwagę przy projektowaniu bazy!)
2. Nie iść na skróty
3. Czas developingu powinien być jak najkrótszy

Tak naprawdę nie zastosowałem się do żadnego z tych punktów. Dziś w końcu zdecydowałem się ogranąć trochę kod całego fetchera i przynajmniej zastosować się do części “Good programming practise”. Cóż, nigdy zbytnio nie przejmowałem się nazwenictwem zmiennych, więc czekały mnie m.in. takie kwiatki:

for id in friends:
	cursor.execute("REPLACE INTO husers (id, name, city, friends,fictional,date) VALUES (%s, %s, %s, %s,%s,%s)" ,(id, clean(friends[id]["first_name"]), clean(friends[id]["city"]), friends[id]["friends"],str(friends[id]["fictional"]),friends[id]["date"]))

Co miałem na myśli pierwotnie odwołując się do friends przez… iterację friends (?)  – nie mam pojęcia. W ogóle nie wiem jakim cudem to działa, więc zdecydowałem się tego nawet nie ruszać

Mieszanie języków też nie było nigdy czymś czym bym się przejmował… i tak oto, jak powyższy fragment wyglądał jeszcze przed wstępnymi poprawkami:

cursor.execute("REPLACE INTO husers (id, imie, miasto, znajomi) VALUES (%s, %s, %s,%s)" , (id, clean(friends[id]["Imie"]), clean(friends[id]["Miasto"]), friends[id]["Znajomi"]))

Tabela z angielskiego ‘half-users’, kolumny w tabeli już po polsku. Tablica z danymi po angielsku, kolumny znów po polsku… No, logiczne przecież, nie?

O ile było jeszcze kilka ciekawych kwiatków, to największy problem napotkałem przy unifikacji bazy danych. Tu już w ogóle zaczynała się jazda bez trzymanki biorąc pod uwagę, że z 4 mln rekordów:

1. 2 mln nie miało określonych czy są kontami fikcyjnymi, czy nie
2. Million nie rozróżniał danych ukrytych od ich braku w ogóle, w 1,5mln ukrycie było oznaczone jako “ukryte”, w 1 mln ukrycie oznaczono było jako “[Ukryte]“, a w ostatniej połówce jako “#UKR#-1″
3. W zdjęciach był taki bajzel, że w ogóle nie mam ochoty nawet opisywać
4. Dawni półużytkownicy nie tylko byli zapisani w innym formacie, to jeszcze nie mieli zapisanej dla siebie “daty odkrycia”
5. Duplikaty we wszystkich tabelach referencyjnych.

Nie ma co ukrywać, baza w takim stanie jest prawie nie do odratowania. Zastanawiam się raczej jak takich błędów unikać na przyszłość.

Jeśli chodzi o punkty 1-4 to rozwiązanie nasuwa się samo: projektować tabele tak by nie były potrzebne w przyszłości żadne zmiany.

A punkt 5?
Cóż, MyISAM nie daje żadnej możliwości ustawiania kluczy referencyjnych, czyli omijanie duplikatów mogę zrobić tylko programowo. Sprawdzanie czy taki rekord nie istnieje za każdym razem na tabeli z liczbą wierszy >4mln niestety nie jest dobrym pomysłem. Wygląda na to, że będę musiał przeskoczyć na InnoDB. Kwestia tylko taka, czy VPS za 40zł miesięcznie jest to w stanie utrzymać :-/

PS & Offtopic:
Trzeci raz już czytam ten tekst i trzeci raz widzę błędy ala literówki/brak zaprzeczeń (!?)