All questions are multiple choice. Moreover it's also indicated in a question itself how many answers it has, for example, "What is this class responsible for in Magento" - it means that the right answer will be only one, "Which two of the following you must do to achieve something" - and you should choose two answers.
I would recommend to start with the Fundamentals of Magento Development Video Course. It covers more than half topics from the Study guide. So before each chapter you can watch these videos and then start digging.
Students will leave the course understanding the Magento
architecture, MVC and data models, how to work with Magento modules,
and how to customize and extend Magento to ensure the best upgrade
path for the websites they extend
There is also a Study Group Moderator’s Kit you can get for a nominal fee. There is a set of exercises on different topics with code sample answers. This could help you not only to prepare for the certification, but also enrich your knowledge in general.
Since the Study Group Moderator's Kit isn't available anywhere, Vinai Kopp made an excellent, free resource: Grokking Magento: Book 1 - Magento Basics & Request Flow. This is an in-depth ebook on the study group material.
At BelVG we have a certification dedicated category in our blog. At the moment it covers only the first chapters, but we're working on it.
Magestore also has a lot of articles.
But the real way to prepare for exam is: all questions in certification guide have the following info:
These code references can be used as an entry point to find answers to
the questions above
Essentially it's a list of files/classes that need to be examined. There is no magic pill - you need to open all of them and check all main methods and analyze how they work. We spent 2-3 hours after work within 3 months to prepare for exam...
As additional info you can check, as mentioned here, Alan Storm articles, Knowledge Base, Magento Extension Developer’s Guide and Design Guide
Disclaimer: I passed exam in May of 2012, and it was based on Magento CE 1.5, from January of 2013 it's based on Magento CE 1.7 and I think that they should update Certification Guide.
Now, In 2016 it's based on Magento CE 1.9
Perhaps consider the following setup:
Applying normal discounts (20-30% off some products)
Either do this manually on each product or create a category called "Sale Items" and under that a subcategory for each discount bracket, e.g "20 percent", "30 percent", etc. You can then use catalog price rules on each of these categories to get the desired discounts.
Flash sales
Again, create a category for the flash sale and then create a catalog price rule discounting products in this category. You can set a "to" and "from" date on this price rule.
Showing sale products on the homepage
To show products that have a special price applied to them I usually create a new block called Namespace_Module_Block_Product_List_Special
(Special.php). It needs to extend Mage_Catalog_Block_Product_List
. You can then overwrite the _getProductCollection()
. Here's the whole block file:
<?php
class Namespace_Module_Block_Product_List_Special extends Mage_Catalog_Block_Product_List
{
//default item limit
protected $_defaultItemLimit = 4;
public function _construct() {
parent::_construct();
}
/**
* Retrieve product collection
*
* @return Mage_Eav_Model_Entity_Collection_Abstract
*/
protected function _getProductCollection()
{
$todayStartOfDayDate = Mage::app()->getLocale()->date()
->setTime('00:00:00')
->toString(Varien_Date::DATETIME_INTERNAL_FORMAT);
$todayEndOfDayDate = Mage::app()->getLocale()->date()
->setTime('23:59:59')
->toString(Varien_Date::DATETIME_INTERNAL_FORMAT);
$collection = Mage::getResourceModel('catalog/product_collection');
$collection->setVisibility(Mage::getSingleton('catalog/product_visibility')->getVisibleInCatalogIds());
$collection = $this->_addProductAttributesAndPrices($collection)
->addStoreFilter()
->addAttributeToFilter('special_from_date', array('date' => true, 'to' => $todayStartOfDayDate))
->addAttributeToFilter('special_to_date', array('or'=> array(
0 => array('date' => true, 'from' => $todayStartOfDayDate),
1 => array('is' => new Zend_Db_Expr('null')))
), 'left')
->addAttributeToSort('special_from_date', 'desc')
;
$itemLimit = $this->getItemLimit();
$collection->setPageSize($itemLimit);
return $collection;
}
public function getItemLimit() {
if($this->hasData('item_limit')) {
return $this->getData('item_limit');
}
return $this->_defaultItemLimit;
}
}
To use it you'll need to add this to your config.xml
under the <global>
tag:
<blocks>
<modulename>
<class>Namespace_Module_Block</class>
</modulename>
<catalog>
<rewrite>
<product_list_special>Namespace_Module_Block_Product_List_Special</product_list_special>
</rewrite>
</catalog>
</blocks>
And then display it on the homepage like so:
{{block type="catalog/product_list_special" name="homepage.products.special" template="catalog/product/list.phtml"}}
Or via layout XML:
<block type="catalog/product_list_special" name="hometabs.products.special" template="catalog/product/list.phtml"/>
You could use the same method to display the special products in each category, but that would require a change to the _getProductCollection()
method that checks for the current category. Have a look at Mage_Catalog_Block_Product_list::_getProductCollection()
for some ideas on the code to use for this.
Best Answer
Reindexing is done for a number of reasons after checkout, here are a few things you can look into:
Percona
Check out the Percona Toolset. We generally use that alongside Percona's build of MySQL. The toolset is a set of diagnostic tools, and there's one just for this. It's called pt-deadlock-logger.
New Relic
We have our clients purchase access to New Relic Pro. When you have it connected, you can easily see all the SQL behind your methods. This helps find ORM calls that might not be efficient and is super convenient when trying to profile and refactor.
Checkout Events
We've seen a ton of crazy stuff observing checkout - it's crazy. I'd look at all of those and see what you can do.
Move Indexers
You could rewrite your indexes to use something other than MySQL. We did this before and it was a dramatic improvement. It was before Magento had the new RDBMS abstraction in 1.6, but is something that would be worth doing.