Что происходит на рынке прямо сейчас

За первую половину 2025 года количество IT-вакансий на Хабр Карьере упало на 32%, на HeadHunter — на 20%. Индекс конкуренции на Хабр Карьере в феврале 2026 года достиг 21,3 — это в два раза выше, чем год назад. На каждую вакансию джуниора сейчас приходится в среднем 11,1 резюме. Для сравнения: на вакансию сеньора — всего 2,3 резюме.

Почему так? Причин несколько. Компании оптимизируют бюджеты, замедлился рост отрасли, AI взял на себя часть рутинных задач. Параллельно на рынок вышло много выпускников курсов и вузов — спрос на IT-образование высокий, и новых кандидатов стало больше.

Но вот парадокс: джуниоров избыток, а мидлов и сеньоров по-прежнему не хватает. Компании не могут найти опытных специалистов, значит, бизнесу приходится растить своих — и вот тут появляется шанс для джуниоров. Их берут вместо дорогих мидлов на поддержку кода, фикс багов, рутинные задачи.

“Классически самыми быстрыми точками входа в профессию были, есть и остаются QA, бизнес-анализ и системный анализ. Особенно если ваш предыдущий опыт так или иначе был связан с аналитической работой — это серьезное преимущество для перехода в бизнес- или системные аналитики.

Кстати, факт: многие рекрутеры успешно переходят и продолжают переходить именно на позиции бизнес- и системных аналитиков. Более того, несколько лет назад как минимум двое моих коллег сменили профессию и ушли в это направление — сейчас это уже крепкие специалисты уровня middle-plus.

QA — еще одно направление, в котором можно действительно много развиваться, начав с ручного тестирования. Дальше есть несколько траекторий роста:
- углубляться в ручное тестирование;
- освоить автоматизацию;
- уйти в нагрузочное тестирование.

И на каждой из этих веток можно отлично себя чувствовать профессионально и финансово

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

Почему компании боятся брать джуниоров

С точки зрения работодателя наём джуниора — это риск. Вот что пугает бизнес:

Накрученный опыт в резюме

Многие джуниоры завышают свой уровень, чтобы попасть на более высокие позиции. Обман вскрывается либо на собеседовании, либо на испытательном сроке, но компания уже потратила время и деньги. Процессинг одного кандидата занимает около двух недель, не считая времени на поиск. Часто приходится привлекать рекрутинговые агентства — это дополнительные расходы.

Долгая окупаемость

Джуниору нужно минимум 6 месяцев, чтобы начать приносить ощутимую пользу. В течение этого времени ему платят зарплату, его обучают, на него тратят время тимлида и коллег, но не каждая компания готова ждать так долго.​

Риск увольнения

Что если вложить в джуниора ресурсы, обучить его, а он уйдёт к конкурентам через год? По статистике, джуниоры работают на первом месте в среднем 5-8 месяцев, а для компании это выглядит как слив инвестиций.​

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

Как компании растят джуниоров

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

Схема выглядит так: вас нанимают с базовыми техническими знаниями и в течение 1-3 месяцев обучают делать что-то одно. Например, работать с определённым участком кода, поддерживать легаси, писать тесты, фиксить баги по чётким инструкциям.

Когда вы выходите в команду, вы уже знаете свою зону ответственности, коллегам не нужно постоянно объяснять, что делать — вы справляетесь с простыми задачами самостоятельно. Это не превратит вас в мидла за три месяца, рост в грейде происходит только через работу с реальными проектами и задачами, но вы станете джуниором, который приносит пользу с первых недель, а не сидит в сторонке и учится полгода за счёт компании.

Как доказать, что вы стоите инвестиций

Не накручивайте грейд

Первое и главное правило: не врите про свой уровень. Компании тратят две недели на обработку одного кандидата, и если обман вскроется на собеседовании или испытательном сроке, вы просто сожжёте свою репутацию, а IT-комьюнити узкое, информация расходится быстро.

Указывайте курсы, которые вы прошли. Лучше всего, если это будут программы от непосредственных работодателей (например, от Яндекса или банков) — они наиболее приближены к тому, чем люди занимаются в реальной жизни.

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

Главный тезис: Ваше резюме должно показывать, что вы — нормальный, надежный человек, с которым можно работать.

Если у вас только pet-проекты и учебные задачи, не называйте это коммерческим опытом. Работодатель не ждёт от вас опыта мидла, он ищет человека с базовыми знаниями, которого можно быстро обучить под свои задачи.

Если у вас был опыт работы до IT — неважно какой — его нужно указать. Особенно ценно, если это крупные компании и долгосрочное сотрудничество (например, три года финансистом в «Северстали» или банке). Это отличный знак для работодателя, потому что:

- вы понимаете, как работает корпоративная среда, и уже адаптированы в ней;
- вы знаете, что такое трудовая дисциплина;
- вас не нужно учить базовым вещам: как вести себя на встречах, что можно и нельзя, как работает бизнес и почему нельзя хамить руководителю.

В таком случае обучение будет одновекторным: оно коснется сугубо изучения новой IT-специальности и погружения в компанию, а не воспитания базовой ответственности.

Покажите готовность учиться конкретным вещам

Компания заточит вас под свой проект, поэтому лучше уберите фразу в резюме: “Хочу изучать современные технологии и развиваться во всех направлениях”. Лучше покажите, что готовы глубоко погрузиться в конкретный стек или задачу. Если компания ищет человека на поддержку старого кода, покажите, что вам интересно разбираться в чужой кодовой базе и рефакторить её.

Важный плюс этих направлений: начальные требования к кандидатам здесь ниже, чем, например, в разработке. Это значит, что на старте можно сильно выехать на хороших софт-скиллах или на навыках, которые вы уже наработали в прошлой карьере — особенно если вы идете в IT не сразу после учебы, а с бэкграундом из другой сферы.

Покажите понимание бизнес-задач

Работодателя волнует, сможете ли вы закрывать задачи, которые приносят компании деньги. Поэтому на собеседовании объясните, какие проблемы вы решали в своих учебных проектах и как это применимо к задачам компании. Если вы делали pet-проект, опишите его не через технологии, а через результат. Например, что вы автоматизировали процесс сбора данных, который раньше занимал три часа ручной работы.

Если вы идете сразу после обучения, резюме нужно разнообразить. Обязательно добавьте ссылки на пет-проекты, если они были.

Для свитчеров: Если вы меняете сферу (например, были маркетологом, а хотите в UI/UX), вам нужны ссылки на работы, которые вы сделали сами, и краткое описание пройденных курсов.

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

Дайте сигналы стабильности

Работодатель боится, что вы уйдёте через полгода, поэтому если вы планируете задержаться надолго, дайте понять это на собеседовании: спросите про карьерный трек, уточните, как устроен рост внутри компании, поинтересуйтесь, какие проекты планируются на ближайшие год-два.

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

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

- Либо после стажировки вы проявите себя, и вам предложат работу на хорошую ставку;
- Либо не предложат, но вы добавите в резюме строчку о трёхмесячной практике в банке — и на вас будут смотреть совершенно по-другому.

На первую джуновую работу, если вы только пришли в IT или это ваша первая работа вообще, не нужно смотреть на деньги и рубиться за них. Вы должны понимать: первые как минимум три месяца вы получаете сугубо опыт. Нормально этот опыт будет котироваться, и вы сможете продавать себя по рыночной ставке, только когда отработаете год. И это должен быть год на одном месте. Если начнёте «прыгать» по компаниям — выстрелите себе в колено, и резюме станет только слабее.

Первые полгода — как оправдать инвестиции

Почему полгода — ваш самый сложный период

Компания окупает вложения в джуниора примерно за полгода. В это время вы выполняете простую линейную работу, постепенно набираете скорость, учитесь работать в команде. За эти шесть месяцев вероятность вашего увольнения минимальна — уйти к другому работодателю с такими маленьким опытом сложно.

Берите простые задачи и закрывайте их качественно

В первые месяцы от вас никто не ждёт архитектурных решений или оптимизации узких мест. Вас будут загружать линейными задачами: мелкие фичи, баг-фиксы, рефакторинг, ваша задача — делать их быстро и без косяков.

Не требуйте постоянного гайдинга

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

Фиксируйте свой прогресс

Ведите список задач, которые закрыли. Отмечайте, что нового узнали, какие проблемы решили. Это нужно, чтобы на встрече с тимлидом или на ревью испытательного срока вы могли чётко показать, что сделали за это время.

Принимайте ответственность за свои ошибки

Вы будете ломать прод, заливать баги или забывать тестить. Это нормально для джуниора, ненормально — прятаться, молчать или сваливать вину на других. Если вы накосячили, сразу говорите об этом, объясните, что пошло не так, и предложите, как это исправить.

От джуниора до мидла — реальные сроки

Рост до уверенного мидла занимает в среднем три года, грейды в разных компаниях определяются по-разному, но временная дистанция примерно одинаковая. Ускорить этот процесс можно, но критично — попытки форсировать рост убивают ключевые компетенции.

Через год работы вы станете интересны другим работодателям. К этому моменту у вас уже есть реальный опыт в команде, закрытые задачи, понимание процессов, а ваша стоимость на рынке вырастет.

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

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

Гораздо важнее потратить это время не на то, чтобы рубиться за лишние 10-15-20 тысяч рублей к зарплате, а на то, чтобы получить опыт, который позволит вам через год зарабатывать в 10 раз больше.

Компания, которая в вас вложилась, это понимает и будет предлагать вам понятный карьерный трек, пересматривать зарплату и условия. Если проект закроется или стек изменится, вас переведут в другую команду.

Чек-лист для джуниора

На этапе поиска работы:

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

Оценивать себя «по медиане» вообще не надо. Нужно исходить из тех предложений, которые идут.

Если у вас спрашивают: «Какая у вас минимальная цифра?» — называйте сумму, которая нужна вам именно для сведения концов с концами. Не называйте цифру, потому что «посмотрел среднее на HeadHunter, решил, что я молодец, добавил чуть-чуть и хочу зарабатывать прямо сейчас». Это плохая стратегия даже в суперкраткосрочной перспективе.

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

Для работодателя джун — это как «кот в мешке». Не добавляйте ему сомнений и желания сделать выбор не в вашу пользу, давая волю жадности. Это всегда работа в будущее.

В первые полгода работы:

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

Через год работы:

• Оцените свой прогресс и обсудите его с тимлидом
• Уточните условия роста и пересмотра зарплаты
• Решите, хотите ли остаться в компании или искать новые возможности

Рынок изменился, конкуренция выросла, но спрос на джуниоров остался, просто они теперь нужны бизнесу для поддержки, обучения и роста внутри компании. Теперь вы знаете, как это работает.

В этой статье мы рассмотрим создание микросервиса обработки изображений на golang с использованием технологии **gRPC**. Цель статьи - показать как может выглядеть такой сервис и что он может в себя включать. В результате мы получим полностью рабочий сервис по обработке изображений, который принимает данные, сохраняет исходную картинку,сжимает её, накладывает на неё ватермарку, изменяет размер изображения, и конвертирует его в нужный формат.

Разберём возможные варианты взаимодействия клиента с сервером для обработки больших объектов, в нашем случае это картинки:

1. HTTP/1.1 (REST)

Передача изображений в виде текстовых чанков (например, base64) приводит к значительным накладным расходам: бинарные данные увеличиваются на ~33% при кодировании в Base64, а текстовый формат неэффективен для больших объёмов.

2. WebSocket

Подходит для долгоживущих сессий и двустороннего обмена, но избыточен, если нам нужно просто «принять изображение → обработать → вернуть результат». Удержание тысяч соединений ради однократных операций — неоптимально.

3. gRPC использует:

Protocol Buffers — строго типизированный, компактный бинарный формат,

HTTP/2 — мультиплексирование, потоки, сжатие заголовков,

Client-Streaming — идеально подходит для передачи одного большого файла (например, изображения) в одном вызове.

I. Постановка задачи

Сервис должен:

Принимать изображение и параметры (format, compress, watermark, width[], height[]),

Сохранять оригинал с уникальным путём (./download/YYYY/MM/DD/UUID/img/...),

Накладывать водяной знак,

Генерировать версии заданных размеров,

Сохранять полученные изображения,

Возвращать список путей.

Пример:

Запрос с width = [1920, 1280], height = [1080, 720], format = "webp", watermark = "logo.png"

→ Сервис вернёт два пути:

./download/2026/02/08/abc123/img/abc123_1920x1080.webp

./download/2026/02/08/abc124/img/abc124_1280x720.webp

II. Архитектура приложения

Обработка происходит в строгом порядке:

1.Приём → 2. Сохранение исходного файла→ 3. Сжатие → 4. Watermark → 5. Resize → 6. Конвертация → 7. Ответ.

Структура хранения:

./download/2026/02/08/a1b2c3d4-.../img/

├── a1b2c3d4-....jpg ← оригинал

├── a1b2c3d4-..._800x600.png

└── a1b2c3d4-..._1024x768.png

Необходимые инструменты:

Для работы с WebP мы используем библиотеку golang.org/x/image/webp , а исходные утилиты можно скачать на официальной странице Google.

Для генерации protobuff нам нужен protoc-gen-go

protoc-gen-go-grpc

Позволяет генерировать определения сервисов Go для буфера протокола, заданного нашим .proto файлом protoc-gen-go-grpc

Также для работы webp нам потребуется работа с CGO, которую мы рассмотрим отдельно.

III. Реализация proto файла

Для начала работы опишем наш proto файл. Это будет сервис с единственным rpc который будет обрабатывать картинки пользователей.

./proto/image.proto

Мы используем Client-Streaming RPC — клиент может отправить несколько сообщений, сервер — один ответ. Этот способ поможет нам в случае необходимости гибкого расширения и избежания ограничений на размер одного сообщения.

V. Реализация основных функций

1. Создание сервера

1.1 Генерация go файлов из .proto: Сгенерируем файлы для реализации сервера с помощью protoc:

У нас должно получиться 2 файла image.pb.go и image_grpc.pb.go в директории proto

1.2 Реализуем конструктор сервера и interceptor (аналог middleware в grpc) восстановления после паники:

./internal/app/server.go

Теперь реализуем функцию запуска нашего grpc сервера:

Мы создали наш grpc сервер, но пока нет никакой реализации ImageServiceServer который сгенерировал нам protoc, это просто интерфейс который нам и нужно реализовать.

2. Реализация ImageServiceServer

Нам необходимо создать структуру ImageServer которая реализует интерфейс ImageServiceServer с его методом DownloadImage, также создадим конструктор для него :

./internal/app/image.go

Нам осталось реализовать ключевые функции для нашего сервиса, а именно: saveSourceFiles: отвечает за сохранение исходных файлов и их сжатие, watermark: наложение ватермарки , resizeAndSave: изменения размера картинки и его конвертация в нужный формат изображения.

3. Сохранение оригинала

Мы создаем путь для сохранения картинки, сохраняем её с необходимым для клиента уровнем сжатия и потом для удобства всю метаинформацию об картинке помещаем уже в нашу структуру и работаем в дальнейшем только с ней:

./internal/app/save.go

Для ускорения нашего процесса обработки все этапы мы будем выполнять конкурентно с помощью горутин.

4. Водяной знак

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

./internal/app/watermark.go

Остаётся только изменить размер и сохранить в нужном формате наши обработанные изображения.

5. Resize и конвертация.

Теперь создадим файл resize.go и реализуем функцию изменения размера изображении и сохранения в нужном нам формате:

./internal/app/resize.go

Теперь реализуем main.go в котором создадим и вызовем наш сервис обработки изображений.

./internal/cmd/main.go

VI. CGO

Наше приложение полностью готово, но теперь нужно удостовериться, что у нас работает поддержка CGO. Для начала нужно убедиться что мы скачали и установили webp по ссылке [официальная страница Google](https://developers.google.com/speed/webp/download?hl=ru). Далее нам необходимо установить GCC, без него go не может распознать импортированные C файлы, скачиваем и устанавливаем [официальные зеркала GNU](https://gcc.gnu.org/mirrors.html). Теперь нужно проверить, что переменная CGO_ENABLED=1, для этого используем команду go env и проверяем, если она равна 0, то используем go set CGO_ENABLED=1 и проверяем ,что она применилась, если нет то перезагружаем нашу систему и проверяем. Теперь мы готовы собрать наше приложение и приступить к тестированию.

VII. Тестирование и оптимизация

Тестирование с Bruno

Здесь вы можете тестировать удобными для вас средствами такими как Postman, Bruno, Yaak, grpccurl и т.д., главное чтобы они поддерживали тестирование grpc методов. Рассмотрим пример с Bruno:

1.Конвертируйте изображение в Base64: Image to Base64 Converter

2.Откройте Bruno создайте новый grpc запрос

3. Выбираем метод grpc:

4.Уберите ползунок с reflection и укажите .proto файл

5.Выберите метод DownloadImage

6.В поле message заполните поле в соответствии с параметрами, например:

В поле image нужно скопировать текстовую строку ,что идёт после запятой, сгенерированную на шаге 1

7.Далее нужно запустить наше приложение и подключиться к нему с помощью кнопки →

В случае успеха должен появиться статус streaming

8.Отправляем наше сообщение/сообщения нажав на кнопку "Send message" один или несколько раз и завершаем нашу передачу сообщений с помощью кнопки → (если не нажать то приложение будет ожидать приёма сообщений). Результатом будет возврат путей наших обработанных сообщений

VIII. Заключение

Подведем итоги, мы создали сервис который:

Использует gRPC для эффективной передачи данных,

Поддерживает WebP, JPEG, PNG,

Безопасен в конкурентной среде,

Можно легко масштабировать.

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

Исходный код доступен по ссылке

Спасибо за внимание!

Маша Даровская (Tproger): Сегодня мы обсуждаем разные хобби и интересные проекты в IT. У нас в гостях Иван, который создал телеграм-бота для генерации эскизов татуировок. Иван, расскажи немного о себе.

Иван: Всем привет! Меня зовут Иван, мне 32 года. Я создал генератор тату-эскизов с помощью вайб-кодинга, нейросети Grok и ChatGPT. Я тату-мастер, работаю в этой сфере уже 13 лет — это мой основной заработок и основная деятельность. Но уже давно хочется чего-то нового: выйти из зоны комфорта, попробовать себя в чём-то другом. Вот сейчас и пробую.

Идея создания чат-бота для тату-эскизов

Маша Даровская: Расскажи, как тебе вообще пришла идея создать чат-бота, который генерирует эскизы?

Иван: Дело в том, что я отношусь к той категории тату-мастеров, которые не любят рисовать. Думаю, таких немного, но я действительно не люблю и не умею рисовать. Прошлым летом я пробовал генерировать эскизы с помощью нейросетей, тестировал разные варианты, но ничего не могло создать идеальный минимализм. Под минимализмом я имею в виду, например, контурный эскиз кота из фотографии. Это специфика моей работы — я в основном занимаюсь минимализмом, графикой. А нейросети выдают сложные, детализированные арты, которые мне не подходят. Поэтому я забросил это дело.

Весной я подключил премиум-версию ChatGPT по другому поводу — хотел писать других ботов. Но потом решил попробовать попросить его сгенерировать эскизы. И он сделал это идеально. В процессе общения я спросил: можем ли мы интегрировать твой API в Telegram-бота, чтобы генерировать эскизы? Так и появилась эта идея.

Маша Даровская: Когда ты говоришь, что не умеешь рисовать, слушателям может быть непонятно: всё равно ведь нужно уметь хотя бы срисовывать эскиз?

Иван: Здесь всё упирается в опыт. Сама отрисовка не требует особых навыков. Я начал заниматься татуировками 13 лет назад, когда друзья позвали меня сделать тату. Я посмотрел, как это происходит: человек переводит контурный эскиз, обводит, закрашивает — как раскраска. Мне это показалось простым, поэтому я и начал. Если речь о реализме или портретах, это сложнее, но даже там с опытом можно научиться срисовывать. Но я не делаю реализм — мне это неинтересно.

Маша Даровская: Тебе казалось, что это просто, а оказалось, что не так?

Иван: Делать татуировки действительно просто. Я до сих пор так считаю. Первые пять лет я удивлялся: почему все не делают татуировки? Это легко, приятно, и деньги неплохие. Я никогда не понимал, зачем люди ходят на нелюбимую работу, если можно заниматься татуировками. У меня нет особой любви к рисованию или татуировкам — это просто работа.

Маша Даровская: Были какие-то необычные татуировки, которые у тебя заказывали?

Иван: Особой любви к этому делу у меня не было, поэтому я мало что запоминал. Но был один случай: делал татуировку под губой у девушки с никнеймом «Сосиписос». Она набила надпись «Соси Песос». Эта татуировка набрала в Instagram около полутора тысяч сохранений. Это было давно, ещё до рилсов. Такие штуки делал.

Создание чат-бота и его влияние на работу

Маша Даровская: Когда ты решил создать бота, насколько он упростил тебе работу?

Иван: Сам бот мне работу особо не упростил, но ChatGPT сильно помог. Я перестал использовать iPad для рисования эскизов — теперь он только для мультиков сына. Я просто пишу в ChatGPT: «Сделай мне это», и почти всегда получаю нужный результат. Иногда с детализированными эскизами он может «тупить» — например, неправильно нарисовать хвост змеи. Но если дать референс с фото татуировки и попросить доработать на белом фоне, он справляется отлично. Мне почти ничего не нужно делать.

Маша Даровская: Клиентам нормально показывать такие эскизы?

Иван: Они даже не знают, чем это отличается от ручной работы. Я в 95% случаев сразу предупреждаю, что не рисую, работаю по готовым эскизам. Теперь я генерирую их через ChatGPT, выкладываю в канал и говорю, что это мои работы. Не вижу в этом ничего плохого.

Маша Даровская: Расскажи подробнее, как ты делал бота и сколько времени ушло?

Иван: Сам бот я написал за неделю на Python, без сервера и деплоя. Сложности начались с деплоем. Было две версии: первая — простая, без оплаты и геймификации, я разместил её на Railway с автодеплоем. Вторая — на российском Timeweb, с монетизацией. Самые сложные моменты — деплой, подключение монетизации и работа с версиями библиотек. Иногда я тратил 10 часов на одну внутреннюю ошибку при запуске.

Маша Даровская: Скрипт на Python, и ты подключал его к API?

Иван: Да, генерация идёт через DALL·E. Сначала пробовал Stable Diffusion, но результаты были ужасными — не хватало оптимизации промтов, как в ChatGPT. DALL·E автоматически улучшает запросы, например, для «змеи с кинжалом». Но через API DALL·E не поддерживает image-to-image, что для меня важно. Для этого нужен Stable Diffusion, но там свои сложности.

Маша Даровская: Думал как-то дорабатывать бота?

Иван: Да, следующий шаг — интегрировать Stable Diffusion для работы с референсами. Для этого нужна отдельная модель под каждый стиль татуировки, обученная на 100–150 эскизах. Это требует сервера с GPU, что стоит около 1500 рублей в месяц. Пока это кажется сложным, но когда я начинал, тоже думал, что всё сложно, а оказалось проще.

Маша Даровская: Думал о браузерной версии или приложении?

Иван: Да, но сейчас приоритет — маркетинг. Сделать бота — одно, а привлечь аудиторию — другое. У меня около 130 пользователей без особого продвижения, но это не целевая аудитория. Оплаты пока скромные — несколько транзакций по 15 рублей за генерацию. Есть пакеты: чем больше покупаешь, тем дешевле. Себестоимость одной генерации — около 4 рублей, но с комиссиями выходит больше.

Маша Даровская: Что было самым сложным при создании бота?

Иван: Не код, а ошибки, которые я не понимал. Для опытного программиста это, может, и просто, но я иногда сидел до четырёх утра, решая одну проблему. Несколько раз хотел бросить, но в итоге всё решалось.

Другие проекты и планы

Маша Даровская: Ты говорил, что начинал с других ботов. Каких именно?

Иван: Сделал бота-врача, который отвечает на вопросы о здоровье. Но он неактуален — люди могут получить то же самое бесплатно, например, в DeepSeek. Монетизация возможна через рекламу, но это не то. Пока дохода нет.

Маша Даровская: Видишь ли ты себя вайб-кодером в будущем?

Иван: Программирование мне интересно. Вайб-кодинг хорош тем, что можно самому реализовать идею, создать MVP, проверить спрос. Если проект пойдёт, можно нанять программистов. Это круто для проверки идей без больших затрат.

Маша Даровская: Ты хотел сменить сферу деятельности. Почему?

Иван: На самом деле, мне не нравится делать татуировки. Раньше казалось крутым, но я всегда смотрел в сторону бизнеса. У меня была студия пять лет, но я её закрыл. Сейчас меня интересуют pet-проекты — создавать небольшие продукты, раскручивать их. Это может стать кейсом для портфолио, например, в продакт-менеджменте. Я не разбираюсь в IT, но знаю, что там ценят реальные достижения.

Маша Даровская: Пробовал учиться чему-то в IT?

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

Работа с нейросетями и их применение

Маша Даровская: Какая нейросеть тебе больше нравится?

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

Маша Даровская: Есть ли нетривиальные способы применения нейросетей?

Иван: Сейчас я использую ChatGPT для судебного разбирательства. Арендодатель не возвращает залог за квартиру, придирается к мелочам. ChatGPT помог составить досудебную претензию и юридические сообщения. Я общаюсь в правовом поле, корректирую его тексты минимально. Он подсказал, что шансы выиграть — 90%, упомянул законы о естественном износе. Это интересный опыт, и если получится, будет крутой кейс.

Маша Даровская: Совет для тех, кто хочет попробовать, но боится?

Иван: Не бойтесь. Это интересно. Ты один дома, пишешь идею в ChatGPT, он подсказывает, что делать: разложить по полочкам, собрать MVP. С маркетингом сложнее, но в остальном — бери и делай.

Что такое pet-проект и зачем его защищать

Pet-проект (от английского pet — «домашний питомец») — тренировочный проект, который разработчик создаёт в свободное время по собственному желанию. Обычно их делают, чтобы освоить новую технологию, пополнить портфолио или поучаствовать в хакатонах.

Такие проекты часто воспринимают как что-то «несерьёзное», но пренебрежение информационной безопасностью может привести к неприятным последствиям. Злоумышленники используют уязвимости pet-проектов для получения доступа к ресурсам разработчика, кражи данных и будущих атак на более крупные цели.

Кроме того, защита pet-проекта — важный навык, который высоко ценится работодателями.

Рассмотрим основные правила кибербезопасности, которые нужно учитывать при работе над pet-проектом.

Безопасное управление секретами

Секреты — это чувствительные данные, такие как пароли, токены доступа, ключи API, SSH-ключи, сертификаты и другие данные, которые обеспечивают аутентификацию и шифрование. Если добавить секреты в код, злоумышленники могут получить полный контроль над вашей инфраструктурой.

Какие правила нужно соблюдать

• Не храните секреты в коде. Храните секреты в отдельных файлах env. и добавьте эти файлы в .gitignore, чтобы они не попадали в репозиторий.
• Придерживайтесь принципа минимальных привилегий. Каждый сервис должен иметь только те права, которые необходимы для выполнения своих задач.
• Регулярно обновляйте секреты. Меняйте токены и пароли периодически, особенно после обнаружения утечек или изменений в проекте.
• Используйте менеджеры секретов. Популярные сервисы: Doppler, HashiCorp Vault, AWS Secrets Manager, 1Password Developer Tools.
• Мониторьте утечки. Можно использовать такие инструменты, как GitGuardian, TruffleHog, Gitleaks.
• Шифруйте секреты. Используйте библиотеки типа cryptography в Python и подключайте шифрование на уровне операционной системы.

Безопасность CI/CD

Пайплайн CI/CD (Continuous Integration / Continuous Delivery) — автоматизированный процесс сборки, тестирования и развёртывания приложений. Он помогает автоматически интегрировать код и деплоить его на различные среды.

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

Способы защиты пайплайна

• Моделируйте угрозы. Оцените, какие угрозы наиболее вероятны на каждом этапе пайплайна: от коммита кода до деплоя на сервер.
• Проверяйте зафиксированный код. Используйте статический анализ кода для автоматического поиска уязвимостей.
• Защитите Git-репозитории. Настройте двухфакторную аутентификацию (2FA), ограничьте доступ к репозиториям, используйте обязательную проверку пул-реквестов двумя разработчиками.
• Изолируйте пайплайн. Не запускайте его на том же сервере, где крутится ваше продакшн-приложение.

Дополнительно стоит шифровать секреты в пайплайне и минимизировать их передачу между этапами сборки.

Сервисы мониторинга и логирования

Логирование — запись событий, ошибок и других данных о работе приложения в специальные файлы или базы данных. По сути, это дневник.

Мониторинг — наблюдение за состоянием приложения, инфраструктуры или сервисов в реальном времени для своевременного выявления падения сервера, роста ошибок и других проблем.

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

Примеры популярных сервисов

Logtail — простой инструмент для сбора и анализа логов, есть бесплатный тариф.

Papertrail — удобный сервис для быстрого поиска по логам, бесплатный план для небольших проектов (10 Мб в день).

Sentry — хорош для отслеживания ошибок в приложениях на клиентской стороне и сервере.

BetterStack — мониторинг доступности сайтов и серверов с бесплатными уведомлениями об инцидентах по почте, через SMS и Slack.

Grafana Cloud Free — мониторинг с красивыми дашбордами, бесплатный лимит ресурсов до 10 тыс. серий данных, 50 ГБ трафика.

Prometheus и Grafana — Prometheus собирает метрики, Grafana их визуализирует.

UptimeRobot — проверка доступности вашего проекта каждые 5 минут, бесплатный тариф на 50 мониторингов.

Бэкап и восстановление данных

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

Как сделать бэкап пошагово

1. Определите данные, которые необходимо бэкапить: какие данные критически важны, какие можно восстановить вручную.
2. Выберите место хранения: облачные сервисы, собственные серверы, внешние носители, Git-репозиторий.
3. Выберите тип бэкапа: при полном копируются все данные целиком, при инкрементном — изменения с момента последнего копирования, при дифференциальном — изменения с момента последнего полного бэкапа.
4. Настройте автоматизацию, чтобы не забывать делать бэкапы вручную. Можно использовать скрипты, планировщики задач или бэкап-сервисы.
5. Проверьте бэкап. Проведите тестовое восстановление.
6. Определите частоту бэкапа. Например, можно проводить полный бэкап раз в неделю и инкрементные бэкапы каждый день.
7. Защитите чувствительные данные.

Локальные туннели

При разработке pet-проекта может возникнуть необходимость показать результат внешнему миру. Кроме того, многие внешние сервисы, такие как платёжные системы и мессенджеры, тоже требуют «боевые» URL для отправки запросов. Однако открывать порты на своём устройстве напрямую небезопасно. Локальные туннели создают временный внешний URL-адрес без развертывания на реальном сервере.

Когда вы запускаете туннель через специальный инструмент, он:

• устанавливает зашифрованное соединение между вашим компьютером и своим публичным сервером;
• создаёт внешний адрес;
• пересылает все запросы, которые приходят на этот адрес, вашему локальному приложению.

Трафик при этом шифруется и проходит через защищённый канал.

Примеры инструментов

Ngrok — самый известный инструмент для быстрого создания туннелей. Есть бесплатный тариф.

Порты от VSCode — отличное решение для пользователей Visual Studio Code, удобно для быстрой демонстрации.

VK Tunnel — российская альтернатива, подходит для работы через VK Cloud.

Tuna и xTunnel — простые в использовании решения, есть бесплатные тарифы.

Чек-лист по инфобезу для тех, кто делает pet-проект

1. Регулярно обновляйте зависимости. Используйте автоматические инструменты, например, Dependabot или npm audit.
2. Настройте базовые HTTP-заголовки безопасности. Добавьте заголовки Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, чтобы минимизировать риск XSS, Clickjacking и других атак.
3. Используйте бесплатные SSL-сертификаты. Подключите HTTPS через бесплатные сервисы, например, Let's Encrypt.
4. Очищайте и валидируйте ввод данных. Фильтрация и валидация данных защитит от SQL-инъекций и XSS.
5. Создайте отдельные учётные записи для разных сервисов. Не используйте одну и ту же учётную запись везде.
6. Минимизируйте доступы к базе данных. Если сервису нужно только читать, не давайте права на запись или удаление.
7. Используйте бесплатные инструменты для сканирования уязвимостей. Проверьте код через такие сканеры, как SonarQube Community Edition, Snyk, OWASP ZAP.
8. Делайте резервные копии. Настройте автоматические бэкапы базы данных и важных файлов.
9. Не храните секреты в коде. Используйте .env файлы и убедитесь, что они добавлены в .gitignore.
10. Включите двухфакторную аутентификацию (2FA). На всех сервисах, где это возможно, включите 2FA для дополнительной защиты.
    

А больше про разработку и все, что с ней связано, в нашем тг-канале!

С чем я пришел в Школу

До поступления в школу я занимался программированием, сейчас учусь в университете на специальности «Робототехника и искусственный интеллект». У нас в программе, разумеется, есть курсы по машинному обучению и Python с практикой. В дополнение я проходил бесплатные курсы на Stepik и похожих платформах, был на митапах по Data Science, пробовал проходить стажировки. Плюсом делал небольшие pet-проекты, но коммерческих работ не было.

Год назад я наткнулся на лендинг Школы. Мне понравилось, как расписана программа, кем являются преподаватели — это и подкупило. Последним аргументом стала возможность попасть на стажировку в МТС.

В итоге я подал заявку, прошел вступительный экзамен (в форме теста), написал мотивационное письмо — и, наконец, попал на обучение. Из огромного числа заявок прошли отбор лишь 120 человек.

Много математики, много домашки и баллы за кофе с одногруппниками: как строилось обучение

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

Занятия были очень интенсивными: два раза в неделю мы слушали лекции, по три часа каждая (всего мы отучились 360 часов!). Весь материал читали преподаватели во время трансляции. Там же отвечали на вопросы студентов по теме лекции или о себе и работе. Живое общение очень мотивировало посещать трансляции, а не ждать записи и откладывать «на потом».

Программа состояла из нескольких блоков: SQL, Python, математическая статистика, оптимизация, классический ML, визуализация, временные ряды и A/B-тесты, Big Data, RecSys, NLP, кейсы в ML и System Design. Около половины программы заняла теория: математика, статистика, теория вероятности и прочее. Другая половина — это работа с данными, Python, машинное обучение.

За пятнадцать лет работы в DS я пришел к выводу, что с коллегами, которые ловко освоили хайповые либы и не обладают фундаментальными знаниями, работается как на минном поле — никогда не знаешь где рванет. Часто эти ошибки касаются базовой статистики, интервальных оценок, а еще чаще — работы алгоритмов. Строгие теоретические выкладки подменяются мифами, а давно преодоленные ограничения старых реализаций алгоритмов становятся догматами. Отсюда и идет целеполагание нашей программы. При этом учить одну лишь теорию скучно, и у студентов возникнут справедливые вопросы о применимости знаний. При создании программы я старался дать за весьма ограниченный срок (всего год) и базу, и практические навыки. Это нужно, чтобы специалист на выходе стал самостоятельным: мог построить end2end-приложение с ML — от скраппинга данных до деплоя и оценки эффективности решения в деньгах. Это действительно сложно: начать с занятий Python и SQL и за год дойти до Spark и PyTorch, параллельно двигаясь от алгебры, оптимизации и статистики до устройства трансформерных архитектур и проблем смещений (bias) в рекомендательных системах. При этом базовые блоки выступают фундаментом для дальнейших занятий, и курс с середины не пройти.

Многие преподаватели делили их на теорию и практику: изучили материал на лекции и сразу попробовали применить его при выполнении какой-то задачи.

Почти после каждого занятия мы получали домашнее задание на неделю — или более объемную итоговую работу, если закончили какой-то блок. Разумеется, все по теме лекции: от посчитать какую-то вероятность до написать бэкенд сайта для бронирования книг.

Что-то было довольно простым, например, все тот же сайт. Но иногда приходилось довольно долго думать.

Хороший пример — итоговая работа по Big Data. Нам дали файлы датасетов, по которым надо было выполнить четыре задачи:

1. Проанализировать данные, описать проблемы, которые в них содержатся (проблемы хранения тоже считаются), и предложить решения.
2. Реализовать поток данных из топика, который бы удовлетворял конкретные условия.
3. Реализовать batch-поток для обработки исторических данных и построить на его основе четыре отчета.
4. Спроектировать модель данных и таблицы для хранения информации из предыдущих задач. И протестировать эту модель на нескольких запросах.

Многие домашки были построены так, что их можно сразу класть в портфолио и подавать как пет-проекты. Например, домашкой по ML было близкое к реальному техническое задание от продакт-оунера: внедрить ML-модель в прод.

До начала курса я был знаком с основами математической статистики, SQL, Python и ML, и Школа аналитиков данных смогла дать мне главное — практический опыт, которого не хватало. С каждым месяцем обучение становилось интереснее: я начал узнавать вещи, о которых никогда не слышал.

А еще меня впечатлила сама организация. Спасибо Алине Веденской и Марии Теплинской за то, что регулярно постили анонсы и новости курса и всегда быстро давали обратную связь.

Еще нас мотивировали с помощью челленджей

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

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

Высокий рейтинг — возможность попасть на стажировку

У топ-5 студентов по учебному рейтингу была возможность пройти все этапы отбора на стажировку в упрощенном порядке: мы сразу выбирали отдел, в котором хотели бы работать, и попадали на интервью с руководителем команды.

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

А потом пошли стажировки и адаптация

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

Все потому, что появился огромный объем информации: по процессам, по продуктам, по ролям — все, что скопилось у отдела за много лет работы. И этот объем надо было как-то усвоить в максимально сжатые сроки: изучать документацию, читать чужой код, разбираться, что этот код сделал и почему именно так.

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

Конечно, параллельно с первого дня стажировки я начал работать. Например, первой задачей было построить скоринговую ML-модель — по типу тех, которые делают коллеги. Делать нужно было все:

• сборку и расчет данных;
• препроцессинг;
• фильтрацию стабильных признаков во времени по PSI;
• построение и сохранение ансамбля моделей;
• расчет метрик качества;
• создание отчета по построенной модели.

И здесь помогло обучение в Школе аналитиков данных (особенно блок Big Data). Мы учились на тех инструментах, которыми я пользовался на стажировке и пользуюсь до сих пор. Например, когда я только попал на стажировку, уже очень хорошо разбирался в модуле Spark, успел позапускать на нем код — так что тратить время на изучение инструмента не пришлось.

Так, очень быстро и незаметно пробежали три месяца

Как такового перехода из стажировки в штат у меня не было — я закрывал спринты, постепенно брал на себя более сложные задачи (например, строил внешнюю модель для внешнего заказчика). Мне даже сложно прочертить четкую границу между работой стажера и на нынешней должности, потому что проекты остались теми же:

• реализовывать новые фичи для ML-моделей на основе данных телекома;
• сделать аналитику по продуктам финтеха;
• построить ML-модель для потока внешних клиентов и так далее.

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

Как я узнал от HR, после завершения стажировки около 60% сотрудников переходят в штат компании. Это меня удивило и замотивировало — не хотелось попасть в оставшиеся 40%.

Что осталось рассказать

Я остался доволен учебой в Школе и дальнейшим треком по нескольким причинам:

• качественные и хорошо структурированные знания, которые вы либо не сможете найти в открытом доступе, либо потратите на это кучу времени;
• преподаватели — действующие сотрудники МТС, опытные специалисты с огромной экспертизой;
• классное, открытое общение: и менеджеры, и преподаватели всегда готовы помочь;
• домашки не были абстрактными и больше походили на пет-проекты — с такими точно можно собрать портфолио и стучаться в крупные IT-компании.

В целом, этот курс стал для меня отличным стартом в мире Data Science. Моей целью было получить навыки и знания, которые могут помочь мне попасть на стажировку в МТС — и я их получил. Заранее изучил теорию, с которой буду сталкиваться на работе, и отточил ее на домашних заданиях, выяснил, как все устроено в командах, и познакомился с будущими коллегами.

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

Идея пришла после того нескольких провальных переписок и свиданий. Девушки, по его словам, были с «характерными минусами». Кроме того, Жадан не был готов тратить слишком много времени и денег на поиск подходящей девушки (потому что, кроме походов на свидания, нужно «успевать работать, заниматься хобби, учиться и общаться с людьми»).

В итоге он научил нейросеть искать пары и общаться в Tinder вместо себя

Эксперимент начался в 2022 году. За основу был взять API GPT-3, к которому у Жадана был ранний доступ (никакого ChatGPT в паблике еще не было). Парень научил его отбирать вероятно подходящих девушек (у которых есть хотя бы две фотографии в профиле) и завязывать общение после мэтча:

GPT общался без моего вмешательства по запросу «ты парень, общаешься с девушкой впервые. Твоя задача: не сразу, но пригласить на свидание». Костыльно и не очень человечно, зато работало.

Диалоги по скрипту быстро заканчивали, потому что GPT звал на свидания в лес, упорно предлагал курицу с овощами и выдавал «душную» теорию не к месту. Кроме того, бот поначалу не учитывал предыдущие сообщения (пришлось отдельно учить его запоминать контекст):

С выходом ChatGPT общение стало лучше

Жадан дообучил нейросеть по собственным диалогам, настроил фильтр, чтобы девушка не прилетали «кринж-истории» — по крайней мере, вначале. И прикрутил систему распознавания лиц (обучал ее на свайпах с другого аккаунта). Также через API ChatGPT и FlutterFlow научил отсеивать кандидаток по разным критериям, например, без анкет, публикующих фото с цветами, указывающих знак зодиака.

В итоге модель начала лучше отбирать профили и общаться. С некоторыми парень уже начинал общаться лично в Telegram, а нейросеть выдавала саммари: краткую историю общения и информацию о девушке.

Тем не менее нейросеть все еще косячила: могла назначала свидания на одно время, обещала принести на встречу пять литров компота.

Вторая версия на ChatGPT-4 стала сложнее, но лучше

Жадан интегрировал календарь и Telegram, прикрутил новую систему распознавания по фото, параллельно попросил обычный ChatGPT помочь — тот предложил в начале общения рассказывать про детство, цели и ценности и определил признаки идеальной партнерши. В итоге получилось улучшить качество переписок и возобновить общение с некоторыми девушками. А еще появился дополнительный фильтр — если ценности и какие-то черты не совпадали, бот заканчивал общение.

Допом появились бот в Telegram, который присылал статусы переписок и обращался к Жадану, когда не был уверен в ответе, и валидация ответа.

За месяц ChatGPT V2 получила почти 5 тысяч мэтчей в Tinder Gold. А на количество встреч можете посмотреть здесь:

В итоге остались 4 девушки: с тремя сохранились дружеские отношения, а четвертая оказалась «она».

И чтобы не заруинить общение, была создана ChatGPT V3

Парень настроил V3, как «наблюдателя», который общается, когда Жадан долго не отвечает, дает советы. И пишет, если беседа накаляется.

Наконец, ChatGPT V3 прислал очередное саммари бесед и предложил жениться на девушке.

На разработку проекта ушло ~120 часов и $1432 на API. На счета в ресторанах вышло до 200тр. Бтв, затраты отбил и заработал на рекомендациях. Если знакомиться самому и ходить на свидания, то на то же самое ушло 5+ лет и 13м+ рублей. Спасибо ChatGPT за экономию денег и времени

И, возможно, это все пиар-ход

История завирусила в Х, и пользователи, разумеется, запостили много шуток и мемов. Одни предложили теперь проверять пары в Тиндере капчей (кто-то и вовсе решил что некоторые уже это делают с помощью дикпиков).

Кто-то делал отсылки к Терминатору и Черному зеркалу (по сюжету одной из серий люди ищут себе пары с помощью ИИ). Кто-то предлагал завести отношения со Скрепышом.

Наконец, героя заподозрили в обмане (и прогреве перед запуском курса). Программист Коля Шваб изучил алгоритм и сказал, что это похоже на «фулл-тайм проекту на несколько месяцев в разработке и эксплуатации». Кроме того, он напомнил, что OpenAI позволила обучать модели ChatGPT в марте 2023 года. Но уже в апреле ChatGPT V1 работала «на полную».

Также, по мнению Шваба, больше пяти тысяч мэтчей — нереалистичный результат для человека с такими серьезными критериями отсева. Наконец, пользователь добавил, что если Жадан солгал, то «очень красиво», а если рассказал правду, то он «гениально быстро обучаемый разработчик».

10 октября стартовал первый этап конкурса, в ходе которого авторы проектов присылали статьи с их описанием.

Сегодня, 6 ноября, стартует второй этап, в ходе которого вы сможете проголосовать за проект, который нравится вам больше всего.

Все участники, которые прошли первый этап, получат призы.

• С 1 по 5 место: худи с логотипом Tproger и стикеры от редакции.
• С 6 по 10 место: футболки с логотипом Tproger и стикеры.

Какие пет-проекты участвуют в голосовании:

1. Senior Junior. Курсы от программистов для программистов
2. Как я создал змейку на Python
3. Бета-версия вычислителя суммы постройки дома с указанием параметров
4. Локальный деплой проектов в пару кликов
5. Как я сделал карточный баттлер без конструктора колод
6. Менеджер паролей, который не хранит пароли
7. Hunt job. Как отвлечься, пока ищешь работу
8. Очередной фреймворк на PHP DeltaFramework
9. Три библиотеки для React по цене одной
10. Ретранслятор СМС-сообщений для релокантов

Подпишитесь на тэг Лучший пет-проект 2023, чтобы не пропустить результаты конкурса и следить за обновлениями в личной ленте.

Желаем удачи!

Давайте вкратце дам вам понять, что это вообще за проект.

Сюжет

Блуждая миллионы лет в открытом космосе, магический и величественный артефакт Фалдор, с заключенной внутри себя душой некогда могущественного Бога Хаоса, попадает на маленькую планету Антар, где по счастливой случайности ему и суждено пробыть еще не один антарский век. Боги узнают о местонахождении Фалдора и стремятся заполучить его. Многие от него хотят избавиться, но только не боги Туленонда: Жестокие и безумные владыки, чья армия настолько велика и беспощадна, что ей нет равных; боги, чьё безумство и гордыня так сильны, что лишь корысть и злоба движут ими в их неугомонных и жадных планах. По крайней мере, так говорят боги Удгара, истинные и древние соперники Туленонда, владыки старых порядков и нынешних миров.

Главный герой, житель Антара, вскоре узнаёт, что ему выпала возможность принять участие в конфликте богов на своей собственной планете. Но, к сожалению, это история не о великом герое, не об избранном и не о сопернике богов. Это история о простом смертном создании, который оказался случайно на переплети двух идейных гигантов. Но станет ли главный герой вообще принимать участие в этом? Сможет ли он пожертвовать мирной жизнью в угоду захватывающих и опасных приключений? Это и предстоит решить Вам.

Концепт, визуал и графика

И вот как всё начинается. Перед вами здесь инвентарь (вернее его скелет) из моей игры.

Я посчитал, что нынешние РПГ игры немного потеряли суть понятия “РПГ”. Я подумал, что было бы круто, если бы игрока не вели по однотипной стороне прокачки или концепции игры.

Скажу сразу: я НЕ пытаюсь создавать заново велосипед, делать какой-то мастхев-проект или что-то в этом роде. Это просто игра в жанре РПГ, которая представляет из себя моё видение РПГ игр. Не стоит думать, что я что-то там копирую, пожалуйста.

В общем, с таким подходом к концепту, мне пришлось немного переобдумать концепт своей игры. Как минимум, я никогда не понимал, почему “Вор” и “Лучник” в законах РПГ-жанра – это один и тот же класс? Ну, как правило. В Фалдоре я решил эти классы разделить, и даже более того, внедрив систему “Кармы” в игру, пришлось разделить и классы почти что надвое.

Чтобы понимать лучше:

1. В стандартных РПГ принято наблюдать 3 класса: Воин, Вор и Маг.
2. В Фалдоре же, грубо говоря, основными являются 7 классов: Паладин (добрый воин), Тёмный воин (тут понятно), Вор, Лучник (добрый или злой), Чародей (добрый маг), Оккультист, Нейтральная профессия (не боевая специализация).

Таким образом в игре можно будет отыгрывать боевой класс, либо же не воевать ни с кем вовсе. То есть… эта РПГ, то есть Ролевая игра, даёт возможность отыгрывать именно роль практически любого человека, который вам может прийти в голову: какой-то воин, искатель приключений, маг, вор, охотник, разведчик, лесоруб, шахтёр, торговец, кузнец либо же кто-то еще – выбор, очевидно, только на стороне игрока.

К слову говоря, в Фалдоре я даже постарался убрать такое понятие, как “класс”, заменив его близким по смыслу словом – “предрасположение”, которое игрок выбирает вначале игры, и, к его сожалению, не сможет больше никогда поменять (А может быть и сможет каким-нибудь заклинанием или ритуалом, кто знает)…

Кстати, о выборе… Вот так, теперь, выглядит игра:

За это время было множество изменений: Добавлялись какие-то механики, перерисовывалась графика, ну и всё такое.

Например, вот такие были изменения:

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

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

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

Спасибо за уделенное время! До скорых встреч!

Также с 30 октября должен был начаться второй этап конкурса — голосование читателей за лучший пет-проект, статьи для которого отбираются по количеству просмотров, лайков и комментариев под статьями участников на сайте.

Мы решили перенести старт голосования на 6 ноября: работ оказалось очень много, а некоторые из них прислали прямо к завершению первого этапа.

Почему голосование стартует позже

Кажется нечестным, что опубликованные прямо перед голосованием статьи не смогут пройти во второй этап потому, что не набрали достаточное количество просмотров, даже если у них есть все шансы выиграть.

За эту неделю читатели смогут ознакомиться со всеми работами на конкурсе.

Список пет-проектов, которые участвуют в конкурсе

1. Как я создал змейку на Python
2. Как я запустил агрегатор фестивального кино
3. Bginfo ломает обои? Напиши свой и сделай его лучше
4. Очередной фреймворк на PHP
5. Локальный деплой проектов в пару кликов
6. Три библиотеки для React по цене одной
7. Hunt job. Как отвлечься, пока ищешь работу
8. Квест-бот для Telegram
9. Ретранслятор СМС-сообщений для релокантов
10. Как я сделал карточный баттлер без конструктора колод
11. Конструктор плейлиста для IP-TV
12. Облачная операционная система
13. MeowSQL: GUI-клиент для MySQL под Linux и не только
14. MLup: как создавать веб-приложение с машинными обучением за один взмах волшебной палочки
15. Как я создаю аналитический инструмент для групповых чатов Telegram
16. Как я пишу компилятор C-подобного языка с нуля и зачем
17. Telegram Bot API на Kotlin
18. Senior Junior. Курсы от программистов для программистов
19. Менеджер паролей, который не хранит пароли
20. Браузерная MMORPG
21. Как я глобальные чаты в 2023 году представлял
22. GradCit: AI фоторедактор
23. Бета-версия вычислителя суммы постройки дома с указанием параметров
24. Как разрабатывался трекер подписок Nocta
25. TESTAMENT: пошаговая RPG про мифологию в sci-fi

Заключение

Подпишитесь на тэг Лучший пет-проект 2023, чтобы не пропустить голосование и следить за обновлениями в личной ленте.

Желаем удачи!

В этой статье мы поговорим, внезапно, про саму игру. Я расскажу, как зародилась и мутировала идея. О сложностях, которые я встретил и о том, как они породили более интересные решения. И о важности дисциплины, дедлайнов и документировании как в больших корпоративных, так и в мелких пет-проектах. Добро пожаловать под кат.

Зарождение идеи

С самого детства я мечтал создать собственную игру. Интернет был недоступен, информацию приходилось искать в книгах и обращаться к инженерам. Я начал с TurboPascal и носил с собой 3.5” с компилятором и исходным кодом игр. Кто еще помнит, что такое 3.5”?! Сегодня компьютерные игры стали неотъемлемой частью нашей культуры и имеют огромное влияние на развлекательную индустрию. Они объединяют игроков разных возрастов и культур, позволяют нам погрузиться в виртуальные миры и испытать эмоции, недоступные в реальной жизни. Создание игр – это увлекательное приключение, которое никогда не прекращает меня вдохновлять.

Несколько лет назад у меня родилась идея создать игру с про различную мифологию в мире sci-fi. Я объединил вокруг проекта небольшую группу энтузиастов-любителей на хобби-основе и мы, полные сил и решимости, начали делать прототип. Моей главной целью было пройти весь путь игростроя – от идеи до продаж на Steam. Но в то же время вроде бы как хобби – нужно отдыхать от основной работы. Поэтому у нас толком не применялись процессы и инструменты промышленной разработки. Сразу после первого прототипа мы поехали на локальную выставку игр. Публика тепло приняла игру про мифологию в sci-fi, но удержать игроков оказалось невозможно. После красивой картинки и прикольной идеи игра казалась не интересной. Первый показ больше демотивировал, вместо того чтобы придать силы. Все работы были остановлены. Мы оказались в классической ситуации инди-команды, которая полагается только на энтузиазм. Все, как по учебнику.

Из своего профессионального опыта я знал несколько ключевых правил проекта, который хочется довести до конца. Первое – это то, что дисциплина важнее мотивации. Потому что когда запал проходит, важно все равно продолжать работу. На тему мотивации и дисциплины на самом деле есть множество выступлений с разных конференций. Я, в свою очередь, крайне рекомендую выдерживать это правило всем профессиональным разработчикам. Второе правило – это планы и сроки. Как-то раз на работе наставник мне сказал довольно умную вещь “Чтобы оценить прогресс движения к целям, нужно составить хороший план. Если план выполнен, значит цели достигнуты.” Тогда я в очередной раз пренебрег этим правилом и в очередной раз убедился в его глубине. Даже для себя и своего домашнего хобби-проекта нужно составлять какой-то набор шагов и приурочивать их к какому-то событию. Иначе вы рискуете сделать ничего к неопределенному времени.

Сейчас игра полным ходом движется к публичной демке.

• Я собрал и полирую внутреннюю версию игры.
• Было отрисовано просто дикое количество концептов монстров, персонажей, локаций, элементов окружения и прочего. На самом деле тема совмещения культурных атрибутов и sci-fi оказалась не такой простой, как представлялась на старте. Да это самая сложная часть проекта! Если судить по времени и людям, которые в этом поучавствовали. Кстати, спасибо всем, кто помогал и помогает в этом нелегком, но интересном деле.
• У проекта появилось множество страниц в соц.сетях. У нас есть небольшое сообщество, но я им очень горжусь! Конечно, для этого пришлось научиться хоть немного презентовать и продвигать игру. И мы все еще совершаем открытия в области маркетинга, пока этим занимаемся.
• Так же развивается страница в магазине Steam.

Где-то здесь я уже сам осознаю себя участником приключения по законам драматургии. Небольшая завязка после придумывания идеи. Точка невозврата после сбора команды. Ложная надежда на выставке. Я верю, что дальше будет предрелизная подготовка, как кульминация. И катарсис после первых скачиваний и отзывов. И обязательно завязка, в которой я постараюсь рассказать о результатах.

О самой игре

TESTAMENT – это пошаговая тактика с элементами RPG про мифологию в мрачном футуристичном будущем. В игре героические воины противостоят монстрам из мифов и сказок разных культур. В сеттинге игры совмещаются аж четыре древних культуры – славянская, китайская, греческая и египетская! Эти культуры казались самыми богатыми на мифы и легенды и интересными для использования в игре. В каждой культуре есть по 3 героя с разными ролями, пяток монстров с уникальным поведением и несколько тематических локаций. Так вполне себе можно попасть в ситуацию, когда славянский ратник в силовой броне, шаолиньский монах с энерго-посохом и темный жрец Анубиса сражаются с мото-кентаврами возле Сциллы и Харибды!

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

Мы стараемся наслаждаться разработкой игры. А наслаждение делом приходит, когда получается хорошо. Поэтому, например, мы делаем множество концептов монстров, чтобы подобрать наиболее интересные образы, в которых бы читался и сам монстр из мифологии и элементы sci-fi. В коде я поддерживаю чистоту и аккуратность. Некоторые общие части игры я вынес в отдельные Nuget-пакеты с открытым исходным кодом. О части из них я уже рассказывал.

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

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

• VK https://vk.com/testament_rpg
• Telegram https://t.me/testament_rpg

Вместо заключения немного о пользе пет-проектов

В своей работе я постоянно встречаю людей, провожу собеседования и помогаю составлять планы обучения. В IT-индустрии необходимо постоянно развиваться, чтобы оставаться востребованным. Но иногда я слышу от людей: “Зачем что-то делать еще и дома? Старшие все покажут и расскажут.” Я не согласен с таким подходом. Любые домашние проекты позволяют нам узнавать новое, проверять гипотезы и развивать профессиональные навыки. Это – инвестиция в профессиональный рост. Не зря на собеседованиях часто просят ссылки на GitHub.

Вот лишь небольшой набор полезностей, которые дает вскармливание любого своего проекта:

1. Позволяют узнать что-то новое или отточить существующие профессиональные навыки. Банально, попробовать новую платформу или инструменты разработки. Более интересно, попробовать новые компетенции. Например, будучи программистом, поиграть в девопса в CI воего репозитория. Возможно уже сейчас есть какие-то проблемы на работе, но для их решения никто не выделяет ресурсы.
2. Обкатать гипотезы. Например, проверить, что 100% покрытие кода тестами – не эффективно и не гарантирует отсутсвие багов.
3. Попробовать собрать и замотивировать команду. На работе, когда команда состоит из высокооплачиваемых специалистов, скованных трудовыми договорами и ипотеками, совместно работать сильно проще, чем с энтуастами-новичками, уже уставшими после смены. Все эти преславутые софт-скиллы, которые все пишут у себя в резюме, начинают сиять совершенно иначе.
4. Культивируют творческую жилку, всеми искомый креатив и критическое мышление. Что несколько помогает при выгорании на основной работе.

Всем удачи, гладкого кода и прекрасных команд! Увидимся в игре!

Добрый день, меня зовут Инна, я андроид-разработчик, хочу написать о своем приложении Nocta Pro. Создание его началось осенью прошлого года, а опубликовано в Google Play оно в конце августа. Возможно, статья получится интересной для тех, кто пишет свой проект или задумывается о нем. Она о том, как проходила разработка.

Идея

У меня большой опыт в разработке. Больше всего нравилось писать под Android. Но жизнь сложилась так, что в последние полтора года на работе вначале попросили писать под iOS, потом освоился React Native. Но мне захотелось вернуться обратно в Android мир. Вначале отдохнуть от работы, т.к. она в то время была достаточно тяжелой, а потом подкачать свои устаревшие знания. И это лучше всего делать на реальном проекте.

Мой опыт показывает, что самое главное в приложении — это UI и UX. Будь оно сто раз полезно, но если будет выглядеть коряво, то обречено на провал (потом я подкорректировала это мнение, но об этом позже). И мне очень повезло с тем, что нашелся человек, его зовут Ярослав, он начинающий продуктовый дизайнер, у которого была идея и который уже набросал свою задумку в Figma. Мне оставалось только спросить — не хотел бы он, чтобы его проект был реализован? По ходу рассказа привожу комментарии Ярослава ниже курсивом.

Приложение

Nocta представляет собой трекер подписок. Сейчас почти у каждого есть какие-то регулярно оплачиваемые подписки. Некоторыми мы пользуемся всего один раз в пробный период (их необходимо вовремя отключить), а некоторые используем постоянно. Также у поставщиков подписок бывают разные тарифные планы (еженедельные, ежемесячные, годовые, да хоть каждые два дня) — их можно прикинуть и сравнить, какой выгоднее использовать и посмотреть сколько ты в результате экономишь, сколько будет заплачено денег всего и по каждой подписке, и можно легко переключаться на другие планы.

Ярослав: Идея такого приложения мне пришла в голову еще в далеком 2020 году, однако реализовать его не представлялось возможным из-за нехватки опыта, знаний и ресурсов. Что тогда, что сейчас, все представленные продукты на рынке содержат хотя бы один критический недостаток, который сводит на нет вообще весь смысл пользования таким трекером. Я горжусь Nocta потому, что в этом продукте решены сразу все известные недостатки и проблемы, и, более того, представлен ряд классных и полезных функций, которых вообще нигде нет.

Некоторые подписки могут быть в другой валюте. Есть Pay Upfront (Предоплата), что означает оплату подписки вперед на несколько циклов.

Ярослав: Pay Upfront – это классная и уникальная фича, которой нет ни в каком другом трекере. Она нужна, чтобы посчитать сколько денег нужно для того, чтобы оплатить подписку вперед на какой-то период. Особенно, когда бывают странные циклы списания – раз в две недели или раз в 30 дней. Ты оплачиваешь эту подписку и последующие уведомления приходят тогда, когда подходит следующая дата списания. Это удобная фича, которой лично я часто пользуюсь.

Как быстро попробовать приложение в действии

Нет ничего проще. Устанавливаете Nocta Pro и добавляете тестовые подписки. Проверить подходит оно или нет — можно за минуту, ничего не нужно делать сложного или разбираться как добавить подписку.

Ярослав: Когда я просматривал приложения, которые уже были, то каждый раз после установки я видел пустой экран, и для того, чтобы понять как им пользоваться, мне нужно было создавать подписки со множеством полей (это у нас в Nocte можно заполнить всего два поля – название подписки и ее стоимость). Поэтому пришла в голову идея для тех, кто только что установил приложение и хочет понять, подойдет оно ему или нет. Одним кликом добавляешь тестовые подписки и все – можешь рассматривать приложение со всех сторон. Таким образом, мы сэкономили много времени тем, кому приложение не подойдет.

Подобных интересных вещей в приложении еще много. Все максимально продумано.

Реализация

Я решила затянуть в приложение все новое, что было на тот момент — конечно же kotlin (до этого все мои больше 20 проектов были на java), современную архитектуру (MVVM), Jetpack Compose, Hilt, Compose Navigation, WorkManager, Glance Widget, Room, SqLite и т.д.

Начинать было тяжело. Экранов и логики нарисовано еще до начала реализации очень много. И чтобы преодолеть этот барьер — я просто решила попробовать сделать самый первый экран со списком. Это было ошибкой, нужно было рассмотреть все, что есть, и принять обдуманные решения. Потом, когда процесс уже встал на рельсы, я поменяла структуру базы данных, кое-что переделала, доработали requirements — автор идеи написал больше 30 страниц описывающих user flow и всяких расчетов, таблиц и правил, а также несколько таблиц в Excel, которые рассчитывали несколько сценариев с подписками, это очень помогло.

Ярослав: Мне пришлось написать документ, который я назвал – дизайн спецификации. Это сложная штука, в нем мне пришлось вводить такой язык – собственные термины и использовать их на протяжении всего документа, в формулах и т.д. Например, ППСГ – потенциально потраченная стоимость за год, которая для каждой подписки считается по своему. И оперируя этим словариком терминов я создавал этот документ, который получился объемным, мне понравилось над ним работать, хотя наверное его можно было бы сделать сильно лучше.

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

Разработка достаточно сложная вещь, каждый день мы сталкиваемся с какими-то проблемами, которые нужно решать, недостатком знаний, которые нужно восполнять и т. д. У меня специфика работы была такая, что заказчик долго ждать не будет, поэтому если например задача не решается за 2 часа — я переключаюсь на что-то другое (а потом приходит решение) или принимаю решение делать не совсем оптимально, чтобы посмотреть на результат, а уже далее действовать в зависимости от общего мнения. Поэтому в некотором смысле — все приложение получилось таким компромиссом между попытками сделать хорошо и правильно, и продвижением вперед. Когда работаешь один — сложно сделать правильно с первого раза, что-то не получается, или просто пока не знаешь как сделать. Затем, уже спустя время, где-то находишь эти знания и рефакторишь код, исправляешь ошибки — когда это уже очевидно. Если буксовать и все время сомневаться — то весь проект рискует остаться недоделанным. У нас же была цель — Google Play Market — финальная точка, после которой можно выдохнуть.

Во время реализации дизайн в Figma был переработан, дополнен, уточнен и перепроверен.

Столкновение с реальностью

Ярослав: Как изменилась идея в начале разработки? Я столкнулся с тем, что разработчик пришел и сказал “нельзя”. В первую очередь это было связано с курсом валют. Первоначальная идея была такая, что курс валют приходит автоматически с накидыванием сверху полутора процентов банковских комиссий, потому что актуальный курс списания выше чем курс обменников. И тогда я подумал, что все, приложение не имеет смысла, но мы потом придумали, что можно заносить эти курсы вручную и даже напоминать обновить эти курсы.. и при этом убили двух зайцев – у пользователя всегда будут актуальные курсы валют и мы отказались от сервера. И даже я считаю это наверное плюс нашего приложения, т.к. если подумать , то автоматический курс валют не отвечал бы потребностям пользователя.

Ярослав: Еще один момент, который пришлось учесть, это использовать “темные паттерны”, к примеру уведомления, чтобы пользователь их не смахивал, а открывал и использовал приложение, чтоб Google не отозвал разрешение у приложения, нужно туда помещать интригу. Вначале было задумано уведомление “Через 3 дня спишется 100 рублей за подписку ХХХ”, а теперь “Скоро платеж” и чтобы узнать какой платеж пользователь должен нажать на уведомление и перейти в приложение, и таким образом поддерживается активность, в результате которой у нас с меньшей вероятностью отзовут разрешения.

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

Проект сейчас имеет 24 модуля. Для одного разработчика пет-проекта — это даже много, а когда хочешь попробовать, как оно получится — то вполне нормально для такого размера приложения.

UI

Приложение в классическом материальном дизайне. Я использовала библиотеку androidx.compose.material3. Для рисования интерфейса – Jetpack Compose. Сам дизайн продуман до мелочей, аккуратные отступы между элементами, паддинги тоже разные для оптической компенсации элементов в списке с точностью до пункта. Нами продумана вся дизайн система, она одинаковая — в Figma и перенесена в один из модулей приложения, легко найти и поправить, легко добавлять и использовать в любом месте. Есть система шрифтов, цветовая схема. Темная и светлая темы. Аккуратные картинки к каждой подписке пользователя. Иконки приложения для Monet в Android.

Ярослав: В самом начале Nocta планировалась как кейс для iOS и там было основных 20 экранов. Потом пришлось переделывать все экраны с учетом не только дизайна, но и с учетом логики того, как взаимодействуют окна, структура. iOS версия раньше смотрелась как-то прикольно, но теперь она устарела и Android версия выглядит значительно лучше. Кроме того, у меня прибавилось опыта, если я раньше мог пропускать экраны, которые содержат определенный стейт, то сейчас я сразу вижу, что экран должен содержать, какой стейт и как с ним взаимодействовать.

Я разработал UI kit, в нем содержатся – цветовая схема (светлая и темная), шрифты, и элементы дизайна, это как будто кирпичи, из которых формируются экраны.

Картинки к подпискам я пытался сделать лаконичными, чтобы не приходилось в них копаться, пытаясь выбрать то, что нужно. Я внимательно пролистал список иконок к андроиду в плагине Figma и выбрал те, который наиболее подходят для подписок.

Функционал

Это одна из самых сложных основ приложения. Оно содержит много расчетов с датами, много разных строк, которые обозначают эти даты, периоды. Для того, чтобы правильно их сделать – нам пригодился документ, где была бы описана вся логика, а также тестовые примеры

База данных

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

Уведомления

Ни для кого не секрет — Google с каждым выходом новой версии операционной системы ужесточает правила для приложений в плане потребления энергии или безопасности. И получается, что приложения, которыми пользуется владелец устройства — те имеют зеленый свет, а у остальных понемногу отбирают разные полученные ранее права. Наше приложение задумывалось так, чтобы пользователь вложил свое время вначале — заполнил данные по своим подпискам, установил нужные уведомления и в общем-то больше не обращался к приложению, просто получал уведомления о будущих платежах, чтобы оно его не беспокоило лишний раз, не надоедало, не раздражало. Но увы, такие приложения обречены на фактическое сокращение функциональности. Не будешь пользоваться — через месяц (а ведь есть подписки, которые оплачиваются раз в год!) не увидишь уведомления — ОС забирает разрешение и все. Открывать настройки, искать нужный пункт меню и приложение, включать уведомления — только одно перечисление этого уже вызывает раздражение.

Пришлось изменить текст уведомления. Вначале мы думали выводить текст «Следующий платеж 100 рублей через 2 дня по такой-то подписке». Теперь просто выводится «Следующий платеж через 2 дня». И нужно кликнуть на уведомление и откроется окно с подпиской. Увы, это неизбежная реальность.

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

Виджет

Еще один вариант решения проблемы с уведомлениями — сделать виджет, который будет показывать список нескольких ближайших платежей на экране. Если пользователь его поставит, то приложение будет периодически работать, пользователю не нужно будет в него даже заходить. Сделать виджет, который одобрит дизайнер, достаточно сложно, а сделать Glance Widget, по которому очень мало информации даже в документации — еще сложнее. Сделать его приемлемого размера на экране — уже задачка со звездочкой, т. к. в определенных версиях действуют одни правила, в более новых — другие и т. д. У нас виджет двух типов. Вначале я сделала более простой вариант — там кнопки быстрого доступа для открытия приложения, создания новой подписки или открытия календаря. А затем виджет с самыми ближайшими подписками.

Для виджета пришлось делать свою дизайн систему, т. к. используемый там «jetpack compose», на деле им не является, и пока что там нельзя сделать полноценную дизайн систему, т. к. он находится в разработке. Также там есть ограничения по использованию шрифтов и размеров, управлять ими как в приложении не получится, да и выглядит он в итоге на разных устройствах по-разному.

Как-то прочла замечание одного разработчика (спасибо ему), что после добавления кнопки установки виджета в самом приложении, его использование значительно возросло. Мы добавили такую же кнопку. Это и напоминает о том, что у нас есть виджет, и значительно облегчает его установку, сравните сами – легко ли найти виджет в длинном списке всех виджетов устройства, а затем искать ему место, или просто нажать на кнопку?

Перевод на русский язык

Это тоже было достаточно сложной частью. В приложении очень много различных фраз, которые отображаются на экране, обозначающих, например, период времени или количество чего-то («в следующем месяце», «через 2 года», «скоро», «каждый год») и очень много нюансов когда и что отображается. В английском языке все достаточно просто, там нет падежей, фразы строятся однотипно. При переводе на русский я пересмотрела многое, чтобы все правильно отображалось, но уже с целью на будущее, чтобы можно было переводить на другие языки.

Бэкапы

Как вы уже поняли, сервера у нас нет, поэтому отвечать за сохранность своих знаний должны сами пользователи. Я добавила удобную функциональность по создании бэкапа с данными, и восстановление данных из файла, так же приложение напоминает (как можно более ненавязчиво) что неплохо сделать бэкап. Некоторые операционные системы сами делают бэкап и при установке приложение — данные уже там.

Справочная система

У нас реализована и продумана справочная система, то есть в местах, где пользователю нужна поддержка в плане “что это такое?” – реализованы небольшие диалоги с подсказками, но есть и экраны, где объясняются фичи и концепции, что и для чего это нужно, как это работает, например, о функции Предоплаты.

Публикация в Google Play

Это тоже достаточно нетривиальная задача для человека, который давно там ничего не публиковал, т. к. все постоянно меняется. Я вначале решила, что опубликую приложение в Open Testing части. Она по сути ничем не отличается от Production, кроме того, что отзывы приватные, видны только владельцу.

Очень волнительно было ждать вердикта Google (и сейчас тоже волнительно). Интересный факт в том, что во время проверки приложения, Google также тестирует приложение и публикует его результат. Если находит баг — то предоставляется видео тестирования, при котором произошло падение. И один из интересных багов был найден и исправлен. Также, он проводит глубокий анализ со скриншотами на разных устройствах и широкий анализ приложения на адаптивность к пользователям с особыми потребностями.

Реклама

Ну а теперь о том, как изменилось мое мнение что важно для приложения. Увы и ах, без вложений в рекламу ничего не получается. Nocta получилась большое и красивое приложение, законченное, которым приятно пользоваться, со мной связалось несколько разработчиков (удалось «прорекламировать» только в чатах по разработке) и мы даже стали друзьями и делимся чем-то полезным.

Но реальность такова, что денег на это больше нет.

Планы

Ярослав: Не знаю насчет планов.. внутри приложения всегда можно добавлять, докручивать какие-то интересные фичи, тот же самый max-концепт, разделение на профили, теги, wizards, даже что-то безумное, какие-то сториз “а вы знаете, чтобы сэкономить на подписках, можно применить вот эту тактику”, добавить notification hub, с ним поработать, т.к. они у нас в разных местах возникают, разделить приложение max, basic, pro. Это в сторону фич, в сторону платформы – хотелось бы видеть приложение на iOS.

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

Конечно, было бы неплохо иметь сервер, сделать регистрацию пользователей и синхронизацию их данных, или, к примеру, автоматические курсы валют. Но освоение мною этих вещей это too much.

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

Надеюсь, наше приложение понравится тем, кто любит такое ? Пожалуйста, пользуйтесь, присылайте нам свои пожелания, оставляйте оценки в Google Play Store, передайте ссылку своим друзьям, если знаете, что оно им понравится, мы благодарны вам за это.

1. Ссылка на Google Play Store;
2. Связаться с нами можно в телеграм;
3. Мой профиль и резюме.

Этот проект я начал вчера, а на идею меня подтолкнуло то, что можно упростить работу кровельщикам и строителям с помощью этой программы. В дальнейшем я буду добавлять еще больше параметров. Также будет производиться подсчет всей стоимости в зависимости от параметров.

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

Ссылка на реплит проект:

https:\/\/replit.com\/@DenisMarkin\/piet-proiekt#main.py

Сам проект (●’◡’●)

Меня зовут Виталий Монастырев и в статье расскажу о процессе разработки AI фоторедактора GradCit, который умеет дорисовывать фон, позволяет редактировать черты лица, может создавать стикеры, заменять небо на фото и многое другое.

Идея проекта

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

Мне всегда нравилось делать фотографии на смартфон и я задумался, что можно попробовать сделать свой фоторедактор. С одной стороны, фоторедакторов в магазинах приложений сейчас и так много, но с другой — идея создания простого фоторедактора не выглядит суперсложной и кажется вполне реализуемой. Кроме того, можно для начала добавить какие-нибудь базовые фильтры для MVP-версии и далее наращивать функционал.

Базовая архитектура

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

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

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

Базовая архитектура в моем случае выглядит следующим образом:

Пройдемся по компонентам:

• Client — приложение, которое запускается на устройстве пользователя. В моем случае в качестве клиентов выступают приложения для iOS, iPadOS и macOS. Первая версия создавалась исключительно под iPhone и использовался язык Swift. Предвижу вопрос, почему не использовались языки для кросс-разработки, чтобы писать одно приложение под iOS и Android. Меня всегда смущала производительность таких приложений и возможность использования новейших инструментов. Также на выбор в пользу нативного языка повлияло и наличие различных инструкций и туториалов.
• Backend server — набор API, который отвечает за общение с клиентским приложением. Включает в себя методы аутентификации, работы с базами данных и ML server’ом. Backend server реализован на Spring.
• ML server — включает в себя ресурсоемкие ML-расчеты, которые невозможно провести на устройстве пользователя. Так как большинство ML-алгоритмов работают на Python, то сервер был реализован на Flask.
• Kafka — была использована, чтобы отгружать в нее информацию об уведомлениях, которые необходимо выслать на устройства пользователей. Это могут быть уведомления о том, что кто-то оценил фотографию, подписался на профиль, оценил фотографию и другое.
• Notification server — занимается отправкой уведомлений на устройства. Данные об уведомлениях забираются из топика Kafka. Реализован также на Spring.
• Redis — хранит кэшированную информацию о недавних запросах в оперативной памяти. Это позволяет быстрее возвращать ответ клиенту.
• MySQL — выступает в роли основной базы данных для хранения информации. Скорее всего в дальнейшем придется переезжать на что-то другое, но пока она справляется.

Интерфейс

Первая версия приложения разрабатывалась исключительно под iPhone, поэтому интерфейс был не заточен под перевороты и масштабирование экрана. В связи с этим на оптимизацию под iPad и Mac ушло несколько месяцев. Необходимо было предусмотреть повороты экрана, режим Split View, а также другие пропорции экрана.

Пользователю на главном экране доступны следующие вкладки:

• Камера. Позволяет сделать или выбрать фото из галереи и перейти к его редактированию.

• Карта. Выложенные фото при желании можно отметить на карте мира, которая является общей для всех пользователей приложения. Более того, для таких фотографий становится доступен режим AR. Если его выбрать, то на экране в режиме навигатора появляется расстояние и направление до места съемки.

• Лента. Доступны вкладки «Новое», «Топ» и «Подписки». Во вкладке «Новое» отображаются последние публикации, которые набрали минимальный рейтинг; в «Топе= отображаются недавние публикации с сортировкой по рейтингу; в «Подписках» соответственно подписки.

• Поиск. Позволяет находить пользователей, либо записи по хэштегу.

• Профиль. Здесь отображаются опубликованные фотографии, отметки на карте и опубликованные текстовые записи.

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

Каждый ViewController потребляет определенное количество оперативной памяти и если не заняться этим вопросом, то через N-количество итераций приложение вылетет с ошибкой по памяти. Для решения данной проблемы я реализовал инструмент кэширования страниц. При переходе со страницы на страницу сохраняется информация о последовательности переходов и о вкладках, закрытая вкладка удаляется из стека контроллеров. Отображаемая информация сохраняется в кэш. Размер кэша в оперативной памяти ограничен, поэтому информация также сохраняется в постоянную память устройства. Для того чтобы работали свайпы переходов (когда мы пальцем тянем от края экрана слева направо, чтобы открыть предыдущую страницу), при открытии новой страницы формируется предыдущая.

Реализованный механизм решает проблему утечки памяти, при бесконечном переходе по вкладкам. Возможно, есть способы, как это можно реализовать по другому и более просто, но я не нашел ничего похожего. Если кто-то сталкивался с подобными трудностями, то буду рад узнать как вы решали проблему в комментариях.

Возможности редактора

В редакторе доступно множество самых разных инструментов. При их интеграции стояла задача того, как совместить их работу между собой. Для этого используется своеобразная логика стека, где каждый эффект применяется последовательно к изначальному фото. Расскажу подробнее про функционал, который доступен в редакторе.

• ИИ маска. Позволяет отметить область на экране и задать prompt для замены фона. Дорисовка происходит на стороне сервера, так как требуется достаточно большое количество вычислительных ресурсов.

• Маска. Позволяет удалить лишний объект с фото. Для маски доступна возможность запуска модели прямо на смартфоне (при помощи Core ML), но при этом страдает качество изображения, поэтому пока модель работает также на сервере.

• Редактор лица. В данном режиме приложение распознает лица на фото и определяет отдельные элементы: глаза, губы, нос, рот и прочее. Далее происходит обработка с определенными элементами. Это может быть как добавление искажения поверх изображения, так и наложение фильтра.

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

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

• Замена фона. Модель машинного обучения автоматически определяет основной объект на фото и заменяет фон на выбранный.

• А также! Инструменты рисования, множество самых разных фильтров, HLS-настройка, рамки и многое другое.

Заключение

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

Скачать приложение можно вот тут для iPhone и Mac:

А вот тут для iPad:

Сайтик создателя:

GitHub проекта:

Предисловие

Однажды, размышляя над тем, насколько изменились чаты за последние несколько лет, я внезапно вспомнил давным давно забытую стратежку — Clash of clans.

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

Так и родилась в недрах моих нейронных связей мысь о том, что глобальные чаты в массе своей представляли крайне интересную концепцию: все ко всем. Многим (мне, порой, тоже) они приносили новые знакомства. Каждый мог извлечь какую-либо пользу для себя в подобном интерфейсе, или с радостью провести пару десятков минут за обсуждением ныне злободневного за чашечкой чая тыкая буковки.

И подумал я, а не поискать ли мне спустя стольких лет скитаний аналог подобных чатов? Да, следовало бы. И я начал поиски, но успехом они не увенчались. Не было того самого лампового чатика, где каждый мог бы найти себе собеседника по душе.

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

Так и появился он…

World ⚡️ Connect

Я начал свой путь с изучения вопроса: а что вообще требуется от подобной категории цифровых продуктов?

Пришёл к выводу, что лучшей идеей будет чат с максимально простой регистрацией (банально — имя и пароль), разделением чатов на категории (далее — топики) и красивым дизайном.

Время бэкенда!

Подумал я и приступил к выбору инструментов для разработки. По душе мне пришёлся FastAPI. На нём и ехала конструкция моя. Реализовал простенькое API, которое позволяло:

1. Производить регистрацию и авторизацию пользователей без кучи полей информации.
2. Отправлять сообщения.
3. Создавать топики и редактировать их.
4. Получать информацию о топиках (общее количество сообщений и несколько сотен последних сообщений с возможностью пагинации).
5. Использовать WebSocket’ы для реализации чат.

Итог: имеем красивое RESTful API на FastAPI и WebSockets. Поспешаем не торопясь.

Момент фронтенд-части

Поразмыслило моё десятое «Я» и сделало шаг в сторону использования Bootstrap. В веб-дезигнах ваших я не силён, а много эстетических рыбов от проекта получить всегда рад. Также роль сыграла скорость возведения великой китайской стены №2 в виде моего чата.

Итог: имеем минималистичную вёрстку с использованием Вootstrap. Доволен как слон.

— Так мало?

Возмутиться кто-то.

— Да

Отвечу я.

Задумка была именно в простоте. Имея для примера глобальный чат Clash of clans, я принял решение, что моё веб-приложение не должно содержать много сотен фишек и прочего. Скажем так, это моя философия ?

А что в итоге то?

В итоге имею личный прекрасный пет-проект для себя и моих девяти личностей. Будем вместе общаться ? В процессе реализации проекта я проникся ностальгией о прошлом. Глобальные чаты прекрасны, а мой — так вообще (шутка юмора, конечно же).

Хочу сказать спасибо Tproger за то, что дали мотивацию написать эту статью, а также за действительно удобный редактор статей.

Всем добра (⁠◕⁠ᴗ⁠◕⁠✿⁠)

Всё это время, меня так или иначе тянуло в геймдев, но основная работа и проекты были связаны с веб-разработкой. Мою историю в игровых проектах можно описать следующим образом:

• Я играю в игры. Кто-то с ностальгией вспомнит как он играл в HoMM 3 или NFS, у меня же в памяти останутся преимущественно онлайн игры, от браузерных (Территория, Бойцовский клуб), до реальных MMORPG (типа LA2 и WoW)
• Я хочу сам написать игру. На дворе ~2007, я в восторге от браузерок, дядя показал мне что можно делать с PHP (но забыл рассказать про базы данных), и первая попытка сделать что-то своё закончилась на окне персонажа, где я через простой if переключал предметы на разных персонажах и думал, что всё так и работает. Совет себе из будущего:

Сохраняй всё что пишешь, потом можно поржать над тем, что делал давно

Думаю неудивительно, что здесь ничего не вышло.

• Я пытаюсь запустить готовую игру и доработать её. На 2 или 3 курсе института я начал усиленно гуглить и искать готовые игры (ну хотелось ведь что-то запустить и развивать, а на чисто своё не хватало энтузиазма). В это время мы с друзьями играли в OGame (браузерная игра), и мне удалось откопать движок XNova (не могу найти ссылку на него сейчас), который по сути был клоном OGame. Было решено запустить его самостоятельно, и поуправлять проектом. По итогу на протяжении пары месяцев был онлайн порядка 5–10 человек, потом игру взломали, и на этом всё кончилось =)
• Читаю об играх, изучаю опенсорс-движки. С работой времени на развлечения стало гораздо меньше, но мечты об игровом проекте никуда не ушли, нашёл утешение в чтении исходников открытых проектов. Наверное, основным, откуда я многое подчерпнул, в том числе для текущего проекта, является CMangos — опенсорс-сервер для WoW. Хотелось бы ещё иметь открытый клиент, но, думаю, мечтам не суждено будет сбыться.
• Довёл игровой пет-проект до состояния, когда им можно поделиться. Сперва хотелось сделать что-нибудь в режиме реального в 3D, но, потыкавшись по разным сторонам, понял, что для освоения всех тонкостей нужно потратить очень много времени, и лучше взять то, с чем в последнее время много работал.

Как начиналось?

Идея возникла на стыке моего игрового опыта и опыта веб-разработчика. Захотелось сделать что-то своими руками (наконец-то), а поскольку руки приспособлены только под клавиатуру — получился код. Но точно могу сказать, что формат браузерной MMORPG появился после мытарств с C/C++ и 3D (брать Unreal Engine, Unity или любой другой готовый движок не хотелось, причина банальная — хотелось по максимум своё), когда я понял, что туда надо всаживать гораздо больше времени, чем есть, и, может быть, через год-другой что-то и получится. То, что буду делать именно онлайн-игру, также было ясно с самого начала, так как под большим впечатлением от времени, проведённого в онлайн-играх, казалось, что только такие игры и должны быть.

Из того, что сделать в вебе, было несколько идей: от симулятора кота, который терроризирует хозяина (но показалось что тут лучше всё же single в 3D сделать), до переосмысления вышеупомянутой OGame, но потыкавшись по текущим браузерным MMORPG, показалось, что можно попытаться привнести что-то новое (к тому же их несколько и проще было бы найти интересные механики и референсы).

Стоит также сказать, что попыток начать в разные этапы жизни было несколько, но до чего-то большего добрался только один. Я считаю, что мне помогло правильное распределение приоритетов и точек интереса в разработке, так как все прошлые проекты начинались с самого интересного — геймплея или реализации основной идеи, а когда время доходило до того, что надо делать всю обвязку (регистрация, авторизация, сессии и прочее), энтузиазма уже не было и доделывать не хотелось. На этот раз я начал со скучного, и когда запас энтузиазма начал иссякать, переключился на геймплейные механики, что позволило вполне себе успешно поработать над проектом около полугода.

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

Базовые механики

Перемещение персонажа

Наверное, первая механика, которую я реализовал. Строится она на том, что мир состоит из локаций, которые могут быть связаны с другими локациями. Выбираешь одну локацию для перехода и попадаешь в неё. Мне сразу же захотелось сделать функционал ограничения на вход в локацию (например, чтобы новые игроки не убегали в локации высокого уровня), и я реализовал это с помощью механизма ограничений, который позволяет создавать набор правил для игрового объекта, которые проверяются при попытке взаимодействия с этим объектом.

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

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

Пример кода, отвечающего за проверку состояния квеста.

Характеристики и предметы

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

Характеристики есть базовые, которые выдаются при регистрации, бонусные, которые вырастают в связи с ростом уровня, и характеристики на предметах, которые применяются к персонажам при использовании найденных предметов (наверное, сюда можно также добавить характеристики от усилений, но этот функционал пока не реализован).

Как и система ограничений, система выдачи бонусов (например, за повышение уровня), одна из основных в игре. Она работает по схожему с ограничениями принципу, в рамках которого мы указываем тип бонуса (например, выдача характеристики), а также значения (код и значение характеристики).

Квесты

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

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

1. Набор фраз для NPC (для получения квеста, для завершения квеста, для промежуточного состояния квеста). Все их нужно перелинковать между собой и разработать систему, которая будет подставлять определённые реплики в разные моменты времени.
2. Бонус на выпадение квестовых предметов, с ограничением на них: квест должен быть взят, а предметов в инвентаре должно быть меньше десяти (зачем нам выбивать и плодить больше предметов, чем нужно).
3. Ограничение на сдачу квеста (должно быть десят квестовых предметов в инвентаре).
4. Бонус за сдачу квеста.

А если квест подразумевает большое количество таких связей и условий, то это большая и кропотливая работа.

И всё остальное

Если описывать все остальные реализованные возможности игры так же полно, как и предыдущие 3, то будет слишком много текста. Поэтому небольшой список того, что ещё есть:

1. Чат (с сообщениями от пользователей и системными, о разных событиях)

2. Аукцион (с возможность покупки и продажи предметов)

3. Почта (на которую приходят покупки и деньги после завершения сделки на аукционе)

4. Группы (с автоматическим или ручным распределением лута)

5. Подземелья (в которые можно войти только группой с нападением монстров на каждом переходе и босом в конце)

6. События (поэтапные, с появлением новых монстров или добычей специальных предметов и наградами за это)

7. Профессии (добывающие и крафтовые, их можно прокачивать, изучать новые рецепты)

Ну и конечно же, боевая система, которую мне хотелось бы описать наиболее подробно

Боевая система

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

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

На базе всего вышесказанного удалось создать с помощью ThreeJS и 3D-поле, и добавить на него объекты персонажа и ботов и реализовать управление.

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

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

Код навыков выглядит всегда примерно одинаково (за исключением случаев, когда он не укладывается в существующие реалии), например код навыка «Рывок» представлен ниже.

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

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

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

Ещё одной составляющей боевой системы является, как не трудно догадаться, AI-боты. И в данном случае они просто заскриптован. Для каждого бота вызывается метод DoTurn, который так или иначе вызывает какой-нибудь из навыков и порождает применение эффектов.

Базовый AI позволяет просто преследовать ближайшего игрока, и если радиус навыка позволяет, ударить персонажа этой способностью.

Данный AI нужен для самых простых ботов, что бы не разрабатывать AI под каждого, но если речь идёт о сложных механиках, тут не обойтись без описания конкретных взаимодействий. Например, у меня есть реализованное подземелье, в рамках которого есть босс-дракон, он умеет использовать разные способности в зависимости от общего таймера боя (на третьем ходу запустить определённое заклинание) или бот-призыватель, который использует предмет для призывы помощников, в случае если его здоровье опустилось ниже 50%.

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

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

Далее формулы, которыми я считал силу удара, я перенёс в код и потестировал на ботах — в среднем всё сошлось.

Технологический стек

В качестве бэкэнда используется Golang, так как последние несколько лет я пишу именно на нём, а сервисы спроектированы на базе чистой архитектуры, которую мы применяем в компании, в которой я работаю.

В качестве базы данных взял MySQL, так как давно не с ней не работал (а опыта на Go с ней вообще не было). Это привело к страшным последствия в аукционе, когда мне пришлось составлять фильтрационные запросы в зависимости от наличия в фильтре тех или иных параметров.

Выглядит стрёмно, и, да, я понимаю что здесь можно было бы применить ORM или просто Query Builder, но, когда я писал эту часть, мне лень было заморачиваться с поиском соответствующих библиотек.

Для управления базой данных я использовал PHPMyAdmin, вспомнил былые времена, когда в базу данных ходил только через неё.

Одной из основных вещей, которые мне хотелось попробовать при реализации данного проекта, это GRPC, поэтому всё общение (и между микросервисами, и запросы с фронта) происходит через этот протокол. Главным разочарованием для меня стало то, что пакет grpc-web не поддерживает stream’ы, хотя казалось бы, можно это обернуть через веб-сокеты, поэтому пришлось делать свой сервис, который занимался проксированием таких запросов. Мне также не очень нравится, как у меня организовано хранение и распространение артефактов от .proto-файлов, но что с этим делать я пока не знаю.

Выбор для фронта был не очень велик, я неплохо знаю Vue, а моё общение с React не задалось ещё очень давно (когда я не смог развернуть его без create-react-app). Поэтому я выбрал React, в конце концов, все мои пет-проекты так или иначе связаны с познанием чего-то нового. Написание React-приложения с помощью хуков мне зашло куда больше, чем старые классовые компоненты. Я использовал библиотеку MUI для основной части интерфейса, и написанные самостоятельно компоненты для того, чего нет в библиотеке.

Самое интересное в этой части кода связано с потребностью сделать всплывающие подсказки к предметам. Мне не хотелось запрашивать данные каждый раз при наведении, и знающие люди подсказали, что для локального кеширования можно использовать useContext.

Всё окружение (включая наполнение БД первичными данными), сейчас поднимается с использованием docker-compose, в котором нет чего бы то ни было интересного.

Статус проекта

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

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

К сожалению, ссылку на Github оставить не могу, так как надеюсь, что из этого проекта сможет вырасти что-нибудь коммерческое. Но рад буду пообщаться и обсудить что со всем этим делать дальше в телеграме

Вступление

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

В начале этого года я решил — хватит! Я перейду на один из менеджеров паролей. Все крутые парни пользуются менеджерами паролей. И я стал изучать их.

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

В критически важный момент мы можем не получить доступ к своему аккаунту.

Эту проблему, якобы решает облачное хранение. Но облачное хранилище — это всегда чей-то сервис. Мы не можем быть уверены, что этот сервис не сломается или не откажет нам в доступе по любой причине.

Идея

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

Принцип простой — придумать и запомнить один надёжный пароль не так уж трудно. Этот пароль может играть роль источника энтропии для криптографической функции, которая вычисляет пароль для конкретного аккаунта. Все данные аккаунтов можно безопасно сохранять на устройстве для удобства пользователя.

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

В качестве варианта реализации я выбрал PWA. Во-первых, PWA — это, прежде всего, веб-сайт. То есть получить доступ к нему максимально просто. Во-вторых, PWA — это приложение, которое можно установить на любое устройство. Буквально одни плюсы и нет минусов.

В начале года как раз узнал про методологию Feature-sliced design и решил распробовать её на своём новом пет-проекте. В качестве реактивной библиотеки выбрал свою любимую третью Vue. Итак, дамы и господа, встречайте…

Passcryptum

GitHub — Passcryptum

Исходный пароль обрабатывается функцией PBKDF2 SHA-512 262144 итераций. Это серьёзное препятствие на пути у тех, кто захочет получить доступ к нашим аккаунтам путём перебора исходного пароля.

Приложение не хранит пароли, но хранит список сервисов и логинов в зашифрованном виде. Без нашего исходного пароля никто не сможет прочитать даже список сервисов, которыми мы пользуемся. В свою очередь мы, заходя в Passcryptum, сразу видим свои сервисы и можем сразу скопировать логин/пароль.

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

Если есть нужда сменить пароль на аккаунте — у каждого логина есть версия. Инкрементируем версию и получаем новый совершенно уникальный пароль.

Чтобы не вводить каждый раз свой суперсекретный исходный пароль (мало ли где кто подсмотрит), существует возможность задать PIN. Хеш исходного пароля шифруется значением PIN, а также отпечатком системы устройства. PIN можно сколько угодно раз забыть, удалить и установить новый. Главное — помнить свой исходный пароль и вводить его исключительно осторожно.

Заключение

Passcryptum решил мою проблему и я с радостью готов поделиться со всем миром этим инструментом. В Passcryptum нет ничего платного и весь код открыт.

Помимо README.md, я добавил несколько полезных инструкций:

• Алгоритм генерации паролей;
• PIN;
• Рекомендации по использованию.

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

Спасибо за внимание! Каждому человеку, который пользуется паролями (ну то есть просто каждому), искренне советую попробовать Passcryptum.

Какие вообще есть варианты?

• Курсы из разряда «%lang_name% с нуля». Имя им легион. Но многие ли из них ориентированы на разработчиков, а не вайтишников? Снова слушать про класс Employer и отличие цикла for от while как-то непродуктивно.
• Книги. Серьезные, профессиональные книги. Проблема не в том, что они толстые и скучные. Просто нужно обладать воистину железной силой воли, чтобы не только дочитать до конца, но и прорешать задачи. Отдельный вопрос, как убедиться, что закодил решение без багов.
• Документация и, опционально, заныривание в исходники. Отличный подход, хоть и не самый эффективный. Жаль, он не дает представления о распространенных в сообществе лучших практиках, о нюансах, на которые наталкиваешься в промышленной разработке.

Итак, однажды вечером собрались четыре разработчика и задались вопросом: как в идеале должна выглядеть площадка для изучения новых языков и технологий? Сошлись на следующем:

• Самое важное — это практика. Ее нужно много. Но маленькими порциями. Пусть теория чередуется с емкими задачами в online IDE на этой же странице.
• Задачи должны быть разноплановыми. Писать код. Рефакторить код. Анализировать, как отработает код. Все как в жизни.
• Концентрированная, свеженькая теория. Без лирических отступлений, опасных упрощений, академеческих дебрей. Прочитать и смочь ревьюить реквесты!
• Курсы должны быть опенсорсными. Чтобы любой желающий мог сообщить об ошибке, предложить реквест с исправлением, заменить скучную задачу на более жизненную. И даже опубликовать собственный курс!

…Так и родилось описание проекта Senior Junior, который мы в свободное время пилим почти полтора года. Эхееей, на прошлой неделе мы выкатили альфа-версию!

Что из себя представляет Senior Junior?

Senior Junior — это площадка с опенсорсными курсами для разработчиков. Повторю, для разработчиков. Вайтишники, осторожно! У нас нет сертификатов, гарантий трудоустройства и лозунгов «освойте с нуля». Зато у нас есть актуальная теория в связке с непрерывной практикой в online IDE.

Тексты курсов и задачи выложены на гитхаб. На данный момент мы почти дописали курс по Python и приступили к курсу по Rust.

Курсы можно проходить на сайте и в Telegram-боте. Между ними легко синхронизировать прогресс! А что, очень удобно: дома начал главу на сайте с десктопа, продолжил уже в метро из бота.

Как устроен проект

Мы публикуем главы курсов в формате md. Тексты размечаем через markdown-it-attrs.

На фронтенде md рендерится в HTML с помощью библиотеки markdown-it. В Telegram-боте форматированный текст подготавливает самописный парсер. CodeMirror используется для интегрирования online IDE в веб-страницу.

Бэк выглядит примерно так:

На данный момент у нас есть:

• 27 глав по Python и 2 главы по Rust. 160 задач. Все они в открытом доступе.
• Площадка senjun.ru и Telegram-бот для прохождения курсов. Согласно принципу «подчеркивай достоинства, скрывай недостатки» все исходники пока надежно спрятаны.
• 4 разработчика, вложившихся в проект и готовых его развивать: Аня Беккер, Дима Шипилов, Володя Хацкевич и Оля Хлопкова.

О настоящем и будущем

Позади полтора года работы. За это время мы запилили бэкенд и клиент-сайд, выкатились на прод и пережили пару итераций тестирования, сбора фидбэка и фиксов.

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

Не скромничайте, выходите на связь:

• Оставляйте фидбэк. Форма для заполнения есть в конце каждой главы курсов senjun.ru.
• Добавляйтесь в группу в Telegram.
• Заводите баг-репорты, открывайте пул-реквесты на GitHub.

Какие у нас планы?

Допишем главы по Python и Rust. Параллельно будем добавлять новые курсы. Golang, линуксовый shell script, Kotlin? C++ за 21 год, почему бы и нет? Carbon, как только появится первый релиз языка? А как насчет узкоспециализированных тем вроде теории компиляторов?

Итак, кто что заказывает?

Что за библиотека такая

Изначально задачей библиотеки была строгая типизация работы с Telegram Bots API. Так уж вышло, что со временем это переросло в нечто большее, теперь это — мультиплатформенная библиотека с поддержкой WebApp в JS таргете и кучей разных DSL.

О зарождении

По счастливому стечению обстоятельств, на момент начинания библиотеки я уже имел опыт публикации JVM-библиотек, работы с Kotlin и работы с Telegram Bots API. Понятное дело, что тогда (около пяти лет назад) уже были какие-то решения для этих задач, но:

• Как минимум, бОльшая часть была написана на Java для JVM — ни о какой null-safety и других фишках Kotlin не шло речи.
• Ни одна из изученных мной библиотек не обладала хотя бы намёком на какую-то безопасность при работе — поля запросто могли отсутствовать, а методы не применяться.
• Тогда еще не так популярны были всякие DSL + поскольку библиотеки были на JVM, очень много чего скрывалось в документации или в лучшем случае в JavaDoc’ах

Самой большой болью было то, что библиотеки калькировали API, из-за чего постоянно происходили выстрелы в ногу: то поле отсутствует для какого-то типа, то метод не применим для чата.

Трудности по-пути

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

Также, каждая итерация поддержки Telegram Bots API вносила свои приколы: например, форумы — это просто группы с галочкой форумов, у которых для сообщений есть поле threadId. Само собой, каждое обновление заставляло перелопачивать иерархию типов, что иногда приводило к болючим изменениям. Цена прогресса, так сказать 🙂

Из забавностей, в одном из обновлений ребята из команды Telegram толи вывалили наружу, толи подглядели в либу и почти скопировали какую-то иерархию типов (кажется, для прав) — это было очень интересно видеть почти 1-в-1 названия для типов и их отношения друг к другу в официальном API и моей либе 😀

Сообщество

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

К чему я (мы) пришел

Я начинал работу над библиотекой один. Со временем приходили люди и привносили идеи. Так появилось много всего:

• удобный API, вроде как дублирующий методы в оригинальном API, но на самом деле также разделённый по типам и строго декларирующий, какие параметры с какими можно сочетать;
• различные DSL вроде Keyboards DSL и Text Entities DSL;
• некоторые библиотеки вокруг: PlaguBot для унификации частей ботов (плагинов), различные FSM и BehaviorBuilder.

Вместо выводов

Библиотека жива. Сейчас во многом она в ситуации поддержки — возможности целенаправленно развивать её и её экосистему особо нет, но тем не менее всё время появляются какие-то классные штуки, как то отдельная абстракция для предварительной информации о чатах или различные дополнения документации.

Спасибо за внимание 🙂

Я являюсь разработчиком на языке Go в течение трех лет. Также вот уже в течение трех лет я пишу пет-проект компилятора C-подобного языка.

Изначально появилась идея написания компилятора C-подобного языка в промежуточный код, который затем бы защищался от несанционированного использования и интерпретировался только лицом, обладающим ключом. Однако сейчас эта идея устарела, поскольку я больше увлекся уже компиляцией промежуточного программного кода в машинный (бэкэндом компилятора).

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

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

Таким образом, я сменил целевой язык на язык Go, получив таким образом транспилер. Тем не менее язык Go и мой C-подобный язык плохо совместимы. Например, в Go нельзя объявлять переменную, которая затем не будет использоваться, а в моем языке можно. В конце концов целевым языком стал для меня классический GNU Assembler, ведь я компилирую программы под ОС Ubuntu x64. В настоящее время он и остается целевым языком. После компиляции программ с языка GNU Assembler я получаю исполняемые файлы.

Лексический анализ предполагает разбиение входного потока символов на осмысленные группы (лексемы), а также выделение токенов (лексемы и ее типа). Например, “AND”, “11”, “(” — это лексемы моего языка). Я выделяю, например, следующие типы лексем: OP — операция, VAL — значение, VAR — переменная, BR — скобка. Так, для приведенных лексем можно назвать следующие токены: “OP AND”, “VAL 11”, “BR (“. Когда код команды (символы до “;”) разбит на лексемы, наступает фаза синтаксического анализа — выявление того, в каких отношениях состоят сущности (токены). Результатом синтаксического анализа обычно является либо абстрактное синтаксическое дерево (АСД), либо трехадресный код. Я строю АСД. Вот пример такого дерева.

Для построения таких деревьев, визуально понятных для человека, я использую GoCV — обертку на Go для библиотеки OpenCV.

В конечном итоге каждая вершина дерева нумеруется в глубину, и мы получаем массива токенов в соответствии с их расположением в дереве:

Пустые кружки означают тот факт, что у узла нет потомков.

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

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

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

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

Программа на C-подобном языке преобразуется в промежуточное представление, похожее на язык Assembler с тем, чтобы в последующем реально получить программу на языке GNU Assembler и скомпилировать ее.

В настоящее время мной написан чат-бот на языке Go ВКонтакте, но я мечтаю переписать со временем этого бота на собственном языке. Любимый кусочек кода:

Функция makeTree, выполняющая основную работу по построению АСД, достаточно объемная, поэтому мне не хотелось бы приводить здесь ее код. Весь код может быть найден на GitHub.

Более подробно о процессе реализации компилятора я рассказываю в своей группе ВКонтакте. Также прикрепляю ссылку на репозиторий GitHub.

• GitHub: https://github.com/korepanov/bint
• ВКонтакте: https://vk.com/repaschool

Привет ✌

Я аналитик в IT и телекоммуникационной компании. Так сложилось, что в текущий момент работаю над своим проектом, который позволяет анализировать эффективность работы сотрудников в Telegram-чатах. И, возможно, местная аудитория даст полезные советы для развития инструмента.

Ну и еще было бы здорово получить худи от Tproger)

Идея проекта

Не нужно рассказывать о популярности Telegram и постоянном увеличении аудитории. В РФ используется порядка 60к групповых чатов, по статистике TGStat на август 2023.

Групповые чаты использует и бизнес для коммуникации со своими клиентами, по опыту, больше для поддержки продукта, чем для продажи. Соответственно руководителю отдела поддержки важно понимать, как эффективно сотрудники работают в Telegram, а именно интересуют метрики:

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

Это только часть метрик, которые необходимы для анализа.

Моя коллега — руководитель отдела поддержки, пришла ко мне с задачей разработки инструмента, который позволит анализировать эффективность сотрудников в чатах Telegram.

Первоначальная и основная задача: быстро и дешево запустить инструмент + проверить, а точно ли он приносит пользу. Так как на рынке нет подходящих решений*, то я решил создать такой инструмент самостоятельно. Который на текущий момент и является моим пет-проектом.

Развитие проекта.

Быстро и бесплатно запускаем MVP инструмента.

Чтобы собирать данные, нужно создать обычный Telegram-бот. Также нужно хранилище для собранных данных. Для этой цели использовал Google Sheets. Чтобы подключить Telegram-бота к гугл-таблицам и собирать данные, нашел в открытом доступе код:

Для получения необходимых руководителю метрик, использовались формулы в гугл-таблицах. И чтобы делать какие-то выводы на основе собранных данных, их нужно визуализировать. Для этой задачи используется Yandex DataLens.

Итог — MVP

В течение полного месяца протестировали на семи групповых чатах Telegram. Все работает корректно, и только одна ошибка при загрузке данных. Удалось вывести следующие метрики:

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

И самое главное, что руководитель может видеть информацию почти в реалтайм (лаг обновления данных в Yandex DataLens — 30 минут) и на мобильном устройстве.

Вывод: продукт закрывает потребности, но, разумеется, требует доработок.

Возникшие трудности

После тестирования MVP, решили использовать инструмент на всех клиентах отдела, с которыми ведется коммуникация в групповых Telegram-чатах.

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

Изначально было понятно, что для большого объема данных такое костыльное хранилище в виде гугл-таблиц рано или поздно приведет к ошибкам. Как раз в текущий момент, мой пет-проект в стадии трансформации, чтобы избавиться от возникших трудностей:

• Создалась БД на MySQL.
• Telegram-бота пишу на Python, не только для наполнения БД, но и для формирования необходимых метрик. Пользуюсь наиболее популярной библиотекой telebot.
• В планах еще разработать GUI для управления и контроля работы ботом.

Заключение

Я ввязался в ту еще авантюру с разработкой данного проекта. Однако с его помощью я повышаю свои скиллы в разработке на Python, продуктовому менеджменту и аналитике данных. Самое главное, что все это меня драйвит и заряжает, поэтому я и считаю это своим пет-проектом.

Буду рад любым комментариям, лайкам и вопросам. Спасибо за внимание)

Про проблему веб-приложений с машинным обучением

Модель – это какой-то исполняемый код, которому можно отдать данные в определенном формате (подать на вход) и получить ответ (получить выход). Как правило, это массивы чисел: массивы numpy, тензоры, спарс-массивы и другие.

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

В больших компаниях есть ресурсы для создания таких интерфейсов, их оптимизации и поддержки. Но также есть много небольших компаний и просто исследователей, которым нужно создавать этот интерфейс самостоятельно. Мой пет-проект должен, если не избавить, то сильно упростить этот процесс.

Библиотека, про которую я пишу, создает веб-приложение с API для модели машинного обучения. Я назвал ее mlup. Чтобы запустить ваше веб-приложение, нужна только модель.

В связи с тем, что основные ЯП в машинном обучении — Python и C++, я написал библиотеку на Python. Хочу в будущем сделать реализацию на С++. Название mlup было уже занято в pypi, поэтому я загрузил библиотеку под названием pymlup.

Установить библиотеку на Python можно через pip: pip install pymlup.

Про решение

Как пользоваться

Самый простой вариант — запустить веб-приложение со всеми стандартными настройками:

Эта команда создаст и запустит сервис c API, в котором можно вызывать предсказание вашей модели. Сам сервис запустится на 8009 порту. Вы можете открыть документацию API и потестировать ваш сервис в ней по адресу http://localhost:8009/docs.

Вы можете написать свой конфигурационный файл в yaml/json формате и запускать из него:

Или сгенерировать код веб-приложения в Python-файл. Созданное приложение можно дорабатывать собственным кодом и запускать любым удобным способом:

Также можно использовать все возможности из кода, импортируя библиотеку mlup и создавая объект mlup.UP.

EmptyModel ничего не возвращает, когда ее просишь что-то предсказать. Это просто заглушка, которая используется для внутренних целей и для пустой инициализации.

Каждая модель машинного обучения занимает какой-то объем памяти, поэтому ее загрузка в память должна быть явной. А без загрузки модели в память невозможен ее анализ и создание веб-приложения. Когда вы создаете объект mlup.UP, ничего в память не грузится. Для загрузки модели и ее анализа нужно вызывать метод up.ml.load().

Код up.run_web_app(daemon=True) запускает веб-приложение. Под капотом используется FastAPI.

Архитектуры веб-приложения

На момент написания статьи, в mlup есть три архитектуры веб-приложения:

1. Прямое использование модели (directly_to_predict)
2. Очередь и воркер (worker_and_queue)
3. Батчинг данных из запросов (batching)

Архитектура веб-приложения: прямое использование модели

Самая простая и очевидная на первый взгляд архитектура. Для каждого запроса пользователя вызывается предсказание модели.

Модели машинного обучения, во время предсказания, выполняют CPU bound операции. Каждый запрос пользователя будет запускать предсказание модели независимо от других. Получается параллельные предсказания. В таком случае ресурсы потребляемые моделью будут множится для каждого запроса и могут закончится. Приложение зависнет.

Но эта архитектура самая быстрая для предсказания. Она подходит для случаев: когда у вас маленькая модель, быстрая модель, мало запросов к ней.

Архитектура: очередь и воркер

Когда у вас недостаточно ресурсов для запуска несколько параллельных предсказаний модели, вы можете обеспечить доступ к модели через очередь. Тогда ваша модель машинного обучения будет выполнять только 1 предсказание (CPU bound операцию) в момент времени. И все запросы пользователей будут обработаны в том порядке, в котором пришли.

Эта архитектура поддерживает долгие предсказания (long predict) – когда ваша модель машинного обучения вычисляет ответ дольше, чем клиент может ждать. Клиент может отправить запрос на предсказание, получить в ответе predict_id (uuid) и вернутся за ответом позже.

Архитектура веб-приложения: батчинг данных из запросов

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

Воркер с моделью читает очередь запросов, пока не наберет определенное число данных для предсказания (батч). Собранную пачку данных из нескольких запросов отправляет в модель, а результаты раскладывает в хранилище результатов по ключу predict_id. В случае mlup, все это происходит в памяти, без привлечения сторонних хранилищ.

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

Какую архитектуру выбирать, зависит от многих факторов: модели, ожидаемой нагрузки, количества ресурсов. Но эта тема заслуживает отдельной статьи.

Более подробно про весь процесс запуска и работы доступных архитектур веб-приложения написано в документации:

Кастомизация

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

Если API веб-интерфейс, созданный mlup, вам не подходит, вы можете создать любой другой интерфейс. Вам нужно просто загрузить вашу модель с помощью mlup и использовать ее. Обращаться к модели, как к черному ящику, через метод mlup.UP.predict, используя привычные Python-типы и не думая о внутренних преобразованиях данных в формат модели машинного обучения и ее работе.

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

Про производство

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

1. Загрузка модели в память.
2. Инициализация модели и ресурсов под нее (GPU).
3. Запуск интерфейса взаимодействия с моделью.
4. Принятие запроса к модели от клиента.
5. Преобразование данных от пользователя в формат модели.
6. Вызов модели с преобразованными данными и ожидание ответа от нее.
7. Преобразование ответа модели в формат понятный пользователю.
8. Ответ пользователю.

В большинстве случаев мне приходилось создавать приложение для каждого сценария заново. Даже если они были однотипные и создавались через Ctrl+C, Ctrl+V. Однажды я захотел консолидировать создаваемые мной приложения в одно, работу которого можно настраивать.

Я планировал сделать MVP за месяц. Это было наивно! Впрочем, я же программист: проваливать дедлайны — часть моей профессии. По часику в день я за месяц собрал приложение с разными архитектурами. Начал создавать разные модели машинного обучения, чтобы протестировать мой код. И тут меня осенило! Data Science специалисты не любят использовать библиотеки для разных задач, которые можно импортировать в свои исследования. А также в 1–2 строчки кода решать свои проблемы: сделать красивый график из массивов данных, красивый прогресс бар для обучения, обучить модель машинного обучения и другие.

Я понял, что созданное мной приложение неудобное для использования. Для его использования нужно клонировать Github-репозиторий, что-то прописывать в конфигурационный файл, собирать докер. Это все сложно и не подходит для главной цели — упростить создание веб-приложения с моделью. Было решено: обернуть написанный сервис в библиотеку. И на это ушло еще пару месяцев. Еще месяц я писал документацию, все оформлял и заливал в интернет.

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

1. Для Data Science специалиста можно использовать как библиотеку. В том числе запускать веб-приложение, тестировать его и сохранять в файл проверенный конфиг для будущего приложения.
2. Для программиста можно использовать из bash или прямо из кода. Можно брать созданное Data Science специалистом приложение с настройками для его модели и навешивать свою инфраструктуру.
3. Для DevOps-специалиста — это привычная работа с конфигами приложений и bash-командами для запусков процессов и приложений.

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

Какие планы

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

Но самая желанная идея — добавить реализацию на C++, которая будет использовать тот же конфиг. Но не все модули из Python реализации можно реализовать в C++. Например, работу с Pickle моделями. Но если вам нужно C++ приложение с моделью машинного обучения, значит вы, скорее всего, знаете, что делаете, и можете сохранить вашу модель в нужном формате.

Спасибо, что дочитали эту статью до конца. Буду рад любой обратной связи, особенно на GitHub.

Ссылки

1. Github — https://github.com/nxexox/pymlup
2. Документация — https://mlup.org

1. Непонятно, как сделать HTTP-маршрутизацию. Нужно ставить отдельно Traefik или аналог и с ним разбираться. А так, чтобы из коробки, такое не поддерживается.
2. Не хватает правильного веб-интерфейса. Чтобы мышкой можно было тыкать и быстро запускать докер-среду с нужными контейнерами. Есть Portainer, но мне он не понравился. Там по сути мышкой создается yaml-файл. Но это неудобно. Хочется просто взять и сказать докеру: «Запусти MySQL, а вот c этими yaml-файлами сам разберись».
3. Я тогда занимался автоматизацией бизнес-проектов, ставил разные CRM, настраивал сервера, поднимал корпоративные почты. Поднять свою почту еще та задача. Обычно это несколько недель работы. А вот есть ли нормальная готовая сборка почты под докер?

Помимо почты, бизнес хотел еще CRM, свою вики, таск-менеджер, и все это на одном домене, на своем сервере, с единой авторизацией. И как такое сделать? Есть ли готовые opensource решения? У меня появилась идея. Давайте создадим такую систему.

На протяжении последних трех лет я разрабатывал ее один, в свободное от работы время. И спустя годы разработок, тестирования и апробации, я создал облачную ОС и назвал ее BAYRELL Cloud OS.

Облачная ОС разработана на языке Bay Lang, который я создал до этого. Идея создать Bay Lang появилась еще раньше, в далеком 2016 году, когда я задался вопросом, а как запустить React на PHP? Варианта два: либо делать бэкенд на PHP как микросервис, либо V8js.

Но меня эти два варианта не устраивали, и я решил разработать шаблонизатор для PHP, который также умеет в реактивность в JS. И вскоре шаблонизатор превратился в язык программирования Bay Lang. На разработку языка программирования ушло примерно семь лет. В нем было около 11 версий.

Сейчас Bay Lang является тьюринг-полным языком программирования. Он умеет:

1. Конвертировать программу в PHP для бэкенда и JS-фронтенда.
2. В реактивность, как у современных фреймворков Vue.js и React.
3. Server Side Render.

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

Облачная ОС, на сегодняшний момент:

1. Управляет докер-контейнерами на сервере.
2. Обладает веб интерфейсом, где можно мышкой запускать WordPress, MySQL, PHP и т.п.
3. Может использоваться как облачный аналог Denwer, XAMPP.
4. Обладает маркетплейсом, в который я собрал различные контейнеры, которые использую у себя на тестовом сервере.
5. Также сейчас активно используется в качестве среды разработки. В облачной ОС есть веб-версия VSCode, которую можно установить себе на сервер, и прямо на там вести разработку микросервисов.
6. Можно взять игровой компьютер, установить туда облачную ОС, и через браузер с планшета обучать модели ИИ на PyTorch. Это такой собственный локальный аналог гугл-колаба на минималках.

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

Я планирую их создать в ближайшем будущем.

Облачная ОС доступна на гитхабе https://github.com/bayrell-os

Сайт проекта: https://cloud.bayrell.org/ru/

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

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

Мне пришла идея реализовать приложение, которое позволит сконструировать нужный для пользователя IP-TV плейлист в формате M3U.

Мне нужно было от приложения следующее:

• Задать каналы и их порядок в плейлисте. Канал — это имя, логотип и ссылки на стримы.
• Сохранить заданный плейлист в БД, выбрав не протухшую ссылку на стрим либо использовав заглушку.
• Сконструировать плейлист в формате M3U из плейлиста, сохранённого в БД.
• Web API с 2 методами: для запуска пункта 2 (далее: метод refresh_channels) и для получения плейлиста в формате M3U (далее: метод ip_tv_playlist.m3u), чтобы телевизор мог его получить и обработать.

Чтобы добавить процессу разработки ценности, я решил выбрать язык программирования Dart. Мне было интересно, насколько он удобен для такой задачи и как язык в целом.

Попользовавшись своим чудом, я понял, что вручную искать рабочую ссылку на стрим — неблагодарное дело, поэтому решил внести корректировки в изначальную задумку:

• Метод refresh_channels принимает список ссылок на IP-TV плейлисты и множество параметров фильтрации каналов:names_to_remove[] — регулярные выражения для удаления каналов по названию канала;groups_to_remove[] — регулярные выражения для удаления каналов по названию группы;source_urls_to_remove[] — регулярные выражения для удаления каналов по ссылке на источник канала;min_resolution_width — минимальная допустимая ширина разрешения канала;min_resolution_height — минимальная допустимая высота разрешения канала.
• Возможность задать каналы и их порядок в плейлисте остаётся той же, но у канала появляется дополнительное поле namePattern, в котором мы можем задать регулярное выражение для поиска этого канала в переданных плейлистах.
• Все каналы, которых не коснулась фильтрация, добавляются в конец заданного списка каналов.

Данная корректировка избавляет нас от ручного поиска рабочей ссылки на стрим для каждого желаемого канала, добавляет каналы, которые могут показаться интересными (кандидаты на добавление в заданный список каналов) или не интересными (причины добавления новой группы, имени или ссылки на источник в параметры фильтрации). Но мы должны вручную найти IP-TV плейлисты, из которых будет собираться наш, персонализированный. С этим неудобством я смирился, хотя можно было и это решить.

В реализации приложения мне похвастаться нечем, потому что делал на скорость, между делом. Но была одна трудность, с которой я столкнулся. Ещё в то время, как я пробовал на деле первую юзабельную версию приложения, я заметил, что некоторые каналы, хоть и работают, показываются в очень низком разрешении (720p, 480p, а то и хуже). На 75” 4К телевизоре это выглядит ужасно, поэтому среди фильтров есть возможность задать минимальное разрешение стрима. В моём случае это 1920×1080. Но единственный нормальный способ проверить разрешение стрима, который я нашёл, это использовать программу ffprobe. Её можно «попросить» вернуть некоторую информацию о стриме, в том числе его разрешение. Но делается это далеко не моментально. Поэтому обработка 14-ти плейлистов, которые я задал, проходила так долго, что я не дождался и остановил процесс. В качестве решения этой трудности я просто распараллелил проверку разрешения стримов на несколько потоков, достигнув приемлимого времени ожидания обработки 14-ти плейлистов (~5 минут).

Довольный результатом, я решил, что было бы круто помочь таким же пользователям Smart TV, которые так же как я не видят ничего удобного в онлайн-кинотеатрах, дополнительно содержащих в себе телевидение. Можно было бы сделать веб-интерфейс, который бы проксировал прямое обращение к Web API, но фильтрацию по минимальному разрешению стрима, скорее всего, пришлось бы скрыть, раз это такая долгая операция. Или сделать платной возможностью и за счёт этого позволить нормальные вычислительные мощности сервера. Но до продолжения делания чего-либо по этому проекту руки не дошли, поэтому я отделался написанием README.md, с помощью которого можно самостоятельно запустить приложение локально и сконструировать себе персонализированный плейлист.

Ссылка на репозиторий проекта в GitHub:

И напоследок: желаю всем меньше «печальных» каналов =)

Все началось еще в университете с лабораторной работы по искусственному интеллекту, где надо было написать свой ИИ. Но перед этим нужно было ответить на вопрос: «Какую задачу он будет решать?».

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

В моей интерпретации два мага по очереди выбирали заклинание, после чего в зависимости от атаки и защиты наносился урон. Тот, у кого закончились жизни, проигрывал. Сеттинг был самым стандартным — магия стихий. Отсюда и название: F — fire, A — air, W — water, E — earth. FAWE.

В последующие годы я занимался разработкой разного рода софта в различных компаниях, а в свободное время делал новые версии все той же игры. Параллельно я приезжал к другу, который частенько выигрывает городские турниры по настолкам. Компанией мы обычно играли в «Манчкин Квест», а вдвоем в Magic: The Gathering. Сам же я пытался играть в Hearthstone, но довольно быстро самой игре я предпочел просмотр мировых чемпионатов по ней.

Почему? Как ни странно, самый очевидный ответ уже давно был мемом: «самая сильная карта — кредитная». Но даже если ты потратишь кучу денег или времени на самые сильные карты, даже если соберешь колоду, даже если выиграешь с ее помощью мировой чемпионат, выйдет новое дополнение — и придется выкинуть львиную долю своих карт и начать собирать колоду заново. Конечно, многим именно это и нравится в карточных баттлерах. Самим компаниям наверняка тоже.

Второй момент — я не очень люблю играть 1 на 1, мне куда интереснее играть компанией или командой хотя бы из двух человек.

Долгие годы меня не покидала мысль «надо что-то менять». В конце лета 2019 года я развелся с женой, уволился из зарубежной компании и самоизолировался в квартире еще до того, как это стало мейнстримом.

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

За многие годы в разработке у меня уже накопился кое-какой опыт по оценке трудозатрат. Поэтому я проверил положение Меркурия, сверился с фазой Луны, подкинул кубик и выяснил, что весь проект займёт 2 месяца. Ещё 1 месяц я заложил на тестирование. «Не так уж и много. Сделаю, а потом наконец отдохну», — подумал я.

Следующие 1,5 года я работал примерно по 12–16 часов в день с парой выходных в месяц. Почти все от идеи до реализации делал сам, разве что арт заказал у одной студии. Этот маневр стоил мне большую часть бюджета, после чего игру во что бы то ни стало надо было закончить до конца 2020 года.

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

Тогда я наивно полагал, что если у тебя есть оригинальная игра с крутым артом, то и от издателей отбоя тоже быть не должно. Все оказалось совсем не так. Самой большой проблемой, как ни странно, стал элеватор питч. Когда меня спрашивали, я обычно отвечал, что делаю Hearthstone в 2 клика. Людям этот питч нравился, но с издателями не прокатило, а Google Play и вовсе запретил мне упоминать чужие бренды.

В итоге игра так и не нашла своего издателя и осела в Google Play под названием FAWE: Enchanted Forest 30 декабря 2020 года.

За все это время накопилось достаточно фидбэка, чтобы понять: пытаясь сделать игру для обычных людей, я ориентировался на хардкорных гиков, в результате чего для первых она получилась слишком сложной, а вторых и так все устраивает в существующих баттлерах. Поэтому несколько месяцев назад вышла вторая часть под названием Let’s FAWE!. В ней геймплей полностью переработан с фокусом на обычных игроков. Но издателя я пока так и не нашел.

Технические детали: наибольший интерес представляют боты. Зачастую, чтобы сделать их интересными и сложными, разработчики просто выдают им читы, например, отсутствие тумана войны или сбор двойных минералов. В своей же игре из академического интереса я сделал честных ботов, которые пользуются только той информацией, которой обладает обычный игрок, и не отличают его от других ботов. При этом, как показывает практика, играть с ними действительно сложно и интересно. Предлагаю челлендж: выиграть хардкорных ботов 5 раз подряд в режиме 1х1х1х1.

Стэк проекта: Golang, Lua, Defold, SQLite.

Любимый кусочек кода:

Адаптирует картинку в режиме Projection: FIXED_AUTO под любой размер экрана/окна.

Поиграть в последнюю версии моей игры можно прямо на сайте.

Для истории оставлю ссылки на оригинальную FAWE: Enchanted Forest:

• RuStore: https://apps.rustore.ru/app/com.cnaize.fawe

• Google Play: https://play.google.com/store/apps/details?id=com.townportal.fawe
• Steam: https://store.steampowered.com/app/1760510/FAWE_Enchanted_Forest

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

Я выбрал Raspberry Pi 2B и модуль SIM900 для Arduino – просто потому, что смог быстро купить их на Авито. Трудности начались ещё на этапе сборки устройства, потому что для модуля SIM900 нет нормального даташита, и очень сложно было понять, куда подавать питание, где находятся выводы последовательного порта, выводы управления. Вдобавок оказалось, что на одном из устройств перепутаны выводы RX и TX, и, не имея осциллографа, я очень долго не понимал, почему я не получаю ответов от модуля SIM900.

Но в итоге я собрал устройство и приступил к построению логики кода. Я написал код на языке Python, реализовал процесс ожидания получения новых СМС-сообщений как путём периодического опроса, так и путём реагирования на событие. В процессе получения сообщений я столкнулся с ещё одной проблемой, которую решить не смог. Дело в том, что очень длинные СМС разбиваются на несколько коротких, и каждое из них отсылается отдельно. Но как собрать их воедино? В описании команды CMGL я не нашёл признаков, которые позволили бы понять, что сообщение является частью более длинного сообщения.

Следующий вопрос – выбор такого мессенджера, через который можно пропихнуть сообщения через великий китайский файрвол. Whatsapp, Telegram сразу не подходят. Китайский WeChat даже не рассматривал – наслышан о его техподдержке и глюках вроде “операция не разрешена для этого аккаунта”. В итоге выбор пал на ВК. Я получил токен VK API и задействовал функцию отправки сообщений от имени сообщества.

Всё заработало. Я оставил устройство у моего друга, где оно лежит возле роутера. Код проекта доступен по ссылке:

Есть ещё одна проблема, которую я не смог решить, и сейчас прошу совета. Система стабильно работала с симкой Мотив, но когда я её заменил на МТС, то всё сломалось. После включения модуля SIM900 (неважно, кнопкой или пином), я получаю по UART такие сообщения:

Сообщения говорят об успешной инициализации SIM-карты. Но после этого устройство сразу отключается, красный светодиод гаснет. Иногда бывает, что после полного отключения питания устройство включается и некоторое время работает, но потом снова отключается, чаще всего после получения СМС.

Я подозреваю, что не хватает мощности источника питания. Устройство питается от одного источника на 5 вольт 2,4 ампера. Питание подаётся на Raspberry, а оттуда проводами на SIM900. Подавать питание напрямую на SIM900 не пробовал, так как нет подходящего адаптера. Как считаете, есть ли смысл его приобрести? Или могут быть другие причины?

Суть игры

Участники конференции: руководители проектов, аналитики и прочие специалисты перемещаются от стойки к стойке, получают четырехзначные коды и отвечают на вопросы вроде этого:

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

Состав проекта

Для краткосрочной работы телеграм-бота на JavaScript достаточно всего трех зависимостей: node-telegram-bot-api, SQLite для хранения данных игроков и util для обработки параллельных событий. По сути для каждого игрока создается копия игры со своими изменяемыми состояниями, поэтому единовременно минимальный сервер (Ubuntu 22.04 1,5 Гб RAM) может поддерживать игру почти сотни человек:

Зададим константы — они помогут запустить личного бота, чей токен отдает BotFather, а также укажут, с каким типом СУБД предстоит взаимодействовать:

Порядок методов и функций здесь сделать естественным не получится. JavaScript — интерпретируемый язык, и читает код построчно. То есть располагать объекты предстоит в таком порядке, чтобы к моменту запуска метода, обращающегося к базе данных, конфигурация была известна.

Переходы между стендами, победы, проигрыши

В этом участке кода мы проверяем прогресс игрока вне зависимости от того, новичок он или нет. Здесь же содержится обработчик для событий: «переход к следующему вопросу», «победа», «проигрыш», «изменение числа попыток».

Когда игрок вводит верный код, получает очередной вопрос:

Проверка игрока

Начинается игра с проверки пользователя. Если запись с таким ID Telegram уже есть в БД, то мы извлекаем число пройденных этапов. И затем высылаем новый вопрос:

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

Ппредусматриваем вывод ошибок в консоль:

Когда настало время игры, в мои обязанности входила лишь поддержка игроков. Проблем было немного, лишь три раза бот прекращал отвечать из-за ошибки, которую не удалось воспроизвести. В большинстве случаев перезапуск командой /start позволял продолжать квест.

SQL через командную строку

Я мониторила игроков, вычищала тестировщиков по окончании квеста через консоль (потому что было интересно освоить CLI-версию sqlite3).

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

И запустить предварительно установленную библиотеку:

Если нужно было проверить число игроков и донести призы впоследствии, подходил SQL-запрос, выдающий число победителей (stake – число пройденных вопросов от 0 до 10):

Хранилище отдавало такой результат:

Если речь шла о помощи игроку, застрявшему с ботом-молчуном, я пару раз дарила прохождение раунда:

Если в основной код проекта внедрялись изменения (с помощью Vim, прямо на месте), то с помощью process manager бот перезапускался:

Заключение

В мае 2023 года этот квест прошло около 150 человек, что весьма здорово, учитывая нулевые затраты на продвижение. И это увеличило время пребывания на стендах примерно на 11 часов.

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

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

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

Кратко о том, что умеет программа:

1. Добавлять новую компанию с данными: название, статус, где нашла вакансию, сколько раз откликалась, комментарий;
2. Обновлять данные по уже добавленной компании;
3. Удалять компании;
4. Искать компанию по названию;
5. Искать по статусу и количеству откликов;
6. Показывать все компании, которые занесены в БД.

Реализовала проверку от дурака: прежде чем добавить компанию, программа проверяет, что ее еще нет.

Есть несколько всплывающих информационных окон: об успехе обновления/сохранения/удаления; предупреждение, что такая компания уже есть.

Есть дефолтные значения для селекторов и полей.

Для реализации UI использовала tkinter, данные хранятся во встроенной в Python БД – SQLite.

Так как при первом тестировании программы я случайно удалила все данные, которые уже занесла для тестов, то в итоговой версии программы я настроила бэкапы.

Программа пишет основные данные в основную БД, а когда работа с программой завершается, она проводит проверку данных основной таблицы с данными из последнего записанного бэкапа. Если они различаются, программа создает новый бэкап, а если нет, то ничего не делает. Ну и при первом завершении работы, конечно, создает первый бэкап.

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

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

В процессе написания кода мне помогал ChatGPT (у меня бесплатная версия) советом, вредным советом или просто обсуждением. На самом деле, как собеседник для обсуждения проекта и его нюансов ChatGPT очень даже ничего. Особенно если учитывать, что Python я учу не регулярно и с большими перерывами, а начала учить только где-то в прошлом году.

Вот как-то так, спасибо всем, кто прочитал!

PS: ссылка на GitHub

Короче говоря, README — это своеобразный план, примерно как бэкендеры и фронтендеры согласовывают интерфейс до начала разработки. Здесь то же самое, но только договор с самим собой. План нужен для уверенности, что всё продумано и схвачено. Не могу не процитировать Лапенко:

Я на сто процентов уверен, что этот план должен сработать. Я вот когда его придумал, потом так в зеркало посмотрел на себя и подумал какой же я молодеец, какие же плааны я придумываю…

А мой план таков: в рамках этой статьи я хочу поделиться с вами своим личным опытом освоения этого подхода.

Пет-проекты отличаются от обычных тем, что их делают с любовью. Пет-проекты — это не про количество, а скорее про качество. Именно поэтому я решил представить вам сразу три своих проекта. Согласен, не бьется с логикой, но это просто попытка продать три продукта по цене одной.

Прежде всего, хочу представиться. Меня зовут Султан, хотя это и звучит словно из какой-то сказки, но это моё настоящее имя. Вашему вниманию предлагаю библиотеки, написанные мной на JavaScript для React. Если вам это интересно, прошу под кат.

Stylin

Это, наверное, самый быстрый и элегантный способ создания стилизованных компонентов React. С помощью этой библиотеки можно импортировать компоненты непосредственно из файлов CSS:

На входе получаем компонент, который полностью стилизован и типизирован, а его внешний вид (стили CSS) управляется через свойства компонента.

И тут самое место задать вопрос: “Карл, как?! Как эта магия работает?”.

Одно дело — это написать в редми, другое дело — это реализовать. Благо, у меня есть фантазия и большой опыт разработки. Мне удалось найти решение в виде CSSDoc, это как JSDoc, но только для CSS. Так вот такие аннотации необходимо добавить перед стилями компонента:

А чтобы всё это заработало, мне пришлось написать специальные загрузчики для Webpack:

Загрузчики преобразуют аннотации в компоненты React и генерируют типы TypeScript. В зависимости от значения свойства компонента, соответствующий CSS класс будет присвоен значению className. Ниже приведенный код – это упрощенный результат конвертации для общего понимания.

Все эти преобразования и извлечение CSS стилей происходят во время сборки проекта. Это означает, что стили не создаются динамически во время выполнения приложения, как это делается в библиотеках css-in-js. Отсюда и скорость: отрисовка компонентов происходит быстро.

В целом, как всё это работает, можно посмотреть в этой демке. Более подробную информацию об этой библиотеке можно получить в README или в этой статье. Однако статья написана в пафосной форме, я был молод и не совсем понимал, что писал, в общем я предупредил.

Holycow

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

Итак, представляю вашему вниманию библиотеку holy state для управления состоянием React-приложения с использованием хуков. Эту библиотеку можно рассматривать как утилитку по созданию хуков, которые могут хранить состояние вне компонентов React. Самая интересная часть заключается в том, что она работает без использования провайдеров контекста, observables, селекторов или HOC-коннекторов.

Основные особенности

• Библиотека не имеет внешних зависимостей. Размер Gzip: ~1.6kb.
• Хуки могут быть использованы за пределами компонентов React.
• Жадная отрисовка. Компоненты перерисовываются только при обновлении значений.
• Вычисляемые значения с кэшированием и вложенностью хуков.
• Асинхронные экшены.
• Подписка на изменения состояния.
• Поддержка событийно-ориентированной архитектуры.
• Гармония с функциональным программированием.
• Полная типизация TypeScript.

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

А для более сложных задач по обновлению состояния, доступны экшены – место для размещения бизнес-логики, такой как валидация, сетевые операции и прочего:

Вычисляемые значения с поддержкой кэширования:

Поддержка событийно-ориентированной архитектуры позволяет разделять код и загружать его с помощью ленивой загрузки. Такой Redux way подход, но в более простой форме.

Следующая библиотека предназначена для очень специфичных кейсов. Если вам не нравится JSX или по каким-то причинам вы не хотите использовать его в своих проектах, то следующая библиотека создана специально для вас.

React on lambda

Всё очень просто, вместо JSX используем функции. Чтобы что?

А просто, для фана:

Конечно, не стоит серьезно относиться к использованию символа λ (лямбды). Он был использован для привлечения внимания и создания шума вокруг. Вместо него можно использовать любой другой допустимый символ. Основное отличие этой библиотеки от подобных заключается в том, что все функции каррированы и удобно программировать в point free стиле.

Если эта библиотека вас заинтересовала, то можно глянуть демку или сходить на репозиторий.

Тех, кого я еще не сбил с толку своими проектами, относительно RDD. Ну, о том, как я начинаю пет-проекты через README, то боюсь вас огорчить. Я, как и любой программист, не люблю писать редмишки и делаю это на последнем этапе (за редким исключением).

Мне один доктор все объяснил,RDD – это миф о загробной жизни. Кто туда попадает, тот не возвращается.

Берегите себя и прошу вас: не ешьте на ночь сырых помидоров!

“Но ведь есть же Docker!”, — скажете вы. И будете совершенно правы, речь пойдёт именно о контейнеризации проектов. Только добавим немного автоматизации. =)

Как это было

Да, сначала был Docker. И было здорово, создаём docker-compose файл с php+mysql+nginx, пробрасываем файлы в контейнер, заливаем базу данных и кодим новые фичи для нашего проекта.

Но на весь этот процесс при первом локальном развороте сайта уходило слишком много времени. Да ещё и одновременно можно запустить только один сайт (либо настраивать постоянно конфигурацию Nginx).

Автоматизируем

Как и большинство разработчиков, я ленив, и если есть возможность что-то автоматизировать, я обязательно это сделаю.

Так и родился мой pet-проект, который по задумке должен был в пару команд в терминале развернуть сайт локально.

Назвал я его DL (Deploy Local). И представляет он из себя небольшую консольную утилиту, написанную на Go — обёртку над docker, которая скачивает по SSH типовой проект с сервера и поднимает всё локально в контейнерах. Правда, получилось чуть больше, чем пара команд, но раз уж автоматизировать, то делать это на максималках. =)

Что умеет

На данный момент программа при запуске деплоя с сервера умеет автоматически определять CMS WordPress, Bitrix и фреймворк Laravel. Но при небольшой настройке будет работать с чем угодно.

DL может запускаться на Linux, MacOS и Windows (через WSL2), позволяет одновременно поднять локально несколько проектов, умеет перехватывать почту, отправленную через PHP, генерирует самоподписанные ssl-сертификаты для локальных доменов и очень легко кастомизируется обычными docker-compose.yaml файлами.

Пару команд

Для работы нужен только Docker Engine и docker-compose (v2). Вся конфигурация настраивается через .env файл в несколько строк.

Проще всего установить dl через запуск bash-скрипта, но для Linux есть также варианты установки через apt и pacman.

После установки запускаем необходимые для работы локальные сервис-контейнеры (portainer, traefik, mailhog):

И вот пример самой простой конфигурации в .env файле:

Сохраняем файл, запускаем скачивание проекта (должен быть прокинут ваш публичный ssh-ключ на сервер): dl deploy.

Поднимаем его локально: dl up.

Вы великолепны!

Теперь ваш сайт можно открыть в браузере по ссылкам, которые отобразяться в консоли. В примере выше это будет два варианта: либо site.com.localhost, либо site.com.127.0.0.1.nip.io.

На данный момент мой pet-проект все ещё обрастает новыми функциями, но уже имеет стабильные релизы и готов к использованию.

Буду рад, если эта утилита сделает вашу локальную разработку простой и продуктивной. =)

• Github
• Документация

Иногда, когда становилось скучно и рабочие проекты пилить не хотелось, я садился за разработку собственного велосипеда. Причем архитектура была выбрана не то чтобы правильная, а наиболее удобная для коротания времени за написанием кода. Где-то встречались костыли, где-то некие ноу-хау.

Мой велосипед представляет из себя некий PHP-фреймворк для создания веб-проектов.

На текущий момент он представляет следующий функционал:

• Авторизация;
• Регистрация;
• Роли пользователей;
• Верификация E-Mail;
• Рассылки почты;
• Поддержка шаблонов почтовых отправлений;
• Менеджер очереди заданий;
• Шаблонизатор;
• Поддержка маршрутизации;
• REST API;
• Кеширование;
• Логирование;
• Работа с файлами;
• Миграции;
• Captcha;
• DDoS Guard (basic).

Пользовательская часть построена с использованием шаблонизатора Twig. Я посчитал, что это приемлемо и, вероятно, в дальнейшем облегчит жизнь верстальщикам.

Админка же, напротив, сделана без использования каких-либо шаблонизаторов (привет, Битрикс). Местами реализации ужасны, местами из глаз идет кровь, но оно работает. Сделано так, скорее, только на время альфа-версий.

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

Из интересного также есть функционал обработки роутов (маршрутов) для фронтовой части сайта с поддержкой динамических составляющих.

Реализована поддержка многосайтовости с подключением локального файла конфигурации (когда мы линкуем папку с ядром к другому проекту и создаем конфиг для нового проекта). А для облегчения развертывания используются миграции через Phinx.

Для большей гибкости реализованы роли пользователей для контроля доступа к каким-либо частям проекта. Там же есть отдельные роли как для администратора с максимальными правами и базовой роли пользователя, так и для менеджера с урезанными правами (базовый доступ к админке). Накручивать можно по желанию что угодно. Кстати, имеется функционал логирования, что очень облегчает поиск виновного, когда кто-то или что-то косячит. ?

Также реализовал функционал диспетчера очереди с поддержкой приоритетов, воркеров и повторного выполнения в случае возникновения ошибок. Использоваться может, например, для рассылки писем, обработки изображений и в целом для всего, что требует времени больше, чем пользователь готов ждать при загрузке страницы (рендерим страницу, а какие-то тяжелые задачи отдаем очереди на обработку, и все счастливы).

В качестве мониторингов был выбран Сентри как основной и Телеграм как дублирующий. Функционал второго также реализован в данном проекте.

Кодовая база на данный момент ведется на Гитлабе, но интереса ради продублировал репозиторий на Гитхаб с публичным доступом. Мало ли, кому-то данный велосипед зайдет. ?

Ссылка на репозиторий проекта:

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

Думаю, многим знакома такая программа, как BGinfo. Если не знаете, то эта программа выводит информацию о ПК на рабочий стол.

После начала работы в компании я понял, что данная программа довольно удобная: можно сразу узнать имя ПК, пользователя, домен, ip адрес и прочее, что помогает быстрее диагностировать проблемы, а также проводить инвентаризацию.

Спустя какое-то время я обнаружил у этой программки неприятный баг. Когда подключены два и более мониторов, после срабатывания BGinfo ломалось изображение, и приходилось руками менять положение с режима “Замостить” на “Заполнение”.

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

Так вот, BGinfo отключает автоматическую смену обоев. Так и родилась идея проекта.

Проект я назвал максимально “круто” — Corporate_Wallpaper_and_sys_info.

При начале разработки я подумал, что, в принципе, ничего сложного в этом проекте нет, и с места в карьер прыгнул в PyCharm.

Параметры ПК

Начал я с того, какие параметры выдает нам BGinfo, а именно: Host Name, Serial Number, IP Adress, Machine Domain, Logon Domain, Logon Server, User Name, OS Version, Build Number, OS Build, SCCM Client Version, Edge Version.

И тут понеслось гугление, была написана функция get_pc_info, в которой собиралась вся информация о ПК.

Часть информации получалась из командной строки, часть из реестра, часть из свойств файла .exe, как например, информация о версии MS edge.

Использовал библиотеки time, winreg, platform, socket, os, subprocess.

Приведу пример нескольких запросов, т.к. функция довольно длинная:

А самое интересное, с чем столкнулся — это вычисление аптайма. Сперва делаем запрос через powershell времени последней загрузки. Далее удаляем лишние символы и приводим к стандарту библиотеки datetime. После этого получаем текущее время и вычитаем из текущего времени время загрузки.

Создание waterpark

После сбора параметров встал вопрос, как же все это дело отобразить на мониторе. И тут нашлась библиотека Pillow, которая умеет редактировать изображения.

Прочитал кучу статей и документации и смог создать Watermark с информацией о ПК.

В коде выше мы создаем изображение с прозрачным фоном и записываем все полученные параметры из функции выше. После вставляем в этот watermark логотип компании, а цельное изображение вставляем в картинку для рабочего стола.

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

При вставке логотипа, логотип нужно конвертировать в RGBA.

В общем итоге мы получили картинку, какая и была у пользователя, но теперь с watermark. Осталось только установить на рабочий стол. Быстрый поиск выдал простую функцию:

В зависимости от разрядности системы функции отличаются, и пришлось добавить проверку разрядности системы.

Но на этом я не остановился и решил добавить автосмену обоев: обои должны быть каждый день новые.

Как я выше писал, мне очень понравилась программа bing wallpaper. Пришлось спарсить страничку bing и сохранить изображение.

Настройки

А что, если пользователь не захочет менять обои? Я начал думать над созданием config файла. Сначала config сделал в формате .py. Удобно, можно его просто импортировать и работать с ним, но я отказался в пользу .ini и библиотеки ConfigParser.

В конфиг я добавил месторасположение сохранения картинки Bing и логотипа компании, добавил автосмену обоев.

Подключил все это через функцию read_config и библиотеки ConfigParser.

Тут же возникла проблема: а если не будет конфига, что делать? Написал функцию проверки конфига, и если его нет, то он будет создан.

Тут мне понадобилась функция getcwd() библиотеки os, которая возвращает путь до запущенного файла, чтобы в этой директории создать конфиг и, тем самым, сделать программу портативной.

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

Получаем путь до обоев пользователя:

Используем путь до обоев, чтобы вставить на него наш логотип и установить на рабочий стол, как мы это делали в коде ранее.

Для постоянной работы создал цикл while, добавив туда запуск функций и time.sleep(3600) для ежечасного обновления информации. Ресурсов потребляет не много.

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

Идея руководству понравилась, и программу пообещали внедрить в компании.

Спасибо, что дочитали до конца. Это моя первая статья, прошу сильно не пинать.

Да и программировать я только учусь, в окружении разработчиков у меня нет, все писалось, тестировалось и улучшалось самостоятельно.

Возможно, я что-то сделал неправильно или неэстетично, но этот проект позволил мне поработать с файловой системой Windows, изучить новые библиотеки и столкнуться с различными нюансами разработки. После разработки я разобрался в auto-py-to-exe, чтобы запуск совершался одной кнопкой, и покопался в реестре, дабы добавить программу в автозапуск.

Если вам понравился проект, и вы хотите посмотреть его полностью, то вот ссылка на GitHub:

И опыт посетителя, и опыт организатора говорят мне одно и то же: люди хотят пересматривать фестивальные фильмы и делиться ими с друзьями. Особенно это относится к короткометражкам.

Но это практически всегда невозможно: фильмов нет в интернете, пока не закончится их фестивальный тур. То есть в течение нескольких лет фильм доступен ТОЛЬКО на фестивалях, и нет никакого способа получить уведомление о том, когда он появится в онлайне.

В общем, мне это надоело, и в этом году я запустил Vurchel.com – пет-проект, который должен решить эту проблему.

Наша основная цель — собрать фестивальные фильмы со всего мира на одной платформе. Мы не хостим сами видео, только встраиваем сторонние плееры или даем ссылки на стриминги.

Зайдя на страницу фильма, который пока еще недоступен, пользователь может на него подписаться, нажав на сердечко возле названия, и получить уведомление, когда этот фильм станет доступен для просмотра онлайн.

Волонтерский проект

Vurchel — открытый волонтерский проект. Как вики, только про фестивальное кино.

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

Мы ищем волонтеров: нужна помощь SEO-специалистов, backend (PHP) и frontend разработчиков, продакт-менеджеров, продакт-дизайнеров.

И, конечно, очень нужны Vurchel Hunters: люди, которые ищут инфу о фильмах в интернете и добавляют ее на сайт — то есть, наполняют Vurchel.com контентом.

Также накидать донатов — всегда хорошая идея!

Как организована работа

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

Coda была выбрана из-за двух главных ее особенностей: бесконечное количество редакторов в доке (бесплатно!) и возможности по тонкой настройке всего, что надо тонко настроить. ✨

Затем Vurchel Hunters добавляют информацию о каждом фильме в базу данных, а потом из этих фильмов собирается программа фестиваля на Vurchel.com.

Таким образом, Vurchel.com — это агрегатор фильмов, фестивалей и фестивальных программ.

Прямо сейчас на Vurchel доступно более 2500 фильмов. Большая часть из них — анимация, все фильмы фестиваля «Бессонница» за 10 лет.

Сейчас мы начинаем планомерную работу по добавлению свежих программ других фестивалей — не только анимации. ?

Что под капотом

Быстрый результат был для меня в приоритете, поэтому я взял знакомую, простую в разработке и, в то же время, богатую по возможностям CMS ExpressionEngine.

Вся разметка генерируется на сервере шаблонизатором от CMS. На фронтенде только чуть ванильного JS.

Кроме того, с помощью сервисов автоматизации, API и вебхуков Vurchel.com общается с другими сервисами: высылает инвайты на доску Coda только что зарегистрировавшимся волонтерам, сообщает Vurchel Hunters о достижении ими новых уровней (у нас есть геймификация с лычками в зависимости от вклада) в волонтерские чаты Discord и Telegram, отправляет уведомления подписчикам фильмов.

Планы

Скоро

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

Попозже

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

Два года назад я решил взяться за создание своего пет-проекта. И хотя многие начинают с классического “Hello World”, я выбрал другой путь. Мой выбор пал на создание игры “Змейка”, и в этой статье, я поделюсь с вами своим опытом.

История началась давно, когда я участвовал в городском конкурсе по программированию для начинающих. Среди сложных заданий была и “Змейка”. Это задание так и осталось в моей памяти, и спустя время я решился воплотить его в жизнь, сидя дома с чашкой чая.

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

Моя задача заключалась в том, чтобы создать консольную версию “Змейки” без использования графических библиотек. Я хотел сделать игру доступным для всех.

Создание игры “Змейка” на Python стало для меня увлекательным и образовательным процессом. Я погрузился в мир разработки игр и научился решать разнообразные программистские задачи.

Свой проект я выложил на GitHub, можно посмотреть и пощупать всем желающим.

Вот, что нужно сделать, чтобы принять участие. Зайдите в редактор, напишите статью о вашем пет-проекте и отправьте её на модерацию.

Взамен вы получите славу, обожание публики и мерч от редакции Tproger.

Требования к материалу

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

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

Будет плюсом, если вы расскажете о процессе работы: как вам пришла идея проекта, с какими трудностями вы столкнулись, как вы их решили и какую пользу извлекли из опыта по завершении работы.

Совсем классно, если вы приведете примеры кода, объясните, как тот работает, и расскажете об использованных библиотеках и инструментах.

Этапы конкурса

Конкурс будет проходить в два этапа.

Первый этап

Со 10 по 30 октября вы пишете статьи о своих пет-проектах и публикуете их на сайте.

Через три недели, 30 октября, редакция Tproger выберет проекты, которые больше всего понравились читателям. Критерии оценки — количество просмотров, лайков и комментариев под статьями участников на сайте.

Второй этап

30 октября стартует голосование на сайте, в ходе которого пользователи смогут выбрать лучший пет-проект.

Призы для участников

Все участники, которые пройдут первый этап, получат призы.

• С 1 по 5 место: худи с логотипом Tproger и стикеры от редакции.
• С 6 по 10 место: футболки с логотипом Tproger и стикеры.

Заключение

Не бойтесь рассказать о себе и своих достижениях, пишите легко и непринуждённо, и тогда ваши труды будут вознаграждены. 🙂

Подпишитесь на тэг Лучший пет-проект 2023, чтобы не пропустить статьи от участников конкурса и следить за обновлениями в личной ленте.

Желаем удачи!

Одной из таких историй является идея, которая началась как пет-проект, но в конечном итоге переросло в научное исследование с удивительными результатами. Название этого исследования – “Application of the ‘Banchenko Dream Synchronization Mnemonics Method’ for Joint Synchronization of Dream Elements (including Lucid Dreams) within the ‘Blokhin Dream Network Concept’ and Analysis of Results based on the ‘Kapustin Dream Match Search AI Model’“.

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

Автор: Капустин Михаил, CTO представляющий компанию ASRP (Advanced Scientific Research Projects & Association of Sleep Research Projects).

Идея, рожденная из страсти к исследованиям

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

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

От пет-проекта к научному моделированию

Поначалу это казалось идеей, которая останется в рамках любительского интереса. Однако смелость и научная любознательность исследователей не знали границ.

Они разработали новую компьютерную модель “Kapustin Dream Match Search AI Model” для идентификации соответствий между снами на основе искусственного интеллекта. Эта модель стала ключевым элементом их исследования.

Для более подробного ознакомления с принципом работы модели можно ознакомиться с ранее опубликованной статьей “Как ИИ помогает изучать осознанные сновидения“.

Гипотезы и результаты

Исследователи сформулировали несколько гипотез.

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

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

Искусственный интеллект и анализ снов

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

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

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

Выводы

Исследование “Application of the ‘Banchenko Dream Synchronization Mnemonics Method’ for Joint Synchronization of Dream Elements (including Lucid Dreams) within the ‘Blokhin Dream Network Concept’ and Analysis of Results based on the ‘Kapustin Dream Match Search AI Model’” превратилось из необычного пет-проекта в научное открытие с потенциалом для дальнейших исследований в области сновидений и искусственного интеллекта.

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

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

Где брать идеи для пет-проектов

Первый источник — ваша жизнь

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

Второй источник — жизнь окружающих

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

Как создать пет-проект

1. Сформулируйте идею

Подумайте, о чём будет ваш проект, какие задачи будет решать, что получат пользователи.

2. Проведите исследование

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

3. Составьте план

Этот этап может занять много времени, но он по-настоящему важен. Вы должны представить, как будет работать ваш проект, какой функционал он имеет, как действует логика в разных сценариях, какой стек технологий вы будете использовать. Рекомендуем составить документ, где вы распишете всё это по пунктам.

Если в стеке есть незнакомые технологии, нужно оценить их сложность. Так, если вы знакомы только с фронтендом, написание серверной части приложения на C# может занять долгие месяцы. И наоборот: освоение Angular или React вряд ли займёт много времени у бэкендера. Новичку лучше брать посильные задачи — так можно быстро увидеть прогресс и сохранить мотивацию.

4. Создайте MVP — минимально жизнеспособный продукт

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

5. Добавьте кейс в резюме

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

Как лучше делать пет-проект: одному или командой

Зависит от целей и объёма работы, который вам предстоит. Работа в команде — отличная возможность улучшить свои коммуникативные навыки и разработать более сложный продукт. Например, если вы разбираетесь в бэкенде, а ваш друг во фронтенде, то из вас получится хорошая команда и не придётся осваивать что-то новое. Но если проект небольшой и технологии вам знакомы, вполне можно справиться и одному.

Примеры пет-проектов

Таск-трекер

Таск-трекеры стали своеобразным мемом в IT-среде, так как с них начинают все программисты, но это всё ещё хороший способ получить практический опыт разработки.

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

Мини-игра

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

Представим функционал проекта на примере морского боя:

• генерация ссылки для входа в игру двух игроков;
• возможность выводить на поле разные боевые корабли;
• возможность выбирать клетки, чтобы проверить, есть ли там вражеский корабль;
• чат для игроков и т. д.

Пример минималистичного морского боя для браузера:

Калькулятор

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

Если это вам не очень интересно, разработайте калькулятор для расчёта заработной платы сотрудников компании с учётом отпусков, больничных и отгулов. Это поможет на практике освоить математические операторы и преобразование типов данных.

А вот так может выглядеть калькулятор отпускных:

Социальная сеть

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

Интернет-магазин

Интернет-магазин с каталогом товаров, загружаемых из базы данных, — хорошая возможность показать свои знания для крепкого новичка в фулстек-разработке. Сделайте личный кабинет пользователя, карточки товаров с отзывами и оценками, поиск по каталогу, корзину.

Самое главное в разработке пет-проекта — регулярность. Старайтесь выделять ему хотя бы 30 минут в день после работы или учёбы, чтобы не потерять интерес. Тогда результат не заставит себя ждать, и завершённый проект станет важным пунктом в вашем резюме.

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

Я, как разработчик, и как CEO проекта CVCode, считаю, что показатель высокого уровня разработчика является именно наличие пет-проектов, а также опенсорсных решений, и это важный критерий для отбора в мою команду единомышленников.

Меня зовут Артем Аментес и я хочу поделиться своим опытом создания проекта для души.

Идея, которая меня захватила, родилась весьма просто: с детства, и уже более 20 лет изучаю английский язык постоянно, и уже достиг уровня fluent (свободно владеющий). Мир, новости, технологии настолько широко используют английский, что очевидно, школьной программы конечно не хватает. Совершенствоваться необходимо постоянно.

Мне вообще нравится английский в качестве языка науки –  это позволяет мне достаточно широко охватывать мировые новости, тренды и факты. И знаю многих людей, кто хотел бы заняться изучением английского, чтобы чувствовать себя увереннее и свободнее, которые пытаются что-то для этого делать, но обычно откладывают до понедельника, а потом – следующего понедельника.

Итак, цель моего pet-проекта – со всеми вокруг поделиться возможностью внедрить английский в свою жизнь.

По опыту скажу, что есть 2 наиболее важных момента в изучении английского языка:

1. Необходимо знать большое количество слов и их определений (definitions).
2. Регулярно практиковаться в общении, чтобы получать точный ответ и комментарии на свои вопросы и рассуждения. Второе, пожалуй, является основным.

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

Начать следовало с архитектуры моего питомца

1. Главная проблема, которую решаем – это собеседник. Большая доля общения приходится на чаты в мессенджерах, а значит, мы можем создать чат-бота. Лучшим решением будет взять телеграмм. Это удобный мессенджер с открытым api и умопомрачительным числом ботов и заготовок.
2. В плане мозгов у «собеседника» тоже не встало много вопросов. Смело берем ChatGPT модель, и на ее базе делаем товарища для общения.
3. Понадобится словарь, где мы будем записывать слово, а затем его определение. Подойдет простое решение.
4. Повторение – мать учения, пусть по запросу бот выбрасывает слово в случайном порядке. А задача пользователя будет дать ему определение по памяти.

Это проект для души, решил не сильно мудрить, быстро дойти до реализации и запустить бота в продакшн.

Шаг 1

Для написания самого бота лучшим решением было взять язык программирования Python, и библиотеку aiogram, а модель искусственного интеллекта в виде нейросети архитектуры GPT 3.5 взял с hugging face ресурса. Причем интеграция заняла совсем немного времени. У них реализован функционал получения API подключения по токену. Иными словами, даже модель загружать не требуется ?

Для формирования толковой базы слов и определений, я использовал обычную кнопку «Add word» и 2 шаговый запрос у пользователя: в первом поле нужно внести слово, затем его определения.

По нажатию кнопки «Get word» идет простая рандомная выгрузка случайного слова из базы. Такой механизм уже по теории вероятности позволит повторять знакомые слова, при этом, предсказать порядок их выдачи не получится. Только понимать и повторять, только хардкор!

База данных слов и определений это обычная таблица, в которой 3 столбца: id, word, definition. В таблицу просто вносятся текстовые данные и ничего сверхъестественного.

Вот такой изящный способ записывать свои слова в базу. Да, придется поработать, предзаписанных форм нет, для освоения языка полезнее пополнять библиотеку слов самостоятельно. Словари пользователей не пересекаются, так как каждое слово и определение привязано к id пользователя.   Возможно, что чем больше пользователей и слов, тем база данных должна быть совершеннее, но это же пет – он пока еще маленький, потом вырастет и подумаем о новой базе для него. Может и стоит сделать общую глобальную базу данных, добавить элемент челленджа?

Шаг 2

В чем же уникальность и использование искусственного интеллекта? Была просто добавлена кнопка «Chat», где включается режим беседы с обученной нейросетью архитектуры  GPT.  Самое приятное в этой модели, что она отвечает на все, что ты ей напишешь. Если не верно использовать слово, то и ответ скорей всего будет отвлеченный от темы. Это помогает использовать слова и конструкции верно, искать варианты, пока не добьешься взаимопонимания. Побочка обучения на векторах с учетом большой памяти контекста. Или, все таки, не баг, а фича?)

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

Думаю, что скоро найдется время доработать некоторые логические моменты, вычистить код, и можно публиковать бота для всех тех, кто хочет учить английский, ну или как-то тихонечко поддерживать свой уровень. Добавлю разные украшения, красиво отредактированный текст для показа слов и определений в стиле Oxford Dictionary, другие визуальные решения, но это задачка на подумать. Проект получился рабочий и механика очень простая.

Почему для меня наличие пет-проекта – такая отдушина

Сейчас я, полностью погружен в работу над своим большим проектом cvcode.ru – это система развития интеллекта человека с помощью искусственного интеллекта.

Да, над проектом работаю не один, это 14 человек, каждый на своем участке, но каждый их кусочек деятельности нужно собрать в единую рабочую картину. CVCODE забирает гораздо больше творческих сил, чем можно подумать, а результат некоторых разработок виден только через 6-7 месяцев.

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

Уверен, что такие небольшие домашние проекты спасают от стресса и выгорания. Когда все идет не так, запустил сервер, выгрузил своего питомца, подчистил ему код, и сразу на душе как-то радостнее.

Ознакомиться со страницей проекта на гитхабе можно здесь:

В первые дни Того-о-чем-Нельзя-Говорить я упёрся в классический для многих список: Турция, Грузия, Армения, Казахстан. Потому что близко, понятно. Но нужен был анализ, в первую очередь по налогам.

В первый раз

Пошёл беглый анализ. Меня интересовало общее положение дел + сколько в среднем живут мужчины (ага, это важно) + условия получения паспорта и его сила.

Турция дешево, опасно, безвиз 3 месяца. Маловат безвиз, да и с языком беды. Оставил на всякий случай. С налогами дорого и гемор.

Армения не звучала как что-то интересное, может имидж для меня у неё сложился не очень. Условия по ИП не вкусные.

Казахстан уже поинтереснее, там есть виртуальная зона где можно зарегать фирму и иметь 0% на инком. Впрочем, есть и доп налоги. Сейчас уже плохо помню условия по налогам, только помню что в итоге…

Первым пунктом высадки была выбрана Грузия: 1% налога на доход + лёгкое и самостоятельное ведение налоговой отчётности. Топ-8 по лёгкости ведения бизнеса (ныне этот рейтинг упразднён авторами ввиду 2-3 скандалов со взятками).

Получение паспорта при этом отошло на второй план, ибо это дело долгое, а жить и кушать хочется сейчас.

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

И во второй

В Тбилиси было неплохо, хоть и с кучей но. Но в определённый момент Казахстан начал выгонять русских. Потом Турция. И я занервничал что Грузия поступит так же.

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

Уехали мы с веб разрабом, с ним же и начали пилить. Несколько дней ушло на обсуждение. Я предлагал любимый мной друпал, но понимая что технология сильно устарела не очень-то настаивал. Он топил за strapi (позже я буду дразнить его за этот выбор, не ориентируйтесь на гитхаб-звёздочки при выборе технологии!). Выбрали именно страпи. Всё еще думаю что друпал бы не потянул задачу.

От тех 3-5 параметров которые рассматривались на старте не осталось и следа. Теперь их полсотни, и это по плану только половина.

Уперевшись в очередной баг (их было много, самый смешной: слева указан максимум параметра, справа минимум) я пошёл копать как исправить этот самый страпи. Не накопал. Зато один человек (здровья ему) упомянул некий directus. Я запросил демку с сайта, немного полазил, решили попробовать. Причины такие:

1. Лучше архитектура админки. Вложенности, связи, куча всякого.
Сейчас я понимаю что без перехода — с таким количеством данных — я бы просто умер или сошёл с ума при заполнении.
2. Можно накатить прямо поверх страпи. Пару дней заняло восстановить связи.
3. Он ВООБЩЕ бесплатный, а не с условиями как страпи.
4. Директус куда больше напоминал мне друпал. Люблю друпал.

На этом моменте я окинул глазами статью и понял что хватит.

Из России я переехал в Грузию. Со Страпи на Директус. Доволен ли? Вроде да и да. На последок первая версия passport.help:

Это — перевод оригинальной статьи «How I built my first Open Source project with ChatGPT and Next.js. 10k users in 24 hours» автора Iuliia Shnai. Далее повествование ведётся от лица автора.

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

Друзья посоветовали мне начать с написания проектов с открытым исходным кодом и помогли мне с первыми настройками проекта.

Практически на каждом шаге я использовал ChatGPT, чтобы разобраться, как настроить что-то, как установить и подключить API или как понять, что означает код.

Теперь я расскажу немного больше о первом проекте, который я создал.

Этапы разработки проекта

1. Настройка среды.
2. Поиск проектов с открытым исходным кодом и разработка на их основе.
3. Разбор кода.
4. Создание проекта.
5. Отправка проекта на GitHub.
6. Публикация поста о проекте в социальных сетях.

Мне потребовалась неделя, чтобы разобраться во всем и запустить проект в Linkedin.

На настройку ушли 1-2 часа, для управления кодом из открытых проектов потребовалось 3-4 дня, а для размещения на GitHub и Vercel потребовался один день.

Какой проект я создал

Я сделал генератор постов Linkedin, который использовал ИИ.

Вот ссылка на него на GitHub:

Вы можете использовать его, чтобы создать свой собственный генератор постов.

Почему генератор постов Linkedin

В первое время я проводил эксперименты на Linkedin.

Я тратил много времени на написание постов на Linkedin. По крайней мере, у меня уходил час на каждый пост, и искал способ упростить написание.

Итак, я провел анализ постов более 100 разных авторов на Linkedin и 300 различных промптов, чтобы найти способы генерации эффективных постов.

Теперь я расскажу об основных шагах разработки, которые я делал поэтапно.

Шаг 1. Настройка среды

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

В этот момент слова “менеджер пакетов” были мне неизвестны.

Как я понимаю, tea помогает установить Node.js, npm, Vercel и любые другие пакеты, которые понадобятся для разработки.

Настройка Next.js с использованием TypeScript и Tailwind CSS

У меня было базовое представление о том, что понадобится мне для фронтенда.

Мне подсказали начать с создания нового проекта Next.js. Также я использовал TypeScript и Tailwind CSS, поэтому следовал этим шагам:

Шаг 2. Поиск проектов с открытым исходным кодом и разработка на их основе

Я использовал два проекта с открытым исходным кодом:

Алгоритм Twitter, чтобы оценивать посты пользователей на Linkedin.

Генератор био в аккаунтах Twitter. Он помог мне разобраться, как подключить OpenAI и генерировать посты для Linkedin с помощью GPT. В проекте по ссылке он генерировал информацию в био для аккаунтов.

Я загрузил эти проекты в виде zip-архивов на свой компьютер.

Шаг 3. Разбор кода

Я был немного шокирован тем, что увидел, и сперва не мог ничего понять.

Поэтому я обратился к ChatGPT и спросил о базовой структуре моего приложения.

Я скопировал код каждой страницы и спросил, что он делает. Также я спрашивал, как вносить изменения в код.

Таким образом, я начал понимать, где находится фронтенд приложения и CSS.

Некоторые из вопросов, которые я задавал ChatGPT, были очень простыми, зато сейчас они мне полностью понятны.

В те моменты я задавал все вопросы, даже откровенно глупые.

Шаг 4. Создание проекта

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

Приложение состоит из двух частей: Ранжирование + Генератор.

Алгоритм генерации постов для LinkedIn

Ранжирование – это оценка вашего сообщения на основе различных критериев, которая повышает его эффективность.

Я адаптировал алгоритм ранжирования постов из Twitter для LinkedIn, использовав следующие функции:

1. Функция для обнаружения нескольких хэштегов.
2. Функция для обнаружения изображений или видео.
3. Функция для обнаружения URL-адресов в сообщении.
4. Функция, которая предпочитает сообщения, содержащие эмодзи.
5. Функция для продвижения негативного контента.
6. Функция для приоритетного форматирования постов.
7. Функция для сокращения длины строки.
8. Функция для задавания вопросов.

В отличие от алгоритма Twitter, алгоритм LinkedIn не является общедоступным.

Интерфейс пользователя алгоритма

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

API OpenAI и генератор промптов

Я использую функцию обработчика handlePrompt для создания поста. Также применяется фильтр по типам, поэтому у меня есть 5 различных промптов в зависимости от типа.

Я просто подключил свой API OpenAI для этого.

Интерфейс генератора

Это мой индекс-файл. Он относится к генератору постов.

Шаг 5. Отправка проекта

После того, как я внёс изменения в исходные проекты, я был готов к отправке собственного приложения на GitHub.

Я создал репозиторий.

Затем я создал аккаунт на Vercel, чтобы отправить проект и проверить наличие ошибок.

Каждое обновление я отправлял при помощи команды:

Для поиска ошибок я использовал ChatGPT. Он очень помог в исправлении ошибок, ведь я даже не понимал, как искать их.

Шаг 6. Распространение в социальных сетях и сбор обратной связи

Поскольку это был проект для LinkedIn, я разместил пост там, и он стал вирусным, набрав 200 тыс. просмотров. У него даже появились хэйтеры. 🙂

Статистика за первые 24 часа:

1. 20000 просмотров на LinkedIn.
2. 7000 просмотров веб-сайта.
3. 600 лайков.
4. Более 11000 сгенерированных постов.
5. 3+ хэйтера.
6. 3+ предложений о совместном проекте.

Что я делаю сейчас

Я создаю различные микро-инструменты и вношу вклад в существующие проекты с открытым исходным кодом.

Вот один из новых проектов с открытым исходным кодом, над которым я работаю.

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

Преимущества Docker

Изолированность

Каждый Docker контейнер работает независимо. Это значит, что приложение будет работать одинаково в любой системе, на которой запущен Docker, независимо от установленных на этой системе библиотек и другого программного обеспечения. Это особенно полезно для парсеров, поскольку они могут требовать конкретные версии библиотек или других зависимостей.

Переиспользование

Docker позволяет создать образ, который затем может быть использован для создания новых контейнеров. Это означает, что вы можете настроить все необходимые для парсера зависимости один раз, а затем использовать этот образ для быстрого и легкого создания новых экземпляров парсера. В реальности многие сайты сопротивляются скрейпингу, потому умеют блокировать IP. Сменив виртуальную машину и обновив правила неактивности паука, вы потратите минимум усилий на восстановление работоспособности проекта.

Все это делает продукт идеальным инструментом для масштабирования приложений. Если ваш парсер должен обрабатывать большой объем данных, вы можете просто создать дополнительные контейнеры для распределения нагрузки.

Безопасность

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

Управление версиями и обновлениями

Docker позволяет легко управлять версиями и обновлениями приложений. Вместо ручного обновления каждого экземпляра парсера вы можете просто обновить Docker-образ и затем обновить его на всех машинах.

Недостаток Docker

В 2023 году все же бытует мнение, что Docker – трата времени. Полагаю, в таких случаях речь шла о готовом контейнере с очень нужным кодом: его нашли на просторах сети и развернули один раз, попутно ругаясь из-за возможных ошибок при подъеме контейнера.

Проект: паук HeadHunter на Docker

Поисковый робот (веб-паук, краулер) — программа, являющаяся составной частью поисковой системы и предназначенная для обхода страниц Интернета с целью занесения информации о них в базу данных поисковика.

Пользователь GitHub с ником undadasea реализовал проект поиска вакансий на hh.ru с помощью docker и PostgreSQL:

Если верить описанию, код проекта сохраняет вакансии в базу данных PostgreSQL в контейнере Docker. Так что мы определенно имеем дело с типовым пауком. Если вакансии больше нет на сайте, она помечается в базе данных как «закрытая». Мониторинг проводится раз в сутки.

Простым набором команд мы клонируем репозиторий на свою машину:

А затем разворачиваем контейнер:

И это все, как же радует такая лаконичность! Конечно, я опустила момент дотяжки алгоритма поиска под свои поисковые запросы, но об этом лучше написать отдельную статью.  Как вы уже догадались, помимо пауков в Docker упаковывают и другие категории ПО:

• серверы, вроде Redis, Jenkins
• базы данных, например, MongoDB
• фреймворки машинного / глубокого обучения, такие как PyTorch, Tensorflow

Если верить статье datadoghq.com, несмотря на разногласия в комьюнити, Docker все же прижился в 25% IT-компаний:

Более того, вероятность его использования возрастает с ростом инфраструктуры:

Вывод получается “с разветвлением”: если ты работаешь над крупным проектом, тебе, скорее всего, потребуется Docker, будь то паук или другой микросервис. В случае индивидуальных экспериментов разворачивание контейнера, хоть и демонстрирует преимущество в разрезе безопасности и воспроизводимости, легко становится тратой драгоценных ресурсов разработчика.

CRM позволит вам добавлять новых пользователей или клиентов в базу данных PostgreSQL, просматривать их данные на панели инструментов, создавать шаблоны электронной почты с помощью ChatGPT и отправлять им электронные письма через Sendinblue.

В этом руководстве мы будем использовать ToolJet для интерфейса приложения.

Дисклеймер: это — перевод оригинальной статьи Building an intelligent CRM using ChatGPT, PostgreSQL, and ToolJet автора Shubhendra Singh Chauhan.

Что такое ToolJet

ToolJet — это low-code фреймворк и открытым исходным кодом, который позволяет нам создавать веб-приложения с полным стеком за несколько минут.

С помощью ToolJet вы можете создавать автономные полнофункциональные приложения или встраивать приложения в другие веб-сайты.

ToolJet позволяет создавать приложения, использующие реляционные и нереляционные базы данных, REST API, технологии OpenAI и облачные хранилища, такие как Google Cloud Storage, AWS S3 и Minio.

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

Настройка базы данных ElephantSQL (PostgreSQL)

ElephantSQL позволяет создавать базы данных PostgreSQL в облаке, а не на вашем локальном компьютере. Выполните следующие действия, чтобы создать базу данных PostgreSQL.

Создайте учетную запись ElephantSQL здесь.

Добавьте новую базу данных. Информация о банковских картах или платежных реквизитах не требуется.

После создания БД отобразится вся информация о ней. Далее создадим интерфейс приложения и подключим базу данных.

Создание приложения с помощью ToolJet

Если вы новичок в ToolJet, и никогда не регистрировались в сервисе, создайте учетную запись.

После этого создайте рабочую область и новое приложение под названием CRM-приложения.

Создайте пользовательский интерфейс, подобный изображенному ниже.

Чтобы создать пользовательский интерфейс, сначала добавьте большой контейнер, в котором будут размещены все остальные элементы интерфейса приложения.

В контейнер добавьте три элемента-контейнера поменьше в верхней части страницы: для этого нажмите кнопку «Добавить интерфейс» и выберите элемент «Таблица».

В ToolJet можно создавать интерфейсы через перетаскивание элементов на рабочую область.

После создания пользовательского интерфейса добавьте в таблицу кнопку «Действие» с текстом «Отправить электронное письмо». Мы настроим кнопку позже, она будет отвечать за отправку электронных писем пользователям.

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

Для этого воспользуемся компонентом Modal. Откройте окно Modal и нажмите кнопку «Добавить лид» для добавления новых данных. После этого нажмите кнопку «Отправить электронное письмо» для ввода содержимого электронной почты для пользователя.

Модальное окно «Добавить новый лид»

Чтобы отобразить модуль «Добавить новый лид», вам нужно создать окно модуля и добавить событие onClick к кнопке «Добавить лид».

Добавьте следующие компоненты в окно модуля и не забудьте закрыть его при нажатии модальной кнопки.

Модальное окно «Отправить письмо»

Окно «Отправить электронное письмо» позволит нам ввести адрес электронной почты пользователя, его тему и содержание.

Вы также сможете создавать содержимое электронной почты с помощью ChatGPT API. Вы узнаете, как это сделать, чуть позже.

В окне есть тумблер с событием onChange, которое скрывает подсказки от ChatGPT и кнопки с генерацией, когда они вам не нужны.

Не забудьте закрыть модуль перед тем, как нажать кнопку «Отправить электронное письмо».

Как взаимодействовать с базой данных PostgreSQL в ToolJet

ToolJet позволяет взаимодействовать с внешними ресурсами или создавать собственные функции через панель запросов. В ToolJet любая функция, которая взаимодействует с базой данных, API или облачным хранилищем и запускает код JavaScript или Python, называется запросом.

Здесь вы узнаете, как взаимодействовать с базой данных PostgreSQL в ToolJet. Во-первых, подключим базы данных PostgreSQL к ToolJet.

Подключение базы данных PostgreSQL к ToolJet

Выберите PostgreSQL из списка баз данных на панели «Глобальные источники данных» и предоставьте необходимую информацию.

На изображении выше хост совпадает с именем сервера в ElephantSQL (за исключением скобок). Имя пользователя и имя базы совпадают. Пароль нужно просто вставить в нужное поле.

Прокрутите страницу вниз и нажмите «Проверить подключение».

Если соединение проверено, мы можем делать запросы к БД.

Запрос базы данных PostgreSQL в ToolJet

Прежде чем мы начнем, добавим некоторые данные в базу данных.

Щелкните PostgreSQL на панели запросов, выберите режим SQL и запустите приведенный ниже фрагмент кода, чтобы создать новую таблицу с данными.

Вы можете просмотреть данные на ElephantSQL после их загрузки.

Затем переименуйте запрос в getTableData и обновите редактор SQL, чтобы отобразить все содержимое таблицы. Сохраните запрос.

Обновите компонент Table, чтобы отобразить данные, полученные из запроса getTableData.

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

Создайте три новых запроса на основе базы данных PostgreSQL с именами getLeadsCount, getProspectsCount и getCustomersCount.

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

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

Наконец, включите переключатель «Выполнять этот запрос при загрузке приложения?» для getTableData и трех других запросов.

Добавление новых пользователей в базу

Создайте новый запрос, связанный с PostgreSQL, который принимает значения из модуля и отправляет запрос SQL для добавления данных в БД.

Убедитесь, что имена из фрагмента кода ниже соответствуют именам компонентов из модального окна. Скопируйте этот код в панель редактора SQL и сохраните запрос.

Теперь добавьте событие onClick к кнопке «Добавить лид», чтобы запрос выполнялся при нажатии кнопки.

Как общаться с ChatGPT в ToolJet

Здесь вы узнаете, как общаться с ChatGPT через OpenAI в ToolJet.

Настройка учетной записи OpenAI

Войдите или создайте учетную запись OpenAI здесь.

Нажмите «Personal» на панели навигации и выберите «View API keys» в строке меню, чтобы создать новый секретный ключ.

Создайте новый ключ API и скопируйте его куда-нибудь. Мы используем его позже.

Взаимодействие с API OpenAI в ToolJet

На вкладке «Глобальные источники данных» на панели инструментов нажмите «Плагины» и выберите «OpenAI». Затем вставьте свой ключ API и идентификатор организации в поля ввода и проверьте соединение.

Теперь вы можете получить доступ к источнику данных OpenAI из панели запросов.

Если у вас нет идентификатора организации, используйте «Personal».

Выберите OpenAI на панели запросов и настройте его содержимое для составления электронного письма с использованием ChatGPT.

Запускайте запрос, когда пользователь нажимает кнопку «Спросить» в модуле.

Наконец, чтобы автоматически отображать адрес электронной почты пользователя в окне модуля, установите значение по умолчанию для ввода электронной почты получателя на {{components.table1.selectedRow.email}}.

Как отправлять электронные письма через Sendinblue API в ToolJet

Sendinblue — это инструмент цифрового маркетинга, который предоставляет электронную почту, SMS, Facebook, чат и многое другое через одну платформу, чтобы помочь развитию бизнеса за счет укрепления отношений с клиентами.

Для начала, вам нужно войти в систему или создать учетную запись SendinBlue.

Выберите SMTP и API на панели инструментов, создайте ключ SMTP и скопируйте его куда-нибудь. Он понадобится нам в ближайшее время.

Вернитесь в приложение ToolJet, добавьте новый источник данных SMTP и введите необходимые учетные данные. Ваш пароль — это сгенерированный ключ SMTP.

При успешном подключении будет отображаться «Подключение подтверждено». Затем вы можете начать отправлять электронные письма.

Затем создайте запрос для отправки писем. Укажите свой адрес электронной почты, имя, адрес электронной почты получателя, тему и компоненты заголовка.

Сохраните запрос и запустите его, когда нажата кнопка «Отправить письмо».

Вот рабочая демонстрация приложения:

Заключение

ToolJet — отличный инструмент разработки с открытым исходным кодом, и его код легко доступен для изменения и улучшения.

У него большое сообщество разработчиков, которые постоянно поддерживают и улучшают ПО. Как пользователь, вы можете быть уверены, что получите максимальную производительность при использовании ToolJet.

Вы заинтересованы в сотрудничестве с ToolJet? Не стесняйтесь проверять репозиторий GitHub и вносите свой вклад в разработку.

Вот как выглядит геймплей.

Чтобы реализовать такое, Lukneu создал мод, который запускает игру на ПК, одновременно передавая видеосигнал на телевизор и вообще на все устройства, которые умеют принимать телетекст.

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

Проект Teletext Doom работает на Linux, а исходники выложены на GitHub.

Телетекст — это стандарт для передачи простых информационных пакетов с текстом с помощью широковещательных сигналов через обычную антенну.

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

Это сайт позволяющий быстро писать и исполнять SQL запросы к различным популярным базам данных, таких как MySQL, MariaDB, PostgreSQL, SQLite, Oracle и Microsoft SQL Server.

Также здесь вы можете написать и исполнить код на языке PHP, который будет обращаться к базе данных и выполнит запросы указанные в коде.

Идея проекта зародилась в процессе моего волонтёрства на Stack Overflow, где принято демонстрировать свой код онлайн с возможностью моментального запуска без дополнительной подготовки.

Существует много подобных сайтов для кодирования на различных языках программирования. Есть отличные площадки для SQL и для PHP, но ни на одной из них невозможно работать с базами данных в совместно с другими языками программирования. Я же отвечал людям, имеющим вопросы по очень популярному стеку PHP + MySQL, и не имел возможности сопроводить ответ живым примером кода. В результате я решил эту проблему, запустив свой проект. Как в анекдоте про типичного программиста который не нашёл нужный драйвер и написал его сам.

Посмотрите что получилось в итоге: PHPize.online – это сайт (совершенно бесплатный) для написания, исполнения и совместного использования кода на языках программирования PHP и SQL.

Сайт имеет две панели для редактирования. Обе панели используют редактор Ace.js для подсветки и автодополнения кода. Слева расположены редактор для кода SQL, элемент выбора СУБД кнопка запуска кода и блок результатов его исполнения. Изначально сайт был рассчитан только на MySQL, но позже мне удалось добавить и другие популярные СУБД (используя докерную контейнеризацию). Таким образом, чтобы протестировать какой-либо SQL запрос, вы пишете или вставляете его в редактор, выбираете версию SQL и нажав кнопку «Run SQL code» или Ctrl +Enter (если Вы поклонник горячих клавиш) и через секунду (или чуть более если Вы написали сложный запрос) получаете результат на экране.

Правая панель такой же редактор, но уже для PHP. Здесь так же можно набрать или вставить из буфера код и попытаться его исполнить в выбранной версии интерпретатора.

Если нужно поделиться своим фрагментом кода с кем-либо, вы можете просто скопировать текущий URL адрес страницы или нажать кнопку «Share» получить сокращенный адрес прямо в буфер обмена. Любой кто откроет Вашу ссылку увидит тот же код что видите Вы.

Теперь о том что делает проект уникальным — здесь в коде PHP вы можете запросить базу данных, которую вы только что создали в левой панели. Использовать библиотеки mysqli для интеграции с MySQL и MariaDB или PDO и Laravel Query builder для взаимодействия с другими СУБД. Вы также можете выбрать, версию PHP для исполнения кода (включая последний PHP 8.2).

Вторая уникальная особенность проекта PHPize.online — это интеграция с ИИ помощником на основе ChatGPT. Как в случае ошибки в SQL запросе, так и при ошибке в коде PHP вместе с кодом ошибки вы увидите кнопку и приглашение исправить ошибку автоматически. Стоит Вам нажать эту кнопку и ИИ предложит вариант исправления.

Я должен отметить что помощь не всегда идеальна, но во многих случаях помогает сократить время на отладку кода.

Если Вам понравился проект, Вы можете поддержать автора.

Вот, чем вы занимались на прошлой неделе.

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

Кидайте всё, чем хочется похвастаться: текст, скриншоты кода и даже ссылочки на видео.

Не забывайте про NDA: не указывайте названия компании или деликатные частности.

Итак, чем вы похвастаетесь на этой неделе?

Внимание Это — зона взаимного уважения, понимания и нулевого токсика. Похвала и помощь горячо приветствуются.

Вот, чем вы занимались на прошлой неделе.

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

Кидайте всё, чем хочется похвастаться: текст, скриншоты кода и даже ссылочки на видео.

Не забывайте про NDA: не указывайте названия компании или деликатные частности.

Итак, чем вы похвастаетесь на этой неделе?

Внимание Это — зона взаимного уважения, понимания и нулевого токсика. Похвала и помощь горячо приветствуются.

Вот, чем вы занимались на прошлой неделе.

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

Кидайте всё, чем хочется похвастаться: текст, скриншоты кода и даже ссылочки на видео.

Не забывайте про NDA: не указывайте названия компании или деликатные частности.

Итак, чем вы похвастаетесь на этой неделе?

Внимание Это — зона взаимного уважения, понимания и нулевого токсика. Похвала и помощь горячо приветствуются.

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

Кидайте всё, чем хочется похвастаться: текст, скриншоты кода и даже ссылочки на видео.

Не забывайте про NDA: не указывайте названия компании или деликатные частности.

Итак, чем вы похвастаетесь на этой неделе?

Внимание Это — зона взаимного уважения, понимания и нулевого токсика. Похвала и помощь горячо приветствуются. ?

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

Также автор этого чуда составил комбинации клавиш, которые можно получится «ввести». Правда, там пока нет цифр, но автор говорит, что «можно заменить на них некоторые из букв».

Теперь можно прочувствовать каждую букву всей душой.

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

Кидайте всё, чем хочется похвастаться: текст, скриншоты кода и даже ссылочки на видео.

Не забывайте про NDA: не указывайте названия компании или деликатные частности.

Итак, чем вы похвастаетесь на этой неделе?

Внимание Это — зона взаимного уважения, понимания и нулевого токсика. Похвала и помощь горячо приветствуются. 🙂

1. Создаём Spring проект на Java
2. Реализация базового функционала
3. Добавление кнопок
4. Подключение Telegram-бота на Java к базе данных
5. Создание исполняемого jar-файла в Intellij IDEA
6. Выводы

Создаём Spring проект на Java

Для этого воспользуемся сервисом быстрого создания Spring Initializr: он предоставляет интерфейс для генерации заготовки проекта с добавлением стандартных зависимостей. При необходимости в дальнейшем их можно настроить под свои нужды.

Мои настройки Spring Initializr выглядят так:

Обратите внимание на кнопку Add Dependencies: с её помощью можно добавить важные зависимости уже на старте.

После того, как вы всё указали, нажмите Generate, разархивируйте стартовый проект и откройте его с помощью удобной IDE. У меня это IntelliJ IDEA.

Реализация базового функционала

Для начала напишем на Java самый примитивный Telegram bot, который будет отвечать на наши сообщения.

Создание Telegram-бота и конфигурация

Начнём с того, что это Maven-проект. Сразу добавим в pom.xml дополнительные зависимости для работы с Телеграм ботом и базами данных:

• Telegram Bots
• Hibernate Core Relocation
• PostgreSQL JDBC Driver
• Lombok

В каталоге resources создадим файл config.properties, где будут храниться данные для подключения к боту и в будущем к БД.

Примечание Данный файл не следует включать в коммиты.

Теперь создадим бота. Для этого перейдём в Telegram в BotFather и создадим нового бота командой /newbot. Выбираем для него название, которое будет отображаться для всех, и его username. После этого BotFather выдаст токен для взаимодействия с бэкендом Телеграмма.

Теперь запишем в файл config.properties следующее:

Добавим в основной каталог проекта пакет config, а внутри него создадим новый класс BotConfig.

Вы наверняка заметили, что мы добавили в pom.xml Lombok. Это популярная библиотека для сокращения кода и расширения функциональности Java. С ней и Spring наш класс BotConfig будет выглядеть очень лаконично:

Что здесь происходит?

1. @Configuration указывает, что класс содержит методы определения @Bean (наши @Value).
2. @Data на этапе компиляции генерирует для всех полей геттеры, сеттеры, toString и предопределяет equals и hashCode.

С остальным, думаю, всё понятно.

Класс Телеграм бота на Java

Давайте теперь выйдем из пакета config и создадим в основном пакете проекта класс бота. Поскольку это бот-счётчик, назовём его CounterTelegramBot.

Сразу унаследуемся от TelegramLongPollingBot — класса, который позволяет взаимодействовать с Telegram. И имплементируем методы getBotUsername, getBotToken и onUpdateReceived. Создадим конструктор и добавим две аннотации перед классом: @Component (авто-создание экземпляра) и @Slf4j (для работы с логером).

На старте получаем следующий класс:

Для начала сделаем так, чтобы на команду /start Telegram-бот что-то нам отвечал и выводил в логи сообщение об успехе. Другие сообщения будут выводить в логи "Unexpected message":

И последним штрихом является инициализация бота. Добавим в пакет config класс Initializer:

1. @Autowired обеспечивает контроль над тем, где и как осуществить автосвязывание (чтобы Spring автоматически подключил бота).
2. @EventListener — слушатель, который вешаем на изменение класса.

Запустите и проверьте работу бота.

Примечание Если возникает ошибка Failed to configure a DataSource, измените аннотацию в исполняемом классе на @SpringBootApplication(exclude = {DataSourceAutoConfiguration.class}). Ошибка исчезнет, как только мы добавим информацию для доступа к БД в config.properties.

Добавление кнопок

Чтобы Telegram bot на Java и Spring Boot выглядел по-настоящему серьёзным, давайте добавим ему команду /help и пару кнопок.

Создадим в основной директории проекта пакет components. В него добавим:

1. Интерфейс BotCommands:

2. Класс Buttons:

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

Теперь немного улучшим класс CounterTelegramBot:

switch вынесли в отдельный метод, добавили обработку команд, в том числе и нажатие кнопок.

Подключение Telegram-бота на Java к базе данных

Перед началом работы установите PostgerSQL, если СУБД ещё не установлена. В случае, если вы работаете с другими СУБД, просто измените настройки доступа в файле config.properties. Для тех же, кто работает с PostgerSQL, config.properties будет выглядеть примерно так:

В директорию проекта добавляем пакет database. В нём следует создать:

1. Класс User:

2. Интерфейс UserRepository:

Данный интерфейс нам нужен для удобной работы с CrudRepository — интерфейсом данных Spring для общих операций CRUD. Сюда же вшиваем запрос на апдейт нашей таблицы: добавление +1 сообщения пользователю в случае, если он написал в чат.

В классе CounterTelegramBot объявим новый интерфейс с аннотацией @Autowired, которая говорит Spring, что в это поле нужно инжектнуть бин:

Там же создаём метод добавления пользователя в базу данных, если он написал впервые, и просто обновление столбца сообщений, если пользователь уже существует:

Финально обновим метод onUpdateReceived в классе CounterTelegramBot:

Примечание Вы можете не делать ограничение по chatId, но тогда следует дополнительно прописать логику для создания отдельной таблицы под каждый чат. В моём случае бот писался под конкретный чат.

Важно Не забудьте предоставить боту права администратора чата.

Создание исполняемого jar-файла в Intellij IDEA

У Telegram API есть одно неприятное ограничение, в соответствии с которым наш бот на Java позволяет достучаться только до сообщений, отправленных за последние 24 часа. Всё, что было отправлено раньше, не учтётся.

Поэтому после вы можете либо создать exe-файл с установкой времени выполнения, либо воспользоваться удалённым сервером. Например, в статье о Telegram-боте на Python мы рассказали, как настроить Docker и задеплоить бота на AWS.

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

Инструкция по созданию jar-файла:

1. File – Project Structure – Project Settings – Artifacts – Кликаем по кнопке + – Jar – From modules with dependencies.
   
2. Выбираем главный класс проекта и жмем ОK.
   
3. После этого собираем Jar файл: Build – Build Artifact.
4. Это создаст .jar, который при двойном клике запустит JVM, если она установлена в ОС.

На первом же скрине вы можете посмотреть структуру проекта.

Выводы

Создание Telegram-бота на Java возможно благодаря специальному классу TelegramLongPollingBot, а Spring Boot и Lombok сильно упрощают этот процесс.

Но стоит отметить, что тот же бот, написанный на Python или PHP, обойдётся вам в меньшее количество строк кода, да и туториалов по таким Телеграм-ботам значительно больше. А вот в качестве практики Java и небольшого пет-проекта, который можно представить в своём резюме, такая программа вполне подойдёт.

Остались вопросы? Задавайте их в комментариях к этой статье.