Forem: Konstantin Komelin

Recording 'From Vanilla JS to Solid.js' Video Series

Konstantin Komelin — Thu, 04 Jan 2024 01:07:21 +0000

I had always wanted to have a Youtube channel where I could share my video tutorials, but had never been brave enough to start... until recently.

Meet my brand-new personal Youtube channel.

The first video series is about porting a small vanilla JS web app to Solid.js and implementing push notifications for it through Firebase.

It's not because I'm a pro in Solid.js, Firebase or Youtube. In fact, I'm not. I'm still learning all this stuff while recording. It's rather about building something in public, sharing my approaches and collecting feedback from the community.

I see it as something like Video Open Source. Just the next step for my Open Source activities and blogging.

Watch my progress. Who knows where it can lead me in a few years.

The most underestimated freelance habit

Konstantin Komelin — Thu, 28 Sep 2023 06:03:25 +0000

So what is it? It's simple - always trying to exceed the expectations. But if it's so simple, why don't all freelancers have this habit?

Most freelancers underestimate the effort required

It's especially typical for large projects and for junior-to-middle freelancers whose experience is somewhat limited.

I solve the large project problem by splitting the project into a few milestones and estimating the first milestone only, or suggesting hourly payments.

The lack of experience is usually solved by multiplying to a risk factor. Let's say, if you have no experience in the area, multiply your estimated time to 2. If you have 1-3 years of experience, multiply to 1.3.

Some people are naturally greedy

Greedy people don't care about investing some time into developing long-term relationships with their clients. That's a huge mistake because clients can come for a quick one-time project and stay for years if they like you, and on top of that they recommend you to their friends.

Some freelancers don't care about their reputation enough

Not keeping promises is totally Okay for some freelancers. They feel that there is a demand for them in the market, so they think they can afford delivering late or not delivering at all.

You know what, it won't last long. More and more people are coming to the market from other industries and they are hungry for work, while AI is destroying some jobs completely. So it's your choice - develop your reputation now and stay in the market or disappear.

My formula is to deliver 110% quicker than expected and give 110% more value. Are you with me, my friends?

// Photo by Cytonn Photography on Unsplash

What I Learned While Building My First Web3 Project

Konstantin Komelin — Mon, 12 Dec 2022 11:18:30 +0000

I started building MarrySign, a crypto-marriage app, during the Chainlink Hackathon Fall 2022 because I wanted to give any couple regardless of their gender, location or any other factors, a chance to register their union quickly and transparently from the comfort of their homes. Now after the hackathon, I continue working on the project in my spare time.

Since it's the first web3 project I'm building, I'd like to share my learnings.

What is Blockchain

I wish I could explain it briefly ;) But let me try to use familiar examples for that...

Blockchain is a distributed database with an acknowledgement mechanism, like in MongoDB, and stored procedures, like in Postgres, directly connected to a payment gateway, like Stripe, but for Crypto.

For the Ethereum network, the “stored procedures” (functions) are grouped together into a “class” (contract). The contract code is written in the Solidity language which resembles a mixture of JS and Go.

Fix bugs in advance

If you once deployed your Solidity contract to the blockchain, you can't change its code. It means that if you find a bug in it, you can't deploy a hotfix. You will need to deploy an updated version to a new address leaving the old contract and user data intact. It adds some challenges, for example migration of user data from an old version of the contract to a new one. There are solutions for that but it's not one button click.

So the idea is to deploy good-quality code to production, well-tested and well-documented.

Taking that into account, I test my Solidity contract with the Hardhat framework, document it properly to generate human readable docs automatically with solidity-docgen. To format my Solidity code, I use solhint and solhint-plugin-prettier.

Gas fees

You pay fees (aka gas fees) for writing to the blockchain, but read data from the blockchain for free. However, it's not guaranteed that your read-only function will return results if it exceeds some network limits.

The Hardhat framework lets you estimate gas fees for running your functions. Not sure if it's 100% accurate but it helps identify heavy functions.

There are also solutions for gas-less payments. It's when the contract creator pays fees for their users through a special gas station, for example Ethereum Gas Station Network.

Staging networks

Since the price of a mistake is normally high on the blockchain, there are a few test networks which you can use to test your contract without paying gas fees on the Ethereum mainnet.

I use the Goerli Ethereum network. People don't like it for some issues but other options are not widely supported yet.

Web3 UX

The UX of some tools and services is not yet ideal, so more and more companies are focusing on web3 UI/UX. I think good UX is a competitive advantage today. I personally liked presentation by Rahat Chowdhury from the Polygon team with ideas on how to improve web3 UX.

Back yourself up with a withdraw() function

I heard stories about contract developers forgetting to implement a withdrawal function and having to lose their earned funds. So if you're going to collect fees from your users or receive any funds to your contract address, make sure you add a withdraw function right from the beginning.

Useful resources

Web3 and Hardhat starters:

Solidity libraries:

Video:

Chainlink Fall 2022 Hackathon Playlist

Communities, hackathons and accelerators

Looks like current crypto-winter doesn't slow down web3 progress because a lot is going on in the area actually.

There are growing Discord groups for almost every blockchain project.
There are many hackathons, dedicated to a blockchain protocol or network, that are happening now.
The Techstars accelerator partners up with big players in the area to help web3 and blockchain startups grow.

To sum up, developing for web3 has its challenges and opportunities, so when you get familiar with tools and services available and discover best practices, you can develop something really new, something disruptive.

I wish you best of luck with your current and future blockchain adventures! And if you like the idea of crypto-marriages, follow us on twitter or get crypto-married with us.

I originally wrote this post for my blog but after receiving good feedback decided to share with the dev.to community. Hope you guys like it.

The Uploadcare Image Loader for Next.js Has Been Released

Konstantin Komelin — Sat, 27 Nov 2021 14:32:13 +0000

First of all, what's Uploadcare? Uploadcare through their API provides file uploading, processing and delivery for web apps, and does it really well.

While working on a series of Next.js tutorials for Uploadcare blog (first, second), I thought people would benefit from integrating Uploadcare services into Next.js, so I offered my help with an Open Source integration.

As it turned out, the Uploadcare guys had already tried to add their image loader to the Next.js core but for some reason Next.js team stopped accepting new third-party loaders to the core, so the Uploadcare loader remained unused in a pull request on Github.

I started with the pull request but went much further. Here is what I did:

Extracted the loader code into a separate package
Refactored and optimized the code
Made it possible to configure the loader through environment variables (custom CDN domain, custom proxy domain, image transformation settings, etc.)
Developed the UploadcareImage component with the loader integrated
Created automated tests for the loader function and the Next.js component
Added a Github workflow for testing and linting the project
Added documentation for the project

Finally, Alex Grenishin from the Uploadcare team added ShipJs integration, improved auto-deployments and helped fix some issues.

You can test the project in action here and check out its code on Github @uploadcare/nextjs-loader. Feel free to suggest your improvements in the issue queue on Github.

And if you want to experiment with the Uploadcare file uploading widget for React, check out @uploadcare/react-widget.

Thanks to the Uploadcare team for their support and assistance.

HTTP Basic Auth for Next.js

Konstantin Komelin — Wed, 21 Apr 2021 05:23:07 +0000

You may need the HTTP basic authentication to protect your secrets/innovations when the app is not ready for production or when your normal authorization mechanism is not yet ready. Let's look at a few possible solutions for the problem in the Next.js context.

Solutions

1. Protect separate routes with nextjs-basic-auth

Install the package nextjs-basic-auth:

npm i nextjs-basic-auth

Create a utility file:

mkdir -p util && touch util/httpAuthCheck.js

And put the following code into it:

// util/httpAuthCheck.js
import initializeBasicAuth from 'nextjs-basic-auth'

const users = [
  { user: 'user', password: 'password' }
]

export default initializeBasicAuth({
  users: users
})

Now you can add the HTTP auth to any of your pages/routes, for example page/index.js.

Open page/index.js and put the following code right after the imports section:

// pages/index.js
import httpAuthCheck from '../util/httpAuthCheck'

export async function getServerSideProps(ctx) {
  const {req, res} = ctx

  await httpAuthCheck(req, res)

  return {
    props: {}
  }
}

To test it, run the app with npm run dev and open http://localhost:3000

Cons:

You have to enable the HTTP auth on per page/route basis.

2. (not working currently) Document-level check with nextjs-basic-auth-middleware

Install nextjs-basic-auth-middleware:

npm i nextjs-basic-auth-middleware

Now let's create pages/_document.js to override the default Document component.

touch ./pages/_document.js

Put the following code into it:

// pages/_document.js
import Document, { Html, Head, Main, NextScript } from 'next/document'
import basicAuthMiddleware from 'nextjs-basic-auth-middleware'

class MyDocument extends Document {
  static async getInitialProps(ctx) {
    const {req, res} = ctx
    await basicAuthMiddleware(req, res)

    const initialProps = await Document.getInitialProps(ctx)
    return { ...initialProps }
  }

  render() {
    return (
      <Html>
        <Head />
        <body>
          <Main />
          <NextScript />
        </body>
      </Html>
    )
  }
}

export default MyDocument

Then put your auth credentials into your .env file like this:

# .env
BASIC_AUTH_CREDENTIALS=user:password

To test it, run the app with npm run dev and open http://localhost:3000

Unfortunately, this solution causes the TypeError: Cannot read property 'url' of undefined because it doesn't properly handle the isomorphic nature of Next and may need some adaptation for the client-side rendering.

Cons:

Not working because of TypeError: Cannot read property 'url' of undefined.

3. Custom server with basic-auth

npm i basic-auth tsscmp

Please refer to the official Next documentation if you're not familiar with the custom server creation.

Create server.js file in the project root:

touch server.js

Put the following code into it:

// server.js
const { createServer } = require('http')
const { parse } = require('url')
const next = require('next')
const auth = require('basic-auth')
const compare = require('tsscmp')

const dev = process.env.NODE_ENV !== 'production'
const app = next({ dev })
const handle = app.getRequestHandler()

app.prepare().then(() => {
  createServer((req, res) => {

    const parsedUrl = parse(req.url, true)
    const credentials = auth(req)

    if (!credentials || !checkHttpAuth(credentials.name, credentials.pass)) {
      res.statusCode = 401
      res.setHeader('WWW-Authenticate', 'Basic realm="example"')
      res.end('Access denied')
    } else {
      handle(req, res, parsedUrl)
    }

  }).listen(3000, (err) => {
    if (err) throw err
    console.log('> Ready on http://localhost:3000')
  })
})

function checkHttpAuth (name, pass) {
  return compare(name, 'user') && compare(pass, 'password');
}

Finally, you need to adapt your package.json to run the custom server:

  "scripts": {
    "dev": "node server.js",
    "build": "next build",
    "start": "NODE_ENV=production node server.js"
  },

As usual, test it with npm run dev and open http://localhost:3000

Cons:

With the custom server approach, we will need to track changes in the built-in Next server code and apply them to our server manually with every Next update.

Possible improvements for all code fragments:

Extract helper functions to separate files, e.g. checkHttpAuth() function in the custom server solution.
Move the user credentials to environment variables.
Use TypeScript.

Conclusions

In this post, we have learned three ways to implement HTTP auth in Next.js and looked at two ways to extend a Next.js app, such as overriding the default Document component and creating a custom server.

At the moment, I personally stick with the custom server solution for HTTP auth because I need to protect all routes at once and because it worked for me from the first try.

The solutions I listed here are code-level ones but it's also possible to implement an Nginx proxy which would provide the HTTP auth layer. Please let me know if you're interested in the Nginx solution and I will add it to the list.

Originally published on my blog.

Node.js Certification: My Experience and Advice

Konstantin Komelin — Mon, 11 May 2020 18:54:39 +0000

In the beginning of the COVID-19 lockdown I made a decision to use the isolation for self-improvement and invest time in something future-proof, so I signed up for OpenJS Node.js Application Developer (JSNAD) certification.

It took me a few weeks and two attempts to pass the exam, and a couple of days ago I finally received my certificate. Now it's time to reflect on the preparation process and test itself.

About the exam

The OpenJS Node.js Application Developer certification exam is not a dry theoretical test. Not at all, it's a performance based test consisting of a few coding assignments which you solve in a remote environment using one of the available IDEs (VSCode or WebStorm).

You're given two hours, IDE and terminal to get the job done. You can only use Node and JS docs during the exam.

Preparation

I've reviewed Node.js 10 documentation. Yes, correct, the certification is for Node 10 (at the moment of writing).
I've completed learnyounode and stream-adventure free interactive courses.
I've watched the first part of the Ilya Kantor's free screencast in Russian.
I've read and reproduced code examples from the following chapters of Node Cookbook:
- Ch 1: Debugging process
- Ch 2: Writing Modules
- Ch 3: Coordinating I/O
- Ch 4: Using Streams
- Ch 9: Optimizing Performance

I was so impressed by the Node streams that I even wrote about them.

First attempt

9 in the morning. Said Hi to my exam proctor through their chat. Showed my ID, desk and room to the proctor. Forgot to close thousands of tabs in Chrome. Experienced screen sharing issue. The proctor motivated to close the tabs. It fixed the issue.

Was solving tasks one by one. Enjoyed the problems and process.

Not enough time.

Result: 62. Passing score: 68.

Second attempt

One retake was free, so I happily used the second chance.

To prepare for the retake, I reviewed all the topics I was not confident about during the first attempt. During the second attempt, I tried to manage my time better and avoid the same organizational mistakes, such as chaotically switching between windows, working on one task for too long, double-checking whether I saved my solution or not, etc.

That worked. In 36 hours, I received my PDF certificate.

Result 76. Passing score: 68.

Advice for future test takers

Make sure you can comprehend written English to follow proctor's instructions.
Dedicate some time to learn candidate resources.
Learn cd and clear Linux commands. You will probably need them to effectively work with terminal.
Make sure you know where to find Node 10 docs.
Practice before the exam. Seriously, try to solve foundational Node problems, such as writing to a file, executing a command in a child process, dealing with promises, getting system info, debugging, etc. Focus on fundamentals rather than on a particular framework or database access layer.
On exam day, make sure you don't have anyone else in your room and anything on your desk except your ID. Move away all electronic devices to not cause redundant questions from the proctor.
Close all apps (except Chrome) which are not necessary for normal functioning of your OS.
Close all browser windows/tabs (except one).
When you first open VSCode, configure it. Turn on auto save (File -> Auto Save) and enable word wrap (View -> Toggle Word Wrap). Believe me, it will save your time.
Use VSCode integrated terminal (Terminal -> New Terminal) to avoid switching between windows.
Every task folder has a README file with the task description. Don't waste your time on reading it in the browser.
Control your time and try not to spend too much time on a single task. Better come back to it later if some time is left.

To sum up

The Node.js certification was not my first technical certification, so I can compare. The first one was Zend PHP Certification back in 2013. That exam had mostly theoretical questions. However, it gave me a big picture of the language and deepened my knowledge. Besides, the PHP certificate favorably distinguished my freelance profile from myriads of others, which helped with job search.

Let's see what opportunities Node.js certificate can bring for my future career. Even though I'm 100% sure the certification has made me a better developer, I still have a lot of things to learn, and I'm not going to stop evolving.