Health to the Web

Ok, so we were live last week, but last night HomeDepot updated their site with 3 links to the buying guide. So we are now live from HomeDepot. You can see one of the 3 links in the banner of this HomeDepot page. Users can click "JELD-WEN..." text to get to the guide homedepot.jeld-wen.com. This is a big big deal for our client Jeld-wen and an important success to get such prominence on HomeDepot. Yeeeaaah! Currently we're looking into performance improvements, working bug list and monitoring the site. Most of the team are taking well earned rest today.

We went live last night:   http://homedepot.jeld-wen.com After a tremendous effort by all involved. We're all pretty tired. Thankfully its a soft launch just for the client and Home Depot since the quality is not where we'd ideally like it to be. Yesterday the cloud server which hosts legacy apis we're using started failing. Our temporary workaround for launch is to restart apache every x minutes which seems to rectify the problem. We are working on migrating to new server today. Found and fixed a last minute 500 error yesterday. This note from the SVP for services at Fluid today 8/9: " WOW! Great job! This team pulled off a miracle and I can honestly say that this is the type of effort that truly inspires me."

Well its one week to go live and we are coming back from the brink. People have put in some long shifts and more to go in this last week remaining but measurable progress is being made. Our turnaround strategy involved. 1. Understand true scope of what we need to do. The api status spreadsheet was a big help to show our true status. 2. Prioritize. We decided on a 'Finder First' strategy i.e. we must dedicate API team to completing Finder apis at expense of other APIs. The necessity of this had to be explained to AM/PM etc. 3. Identify workarounds where possible. We identified we could reuse some existing main site apis and started work on using and proxy-ing them immediately on front-end. 4. Keep non Finder team moving forward as much as possible. At the same time we've been focussing on QA and bug fixing. Coding a 404 page for your app in Backbone: Put *path as l ast route on a Router Also code a specific route for 404 page e.g. #404 When *path route fired...

Access mysql from command line / Applications / MAMP / Library / bin / mysql -uroot -p You can find your mysql pass on the MAMP 'start page' Check the logs /Applications/MAMP/logs Command to copy db from server to local

The reason I code named this project "pitbull" is I knew with such aggressive deadline and scope there was a high probability this project could bite ones face off! And so I think it has come to pass. We are in crisis mode because the apis are waaay behind from where they should be. Some time back, I told the PM and API lead all apis needed to be complete no later than 2 weeks before launch, it's 2 weeks before launch today and the apis are basically started, I'd say approx 30% or less complete. Unfortunately  I could see this happening and raised the problem with a number of people but assurances of delivery and progress won the day, until now. And when I rose the issue, I was not aware of the true scale of data the client had to provide or lack of build progress. Today I created a spreadsheet which lists all the apis, true detailed status, responsible parties etc. It has indicators for each step in the process from data from client to api successfully integrated...

Coding My original estimate of 7 days for SelectSizesHopup proved accurate, especially since we uncovered a significant missed requirement. The good news is the view and underlying behavior can be reused on PDP as planned, so reuse goal attained. Here's the UML for the design and what was built. Whats reuseable is basically all but SelectSizesHopupView I created a SelectSizeRowModel for a ui row. It has all the data for the ui and as changes happen on the ui it is updated and in turn triggers change events to which the SelectSizeViewRow controller listens to. Driving behavior through the model. I tried to use Backbones validate() method but ended up writing a custom validate instead. I found that with custom sizes the user can choose to enter a custom size in which case I set a default invalid value, but that would fail in the validate() method and the old value would be retained, which I did not want to happen. In addition, size and height are 1 attribute but with custom...