Since some time I've noticed that after logging in to Windows 7 something is doing a lot of HDD I/O operations for like 3 minutes.

This was of course making everything else running much slower. Especially running any app for the first time was taking much longer than it should.

After checking in "Performance Monitor" (standard Windows tool) I've noticed that Wmpnetwk.exe process is performing most of the HDD I/O operations.
This is part of the Windows Media Player which lets you share media through network. @see Windows media sharing

When you have a lot of media (pictures, movies) it takes long to scan for changes etc. This is what was taking so long after system start-up. I'm not using this feature anyway so I've decided to turn it off.

How to disable Windows media sharing?

1. Run services.msc
2. Stop and disable  "Windows Media Player Network Sharing" service

You can read this post for more details (screenshots).

• Check file content when you receive it through $_FILES. Check if it contains "<?php".
• Remember that image EXIF can be dangerous.
• Salt passwords.
• Do not authenticate on the client side.
• Write down basic procedures what would you do if your application has been hacked.
• Let people in your company use the app for the first time to play and try to break it.
• Separate development from production machines on every aspect.

So how can we increase our productivity?

• Use mouse as rare as possible. Try to do everything just with keyboard.
• Use clipboard manager, eg. ClipX
• Keep you passwords in one place, eg. Keypass
• Use shortcut keys, eg. with AutoHotkey
• Learn IDE shortcut keys. Search files using keyboard, not mouse.
• Use virtual machines when you have to set up specialized environment to work with some project.

What's the best way to learn shortcut keys?

1. Do something using mouse.
2. Next check how can it be done with just a keyboard.
3. Revert action and do it using a keyboard.

You can read more interesting things out of his presentation.

I've heard of that framework many months (or maybe even few years) ago. I've looked at it a bit but I was not convinced it's so much better than the other frameworks.
After that presentation I've decided to take a bit closer look. That's what I think about it.

Pros:

• It lets you create a web application really fast. A lot of the code can be autogenerated so you have to just adjust it to your needs.
• Code easy to understand and use. Behaviors.
• Prepared for testing (PHPUnit).
• Good documentation. Sample applications included so you can see in practice how an app looks like.

Cons:

• Active record - it's easy to use but it often does not work efficient enough for heavy loaded apps.
• Not as "loosely coupled" as some would like it to be.
• No dependency injection container.

After just few hours spend on getting familiar with that framework I could recommend it for small or medium projects.
If you need to create fast not so complex webpage this framework will definitely help you with that.
It's using many where known solutions (eg. Active Record, MVC) so person familiar with that should not have problems with starting using Yii.

I would not recommend it for big projects where you want things really decoupled, independent and testable.
I think dependency injection container, Doctrine 2, totally independent parts (modules, bundles - whatever you call it) that can be easy configured (eg. with annotations) are what makes your life easy and beautiful.
Yes, I'm thinking about Symfony 2 (and maybe Zend Framework 2 soon) when I think about framework for big projects.

I think Yii authors will change it so it will look more like "modern" frameworks (eg. Symfony 2) if they would want it to be widely used in big projects. Right now Yii is using well known solutions that are also well known to be NOT enough when there's huge amount of code, modules, functionality etc.

But I haven't used Yii. Maybe I'm wrong. But this framework definitely did not make such a big and good impression on me as Symfony 2 did.

Of course maps are strictly GUI related so we need to have some knowledge about JavaScript. But sample code we saw on slides was really simple so no one should have problems with that. At least in basic use cases.

Almost all developers think about Google Maps when they consider solutions that will let them use maps on a site they are building.
But as Derick showed us there are alternatives for Google Maps.
He has mentioned Leaflet (JavaScript library for interactive maps) and OpenStreetMaps (open alternative for Google Maps).

You can see his presentation here. 

According to Derick you can even host your own map service thanks to OpenStreetMaps data that can be downloaded for free.
His presentation was full of "realtime demos" what made it really interesting.

Maps are just one think that we could use in our application but even plain data about places location could be used in many interesting ways.
With a bit of imagination and creativity you can create amazing and interesting things.
I can't wait to play with that some day.

PHPUnit tests that are heavily using the database can run like 10x faster when you run the database from the RAMDisk.
It's the easiest way I know to improve the speed of the tests execution.

Problem - PHPUnit tests can run long time when they are using the database

Project I'm contributing at my work - License Statistics - uses quite a lot of unit tests.
One of the reasons is that we try to do the Test Driven Development (TDD). But this method of creating the software has some drawbacks.

Right now we have something around 1 000 tests that check around 3 000 assertions. Much of them involve database operations. That's why running all tests on Windows machine can take up to 25 minutes.

Tests on Linux machine are much faster - around 7-10 minutes but we still need to run tests under Windows environment due to fact we have to support both platforms and we have to be sure that both of them work perfectly fine.

Solution - put the Database on a very fast hard disk - RamDisk is the fastest

I was "angry" (to say it nicely) that I have to wait almost half hour to see if my changes did not broke anything before I'll do a commit. Although we use continues integration it's nice to know that everything works fine on your machine. That's why I tried to figure out something that will speed up the tests execution.

It was not hard to see that the CPU has to wait for the HDD due to heavy database operations - database is cleaned after every test and initialized with small amount of needed, basic fixtures. Well maybe not every test, but every test that uses Doctrine somehow.

So the simplest  solution would be speeding up the HDD. Especially amount of the the I/O operations per second. There's no way to "overlock" the HDD like CPU so I tried to run the database from the pendrive. This gave me very small speed improvement (maybe because my pendrive is not so fast). But still I had to wait more than 20 minutes for the tests to finish.

Next idea was to "sacrifice" some part of the RAM for the purpose of creating a virtual HDD in that memory - so called RAM DISK.
This solutions is known for years but I didn't see a really good reason till then to use it every day.

Finally I used the Dataram RAMDisk. I created a 0,5 GB RAMDisk and put the database on it. I still have like 3,5 GB of RAM so it's enough for PHP development right now.

Thanks to that the tests are done in around 2 min 30 seconds! That's like 10 times faster comparing to the time that was around 25 minutes when using regular HDD.
I can say that it is worth for sure to sacrifice some part of the RAM to use the RAMDisk.

PS  Dataram RAMDisk is available as a freeware. It allows to create a disk up to 4 GB. For $10 you can buy a license that will allow you to create larger disk - up to 32 GB.

I always try to use objects when I see they are giving me more flexibility than arrays or primitive types.

During my work often I have to operate on dates so I use Zend_Date quite a lot - our project is based on the Zend Framework. But recently I've run a profiler for one of the pages I created and I saw huge impact on the performance that Zend_Date had.

It did speed up development and made it easier but it also made the code much slower. Zend_Date Comparing with the plain PHP DateTime was like 5 to 10 times slower. Even Zend_Date::toString took quite large amount of CPU time.

Solution - use PHP DateTime instead of Zend_Date

Solution for that part of code was replacing the Zend_Date used in the loops (executed even couple hundred times) with DateTime. It was very simple. Also date operations like adding one day is very easy when we have DateTime object - we just need to pass a DateInterval into DateTime::add().

I'm still using Zend_Date for example as the method parameter but in code where I do many date operations I replace it with the DateTime. Thanks to that my scripts are executed much faster.

Some of DateTime features are available since PHP > 5.3 but you can easily use DateTime with older PHP doing small changes in the code.

Doctrine_Query has method which returns one row, it's called fetchOne.
This method is quite useful because sometimes we just don't need all records that a query can return.

But there's a "small" problem with that method. It does not fetch one record!
Well maybe it's not quite true because it returns one row, but at the back-end it fetches the whole collection.

Almost everyone knows that it's the worst solution to fetch all data into PHP from the database to make use just of one of the records. Sadly that is how the Doctrine_Query::fetchOne() really works.

Solution

Simple solution for that is to specify limit by hand, before executing fetchOne().

/* @var $query Doctrine_Query */
$query->limit(1);
$record = $query->fetchOne();

Let's take a look at the source code of this method (Doctrine 1.2.3)

  /**
     * fetchOne
     * Convenience method to execute the query and return the first item
     * of the collection.
     *
     * @param string $params        Query parameters
     * @param int $hydrationMode    Hydration mode: see Doctrine_Core::HYDRATE_* constants
     * @return mixed                Array or Doctrine_Collection, depending on hydration mode. False if no result.
     */
    public function fetchOne($params = array(), $hydrationMode = null)
    {
        $collection = $this->execute($params, $hydrationMode);

        if (is_scalar($collection)) {
            return $collection;
        }

        if (count($collection) === 0) {
            return false;
        }

        if ($collection instanceof Doctrine_Collection) {
            return $collection->getFirst();
        } else if (is_array($collection)) {
            return array_shift($collection);
        }

        return false;
    }

As we can see there's no limit added to the query. This causes that the collection returned by execute() can be very huge. That may slow down our application a lot. And in the worst case it may even make it crash due to excessive memory and CPU usage.

Why this method does not apply limit? As far as I know the limit caused some problems in some cases and it was deleted from this method.

To store the state of the component so it will look the same after page reload or after going back to the same page I need to do few simple things.

// 1. Activate a State Manager using State Provider.
// The simplest is the Cookie Provider implemented by ExtJS developers
Ext.state.Manager.setProvider(new Ext.state.CookieProvider());

// 2. Create an Component and mark it as stateful
// eg. GridPanel can save columns order etc.
var grid = new Ext.grid.GridPanel({
   ...
   stateful: true,
   stateId: 'my_grid_id_for_state_manager',
   ...
});

Now let's try to make a stateful Ext.Panel.

In ExtJS every Component can be stateful but not all components brought by ExtJS have this behavior implemented.

For example GridPanel can already store the settings like columns order, sorting direction, columns visibility. But it can't store for example information if it is collapsed or expanded.

Ext.Panel does not save any information about it's state. That's why I need to specify what should be stored for example in the cookies.

To do that I just need to specify what should be saved by the State Manager and when.

// setting up the State Manager
Ext.state.Manager.setProvider(new Ext.state.CookieProvider());
// creating stateful panel that is collapsible and stores it's state - collapsed or expanded
var panel = new Ext.Panel({
// mark it as collapsible
   collapsible: true,

// mark it as stateful
   stateful: true,

// I can specify the Id of the state
   stateId: 'myPanelStateId',

// say what describes the state of the panel - in that case it is the "collapsed" field
   getState: function() {
      return {
         collapsed: this.collapsed
      };
   },

// specify when the state should be saved - in that case after panel was collapsed or expanded
   stateEvents: ['collapse', 'expand']
});

More detailed information about this topic can be found in the ExtJS documentation - see description for Ext.Panel, especially fields: stateEvents, stateId, stateful.

It should be quit easy to store the components state in the database. Thanks to that the user settings related to the ExtJS components could be restored on every machine he is logging in. I "just" need to provide a proper State Provider.

I didn't have a chance to play with it yet. But as soon as I do, I'll write a new post about it.