ZendCon 2016
18 - 21 Oct 2016 at Hard Rock Hotel & Casino

This was a solid and fun talk.

Adam always does a good job presenting information in a clear and conscience manner. Asynch has a ton of little details and Adam provides a good balance between, why, what and how in the talk.

I was drawn to this talk specifically because the extent of my experience with SELinux is indeed simply figuring out how to turn it off. Unfortunately, it just didn't really sink in, but I think this talk has a lot of potential to be a very good talk on a very important topic. I hope the speaker will get some more feedback and make improvements.

The main issue that made it difficult for me to really grok this was the overall flow of the live demo. The speaker definitely knew what he was talking about and was very confident in what he was saying, but the flow of the demo felt a bit clunky. Things like Vagrant misbehaving a bit, the general pace, and so on. I might have had an easier time of this if I already had a good background on SELinux, but I assumed that knowing how to spell it and how to turn it off were the only prerequisites for this talk. Maybe I was mistaken?

I would definitely give this talk another shot if I did a little bit of research into SELinux on my own in order to go in having some context already. Just being able to have some better quality Q&A time with the speaker once I have a bit more background would be very valuable, even if I wouldn't be able to rate the talk higher next time.

I tend to be biased towards wanting keynotes to be more and more technical just like the rest of the talks at conferences, but for closing keynotes, it's always fun to sit back and watch Cal do his thing, regardless of what he's talking about. I'm amazed he was able to pick this concept of rockstars/groupies/roadies and somehow manage to make the connection between them and the different types of players you'll find in the open source community. Even more amazed that he managed to hit the nail on the head for probably all of it, AND be entertaining in the process.

Speaking from the perspective of both an author of a few projects nobody uses, and as someone who was recently bestowed with the honor of maintaining one of my favorite open source projects, there absolutely is a TON of value that so-called "Groupies" and "Roadies" can provide, regardless of how little time they have or how much technical ability they have. I'd love to give my "nobody uses them" projects some more attention, but just don't have the time, so I'm sure anybody in that same situation would welcome these types of contributors. On the other end of the spectrum, existing Groupies and Roadies have made settling in to becoming a maintainer and getting through issues and PRs so much easier because of the attention to detail they give to this project, despite having no real obligation to do so.

If you're a "Roadie" who is finding yourself "shoveling shit" with no appreciation, or a "Groupie" who never gets to go backstage because you're not worth the time to the "Rockstar", find a new band. There are plenty of us out there, and we'd love to have you.

Thanks for great closing, Cal.

I've been interested in event sourcing (from a "people are talking about it, so I want to see what it's all about" perspective) for a while now, and it was great to see a practical example of it in action that I could easily wrap my head around. This talk gave me enough background information and reference material to play around with it on my own.

The speaker is extremely knowledgeable about this topic and other relevant topics that tie in to event sourcing, so this talk is bound to end with a good Q&A session if the crowd is large enough.

Even if you don't have a use case for it now (or do, but it wouldn't be practical to switch it over), you should still attend this talk in order to learn what it's all about so that you can be able to decide to use it or not when the opportunity arises. Fantastic talk!

I confess that I'm not a Laravel developer, and I attended this talk solely because I love live demos and I know this speaker does them well. :) That said, this was indeed a fantastic talk, and someone with a Laravel background wanting to learn TDD absolutely must attend this talk if they have the opportunity.

There seemed to be a lot of background info being covered leading up to the example. This is normally OK for me if we get past it quickly, but it took up a lot of time at the beginning of the talk. The speaker was definitely knowledgeable on the topic, but didn't leave much time to demonstrate a lot of the ways one might have to bridge between a legacy system and Expressive.

Basically, too much focus for too long on the WHAT and the WHY and not enough on the HOW, which is what I think the people typically attending this talk would be looking for.

Good talk. I'm an undying PHPUnit fanboy myself, but I'm glad I was able to get some exposure to phpspec from someone who has more proficiency with it in order to see how the tools differ.

The "recorded coding demo" is a great substitute for a live demo if a speaker isn't comfortable doing one, but there was a bit of awkward pausing/waiting while the videos played and we were just watching the code be typed out in order to move on. During a live demo this is OK because, obviously, a speaker isn't going to be able to type instantaneously (or, they can talk to the audience while typing to make it less awkward), but that's not the case with a video. I would suggest either speeding up the video to superhumanly fast typing speed to help move things along. Either that, or do the opposite - slow them down a bit, but talk through the process and pause where needed (i.e. "ok first you foo the bar and then bar the baz, oh *pause*, yes, what's your question?"

Only other thing is that normal sized text with dark backgrounds on a projector screen is death to readability by anyone other than people with perfect vision in the front row. I'd suggest either enlarging everything as much as possible, or doing everything with a white background.

I've always found some people's "semi-dogmatic" obsessions with things like avoiding if statements, immutability, strict FP, etc.. "just because" to be a little off-putting, so seeing "never write another loop again" in a talk description would have normally resulted in an eyeroll and me moving on to a different talk... however, I attended an excellent talk by this speaker at a different conference and decided to give him the benefit of the doubt and take a look anyway. I'M GLAD I DID! (and you should too, if you happen to be reading past talk ratings to help you decide if you should see this talk at whatever other conference it's being given).

The majority of this talk is a flawless live demonstration of refactoring a deeply-nested, difficult to test, horribly unreadable disaster of a function. The speaker takes you step by step throughout his thought process as he refactors it, and continues to show along the way that the end result remains the same after every incremental change. He could keep the talk exactly the same next time and the time after that and it'd still be a 5 star talk; HOWEVER, I think there are a few improvements that could be made to address some of the criticisms raised by other reviewers.

1. Terminology: Some people may not be familiar with terms like "map", "reduce", "pluck", "flatten", and so on, and might see those terms used and consider the code unreadable because they don't know what it's supposed to do. I've seen those terms before in different contexts so it wasn't hard for me to follow, but someone hearing them for the first time might have trouble understanding the examples, even if you define the terms for them before proceeding. Maybe a little "reference block" of comments off to the side, or perhaps make the editor window a little smaller in order to fit a cheatsheet on the screen at the same time? That way someone can always look back and say "ah ok, that's what pluck does. OK, now what's he doing..."

2. Performance: Refactoring to collections is absolutely going to impact performance - there is no avoiding that. Readability and maintainability trump performance micro-optimizations IMO, though, so I suggest nipping the "this is going to make my site slow" criticism in the bud. Maybe bootstrap a simple Laravel / Expressive / Symfony quickstart application, create an endpoint for the original version of the function and another for the fully refactored version, and do a benchmark to demonstrate "yes, collection pipelines are slower. this example adds 1/10 of a millisecond to your 100-200ms pageload time. can you read and understand the original version in less than 1/10 of a millisecond? no? then stop worrying." You can even use a prepared slide with the benchmark results already on it, since that wouldn't be terribly entertaining to watch live (and it's not really relevant to the talk other than "see? i told you so").

3. Debugging: People said the refactored version is harder to debug than the original monstrosity. Prove them wrong - add some strategically placed bugs and compare how you'd debug them in the collection pipeline approach versus with the original approach.

I won't be seeking out and destroying all loops and conditionals in my application (or refusing to add new ones) after this talk or anything, BUT I now have a new tool in my tool chest, and I'll be sure to wield it whenever I think it makes sense to do so.

(oops, i typed too much...)

The talk was very content-rich and covered a broad range of topics within the OSS compliance space, but I think attendees would benefit more from a deep-dive into the few most common licenses that we see in popular OSS projects on GitHub, as well as a lot more translation from the "quasi-legalse" language you find in licenses to plain English. I typically go with MIT for my open source projects mostly because I can't be bothered to try to read and understand the massive wall of text that stuff like BSD or GPL are in comparison, so something like that would really help.

The speaker is clearly very knowledgeable on the subject and has many years of experience dealing with it, so I think it's easy to miss the fact that the scope might have been too broad for people new to the topic to digest, hence my suggestion to approach it from more of a "deep dive into the common / important things" versus "let me teach you everything".