Skip to content

Instantly share code, notes, and snippets.

@psyho
Created April 10, 2013 22:12
Show Gist options
  • Save psyho/5358917 to your computer and use it in GitHub Desktop.
Save psyho/5358917 to your computer and use it in GitHub Desktop.
Notatki z SCKRK #40 - Lean Coffee
Tematy:
* sckrk workshops (4)
- warsztaty z security
* open data (4)
- jak uwalniać dane z miasta
* why we fail in tdd and what we do about it (7)
* ddd-krk (7)
- nowy meetup dla ludzi z DDD
* formuła spotkań (3)
- co poza reading club i lean coffee
- może prawdziwy book club?
* BaaS (3)
- backend as a service
- doświadczenia
- czy tylko termin marketingowy?
- analityka, obsługa użytkowników, chatów
- trochę jak PaaS
* git + gerrit - how to do code review? (8)
- jak pomogło?
- czy wzrosła jakość kodu?
* pair programing patterns (8)
- czy ktoś robi pp?
- co się sprawdza?
- kiedy warto, kiedy nie warto?
- co sprawia, że z jedną osobą można, a z inną nie pairprogramować?
* code retreat in june (2)
- kto pomoże w oranizacji?
* web w scali (8)
- który z frameworków fajniejszy?
****git + gerrit - how to do code review*****
- konieczne do podniesienia jakości kodu
- doświadczenia z gerrit (php) + redmine
- na github:
* pull requests
* tagi tasków + kanbanery
- policyjne narzędzie na młodych w zespole
* nie czytanie commitów "wymiataczy"
* tworzenie przez nowych-wymiataczy kodu niespójnego, będącego od razu legacy
- czy potrzebne przy pair programming?
* krótszy cykl sprzężenia zwrotnego
- refactor na starcie kodu od hindusów
* ping-pong kodem
- cursible
* uczenie code-base'u przez code review
- "ej, ty chdoź tu" jako gwałt na czyjejś uwadze, zaburzenie naturalnego trybu pracy
- trend na coraz mniejsze zespoły, lepiej zarządzale
* proporcja między nowymi a bardziej doświadczonymi
* publiczne wyświetlanie projektorem kodu całemu zespołowi :-)
- opowiedzenie komuś po tygodniu o zmianach - antypraktyka!
- integracja cursible z jira
- smart commits, wykonywanie czynności procesowych (hooki?)
- code review per user story i ciągły refactoring
- feature branch jako antypatern
* wręcz tyle drzew kodu co osób w projekcie
* utrudniony refactor, szczególnie przy długich branchach
* refactor jako osobny branch
****pair programing patterns****
- NIE o wyższości pair-programowania
- pp jako rozpraszający
* odcięcie się od świata, skupienie na tasku
* utrudnia pomodoro!
* input od innej osoby nie potrzebny cały czas, ważny jest flow!
* wystarczający code-review
- czy pp rzeczywiście pomaga?
* hamuje over-engeneering
* pomaga w debugowaniu
* wspólna wiedza zespołu ciągle rośnie, jeżeli zmieniamy pary
* nowa perspektywa
* "płacimy 10 programistom, więc czemu mają robić robotę 5?"
- nie jesteśmy maszynistkami, nie przepisujemy kodu z kartki na kartkę
* pomodoro jako sztuczka w pair-programmingu
- trudniej w pp zrobić sobie przerwę
* wzrost produktywności :-)
* pozwala robić dzień w dzień PP, bo wymusza rytm pracy
- "8 pomodoro w 8 godzinnym dniu to dużo" :-)
* ping-pong: tdd!
- pułapka: jedna pisze, druga patrzy
- wymusza skupienie na obu osobach
* zakłada, że wszyscy pracują w tych samych godzinach, w tym samym trybie
* co, jeżeli kolega pracuje na Macu, z type matrixową klawiaturą bez naklejonych literek, w układzie Colemac?
- wybranie wspólnego środowiska - wymaga woli!
* co, jeżeli spotkają się dwaj over-engeenerowie?
- niekoniecznie będą mieć zgodne fazy - raczej będą obcinać wzajemnie chore pomysły
- może jeden być podatne na sugestie drugiej osoby
- znajomość kodu w całym zespole, dzięki rotacji osób w parach
* każda osoba przejdzie przez feature
* kazdy zna każdy zakamarek projektu
* "zjawisko w Stanach, że żyli sobie ludzie, grupą uprawiali seks, a i tak łączyli się w pary"
- czy nie będzie podobnej tendencji przy cyklach zmian par?
- "to jest moja klawiatura"
- czy czasem nie za duża armata, do zbyt małych rzeczy?
* co z prostackimi formatkami?
- "zapomniałeś o tym w tym miejscu, zapomniałeś o tym w tym miejscu..."
- programowanie pp na legacy code'u
* dobry sposób na refactor
- pair pisanie maili :-)
****web w scali****
- "nie da się" vs. "da się da się"
- Play (lekkie, state less)
* "klon Railsów"
* lean
* template engine mieszający kod Scalowy z HTML
- Lift (osadzenie w serwerze aplikacyjnym jako servlet, state full)
* twór Davida Polaka
* własny template engine
- czysty html
- bindowanie po selektorach
* taki mały projekt na T, t, t, t... Twitter
- migracja najpierw backendu, potem frontendu do Lift z Railsów
* przesiąknięty tym, co można zrobić w Scali
****why we fail in tdd and what we do about it****
- problem z legacy code
- "Thinking fast and slow" - analiza społeczności analityków giełdowych
* mimo specjalizacji, zerowe efekty
* wymyślenie rozwiązywalnych, niejako powiązanych problemów, w zastępstwie rozwiązywania trudnych problemów
- co oznacza wydajny programista?
* trudno-mierzalny wynik
- czy TDD powoduje, że piszemy lepszy kod?
- konieczność za-stub-owania miliona rzeczy => kod do kitu
* możesz przetestować => dobry kod; (transpozycja) nie możesz przetestować => nie dobry kod
- behaviour-driven development?
- nie gwarantuje, że idziemy w dobrą stronę - może lepiej czasem stworzyć break away prototype?
* tworzenie rzeczy o których nie mamy pojęcia
- "TDD to jest tylko młotek. Jeżeli masz w ręce młotek to wszystko jest gwoździem."
- TDD jest ślepym procesem, jak ewolucja
- drobny feedback z testów
- jeżeli nie wiesz, gdzie chcesz dojść, nie dojdziesz nigdzie
- outside-in TDD dba o architekturę
- doświadczenie w robieniu TDD
- jeżeli nie masz od kogo się uczyć, uczysz się od samego siebie
- czas dopóki nie dowiesz się, że jest błąd w Twoim kodzie, to wiele miesięcy
* jeżeli nie umiesz, możesz pisać testy które przeszkadzają
- testy prowadzą w stronę izolacji, uczą pisać luźno powiązany kod
* z czasem wiesz, jak wygląda luźno powiązany kod - więc po co to testować?
- problem, że ludzie nie przestają robić TDD
- dwie perspektywy - pisanie kodu i testów
- perspektywy zbliżają się do siebie z czasem - możemy dojść do pisania kodu do testów, bez pisania testów
- z czasem możliwe robienie czegoś z TDD bez TDD
- pominięcie procesu pisania testów
- nie rozwjanie umiejętności pisania testów
- przez rozbijanie problemów łatwiej jest zrozumieć i rozwiązać
- TDD a Android development
- jUnit - OK
- wyżej: niestabilne Robotium, niewydajne emulatory - jak?
Kolejne tematy:
- datomic - baza danych o wielu oryginalnych rozwiązaniach: (7)
* immutable object,
* zapisywanie faktów,
* persistent data structures,
* gwarancje spójności,
* dowolny key-value backend, np. Riak
- event store (2)
* event-sourcing
* append on store
* funkcyjne podejście do wyszukiwania danych
- concurrent file editing (6)
* algorytm uzywany do rozwiązywania konfliktów w Google Docs
- object calesthetics
* wymagający zestaw praktyk,
* dojo!
- actors based computing - jako inna niż von Neumana architektura (9) <= kolejny temat
- hyperdex - baza danych (1)
* NoSQL
* Full-text search
* nie jest open-source
- software barriers on different cpu architectures
* jak tworzyć bariery na architekturach, które ich nie zapewniają?
* istotne na ARM, RISC - dowolny reordering zapisu do pamięci, wynikający z innego modelu pamięci
* bliski sprzętu
- callbacks are imperative, promisses are functional
* andrzejowy paper o cache'u procesora
* jak wygląda obecnie pojęcie lean software
Book club:
- "Structure interpretation of computer programs" (SICP)
* dostępna za free
* podręcznik dla 1. roku
* z Lambdą na okładce :-)
- pobocznie, jedyny wolny dzień: niedziela :-)
- klub śniadaniowy: wtorki, 8:30, Lokator na Mostowej, przy Placu Nowym
* ok. godziny
* przynieść rozwiązania z 1. rozdziału
DDD-KRK
* talk "papieża ddd" dla community
* pierwsze wtorki miesiąca, z wyjątkiem 2 pierwszych miesięcy
Code Retreat:
* potrzebni sponsorzy
- wydatki per sponsor rzędu 1 tyś.
* obiad 900
* koszulki 1200
* after party 400
* kanapki 300
@psyho
Copy link
Author

psyho commented Apr 10, 2013

Autorem notatek jest @jkramarz. Wielkie dzięki!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment