git-svn – pracuj lokalnie z git, synchronizuj się z SVN

Wszystkie projekty w mojej pracy są wersjonowane mocno na SVN. Ten system kontroli wersji ma już swoje lata i już dawno temu zaczął być wypierany przez gita. Niestety, u nas perspektyw na migrację nie ma w najbliższej przyszłości, więc od kilku lat korzystałem bezpośrednio z SVN.

Na początku niezbyt mi to przeszkadzało – najpierw się wdrażałem, potem zmieniłem zespół, potem zmiany wprowadzałem liniowo i nie było zapotrzebowania na „skakanie” pomiędzy zagadnieniami. Jedynie czasem trzeba było wybrać część zmian z wielu innych w tych samych plikach, ale mniej więcej w tym czasie odkryłem możliwości pary diff + patch, przez co wybrane zmiany można było łatwo scommitować gdzieś na boku bez zbędnego komentowania zmian, które wejść nie powinny.

Sytuacja zmieniła się radykalnie wraz ze zmianami w szeregach naszego biznesu. Coraz częściej wykonywaliśmy po kilka zagadnień „jednocześnie”, przestała mieć też znaczenie kolejność wykonywania zmian – czasem zagadnienia skończone jednego dnia musiały wejść na produkcję jeszcze w tym samym dniu, inne zaś musiały czekać tygodniami, a czasem nawet zostawały zaorane.

Miało to co najmniej trzy poważne konsekwencje:

  • wiecznie zapchane working copy: po roku takiej pracy miałem zawsze kilkadziesiąt zmienionych plików i efektywne przejrzenie diffa przed commitem było praktycznie niemożliwe, przez co często zdarzało się zapomnieć o jakimś pliku; nie muszę też pisać, że codzienny widok niewdrożonych zmian sprzed np. kilku tygodni ma katastrofalny wpływ na motywację,
  • utrudnione testy: zmiany bardzo często dotyczyły tych samych plików, codziennością było kilka zagadnień w tym samym module, co powodowało, że testowanie niektórych zmian było bezcelowe w oderwaniu od innych, zaś czasem sztucznie wstrzymywałem pracę nad dalszymi zmianami w oczekiwaniu na testy ze strony biznesu,
  • wieczny ból dupy przed wdrożeniami: po pewnym czasie nakładających się na siebie zmian było tyle, że diff i patch na boku musiał być używany hurtowo; ręczna edycja diffów bywa czasem utrudniona, co w połączeniu z wybieraniem zmian z kilkudziesięciu plików było szalenie czasochłonne; przygotowania do wdrożenia zaczęły być pasmem kombinowania.

Mniej więcej w tym samym czasie zacząłem podchodzić dużo poważniej do kwestii testowania oprogramowania, co wcale nie ułatwiało sytuacji. SVN był w takich sytuacjach po prostu bezbronny – jego branche w tak szybkim i zmiennym procesie rozwoju oprogramowania nie mają prawa bytu i są strasznie ciężkie. Zacząłem czytać coraz więcej o gicie.

Gita znałem jeszcze z czasów swojej freelancerki, jednak z racji tego, że pracowałem sam, to tak naprawdę go nie znałem. Nie korzystałem nawet aktywnie z branchów – wszystkie moje projekty z tamtego czasu to jedynie master, służący jako kopia zapasowa i archiwum zmian. Wiedziałem jednak, że możliwości są dużo większe, aż w końcu trafiłem na sposób pogodzenia SVN i git – projekt git-svn.

Po przejściu przez kilka tutoriali wiedziałem, że to będzie to. Git-svn pozwala stworzyć gitowe repozytorium na podstawie brancha z SVN, który będzie synchronizowany w dwie strony.

Użyłem więc git-svn do clone’a z SVN. Po kilkudziesięciu minutach mielenia (nasz projekt miał wtedy ponad 2,5k commitów) miałem już gotowe repo, które spatchowałem niescommitowanymi zmianami z kopii roboczej SVN, której dotąd używałem.

Zacząłem ostrożnie – dalej miałem mnóstwo niescommitowanych zmian, dalej nie używałem branchy, jednak git add –patch i selektywne dodawanie zmian do scommitowania w obrębie jednego pliku zrobił furorę – to był ten moment, w którym przestałem zaprzątać sobie głowę myśleniem o wtórnych problemach: czyli „jak tym razem scommitować zmiany wymieszane pomiędzy zagadnieniami?”.

Po miesiącu takiej pracy okazało się, że w zasadzie nie występują większe problemy. Dlaczego więc nie pójść o krok dalej? Tym krokiem było oczywiście przeniesienie zmian do osobnych gałęzi zgodnie z git flow. Dzięki temu rozwiązałem raz na zawsze problem zapchanego working copy (czy – w przypadku gita – indeksu).

Podaję materiały, które mogą się przydać każdemu znajdującemu się w sytuacji podobnej do mojej, a z których sam korzystałem:

8.1 Git and Other Systems – Git and Subversion

Effectively Using Git With Subversion

Na koniec moje protipy:

  • unikaj rebase na synchronizowanym z SVN branchu (przeważnie master), przepisanie historii commitów powoduje czasem zaburzenie liniowości historii, przez co synchronizacja się nie udaje; sam rozwiązuję to w ten sposób, że feature branche merge’uję do mastera z przełącznikiem –no-ff,
  • pamiętaj, że korzystając z git-svn wszelkie zmiany w lokalnych branchach nie są wypychane tak, jak przy „tradycyjnym” repozytorium gita, posiadasz więc prawdopodobnie jedyną kopię tych zmian – pamiętaj o wykonywaniu kopii zapasowych, w przypadku uszkodzenia lokalnego repozytorium możesz stracić wszystkie efekty swojej pracy.

Muszę też ostrzec potencjalnych użytkowników – spotkałem się z wieloma opiniami mówiącymi o tym, że git-svn tak bardzo usprawnia pracę, że jest pierwszym krokiem do całkowitego przejścia na gita w pracy. Sprawdziło się to i u mnie – narzędziem tym zaraziłem kolegę z zespołu. Czas na resztę. 😉

Uruchomienie starego kodu na nowych wersjach jQuery

Jeżeli w swoich projektach masz dużo legacy kodu napisanego w JS z użyciem starych wersji biblioteki jQuery, a nie chcesz/nie możesz w danej chwili przepisać jego części niedziałających w nowszych wersjach – polecam zacząć migrację od pluginu jquery-migrate.

Plugin ten wykrywa i przywraca usunięte od wersji 1.9 funkcje jQuery, dzięki czemu stary kod wykona się poprawnie na nowych, niekompatybilnych wstecz wersjach biblioteki.

Oczywiście podpięcie go powinno być stanem przejściowym do czasu pełnej migracji i przepisania wywołań usuniętych funkcji. Sam plugin doskonale w tym pomaga dzięki możliwości generowania ostrzeżeń przy każdym wywołaniu nieobsługiwanej w nowej wersji funkcji. Można dzięki temu korzystać natychmiast z nowych wersji jQuery, stopniowo przepisując stary kod na podstawie zaraportowanych wywołań.

SQL savepoint – obsługa złożonych transakcji

Jakiś czas temu natknąłem się w pracy na problem obsługi złożonych transakcji.

Jako, iż SQL (a przynajmniej DBMS, z którego korzystamy) nie obsługuje zagnieżdżonych transakcji, do tej pory – dla wygody – wystarczała nam prosta modyfikacja adaptera bazodanowego, która pozwalała na „zagnieżdżanie transakcji”, a polegała jedynie na zliczaniu żądań rozpoczęcia transakcji i pilnowaniu liczby wywołań commitów/rollbacków na adapterze. W przypadku niezgodności rzeczywista transakcja (otwierana przy pierwszym żądaniu) nie była commitowana, podobnie, gdy wystąpiło przynajmniej jedno wywołanie rollback na adapterze – żadne zmiany nie były stosowane.

W rzadkich sytuacjach nietypowych, gdzie część zapytań miała zostać zastosowana, a część – w razie potrzeby – nie, obsługa odbywała się w kilku niezależnych transakcjach.

Jednak w końcu przyszedł ten moment, gdy rozbicie na wiele transakcji było praktycznie niemożliwe ze względu na złożoność procesu, który trzeba było zmodyfikować.

W skrajnym przypadku mogło to wyglądać tak:

  1. Początek procesu – wykonanie podstawowych zapytań INSERT/UPDATE
  2. Wykonanie serii zapytań INSERT/UPDATE z możliwością warunkowego ich cofnięcia.
  3. Zakończenie procesu – kolejne zapytania INSERT UPDATE.

W pewnych warunkach powinny być więc zastosowane zmiany z punku 1., cofnięte wszystkie z punktu drugiego i zastosowane zapytania z punktu trzeciego.

I tutaj przydatna okazała się klauzula SAVEPOINT, o której istnieniu wcześniej nie wiedziałem, natomiast idealnie wpasowywała się w tego typu sytuacje.

Jej zasada działania jest banalnie prosta. W momencie wywołania:

SAVEPOINT nazwa_savepointa

wewnątrz transakcji tworzony jest punkt, po którym następują kolejne zapytania i do którego można – w razie potrzeby – cofnąć się poprzez

ROLLBACK TO nazwa_savepointa

W ten sposób „zapominamy” o wykonanych po utworzeniu savepointa zapytaniach SQL, natomiast wszystkie zapytania sprzed tego czasu zostaną zastosowane, jeżeli na całej transakcji zostanie wykonany COMMIT.

Bitcoin nie daje rady

Bitcoin to niewątpliwie waluta przyszłości. Prostota użycia, implementacji, anonimowość i błyskawiczne płatności, a to wszystko niezależnie od rządów i – przy stosowaniu się do kilku reguł – podatków. Właśnie tak myślałem, dopóki nie przyszło mi skorzystać z tej waluty w praktyce. Całe szczęście, że nie do końca do moich celów.

Bitcoin stał się popularny w polskich mediach w zeszłym roku, pewnie ze względu na gwałtownie rosnący kurs BTC do USD (jednak ta bańka pękła prawdopodobnie na początku grudnia). To spowodowało, że zainteresowałem się tematem i postanowiłem przetestować, jak płatności Bitcoin sprawdzają się w praktyce.

I żeby nie przedłużać – nie sprawdzają się. Spostrzeżeń jest kilka:

  1. Bitcoin nie nadaje się do mikropłatności. Jeżeli masz serwis oferujący relatywnie tanie usługi i chcesz wdrożyć płatności w tej walucie, szybko o tym zapomnij – unikniesz wyrzucenia pieniędzy w błoto. Małe transakcje są znaczącym problemem dla sieci i są przez osoby z nią związane wprost nazywane spamem. W efekcie oficjalny klient, dla transakcji niskopriorytetowych – wymusza minimalną opłatę transakcyjną na poziomie 0,0001 BTC, czyli ok. 0,26 zł w dniu i godzinie redagowania tego wpisu. W praktyce jednak opłata ta jest wyższa. Przykładowo – przy wykonaniu pojedynczej, testowej płatności pomiędzy swoimi portfelami na kwotę 0.00006 BTC (~0,16 zł) zapłaciłem 0.00146 BTC (~0,38 zł) prowizji. Słabym pocieszeniem jest brak faktycznej konieczności płacenia prowizji od transakcji powyżej 0,01 BTC (~26 zł). W pozostałych przypadkach, jeżeli nie zapłacisz prowizji, zapomnij o potwierdzeniach transakcji w rozsądnym czasie. Lepiej skorzystaj z ELIXIR.
  2. Zerowa wiarygodność kursu. O ile punkt pierwszy Cię nie dotyczy, przygotuj się na konieczność szybkiego i częstego „przewalutowania” płatności otrzymanych w Bitcoin na coś stabilniejszego, lub na ryzyko utraty sporego odsetku pieniędzy w ciągu długiego weekendu. Zdaję sobie sprawę, że jest to pewnie kwestia młodego wieku tej waluty, jednak niedogodność tę trzeba mieć „z tyłu głowy” przy podejmowaniu decyzji o wdrożeniu płatności w Bitcoinach.
  3. Anonimowość w płatnościach Bitcoin to fikcja. Wszystkie transakcje są dostępne publicznie. Co z tego, że do informacji należy tylko adres portfela źródłowego, docelowego i kwota i że nie ma tam żadnych danych stron transakcji, tytułów, itp.? W praktyce jednak zawsze dojdzie do powiązania adresu portfela z podmiotem gospodarczym. A do tego wystarczy już tylko Google i np. https://blockchain.info/, i już każdy zna nie tylko saldo Twojego portfela, ale też szczegóły wszystkich jego transakcji. Jeżeli chcesz w miarę szybko zacząć przygodę z Bitcoin, prawdopodobnie kupisz pierwsze Bitcoiny w którymś z dużych kantorów. Przyda Ci się więc informacja, że jeden z największych – https://www.mtgox.com/ – przy rejestracji może poprosić Cię nie tylko o skan dokumentu tożsamości, ale też np. wystawionego na Ciebie rachunku za bieżące opłaty.

Powyższe powody dyskwalifikują dla mnie BTC w obecnym czasie. A szkoda, bo zakochałem się w tym, jak proste jest korzystanie z tej waluty – zarówno w zwykłych transakcjach, jak i samym wdrożeniu płatności w tej walucie w aplikacjach internetowych.

Odpowiedzialność moralna

Sąd Boż… Apelacyjny orzekł, iż Beata Sawicka ponosi odpowiedzialność moralną za przyjęcie łapówki w 2007.

Miało to miejsce prawie 6 lat temu, więc dla opinii publicznej jest to już prehistoria. W powszechnej pamięci zakorzeniła się na pewno ckliwa historia posłanki, która została wmanewrowana i uwiedziona przez złych agentów CBA.

Szkoda, że w Polsce nie obowiązuje reguła precedensowa, bo już zacząłem sobie wyobrażać komitety kolejkowe chętnych do poniesienia odpowiedzialności moralnej za podobne czyny:

Co dały mi studia?

Pół roku po obronie to dobry czas, aby podsumować jeden z dłuższych, formalnych etapów nauki (bo dłuższa była tylko sześcioletnia podstawówka). Jest to okres, który pozwala nabrać dystansu do studiów (a ten dystans mi się mocno przydał po „pożegnaniu”, jakie sprezentowała mojemu rokowi uczelnia), a jednocześnie wiele szczegółów ciągle się pamięta.

Obecnie jestem programistą języka drugiej kategorii w jednym z większych holdingów zajmujących się wielkim kapitałem. :> Podsumowanie to będzie więc pewnie zdominowane przez spojrzenie na studia pod kątem ich przydatności w tym zawodzie.

Początek studiów to matematyka. Można powiedzieć, że pierwsze trzy semestry były tylko delikatnie dekorowane przedmiotami ściśle technicznymi. Matmy było do zarzygania. Podobno ma to nauczyć ludzi myślenia na wyższym poziomie abstrakcji, niż dotychczas. Może i jest w tym trochę prawdy, jednak tylko za zasługą pojedynczych prowadzących zajęcia. Pozostałe wyglądały dość szablonowo i polegały na wałkowaniu tematu do czasu zauważenia schematu, który dało się przyłożyć do większości następnych zadań – a przynajmniej do tej ich części, która umożliwiała awans na kolejny rok. Ciężko mi więc określić, na ile przedmioty stricte matematyczne pomogły mi w życiu. Pewne jest, że umiejętności wyniesionych z uczelnianej matematyki nie wykorzystałem nigdy w praktyce, a moja obecna wiedza, np. o całkach, sprowadza się do ogólników i strzępów zasad ich rozwiązywania.

Ze względu na techniczny profil uczelni i – jak podejrzewam – konieczność wyżywienia pewnej mało potrzebnej obecnie katedry, mieliśmy dużo przedmiotów związanych z elektrotechniką. Część z nich była ciekawa i ogólna wiedza w tym temacie na pewno się przydaje, jednak mam wątpliwości, czy pchanie ich na takim poziomie na informatyce ma sens – powinny być raczej realizowane w szkole średniej na poziomie ogólnym. Poza wyjątkami – przedmioty te były fatalnie prowadzone, zaś prowadzący skutecznie obrzydzali nawet najciekawsze tematy. Tak było m.in. z moimi zainteresowaniami programowaniem niskopoziomowym. Ludzie, z którymi miałem pierwsze zajęcia z dotyczących go przedmiotów byli tak efektywni w tym, co robią, że do tej pory moje szczenięce fascynacje tym tematem wspominam już tylko z grymasem na twarzy. Ci prowadzący odpychali chęcią do nauki pod każdym względem, a ich doświadczenie zawodowe oscylowało gdzieś na początku lat 90., kiedy to udało im się napisać parę linii kodu w jakimś projekcie przemysłowych wag dla PKP. :> Pozostaje się tylko cieszyć, że ze względu na rekrutacyjne tendencje, katedra ta (a teraz nawet chyba instytut) umrze śmiercią naturalną.

Ale nie ze wszystkim było tak źle. Mimo, że ciekawe zaczęło robić się dopiero od trzeciego roku, to właśnie wtedy miałem większość przedmiotów, które wciąż mi się przydają. Chodzi głównie o solidną dawkę programowania obiektowego i równolegle prowadzoną inżynierię oprogramowania.

Tę drugą mogę określić chyba jako najlepsze zajęcia na całych studiach. Wykład był dyskusją o inżynierii oprogramowania z anegdotami i praktycznymi przykładami, co w fajny sposób otwierało umysł na pewne sprawy. Na laborkach było głównie projektowanie w narzędziach CASE z naciskiem na diagramy ERD. Tego, czego się wtedy dowiedziałem, używam praktycznie codziennie do dzisiaj i nie miałem z tym nigdy potem problemów, więc wydaje mi się, że zajęcia te były dość solidnie prowadzone.

Z programowania obiektowego również wiele wyniosłem, zwłaszcza, że jeszcze kilka lat przed rozpoczęciem studiów klasy służyły mi głównie jako kontenery dla metod i nie używałem niczego poza prostym dziedziczeniem. Zajęcia z C++ pozwoliły mi usystematyzować wiedzę, ale też wielu rzeczy się nauczyłem. Ostatecznie przygodę z tym językiem podsumowałem pracą inżynierską i – poza kilkoma zleceniami – już do niego nie wróciłem. Jednak sam paradygmat programowania obiektowego jest uniwersalny, a na składni C++ opiera się większość wiodących obecnie na rynku języków programowania. Kolejnym „moim” językiem stał się PHP.

PHP nauczyłem się całkowicie dopiero na studiach. Szybko jednak zostałem neofitą, a pokochałem zwłaszcza brak jawnych typów zmiennych. Zaczęło się od prostych aplikacji w „czystym” PHP na potrzeby projektów zespołowych. Polubiłem ten język, jednak perspektywa napisania w nim aplikacji bardziej złożonej od nieskomplikowanego CRUD-a przytłaczała mnie pod względem czasowym. Wtedy właśnie zainteresowałem się frameworkami. Pierwszym, z którym miałem styczność, był CakePHP, jednak wtedy było na niego trochę za wcześniej – byłem po prostu za głupi na ten framework. Trafiłem ze znajomym na CodeIgnitera – i to był strzał w dziesiątkę. Pisałem w nim ponad dwa lata i zrobiłem wiele zleceń. Projekty w nim realizowało też kilka innych osób na moim roku, co można uznać za dobre referencje dla CodeIgnitera – zwłaszcza, że wielu programistów PHP nigdy o nim nie słyszało. Obecnie pracuję z Zendem i perspektywa powrotu do CodeIgnitera wydaje się być nużąca, jednak jest to – moim zdaniem – najlepszy start, jaki mogłem sobie zapewnić w PHP.

Same projekty zespołowe dużo mi dały, ponieważ przez wszystkie na studiach inżynierskich realizowałem z kolegą, z którym dobrze szła mi praca. Pracę próbowaliśmy sobie ułatwiać i stosować np. duże IDE, zewnętrzne API czy systemy kontroli wersji (podczas, gdy reszta ludzi w grupie przesyłała sobie kod paczkami RAR w mailach :>). Na prowadzących raczej nie można było liczyć – ich rola sprowadzała się do nadzorowania projektu i testowania go pod koniec. Nie zapomnę sytuacji, w której prowadzący testował finalną wersję naszego pierwszego projektu, i po kilkunastu minutach, gdy już wydawało się, że skończył, wrócił się jeszcze ze słowami: „Sprawdzę jeszcze, czy przejdzie u Was SQL injection”. Świadomie pominęliśmy to zabezpieczenie ze względu na czas licząc, że prowadzący się nie zorientuje. Podczas, gdy już zastanawialiśmy się nad poprawkami, prowadzący otworzył formularz i zaczął wpisywać: !@#$, po czym wysłał formularz i – nieco zaskoczony – powiedział: „O, widzę, że przewidzieliście to. Wystawiam 5”. Nie wiem, na jakim poziomie była jego wiedza o SQL injection, ale nasz projekt można było wyłożyć nawet pojedynczym apostrofem w dowolnym polu.

Projekty zespołowe na studiach magisterskich były już mniej przydatne, ale to ze względu na olewający stosunek do studiów ze strony ludzi, którzy po części już pracowali lub czekali na obronę.

Wstyd się przyznać, ale SQL i bazy danych ruszyłem dopiero na studiach. Źle ułożony był też harmonogram studiów, który na ostatnim (lub przedostatnim) semestrze studiów I stopnia przewidywał pierwsze zajęcia z baz danych… w Accessie. Oczywistym więc było, że trzeba opanować bazy we własnym zakresie wcześniej.

Na studiach inżynierskich lubiłem też zajęcia z algorytmów i struktur danych. Dość dużo z nich wyniosłem i były ciekawe. Mówię tu jednak o laborkach, na których trafili mi się kompetentni prowadzący. Wykład był nudnym bełkotem dyktowanym z pożółkłych kartek, pamiętających pewnie lata 80.

Jeżeli chodzi o studia magisterskie, to żałuję, że na nie poszedłem. Przy rekrutacji do pracy nikt na to nie patrzył – skończyły się już czasy zatrudniania ludzi na podstawie dyplomu (a przynajmniej dyplomu polskich uczelni), a idąc wtedy do pracy, miałbym 1,5 roku doświadczenia więcej. Moi znajomi, którzy zdecydowali się na taki krok, planują już migrację do Warszawy.

Studia magisterskie były też nijakie pod względem jakości. Na pewno miał na to wpływ fakt, że były realizowane w ramach dużego projektu UE, który przewidywał m.in. wysokie wynagrodzenia za przygotowanie materiałów do zajęć. Brzmi motywująco, jednak termin, w jakim miały zostać opracowane, zamykał się w 1-2 miesiącach. Prowadzący jednak nie popuścili szansy na zdobycie takich pieniędzy, więc większość materiałów była po prostu kompilacją dostępnych w internecie informacji, wstawioną w nowy szablon. A przecież nikt tego merytorycznie nie weryfikował.

Za przydatne zajęcia z II stopnia studiów mogę uznać systemy baz danych. Wprawdzie w momencie ich rozpoczęcia nie było osoby, która by nie znała SQL, jednak ja sam nauczyłem się z nich PL/SQL-a i kilku innych rzeczy.

Co można powiedzieć o kadrze na studiach? To zależy. Przekrój jest dość duży: zdarzają się świetni nauczyciele, posiadający nie tylko wiedzę, ale potrafiący ją przekazać. Ale miałem wrażenie, że na moich studiach były to wyjątki. Prowadzących ze wspominanej już katedry można w większości uznać za zakały tej uczelni. Tematy się pokrywały, doświadczenie mieli nikłe, a na wykładach miałem się wrażenie, że padam ofiarą elokwencji niemających pojęcia o temacie ludzi.

Czego brakowało mi na studiach? Wzorców projektowych. Jest to wiedza, która przydaje się niemal każdemu developerowi, a jest na tyle uniwersalna, że wydaje się być idealnym tematem na zajęcia bez obawy o to, że narzuca się jakiś kierunek studentowi (jak ma to miejsce np. w doborze technologii). Brakuje też ludzi mających praktyczne doświadczenie w IT. Z rozmów z ludźmi z innych uczelni wynika, że pracuje w nich wielu prowadzących, którzy na co dzień zajmują się „swoją” dziedziną na wolnym rynku. U mnie naliczyłem tylko dwie takie osoby, które dodatkowo przerwały karierę na rzecz etatu na uczelni.

Miałem zamiar podsumowania studiów już od kilku tygodni i mam nadzieję, że zawarłem w tym wpisie wszystko, co chciałem przekazać. Być może ktoś wyciągnie wnioski z moich przemyśleń.

To przerażające!

Na początku października w Lublinie pojawiły się ateistyczne billboardy. Akcja była zapowiadana z pompą już miesiąc wcześniej. Ogłaszane były miejsca, gdzie zostaną postawione, były nawet jakieś przepychanki potencjalnych reklamobiorców z organizatorami akcji. Organizatorzy Ci z pełnym spokojem zaś odpierali zarzuty o atakowanie kampanią katolików. Po prostu – jak można było wywnioskować z ich argumentacji – organizatorami akcji byli tak gorliwi ateiści, że nie wystarczał im fakt tego, że nie wierzą, oni muszą po prostu podzielić się tym ze światem. Taka ateoewangelizacja.

Spokój organizatorów zburzyła jednak kontra jakiegoś katolickiego ruchu. Chodzi również o billboardy, ale te nawet nie stanęły jeszcze w Lublinie, lecz są w tej chwili dopiero dość prymitywną wizualizacją. Na zmontowanym obrazku widnieje hasło: „Pokazane Wam zostanie jak to jest umrzeć w stanie grzechu śmiertelnego (…) Ratujcie dusze póki możecie”. Powinno to ucieszyć katolików, bo jest równowaga dla ateistycznych billboardów, ale przy okazji autorzy tych drugich wpadli w panikę. Okazuje się, że ci sami ludzie, którzy wcześniej wydawali się być zdziwieni brakiem tolerancji wobec propagowanej przez nich „wolności od religii”, sami się przerazili. Tylko dlaczego słowa z ww. billboardów przerażają ateistę? Trzeba by spytać pani Doroty Wójcik, która tak oto zareagowała na katolickie hasła:

– Przekaz tego kontrbillboardu jest negatywny, atakujący i zastraszający – mówi Dorota Wójcik, prezes Fundacji Wolność od Religii. – Dla mnie stwierdzenie, że jeśli nie wierzysz w Boga, to umrzesz w mękach, jest przerażające.

Grzejące media

Proces tabloidyzacji mediów nie jest jakimś szczególnym odkryciem. Zdawałem sobie sprawę z tego od wielu lat, jednak dopiero ostatnio kilka rzeczy nastąpiło mniej więcej jednocześnie do tego stopnia, że uświadomiłem sobie, jak daleko proces ten się posunął.

Pierwszą z nich było uświadomienie sobie, że w zasadzie poza kilkoma portalami (jak np. Wiadomości Polskiego Radia lub Fronda) nie ma takiego, który można by czytać bez zażenowania. W ostatnim czasie otarłem się o kilka portali, których unikałem przez wiele lat. jak np. onet.pl lub wp.pl i miało to miejsce jeszcze przed wpisem, który opublikował torero, jednak wnioski są niemal identyczne. Brakuje po prostu informacji, takich podstawowych. Jeżeli szukasz jakiejś wiadomości, która z powodu nagannej absencji w sieci danego dnia ominęła Cię – nie licz na to, że portale informacyjne Ci ją zasugerują. Jeżeli chcesz poznać wynik meczu, który miał miejsce kilkanaście godzin temu, również o tym zapomnij. Sam przekonałem się o tym, gdy dzień po śmierci Szaniawskiego (która to informacja pojawiła się w mediach ok. 22:00) doznałem szoku, trafiając na jakiś offtopiczny komentarz pod innym newsem. Zamiast tego dowiedziałem się o tak ważnych sprawach, jak wypadek samochodowy anonimowej osoby, jakieś 600 km ode mnie. Mogłem też obejrzeć zdjęcia przykrytych zwłok, o czym dał mi znać krzyczący tag: „[ZDJĘCIA]” w tytule.

Na portalach informacyjnych można znaleźć w zasadzie same bzdury. Są to informacje żywcem z blokowiska, przeniesione na ogólnokrajowy grunt. Nie mają żadnej merytorycznej wartości, mają po prostu „grzać”. Czym bardziej kontrowersyjne, tym lepiej – za chwilę przecież „atakowana” grupa zacznie się bronić, zaś druga strona będzie dolewać oliwy do ognia. W tym całym kotle sytuację poprawiają trolle, które – wbrew pozorom – pomagają w robocie marketingowcom pracującym nad portalami. Przecież niekończące się dyskusje (mimo, że pozbawione sensu) to więcej wyświetleń reklam, nieprawdaż? Portale informacyjne opierają się więc o szeroko rozumianą prowokację. I nie ma tu nawet jakiejś mocno widocznej linii politycznej (poza specyficznymi portalami, jak np. gazeta.pl), bo podejrzewam, że dla właścicieli nie ma to wielkiego znaczenia. Wszędzie są więc zdjęcia, filmy, ogrom treści dla idiotów i reklamy. Większość tytułów kończy się prowokacyjnym pytaniem, niedomówieniami lub jest po prostu kłamliwych, tylko po to, aby odwiedzić stronę newsa. Ciężko też znaleźć portal bez cycków na stronie głównej – w dowolnej chwili.

Na koniec polecam ostatni wpis na blogu Ziemkiewicza. Traktuje on wprawdzie raczej o tygodnikach, jednak jest niezwykle trafny i zbiegł się z moimi ostatnimi obserwacjami.