# Craig Antolick — Full Content Index > All blog post content inline. Generated from query-index.json for LLM indexing. > Posts are sorted newest first. Source: https://www.craigantolick.com Index: https://www.craigantolick.com/llms.txt --- ## [Agent-Driven Block Compilation and Compression for EDS](https://www.craigantolick.com/blog/agent-driven-block-compilation-and-compression-for-eds) **Date:** April 2026 **Category:** Edge Delivery **Tags:** ai-agents, edge-delivery-services, buildless, performance, agent-workflows, developer-productivity Agent-driven workflow for compiling and compressing EDS blocks without introducing a traditional build pipeline. Agent-Driven Block Compilation and Compression for EDS April 2026 In EDS, you typically do not rely on a traditional build pipeline. The platform leans on native JavaScript, browser capabilities, and edge delivery to handle performance, which removes much of the need for bundling and heavy optimization steps. https://www.aem.live/developer/architecture That works well in practice, but compression still matters. Even without a build system, smaller files mean less data over the wire and faster load times. The challenge shows up once you introduce agent-driven development. You still need code that is readable and maintainable, but you also want output that is optimized for production. In a buildless model, there is no obvious place for that transformation to happen. This workflow addresses that gap. Instead of introducing a build step, the repo uses a familiar pattern with two versions of the code: readable source and compressed output. The difference is that the agent is responsible for generating both. I wanted to see if this actually makes a difference, so I pushed compilation and compression into the repo itself and compared the results between main and a branch where blocks are compiled and compressed as part of the workflow. Page load timing improved. Metric minify main Change onContentLoad 149 ms 177 ms -28 ms onLoad 174 ms 206 ms -32 ms That is roughly a 30ms improvement without changing any runtime behavior. Looking at uncompressed sizes shows where the gains actually come from. File minify main Change Smaller header.js 2,678 5,727 -3,049 -53% related-posts.js 2,337 4,120 -1,783 -43% reading-time.js 758 1,589 -831 -52% footer.js 361 700 -339 -49% header.css 4,214 5,365 -1,151 -21% related-posts.css 1,068 1,252 -184 -15% reading-time.css 237 295 -58 -20% JavaScript is where most of the impact shows up, around 40 to 50 percent smaller across the blocks we own, while CSS moves less as expected. What matters more is transfer size. File minify main Change header.js 1,444 2,127 -683 related-posts.js 1,498 1,949 -451 reading-time.js 892 1,110 -218 footer.js 682 802 -120 header.css 1,538 1,691 -153 Each file is smaller over the wire, and it adds up across the page, which is what shows up in the timing improvements. It is also worth calling out what did not change. Shared assets like aem.js, styles.css, the hero image, and query-index.json are identical between branches, which confirms that only block-level code is being optimized. At a high level, the repo treats block code in two forms. Readable source lives in .src.js and .src.css, while compiled .js and .css files are what actually get served. The agent is responsible for keeping those in sync. The workflow itself is simple. Edit the source files, run the minify step, verify outputs, check size reports, enforce budgets, and commit. What changed is not the tooling but the responsibility. The agent is expected to produce code that is ready to ship, which includes compiling, compressing, and validating output before commit. This works especially well in EDS. The platform is already buildless, blocks load independently, and pages only load what they need. That makes block-level optimization more relevant than bundle-level optimization. I also tested this with a new code block that touched everything, including source, compiled output, and real content usage. Existing blocks got smaller with compression, while the new block added weight because it introduced new behavior. The difference is that the tradeoff is now visible and measurable. This also lines up with where EDS is going. Adobe is already documenting how AI coding agents interact with EDS projects. https://www.aem.live/developer/ai-coding-agents#useful-tools-for-ai-agents There are also supporting projects emerging around this model. https://github.com/cloudadoption/helix-mcp https://github.com/upstash/context7 Agents are expected to operate on repositories and produce usable output, and this workflow fits that model. The repo enforces a few simple rules. Blocks we own follow the workflow, core runtime code does not, scripts and styles stay upgradeable, artifacts are regenerated before commit, and budgets are part of validation. This pattern works if you want better performance discipline without introducing a full build system. It keeps source readable, produces compressed output, fits naturally with agent workflows, and does not make future upgrades harder. The point is simple. If agents are writing the code, they should also be responsible for getting it ready to ship. --- ## [Making Edge Delivery AI-Readable (Without Rebuilding Everything)](https://www.craigantolick.com/blog/making-edge-delivery-ai-readable) **Date:** April 2026 **Category:** Edge Delivery **Tags:** ai-tools, ai-workflow, edge-delivery-services, migration, developer-productivity, llm, cloudflare, structured data You don’t need new infrastructure to make EDS LLM-friendly, you just need to expose what you already have the right way. Making Edge Delivery AI-Readable (Without Rebuilding Everything) April 2026 Why this matters now AI agents are becoming real consumers of the web. GPTBot, ClaudeBot, PerplexityBot, and internal enterprise pipelines are all crawling content. And they are doing it the same way search engines have for years: raw HTML, no JavaScript, no browser rendering. That creates a problem. Most modern sites assume a browser. They assume JavaScript will run. They assume content can be assembled at runtime. AI agents see none of that. If it is not in the HTML response, it does not exist. How agents actually find your content There are two signals that matter. The first is still structured data. JSON-LD in the head tells an agent what a page represents. That part has not changed. The second is newer. Agents are starting to look for site-level indexes like llms.txt. These act as a simple, crawlable map of your content. Those indexes are often exposed through links in the head: rel=“alternate” type=“text/plain” title=“LLMs.txt” href=”/llms.txt” rel=“alternate” type=“text/plain” title=“LLMs-Full.txt” href=”/llms-full.txt” This is the entry point. If you do nothing else, make it easy to discover. The constraint everything falls out of AI agents do not execute JavaScript. That one rule simplifies the architecture a lot. Anything you want an agent to understand has to be: in the HTML directly accessible not dependent on runtime execution This is the same constraint SEO has always had. The difference is the depth of data now expected. What EDS already gives you One of the reasons this pattern works well with EDS is that most of the pieces already exist. On the page side, JSON-LD is handled as content. You add it to metadata and it is rendered into the HTML at publish time. No extra work required. On the site side, you already have a full content index. query-index.json is generated automatically and used for feeds and related content. That means you are not starting from scratch. You already have both page-level meaning and site-level structure. The only thing missing is how that structure is exposed. The gap query-index.json is useful, but it is not how most AI agents consume content. They expect something simpler. Something predictable. Something they can crawl without needing to interpret an API. That is where llms.txt fits. The key shift is this: You are not creating new data. You are reshaping what already exists. Turning the index into something agents can read This is where the CDN edge comes in. EDS handles rendering. It is not responsible for transforming data into alternate formats. A Cloudflare Worker sits in front of EDS and does that transformation on demand. Here is the flow: A request comes in for /llms.txt The Worker fetches /query-index.json from EDS The Worker formats the response as plain text The result is cached and returned That is the entire system. What the Worker actually does At its core, the Worker is just mapping fields. Here is a minimal implementation: export default { async fetch(request, env) { const url = new URL(request.url); if (url.pathname === "/llms.txt") { return handleLLMs(env, false); } if (url.pathname === "/llms-full.txt") { return handleLLMs(env, true); } return fetch(request); } }; async function handleLLMs(env, includeBody) { const res = await fetch(${env.EDS_ORIGIN}/query-index.json); const json = await res.json(); const lines = json.data.map(entry => { let output = ${entry.title}\n${entry.path}\n${entry.description || ""}; if (includeBody && entry.body) { output += `\n${entry.body}`; } return output; }); return new Response(lines.join(”\n\n”), { headers: { “content-type”: “text/plain”, “cache-control”: “public, max-age=3600” } }); } There is nothing complex here. That is the point. You are not building a system. You are exposing one that already exists. What you end up with Once this is in place, your site exposes two useful entry points. The first is a lightweight index with titles, URLs, and descriptions. The second is a full index that includes the body content. Both are: server-rendered crawlable always in sync with your content And they require no additional data source. Where JSON-LD fits into this The Worker solves the site-level problem. JSON-LD solves the page-level problem. In EDS, this stays simple. Add a metadata row in your document that includes your JSON Object Metadata | json-ld | “@context”:“https://schema.org”,”@type”:“BlogPosting”,“headline”:“AI-Readable Edge Delivery”} EDS renders it into the HTML automatically. That is all you need. You can generate schema dynamically if you want, but in most cases that just adds complexity. Keeping it authored alongside the content is cleaner and easier to maintain. Putting it together There are really only three moving parts: JSON-LD defines what each page is query-index.json defines what the site contains the Worker exposes that structure in a crawlable format Each layer does one job. That separation is what keeps the system simple. Final thought The interesting part here is not the Worker. It is recognizing that you already have the data. Most implementations over-engineer this. They build pipelines, duplicate indexes, or try to generate everything dynamically. EDS already solved the hard part. The pattern is just about exposing it correctly. --- ## [From Developer to Orchestrator: What I Learned by Treating AI Agents Like a Team](https://www.craigantolick.com/blog/ai-agent-swarm-dev-to-orchestrator) **Date:** April 2026 **Category:** Edge Delivery **Tags:** ai-agents, ai-workflow, prompt-engineering, edge-delivery-services, architecture, developer-productivity A practical exploration of how splitting AI into specialized agents improves feature delivery, reduces rework, and shifts the developer role toward orchestration. From Developer to Orchestrator: What I Learned by Treating AI Agents Like a Team April 2026 The interesting shift is not that AI can write code. It is that it can behave like a team, even when there is only one person involved. I ran into this while building a related posts sidebar for blog pages. The goal was simple. The outcome was not. What started as a straightforward feature turned into an experiment in how multiple agents can work together, and more importantly, how to coordinate them. The Problem I Was Running Into I started the way most people do. One prompt. One agent. End to end feature delivery. It looked efficient. It was not. The agent would: design the architecture plan the implementation write the code make assumptions about content and indexing All in one pass. The result was familiar: layout decisions baked into logic incorrect assumptions about metadata mismatches between authored content and indexed data debugging happening in code instead of the system It felt fast, but every iteration required going back and undoing earlier decisions. The Experiment Instead of trying to improve the prompts, I changed the model. I treated the agents as separate roles. This was not about scaling a team. It was about understanding how specialization changes outcomes, even when everything is driven by a single person. The flow became: Architecture agent Planning agent Implementation agent Consumer agent Reviewer agent Each step had a clear boundary. No overlap. No shortcuts. How the Agents Actually Worked Together Architecture agent defines the system This agent did not write code. It focused on: page structure authored content contract metadata and indexing behavior For the related posts feature, this meant: using a blog-post template for layout introducing a related-posts block relying on tags via query-index.json This step forced clarity before anything else happened. Planning agent makes it executable The planning agent translated ideas into: exact file changes required data fields validation steps This is where most of the hidden complexity showed up: handling no tags handling no matches excluding the current page Catching this here meant it never became a debugging problem later. Implementation agent just executes By the time I got here, there was nothing left to figure out. The implementation became: predictable minimal aligned with EDS The agent was not making decisions. It was applying them. Consumer agent checks clarity This step was not about code. It looked at the feature as: a reader a content author an AI consumer This exposed things I would not have caught otherwise: unclear headings weak relationships between content confusing empty states Reviewer agent checks risk The final pass focused on: bugs regressions indexing assumptions This is where I validated the system, not just the feature. What Changed The biggest change was not speed. It was how much rework disappeared. Before implement realize assumptions were wrong debug rewrite After define plan implement once validate The Role Shift This is where the model clicked for me. I was not acting like a developer anymore. I was acting more like a coordinator. Defining: roles sequence expectations Letting the agents handle: architecture thinking planning implementation validation It started to feel very similar to running a Scrum team, except the entire team was AI driven. Why This Matters Each agent is good at a specific type of thinking. None of them are good at everything at once. By separating responsibilities: assumptions surface earlier decisions become explicit implementation becomes cleaner And most importantly: the system becomes predictable. Takeaway This was not about building a feature. It was about understanding how to structure AI work. If everything runs through one agent, it behaves like a single developer under pressure. If the work is split into roles, it behaves like a coordinated team. Even if that team is just one person orchestrating multiple agents. --- ## [AI in VS Code helped me modernize a 3-year-old EDS fork in under 2 hours](https://www.craigantolick.com/blog/ai-vscode-eds-migration-post) **Date:** March 2026 **Category:** Edge Delivery **Tags:** ai-tools, ai-workflow, edge-delivery-services, migration, developer-productivity, vscode A firsthand account of using AI in VS Code to modernize a legacy fork for Edge Delivery, emphasizing prompt precision, iterative validation, and preserving custom work without a full rewrite. AI in VS Code helped me modernize a 3-year-old EDS fork in under 2 hours March 2026 In April 2023, I forked the EDS boilerplate so I could ramp up on what Edge Delivery Services actually is. I learn best by building, so I rebuilt my personal site on top of that fork. The goal was not perfection. The goal was to see the patterns, build some custom styles, and create my own components so I could understand the moving parts. Then life happened. Like most personal projects, it sat for a while. When I came back and started trying to use newer EDS capabilities, I realized how much innovation had happened since I forked. The gap was bigger than I expected. The project still worked, but it was clearly not current with the latest boilerplate patterns. At that point I had two options: Spend a weekend doing manual diffs and risky merges. Use AI in VS Code as a migration partner. I chose option 2. How I prompted AI I did not use one giant prompt. I used short prompts in sequence, like pairing with an engineer: "Do a pre-analysis and tell me the safest path to parity." "Create a branch strategy and migrate in batches." "Keep parity first, then preserve my custom work." "Run lint and fix issues as you go." "Document what changed and what features are now enabled." "Trim non-runtime files so the repo stays clean." That flow worked really well. Each prompt had one clear objective. How the plan came together The biggest win was early: AI identified that my repo and upstream did not share clean merge history, so a direct merge would create noise and conflict. Instead, it recommended an upstream-first parity branch and then moved my project-specific deltas in controlled batches. The migration happened in stages: Baseline config and identity files Blocks and styles Runtime scripts and plugin layer Validation and cleanup After each stage, it validated with lint, then fixed what was needed before moving on. That removed a lot of risk. How documentation stayed in sync I did not want "tribal knowledge" after the migration, so I asked AI to keep a succinct migration note and feature checklist as it worked. That gave me a running log of: Why decisions were made What was complete What was pending What was runtime-required vs optional baggage This part was surprisingly useful. It turned the migration into something I can maintain later without re-discovering everything. What features this migration enabled The update brought my project much closer to current EDS expectations while preserving my custom site behavior. Highlights: Modernized runtime wiring aligned with current boilerplate patterns Experimentation integration for audiences, campaigns, and experiments Universal Editor support for content patch/redecorate flow Rich text editor instrumentation support Sidekick library and sidekick config restored Lint-clean codebase after migration Asset cleanup (removed non-runtime SCSS/LESS/docs bloat while keeping required runtime files) In short: parity foundation restored, customizations retained, and future upgrades should be much easier. Time to value The whole process took less than 2 hours. Not because migration is trivial, but because AI kept the work structured: Analyze first Plan in batches Validate continuously Document as you go Remove non-essential files That combination is the difference between "I should do this someday" and "done today." Final thought If you have an older EDS fork, this approach is worth trying. Use AI in VS Code like a technical partner, not a magic button: Keep prompts specific Make decisions in small steps Validate after every change That is how I got a 3-year-old fork caught up without a full rewrite and without losing my custom work. --- ## [Spreadsheet as a service](https://www.craigantolick.com/blog/spreadsheet-as-a-service) **Date:** August 2025 **Category:** EDS **Tags:** edge-delivery-services, aem, google-sheets, content-management, api, javascript A demonstration of using Google Sheets as a dynamic data source for API queries, showcasing how named tabs like “shared-visited” can drive structured content delivery for Edge Delivery Services. Spreadsheet as a service August 2025 As an author of a content management system, sometimes you don’t have the time to wait for a development team to build an API. Even when they set up the API endpoint, every update requires a database change request or some synchronization job to occur. What if, as an author, you could create your own JSON output without the complexities of building out an API? To learn by doing, I embarked on a proof of concept: I wanted a page to track my progress through Minnesota’s State Parks. I needed to capture the location, title, and whether or not I had visited each park. So, I quickly coded a little app. The results ended up here: https://www.craigantolick.com/mn-state-parks The Google Sheet manages all the content for the service: Once published, it is cached and performant: https://www.craigantolick.com/parks.json AEM Edge Delivery allows you to use multiple sheets with query parameters to pull in specific content. You can access them by appending query parameters such as ?sheet=visited, ?sheet=yet, or ?sheet=visited&sheet=yet. A wonderful feature is the ability to create Google Sheet functions to build out queries, enabling centralized management. In the image below, I have a QUERY function that filters data from columns A-O in "Sheet" to show only rows where column O equals TRUE. It returns all columns for the matching rows while treating the first row as headers. This setup allows me to reuse content and manage it from one place. Since I have the sheet named shared-visited, I can use the query parameter ?sheet=visited to retrieve the relevant content: https://www.craigantolick.com/parks.json?sheet=visited --- ## [Throwback Thursday: Flash Game](https://www.craigantolick.com/blog/throwback-slingshot-swamp) **Date:** Jun 2025 **Category:** Throwback **Tags:** throwback, flash, game-development, animation A nostalgic look back at the Slingshot Swamp Flash game, reflecting on its animation style and gameplay as part of a broader Throwback Thursday series. Throwback Thursday: Flash Game Jun 2025 At Accompany Software, I was working on animating a frog to play with motion and see how the timing of keyframes worked in Macromedia Flash. This was before Adobe acquired it. My coworkers chimed in and said we should see if we can build a game. So I drew out the and animated the additional character for the 3 levels and a Boss. We only had blackberries and flip phones, so no mobile support. After I had left and the browser plugin was no longer supported, I thought this content was lost. In talking to my kids, I mentioned I had built a few different games. So I did some digging and found a copy of it. With a little reconnaissance work, I made a copy that can be played here: https://flash.craigantolick.com/slingshot-swamp.html --- ## [Top 3 things I learned when implementing my first Edge Delivery](https://www.craigantolick.com/blog/top-3-things-i-learned-when-implementing-edge-delivery) **Date:** December 2024 **Category:** EDS **Tags:** edge-delivery-services, aem, autoblocks, cdn, migration A practical reflection on rebuilding a legacy site with Edge Delivery, highlighting autoblocks, table-based layout structuring, and CDN integration for faster iteration and content updates. Top 3 things I learned when implementing my first Edge Delivery December 2024 Deciding to rebuild my old website with Edge Delivery was driven by the urge to confront real-world challenges head-on. While starting off with a boilerplate is useful, diving into the practical implementation of a unique design reveals the true hurdles. Here’s what I learned along the way: Autoblocks Are Invaluable: The page layout wasn’t too complicated, yet the simplicity and speed at which I could create tables and refresh content using autoblocks were game-changers. These tools proved to be incredibly efficient for quick updates and modifications. A New Appreciation for Tables: Having avoided tables for years, I’ve now recognized their worth. Tables provide a clear and defined structure for content placement, a more reliable method than guessing the sequence of content chunks. Perhaps my comfort with the intuitive drag-and-drop nature of AEM has made me a bit complacent, but I’ve come to see the utility of tables in organizing content effectively. Smooth CDN Integration: Incorporating my existing CDN into the project was more straightforward than anticipated, thanks to well-documented guidance. This allowed me to cache my pages effectively, although the process for clearing the cache wasn’t flawless. During periods of rapid iteration and adjustments, I found myself manually purging the cache through my CDN’s interface to ensure updates were applied correctly. Does my Edge Delivery site mirror my personal site exactly? Not quite. The original utilized an older version of VueJS and featured experiments with lazy loading as users scrolled. I scaled back on many of these elements to focus squarely on mastering Edge Delivery and spotting potential snags. I’m looking forward to delving deeper into experimentation and exploring the full capabilities of Edge Delivery. Explore more at https://www.aem.live/ --- ## [Top 3 things I learned at Imagine 2019](https://www.craigantolick.com/blog/top-3-things-i-learned-at-imagine-2019) **Date:** May 2019 **Category:** Commerce **Tags:** ai, ecommerce, seo, docker, pim, magento Key takeaways from the Imagine 2019 commerce conference, emphasizing the importance of product imagery, local Docker setups, and centralized product information management (PIM) for omni-channel success. Top 3 things I learned at Imagine 2019 May 2019 1. Images are important for SEO A.I. is more scalable than people. The presentation on how images can increase your visibility due to image search and how Adobe Sensei can automate that process was amazing. The AI has the ability to determine what the product is in the image, based on the percentage how much real-estate it takes up. The days of image recognition that requires the product to face the camera are over. 2. Local Docker instance for managing Magento Cloud I had set up a local Docker for AEM development a few years ago using this repo as the base. In the long run we ended up using Vagrant, but that is a different write up. The Magento Cloud set up for docker is perfect for containers. The way you can split up php code, ElasticSearch, and the database into their own separation of concerns makes perfect sense. The challenges I struggled with, which might be due to the lack of experience, was how much the set up depended on the composer. My assumption is that the solution was easier for their current development base to keep moving forward with something they are familiar with. Overall the training was great for me as an overview. 3. A PIM is a necessity for products When your company reaches a certain level, your products are rarely configured in one system. Each system ends up defining the what and how a product is configured. This limits the ability for the marketing team to "brand" the product. If your product catalog only supports dimensions and specs, then you are limited on how you can describe a product. Most marketing teams end up putting together a hodge-podge of spreadsheets and sending that over to the development team. This solution becomes more complicated once you want to talk omni-channel. There is no source of truth. Just a bunch of systems with their own version. There are other options, like CRUD, MDM, or more spreadsheets, but having a tool that allows a Marketer to customize how they want to talk about the product is key. This gives them options to have content on the website, eCommerce solution, email, or print coming from one system. --- ## [Throwback Thursday: 64 PDAs Display Wall](https://www.craigantolick.com/blog/throwback-thursday) **Date:** Feb 2019 **Category:** Throwback **Tags:** throwback, flash, animation, digital-signage, hardware A nostalgic reflection on building a PDA-powered digital signage wall using Vikuiti film, showcasing early innovation in interactive displays and the challenges of delivering a large-scale tech demo. Throwback Thursday: 64 PDAs Display Wall Feb 2019 At Accompany Software, I worked on a display for 3M to display their Vikuiti product line at SID 2003 (Society for Information Display). We managed to build an array of 64 PDA's that made up a display wall. We also were able to create animations that would span the entire length. Each PDA has its own processor. What we ended up building was a Flash based application with a modified XML server that would scale to the dimensions of the PDAs. Over the serial port we would trigger a byte that would start the animation in motion. We found that traffic over USB wasn't instantaneous. At one point we did flush how to motorize the PDAs as well with synchronized animation. This is a combination of using 3D Studio Max and video. I was able to build a simulated armature and output the rotation degrees so our motors could use it. However, time, budget and sleep cut that from scope. This project provided lots of roadblocks and challenges and though 15+ years ago is still a fond experience. --- ## [Screenly.io OSE](https://www.craigantolick.com/blog/screenly) **Date:** Feb 2019 **Category:** Digital Signage **Tags:** digital-signage, raspberry-pi, home-automation, open-source A personal exploration of open-source digital signage using Screenly OSE, highlighting its simplicity, offline capabilities, and suitability for home automation and workplace displays. Screenly.io OSE Feb 2019 I like the idea of Echo Show and the Google Hub. It is a quick look at the weather and what is my day's agenda. What I am not crazy about is what I might be giving up for convenience. (Google says 'hidden' microphone in Nest product never intended to be a secret) What I really want to know is if my kids need lunch and to wear their school t-shirt. In other words, they are overkill for what I need. I did some research and found lots of great ideas. I narrowed it down to two. The first is the "Magic Mirror". It is simple and meets my needs. I can skip the mirror part pretty easily. The other option I landed on was digital signage. I had some experience updating the content on the Navori player at work. I read and understood the concept of what AEM Screens was about. I ended up finding Screenly. What I liked about digital signage was the offline option. I wouldn't have to run a constant connection to the internet if I wanted to cycle through some photos, or an inspiring message. The best part, they support the open source community with an OSE version. This isn't going to be a "how to" article. The instructions were very straightforward. You can read more about Screenly's OSE version here: https://www.screenly.io/ose/. I ended up using the grabbing the release: https://github.com/screenly/screenly-ose/releases and installing the image via etcher https://www.balena.io/etcher/ --- ## [Process Result](https://www.craigantolick.com/blog/process-result) **Date:** February 2018 **Category:** Thought Leadership **Tags:** productivity, prioritization, personal-development, leadership, emotional-intelligence A reflection on using the “Big Rocks” metaphor to improve task prioritization, personal discipline, and process alignment—emphasizing checklist habits and self-forgiveness to drive better organizational outcomes. Process Result February 2018 “Process is a result of a lack of discipline” Steven R. Covey wrote in First Things First prioritizing your "Big Rocks". The gist of the story is that your time is a limited vessel. You need to put your tasks into that vessel. Big Rocks represent priorities. Sand represents the little things, like email, instant messaging, internet browsing, chasing down trivial questions, etc. If you fill the vessel with the sand, the vessel fills up. When you try to squeeze in the "big rocks" or important tasks in that vessel, it is already full with no room. When you put your "big rocks" in first, there is room between them to fit in the sand too. Check out the video Big Rocks The concept is always easy to understand. The challenge is the discipline putting in practice. My best results are when I write down my tasks for the day as a checklist. I place an asterisk next to the most important. There are many days I fail, and that is when forgiving yourself comes into play. Trying over and over is how we get better. If we don't manage ourselves, we end up getting process to force the results the organization wants to see. --- ## [Influential Engineer](https://www.craigantolick.com/blog/influential-engineer) **Date:** October 2017 **Category:** Thought Leadership **Tags:** leadership, communication, influence, soft-skills A reflection on applying six core influence principles; reciprocity, scarcity, consensus, consistency, authority, and likability, to improve leadership communication and elevator pitches in technical environments. Influential Engineer October 2017 I visited a NFJS session to help me work with our leadership. Sometimes logic and reason isn't the best way to make your case when you need something. You must learn how to deliver an elevator pitch. The pitch needs to describe what problem you are going to solve and what the outcome will be. The 6 principles of influence are: Reciprocity Scarcity Consensus Consistency Authority Being Liked --- ## [VueJS evaluation](https://www.craigantolick.com/blog/vuejs) **Date:** October 2017 **Category:** JavaScript **Tags:** javascript, vuejs, frontend, aem, frameworks A concise evaluation of VueJS as a modern JavaScript framework for CMS-based static websites, comparing its performance, testing capabilities, and developer adoption against jQuery and AngularJS. VueJS evaluation October 2017 In a world of new JavaScript Frameworks popping up every week, it's hard to choose. I was ready to jump on the React bandwagon 2 years ago. Unfortunately, my work is on the CMS platform AEM. We use AEM to build static content websites. We had done some homework on the performance metrics and how inactivity equates to cost and conversion. What we needed at the time was DOM manipulation. We decided at that time that jQuery was still our best option. At my company, there are complex standalone interfaces. Those interfaces are not managed by my team, so those teams chose AngularJS. It was the Framework they were familiar with, and they were not ready to learn a new tool and still commit to a deadline. Two years later, I am seeing that Vue.js can not only handle our DOM manipulation, standalone apps, and the benefits of a virtual DOM. It has an established testing library. The downside of the framework is that Vue does not have that corporate backing like Google or Facebook. Yet, in my opinion Vue should be our next framework we implement. Performance: https://medium.com/the-vue-point/vue-2-0-is-here-ef1f26acf4b8 Comparison to jQuery: https://laravel-news.com/jquery-vue Unit Testing: https://vuejs.org/v2/guide/unit-testing.html --- ## [GEB (jeb)](https://www.craigantolick.com/blog/geb-jeb) **Date:** October 2017 **Category:** Testing **Tags:** testing, qa-automation, groovy, frontend A summary of GEB’s role in automating front-end testing using familiar jQuery-like syntax, presented at a tech-focused session to improve QA alignment and explore cucumber-based test generation. GEB (jeb) October 2017 My first session at No Fluff Just Stuff this year was about how to work with the business. The goal of the session was to get better alignment with what the development team needs. Generally that is time and planning. The talk was great. However, No Fluff is a tech focus group. In passing the presenter spoke about a testing framework. We have been looking at different options to help our QA team automate the front-end testing. The tool he liked was GEB. GEB is a groovy based framework that takes the familiarity of jQuery and help automate the front-end testing If I can figure out how to do these tests generated by cucumber, then we might have a viable solution. Learn more about GEB http://www.gebish.org/ Cucumber GEB https://github.com/geb/geb-example-cucumber-jvm --- ## [NFJS - Business Pressure](https://www.craigantolick.com/blog/nfjs-business-pressure) **Date:** October 2017 **Category:** Thought Leadership **Tags:** technical-debt, leadership, git, developer-productivity, team-management A reflection on balancing maintainable code and delivery speed under business pressure, with strategies like smart commits and time tracking to manage technical debt and improve developer workflows. NFJS - Business Pressure October 2017 Business pressure on the technology team is a constant. There is a struggle between delivering maintainable, performant, and tested code vs fast deliverables. At No Fluss, Janelle Klein hit on a pattern that we as developers. Start a clean foundation, have a few good deliveries. Then the "exception" to hitting a high pressure deadline happens. You take on technical debt. One of the main points that Klein hit on was that in business, paying the interest on debt can be easily offset. What business doesn't like its risk. How much risk? Well if you can't measure it, you don't know. Open mastery is a tool that developers can use to track how much time they are working on addressing issues. There are issues with tools. Some companies do not allow their employees to install software. I struggle to log my time on my tickets properly. There is one habit I did adapt, which is to add my JIRA ticket to my commits. My goal is to ask the team to add their time to their commits too. Since we have the Atlassian Suite, we could eventually enable "smart commits". In a smart you can add a hash #time and include the time you worked on that ticket. https://confluence.atlassian.com/fisheye/using-smart-commits-298976812.html If I cannot get smart commits enabled, then at least I could use git-log to look for the same pattern for each developer. :) ---