Ответ на пост «Фронтендер Гриша»
И так еще один способ. Имхо самым простой. Но 26 секунд. А автор писал про 10 :)
И так еще один способ. Имхо самым простой. Но 26 секунд. А автор писал про 10 :)
Показал что знает ноду, nvm, реакт. Пишет не на js, а на TypeScript - значит понимает что это и зачем. Кучу инфы дал на простом вопросе.
вот кстати такие оверхидеры с предприятия 6 шкур снимают вместо одной. впаривают любимые инструменты, а не тот минимум, который решит проблему.
data:text/html;base64,PGJ1dHRvbj5IZWxsbzwvYnV0dG9uPg==
Эм. Это собеседование! В голове у соискателя появляется простой вопрос: "А зачем на собесе это спрашивать?" Нет ни одной причины такое спрашивать даже у джуна. Да даже блин у школьника.
В этом как бы и суть технических собесов. Задаём простой вопрос и даём человеку раскрыть тему в меру своих знаний.
Устанавливает nvm, через него ставит node.js, потом через yarn ставит vite, создаёт новый проект на React + TypeScript...
Показал что знает ноду, nvm, реакт. Пишет не на js, а на TypeScript - значит понимает что это и зачем. Кучу инфы дал на простом вопросе.
И что ему в ответ? Надо <button>Кнопка</button>? Если собеседующий задаёт такой вопрос и хочет получить на него ответ html <button>Кнопка</button> - он идиот. Надо заканчивать собеседование и делать оттуда ноги.
PS: Идея поста понятна, а вот ситуация с собесом - в корне не верный для неё контекст)
Сделал пост с этой же картинкой, т.к. не знал что ТС есть и на Пикабу.
@imctobitch, прошу прощения больше не повториться.
К картинке я добавил текст "И не только Гриша, И не только фронтэнд... И даже не только программисты..." потому что выдалось 5 минут на одну очень важную тему.
Причины, почему в 99,9 % случаев всё происходит через жопу.
Для почти всех разработчиков будет открытием, что помимо классической классификации софта есть ещё и производственно-эксплуатационная. Есть 4 крайне важные градации:
Штат специалистов
Крупная команда (> 7 человек)
Обычная команда ( 2 - 7 человек)
Один исполнитель
Масштабная:
Крупный проект
Мелкий проект
Разовая задача
Нагрузочная:
Очень много пользователей одновременно (> 10 тысяч)
Нормальная нагрузка (100 - 10к)
Незначительная нагрузка. (< 100)
Периодичность:
Постоянная работа
Работа периодами (например, в рабочее время)
Разовая задача
Так вот - все "как надо" в ИТ сфере обычно подразумевают крупную команду, крупный проект, нормальную нагрузку и постоянную работу.
При этих вводных все эти "чистые коды" работают и иногда даже хорошо...
!!! НО ТОЛЬКО В ЭТИХ УСЛОВИЯХ !!! Во всех остальных условиях следование этим принципам является идиотизмом. Правда этот идиотизм настолько врос в профессию, что многими он воспринимается как должное и естественное.
Пятница, писать лень, так что 3 примера:
Разовая задача. Эта задача которая по тем или иным причинам либо не возникнет снова, или ТЗ будет изменено настолько, что проще написать снова. Тут нужно говнокодить по страшному.
Пример - бывает, что госорганы для своих каких-то целей запрашивают данные. Эти данные могут быть довольно сложно структурированы в БД т.е. руками и простым запросом не решить. Такие запросы НИКОГДА не повторяются. Написали код, выполнили и забыли. Все проектирования классов, тесты и прочая шняга - это время потраченное абсолютно впустую.
Крупный хайлоад. Вы должны писать код так, чтобы он работал быстро. В коде 100 if подряд? если это конкретно здесь работает быстрее - делайте именно так. Потому что от качества работы приложения напрямую зависит количество серверов на котором это всё будет работать. Серверов стоимость которых зачастую примерно равна квартире в каком-нибудь региональном центре.
Менеджеры "от бизнеса" эти нюансы очень остро чувствуют. И 90 % неприязни к ИТ как раз и заключается в том, что у них есть понимание, что эта задача должна стоить Х и делаться за У времени, а по факту бюджеты и сроки перекрываются в разы. И в качестве ответа на вопрос "какого хера?" им рассказывают про SOLID, Agile и далее по списку.
Я не раз наблюдал, когда гендир спокойно подписывает увольнение сеньору, (да ещё и предварительно его спровоцировав на это самое увольнение), но умоляет остаться джуна.
Просто потому что конкретно этот джун понимает что не все задачи нужно делать "по канону".
Разработчики часто не видят ситуацию "в целом". У бизнеса совершенно другие ценности. Бизнесу нужно прежде всего решать свои задачи. И решать их экономически целесообразно.
И в 99 из 100 проектов "каноны" и "мастхэв" ИТ-индустрии для бизнеса это - полный пиздец, которым пользуются исключительно потому, что нет более подходящего предложения.
Могу проиллюстрировать простым примером. Есть "джуновская" булка хлеба, которая "здесь и сейчас" стоит 20 рублей. Купил-съел. Есть "мидловская" хлебопечка, которая делает хлеб получше, но дороже и 4 часа. А есть хлебзавод "сеньора", который хер знает когда построят, стоит дохера и может давать продукт только тоннами.
Так вот, если компания планирует продавать хлеб тоннами, то хлебзавод рулит.
Если компания хочет разок выебнуться, то хлебопечка рулит.
Если нужно просто пожрать, то просто покупается булка хлеба.
А когда "канон должен быть везде", то получается, что в 90 % случаев вы голодный приходите за хлебом, а с вами начинают согласовывать проект хлебзавода...
И менеджер понимает, что ему продают булку хлеба по цене хлебзавода. И самая главная проблема для него в том, что ВСЕ ДОСТУПНЫЕ КАНДИДАТЫ продают именно это. За специалистов, которые могут сопоставлять задачи и способы их решения грамотные HR войны ведут. Потому что найти 50 сеньоров проще, чем 1 такого.
И самое главное - это не уникальная для ИТ ситуация. В других отраслях всё абсолютно то же самое.
Всем привет! Как насчет того чтоб перенять мой опыт?
Сегодня я хочу затронуть две темы, о одной из них мало информации в открытых источниках. Первое - это как я реализовал защиту в Telegram на REST API. Второе - это какие дыры есть в Mini App Telegram.
Я разрабатываю Mini App в Telegram, это такая штука открывающаяся внутри бота и есть внутрение приложение Telegram.
Стояла задача разработать приложение с админкой, тратить время на развертывание сервера, налаживание и его защиту не было времени. Нужна оперативная работа.
Изучив возможные варианты, выбрал Strapi - это OpenSource проект написанный на Node.js. Развернуть можно как в облаке так и локально. Имеет поддержку русского языка.
Так выглядит админка Strapi
Если в общем, то мой стек используемых инструментов выглядит следующим образом:
Telegram App ( Библиотека )
Strapi ( Админ панель + REST API )
PostgreSQL ( База данных )
Next.js ( Само приложение )
Стек технологий
Решение с защитой что я предлагаю подойдет каждому. Главное понять его принцип.
Когда пользователь открывает веб-приложение через Telegram, ваше приложение получает начальные данные от самого Telegram, такие как идентификатор пользователя и его имя. Чтобы убедиться, что эти данные подлинные и не были изменены, используется специальный процесс проверки.
Преобразование данных: Приложение преобразует начальные данные в удобный формат.
Создание строки для проверки: Из всех параметров (кроме специального hash) создается отсортированная строка.
Создание секретного ключа: С помощью токена вашего бота создается секретный ключ.
Создание цифровой подписи: Используя секретный ключ и строку параметров, создается цифровая подпись.
Сравнение подписей: Приложение сравнивает созданную подпись с полученной от Telegram. Если они совпадают, данные подлинные.
Этот процесс помогает убедиться, что данные, полученные от Telegram, не были изменены, обеспечивая безопасность вашего приложения и его пользователей.
После успешной валидации я генерировал JWT токен для пользователя и он становился полноценным пользователем в моей системе.
Далее можно с ним делать что угодно 😏 - ну допустим заблокировать его, дать права админа и т.д.
А сам пользователь имеет полный доступ к возможностям приложения. Но вне телеграма он ничего не сделает.
Не буду показывать на конкретном примере, но большинство разработчиков не умеют или не хотят защищать свои приложения, а чисто привязывают все к Telegram ID ( ID вашего аккаунта ) и так и живут.
Telegram ID состоит из цифр и перебрать его методом подбора не составит труда и получить доступ к аккаунту в Mini App.
Зачастую этим грешат новые приложения или не опытные разработчики, например в Telegram Apps Store ваше приложение проверяют на наличие этой защиты.
Кроме того нужно учесть что само приложение не должно никоем образом отображаться в поисковиках, если все взаимодействие выстроено на основе телегерама. Приложения же имеют свой адрес и могут индексироваться, не забывайте выключать!
Кроме всего этого можно запретить вне телеграма заходить в ваше приложение тем же способом что описан выше.
Не важно на каком языке вы пишите, телеграм уже сделал для вас подсказку, осталось ей воспользоваться.
Оставлю ссылку здесь на данный раздел - Документация Telegram
Я надеюсь эта статья поможет тем кто хочет или уже занимается разработкой WebApp на Telegram. Если все еще осталось что-то не понятно, то пишите смело - будем вместе разбираться:)
Если у вас так же останутся вопросы или предложения или вы просто захотите поделиться своим приложением, то пишите! Всегда рад пообщаться с читателями 😁
Из кого состоит команда разработки, кто в нее входит кроме программистов, за какие области отвечает каждый из участников и по каким поводам стучаться к ним в личку
Меня зовут Сергей Горшунов. Я веду блог о финансах
Однажды в жизни каждого человека наступает момент знакомства с такой сферой, как разработка. Причины могут быть совершенно разными: реклама во время подкаста на YouTube, устройство на работу в компанию, где есть IT-отдел, чтение новостей, приход нового человека в компанию друзей и так далее.
Не всем нужно знать, кто такие эти разработчики и чем они занимаются, но для тех, кому все-таки понадобилось понимание специфики работы этих людей, мы подготовили гайд. В нем расскажем об участниках команды разработки, их задачах, по каким поводам к ним обращаться и как понять, о чем они говорят.
К счастью, у большинства проектов за все не отвечает один единственный человек, похожий на Шиву. Команда разработки на то и команда, что в ее состав входит целый коллектив.
Владелец продукта или PO (Product Owner) — это тот, кто занимается управлением продукта. Он является связующим звеном между заказчиком и командой, выступая за интересы первого. На нем лежит подготовка требований по функционалу, постановка задач в бэклог, определение приоритетности выполнения и так далее.
Проектный менеджер или PM (Project Manager) — это управляющий проекта, а не продукта, в отличии от РО. Он координирует действия команды, следит за сроками и контролирует выполнение проекта. РМ дает РО данные о проекте, а РО ему о продукте.
Тимлид — это руководитель команды разработчиков. Его задача в организации работы и контроле за происходящим. Так как он курирует процесс разработки, принимает ключевые решения и помогает подчиненным, то ему нужно понимать во всем. В его компетенции входит как фронт, так и бэк.
Фронтенд разработчик или фронтендер (frontend developer) — это тот, кто наводит красоту и делает нашу с вами жизнь лучше. Он отвечает за части сайта или приложения, с которыми взаимодействует пользователь. Фронтендер берет за основу работу дизайнера и превращает ее в визуальную часть сайта. Правильность отображения кнопок, текста, картинок и других элементов — ответственность фронтенд разработчика.
Бэкенд разработчик или бэкендер (backend developer) — это боец невидимого фронта, работающий над внутренней частью сайта или приложения. Он обеспечивает правильное выполнение команд от пользователя. Если фронт отвечает за правильное подсвечивание и отображение кнопки, то бэк за действие, которое произойдет при нажатии.
UI/UX дизайнер — это создатель плана сайта или приложения с точки зрения визуального наполнения. Дизайнер продумывает логику взаимодействия пользователя с продуктом, размещает контент и после передает свое творение разработчикам.
QA-инженер или тестировщик — это ответственный за проверку работы. Он ищет всевозможные ошибки и сообщает о них. Так как проблемы могут касаться разных частей сайта или приложения, то взаимодействует тестировщик практически со всей командой. Он даже может предложить новое решение для улучшения клиентского опыта или повышения продаж.
DevOps-инженер — это тот, кто упрощает взаимодействие между разработчиками, тестировщиками и менеджерами, ускоряет разработку за счет автоматизации части процессов. Девопс также отвечает за работу сервера и должен гарантировать непрерывность работы. Задача у него непростая, поэтому для понимания сути его работы желательно иметь базовые знания в программировании.
Этот список профессий далеко не исчерпывающий и может включать себя и других сотрудников, но мы остановимся на наиболее популярных и известных, ведь именно с ними проще всего столкнуться в реальной жизни.
Первое знакомство с командой прошло успешно, так что самое время посмотреть на ее жизнь в естественной среде.
Не вникая в процесс разработки, может показаться, что создание ПО происходит по единому скрипту. Однако все не так просто — методологий и принципов разработки существует достаточно много. Чтобы не углубляться в эти нюансы, мы пройдемся по верхам, сформируем общее понимание этапов разработки ПО и расскажем, кто и когда вступает в игру.
Подготовка и планирование
Владелец продукта:
собирает данные о клиентах, рынке и конкурентах;
получает информацию от заказчика;
готовит список целей и определяет задачи;
согласует план проекта с РМ.
Проектный менеджер:
систематизирует собранные данные;
фиксирует задачи и требования от РО и совместно с РО расставляет приоритеты;
согласовывает техническое задание;
готовит план проекта.
Тимлид:
консультирует РО и РМ по технической части;
определяет, что можно реализовать, а что нет;
участвует в формировании задач с точки зрения технической реализации;
определяет технологии и инструменты;
оценивает необходимые ресурсы и время для выполнения поставленных задач;
проверяет и утверждает техническое задание.
Проектирование
Тимлид:
определяет основу архитектуры;
консультирует других участников команды;
принимает ключевые решения по части разработки.
UI/UX дизайнер:
формирует прототип сайта;
готовит основные части;
наращивает дополнительные по мере внесения правок;
финализирует дизайн интерфейса.
Проектный менеджер:
следит за выполнением работ командой и соответствием установленным требованиям.
Разработчики:
помогают дизайнеру с подготовкой прототипа;
вносят правки с точки зрения возможности реализации прототипа.
Разработка
Фронтенд разработчик:
создает внешние части сайта по прототипу от дизайнера.
Бэкенд разработчик:
создает внутреннюю (серверную) часть сайта и работает с базами данных (БД).
Тимлид:
координирует работу разработчиков и помогает со сложными задачами.
DevOps-инженер:
работает над автоматизацией части процессов разработки и обеспечением ее непрерывности.
Тестирование
QA-инженер:
ищет ошибки и передает данные о них разработчикам.
Разработчики:
воспроизводят найденные тестировщиком баги;
исправляют ошибки.
Тимлид:
координирует работу разработчиков и тестировщиков;
помогает со сложными проблемами.
Развертывание
DevOps-инженер:
развертывает приложения на сервере — вывод ПО на сервер с локального хранения (без этого пользователи не смогут взаимодействовать с ПО);
настраивает инфраструктуру — подготовка к началу работы серверов и других технических компонентов;
управляет CI/CD процессами — обеспечение непрерывного процесса разработки, тестирования и развертывания.
Бэкенд разработчик:
принимает участие в настройке серверной части и настройке взаимодействия с базами данных.
Проектный менеджер:
контролирует работу команды и следит за процессами.
Тимлид:
следит за развертыванием, обеспечивает его корректность и помогает другим членам команды.
Поддержка и обновление
Разработчики:
исправляют баги;
разрабатывают и внедряют новые функции.
QA-инженер:
ищет ошибки и передает их разработчикам.
Тимлид:
помогает в решении сложных проблем, которые не удалось разрешить на уровне разработчиков и тестировщиков.
Владелец продукта:
дает обратную связь от заказчика и пользователей;
формирует задачи по новому функционалу;
определяет приоритетность задач.
Проектный менеджер:
организует работы по поддержке и обновлению ПО командой.
Документация
Тимлид:
создает и обновляет техническую документацию кода с описанием технологий, инструментов и библиотек.
Разработчики:
комментируют код и обновляют данные при изменениях.
Проектный менеджер:
следит за актуальностью документации и своевременным обновлением.
Владелец продукта:
готовит документацию для пользователей.
Если в вашем проекте вы не состоите в команде разработки, но вам нужно коммуницировать с ней, то вы можете воспользоваться нашей шпаргалкой с темами и примерами вопросов, которые можно задать.
Тимлид
По техническим возможностям и ограничениям.
«Какие новые функции будут реализованы в будущем?»
«Какие метрики используются для оценки стабильности работы ПО?»
«Есть ли ограничения, которые нужно учитывать при планировании нового функционала?»
Владелец продукта
По функциям, приоритетам задач, дорожной карте и обратной связи от пользователей.
«Можно ли добавить функцию N?»
«Какие функции будут запущены в следующем квартале?»
«Когда будет реализована функция N»?
«Какой план развития у проекта?»
«Развитие каких функций сейчас в приоритете?»
Проектный менеджер
По срокам, графикам, обновлениям, статусам, координации задач и сотрудников.
«Какой сейчас график релизов?»
«Есть ли сейчас задержки по задачам и будет ли реализован новый функционал в срок?»
«Какой сейчас статус у разработки?»
Фронтенд разработчик
По изменениям визуала и интерактивных элементов.
«Можем ли мы поменять фото на главной на анимацию?»
«Как лучше реализовать всплывающие окна?»
«Насколько сложно будет поменять дизайн на сайте?»
«Сильно ли скажется на скорости загрузки внедрение новых анимированных блоков?»
Бэкенд разработчик
По новому функционалу и получению данных.
«Можем ли мы подключить новую аналитику?»
«Можно ли настроить выгрузку определенных данных о действиях пользователей?»
«Как долго будет устраняться баг?»
UI/UX дизайнер
По дизайну, брендингу и улучшению пользовательского опыта.
«Нужно ли нам адаптировать дизайн страницы для повышения конверсий?»
«Как нам оформить новые функции для выделения их среди старых?»
«Мы хотим добавить новый блок, будет ли он удобен для пользователей или нужно подкорректировать?»
QA-инженер
По тестированию новых функций, ошибкам, стабильности и качеству работы ПО.
«У нас запланирована рекламная кампания на следующей неделе, есть ли баги, которые еще не исправлены?»
«Есть ли ошибки, о которых нужно знать?»
«Сколько времени уйдет на тестирование новой версии сайта?»
DevOps-инженер
По стабильности работы сервера, мониторингу производительности системы.
«Выдержит ли сайт повышенную нагрузку при проведении маркетинговой кампании?»
«Можем ли мы настроить мониторинг для отслеживания производительности системы?»
«Что нужно сделать для повышения устойчивости к нагрузке при наплыве пользователей?»
Если вы раньше не общались с представителями IT-сообщества в разрезе работы, то в ходе беседы можете почувствовать себя иностранцем. IT-сфера наполнена собственной терминологией, которую сложно понять без надлежащего опыта. Для вас мы собрали краткий список с популярными словами, которые помогут не потерять нить разговора и стать своим хотя бы на базовом уровне.
Прод — рабочая версия продукта.
Релиз (залить на прод) — выпустить рабочую версию продукта.
Стейдж — среда для тестирования, которая полностью копирует прод.
Баг-репорт — отчет об ошибке.
Проджект — менеджер проекта.
Мок — имитация реального объекта при проведении тестирования.
Спека/дока — документ с техническими требованиями для разработки и тестирования.
Ассайнить — поручить задачу.
Аттач — файл, который прилагается к сообщению.
Грумить — приводить в порядок.
Деплой (развертывание) — совокупность действий, которые делают ПО готовым к использованию на сервере.
Коммит, коммитить — фиксация изменений кода в системе контроля версии (git).
Комплитить — завершить задачу.
Мерджить — объединять изменения от разных программистов в одном проекте.
Патч — временное дополнение к коду.
Пушить — загрузить код в git.
Ребут — перезагрузка.
Темплейт — шаблон.
Фича — функция.
Футер, подвал — элемент сайта в его нижней части.
Хедер — элемент сайта в верхней части.
Бэклог — список задач, которые нужно сделать в будущем.
Спринт — интервал времени, за который нужно выполнить определенный список задач.
Сторя — корневая задача.
Таск, таска — задача.
Апрув, апрувить — согласовать.
Пинговать — напоминать.