DEV Community: Shaquil Hansford

Test from takeshapeio

Shaquil Hansford — Fri, 11 Jun 2021 18:52:07 +0000

Test

Post for Mondo Robot Example, Baby!

Shaquil Hansford — Fri, 07 May 2021 23:26:57 +0000

This article comes from Tomislav Capan, technical consultant and Node.js enthusiast. Tomislav originally published this in August 2013 in the Toptal blog — you can find the original post here; the blog has been slightly updated. The following subject matter is based on the opinion and experiences of this author.

Introduction

JavaScript’s rising popularity has brought with it a lot of changes, and the face of web development today is dramatically different. The things that we can do on the web nowadays with JavaScript running on the server, as well as in the browser, were hard to imagine just several years ago, or were encapsulated within sandboxed environments like Flash or Java Applets.

Before digging into Node.js, you might want to read up on the benefits of using JavaScript across the stack, which unifies the language and data format (JSON), allowing you to optimally reuse developer resources. As this is more a benefit of JavaScript than Node.js specifically, we won’t discuss it much here. But it’s a key advantage to incorporating Node.js in your stack.

Node.js is a JavaScript runtime environment built on Chrome’s V8 JavaScript engine. It’s worth noting that Ryan Dahl, the creator of Node.js, was aiming to create real-time websites with push capability, “inspired by applications like Gmail”. In Node.js, he gave developers a tool for working in the non-blocking, event-driven I/O paradigm.

In one sentence: Node.js shines in real-time web applications employing push technology over websockets. What is so revolutionary about that? Well, after over 20 years of stateless-web based on the stateless request-response paradigm, we finally have web applications with real-time, two-way connections, where both the client and server can initiate communication, allowing them to exchange data freely.
This is in stark contrast to the typical web response paradigm, where the client always initiates communication. Additionally, it’s all based on the open web stack (HTML, CSS and JS) running over the standard port 80.

One might argue that we’ve had this for years in the form of Flash and Java Applets — but in reality, those were just sandboxed environments using the web as a transport protocol to be delivered to the client. Plus, they were run in isolation and often operated over non-standard ports, which may have required extra permissions and such.

With all of its advantages, Node.js now plays a critical role in the technology stack of many high-profile companies who depend on its unique benefits. The Node.js Foundation has consolidated all the best thinking around why enterprises should consider Node.js in a short presentation that can be found on the Node.js Foundation’s Case Studies page.
In this post, I’ll discuss not only how these advantages are accomplished, but also why you might want to use Node.js — and why not — using some of the classic web application models as examples.

How Does It Work?

The main idea of Node.js: use non-blocking, event-driven I/O to remain lightweight and efficient in the face of data-intensive real-time applications that run across distributed devices.

That’s a mouthful.

What it really means is that Node.js is not a silver-bullet new platform that will dominate the web development world. Instead, it’s a platform that fills a particular need. And understanding this is absolutely essential. You definitely don’t want to use Node.js for CPU-intensive operations; in fact, using it for heavy computation will annul nearly all of its advantages. Where Node.js really shines is in building fast, scalable network applications, as it’s capable of handling a huge number of simultaneous connections with high throughput, which equates to high scalability.

How it works under-the-hood is pretty interesting. Compared to traditional web-serving techniques where each connection (request) spawns a new thread, taking up system RAM and eventually maxing-out at the amount of RAM available, Node.js operates on a single-thread, using non-blocking I/O calls, allowing it to support tens of thousands of concurrent connections (held in the event loop).

test

Shaquil Hansford — Thu, 06 May 2021 21:36:22 +0000

test

I made an app that publishes your blog posts to multiple platforms at once.

Shaquil Hansford — Fri, 02 Apr 2021 15:21:46 +0000

Blogging is one of the most powerful tools in your toolbox as a developer, whether you're an entrepreneur or a member of a team. But as someone whose career path requires constant learning and growth, your most precious resource is time--and blogging takes up a lot of time.

Even worse, there are so many platforms to choose from. Should you go with Medium, Dev.to, Hashnode, or a self-provided solution like Ghost CMS?

With OnePush, you don't have to make that choice anymore.

OnePush.blog lets you link your Medium, Dev, Hashnode and Ghost accounts together in one place, so that you can write your posts in one editor and publish them on any combination of platforms that you want--all with the push of one button.

In fact, I'm writing this from OnePush right now, and posting it to Medium, Dev, Hashnode and Ghost! I mean... if Hashnode's moderators will let this through.

A Technical Look at the Features

While the above description tells you all you need to know about the app as a user, it doesn't detail the process of actually constructing the app.

From a developer's standpoint, I had two issues to worry about: Providing a simple but informative frontend for the users, and a thorough and precise backend for the platforms they will be publishing to.

On the frontend, I had to create buttons, inputs and checkboxes that essentially give the user a tutorial on how the platform works, while also being easy enough to jump into if you're not confused. This was a bit complicated, and I ended up conceding in the mission a little when it came to teaching users how to connect OnePush to their accounts on other platforms.

You see, each popular blogging platform has its own unique way of implementing what is essentially the same solution to the problem of integrating external apps. They use JSON web tokens, which you generate by going through the settings in your account--but some of them also need other tokens which cannot be generated through their user interface.

Worse, each of them hides their API token settings in different parts of their UI's, and there isn't any simple way to explain this to a user from OnePush's perspective other than to say, "Hey, go into your account and look around for tokens. If you find them, paste them here.

In my custom backend, I had to not only craft fetch requests for each API endpoint on each platform that a user can post on, but I had to build robust error-handling systems. It's incredibly vital, especially when you're posting to an existing audience, that you know if any issues happened with posting your content, and that you have a URL to the content immediately so you can make sure it came out right.

All I can say after two weeks of this work is that Error Handling Engineer should be a full-time salaried position.

Tech Stack

So you know what OnePush is, and you know why I built it--but as a coder yourself, you may be interested in how I built it.

Well, I think everyone's natural tendency, myself included, is to focus intensely on understanding the problem we're trying to solve, and then throwing solutions at it until one sticks. While this is admirable, it is a bit irrational, and can at times even be dangerous.

Metaphorically speaking, it's like seeing a flame, identifying the source of it, and dumping water on it. That may seem like a fine enough strategy at first, but fire extinguishers exist for a reason. There may have even been one on the wall beside you, but you were so focused on rapidly trying out a solution that you ignored the better one waiting right there.

With this in mind, I decided that, even though React seems like a fine enough solution for building the frontend UI, it may not actually be quite enough. In its current state, the app's UI won't change very much at all, and any users will expect their text editor to pop up as quickly is possible so they can get writing. I also wanted to do rapid prototyping by testing API calls from the UI without having to build an entire backend.

NextJS was the obvious solution.

Express and Node

But that doesn't mean I didn't eventually want to build my own backend. I knew it would allow me more flexibility for implementing future features if I did so, and I didn't want to shoot myself in the foot. In a world that rightfully reminds everyone of YAGNI (You Ain't Gonna Need It) whenever thoughts of future-proofing your code come up, it's important to remember that there's nothing wrong with a little upfront work to increase scalability.

I deployed my Node backend on Render.com for simplicity's sake, though it's slightly more expensive than Digital Ocean. In return for building out my own API and backend, I will be able to implement packages like Passport and bCrypt in the future for user accounts and login sessions.

This is very necessary, as any users of the app will soon notice. When you enter your API keys, they are remembered; but currently your blog posts aren't saved to OnePush for later editing or deleting, and if you use a different browser or clear your localstorage, you'll have to manually re-enter all that data.

We'll have logins one day soon!

What's Next?

So what's next?

A small break, please. Goodness!

But aside from that, I've got a ton of features I can already think of. Aside from implementing a user account system, I do want people to use OnePush as the "One Source of Truth," which isn't possible yet, and won't be possible until you can view and edit your posts from within OnePush. Heck, you can't even save drafts yet.

But that'll all be coming very soon. If you want to use this app, head to OnePush.blog. If you have any suggestions, I'm on twitter! @shaquilhansford.

Thanks for reading!

Final Test for Dev

Shaquil Hansford — Thu, 01 Apr 2021 01:26:46 +0000

Final Test

New Test

Shaquil Hansford — Thu, 01 Apr 2021 01:16:16 +0000

Testing again

Test Post

Shaquil Hansford — Thu, 01 Apr 2021 00:59:57 +0000

Test Post

Test post from onepush

Shaquil Hansford — Tue, 23 Mar 2021 22:07:44 +0000

This is a test post from the one-push app. Users can now add their own API keys, and it should work.

testing the dev api

Shaquil Hansford — Sun, 21 Mar 2021 03:14:43 +0000

Dev API Test!

Just wanted to test the dev.to api.

I'm building an app, and wanted to see how easy it would be to implement the API in a nextjs application. If this works, it's really easy!

Which is awesome.

Best Podcasts For New Web Developers

Shaquil Hansford — Sat, 23 Jan 2021 02:55:00 +0000

It's hard finding a good podcast when you're new to coding.

You want something with substance, so you can learn, but you want it to actually feel approachable. No one wants to be battered with jargon for an hour when they're supposed to be relaxing.

So I've compiled a very short list of the very best podcasts I've found while learning webdev. I hope it will be useful for you.

4. AWS Morning Brief

Taking the bottom place on the list is AWS Morning Brief, though not due to lack of quality. I actually love Corey Quinn's podcast; it's funny, snarky, cynical and entertaining. Most episodes are under 10 minutes long.

It fails to get a higher spot for two reasons: First, it's not strictly webdev related; and second, it's very technical.

Anyone trying to get into webdev, especially backend or fullstack development, will at some point have to consider whether or not they'll host their projects on AWS. Most likely they'll need to use some cloud provider. Even so, at the very beginning, you won't want to worry yourself with the complexities of how to specifically build out an app's cloud architecture.

You'll also struggle, because the subject itself is so dense. In fact, if Corey Quinn wasn't so fun and natural in his role as a host, the podcast would probably be unlistenable. Definitely check this out every once in a while for a fun peek into a side of the web that most coders are baffled by.

3. DotNet Rocks!

I'm just happy these guys are still around.

.NET Rocks is a long-running podcast by one current and one former Microsoft developer. And when I say long-running, I mean long-running. I first started listening ten years ago, and the show was already established by then.

This show leans more toward the conversational and chill side of coding, with technical topics being explored but not typically delivered in a tutorial style. If you want something to listen to during a road trip, this one's definitely it!

It doesn't get a higher spot on the list because, while they focus a lot on the .NET stack, their show does often talk more generally about .NET and software development as a whole. They're still well worth listening to though, if not to learn than to get some motivation to be more positive about the future of software development.

2. ShopTalk

If you haven't heard of css-tricks.com, go check it out immediately. It's an incredible resource, especially for beginners. The creator of css-tricks.com is one of the two amazing hosts of the ShopTalk podcast.

ShopTalk, like .NET Rocks, is a more chatty podcast, but unlike .NET Rocks, it's entirely geared toward webdev. You'll hear of concepts you've never heard of, get a peek into the minds of top-tier coders as they're working through their own personal projects, and get to relax and have fun along the way.

It's an excellent experience, and if there's any small flaw in it at all, it's the fact that the hosts are so bleeding edge that you may miss out on discussions of more practical, real-world aspects of webdev.

1. Syntax.fm

The perfect mix of everything.

AWS Morning Brief is fun, but man is it technical. .NET Rocks is easy to get into, but boy does it have a wide range of topics. Shoptalk is webdev-specific, but it just never feels all that instructive.

If only there was a podcast that was technical without being impenetrable, diverse in content without losing track of webdev, and chill without lacking hard educational value.

Oh, hi, Syntax.fm!

Syntax is strictly the best podcast for beginner webdevs. Your first few listens will be hard, but Scott Tolinski and Wes Bos's wonderful personalities will carry you through. Then once you start actually building projects, all the topics they discuss will suddenly make so much sense and feel so relatable. You'll also be learning a ton.

And just when all the learning and technical concepts feel too intense, the podcast still finds a way to slow everything down and feel like a fun conversation between two friends.

Honestly, you don't have to like syntax.fm, and if you dislike it, that's fair enough--but you do have to listen to it right now. It's the best of the best in my opinion.

Check me out on twitter @shaquilhansford
https://twitter.com/shaquilhansford

Thanks for reading!