Tag Archives: PHP

Learning PHP sans bad habits

Posted on by
4

I’ve received some fatalistic responses to my last installment related to what I see as problems with PHP teachings. In particular, I fear we teach people to write applications in ways that are reckless to the fact that these individuals likely read no more than 1-2 PHP books and move on to start writing their application.

Now I’ll present some solutions I propose to the challenges of teaching PHP without encouraging bad habits from the beginning.

Chapter 1: Intro to PHP syntax using the commnd-line
Chapter 2: Make your first dynamic web page using our small framework (hello world)
The framework handles: data escaping input and output, proper sql injection protection, and data/presentation separation. The student needn’t understand all of this yet, but will be explained.
Chapter 3: Variables & Arrays
Chapter 4: Conditionals, Loops & Functions
Chapter 5: Classes
Chapter 6: Sending/Receiving data on the web.
Chapter 7: How to create additional pages in the framework
Chapter 8: Creating forms
Chapter 9: Dissect the framework input/output, presentation and database aspects
Chapter 10: Show how failing to do these things is insecure
Chapter 11: Create additional views/flow using OO framework
Chapter 12: Create a simple application with 3-4 views

This describes the mostly the PHP aspects of a book. This book could easily use SQLite and save the MySQL for another book where it can be properly introduced. It could also include some MySQL education to increase its marketability. The framework itself sounds like a big undertaking, but in fact it can be kept extremely simple as governed by the examples put forth herein. In addition, the frameworks simplicity will allow it to be dissected later in the book for the education of the reader. Finally, when someone finishes the book (or the worst risk with current books if they don’t finish it, they’ll still have the right ideas and not go willy-nilly writing an application using $_GET and $_POST without thinking twice.

[tags]teaching, learning, php[/tags]

PHP Appalachia

Posted on by
2

Brian and I went to PHP Appalachia this Wednesday and Thursday. Different from a traditional conference, the Cherokee, NC KOA served as the main venue for PHP Appalachia. The two of us stayed in a Kabin with a full bed and a set of bunks. All of us hiked, chatted, and met with the other attendees until we left mid-day on Thursday.

We sat around the fire on Wednesday night chatting about PHP when Ben Ramsey and I entered an interesting discussion about PHP’s future and how to introduce newbies to PHP.

I’ll define the sterotype which serves as the premise for this discussion. Most books that introduce PHP, even those which rely on previous programming knowledge begin with an example like this: [code lang="php"]print "hello world";[/code] This example will be soon followed within the next 1-3 chapters (sometimes after, sometimes before introducing loops, conditions, and other basic language constructs of PHP) by an example like this: [code lang="php"]print $_GET['foo'];[/code] In any/all books it’s far later in the book where Object-Oriented programming is covered. In the coverage of creating forms, handling GET/POST/Cookies/Session there’s relatively little talk of security, escaping, or encodings.

The long and short is that people learn PHP in a way that first teaches them to design web applications in a poorly maintainable, insecure, and generally poor method. With the advent frameworks like the Zend Framework and other MVC-based libraries there’s no need to teach bad habits that result in a bad name for PHP.

[tags]php, books, rant[/tags]

return of branching

Posted on by
Reply

We’ve ultimately decided to bring ‘branching’ back into our development cycle. The best part is that we’ve managed to improve the quality of commits from about a 5/10 to about a 8/10 in my opinion. We’ve been dealing with very few production defects. On the flip side, it’s tied our hands when we need to deploy fixes to things like these and we know about problems in the trunk of our software.

We will be ressurecting branches in a very limited capacity. When we do a release (about once per week) we’ll create a branch in our code. This will allow emergency bug fixes to be done without forcing deployment of code that hasn’t been reviewed. It’s not that the code can’t be deployed when in fact we’ve had litte/no issues deploying untested code. However, with the inclusion of QA in our process, we now have resources to eliminate regression by better verifying our releases.

By coordinating the official releases with the end of our sprints we’ll gain the insight of the Sprint Review process to approve the work done during the sprint.

Getting Closer to the Zend Framework

Posted on by
Reply

I’ve subscribed to the mailing list for the new Zend Framework. It’s been quite enlightening to be thrown into a community of the highest-caliber PHP developers (aside from my team of course).

I look forward to contributing more and more to the discussion and ultimately contribute patches and code going forward.

For example, in the preview release, I’ve been working with the Zend_Controller and found a number of things that it lacks. This in and of itself is no problem. The framework is supposed to include some of the best solutions for the most common problems. The aspect I’d like to improve is to allow the framework to be a bit more extensible. For example, there’s no easy way to change the parsing of the actual URL. Even by overloading the functions I still have to pass the URL in via a global variable.

It’s very lucky that we just finished rewriting our front-controller. We learned lots of lessons in the process, but ours solves a specific problem and wouldn’t be for everyone.

[tags]zend, php, framework, front controller, design[/tags]