indiesquidge

Subdomaining Localhost with Rails 5

I've been following this blog post on how to set up an api-only Rails 5 application. One of the sections talks about creating a subdomain for your api

Rails.application.routes.draw do
  constraints subdomain: "api" do
    scope module: "api" do

indiesquidge

#!/usr/local/bin/node

/*
 * Usage: in-place deletion of duplicate files within a folder.
 * ```
 * ./deleteDuplicates.js relative/folder/path/of/duplicate/files
 * ```
 *
 * You may need to change the access control to run this as an executable.
 * ```

indiesquidge

/* 
 Let us re-create `Promise.all`

 `Promise.all` method returns a promise that resolves when all of the promises in the iterable argument have resolved, 
 or rejects with the reason of the first passed promise that rejects.
 
 Read more about `Promise.all` on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all
 
 A basic example would be something like this:
 

indiesquidge

Advanced React by React Training

Personal notes while working through Advanced React: https://courses.reacttraining.com/p/advanced-react

Granted this is a contrived example, but it's still something I took notice to: in those "Advanced React" videos I've been watching, Ryan Florence codes very slowly, and does not make one quick change and jump back to the browser to see what changed.

He stops and thinks. He asks himself (or the viewer) questions. He wonders what

indiesquidge

Plain JavaScript objects are better than classes when they can be used, and many popular modern frameworks have adopted their use.

Consider that in React a component can be created as either a class or as an object.

// using a class
class Welcome extends React.Component {
  render() {
 Hello, {this.props.name}

indiesquidge

There are a myriad of benefits of smaller PRs with smaller line change deltas:

• easier for reviewers, not only in sheer amount of code to review, but also in the ability to provide useful feedback or start a discussion around different architecture patterns
• lower chances of bugs creeping in
• simpler to refactor and iterate upon
• encourages the code author to think more iteratively (e.g. what is the API I am trying to add right now? What will it look like when I'm done? Is what I'm doing extensible? Will it be suitable for future extensions, etc.)
• more synonymous with a CI flow; it is better to ship multiple small things that can easily be cherry-picked or reverted than it is to ship big PRs that are harder to debug and roll back

One pitfall to small PRs is people feeling like they can't move ahead or build on top of code that is up for review.

indiesquidge

Homebrew

How To

Homebrew is a package management system for OS X. You can read more about it here, or simply run

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

to install it.

indiesquidge

Express.js Example

Setup

This code is a direct copy of the code found on the Express.js site under Getting Started. I just followed installing and hello world from there to get a basic server up and running.

(index.js file)

indiesquidge

Status	Type	Env Vars Change	Review App	Ticket
Ready/Hold	Feature/Bug/Tooling/Refactor/Hotfix	Yes/No	Link	Link

⚠️ NOTE: use notes like this to emphasize something about the PR. This could include other PRs this PR is built on top of; new or removed environment variables; reasons for why the PR is on hold; or anything else you would like to draw attention to.

Problem

What problem are you trying to solve?

indiesquidge

import React, { Component } from 'react';

class App extends Component {
  constructor () {
    super()
    this.state = {
      name: null,
      imgUrl: null
    }
  }