DEV Community: Bennett Dungan

Tydii - Decluttering App

Bennett Dungan — Mon, 08 Jun 2020 14:46:09 +0000

As a follow-up to my How to Escape Tutorial Hell article, I referenced this little app I was building off to the side to use as my showcase example. This app is the product of following through with that whole process I laid out.

Check it out here: https://www.tydiiup.com

It's a mixture of my interest in minimalism and as something to practice using NextJS and React. The idea, in a nutshell, is that people have emotional ties to their belongings which makes getting rid of certain items harder than others. The app allows the user to rate each individual item they are on the fence about keeping on a 'happiness' scale denoted by facial expressions. Once you're done with that, it filters out the things you weren't completely happy with and brings you to a dash that helps you keep track of the items that you're either selling or donating (or throwing away, lol).

The part I upgraded the past couple months was implementing a user login system which encrypts and stores user data in a MongoDB database. I then built a dashboard that helps people keep track of their things as they get rid of them.

It's by no means perfect, but I've come to a point in this project that Im okay with some of the imperfections and will circle back to them at a later date.

I essentially built it for myself when I go through bouts of decluttering. I hope some of you also find it useful as well. Feel free to (deep breath...) check out the code on Github. Im sure it could use lots of improvements!

A Definitive Guide for Escaping Tutorial Hell

Bennett Dungan — Sat, 29 Feb 2020 23:59:50 +0000

There's quite a few articles floating around the interwebs in regards to the whole "tutorial hell" dilemma that many developers face. They tell you to apply what you've learned by giving you some ideas for projects and how to contribute to open source but I feel those are the end goals. What I usually find missing is how you go from an endless cycle of tutorials to successfully applying that knowledge to real world projects. I've made my own little system for escaping the never ending spiral of the tutorial hell hole that I think some of you might find beneficial.

What is tutorial hell and how did I get here?

One thing we need to have a clear understanding of before we dive into the strategy is why we get stuck in this predicament to begin with. I personally find myself in this cycle sometimes so I know how alluring it can be to build something flashy in a perfectly sanitized environment that the instructor has laid out for you every step of the way. That's one of the seductive things about tutorials though, they are these pristinely engineered walkthroughs of something that has no gotchas along the way because you're being held by the hand. This gives you a perpetual sense of accomplishment when we all know coding is generally all about pushing through roadblocks and constant challenges.

Don't get me wrong, I devour tutorials like crazy because it's how I personally learn to use a tool or language. There's a distinction that you need to make though, you either become a 'tut slut' or you know when to pump the breaks and use that knowledge for something useful before it goes stale.

Step 1: List any app idea you've ever had

The first thing to do after binging a whole season of Wes Bos n' Friends or the Coding ChooChoo Train is to just jot down a list of apps that you think would be cool. Like literally anything, the sky's the limit at this moment. Your knowledge need not apply, just write down anything you think would be fun or useful to use in your own life. I usually find the most inspiration by thinking of small annoyances I have each day and think if there is any sort of usefulness an application could bring to the table. This might take a few days too, I rarely have a good idea the first time I think about this. Sometimes it’ll hit me when I'm doing something completely irrelevant. Here’s an example list of items I’ve jotted down:

minimalism app for getting rid of items
astronomy events reminder app
drive your roomba manually app
hide everything except events on facebook
ebay price history from pictures

Step 2: List your tutorials

Now you've got this little list of cool app ideas, nice! Before we whittle that list down some, we need to make another list but this time it's of all the tutorials you recently completed. Don't worry if you didn't finish the tutorial either, even if you got 20% of the way through just jot that down as well. Here’s the most recent ones I’ve done:

API Design in Node
Typescript Fundamentals
React todo walkthrough
Design for Developers
Playing around with React Dnd
JWT Authentication and Login

Step 3: Pair the apps to the tutorials

In this phase we need to take each app and find any tutorial that we think would be beneficial in building it out. In the end we will see which app idea has the most relevance from our recent learning cycle:

minimalism app for getting rid of items - 4 total
1. Design for developers
2. Typescript fundamentals
3. React todo walkthrough
4. JWT auth and login
astronomy events reminder app - 4 total
1. Design for developers
2. Typescript fundamentals
3. JWT auth and login
4. Api design in node
drive my Roomba manually app - 0 total
- (moonshot idea, no realistic overlap from recent tutorials)
hide everything except events on facebook - 1 total
1. Design for developers
eBay price history from pictures - 3 total
1. Api design in node
2. Typescript fundamentals
3. Design for developers

Note: You may not really know what types of tools, libraries, frameworks are required for your app idea and that’s ok! Just put down anything you’ve recently learned that you think may even remotely benefit you during the build process.

Step 4: Pick the most exciting app/tutorial combo

In this step we want to analyze our top app ideas with the most tutorials and decide which of these are the most interesting and/or inspiring to work on. In my case, my top two are “astronomy events reminder app” and “minimalism app for getting rid of items” . I really love astronomy and would love an app to remind me of specific events (meteor showers, ISS overhead, full moon, etc), but this would be more of a ‘for fun’ app. The minimalism app would actually help me solve a problem I have been having lately and that is trying to decide what items to keep or give away. In this example I decide to go with the minimalism app because I like the idea of solving a real issue.

Step 5: Strip it to the essential building blocks

Right on, so we have an app idea that has a solid foundation of tutorials and some inspiration. This step is to lay out the high level functionality of our app and see where the tutorials we completed can help us out:

Minimalism App:

Needs to list out items with add/delete feature:
- I can use the React Todo tutorial to build out the whole list feature. This is the base feature for the application so I can either take the React Todo app I built and just modify it or reference the tutorial again as I am adapting it for my specific needs.
Needs a rating system for each item
- The rating system isn’t something I’ve specifically tackled, but it’s something I know I can figure out along the way.
User login and authentication to save list:
- The JWT Auth Login tutorial I did can help me out for making a user login system
Simple but inviting design
- Not an essential, but I’d like for the app to be appealing to use so I can use the Design tutorial for this part

I’ve got around 75% of the application covered by the tutorials I’ve completed, the other 25% is something I can just use some Google-Fu to cover.

In the end, I actually made this app with the above process. You can view it HERE.

^{I haven’t gotten to adding user auth just yet but the majority of my idea was completed using the above steps.}

Conclusion

I hope by breaking down your tutorials into building blocks for an application proves to be useful. You’re probably more ready to build that app idea you’ve always had, you just need to take time to analyze the app's essential functionality and identify all the areas you’ve already covered in tutorials. You’re never going to know 100% of everything needed, but that’s literally with everything you’ll ever do as a developer.

Since most of you reading this are looking to escape the tutorial hell spiral, I’ve framed this system as something to do on your first venture of escaping that void. What I do now is actually decide on something I want to build and then figure out what I know/don’t know and watch or read a few guides on those unknowns (but not too much, just enough to get 80% of the way there). I’d love to know what everyone else’s strategies are so feel free to drop a comment down below.

♫ Writing Music ♫

^{I thought it would be fun to just share some of the tunes I listen to while writing :)}

Review: 100 Hours of Front End Masters

Bennett Dungan — Sun, 16 Feb 2020 21:34:54 +0000

NOTE: I have no affiliation with Front End Masters nor any of the people mentioned in the review. All of the opinions are solely my own.

I've been lucky enough to spend over 100 hours using the Front End Masters program for the past year and I've decided that I've gotten a good enough feel for the quality of it to give an honest review. Being that the course can run a few hundred $$$, a lot of people might want to know if its worth the money. Hopefully, I can make things a bit clearer for those of you who are undecided.

I've divided this review into 4 sections:

Content
Teaching Style
Suggested Improvements
Conclusion

CONTENT

One of the main reasons I enjoy FEM is the sheer amount of content that is available. They cover everything from Node, React, Vue, Angular, general CS, GraphQL, Javascript, Python, CSS, SVGs, Design, CSS, etc etc. They do a great job at keeping the range of topics very broad and for someone like me, whose getting their feet wet in this whole industry, the diversity of content has been fantastic.

There definitely is more focus on certain frameworks/technologies over others though. I develop in React and there's a ton of React content but for someone who wants to focus on Vue, the amount of content for that is marginal in comparison. Luckily, you can browse their entire catalogue of courses to determine if they have an adequate amount of lessons on the things you would like to learn before you sign up. The length of the lessons vary a bit but almost all of them are long-format ranging between 3 to 10 hours in length. As long as the topics being taught aren't too broad, I've found that you can get through quite a bit of content over this time-frame.

Teaching Style

The style of teaching is in front of a live classroom. While this may or may not be conducive to your learning style, I find that the interaction between the teachers and students helps to fill in some gaps that I typically don't get during traditional video lessons. Most of the teachers are full-time developers themselves so they bring a ton of real-world scenarios and perspectives into their teaching style. I just finished up a course called Full Stack for Front End Developers by Jem Young who works at Netflix. He sprinkles in bits of information about how Netflix utilizes some of the technologies being taught and that added a whole new layer of knowledge that connects real-world scenarios to the things you're learning in the classroom.

One of the best things about FEM is when the teachers actively get the students involved. I know we all hated it when teachers called on us in school to answer questions, but as a 3rd party viewer its extraordinarily helpful to have these students answer questions you may have been scratching your head about yourself. The students sitting in the live audience usually range from beginner to advanced so in every class you'll get a range of questions being brought up. One of the grand masters of getting the students involved (along with killer white-boarding skills) is Will Sentance.

I believe this guy should be one of the benchmarks when it comes to how people should teach code. The enthusiasm mixed with step-by-step drawings and explanations broke a mental barrier I had on a lot of JS concepts. Many of the teachers are great about giving detailed explanations on how to do X without going at breakneck speeds, which is a plus for me.

Suggested Improvements

As with everything, the program isn't for everyone and could be improved. One of the great things I was touting earlier, the live teacher/student interaction, doesn't actually happen on all courses taught. Some of the teachers don't really get the students involved and I find that these lessons have a lot less retention for me. I think the FEM organizers should make it mandatory that the teachers have some level of interaction with the students because it makes a huge difference for the 3rd party viewers.

Another issue I've had is that there doesn't seem to be an outlet for students to interact with one another and/or find help with the courses. One thing I enjoy about Wes Bos's paid courses are the Slack groups. There's always a handful of people able to help you if you're ever stuck in one of his lessons. If you get stuck on a FEM lesson, you're kinda out of luck unfortunately.

One thing in regards to accessibility is the closed captions. Its great that they have them on every video but sometimes I notice misinterpretations of what is being talked about. IE. "git" will be translated to "get" or "vue" to "view". I can imagine a hearing impaired dev might get a bit confused if they're solely relying on the captions so its definitely one area that could be improved.

This one is kind of nit picking and almost counter-intuitive given that the name of the program is 'Front End Masters' but I really wish there was more back-end courses. As I've gone through a bit of the front-end technologies, I've gotten more and more interested in the back-end. I love the teaching style and besides the Full Stack course I mentioned before with Jem Young, there really isn't a whole lot of back-end lessons. Again, I know how counter-intuitive this sounds but its an option I wish I had given that I enjoy the format so much.

Conclusion!

Should you buy the program? Well if you enjoy the live & interactive classroom teaching style then yes, I find it to be a fantastic resource and worth the money. The variety of subjects and teachers keeps things fresh and the quality of the content is always impressive.

As someone who just started out in this industry, I've found the content fascinating and I'm always looking forward to the newer courses that get released. If you have any specific questions about the program that I didn't cover, feel free to ask me in the comments below.

Build a REST API with Node, Express & MongoDB!

Bennett Dungan — Thu, 01 Aug 2019 21:31:45 +0000

In this project we will be creating a way for people to subscribe, update, retrieve and delete data on Youtube accounts. We’ll do this by coding a REST API that lets users interact with our Youtube database by defining what info our database will accept and how it goes about manipulating that data depending on what a user would like to do.

A big shoutout to Web Dev Simplified for the knowledge he was able to pass along in helping me create this tutorial. If you’d prefer to see a video walkthrough for this then I highly recommend checking out Web Dev Simplified’s tutorial HERE

MY GITHUB REPO

If you get stuck or think you did something wrong and can’t quite figure it out, refer to my Github Repo of the completed application here: https://github.com/Beznet/node-api

Project and Dependency Setup

Important Prerequisite: Make sure you already have MongoDB installed and setup on your machine before starting this tutorial. Here is a link to a guide that MongoDB provides on their website: MongoDB Installation

First, let’s open our terminal and create a new directory for this project. Now in our terminal type npm init to start and just leave all fields blank for the time being by pressing ENTER through each question. Next we want to install Express and Mongoose:

npm i express mongoose

Then once those two are finished being installed we need to also install dotenv and nodemon by entering:

npm i --save-dev dotenv nodemon

Note: --save-dev from above will save development-only dependencies without saving them to production

dotenv will allow us to pull in environment variables from a .env file and nodemon will update our local server each time we save

When we ran npm init earlier it created a package.json file. In this file under the scripts we want to replace that ‘test’ script with our own script that starts our server with nodemon:

"scripts": {
  "devStart": "nodemon server.js"
}

Setting Up Our Server

Ok now we get to create our first file called server.js . Once created, at the top of the file we want to include all of the dependencies that we will need for our project:

const express = require('express')
const app = express()
const mongoose = require('mongoose')

When we want to test and make sure our server is working, we will run this function to listen on port 3000 and log a string if its successful:

app.listen(3000, () => console.log('server started'))

At this point our server.js file should look like this:

const express = require('express')
const app = express()
const mongoose = require('mongoose')

app.listen(3000, () => console.log('server started'))

Connecting to Our Database

This next chunk of code in our server.js file starting with mongoose.connect is how we connect to the database. I’ll explain it line by line:

const express = require('express')
const app = express()
const mongoose = require('mongoose')

mongoose.connect(process.env.DATABASE_URL, { useNewUrlParser: true })
const db = mongoose.connection
db.on('error', (error) => console.error(error))
db.once('open', () => console.log('connected to database'))

app.listen(3000, () => console.log('server started'))

The first line allows us to connect to the database using Mongoose. You may be wondering what DATABASE_URL is, this is the location we want for our database which I have defined in our .env file. If you haven’t created a .env file, now would be a good time and then you can set the DATABASE_URL there:

// .env file

DATABASE_URL=mongodb://localhost/subscribers

After we have our DATABASE_URL defined in our .env let's hop back to our server.js file. Now to reference variables in our .env file we need to require the dotenv package at the top of our server.js file:

require('dotenv').config()

After we get that package required the line of…

mongoose.connect(process.env.DATABASE_URL, { useNewUrlParser: true })

…will now function appropriately.

Moving on, we have set db to mongoose.connection as a syntactically easier way to reference our database. Next, we’ve defined what happens when the database encounters an error, which is to log the error itself. If there’s no error we want to log the string of connected to database to our terminal.

Ok! That’s a lot of stuff. So to sort of put everything together our server.js file should now look like this:

require('dotenv').config()

const express = require('express')
const app = express()
const mongoose = require('mongoose')

mongoose.connect(process.env.DATABASE_URL, { useNewUrlParser: true })
const db = mongoose.connection
db.on('error', (error) => console.error(error))
db.once('open', () => console.log('connected to database'))

app.listen(3000, () => console.log('server started'))

Let’s Test Our Database Connection!

At this point we can now test out our connection to the database to make sure everything is working smoothly. In our terminal, let’s go ahead and start our database by typing mongod and then in another terminal tab let’s start our server with npm run devStart. If all went well, we should get these messages after we start our server:

Cool! We’ve successfully started our server and our database appears to be operational.

Setting Up Our Server to Accept JSON

In our same server.js file we want to tell Express that it should accept JSON. Lets put this line of code in between our ‘database is open’ line of code and the ‘listen on port 3000’ line:

...
db.once('open', () => console.log('connected to database'))

app.use(express.json())

app.listen(3005, () => console.log('server started'))
...

The .use is middleware that allows you to run code when the server gets a request but before it gets passed to your routes. So in this instance we’re telling Express to accept JSON as the data format.

Creating Our Routes Folder & File

Let’s create a new directory for our routes to live in called routes and then a file in this directory called subscribers.js . Inside of this file is where we will define how the server should handle the data when it receives a GET, POST or PATCH request.

But before we start creating those, lets switch back to our server.js file and tell the server that we now have routes that it needs to handle and use. These next two lines of code are actually the last ones we need for our server.js file.

const subscribersRouter = require('./routes/subscribers')
app.use('/subscribers', subscribersRouter)

Here’s the full server.js file with the new lines of code added:

require('dotenv').config()

const express = require('express')
const app = express()
const mongoose = require('mongoose')

mongoose.connect(process.env.DATABASE_URL, { useNewUrlParser: true })
const db = mongoose.connection
db.on('error', (error) => console.error(error))
db.once('open', () => console.log('connected to database'))

app.use(express.json())

const subscribersRouter = require('./routes/subscribers')
app.use('/subscribers', subscribersRouter)

app.listen(3005, () => console.log('server started'))

If something is missing or incorrect, right now is a great checkpoint to make sure you’ve got everything updated with the above. Give yourself a pat on the back for getting this far! We’re getting onto the fun stuff next…

Setting Up Our Routes

Now that our server file is all setup, let us now switch gears to our new subscribers.js routes file. To start, let us require Express and define the express.router() function on a variable called router . While we’re at it let’s add our module export function as well at the very bottom:

const express = require('express')
const router = express.Router()

module.exports = router

Before we get into the code, let’s get an understanding of what we exactly want to do with our routes. Since we’re trying to see and artificially create new subscribers on Youtube, we need this set of criteria:

Route for getting all subscribers
Route for getting one subscriber
Route for creating one subscriber
Route for updating one subscriber
Route for deleting one subscriber

Now let’s start each of the bullet points above with the basic framework depending on if its a GET, POST or PATCH request:

const express = require('express')
const router = express.Router()

// Get all subscribers
router.get('/', (req, res) => {
})

// Get one subscriber
router.get('/:id', (req, res) => {
})

// Create one subscriber
router.post('/', (req, res) => {
})

// Update one subscriber
router.patch('/:id', (req, res) => {
})

// Delete one subscriber
router.delete('/:id', (req, res) => {
})

module.exports = router

The GET, POST and DELETE methods should look familiar but if not here’s a little refresher on them . The one thing that might look weird is the PATCH method. The PATCH method is being used here instead of the more traditional PUT method because we only want to use this to update pieces of the subscriber’s information and not all the information of the subscriber.

You also may have noticed that we include /:id in most of our parameters. This is for the routes that are requesting an action to be taken on a single subscriber thus we need that subscriber’s unique ID.

Testing Out Our API

Let’s take a little break from our routes and test out our API with what we have so far. Inside of our ‘Get all subscribers’ route, let’s send text to our server:

// Get all subscribers

router.get('/', (req, res) => {
   res.send('Hello World')
})

Now for testing our API, I am going to use a Visual Studio Code extension called REST Client. If you do not have VS Code then you can use another program called Postman that will also aid in testing the API. For this tutorial I will be using just REST Client in VS Code.

Once you have the REST Client extension installed, let’s create a new file in our routes folder for us to run our tests and call it route.rest. It needs to end in .rest or else it will not work correctly with REST Client.

Great so now let’s write a test GET call to our server inside of our route.rest file:

GET http://localhost:3000/subscribers

Make sure you have /subscribers after the 3000. Now if you hover above that line you just wrote, you should see ‘Send Request’ appear above it. Click that and watch on the right hand side of your screen for the result. If all went well, it should look something like this:

On line 9, we can see that the server sent back ‘hello world’. This means our API is working correctly! Ok so we’ve done a lot so far, let’s take a hydration break and then we’ll get started with models.

Making the Model

Let’s go ahead and setup our model and the schema inside of our model. A schema is how our app defines what the data looks like and also sets up the document in MongoDB. If that sounds confusing, it’ll make more sense once we see what’s going on.

Let’s first start by creating a new folder called models. Inside of this folder, let’s create a new file called subscriber.js. Notice how we’re naming this file ‘subscriber’ singular as opposed to our routes file which is ‘subscribers’ plural. The idea is that the model will handle how each and every subscriber, on an individual level, will look inside of our database. The ‘subscribers’ routes handles sometimes multiple subscribers requests such as Get All Subscribers route. It’s an important thing to mention as verbiage is important when naming files in projects.

In this new file, we want to first require Mongoose since we will be using their schema models:

const mongoose = require('mongoose')

After we require mongoose, we’ll start by defining our schema

const mongoose = require('mongoose')

const subscriberSchema = new mongoose.Schema({})

Inside of this javascript object will be all of the keys for the different properties of our subscriber. These keys will include name, subscribedChannel and subscribeDate. We essentially want to tell our database what to expect from each one of these key’s such as their type, if they’re required and if a default value should be applied.

const mongoose = require('mongoose')

const subscriberSchema = new mongoose.Schema({
  name: {
    type: String,
    required: true
  },
  subscribedChannel: {
    type: String,
    required: true
  },
  subscribeDate: {
    type: Date,
    required: true,
    default: Date.now
  }
})

The type and required properties should be pretty self explanatory. These are defining the expected schema type (a String and Date in this case) as well if that key is required upon entering information for a new subscriber.

One thing to note about subscribeDate, we set the type to Date instead of String since we will be expecting a date from the user. If no date is provided then we default it to the current date by using Date.now .

Moving on, the last line of code we want to write in our schema is the module.exports. This will allow us to use and interact with the database using our schema. Mongoose has a special way of exporting models utilizing mongoose.model() that takes two properties:

// exporting our subscriber schema

module.exports = mongoose.model('Subscriber', subscriberSchema)

‘Subscriber’ is the name we want to give the model in our database and then the next one is the schema that corresponds to that model which is our subscriberSchema.

That’s it for our model! Let’s take a look at the finished schema to make sure we’ve got it all:

const mongoose = require('mongoose')

const subscriberSchema = new mongoose.Schema({
  name: {
    type: String,
    required: true
  },
  subscribedChannel: {
    type: String,
    required: true
  },
  subscribeDate: {
    type: Date,
    required: true,
    default: Date.now
  }
})

module.exports = mongoose.model('Subscriber', subscriberSchema)

Routes – Create and Get Subscribers

Now that we have our model setup with a schema for our database, let’s require it in our subscribers.js route file below where we required router

const express = require('express')
const router = express.Router()
const Subscriber = require('../models/subscriber')

Now we can pick up where we left off with our routes where we coded a shell for each one:

// Getting all subscribers
router.get('/', (req, res) => {
   res.send('Hello World')
})

// Getting one subscriber
router.get('/:id', (req, res) => {
})

// Creating one subscriber
router.post('/', (req, res) => {
})

// Updating one subscriber
router.patch('/:id', (req, res) => {
})

// Deleting one subscriber
router.delete('/:id', (req, res) => {
})

We have our test response from earlier when we sent ‘Hello World’ to the server but we can go ahead and delete that since we want to actually tell that route to Get All Subscribers.

The first thing we’ll need to do, after we get rid of our old res.send('Hello World') line, is wrap the function in a promise with a try/catch statement:

// Get all subscribers

router.get('/', async (req, res) => {
  try {

  } catch () {

  }
})

Inside of our try statement we want to get all of the subscribers from our model. So we want to set a new variable called subscribers to that model with a .find() method applied to our Subscriber model.

// Get all subscribers

router.get('/', async (req, res) => {
  try {
    const subscribers = await Subscriber.find()
  } catch () {

  }
})

As the name implies, the find() Mongoose method works by returning all associated subscriber objects that meet its criteria. Since we’re returning all subscribers, we just leave the parentheses blank since we want all the subscribers:

After that line we then want to send a response with the data of our subscribers variable we just created in the form of JSON:

// Get all subscribers

router.get('/', async (req, res) => {
  try {
    const subscribers = await Subscriber.find()
    res.json(subscribers)
  } catch () {

  }
})

Finally, in our catch statement we want to just catch any errors that may occur and have it sent to the user as a 500 error in JSON format:

// Get all subscribers

router.get('/', async (req, res) => {
  try {
    const subscribers = await Subscriber.find()
    res.json(subscribers)
  } catch (err) {
    res.status(500).json({ message: err.message })
  }
})

Now that we have our route to send us all the subscribers in our database, we need to code a way for us to actually add a subscriber into our database. So, lets move onto our Create One Subscriber route so we can enter data about a subscriber:

// Create one subscriber

router.post('/', async (req, res) => {
  const subscriber = new Subscriber({
    name: req.body.name,
    subscribedChannel: req.body.subscribedChannel
  })

  try {
    const newSubscriber = await subscriber.save()
    res.status(201).json(newSubscriber)
  } catch (err) {
    res.status(400).json({ message: err.message })
  }
})

You can see its somewhat similar to our Get All Subscribers route except a few important differences. For one, we’re no longer doing a GET call on our database but a POST which will allow us to push data to our database.

On this line:

const subscriber = new Subscriber({...

we are creating a variable that will be assigned to a new Subscriber from our model that we created earlier. If you recall, we require a name, subscribedChannel and subscribeDate properties for a new subscriber.

These next two lines of code:

name: req.body.name, subscribedChannel: req.body.subscribedChannel

We’re telling our route to save the request made from a user’s input of a new Subscriber name property and subscribedChannel property. Our subscribeDate doesn’t need to be defined because it will default automatically to the date/time that this database entry is made.

The try and catch statements should look familiar. We’re instead using a .save() Mongoose method instead of find() because this is how we will tell the database that we want it to hold the information a user passes to us through this router function.

Lastly:

... res.status(201).json(newSubscriber) } catch (err) { res.status(400).json({ message: err.message }) }

We’re sending the user a response with a success status of 201 and to pass our new subscriber back to us as JSON. The catch is just like our Get All Subscribers route except we pass a 400 error since this would be a user error for passing us bad data.

Let’s Create and Get Our First Subscriber!

At this point we’ve created our Model and two Routes that will allow us to create a subscriber and then call that subscriber’s information from our database. Let’s switch gears back to our route.rest file and create our first user:

GET http://localhost:3000/subscribers

###

POST http://localhost:3000/subscribers
Content-Type: application/json

{
  "name": "Robert",
  "subscribedChannel": "Bennetts Channel"
}

With REST Client, we need to separate our different test requests with those three hashtags you see in between the two statements on line 3.

Our first request should be the exact same as before so the only different one here is our new POST request that allows us to create a new subscriber with their name (Robert in my case) and the channel they subscribed to (mine!). So lets run our POST request and see what we get:

If everything went well, our response when we click ‘Send Request’ should look like the above. We can see that we received our 201 success status at the very top along with our Subscriber object at the bottom with all the information we just plugged in.

Again, subscribeDate is set automatically to the date of creation so we don’t need to manually set it. Now lets use our Get All Subscribers request and make sure that it returns us Robert’s information:

Our response will look similar to our Create Subscriber response since we only have a single user in our database but if you create multiple subscribers then this will populate all of them for you.

The Middle-what? The Middleware!

We’re in the final stretch! The last things few things we need to do is complete our Delete, Update and Get One Subscriber routes and our REST API is complete!

One thing in common that all 3 of the last routes share is getting the ID of a specific user. Instead of writing out that part of the code 3 times over we can just put that piece of code in its own function and call it as middleware in the Mongoose GET/PATCH/POST statements. Lets place this middleware function called getSubscriber right before our module.exports = router line:

async function getSubscriber(req, res, next) {
  try {
    subscriber = await Subscriber.findById(req.params.id)
    if (subscriber == null) {
      return res.status(404).json({ message: 'Cant find subscriber'})
    }
  } catch(err){
    return res.status(500).json({ message: err.message })
  }

  res.subscriber = subscriber
  next()
}

There’s a lot going on here so let’s break it down. The first line should look pretty familiar except that new property called next . Basically, when next is called its telling the function execution to move onto the next section of our code, which is the route function this getSubscriber function will be added to.

Our try and catch statements are opened up as with our other routes. We then define subscriber on line 3 equal to our Subscriber model object which we will then use the findById method to find our subscriber that correlates to the ID the user passes in from the parent route. This will set the subscriber to an object equal to that id.

Side Note: This part can be a little confusing but hang on until we get to the Update/Delete/Get One routes below. I’ll make more sense when we see it in action.

Once we have subscriber set to our model’s object, we check with an if statement to see if that subscriber even exists with a null check. If the subscriber is nonexistent then we want to throw a 404 error. Then our catch is doing the familiar error check and sending the user back a 500 status code if that

Finally we’re left with our last two lines of code from our middleware function:

res.subscriber = subscriber next()

The res.subscriber is setting a variable on the response object which is equal to our subscriber object. This is useful so we don’t have to write that same line of code, we can just reference res.subscriber from this function. Lastly, we use the next() function after everything else is finished executing to tell the getSubscriber function to move onto the actual request.

Now that we’ve got our middleware function completed, let’s add it to our Delete, Update and Get One routes:

// Get one subscriber
router.get('/:id', getSubscriber, (req, res) => {
})

// Update one subscriber
router.patch('/:id', getSubscriber, async (req, res) => {
})

// Delete one subscriber
router.delete('/:id', getSubscriber, async (req, res) => {
})

Route – Get One Subscriber

We did most of the heavy lifting for these last 3 routes with our middleware so horray for that. Let’s start off with our Get One route:

// Get One Subscriber

router.get('/:id', getSubscriber, (req, res) => {
  res.json(res.subscriber)
})

Look how ridiculously simple that looks. All we have to do is send the user a response in JSON with the res.subscriber that we defined in our middleware function which returns that specific subscriber’s info. We can test this new route real quick to make sure our getSubscriber middleware function and this new route we created actually works.

Let’s hop back over to our route.rest file and create a new subscriber with our Create Subscriber request so we can get that subscriber’s ID:

Alright so we created a new subscriber and named him Bob and we can see he has a long ID associated with his object right above his name. I want to keep that ID so when we write our new GET route I can call Bob specifically by his ID. We can put this below our Get All Subscribers request:

GET http://localhost:3000/subscribers

###

GET http://localhost:3000/subscribers/5d3ce4ef1b5de0b79d3443b9

###

POST http://localhost:3000/subscribers
Content-Type: application/json

{
  "name": "bob",
  "subscribedChannel": "Bennetts Channel"
}

On line 5 is where we’ll create the new test request, so put in your newly created user’s ID (yours will be different than mine above) and click ‘Send Request’:

If everything went well, we shouldn’t see a change on our response to the right because we’re just calling the same user that we just created. Give yourself a pat on the back, your middleware function and Get One route works!

Route – Delete Subscriber

Now that we know our middleware is doing its job, lets switch back on over to our subscribers.js routes file and finish our last two routes starting with Delete:

// Delete one subscriber

router.delete('/:id', getSubscriber, async (req, res) => {
  try {
    await res.subscriber.remove()
    res.json({ message: 'Deleted This Subscriber' })
  } catch(err) {
    res.status(500).json({ message: err.message })
  }
})

We open up our try statement and then we plug in our await operator right before we set our res.subscriber to then use the remove() method to delete the subscriber that the res.subscriber object was set to. We then want to tell the user that we successfully deleted the subscriber by passing the response message in JSON:

res.json({ message: 'Deleted This Subscriber' })

As always, we want our catch to send the user the appropriate error if one did occur. That’s it for delete!

Route – Update Subscriber

Our Update Subscriber route is the very last thing we need to write for this application to be fully functional! Ok so before we get into the code lets get a general idea of how updating will work in this case:

User updates just the name
User updates just the channel
User updates both name and channel
Or they mess up and it throws an error

Our requirements need for us to essentially check and see if any changes were made and if so, update them appropriately. Now onto the code:

// Update Subscriber

router.patch('/:id', getSubscriber, async (req, res) => {
  if (req.body.name != null) {
    res.subscriber.name = req.body.name
  }

  if (req.body.subscribedChannel != null) {
    res.subscriber.subscribedChannel = req.body.subscribedChannel
  }
  try {
    const updatedSubscriber = await res.subscriber.save()
    res.json(updatedSubscriber)
  } catch {
    res.status(400).json({ message: err.message })
  }

})

We start our function off with a PATCH method, which we discussed when initially defining the shell of our routes. Now you can see we’ve added two if statements to our function. The first if statement is checking to see if the name coming from the body of the user’s request is not equal to null. This is an important check because if it is equal to null then that means the user did not pass any data about name through our route function. If they did then we move onto this line:

res.subscriber.name = req.body.name

Where we’re setting our subscriber’s name from res.subscriber and setting the name now equal to the new name that the user passed in from their request.

The same logic follows here:

res.subscriber.subscribedChannel = req.body.subscribedChannel

Where we’re checking to see if the user updated the subscribedChannel and if so, we then perform the same sequence of changing the current subscribedChannel to the new one from the user’s request.

After we’ve made these if statement checks we then want to tell the function to then save these new changes into our database. This is easily done within our try statement where we take the res.subscriber object with our new name and/or channel and then add the save() method onto it within a new variable called updatedSubscriber. We then want to pass this new updatedSubscriber object to our user in the form of JSON:

try { const updatedSubscriber = await res.subscriber.save() res.json(updatedSubscriber) }

That’s literally everything we need in our subscribers.js route file so let’s take a pause here and make sure we’ve got everything up to this point. Go to my github repo for this project and make sure your code accurately mirrors what I have before moving onto the final tests below.

The Final Test

We’ve completed our last two routes, let’s go into our route.rest file and test these bad boys out and make sure they work correctly.

Our Delete request is just as simple as our Get One Subscriber route except instead of using the GET request we’re naturally going to use the DELETE request instead. So get the ID of one of the subscribers in your database and let’s create that test route:

###

DELETE http://localhost:3000/subscribers/5d3e0db7cb4be0bfc4c25ff9

Now let’s click ‘Send Request’ and see if our user is successfully deleted:

Nice! So we can see we got a message of ‘Deleted This Subscriber’ on the right hand side which means we were successful. Now if you take that same ID that you just deleted and try to request it using our Get One Subscriber request, it should tell us that it cannot find that subscriber since they no longer exist in our database:

Our last request will be to update an existing subscriber’s information in our database with our Update route. Since we just deleted our last subscriber, go ahead and create a new subscriber and lets write our Update request using PATCH:

###

PATCH http://localhost:3000/subscribers/5d3e144ecb4be0bfc4c25ffa
Content-Type: application/json 

{
  "name": "Tommy"
}

I just created a new subscriber before running the above PATCH request and named them Lizzy:

Alright so if we run the above PATCH request we should see Lizzy’s name change to Tommy:

If everything went smoothly then we just were able to successfully update Lizzy’s name to Tommy.

Conclusion

Guys, we made it. I really hope this tutorial was helpful to some of you. We went over a lot of stuff so if you’re feeling overwhelmed then thats totally understandable. But realize we just made a pretty awesome backend piece of code that translates into so many different real-world applications. So big props to you for making it through it all!

If you ever got stuck or found something worth mentioning, go ahead and leave me a comment below. Also feel free to follow me on Twitter and Youtube as I post regularly on both. Happy coding everyone!

Originally published here

At work, do you have planned roundups with coworkers to discuss new and/or unfamiliar coding concepts?

Bennett Dungan — Thu, 06 Jun 2019 02:18:45 +0000

Im newer at my place of work and the skill gap is fairly large between myself and my coworkers. I was thinking of having a weekly 'roundup' of sorts where either I or someone else has a concept on the agenda to discuss. For instance, I just discovered what 'currying' is in Javascript and would love to discuss it with the others and see if there are ways we can implement it into our projects.

Does anyone else have these sorts of meetups with their coworkers to get on the same page knowledge-wise? If so, how are they typically structured?

Create a Horizontal Mobile Scroll Box Using CSS Flexbox and Media Query

Bennett Dungan — Mon, 13 May 2019 03:30:48 +0000

Originally published here

I had the chance to flex my CSS chops recently, which turned out to be pretty weak, but I learned a few cool things along the way. I was tasked to create a vertical list that transforms to horizontal scrolling when sized down to mobile. This was the outcome:

The two main takeaways from this came from using CSS's media queries and flexbox. I had only done some real quick and dirty CSS styling in the past so this was my first exposure to both of these two tools. I whipped up this simple Codepen version of the above where you can see the vertical to horizontal list and scroll in action. The majority of the magic comes from this little chunk of CSS:

@media (max-width: 992px) {
  .container {
      display: flex;
      flex-wrap: nowrap;
      height: 300px;
      overflow-x: auto;
      width: auto;
  }
}

The first thing you'll notice is that @media rule which is how Im telling the div with all the items to apply the subsequent CSS properties to the .container class. To put it simply, when the screen size hits 992px or lower, the .container class now changes/adds the listed properties starting with display: flex .

Next, we're adding flexbox with display: flex and then making sure that the items do not wrap within the container as we scale it down with flex-wrap: nowrap . I changed the height of the container to a more narrow 300px so it creates a mobile-friendly view of the item that scroll.

Sidenote: If you're unfamiliar with Flexbox , I highly recommend doing this interactive learning game: Flexbox Froggy . It teaches you most of the basic and some advanced properties of Flexbox by maneuvering a frog onto its lillypad.

Finally we add overflow-x: auto to allow the items within the container to have scrollable functionality on the X axis when the items spill outside of the parent container. Without this property we'd have something that looks like this:

Once we have all those properties put together, we're left with a nifty little item list that transforms to mobile-friendly horizontal scrolling:

Typically, you're going to be taking a list of items that is horizontal in desktop screen sizes and then scaling it down to a vertical list when hitting mobile screens. So we're essentially forcing the opposite to happen here which isn't too common and why its sometimes hard to find a solution for it on places like Stackoverflow.

Hopefully you found this useful. If you know of a better way or some clever little tricks I missed please be sure to let me know!

Life Update: I’m Officially a Developer

Bennett Dungan — Mon, 10 Dec 2018 01:55:53 +0000

It’s been awhile. I promise my absence has been for good reason though, not because I fell off the coding wagon. Actually, quite the opposite. As the title says, I got a freakin’ job as a web application developer! I was hired on back in September and have been there for about 3 months now. Since then coding has been apart of my daily life more than ever before so my blog updates have sort of taken a back seat.

I do apologize about the long hiatus though. From the interviewing process (which was quite brutal for someone of my novice skill level) to the job itself , life has been super draining. Don’t get me wrong, I’m learning loads of stuff each and every day but I now know this is where the real journey starts. Getting the job was just the beginning.

I definitely intend to give a full recap about the interview, personal struggles, how I overcame certain obstacles and ultimately landed the job but in the mean time I wanted to let everyone know that I’m alive and doing well. Until next time, happy coding!

Originally published on my blog

Learning Code While Working a Full Time Job

Bennett Dungan — Fri, 10 Aug 2018 02:51:58 +0000

Originally published here

This is about my journey of learning how to code while also maintaining typical 8 to 5. Spoiler, its hard as hell and the burn-out is super easy. Though I'm here to hopefully shed some light on what's worked for me and how I maintain my sanity...

1. Make coding your hobby

I've talked a bit about this in my previous posts but I think it's worth reiterating. I haven't had success in the past attempting to balance work, social activities, hobbies and learning code. There's just not enough time in the day to do everything I wanted so I had to prioritize. I used to come home after work and get online with friends to play games. As hard as it was, I've had to cut that out of my life temporarily. Anyone who's ever played online games knows that its a sinkhole for time. One moment you've promised to just play one 20 min game of Overwatch and the next thing you know it 3 hours have passed by. So it was imperative that I put a halt to this if I wanted to progress in any sort of fashion. I've also been cooking less than I used to. That's something I didn't want to see diminish but cooking can take me a whole evening of preparation, so I usually just opt for the simple sandwich or omelet lately (my girlfriend is upset by this side-effect). The point is, if the majority of your day is taken up by your day job then you're going to need to make major sacrifices. Its just the nature of the beast but a necessary step if you're wanting to progress.

Update: Just to clarify, I'm not suggesting to totally rid yourself of everything that makes you happy. My suggestion is to take a hard look at what you're doing before/after work and ask yourself "Is this worth my time? Can I utilize this time to learn code?". Assuming you're learning code to one day land a dev position, this is something I've found to work the best for me. Adjust your time constraints on leisure activities according to what fits your life balance.

2. Have a long-term outlook

This isn't going to come to you overnight. With the influx of these coding 'bootcamps' that promise to get you job ready in 3-6 months, the realistic expectation for people has been massively skewed. This is a bit like weight training, your muscles can only strengthen so much in a given period of time. If you're bench-pressing 95lbs today and some guy promises to train you up to 225lbs in 6 months, it's just not physically possible for most people to achieve this. Your brain is like a muscle, you can only train it to absorb so much in a given day before you just burn out. So I've adopted the slow and steady approach. I don't cram 5-6 hours of coding in after work because that is a recipe for disaster. In fact, I recently spent the weekend trying to cram as much coding as I could in to get this weather app built and quite frankly, I was miserable afterward. I find an hour or two of coding each and every day to be much healthier than just doing these cram sessions. Plus it gives your mind time to process what you've learned in much more manageable chunks. If you haven't been to my Daily Coding Log then you might not have seen this quote:

“Continuous improvement is better than delayed perfection.” – Mark Twain

Just keep at it each and every day no matter how little you do or learn. Just keep chugging.

3. Start a Coding Log

With the long-term approach, it's sometimes hard to remember where you started and just how much you've progressed. Even though I've only had my coding log for a few months, I have gone back a few times and looked at my notes on Git and Javascript basics and it makes me feel really good to know how far I've come. I've also named it "Daily Coding Log" for a reason, so I commit to myself to code daily. It basically doubles as an accountability tool when there's no one else there to make sure you're keeping up.

4. Code in the mornings before work

This was probably the hardest one for me to adapt to because I have always been a night owl. I started off coding after work but found my attention span to be much less and often found myself getting distracted often since I was usually at home. I just didn't have the energy after work because I'm mentally exhausted by the evening so pushing more information into my head just didn't pan out. One day I forced myself out of bed at 6am and got to work just before 7am so I could get 1 hour of coding in before 8am rolled around. Turns out, my head was much clearer without the clutter of the day fogging up my mind and I was able to focus a lot easier (this could also be because of the coffee). This is now my go-to time of day for coding since the distractions are minimal and I'm able to start the day coding with a clear mind.

5. Make friends with smart people

This one might sound kind of weird to you, you might be thinking "what do my friends have to do with this?". There have been a bunch of times where I've hit a brick wall and there wasn't a single Stack Overflow document on the entire web that could have helped me. This is where having a friend whose very well versed in programming comes in. I'm very lucky to be friends with multiple programmers all of whom are very good at what they do. I've reached out to a few of them on occasion when I was losing all hope and just getting 10-30minutes of their time can be immensely helpful. Having someone right there to show you the process and how to go about doing even the littlest of things has been one of the most helpful learning resources for me in my coding journey.

6. Go to local coding meetups

So you just read tip #5 and are thinking, "Wow cool Bennett, you've got smarty pants friends, great freakin' job. But I don't know anyone who programs. What do I do?". Well, you could go online and ask random internet people for help, which is useful OR you can go to your local coding group's meetups. This place is great for getting to know other local programmers and networking for when you're job-ready. Having trouble finding a coding meetup?

Try here: www.meetup.com/topics/computer-programming/

If that doesn't work then do a little searching around on Facebook. My local coding group, Acadiana Software Group, isn't on meetup.com but they have a Facebook page so give that a shot.

Conclusion

Those are my 6 tips for all my fellow aspiring developers who are struggling with the 8-5 grind. These tips are just what have worked for me so if you're stuck in a rut, give them a try and let me know how they worked. If you have any of your own tips you'd like to share, please leave me a comment! Happy coding.

Building My First App with Limited Coding Knowledge

Bennett Dungan — Sun, 24 Jun 2018 17:20:58 +0000

Originally Published Here

image source - weeblytutorials.com

A ton of beginners believe that they need to learn an immense amount of code before they can ever build anything useful. I've felt like that before, hell I still get that feeling of extreme self-doubt but its less frequent than before. I'm here to prove you CAN build an app that serves a purpose with very limited programming knowledge. There's a few prerequisites that you must have that are not even coding related before you decide to build just anything. I'll list the ones I find most important:

Do you really want to solve problems and build things that make a difference for people?

Can you identify a need or want that you have a desire to solve?

Are you willing to put aside leisure activities to solve this problem?

I find the most successful programmers are not the people with the best coding skills, its the people who want to genuinely make a difference. If you're still struggling with those aspects then you maybe need to re-look at the whole reason you are in this game.

Ok so if you've got those 3 questions above answered, then we can move on. Just as a little background, I currently work at a marketing agency and we use a program called Google Adwords to setup and deploy advertisements. Without getting into too much boring details, we use these things called 'keywords' to basically figure out who we want to show the ads to when people search for things on Google. There's a few modifications we can make to these keywords to alter their properties. For example, I can take the word "find a plumber" and change its properties in 3 different ways, like this:

+find a +plumber

"find a plumber"

[find a plumber]

I used to manually adjust these keywords one by one so it took a stupid amount of time to complete. I knew there had to be a better way, so I searched around and found this cool website called Keyword Toaster. This was great because I could now save a ton of time by just copying/pasting my chunk of keywords here and have this website convert them for me. Though, there were a few problems I identified that I feel could be improved:

Prepositions shouldn't be include for modified broad keywords
I had rather edit the keywords in the same window as Adwords

So it dawned on me, what if I just made a Chrome Extension that fulfilled these needs? All the app is essentially doing is taking a string, altering it, then returning the altered string in an output box. Easy right? Well, kinda...

I looked into what it takes to create a Chrome Extension and found that I should primarily be using Javascript. One thing that made me go with a Chrome Extension is A) I could use the extension in the same window as Adwords and B) No backend/server-side coding needed. I rarely see anyone suggest creating a Chrome Extension to newbies but this was the easiest, most straightforward platform to launch my simple app to the world.

Alright so, I had a minimal amount of JS knowledge beforehand but I knew I really needed to brush up on the basics. So I went through a highly recommended course on watchandcode.com that taught me these essential concepts:

1. How to read Javascript
2. How to debug
3. Functions/Arrays
4. Basic DOM manipulation

The course basically teaches you how to create a simple Todo app in your browser. This is perfect because all a Todo app does is take an input and display an output. If you think about it, that's almost the core function of most applications at a very basic level. So what I did was run through the whole course once, then a second time. During the second pass of the course, I essentially took what was being taught and applied it to the concept of the app I was trying to create. I was able to take 80% of the code taught and use it in creating my app. The only real difference in this case was altering the output, which I accomplished with a little REGEX.

To live test the code I was writing I used glitch.com. This made it super easy to see my changes in real time for an app of this size. I wasn't overly worried about CSS so it looked pretty fugly but all I cared about was the core functionality. Trust me, I make it sound like this was a simple process but even though most of the code I used was from the Watch and Code lesson, I had to reach out to people on different Slack channels and refer to Stack Overflow countless times for help.

After many months, my first little application, Keyword Modifier, was born on the Chrome Web Store!

Here is a link to the first version I had initially launched.: https://github.com/Beznet/keyword-mod .
Its a little cleaner now after some refactoring and added functionality, so you will see some minor changes to it if you download it today.

The point of this whole article is to prove that if you have the desire to create and build, its going to carry you through the hurdles of coding regardless of how little you know.

If you're reading this and currently struggling with your idea for an app, leave me a comment! I'd be happy to talk about your process and help you along.