Насчёт стилизации тегов у вас слабо расписано. По умолчанию все типографские элементы должны иметь стили, положенные им от природы, но с учётом дизайна страницы. У нас был один фронтендер, который полностью обнулил стили всех элементов, а далее стилизовал только классы. В итоге, текст статей, набранный контентщиком в админке с использованием визуального редактора выглядел абсолютно безобразно, а именно: тэги p не имели отступа снизу, тэг strong не был жирным, списки не имели отступов ни слева, ни снизу. В макетах от дизайнера был макет страницы статьи, так фронтендер сверстал весь текст на div-ах. А всё потому, что где-то в "умных" книжках он вычитал правило, что никогда ни в коем случае нельзя стилизовать элементы.
поэтому он готов к удовлетворению самых диких запросов заказчика
А инхаус команда разве не готова удовлетворять самые дикие запросы своего руководства?
Аутсорсер пишет код, который ему поддерживать и развивать не придётся
Разработка ПО - это не батон колбасы, где купил и забыл. Не думаю, что хоть кто-то в здравом уме будет заказывать разработку серьёзного софта у стороннего исполнителя без дальнейшей перспективы сопровождения этого софта тем же исполнителем. Более того, в любой компании, занимающейся аутсорсинговой разработкой, большинство проектов - это именно сопровождение старых проектов, а не создание новых.
А как проверяли какой вариант возвращать в кастомном роутере?
Делал запрос к бэкенду.
то можно сделать просто общий роут и в нём возвращать либо один компонент, либо другой
Изначально так и планировалось, но потом почему-то возникла необходимость ещё до начала рендеринга знать тип страницу. Не помню, почему, но знаю, что через год, как я ушёл, кто-то пытался всё это выпилить и упростить, а через две им недели пришлось вернуть всё как было.
а страницы всегда стоит держать серверными, иначе нельзя будет настроить для них мета-заголовки
А для чего тогда компонент Head придумали, он прекрасно с этим справляется? Я пользовался next.js с 6 версии. И тогда мне очень понравилось то, что это было изоморфное решение, где один и тот же код отрабатывал на сервере при запросе первой страницы, а затем он уже работал в браузере. Всё это делалось с помощью getInitialProps. И для меня было огромным разочарованием, когда этот метод депрекейтнули. Ещё тогда я заметил, если у нас есть отдельный бэкенд, скажем на php, который просто отдаёт данные в json, бутылочным горлышком всей системы был сервер Next.js. Клиентские переходы как правило происходили заметно быстрее, чем запрос с сервера отрендеренной страницы. Очевидно, и сами разрабы некста это признали, когда придумали статическую генерацию. По факту это значит только одно: "Ребята, мы не можем сделать приемлемой скорость рендеринга в next.js, поэтому вот держите генератор статики". Но статика не подходит для проекта, где 100.000 страниц, и в день добавляется или обновляется тысяча из них. Но бог с ней, со статикой, они и динамику испортить умудрились. Сейчас вместо метода getInitialProps рекомендуют getServerSideProps. И теперь вместо того, чтобы бросить с клиента запрос к API бэкенда и получить мгновенно закэшированный ответ, запросы идут всё на тот же сервер next.js, который и так нагружен рендерингом, так ещё эти запросы некэшируемые. ИМХО, последние годы развития next.js - это скорее деградация, нежели развитие.
Интересно, умеет ли app router работать с полноценными синонимами URL, когда нет возможности только лишь по виду URL определить тип страницы? Например, есть страница товара и страница статьи - это два разных компонента. На сайте 100500 статей и товаров с урлами типа /abcd /bcda и т.д. и нужно их рендерить в разных компонентах. Предлагает ли app router что-нибудь для решения этой задачи? Три года назад мне пришлось писать для этого полностью кастомный роутер плюс кастомный компонент ссылки, чтобы обрабатывать ещё и client side роутинг.
Вот только если это, скажем, API ключ к какому-нибудь пусть даже Google Maps API, ключ может оказаться неограниченным по доменам, кто-то может использовать этот ключ у себя, а потом гугл владельцу ключа выставит счёт. Это не говоря уже о том, что бывают довольно дорогостоящие API, и для какого-нибудь школьника или студента счёт в 500 долларов может оказаться ощутимой проблемой.
Да, форматировать код ИИ умеет хорошо. И практики всякие применяет. Вот только этот код частенько представляет собой, к примеру, смесь двух версий API, не совместимых между собой. Или предлагает решать задачу путём вызова несуществующего сервиса. Несколько раз пытался использовать в работе ChatGPT и AI Assistant от JetBrains - не удалось извлечь вообще ни малейшей пользы. При этом я не вижу смысла просить ИИ решить какие-то примитивные задачи - мне быстрее написать 5-10 строк самому, чем формулировать промпт аналогичной доины, да ещё потом проверять результат. Я пытался решать задачи, решение которых не мог придумать сам в течение получаса - ChatGPT выдал полную чушь. Все варианты были настолько далеки от действительности, что нельзя было хотя бы пару строк из этого применить. В итоге, подумал ещё полчаса и решил задачи сам.
Причём мне довольно часто приходится общаться с теми, кому ChatGPT очень здорово помогает. А когда ChatGPT не может решить их задачу, они просят меня им помочь.
При помощи гпт я сделал фронт на реакте, которого никогда не знал, когда потребовалось.
В том то и дело , что когда сам в технологии не разбираешься, то нейросети очень помогают в освоении технологии. Но когда очень хорошо разбираешься в теме и делаешь что-то сложнее примитивных вещей, то это всё равно, что с джуном советоваться
Я так понимаю, что запутанность состоит в том, что когда меняют параметр одного фотона, аналогично меняется параметр второго фотона. И синхронизация эта происходит мгновенно, независимо от пространственного расположения фотонов. То есть можно поставить источник запутанных фотонов на полпути от Саранска до Плутона и светить им в две стороны. Когда фотон долетит до Плутона, плутоняне меняют его спин, что моментально детектируют жители Саранска. В ответ они у себя в Саранске меняют спин другого фотона, о чём моментально узнают на Плутоне. Пинг выходит нулевой. А после того, как в источнике спутанных фотонов сядет батарейка, каналом связи можно будет пользоваться ещё как минимум два часа, пока последние фотоны не достигнут пунктов назначения.
Самое интересное, что если вдруг какие-то из фотонов реликтового излучения вселенной имеют пары, это значит, что мы с помощью этих фотонов прямо сейчас можем мгновенно передать информацию на другой конец вселенной.
А ведь есть ещё is-odd-number, assert-is-odd, isodd. Также есть, к примеру is-array и isarray, при том, что сейчас нет ни малейшей необходимости ни в одном из них. А если полазить в своих проектах по node_modules, то там найдётся ещё куча is-много-чего. И в большинстве случаев, там кода от 1 до 10 строк. Но к этому ещё может прилагаться 1000 строк документации, юнит-тесты и скрипт для CI. И конечно же, никто это не ставит в свои проекты - оно всегда тянется, как зависимости. Не то чтобы меня это сильно беспокоило, но иногда заставляет задуматься.
На данный момент с точно таким же успехом можно рассуждать, что будет, когда у всех будут летающие автомобили, или когда изобретут гравитационный двигатель. Можно ещё начать считать, какими убытками обернётся владение недвижимостью на Земле, когда все начнут переезжать на Марс.
Ну вот пусть изобретут и заменят. Вот только это "завтра" наступит далеко не завтра. В последний год я стараюсь следить за ИИ-инструментами для программистов, и неоднократно пытался применить их в своей работе. Так вот, если в какой-то теме вообще ничего не понимаешь, то нейросети могут хорошо это объяснить с примерами. Но если ты хороший специалист и хорошо владеешь языками/фреймворками/библиотеками, которыми пользуешься, то хотя бы какую-то минимальную пользу из ИИ выжать практически невозможно. Я даже потратил 10 баксов на AI assistant от JetBrains. Единственное, с чем он нормально справляется - может в комментарии написать, что функция делает. Но вот сгенерировать phpdoc так, чтобы phpcs не ругался - это он уже не может. Притом, что сам по себе шторм умеет делать это довольно сносно. Получается, отдал 10 баксов, чтобы ухудшить функционал своей любимой IDE.
Поэтому я и смеюсь в лицо всем, кто говорит, что ИИ вот-вот заменит программистов. Сперва изобретите что-нибудь, что сможет хоть как-то реально помогать квалифицированным специалистам, а потом посмотрим.
благодаря ГПТ я сделал за час то на что раньше уходили сутки!
Это тоже выглядит крайне сомнительным, если речь не идёт о совсем уже новичках. Пока максимум, что мне удавалось выжать из нейросетей для работы - это за полчаса потратить впустую полчаса.
А почему вы думаете, что я так думаю? Чтобы было понятнее, перефразирую: до сих пор не удалось заменить с помощью ИИ ни одного программиста уровнем выше мидла.
Можно очень долго спорить, заменит ли ИИ программистов, но есть факт, что до сих пор ни один программист не смог заставить ChatGPT или Copilot работать вместо себя, чтобы самому в это время заниматься своими делами или просто отдыхать.
Я уверен в обратном. Когда начинаешь выбирать стул, сначала выбираешь только по картинке и иногда по параметрам. Потом, когда уже есть представление, что нужно, смотришь конкретную модель конкретного производителя, и всё лишнее в заголовках только мешает. А для SEO-продвижения всю эту дрянь можно запихнуть в описание, а не заголовок.
Мне непонятна мотивация продавцов делать это. Зачем стульям давать какие-то высокохудожественные названия? Чем плохо название "Стул НьюЙоркДрев С777", данное самим производителем?
Можно работать в парке на скамейке, в кафе, в коворкинге, в офисе у друзей и знакомых.
Пробовал работать на скамейке: через 15 минут отваливается кисть с мышкой, через 30 - шея. И всё это время вытекают глаза, потому что даже в пасмурный день естественное освещение на улице в разы сильнее, чем любые лампы в помещении. В кафе - может быть то же самое. При сидячей работе самое главное - правильная посадка, чего можно достичь только на нормальном офисном стуле. Для себя пришёл к выводу, что если уж очень хочется сходить днём на улицу или в кафе, лучше перед этим поднапрячься, сделать побольше задач, а потом с чистой совестью и пустыми руками пойти на пару часов куда-нибудь.
Макет без адаптивности, без слайдера на главной, без увеличивалки картинок. Вообще без ничего. Я в своё время сделал больше десятка разных интернет-магазинов. Так вот, в процессе создания реального интернет-магазина нет такой стадии, на которой может потребоваться такой вот скетч на ангуляре. Вот это вот всё обычно заказчик рисует ручкой на бумажке, потом дизайнер в какой-нибудь фигме делает такую раскладку прямоугольничков на этапе утверждения ТЗ для создания дизайна.
А то, что получилось у автора больше похоже на контрольную работу на начальном этапе курсов, где требуется сверстать пару примитивных страниц с единственным требованием, что код должен быть валидным. Мол смотрите, я умею закрывать теги, умею флекс в цсс и понял синтаксис js.
Насчёт стилизации тегов у вас слабо расписано. По умолчанию все типографские элементы должны иметь стили, положенные им от природы, но с учётом дизайна страницы. У нас был один фронтендер, который полностью обнулил стили всех элементов, а далее стилизовал только классы. В итоге, текст статей, набранный контентщиком в админке с использованием визуального редактора выглядел абсолютно безобразно, а именно: тэги p не имели отступа снизу, тэг strong не был жирным, списки не имели отступов ни слева, ни снизу. В макетах от дизайнера был макет страницы статьи, так фронтендер сверстал весь текст на div-ах. А всё потому, что где-то в "умных" книжках он вычитал правило, что никогда ни в коем случае нельзя стилизовать элементы.
А инхаус команда разве не готова удовлетворять самые дикие запросы своего руководства?
Разработка ПО - это не батон колбасы, где купил и забыл. Не думаю, что хоть кто-то в здравом уме будет заказывать разработку серьёзного софта у стороннего исполнителя без дальнейшей перспективы сопровождения этого софта тем же исполнителем. Более того, в любой компании, занимающейся аутсорсинговой разработкой, большинство проектов - это именно сопровождение старых проектов, а не создание новых.
Ох, сколько всего нового появилось. Чувствую, если когда-нибудь снова вернусь к next.js, придётся долго въезжать, что к чему
Делал запрос к бэкенду.
Изначально так и планировалось, но потом почему-то возникла необходимость ещё до начала рендеринга знать тип страницу. Не помню, почему, но знаю, что через год, как я ушёл, кто-то пытался всё это выпилить и упростить, а через две им недели пришлось вернуть всё как было.
А для чего тогда компонент Head придумали, он прекрасно с этим справляется? Я пользовался next.js с 6 версии. И тогда мне очень понравилось то, что это было изоморфное решение, где один и тот же код отрабатывал на сервере при запросе первой страницы, а затем он уже работал в браузере. Всё это делалось с помощью getInitialProps. И для меня было огромным разочарованием, когда этот метод депрекейтнули. Ещё тогда я заметил, если у нас есть отдельный бэкенд, скажем на php, который просто отдаёт данные в json, бутылочным горлышком всей системы был сервер Next.js. Клиентские переходы как правило происходили заметно быстрее, чем запрос с сервера отрендеренной страницы. Очевидно, и сами разрабы некста это признали, когда придумали статическую генерацию. По факту это значит только одно: "Ребята, мы не можем сделать приемлемой скорость рендеринга в next.js, поэтому вот держите генератор статики". Но статика не подходит для проекта, где 100.000 страниц, и в день добавляется или обновляется тысяча из них. Но бог с ней, со статикой, они и динамику испортить умудрились. Сейчас вместо метода getInitialProps рекомендуют getServerSideProps. И теперь вместо того, чтобы бросить с клиента запрос к API бэкенда и получить мгновенно закэшированный ответ, запросы идут всё на тот же сервер next.js, который и так нагружен рендерингом, так ещё эти запросы некэшируемые. ИМХО, последние годы развития next.js - это скорее деградация, нежели развитие.
Интересно, умеет ли app router работать с полноценными синонимами URL, когда нет возможности только лишь по виду URL определить тип страницы? Например, есть страница товара и страница статьи - это два разных компонента. На сайте 100500 статей и товаров с урлами типа /abcd /bcda и т.д. и нужно их рендерить в разных компонентах. Предлагает ли app router что-нибудь для решения этой задачи? Три года назад мне пришлось писать для этого полностью кастомный роутер плюс кастомный компонент ссылки, чтобы обрабатывать ещё и client side роутинг.
Вот только если это, скажем, API ключ к какому-нибудь пусть даже Google Maps API, ключ может оказаться неограниченным по доменам, кто-то может использовать этот ключ у себя, а потом гугл владельцу ключа выставит счёт. Это не говоря уже о том, что бывают довольно дорогостоящие API, и для какого-нибудь школьника или студента счёт в 500 долларов может оказаться ощутимой проблемой.
99.9% одинаковой части уже не первый десяток лет решаются при помощи CMS и фреймворков.
Да, форматировать код ИИ умеет хорошо. И практики всякие применяет. Вот только этот код частенько представляет собой, к примеру, смесь двух версий API, не совместимых между собой. Или предлагает решать задачу путём вызова несуществующего сервиса. Несколько раз пытался использовать в работе ChatGPT и AI Assistant от JetBrains - не удалось извлечь вообще ни малейшей пользы. При этом я не вижу смысла просить ИИ решить какие-то примитивные задачи - мне быстрее написать 5-10 строк самому, чем формулировать промпт аналогичной доины, да ещё потом проверять результат. Я пытался решать задачи, решение которых не мог придумать сам в течение получаса - ChatGPT выдал полную чушь. Все варианты были настолько далеки от действительности, что нельзя было хотя бы пару строк из этого применить. В итоге, подумал ещё полчаса и решил задачи сам.
Причём мне довольно часто приходится общаться с теми, кому ChatGPT очень здорово помогает. А когда ChatGPT не может решить их задачу, они просят меня им помочь.
В том то и дело , что когда сам в технологии не разбираешься, то нейросети очень помогают в освоении технологии. Но когда очень хорошо разбираешься в теме и делаешь что-то сложнее примитивных вещей, то это всё равно, что с джуном советоваться
Я так понимаю, что запутанность состоит в том, что когда меняют параметр одного фотона, аналогично меняется параметр второго фотона. И синхронизация эта происходит мгновенно, независимо от пространственного расположения фотонов. То есть можно поставить источник запутанных фотонов на полпути от Саранска до Плутона и светить им в две стороны. Когда фотон долетит до Плутона, плутоняне меняют его спин, что моментально детектируют жители Саранска. В ответ они у себя в Саранске меняют спин другого фотона, о чём моментально узнают на Плутоне. Пинг выходит нулевой. А после того, как в источнике спутанных фотонов сядет батарейка, каналом связи можно будет пользоваться ещё как минимум два часа, пока последние фотоны не достигнут пунктов назначения.
Самое интересное, что если вдруг какие-то из фотонов реликтового излучения вселенной имеют пары, это значит, что мы с помощью этих фотонов прямо сейчас можем мгновенно передать информацию на другой конец вселенной.
А ведь есть ещё is-odd-number, assert-is-odd, isodd. Также есть, к примеру is-array и isarray, при том, что сейчас нет ни малейшей необходимости ни в одном из них. А если полазить в своих проектах по node_modules, то там найдётся ещё куча is-много-чего. И в большинстве случаев, там кода от 1 до 10 строк. Но к этому ещё может прилагаться 1000 строк документации, юнит-тесты и скрипт для CI. И конечно же, никто это не ставит в свои проекты - оно всегда тянется, как зависимости. Не то чтобы меня это сильно беспокоило, но иногда заставляет задуматься.
На данный момент с точно таким же успехом можно рассуждать, что будет, когда у всех будут летающие автомобили, или когда изобретут гравитационный двигатель. Можно ещё начать считать, какими убытками обернётся владение недвижимостью на Земле, когда все начнут переезжать на Марс.
Ну вот пусть изобретут и заменят. Вот только это "завтра" наступит далеко не завтра. В последний год я стараюсь следить за ИИ-инструментами для программистов, и неоднократно пытался применить их в своей работе. Так вот, если в какой-то теме вообще ничего не понимаешь, то нейросети могут хорошо это объяснить с примерами. Но если ты хороший специалист и хорошо владеешь языками/фреймворками/библиотеками, которыми пользуешься, то хотя бы какую-то минимальную пользу из ИИ выжать практически невозможно. Я даже потратил 10 баксов на AI assistant от JetBrains. Единственное, с чем он нормально справляется - может в комментарии написать, что функция делает. Но вот сгенерировать phpdoc так, чтобы phpcs не ругался - это он уже не может. Притом, что сам по себе шторм умеет делать это довольно сносно. Получается, отдал 10 баксов, чтобы ухудшить функционал своей любимой IDE.
Поэтому я и смеюсь в лицо всем, кто говорит, что ИИ вот-вот заменит программистов. Сперва изобретите что-нибудь, что сможет хоть как-то реально помогать квалифицированным специалистам, а потом посмотрим.
Это тоже выглядит крайне сомнительным, если речь не идёт о совсем уже новичках. Пока максимум, что мне удавалось выжать из нейросетей для работы - это за полчаса потратить впустую полчаса.
А почему вы думаете, что я так думаю? Чтобы было понятнее, перефразирую: до сих пор не удалось заменить с помощью ИИ ни одного программиста уровнем выше мидла.
Можно очень долго спорить, заменит ли ИИ программистов, но есть факт, что до сих пор ни один программист не смог заставить ChatGPT или Copilot работать вместо себя, чтобы самому в это время заниматься своими делами или просто отдыхать.
Я уверен в обратном. Когда начинаешь выбирать стул, сначала выбираешь только по картинке и иногда по параметрам. Потом, когда уже есть представление, что нужно, смотришь конкретную модель конкретного производителя, и всё лишнее в заголовках только мешает. А для SEO-продвижения всю эту дрянь можно запихнуть в описание, а не заголовок.
Мне непонятна мотивация продавцов делать это. Зачем стульям давать какие-то высокохудожественные названия? Чем плохо название "Стул НьюЙоркДрев С777", данное самим производителем?
Пробовал работать на скамейке: через 15 минут отваливается кисть с мышкой, через 30 - шея. И всё это время вытекают глаза, потому что даже в пасмурный день естественное освещение на улице в разы сильнее, чем любые лампы в помещении. В кафе - может быть то же самое. При сидячей работе самое главное - правильная посадка, чего можно достичь только на нормальном офисном стуле. Для себя пришёл к выводу, что если уж очень хочется сходить днём на улицу или в кафе, лучше перед этим поднапрячься, сделать побольше задач, а потом с чистой совестью и пустыми руками пойти на пару часов куда-нибудь.
Макет без адаптивности, без слайдера на главной, без увеличивалки картинок. Вообще без ничего. Я в своё время сделал больше десятка разных интернет-магазинов. Так вот, в процессе создания реального интернет-магазина нет такой стадии, на которой может потребоваться такой вот скетч на ангуляре. Вот это вот всё обычно заказчик рисует ручкой на бумажке, потом дизайнер в какой-нибудь фигме делает такую раскладку прямоугольничков на этапе утверждения ТЗ для создания дизайна.
А то, что получилось у автора больше похоже на контрольную работу на начальном этапе курсов, где требуется сверстать пару примитивных страниц с единственным требованием, что код должен быть валидным. Мол смотрите, я умею закрывать теги, умею флекс в цсс и понял синтаксис js.