Some time ago I’ve attended a .net developer days 2017 conference. I was quite busy since (traveling, teaching .net, working) that only now I got some time to share some thoughts about it. As a bonus I’m including a short interview I did during the event. I need to state here, just to be clear, I got a free ticket for the conference from the organizers but I’ve paid for workshop by myself.

If you haven’t read my last year review you might want to check that as I will be referring one or twice to that. So for a start – the biggest issue from last edition – registration queue was resolved. I don’t know what was done to solve the issue as it looked like there was not that different from the last year but there was no queue as was seen in 2016.

Even though the event was scheduled to start on Wednesday we can say that there’s some tradition that before such events the local .net UG has it’s meeting too. You can see this before DevConf, and you could see this here. Day before the conference you could attend WG.NET meeting and listen to two talks there. Konrad Kokosa & Sasha Goldshtein had their talks about similar topics – ETW, performance & debugging. Both were really, really good.

And now a bit of a review of workshop & sessions:

Pre-Con Workshop – Production performance and troubleshooting of .net application

This workshop was the best option for me as the topic of performance and troubleshooting is dear to my heart. Maybe I wasn’t expecting so many people to be attending as there was like 40-50 present. Anyway it was well spend day by doing some troubleshooting examples and learning what can be done if those happen in the production environment.

Day 1

Surviving Microservices

I don’t know if I have different expectations from a keynote talk or this was wrongly marked as such but it was not a keynote. It was just a standard talk about microservices with a lot of references to Games of Thrones that I did not get (some where ok ;)). Talk was quite good even for someone who did not have any experience with them.

5 unit testing facts I wish I know 10 years ago

Judging by the title I was expecting something revolutionary but got nothing of that kind. If one is doing unit tests for some long the facts are a common knowledge:

• you need the whole team onboard
• unit is not always a class
• not all tests are unit tests
• code duplication is ok
• it’s not only about writing tests

It wasn’t a bad session but nothing new really was presented if you are doing testing already.

Async/Await and the Task Parallel Library: await headexplosion

One of the best if not the best session of the day (I can’t be sure as I skip the last one for Day1). Technical content, and good delivery. Maybe some easy part could be omitted so that there’s more room for the more advanced stuff but anyway it was a good 1h. Kudos for showing code in the examples.

I’ve skipped the sponsored session but I’ve heard very good opinions about it from people that I trues so I strongly believe thy were on worth watching too.

Debugging and Profiling .NET Core Apps on Linux

This was one of my “must-see” session of the conference. I had a bit of preview of the topic since I’ve attended Sasha’s workshop and also attended his session during workshop but even considering that there was a session full of knowledge and useful technical info. A must go to for everyone interested in the topics of debugging and profiling even if your target platform is not Linux.

Software Architecture That Every Developer Should Know

That was, as I already mentioned before, the last session for me for the Day 1. Again the title sets maybe a bit too high expectations as there was nothing that new in the talk that someone who does the coding for enough time wouldn’t know but anyway it was a ok. Maybe the pace of the talk could be a bit more energetic – that would make the talk a bit more live that it was. Especially since it was a bit late in the day a different form of presenting might be better.

That was the end of day 1. I’ve skipped the last one as well as the DevTalk panel discussion.

Day 2

Performance that pays offs

Day 2 was started by our local star – Szymon Kulec – how talked about performance and what can we achieve if we try to break the boundaries and optimize our code down to the last bits. If we trim down allocations to the bare minimum and if we optimize code that there’s nothing left to be optimize we get a code that is fast and efficient. Really nice presentation and interesting topic. Time well invested.

The Performance Investigator’s Field Guide

This was the first slot where I was thinking what session I should go to. Finally I’ve decided to go to again to Sasha’s session about Investiagtor’s Field Guide and again it was time well spent. During the talk there were methods, tools and techniques mentioned that can be useful if your job is to investigate performance issues or solve bugs that can be seen only in production.

The next slot I’ve skipped to record an interview with Sasha Goldshtein. What I did was basically sit that with him and talked about performance, debugging & .net core topics for around 20 minutes. Then the recording was transcribed and you can read the interview below.

Securing .NET applications in Azure

Base that it was a sponsored session it was really, really good. No marketing crap but technicalities and raw stuff. I know that Sebastian could go even into more low level stuff but since the session was for the general audience I think the level of difficulty was correctly set. It got some details but not so much so everyone could follow.

How I Built An Open-Source Debugger

Third session by Sasha Goldshtein – I really must like what he does. third time and third really good session on the topics I like and like to listen about. This time you can get some knowledge about ClrMD – a library that can be used to write your own debugger.

As for the closing keynote I stayed there only for about half but wasn’t enjoying really that part.

And now as for the interview:

Paweł Łukasik: Let me start by saying that I’ve been following you on this event in Warsaw. In order to attend it, I came from Wrocław, which is about 500 kilometers away. I was on the Warsaw .NET Group first on your session, then I went to the workshop, and then to your session yesterday. Probably I will be on your two sessions today. I really like what you are doing and the topics you are dealing with. Watching your presentations, I noticed that you sometimes discuss low level stuff like CPUs and memory. I don’t know if you’re familiar with the term Mechanical Sympathy. This is a concept coined by a Formula One champion a long time ago. Basically, the idea is that to be good at racing, you should know your car in great detail, know how it behaves. By analogy, one could say that to be a good developer, you should know your hardware, know how it works. So I would like to ask you what do you think about it? Is it necessary for good developers to know the hardware?

Sasha Goldshtein: Well, I generally think that you need… I’m not sure if the hardware. But in any case whatever you’re working on, you should probably know one or two levels pretty well below the level you’re on. So if you are an engineer who specializes in algorithm optimization on CPU, like really tight CPU-bound code, then the level below you is sometimes just the CPU. So you do need that. If you’re building  database transaction systems that move data from one place to another, a typical web service or that kind of thing, then it’s probably four levels below or five levels below. So you don’t have to go there. But then it probably would help a lot if you understand how networking works, how HTTP works, and you know what kind of delays can occur, so it depends on…

PŁ: …on what you do.

SG: … on what kind of developer you are. So the hardware stuff… I don’t expect everyone to be interested in that and to actually explore that. But if you look at what Intel is saying and if you look at the Intel optimization manuals, they are designed for people doing exactly CPU-sensitive workloads. And like all of their guidance is based on… yes, you have to understand the CPU, their terminology, their optimization techniques. It’s all about understanding.

PŁ: OK. So basically, if you are doing for example a CRUD application, you don’t necessarily need to know the hardware, but in general, well, I guess it depends.

SG: Yes.

PŁ: Probably this will be a cliché and probably I know the answer from your talk, but what do you think about premature optimization? Should we do it or not? I know it’s a cliché…

SG: No, it’s fine. I mean people sometimes use this quote as an excuse, like: we’re not going to optimize because it’s premature, and it doesn’t matter, and why invest resources in it. I mean, sometimes it makes sense, but I don’t think what Knuth was trying to say is that we should write badly performing code and we shouldn’t care about performance. He was just saying that in some cases optimizing in the wrong places or spending time on optimization before you know it’s going to be an important bottleneck in your system, that’s a waste of time. But people just abuse that quote to say: why waste time improving performance? Why waste time profiling? And if you go to that extreme, it doesn’t pay off.

PŁ: So basically, you should measure first and know that you are optimizing the hot path, because it might happen that you gain like a thousand percent improvement, but if it’s called once in the application, then I guess it’s not much of an improvement, right?

SG: Yes. And then on the other hand, the case where I think the quote is used correctly is where people uglify their code for no good reason in the not important parts. So just as an example: LINQ has a name for being a bit slow. And, yeah, if you look at a really complex LINQ query, you can often optimize it by switching it to loops and not using IEnumerable so much and doing a lot of things in a different way. Sometimes it makes sense, but if you go and write all your code without LINQ in the first place for all the cases, for all the queries, you’re probably missing out on something. And you’re just uglifying.

PŁ: Usually that’s the case when you want to write performant code and what you get is not a nice code. I mean, you have to use some tricks to make it run faster…

SG:  Yes. There’s a talk that Aleksey Shipilev did in Russia. He’s working at Red Hat on the Java garbage collector and he talked about three stages in performance optimization that a project goes through. There’s the green zone where like almost everything you do is going to improve things because you haven’t profiled it yet and you haven’t looked at it yet. So again almost everything you’re doing is going to improve, if you do it methodically. And then at some point, you tuned it enough and there are no obvious bottlenecks remaining. A lot of projects get to that point, like you run the profiler, there’s a thousand different functions, each taking a tiny portion of the time, there are no obvious things to optimize anymore. This is where the yellow zone starts: where you start, like you said, tweaking your code and using tricks, like hardware-dependent stuff that works on this machine and doesn’t work on that machine. Which gets you to the red zone, which is where you’ve completely uglified everything and it’s unmaintainable now. And then tomorrow, you have to use some different hardware or slightly different architecture and everything breaks down. So there is a point where you have to stop.

PŁ: This talk that you mentioned was given at DotNext?

SG: It was at JPoint. It’s a Java conference. The JPoint keynote from 2017. I think it’s either online or it will be online.

PŁ: OK, I’ll have a look. Now, I have a bit less technical question. It looks like you know a lot. So how do you learn? I mean, what are you doing to learn all that stuff that people learn from you? As I told you, I went to the workshop, the talks here and the Warsaw User Group, and I am impressed by your knowledge. It would be nice to know how you learn stuff.

SG: Right. So it changes over the years. There was a period when I was reading a lot of blogs when blogs were a bit more popular than today. I had like 200 blogs on my RSS reader, I was using Google Reader.

PŁ: Yes, me too. I’m that old.

SG:  It’s such a pity they shut it down. Anyway, I was reading them almost every day, trying to keep up with new stuff that way. When blogs died, I mean when Google Reader died, and then people started blogging less – which was not related  but just happened around the same time –  I switched to Twitter. So I get a lot of technology from Twitter. Not the hardcore low level stuff but learning about general developments in the industry. So, for example, Java 10 is going to have this new feature or Red Hat has just released this new feature in their enterprise Linux edition or Intel are planning a new CPU with that or that. Such bites of technology news I usually just get from Twitter these days. And then, instead of reading people’s blogs, I often just follow them on Twitter and they would post interesting things. So there’s a bunch of people for whom I’ve set up notifications on Twitter. Otherwise it’s books. I still find books useful. I read pretty fast so I usually can take a 400-page book and skim through it in a day. I’m not going to remember everything and I don’t actually read every word, but I get the general idea of what it’s saying. And then specific things I would maybe try out myself, if it’s interesting enough. But then by reading a lot I get this overview of stuff. For the low level, like really going deep in some technology, you just got to invest time, sit down, try it out.

PŁ: So basically you try to do the stuff yourself and that’s how you learn. I mean, the most low level stuff.

SG: Yes, I’ll give you an example. For the last two months I’ve been researching container performance tools. So which tools can be used to investigate Linux container performance and what things work when the application is running in a container and what things don’t work. What tools would actually work or not. There’s not a lot of research on that online, there’s like one or two presentations by people who have also been working on it. So I went ahead and created some examples. I ran them and tested this tool and that tool, and then I saw why some things are working and some are not. So over a few weeks of doing it, not like every day but once in a while, you build up the knowledge. And presenting actually really helps me because it helps you organize everything.

PŁ: Yes, exactly. First you need to have the knowledge to pass it onto the listeners, right? Because knowing something for yourself is different from presenting it to others. I think you do it very well. I mean, as I told you before, you can sell, maybe it’s not a good word, but you can sell the stuff that you are saying. It’s really nice to listen to you even though it’s low level. And I guess although not everyone is really interested in this low level stuff, you can say it in a way making people really enjoy the talk.

SG: Thanks. Yes, I try. Like I said before, if I do present something, if I need to talk about something, then it also helps me organize things in my head, but it also gives you some kind of deadline. I know that if I’m not going to understand it well by then, it’s going to be embarrassing when people will ask me something and I will have no idea. That’s not a good position to be in. I mean, as a speaker, I’ve learned to say ‘I don’t know,’ but it’s a card you can play once or twice in each talk. You can’t answer all the questions with ‘I don’t know.’

PŁ:  I get it. Let’s talk about debugging. I think you also like this topic. I mean, probably every developer should know how to debug an application, but do you think that advanced debugging, I mean really specific cases, is what every developer should know? Or is it true that when you specialize in it and want to do it well, you have not much time to do anything else?

SG: I mean, it’s not always advanced because it’s using advanced tools. Sometimes it looks advanced because it was hard and took a lot of time and the problem was just not trivial and you couldn’t figure it out for a long time. That’s something all of us would experience at some point, I guess. I’m saying that a lot of people just don’t really debug outside of their development environment. Their debugging is limited to what they can do in Visual Studio…

PŁ: Yes, exactly.

SG: … and everything else they don’t treat as debugging. Like if there’s an issue in production, they would read logs or they would look in the dashboard of that system. And that works, I guess, for some people, but I think it makes you a better developer if you can also look a little deeper.Even though it’s running in production, you still can, if you want, it’s not always the right thing, but you can if you want, still use some debugging tools which would also work in production. Or you could look into the system and not just its external signals like log messages because you can’t add a log message for everything.

PŁ: Yeah, definitely. I mean, too many logs it’s also not very good information. It’s hard to go through them, if every second you have new log information that’s basically the same as all the rest.

SG: Yeah. Although we did improve a lot as an industry in log aggregation analysis, a bunch of automatic dashboards on top of your logs and that kind of things. We put it in ElasticSearch to run full text queries; we’re doing automatic log analysis, anomaly detection, that kind of thing. We’re getting better at this. I mean, most people don’t use Notepad++ to read logs anymore.

PŁ: You can, but there are better tools. OK, let’s talk about .NET Core. I saw you also had a talk about .NET Core. How do you see the future of .NET Core? Do you think it will gain some momentum?

SG: I can only share what I see. So back in Israel we haven’t had many real customer projects using .NET Core yet. We’ve been doing a lot of work with customers on proof of concept projects, trying to help them with getting started or migrating. We’ve done some training. The company I work for, SELA, we’re building the Microsoft official training for some .NET Core topics. So we’ve been around this whole thing, but we don’t see a mass migration. We don’t see all the .NET customers just one day waking up and migrating. I hope it will eventually succeed because it’s been a huge bet for Microsoft, a huge investment as well. And as a result, a lot of things in the standard .NET framework have kind of gotten a bit slower. Some areas look like they’re completely neglected and nobody’s going to touch them, like WPF for example. You know, they’re adding like really tiny tweaks but…

PŁ: … nothing major.

SG: More or less the feeling is that it’s done. Stop talking about it. Which is OK sometimes. But then… I’m saying that if it doesn’t succeed, it’s going to be really bad for Microsoft and really bad for .NET developers. So I think we all sort of want it to succeed. But there were a lot of mistakes along the way.

PŁ: The versioning of the .NET Core. They have like really strange numbering with this preview: preview 1, preview 2…
SG: Sure, they have really crazy versioning, they have changed a lot of things in a breaking way many times and I’m not sure right now there’s a really solid understanding internally at Microsoft that it was not acceptable. So if .NET Core 3.0 is to break something, I truly hope that it’s not going to be like the previous breaking changes, there’s going to be more communication and more compat along the way. And because it’s a large project and it’s a new platform from Microsoft and the whole thing is new, like managing the project in an open way, they’re stretched too thin. Some things have just not gotten enough attention. Like my talk yesterday was about diagnostics; the diagnostics story is really not there yet. Even though it’s version 2, RTM, officially supported by Microsoft. So people will hit some issues there. With .NET and Windows you sort of know it’s working, you know the platform, you know different quirks and Linux is also a lot more fragmented. There’s a lot of different distributions, people compile it in different ways. So there’s going to be a lot more interesting challenges. You can see it already if you look at the bug reports on GitHub for Core CLR. One person is saying this doesn’t work on Arch Linux. Another person complains they tried building it for ARM 64–bit and it didn’t work. People are using it in a lot more ways than they use .NET on Windows.

PŁ: Yeah, because Windows, even though it has to support multiple devices and multiple things, is still more consolidated, so to say. So, like you said, it’s not fragmented, there are not that many distributions…

SG: No. And also Microsoft controls it.

PŁ: Like the internal knowledge on how something works … I think it was like when they rewrote Visual Studio to WPF. People tried to use it and they hit some roadblocks. And it was only when Microsoft took WPF to create Visual Studio, they found out that there had been some issues with the technology that needed fixing. Like with text rendering. There was this issue with blurring text. So I think, maybe because of .NET Core there will be some good changes to the Linux technology.

SG: Yeah, but then I really hope it doesn’t mean that we have to wait for Microsoft to migrate everything to .NET Core on Linux and then discover that it doesn’t work like it should. Because, you know, Microsoft is moving a lot in that direction. I mean, I don’t know any way of any big internal system that is now using .NET Core on Linux at Microsoft. And I don’t really see what it could be. But maybe there is. I’m saying, internally for them I don’t know if there are already big customers for their own stuff. And like you said, I completely resonate with that, they make their products a lot better when they are their own customers.

PŁ: As our interview is coming to an end, let me ask you my last question. You also like writing books and recording Pluralsight courses. Are there any new books or courses coming up?

SG: So books are just really time-consuming. I am considering maybe to experiment with something smaller, like these tiny books that O’Reilly are publishing. They call them reports. Maybe I’ll be thinking of something like that. I don’t see myself writing a 400-page book anytime soon. I’ve been doing some courses with O’Reilly lately. I recorded for them. Kind of like a Pluralsight course. They have a video platform as well so I recorded an offline course and I’ve been doing some online training with them. It’s live training: you can come to the class, ask questions. For me it’s a lot more fun than recording.

PŁ: Because you get some interaction with the people.

SG: Exactly. When you record them to a microphone, you feel really like an idiot. I mean, you’re explaining something to the microphone. But when there are people and there’s a Slack channel and they keep asking questions and there’s hands-on exercises, then it’s just a totally different thing. It’s not like classroom training when I’m physically there, but it’s still a lot nicer than recording.

PŁ: These were all my questions. Thank you for the interview.

SG: Thank you very much.

 

The whole event was really nice so thank you to all that made it happening. See you next year.