В любой беседе всегда нужно сперва договориться о терминах. И если преподаватель бросается какими-то терминами, то их определение он либо объяснял ранее на занятиях, либо вы должны потребовать от него определение термина "утилита для автоматизированного проектирования".
Он должен перечислить вам критерии, по которым вы должны понимать, что перед вами именно эта хрень, а не что-то другое.
Например, я могу любую ORM, поддерживающую миграции, назвать такой утилитой. Ведь там ты описываешь классы, которые можно назвать проектом, а оно тебе автоматически создаёт нужные миграции для создания базы.
Ну не надо оно вам. Поверьте. Как часто на практике приходится менять имя модуля? А если приходится, то что-то вы не так делаете.
Если всё же для вас это критично, то купите себе Jetbrains Goland. Там очень мощный рефакторинг. Например, изменив имя пакета при помощи опции "Rename", он попытается не только изменить все импорты этого пакета в проекте, но даже название директории пакета изменит.
Steel_Balls, А я вам объясню, как это получилось.
Чтобы понять, почему от полного рендеринга на сервере перешли к созданию монструозных SPA, надо понять, что в те годы распространённость быстрого интернета была всё ещё крайне мала, а вот компьютеры стали уже достаточно быстры, да и памяти у них стало значительно больше. Поэтому, с ростом сложности проектов и динамики на страничках SSR начинал тормозить из-за того, что большое количество одновременных запросов не укладывалось в трафик. Решением этого стало кэширование данных в браузере, перенос значительной части функционала в SPA, а общение с сервером стало редким и передавалось мало данных. И это была революция для того времени, ведь можно было пользоваться сложным сайтом даже при наличии 3g модема на телефоне в глухой местности.
Но не будем забывать, что это привело к такому росту сложности браузерного фронтенда, что совсем скоро браузеры превратились в основного пожирателя памяти компьютера. Наличие двух образов данных в браузере и на бэкенде неминуемо привело к росту багов из-за их неверной синхронизации и из-за того, что данные иногда по-разному валидировались в браузере и на сервере. По этому поводу уже давно шло ворчание в соцсетях.
И вот... Случилось... Интернет стал быстрым почти везде, 4G и 5G сделали смартфоны иногда даже быстрее домашнего интернета. Серверы переехали в облака и стали невероятно быстрыми. В результате, уже классические SPA превратились в анахронизм, от которого вреда стало гораздо больше, чем пользы. И люди стали возвращаться к тому, что гораздо лучше и проще - к SSR. Вот и всё.
RadioC, Сайтик, конечно, имеет немножко устаревший дизайн, но вроде бы работает без тормозов, и если он приносит прибыль, то это не так критично. Конечно, мобильная версия далека от идеала, но если клиенты в основном смотрят на десктопе, то и так сойдёт. У меня вот прям слезы ностальгии выступили, я ведь в десятые года как раз такие клепал.
Если я верно понял, то там нет личного кабинета покупателя, а покупки - это просто формы, которые отправляет покупатель, и с ним потом связываются.
Т.е., в принципе, если не хочется переосмысливать дизайн, то можно не обновляться, но обязательно настроить у хостера как можно более частый бэкап, чтобы в случае взлома и шифровки базы было откуда быстро откатиться без потерь контента.
В общем, если затеивать обновление, то работы будет не намного меньше, чем при создании сайта с нуля, т.е. можно будет уже подумать и о новом дизайне, особенно в мобильной версии!
Поспрашивал знакомых, все говорят, что заняты, а может, не хотят возиться. Сам уже давно потерял компетенцию в Drupal, а какую-то студию рекомендовать не могу, так как живу не в РФ.
Ищите контору с хорошими отзывами и портфолио с сайтами, которые выглядит современно, лаконично, а, главное, молниеносно грузятся. Очень тщательно изучите как их сайты ведут себя в мобильной версии. Грехи в мобильной версии выдают неаккуратность исполнителя. Успехов!
Vitsliputsli, BFF - это про сессии, httponly secure cookies, правильный csfr.
Если бы вы знали, как безответственно некоторые фронтендеры относятся к безопасности, храня самые секретные токены где попало, то не говорили бы такое про BFF.
Второй пункт - SSR. Две первые буквы в HTTP обязываются Hyper Text. Разметка передаётся быстро, сразу вставляется в DOM без идиотского медленного парсинга километров JSON. Состояние сессии хранится только в одном месте - на бэке, таким образом не надо тратить нервы на затратную синхронизацию состояния при помощи монструозного пожирания памяти.
Третий пункт - это скорость разработки. Фронтендеру при разработке MVP иногда надо менять API по нескольку раз в день. Я, как бэкендер, послал бы его на три буквы и требовал бы тикетов от менеджера, потому что у меня и так делов полно. Это сильно замедляет разработку.
И т.д., и т.п.
Alex, Всё всегда зависит от проекта и сроков.
Если всё горит, фронтендер уже почти наклепал сайт на Реакте, манагер орёт, что проект должен был быть готов ещё вчера, то берём Symfony + Doctrine + API Platform, и за один день собираем CRUD, который на первых порах будет прекрасно работать.
Если же проект серьезный, время есть, или просто хочется изучить Go, то выбросьте из головы эту джаваскриптизёрскую парадигму о том, что надо ставить npm модуль даже для определения четности числа.
Пишите всё сами, у Go одна из лучших стандартных библиотек. Например, роутер я уже давно использую только стандартный, там есть всё. Строение библиотеки ставьте только тогда, когда вот совсем не знаете, как написать что-то. Для безопасности поставьте пакеты от gorilla (сессии, csrf и т.д.), для работы с базой sqlc. Тут вы пишете в специальных файлах SQL, а sqlc вам сам сгенерирует код для работы с базой в Go. Если хотите сами написать и фронтенд, то очень советую изучить подход, реализуемый HTMX, и тогда вам для написания динамического сайта даже не потребуется знать JavaScript.
Гошники не зря плюются от ООП, ORM, фреймворков, зависимостей и т.д. Это не потому, что мы какие-то заносчивые снобы, а потому, что мы знаем простую истину: чем программа проще, чем меньше в ней магии и зависимостей, тем меньше у нас седых волос и бессонных ночей.
Именно всяческие идиотские глюки и особенности этого костыля насильно заставили меня много лет назад полностью перейти на Linux на десктопе, а потом на Mac. Ни секунды не жалел об этом. Вспоминаю это чудовище как ночной кошмар, который активно мешал заниматься работой.
Вам бесплатный совет, который надо запомнить на всю жизнь: никогда не давайте никому root права. Даже сами не пользуйтесь root учёткой, а создайте себе самому пользователя, который может использовать sudo.
Это как мыть руки перед едой - вопрос гигиены. Да, 999 раз из 1000 ничего не случится, но в самый неподходящий момент подхватите какую-то такую болячку, которая 10 лет жизни заберёт.
Создайте группу, создайте права для этой группы, создайте пользователя для этой группы. Потратьте какое-то время, но обезопасьте себя.
Советы на будущее:
1. Goland часто тупит. Иногда помогает инвалидация кэша. File - Invalidate Caches
2. В связи с текущей ситуацией рекомендую включить вендоринг пакетов (go mod vendor). Таким образом ваши внешние пакеты будут храниться прямо в проекте в директории vendor. Вы можете их закоммитить в git, и тогда вы сможете спокойно собирать ваш проект всегда и везде: и на локалке, и на проде без пляски с VPN и прокси. А VPN вы будете включать только при установке новых пакетов у себя на компе. Больше VPN вам не нужен Дальше завендорите новый пакет, закоммитите его в git, и спокойно работаете.
Anna0802, Это очень правильно. Код пишите только сами. Иначе не научитесь. ИИ просто использовать вместо Гугла.
Совет: когда будете учить CSS, нет ничего лучше, чем изучать чужую работу. Находите что-то прикольное в интернете, и смотрите, как они это сделали. Там просто масса идей, которым вас никто не научит
Anna0802, Охх, удачи вам.
Я раньше думал, что ИИ заменит начинающих программистов. А вот ваш случай дал мне понять, что раньше он заменит плохих преподавателей. Вполне возможно, что он уже лучше)
Anna0802, Поздравляю! Ваш преподаватель плохой.
Понятие "красиво" неприменимо, потому что у всех разные идеалы красоты.
Любой, самый плохонький программист знает, что между людьми идёт нескончаемая война о том, что лучше: табы или пробелы. И такая же война идёт между теми, кто использует разное количество пробелов для отступов. Но самое интересное, что все они правы, потому что у каждого своя "красота".
И единственное, что сдерживает команды разработчиков от бардака - это style guides.
А когда требуешь какую-то "красоту" от неопытного начинающего программиста, это совсем ни в какие ворота. Ведь начинающий не видел много кода в своей жизни, он толком не знает, что такое "красиво".
Хороший преподаватель должен на первых же занятиях рассказать пару баек про оформление кода, про важность того, чтобы все сотрудники использовали единые правила, и должен дать ученикам эти самые правила.
2. YouTube поиск "HTML5"
3. Профит
https://youtube.com/shorts/6_J-3dKB99A?si=uz6yOafE...