– The Ruthless Elimination of Hurry: How to Stay Emotionally Healthy and Spiritually Alive in the Chaos of the Modern World by Mark Comer https://amzn.to/3ttTGsx

– Jesus and John Wayne: How White Evangelicals Corrupted a Faith and Fractured a Nation by Kristin Kobes Du Mez https://amzn.to/41F490R

– Robert E. Lee and Me: A Southerner’s Reckoning with the Myth of the Lost Cause by Ty Seidule https://amzn.to/3H5ahWO

– Deep Work: Rules for Focused Success in a Distracted World by Cal Newport https://amzn.to/41GGSeS

– So Good They Can’t Ignore You: Why Skills Trump Passion in the Quest for Work You Love by Cal Newport https://amzn.to/3vohBu4

– Never Split the Difference: Negotiating As If Your Life Depended On It by Chris Voss https://amzn.to/47sjmnm

– Amazing Grace: William Wilberforce and the Heroic Campaign to End Slavery by Eric Metaxas https://amzn.to/3NRrhn1

– The Reason for God: Belief in an Age of Skepticism by Timothy Keller https://amzn.to/3NHZrcH

– Defending Your Faith: An Introduction to Apologetics by R.C. Sproul https://amzn.to/48Baug6

– The Righteous Mind: Why Good People Are Divided by Politics and Religion by Jonathan Haidt https://amzn.to/3S2bkNe

– Digital Minimalism: Choosing a Focused Life in a Noisy World by Cal Newport (not pictured) https://amzn.to/3S2Nz7Q

– The Screwtape Letters by C.S. Lewis (not pictured) https://amzn.to/3Tr4LV3

– The Bible (ESV) https://www.esv.org/

I can say that for me, my life is much richer having read these books than having spent the equivalent amount of time scrolling. I’m definitely not spending much time writing blogs, though I’d love to share more long form content.

See you in 2025 most likely .

The post 2023 Recap appeared first on Seth Alexander.

See, I knew our backend was running Ruby on Rails (RoR) and I knew that Active Storage is now the thing but I didn’t realize the issues I would run into when I threw Amazon Web Services (AWS) S3 into the mix. I had heard good things bout Active Storage though I hadn’t worked with it any, I know RoR well enough to know that the things they add are intentional and typically well thought out, and I also knew my experience with S3 was while the configuration could be somewhat complex when it comes to IAM roles and things once it was running the way you wanted it should be pretty easy to use. Especially for something that was going to be public.

Early on in my work on this task I was informed by the back end engineer that Active Storage had this pretty neat way of allowing the client application to send files directly to S3 and just sending a reference string to the Rails server. This is preferred because instead of sending the data from the client to the Rails server to Amazon it goes directly from the client to Amazon. Bypassing one step speeds everything up and also saves some load on the server. I thought to myself this was pretty cool. We at Airship had done this before with a web app with solid results. I had that code to reference and base my work off of.

Where things start to go wrong…

This is where things start to splinter. I start to digest the code from the web app we created:

import axios from "axios";
import SparkMD5 from "spark-md5";
const getUploadInfo = async (file) => {
  const checksum = await createFileChecksum(file);
  return axios.post(
    `${process.env.BASE_URL}/rails/active_storage/direct_uploads`,
    {
      blob: {
        filename: file.name,
        content_type: file.type,
        byte_size: file.size,
        checksum: checksum
      }
    }
  );
};
export const createFileChecksum = async (file) => {
  return new Promise((resolve, reject) => {
    const chunkSize = 2097152; // 2MB
    const chunkCount = Math.ceil(file.size / chunkSize);
    var chunkIndex = 0;
    const md5Buffer = new SparkMD5.ArrayBuffer();
    const fileReader = new FileReader();
    const readNextChunk = () => {
      if (chunkIndex < chunkCount || (chunkIndex === 0 && chunkCount === 0)) {
        const start = chunkIndex * chunkSize;
        const end = Math.min(start + chunkSize, file.size);
        const fileSlice =
          File.prototype.slice ||
          File.prototype.mozSlice ||
          File.prototype.webkitSlice;
        const bytes = fileSlice.call(file, start, end);
        fileReader.readAsArrayBuffer(bytes);
        chunkIndex++;
        return true;
      } else {
        return false;
      }
    };
    fileReader.addEventListener("load", event => {
      md5Buffer.append(event.target.result);
      if (!readNextChunk()) {
        const binaryDigest = md5Buffer.end(true);
        const base64digest = btoa(binaryDigest);
        resolve(base64digest);
      }
    });
    fileReader.addEventListener("error", () =>
      reject(`Error reading ${file.name}`)
    );
    readNextChunk();
  });
};
export const uploadFile = async (file) => {
  const uploadInfo = await getUploadInfo(file);
  await axios.put(uploadInfo.data.direct_upload.url, file, {
    headers: uploadInfo.data.direct_upload.headers
  });
  return uploadInfo.data.signed_id;
};

Real quick, getUploadInfo() sends the relevant info about the file the the Rails back end and returns what’s needed to direct upload to S3. createFileChecksum() is used by getUploadInfo() to calculate the base64 encoded md5 checksum of the file being sent. While Amazon does not require this Rails does. Lastly, uploadFile() uploads the file to AWS and then returns the signed_id that is then sent to Rails so it can associate that file with whatever it is in the back end.

I later realized most of this code came from somewhere else, maybe even the @rails/activestorage package. I found similar code living in a <a href="https://github.com/rails/rails/blob/master/activestorage/app/javascript/activestorage/file_checksum.js">file_checksum.js</a> file in the Rails repository on GitHub. No matter the source of the code, there was an issue. I don’t have access to the FileReader api on mobile. I’m working in React Native and not a browser. So now the search commences to doing this exact same thing in React Native.

All the things that didn’t work

Actually, I’m not going to bore you with everything that didn’t work. I honestly don’t think you care. You probably Googled how to do this and it’s NOWHERE TO BE FOUND on the internet. Yet, this direct upload has been a feature in Rails for a while. You might have even landed on the Rails issue Make ActiveStorage work for API only apps and a comment there:

For those on react native, I was able to get direct uploads working using rn-fetch-blob for md5 hashing (which is output in hex), then converting its hex output into base64 using buffer for calculating the checksum. To lookup the content_type, I used react-native-mime-types, and last but not least, used rn-fetch-blob again for calculating the size. Then, just follow the communication guidelines pointed out by @cbothner, and if the files are big, use rn-fetch-blob for efficiently uploading the file.

– Samsinite

So, I tried to follow the above thread and I couldn’t get it to work. Granted, that comment is almost 6 months old and in JavaScript time that’s a lifetime ago. The main issue I ran into is I could not for the life of me get the checksum to match up with what Amazon calculated on their side. I kept getting responses of “The Content-MD5 you specified was invalid”. I tried MANY ways of generating the md5 checksum and they all ended up with the same Content-MD5 message being returned from AWS.

So here’s how I ended up getting it to work (why you’re really here):

import axios from "axios";
import Config from "react-native-config";
import RNFetchBlob from "rn-fetch-blob";
import AWS from "aws-sdk/dist/aws-sdk-react-native";
import { Platform } from "react-native";
import { Buffer } from "buffer";
const { fs } = RNFetchBlob;

AWS.config.update({
  accessKeyId: Config.AWS_ACCESS_KEY_ID,
  region: Config.AWS_REGION,
  secretAccessKey: Config.AWS_SECRET_ACCESS_KEY
});
const s3 = new AWS.S3({ apiVersion: "2006-03-01" });

const getUploadInfo = async (fileInfo, file) => {
  const params = {
    Bucket: Config.AWS_BUCKET,
    ContentType: fileInfo.type,
    Key: fileInfo.fileName,
    Body: file
  };
  const psUrl = s3.getSignedUrl("putObject", params);
  const checksum = unescape(psUrl.split("&")[1].split("=")[1]);

  return axios.post(
    `${Config.API_UPLOAD_HOST}/rails/active_storage/direct_uploads`,
    {
      blob: {
        filename: fileInfo.fileName,
        content_type: fileInfo.type,
        byte_size: fileInfo.fileSize,
        checksum: checksum
      }
    }
  );
};

export const uploadFile = async (fileInfo) => {
  const uri =
    Platform.OS === "ios" ? fileInfo.uri.replace("file://", "") : fileInfo.uri;
  const file = await fs
    .readFile(uri, "base64")
    .then(data => new Buffer(data, "base64"));

  const uploadInfo = await getUploadInfo(fileInfo, file);
  const { headers, url } = uploadInfo.data.direct_upload;

  try {
    await axios.put(url, file, { headers: { ...headers } });
  } catch (e) {
    throw e;
  }

  return uploadInfo.data.signed_id;
};

This is definitely not the most elegant solution. I haven’t refactored it at all yet either. However, it works. In the world of code that means something. So what in the world is going on here? I’ll walk through it, although, I’ll jump around the file some. First, I setup the aws-sdk and a new s3 instance. I’m using react-native-config to manage environment variables here. I initially did this to see if I could get the signed_id I needed by just bypassing Rails and uploading directly to AWS, that didn’t work. However, what I noticed when I generated a pre-signed URL for uploading via the aws-sdk was that the URL contained and md5 checksum!

Back to the code

Okay, the code, walk through it, here we go. I call uploadFile() in the response from react-native-image-picker on my screen component. That’s where the fileInfo argument comes from. I then get the proper URI based on the OS, and read the file with rn-fetch-blob. I turn that data into a Buffer because the aws-sdk on accepts certain types of files when creating a pre-signed URL. I then pass the fileInfo and the file along the getUploadInfo(). getUploadInfo() then creates a pre-signed URL using the s3 instance we setup earlier and does some hacky string manipulation (needs a refactor) to acquire the checksum. Now, I can use that checksum (which Amazon code created) to get the direct upload URL and headers from Rails. Lastly, I upload the file to AWS and return the signed_id which I send along to Rails elsewhere in my code.

Ultimately, this was a pretty frustrating problem to fight against. However, it felt so good when I uploaded a file and saw the user profile image change. I actually got up and ran around my home office with my hands in the air rejoicing. I’m also stoked that I can share this solution and see how others might improve on what I did or figure out better ways to go about this. I’m not convinced this is the best solution to this problem, however, it’s a solution that works.

From my yarn.lock:
– react-native v0.60.5
– react-native-image-picker v1.1.0
– rn-fetch-blob v0.10.16
– aws-sdk v2.532.0

The post Rails Direct Upload to AWS S3 from React Native appeared first on Seth Alexander.

During a recent project in my work at Airship I had to stop using the built in cluster functionality that <a href="https://github.com/react-native-mapbox-gl/maps">@react-native-mapbox-gl/maps</a> provides and utilize Supercluster instead. The reason is we need access to the points that make up the clusters. We had some items that never broke out of their clusters because they had the same exact longitude & latitude combination. As well as wanting to show a slide up view of those locations in a list view. What started me down this path was an issue on the deprecated <a href="https://github.com/nitaliano/react-native-mapbox-gl">react-native-mapbox-gl</a> library which shares a lot of functionality with the new library. You can view that issue here. I’m honestly surprised that this functionality isn’t available in the library since it is supported in the Mapbox JS SDK as documented here with the getClusterLeaves() function. I noticed people asking how to do this so when I nailed it down I knew a how-to was coming.

Without Supercluster

I setup a code example here to show a contrived starting state utilizing the built in clustering functionality. This is essentially where I started with the core Mapbox functionality. Let’s walk through this code some.

render() {
  return (
    <View style={{ flex: 1 }}>
      <MapboxGL.MapView
        ref={c => (this._map = c)}
        zoomEnabled
        style={[{ flex: 1 }]}
      >
        {this.renderPoints()}
      </MapboxGL.MapView>
    </View>
  );
}

Here’s our MapboxGL container to setup our map. We then need to render all our points on the map and we handle that in a helper function renderPoints().

renderPoints = () => {
  const { points } = this.state;

  return (
    <MapboxGL.ShapeSource
      id="symbolLocationSource"
      hitbox={{ width: 18, height: 18 }}
      onPress={this.onMarkerSelected}
      shape={points}
      cluster
    >
      <MapboxGL.SymbolLayer
        minZoomLevel={6}
        id="pointCount"
        style={mapStyles.clusterCount}
      />

      <MapboxGL.CircleLayer
        id="clusteredPoints"
        minZoomLevel={6}
        belowLayerID="pointCount"
        filter={["has", "point_count"]}
        style={mapStyles.clusteredPoints}
      />

      <MapboxGL.SymbolLayer
        id="symbolLocationSymbols"
        minZoomLevel={6}
        filter={["!has", "point_count"]}
        style={mapStyles.icon}
      />
    </MapboxGL.ShapeSource>
  );
};

So here we’re getting the list of groups from state and passing them into MapboxGL.ShapeSource and toggling the cluster functionality on. We have three layers inside there which I’ll refer to by ID values.
– pointCount is the actual numerical value of the number of items that make up the cluster.
– clusteredPoints is the cluster circle which we see is set to be below the pointCount layer.
– symbolLocationSymbols is the map marker for a single location on the map that isn’t being clustered.

When we click a marker, whether it’s a cluster or single point on the map we call onMarkerSelected which currently only has functionality implemented for non-clusters like so:

onMarkerSelected = event => {
  const point = event.nativeEvent.payload;
  const { name, cluster } = point.properties;
  const coordinates = point.geometry.coordinates;

  if (cluster) {
    console.log(cluster);
  } else {
    this.setState(
      {
        selectedPointName: name,
        selectedPointLat: coordinates[1],
        selectedPointLng: coordinates[0],
      },
      () => {
        this.map.flyTo(point.geometry.coordinates, 500);
      }
    );
  }
};

The if/else statement is just logging the cluster if there is one otherwise it’s setting the state to the selected point and centering the map on that point. The idea of adding the point info to state is to do something with that info.

We decide if we’re going to render the circle or marker based on the filter criteria being passed into the CircleLayer and SymbolLayer.

const mapStyles = MapboxGL.StyleSheet.create({
  icon: {
    iconAllowOverlap: true,
    iconSize: 0.35
  },
  clusteredPoints: {
    circleColor: "#004466",
    circleRadius: [
      "interpolate",
      ["exponential", 1.5],
      ["get", "point_count"],
      15,
      15,
      20,
      30
    ],
    circleOpacity: 0.84
  },
  clusterCount: {
    textField: "{point_count}",
    textSize: 12,
    textColor: "#ffffff"
  }
});

This last piece provides some of the styling and actually won’t change when we swap out the clustering functionality.

Implementing Supercluster

So the idea of switching to Supercluster to to replace the built in clustering of the raw FeatureCollection data. Supercluster is not going to do anything with the actual rendering of that data. We need to initialize a cluster using Supercluster then update that cluster based on the bounds of the map and zoom level. I’m going to walk through the guts of this conversion.

Firstly, you’ll need the cluster which I decided to store in state. I think this makes the most sense and works well for me.

const collection = MapboxGL.geoUtils.makeFeatureCollection(groupFeatures);
const cluster = new Supercluster({ radius: 40, maxZoom: 16 });
cluster.load(collection.features);

this.setState({
  point: collection,
  loading: false,
  selectedPoints: [],
  superCluster: cluster,
  userFound: false
});

So now I have the FeatureCollection as state.groups and the Supercluster cluster as state.superCluster. However, we will not be able to pass this superCluster into our MapboxGL.ShapeSource just yet. This cluster is immutable and essentially what we will now use to create the shape object we will pass into ShapeSource. Next let’s update our MapView like so:

<MapboxGL.MapView
  ref={c => (this._map = c)}
  onRegionDidChange={this.updateClusters}
  zoomEnabled
  style={[{ flex: 1 }]}
>
  {this.renderPoints()}
</MapboxGL.MapView>

Notice the added onRegionDidChange which takes a callback function. This prop I found works the best for me, however, as the react-native-mapbox-gl/maps library continues to evolve there may be a better solution. This calls updateClusters after the map has been moved. Now lets take a look at the updateClusters function:

updateClusters = async () => {
  const sc = this.state.superCluster;
  if (sc) {
    const bounds = await this._map.getVisibleBounds();
    const westLng = bounds[1][0];
    const southLat = bounds[1][1];
    const eastLng = bounds[0][0];
    const northLat = bounds[0][1];
    const zoom = Math.round(await this._map.getZoom());
    this.setState({
      superClusterClusters: sc.getClusters(
        [westLng, southLat, eastLng, northLat],
        zoom
      )
    });
  }
};

So, I take the cluster that was created in my componentDidMount() and set that to a local variable. Just in case I check to ensure it exists before doing anything else. Next, I get the visible bounds from the _map ref that is setup on the MapView. I extract the four bounds into their own variables mostly for ease of knowing what they are. I then get the zoom and round it to a whole number (I found decimal zooms gave Supercluster issues). Finally, I take all that information and create the appropriate clusters for those bounds and zoom level and save them in state to superClusterClusters.

This superClusterClusters is what gets fed into the ShapeSource in renderPoints like so:

renderPoints = () => {
  const { superClusterClusters } = this.state;

  return (
    <MapboxGL.ShapeSource
      id="symbolLocationSource"
      hitbox={{ width: 18, height: 18 }}
      onPress={this.onMarkerSelected}
      shape={{ type: "FeatureCollection", features: superClusterClusters }}
    >
      <MapboxGL.SymbolLayer
        id="pointCount"
        minZoomLevel={6}
        style={mapStyles.clusterCount}
      />

      <MapboxGL.CircleLayer
        id="clusteredPoints"
        minZoomLevel={6}
        belowLayerID="pointCount"
        filter={[">", "point_count", 1]}
        style={mapStyles.clusteredPoints}
      />

      <MapboxGL.SymbolLayer
        id="symbolLocationSymbols"
        minZoomLevel={6}
        filter={["!", ["has", "point_count"]]}
        style={mapStyles.icon}
      />
    </MapboxGL.ShapeSource>
  );
};

Notice that the shape prop requires the creation of an object and I’m not passing in the superClusterClusters directly from the state. Also notice that the cluster prop is no longer included on ShapeSource. This is something I forgot about and caused me a lot of grief. The built in clustering was conflicting with my clustering.

Lastly we add in functionality for getting the info about each point out of the cluster when we touch it on the phone in our onMarkerSelected() like so:

onMarkerSelected = event => {
  const point = event.nativeEvent.payload;
  const { name, cluster } = point.properties;
  const coordinates = point.geometry.coordinates;

  if (cluster) {
    const sc = this.state.superCluster;
    if (sc) {
      const points = sc
        .getLeaves(point.properties.cluster_id, Infinity)
        .map(leaf => ({
          selectedPointName: leaf.properties.name,
          selectedPointLat: leaf.geometry.coordinates[1],
          selectedPointLng: leaf.geometry.coordinates[0],
        }));
      this.setState({ selectedPoints: points });
      console.log(points);
    } else {
      this.setState(
        {
          selectedPoints: [
            {
              selectedPointName: name,
              selectedPointLat: coordinates[1],
              selectedPointLng: coordinates[0],
            },
          ],
        },
        () => {
          this.camera.flyTo(point.geometry.coordinates, 500);
        }
      );
    }
  }
};

By using Superclusters getLeaves() we map those to a new array and set our selectedPoints state to it. We can now use this new data in state to render something in the UI.

Final Thoughts

While there might seem like there are many steps involved in adding Supercluster to a react-native-mapbox-gl/maps map to access the underlying points of a cluster most of the code that I have shared can be reused as is to ease the transition.

For reference, the exact versions I’m using in this example are:
react-native-mapbox-gl/maps: 7.0.1
supercluster: 6.0.2
A final code sample is available here.

NOTE: The code samples WILL NOT WORK. Although, if you’re reading this article I’m making the assumption you already have Mapbox implemented. With that I also assume you have the library initialized with your access token.

I hope this saves people some headaches along the way and you build amazing things having access to the underlying data points that make up your clusters.

The post Supercluster with @react-native-mapbox-gl/maps appeared first on Seth Alexander.

WHERE. TO. START???

I recently faced this same dilemma. It was a struggle but at the end of it, I had a solid repo that I could use as a basis for future React projects. I realized I wanted to use webpack because it’s the new hotness (well not so new) but I would have a lot of resources to pull from to figure it out. I have ZERO working knowledge of Grunt or Gulp although with the minimal amount I’ve looked at them they do some cools things in their own right. Also, I know the people I interact with who know more than me use webpack. I also had a reference React boilerplate webpack config I was going to use as a base (I quickly realized I was going to rewrite most of this config).

Back to the Beginning

Let’s take it back though. What really is a boilerplate? Dictionary.com failed in getting me a definition that would work. Oxford Dictionaries on the other hand landed the W with:

3.1 Standardized pieces of text for use as clauses in contracts or as part of a computer program.

This works. So something that’s standard across computer programs. As in some code that’s always the same at least in theory. So instead of having to run things like npm i react react-dom webpack etc… every time we start a project we can copy our boilerplate and be off to the races knowing all the essential pieces we want are ready to go. We’ll also know that everything is being maintained the way we want it to because it’s ours. We also will learn a lot during the process and possibly even decide to make decisions that differ from what others have instructed us to do.

Get Git

First let’s create a local folder and make this a Git repository.

First things First

Now, what type of project would this be without a README.md? Every repository should have a readme file. Even if it’s just to remind YOU about how things work. Trust me, it may seem like you’ll remember exactly what each script does and why right now. However, a year from now these readme’s come in handy! Trust me. So, create a README.md in the root of the project. Put something like this in there:

Make sure to commit your files to Git after any changes you make:

Folder Structure

This one is pretty straightforward. Make the following folder structure to house everything:

You can accomplish this easily with this command:

.gitignore

An essential part of any Git project is the .gitignore file. This tells git to not put certain files under version control. This is important for things like packages and other things that we will retrieve from repositories. Not only do we not need these in version control but it’s actually detrimental if we do include them in version control. At least I’m pretty sure it’s detrimental. Create a .gitignore file in the root of your project and add the following to it:

There are generators for this file, like this one, but this should be enough for what we’re doing today.

npm

All node projects must be initialized so we can use the package manager. This will create a package.json file for us which must be in version control.

It contains many things but the most important are:

• A list of all the installed packages and their semantic version allowed
• Scripts

To start this process enter the following in your terminal in the root of your project:

You’ll be asked more than a few questions, feel free to just press Enter and leave it all blank, and in the end you’ll now have a shiny new package.json that looks something like this:

HTML

Yes! Time to write some code! Well, this is going to be the most boring HTML you probably ever write. Create an index.html in the root of your project and set it up like so:

React

Now, let’s add React to our project.

Create this file /src/components/App.js and in it put the following:

Then we will render the App via an index which we will create here at /src/index.js and put the following in:

Babel

Babel is awesome. It lets us write the latest and greatest JavaScript while ensuring we have maximum compatibility with the code we ship. First thing is we have to install Babel and a few additional Babel packages to make this all work together. Don’t worry it’ll be explained soon.

Then we need to create a .babelrc in the root of our project and add the following to it:

Now, what does this do exactly? The env preset implicitly includes babel-preset-es2015, babel-preset-es2016, babel-preset-es2017, and babel-preset-latest together, which means you can run ES6, ES7, and ES8 code.

The react preset I think is pretty self-explanatory, but, you might be wondering why we need it if React is JavaScript. That’s because Babel doesn’t know what to do with React & JSX.

NOTE: I removed the stage-2 preset from this update. If you’re wondering why, read this great post by the Babel team: Removing Babel’s Stage Presets.

Tests

So we’re making progress. Now that we have a React component with our App.js let’s make sure to create a simple associated test for that component. This way we’re starting to ensure some good practices of having tests for the things we build. We will be using Jest with Enzyme for this project. First things first, let’s install it with:

Now create /test/enzyme.setup.js and put in it:

We’ll need to add Jest functionality into our package.json so add the following to it:

Next, we should add our first component test! So, create a file at /test/App.test.js to test that our App component renders as expected. We are also going to implement a snapshot test to ensure our components structure doesn’t change from test to test. To do that we’ll need the following:

You might be wondering how to run this new test. To do so we need to change the test script in the package.json to this:

You can now run the test from your terminal with npm test and should see something like this:

Break Time

If you’ve made it this far with your React boilerplate, CONGRATS! Mostly because you’ve realized that I’m using images for my code and you have to type it all out. That’s a pain in the ass, I know. Trust me though, you’re learning more than you know by being forced to type it all and the muscle memory is going to serve you well long after this tutorial.

webpack

webpack will allow us to modularize our code and easily bundle it into a single file for production. Something I think a lot of people really like about webpack though is the development server! We’ll start by just installing webpack with:

webpack looks for a webpack.config.js file by default in the root of the project so let’s create that and add to it a couple things:

The entry is telling webpack where to find the base JavaScript file. In our application that’s index.js. Then it tells it where to output the built file when it’s done with it.

webpack loaders

Loaders are helpful pieces we can add to webpack to make it more powerful and do things to other file types. Before webpack will work properly we need to set it up to work with ES6 and JSX. We’ll do this through the babel-loader. Add the babel-loader to your project with:

Then add the loader to your webpack.config.js like so:

To utilize Sass and SCSS we’ll need another loader. Now to get the best “bang for our buck” we’re going to chain three loaders together so our styles are applied immediately to the DOM. Let’s install the loaders:

And configure it like so in our webpack.config.js:

Since we just enabled some style support let’s add some. Create /src/styles/style.sass and put in it:

Then add it to your index.js like so:

Up next are webpack plugins. So, we need a way to include the built JavaScript in our index.html and of course, there’s a way to do this automatically. This is also going to take the index.html file and drop it into our build folder (more on the build later). Let’s add the HtmlWebPackPlugin and include it in our webpack.config.js like so:

Then:

Our next plugin is going to ensure that the directory we put our build in is cleaned out of any former files every time we run a build. We do that with these two steps:

Then:

The moment we’ve all been waiting for! Let’s get the development server setup. So we’re going to add two packages in this step. webpack-cli is going to be used to run our commands from our package.json file. First:

Then update our webpack.config.js:

Finally add to the scripts section of the package.json:

Now fire up your development server and your default browser will open. It’ll take a second while webpack does it’s thing but you’ll soon see you React live in the browser.

So right now we could say success! However, our code isn’t optimized for production use. However, we don’t want to optimize our code while we’re in development either because it takes a lot longer to build. So let’s create separate build files for our production and development environments and tell webpack how to handle that. I promise we’re almost done. Really we are… Up next is:

This is going to allow us to have three webpack config files. So let’s get that setup. Rename your webpack.config.js to webpack.common.js. Then create webpack.dev.js and webpack.prod.js. The idea is one will have configuration used in both development and production, one will be development only, and one will be production only. So first thing, let’s remove the development server code from common we just added in the last step and add it to webpack.dev.js. We’ll utilize webpack-merge to include everything from webpack.common.js and add on webpack.dev.js. So now your webpack.common.js looks like this:

Your webpack.dev.js should look like this:

Your webpack.prod.js should look like this:

The last step here is to update the scripts in our package.json file to utilize these different files at different times. Your new scripts sections should look like:

What now?

Now you can go ahead and start your development server with:

You can build your application and have all the advantages of everything we’ve put together. When you’re ready to deploy your production application just run:

This will output an optimized version of your code into the /dist folder. Take those files and upload them to your favorite host and you’re good to go!

What’s Next With Your React Boilerplate?

Well, nothing from me! Ha, I think you’ve had enough by now. Hopefully, this empowers you to dive into creating your own boilerplate. You’ll start your personal projects steps ahead and really get an understanding of what each piece does. I HIGHLY recommend the webpack docs for further reading if you want to continue to add configuration to your webpack setup. There is A LOT more you can do with it. Another thing you might want to do is set up something like ESLint in your project as well. You can also dive deep into Babel and all that it allows you to do.

Thanks and I’d love to hear what you think about this setup. Anything you’d add, remove or change leave in the comments below.

I ALMOST FORGOT! Actually I did, I’m adding this after I clicked “Publish”. If you want to find all this code I have it in a repo here.

The post How-to Build Your Own React Boilerplate appeared first on Seth Alexander.

Should I build my site from scratch?

When I asked this question to the ever helpful NashDev community I received a resounding “No” from Senior devs. This might seem counter intuitive, however, the overall thought process was if you’re just starting out, unless you’re looking to be considered a designer, then using something someone else has already done very well as the base of your portfolio is better than building it yourself. Concentrate on highlighting the things that you are going to be doing in a potential job, not on the overall layout and design of your portfolio site. I decided to go with a template from HTML5 UP for a few reasons. First, they’re FREE as long as you keep the attribution. Second, AJ who creates these amazing templates is based out of Nashville just like me and had in the past connected me with some solid people to have beer/coffee with and discuss my career. Third, it’s a static site. That is, it’s 100% HTML, CSS & JavaScript so I would have many simple options for hosting when I got to that point. Lastly, all of the templates are responsive so if a potential hiring manager clicks through from their phone they’re going to get a great experience.

I’ve got my template, now what?

Fill er up with content! So this I don’t think I can help with too much. What you decide to include on your site is going to be up to you. However, as this is going to be something professional shy away from anything controversial. Keep it scoped around the skills you have and things you have built. A couple resources that I used for my site. The high-res background images I used all came from Unsplash. Unsplash describes itself as:

Beautiful, free photos.
Gifted by the world’s most generous community of photographers. ?

There aren’t that many coding images so once you’ve seen them you’ll start noticing them all over the web. Check them out and see if you can find interesting images that represent YOU and use them. Or don’t. Like I said, it’s up to you. Another cool place I found but didn’t get to integrate is Coverr which provides “beautiful, free videos for your homepage”. I still want to replace the top image on my site with one of their videos on a loop. I just haven’t spent the time to figure out how to implement it within the template I am using. All of my technology icons come from DEVICON which has sweet full color SVG’s. Note, if you don’t see it on the linked site check there GitHub repo here as I found not all the icons are on their site. Just look in the icons folder of the repo. I like these icons because since they’re SVG’s they they will look great no matter their scale. For example this Vim icon:

I implemented my contact for by using Formspree which is a sweet way to add a form to a site super simply. I wouldn’t suggest using them for a production app but for something like this they’re perfect. They also include reCAPTCHA by default so you won’t have to worry about spam.

It’s done! How should I host it?

Before moving on to picking a web host, I think you should get yourself a domain name. I’ve been an avid user of Namecheap (Full Disclosure: This is an affiliate link. I recommend them because I use them not because I can get 20% of your domain purchase.) for years and purchase all my domains through them. Try for a first name, last name domain. Stay away from domains that are truly vanity and try to stick to .com, .io, .me if you can. They’re just easier to remember in general. Once again, do what you want. This is just what I would do.

Now because you’ve built a static site there are MANY free options that you can use in conjunction with your domain name for hosting. I currently use Surge however, Now, GitHub Pages and Netlify are also very common, free and easy to use. If you’re looking for a more fully featured web host I currently use GeekGhost (Another affiliate link) and enjoy them. I haven’t had any issues, they allow Let’s Encrypt SSL Certificates (an easy and free way to get your site using HTTPS) and their base plan is only $3.50/mo! I won’t go through deploying your site and setting up your domain name as this will be different for each host you may use. Feel free to ask host specific questions in the comments.

I’m online, what now?

Honestly, not much. Just make sure to link to your site from your resume, on LinkedIn, etc… In addition, remember to keep your site updated as you gain new work experience, publish new projects, and acquire new skills. You never know who might be looking at your portfolio and decide they want to reach out to you!

The post Portfolio Site How-To For New Developers appeared first on Seth Alexander.

Below you’ll find the highlights and some noteworthy quotes from our discussion. With any panel discussion it’s difficult to keep very detailed notes. I did the best I could and these are the types of things we hope you attend in the future with us. With that, I do hope some of this helps you out some. Use the comments for questions and further discussion. Or just join on in the #freecodecamp channel on the NashDev Slack network.

One if the fist topics we discussed was LinkedIn

• Recruiters are keyword driven when looking through LinkedIn.
• Make it concise and keep it professional.
• What technologies you used and where. Not really looking at the summary.
• “Be conscious of what you “like” because people see that,” Caroline.
• “First impressions are key. ‘You get about 15 seconds before I decide to move on or stay,'” Sydney.
• The heading should be what you know today not things that you’re going to do.

Make sure that your LinkedIn account is setup so recruiters can find you:
On your LinkedIn account click your profile picture, then Settings & Privacy, next click Privacy at the top, then scroll down to Job Seeking and make sure that section is setup the way you’d like so recruiters can find you.

In addition ensure your Career Interests are accurate.

Networking Is Key

• Build your portfolio and projects you can explain. Real life in production apps that you can demonstrate.
• Keep your Github up to date for others to look at.
• You need the above two so that you can, “Find people to go to bat for you. Find people to say ‘Hey I need help. Take a look at my code or my projects.’ Purely professional contacts,” Caroline.
• References can help you fill the credibility gap so for sure list them up front when you have good ones.

The Nashville Job Market

• More people interested in front end than backend. Finding backend devs is more challenging.
• Even though the Nashville market is saturated for the Junior level positions Nashville is working on the situation and the community here is very open to people who are starting out.
• Ruby on Rails & Salesforce are in high demand.
• Java.
• Q3 is known as the highest time for staffing. Q4 slows down. Q1 companies typically get fresh new budgets.

Interview Tips

• “Never say, ‘I learn quickly,’ or ‘I’m a jack of all trades.’ Be relaxed, be yourself.” Hunter.
• “Be confident but also be humble.” “Address where your shortcomings might be up front. Point blank ask someone ‘What concerns can I alleviate for you.'” Caroline.
• “Don’t be afraid to say no. Yes and no but. If you have worked with something say ‘Yes and’ explain it. If you haven’t say, “No but’ then explain something else.” Sydney.
• Be confident and able to tell your story in a clear and concise way. – Caroline

Resume

• Career changers could remove bullet points from past careers but still list the work to keep a resume concise.
• One page is not the hard and fast rule.

Salary

• Be transparent as you can with recruiters.
• Typically on W2 roles the recruiting company gets a % so they are motivated to get you more.
• Contract positions are typically a $ amount. So if you get paid less then the recruiting company will get more.
• Junior in Nashville will be 50-60k typically.

General Advice

• “Don’t be picky for the first gig. The experience is worth it and you can be more picky if or when you choose to move on to a new job.” Sydney.
• Follow up with recruiters ~1 time per month when you haven’t heard from them.
• Don’t deal with a recruiter who targets you obviously for a position you’re not qualified for. They’re just trying to get their numbers in.

Podcasts:

• Freakanomics
• Complete Developer Podcast
• Junior Developer Toolbox
• CodeNewbie
• NashDev Podcast
• JavaScript Jabber
• NodeUp

I hope this was helpful and I’m looking forward to the comments section on this one for more discussion of these topics.

The post freeCodeCamp Nashville December Meetup Recap appeared first on Seth Alexander.

Next, you’ll want to click Create a new workspace.

Then, your Workspace name can be whatever you want. Leave Hosted workspace selected and choose Private or Public, it doesn’t matter which. In Clone from Git or Mercurial URL input https://github.com/davi3blu3/fcc-node-crash.git. Then, under Choose a template select Node.js. Lastly, click Create Workspace.

This might take a minute but eventually, you’ll have something that looks like this:

So first thing, let’s go to the terminal at the bottom of the screen and type in npm install and hit enter. That’s going to bring in all the packages at are in our package.json file. You’ll see a new folder in your file tree now called node_modules. That’s where all the packages live.

Now let’s open up 1_helloworld.js. It should look like this (please excuse Dave’s inconsistent semicolon usage, I already ragged on him about it):

var hello = function() {
    console.log('Hello world');
}
hello();

// console.log(process.argv);

// var greet = process.argv[2] || "World";

// var hello = function(name) {
//     console.log('Hello ' + name + '!');
// }
// hello(greet);

Back in our terminal, we can run this file with node 1_helloworld.js. With the initial code, you should see “Hello World” printed in your terminal. This terminal is also our console inside Cloud9. So anything we console.log will end up here. We can see something interesting when we uncomment line 6 by taking out the //. So line 6 should look like this now: console.log(process.argv);. When we run node 1_helloworld.js we get our “Hello World” again but then we also get an array that has two elements. Yours should be the same as mine and be:

[ '/home/ubuntu/.nvm/versions/node/v6.11.2/bin/node',
'/home/ubuntu/workspace/1_helloworld.js' ]`

These two elements are the whole command-line invocation. However, we can do some interesting things with this as well. Let’s change our code up some:

// var hello = function() {
//     console.log('Hello world');
// }
// hello();

console.log(process.argv);

var greet = process.argv[2] || "World";

var hello = function(name) {
    console.log('Hello ' + name + '!');
}
hello(greet);

Okay, well not changed much just comment and uncomment stuff. So now we have our console.log from before, we set a variable, we set a function, and we call that function. So if we run node 1_helloworld.js now we’ll see our process.argv array and “Hello World”. If we run node 1_helloworld.js "freeCodeCamp Nashville", we’ll see an array with 3 elements and “Hello freeCodeCamp Nashville” printed. We can pass things in this way!

Let’s look at 2_hellofile.js now:

const fs = require('fs');
const fileToRead = process.argv[2] || 'README.md';
const lineIndex = process.argv[3] - 1 || 3;

fs.readFile(fileToRead, function (err, data) {
    if (err) throw err;

    var lines = data.toString('utf-8').split("\n");

    console.log(lines[lineIndex]);
});

Let’s run this with node 2_hellofile.js and see what we get. Whoa, where did that come from? Let’s walk through how this happened. I’m not going to walk through how fs works. Just know that it’s a module that comes with Node.js and if you want to learn more you can look here.

Once we require the module in our JavaScript file (like we did on line 1) we can use everything that comes with it.
Line 2 we’re setting a variable equal to something we pass into our process.argv or README.md.
Line 3 we’re setting another variable equal to something we pass into our process.argv or 3.
Line 5 we’re using the readFile function that comes with fs and passing in an argument and a callback function to handle an error or data.
Line 6 we say we’ll throw an error if an error occurs.
Line 8 we set a variable that takes the data fs gets for us and turns it into a string then splits it on “\n” so we end up with an array of strings.
Line 10 we console.log the element from the lines array that is at lineIndex index position.
Line 11 we close the function.

If you want to play with this try node 2_hellofile.js 'README.md' 14. We’re taking the readme and turning it into an array split at the end of each line then logging the line that we call by number.

On to 3_helloweb.js which should look like this:

const http = require('http');

// on c9.io hostname must be '8080'
// locally, this can be almost anything
const port = 3000;

// on c9.io hostname must be '0.0.0.0'
// locally, you would use 'localhost' (a variable for '127.0.0.1')
const hostname = 'localhost';

const server = http.createServer(function(request, response){
    response.writeHead(200, {"Content-Type": "text/plain"});
    response.write("Hello Web! XOXO, Node");
    response.end();
});

server.listen(port, hostname, function(){
    console.log(`Server running at ${hostname}:${port}/`);
});

Once again not to go too deep into what http is but it gets our server going. This 3_helloweb.js is going to be our Node.js web server. A very simple one but one nonetheless. Dave has left some notes for us. We need to change the port variable on line 5 to 8080 and the hostname variable on line 9 to '0.0.0.0'. If you were running this code locally the settings that are here should work. However, Cloud9 has some specific restrictions to how they will allow us to run a server. So make the changes and run node 3_helloweb.js in your terminal. You should be greeted with a Server running at 0.0.0.0:8080/ and a green box from Cloud9 with a link to the server.

When you click that link the first time you’ll get a nasty orange screen with a red button. That’s Cloud9 telling you to not use this type of server for anything important. So click through and you should see a web page that says “Hello Web! XOXO, Node”. That text coming straight from line 18 of our 3_helloweb.js file. To kill the server click on the terminal and ctrl + c or cmd + c.

Lastly, we have 4_helloexpress.js:

// bring in dependencies / libraries
var http = require('http');
var express = require('express');
var app = express();
var bodyParser = require('body-parser');

// environment variables
var port = 8080;
var hostname = '0.0.0.0';

// parses text content of a http request
app.use(bodyParser.text({ type: 'text/html' }));

// servers static files like our html $ css from public folder
app.use(express.static('public'));

// this handles our post request from the front end
app.post('/', function(req, res, next) {
    console.log('Message from browser: ',  req.body);
    res.end('Message received. Hello from the back end!');
})

// start the server and listen for requests
var server = http.createServer(app);

server.listen(port, hostname, function(){
    console.log(`Server running at ${hostname}:${port}/`);
});

In this app, we’re going to be using Express as our web application framework. Express is super popular, read their docs if you’re interested, I’m not going to dive into it too deeply here. I’m actually not going to get too deep into this code except to point out a few things. Let’s run our server with node 4_helloexpress.js. When we go to the website we should have a simple form.

This is coming from line 15 where we tell Express to serve the files in the public folder. The public folder has three files which make up our front end. Take a look at frontend.js back in Cloud9:

var submit = document.getElementById('submit');

var captureData = function(e) {
    var data = document.getElementById('data');
    sendData(data.value);
}

var sendData = function(message) {

    var xhr = new XMLHttpRequest();
    xhr.open("POST", '/', true);
    xhr.setRequestHeader("Content-type", "text/html");
    xhr.onreadystatechange = function() {
        if(xhr.readyState == XMLHttpRequest.DONE && xhr.status == 200) {
            console.log('Sending: ' + message + '. Successful!');
            console.log(xhr.response);
        }
    }
    xhr.send(message); 
}

submit.addEventListener("click", captureData);

Now if you’re using Chrome (which we at freeCodeCamp Nashville recommend), open up the console (sorry none Chrome peeps) back on that ugly purple page ctrl + shift + i or cmd + shift + i should do it. If not, right-click anywhere purple and choose the “Inspect” option. You’ll see an error about favicon.ico and you can ignore that. What we want to show off here is the front end (browser) talking to the back end (server). We’re going to show this off through logging stuff to the two different consoles. So when we type something into our form and click “Submit” we should see this in our browser console:

and this in our Cloud9 server terminal:

When we click “Submit” we’re doing a POST request on line 11 of frontend.js and on line 14 we’re creating that first console message we see in our Chrome console if the data is sent successfully. Then back in our 4_helloexpress.js on line 26, we set the server up to listen. Our front end just sent the POST so the server “hears” that and handles it on line 18 because it’s a POST. On line 19 it logs to the Cloud9 terminal what we saw before and on line 20 it sends some stuff back to the front end. Finally, line 16 in frontend.js receives the stuff the back end just sent in response and logs that to our Chrome console. That’s a lot of back and forth but illustrates how browsers and servers “talk” to each other.

Hopefully, this piqued your interest and you want to start building your own full stack JavaScript apps. Or maybe now you know just enough to start having fun and playing around. If you want to hook up with us who are a part of freeCodeCamp Nashville check us out on Meetup at freeCodeCamp Nashville. We also have a Free Code Camp Nashville Facebook Page. My favorite is the #freecodecamp channel on the NashDev Slack network. If you want to get in on that, go to the link, enter your email, you’ll get an invite to the network, set up your account, once you log in you’ll be dumped into the #general channel by default, type /join #freecodecamp and hit enter and you’ll be right there with us chatting.

A few more pics from the meetup:

The post freeCodeCamp Nashville October Meetup Recap appeared first on Seth Alexander.

Staying Active Coding

While this seems like a standard practice I know it’s not. I’ve watched many boot camp graduates GitHub accounts go from consistent commits to zero after graduation. This is something I prepared for as I worked on my portfolio projects. I always knew ways that I wanted to extend them. Although, now that I have the freedom to learn ANYTHING I need to stay on track. As soon as I became a graduate a Node.js track opened up for me in my courses listing. This is attractive as I could round out some full stack JS knowledge. I also purchased Wes Bos’ Learn Node course while I was going through the boot camp so I have that too.

It’s easy to become lax though. It’s nice to take a breath and relax. I’ve worked hard and I deserve a break, right? Well, no I don’t. I still have to work my butt off. I’m at the bottom right now and the climb is hard. However, the job search is pretty much full time in and of itself so now I need to find time to code too? Yes. Here’s the plan:

1. Refactor my React with Redux project to pull from the Yelp API instead of from the Rails API I built it on. Then implement comments being persisted in the DB.
2. Finish the TODO items I left open for the rest of my projects. Work on the Ruby CLI Gem first, then my jQuery front end, then my Rails project, then my Sinatra project (maybe).
3. Node.js is next. First the Flatiron track then Wes Bos’ course.
4. If I’m still looking for work at this point I’m not sure what I’ll dive into. I might choose to build my React app using other frameworks to acquire familiarity and demonstrate my ability to learn other things.

Ultimately, I don’t want my GitHub to go stale. I’m also working on algorithm challenges to prepare for technical interviews. I’m mostly working on CodeFights currently as they have an Interview Prep set of problems. However, I’ve done problems on Codewars which are fun and I hear a ton of good things about exercism.io which I’ll probably dive into once I’m done with CodeFights stuff.

Networking

While this might seem like a natural thing for me, former restaurant manager, bartender, meetup co-organizer, meetup attender, etc… It’s always awkward to reach out to someone for the first time. Luckily, I have help with this. There are some awesome resources for this in Nashville as well. I’m sure if you look around there are resources in your city as well.

Meetup.com has to be the #1 resource for networking around shared topics. There are so many user groups and these are open to the public. So, everyone at a meetup event is already a warm contact. They expect to be approached and talked to. Adding to that the topic should hopefully be something that you are interested in and can speak somewhat about. I’ve had some great conversations, met some awesome engineers and established friendly contacts that I hope to maintain long-term.

Another great place to check out, and meetups will help you find these, are Slack networks in your city. Nashville has the NashDev Slack network which is a central place for people in IT in Nashville to chat. I’ve asked questions there and learned a ton from the responses from lead engineers and seasoned developers who have helped me with no strings attached. The best part is, some of these people I’ll probably end up interviewing with. Now I’m not a random name but someone that they have conversed with and taught before.

In addition, look for groups specifically for people to extend their learning. Started in Nashville and slowly spreading I found Penny University. I think they describe the idea better than I can paraphrase:

The name “Penny University” is a reference to the early coffeehouses in Oxford England. These coffeehouses held an important association with the European Age of Enlightenment. For the price of a penny, scholars and laypeople alike would be given admittance to the coffeehouse, enjoy an endless supply of coffee, and more importantly enjoy learning through conversations with their peers. Thus these coffeehouses came to be called “Penny Universities”.

Our new group, Penny University, serves as a modern take on this old tradition by connecting those who desire to learn with those who are willing to share what they know. This can certainly be at a coffeehouse, but anywhere else as well, including just a quick Google Hangout.

There are no mentors or mentees, leaders or followers. We are all peers and we are here to both learn and to teach.

Not surprisingly Penny U has their own Slack network.

Look for ways that you can donate time to coding. It’s a great way to work next to Senior developers and learn. In addition, the contacts are great. You’ll demonstrate not just what you know but how you can interact in a team setting. An awesome place to start is [Code for America] and then track down your local [Brigade] that does civic projects. I recently attended a [Code for Nashville] meetup and got hooked in with them. Was told to join their Slack network and learn some Node.js for the project they’re getting ready to start.

A final piece to networking is meeting people for 1 on 1 conversations. While these can be the most intimidating hopefully they aren’t completely cold. I know that I’m only asking people that I’ve met in person at a meetup or have spoken with via Slack to some extent. I’m meeting some great people this way and as soon as I’m done with my project refactors I’m going to start asking for code reviews which will help level me up as a developer too.

Let’s see if I can beat the odds and land a job quicker than the average bear through these efforts.

The post The Full Time Job before The Full Time Job appeared first on Seth Alexander.

So one problem I ran into was not getting the data from my API when I called fetchPlaces(). I was stumped. By all accounts, it should be working. My API was returning proper JSON formatted data. I had:

// fetch places
function fetchPlaces () {
  return (dispatch) => {
    dispatch({type: 'FETCH_PLACES'})
    return fetch('http://localhost:3001/api/places')
      .then(response => {
        dispatch({type: 'RECEIVED_PLACES', payload: response})
      })
      .catch((err) => {
        dispatch({type: 'FETCH_PLACES_ERROR', payload: err})
      })
  }
}

I couldn’t for the life of me figure out why I wasn’t getting the data that I needed back. I considered using parseJSON() but I didn’t think I needed to since the data being returned was already JSON. I was going to use it just like that as well. I wasn’t accounting for the fact that I was using fetch() to retrieve the JSON from my API. For more about the small, but important piece, that I was missing take a look at Using Fetch followed by Body.json() on MDN. With that knowledge, I was able to fix my call by implementing .json() on line 7 below followed by another .then which now has the proper data to pass into the payload.

// fetch places
function fetchPlaces () {
  return (dispatch) => {
    dispatch({type: 'FETCH_PLACES'})
    return fetch('http://localhost:3001/api/places')
      .then(response => {
        response.json()
        .then(json => {
          dispatch({type: 'RECEIVED_PLACES', payload: json})
        })
      })
      .catch((err) => {
        dispatch({type: 'FETCH_PLACES_ERROR', payload: err})
      })
  }
}

Another issue I ran into was a CORS violation. CORS stands for “Cross-origin resource sharing” and can be described as:

Cross-origin resource sharing is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain from which the first resource was served. A web page may freely embed cross-origin images, stylesheets, scripts, iframes, and videos. Certain “cross-domain” requests, notably Ajax requests, however, are forbidden by default by the same-origin security policy.
— Wikipedia

If that doesn’t make sense, don’t worry. Just know that CORS is implemented for security on the web. However, it also meant that unless I explicitly stated that my React app could talk to my Rails API I wasn’t going to be able to get the data. Luckily, there is a pretty easy way to enable this and it only took a few lines of code. I first added gem 'rack-cors', :require => 'rack/cors' to my Gemfile and ran bundle. Next, I had to add some code:

# /config/initializers/cors.rb

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins 'localhost:3000'

    resource '*',
      headers: :any,
      methods: [:get, :post, :put, :patch, :delete, :options, :head]
  end
end

This enabled my React application running on localhost:3000 to talk to my Rails API server running on localhost::3001 with no problems.

Ultimately I learned A LOT doing this project. I’m not 100% happy with where my app is at currently. However, to my understanding, it fulfills all the requirements of the project and that’s what I was shooting for. I can see abstracting it away from the back end and setting it up to pull all data from an external API call instead. Having built the back end though I know that it’ll always work the way I want it to and thus is a more stable project to include in a portfolio.

Check out Foodie View and see what you think for yourself. I’ll get it up on Heroku soon and will link to it from GitHub.

Time spent total: 457:50
Lessons completed total: 689

The post So Close to the End appeared first on Seth Alexander.

let itemsValues

$(() => {
  $.getJSON('/items.json', function (data) {
    itemsValues = $.map(data, function (e) {
      return e.id
    })
  })
})

Then, I wanted the functionality that I stated above. However, I didn’t want to get to the last item and just have a button that does nothing because there’s no next item. I also didn’t want the button to just disappear (I did that and I thought it was weird). So I decided when we reached the last item we should loop back around and go to the first item again. So I started coding and got to this point:

$('.js-next').on('click', function() {
  let nextIndex = itemsValues.indexOf(parseInt($('.js-next').attr('data-id'))) + 1
  $.getJSON('/items/' + itemsValues[nextIndex], function(data) {
    $('#name').html(data['name'])
    $('#rating').html(data['rating'])
    $('#notes').html(data['notes'])
    if (nextIndex === itemsValues.length)
      $('.js-next').attr('data-id', itemsValues[0])
    else
      $('.js-next').attr('data-id', data['id'])
  })
})

So my “Next Item” link has a class of ‘js-next’. Then I set a nextIndex variable by getting the current data-id of my link (ie, the current item being displayed ID number), turning that into an integer, finding the index of that ID in the itemsValues array and adding one to it. Then I call my internal API and get the next item’s info as a JSON object. I then fill in the new data to the DOM. Finally, I have an if…else block where I try and set the data-id to the first item ID if the new item is the last item in the array. If not, set it to the now current item ID.

Looking at this now I think the logic is flawed because I increment by one on the API call after the click. So setting it to the first item before the click will eliminate one item from ever showing up. I actually had this happen and couldn’t figure out why. This logic was fuzzy but is probably why I ended up moving the if…else logic to the top of my function and when I did it worked!

$('.js-next').on('click', function() {
  let nextIndex
  let dataIdIndex = itemsValues.indexOf(parseInt($('.js-next').attr('data-id')))
  if (dataIdIndex === itemsValues.length - 1)
    nextIndex = 0
  else
    nextIndex = dataIdIndex + 1
  $.getJSON('/items/' + itemsValues[nextIndex], function(data) {
    $('#name').html(`${data['name']} -
        <a href="/items/${data['id']}/edit">Edit</a> -
        <a data-confirm="Are you sure?" rel="nofollow" data-method="delete" href="/items/${data['id']}">Delete</a>`)
    $('#rating').html(`Rating: ${data['rating']}`)
    $('#notes').html(`Notes: ${data['notes']}`)
    $('.js-next').attr('data-id', data['id'])
  })
})

I also filled out the HTML for the name section of the page using those lovely template literals I talked about in my last blog post. This project is coming along well. I’m hoping to be done with it tomorrow night at some point in time. If I can finish this off before the weekend I’ll be super happy and think right on track to be done before the end of the month.

Time spent today: 2:16
Time spent total: 394:16
Lessons completed today: 0
Lessons completed total: 646

The post Sometimes The Logic Is Flawed appeared first on Seth Alexander.