Stosunkowo często możemy spotkać się z sytuacją, w której aplikacja działająca przez sieć udostępnia w sobie wbudowany serwer WWW nadający na określonym porcie. Problem rozpoczyna się w sytuacji, gdy jest to nasza jedyna opcja, a mimo to chcielibyśmy mieć jakiś bardziej przyjazny adres w postaci np. subdomeny.

Dziś na szybko zademonstruję konfigurację hosta w serwerze nginx właśnie tak, aby przechwytywał on ruch występujący na określonym porcie - w tym wypadku na przykładzie Gitea (społecznościowego forku Gogs, lekkiego serwisu w stylu GitHub do samodzielnego hostowania). Wystarczy nam wiedzieć, że domyślnie jest on dostępny na porcie 3000, a naszym celem jest subdomena git (na potrzeby wpisu załóżmy że będzie to git.sobak.pl). W celu przekierowania ruchu wykorzystamy jedno z powszechnych zastosowań serwera nginx, znane jako reverse proxy.

server {
	listen 80;

	server_name git.sobak.pl;

	location / {
		proxy_pass http://localhost:3000;
	}
}

Tak, tylko tyle i aż tyle. W wypadku gdy korzystamy z HTTPS, zmieniamy drugą linijkę na listen 443, czyli odpowiedni dla tego rodzaju komunikacji port. Podany plik prawdopodobnie będziecie musieli zapisać w lokalizacji /etc/nginx/sites-available/git.sobak.pl i zsymlinkować z sites-enabled, czyli tak jak dla każdego innego hosta w nginxie. Pamiętajcie o zmianie przykładowych wartości subdomeny i portu - pamiętajcie że to rozwiązanie absolutnie nie ogranicza się do tej jednej aplikacji lecz stanowi ogólny schemat postępowania.

Powyższy wpis jest realizacją wymogów konkursu "Daj Się Poznać". Więcej o nim możecie przeczytać w tym wpisie. Po nowe materiały poświęcone tworzeniu projektu Codice, z którym startuję w konkursie, zapraszam w każdy wtorek. Ponadto więcej wpisów, poświęconych temu projektowi lub ogólnej tematyce bloga przeczytacie co sobotę. Miejmy nadzieję że publikacja dwóch wpisów w niedzielę jest tylko niewinnym wypadkiem przy pracy ;)

Dzisiejszy wpis będzie skierowany do osób zaczynających swoją przygodę z systemami kontroli wersji (VCS). Mimo że porady będą bazowane na systemie git, większość z nich można z powodzeniem zastosować także dla jego alternatyw.

Rozmiar commitu

Jest to rzecz, z którą - według moich obserwacji - początkujący mają największy problem. Nie istnieje bowiem idealna ilość zmian w jednym commicie, którą możemy się kierować za każdym razem. Myślę, że commit o dobrym rozmiarze najprościej jest zdefiniować słowem samodzielny. Co takiego mam przez to na myśli?

• zmiany w commicie powinny stanowić działąjącą całość, nie powinno się commitować kodu, który generuje na przykład błąd parsera
• commit powinien obejmować jedną funkcjonalność. Ponownie, nie da rady zdefiniować jak dużo obejmuje jedna "funkcjonalność". Spróbuj jednak postąpić w ten sposób - wyobraź sobie, że commit, który masz zaraz wyślesz, będzie musiał zostać cofnięty (np. komendą git revert). Czy robiąc to, pozbędziesz się tylko jednego kroku, czy też będziesz musiał w osobnym commicie powtórzyć część z dokonanych wcześniej zmian (które właśnie hipotetycznie cofnąłeś). Jeżeli zachodzi druga sytuacja, to commit jest za duży.

Opis commitu

Bądźmy szczerzy, każdy lubi czasem popuścić wodze fantacji wpisując wiadomość commitu. Najczęściej jest to danie upustu frustracji, która towarzyszyła tworzeniu danego kodu. Powstały nawet specjalne strony jak whatthecommit.com. Warto jednak poświęcić kilka sekund więcej na napisanie wiadomości commitu, aby w przyszłości zaoszczędzić swój czas.

Opis commitu jest wykorzystywany w bardzo wielu sytuacjach - komendach git log, git rebase, git blame, czy ich odpowiednikach w serwisach typu GitHub. Traktuj opis commitu tak, jakbyś musiał go przeczytać i szybko zrozumieć kilka dni później. Staraj się być zwięzłym i rzeczowym - jeżeli nie ze względu na siebie, to na współpracowników.

Kolejną sprawą jest możliwość podzielenia commitu na krótki opis główny i dłuższą (opcjonalną!), bardziej szczegółową część, która nie jest pokazywana w niektórych sytuacjach. Wspiera to oryginalny klient gita (np. komenda git log --abbrev-commit) i np. GitHub (w widoku listy commitów pokazywana jest tylko krótka wiadomość, a reszta rozwija się po kliknięciu). Git oddziela streszczony opis commitu od jego pełnej treści za pomocą jednej pustej linii.

Oto skrótowy, kontretny opis Twojego commitu

Tutaj możesz zawrzeć długi opis, w którym przykładowo omówisz przyczyny
wprowadzenia danej zmiany i jej konsekwencje dla projektu. Może być to
przydatne szczególnie dla Twoich współpracowników.

Na koniec kilka dodatkowych (częściowo subiektywnych, lecz popartych obserwacjami) zaleceń dotyczących formy samej wiadomości:

• żadna z linii w opisie commita nie powinna przekraczać 72 znaków (konsola ma domyślnie 80 znaków szerokości)
• rozpocznij opis od wielkiej litery
• na końcu pierwszej linii commitu nie stawiaj kropki
• użyj trybu rozkazującego (zwłaszcza w języku angielskim; powód - git używa takiego samego trybu dla wiadomości generowanych przez siebie, na przykład "Merge a from remote b")

Weryfikacja commitu

Przed zatwierdzeniem dowolnego commitu, przejrzyj go - najlepiej dwa razy. Służy do tego oczywiście diff, czyli wykaz wszystkich zmian poczynionych w ramach danego commmitu. Generalnie do jego wyświetlenia służy komenda git diff (trudne, prawda?), ale oczywiście jest haczyk. Domyślnie nie pokazuje ona zawartości plików właśnie dodanych do repozytorium, a jedynie zmiany w przestrzeni roboczej (przed wykonaniem git add).

Metodą uniwersalną jest wydanie komendy git add . (lub git add . --all dla gita 1.x - wszystko, aby uwzględnić też pliki właśnie usuwane z repozytorium) a następnie git diff --cached. Po tych dwóch poleceniach dostaniemy pełną listę zmian, zarówno w dodawanych, zmienianych, jak i usuwanych plikach - pozwala to zaoszczędzić naprawdę wielu pomyłek w kodzie.

Łączenie (squashowanie) commitów

Łączenie kilku commitów w jeden, zwłaszcza po ich wysłaniu do zdalnego repozytorium (remote), zaburza poniekąd historię zmian i może prowadzić do tego, że system kontroli wersji nie będzie spełniał swojej roli. Zachodzą jednak sytuacje, w których może być to przydatne, a nawet wymagane przez innych developerów. Najczęściej dzieje się tak w wypadku Pull Requestów lub ich odpowiedników z serwisów innych niż GitHub.

Powodem, dla którego w tej sytuacji możemy użyć squashowania (dosł. zgniatania) commitów jest zachodzący workflow. Zmiany są wykonywane w obrębie naszego własnego repozytorium (forka) i wysyłane jako propozycja zmian dla jakiegoś projektu. Bardzo często ludzie zarządzający tym projektem będą mieli do nas pewne uwagi i wskazówki, w związku z czym do Pull Requesta dołączają kolejne commity. Warto je na końcu połączyć, bo Pull Request z założenia powinien obejmować jedną funkcjonalność, a więc często być też jednym commitem (jak pisałem na początku artykułu). Kilka różnych metod squashowania commitów znajdziecie w tym wątku na SO.

Zakończenie

Mimo, że opisałem tutaj całkiem sporo założeń i może się wydawać, że teraz wysłanie dobrego commita miałoby zajmować wieczność i oznaczać sprawdzanie każdego punktu z listy, to nie ma czym się przejmować. Większość z wniosków wyciągniętych w artykule jest bardzo logiczna i nie powinna być dla Was niczym nowym, a reszta szybko wejdzie w nawyk. Należy brać poprawkę na dozę subiektywizmu zawartą w tym tekście.

Uprzedzam od razu, wpis szczególnie odkrywczy nie będzie. Łatwość tworzenia i promowania miejsc do dzielenia się swoją treścią ze światem powoduje, że zabierają się do tego zadania również osoby, nazwijmy to… mniej rozgarnięte. Tak było, jest i będzie, bo samemu portalowi na rękę jest generowanie jak największej ilości treści - o czym już pisałem - jej jakość nie ma wielkiego znaczenia.

Od pewnego czasu mam jednak wrażenie, że kilka zjawisk występuje na praktycznie każdym "fanpejdżu", a ponadto, nasila się. Ze swoich obserwacji mogę wymienić kilka zabiegów, które są powszechne i bardzo denerwują.

Czytaj dalej →

Czas leci. Zmienia się wszystko co nas otacza. Kwestią indywidualną jest to, czy dostosujemy się do zachodzących procesów, czy będziemy stać w miejscu i biernie się temu przyglądać.

Informatyka jest dziedziną wiedzy, w której tempo rozwoju widać szczególnie wyraźnie. Co i rusz spotykamy się z technologicznymi nowinkami - a to nowy procesor mniejszy niż kiedykolwiek, a to czytnik e-booków w kształcie parówki, który w razie potrzeby możemy zjeść. Nie inaczej sprawa ma się w kwestii programowania. Ewolucja nie dotyka każdego języka w jednakowym stopniu, ale ogólnopojęta dziedzina wciąż wykształca nowe rozwiązania. Inne zaś odchodzą w niepamięć.

Czytając ten wstęp nietrudno jest domyślić się, o czym będzie dalej. Trudno mi za to o tym napisać, bo nie jest to prosta decyzja. Dotychczas wiedziały o niej tylko dwie osoby, jednak ze względu na to, że prowadzę publicznie dostępne zapiski ze swojej działalności w internecie, czas podzielić się tym ze wszystkimi, którzy mogą być zainteresowani. Niniejszym wrzucam to stwierdzenie do internetu i niechaj w nim zostanie: porzucam PHP.

Zmiana technologii jest naprawdę ciężką kwestią, zwłaszcza dla osoby tak przyzwyczajonej jak ja. Zdaję sobie jednak sprawę z ograniczeń tego języka. Przemyślałem to dokładnie i uważam, że czas podjąć konkretne kroki. Liczę, że cząstka doświadczenia zdobytego w PHP przyda mi się w nowej technologii. Ruby.

Dlaczego właśnie ten język? Powodów jest bardzo wiele: począwszy od spójnego i uporządkowanego API (którego w PHP chyba nie dożyję), przez szerokie możliwości, po zwyczajną estetykę kodu.

Argumentu o czytelności nie muszę chyba rozwijać - dużo materiałów mówi o PHP w tym zakresie, kilka skromnych sam napisałem. Jeżeli chodzi o możliwości. Korzystając z Ruby otrzymuję technologię przystosowaną zarówno aplikacji sieciowych jak i desktopowych. Mój obszar zainteresowań jest chyba jasny, tak więc Ruby on Rails już jakiś czas temu zawitał na moim dysku, jednak nie porzucam nadziei, że nauka technologii bardziej uniwersalnej niż pehap pozwoli mi na (choćby skromne) wejście w świat aplikacji okienkowych. Ostatnia cecha, estetyka kodu: Ruby, jako język nowszej generacji, nie czerpie swojej składni z C. To pozwala nam pozbyć się irytujących klamerek i umożliwia chociażby method-chaining ("Test".upcase.reverse). Wszyscy, którzy mnie znają, wiedzą, że w kwestii spójności wyglądu kodu jestem pedantem. Pisałem o tym minimum raz. To jedna z wielu rzeczy, które Ruby da mi w standardzie - nie będę musiał walczyć z językiem o ładny kod i wyszarpywać mu go z paszczy - co najwyżej to on zawalczy ze mną, jeżeli postanowię rozwiązać coś nieodpowiednio.

Tyle o powodach… i co tu więcej mówić. Intensywna nauka trwa już jakiś czas, za kilka dni chcę się pochwalić pierwszym prostym projektem. Mam swoją drogą nadzieję, że całkowicie nowa gałąź wiedzy do zgłębienia, rozrusza jakoś ten blog. Jednocześnie informuję, że rozwój wszystkich dotychczasowych projektów napisanych w PHP (a innych nie ma ;)) został zatrzymany. Nie był to jakiś istotny dorobek, tak więc myślę, że spokojnie przeżyjecie, a ja nie mam czasu na dalsze inwestowanie go w PHP.

Pozdrawiam Was z nowego, lepszego świata!

-- edit (02.04.2014) -- Pierwszy kwietnia już za nami - sprostowanie dostępne tutaj ;)

Nie, w dzisiejszym wpisie nie chcę Wam opowiedzieć o londyńskim lekarzu zamieniającym się nocą w potwora. Będzie standardowo, czyli o sprawach powiązanych z webmasterką.

Krótki akapit wstępu, bo większość z Was prawdopodobnie nie zna wspomnianego skryptu. Otóż [Jekyll][jekyll] jest to narzędzie, które pozwala wygenerować statyczną stronę na podstawie dostarczonych plików. Można to nawet nazwać CMS-em, bo w pewien sposób umożliwia zarządzanie treścią, jednak w sposób odmienny od większości systemów tego typu. Tak jak wspomniałem wcześniej, Jekyll bazuje na plikach utworzonych przez webmastera. Składają się na nie:

• Szablony - pliki HTML, które definiują układ i kod strony. Tak jak we wszystkich innych skryptach, zawierają one zmienne, pod które będą podstawiane odpowiednie wartości: np. tytuł strony, czy jej treść
• Pliki z treścią - tutaj rozróżnić możemy wpisy oraz normalne podstrony
• Pliki nie parsowane - takie jak pliki CSS czy obrazki

Jekyll sparsuje otrzymane pliki i wyrzuci nam całą strukturę statycznych plików, które wrzucamy na serwer i mamy naszą stronę. Odmienia to trochę podejście do tworzenia witryn. Zamiast dynamiki nadawanej za pomocą języków działających po stronie serwera, całą stronę generujemy u siebie na komputerze, a na serwerze trzymamy statyczną witrynę wspieraną co najwyżej przez technologie client-side takie jak JavaScirpt.

Może wydawać się, że takie rozwiązanie to cofnięcie się do średniowiecza, w końcu Web 2.0, to coraz bardziej interaktywne strony internetowe. Z drugiej strony użycie Jekylla pozwala się nam skupić na tworzeniu treści, nie martwiąc się o inne kwestie. Po prostu piszemy treść w naszym ulubionym formacie (takim jak Markdown), a potem wydajemy jedną komendę i mamy gotowego bloga, który w dodatku do działania nie wymaga żadnego specjalnego serwera, bo wystarczy serwowanie odwiedzającym statycznych plików.

Drugą cechą stojącą za rosnącą popularnością tego rozwiązania w ostatnim czasie, jest fakt iż Jeykyll jest automatycznie zintegrowany z GitHub Pages. Jeżeli ktoś nie wie co to, to już spieszę z tłumaczeniem. Jest to metoda serwowania strony WWW przetrzymywanej w systemie kontroli wersji git. Przyznacie, że brzmi to bardzo wygodnie - całość witryny trzymana jest na GitHubie dzięki czemu mamy dokładną kontrolę nad wszelkimi wprowadzanymi zmianami, a Jekyll "magicznie" generuje bloga/stronę na podstawie dostarczonych plików.

Sam myślałem nad zastosowaniem tego hipsterskiego podejścia u siebie na stronie, jednak przeważyło moje przywiązanie do klasycznej dynamiki stron WWW. W momencie kiedy do strony obsługiwanej przez Jekylla trzeba dodać podstawowe elementy interakcji z użytkownikiem, zaczyna się naprawdę mocne kombinowanie. Poza tym nie znam w ogóle Ruby, w którym został napisany Jekyll i wszelkie modyfikacje przychodziły by mi z trudem.

Zaprezentowany skrypt nie jest oczywiście jedynym tego typu. Ze względu na popularność opisanego podejścia, powstały podobnie działające rozwiązania dla wielu innych języków. Z tych napisanych w PHP można wymienić między innymi Phrozn czy PieCrust. Pewne podsumowanie najpopularniejszych static generatorów zawiera strona StaticGen.com.

Co sądzicie o takim, jakby nie patrzeć, mocno odmienionym podejściu do tworzeniu blogów. Interesowaliście się kiedyś takimi rozwiązaniami?

Witajcie, o zmianach na YT raz już pisałem na swoim blogu, wtedy pozytywnie. Tym razem nie będzie tak miło i przyjemnie, bo same zmiany nie są dla mnie przyjemne.

Próba siłowej integracji YouTube z serwisem Google+ trwała od dawna. Pamiętam, że na samym początku nie mogłem zrozumieć skąd wśród ludzi tak wielka moda na podpisywanie się swoim imieniem i nazwiskiem w tym serwisie - kojarzyło mi się to z planami chińskiej władzy ludowej, która chciała wprowadzić coś takiego obligatoryjnie w całej ichniej parodii internetu. Nie wiedziałem po prostu, że ludzie są zachęcani do takiej zmiany systemowo. W końcu i ja zostałem zapytany o to czy chcę posługiwać się nickiem wybranym przy tworzeniu konta na YT, czy imieniem i nazwiskiem z Konta Google, do którego potem przypisano mojego użytkownika. Wybierałem oczywiście opcję pierwszą, bo w tym czasie i tak nie występowałem prawie w internecie pod swoim imieniem i nazwiskiem, więc chodziło o zwykłe zachowanie konsekwencji.

Pytania/prośby o wybór tożsamości pojawiały się co jakiś czas - twardo wybierałem pozostanie przy nicku - mam dziwne przeczucie, że nie spotkałbym więcej tego popupa, gdybym wybrał nazwisko. Tak czy inaczej, w ostatnim czasie zostałem przez Google zmuszony do "zintegrowania" swojego kanału z usługą Google+ (w której nigdy konta nie zakładałem). Proces nie był zbyt dopracowany, gdyż od razu zauważyłem zniknięcie mojego ukochanego diabła. Postanowiłem rozejrzeć się po nowych możliwościach oferowanych przez stronę na Google+ (bo w takiej postaci zarządzało się od tego momentu kanałem) po czym poddałem się. Pewnie dało by się to ogarnąć, ale wiedziony siłą przyzwyczajenia, po 20 minutach poszukiwań, udało mi się odnaleźć w zakamarkach ustawień opcję pozwalającą na powrót do tradycyjnej postaci kanału. Jak za dotknięciem czarodziejskiej różdżki powrócił stary interfejs i avatar. Nie, nie emocjonujcie się - to było dawno, dziś takiej możliwości już nie ma.

Około tygodnia temu, nie pamiętam dokładnie, zmiana nastąpiła ponownie. Bez pytania o zgodę, tym razem obligatoryjnie. OK, pomyślałem, może dopracowali szczegóły i postanowili wdrożyć rozwiązanie dla wszystkich użytkowników. Według mnie jednak nie zmieniło się wiele, a przynajmniej nie na plus. Znów musiałem pożegnać się z avatarem (krótkie pytanie: dlaczego do cholery google+ oczekuje że avatar będzie okrągły? nie znam innego takiego serwisu).

Od strony osoby zalogowanej ta fuzja stała się prawdziwym koszmarem, nastąpiło bowiem chaotyczne rozbicie usługi na dwa serwisy. Część zarządzania kontem i kanałem mamy z poziomu YouTube, a część z poziomu G+. Tak samo powiadomienia, większość z nich widoczna jest teraz jako notyfikacje na Google+, ale część nadal wędruje do skrzynki odbiorczej. Dlaczego aby włączyć przesyłanie dłuższych filmów muszę wejść w ustawienia na YouTube, a żeby zmienić nazwę kanału, muszę skorzystać z Google+? Fakt, że oba te serwisy mają całkiem niespójne designy nie ułatwia sprawy, bo nie da się przeoczyć momentu, w którym wychodzimy z jednej usługi na drugą.

Teraz temat, który jest na tyle istotny zjebany, że trzeba mu poświęcić osobny akapit. Mianowicie komentarze. Tu też Google postanowiło na siłę wepchnąć ludziom swój serwis społecznościowy i zrobiło to w sposób maksymalnie nieprzemyślany. Wygląda na to, że od teraz część komentarzy jest widoczna jako te dodawane z poziomu Google+, a reszta z poziomu samego YT. Zniknęły łapki. Wielka tragedia, możecie powiedzieć, pewnie wielu wkurzały. Problem jednak w tym, że zniknęły nie wszędzie. Na początku myślałem, że po prostu inżynierowie Google byli zbyt leniwi i wszystkie stare komentarze zostały pozbawione ocen. To jednak kwestia szersza i bardziej skomplikowana - część nowych komentarzy można oceniać łapkami, reszty nie. Dodatkowo komentarze domyślnie są sortowane właśnie wg. ocen, co w połączeniu z tym, że większość komentarzy została pozbawiona widocznego licznika daje totalny chaos. Widać bowiem, że komentarze nie są sortowane chronologicznie, ale nie ma jednocześnie możliwości ich oceny - gdzie tu logika? Sprawa kolejna i bardzo prosta, wczytywanie "nowych super komentarzy" działających w oparciu o Google+ trwa długo. Trzeba odczekać chwilkę zanim wczyta się ta część strony - nie jest to komfortowe, tym bardziej że preloadera brak, w pierwszej chwili miejsce na komentarze jest po prostu puste. Google chwali się też wprowadzeniem poprawionych odpowiedzi na komentarze. Przecież coś takiego już było i mimo pewnych bugów jako tako działało. Teraz część komentarzy ma dopiski w starym stylu: "Ten komentarz jest odpowiedzią na komentarz użytkownika XXX", a część jest przedstawiana jako wcięty wątek dyskusji - podejrzewam, że odnosi się to do komentarzy umieszczanych z poziomu Google+. W dodatku odpowiedzi na komentarze są teraz zwijane przez co nie da się płynnie czytać dyskusji, bo co chwilę trzeba gdzieś klikać.

Cały proces zmian wygląda jak plan wymyślony wyłącznie przez dział marketingu. Strategia "Google+ idzie nam słabo więc wepchnijmy je ja siłę do YouTube, tam jest dużo więcej ludzi". Wygląda to tak jakby do realizacji nie przyłożyła ręki ani jedna osoba techniczna ani tester.

I ostatni krótki akapit, który zapobiegawczo kieruję do ludzi, którzy chcieli by mi napisać, że mamy wolny rynek, który rządzi się prawami popytu i podaży, i jak mi się nie podoba YT, to mogę nie korzystać, bo to własność Google i może z tym robić co się podoba. Owszem, ale nie zmienia to faktu, że w mojej opinii sprawę zjebali, więc opisuję to na blogu, którego można nie czytać ;) A wolnego rynku nie mamy.

Pozdrawiam tych, którzy wytrwali do końca!

Przez moment szukałem w głowie odpowiedniego przymiotnika, którym chciałbym opisać bohatera dzisiejszego krótkiego wpisu. Myślę, że wygodny będzie całkiem dobrym określeniem choć Markdown jest zarówno wydajny jak i intuicyjny.

Czym w ogóle jest Markdown? Jest to język znaczników, służący do formatowania tekstu, wymyślony przez Johna Grubera i Aarona Schwartza w roku 2004. Jak już wcześniej wspomniałem, od innych dostępnych rozwiązań takich jak BBCode czy czysty kod HTML odróżniają go między innymi szybkość użycia i intuicyjność. Składnia Markdown zaprojektowana jest w taki sposób, że nawet patrząc na jeszcze nieprzetworzony kod widzimy przeznaczenie każdego znacznika. Już podaję przykład:

Nagłówek pierwszego stopnia
===========================

Podrozdział
-----------

Poszczególne akapity są od siebie oddzielone pustą linią, tak więc
w obrębie jednego paragrafu swobodnie możemy korzystać z
klawisza enter.

Równie intuicyjne jest też wyróżnianie tekstu: czy to poprzez *emfazę*,
czy **pogrubienie**.

Lista nienumerowana

- kurczaki
- ziemniaki
- psychotropy

Oraz lista ponumerowana:

1 kurczaki
2 ziemniaki
3 psychotropy

Taki kod Markdown zostanie sparsowany (parsery dostępne są dla większości języków) do następującego kodu HTML:

<h1>Nagłówek pierwszego stopnia</h1>

<h2>Podrozdział</h2>

<p>Poszczególne akapity są od siebie oddzielone pustą linią, tak więc
w obrębie jednego paragrafu swobodnie możemy korzystać z
klawisza enter.</p>

<p>Równie intuicyjne jest też wyróżnianie tekstu: czy to poprzez <em>emfazę</em>.
czy <strong>pogrubienie</strong>.</p>

<p>Lista nienumerowana</p>
<ul>
<li>kurczaki</li>
<li>ziemniaki</li>
<li>psychotropy</li>
</u>

<p>Oraz lista ponumerowana:</p>
<ol>
<li>kurczaki</li>
<li>ziemniaki</li>
<li>psychotropy</li>
</ol>

Jest to oczywiście pokaz tylko części możliwości Markdown. Chodziło m raczej o zademonstrowanie samej koncepcji i przejrzystości składni. Jak widać, dzięki użytej budowie, artykuły można spokojnie pisać w dowolnym edytorze tekstowym i nadal pozostaje to czytelne.

Poza to, co pokazano wyżej, składnia Markdown oferuje jeszcze między innymi: odnośniki, obrazki, przełamania linii wewnątrz akapitów, umieszczanie bloków kodu, czy cytaty. Istnieje też alternatywna składnia dla kilku z pokazanych już zastosowań - w standardzie dostarczono m.in. dwa sposoby oznaczania nagłówków, emfaz i pogrubień, które można stosować wymiennie w obrębie jednego dokumentu. Nic nie stoi też na przeszkodzie aby np. umieścić element listy składający się z kilku akapitów -nie chciałem po prostu opisywać tutaj całej składni, bo to już dobrze zrobił sam autor.

Ponadto, dla PHP (oryginalny preprocesor został napisany w Perlu) istnieje parser Markdown w wersji Extra, który oferuje nam takie rzeczy jak listy definicji, przypisy, tabele, czy poprawiony sposób umieszczania kodów źródłowych w tekście. Tutaj należy wspomnieć o jednym założeniu poczynionym na samym początku przez Grubera - Markdown nie ma stać się składnią alternatywną dla HTML. Ma być jedynie wygodną warstwą abstrakcji, która faktycznie ułatwi nam najczęściej stosowane formatowania tekstu.

Jako potwierdzenie powyższych zalet wystarczy zobaczyć jak wiele języków obecnie dostarcza biblioteki do obsługi tej składni i jak wiele oprogramowania pozwala z niej korzystać, czy to jako natywny sposób formatowania, czy jako rozmaite modyfikacje. Znajdziemy więc między innymi rozszerzenie do Thunderbirda, które pozwala nam pisać maile w ten sposób, a potem konwertuje je do HTML-a, a także wtyczkę do Wordpressa (przyznaję, że sam chętnie przerzuciłbym się właśnie na Markdowna, gdyby nie duża ilość treści do przekonwertowania).

Markdown jest też jednym ze sposobów formatowania treści dostarczanym natywnie przez takie usługi jak Github, BitBucket, Jekyll, a także rozmaite systemy CMS.

Tak więc Markdown kryje pod swoją nazwą dwie rzeczy: standard opisu informacji, czyli zaprezentowany i opisany wyżej język znaczników, a także pierwotny parser napisany przez Grubera w Perlu. Niezależnie od czy tworzycie jakąś nową aplikację w języku, który ma bibliotekę do parsowania Markdowna albo pracujecie z programem, który umożliwia jego użycie , jeżeli przewidujecie dużą ilość pracy z prostym tekstem, polecam spróbować tego rozwiązania - praca po chwili staje się naprawdę przyjemna i szybka.

Na sam koniec dwa konkretne linki dla osób, które zainteresował temat: oryginalna strona projetu gdzie w pełni opisano dostępną w standardzie składnię oraz stronę klasy Markdown.php.

Miałem już dziś nie spamować więcej, ale w sumie dlaczego nie? Już nie wiem który raz widzę tego typu bug iTunes i mojego iPoda Nano. Jakby ktoś miał wątpliwości to obie widoczne pozycje są w rzeczywistości dwoma osobnymi plikami (widać po liczbie odtworzeń choćby), tylko oprogramowanie od Apple ma ciekawe kryterium tego, jaki utwór jest obecnie odtwarzany.

PS: Wpisy nie będą się codziennie pojawiać z taką częstotliwością, bo wiadomo jak wygląda sprawa z moją motywacją, ale niewątpliwie będzie ich więcej niż obecnie. Nie przeszkadza Wam taka ilość małych wpisów? Może chcecie aby w jakiś sposób oddzielić takie małe pierdółki od reszty bloga (choćby przez osobny kanał RSS)?

PS2: Tak, to kryptoreklama Tima Minchina, polecam :D

Być może miałeś okazję zobaczyć taki plik w kilku repozytoriach Git i zastanawiałeś się czym on jest. Podstawowa znajomość angielskiego pozwala stwierdzić, że będzie on czymś w rodzaju pliku .gitignore - wewnętrznym plikiem przekazującym jakieś informacje gitowi.

Rolą pliku .gitkeep jest spowodowanie aby dany folder był wysłany do repozytorium nawet gdy nie zawiera żadnych innych plików - git bowiem pomija puste foldery przy commitowaniu. Teraz uwaga: plik nie jest w żaden sposób częścią standardu - jest to nazwa umowna - plik na dobrą sprawę może być dowolnym innym (pustym bądź nie) plikiem, jest on potrzebny aby Git uwzględnił zawierający go folder w repozytorium. Wprowadzenie jakiejś określonej nazwy pozwala po prostu zorientować się czym jest plik, po samej jego nazwie.

Tak więc podsumowując jakby ktoś nie zrozumiał: folder pusty nie jest "widziany" przez Gita, tak więc dodaje się do takich folderów puste pliki o dowolnych nazwach, żeby zmienić to zachowanie. Kilka osób umówiło się natomiast, że .gitkeep to dobra nazwa, bo nawiązuje konwencją do .gitignore - faktycznego pliku konfiguracyjnego no i mówi nam nazwą o co w pliku chodzi.

Sobak, jako wybitny specjalista w dziedzinach accessability, usability i innych –ity ma dla Was najnowszą super-wypasioną poradę przydatną w dzisiejszych czasach. Będzie ona dotyczyć… cookies. Małych, niewinnych ciasteczek, które od maja tego roku zostały skazane na bycie piętnowanymi przez Unię Europejską miłościwie nam panującą.

Mam ja krótkie pytanie: dlaczego prawie nikt nie umieścił komunikatu o cookies na dole strony bez fixed? Najczęściej widuję strony, które taki komunikat mają przyczepiony na górze. Dosyć rzadko dzieje się tak, że po przewinięciu w dół komunikat zostaje na górze (czyli po prostu nie ma fixed). Wiele stron zdecydowało się umieścić taki komunikat na dole, jednak w takim rozwiązaniu mamy permanentnie ucięte kilkanaście pixeli z dołu strony.

Natomiast zestaw, do którego chciałbym Was przekonać, czyli informacja umieszczona na dole strony i nie przylepiona do dołu ekranu na fixed, mimo że zdaje mi się najlepszy, widziałem raptem na kilku stronach WWW (choćby Google/Youtube czy Forumweb). Dlaczego takie rozwiązanie jest wg mnie najlepszym wyjściem? Przede wszystkim nie zabieramy na stałe przestrzeni z ekranu. Komunikaty z fixed rezerwują sobie nieraz wiele przestrzeni i dopóki użytkownik ich nie zamknie będą wędrować z nami podczas czytania strony. Komunikat umieszczony na dole może być przeczytany przez użytkownika po zobaczeniu tego, po co przyszedł na stronę. To przecież nie informacja o ciasteczkach jest dla niego najważniejsza.

Dlaczego więc webmasterzy tak bardzo upodobali sobie inne formy? Zwięzłą i bardzo ciekawą analizę przedstawił logeen na Forumweb.pl. W skrócie: jako pierwsze komunikat o cookies wprowadziły witryny rządowe. Webmasterzy, a raczej ich zleceniodawcy pod natłokiem całego szumu jaki wywołała zmiana prawa uznali strony rządowe za dobry wzorzec i gwarancję zgodności ze znowelizowaną ustawą ("to nie może być złe bo tak robi strona prezydenta/premiera etc").

Tymczasem przedstawione przeze mnie rozwiązane w żaden sposób nie narusza ustawy Prawo Telekomunikacyjne. Ustawa o samym komunikacie mówi jedynie, że ma być on jednoznaczny, bezpośredni i zrozumiały dla użytkownika.

abonent lub użytkownik końcowy zostanie uprzednio jednoznacznie i bezpośrednio poinformowany, w sposób łatwy i zrozumiały

W związku z tym porada na dziś będzie taka: nie marnujcie miejsca na monitorach Waszych czytelników, nie marnujcie ich uwagi na czytanie tego samego komunikatu po raz kolejny. Odpowiednia wzmianka w stopce spokojnie wystarczy.