Done!

[pne]

Yay! I just finished the first draft of my YAPC presentation which I'm scheduled to give on Thursday, the 24th of July, at 15:10 in the Fotango room.

I'm pretty impressed at myself, since I tend to procrastinate things. But I just sat down and wrote the thing in one sitting. (It probably helped that I had already ordered my thoughts by preparing the version for the proceedings.)

Anyway, if anyone is interested in taking a sneak preview at my presentation, they can go and have a look at the current draft. Comments and suggestions are welcome, especially typo corrections or bad links. Enjoy!

Comments

[nik-w.livejournal.com]

Will have a read of that later:)

pretty good

[signal11.livejournal.com]

Just a couple of things I was wondering about:

- I've heard that Perl ithreads don't work too well. Any truth to that?
- For "Why Perl?", why didn't you consider using C++ with threads? You suggested the two other ways I know of doing it (fork and select)

Overall, it was quite good.

Re: pretty good

[pne.livejournal.com]

- I've heard that Perl ithreads don't work too well. Any truth to that?

Can't tell you that. They appeared to work just fine for me, but then, my application was fairly simple. I don't know what trouble they might cause for other people.

- For "Why Perl?", why didn't you consider using C++ with threads?

I don't know. I think the thought just never crossed my mind. Plus the fact that I have no experience with any C++ thread libraries and wouldn't have known where to find one on the Linux dev machine or how to program against it. The Perl threads "just worked".

Overall, it was quite good.

Thank you.

I'll still have to test the presentation (perhaps by giving it to my wife, though she'll only be able to nod sagely every once in a while since she won't understand a word of it, since it's (a) in English and (b) about computers) to see whether it's too long or too short.

[2shortplanks.livejournal.com]

I hope this doesn't seem harsh. I quite liked the slides, but here's my comments and suggestions. Please take them as constructive critisim, not at disparaging remarks.

• slide 1: buzzword alert? SMSC? X25? Any chance you could explain what these are (well, I know, but joe average isn't going to.)
  
• slide 4: You're introducing the term 'RFC-1086-type bridge' here, but not explaining what it is. Maybe you want to restructure the talk to drop this slide, do the next few slides, and then say (if it's not blindingly obvious by the time you've explained the bridge) that you're going to use it.
  
• Slide 6a: Is it important what port is used here, or can this information be ommited for greater clarity?
  
• Slide 6b: I don't like HTML as a presentation medium, or at least not the way you're doing it. Too much scrolling about the page, and the diagrams are never going to fit. Remember, your fonts are going to have to be very large to be readable at the back (and hence not all your stuff will fit on the screen for quite a lot of slides.
  
• Slide 10: Too much information? Do we need to know all this detail. I'm still not clear on what the problems are. Maybe you could just say something like "IPC Shared Memory too complicated".
  
• Slide 11a: You don't mention what version of Perl you're running here. This is quite important when it comes to threads
  
• Slide 12: This is arse about tit. State that data is not shared by default, then state that you can share it with Threads::Shared
  
• Slide 13: It'd be nice to show 'use threads::shared' so people know where this odd 'lock' function is being exported from.
  
• Slide 14: The Threads::Queue thingy needs a diagram. I can't visulise that easily.
  
• You're covering too much in one slide. For example, the Thread::Queue slide is really three slides - one slide for the main stuff, and a slide each for each of the 'I also'
  
• Slide 15: You don't need the # by the } in the while loop for this example as it's obvious what's going on and this just makes it more confusing.
  
• Some of your comments are obvious 'Thread::Semaphore' - this module provides semaphores. Well, duh ;-) How about "This module provides a way for threads to signal status to one another" (seeing as you don't explain what a smeaphore is)
  
• I'd be tempted to restucture some of your slides to be Problem-Solution, rahter than Solution-Problem. For example, the Thread::Semaphore slide could be a slide on the problem of getting one screen to scribble to screen at once, and that you used Threads::Semaphore to do it.
  
• Page 17: The [ ] in the print statement are confusing and probably come from your original code, but isn't something the conference attendees need to see
  
• Page 18: What, a conclusion? No running demo? No screenshot of the example output? I need to get a feel on what's going on here.
  

[pne.livejournal.com]

Thanks for your comments; I appreciate them, especially since this is the first time I'm doing this sort of thing. I'll think about them and see what I can do.

A couple of responses already.

slide 4: You're introducing the term 'RFC-1086-type bridge' here, but not explaining what it is.

Well, it's the last thing on the slide, and the next slide immediately talks about RFC 1086. Is this not good?

Slide 6a: Is it important what port is used here, or can this information be ommited for greater clarity?

The port itself is not that important... I was trying to say that both incoming connections must use the same port, but I'm not sure whether even that needs to be stated. I'll think about this a bit more.

Slide 6b: I don't like HTML as a presentation medium, or at least not the way you're doing it.

It seemed the best thing I could do. I don't have a laptop myself, so I'll have to borrow someone else's. I figured that HTML would work on pretty much everything, regardless of the operating system or installed programs. (Plus I don't have any experience with presentation software such as PowerPoint.)

Too much scrolling about the page, and the diagrams are never going to fit.

I can see the scrolling bit and was thinking about the diagrams. It depends in part on whether the browser has a full-screen mode; when I tested it in Opera and MSIE 5.5, most slides fit one one page. But if there's lots of UI on-screen and/or the browser isn't maximised, then yes, there will be scrolling in some places.

I'll have to go over the slides and see which ones are clearly too long.

Remember, your fonts are going to have to be very large to be readable at the back (and hence not all your stuff will fit on the screen for quite a lot of slides.

I tried to suggest this with my style sheet. Do you think the fonts, as you saw them, are big enough? Or should I make them still larger? (In that case, I'll need to look at the slides again with the larger font to see the effect.)

Slide 11a: You don't mention what version of Perl you're running here. This is quite important when it comes to threads

Good point; thanks.

Thanks also for the suggestion on problem-solution order (which also applies to slide 12).

Slide 15: You don't need the # by the } in the while loop for this example as it's obvious what's going on and this just makes it more confusing.

Page 17: The [ ] in the print statement are confusing and probably come from your original code, but isn't something the conference attendees need to see

Yes; in both cases this came straight from the code. I'll simplify it a bit more to remove irrelevant things.

Page 18: What, a conclusion? No running demo? No screenshot of the example output? I need to get a feel on what's going on here.

This is a difficult one. I'm not sure what to provide.

A demo would be a bit difficult since I'd either need to get the application running on the presentation machine (or one I can access e.g. via ssh), which means installing BEA TUXEDO and our company code and stuff, or writing an app simulator.

And I'm not sure whether the output will exemplify well what I've talked about (queues, semaphores, shared variables); there'll be lots of stuff about decoded EMI packets and other things which are irrelevant in this context.

I think I wanted to show the innards more than the output, but that's not something you can visualise graphically very well.

Again, thank you for your comments and suggestions.