Category Archives: Project Log

A collection of web development projects I’ve done for the organizations I’ve worked with.

Chatbot with Microsoft Azure

In lieu of SleepScore Labs newest sleep solution, SleepScore App, our Customer Service team wanted to create a chat alternative to support this product launch.

Over the course of three furious weeks (one to vet out the needs, and two to build), I worked one-on-one with our Customer Service Manager on outlining the bare minimum of what we’d really want in this type of feature.

It’s safe to say, that you can get trapped inside of a rabbit hole fairly quickly with ideas but after easing in a bit our solution was to design an FAQ (Frequently Asked Questions) Chatbot.

We took as much existing data we could from previous customer service engagements, organized them a bit and indexed them within a Web Service called QnA Maker. I connected that dot to a Microsoft Azure Bot Service as a NodeJS Web App and published it to a channel called Live Assist.

A NodeJS chatbot powered by QnA Maker, Microsoft Azure and channel, Live Assist.

Housed entirely inside of Microsoft products, I was for the most part impressed on how straightforward it was to put all three together to build out something real customers could actually engage with. There was no additional coding on my part and getting to the finish line on time was in itself a win.

If you ever wanted to try building this out yourself here’s the bare minimum you’d need:

  • QnA Maker: which will index your questions and answers and open an end-point for your web app (chatbot) to consume.
  • Azure Bot Service: which is actually how you create the chatbot.

The optional requirement here is the channel. Building out a chatbot requires you to point your chatbot to a channel. In our case it was Live Assist because that was the requirement. But this could easily ship to other channels like Facebook, SLACK, etc.

I’ll be making a follow-up post to this for the most part as a retrospective to outline the journey and its gaps to this implementation in hopes that one day I have the opportunity to make more improvements at this first pass on building out a chatbot.

Thanks to, Microsoft Developer US for getting me started.

SleepScore Labs Data Dashboard in Angular 2

In April of 2017, I was tasked with design and development of a data visualization dashboard for new customers of SleepScore Max, a non-contact sleep improvement system. Designed for both iOS and Android users, my role was to build a web application which would compliment this sleep solution experience by connecting the dots between sleep data and pragmatic advice in a more robust fashion.

I took it upon myself to go head first into Angular (granted my previous experience with AngularJS) but I got a first-hand view of how different both JavaScript frameworks were.

SleepScore Max login page written in Angular.

SleepScore Max login page written in Angular.

I kickstarted this project prior to the full standardization of Angular CLI so I was pretty much left to my own devices on how to properly build and deploy this application into a cloud instance.

I credit PluralSight author Deborah Kurata as the initial key to making this project work. Specifically, her course in Angular: Getting Started was a jaw-dropping course on Angular’s moving parts. Needless to say, now that I have both AngularJS and Angular perspectives, my best assessment on distinguishing between AngularJS and Angular is that while AngularJS thinks of drafting features from controllers and scope, with Angular you need to abstract those things via components.

To dumb it down for me, I’ve come to think of a component as simply a web page (the overall object), while the super powers you write inside of that web page act as the methods and properties of that web page. Coming to that conclusion wasn’t linear. I needed to dive into TypeScript since it is the driving force in authoring modern Angular apps.

I’m still tinkering with TypeScript and have a long way to go to understand its full value but I definitely became a fan simply because it makes a JavaScript author a bit less error prone. Let’s face it, web browsers are still running JavaScript in ES5 and not ES6. Having that superset above JavaScript to reinforce little things like the data-type of an object is awesome and learning how to write a component in TypeScript helped reinforce how I’ve dumbed down the difference between AngularJS and Angular.

A splash of jQuery animation for the sleep score petals, CSS styling to chart out the breakdown all inside of an Angular dashboard.

A splash of jQuery animation for the sleep score petals, CSS styling to chart out the breakdown all inside of an Angular dashboard.

Yes, this dashboard is also responsive.

Yes, this dashboard is also responsive.

What’s next? I’m already thinking about the upgrade path into Angular version 5, smoothening out continuous integration and making Angular CLI the gold standard for facilitating all portions of this project.


Responsive Web Design for

3 years ago, Thermo Fisher Scientific (previously Life Technologies) was tasked with enhancing its original mobile experience integration which leveraged Moovweb’s cloud platform. It was a good solution in getting the domain introduced into browsers outside of desktop, specifically mobile and tablet devices but it certainly came with its own set of constraints.

While Moovweb was an excellent platform for enhancing on mobile conversion rates it came at the cost of scalability and ease of maintenance. The overall platform required you to maintain two separate codebases—your desktop HTML and Moovweb’s SDK, which effectively transformed your HTML into mobile-friendly elements. It was also a page-by-page type deal. Every page would require its own transformation. Every transformation was its own subset of code. The first two waves for those previous projects had the strictest of intentions on mobile-optimizing eCommerce related workflows for all regions but in English only (e.g. checkout flows). It was not enough. The domain needed more flexibility in a web property that could display well to a majority of legacy and evergreen browsers as well being agnostic of device type.

Because of these limitations the Responsive Project for was designed to effectively address the following constraints:

  • Reduce dependency on additional vendor code.
  • Generate mobile, tablet and desktop experiences from one codebase.
  • Scale solutions which would be available globally and not just page-by-page.
  • Responsive interfaces for all regions, all languages.
  • Extend the experience beyond eCommerce: content authored areas and channels outside of B2C.

The domain is huge and its attached ecosystem is a collection of multiple applications owned by multiple teams with their own standard of implementation. Adding to that loophole, not every application in the domain was a candidate for this new responsive experience. From June 2016 and forward, our team had to break features down into chunks.

It was agreed that the header, navigation and footer would be the first to address as this was considered the foundation for everything else to work. Each app would rope this subset of components based under their back-end constructs (e.g. Java, ColdFusion, etc.). This took 3+ months. Not an easy feat if you consider the amount of tooling currently being offered from these areas. You have a series of controls for search tools, commerce and deep links into areas such as login and Order Support.

Real estate doesn’t come cheap with smaller screen sizes. The basics needed to be in order first. In essence, an organized CSS media query strategy for an agreed set of breakpoints and a baseline approach for DOM manipulation in the event this choice ever needed to be made.

Listed below were some saving grace plugins, libraries and frameworks from the open source world which allowed us to get our job done:

  • Bootstrap 2.3.2 – the overall HTML, CSS and JS framework for delivering responsive enabled user interfaces. Keep in mind that support for legacy browsers in IE8+ was priority. Also, since the domain is driven from a desktop-first approach this framework was still considered standard.
  • jQuery 1.8.1 – a minor upgrade path for better DOM selector performance. Originally, 1.8.0 was elected to be the global jQuery library available but that caused problems for older Internet Explorer browsers with .ready() firing prematurely. See jQuery defect 12282.
  • Responsive HTML Tables – a CSS technique which turns table elements into div blocks with labels being controlled through data attributes.
  • TableHeadFixer – a jQuery plugin which was modified in-house to give content authors more flexibility in drafting HTML tables with features such as locked table headers or columns.


Mobile Optimization Project:

In the summer of 2014, I was contracted and assigned to develop the mobile experience for Life Technologies.

Life Technologies Homepage in Mobile

Life Technologies Homepage in Mobile

Partnered with Moovweb, we were able to generate mobile optimized workflows from high-traffic areas like Homepage, Cart/Checkout and PDP. Several mobile optimized workflows were developed fairly quickly and we successfully launched in all regions (English only) in January of this year.

Client and vendor teams were geographically split, yet worked in unison to accomplish this project at the expected go-live date. The desktop experience is transformed with Moovweb’s SDK and deployed to their cloud infrastructure. This allowed front-end development teams to start the project fairly quickly without too much reliance on back-end development support.

The next challenge relies heavily on building and maintaining the experience while integrating their tech stack w/in Thermo Fisher Scientific standards.

Visit on iOS or Android mobile browser.

Apply a Rewrite Directive to a Solr Instance

After exposing the Solr endpoint with a reverse proxy, it’s important to note that it also exposes the Solr admin panel to the end-user. This is not desired.

Flowchart of a RewriteRule directive that rests on’s httpd.conf file.

Flowchart of a RewriteRule directive that rests on’s httpd.conf file.


  • Solr’s admin panel becomes exposed from the reverse proxy.


RewriteRule ^/solr/$ / [R=301,L,DPI]

Reverse Proxy a Solr Instance

It’s encouraged that you secure your Solr instance by placing the application on a different file server and behind a firewall. That’s an issue if you are trying to consume data from the Solr instance leveraging AJAX techniques.


Flowchart of a reverse proxy directive that rests on’s httpd.conf file.


  • and Apache Solr live on separate boxes.
  • A firewall protecting Apache Solr plus the cross-domain issue does not expose the necessary end-point to consume via AJAX.
  • Depending on your sys admin setups, Solr may not live on a fully qualified domain (ie.
  • An AJAX call to consume the Solr instance’s JSON/XML won’t work cross-domain.


  • Reverse Proxy directive, mod_proxy – Apache HTTP Server
  • This allows for an endpoint that is visible to the browser and we can consume the JSON/XML that rests within the Solr instance.

ProxyPass /solr
ProxyPassReverse /solr

Don’t forget to apply a RewriteRule Directive to protect the Solr admin panel, once you’ve exposed it to the browser!

Simple PHP Proxy returns incorrect JSON from Apache Solr instance

I’ve implemented Ben Alman’s simple-proxy.php to communicate to an Apache Solr instance (in this case my local) outside of my domain.

I’ve followed the instructions in full, the core of which is to set the simple-proxy.php on my domain’s file server.

I’m curious on if there are any modifications that must be made to the proxy in order for the response to be in the correct format?

View on Stackoverflow.


Page speed seems to be one of the bigger priorities as of late and I was designated with the RND task in making one of our subdomains, a bit…faster. In summary, this is a single-page design intended to support our Marketing campaigns during the 2014 Winter Olympics.

In one sprint (2 weeks in my case), we were able to set some benchmarks and reduce our network requests, optimize our images, minify our CSS, minify our JavaScript, compress and cache our assets by tweaking our server-side configurations.

The before benchmarks are listed below for 03/19/2014 unless otherwise stated:

  1. Google PageSpeed – Mobile: 55/100
  2. Google PageSpeed – Desktop: 71/100
  3. Y-SLOW: 67/100
  4. Network Requests: 112 (03/21/2014)

The after benchmarks are listed below for 03/27/2014:

  1. Google PageSpeed – Mobile: 64/100
  2. Google PageSpeed – Desktop: 83/100
  3. Y-SLOW: 79/100
  4. Network Requests: 87

Tools and methods I used to compliment our page speed via server-side:

Tools and methods I used to compliment our page speed via client-side,:

I still have some items to solve—Youtube iframes ultimately being the culprit. Getting into a 1-second threshold with mobile is another instigator. I’m suspecting a JavaScript solution is on the horizon but we shall see.

Apache Solr + University of Rockies

Search Engine Apache Solr added to

Search Engine Apache Solr added to

In the Fall of 2013, my team was tasked with R&D on integrating a search solution within the University of Rockies. Starting from the ground up, we pursued the idea of open-source search server, Apache Solr. After hours vetting out a workflow and experimenting, we were able to create a search product that not only touches base with Rockies, but can be extended to other web properties owned by the Marketing Group.

Some keypoints we put into consideration were the following:

  1. Search results….what type of results should we expose?
  2. Crawling and indexing…how do we crawl our domain and index our results?
  3. Web security…what standards do we need to put in place granted our search server is open-source?
  4. Third party dependencies…can we bring application ownership in-house?
  5. Future maintenance…what is our SOP and response time as the domain’s content changes?
  6. Technology Services protocols…what moving pieces are pertinent to change management guidelines, etc.?

The official release of UoR search went live in December 2013 and continuous improvements are slated throughout the year, so stay tuned. For now, feel free to explore this feature at,

Crawl Metatags with Nutch 1.7

In regards to the Stackoverflow recommendation on enabling the metatag plugin, I came across a roadblock when I had to merge this solution to my integration of AJAX Solr. Unfortunately, taking the recommendation at face value caused a JavaScript error of undefined when accessing the the meta tag key/value pair from the JSON object. Granted the recommendation chained metatag.description together, it interpreted metatag to be an object that did not exist.

Reviewing the key/value structure of JSON, I came across this discussion on Parsing JSON with hyphenated key names, I thought the same would hold true for mine. That said, I’ve augmented the Stackoverflow suggestion slightly to leverage underscores versus dot syntax and came up with the following:

/* For schema.xml on Nutch and Solr */
<field name="metatag_description" type="text_general" stored="true" indexed="true"/>
<field name="metatag_keywords" type="text_general" stored="true" indexed="true"/>

/* For solrindex-mapping.xml on Nutch */
<field dest="metatag_description" source="metatag.serptitle"/>
<field dest="metatag_keywords" source="metatag.serpdescription"/>

This was implemented on Nutch 1.7 on a Solr 4.5.0 instance.

Please refer to the following for context:

  1. Extracting HTML meta tags in Nutch 2.x and having Solr 4 index it
  2. Parsing JSON with hyphenated key names
  3. Nutch – Parse Metatags