DEV Community: Stavleak

Git на хакатоне: как объединять код и не потерять демо

Stavleak — Wed, 07 Oct 2026 11:48:35 +0000

На хакатоне Git помогает хранить общую историю проекта и соединять работу участников. Для небольшой команды достаточно простого порядка: основная ветка запускается, изменения делаются небольшими порциями, а перед объединением кто-то проверяет результат. Сложную модель ветвления лучше не вводить в середине соревнования.

Git хранит версии файлов. GitHub и другие сервисы добавляют совместную работу, обсуждения и управление доступом. Команда может выбрать любой разрешённый инструмент, но всем нужно знать, где находится общий репозиторий и какая версия считается готовой для демонстрации.

Проверьте доступы до первой задачи

Создайте репозиторий в аккаунте или организации, которые команда согласовала использовать. Добавьте участников с нужными правами и убедитесь, что приглашения приняты. Одно отправленное приглашение ещё не означает, что другой человек может получить и отправить изменения.

Выберите видимость по условиям события и характеру материалов. Закрытый репозиторий может потребовать отдельного доступа жюри. Открытый репозиторий не должен содержать персональные данные, закрытые наборы или секретные ключи. Если организатор требует публикацию, подготовьте проект к ней до финального часа.

Добавьте короткую инструкцию запуска и файл исключений для локальных настроек, временных файлов и установленных зависимостей. Образец конфигурации должен описывать необходимые параметры без настоящих секретов. Не полагайтесь на то, что случайно попавший в историю ключ исчезнет после удаления строки в новом изменении.

Договоритесь о рабочей основной ветке

Пусть основная ветка содержит версию, которую можно запустить по инструкции. Незавершённые эксперименты сохраняйте отдельно. Команда должна понимать, что получение последней основной версии не превращает рабочее приложение в неизвестное состояние.

Перед началом задачи получите актуальные изменения. Назовите ветку по работе, например fix-upload-error или add-results-screen. Название не обязано быть длинным; оно должно помогать связать изменение с задачей и человеком, который его делает.

Не храните один огромный набор изменений до конца события. Если задача занимает несколько часов, выделяйте законченные шаги, которые можно проверить отдельно. Так проще заметить несовместимость раньше, чем несколько участников перестроят общие файлы.

Перед объединением объясните поведение

Документация GitHub о pull requests описывает предложение, обсуждение и объединение изменений. На хакатоне описание может быть коротким: что изменилось, как проверить и какое ограничение осталось. Для экрана полезен снимок, для обработки данных пример входа и выхода.

Проверяющий проходит изменённый сценарий и смотрит, не затронуты ли общие границы. Автор лучше знает свою задачу, но другой участник может заметить недоступную переменную окружения или ошибку, которую локальные данные скрывали.

Не требуйте длинной формальной проверки для каждой подписи. Сосредоточьтесь на изменениях, которые влияют на запуск, формат данных, доступы и демонстрацию. При этом даже маленький исправленный файл должен попасть в общую версию, а не остаться только в сообщении чата.

Разделяйте работу по файлам и интерфейсам

Если двое одновременно меняют один большой компонент, конфликты вероятнее. Договоритесь о границах: один участник работает с загрузкой, другой с экраном результата. Общую схему данных согласуйте до начала параллельной работы.

Изменение общей зависимости или структуры проекта сообщайте заранее. Обновление инструмента может затронуть запуск у всех участников. Во время короткого события у такой работы должен быть конкретный повод, а не желание привести весь репозиторий к личным предпочтениям.

Когда конфликт всё же возник, не выбирайте автоматически «нашу» или «их» версию. Прочитайте обе правки и выясните, какое поведение каждая добавляла. Если смысл неясен, позовите автора. Случайно удалить чужую обработку ошибки легче, чем заметить потерю при быстром просмотре.

Проверяйте проект после соединения частей

Отдельно успешные изменения могут не работать вместе. После объединения запустите проект и выполните главный пользовательский путь. Если есть подходящие автоматические проверки, запускайте их. Не добавляйте сложную систему тестирования только ради отчёта, если команда не успеет ею воспользоваться.

Полезен короткий список ручной проверки: приложение открывается, ввод принимается, результат отображается, ошибка понятна. Список должен соответствовать вашему прототипу. Для устройства или обработки файлов понадобятся другие действия.

Назначьте человека, который следит за общей сборкой. Это не означает, что только он имеет право объединять код. Его задача замечать, когда команда перестала понимать текущее состояние, и остановить новые изменения до восстановления рабочего сценария.

Сохраните версию для защиты

Перед записью демо обозначьте готовое состояние тегом или другим понятным способом фиксации версии. Запишите, какой набор данных использовался и какие ограничения известны. Если после записи вы исправили поведение, проверьте, соответствует ли видео обновлённому проекту.

Не переписывайте общую историю без согласования с командой. Принудительная отправка изменений может нарушить работу у остальных. Если случайно добавлены секреты, ограничьтесь не только очисткой файлов: отзовите скомпрометированный доступ по правилам соответствующего сервиса и сообщите ответственному участнику.

Учебный пример сбоя: один разработчик добавил новый параметр, но не обновил инструкцию. На его компьютере всё работает, у докладчика запуск падает. Проверка на втором устройстве обнаруживает это до финала. Именно поэтому завершение задачи включает воспроизводимый запуск, а сдача проекта включает проверку доступа к нужной версии.

Перед отправкой репозитория найдите требования выбранного события через каталог Stavleak. Сверьте состав материалов и срок, до которого жюри нужен доступ.

AI hackathon: how to test a solution before the final pitch

Stavleak — Wed, 07 Oct 2026 10:34:03 +0000

A team shows a successful model response. A judge changes the input text and gets a different result: a date disappears, an invented city appears or the request hangs. To investigate before the presentation, the organizer needs an evaluation protocol: which examples to test, what to compare the answers against and what to save after each run.

Prepare it before development starts. Teams will know the evaluation format, and judges will receive material they can use to repeat a run and inspect an error. Below, we build that protocol for a single illustrative AI prototype.

1. Define the result you will test

Our illustrative task is a service that extracts a city, an event format and a registration deadline from a short announcement. All announcements are fictional. The expected response is JSON with the fields city, format and deadline. Missing values must be null; the format can be online, offline or hybrid; dates use YYYY-MM-DD.

An example input is “Almaty, online. Register by 18 October 2026.” The expected values are Almaty, online and 2026-10-18. “Register tomorrow” without a publication date does not establish a definite deadline. The expected value in that case is null, rather than a guess.

Before the event, agree on accepted city name variants and rules for incomplete dates and ambiguous wording. Record them in the challenge brief. If two reviewers disagree about the correct answer, fix the task description and labels first.

2. Separate development from the held-out evaluation

To demonstrate the protocol, we will use 30 artificial announcements: 18 are available to teams and 12 are held out. These are chosen illustrative conditions, not a recommended sample size or a universal ratio. This set is too small to establish performance on real incoming data.

Teams use the available examples to refine the prompt, text processing and approach. If a team trains a model, its development data needs separate training and validation subsets. Keep the held-out test set for the final evaluation. Google explains this separation: choosing changes based on test answers turns the test into part of the tuning process.

Appoint an owner for the held-out set. Until solutions are frozen, that person keeps inputs and expected answers separately from the teams. Group repeated announcements about the same event so their variants cannot land on opposite sides of the split. For our example, include Russian and Kazakh texts, missing fields and ambiguous dates chosen in advance.

If a preprocessing step learns from data, fit it only on the training subset. The scikit-learn documentation specifically warns about leakage through preprocessing. This also applies to steps that appear to be simple data preparation.

3. Prepare a simple baseline

Build a baseline using a city dictionary, explicit event format indicators and recognition of fully specified dates. It also returns null when information is insufficient. Freeze the dictionary version and rules before running the held-out evaluation.

Test the baseline and the AI solution on identical inputs with identical comparison rules. This shows where the model performs better than a simple approach and where it introduces errors. Google's ML guidance recommends starting with a simple solution and defining what to measure in advance.

Check fields separately: city, format, deadline and handling of missing data. Save the count of correct answers alongside the number of fields checked. Do not combine them into a single “accuracy” figure if the number hides what you counted. Agree how these checks contribute to the overall assessment through the judging criteria.

4. Save a record of every run

Before revealing the held-out inputs, freeze the solution commit and evaluation settings. Ask each team for a short run record containing these fields:

Run identifier, commit and held-out dataset version.
Model: name and available API version, or local checkpoint identifier.
Prompt version, response schema and preprocessing rules.
Runtime and dependency versions, generation settings and seed where applicable.
Each example's identifier, raw response, status and run time.

An API version does not always freeze an external service's internal state. Record what the provider allows you to pin and which conditions the team cannot control. Keep keys, tokens and real user data out of the record.

Save responses before repairing their format. Otherwise, you cannot tell whether the model returned valid JSON or the application recovered it after an error. Record separately the processed result shown to the user.

For a nondeterministic solution, agree the number of repeats in advance and save every result. Do not pick a successful run after evaluation. A fixed seed alone does not guarantee identical output: PyTorch warns about differences across releases, platforms and CPU/GPU execution. For an external API, also account for its provider's limitations.

5. Inspect errors example by example

A judge needs a log with one record per input per run. Use this template: run_id, example_id, input text, expected fields, raw response, processed response, error type, run status and reviewer's note.

In our example, distinguish a missing date, an invented city, invalid JSON, a correct null and a missing response caused by a failure. Correctly declining to guess differs from an extraction error. An API access problem also needs a separate status.

Do not remove stalled requests or missing responses from the report. Show the number of all planned examples, completed runs and failures. If a label is wrong, record the correction and recalculate both solutions using the same rule. Once a team tunes its solution against held-out errors, that set no longer provides an independent test of the next version.

6. Let a judge repeat the evaluation

First, check whether the submitted package runs according to its instructions. For access, a fixed version and a fallback demo, use the submission acceptance checklist. Run unreviewed code in a disposable isolated environment without work secrets, using a separate test account.

Then a judge selects examples from the agreed held-out set and repeats the run with the recorded settings. Compare the raw responses with the saved ones. If they differ, record the difference, the conditions and the team's explanation. A video documents the result shown, but does not replace this run.

Before the pitch, give the judges the solution version, run record, baseline comparison and error log. State the size and composition of the evaluation, untested input types, external service dependencies and where a human must check the result. Judges can refer to specific responses and failures when the team explains what the prototype can already do and which evaluation it needs next.

Your first hackathon: prepare well and get your project to a working demo

Stavleak — Mon, 05 Oct 2026 20:21:02 +0000

Go into your first hackathon with a task you can finish and explain. For a beginner, a good result is concrete: your team builds a working user flow, submits the required materials on time and understands what to improve. The judges decide who wins. The scope of your project, access to your files and readiness to demonstrate it depend largely on you.

A hackathon is usually a time-limited event where participants build solutions and present the result. Requirements vary: some events expect working code; others accept research, a hardware prototype or a mockup. Preparation starts with the rules of your chosen event, rather than a list of popular technologies.

Start with the participation rules

Open the event page and save the rules. Look for requirements covering age, team composition, place of residence and attendance in person. Check the start time, the submission deadline's time zone and the presentation format. A multi-day online round and a short in-person final may have different conditions.

Write down exactly what you need to submit. A repository link, a deployed application, slides and a video each require different preparation. If the organizer expects a video, test your microphone and recording setup before the event. For a hardware project, ask about bringing equipment and the available power supply.

Ask the organizer a specific question with enough context: "We want to use a library we wrote earlier. Do we need to list it separately?" Save the answer with the rules. A verbal agreement with a volunteer may never reach the person reviewing submissions.

Set up your tools before building the solution

Before the event, install the tools you already know how to use. Check that you can sign in to your editor, repository and hosting service. Make a test screen recording, open it on another device and listen to the audio. None of this requires solving the competition task in advance.

You can practise by building a small learning project. Whether you can reuse its code at the hackathon depends on the rules. Learning a tool, preparing a template and developing the competition entry ahead of time are different activities. If the boundary is unclear, ask before starting the work.

Bring your charger and any adapters you need. For an in-person event, find out where you can rest and eat, how to reach the venue and when it closes. Do not make an unfamiliar laptop, someone else's account or temporary access to a paid service the foundation of your project.

Describe your skills honestly

"I can build two screens and connect a form to an existing API" is more useful to your team than "I'll handle the entire frontend." Explain what you have done independently, what you have followed in a tutorial and what you want to learn. This helps you choose a scope that does not rely on discovering a missing skill in the middle of the night.

A participant without programming experience can research the problem, test the interface, prepare data, record the demo or write the project description. Each task needs a result the team can check. "Helping with the product" is hard to assess; "I'll prepare five examples of user errors by lunchtime" can go into the plan.

If you are coming alone, find the team-matching channel and any meetup for prospective teammates. Introduce your skills, available time and the problem you want to work on. Do not promise to work all night just to get an invitation. Agree on realistic participation before the event rather than disappearing after the first stage.

Choose one path from problem to result

Consider a practice example: your team is building a consultation-booking tool. A complete product might include a calendar, payments, messages, reviews and user accounts. For the first demo, one path is enough: a person picks an available time, sends a request and receives a clear confirmation.

Write down that path and sketch a few screens. Then identify the riskiest part. The calendar might look simple, but your team may not know how to retrieve available time slots. Test that dependency before designing an attractive landing page.

In a Reddit discussion about a first online hackathon, a participant describes a project that the rest of the team could not run. It is one person's account, but it suggests a useful check: at least two teammates should be able to run the working version well before the presentation.

Agree on checkpoints

Replace a long feature list with a few visible results. First, the team can explain the problem. Next, the application completes the main flow using test data. Then another person checks the startup instructions, and the presenter rehearses the demo with a timer.

Give each checkpoint an owner. They do not have to do all the work themselves, but they know its status and report blockers. Keep the discussion short: what is ready, what prevents the next step and which part of the idea you should drop.

If you are behind, cut additional flows. Removing an optional filter is usually safer than skipping a link check or rehearsal. The 48-hour hackathon plan, in Russian gives a more detailed example of time allocation. Adapt its intervals to your event's schedule.

Start submitting before the final hour

Create a draft submission once you know the project's name and purpose. Update the description as you work. Devpost's project-planning guide also recommends starting with the rules and a draft entry. Check the actual fields and submission confirmation process for your hackathon.

Leave time to upload the video, process files and fix access. Open every link in a browser without signing in to your account. If the materials must remain private, test the organizer's approved access method for judges rather than making them public.

After submitting, save the confirmation. Then have a short team debrief: which step was harder than expected, what did you learn and what small project could you build again on your own? That will help at your next hackathon more than a vague promise to "prepare better next time."

For your first attempt, choose an event in the Stavleak hackathon catalog: read the participation rules and check the application deadlines.

Check a parsed JSON response before rendering demo items

Stavleak — Sat, 03 Oct 2026 02:40:29 +0000

Validate the structure of parsed JSON before your hackathon demo tries to render its items.

A response can contain valid JSON and still have the wrong shape for your screen. A resource list might expect an object with an items array, while the endpoint returns null, an error object, or a string. Parsing alone does not prove that each item has the fields your component needs.

State the small contract

This illustrative contract requires an items array, and every item needs a string id and a string label. Reject unexpected shapes before updating the visible list.

function readItems(value) {
  if (value === null || typeof value !== 'object' ||
      Array.isArray(value) || !Array.isArray(value.items)) {
    throw new Error('Expected an object with an items array');
  }

  for (const item of value.items) {
    if (item === null || typeof item !== 'object' ||
        Array.isArray(item) || typeof item.id !== 'string' ||
        typeof item.label !== 'string') {
      throw new Error('Each item needs string id and label fields');
    }
  }

  return value.items.map(({ id, label }) => ({ id, label }));
}

The helper returns only the fields this screen needs. It accepts an empty array as a valid empty result. That decision is part of this example's contract; change it if your workflow requires at least one item. It does not require unique IDs or a particular maximum number of items. Add those checks if your application depends on them.

Know which check answers which question

MDN's JSON.parse reference covers converting JSON text to a JavaScript value. That value can have several types. MDN's Array.isArray reference describes the explicit array check. The null checks are deliberate because typeof null is object.

In a fetch workflow, check the HTTP response, parse the body, validate this shape, then render. Give the user a readable failure message if the shape is wrong. Keep diagnostic details in an appropriate development log, without credentials or personal data. Client checks do not replace server-side validation or authorization.

Rehearse the bad shapes

Use fictional fixtures for null, an empty object, items as a string, a valid empty array, one valid item, and one item missing a label. Try a numeric ID to confirm that it fails this string-only contract. Verify that the previous valid screen is handled according to your chosen replacement behavior.

Put the expected outcomes beside those fixtures in your README. The English Stavleak guides provide project preparation material to help your team document a reproducible demonstration.

Preserve plus signs and ampersands in demo search URLs

Stavleak — Sat, 03 Oct 2026 02:35:15 +0000

Build search parameters from raw values with URLSearchParams so a plus sign or ampersand in the user's input survives the round trip.

A prototype may work with a single word and fail with a team name such as C++ & design. Concatenating that value into a query string gives punctuation another job: an ampersand can separate parameters, and a plus sign in form-style query syntax can be decoded as a space. Rehearse a value that contains both characters.

Let the URL object serialize the value

Use a URL object for the full address, then set the unencoded input value on its searchParams. Do not percent-encode the value first and then feed the encoded string to set.

const query = 'C++ & design';
const url = new URL('https://example.org/search');
url.searchParams.set('q', query);

const shared = url.toString();
const restored = new URL(shared).searchParams.get('q');

console.assert(restored === query);
console.log(shared);

This uses a reserved example domain and sends no request. MDN's URLSearchParams documentation describes serialization and percent encoding. Supply decoded keys and values to its methods; serialization handles their representation in the query string.

Test what your product actually reads

Check the generated link and the restored value rather than judging the URL's visual appearance. A space may appear as a plus sign in serialized form. That representation can still restore to the correct space. A literal plus in the value needs to restore as a plus.

The set method represents one value for the named parameter. MDN's set reference says it replaces additional values for that name. If your product supports multiple filters under the same key, decide that contract separately; do not silently reduce a multi-selection to one item.

Try a useful fixture list

Test C++, research & design, a value with spaces, Russian or Kazakh letters, an empty value, and a literal percent sign. Share each generated URL with a teammate and inspect the value after parsing it. Confirm that the UI also displays the restored selection rather than only parsing it into an unused variable.

Keep query handling separate from HTML rendering. Correct URL serialization does not make arbitrary text safe to insert as HTML. Render text through your framework's normal text output, and validate any server-side meaning such as allowed filters independently.

For an event to practise on, visit the English Stavleak hackathon catalog. Read the selected event's requirements before shaping a prototype around it.

Keep an older search response from replacing the latest results

Stavleak — Sat, 03 Oct 2026 02:30:08 +0000

Give each search request a sequence number and only render the result that belongs to the latest search.

A hackathon demo can look fine when typing slowly. During a presentation, a short query may take longer than the next query. If every response updates the screen, the older request can replace the results for the words currently in the input. The user then sees results that belong to a different question.

Decide which result owns the screen

Keep the counter beside the search workflow. Increase it before starting each request, then compare the saved number after every asynchronous step that can finish later.

let latestRequest = 0;

async function search(query, render, showError) {
  const request = ++latestRequest;
  try {
    const url = new URL('/api/search', location.origin);
    url.searchParams.set('q', query);
    const response = await fetch(url);
    if (!response.ok) throw new Error('Search failed');
    const results = await response.json();
    if (request !== latestRequest) return;
    render(results);
  } catch (error) {
    if (request !== latestRequest) return;
    showError(error);
  }
}

function leaveSearch() {
  latestRequest += 1;
}

The endpoint and callbacks are illustrative. The counter invalidates both old successful results and old failures. Calling leaveSearch prevents pending requests from changing a screen that the user has left. Keep the counter scoped to this search instance so two unrelated search boxes do not invalidate each other.

Guard loading as well as results

Set loading for the new request and clear it only if that request is still current. If an old request clears loading while a newer request is pending, the screen can claim it has finished too early. Apply the same ownership check to any empty-state message.

MDN's Fetch guide explains that HTTP errors require a response-status check. A sequence number handles which result is current; it does not validate the response data, cancel traffic, or provide a timeout. You can add cancellation to save work while retaining a result-ownership check.

Force the wrong completion order

Use fictional fixtures or a local stub with two named queries. Make the first response finish after the second. Confirm that the second result stays visible. Repeat with the old request failing after the newer request succeeds. Then test the latest request failing and the user leaving while either is pending.

Write down the input and expected visible result for each case. For more rehearsal material, open the English Stavleak guides and adapt the project preparation steps to your prototype.

Cancel a demo request when the user leaves its screen

Stavleak — Sat, 03 Oct 2026 02:22:48 +0000

Cancel a screen's pending request when the user leaves it, and keep that deliberate cancellation out of the visible error state.

A hackathon prototype may load a resource list when a panel opens. If the user closes the panel, the request can keep running. Define what should happen to loading, success, and failure after that panel is gone. Treat the request as belonging to that particular visit, rather than to every future visit to the panel.

Give each visit its own controller

MDN's AbortController reference describes a controller that can abort asynchronous operations, including fetch requests and response-body consumption. Pass its signal to the operation you want to cancel.

function openPanel(render, showError) {
  const controller = new AbortController();
  let active = true;

  const done = (async () => {
    try {
      const response = await fetch('/api/demo-resources', {
        signal: controller.signal
      });
      if (!response.ok) throw new Error('Resource request failed');
      const data = await response.json();
      if (active) render(data);
    } catch (error) {
      if (active && !controller.signal.aborted) showError(error);
    }
  })();

  return {
    done,
    close() {
      active = false;
      controller.abort();
    }
  };
}

This is a lifecycle sketch. The endpoint is illustrative, and the caller supplies the real rendering functions. Keep error details suitable for a participant; do not print credentials or raw internal responses to the screen. Set the loading state when opening the panel and end it on the appropriate active success or failure path.

Distinguish leaving from failing

The active flag prevents a finished operation from updating a closed panel. The signal stops work that supports cancellation. Create a new controller when reopening; a previously aborted signal stays aborted. Link the returned close function to the actual component or panel cleanup in your framework.

Aborting a request does not guarantee that the server undid a write. This example concerns a read. A submission or payment needs a separate server contract for its outcome. Never tell a user that their submission vanished because the browser stopped waiting.

Rehearse the lifecycle

Try opening and immediately closing the panel, opening it again, allowing a successful read, and causing a genuine failure while it stays open. Also close after the response arrives. Verify that the second visit can load normally and that the closed panel never receives a late update.

Keep these cases in the team's rehearsal notes. The English Stavleak organizer toolkit provides checklists that you can adapt when planning a demonstration.

Handle partial failures in optional widgets with Promise.allSettled()

Stavleak — Sat, 03 Oct 2026 02:06:51 +0000

Use Promise.allSettled() for independent optional widgets so one failed request does not hide the other widgets' successful results.

A hackathon dashboard might show a required project result plus optional weather and resource cards. Decide which pieces the user needs to finish the task. An unavailable optional card should have its own failure state, while the required result should follow its own loading and failure contract.

Keep independent outcomes separate

MDN documents Promise.allSettled() as waiting for all input promises to settle and returning their outcomes in input order. Each outcome has either a fulfilled value or a rejection reason. Completion order does not change which slot belongs to which request.

const widgets = [
  { name: 'resources', task: Promise.resolve(['Guide']) },
  { name: 'weather', task: Promise.reject(new Error('Unavailable')) }
];

const outcomes = await Promise.allSettled(widgets.map(w => w.task));
for (const [index, outcome] of outcomes.entries()) {
  const name = widgets[index].name;
  if (outcome.status === 'fulfilled') {
    console.log(name, outcome.value);
  } else {
    console.log(name, 'Could not load this optional widget.');
  }
}

These tasks are deterministic fixtures, not calls to an actual weather service. Replace the console output with a separate UI update for each named widget. Keep the name mapping beside the request list so later edits cannot swap two results accidentally.

Make real requests reject when appropriate

When replacing the fixture with fetch(), inspect response.ok before parsing. MDN's Fetch guide explains why an HTTP error can otherwise appear as a fulfilled response. allSettled() classifies promise outcomes; it does not decide whether an HTTP response meets your application's success contract.

It also does not provide a timeout or cancel requests. A request that remains pending keeps the combined wait pending. Design request cancellation and time limits explicitly for the real services you use. If widgets need to appear as soon as each completes, update them individually instead of waiting for the entire group to finish.

Test partial availability

Rehearse both successful widgets, each single failure, and both failures. Confirm that a failed card names its own problem and that successful content remains visible. Add one deliberately slow fixture to see whether the loading state matches your intended experience.

Keep a required submission request outside this optional-widget group when its failure must stop the workflow. Write that dependency in the README. For planning a rehearsal, the English Stavleak organizer toolkit offers checklists and templates that you can adapt to your event.

Validate demo uploads beyond the file input accept attribute

Stavleak — Fri, 02 Oct 2026 02:52:02 +0000

Treat a file input's accept attribute as a picker hint and validate the selected upload separately before a hackathon demo depends on it.

A prototype that requests a CSV can still receive the wrong kind of file. The browser's chooser helps the user find an expected format, but the application needs its own rules for size, contents, and what happens after rejection. A successful chooser interaction does not prove the file can be processed.

Describe the expected selection

Use a visible label and a narrow hint that matches the formats your implementation supports. This example names CSV explicitly; it does not promise to import spreadsheets or every text file.

<label for="demo-data">Demo data (CSV)</label>
<input id="demo-data" type="file" accept=".csv,text/csv">

MDN's accept documentation states that the attribute guides selection rather than validating the file type. It also calls for server-side validation. A filename extension or client-provided media type alone is not a trustworthy security boundary.

Check the product contract

For a local rehearsal, write down the accepted column names, encoding assumptions, and a size limit that your team has actually chosen. Explain that limit in the UI. Do not invent a universal CSV maximum or silently accept a file that the parser cannot handle.

function checkSize(file, maximumBytes) {
  if (!file) return 'Choose a file first.';
  if (file.size > maximumBytes) return 'File exceeds this demo limit.';
  return null;
}

This helper only checks presence and size. It does not validate CSV syntax, required columns, or whether the upload is safe. Use a CSV parser that handles the dialect your product supports, and validate the parsed structure before adding data to the visible results.

Rehearse rejection without losing the user's work

Prepare fictional fixtures for a valid file, a file missing a required column, a malformed file, an oversized file, and an empty file. Try cancelling the chooser as well. Keep the previous valid data visible until the replacement passes your checks, if that matches the product's intended behavior.

For every rejected fixture, show a specific reason and let the user choose another file. Confirm that the loading state ends, the error is readable, and the next valid upload succeeds. A presenter should not need to reload the entire app after one mistaken selection.

Apply authorization and validation again wherever files reach the server. Keep the demo fixtures free of real identities. The English Stavleak hackathon catalog can help you find a challenge; read that event's data rules before bringing any external dataset into the project.

Format event times with an explicit Intl.DateTimeFormat time zone

Stavleak — Fri, 02 Oct 2026 02:50:30 +0000

Pass an explicit timeZone to Intl.DateTimeFormat when a demo must display the same event time on teammates' computers.

The locale controls presentation conventions, while the time zone determines which local clock time represents an instant. Choosing English labels does not specify the event's zone. During a rehearsal, two people can format the same timestamp and see different hours if their runtime defaults differ.

Start with an unambiguous instant

Use a timestamp that includes an offset, such as the fictional example below. Keep the event's actual zone as separate configuration. This example uses UTC to make the formatting behavior easy to inspect and does not announce a real event deadline.

const instant = new Date('2026-10-02T12:00:00Z');
const formatter = new Intl.DateTimeFormat('en-GB', {
  dateStyle: 'medium',
  timeStyle: 'short',
  timeZone: 'UTC'
});

console.log(formatter.format(instant));
console.assert(formatter.resolvedOptions().timeZone === 'UTC');

MDN's Intl.DateTimeFormat reference shows explicit time zone options and locale-sensitive formatting. The output is human-facing text. Keep the original timestamp for storage and comparisons rather than parsing the formatted label back into a date.

Make the zone visible to the reader

A time such as “12:00” needs context on a schedule card or confirmation screen. Include a visible label for the configured zone. If you want the formatter to include a zone name, use individual date and time components with timeZoneName rather than mixing that component option into this style-based example.

When an organizer changes the event zone, update the configuration and the explanatory label together. Do not change the stored instant merely to make the displayed hour look familiar. First establish whether the change concerns presentation or the actual scheduled moment.

Check the formatting contract

Run the same instant on two machines with different system zones and compare the displayed event time. Then try an instant near midnight so a date change becomes visible. Confirm that the screen and any copied confirmation text use the same zone setting.

Avoid asserting an entire localized string in a portable test unless you control the runtime data and formatting environment. The resolved zone and selected date/time parts are more targeted checks. Leave room for different punctuation and translated month names.

Record the configured zone next to your fixture timestamp so a teammate can reproduce the result. If you are building an event schedule, the English Stavleak organizer toolkit provides planning materials; confirm the real event time with its organizer before replacing the fictional fixture.

Check Fetch HTTP status before treating a demo request as successful

Stavleak — Fri, 02 Oct 2026 02:41:48 +0000

Check response.ok before parsing a Fetch response so an HTTP error cannot enter the success path of your hackathon demo.

A request can reach the server and receive a 404 or 500 response while the JavaScript promise still fulfills. If a prototype treats every fulfilled promise as successful data, the UI may display an error document as a result or fail later during JSON parsing.

Separate response status from transport failure

MDN's Fetch guide explains that HTTP error responses do not automatically reject fetch(). The application must inspect the status. A rejection means the request could not complete normally, but it does not identify one specific cause such as being offline.

async function readJson(url) {
  const response = await fetch(url);
  if (!response.ok) {
    throw new Error(`HTTP ${response.status}`);
  }
  return response.json();
}

This helper also lets a JSON parsing failure reject the returned promise. It assumes a successful endpoint returns JSON. A 204 response with no body needs a different branch; document that contract instead of applying this helper to every endpoint.

Give the interface an honest next step

Keep the technical error useful for development while showing a short message the presenter can act on. For a read-only lookup, that might be “Could not load the result. Try again.” Avoid claiming the internet is down when you have only observed a failed request.

try {
  const result = await readJson('/api/demo-result');
  renderResult(result);
} catch (error) {
  console.error(error);
  renderRetryMessage();
}

The rendering functions here are application placeholders. Replace them with your actual UI updates. Do not put tokens, private response bodies, or personal data into the displayed message or a public rehearsal recording.

Test three different failures

Use a controlled local fixture to return a 404 JSON response, a 500 response, and a 200 response containing malformed JSON. Confirm that none shows a successful result. Then simulate a rejected request in your test double and confirm the same recovery control remains available.

Also test a valid 200 JSON response. Otherwise a change that sends every case to the failure screen can appear to fix the original problem. Check that the loading indicator stops in both success and failure, and that a retry starts a new request rather than replaying stale success content.

For a live pitch, write down the endpoint and its expected response format with the teammate running the backend. Organizer checklists in the English Stavleak toolkit can help structure the rehearsal; the event's own submission instructions still decide what you must deliver.

Read repeated URL query parameters with URLSearchParams.getAll()

Stavleak — Fri, 02 Oct 2026 02:39:51 +0000

Read repeated query parameters with URLSearchParams.getAll() before a hackathon demo loses one of the user's selections.

A prototype might send two selected skills as skill=design&skill=javascript. A teammate who reads only the first value can show an incomplete summary even though the browser sent both. Make the representation part of the interface contract before connecting the form to the results screen.

Read the complete list

MDN documents getAll() as returning an array of strings for the requested key. A missing key produces an empty array. Use that shape consistently instead of switching between a string and an array depending on how many selections exist.

const params = new URLSearchParams(
  'skill=design&skill=javascript&note=a%2Bb'
);
const skills = params.getAll('skill');

console.assert(skills.length === 2);
console.assert(skills[0] === 'design');
console.assert(skills[1] === 'javascript');
console.assert(params.getAll('missing').length === 0);

For a hackathon registration prototype, document whether repeated values preserve a deliberate ranking or represent an unordered selection. That choice belongs to your application. Do not silently remove duplicates if two entries can carry different meaning elsewhere in the workflow.

Build the same representation

Keep the serializer beside the parser during the rehearsal. Start with an empty parameter object and append one entry for each selected value. This example uses fictional skills rather than an event's actual registration rules.

const output = new URLSearchParams();
for (const skill of skills) output.append('skill', skill);
console.assert(output.getAll('skill').length === 2);

The URLSearchParams reference explains encoding and iteration. Prefer its serializer to manually joining unescaped user text with ampersands. Decide which values your server accepts separately; correctly encoded input can still be invalid for the product.

Rehearse the boundary cases

Run the demo with no selections, one selection, two different selections, and the same value twice. Compare the visible summary with the parsed array. Add a value containing a space, then one containing a literal plus sign through append(), and check the round trip.

Ask the teammate implementing the receiving endpoint to repeat those cases. Save the expected representation in the README so the next person does not replace it with a comma-separated string during the final hour. Keep private contact details out of URLs, which people may copy into screenshots and browser history.

When choosing a project to rehearse, browse the English Stavleak hackathon catalog, then check the selected event's own requirements before adapting the example.