Forem: lutif

HOME: Dev productivity Extension, bring Arc to chrome

lutif — Mon, 02 Mar 2026 02:09:41 +0000

In today’s fast-paced digital world, productivity is often lost in a sea of browser tabs, scattered notifications, and endless context switching. Developers, designers, and knowledge workers constantly juggle GitHub pull requests, Slack messages, Google Calendar events, and more—each in its own silo. What if you could unify all these signals in one place, instantly, without ever granting access to your private accounts?

Introducing HOME: the first truly zero-auth Chrome extension that brings your digital workday together—securely, privately, and effortlessly.

🚀 What Makes HOME Innovative?

HOME isn’t just another productivity dashboard. It’s built on a radical, privacy-first principle: zero-auth. Here’s what sets it apart:

Zero-Auth, Zero Setup: No API keys. No OAuth. No connecting third-party accounts. HOME works by scraping data from the services you’re already logged into, right in your browser. You never have to grant access or share credentials—ever.
Unified Dashboard: See your GitHub PRs, Slack mentions, Google Calendar events, and more in a single, beautiful side panel. No more tab overload or missed updates.
Privacy by Design: All data stays local. HOME never sends your information to external servers. Your workflow is yours alone.
Arc-Style Workspaces: Organize tabs, links, and folders into customizable “spaces” with drag-and-drop, pinning, and themes—just like the best modern browsers.
Auto-Refresh & Live Updates: HOME quietly scrapes and updates your dashboard in the background, so you’re always up to date without lifting a finger.
Customizable & Open Source: Personalize each workspace with emojis, names, and color themes. As an MIT-licensed open source project, HOME is transparent and extensible.
🛠️ How Does Zero-Auth Work?
Traditional productivity tools require you to connect your accounts, hand over API keys, or trust third-party servers with your data. HOME’s zero-auth approach is different:
Local-Only Data Scraping: HOME injects lightweight scripts into the service pages you’re already using (like GitHub or Slack). It reads only what you see, processes it locally, and never transmits it elsewhere.
No External Servers: There’s no backend, no analytics, and no risk of data leaks. Everything happens on your device.
Instant Onboarding: Just install HOME, open the side panel, and your workspaces appear—no sign-ins, no permissions, no waiting.
🎨 Designed for Focus and Flow
HOME is more than functional—it’s designed for deep work:
Quick Actions: Pin tabs, create folders, and save workspaces with a click.
Bulk Management: Archive old tabs, manage groups, and keep your browser organized.
Beautiful Themes: Make each workspace your own with custom emojis, names, and colors.
🔒 Zero-Auth Means Zero Compromise on Privacy
With HOME, privacy isn’t an afterthought—it’s the foundation:
No Data Leaves Your Browser: All information is stored locally using Chrome’s secure storage.
No Tracking or Analytics: HOME doesn’t track your activity or usage patterns.
Open Source Transparency: Anyone can review, audit, or contribute to the code.

🌟 Try HOME Today

Ready to experience the future of browser productivity—without ever connecting your accounts? Here’s how to get started:

Download HOME from GitHub Releases.
Load as an Unpacked Extension in Chrome.
Open the Side Panel and see your unified, zero-auth dashboard in action.

Want to contribute or leave a star? Visit the GitHub repository and join the zero-auth productivity revolution!

Lutif / dev-home

developers

HOME - Chrome Extension

A productivity command center that brings GitHub PRs, Slack notifications, and Google Calendar into one unified side panel with Arc-style workspace management.

✨ Features

🎯 Unified Dashboard

GitHub PR Tracking: See all PRs requesting your review, your open PRs, and assigned issues
Slack Activity Feed: Monitor mentions and threads from your Slack workspace
Google Calendar: View upcoming events and meetings

🎨 Workspace Management

Multiple Spaces: Create unlimited workspaces with custom emojis and names
Custom Themes: Each space has 4 customizable colors (primary, background, surface, accent)
Designer Presets: 6 beautiful pre-made themes (Default, Ocean, Forest, Sunset, Rose, Purple)

📁 Organization

Pinned Items: Keep important tabs and links easily accessible
Folder System: Organize tabs and links into collapsible folders
Drag & Drop: Reorder items and folders with intuitive drag-and-drop

⚡ Productivity

Quick Refresh: Update all services with one…

View on GitHub

Stop Paying for Slack Alerts: Send Sentry Errors to Slack for Free

lutif — Fri, 13 Feb 2026 07:33:04 +0000

Tired of paying for Sentry’s Slack integration? Good news: you don’t have to.

With a simple setup using Sentry webhooks, Vercel Edge Functions, and Slack’s free API, you can receive real-time error notifications in Slack—without paying for a premium plan.

Here’s how to set it up.

Why Pay for What You Can Build?

Sentry’s built-in Slack integration sits behind a paywall. For indie developers and small projects, that cost often isn’t justified.

Instead, you can:

Use Sentry’s webhook integration
Catch events with a Vercel Edge Function
Send formatted messages using Slack’s free chat.postMessage API

Same result. Zero extra cost.

Step 1: Set Up the Sentry Webhook

Sentry provides a legacy webhook integration that sends event data to any external endpoint.

Open your Sentry project settings

Go to Legacy Integrations → Webhooks

Add a new webhook

(You'll paste your Vercel function URL here after deployment)

That’s it. Sentry will now send error events to your custom endpoint.

Step 2: Create the Vercel Edge Function

If you’re new to Vercel, it’s a serverless platform that runs code at the edge with a generous free tier.

We’ll create an Edge Function that:

Receives Sentry events
Formats them using Slack Block Kit
Sends them to Slack via API

Here’s the function:

export const config = {
  runtime: 'edge',
};

const sendMessage = async (
  channel,
  { level, formatted, environment, email, title, culprit, project }
) => {
  const isError = level === "error";

  const blocks = [
    {
      type: "section",
      text: {
        type: "mrkdwn",
        text: `${isError ? ":red_circle:" : ""} *${title}*`,
      },
    },
    {
      type: "section",
      fields: [
        { type: "mrkdwn", text: `*Environment:*\n${environment}` },
        { type: "mrkdwn", text: `*Level:*\n${level}` },
        { type: "mrkdwn", text: `*Project:*\n${project}` },
      ],
    },
    {
      type: "section",
      fields: [
        { type: "mrkdwn", text: `*User:*\n${email}` },
      ],
    },
    { type: "divider" },
    {
      type: "section",
      text: {
        type: "mrkdwn",
        text: `*Message:*\n${formatted}`,
      },
    },
    {
      type: "section",
      text: {
        type: "mrkdwn",
        text: `*Culprit:*\n${culprit}`,
      },
    },
    { type: "divider" },
  ];

  await fetch("https://slack.com/api/chat.postMessage", {
    method: "POST",
    headers: {
      "Content-Type": "application/json; charset=utf-8",
      Authorization: `Bearer ${process.env.SLACK_ACCESS_TOKEN}`,
    },
    body: JSON.stringify({
      channel,
      blocks,
    }),
  });
};

export default async (req) => {
  const body = await req.json();

  const {
    project,
    culprit,
    event: {
      level,
      logentry: { formatted },
      user: { email },
      environment,
      metadata: { title },
    },
  } = body;

  await sendMessage(process.env.CHANNEL_ID, {
    level,
    formatted,
    environment,
    email,
    title,
    culprit,
    project,
  });

  return new Response("Event received");
};

What This Does

Receives error events from Sentry

Formats structured Slack messages using blocks

Posts directly to Slack using an OAuth token

Step 3: Create and Configure Your Slack App

To allow Slack to receive messages:

Go to api.slack.com/apps

Create a new app in your workspace

Under OAuth & Permissions, add:

chat:write

Install the app to your workspace

Copy the OAuth Bot Token

Now add these environment variables in Vercel:

SLACK_ACCESS_TOKEN

CHANNEL_ID

Step 4: Deploy to Vercel

Push your code to GitHub

Import the repo into Vercel

Add your environment variables

Deploy

Once deployed, copy the function URL and paste it into your Sentry webhook settings.

Done.

Step 5: Test It

Trigger a test error in Sentry.

If everything is configured correctly, you’ll see a clean, structured error notification in Slack within seconds.

Why This Setup Wins

Completely Free
Real-time notifications
Fully customizable Slack formatting
Serverless and low maintenance
Works on Sentry’s free plan

You’re essentially recreating the paid integration—with more flexibility.

Grab the Code & Customize It

Feel free to adapt this setup for your own workflow:

Add severity filtering

Route different projects to different channels

Format alerts differently for staging vs production

If this helped you save money or level up your monitoring setup, leave a start and share it with other developers. Small optimizations like this make a big difference over time.

Check out the GitHub Repository Here

Happy building 🚀

Solving Unnecessary Rerenders in React with eventsync

lutif — Sun, 06 Jul 2025 09:30:52 +0000

If you’ve ever used React Context for global state management, you probably ran into this: updating one small value causes your entire app to rerender. Annoying, right? Especially when only one component needed the update.

Let’s break down why this happens and how eventsync fixes it using a simple, event-driven approach.

The Problem: Context Rerenders Everything

React Context is great for sharing global state, but it comes with a hidden cost. Imagine this setup:

context.tsx

import React, { createContext, useContext, useState } from 'react';

const AppContext = createContext(null);

export const AppProvider = ({ children }) => {
  const [counter, setCounter] = useState(0);
  const [user, setUser] = useState({ name: '', email: '' });

  return (
    <AppContext.Provider value={{ counter, setCounter, user, setUser }}>
      {children}
    </AppContext.Provider>
  );
};

export const useAppContext = () => useContext(AppContext);

Now, two components that use different parts of the state:

Counter.tsx

import { useAppContext } from './context';

const Counter = () => {
  const { counter, setCounter } = useAppContext();
  console.info('Counter rerendered');

  return (
    <button onClick={() => setCounter(counter + 1)}>{counter}</button>
  );
};

UserName.tsx

import { useAppContext } from './context';

const UserName = () => {
  const { user } = useAppContext();
  console.info('UserName rerendered');

  return <div>{user.name}</div>;
};

If you click the Counter button, both Counter and UserName rerender. But why?

React Context triggers a rerender for all consumers whenever the context value changes, even if the part they care about stayed the same.

This means:

✅ More rerenders than necessary
✅ Performance bottlenecks in large apps
✅ Frustrating debugging sessions

The Solution: eventsync

eventsync gives you global state without the Context rerender headaches. It uses good old DOM events to notify only the components that care.

Here’s the same example rewritten with eventsync:

App.tsx

import { initGlobalState } from 'eventsync';
import Counter from './Counter';
import UserName from './UserName';

initGlobalState({
  counter: 0,
  user: { name: '', email: '' }
});

function App() {
  return (
    <>
      <Counter />
      <UserName />
    </>
  );
}

Counter.tsx

import { useGlobalState } from 'eventsync';

const Counter = () => {
  const [{ counter }, { setCounter }] = useGlobalState(["counter"]);
  console.info('Counter rerendered');

  return (
    <button onClick={() => setCounter(counter + 1)}>{counter}</button>
  );
};

UserName.tsx

import { useGlobalState } from 'eventsync';

const UserName = () => {
  const [username] = useGlobalState('user.name');
  console.info('UserName rerendered');

  return <div>{username}</div>;
};

With eventsync:

✅ Updating counter only rerenders Counter
✅ UserName stays untouched
✅ No need to split context or build complex selectors

Why Use eventsync?

Fine-grained updates: Components subscribe to specific state fields

Cleaner code: No boilerplate splitting context for different consumers

Better performance: Fewer unnecessary renders

Zero context dependency: eventsync uses native DOM events under the hood

Final Thoughts

Tired of your whole UI rerendering when only one value changes? Give react-eventsync a try.

You get global state with precise, efficient updates, powered by DOM events. It’s a simple drop-in tool that keeps your app performant without extra complexity.

Curious to explore more? Check out the Getting Started guide and level up your global state management.

The project is open-source and available on GitHub:
🌟 https://github.com/Lutif/eventSync

If you find it useful, please give it a star
Want to follow my work? Follow on github to support my work. lutif

Customizing the user interface on Linux:

lutif — Sat, 10 Dec 2022 13:53:37 +0000

Linux allows users to customize their user interface in many different ways, giving them the ability to create a unique and personalized experience. In this tutorial, we will explore some of the options for customizing the user interface on a Linux system.

Choosing a desktop environment
The first step in customizing the user interface on a Linux system is to choose a desktop environment. A desktop environment is a collection of tools and applications that provide the user interface for a Linux system. There are many different desktop environments to choose from, each with its own look and feel. Some popular examples include GNOME, KDE, Xfce, and LXDE.

To choose a desktop environment, you can either install a Linux distribution that comes with a specific desktop environment, or you can install a desktop environment on an existing Linux system. To do this, you can use a package manager to search for and install the desktop environment of your choice.

Configuring the desktop environment
Once you have installed a desktop environment, you can start configuring it to your liking. Most desktop environments include a settings application that allows you to change various aspects of the user interface, such as the wallpaper, the color scheme, and the fonts. You can also change the layout of the desktop, the position of the panels and widgets, and the behavior of the windows and menus.

In addition to the settings application, many desktop environments also provide tools for managing the applications that are installed on the system. This can include things like the application launcher, the application menu, and the system tray. You can use these tools to customize the way that applications are organized and accessed on the system.

Installing and configuring a window manager
In addition to a desktop environment, Linux systems also allow users to install and configure a window manager. A window manager is a piece of software that controls the appearance and behavior of the windows on the desktop. Unlike a desktop environment, which provides a complete user interface, a window manager only manages the windows, leaving other aspects of the user interface up to the user.

There are many different window managers available for Linux, each with its own unique features and capabilities. Some popular examples include Openbox, i3, and Awesome. To install and configure a window manager, you can use a package manager to search for and install the window manager of your choice. Once it is installed, you can use its configuration files to customize its appearance and behavior to your liking.

Using a theme
Another way to customize the user interface on a Linux system is to use a theme. A theme is a collection of files that defines the appearance of the desktop environment and the window manager. A theme can change things like the color scheme, the fonts, the icons, and the cursors.

To use a theme on a Linux system, you first need to install the theme files. Most themes are available as packages that can be installed using a package manager. Once the theme is installed, you can use the settings application or the configuration files of the desktop environment or window manager to apply the theme.

Conclusion
Linux provides a wide range of options for customizing the user interface, allowing users to create a unique and personalized experience. By choosing a desktop environment, configuring the desktop environment and window manager, and using a theme, users can customize the look and feel of their Linux system to their liking. With the right tools and techniques, anyone can create a user interface that is tailored to their specific needs and preferences.

Using Git for version control in software development

lutif — Sat, 10 Dec 2022 13:47:41 +0000

Git is a popular version control system that is widely used in the software development process. It allows developers to track and manage changes to their codebase over time, making it easier to collaborate on projects and maintain a history of their work.

What is Git version control?
To use Git, developers first need to initialize a local repository on their own computer. This is done using the git init command, which creates a new directory where all the files and changes will be tracked. The repository can then be linked to a remote repository, such as one hosted on GitHub, using the git remote add command.

Using Git for collaboration in software development
Once the local repository is set up, developers can begin adding files to it using the git add command. This stages the files for commit, meaning they are ready to be saved to the repository. Developers can then use the git commit command to save the staged files to the repository, along with a message describing the changes that were made.

Git also allows developers to create branches, which are separate lines of development that can be worked on concurrently. This is useful for implementing new features or experimenting with different approaches to a problem without affecting the main codebase. To create a new branch, developers can use the git branch command, and then use the git checkout command to switch between branches.

Git also provides a number of tools for collaborating with other developers. For example, the git clone command allows developers to create a local copy of a remote repository, and the git push and git pull commands can be used to synchronize changes between the local and remote repositories. This makes it easy for multiple developers to work on the same codebase and share their changes with each other.

Conclusion
Overall, Git is an essential tool for managing the software development process. It allows developers to track and manage changes to their codebase, collaborate with others, and maintain a history of their work. By using Git, developers can work more efficiently and effectively, and can ensure that their projects are well-organized and easy to maintain.

Optimise CI to make sure your test run for only modules changed and save avoidable computation minutes

lutif — Fri, 02 Sep 2022 13:19:29 +0000

We all profess test driven development and we should. Sometimes pushing MVP to the market in certain time is important and we skip tests at all.

Whatever the case, write tests for your code as soon as you can.

But with huge code base, and good test means you will have hundreds if not thousands of tests to run. And all those tests could include some preparation computation before we execution and clean-up after it. There are separate strategies to optimise that much in-nutshell: tests could take a lot of time to run. Often we run those test for automatically at merge and pull requests.

That require a lot of compassion on cloud and hence cost you fortune.

Read about development pipeline strategies here.

Strategies to ship faster, and keep your development pipeline unblocked at scale

lutif ・ Sep 1 ・ 3 min read

#github #codequality #beginners #webdev

So, it would be better to run only test related to the feature changed, if its UI test run test for the concerned page, and not for something that stay unchanged.

Here we will see an example how to do that if you have your code hosted on Github and CI done via Github actions, but these strategies works for other tools too.

Lets, assume we are doing UI tests and our code is structured such that we have scr/pages folder that contains components for all pages eg: src/pages/register , there could be subdirs as well eg: src/page/register/shared, src/page/register/styles etc.

Now in your Github action where you run tests

Get files changed: For Github Actions you can use Changed Files action from action market place
Filter files from your pages directory, get pages names keep unique only, that's where you UI components are right?
Pass this list to whatever testing library/suit/runner you are using, be it JEST, playwright. Let your runner only run those test only.

Warning: If you have shared components which are used on multiple pages, make sure if there are any changes in those, run all tests to be sure you are not breaking anything.

Comment about your approach to tests and have you run into this issue of insane time to run tests.

Strategies to ship faster, and keep your development pipeline unblocked at scale

lutif — Thu, 01 Sep 2022 11:43:18 +0000

When your team size grow, you start seeing a lot of merge conflicts. Few people are making changes on same files, you have this big feature to ship, should you let smaller PRs related it to be merged on staging so other dev working on that feature can use that piece of code. Someone is blocked because someone else is working on a module that's needed. You can't even think of refactoring causing so many people are making changes on those parts of codebase.

Well that chaos is worth the diving deep. Let's first see what's very common developing flow, here I might be referring github once a while but these strategies works with any other alternatives too.

Mostly you have this master/main branch - github create this by default when you create a repo - this should be your single source of truth any code merged to this branch should be tested well and have no any know bugs. This should be your production code, all CI/CD should be automated for this branch at least.

Next is your dev/staging branch, its good practice to have an intermediary stage between your development and your production code. Often this branch is also deployed to some staging deployment so devs/QA can test on real production environment. You merge your branch into this staging branch and once a while rollout to production by merging this staging branch into master/main, often these rollouts are scheduled but frequency depends on team size and the development acceleration. Better to do smaller rollout to minimise bugs and impact they can have on users. But on other hand rollout means new deployments on production which might cause some disturbances - new instances of app could cause inflight request canceled, or delay in page loads etc - you find a good balance for your team here.

It is important to keep staging and master in sync, and merge only staging branch to master no other branches or direct commits to master.

Trunk vs Atomic branches

Normally you branch out from staging create a feature branch, you make changes, raise a pull request and once reviewed and approved by others you merge it. But what if you have to work on a bigger feature, multiple other devs will also be working , you might be experimenting and different implementations for that feature, You can't create once big branch let many people push their commits in it, it will raise conflicts. You might just want to work on your part and let others create separate PR and work on their part but what if they need some of your code too. You both need one utility function to make your code work.

Their is a development strategy to make this easier, often referred as Trunk-based development . So now you create a trunk branch, which will have all changes related to that specific feature.let's say you are adding login with Google feature to your website. You can create a trunk branch, and dev's branch out from this branch to work on their individual tasks. Once their atomic branches are reviewed and approved, they get merged to this trunk branch and when you have this feature ready and tested you merge your trunk branch into staging, and rollout. Often these trunk branches are deployed too to make it easy for non-dev team to test it experience it.

Next we will talk about testing and how to optimise CI to make sure your test run for only modules that are changed in the PR and not all tests as that might slow down your development and cost you avoidable computation minutes.

How to write a scalable router for express in nodejs.

lutif — Sun, 06 Sep 2020 07:19:28 +0000

I have been looking for a good way to handling routing in MERN project, scalable and robust router, there were many articles but somewhat confusing for beginners so I decided to simplify it for and what else could be a good topic for the first article at dev.to.

Here we will assume we are working on a large project that provides API to front-end with a bunch of routes.

let's dive in

1. Create a folder in root directory

I prefer it naming routes, ofcourse you can name anything you like

~/routes

2. Create root router

Now, that we have a folder to hold all of our routes, we can have the root router in it. Create a router.js file in the ~/routes folder.

3. Create and export the router

const express = require("express"); 
const router = express.Router();
const subRouters = []; //will get subRouters soon
router.use(subRouters);
module.exports = router;

Now you can import this router in your main file and let express use it.

4. Creating sub routers

In the ~/routes folder create more folders according to your need; for demo I will create a couple of folders

~/routes/auth ~/routes/profile ~/routes/chat

create routers in subfolders accordingly, for example, ~routes/auth could have login.js and register.js.
Here ~/routes/auth/register.js

const express = require("express"); 
const router = express.Router();


router.post(
  "/api/users",
  async (req, res) => {

 //your logic here 
}
module.exports = router;

5. The Fun part- telling your root router to look for subRouters

Now that we have a couple of routers in subfolders -there can be as many as you want- we tell our root router to import them. Importing them manually one by one could be tedious also if we add any subRouter in the future we would have to come back to root router again and take care of it manually.

Import file system and path module we will use them to look take a look in the directory.

const fs = require("fs");
const path = require("path");

Now let's get subroutes, we are defining here an empty array to hold all imported subRoutes and a function getAllSubroutes given a directory to this it will look for all files in the directory and import them in subRoutes array,

const subRouters = [];
const getAllSubroutes = (dir) => {
  fs.readdirSync(dir).forEach((file) => {
    const fullPath = path.join(dir, file);
    if (fs.lstatSync(fullPath).isDirectory()) {
      getAllSubroutes(fullPath);
    } else {
      if (fullPath !== __filename) {
        subRouters.push(require(fullPath));
      }
    }
    return subRouters;
  });
};

if it come across a directory it will search it recursively - take note

if (fs.lstatSync(fullPath).isDirectory()) { getAllSubrouts(fullPath);

incase you are wondering forEach is builtin array function works similar to for loop. Also , notice in else block we check if (fullPath !== __filename) this ensure we do, not import rootRouter into itslef .

6. Call `getAllSubroutes`

Next, we put our function to work, call it with argument of __dirname; this is global property available in every file pointing to its directory.
now your ~routes/rootRouer/router.js should look like this.

//root router

const express = require("express");
const fs = require("fs");
const path = require("path");

const router = express.Router();

const subRouters = [];
const getAllSubroutes = (dir) => {
  fs.readdirSync(dir).forEach((file) => {
    const fullPath = path.join(dir, file);
    if (fs.lstatSync(fullPath).isDirectory()) {
      getAllSubroutes(fullPath);
    } else {
      if (fullPath !== __filename) {
        subRouters.push(require(fullPath));
      }
    }
    return subRouters;
  });
};

 getAllSubroutes(__dirname)
router.use(subRouters);

module.exports = router;

Now, we can add or remove as many routes according to our needs, without requiring us to change anything else.
This is off-course one of the preferred ways, let me know in the comments what do you think about this method?
Thanks for reading!😊

Forem: lutif

HOME: Dev productivity Extension, bring Arc to chrome

Introducing HOME: the first truly zero-auth Chrome extension that brings your digital workday together—securely, privately, and effortlessly.

🚀 What Makes HOME Innovative?

🌟 Try HOME Today

Lutif / dev-home

developers

HOME - Chrome Extension

✨ Features

🎯 Unified Dashboard

🎨 Workspace Management

📁 Organization

⚡ Productivity

Stop Paying for Slack Alerts: Send Sentry Errors to Slack for Free

Why Pay for What You Can Build?

Step 1: Set Up the Sentry Webhook

Step 2: Create the Vercel Edge Function

Step 3: Create and Configure Your Slack App

Step 4: Deploy to Vercel

Step 5: Test It

Why This Setup Wins

Solving Unnecessary Rerenders in React with eventsync

Customizing the user interface on Linux:

Using Git for version control in software development

Optimise CI to make sure your test run for only modules changed and save avoidable computation minutes

Strategies to ship faster, and keep your development pipeline unblocked at scale

lutif ・ Sep 1 ・ 3 min read

Strategies to ship faster, and keep your development pipeline unblocked at scale

Trunk vs Atomic branches

How to write a scalable router for express in nodejs.

let's dive in

1. Create a folder in root directory

2. Create root router

3. Create and export the router

4. Creating sub routers

5. The Fun part- telling your root router to look for subRouters

6. Call getAllSubroutes

6. Call `getAllSubroutes`