Frontend Developer (React)
#удаленка #проект
Запускаем веб-приложение для изучения иностранных языков. Ищем Frontend разработчика с опытом работы в команде на проектную занятость сроком 1-1,5 месяца
Что нужно знать
- Можешь сверстать сложный макет pixel perfect
- React + TypeScript
- Уверенные навыки работы с Git
- Базовые архитектурные принципы, а не просто структура папок из FSD
Чем будешь заниматься
- UI кит на shadcn компонентах + Tailwind V4 по макету из Figma
- Верстка чата для взаимодействия с ИИ репетитором по макету из Figma
- Интеграция с API, REST, SSE, WebSocket
- Вести прогресс работы в таск трекере
Что получишь
- Ментора и разбор кода на каждом ревью - не «разберись сам»
- Реальный продукт в портфолио, а не очередную админку
- Интересный проект, где минимум верстки и максимум логики
- Знакомство с боевым стеком: TypeScript, React, i18n, Docker, Sentry, REST
- Проектная занятость на время разработки MVP, по итогам - оффер в штат
Условия
- Удалённо
- занятость: фултайм
Как откликнуться
Присылайте в личку @lebedev_maksim6 ссылку на GitHub или любой проект, который можно открыть и резюме.
ВладПочему так много? 😭
В продакшен среде подобных регулярок избегают, кроме того она пришла из Perl и не полноценна (не до конца соответствует стандарту RFC 5322 - для которого была создана)
P Status: Succeeded Exit code: 0 Execution time: 1.8s Code import this Result The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
PyTegBotStatus: Succeeded
Exit code: 0
Execution time: 1.8s
Code
def f0():
try:
return 1
finally:
return 2
def f1():
x = 1
try:
return x
finally:
x = 99
def f2():
x = [1, 2]
try:
return x
finally:
x.append(3)
print(f0())
print(f1())
print(f2())
Result
2
1
[1, 2, 3]
Я так понимаю:
f0() - finally выполняется в любом случае не зависимо от ошибок в try.
f1() - выводится 1, так как на момент вызова x = 1, а уже после x = 99.
f2() - выводим список через переменную x, и затем к этому же списку добавляем значение, тоесть метод append не возвращает новый список, а изменяет имеющийся