Thursday, May 07, 2015

Some effect with datatables

.highlight{
    background-color: rgba(255, 200, 50, 0.1) !important;
}
tbody tr:hover {
    background-color: rgba(255, 200, 50, 0.1) !important; 
}







$(document).ready(function() {
    var lastIdx = null;
    var table = $('table').DataTable();
    $('table tbody')
            .on( 'mouseover', 'td', function () {
                var colIdx = table.cell(this).index().column;

                if ( colIdx !== lastIdx ) {
                    $( table.cells().nodes() ).removeClass( 'highlight' );
                    $( table.column( colIdx ).nodes() ).addClass( 'highlight' );
                }
            } )
            .on( 'mouseleave', function () {
                $( table.cells().nodes() ).removeClass( 'highlight' );
            } );
} );


Monday, May 04, 2015

composer in production

Why
There is IMHO a good reason why Composer will use the --dev flag by default (on install andupdate) nowadays. Composer is mostly run in scenario's where this is desired behavior:
The basic Composer workflow is as follows:
  • A new project is started: composer.phar install --dev, json and lock files are commited to VCS.
  • Other developers start working on the project: checkout of VCS and composer.phar install --dev.
  • A developer adds dependancies: composer.phar require <package>, add --dev if you want the package in the require-dev section (and commit).
  • Others go along: (checkout and) composer.phar install --dev.
  • A developer wants newer versions of dependencies: composer.phar update --dev <package>(and commit).
  • Others go along: (checkout and) composer.phar install --dev.
  • Project is deployed: composer.phar install --no-dev
As you can see the --dev flag is used (far) more than the --no-dev flag, especially when the number of developers working on the project grows.
Production deploy
What's the correct way to deploy this without installing the "dev" dependencies?
Well, the composer.json and composer.lock file should be committed to VCS. Don't omit composer.lock because it contains important information on package-versions that should be used.
When performing a production deploy, you can pass the --no-dev flag to Composer:
composer.phar install --no-dev
The composer.lock file might contain information about dev-packages. This doesn't matter. The --no-dev flag will make sure those dev-packages are not installed.
When I say "production deploy", I mean a deploy that's aimed at being used in production. I'm not arguing whether a composer.phar install should be done on a production server, or on a staging server where things can be reviewed. That is not the scope of this answer. I'm merely pointing out how to composer.phar install without installing "dev" dependencies.
Offtopic
The --optimize-autoloader flag might also be desirable on production (it generates a class-map which will speed up autoloading in your application):
composer.phar install --no-dev --optimize-autoloader
Or when automated deployment is done:
composer.phar install --no-ansi --no-dev --no-interaction --no-progress --no-scripts --optimize-autoloader

How to mount an ISO file in ubuntu?

Maybe, instead of installing additional software, you can use what the system has to this end: Create a directory to serve as the mount ...