Tag: JavaScript

Categories
Analytics Growth Troubleshooting

Jumping In For Analytics

(Decorist : 11/19-11/19)

Challenge

A newly-added Custom Dimension VWO wasn’t tracking.

Action

We had just introduced VWO into the stack for A/B testing when one of the experiements wasn’t reporting correctly.

I jumped in with PROD to debug and worked with VWO to resolve and figured out there was a race condition with our Angular code preventing the beaconing of the Custom Dimension.

I fixed the issue and deployed to prod.

Results

  • Collaborated w/Product Manager to get VWO experimentation working.
Categories
Backend eCommerce Frontend Performance Engineering Process

What To Do With a 9s Page Load?

(Decorist : 9/18-12/19)

Challenge

Inherited a two-fold challenge: 1) less-than-optimal user experience of 9.01s Avg. Page Load Speed and 2) a culture that did not yet value performance engineering.

Action

Idenfitied initial frontend and backend low-hanging fruit (e.g. page structure, image resolutions, N+1 queries, lazy-loading, etc.) Identifed and delegated KRs to FE leads. Introduced process to methodically follow up each week, pressing the case for performance engineering over months.

Below, a sampling …

Some initial efforts shaved ~3s of the Homepage:

Lighthouse score soared from 5 to 61:

There were multiple speed improvements of up to 50% on various pages across the site as a result of backend query improvements and a +300% bump YoY in SEO traffic (verified by 3rd party SEO consultant)

After Dec 2019, we shifted focus to non-converted UXes after having addressed low-hanging fruit for all UXes.
Sept 2018 to Dec 2019

Results

  • Record Avg. Site Page Load Speed of prevous four years : 9.03s (Sep 2018) to 4.13s (Dec 2019.)
Categories
Architecture eCommerce Management Process Re-platforming Roadmapping SOA

Changing Engine Mid-flight : Again

(Decorist : 8/18-12/19)

Challenge

Take a half-baked v1.5 SOA and continue re-platforming to support scaled integration with corporate parent and its subsidiaries.

Action

Aug 2018

When I joined, it was with the idea that I would be instrumental in helping scale the Decorist relationship-creation paradigm leading to higher AOV to its corporate parent – Bed Bath and Beyond – and its subsidiaries: Buy Buy Baby and Cost Plus World Market.

I inherited the beginnings of a movement away from a Django/Angular/MySQL monolith and towards a Django/React/Postgres multi-tenant platform; a v1.5 of the application architecture. My predecessor had extracted some facets of the monolith to build out the initial stages of the SOA in partnership with another Bed Bath and Beyond subsidiary: One Kings Lane.

Although labeled a multi-tenant platform, it had been built quickly – effectively as a prototype – to service one tenant and was not truly extensible for other silos, though it did encompass solid SOA principles for reuse.

Dec 2018

As part of roadmapping for 2019, wanting to strategically position ‘scalability’ for the corporate org, I worked with my boss – SVP Prod/Tech – to detail a project plan to leverage the exisitng nascent SaaS paradigm for the next generation of the Decorist user experience.

We were sanctioned by the CEO for reduced scope on the roadmap; it would be the very first effort internally for moving towards a new platform to future-power the site. We focused on porting a back-office, manual task of determinging supply-side match and availability with demand-side need.

Wanting to keep a engineer engaged, I shepherded him and helped him understand the Cost-Benefit trade-offs we would need to make in order to meet the deadline, setting a course of re-using the User service for authentication, builidng out a new React-based UI, and integrating with the monolith.

Feb 2019

A few months later, we delivered the feature of supply-side Matching and Availability:

Shortly after launch, business priorities shifted towards a focus on a new eCom offering and we had to back-burner re-platforming efforts.

Dec 2019

Given guidance that 2020 might be the year we could re-visit re-platforming, I ideated around what was still lacking in v1.5 and what would need to be built out, creating a project plan and technical roadmap for the go-forward.

I worked with my boss again around planning and prioritization and we again provided guidance to CEO. Ultimately, we could not secure the necessary corporate integration buy-in for further progress and have had to defer any further progress given other priorities.

Results

  • Mentored Lead Engineer towards implementation of first feature for new SOA paradigm.
Categories
Architecture Backend Chat Cloud demand-side eCommerce Frontend Innovation Prototyping Strategy supply-side

Launched MVP

I was brought on initially part-time into a two-sided marketplace in the holistic services space to assist the team to go from an environment where code wasn’t being shipped to a place that could launch an MVP.

Prior to joining, I commissioned my own Market Landscape (via UpWork) around holistic services potential; one finding: 2015 global revenue = ~$40B

Better Engineering

When I arrived, the POC had been built by an offshore team in WordPress via cPanel and PHPAdmin and transferred from AWS to Digital Ocean. There was no source control. The first thing I did was `git init`.

I spent time attempting to decompose the production instance into a Docker container (of WordPress and MySQL.) I learned how tricky it is when an application is not already 12-factored to spin-up an alternative instance having functional parity. In case you didn’t know, much of the application state of a WordPress site is maintained as JSON config blobs IN THE DATABASE.

Seeing opportunity to prioritize feature creation (in support of product-market fit) in lieu of operational excellence, I put the Docker initiative on hold and spun up dev and staging instances using cPanel and PHPMyAdmin, simply copying the prod DB.

dev instance after trying to decouple

CaaS : Chatroom as a Service

First Iteration

My initial task was to integrate a chat UX with a broadcast streaming experience being built out and powered by Wowza. I settled on Converse.js and ejabberd given decent documentation, an acceptable UX, and (what seemed to be) easy integration; delivering the following POC

chat, working

Next Iteration

With the web server running under CentOS on one Droplet, I had thought it smart to run ejabberd on a separate instance, installing v14 on an Ubuntu Droplet. I ran into issues opening port 5281 from the CentOS VPS to Ubuntu so I doubled-back on my strategy, opting to co-host the daemons on one Droplet (CentOS.) I then ran into package manager issues and wound up having to build and install ejabberd 18 from scratch while upgrading OTP to v20.

While this was happening, the junior engineer was working to get the Wowza live-broadcast video solution working and time wasn’t on our side to get the MVP launched.

(Additionally, at one point, I looked at using the YouTube/Hangout API didn’t find support for our use case.)

Attempt to leverage YouTube/Hangouts

Once I got ejabberd 18 built, installed, and running, we started experiencing timeout issues; manifesting in FE with a spinner that spun for 1.5 mins before the user was finally able to get into the chatroom. I dove into the ejabberd code, and realized that there was something blocking going on server-side. I never did figure out what was happening, but about that same time I realized that the junior engineer had integrated Twilio Video for the 1:1 experience and Wowza Streaming for the 1:many broadcast experience.

Seeing opportunity to reduce waste and consolidate coding paradigms, I researched Twilio Video and realized that we could, for the MVP, likely replace the Wowza experience for both of the 1:1 and 1:many experiences WHILE ALSO leveraging Twilio Chat to replace Converse.js/ejabberd.

Twilio Video, 1:many POC

Next Iteration

I found and customized React Programmable Chat

Twilio Chat, POC

The next step was to integrate with Wowza.

Wowza UX, now w/Twilio Chat

As their were some production issues with the Wowza implementation, I forged ahead creating an alternative Twilio Video React component using React Scripts.

1:1 UX, Twilio Video Chat (desktop and mobile)

At soft (internal) launch, I posited the Twilio solution and the other team members were delighted.

Though the Twilio Video quickstart project was useful, I ran into challenges around the video codecs (VP8 and H.264) between Chrome and Safari, namely getting desktop and mobile video interaction to work as expected. Digging around produced Github links helping lead to resolution (e.g. simply switching to H.264 to ensure cross-browser support.)

On 4/6/18, we had our first successful supply-side (1:many) broadcast, powered by Twilio Video and Chat.

MVP

After helping the team achieve MVP launch and when funding could not be raised in a timely fashion, I moved on.

Results

  • Swooped in when feature-delivery was woefully behind, built out (desktop/mobile) UX, and launched MVP to paying customers.
Categories
eCommerce Prototyping

Centralized to Decentralized Marketplace

Bluxome Labs : 3/18-4/18)

Challenge

Re-conceptualize centralized marketplace idea around leveraging Blockchain.

Action

Going into Q1/18 after the mania of 2017 ICOs, I assisted the CEO to re-conceptualize the centralized marketplace idea around leveraging Blockchain. I dove into the Blockchain ecosystem, prototyped around Origin Protocol, and crafted the initial beginnings of a White Paper.

As part of that process, I explored options leveraging Truffle…

POC (derivative of Truffle Petstore DApp)

… as well as Origin Protocol.

POC (derivative of Origin Protocol DApp)

As the market cooled, we slowed down towards project planning a gradual transition to a decentralized paradigm.

Result

Contributed to Origin Protocol.

Categories
Leadership Optimization Performance Engineering supply-side

Improving Speed and Conversions

With no-one on staff having formal performance engineering experience or training, I led the effort to address a 6s sitewide page load average. Over approx. 6 months, stealing time from each sprint as I could given other responsbilities, I assessed bottlenecks using performance tools, including procuring a contract for Insights, Browser Pro, and Synthetics.

In a nutshell, assessing some of the pages having a roughly 13s page load, skewing the overall site’s average, I determined that the bulk of the performance issues were in blocking JS libs and then crafted a remediation strategy and established SMART goals for baselining/measuring impact of changes quarter-over-quarter with intent to drop from 6s to 3.5s by the end of 2017. Below you’ll see a spreadsheet I kept, noting the average Page Load Speed every Monday morning. Finally, in May, we address the bulk of the blocking JS libs and reversed the upwards trend.

The CEO was amazed at how much faster the site felt.

Results

  • Intro’d performance engineering, leading to page load speed reduction by one full second and 11% bump in mobile web conversions.
Categories
Architecture Prototyping supply-side

Not Ready for React

(The RealReal : 1/17-2/17)

When I joined, it was with the understanding that as the company was growing, we would need to be splitting out the codebase into a more service-oriented architecture.

In late Q1/17, seeing an opportuntiy to leverage React components to both DRY up and reuse functionality and in a bid to further decoupling frontend and backend, I tasked the remote Russian team with the introduction of React around signup functionality.

When the project was almost complete, an engineering executive required that we pull out React and implement the functionality in a more vanilla way, citing that “any changes that engineering [made] causing the business to potentially miss its numbers would be bad.”

Results

  • Explored (but had to abandon) use of React at TRR.
Categories
eCommerce Innovation supply-side

Hackathon : Browser Extension

(The RealReal : 2/17-2/17)

Results

  • Won “Best Hack” while pairing w/DIR Design to create Chrome Browser Extension (similar to Honey) to cross-sell inventory on related retailers.
Categories
APIs Architecture Backend Collaboration Frontend Innovation SOA SPAs

Next Gen FE

(Bluxome Labs : 7/16-7/16)

Leading the Charge

Upon returning from vacation, I disovered that the VP ENGR gave the recently-joined Team Lead carte blanche around moving ahead with the next phase of re-engnineering the codebase for a further SOA-influenced frontend and backend split.

Being intimately familiar with the current system architecture, in a race against time for Week One (only had a week before VP ENGR wanted Best Practices/new workflows/adoption of new technolgies and because one substanitally differing proposal – likely much more costly from development and operational standpoints – was on the table,) I set out to formulate a concrete strategy towards delivering in the short-term while providing a basis to iterate against a longer-term architectural shift.

Architecting the Solution

First, I advocated for the adoption of the ‘Launch Page’ as the testbed with which to move forward. Then, I reviewed that page in order to reverse-engineer whatever model attributes I might be able to use (in a Backbone model) as exposed by in a simplistic GET request on page load for initial state.

I then modeled that simplistic endpoint using the Swagger Editor

Next, I dumped the YAML of that endpoint and leveraged Swagger code gen tools to create an initial version of the endpoint in Node.js (and Ruby and Java) and fired up that Node.js for serving HTTP requests.

At that point, having proved to myself the utility of Swagger for spinning-up some simple Node.js services, I turned to building out a placeholder SPA using React that would consume a Node.js service. I opted to stay within the Rails paradigm (instead of adopting an approach of statically hosting assets elswhere) and first used react_on_rails to incorporate React and then the react-rails-hot-loader for HMR.

I wound up needing to patch the latter locally in order to get Web Sockets working correctly in my environment.

Having put the Big Rocks in place, I could hand off the SPA POC to the F2E consultant for further refinement and could focus on building more of a case for the overall approach which the VP ENGR then gave his blessing to.

Building the API

During this phase (Weeks Two and Three,) I implemented GET, POST, and PUT JSON-serving routes in Rails (not to have to worry about CORS) while also developing in the context of Amazon’s Lambda and API Gateway, taking the Node.js server stub above and dropping it in as an HTTP Proxy to collate information from existing API endpoints (as microservices.)

I also worked with five backend specialists and my work guided the conversation around establishing Best Practices for API development.

Results

  • Championed bottoms-up approach to decouple microservices, influenced VPE/Team Lead/F2E to adopt, and prototyped using React / Hot Module Reloading
Categories
Frontend Prototyping supply-side

NUX Refresh, Again

Bluxome Labs : 5/16-5/16)

The NUX for the people doing work on the CrowdFlower platform has been around for two years.

Time for a refresh! Given the following from Design

… I set about improving the NUX.

First, I could see the difference in the pre- and post- and decided to remove the dependency on Guiders, a lib that has long served CrowdFlower well. Then, given the design, I saw we could realize the implementation quickly with a Twitter Bootstrap Modal. Going a step further, I also realized it would be the perfect opportunity to introduce React (and even React-Bootstrap) on a small scale in a Rails app where it did not yet exist.

After several copy changes, this was the final Deliverable

(specs were not unfortunately not created in conjunction with the delivered product given the scope they would have added to the original ticket.)

Results

  • Deprecated legacy 3rd party JS lib usage (Guiders) in favor of re-imagined NUX with React component.