2026-01-14 14:13:02
CES 2026 just wrapped up ... and I can't stop thinking about how the timeline between "impossible" →← "shipping next quarter" is just collapsing! Here are the top 5 things that caught my fancy 🤩 • the LEGO Group bricks that react to how you play with them. Chips smaller than a stud + built-in sensors. Swing a lightsaber & it hums in real-time. No app, no screen. Just intelligent physical play. • Paper batteries already in production w Logitech & Amazon. Biodegradable, non-flammable batteries + zero lithium. If this scales, we're watching a supply chain get rewritten in real time. • Robot vacuum climbing stairs. Roborock's Saros Rover deployed wheel-legs & hopped up 5 steps in 40s while vacuuming each one. The impossible will just become mundane. • Your car's windshield is about to replace the dashboard. BMW Group's full-AR HUD projects navigation exactly where you need it on the road ahead. Not on a screen. On reality. • Your bathroom mirror will diagnose you. Smart mirrors, needle-free injections & ambient health tracking that catches illness before symptoms appear. Healthcare is shifting from reactive to invisible. The pattern? Companies that treated AI as a feature to bolt on are getting lapped by companies rebuilding products, assuming AI exists from day 1. The gap isn't closing. It's accelerating ⚡️ #CES #CES2026 #TechTrends
linkedin.com
CES 2026 just wrapped up ... and I can't stop thinking about how the timeline between "impossible" →← "shipping next quarter" is just collapsing!
Here are the top 5 things that caught my fancy 🤩
• LEGO bricks that react to how you play with them. Chips smaller than a stud + built-in sensors. Swing a lightsaber & it hums in real-time. No app, no screen. Just intelligent physical play.
• Paper batteries already in production w Logitech & Amazon. Biodegradable, non-flammable batteries + zero lithium. If this scales, we're watching a supply chain get rewritten in real time.
• Robot vacuum climbing stairs. Roborock's Saros Rover deployed wheel-legs & hopped up 5 steps in 40s while vacuuming each one. The impossible will just become mundane.
• Your car's windshield is about to replace the dashboard. BMW Group's full-AR HUD projects navigation exactly where you need it on the road ahead. Not on a screen. On reality.
• Your bathroom mirror will diagnose you. Smart mirrors, needle-free injections & ambient health tracking that catches illness before symptoms appear. Healthcare is shifting from reactive to invisible.
The pattern? Companies that treated AI as a feature to bolt on are getting lapped by companies rebuilding products, assuming AI exists from day 1.
The gap isn't closing. It's accelerating ⚡️
2026-01-14 14:12:54
TL;DR: Stop console.logging your cart state. Shopify Theme Devtools gives you a visual cart inspector, history tracking, test automation, and scenario management—all in your browser while developing themes.
If you've developed Shopify themes, you know the pain:
console.log({{ cart | json }}) to debugShopify Theme Devtools solves all of this with a dedicated Cart Panel that transforms how you debug and test cart functionality.
Shopify Theme Devtools is an open-source, in-browser developer panel for Shopify theme development. Think of it as Chrome DevTools, but specifically designed for Liquid and Shopify.
The Cart Panel is one of its most powerful features—a complete cart management and debugging toolkit that runs directly in your development theme.
Key Features:
npx shopify-theme-devtools init
This adds the Liquid snippet to your theme. The devtools only render on unpublished themes, so your live store is never affected.
Once installed, you'll see a floating devtools panel on your development theme. Click the Cart tab to access all cart debugging features.
Debugging cart state usually means adding {{ cart | json }} to your template, refreshing, copying the JSON, and pasting it into a formatter. Repeat for every change.
The Cart Panel shows your complete cart state in a clean, interactive interface:
At a glance, you see:
For each line item:
Click any item to reveal:
Quick Actions:
You're debugging why a discount isn't applying correctly. Instead of digging through JSON:
line_price but your theme is displaying original_line_price
Time saved: 15+ minutes per debugging session
You've finally reproduced a cart bug after 10 minutes of adding products. You refresh the page to test your fix—and the cart state is gone or changed.
Cart History automatically tracks every cart change with timestamps and visual diffs.
What gets tracked:
See a historical cart state you need? Click Restore and the Cart Panel:
The entire process takes ~2 seconds.
You're testing a "free gift at $100" promotion:
Time saved: 5-10 minutes per cart rebuild
You have 8 different cart configurations you need to test:
Rebuilding these manually for every test cycle is exhausting.
Cart Scenarios let you save, name, and instantly load predefined cart states.
Need to tweak a scenario without rebuilding the cart?
Share scenarios with your team:
// Exported scenario file
{
"name": "GWP Test Cart",
"items": [
{ "variant_id": "12345678", "quantity": 2, "properties": { "_is_gwp": "true" } }
],
"attributes": { "gift_message": "Happy Birthday!" },
"note": "Test order - do not fulfill"
}
Your QA team needs to test 12 different cart states for a new promotion:
Time saved: Hours of manual cart building across team members
Cart validation logic is complex. Gift-with-purchase items need specific properties. Quantity limits must be enforced. Bundles require companion products. How do you catch these issues before they reach production?
Cart Tests let you define validation rules that run automatically against your cart state.
"If item has property X, it must also have properties Y and Z"
IF item has property "_is_gwp" = "true"
THEN item MUST have properties: "_gwp_price", "_gwp_source", "_gwp_campaign"
Use cases:
"If item field equals X, then another field must equal Y"
IF item product_type = "Gift Card"
THEN item quantity MUST equal 1
Use cases:
"If cart contains item X, cart must also contain item Y"
IF cart contains item with product_type = "Electronics"
THEN cart MUST contain item with product_type = "Warranty"
Use cases:
"Item/cart quantities must meet min/max/multiple constraints"
SCOPE: per-item
MAX: 10
(No item can have quantity > 10)
SCOPE: cart-total
FILTER: product_type = "Sample"
MAX: 3
(Maximum 3 sample products in cart)
Use cases:
Don't want to configure from scratch? Choose from 13 pre-built templates:
[Property] GWP Validation[Property] Personalization Check[Property] Pre-order Validation[Field] Gift Card Qty = 1[Field] Subscription Valid[Field] Digital Products Check[Field] SKU Required[Composition] Warranty Required[Composition] Bundle Check[Qty] Max Per Item (10)[Qty] Cart Max (50 items)[Qty] Pack of 6 Only[Qty] Samples Max 3Enable Auto-run and tests execute automatically whenever your cart changes. Failed items are highlighted with a red border directly in the cart display.
You're implementing a gift-with-purchase promotion:
_gwp_price property"Time saved: Catching bugs before they reach production = priceless
No need to browse to product pages. Enter a variant ID and quantity, click Add, and the item is in your cart.
Variant ID: 12345678901234
Quantity: 2
[Add]
Test discount logic directly from the panel without going through checkout:
Discount Code: SAVE20
[Apply]
Need to share a specific cart state? Click Link to copy a permalink:
https://yourstore.com/cart/12345678:2,87654321:1
Click Export to download your complete cart state as JSON for documentation or bug reports.
Something is modifying your cart unexpectedly. Is it a third-party app? A theme script? A Shopify feature?
The Cart Panel intercepts and logs all cart-related AJAX requests:
Tracked endpoints:
/cart.js/cart/add.js/cart/update.js/cart/change.js/cart/clear.jsFor each request, you see:
Found a rogue script modifying your cart? Block requests by source to isolate the issue:
Build a comprehensive set of scenarios for your store:
├── Basic States
│ ├── Empty cart
│ ├── Single item
│ └── Multiple items
├── Edge Cases
│ ├── Max quantity (per item)
│ ├── Max items (cart limit)
│ └── Zero-price items
├── Features
│ ├── Gift with purchase
│ ├── Subscription items
│ ├── Personalized items
│ └── Pre-order items
└── Promotions
├── Percentage discount
├── Fixed amount discount
├── Free shipping threshold
└── BOGO promotion
Document your business logic as automated tests:
| Business Rule | Test Type | Configuration |
|---|---|---|
| Gift cards qty = 1 | Field Value |
product_type = "Gift Card" → quantity = 1
|
| GWP has tracking | Property Dependency |
_is_gwp = true → requires _gwp_source
|
| Electronics need warranty | Cart Composition |
product_type = "Electronics" → requires product_type = "Warranty"
|
| Max 3 samples | Quantity |
cart-total, max: 3, filter: product_type = "Sample"
|
Keep tests running automatically while you code. Instant feedback when something breaks.
| Task | Without Devtools | With Cart Panel |
|---|---|---|
| Inspect cart state | Add Liquid, refresh, copy JSON, format | Click Cart tab |
| Rebuild specific cart | 5-10 min manual work | 2 seconds (scenario load) |
| Test 10 cart states | 50-100 minutes | 5 minutes |
| Track cart changes | Custom logging code | Automatic history |
| Validate GWP logic | Manual testing | Automated tests |
| Find rogue cart scripts | Console debugging | Request tracking |
| Share cart states | Screenshots, instructions | JSON export |
No. The devtools only render on unpublished themes for security.
It adds a single Liquid snippet that conditionally loads the devtools JavaScript.
Yes. It works with Basic, Shopify, Advanced, and Plus plans.
Yes. Shopify Theme Devtools is open source.
The Cart Panel in Shopify Theme Devtools transforms cart debugging from a tedious, time-consuming task into a streamlined workflow. Whether you're:
...you'll save hours of development time.
Get started:
npx shopify-theme-devtools init
Tags: #shopify #shopifythemes #shopifydevelopment #liquid #ecommerce #webdevelopment #javascript #debugging #devtools #tutorial
2026-01-14 14:09:29
For many developers, Git feels like a magical incantation. We type git add . followed by git commit -m "fixed stuff", push it to a remote server, and hope for the best. When it works, it’s fantastic. When it breaks, it feels like trying to defuse a bomb while blindfolded.
The key to moving from blind memorization to true mastery lies in understanding what happens beneath the surface. Git isn't just a list of commands; it is a beautifully designed system for managing information. By peeling back the layers, we can build a mental model of how Git actually "thinks."
Our journey begins at the hidden heart of your repository: the .git folder.
Before diving into the folder structure, we need to correct a common misconception. Many people believe Git stores data as a diff—a series of changes recording only which lines were added or removed.
Git doesn't do this. Instead, Git thinks in snapshots.
Every time you commit, Git takes a "picture" of what all your files look like at that exact moment and stores a reference to that snapshot. To stay efficient, if a file hasn't changed, Git doesn't store the file again; it simply links back to the previous, identical version it already has.
If you open your project folder in a file explorer, you might not see it at first. It’s usually hidden because it is crucial that you do not manually mess with its contents.
The .git Folder is your repository.
Everything outside of this folder is just your "working directory"—the temporary sandbox where you edit your current files. The .git folder is the database where Git stores every version of every file, the entire commit history, and all your branches.
Important Note: If you delete the
.gitfolder, you lose your project's entire history, leaving only the "current" version of the files you see on your screen.
While there are many files inside, these three are the most critical for understanding internals:
objects/: The heart of the database. It stores all the content of your files and your history.refs/: This directory stores pointers (references) into the object data, such as branches (heads) and tags.HEAD: A simple text file that tells Git which branch you are currently working on.Git is essentially a key-value data store. You put data in, and Git gives you a unique key to retrieve it later.
The key is a Hash—a 40-character string (SHA-1) generated based on the content. If the content changes even slightly, the hash changes completely. This ensures data integrity: if the hash is the same, you can trust the data is unchanged.
Git stores three main types of objects in the objects/ folder:
A Blob is the simplest object; it just stores the content of a file. Crucially, a Blob does not know the file's name or where it lives in your project. It only knows the raw data.
Pro-tip: If you have two different files (README.md and intro.txt) that both contain the exact text "Hello World," Git only stores one Blob.
If Blobs store content, Trees store structure. A Tree object acts like a directory. It contains a list of entries pointing to:
The Commit object is the wrapper that ties everything into a snapshot in time. It contains:
Understanding these objects unlocks the mystery of the "Staging Area." Let’s track what happens when you save a new file to history.
You create style.css. Right now, this file only exists in your working directory. Git’s database doesn't know it exists yet.
git add)
When you run git add style.css, Git:
.git/objects.style.css should point to that specific Blob hash.git commit)
When you run git commit -m "Added Styles", Git freezes the stage:
👉 Follow, Like & Share if this helped you to understand Git internals
2026-01-14 14:08:33
In the fast-paced world of software development, the choice between headless and real browser testing is more than a technical decision - it's a strategic one that impacts your release velocity, product quality, and team efficiency. Each method serves a distinct purpose in the testing lifecycle, and understanding their nuanced strengths and limitations is crucial for any QA professional or development lead. Drawing from years of scaling automated testing frameworks, I've seen teams thrive by strategically blending both approaches, not by dogmatically choosing one over the other.
Before diving into comparisons, it's essential to define what we're discussing. At its heart, this is a choice between a visible interface and raw, automated efficiency.
Headless browser testing runs automated scripts against a browser engine that operates without a graphical user interface (GUI). Think of it as the browser's brain working in the dark: it loads pages, executes JavaScript, and interacts with the DOM, but it does not paint pixels on a screen.
This approach leverages the same underlying engines (like Chromium or WebKit) as their headed counterparts but skips the computationally expensive step of visual rendering. It's primarily driven via command-line interfaces or automation tools like Puppeteer, Playwright, or Selenium with headless flags. Its primary virtue is speed; by forgoing the GUI, tests can run significantly faster, often 2x to 15x quicker than in a full browser.
Real browser testing, sometimes called "headed" testing, is what most users intuitively understand. It involves automating or manually interacting with a full, visible browser instance - the complete application with tabs, address bars, and developer tools.
This method provides the highest fidelity to the actual user experience because it tests the application in the exact same environment a customer uses. Every pixel is rendered, every CSS animation plays, and every GPU-accelerated effect is processed. It's the gold standard for validating visual correctness and complex interactive behavior.
Choosing the right tool requires a clear view of the trade-offs. The following table summarizes the key differences, which I've validated across countless projects.
| Aspect | Headless Browser Testing | Real Browser Testing |
|---|---|---|
| Primary Strength | Speed & Resource Efficiency | Visual Fidelity & Realism |
| Test Execution Speed | Very Fast (No UI rendering) | Slower (Full rendering required) |
| Resource Consumption | Low CPU/Memory | High CPU/Memory/GPU |
| Visual Debugging | Limited or none; relies on logs & screenshots | Full capability; use of DevTools and live inspection |
| Real User Simulation | Low (Programmatic interaction only) | High (Mirrors actual user interaction) |
| Ideal Use Case | Early-stage functional checks, CI/CD pipelines, API/unit testing | Visual validation, cross-browser/device QA, final user-acceptance |
| Debugging Ease | Challenging; requires interpreting console output | Straightforward; visual context aids immediate diagnosis |
Headless testing excels in environments where rapid, repetitive feedback is paramount. Based on my experience, here are its strongest applications:
CI/CD Pipeline Integration: In continuous integration environments, where tests run on every commit, speed is non-negotiable. Headless tests provide fast feedback to developers without bogging down the pipeline.
Large-Scale Regression & Smoke Suites: When you need to verify that core functionalities work after a change, running hundreds of headless tests quickly can provide essential confidence before deeper, slower testing begins.
Unit and Integration Testing of UI Logic: For developers writing unit tests that involve DOM manipulation or JavaScript execution, a headless browser offers a lightweight, realistic environment without the overhead of a full UI.
API and Backend-Focused Validation: If the test's goal is to ensure data flows, form submissions, or network requests work correctly, the visual layer is irrelevant. Headless mode is perfectly suited.
Despite the allure of speed, some testing imperatives demand the full, visual browser. You cannot compromise here:
Visual and UI Regression Testing: Subtle layout shifts, font rendering issues, z-index problems, and broken animations are almost impossible to catch headlessly. Real browsers are mandatory.
Cross-Browser and Cross-Device Compatibility: A website can pass all headless Chrome tests but fail spectacularly in Safari or Firefox due to rendering engine differences. Only testing on real, headed versions of these browsers reveals these issues.
Complex User Interaction Flows: Testing drag-and-drop, hover states, file uploads, or complex gestures often requires the precise event timing and rendering that only a real browser provides.
Client-Side Performance Profiling: Tools like Chrome DevTools' Performance panel, which are critical for diagnosing runtime jank or slow script execution, require a headed browser.
Final Pre-Release Validation: Before a major launch, the final sanity check must happen in an environment that mirrors the end user's. There is no substitute.
The most effective teams I've worked with don't choose sides; they build a pyramid of quality that leverages both methods strategically. Here's a practical framework:
Begin with a broad base of fast, headless tests. These should cover all critical user journeys, API endpoints, and business logic. Run this suite with every single build in your CI/CD pipeline. Its goal is to provide developers with instant feedback - typically within minutes.
Build a more selective suite of tests that run in real browsers. This suite focuses on visually complex components, critical conversion paths (like checkouts), and high-traffic pages. Run this suite nightly or on demand before staging deployments.
The top of the pyramid is reserved for manual exploratory testing, usability reviews, and final visual acceptance in real browsers across the full matrix of supported devices and browsers. This is where human judgment catches what automation misses.
Managing this hybrid workflow efficiently is key. A unified test management platform like Tuskr can be instrumental here, as it allows teams to organize, schedule, and track results from both manual and automated tests - whether headless or headed - in a single dashboard, providing clear visibility into overall quality.
Modern Tools Bridge the Gap: Frameworks like Playwright and Puppeteer have minimized the differences between headless and headed modes. You can often write a test once and run it in both configurations simply by toggling a launch flag.
Debugging Headless Tests: While challenging, you can mitigate debugging pains. Always configure your headless runs to capture screenshots or videos on failure. Increase logging verbosity and integrate with reporting tools that aggregate logs and assets for analysis.
Infrastructure Matters: Running a large real-browser test grid requires significant resources. Many teams turn to cloud-based platforms (like BrowserStack or Sauce Labs) that provide managed grids of real browsers and devices, eliminating the maintenance burden.
The debate between headless and real browser testing is not about finding a winner. It's about applying the right tool for the right job at the right time. Headless testing is your engine for speed and efficiency, enabling agile development practices and rapid iteration. Real browser testing is your guardian of user experience, ensuring that what you ship is not just functional but polished and reliable.
Adopt a hybrid, layered strategy. Let headless tests be your first line of defense, catching functional regressions quickly and cheaply. Reserve the power of real browser testing for validating the visual and interactive integrity that defines quality in the user's eyes. By mastering both, you equip your team to deliver superior software at the pace the market demands.
2026-01-14 14:05:31
If you've tried to make a full-screen hero video work on iOS Safari, you've probably spent hours reading the same recycled advice that doesn't actually solve the problem. I just burned an afternoon on this, so let me save you the pain.
The problem: You want a background video that fills the entire screen on an iPhone. The bottom keeps getting cut off, or there's a gap, or the content below the fold is hidden behind Safari's toolbar. You Google it. You find 50 articles. None of them work.
What the internet tells you to try:
100vh — Too tall. Safari calculates this based on the viewport with toolbars hidden, not what the user actually sees.100svh — The "small viewport height" that's supposed to fix this. Doesn't work reliably. Tried it. Multiple times. Different ways.100dvh — The "dynamic viewport height" that updates as toolbars show and hide. Causes layout jank and still didn't solve our problem.100lvh — The "large viewport height." Gets closer but still came up short on our iPhone 16 Pro Max.-webkit-fill-available — Only works on WebKit, breaks Chrome, doesn't work when nested, and half the implementations out there are wrong anyway.window.innerHeight — Same problem. innerHeight gives you the current visible height, which is the short one. You're back where you started.env(safe-area-inset-bottom) with viewport-fit=cover — Useful for padding content away from the notch and home bar, but doesn't fix the fundamental height issue.I tried all of these. I tried combining them. I tried the "triple fallback" approach with CSS custom properties. I probably went through 10-12 iterations over three or four hours. The video kept coming up short on taller phones.
What actually worked:
.hero {
min-height: calc(100lvh + 60px);
}
That's it. Make it too tall on purpose. Then adjust your content positioning to account for it — we bumped bottom-positioned elements from bottom: 15% to bottom: 25% on mobile so they sit comfortably in the visible area on initial load.
Is this elegant? No. Does it feel like a hack? Absolutely. But here's the thing: users don't see your CSS. They see whether your hero video fills their screen or looks broken. "Too tall" means they scroll past it by a few pixels and never notice. "Too short" means the first thing they see is a janky, cut-off hero that makes your site look amateur.
The web development community keeps chasing spec-compliant solutions that Apple keeps breaking with every iOS release. Meanwhile, the simple answer — just add some extra height and adjust your content — isn't anywhere in the search results because it doesn't feel like a "real" solution. But it ships. It works across devices. And it took 30 seconds to implement after we stopped trying to do it the "right" way.
If you're stuck on this problem, stop fighting Safari's viewport quirks. Make your hero too tall, push your content into the visible area, and move on. You've got better things to build.
I'm not claiming this is the best solution — just the one that actually worked after a frustrating afternoon. If you've found something cleaner that reliably works across iOS devices, drop it in the comments. I'd genuinely love to be proven wrong on this one.
That should do it. Good luck — hopefully it helps some people and maybe someone does have a better answer buried somewhere.
2026-01-14 14:02:01
When people hear “dark web monitoring”, they often assume hacking, buying databases, or digging through stolen data.
In real-world defensive security work, none of that happens.
Practically, dark web monitoring is threat watching and signal analysis.
Security researchers treat the dark web as one more intelligence surface—similar to Twitter, Telegram, GitHub, or paste sites—where threat actors publicly announce what they claim to have.
The job is not to access data, but to evaluate the claim.
Researchers passively monitor underground forums, leak boards, and breach channels in read-only mode.
Monitoring is keyword-driven:
When a claim appears, only high-level details are recorded:
No interaction.
No data access.
Most claims are discarded early due to:
Only plausible claims move forward.
If masked samples are shared, researchers examine:
Focus: Does the schema make sense?
Not: Who the data belongs to.
Claims are cross-checked using open sources:
This avoids false alerts and misinformation.
Researchers evaluate how the data could be abused:
This drives advisories, not exploitation.
Findings are shared as:
Raw data is never accessed, downloaded, or published.
Researchers do not:
Dark web leak monitoring is signal analysis, not data access.
The work focuses on early detection, risk evaluation, and responsible communication—nothing more.