arch-x1: 2026-06-08 14:58:28 | 2
This commit is contained in:
Dmitry
@@ -1,813 +0,0 @@
|
||||
---
|
||||
status: processing
|
||||
type: concept
|
||||
tags: []
|
||||
created: 2025-12-17
|
||||
updated: 2026-06-05
|
||||
aliases: []
|
||||
---
|
||||
|
||||
# Вопросы по Вебу
|
||||
|
||||
## Теория по блокам
|
||||
|
||||
Опорные заметки:
|
||||
|
||||
- [[IP-адрес]], [[IPv6]], [[Подсети и маска подсети]], [[NAT]], [[DNS]], [[TCP Vs UDP]]
|
||||
- [[HTTP, HTTPS и HTTP3]], [[Сетевые порты]], [[Веб-аутентификация и авторизация]], [[OAuth 2.0]], [[URI, URL, URN]]
|
||||
- [[Основы HTML (структура, таблицы, формы)]]
|
||||
- [[Основы, селекторы и блочная модель|CSS: Основы и селекторы]], [[Адаптивность, Flexbox и Grid|CSS: Адаптивность, Flexbox и Grid]]
|
||||
- [[Модели и ORM|Django Модели и ORM]], [[Представления, шаблоны и CBV|Django: Представления, шаблоны и CBV]], [[Работа с формами и CUD|Django: Формы и CUD]]
|
||||
|
||||
### Блок 1. Общие вопросы
|
||||
|
||||
**IP-адрес** - адрес узла в сети. IPv4 записывается как `192.168.1.10`, внутри это 32 бита. IPv6 длиннее, 128 бит, например `2001:db8::1`.
|
||||
|
||||
**Маска подсети** показывает, какая часть IP относится к сети, а какая - к устройству. В `192.168.1.10/24` первые 24 бита - сеть, оставшаяся часть - хост.
|
||||
|
||||
**Приватные IPv4-адреса** используются внутри локальных сетей: `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`. Они не маршрутизируются напрямую в интернете.
|
||||
|
||||
**Localhost** - обращение к самому себе. Обычно это `127.0.0.1`.
|
||||
|
||||
**NAT** переводит внутренний приватный адрес в публичный. Домашний роутер обычно делает PAT: много устройств выходят в интернет через один публичный IP, а различаются по портам.
|
||||
|
||||
**DNS** превращает доменное имя в IP-адрес. Браузер не ходит на `example.com` как на текст - сначала нужно узнать IP через DNS.
|
||||
|
||||
**TCP** устанавливает соединение через `SYN`, `SYN-ACK`, `ACK`, следит за доставкой и порядком данных. Поэтому он подходит для HTTP/HTTPS.
|
||||
|
||||
**HTTP** - протокол запроса и ответа. Клиент отправляет запрос, сервер возвращает ответ. HTTP не хранит состояние сам по себе.
|
||||
|
||||
**GET** обычно получает данные. **POST** обычно отправляет данные в теле запроса: форму, JSON, файл.
|
||||
|
||||
**HTTP-ответ** содержит код состояния:
|
||||
|
||||
- `2xx` - успех;
|
||||
- `3xx` - перенаправление;
|
||||
- `4xx` - ошибка клиента;
|
||||
- `5xx` - ошибка сервера.
|
||||
|
||||
**HTTPS** - это HTTP поверх TLS. Он шифрует трафик и проверяет сервер через сертификат. HTTP обычно использует порт `80`, HTTPS - `443`.
|
||||
|
||||
**HTTP/3** использует QUIC поверх UDP. Смысл методов и кодов HTTP не меняется, меняется транспорт.
|
||||
|
||||
**Идентификация** - пользователь сообщает, кто он. **Аутентификация** - доказывает это. **Авторизация** - система решает, что ему можно.
|
||||
|
||||
**OAuth 2.0** позволяет приложению получить ограниченный доступ без передачи пароля пользователя. Это протокол авторизации, не прямой протокол логина.
|
||||
|
||||
**URI** - общий идентификатор ресурса. **URL** - адрес и способ получить ресурс. **URN** - устойчивое имя без обязательного адреса.
|
||||
|
||||
### Блок 2. HTML
|
||||
|
||||
HTML описывает структуру страницы. Минимальная структура:
|
||||
|
||||
```html
|
||||
<!doctype html>
|
||||
<html lang="ru">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>Страница</title>
|
||||
</head>
|
||||
<body>
|
||||
Контент
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
`<head>` содержит служебные данные: `meta`, `title`, `link`, `script`. Видимый контент находится в `<body>`.
|
||||
|
||||
HTML-комментарий:
|
||||
|
||||
```html
|
||||
<!-- комментарий -->
|
||||
```
|
||||
|
||||
**Нормальный поток** - стандартная раскладка без flex/grid/position. Блочные элементы идут сверху вниз, строчные - внутри строки.
|
||||
|
||||
**Блочные элементы**: `<div>`, `<p>`, `<h1>`, `<section>`, `<form>`. Обычно занимают всю строку.
|
||||
|
||||
**Строчные элементы**: `<span>`, `<a>`, `<strong>`, `<em>`, `<code>`. Идут внутри текста.
|
||||
|
||||
**Семантические теги** помогают показать смысл: `<header>`, `<nav>`, `<main>`, `<section>`, `<article>`, `<aside>`, `<footer>`.
|
||||
|
||||
`class` используют для групповой стилизации. `id` должен быть уникальным на странице и часто используется для якорей и связи с `label`.
|
||||
|
||||
Заголовки - `<h1>` ... `<h6>`, абзацы - `<p>`, списки - `<ul>`/`<ol>` + `<li>`, таблицы - `<table>`, `<tr>`, `<th>`, `<td>`.
|
||||
|
||||
Ссылка:
|
||||
|
||||
```html
|
||||
<a href="https://example.com">Текст</a>
|
||||
```
|
||||
|
||||
Картинка:
|
||||
|
||||
```html
|
||||
<img src="image.jpg" alt="Описание">
|
||||
```
|
||||
|
||||
Повторяющиеся пробелы и переносы строк в HTML схлопываются. Для явного переноса используют `<br>`, но для абзацев лучше `<p>`.
|
||||
|
||||
### Блок 3. HTML Forms
|
||||
|
||||
Форма собирает данные пользователя и отправляет их на сервер:
|
||||
|
||||
```html
|
||||
<form action="/login/" method="post">
|
||||
<input name="username">
|
||||
<button type="submit">Войти</button>
|
||||
</form>
|
||||
```
|
||||
|
||||
Главные атрибуты формы:
|
||||
|
||||
- `action` - куда отправлять данные;
|
||||
- `method` - каким HTTP-методом: обычно `get` или `post`.
|
||||
|
||||
У полей:
|
||||
|
||||
- `id` нужен для связи с `label`;
|
||||
- `name` нужен серверу, именно под этим именем поле попадёт в запрос.
|
||||
|
||||
`label` связывают с полем через `for` и `id`:
|
||||
|
||||
```html
|
||||
<label for="email">Email</label>
|
||||
<input id="email" name="email" type="email">
|
||||
```
|
||||
|
||||
`radio` выбирает один вариант из группы с одинаковым `name`. `checkbox` - независимый флажок, можно выбрать несколько.
|
||||
|
||||
`required` делает поле обязательным. `placeholder` показывает подсказку внутри пустого поля, но не заменяет `label`.
|
||||
|
||||
`fieldset` и `legend` логически группируют поля.
|
||||
|
||||
`textarea` - многострочное поле текста.
|
||||
|
||||
У `<button>` важно явно указывать `type`: `submit`, `button`, `reset`.
|
||||
|
||||
### Блок 4. CSS selectors
|
||||
|
||||
CSS выбирает элементы селекторами и применяет к ним свойства.
|
||||
|
||||
Основные селекторы:
|
||||
|
||||
- `*` - все элементы;
|
||||
- `p` - все теги `<p>`;
|
||||
- `.card` - элементы с классом;
|
||||
- `#main` - элемент с id;
|
||||
- `div p` - потомки;
|
||||
- `div > p` - прямые дочерние элементы;
|
||||
- `h2 + p` - сосед сразу после `h2`;
|
||||
- `input[required]` - элементы по атрибуту;
|
||||
- `a:hover` - псевдокласс;
|
||||
- `li:nth-child(2)` - структурный псевдокласс.
|
||||
|
||||
Группировка:
|
||||
|
||||
```css
|
||||
h1, h2, h3 {
|
||||
color: black;
|
||||
}
|
||||
```
|
||||
|
||||
Комбинация селекторов:
|
||||
|
||||
```css
|
||||
button.primary:hover {
|
||||
background: blue;
|
||||
}
|
||||
```
|
||||
|
||||
**Каскад** - правила могут переопределять друг друга. Если свойство конфликтует, важны специфичность и порядок.
|
||||
|
||||
Специфичность по силе:
|
||||
|
||||
1. inline-style;
|
||||
2. id;
|
||||
3. class, attribute, pseudo-class;
|
||||
4. tag, pseudo-element.
|
||||
|
||||
Пример: `body .content` сильнее, чем `div p`, потому что класс сильнее тега.
|
||||
|
||||
Наследование - некоторые свойства переходят от родителя к потомку, например `color` и `font-family`. `margin`, `padding`, `border` обычно не наследуются.
|
||||
|
||||
### Блок 4. CSS базовые свойства
|
||||
|
||||
Блочная модель:
|
||||
|
||||
- `content` - содержимое;
|
||||
- `padding` - внутренний отступ;
|
||||
- `border` - рамка;
|
||||
- `margin` - внешний отступ.
|
||||
|
||||
`box-sizing: content-box` - `width` задаёт только контент. `box-sizing: border-box` - `width` включает `padding` и `border`.
|
||||
|
||||
Если задано `width: 100px`, `padding: 10px`, `border: 5px`, `box-sizing: border-box`, реальная ширина будет `100px`.
|
||||
|
||||
Фон:
|
||||
|
||||
- `background-color`;
|
||||
- `background-image`;
|
||||
- `background-repeat`;
|
||||
- `background-position`;
|
||||
- `background-size`.
|
||||
|
||||
Шрифты:
|
||||
|
||||
- `font-family` - семейство;
|
||||
- `font-size` - размер;
|
||||
- `font-weight` - толщина;
|
||||
- `font-style` - наклон.
|
||||
|
||||
Текст:
|
||||
|
||||
- `text-align` - выравнивание;
|
||||
- `text-decoration` - подчёркивание и другие линии;
|
||||
- `line-height` - расстояние между строками;
|
||||
- `letter-spacing` - расстояние между буквами;
|
||||
- `text-shadow` - тень текста.
|
||||
|
||||
`margin: 0 auto` часто центрирует блочный элемент с заданной шириной.
|
||||
|
||||
### Блок 5. FlexBox Layout. Grid Layout
|
||||
|
||||
Flexbox - одномерная раскладка: по строке или колонке.
|
||||
|
||||
```css
|
||||
.row {
|
||||
display: flex;
|
||||
flex-direction: row;
|
||||
}
|
||||
```
|
||||
|
||||
Главная ось зависит от `flex-direction`. При `row` главная ось горизонтальная, при `column` - вертикальная.
|
||||
|
||||
`justify-content` выравнивает по главной оси. `align-items` - по поперечной. Значение `align-items` по умолчанию - `stretch`.
|
||||
|
||||
`inline-flex` создаёт строчный flex-контейнер.
|
||||
|
||||
Свойства flex-элементов:
|
||||
|
||||
- `flex-grow` - как элемент растёт;
|
||||
- `flex-shrink` - как сжимается;
|
||||
- `flex-basis` - базовый размер до распределения свободного места.
|
||||
|
||||
Grid - двумерная раскладка: строки и столбцы.
|
||||
|
||||
```css
|
||||
.grid {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(3, 1fr);
|
||||
grid-template-rows: auto minmax(200px, 1fr);
|
||||
}
|
||||
```
|
||||
|
||||
`fr` - доля свободного пространства. `repeat(3, 1fr)` - три одинаковых столбца. `minmax(200px, 1fr)` - минимум 200px, максимум по доступному месту.
|
||||
|
||||
Термины Grid:
|
||||
|
||||
- grid lines - линии сетки;
|
||||
- grid tracks - строки или столбцы;
|
||||
- grid cells - ячейки;
|
||||
- grid areas - области.
|
||||
|
||||
### Блок 6. Django models
|
||||
|
||||
Модель Django - Python-класс, который описывает таблицу БД. Поле модели - колонка. Объект модели - строка.
|
||||
|
||||
Если не указать `primary_key`, Django создаёт поле `id`.
|
||||
|
||||
Миграции:
|
||||
|
||||
- `makemigrations` - создать миграции из изменений моделей;
|
||||
- `migrate` - применить миграции к БД.
|
||||
|
||||
`class Meta` задаёт настройки модели: сортировку, имена, ограничения.
|
||||
|
||||
`null=True` разрешает `NULL` в БД. `blank=True` разрешает пустое значение в формах.
|
||||
|
||||
`CharField` требует `max_length`.
|
||||
|
||||
`ForeignKey` задаёт связь "многие к одному". `on_delete` говорит, что делать при удалении связанного объекта. `related_name` задаёт имя обратной связи.
|
||||
|
||||
`ManyToManyField` задаёт связь многие-ко-многим. Связи меняются через `.add()`, `.remove()`, `.set()`, `.clear()`.
|
||||
|
||||
Промежуточная модель задаётся через `through`, если у связи есть свои поля.
|
||||
|
||||
### Блок 7. Django FBV
|
||||
|
||||
FBV - function-based view, обычная функция-представление.
|
||||
|
||||
View принимает `request` и возвращает `HttpResponse` или результат helper-функции:
|
||||
|
||||
```python
|
||||
def home(request):
|
||||
context = {"title": "Home"}
|
||||
return render(request, "index.html", context)
|
||||
```
|
||||
|
||||
В `render()` первым аргументом должен быть `request`.
|
||||
|
||||
Данные в шаблон передаются через context-словарь.
|
||||
|
||||
`get_object_or_404(Model, pk=pk)` получает объект или возвращает ошибку 404, если объекта нет.
|
||||
|
||||
Маршрут связывает URL и view:
|
||||
|
||||
```python
|
||||
path("", views.home, name="home")
|
||||
```
|
||||
|
||||
### Блок 8. Django CBV
|
||||
|
||||
CBV - class-based view, представление как класс.
|
||||
|
||||
Основные классы:
|
||||
|
||||
- `TemplateView` - просто показать шаблон;
|
||||
- `ListView` - показать список объектов;
|
||||
- `DetailView` - показать один объект.
|
||||
|
||||
CBV вызывается в маршруте через `.as_view()`:
|
||||
|
||||
```python
|
||||
path("posts/", PostListView.as_view(), name="post_list")
|
||||
```
|
||||
|
||||
`ListView` и `DetailView` можно привязать к модели через `model = Post` или через `queryset`.
|
||||
|
||||
Если в `ListView` не указать ни `model`, ни `queryset`, Django выдаст ошибку.
|
||||
|
||||
Стандартные переменные:
|
||||
|
||||
- `ListView`: `object_list` и `<model>_list`;
|
||||
- `DetailView`: `object` и `<model>`.
|
||||
|
||||
Дополнительные данные добавляют через `get_context_data()`.
|
||||
|
||||
Список объектов меняют через `get_queryset()`. Один объект в `DetailView` меняют через `get_object()`.
|
||||
|
||||
Паджинация в `ListView`:
|
||||
|
||||
```python
|
||||
paginate_by = 10
|
||||
```
|
||||
|
||||
Шаблоны по умолчанию:
|
||||
|
||||
- `ListView`: `<app>/<model>_list.html`;
|
||||
- `DetailView`: `<app>/<model>_detail.html`.
|
||||
|
||||
При переопределении методов часто вызывают `super()`, чтобы сохранить базовую логику Django.
|
||||
|
||||
### Блок 9. Django URLs
|
||||
|
||||
Маршрутизация описывается в `urls.py`.
|
||||
|
||||
`path()`:
|
||||
|
||||
```python
|
||||
path("posts/<int:pk>/", views.detail, name="detail")
|
||||
```
|
||||
|
||||
Аргументы:
|
||||
|
||||
- route - шаблон URL;
|
||||
- view - представление;
|
||||
- kwargs - дополнительные аргументы;
|
||||
- name - имя маршрута.
|
||||
|
||||
Path-конвертеры:
|
||||
|
||||
- `<int:pk>`;
|
||||
- `<str:name>`;
|
||||
- `<slug:slug>`;
|
||||
- `<uuid:id>`;
|
||||
- `<path:subpath>`.
|
||||
|
||||
`urlpatterns` - список маршрутов.
|
||||
|
||||
`re_path()` использует регулярные выражения.
|
||||
|
||||
`reverse()` строит URL по имени маршрута в Python.
|
||||
|
||||
Шаблонный тег:
|
||||
|
||||
```django
|
||||
{% url 'app:name' arg %}
|
||||
```
|
||||
|
||||
`app_name` задаёт namespace приложения.
|
||||
|
||||
### Блок 10. Язык шаблонов Django
|
||||
|
||||
Переменные:
|
||||
|
||||
```django
|
||||
{{ user.name }}
|
||||
```
|
||||
|
||||
Если переменной нет в контексте, обычно выводится пустая строка.
|
||||
|
||||
Теги:
|
||||
|
||||
```django
|
||||
{% for item in items %}
|
||||
{{ forloop.counter }}. {{ item }}
|
||||
{% endfor %}
|
||||
```
|
||||
|
||||
`forloop` даёт служебные данные цикла: `counter`, `first`, `last`.
|
||||
|
||||
Фильтры:
|
||||
|
||||
```django
|
||||
{{ title|lower }}
|
||||
{{ items|length }}
|
||||
{{ date|date:"Y-m-d" }}
|
||||
```
|
||||
|
||||
Наследование:
|
||||
|
||||
```django
|
||||
{% extends "base.html" %}
|
||||
|
||||
{% block content %}
|
||||
Контент
|
||||
{% endblock %}
|
||||
```
|
||||
|
||||
Включение шаблона:
|
||||
|
||||
```django
|
||||
{% include "parts/menu.html" %}
|
||||
```
|
||||
|
||||
Статика:
|
||||
|
||||
```django
|
||||
{% load static %}
|
||||
<link rel="stylesheet" href="{% static 'css/app.css' %}">
|
||||
```
|
||||
|
||||
Функции Python с произвольными аргументами напрямую из шаблона обычно не вызывают. Логику готовят во view, model method, custom template tag или filter.
|
||||
|
||||
### Блок 11. Django queries
|
||||
|
||||
ORM позволяет писать запросы к БД через Python-код.
|
||||
|
||||
`QuerySet` ленивый: запрос в БД не выполняется сразу при создании цепочки, а выполняется при обращении к данным.
|
||||
|
||||
Методы:
|
||||
|
||||
- `.all()` - все объекты;
|
||||
- `.filter()` - объекты по условию;
|
||||
- `.exclude()` - исключить условие;
|
||||
- `.get()` - один объект;
|
||||
- `.distinct()` - убрать дубли;
|
||||
- `.aggregate()` - итог по всей выборке, возвращает словарь;
|
||||
- `.annotate()` - вычисляемое поле для каждого объекта;
|
||||
- `.order_by()` - сортировка;
|
||||
- `.count()` - количество;
|
||||
- `.exists()` - проверка существования.
|
||||
|
||||
Цепочки:
|
||||
|
||||
```python
|
||||
Post.objects.filter(is_published=True).order_by("-created_at")
|
||||
```
|
||||
|
||||
`Q` нужен для сложных условий:
|
||||
|
||||
```python
|
||||
Post.objects.filter(Q(title__icontains="web") | Q(body__icontains="web"))
|
||||
```
|
||||
|
||||
`F` нужен для работы с полями на стороне БД:
|
||||
|
||||
```python
|
||||
Post.objects.update(views=F("views") + 1)
|
||||
```
|
||||
|
||||
N+1 - проблема, когда один запрос получает список, а потом в цикле делается по запросу на каждый связанный объект.
|
||||
|
||||
`select_related()` делает SQL JOIN и подходит для `ForeignKey`/`OneToOne`.
|
||||
|
||||
`prefetch_related()` делает отдельный запрос и подходит для `ManyToMany` и обратных связей.
|
||||
|
||||
### Блок 12. Django forms
|
||||
|
||||
`forms.Form` - обычная форма без прямой привязки к модели.
|
||||
|
||||
`forms.ModelForm` - форма на основе модели. Модель и поля задаются в `Meta`.
|
||||
|
||||
Основные поля:
|
||||
|
||||
- `CharField`;
|
||||
- `IntegerField`;
|
||||
- `BooleanField`;
|
||||
- `ChoiceField`;
|
||||
- `EmailField`;
|
||||
- `DateField`;
|
||||
- `FileField`.
|
||||
|
||||
`widget` управляет HTML-видом поля:
|
||||
|
||||
```python
|
||||
password = forms.CharField(widget=forms.PasswordInput)
|
||||
```
|
||||
|
||||
`help_text` задаёт подсказку.
|
||||
|
||||
Валидация одного поля:
|
||||
|
||||
```python
|
||||
def clean_email(self):
|
||||
email = self.cleaned_data["email"]
|
||||
return email
|
||||
```
|
||||
|
||||
Валидация связи между полями:
|
||||
|
||||
```python
|
||||
def clean(self):
|
||||
cleaned_data = super().clean()
|
||||
return cleaned_data
|
||||
```
|
||||
|
||||
После `is_valid()` появляются `cleaned_data` и `errors`. `cleaned_data` содержит очищенные Python-значения.
|
||||
|
||||
## Тестовые вопросы
|
||||
|
||||
### Какой селектор сильнее: `body .content` или `div p`?
|
||||
|
||||
A. div p
|
||||
B. Победит тот, который короче
|
||||
C. body .content
|
||||
D. Они равны
|
||||
|
||||
✅ Ответ: **C. body .content**
|
||||
|
||||
---
|
||||
|
||||
### С помощью какого свойства можно добавить тень к тексту?
|
||||
|
||||
A. text-shadow
|
||||
B. shadow-text
|
||||
C. box-shadow
|
||||
D. font-shadow
|
||||
|
||||
✅ Ответ: **A. text-shadow**
|
||||
|
||||
---
|
||||
|
||||
### Дан блок CSS
|
||||
|
||||
```css
|
||||
width: 100px;
|
||||
padding: 10px;
|
||||
border: 5px solid;
|
||||
box-sizing: border-box;
|
||||
```
|
||||
|
||||
Какова его реальная ширина?
|
||||
|
||||
A. 120px
|
||||
B. 115px
|
||||
C. 130px
|
||||
D. 100px
|
||||
|
||||
✅ Ответ: **D. 100px**
|
||||
|
||||
---
|
||||
|
||||
### Значение свойства `align-items` по умолчанию
|
||||
|
||||
A. flex-start
|
||||
B. stretch
|
||||
C. center
|
||||
D. baseline
|
||||
|
||||
✅ Ответ: **B. stretch**
|
||||
|
||||
---
|
||||
|
||||
### Как называются линии, которые образуют структуру сетки?
|
||||
|
||||
A. Grid Tracks
|
||||
B. Grid Cells
|
||||
C. Grid Areas
|
||||
D. Grid Lines
|
||||
|
||||
✅ Ответ: **D. Grid Lines**
|
||||
|
||||
---
|
||||
|
||||
### С помощью какого аргумента можно указать собственную модель для промежуточной таблицы?
|
||||
|
||||
A. to_field
|
||||
B. intermediate
|
||||
C. through
|
||||
D. link_model
|
||||
|
||||
✅ Ответ: **C. through**
|
||||
|
||||
---
|
||||
|
||||
### Как называется поле, которое Django создаёт автоматически, если не указан `primary_key`?
|
||||
|
||||
A. uuid
|
||||
B. pk_id
|
||||
C. id
|
||||
D. index
|
||||
|
||||
✅ Ответ: **C. id**
|
||||
|
||||
---
|
||||
|
||||
### Как найти самую высокую цену товара в категории?
|
||||
|
||||
A. `Product.objects.aggregate(Max('price'))`
|
||||
B. `Product.objects.filter(max=True)`
|
||||
C. `Category.objects.count('price')`
|
||||
D. `Category.objects.annotate(Max('product__price'))`
|
||||
|
||||
✅ Ответ: **D** (для максимума по каждой категории)
|
||||
|
||||
---
|
||||
|
||||
### Какой фильтр используется для поиска подстроки без учёта регистра?
|
||||
|
||||
A. `__exact`
|
||||
B. `__search`
|
||||
C. `__icontains`
|
||||
D. `__contains`
|
||||
|
||||
✅ Ответ: **C. __icontains**
|
||||
|
||||
---
|
||||
|
||||
### В каком файле проекта обычно настраиваются основные маршруты?
|
||||
|
||||
A. models.py
|
||||
B. urls.py
|
||||
C. settings.py
|
||||
D. views.py
|
||||
|
||||
✅ Ответ: **B. urls.py**
|
||||
|
||||
---
|
||||
|
||||
### Как называется аргумент в функции `path()`, который позволяет обращаться к маршруту по имени в шаблонах?
|
||||
|
||||
A. alias
|
||||
B. id
|
||||
C. name
|
||||
D. ref
|
||||
|
||||
✅ Ответ: **C. name**
|
||||
|
||||
---
|
||||
|
||||
### Что произойдёт, если обратиться к переменной, которой нет в контексте?
|
||||
|
||||
A. Django вызовет NameError
|
||||
B. Отобразится текст "None"
|
||||
C. Страница вернёт ошибку 500
|
||||
D. Вместо переменной будет выведена пустая строка
|
||||
|
||||
✅ Ответ: **D. Пустая строка**
|
||||
|
||||
---
|
||||
|
||||
### Какой синтаксис используется для шаблонных тегов?
|
||||
|
||||
A. `{% tag %}`
|
||||
B. `{{ tag }}`
|
||||
C. `{# tag #}`
|
||||
D. `<% tag %>`
|
||||
|
||||
✅ Ответ: **A. {% tag %}**
|
||||
|
||||
---
|
||||
|
||||
### В чём ошибка? FBV
|
||||
|
||||
```python
|
||||
def home(request):
|
||||
context = {"title": "Home"}
|
||||
return render("index.html", context)
|
||||
```
|
||||
|
||||
A. Первым аргументом в render всегда должен идти request
|
||||
B. Путь к шаблону должен быть в кортеже
|
||||
C. Context должен быть списком
|
||||
D. Нужно использовать render_to_response
|
||||
|
||||
✅ Ответ: **A**
|
||||
|
||||
---
|
||||
|
||||
### Какая функция позволяет быстро получить объект из базы или выдать 404?
|
||||
|
||||
A. get_object
|
||||
B. get_object_or_404
|
||||
C. find_or_404
|
||||
|
||||
✅ Ответ: **B. get_object_or_404**
|
||||
|
||||
---
|
||||
|
||||
### Что произойдёт, если в `ListView` не указать ни `model`, ни `queryset`?
|
||||
|
||||
A. Django автоматически найдёт модель по названию класса
|
||||
B. Ошибка во время запуска
|
||||
C. Он покажет все объекты из базы
|
||||
D. Покажет пустой список
|
||||
|
||||
✅ Ответ: **B**
|
||||
|
||||
---
|
||||
### Как правильно создать ссылку на маршрут с именем `find`?
|
||||
|
||||
A. `<a href="/myapp/find/">`
|
||||
B. `<a href="{% path 'myapp:find' %}">`
|
||||
C. `<a href="{{ search myapp.find }}">`
|
||||
D. `<a href="{% url 'myapp:find' %}">`
|
||||
|
||||
✅ Ответ: **D**
|
||||
|
||||
---
|
||||
|
||||
### Для чего используется `app_name` в urls.py?
|
||||
|
||||
A. Для выбора БД
|
||||
B. Для задания пространства имён (namespace)
|
||||
C. Для заголовка сайта
|
||||
D. Технический комментарий
|
||||
|
||||
✅ Ответ: **B**
|
||||
|
||||
---
|
||||
|
||||
### Как обратиться к ключу словаря `user_data['name']` в шаблоне?
|
||||
|
||||
A. `{{ user_data.name }}`
|
||||
B. `{{ user_data['name'] }}`
|
||||
C. `{{ user_data.get('name') }}`
|
||||
D. `{{ user_data->name }}`
|
||||
|
||||
✅ Ответ: **A**
|
||||
|
||||
---
|
||||
|
||||
### Где обычно описывается логика FBV в Django?
|
||||
|
||||
A. admin.py
|
||||
B. views.py
|
||||
C. models.py
|
||||
|
||||
✅ Ответ: **B. views.py**
|
||||
|
||||
### Как работает `select_related` на уровне SQL?
|
||||
1) Делает `SQL JOIN` и получает данные за один запрос.
|
||||
2) Группирует данные через `GROUP BY`
|
||||
3) Кэширует данные
|
||||
4) Выполняет дополнительный отдельный запрос
|
||||
|
||||
### В каком файле проекта обычно настраиваются основные маршруты (URL-адреса)?
|
||||
1) `models.py`
|
||||
2) `urls.py`
|
||||
3) `settings.py`
|
||||
4) `views.py`
|
||||
|
||||
### Как называется аргумент в функции `path()`, позволяющий обращаться к маршруту по имени в шаблонах?
|
||||
1) `alias`
|
||||
2) `id`
|
||||
3) `name`
|
||||
4) `ref`
|
||||
|
||||
### Какая функция позволяет быстро получить объект из базы или вызвать 404, если объект не найден?
|
||||
1) `get_or_error()`
|
||||
2) `request_object()`
|
||||
3) `get_object_or_404()`
|
||||
4) `find_or_404()`
|
||||
|
||||
### Что произойдет, если в ListView не указать ни `model`, ни `queryset`?
|
||||
1) Он автоматически найдет модель по названию класса.
|
||||
2) Django выдаст ошибку.
|
||||
3) Он покажет все объекты базы.
|
||||
4) Покажет пустой список.
|
||||
|
||||
### Какой метод в CBV отвечает за получение словаря контекста для шаблона?
|
||||
1) `get_template_context()`
|
||||
2) `set_context_data()`
|
||||
3) `get_context_data()`
|
||||
4) `get_context()`
|
||||
|
||||
### Какой метод следует переопределить для валидации связи между полями (например, "Пароль" и "Повтор пароля")?
|
||||
1) Метод `save()` в модели.
|
||||
2) `validate_fields()`.
|
||||
3) `clean_password()`.
|
||||
4) Общий метод `clean()` всего класса формы.
|
||||
+38
-34
@@ -1,5 +1,9 @@
|
||||
# УИР (Глава 1): Обзор аналогов и обоснование инструментария системы учёта посещаемости студентов НИЯУ МИФИ
|
||||
---
|
||||
created: 2026-06-08
|
||||
updated: 2026-06-08
|
||||
---
|
||||
|
||||
# УИР:
|
||||
## TL;DR
|
||||
- **Готового аналога, закрывающего все требования МИФИ, на рынке нет:** зарубежные универсальные инструменты (Microsoft Teams, Google Classroom/Meet, Brightspace) фиксируют посещаемость лишь как побочный продукт онлайн-встреч и не интегрируются с CAS МИФИ и внутренними реестрами; российские ЭЖ/LMS (БАРС.Образование, iSpring Learn, 1С:Университет) ориентированы на школу или корпоративное обучение, не дают студенческой QR-самоотметки и Outbox-синхронизации. Это прямо обосновывает разработку собственной системы.
|
||||
- **Стек Rails 7 + Hotwire + PostgreSQL + Sidekiq/Redis + Tailwind обоснован архитектурно:** server-rendered HTML через Hotwire снимает необходимость в отдельном SPA, Outbox-паттерн гарантирует надёжную (at-least-once) доставку данных во внешние реестры, Service Objects изолируют бизнес-логику, namespaced-контроллеры естественно поддерживают ролевую модель вуза.
|
||||
@@ -9,11 +13,11 @@
|
||||
|
||||
### Часть 1. Аналоги
|
||||
1. Ни один массовый продукт не сочетает одновременно четыре ключевых свойства, необходимых корпоративному вузу: **(а)** QR-самоотметку студента на очном занятии, **(б)** интеграцию с корпоративным SSO (CAS МИФИ), **(в)** гарантированную (Outbox) синхронизацию с внутренними академическими реестрами, **(г)** полную ролевую модель (студент / преподаватель / куратор / деканат / администратор).
|
||||
2. Российские школьные ЭЖ (БАРС, Дневник.ру, ЭлЖур, «Сетевой город») реализуют посещаемость как **ручную отметку учителя**; модель «класс — родитель» не масштабируется на вузовскую «поток — группа — подгруппа».
|
||||
2. Российские школьные ЭЖ (БАРС, Дневник.ру, ЭлЖур, "Сетевой город") реализуют посещаемость как **ручную отметку учителя**; модель "класс — родитель" не масштабируется на вузовскую "поток — группа — подгруппа".
|
||||
3. Зарубежные инструменты считают **присутствие на онлайн-встрече** (время входа/выхода), что не эквивалентно присутствию на очном занятии.
|
||||
|
||||
### Часть 2. Инструментарий
|
||||
Каждый компонент стека имеет рецензируемое либо авторитетное первичное обоснование, пригодное для цитирования в УИР; «слабые места» (производительность Ruby, противоречивость бенчмарков СУБД, небиблиометричность части источников) отмечены явно.
|
||||
Каждый компонент стека имеет рецензируемое либо авторитетное первичное обоснование, пригодное для цитирования в УИР; "слабые места" (производительность Ruby, противоречивость бенчмарков СУБД, небиблиометричность части источников) отмечены явно.
|
||||
|
||||
---
|
||||
|
||||
@@ -23,53 +27,53 @@
|
||||
|
||||
### Российские системы
|
||||
|
||||
**1. Система «Учёт посещаемости студентов» ВВГУ (ВГУЭС)**
|
||||
**1. Система "Учёт посещаемости студентов" ВВГУ (ВГУЭС)**
|
||||
- *Описание:* собственная разработка Департамента цифрового развития ВВГУ. Преподаватель показывает QR-код, студенты сканируют его для записи о присутствии; возможна ручная отметка преподавателем или назначенным кафедрой куратором группы.
|
||||
- *Функции:* QR-отметка, ручная отметка, роль куратора.
|
||||
- *Ограничения:* закрытая внутренняя система одного вуза; нет публичного API/Outbox-синхронизации; права куратора выдаются по бумажному заявлению в Центр ИТ-обеспечения.
|
||||
- *Почему хуже для МИФИ:* не интегрируется с внешними CAS/реестрами МИФИ; ограниченная ролевая модель.
|
||||
|
||||
**2. БАРС.Образование — Электронная школа**
|
||||
- *Описание:* одна из самых распространённых в РФ платформ ЭЖ/электронного дневника; модуль «БАРС.Образование — Электронная школа» рекомендован Минкомсвязью к тиражированию в рамках мероприятия «Электронный регион»; вход — по логину/паролю Госуслуг.
|
||||
- *Описание:* одна из самых распространённых в РФ платформ ЭЖ/электронного дневника; модуль "БАРС.Образование — Электронная школа" рекомендован Минкомсвязью к тиражированию в рамках мероприятия "Электронный регион"; вход — по логину/паролю Госуслуг.
|
||||
- *Функции:* электронный журнал (оценки, темы уроков, отметка посещаемости — вручную учителем), электронный дневник, планирование учебного процесса, расписание, отчётность.
|
||||
- *Ограничения:* посещаемость только ручная (нет QR/самоотметки); архитектура «школа — класс — родитель».
|
||||
- *Ограничения:* посещаемость только ручная (нет QR/самоотметки); архитектура "школа — класс — родитель".
|
||||
- *Почему хуже для МИФИ:* школьная модель данных; интеграция реализуется через СМЭВ/Госуслуги, а не через корпоративный CAS вуза; проприетарность.
|
||||
|
||||
**3. iSpring Learn (iSpring LMS)**
|
||||
- *Описание:* российская корпоративная LMS (компания iSpring, Йошкар-Ола; платформу используют клиенты в 172 странах), доступна в облаке вендора и в установке на сервер клиента (on-premise).
|
||||
- *Функции:* курсы, тесты, вебинары (интеграция с Zoom), отчёт «ILT Attendance» по посещаемости очных тренингов/вебинаров (преподаватель отмечает участников вручную после мероприятия), SSO, открытый API, мобильное приложение.
|
||||
- *Ограничения:* посещаемость — побочная функция «мероприятий»; нет QR-самоотметки на занятии; нет модели «учебный поток вуза».
|
||||
- *Функции:* курсы, тесты, вебинары (интеграция с Zoom), отчёт "ILT Attendance" по посещаемости очных тренингов/вебинаров (преподаватель отмечает участников вручную после мероприятия), SSO, открытый API, мобильное приложение.
|
||||
- *Ограничения:* посещаемость — побочная функция "мероприятий"; нет QR-самоотметки на занятии; нет модели "учебный поток вуза".
|
||||
- *Почему хуже для МИФИ:* предназначена для корпоративного обучения персонала, а не для учёта очной посещаемости студентов; нет Outbox-синхронизации с академическими реестрами.
|
||||
|
||||
**4. 1С:Университет**
|
||||
- *Описание:* отраслевое решение на платформе «1С:Предприятие 8.3» для комплексного управления вузом.
|
||||
- *Описание:* отраслевое решение на платформе "1С:Предприятие 8.3" для комплексного управления вузом.
|
||||
- *Функции:* контингент студентов, личные дела и зачётные книги, учёт успеваемости и посещаемости, массовое формирование ведомостей, приёмная кампания, поддержка территориально распределённых баз.
|
||||
- *Ограничения:* тяжёлое ERP-решение, посещаемость вводится вручную через АРМ; нет студенческого QR-self-service и нативного веб-самообслуживания.
|
||||
- *Почему хуже для МИФИ:* монолитная проприетарная экосистема 1С; интеграция требует механизмов обмена 1С, а не REST/CAS.
|
||||
|
||||
**5. Прочие российские: Дневник.ру, ЭлЖур, «Сетевой город. Образование» (NetSchool), «Мой Класс», «Учебный учет»**
|
||||
- Это школьные электронные журналы или CRM для учебных центров: ручная отметка посещаемости, модель «класс/группа», без QR-self-service и без вузовской интеграции с CAS/реестрами.
|
||||
**5. Прочие российские: Дневник.ру, ЭлЖур, "Сетевой город. Образование" (NetSchool), "Мой Класс", "Учебный учет"**
|
||||
- Это школьные электронные журналы или CRM для учебных центров: ручная отметка посещаемости, модель "класс/группа", без QR-self-service и без вузовской интеграции с CAS/реестрами.
|
||||
|
||||
### Зарубежные системы
|
||||
|
||||
**6. Microsoft Teams (attendance & engagement report)**
|
||||
- *Функции:* автоматический отчёт о посещаемости онлайн-встречи (имена, время входа/выхода, длительность участия); engagement-отчёт (реакции, поднятые руки, включённые камеры) — только в Teams Enterprise/Premium; экспорт в CSV.
|
||||
- *Ограничения:* фиксирует присутствие на **видеовстрече**, а не на очном занятии. По документации Microsoft, «If the event organizer leaves the org, reports are permanently deleted and can't be retrieved» — отчёты привязаны к организатору и безвозвратно удаляются при его уходе из организации. Также: «In meetings with more than 120 participants, the attendance report that's available during the meeting will only include a partial list of attendees. The post-meeting report will contain the full list» — во время встречи >120 участников виден лишь частичный список.
|
||||
- *Ограничения:* фиксирует присутствие на **видеовстрече**, а не на очном занятии. По документации Microsoft, "If the event organizer leaves the org, reports are permanently deleted and can't be retrieved" — отчёты привязаны к организатору и безвозвратно удаляются при его уходе из организации. Также: "In meetings with more than 120 participants, the attendance report that's available during the meeting will only include a partial list of attendees. The post-meeting report will contain the full list" — во время встречи >120 участников виден лишь частичный список.
|
||||
- *Почему хуже для МИФИ:* считает онлайн-участие; нет QR для очных занятий; нет интеграции с CAS/реестрами МИФИ; нет вузовской ролевой модели.
|
||||
|
||||
**7. Google Classroom / Google Meet (attendance tracking)**
|
||||
- *Функции:* в самом Google Classroom **нативной отметки посещаемости нет** (распространённый обходной путь — Google Forms/Sheets). По справке Google Meet, отслеживание посещаемости доступно только на платных тарифах: «Attendance tracking is available to Google Workspace Essentials, Business Plus, Enterprise Starter, Enterprise Essentials, Enterprise Standard, Enterprise Plus, Education Plus and the Teaching and Learning Upgrade users»; пользователи Education Plus и Teaching and Learning Upgrade «automatically receive an attendance report for any meeting with two or more participants».
|
||||
- *Функции:* в самом Google Classroom **нативной отметки посещаемости нет** (распространённый обходной путь — Google Forms/Sheets). По справке Google Meet, отслеживание посещаемости доступно только на платных тарифах: "Attendance tracking is available to Google Workspace Essentials, Business Plus, Enterprise Starter, Enterprise Essentials, Enterprise Standard, Enterprise Plus, Education Plus and the Teaching and Learning Upgrade users"; пользователи Education Plus и Teaching and Learning Upgrade "automatically receive an attendance report for any meeting with two or more participants".
|
||||
- *Ограничения:* отсутствие встроенной посещаемости в Classroom; отчёт Meet формируется по онлайн-встрече и требует платной редакции; привязка к экосистеме Google Workspace.
|
||||
- *Почему хуже для МИФИ:* ключевая функция отсутствует/платная; нет очного QR; нет интеграции с внутренними системами вуза.
|
||||
|
||||
**8. Brightspace (D2L) — Attendance tool**
|
||||
- *Функции:* реестры посещаемости (registers), настраиваемые схемы статусов и порог тревоги. По документации D2L, системная схема (System Scheme) состоит из двух статусов — present и absent, а «Cause for Concern (%)» задаёт порог, при падении ниже которого в колонке процента посещаемости выводится предупреждение; есть интеграция с журналом оценок и e-mail. QR/мобильная самоотметка — **только через сторонние интеграции** (Qwickly Attendance, You-Attend) из D2L IntegrationHub.
|
||||
- *Функции:* реестры посещаемости (registers), настраиваемые схемы статусов и порог тревоги. По документации D2L, системная схема (System Scheme) состоит из двух статусов — present и absent, а "Cause for Concern (%)" задаёт порог, при падении ниже которого в колонке процента посещаемости выводится предупреждение; есть интеграция с журналом оценок и e-mail. QR/мобильная самоотметка — **только через сторонние интеграции** (Qwickly Attendance, You-Attend) из D2L IntegrationHub.
|
||||
- *Ограничения:* базовый инструмент — электронный ledger; отметку ставит преподаватель/ассистент вручную (инструмент **не** self-reporting).
|
||||
- *Почему хуже для МИФИ:* требует внедрения всей LMS Brightspace плюс платных плагинов для QR; нет нативной интеграции с CAS МИФИ.
|
||||
|
||||
**9. Специализированные QR/чек-ин SaaS: OneTap, AccuClass (Engineerica), QR-Code-Generator, SuperQR, QR Attendee**
|
||||
- *Функции:* QR/штрихкод чек-ин, импорт из Excel, дашборды, отчёты, иногда геолокация.
|
||||
- *Ограничения:* SaaS «под мероприятия/школы/залы»; данные хранятся в облаке вендора; нет вузовской ролевой модели и интеграции с внутренними реестрами.
|
||||
- *Ограничения:* SaaS "под мероприятия/школы/залы"; данные хранятся в облаке вендора; нет вузовской ролевой модели и интеграции с внутренними реестрами.
|
||||
- *Почему хуже для МИФИ:* vendor lock-in, хранение ПДн у внешнего провайдера, отсутствие SSO-интеграции с CAS и Outbox-синхронизации.
|
||||
|
||||
**10. Open-source проекты (GitHub: AzeemIdrisi/QR-Attendance-System, Gudleifr1/Check-by-QR и др.)**
|
||||
@@ -81,7 +85,7 @@
|
||||
|
||||
| Система | QR-self-service | SSO/CAS-интеграция | Outbox-синхронизация | Вузовская ролевая модель | On-premise | Open-source |
|
||||
|---|---|---|---|---|---|---|
|
||||
| ВВГУ «Учёт посещаемости» | ✔ | ✘ | ✘ | частично | ✔ | ✘ |
|
||||
| ВВГУ "Учёт посещаемости" | ✔ | ✘ | ✘ | частично | ✔ | ✘ |
|
||||
| БАРС.Образование | ✘ | ✘ (Госуслуги/СМЭВ) | ✘ | школьная | зависит | ✘ |
|
||||
| iSpring Learn | ✘ | ✔ (SSO) | ✘ | корпоративная | ✔ | ✘ |
|
||||
| 1С:Университет | ✘ | ✘ | ✘ (обмен 1С) | ✔ | ✔ | ✘ |
|
||||
@@ -91,20 +95,20 @@
|
||||
| QR-SaaS (OneTap и др.) | ✔ | частично | ✘ | ✘ | ✘ | ✘ |
|
||||
| **Проектируемая система МИФИ** | **✔** | **✔ (CAS МИФИ)** | **✔** | **✔ (полная)** | **✔** | **✔** |
|
||||
|
||||
**Вывод по Части 1:** ниша «QR-самоотметка очной посещаемости + CAS-SSO вуза + Outbox-синхронизация с реестрами + полная ролевая модель + on-premise» не закрыта существующими продуктами — это и есть обоснование разработки собственной системы.
|
||||
**Вывод по Части 1:** ниша "QR-самоотметка очной посещаемости + CAS-SSO вуза + Outbox-синхронизация с реестрами + полная ролевая модель + on-premise" не закрыта существующими продуктами — это и есть обоснование разработки собственной системы.
|
||||
|
||||
---
|
||||
|
||||
## ЧАСТЬ 2. ОБОСНОВАНИЕ ВЫБОРА ИНСТРУМЕНТАРИЯ (с источниками)
|
||||
|
||||
### 2.1 Веб-фреймворк: Ruby on Rails 7 (vs Django / Laravel / Spring)
|
||||
- *Обоснование:* Rails реализует строгий паттерн MVC, принципы «Convention over Configuration» и DRY, что ускоряет разработку CRUD-приложений; зрелая экосистема gem'ов; Hotwire включён в Rails 7 «из коробки». На Rails работают GitHub, Shopify, Basecamp.
|
||||
- *Честный контр-аргумент:* Ruby исторически уступает по «сырой» производительности оптимизированному PHP/Python и требует больше памяти; компенсируется фоновой обработкой, кэшированием и горизонтальным масштабированием.
|
||||
- *Русскоязычный источник:* Даньшин К.А. «Сравнительный анализ современных веб-фреймворков для разработки приложений» (CyberLeninka, 2019) — сравнение ASP.NET Core, Laravel, Spring, Ruby on Rails, Django. Альтернатива (ВАК): «Преимущества и недостатки фреймворков для разработки веб-приложений в целях цифровизации экономики» // «Научное обозрение. Технические науки».
|
||||
- *Обоснование:* Rails реализует строгий паттерн MVC, принципы "Convention over Configuration" и DRY, что ускоряет разработку CRUD-приложений; зрелая экосистема gem'ов; Hotwire включён в Rails 7 "из коробки". На Rails работают GitHub, Shopify, Basecamp.
|
||||
- *Честный контр-аргумент:* Ruby исторически уступает по "сырой" производительности оптимизированному PHP/Python и требует больше памяти; компенсируется фоновой обработкой, кэшированием и горизонтальным масштабированием.
|
||||
- *Русскоязычный источник:* Даньшин К.А. "Сравнительный анализ современных веб-фреймворков для разработки приложений" (CyberLeninka, 2019) — сравнение ASP.NET Core, Laravel, Spring, Ruby on Rails, Django. Альтернатива (ВАК): "Преимущества и недостатки фреймворков для разработки веб-приложений в целях цифровизации экономики" // "Научное обозрение. Технические науки".
|
||||
- *Раздел:* выбор бэкенд-фреймворка и архитектуры MVC.
|
||||
|
||||
### 2.2 Hotwire / Turbo / Stimulus (альтернатива SPA)
|
||||
- *Обоснование:* Hotwire («HTML Over The Wire», автор — D. H. Hansson) отправляет фрагменты HTML вместо JSON, обеспечивая «SPA-ощущение» без тяжёлого клиентского JS. Компоненты: Turbo Drive (навигация без полной перезагрузки), Turbo Frames (независимые регионы), Turbo Streams (точечные/realtime-обновления, в т.ч. по WebSocket), Stimulus (минимальная интерактивность). Меньше передаваемых данных, быстрее загрузка, проще поддержка для backend-команды.
|
||||
- *Обоснование:* Hotwire ("HTML Over The Wire", автор — D. H. Hansson) отправляет фрагменты HTML вместо JSON, обеспечивая "SPA-ощущение" без тяжёлого клиентского JS. Компоненты: Turbo Drive (навигация без полной перезагрузки), Turbo Frames (независимые регионы), Turbo Streams (точечные/realtime-обновления, в т.ч. по WebSocket), Stimulus (минимальная интерактивность). Меньше передаваемых данных, быстрее загрузка, проще поддержка для backend-команды.
|
||||
- *Честный контр-аргумент:* в части независимых тестов прирост скорости навигации Turbo по сравнению с уже оптимизированными решениями оказывался незначительным; htmx даёт меньший бандл. Для backend-ориентированной команды и server-rendered приложения выигрыш Hotwire — прежде всего в DX и снижении объёма JS.
|
||||
- *Раздел:* фронтенд-архитектура; обоснование отказа от отдельного React/Vue SPA.
|
||||
|
||||
@@ -113,18 +117,18 @@
|
||||
- *Раздел:* асинхронная обработка; реализация Outbox-релея.
|
||||
|
||||
### 2.4 Outbox Pattern (надёжная доставка во внешние реестры)
|
||||
- *Обоснование:* решает проблему «dual write» — несогласованности при одновременной записи в БД и отправке сообщения брокеру. Событие записывается в outbox-таблицу **в той же транзакции**, что и бизнес-данные; отдельный процесс-релей (Sidekiq) публикует его наружу, обеспечивая гарантию доставки at-least-once; получатели должны быть **идемпотентны** (релей может опубликовать сообщение более одного раза). Устраняет необходимость в распределённых транзакциях (2PC).
|
||||
- *Источники (первичные/авторитетные):* Chris Richardson, microservices.io — «Pattern: Transactional outbox»; AWS Prescriptive Guidance — «Transactional outbox pattern»; Confluent Developer; книга Chris Richardson «Microservices Patterns».
|
||||
- *Обоснование:* решает проблему "dual write" — несогласованности при одновременной записи в БД и отправке сообщения брокеру. Событие записывается в outbox-таблицу **в той же транзакции**, что и бизнес-данные; отдельный процесс-релей (Sidekiq) публикует его наружу, обеспечивая гарантию доставки at-least-once; получатели должны быть **идемпотентны** (релей может опубликовать сообщение более одного раза). Устраняет необходимость в распределённых транзакциях (2PC).
|
||||
- *Источники (первичные/авторитетные):* Chris Richardson, microservices.io — "Pattern: Transactional outbox"; AWS Prescriptive Guidance — "Transactional outbox pattern"; Confluent Developer; книга Chris Richardson "Microservices Patterns".
|
||||
- *Раздел:* синхронизация с внешними реестрами МИФИ; надёжность данных.
|
||||
|
||||
### 2.5 Service Objects в Rails
|
||||
- *Обоснование:* вынос бизнес-логики из «толстых» моделей/контроллеров в PORO (plain old Ruby object) с единственным публичным методом `call`, размещаемые в `app/services`. Принципы: единая ответственность, тестируемость в изоляции, переиспользуемость, «skinny models, skinny controllers».
|
||||
- *Честный контр-аргумент:* часть сообщества (M. Fowler — критика «анемичной модели») считает массовые Service Objects антипаттерном, ведущим к процедурному стилю; применять для логики, которая действительно не принадлежит ни модели, ни контроллеру.
|
||||
- *Обоснование:* вынос бизнес-логики из "толстых" моделей/контроллеров в PORO (plain old Ruby object) с единственным публичным методом `call`, размещаемые в `app/services`. Принципы: единая ответственность, тестируемость в изоляции, переиспользуемость, "skinny models, skinny controllers".
|
||||
- *Честный контр-аргумент:* часть сообщества (M. Fowler — критика "анемичной модели") считает массовые Service Objects антипаттерном, ведущим к процедурному стилю; применять для логики, которая действительно не принадлежит ни модели, ни контроллеру.
|
||||
- *Раздел:* организация бизнес-логики (генерация/валидация QR, проведение отметки, формирование Outbox-событий).
|
||||
|
||||
### 2.6 СУБД: PostgreSQL (vs MySQL / SQLite)
|
||||
- *Обоснование:* PostgreSQL — полностью ACID-совместимая СУБД с MVCC, расширенным набором типов, ролевой моделью доступа (role-based access control), SSL/TLS, логической репликацией (Publish/Subscribe); предпочтительна для сложных транзакционных приложений с большими объёмами данных.
|
||||
- *Рецензируемый источник:* Salunke S.V., Ouda A. «A Performance Benchmark for the PostgreSQL and MySQL Databases» // Future Internet (MDPI). 2024. Vol. 16(10). Art. 382. DOI: 10.3390/fi16100382. Ключевой результат: «PostgreSQL's execution time for 1 million records ranged from 0.6 ms to 0.8 ms, while MySQL's ranged from 9 ms to 12 ms, indicating that PostgreSQL is about 13 times faster»; для SELECT c WHERE — 0.09–0.13 мс против 0.9–1 мс (≈9× быстрее). Авторы отмечают: «Our quantified results show PostgreSQL's superior performance in select operations».
|
||||
- *Рецензируемый источник:* Salunke S.V., Ouda A. "A Performance Benchmark for the PostgreSQL and MySQL Databases" // Future Internet (MDPI). 2024. Vol. 16(10). Art. 382. DOI: 10.3390/fi16100382. Ключевой результат: "PostgreSQL's execution time for 1 million records ranged from 0.6 ms to 0.8 ms, while MySQL's ranged from 9 ms to 12 ms, indicating that PostgreSQL is about 13 times faster"; для SELECT c WHERE — 0.09–0.13 мс против 0.9–1 мс (≈9× быстрее). Авторы отмечают: "Our quantified results show PostgreSQL's superior performance in select operations".
|
||||
- *Честный контр-аргумент:* результаты бенчмарков зависят от профиля нагрузки — в ряде независимых тестов (sysbench OLTP read-only) MySQL опережал PostgreSQL на простых SELECT на 20–30%. Абсолютное превосходство одной СУБД утверждать некорректно; выбор PostgreSQL мотивирован транзакционной целостностью и богатством типов, важными для Outbox и ролевой модели.
|
||||
- *Раздел:* выбор хранилища данных.
|
||||
|
||||
@@ -133,8 +137,8 @@
|
||||
- *Раздел:* архитектура контроллеров и авторизация.
|
||||
|
||||
### 2.8 CSS: Tailwind CSS (vs Bootstrap)
|
||||
- *Обоснование:* utility-first подход даёт существенно меньший production-бандл за счёт JIT-purge (по отраслевым обзорам — на 60–70% меньше, чем production-CSS Bootstrap), полную кастомизацию через `tailwind.config.js` и отсутствие навязанного «вида Bootstrap»; нативная интеграция с Rails 7 (`rails new myapp --css tailwind`). Tailwind не тянет JS-компоненты (Bootstrap поставляет ~20 КБ JS).
|
||||
- *Честный контр-аргумент:* более крутая кривая обучения и «шумная» разметка; Bootstrap быстрее для прототипа за счёт готовых компонентов и CDN-подключения.
|
||||
- *Обоснование:* utility-first подход даёт существенно меньший production-бандл за счёт JIT-purge (по отраслевым обзорам — на 60–70% меньше, чем production-CSS Bootstrap), полную кастомизацию через `tailwind.config.js` и отсутствие навязанного "вида Bootstrap"; нативная интеграция с Rails 7 (`rails new myapp --css tailwind`). Tailwind не тянет JS-компоненты (Bootstrap поставляет ~20 КБ JS).
|
||||
- *Честный контр-аргумент:* более крутая кривая обучения и "шумная" разметка; Bootstrap быстрее для прототипа за счёт готовых компонентов и CDN-подключения.
|
||||
- *Раздел:* выбор UI-фреймворка.
|
||||
|
||||
### 2.9 SSO / CAS (Central Authentication Service)
|
||||
@@ -142,10 +146,10 @@
|
||||
- *Раздел:* интеграция с корпоративной системой аутентификации МИФИ.
|
||||
|
||||
### 2.10 Академические источники по QR-посещаемости и ЭЖ вуза
|
||||
- **Nuhi A., Memeti A., Imeri F., Çiço B.** «Smart Attendance System using QR Code» // 2020 9th Mediterranean Conference on Embedded Computing (MECO), Budva, Montenegro, 2020, pp. 1–4. **DOI: 10.1109/MECO49872.2020.9134225** (IEEE Xplore). — прямое обоснование QR-подхода для учёта посещаемости в вузе.
|
||||
- **Глуховский К.С., Пирожков Р.В., Цвелик Е.А.** «Электронный журнал как элемент цифровой трансформации вуза» // Инженерный вестник Дона. 2021. №5 (URL ivdon.ru, ст. 6978; зеркало CyberLeninka). — отраслевой аналог в **ВИТИ НИЯУ МИФИ** (электронный дневник посещаемости/успеваемости как модуль ЭИОС); особо ценен ведомственной релевантностью.
|
||||
- Дополнительно (CyberLeninka, для контекста методов): «Система учёта посещаемости студентов на основе распознавания лиц» (RetinaFace/ResNet); «Методика автоматизации контроля посещаемости очных занятий…» (кафедра ИКТ РХТУ им. Д.И. Менделеева, Google-таблицы + QR-сканер).
|
||||
- Прочие IEEE по теме (для расширения обзора методов): «Class Attendance Recording using QR Code via Smartphone» (DOI 10.1109/...8912099); «Online Attendance Monitoring System Using QR Code (OAMS)».
|
||||
- **Nuhi A., Memeti A., Imeri F., Çiço B.** "Smart Attendance System using QR Code" // 2020 9th Mediterranean Conference on Embedded Computing (MECO), Budva, Montenegro, 2020, pp. 1–4. **DOI: 10.1109/MECO49872.2020.9134225** (IEEE Xplore). — прямое обоснование QR-подхода для учёта посещаемости в вузе.
|
||||
- **Глуховский К.С., Пирожков Р.В., Цвелик Е.А.** "Электронный журнал как элемент цифровой трансформации вуза" // Инженерный вестник Дона. 2021. №5 (URL ivdon.ru, ст. 6978; зеркало CyberLeninka). — отраслевой аналог в **ВИТИ НИЯУ МИФИ** (электронный дневник посещаемости/успеваемости как модуль ЭИОС); особо ценен ведомственной релевантностью.
|
||||
- Дополнительно (CyberLeninka, для контекста методов): "Система учёта посещаемости студентов на основе распознавания лиц" (RetinaFace/ResNet); "Методика автоматизации контроля посещаемости очных занятий…" (кафедра ИКТ РХТУ им. Д.И. Менделеева, Google-таблицы + QR-сканер).
|
||||
- Прочие IEEE по теме (для расширения обзора методов): "Class Attendance Recording using QR Code via Smartphone" (DOI 10.1109/...8912099); "Online Attendance Monitoring System Using QR Code (OAMS)".
|
||||
|
||||
---
|
||||
|
||||
@@ -159,6 +163,6 @@
|
||||
## Caveats
|
||||
- **Небиблиометричность части источников.** Материалы по Hotwire, Tailwind, Sidekiq и Service Objects — преимущественно официальная документация и технические блоги, а не рецензируемые публикации; в УИР их следует помечать как технические/отраслевые источники, а научную аргументацию строить вокруг рецензируемых работ (IEEE, MDPI, ВАК/РИНЦ).
|
||||
- **Противоречивость бенчмарков СУБД.** PostgreSQL уверенно выигрывает на сложных транзакциях и в цитируемом бенчмарке Salunke & Ouda (до ~13× на больших выборках), однако на простых OLTP-SELECT MySQL в ряде независимых тестов опережает PostgreSQL на 20–30%; нельзя утверждать абсолютное превосходство — выбор мотивирован транзакционной целостностью и типами данных.
|
||||
- **Производительность Ruby/Rails** исторически ниже, чем у оптимизированного PHP/Python; обоснование Rails строится на скорости разработки и DX, а не на «сырой» скорости рантайма, — это важно сформулировать честно.
|
||||
- **Неполные библиографические поля** статьи Даньшина (2019): подтверждены автор, название, год; журнал/номер/страницы требуют верификации на первоисточнике. Для статьи Глуховского и др. (2021) журнал «Инженерный вестник Дона» — онлайн-издание, использующее номера статей (ст. 6978), без классической пагинации и DOI.
|
||||
- **Производительность Ruby/Rails** исторически ниже, чем у оптимизированного PHP/Python; обоснование Rails строится на скорости разработки и DX, а не на "сырой" скорости рантайма, — это важно сформулировать честно.
|
||||
- **Неполные библиографические поля** статьи Даньшина (2019): подтверждены автор, название, год; журнал/номер/страницы требуют верификации на первоисточнике. Для статьи Глуховского и др. (2021) журнал "Инженерный вестник Дона" — онлайн-издание, использующее номера статей (ст. 6978), без классической пагинации и DOI.
|
||||
- **Изменчивость функций коммерческих систем.** Привязки тарифов (Teams Premium, Google Education Plus / Teaching and Learning Upgrade) и набор функций периодически меняются — в работе обязательно указывать дату обращения к источнику.
|
||||
Reference in New Issue
Block a user