Forem: Tori Pugh

Gatsby Blog: Next and Previous Links

Tori Pugh — Mon, 18 Nov 2019 03:06:13 +0000

I wanted to add next and previous links to the bottom of my blog posts for a bit. To make this work I started by going into gatsby-node and finding the query that is used to generate my blog posts.

This query just gets all the nodes (the markdown files) and get's the html, id and frontmatter in the form of the path name, blog title, blog date and blog tags associated with each markdown file.

allMarkdownRemark {
  edges {
    node {
      html
      id
      frontmatter {
        path
        title
        date
        tags
      }
    }
  }
}

Then I find the section of code that actually generates the blog post page. It's taking that query and looping over each node and then passing it the path and telling it what component to render.

 res.data.allMarkdownRemark.edges.forEach(({ node }) => {
      createPage({
        path: node.frontmatter.path,
        component: postTemplate,
      })
    });

The changes that I need to make are getting the next and previous from my query and then passing those into my generated pages. For allMarkdownRemark there is an option for next and previous under edges.

Adding these options under node (equal to node not inside node) in the query so I can access that information in my createPage function.

Changing the query to resemble this:

allMarkdownRemark {
  edges {
    node {
      html
      id
      frontmatter {
        path
        title
        date
        tags
      }
    }
    next {
      frontmatter {
        path
        title
      }
    }
    previous {
      frontmatter {
        path
        title
      }
    }
  }
}

Now we have access to previous and next and their frontmatter information, path and title, in the createPage function.

To update the blog post generating with our next and previous, just add them behind node. Updating the code to this:

res.data.allMarkdownRemark.edges.forEach(({ node, next, previous }) => {
  createPage({
    path: node.frontmatter.path,
    component: postTemplate,
  })
});

Now our createPage has access to next and previous. What we can do now is pass these down to the component by using context. Context will be an object with the information that will be passed to a component. It can then be accessed in a component by using pageContext.

res.data.allMarkdownRemark.edges.forEach(({ node, next, previous }) => {
  createPage({
    path: node.frontmatter.path,
    component: postTemplate,
    context: {
      next,
      previous,
    }
  })
});

Now if we go into the component and use pageContext we can destructure it to get next and previous.

const BlogTemplate = ({ pageContext }) => {
  const { next, previous } = pageContext;
  const nextArticle = next && (
    <Link to={next.frontmatter.path} style={{ maxWidth: '25%'}}>
      <strong>Next Article</strong> <br/>
      {next.frontmatter.title}
    </Link>
  )

  const prevArticle = previous && (
    <Link to={previous.frontmatter.path} style={{ maxWidth: '25%'}}>
      <strong>Previous Article</strong> <br/>
      {previous.frontmatter.title}
    </Link>
  )
}

Great! We've now got access to next and previous and can now see them in our blog posts. There is one issue that I ran into, the next and previous aren't showing the correct order of posts. The next article isn't technically the next article that's showing on the homepage.

The solution to this is to sort the query used in gatsby-node. To display my blog posts, on the homepage I'm using a query that is sorting the posts by the frontmatter date and arranging them in descending order.

allMarkdownRemark(
  sort: {
    fields: frontmatter___date,
    order: DESC
  }
)

This should fix the issue, if you notice your next and previous are not matching up with your layout of your articles.

This post was originally posted at toripugh.com

Getting Started Using Gatsby

Tori Pugh — Mon, 09 Sep 2019 01:12:38 +0000

I'd been curious about Gatsby for awhile. I've heard about the JAMSTACK (JavaScript, APIs, and prerendered Markup) and about static site generators for awhile. Had a Gatsby course saved on egghead.io and I decided one day that a side project I was building might be a good candidate to use it. So, there was no better time to start then now.

Video Tutorials are great starting points

I'm personally a fan of video tutorials, I'm a visual learner and I like watching people build things. I watched Build a Blog With React and Markdown and was just amazed at how straight forward and simple this all seemed. Having used Gatsby about a year ago, but with no experience in React. I was fairly confused how anything worked.

Now I’m React trained and I think it’s time to give this another shot. After watching the Egghead series and a Youtube series to better understand how to use Gatsby I thought it was time to start. After reading articles about how people should try and maintain their own blogs the decision was pretty clear. Make a blog! This would be the perfect way to get a controlled feel for Gatsby and make something that would be beneficial to me.

Using Gatsby CLI to develop a site

This is one of the easiest setups I've encountered.

• Install the CLI
• Create a new site
• Move into the newly created site folder
• Develop the Gatsby site.

Technical Directions:
Install the CLI by running npm install -g gatsby-cli in your terminal. Then run gatsby new gatsby-site, replacing 'gatsby-site' with the name you want your folder to be. After the folder is created, change directories to go the newly created folder. Then you can run gatsby develop and Gatsby will start a development server that hot-reloads and can be accessed at localhost:8000.

After following these instructions your Gatsby site is up and running. This will feel familiar if you've done create-react-app for a basic React app. The way Gatsby is setup is very different from a React app and requires special handling.

In Gatsby there are two important files that control aspects of your site. Two I'm going to describe are gatsby-config.js and gatsby-node.js. Unlike a plain React site, these two files are the heart and soul of your site. The config is going to control your access to files and plugins and the node will control the creation of pages, among other things.

Gatsby-config.js

This is where your site configuration, surprise surprise, for your site will be placed.

The options that I used on this page were siteMetadata and plugins. There are a few more that I haven't made use of yet, configuration options

siteMetadata

  siteMetadata: {
    title: `Tori Pugh`,
    description: `Kick off your next, great Gatsby project with this default starter. This barebones starter ships with the main Gatsby configuration files you might need.`,
    author: `@gatsbyjs`,
    menuLinks: [
      {
        name: 'Work',
        link: '/work'
      },
      {
        name: 'About',
        link: '/about'
      },
      {
        name: 'Contact',
        link: '/contact'
      },
      {
        name: 'Blog',
        link: '/blog'
      }
    ]
  }

This is an object that will contain site wide data that you want to keep consistent. This would be the site name, menuLinks, or anything you'd use from one page to another.

plugins

plugins: [
    `gatsby-transformer-json`,
    `gatsby-plugin-react-helmet`,
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `project`,
        path: `${__dirname}/src/data`
      }
    },
  ]

Plugins can either be only listed by name or some may take options. If it takes options, it will need to be in object form with a resolve being the listed name, followed by an options object.

Gatsby-node.js

This is where usage of the Gatsby node APIs are expected. The most important part of the file that I learned was to create new pages during the build process with createPages.

CreatePages works by taking a GraphQL schema and using that to reference and query some data. That queried data can be used in a function to create pages.

  workPages: allMarkdownRemark(sort: {fields: frontmatter___role}, filter: {frontmatter: {client: {regex: ""}}}) {
    edges {
      node {
        frontmatter {
          title
          path
          client
          github
          draft
          description
          deliverable
          role
          project_description
          url
        }
        html
      }
    }
  }

This GraphQL query finds all my work projects and will return them in an array. I will then take this array and loop through it and create pages for each item in the array.

    res.data.workPages.edges.forEach(({ node }) => {
      createPage({
        path: node.frontmatter.path,
        component: workTemplate,
      })
    })

Resources:

Gatsby Node APIs

Gatsby Tutorial Part Seven - Programmatically create pages from data

GatsbyJS Tutorials #5 - Building A Blog With Markdown Part 2 - Should watch Part 1 to understand the foundations for this part.

The Page Folder

Gatsby will automatically create a page for any React component created in the src/pages folder. After setup the initial pages should be - index.js, page-2.js, 404.js. If you change anything in these files it will make changes to the corresponding pages on the website and if you add a new React component a page will be automatically generated for it.

Example new page. Create a new file src/pages/about.js with the following code.

  import React from "react"
  const AboutPage = () => (
    <main>
      <h1>About the Author</h1>
      <p>Welcome to my Gatsby site.</p>
    </main>
  )
  export default AboutPage

Something as simple as the code above would generate a new page in Gatsby. You could then go to localhost:8000/about and see your new page.

Creating Pages Automatically

Were do you go from here

This is only scratching the barest minimum to get a functioning Gatsby site running locally. With an idea of what to do next, automatically or dynamically creating new pages; using data in some way with GraphQL; or using different plugins and options to change how your site/app will function, you can do whatever you want.

I'm going to document more of my steps to create a working blog and then transitioning that blog over into a full site. This is no way exhaustive, since I myself don't know all there is to know about Gatsby. I'm just sharing what I've done with my Gatsby experience.

Resources

Gatsby website has some of the best documentation I've ever encountered. Many times I was lost on how to do something and I just followed their tutorials or read their vast documentation and I could sort it out in the end.

Gatsby Docs
Gatsby Reference Guides
Gatsby API Reference
Gatsby Recipes

Big issues from simple things

Tori Pugh — Tue, 14 May 2019 01:23:58 +0000

I feel a little weird admitting this

Apparently I missed something really simple, I configured my nunjucks config file incorrectly. Not for a little bit, for the past 3 years! I combined info from a bunch of tutorials and mashed them all together to form my gulpfile that powered my gulp-nunjucks-render configuration.

When starting out this is really helpful to get a feel for how something should work, though eventually you should learn more about the code and make adjustments that are best for your needs. I never did that, I just made my peace with the fact I couldn't use relative paths and had no idea why I couldn't do that.

Now after all these years, deciding to upgrade to Gulp 4, deal with breaking changes from upgrading, and having to relearn everything about Gulp I've done before, I notice this. I'm not upset since everything is a learning experience. I'm more disappointed something as simple as changing the url from 'src/templates/' to 'src/' makes such a large difference.

I'll gladly have better control over my content and happily move my files back to more convenient places. Just another case of doing due diligence while coding. Don't forget to check in on your code every now and then.

Deployment Struggles - React app to Heroku

Tori Pugh — Thu, 14 Mar 2019 02:29:12 +0000

Starting my deployment journey

I started on this journey because I wanted to launch an app into the world, it's one of my resolutions for the year. I wanted to know more about this process of deploying and what that entailed. Most importantly I wanted to deploy so people could eventually see it and then I could test and use it the way it was meant to be, through the internet.

With no experience of deploying to Heroku or deploying a React app this test app would be the best time and place to do that. Unsurprisingly, I ran into a few problems. Some related to Heroku, to Github, and human error.

Github error

The Github error was the most subtle and hardest one to solve. Like most bugs, it's something painfully simple — I capitalized my filenames. That's it. Github doesn't acknowledge capitalization changes, so kept getting an error of not able to find file because on Github it was still lowercase.

On one hand I know I shouldn't have switched my naming convention after creating my files but I thought it wouldn't be an issue, so why not? In future I'll stick to camelCase, pascalCase, snakeCase, etc beforehand and not change it after the files are made and pushed to Github. Lesson learned: make a decision early then stick with it and read the error log carefully.

(My) Human errors

Almost all my errors were caused by not reading the error log properly for extended periods of time, not running npm install after adding assets or making changes to Webpack, or problems with my assets.

I was trying to add sound to my app and it wouldn't work for days. I'd made a vue app with these sounds and had no problem. I couldn't understand why replication in React wasn't working. After running into the problem of a Promise with .play() and finding a supposed solution, it still wasn't working.

Simple solution, the audio file was bad. I assumed it was working, but it wouldn't play on my computer. Rule: Always check your assets when troubleshooting, don't assume they aren't the problem.

Heroku misunderstanding

A lot of the problems stemmed from my lack of knowledge of how Heroku works. I didn't know anything about configuring my .envs or how to properly set my scripts so they run correctly and build in the right order.

All in all it was a significant learning curve, especially with how the Webpack build would affect things in Heroku. Without being to able to directly look at the dist folder it was really hard to troubleshoot sometimes. It would build with no errors and the page still wasn't showing. Those were the worst times of not knowing what went wrong.

Knowledge Gained

I ran into a lot of problems but when your starting something new that's not unexpected. With determination and the use of trust Google, I prevailed. It may be annoying that you can't seem to figure something out, it's ok though. Take a few days and collect your thoughts; don't forget to read the error logs, check all your files and double check your naming conventions; and test on your local when you can't see what the problem is.

These should help you find a solution to your problem. Otherwise, keep messing around and it'll come in time.

Nevertheless, Tori Pugh Coded

Tori Pugh — Sat, 09 Mar 2019 00:57:54 +0000

I continued to code in 2019 because...

I was working in a language that I didn't know and wasn't really confidant about my abilities. I really wanted to expand my skills and become a better frontend developer.

I'm always looking to learn and improve myself. Using my skills to create a couple of side projects, it would push me closer to making some live and usable products.

I deserve credit for...

Working hard to continue growing my skills in React and adding redux to my skill set.

Also, I need time to work on my testing with Jest and Enzyme. It's a syntax and mindset issue. Yet, I'm reading and learning all the time.

I hope to see my tech community...

Continue its growth with support for women coders. That sense of community is one of the reasons I feel so confident. When your surrounded by so many supportive people you feel like you can do anything.

2019 Dev Resolutions

Tori Pugh — Sun, 06 Jan 2019 01:19:46 +0000

I'm feeling purposeful recently

I've felt particular invigorated since I got a new job last year. The people I work with are much better developers than me and that's not a bad thing. They are teaching me so much and I feel the self-taught education I gained is missing some skills to round me out.

I've come up with some things I'd love to learn in 2019 so I can understand more in our app development and that I can bring more to the table in terms of planning out apps and components better.

Better Foundation in React

I just learned React in October. I never thought I'd be able to learn it and my new job actually taught me. It took about 2 weeks to get through the videos and then a month to feel confident in my skills. So, now in January I'm trying to brush up on the beginners principles that I may have overlooked. Then I want to ease myself into more advanced features. It's probably a strange way to do it but life comes at you fast.

Learn Redux

I have little knowledge of Redux, my colleague is in charge of creating the actions and other Redux features. I'd love to be able to help and make my components in preparation for hooking up to Redux and getting data. In the general scheme of a life, this seems like something good to know at least basically. I'm not expecting to be an expert but to be able to hook up a system for a personal project would feel like a win for me.

Learn About API's and NodeJS

I've made the basic API using NodeJS and Express, but I'd like to learn a bit more. This isn't the most important thing on this list but I really like learning all sides of development. The better understanding I have of the working of backend the better I feel about syncing things up with the front-end.

Understand Technical Side of Authentication

It sounds silly, but I never really thought about authentication. Now that my eyes have been opened I'm determined to learn more about JWT (jsonWebTokens), OAuth, and any other system or version of authentication.

Make better tests — Jest & Enzyme

This is the most important to me right now. My tests are just checking if the components render and don't crash. I'm hoping to make strides in this area because it'll be great to have components with strong tests to catch any errors I've made that could potentially effect the projects I build.

Learn GraphQL

This seems like an upcoming technology that's about to blowup, so I'd like to stay somewhat up-to-date. I'm not sure where I'd use it right now but if people are going to be interested in it then I've got to get eyes on it.

What Else?

Is there anything else to add to the list to become a better Front-End Developer?

Building a Pomodoro Timer with Vue.js on CodePen

Tori Pugh — Thu, 31 May 2018 16:05:05 +0000

I've been following the challenges on Scotch.io for awhile and saw one that I was really interesting in trying to make. It was a Pomodoro timer for the Scotch.io Challenge #6. Always looking to test my skills I wanted to take a crack at this one.

Setup

The setup was easy as there already was a codepen (below) with all the required html and css work done. With the major work ahead of me it was time to start working on the javascript portion of this challenge.

This codepen doesn't work

First Steps

The first thing I wanted to do was setup my data with all the variables I would need.

data: {
    message: 'Let the countdown begin!!',
    timerRunning: false
}

This just created the variable for my messaging, which would change depending on what state the timer is in, and the states to differentiate from the timer being active or being paused. These states would be crucial to creating my methods in relation to getting the timer to countdown.

The methods came pretty naturally in reference to their connections with the buttons. I needed to attach a method to each button that would run on click. The requirement called for 4 buttons (Start, Pause, Resume, and Reset).

The start button would turn on the countdown and make the timerRunning: true, since the timer would be running. The pause button would freeze the countdown and make the timerRunning: false. The resume button would turn the countdown back on at it's current time and pace while making timerRunning: true. Finally the reset button would set the countdown to it's starting number and make timerRunning: false.

This is the original code for the methods relating to the functionality we just talked about. Including the changing of the message on the certain states.

methods: {
    timerRun() {
      this.timerRunning = true;
      this.message = 'Greatness is within sight!!!';
    },
    timerPause() {
      this.message = 'Never quit, keep going!!';
      this.timerRunning = false;
    },
    timerReset() {
      this.message = 'Let the countdown begin!!';
      this.timerRunning = false;
    },
    timerCountdown() {
      this.timerRunning = true;
    }
  }

To change the message for certain steps I tied the methods, shown above, to the buttons, shown below, and this triggers different actions. Depending on what button was pressed it could say the timer is running, the timer is paused, the timer was reset, or the timer is running. With the variable of timerRunning changing in the scenarios that also would change which button configuration was being shown at the moment, with the v-if function. So, this took care of the functions of the buttons and it's time to actually get the timer working.

<div class="buttons">
      <button @click="timerRun" v-if="!timerRunning">Start</button>
      <button @click="timerPause" v-if="timerRunning">Pause</button>
      <button @click="timerReset" v-if="timerRunning">Restart</button>
</div>

When I went to create the timer I realized I didn't really know how to code something counting down and didn't understand the basic principles to create a timer. To learn how this should work I took a quick deviation into making a clock.

I learned about using the milliseconds to base all the clock actions on, how to step through time, and display hours, minutes, seconds and milliseconds. From this side project I learned a lot about time management when it comes to going forward or backward through time.

A major problem that I was having for the countdown timer was consistently moving through time. When I first created it, whenever the start/resume button was pressed after the initial start, the countdown would speed up incrementally for every time pressed. This was not the expected result and not conducive to something where you'd need to resume. After making this clock I realized a more consistent method of triggering the start of the timer.

data {
    interval: null
},
methods: {
    timerRun() {
      this.timerRunning = true;
      this.message = 'Greatness is within sight!!!';
      this.interval = setInterval(this.countdownTimer, 1000);
    }
    timerPause() {
      this.message = 'Never quit, keep going!!';
      this.timerRunning = false;
      clearInterval(this.interval);
    },
    timerReset() {
      this.message = 'Let the countdown begin!!';
      this.timerRunning = false;
      clearInterval( () => { this.interval; });
    }
}

This code was important to having a consistent movement in the countdown from initial run to any subsequent resumes. Now when the timer is started a new this.interval is started to countdown the timer. On a pause and reset that variable is cleared, which pauses the countdown and stops the variable from multiplying on top of each other.

Getting the timer to countdown was a long road of understanding a lot of math, which I'm sadly very poor at. In the end I needed to break down the interpretation of time into — hours are 60*60*60, minutes are 60*60 and milliseconds are 60. So you need to take the milliseconds and times up. (I apologize if I'm explaining this poorly, I'm horrible at math).

Now the other problem with counting down, how not to go into negative numbers. With the explanation below this is the reason that the time doesn't become negative (it actually does but we don't show that).

timerCountdown() {
      console.log('Working');
      this.timerRunning = true;
      this.interval = setInterval(this.updateCurrentTime, 1000);
      // Counts down from 60 seconds times 1000.
      setInterval( () => {
        this.timerMinutes--
      }, 60 * 1000)

      // Check if seconds at double zero and then make it a 59 to countdown from.
      // need another method of checking the number while in the loop and then adding a zero on the number under 10
      if(this.timerSeconds === '00'){
        this.timerSeconds = 59;
        setInterval( () => {
          this.timerSeconds--
        }, 1000);
      } else {
        setInterval( () => {
          this.timerSeconds--
        }, 1000);
      }
    },

It does go into negatives in his solution. You could include a simple check if time <= 0 to reset and stop the timer. And how it stays in 60 seconds is just maths. He converts the rounded minutes into seconds and subtracts them from the total time (in seconds). So what will be left are seconds between 0 and 60.
This could be shortened and cleared up using modulo.
this.totalTime % 60
This will always leave the remainder of a number 0 - 60.
Thanks to Zammy13 for answering my question

The breakdown of the modulo (Remainder %).
// Detect dark theme var iframe = document.getElementById('tweet-976186607794520065-279'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=976186607794520065&theme=dark" }

For my timer I wanted 25 minutes, so I used this instead totalTime: (25 * 60). This equals the total amount of time (25 minutes) times 60 which equals the amount in seconds. The totalTime is then 1500 in seconds.

computed: {
     time: function() {
      return this.minutes + " : " + this.seconds;
    },
    hours: function() {
      var milli = this.milliseconds;
      // var hrs = new Date().getHours();
      // Used getHours() since the below didn't work for me
      var hrs = Math.floor((milli / 3600000) % 24);
      if (hrs >= 13) { hrs = hrs - 12 }
      return hrs >= 10 ? hrs : '0' + hrs;
    },
    minutes: function() {
      var min = Math.floor(this.totalTime / 60);
      return min >= 10 ? min : '0' + min;
    },
    seconds: function() {
      var sec = this.totalTime - (this.minutes * 60);
      return sec >= 10 ? sec : '0' + sec;
    }
  }

The final step was to make sure that your timer knew it was counting down. Which is probably the easiest part of this whole thing, just checking that the variable timerRunning == true and then removing a millisecond.

countdownTimer() {
      if (this.timerRunning == true) {
          this.totalTime--;
      }
    }

End

It was a long road and a lot more work than I thought it was going to be. In the end I made something that is basic and can't wait to make something with all the bells and whistles. Something to tell you where you are in the pomodoro technique and something to make it visually more fun.

The final codePen for the challenge

This codepen has a lot of problems, including an accelerated countdown. I fixed this in my personal version of the timer. This was done to reach a goal and that was the challenge due date. There will be a part two of my own advanced timer.

When to Call it Quits on a Project: Stepping Back and Taking a Break

Tori Pugh — Thu, 29 Mar 2018 20:43:05 +0000

I was trying to make a Pomodoro timer for the Scotch.io Challenge #6 using a framework I had just started learning, Angular. It was going pretty well at first. I had replicated the desired design look. I'd setup the components and just needed to create the javascript to make the timer actually countdown from a given time. This is where it took a sharp downturn.

Problem Strikes

I just couldn't get the timer to countdown no matter what I tried, I felt I had a good game plan. I thought I knew the steps to make this work and it would be no problem. It did not work out that way at all. I spent a few hours trying to lookup any examples of people who'd done something similar, to no avail. None of the examples where using the setup I had of using Angular CLI. They were all using a setup that relied on $scope and I didn't know anything about that or how it related to my setup.

I'm a pretty determined person so I spent a good part of my night trying to break this "problem hump". Thinking if I just pushed enough everything would click into place and it would all make sense. That's usually how it works for me, I do research and trial & error and then things works. I kind of figure out what I needed to do and then it's something I've learned.

Calling it Quits

It was getting close to 3am. I was super tired and very angry, at myself. I wanted so badly to do this, I thought that I'm better than this I can make it work. That wasn't actually fair or true. It had nothing to do with my abilities in the sense of I'm a failure but more that I'm really new at this. Why should I be expected to know everything about a framework I just started using not even a month ago. Once I realized that I thought it was silly to push myself to learn everything about Angular in the wee hours of the morning.

I didn't want to but I put this project, making a Pomodoro Timer with Angular, on the backburner. I made it in Vue and don't regret that. That's a framework I've had a few more months experience with and I feel really comfortable in. Took about two days but I got it working and fleshed it out into a full functional Pomodoro Timer.

End Result

I would have never gotten that far if I was too upset about my Angular project and called it quits. I know when I have more experience in using Angular and have a better handle of how it works I will come back and finish that project. There is not doubt in my mind.

Sometimes you need to give up and come back later. If you don't know why it's not working or you feel your missing something, step back and get a different perspective. There is no shame in not having enough experience. Just don't give up and you can always come back later.

Nevertheless, Tori Pugh Coded

Tori Pugh — Wed, 07 Mar 2018 18:16:35 +0000

I began/continue to code because...

I started coding because it was a required course for my graphic design major. I had to take a web design class, this included learning the basics of HTML and CSS. After that first encounter I was really impressed with it and saw how eventually the demand for print materials would become less. I decided to pursue the digital spectrum instead of my first thought of branding.

I've continued to code because I'm in love with the idea of constantly learning something new. The technology that comes out is usually better or does things differently and it's so much fun. I've slowly progressed from doing simple emails, to bad websites, to better and progressive websites and emails. And the journey isn't over yet. There is so much to learn and it's not going to stop anytime soon.

I'll gladly stick with coding just to see what else is created. Maybe create something myself one day.

I recently overcame...

I'm transitioning into a MEAN stack development role and I recently overcame the initial hurdle of learning about some new languages, specifically some javascript frameworks. I like Vue but I'm also learning Angular as well. I've progressed well with Node.js and am looking to keep leveling up.

I want to brag about...

I was really proud when last year I created my own workflow to speed up my email creation. I had never used a task runner, node, or javascript templating languages. I was excited to make something that made my life easier and to make it functional at all. Then to have it important in data from json files, I was over the moon. Now to make it a GUI and have the ability to make changes to those json files.

The idea that what I deemed a complex plan not only came together and is working but I can outline it's plans for expansion is mind-boggling. I'm damned proud of myself and for the pushing and perseverance I've had for dealing with the unknown alone and making it out just fine.

I'm currently hacking on...

I'm messing around with Vue and learning the ins and outs of how it works. I'm building an editable navigation where you can add, delete, edit and move links. It's been a big learning lesson and it was just a random thought I had.

My advice for allies to support women and non-binary folks who code is....

Treat them like any other folks who code, they don't want or need extra privilege, they just want to be a programmer. Not an "insert-title" coder, just a coder. They want to do a job and have a passion for it. Build them up just like any other person.

If you see anyone treating these people in a negative way, try and be the voice of reason and use your voice to try and make a difference. Not in place of these people but for these people.

Finally if your in a male-dominated area, be it a hackathon, conference, or other form of get-together, do keep in mind that is a tough place for women and non-binary people to go. It can feel daunting and intimidating, don't give up on them just keep trying to appear as a neutral and fun atmosphere and they'll appear eventually. These changes won't happen overnight but with intentionality and repetition, it will work in the end.

My advice for other women and non-binary folks who code is...

I can only say from my experience, don't be afraid to show interest in something and ask a lot of questions. I've had many people open up to honest interest. If you see someone, in person or online, who does something and you think "wow, how did they do that?". Just ask them. Granted, they may not answer you it happens. If they do then you've got some knowledge you didn't have before.

Also, follow/interact with a strong group of people. Irregardless of gender, this should be a group that wants to lift everyone up and help them succeed. You can go to them if you need help and most certainly is a place where you can learn.

I've been lucky in my career to not have any overt run-ins with negative or toxic personalities relating to my gender. That doesn't mean it doesn't happen or that you won't. Realize that whatever those negative sentiments are, don't let them get you down or change what you want to achieve. Know your inner strength and desire and don't let it derail you. (sidenote: If you need to take a breather for self-help and then carry on. Don't let negative feelings dwell and fester. Get rid of that stuff fast.)

In Closing

I can't wait to hear from more women and non-binary folks who code. If you've got ideas and the ability to make things happen then tech needs you. Don't be afraid to make your ideas reality. Can't wait to read what you do, use what you make.

If you'd like to talk you can DM me on twitter or through email.

Making a Vue component: an Editable Navigation Element

Tori Pugh — Thu, 01 Mar 2018 22:17:02 +0000

I had an interesting idea to create a navigation that for simplicity I’ll call an editable navigation. I wanted this navigation to be easy to use. When you fill out the form then a link gets added. You can delete links, edit the content of a link, and change the order of the links.

To start this project I broke it down into 3 phases: add links, delete links, and move links. As I went through them though, I felt these phases were a bit too vague. I had overlooked the important details that make a product usable. The nuances behind making something like adding seem so simple, error-handling and warnings. Without these I could create a very poor experience. As such, I added another phase of error handling but could have easily added more phases to encompass a smoother experience.

Phase 1: Add Links

Phase 1 Codepen: The first phase of my navigation creation was developing a function to add links from input data. This was a simple matter of creating an empty array to place the new links into and when the “Add to Navigation” button is pressed it adds the content of the inputs into the array. This in turn would add a new link to the navigation.

It’s probably more simplistic than I intended. There is no safeguard against either input being blank and triggering the function or any error message if an input is blank telling the user it needs to be filled out. I’d fix this later on, the first thought was to make this function work.

The tough part about this code was a problem with the nested arrays storing the data. I initially couldn’t get the information pushed into the array, they just didn't show up. When I wrote it more literally [{ text: text, url: url }] as a nested array it worked.

addLink: function() {
  var text = this.newLink.trim()
  var url = this.newURL.trim()
  if (text) {
   this.links.push({ text: text, url: url })
   this.newLink = ""
   this.newURL = ""
 }
}

Phase 2: Deleting Links

Phase 2 Codepen: The next step was to create a function that would take into account the index of the link you clicked and then delete that object from the array.

removeLink: function(index) {
  this.links.splice(index, 1)
}

Phase 3: Error Handling

Phase 3 Codepen: This started as a need to add error handling (warnings and stopping the data from being added to the array). It than morphed into adding functionality for pressing enter to trigger the function. If you pressed enter on the last input it would trigger the add function. I found myself wanting to finish filling out the last input and just press enter expecting it to work and it didn’t.

addLink: function() {

      var text = this.newLink.trim()
      var url = this.newURL.trim()

      if ((text !== '') && (url !== '')) {
        this.isEmpty = false
        this.links.push({ text: text, url: url })
        this.newLink = ""
        this.newURL = ""

      } else {
        this.isEmpty = true
        this.error = 'Complete all boxes!'
      }
    }

This function is pretty straight forward in it's concept. The reason behind the logic is to make the text-input content and url-input content a variable and then check if either variable is empty. If so, then the function will make the variable isEmpty true which shows the error box with the message. The array push will not happen and the links will not be added.

I did make a few mistakes in this function. With the original logic statement it wasn’t properly triggering the function. It was checking only if variable text existed and if variable url was empty. The issue came because I wanted to check if the inputs are empty and not that they exist. The function would trigger if the url was not empty and text was empty. This was not what I wanted to happen. This would push a link with no title and would be a blank space.

if ((text && url !== '')

The other issue I ran into was trying to be too fancy and have the isEmpty toggle instead of explicitly state true or false. Whenever the logic failed it would keep toggling the error message on and off regardless if there was still an error. In this updated version, the variable is always true if there is an content in the inputs and will be false if the inputs are not empty.

These 3 phases went by quickly, they took me the better portion of a day. I was stuck on phase 3 the most, it was a classic case of needing to simplify and not be so fancy.

Phase 4 — Editing Links

Phase 4 Codepen: This has been my toughest challenge yet! I was initially concerned about the mechanism to make the changes and settled on using a modal.

  <transition name="fade">
    <div class="editMenu" v-show="isEditing">
      <button class="close" @click="hideForm">X</button>
      <h3>Edit Link</h3>
      <label for="" >Link Title</label>
      <input v-model="editLink" @keyup.enter="editLinks" type="text">
      <label for="">Link URL</label>
      <input v-model="editURL" @keyup.enter="editLinks" type="text">
    </div>
  </transition>

I created a simple one by using a transition and v-show. The transition creates a smooth fade in animation and the v-show activates the modal coming into view when a button is pressed.

showForm: function(index) {
  this.isEditing = true
  this.editingIndex = index
  this.editURL = this.links[index].url
  this.editLink = this.links[index].text
}

The editing part had been a trouble spot. After assistance from Roel Nieskens, he solved this crucial problem for me. The answer to making the edits specific to the link that was pressed is to take the index of the link and save that to a data variable. This would be done when the showForm function is being run so that the index value, which is now a variable of editingIndex, is available for the next function.

editLinks: function(){
      var text = this.editLink.trim()
      var url = this.editURL.trim()
      Vue.set(this.links, this.editingIndex, { text: text, url: url })
      this.isEditing = false
      this.editLink = ""
      this.editURL = ""
    }

This function takes the information that is in the inputs and pushes them back to their array. This is where Vue.set() comes in handy.

Vue.set(object, key, value) works like this. The object is where I want the changes to be, the links array. The key is the index of the particular link that has been clicked. The value is the content of the inputs.

Phase 5 - Rearranging Links

This final phase will be centered around making the links change position in the navigation. I'm not sure where to begin with making this work and am unsure whether to use an outside extension or import something to assist with this. I'll try and build something first and then get more complex from there.

Tips on overcoming Imposter Syndrome

Tori Pugh — Wed, 10 Jan 2018 15:51:02 +0000

Imposter syndrome is that problem that all people, but especially creative people, run into. It’s that feeling that you aren’t good enough and don’t belong where you are. It’s insidious and creeps in so fast that you can’t really prepare for it. When it takes hold of you, and it most likely will, here are somethings you can do to work through it.

1. Don’t feel bad, it’s really common

Having these feelings of being inadequate aren’t uncommon. Sometimes your having a bad week and nothing you do seems to pan out. You can get really down on yourself and wonder why your doing any of this at all. Don’t fear! Many people, people of all skill levels, face these problems.

Example, Slideshow,

2. Don’t let failure get you down

People aren’t perfect from the get go. This means you will run into failure every now and then. Don’t let it derail you or make you feel you can’t do something. Sometimes you need to learn how not to do something to learn how to do it correctly.

Many of life’s failures are people who did not realize how close they were to success when they gave up.> – Thomas Edison

3. Look for a mentor

Sometimes these feelings are a literal implication of reaching our limit on our own. It’s hard to push yourself and you might need to seek out a mentor. To find that person who will push when you can’t or wouldn’t push yourself. It’s someone who sees the possibilities that you may be blind to. Going it alone only amplifies these feelings. Being around similar and experienced people will push you that extra mile.

4. Share your knowledge

You know you know things, so why not share it. This is a great way to think through all the information you have and build confidence in what your doing. At the same time your teaching others, which is always good. Sometimes the act of sharing unlocks something within us. It can lead to a new passion or a renewed desire in pushing yourself. Interacting with people who want to pick your brain is the reassurance that you need.

Creating my own Gulp-based email workflow system

Tori Pugh — Tue, 24 Oct 2017 03:21:01 +0000

Wanting modular + dynamic content so badly I made my own system.

I’m an email fanatic, an #emailgeek if you will. I attended Litmus Live Boston 2016 and heard people swearing by modularity and using data driven design to save us all. Wanting to be apart of the change and not the problem lead me to wonder if there was a Gulp based solution that would help me at work. Most use the modularity functions in something like Litmus or within their own ESP. My company had neither available as an option, our ESP is awful and we don’t use Litmus. In a constant struggle to keep emails maintainable, on brand, error free, and as customizable as possible I needed to get this workflow up and running.

Searching for a starting point

The idea was to find something to build upon that would allow me to template our emails, create modules for the templates, make them easy to maintain, help reduce errors and increase consistency. I stumbled across A Gulp Workflow for Building HTML Emails by ireade and saw that it was a perfect starting point. Removing the PostCSS options, and disregarding the capability to inline css (due to time constraint I had to hardwiring all the templates). It did everything that I had wanted it to.

Using a templating system

The workflow used Nunjucks for templating, which is similar to Swig/Twig/Dwoo, a simple but powerful templating language. Before this I’d never really used one, since it required using PHP and my knowledge is lacking. Nunjucks uses a simple language and no PHP, its easy to learn and their is strong documentation if you forget. Having a templating system makes creating modules for the emails so much easier, controlled, and clean.

It helped exponentially with changes, which was one of the biggest problems we had with our emails. When I copied and pasted past emails and had to keep remaking changes from one group of emails to another. I’d forget what changes were done to which email and it became a huge problem of consistency. There were emails without the “new” changes and some with even more changes. The templating system reduced these errors and inconsistencies drastically and helped to document the various changes.

Using data is a real game changer

The best part of this system was using Gulp-data to incorporate data files. They are .json files, that can be named and referenced in the template files. Personally, I created a data file specifically for the main content of the site: the logo, the homepage link, the social links, etc. If it‘s something to be permanently found on all of the emails it’s in this file. Now I never had to code header or footer links again, which increased consistency and reduced errors.

In my specific usage case, an event that spans different cities and uses similar but different information. This was paramount in cutting down errors, tedious tasks, and speeding up production. I created a data file for each city which had the speaker subject, speakers, their bios, the presentation information, the agenda time, the city sponsors, hotel information, city information, and all the links for the event (different ticket packages). This file would be called into the templates when needed and helped to create the dynamic data. When the cities changed from template to template all the variables pulling in this data would change. There was no constantly writing the same data in and possible seeing it changed from email to email. When there was series wide changes, such as personnel or agenda I made it in the database and didn’t worry about it again. Things like the unsubscribe, which was a part of the data file, and once it was set never needed to be revisited.

The only downside to this data system was the manual nature of it. This required me to also maintain data in case of changes. Since I had no control over changes I had to rely on people updating me to changes or additions. This did require some great rewrites of the system due to needing something and not having the email setup for it. All of which could have been averted with some good planning and discussion about future needs of the emails.

Creating variables to take advantage of data

Using the data files you could then pull in information and save them in the templates as variables. Variables could be anything from Hotel Name, with different variations, from a short version to a long version, to referencing the agenda speakers, date of the event or location. Being able to create variables lead to being able to create dynamic data, it was based on verifying information against variables.

You could also make conditionals built into the templates and put all the options in each template. Using variable functions you can change the data being displayed depending on the current variables. An example is the pricing and labels would change based on the type of sale going on, early-bird or preview pricing. This included all the links to the different prices and using any necessary verbiage changes.

You could also make some custom variables, like one that when compiled together would create the view in browser link. It would take all the information for the compilation from variables in the main email file.

Planning for the next step

For a trial run from a first creation it did great! There where some noted pain points, when the style needed to be changed I needed to make changes in each data file to stay consistent. Also there were changes without my knowledge that I had to change in my data to match the current event. A lot of times I was running without data and would have to leave areas empty. These are not necessarily the systems fault, that’s communications errors and bad planning. One of the biggest problems seemed to revolve around creating, changing and maintaining data.

For a truly consistent and easier usage the next step would be to make a GUI and integrate a server system and a database. With a database in place and a method for another person to maintain the data, the responsibility of data handling wouldn’t fall to me. With these changes in place I believe they would alleviate these problems. From a technical standpoint, the main problem to address is refreshing the data without restarting the server. Currently I change the data and need to restart the server. It’s annoying when making simple changes in the data and having to restart the server. For non-code people it could be a potential barrier and more of a problem than helpful.

Gulp Email Workflow Github

Still working on updating the repo. I kind of let it go to seed there.

This is still new for me and I’m trying to get in a habit of writing more. Share any thoughts in the comments below or on my twitter @teekatwo.