Czym jest HertBeat API?

Heartbeat API umożliwia ciągłą komunikację przeglądarki z serwerem. Komunikacja ta polega na cyklicznym wysyłaniu danych do serwera, który w reakcji na to odsyła dane wykorzystywane przez przeglądarkę. Proces ten jest powtarzany regularnie, przypominając bicie ludzkiego serca, dzięki czemu zresztą zawdzięcza swoją nazwę. Wszystko to odbywa się w tle, nie wpływając tym samym na pracę użytkownika. Ważny jest też fakt, że HeartBeat API startuje automatycznie po załadowaniu strony, ale z serwerem komunikuje się tylko wtedy gdy posiada jakieś dane do wysłania.

Komunikacja przeglądarka -> serwer

Do komunikowania się przeglądarki z serwerem wykorzystywana jest, napisana w JavaScripcie biblioteka heartbeat. Oznacza to, że każdy utworzony skrypt do poprawnego działania wymaga by wcześniej został załadowany plik heartbeat.js.

wp_enqueue_script(
 'heartbeat_example',
 get_template_directory_uri() .'/heartbeat_example.js',
 array( 'heartbeat'),
 '1.0.0',
 true
);

Aby wysłać jakieś dane do serwera musimy je najpierw dodać do kolejki dzięki metodzie wp.heartbeat.enqueue(), która przyjmuje 3 parametry:

• handle – (string) identyfikator wysyłanych na serwer danych. Powinien być unikatowy.
• data – (object) dane wysyłane do serwera
• override – (bool) jeżli true to wcześniejsze dane przypisane do identyfikatora zostaną nadpisane

Przykład użycia:

wp.heartbeat.enqueue('sign_in', {
    'name': 'chemikpil'
}, false};

Dodane do kolejki dane, oczekują na wysłanie do serwera, co następuje co 15 sekund, po czym są z niej usuwane. Aby sprawdzić czy nastąpiło już wysłanie, możemy skorzystać z metody wp.heartbeat.isQueued(handle), która zwraca null lub przypisane do identyfikatora informacje.

Komunikacja serwer -> przeglądarka

Po odebraniu danych przez serwer, są one ponownie zwracane do przeglądarki. Podczas tego procesu uruchamiane są dwa pomocne hooki, dzięki którym mamy możliwość wpływać na informacje wracające do przeglądarki.

• heartbeat_received – filtr pozwalający na modyfikowanie zwracanej odpowiedzi. Dodatkowo przekazywane są również dane przesłane przez przeglądarkę oraz screen_id, lub front jeżeli użytkownik nie jest zalogowany.
• heartbeat_send – filtr działa podobnie do powyższego, z ta różnicą, że nie są przekazywane dane z przeglądarki.

Powyższe filtry działają dla użytkowników zalogowanych i posiadają swoje odpowiedniki dla przypadków, kiedy dany użytkownik nie jest zalogowany:

• heartbeat_nopriv_received
• heartbeat_nopriv_send

Przykład użycia:

function admin_sign_in($response, $data, $screen_id) {
    if (isset($data['sign-in'])) {
        $response['sign-in'] = array(
            'message' => 'admin is here!'
        );
    }
    return $response;
}

add_filter('heartbeat_received','admin_sign_in',10,3);
add_filter('heartbeat_nopriv_received','admin_sign_in',10,3);

Nasłuchiwanie danych

Na koniec pozostaje nam już tylko odebrać dane po stronie przeglądarki. Robimy to poprzez nasłuchiwanie eventu heartbeat-tick.

document.addEventListener('heartbeat-tick.sign-in', 
    function (event, data) {
        if (data.hasOwnProperty('sign-in')) {
            console.log(data['sign-in']);
        }
    },
false);

Konfiguracja

Po za wysyłaniem i odbieranie danych mamy możliwość również konfigurowania samego działania Heartbeat API.

Zmiana pulsu

function heartbeat_api_settings( $settings ) {
    $settings['interval'] = 60;
    return $settings;
}
add_filter( 'heartbeat_settings', 'heartbeat_api_settings' );

Powyżej zmieniliśmy domyślny interwał $settings['interval'], który przyjmuje wartość pomiędzy 15 a 60 sekund. Przypomnijmy ponownie, że domyślny puls wynosi 15 sekund.

Puls możemy również zmienić po stronie JS przy pomocy metody

wp.heartbeat.interval(interval);

z tym że tutaj możemy użyć tylko trzech wartości, które są stringami

• fast – puls co 5 sekund przy czym tylko na maximum 2,5 minuty, po czym wraca do domyślnego ustawienia
• standard – puls co 15 sekund
• slow – puls co 60 sekund

Wyłączenie autostartu

Kolejna zmiana to wyłączenie autostartu:

function heartbeat_api_settings( $settings ) {
    $settings['autostart'] = false;
    return $settings;
}
add_filter( 'heartbeat_settings', 'heartbeat_api_settings' );

Po tej zmianie możemy go ponownie włączyć z poziomu JavaScriptu przy pomocy metody:

wp.heartbeat.start();

Można go również z poziomu JS wyłączyć:

wp.heartbeat.stop();

Podsumowanie

To by było na tyle jeżeli chodzi o HeartBeat API. Jak widać jest to całkiem fajna opcja, dająca autorom pluginów jeszcze większe pole manewrów niż dotychczas. Wystarczy tak naprawdę poznanie kilku JavaScriptowych funkcji oraz filtrów od strony PHP. Nie jest to oczywiście jedyna zmiana, która pojawiła się wraz z „Oscarem”, ale o tym w kolejnych wpisach.

Co nowego?

Najbardziej zauważalną zmianą w nowej wersji Bootstrapa jest nowy design komponentów, który stał się płaski jak iOS 7. Nie jest to jednak żaden nowy trend, jak tłumaczą autorzy, a próba dostarczenia użytkownikom najbardziej neutralnego designu, który pozwalał by na łatwiejsze tworzenie własnych motywów graficznych. Przykładem jest strona bootswatch.com, na której możemy znaleźć kilka ciekawych rozwiązań.

Po za desginem autorzy przepisali cały kod css od nowa, stosując podejście Mobile First. Teraz każdy komponent jest napisany z myślą o urządzeniach mobilnych i skalowany do desktopów, a nie na odwrót, jak w wersji 2.

Po za wyżej wymienionymi nowy Bootstrap to:

• Nowy Customizer
• Poprawiony box model – teraz wszystko ma box-sizing: border-box
• Nowy Grid System
• Od nowa przepisane pluginy JavaScript – niestety wciąż napisane w jQuery
• Glyphicons icon font
• Sporo zmian w samych komponentach CSS

Autorzy dodatkowo postanowili porzucić wsparcie dla IE 7 i FF 3.6, co jest dobrym ruchem, patrząc na to jak archaiczne są to przeglądarki. Zalecane jest również dołączenie pliku Respond.js, jeżeli zależy nam na media queries w IE 8.

Żródła

• Wpis na blogu autorów
• Dokumentacja Bootstrapa

Dlaczego jest to lepsze?

Wszystko rozchodzi o sposób w jaki to narzędzie działa. Emmet LiveStyle nie wymusza na nas trzymania wszystkich plików lokalnie. Tak naprawdę on w ogóle nie interesuje się tym gdzie dany plik się znajduje, a zmiany wprowadza poprzez powiązany edytor tekstu (na razie jest to niestety tylko Sublime Text). Dzięki temu edytowany plik CSS wcale nie musi być tym samym, który jest wykorzystywany w przeglądarce. Idąc dalej, również nowo utworzony i niezapisany plik możemy powiązać z Emmet LiveStyle i wprowadzać w nim zmiany.

Narzędzie to dodatkowo działa w obie strony, a więc również zmiany wprowadzane w Chrome DevTools są przenoszone do edytora. Jedyne co nam zostaje to tylko zapisać taki plik. Wspomniany wyżej np. LiveReload już tego nie potrafi.

To oczywiście nie wszystko. Poniżej znajduje się demo przygotowane przez autora rozszerzenia pokazujące jak to działa. Warto zobaczyć.

Na koniec, Emmet LiveStyle nie radzi sobie niestety z preprocesorami CSS takimi jak np. LESS, SASS, SCSS. Autor jednak zapewnia, że jest szansa by to uzyskać. Na razie zostaje nam jednak używanie np. CodeKit.

Źródła

• Strona główna rozszerzenia
• Instalacja
• Artykuł na Smashing Magazine

Jak definiujemy szablony teraz?

Dotychczas, definiując szablon w dokumencie, mogliśmy skorzystać z dwóch rozwiązań. Pierwsze podejście to tworzenie takiego szablonu jako część DOM i ukrywanie go poprzez display:none lub nowy atrybut hidden:

<div id="myTemplate" hidden>
    <li class="todo-item"></li>
</div>

Drugie podejście wykorzystuje element script:

<script id="myTemplate" type="text/template">
    <li class="todo-item"></li>
</script>

Obydwa podejścia mają swoje wady i zalety, ale nie są to rozwiązania natywne. W3C postanowiło więc wprowadzić element <template>, który takie natywne wsparcie ma nam zapewnić

Element template

Element <template>, jak mówi specyfikacja, pozwala nam na zdefiniowanie fragmentu kodu HTML, który możemy wielokrotnie wykorzystywać w dalszej części naszej aplikacji. Zawartość tego elementu, czyli nasz szablon, nosi nazwę template content i znajduje się pod właściwością content. Poniżej przykładowy szablon.

<template id="myTemplate">
    <li class="todo-item"></li>
</template>

Element <template> ma kilka ciekawych właściwości o których warto pamiętać.

1. Może zostać umieszczony w dowolnym miejscu na stronie, czyli i w <head> i w <body> ale także np. w <table>.
2. Zawartość szablonu jest ignorowana przez przeglądarkę, co oznacza że HTML nie pojawi się na stronie.
3. Wywołanie querySelector (lub jemu podobnych) na elemencie <template> nie zwróci nam żadnego wyniku. Jednak wywołanie tej funkcji na własności content już wynik zwróci:

   var t = document.querySelector('#myTemplate');
   t.content.querySelector('label');

4. Znajdujące się wewnątrz skrypty nie zostaną wywołane.
5. Przeglądarka nie pobierze również obrazków, video czy audio zdefiniowanych w szablonie.
6. Zawartość content jest tylko do odczytu

Wykorzystanie szablonu

Najprostszym sposobem aby wykorzystać zdefiniowany szablon jest utworzenie głębokiej kopii zawartości content, używając do tego funkcji cloneNode(true).

var t = document.querySelector('#myTemplate'),
    todos = document.getElementById('todos');

todos.appendChild(t.content.cloneNode(true));

Warto tutaj zaznaczyć, że w momencie kopiowania zawartości, przeglądarka pobierze wszystkie zdefiniowane wewnątrz obrazki, video ipt. i/lub wywoła napotkane skrypty.

Link do demo (chrome 26+, lub firefox 22+)

Wsparcie przeglądarek

W chwili pisania tego postu jedynie chrome ( 26+) oraz firefox ( 22+) zapewniają wsparcie dla elementu <template>. Jak zawszę odsyłam jednak do caniuse.com aby być na bieżąco.

Aby wykryć wsparcie przeglądarki dla template wystarczy utworzyć ten element w JS i sprawdzić czy posiada on właściwość content.

function supports_template() {
  return 'content' in document.createElement('template');
}

Podsumowanie

To by było na tyle. Specyfikacja dalej się rozwija więc możemy się spodziewać kolejnych zmian, ale już teraz można powiedzieć, że dobrze że taki element się pojawił. Fajnie, że dostaniemy natywną możliwość definiowania szablonów, zamiast bawić się nie do końca semantycznymi rozwiązaniami. Wsparcie oczywiście nie jest jeszcze imponujące ale miejmy nadzieję, że to się szybko zmieni.

Źródła

• W3C spec
• Artykuł na html5rocks.com

Emmet, czym ty w ogóle jesteś?

Emmet to stworzone dla web-developerów narzędzie, a bardziej plugin do ich edytorów, który ciąg znaków, przypominający budową selektory w CSS, zamienia w rozbudowaną strukturę HTML. Dla przykładu poniższy ciąg znaków:

ul#menu>li.item-$*5>a[href=#]{Menu link $}

… po wciśnięciu klawisza tab zamieni się na:

<ul id="menu">
	<li class="item-1"><a href="#">Menu link 1</a></li>
	<li class="item-2"><a href="#">Menu link 2</a></li>
	<li class="item-3"><a href="#">Menu link 3</a></li>
	<li class="item-4"><a href="#">Menu link 4</a></li>
	<li class="item-5"><a href="#">Menu link 5</a></li>
</ul>

Emmet potrafi też pomóc w pisaniu CSS. Fajną rzeczą jest np. skrót lg(…), który na wyjściu daje nam definicje gradientu dla wszystkich przeglądarek.

lg(top, red, blue)

background-image: -webkit-gradient(linear, 0 0, 0 100%, 
                   from(red), to(blue));
background-image: -webkit-linear-gradient(red, blue);
background-image: -moz-linear-gradient(red, blue);
background-image: -o-linear-gradient(red, blue);
background-image: linear-gradient(red, blue);

Problemem przy CSS jest jednak to, że skrótów do zapamiętania jest zbyt wiele, co znacznie utrudnia korzystanie z niego. Emmet postarał się jednak rozwiązać ten problem, wprowadzając fuzzy search. Działa to tak, że za każdym razem kiedy podamy niezdefiniowany skrót, Emmet postara się znaleźć najbardziej zbliżoną do niego definicję. Dla przykłady, aby otrzymać overflow: hidden, możemy użyć skrótu ov:h, który jest właściwy, ale również ov-h, ovh lub nawet oh, które de facto nie występują w dokumentacji.

Akcje

Emmet to nie tylko skróty i klawisz tab. To również wiele bardzo przydatnych akcji. Dla przykładu, możemy w łatwy sposób poruszać się pomiędzy specjalnymi punktami edycji, dodawanymi przez Emmet pomiędzy tagami lub w miejscu na wartość atrybutu. Innym przykładem jest wzbogacanie tagu img o atrybuty width i height, pobrane automatycznie z dołączonego pliku używając klawiszy Shift+Ctrl+U (Shift+Ctrl+i w Sublime Text 2). Więcej akcji znajdziecie w dokumentacji:
http://docs.emmet.io/actions

Składnia, dokumentacja, taka sytuacja

A propo dokumentacji. Celowo piszę tutaj szczątkowo o tym co potrafi to narzędzie, bowiem Emmet w porównaniu do swojego poprzednika ma zdecydowanie lepszą i bardziej przystępną dokumentację. Znaleźć tam można opis wszystkich możliwości tego narzędzia wraz z interaktywnymi przykładami. Nie ma sensu bym to powielał, dodatkowo w gorszej formie. Link poniżej:

http://docs.emmet.io
http://docs.emmet.io/cheat-sheet/

Podsumowanie

Narzędzie jest warte uwagi i polecam je każdemu, o ile w ogóle istnieje jeszcze ktoś, kto o nim nie słyszał. To w jaki sposób ułatwia ono prace jest nie do opisania. Ja osobiście nie potrafię pracować w środowisku gdzie Emmeta nie ma (tak, w notatniku bym sobie nie poradził). Dla mnie jest po prostu must have.

O samej konferencji słów kilka

Edycja 2013 w porównaniu z latami ubiegłymi trwała 3 dni, zaproszonych zostało 24 wspaniałych speakerów, pojawiło się 420 gości. Tyle jeżeli chodzi o liczby.

Rejestracja

Organizatorzy bardzo się postarali by rejestracja nie była głównym punktem do narzekań gości. Wszystko przebiegło bardzo sprawnie i nie odnotowano żadnych poślizgów. Tu ukłon w stronę organizatorów bo rok temu tak dobrze nie było.

Venue

Ponownie wybrano Soho Factory, więc nie ma się co tutaj za bardzo rozpisywać. Kto był rok temu dobrze znał to miejsce. Zabrakło jednak hamaków, a sala gdzie odbywały się przerwy, trzeciego dnia zamieniła się w saunę. Nie były to jednak jakieś duże niedogodności, i osobiście uważam że to dobre miejsce na tego typu eveny.

After Party

Po za oficjalnymi after partami, które zorganizowane zostały po drugi dniu, odbyło się jeszcze kilka nieoficjalnych. Tutaj jak zwykle było epicko i każdy kto się pojawił, czy to w Irish Pubie, czy w Soho nie miał czego żałować. O tym co się tam działo być może przeczytacie kiedyś na PudelekJS.

Co ciekawego mówili speakerzy?

Jak to bywa na takich konferencjach, występy są lepsze i gorsze. Skupię się tylko na tych które dla mnie wydały się najbardziej wartościowe.

Holger Bartel – 180 Degrees East

Holger przedstawił jak wygląda rynek azjatycki i jak dziwny on jest w porównaniu do tego co znamy, czyli Europy lub Stanów. Jako największe różnice wymienione zostały choćby język czy kultura jaka tam panuje. Azjaci kładą na to duży nacisk, co oznacza, że chcąc wejść na ten rynek, od razu trzeba pomyśleć o tym by zatrudnić dobrego tłumacza. Prezentacja głównie pomocna dla tych, którzy myślą o tym by zacząć zarabiać sprzedając swoje produkty w Azji.

Estelle Weyl – Web performance considerations in a mobile world

To chyba najlepsza prezentacja pierwszego dnia. Estelle mówiła o tym co zrobić by nasza strona była lżejsza na urządzeniach mobilnych. Niby nic odkrywczego jak np. to jpg < png < gif czy choćby zdanie dnia jak dla mnie:

The best sentence today „Use querySelector instead of jQuery’s $” #fronttrends

— Michał Maćkowiak (@chemikpil) April 24, 2013

… ale np. ładowanie responsywnych obrazków przez svg, było dla mnie nowością. Warto zainteresować się tą prezentacją, gdy tylko pojawi się w sieci.

Allen Wirfs-Brock – JavaScript: The Machine Language of the Ambient Computing Era

Wspaniałe otwarcie drugiego dnia co było widać choćby po reakcjach na twitterze. Allen opowiedział o tym jak JavaScript wyglądał, wygląda i będzie wyglądał. Pokazał kilka innych zastosowań tego jezyka jak np. asm.js oraz kilka nowości z ES6 jak choćby klasy. Po tej prezentacji wiem, że czekają nas piękne czasy.

Jake Archibald – Rendering without lumpy bits

Kolejna wspaniała prezentacja, głównie przez sposób prowadzenia. Jake pokazał nam kilka problemów związanych z renderingiem i wyjaśnił jak sobie z nimi radzić, robiąc przy tym wspaniałe show. Przypomina mi się Chris Coyier z roku ubiegłego. Poniżej wideo z innej konferencji, na której Jake pojawił się z tym samym tematem:

Link do prezentacja: Rendering Without Lumps

Braniecki i Małolepszy – Responsive localization with L20n

Kolejna dobra prezentacja, której przyjemnie się słuchało, tym razem o narzędziu l20n.org. Nie będę się tu rozpisywał tylko od razu zaproszę do przejrzenia prezentacji. Od siebie dodam, że samo narzędzie wygląda ciekawie, a na dniach pojawi się jakiś wpis o tym jak to działa.

P.S. był to jedyny polski akcent w tym roku.

Lea Verou – The humble border-radius

Na koniec nie mogłem nie wspomnieć o prezentacji Lei, która mówiła o właściwości border-radius. Wydawać by się mogło, że zrobienie z tego prezentacji na 30 min to jakaś abstrakcja. Nic bardziej mylnego. Wiele ciekawych informacji i przykładów. Zresztą przekonajcie się sami: link do prezentacji.

Co przegapiłem?

Niestety przegapiłem też dwie prezentacje, które muszę nadrobić jak pojawi się wideo (organizatorzy wspominali coś o miesiącu oczekiwania):

• The New CSS Layout – Rachel Andrew
• Everybody hates passwords – your site doesn’t need one – Shane Tomlinson

Podsumowanie

No cóż wszystko co dobre szybko się kończy i nie inaczej było w tym przypadku. Wspaniałe 3 dni które na długo zapadną mi w pamięci. Teraz pozostaje czekać na kolejne okazje do spotkań w Warszawie, a najbliższa może nadarzyć się 1 czerwca na warsztatach z Firefox OS.