Jak zacząć, aby nie żałować - czyli 50 twarzy PHPPiotr Horzycki
Prezentacja na phpCE Polska 2017. Omawiam historię PHP oraz sposób, w jaki wykorzystujemy go dzisiaj. Pokazuję, w jaki sposób wybierać narzędzia i architekturę, aby nasze projekty żyły na produkcji długo i szczęśliwie.
Jak zacząć, aby nie żałować - czyli 50 twarzy PHPPiotr Horzycki
Prezentacja na phpCE Polska 2017. Omawiam historię PHP oraz sposób, w jaki wykorzystujemy go dzisiaj. Pokazuję, w jaki sposób wybierać narzędzia i architekturę, aby nasze projekty żyły na produkcji długo i szczęśliwie.
Oprogramowanie można podzielić na typu według wielu rożnych
kluczy, jednym z nich może być: czy buduje produkt który będę utrzymywał przez lata, czy piszę kod dla kogoś - i przyszłość rozwiązania to nie będzie już moje zmartwienie. Przy tak postawionym pytaniu zasadnicza różnica dotyczy jakości, nie tylko ostatecznego produktu (działa czy nie działa) ale jakości samego rozwiązania. Nie tego co zostało dostarczone ale jak zostało zrobione. Bo właśnie to 'jak' wpływa później na koszt nanoszenia poprawek, dodawania kolejnych elementów, poprawiania ewentualnych błędów. Na wykładzie chciałbym przybliżyć te zasady jak, jak programować aby później z trwoga nie wracać do fragmentów sprzed lat. Jakich trzymać się zasad aby kod był czytelny, klarowny, intencja jasna a całość była dobrze zaprojektowana
[PL] PRUG Luty 2022 - Service objecty to za mało - jak żyć z Railsami?Andrzej Krzywda
Service objecty dają nam sporo korzyści, ale nie rozwiązują problemów typowych dla dużych aplikacji Railsowych. Ta prezentacja podsumowuje pozostałe problemy oraz prezentuję docelową wizję opartą na DDD/CQRS.
Simple introduction to CakePHP framework including explenation of MVC architecture. Then list of most common errors and some good advices how to create applications using CakePHP.
Jakość oprogramowania jest rozbudowaną dziedziną wiedzy, którą każdy programista zna doskonale, ale ilu tak naprawdę stosuje skutecznie? W prelekcji przedstawię zarówno najważniejsze, zweryfikowane praktycznie sposoby podnoszenia i utrzymywania jakości oprogramowania na założonym poziomie, jak również omówię kilka pułapek, w które nadzwyczaj łatwo wpadamy.
O zagadnieniu:
Czy następuje taki moment w życiu programisty, kiedy może on stwierdzić, że jego warsztat jest już doskonały? Nie, jeżeli pracuje w technologiach internetowych. Ta dziedzina informatyki rozwija się w niesamowicie szybkim tempie, a stworzone wczoraj rozwiązania warto stosować już dziś!
Cel i korzyści spotkania:
Podczas spotkania słuchacze poznają aktualnie wykorzystywane technologie oraz kluczowe umiejętności w produkcji aplikacji internetowych, jak również metody programowania ekstremalnego i techniki zwinnego wytwarzania oprogramowania. Osobom, które dopiero zaczynają swoją przygodę z web development, zostanie przedstawiona propozycja działań, których sumienne podjęcie się gwarantuje odniesienie sukcesu zawodowego.
REvolution, czyli o bardziej obiektowym podejściu w RailsachThe Software House
Prezentacja z meetupu Uszanowanko Programowanko #3 http://www.uszanowanko.pl/rubyonrails
REvolution - czyli o bardziej obiektowym podejściu w rozwiązaniach kolejowych
Framework Ruby on Rails pozwala na szybkie i stosunkowo łatwe tworzenie aplikacji webowych w języku Ruby. Można powiedzieć, że podejście zwane “The Rails Way” w wielu przypadkach zdało swój egzamin. Szybko jednak okazało się, że to podejście nie sprawdza się w przypadku bardziej złożonych systemów. Logika biznesowa w kontrolerach, wypasione modele, logika w szablonach… ogólnie mówiąc chaos. Potrzebna była (r)ewolucja...
Autor: Tomek Jasiulek
Wbrew powszechnym opiniom, nie tak prosto jest zrobić dobre Code Review. Robione w pośpiechu, tylko po to by je "odbębnić", często stwarza więcej szkody niż pożytku. Opowiem wam dlaczego code review jest ważne i jak wykorzystać ten proces aby upewnić się, że napisany kod jest najwyższej jakości. Będę nie tylko mówił o tym kto powinien robić code reviews, i dla kogo, jakie informacje są potrzebne do przeprowadzenia skutecznego code review, ale także jak zrobić dobre code review w najkrótszym możliwym czasie.
Każdy kod ewoluuje. Duży produkt zaczyna jako małe niewinne MVP, by powoli i (oby) iteracyjnie rozrastać się do 'dorosłej' postaci. Równocześnie ze wzrostem produktu od strony 'ficzerów' rośnie jego wewętrzna komplikacja. Powstaje architektura - czasem zła, czasem dobra. Nowe API Getresponse'a jest gdzieś w trakcie tej drogi, juz po kilku iteracjach, juz nie jako MVP. Chciałbym podzielić się doświadczeniem z procesu budowania architektury naszego API, wyboru i implementacji rozwiązań architektonicznych oraz sposobu mierzenia efektywności naszych decyzji.
Oprogramowanie można podzielić na typu według wielu rożnych
kluczy, jednym z nich może być: czy buduje produkt który będę utrzymywał przez lata, czy piszę kod dla kogoś - i przyszłość rozwiązania to nie będzie już moje zmartwienie. Przy tak postawionym pytaniu zasadnicza różnica dotyczy jakości, nie tylko ostatecznego produktu (działa czy nie działa) ale jakości samego rozwiązania. Nie tego co zostało dostarczone ale jak zostało zrobione. Bo właśnie to 'jak' wpływa później na koszt nanoszenia poprawek, dodawania kolejnych elementów, poprawiania ewentualnych błędów. Na wykładzie chciałbym przybliżyć te zasady jak, jak programować aby później z trwoga nie wracać do fragmentów sprzed lat. Jakich trzymać się zasad aby kod był czytelny, klarowny, intencja jasna a całość była dobrze zaprojektowana
[PL] PRUG Luty 2022 - Service objecty to za mało - jak żyć z Railsami?Andrzej Krzywda
Service objecty dają nam sporo korzyści, ale nie rozwiązują problemów typowych dla dużych aplikacji Railsowych. Ta prezentacja podsumowuje pozostałe problemy oraz prezentuję docelową wizję opartą na DDD/CQRS.
Simple introduction to CakePHP framework including explenation of MVC architecture. Then list of most common errors and some good advices how to create applications using CakePHP.
Jakość oprogramowania jest rozbudowaną dziedziną wiedzy, którą każdy programista zna doskonale, ale ilu tak naprawdę stosuje skutecznie? W prelekcji przedstawię zarówno najważniejsze, zweryfikowane praktycznie sposoby podnoszenia i utrzymywania jakości oprogramowania na założonym poziomie, jak również omówię kilka pułapek, w które nadzwyczaj łatwo wpadamy.
O zagadnieniu:
Czy następuje taki moment w życiu programisty, kiedy może on stwierdzić, że jego warsztat jest już doskonały? Nie, jeżeli pracuje w technologiach internetowych. Ta dziedzina informatyki rozwija się w niesamowicie szybkim tempie, a stworzone wczoraj rozwiązania warto stosować już dziś!
Cel i korzyści spotkania:
Podczas spotkania słuchacze poznają aktualnie wykorzystywane technologie oraz kluczowe umiejętności w produkcji aplikacji internetowych, jak również metody programowania ekstremalnego i techniki zwinnego wytwarzania oprogramowania. Osobom, które dopiero zaczynają swoją przygodę z web development, zostanie przedstawiona propozycja działań, których sumienne podjęcie się gwarantuje odniesienie sukcesu zawodowego.
REvolution, czyli o bardziej obiektowym podejściu w RailsachThe Software House
Prezentacja z meetupu Uszanowanko Programowanko #3 http://www.uszanowanko.pl/rubyonrails
REvolution - czyli o bardziej obiektowym podejściu w rozwiązaniach kolejowych
Framework Ruby on Rails pozwala na szybkie i stosunkowo łatwe tworzenie aplikacji webowych w języku Ruby. Można powiedzieć, że podejście zwane “The Rails Way” w wielu przypadkach zdało swój egzamin. Szybko jednak okazało się, że to podejście nie sprawdza się w przypadku bardziej złożonych systemów. Logika biznesowa w kontrolerach, wypasione modele, logika w szablonach… ogólnie mówiąc chaos. Potrzebna była (r)ewolucja...
Autor: Tomek Jasiulek
Wbrew powszechnym opiniom, nie tak prosto jest zrobić dobre Code Review. Robione w pośpiechu, tylko po to by je "odbębnić", często stwarza więcej szkody niż pożytku. Opowiem wam dlaczego code review jest ważne i jak wykorzystać ten proces aby upewnić się, że napisany kod jest najwyższej jakości. Będę nie tylko mówił o tym kto powinien robić code reviews, i dla kogo, jakie informacje są potrzebne do przeprowadzenia skutecznego code review, ale także jak zrobić dobre code review w najkrótszym możliwym czasie.
Każdy kod ewoluuje. Duży produkt zaczyna jako małe niewinne MVP, by powoli i (oby) iteracyjnie rozrastać się do 'dorosłej' postaci. Równocześnie ze wzrostem produktu od strony 'ficzerów' rośnie jego wewętrzna komplikacja. Powstaje architektura - czasem zła, czasem dobra. Nowe API Getresponse'a jest gdzieś w trakcie tej drogi, juz po kilku iteracjach, juz nie jako MVP. Chciałbym podzielić się doświadczeniem z procesu budowania architektury naszego API, wyboru i implementacji rozwiązań architektonicznych oraz sposobu mierzenia efektywności naszych decyzji.
2. Kim jestem?
• programista od 8 lat
• znam Ruby/Rails od ponad
5 lat - WorkingWithRails
• ostatnio pracowałem
w porównywarce Nokaut.pl
• github: ravbaker
• twitter: @ravbaker
7. Agenda
• zasada skautów • obiekty i struktury
danych
• znaczące nazwy
• obsługa błędów
• funkcje
• testy jednostkowe
• komentarze
• klasy
• formatowanie
• systemy
10. • jeśli nazwa wymaga komenarza nie jest dobrą
nazwą: d, af_objects, the_list, a2
• unikaj dezinformacji:
controller_for_efficient_handling_of_strings vs.
controller_for_efficient_storage_of_strings
• tworzenie nazw które można wymówić: time_ymdhis
• rzeczowniki (lub wyrażenia rzeczownikowe) dla klas i
czasowniki (lub wyrażenia czasownikowe) dla metod:
AddressParser, Manager, Processor
delete_page, save, wait_until
• nie dodawać nadmiarowego kontekstu:
LSBAccountAddress
11. Funkcje
• Celem jest aby opowiadały historię systemu
• Podstawową regułą jest aby były małe -
mieściły się na jednym (małym) ekranie
• Powinny robić jedną rzecz!
• Zasada zstępująca i nie mieszanie
poziomów abstrakcji
• Nie powtarzaj się! (DRY)
12. • Nazwy opisowe i wyjaśniające co się dzieje
z argumentami: include_teardown_page()
check_password(user_name, password)
• Idealna liczba argumentów to... "zero"
• Więcej niż 3 argumenty nie powinno
być nigdy używane
• Argumenty-flagi są okropne: render(is_suite)
lepiej render_for_suite() i render_for_single_test()
• Unikaj efektów ubocznych
14. Dobre komentarze Złe komentarze
Publiczne API zamknięcia bloków i tagów
wyjaśnienie zamierzeń zakomentowany kod
ostrzeżenia przed
nadmiarowe komentarze
konsekwencjami
komentarze niepublicznych
prawdziwe listy TODO
metod
znaczniki pozycji:
# #### Action #####
15. • nie używaj komentarza kiedy możesz to
wyjaśnić kodem:
x = 10 # assigns number 10 to variable x
• komentarze nie naprawią złego kodu
• licz się z tym, że komentarze mogą zawierać
kłamstwa
• celem komentarzy jest wyjaśnić kod,
który nie wyjaśnia się sam
18. Prawo demeter
głosi, że metoda f() klasy C powinna
wywoływać tylko metody z:
•C
• obiektu utworzonego przez f()
• obiektu przekazanego jako argument do f()
• obiektu umieszczonego w zmiennej
instancyjnej klasy C
23. • testy i kod produkcyjny pisany razem!
• staraj się aby testy były czytelne
• testy są tak samo ważne jak kod
produkcyjny
• pamiętaj, mając testy łatwiej refaktorować
• jedna asercja lub koncept na test *
24. zasada F.I.R.S.T.
• Szybkie (Fast)
• Niezależne (Independent)
• Powtarzalne (Repeatable)
• Samokontrolujące się (Self-Validating)
• O czasie (Timely)
25. Klasy
• Powinny być małe!
• SRP - Zasada pojedyńczej odpowiedzialności
• Organizuj zmiany