Dodatkowo zapraszam (w szczególności uczestników GTUG-a, na którym było więcej kodu) do projektu na Githubie, gdzie wgrałem źródła.

Na koniec chciałem jeszcze podziękować organizatorom za trud włożony w dogranie tych spotkań i Wam, uczestnikom, za przybycie i zadawanie ciekawych pytań :). Do zobaczenia na następnych imprezach.

Podobne wpisy:

1. Wrocław wita JavaScript – Meet.JS i Wrocław GTUG
2. meet.js – JavaScriptowe spotkanie w realu
3. Node.js i middle-end – przenośny kod i emulacja przeglądarki

Problem

Czasami udaje się nam doprowadzić swoją niemałą bazę danych do takiego stanu, w którym część sekwencji będzie źle ustawiona, a tym samym nie będzie możliwe dodawanie nowych danych w standardowy sposób, gdyż kolejnym id wg sekwencji, będzie takie, które już w bazie istnieje.

Możemy wtedy ręcznie naprawić daną sekwencję, zgodnie z manualem:

ALTER SEQUENCE serial RESTART WITH 105;

Gdzie serial to nazwa sekwencji. Co jednak, gdy mamy kilkaset popsutych tabelek?

Rozwiązanie — teoria

Na szczęście PostgreSQL udostępnia nam duuużo informacji o każdej swojej bazie danych w schemie information_schema, która to zawiera zestaw zawsze dostępnych widoków. My tutaj wykorzystamy dwa:

• columns — informacje o wszystkich kolumnach i widokach w bazie
• constraint_column_usage — informacje o kolumnach, które są obłożone jakimś constraintem

To co chcemy zrobić to:

1. Znaleźć wszystkie zestawy tabela-kolumna-sekwencja (bazując na tym, że definicja sekwencji jest stała, zawiera wywołanie nextval().
2. Dla każdej kolumny znaleźć największą wartość identyfikatora.
3. Zrestartować każdą sekwencję z wartością znalezioną w poprzednim kroku i zwiększoną o 1.

Rozwiązanie — praktyka

W praktyce wystarczy wykonać poniższy kod w swojej bazie danych. Tworzy on funkcję naprawiającą sekwencje, wykonuje ją raz i a następnie ją kasuje. Należy pamiętać, że działanie jest ograniczone do schemy public. Jeśli chcemy naprawić inną, trzeba sobie kod lekko zmodyfikować (np. dodając nazwę schemy jako paramert).

CREATE OR REPLACE FUNCTION rebuild_sequences() RETURNS INTEGER AS
$body$
DECLARE
	sequencedefs RECORD;
	c INTEGER;
BEGIN
	-- Find sequence name and primary key column for every table
	FOR sequencedefs IN
	SELECT DISTINCT
		constraint_column_usage.TABLE_NAME AS TABLE_NAME,
		constraint_column_usage.column_name AS column_name,
		REPLACE(REPLACE(COLUMNS.column_default,'''::regclass)',''),'nextval(''','') AS sequence_name
		FROM
			information_schema.constraint_column_usage, information_schema.COLUMNS
		WHERE
			constraint_column_usage.table_schema = 'public' AND 
			COLUMNS.table_schema = 'public' AND
			COLUMNS.TABLE_NAME = constraint_column_usage.TABLE_NAME AND
			constraint_column_usage.column_name = COLUMNS.column_name AND
			COLUMNS.column_default IS NOT NULL AND
			COLUMNS.column_default LIKE ('nextval%')
	LOOP
		-- Find current max PK value
		EXECUTE 'SELECT max('||sequencedefs.column_name||') FROM ' || sequencedefs.TABLE_NAME INTO c;
 
		IF c IS NULL THEN
			c = 1;
		ELSE
			c = c + 1;
		END IF;
 
		-- Rebuild sequence
		EXECUTE 'ALTER SEQUENCE ' || sequencedefs.sequence_name ||' RESTART WITH ' || c;
	END LOOP;
 
	RETURN 1;
END;
$body$ LANGUAGE plpgsql;
 
SELECT rebuild_sequences();
 
DROP FUNCTION rebuild_sequences();

Pierwsza wersja funkcji została napisana przez Klausa ze StackOverflow. Wersja powyżej zawiera poprawki błędów, niedociągnięć oraz formatowania.

Podobne wpisy:

1. Logowanie do pliku wszystkich zapytań w PostgreSQL
2. Migracja MySQL → PostgreSQL aplikacji w Symfony 1.1
3. PostgreSQL: obliczanie odstępów czasu

Meet.JS

Żeby się nie powtarzać, za Damianem Wielgosikiem:

Meet.js jako społeczna i darmowa platforma dzielenia się wiedzą o technologiach front-endowych rozwija się w niesamowitym tempie. Dzięki chłopakom z firmy Monterail.com spotkania meet.js będą organizowane również – obok Poznania, Warszawy i Krakowa – we Wrocławiu.

Pierwszy event odbędzie się w najbliższy czwartek 24.11.2011 w siedzibie Monterail. Start od 18!

Jednocześnie poszukiwani są prelegenci do tego ekscytującego wydarzenia. Jeśli chcesz podzielić się czymś o HTML5, CSS3 czy JS nie zastanawiaj się! Bartek Pietrzak, organizator meet.js, czeka na zgłoszenia wszystkich chętnych pod bartosz@monterail.com.

Więcej informacji na Facebooku, @meetjs i u Damiana.

Wrocław GTUG – Wrocław Google Technology User Group

Z braku weny, również cytat, tym razem z oficjalnej strony wydarzenia:

Zapraszamy serdecznie na pierwsze spotkanie wrocławskiej grupy GTUG.

Zaczniemy krótkim wprowadzeniem na temat działalności naszej grupy. Jednakże tematem wiodącym spotkania będą aplikacje dla platformy Chrome. Poruszone zostaną zagadnienia związane z możliwościami jakie daje ta platforma. Postaramy się zaprezentować przykładowe aplikacje oraz technologie wykorzystane do ich stworzenia.

Na koniec przedstawimy pomysły na kolejne eventy i ewentualne tematy kolejnych spotkań.

Po spotkaniu proponujemy wspólne wyjście na piwo :)

Spotkanie odbędzie się we wrocławskim biurze Google (Bema Plaza) we wtorek, 29 listopada, o godzinie 19:00. Możliwe są jeszcze drobne korekty dotyczące miejsca i na pewno pojawi się formularz rejestracyjny. Tak więc polecam śledzić WroGTUG-a, do wyboru – Facebook, Google+, @wroclawgtug.

Do zobaczenia!

Ja okazji nie przegapię i jeśli studia nie przeszkodzą, to pojawię się na obu spotkaniach. Sam niestety, ze względu na napięty czas przed obroną pracy inżynierskiej, nic nie powiem, ale prelegentów nigdy dość, więc chętni niech się zgłaszają :).

Przy okazji dowiedziałem się, że nie tylko ja uważam, że we Wrocławiu firm zajmujących się frontendem na poziomie praktycznie nie ma. Mamy setki korporacyjnych miejsc pracy dla programistów Javy i C#, ale związanych z webem prawie nie widać. Najgorzej wypada JavaScript, w związku z czym swój wzrok musiałem skierować na Poznań, Kraków, czy Warszawę. Trochę szkoda będzie wyjeżdżać :).

Podobne wpisy:

1. Moja prezentacja o Node.JS z Meet.JS i GTUG Wrocław
2. meet.js – JavaScriptowe spotkanie w realu
3. Walka Dart vs JavaScript – nokaut podczas ważenia

Pożal się Google

To co zrobiło Google, to żart. Cała historia z wewnętrznymi, nie do końca miłymi mailami z Google’a, które wyszły na światło dzienne, sam Dart i otoczka PR-owa jaką ma, to jedno wielkie nieporozumienie. Google się nie popisało i, moim skronym zdaniem, wyjdzie to tylko na dobre open webowi.

Wyobraźmy sobie, co by się stało gdyby Dart rzeczywiście powalał na kolana i miałby świetnie zaimplementowaną, super wydajną i dostępną out of the box w Chrome maszynę. Szybko znalazłoby się grono fan boy’ów, którzy bez zastanowienia zaczęliby pisać aplikacje „only for Chrome”, bądź „works best with Chrome”, z ewentualną, wątpliwej jakości, kompilacją do powolnego i starego JavaScriptu dla „gorszych przeglądarek”. (BTW. hello world w Dartcie skompilowany do JS to 17000 linii kodu :D).

Po chwili okazałoby się, że Google, wykorzystując swoją pozycję lidera na wielu rynkach, zaczyna (pośrednio – przez zadowolonych użytkowników) wymuszać na innych producentach implementację Darta. No dobra – wygrał, ale w czym problem, pytacie? W tym, że Google nie raczy podzielić się odpowiedniej jakości specyfikacją języka i Mozilla, MS, czy Opera zostają zmuszone do reverse engineeringu z Chrome’a. Brzmi jak głupia apokaliptyczna wizja? Problem w tym, że ten przypadek już mieliśmy z protokołem SPDY, ponieważ Mozilla została zmuszona przez Google do zgadywania jak on w szczegółach działa. Koniec końców, po wykonaniu nieprzyjemnej pracy, pozostali producenci i tak kończą z „gorszą” implementacją. Innymi słowy – wracamy do czasów wojny przeglądarek i nieczystych zagrań. W dodatku pieczę nad specyfikacją języka sprawuje Google i wcale nie mamy pewności, czy się nią podzieli.

Dalej brzmi to jak bajka? Ciekawostka – opublikowana „specyfikacja” (wczesny draft oczywiście) Darta ma 70 stron, a specyfikacja wiele razy mniej złożonego ES5 250 stron. I nie, nie z powodu wielkości fonta. Mówicie – są języki, które radzą sobie bez specyfikacji – Python, Ruby – i są świetne (ktoś wymienił PHP – strzał w stopę w tej dyskusji :D). Tak, ale implementuje je jeden producent. W webie to nie działa i nigdy nie działało. Chcecie żeby przeglądarki miały spójne implementacje, to nie cofajcie się teraz o krok wstecz (prawie jak cofać się do tyłu :P). Nie po to wielokrotnie straciliśmy włosy na głowie (a i twarz też, bo czasami głupio się przyznać – „jestem programistą JavaScript”), by zapominać czego nauczyła nas historia. Nie po to został włożony i nadal jest wkładany ogromny trud w to, by ujednolicić i dogłębnie dospecyfikować wykorzystywane przez nas technologie, byśmy teraz tę pracę skreślili i zaczęli od początku. W szczególności, że…

Na poważnie, czyli z forkowaniem za pan brat

… nie ma takiej potrzeby. Wiele osób, w tym i ja, narzeka na JavaScript. Niektórzy wciąż nie wiedzą ile naprawił ES5 ze strict modem, niektórzy też nie zdają sobie sprawy ile jeszcze problemów jest do rozwiązania. Większość jednak narzeka i moim zdaniem słusznie. Na szczęście trwają prace nad ES6 aka Harmony aka ES.next (w których oczywiście Google uczestniczy). O ile, co smutne, ale racjonalne, ES5 nie wprowadził żadnych (może poza strict modem) przełomowych zmian w JavaScriptcie, o tyle ES6 takie zmiany ma wprowadzić, włącznie z dużymi w składni (choć Marcoos mi ostatnio powiedział, że myślą o wydaniu pośrednim, bez zmian składniowych, stąd pośrednie nazwy – oby pomysł upadł – miejcie jaja, Panowie!).

Na pewno jednak ten właściwy ES6 zrywa ze wsteczną zgodnością. Jest więc pole do popisu i czas, by, jeśli ktoś się postara, niemal od nowa projektować pewne aspekty języka. Można mieć tylko jeden zarzut do Harmony – nic nie wiemy o planowanym terminie zakończenia prac. Jednym z argumentów zwolenników strategii Google jest to, że „nie chcieli czekać, aż się powolny komitet naprodukuje i jako największy gracz wzięli sprawy w swoje ręce”. Brzmi niemal przekonująco. Poza tym, że Darta też szybko w wersji stabilnej i szeroko dostępnej nie zobaczymy (jeśli w ogóle). W dodatku praktyka odległej wersji finalnych HTML5 i CSS3 pokazuje, że dzięki wczesnym prototypom częściowym możemy raz, że wiele poprawić jeszcze podczas prac nad specyfikacją, dwa że płynnie przejść pomiędzy wersjami i szybko z nowych ficzerów korzystać. Co prawda JavaScript, to nie CSS, gdzie możemy sobie pozwolić na graceful degradation, jednak gracze typu Google bez problemu mogą serwować inne źródła w zależności od zdolności przeglądarki (a i tak mówimy o kompilacji ES6 do ES3, bo polyfilli to nie będzie). W dodatku wiele osób pisze aplikacje w JavaScript na w miarę przewidywalne środowiska (intranet, komórki, serwer), gdzie problemu nie ma w ogóle.

Stąd przechodzę do pytania – dlaczego Google zamiast forkować istniejące rozwiązania, nie zdecydowało się na wczesną, testową implementację ES6 w V8 (choć zdaje się chodziły takie słuchy)? Dzięki temu mogłoby wpływać na prace komitetu (wprowadzać ficzery w V8 i pokazywać, że świetnie się przyjmują wśród developerów, bądź po prostu dobrze działają), przyspieszyć je i poprawić zawczasu wiele wątpliwych kwestii. Spotkałem się też z argumentem, że konkurencja jest przecież dobra. Owszem, mamy na szczęście kilku producentów i stosunkowo równomierny ich udział w rynku. Moim zdaniem to wystarcza, co widać choćby na przykładzie wcześniej przeze mnie wspomnianych HTML5 i CSS3 (kontrargument swoją drogą, to to, że wyścig rodzi kiepskie implementacje – vide koszmarne formsy).

Bawi mnie niezmiernie jeszcze jedna kwestia. Dart wcale nie jest fajny. Wygląda jak Java, jest toporny, nie ściągnie gawiedzi jak laska z cycem na wierzchu zwana CoffeeSkryptą (BTW. uroda z inteligencją w parze nie idzie – to może ten Dart taki zły nie jest? Małżeństwo z rozsądku? ;). Nie jest też wybitnie rewolucyjny, ani… odległy od ES6. Koncepcje, które znalazłem w Dartcie widywałem też w materiałach o ES6. Jego implementacja też póki co nie powala na ziemię pod względem wydajności, a był to przecież podobno jeden z powodów porzucenia JS. W dodatku pokazuje to jak wiele pracy jest do wykonania, by dogonić już wiele lat rozwijany engine V8. To jest kolejny powód dla którego nie rozumiem decyzji Google’a.

Jest też plus

Jest jednak jedna rzecz, która mi się podoba w Dartcie – szersza biblioteka standardowa (włączając w to sensowną implementację DOM-a). Uważam, że w tej chwili jednym z największych problemów JavaScriptu, jest brak ustandaryzowanych (mniej, lub bardziej formalnie) podstawowych narzędzi. Ja np. w najświeższym projekcie postanowiłem wykorzystać deferred i es5-ext skompilowane do niecommonjsowej postaci. Zastanawiałem się jednak, czy nie wolę underscore’a. Ale zaraz – deferred i tak korzysta z es5-ext, więc ten kod i tak załaduję (tutaj ukłon w kierunku Medikoo – na szczęscie es5-ext jest 100% zmodularyzowane, więc konfigurowalne). Potrzebowałem jeszcze czegoś do DOM-a. Z jQuery nie skorzystam, bo nie potrzebuję 90% (dosłownie!) tej biblioteki, w dodatku pokrywa mi się z deferred i trochę es5-ext, no i szukałem czegoś lekkiego. Trafiłem na xui.js, które okazało się niedopieszczone. Szukałem czegoś do single page apps – Backbone? Nieee… ktoś wymyślił, że dla XHR-a, delegate’a i deferred (i czegoś jeszcze?) skorzysta z jQuery. Jeszcze gorzej chyba ze Spine.js, gdzie znalazłem jakoś z 5 odniesień do jQuery, ale zaszytych głęboko w kodzie, bez możliwości łatwej podmiany. Przy całym tym śmietniku idiotycznych decyzji twórców tych (i wielu innych) narzędzi, są myślące osobniki, które wyprodukowały takie mini biblioteki jak Crossroads, czy js-signals. Robiące dokładnie jedną rzecz i nie zawierające zbędnych zależności.

Żalę się generalnie, ale nie bez powodu. Dart rozwiązałby połowę moich problemów. Mamy i promise’y, i wygodniejszego DOM-a. Dużo więcej ciekawych rzeczy niestety nie znalazłem, ale początek jest dobry. Uważam, że to jest aspekt języka, na który powinny zwrócić uwagę osoby pracujące nad ES6. Wiem na pewno, że jeden problem zostanie rozwiązany – zostaną wprowadzone natywne moduły. Trochę martwi mnie ich rozbieżność w stosunku do CommonJS-owej wersji (i trochę niezrozumiała dla mnie decyzja o wprowadzeniu nowej składni), ale może uda się to zgrabnie rozegrać.

Podsumowując

Nie wierzę, a przynajmniej nie chcę wierzyć, w sukces Darta. Póki co niczym mnie nie zainteresował i nie zamierzam się w niego zagłębiać. Mam nadzieję, że byłaby to strata czasu.

Zauważyliście pewnie, że brakuje w treści linków do źródeł. Tak – nie chce mi się. Google w tym wypadku pomoże :). Poza tym, nie chcę być wyrocznią, nie chcę napisać pracy doktorskiej, nie chcę nikogo zniszczyć, wypunktowując go bezlitośnie. Co więcej, możliwe, że sam niedługo zmienię na co poniektóre tematy zdanie, bo i nie mam pełnej wiedzy o tym co się dzieje i co się stanie. Powyższa opinia rodziła się we mnie jednak już kilka tygodni, więc nie jest też pisana pod wpływem wielkich emocji. Może więc jest racjonalna :).

Podobne wpisy:

1. Wrocław wita JavaScript – Meet.JS i Wrocław GTUG
2. Zarezerwowane słowa kluczowe w JavaScript – gramatyka języka
3. Darmowe szkolenie z programowania gier w JavaScript by DevMeetings

1. Moja prezentacja o Node.JS z Meet.JS i GTUG Wrocław
2. Darmowe szkolenie z programowania gier w JavaScript by DevMeetings
3. Zapraszam na darmowe szkolenie DevMeeting – middle-end w oparciu o NodeJS

Wycofywanie zmian w Subversion można podzielić na dwie kategorie. Pierwsza to wycofywanie zmian lokalnych, jeszcze przed wysłaniem do repozytorium. Druga to odwracanie zmian już zatwierdzonych.

Wycofywanie lokalne

Anulowanie zmian w kopii lokalnej jest w miarę proste i intuicyjne. Wykorzystujemy tutaj podpolecenie revert, po którym podajemy nazwę pliku lub maskę. Opcją którą właściwie trzeba znać jest -R, która włącza wycofywanie rekursywne. Przykłady:

Anulowanie zmian w pliku ‘playground’:

svn revert playground

Anulowanie wszystkich zmian w projekcie (uruchamiane w głównego katalogu):

svn revert -R *

Wycofywanie zmian z repozytorium

W Subversion de facto nie da się wycofać zmiany już zatwierdzonej. Zamiast tego można jednak zatwierdzić zmiany odwrotne do wprowadzonych. Efekt będzie taki jak zamierzony, jednak „wadliwe” zmiany zostaną w historii. Dlatego konieczne jest tutaj użycie podpolecenia merge a nie revert, które, patrząc na nazwę, wydawało by się bardziej intuicyjne.

Zakres zmian do wycofania możemy podać używając dwóch przełączników:

-c Podajemy nr jednego zatwierdzenia, który może być ujemy. Podanie -c 123 jest równoważne z -r 122:123, natomiast -c -64 to to samo co -r 65:64

-r Podajemy zakres zatwierdzeń. Przykładowo -r 100:120.

Podając malejący zakres rewizji lub nr poprzedzony minusem otrzymujemy zmian odwrotne do wprowadzonych, co można sobie fajnie sprawdzić używając podpolecenia diff:

svn diff -r 56:57 testfile 
Index: testfile
===================================================================
--- testfile    (revision 56)
+++ testfile    (revision 57)
@@ -1 +1,3 @@
 Treść początkowa
+
+Wprowadzenie treści błędnej

svn diff -c -57 testfile
Index: testfile
===================================================================
--- testfile    (revision 57)
+++ testfile    (revision 56)
@@ -1,3 +1 @@
 Treść początkowa
-
-Wprowadzenie treści błędnej

Powyższe przykłady prezentują jak podejrzeć wprowadzoną zmianę oraz jak otrzymać patch do jej wycofania. Samo wycofanie polega na scaleniu zmian odwrotnych oraz zatwierdzeniu tej zmiany:

> svn merge -c -57 testfile
--- Reverse-merging r57 into 'testfile':
U    testfile
 
> svn diff testfile 
Index: testfile
===================================================================
--- testfile    (revision 57)
+++ testfile    (working copy)
@@ -1,3 +1 @@
 Treść początkowa
-
-Wprowadzenie treści błędnej
 
> svn ci

Podobne wpisy:

1. Naj- opisy zmian w kodzie

Jak statyczne zmienne działają?

Wielu z nas jest przyzwyczajonych do tego, że elementy oznaczone jako statyczne to coś co występuje tylko w klasach. Jednak słówka static można również użyć w zwykłej funkcji do oznaczenia zmiennej. Czym się różni zwykła zmienna od statycznej?

Wartość statycznej zmiennej jest inicjowana za pierwszym wywołaniem funkcji i zapamiętywana pomiędzy jej kolejnymi wywołaniami. Czyli zachowuje się zupełnie podobnie do klasowych zmiennych statycznych, tyle że nie za bardzo jest do niej dostęp z zewnątrz.

Gdzie to się może przydać?

1. Licznik wywołań funkcji.

Sztandarowym przykładem wykorzystania statycznych zmiennych w funkcji jest licznik jej wywołań, raczej rzadko wykorzystywany w praktyce.

function say_hello_and_count_yourself()
{
    static $counter = 0;
    echo "Hello! I've already said this ".$counter++." time(s).";
}

2. Licznik elementów na stronicowanej liście

Tu już przykład z życia wzięty. Mamy do wyświetlenia listę elementów podzieloną na strony i chcemy wyświetlić liczby porządkowe przy każdym z nich. Do funkcji jako parametr podajemy nr strony i za każdym jej wywołaniem dostajemy liczbę większą o jeden (oczywiście z uwzględnieniem strony na której aktualnie jesteśmy):

function calculate_order_num ($page = 1)
{
	static $i = 0;
 
	return (PER_PAGE * ($page - 1) + ++$i);
}

3. Odróżnianie parzystych i nieparzystych wierzy

Dość często zachodzi potrzeba pokolorowowania co drugiego wiersza w tabeli w inny sposób. Wykorzystując statyczne zmienne, możemy sobie napisać zwięzłą i możliwą do wykorzynia wiele razy funkcję:

function calculate_parity ($word1 = 'odd', $word2 = 'even')
{
	static $current = false;
	$current = !$current;
 
	return ($current ? $word1 : $word2);
}

Wywołując tę funkcję wiele razy będziemy otrzymywać podane wartości naprzemiennie. Przykładowo:

<tr class="<?= calculate_parity() ?>">…
<tr class="<?= calculate_parity() ?>">…
<tr class="<?= calculate_parity() ?>">…

Da nam:

<tr class="odd">…
<tr class="even">…
<tr class="odd">…

Prędkość działania

Miałem podejrzenia, że przechowywanie wartości w zmiennej statycznej może działać nieco szybciej niż w standardowy sposób jednak okazało się inaczej, przynajmniej w jednym prostym teście. Na (pozbawionym sensu) przykładzie sumowania kolejnych liczb:

1) Sumę trzymamy w „globalu” a funkcja do aktualnej sumy dodaje składnik:

function sum_up ($sum, $addend)
{
	return $sum + $addend;
}
 
$sum = 0;
for ($i = 1; $i <= 40000000; $i++)
{
	$sum = sum_up ($sum, $i);
}
 
echo "$sum\n";

Średni czas wykonania: 13-14s.

2) Sumę inicjujemy w funkcji i tam ją trzymamy:

function sum_up ($addend)
{
	static $sum = 0;
	return $sum += $addend;
}
 
for ($i = 1; $i <= 40000000; $i++)
{
	$s = sum_up ($i);
}
 
echo "$s\n";

Średni czas wykonania: 15-16s.

Także jak widać, ze zmiennymi statycznym jest wolniej. Do tego, pierwszy przykład można zoptymalizować, przekazując zmienną przez referencję, ale tego już nie robiłem, żeby zachować odzwierciedlenie działania możliwie dobrze (i mam nadzieje, że nic nie pomieszałem).

Podsumowanie

Podsumowując: bardzo wielu zastosowań dla zmiennych statycznych w funkcji nie widać, jednak w kilku przypadkach mogą one nam całkiem fajnie skrócić i uprościć kod. Jednocześnie trzeba się liczyć z tym, że ich wykorzystanie może nie być najszybszym rozwiązaniem, jednak są to różnice, które dla 99.9% projektów są raczej pomijalne.

Podobne wpisy:

1. Co lepiej wiedzieć o JavaScriptcie cz.2.: hoisting, deklaracje funkcji i wyrażenia funkcyjne
2. PHP: Sortowanie obiektów po dacie utworzenia
3. PHP: prawie jak parametry nazwane

Ekipa organizująca szkolenia zwróciła się do mnie z prośbą, bym zastąpił Davida, któremu wypadły pilne sprawy. Nie mogłem odmówić i zabrałem się za przygotowania. Czego możecie się spodziewać? Na pewno szkolenie będzie kręciło się w okół Node’a i middle-endu. W związku z obserwacjami dotyczącymi problemów, jakie z SSJS mieli uczestnicy warszawskiego meetingu, postaram się wyjaśnić, jak organizować kod, radzić sobie z asynchronicznością, czy pisać przenośne moduły w standardzie CommonJS. Poruszę więc kwestię odmiennych charakterystyk przeglądarkowego i serwerowego JavaScriptu. Wstęp ten przyda się do zadań praktycznych, które tak jak na pozostałych jesiennych meetingach będą kluczowym elementem Krakowskiego szkolenia.

Rejestracja jest darmowa i jeszcze otwarta. Do zobaczenia w Krakowie :)

Podobne wpisy:

1. Darmowe szkolenie z programowania gier w JavaScript by DevMeetings
2. Moje prezentacje z DevMeetings i MeetJS
3. Node.js i middle-end – przenośny kod i emulacja przeglądarki

DevMeetings – hot topics

Na początku lata ekipa z DevMeetings zorganizowała trzydniowy DevCamp, na którym wykrystalizowały się trzy ciekawe backendowe tematy. Teraz nadszedł czas, aby przyjrzeć im się dokładniej. I tak odbędą się po kolei:

• Wydajność Node.JS kontra reszta świata (3 września, Poznań) – kontrowersyjny temat – ile prawdy jest we wszystkich stwierdzeniach o super wydajności Node’a? Trochę na ten temat dowiedzieliśmy się już na DevCampie (polecam zajrzeć do materiałów z naszych badań), jednak wiele osób krytykowało zastosowane podejście jako zbyt oderwane od rzeczywistości. Dlatego tym razem postaramy przygotować się prawdziwą aplikację i na tej podstawie wyciągnąć wnioski. Rozpoczęła się już dyskusja, o tym jak podejść do tematu. Ja oczywiście będę, a Ty wciąż możesz się zarejestrować.
• Bazy noSQL-owe – naturalny storage aplikacji JSON-owych (10 września, Warszawa) – drugi temat na czasie, czyli bazy noSQL-owe (np. CouchDB, MongoDB, Redis). Meeting powinien być interesujący dla zwolenników, jak i przeciwników tego typu rozwiązań, w końcu nie ma nic lepszego niż potężny flame :). Jedni i drudzy dodatkowo dowiedzą się jak radzić sobie w nowym środowisku, które wymaga nowego podejścia (żegnaj SELECT, witaj map-reduce). Tym razem mnie nie będzie, bo do Warszawy mi zbyt daleko, ale i tak polecam :). Również można się jeszcze zarejestrować.
• Middle-end w oparciu o serverside JavaScript (24 września, Kraków) – to temat, na który czekam z niecierpliwością. Z jednej strony bowiem wiem co to middle-end, o którym nawet pisałem, a na DevCampie bawiliśmy się w jego implementacje, z drugiej, faktyczna architektura całego przekroju zastosowań (nie tylko DOM po stronie serwera, ale też np. walidatory) jest dla mnie pewną zagadką. Polecam ten temat wszystkim, którzy zastanawiali się kiedyś tym, czy da się współdzielić kod pomiędzy serwerem i przeglądarką i jak do tego podejść. Ja oczywiście będę i zachęcam do rejestrowania się.

onGameStart – first HTML5 conference

Konferencja organizowana przez Michała Budzyńskiego odbędzie się 22-23 września w Warszawie. Michałowi udało się ściągnąć wielu ciekawych prelegentów, więc na pewno warto posłuchać co mają do powiedzenia. W szczególności, że temat gier budowanych przy użyciu pakietu HTML5+CSS3+JS, jest ostatnimi czasy bardzo na topie i dużo w tej kwestii się dzieje. Mnie niestety nie będzie, mimo że wygrałem bilet, ale polecam zainteresowanym. Bilety po 79 i 89 euro są jeszcze do kupienia. Można też spróbować wygrać bilet u Lidii Wilczyńskiej.

Front Row Conference

Konferencja poświęcona frontendowi, która odbędzie się 20-21 października w Krakowie. Póki co nie ogłoszono zbyt wielu prelegentów, ale dwóch może być Wam znanych. To wspomniany przeze mnie przed chwilą Michał Budzyński oraz znany uczestnikom DevMeetingów Marek Pawłowski. Bilety do kupienia po 123 euro. Na razie, przyznam szczerze, odnoszę wrażenie, że organizatorom idzie topornie z organizacją, ale kibicuję im, bo im więcej tego typu imprez w Polsce, tym lepiej.

Do zobaczenia we wrześniu i październiku!

Podobne wpisy:

1. Falsy Values 2011 – prawdziwy JavaScriptowy event
2. meet.js – JavaScriptowe spotkanie w realu
3. Darmowe szkolenie z programowania gier w JavaScript by DevMeetings

W tym artykule chciałbym wyjaśnić czym jest hoisting i porównać deklaracje funkcji (function declarations) z wyrażeniami funkcyjnymi (function expressions). Zauważyłem, że są to tematy obce wielu programistom JavaScript i myślę, że o ile test z poprzedniego artykułu wielu z Was nie powinien sprawić problemu, o tyle poniższy ma szansę być małym zaskoczeniem. Taką mam przynajmniej nadzieję :).

Źródła z których korzystałem, umieściłem na końcu wpisu.

Sprawdź się!

Spróbuj rozpoznać co wydrukuje każde wywołanie console.log. Skrypt z wszystkimi pytaniami, wraz z odpowiedziami wrzuciłem na Gista.

Hoisting

console.log('3.1:', a);
 
console.log('3.2:', b);
var b = 1;
 
 
console.log('3.3:', c);
if (false) {
    var c = 1;
}
console.log('3.4:', c);
 
 
var d = 10;
(function () {
    if (d === 10) {
        var d = 20;
    }
    console.log('3.5:', d);
})();

Funkcje

a('4.1:');
var a = function (i) {
    console.log(i, '1');
};
function a(i) {
    console.log(i, '2');
}
a('4.2:');
 
 
function b() {
    console.log('4.3: 1');
}
function b() {
    console.log('4.4: 2');
}
b();
 
 
var c1 = function c2(i) {
    console.log(i, c1, c2);
};
c1('4.5:');
c2('4.6:');

Hoisting, czyli wynoszenie

Myślę, że nikomu nie powinien sprawić problemów przykład 3.1. To będzie oczywiście RerefenceError. Co jednak dostaniemy dla przykładu 3.2? Deklaracja zmiennej b znajduje się w kodzie poniżej próby jej użycia, a więc też błąd? Nie – dostaniemy wartość undefined.

Zachowanie to jest efektem hoistingu (po polsku – wynoszenie). Polskie tłumaczenie co prawda lepiej informuje nas o wyniku działania tej konstrukcji, jednak brzmi strasznie, tak więc będę go unikał (przynajmniej w rzeczowniku :).

Czym jest więc hoisting? Jest to wyniesienie deklaracji zmiennych, bądź funkcji do samego początku kontekstu deklaracji (najczęściej ciała funkcji – zasięg funkcyjny), przy jednoczesnym pozostawieniu inicjalizacji samej zmiennej w oryginalnym miejscu. Takie zachowanie jest spowodowane istnieniem dwóch etapów wykonywania kodu, o czym pisze Dmitry Soshnikov:

There are two stages of the code handling: (1) entering the context, where all the data are created, and (2) the code execution stage.

Dla przykładu przyjrzyjmy się następującej funkcji:

var fn = function () {
    var sth = getSomeStuff();
 
    var sthelse = [1, 2, 3];
    for (var i = 0; i < sthelse.length; ++i) {
        var sth = sthelse[i];
    }
 
    for (var i = 0; i < 3; ++i) {
        if (i > 10) var ok = true;
    }
};

Taka funkcja zostanie przez interpreter wykonana w następujący sposób:

var fn = function () {
    // etap 1. - deklaracje
 
    // zmienne automatycznie zostają
    // zainicjalizowane wartością undefined
    var sth, sthelse, i, ok;
 
    // etap 2. - wykonanie
 
    sth = getSomeStuff();
 
    sthelse = [1, 2, 3];
    for (i = 0; i < sthelse.length; ++i) {
        sth = sthelse[i];
    }
 
    for (i = 0; i < 3; ++i) {
        // wyjaśnienie pkt. 3.3: wszystkie deklaracje są wynoszone
        // nawet te do których interpreter nigdy nie dojdzie
        if (i > 10) ok = true;
    }
};

Jak widzisz, wszystkie zmienne zadeklarowane w obrębie całego ciała funkcji zostają zgromadzone na początku. By wyeliminować „magię”, identyczny zabieg stosują ręcznie niektórzy programiści JavaScript i deklarują wszystkie zmienne na samym początku ciała funkcji (czasami wraz z inicjalizacją tych wartości, których wartość jest znana od początku). Ja też tak postępuję jeśli ciało funkcji jest na tyle długie, że mógłbym pogubić się które zmienne mam zadeklarowane, a które nie. Przykład żywcem z kodu, który pisałem wczoraj:

var txt_ratio = Math.ceil(TXT_WIDTH / TXT_HEIGHT),
    rows, cols,
    geometry,
    x, y, i, t, d, xi, yi, rowi, coli;

Jak widać, bywa tego dużo :). Tak na marginesie, o ile w ogóle dobrą praktyką jest dzielić dłuższe funkcje na kilka osobnych, o tyle w JavaScriptcie jest to jeszcze ważniejsze. Dlaczego?

Wady hoistingu

Daleko szukać nie trzeba, by trafić na pierwsze wady hoistingu. W szczególności początkujący programiści nie lubią magii i niejawnych zachowań czy to we frameworkach, czy w językach samych w sobie. Spójrzmy na przykład 3.5 z testu (wyciągnąłem go z prezentacji Damiana Wielgosika):

var d = 10;
(function () {
    if (d === 10) {
        var d = 20;
    }
    console.log('3.5:', d);
})();

Na pierwszy rzut oka myślimy (sam przed chwilą to zrobiłem :D) – d jest równe 10, więc warunek się wykona i dostaniemy wartość 20. Nic bardziej mylnego. Powyższy kod zostanie wykonany w następujący sposób:

var d = 10;
(function () {
    var d; //undefined!
    if (d === 10) {
        d = 20;
    }
    console.log('3.5:', d);
})();

Nieco inny, ale nawet łatwiejszy do doświadczenia, przykład podał Dmitry Soshnikov:

var a = 10;
 
(function () {
    alert(a); // undefined ?
    var a = 20;
})();

CoffeScript na lekarstwo?

Problem ten dostrzegli autorzy CoffeScriptu i postanowili mu zaradzić:

outer = 1
changeNumbers = ->
  inner = -1
  outer = 10
inner = changeNumbers()

Powyższy kod zostanie skompilowany do:

var changeNumbers, inner, outer;
outer = 1;
changeNumbers = function() {
  var inner;
  inner = -1;
  return outer = 10;
};
inner = changeNumbers();

Widać, że zmiennych w ogóle nie trzeba deklarować, ponieważ są automatycznie deklarowane w pierwszym kontekście wystąpienia. Rozwiązuje to problem magii hoistingu, zabezpiecza nam obiekt globalny, ponieważ nie ma opcji, żeby niezadeklarowana zmienna wypłynęła do niego (w czystym JavaScriptcie sprawę załatwia strict mode – polecam). Co jednak jeśli chcemy ograniczyć zasięg zmiennej jedynie do zagnieżdżonej funkcji? Tego chyba autorzy CoffeeScript nie przewidzieli (jeśli się mylę, poprawcie mnie) i dla mnie to duża wada. Dlatego też z tego i kilku innych powodów mówię CoffeScriptowi nie.

A jakieś zalety?

Przedstawiłem wady hoistingu, ale pozostało pytanie – dlaczego w ogóle został wprowadzony, skoro powoduje tyle niejasności? Pytanie jest o tyle dobre, że nie udało mi się znaleźć na nie odpowiedzi. Jedyne o czym wspomina Dmitry Soshnikov to optymalizacja. Jak pokazał jeden z poprzednich przykładów, wyniesienie deklaracji zabezpieczyło nas przed redeklarowaniem zmiennej w pętli (sth), czy przy wielokrotnym użyciu (np. i). Hoisting nie jest jednak jedynym sposobem na radzenie sobie z tymi sytuacjami, tak więc wydaje się, że jego zastosowanie można uznać za złą decyzję twórców języka.

Deklaracje funkcji vs wyrażenia funkcyjne

Temat hoistingu łączy się zgrabnie z tematem funkcji. Okazuje się, że mamy w JavaScriptcie dwie konstrukcje składniowe do ich definiowania. ECMAScript5 specyfikuje obydwie następująco:

FunctionDeclaration :
 
    function Identifier ( FormalParameterListopt ) { FunctionBody }
 
FunctionExpression :
 
    function Identifier_opt ( FormalParameterListopt ) { FunctionBody }

Początkowo wydaje się, że jedyną różnicą jest opcjonalność identyfikatora funkcji. Różnica jednak wynika z możliwości umieszczenia obydwu konstrukcji w różnych kontekstach składniowych. Deklaracja funkcji znajduje się na równi z instrukcją (statement), zaś wyrażenie funkcyjne, jak sama nazwa wskazuje, jest wyrażeniem, które jest dopiero częścią instrukcji.

Domyślam się, że teraz wiesz, że jest jakaś różnica, ale nie wiesz dalej co z niej wynika :). W uproszczeniu można więc powiedzieć, że deklarację funkcji mamy tam gdzie funkcja nie jest wykorzystana jako wartość (jest osobną pseudo-instrukcją). Funkcja wykorzystana jako wartość (jest częścią instrukcji) jest wyrażeniem funkcyjnym. Przykłady:

// deklaracja funkcji
function a() {
}
 
// wyrażenie funkcyjne - zostało przypisane
// więc użycie jako wartość
var b = function (arg) {
    arg();
};
 
// przekazujemy wyrażenie funkcyjne
b(function () {});

Hoisting deklaracji rozwiązaniem testu

Definiując hoisting wspomniałem o tym, że zachodzi on również dla deklaracji funkcji. Inaczej niż w przypadku zmiennych, w tym wypadku wynoszona jest też cała „zawartość” funkcji, nie tylko inicjalizacja zmiennej do undefined. Bardzo spodobał mi się przykład, mojego własnego, skromnego autorstwa, na który, co ciekawe, sam się naciąłem :).

a('4.1:'); // -> 2
var a = function (i) {
    console.log(i, '1');
};
function a(i) {
    console.log(i, '2');
}
a('4.2:'); // -> 1

Na pierwszy rzut oka nie ma w tym żadnego sensu. Kiedy pomyślimy jednak jak wynoszone są deklaracje, wszystko staje się jasne:

var a;
function a(i) {
    console.log(i, '2');
}
a('4.1:'); // -> 2
 
a = function (i) {
    console.log(i, '1');
};
a('4.2:'); // -> 1

Okazuje się, że hoisting deklaracji funkcji niesie ze sobą jeszcze więcej problemów, niż hoisting deklaracji zmiennych. Załóżmy, że mamy dwa pliki ze skryptami. W pierwszym deklarujemy funkcję fn i w drugim również deklarujemy funkcję fn. W środowisku deweloperskim wszystko działa jak należy, jednak kiedy połączymy oba pliki na produkcję, funkcja z drugiego pliku nadpisuje funkcję z pierwszego i teraz również kod z pierwszego pliku korzysta z drugiej funkcji. Co prawda jest to też przykład kiepskiej architektury, ale zdarzyć się może.

Named Function Expressions

Pisałem o tym, że wyrażenie funkcyjne ma opcjonalny identyfikator. Wyrażenia funkcyjne z podanym identyfikatorem, to po prostu nazwane wyrażenia funkcyjne, czyli NFE. Okazuje się, że są bardzo przydatną konstrukcją, ponieważ identyfikator takiej funkcji nie jest widoczny z zewnątrz, a jedynie wewnątrz niej. Przykładem jest ostatnie zadanie z testu:

var c1 = function c2(i) {
    console.log(i, c1, c2);
};
c1('4.5:'); // -> function, function
c2('4.6:'); // -> ReferenceError

Pierwszy powód dlaczego NFE są przydatne, to wycofanie w strict modzie arguments.callee. Dzięki NFE wciąż możemy tworzyć rekurencyjne wywołania. Teraz zamiast pisać (przykład wzięty z wybitnego artykułu kangaxa o NFE):

(function (x) {
    if (x <= 1) return 1;
    return x * arguments.callee(x - 1);
})(10);

Napiszemy:

(function factorial(x) {
    if (x <= 1) return 1;
    return x * factorial(x - 1);
})(10);

Drugi powód to debugowanie. Niestety nienazwane wyrażenia funkcyjne, są niemal anonimowe. Używając ich widzimy później call stack pełen „anonymous function, anonymous function”. I co prawda Google się chwali, że Chrome identyfikuje funkcje anonimowe (po tym do jakich zmiennych, czy właściwości są przypisywane), ale według mnie nie działa to najlepiej. W dodatku jak nazwać funkcję przekazywaną jako callback do jakiejś funkcji? No nie da się. Dlatego w ostatnim projekcie zacząłem nazywać wiele funkcji. Na przykład:

var BigInteger = function BigInteger(num, base, c) {
//...
BigInteger.prototype._addOffset = function _BI_addOffset(n, w) {
//...
BigInteger.prototype.abs = function BI_abs() {

Miałem nie wspominać, ale żeby nie było – Z NFE związanych jest kilka błędów. Większość dotyczy starych wersji Safari (2.x) i Firefoksa (<=3), jednak największym problemem mogą być te związane z IE (<9). Na szczęście są stosunkowo "niekrytyczne", choć jeśli zamierzasz je stosować, to polecam artykuł kangaxa.

FD vs (N)FE – wynik walki

Zdecydowanie wyrażenia funkcyjne. Pomijamy część wad hoistingu, deklaracje funkcji (ponoć) nie wszędzie są dopuszczalne (aczkolwiek nie znalazłem przykładu gdzie nie są – może ktoś zna?), deklaracje funkcji to kiepska kalka z Javy oraz argument ostateczny – 90% naszego kodu to i tak będą wyrażenia funkcyjne.

Źródła, czyli poczytaj więcej

• Dmitry Soshnikov – Note 4. Two words about “hoisting” – bardzo lubię artykuły Dmitry’a, ponieważ schodzi aż do akademickiego poziomu,
• Damian Wielgosik (Ferrante) – prezentacja Just advanced JavaScript – polecam całą, ale część związana z tym artykułem zaczyna się od slajdu 132.,
• Angus Croll – Function Declarations vs. Function Expressions – uzupełnienie i rozjaśnienie tego o czym ja pisałem,
• Juriy „kangax” Zaytsev – Named function expressions demystified – niesamowicie dokładny przegląd dotyczący NFE (m.in. omówienie kilku błędów przeglądarek); tak długie, że nie przeczytałem, ale na pewno to zrobię :D.

Podobne wpisy:

1. Co lepiej wiedzieć o JavaScriptcie cz.1.: typy zasięgu i domknięcia
2. PHP: Statyczne zmienne funkcji — do czego mogą się przydać?
3. Najszybszy stworek – algorytm genetyczny w JavaScriptcie