First day at Lone Star PHP Conference

Courtesy of Lone Star PHP 2014

Today the development team at PMG traveled to Addison for the Lone Star PHP Conference. During our first day we encountered some great sessions and insights into the world of PHP and enterprise scalability. Here are some overviews from the sessions that piqued my attention.

Developing clean code and maintainable applications is an important part of the daily lifecycle of a programmer. Adam Culp presented on the subject of developing clean applications and covered some great topics such as..

Leave the code cleaner than you found it

Abstract away complex logic into methods for easier readability

Make function and variables names matter! Simplistic or vague naming conventions often lead to confusion

Refactor when possible, don’t rewrite (this is not exclusive)

Enforce good coding standards. Don’t sacrifice code quality for deadlines or shortcuts

Ask and define all project requirements before coding. This allows you to easily write code from a TDD perspective

Create realistic timelines from the requirements given (do not pad estimates!)

Adam presented numerous examples on the subject and is even writing a book on refactoring PHP code which can be found here (the book is still WIP but code examples can be found on his Github account).

Keith Casey is currently authoring A Practical Approach to API Design From Principles to Practice and presented on ways to improve your API by using examples of how someone can unintentionally — and intentionally — make a “horrible API”. Keiths’ presentation was pretty in-depth so here’s a breakdown of some key points to take away from it..

NOTE: Some of the reasons got merged together in my notes so there’s only 10 instead of 12. However here is a link to the powerpoint presentation with all 12 reasons.

Bad or poorly written documentation. Nothing is worse than having documentation that doesn’t properly reflect the code. This is made worse when developers ship documentation as PDFs which makes updating and distributing new documentation more difficult vs using a live documentation system that updates as your code changes.

Adoption of your API should not be a “long” or “hard” process. Onboarding a new developer to your API should be fast and this is accomplished by writing concise business logic that improves the developer experience.

Extending upon the previous point writing small effective blocks of code is important. Functions and methods should serve a single purpose and not attempt to do multiple actions within its scope.

SOAP as an interface. I found this comical but is very true. SOAP interfaces are extremely vague and hard for someone who didn’t develop the system to follow and understand. Stick with REST as Keith put in his presentation.. “SOAP is like a mortgage, REST is like borrowing $10 from your friend”.

Poorly defined expectations within the API. This is related to how the user/client interacts with the API. For instance reducing the number of required requests and making the endpoints more concise is a huge part to this.

Inconsistencies within the API this can be anything from poor code or bad naming conventions. A perfect example of this is how HTTP URIs are named.

Payloads defining data requests that minimize duplication and respond with correct status codes (e.g. 404 for Not Found, 200 for OK)

Authentication don’t roll your own There are plenty of existing technologies that are thoroughly tested and perfectly suitable for most situations (OAuthV2). Additionally HTTPS comes with an authentication scheme already baked in.

Error Messages this is very important because external developers will be able to design applications faster because errors message are clear and understandable which allows them to correct errors within their application without requesting tech support.

Logging and debugging as with any application its vital to have a proper logging architecture setup using a standard such as PSR-3.

After the conference I had the chance to speak with Keith about a new product he is working on called OP3Nvoice which is an impressive API that allows people or companies to generate analytics data against videos, images, audio, and archives among other formats! But this isn’t just normal meta data the API will actually extract text from audio, do image recognition on videos and generate metrics according to your needs.

Alison Gianotto deserves a shout out for her great session on AppSec (application security) and how it applies to everyone. There were a number of topics she included in her speech that should be noted..

Do not consider security an after thought. Start implementing it when you start creating your program

Reduce unnecessary complexity bugs = vulnerabilities and the more you have the more you expose yourself

Hackers have almost unlimited resources don’t underestimate them. In particular small companies are not adverse to hacking.. in fact they’re more prone to it

Create incident plans, emergency plans, and routinely perform simulated attacks

Invest in security if you don’t have anyone capable of performing penetration tests or other security attacks hire someone to do it — preferably soon

Make sure any 3rd party service your working with encrypts and protects your data to the highest standard.

Most importantly any hack depreciates the value of the program because you loose confidence in your customer base regardless of the scale.

As you can see a lot of knowledge was covered in just 3 sessions! We’re looking forward to seeing what the speakers present tomorrow! Be sure to check back for updates and overviews of Lone Star PHP Conference.