Lone Star PHP 2015
16 - 18 Apr 2015 at Addison Conference Center

A fun, joyful, slowly-devolving trainwreck. I loved every minute.

I attended a session at MinneBar in Minnesota the previous week entitled "Kids, Code, and Diversity" that was very similar to this presentation. That talk had an advantage over this particular talk: it was delivered by Minnesotans to Minnesotans, by a panel, about a number of programs in Minnesota that are out there trying to tackle the same issues that ScriptEd is working on in New York.

I think the goals and achievements of the ScriptEd program are admirable and worth highlighting in any community, and I would agree with others that providing actionable ways developers can get involved would improve the overall quality of the talk. Development conference attendees are generally looking to get better at their craft, to network with the community, and to figure out how they can get involved, so a talk that doesn't offer those opportunities might fall short. Toward that end, figuring out a way to tailor your talk so that it is applicable to the audience will be helpful both for the goals of your organization and your audience.

"An API is literally just a way of interacting with stuff."

I loved that quote.

Reviewing my notes from this talk, everything comes across more as a practical, common-sense guide to building an API: Use a default query string, don't auto-increment values, ensure you've got unique identifiers, "Just Send JSON", don't use 200 for errors, supplement your HTTP status codes with actual human-readable content.

To date, I have limited experience working with third-party APIs, but after seeing Phil's talk and reflecting on the ones I have used, it's clear to me that there's a lot of work to be done by developers to improve the quality and consistency of their APIs. I appreciated the resources Phil provided, along with an overview of which HTTP methods to use depending on the verb.

As an aside: I attended Matt Frost's OAuth talk earlier in the day, and he and Phil seem to disagree about which version of OAuth to use.

Excellent talk!

A very fast-paced, terrific talk that was simultaneously high-level and practical. There are a lot of ways to modernize WordPress as a development platform, and I appreciated Eugene's overview of the various build, development, and deployment tools one should consider when choosing to work with WordPress. I've been exploring ways to integrate Composer into my own workflow and improving my deployment strategy, so while this talk didn't show me HOW to do it, the reminder on the importance of WHY to do it was useful.

I felt that the idea to version control and tag your organization's purchased/frequently used plugins and themes was one of the best concepts in here, and I look forward to seeing the completely utility Eugene's team has been working on when it's done.

"WordPress can be tamed - you control the environment" should be a mantra.

I will agree with a previous commenter that the talk came off as somewhat of a marketing piece, perhaps because Eugene was joined on stage the entire time by Austin from Roots. There was enough good information that I don't think this was necessarily detrimental to the talk, but speaking alone (when you're the only listed speaker) may be something to consider if this talk is given again elsewhere.

Simply amazing.

At the start of the presentation, Yitz asked, "What can you expect from this session? It's primarily about advice," then said, "Write down just one item that speaks to you." There was far, far more than one item on both the card he handed out for the session and in the notes I took on my computer.

The session was a gentle reminder about the value of community, that no one is an island, effectively growing your skill in this field requires far more than just writing code - it involves interaction, patience, curiosity, and practice.

A+.

This was one of several sessions at Lonestar where I left wanting to dig into the topic further on my own right away. Matt was hugely ambitious in trying to cover both OAuth 1 and 2 in the 50 minute time slot, and focusing on just the client side was a smart move. That said, 50 minutes still wasn't enough to get through the material, and caused Matt to skip over some pieces that may have been helpful to newcomers to OAuth such as myself.

One example: During the OAuth 1 segment, Matt discussed how to build a base string and a composite string, but as far as I can tell, never showed an example of what the full completed string looks like.

In general, I think a talk so heavy in implementation and light on concepts could benefit from a general outline in the slides - tell us where we're going before we get there, then tell us where we're at in the process - visually - so that as learners, we can plan ahead and make sure that we're in the right place when we're following along.

Overall, I thought this was an excellent talk. Ideas for improving it might entail describing the differences between OAuth 1 and 2 and choosing one in which to do a deeper dive (as opposed to racing through both), and/or providing more of a visually guided tour that includes an outline, as described above.

In reviewing my session notes, and re-reading the abstract for the talk, Jordi did deliver in presenting exactly what he said he would present - version constraints, stability, and semantic versioning, plus a few additional tips when using Composer. I enjoyed the talk, but somehow, I came away feeling like I wanted more, even if I can't quite put my finger on what "more" means, in this case. Perhaps a clearer outline of where the talk is going before it gets there might help?

Topics in this talk I particularly appreciated: Jordi's clarification that the composer.lock file should be tracked in version control (and that it shouldn't be deployed!), reinforcement on how versions should be numbered, what a README file should include, and how to constrain package versions in your composer.json file. Some of the talk around tags, branches, and stability resolution were lost on me, but I'm not sure whether that is a reflection on the speaker, my own knowledge level, or both.

Lastly, I appreciated the list of resources I can look up in my own time for additional information.

Overall, a solid presentation. There's no better source than the creator of a utility!

I thought this was a great high-level overview for a lot of OOP programming concepts that can be difficult to understand, and I love the idea of presenting this topic as "More Than Cars and Dogs". The problem with most OOP education is that professors use non-business terminology to explain these concepts, when the reality is that you're more often going to run into nouns like Employee and Manager. Kudos to Chris for using these examples. I would liked to have seen more, including examples of classes that don't map neatly onto any real world object or thing.

"Can a dog have wheels?" offered a reason to walk through topics such as inheritance, interfaces, traits, dependency injection, and testing, with the downfall being that the question at hand went against the very primary topic of the talk. Again, reinforcing the idea of how these tools can be used for actual programming problems would be beneficial.

Chris was far from the only speaker to suffer from this during the event, but adjusting slides with code on them so that they CAN be visible to the entire audience should be a priority.

Overall, I thought this talk was very excellent and few small refinements would make it a must-see.

This talk was a journey of self discovery as a way to advance not only personal learning style but effective communication. The format was engaging and efficiently organized and the information was fresh and exciting. More talks highlighting effective teaching/learning skills are an asset to any community. Bravo!

This was full of interesting (and actionable) content but the pacing and volume were rough. A little more energy/enthusiasm would have made you a bit louder and engaging to create a really solid session.

(Also, for the slides, you can attach those to the talk description above. They're easier to find that way.)