Долгое основательное вступление, к нему ожидались поучительные примеры из жизни, но нет, опять в другой раз. Сама то идея понятна и привлекательна. Хочется узнать реальный опыт
Понимаю, данную публикацию изначально планировал на "entry" уровне, просто как призыв к действию и краткий обзор имеющихся инструментов. Про опыт конкретных реализаций наверное в следующих публикациях расскажу, благо он есть.
собрали OpenAPI схему, утвердили, положили в репозиторий, таким-то инструментом нагенерили моки, оживили их, фронтэндеры пользуются. Потом прилетела правка, обновили схему. Что-то ещё надо сделать? Насколько гладко и безболезненно проходят правки?
Если правки не меняют логику работы клиентского приложения, а только касаются формата API, то изменения гладко проходят. Используем что-то типа паттерна "Адаптер", который на вход принимает схему данных приходящую из api, а на выходе отдаёт схему данных необходимую для построения UI (её можно даже просто видя макет определить). Соответственно, если макеты не менялись то на выходе адаптер отдаёт всегда одно и тоже, и при небольших правках в api, мы просто учим адаптер работать с новыми входящими данными. Выглядит это обычно как правки в пару строк в одном файле, то есть безболезненно. Особенно если у вас моки автоматом генерятся.
Я на своей первой работе тоже был единственным фронтенд-разработчиком в команде и целиком отвечал за свое приложение. Могу ли я писать что я был техлидом/архитектором в резюме? Чисто фактически, я определял развитие всего фронтенд приложения и за все что можно отвечал, чем не техлид.
Жаль ушел до того как мне дали бы напарника, сразу бы стал тимлидом.
В стартапах действительно есть возможность пощупать и то и другое и третье.
Только не факт что со всех сторон там будут костыли, хреновые практики и говнокод. В Энтерпрайзе стандарты все же выше.
Я из бигтеха, недавно был совместный проект с одним стартапом.
По итогу:
Управленцы не знают что можно писать фронтенд до того как готово API с данными. Фронты отдыхали три дня ничего не делая, зато в четверг менеджер попросил их выйти поработать в субботу, "ведь вы всё-равно ничего не делали эти дни".
Даже после получения финансирования, проект продолжал писаться от исходного mvp суть которого менялась дохрена раз до его демонстрации, в итоге даже на начало разработки там сплошные костыли и спорные поспешные решения.
Управленцы не знают ни скрама, ни канбана, а просто раздают указания как в шаурмечной.
Разработчики на вопрос будем ли писать юнит-тесты спрашивали "зачем? Есть же тестировщики".
Лидом фронтов поставили барышню которая была в техническом плане хуже всех разрабов, что привело к тому что вся команда свалила.
а деплоить зачем? в основном все используют для локальной разработки. Кода писать получилось меньше чем на том же MSW, точно так же ендпоинт описываешь и отдаёшь на клиент. Дополнительно в пару строк добавил проксю на рабочий апи, если по урлу не нашлось замоканных данных. Функционал расширяешь как хочешь по желанию, насколько фантазии хватит. И все это без ковыряний в документациях, так как в основном все фронты от миддлов с экспресс/коа знакомы.
Еще у отдельного сервера плюс, что он как раз-таки не зависимость твоего фронтового приложения, а отдельно собирается и в билде клиентского приложения не участвует. Потому что с MSW мне однажды от безопасников отбивка пришла, что мол он в себе зависимости небезопасные использует, и соответственно все приложение становится небезопасным. Тогда как в своем сервере ты сам зависимости выбираешь.
вот плюсую использовал и MSW и Mirage, но простой сервер на Express/Koa оказался вообще ничем не сложнее в использовании, но при этом гораздо функциональнее. Настроил его как себе нужно, не надо ни в документациях всех этих MSW ковыряться, что-то надо, взял и написал сам.
фулл-стэки существуют, но это почти всегда либо чистый фронт со знанимем NodeJS, либо чистый бэк со знанием одного фронтового фреймворка. Думаю, что большинство веб-разрабов в каком-то смысле фулл-стэки, как еще пет-проекты писать.
Да, но за 5млн рублей 47кв.м было почти нереально найти и до льготной ипотеки.
Нормальная однушка в Царицыно примерно такого метража сейчас стоит 8.5млн, весной стоила 7.8млн.
.catch в середине цепочки сможет обрабатывать ошибки, которые произошли до нее.
несколько вызовов .catch в цепочке будут по цепочке обрабатывать объект ошибки, по аналогии с then
Автор настолько матерый, что оставляет на сайте следы своего гугл аккаунта вместе с идентификаторами гугл аналитикс, видимо для того чтобы его жертвы, раз уж позвонить не могут, могли ему на почту написать куда им деньги высылать. Все правильно, ведь матерому балующемуся олдскульному прогеру нечего бояться.
Такой матерый, что запустил это с обычного публичного хостинга с ipv4 адреса, подключил жквери где не надо, забыл добавить телефон и много всего другого.
«Наконец, включение jQuery свидетельствует о том, что автор — опытный веб-разработчик, особенно с учётом того, что ни один JS-скрипт на сайте не использует jQuery.»
Это сарказм или где логика?
Алсо, похоже больше не на опытного разработчика, а на школяра, стырившем скрипт где-нибудь на blackhatworld'е и иже с ним и играющего в кулхацкера.
Не вырастет, он на уровне отдельных методов работает
Ничем не плоха если Вам её достаточно, но если есть также задача обработать ошибки вызванные статусами 4хх и 5хх, то тут уже надо что-то посерьёзнее.
Понимаю, данную публикацию изначально планировал на "entry" уровне, просто как призыв к действию и краткий обзор имеющихся инструментов. Про опыт конкретных реализаций наверное в следующих публикациях расскажу, благо он есть.
Если правки не меняют логику работы клиентского приложения, а только касаются формата API, то изменения гладко проходят. Используем что-то типа паттерна "Адаптер", который на вход принимает схему данных приходящую из api, а на выходе отдаёт схему данных необходимую для построения UI (её можно даже просто видя макет определить). Соответственно, если макеты не менялись то на выходе адаптер отдаёт всегда одно и тоже, и при небольших правках в api, мы просто учим адаптер работать с новыми входящими данными. Выглядит это обычно как правки в пару строк в одном файле, то есть безболезненно. Особенно если у вас моки автоматом генерятся.
Тоже не понимаю свистопляски вокруг титулов -)
Я на своей первой работе тоже был единственным фронтенд-разработчиком в команде и целиком отвечал за свое приложение. Могу ли я писать что я был техлидом/архитектором в резюме? Чисто фактически, я определял развитие всего фронтенд приложения и за все что можно отвечал, чем не техлид.
Жаль ушел до того как мне дали бы напарника, сразу бы стал тимлидом.
В стартапах действительно есть возможность пощупать и то и другое и третье.
Только не факт что со всех сторон там будут костыли, хреновые практики и говнокод. В Энтерпрайзе стандарты все же выше.
Я из бигтеха, недавно был совместный проект с одним стартапом.
По итогу:
Управленцы не знают что можно писать фронтенд до того как готово API с данными. Фронты отдыхали три дня ничего не делая, зато в четверг менеджер попросил их выйти поработать в субботу, "ведь вы всё-равно ничего не делали эти дни".
Даже после получения финансирования, проект продолжал писаться от исходного mvp суть которого менялась дохрена раз до его демонстрации, в итоге даже на начало разработки там сплошные костыли и спорные поспешные решения.
Управленцы не знают ни скрама, ни канбана, а просто раздают указания как в шаурмечной.
Разработчики на вопрос будем ли писать юнит-тесты спрашивали "зачем? Есть же тестировщики".
Лидом фронтов поставили барышню которая была в техническом плане хуже всех разрабов, что привело к тому что вся команда свалила.
И ещё много чего...
а деплоить зачем? в основном все используют для локальной разработки. Кода писать получилось меньше чем на том же MSW, точно так же ендпоинт описываешь и отдаёшь на клиент. Дополнительно в пару строк добавил проксю на рабочий апи, если по урлу не нашлось замоканных данных. Функционал расширяешь как хочешь по желанию, насколько фантазии хватит. И все это без ковыряний в документациях, так как в основном все фронты от миддлов с экспресс/коа знакомы.
Еще у отдельного сервера плюс, что он как раз-таки не зависимость твоего фронтового приложения, а отдельно собирается и в билде клиентского приложения не участвует. Потому что с MSW мне однажды от безопасников отбивка пришла, что мол он в себе зависимости небезопасные использует, и соответственно все приложение становится небезопасным. Тогда как в своем сервере ты сам зависимости выбираешь.
вот плюсую
использовал и MSW и Mirage, но простой сервер на Express/Koa оказался вообще ничем не сложнее в использовании, но при этом гораздо функциональнее. Настроил его как себе нужно, не надо ни в документациях всех этих MSW ковыряться, что-то надо, взял и написал сам.
Благодарю, неплохой краткий обзор основных подходов к работе с данными
попробуйте второй раз не нажимать клавишу когда горит "Press any key to boot from CD or DVD..."
В райффайзене проходил интервью совсем недавно.
Был один этап тех. Собеса, на час-полтора.
И знакомство с командой.
По итогу получил оффер.
фулл-стэки существуют, но это почти всегда либо чистый фронт со знанимем NodeJS, либо чистый бэк со знанием одного фронтового фреймворка. Думаю, что большинство веб-разрабов в каком-то смысле фулл-стэки, как еще пет-проекты писать.
Нормальная однушка в Царицыно примерно такого метража сейчас стоит 8.5млн, весной стоила 7.8млн.
несколько вызовов .catch в цепочке будут по цепочке обрабатывать объект ошибки, по аналогии с then
"Правда веба: CSS — это не настоящее программирование".
Проиграл с заголовка.
Это сарказм или где логика?
Алсо, похоже больше не на опытного разработчика, а на школяра, стырившем скрипт где-нибудь на blackhatworld'е и иже с ним и играющего в кулхацкера.