How to change root mysql password

1. Login to mysql, and type the following command:

$ mysql -u root -p

2. Switch to the mysql database:

mysql> use mysql;

3. Change password for user root, enter:

mysql> update user set password=PASSWORD("NEWPASSWORD") where User='root';

4. Reset the privileges:

mysql> flush privileges;

Using Symfony2 on a MAC

If you are programming in an OSX environment with symfony2, you will likely come across the following software error:

> Fatal error: Call to undefined function Symfony\Component\Form\Extension\Core\DataTransformer\intl_is_failure() 

As of PHP 5.3, intl is a core extension, but it doesn't ship with OSX. Symfony is supposed to account for this in a stub re-implementation, but there appears to be a bug in play. However, there is a workaround.

First, ensure your autoload.php file contains:

   $loader->registerPrefixFallbacks(array(
       __DIR__.'/../vendor/symfony/src/Symfony/Component/Locale/Resources/stubs',
   ));

Then, you have to make sure that the stub/functions.php file is in play:

   require_once __DIR__.'/../vendor/symfony/src/Symfony/Component/Locale/Resources/stubs/functions.php';

That keeps you running on a Mac.

How to document a file using PHPDoc

h3. Documenting the file

If the first DocBlock in a file contains a *@package* tag,* it will be used to document the file, except when it immediately preceds a class declaration.

This is a file description:

<?php
/**
 * my description
 * @package foo
 */
define('foo','foo');

This is not a file description:

<?php
/**
 * this is a file description
 * @package foo
 */
class foo{

Neither is this:

<?php
/**
 * this is a file description
 * without @package
 */
... some code ...

Why is tar so annoying?

 (xkcd.com - there can be only one )

Can someone please tell me why the tar command is the worst command in the world? Why did the founders of command line wizardry choose to make the most useful command in the world so cryptic.

The tar command has to be the most frustrating command in the world, if measured by by two vectors:

likeability(x) = ( usefulness(x)^2 - difficulty(x)^2)^1/2

In other words, the more useful the command is, the more likeable it is, but this likability is controlled by how difficult it is to use.

The tar command minimizes likeability because it's annoying difficulty is almost equal to how wonderfully useful it is.

Note that when a command is less useful than it is difficult to use, it's likeability becomes an imaginary number. That sounds about right.

Symfony fixtures - doctrine entities only!

This is less a gotcha than a complaint about the DoctrineFixuresBundle. You cannot set a non-entity as a reference.

/**
 * This is the standard example found at
 * http://http://symfony.com/doc/2.0/bundles/DoctrineFixturesBundle/
 * With a few comments added
 **/
class LoadUserData implements FixtureInterface
{
    public function load(ObjectManager $manager)
    {
        // this is a typical approach
        // to making a doctrine fixture
        $userAdmin = new User();
        $userAdmin->setUsername('admin');
        $userAdmin->setPassword('test');
        $manager->persist($userAdmin);
        $manager->flush();
        $this->addReference('admin-user', $userAdmin);

        // but, if you try this approach
        $userAdmin2 = new \genericUserClass(); // not a doctrine entity, not namespaced
        $userAdmin2->setName('admin');
        $userAdmin2->setPassword('test');
        $userAdmin2->saveUsingSomeCustomMethod();
        $this->addReference('admin-user-2', $userAdmin2);  // NOPE! ERROR!

    }
}

I understand the strictness. I understand that it makes logical sense to restrict a doctrine fixture generator to passing around only doctrine entities.

But logical sense doesn't always equal intuitive sense and, if the class has an interface that is acceptable to doctrine references, then it should be allowed.

This strictness makes it more difficult to refactor legacy systems into Symfony2. Existing classes, heavy with business logic, become more difficult to use. I find that I have to do something like:

class LoadUserData implements OrderedFixtureInterface,ContainerAwareInterface
{
    public function load(ObjectManager $manager)
    {
        $userAdmin2 = new \genericUserClass(); // not a doctrine entity
        $userAdmin2->setName('admin');
        $userAdmin2->setPassword('test');
        $userAdmin2->saveUsingSomeCustomMethod();
        $doctrineUserAdmin2 = $manager->getRepository("CoreBundle:UserClass")
                                      ->findById($userdmin2->getId()); 
        $this->addReference('admin-user-2', $doctrineUserAdmin2 );  
    }
}

Certainly there are plenty of arguments why you should stick to only doctrine entities. But it inevitably makes it harder to structure and integrate symfony2 and legacy systems.

Just my two cents. Which is what this opinion is probably worth.