Недавно, ко всеобщему сожалению, heroku урезал свой бесплатный тариф для хостинга приложений, который использовался многими разработчиками для хостинга своих пэт проектов. В качестве альтернативы можно использовать:
- Render
- Railway
- Vercel
Ещё по теме:
- 3 free Heroku alternatives to deploy a Node.js app
- Using Express.js with Vercel
А каким бесплатным хостингом пользуетесь вы❓
https://t.me/cherkashindev/72
Народ, аська подыхает, но гля, чего я нашёл!!!!!
Привет пикабу, подскажите как можно реализовать эту идею.
Имеется доступ к базе по API с правами чтения и записи в базу, но проблема в том, что запрос должен быть привязан к 1 IP, можно ли как то перенаправлять запросы к базе через другой сервер минуя привязку по IP ( т.е привязать IP одного сервера и перенаправлять запросы?)
Сам я не кодер и не айтишник, поэтому заранее извиняйте.
Прошу прощения за, казалось бы, тупой вопрос, но хотелось бы получить ответ от шарящих в теме. Я написал несколько небольших учебных проектов (без курсов, всё изучал сам, английский хороший), есть небольшой коммерческий опыт вёрстки, кое-какие знания ES 6+, TS, Vue 3, React, Effector, Python (Flask), PostgreSQL, Linux. В данный момент в основном занят решением задач на leetcode и на codewars и подтягиванием общей теории. В общей сложности учусь уже около 7 месяцев, но за последние 4 месяца отзывов на подобного рода вакансии и тонны написанных сопроводительных дали всего три тестовых задания, которые были выполнены по требованиям и в срок: одно из них вообще не смотрели, т.к. после отправки буквально через минуту пришёл отказ, второе долго проверяли, но сказали, что позиция уже занята, третье (чтобы попасть на месячную неоплачиваемую стажировку!) я выполнил, но не прошёл собеседование (сказали, недостаточно знаний по TS и React). Т.е., из нескольких сотен откликов на подобные вакансии в разных городах с готовностью переехать и работать буквально за еду - 3 тестовых задания и одно непройденное собеседование на стажировку. Я, конечно, понимаю, СВО, рынок упал, но складывается ощущение, что "начинальщики" сейчас попросту не нужны вообще, а с учётом того, что мне уже за 30 и нет технического ВО, то, судя по всему, дела мои совсем плохи...
Подскажите, что я делаю не так? Продолжать искать и учиться? Или попробовать освоить другой стек? Или объективно лучше заниматься другой деятельностью, а IT отложить "до лучших времён"?
Спасибо.
После появления jQuery, захватившего практически всю веб-разработку, прошло уже довольно много времени, сейчас уже мало кто использует эту библиотеку, кто-то перешёл на разработку на чистом JS, кто-то на React и Vue, и вот пару лет назад появилась новая идея, сравнимая по простоте с jQuery, это HTMX.
Теперь взаимодействие с сервером можно описывать декларативно в HTML атрибутах, создавая быстрые веб-приложения без JavaScript кода.
Автор этой небольшой библиотеки переписал со своей командой из 4 человек свой сервис, созданный на React и Django, и получил уменьшение кода на 67% при той же функциональности, при этом команда из двух фронтендеров, одного бэкендера, и одного фуллстека, превратилась полностью в фуллстековую.
Я тоже начал использовать htmx.js в своей работе, теперь можно выкинуть много ванильного JS кода, заменив его на декларативщину HTMX, сложно устроенные интерфейсы становятся простыми и более функциональными.
Бэкенд может быть любым, можно даже вообще без него обойтись для некоторых задач, например, подгрузку при клике какой-то информации можно осуществлять прямо из статичного HTML файла, и это будет отлично и быстро работать.
Здравствуйте уважаемые, очень нужна помощь. На основе первого примера с сайта https://html5book.ru/mnogourovnevoe-vypadayushee-menu/
делаю 4х уровневое выпадающее меню. В связи с большим количеством планируемых пунктов нужно укоротить меню до 200-300px и сделать прокрутку. Кому не лень, гляньте пожалуйста код по ссылке и скажите, как его поправить. Сам пытался пихать overflow-y, у меня ничего не вышло
Иногда при написании проги появляется спагетти-код. Это значит, что для простоты и скорости решения мы копируем одинаковые куски кода, которые делают почти одно и то же. У них внутри одинаковая логика, но разные входные данные, и мы их просто скопировали-вставили.
У такого подхода к программированию есть несколько проблем:
• расширять функциональность сложно, так как легко запутаться, какую именно часть кода мы расширяем или оптимизируем;
• читать такой код трудно, потому что один и тот же код встречается много раз.
Единственное, когда можно использовать такой подход — если нужно что-то быстро протестировать и понять, работает оно или нет. Если не работает — значит, мы сэкономили время и не стали тратить его на неудачное решение.
А если всё работает как нужно, значит, настало время переписать код в нормальном виде. Для этого нам понадобится некоторое подобие объекта, но не на основе класса, а созданное вручную.
Делаем красивые пуши для вашего сайта в стиле MacOS
Новый тип переменной: объект
У переменной типа «объект» есть одна отличительная особенность: она состоит как бы из двух частей — свойства и значения, и здесь всё то же самое — у объекта меняются только значения свойств. Поясним на примере языка JavaScript.
Сделаем переменную-объект, у которой будет два свойства — имя и возраст:
var person = {
name: "Миша",
age: 35
}
Чтобы поменять имя, нужно написать название переменной и через точку указать название свойства, которое хотим изменить:
person.name = "Илья";
person.age = 31;
Свойств у объекта может быть сколько угодно:
var person = {
name1: "Миша",
name2: "Саша",
name3: "Лена",
age1: 35,
age2: 21,
age3: 19
}
Но если у объекта получается много однотипных свойств, можно сделать их массивом и обращаться к ним по номерам. А если элементы массива тоже сделать объектами с одинаковыми названиями свойств, получится вот такая магия:
Смотрите, так как у каждого элемента массива одинаковое название свойств, то, меняя просто номер элемента, мы можем запоминать разные свойства у одинаковых по сути элементов. Это нам пригодится на следующем шаге.
Собираем дубли
Пройдёмся по нашему старому коду из прошлой статьи и соберём все одинаковые переменные, которые отличаются только цифрами:
• Mask(1,2,3,4)
• element_Id_(1,2,3,4)
• number_Id_(1,2,3,4)
Первые две переменные задают ссылку на объект и маску для сравнения элементов, а вторые две отвечают за количество задач в колонках.
Свернём эти 16 переменных в один большой объект:
Теперь, зная только номер колонки, мы можем обратиться к объекту, маске и количеству задач в колонке. Сначала это может показаться громоздким, но на самом деле сокращает наш финальный объём программы в 4 раза.
Чтобы избавиться от дублей в коде, используют циклы или выносят повторяющийся код в отдельную функцию. На самом деле вариантов больше, но основные — эти.
Используем цикл
Циклы применяют в тех случаях, когда спагетти-код по очереди используется несколько раз, где отличаются только порядковые номера элементов. В нашем случае это функция showTasks (). Она берёт по очереди все элементы из локального хранилища и по очереди же сравнивает их с шаблоном — для первой, второй, третьей или чётвёртой колонки. Единственное, чем отличаются фрагменты — маской и колонкой, куда их отправлять:
Сделаем то же самое в цикле, используя нашу большую переменную-объект. Для этого мы организуем цикл от 0 до 3 (потому что нумерация элементов массива начинается с нуля) и по очереди проверяем все значения:
Код сократился в 4 раза, читать стало проще, и всё меняется в одном месте. Красота.
Делаем отдельную функцию
У нас есть вот такой огромный кусок кода, который делает одно и то же, только с разными элементами.
Здесь 4 раза задаётся обработчик нажатия клавиш в поле ввода у каждой колонки. Очевидно, что проще вынести повторяющийся код в отдельную функцию и вызывать её по мере необходимости:
Что дальше
Мы только что убрали почти весь спагетти-код из нашего проекта. Почти — потому что у нас осталось два неопрятных фрагмента:
2. У нас остались 4 обработчика нажатий, которые делают одинаковые вещи — вызывают одну и ту же функцию с разными параметрами.
Оба фрагмента можно оптимизировать, например, с помощью jQuery.
Попробуйте сделать это сами, пока это не сделали мы
Пост для тех, кто читает вакансии в ИТ-компаниях и думает, что там всё классно.
Иногда уже по тексту вакансии можно понять, что работать в компании будет сложно. Мы просмотрели разные вакансии в ИТ и собрали 9 признаков того, что в реальности всё окажется хуже, чем в объявлении.
Читайте нас в телеге, ибо там выходит контент ежедневно (не как тут) и вы сможете устроиться на вакансию мечты, обретя силу фронтенда.
А теперь к делу
1. Слишком странный набор навыков
В компанию требуется JavaScript-разработчик со следующими навыками:
• JavaScript + HTML;
• знание Microsoft Excel;
• составление отчётов в 1С;
• уверенное владение системой автоматизации СДЖУ-85.
Что здесь не так: кажется, что эта вакансия составлена под конкретного человека, чтобы он прошёл, а остальные — нет. В жизни у обычных разработчиков не встречается такой каши из специфичных навыков из разных областей.
Ещё есть поверие: если в вакансии написано «1С», то это будет то, с чем вы будете возиться 90% времени.
Как норм: скучный, понятный, пусть даже модный стек технологий, который кочует из одной вакансии в другую. Ну вот надо людям в каком-то году React, а в другом — Vue. Окей, но пусть это будет стандартный стек этого года, а не безумный микс.
2. Участие в техподдержке
Ваши рабочие задачи:
• написание и отладка кода;
• разработка новых систем;
• помощь при работе с клиентами, иногда — ответы на вопросы пользователей.
Что здесь не так: чаще всего за этой строкой скрывается дополнительная обязанность по техподдержке продукта, за которую не будут дополнительно платить. Это значит, что вам нужно будет успевать и писать код, и разгребать тикеты в техподдержку. Если это не позиция сотрудника техподдержки — стоит насторожиться.
Как норм: поддержкой занимается поддержка.
3. Высокий темп разработки
Мы заботимся о скорости обновлений, поэтому ваш код сразу будет уходить в новую версию продукта каждую неделю.
Что здесь не так: высокий темп означает, что в компании, скорее всего, не налажено тестирование и оформление документации. С этим просто некогда разбираться, а все проблемы решаются выпуском нового кода. В итоге всё превращается в спагетти-код и падает из-за отсутствия документации.
Как норм: у компании должен быть этап тестирования, обязательные требования по документированию своего софта, а в идеале ещё и код-ревью — когда старшие товарищи проверяют ваш код.
4. Десятилетний стартап
Мы — стартап, который образовался 10 лет назад, и у нас до сих пор сохранилась та атмосфера свободного общения и отношения к продукту.
Что здесь не так: если стартапу больше трёх лет и он всё ещё стартап, то с продуктом явно что-то не то: либо нет клиентов, либо нет квалифицированных разработчиков, либо ребята не знают значения слова «стартап». В любом случае за это время там накопится технический долг, на разгребание которого понадобится ещё 10 лет. Хотите ли вы в таком участвовать — хорошо бы решить заранее.
Как норм: компания, которая работает уже 10 лет, скорее всего, уже имеет штат HR-специалистов, которые будут обрабатывать входящие вакансии. Это признак, что хотя бы процесс найма у компании поставлен.
5. Обязательное участие в корпоративных мероприятиях
Наша компания — как семья. У нас высокая культура внутри компании, поэтому мы ожидаем от каждого кандидата, что он будет принимать участие во всех корпоративных мероприятиях и будет активно вовлечён в профильные активности.
Что здесь не так: ну как можно навязывать работникам досуговые мероприятия? Это просто неприлично.
6. Горизонтальное управление, никакой иерархии, решает команда
У нас нет привычного руководства, а все вопросы мы решаем вместе. Каждая идея обсуждается коллективом разработчиков — благодаря этому у всех в работе только важные и интересные задачи.
Что здесь не так: в коллективе всё равно будут лидеры и руководители, только они будут неформальные и в случае чего смогут откреститься от любой ответственности. Вам придётся помимо работы участвовать в беспощадной внутриполитической борьбе.
Как норм: в вакансии этого не напишут, но вообще должны быть чёткие должностные обязанности, назначения в команды, чёткие руководители и понятные сферы ответственности.
7. Руководитель лично вовлечён
Вы будете работать непосредственно с Иваном Петровым, который лично курирует эту работу.Что здесь не так: вероятно, вы получите босса, который стоит над душой, двигает пиксели и меняет задачу по семь раз на дню. Неприятно работать персональным кодером с голосовым управлением.
Как норм: «вы будете работать в команде такой-то над такими-то задачами».
8. Оперативные ответы в любое время
Будущий сотрудник должен:
• быть на связи и сразу реагировать на входящие задачи;
• вовремя проверять электронную почту;
• иметь возможность оперативно подключиться к решению первоочередных задач.
Что здесь не так: подобное описание означает, что вас будут дёргать днём и ночью по любому поводу. Ночные переработки, работа в выходные и на праздники, внезапно закончившийся отпуск — всё это скрывается за простыми словами «нам важно, чтобы сотрудник был всегда на связи».
Как норм: обычно, если работа действительно требует мгновенной реакции в любое время, это обосновано спецификой. Так могут эксплуатировать персональных ассистентов или, например, дежурных сисадминов.
9. Несоответствие опыта и развития отрасли
Мы — стартап в области нейрогенеративного искусства, занимаемся созданием видеороликов на основе нейросетей по текстовому описанию. Нам нужен Python-разработчик с пятилетним опытом работы в этой теме.
Что здесь не так: пять лет назад не было популярных разработок в области генерации видео из текста, поэтому у любого разработчика просто не будет такого опыта. Судя по описанию, компания не разбирается в технологиях и им нужен тот, кто всё объяснит либо сделает за них с нуля всю работу.
Это не панацея
К сожалению, нет идеальных компаний: везде есть какие-нибудь трудности, загоны и отдельные вонючки, которые будут всё портить.
Часто нормальные внешне вакансии ведут в проклятые компании, и никак, кроме как по отзывам, ты это не узнаешь (или на личном опыте).
Наконец, бывают просто некомпетентные эйчары, которые составляют вакансии так, что от компании хочется бежать. Хотя внутри там норм.
Как это всё научиться отлавливать? Достоверно не знаем. Но с опытом становится легче.
