## From a page element to useful context

Describing a small part of a web page to an AI agent can mean switching between the browser, developer tools, and a prompt. Element Lens brings the rendered element and its surrounding context into one clipboard capture.

The extension runs in Chrome and Edge. Click its toolbar action to enter pick mode, hover over an element to see its outline and label, then click to copy the context. Escape cancels the selection. The picker closes after a capture and shows whether the clipboard write succeeded.

## What the capture contains

The output is a Markdown bundle with four sections:

- **Selected HTML:** a bounded copy of the element's markup, with form values and sensitive-looking attributes redacted.
- **Computed styles:** values for layout, spacing, typography, color, borders, and other selected CSS properties.
- **Nearby DOM context:** an ancestor path and short descriptions of the selected element and adjacent siblings.
- **JavaScript clues:** the element's tag and available role, ARIA, data, and inline event attributes.

These clues describe what the browser exposes. The capture does not recover authored stylesheets, general event-listener code, or framework state. Large or deeply nested markup is truncated to keep the bundle focused.

## A small extension with local capture

The implementation uses plain JavaScript and Manifest V3. A service worker handles the toolbar action and injects the picker into the active tab. The picker places its outline and label in a shadow root, then removes its listeners and overlay when selection ends.

The manifest requests `activeTab`, `scripting`, and `clipboardWrite`. The capture code writes to the clipboard and does not transmit the bundle to a server. Redaction covers form values and attributes with names that suggest credentials or secrets; visible page text remains in the output and should be reviewed before sharing.

## Scope and current stage

Version 0.1.0 includes the extension shell, the one-shot picker, and a packaged ZIP for local installation through the browser's **Load unpacked** option.

Selection operates in the top-level page. An embedded frame is captured as a frame element rather than inspected internally. Open shadow-root content can be selected when exposed through pointer events; closed shadow roots are represented by their hosts. Browser-internal and protected pages cannot be inspected, and the toolbar indicates when the picker is unavailable.

The case study reflects the [published 0.1.0 source snapshot](https://github.com/Alaa-Taieb/element-lens/tree/9df3cac32f9f90da112bb718ae26d79b5fbb8579). See the [repository README](https://github.com/Alaa-Taieb/element-lens#readme) for installation instructions and current capture limits.

A Chrome and Edge extension that turns a selected page element into context for an AI agent.

Element Lens

## A mission-control view for a short Reel

I built Artemis II Mission Tracker as a one-off project for an Instagram Reel. The idea was to make the mission’s path the center of the screen: Orion travels along a luminous route while Earth, the Moon, and a compact control-room interface give that motion some context.

The main scene shows the spacecraft moving between Earth and the Moon, with its trajectory and the Moon’s orbit drawn around it. A heads-up display adds the mission phase, elapsed time, velocity, distances, and progress. It is designed to read as a visual simulation rather than a general-purpose flight-planning tool.

## Make the trajectory explorable

The controls let viewers change the camera target, switch between 3D orbit and 2D map views, pause the timeline, scrub to another point, or speed the simulation up to 10,000×. These controls make the route legible at different scales and give the scene a little more life than a fixed animation.

The displayed positions come from bundled ephemeris data. The app interpolates the stored Orion and Moon vectors as the simulation clock advances; the “LIVE” control syncs that clock to the configured timeline. The page’s live-style telemetry is therefore simulated, not a feed from an operating spacecraft.

## Building the scene

I built the interface with Next.js, React, and TypeScript. React Three Fiber and Three.js render the Earth, Moon, Orion, orbit, and trajectory, while Drei and postprocessing add scene controls and glow. Framer Motion brings the heads-up display in, and Tailwind CSS handles its responsive layout and dense readouts.

Keeping the 3D view behind the interface let the project feel like a small mission console, while the timeline and focus controls gave the main visual a clear way to respond. That balance was the useful constraint for a project made specifically to appear in one Reel.

## View it

- [Open Artemis II Mission Tracker](https://artemis-2-tracking.vercel.app)
- [Watch the Instagram Reel](https://www.instagram.com/p/DWpIgm9kb_Z/?hl=en)

A cinematic mission simulator that traces Orion’s route around the Moon through a 3D scene and a compact control-room interface.

Artemis II Mission Tracker

## A tiny calendar brain game

What day of the week was August 8, 2088? This little trainer teaches John Conway’s Doomsday Rule, a mental method for answering questions like that without checking a calendar.

There are two ways in: **Learn** walks through the method, and **Practice** throws out random dates for quick timed rounds. Get one right and keep the streak going; miss one and the game shows how the answer was worked out.

## How the date trick works here

The calculation is broken into friendly chunks: find the century’s anchor day, work out the year’s Doomsday, use the month’s anchor date, then count to the date you were given. In practice mode, the game reveals each part after an answer, so a wrong guess still teaches you something.

## Why I made it

I made this as a playful build for one of my Instagram videos. It is a small, self-contained experiment: learn a surprisingly useful mental trick, then see how quickly you can do it. No grand calendar platform here—just dates, a timer, and the satisfaction of getting a weekday right in your head.

## Under the hood

The app is built with Next.js, React, and TypeScript. The date calculation lives in a small standalone module, which returns both the weekday and the intermediate values used to reach it. That breakdown powers the explanations in the learning and practice flows.

## Try it

- [Play Doomsday Game](https://doomsday-game-pi.vercel.app)
- [Watch the Instagram video](https://www.instagram.com/p/DXA0luXkWLd/?hl=en)

A playful little trainer for learning Conway’s trick for finding the day of the week for any date.

Doomsday Game

## Why I built Tunic Desktop

I built Tunic Desktop around a question I keep coming back to: what would an AI assistant look like if it could help with ongoing desktop work, instead of stopping at a chat reply? I wanted the project to bring conversations closer to the things they are about—files, code, research, and plans—while keeping model choice and local project data in the user's hands.

That direction is visible in the product's shape. Tunic is an Electron desktop app with streamed conversations, project spaces, planning tools, and a permission-aware tool system. I see the central challenge as connecting those capabilities without turning the assistant into an opaque process with unrestricted access to the machine.

## One conversation layer, multiple model providers

I did not want the chat experience to depend on a single model service. Tunic has a provider layer that supports local inference through LM Studio and vLLM, as well as hosted services including OpenRouter and Google AI. Other adapters are present in the codebase too. A shared provider contract gives the conversation pipeline a consistent way to send requests, stream responses, and handle tool calls across those integrations.

That separation matters to me because provider choice affects how someone wants to work: a local model server and a hosted API have different setup and operating needs, but they can still fit the same desktop workflow. Streaming keeps generated responses visible as they arrive. The interface can then move from a response into an action when the model requests an available tool.

## Useful tools with explicit boundaries

Tunic's tool workflow can support multi-step work with capabilities for files, Git, search, web access, and code analysis. A permission setting controls whether actions run automatically, require approval, or are disallowed. I consider that boundary part of the product itself. If an assistant can act on a project, the user needs a clear way to decide how much authority it has.

Under the hood, a tool loop coordinates the model and tool results, while a registry connects requests to built-in tools. The architecture documents more than 50 built-in tools, along with skills and plugins that extend the system. My focus here is not simply to give a model more actions; it is to make tool use part of a workflow whose access rules the user can understand and control.

## Connecting chat to project work

I also wanted Tunic to have a place for work that continues after a conversation ends. Project spaces include Kanban-style tasks, notes, and documents alongside chat. This lets the assistant sit near the context of a project rather than in a separate, disposable thread. The app's context pipeline can bring relevant information into a conversation, and its architecture includes context compaction for longer sessions.

This is one of the choices that makes Tunic feel like a workspace to me, rather than only an interface for trying different models. The project system and chat system share the same desktop environment and local data store, so planning and assistant conversations can belong to the same body of work.

## Voice input and local-first data

I added a voice path using Transformers.js and the Whisper Tiny English model. The transcription pipeline loads when it is first needed, then converts audio chunks into text for the conversation. It gives Tunic another way to start an interaction without changing the rest of the chat workflow.

Conversations and project records are persisted in SQLite through `better-sqlite3`. Local persistence is an important part of the direction I chose: the desktop app keeps its workspace data on the user's machine, while model inference can connect to a configured local server or hosted provider. That distinction lets Tunic offer provider flexibility without treating the workspace database as a remote service.

## How I structured the desktop app

I built the interface with React and TypeScript inside Electron, but kept the renderer isolated from operating-system access. The renderer is sandboxed and does not get direct Node.js access. It talks to the Electron main process through a controlled `contextBridge` and IPC API; the main process handles privileged work such as database and system operations.

That process boundary is one of the most important technical decisions in the project. It lets me use web technologies for the interface while keeping local capabilities behind an explicit bridge. Zustand manages frontend state, Tailwind CSS styles the interface, and Vite with `electron-vite` supports the desktop development and build workflow.

## What this project represents to me

For me, Tunic Desktop is an exploration of what a practical AI workspace needs around the model itself: provider choice, relevant project context, tools that can act, and boundaries for those actions. The work is in making those parts cooperate inside one application, while leaving the user able to understand where data lives and what the assistant is allowed to do. That is the product direction I am building toward with Tunic.

I built Tunic Desktop as a local-first AI workspace that brings streamed chat, flexible model providers, permission-aware tools, and project planning together.

Tunic Desktop

## Overview

Open-Codemap is a local-first, open-source codebase indexer and retriever for AI-assisted development. It is designed to return relevant code context without sending a whole repository into a prompt.

## How it works

- Parses repositories with tree-sitter and splits code into structural units such as functions and classes.
- Stores workspace data locally in SQLite.
- Combines semantic, keyword, and code-relationship signals to retrieve relevant code.
- Can be used as a TypeScript library, command-line tool, or HTTP API.

## Technical notes

The repository is MIT-licensed. Its README documents a mock embedder for deterministic local use, as well as optional embedding providers. See the repository for setup instructions and current implementation details.

A local-first codebase indexer and retriever that helps AI agents find relevant code.

Open-Codemap

## Overview

TunisiaKit is an open-source TypeScript toolkit for common Tunisian data tasks. It brings validation and formatting helpers together with regional reference data, so developers do not have to rebuild those utilities in each project.

## What it includes

- Validation helpers for identifiers and local data such as CIN, RIB, IBAN, phone numbers, and postal codes.
- Formatters for phone numbers, IBANs, and currency, including Arabic-friendly output.
- Reference data for governorates, delegations, banks, and regions.

## Technical notes

The package is written in TypeScript, has no runtime dependencies, and is published on npm as [tunisia-kit](https://www.npmjs.com/package/tunisia-kit). See the repository for the complete API and usage examples.

A TypeScript toolkit for validating and formatting Tunisian data, with local reference data for developers.

TunisiaKit

## Overview

I built this French-language website for CK-CEE, a company presenting energy-renovation solutions to businesses. The site brings together explanations of professional LED lighting, floating high-pressure control, and air destratification, alongside financing information and a guided CEE estimate.

## Making a technical subject easier to approach

The estimate flow guides a visitor through project details before showing an indicative result and offering a way to request a tailored study. The site explains that the estimate is not final; a technical review confirms the eventual amount. That distinction matters in a subject where eligibility depends on the kind of work and its technical context.

The repository includes the simulator implementation, its project-specific inputs, and reference data used to calculate an initial estimate. The live site gives the tool context through solution pages, a financing explanation, and contact paths.

## My perspective

The funny part of this project was how much research sat behind what looks like a straightforward company website. I found myself looking up French energy law and reading dozens of documents to understand the CEE rules well enough to shape the site's explanations and simulator. That domain research became part of the product work: the visitor needs a clear first step, while the site still has to present the result as an estimate rather than a legal or technical determination.

## Technology

The site is built with Next.js, React, TypeScript, and Tailwind CSS. I kept this portfolio entry at a high level because the source repository is private client work; it describes the visitor experience without publishing implementation or operational details.

A client website for CK-CEE that explains CEE-backed energy renovation and guides French businesses through an initial eligibility estimate.

CK-CEE Website

## A direct path from an ad to a stay

I built Djerba Maison Location from the ground up with a specific purpose: make it straightforward to turn interest from Meta ads into bookings. The product brings together a public rental website and a private management app for an apartment in Midoun, Djerba. Visitors can explore the property, check their dates, understand the price, and send a request directly to the owner.

That purpose gives the website a clear job. Someone arriving from an ad needs enough information to decide whether the apartment suits their stay, followed by an obvious next step. The public experience connects those two parts: showing the accommodation and making it easy to ask for it.

## Show the apartment, then make the next step clear

The homepage leads with the apartment's private terrace, a property photograph, and date selection. Further down, visitors can explore room photos, sleeping arrangements, amenities, location information, and frequently asked questions. The gallery lets them browse by room rather than relying on a single cover image.

These details give the date check context. A visitor can see what is offered before entering their arrival, departure, and number of guests. Calls to action throughout the page return to the same booking flow, while direct contact options provide another way to ask a question.

## From dates to a booking request

The date check shows an indicative availability response and a breakdown of the stay price. When a request can proceed, a form collects the guest's contact details, preferred contact language, and an optional message.

The site makes the handoff explicit: sending a request does not confirm a reservation, and no payment is required at that stage. The owner reconfirms availability and communicates the next steps. This keeps the website's promise aligned with how the stay is actually arranged, while still giving an interested visitor a concrete action to take.

## French and Arabic, including on a phone

The public site is available in French and Arabic, with a right-to-left layout for Arabic. Switching languages preserves the selected stay dates and guest count, so visitors can continue the same enquiry in the language they prefer.

On a narrow screen, the date controls and property information stack into a mobile layout. For a journey that starts in a social feed, having the booking path available on a phone is part of the core experience.

## Support the booking after the click

Behind the public website, the owner has a private workspace for enquiries, reservations, a calendar, and day-to-day rental management. The project therefore covers both sides of the journey: helping a visitor request a stay and giving the owner a way to handle that interest.

The public site also offers a choice about advertising measurement, and declining it leaves the booking flow available. The overall product stays focused on the same purpose I started with: a straightforward route from interest in an ad to a stay arranged directly with the owner.

[Explore the live website](https://dar-jerba.online/).

A bilingual rental website and booking management app, built to give visitors arriving from Meta ads a straightforward path from discovering an apartment in Djerba to requesting a stay.

Djerba Maison Location

## Overview

Wasael is a messaging and sales workflow product for Tunisian e-commerce teams. It is designed to bring customer conversations from major messaging channels into one shared workspace and connect them with lead follow-up and order progress.

## Product focus

The project brings together a unified inbox and a sales workflow, with supporting views for follow-up and reporting. The goal at the product level is to help a team keep conversations and the next step in view as a customer moves from an initial question toward an order.

## My approach

I chose to present Wasael as a product-level teaser. The source project is private, so this entry explains the product purpose without exposing customer records, operational details, or internal security and integration design.

## Technology

The application is built with Next.js, TypeScript, and Tailwind CSS. This entry shares only a small part of the project’s technical context; it does not publish the private source repository or implementation details.

A messaging and sales workflow product for Tunisian e-commerce teams, bringing customer conversations and follow-up into one workspace.

Wasael

## A request that needed a closer definition

I took on this freelance project to build a tool around a client's request to turn a 2D drawing into a detailed 3D model without losing information. The initial brief was vague, so I first approached it as a visualization and comparison problem. As we worked through what the output was expected to contain, the central constraint became clear: the supplied 2D drawing did not include the metadata and design information needed to reconstruct the requested 3D detail reliably.

A 2D drawing can show outlines, dimensions, and annotations, but it does not necessarily encode what each element represents or how it should become a 3D object. Where that information is absent, software cannot recover the original design intent just by viewing the lines. Several rounds of discussion were needed to make that boundary clear. The project became as much about aligning expectations with the source data as it was about implementing the viewer.

## Build a review workflow around the available files

The prototype accepts a 2D drawing and a 3D model as separate inputs, uploads them to Autodesk Platform Services, waits for translation, and stores a comparison record. The supported upload controls cover DWG and PDF drawings plus RVT and IFC models. Progress updates keep the user informed while the files are uploaded and processed.

Once ready, the results page opens the drawing and model in separate Autodesk viewers side by side. That provides a practical way to inspect both files in one place. It does not create a 3D model from the drawing, preserve unseen details, or establish that the two files match. The source also contains comparison-history screens and a service placeholder for analysis; automated element matching and detailed difference reports are not implemented in this snapshot.

## Implementation

I built the client with React, React Router, Material UI, and React Query. An Express server handles file uploads, Autodesk Platform Services authentication and model translation, progress updates over WebSockets, and saved comparison records in MongoDB. Keeping the viewer workflow focused on translation and side-by-side inspection made the prototype useful within the limits of the available inputs.

My main lesson was to clarify the source data and the expected output before treating a request as a straightforward conversion feature. For this kind of work, the feasibility discussion is part of the engineering: it determines what can be automated, what needs richer model data, and what the tool can honestly promise.

## Source

- [View the project repository](https://github.com/Alaa-Taieb/2D-3D-Model-Visualization-using-Autodesk-APS-API)

A freelance prototype for uploading and viewing a 2D drawing beside a 3D model, and a lesson in the information required to turn drafting geometry into a detailed model.

2D and 3D Model Review with Autodesk APS

## Overview

Flux Convert is a browser-based file conversion app. Its public catalog lists 254+ conversion types across nine categories. The product offers format detection, multi-file conversion, and ZIP downloads.

The catalog covers image, audio, video, document, data, developer, subtitle, font, and other conversions. The live product describes its workflow as browser-based; this case study focuses on the public catalog and workflow rather than making independent privacy or capacity guarantees.

## Key Features

- **Public conversion catalog:** 254+ conversion types across nine categories.
- **Format discovery:** Search the catalog and open a converter for a supported format pair.
- **Batch workflow:** Select multiple files and download converted results together as a ZIP.
- **Format detection:** The product describes automatic input detection and compatible converter suggestions.

## Technical Stack

The product describes a browser-based workflow and lists WebAssembly and Canvas APIs in its technical overview:

- **WebAssembly (WASM):** Listed by the product as part of its browser-based conversion stack.
- **Canvas APIs:** Listed by the product for image operations.

## Conversion flow

```mermaid
flowchart TD
    A[Choose files] --> B[Detect input format]
    B --> C[Choose a listed output format]
    C --> D[Convert]
    D --> E[Download files]
    D --> F[Download a ZIP]
```

## Portfolio Highlights

- **Catalog:** The public formats page lists 254+ conversion types across nine categories.
- **Workflow:** The live product exposes format search, automatic input detection, batch conversion, and ZIP export.

## Links

- [Live Site](https://flux-convert.xyz)

A browser-based file conversion app with a public catalog of 254+ conversion types across nine categories, format detection, batch conversion, and ZIP downloads.

Flux Convert

**LLM Web Interface**

A sleek and powerful web application I developed to provide a seamless interface for interacting with Large Language Models, specifically integrated with **Groq's** high-speed APIs.

This project was a great opportunity to explore real-time data streaming and robust full-stack development. It features a modern tech stack centered around **React**, **Node.js**, and **MongoDB**, with a strong focus on security and a dynamic user experience.

---

**🚀 Key Features & Highlights**

- **Blazing-Fast Response Streaming:** Utilizes server-sent events (SSE) to deliver a fluid, token-by-token response from the LLM, making the conversation feel instantaneous and natural.
- **Robust Security:** Implements a custom, encrypted system for managing Groq API keys, ensuring user data is secure. This is complemented by a **JWT authentication** system with Google OAuth for hassle-free sign-in.
- **Intuitive & Rich Interface:** The chat interface supports full **markdown rendering** with syntax highlighting for code blocks, providing a clean and professional display of LLM responses.
- **Modern Design:** Built with **Material UI (Joy)**, the application is fully responsive and adapts flawlessly across all devices.

---

**💻 Technical Stack**

The project is built on a robust MERN-like stack, with a clear separation between the frontend and backend.

**Frontend**

- **React.js:** Used with the Context API for efficient state management.
- **Material UI Joy:** Provides a beautiful and responsive component library.
- **Real-time Streaming:** Manages the incoming token stream from the backend.

**Backend**

- **Node.js & Express.js:** A RESTful API serves as the core of the application.
- **MongoDB:** The NoSQL database handles user and API key data.
- **JWT & Google OAuth:** Manages secure user authentication and sessions.
- **Groq API:** Handles all LLM interactions with streaming support.

---

**🛠️ Project Architecture**

This diagram illustrates how the different components of the application communicate to provide a seamless experience.

```mermaid
graph TD
    A[React Frontend] -->|JWT Auth| B[Express Backend]
    B --> C[MongoDB]
    B -->|Streaming| D[Groq API]
    A -->|SSE| B
```

---

**🔬 Technical Deep Dive**

**Real-time Message Streaming**

Here's a glimpse into how the backend streams responses from the Groq API to the frontend.

```javascript
const stream = await groq.chat.completions.create({
  messages: apiMessages,
  model: "llama3-70b-8192",
  stream: true,
})

for await (const chunk of stream) {
  const content = chunk.choices[0]?.delta?.content || ""
  // Logic to send content to the client via SSE
}
```

**Secure Key Encryption**

The API key management system uses encryption to protect sensitive user data before it is stored in the database.

```javascript
// A simplified example of the encryption process
const encrypted = crypto.encrypt(apiKey)
await ApiKey.create({
  user: userId,
  key: encrypted,
  name: keyName,
})
```

---

**🚀 How to Run the Project**

You can get this project up and running with a few simple commands.

1.  **Clone the repository:**

    ```bash
    git clone https://github.com/Alaa-Taieb/LLM-Web-Interface.git
    ```

2.  **Install dependencies:**

    ```bash
    # Frontend
    cd client && npm install

    # Backend
    cd server && npm install
    ```

3.  **Set up environment variables:**
    - Create a `.env` file in both the `client` and `server` directories with the variables listed in the original project description.

4.  **Start the servers:**

    ```bash
    # Frontend
    cd client && npm start

    # Backend
    cd server && npm run dev
    ```

Chat interface for Groq LLMs with streaming & secure key management.

LLM Web Interface

## Overview

A production-ready admin interface to manage a personal blog: posts, tags, and content relationships. Built with Next.js App Router, TypeScript, Supabase, React Query, Tailwind, and shadcn/ui. It features a Monaco-powered Markdown editor with live preview, robust form validation (Zod + React Hook Form), and a clean, responsive UI.

- Monorepo path: `blog-admin/`
- App Router with API routes under `src/app/api/*`
- Data storage with Supabase (PostgreSQL)
- Realtime-friendly patterns and React Query caches
- Strict TypeScript for reliability

## Architecture

- Next.js 15 (App Router) with Turbopack for fast builds and dev.
- UI: Tailwind CSS + shadcn/ui (Radix primitives) for accessible components.
- State/Data: React Query for fetching, caching, and optimistic flows.
- Forms: React Hook Form with Zod schemas in `src/lib/validations.ts`.
- Database: Supabase client (`src/lib/supabase.ts`) and queries (`src/lib/queries.ts`).
- Editor: Monaco Editor wrapped in `MarkdownEditorWithPreview` for edit/preview/split modes.
- Types and hooks organized under `src/types` and `src/hooks`.

Directory highlights:

- `src/app/` – pages and API routes (posts, tags, stats)
- `src/components/ui/` – reusable UI components (button, card, dialogs, editor)
- `src/lib/` – supabase client, queries, utilities, validations
- `src/hooks/` – typed React Query hooks

## Data model

Tables managed:

- `posts` – title, slug, summary, content_md, draft, publish status, cover image, timestamps
- `tags` – label, slug, usage counts
- `post_tags` – many-to-many between posts and tags

## Features

- Posts and tags CRUD with React Query for smooth UX
- Monaco Markdown editor with:
  - GFM support (tables, task lists) via `remark-gfm`
  - Syntax highlighting via `rehype-highlight`
  - Live preview and split view
  - Sensible defaults (word wrap, line numbers, automatic layout)
- Form validation with Zod schemas and error messaging
- Responsive layouts with proper overflow management
- Optimized tables (column sizing, no horizontal scrolls)

## Editor experience

We consolidated editor usage into a single `MarkdownEditorWithPreview` component to ensure consistent behavior and layout across the Create and Edit flows. Issues like height shrinkage in dialogs were addressed using:

- Parent flex containers with `min-h-0` and explicit heights where needed
- Avoiding percentage heights within complex dialog flex trees
- Fallback to textarea if Monaco fails to mount within a set timeout

## Performance & build

- Dev startup: ~1–2s (Turbopack)
- Lint: ~3s
- Build: ~25–30s
- Shared bundle: ~135KB

These values are from local runs and can vary by machine.

## How to run

Prereqs: Node.js LTS and a Supabase project.

1. Install deps

```powershell
cd "blog-admin"
npm install
```

2. Configure environment

Create `blog-admin/.env.local` from example and set Supabase keys:

```powershell
Copy-Item .env.example .env.local
# Then edit .env.local and fill:
# NEXT_PUBLIC_SUPABASE_URL=your_supabase_project_url
# NEXT_PUBLIC_SUPABASE_ANON_KEY=your_supabase_anon_key
# SUPABASE_SERVICE_ROLE_KEY=your_supabase_service_role_key
```

3. Dev server

```powershell
npm run dev
# App at http://localhost:3000
```

4. Lint & build

```powershell
npm run lint
npm run build
```

Notes:

- Without Supabase credentials, UI loads but data ops return 500s (expected).

## Challenges & solutions

- Markdown rendering inconsistencies → standardized ReactMarkdown config with GFM + highlight plugins and custom component styling.
- Dialog/editor height issues → unified container strategy with `min-h-0`, explicit pixel heights where appropriate, and a single editor component.
- Table overflow in posts list → column sizing and layout tweaks to remove the bottom scrollbar.

## Future work

- Role-based auth and access control
- Media manager for cover images
- Draft autosave and version history
- MDX support for richer content blocks
- End-to-end tests (Playwright) and unit tests for API routes

## Attribution

- UI primitives by Radix via shadcn/ui
- Markdown highlighting via highlight.js themes
- Icons by Lucide React

A modern Next.js + Supabase admin app to manage personal blog posts, tags, and content with a Monaco-powered Markdown editor and live preview.

Personal Website Management – Blog Admin

## Overview

Boura Flower Shop is a responsive e-commerce website designed to showcase and sell a curated selection of floral arrangements and related products. The platform aims to provide a seamless and visually appealing online shopping experience for customers looking to purchase flowers for various occasions. It offers detailed product information, a streamlined browsing process, and an intuitive shopping cart functionality.

## Key Features

- Dynamic product catalogue with filtering and searching capabilities.
- Detailed product pages displaying images, descriptions, and pricing.
- Interactive shopping cart for managing selected items.
- Responsive design ensuring optimal viewing across all devices.
- Visually engaging hero section and product cards for an attractive presentation.
- Multi-language support for a broader customer reach.
- Optimized for performance with fast loading times.

## Technical Stack

The project is built using React and Vite, leveraging Tailwind CSS for utility-first styling to ensure a consistent and modern UI. The architecture follows a component-based approach, promoting reusability and maintainability. State management for the shopping cart is handled using React's Context API, enabling efficient data sharing across different components without prop drilling. Product data is managed locally via JSON files, facilitating easy updates and offline access during development. Performance optimizations are inherent in the Vite build process, which includes features like hot module replacement for faster development cycles and optimized production builds. Security considerations are addressed by not exposing any sensitive credentials or proprietary logic, focusing solely on the client-side user interface and interaction.

## Architecture

```mermaid
flowchart TD
    A[User Browser] --> B(React Application)
    B --> C{UI Components}
    C --> D[Header]
    C --> E[Footer]
    C --> F[Hero]
    C --> G[ProductCard]
    C --> H[CartSidebar]
    C --> I[SEO]
    B --> J{Context APIs}
    J --> K[CartContext]
    J --> L[LanguageContext]
    B --> M[Data Layer]
    M --> N(products.json)
    B --> O[Styling]
    O --> P(Tailwind CSS)
    B --> Q[Build Tool]
    Q --> R(Vite)
```

## Getting Started

This project is designed to be viewed via its live URL (https://bouratn.netlify.app/). As it is a static client-side application, direct local setup instructions are not applicable in the context of a private repository. The focus is on the deployed version's functionality and user experience.

## Links

- [Live Demo](https://bouratn.netlify.app/)
- [Source Code](https://github.com/Alaa-Taieb/boura.tn)

Boura Flower Shop is a responsive e-commerce website designed to showcase and sell a curated selection of floral arrangements and related products. The platform aims to provide a seamless and visually appealing online shopping experience for customers looking to purchase flowers for various occasions. It offers detailed product information, a streamlined browsing process, and an intuitive shopping cart functionality.

Boura Flower Shop

## Overview

The Djerba Confort Management System is a comprehensive web application designed to streamline and optimize the operations of a bus transportation service. It addresses the complexities of managing routes, schedules, seat inventory, ticket sales, and financial transactions within a single, integrated platform. The system aims to eliminate manual processes, reduce errors, and enhance efficiency for both administrators and customers.

The core problem this system solves is the fragmentation and inefficiency often found in traditional transportation management. By centralizing all aspects of operations, from route planning and schedule creation to real-time ticket booking and refund processing, Djerba Confort provides a unified solution. This allows the company to better manage its fleet, optimize resource allocation, and improve customer service through a seamless booking experience. The target audience includes bus company administrators, station managers, agents, and end-users looking to purchase bus tickets.

The key value proposition of the Djerba Confort Management System lies in its ability to deliver operational control, financial transparency, and a superior user experience. It empowers administrators with powerful tools for managing all facets of the business, while providing customers with a modern, user-friendly interface for booking and managing their travel. The system's robust features, including dynamic scheduling, real-time inventory, and comprehensive reporting, contribute to increased revenue, reduced operational costs, and enhanced customer satisfaction.

## Key Features

- Real-time bus ticket booking and management with dynamic seat selection.
- Comprehensive route and schedule management, including multi-stop routes and schedule overrides.
- User and role-based access control for administrators, agents, and customers.
- Integrated financial management, including payment processing, refunds, and balance tracking.
- Robust reporting and analytics for sales, performance, and revenue trends.
- Audit logging for tracking system changes and user activities.
- Internationalization (i18n) support for multi-language interfaces.

## Technical Stack

The Djerba Confort Management System employs a robust, layered architectural approach, separating concerns into distinct backend and frontend applications. The backend, built with Node.js, leverages a Model-View-Controller (MVC) pattern for organizing application logic. It utilizes a PostgreSQL database, managed through migration scripts, to ensure data integrity and schema evolution. Key design patterns observed include dependency injection for managing configurations and services, and middleware for handling cross-cutting concerns like authentication, validation, and error handling. Security is a paramount consideration, with features like JWT for authentication, password hashing, and input sanitization implemented to protect sensitive data and prevent common web vulnerabilities.

Notable technical challenges addressed include the complexity of multi-stop route management, dynamic schedule generation with recurring events, and the intricate logic for ticket reschedules and refunds, particularly handling post-departure scenarios and vendor configurations. Performance optimizations are likely achieved through efficient database queries, optimized API responses, and potentially caching mechanisms. The use of Docker for containerization ensures consistent deployment across different environments, simplifying setup and scaling.

## Architecture

```mermaid
graph TD

    %% =======================
    %% Frontend
    %% =======================
    subgraph Frontend
        A[Client Browser]
        B[React App]
        C[UI Components]
        D[API Services]
        E[Context API]
        F[i18n]

        A --> B
        B --> C
        B --> D
        B --> E
        B --> F
    end

    %% =======================
    %% Backend
    %% =======================
    subgraph Backend
        G[API Gateway]
        H[Node.js Server]
        M[Middleware]
        I[Controllers]
        J[Services]
        K[Models]
        L[PostgreSQL Database]
        N[Configuration]
        O[Docker Host]

        G --> H
        H --> M
        M --> I
        I --> J
        J --> K
        K --> L

        H --> N
        H --> O
    end

    %% =======================
    %% External Services
    %% =======================
    subgraph External Services
        P[Payment Gateway]
        Q[Email Service]
    end

    %% Connections
    D -- API Calls --> G
    J -- Uses --> P
    J -- Uses --> Q

```

The Djerba Confort Management System is a comprehensive web application designed to streamline and optimize the operations of a bus transportation service. It addresses the complexities of managing routes, schedules, seat inventory, ticket sales, and financial transactions within a single, integrated platform. The system aims to eliminate manual processes, reduce errors, and enhance efficiency for both administrators and customers.