标签：#Web

The people who make open source work aren't just the ones writing code. Some of them write the words that make the code make sense. I spent years assuming open source was a closed door. Every time I opened GitHub, I felt like I'd wandered into a conversation being held in a language I hadn't studied. Pull requests, forks, issues tagged with words like "good first issue" that somehow still felt intimidating. I closed the tab more times than I can count, convinced that space belonged to people who could write functions, not people who could write sentences. It took me longer than I'd like to admit to realize how wrong that assumption was. The myth that keeps people out Open source has a branding problem, and it's an ironic one for a movement built on collaboration. The public image is almost entirely code: commits, merges, terminals, lines of syntax scrolling past on a dark screen. That image is accurate, but it's incomplete. It leaves out the writers who make a tool's documentation actually usable. It leaves out the designers who turn a clunky interface into something people want to use. It leaves out the community managers who keep a project from imploding when a disagreement gets heated. It leaves out the translators, the testers, the people who write the first draft of a README at 11pm because nobody else got around to it. If you've stayed away from open source because you don't code, you've been kept out by a myth, not a rule. What non-developers actually do in these projects Documentation is the most obvious entry point, and it's also one of the most needed. A huge number of open source projects are built by people who are excellent engineers and mediocre explainers. That's not a criticism, it's just a different skill. Someone can write brilliant code and still produce a setup guide that only makes sense to the person who wrote it. Projects need people who can sit with a piece of software as a genuine beginner would, notice where the instructions fall apart, and

I am testing my first automated end to end social media post automation system. which is created using the free tools. But it is very efficient and productive. i can use this thing in future posting on various platforms to tell people about my learning's and update about me. Tools : Make.com = I use this tool to mainly automate my system it include flow how things works and system is linked. Hashnode = I use this as a central blog and article publishing tool other tools is connected with it so content links is properly distributed. Google Ai Studio = I use this to integrate the ai in between this whole process which just do small job to add the engaging hook and the tags for the reach Buffer = I use to connect X (twitter) with this Because Make.com remove the platform X (twitter) to His integration. After the policy change of the platform. Dev.to = I use this to improve SEO of my post over the google search engine. Challenges : I cannot integrate the github actions with the hashnode becuase this feature is become paid on hashnode. May be in future i can do this thing using self written yml file, i am guessing Not sure will this 100 % work or not. Twitter integration as i described early that twitter integration is not present in the make.com so i use the another tool Buffer. The limits calculation, Their was a limits on each tools for their specific use case so i have to intentionally calculate them properly. Even the free tear of the twitter which is X is few hundreds words that's why i have to limit the text of the post, which is hook only, The threads creation i don't think it will be their in this tools which i am using, i will definitely find it if their. Solutions : Simply use other Way if this way is closed, use different tool for twitter May be in future i create yml file for the github actions but for now i am directly writing on hashnode. The dev.to does not provide feature of direct posting it save your cycle into draft so you have to manually click on pu

Modern AI UX — chat panels, tool-calling agents, assistants that remember context and even suggest your next step — has lived in JavaScript SaaS for years. The Java enterprise stack has been left doing it the hard way. TabForge AI closes that gap . It's a complete platform for building AI-powered web apps on Jakarta EE + PrimeFaces — from the multi-tab UI shell down to a clean, provider-agnostic AI layer. Library, live demo, starter project, and a drop-in UI template — all shipped. Here's the whole thing, top to bottom. ## 1. Tabs as annotated beans — DynTabs You describe a tab; the framework handles opening, closing, lifecycle, and state. Each open tab gets its own isolated CDI bean via a custom @TabScoped scope. @Named @TabScoped @DynTab ( name = "OrdersDynTab" , uniqueIdentifier = "Orders" , title = "Orders" , includePage = "/WEB-INF/orders.xhtml" , trackActivity = true ) public class OrdersBean extends BaseDyntabCdiBean { // open the same tab twice → two independent instances } java No manual navigation, no page-state juggling. Open a tab, get a bean; close it, it's gone. A clean AI layer — EasyAI One fluent entry point over LangChain4j. Chat, tools, agents, and structured extraction — provider-agnostic, so the model behind it is a config detail. // A typed assistant with a business service exposed as tools OrdersAssistant ai = EasyAI . assistant ( OrdersAssistant . class ) . withTools ( orderService ) . build (); String reply = ai . ask ( "cancel order ORD-002" ); You opt methods in as tools explicitly — no accidental exposure: @EasyTool ( "Cancels an active order" ) public String cancelOrder ( String orderId ) { ... } Deterministic pipelines — flow() Agents are powerful but unpredictable. When you want a repeatable, testable process, flow() lets you own the steps and call the model only at the edges that actually need language: EasyAI . flow () . step ( "understand" , ctx -> EasyAI . extract ( OrderRequest . class ). from ( ctx . inputText ())) . step ( "check

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art . 🍩 Inspiration I write about WordPress plugins and PHP standards for a living, so when DEV dropped a "Comfort Food" theme for their Frontend Challenge, I didn't need to think twice about what to build. Not ramen, not pancakes — a donut. Specifically, the kind of donut that shows up on your desk right when a deploy breaks and somehow fixes everything. The twist I gave myself: don't just draw a static donut. Let people build one — pick a glaze, pile on toppings, then serve it — and do almost all of it in CSS, with JavaScript kept firmly in the back seat where the challenge rules ask for it to stay. That's how Donut Panic was born. 🎬 Demo Pick a glaze, load it up with sprinkles, drizzle, or powdered sugar, then hit Serve and watch it animate off the plate. 🛠️ Journey No JavaScript is driving the donut — :has() is Here's the part I'm most excited to talk about: every visual change in Donut Panic — the glaze swap, the toppings appearing, the donut lifting off the prep station and landing on the plate — is driven by plain checkbox/radio inputs and the :has() selector. Something like .kitchen:has(#serve:checked) .donut lets a parent element react to the checked state of an input buried somewhere inside it, which means the "Serve" button, the topping toggles, and the glaze picker are all just styled <label> s wired to hidden inputs. No click handlers, no state management — the checkbox is the state. JavaScript only shows up once, and it's not touching the art at all: it smooth-scrolls the stage into view on mobile after you hit Serve, because on a stacked mobile layout the donut can animate off-screen. That's the "sprinkle" of JS the challenge rules allow, used exactly the way it's meant to be — a UX nicety, not a rendering engine. Building the donut from the inside out The donut itself is layered rings, not a single flat shape: A base dough circle with a radial gradient doing double duty as both c

Sometimes your application can reach an external service from one server, but not from another. I ran into this problem while working on one of my projects. I needed my server in Iran to communicate with Telegram, but the connection wasn't reliable from inside Iran. Instead of moving the whole application, I built a small intermediate service: Signed Webhook Receiver It is a lightweight FastAPI service that receives requests signed with an RSA private key and verifies them using the corresponding public key before processing them. Your Server | | RSA Signed Request v Webhook Receiver | | HTTP Request v External Service The receiver can be useful for: Secure server-to-server communication Webhooks and internal APIs Acting as a controlled proxy/gateway Connecting servers across different network environments Payment integrations where a provider requires requests from an Iranian IP For example, if your main application is hosted outside Iran but a payment gateway only accepts requests from Iranian IP addresses, an Iranian server can act as the intermediate gateway: Foreign Server | | Signed Request v Iranian Gateway Server | v Payment Gateway The important part is that this isn't an open proxy. Requests can be authenticated and the gateway can be restricted to specific operations and destinations. The project is built with Python, FastAPI, Cryptography, Docker, and Traefik and is open source. View the project on GitHub I also wrote more technical notes and development articles on my website: Building a Secure Webhook Receiver for Server-to-Server Communication | CyberHuginn

Cybersecurity is entering a new phase. This is because security teams are facing more and more complex problems and threats that are moving faster. To help defenders respond more effectively, OpenAI has introduced GPT-5.6-Cyber, a special model designed for advanced cybersecurity tasks. The model supports authorized security research, vulnerability discovery, and other defensive workflows. The Daybreak program is showing how specialized AI tools can improve modern cybersecurity by working together with human security experts. Quick overview GPT-5.6-Cyber is a specialized model for authorized cybersecurity work. It is available through OpenAI’s Daybreak Red access for approved defenders. OpenAI reports a 95% completion rate on its internal advanced cybersecurity evaluation. The model helped researchers uncover vulnerabilities in Chrome’s V8 JavaScript engine. Controlled access, monitoring, and human oversight remain important for safe deployment. What Is GPT-5.6-Cyber? GPT-5.6-Cyber is OpenAI’s cybersecurity-specific model, available through Daybreak Red. Built on GPT-5.6 Sol, it is trained to improve performance on specialized cybersecurity tasks such as finding zero-day vulnerabilities and developing exploit chains, while reducing refusals for certain higher-risk, dual-use cyber tasks. Daybreak has two access tiers: Daybreak Blue provides approved defenders with frontier general-purpose models such as GPT-5.6 Sol, with safeguards tailored to authorized defensive security work. Daybreak Red provides purpose-trained cybersecurity models for authorized vulnerability research, exploit validation, and security testing. This approach reflects a significant shift toward security tools designed for professional cybersecurity environments rather than unrestricted public use. The goal is clear: to help trusted defenders investigate vulnerabilities, analyze potential threats, and respond to security incidents more effectively while keeping access controlled. According to Open

TL;DR — Events in Fitz LiveViews carry data three ways: a click payload ( data-flv-value-* ) tags a button with the value it should send; a form submit ( data-flv-submit ) reads the form's named inputs; and a live value ( @input / @change ) delivers a control's current value in payload["value"] . All three land in the same place — a payload map your handler reads. This post builds a live name list (add / remove / count) that runs both server-rendered and as WebAssembly. (Part 3 of the FitzLiveViews series.) Parts 1 and 2 covered the pitch and the counter. A counter only reads +1 / -1 — no data flows in . Real UIs take input: text, selections, form fields. Here's how that data reaches your handlers. The payload Every event handler has a payload in scope — a Map<Str, Str> . The three mechanisms below all fill it; your handler reads it with payload["key"] (guard with payload.has("key") ): 1. Click payload — a button that carries a value Tag any element with data-flv-value-<key>="{expr}" , and when a data-flv-click on it (or an ancestor) fires, that value rides along: <button data-flv-click= "remove" data-flv-value-item= "{it}" > × </button> event remove () { if ( payload . has ( " item " )) { let target = payload [ " item " ] names = names . filter ( fn ( it ) => it != target ) } } The delete button knows which row it is because the row's value is stamped on it. No IDs threaded through a callback, no closure capture. 2. Form submit — the whole form at once data-flv-submit="handler" on a <form> reads each named input into the payload on submit; data-flv-clear resets a field afterward: <form data-flv-submit= "add" > <input name= "item" placeholder= "Add a name" data-flv-clear /> <button type= "submit" > Add </button> </form> event add () { if ( payload . has ( " item " )) { let n = payload [ " item " ] if ( n != "" ) { names . push ( n ) } } } payload["item"] is the input's value at submit time. No preventDefault , no FormData , no fetch . 3. Live value — @input / @chang

Nuxt 4.5 launched last month and it's really neat. One of my most favorite features is the...

A free AI visibility score is auditable only when you can inspect the prompt, engine, raw answer, date, and denominator. Treat the score as a test result, not a property of your brand. This tutorial builds a six-check control you can run by hand, store as plain data, and compare with any tool's output. The workflow takes three buyer questions, runs them in two AI surfaces, and records the six answers without trying to force agreement. It will not estimate your entire market. It will tell you whether a dashboard's headline number has enough evidence to be investigated. What does an AI visibility score measure? An AI visibility score usually summarizes brand presence across a defined set of generated answers. That definition contains the trap: the question set is part of the metric. So are the engine panel, run date, session state, retrieval mode, and rule used to count a “hit.” Remove those inputs and the number is not reproducible. Imagine a tool asks three questions in two engines. That creates six cells. If your brand appears in two cells, the simple presence result is: presence = brand_present_cells / total_cells presence = 2 / 6 presence = 0.333... = 33.3% The arithmetic is trivial. The evidence is not. A different tool can ask five different questions in three engines and produce a different score without contradicting the first run. The two tools measured different grids. Keep the unit explicit: “present in two of six generated answers on this date” is defensible. “Our AI visibility is 33” is incomplete. Which evidence fields should you require? Require five fields for every result: prompt, engine, raw answer, timestamp, and counting rule. Use a sixth field for cited sources when the surface exposes them. A source-only appearance and a prose mention can signal different problems, so do not merge them silently. Here is one real saved result from Webappski's public 14 June 2026 tracker report: { "run_date" : "2026-06-14" , "prompt" : "beste Answer Engine Optimiz

Why a live payment is not a release test The riskiest way to test a SaaS checkout is to make a real payment to yourself. It feels reassuring: the live checkout opened, the card worked, the webhook fired and the refund came back. But that proof mixes engineering QA with revenue evidence. Three different proofs A cleaner billing release process separates three questions: Does billing behave correctly? Test payment, refund, webhook and subscription edge cases in a Stripe sandbox. Is production configured correctly? Verify the live price, currency, checkout destination, webhook configuration and deployed revision without moving money. Did a customer pay? Treat a genuine live transaction as customer activity and revenue evidence, not as an engineering fixture. Stripe documents sandboxes as isolated testing environments and separates sandbox credentials from live credentials. The practical lesson is broader than Stripe: operational proof and commercial proof should not share the same transaction. A useful boundary Use this sequence: Sandbox QA → read-only production verification → genuine customer payment . It keeps release evidence, reconciliation and revenue numbers easier to interpret. We recently tightened the same boundary in VendorOS. That does not prove live customer revenue; it is a workflow lesson about keeping evidence categories separate. If your release process still requires a live self-payment, ask which part of the verification can become read-only. Sources: Stripe Sandboxes Stripe API keys Stripe testing VendorOS release boundary

I Built a Cinematic Developer Portfolio Instead of a Traditional One — Here’s What I Learned Most developer portfolios follow the same structure: About. Skills. Projects. Contact. There is nothing wrong with that. But when I started rebuilding mine, I wanted it to feel less like a collection of sections and more like an experience . So what started as a simple portfolio redesign slowly turned into a cinematic, interactive developer portfolio built around my journey as a Software Engineer and AI Developer . 🌐 Live Portfolio: https://pavan-sai-portfolio-xi.vercel.app The Idea I wanted the visitor to feel like they were entering a story rather than opening another resume website. The final experience includes: A cinematic opening sequence A custom soundtrack Full-screen scene-based navigation Animated video backgrounds Project showcases and case studies A personal journey timeline Responsive mobile layouts A cinematic closing scene Smooth transitions between sections The overall visual direction is built around: Black + Champagne Gold + Cinematic Lighting The Portfolio Flow The experience follows a sequence: Intro → Pavan Sai → Hero → About → Skills → Projects → Journey → Contact → Closing Credits Instead of normal vertical scrolling, the main portfolio behaves more like a sequence of scenes. Visitors move through the experience using navigation controls. Project case studies are separate and can scroll normally because they contain more detailed technical information. The Projects Some of the projects featured in the portfolio include: DevPilot AI An AI-powered DevOps incident recovery platform focused on detecting failures, diagnosing issues and helping recover production systems. ROCmPorter Agent An AI-assisted CUDA-to-AMD ROCm migration tool that analyzes repositories, identifies CUDA dependencies and helps generate migration changes. HunarHub A local skilled-worker discovery and service marketplace platform. I also showcase other engineering, AI and full-stack pro

WordPress sitelerinde hız problemi yaşandığında genellikle ilk refleks bir cache eklentisi kurmak oluyor. Bazen gerçekten fark yaratıyor, bazen de PageSpeed puanı biraz yükselmesine rağmen site hâlâ yavaş hissettiriyor. Bunun nedeni WordPress performansının tek bir ayardan oluşmaması. Hosting, tema, eklentiler, görseller, JavaScript dosyaları ve veritabanı aynı anda sayfanın yüklenme süresini etkileyebiliyor. Bu nedenle bir siteyi hızlandırmaya başlamadan önce asıl problemin nerede olduğunu bulmak gerekiyor. WordPress projelerinde sık karşılaştığım 7 performans hatasını aşağıda topladım. Gereğinden büyük görseller kullanmak En sık karşılaştığım problemlerden biri bu. Sayfada 700 piksel genişliğinde görüntülenecek bir görselin 4000-5000 piksel olarak yüklenmesi oldukça yaygın. Özellikle yüksek çözünürlüklü stok fotoğraflar doğrudan WordPress'e yüklendiğinde tek bir görsel birkaç megabayta ulaşabiliyor. Bu da özellikle mobil bağlantılarda ciddi yük oluşturuyor. Görselleri yüklemeden önce kullanılacağı alana uygun boyuta getirmek, sıkıştırmak ve mümkün olduğunda WebP veya AVIF gibi modern formatları tercih etmek önemli. Ancak yalnızca dosya formatını değiştirmek yeterli değil. 4000 piksel genişliğindeki bir görseli WebP'ye çevirmek, görselin gereğinden büyük olduğu gerçeğini değiştirmiyor. Her problemi cache eklentisiyle çözmeye çalışmak Cache WordPress performansında önemli bir yere sahip. Fakat cache eklentisi kurmak her hız problemini ortadan kaldırmaz. Sunucu geç cevap veriyorsa, çok fazla JavaScript çalışıyorsa veya veritabanında ağır sorgular varsa cache yalnızca problemin bir bölümünü gizleyebilir. Ayrıca aynı anda birden fazla optimizasyon eklentisi kullanmak da başka sorunlara yol açabiliyor. Örneğin bir eklentide JavaScript erteleme, başka bir eklentide tekrar JavaScript optimizasyonu ve hosting panelinde üçüncü bir optimizasyon sistemi açıldığında hangi ayarın ne yaptığını takip etmek zorlaşıyor. Ben mümkün olduğunca tek bir ana cache sistemi üzerinden ilerl

I used to think financial apps were designed mostly for people who already understood finance. You open an app, see dozens of charts, numbers, and settings, and sometimes your first thought is: “Okay… where do I even start?” AI is slowly changing that experience. The most useful AI applications in fintech are not always about making predictions. In many cases, they are about removing friction: organizing information, automating repetitive tasks, and helping users understand complicated processes. We can already see this trend in different areas. Companies like Stripe are using technology to simplify online payments, while platforms like Plaid help connect financial data between different services. The same idea is appearing in other parts of finance too. Some digital financial platforms are exploring automation tools that help users create more structured workflows instead of manually managing every step. For example, platforms like BYDFi have introduced automated tools that allow users to use predefined strategies rather than constantly monitoring every market movement. Of course, automation does not replace human decisions. A smarter tool does not mean a person can ignore research or risk management. For developers, the interesting challenge is not building the most complicated system. It is building something that makes complicated things easier for real users. Maybe the future of fintech is not about adding more buttons. Maybe it is about helping people need fewer buttons.

A few years ago, a technical interview mostly tested one thing: can you write correct code, from memory, under pressure. That bar has quietly shifted — and a lot of developers preparing for interviews right now haven't fully clocked it. AI coding assistants are part of daily work at most companies now, from big IT services firms to small product teams. Interview panels have adjusted to that reality faster than most prep guides have. What's actually different now Interviewers care less about whether you can produce a function from scratch, and more about whether you understand what code is doing and why. It's increasingly common to be handed a piece of AI-generated code and asked to find the bug, justify a design decision, or optimize it — instead of writing something from zero on a whiteboard. Some companies go further and let you use AI tools during the technical round, then evaluate how well you direct the tool, verify its output, and catch its mistakes. The skill being tested has moved from "can you write code" to "can you reason clearly with code as your material." Three things I keep seeing candidates get wrong Treating a finished course or degree as the finish line. Completing a syllabus tells an employer you were exposed to concepts. It doesn't tell them you can apply those concepts to a messy, real-world problem — which is exactly what open-ended interview scenarios are designed to expose. Leaning on AI tools without understanding the output. Using an AI assistant while practicing at home is fine. The problem shows up when that habit surfaces in a live interview as an inability to explain your own solution. If you can't walk through why a piece of code works, a couple of follow-up questions will make that obvious fast. Underrating communication and debugging skills. As AI tools take on more initial code-writing, the human value shifts toward reviewing, debugging, and explaining decisions to teammates. Candidates who only practiced writing code — and never pr

Spent the week redesigning my portfolio’s blog layout and nuking thousands of stale notes in my Obsidian vault. Between the UI polish and some deep dives into libp2p DHT de-flaking, I pushed 36 commits and managed to delete almost 16,000 lines of clutter. TL;DR I’ve always believed that your digital space needs a good pruning every now and then to stay healthy. This week was the embodiment of that philosophy. I pushed 36 commits across four primary projects, resulting in over 23,000 additions and nearly 16,000 deletions. Most of that churn came from a massive redesign of my portfolio's blog and a long-overdue "fresh start" for my Obsidian vault. On the open-source side, I spent some quality time in the weeds of py-libp2p , chasing down flaky DHT tests and proposing better subnet diversity limits. What I Built Portfolio Redesign: The Typography Pivot My main focus this week was my portfolio. I’ve been feeling like the blog layout was getting a bit cluttered, so I opened and merged PR #15, which was all about "typographic hierarchy instead of decoration." I’m moving away from unnecessary borders and boxes and letting the type do the heavy lifting. I spent a lot of time in components/blog and app/blog refining the layout. I implemented borderless filter pills and full-width rows to give the content more room to breathe. One of the bigger technical shifts was moving the blog list to be fully server-rendered. It feels snappier, and it allowed me to implement more "honest" dates and better hover states on the rows. I also added a real focus ring for accessibility (because we’ve all been frustrated by keyboard navigation that feels like a guessing game). By the time I was done, I’d touched over 200 files in that repo alone. The Obsidian Purge I also took a metaphorical chainsaw to my obsidian-vault . I nuked nearly 10,000 lines of stale content. I removed entire directories for "Projects," "Rust," and "Backend" notes that were just gathering digital dust. It’s easy to let

Most "AI gift finders" are a search box with a chatbot glued on. I wanted to build something different — a quiz-driven gift recommender that ranks real Amazon products by who the recipient actually is , not just keywords. I call it GiftHive . In this post I'll walk through the architecture, the conversion tricks I learned shipping it, and the bits I'm proudest of. The Problem Picking gifts is emotionally expensive. You scroll Amazon for an hour, second-guess every option, and end up buying a gift card. Existing tools don't help because they optimize for keyword match , not recipient fit . GiftHive flips the input: instead of "show me gifts under $50", you answer a 30-second quiz about the person (relationship, interests, occasion, budget) and get a ranked shortlist with explanations of why each gift fits. Stack Next.js (App Router) — SSR for fast first paint, RSC for product data Tailwind CSS — design system + dark mode via CSS variables Cloudflare Pages — edge-deployed, free tier covers the traffic Amazon Associates — affiliate revenue model The Funnel The whole site is a 3-step conversion funnel: Landing page — exit-intent modal + social proof toasts prime the visitor Quiz — 30-second, one-question-per-screen flow, no login Results — ranked products with countdown bar and "X people found gifts this week" social proof Every step has a single primary CTA. The exit-intent modal is route-aware — it only fires on / and stays silent on /quiz and /results so it never interrupts the funnel mid-flow. That bug cost me ~15% of quiz completions before I caught it. Personalization Logic Each quiz answer maps to a vector of attributes (interests, style, budget, relationship). Products in the catalog have matching tags. Ranking is a weighted score: score = tag_overlap * w1 + budget_match * w2 + occasion_match * w3 No ML model needed — a few hundred products and clean tagging is enough to feel personal. Amazon Affiliate Integration Every product link runs through getAmazonUrl() w

I was watching The Mandalorian the other day when it struck me that I don't know Pedro Pascal, which...

Say "AI" in a room full of developers and a pecking order forms on its own. Python sits at the top,...

🚀 Shipping a major update to my portfolio After weeks of designing, developing, and refining, I'm excited to share the latest version of my personal portfolio. Rather than building another static portfolio, I wanted to treat it like a real product—focusing on performance, interaction design, accessibility, analytics, and user experience. 🌐 Live: https://www.alanbabychan.online What I built 🟩 Matrix Theme A cyberpunk-inspired dark mode featuring animated binary effects, glowing UI elements, and an immersive developer experience. ⬜ Paper Theme A clean, modern light mode designed with readability, visual hierarchy, and clarity in mind. 🎵 Interactive Audio System •Background music •UI sound effects •Dedicated settings panel •Adjustable volume controls •Built using the Web Audio API 🖱️ Interactive Cursor A custom mouse-follow glow and subtle cursor interactions that enhance the browsing experience without becoming distracting. ✨ Micro-interactions Hover states, smooth page transitions, animated UI components, and responsive visual feedback to make every interaction feel intentional. 📖 UX & Accessibility Built around clear typography, intuitive navigation, responsive layouts, and accessibility-focused design to provide a consistent experience across devices. 📊 Performance & Analytics Built with Next.js and optimized for speed, SEO, and scalability. Implemented a complete Google Analytics 4 setup including: •SPA page tracking •Google Consent Mode v2 •Custom event tracking •User interaction analytics Tech Stack: Next.js • React • Tailwind CSS • Framer Motion • Web Audio API • Google Analytics 4 • Microsoft Clarity Coming Soon... 👀 I'm currently building a personal AI assistant that will allow visitors to interact with my portfolio, ask questions about my projects, experience, and skills, and explore everything conversationally. What I learned This project pushed me to dive deeper into: •Theme architecture •Frontend performance optimization •Animation systems •Custom UI inte

As developers, we use package managers almost every day. Whether we are working with Node.js, React, Next.js, TypeScript, Express, Prisma, or other technologies in the JavaScript ecosystem, choosing the right package manager can have a meaningful impact on our development workflow. Recently, I spent some time comparing the most popular package managers: npm, Yarn, pnpm, and Bun. After looking at them from the perspective of performance, dependency management, disk efficiency, ecosystem compatibility, and developer productivity, my current preference is pnpm. Why pnpm? For me, pnpm provides one of the best overall balances between speed, disk efficiency, reliability, dependency management, and developer experience. One of the key differences is how pnpm handles dependencies. It uses a content-addressable store and links packages into projects instead of unnecessarily keeping separate copies of the same packages for every project. This can reduce disk usage and make package installation more efficient, especially when working on multiple JavaScript or TypeScript projects. Another advantage is pnpm's stricter dependency management. It encourages projects to explicitly declare the packages they actually depend on, which can help prevent accidental reliance on transitive dependencies. This becomes particularly useful when working on larger applications, monorepos, or team-based projects. What about Bun? Bun is extremely interesting because it is much more than a package manager. It provides a JavaScript/TypeScript runtime, package manager, test runner, and bundler. Its performance is impressive, especially when it comes to package installation and certain development workflows. However, I don't think raw speed should be the only factor when choosing a technology for production. Compatibility, ecosystem maturity, team familiarity, tooling support, and long-term maintainability are equally important. That is why I see Bun as an excellent and promising tool, but I would not