Geeky links 1

Jeśli mam odkładać setki narzędzi/linków na później/na zapas/do myślowego pudełka z narzędziami, to czemu nie robić tego publicznie. Oczywiście, na pewno istnieje już do tego 20 serwisów społecznościowych, ale… Najbezpieczniej będzie przecież zachomikować linki u siebie na starym dobrym WordPressie.

Treść większości silnie programistycza.

Oraz goście specjalni:

 

JavaScript


Obraz pochodzi z The Profound Programmer

Proste pytanie, idealne na rozmowę kwalifikacyjną…

Mając wywołanie postaci

parseInt("010")

jaki będzie otrzymany wynik?

Początkujący programista JavaScript odpowie „10”.
Doświadczony programista JavaScript odpowie „8, bo liczby zaczynające się od 0 traktowane są jako ósemkowe”.
Firefox 18 odpowie: 8.
Chrome 21 odpowie: 8.
Chrome 23 odpowie: 10.

Bo czemu nie :)
Pamiętaj, jako drugi argument zawsze podaj bazę systemu liczbowego (zwykle 10).
Pytanie dodatkowe: który z wyników jest zgodny ze standardem ECMAScript 5? odpowiedź.

Niby banalny HTML…

Jest sobie HTML. Prezentujemy w nim listę elementów. Ponieważ jest to lista, na przykład lista cech, semantycznie wypada przedstawić ją jako <ul> lub <ol> (unordered/ordered list). Zarazem chcemy, by – bez zaśmiecania kodu HTML – wypisać ją po prostu jako ciągły tekst oddzielony przecinkami, np. „majonez, jajko, ananas„. Robimy to wyłącznie jako element prezentacji, nie samej treści w kodzie HTML. To też nie problem, prawda? Za pomocą CSS dodajemy przecinki za każdym elementem listy, z wyjątkiem ostatniego:

li::after {
  content: ", ";
}
li:last-child::after {
  content: "";
}

Niby wszystko działa… Lecz oto jeśli wewnątrz naszej listy umieścimy podlistę, Google Chrome płata nam figla. Jeżeli załamanie linii wypada po ostatnim elemencie podlisty, przecinek zawija się do drugiej linii, zamiast zostać w tej samej. Wygląda to paskudnie:

Co ciekawe, w Firefoksie problem nie występuje.

Jako ćwiczenie dla czytelnika pozostawiam pobawienie się tym przykładem na jsFiddle.

Lepsze wrogiem dobrego

Publikacja wpisu o problemach po aktualizacji Ubuntu do 11.04 uświadomiła mi, że aktualizacja WordPressa też nie była najlepszym pomysłem…

Uczelniane projekty – odbębnić i zapomnieć? – cz.2a

Dziś dwa projekty bazodanowe pierwszy z dwóch projektów bazodanowych. No cóż, odbębnić przeważa. Bo cóż innego można zrobić, gdy celem ćwiczenia jest „zrobić cokolwiek, co korzysta z TuNazwaTechnologii”. W szczególności irytujące było to przy projekcie „Biblioteka”… ale o tym za chwilę następnym razem :)

Oba projekty realizowane były na semestrze IV, czyli właśnie ukończonym. Oba miały korzystać z baz danych – jeden dlatego, że przedmiot nazywał się „Systemy Baz Danych”, a drugi bo tak. Jako ludzie kulturni realizujemy z Michałem oczywiście najczęściej bazy danych dokumentujące dobytek kulturowy cywilizacji w jakimś sympatycznym zakresie ;-). Dlatego też projekty od samego początku kręciły się wokół kolekcji muzycznej oraz kolekcji książek. No fakt, powodem oparcia się na kolekcji muzycznej było także to, że bazę danych tego rodzaju obaj już robiliśmy… w liceum, na zajęciach z informatyki. To i dane – dość pokaźna ich ilość z licealnej bazy MKLa – były już gotowe.

Jak to wyglądało? Od czego należało wyjść, jakie były wymagania, jak się nad tym pracowało i co z tego wyszło? No cóż… :) Skoro nadal to czytasz, to zapewne lubisz takie narzekania…

Projekt nr 2 – sklep muzyczny

Czemu sklep, a nie kolekcja? Ano bo kolekcja to taka dość statyczna jest i chyba MKLowa baza od początku bardziej sklepową była ;)

Wymagania? Jakaś baza, kilka tabel, jakieś relacje między nimi, jakiś formularz, jakieś raporty. I „żeby coś liczyło w bazie”. Technika realizacji? Dowolna, czyli MS Access 2003, a przynajmniej tak zrozumiała tę dowolność znakomita większość grupy (roku?). My się wyłamaliśmy i [żeby się nie męczyć :P] zrobiliśmy to w czymś, co znamy i w czym powstawała licealna wersja projektu: nieśmiertelny tandem PHP+MySQL. O dziwo PHP na uczelnianym serwerze jest, a MySQL można sobie utworzyć. Bezboleśnie.

Zasadniczo główny kod został rozbudowany i dopieszczony przez MKLa, bez bicia przyznaję, że mój udział był raczej znikomy, a są miejsca, że nawet nie wiem, jak coś działa ;P Cóż więc tu mogę powiedzieć.

W warstwie prezentacji (student informatyki umie stosować mądre określenia na proste rzeczy) jest to bardzo prosty HTML potraktowany bardzo prostym stylem CSS, a grafika całej strony z podstronami zamyka się w kilku obrazkach. Błękit (miał być szafirowy, okazał się wpadać w ciemny turkus – bo nie miałem skalibrowanego monitora), pomarańcz, trochę ciemnej czerwieni tam, gdzie pole powoduje zmiany w bazie.

Strona główna sklepu z rozwiniętym pierwszym działem Sklep muzyczny - wybrany jeden album bez okładki
Sklep muzyczny - raporty dot. zamówień Sklep muzyczny - wybrany album z okładką

W sklepie znalazło się też kilka javascriptowych myków takich jak obsługa okłądki płyty – gdy nie ma nic w bazie, mamy „brak okładki” widziany na screenie nr 2, ale gdy jest wpis w bazie, a nie uda się pobrać poprawnej okładki (link jest nieaktualny – bo tak naprawdę okładki kradniemy z innych serwisów ;P), to JS podstawia znów domyślny obrazek „brak okładki”, by nie zostawić brzydkiego krzyżyka. Drugi myk to formularz, w którym ustalamy kryteria do wygenerowania raportu – wszystko jest w nim kosmicznie dynamiczne (hail to MKL) – treść formularza zmienia się w zależności od wybranych opcji, natychmiast po kliknięciu (no AJAX here).

Tak, sklep jest zrealizowany od strony zarządzania sklepem, a nie z punktu widzenia klienta! Daje to większe pole manewru do dłubania w bazie danych.
Zamówienia początkowo były na każdy album z osobna, ale pani prowadząca przedmiot nie czuła się z tym dobrze i trzeba było dorobić jakieś „koszyki” ;-)

Tu można pobawić się sklepem i jego bazą danych – ale proszę nie psuć. Bazę ewentualnie możemy co jakiś czas przywracać do stanu oryginalnego (przykładowego), ale lepiej nie stwarzać ku temu okazji ;) W razie nadużyć sklep i baza zostaną po prostu usunięty z konta, więc po co to komu ;)

Największy ból projektu?

Największym problemem było tu… oddanie projektu. Mieliśmy gotowy długo przed terminem, ale prowadzące nie wykazywały zainteresowania / nie potrafiły znaleźć czasu (?), by rzucić na niego okiem. Dlatego też poprawki pod kątem ich widzimisię takie, jak wprowadzenie koszyków, trzeba było robić pod koniec semestru, gdy chcieliśmy zająć się innymi przedmiotami.

Czego nauczył mnie ten projekt?

Y… e… zakładać konto MySQL na uczelnianym serwerze. Śmiać się z tych, którzy psioczą miesiącami na Accessa, a robią w nim projekt przecież z własnego wyboru, lub nieświadomości, że wybór w ogóle był. Ale o tym przecież była mowa już na początku semestru..

Nie nauczył mnie natomiast wygenerowanego losowego hasła do bazy danych – o wiele za długie i zbyt losowe ;) Więc kilkukrotnie jeden z nas je dyktował, a drugi klepał :D

Czas wykonania – no idea.
Skład: ikari & MKL.
Podział pracy: unfair. [yeah, przyznaję]
Satysfakcja: 7/10 [just because]