<form action="/foo" method="post">
    <!-- other form fields -->
    <input type="submit" value="Send data" />
</form>

…and…

<form action="/foo" method="post">
    <!-- other form fields -->
    <button type="submit">
        Send data
    </button>
</form>

Apparently none. Both snippets look and act exactly the same way. And yet, there is a more subtle difference. The difference lies in the semantics and in the meaning of the two types of buttons. A <button> tag displays a button, that you can click with your mouse and can be placed almost anywhere on a page. That’s all. It doesn’t have a purpose.

An <input type=”submit” > on the other hand does a lot more. It’s a form element – can only appear in a form – and it has meaning attached to it. When you submit a form by clicking on such an button, the value of the button is being sent along with the values of all the other form elements to the server.

<form action="/foo" method="post">
    <input type="checkbox" name="item[]" value="1" id="item_1" /> <label for="item_1">First item</label>
    <input type="checkbox" name="item[]" value="2" id="item_2" /> <label for="item_2">Second item</label>
    <input type="checkbox" name="item[]" value="3" id="item_3" /> <label for="item_3">Third item</label>
    With selected: <input type="submit" name="delete" value="Delete" /> <input type="submit" name="archive" value="Move to archive" />
</form>

In this case it matters on which button the user clicks, so an input type=”submit” tag is the best choice. But when you have something like:

<form action="/foo" method="post">
    <input type="text" name="email" />
    <button type="submit">
        Subscribe to newsletter
    </button>
</form>

…it doesn’t! So here the button tag is best suited.

They may be right on some of the statements they make, but when they claim that a career in perl in better than one in PHP they’re wrong. Dead wrong. PHP has a bright future ahead it whereas PERL does not. Because, in the end, arguments such as “perl has better naming conventions” don’t matter. In a world where nearly all programmers have access to speedy O2 broadband packages or other reliable internet connections, both systems can be (and usually are) widely in use on a number of hugely popular sites. Decisions on what technologies should be used, especially on large projects where loads of money are involved, aren’t taken by geeks in dark rooms over a game of AD&D, but by CEOs over a game of golf or in really expensive restaurants.

If you go on Zend‘s website, you find things like improve productivity, maximize IT investments. This is music to a manager’s ears. CEOs like pie charts more than they like pie. If you go on perl’s website, what do you see? Well, perl 5, perl 6, CPAN ratings, Annotated CPAN, mailing lists. Why do you think that there are so many products being developed on Microsoft technologies? Do you think C# in better than perl or PHP? Or that ASP (not ASP.NET, the original ASP) was better? No, this is just Microsoft’s image at work.

PHP is quite big on its own, but compared to perl, it’s huge. PHP in on Oracle’s site. PHP is on Adobe’s site. Wikipedia is built on PHP, WordPress is built in PHP and the examples go on and on. Perl is not even in the debate, it’s seen as an esoteric language used by CLI geeks. I doubt (I haven’t checked so feel free to prove me wrong) that there is a single project with a budget over 200.000 euros being developed on perl.

These factors aren’t exactly “programming related”, so why are they so important in the day by day life of the average programmer? Well, they create jobs, pay money, give you the ability to pay the rent, buy a car, go on vacation and so on. If you come across a career decision between perl and PHP, don’t waste time wandering if perl’s naming standard is better than php’s or which language has less string comparison functions. But instead ask yourself, which technology will allow you to find a better job? Look on a local jobbing site and see how many PHP are available and compare that number to the number of perl jobs available – if any.

…just my 2 cents.

There are 4 traditional stages in software development: development, integration, staging and production. Usually, all these stages take place of different machines that have different domains and/or subdomains. This means that you need a Google API key for each stage. It means that you’ll need at least 3 different API keys just to get to the part where you’re testing the application. But if the developers use different virtual hosts for the project, the number of required APIs increase exponentially. I know that API keys are free, but time isn’t and it’s quite annoying to have to register for a new API key everytime you set up a demo version of the project on a new subdomain.

With Yahoo on the other hand, you only need one API key. And it works. A word of advice: if you need a map API, go with Yahoo! I did…