DEV Community: Jordan Snow

What I Have Learned About Freelance Web Development

Jordan Snow — Mon, 01 Jun 2020 19:00:35 +0000

As I am growing in the world of software development, it's becoming more and more clear that the experience is completely different for everyone. Sounds like it should be common sense, right?

But here's the thing...it's not! I've spent the last year researching and learning as many javascript topics as I could shove into my head, and I've started noticing a pretty large misconception shared by many blogger-developers. I bet you've noticed the same thing - how many times have you seen someone say "All you need is working knowledge of HTML and CSS to start your design or development journey!" or "I've known many people who have made a career using just HTML and CSS!"

That's just not quite true...

"...Using Just HTML and CSS"

The only way that you'll be able to use just HTML and CSS to create a career doing freelance development would be to specialize in it. While there is nothing wrong with that in general, it will shut a lot of potentially lucrative doors for you.

That's just not quite true...

By specializing, I mean only doing HTML/CSS work. That means that any time you need any functionality like what Javascript provides, either you will have to hire a developer, or your client will. Either way, that's money out of your pocket. Some people are ok with that - I'd rather keep as much productivity as I can provide one of my customers in-house. This will maximize customer satisfaction, as I then have control over quality and can guarantee consistency across the entire project; if I were to outsource 3/4 of the same project to provide javascript functionality, get the backend built, build an API, make sure everything communicates, deploy, set up NGINX, and set up SSL, I've lost thousands. Not to mention, unless you have good working relationships with every one of the subcontractors that you hired for all of the above steps, you can't guarantee that they will exercize the same care of your project as you did.

The Better Option

In my humble opinion, it's a much better option to really deep dive into your functional language of choice (mine's obviously Javascript), and create and deploy your own website. I suggest deploying multiple different ways; Netlify/Heroku/Zeit Now to start, then moving to a VPS (or virtual private server) like DigitalOcean or Linode.

JAMstack Deployments

Heroku, Netlify, and Zeit are examples of JAMstack deployment. JAMstack stands for Javascript, APIs, and Markup. With most of these, there will be a command line tool to allow for quick, one command deployments from the command line. How cool is that? Trust me when I say the learning curve for these tools is not steep - the first time I deployed to Zeit, which has recently been rebranded to Vercel (you can find the docs here) using it's now command line tool, it only took a few hours to figure out. Hours, not days. You can also hook these up with Github Integrations so that your site will rebuild on subsequent code pushes. Check it out, now your doing CI/CD like a true DevOps engineer 😉

DigitalOcean Deployments

My favorite way to deploy my sites is through DigitalOcean. DigitalOcean provides a VPS service that is incredibly easy to get rolling. VPS solutions differ from JAMstack by building a completely private server instance within a cloud server(for DO, this is called a "droplet"). This means that you are not limited in the technology and softwares you want running on your servers!

For $5/mo, DO will partition you a Linux server instance, running whatever distribution you want, on a single virtual core, with 25GB SSD space and 1GB RAM. Pretty impressive, for the amount of versatility you receive - you can access the new server by simply running ssh <your-droplet-ip> in your command line, and boom, you're in! And when I say you're in, I mean you have now remotely accessed your private server, and are now free to install whatever softwares and technologies you'd like! How cool is that?!

DO's pricing plans run up from there, but I still haven't found a need to go over their $10/mo plan for anything I've needed. If you'd like to give DigitalOcean a shot, you can use this link to get $100 free credits! Tell me you can't figure out how to use it with that deal, you won't even have any skin in the game!

DigitalOcean has a slightly steeper learning curve, as you will be using a Linux system via the command line. There are many resources for doing this online, and I will also be writing an article detailing how to set up your first droplet soon!

Taking it a step further

There's always more to learn - after you have your application running on whatever medium you choose, it's then time to take charge of your domains, set up SSL, and set up reverse proxies and load balancers. I know this all seems like a lot, but don't despair. If I can do it, you can definitely do it! One of the biggest skills a developer can have is the ability to search the web for answers to your questions, so when you get stuck, whip out the old Google and start researching!

Another hint I can give is keep notes the first time you work through anything you haven't done before. This will make it easy to reference later for steps to duplicate, and/or figuring out better ways to do things.

Here's What I'm Saying

Basically, don't stunt yourself by just being satisfied learning one, or two, or even a few, different things. Continue to challenge yourself, continue to move forward, and learn something new every day. After awhile, you'll be able to decide what you really don't want to work on, and outsource just those little pieces. This approach will maximize the revenue that you'll be able to keep in your pocket for each project, rather than having to shell out for things that you never took the time to learn how to do.

Do you have any thoughts or opinions on this topic? I'd love it if you shared them in the comments - I'm sure I'll be able to learn something from you, too! If you're interested in the work I do, or maybe want to hire me for an upcoming project, jump on over to my website and use the contact form there!

Hope everyone's having a great day! Get out there and learn something new!

How to Develop HTML (the right way)

Jordan Snow — Fri, 29 May 2020 22:06:41 +0000

Lately, I've been noticing a trend. With all the Javascript frameworks having a battle royale to decide who's going to come out on top (React, Vue, Angular), proper HTML practices have been dwindling. It's become so much easier to write your HTML using Javascript that the div tag is truly starting to reign, and it's terrible.

So, without further ado, here's my top six list of proper HTML practices to make you a better developer!

1. Use Semantic Tags

One of the very first things that you should keep in mind when trying to write production ready HTML is to use "semantic" markup. Stop using div tags, please! For instance, rather than:

<!DOCTYPE html>
<html>
<head>
  <title>Hello World</title>
</head>
<body>
  <h1>Welcome</h1>
  <div>
    <div>
      <div>
        <p>Some header</p>
      </div>
      <div>
        <div>
          Some subheader
        </div>
      </div> 
    </div>
  </div>
</body>
</html>

Try this out for size:

<!DOCTYPE html>
<html>
<head>
  <title>Hello World</title>
</head>
<body>
  <section>
    <header>
      <h1>Doc Title</h1>
      <p>Some subtitle</p>
    </header> 
  </section>
</body>
</html>

This is much cleaner, and is so much easier to decipher if another developer needs to access, modify, or fix a break in your code later. Many times, div tags are unavoidable for styling purposes, and it's in this area where they shine, but they should NOT be used as a catch all tag for any section or text manipulation you may need.

2. Use Lowercase for Your Markup

This one seems like a given, but I think it should definitely be said. Uppercase is reserved for text elements, React Components, and other use-cases. It's not for the markup. When I'm looking through a document's source, my eyes recognize important patterns that help me find whatever it is I'm searching for. I saw a site once that had been written with the HTML tags completely caps locked the entire time (ie <HEAD></HEAD>, <TITLE></TITLE>) - you have no idea how bad this messed with my tiny brain. I couldn't find anything. And then smoke started wafting out of my ears. I almost quit coding. Don't make people like me quit coding and start smoking, use lower case.

3. Pay Attention to Accessibily

There's a reason there are a lot of assets for learning accessibility in regards to web development. There are a lot of people out there that struggle with disabilities such as blindness or color-blindness. On top of just being a good person/developer, there's also compliance issues that you can end up with you facing a lawsuit. Do your research and study the WCAG and ADA standards to ensure you're developing a good product for all of your users.

Here are some really great resources for learning about accessibility

4. Don't Use Inline Styles

There are so many ways to style your documents anymore, it's getting insane. CSS, LESS, SCSS, SASS, Bootstrap, MaterialUI, Tailwind, CSS-in-JS, JSS, the makeStyles() hooks, and just so much more. Here's a tip that you can use no matter which you go with: don't ever use inline styling in your markup. It's a terrible idea that will literally send you on goosehunts for hours to figure out what's going on with your styling. Component level stying, global styling, choose any other way to style your elements, but don't inline style.

The reasoning behind this is fairly simple - inline styling sets the priority for that style higher than all of your other stylesheets, so that while you're using the stylesheets to tune and tweak your design, you'll have these pesky little aberations that will refuse to go away. You'll have to dive into your inspection tools and sometimes even dig around there for awhile before you'll find the exact place where that specific style (or lack thereof) is coming from. Beyond frustrating, let me tell you. The problem then grows exponentially when you're working on a site that wasn't written by you, but that you were hired to tweak or fix, and there are inline styles peppered through the code arbitrarily. Best practice is to keep all of your styles in the designated styling sections or sheets related to the project.

5. Learn How to Form

Forms are a type of data management that are not going to disappear any time soon. As such, learning the proper way to markup, and then use, form data is an invaluable skill. <fieldset>, <legend>, <label>, these are all semantic tags that definitely should be used in almost every form to ensure good behavior and ease of updating later. The attributes for form data make these things so much better, too.

<input type='email' name='email' id='email' placeholder='john@smith.com>

This can end up being kind of confusing sometimes, but well worth it to learn. Every attribute above can be integral in making your code function as you want it to consistenly. These really start to become even better when used in React and Vue, or alongside Bootstrap or MaterialUI, because each of those frameworks or libraries has boilerplate styling for forms and form validation that makes life a breeze.

6. Review Your Code

[Neatness] is all the next developer is going to care about...!

Don't ever settle for "good enough". Make sure your code stands out. Every piece of code you make is a work of art, and one that was created by you. I don't really have opinions on tabs vs spaces, or two-space vs four-space tabs, or semi-colon use, or even single quotes vs double quotes (let me know your opinions in the comments!) - I care about readability, structure, organization, consistency, and neatness, and here's a secret - that's all the next developer is going to care about, too! Feel free to make your code yours, but review it, edit it, and make it perfect for the next guy who has to work on it.

There it is, not much to it. Use semantic tags, structure your HTML well, use forms, make your sites accessible, and please - even if you don't follow any of the other recommendations on this article - don't use inline styling 😉

As always, leave your comments, thoughts, opinions and recommendations in the comments, let's have a conversation! If you'd like to employ my services to transform your web presence into a business aid instead of a hindrance, check out my website, or find me on Facebook. Hope everyone is having a great day! Now get out there and learn something new!

Choosing a Content Management System

Jordan Snow — Mon, 25 May 2020 17:50:23 +0000

First off, let's get something straight. I'm something of a new developer. I played hell trying to figure out what the differences were between headless, decoupled, and legacy CMS's, as I'm sure any new developer who is teaching themselves how to code would under the same circumstances. The weird part, though, is that I have never really messed with Wordpress or Drupal (or any other traditional CMS). This really slowed me down in the long run, because when I started my search for a good headless CMS, I really didn't even know what I was looking for!

The SnowDev Blog

The only thing I really knew was that I needed some kind of system to reliably and efficiently write and consume my blog posts. I had a few simple requirements:

I needed to be able to use the CMS with my own custom frontend, as I was trying to teach myself as much as I could about development
I knew I would need a badass API system for when my blog goes completely viral and I have to set up load balancers on 12 different servers to be able to handle all the visitors 😁😁
I really wanted to have an excellent admin panel, with included editor, so that I wouldn't have to build it ALL on my own!
Whatever I chose had to be completely open source!

All these things had to exist in one place, right? So I fired up the trusty old Google search and started clicking away on the keyboard, but what was I actually looking for?

All CMS's Are Not Created Equal

The first thing I had to come to grips with was that there are profound differences between content management systems. So I needed to start chiseling out some definitions for myself.

Traditional Content Management System

Come to find out, a traditional CMS, such a Wordpress, Drupal, and Joomla, to name just a few, IS a solid way to get all of things you need to run a blog in production quickly. I didn't go this route, and while I truly learned a lot and accomplished my goals, I also decided that this really is the only option for the person who has minor technical chops, but who really wants to get a website up and running yesterday.

Sites like these are absolutely designed with the "leyperson" in mind. They truly have everything - SEO out of the box, secure and streamlined admin panels and content editors, full REST API's that are easy to work with (as long as you don't get too crazy about thinking outside their box), and beautiful frontends that make your website look like they were designed by an absolute pro (...well, because they WERE!). And don't even get me started on deployment! It's so easy! No worrying about Nginx or load balancing or Linux or DigitalOcean or, or, or...However, this really isn't what I was looking for. While I learned how cool some of these could really be, they definitely haven't converted me.

Decoupled CMS

I'm going to admit something here...I really didn't even know these were a thing until it was too late and I had already taken the bait. In fact, my blog as it sits right now, at the writing of this, uses a decoupled (not 'headless', as it's documentation says) CMS called Ghost. Now don't get me wrong, Ghost is pretty cool for a lot of reasons, and for the right person, I believe it would be fantastic. The Github community agrees, as right now Ghost has about 33.8K Stars. That's some pretty impressive numbers, but for as excited as I was, I was pretty let down when I finally got it up and running.

First of all, the documentation literally screams that Ghost is a "headless" CMS. Screams it.

So imagine my disapointment when I realized that this system was more "decoupled" than it was "headless". A decoupled CMS has frontend, backend, and admin UI components, and you can decide which to use interchangably. For instance, Ghost is technically a legacy CMS that has been decoupled - which is great! I just wish they'd use the right terminology to describe their product, especially for new guys like me. What they really did was give out the API, which allows you to make calls from a custom frontend and consume the data. They don't allow you to shut off the site with their frontend running, however, as this is where the admin UI is located as well! (ie. - the frontend server is running on example.com, while the admin panel is running on example.com/ghost. This was very frustrating to me, and I spent entirely too many hours trying to figure out how to shut off the frontend for a supposedly "headless" CMS.

An Actual Headless CMS

It's ok, though. Thank the Lord for Youtube subscriptions. My man Brad Traversy over at Traversy Media really came through for me, without ever knowing he was doing it! Right in the thick of my woes over this CMS struggle, I get a notification that he had a new video, giving a runthrough of something called Strapi. I was done coding for the night and ready for something a little different, so I checked it out. Glad I did...

Strapi is a truly headless, API-first, content management system. This means that, out of the box, you get an insanely powerful tool capable of making flexible data structures without breaking a sweat. Defining models, controllers, and middleware ("policies", in Strapi-speak) is a breeze. And then, and here's the best part, there is no frontend. None. You can consume Strapi API from any client. React? Check. Gatsby? Check. What about Angular, Vue, hell, even just a vanilla HTML/CSS/JS site? Yup, that works too.

I'm gonna blow your mind with this one, it get's even better - Strapi even works with GraphQL!!

I mean, the thing is just crazy. It comes with a --quickstart flag in it's CLI tool that, you guessed it, quickly starts your own instance of a development server, complete with SQLite and a file watcher that hot reloads the server, and a performant and efficient browser-based GUI for the developer. I could literally go on for about a thousand lines about how cool this thing is, so you're just going to have to take my word for it and go try it out!!!

So Let's Recap

A true headless CMS is API-first, meaning it doesn't have any frontend whatsoever forconsuming the data of your API, just creating and maintaining it
- great for developers, steep learning curve for the blogger that just wants to get their words published online
- most technical to get started with
A decoupled CMS has individualized components, ie a backend, API, frontend, and admin interface, and each part can be used somewhat individually
- Really good intermediate starting point for the beginner developer that wants to learn about this stuff, but quickly stifling with the push to only use it in one way
A traditional, or legacy, CMS, provides everything in one package
- The easiest way to get started, perfect for the professional blogger who wants to make their own small site without much customization

As always, if you have any questions, comments, concerns, or criticisms, feel free to drop a comment below! I would love to write an article on something you bring me! Make sure to watch for upcoming articles on how to get both a Ghost site and a full Strapi site deployed! These will be complete walkthroughs, with technical breakdowns of all the steps necessary to get a site up and running using both of these technologies!

Also, drop on by my website - Snow Development, and check out my blog running on the Ghost platform before I jump it over to Strapi!