4:55 I did not get why team cannot pull from `master` into "feature Y" if it already has "feature X" code integrated. what was the initial plan then? to finish with feature Y and merge it into master but somehow revert everything related to feature X?
@warren-cga3 ай бұрын
I think he described the problem with the team that was working on the long lived feature branch, they did not pull from master on each release in their feature branch
@tanko.reactions1763 ай бұрын
"feature toggle' - ahahaha.. sure.. no, that does not work. if you (sadly) employ the DRY principle (which is an abomination), you will have so many overloaded functions which all lead to one mega function with lots of parameters and many many feature checks and depending on what constellation of params it receives, it will behave completely differently. introducing a new pathway into that mess has been the greatest source of bugs for us. we are now trying to catch all those regression bugs through having as many tests as humanly possible. but there are so many pathways, that it is hard to think about every imaginable permutation of flags to really cover all bases. im talking about a 20 year old enterprise software. so careful with feature flags. if the code is cleanly disjoint, it will work. if there is a common shared functionality, its a mess.
@TheAkhileshDas3 ай бұрын
🤌👏👏👏👏👏
@Metaconta5 ай бұрын
En el tiempo15:58 se muestra los bordes redondos de los cuadros. En la tabla ASCII aparece solo cuadrados puros, no curvados. ¿En qué tabla aparece? Voy a dedicarme hacer programas en consolas así de bonitos.
@israelterorisprikopat5 ай бұрын
❤❤❤❤
@RyanPerrella5 ай бұрын
Knowing .net is associated with Balmer and Baal Gates via your inclusion of them on the thumb nail makes me glad that of all the domains ive registered, i’ve never registered a .net. Everything Microsoft touches is 💩
@jon-fs2js5 ай бұрын
This is an incredibly useful video, thank you!
@ashrafdar6 ай бұрын
Excellent Watch!! Love you Sir!!
@hasmich7 ай бұрын
I've just used Spectre.Console in my project to parse arguments and present the progress of a long-running async operation instead of printing "Please wait...". It was the first time I've used it and just loved how easy and well-thought the API is. Matched it with IProgress<T> interface and the experience was delightful. I wanted to learn more so ended up here. Thank you Patrik!
@zerohecks48647 ай бұрын
Flavor of the month shit
@Barakatic7 ай бұрын
People using Microsoft are idiots
@some1rational8 ай бұрын
the moment I saw tau=2.0*pi I knew this would be legit <3
@devleadse8 ай бұрын
Serious skills, love a topic about coding for oneself. ❤️👍
@JanekBogucki8 ай бұрын
Excellent watch, fact rich and engagingly presented. Thanks Richard!
@ForgottenKnight19 ай бұрын
22:30 - It should be obvious - Darkly is super easy to implement in code and super easy to use, not to mention the other stuff.
@JanekBogucki9 ай бұрын
Excellent presentation. I will be sharing this with my team.
@JanekBogucki9 ай бұрын
42:17 Love the suggestions features AND the suggestion to use this. My preference is to provide an example but also to link to the relevant documentation or good blog article This turns the review comment into targeted learning.
@JanekBogucki9 ай бұрын
21:33 Nits should be fixed by the PR author to help reduce the later occurance rate of similar nits. Of course, automate first :) Great talk, thanks for sharing. Packed with useful ideas.
@sergeixtc10 ай бұрын
Amazing talk, Blazor is amazing! Thanks for sharing.
@oph106610 ай бұрын
Does anyone know what happened to this book? was it abandoned in favour of making it a presentation?
@vincentcifello443510 ай бұрын
This is the most sensible review of. CQRS(and programming in general) available. Thank you Oskar! Looking forward to exploring your website.
@gp538111 ай бұрын
awesome, is the CLI slides code available online? so cool
@vallJune11 ай бұрын
Thanks Oskar for cool talks. Do you have those example in github what to take a look out of corner of my eyes?
@JerreMuesli Жыл бұрын
Git workflow, when using short-lived branches and rebases, isn't an issue. Trunk-based development is handy at the start of a project when you both need to e.g. extend the domain model or you both need to work on the same modules (records/classes) I don't like feature toggles as it instantly creates technical debt in both code and unit/integration tests and also it increases complexity. I don't say I hate trunk-based but saying that it is a silver bullet when using git, and git workflow is bad is just ridiculous
@szeredaiakos Жыл бұрын
Unit tests are cancer.
@amsimun Жыл бұрын
at 9:31 min cherrypicking the Bugfix into the Hotfixbranch. doesn’t this potentially cause new Bugs and introduces unreleased features from ongoing trunk dev. ?? or does cherrypick refer only to that particular bugfix without other trunk improvements ?
@jankinsics Жыл бұрын
Love this talk. So far the best I have watched here. I used to use git flow(the very first version). Caused lots of problems. One of the big problem is the long lived branches. It’s a nightmare. Finally, we ditched that. Our way is similar to trunk based development model with minor differences, it’s been working great.
@assaqwwq Жыл бұрын
another great tutorial that ends in the send method cannot be called if the connection is not active. thanks, gerald.
@christopherdunderdale7238 Жыл бұрын
I love this guys humor - thanks for the great talk!
@aayushiagarwal8063 Жыл бұрын
When we are committing in main trunk, is it necessary to create tags for every commit. When we are going for a release, shall we cut a branch out of it or just tag??
@Ddrhodes1239 күн бұрын
Tags are not necessary for every commit. For the commit slated for release (assuming “release” is to general use), tagging is useful. A release branch is not required until a bug fix is needed prior to the next release.
@cheeseburger1884 Жыл бұрын
this guy is Jimmy Bogard on steroids
@event-driven Жыл бұрын
That's one of the best compliments I could get 😅
@niebieskigonzo Жыл бұрын
Can someone explain how kzbin.info/www/bejne/nn2UgI2cnNSNfc0 is not a feature branch?
@deweywsu Жыл бұрын
Wow, what a wonderful talk.
@RixtronixLAB Жыл бұрын
Nice video shot, keep it up, thanks for sharing it with us :)
@z0nx Жыл бұрын
Nice talk. Didn't expect to see actual Func<_>s in a csharp talk, that's like the most overlooked ways to abstract out implementation details! I feel like this is what is lacking in most of the talks: simplicity.
@event-driven Жыл бұрын
Thanks @z0nx, I'm glad that you liked it. It was intention behind my talk to show that CQRS is about simplicity, and also new C# and .NET features allow us to write code simpler. Better to start with less code and add it when it's needed, instead of the other way round.
@__hannibaalbarca__ Жыл бұрын
I have my own in C++, but if I knew yours , I ll not make mein, waste too much time . NOW I GOING TO MAKE IT FOR C AND ASM.
@laughingvampire7555 Жыл бұрын
dude, use sixel to show your picture
@deverse Жыл бұрын
Dotnet agggg
@magne6049 Жыл бұрын
Are the slides available somewhere? It would help a lot, since the camera doesn’t focus in on every slide or so often.
@Olga-pc3bm Жыл бұрын
Also, feature toggles makes code unclear at all. It breaks a lot of common programming rules like don't create zombie code or zombie comments. What will happen if 3-5 developers left the company and their features are in the intermediate, non-working state? Nobody can understand what they were trying to do and what was the idea. Or the implementation way could be wrong. And all this code we have in master branch! Each reader of this branch should spend time on trying to understand fired developers' thoughts until he comes to the idea that it was a wrong implementation of smth.
@Olga-pc3bm Жыл бұрын
Please, don't share this shit (trunk based cherry picks from 10:00). It's not only doesn't work in real life as you described, it makes a nightmare which ruins all merge, deploy and development life cycles with unpredictable results with unstable master branch. Cherry picking is a took which has to be hidden as far as possible from real developer. It ruins history, it forces you to re-resolve conflicts, it can overwrite all the work. All you need here is an every day rebase of long-refactoring branch onto your master branch, or better not to do a long refactoring branches at all, while you develop features. Because it's not a refactoring. It's already a payment of the technical and architecture debts. It's not the refactoring - a thing developer must do each time he adds a new feature or fixes a bug (M. Fowler). In case of the debt payment and serious change of architecture you must stop development of the features. So, the right tools should be selected for the right issues. And trunk based + cherry picking to allow long technical debt payment is not the right combination.
@nccnm Жыл бұрын
How to create a presentation like this one?
@vbachris Жыл бұрын
i think he just made a dotnet console app and used his library. also fullscreened the terninal
@csabaczcsomps7655 Жыл бұрын
Amazing, he make console to work almost as worpad.
@quachhengtony7651 Жыл бұрын
great talk
@DeepWorksStudios Жыл бұрын
Gerald Versluis as always valuable content! Thanks !! <3
@AapVanDieKaap Жыл бұрын
I really wish I'd seen this earlier. We are still using feature branches and it's not working for us. I immediately shared this with my team and we are already in the process of adapting our processes.
@bpospanov2 ай бұрын
How it did go?
@AapVanDieKaap2 ай бұрын
@@bpospanov We basically went back to branches. The advantage of working on one branch is to force frequent integration. We do that anyway so it felt more like we lost flexibility. I think the key is for people not to isolate themselves and not have long lived branches. Working on a single branch can be a useful way to "force" this behaviour but I believe ideally the team communicates organically on a regular basis to avoid big conflicts.
@bpospanov2 ай бұрын
@@AapVanDieKaap thank yiu for sharing your experience 🙆🏻♂️
@TheEVEInspiration Жыл бұрын
Its always possible to do trunk based changes, even when using feature branched for other stuff. So that negates any argument in favor of CI, let alone CD. Really I hate these videos made by amateurs, trying to solve problems that already have working solutions. Just because they stumbled and messed up in obvious ways before using one method, does not mean another is somehow superior. I only see downsides to CI, let alone CD, not even customers want it (they hate constant change). It simply cannot work for most kinds of projects, every showcase is about an existing product undergoing insignificant changes. Not because they are broken up in small pieces, but because they really are that insignificant.