utf8_general_ci vs utf8_bin

Od jakiegoś roku głowiłem się nad problemem - dlaczego w dokumentacji MySQL LIKE jest case sensitive a u mnie nie. Problem polegał na tym, że wszystkie pola miałem utf8_bin. Oznacza to mniej więcej tyle, że wyszukiwanie odbywa się wtedy binarnie.

Wyszukiwanie binarne, czy sortowanie binarne nie jest czułe na wielkość znaków. Pole utf8_bin wymusza takie właśnie traktowanie i wszystkie zapytania automatycznie działają na danych jako binarne. Dlatego, jeżeli chcesz mieć wybór używaj pól utf8_general_ci a efekty binarne zawieraj w zapytaniu np. BINARY ORDER BY ... itp.

Listowanie na strony

Zawsze miałem problem, z tym jak obliczyć ile stron będzie zajmowało wyświetlenie wyników pewnego zapytania powiedzmy po 30. Jak robiło się LIMIT to COUNT automatycznie zawracało wartość w limicie. Ostatnio kolega podesłał mi takie zapytanie:

mysql> SELECT SQL_CALC_FOUND_ROWS * FROM tbl_name
-> WHERE id > 100 LIMIT 10;
mysql> SELECT FOUND_ROWS();

The second SELECT returns a number indicating how many rows the first SELECT would have returned had it been written without the LIMIT clause.

Więcej znajdziecie tutaj:
http://dev.mysql.com/doc/refman/5.0/en/information-functions.html

Pierwsze wrażenia z programowania w Rails

Powiem od razu nie są najlepsze. Może wpływa na to fakt, że kiedyś na spotkaniu TLUGu jakiś gość zbeształ PHP (porównując go do Rails) więc na dzień dobry podchodziłem do tego zupełnie sceptycznie.

Po pierwsze do tej pory nie udało mi się odpalić procesu i komunikować się z nim na poziomie strumieni 3,4 wykraczających poza standard in/out/err i nikt ze społeczności jak na razie nie jest w stanie mi pomóc.

Kolejna sprawa to dokumentacja. W porównaniu do PHP jest do niczego. Nawet www.noobkit.com czy getapi.com wypada bardzo słabo. Ok - nawet nie porównujemy tego, bo w sumie PHP ma najlepszą dokumentację jaką w życiu widziałem. Ale nawet dokumentacja frameworków PHPowych jest lepsza niż Rails.

Dodatkowo ogromna ilość artykułów niespecjalnie pomaga zorientować się w sytuacji... i odnaleźć drogę do celu :/ co stanowi pewien problem.

To taka pierwsza refleksja - może czas przyniesie zmiany. Zobaczymy.

Program z OJP

Zamieszczam swój program z OJP. Może komuś się przyda - jest tutaj bardzo dużo dobrego kodu (chociaż i słabego nie brakuje)... Mam nadzieję, że ktorą na tym skorzysta.

Powodzenia :)

http://jan.koprowski.zhr.pl/studia/OJP.tar.bz2

Ignorowanie w SVN

Swojego czasu znalazłem ciekawe linki na temat ignorowania w svn.

http://svn.haxx.se/users/archive-2006-01/0494.shtml
http://dotnot.org/blog/archives/2005/12/30/ignore-a-file-in-subversion-svn-ignore/
http://wolfram.kriesing.de/blog/index.php/2005/svnignore-and-svnkeywords

dla wszystkich, którym potrzebna jest ta umiejętność polecam zapoznanie się z nimi.

Troszkę plików z przeszłości

Postanowiłem pokazać co nieco plików z mojej przeszłości... Zamieszczona paczuszka zawiera:

1) Kilka programików ze współbiegów
2) Programy z OJP (C++)
3) Ciut programów z metod numerycznych
4) Program ZOO (katalog OJP), w którym można zobaczyć jak używać MySQL-a pod C++

Mam nadzieję, że komuś się przyda.

http://www.jan.koprowski.zhr.pl/studia/olimp.tar.bz2

OJP część E

W całym programie stosujemy ten sam styl wcięć. Jeżeli szef nakazuje używać K2R to używamy K2R choćbyśmy całe życie używali czegoś innego.




K2R:


for (int i=0; i <= 100; i++) {

-> ...

-> ...

-> ...

}

// wada nie można jednym komentarzem sprawić by pętla wykonała się tylko raz.

// Styl Almana eliminuje ten problem:

// pętla leci tylko raz nie da się tego zrobić w K2R for (int i=0; i <= 100; i++)

{
-> ...
-> ...
-> ...
}

//Tabulacje zamieniamy na spacje. Bo nie ma wtedy problemu przy przeniesieniu z Linux-a na MAC-a programu, w którym zgadzają się wcięcia. Najlepiej jest mieć edytor, który automatycznie umie robić to za nas.

Taki komentrz jest problematyczny

/*

/* */

*/

Nie zadziała wyłączenie sekcji kodu.

Inna metoda wyłączania kodu

#ifndef 0

//

/*

*/

#endif

i tutaj zadziała :)

Dodatkowo, możemy opisywać każdy plik podając na przykład:

autora
data utworzenia
data ostatniej modyfikacji.

Opisujemy też każdą klasę mówiąc (nie programistycznie, ale tak z punktu widzenia modelowanej rzeczywistości) co przedstawia i co robi.

Komentujemy każdą metodę, mówiąc co robi (z punktu widzenia modelowanej rzeczywistości)

Komentujemy trudniejsze kawałki kodu, mówiąc co robią (ogólnie co robi dany kawałek kodu) jeżeli nie widać explicite co robi.

Parametry w stylu "zmienna = "wartosc"" podajemy w plikach nagłówkowych *.h, nie w plikach *.cpp - dodatkowo, jeżeli sparametryzujemy wszystkie parametry np. konstruktora to jest to automatycznie konstruktor domyślny: konstruktor();

Wirtualizacja:

Robimy wirtualizację. Czyli robimy metody czysto wirtualne + destruktor musi być wirtualny.

Zasada substytucji Liskova mówi o tym, że jeżeli wszystkie klasy bazowe zastąpimy pochodnymi to działa nadal poprawnie.