poniedziałek, 30 grudnia 2013

Niech Wam testy przejdą :)

Ostatnio trochę Was zaniedbałem za co serdecznie przepraszam i obiecuję, że w nadchodzącym roku postaram się nadrobić dwumiesięczny brak aktywności na blogu :) To tyle w kwestii usprawiedliwiania się, w końcu kończy się rok i nie ma co płakać nad tym, co nie wyszło w stu procentach tak jak byśmy chcieli. Natomiast tym, co wyszło dobrze albo nawet lepiej niż zakładaliśmy również trzeba przestać się zachwycać i zrobić miejsca na kolejne sukcesy :)

Dzisiaj krótko i w klimacie TDD - Niech za rok, po odpaleniu, poniższe testy Wam przejdą :)

sobota, 19 października 2013

SOLIDny kod cz. 4 - Liskov substitution principle

zacznijmy od podstaw

Zasada podstawienia Liskov brzmi:
Funkcje które używają wskaźników lub referencji do klas bazowych, muszą być w stanie używać również obiektów klas dziedziczących po klasach bazowych, bez dokładnej znajomości tych obiektów.
Sprowadza się to do tego, że w każdym miejscu gdzie wykorzystujemy klasę bazową (rozszerzaną) lub interfejs możemy wykorzystać każdą klasę potomną i nie wpłynie to na zmianę zachowania czy też wynik działania, nie wpłynie negatywnie na działania aplikacji.

wtorek, 15 października 2013

Prototype i this - wiem, że nic nie wiedziałem

Kolejna prezentacja stworzona przez Piotrka Repetowskiego i Mirka Filipa. Tym razem na temat działania prototype i this w JavaScripcie. Obejrzyjcie, bo warto:)

Człowiek nie zdaje sobie sprawy o ilu rzeczach nie wie i ile kryje się "pod maską" dopóki ktoś mu tego w jasny i klarowny sposób nie przedstawi:)

Nie mam wątpliwości, że dzięki tej prezentacji dowiecie się "kilku" interesujących (i możliwe, że przydatnych) rzeczy:)

Prezentacja do obejrzenia tutaj.

piątek, 11 października 2013

Programista - zawód niewdzięczny...

Bycie programistą nie jest proste, a im lepszym się stajesz, im więcej widzisz i wiesz, tym cięższe staje się Twoje życie. I wcale nie mam na myśli tej ciągłej konieczności bycia "na bieżąco", uczenia się nieustannie nowych języków, paradygmatów, technik, bibliotek i wszystkiego tego, co dobry programista wiedzieć powinien, aby być "wartościowym towarem" na rynku pracy.
Nie, to naprawdę nie jest problematyczne, a im trafniejszy był wybór Twojego zawodu, tym bardziej te wszystkie rzeczy Cię cieszą. Rozwój może być wycięczający i męczący, ale w gruncie rzeczy każdy z nas chce to robić i w dodatku chce to robić bez przerwy, zarówno w pracy jak i po godzinach.

sobota, 28 września 2013

Czasami szkoda czasu na najlepsze rozwiązania

Kilka dni temu rozmawiałem z członkiem mojego zespołu na temat niektórych defectów, które zgłaszamy.
Stwierdził on, że o ile zazwyczaj nie ma się nad czym rozwodzić i kłócić, to zastanawia się, czy w niektórych przypadkach nie jest to zwyczajny przerost formy nad treścią (nie cytuję, więć z góry przepraszam za wszelkie odstępstwa). O co mianowicie chodziło?
Zastanawiał się czy rzeczywiście zawsze warto inwestować czas w poprawianie kawałka kodu tak, aby był jeszcze lepszy, skoro spełnia on swoje założenia i wcale zły nie jest.

Whatever

świętymi bądźmy... ale trzeba znać umiar

Ostatnimi czasy zdarzało mi się trafiać w review kodu na zażarte dyskusje na temat pewnego jego fragmentu. Czasami rozmowy tam prowadzone zmieniały się w dialogi nie za pośrednictwem komentarzy i klawiatur, a werbalne.
Gdy się wsłuchiwałem (bądź wczytywałem) w nie, ciężko było trzymać stronę któregokolwiek z dyskutantów, a to dlatego, że moim zdaniem każdy z nich miał rację, a rozmowa sprowadzała się do kwestii estetycznych i osobistych preferencji aniżeli do "obrony jakości kodu" przed "nieodpowiednimi" linijkami.

No i tak sobie te dyskusje trwały do momentu, gdy w końcu obaj rozmówcy decydowali się na skorzystanie z "telefonu do przyjaciela", co sprowadzało się do skierowania spojrzeń w kierunku najbliższego programisty i zadania mu jakże istotnego pytania - "A Ty co o tym sądzisz?".

Zdarzało się tak, że owym programistą byłem ja. I cóż mogłem odpowiedzieć?

wtorek, 24 września 2013

O tworzeniu obiektów w JavaScriptcie słów kilka...

Ciekawa prezentacja zrobiona przez moich kolegów z zespołu (Piotrka Repetowskiego i Mirka Filipa) dotycząca tworzenia obiektów w JavaScripcie i problemów, które można po drodze napotkać.

Cóż mogę napisać? Polecam i czekam na więcej (a wiem z dobrych źródeł, że owo "więcej" jest jedynie kwestią czasu:).
Co prawda jest ona w języku angielskim, ale z dużą ilością kodu, więc każdy, kto zna JS'a powinien wszystko bez większych problemów zrozumieć:)

Prezentacje znajdziecie pod tym linkiem.

Jeżeli coś jest niejasne to piszcie w komentarzach, a ja postaram się ich namówić na udzielenie odpowiedzi :)

piątek, 20 września 2013

Enumy w PHPie? Oczywiście, że się da!

Ostatnio, przeglądając jedno z reviewew mój kolega z zespołu rozpoczął rozmowę na temat naszych pseudo-enumów w aplikacji.
Nie odkryliśmy tutaj koła na nowo i nasze "klasy enumeracyjne" wyglądały tak, jak w większości frameworków, bibliotek i aplikacji, które widziałem, a które zostały napisane w PHP:
interface PseudoEnum
{

    const SUCCESS = 1;
    const FAILURE = 2;
}

Dobre rozwiązanie? No cóż, osobiście od dawna bolałem nad tym, że takie konstrukcje nie pozwalają nam na jedną z jakże istotnych funkcjonalności, które w przypadku zwykłych obiektów PHP posiada, a które są bezproblemowe w językach, gdzie coś takiego jak enum istnieje. O czym mowa? Chodzi o typowanie.

Pomimo cudownych i deskryptywnych nazw, te stałe, jakby na to nie patrzyć, w gruncie rzeczy są int'ami i w chwili, gdy któraś metoda mogła przyjąć wartość tylko i wyłącznie taką, jaka została zadeklarowana wcześniej w naszym pseudo-enumie, to musieliśmy tworzyć do tego celu specjalne metody sprawdzające.
Nie mogę powiedzieć, że było to zadowalające rozwiązanie, ale jakoś z tym żyliśmy.

poniedziałek, 5 sierpnia 2013

... a test, żeby testował jedną rzecz...

to zależy

Ostatnio mieliśmy w pracy prezentacją dotyczącą test double (swoją drogą polecam zainteresować się tematem i zacząć stosować wszelkiego rodzaju mocki itp., programista nawet nie zdaje sobie sprawy, jak wpływają one na jakość tworzonego kodu i czytelność testów).
Ale ja nie o tym (przynajmniej nie dzisiaj :).
Po prezentacji (i w jej trakcie) poruszyliśmy kilka tematów dotyczących testowania w ogóle i jednym z owych tematów było pytanie: czy jeden test powinien składać się z jedej asercji?
Jak to zazwyczaj bywa z takimi ideologicznymi pytaniami ludzie się podzielili na dwie grupy i zaczęliśmy dyskutować i wymieniać się poglądami. Nie muszę dodawać, że konkluzją było stwierdzenie "to zależy" :)

Tylko czy rzeczywiście "zależy"? A jeżeli tak, to od czego?

piątek, 2 sierpnia 2013

Ten kod mi się nie podoba...

somehow I don't like it

Rok, może dwa lata temu mieliśmy w firmie dyskusję na temat tego, co można zakwalifikować jako defect, a co nie powinno za takowy zostać uznane.
Nie mieliśmy na celu twardej definicji, ponieważ każdy z nas zdawał sobie sprawę, że granica jest dość cienka i subiektywna i najlepiej większą część "klarowania definicji" przerzucić na powolny proces jej naturalnego stabilizowania się w obrębie konkretnego zespołu.

Skupiliśmy się przede wszystkim na tym, co nie powinno zostać nazwane błędem. Pomysł na zrobienie takiego spotkania był wynikiem wielokrotnego pojawiania się "defectów", które nie informowały o niczym, nie dawały żadnych wskazówek i niekiedy nawet, po ich przeczytaniu nie było wiadomo co należy poprawić i co tak bardzo zirytowało osobę przeglądającą kod, że zdecydowała się na ten drastyczny krok.

środa, 24 lipca 2013

Więcej nie znaczy wolniej

to już jest koniec

I dotarłem (i Wy również:) do końca tej serii wpisów.

Wielokrotnie, gdy czytałem któryś z nich, zaraz przed jego publikacją, dochodziłem do wniosku, że jeszcze przecież tyle rzeczy wypadałoby napisać, dodać i już prawie miałem to zrobić, ale... patrzyłem na jego długość i stwierdzałem, że jednak byłaby to przesada. Poza tym, nie gruntowne omówienie zagadnienia było moim zamierzeniem, a uzmysłowienie, w jak najbardziej skompresowanej formie, zalet opisywanych aktywności/procesów/technik oraz tego, że we wszystkim trzeba znać umiar. Czy mi się to udało? To pozostawiam już do Waszej oceny.

Zdaję sobie sprawę, że na każdy z poruszonych przeze mnie tematów możnaby (i już nieraz to robiono) napisać obszerne tomy i wiem również, że wiele rzeczy pozostało jeszcze do omówienia, więc jeżeli macie jakieś pytania albo chcielibyście więcej, to czekam na komentarze lub wiadomości na fan page'ach (na Google+ lub Facebooku).

Jeżeli chcecie niektóre (wszystkie?) z opisanych procesów zaimplementować u siebie w projekcie/pracy, ale nadal macie wątpliwości lub problemy z rozpoczęciem, to również czekam na Wasze pytania, może wspólnie uda nam się rozwiązać problem :)

czwartek, 18 lipca 2013

Więcej nie znaczy wolniej cz. 8 - dokumentacja

Na wstępie cytat o tym, że dokumentacja jest jak seks

dokumentacja jest jak...

Dzisiaj zacznijmy od cytatu:
Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. - Dick Brandon
Osobiście uważam, że nic tak nie oddaje istoty tego, czym właściwie jest dokumentacja.

wtorek, 9 lipca 2013

Więcej nie znaczy wolniej cz.7 - refaktoryzacja

ach refaktoryzacjo, a na cóż Ty mi?

Dzisiaj przyszła pora na jedną z przyjemniejszych aktywności opisywanych w ramach tej serii. Żeby jednak jakiś temat poruszyć, trzeba najpierw wiedzieć o czym będzie mowa, tak więc zacznijmy od początku, a na początku był kod (i jeszcze kilka innych produktów było wcześniej, ale na dzisiaj możemy założyć, że od kodu zaczynamy :).

Każdy z nas ma pewnie w sobie coś takiego, że chciałby aby jego kod był doskonały, pewnie większość z Was zaliczyła jakiś własny projekt, w którym setki razy dopieszczaliście isniejącą funkcjonalność, bo mimochodem wpadliście na pomysł, co tu zrobić, żeby działa/wyglądała lepiej, była czytelniejsza bądź przyjemniejsza dla oka. I tak w nieskończoność, aż pewnego dnia dochodzimy do wniosku, że już szkoda naszego czasu na pracę nad nim i trafia on gdzieś na dno szafy.

Pewnie równie wielu z Was zdaje sobie sprawę, że w projektach, które muszą ujrzeć światło dzienne i wyjść do użytkowników, takie zabiegi nie są możliwe i w pewnym momencie (zazwyczaj dość szybko) musimy powiedzieć stop i iść dalej.
Jednym zdaniem - projekty dzielimy na te idealne i te zrealizowane (niestety nie pamiętam autora cytatu) i osobiście zgadzam się z nim w zupełności i pomimo mojej lubości dobrych praktych, czytelnego kodu, itp., itd., kiedyś trzeba powiedzieć stop i ruszyć do przodu.

środa, 19 czerwca 2013

Więcej nie znaczy wolniej cz.6 - code review

Ech... i jeszcze to review kodu

Pora na kolejną "problematyczną" praktykę, a mianowicie na code review. Sama idea jest prosta do zrozumienia i polega ona na tym, że kod (jego forma, wygląd i sposób rozwiązania problemu) musi zostać zaakceptowany przez kogoś poza jego twórcą.
Tak naprawdę nie jest istotne czy używasz do tego celu specjalnie dedykowanych narzędzi, czy rozsyłacie patche ze zmianami, czy stosujesz do tego celu jeszcze inną technikę, ważne jest, aby na każdą linijkę, która chce "dostać się" na produkcję, popatrzył ktoś poza jej autorem. Dzięki temu nieustannie dbamy i poprawiamy jakość kodu, eliminujemy bugi implementacyjne, dodajemy, nie wzięte pod uwagę przez autora, test case'y itp.

Dobra, to skoro podstawowe informacje mamy za sobą, to pora przejść do jakichś konkretów :)

poniedziałek, 3 czerwca 2013

YAGNI + Test First

czy warto pisać testy przed implementacją?

Testowanie samo w sobie przynosi korzyści, zazwyczaj w dłuższej (oby:) perspektywie czasu, ale prędzej czy później jesteśmy w stanie dostrzec ich wartość i nieraz oddychamy z ulgą, gdy widzimy, że ludzie pracujący nad kodem przed nami, poświęcili trochę czasu na napisanie solidnych zestawów. Lecz o zaletach posiadania testów już pisałem ostatnio (tutaj i ciąg dalszy :).

I o ile z tym, że posiadanie testów przynosi korzyści i jest to jedna z tych rzeczy, którą wielu programistów chce praktykować nie kłóci się nikt, o tyle nie wszyscy widzą jakikolwiek sens w pisaniu testów przed implementacją. Że niby sprawia, że kod jest lepszy, że jeszcze raz myślimy o problemie, że patrzymy na niego od innej strony, itp., itd.
Problem z tymi wszystkimi stwierdzeniami jest taki, że to są jedynie oklepane zwroty, którymi karmią nas bardziej doświadczeni, mądrzejsi znawcy tematu, którzy powołują się na własne doświadczenie i którym powinniśmy zaufać. I ja wcale nie twierdzę, że nie mają racji, czy też nie neguję ich kompetencji, ale człowiek (a programista też człowiek :) woli uczyć się na własnych błędach. Przynajmniej do momentu, gdy nie zobaczy konkretnego przykładu, który pokazuje mu, że jednak jest tak, jak podpowiada starszy kolega.

wtorek, 21 maja 2013

Więcej nie znaczy wolniej cz.5 - testowanie po raz drugi

i jeszcze jeden i jeszcze raz...

Komentarze (krytyka :) pod wczorajszym wpisem zmotywowały mnie do powałkowania tematu testowania jeszcze przez moment.

Na wstępie jednak pragnę zaznaczyć, że i tym razem nie będzie ani jednej linijki kodu. Ta decyzja wynika bezpośrednio z tego, o czym wczoraj pisałem w komentarzu pod wpisem, a mianowicie z samego założenia dotyczącego serii - nie ma to być opis technik/procesów, czy też opis samej ich idei, chodzi mi raczej o przedstawienie argumentów, które mogą pomóc Wam (oczywiście jeżeli będziecie mieli na to ochotę) przekonać managera czy też właściciela produktu do zastosowania opisywanych aktywności w projekcie.

Muszę pokornie pochylić głowę i przyznać, że rzeczywiście we wczorajszym poście zabrakło przykładów z życia wziętych. Był zbiór uwag (swoją drogą całkiem słusznych :), które jednak poza opisem nie zawierał żadnych odniesień do rzeczywistości, w której przyszło nam się zmagać z klientami, managerami, czy też innymi opornymi przedstawicielami idei minimalizmu w odniesieniu do ilości procesów w trakcie tworzenia oprogramowania.

niedziela, 19 maja 2013

Więcej nie znaczy wolniej cz.4 - testowanie

no to co? może teścik?

A może jeszcze jeden? I kolejny? I jeszcze dziesięć następnych? I co?

No właśnie, i co? Obrońcy rzeczywistości, w której testów nie spotkasz nawet tam, gdzie mógłbyś (a wręcz chciałbyś) się ich spodziewać, nieustannie twierdzą, że z tą aktywnością nierozerwalnie wiążą się dwa podstawowe problemy:
  • Ilość kodu, który testujemy niekiedy jest dużo większy niż ilość kodu testowanego (czyt. a można by przecież napisać tyle więcej nowej funkcjonalności)
  • Testowanie nie daje gwarancji tego, że w produkcie nie ma bugów (czyt. jesteśmy tak pewni swojej aplikacji po je przetestowaniu, jak przed)

Oczywiście są to prawdy objawione, z którymi się nie da dyskutować.

Hmm... ale zawsze można spróbować :)

sobota, 11 maja 2013

Czy to już czas?

Jakiś czas temu, po długim ślęczeniu nad bugiem zgłoszonym przez klienta, gdy udało mi się w końcu odkryć źródło problemu i otworzyłem plik z klasą, której metoda była odpowiedzialna za całe wyrządzone zło, popatrzyłem na kod i przed oczami stanął mi obraz dżungli, pełnej pnączy, drzew, zwierząt, insektów i wszystkiego, co tam jeszcze w takich dżunglach się znajduje. Niby dżungla jedna, ale jak wejść do środka, szczególnie bez przygotowania i dość obszernej wiedzy, co w niej można znaleźć, to aż przebiega zimny dreszcz po plecach.

poniedziałek, 29 kwietnia 2013

Czy to już paranoja?

a zaczęło się to tak...

Wydajność mojego zespołu zwiększyła się w ostatnich miesiącach kilkukrotnie. Oczywiście jest to powód do zadowolenia, ale generuje to również wiele code review, które wcześniej czy później trzeba przejrzeć. Co prawda, nie wszyscy muszą oglądać wszystko, ale tak czy inaczej, ich ilość ostatnimi czasy jest przytłaczająca. Zazwyczaj rano przy kawie przeglądam ich listę i po kolei, jeden po drugim, zamykam bądź oglądam, w zależności od tego, ile osób przede mną już miało przyjemność patrzyć na ten kod. Tak też zrobiłem ostatnio. Gorąca, czarna, parzona i aromatyczna kawa powoli cuciła mnie i przywracał do świata żywych, a ja w między czasie przedzierałem się przez kolejne linijki kodu.

W pewnym momencie trafiłem na bardziej złożone zadanie i po ilości klas byłem w stanie stwierdzić, że zrozumienie wszystkiego będzie wymagało ode mnie trzeźwości umysłu i skupienia, o jakie ciężko we wczesnych godzinach porannych. Ale któż powiedział, że życie lekkie jest:) Łyk, już tylko ciepłego, napoju i do dzieła.

niedziela, 14 kwietnia 2013

Test ma testować, nie powielać kod metody.

czy aby oczywiste jest to wszystko?

Niby jasne, że właśnie tak to powinno wyglądać, ale naprawdę często (dobra, dla ścisłości - częściej niżbym chciał:) zdarza mi się oglądać testy, w których ciele mam dokładną kopię kodu, który znajduje się wewnątrz metody testowanej.
Zdaję sobie sprawę, że w przypadku niektórych rzeczy dużo wygodniej jest wykonać kilka instrukcji niż zastanowić się jaki może być wynik. Najczęściej, takie mam przeświadczenie, programiści decydują się na kopiowanie kodu z metody po to, aby się przypadkiem nie pomylić i żeby oczekiwany wynik był na pewno dobry.

I w tym miejscu pragnę wrzucić delikatne, ale jakże wymowne - WTF?!

środa, 10 kwietnia 2013

Diagramy statyczne nie są drogą do celu

Ostatnio miałem okazję przyglądać się kilku osobom, które nie mają zbyt wielkiego doświadczenia w tworzenia projektów. Posiadają wiedzę na temat programowania obiektowego, znają paradygmaty, wzorce, ogólnie całkiem nieźli z nich programiści, jednak swoją przygodę z tworzeniem designów dopiero zaczynają.
Jedną z obserwacji, która rzuciła mi się w oczy jest sposób w jaki większość z nich rozpoczyna tworzenie projektu. Mianowicie - zaczynają od tworzenia diagramów klas.

sobota, 6 kwietnia 2013

SOLIDny kod cz. 3 - Open/closed principle

łatwo powiedzieć

W najprostszej i najkrótszej postaci definicja drugiej zasady SOLID, to: elementy systemu powinny być otwarte na rozszerzenia, ale zamknięte na zmiany. Proste, jasne i przejrzyste, czyż nie? No dobra, może nie takie jasne i przejrzyste, ale przynajmniej proste. Łatwo zapamiętać:)

Może przesadzam z tym, że nie jest ona (definicja) równie przejrzysta jak prosta, bo w większości przypadków programista jest w stanie wytłumaczyć o co chodzi - "O to, żeby łatwo było rozszerzać bez mieszania w kodzie". Problemy zaczynają się wtedy, gdy docieramy do projektowanie czy też tworzenia kodu, bo to, co prosto powiedzieć, już wcale takie banalne w realizacji nie jest.

Jak umożliwić rozwój, który nie wymaga zmian?

niedziela, 24 marca 2013

You Aren't Gonna Need It

programista = wróżbita

Z moich obserwacji wynika, że większość programistów ma podświadomy pociąg do arkanów sztuk tajemnych, w szczególność do wróżbiarstwa. I o ile nie widzę nic złego w oderwaniu się od codziennej rutyny, to problem zaczyna się wtedy gdy owe zainteresowania zaczynają praktykować również podczas tworzenia kodu. I jeszcze śmiem twierdzić, że to również nie jest takie tragiczne, ale... no właśnie... ale najczęściej to przepowiadanie przyszłości programistom najzwyczajniej nie wychodzi zbyt dobrze.

Żeby nie powiedzieć - wcale.

niedziela, 10 marca 2013

Więcej nie znaczy wolniej cz.3 - projektowanie

zaprojektujmy coś...

Kiedy przeprowadziliśmy już analizę i wiemy, co klient chce abyśmy zrealizowali, wiemy, czego nie chce i obie strony rozumieją co i jak ma działać, możemy ruszać dalej, czyli przełożyć wymagania na coś, co lepiej pasuje do naszego obiektowego świata:)
Jednym zdaniem - pora na zaprojektowanie naszej aplikacji.

niedziela, 27 stycznia 2013

Więcej nie znaczy wolniej cz.2 - analiza

kiedy jest tylko pomysł...

Czym jest analiza? Analiza to rozkład na składniki/czynniki (wikipedia). Trochę lakonicznie, nieprawdaż? Próbą zdefiniowania terminu w interesującym nas kontekście zajmę się w kolejnym akapicie. Teraz skupmy się na tym kiedy jest czas na analizę?

Jest to aktywność, która powinna być przeprowadzona na samym początku, to wyniki analizy dają nam podstawy do stworzenia dobrego projektu.

niedziela, 20 stycznia 2013

Więcej nie znaczy wolniej cz.1

o tym, co sprawia, że jesteśmy lepsi

Ostatnio robiłem podsumowanie roku kierowania projektem (pisałem o tym tutaj) i statystyki, które ujrzały moje oczy, były dużo lepsze niż się spodziewałem:)
Nie jestem jednak osobą, która długo cieszy się sukcesami. Większą radość odnajduję w kolejnych wyzwaniach, więc następnego dnia, po przedstawieniu zespołowi efektów naszej wspólnej pracy, zacząłem się zastanawiać, co dalej? Wychodzę z założenia, że pozostanie w tym samym miejscu jest równoznaczne z cofaniem się do tyłu, tak więc jedynie kolejne ulepszenia wchodzą w grę:)

środa, 9 stycznia 2013

SOLIDny kod cz. 2 - Single responsibility principle

w czym rzecz

Jak już ostatnio pisałem, Single responsibility principle (SRP), czyli zasada jednej odpowiedzialności, mówi o tym, że klasa nie powinna mieć więcej niż jednego powodu do modyfikacji.
Często spotykam się z tym, że programiści twierdzą, że takie myślenie prowadzi jedynie do niepotrzebnego rozbijania każdej klasy na kilka bądź więcej elementów składowych. Co za tym idzie? Potrzeby zarządzania wieloma klasami. A to wszystko tylko po to, żeby zrobić coś naprawdę prostego.

Cóż, można na to spojrzeć w ten sposób. Jednak jest kilka ale...