Analysis of the report of Roman Nevolin about F #
Much time has passed since the previous analysis, but I didn’t give up. Today I bring to your attention the report of Nevoroman Roman Nevoroman , dedicated to how a person has a way out, if he, firstly, is a data scientist, and secondly, for some reason loves .NET.
It is quite logical that this performance took place on DotNext in December 2016:
Slides can be found here .
')
Traditional disclaimer: about .NET, only the report being analyzed in the article, and not the article itself.
In the previous analysis there was no reason to focus on this, but Roman wrote separately that he considered himself not a very experienced speaker, so I will comment on a couple of points.
Please note that the speaker's view returns to the hall very quickly every time he has to look somewhere aside. In the story there is a code on the slides, demo and other things that require the attention of the speaker. Very many, even quite experienced people, look after it for a long time sticks on the screen, and Roman does an excellent job, and this is exactly what should be done.
Another remarkable moment came at about 3:45 . If a person was put on the podium and ordered to stand there, because the camera is aimed there, then he will often do so, even if it is inconvenient. In this case, the speaker did the right thing: you should immediately correct your discomfort during the performance, and the camera will adjust somehow.
A lively and keeping in touch with the audience a speaker can afford more flaws in the content and slides and still perform well. Of course, failure to deliberately save any contact with the audience, but the liveliness of the speaker gives a normal story a lot of credibility points.
In general terms, the meaning of the novel’s story is as follows: there are typical tools that the data scientist needs, and so far this set of tools has not been associated with .NET. Meanwhile, within the framework of the platform, there is an excellent F # tongue in which practically everything already exists, take it and use it.
Suppose that the purpose of the performance is to promote F #. Since this is a tool at the junction of .NET and data science, it would be promising to go to those with data science and sell it to .NET + F #. It’s hard to imagine how to transfer a .NET researcher, who has a completely different technology stack now, and the developers who surround it, also do not use .NET, but it seems to me that the sales market is there. At the .NET conference, there are hardly a lot of people who suddenly slap their foreheads and realize that F # is suitable for solving their problems.
I am deeply convinced that a story with a plot, at least some one in which technical information is embedded, works better than simply listing this technical information. In the report, we see aspects of the data scientist's work, supported by small tasks in F #. There are several problems with this approach.
First of all, it does not follow from all this that the system as a whole is suitable for solving global problems.
Secondly , the spectators have to reflect on each task from the ground up, ejecting the previous one from their minds, even if they are small. During the report, we encountered the following subject areas:
Since the task is completely new every time, the conditions have to be explained from scratch, and the audience has to unload some of the previously accumulated information. It seems to me that one big end-to-end story would look more advantageous, in which there would be tasks along the way that could demonstrate the power of F #. It is easier to put the whole picture in the head of the viewer.
At the same time, the real or similar to the real task is better than the obviously fictional one. Even if this is a custom development and all real tasks under NDA, quite often the customer is not against the story, since we don’t need to disclose anything truly confidential. By asking the customer for permission, we do not lose anything.
If we have an end-to-end task, it will be a little easier for the audience, but it may take more time: you will need to do an intro in the subject area, describe the solution architecture (which you should also refer to more than once), and the code will probably will be harder. In order to find this time, I propose to shorten the demonstrations, which now is the time to say a few words.
In my opinion, the demonstration organically looks in the hands of the front-end. True, it slows down like this, but there is no such thing any more. Here you get beautiful 3d effects, but they don’t work there. Through the demonstration, you can immediately link the code and the effects it produces. But even this can be done using a pre-recorded screencast.
There is no need to demonstrate live server application at all, it is easier to show the result of its work on the slide. The audience and without demonstrations tend to believe the speaker, if he generally looks reasonable and speaks believable things.
Separately, I want to criticize the demo with a linear regression of bike rental (starts at 27:20 ). For those who are not familiar with linear regression, it does nothing, because the code appears and disappears quickly, and all the time there are references to relevant mathematics. Here, Roman says just not quite believable things, and this makes it very difficult to follow. If we don’t like the mistake we got in some machine learning (whether this term refers to linear regression is a subject of a separate philosophical dispute), then feeding all the available data into training is a bad idea. The first thing that comes to my mind is the idea of retraining, and not at all that there is some kind of fake dataset and there is no natural noise in it. That is, it wasn’t mathematically accurate to tell here, and there’s also a flicker between applications.
According to the results of the report, I’m ready to believe that there is everything in F # that is needed, so it seems that you don’t need to repeat this in a separate summary slide. Behind the brackets are limitations and performance, but you can not talk about everything.
The slides are quite decent, so most of my comments are minor improvements. The main thing that is good is that on the slides there is something that needs to be shown, and there is no unnecessary text. That is, the slides perform exactly the role that should be performed in an ideal world: the role of illustrations for the speaker's speech.
But to improve, of course, there is always something.
Much of the code appears on the screen during the demonstrations, but it is also quite a lot on the slides. I have several suggestions for the code.
Slides 22-25 show successively classes that need to be implemented to make a wrapper around the Stackoverflow API call. On the one hand, I want to focus on the word consistently : this is correct, it is better to open all somewhat complex objects to the viewer in parts. But you can make this process cleaner. Look, in the end everything comes to three additional classes:
You can see at once on this slide, why did you need these three additional classes? It takes some time, right? Therefore, I propose to highlight only what you should look at:
It seems to me so much clearer who of them pulls someone along. With the sequential opening of pieces of code, the backlighting of already exhausted sections can, of course, be removed.
Slide 51, in which there is quite a lot of code, appears in the report at 20:33 and shows two seconds with the comment “not the essence.” I think it's better to just remove it. No need to show people anything that they should not look at.
Every time when we show the dynamics of a process or successive approximations to a solution, it is better to change only what we want to draw attention to in the picture. All other information, as long as it is relevant, should be left in place. The novel does this in most places, but on slides 36-38 I propose to redraw the diagrams:
What can be improved here? First, time is such a thing that in the minds of most people flows from left to right, so it is better not to use horizontal bars for data that changes over time, unlike in almost any other case. In addition, if you rotate the chart from slide 36, you can overlay the chart from slides 37 and 38 on it, and the viewer will have a previous version of the problem solution for contrast. Of course, the situation that Roman shows is quite simple, so here it is understandable even without all these tricks, but in some more complicated case it will save viewers a lot of energy.
In order not to suffer with two scales, it is better to completely remove the vertical axis, leaving only a qualitative comparison. I understand that a real data scientist during real work will not do this, but here we only need to transfer the idea. I did not ask the speaker for the source codes from the schedule, otherwise I would have removed the grid.
Side note: Interestingly, Valentine's Day is cooler than March 8th. However, maybe in a nearby kiosk everything is different.
Honestly, the observed negligence is not noticeable, but once I’m caught, I will not say a word. First, in several places, objects on the slide are displaced unnecessarily. The problem here is that if the object has not changed, but moved, the eye still fixes the change, and the mind is no longer sure whether the object has changed or not. And since the previous object has already gone out of sight, it is also impossible to compare them with a conscious effort. Therefore, immutable objects spontaneously jump on the slide should not.
When switching between slides 22 and 23, it is noticeable that the upper block of code is jumping, although it has not changed. The same happens with the lower code block between slides 30 and 31. Even it is clear how this happens: since it is too lazy to manually highlight the slide, it is more convenient to copy the code from the IDE in the form of a screenshot. Further on one of the slides, the picture randomly moves or resizes, but the author does not notice this. It is better to abandon syntax highlighting, but to have the code in the form of text: it is easier to align.
Another funny thing was found in the sales of the flower stall, which we have already looked at above. The year on slides 33-35 and 37-38 does not match:
This may have many valid explanations, but the sediment remains.
If you want to get feedback on your performance, I’ll be happy to give it to you.
On Wednesday, June 7, at about seven in the evening in Moscow, we are holding a joint event with Kirill Anastasin . We have accumulated a decent list of typical mistakes that speakers often make before going on stage: when choosing a topic and during preparation. If you start performing, come: it will be useful.
It is quite logical that this performance took place on DotNext in December 2016:
Slides can be found here .
')
Traditional disclaimer: about .NET, only the report being analyzed in the article, and not the article itself.
Speaker behavior
In the previous analysis there was no reason to focus on this, but Roman wrote separately that he considered himself not a very experienced speaker, so I will comment on a couple of points.
Please note that the speaker's view returns to the hall very quickly every time he has to look somewhere aside. In the story there is a code on the slides, demo and other things that require the attention of the speaker. Very many, even quite experienced people, look after it for a long time sticks on the screen, and Roman does an excellent job, and this is exactly what should be done.
Another remarkable moment came at about 3:45 . If a person was put on the podium and ordered to stand there, because the camera is aimed there, then he will often do so, even if it is inconvenient. In this case, the speaker did the right thing: you should immediately correct your discomfort during the performance, and the camera will adjust somehow.
A lively and keeping in touch with the audience a speaker can afford more flaws in the content and slides and still perform well. Of course, failure to deliberately save any contact with the audience, but the liveliness of the speaker gives a normal story a lot of credibility points.
Plot
In general terms, the meaning of the novel’s story is as follows: there are typical tools that the data scientist needs, and so far this set of tools has not been associated with .NET. Meanwhile, within the framework of the platform, there is an excellent F # tongue in which practically everything already exists, take it and use it.
The target audience
Suppose that the purpose of the performance is to promote F #. Since this is a tool at the junction of .NET and data science, it would be promising to go to those with data science and sell it to .NET + F #. It’s hard to imagine how to transfer a .NET researcher, who has a completely different technology stack now, and the developers who surround it, also do not use .NET, but it seems to me that the sales market is there. At the .NET conference, there are hardly a lot of people who suddenly slap their foreheads and realize that F # is suitable for solving their problems.
Enumeration vs. story
I am deeply convinced that a story with a plot, at least some one in which technical information is embedded, works better than simply listing this technical information. In the report, we see aspects of the data scientist's work, supported by small tasks in F #. There are several problems with this approach.
First of all, it does not follow from all this that the system as a whole is suitable for solving global problems.
Secondly , the spectators have to reflect on each task from the ground up, ejecting the previous one from their minds, even if they are small. During the report, we encountered the following subject areas:
- Distribution of developers by country
- Sales of flowers
- Contact lens recipes
- Macroeconomic indicators of third world countries
- Bicycle rental + linear regression
- Stock price analysis
Since the task is completely new every time, the conditions have to be explained from scratch, and the audience has to unload some of the previously accumulated information. It seems to me that one big end-to-end story would look more advantageous, in which there would be tasks along the way that could demonstrate the power of F #. It is easier to put the whole picture in the head of the viewer.
At the same time, the real or similar to the real task is better than the obviously fictional one. Even if this is a custom development and all real tasks under NDA, quite often the customer is not against the story, since we don’t need to disclose anything truly confidential. By asking the customer for permission, we do not lose anything.
Live music
If we have an end-to-end task, it will be a little easier for the audience, but it may take more time: you will need to do an intro in the subject area, describe the solution architecture (which you should also refer to more than once), and the code will probably will be harder. In order to find this time, I propose to shorten the demonstrations, which now is the time to say a few words.
In my opinion, the demonstration organically looks in the hands of the front-end. True, it slows down like this, but there is no such thing any more. Here you get beautiful 3d effects, but they don’t work there. Through the demonstration, you can immediately link the code and the effects it produces. But even this can be done using a pre-recorded screencast.
There is no need to demonstrate live server application at all, it is easier to show the result of its work on the slide. The audience and without demonstrations tend to believe the speaker, if he generally looks reasonable and speaks believable things.
Separately, I want to criticize the demo with a linear regression of bike rental (starts at 27:20 ). For those who are not familiar with linear regression, it does nothing, because the code appears and disappears quickly, and all the time there are references to relevant mathematics. Here, Roman says just not quite believable things, and this makes it very difficult to follow. If we don’t like the mistake we got in some machine learning (whether this term refers to linear regression is a subject of a separate philosophical dispute), then feeding all the available data into training is a bad idea. The first thing that comes to my mind is the idea of retraining, and not at all that there is some kind of fake dataset and there is no natural noise in it. That is, it wasn’t mathematically accurate to tell here, and there’s also a flicker between applications.
findings
According to the results of the report, I’m ready to believe that there is everything in F # that is needed, so it seems that you don’t need to repeat this in a separate summary slide. Behind the brackets are limitations and performance, but you can not talk about everything.
Slides
The slides are quite decent, so most of my comments are minor improvements. The main thing that is good is that on the slides there is something that needs to be shown, and there is no unnecessary text. That is, the slides perform exactly the role that should be performed in an ideal world: the role of illustrations for the speaker's speech.
But to improve, of course, there is always something.
Code
Much of the code appears on the screen during the demonstrations, but it is also quite a lot on the slides. I have several suggestions for the code.
Slides 22-25 show successively classes that need to be implemented to make a wrapper around the Stackoverflow API call. On the one hand, I want to focus on the word consistently : this is correct, it is better to open all somewhat complex objects to the viewer in parts. But you can make this process cleaner. Look, in the end everything comes to three additional classes:
You can see at once on this slide, why did you need these three additional classes? It takes some time, right? Therefore, I propose to highlight only what you should look at:
It seems to me so much clearer who of them pulls someone along. With the sequential opening of pieces of code, the backlighting of already exhausted sections can, of course, be removed.
Slide 51, in which there is quite a lot of code, appears in the report at 20:33 and shows two seconds with the comment “not the essence.” I think it's better to just remove it. No need to show people anything that they should not look at.
Saving context
Every time when we show the dynamics of a process or successive approximations to a solution, it is better to change only what we want to draw attention to in the picture. All other information, as long as it is relevant, should be left in place. The novel does this in most places, but on slides 36-38 I propose to redraw the diagrams:
What can be improved here? First, time is such a thing that in the minds of most people flows from left to right, so it is better not to use horizontal bars for data that changes over time, unlike in almost any other case. In addition, if you rotate the chart from slide 36, you can overlay the chart from slides 37 and 38 on it, and the viewer will have a previous version of the problem solution for contrast. Of course, the situation that Roman shows is quite simple, so here it is understandable even without all these tricks, but in some more complicated case it will save viewers a lot of energy.
In order not to suffer with two scales, it is better to completely remove the vertical axis, leaving only a qualitative comparison. I understand that a real data scientist during real work will not do this, but here we only need to transfer the idea. I did not ask the speaker for the source codes from the schedule, otherwise I would have removed the grid.
Side note: Interestingly, Valentine's Day is cooler than March 8th. However, maybe in a nearby kiosk everything is different.
Negligence
Honestly, the observed negligence is not noticeable, but once I’m caught, I will not say a word. First, in several places, objects on the slide are displaced unnecessarily. The problem here is that if the object has not changed, but moved, the eye still fixes the change, and the mind is no longer sure whether the object has changed or not. And since the previous object has already gone out of sight, it is also impossible to compare them with a conscious effort. Therefore, immutable objects spontaneously jump on the slide should not.
When switching between slides 22 and 23, it is noticeable that the upper block of code is jumping, although it has not changed. The same happens with the lower code block between slides 30 and 31. Even it is clear how this happens: since it is too lazy to manually highlight the slide, it is more convenient to copy the code from the IDE in the form of a screenshot. Further on one of the slides, the picture randomly moves or resizes, but the author does not notice this. It is better to abandon syntax highlighting, but to have the code in the form of text: it is easier to align.
Another funny thing was found in the sales of the flower stall, which we have already looked at above. The year on slides 33-35 and 37-38 does not match:
This may have many valid explanations, but the sediment remains.
Regular Parsing
If you want to get feedback on your performance, I’ll be happy to give it to you.
What is needed for this?
All this needs to be sent to the habrauzer p0b0rchy , that is, to me. I promise that the review will be constructive and polite, as well as highlight the positive aspects, and not just what needs to be improved.
- Link to the video recording of the speech.
- Link to slides.
- Application from the author. Without the consent of the speaker himself, we will not analyze anything.
All this needs to be sent to the habrauzer p0b0rchy , that is, to me. I promise that the review will be constructive and polite, as well as highlight the positive aspects, and not just what needs to be improved.
A moment of shameless self-promotion
On Wednesday, June 7, at about seven in the evening in Moscow, we are holding a joint event with Kirill Anastasin . We have accumulated a decent list of typical mistakes that speakers often make before going on stage: when choosing a topic and during preparation. If you start performing, come: it will be useful.
Source: https://habr.com/ru/post/328106/
All Articles