Easy HTTP Clients with Guzzle


Comments are closed.

Anonymous at 11:14 on 5 Oct 2013

Please try to watch your filler words, such as 'em'. Otherwise it's good.

Good content, but speaker seemed a little unsure/nervous.

Nathaniel seemed a bit nervous but had no reason to be. Guzzle was introduced well and went into a sensible amount of detail for each of the different uses. Particularly enjoyed the real(ish) world examples with the joind.in API rather than overly simplified examples that can get used in some talks.

(Comment sadly not submitted using Guzzle through the API)

Using a real world example (our very own joind.in) to go through the various sections made it easier to follow, though I did get a little lost on some of the more advanced topics. Sitting down with the slides and a Guzzle install will no doubt solve that.

For the presentation, it wasn't the smoothest, but nothing was actually wrong. I'd recommend having a bottle of water with you, and taking a few seconds to have a sip and pause to get your head clear.

Thankfully, the inevitable phone went off during the questions and didn't ruin the main presentation.

Despite using Guzzle, this talk really showed how much there is to the project; I didn't know there was support for building full API clients with service commands, a really nice touch I can see myself using in the near future.

Genuinely useful information and introduction to Guzzle. The examples were clear and the more complex information was introduced at just the right pace to keep the viewer engaged but not feel overwhelmed.
Nat was a little nervous but managed to get the message across and was engaging enough to keep us interested. I think a few more presentations should help him get over any nerves.
I really enjoyed this presentation and would be interested in seeing him present other topics in the same clear and informative way.

From never having heard of Guzzle I felt I could pick it up and start playing with it pretty quickly by the end of the talk. Good examples seemed to cover a lot of ground without getting dull/repetitive/just too much.

One thing I've heard somewhere is that slide titles should be the punchline of that slide (like a good class/method name, perhaps) - then the actual slide content shows the how and why.

I've just started implementing an SDK for an internal API and already decided to use Guzzle. Picked up a good few features that will definitely make me switch Zend HTTP Client. Can't wait to play with the service description stuff. Talk was short but still packed with content.

Anonymous at 15:28 on 6 Oct 2013

Good talk, lots of useful info, good slides. Speaker was a little nervous and had a slight "umm" problem but still did well. Just needs a little more spark and would be a very good talk.

Having never used Guzzle myself but wanting to try this was a very welcome introduction. If the speaker was looking to expand the talk they might want to look into swagger to generate the specification from comments in the API itself instead of writing everything by hand.

An excellent introduction to Guzzle, which is handy as it is in Drupal 8 and will be good to know.

One of my favorites. The speaker was quite nervous but the talk was very informative - I've used Guzzle but still learned several things from this session.

Guzzle is a great tool and I was happy to see it on the schedule. The talk had good pace and content. The speaker should address the audience and try to work on using fewer "erms" as I found it really distracting. Also talk to the audience rather than the slides - give line numbers as a way to guide people's attention to the correct portion of code (in a small room you can point, when you get the main stage, you won't be able to - and it is always better to face the audience).

Finally: don't apologise. Your sorrow is not the point you're trying to get across, and it distracts from your technical message (which was great!). Look forward to seeing you speak again

We're just about to start using guzzle so this was a great intro for me. The talk was well structured and the slides have good examples, so I'm actually going to do a slidedeck kareoke for my team using them :-)

Nathaniel was nervous and unfortunately it did show but but it's nothing a deep breathe and a little practice won't solve.
I really enjoyed the talk

Nice overview of the possibilities of Guzzle; having not used the tool before, it convinced me to go off and have a proper look at it.
Thought the build up from simple to more complex and diverse examples was very good.

On the presentation side: please try to really look at your audience: we won't bite!
I know it's hard but pick one or two faces or the back wall to focus on. Looking away from the audience at your slides gives a very weird impression.
Next time, get some water on stage and take the time to have a drink every now and again. It also gives the audience time to re-focus.

Clearly you know your subject matter and can plan a presentation, however you didn't take your audience with you very well - you were facing your own slides talking away from your audience far too much to be considered engaging. That combined with me ending up playing 'erm' bingo meant I was quite distracted by your presentation style.

The good news, this can all easily be fixed with more practice :)

I agree with Jeremy. The topic is really intersting and I never thought there was so much to it to be honest. Really need to check Guzzle out some time. However, next time try to make it into a story and please use more joind.in examples. It was good to do, but it would have been nice if all the examples used joind.in. Also, maybe try and create more structure into it and build it up, starting small and then expand until you covered all/most of the functionalities.

I hope this helps.

Great intro to Guzzle, looks like something I need to have a look into at some point. However as has been said in previous comments, the filler words were quite noticeable and distracting at some points.

Good topic, inspired me to have a look at using this myself. I think it would be improved if you could have focussed less on basics that are easily obtained from the website and given more high-level information.