Niecodziennik krytyczny

Tym razem w konkursie programistycznym Codecup pojawiło się zadanie podchwytliwe - ciekawe ile osób próbowało tego samego rozwiązania co ja i zdziwiło się pojawiającym się komunikatem :). Treść zadania to napisanie funkcji konwertującej zadaną liczbę z jednego systemu liczbowego na inny (pełna treść zadania 20). Rozwiązanie trywialne...

Czytaj dalej...

Prezentuję kolejne moje kodziwo z serii rozwiązań zadań publikowanych w serwisie CodeCup.pl. Treść zadania to "Napisać funkcję, która obliczy współrzędną kuli po przetoczeniu przez daną liczbę poziomów i zapadni" (pełna treść zadania). Tym razem zadanie było prościutkie, udało mi się je rozwiązać w kilkanaście minut, łącznie z opracowaniem przypadków testowych. Co więcej, pochwalę się, że moje rozwiązanie ma aż 7 linijek kodu z nawiasami zamykającymi i returnem włącznie, a przykładowe rozwiązanie zadania ma tych linijek 26, tak więc udało mi się otrzymać w rezultacie dodatkowe punkty za styl. A o to i kodziwo:

Czytaj dalej...

Jakiś czas temu obiecałem przedstawić rozwiązanie zadania 15 z konkursu na stronie codecup.pl. Czas dotrzymać słowa, tak więc publikuję moje rozwiązanie i jeśli ktoś ma ochotę, to zapraszam do komentowania, ulepszania, itp. :)

Czytaj dalej...

Na joggerze Albiego znalazłem link do ciekawego serwisu CodeCup.pl, w którym można wziąć udział w turnieju kodowania w PHP. Co jakiś czas publikowane jest nowe zadanie. Od momentu publikacji, wraz z upływem czasu, aż do chwili rozwiązania go przez pierwszą osobę, rośnie punktowa stawka za przesłanie poprawnego kodu. Każda następna osoba, otrzymuje odpowiednio mniejszą liczbę punktów.

Dzisiaj udało mi się rozwiązać za pierwszym podejściem zadanie 15 (po ogłoszeniu wyników postaram się podzielić się moim kodem). Muszę przyznać, że

Czytaj dalej...

Dzisiaj, po ponad roku pracy w WP, nastąpiła u mnie oficjalnie zmiana:

• Dział: Zespół Obsługi Klientów -> Zespół Projektów WWW
• Stanowisko: Specjalista ds. Obsługi Klienta -> Programista Stażysta

Skrobiąc dzisiaj swoją stronę napotkałem pewien problem, który teoretycznie mógłby wymagać stworzenia kilku różnych arkuszy styli. Załóżmy, że mamy stronę, której każda podstrona jest utrzymywana w innej kolorystyce. Oczywiście nie jest problemem stworzyć takie arkusze, jednak przy najdrobniejszej modyfikacji musimy uwzględnić ją we wszystkich plikach, a to już może być z lekka dokuczliwe.

Problem można rozwiązać badzo prosto w przypadku, gdy mamy na serwerze dostęp do PHP. Załóżmy, że mamy następujący szablon Smarty:

{if $DZIAL eq "oferta"}
	<link rel="stylesheet" type="text/css"
        href="./style.php?main=blue&second=red" />
{elseif $DZIAL eq "sklep"}
	<link rel="stylesheet" type="text/css"
        href="./style.php?main=green&second=blue" />
{elseif $DZIAL eq "onas"}
	<link rel="stylesheet" type="text/css"
        href="./style.php?main=red&second=green" />
{/if}

Jak widać, skrypt style.php jest odpowiedzialny za wygenerowanie arkusza CSS. Informacje, w tym przypadku o kolorystyce, przekazujemy za pomocą zmiennych.

Plik style.php w większości przypadków będzie wyglądać tak jak zwykły CSS. Jednak na samym jego początku trzeba wysłać jeden nagłówek:

<?php header ('Content-Type: text/css'); ?>

Na brak nagłówka odporny jest IE co oczywiście o nim dobrze nie świadczy, mimo, że akurat w tym momencie piszący strony pod niego nie będą narzekać. Firefox zaś zachowuje się tak jak powinien i jeśli nie otrzyma nagłówka to po prostu nie zaaplikuje stylu z nieznanego typu pliku.

Po zabiegach z nagłówkami możemy przystąpić do tworzenia styli. Sposób zapisu nie różni się niczym od zapisu zwykłego CSS'a. Jednak w pewnym momencie dochodzimy do miejsca, gdzie chcemy dynamicznie wygenerować dane. Możemy to zrobić w następujący sposób:

#navcontainer a:hover, #active a:link, #active a:visited {
	background: 
	<?php 
		switch ($_GET['main'])
		{
			case 'blue' :
				print '#0fb6ed';
				break;
			case 'red' :
				print '#ff3d33';
				break;
			case 'green' :
				print '#bde24e';
				break;
		}
	?>
	url('gfx/new/ground_dot_<?php echo $_GET['second'] ?>.gif');
}

#active a:hover {
	background-color : 
	<?php
		switch ($_GET['second'])
		{
			case 'blue' :
				print '#0fb6ed;';
				break;
			case 'red' :
				print '#ff3d33;';
				break;
			case 'green' :
				print '#bde24e;';
				break;
		} 
	?>
}

Jak widać, metoda całkiem przyjemna i pokazująca, że PHP można wykorzystać do ułatwienia sobie życia w wielu miejscach.

IE jak zwykle wymiata. Zgodnie z dobrym zwyczajem chciałem sobie elementy formularza powsadzać w znaczniki <fieldset>. Po radosnym wykorzystaniu go postanowiłem sobie go ostylować dając mu border : dotted. Czas jakiś pracowałem, ładnie wszystko pod Firefoksem wyglądało, aż w końcu nadeszła ta wiekopomna chwila gdy sprawdziłem co tam słychać pod IE. Moim oczom ukazało się takie oto cudo:



Jak to zobaczyłem to już zacząłem kombinować co tu z tym fantem zrobić i jak go zamienić bo przecież zleceniodawcy, który to kilka dni temu dowiedział się ode mnie, że są inne przeglądarki niż IE, nie dam takiego syfu. Zanim jednak zacząłem radośnie wywalać fieldsety coś mnie tknęło i zmieniłem ostylowanie na border : solid. Efekt:



No po prostu rewelacja. Pozostawiam bez komentarza po raz kolejny zdolności programistów z Redmond do wyczyniania cudów i wprawiania mnie w zadziwienie...

Aha, jakby się ktoś na przyszłość zastanawiał to w IE dashed == dotted. Jak to pirveli określił: "Sprawdzanie odbywa się po pierwszej literze" :)

Grzebiąc sobie po archiwach grupy pl.comp.lang.php natknąłem się na wzmiankę o tzw. teście porneLa. Test ten dotyczy sprawdzenia czy rzeczywiście to co pracowicie stworzyliśmy jest pełnowartościowym, możliwym do pełnego wykorzystania XHTML'em czy też jednak nie. Jak się okazuje, samo sprawdzenie strony Validatorem W3C niewiele daje, gdyż nie wykrywa on pewnego drobnego, a jednak ważnego szczegółu. Szczegółem tym jest sposób określenia Content-Type. Bardzo często spotyka się strony chwalące się znaczkiem zgodności z XHTML, które wysyłają dokument z nagłówkiem Content-Type: text/html co powoduje, że będzie on traktowany jako zwykły, najczęściej jeszcze błędny dokument HTML. Aby wykorzystać w pełni możliwości naszego X powinien on zostać wysłany z nagłówkiem application/xhtml+xml. Niestety odnośnie tej drugiej możliwości standardy W3C określają ją jako 'SHOULD', a nie 'MUST' wobec czego takie strony są zgodne ze standardem XHTML aczkolwiek tak samo (o ile nie mniej) użyteczne jak zwykły HTML.

Aby jednak nie przepisywać napisanych już tekstów teraz garść odnośników:

• Irracjonalne uwielbienie dla XHTML - strona porneLa, na której możemy poczytać jak dokładnie powinien wyglądać poprawny XHTML i dlaczego jednak go używać plus oczywiście wcześniej wspomniany "test porneLa"
• Content Negotiation - czyli co zrobić jeśli naszą stronę w XHTML będą odwiedzać internauci wyposażeni w przeglądarki nieinterpretujące lub interpretujące XHTML czy chociażby google.
• XHTML Media Types - krótka specyfikacja z W3C

A na koniec dodam taki jeden miły szczególik: po wysłaniu application/xhtml+xml nasza nowoczesna przeglądarka (np. Firefox) zamienia się w niezły validator, który bonusowo nie jest wrażliwy np. na to, że generujemy strony na podstawie danych przechowywanych w sesji co jak wiadomo jest oczywistą bolączką validatora z W3C ;)

W przypadku gdy parser php wywali błąd

Parse error: parse error, expecting `T_STRING' or `T_VARIABLE' or `T_NUM_STRING'

to należy zakomentować kawałek kodu, który zawiera tę linię. Jeśli nadal parser wywala nam błąd w tymże komentarzu, to należy sprawdzić czy 110 linijek wcześniej nie umieściło się przez przypadek znaczka ` zamiast [tab] ;)

To tak ku pamięci półgodzinnego szukania małego dziada ;)

Podczas dynamicznego generowania formularzy na podstawie informacji z bazy danych często przydatne jest wprowadzenie ukrytej tablicy, która zawiera nazwy interesujących nas zmiennych wykorzystanych w tymże formularzu. Przykładowo może to być coś takiego:

<select name="cat24">
  bla bla bla
</select>
<input type="hidden" name="varnames[]" value="cat24" />

Po wysłaniu takiego formularza wystarczy w prosty sposób przejrzeć zawartość zmiennej $varnames i można "zaopiekować się" potrzebnymi danymi np. w taki sposób:

$catsinfo[$dbrow['cat_id']] = array ('label' => $dbrow['label'],
  'crits' => $crits, 'selection' => ${$varnames[count ($catsinfo)]});

Oczywiście ktos mógłby powiedzieć po co wymyślać ukryte zmienne jak można wykorzystać np. $_POST i też ma się dostęp do wszystkich zmiennych. Jednak nie zawsze się tak da, gdyż można potrzebować informację na temat pewnego określonego zbioru zmiennych.

Pewien mały problem powstaje w przypadku, gdy powyższą linijkę będziemy chcieli użyć w funkcji. Jak wiadomo wewnątrz funkcji jeśli zmienne nie są zadeklarowane jako global to będą miały zasięg lokalny tylko wewnątrz ciała tej funkcji. Jeśli jesteśmy w stanie przewidzieć jakie zmienne chcemy wykorzystać to raczej nikt nie będzie zastanawiać się co zrobić z tym fantem. Co jednak ze zmiennymi zmiennymi? Ano to:

foreach ($varnames as $value)
    global $$value;

Otóż rozwiązanie jest w sumie banalne aczkolwiek w pierwszym momencie gdy pojawił mi się ten problem to chwilę musiałem pomyśleć, żeby wymyśleć ;)

Oberwała dzisiaj po łbie moja opinia o Mozilli. Otóż jest w niej (w FF przy okazji też) problem, że nie daje się wykonać zmiany wielkości czcionki dla elementów typu "input". Jakoś do tej pory specjalnie mi to nie przeszkadzało, aż w końcu dzisiaj zaczęło. Po poszukiwaniach googlowych gdzie bardzo często spotykałem się z tym spostrzeżeniem, że "tak po prostu jest" znalazłem perełkę na jednej ze stron z opisem co zrobić, żeby tak jednak nie było.

Otóż jak się okazuje jest sobie taki pliczek: /Mozilla/Firefox/Profiles/[xxxxxxx]/chrome/userContent.css a w nim piękny wpis:

1. input {
2. font-size: 12px !important;
3. }

No jak zobaczyłem to important to normalnie ręce mi opadły na myśl o tym, że Mozilla aspiruje do myślenia za mnie i za tysiące webdesignerów, którzy chcieliby sobie jednak zmienić font-size tak jak sami sobie wymyślili. Normalnie pod pręgierz stawiam Mozillę i wysmażam jej za to piękne czarniutkie piętno.

Po raz kolejny musiałem się nawkurzać na beznadzIEjność wiadomo czego i spędzić prawie godzinę na szukaniu rozwiązania. Problem jest następujący: stworzyłem menu na divie, w którym to umieściłem na przemian img oraz inne divy z treścią i z podkładem typu background : url ('...');. W Mozilli oczywiście wszystko pięknie gra bo jakby nie patrzeć obydwa typy obrazków są tej samej wysokości, div je zawierający jest również tej samej wysokości więc nie ma powodów, żeby miało coś nie grać. IE oczywiście się zamotał skutkiem czego dostawił ot tak sobie 2 dodatkowe piksele co spowodowało piękne zawinięcie tła w głównym divie i ogólnie sieczkę. Rozwiązanie wydawałoby się proste: dać background : no-repeat; ale niestety 2 dodatkowe piksele w IE nadal pozostają.

I tu zaczęło się googlanie za tym co zrobić z tymi 2 pikselami. Jak się okazało, problem dość popularny ale rozwiązanie już mniej. W końcu jednak coś mi się udało znaleźć. Jak się okazało, rozwiazaniem problemu IE z obrazkami jest następujący wpis w CSSie dla znacznika img: vertical-align : bottom; No dobrze, odpalone, w IE pięknie już wygląda ale za to Mozilla i Opera się zamotały i obcięły sobie na odmiane dwa górne piksele ze wszystkich obrazków... No to cóż, trzeba zastosować kolejnego, drugiego już hacka, żeby na odmianę poratować niebadzIEwne przeglądarki :) Jakby ktoś był ciekaw ostatecznego rozwiązania to jest takie:

1. img {
2. padding : 0px;
3. margin : 0px;
4. border : none;
5. /* hack na IE i 2px padding od dołu obrazka */
6. vertical-align : bottom;
7. }
9. /* Hack przywracający domyślne ustawienia Mozilli i Operze */
10. div>img {
11. vertical-align : baseline;
12. }

Wczoraj spotkałem się z bardzo interesującym i efektownym zjawiskiem jakie przydarza się floatowanym elementowm w badzIEwiu. Pakuję sobie wszystko w divy, floatujące właśnie. Pod Mozillą, FireFoxem i Operą wszystko pięknie działa. Problem pojawia się, jakżeby inaczej, po odpaleniu w IE. Otóż jest taki efekt, że część tekstów na stronie nie wyświetla się. Po zaznaczeniu kawałka tekstu, który nie wyświetla się, pojawia się on, po kliknięciu poza zaznaczeniem tekst ten pozostaje nadal widoczny, a część, która nie była zaznaczana dalej jest niewidoczna. Drugi efekt to taki, że jak się odpali tę stronę w IE, przejdzie na dowolne inne okienko i znowu wejdzie na IE z odpaloną wcześniej stronką to teksty automagicznie się pojawiają.

Trochę zgłupiałem przy tych dzikich, jakby nie patrzeć, efektach. Więc zapytanko na grupy dyskusyjne sobie wysłałem. Jak się okazało, problem dość znany i polegający na tym, że div bez podanej szerokości, który znajduje się w środku floatowanego diva (z podaną szerokością) powoduje zamotanie się badzIEwia, gdyż nie wie ono co ma zrobić z tym fantem i skutkiem tego po prostu sobie losowo ukrywa bądź pokazuje tekst w tymże divie. Żeby było ciekawiej to inne elementy typu obrazki, formularze pokazuje prawidłowo, tekstu tylko sobie nie wyświetla :] Ech, jaki świat byłby prostszy, gdyby badzIEwie zniknęło z powierzchni ziemi...

Ja to pewnie dziwny jestem, że w jeden dzień cieszę się z otrzymania praktyk programistycznych w firmie. Na drugi dzień zabieram się za zlecone małe zadanko i zaczynam mieć wątpliwości by po chwili sobie pogooglać i znaleźć parę niezwykle interesujących opinii na temat pracodawcy. Jeszcze w ten sam dzień dostaję właściwie przez przypadek zlecenie wykonania pewnemu całkiem miłemu biznesmenowi sklepu internetowego co skutkuje nieodwołalną decyzją rezygnacji z praktyk i "związania się z obiecującą firmą webdesignerską" :D Cóż, trzeba się cenić i swój kod :D W ramach rozrywki parę linijek kodu stworzonego przez "obiecującą firmę":

1. if($zadeklarowalem_juz_huz!=TRUE OR mysql_ping()==FALSE)

1. if($tryb_debugowania>0)

1. if(!include_once("./lib/class_login.php"))
2. {
3. die('Fatal error numer 0');
4. }

1. W jednym dokumencie <br>, <BR>, <br /> i hit wieczoru <BR />

1. echo "Wykonanie zapytania:<br>\n";

1. global $_SERVER;

1. for (reset($key);$name=key($key);next($key))

1. $Session = "";
2. unset($Session);

1. $LANG['<left><b>Podczas rejestracji napotkano na nastżpujżce b??edy:</b><br> <ul><li>Pole <b>nazwa firmy</b> nie zosta??o wype??nione. Jego wypelnienie jest wymagane.</li> <li>Pole <b>ulica</b> nie zosta??o wype??nione. Jego wypelnienie jest wymagane.</li> <li']="<left><b>Podczas rejestracji napotkano na nastżpujżce b??edy:</b><br> <ul><li>Pole <b>nazwa firmy</b> nie zosta??o wype??nione. Jego wypelnienie jest wymagane.</li> <li>Pole <b>ulica</b> nie zosta??o wype??nione. Jego wypelnienie jest wymagane.</li> <li";

1. function lang($wyrazenie)
2. {
3. return la($wyrazenie);
4. }

1. if(nrsql($w)>0)
2. {
3. return true;
4. }else{
5. return false;
6. }

1. W zapytaniu SQL:
2. AND wykorzystany='nie'

Mimo, że co kawałek to co w tytule piszę to zawsze mnie to na swój sposób rozśmiesza :D

W takim razie coś dla PHP'owców:

1. $question = to_be () || (!to_be ()) ? live ('') : die ('');

Przeżył? :P