Zend Server as Bottleneck Breaker

Let’s rewind the scenario to the point where Ted transitions the first round of features to the operations team and make one early addition that changes everything.
While the development team moves on to the next set of features, Ted transitions the tested feature set to Mark, a project lead on the operations side of the IT department, so that he and his team can prepare and implement the first round of changes and be ready for the next round.
Mark has had experience deploying applications in previous jobs and is concerned about problems that may arise from the absence of a standardized deployment process. He knows that his team will not be able to match the development team’s agility without a consistent and automated deployment process that cuts down on manual errors. He recommends implementation of Zend Server to provide the needed structure and Ted agrees.
As development team members finish each incremental build, they create deployment packages with Zend Server. Each package contains:
• The application code
• Prerequisites that make sure the system has all the correct PHP extensions and libraries to run the application
• All the parameters that the administrator will need to enter to install it correctly (e.g. database host and credentials)
• Installation PHP scripts that can be run at various points in the deployment process (e.g. after staging or activation)
The application prerequisites save time by ensuring compatibility, avoiding unexpected “wrong library version” crashes at some later point. Predefining installation parameters eliminates potential for deployment error. Zend Server deployment also enables integration with continuous integration servers (e.g. Hudson) for continuous building and deployment of code.
To maximize the application’s scalability and flexibility, Ted’s team decides to deploy it in the cloud, knowing that Zend Server can easily handle application deployment to multiple PHP servers. Using Zend Server Cluster Manager, they are able to auto-scale the application, spinning up new virtual hardware plus PHP middleware (Zend Server) as well as the actual application itself. This means that they are able to automatically adjust their application capacity based on load.
The result exceeds expectations. The project is completed within the required timeline, customer feedback is positive as features go live, and the business sees value in the form of improved bottom line performance and competitive advantage. Behind the scenes, Ted’s team has a structured, easily maintained, business-critical application that will form the basis for a new approach to future development.
And there is more. An unexpected business benefit is the new kind of connection that the company makes with customers. Because of the short iterative deployment cycle, Ted’s team is able to get continuous and ongoing feedback from users and stakeholders. They respond quickly to this feedback with seamless roll out of incremental improvements, which has a positive impact on consumer perceptions of the company and the quality of its customer service.

Read more ►

Anatomy of a Deployment Bottleneck

What causes the deployment slow down? To answer this question, let’s look at what must occur to get an application from development to production in a large enterprise. We’ll do that with a fictional but not uncommon scenario.
A big brand national retailer needs to improve its e-commerce site by making it easy for customers to personalize their shopping experience. This is considered a business imperative as competitors have rolled out robust personalization and social media features that have led to increased sales. Ted, the director of IT, has agreed to a hard deadline of six months to go live with this new functionality.
Ted’s development team launches the project using PHP because it allows rapid application development. It will also allow the team to roll out features incrementally on a weekly or daily basis, feature by feature. This agility has a number of advantages over the traditional approach of building a whole project that launches on a “grand opening” release date:
1. Customers will see immediate improvements in their online experience
2. Upper management will quickly see positive results from the e-commerce improvement
3. Small iterative deployments are easier to address if something goes wrong
4. All features of the new application will be live within the required time frame
The first features are ready for deployment according to the plan timeline. While the development team moves on to the next set of features, Ted transitions the tested feature set to Mark, a project lead on the operations side of the IT department, so that he and his team can prepare and implement the first round of changes and be ready for the next round.
Issues crop up almost immediately.
Mark and his team attempt to keep pace with the speed of the development team, but the lack of processes leads to errors. Deployment steps are run in the wrong order. The database schema doesn’t get synched with the new version of the code. The project slows as the operations team goes back and corrects errors. In the meantime, the development team is ready to transition the next set of features for roll out.
The original goal of deploying features in incremental fashion, along with the benefits that this approach would create, begins to evaporate as the operations team gets bogged down. Ted and Mark seriously consider adapting a deployment technology originally designed for use with a different language. However, nobody on the team has the expertise to adapt any of those technologies to a PHP platform, and hiring the needed talent will take time and money. This would simply add to the delay, so Ted and Mark decide not to pursue the idea.
In order to avoid more process errors, the operations team is forced to slow down the pace of deployment further. This effort, designed to make a strategic difference to the corporation in a short space of time, has soaked up far more resources than intended without reaching a resolution. Ted dreads C-suite meetings because he will not only have to report continued delay, he will have to listen to the problems the delay is causing elsewhere in the business:
• Sales will not meet its targets, which were based in part on the ecommerce improvement going live on time
• Marketing must keep revising its campaigns, which had centered on getting maximum brand leverage from the “rolling improvements” Ted initially promised that aren’t showing up on time
• Finance points angrily to both sides of the ledger, as Ted’s department once again spends more than allocated without any revenues to justify the extra expense
On top of everything else, Ted considers the application’s future scalability requirements, which leads to more concern. If the operations team is running into problems from manual errors and lack of processes as they deploy onto a single server, how bad will things be when they need to deploy exactly the same way onto an eight-server cluster?

Read more ►

Made to OrderModule (Magento)

In Magento, everything you wish to sell must be defined as a Simple Product having its own SKU and price. But there are times when a merchant wishes to sell items that do not have a unique identifying code, like a SKU. The reason that some products might not have an identifying SKU depend largely on the type of item being sold and the organization of the merchant’s business.
These types of situations are especially common for manufacturers who take special orders for items that they may only make one time. An example that most anybody can relate to would be purchasing produce or meat at a supermarket. Apples are sold by the pound, purchasing one pound of apples costs more than purchasing a half pound of apples, or any fractional weight in between. But, each possible weight of apples does not have its own predetermined and unique SKU number. The type of apple probably has a unique PLU, or Price Look-Up code, but the final item of the transaction is an item and a specific quantity; weight in this example.
This fabricated receipt shows an example of how individual line-items of a receipt can be composed of a dimension or quantity plus a unique identifying number, such as a SKU or PLU.
Sample receipt print-out of buying apples.
0.5 @ $3.00 / lbs
........ 1200 Red Apples ........... $1.50
3.19 @ $2.00 / lbs
........ 2200 Florida Oranges ...... $6.38
------------------------------------
Sub-Total .......................... $7.88
Magento currently lacks the ability to accept user input as a determining factor for the end result of a transaction. The customer can only pick from a predetermined selection of items. For manufacturers, who might take special orders for products with varying dimensions of size, this could result in Magento’s database containing millions of “products”. The management of such a database would become cumbersome, in part because it is not how the manufacturer thinks about their own products.

Read more ►

How Magento Does Themes Different from Others

The term ‘theme’ probably sounds to you a familiar ring. Either as an audience, a creator, or both, you’ve experienced the sea of available web applications options via its themes. A theme has largely two types of users – First, the audience–type who experiences it from the aesthetical and usability standpoint by browsing through a store – And second, the creator–type who goes through an additional layer of the theme experience by taking part in building the theme.
To the first user type, a store experience is defined by the ability of a store to fulfill his/her tactical and emotional demands. To the second user type who must fill the creator role, it is the efficiency with which he/she is able to complete a set of development tasks that determines the store experience. We recognize that it is the accumulated experiences of both user types that determine the final profitability of the store, therefore neither user’s experience can afford to be overlooked.
Because we know that as designers you’ve already got the graphical end of things best covered (servicing to the audience–types), we figured we'd just help you along by building an out-of-this-world theme management to maximize your work-flow efficiency and take your creativity to the next level. Here are some things we thought might get you drooling:
1. Maximum customization power
With Magento you can update the look and feel of your store in the category and product level, giving you greater marketing and promotional power as well as a store with endlessly unique design. Ever imagined presenting each product in its own customized product info page? Magento gives you the power to do just that and more, by providing a quick way to customize your product presentation in a per-product and per-category basis.
2. Multiple themes
Magento gives you the ability to load multiple themes at once, allowing you to swap between a default store design and temporary event/season-specific ones — All at the command of a few key strokes.
3. Uninterrupted workflow
With Magento’s fully object-oriented programming, all modules are immediately accessible via template tags from any template files. And because Magento comes feature-rich right out of the box, you’ll never again have to be dependent on a programmer to finish the simplest tasks for you. Magento also thrives on an extensive network of knowledgeable community members (including the official Magento Team), so you will never need to think twice about where to get guidance should you need it along the way.
4. Minimize debugging time
Any designer can recall those precious hours and minutes wasted looking for the unclosed markup scrutinized by your validator. The validator may tell you what’s wrong, but it never seems to tell you where it’s happening. Magento’s modular backend brings with it a modular template system that minimizes the amount of (X)HTML you need to handle at once. Less the mess means less the fuss and more the sanity for the truly important things in life.

Really, the best part of what Magento offers you though, is an application that thrives on its flexibility, leaving you with nothing much to worry about except devising your brilliant plans for your next ‘wow’ front-end. The sky is the limit for this application, and we hope you have fun applying it to your store.

Read more ►

Magneto Product Catalog Development.

I want to share some info related with magneto Major Bug: though I don’t have a time that’s why I have not posted this with Magneto Blog and forum.
If we use the default magneto Promotion... It will take effect to our system but if we delete it does not remove the rule completely from the referenced table. That’s why we have $2.00 in test and $0.00 in live site as a special price.
What we have to do in future if this happens again:
Truncate the table: catalogrule_product_price
And update the table: catalog_product_index_price
Update `catalog_product_index_price` SET `final price`=19.9900,`min_price`=19.9900,`max_price`=19.9900;
19.000 is for the price what we want to set there.
Even for promotion magneto need Price to be set but we have to put some words there.
So if you say we can put some hard code stuff there.... but the promotion way you want will not work with magneto.

http://ping.fm/ZbNJ0

Read more ►

Java J2ee open sorce

The best open source in Java J2ee for B2B, B2C or Web Site i.e Jboss Portel.

Read more ►

Independence Day

We are celebrating Independence day and kite festival with all indian.

Read more ►