Group items tagged

2. Use Many Tables With PHP and MYSQL for Scalability – Matt Mullenweg

3. Never, ever trust your users – Dave Child

4. Invest in PHP Caching – Ben Balbo

5. Speed up PHP Development with an IDE, Templates and Snippets – Chad Kieffer

6. Make Better Use of PHP’s Filter Functions – Joey Sochacki

7. Use a PHP Framework – Josh Sharp

8. Don’t use a PHP Framework – Rasmus Lerdorf

9. Use Batch Processing – Jack D. Herrington

10. Turn on Error Reporting Immediately – David Cummings

JavaScript only recognizes the keyword true in all lowercase. PHP accepts both uppercase and lowercase

PHP is not case-sensitive in function or class declarations, but JavaScript is case sensitive for these also.

The key difference between PHP and JavaScript is that JavaScript does not have associative arrays.

JSON strings having become very popular as a faster alternative to XML, and can be read and created with the PHP functions json_encode() and json_decode().

Let's take one more look at defining an object in JavaScript and see how it can be used to compensate for the lack of associative arrays in JavaScript.

// Note that variables should always be// prefixed with "var" to define a local scope.for (var n = 0; n < 10; n++) {  alert(n);}

So, are there any frameworks that don’t suck? Rasmus did mention that he liked CodeIgniter because it is faster, lighter and the least like a framework.

It all starts with “I don’t need a framework.” 2. Then you create 7 classes. 3. Now you have a small library of classes. 4. Then you create an application that uses your library. 5. It works and it’s fast, hurray! 6. Then someone asks you to extend the functionality of your application. 7. And they keep asking for more, and more, and more and more… 8. Now you have 43 classes. 9. You’ve learn so much in the last 2 years. Design patterns, security, performance, testing… 10. What once was a small library is now a big, ugly, un-tested, un-documented, scary framework. 11. Then you change jobs. 12. And you create another 7 classes… This has been happening for the last 30 years.

Les tests unitaires apportent donc un feedback beaucoup plus rapide que les tests de recette, pour un coût nettement plus réduit.

Bien sûr, l'adoption de cette pratique n'est ni gratuite ni immédiate. Il faut d'abord apprendre à utiliser un framework de tests, et surtout ensuite apprendre à organiser son code pour le rendre testable unitairement.

Third, you make a little change to your functional code

Next, you run the tests

In the optional fifth step, you refactor your code to remove any duplication.

two simple rules. First, you should write new business code only when an automated test has failed. Second, you should eliminate any duplication that you find.

Your designs must consist of highly cohesive

You write your own tests because you can’t wait

the running code providing feedback between decisions

Test-Driven Development (Addison-Wesley 2003)

a Smalltalk system with a completely test-driven approach that took four years and 40 person-years of effort

there’s far more to testing than unit tests, so you’ll still need other testing techniques such as functional testing, user acceptance testing, system integration testing and so on.

you have a clear measure of success

most programmers don’t read the written documentation for a system; instead, they prefer to dig right into the code.

Your acceptance tests define exactly what your stakeholders expect of your system; therefore, they truly do determine a good portion of your requirements.

Bob Martin says it best: “The act of writing a unit test is more an act of design than of verification. It’s also more an act of documentation than of verification.

Side by Side: Comparing TDD and AMDD TDD shortens the programming feedback loop; AMDD abridges the modeling feedback loop. TDD provides detailed specification (tests), while AMDD provides traditional specifications (agile documents). TDD promotes the development of high-quality code; AMDD encourages high-quality communication between your stakeholders and other developers. TDD provides concrete evidence that your software works, whereas AMDD supports your entire team, including stakeholders, in working toward a common understanding. TDD provides finely grained, concrete feedback in minutes. However, concrete feedback requires developers to follow the practice Prove It With Code, and they may become dependent on non-AM techniques; AMDD lets you get verbal feedback in minutes. TDD ensures that your design is clean by focusing on creation of callable and testable operations; AMDD lets you think through larger design and architectural issues before you code. TDD isn’t visually oriented; AMDD is. Both techniques are new and therefore may be threatening to traditional developers. Both techniques support evolutionary development. —S. W. Ambler