Debugging with Pry

Hi, I have no experience with ruby so my comment is the view of a first contact with the contents of your talk.
In the end of your talk I was fully convinced that you are a guru developer, very active in open source projects. However that is not the aim of a talk. The aim is pass on knowledge, and the way you do it must be adapted to the audience you have. In this talk you had a mix of ruby and php developers, so you must have figured not all were experienced with ruby.
These are the problems in your talk:
- You spoke too fast
- At some point you gave an example of php tools, which is good, so you didnt ignore the php ppl, but it was spoken too fast and just mumbling. There was no place where the name was written so I couldn't get it. This is why slides are used for.
- You spoke of the problem and than explained the solution, which is good. But you just spoke it. There should be a clear, short, message about the problem that stays there while you explain the solution. Or at least for some time, so ppl can digest the problem. This is why slides are used for.
- You gave real time and real life examples, which is great. However if ppl don't see your command line stuff clearly and have time to digest it, ppl get lost in the example. Again, there should be a clear explanation of the example, that stays for a while for ppl to digest it.
- Real time examples are great, but you always have the risk of things going wrong, and they did. First you didn't have some stuff installed, than something else happens, and so on. Its great that you make real time examples, but you have to make, at least one test run before the talk.
- Next time, if you plan real time examples, make sure your hosts have a chair for you so you can properly see whats in your screen.

I give 2 points because you definitely knew what you were talking about, you were available for all questions even if out of scope.

Keep it up, Im sure you will get better.

I'm pretty sure Yorick has a very decent understanding in what he was talking about but the talk just didn't cut it. To be honest it showed a lack of respect to the viewers. The talk seemed unprepared and unstructured. There was no clear beginning or ending. Examples in the talk didn't work, that's something that could have been avoided. If your talk requires resources, make sure you have them installed. The viewer doesn't want to be annoyed by watching somebody install dependencies. The talk ended in an awkward period of silence. Some people in the audience tried to make a conversation spring to live, though in my opinion unsuccessfully.

My advice would be:

- structure the talk, people will know what to expect and what to look forward to.
- prepare moments of interaction, once again, people will then expect it and have a question or feedback
- make sure you got your setup working, check it before you do the talk

This might sound as a quite harsh review, but frankly I didn't feel like I was taken serious. People take the time to listen, it's a speakers job to show they respect that by taking preparations, show the effort.