Podejście zwinne a budowa aplikacji, czyli jak to wszystko zaplanować?

Metody zwinne w wytwarzaniu oprogramowania stały się tak popularne i wszechobecne, że nie będzie nadużyciem, jeśli stwierdzę, że prawie wszystkie organizacje pracują zwinnie, „w agile-u”. Jednak gdy przyjrzeć się dokładniej, okazuje się, że sprawy nie mają się tak kolorowo. Ciągle można zauważyć tendencję do planowania wszystkiego z góry. Nic dziwnego, skoro przez lata organizacje pracowały w ten sposób; zmiana sposobu myślenia nie dzieje się ot tak, z dnia na dzień. Ta zmiana wymaga olbrzymiej pracy i determinacji na wszystkich poziomach. Bez względu na to, czy mówimy o developerach, testerach, architektach czy osobach z szeroko pojętego biznesu.

Co robić?

Dosyć często szukamy winy u innych – to niestety nie jest najproduktywniejszy sposób rozwiązywania problemów. Jeżeli „agile” nie wychodzi, to może warto zastanowić się, co JA robię nie tak, co JA mogę zmienić w swojej pracy. Będąc programistą, developerem, popełniłem wiele grzechów – albo inaczej: mogłem wiele rzeczy zrobić lepiej.

Architektura

Zacznijmy z przysłowiowej grubej rury. Nie raz i nie dwa razy zdarzyło mi się zastanawiać jak zaprojektować architekturę aplikacji tak aby była wspaniała, doskonała i spełniała wszystkie możliwe (w owym czasie) trendy. Nie robiłem tego ze względu na CDD (CV-Driven Development) – chodziło o to, aby uniknąć problemów, z jakimi spotkałem się wcześniej. Tym razem zrobię to lepiej, tym razem będzie doskonale – znasz to skądś?

Stworzenie doskonałej architektury, która będzie idealnie odpowiadała potrzebom naszego projektu nie jest trywialne. Najprostszy sposób to napisać aplikację, a potem napisać jej wersję drugą, trzecią i czwartą – każdą lepszą od poprzedniej. Niestety, mało kto ma komfort przepisywania jednej i tej samej aplikacji x-razy. Co zatem można zrobić zamiast tego (i zarazem lepiej)? Okazuje się, że lepiej sprawdza się ciągłe dostosowywanie architektury aplikacji do zmieniających się potrzeb klienta oraz nowych wymagań.

Wyobraźmy sobie, że naszym klientem jest biblioteka. Pierwsze wymaganie to prezentacja listy książek, które są na stanie. Czego tak naprawdę potrzebujemy? Lista oraz sposób dodawania elementów (książek) do listy. Ile czasu jest potrzebne, aby coś takiego napisać? Pewnie niezbyt dużo. Ale czy nie korci Cię, aby od razu dodać możliwość usuwania, modyfikowania, no i oczywiście generowanie kodów kreskowych, żeby wkleić je do książki i umożliwić szybkie skanowanie…. i na pewno wyobraźnia podpowiada Ci setkę innych rzeczy, które należy dodać.

A jeśli naprawdę nasza biblioteka nie potrzebuje nic więcej? Jeśli ma 1000 oddziałów? A może ma być tylko online? A może wszystko będzie działało tylko na jednym komputerze sprzed 15 lat? Czy naprawdę znasz odpowiedzi na wszystkie te pytania? Ja ich nie znam, ale nieraz dopowiadałem sobie czego jeszcze klient potrzebuje. Potem często się okazywało, że te wyimaginowane „potrzeby” były do wyrzucenia lub co gorsze zostawały w kodzie, ale trzeba je było utrzymywać.

Architektura jest jak kurs dla jachtu. Wyznacza pewien kierunek. Drivery architektoniczne wskazują cel, do którego chcemy dotrzeć. Nie oznacza to, że wypływając z portu mamy zaplanowane wszystkie zwroty, wszystkie ustawienia żagli i do tego horyzont czasowy. Te same zasady powinny przyświecać podczas budowania aplikacji. Reagujemy na bieżące zmiany, bieżące potrzeby, bieżące burze i zawirowania, aby posuwać się do przodu w wyznaczonym (mniej więcej) kierunku. Wypisz wymaluj czwarte zdanie z Agile Manifesto:

„Responding to change over following a plan”

Architektura architekturą, ale ktoś musi napisać kod

Są takie organizacje, gdzie funkcjonuje dział architektów, którzy tworzą najlepiej jak potrafią, najlepszą architekturę, która ma sprostać wszystkim wymaganiom. Jeżeli ten dział nie współpracuje z osobami tworzącymi kod to… no cóż, pojawia się brak zrozumienia oraz konflikty. Co więcej, tak powstała architektura nie jest architekturą a jedynie projektem. Architekturą jest to co zostało wykute w kodzie. Jeśli rozdzielimy te dwie rzeczy, jeśli architektura powstaje tylko na papierze, wówczas pozostaje projektem lub marzeniem. Jeśli zaś kod powstaje bez architektury, niejako samorzutnie, zazwyczaj przypomina spaghetti. Ani jedno, ani drugie nie jest czymś czego oczekują klienci. Klienci chcą:

„Działające oprogramowanie od szczegółowej dokumentacji”

Aby tego dokonać architekci i programiści muszą współpracować. Potrzebujemy w zespole osoby, która raz za jakiś czas usiądzie i zastanowi się, czy obecna architektura jeszcze spełnia bieżące wymagania, czy już pora na refaktoryzację. I zwróć uwagę: refaktoryzację a nie rewolucję.

Refaktoryzacja

Dlaczego refaktoryzacja jest taka ważna? Wiadomym jest, że klienci będą mieli nowe potrzeby i nowe wymagania. Gdy tylko nasze oprogramowanie rozwiąże ich problemy, zaraz pojawią się nowe potrzeby. Wraz z nowymi potrzebami może okazać się, że należy trochę przebudować nasz kod. Jeśli robimy to regularnie, jeśli regularnie myślimy o refaktoryzacji, wówczas poprawiamy w takiej sytuacji tylko to, co poprawione być musi, zamiast przebudowywać całą aplikację. Jeżeli nasz kod bardziej przypomina pudełko klocków Lego (low coupling) niż talerz spaghetti (hight coupling) to jesteśmy w stanie przemodelować środek aplikacji bez wielomiesięcznej rewolucji.

Eee… tam, to tylko teoria!

No nie, to nie jest tylko teoria, to jest długoterminowy plan i codzienna solidna praca nad kodem. Rozmawiałem kiedyś z człowiekiem, który zjadł zęby na Event Sourcingu i to z niemałymi sukcesami. Wiesz jaki był jego przepis?

  1. Tworzymy aplikację CRUD. Tak zwykły CRUD – „nothing fancy”. Dlaczego tak? Bo tworząc CRUD-a jesteśmy w stanie bardzo szybko dostarczyć klientowi podstawową funkcjonalność, to po pierwsze. A po drugie poznajemy potrzeby i domenę.
  2. Po kilku tygodniach/miesiącach zaczynamy publikować eventy. Dlaczego tak? Bo po tych kilku tygodniach/miesiącach znamy już domenę na tyle dobrze, że jesteśmy w stanie sensownie zidentyfikować zdarzenia domenowe. Co ciekawe, na początku tylko publikujemy eventy – nie konsumujemy ich. Taka zmiana dla klienta jest praktycznie niewidoczna.
  3. Po dalszych kilku tygodniach/miesiącach zaczynamy konsumować eventy. Dopiero tutaj z wprowadzonych wcześniej eventów pojawia się (dodatkowa i duża) wartość dla klienta. Wartość dodatkowa, bo już na samym początku dostarczamy wartość zwykłym CRUD-em. Teraz jednak pojawia się wielkie WOW! Można dostarczyć klientowi informacje o danych wstecz. Dlaczego dopiero teraz? Bo z każdą linijką kodu, poznajemy coraz więcej szczegółów i zawiłości problemów klienta, a im więcej wiemy, tym trafniejsze decyzje możemy podejmować.

Pamiętasz jeszcze to co pisałem o bibliotece? Jaką najlepiej użyć bazę danych? Na studiach pewnie była relacyjna – ale która? Masz wybraną jedną, jedyną słuszną? Jak się zmieni ten wybór, jeśli odkryjemy, że mamy obsługiwać 50% bibliotek na świecie? Jak się zmieni wybór, jeśli odkryjemy, że te 50% bibliotek to specjalistyczne wewnętrzne biblioteki w szpitalach? W końcu jak się zmieni wybór, jeśli okaże się, że ze względu na RODO, dane nie mogą wypłynąć poza szpital? Im więcej wiemy, tym lepsze decyzje możemy podejmować. Na początku projektu nie mamy takiego komfortu jak na końcu.

Ale jeśli dobrze zbierzemy wszystkie wymagania na początku…

No to będzie łatwiej, tylko czy to jest w ogóle możliwe? Będąc młodym developerem, miałem nadzieję, że tak. Wyciągnę wnioski z poprzednich projektów, przetrawię to, przeanalizuję i teraz będzie lepiej. Jednak problemy zasadniczo są dwa.

  1. Klient nie powie nam o wszystkim, bo pewne rzeczy będą dla niego oczywiste i w jego odczuciu nie będą wymagały dyskusji. Klasyczny przykład to systemy do wystawiania faktur z lat około ‘90. W sumie temat do „obgonienia” w Excelu. Jak zapytamy klienta czy jest taka faktura to powie nam, że dokument obejmuje: odbiorcę, wystawcę, numer, datę, pozycje… tutaj suma, tam mnożenie. Żadna technologia kosmiczna. Ale jak wejdziemy w szczegóły to okaże się, że mamy proformy, korekty, faktury zagraniczne, zagraniczne wewnątrzwspólnotowe, z odwrotnym obciążeniem i jeszcze pewnie wiele innych typów. Klient o wielu pewnie nam nie powie, bo dla niego to może być oczywiste.
  2. Jeśli dostarczymy klientowi dobry, działający software – taki, który spełnia jego potrzeby i rozwiązuje jego problemy – to pewnie wkrótce zaczną się pojawiać nowe potrzeby. Prosta sprawa: jeśli już zbudowaliśmy ten system do faktur, to może by tak zrobić mailing na koniec roku do naszych kontrahentów? Jak mamy mailing, to może jakiś system bonusów dla naszych najwierniejszych klientów? Wraz z jedzeniem apetyt rośnie więc i wymagań będzie przybywać.

„Bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności.”

Źródło: „Założenia Manifestu Programowania Zwinnego”

Ale nam się wszystko wali

Już wiemy, że mamy stały i nieunikniony strumień wymagań. Wiemy, że nie zaprojektujemy „über-architektury”, która wszystko zniesie – tylko będziemy musieli ciągle (continuously) refaktoryzować i dostosowywać się do zmian. Jak w ogóle zapanować nad tym „chaosem”? Odpowiedź znajdziemy na drugiej stronie Agile Manifesto – w 12 zasadach wspierających rozwój oprogramowania.

„Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność.”

Tworząc linijkę kodu tworzymy ją najlepiej jak potrafimy. Pisząc kawałek kodu z przysłowiowego „buta” pamiętać należy, że to my sami będziemy ten kod utrzymywać, więc pewnie i sami się potkniemy o niego. Nie wierzysz? Spróbuj w domu codziennie zjeść trzy banany, a skórki rzucaj na podłogę. Jak myślisz, po jakim czasie przejedziesz się na jednej z nich?

„Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów.”

Słowo klucz to ZESPÓŁ!!! Nie w pojedynkę, nie każdy osobno na swoim piętrze, ale razem, zespołowo. Łącząc różne kompetencje jesteśmy wstanie budować lepsze produkty, które lepiej odpowiadają na potrzeby naszych klientów.

„W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.”

Regularna samokontrola to podstawa, tak powie Ci każdy lekarz. Nie inaczej sprawy się mają z budowaniem produktów. Na co dzień zakaszemy rękawy i tworzymy kod, testujemy, wdrażamy, naprawiamy, piszemy SQL-e i JSON-y, docker-file i YAML-e, praca wre. Ale regularnie powinniśmy się zatrzymać i sprawdzić, czy zmierzamy w dobrym kierunku. Czy ten wspaniały framework, który przywieźliśmy z konferencji nas spowalnia czy przyspiesza. Raz w tygodniu zatrzymaj i zastanów się, czy nie biegasz tak szybko z taczkami, że nie masz czasu ich załadować. A może nie taczki, tylko wiadro będzie lepsze? Refleksja nad tym co i jak robimy jest najlepszą praktyką, jaką można sobie wyobrazić.

Call for papers: BBQ4IT i BBDays4IT

Pamiętasz BBQ4IT? Jeśli nie to przeczytaj skąd się wziął pomysł jakże nietypowej konferencji pod chmurką czyli BBQ4IT . Trzy edycje minęły i teraz pora na zmiany. Pora na nową lepszą wersję. BBQ4IT jako takie zostaje, czyli będzie powietrze, będzie bbq i będzie chill. Jednak oprócz tego będzie dużo dużo więcej. Będzie część bardziej techniczna, będzie też kumulacja meetup-ów oraz różnych aktywności w bielskich firmach.

BBQ4IT rośnie do całotygodniowego festiwalu informatycznego gdzie oprócz konferencji pokażemy lokalne grupy, pokażemy firmy z regionu. Dlaczego? Bo w okolicy dzieje się bardzo dużo mimo, że czasem tego po prostu nie widać.

No i teraz pytanie od Ciebie. Chcesz być częścią tej inicjatywy? Chcesz budować historię i stać się częścią pierwszej epickiej edycji BBDays4IT? Masz szansę… zgłoś się na Call For Papers i masz szansę zbudować historię.

BBQ4IT / BBDays4IT CFP

A jeśli nie czujesz się na siłach aby wystąpić jako prelegent ale zastanawiasz się czy przyjechać, pochodzić po górach, posłuchać o it i spotkać niesamowitych ludzi to mam dla Ciebie PRO TIP!!! Wejdź na stronę festiwalu i zapisz się na newsletter aby nie przegapić ważnych informacji – w zeszłym roku wejściówki na BBQ4IT rozeszły się mega szybko więc żeby nie było potem płaczu 😉

CoreDump – zaproszenie

Sezon konferencyjny został oficjalnie rozpoczęty – przez BBQ4IT oczywiście 😉 – machina ruszyła. Czasy są teraz złote bo można wybierać i przebierać. Jest jednak kilka perełek i dzisiaj o takiej perełce właśnie. Dzisiaj będzie o CoreDump i SegFault.

 

CoreDump to konferencja wyjątkowa, to ukoronowanie serii konferencji SegFault. Najbliższy SegFalult odbędzie się we Wrocławiu, 24 września więc dni zostało już niewiele. To co odróżnia SegFault-y od innych konferencji to tematyka, która skupiona jest nie na nowych frameworkach i libach a na fundamentach branży. Na tych koncepcjach i podstawach teoretycznych, które są niezmienne. Na Wrocławski SegFault możesz się zarejestrować tutaj.

Wracając jednak do CoreDump – korony serii SegFault. To tam będzie jeszcze głębiej jeszcze bardziej o podstawach. Brzmi ciekawie? No to teraz taki pro tip….

jutro, w dzień programisty będzie okazja wyrwać wejściówkę taniej, dużo taniej. Tajny kod na promocje to „2_do_potegi_8” – jakby inaczej 😉 i z tego co wiem to kod ma działać również na SegFaulta. Tylko jedna sprawa, kod działa tylko jutro 🙂 więc nie ma co zwlekać.

 

 

AKTUALIZACJA: 12.09.2018

W branży czasem się mówi o błędzie off by one. Najwyraźniej tym razem też mamy taki bug (chociaż dzisiaj to nie bug). Promocyjny kod zniżkowy działa już od dzisiaj 😀

Jak zarządzać dużą ilością testów automatycznych?

testy automatyczne

Testy automatyczne – jeszcze kilka lat temu coś bardzo egzotycznego i mało spotykanego – bo przecież można zatrudnić skończoną ilość studentów do przeklikiwania. Chyba wielu słyszało ten idiotyczny tekst. Rynek jednak powoli się zmienia. Obecnie okazuje się, że przysłowiowych klikaczy nie ma już tak wielu. Zresztą, zatrudnianie klikaczy do testowania aplikacji od A do Z jest skrajnie nieefektywne kosztowo. Taka osoba może klikać 8h dziennie, jednak po kilku iteracjach klikania zacznie być coraz mniej efektywna, przyjdzie zarówno zmęczenie jak i znużenie. Efektywność w wyłapywaniu błędów może znacząco spaść.

Testy automatyczne

Testy automatyczne to naturalny krok w rozwoju organizacji. Dosyć szybko można zauważyć, że niektóre testy można zautomatyzować. Ma to tę zaletę, że odciążamy człowieka, który teraz może bardziej skupić się na pracy testera, czyli na opracowywaniu scenariuszy testowych, a nie na bezmyślnym klikaniu wg. ustalonego scenariusza. Może zająć się czymś bardziej kreatywnym. Super…

…ale

…ale nie ma róży bez kolców. Test automatyczny działa bardzo zero-jedynkowo, albo przechodzi albo nie. Jeśli testy automatyczne są napisane prawidłowo – czyli nie są to tzw. flaky tests, które raz przechodzą a raz nie – to powinny zacząć nie przechodzić w momencie pojawienia się błędu w aplikacji lub w przypadku zmiany logiki aplikacji.

Jeśli pojawił się błąd w aplikacji – należy poprawić aplikację, jeśli natomiast zmieniła się logika aplikacji to trzeba dostosować test automatyczny do nowych wymagań. Jest jednak jeszcze jedna zmiana, która nie jest ani błędem ani zmianą w logice aplikacji, a też może spowodować, że nasze testy automatyczne przestaną działać.

Testy automatyczne a zmiana interfejsu użytkownika

No właśnie, zmiana w interfejsie użytkownika. Trochę inne kolorki, trochę inny układ przycisków, drobne poprawki UI/UX i już nasze testy leżą.

Z każdym jednym testem automatycznym, który dodajemy do naszego rozwiązania dodajemy kolejny element, który trzeba utrzymywać. Przy 2-5-10 testach automatycznych to nie jest wiele pracy, ale co jeśli tych testów będzie 100-1000? Wtedy zaczyna to być znaczący koszt. Czasem pojawia się pomysł, aby zaprzestać używać testów automatycznych, bo to kosztuje zbyt dużo. Decyzja taka jednak jest jak wylanie dziecka z kąpielą. Rozwiązuje problem, ale może niekoniecznie w sposób pożądany. Albo dosadniej, na ból głowy lepiej wziąć lekarstwo niż zaaplikować gilotynę. Niby oba sposoby działają, ale ten pierwszy jest jednak bardziej preferowany.

Ok, to jak poradzić sobie z dużą ilością testów automatycznych? Tak, aby się dało to utrzymywać przy rozsądnym koszcie? Rozwiązaniem jest Page Object Pattern. Wzorzec bardzo prosty w swoim założeniu i genialnie efektywny, jeśli stosowany poprawnie. Jeśli chcesz wiedzieć więcej na temat tego wzorca, to zapraszam Cię na zupełnie DARMOWY webinar na temat Page Object Pattern.

Jest tylko jeden haczyk. Trzeba się spieszyć z rejestracją, bo czasu nie zostało wiele.

REJESTRACJA

5 błędów początkującego blogera

Jeżeli mój poprzedni wpis o zaletach blogowania zainspirował Cię do założenia własnego bloga albo już wcześniej chodził Ci po głowie pomysł założenia to jest pięć rzeczy, które musisz wiedzieć. Poznaj 5 błędów popełnianych przez osoby zaczynające blogowanie. Te 5 błędów bardzo często powoduje, że blogi jak szybko powstają tak samo szybko umierają ze szkodą dla ludzkości 🙂 Taką szkodą, że mogły by się tam pojawić bardzo wartościowe przemyślenia – ale się nie pojawią bo osoba prowadząca utknęła – najczęściej – na przynajmniej jednym z poniższych problemów….. serio, widziałem to kilkanaście razy, ktoś stwierdził, że zacznie pisać, a potem…. no cóż….

Kiedy zacząć prowadzić bloga

No właśnie, kiedy? Niektórzy mówią, że blogosfera już umarła, że teraz videło, jutuby i inne tego typu wynalazki bo milenialsi to pokolenie obrazkowe. Serio? Ale serio? Fajnie się ogląda vlogi i filmiki ale jeśli potrzeba konkretnej wiedzy to jednak tekst jest wygodniejszy do konsumpcji, łatwiejszy do wyszukania, łatwiejszy do szybkiego przeglądnięcia, do szybkiego przeczytania. I nawet źli osławieni milenialsi czytają. Tekst nie umarł, dlatego i blogi nie umarły. Zresztą zastanów się przez chwilę, ile treści odnośnie programowania konsumujesz w postaci video a ile w postaci blogów i artykułów tekstowych o programowaniu? No właśnie…

Blogi nie przeminęły, słowo pisane nie przeminęło. Jeśli chcesz założyć bloga to to zrób, tu i teraz. Otwórz nową zakładkę w przeglądarce i załóż. Nie ma co czekać na poniedziałek, pierwszy dzień miesiąca czy nie daj boże roku. Tu i teraz jest najlepszy czas. Lepszy czas już był 5, 10 lat temu. Jeśli serio chcesz założyć bloga to nie odkładaj tego – pora działać.

Wybór platformy blogowej

TL;DR; Wordpress.

Nie zastanawiaj się, czy lepszy jest wordpress czy joomla, czy może drupal, a może ghost, a może samemu coś by się dało napisać. Żadne własne wynalazki się nie sprawdzą. Serio… Zbudowanie porządnej platformy do blogowania to zadanie na pełny etat. Trzeba pomyśleć o bezpieczeństwie, o SEO, o wygodzie czytelnika i milionie innych rzeczy. Nie ma sensu pisać własnego narzędzia jeśli w 5 minut jesteś w stanie postawić działającego wordpressa. Wybór platformy blogowej to pierwsze sito odsiewające. Na tym etapie padło wielu. Wchłonięci w czeluści internetów, analizujący internetowe wojny o wyższości XXX nad YYY. Bez sensu…. instaluj wordpressa i pisz. To jest Twoje najważniejsze zadanie na początku prowadzenia bloga. Może kiedyś, gdy Twoje umiejętności w temacie wzrosną, gdy świadomość wzrośnie, zaczniesz się zastanawiać nad zmianą platformy. Ale tu i teraz, nie pora na to. Instaluj i pisz pisz pisz!!!

Wybór hostingu

Sito numer dwa, hosting. Który lepszy, który wydajniejszy, który daje więcej ficzerów. Może VPS lepszy bo postawie co chcę i jak chcę. Wszystko zabezpieczę, wszystko poustawiam…. bla bla bla. Serio? Masz telefon w kieszeni? Zbudowany samodzielnie? A może samochód kupujesz w częściach i składasz w garażu? Wybór hostingu na początku nie ma zupełnie znaczenia. Nawet najgorszy, najmniej wydajny hosting da radę. Powaga. Jeśli kupując domenę dostałeś jakiś minimalny hosting za free – to wiedz, że on zupełnie wystarczy. Cały myk w blogowaniu polega na tym aby pisać pisać pisać. Na początku nie będzie walić 10000 ludzi dziennie więc to serio nie ma znaczenia. Nie ma sensu marnować energii i czasu na analizowanie wszystkich hostingów na rynku. Zdradzę, Ci sekret. Bloga można przenosić pomiędzy hostingami. To się da zrobić i nawet nie jest jakieś specjalnie trudne. Jeśli myślisz o założeniu bloga to kluczem jest pisanie. Więc na początku skup się tylko na tym….. i na niczym innym.

Wybór skórki, tematu

Trzeci krąg piekła, odsiewający tych co już zainstalowali wordpressa. Ten krąg odsiewa najwięcej adeptów. Temat, skórka, wygląd. Jaki wybrać. Co wybrać. Wiadomo, musi być responsywny, musi być piękny, musi być wspaniały. Najlepiej bezpłatny. I wchodzisz w skórki, i przeglądasz, i szukasz. Energia Ci maleje bo tematów w internetach znajdziesz miliony. W każdym coś nie będzie Ci pasować, w każdym coś będzie nie tak. Czasem może się pojawić szaleńcza myśl, poprawię ten temat, albo jeszcze gorsza, zrobię samodzielnie temat. UWAGA!!! TO BŁĄD. Co jest najważniejsza rzeczą w blogu? TREŚĆ!!! TREŚĆ!!! TREŚĆ!!! więc pisz pisz pisz. Jeśli po trzech miesiącach dalej będzie Ci się chciało pisać i będziesz regularnie pisać to wtedy poszukaj sobie jakiegoś tematu. Wcześniej nie ma sensu bo poszukiwania idealnego tematu zabiorą Ci resztki energii i nie powstanie nic. Znowu, z doświadczenia, wielu adeptów padło na tym etapie. Chcieli prowadzić bloga ale poszukiwania tematu idealnego zwiodły ich na manowce. Nie popełniaj tego błędu i używaj tematu domyślnego. Zacznij myśleć o jego zmianie dopiero 3 miesiące po regularnym pisaniu. Jeśli domyślny temat wydaje Ci się brzydki i bezsensowny to mimo wszystko oprzyj się pokusie zmieniania go a swoją energię przelej na pisanie pisanie i jeszcze raz pisanie.

Wybór pluginów

Jest jeszcze jeden krąg piekła, który odsiał niemało adeptów blogowania i zawrócił z drogi tworzenia na drogę konsumpcji. Pluginy. Wiadomo, żodyn, ale to żodyn wordpress nie ostanie się bez dobrej paczki pluginów. Tylko jakie wybrać. Jak zainstalować. Cache, optymalizacje, seo, karty fb, karty tt, meta sreta. Jeśli dalej czytasz, to już wiesz jaka jest odpowiedź. Na początku drogi nie potrzebujesz, żadnych pluginów. Potrzebujesz treści więc musisz pisać pisać i jeszcze raz pisać. Dopiero po jakimś czasie zastanów się, czy na pewno potrzebujesz jakiegoś pluginu, a jeśli tak to jakiego. Na samym początku skup się na treści. Przyjdzie czas na picowanie bloga.

Na koniec mały disclaimer. Nie zrozum mnie źle, pluginy, dobry temat, solidny hosting to wszystko jest potrzebne i ważne ale nie na początku. Na początku skup się na budowaniu treści i budowaniu nawyku pisania. Masz wiele rzeczy nad którymi trzeba pracować więc nie bierz za dużo na barki. Nie zmarnuj swojej początkowej energii a skieruj ją na pisanie i tworzenie TREŚCI.  Na początku to jest najważniejsze. Wszystkie inne rzeczy to drugi, trzeci i czwarty plan. Serio, jeśli wytrwasz i przez trzy miesiące będziesz regularnie pisać to dopiero wtedy zacznij myśleć o tych innych rzeczach. Wtedy to będzie miało sens.

…a teraz pora założyć swojego bloga, tylko wiesz…. 🙂

Powodzenia

 

 

5 rzeczy, które da Ci prowadzenie bloga

Ponad 10 lat temu założyłem tego bloga. Jak, chyba każdy,sam zacząłem od wpisu a’la hello world. Właśnie przed chwilą go otwarłem i przypomniałem sobie, że to nie było pierwsze podejście do tematu – zresztą sprawdź sam. Przez te 10 lat nie blogowałem regularnie, jednak z perspektywy czasu nasunęło mi się kilka myśli i powodów dlaczego warto założyć własnego bloga – choćby dzisiaj. Być może będzie to dla Ciebie ciekawa inspiracja, być może stwierdzisz, że też tak chcesz. Być może masz już swojego blogaska i masz inną perspektywę – chętnie posłucham. Tymczasem oto moja subiektywna lista 5 rzeczy, które da Ci prowadzenie bloga.

1. Wzrosną Twoje umiejętności

Bez względu na tematykę bloga, Twoje umiejętności wzrosną. Poprawi Ci się interfejs pisarski. W zawodzie programisty często krąży obiegowa opinia, że to nie jest nasz najważniejszy skill – bo przecież „ja se kodzik pisze a nie wypracowania”. Nie do końca jest to prawda. Czasem trzeba napisać maila do klienta albo współpracownika. Czasem trzeba napisać – o zgrozo – kawałek dokumentacji. Pół biedy jak to jest dokumentacja techniczna – wtedy dobra ilość „exampli” się obroni, czasem jednak trzeba napisać dokumentację taką dla… wiesz, normalnych ludzi. Zresztą pisanie to nie wszystko. Przecież bloga prowadzi się o czymś. Jeśli zaś piszemy o czymś, to warto by było pisać o czymś na czym się znamy – zgadza się? Pisząc o programowaniu czasem trzeba sięgnąć do książki czy dokumentacji i okazuje się, że właśnie nasze umiejętności techniczne trochę wzrastają. Działa tutaj stara zasada – jeśli chcesz się czegoś dobrze nauczyć, zacznij uczyć innych. Wtedy wszelkie luki we własnej wiedzy powoli się wypełniają. Czasem ktoś zada ciekawe pytanie i trzeba poszukać głębiej. Czasem ktoś podrzuci uzupełniający materiał. Przekazując wiedzę innym, pogłębiasz swoją własną. Win-win.

2. Prowadznie bloga nauczy Cię SEO

Być może, nie tworzysz systemów webowych, być może seo zupełnie Cię nie interesuje. Prowadząc bloga jest jednak duża szansa, że wcześniej czy później zaczniesz zgłębiać tą tematykę. Dowiesz się jakie znaczenie ma optymalizacja tekstu, js-ów, css-ów i wielu, wielu innych rzeczy. Tematyka jest bardzo szeroka. Ja dzięki temu blogowi liznąłem tematykę AdWords i AdSense, jakieś podstawy SEO właśnie, reklamy na FB, jak pisać ciekawie – tak aby ludzie chcieli to czytać. Poznałem wiele narzędzi i mechanizmów, których bym nie poznał bo nie leżą one w zakresie moich codziennych zadań. Jak pewnie wiesz, trudno uczyć się wszystkiego, trudno też uczyć się suchej teorii. Blog może być bardzo fajnym eksperymentem do zgłębiania tajników internetów i lepszego zrozumienia jak cała ta sieć działa. Być może odkryjesz w sobie nowe talenty albo poznasz technologie, które bardziej Cię wciągną niż codzienna „bieżączka”.

3. Poznasz ciekawych ludzi

Nie samym internetem człowiek żyje, ale internet może spowodować, że poznasz ciekawych ludzi, którzy mają podobne pasje i podobne zainteresowania jak Twoje. Znajomości offlineowe mają pewne geograficzne ograniczenie. Internet znosi tą barierę a prowadzenie bloga może spowodować, że dotrzesz do takich jak Ty. Jak to działa? Ano jeśli piszesz w miarę regularnie to zostawiasz w Internecie pewną wartość. Nawet nie zdajesz sobie sprawy dla jak wielu ludziom Twój wpis może ułatwić pracę. Później będąc na konferencji czy jakimś meetupie te osoby mogą przyjść i podziękować, powiedzieć, że Twój tekst im pomógł. Nie raz miałem takie sytuacje i to daje miłą satysfakcję i energię do dalszej pracy. Pewnego razu dostałem nawet mailowe podziękowania od kogoś z bodajże USA, że mój post pozwolił rozwiązać problem, który ta osoba miała, a nawet na Stack Overflow nie było odpowiedzi. Najciekawsze w tym wszystkim jest fakt, że piszę po polsku – to jednak nie stanowiło bariery. Komunikat błędu plus screeny były wystarczającą informacją dla tej osoby. Piękne, prawda? Jestem przekonany, że w Twojej codziennej pracy zmagasz się z wieloma problemami. Opisz je, podaj rozwiązanie, pomożesz komuś.

4. Otworzą się przed Tobą różne drzwi

Prowadzenie bloga otwiera czasem, różne ciekawe drzwi. Czasem jakaś firma poprosi Cię o opinię. U mnie tak się stało po serii artykułów o długu technologicznym. Napisała do mnie firma z Francji, która próbowała wprowadzić narzędzie do zarządzania długiem technologicznym na polski rynek. Niestety wtedy (a był to rok 2013) temat był… delikatnie mówiąc abstrakcyjny dla wielu ludzi.  Po wielu mailach stwierdziliśmy, że jeszcze nie pora na to narzędzie. Oczywiście firma prowadziła dalej swoje badania (przecież nie będą się podpierać opinią jakiegoś jednego kolesia z internetów), wróciła do mnie po ponad pół roku z informacją, że niestety ale na tamtą chwilę, rynku w Polsce na to nie ma. Inne drzwi, które otwarły się dla mnie przez (między innymi) prowadzenie bloga to możliwość prowadzenia szkoleń – a tym samym pogłębianie mojej własnej wiedzy (patrz punkt 1). Z tymi szkoleniami to dłuższa historia – może na inny wpis – jednak posiadanie jakiejś udokumentowanej i online-owej bazy tekstów ułatwiły wejście do tego świata.

5. Zbudujesz swoją własną, podręczną bazę wiedzy w formie bloga

Najważniejsze zostawiam na koniec. Własna podręczna baza wiedzy w formie bloga. Rozpoczynając blogowanie nie miałem zamiaru zostać znanym blogerem – to nie był mój cel. Bardziej chciałem spisywać rzeczy, które mnie interesują. Pisać dla siebie. Tworzyć treści, do których mogę czasem wrócić. Wielokrotnie zresztą wracałem. Ile razy zdarzyło Ci się drugi, trzeci raz tłumaczyć to samo? Albo kolejny raz szukać rozwiązania tego samego problemu? Napisz notkę na blogu i voila. Czasem sam sięgałem do taki wpisów a czasem podsyłałem komuś link do gotowego rozwiązania – jak choćby integracja SVN z GIT-em. Jeden link i problem z głowy. Same plusy.

 

 

BBQ4IT czyli najlepsza konferencja na Podbeskidziu – Call For Papers

BBQ4IT jako pomysł pojawił się dwa lata temu. Od pomysłu do czynu i tak powstała konferencja (więcej o BBQ4.IT możesz przeczytać tutaj). W tym roku odbędzie się kolejna edycja tej zacnej inicjatywy. Prace nad nią już trwają. W związku z tym mamy dla Ciebie propozycję. Jeśli chcesz współtworzyć tą konferencję z nami to zgłoś swojego talka na BBQ4IT już dzisiaj. Scenę będziesz dzielić z dwiema gwiazdami polskiej sceny IT, które już potwierdziły swój udział… (ale na razie ciiiisza, nie zdradzamy kto to) więc, żeby potem nie było płaczu, że mogłam/mogłem wystąpić na scenie obok ….. i ……. 🙂 siadaj do tematu i wysyłaj na:

http://bbq4.it/c4p