Suresh G

Quick update on my recent article for using Playwright MCP [https://lnkd.in/g4f5SbU2] Something extra for those who want to try it hands-on. Thanks to everyone who read, shared, and commented. A few folks reached out asking if they could see the actual prompts and test cases I used, so I cleaned it up (aka tried to 😛) and put everything in a GitHub repo here: https://lnkd.in/gycyUTiK What’s inside: > Prompts and Manual test cases I used. > GitHub Copilot generated automated test scripts. > Sample VS Code project setup (MCP-ready). > A ReadMe where I've tried to explain what all is there in the project. > POM and reports that I setup and used, but can be ignored if you want to take a different approach. Note: Both the manual and automated tests have been tweaked by me to better match what I needed. AI helps a lot in planning, creating, and accelerating test development, but we still need to adjust things so they align well with the requirements. Two automated tests are failing right now because these are correctly catching issues: 1. Browser back navigation is incorrectly taking users to a session that was logged out of. 2. Enter key press doesn’t submit the form. If you're just starting with automation or want to see how AI can assist with QA workflows, feel free to fork the repo, run it, and play around. And if you find it helpful, please drop a ⭐️ on the repo. P.S. I did run into some AI hallucination from GitHub Copilot Agent: e.g., it kept asking me for inputs even though I’d already told it to run all tests in one go 😅 (maybe because I’m on the free version?🤷). It should, and does request user consent when doing operations like installing something, starting/stopping MCP server, deleting files etc. #qa #automation #playwright #githubcopilot #manualtesting #aiinqa #testautomation #learningbydoing

16

When you join a new org or switch teams in the same, it is quite an unsettling and borderline anxious experience. Here are a few things that I did to ramp up faster. 1. I consciously made an effort to remain unblocked 2. I read a ton of code and its history, sometimes even unrelated 3. I asked questions about the past, the present, and the future 4. I took up relatively mundane tasks - cross-team work, tests, and docs 5. I extended a helping hand in whatever capacity I could 6. I proactively met skip-level leaders and managers to understand the vision Some companies do have a culture of pairing up with someone existing in the team, but even if you do not get a mentor, it is important that you still navigate the situation and ramp up as quickly as you can. The above list is not exhaustive, by any means, and hence you can always add things that you find helpful in your context. but the lowest common denominator is to show extreme intent and interest to get output and drive outcomes. Hope this helps.

996

25 Comments

Why is Redis so fast? There are many design decisions that make Redis blisteringly quick. We’ll focus on two that carry most of the weight. - First is Redis’s in-memory design + single-threaded event loop. Keeping data in RAM and processing commands in one core loop avoids locks and random I/O. - Second is its purpose-built data structures and lean wire protocol. Most commands hit O(1) or O(log N) paths with tiny per-op overhead. What happens when you read from Redis👇 Step 1: A client sends a command using RESP (a simple, compact text/binary protocol). Minimal parsing and small payloads reduce CPU and network overhead. No big JSON/XML blobs. Step 2: Redis’s event loop accepts the socket and queues work. Single-threaded command execution means no lock contention or context-switch thrash. If you want to use more CPUs you need to run more Redis instances in a cluster. Step 3: The command is parsed and routed via a hash table lookup to the target keyspace entry.  Lookups are O(1) on average thanks to efficient dictionaries and cache-friendly memory layouts. Step 4: The operation runs entirely in memory using specialized structures:   Strings, lists (quicklist), hashes (compact encodings), sets/intsets, sorted sets (skiplist + hash), streams, etc. They're are engineered for predictable, fast operations with tight CPU caches. Step 5: The response is written back through the same event loop.   Pipelining and batching can amortize syscalls and round trips, pushing throughput even higher. Step 6: Persistence and replication are off the critical path.   AOF uses append-only, sequential writes with configurable fsync; RDB snapshots happen in a child process.  Basically: we can lose data! This is a tradeoff Redis makes. Replication is async by default. The slow stuff is handled in the background so the hot path stays hot. Because Redis keeps data in RAM, executes commands in a single, lock-free event loop, and uses highly optimized data structures and a lean protocol, it avoids the latency traps of disk I/O, heavy parsing, and lock contention. That’s why it’s fast. Reed more about Redis here! https://lnkd.in/g2TEVzvx

163

This will-it-work-or-not approach to software development is antithetical to the concept of "engineering". If any process (including manually typing code) generates code you /understand/ to be both correct and well-formed, then the process is well-founded. Otherwise, it's nonsense.

9

ambaricloud: 108 recipes. 🥭 https://lnkd.in/gS6fuAtu Ravi Kiran Gurram Anil Koripelly Bhushan Lakhe Raja Purkayastha When this recipe e-book was first published on January 1, 2025, our goal was to give engineers, architects, and data practitioners a hands-on guide to Apache Iceberg. In the months since, the pace of change has been remarkable. Platforms such as Snowflake, Databricks, Dremio, RisingWave, ClickHouse, Cloudera, Lakekeeper, Trino Software Foundation, and Amazon Web Services (AWS) have delivered significant new integrations, and Apache Iceberg itself has reached version 1.10.0, introducing capabilities that reshape how practitioners interact with the format. To reflect this momentum, we are undertaking a ground-up rewrite. Our priorities include: ✅ Iceberg 1.10.0 alignment and deprecation cleanup – removing outdated recipes that no longer reflect best practices while upgrading all demos, examples, and exercises to incorporate the changes introduced in Iceberg 1.10.0. For example, Snowflake’s support for catalog-linked databases to external catalogs makes earlier object integration recipes obsolete. ✅ Ecosystem validation – testing and refining recipes across Databricks, Snowflake, Dremio, and AWS to ensure seamless interoperability with Iceberg 1.10.0. We expect this rewrite to take two to three months. Once complete, this edition will provide readers with a technically accurate, future-ready reference for Iceberg 1.10.0 and its surrounding ecosystems--Snowflake, Databricks, Dremio, RisingWave, ClickHouse, Cloudera, Lakekeeper, Trino Software Foundation, and Amazon Web Services (AWS) Please 🕺 suggest 🔪 comment 🥃 recommend ✅ Spark Variant ---Iceberg1.10.0 spports now. https://lnkd.in/gBmaNrPH

11

4 Comments