Matthias Noback has written up an article on his site covering a tool that's common in many web applications, especially for testing: fixture data. In the post he makes some suggestions about effective ways to use them to provide more "real world" results for tests.

System and integration tests need database fixtures. These fixtures should be representative and diverse enough to "fake" normal usage of the application, so that the tests using them will catch any issues that might occur once you deploy the application to the production environment. There are many different options for dealing with fixtures; let's explore some of them.

He makes four suggestions of ways to handle fixtures:

1. Generate them the "natural" way via interaction with the application and taking a snapshot of the data.
2. Generate them at runtime for the tests, reloading them each time
3. Manual insertion of custom data into the database for all tests
4. Manual insertion of custom data into the database for each test case

He finishes the post by asking a question for those considering using fixture data: do you need them at all? Testing should be isolated from external sources so maybe they're not really needed...

In a new post to his site Jason McCreary makes a case for writing clean code in your development processes. He makes three main suggestions of practices you can integrate into your workflow to help make the code you write cleaner.

I noticed [legacy codebases] all suffer from the same fundamental issue - inconsistency. Often the result of years of code patching, large teams, changing hands, or all of the above.

This creates a problem because we read code far more than we write code. So as I read a new codebase these inconsistencies distract me from the true code. My focus shifts to the mundane of indentation and variable tracking instead of the important business logic.

In my experience, I find I boy scout a new codebase in the same way. Three simple practices to improve the readability of the code.

His three suggestions for improving the overall code quality center around standardized formatting rules, consistent naming practices and avoiding nested code. He uses an example piece of code to help illustrate these recommendations with explanations for each.

If you've ever thought about submitting a topic to speak at a technology conference, but never quite knew how to take those first steps, check out this advice from Beth Tucker Long. It's a list of steps and reminders to follow when thinking about your topics and submitting.

I've been on both sides of the proverbial conference table. I have been the one submitting proposals, hoping against hope that they will pick mine, and I have been on the selection committee, struggling to choose between hundreds of awesome proposals when you only have a few talk slots available. Through these varied experiences, I've learned a few things about what works and what doesn't when submitting a conference proposal.

Her list includes things like:

• First and foremost, remember to hit spell-check
• Have someone else read your submission
• Identify a clear problem that the topic of your talk will help solve
• Be honest about your topic
• Share past feedback in the comments or notes section
• Submit a lot of proposals

On DZone.com today there's a new post that welcomes those coming from Java over to PHP with a few recommendations and suggestions about what's different and some things they might find familiar in the transition.

We are welcoming some new colleagues that come from a Java background in the Onebip team, both from the development and operations field. Here's a primer on learning PHP in this situation, that you may find useful when introducing similar people in your PHP-based projects.

He breaks it up into a few sections:

• the "absolute basics" (like the differences in variable handling)
• things to not care about (like procedural PHP or the installation of Apache+PHP)
• how to "write to a graph" (things like PDO, DateTime)
• things to watch out for (like == vs === and some php.ini settings)

He also recommends doing some coding katas with TDD to give you a "crash course" in the language and help you learn from more than just reading.

Rafael Dohms has (re)osted an article of his that previous appeared in php|architect magazine about creating user groups for technology communities and how it relates to physics (well, vacuums at least).

Some developers may notice this absence of “particles” and interaction between them in their local area, this may even cause them enough of an itch that it needs to be scratched, and thus a User Group starts forming. But how hard is it to start a group? Can anyone do it? what really am I going to have to do to get all these particles into my vacuum and end this “empty space” in my region?

He offers some suggestions of things he's done in the past to help start up user groups including things like:

• Finding local developers interested in meeting up
• Spreading the word via coworkers/other companies using PHP
• Having more than just a "one man operation" running the group
• Looking for partners/sponsors for the group and its activities

Come join the fun, being in a user group and participating is a very good, professionally and personally, you are not just helping others, you are learning, teaching and expanding you set of tools.

If you've ever looked at getting your ZCE (Zend Certified Engineer) certification but didn't know where to start, Lorna Mitchell suggests that 2013 is the year to do it and offers some tips (and her own guide to help you along the way).

A few people have told me it's their New Year's resolution to become a ZCE this year, and I'm sure they're not the only ones. I regularly help developers and teams prepare for ZCE, so I thought I'd make up a mini package of tips, tricks and a full set sample questions with solutions and explanations, for anyone who won't be taking a whole preparation course.

She recommends a few things in general too like studying up with the free Zend PHP 5.3 ZCE guide, research into areas that might be a bit foreign to you and, of you have the time and means, try taking a course to walk you through what you'll need to know

Adam Culp has written up a great post with some good suggestions about how you can more effectively foster a better technology community in your area or company.

As most know, I am the organizer of the South Florida PHP Users Group and I am passionate about helping the PHP community grow in south Florida. Over my years as a developer I have noticed the decline of technology in this market, and specifically the PHP community. It was this that led me to organize a group dedicated to turning this trend around, and and grow the PHP community rather than continue to watch it decline.

He shares suggestions on a few different topics, spurred by a conversation at a recent meeting he attended:

• Having a litte-to-no distraction workplace
• Being open to telecommute/remote workers
• Avoiding the "sweat shop" mentality
• Advocating bringing in a fresh perspective (hiring an entry-level dev)
• Supporting company-provided training opportunities
• Respect them as professionals
• Not worrying as much about salary and more about the quality of the developerA

Jacob Mather has written up a (somewhat lengthy) post about things for developers to consider when wanting to improve at their jobs.

At Symfony Live San Francisco 2012, I gave a little talk. No, really. A little talk. Seven minutes. I’m not even sure I used all of it. That’s not a lot of time, but I think I managed to at least provoke some thinking. At least I hope I did. Hmm. How do you act like you care about your work, as a developer?

He has the post broken up into several different categories including being involved in the community, continuing your education constantly, working with automation to make your day-to-day easier and what your real job is (hint, it has more to do with problems and less with code). He also includes a section with suggestions about dealing with coworkers of all different types - everything from management to designers.

On NetTuts.com Jonathan Cutrell has posted some ideas for you to consider when designing your enterprise-level applications, regardless of the language(s) they're written in.

Organization can make or break the maintainability of an application. With smaller applications, organization is more obviously apparent; however, as the application grows and as the number of application developers and front-end engineers producing code increases, the more confusing organization can become. In this post, we will go over some basic concepts for keeping applications organized so that finding relevant code is an efficient and systematic process.

He's broken it up into a list of suggestions to make it a bit easier to take it all in:

• Learn from Frameworks
• Building a Standard
• Uniformity of Connected Parts, Uniqueness of Discrete Parts
• Another Note About Static Files
• What Should Be Unique?

There's some good advice in there, especially around things like standards, naming conventions, site complexity and how much usage the site is likely to see.

In this new post to Reddit, the author asks the community for suggestions for a talk they're giving at a university to cover the PHP language and some of its major features.

I've been asked to give a 1.5-hour talk to university students about PHP. What helpful information should I not miss to impart? Little help please. I plan to name the talk "Why PHP?" to give an introduction of the language and give reasons why it's a good/bad career path. I'm also asked to show a short demo and show some past projects. [...] What would be really helpful facts, tips, etc that I can impart to the students?

Suggestions in the comments include:

• PHP performance
• The accessibility of the language
• Popular sites that currently use it
• The wide community
• Corporate usage

Have any other thoughts? Share them here!