tag:blogger.com,1999:blog-1759916214638009707.post8796488932024532561..comments2023-07-18T15:59:14.315+02:00Comments on Getting Things Programmed: Po 33rd Degree '13Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-1759916214638009707.post-33307932467023295602013-03-26T17:51:51.516+01:002013-03-26T17:51:51.516+01:00@1: ja wcale nie obserwuję żadnego magicznego myśl...@1: ja wcale nie obserwuję żadnego magicznego myślenia wokół DDD czy BDD. Wokół TDD owszem, jakiś czas temu bywały takie "zjawiska". A z moich obserwacji w DDD czy BDD wchodzą głównie ludzie/zespoły/organizacje wręcz krytycznie nastawione do branży jako takiej, więc ich nastawienie jest raczej typu: "może coś z tego wykorzystamy i w jakimś stopniu się przyda".<br /><br />@2: no tak, każda dobra "technika" to miecz obosieczny, więc świadczy to tylko o Twoim kunszcie i dodatkowo umiejętności jej przedstawienia (mam na myśli ostatni artykuł w programistamag)Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-1759916214638009707.post-72786391358060950662013-03-26T11:04:37.180+01:002013-03-26T11:04:37.180+01:00@Sławek
"1. cieszy mnie, że obserwuję zmianę ...@Sławek<br />"1. cieszy mnie, że obserwuję zmianę stanowiska w stosunku do ostatnich postów: z ataku na x-Driven do "wchłonięcia" i traktowania jako podbudowy do produktu"<br /><br />Cwaniak:)Nie było moją intencją krytykować DDD jako takiego, lecz "magiczne myślenie" o nim, które jak wiesz jest gęsto uprawiane; "no silver bullet" po prostu; oczekiwałbym zawsze wyraźnego podkreślania kontekstu: kiedy warto? kiedy nie? kto może? a kto zrobi sobie krzywdę? i że wbrew ambicjom nie wszyscy będą pisać core domain, lecz tylko wybrańcy:)<br /><br />"2. odnośnie ostatniego akapitu: gdzieś chyba ostatnio czytałem o możliwym błędzie w sytuacji gdy dokonujemy indukcji na podstawie ograniczonych próbek swych doświadczeń a później dokonujemy dedukcji poza te doświadczenia (brzmiało to sensownie)"<br /><br />Tu mnie masz:) Tak, to prawda, ale dyskusja na blogasku czy przy okazji artykułu rzuca mi więcej światła na słabe punkty tego co napisałem. Lepiej pomylić się na blogu niż na konferencji albo w książce. Anonymoushttps://www.blogger.com/profile/03968505875451301931noreply@blogger.comtag:blogger.com,1999:blog-1759916214638009707.post-47426472389443747292013-03-26T00:27:57.131+01:002013-03-26T00:27:57.131+01:00Dzięki za wyjaśnienie... chyba jednak na początku ...Dzięki za wyjaśnienie... chyba jednak na początku nie zadałem sobie trudu aby zrozumieć co autor (Ty) miał na myśli i z pychą podszedłem do tematu myśląc, że rzutem oka ogarnę czyjeś kilkuletnie przemyślenia, po czym zbuduję ich słomiany model aby z łatwością je obalić:PPP<br /><br />"szejm on mi"<br /><br />No ale dobrze, że miałeś szansę się wybronić. Inni autorzy jej nie mają...<br /><br />Ale na poważnie:<br />1. cieszy mnie, że obserwuję zmianę stanowiska w stosunku do ostatnich postów: z ataku na x-Driven do "wchłonięcia" i taktowania jako podbudowy do produktu<br />2. odnośnie ostatniego akapitu: gdzieś chyba ostatnio czytałem o możliwym błędzie w sytuacji gdy dokonujemy indukcji na podstawie ograniczonych próbek swych doświadczeń a później dokonujemy dedukcji poza te doświadczenia (brzmiało to sensownie)Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-1759916214638009707.post-58830285114293232842013-03-25T12:25:46.051+01:002013-03-25T12:25:46.051+01:00@Sławek
"Więc może bardziej ogólny komentarz:...@Sławek<br />"Więc może bardziej ogólny komentarz: skąd wiadomo, że coś czegoś nie zmieni, a co innego coś zmieni?"<br /><br />Oj, drugiej części zdania to ja nie powiedziałem, ani też nie napisałem. W prezentacji mówiłem o priorytetach: (1) Najpierw świadomie buduj swoje doświadczenie projektowe (2) Potem korzystaj z narzędzi, technologii i tych frameworków mentalnych. Gdy tracisz te priorytet to też robi się z tego (jak ty to ujmujesz)..."zabawa" lecz nie technologiczny lecz na wyższym poziomie. W drugiej części artykułu opisaliśmy po prostu rozwiązania jakie obserwujemy. Nie wymyśliliśmy tego.<br /><br />"Czy stoją za tym badania na większych próbkach i analizy czy jedynie "wewnętrzne przeczucia"<br /><br />Takie same jak za wszystkimi tymi rzeczami, o których piszemy. Czyli najpierw mamy sformułowanie problemów, następnie sformułowanie hipotezy, potem informowanie o tym ludzi, a gdy się uznają, że te problemy występują u nich, to dopiero zaczynają się badania. O ile kojarzę to taka była ścieżka TDD. Jeśli na inne *-Driven* istnieją "naukowe" dowody, to chętnie poznam. W tej chwili mamy projekty, w których nasze podejście po prostu działa i problemy, które rozwiązało i widzimy w tym bardzo dużą powtarzalność. Czyli jest to mniej więcej tyle ile mieli ludzie o wielkich nazwiskach, a więc własne doświadczenie i priczing. Bez "badań" mogłeś zaufać im. Zaufaj i nam :)Anonymoushttps://www.blogger.com/profile/03968505875451301931noreply@blogger.comtag:blogger.com,1999:blog-1759916214638009707.post-31191119623857174652013-03-25T10:06:18.864+01:002013-03-25T10:06:18.864+01:00Zgadza się, bo właściwie impulsem do komentarza by...Zgadza się, bo właściwie impulsem do komentarza była poranna lektura artykułu z programistamag - założyłem (sugerując się tytułem), że treść była zbieżna.<br /><br />Więc może bardziej ogólny komentarz: skąd wiadomo, że coś czegoś nie zmieni, a co innego coś zmieni?<br /><br />Czy stoją za tym badania na większych próbkach i analizy czy jedynie "wewnętrzne przeczucia" (badania metodą naukową są potrzebne po to aby zweryfikować takie zdroworozsądkowe przeczucia jak to, że Ziemia jest płaska i krąży wokół niej Słońce)?Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-1759916214638009707.post-35438085339474947552013-03-24T23:24:19.249+01:002013-03-24T23:24:19.249+01:00@Sławek
No, gdybyś był na prezentacji, to wiedzia...@Sławek<br /><br />No, gdybyś był na prezentacji, to wiedziałbyś, że piszesz nie na temat i wbrew temu co mówiłem :)Anonymoushttps://www.blogger.com/profile/03968505875451301931noreply@blogger.comtag:blogger.com,1999:blog-1759916214638009707.post-19115851224711442722013-03-24T21:52:12.966+01:002013-03-24T21:52:12.966+01:00Można się spodziewać, że za jakieś 2-3 lata ktoś n...Można się spodziewać, że za jakieś 2-3 lata ktoś napisze książkę: "Zadawanie pytań niczego nie zmieni - jak pracować z quasi-programistami po kursie NLP, którzy nie znają podstawowych technik i narzędzi inżynieryjnych oraz frameworków mentalnych":PPP<br /><br />Później pewnie ktoś zauważy, że nie każdy chce/może zadawać pytania i po pewnym czasie stopniowo znowu wrócimy do przed-agilowego rozdzielenia kompetencji: analityk biznesowy, analityk systemowy, architekt korporacyjny, architekt rozwiązań, architekt systemowy, projektant, developer, koder, tester, wdrożeniowiec. A później znowu ktoś zacznie odciążać, itd, itd, itd...<br /><br />Widzę tutaj analogię do sinusoidy ilustrującej skrajności w epokach literackich.<br /><br />A nie można by tak mniej faszystowsko, więcej naturalnego balansu i podejścia do indywidualnego człowieka oraz zastanowienia się co, kiedy i po co...<br /><br />Ale tutaj mamy znowu błędne koło, bo aby wybrać trzeba mieć z czego, czyli potrzeba doświadczenia. A jak go nie ma, to cóż czynić? Instynktownie ufamy komuś/czemuś co wzbudza zaufanie i próbujemy naśladować... z czasem zacznie wychodzić...Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-1759916214638009707.post-35727060709528144902013-03-22T09:17:26.653+01:002013-03-22T09:17:26.653+01:00Hej, dzięki
Poniżej książki, ale tak jak starałem...Hej, dzięki<br /><br />Poniżej książki, ale tak jak starałem się przedstawić: książki, książkami i warto jest znać, ale rozwijanie swojego doświadczenia jest ważniejsze:<br /><br />* Pattern-Oriented Software Architecture Vol 4 (i jako uzupełnienie Vol. 1, Vol. 2, Vol. 3), Praca zbiorowa<br />* Patterns of Enterprise Application Architecture, Martin Fowler<br />* Enterprise Integration Patterns, Gregor Hope<br /><br />A poza tym:<br />* Essential Software Architecture, Ian Gorton<br />* Server component patterns, Markus Volter<br />* Domain-Driven Design, Eric Evans<br />* Agile Software Requirements, Dean Leffingwell<br />* Scaling Lean & Agile Development, Craig Larman<br />* Beatifull Architecture, Diomidis Spinellis<br /><br />I na deser Lean Architecture CoplienaAnonymoushttps://www.blogger.com/profile/03968505875451301931noreply@blogger.comtag:blogger.com,1999:blog-1759916214638009707.post-4650616390712451052013-03-22T08:30:05.197+01:002013-03-22T08:30:05.197+01:00Bardzo dobra była Twoja prezentacja. Mam w zwiazku...Bardzo dobra była Twoja prezentacja. Mam w zwiazku z nią pytanie, bo przedstawione zostały 4 książki stanowiące tzw. kanon. Jedną z nich były wzorce Gang of Four. A trzy pozostałe ?Michał Flasińskihttps://www.blogger.com/profile/02300552005205423032noreply@blogger.com