Going good until TDD, many say it is about design not test, yet I have not come across a good/comprehensive tutorial that use it as a design tool Makes me think this is just lip service, because how can you properly design dealing only with a small portion of the system (user story), "system wide thinking" is dead and we are seeing the results We have quality matrix for IT practitioner but no equivalent value matrix for end users, very convinient if you ask me

This was very useful. Thank you!

These talks never describe the flow 99% of people use, SPA and a .NET backend. No downstream services called. What am I supposed to with access token if I only need to call my API? OpenIdConnect library only builds the claims principal based on the ID token. And the specs say "never look into the access token", so just throw it away?

Great presentation and all but... tabs for indentation, that's where I draw the line

Great. When I see talks like this, about what goes on in web development is exposed, I realise why almost all websites I have to use look like crap and behave really badly. Which is amazes me more and more as time goes by given the huge number of people working on the problem for three decades now and the ever sprouting number of web frames works and the like that grow like weeds all the time. Us users want less designers fussing about fonts and colours and more engineers working on how to make the thing actually work properly.

what if you have huge data like 100000000comments in Post object. I don't think you can init a domain object with that much... looks useless to me when dealing with large chunks of data. Thoughts?

Uhm.... what do you mean by "argue" if this clearly entails being very hostile towards each other?! We argue _all the time_ at my current job, but it is mostly always constructive. It's not about finding "flaws", but for the originator of an idea to expose his reasoning and for others to provide feedback and possibly input on this. So it sound more like you need to review how you "argue", and hearing that the mere concept of an "argument" for some is itself scary is a bit sad to hear.

very clear talk. thanks!

DUDE HOLD STILL

Container app cold start is still an issue atm.

Well done. Excited about the future.

A-M-A-Z-I-N-G

Psychology is a sudo-science. Intelligence is a self-applied, self-defined term that is not verifiable.

That’s what a polished and well rehearsed presentation looks like, kids. Bravo!

So Microsoft learned from Unixes daemons idea that was working before Steve Balmer? That you can turn a console app into "windows service" without rewriting it as "windows service".

Tremendous amount of value delivered here through this template

The URL @4:45 doesn't work. Ironically, this defect would have been caught had the presentation been better reviewed beforehand.

I agree with Tess that the heated argument in a PR is an indication of a broken development process. In our case, having an architecture/design session before the implementation solved majority of hard issues.

afaik CD is constant linear speed, slowing down angular speed when reading outer rings

So how to implement that non-blocking in c#? I did not get any answer that I can apply. Grr!

For operator precedence, i suggest we take C++'s and shuffle it. Also make everything right-associative. because we hate people.

38:31 accout.Save(); has an input: an object of type account.

Imo, it's not so much about some patricular piece of the system (i.e. Napster for Music or Opensource for Software) as it's about the system in it's entirety. Exploitation exists not because it's "allowed" for or "enabled" by previous bad decissions, but because it is necessary, so if you want it to stop you need to think not on how you can stop an instance of it, but on how you make it NOT necessary. Trying to fight every particular issue separately just won't lead anywhere, because even if you succeed, while you get busy patching one hole, 3 more appear. I mean, "changing licensing", "introducing billing to package managers" - depending on the implementation, seems like you can just go straight the other direction with all that . Giving middleman power to those platforms, however benevolent they may be now, can make them just as bad as any "app-store" in the future. That being said, you are right in that something needs to change, it's just that there's a devil or two to get flashed out before I'd be comfortable fully accepting your approach (not that my acceptance really changes anything)

Interesting, thank you!

Painful to watch even at 2x, the presenter butchered an interesting and important topic.

The more I listen to this video, the more it gets under my skin. "We don't necessarily want to get feedback". Well that's why there is such a thing as workflows enforcing code reviews. Some (actually all) developers make mistakes, and many of these mistakes have real consequences. Every time my mail address is leaked by a company that does not ensure sufficient security standards, I am upset, because I have to cope with even more spam. I am more upset when my credit card info gets leaked. As a customer, I really don't care about the feelings of a developer that didn't care about the quality of their code that leaked my credit card. I don't care for a team member that makes "my code" break in such ways. I want an additional pair of eyes look over that code and if they see something bad, I want these eyes make a report to the brain and then I want a mouth to speak up. Then I want ears to listen and hands to hack corrections into that code. What is all this being nice and politically correct stuff about, when the topic is how to write good or at least good enough code, such that people don't die when they get medical treatment or get robbed when they pay online? What kind of ethics is this?

"How can we do [reviews] better, how can we not argue [..] and still stay friends" - Simple, just don't do reviews. Everybody with access to the code can review it on their own terms. They can nicely talk about things they like and ignore bugs they see. Or they can just be nice to each other and ignore the code nobody seems to care about alltogether. To me, these reviews look like a waste of time.

If and whenever I have to accept a change to "my" code that I perceive as defective, it's no longer my code. I don't commit defects into my code, not unless I mark them with FIXIT. For me, the term "ownership" either means literally that it's mine and I have the last say how that is changed, or it means that I am dedicated to it and then I really don't want it to be made defective. What kind of respect is it, when my view is catered to because I am a member of some group and not because it's right? That only means that my view is irrelevant. If it's wrong, than being irrelevant is a good thing. If my view is right, I want it to matter, because otherwise, I get no respect, it's the team that owns the respect, not me or the intrinsic value of my views. If I want to feel good, I go out with my friends. When I'm developing software, I want to see an excellent result, that's my work ethics. In that context, I don't care for the feeling of my team mates. If it's a good team and I'm a good team member, they are friends anyway and we're producing good code, not mutally owned defects. If I ever start thinking of a mutual defect as an accomplishment, I'll stop writing software and start growing tomatoes in a green house. If you need code reviews to keep external audiences up to date, then you do something wrong in your documentation or communication. That is not and should not be the purpose of code reviews. A code review should review THE CODE. Why would you do that if not to SEE if it's ok?

does anyone have this example project somewhere on Github?

If finding defects is not a main objective but sharing patterns is, then what you end up doing is sharing defects, isn't it? I find it horrible that arguing has a negative connotation. Arguing is the process of exachanging arguments. If that becomes an unpleasant experience, the only reason I can think of for that is that the arguments do not serve the right purpose. If both parties have the same objective, exchanging arguments support that purpose and both parties should enjoy that. The fact that most often one side was right is a downside of arguing, but that can't really be helped. Then again, both sides have opportunities to learn, no matter who wins, transforming arguments into win-win activities. This goes wrongwhen both parties do not have the same objective. That creates a new objective which would be to examine respective goals and redefine them accordingly. The problem is not that there is an argument, the problem is that it's the wrong argument. The reason why reality does not align with my description is that most people are not interested in shared goals, they follow their personal agenda for personal gains. Sad as it is, drawing the conclusion "let's not argue" is probably the most stupid strategy to handle this problem, as it just accepts hostility as a natural modus operandi and not as something that has to be worked on.

The more talks and presentations i listen to, the more often i hear something along the lines of "you are doing topic X wrong, because you don't understand it well enough or have completely misunderstood it". Which is a really weird state that the world of software development is in. A field of work where being clear, precise and having a good understanding about your work is mandatory. On the other hand it's a comparatively young field of work and we don't have houndreds of years of softwaredev we can look back upon. 😅 A new junior software dev recently asked me what is expected for a dev to do in a code review and i couldn't give him an answer i was happy with (not a dev myself). This talk definitely helped me get a better understanding about what code reviews should be about. Thanks!

Shared ownership where everyone shares ownership does not work because no one can be responsible for everything.

Sure I'll wqtch the 2nd version of this

Wow, this was incredibly thought-provoking and packed full of ideas, thankyou.

We should be moving to lower entropy technologies, the tech stacks should get thinner not bulkier as we discover a correct simple way to do things.

Looks like a legacy php everything before Astro😅 and then web elements came. What is the reason of using client:load, why it can't just load?

"I apologize for utilizing the `master` branch; we have certain `daemons` in place. These seemingly trivial issues can complicate matters, but it's important to note that they won't alter the past or impact the future significantly.

at 7:22 the code is as Fowler says, a thin DB wrapper (class or script). But as you pull data belonging to different Entity classes (if you're using an ORM) and then put them into objects etc, can we say It is object oriented OR is the data simply being stuffed into objects to iterate over and do your business logic so it's merely data oriented?

😂 the more things change the more they change the same... We went from running code on the server to running on the client and I see we back running code on the server.

Incredible talk, the snippets prepared beforehand makes it flow very smoothly. The WASI part is what I'm hyped for. A polyglot jupyter notebook comes to mind

damn, all of that to render a couple of div tags sheeeeeit

Great talk, All claims are substantiated by evidence, which is rare in all the internet talk about ML bots called "AI". This talk is science, not opinion. I learned a lot.

Go go team witters

Some demonstration which are worth watching.

bro still uses ICQ!?!? wow - cool

Nice sneak peek into the software I use everyday

Very good talk!

I just love listening to Mads while learning more about the language!

Great comparison - I am torn beteween proto.actor and Orleans.... either way I'm sure I'll be in good hands!

for anyone wondering: I am 99% certain the slide at 49:47 is FizzBuzz in Regex (or a fizzbuzz validator probably)