├── LICENSE └── README.md /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2021 Ivan Shalganov 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | Oh My BackEnd 2 | ============= 3 | 4 | **Что это?** Этот документ содержит список (roadmap) навыков, которые **часто** требуются backend разработчику web-приложений. Документ разделён на этапы (темы). Каждый этап разделён на пункты. Каждый пункт, в документе, подразумевает что: 5 | - бекендер знает что это и какую проблему решает. 6 | - бекендер знает для чего и когда следует применить. 7 | - бекендер знает как с этим работать или знает где подсмотреть. 8 | - при разработке или проектировании бекендер помнит про них и учитывает в приложении. 9 | 10 | Понимание принципа работы каждого пункта будет дополнительным бонусом в понимании всей темы, но это может занять много времени. Изучайте по желанию и необходимости. 11 | 12 | **Как работать с документом?** Этапы и пункты выстроены в рекомендуемом порядке для изучения. Просто следуйте сверху-вниз. 13 | 14 | **Как работать с пунктами документа?** Каждый пункт легко гуглится и имеет страницу в wikipedia. 15 | Ссылки устанавливаются если есть альтернативная документация — более понятная и/или более подробная. Некоторые ссылки могут потребовать наличия VPN. 16 | Ссылка на wikipedia ставятся для уточнения если название статьи неочевидно или можно перепутать статьи. 17 | > Цитатой обозначены пояснения к пункту для чего следует это знать и/или где с этим можно столкнуться. 18 | > Если пояснения нет — то либо не успели сделать, либо там и так ясно. 19 | 20 | **Есть ли разделение по скилам?** Каждый пункт делится на градации junior, middle, middle+ (он же high middle). 21 | Градации используются чтобы помочь выставить приоритеты в различных темах — на то что стоит изучать в первую очередь. 22 | Тут применяется [общепринятая градация](https://vas3k.ru/blog/team/) навыков и зон ответственности, где senior это middle+ с soft-скилами. 23 | В данном документе максимальным уровнем градации будет — middle+, так как этот документ акцентирует внимание на hard-скилах. 24 | 25 | Метка guru ⚡ означает что этот пункт для более глубокого и продвинутого изучения темы (если у Вас есть время). 26 | 27 | **В каком состоянии документ?** Документ еще находится в процессе дополнений и правок. 28 | В идеале каждый пункт должен иметь градацию, иметь пояснение и ссылку на толковое разъяснение на русском языке. 29 | До идеала еще далеко, но начало положено! 30 | 31 | Если хотите что-то изменить (пункт, ссылку, опечатку) — создавайте [issue](https://github.com/bzick/oh-my-backend/issues) или делайте [pr](https://github.com/bzick/oh-my-backend/pulls). 32 | Если хотите обсудить документ — создавайте обсуждение в [discussions](https://github.com/bzick/oh-my-backend/discussions). 33 | 34 | # Содержание 35 | 36 | - [Этап 1. Виртуализация docker](#этап-1-виртуализация-docker) 37 | - [Этап 2. Linux](#этап-2-linux) 38 | - [Этап 3. Общие знания](#этап-3-общие-знания) 39 | - [Этап 4. Сеть](#этап-4-сеть) 40 | - [Этап 5. Базы данных](#этап-5-базы-данных) 41 | - [Этап 6. Протокол HTTP](#этап-6-протокол-http) 42 | - [Этап 7. Безопасность](#этап-7-безопасность) 43 | - [Этап 8. Тут должен быть ваш язык программирования](#этап-8-тут-должен-быть-ваш-язык-программирования) 44 | - [Этап 9. Электронная почта](#этап-9-электронная-почта) 45 | - [Этап 10. Полнотекстовый поиск](#этап-10-полнотекстовый-поиск) 46 | - [Этап 11. Логи и метрики](#этап-11-логи-и-метрики) 47 | - [Этап 12. Проектирование и разработка](#этап-12-проектирование-и-разработка) 48 | 49 | # Этап 1. Виртуализация docker 50 | 51 | Для начала надо поднять виртуальную машину для экспериментов и исследований. В случае чего, виртуальную машину всегда можно пересоздать. 52 | 53 | Есть много систем виртуализации, но docker выделяется среди них. Docker — популярный инструмент для десктопной виртуализации. На боевых серверах к нему прибегают в меньшей степени, так как там более популярен Kubernetes (aka k8s). Docker не единственная система виртуализации, ближайшие аналоги это [Lima](https://github.com/lima-vm/lima), [Podman](https://podman.io/) (нечто среднее между `docker` и `k8s`). 54 | 55 | 1. установить [docker](https://www.docker.com/products/docker-desktop) junior 56 | 1. запустить контейнер с Linux Ubuntu, последней [LTS версией](https://ru.wikipedia.org/wiki/Список_версий_Ubuntu#Выпуски). Запустить bash (консоль) контейнера. junior 57 | 1. установить удобное приложение для управления образами и контейнерами [Kitematic](https://kitematic.com/), [Portainer](https://hub.docker.com/r/portainer/portainer/) и т.д. 58 | Либо сродниться с консольными командами docker. docker-desktop уже имеет [свой dashboard](https://docs.docker.com/desktop/dashboard/) для управления образами и контейнерами. junior 59 | 1. [docker compose](https://docs.docker.com/compose/) для поднятия кластера контейнеров. middle 60 | > Для рабочего приложения, как правило, требуется несколько различных сервисов (база данных, кэшер, http-сервер и т.д.) 61 | > и всё это упаковать в один docker контейнер будет проблемно, просто из-за специфики работы самой виртуализации. 62 | > Тут как раз поможет compose чтобы запустить кучу контейнеров и подружить их между собой. 63 | 64 | # Этап 2. Linux 65 | 66 | Изучить установленный в контейнере — Linux. Linux, де-факто, является серверной ОС для большинства web-приложений. 67 | В этом разделе будет говориться о Linux, хотя (почти) всё так же актуально и для других posix-совместимых систем. Например для [bsd семейства](https://ru.wikipedia.org/wiki/BSD), включая MacOS. Однако, могут быть отличия. 68 | В качестве стартового дистрибутива Linux, обычно, выбирают [Ubuntu](https://ru.wikipedia.org/wiki/Ubuntu), но вы можете взять самый компактный - [Alpine](https://ru.wikipedia.org/wiki/Alpine_Linux), который часто используется в виртуализации. 69 | 70 | 1. Установка пакетов и обновление системы через `apt`/`apt-get` в Ubuntu/Debian и `apk` в Alpine. junior 71 | > В процессе исследований и различных проб придётся много раз ставить, обновлять и переустанавливать множество пакетов Linux. 72 | > Лучше сразу изучить как работают эти команды. Нужны базовые операции: найти, установить, обновить, удалить. 73 | 1. Базовые навыки в `bash` (улучшенный `sh` aka `shell`). junior 74 | > В Linux-подобных системах bash'ем пронизано всё. Вы гарантировано столкнётесь с ним и будут случаи когда надо будет писать bash/shell скрипты. 75 | * Базовый синтаксис bash. middle 76 | > По факту это единственный скриптовый язык который гарантированно будет установлен в системе. 77 | * Управляющие операторы `if`, `for` и `while` 78 | * Логические операторы `;`, `&&`, `||` 79 | * Исполняющие выражения `` `cmd` `` и `$(cmd)` 80 | * Базовые команды для работы с файловой системой `cd`, `ls`, `find`, `cat`, `cp`, `mv`, `mkdir`, `rmdir`, `rm`. junior 81 | * Вызов мануалов через команду `man`. junior 82 | > Через эту команду можно получить справку по любой команде, операции, файлам и даже исходному коду. 83 | * Конвейеры команд через оператор `|` (`cmd1 | cmd2 | cmd3`). junior 84 | > Linux имеет большое количество команд для обработки данных и для решения различных задач которые вам может понадобится объединять через конвейеры. 85 | * Команды обработки данных `cat`, `tail`, `head`, `grep`, `awk`, `sed`. middle 86 | > Этот набор потребуется для сканирования и анализа логов или больших объёмов текстовых данных. 87 | * Команды работы с архивами данных `zcat`, `gzip`, `gunzip`, `tar`, `zgrep`. middle 88 | > Как правило, никто не хранит логи или большие объёмы текстовых данных "как есть", обычно это архив `gz` или `tar.gz` (`tgz`). 89 | * [Консольные редакторы vim, nano.](https://basis.gnulinux.pro/ru/latest/basis/10/10._Текстовые_редакторы_nano_и_vi.html) Открыть файл, внести изменения, сохранить. junior 90 | > Редактирование файла из консоли не такая редкость. Кстати, чтобы выйти из vim: esc, напечатайте `:q!`, enter. 91 | * Консольные просмотрщики `less`, `zless`. Открыть, найти слово, закрыть. junior 92 | > Редакторы избыточны, чтобы просто посмотреть содержимое файла. Просмотрщики так же справляются с не "стандартными" для редакторов файлами. 93 | * Консольный файловый менеджер `mc`. junior 94 | > Консольные файловые менеджеры, наподобие [Midnight Commander](https://midnight-commander.org), предоставляют UI, который делает более удобной и наглядной работу с типовыми файловыми операциями. 95 | * Фоновые задачи, оператор `&`, команды `jobs`, `fg`, `bg`. middle 96 | > Оператор позволит в одной shell-сессии запускать несколько команд. 97 | * Команда игнорирования сигналов прерываний `nohup`. middle 98 | > Команда позволит, при завершении shell-сессии, оставлять в живых запущенные фоновые задачи до их логического завершения. 99 | * [Потоки, перенаправление потоков](http://gitlab.com/doatta/gnu-linux-rhcsa/-/blob/master/11.%20Стандартные%20потоки.md), операторы `>`, `>>`, `<`. junior 100 | > Куда писать вывод, а куда ошибки, помогут указать эти операции. 101 | * [Упороться полностью консолью](https://github.com/jlevy/the-art-of-command-line/blob/master/README-ru.md) guru ⚡ 102 | 1. Понятие `процесс`. junior 103 | > Как и во всех других ОС, в Linux запущенные приложения представляются процессами. 104 | * Команды анализа процессов `top`, `htop`, `ps` (`ps aux`). junior 105 | > Этакий "диспетчер задач" в мире Linux, позволяющий мониторить процессы системы. 106 | * Родительский процесс, дочерний процесс. middle 107 | > Процессы не появляются из ниоткуда, их что-то запускает. Понимание иерархии процессов облегчит работу с ними и сделает проще понимание мультипроцессовых приложений. 108 | * Мастер-воркер процессы, демон (daemon). middle 109 | > Это один из распространённых видов распараллеливания вычислений в приложениях. Много программ используют именно такой подход распараллеливания. 110 | * Зомби-процессы. Откуда берутся и как с ними бороться. middle+ 111 | > Это вид проблемы распараллеливания вычислений через дочерние процессы. Возникает когда у мастер-процесса есть проблемы или баги. 112 | * [Отправка сигналов процессам](https://ru.wikipedia.org/wiki/Сигнал_(Unix)). junior 113 | > Это основной рычаг воздействия на процессы сторонними приложениями (системными или вашими). 114 | * Изучение команд `kill`, `pkill`, `killall`. junior 115 | * Назначение сигналов [SIGKILL](https://ru.wikipedia.org/wiki/SIGKILL), [SIGTERM](https://ru.wikipedia.org/wiki/SIGTERM), [SIGINT](https://ru.wikipedia.org/wiki/SIGINT), [SIGHUP](https://ru.wikipedia.org/wiki/SIGHUP), [SIGSEGV](https://ru.wikipedia.org/wiki/SIGSEGV). middle 116 | * Системный вызов (syscall). middle+ 117 | > Системный вызов (вызов API ядра Linux) — не бесплатная операция и лучше их держать под контролем на высоконагруженных приложениях. 118 | * Команда анализа системных вызов процесса через `strace`. middle+ 119 | > Самый простой и доступный способ посмотреть какие системные вызовы делает процесс в реальном времени. 120 | 1. Изучение понятия `дескриптор`. middle 121 | > Любой поток данных (входящий и/или исходящий) представляется в виде дескрипторов. Что-либо читать или писать будете (вероятней всего) через дескриптор. 122 | * Стандартные дескрипторы `STDIN`, `STDOUT`, `STDERR` и их нумерация. middle 123 | > Любой поток в процессе пронумерован и есть "зарезервированные" номера под определенные потоки. 124 | * Потоки, сокеты и unix-сокеты. middle 125 | > Это всё разновидности дескрипторов с которыми придётся работать. На всех них распространяются правила дескрипторов, ну так как они и есть дескрипторы. 126 | * Ограничение на дескрипторы. middle+ 127 | > Не редкая проблема приложений когда оно упирается в лимит открытых дескрипторов. 128 | * Команда анализа открытых дескрипторов у процесса через `lsof`. middle+ 129 | > Для отладки приложения всегда надо знать с чем ведёт общение приложение (отлично работает в паре с `strace`, сопоставляя номера дескрипторов). 130 | 1. [Пользователи](https://gitlab.com/doatta/gnu-linux-rhcsa/-/blob/master/19.%20Пользователи.md) junior 131 | * Пользователь `root`. junior 132 | > По сути это админ системы. Избегайте использование root (даже в контейнерах) так как доступ к root даёт доступ ко всей системе, о чем мечтают все зловреды. 133 | * Супер пользователь, команды [su](https://gitlab.com/doatta/gnu-linux-rhcsa/-/blob/master/17.%20su.md) и [sudo](https://gitlab.com/doatta/gnu-linux-rhcsa/-/blob/master/18.%20sudo.md). junior 134 | > Никто не даст вам root на проде, но вполне можете иметь "привилегированного" пользователя, который умеет в `sudo`. 135 | 1. [Файловая система](https://gitlab.com/doatta/gnu-linux-rhcsa/-/blob/master/04.%20%D0%9E%20%D1%84%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2%D1%8B%D1%85%20%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0%D1%85.md) junior 136 | * Команда `stat` junior 137 | * [Права и доступы файловой системы](https://gitlab.com/doatta/gnu-linux-rhcsa/-/blob/master/20.%20Права%20на%20файлы.md) junior 138 | > Избыточные доступы ведут к дыре в безопасности, недостаток доступов ведёт к багам в приложении. Осмысленно ставьте где `x` (особенно у директорий), где `r`, а где `w`. 139 | * Понимание описания доступов вида `--xr-xrwx` и `0137` (восьмеричная) у файлов и директорий. junior 140 | > Обычно в таком виде вы будете видеть уровни доступов в консолях. 141 | * Исполняемые файлы, [sha bang](https://ru.wikipedia.org/wiki/Шебанг_(Unix)). junior 142 | * Изменение прав доступов через команды `chmod`, `chown`. middle 143 | * [Работа с дисками](https://gitlab.com/doatta/gnu-linux-rhcsa/-/blob/master/22.%20Работа%20с%20дисками.md) middle+ 144 | > Нужно знать где, как и куда примонтированы различные диски или носители. Бывает, что приложение может работать сразу с несколькими дисками, некоторые могут быть сетевыми. 145 | 1. Ссылки на файловой системе. junior 146 | * Symlink (aka символическая ссылка). junior 147 | > Самый распространённый вид ссылки. Повсеместно используется в Linux да и пакетных менеджерах разных языков. Вы тоже будете это использовать. 148 | * Hardlink (aka жесткая ссылка). middle 149 | > Редкий случай использования ссылки. Потребуется если надо "дедуплицировать" большой объём файлов. 150 | > По сути позволяет создать несколько имён одному файлу. 151 | 1. Запуск и остановка сервисов systemd. middle 152 | > Linux по сути просто пачка запущенных приложений как сервисов. 153 | 1. [SSH](https://ru.wikipedia.org/wiki/SSH). junior 154 | > Самый доступный способ запустить `shell` на удалённой машине это использовать SSH. Используется повсеместно. 155 | * Генерация собственного ssh-rsa ключа через `ssh-keygen`. junior 156 | > Без него вы не попадёте на хосты по SSH. 157 | * Использование публичного ssh-rsa ключа для входа на удалённую машину (используйте второй контейнер с Linux). junior 158 | 1. Перенос контента. junior 159 | > Появляется потребность перекинуть логи, дамп базы и другие файлы между машинами или к себе. 160 | * `scp` junior 161 | > самый простой инструмент переноса файлов между хостами по ssh. 162 | * `rsync` middle 163 | > пожалуй самый мощный инструмент переноса файлов между хостами с кучами настроек, правил и протоколов. 164 | * `rclone` middle 165 | > "rsync" для облачных хранилищ. Универсальный инструмент для работы с контентом, который хранится в облаках или где-то по сети. 166 | 1. Планировщики задач 167 | * Команда `crontab` и запуск `crond`. 168 | > Самый распространённый и простой планировщик задач, с весьма гибкими настройками расписания 169 | * Команда `at` middle 170 | > Когда хотите запустить задачу разово, к определенному времени. 171 | > В crontab это потребует отдельно создавать расписание, что сильно затрудняет автоматику и захламляет всё расписание. 172 | 1. Оперативная память. middle 173 | * Команда `free`, мета информация `/proc/meminfo`. middle 174 | > Всегда оценивайте сколько памяти потребуется приложению или скриптам, чтобы не быть убитыми системой. 175 | * Ошибка `Out Of Memory` (OOM) и причина появления. [OOM-киллер](https://habr.com/ru/company/southbridge/blog/464245/). middle+ 176 | > Именно это происходит когда вы превысили все допустимые пределы потребления памяти в системе. 177 | 1. [Логи системы](https://habr.com/ru/post/332502/). Для чего и как посмотреть. middle 178 | > Когда случаются проблемы то логи — единственное, что может навести на суть проблемы. 179 | > Помимо логов приложения стоит заглядывать в логи системы, иногда её проблема может вести к проблеме в приложениях. Стоит выделить некоторые логи: 180 | * `dmesg` (driver messages) — важные сообщения от компонентов Linux, включая от OOM-киллера. middle 181 | * `syslog` — системный журнал. middle 182 | > Там могут быть сообщения от ядра Linux, различных служб, сетевых интерфейсов и многого другого. 183 | 1. Проблемы в Linux и последствия. junior 184 | > Их много, но выделим только несколько. 185 | * Kernel panic. junior 186 | > BSoD аналог для Linux. Самая не приятная ошибка системы, явно намекающая, что система не стабильна. 187 | * Segmentation fault (aka segfault aka сегфолт). middle 188 | > Не такая уж и редкая ошибка приложений, как хотелось бы. Приложение попыталось работать с памятью доступа к которой у неё нет. 189 | * Core dump (aka корка). middle+ 190 | > Результат обработки segmentation fault системой. Корка может потребоваться разработчику упавшего приложения для анализа состояния программы на момент падения. 191 | 192 | # Этап 3. Общие знания 193 | 194 | Некоторые пункты сложно категоризировать в этом документе. Но без них не обойтись. 195 | Это базовые вещи которые используются повсеместно в коде, в системах, "под капотом" вашего языка программирования. 196 | 197 | 1. Регулярные выражения. Поиграться регулярными выражениями можно [тут](https://regex101.com/). Хоть каждый язык может иметь своё видение регулярных выражений, в общем смысле (и синтаксисе) они похожи. middle 198 | > Рано или поздно придётся спарсить данные из текста или проверять данные, вот тут как раз и потребуются регулярные выражения. 199 | 1. Криптография. junior 200 | > Не пугайтесь. Пункт подразумевает прикладное применение криптографических функций (для чего нужны те или иные функции), а не изучении самой криптографии. 201 | * Хеши и хеш-функции, в том числе `crc32`, `md5`, `sha1`, `sha256`. junior 202 | * Цифровые подписи. junior 203 | > Чтобы обезопасить от подделки данных используются цифровые подписи этих же данных. 204 | * Соль для подписей. middle 205 | > В теории (да и на практике) хеш-функцию можно определить и чтобы сильнее обезопасить от "взлома" вашего хеша, используя так называемую соль. 206 | * Коллизии хешей. middle 207 | > Хеш-функции могут на разных данных вернуть один и тот же результат (хеш), что может привести к проблемам и багам. 208 | > Лучше знать какова вероятность коллизий у хеш-функции и как их избегать. 209 | * Симметричное и асимметричное шифрование. middle+ 210 | > Иногда приходится шифровать данные и важно выбрать стратегию шифрования. 211 | * [Принцип работы TLS](https://habr.com/ru/post/188042/). middle+ 212 | > Имеется ввиду как работаю CA корневые и промежуточные, что стоит за сертификатом. 213 | 1. [Базовая работа с `git`](https://www.youtube.com/watch?v=zZBiln_2FhM). junior 214 | > По факту это дефолтная система контроля версий в мире IT. 215 | * Коммит изменений (commit) junior 216 | * Отправка изменений (push/pull) junior 217 | * Создание веток и тегов (branch/tag) junior 218 | * Слияние веток (merge) junior 219 | * [Упороться полностью git'ом](https://git-scm.com/book/ru/v2) guru ⚡ 220 | 1. Структуры данных. junior 221 | * Хеш таблицы. middle 222 | > Таблицы часто используются в самих языках программирования (ассоциативные массивы, объекты и т.п.) 223 | * Очередь и стек. junior 224 | > Самые простые структуры данных, которые часто придётся использовать повседневно в коде. 225 | * [Связный список](https://ru.wikipedia.org/wiki/Связный_список) и [двусвязный список](https://ru.wikipedia.org/wiki/Связный_список#Двусвязный_список_(двунаправленный_связный_список)). middle 226 | > Эти структуры данных часто используются в разработке так как являются самым простым способом связать элементы с собой. 227 | > Они так же активно используются внутри вашего языка (под "капотом") повсеместно. 228 | 1. Форматы хранения и передачи данных 229 | * Текстовые. junior 230 | > Текстовые форматы используются так же для хранения конфигурации приложений 231 | * JSON 232 | * YAML 233 | * XML 234 | * Бинарные. middle 235 | > Бинарные форматы используются сугубо для хранения и передачи данных. 236 | * MessagePack 237 | * BSON (бинарный аналог JSON) 238 | * ProtoBuf 239 | 240 | # Этап 4. Сеть 241 | 242 | Сеть в разработке самая важная и, часто, мало заметная часть. 243 | 244 | 1. Базовое понимание работы сети. junior 245 | * Протокол TCP middle 246 | > Вы вряд ли будете читать пакеты TCP. Но полезно знать КАК работает TCP, 247 | > это позволит понять почему при идеальных "интернетах" всё равно приложение может лагать по сети. 248 | * TCP пакет guru ⚡ 249 | > Вряд ли придётся работать с пакетом TCP напрямую, однако из его структуры можно подчерпнуть некоторую полезную информацию по протоколу TCP в целом. 250 | * Флаги ACK, SYN, FIN и прочие middle+ 251 | > Флаги отвечают за организацию, подтверждение передачи и закрытие TCP коннектов. 252 | * Буферы (window size) middle 253 | * [Проблемы TCP](https://www.youtube.com/watch?v=aXYJlizk3CQ) middle+ 254 | > TCP очень старый протокол, который уже не удовлетворяет современным реалиям. 255 | * Протокол UDP. middle 256 | > Самый простой сетевой протокол семейства. Требуется понимание его работы. 257 | > HTTP/3.0, DNS работает на протоколе UDP, и понимание UDP даст немного понимания в работе HTTP/3.0 258 | * UDP-пакет guru ⚡ 259 | > Изучить придётся только если потребуется создать свой протокол передачи данных взамен изжившего себя TCP. 260 | 1. Проблемы сети. junior 261 | > Их, как всегда, много. Но стоит выделить те, которые явно влияют на скорость работы сети. 262 | > По большей части эти проблемы присущи TCP, но могут появиться и там где эмулируют TCP — на другом протоколе (например UDP) 263 | * Packet loss junior 264 | * Reordering middle 265 | * Jitter middle 266 | * Round-Trip Time (RTT aka лаг) junior 267 | * [Сетевое ожидание](https://developer.mozilla.org/ru/docs/Web/Performance/Understanding_latency) (Network latency, задержка) middle 268 | 1. IPv4, IPv6. 269 | > Базовое отличие протоколов надо знать, хотя бы, чтобы правильно создать колонку IP в базе и обработку в коде. 270 | 1. [DNS](https://developer.mozilla.org/ru/docs/Learn/Understanding_domain_names). junior 271 | > Ваш код 24/7 будет работать с доменами так как никто не использует чистый IP для соединения с чем-либо. 272 | > Зная как работает DNS и управление резолвингом домена в системе, можно упростить отладку в некоторых случаях. 273 | * [Как работает резолвинг доменов](https://temoto.github.io/a/kak-rabotayut-domeny.html) junior 274 | * [DNS записи](https://ru.wikipedia.org/wiki/Типы_ресурсных_записей_DNS) middle 275 | * Основные MX, CNAME, NS, A, AAAA, TXT middle 276 | * Прочие записи middle+ 277 | * Файл `/etc/hosts` junior 278 | > Самый простой и доступный способ поменять IP любому домену, локально, конечно же. 279 | * Файл `/etc/resolv.conf` middle+ 280 | > Конфигурация для системы, как и где надо резолвить домены. 281 | * Консольные команды работы с доменами: `whois`, `dig`, `host`. junior 282 | > Чтобы идентифицировать проблему с доменом нужно научиться работать с этими командами. 283 | > Анализируйте домены как через дефолтный для себя DNS так и через публичные, такие как `1.1.1.1` или `8.8.8.8`. 284 | 1. Трассировки маршрутов. middle 285 | 1. Анализ трафика через `tcpdump` + `wireshark` guru ⚡ 286 | > Не простой, но очень эффективный способ "увидеть" и проанализировать трафик в удобном UI. 287 | 1. [Упороться сетью полностью 🇺🇸](https://hpbn.co/) guru ⚡ 288 | 289 | # Этап 5. Базы данных 290 | 291 | Без баз данных — никуда. Самый частый вид баз данных — реляционные базы данных. 292 | Поэтому даже junior должен уметь работать с ними, 293 | а вот с NoSQL базами данных можно ознакомиться чуть позже. 294 | 295 | 1. Реляционные базы данных MySQL/Postgres/и т.д. junior 296 | > MySQL подразумевает как MySQL от Oracle, так и различные варианты в виде MariaDB, Percona XTraDB и т.д. 297 | > В общем понимании семейства: MySQL/Postgres/MSSQL/и т.д. имеют схожие SQL API, различаются только внутренней реализацией, производительностью и масштабируемостью. 298 | * Базовый синтаксис запросов `SELECT`/`INSERT`/`UPDATE`/`DELETE`. junior 299 | * Создание и модификация таблиц junior 300 | * Типы колонок таблиц их назначение и различие junior 301 | * Целочисленные типы (int) 302 | * Текстовые типы (text) 303 | * Наборы, перечисления (enum) 304 | * Строковые типы (char, varchar) 305 | * Десятичные типы (decimal) 306 | * Числа с плавающей запятой (double) 307 | * прочие 308 | * Создание и применение ALTER запросов. junior 309 | * Анализ выполнения запросов через `EXPLAIN`, понимание результатов `EXPLAIN`. junior 310 | > Самый действенный способ понять почему тормозит запрос. 311 | * Диагностика производительности. 312 | > Всегда будут появляться медленные запросы, и чем их больше, тем медленнее будет работать ваше приложение. 313 | > И как правило у разных баз данных всегда есть аналитика для поиска "узких" мест. 314 | * Ведение логов медленных запросов — slow_log. middle 315 | > Не получится сидеть всё время, мониторя все запросы. Проще настроить агрегацию медленных запросов. 316 | * Чтение аналитики и статистики middle+ 317 | > В MySQL семействе это perfomance_scheme, в postgres это Statistics Collector. 318 | > Поможет в полной мере понять какие запросы плохо работают, где не достаёт индексов, где их в избытке и так далее. 319 | * Индексы junior 320 | > Индексы очень важная часть баз данных. Ваши запросы всегда должны работать "по индексам". 321 | > Запрос без индекса или с "плохим" индексом, на нагруженных проектах, гарантировано может привести к падению приложения. 322 | * Кластерный индекс middle 323 | > Это не относится к вычислительным кластерам. Это индекс данных, по нему и укладываются строки в таблице. 324 | * PRIMARY индекс (aka первичный индекс) junior 325 | > Индекс, уникально идентифицирующий каждую строчку в таблице. Как правило, PRIMARY индекс и есть кластерный индекс. 326 | * UNIQUE/обычные индексы junior 327 | * Составные индексы. junior 328 | > Условия и/или сортировки редко когда бывают по одному полю, обычно их больше. Вот тут на сцену выходят составные индексы. 329 | > Тут надо понимать что в составном индексе, последовательность полей важна. 330 | * Понимание какие поля в какой последовательности добавлять в индекс при фильтрации и/или сортировке. middle 331 | * Понимание как строятся деревья индексов у составных индексов. middle+ 332 | * [Понимание работы индексов](https://highload.today/indeksy-v-mysql/) middle 333 | * Алгоритм построения индексов `BTREE`. guru ⚡ 334 | > Это понимание не сделает ваши запросы быстрее, но даст понятие как ведут себя те или иные данные в индексах. 335 | * Объединение таблиц `LEFT JOIN`, `RIGHT JOIN`, `INNER JOIN`, `OUTER JOIN`, `JOIN`. junior 336 | > Данные всегда "размазаны" по таблицам. Чтобы их собрать потребуются эти операторы. 337 | * Группировка данных через `GROUP BY`. junior 338 | > Группировка данных — не редкие запросы, как правило, используются для сбора статистики. 339 | * Фильтрация после группировки. junior 340 | * Функции работы с группами MAX/MIN/AVG/и т.д. junior 341 | * Понимание и назначение внешних ключей (`foreign key`) middle 342 | > Нередко используют внешние ключи для поддержания консистентности данных в базе. 343 | * Транзакции. middle 344 | > Чтобы провести несколько операций атомарно (как одну операцию) используются транзакции. 345 | * Уровни изоляций транзакций. middle 346 | * Deadlock и как его не допускать. middle+ 347 | * Триггеры на `INSERT`/`UPDATE`/`DELETE`. middle 348 | > Не стоит активно использовать триггеры. 349 | > Тем не менее они могут оказаться полезными в некоторых отладочных или maintenance случаях. 350 | * Хранение деревьев. junior 351 | > Не просто сохранить древовидную структуру в реляционной базе. Есть насколько алгоритмов со своими плюсами и минусами. 352 | > На самом деле актуально и для других видов баз данных 353 | * Алгоритм parent-child junior 354 | > Классический вариант "с parent_id" у дочерних элементов. Простые и "дешевые" на вставку элементов в деревья. 355 | > Но такие деревья затратные "на сборку". 356 | * Алгоритм [nested sets](https://ru.wikipedia.org/wiki/Вложенное_множество_(модель)) middle 357 | > Алгоритм позволяет достаточно дёшево собирать деревья с различными модификациями и сегментами. 358 | > Но затратные на вставку элементов в деревья. 359 | 1. Документо-ориентированная база данных (часть NoSQL баз данных) — MongoDB. middle 360 | > Среди всех NoSQL самой популярной является MongoDB. 361 | * Типы данных в коллекциях, их назначение и различия. middle 362 | * Анализ выполнения запросов через `explain()`, понимание его результатов. middle 363 | * Понимание работы индексов (аналогично SQL индексам с небольшими отличиями). middle 364 | * Sparse свойство индекса 365 | * Partial свойство индекса 366 | * TTL свойство индекса 367 | * Geospatial индекс 368 | * Text индекс 369 | * Вложенные объекты, массивы. middle 370 | * Агрегации middle+ 371 | * Работа с репликацией. middle+ 372 | * Работа с кластером MongoDb. middle+ 373 | 1. Redis junior 374 | > Универсальный инструмент хранения данных с уклоном в производительность. 375 | > Может быть, как быстрым постоянным хранилищем, так и реактивным кэширующим, временным хранилищем. 376 | * [базовая работа с ключами](https://redis.io/commands#generic) :us: junior 377 | * [работа со списками](https://redis.io/commands#list) :us: junior 378 | * [работа с хешами](https://redis.io/commands#hash) :us: junior 379 | * [работа с набором](https://redis.io/commands#set) :us: junior 380 | * [сортированным набором](https://redis.io/commands#sorted_set) :us: middle 381 | * [Транзакции](https://redis.io/topics/transactions) :us:, но в другом, своём, понимании. 382 | * [Работа с Lua](https://redis.io/commands/eval) :us: middle 383 | > Даёт возможность запустить любой набор команд атомарно, дополнительно снабдив логикой. 384 | 1. Проблемы в базах данных junior 385 | * Deadlock middle 386 | * Переполнение числовых полей (в том числе autoincrement) junior 387 | * Full scan middle 388 | * Split-brain middle+ 389 | 390 | # Этап 6. Протокол HTTP 391 | 392 | Каждый WEB разработчик должен понимать протокол HTTP. 393 | Разработчик который не знает HTTP протокол — это как сапожник без сапог. 394 | Поэтому даже junior должен многое знать про протокол HTTP. 395 | 396 | 1. [Понимание общего формата протокола](https://developer.mozilla.org/ru/docs/Web/HTTP/Overview): где заголовки, а где тело. junior 397 | 1. Сродниться со вкладкой Сеть/Network в инспекторе браузера junior 398 | > В консоли можно наблюдать все HTTP-запросы со страницы и даже делать самим через функцию `fetch`. 399 | 1. [Методы HTTP-запросов.](https://developer.mozilla.org/ru/docs/Web/HTTP/Methods) Их назначение и ограничения. junior 400 | > Каждый метод имеет своё назначение (достаточно перевести названия методов) и, как следствие, имеет свои условности и ограничения. 401 | * Основные [GET](https://developer.mozilla.org/ru/docs/Web/HTTP/Methods/GET), [POST](https://developer.mozilla.org/ru/docs/Web/HTTP/Methods/POST), [HEAD](https://developer.mozilla.org/ru/docs/Web/HTTP/Methods/HEAD) junior 402 | * Дополнительные `PUT`, `DELETE`, `PATCH` middle 403 | > Используются в REST API вместе с основными методами 404 | * Прочие middle+ 405 | > Это уже методы узкой направленности, редко когда придётся с ними напрямую работать. Тем не менее они активно используются приложениями. 406 | 1. [Коды HTTP ответов](https://developer.mozilla.org/ru/docs/Web/HTTP/Status) junior 407 | * Принцип разделения кодов на группы: 100-199, 200-299, 300-399, 400-499, 500-599. junior 408 | > Коды создавались и описывались не в хаотичном порядке. Есть чёткое разделение их "сфер влияния". 409 | > Даже если какой-то сервер придумает свой код ответа, то по группе вы сможете лучше понять причину такого ответа. 410 | * Основные (частые): [200](https://developer.mozilla.org/ru/docs/Web/HTTP/Status/200), 411 | [206](https://developer.mozilla.org/ru/docs/Web/HTTP/Status/206), 412 | [301](https://developer.mozilla.org/ru/docs/Web/HTTP/Status/301), 413 | [302](https://developer.mozilla.org/ru/docs/Web/HTTP/Status/302), 414 | [304](https://developer.mozilla.org/ru/docs/Web/HTTP/Status/304), 415 | [400](https://developer.mozilla.org/ru/docs/Web/HTTP/Status/400), 416 | [401](https://developer.mozilla.org/ru/docs/Web/HTTP/Status/401), 417 | [403](https://developer.mozilla.org/ru/docs/Web/HTTP/Status/403), 418 | [404](https://developer.mozilla.org/ru/docs/Web/HTTP/Status/404), 419 | [500](https://developer.mozilla.org/ru/docs/Web/HTTP/Status/500), 420 | [502](https://developer.mozilla.org/ru/docs/Web/HTTP/Status/502), 421 | [503](https://developer.mozilla.org/ru/docs/Web/HTTP/Status/503), 422 | [504](https://developer.mozilla.org/ru/docs/Web/HTTP/Status/504) junior 423 | > Это наиболее частые коды ответов которые вы гарантировано встретите. 424 | * [Другие](https://developer.mozilla.org/ru/docs/Web/HTTP/Status) middle 425 | 1. [Заголовки HTTP](https://developer.mozilla.org/ru/docs/Web/HTTP/Заголовки) junior 426 | * [MIME тип](https://developer.mozilla.org/ru/docs/Web/HTTP/Basics_of_HTTP/MIME_types) (тип документа) и заголовок типа [Content-Type](https://developer.mozilla.org/ru/docs/Web/HTTP/Заголовки/Content-Type). junior 427 | * Формат передачи `application/x-www-form-urlencoded` junior 428 | * Формат передачи [multipart/form-data](https://ru.wikipedia.org/wiki/Multipart/form-data) middle 429 | * Системные заголовки Host, Content-Length, 430 | [Content-Encoding](https://developer.mozilla.org/ru/docs/Web/HTTP/Headers/Content-Encoding), 431 | [Transfer-Encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding)) junior 432 | * [Кэширование HTTP](https://developer.mozilla.org/ru/docs/Web/HTTP/Кэширование), заголовки управления кэшем: `Cache-Control`, `Expires`, `Vary`, `ETag`, `Last-Modified`. 433 | 1. [Куки](https://developer.mozilla.org/ru/docs/Web/HTTP/%D0%9A%D1%83%D0%BA%D0%B8) junior 434 | > На данный момент это единственный точный способ идентифицировать пользователя. 435 | 1. [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/ru/docs/Web/HTTP/CORS) middle 436 | > Для кросс-доменных XHR/WebSocket запросов надо научиться работать с CORS, иначе запросы не будут работать. 437 | 1. [Content-Security-Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) middle 438 | > Для повышения безопасности можно ограничить и указать что и откуда может загружаться и запускаться на странице. 439 | 1. Различия версий протокола HTTP: HTTP/1.0, HTTP/1.1 middle 440 | > Не смотря на появление новых версий протокола HTTP, версии HTTP/1.0 и HTTP/1.1 всё еще остаются частыми во внутренних сетях кластеров. 441 | 1. Консольные команды HTTP запросов `curl`, `wget` junior 442 | > На серверах (хостах) нет браузеров, чью удобную консоль можно использовать. 443 | > Там есть shell и множество утилит, которые умеют работать с HTTP. 444 | 1. Различия протоколов HTTP/1.1, HTTP/2.0 и HTTP/3.0 middle+ 445 | > Каждый протокол имеет свои возможности и улучшения, которые можно использовать для ускорения приложения. 446 | 1. WebSocket протокол middle 447 | > Это расширения версии HTTP/1.1 и выше для механизма обмена данными по одному соединению. 448 | > Часто используется для чатов и/или для event-driven модели. 449 | 1. WebRTC guru ⚡ 450 | > Если надо будет организовывать P2P (peer-to-peer) чаты или P2P стриминг, то WebRTC как раз для этого. 451 | 1. HTTP API форматы junior 452 | * [REST API](https://ru.wikipedia.org/wiki/REST) junior 453 | * RPC junior 454 | * [GraphQL](https://habr.com/ru/post/326986/) middle 455 | 1. Web сервера junior 456 | * [Nginx](https://nginx.org). junior 457 | > Самый распространённый Web-сервер. Вероятность натолкнуться на него во время разработки web-приложения - высока. 458 | * [Ознакомление с базовыми возможностями](https://nginx.org/ru/docs/beginners_guide.html) junior 459 | * [Масштабируемая конфигурация nginx](https://www.youtube.com/watch?v=jf3wIN-FwW4) middle 460 | * Написание простых локаций в `/etc/nginx/nginx.conf` раздачи файлов junior 461 | * HTTP, FastCGI проксирование junior 462 | * [Apache httpd](https://httpd.apache.org/). junior 463 | > Один из старых, но активно использующихся Web-серверов широкого профиля. 464 | > Хоть он уже и уступает nginx-у в популярности, но столкнуться с ним в проекта есть всё так же легко. 465 | 466 | # Этап 7. Безопасность 467 | 468 | Ваше приложение всегда под угрозой, даже если это какое-то home-page приложение. 469 | Ботнетам всегда не хватает вычислительных ресурсов. Хакерам — данных. А пользователям — мозгов (без обид). 470 | 471 | 1. Виды управления доступом middle 472 | * Access Control List (ACL) middle 473 | * [Role-based access control](https://habr.com/ru/company/custis/blog/248649/) (RBAC) middle 474 | * [Attribute-based access control](https://habr.com/ru/company/custis/blog/248649/) (ABAC) middle 475 | 1. Аутентификация junior 476 | * [Basic](https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication) junior 477 | > Самый простой вид авторизации, не требующий дополнительных вычислительных мощностей (серверов). 478 | * [SSO](https://habr.com/ru/company/nixys/blog/563244/) (Single Sign On) junior 479 | > Общее название подхода к авторизации: авторизация на множестве приложений через одну точку. OAuth и OpenID — частные случаи SSO. 480 | * [OAuth2](https://www.digitalocean.com/community/tutorials/oauth-2-ru) middle 481 | > Распространенный вид авторизации через посредника, который гарантирует что Вы это Вы и может выдать некоторые данные по пользователю, с его согласия. 482 | > Часто сталкиваются c OAuth2 тогда когда надо подключить авторизацию через соц. сети. У них у всех OAuth2 (но каждый со своими модификациями). 483 | * OpenID middle 484 | > Один из первых популярных SSO. Уступает Oauth2 по популярности, но так же где-то используется. 485 | * Ldap middle 486 | > Данный вид авторизации используется, чаще всего, для авторизации во внутренних сервисах своих сотрудников. 487 | * JSON Web Token (JWT) middle 488 | > Это не тип авторизации, а инструмент для передачи идентифицирующих данных. Однако такой токен может иметь очень широкое применение, не только в авторизации. 489 | 1. [Виды атак и уязвимостей](https://docs.wallarm.ru/attacks-vulns-list/) junior 490 | * Фишинг сайта junior 491 | * Небезопасное перенаправление, Open Redirect junior 492 | * Инъекции (например SQL-инъекции) junior 493 | * XSS атака junior 494 | * IDOR уязвимость middle 495 | * CRLF атака junior 496 | * LFI/RFI атака junior 497 | * DoS/DDoS middle 498 | * HTTP-флуд middle 499 | * SYN flood (потребуются знания TCP) middle+ 500 | * UDP flood (UDP амплификация) middle+ 501 | * Медленный запрос middle 502 | * Бомбы middle 503 | * Logic Bomb middle 504 | * Zip Bomb junior 505 | * Атака посредника (Man In The Middle, MITM) middle 506 | * Брутфорс (например брутфорс паролей) junior 507 | * Спуфинг middle 508 | 509 | # Этап 8. Тут должен быть ваш язык программирования 510 | 511 | Языков программирования много. Однако, они имеют много общего между собой, кто-то больше, а кто-то меньше. 512 | Этот этап будет задевать только часто встречающиеся пункты в большинстве популярных языков программирования. 513 | Этап не будет чётко дробиться на градации, так как многое зависит от самого языка, его возможностей и его расширений. 514 | 515 | Принцип работы с этим разделом: ищите `%ваш_язык_программирования% %пункт_из_этапа%`. 516 | Учтите, что **некоторых пунктов может не быть в вашем языке**. 517 | 518 | 1. Что такое интерпретатор, компилятор, JIT, оп-код, байт-код. Что из этого использует ваш язык? junior 519 | 1. Ваш язык программирования junior 520 | * Примитивные типы данных 521 | > Базовые скалярные типы — целые числа, строки, булевы значения, числа с плавающей точкой, null/nil и так далее. 522 | * Функции, макросы. 523 | * Определение и их вызов 524 | > Умение определить простую функцию и вызвать её. Бывают языки где функций без объектов не может быть 525 | * Главная функция или точка входа в программу. 526 | > В языке программа может запускаться только через стартовую функцию, например `main()`. 527 | > Но некоторые языки позволяют запустить файл с кодом. 528 | * Набор, массив, хеш-таблица (ассоциативный массив), кортеж. 529 | > Представляет собой различные комбинации примитивных типов. Например числовой массив данных можно сделать почти в любом языке. 530 | * Объекты/классы/структуры, прототипы/интерфейсы/миксины. 531 | > Все современные языки имеют объекты и умеют ими оперировать. 532 | * Перегрузка операторов 533 | > Позволяет объектам самим определять как над ними производить математические, логические и прочие действия (операции). 534 | * Перегрузка методов 535 | > Позволяет определить несколько методов с одним названием, но с разной сигнатурой. 536 | > Как правило это достигается за счет различного набора параметров (количества или типов принимаемых значений) для каждого метода. 537 | * Generics (aka генерики aka шаблоны aka обобщения) 538 | > Специфичная возможность некоторых языков программирования со строгой типизацией. 539 | > Позволяет определить единую сигнатуру для обработки различных типов. 540 | * Объектно-ориентированное программирование (ООП) 541 | * Ссылки, слабые ссылки. 542 | * Области видимости переменной. 543 | > Важно понимать когда ваши переменные доступны в коде, а где уже/ещё нет. Особенно важно это понимать когда работаете с ссылками. 544 | * Garbage Collector (GC). 545 | > Много языков высокого (и не только) уровня имеют GC. GC отвечает за освобождение памяти от мусора (забытые данные, данные которые уже не нужны коду) 546 | > в процессе работы кода. Это очень важная часть вашего языка, так как пока работает GC — не работает ваш код. 547 | > А если GC будет часто и/или много работать то ваше приложение начнет лагать и "зависать". 548 | * Когда и как запускается GC. 549 | * Изучить настройки GC. 550 | * Включение/выключение GC, принудительный запуск GC. 551 | * Профилирование утечек или потребления памяти. 552 | * Преобразование типов. 553 | * Слабая/сильная типизация в коде. На что влияет и как с этим жить. 554 | > Сильная типизация требует явного указания в коде типа данных, которые будут использоваться в переменной, аргументе и т.д. 555 | > А динамическая, наоборот, позволяет не указывать тип. Вычисление типа значения будет происходить динамически, в момент выполнения программы/программного кода (runtime). 556 | > Некоторые языки могут поддерживать одновременно как строгую так и слабую типизации. 557 | * Битовые операции: `not`, `and`, `or`, `xor`, сдвиг влево, сдвиг вправо junior 558 | > Часто вместо `or` и `and` используются символы `|`/`||` и `&`/`&&`. 559 | > С битовыми операциями можно столкнуться чаще чем кажется, много функций/методов принимают опции в виде битовых флагов вида `READ|WRITE|CREATE`. 560 | > Нужно уметь комбинировать битовые флаги, удалять, определять какие флаги установлены. 561 | * Обработка ошибок. Исключения, паники, error и прочие проявления _ошибок_. 562 | * Проблемы в коде 563 | * Бесконечные циклы 564 | * Рекурсии 565 | * Погрешность в числах с плавающей запятой (float, double, number). 566 | * Ошибка сегментации (и ее связь с сигналом SIGSEGV) 567 | 1. Распараллеливание вычислений middle 568 | > Вычислять в один поток, используя 1 CPU, неимоверно удобно и просто. Однако в этом случае вы ограничены скоростью 1 CPU, что 569 | > может занять много времени. Для ускорения сложных вычислений или действий использоют несколько CPU одной или нескольких машин. 570 | > Но это будет "стоить" не дёшево. 571 | * Процессы 572 | * Создание дочернего процесса через [fork](https://ru.wikipedia.org/wiki/Fork). 573 | * Поведение дескрипторов до и после fork. 574 | * Разделяемая память (Shared memory) 575 | * Межпроцессное взаимодействие (IPC) 576 | * Потоки (threads) 577 | > В отличии от процессов, потоки имеют общую память, как следствие, всегда единую кодовую базу. 578 | * Истинные потоки (pthreads, posix-threads) 579 | * Зелёные потоки (Green threads) 580 | > Ведут себя как истинные потоки, но таковыми не являются, так как только эмулируют распараллеливание. 581 | * КоРутины 582 | > Вариант распараллеливания, когда один код приложения, ожидающий событие системы, уступает CPU другому коду приложения. 583 | > Выполняются-ли они параллельно - зависит от реализации. 584 | * Проблемы распараллеливания 585 | * Race Condition (aka race aka состояние гонки) 586 | > Как только у вас что-то может пойти параллельно у вас сразу же появится вероятность получить проблему RACE. 587 | > На устранение или недопущение RACE всегда расходуются вычислительные ресурсы. И проблему RACE всегда сложно диагностировать. 588 | > Поэтому параллелят вычисления только там где это остро необходимо. 589 | * Deadlock 590 | > Как и в базах данных случается так что два или более параллельных вычисления ждут друг друга. И не дождутся. 591 | * Атомарные операции 592 | > При работе в потоках, для избежания Race, языки реализовывают атомарные операция, позволяющие безопасно менять значения переменным. 593 | * Блокировки 594 | > Чтобы избегать Race нужно использовать блокировки. 595 | * Mutex (aka Мьютекс / aka mutual exclusion) 596 | > По сути это атомарная блокировка. 597 | * Семафоры 598 | > Упрощенный вид mutex 599 | 1. Пакетный менеджер или менеджер зависимостей. junior 600 | 1. Расширения языка 601 | > Высокоуровневые языки, обычно, расширяются модулями, написанными на низкоуровневом языке, на котором написан сам обработчик языка. 602 | 1. Отладчик (aka дебаггер) 603 | > Большую часть времени вы будете не писать новый код, а производить отладку уже написанного кода. 604 | > В некоторых языках отладчик уже "встроен в язык", но некоторые языки требуют дополнительные модули или инструменты для этого. 605 | 1. Запуск сервера и работа c ним в языке (обработка HTTP-запросов). junior 606 | > Некоторые языки в коде запускают сервера, а некоторые имеют отдельный сервер который запускает код. Может быть и то и то. 607 | 1. Кэширование данных middle 608 | * Частые алгоритмы кэша [LRU](https://ru.wikipedia.org/wiki/Алгоритмы_кэширования#Least_recently_used_(Вытеснение_давно_неиспользуемых)), LFU 609 | * [Иные алгоритмы кэширования](https://ru.wikipedia.org/wiki/Алгоритмы_кэширования) guru ⚡ 610 | * Прогревание кэша, инвалидация кэша 611 | 1. Шаблонизация 612 | > Генерировать UI через `print`'ы очень плохая практика из-за множества проблем с поддержкой такого кода, с ростом проекта и контрибуторов. 613 | > В вашем языке должны быть пакеты/модули для шаблонизации. И, как правило, их несколько. 614 | 1. Юнит тестирование junior 615 | > Ознакомление с системой тестирования в вашем языке. Подбор пакета/модуля для тестирования. 616 | 1. Специфика работы IO (сокетов, дескрипторов, потоков) middle 617 | * Буферы IO 618 | * Асинхронный IO 619 | 620 | # Этап 9. Электронная почта 621 | 622 | Работа с email, неотъемлемая часть web-разработки (да и не только). По факту, это единственный гарантированный канал связи с пользователем. 623 | 624 | 1. [Спецификация письма MIME](https://www.opennet.ru/docs/RUS/inet_server/servers_glava2_5.html) junior 625 | * Основные заголовки: `Return-Path`, `Received`, `From`, `To`, `Cc`, `Bcc`, `Reply-To`, `Subject`, `Message-ID` junior 626 | * прочие заголовки middle+ 627 | * указание кодировки junior 628 | * кодирование полей и тела в base64 и qp (quoted-printable) middle 629 | 1. Установка [MailHog](https://github.com/mailhog/MailHog) middle 630 | > Это почтовый сервер для тестирования работы отправки писем приложениями, который можно поднять локально в контейнере. 631 | 632 | # Этап 10. Полнотекстовый поиск 633 | 634 | Каждый разработчик сталкивается с необходимостью полнотекстового поиска, да и в целом быстрого поиска по куче атрибутов и текстов. 635 | Для этого используются различные полнотекстовые поисковые движки такие как [ElasticSearch](https://www.elastic.co/), [SphinxSearch](http://sphinxsearch.com/), [ManticoreSearch](https://manticoresearch.com/), [MeiliSearch](https://www.meilisearch.com/) и т.д. 636 | Самый распространенный полнотекстовый поисковый движок с большим сообществом — ElasticSearch. 637 | 638 | 1. Установить [Cerebro](https://github.com/lmenezes/cerebro) для работы с ElasticSearch. junior 639 | 1. Индексы junior 640 | * Alias middle 641 | * Настройки middle+ 642 | * Шаблоны middle 643 | * Mapping middle 644 | 1. Запросы junior 645 | * Запросы поиска junior 646 | * Запросы добавления/обновления/удаления документов junior 647 | * bulk запросы middle 648 | > Запросы на изменение лучше делать пачкой, так называемым bulk-ом. 649 | * painless-скриптинг middle+ 650 | > потребуется чтобы точечно обновить некоторые поля у документа или вложенные документы, вместо всего документа 651 | 1. Подключение или изменение морфологий junior 652 | 1. Агрегации middle+ 653 | 1. Lucene индексы middle+ 654 | > Основную работу по индексации и поиску выполняют Lucene-индексы. Сам ElasticSearch — кластер с HTTP-сервером, 655 | > гарантирующий сохранность Lucene-индексов и отвечающий за их репликацию и шардирование. 656 | > Если вам нужно чтобы была быстрая индексация и/или быстрый поиск то вам надо тюнить работу Lucene-индексов. 657 | 658 | # Этап 11. Логи и метрики 659 | 660 | Метрики позволят узнать о проблеме, а логи позволят понять причину проблемы. Для крупных и/или распределённых систем этот тандем обязателен. 661 | Для обработки большого объёма данных нужны подходящие системы для сбора, хранения и агрегации. 662 | Любое приложение должно уметь генерировать _полезные_ метрики для системы сбора и анализа метрик. И писать _правильные_ системные логи о _своих_ событиях. 663 | Логи о событиях пользователей уже относятся к аудиту, а не к системным логам. 664 | 665 | 1. Системы хранения и обработки логов 666 | > Их на самом деле много, но среди бесплатных opensource, по популярности выделяются несколько 667 | * Решение [ELK](https://www.elastic.co/what-is/elk-stack) middle+ 668 | > Не самая тривиальная, но эффективная для приёма, обработки, хранения и работы с логами. 669 | > ELK: Logstash - парсит логи, ElasticSearch - хранит логи, Kibana - UI для ElasticSearch для работы с логами. 670 | * [ClickHouse](https://clickhouse.tech/docs/ru/) middle+ 671 | > Колоночная база данных, которая отлично справляется с большим количеством логов (и не только access). Если проводить аналогию с ELK то: 672 | > MaterializedView - позволяет парсить (структурированные) логи, семейство MergeTree — хранит логи. 673 | > А вот UI только сторонний брать, например Grafana или [Kibana](https://www.highload.ru/moscow/2019/abstracts/5906). 674 | * [Grafana Loki](https://grafana.com/oss/loki/) 675 | > База данных для логов на базе Prometheus-like хранилищах с хорошей интеграцией с Grafana. 676 | 1. [Prometheus](https://prometheus.io/) или подобные, например, [Victoria Metrics](https://victoriametrics.com/) middle 677 | > Популярная система сбора и хранения метрик. 678 | * Типы метрик middle 679 | * count 680 | * gauge 681 | * histogram 682 | * summary 683 | * Варианты отправки метрик: push и pull middle 684 | * Запросы (лучше и наглядней делать из Grafana) middle 685 | * [Синтаксис](https://prometheus.io/docs/prometheus/latest/querying/basics/) middle 686 | * Лейблы 687 | * Векторы 688 | * Интервалы 689 | * Операторы 690 | * [Функции](https://prometheus.io/docs/prometheus/latest/querying/functions/), особенно стоит выделить 2 из них: middle 691 | * rate 692 | * irate 693 | 1. Grafana middle+ 694 | > Отличный UI для отображения метрик из разных систем хранения, включая Prometheus-like системы. 695 | * Создание дашбордов 696 | * Создание графиков 697 | * Настройка алертов 698 | 699 | # Этап 12. Проектирование и разработка 700 | 701 | Паттерны, концепции и подходы к проектированию различных web-приложений. 702 | 703 | 1. Принципы разработки junior 704 | * GRASP (General Responsibility Assignment Software Patterns) middle 705 | * [SOLID](https://blog.byndyu.ru/2009/10/solid.html) (Single Responsibility, Open–Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) middle 706 | * KISS (Keep It Simple, Stupid) junior 707 | * YAGNI (You Aren't Gonna Need It) junior 708 | * DRY (Don’t Repeat Yourself) junior 709 | * [IoC](https://habr.com/ru/post/321344/) (Inversion Of Control), и как следствие — DI (Dependency Injection) middle 710 | * DDD (Domain-Driven Design) middle 711 | 1. Архитектурные шаблоны junior 712 | > В одном проекте может быть один или несколько архитектурных шаблонов, или даже половина. Архитектурные шаблоны - подход к решению задачи, которую возложили на проект. 713 | * Гексагональная архитектура middle+ 714 | * [Event-Driven Architecture](https://habr.com/ru/post/346630/) (aka Шаблон посредника или Broker pattern) middle+ 715 | * Onion Architecture (аkа Луковая архитектура или Многоуровневый шаблон) middle+ 716 | * CQRS (The Command and Query Responsibility Segregation) middle+ 717 | * SoA (Service-Oriented Architecture) middle+ 718 | * Event Sourcing middle+ 719 | * Шаблон MVC junior 720 | > Самый старый и достаточно распространённый шаблон проектирования приложения, разделяющий UI от логики приложения. 721 | * [Шаблон ADR](https://habr.com/ru/post/260769/) (Action-Domain-Responder) 722 | > Доработка MVC под задачи веба 723 | * Шаблон MVP junior 724 | > MVP - итерация развития MVC из-за усложнений приложений и UI. Часто используется во front-end - в браузере. 725 | * Шаблон [MVVM](https://habr.com/ru/company/mobileup/blog/313538/) 726 | > На самом деле этот шаблон подходит для десктопных или мобильных приложений. В web приложениях практически не используется. 727 | 1. [Шаблоны проектирования](https://refactoring.guru/ru/design-patterns/examples) 728 | > Шаблоны упрощают разработку, так как это, по сути, опыт сообщества по решению тех или иных проблем. 729 | > Главное не забывайте про KISS и YAGNI, чтобы не упасть в ад абстракций и пучину сложности. 730 | * Порождающие шаблоны проектирования 731 | * Структурные шаблоны проектирования 732 | * Поведенческие шаблоны проектирования 733 | 1. Методологии разработки 734 | > Это не про scrum, agile, waterfall, планирование, проектирование и прочее. Это про методологии написания кода. 735 | * [TDD](https://habr.com/ru/company/ruvds/blog/450316/) (Test Driven Development) 736 | > Разработка через тестирование, самый известный способ разработки, требующий от разработчика сначала - написание теста к коду, а потом самого кода. 737 | * BDD (Behavior Driven Development) 738 | > Расширенная версия TDD, тем что сперва пишется не тест, а описание что нужно сделать, на предметном языке, например Gherken. 739 | 1. [Типы приложения](https://dou.ua/forums/topic/31720/) 740 | > Существует разделение приложения по способу генерации UI. 741 | * MPA (Multi-Page Application) 742 | > Классический тип приложения, с несколькими страницами генерируемыми на back-end для создания UI. 743 | * SPA (Single Page Application) 744 | > Общее название типа приложения когда приложение живёт в браузере и ходит за данными на сервер. Может быть как SSG, SSR, CSR или любое их сочетание. 745 | * SSG (Static Site Generation) 746 | > Все страницы приложения заранее генерируются в статичные файлы. Динамика полностью на JS. Может быть как и MPA так и SPA. 747 | * SSR (Server Side Rendering) 748 | > Подход к генерации страниц приложения. Каждый запрос обрабатывается на сервере, где генерируется UI, а после сервер возвращает ответ клиенту на front-end. 749 | * CSR (Client Side Rendering) 750 | > Подход к генерации страниц приложения. Весь UI генерируется в браузере при помощи JS. JS делает запросы на сервера за данными, для построения или изменения UI. 751 | > SPA — частный случай CSR. 752 | * PWA (Progressive Web Application) 753 | > Буквально ваш сайт в виде мобильного приложения. 754 | 1. Тестирование. junior 755 | * Unit тестирование junior 756 | > Тестирование отдельных (в том числе отдельных друг от друга) частей продукта, обычно отдельных функций/методов. 757 | > Unit-тесты так же несут ещё одну цель - проверка архитектуры вашей реализации. 758 | > Как правило, если у вас не получается написать unit-тест на функцию/метод, не вовлекая сторонние компоненты приложения 759 | > то возможно стоит пересмотреть архитектуру. Хорошее Unit-тестирование ведёт к хорошей инверсии контроля (IoC, см. выше) 760 | * Интеграционные тесты middle 761 | > Сложный вид тестов. Проверка работоспособности приложения, модуля, компонентом с другим приложением, модулем, компонентом. 762 | * End-to-End (aka E2E aka Сквозное тестирование) middle 763 | > Пример E2E теста - тестирование готового API приложения. Тестируются не компоненты приложения, а готовая функциональность. 764 | * Smoke test (aka дымовые тесты) middle 765 | > Дымовые тесты позволяют протестировать саму возможность работать вашему приложению. 766 | > Иногда используют для тестирования инфраструктуры на возможность работать в ней вашему приложению. 767 | 1. Проблемы приложений и проектирования. junior 768 | * Технический долг. junior 769 | > Тех.долг начнёт копиться в проекте с первых строк кода. Всегда стоит его учитывать в разработке и планировать его устранение. 770 | * Over engineering junior 771 | > Когда реализация намного больше или сложнее чем требуется. Потребует кучу ресурсов на поддержку проекта. 772 | * Преждевременная оптимизация (aka Premature Optimization) junior 773 | > Прибегание к оптимизации там где она не требуется на данный момент. Отнимет кучу ресурсов на этапе разработки проекта. 774 | 1. [Приёмы рефакторинга](https://refactoring.guru/ru/refactoring/techniques) 775 | > Чтобы избавляться от тех.долга придётся часто и много рефакторить. 776 | 1. [Антипаттерны](https://ru.wikipedia.org/wiki/Антипаттерн) 777 | > Полезно знать как следует делать, но не менее полезно знать как НЕ следует делать. 778 | 1. [Semver](https://semver.org/lang/ru/) 779 | > Самый распространённый принцип наименования версий приложения. В некоторых языках и пакетных менеджерах является обязательным к соблюдению. 780 | 1. Распределенные системы 781 | > Когда приложение упирается в потолок сервера то у вас только один выход - заставить приложение работать на нескольких серверах. 782 | > Это сильно усложняет приложение и много ресурсов уходит на сохранение целостности и согласованности данных. 783 | * [Теоремы CAP и PACELC](https://habr.com/ru/company/gaz-is/blog/551986/) 784 | > В распределённых системах придётся чем-то жертвовать. PACELC - расширенная теорема CAP. 785 | > Эти теоремы как раз описывают какими параметрами придётся пожертвовать системе. 786 | * [Микросервисная архитектура](https://habr.com/ru/company/dataart/blog/280083/) 787 | --------------------------------------------------------------------------------