Программисты — удалённая работа в Москве

Веб-разработка. Разработка с нуля, доработка существующего продукта, настройка, тестирование. В нашу команду ищем опытного разработчика с хорошими знаниями в современном стеке и умением разбираться в чужом коде. Нам важна инициативность, самостоятельность и глубокое понимание технологий. Что нужно знать и уметь: Отличное знание Directus Умение читать и разбираться в чужом коде Уверенные знания JavaScript (ES7+) и TypeScript Опыт работы с Node.js (Express.js) Хорошее владение SQL, понимание ORM, реляционных баз данных Опыт фронтенд-разработки: React + Next.js Умение работать с TailwindCSS Знание принципов ООП Навыки Linux-администрирования, установка и настройка Nginx Опыт работы с Docker и Docker Compose Уверенное владение Git. _______________________________________ Выплаты: два раза в месяц Трудоустройство по договору с самозанятым. Опыт работы: 2–3 года _______________________________________ Условия: График работы: полный рабочий день, 5/2 Образование не обязательно — важны знания и опыт Стажировка: 1 неделя Уровень заработной платы — по результатам собеседования Если ты хочешь работать с современными технологиями, не боишься сложных задач и готов развиваться вместе с проектом — присылай резюме!.

Программирование микроконтроллеров. Микроконтроллер: по рекомендации специалиста. Функции и задача устройства: Описано в описании задачи. Нужна система автоматизации для закрытого грунта на базе ардуино. туда входят датчики уровня воды, температуры, влажности, кислотности, привод окна, мембраный насос, уф подсветка. все должно работать как единая система как с вай фай так и через радиосвязь, а также чтобы была возможности управлять как дистанционно, так и вручную (интеграция с приложением Gros.Farm). я в этом смыслю мало, буду рада консультации.

Настроить: обмен данными, доступ пользователей. Конфигурация: 1С: УНФ. Версия платформы: 8.3. Задача: Обслуживание 1с унф в сети продуктовых магазинов: проверка связи с оборудование, устранение неполадок, сбоев, установка драйверов и тд.

Финансовые расчёты, оптимизация закупок, управления запасами. Финансовые расчёты: Таблица для соцконтркта. Техническое задание есть. Пожелания и особенности: Поменять данные в таблице по соцконтркту.

Взять готовую LLM модель, дообучить на дата сете (соберу сам по вашему ТЗ), задеплоить с предоставлением API. Нужно научить ее генерить художественный текст в 1000 слов со стримингом токинов.

Задачи чат-бота: финансовые операции, ответы на типовые вопросы, интерактивное меню или каталог, сбор информации, информирование клиентов. Продукт: стандартный магазинный бот: юзеры, продукты, магазины, задания, ответы, баллы. Техзадание есть. Техническое задание: Инфраструктура для Telegram-бота 🎯 Цель проекта Разработка отказоустойчивой, масштабируемой и сопровождаемой инфраструктуры для Telegram-бота. Требуется продумать и реализовать архитектуру, которая поддерживает: * высокую нагрузку (в перспективе — десятки тысяч пользователей); * масштабирование на несколько нод/серверов; * балансировку нагрузки; * автоматическое обновление кода и схемы базы данных. Также при разработке архитектуры важно учесть, что бот активно выполняет сложные SQL-запросы с JOIN-ами, фильтрацией, агрегацией, вставкой и обновлением данных. Необходимо обеспечить возможность горизонтального масштабирования — запуск нескольких копий бота на разных серверах с общей базой данных. Инфраструктура должна быть развернута в одном из российских облачных провайдеров (VK Cloud, Selectel, Timeweb Cloud или аналог), на виртуальных Linux-серверах. Выбор конкретного провайдера остаётся за исполнителем, однако при прочих равных предпочтение должно отдаваться наиболее бюджетному решению. Требуется настроить репликацию базы данных, балансировку нагрузки, кеширование запросов, а также автоматическое обновление кода и схемы базы при пуше в основную ветку репозитория (CI/CD). Все решения должны быть реализованы на бесплатных и открытых технологиях. Использование Kubernetes не предполагается, так как считается избыточным и затратным для задач данного масштаба. Однако, если исполнитель сможет обосновать, что применение Kubernetes или его минимального окружения даст более простое, устойчивое и экономичное решение — такой вариант может быть рассмотрен. ------------------------------------------------------------------------------------------------------------------ 🧰 Что есть на входе На текущем этапе исходный код Telegram-бота отсутствует — мы ожидаем, что разработчик самостоятельно реализует тестового mock-бота на Python, эмулирующего активную работу с базой данных (любая Open Source СУБД, поддерживающая SQL-запросы — PostgreSQL, ClickHouse и др., на ваш выбор, но с архитектурным обоснованием её необходимости), в частности с большим количеством джойнов (для демонстации достаточно и 3+ таблиц) Основные характеристики этого бота: * интенсивное взаимодействие с базой: частые JOIN, INSERT, UPDATE, DELETE; * сложные SQL-запросы с агрегациями, фильтрацией, группировками; * обновление, вставка, удаление и прочие манипуляции с данными в базе — как можно быстрее, но в пределах 30 минут (NRT допустимо); * база должна быть реплицируемой и поддерживать масштабирование; * выполнение сложных запросов — максимально эффективно (под нагрузкой); * всё взаимодействие с БД должно быть асинхронным (если это возможно на выбранной технологии); * требуется полноценная поддержка Flyway для управления схемой базы: создание базы, таблиц, миграции, обновления. * бот необходим для взаимодействия пользователей с магазинами и товарами. Предполагаем наличие следующих таблиц: юзеры, логи юзеров, магазины, товары, свойства товаров, покупки юзеров, баллы юзеров, задания, типы заданий, ответы юзеров Ожидается, что инфраструктура будет построена в соответствии с остальными требованиями ТЗ: масштабирование, отказоустойчивость, CI/CD, безопасность и документация (подробнее ниже) ------------------------------------------------------------------------------------------------------------------ ✅ Что ожидается от кандидата - Опыт настройки PostgreSQL/GreenPlum/ClickHouse с репликацией и масштабированием; - Опыт настройки CI/CD; - Знание Python, PgBouncer, HAProxy, Docker, K8s, Redis; - Умение документировать шаги; - Готовность работать с mock-кодом без доступа к реальному проекту; - Умение читать SQL и понимать async-запросы; - Ответственность, самостоятельность, надёжность. - Открытость к обсуждениям, своевременная обратная связь и прозрачное информирование заказчика о ходе работ. 🛠 Что требуется 1. Реализация Mock-ового телеграм бота - написание на python + python-telegram-bot 2. Масштабирование - Развернуть PostgreSQL (или расширение: Citus, Patroni и пр.); - Настроить репликацию (streaming, logical и т.п.); - Обеспечить горизонтальное масштабирование (возможность запуска бота на нескольких нодах); - Обеспечить совместимость с Flyway-механизмом миграций (добавление новых миграций должно применяться поверх старых); - Исполнитель предоставляет обоснование выбранного решения для масштабирования PostgreSQL, раскрывая причины выбора конкретного инструмента или расширения, а также преимущества этого подхода с точки зрения отказоустойчивости, производительности, стоимости и удобства поддержки по сравнению с альтернативами. - В случае убедительного обоснования исполнитель может предложить использование альтернативных технологий (например, GreenPlum, ClickHouse или других), если это будет целесообразно для поставленных задач. 2. Балансировка и отказоустойчивость - PgBouncer или аналог — для пула соединений; - HAProxy или аналог — для балансировки трафика между нодами и репликами; - Поддержка отказоустойчивости: отключение одной ноды не нарушает работу всей системы; - Демонстрация восстановлений и переключений вручную или автоматически. 3 Обновление кода Telegram-бота - Возможность обновления кода на всех нодах: - через `git pull + restart`; - либо другим способом, который не прерывает работу всей системы; - Обновление одной ноды не должно мешать остальным; - Данные в базе при обновлении должны сохраняться. 4. CI/CD: auto-deploy при пуше - Настроить CI/CD для автоматического обновления при `git push` в `master`: - обновление кода Telegram-бота; - запуск Flyway миграций; - перезапуск службы бота; - Можно использовать GitHub Actions, GitLab CI, Ansible, rsync и т.п.; - Предоставить `.yml`-конфигурацию + пошаговую инструкцию по настройке. 5. Безопасность - Настроить безопасные роли PostgreSQL (readonly, writer, admin); - Минимизация открытых портов; - Ограничения по IP через конфигурацию `pg_hba.conf`; - Настройка параметров сети в `postgresql.conf` (например, `listen_addresses` и `port`); - Настройка базового firewall (например, UFW) для ограничения доступа к нужным портам. - Желательно обеспечить шифрование трафика между компонентами (PostgreSQL, Redis, бот и пр.) для защиты данных в передаче. 6. Снижение нагрузки - Настроить кеш (Redis или аналог) с TTL и политикой очистки; - По необходимости — использовать materialized views или рекомендации по оптимизации схемы; - Все решения должны поддерживать асинхронную работу (совместимость с `asyncpg`). --- 🧪 Тестирование - отключение одной из нод и проверка устойчивости и продолжения работы системы; - обновление кода должно поддерживать возможность поочерёдного обновления нод; - успешное применение миграций схемы базы данных через Flyway; - масштабирование системы: добавление новой ноды и проверка её интеграции и работы; - восстановление данных после аварийного отключения или перезапуска ноды; - нагрузочное тестирование для подтверждения производительности и масштабируемости системы; - проверка отказоустойчивости компонентов балансировки (PgBouncer, HAProxy); - проверка безопасности: доступ по ролям, ограничение по IP, корректность настроек firewall; - проверка CI/CD пайплайна: успешный деплой кода и миграций без остановки всей системы; - прочие тесты --- 📄 Документация - README + отдельные инструкции: - установка и запуск инфраструктуры; - добавление новых нод; - обновление кода; - миграции; - управление PgBouncer, HAProxy; - структура и использование кеша; - CI/CD: как работает, как добавить новую машину; - Язык изложения — простой, с пояснениями, примерами команд, скриншотами (по возможности); - Пояснение всех переменных `.env`, конфигураций и ключевых команд. --- 📦 Стек и ограничения - Допустимо использовать **Docker и docker-compose**, если это помогает упростить запуск и обслуживание; - Все решения должны быть **бесплатными и open source**; - Развёртывание на **виртуальных Linux-серверах в российских облаках** (например: VK Cloud, Selectel, Timeweb); - Все действия должны быть воспроизводимы вручную или с помощью скриптов и подробно описаны в документации. --- 📋 Приёмка - Полная передача всех материалов: скрипты, миграции, конфигурации, инструкции; - Демонстрация работоспособности системы на 2+ нодах (репликация, масштабирование, кеш, миграции, CI/CD); - Проверка отказоустойчивости (отключение одного из компонентов не останавливает систему); - Проверка корректной работы кеширования и механизма обновления кода; - **Разработчик отказывается от авторских прав** на результат: весь код, инструкции, конфигурации передаются заказчику без ограничений; - **Финальная приёмка производится после демонстрации работы системы и передачи всех материалов**,а также успешного прохождения заказчиком самостоятельной проверки по предоставленным инструкциям: - установка с нуля, - добавление ноды, - обновление кода, - применение миграции, - прохождение базовых тестов; - Приёмка подтверждается обеими сторонами после верификации результата и устранения возможных недочётов. --- 💰 Оплата - Предпочтительный вариант оплаты — через безопасную сделку - Либо иной способ оплаты — по договорённости сторон; - Ожидается оценка сроков и стоимости по этапам от исполнителя. 🧭 Рекомендуемый план разработки и тестирования Ожидается, что разработка и проверка решения будут организованы поэтапно, с учётом лучших практик инфраструктурной сборки. Ниже описан предпочтительный порядок действий, которого желательно придерживаться: 🔹 Этап 1: Локальная сборка - Первичная сборка и отладка инфраструктуры производится на локальной машине исполнителя с использованием `docker-compose`; - Все ключевые компоненты (бот, PostgreSQL, PgBouncer, Redis, Flyway) разворачиваются и тестируются в контейнерах; - Отрабатываются сценарии отказоустойчивости, масштабирования, миграции и кеширования; - Подготавливается структура каталогов, конфигураций и `.env`. 🔹 Этап 2: Настройка CI/CD - Реализуется автоматизация деплоя (например, через GitHub Actions или GitLab CI): - Обновление кода; - Применение миграций; - Перезапуск сервисов; - Проверяется цепочка обновления на тестовом сервере (в Docker или вручную). 🔹 Этап 3: Развёртывание в облаке - Исполнитель может начать тестирование на бесплатных облаках или промо-сервисах (например, пробные аккаунты VK Cloud, Timeweb Cloud, Selectel); - Если этих ресурсов недостаточно — исполнитель формирует краткий запрос к заказчику с предложением: - сколько виртуальных машин потребуется (и с какими параметрами); - на какой срок; - почему выбран конкретный провайдер; - Заказчик рассматривает этот запрос и принимает решение об аренде тестовых ресурсов, исходя из бюджета и целесообразности; - Все тестовые серверы должны быть подобраны с учётом минимальных расходов, без избыточных конфигураций; - Развёртывание производится вручную на 2 и более нодах; - Проверяется: - отказоустойчивость; - масштабирование; - взаимодействие компонентов (Redis, PgBouncer, координатор/воркеры); - полноценный запуск CI/CD; - Оценивается воспроизводимость развёртывания на новой машине по инструкции. 🔹 Этап 4: Передача и проверка заказчиком - Исполнитель предоставляет полные инструкции по воспроизведению среды на стороне заказчика; - Заказчик самостоятельно разворачивает систему по инструкции, обновляет код, применяет миграции и добавляет ноды; - Финальная приёмка проводится только после успешной самостоятельной верификации всех компонентов и сценариев.

Data Science. Разработка с нуля. Для приведенных ниже вариантов выполнить следующие задания: 1. (10 баллов) Провести анализ предметной области. Определите структуру коллекций так, чтобы они позволяли хранить все представленные в описании предметной области данные. Обосновать выбранную структуру данных. 2. (10 баллов) Создайте базу данных в СУБД MongoDB, коллекции в соответствии с пунктом 1 и минимум по 5 документов для каждой коллекции. Скрипт для выставки документов сохраните в отдельном файле *.js. 3. (10 баллов) Выполните запросы для созданных документов. Запросы представлены в каждом из вариантов. Аптека продает медикаменты и изготавливает их по рецептам. Лекарства могут быть разных типов: 1. Готовые лекарства: таблетки, мази, настойки: 2. Изготовляемые аптекой: микстуры, мази, растворы, настойки, порошки Различие в типах лекарств отражается в различном наборе атрибутов, их характеризующих. Микстуры и порошки изготавливаются только для внутреннего применения, растворы для наружного, внутреннего применения и для смешивания с другими лекарствами и мази только для наружного применения. Лекарство различны также по способу приготовления и по времени приготовления. Порошки и мази изготавливаются смешиванием различных компонент. При изготовлении растворов и микстур ингредиенты не только смешивают, но и отстаивают с последующей фильтрацией лекарства, что увеличивает время изготовления. В аптеке существует справочник технологий приготовления различных лекарств. В нем указываются: идентификационный номер технологии, название лекарства и сам способ приготовления. На складе на все медикаменты устанавливается критическая норма, т.е. когда какого-либо вещества на складе меньше критической нормы, то составляются заявки на данные вещества и их в срочном порядке привозят с оптовых складов медикаментов. Для изготовления аптекой лекарства, больной должен принести рецепт от лечащего врача. В рецепте должно быть указано: ФИО, подпись и печать врача, ФИО, возраст и диагноз пациента, также количество лекарства и способ применения. Больной отдает рецепт регистратору, он принимает заказ и смотрит, есть ли компоненты заказываемого лекарства. Если не все компоненты имеются в наличии, то делает заявки на оптовые склады лекарств и фиксирует ФИО, телефон и адрес необслуженного покупателя, чтобы сообщить ему, когда доставят нужные компоненты. Такой больной пополняет справочник заказов - это те заказы, которые находятся в процессе приготовления, с пометкой, что не все компоненты есть для заказа. Если все компоненты имеются, то они резервируются для лекарства больного. Покупатель выплачивает цену лекарства, ему возвращается рецепт с пометкой о времени изготовления. Больной также пополняет справочник заказов в производстве. В назначенное время больной приходит и по тому же рецепту получает готовое лекарство. Такой больной пополняет список отданных заказов. Ведется статистика по объемам используемых медикаментов. Через определенный промежуток времени производится инвентаризация склада. Это делается для того, чтобы определить, есть ли лекарства с критической нормой, или вышел срок хранения или недостача. Виды запросов в информационной системе: 1. Получить сведения о покупателях, которые не пришли забрать свой заказ в назначенное им время и общее их число. 2. Получить перечень и общее число покупателей, которые ждут прибытия на склад нужных им медикаментов в целом и по указанной категории медикаментов. 3. Получить перечень десяти наиболее часто используемых медикаментов в целом и указанной категории медикаментов. 4. Получить перечень и общее число покупателей, заказывавших определенное лекарство или определенные типы лекарств за данный период. 5. Получить перечень и типы лекарств, достигших своей критической нормы или закончившихся. 6. Получить полный перечень и общее число заказов находящихся в производстве. 7. Получить полный перечень и общее число препаратов требующихся для заказов, находящихся в производстве. 8. Получить все технологии приготовления лекарств указанных типов, конкретных лекарств, лекарств, находящихся в справочнике заказов в производстве. 9. Получить сведения о ценах на указанное лекарство в готовом виде, об объеме и ценах на все компоненты, требующиеся для этого лекарства. 10. Получить сведения о наиболее часто делающих заказы клиентах на медикаменты определенного типа, на конкретные медикаменты. Требования: Таблицы оформляются в удобном формате и размере. Допускается применять размер шрифта в таблице меньший, чем в тексте. Таблицы обязательно имеют номер и название. Таблицы следует нумеровать арабскими цифрами сквозной нумерацией. Допускается нумеровать таблицы в пределах раздела, тогда номер таблицы состоит из номера раздела и порядкового номера таблицы в разделе, разделенных точкой. Таблицу следует располагать непосредственно после текста, в котором она упоминается впервые. Название таблицы должно отражать ее содержание, быть точным, кратким. Название таблицы следует помещать над таблицей слева, без абзацного отступа в одну строку с ее номером через тире. Для всех величин, приведенных в таблице, должны быть указаны единицы измерения. Если в конце страницы таблица прерывается и ее продолжение буде на следующей странице, то в первой части таблицы нижнюю горизонтальную черту, ограничивающую таблицу, не проводят. На следующей странице пишут слова «Продолжение таблицы» или «Окончание таблицы», повторяют шапку таблицы или нумерацию граф таблицы. Уравнения и формулы из текста выделяют отдельными строками. Выше и ниже каждой формулы должен быть оставлен пробел не менее одной строки. Расшифровку символов и значений числовых коэффициентов следует давать под формулой. Обозначения символов дают подряд, через точку с запятой. Все рисунки рекомендуется размещать непосредственно после текста, в котором на него впервые ссылаются или на следующей странице. При этом следует писать «…в соответствии с рисунком 1». Нумерация рисунков может быть сквозная или по разделам. Слово «Рисунок» с его номером и наименованием через тире помещают под рисунком.