PSR-7 HTTP messages in the wild

Comments

Comments are closed.

Nice presentation. Some very interesting stuff in it.
The having your code available on a repo is also a nice idea.

Some tips:
- Try to inform your viewers what they will learn and bring a bit more structure in your presentation.
- The editor color scheme wasn't always readable (color and contrast) and text was to small.
- Practice a few times
- I would love a practical example of how to implement such a virtual package in composer.

Over all a very interesting presentation!
PS: I would like to give you 3 and a half thumbs but thats not possible, sorry ;)

Very interesting presentation!

Maybe add some short explanation about what PSR-7 actually is about in the beginning, and change the colorscheme of your IDE for the code demos (grey on black is not that easy to read).


- You seemed very enthusiastic about the subject and had extensive knowledge on it, and yet you were able to explain everything in an easy to understand way without alienating people with less experience on the subject. (Eg. explaining immutable objects, translating certain technical terms into easier to understand examples, ...)

- I already knew about PSR-7 and Guzzle 6, but was happy that you included php-http/adapter because I was actually looking for a loosely-coupled way to depend on an HTTP Client in an SDK I'm working on, but didn't know about php-http/adapter yet.

- Learning about virtual packages was informative as well, but maybe you focused a bit too much on what a virtual package is and isn't when the presentation got closer to the end. Explaining it once was sufficient, but repeating that composer can't install virtual packages every time it came up was not necessary IMHO.

- As mentioned in other comment(s) a little bit more practice could help improve the presentation, but I think overall you can improvise very well when things do not go as planned and you seem to be able to keep the audience engaged at all times. So it's not that big of a issue in my opinion. Maybe keep some presentation notes nearby so you have some reminders to fall back on when really necessary (for example the location of the script to start the debug bar server).

- Agree about the editor color scheme mentioned in another comment. I was seated at the front row so everything was readable for me, except for docblocks (which I think you focused on once or twice).

- To me, the structure of the presentation was clear. (1) Interface specifications of Request & Response, (2) Guzzle implementation of those interfaces & how the Guzzle client works in version 6, (3) How to use a loosely-coupled HTTP client instead of depending on Guzzle directly. But maybe the sense of structure becomes clearer when you do a short summary of each "chapter" at the end, so it's clear you're closing one and moving on to a new one.

- Overall I really enjoyed the presentation, and was able to learn some things even though I already had some basic knowledge / experience on the subject. Keep up the good work!

Take aways for myself:

1: Take some more time up front to prepare
2: Before starting the first chapter: spend more time explaining what to expect.
3: Make sure to have a recap per chapter. I usually do this but I didn't this time.
4: Set the color scheme of my IDE to something more suitable for projection and adjust font size.

It was a great talk, and very informative! Learnt quite some stuff!
Things I'd personally would have liked to see or would have done differently:
- Before beginning the talk check how view-able everything is (design for the back of the room)
- Bring more structure, perhaps a different background image for every topic?
- The live demo's were awesome, but perhaps next time host every folder on a different port and have a tab for each demo open in advance, or have the github get responses locally in .json files in case wifi stops working?
- You repeated the part about composer and virtual packages, I'd love to see how composer reacts to virtual packages without implementation (Does it just complain, does it give a list of possible implementations, The part where you showed how to find the different kinds of implementations was super useful!)
- Ask whether people are familiar with a subject before explaining it, like semver, if most people have good knowledge perhaps go more quickly over it?

What was awesome:
- Showing the requests in the timeline with Debugbar
- Live demos
- The presentation shows clearly why abstraction is good

Some nitpicking:
- "What else?" was slightly overused
- No need for the title of the topic and slide on every slide as it adds text you don't want your audience to focus on.

Anonymous at 22:21 on 19 Sep 2015