DEV Community: Dennis Krasnov

DO Hackathon: Official Submission

Dennis Krasnov — Sat, 09 Jan 2021 19:59:46 +0000

What I built

I built a portfolio website showcasing my skills and experience. Check it out at denniskrasnov.com!

Category Submission:

Personal Site/Portfolio

App Link

denniskrasnov.com

Screenshots

Description

denniskrasnov.com is a portfolio website showcasing my skills and experience.

Features custom art and branding for a personal touch.

I designed the website myself, with an equal focus on performance, design, and accessibility.

See my first post in this series to find out how how I designed my portfolio, my second post to see how it's deployed, and my third post to see deployment benchmarks.

Link to Source Code

github.com/Dennis-Krasnov/Portfolio

Permissive License

MIT License

Background

(What made you decide to build this particular app? What inspired you?)

Building a personal brand is important for my career. In 2020, an online presence is non-negotiable, and a portfolio website allows me to showcase my skills and experience in a way that is not possible via the traditional resume format.

How I built it

(How did you utilize DigitalOcean’s App Platform? Did you learn something new along the way? Pick up a new skill?)

My website is written in Svelte for its simplicity and performance, while Sapper compiles my website into a static bundle. See my first post for more details.

DigitalOcean's App platform can host and distribute the static bundle on a content delivery network, which simplifies devops and minimizes latencies. Check out my second and third posts in this series for more info :)

Additional Resources/Info

You can use the Deploy to DigitalOcean button to deploy this repo directly to App Platform :)

DO Hackathon: Deployment Benchmark

Dennis Krasnov — Sat, 09 Jan 2021 19:59:39 +0000

Nobody likes waiting for a website to load, so it's important to have performance in mind while hosting websites.

In this article, I will compare the performance of both the deployment methods from the previous article in this series.

Benchmark Methodology

I'll be focusing exclusively on latency as that's what the end-user cares about. I'll be running an http benchmark tool from DigitalOcean droplets located in Toronto 1 and in Frankfurt 1, running these scripts:

# Kubernetes deployment
echo "GET https://krasnov.dev" | vegeta attack -duration=60s | vegeta report

# App Platform deployment
echo "GET https://denniskrasnov.com" | vegeta attack -duration=60s | vegeta report

The Results

Toronto 1 -> Kubernetes (Toronto 1)

Note that both resources are in the same region.

Requests      [total, rate, throughput]         3000, 50.02, 50.01
Duration      [total, attack, wait]             59.983s, 59.98s, 2.885ms
Latencies     [min, mean, 50, 90, 95, 99, max]  1.715ms, 3.944ms, 2.485ms, 3.147ms, 5.321ms, 50.502ms, 144.859ms
Bytes In      [total, mean]                     6348000, 2116.00
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:3000

Toronto 1 -> App Platform

Requests      [total, rate, throughput]         3000, 50.02, 50.01
Duration      [total, attack, wait]             59.986s, 59.98s, 5.764ms
Latencies     [min, mean, 50, 90, 95, 99, max]  5.141ms, 9.251ms, 7.443ms, 13.194ms, 17.124ms, 30.828ms, 223.472ms
Bytes In      [total, mean]                     40320000, 13440.00
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:3000

Frankfurt 1 -> Kubernetes (Toronto 1)

This represents a user that lives far away.

Requests      [total, rate, throughput]         3000, 50.02, 49.94
Duration      [total, attack, wait]             1m0s, 59.98s, 96.21ms
Latencies     [min, mean, 50, 90, 95, 99, max]  95.502ms, 103.55ms, 96.419ms, 98.411ms, 103.918ms, 344.845ms, 616.864ms
Bytes In      [total, mean]                     6348000, 2116.00
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:3000

Frankfurt 1 -> App Platform

Requests      [total, rate, throughput]         3000, 50.02, 50.01
Duration      [total, attack, wait]             59.986s, 59.98s, 6.333ms
Latencies     [min, mean, 50, 90, 95, 99, max]  4.248ms, 9.539ms, 6.037ms, 9.089ms, 11.87ms, 62.803ms, 666.033ms
Bytes In      [total, mean]                     40320000, 13440.00
Bytes Out     [total, mean]                     0, 0.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      200:3000

Mean latencies from all runs

Kubernetes

Kubernetes clusters are designed to be hosted in one location. This works well locally, but is slower when users are far away.

App Platform

Hosting on App Platform is geographically distributed (thanks to the built in CDN), and is performant no matter where the users are located.

Conclusion

For static websites, hosting on Digital App Platform can be more performant for users far away.

DO Hackathon: Devops Architecture

Dennis Krasnov — Sat, 09 Jan 2021 19:59:31 +0000

Once we have a portfolio website ready, we need to host it to make it publicly accessible on the web. Devops, among other things, is the automated process of pushing code onto production hosting.

In this article, I will cover two ways (out of many) to do hosting and devops for a static website.

Method 1 - DigitalOcean Managed Kubernetes

This version of the website is currently hosted at krasnov.dev.

Steps:

Setup a Kubernetes cluster and container registry
Apply Kubernetes deployments, services, ingresses, etc.
Commit and push code
Within a CI/CD tool:
1. Build an OCI image
2. Push the image to a container registry
3. Update the Kubernetes cluster to use the new image

notes:

Much harder than it looks, Kubernetes is notoriously complex
It takes a minimum of $10/month for a single node and $10/month for a load balancer on DigitalOcean
Kubernetes can be used to host just about anything, it's amazing if you're planning to host many other applications

Method 2 - DigitalOcean App Platform

This version of my portfolio is currently hosted at denniskrasnov.com.

Steps:

Hook up App Platform (starter variant) to GitHub
Tell it how to build
Tell it which output folder to use
Commit and push code

Just click the button to get started.

notes:

This is about as simple as it gets, definitively does "Get apps to market faster" as promised
You can host 3 sites for free, then at $3/month for more, not bad for what you get
App Platform also supports hosting services and databases, which is enough for most use cases

Conclusion

That covers the two ways that I've hosted my portfolio. Between the two, DigitalOcean App Platform is by far the easier option.

Next up, I will benchmark both these deployment options.

DO Hackathon: Portfolio Design

Dennis Krasnov — Sat, 09 Jan 2021 19:59:21 +0000

Building a personal brand is important for any developer's career. Maintaining a portfolio is a great way to get an online presence. While resumes are limited by conventions and a piece of paper, portfolios can showcase your skills and experience in the best way possible.

In this article I will showcase and justify the design of my portfolio. Check it out at denniskrasnov.com.

Goal

My portfolio should:

Showcase my skills and experience
Make it easy for recruiters and hiring managers to access my resume
Ultimately get me more job opportunities :)

Layout

Landing Section

The goal is to keep things short and simple, with a focus on benefits instead of features, ie. "developer available for hire" instead of "I'm a developer".

The button to download my resume provides a clear call to action. while the caricature adds some personality to the website :)

Skills Section

Most jobs look for a certain set of skills. The goal is to make it easy for the recruiter or hiring manager to check off these requirements.

Thus I logically divided my skills into six categories, and highlighted the important bits.

Content that is above the fold (visible without scrolling down) gets viewed the most. The skills section is important enough to put place near the top.

Testimonials Section

Social proof helps with credibility, whether it's reviews, recommendations, or testimonials.

Work Section

Obviously, work experience is very important when applying to jobs.

I stylized a standard resume layout to make it more pleasing to look at.

Projects Section

I have several notable side projects, and want to showcase them to their fullest potential.

Thus I created a catchy thumbnail for each project which leads to a case study (description, demo, and optionally highlights).

Education Section

Not much to say here, in my case I want to put more emphasis on everything else so I ordered this last.

Technology

My content doesn't change often, so a static website is all I need. I also want to use a JavaScript framework and SCSS.

I settled on Svelte and Sapper for several reasons:

Working with Svelte feels very similar to working with vanilla HTML and CSS, it's simple and enjoyable
Svelte is extremely lightweight
Sapper compiles into a static website bundle (reactive Svelte sprinkled in where needed)
Much like a class in an object oriented language, Svelte components are:
- Reusable
- Composable
- Enables separation of concerns (JavaScript logic and scoped CSS)

Here's a snippet of code to demonstrate the kind of high level code that's possible with Svelte:

<Section id="skills" watermarkPadding dark>
    <WatermarkHeader title="skills" />
    <Skills>
        <Skill
            imageUrl="/skills/backend.svg"
            title="Backend Development"
            summary="<b>Spring</b>-based <b>Java/Kotlin</b> ..."
        />

        <!-- other skills ... -->

    </Skills>
</Section>

<!-- other sections ... -->

Right now I hard code website content in the code, but if I ever get tired of editing source code to change content, I can source the data from a content management system easily with minimal changes.

Conclusion

That covers the layout and the technologies that I used to make my portfolio.

Next up, I will cover how I deployed my portfolio.