Video

really nicely put: from SSE to websocket integration with Fluxes. Old but gold

Asciidoc ist toll, aber Markdown immernoch verbreiteter. Gerade bei VENOM müssen wir einbeziehen, woher wir kommen. Oft aus einer Legacy-Welt, in der wir froh sein können, wenn wir überhaupt etwas an Doku in Code haben, oft eher eine Welt großer Word-Dokumente in Version 98.

Very well explained by Valentina.. Thank you very much

Ich neige zunehmend zu umfassenden, aber soften Vorgaben: Es wird eine Referenz vorgegeben, etwa xy soll eingesetzt werden und mit diesen Parametern. Teams sollen aber die Freiheit behalten, Abweichungen davon zu beschliessen (allenfalls challenged von denjenigen, die die Referenz definiert haben) und diese entsprechend zu dokumentieren. Eine zu hohe Fragmentierung erschwert den Austausch von Teammitgliedern oder die teamübergreifende gegenseitige Unterstützung, wenn ein Team irgendwo technisch ansteht.

Eberhards Stärke liegt zweifelsohne in seiner eloquenten Ausdrucksweise, doch bedauerlicherweise bleibt der Gehalt seiner Präsentation eher dünn. Es ist schade, denn meine Erwartungen lagen höher.

Its a gem of a presentation.

Promo`SM

schlechte Ton Qualität schade

Hi Valentina, thanks a lot for the great talk. This one and Ian Cooper presentation on DevTernity opened my eyes: it turned out I practice almost the same approaches. But almost :) What I realized is that integration (or component) tests are much more useful then tests on the class level and I should concentrate on them. But unfortunately still writing by inertia those class level tests with a bunch of mocks and stucking fixing them during refactoring (that I do a lot working with foreign code). So, what my int. tests looks like: input - REST call with json, output - verify response, verify some db records, verify some external rest call (that are stubs), etc. I try to keep infrastructure for tests close to production system. Using TestContainers it is not so hard. I practice hexagonal architecture as well. As far as I understand you consider unit-tests rather as tests on domain level. However imo it means your tests knows your code architecture i.e. implementation details. Isn't it? What do you think if consider unit as a use case and create only integration tests on application level and do not create tests on lower levels at all? I'm talking here only about business applications without high algorithmic complexity.

Danke

Slides: www.jug.ch/html/events/2021/java_17.html

Years ago I got interested in testing UI and trying to decouple the GUI logic from the actual UI - it was called Presenter-first and (just conceptually) it is like working driven by use cases (just specific to the GUI) but the separation of concerns is still the basic principle. en.m.wikipedia.org/wiki/Presenter_first_(software_approach)

NEWS UPDATE: Thanks to everyone for your feedback after this initial meetup. The next meetup in this series was hosted by Software Craftsmanship Luxembourg, video here czcams.com/video/IZWLnn2fNko/video.html where we went more into implementation details, as was requested by several viewers - we showcase the examples in Java & .NET. Furthermore, if anyone else has any questions or suggestions regarding the code samples or questions you'd find useful for future meetups, you can post in discussions here github.com/valentinacupac/community/discussions

Impressive presentation. Thanks a lot Victor.

Amazing tool!!!! Thank you for sharing this great overview of JBang!

Excellent talk @Valentina Cupac. Thanks for the insights

Skip to 50:00 to see the extension :) 12:15 What is Conway's Law 15:00 Inverse Conway's Law manouvre - via Eberhard Wolff 17:00 What is Architecture 30:00 Laws of Architecture - via Neal Ford 36:50 Work <- 3. aspect of Team Collaboration 38:50 Deployed VS Released czcams.com/video/RBQz9QhFfdc/video.html 43:00 How does Work come to teams - via John Cutler 50:00 Extended Conway's Law

5:38 start

@d_stepanovic - thanks a lot! Great work to support pair and mob programming practices to speed up product development time. Awesome! There is one caveat though I try to bend my head around: There's not only writing code - there is analysis work, understanding the business background, developing domain models, planning release and Sprints, onboarding of new team members, running retrospectives, doing line management activities, attending top down company communications, etc. How to weave this into the overall picture? Don't get me wrong, I'm a big fan of lean, flow, WIP limitation, etc. - that all makes total sense. I just need solid content to explain to my product managers that humans are bad at multi-threading and that it's bad for the overall productivity.

This is interesting subjects, but I'm sorry I still can't imagine how to implemented this. From what I know until now, test driven by behavior is usually used only in instrumented test, not unit test. By testing unit test driven by behavior, won't it be covering any component used aside what users can see? For example, CMIIW, let's just say user want to login in to an application. The test should be like "When the user login with the correct credential, he can move into his account". In the implementation, the test would be testing the login usecase with a correct credential parameter and make sure that he move into his account. Is that the only test needed? Because when I think it's as structural, I would also test the whether repository or datasource classes used in that login is called and working, which covered more component that needed to make the behavior working properly, but as a user, they wouldn't know that behavior is required to use those components. So should the component like repository and datasource be not included in test at all? So what's the correct implementation test on this case?

Interesting and insightful conversation on PR sizes.

Thanks a lot. Loving the book!

Thank you

Thanks very informative.

How did you overcome the pretty-print style JSON API change? Did you have to transform it to single lines somehow? I'm working on an application that needs to take standard json.

This made making data pipelines seem approachable. Thank you.

35:12 I ❤ how Victor fixes slides while he goes. AWESOME! Thanks for this talk! @vrentea czcams.com/users/vrentea

00:00:00 Welcome and Intro 00:04:23 Start of the talk 00:05:30 1936 - Alan Turing 00:08:22 1939 - Breaking the Enigma code 00:09:55 1942 until 1945 - Colossus + ACE 00:14:38 1945 - Turing writes code in binary 00:17:40 1945 - Turing about programmers: "mathematicians of ability" 00:18:40 1945 - Turing about programming: importance of "appropriate discipline" 00:19:12 There are about in the order of 100 million programmers today 00:19:57 1945 - Only a few computers and programmers in the world -> O(1) 00:21:10 1950s - Core memory was invented 00:23:37 1950s - Vacuum tubes mass production 00:24:20 1953 - Programming languages were invented like Fortran, Cobol, ... 00:27:22 1958 - LISP as first functional programming language 00:27:57 1954-1960 - IBM 70x computers and more than half of the programmers were women 00:29:22 Grace Hopper who invented the first compiler 00:30:34 1960 - Number of computers in the world: 100 - 500, number of programmers: 10x of that 00:31:35 Programmers were engineers, scientists, mathematicians 00:32:41 Transistors were invented 00:33:20 1965 - transistor based computers like the IBM 1401 were affordable for mid-sized companies 00:34:40 1965 - Number of computers in the world: tens of thousands, number of programmers: 10x of that 00:36:57 1965 - Programmers were still coming from other disciplines, were older and disciplined 00:37:36 1966 - IBM 360s every month 1000 pieces produced 00:38:50 1966 - The invention of object oriented programming (OOP) 00:40:00 1968 - GOTO statement considered harmful, invention of structured programming (Dijkstra) 00:40:36 1965 - C programming language and UNIX operating system 00:41:26 1970 - Mini computers like the DEC PDP-8 were available 00:42:23 1970 - Number of computers in the world: hundreds of thousands, number of programmers: about 1'000'000 00:43:24 Universities started to crank out computer science graduates: all young, most male 00:45:55 1980 - Most programmers were young and male 00:46:30 The graph with the declining number of women in computer science over the years 00:51:07 Waterfall as a way to manage these hords of young software developers 00:52:00 Waterfall era for 30 years: 1970 until 2000 00:54:30 1995 - Doubling of programmers every 5 years 00:55:18 Because the doubling rate is to high, our industry stays in a state of perpetual inexperience 00:56:02 The future: we are headed towards a disaster 00:58:14 We programmers are killing people and destroying sometimes companies and fortunes 00:58:40 Our society runs on software 00:59:00 Programmers rule the world 01:00:20 Politicians will legislate as an answer to catastrophes 01:01:04 The future of programming is learning the disciplines, standards, morals and ethics 01:03:08 Question: What do you think a capable programmer will look like in 10 years or more? 01:05:45 Question: What role will AI play? Will computer replace programmers? 01:08:45 Question: How you do think quantum computing will affect our industry? 01:10:00 Question: Does Bob still program for productive systems? What about the problems of TDD? 01:12:24 Question: What about the future of agile, project planning, ...? 01:15:20 Question: How many hours per day can a programmer be "productive"? 01:20:35 Question: What do you think of the current no-code movement? 01:21:55 Question: How to get the discipline and become a better programmer? 01:26:20 Question: Is open source development and massive peer review a solution regarding some of the problems? 01:26:55 Question: How to establish clean code and "convince people"? 01:28:50 Question: About the role of universities? Will they change and adapt their program? 01:31:15 Question: Must programmers also address political questions, beside of moral dilemmas? 01:31:10 Question: About the evolution of programming languages? 01:34:45 Question: Is there enough time to become a better programmer in these fast changing times? 01:36:50 Question: Do you think the companies will move software development to countries where programmers are cheaper? 01:38:12 Question: What do you think about programmers that have almost no knowledge about hardware and computer internals? 01:39:25 Question: Aren't predictions of the future usually wrong?

'clean architecture' lässt einen sofort skeptisch werden :)

Who needs an architect?

Thanks for sharing!!

Great presentation! Thank you for it!

Nice work. Definitely something worth to try.

Loved this: "We stopped shipping magic recently!"

slides available here docs.google.com/presentation/d/1IScJ47fsPrDTloM_Wbh_-0rm22_L9NYv9-2JAJ0Ahvo/edit?usp=sharing

Start from 5:00

What if you want to build a modular monolith, does Quarkus provide some benefits for that scenario aswell?

Start from 5:10 :-)

Sehr guter Talk. Sehr wertvolle insights.

Great video Sir

Greeting, Java User Group Switzerland. it's a pretty fun video. thanks. :)

Die Runner von Spring Boot werden durch die ExtendWith von JUnit Jupiter ersetzt. Seit Spring Boot ... github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.2-Release-Notes Verwendung von JUnit Jupiter ausschließlich.

Druch die schlechte Tonqualität von Herr Reelsen und seine sehr schnelle Sprechweise und am Ende des Satzes Wörter zu "vernuscheln", ist es ihm zu folgen sehr anstrengend.

Interessanter Talk, danke!

Funny that arguments of "assertEquals" are mixed in the presentation :)

Das war schnell!

Was testet ein "Unit-Test"? - Methode oder Klasse? ODER - Unit of Work? Michael Feathers hat da eine super Definition die ich besser finde als die in Minute 19:40.