Created
April 10, 2013 22:12
-
-
Save psyho/5358917 to your computer and use it in GitHub Desktop.
Notatki z SCKRK #40 - Lean Coffee
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| 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 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Autorem notatek jest @jkramarz. Wielkie dzięki!