Pico

PicoSupportEngineer.md

To start the challenge, I read over the four steps and evaluated where struggles may happen. I felt most uncomfortable about the first step, whereas working within the Pico documentation in steps 2-4 made me feel a bit more at ease.

Add wrapper.local as a local host to your /etc/hosts.

I had never been in the ‘hosts’ file and learned a bit about it along the way. The ‘hosts’ file can override the default DNS information on your system. There are some slight differences in the appearance of the ‘hosts’ depending on your machine. I am using a Mac and followed the guidelines from this explanation: https://www.imore.com/how-edit-your-macs-hosts-file-and-why-you-would-want#page1

I also found this explanation from the NetApp library useful: https://library.netapp.com/ecmdocs/ECMM1278401/html/nag/GUID-DBF81E5C-CF3C-4B07-AF01-83A625F2B4BF.html, In particular the line of: “IP_address host_name aliases”

With this information, I configured my ‘hosts’ file to show this:

127.0.0.1 localhost wrapper.local

This is a bit out of order, but I could confirm that it was reading this as an alias by using the command:

dscacheutil -q host -a name wrapper.local

Which yielded the response:

name: wrapper.local ip_address: 127.0.0.1

Great!

Run the local site container running using docker-compose. You may need to install Docker Desktop

I have Docker Desktop on my machine!

I navigated to where I had cloned the repo down onto my machine and typed in docker-compose.

My machine said, that isn’t enough. It needed to take in some arguments. I went with docker-compose build. Why not?

My response: wrapper uses an image, skipping

Ahh yes, of course. Obviously. Moving on.

docker-compose up seems to be pretty popular, so I went with that.

My response: Creating wrapper.local ... done Attaching to wrapper.local wrapper.local | [Sat Jan 30 18:02:13.179246 2021] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.38 (Debian) PHP/8.0.1 configured -- resuming normal operations wrapper.local | [Sat Jan 30 18:02:13.179600 2021] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'

This seemed good! I went over to the Docker Desktop Tool and saw that the ’support-engineer’ container seemed to be running. Great!

Navigate to http://wrapper.local in your web broswer and ensure you can view the support site.

I navigated to http://wrapper.local in my web browser to ensure I could view the site.

Nothing. No errors. No network calls. Just nothing. Hmm.

At this point, I had confirmed that wrapper.local was a confirmed known alias. I also could tell that I was running the app according to Docker Desktop. I wish that I had a helpful error message to go off of, but there did not seem to be much. I decided that what I would do is dive into the documentation and perhaps some tutorials to determine what I needed to do next.

I saw that an application that I had on my Docker Desktop was running on port 27017 and Docker Desktop was clearly expressing that knowledge. When I examined the support engineer application, it did not have the same tag indicating that it was being run on a specific port. I then spent some time reading into what it meant to expose a port as the docker-compose.yml was exposing 80. I spent some time with this documentation: https://docs.docker.com/engine/reference/run/#expose-incoming-ports, and tried adding tags to docker-compose up, such as -p and -P, but with no avail.

At this point, I decided that I would add a port within the docker-compose.yml file. I initially chose port 5000. This was not a winner. After further reading, the port you expose, must match the port you run on. I then changed the file to point to port 80. Finally, I was making some network calls and was able to see Penny from Inspector Gadget at http://wrapper.local

I had not been this exicted to see her since watching the show, eating Pop-Tarts while getting ready for school in the first grade. I was pumped.

As an aside, the troubleshooting for this problem was not as linear as my description of the events. I spent the majority of my time during this challenge here and went down a quite a few lines of thought, often leading to dead ends. As none of those hypotheses led to committed code, I have omitted them. What did get me to my desired conclusion is the two lines of code in the docker-compose.yml file that point to port 80

I have included a few pictures in the images folder to help visualize my experience. They include:

DockerDesktopRunningWithoutPort DockerDesktopRunningWithPort Wrapper.localWithNetworkCalls Wrapper.localWithoutPortOrNetworkCalls

Load the Pico Gadget!

Review installation instructions for the manual installation of the Pico Gadget

Modify header.php so it loads the Gadget code from Pico's staging environment: https://gadget.staging.pico.tools/wrapper.min.js

Fix any console errors about the publisher ID not being found by editing docker-compose.yml to use publisher c9298a6f-566d-4507-9def-116384264538

When you refresh the site you should see the gadget on the site as it will popup on the screen.

I began step 2 by reviewing the instructions via the link provided and found the helpful information of loading the gadget manually about a third of of the way down the page. I then modified the header.php file so that it would grab the from staging within the script tag. This seemed to be only switching the work dev to staging in the call. Next, I wanted to fix any console errors about the publisher ID not being found by editing the docker-compose.yml file. I did not see any errors in the console. Additionally, the publisher ID was already in the file using the appropriate configuration. I included a screenshot of my console at that particular point in the process in the /images folder (titled Initial Popup) for verification.

Use the Pico Signals feature

Add a new element to the site with signals that will show when a user has registered.

This element can be something simple - like a div with 'Welcome back!' inside. If the user is anonymous then it should be hidden.

I navigated to the Pico Signals documentation and knew that I needed to add an element on the page. I remained in header.php because it was loaded on all other pages and seemed reasonable to complete the exercise within that file. I found a spot in between the main header and the menu button and added a div with the class name PicoSignal which was recommended by the documentation. As the site loaded, a few data attributes loaded onto the site the element, including data-pico-email and data-pico-first-name. Seemingly, useful bits of information for displaying user information. I saw that the data-pico-status was anonymous and figured that I could use that piece to determine whether to display a piece of information or not. In the documentation, I found this helpful script:

div.advertising[data-pico-status="paying"]{display:none}

I changed it to:

div.PicoSignal[data-pico-status="anonymous"]{display:none}

I then added it to my CSS file and it worked! I found the documentation to be especially on point during this exercise.

Add custom triggers to the site.

Add a custom trigger (button) that will open a registration prompt. The registration prompt will look similar to:

Add a custom trigger (any html element) that will open a payment prompt for a specific plan. The element will need to have class="PicoPlan_XXX" (where XXX is the short code for the plan).

HINT: You can find the short code by inspecting the POST response from https://api.staging.pico.tools/loader/guest. The key is short_code and will look like 1a23bcde. It has 8 characters with numbers and letters.

Add a payment prompt as well.

I navigated to the custom triggers documentation and, once again, found the Pico documentation to be extremely useful. I decided to add two button elements directly below the 'Welcome Back' div in the html. In order to add custom triggers, I again needed to add a class to the html. The payment plan required the PicoPlan class and the registration required the PicoRule class. I also took a peak at the network calls regarding the https://api.staging.pico.tools/loader/guest call. I received a large JSON object which I parsed and took a screenshot of, which is included in the /images folder I have included. I then decided to sign up and register for the plans and found them to be very easy to use! Once I signed up, the 'Welcome Back' div that I had made in step three appeared, as I was no longer anonymous. Also, a chatbox came into view that gave me access to my profile. I deleted my account and added it back a few times to make sure I understood the behavior. Afterwards, I signed up for the payment plan and got some helpful messages during this process as well! I tried to take a few screenshots of the events here and added them to the /images folder as well. They are:

ButtonsWithResponse MonetizationWithWelcomeBack NotificationsAndWelcomeBack Registration Popup ShortCode

(Quick aside: the short code photo is the JSON response parsed out via an online parser with the short code highlighted. The Registration popup shows no 'Welcome Back!' div demonstrating that the user is 'anonymous' at that point until they sign in. The 'Welcome Back!' can be seen in other photos after I have signed into Pico!)

Stepping away, I found this to be a healthy challenge. I struggled in the beginning a bit, but as I set out, I anticipated the setup to be the murkiest. In the end, I learned some new information about the etc/hosts file, as well as, some new information about Docker configuration. From there, I found the challenge to be pretty smooth sailing due to the well-written Pico documentation.

I would love to talk about my experience and answer any questions you may have about the way I undertook my approach soon! Thank you so much for the opportunity to take this on and for embedding the Inspector Gadget theme song in my head all weekend, hahaha.

Thanks again! --Greg