tekx stream of though on best practices tutorial.

Starting off the best practices with source control @lornajane asked who is using source control and how much of that is using distributed source control. I’m 2/2 so far. woot. For those who aren’t familiar with source control, it creates a history and is a great collaboration tool.

Using source control is being discussed. You create a repository, add your project, check out your project, make changes. You can update to get changes from others then you commit it all back to the repository.

We’re looking at an svn log and will be discussing distributed vs non-distributed systems. Demonstrating a sample diff.

Source control Tool

* Subversion (svn)

* Git (git)

* Bazaar (bzr)

* Mecurial (hg)

Difference ways to interact with source control. Lorna gives a shout out for all the command line user people and is now mentioning IDE plugins, Trac, Tortoise[SVN|Git|Bzr|Hg]. I need to see if there’s a tortoiseBzr for OSX. I’m thinking of moving to Git since that gives my team more GUI tools, love Bzr but haven’t found many tools. Done with that sidebar. On to Centralized Source Control.

Centralized is like it sounds, and is derived from a central repository. @weierophinney is talking about repository usage including features being worked on at the same time with different release times. Talking about long-lived branches with staging towards production. I’ve found that I’m using a bit of both but want to move away from that. @weierophinney agrees and is moving away too. We’re tlaking about release branches now that live in their own timeline. Mentions that Distributed version control’s power lies in large groups with lieutenants bringing in changes to the project.

@weierophinney talked about most people moving from a central to distributed. I personally just used distributed and didn’t find it tough to pick up but do agree that if you started on central, you have a finer appreciate for the power distributed has.

Reviewing bridges such as git-svn and bzr-svn. Zend Framework 2.0 is on git and 1.x is on svn and they’ve been using the bridges to transition. Now @lornajane is plugging her use of bzr-svn. Just heard the term “continuous integration” used. Is it me or does anyone else consider this a buzzword now? We should make a buzzword bingo game for these talks…just saying.

Going over Hosted Solutions for authoritative sources such as github, bitbucket, googlecode, launchpad, sourceforge. Maybe I should plug @haralovich‘s bzrhive, maybe that will move his ass towards finishing so i don’t have to move from bzr to git. what is bzrhive? think what github is to git, bzrhive will be for bzr. people should harrass/help @haralovich make it happen.

Heard: If you’re not using source control, you’re doing it wrong nub. (not an exact quote)

goinv over resources including tek talks, subversion books, comparison of tools can be found on wikipedia.

On to discussing coding standards.

You don’t have a standard when…

* you always reformat code you get from others

* code you wrote 6 months ago looks different from what you write today

* it introduces a syntax error

I can see that list becoming a meme.

Coding standards assist in maintainability and collaboration. Maintainability provides sttructured predictability. Collaboration is aided by letting any developer can pick up and read it which means

* anyone can maintain it

* decentralizes responsibility

* issues and features are quicker to implement

There are 2 pillars of coding standards but i missed the bullet points on that. =(

ack, messed up my text and missed more thing. lesson learned, save often and wish that this post was version controlled so I could roll back.

Design Patterns isn’t rocket surgery. They’re a common way to describe a common problem which gives us a shared language. Allows you to be put in a position to be able to research best solutions. It’s not just only found in PHP but shared across languages. It is heavily OOP.

common patterns

• factory
• registry
• adapter
• decorator (can be visually decorative but not always)
• observer

factory has methods to creat and return objects. It can return different objects, may use complex logic to work out what to do thus eliminating using a switch to do this. Example is a hat factory. I’ll let people look up patterns because they should and the slides are going pretty fast to parrot back on this post. @lornajane is using SOAP to REST as an example to adapter pattern. This is real life example. If i’m remembering correctly, she wrote a series on her blog on this. I’ll have to see if i can dig that up and link if relevant.

“The root problem is the client came across a little bit of knowledge” – @lornajane

Going over decorators which is making me want to attend the zend_form session by @akrabat so that I can maybe get some insight into the form decorators. Need to see who’s going to the other sessions and get recordings if possible. Should also check with @akrabat if I can record so that I have a bartering chip for some recordings.

Observer pattern watches for changes in another object and responds to those changes. Target class is aware and notifies the observing classes. Example is a map whowing where event attendees are located. If they’re wanting to track traffic, they could ask @dragonbe about that. word on the street is he might know something about that. 😉

Back on topic, I’m thinking I need to look over some of my classes and implement observer strategy. Mention of resources such as the Gang of Four, martin fowler and @sweatje’s own book.

http://www.fluffycat.com/PHP-Design-Patterns/ is a ridiculously silly domain name but also is apparently a good resource.

Documentation via API Docs. Specifically talking about PHPDocumentator found at phpdoc.org. If there’s no code comments, then it uses reflection. PHPDoc output can be generated via command line, web interface and there’s some IDE plugins for it too. One thing to note is that PHPDocumentator isn’t upgraded to php 5.3.

End user documentation. bwah? Oh, narrative documentation for developers such as a wiki. Issues with using a wiki is that it’s un-distributable and un-versioned. HTML is another option but hard to offer in alternate formats (e-reader, windows help system, etc). Docbook XML is yet another option, nice thing is you can use XSLT on it for alternate formats. Looking at an example of Docbook. I’m sold, going to start using that for my projects. Remember to do programming examples as cdata.

tools you’ll need:

• xsltproc
  • http://xmlsoft.org/XSLT/xsltproc2.html
• phd (PHP Documentor)
  • http://doc.php.net/phd/docs/

Going beyond API Docs include doing tutorials, installation instructions, examples, FAQs, forums and user-contribution.

This segues into you (and me) becoming a user-contributor. How? Answer forum questions, hang out on the IRC channel. Help with official project documentation. blogging. @lornajane uses her blog like I do/mean to…as a substitute for a brain. Write for your own use and it hope it’s useful to other people.

Looks like they may be saving the best for last, Testing. Disappointingly, there wasn’t many hands raised when asked who’s doing unit testing. I’m proud to say that I was one of thoe hands raised. So, let’s go on to why you should start. First reason is maintainability (see the slide b/c I was too busy patting myself on the back to catch reasons listed on the slide). Testing quantifies the quality of your code. Kitty photo I want permission to insert here that illustrates the fuzzy feeling you get when your tests go green.

what is not testing

• reloading your browser
• var_dump

Testing is

• reproducable
• automatible

Good testing has defined behaviors, code examples of use cases and expectations.

Testing frameworks available

• PHPT – used by PHP project, some PEAR libraries. neat b/c it’s php using itself
• SimpleTest – JUnit style testing framework
• PHPUnit – JUnit style testing framework; de facto standard

How to test? Create a test case class (usually named after unit or class you’re testing). Think about the behavior you’re testing and state it in your native language. Create a method named after the behavior. capture the code that should create the behavior. Create assertions indicating the expected results. When the slides come up, you’ll have a visual on this with an example that was given in the talk.

Once you’ve built the test case, you run the test. If it fails, then you get to check the test assumptions and assertions then you check your code. Rinse. Repeat. Beer. WIN.

Other Testing Topics includes test doubles (stubs and mock objects). Doubles are amazing but I found the learning curve for me was steep but once I got it, it was the greatest feeling in the world and has made the speed of my testing incredibly quick. If you’re getting into testing, there is a curve and it is time intensive. Stick with it, it is worth every second you spend. It may seem like it takes more time to be worthwhile but as you get more practice, you get a return on that time.

Moving on to Test coverage, conditional tests (useful for environmental conditions). Functional and Integration tests allows you to test systems a unit interacts with all respond expected. This is a scary step. I’m just now trying to get these written for my own systems. Time and budget to do it are hard to find but I have a feeling it’ll be worth it in the end. @weierophinney mentioned Selenium and some other tools that can help with this. Learned about Selenium last year but haven’t looked into it since then.

Adding tests to existing, untested projects is a huge barrier of entry. Best way to handle this is to create tests as you add new features. When you fix a bug, make a test.

Talking about TDD. I agree that once you start using it, you can’t go back. You capture behaviors and individually and iteratively in unit tests. You define your API before to committing to coding them. The biggest help is that you can refine some business logic or how class interaction works. Talking about breaking down tests, we touched upon striving for “one assertion per test” that’s been discussed before.

Bottom line on testing: test early and often.

Looks like I was wrong on testing being last. Continuous Integration and Quality Assurance(?) are last. Staring out with static analysis. lines of code was one tool mentioned but I didn’t get the rest (which is fine since they’ll go through them and I’ll write about them below). Lines of Code utilizes cyclomatic complexity which helps in auditing your code. I’m kinda scared of running this on some of my code. I think it will trigger some kind of “you’re a nub” message.

Code sniffer is associated with coding standards. it’s configurable to look for different properties. There are some pre-defined standards.

Continuous Integration? bwah?? Originally, automated build systems for compiled languages. Used in PHP to run unit tests, build documentation, etc. Any QA tool you have should hook into your Continuous Integration. System typically monitors commits (remember version control from earlier?). Poor man’s CI system can be done with cron if you don’t have time/inclination to create post-commit hooks. Build will run tests, run QA tools (sniffer,etc), build documentation…

Ant (http://ant.apache.org) is one solution. Ant isn’t CI  by itself but a build system. Phing (http://phing.info/trac) is a PHP Ant clone.

CruiseControl (http://cruisecontro.sourceforge.net) uses Ant under the hood but is the first CI solution presented. Has a browser based interface which looks sexy. Next option up is phpUnderControl (http://www.phpundercontrol.org) which is a superset of CruiseControl with built-in support for PHPUnit, CodeSniffer, and more.

Hudson (http://hudson-ci.org) which is an oracle OSS project, written in Java. Uses Ant for build configuration. PHPUnit support via a generic xUnit plugin and supports other PHP tasks via Phing.

Bamboo (http://www.atlassian.com/software/bamboo/) is a commercia Java solution. Uses Ant or Maven. Most PHP QA tools export logs to formats compatible with equivalent Java tools; Bamboo simply uses these logs.

Continuous Integration is about automation to help you find issues early and fix them before deployment. Use CI solutions to perform the automation.

Check out http://phpqatools.org and http://phpqabook.com as well as Sebastian Bergmann’s talk “The State of QA tools…”

Oh, last topic is Deployment. That makes sense. Tools include hand-spun scripts (done this when I was at Resite), Phing, Capistrano (which is Ruby…wonder what @tychay has to say about this. bet he already has said something. ^^)

They may have skimmed a lot of the topics discussed but damn, did they skim them well. For a lot of stuff I already knew or read about, they managed to hold my interest and keep me awake. As @kevinbruce tweeted, it was very intensive and awesome.