After spending a little while changing just the view script I realized I really needed to change the layout file for my public home page. It turns out this is a little more complicated than changing the view file but not my much. Read More
If it's not obvious by the age of these last link posts I'm cleaning out my Instapaper backlog. :-)
I did find it interesting how they generated the ID based on the shard the record was located in.
http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram
An interesting idea that I don't think will work. Who would want to have three racks of servers to replace a much smaller furnace and then have to deal with cooling them in the summer?
http://www.nytimes.com/2011/11/27/business/data-furnaces-could-bring-heat-to-homes.html?_r=2&
For the application I'm working on I want to have give the user one home page if they're logged in and one if they're logged out (marketing stuff mostly). I could have just redirect the user to /index/public/ (I've worked on a project where this was done) but it's an extra page load the isn't really needed. To combat this I dynamically switch the user over to a different view script:
if(!$userLoggedIn){
$viewModel = new \Zend\View\Model\ViewModel();
$viewModel->setTemplate('application/index/public.phtml');
}
Then you just need to create that view file.
This was WAY easier in ZF1...
http://akrabat.com/zend-framework-2/injecting-configuration-into-a-zf2-controller/
Google Chrome has an amazing feature in it's development tools that allows you to right click on an element and select "Inspect Element".
And be able to see all of the CSS styles applied to that particular element.
The one downside to this is that it doesn't show you the :active, :hover, :focus, and :visited styles or does it...
If you click on this icon.
You will get the following checkboxes.
Which allows you to view the extra styles.
I've talk about this before in Zend Framework 1 but Zend Framework 2 has a quick and easy want to find the current version of Zend Framework installed using the following variable:
\Zend\Version\Version::VERSION
I've taken this same approach in the application that I'm working on that has versions. This way the version number is located somewhere safe and it's easy to reference.
I'm super happy that PHP 5.5 added a built in functions to hash and salt passwords. As soon as 5.5 becomes more widespread there won't be a reason for people storing passwords using md5 without salts other than stupidity.
http://www.sitepoint.com/hashing-passwords-php-5-5-password-hashing-api/
At work today somebody accidentally deleted a couple rows from our production database. Normally, this wouldn't be so bad but when the website deleted those row it also deleted a little over a 150 other rows that were dependent on it. I would just copy these rows over using an insert ... select
but those can be error prone when dealing with the 25 columns that this table had so I had to find another way to restore the data.
mysqldump has a parameter that allows you create a dump file that allows you to specify what rows to dump:
mysqldump -uroot -ppassword databaseName tableName --where='foreignId in (802, 803, 804)'
I'm finally jumping feet first into ZF2 and one of the feature's I'm still not sure about is modules. Ideally, they break your code up into reusable chunks but it they still seem to have some drawbacks. For example, I'm a big fan of making sure a page is created as fast as possible (because performance is a feature) so I love the fact that there is a module (the ZendDeveloperTools module which I've mentioned before) that displays a bar at the bottom of the screen with various statistics about the page including how long it took to generate the page. The downside to the module system is that by enabling the module in the application.config.php file
Zend will run code specific to that module even in environments where it won't ever be used (like production). Below is a simple fix to only load specific modules on your local instance.
Read More
subscribe via RSS