标签：#legacy

Have you ever been at a situation where you have been recently hired to maintain a legacy project, an important project at your company, but the previous team has long retired, and when you start, there is no documentation? When that happens, the old adage of "The code is the documentation" sounds true, but what happen when the code is also very old, hard to understand, and make use of libraries from when your parents were dating? In that case, using an AI Tool to help you understand how this project was created and maintained could be an option. Below are five prompt engineering techniques taken from a scientific article, with CLI based examples, to help you get the best out working with a legacy project. Zero-shot prompt A zero-shot prompt is when you make a prompt to request the model to execute a task without giving it any extra information or practical example in the input prompt. A classic example would be to ask a coding model to translate a "string.xml" file containing commonly used text strings in a natural language (for example, English) into another (for example, Spanish). Those are the easiest prompts to create and to feed to the model, but their results can be more unpredictable, since they usually lack the constraints of larger prompts. Prompt example: I want you to translate the contents of "string.xml" from English into Spanish and output it to me. Check this project files and directories, and provide me a list containing the current node version being used on this project and its libraries. Few-shot prompt In contrast to a zero-shot prompt, a few-shot prompt is a prompt including one or more pairs of the desired input and output, so the model can infer or mimic the desired output when you input the next value. A classic example would be asking a model for predictions based on a set of constraints. Those prompts tend to be longer and more complicated, and you must check the answer, because there is always a chance the model may infer incorrectly your

Introduction Extracting data from older websites is a technical challenge that goes beyond simple copy-pasting. The example website provided illustrates this perfectly: its outdated design, reliance on mouse-over interactions, and lack of structured export options create a perfect storm of extraction difficulties. This article dissects these challenges and provides a roadmap for extracting both visible content and mouse-over images while preserving data integrity. The Core Problem: Legacy Technology Meets Modern Needs The website's URL parameters ( screen_width=0&screen_height=0 ) immediately signal a legacy system likely built for a bygone era of fixed-width displays. This design choice breaks modern scraping tools that expect responsive layouts. The mouse-over images, critical to the site's content, are dynamically loaded via JavaScript , meaning they don't exist in the initial page source. This requires simulating user interactions to trigger their appearance, a task beyond basic HTML parsing. Why Manual Extraction Fails Attempting to manually save images or copy text from this site is a losing battle. The mouse-over images, for instance, are not directly downloadable – they're embedded in JavaScript events. Even if you could save them individually, maintaining their association with the corresponding visible content would be error-prone and time-consuming. This method also fails to scale for larger websites with hundreds of such elements. The Technical Solution: A Multi-Pronged Approach Effective extraction requires a combination of techniques: Browser Automation: Tools like Selenium or Puppeteer can simulate mouse movements to trigger hover events, capturing both visible and hidden content. This method mirrors human interaction , ensuring all dynamic elements are revealed. Network Request Inspection: Analyzing the website's backend requests using browser developer tools can reveal direct URLs for mouse-over images , bypassing the need for hover simulation. This

I was diagnosed with stage 3 cancer. Surgery is scheduled for December 31st. Last day of 2020. Fitting. I'm not going to use this space for medical details or false optimism. What I want to think through is what this does to how I approach work. Mortality as a Constraint Time might be finite. It was always finite, technically, but now the bound is tighter and less abstract. This changes the optimization problem. Before: maximize long-term impact. Now: maximize impact given uncertainty about time remaining. Concretely, that changes which projects I start, how I document things, what I publish vs. keep private, and how much I think about whether my work outlasts me. The Archive Problem I keep thinking about durability: Will my code still build in 10 years? Have I documented my reasoning, not just my results? Are my repositories structured so someone else could pick them up? Is it clear why I built these things, not just what they do? This isn't morbid. It's practical engineering applied to an uncertain timeline. What I'm Focusing On Cancer is good at clarifying priorities. Finish meaningful work. Complete the projects that contribute something real. Document obsessively. Write as if I won't be here to explain. Open source everything. Make my work reproducible and continuable. Think clearly about hard problems. Use whatever time there is to engage honestly with questions that matter. The Paradox Cancer has made me more productive. Not because I'm racing, but because the filter got sharper. I care less about publications for their own sake. I care more about whether what I've built will be legible and useful to someone else. Continuing I'm still in my math degree. Still building tools. Still writing. The diagnosis doesn't change the work. It changes the framing. Every project is now: "If this is my last contribution to this area, is it worth the time?" Most things fail that test. A few pass. I'm working on those.