Good solid intro of the reasoning behind Stack and how wonderfully simple some things can be when using it.
Wish I'd known of it earlier.
I liked the explanation of the httpKernelInterface; it has given me some ideas for writing my own middleware.
Very entertaining talk. Very recognizable stuff.
I really appreciate the we're-all-playing-in-the-mud-sometimes atmosphere, instead of the I'm-on-my-high-horse-and-therefore-infallible approach.
It made the talk that much more entertaining. Thanks.
Thanks for the intro into Go.
I knew nothing technical about the language before this talk and the real world example touched upon a couple of basic constructs.
Worth looking into further.
Presentation wise, I noticed a lot of the audience was getting 'bored' halfway through. This might be due to:
- the high number of slides with Go code. Although the talk is about Go, on this PHP conference it might be worth using less Go code. Or maybe ease people into the Go concepts by drawing what you are trying to achieve and then relating it to PHP code, before using Go constructs to solve it in a more elegant way.
I think I noticed you did that a couple times in reverse, but I'm not sure and can't find the slides. If not, then maybe just add some PHP code how we could tackle the problem, maybe using closures, socket functions and the stream_select() function (poor man's way of trying to do asynchronous programming in PHP). Then you could also explain where and why such an implementation would lead to problems and how Go alleviates them by using real threading.
- the relative unfamiliarity with StatsD for PHP dev's (I can imagine). Maybe you could use something more familiar to the web and not something devops-y like monitoring? Like maybe a chat server using PHP as a frontend and Go as a synchronizing and pub-sub backend (first thing that popped into my head :).
- even sockets (listening, a packet stream, etc) and the advantages of local UDP sockets can be quite foreign to seasoned framework devs.
Don't get me wrong I enjoyed the talk, just trying to give some constructive feedback.
As said before, good balance between basic and advanced stuff.
I can imagine it's quite a steep learning curve for some, as not many will think of programming in this low-level way.
But it was very engaging for the more experienced dev who likes to keep in touch with the root of computing.
Nice illustration of the bare logic, with computing theory and history. And I have to give credit to Igor and Anthony for giving timely support, while making the exercises, so nobody felt left out. Thanks.
Sound advice with some good examples.
-1 for showing up 10 minutes late.
This is an interesting subject which had a lot of attendees even though it was the first slot of the second day.
There were some technical difficulties; the headset didn't work properly so you had to use a microphone. Also you had to walk to your laptop each time to click to the next slide. These things could have been solved by a bit more preparation.
In the description of your talk you mentioned topics that were not in your presentation (PHPUnit vs Behat vs CodeCeption). DDD is a very broad subject; try to limit the things that you want to present.
The content of your slides were clear although a bit dry. At the start when you showed the start-up example with South Park characters there was room for a joke there. Check out South Park season 18, episode 1 (Go Fund Yourself) for inspiration :-)
3 out 5, it seems the rating disappears after you edit your comment..
Inspirational talk.
Good talk.
A clear demo of xhgui with some good examples.
You can't really go in-depth in such a short amount of time.
Overall I got a good overview of the tools.
I learned quite a few new tricks or features when using regular expressions that by attending this talk.
I though the code examples especially were really well thought out and made all the different options and flags very clear.
I did however find the presentation lacking in style; it all sounded a bit monotomous which does make it hard to keep focusing on the content all the time. And might give the impression that it's only documentation.
Maybe create some break points in between the chapters to explain a bit of background or something, so the audience can re-focus on the next subject.
3 out of 5 stars (they seem to disappear after editing?)