Squashing Failed: Squash the commits locally, resolve any conflicts, then push the branch. Try again.

It's happened to me several times. It took me some time before I gave up with it and get moved on with duplicating my merge requests (and asking for a re-approval from my workmate).

Now, not anymore. So here's how I solve it.

Assume your current work branch is awesome-feat

• Move back to the base branch, and ensure it's up to date.

git checkout main
git pull

• Merge squash from the work branch. This shouldn't commit anything, but your previous work will be moved to this branch.

git merge --squash awesome-feat

• Confirm changes are in your files right now (If you have conflicts, you may need to resolve them first). Then, delete your work branch locally

git branch -D awesome-feat

• Create a new branch, one with the same name, and checkout.

git branch awesome-feat
git checkout awesome-feat

• Your current work should be still the same, uncommitted, with a new branch that's clean with recent changes. Commit.

git add .
git commit -m "My new awesome feat"

• Here's the tricky part: Force push that to your existing MR branch.
  Don't mistake it with the main branch or any other.

git push --set-upstream origin awesome-feat --force

Your merge request should be clean without conflicts and ready to merge 🎉

• jobfair-utm JobFair system translated for Indonesian content. Stack: Laravel.
• siskampus Academic-wide system for the university. Unfortunately, it's abandoned and not finished yet. Stack: CI
• eabsen Web-based attendance system. Stack: CI
• efaktur-ci Electric facture system. Stack: CI
• wedo Food delivery system. Stack: CI
• ekasir-ci ekasir-front Electric counter system. Stack: CI and CRA
• daftarkp KP (university interns) signing up system. Stack: CI

Please note all names, logos, and icons are reserved copyrights by my clients.

More will be updated here. Anyway, I have a lot of side projects. You can see them all on my GitHub page.

There are many ways to avoid relative imports in Node.js. One of them is either:

1. Add NODE_PATH=./ env ( reference )
2. Set "baseUrl" in (js|ts)config.json ( reference )
3. Use require.main.require ( reference )
4. Directly write into node_modules ( reference )
5. Use NPM/Yarn workspaces ( reference )

There are many downsides to each approach.

1. Adding an environment variable requires adding cross-env NODE_PATH=./ to all package.json scripts and every time you need to run the script yourself. This behavior is also somewhat unreliable during my testing, also VSCode Intellisense won't understand what you're trying to import.
2. The baseUrl option from (js|ts)config.json seems to work out of the box, only for VSCode Intellisense. Node.JS won't understand them so I need a babel compiler to set up, it's explained here anyway but to me, this is way too complicated.
3. Using require.main.require seems like a hack to me, it enforces me to use that in all the scripts rather than the usual require, which of course it's something that I don't like.
4. Directly writing to node_modules is something against its purpose, also would you rather be willing to move your scripts to mode_modules? I wouldn't want it. It would become a nightmare to maintain.
5. Using NPM/Yarn workspaces seems promising at first glance but it enforces me to thinking in the way it was designed for "monorepo". Monorepo is good if you have multiple projects that share code, but really it's just too much because I just work on one big node app. Note this was Yarn only feature, NPM add support too but my last experience using it was buggy.

I have found a less popular but way more reliable: symlink-dir. Let's me summarize their explanation on NPM:

Lets suppose you'd like to self-require your package. You can link it to its own node_modules: symlink-dir . node_modules/my-package

What is by mean to "link"? It's basically creating a directory shortcut. You can read it more here. NPM/Yarn workspaces internally also doing this way.

So to use symlink-dir, I just need to add these values in package.json:

{
  "scripts": {
    "postinstall": "symlink-dir src node_modules/src",
  }, 
  "dependencies": {
    "symlink-dir": "latest"
  }
}

This creates a symlink from src folder to node_modules in my project. After npm i I can use require('src/module.js') instead of require('../../../src/module.js'). Works with ESM imports too!

You can also add more symlinks by just appending the postinstall like "symlink-dir src node_modules/src && symlink-dir lib node_modules/src/libraries" and redoing npm i. Out of all solutions previously, this method works best to me. Hope you like it too!

****
***
**
*
**
***
****

So how you would do that? Here's the code in Python we end up:

for i in range(4, 1, -1):
    print('*' * i)
for i in range(1, 5):
    print('*' * i)

For those who wonder, range(a, b, c) creates an iterator loop from a to b by c. the a is inclusive but b is not. If c is 1, you can omit it since it's the default anyway. Thus range(4, 1, -1) generates [4,3,2] while range(1, 5) generates [1,2,3,4].

And then we take that i to multiply with '*' because python multiplication with string causes that string to be repeated i times, e.g. '*' * 3 generates '***'

This is already short in fact 😅 that's really awesome about Python, isn't it?

But wait, there's more! We can reduce our python code into one single for loop:

for i in range(1, 8):
  if (i < 4):
    print('*' * (5 - i))
  else:
    print('*' * (i - 3))

What does this code do? It transforms [1,2,3,4,5,6,7] to [4,3,2,1,2,3,4] so then we took these values to get multiplied by *. If it takes a while to grasp why I put these values on, I'll try to explain here:

# i < 4
i = 1 => 5 - 1 = 4
i = 2 => 5 - 2 = 3
i = 3 => 5 - 3 = 2
# else (i >= 4)
i = 4 => 4 - 3 = 1
i = 5 => 5 - 3 = 2
i = 6 => 6 - 3 = 3
i = 7 => 7 - 3 = 4

Okay, but why do we do this? It seems didn't make our code shorter, right?

That's why we need to do some math here. Enter the absolute function:

How does this absolute function help us? Well, with some fitting on the equation, we get this graph:

(click the image to see interactive version)

This graph does what we want, transforms [1,2,3,4,5,6,7] to [4,3,2,1,2,3,4] with a single equation. Math is powerful 💪.

This is the code now looks like after we implement the equation:

for i in range(1, 8):
  print('*' * (abs(i - 4) + 1))

Luckily python has abs() built-in without importing any modules. This reduces our code lines from 5 to 2 💪.

But does this can get further decreased to 1 line? Yes 😱

But before that, we have to put the print() function outside the loop. This can be done with a temporary variable that holds the whole string in a loop:

output = []
for i in range(1, 8):
  output.append('*' * (abs(i - 4) + 1))
print('\n'.join(output))

Now we hold the loop value to a variable named output and use that to print output once. Note that we use '\n'.join(output) which converts the array to string with \n between values. \n simply means a new line, for each string, we add during for loop.

But why this makes our code more verbose? Enter Python's killer feature: List Comprehension.

List Comprehension simply means doing a loop within a single line. Effectively makes a loop became a python expression. What this means for a layman is they allow us to convert this code:

variable = []
for item in list:
  variable.append(expression(item))

to:

variable = [expression(item) for item in list]

Three lines into one! Doesn't that awesome? 😎

This is our final code after the list comprehension:

print('\n'.join(['*' * (abs(i - 4) + 1) for i in range(1, 8)]))

That's really short, isn't it? Of course, this code is not readable as we are beginning with 😅 but hey, we do this for fun 💪 also these pieces of stuff are also useful for machine code optimization (if you're into that).

Anyway, if you're familiar with code golfing, you can get the lowest of all codes within 55 characters in Python by removing unneeded whitespace:

print('\n'.join(['*'*(abs(i-4)+1)for i in range(1,8)]))

Anyone can beat that? 😅 Hope this useful 💪

For the reader: I hope you already know what basically monolithic and serverless is, if not, read here. And you may not know about DOM Cloud, it's basically my own hobby project to host websites, it's run on monolithic architecture just like another hosting business does.

Pros and cons of serverless

Definitely, we can't compare uptime quality between monolithic and serverless websites. Serverless is the winner for uptime and it's load resilient over monolithic no matter how it is set up, but this is also a trade: Serverless is complex, that's why both services exist to make it easy for us.

But still, there are still limitations. Serverless websites are immutable, you can't edit files once deployed, because serverless apps might be already replicated over multiple servers. Also, you can't have a persistent connection (WebSocket) and you have to make sure your server code is really idempotent (aka. identical) no matter how their local files and memory are set up or changed.

This is why it's common to use Node.js for serverless apps because with Node.js you are forced to use an external database somewhere even for simple things like sessions. This is very different than, say PHP. Which you just use start_session() then forget how it really works, because PHP loves to write things in files, just like ancient times. This is why practically you won't see any serverless apps written in PHP.

There are many other services that help to lift the serverless architecture limitations, like managed databases or authentication that comes from Firebase or Supabase. You can also use Pusher for handling WebSocket notifications. Those services are easy to get used to (I think) and can easily scale up once your project does.

But, at what cost?

Pricing concerns

With these specialized services, it's easy to get up and running any serverless website. No doubt, probably it's the future. They are also generous with their free plan. But once you go production and scale-up, prices will be unpredictable. Just for a starting point, Vercel + Supabase costs about $45 a month. Okay maybe $45 a month is cheap but this will only go up if usage gets high. And remember, they're behind tech giants like AWS. I heard people can easily get thousands of bills in AWS usage. Why it would be any different if you're behind an abstraction service that also runs on AWS?

Maybe I'm overrating things because these companies must be successful if they had, like thousands of dollar bills in AWS usage. I think this is true if they're a tech company. But many are don't. I work with many people and trust me, they just want their website up and running. You may be thinking because these services are free to start, you just leave them as it is once you lose the freelance contract? You would be a moron, I think. And remember, companies (who are not tech companies) have other bills to pay.

Now, what about monolithic? It's simple as spinning a VM. You can start with a $10 VM instance and pack any software that you want. This takes skill, of course. But many software like Docker should handle this easily. With a monolithic setup, you bear the risk of downtime if there's a misconfiguration or regional downtime. But hey, it's cheaper and the good thing is, you give the company an option if they want to stay in the cloud or going on-premise. This is a big deal that's often overlooked. Because you can't do that with serverless.

I'm maybe biased while writing this but I still have concerns with going serverless and this is it. And I'm not alone.

So domcloud.io still worthy? Yes, as I see it's still useful. Still, it's a no match if you compare it with already hugely successful services like Vercel. But, time will tell as I'm improving it (it's a solo hobby project anyway).

Without further ado, let's start:

1. Use a web hosting control panel

This is true, especially if you aren't familiar with the Linux tools or have a Windows background. There's a lot of setup and maintenance hurdles that come when you start to manage your own server. And definitely, you don't want to memorize all the things using only the terminal! So to lift this, we need to install this piece of software.

While there are some popular options like cPanel or Plesk, it comes with string (price) attached. So we need to use the free one, and Virtualmin, to me, is just perfect.

The installation step is easy too. I won't cover them all here but all it needs to do is run this command (as root):

wget http://software.virtualmin.com/gpl/scripts/install.sh
chmod 0700 ./install.sh
sh ./install.sh --bundle LEMP

Do you see that? I put --bundle LEMP because I prefer to install Nginx over Apache. Whatever the choice is up to you but overall Nginx is way faster than Apache because of its simple configuration and event-driven, and you need those (the webserver) anyway to let it handle the heavy lifting of managing your app processes.

I'll discuss these later but one thing you need to know is installing Virtualmin or any of these will destroy any existing setup on your server so only install it when your VM or server is a fresh install.

But then, what happens after the installation? Head to https://<Your IP address>:10000 to open Webmin portal (yes, Virtualmin is part of Webmin).

You may encounter some SSL issues but skip it, it's fine. Login with root account and password that you've set up, then follow the initial setup and create a new domain. Voila, you're done! There is no need to learn the hassle of creating a non-root user in a terminal and trying to synchronize everything overnight!

Sounds good? Let's continue.

2. Know how to run your app properly

Chances are you already know how to start your own local server. You may do the same thing on your VM but it will be a bad, bad idea. For an online server that needs to run 24 hours 7 days a week, you need some sort of proxy that protects your app processes from randomly crashing due to fatal crashes or high flood of traffic, and this proxy is what Nginx (or Apache) really does. What these proxies really do is they're run the actual HTTP(S) port on 80 and 443 and forward any incoming traffic to a local port or socket which your app really listens to. Web proxies are also really good at dividing traffic based on domains (like domain A goes to this app then domain B goes to that app) and reporting or logging crashes of your app. Web proxies are just that awesome and you need to understand how to configure them properly, even though Virtualmin will already do the heavy lifting for you.

After the installation of Nginx that comes from Virtualmin, you might be surprised that, it already comes with PHP support by default, like the usual way web hosting does. You can see how NginX config on a specific domain looks like:

server {
    server_name example.com;
    listen 1.2.3.4;
    listen 1.2.3.4:443 ssl;
    root /home/username/public_html;
    index index.html index.htm index.php;
    access_log /var/log/virtualmin/example.com_access_log;
    error_log /var/log/virtualmin/example.com_error_log;
    location ~ \.php(/|$) {
        try_files $uri =404;
        fastcgi_pass localhost:8001;
    }    
    ssl_certificate /home/username/ssl.combined;
    ssl_certificate_key /home/username/ssl.key;
}

You can see that it has the domain you want to listen to example, the server IP to listen with 1.2.3.4, where the base directory is /home/username/public_html and so on. What is essential in NginX is that by default it only serves as a static web server. To make most of the features it gives you need to understand additional configs, like the fastcgi_pass to enable dynamic processing on .php files.

PHP is great, but not for all of us. What about running Node.js or Python apps? You might be tempted to use proxy_pass but it won't handle the app startup and crashes for us. Luckily we have a better option: Phusion Passenger.

What is that? That is the app server, which is able to manage and automatically run Node.JS, Python, Ruby, well, all kinds of server apps you might need to run in your server, and it has an awesome integration with Nginx.

After you follow the installation step, all you need to do is add these options in NginX config:

    root /home/username/public_html/public;
    passenger_enabled on;
    # for easier debugging!
    passenger_friendly_error_pages on;

It will magically find any relevant startup file (like app.js or passenger_wsgi.py) in the parent root directory (public_html) and boot the relevant process (of course, you need to already do have Node.js or whatever programming language you want to run with and already installing node_modules or whatever code dependencies your app need beforehand).

Can you run your app now? Great. Let's continue.

3. Overcoming DNS (and SSL) problems

Your app runs on an IP public address now. Great! But nobody (even Google) wants to remember your IP address. You need to buy a domain yourself. I won't point out what's to recommend on this one so go buy a domain from whatever web hosting service you're already familiar with. But what I need to tell you is that after you buy a domain, you need to point out that domain to your server's IP address. This is done under "DNS Management" and in there, you can insert your server IP address using A record (and AAAA if care about IPv6), and that's it!

But wait. There's more...

DNS caches everything under the TTL (Time to Live), and by default for most services, it's set for about 4 hours (14400). You certainly don't want to wait 4 hours to just be able to see your new shiny website, right?

While you can just bypass DNS using hosts file, it's much better if you can go to Google DNS resolver and see if Google itself picks up your new domain. It usually works for the first time without flushing their cache. (if it doesn't work, well something may be wrong with your registrar?!).

After you check it, if Google DNS resolver sees your IP address now but your device still won't pick up it, you can set your device DNS resolver to 8.8.8.8 and 8.8.4.4 (the Google Public DNS) and after that, it will certainly work. Yay!

But wait. There's more (again!)...

You can access your site using http:// but not https://, right? HTTPS is very important nowadays so you can't ignore it. But then, to do that, you need to sign your SSL certificates. I won't go into detail about why it works like that but what I need to tell you is that there's the only kind of SSL agency there, it's called Let's Encrypt and it will create a signed SSL certificate for your domain for free. How?

Assuming you already have a correct configuration in your Nginx, with Virtualmin you can go to SSL certificate panel and send a request to Let's encrypt in a few clicks. Sound simple? Yes, but not just that. You can also make Virtualmin renew your SSL certificate automatically. Awesome, isn't it?

Now your website should be online and can start gaining users. Congrats!

4. Understand memory management (and when to panic)

It's a regular evening and your server has been running for few weeks. Yet you look at the Virtualmin memory gauges of your server and start wondering.

Usually, this will come in two situations:

Situation A: Your server is wasting resources

You notice that your server only uses around 40% of memory so you think if you could cut the monthly bill in half by reducing its computing memory. Before it happens, I will tell you: don't do that! unless you're running into a budget problem.

Even though it seems your system is wasting the excess memory, it's actually not. Linux will always use most of your RAM because of RAM cache. And you might wonder, what's the deal with it?

Well, most operations on Linux rely heavily on files. The kernel is smart, when a process is done reading or writing a file, it's actually kept temporarily as RAM cache so when another process reads it the next time, it won't wait for the storage disk to actually perform the read, dramatically improving the overall system performance.

I won't tell more details in this, but that's the whole point. Cutting your free memory will severely decrease the overall performance. Don't reduce it unless you have a problem with budgeting.

Situation B: Your server is heating

Some users tell you slower loading times and some error pages show up significantly. How would you confirm what goes wrong? Firstly, you need to check the load. If the load metric is going like tens, it means your server can't keep up the traffic. Then you need to check your memory consumption by going to free -m. The result is probably like this:

              total        used        free      shared  buff/cache   available
Mem:           1817        1327          67          72         421         268
Swap:             0           0           0

If you have low memory available, it means your server struggling to find more memory. You can increase the computation memory right now but it would be a bad idea if you actually turn off your VM during high traffic, so what you can do is create a swap file.

A swap file is basically an additional memory attached to a storage disk. You might think it's a good idea to put a large swap file and suddenly your memory problem would go, but no. Because too much swapping could render the system unstable too.

A better way to think about a swapfile is like a band-aid. During temporary traffic surges, Linux can put non-essential memory processes to swapfile so the actual memory can better spend on essential programs and frequently used RAM caches. For this to work, I recommend a swapfile about 1 or 2 GB size and swappiness around 30.

But if you have already done these but still have low memory availability, it's time to add more actual memory.

I talked frequently about memory. While it's the most likely problem during high load, sometimes there's another factor too, like a rogue process running in the background or maybe there's just not enough core counts in your VM. A look at top can help you a lot to diagnose this.

5. Protect your server with basic security and backup knowledge

This is the final piece of advice that I need to tell you, as security and backups are so easy to overlook yet most people don't realize how important it is until it's too late.

Good basic security of any VM serving the internet is to only allow specific inbound ports like SSH, HTTP(S), and any related port you might use. Most cloud providers already have a firewall config so it's good to use them if available. Or if it isn't you can use firewalld or iptables to safeguard your traffic at the kernel level. If you're like me who uses Webmin, you might want to change the port to something else as leaving the default 10000 probably would make it vulnerable to botnets that swarming the internet.

If you have some memory and computation to spare, it might be a good idea to install software that prevents brute force attacks like Fail2Ban, or maybe just don't enable password-based login in SSH and disable database remote control when you don't need it.

And lastly, do a frequent backup, as you probably don't aware of how things can be messed up certainly in the future. The good news is most cloud providers have a way to make a "snapshot" of your VM and allow you to schedule it weekly. It probably cost you an additional pennies but it totally worth it.

Closing

That is a lot of topics I discover. You might think, where do I get all those knowledge? Well, I have some background story that you might want to read, go check it out :)