Archiwum autora: Przemysław Kruglej

Rzemiosło tworzenia oprogramowania – Element #7 – Miej szerszy punkt widzenia

Tematem Elementu z mojego dokumentu „Craftsmanship of Software Development” tydzień temu było uznanie testowania za część naszej pracy (Element #6 – Uznaj testowanie za część swojej pracy). Tym razem opowiem Ci o patrzeniu na wytwarzanie oprogramowania z większej perspektywy.

Element #7 – Miej szerszy punkt widzenia

Wyobraź sobie: programista przychodzi do pracy, siada do swoich zadań i problemów do rozwiązania. Przez cały dzień pisze kod, a potem zadowolony wraca do domu. Dla wielu programistów, z … czytaj więcej…

Rzemiosło tworzenia oprogramowania – Element #6 – Uznaj testowanie za część swojej pracy

Mój wpis sprzed tygodnia dotyczył pierwszego przetłumaczonego Elementu Wszechstronności (Element #5 – Szukaj odpowiedzi) z mojego dokumentu „Craftsmanship of Software Development”. Ten wpis dotyczy drugiego Elementu z tego zbioru.

Element #6 – Uznaj testowanie za część swojej pracy

Testowanie ma kluczowe znaczenie w naszej branży – często naszymi współpracownikami są dedykowani testerzy. Zajmują się testowaniem wtedy, gdy przekażemy im zadanie, które – naszym zdaniem – jest już gotowe.

Zdarza się jednak, że tester z naszego … czytaj więcej…

Tworzenie gry Mazer – prolog

Co mają kamienie szlachetne, wieża szachowa, plan mieszkania i sierżant do pisania gry? Co trzeba umieć i zrobić, aby stworzyć grę na telefony i komputery stacjonarne?

Na blogu mojej strony Kurs Java opublikowałem pierwszy artykuł z serii „Tworzenie gry Mazer”, w którym będę opowiadał o procesie tworzenia mojej gry Mazer na telefony i komputery stacjonarne. Zapraszam do czytania!

Tworzenie gry Mazer – prolog

Rzemiosło tworzenia oprogramowania – Element #5 – Szukaj odpowiedzi

Wpis z zeszłego tygodnia dotyczył ostatniego przetłumaczonego Elementu Jakości (Element #4 – Bądź kimś, na kim można polegać) z mojego dokumentu „Craftsmanship of Software Development”. W tym wpisie przeczytasz o pierwszym Elemencie ze zbioru Wszechstronności.

Wszechstronność u programistów rozumiem jako zdolność do szybkiego dostosowywania się oraz rozwijania różnych umiejętności aby nadążać za zmianami, a także spoglądanie na problem bądź wyzwanie z szerszej perspektywy.

Element #5 – Szukaj odpowiedzi

Często, gdy zadasz koleżance/koledze z zespołu … czytaj więcej…

Wydałem moją pierwszą grę – Mazer

Logo gry Mazer napisanej przez Przemysława Krugleja

Od dzisiaj w Google Play Store (dla urządzeń z systemem Android) oraz w platformie Steam (komputery stacjonarne) dostępna jest moja gra Mazer.

Mazer to gra logiczna, w której musisz znaleźć drogę przez labirynt, przestrzegając zasad każdego napotkanego elementu. Dzięki 150 ręcznie wykonanym łamigłówkom o różnym stopniu trudności każdy poziom przetestuje Twoją logikę do granic możliwości!

Mazer jest darmowy i nie zawiera żadnych reklam. Jeżeli chcesz zainstalować go na swoim urządzeniu z systemem Android, to znajdziesz go tutaj: Mazer w czytaj więcej…

Rzemiosło tworzenia oprogramowania – Element #4 – Bądź kimś, na kim można polegać

W tym tygodniu przedstawiam czwarty, a zarazem ostatni, przetłumaczony Element Jakości z mojego dokumentu „Craftsmanship of Software Development”. Poprzedni Element dotyczył dbania o drobne rzeczy. Dzisiaj opowiem Ci dlaczego warto być kimś, na kim można polegać.

Element #4 – Bądź kimś, na kim można polegać

Kiedy dołączasz do nowego projektu, często okazuje się, że są w nim osoby o których mówi się, że wiedzą wszystko na temat projektu i/lub są bardzo mocne technicznie. Można zapytać je … czytaj więcej…

Rzemiosło tworzenia oprogramowania – Element #3 – Dbaj o drobne rzeczy

W tym wpisie kontynuuję przedstawianie przetłumaczonych „Elementów” z mojego dokumentu „Craftsmanship of Software Development”. Tydzień temu, w Elemencie #2, tematem była jakość jako cel. Dzisiaj opowiem Ci o zwracaniu uwagi na detale i ich bezpośrednim wpływie właśnie na jakość.

Element #3 – Dbaj o drobne rzeczy

Osoba poprawia krzywo wiszący obraz na ścianie

Czasem trafiasz na zadanie (może nawet własne) i zauważasz, że można je było wykonać lepiej.

  • Może autor nie zwrócił wystarczającej uwagi na formatowanie kodu, albo kod nie przestrzega dobrych praktyk
czytaj więcej…