DEV Community: Jarret Bryan

Getting Started with Gatsby

Jarret Bryan — Sat, 20 Oct 2018 00:37:14 +0000

So a little while back, I wrote about the basics of starting a site using Jekyll. I built my first personal site using Jekyll! I really liked the simplicity.

But times have changed. Tastes have changed. I'm rebuilding my site, and this time I'm using Gatsby!

Like Jekyll, Gatsby can be used as a static site generator. It's great for portfolio sites, blogs, personal sites, etc. And static sites are easy to deploy using Github pages, Netlify, Surge, etc. But what makes Gatsby particularly exciting for me is its a site generator for React.

If you know React, if you've used React to build build a dynamic web application, you already are in business - Gatsby is using the React library.

So like I did with Jekyll before, let's do a quick run through to get started with Gatsby.

Assuming you have Node and Node Package manager all set and ready to go on your machine, let's jump into the command line, and install Gatsby's CLI tool, and generate a new site.

$ npm install --global gatsby-cli
$ gatsby new my-new-site https://github.com/gatsbyjs/gatsby-starter-default

Our first line here just installs the Gatsby CLI package on our machine. Our second line is the interesting bit here:gatsby newis our command to generate a new site. 'my-new-site' will be the directory name that's generated. And inside this directory we'll have all our tools to get started. And that URL at the end? That's our 'starter'. A starter is essentially a theme, or a template for our site.. We're using the default here.

Here's the file structure that we're given:

It looks a little more complex than a Jekyll set up!

At this stage we can use a whole set of commands that Gatsby provides us with.

gatsby develop - This will set up a local development environment that reloads on every change!
gatsby build - This will generate a production build, your static site, to deployed at your service of choice (surge, Netlify, etc.)
gatsby serve - This will set up a test environment for your built site.

Let's focus on gatsby develop - run this one, and you'll have a server started at Localhost:8000. Mine looked like this!

All of this content was provided to us using the default Gatsby starter? So how do you drill down and actually do some editing? You can go straight to the src folder, and edit the components, just like any old React App! To illustrate, I'll add a very basic component.

If you're unfamiliar with React Components, the quick, sloppy explanation is it's just a Javascript function that returns HTML. It's a little more than that, but that will do for our purposes.

So our default layout looks like the below:

I'm going to create a new .js file in our src/components folder to build this example component like so:

(Note that I imported React to build this component! It's all just React.

Then let's import my new Example Component into my index.

That was pretty easy! And what does our site look like now?

Ok... so it's not the prettiest - but we see how easy it is to build HTML content and place it on our page! And just like React, we can pass down props to children Components, import libraries, build class based components or functionals ones, and so much more.

I'm currently building a new portfolio site, so here's a peak at the work in progress, built using Gatsby:

I'm not done! It's a work in progress. But this was so easy to make because of the modular component structure of the React library, and the flexibility it offers me. It's a simple paradigm, but an incredibly powerful one and lends itself to so much customization.

When I'm ready, I'll run gatsby build which will generate a public folder - and I can deploy that to the static service of my choice! It's really that straightforward.

Dig into the Gatsby and React docs below, and get building!

Gatsby
Gatsby Tutorial
React
React Components

Byte-Sized: .env Keeping things Secure

Jarret Bryan — Tue, 31 Jul 2018 12:53:39 +0000

I spent a little time recently looking into how to build a twitter bot with JavaScript; it's actually not super difficult - but it's definitely worth exploring the ethics, intent, potential and ramifications around - but I came across something that I hadn't been familiar with - .env files.

I have my bot projected situated on glitch.me - and the project I remixed already had a .env file included. But I wasn't entirely familiar with the idea.

Glitch is fantastic as a community and a project that I could fork a repository and receive a blank .env file - providing me with the template without betraying the previous repository owner's content and secrets.

But... what is a .env file? And why do I have on Glitch for a twitter bot?

So .env files are the solution to the problem of - how do I keep my APIkeys secure.
I need to talk to the TwitterAPI to make my Twitter bot. But the case for many APIs is just that I would need a secure key to talk to the API. And that key needs to stay secure - I can't just post that to a public repository on Github for the world to see. Anyone could grab it and use it.

Quick solution is the dotenv npm package - Glitch allows me to have the package on their site, but let's say I'm working locally in JS. Quick install:

npm install dotenv --save

Now that I have the package, I require it as early as possible in my program:

require('dotenv').config()

And now I can have my APIKey, set in an .env file -

echo "API_KEY=secure_API-key_here" >> .env

And if open up that file, I can see my secure API key, and it doesn't have to be situated in the other files in my repository. I'm in business! dotenv is going to look for a .env file, and when I run my the required .js file for my application, dotenv will read the .env file and make its contents available to my process as an environment variable. I can access that variable with

process.env.API_KEY

And if I add my .env file to my .gitignore file, I don't have to commit my secrets for the world to see. Keeping my keys secure, and allowing my code to function.

Again, I first game across this in the context of Glitch.me. Glitch.me by default keeps the .env file secure - so even if other users view your code, they don't have access to your secure keys. But your program still does!

Learning About Dat Protocol and Decentralization

Jarret Bryan — Tue, 17 Jul 2018 13:17:16 +0000

This past Sunday, June 15, I got to attend a skillshare hosted by the Distributed Web of Care initiative. This session included a workshop on Black Feminist art criticism, spearheaded by Jessica Lynne, and a workshop on accessbility spearheaded by Shannon Finnegan. For the last portion Callil Capuozzo gave a brief 20 min introduction to using the Dat protocol, so I'm going to try to quickly summarize what I've begun learning from that workshop here.

So the (very) quick and dirty summarization of the web in it's current form is that most information is shared in a top down hierarchal fashion from server to client. Things like applications are hosted on remote servers (the cloud) which allows the browser to act as just an interface to access data that is held elsewhere. And we access this data generally using http protocol. This works well for a lot of things, and is generally a successful model but is not without its downsides. Among the downsides to the data being held elsewhere is the potential lack of ownership or privacy over the data that is held. And for things that are inherently user to user, like sending an email, or sending a file, we involve a third party (the server).

This image is sourced from Paul Frazee's presentation on the Peer 2 Peer Web at PDXNode on September 14th, 2017.

The Dat protocol can be thought of an alternative to the http protocol that works on a Decentralized Web to circumvent this problem of server centralization. Decentralization pops up in many forms, notable WebRTC, Blockchain, or IFPS protocol.

Dat in laymans terms is like if git and bittorrent had a child.

The abstract of the whitepaper for Dat has the following:

Dat is a protocol designed for syncing folders of data, even if they are large or changing constantly. Dat uses a cryptographically secure register of changes to prove that the requested data version is distributed. A byte range of any file's version can be efficiently streamed from a Dat repository over a network connection. Consumers can choose to fully or partially replicate the contents of a remote Dat repository, and can also subscribe to live changes. To ensure writer and reader privacy, Dat uses public key cryptography to encrypt network traffic. A group of Dat clients can connect to each other to form a public or private decentralized network to exchange data between each other. A reference implementation is provided in JavaScript.

Dat files are distributed peer 2 peer, with networked users contributing bandwidth by rehosting files, and anyone can publish from their local machine. Like bittorrent, the more people who are networked to host a file, the larger the network swarm, and the more bandwidth load is shared among the swarm - which allows another party more resources (more servers) to receive bits of the same dataset from.

Anyone can get set up with dat very quickly:

If you have node and npm already installed, installing dat is fairly simple - run the below in your Terminal to install dat on your system:

npm install -g dat

Then you'll want to share a file. So let's say I want to share a folder of all my poems with my friend Brad. Really quickly, from my Terminal let me make a folder of .txt files.

$ mkdir great_poetry
$ cd great_poetry
$ touch deep_poem.txt
$ profound_poem.txt

And let's pretend I've populated the text files with deep and profound text. And I want to share them now. With dat, within the directory, all I have to do to share it, is enter 'dat share'

$ dat share

dat v13.11.3
Created new dat in /Users/jarretbryan/great_poetry/.dat
dat://71978b78f44efe013e3d34642bd8e4efb7b40e1a83202408ecaa06d5fef4357e
Sharing dat: 2 files (62 B)

0 connections | Download 0 B/s Upload 0 B/s

Watching for file updates


Ctrl+C to Exit

And that will initialize a dat repository for me. Essentially, dat share has created a set of hidden metadata files like the below, which will maintain the encrypted key and the version history - essentially if the files are changed. It will simultaneously have my computer act as a miniserver to host the file.

If files are changed from the source, the data updates for everyone rehosting this particular document or set of documents, but the previous versions of the data are not maintained - only the fact that the data was changed, making dat dynamic without overburdening the users. Only the source user can edit the files, but any networked user can copy the files, edit them, and then rehost them with a different encrypted key.

The important bit here now is the line

dat://71978b78f44efe013e3d34642bd8e4efb7b40e1a83202408ecaa06d5fef4357e

This is the encrypted key that points directly to the files. If Brad wants to see my poetry, all he has to do is run in his terminal -

dat clone dat://71978b78f44efe013e3d34642bd8e4efb7b40e1a83202408ecaa06d5fef4357e

and he will receive the files directly from my hosting computer, and also simultaneously begin rehosting them. Now we share bandwith. Now let's say our friend Alex has heard all the fuss about these profound poems and also wants to receive the files. All Alex has to do is run the same 'dat clone' command, and she will receive the files from both Brad and I, as long as we both are hosting. She then will also begin rehosting the files. And if our friend Kurt wants access to the files as well, the process repeats, and he will receive bits of the data from Brad, Alex, and I. So the process scales with the user - the larger the network swarm, the more the bandwidth is shared.

We can see in my above block of code that reflects the hosting that there are 1 connections, but that number will reflect the number of users currently connected.

At no point in the process are the files hosted on a centralized server - they are distributed among the networked users. And as long as someone is hosting the files, they will be accessible - so I, as the original hoster, can stop hosting for a bit, but in theory there is still access to the networked files, even if they don't reflect changes that I've made locally.

The example I've given is fairly simple, using just .txt files but - imagine if I instead host .html files? I can host an entire website, or conceivably an entire application via a decentralized web.

Getting Started with Jekyll

Jarret Bryan — Tue, 03 Jul 2018 13:54:41 +0000

I started working with Jekyll this weekend past; it's exceptionally beginner friendly, and it's essentially just a tool to build out static sites and blogs. It's built off of ruby and can run its own development environment, so it's very easy to make changes and see them rapidly.

I thought it would be a decent enough staring point since to date, my first experience with Ruby web frameworks was Rails - this is far more lightweight - to the point that making an analogy with Rails actually makes no sense. Since it's so simple, there is no model or database management. Essentially, Jekyll uses a combination of Markdown, HTML, CSS and a template language "Liquid" to render the sites.

Setting up is very fast - let's assume you already have Ruby ready to use on your machine.

In the terminal I simply ran

$ gem install bundler jekyll
$ jekyll new blog-post-site

where 'blog-post-site' was just the name of the new directory that I was making. That generated a whole lot for me:

 Bundler: Fetching gem metadata from https://rubygems.org/...........
  Bundler: Fetching gem metadata from https://rubygems.org/.
  Bundler: Resolving dependencies...
  Bundler: Using public_suffix 3.0.2
  Bundler: Using addressable 2.5.2
  Bundler: Using bundler 1.16.2
  Bundler: Using colorator 1.1.0
  Bundler: Using concurrent-ruby 1.0.5
  Bundler: Using eventmachine 1.2.7
  Bundler: Using http_parser.rb 0.6.0
  Bundler: Using em-websocket 0.5.1
  Bundler: Using ffi 1.9.25
  Bundler: Using forwardable-extended 2.6.0
  Bundler: Using i18n 0.9.5
  Bundler: Using rb-fsevent 0.10.3
  Bundler: Using rb-inotify 0.9.10
  Bundler: Using sass-listen 4.0.0
  Bundler: Using sass 3.5.6
  Bundler: Using jekyll-sass-converter 1.5.2
  Bundler: Using ruby_dep 1.5.0
  Bundler: Using listen 3.1.5
  Bundler: Using jekyll-watch 2.0.0
  Bundler: Using kramdown 1.17.0
  Bundler: Using liquid 4.0.0
  Bundler: Using mercenary 0.3.6
  Bundler: Using pathutil 0.16.1
  Bundler: Using rouge 3.1.1
  Bundler: Using safe_yaml 1.0.4
  Bundler: Using jekyll 3.8.3
  Bundler: Using jekyll-feed 0.10.0
  Bundler: Using jekyll-seo-tag 2.5.0
  Bundler: Using minima 2.5.0
  Bundler: Bundle complete! 4 Gemfile dependencies, 29 gems now installed.
  Bundler: Use `bundle info [gemname]` to see where a bundled gem is installed.
New jekyll site installed in /Users/jarretbryan/Development/blog-post-site.

So once I jump into the created directory, the absolute basics of the static site have been created for me. The basic file directory looks like this:

The most important file here is the _config.yml, which written in YAML (YAML Ain't Markup Language, the most obnoxious recursive initialism ever) manages settings for the entire site or blog. YAML is just a data oriented language (not unlike JSON) that can manage data structures for web applications - but it's meant to be human friendly. In theory, you absolutely never have touch HTML or CSS for the rest of the site - it can all be managed through the this config file.

The default config files looks something like this:

and if I run

$jekyll serve --livereload

this will setup my server at localhost:4000.

$jekyll serve

sets up the server, and the livereload flag refreshes it every time an edit is made to any file that isn't the config. And the page itself at the localhost looks little like this:

And that's a basic static website! It's really that simple. And any content necessary content need can be modified through the config file.

The file structure allows you to build out the site for blog posts or other pages with static html layouts. The 'posts' default to markdown language, making it exceptionally easy to blog (just like here on dev.to!). Each blog post can just be another markdown page. And since the site is so lightweight, it can be hosted in its entirety on GitHub Pages! I believe it's actually the engine behind GitHub pages

Now the default theme, which is specified in _config.yml is called 'minima' and while it gets the job done, it's not that interesting. But there is no shortage of themes available (for free or to pay for), put together by other designers and developers, with default file structures and layouts. I did a quick cursory search, and found some, and they're all generally easy to install (provided they are well documented). More often than not, there is an extra line of code provided to add to your gemfile, and then just changing the theme in your YAML config file. Then run $bundle and suddenly your site is transformed!

Here are some examples of sites I created, and I touched little to no HTML in the process using themes:
Jekyll Material Theme

Swiss Theme

There's a lot of room for customization that I need to dive into. But Jekyll is so lightweight and flexible that it's really easy to build out the basics of what you need without getting bogged down in web app architecture.

Using ANT to grok OOP

Jarret Bryan — Tue, 19 Jun 2018 04:47:56 +0000

OOO & OOP

One of the first things that came to mind when I read that Ruby was an Object Oriented Programming language was Object Oriented Ontology. The first draft of this blog post was a desperate attempt to link Ruby's conception of the Object to Bruno Latour's Actor Network Theory - I got Reassembling the Social off of my bookshelf; I thumbed through as much of the text as I could, trying to dig into the particulars of intermediaries and mediators, not privileging human actors over objects, relearning what the five uncertainties are --

It was largely a trainwreck, not least because ANT is famously obtuse and difficult to summarize and I really didn't have the time to relearn the particulars of Latour's conception of ontology; so here I want less to draw direct parallels and risk butchering and misunderstanding Bruno Latour's ontological claims and focus more on how the ideas (or maybe the idea of the ideas) allowed me to grok what Ruby's Object Oriented paradigm means for understanding objects and the relations between them through other objects.

Everything is an Object

So a concept that I've come across numerous times in my early experiences with Ruby is the idea that everything in Ruby is an object. Depending on who you talk to, there seem to be very minor exceptions (are methods objects? are blocks objects? both can be wrapped in objects?), but they seem to be exceptions that prove the rule more so than undermine it.

Every singular object is an instance of a Class. Even the object of Class is in instance of the class Class. And by virtue of being a specific kind of class, an object has attributes particular to that class that can be called upon.

#even nil has a class!
nil.class
 => NilClass

Object Relations

Therefore, in an object oriented language like Ruby, understanding the relationships among objects is very important - and there is no privileging one object over another. And relationships among objects must be understood through other objects. It's a level playing field. And so what we might consider objects without agency or conceptions of ownership, suddenly have ownership in relation to other objects. Here's where I wanted to draw parallel's to Latour's conception of the actant:

To break away from the influence of what could be called 'figurative sociology,' ANT uses the technical word actant that comes from the study of literature. Here are four ways to figure out the same actant: 'Imperialism strives for unilateralism'; 'The United States wishes to withdraw from the UN'; 'Bush Junior wishes to withdraw from the UN':; 'Many officers from the Army and two dozen neo-con leaders want to withdraw from the UN.' That the first is a structure trait, the second a corporate body, the third an individual, the fourth a loose aggregate of individuals makes a big difference of course to the account, but they all provide different figurations of the same actions. None of the four is more or less 'realist', concrete', 'abstract' or 'artificial' than the others.

Latour, Bruno, Reassembling the Social Oxford University Press, 2009, 54

For our purposes, an actant is just anything that enables action or can be the fulcrum of an action.

This points to an idea of 'generalised symmetry', in which there is no 'a priori asymmetry' among actors (commonly 'subjects) with intentional action and a material world of causal relations. We use the same analytical framework for all actors, whether they are a person, or a computer, or an idea about technology. This can get esoteric fairly esoteric fairly quickly, so let's drill down to how I understood the parallel in Ruby.

For example, if I make a class "Elevator" with a attribute "name", and "is_functioning" as a boolean that defaults to "true" then I can be sure that anything initialized with that class will have those attributes.

class Elevator

    attr_reader :name
    attr_accessor :is_functioning

    def initialize(name)
        @name = name
        @is_functioning = true
    end
end

elevator_9 = Elevator.new("Elevator No. 9")
#<Elevator:0x00007ff5ce3bc998 @functioning=true, @name="Elevator No. 9">

elevator.name
# "Elevator No. 9" 

elevator.is_functioning
#true

I can also make a class "Inspector" with its own set of attributes

class Inspector
    attr_reader :name

    def initialize(name, philosophy)
        @name = name
        @philosophy = philosophy
    end
end

lila_mae = Inspector.new("Lila Mae Watson", "Intuitionism")
#<Inspector:0x00007fccd6a0fdc0 @name="Lila Mae Watson", @philosophy="Intuitionism">

So I have a class Elevators, and a class Inspectors. There is nothing inherent to the code that implies a direct relationship. But the object oriented paradigm is useful to mapping to real world relationships; the thorn here being that in the real world, an Inspector is a person with agency and can claim ownership over something, while an elevator cannot. But with Ruby, there is no such a priori asymmetry. Both are objects (and both are actors) - so we use the same framework to understand them. And as a result we can say, an Inspector "has many" (or inspects many) elevators. And an Elevator "has many" (or is inspected by many) inspectors.

More importantly, we can understand the relationship between the two as an object as well. These two actors (the Ruby objects of the class Elevator and Inspector) form a temporary network, which becomes an assemblage of relations - Latour's "actant." And the point of interaction, the "Elevator Inspection," can be represented as a Ruby Object as well. Picture the below:


class ElevatorInspection

    def initialize(elevator, inspector)
            @elevator = elevator
            @inspector = inspector
    end

end

Here we see that every instance of the class ElevatorInspection is initiated with instances of the classes Elevator and Inspector. If within the class we define a class method .all to collect every instance -


class ElevatorInspection

    @@all = []

    def self.all
        @@all
    end

    def initialize(elevator, inspector)
            @elevator = elevator
            @inspector = inspector
            self.class.all << self
    end

end

then we can in theory understand the entirety of the relationship between the class Elevators and Inspectors, since every instance of ElevatorInspection class will contain information from the other two. So we understand that Elevators "have many" Inspectors through the ElevatorInspection class - and vice versa. This object can act as our "Single Source of Truth" and I argue parallel's the 'actant,' modifying the actors of Elevator and Inspector by allowing a relationship of 'ownership.' Our entire assemblage can be represented as an object, and, like an actant holds a relevance only particular to this relationship.

Is it coding as ontology?

If I've lost you, or the parallel's seem tenuous, I don't blame you: but the key takeaway for me in drawing these parallels is simply that Ruby's object oriented paradigm allows us to model real world relationships - and these relationships can be understood in terms of objects as well since we do not need to adjust our analytical framework. And since we can assign attributes to any given object in Ruby, by simply identifying the object that can be considered representative in the relationship, we can modify and manipulate that object to understand the entirety of the relationship. We've abstracted the relationship as a Ruby object.

So let's finally drill down to what this looks like in Ruby:

class Elevator  
    attr_reader :name
    attr_accessor :is_functioning

    def initialize(name)
        @name = name
        @is_functioning = true
    end
end

class Inspector
    attr_reader :name

    def initialize(name, philosophy)
        @name = name
        @philosophy = philosophy
    end
end

class ElevatorInspection
    @@all = []

    def self.all
        @@all
    end

    def initialize(elevator, inspector)
        @elevator = elevator
        @inspector = inspector
        self.class.all << self
    end
end

elevator_9 = Elevator.new("Elevator No. 9")
=> #<Elevator:0x00007fab56b99c00 @is_functioning=true, @name="Elevator No. 9">

lila_mae = Inspector.new("Lila Mae Watson", "Intuitionism")
=> #<Inspector:0x00007fab55c6c070 @name="Lila Mae Watson", @philosophy="Intuitionism">

 ElevatorInspection.new(elevator_9, lila_mae)
=> #<ElevatorInspection:0x00007fab56087a10
 @elevator=#<Elevator:0x00007fab56b99c00 @is_functioning=true, @name="Elevator No. 9">,
 @inspector=#<Inspector:0x00007fab55c6c070 @name="Lila Mae Watson", @philosophy="Intuitionism">>

Since every instance of the ElevatorInspection class "belongs to" an Elevator and an Inspector, I can find out everything I need about the relationships between the two classes, through the ElevatorInspection Class - you'll notice the ElevatorInspection instance that I've initiated has all the information about both relevant Elevator and Inspector instances. The key is identifying the object that is representative of and maintains the relationship.

Byte Size: Changing Habits with the Command Line

Jarret Bryan — Tue, 19 Jun 2018 03:08:57 +0000

I think one of the more tangible elements of tracking my progress while being a coding beginner is tracking how my habits have changed in the most basic ways as I use my computer. My experience interacting with the UI of my computer has completely shifted relatively quickly.

Previously, I, like many users, adhered to the user experience of manually clicking through folders, dragging and dropping documents and folders, right clicking for copying and deleting materials, double clicking to open files etc. etc. I stuck with the GUI.

I don't have to do this anymore

Everything has shifted after discovering the terminal and learning some very basic bash commands.

Instead of clicking through folders and scrolling manually, I navigate through my file structures just using change directory command and using the "ls" bash command to see what files I'm looking for:

Using the command line for navigation has really streamlined my workflow. I end up memorizing file and path names (or at least what they start with), and I spend far less time navigating and resizing menus.

The bash shell seems to be a really powerful tool with a lot of capabilities I've barely begun to scratch the surface of - after all, it's not just for navigation.

Lifehacker has a really beginner friendly guide on getting used to the command line.