For those out there that are speakers (or are wanting to try their hand at speaking) at a technology conference, Anna Filina has shared her own thoughts about how many talks to submit to a single conference...and what might be too many.

I read this interesting post by Cal Evans about submitting conference proposals. He makes some very valid points, but I’d like to add my own experience as an organizer, so that when you submit, you have multiple perspectives.

She responds to Cal's comments about filtering talks based on topics the conference has mentioned, submitting a max of four talks and submitting the best idea first. Anna also shares some of her own recommendations as an organizer from the Confoo conference(s).

I know how hard it is to go through so many talks. At ConFoo, we receive close to 1000 proposals. [...] I don’t mean to tell other conferences what to do. However, speakers should always bear in mind that conferences operate differently. Perhaps organizers can create a comprehensive guideline specific to their event.

While not specific to PHP Jani Hartikainen asks an interesting question in his latest post - how many tests are too many?. He gives an example of the number of tests in a widely used open source project and how, sometimes, more tests doesn't mean better code.

Some time ago I stumbled upon some crazy stuff… Specifically, I found out that SQLite has 787 times more tests than they have actual code! It’s no joke, it’s documented right on their website. While they have about 116 300 lines of source code, they have 91 577 300 lines of test code.

That sounds completely insane. [...] I bet you’ve sometimes wondered what is the right amount of tests to write. In some cases, it’s easy to end up with more tests than code. [...] When thinking of how many tests is enough, we need to think of what the goals are – both for the tests and our actual project.

He focuses in on this last idea, talking more about the SQLite project and its test suite. He then helps answer the main question - how do you know how many tests are enough? Should you "bend over backwards" to make tests for every possible scenario just because you can? He suggests a few things that can help the situation including refactoring where testing is difficult and writing regression tests for bugs fixed.