This is the 2nd set of Zend Certification Tips and Advice to help anyone taking either of the two Zend Exams powered by Zend Technologies: the Zend PHP Certification Exam and/or the Zend Framework Certification Exam. The aim being to help people who want to sit for those exams and inform them what it is all about & what to expect by hearing it from (pro) PHP Guys who have already been through it, that is => Hear It From Zend Certified Engineers!

They start with a little background on her and her experience with PHP and get quickly into the questions about the exam. Topics include things like:

• What the test is about and hopes to achieve
• Some things you can do to prepare
• A recommendation to make the most of your time exploring topics you might be weak in
• Whether or not the ZCE training classes help in the learning process

You can read the rest of the interview here.

No one ever talks about how to create quality pages, what they should look like, how should they be structured, and so on. The reason for that is simple: we don't need no stinkin' instructions for that! Everyone knows how to design good screens (opps, pages). That's the easy part, right? Well, maybe not. [...] Of course, business pages are different from the pages that we may develop for a blog or website.

He goes on to talk about things like the number of "switches" (shifts in context between just using the keyboard vs using the mouse as well) and how you should "mirror the task" not the database that lives behind it. He also makes a recommendation about keeping the important things "above the fold". He notes that, unlike some of the usual sites out on the web, business applications are a bit more about usefulness and less about style.

What about code readability, from my point of view is one of the most important thing in the code. Who writes code that is easy to read, writes good code. Probably reading code is where you spent most part of your time, and not only your code, probably code of your team mates, or maybe code from the open source community, so write code that is simple and is easy to understand it's really important.

His tips (seven of them) are:

• Comment before write your code (DocBlock)
• Return frequently, Return early
• Break, Continue
• Code Standard / Name conventions
• Throw Exception
• Comment often, but not write stupid comments
• Methods can be always smaller than they are

It's a little difficult to read as the English isn't the speaker's native tongue, but it gets the point across. He also recommends reading this if you'd like more information about writing better OOP code that's easier to read.

At Velocity 2011, Nicole Sullivan and I introduced CSS Lint, the first code-quality tool for CSS. We had spent the previous two weeks coding like crazy, trying to create an application that was both useful for end users and easy to modify. Neither of us had any experience launching an open-source project like this, and we learned a lot through the process.

The article reads like a checklist of things you'll need to consider as you create your project - things like:

• Determining what your goals are
• Choosing a license
• Code structure and organization
• Documentation

There's also a few other suggestions that may or may not be useful depending on the project like "use a mailing list" or "use version numbers" but they're all good ideas. Even if you're already working with an open source project, this is a good overview and could give you food for thought on things you might have overlooked.

The plan was to try and write as many tests as we could for the Constraint classes PHPUnit uses to implement its assertions. [...] Well, our plan didn't work out that way, we didn't really succeed in writing a considerable amount of unit tests. However, it still was a valuable experience, as it turned out the unit tests of the Constraints are a good example of how not to unit test.

He includes three of the major points they came across in their practice development:

• Don't use one single test case class to test several different classes
• Name your tests well
• Avoid to test more than one behaviour in one single test

For each, there's a summary answering the "why" question behind them including an example test (testConstraintIsType) that shows a bad, multiple assertion practice that should be avoided if possible.

He breaks it down into to categories - the good and the bad. Some of the items on either list include:

• static methods (good)
• E_STRICT (bad)
• random passing by reference gone (good)
• replacing is_a() with instanceof (bad)

He also offers some of his personal suggestions for guidelines for future language updates.