DEV Community: Tonny Kirwa

The Graveyard of Repos: 100 Projects - Zero Shipped

Tonny Kirwa — Fri, 26 Dec 2025 07:08:32 +0000

Every software engineer knows the feeling. You're browsing GitHub, your own local machine, or even just your mental list of "things I'm working on," and there it is: a sprawling digital graveyard of half-finished projects. Directories brimming with package.json files and node_modules folders, each one a testament to initial enthusiasm that slowly, quietly, faded into abandonment.

You started with a spark - a brilliant idea, a new technology to learn, a problem to solve. You coded furiously, built out the core features, marvelled at your progress, and then... nothing. The last 20%-the polish, the edge cases, the deployment, the marketing-became an insurmountable wall. The allure of the next shiny idea pulled you away, and another project joined the ranks of the dearly departed.

If you're nodding along, you're not alone. The transition from "starter" to "shipper" is one of the most significant hurdles in a software engineer's journey. It's not about a lack of skill or intelligence; it's about shifting your relationship with "done."

It's time to stop collecting projects and start collecting wins.

Why Projects Die: The Unseen Killers

Before we revive the living, let's understand why so many projects end up in the digital afterlife:

The "Creation High"

The initial phase of building something from scratch is exhilarating. It's pure problem-solving and immediate gratification. The tedious work of bug fixing, UI polish, and deployment simply can't compete with the thrill of a fresh canvas.

Lack of a Clear "Definition of Done"

If you don't know what the finish line looks like, you'll never cross it. "Done" becomes a perpetually moving target, leading to feature creep and endless tinkering.

The Allure of the Next Shiny Thing

The tech landscape evolves at light speed. A new framework, a new language, or just a cooler idea can easily derail an almost-finished project.

Perfectionism

The enemy of "good enough." The desire for a flawless product often prevents any product from ever seeing the light of day.

Fear of Judgment

Putting your work out there can be intimidating. What if it's not good enough? What if people criticize it? This fear often manifests as endless "just one more feature" syndrome.

From Graveyard to Greenhouse: A Framework to Finally Ship

It's time to move beyond motivation and implement concrete systems that prioritize completion.

Redefine "Done" with the Minimum Viable Ship (MVS)

This is the single most critical shift. Stop aiming for v1.0; aim for v0.1.

The Single Core Feature: What is the absolute, non-negotiable, singular most important thing your project must do? If it's a note-taking app, it's "create and view a note." Forget search, tags, or rich text for the MVS.
The "One-User" Rule: A project is truly "shipped" when one person (even if it's just you, a trusted friend, or a stranger from a niche forum) can use it via a URL or a downloadable artifact. No user, no ship.
Public URL First: As early as possible, deploy a "Hello World" or a basic skeleton of your app to a public URL (Vercel, Netlify, Fly.io, etc.). This makes the project feel real and creates a psychological commitment.

Leverage Powerful Mental Models

Parkinson's Law in Action: "Work expands to fill the time available for its completion." Instead of "I'll finish this project this weekend," try, "I will get this deployed in the next 4 hours." This forces aggressive prioritization and efficiency.
The 15-Minute Rule: When you hit a frustrating bug or feel the urge to start something new, commit to working on the current project for just 15 minutes. Often, the inertia of starting is the biggest hurdle.
Type 1 vs. Type 2 Decisions: Don't get stuck in analysis paralysis over framework choices (React vs. Vue), database options (SQL vs. NoSQL), or styling libraries. These are almost always "Type 2" (reversible) decisions. Pick one quickly and move on. Only "Type 1" (irreversible, high impact) decisions warrant significant thought.

The "Finish One" Protocol: A Digital Declutter

If you have multiple active projects, you're fragmenting your focus.

Inventory & Excise: List every single open project you have. Be honest. Then, ruthlessly archive or delete anything you haven't touched in 3-6 months. Let them go. They served their purpose as learning tools.
Choose Your Champion: From your remaining list, select one project. Your goal is to get this one across the finish line. Choose the one closest to completion, or the one you're most excited about.
Salami Slice the Remaining Work: Break down the remaining tasks for your chosen champion into incredibly small, actionable steps. "Build Authentication" is too big. "Create Login Form UI" or "Implement Email/Password Sign-up" are tasks. Aim for tasks that take 30-90 minutes.

Systems Over Motivation: Build Pipelines, Not Dreams

Embrace Boilerplates: If your goal is to ship a product, not to learn every intricate detail of Webpack configuration, use a solid boilerplate (e.g., Create React App, T3 Stack, Next.js templates, Phoenix generators). Speed to deployment is key.
Automate Everything Possible: CI/CD pipelines, automated testing (even minimal), and simple deployment scripts reduce the friction of getting updates out.

The Unfinished Project as Tuition

It's crucial to acknowledge this: Your graveyard of repos is not a monument to failure; it's a testament to your learning and experimentation. Each abandoned project likely taught you a new library, a better coding pattern, a different language, or a deeper understanding of software architecture. You haven't wasted time; you've been acquiring skills.

Now, it's time to leverage those skills to create something tangible. Choose one project. Define its MVS. Break it down. And ship it. The first one is the hardest, but it breaks the cycle.

You have the skills. You have the ideas. It's time to move from aspiring developer to a developer who ships. What will be the first project you pull from the graveyard and bring to life?

Zod, A Population Schema Validation Library, Next.js

Tonny Kirwa — Sat, 07 Jun 2025 08:59:52 +0000

In Next.js, Zod is commonly used as a schema validation library to ensure data integrity and type safety for runtime data, such as form inputs, API responses, or environment variables. It is not a built-in part of Next.js but is often integrated into Next.js projects to handle validation and type inference in a robust, TypeScript-friendly way.

Schema Validation

Purpose: Zod allows you to define schemas to validate data structures, ensuring they conform to expected formats before processing them.
Use Cases:
- Form Validation: Validate user inputs in forms (e.g., ensuring an email is valid or a password meets complexity requirements).
- API Route Validation: Validate incoming request data in Next.js API routes or server actions.
- Environment Variables: Validate environment variables to ensure they are present and correctly formatted before the app runs.

Example (Form Validation):

   import { z } from 'zod';

   // Define a schema for a user form
   const userSchema = z.object({
     name: z.string().min(2, 'Name must be at least 2 characters'),
     email: z.string().email('Invalid email address'),
     age: z.number().min(18, 'Must be at least 18'),
   });

   // In a Next.js API route or server action
   export async function POST(request: Request) {
     try {
       const data = await request.json();
       const validatedData = userSchema.parse(data); // Throws error if invalid
       // Process validated data
       return Response.json({ success: true, data: validatedData });
     } catch (error) {
       return Response.json({ error: 'Invalid data' }, { status: 400 });
     }
   }

Type Safety with TypeScript

Zod integrates seamlessly with TypeScript by automatically inferring TypeScript types from schemas using z.infer.
This ensures that validated data is type-safe, reducing runtime errors and improving developer experience.

Example (Type Inference):

   import { z } from 'zod';

   const userSchema = z.object({
     name: z.string(),
     email: z.string().email(),
     age: z.number(),
   });

   // Infer TypeScript type from schema
   type User = z.infer<typeof userSchema>;

   // Use the inferred type
   const user: User = { name: 'John', email: 'john@example.com', age: 25 };

Environment Variable Validation

In Next.js, environment variables are often defined in .env files. Zod can validate these variables to ensure they exist and have the correct format, especially in next.config.js or server-side code.

Example (Environment Variables):

   import { z } from 'zod';

   const envSchema = z.object({
     DATABASE_URL: z.string().url(),
     API_KEY: z.string().min(1),
   });

   const env = envSchema.parse({
     DATABASE_URL: process.env.DATABASE_URL,
     API_KEY: process.env.API_KEY,
   });

   // Use validated environment variables
   console.log(env.DATABASE_URL); // Safe access

Integration with Next.js Features

Server Components and Server Actions: Zod can validate data in React Server Components or server actions, ensuring safe data handling on the server.
API Routes: Validate incoming JSON payloads in Next.js API routes to prevent invalid data from reaching your business logic.
Form Libraries: Zod is often used with libraries like react-hook-form or formik for client-side form validation in Next.js apps.

Example (with react-hook-form):

   import { useForm } from 'react-hook-form';
   import { zodResolver } from '@hookform/resolvers/zod';
   import { z } from 'zod';

   const schema = z.object({
     email: z.string().email('Invalid email'),
     password: z.string().min(6, 'Password too short'),
   });

   export default function LoginForm() {
     const { register, handleSubmit, formState: { errors } } = useForm({
       resolver: zodResolver(schema),
     });

     const onSubmit = (data: z.infer<typeof schema>) => {
       console.log('Validated data:', data);
     };

     return (
       <form onSubmit={handleSubmit(onSubmit)}>
         <input {...register('email')} />
         {errors.email && <p>{errors.email.message}</p>}
         <input {...register('password')} type="password" />
         {errors.password && <p>{errors.password.message}</p>}
         <button type="submit">Submit</button>
       </form>
     );
   }

Error Handling

Zod provides detailed error messages when validation fails, which can be used to return meaningful feedback to users or log issues for debugging.

Example:

 try {
   userSchema.parse({ name: '', email: 'invalid', age: 'not-a-number' });
 } catch (error) {
   if (error instanceof z.ZodError) {
     console.log(error.errors); // Detailed validation errors
   }
 }

Why Use Zod in Next.js?

Type Safety: Combines runtime validation with TypeScript type inference.
Developer Experience: Clear, declarative schema definitions and detailed error messages.
Flexibility: Works across client, server, and API contexts in Next.js.
Ecosystem Compatibility: Integrates well with popular Next.js tools like react-hook-form, tRPC, or NextAuth.

Installation

To use Zod in a Next.js project:

npm install zod
# or
yarn add zod

Conclusion

Zod’s role in Next.js is to provide robust data validation and type safety, making it easier to handle form inputs, API requests, and environment variables in a secure and maintainable way. It’s particularly valuable in TypeScript projects for ensuring consistency between runtime and compile-time types.

Managing Secure Boot Keys for Software on Ubuntu 24.04 LTS

Tonny Kirwa — Fri, 09 May 2025 06:51:34 +0000

Secure Boot is a security feature that ensures your computer only boots with software trusted by the Original Equipment Manufacturer (OEM). It verifies the digital signatures of bootloaders and firmware, preventing unauthorized or malicious software from loading before the operating system. This helps protect against rootkits and other malware that could compromise the system early in the boot sequence.

When using Secure Boot on Ubuntu 24.04 LTS, your system ensures that only trusted software is loaded during the boot process. Ubuntu's core components are signed by Canonical's key, which is recognized through a chain of trust established with the UEFI firmware. However, for third-party software, particularly drivers (like NVIDIA proprietary graphics drivers) or custom-compiled kernel modules, an additional step is often required: enrolling a Machine Owner Key (MOK).

There isn't a single command to "add all keys pending for all software" in a batch operation for distinct keys. Instead, the system typically handles MOK enrollment on a per-need basis when software requiring a new signature is installed or updated.

Here's how the process generally works and how you can manage these keys:

Understanding MOKs and the Enrollment Process:

Triggering Enrollment: When you install software that includes kernel modules not signed by Canonical's key (e.g., via dkms for NVIDIA drivers, VirtualBox modules, etc.), the installation process should automatically initiate the MOK enrollment procedure.
Password Prompt: You will typically be prompted to create a temporary password (usually between 8 and 16 characters). This password is specifically for the MOK enrollment process that will occur on the next reboot. Remember this password.
Reboot and MOKManager: Upon rebooting your system, before Ubuntu fully loads, a blue screen interface called MOKManager (or Shim UEFI key management) will appear.
Enrolling the Key:
- Select "Enroll MOK" (or a similar option like "Enroll key from disk").
- You might be asked to confirm the key you want to enroll.
- You will then be prompted to enter the password you created in step 2.
- Confirm the enrollment.
System Reboots Again: After successful enrollment, the system will reboot once more, and the newly enrolled key will allow the signed third-party modules to be loaded.

Checking Secure Boot and MOK Status:

You can use the mokutil command in the terminal to check the status:

Check Secure Boot status:
```
mokutil --sb-state
```
This will tell you if Secure Boot is enabled.
List enrolled MOKs:
```
mokutil --list-enrolled
```
This will show any MOKs that have already been enrolled in your system's firmware.

What if Enrollment was Skipped or Failed?

If you accidentally skipped the MOKManager screen (e.g., by selecting "Continue boot") or if an enrollment seems to have failed, you can often re-initiate the process:

Re-initiating MOK Enrollment:
For keys managed by shim-signed (which is common for DKMS modules like NVIDIA drivers), you can try to force the re-enrollment prompt for an existing key that hasn't been enrolled yet:
```
sudo update-secureboot-policy --enroll-key
```
This command will check for a pending MOK and, if found, prompt you to set a password for enrollment on the next reboot. If it says a key is already enrolled, or no new key is pending, then there's nothing immediate for this command to do.
Reinstalling the Software:
In some cases, reinstalling the specific software package (e.g., the DKMS version of a driver) might re-trigger the MOK enrollment prompts:
```
sudo apt reinstall <package-name>
```
Replace <package-name> with the actual name of the driver package (e.g., nvidia-dkms-550).
Generating and Importing a New MOK (Advanced):
If a MOK wasn't generated or if you need to manage keys manually (less common for typical software installs):
- A MOK is often automatically generated by packages like shim-signed and placed in /var/lib/shim-signed/mok/ or by DKMS in /var/lib/dkms/.
- You can generate a new MOK pair if needed:
```
sudo update-secureboot-policy --new-key
```
  You'll be prompted to create and verify a password for this new key. Then, use sudo update-secureboot-policy --enroll-key to enroll it.
- To manually import a specific key file (e.g., MOK.der):
```
sudo mokutil --import /path/to/your/MOK.der
```
  You'll be prompted to set a password for enrollment on reboot.

Important Considerations:

"All Software": Secure Boot key enrollment is decentralized. Each piece of software that installs unsigned kernel modules will typically trigger its own MOK enrollment request if its signing key isn't already trusted. If multiple drivers are built using DKMS, they might all be signed by a single DKMS-generated MOK once it's enrolled.
Third-Party Repositories: Software from third-party repositories might also require MOK enrollment if it includes kernel modules.
TPM and Full Disk Encryption (FDE): While generally compatible, some users have reported complexities with MOK enrollment when TPM-backed FDE is also in use. Ensure your system firmware is up to date.
BIOS/UEFI Settings: Ensure Secure Boot is enabled in your system's UEFI/BIOS settings. Some firmware interfaces also offer options to manage Secure Boot keys directly (e.g., to enroll keys from a USB drive), though using Ubuntu's mokutil is usually the standard procedure.

By understanding the MOK enrollment process and using the mokutil and update-secureboot-policy commands, you can effectively manage the keys required for your software to run under Secure Boot on Ubuntu 24.04 LTS. Remember to follow the on-screen prompts carefully during driver or module installation and the subsequent reboot.

Gatsby and Next.js

Tonny Kirwa — Fri, 09 Feb 2024 09:26:09 +0000

Let’s delve into a comparison between Gatsby and Next.js, two popular frameworks in the React ecosystem. Each of these tools serves distinct purposes and excels in different scenarios. Here’s an overview of both, along with their ideal use cases:
Gatsby

Static Site Generator (SSG): Gatsby is primarily a static site generator. It builds static HTML/CSS/JS files during the build process, which can be deployed without a server.
Performance and SEO: Gatsby focuses on fast page load times, excellent SEO optimization, and progressive image loading.
Content Sources: It integrates well with various data sources (e.g., Markdown files, APIs, headless CMS) to create content-rich websites.
Ideal Use Cases
- Building static websites (blogs, portfolios, marketing sites).
- Content-driven sites with rich data sources.
- Projects where SEO and performance are critical.

Next.js

Hybrid Framework: Next.js combines server-side rendering (SSR) and static site generation. It generates HTML/CSS/JS at runtime when needed.
Server-Side Rendering: Next.js excels in server-side rendering, making it suitable for dynamic content and personalized experiences.
Data Handling: Next.js leaves data handling decisions to the developer, allowing flexibility in fetching data.
Ideal Use Cases
- Server-rendered pages (e-commerce, dashboards, user-specific content).
- Projects where developer experience and scalability matter.
- Applications requiring offline access (Progressive Web Apps).

When to Choose Each

Gatsby
- Choose Gatsby for static sites, blogs, and content-heavy projects.
- If you prioritize SEO, image optimization, and fast initial page loads.
- When you want to leverage GraphQL for data sourcing.
Next.js
- Choose Next.js for dynamic pages, e-commerce, and personalized content.
- If you need server-side rendering (SSR) for better SEO and user experience.
- When you value developer experience and scalability.

Remember that both frameworks have their strengths, and the choice depends on your specific project requirements.

Formatting Phone Number in JavaScript - Country Code + Leading Zero (0)

Tonny Kirwa — Sun, 07 Jan 2024 07:33:53 +0000

To ensure that smsPhone is in the format '+2547XXXXXXXX', you can modify the code as follows:

// Assuming smsPhone is a variable holding the phone number
const formattedPhone = `+${smsPhone.replace(/^0/, '254')}`;

const response = await sms.send({
    to: [formattedPhone],
    message: smsMessage,
    enqueue: true
});

This code uses the replace function to replace the leading '0' in the phone number with '254' and then adds a '+' to the beginning. This ensures that the phone number is in the international format. Ensure that smsPhone is a string representing the phone number without the country code. The modified formattedPhone variable should then be used in the to field of the sms.send method.

Disappoint Hackers - Add SSL Certificates to your Website

Tonny Kirwa — Sat, 06 Jan 2024 12:18:41 +0000

To obtain SSL certificates for www.realmigo.tech and realmigo.tech using Let's Encrypt, you can use Certbot. Certbot simplifies the process of obtaining and renewing SSL certificates. Here's a step-by-step guide:

Prerequisites:

Ensure that your domain's DNS records point to the correct IP address.
Make sure that your server is reachable on ports 80 and 443.

Steps:

Install Certbot: Install Certbot on your server. The commands might vary depending on your operating system. For example, on Ubuntu, you can use:

sudo apt update
sudo apt install certbot
sudo apt install python3-certbot-nginx

Obtain SSL Certificates: Run Certbot to obtain SSL certificates for both www.realmigo.tech and realmigo.tech:

sudo certbot certonly --nginx -d realmigo.tech -d www.realmigo.tech

This command will use Certbot in standalone mode and perform the necessary steps to prove domain ownership.

Configure Nginx to Redirect HTTP to HTTPS (Optional but recommended): Create an Nginx configuration file for your application, specifying the SSL certificate paths. Create a new file, for example, /etc/nginx/sites-available/your-app, and add the following content:

   server {
       listen 80;
       server_name realmigo.tech www.realmigo.tech;
       return 301 https://$host$request_uri;
   }

   server {
       listen 443 ssl;
       server_name realmigo.tech www.realmigo.tech;

       ssl_certificate /etc/letsencrypt/live/realmigo.tech/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/realmigo.tech/privkey.pem;

       # Additional SSL configurations go here

       location / {
           proxy_pass http://localhost:your_app_port;
           proxy_http_version 1.1;
           proxy_set_header Upgrade $http_upgrade;
           proxy_set_header Connection 'upgrade';
           proxy_set_header Host $host;
           proxy_cache_bypass $http_upgrade;
       }
   }

Replace your_app_port with the actual port where your application is running.
Create a Symbolic Link:
Create a symbolic link to enable the Nginx site:

sudo ln -s /etc/nginx/sites-available/your-app /etc/nginx/sites-enabled/

Test Nginx Configuration and Restart Nginx: Check the Nginx configuration for syntax errors:

   sudo nginx -t

If there are no errors, restart Nginx:

   sudo service nginx restart

Automatic Renewal: Set up a cron job to automatically renew the Let's Encrypt certificates:

   sudo crontab -e

Add the following line to run the renewal process twice daily:

   0 */12 * * * certbot renew --quiet

Save and exit the editor.

Now, your site should be accessible over HTTPS at https://www.realmigo.tech and https://realmigo.tech. Make sure to customize the Nginx configuration according to your application's needs.

SSH: "Connection refused" Fix - Ubuntu Server

Tonny Kirwa — Sat, 06 Jan 2024 11:28:52 +0000

The "Connection refused" error typically indicates that the SSH service is not running on the specified host, or a firewall is blocking the connection.

Error below

root@00bc17d6e6f8:/# ssh -v ubuntu@100.24.238.153
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014

debug1: Reading configuration data
/etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying
options for * debug1: Connecting to 100.24.238.153 [100.24.238.153]
port 22. debug1: connect to address 100.24.238.153 port 22:
Connection refused ssh: connect to host 100.24.238.153 port 22:
Connection refused root@00bc17d6e6f8:/#

Here are a few steps to troubleshoot the issue:

Check SSH Service: Ensure that the SSH service is running on the remote server. If you have access to the server, you can check and restart the SSH service using the following commands:

   sudo service ssh status
   sudo service ssh restart

Firewall Configuration:
Make sure that the firewall on the remote server is not blocking incoming connections on port 22 (the default SSH port). You can temporarily disable the firewall or allow SSH traffic through it.
Security Group / Network ACLs (for AWS):
If you are using Amazon Web Services (AWS), check the security group and network ACL settings for the instance. Ensure that incoming traffic on port 22 is allowed.
Check if SSH is Listening:
On the remote server, check if SSH is listening on the specified port (22 by default). You can use the following command:

   sudo netstat -tulpn | grep 22

This should show an entry for the SSH daemon (sshd) listening on port 22.

Restart SSH Service on the Remote Server: If the SSH service is running, try restarting it on the remote server:

   sudo service ssh restart

Check Server Logs:
Examine the logs on the remote server for any SSH-related issues. The location of the logs may vary depending on your server's operating system. Common locations include /var/log/auth.log, /var/log/secure, or /var/log/messages.
Confirm IP Address:
Double-check that the IP address (100.24.238.153 in this case) is correct and corresponds to the intended server.

After performing these steps, try connecting again:

ssh -v ubuntu@100.24.238.153

The -v option provides verbose output and might give more details about the connection issue. If the problem persists, inspect the logs and error messages for further troubleshooting.

Senior Backend Engineer, Markets (Kenya) - TALA - Job

Tonny Kirwa — Sun, 31 Dec 2023 13:03:17 +0000

Tala · Nairobi, Nairobi County, Kenya

The Senior Backend Engineer builds and extends Tala’s backend architecture to support new country launches, new features, and a fast-growing user base. As a technologist and a leader, the Senior Backend Engineer pushes the team towards building a highly available, scalable, reliable, fault-tolerant, and performant microservices platform. The Senior Backend Engineer follows and improves upon Tala’s engineering processes and standards while advancing Tala’s mission and business objectives. This is a technical leadership role within Tala’s technical track. You will report to the Backend Engineering Manager and collaborate cross-functionally with all Tala teams across the globe.

Responsibilities

Design and implement features as defined in the Product roadmap
Review design documents, perform code reviews, and weigh in on implementation choices from other technical teams
Collaborate and support with cross-functional teams (Product, Data, Credit, and Business Development) to ship scalable software solutions
Continually improve our codebase with clean and efficient code as well as solve problems using the most appropriate technology
Contribute to the complete migration of the legacy codebase to the microservices architecture
Contribute to the testing infrastructure to increase code coverage for backend modules
Advance monitoring and alerting capabilities of backend modules to allow proactive improvements to availability and response times
Technically lead and mentor a team of Backend Engineers to build/extend complex modules

Requirements

4+ years of backend software engineering experience
4+ years coding in one or more of the following languages: Java, Scala, Kotlin
Developed and launched large-scale consumer applications with the backend on Cloud infrastructure (AWS, Google Cloud, or Azure) using a microservices architecture paradigm
Expert knowledge in REST API design and development for mobile/web use
Expert proficiency in the Agile development process
Excellent ability to prioritize and communicate in a fast-paced environment
Strong relational database experience (MySQL, PostgreSQL, Oracle, or MS SQL)
Strong non-relational database experience (Cassandra, Redshift, DynamoDB, HDFS)
BS degree in Computer Science or related fields is a plus
Demonstrated ability to interview candidates and evaluate technical skills

Our vision is to build a new financial ecosystem where everyone can participate on equal footing and access the tools they need to be financially healthy. We strongly believe that inclusion fosters innovation and we’re proud to have a diverse global team that represents a multitude of backgrounds, cultures, and experiences. We hire talented people regardless of race, religion, colour, national origin, gender, gender expression, sexual orientation, age, marital status, veteran status, or disability status.

Apply Here
https://www.linkedin.com/jobs/view/3707531360/

Setting up Express Backend API to use Docker

Tonny Kirwa — Mon, 18 Dec 2023 15:31:56 +0000

To set up a Dockerfile for your Clarek CRM backend using Express.js with port 8000, follow the steps below:

Create a Dockerfile:

Create a file named Dockerfile in the root directory of your Clarek CRM backend project.

# Use an official Node.js runtime as a base image
FROM node:20

# Set the working directory in the container
WORKDIR /usr/src/app

# Copy package.json and package-lock.json to the container
COPY package*.json ./

# Install app dependencies
RUN npm install

# Copy the rest of the application code to the container
COPY . .

# Expose port 8000
EXPOSE 8000

# Define the command to run your application
CMD ["node", "app.js"]

Noted that WORKDIR /usr/src/app becomes WORKDIR /clarek-crm-backend

Build the Docker Image:

Open a terminal and navigate to the directory containing your Dockerfile and application code. Run the following command to build the Docker image:

docker build -t clarek-crm-backend .

This command will build the Docker image using the instructions in the Dockerfile and tag it with the name clarek-crm-backend.

Run the Docker Container:

After building the image, you can run the Docker container using the following command:

docker run -p 8000:8000 -d clarek-crm-backend

This command maps port 8000 on your host machine to port 8000 in the Docker container and runs the container in detached mode (-d).

Now, your Clarek CRM backend should be accessible at http://localhost:8000.

Note: Make sure your Express.js application is configured to listen on port 8000. You can set the port in your Express.js application code or through a configuration file.

Remember to replace any placeholder names or values with your actual project details. Adjust the Node.js version in the FROM statement based on your project's compatibility.

Generate a Random JWT Secret Key

Tonny Kirwa — Sat, 16 Dec 2023 12:06:41 +0000

To generate a random JWT secret key, you can use a tool like Node.js to create a random string. Here's a simple example:

Open your terminal or command prompt.
Run the following Node.js script to generate a random string:

node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"

This command uses the crypto module in Node.js to generate a random sequence of 32 bytes and then converts it to a hexadecimal string.

Copy the generated string.
Open your .env file and set the JWT secret key:

JWT_SECRET=paste-the-generated-string-here

Replace paste-the-generated-string-here with the string you copied.

Save the changes to your .env file.

Now, you have a securely generated JWT secret key. Remember to keep this key confidential and don't share it publicly. If needed, you can regenerate the key and update it in your .env file.

PostgreSQL and Nginx through the firewall using Ports

Tonny Kirwa — Tue, 10 Oct 2023 10:39:46 +0000

To allow PostgreSQL and Nginx through the firewall by specifying the ports they use, you can use the ufw (Uncomplicated Firewall) utility on Ubuntu. Here's how you can do it:

Allow PostgreSQL (Postgres) Port:

By default, PostgreSQL uses port 5432. To allow PostgreSQL through the firewall, you can use the following command:

sudo ufw allow 5432/tcp

This command allows incoming TCP traffic on port 5432, which is the default PostgreSQL port.

Allow Nginx Port:

Nginx uses port 80 (HTTP) and/or port 443 (HTTPS) to serve web traffic. You can allow these ports using the following commands:

For HTTP (port 80):

sudo ufw allow 80/tcp

For HTTPS (port 443):

sudo ufw allow 443/tcp

These commands allow incoming TCP traffic on ports 80 and 443, which are the default ports for HTTP and HTTPS traffic served by Nginx.

After running these commands, make sure to check the status of the firewall rules to ensure that they are correctly configured:

sudo ufw status

You should see the rules you've added, and they should be marked as "ALLOW." If everything looks correct, you can reload the firewall to apply the changes:

sudo ufw reload

Your PostgreSQL and Nginx services should now be accessible through their respective ports, and they are allowed through the firewall.

Deploying Django Project on an Ubuntu Server

Tonny Kirwa — Tue, 10 Oct 2023 10:35:37 +0000

Setting up a Django project on an Ubuntu server involves several steps. Here's a step-by-step guide to help you get started:

Connect to the Remote Server
Open your terminal and use the ssh command to connect to your remote server using the provided IP address and your SSH key. Replace ~/.ssh/id_rsa with the path to your private SSH key:

   ssh -i ~/.ssh/id_rsa ubuntu@ip_address

You should now be logged into your Ubuntu server.

Update Package List
It's always a good practice to update the package list on your server before installing new software. Run the following command to update the package list:

   sudo apt update

Install Nginx
Nginx is a popular web server that can serve as a reverse proxy for your Django application. Install Nginx using the following command:

   sudo apt install nginx

After the installation is complete, start the Nginx service and enable it to start at boot:

   sudo systemctl start nginx
   sudo systemctl enable nginx

By default, Nginx should be allowed through the firewall, but you can verify that it's enabled by running:

   sudo ufw allow 'Nginx Full'

Install PostgreSQL & Allow it via Firewall
If you intend to use PostgreSQL as your database, you can install it using the following command:

   sudo apt install postgresql postgresql-contrib

PostgreSQL should also be allowed through the firewall, but you can explicitly enable it:

   sudo ufw allow 'PostgreSQL'

To create a PostgreSQL database, assign a user to it, and grant all privileges, you can follow these steps:

Log in as the PostgreSQL Superuser

First, switch to the PostgreSQL user and open the PostgreSQL command line utility:

   sudo -u postgres psql

Create the Database

Once you are in the PostgreSQL shell, you can create a new database. Replace your_db_name with your desired database name and your_db_user with your desired username:

   CREATE DATABASE your_db_name;

Create a User and Assign to the Database

Create a user and set a password for it. Replace your_db_user and your_password with your desired username and password:

   CREATE USER your_db_user WITH PASSWORD 'your_password';

Next, grant the user privileges on the database. Replace your_db_name and your_db_user with your database name and username:

   GRANT ALL PRIVILEGES ON DATABASE your_db_name TO your_db_user;

This will grant the user full access to the specified database.

Exit the PostgreSQL Shell

To exit the PostgreSQL shell and return to the regular command line, type:

\q

You should now have created a PostgreSQL database, assigned a user to it, and granted that user all privileges on the database. Make sure to update your Django project's settings to use the correct database name, username, and password as configured in these steps.

Install Python and Virtual Environment
You'll need Python and a virtual environment for your Django project. Install Python and venv

   sudo apt install python3 python3-venv

Clone Your Django Project
You can clone your Django project repository from a Git repository or transfer it to the server using another method.

Set Up Your Django Project
Navigate to your Django project directory and create a virtual environment

   cd /path/to/your/django/project
   python3 -m venv venv

Activate the virtual environment:

   source venv/bin/activate

Install project dependencies:

   pip install -r requirements.txt

Configure Django Settings
Configure your Django settings to use the PostgreSQL database and other necessary configurations.

Collect Static Files
If your project serves static files using Django, collect them using the following command

    python manage.py collectstatic

Migrate Database
Apply initial database migrations

    python manage.py migrate

Test Your Application
Start your Django development server to test your application

    python manage.py runserver 0.0.0.0:8000

Configure Nginx for Django
Configure Nginx to serve your Django application. Create an Nginx server block (virtual host) configuration file for your site. You can create a new configuration file in /etc/nginx/sites-available/, or modify the default configuration. Make sure to configure Nginx to proxy requests to your Django application using the Gunicorn or uWSGI server.

Test Your Website
Test your website by accessing it through your domain or the server's IP address in a web browser.

Secure Your Site with SSL (Optional)
Consider securing your site with SSL using Let's Encrypt or another SSL certificate provider.

That's a general overview of the steps required to set up a Django project on an Ubuntu server. The specific details may vary depending on your project's requirements and configurations.