Михаил Р.

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

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

В универах и остальных заведениях подобного характера математику и программирование скрещивают для того чтобы будущий программист научился на самом базовом уровне выстраивать алгоритмы решения задачи. Грубо говоря, шаг 1 + шаг 2 + шаг 3 + шаг 4 + шаг 5 = результат. Если тебе чисто рассказывать про переменные, циклы, массивы и т.д. ты не поймешь нахрена это все надо и как это использовать чтобы зарабатывать деньги. Если тебе с нулевой дать решать бизнес задачи то это только лишнее грузилово мозга в и так не совсем простой сфере. Поэтому и используют математику как самое простое где можно показать как использовать те или иные конструкции в языках программирования и научить склеивать это все так чтобы получить результат требуемый.

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

2. На работе математические требования зависят от области применения.

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

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

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

Второй запрос = отправляем с клиента токен (тот 64 символьный полученный от сервера) и строку с кодом из смс. Проверяем на сервере токен и код из смс, если все ок - пускаем в аккаунт.

Примечания:
1) токены и сами попытки входа должны жить определенное количество времени, предположим 5 минут.
2) попытки ввода кода (неправильные вводы) должны быть ограничены разумным числом (ну допустим 5 попыток)
3) если можно то лучше код сделать длиннее - хотя бы 6 цифр, а лучше 8 и более.
4) попытки входа в аккаунт можно ограничить, но тогда будет можно абузить эту "фичу" и блокировать вход чувакам, тут выбираем меньшее из зол исходя из бизнес требований
5) можно экономить на смсках и доставлять код в последних цифрах номера / голосовой озвучкой, отправлять в вк, ватсап, телеграм, вайбер

500 айкью примечания для кое какой защиты от слива бюджета:
1) можно юзать капчу (можно не всегда а когда начинается аномалия по отправке кодов - всплеск количества отправок)
2) как уже и говорил разделение входа и регистрации
3) ставим бот защиту от какого нибудь сервиса по защите от ддос/бот атак
4) иногда можно не отправить код а отправить клиенту респонс что код отправлен, если клиент вводит код - скорее всего это атака. человек же запросит код повторно (потому что он тупо ему не пришел)
5) иногда можно отправить код не сразу а через предположим, 30 секунд - если ввели код раньше - значит что-то не так

Убирать регистрацию стилей из блок.json и вручную проверять?

Именно так, к сожалению, до сих пор эта задача на плечах юзеров.

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

add_action('wp_enqueue_scripts', function (): void {
  global $post;
  $content = $post->post_content;
  $blocks = parse_blocks($content);
  foreach ($blocks as $block) {
    if ('Your block name' === $block['blockName']) {
        // enqueue
    }
  }
});

Если интересно покопаться в коде, то здесь https://github.com/yarovikov/gutengood/blob/master...

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

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

Микросервис в двух словах - это самостоятельная сетевая единица со своим потоком исполнения, своим URI и своим маленьким (как правило REST) API для которой поднимать nginx setup избыточно.

А теперь возьмите не синтетический тест, а реальную задачу сложнее перекладки json'ов, например, с шифрованием, дайте серьëзную длительную нагрузку и посмотрите латентность по процентилям.

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

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

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

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

В итоге, легковесность горутин, легкость работы с ними и асинхронная модель из коробки (не создается тред на каждую рутину, а наоборот, рутины обрабатываются разными тредами по необходимости) привели к тому, что ниша Го это сервисы, которые упираются в ожидание ресурсов от каких-то внешних систем по сети. То есть, идеальный кейс для веб-сервера, который собирает под капотом инфу с БД и других сервисов. По сути такой сервис большую часть времени ждет ресурсов по сети, в Го это ожидание сделано очень эффективно.

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

Что лично вижу сейчас. На данный момент почти каждая вакансия senior вакансия на golang, которую приносят приятные девушки HR содержит требование 3 лет в Golang или опыт работы senior на другом стеке с желанием переучиться на go.

На менее хайповых стеках такое тоже бывает. Бывают готовы обучать на редкие языки - ruby, например вспоминают пару раз в год. Лет 7 назад также массово вербовали на nodejs. А сагитировать с PHP в Python так вообще святое дело. Такое происходит и на позиции мидлов. На тот же go в крупные компании часто достаточно хорошего опыта мидла и желания изучать go. Зп будет из грейда мидла.

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

1. Открываешь ИП, к нему транзитный валютный счет. Рассчетный валютный счет можно открыть если желаешь сидеть в долларах.
2. Делаешь wire трансфер с Upwork, уплачивая 30$ за перевод.
3. После перевода деньги блокируются валютным контролем.
4. Дальше два варианта, либо выбить из поддержки договор (что почти нереально), либо отдать в ВК публичную оферту (User Agreement, на который соглашаемся при регистрации) в биллингве, на каждой странице публичной аферты поставить свою печать, "Копия верна" и подпись (после этих действий ВК охотней примет публичную аферту, нежели просто распечатанный биллингв).
5. На каждый денежный перевод нужен акт выполненных работ, тут два варианта. Либо предоставить в ВК скриншот трансфера из панели апворка (что филькина грамота, не каждый ВК примет это), либо запрашивать у поддержки "Act of acceptance", который будет подписан апворком и тобой, в нем будет указана сумма перевода. Act of acceptance выглядит внушительней, нежели скрин из панели.
6. Дальше при каждом переводе предоставляешь новый Act of acceptance.
7. Работаешь так до достижения лимита в 50000$, дальше нужно заключить паспорт сделки (что сложно, но реально, нужно трясти поддержку апворка). ЛИБО заключить новый "контракт" с Upwork, опять предоставив User Agreement в билингве (про схему с закрытием старой оферты и открытием новой вычитал на хабре, там чувак ставил номер контракта в шапке оферты, что позволяло "открыть" новый контракт, поменяв этот номер)
8. Ну и работаем дальше, либо по паспорту сделки, либо по вновь открытому контракту.

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

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

им всё равно нужно самостоятельно планировать работу и отвечать за неё?

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

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

1. Agile - это про то что люди должны договариваться. По тому надо не намёки делать, а говорить прямо и предметно.

2. Вот вы говорите, что вам нужно ТЗ. А зачем вам оно нужно?
Вам не понятна та постановка, которая описывается в карточках?
Есть неоднозначность?
Уже есть примеры, когда от этой неоднозначности пострадал продукт (например из-за необходимости переделывать)?

Или вам нужно не ТЗ, а виденье того, чем в итоге должен стать продукт?
Не понятно, для чего вообще все эти карточки перекладываются?
Если так, то, вероятно, вам нужно не ТЗ, а какие-то OKR-ы, чтобы можно было от них отталкиваться при составлении задач.

Возможно, произошла мискоммуникация между вами и заказчиком. Возможно, заказчик действительно ожидает от вас (команды) самостоятельности при составлении задач - по сути сочетание в себе и менеджера и аналитика.
Это нормально, но нужно этот момент тоже прояснить.

Смысла в таких сервисах не особо много. И дело не только в прибыли самого сервиса. Дело в самом пользователе.

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

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

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

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