Я добавлю. 1. Этот хлебозавод будет производить 8987567 грамм хлеба в день вне зависимости от необходимости. Причем только булочки с корицей. 2. Для булочек с маком нужен другой хлебозавод. 3. При попытке изменить техпроцесс, добавив кунжут - завод встает, пока в радиусе 100 км останется хоть одно зернышко кунжута. 4. Внезапно может встать и требовать апгрейда для лучшей выпечки. После апгрейда запуск возможен после перестройки 50% завода. 5. Внезапно он может встать по причине истекших ТУ на корицу. Запустить можно только после оплаты ТУ на корицу, соль и сахар, после чего требуется замена оборудования для поддержки новых ТУ на сахар. 6. Если попытаться использовать муку другого производителя - он встанет на неделю, после чего главный цех саморазрушится. 7. Если у РФ санкции - хлебозавод начинает перерабатывать муку на дерьмо, не забывая, впрочем, посыпать конечный продукт корицей. 8. Заказчик боится упоминать о том, что ему нужен был чёрный и белый хлеб. Не без оснований. 9. Заказчик проходит все предыдущие пункты, после чего, если ему очень - очень нужен хлеб и остались деньги - начинает печь хлеб вручную.
Это не юмор, это злой сарказм. Гореть в аду этим "сеньорам"!
Эм. Это собеседование! В голове у соискателя появляется простой вопрос: "А зачем на собесе это спрашивать?" Нет ни одной причины такое спрашивать даже у джуна. Да даже блин у школьника.
В этом как бы и суть технических собесов. Задаём простой вопрос и даём человеку раскрыть тему в меру своих знаний.
Устанавливает 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 такого.
И самое главное - это не уникальная для ИТ ситуация. В других отраслях всё абсолютно то же самое.
Такую задачу поставил Little.Bit пикабушникам. И на его призыв откликнулись PILOTMISHA, MorGott и Lei Radna. Поэтому теперь вы знаете, как сделать игру, скрафтить косплей, написать историю и посадить самолет. А если еще не знаете, то смотрите и учитесь.
Всем привет! Как насчет того чтоб перенять мой опыт?
Сегодня я хочу затронуть две темы, о одной из них мало информации в открытых источниках. Первое - это как я реализовал защиту в Telegram на REST API. Второе - это какие дыры есть в Mini App Telegram.
Вводные данные
Я разрабатываю Mini App в Telegram, это такая штука открывающаяся внутри бота и есть внутрение приложение Telegram.
Стояла задача разработать приложение с админкой, тратить время на развертывание сервера, налаживание и его защиту не было времени. Нужна оперативная работа.
Изучив возможные варианты, выбрал Strapi - это OpenSource проект написанный на Node.js. Развернуть можно как в облаке так и локально. Имеет поддержку русского языка.
Так выглядит админка Strapi
Если в общем, то мой стек используемых инструментов выглядит следующим образом:
Telegram App ( Библиотека )
Strapi ( Админ панель + REST API )
PostgreSQL ( База данных )
Next.js ( Само приложение )
Стек технологий
Решение с защитой что я предлагаю подойдет каждому. Главное понять его принцип.
Как я защищал REST API? Валидация данных
Когда пользователь открывает веб-приложение через Telegram, ваше приложение получает начальные данные от самого Telegram, такие как идентификатор пользователя и его имя. Чтобы убедиться, что эти данные подлинные и не были изменены, используется специальный процесс проверки.
Преобразование данных: Приложение преобразует начальные данные в удобный формат.
Создание строки для проверки: Из всех параметров (кроме специального hash) создается отсортированная строка.
Создание секретного ключа: С помощью токена вашего бота создается секретный ключ.
Создание цифровой подписи: Используя секретный ключ и строку параметров, создается цифровая подпись.
Сравнение подписей: Приложение сравнивает созданную подпись с полученной от Telegram. Если они совпадают, данные подлинные.
Этот процесс помогает убедиться, что данные, полученные от Telegram, не были изменены, обеспечивая безопасность вашего приложения и его пользователей.
После успешной валидации я генерировал JWT токен для пользователя и он становился полноценным пользователем в моей системе.
Далее можно с ним делать что угодно 😏 - ну допустим заблокировать его, дать права админа и т.д.
А сам пользователь имеет полный доступ к возможностям приложения. Но вне телеграма он ничего не сделает.
Какие дыры есть в приложениях и почему?
Не буду показывать на конкретном примере, но большинство разработчиков не умеют или не хотят защищать свои приложения, а чисто привязывают все к Telegram ID ( ID вашего аккаунта ) и так и живут.
Telegram ID состоит из цифр и перебрать его методом подбора не составит труда и получить доступ к аккаунту в Mini App.
Зачастую этим грешат новые приложения или не опытные разработчики, например в Telegram Apps Store ваше приложение проверяют на наличие этой защиты.
Кроме того нужно учесть что само приложение не должно никоем образом отображаться в поисковиках, если все взаимодействие выстроено на основе телегерама. Приложения же имеют свой адрес и могут индексироваться, не забывайте выключать!
Кроме всего этого можно запретить вне телеграма заходить в ваше приложение тем же способом что описан выше.
Как же защитить приложение и пользователей?
Не важно на каком языке вы пишите, телеграм уже сделал для вас подсказку, осталось ей воспользоваться.
Я надеюсь эта статья поможет тем кто хочет или уже занимается разработкой WebApp на Telegram. Если все еще осталось что-то не понятно, то пишите смело - будем вместе разбираться:)
Если у вас так же останутся вопросы или предложения или вы просто захотите поделиться своим приложением, то пишите! Всегда рад пообщаться с читателями 😁