Computers require a set of fonts to be installed on their machine in order to render them and for this reason, relying on
font-family is problematic. We want to make sure that everyone gets the same experience of the fonts. However, if they do not have the fonts specified in the css properties installed on their computer, then their browser will just render the site with the default fonts available on the local machine -- making your site look look inconsistent across devices. To get around the local installation problem of fonts, Google Fonts have a large reservoir of fonts to choose from, and will give you more options in allowing most people experience the font-family that you set in your CSS.
Google Fonts hosts these fonts online. When we link to them in our
head the browser pulls in the font asset from the network so the browser can have access to the font family specified in the CSS. When pulling in your fonts from google fonts, you want to specify the font asset link first and definitely before the link to pull in your CSS:
display property of a CSS element is foundational to understanding CSS. In this post, we will continue building up our foundations from the previous post by examining the
display property and understanding a bit more on how to properly style buttons and links.
More often than not, developers and non developers alike believe HTML and CSS is easy. In revisiting the fundamentals of HTML and CSS, there are important foundational characteristics to note, which may be surprising to even very experienced frontend developers.
Sure, there are aspects of HTML and CSS that can be relatively easy to learn at first with a “monkey see; monkey do” approach. The feedback one receives in writing HTML / CSS is instant. Just reload the browser and gaze at your yellow square on the page. Now let’s center the yellow square. See! Easy.
For this site, I have a local set up which allows me to add new features as well as publish content like this very blog post you are reading. In part 1 I showed you how the site is set up in the cloud with AWS services like S3, ACM, Cloudfront and Route53 . In this post I will show you how I add new features to my site, deploy changes and add content like this very blog post.
At a high level my local set up includes:
Intro: Watch out! This is a long post and most likely will be updated over time as I go through the motions of setting up a site as I describe below with a friend. If any of the below information is inaccurate or unclear please email me at the information provided under about / contact.
As an application developer, I am very comfortable with local development. Once I have an app or a technology installed and set up -- the set up on my computer or the configuration harness for the technology is usually the hardest part for me -- I am good to go. Once I have what I need running on my machine, I am ready and excited to start developing. However, when it comes to managing software in “the cloud”, I can get a little nervous because managing infrastructure is not my strongest suit.
This great article discusses how either avoiding conditionals entirely or refactoring them out of an application can make a codebase easier for developers to understand and change. To expand on how
culling conditionals with abstractions not only works in terms of implementation but also improves the cleanliness of a codebase, we will take the same examples from the above article, modify them slightly and provide a detailed implementation of the abstractions working together.
Hopefully, this demonstration will make the message more clear on why conditionals can add unnecessary complexity and confusion and how removing them with abstractions will create a simpler and more flexible solution. Moreover, further detailed examples will bring into the discussion the tradeoffs a developer must consider when
culling conditionals with abstractions.