The demo was pretty slick and I like the fact that I can peer through the code afterwards, but I think it might have taken away from other parts of the presentation. I don't think the ""anonymous callbacks are so easy; wait, now I can't test anything" trap" part was mentioned due to lack of time.
I kept looking at the Silex API and comparing it to with what I was learning with Node/Express apps and seeing a lot of similarity. That's why I was interested about the callback hell part of the talk that I didn't get to see as I would like to avoid that hell, obviously. Maybe I just missed this part, but I would either add some code or take that part out of the description in the future.
Best session I went to all day -- entertaining, engaging, and informative! I do small-level conference planning and all of the presenter's tips were super helpful.
This was above my skill level, but not the presenter's fault. The presentation was very well organized and almost made sense to me :)
I liked the presentation and resources mentioned. I've never liked using Features and so will take a much closer look at CINC and alternatives now.
Also, great point of emphasis on how important the interface is in terms of how people think about and use config systems. More people need to realize this.
Awesome poem about mocking the service container and keeping with MAD in MADcamp more than any other presentation I saw. Liked the MADTip resources, too. I think the MADCamp organizers should give you some sort of Lewis Carroll award for this :)
Something that could be improved was the "why would I want to use Typed Data API" part. You did talk about this in the Q&A, but I think your most salient answer is that modules like Rules, Token, Panels, etc. will probably use this API and so you get integration with those systems for free.
P.S. The slides link on the MADcamp site didn't work for me when I just clicked on them.
I unfortunately came in late and was hungover but could tell it was a good presenter/presentation.
I'm still a little unclear on how the console will meld with drush, but it seemed like the presenter said they are having discussions about that.
Also, it was cool to hear that the presenter was also talking to Laravel people since they also use the Symfony console for their Artisan CLI. Props to getting off the island, man!
I only take off some thumbs up because I know it was hard for everyone to hear.
The actual discussion, I thought, was pretty good with reasons for and reasons against using Drupal as it currently is in D7 in a headless, or Hydra-headed way.
For me personally, I walked away with the idea of not exploring Drupal in this arena quite yet and using other PHP or non-PHP based frameworks if you want a different view layer than PHPtemplate, like hooking in an Ember or Angular on the client. To me, it just didn't seem worth it in favor of learning how to do this with other readily available tools.
The other great point was the questions that "headless Drupal" brought up in terms of where do you "cut the head off?" and where the neck is. Drupal is pretty messy in that regard as it has been a monolithic solution and hearing the debate around where the neck was...was interesting.
Awesome talk! I will definitely be using code coverage analysis and CRAP scores as I look through other PHP-based projects and write my own tests. I always like talks that make you feel excited to go back to work and try something new out or think in a different way and this talk definitely fit the bill in that respect.
I have to give five thumbs up for having your setup work against you and still giving a great talk and being entertaining :)
You also answered a question I was going to ask without even making me ask it, bravo! For those curious, if you don't have anything going testing-wise as a developer, the advice was to just start with unit tests rather than getting your whole company to have a talk about BDD and or TDD and or risk doing nothing. I have made the mistake of trying to bring up this issue in companies with no testing methodology other than "clickin' it, checkin' it off the list" and management just says that the client/business can't pay for it. You're better off just leading by example in your own work within the development team so you have that experience and knowledge when trying to bring up testing in a larger context.
One question I didn't have answered is how PHPSpec compares to other xSpec tools like RSpec. I'm a big fan now of comparing tools across languages frameworks, because there are always examples to follow and ideas to steal when you make comparisons like that. I would think PHPSpec borrows a lot from RSpec but am too noobish to really know. I love knowing the history of that kind of shit though. This talk is definitely "off the island" as they say, but maybe adding some xSpec history and comparisons would add future presentations of this talk.
Yes on historical perspective...I love that shit! I see the other commenters are dissing that part of the talk, but if someone doesn't bring it up, how are new people supposed to know why things are the way they are. I mean, it was supposed to be 2/3rds of the talk anyway based on your title and description anyways.
The fact that you finally explained to me the reason behind Drupal's div-itus problem was magical. No other talk I've seen has come close to elucidating this for me and that designers/front-ends strictly using what CSS they were given was once a best practice as "sustainable theming".
The debate at the end was also great between whether Drupal should present shiny buttons to the end user for helping with design inherently coupling data to presentation or if more decoupling is needed where the truth is in the template and screw your shiny Quick Edit button. It still seems like a debate, but I don't see how the future will not look like what you presented as being in store for the future.