<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: DwightColbyJack</title>
    <description>The latest articles on DEV Community by DwightColbyJack (@notmuchnotmuch).</description>
    <link>https://dev.to/notmuchnotmuch</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F596957%2F3c692a78-f152-40ba-b1d2-fc36cec56322.jpeg</url>
      <title>DEV Community: DwightColbyJack</title>
      <link>https://dev.to/notmuchnotmuch</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/notmuchnotmuch"/>
    <language>en</language>
    <item>
      <title>C# and ASCII art</title>
      <dc:creator>DwightColbyJack</dc:creator>
      <pubDate>Sat, 19 Jun 2021 23:09:29 +0000</pubDate>
      <link>https://dev.to/notmuchnotmuch/c-and-ascii-art-367</link>
      <guid>https://dev.to/notmuchnotmuch/c-and-ascii-art-367</guid>
      <description>&lt;p&gt;So I'm starting to learn C#. It's a legendary language and I feel like breaking out of the React path I've been on as soon as I finish building my restaurant POS with React and NextJS. I'll continue the blog following the build out and how to leverage Keystone.ts to build mutations and queries along with some fun tricks I learned from Wes Bos' Advanced React Tutorial. &lt;br&gt;
Today, however, we're starting a new journey, and as such, we're going to cover something kind of simplistic: ASCII art! &lt;br&gt;
I've always been in the dark as to how people made this kind of art. It is defined as the images a computer can create using the 95 ASCII characters defined by the ASCII Standard from 1963 including it's extended proprietary character sets. This all means, we can create cumulative images using our computer's printable characters combined in specific orders.&lt;br&gt;
C# comes with its own &lt;code&gt;console.log&lt;/code&gt; method but is better known as it's wordier version &lt;br&gt;
&lt;code&gt;Console.WriteLine()&lt;/code&gt;.&lt;br&gt;
How do we get data displayed in the the console? All we need is &lt;code&gt;Console.WriteLine()&lt;/code&gt; and whatever message we want to world to see, like so:&lt;br&gt;
&lt;code&gt;Console.WriteLine("I like Pizza!")&lt;/code&gt;&lt;br&gt;
Our love of pizza will be displayed on the console and we can revel in our computer savvy. The artistic capabilities of our WriteLine method are quite a bit more useful than printing out strings. You can create your own ASCII images by printing any combinations of characters, lined up strategically, to produce shapes and even value (the shading from white to black produced with the amount of characters that might overlap or lay adjacent to eachother). Since it's early on in my knowledge of C# and ASCII art, I won't show off my less-than-novice artistic sensibility but you can checkout a ton of examples here &lt;a href="https://www.asciiart.eu/"&gt;https://www.asciiart.eu/&lt;/a&gt;&lt;br&gt;
Also, the next time you're hanging out in Visual Studio and need a break from the monotany, give Console.WriteLine a try and start stringing your "strings" together to create your own ASCII art.&lt;br&gt;
Happy coding.&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Loading State Visuals: how to make waiting more fun...</title>
      <dc:creator>DwightColbyJack</dc:creator>
      <pubDate>Sun, 13 Jun 2021 02:03:19 +0000</pubDate>
      <link>https://dev.to/notmuchnotmuch/loading-state-visuals-how-to-make-waiting-more-fun-4c28</link>
      <guid>https://dev.to/notmuchnotmuch/loading-state-visuals-how-to-make-waiting-more-fun-4c28</guid>
      <description>&lt;p&gt;No one likes waiting. It's the down time we could be using to eat snacks, text friends and try to rearrange our to-do lists for maximum laziness. Waiting for a page load, especially, is some of the most audacious down time because computers are supposed to be fast. However, given the asynchronous state of our functions, the business of our network or even just the strength of our internet signal, we will need to wait so we might as well make it look cool. Enter nProgress, a styling package that helps us add styles to our loading state so we can have a visual representation of our downtime with cool animations and color schemes.&lt;br&gt;
To use nprogress, all we have to do is import it &lt;br&gt;
&lt;code&gt;import 'NProgress from 'nprogress'&lt;/code&gt;&lt;br&gt;
and the associated styling that comes with the package.&lt;br&gt;
&lt;code&gt;import 'nprogress/nprogress.css'&lt;/code&gt;&lt;br&gt;
NProgress comes with it's own methods that let us start the progress bar &lt;br&gt;
&lt;code&gt;NProgress.start()&lt;/code&gt;&lt;br&gt;
We can also set it to a certain amount or increment &lt;br&gt;
&lt;code&gt;NProgress.set()&lt;/code&gt;&lt;br&gt;
&lt;code&gt;NProgress.inc()&lt;/code&gt;&lt;br&gt;
and finally we can stop the animation with &lt;br&gt;
&lt;code&gt;NProgress.done()&lt;/code&gt;&lt;br&gt;
In my Advanced React and GraphQL tutorial we go over page load, and how to use NProgress to give us some visual effects to display our loading state. Utilizing the NextJS Router component, we are able to listen to Router based events, specifically &lt;br&gt;
&lt;code&gt;Router.events.on(&lt;/code&gt;routeChangeStart)&lt;code&gt;&lt;br&gt;
This gave us something to listen for before starting the NProgress effects &lt;br&gt;
The final implementation looks something like this &lt;br&gt;
&lt;/code&gt;&lt;code&gt;Router.events.on('routeChangeStart', () =&amp;gt; NProgress.start()).&lt;br&gt;
Router.events.on('routeChangeComplete', () =&amp;gt; NProgress.done())&lt;/code&gt;&lt;code&gt;&lt;br&gt;
A caveat here if you're using styled components is that the server and the client might be rendering different identified components (meaning styled components has an id for it, and the server has it's own id). Should this be the case, you'll recieve a scolding from the console and we have some light editing to do. Make sure you use the&lt;/code&gt;&lt;code&gt;getInitialProps&lt;/code&gt;&lt;code&gt;hook. The implementation is pretty heavy, and honestly this is a great example of reading your Docs because it looks weird, but it handles this problem quite nicely:&lt;br&gt;
&lt;/code&gt;&lt;code&gt;static getInitialProps({ renderPage }) {&lt;br&gt;
     const sheet = new ServerStyleSheet();&lt;br&gt;
     const page = renderPage((App =&amp;gt; (props) =&amp;gt; &lt;br&gt;
     sheet.collectStyles( &amp;lt;App {...props} /&amp;gt; &lt;br&gt;
   );&lt;br&gt;
   const styleTags = sheet.getStyleElement();&lt;br&gt;
   return {...page, styleTags };&lt;br&gt;
}&lt;br&gt;
&lt;/code&gt;`&lt;br&gt;
So, that was alot, but bear in mind we are asking our App component to render with spread props a-la the "spread" operator, meaning we have essentially collected all the styles from the page as well as any initial styles from the server. Now the id's on the server and client side styled  components can "work together".&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Technically speaking</title>
      <dc:creator>DwightColbyJack</dc:creator>
      <pubDate>Sat, 05 Jun 2021 22:47:13 +0000</pubDate>
      <link>https://dev.to/notmuchnotmuch/technically-speaking-2chd</link>
      <guid>https://dev.to/notmuchnotmuch/technically-speaking-2chd</guid>
      <description>&lt;p&gt;
Technical interviews: the scourge of up and coming software engineers, the great assessor. Technical interviews can be scary and after my first I figured I'd lay out some tips for your next nail-biting experience. 
The goal of technical interviews is to test your prowess at coding and to get a sense of how you code. Are you naming your functions in a concise way? Do you write your code using the necessary layout? Are you pseudo-coding and commenting and how much?? Something to keep in mind is your personality while coding as well. These people want someone who they are comfortable with and who knows their stuff, so be friendly, communicative and an active listener.
A huge take away from my own recent interview is **read the directions and read the DOCS!** I know it sounds like a given, but I signed off on my interview realizing I didn't take the time to educate myself about the challenge and my performance suffered because of it.
Next, locate and define the key components of the code you are looking at. Are you working with an array? An object? Do you need to use bracket notation or dot notation? Where are the functions and what are they doing? Take 15 minutes and read the whole code over so you have a clear picture of where you are and where you need to go.
Finally, keep testing. Coding in my experience is about 70% research and testing and 30% actually typing. If you want to see something work, keep running that code and watch your changes. At the end of the day, you'll want to talk about what you want to happen, giving you a chance to speak in code and give the interviewers the chance to see you in action. 
Take heart in yourself and your abilities. These interviews are intimidating, and sometimes very tough. Even if it doesn't go well, you can walk away with a good idea of what you need to work on and how to improve your practice. 
Good luck, and happy coding!
&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Console.log(everything)</title>
      <dc:creator>DwightColbyJack</dc:creator>
      <pubDate>Sat, 29 May 2021 23:46:56 +0000</pubDate>
      <link>https://dev.to/notmuchnotmuch/console-log-everything-50nb</link>
      <guid>https://dev.to/notmuchnotmuch/console-log-everything-50nb</guid>
      <description>&lt;p&gt;As a new developer, things like debugging can be tedious, confusing, and disheartening. Thinking and planning in a computer language calls for incremental building of the behavior you want and when conceptualizing that behavior it often helps to just "take a look under the hood." Thanks to console.logs you can see an element you want created, observe what kind of promise you get after a fetch call, and track the behavior of your functions. &lt;br&gt;
The MDN definition for console.log states &lt;br&gt;
"The Console method log() outputs a message to the web console. The message may be a single string (with optional substitution values), or it may be any one or more JavaScript objects."&lt;br&gt;
When making a fetch call in a Javascript application I wanted to make, I plugged by returned promise in a "data" variable into a console.log and behold the console showed me the structure and content of the promise in the dev tools. &lt;br&gt;
During a tutorial build out of a NextJS/ Advanced React webpage, we console.log the return of some functions to see their behavior in action. Console.log is one of the most important tools in my development practice. &lt;/p&gt;

</description>
    </item>
    <item>
      <title>Hold on to Your Props!(creating components for every page in NextJS)</title>
      <dc:creator>DwightColbyJack</dc:creator>
      <pubDate>Sat, 22 May 2021 19:50:13 +0000</pubDate>
      <link>https://dev.to/notmuchnotmuch/hold-on-to-your-props-creating-components-for-every-page-in-nextjs-1hob</link>
      <guid>https://dev.to/notmuchnotmuch/hold-on-to-your-props-creating-components-for-every-page-in-nextjs-1hob</guid>
      <description>&lt;p&gt;Making pages and an associated Page component is the name of the game for organizing your layout in React and NextJS. The page itself will route you to specific content and the Page component (note the capital P) can hold onto things like Navigation components, Footer components, Sidebar components and the like. The general rule is that pages will be wrapped in their Page component and render &lt;code&gt;{props.children}&lt;/code&gt; so whatever content is within a page, and whatever you might want from it's parent &lt;code&gt;&amp;lt;Page&amp;gt;&lt;/code&gt; will be rendered. This is redundant though, especially if you have a great many pages to wrap in a component and import that component and I can feel my knuckles aching just thinking about it. As a higher scope to hold the Page component, NextJS offers the &lt;strong&gt;_app.js&lt;/strong&gt; page, which will live in the pages directory. This can be considered a "container" of the highest scope for NextJS and can be used to render the Page component and two props, namely the &lt;code&gt;&amp;lt;Component&amp;gt;&lt;/code&gt; prop and &lt;code&gt;pageProps&lt;/code&gt;. It will look something like this inside _app.js:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;&amp;lt;Page&amp;gt;
  &amp;lt;Component {...pageProps} /&amp;gt;
&amp;lt;Page&amp;gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;Boom! A global &lt;code&gt;&amp;lt;Page&amp;gt;&lt;/code&gt; that can wrap around the &lt;code&gt;&amp;lt;Component /&amp;gt;&lt;/code&gt; prop. This represents an active page and any props passed to it will be received by the page itself. &lt;code&gt;pageProps&lt;/code&gt; represent the initial props, preloaded by a fetch method and will be empty without a call to that method. &lt;br&gt;
Woof! All that work (it's actually really quick once you see it in action) and now we can persist anything we want to display on every page we choose!&lt;/p&gt;

</description>
      <category>nextjs</category>
      <category>react</category>
    </item>
    <item>
      <title>Styled Components and ReactJS</title>
      <dc:creator>DwightColbyJack</dc:creator>
      <pubDate>Sun, 16 May 2021 02:54:22 +0000</pubDate>
      <link>https://dev.to/notmuchnotmuch/styled-components-and-reactjs-c0e</link>
      <guid>https://dev.to/notmuchnotmuch/styled-components-and-reactjs-c0e</guid>
      <description>&lt;p&gt;I went to school for graphic design, and while I excelled at rendering and photo manipulation, web design was always a pain-point for me. A lot of CSS, or "cascading style sheets" deal with determining the elements on your page that you would like to organize or style using class and id tags. When you know what combinations you want to group and apply styles to, the file they come from is off in another directory like "assets" or "styles" and this all follows a protocol that is somewhat standardized and accepted as best practices. However, React offers the ability to style components in line, meaning you can differentiate some components based on their change in state, their importance, or even just to shake things up for the user for a little fun.&lt;br&gt;
The question is, how do we maintain a readable and understandable code base in terms of our styles. If you've got inline styles and styles from a stylesheet conflicting, it can be a pain to debug the look of your application. Styled Components makes use of tagged template literals which is a recent addition to JavaScript. Essentially scoping CSS is the name of the game with Styled Components, giving us the ability to package the many styles we want for our React Components in in components dedicated to styles alone, and using them as a "wrapper." The wrapped component will have access to styles in the wrapper and those styles can wrap ANY component we choose. The really wild thing about styled components is the syntax. Tagged template literals use the back ticks we might use to interpolate. You can then define a const variable (whatever you want to name the style-component you're making) and set it equal to "styled", like so:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;const CartItemStyles = styled.li`
  padding: 1rem 0;
  border-bottom: solid var(--lightGrey);
  display: grid;
  grid-template-columns: auto 1fr auto;
  img {
    margin-right: 1rem;
  }
  h3, p {
    margin-right: 0;
  }
`;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;The li tag will define the elements to be styled with this style-component, but whatever we wrap in  will adhere to these CSS rules and it can be used all over our application. React is already making my development work alot more streamlined, but finally making all that code look good is even more convenient thanks to Styled Components.&lt;/p&gt;

</description>
    </item>
    <item>
      <title>My journey through NextJS</title>
      <dc:creator>DwightColbyJack</dc:creator>
      <pubDate>Sat, 08 May 2021 05:11:20 +0000</pubDate>
      <link>https://dev.to/notmuchnotmuch/my-journey-through-nextjs-414f</link>
      <guid>https://dev.to/notmuchnotmuch/my-journey-through-nextjs-414f</guid>
      <description>&lt;p&gt;I recently graduated from the Flatiron School for Software Engineering. It was truly an experience in building on a foundation, namely Ruby, the beloved object-oriented programming language. At the end of the course, I found myself drawn to React, the Javascript-based library used to build-out interactive user interfaces. React is based on components comprised of Javascript logic, in self-contained "building-blocks" that are easy to compose and reuse as needed. React's true utility is templating data and efficiently rendering those templates to the DOM. From a visual learner's stand-point, being able to see a '' component and a '' component in the editor brought the big picture into focus without a ton of code obscuring the greater vision for an application. &lt;br&gt;
In exploring where to go after graduation, I found out about NextJS through a tutorial offered by Wes Bos, a popular programming blogger, educator and developer. While my blog will follow my journey through this course, I want to emphasize the greater technical take-aways from what I learn rather than give a "review" of the program. So to start off, NextJS is a framework that acts like a wrapper for React components, offering greater capabilities like routing, pages, static or server rendering and image handling. Enter pages; the "pages" directory offered by the framework offers easier composition of applications and produces the literal pages of a website using file-system-based routing. Add a page to the directory and immediately get that route created as well. As a light comparison I'd like to show-off the logic used to set routes in a React project I did for Flatiron called Lookin' Sharp. Here's a look &lt;br&gt;
&lt;a href="https://res.cloudinary.com/practicaldev/image/fetch/s--6fP0vtbr--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/37rcddjlhh5586fotn5l.png" class="article-body-image-wrapper"&gt;&lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--6fP0vtbr--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/37rcddjlhh5586fotn5l.png" alt="React routing pic"&gt;&lt;/a&gt;&lt;br&gt;
All wrapped together are a Switch component, the Router component from React Router and then the individual components to be routed...somewhere in there. Not to mention the React container holding onto this big chunk of code, it's beginning to look like a needle in a haystack scenario figuring out how to get from page to page. Now here's a peek at what it takes to route with NextJS: &lt;br&gt;
&lt;a href="https://res.cloudinary.com/practicaldev/image/fetch/s--J0ua9Fsx--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nnjkzyw690ukv9of9m7n.png" class="article-body-image-wrapper"&gt;&lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--J0ua9Fsx--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nnjkzyw690ukv9of9m7n.png" alt="NextJS routing"&gt;&lt;/a&gt;&lt;br&gt;
Boom, we define them in the pages directory and we can already navigate to those pages and their content. Index, the sell page, the signin page all routed for you upon creation! I'm loving the advantages of NextJS and honestly can't wait to start building more applications with it! &lt;/p&gt;

</description>
    </item>
  </channel>
</rss>
