Forem: Sudo BLAZE

Finding best performant stack so you don't have to.

Sudo BLAZE — Mon, 13 Jan 2025 22:01:00 +0000

Recently while thinking about indie hacking I went on a tangent, researching the topic on how to improve performance. It's usually a long shot to think about performance early on development stage while product does not have proven usage. But it's a dream come true when the problem your app begin to have is a problem of performance. So this curiosity lead me to https://www.youtube.com/@AntonPutra channel that have several performance tests done under heavy load. A lot of his tests showcases that actually while some solutions might have initial higher latency (long response time) under almost no load, the same solutions might end up more performant under heavy load (like DDoS of 80K requests per second!).

So here I would like to make a comparison and podium under several categories on which option in each category is most performant. Keep in mind, that very often it's a game of trade-offs, and taking only performance in mind while building your app you might end up with unmaintainable app. Usually going with something you know will actually help you move faster, and then rewriting bits and pieces to more performant option is a way to go. Anyway, without further ado, let's get into it:

Top load balancers

Recently the hierarchy has been violated with release of Pingora by Cloudflare. So first spot might surprise you.

Pingora by Cloudflare
Nginx
Caddy
Traefik

While Traefik is one I used the longest, Nginx was my bread and butter for the longest. Even though Pingora is the new hot stuff around the block, I would still wait a little until it's fairly established.

Top backend languages

This one might be most opinionated, because a lot of developers get attached and emotional about their favorite language. I'm language agnostic to be honest (I have my own opinions and preferences of course), but I'm looking purely on how much load and latency each can produce in typical backend stack: framework, CRUD and Database. That's why I like Anton's analysis, because it tests both static content load, and CRUD ops load as well. And based on that we have:

ZIG (+ ZZZ as potentially best framework)
RUST (actix, however axium and rocket not very significantly behind)
GO (stdlib / fasthttp, depending on case)
Java + Quarkus + GraalVM
c# dot.net
Ruby (no Rails, Rails actually slows down Ruby to fall behind JS)
JS = Bun > Deno > Node.js
Python (FastApi)

The key takeaway for me is that a lot of those technologies got very close to each other in terms of performance. Throughput and latency really starts to fall apart after node.js. Another one is that framework overhead can actually be one of the biggest bottlenecks in terms of performance.

I would group these into 3 groups of solutions: Top Performers (Zig, Rust), High Performing Enterprise (GO, Java Native, c#, Ruby Native, Node on Bun), Framework Performance (Rails, Fastapi, Django, Spring etc.).
If we are talking about frameworks, let me cover only two backend languages in that regard.

Top Java Frameworks

The list is pretty short in that terms:

Quarkus
Micronaut
Spring

This is done by my own testing on docker containers in localhost. Unfortunately I don't have funds to spin up AWS Infra like Anton, so I'm unable to test heavy loads on infra, but I have my lab micro PC, that I can imitate that somehow over local network. If you are interested in that, let me know in the comments.

Top JS Backend Frameworks

Encore (Far up front)
Elysia (Bun's favorite)
Hono
Fastify

Recent Node.js backend frameworks basically managed to drastically improve performance, effectively closing the gap between Node backend and GO backend in terms of performance. No wonder because Encore is basically Typescript run on top of Rust runtime. While Encore claims to be 50% faster than Elysia, Elysia by itself is built for Bun, which is actually rewritten in ZIG. So while technically you are writing Typescript, both those frameworks are leveraging capabilities of two most performant new languages out there.

Top JS Frontend Frameworks

Astro
Svelte
Remix
Gatsby
Next.js

No surprise for me here. I've been in love in Astro since the beginning. First truly meta framework that you can mix and match with others. This podium is based on Page Vitals and Lighthouse metrics, because we are talking mainly about static content. In simple terms it refers to: how fast page loads and how much overhead framework itself adds. And while Astro itself feels closer to Next.js in terms of usability and convenience, static build is actually one of the smallest. Server build however might not be up to par with top performant backend frameworks, unless it is running on Bun, so keep that in mind.

Top Databases

SQLite
MongoDB
Postgres
MariaDB
MySQL

First place might surprise you. I was surprised myself, but actually it's obvious. Think about it. All other solutions work over network protocol. SQLite directly saves to disk drive. It's only bottleneck is disk space, and disk speed. And recently libsqlite (thanks to turso) pushed it even further. To be honest I was more surprised that MongoDB outperforms Postgres in terms on how much more inserts and updates are more efficient. Partially it's due to the fact, that by default, Mongo flushes the state every 100ms, while Postgres saves right away. Either way top 3 will always be a solid choice.

Top caching / Key-value store

Memcached
Redis (better Throughput) / Dragonfly (better Latency)

Memcached is clear winner by a landslide. Of course any solution at this point will improve performance, but memcached won't have a rival for very long time.

Conclusion

While being sidetracked from my other projects, this research gave me something to think about when choosing stack for my next application.
I think this is not a total revelation for those who work long enough in the industry, but still this results shows how convenience is often trade-off for performance. You have to pick your poison. In 1 year time, or even 6 months, this might be outdated, given how Zig and Rust moved things forward in terms of performance across many solutions. For me, it's a question whether I should consider dipping my fingers in Rust or Zig, or should I settle with encore as a good enough alternative. On the other hand, Mongo is database I know, but never considered for production, and now I know I shouldn't disregard it that fast.

The point is that by tweaking some decisions early on, you might avoid a complete rewrite of your application as soon as it takes off.

So I created Linktree alternative...

Sudo BLAZE — Fri, 13 Dec 2024 16:51:51 +0000

You might be asking why I decided to do something that is completely free already and was recycled over and over again. Well the reason is I stumbled upon peculiar problem.

Basically I wanted to host my link list myself, and existing solutions were not satisfactory enough for me. Either because of how routing behaved, or were too bloated (really? laravel for simple page with links? I'm looking at you linkstack).

Basically I needed on that will fit my docker stack and is easy to configure with traefik.

And I decided to make one in Astro. Easy, light, no backend, just frontend, quick configuration with yaml. That was my goal.

Issue #1

I didn't want to spend too much time on styling. Sooo... tailwing - check, daisyui, check, ChatGPT plis spit out template in astro... I said astro, not React... I said tailwind, not bootstrap... FFFFFFFFFF... Fine, I'll do it myself too.

Two hours later and three different skins to choose from, now we can put some data.

Issue #2

Ok, after some googling seems like we can import yaml as is to our script directly using rollup-yaml plugin. That would be actually nice, but the problem is, yaml is packed together with application, which it does not give us much control over it's contents.

Finally I ended up loading it with fetch and js-yaml from "public".

Issue #3

At this point I could already package my application, but one more thing I have to consider was base image for my container. I can go either with nginx, but then my yaml file have to be loaded and parsed on the client.
However, if I go Astro SSR route and run it with node, the file can be loaded by server in the background, and no requests for config file is made on client side. Downside however is that I have to install all server dependencies on server side during image creation.

I went with node:alpine. Less processing on client side = better user experience.

Now I can hook up my list of links (don't confuse with linked list), and attach a volume to a file with my configuration without any UI, backend, server, database or any other dependency whatsoever.

All of that took me maybe 4-5 hrs so I decided to simply open-source it.
Feel free to check it out, use it, fork it, or whatever. Contributions welcome.

https://github.com/TheDigitalBlaze/linkspace

React is total brainrot! 🤬

Sudo BLAZE — Sat, 21 Sep 2024 17:31:10 +0000

Some time ago I had opportunity to look into the code of AirBnb frontend, written in React... and it was nightmare. I have PTSD to this day. It was huge monorepo project with ton of components, embedded in one another, without clear logic or structure behind them. Not even clear separation between presenters and containers. I mean, there were some attempts to separate logic from presentation, however, it was not clear from project's structure. There were hundreds of components all in one folder.

To be completely honest with you - I never liked React, so I might biased. But let's dive deeper on why is that in the first place.

The beauty and the beast

Even though I hate it, I can see the appeal. You know a little bit of html, and you know little bit of javascript - you are good to go. It is great rendering engine (!) if you want to move fast. And with the right use case and right architecture it can be very easy to manage, and iterate upon. Basically if your programming experience is purely frontend, little bit of HTML, CSS and JS, than React simply builds upon what you already know.

import React from 'react';

const HelloWorld = () => {
  return (
    <div className="flex flex-col items-center justify-center min-h-screen bg-gray-100">
      <h1 className="text-4xl font-bold text-blue-600 mb-4">Hello, World!</h1>
      <p className="text-lg text-gray-700">Welcome to your React application.</p>
    </div>
  );
};

export default HelloWorld;

Problem comes with complexity. Every project large enough comes through complexity hell. The true test of great technology comes with ease of introduction to new users. This applies both to user experience (UX), and developer experience.

The main problem with React though, is that it does not enforce good architecture from beginning. There is no clear separation of concerns, and logic is mixed with presentation.
I can already hear voices: "there is container/presenter pattern! there is redux/jotai/mobx etc!"
Yes, there is, but it's not enforced standard. It's just pieces of libraries, spread apart without clear implementation guidelines. And unless you end up in greenfield project, you are going to regret it at some point. Fortunately someone had an idea how to rectify that.

The Next(js) React

Clearly Vercel had great idea with it's meta-framework because it solves majority of problems with react. If Express and React had a baby, it would be Next.js. It has folder-based routing, clear project structure, server side rendering and possibility to create server endpoints.

Wait... folder-based routing and server endpoints? I have flashbacks...

<?php
include('pages/'.$_GET['route'].'.php');
?>

Oh.... Now it all makes sense. No wonder server-side react have the same issues: exposing secrets, unused endpoints.
But let's be honest: next.js was created to promote vercel, because were all these noob saas js developers will go with their app most likely?
At lest PHP since version 7 can be called high-level, especially when using with Laravel or Symfony. And PHP is not trying to take over native apps.

React Native

Like taking over the web was not enough. With electron becoming so bloated, and cross-platform mobile apps is basically "killing two stones with one bird" we definitely needed JS solution for that. The good thing is, that any company now can slap Frontend Dev to this task, order them to make mobile app, and call it a day. Great idea on paper. Another nightmare fuel to add if for some reason your mobile app and web app is the same codebase. Oh wait, code base diverges? Let's put couple of if statements and call it a day. It's nice to talk about success stories like "X - formerly Twitter" (we know!) or several Microsoft use cases (I don't remember which ones though tbh). But, boy oh boy, I bet those developers are doing speedrun to burnout.

React Ecosystem

Did you know you can also compose emails and create pdf's using react? Technically you can slap react on your cli as well! Why use go, rust, or even bash when you can use react!

Every language, framework or library becomes trashy if you use it long enough. But let's be honest do you really need react in cli? Ok, I admit, react on discord is pretty neat, and that is something I can see myself using for such case.

The reason for that is that discord bot, even fairly feature-full wouldn't come close to behemoth of a system you can expect in big tech companies. Anything bigger then that, with multiple people in the team and couple of years maintenance cycle, and react goes out of window, unless you start using microfrontends from the beginning and chunking the systems into smaller pieces. But I rarely see that done early on, and later on becomes too late.

What's the alternative?

I can hear react bros sight audibly when I mention Angular. You knew where this is going. I can even hear accusations in the style of "oh you are backend dev, obviously you gonna choose Angular". Believe it or not, I started on frontend, but I dabbled my hands in backend as well. And I've been fullstack dev for pretty long time already. Now think a bit about it - why is that Angular is so often selected by backend developers? Why is that Java with Spring Boot is still the default on backend corpo world, even when there are newer and faster technologies?

The answer is simple - reliability and predictability. Most backend developers experienced maintaining existing codebase for a long time. And jumping into existing project where you don't need to worry about technology, only the business rules, is way better.
Angular is a framework compared to React. Pure web (browser) technologies were never designed as software development tool to begin with. That's why Angular adopts a lot of solutions that where proven in traditional application development.
It imposes certain standard on developer from the start. Even without conscious architecture and pattern selection, you can be almost sure, that most logic will land in the services, and most rendering will happen in components. Performance-wise it might not be the best option but on the long run? As maintainer you will be frustrated significantly less so then in React. Because React codebase is maintained differently in every company. And under certain threshold it does not matter if app is responsive in 400ms or 200ms. If that matters to you so much... what the hell you are doing in JS?
Did you know that a lot of companies that are established on the market for quite a long time compared to most big tech giants actually prefer Angular? Companies that have more than 20-30 years of history will stick with Java and Angular instead of React or Next.js. Those companies are less volatile to market changes, and prone to lay offs, if you value your stability, don't pursue FAANG or any startup that went big in last 10 years. Maybe with exception to fintech... fintech is crazy town, regardless of how much they are on the market.

Now let me give you my personal recommendations.

Web

Angular - Obviously. Keep in mind, that Angular didn't sit on his ass while others where innovating. Currently modules are not mandatory, components can be standalone. Also you can actually get rid of zone.js and polyfills completely, and use signals instead! That speeds up application considerably.

Meta-framework

Analog.js - If Next.js and Angular SSR had a baby (there is no angular universal anymore). It still uses Angular under the hood, so migration should not be that hard. I think in general it is even better then native SSR, because you don't have to use afterRender and afterNextRender (I might be wrong here, so correct me if I am).

Backend framework

Nest.js - You need backend only approach in Node, and you like Angular / Spring Boot? Well, fret not, Nest.js comes with help. One of the reasons why Angular is so popular among backend developers are "@" annotations that make cross-cutting concerns like dependency injection easy. Nest.js just much like Spring enables such annotations like @Controller in your code. Keep in mind however, because it's backend framework, it does not adopt angular.

Mobile Development

Here we have actually two options, one obvious: Flutter; and one not so obvious: PWABuilder.
PWABuilder - great option if you have website with PWA enabled in Angular or Analog.js. With this tool you can quickly turn your PWA App into Native app, that you can compile and put on Google Play or Apple App Store. But keep in mind it has some limitations.
Flutter - while not much of a standard angular approach, it's way easier to grasp and manage then React Native app. It has little bit less smooth animations than React Native, but overall performance is much better. Great thing about it is that it comes with a lot of ready-to-use Widgets based on Native Apple or Android UI, that you can further customize.

Conclusion

I don't dismiss React altogether. It has it's use cases and overall contribution of this technology to web development is huge. I don't deny that. There is a place for everything. However it has a feature called "brainrot native" that causes average frontend developer to design poorly. And because it's relatively very young technology (official React launch was 2013, Angular.js was 2010) not a lot of devs with years of experience came to it. Nobody coming from jQuery was thinking about big frontend websites outside maybe of Google! Think about it. Who at the time was doing massive frontend websites? Google. Who come up with angular.js? Google. In the meantime 90% of Facebook was running on PHP. That's why they come up with react, because they needed small pieces of website updated with small components, not a whole web app run in the browser. And the architecture of both reflect that.
So take my advice, and go with Angular if you are going to make massive web application that is going to be maintained over the course of several years. Or make a proper f*cking architecture design for your application if you are going with React, so others don't go bald maintaining it.

Are you burning your money?

Sudo BLAZE — Fri, 21 Jun 2024 18:33:41 +0000

Recently I've became very spending conscientious. Partially because there are more and more services that adapt subscription based model, and partially because I became more and more aware how much every possible industry giants try to milk their customers as much as possible. I've became quite resentful towards those practices, and recent news about Adobe TOS and anti-consumer practices just pushed that resentment even further.

On top of that I do tend to forget, that there are some subscriptions I subscribed to trial and forgot to cancel. Sometimes I want to just check what are recurring payments that automatically draw from my account, and where I would like to cut costs.

Because of that initially I created a script that will look into my financial raport and recognize those payments automatically.

You can find the source code here: https://github.com/sudo-sein/subscription-finder

However, at the end of the day, I thought that I would go a bit further, and create service that will create such reports via webapp. So, If you guys want to check it out!

Subscription Finder

If application gain enough traction and interest, I might extend it's functionality.

Self-hosted public site - safe and cheap.

Sudo BLAZE — Mon, 17 Jun 2024 12:06:00 +0000

In my first post in the series there where a lot of people that were concerned about exposing local network to public internet, or actually might have a problem with doing that due to ISP limitations like dynamic IP or reverse lookup. That might not be a problem if you order a static IP from your ISP, but not all ISPs make it easy or cheap. There are also several reasons you might want to avoid that.

Current setup

In my initial post I suggested using Intel NUC to host every tool in the closed off local network that only you have access too. Basically you can install server version of Ubuntu, setup ssh access, install docker, and run any tool you need on that docker (I will post extensive guide in the future). I'm using also Portainer and Traefik as my main containers to actually bind any local address to a new service, so I don't have to jump on different ports, depending on what I want. Now your local address becomes something like portainer.home.local.

Moving to public

Now, this type of routing can be incorporated in public environment if you had domain pointing to your static IP, port-forwarded 80 and 443 to your intel NUC from router, and let Traefik take over routing over subdomains. That's classic way of routing traffic. In fact, that's not so different from spinning up EC2 with docker and doing that yourself on external network. Definitely it's safer this way.

But we are going the economic way, and actually the best of both worlds: tunneling. That's right, we will make a bridge between the domain and our container. This way traffic comes from indirect source instead of directly through our router and local network. You can even set up docker network so it's closed off from the rest of your internal network.

There are several tools that allows tunneling like ngrok or tunnelmole, however, best option is actually Cloudflare. It's free for small amounts of traffic, and works best in docker environment.

Step 1. Get the domain

Honestly, you can't go public without domain, if you don't have one, you have to grab one. Keep in mind that you need to point DNS towards Cloudflare nameservers so you can't use one that already is occupied by something else. Best services that provide domains for me are:

GoDaddy - I've been using them for years. I had good experience with their customer service, and most of my domains sits there.
NameCheap - Name says it all. Solid alternative, some domains comes cheaper then GoDaddy, some don't. But one of the main benefit is - they have .xyz domains for $1 a year!

Step 2. Set up a domain on cloudflare.

Now let's create account on cloudflare and add our domain. Go to websites and add new domain.

After you provide domain you already own, you will be asked to subscribe... don't worry, there is free tier, scroll down:

Do the quick domain scan, click on next, until you get to activation page:

Scroll down until you see nameservers:

Set up DNS records to point to your cloudflare nameservers (don't copy from me, these can be different for you)

Now, you need to wait until domain propagates correctly. Depending on where you have your own DNS servers set up, it can take between 5 minutes up to 24 hours.

Step 3: Tunnel your traffic.

Alright, we have cloudflare account and domain set and ready. Let's setup our proxy bridge. Go to "Zero Trust" section:

Now expand "Networks" section and select "Tunnels":

Now click on "Create a tunnel" and on the next screen select "Cloudflared". Name your tunnel on the next screen.

Your tunnel is created, now you have to install it in your docker. But before we do that, we need to setup our network.

$ docker network create -d bridge public_services
$ docker run --network=public_services cloudflare/cloudflared:latest tunnel --no-autoupdate run --token <your-token>
$ docker run --name hello-world --network=public_services -d -p 80:80 strm/helloworld-http
$ docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' hello-world
$ # 172.17.0.3

This way your tunnel will have access only to services that run on the same network. Last command is what you need to get internal networks container ip. We will need that for tunneling.

Let's get back to cloudflare and let's make new routes. Edit your tunnel and go to "Private Network"

Here set up which networks should be visible in your tunnel. Set up CIDR accordingly to your container's IP.

Now go to "Public Hostname" tab, and click "Add a public hostname"

Here we set up our routing to a specific domain. We can run multiple services this way, each with it's own specific subdomain, or we can set up our personal website. The best thing is - there are no limitations to technology you want to use, as long as it's dockerized.

Conclusion

Setting up a personal domain and hosting your own services can be a daunting task, especially if you're concerned about security and exposing your local network to the public internet. With docker and Cloudflare however it can be actually quite rewarding and fairly safe. It is good extension of your homelab if you have one, without a need to resort to traditional hosting.

With this setup, you can host a variety of services, from personal websites to custom applications, all while maintaining a secure and isolated environment. The possibilities are endless, and the best part is that you have complete control over your data and services.

So, if you've been hesitant to explore the world of self-hosting due to security concerns or technical challenges, give this method a try. You might be surprised at how easy and rewarding it can be to have your own little corner of the internet, all while keeping your local network safe and sound.

Do you do your homework before interview?

Sudo BLAZE — Sun, 16 Jun 2024 16:06:00 +0000

Do you ever feel like doing the homework before every interview? Do you feel that there is some kind of test you have to pass and not only gain enough points but also outscore other candidates? But when you actually get the job, it has nothing to do with questions, requirements and responsibilities posted in the listing.

I think this is ridiculous. Recruitment process became detached from reality for a long time, and I've seen only few companies that actually make recruiting right. I have over 15 years of experience in the field, I've been on many recruiting processes, and I did some recruiting myself as well. I'm not saying my approach is bad, but we have to address elephant in the room.

The BAD

Let's start with how most interviews go. You show up. You have a ton of questions in regards to technical knowledge about tech that was listed in the job listing. But let's be hones, recruiters have a standard list of those questions. And the number of questions is limited to a degree, so most of them you can find online easily (yeah, recruiters take that questions from online sources as well). So, if you are determined you can just study answers for the questions, without really understanding the topic! In fact, there are many people that do so!

The problem starts to be visible when ability to answer questions, does not corelate with ability to solve problems in the job environment. Or in worst case scenario - it does, but the temper does not fit the team, and it ends up lowering efficiency of the whole team. Gaining 1 team member ends up loosing 200% productivity.

The Ugly

And the productivity is actually on the elitist approach to recruiting.
This is "the top 1%" of programmers. You either have to answer all questions perfectly and beyond, answer leetcode problems, take test on the coding exercise platforms within 2h timeframe, or make a full blown solution within 24h window.
This is not a problem with recruitment process. It's a problem with company culture. The grind mindset. You sacrifice everything for that company, if you don't we don't want you. Those type of companies expect ultimate loyalty from you, but don't return any loyalty back to you.
Let's be honest - companies are loyal as long as it benefits them, but no company is nowadays loyal to their employees, so you don't have any obligation to be loyal back.
Anyway, for the sake of your mental health - steer away from that type recruiting processes.

The Good

Now, the best recruiting processes are those who don't focus on the knowledge, but concepts and problem solving skills. Intricacies of a specific tech does not matter unless there are conceptual mindset behind it. Mindset and thinking process are the money saving skills. And heads up recruiters - any hard technical knowledge can be bridged very quickly with googling skills, or nowadays even prompting skills.
So prohibiting googling during interview is one of the stupidest rules ever. Why? Because the way someone is looking for information is one of the most important skills to have. People do that on the job anyway, and during interview you are pretending like it does not happen.
And one more aspect to consider - attitude and company culture fitness. Basically, check for soft skills like self-presentation, honesty, teamwork capabilities, communication. How to do that? By asking questions like: "what would you do, if you realize there is a bug on production", or "how would you handle conflict, if you have disagreement about implementation, and you are sure you represent better solution". But you have to be very sensitive to bullshit answers.

My protocol

I'm assuming that at this point you want to recruit some talent. You might have considered other approaches, you might have your own recruiting recipe, however you might think there is some room for improvement. Certainly, there is some room for that in my recruiting protocol - it's not bulletproof. But I think it's one that I like the most and whenever I'm being recruited in similar way, my green lights goes off. I suddenly know, that people on the other side actually know how to do it properly. So here's my process:

Introduction (~10 minutes)
Brief technical check (~10-20 minutes)
Problem solving check (~15 minutes)
Soft skills check and debrief (~15 minutes)

Of course if you have more time, or multiple step recruiting process, you can extend it, but apart from introduction, all the parts should take roughly same amount of time. Let me explain each part briefly.

Introduction

Standard who am I, who are you, why you left. Nothing outside of typical formula. You can explain the tech stack and team composition as well.

Technical Check

Yeah, I mentioned that in "the bad" section, that you can easily learn answer for these questions, but even so - you still need to check with simple questions, if that resume you got has anything to do with reality. But don't be tempted with very niche technical questions that you don't actually use in production. A datatype questions or common libraries are enough to see if someone is using the technology or not. If you are asking about something technical that you do not use on a daily basis, you cannot realistically expect an answer from someone else without being a jerk.

Problem Solving Check

This is the section, where you can ask, how someone would solve some technical issue. How would you design an API, or solution architecture, or consistency across multiple databases. Those questions ask about concepts and patterns, and does not focus on any specific technology. Of course, depending on skill level of candidate you can scale them up and down. You can ask a junior or mid about naming and linting problems, or clean code. Important thing is, that you have to check not the answer itself but how they got to the answer. Answer itself can be wrong (!) as long, as their thinking process is solid, and they are open for suggestions.

Soft Skills Check

That openness to suggestions is also a soft skill check. This is important, if not most important skill check. Emotional maturity can make or break your team. You are not hiring a freelancer, but someone who will be part of the social group. In group environment you need to keep in mind that there are couple situations where people have to know how to manage their emotions. And no, I don't mean they have to hide them by that.
What you have to have in mind is: how they handle constructive critique and suggestions, ideas rejection, giving feedback themselves, other people's feelings and social outings. This is emotional intelligence. It's part of the job, even though almost every company out there does not recognize it or cultivate it. And assuming yours does not have a program to improve emotional awareness of your employees, you have to look for those who have emotional self-regulation mechanism by themselves. What it means is:

candidate can take critique into account, does not reject it or does not shut down immediately
candidate can propose ideas and solutions in clear and easy to understand way
candidate knows how to communicate during conflict, and does not escalate
candidate is eager to participate in social outing of the team Based on that "metrics" you can come up with questions or provoke situation to check against it in non obvious way. Asking some of the questions directly can also help, but you are risking getting logical answer, not the actual behavior.

Conclusion

Recruitment process might be one of the most annoying processes in our line of work. Compared to other industries, software engineers and IT change jobs way more often. Not surprising, considering that switching jobs is one of the best ways to get a pay rise in a industry that wage changes happen also more often than any other industry. However, sometimes even though it is mostly intellectual and creative work, recruiters/companies seems to treat us like construction workers. But maybe there's better way? I would recommend anyone who participate in the recruitment process, to think this through a little bit more. If you have your own thoughts and suggestions, I'm happy to hear them in the comments.

Self-hosting: What's the point of homelab?

Sudo BLAZE — Wed, 05 Jun 2024 19:27:21 +0000

My previous post on Why You Should Self-Host Everything blow up to my surprise. I'm positively encouraged to write more. However, I realized that not everyone quite realized what was the purpose of self-hosting in that instance! And I wrote the article under the assumption that it's obvious! Well then, let me explain.

Assumption #1: Public facing service

Self-hosted homelab was never intended to be accessible from the web. By design it is available for internal network only. It's for you. For your own personal projects. For hacking, pentesting, trying new technologies, learning. You can spin up redis, kafka, postgres with ease and learn integration with it in your home environment. You can setup rss reader, media server, password vault, etc. in your home network without access from outside world. This is the benefit of self-hosting because you can create your own tools that only you have access to.

Assumption #2: Why not on your working PC?

For some use cases - of course, Docker Desktop is enough. Especially in case of local development environment. But the downside is that it becomes unavailable as soon as your main device is down. What if you want to have an access to your tools while your main pc is down? What if there are background jobs you want to run, or maybe you have notification bot running? The main benefit if micro-pc is that it has low power consumption of around 30 watt-hours per hour. For comparison fully-fledged stationary PC consumes between about 100-150 watt-hours per hour on light work, and laptops around 50 watt-hours per hour. That's up to 5 times difference! And that's not accounting for PC monitor!
So yeah - for something that can potentially work 24/7, it's definitely more cost-effective.

Assumption #3: Private access

Now, let's say, you are out of home, maybe you were sent by company to a conference, or to work in different hub for a while. How do you set up remote access? Didn't I mentioned that they are not public facing services? Well, I did. But you don't have to expose your services to the web, to actually use them remotely. Please welcome VPN - the actual intended way of using them (unlike what "private vpn" services promote).
There are two solutions for VPN, and two ways to set them up. Some routers have VPN server built in, like Asus:

This is actually screenshot from custom built firmware for Asus Router

In case of cheaper ones, you can actually setup your VPN via docker container, and simply port-forward from router to your VPN instance.

And you can choose between OpenVPN and Wireguard, both are solid options, however Wireguard a much newer and faster than OpenVPN.

But doesn't that mean you are exposing open port to the world? Yeah, but there are ways to mitigate that:

use fail2ban, to ban anyone on #ish attempt that fails.
use non standard port and udp-only approach, you can avoid noobs and script kiddies this way
use tunneling - this way you are not exposing anything, but connect via proxy to actually connect to your network. You can achieve that by yourself setting up reverse-proxy vpn on vps (now your network is just client with pass-through) or using service like Twingate

I might cover all of that in the future, but at least I wanted to leave you something to go on on yourself.

Assumption #4: Small number of services

Now, one of the arguments was - if you have small number of containers, you can use raspberry pi - and that's correct, but in that case wouldn't it be better to just run it on your machine? I'm talking about running more then 10-15 containers constantly. Right now, my personal server is running 27 services and counting! I'm literally replacing a lot of subscription-based productivity services with my own - all in my network.
That's what most companies do, when they ask you to connect to work VPN, most of their internal network is self hosted, and available for employees only.
Of course, I'm using raspberry pi in my own setup, but only as dns server and network intrusion detection system (nids). My NUC however, is running home assistant, wiki / notes, rss reader, media server, meal planner, automation tool, searx, password vault and task/project tracker, among others. And the best thing is - because it's all on docker, I'm not even using that much resources I would with VPS or VM. Here's proof:

CPU utilization at ~15%
RAM utilization at ~32%
SSD utilization at ~10%

And this is number of apps exposed to my network. It does not count for dependencies. So as you can see, you don't need strong CPU for something like that. Simple i3 2-core 4-thread CPU is enough. What you need is RAM. I have 32 GB of DDR4, and I'm using only 1/3 of it, but as my infrastructure grows I might need an upgrade... maybe... or maybe not.
It all depends on use case.

Assumption #5: Why not cloud? Why not RACK?

Now you might ask, why not spin up AWS EC2 if CPU is not that demanding? Well let's keep in mind, that what containers uses the most is RAM. For my current setup I would need about 12-16 GB RAM instance. Currently only R6G Large fulfill that demands which equals to $80 monthly which is $960 yearly. For that amount of money you can buy both NUC and NAS which will collectively exceed what AWS has to offer and stay with you for years!

RACK on the other hand is really fun project to have, but it's way more expensive one, takes up a lot more space, and consumes more energy. So if you are about cost-cutting, that's not the most cost-effective option.

Practical use cases

Now that we tackled most of the assumptions, let's discuss who actually benefits such setup.

Use Case #1: Startups and small business

Having a small on-premise pc, that runs business infrastructure is a blessing, granted you have at least one person that know how to maintain it. It means that you can set up your infrastructure according to your employees needs. There are a ton of tools that helps running a business and doesn't cost a dime if you host them yourself, starting on LDAP, and ending with CRM.

Use Case #2: Network Nerds

I don't even have to mention it in this case right? Chances are you already have one. Don't confuse with "networking" during IT conference.
You own a homelab to play with infra. You create virtual networks, set up credentials, firewalls and policies. You are basically refining your skills as IT guy, because you like it.

Use Case #3: Penetration Testers

Homelab is great environment to actually deploy vulnerable apps and OS, to try and hack into them. Yeah sure, there are sites like hackthebox that provide that experience, but if you want to see ransomeware running wild, VM or container are safe environment for that.

Use Case #4: DevSecOps

Now, I don't have to explain docker containers for you. But kubernetes on the other hand, is a different story, and with homelab you can test deployment script for cheap. And I know, probably like some of you I tested kubernetes on VM stack, and was not impressed. Well, let me tell you that there is such thing like kubernetes in docker (kind), and it runs 100x better on vm-less machine than vm stack!

Use Case #5: Cloud Native Developers

Basically same category as DevSecOps. You might put Openstack or Rancher on top of your infra. Or you might add Gitlab to keep your repos private with additional CI/CD pipeline to deploy locally. It makes total sense if you want your apps available internally. After all it's part of the fun.

Use Case #6: Automation, Media Server, Documents and News Hosting.

And the final case is almost simply "others". You can set up Home Assistant, N8N, Plex/Jellyfin, Paperless. All of that are convenience software. It's just helps to organize your life better and automate a bunch of staff. It also works great with smart homes, when you have local network enabled devices, like lights, air conditioning, blinders. You don't need fancy service to set up your smart home, you can do it yourself one bit at a time. Granted, if you only have only couple of services, newest raspberry pi might be more then enough.

Upsides and downsides

Of course running homelab has it's upsides and downsides. It's not for everyone. For me, opportunity to learn and shear fun of setting it up outshines the frustration of maintaining it. But let me recap some pros and cons:

Pros:

Your personal network, hidden behind the curtain
Full control over what's in the
Free open-source stuff
Fun way to improve your skills and learn
Depending on setup you can cut quite a lot of monthly costs

Cons:

Steep initial cost
Takes quite some time to set up
Requires above average technical skills
Adds up to your electricity bill
Requires regular semi-maintenance

Summary

The number of use cases for homelab might not be that big and for many it might not be convenient to maintain it themselves. With using third party, you often pay for exactly that: convenience. However if you are into this stuff, you don't have to use your homelab for exactly one use case. You can mix and match according to your needs. And that's the beauty of homelab - flexibility. That's why I chose to run mine. For every paid service I might need at the moment, there is an open source version, that I might be able to run myself. And for everything that is client-facing - I will use AWS.

Take control! Run ChatGPT and Github Copilot yourself!

Sudo BLAZE — Sat, 01 Jun 2024 04:57:15 +0000

The Dark Side

I guess by now everyone already used ChatGPT in some form. At some point I found myself using it to generate boilerplate code, write tests and document stuff. All the boring things. I do like some challenge, but writing same thing over and over again get's quite boring. Well good thing that AI excel at boring!
There is however some concern for not-so-boring stuff, which is privacy. Pasting a proprietary code into ChatGPT is like committing environment variables to git repository. Yet for obvious reason people keep using ChatGPT and Github Copilot on daily basis - for convenience.

You probably also heard already that Reddit and StackOverflow already sold their data to OpenAI for training (actually probably long before it was publicly announced!). We can be almost sure that chat history is also fed into teaching the model.

The Alternative

Enough of my ranting about OpenAI. The alternative is obvious - run it by yourself. If you are well versed in running your own models - you probably won't learn anything new. But if you are new to this, here's the gist: if you have a PC good enough to run a modern game in medium settings, then you are able to run it by yourself. You might be surprised how open source community is active in this area. More so - Meta (yes, Facebook's Meta) is quite in forefront of open-source llm models.

But there are downsides. Self-hosted model will never be up to par with Closed ones. And speed and quality relies heavily on your GPU capabilities. However, for many use cases any RTX cards, and even some GTX 10 Series are enough. Personally I'm using RTX 3080 TI 12GB of VRAM.
Oh - one more thing. While I recommend using NVidia cards for inference (running local model), I don't have experience with AMD Cards, and I cannot recommend or even be 100% sure my approach works for AMD. From what I heard, working with AMD drivers is hell not only for ML Researchers but also for game developers. It breaks my heart because I like their processors.

The Tutorial

There are several solutions out there, but I would go with one that is seamless, and runs in the background, which makes it almost invisible.
However there are some requirements:

Docker
CUDA enabled GPU Yeap, that's it. This solutions should work on Windows, Linux and MacOS. However you might be already aware that docker in windows requires WSL2 enabled.

Step. 1 Install Ollama

Ollama will be our inference backend. If you are familiar with docker, ollama will fill like home. It downloads models from it's own repository and serve them through it's own API which follows OpenAI format. You can also converse with chat in CLI.
To install Ollama go to ollama's downloads page and install it according to your OS.

For bash users (non-windows) here's quick install script:

curl -fsSL https://ollama.com/install.sh | sh

Important! I don't recommend running ollama on docker unless you really know what you are doing, and know how to setup GPU usage from docker. Otherwise, in my opinion Ollama works best on host system.

Now let's test our ollama (yes, after installing windows version, it should be available in cmd and git-bash as well):

ollama pull llama3
ollama run llama3

After second command you need to wait a little while until model loads to VRAM. Then you can chat with it in the CLI!

There are also other models worth checking, like:

llava - multimodal model - you can drop media to prompt about
codellama, codegemma, deepseek-coder - three models dedicated for coding tasks
qwen2 - multilingual competitor to llama3 that also performs twice as good on coding tasks

More: Ollama library

Step 2. Install OpenWebUI

If you are familiar with ChatGPT UI, and feel at home with it, you might like OpenWebUI which is heavily inspired by it. It actually might be more intuitive and powerful than ChatGPT, because it not only supports full chat mode, but also multi-modality (droping files into chat), and RAG workflow (Retrieval Augmented Generation - takes into account context of your files/documents). I checked multiple solutions so far, and this one by an extent is my favorite. And to have it running locally we will use docker.

docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

All the other installation options can be found here: https://github.com/open-webui/open-webui

Now, let's heads up towards http://localhost:3000/
We should be greeted with following screen:

In general you should be able to start chatting, but in case ollama is not set up as backend, you can go to Profile -> Settings -> Connections, and set connection http://host.docker.internal:11434

It means that your docker container will connect to localhost:11434 - exactly where your local ollama api sits.

Step 3: Local Copilot

As of writing this article, I found only one solid replacement for Github Copilot: continue.dev.

The best thing is - it works both with intellij and vscode!
It has all the good stuff: contextual autocomplete, chat with gpt, and shortcuts for snippets!

Setup process is pretty straightforward. It might ask you during install phase to login via github, but you can skip it, and you won't be asked again. Next up, choose your engine, public api or ollama. Then install starcoder:3b for completion and voila!

For me, most important was overall developer experience similar to Copilot, and lack of extra authentication layer. There are several solutions and extensions out there, but this setup works completely on your machine.

Conclusion

What I described here is most optimal workflow I found to be working for me. There are multiple ways to run open source models locally worth mentioning like Oobabooga WebUI or LM Studio, however I didn't found them to be so seamless, and fit my workflow.

For vscode extensions there are also many plugins that attempt to replicate Copilot experience like Llama Coder, CodeGPT or Ollama Autocoder and many more, and I tested a lot of them, however only Continue actually comes close or even surpasses by a bit actual Copilot.

Worth mentioning is also Pieces OS which is basically locally running RAG-app that keeps your whole basecode in the context. I did use it for a while and it's pretty good, however current setup works better with my coding habits.

Overall, this setup saves you some subscription fees and works just as good as original thing!

Why You Should Self-Host Everything

Sudo BLAZE — Mon, 27 May 2024 12:16:49 +0000

In today's digital age, it seems like everything is subscription-based. If you're not paying for a service, you're likely being monetized by watching ads or providing personal data to companies that don't necessarily have your best interests at heart. The internet has become a polluted space where our online activities are tracked and sold to the highest bidder.
And most companies try to exploit and leverage human behavior for profit.
But there's a way to take back control: self-hosting.

The Problem with Centralization

When you use popular services like Netflix, Facebook, Dropbox, or Microsoft Office 360, you're entrusting your data to companies that have no obligation to keep it private or secure. These corporations are incentivized to collect and sell your data to maximize their profits, often without your consent. This centralization of information has created a surveillance state where our online activities are monitored and analyzed for commercial gain. In some cases you pay twice: with your data, and with your wallet. Now it's more visible then ever, when suddenly your repos are being fed to train AI models if by any chance your are using Github.

The Alternative: Homelab Server

Self-hosting is not just about moving your data from one centralized location to another; it's about taking control of your digital life. By setting up a homelab server, you can store your files, communicate with others, and access your favorite services without relying on third-party companies. With a homelab server, you'll have complete control over your data and can ensure that it remains private and secure. To achieve that you will need either pretty solid NAS (like Synology) or micro-pc, like Intel NUC. Raspberry Pi won't do unfortunately, unless you run up to 4 lightweight containers.

Cost Comparison

While setting up a homelab server may require an initial investment of time and money, it's often more cost-effective in the long run. For example:

Cloud Service x4: $10 per month x 12 months x 4 = $480
Intel NUC or Synology NAS: approximately $300-$500 (depending on options you choose)

So depending on your situation and amount of services you are currently subscribed to, the cost of homelab will pay itself in about a year!
Of course there is also cost of time, and required maintenance, but with proper setup it can be minimal effort.

HomeLab possible solutions

As I mentioned, best options are not that expensive, and all you need is a micro-pc. Here's a list of good options eligible for solid docker based homelab:

Intel Nuc 11 i-7, 32GB RAM, 1TB $550 - solid starting point with quite a bit of storage, and a lot of RAM.
Intel Nuc 11 i-7, Bare $390 - No ram, no storage option, if you want to upgrade it yourself from scratch
Intel NUC 11, Celeron N5105, 8GB RAM, 256GB SSD $240 - Low budget option, I know - it's twice as expensive as RPi 5 with the same amount of RAM, but let's be honest - you cannot extend Raspberry Pi
Raspberry Pi 5, 8GB $95 - For the sake of completion. You would still need to buy SD Card. But you can at least set up Pi.Hole and Pi.Alert on it.
Synology 2-Bay NAS DS223, 2GB RAM, Diskless $250 - For those who favor storage space over computing power. As you can see, compared to NUC, it does not have much RAM.
Synology DS723 2-Bay, 2GB RAM, 8TB Storage $990 - A bit more powerful machine with quite solid CPU, but still in range of 2GB of RAM. Some versions comes even with docker preinstalled.

Overall, as you can see, Intel NUC might seem like more cost-effective solution, however NAS has it's own benefits, and often comes with preinstalled OS and Manager, where you can deploy docker on your own.

Easy Deployment with Docker

Setting up a homelab server doesn't have to be a daunting task. What we need is ubuntu or debian OS on our machine.
With the help of containerization platforms like Docker or Podman, you can easily deploy and manage your services without requiring extensive technical expertise. And after initial setup and ssh exposed to your local network, you won't even need to connect your monitor and keyboard anymore, unless to upgrade the whole system again!

You can read how I did it in future article. But for now, there is still one more step in our setup.

Open Source Community

The open source community is thriving, and many self-hosted services are built on top of these collaborative efforts. Now more then ever we have a ton of open source software "just laying around" GitHub.
Many of those software offer simple one line setup for docker. The best thing about docker is, that you don't have to worry about dependencies. And know what's best about them? Because they are open source, it means that you can contribute yourself as well! You are missing a feature? You found a bug and fixed it? Create a Pull Request, Report, Contribute! That's what makes open source community thriving. And by doing a homelab environment, there's nothing stoping you from doing your own docker hosted tools!

Conclusion

Self hosting and running a homelab was never as easy as this. Not that long ago I was running Proxmox and creating VM for everything I needed. Problem is, VMs take up a lot of resources, and without RACK they are highly unreliable, unless you do Penetration Testing and you need like 3-4 environments. Single OS with docker makes it much easier! And by self-hosting everything, you'll enjoy numerous other benefits:

Privacy: Your data remains private and secure, away from prying eyes. You own your data, not a third-party.
Control: You have complete control over what's running. You own the server. Nobody beside you have access to that server.
Flexibility: You can choose the services and software that best suit your needs, without being locked into a specific ecosystem. You can integrate them if you want, or keep them separate.
Financial Benefits: In the long run, self-hosting can be more cost-effective than relying on subscription-based services.

In an era where data is the new currency, it's time to take back control of our online activities. Self-hosting everything offers a powerful alternative to the centralization of information and provides a way to ensure that your digital life remains private, secure, and flexible. Join the self-hosting movement today and start reclaiming your digital sovereignty!

UPDATE!
Because couple of you asked for AMD solution, I dug deeper into mini-pc market, and found couple sweet deals, even one favorite I would definitely went for, if I chose to change systems!

MINISFORUM EliteMini UM780 XTX AMD Ryzen 7 7840HS, 64GB DDR5 1TB $690 - This one is packing!
Beelink AMD Ryzen 7 16GB RAM 1TB SSD $360 - Cheap option, good option for starter with great CPU.
Kamrui AMD Ryzen 5 16GB DDR4 512GB SSD $270 - Slightly cheaper option, more than enough, definitely more than you would get from VPS for $20 a month. Better value then Intel NUC's alternative in similar price range.

Most common Junior JS Developer interview questions

Sudo BLAZE — Thu, 27 Jul 2023 06:01:15 +0000

As a junior JavaScript developer, you can expect to be asked a variety of questions during interviews, covering both technical and non-technical aspects. Here are some of the most common questions that you might encounter:

Basic JavaScript Concepts:
- What is JavaScript, and what is it commonly used for?
- Explain the difference between var, let, and const.
- What are data types in JavaScript?
- How do you declare and call functions in JavaScript?
- What is the difference between null and undefined?
- How does hoisting work in JavaScript?
DOM Manipulation and Events:
- What is the DOM (Document Object Model) in the context of web development?
- How do you access and modify elements in the DOM using JavaScript?
- Explain event delegation and its benefits.
Asynchronous Programming:
- What is asynchronous programming in JavaScript, and why is it important?
- How do you handle asynchronous operations using callbacks, promises, or async/await?
Array Manipulation and Higher-Order Functions:
- How do you loop through an array in JavaScript?
- What are some common array methods like map, filter, and reduce, and how are they used?
ES6+ Features:
- What are some new features introduced in ES6 and later versions of JavaScript?
- How do arrow functions differ from regular functions?
- What are template literals, and how do you use them?
Common Libraries and Frameworks:
- Have you worked with any JavaScript libraries or frameworks like React, Vue, or Angular?
- What are the advantages and disadvantages of using a framework?
Debugging and Tools:
- How do you debug JavaScript code?
- Have you used any developer tools like Chrome DevTools?
Testing:
- Have you written unit tests for JavaScript code?
- What testing frameworks have you used?
Code Organization and Best Practices:
- How do you organize your JavaScript code to make it maintainable and scalable?
- What are some best practices you follow while writing JavaScript code?
Project Experience:
- Can you describe a JavaScript project you worked on?
- What were the most significant challenges you faced during the project, and how did you overcome them?

Remember that the specific questions can vary depending on the company and the interviewer's preferences. It's crucial to review JavaScript concepts, practice coding exercises, and be prepared to discuss your own experiences and projects to demonstrate your skills and enthusiasm for the field.