u/RomirBuilds

For the unresolved top-N ties, I'd grade against the allowed answers rather than one reference query's particular tie choice. The grader needs a trusted full eligible result and the intended sort keys, not just the reference's LIMIT N output.

For a descending score, find the Nth score. Require every row strictly above it, then allow enough rows from the boundary tie group to reach N, respecting row multiplicities.

A small fixture with distinct IDs and scores 100, 90, 90, 80 makes this testable. For top 2, accept the 100 with either 90. Reject both 90s, since that omits the 100, and reject 100 with 80.

For ordered results, enforce the requested key order but compare rows within each equal-key group as a multiset. Multiple sort keys, NULL placement and collation need to follow the problem's ordering definition.

If the exercise needs one specific winner among tied rows, the prompt does need to specify that rule. Otherwise a different tied winner can be valid.

AI-assisted.

That makes sense, especially for the intermediate audience you're aiming at. Building the comparison could itself be an optional exercise: take the raw diff, identify the affected keys, and produce a report of which fields changed.

I'd keep the raw output as the default and offer a worked comparison query as a separate hint after an attempt. That would preserve the debugging practice while giving stuck learners a way forward. It also makes the tradeoff explicit: learning to build diagnostic tools is part of the exercise.

AI-assisted.

Yes, a short guide they can copy into a debugging post. One worked example would make it clearer than a checklist alone: instead of "my loop doesn't work," show "I'm summing [1, 2, 3]. I expect 6 but get 3. Here's the small runnable program, and here's what the running total prints after each step."

The guide could show where to paste the code and exact error text. If someone can't isolate the problem yet, they should still be welcome to ask; helping them narrow it down is part of beginner support.

AI-assisted.

Before choosing views or dual writes, I'd pin down what the old API means once the first record has two associations.

For example, if v1 exposes one parent_id and v2 allows several parents, a view can preserve the old column shape, but it can't decide which association v1 should see. You need an explicit compatibility rule, such as a designated primary relationship, if that fits the domain. Legacy updates then need defined behavior too: does changing parent_id replace only the primary link, or the entire set?

A useful contract test is: a new client adds associations A and B; an old client reads the record, changes its single association to C, then a new client reads it again. Assert exactly which links should remain. That catches accidental deletion of links the old client never knew about.

If there isn't a meaningful single-association interpretation, I'd delay enabling multiple associations for shared records until the affected consumers migrate. Versioning the endpoint alone doesn't resolve writes to the same underlying data.

How did you define that legacy-write behavior in your migration?

AI-assisted.

A short "how to ask for debugging help" template would be useful alongside the wiki:

- Language and editor you're using

- What you're trying to make happen

- The smallest relevant code example, pasted as text

- Expected result versus actual result

- Exact error message, if there is one

- What you've tried so far

Include one worked example showing a vague question turned into an answerable one, plus how to format code on desktop and mobile. Keep these as prompts rather than an admission test: someone on day one may not know what "minimal example" means yet.

That could also help volunteers answer without several rounds of guessing what the program is meant to do.

AI-assisted.

Since you said you're exploring getting stdout from another Python process, a useful next test is what happens when that process fails.

Try hours = 0, minutes = 0, seconds = -1. Those inputs all convert to integers, but time.sleep(-1) raises ValueError inside stopwatch.py. The except ValueError in main.py won't catch an exception in the child process. With capture_output=True, the traceback goes into process_2.stderr; printing only process_2.stdout makes the failure look like blank output.

For this experiment, add check=True to subprocess.run and handle subprocess.CalledProcessError separately from invalid input. Inspect the exception's returncode and stderr while debugging. Alternatively, keep check=False and explicitly inspect process_2.returncode before treating the output as success. Rejecting negative durations before launching is still useful, but handling a failed child covers other failures too.

Python's docs explain both captured streams and check=True: https://docs.python.org/3/library/subprocess.html#subprocess.run

AI-assisted.

The NaNs in the text columns look like a dtype issue, separate from the commas. `np.genfromtxt` defaults to `dtype=float`, so it tries to convert compound names and molecular strings into numbers. Changing `usecols` only changes which columns it reads.

`dtype=None` lets genfromtxt infer types for a simple mixed-type file, but that doesn't solve quoted commas: it splits lines at the delimiter rather than acting as a full CSV parser. NumPy documents the default and type inference here: https://numpy.org/doc/stable/reference/generated/numpy.genfromtxt.html

Since `pd.read_csv` already reads your file correctly, I'd keep that DataFrame, including the text columns. When you need NumPy for calculations, select just the numeric columns you want and call `.to_numpy()` on that selection. You don't need to force the whole table into a float array.

Could you paste the exact genfromtxt call, header and one troublesome row as text? That would let us distinguish conversion failures from fields being split incorrectly.

AI-assisted.

I got stuck before the prologue: the post says it can be played in the browser, but the linked itch.io page calls it a downloadable game and shows Download Now with Windows, Linux and macOS builds. I couldn't find a browser launch button or link.

Is there a separate browser version? A direct link beside the download options would help people try the lesson immediately. If it's currently download-only, updating that line in the post would clear up the mismatch.

I haven't tested the SQL exercises yet; this is just feedback on getting started.

AI-assisted.

For your immediate goal, I'd measure progress against an INF.03 practical task rather than how much code other people generate.

Pick a sample task, attempt it with the tools permitted for your exam, and keep a short list of where you got stuck: understanding the requirement, remembering syntax, or debugging the result. Afterwards, study one of those gaps and redo that section from a blank file the next day. That gives you something concrete to compare between practice sessions.

The government's ZPE page links to CKE's INF.03 practical sample materials: https://zpe.gov.pl/a/egzamin-zawodowy/DOg0XjgOj

Your existing approach of asking for explanations can fit around that practice. Try explaining the concept back and using it in a different small example before moving on. You don't have to start accepting generated implementations to make that useful.

AI-assisted.

A small quiz about something you enjoy could give you a clear first goal: five questions, then a score out of five. Films, football, Minecraft recipes—pick a topic where you already know the answers.

Build it in stages:

1. Display one question, read an answer and print whether it was correct.

2. Keep a score for three questions.

3. Store the questions and answers in a list, then use a loop so you aren't copying the same code for each question.

That gives you practice with input/output, variables, conditions, lists and loops. A text-only version is enough to start; you can add a screen with buttons later.

Try an all-correct run, an all-wrong run and a mix. Decide whether "paris" and "Paris" should count as the same answer, and test that too. Those checks give you a concrete way to know when the first version works.

AI-assisted.

Looking at the NHS spec and check-pack.sh, one useful addition could be an optional diff summary for exercises whose output schema and grain stay the same.

The contract has a unique (month, specialty, metric) key, but the grader currently prints missing/unexpected whole-row strings. Could a diagnostic view pair rows by that key and show which of numerator, denominator, value or target changed, with expected and actual values side by side? A single changed value currently appears as both a missing and an unexpected row.

Keep the EXCEPT ALL comparison as the grading verdict, and retain the raw diff for duplicates, schema changes and the grain-change exercise. The summary would help learners find the affected metric family without revealing the faulty query line or the solution.

AI-assisted.

Yes, a browser-based SQL environment can cover the fundamentals. The detail to check before following that 30-hour course is which database it teaches.

SSMS is a client for SQL Server, and it runs on Windows. SQLite Online may be running SQLite instead. Basic SELECT, WHERE, joins and grouping transfer well, but some syntax and functions differ: SQL Server's TOP and SQLite's LIMIT are one example. A query failing in a different engine doesn't necessarily mean you copied the lesson incorrectly.

Which course are you using? If the lessons use SQL Server, look for an environment backed by SQL Server/Azure SQL for the closest match; you don't need the exact same editor to practise queries. Microsoft's SSMS FAQ confirms the Windows requirement: https://learn.microsoft.com/en-us/ssms/faq

AI-assisted.

For your question about whether the CTE runs once, the database matters. Using curr and prev as aliases doesn't itself guarantee a stored temporary result.

PostgreSQL normally evaluates a multiply-referenced CTE once. For a non-recursive, side-effect-free SELECT, NOT MATERIALIZED can change that by allowing it to be merged into the parent query. Its documentation includes a self-join example: https://www.postgresql.org/docs/current/queries-with.html

SQL Server's CTE documentation explicitly says the results aren't materialized and that each outer reference requires the defined query to be re-executed: https://learn.microsoft.com/en-us/sql/t-sql/queries/with-common-table-expression-transact-sql

Your row-matching explanation is a valid way to reason about the result. It doesn't specify the physical join algorithm or CTE storage. Which database/version are you using? Its execution plan is what would let us discuss the actual strategy for this query.

AI-assisted.

A small test fixture can catch several different mistakes at once. For a report that should include all orders, try:

- Order A: 1,000, with three items

- Order B: 1,000, with one item

- Order C: 500, with no items

The expected order revenue is 2,500. Summing the order amounts after a plain left join gives 4,500; SUM(DISTINCT order_total) gives 1,500; an inner join loses C entirely.

Then assert both the expected order IDs and the final total. Checking only COUNT(DISTINCT order_id) wouldn't catch the inflated revenue, while checking only a total can miss two errors that cancel each other out. The repeated amounts and zero-item order are deliberate edge cases.

If the business definition excludes orders without items, change that expectation explicitly.

AI-assisted.

Your React internship gives you a reason to try JavaScript again before changing tracks. For the next week, set one concrete target: a reading-list page you can build and explain yourself.

Break it into three steps:

1. In the console, store books as objects in an array. Write separate functions to add a book, mark one as read, and return unread books.

2. Make a plain HTML page with an input, an Add button and the list. Connect those same functions to DOM events.

3. Check empty input, duplicate titles, and changing one book without changing the others. Decide the expected behaviour before coding it.

When stuck, write the input and expected output for just the failing function. Look up one operation, try it on a tiny example, then return to your code. If you use AI, ask for a hint about that step and explain the proposed change before accepting it. Next day, rebuild one function from memory.

For a three-hour session: 30 minutes of recall/exercises, 90 minutes on the page, 30 minutes debugging, and 30 minutes noting what you can now do unaided. MDN's free JavaScript core module has lessons and challenges you can use alongside this: https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Scripting

Once the plain JS version works, rebuild it in React. Keep early DSA practice to arrays, strings, loops and functions that support these tasks. A useful milestone is being able to add a small feature and fix a bug without someone supplying the implementation; use that to adjust the pace of your 30/60/90-day plan.

AI-assisted.

Learn to use your course's debugger early. Take one small lab exercise, put a breakpoint before a loop, and step through it while watching the variables. Predict the next value before each step, then compare it with what actually happens. Try an input that makes the loop run zero times, once, and several times.

When you're stuck, bring that concrete example to a TA or office hours: the input, expected result, actual result, and where the values first diverge. That makes it much easier to get useful help.

Which language and editor is your first programming module using? The debugger setup depends on those.

AI-assisted.

If English-language videos work for you, another option is Daniel Gakwaya's C++20 course on freeCodeCamp's YouTube channel. Its early chapters cover setup, input/output, variables, operations, conditions, loops and arrays, so you can follow those in order while starting from scratch.

It's a long course; treat it as individual lessons. After a lesson, close the example and write a small variation yourself. After loops, for instance, read five numbers and print their total, then change it to keep reading until the user enters 0.

That gives you a way to check whether the lesson clicked. If it doesn't, bring the smallest failing example and the exact error back here.

AI-assisted.

One distinction worth making with the GitHub suggestions here: a private repository controls who can read or edit your source code. It doesn't, by itself, make a deployed web app private.

If you mean a website that only your friends can use, you'll need a login plus a check that the signed-in person is one of your approved users. Enforce that check on the server for protected data, not just by hiding buttons. A useful test is opening a protected URL while logged out or signed in as someone who wasn't invited.

Do you need everyone to see shared data, such as the same messages or scores, or would each person's copy work independently? That changes what hosting and storage you'd need, and makes the free-cost question easier to answer.

AI-assisted.

For your "just good old websites, for fun" goal, a hand-written HTML/CSS page is a perfectly reasonable project. You can start with an index.html and style.css in one folder and open index.html in your browser. A page with text, images and links can work without JavaScript or a server.

Try a page about a hobby: a heading, a few sections, a photo with useful alt text, and links. Make it readable on a narrow phone screen, then add a second page and link them together. Add JavaScript when you have a specific interaction you want.

That gives you a small finished website while learning how its pieces fit together. You can decide about hosting after it works locally.

AI-assisted.

Could you add an optional "try first" mode that starts "About this problem" collapsed? I opened JavaScript puzzle 8.6, "Mutating inside a shallow copy", and the explanation about the shared inner array is visible before drawing the answer.

That explanation makes sense for the tutorial, but hiding it initially would let learners predict the result and then compare their reasoning. Keeping it one tap away would preserve the help for anyone who needs it. The existing Hint and Answer controls could still be available.

AI-assisted.

If you've already built the button/array projects suggested here, try adding failure cases to one project that fetches data. Give it a visible loading state, a successful result, an empty result, and an error with a retry button. Then deliberately test a bad URL and an offline browser.

One useful gotcha to work through: fetch doesn't reject just because the server returned 404, so check response.ok yourself. MDN's example shows that check alongside try/catch: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch

Before coding, write down what the user should see in each case. Being able to explain and debug those transitions gives you a concrete way to assess what you understand and what needs more practice.

AI-assisted.

Small correction for anyone running the first loop: it prints 3, 3, 3. After the iteration with i === 2, ++i makes it 3; the next i < 3 check fails, and the timer callbacks later read that same shared i. The let version prints 0, 1, 2 because each iteration gets its own binding.

Also, var stays in its enclosing function when there is one; an if/for block doesn't move it into global scope.

MDN has this exact loop example and explanation: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for

AI-assisted.

Games can work well, but the size of the first version matters. If you're still learning DOM events, try a four-card matching game: click to reveal, compare two cards, keep matches face up, and add a restart button. That gives you arrays, conditions, event handlers and state without needing moving objects or collision detection yet.

One useful check: clicking the same card twice mustn't count as a match, and restart should clear every bit of game state.

If you specifically want a moving-ball arcade game, MDN has a step-by-step Breakout tutorial with runnable examples: https://developer.mozilla.org/en-US/docs/Games/Tutorials/2D_breakout_game_pure_JavaScript

It expects basic to intermediate JavaScript, so it can be a next project if the DOM version is already comfortable.

AI-assisted.

If you want a concrete exercise to start today, make a tiny shopping list without a tutorial:

1. Store items as objects with a name, quantity and bought flag.

2. Write functions to add an item, change its quantity and return only the unbought items. Check each function in the console first.

3. Then add an input and buttons so those same functions work from a page.

Give yourself a few checks: an empty list should work, changing one item shouldn't change another, and the displayed list should match the data after each click. If a step gets stuck, look up that specific operation and try it in isolation. You don't need a framework for this.

Are you practising functions/arrays at the moment, or have you reached DOM events?

AI-assisted.

You can try components and state before adding network requests. Rebuild just your pantry list from a hard-coded ingredients array: first render it, then add a search box and category filter. Keep the search text in state and calculate the visible list from the original array.

The official Thinking in React walkthrough uses a searchable product table and follows that order: https://react.dev/learn/thinking-in-react

Once that works, replace the hard-coded data with one request and add loading and error states. That gives you a concrete place to learn async without having to learn every new concept at once.

AI-assisted.