Building a Crypto Weed App: Part 4 - Pretty Things

A walk through, turning a website without CSS into something people want to look at, are able to find online, and have documentation about.

If you are new to this series about building a crypto weed app, hello. I am a STEM teacher, curious about crypto, weed enthusiast, and wannabe programmer. This account is a place to experiment with my work and keep me accountable while I learn. Specifically, I am on the road to building a crypto oracle for weed prices. The recap:

• The Proposal

• Part 1 - Working Anonymously (first paid post, WIP)

• Part 2 - Barebones API

• Part 3 - Going Live

This is also the first post that I am writing in Substack. The others linked above were all copied from Patreon. Substack definitely seems superior in ability to embed code and other text elements.

Today, we are starting with a working API and website. We aren't going to add any backend features to the API. Instead, we will make the website look nicer and add documentation so that people will want to, and know how to use it.

Pretty Things Requirements

As always, it is important that we specify exactly what needs to be done. I don't know about you, but I know if I'm not clear upfront, my brain wanders and I end up having wasted hours looking at lots of shiny things but not actually doing anything.

Our requirements for making things pretty are below. Where possible. I will include links to relevant commits for that feature.

• Work on feature branch with PR instead of commits into master [github]

• Wireframes drawn before code written [figma]

• Use Twitter Bootstrap [github]

• UI has links to: substack, patreon, github [github]

• Setup a favicon [github]

• Responsive design optimized for: xs and lg screen sizes [github]

• API documentation (docs.cluutch.io?) [github]

• Quote forms not touched because not seen by public

• SEO: robots.txt, tags, submit to search engine [github]

• Analytics [github]

• Logo attribution [github]

Notice that its not only UI components, that are part of the application’s beauty. Its code, documentation, SEO, and process are just as important.

A requirement that was ultimately left out was moving the frontend to React or Angular. Although js based frontends are cool, the app is too nascent for js to be useful. I would rather spend time migrating to a different frontend if this project gains traction, than risk losing momentum by switching tools before its even gotten off the ground.

Wireframes [figma]

Typically, I’m open source everything. For Cluutch, I want to try optimizing for output. Sure, this is a crypto weed app at the end of the day, so decentralized and liberating values are important to keep in mind. But as long as I don’t feel like I’m killing baby seals, I’m fine using proprietary tools for this project. Enter: Figma.

Pretty much any wire framing tool would work for the fidelity I’ll be using things. Figma is popular, backed up in the cloud (I use multiple computers without a good file sync), and free to use for small projects. Here are bare bones mobile and desktop designs.

cluutch.io webpage: desktop

cluutch.io webpage: mobile

Twitter Bootstrap [github]

Twitter Bootstrap solves basic CSS and layout problems. No need to reinvent the button and dropdown wheel. The bootstrap-rubygem documentation is pretty good. Follow their instructions to install bootstrap:

# Add to Gemfile
gem 'bootstrap', '~> 5.0.0.beta1'

Then, remove all the *= require and *= require_tree statements from the Sass file. Instead, use @import to import Sass files.

Do not use *= require in Sass or your other stylesheets will not be able to access the Bootstrap mixins and variables.

# Rename application.css
mv app/assets/stylesheets/application.css app/assets/stylesheets/application.scss

# Add to app/assets/stylesheets/application.scss  
@import "bootstrap";

Unfortunately, I hit some snags running Rails 6 and Bootstrap 5. The biggest blocker was that I wasn’t able to get the javascript building correctly. To get around this, I load the js from CDN.

A new homepage [github]

The current homepage redirects to the quotes controller and displays all the historical weed prices with default Rails styling.

This is a far way off from the desired homepage from Figma. Let’s get started.

1. Remove redirection:

   app/controllers/pages_controller.rb
   @@ -1,5 +1,4 @@
    class PagesController < ApplicationController
      def home
   -    redirect_to action: "index", controller: "quotes"
      end
    end

2. Add a navbar

   • Pro-tip: Read the migration notes. ml-auto is now ms-auto in Bootstrap v5. This can be used for pulling navbar item right.

3. Update theme colors by defining new colors above the bootstrap import in application.scss.

   // app/assets/stylesheets/application.scss  
   
   $primary: #920258; # colors copied from figma
   $secondary: #E5E5E5; 
   $light: #FFFBFB;  
   @import "bootstrap";

4. Update navbar text color:

   nav.navbar ul.navbar-nav a.nav-link {
     @extend .text-primary
   }

API documentation [github]

At this point, all the scaffolding for the homepage has been setup. Building out the documentation is just a matter of writing some copy and sensible formatting.

At this point, a few fields were removed from the API response. The `url` field was wrong and the others were not adding any consumer utility at this point (though ID will be useful in the future).

• Removed: url, id, created_at, updated_at from response

Favicon [github]

Favicons are the little icons in each of your browser’s tabs. Mine is really hard to see and needs to be improved. These are the steps I followed so far:

1. Upload icon to favicon.io

2. Follow instructions to download output

3. Copy contents of downloaded zip to the rails project public/ folder

4. Modify application.html.erb to add favicons:

   <link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png"> 
   <link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png"> 
   <link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png"> 
   <link rel="manifest" href="/site.webmanifest">

Robots [github]

A robots.txt file is a way that you can tell search engines like Google to include or ignore parts of your website from their results. In this case I want to be very permissive and expose the entire website.

The default Rails robots.txt points to this helpful reading from robotstxt.org. This is how to allow all pages to be crawled:

User-agent: * 
Disallow:

Meta tags [github]

When you Google meta tags rails, meta-tags is the first gem you will find. Its very easy to add to your project. I decided to set the tags through my controller although several methods are supported.

class PagesController < ApplicationController
  def home
    @page_title       = 'API for weed prices'
    @page_description = 'An API for the price of weed/marijuana, pulling from legal dispensaries and the darknet. Long term crypto oracle.'
    @page_keywords    = 'Weed, API, Marijuana, Crypto, Oracle, Market, Price'
  end
end

Analytics with Matomo [github]

Sandstorm is a fantastic service that makes it easy to self-host lots of open source tools (Etherpad, Gitlab, Draw.io, etc). Piwik support is also included. That said, I didn’t feel like setting up a whole new Sandstorm instance just for this work.

Piwik is now Matomo. Matomo offers a 21 day no credit card trial of their cloud offering. Given I’m not sure if I’ll still be dedicated to this project in 3 weeks, that is a great deal for me.

It was extremely easy to setup a Matomo account with only an email address. The embed code can be dropped into application.html.erb and that’s it. Although Matomo Cloud will cost after the trial, I’d rather own my data than give Google Analytics or another free provider access.

Test deployment

Skipping over some details, the app is ready to deploy at this point. But as-is, there is an order of operations problem.

• No staging environment exists, so I have to deploy to production to test the code.

• Should not merge PR into main until code is fully tested.

• Heroku is setup to deploy from main only by default

To overcome this, we can tell heroku to use the feature branch:

git push heroku part-4/pretty-things:main

And when the PR is merged, force push to deploy from main again.

git push -f heroku main:main 

Submit to Google for indexing

This page details two options for getting Google to crawl/index your new website. I chose to use the URL Inspection tool. During the sign up process, you’ll be asked to add a TXT record to your domain.

Once verified, select REQUEST INDEXING from URL Inspection.

Within a few hours, you should see some results.

What’s next

It has been fun working on this. But it is extremely time consuming to code and document the process at the same time. The scope of the next segment will need to be more focused.

With the bulk of the structure in place, next week will focus on the actual calculation of marijuana price. There are so many problems with the methodology, the current values are almost meaningless.