Paul Clegg

I put together a step-by-step guide to help you implement LLM Optimisation the right way for E-commerce. In this carousel, you’ll find the high-level overview. The full version includes: → How to generate a structured product feed (CSV, JSON, XML) with the right attributes: title, GTIN, MPN, price, availability, and product URLs → How to apply Schema . org Product markup using JSON-LD, with full code examples → How to configure your robots.txt to allow GPTBot, OAI-SearchBot and PerplexityBot access to your PDPs and feeds → How to prerender JS-heavy product pages using static snapshots or SSR → Where and how to submit your feed to Perplexity’s Merchant Program and OpenAI’s early access initiative → How to debug AI visibility using server logs, schema validators, and live prompt testing inside LLM tools If you’re working on e-commerce, SEO, or growth, this is where things are moving. 💬 Comment or DM me, and I’ll send you the full guide. 📌 Save this post if you're not ready yet but know you'll need it.

582

915 Comments

One of the biggest misconceptions I hear about serverless is this: "It’s just a spaghetti of Lambda functions calling each other." Yes, I’ve seen that happen. When it does, it’s ugly, and it usually comes from inexperience and lack of design. But that’s not what serverless architectures are supposed to be. It’s like saying "cats are animals that poop on your bed", sure, accidents happen (…probably 😹), but that’s not the norm or the expected behaviour! So, what does a well-designed serverless architecture actually look like? From a bird’s-eye view, pretty much the same as what you'd build with containers or EC2: • Separate accounts per team/workload • System is decomposed into independent services • Every service owns its own data (no shared DBs) • Services are loosely coupled through events • Centralised logging and observability Whether I have an API (synchronous communication) or use events (asynchronous communication) does not depend on whether I use Lambda vs. containers. A serverless architecture doesn't have to be event-driven. Equally, an event-driven architecture can run on containers or EC2. Those are orthogonal architectural choices. Inside each service, I use the serverless-first mindset to decide on my tech stack, e.g. • Prefer DynamoDB over RDS • Prefer API Gateway of ALB • Prefer Lambda functions over containers or EC2 • Prefer EventBridge over Kafka The guiding principle is simple: pick the service that does the most heavy lifting. And with serverless technologies like Lambda, you get built-in multi-AZ redundancy; scalability; reduced attack surface; no need to manage infrastructure; simplified deployment; and, pay-per-use pricing. So no, you don’t expose "a bunch of Lambdas" as your service boundary. That’s not the goal. That’s just a mistake.

376

14 Comments

When developers use "tech debt" to refer to any code that they didn't write (and some they did), how do you decide where to invest? I find this 2x2 quite helpful for framing the discussion. In many situations, the trouble with debt is not the principal, it's the interest. When it comes to technical debt, that's the increase in the cost of change that's created by the debt. And you're not really required to pay until you're working in that area. The axis for "ease of change" includes everything it takes to get a change into production. Is the code easy to reason about? Do you trust the tests? Is the pipeline fast? Anything that makes it harder is bad. However, if the system or component isn't undergoing change, it's not hampering your business as badly. Hence the need to incorporate "desired rate of change." In other words, if we could, how much work would we be doing in this area? If something is slowing you down or blocking you in an area of your system that presents critical opportunities to your business, it's probably time to get it cleaned up. Like any 2x2, it's pretty simple. But I assure you someone, somewhere, is arguing right now about how to improve a thing that's already good and pretty stable. PS. I used this chart in a workshop at LeadDev's LDX3 and it led to some great discussions. If you'll be at LeadDev in NYC or Berlin this year, come have a chat. The workshop will be repeated at both.

61

2 Comments

You can make mocks of a video game you're designing with JSON + Veo3 Here's my First Person View "Catpetter" game 1. You can use my video as a link to different chatbots (I use Kimi2, ChatGPT or Claude) to write a JSON or YAML or a particular video. Then you can edit it if you need to. 2. You can also write this prompt by hand for Kimi 2 or ChatGPT or Claude: "Make me JSON of a FPV of a video game I'm creating: petting cats and the more cats you pet the more score you get. It's set up in New York." You can describe your video game concept. 3. I use Firefly Boards to generate all my videos with Veo3. The licking part I generated with Veo2 (it simply worked better that the ending of Veo3). I like switching tools. Sometimes I go to Express to put things together. Screenshots in comments JSON prompt + instructions

106

20 Comments

New in Chrome DevTools: Instantly check CSS feature compatibility with Baseline! Exciting news for web developers! Chrome DevTools now displays the Baseline status for CSS properties right in the Elements panel - Baseline gives you clear info about which web features are ready to use in your projects today. This fantastic new feature, contributed by Google Developer Expert Alexey Rodionov, provides a quick and easy way to see if a CSS property is ready for production. Now, when you hover over a CSS property, you'll see its Baseline status: - Widely available: The feature is supported by all core browsers. - Newly available: The feature has recently become supported by all core browsers. - Limited availability: The feature is not yet supported by all core browsers. This update, available in Chrome 140 and above, also shows the interoperability date for widely or newly available features, so you can see how long a property has been broadly supported. This will be a huge time-saver for debugging and ensuring a consistent experience across browsers. #programming #softwareengineering #web

286

15 Comments

🚀 New Release from ComfyUI - Subgraph Publishing & Selection Toolbox Redesign ComfyUI 0.3.63 update unlocks two powerful enhancements that make working with this tool even more fluid and modular: ✨ What’s New ⁉️ 1. 𝗦𝘂𝗯𝗴𝗿𝗮𝗽𝗵 𝗣𝘂𝗯𝗹𝗶𝘀𝗵𝗶𝗻𝗴 You can now save any subgraph as a reusable component in your node library. Use the publish icon or menu in the Selection Toolbox, then find it under Node Library → Subgraph Blueprints. When you need to tweak the behavior, just edit and update it like a regular node. This change elevates composability and reusability in your workflows. ComfyUI 2. 𝗦𝗲𝗹𝗲𝗰𝘁𝗶𝗼𝗻 𝗧𝗼𝗼𝗹𝗯𝗼𝘅 𝗥𝗲𝗱𝗲𝘀𝗶𝗴𝗻 The UI of the selection toolbox has been refreshed with clearer icons and an expandable menu. This redesign isn’t just aesthetic — it paves the way for future enhancements and more flexible workflows. ComfyUI Blog 🔍 𝗪𝗵𝘆 𝗧𝗵𝗶𝘀 𝗠𝗮𝘁𝘁𝗲𝗿𝘀 𝘔𝘰𝘥𝘶𝘭𝘢𝘳𝘪𝘵𝘺 & 𝘙𝘦𝘶𝘴𝘦: Subgraphs can now live as first-class entities—no recreating from scratch each time. 𝘉𝘦𝘵𝘵𝘦𝘳 𝘜𝘟: Cleaner UI and menu structure help speed up experimentation and iteration. 𝘌𝘹𝘵𝘦𝘯𝘴𝘪𝘣𝘪𝘭𝘪𝘵𝘺: The foundation is laid for even richer features down the line. As someone who values efficient, scalable design in creative and engineering workflows, I’m excited to see how this deepens what’s possible in ComfyUI. #ComfyUI #UIUX #subgraphs #ai #monks

98

4 Comments

Nice new addition to Rails- Rails introduces a powerful new feature allowing associations to be marked as deprecated, with sophisticated reporting mechanisms to safely identify and clean up their usage across all environments. Before this enhancement, removing associations like 'has_many' or 'belongs_to' posed risks, requiring developers to delete or modify them and heavily rely on tests or manual checks to catch all usage. This was especially perilous in production settings with incomplete test coverage or mocked associations. What’s new? Rails now includes a ':deprecated' option in association declarations. When marked, Active Record will issue a warning each time the association is used, significantly enhancing the safety and efficiency of deprecating associations before removal. This proactive approach helps prevent surprises and app disruptions. Developers can manage how Rails addresses deprecated associations through three modes: - ':warn' (default): Logs a warning via the Active Record logger, potentially including clean backtraces filtered by 'Rails.backtrace_cleaner' to trace the usage source. - ':raise': Raises an 'ActiveRecord::DeprecatedAssociationError', beneficial for immediate detection of deprecated usage in test and dev environments. - ':notify': Emits an 'ActiveSupport' notification ('deprecated_association.active_record'), ideal for integration with monitoring tools like Sentry or New Relic, offering detailed payloads such as reflection, message, location, and optional backtrace. This behavior is globally configurable, ensuring consistent deprecation handling throughout your Rails application, simplifying deployment and scaling deprecations securely. 🔗 Read the full article here: https://lnkd.in/eKM67Exr

56

1 Comment