Комментарии

Выбор фреймворка, равно как и языка программирования, зависит от множества факторов. Я приведу основные, самые значимые, на которые смотрю сам.

Востребованность технологии. Насколько много вакансий на рынке, какие в среднем зарплаты. Причём лучше посмотреть по разным странам. Например, PHP-фреймворк Laravel очень популярен на Западе и сильно обгоняет своего конкурента Symfony, а значит, работу на нём будет находить значительно проще. А вот Yii имеет некоторую популярность только в России — да и то вакансий немного.

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

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

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

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

При выборе фреймворка или языка программирования необходимо всегда обращать внимание в первую очередь на его популярность и наличие экспертов в команде (или на рынке). Это позволит в будущем избежать проблем с поиском кадров. Можно выбрать в качестве языка, например, Scala или Clojure, которые, безусловно, имеют свои сильные стороны относительно консервативной Java, но потом столкнуться с серьёзной проблемой поиска специалистов, когда необходимо будет усилить команду или заменить сотрудников, которые решили покинуть проект.

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

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

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

Для бэкенда самыми популярным языками являются JavaScript, Python, Ruby, Java, C#, Go и PHP.

Для простых проектов и задач выбор языка практически не имеет значения. Времена сложных конфигураций с веб-серверами и XML давно прошли, а с текущими MVC-фреймворками написать простое приложение можно на любом языке. Что на Node.js, что на Spring Boot развернуть веб приложение можно всего за несколько минут.

Если же вам нужна автоматическая генерация CRUD веб-страниц, можно использовать Ruby on Rails для Ruby или Grails для Java.

Что касается сложных и объёмных проектов с долгосрочной поддержкой, лучше отдавать предпочтение статически типизированным и компилируемым языкам, таким как C#, Go и Java.

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

И наконец, фреймворки ASP.NET для C# и Spring для Java, благодаря большому набору компонентов в DI-экосистеме, предоставляют все возможности для удобного проектирования и точной конфигурации веб-приложения.

При выборе языка и фреймворка для бэкенда обычно учитывают следующие критерии:

Размер и сложность проекта. Если это небольшой проект или MVP, когда стоят короткие сроки выполнение проекта, то можно выбирать тот язык и фреймворк, в которых есть знание у команды или легко найти специалистов на рынке. Очень часто, особенно на аутсорсе, решение принимается в зависимости от отдела, куда попадает проект. К примеру, один и тот же проект может быть сделан с использованием как Java, так и .NET.

Тип проекта. Разные типы проектов требуют различных технологий. К примеру, приложения с интенсивным использованием данных, системы бронирования, приложения для социальных сетей, потоковые приложения, CMS, IoT, приложения в банковской сфере, торговые площадки и простые MVP, скорее всего, потребуют различных языков программирования и фреймворков.

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

В моей практике чаще всего всё зависело от языка программирования, которым владеет команда. Если команда пишет на C#, то и весь стек связан с платформой .NET. Если команда пишет на Java, то и фреймворки, соответственно, Spring, Hibernate и так далее.

Ещё бы я разделил проекты на корпоративные и не корпоративные. Существует мнение, что корпоративные проекты чаще всего пишутся на Java или .NET. Хотя в последнее время такие языки и фреймворки, как Go, Node.js и Python, составляют достойную конкуренцию по многим параметрам.

Несколько факторов, которые стоит учитывать при выборе:

— Возможности сайта или приложения. Например, если нужны персонализированные рекомендации или анализ данных, то можно выбрать фреймворки, такие как Laravel, Django или Nest.js.
— Объём трафика. Если планируется высокий трафик (от 10 тысяч), то простые решения, например CMS, могут не выдержать нагрузки.
— Масштабирование. Стоит выбирать стек, который позволит легко добавлять новые функции и адаптироваться к увеличению нагрузки, например, Express.js и Nest.js.
— Безопасность. Важно выбирать стек с повышенными механизмами защиты.
— Сообщество. Нужно изучить, насколько активно сообщество каждого фреймворка. Чем шире аудитория, тем больше она предоставляет ресурсов и ответов на сложные вопросы.

Некоторые особенности фреймворков:

— Django (Python). С помощью Django можно быстро настроить и запустить работающий веб-сервис, а специфичные функции и бизнес-логику запрограммировать отдельно.
— Spring Boot (Java). Фреймворк предлагает разработчикам те же самые функции, но при этом работать с ним намного проще. В нём есть встроенные функции безопасности, удобная работа с базами данных и поддержка API.
— Express.js (Node.js). Минималистичный и гибкий фреймворк для создания веб-приложений и API. Известен скоростью и масштабируемостью.
— Laravel (PHP). Удобный для пользователей фреймворк с большим сообществом.

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

Результат может быть разным. Разные модели данных, и даже та же самая модель данных и алгоритм — могут по-разному формировать результат. Так же как и люди. Но один код может стать лучше, другой нет. Даже один и тот же код на разных прогонах может быть лучше и хуже даже на одной модели!

Но вообще — такая стратегия кодогенерации есть — она в классе более глобальной стратегии «Синтетических данных» когда ИИ учится на сгенерированном другой моделью ИИ данных — и получает новый результат. Стратегия спорная, но вроде работает.

Главная дилемма — сейчас ИИ очень сложно оценивать исходный (в т.ч. в базе данных) и сгенерированный код на предмет его эффективности (по набору параметров). Пока только, относительно доступный критерий — это «повторяемость»/«распространённость» частей кода. Но и плохой код может быть очень широко распространён. Более того — как раз эффективный и сложный код распространён очень мало — люди просто мало его пишут, тем более в публичных источниках!

А, вот ИИ — как раз наоборот — может генерировать сложный и очень хитрый код — на котором потом и обучаться!

Но ИИ всё-равно не хватает критериев эффективной оценки кода по целому набору параметров и способов проводить эту оценку — но подход «синтетических данных» может включать в себя не только банальную обработку текстов — но и фактическую проверку программ в режиме исполнения — что позволит собрать больше сведений параметров эффективности!

Но вторая дилемма — эффективность кода очень сильно зависит от контекста и среды применения (входных данных и иных условий эксплуатации) — и вот это ИИ генераторам пока вообще не по зубам — а именно готовность эффективно работать в заданной среде — и определяет конечную эффективность программы — а не её математическая красота!

Вообще — я пропагандирую ЯП 5-го поколения — где написанный/сгенерированный код вообще не является статическим — он постоянно тестируется, профилируется и переоценивается — именно в реальной (снача, конечно, в тестовой) среде эксплуатации. Кстати, а в будущем — ИИ может ещё и сам создавать отдельные тестовые контуры из продуктивной среды — и устраивать там свои эксперименты по разным сценариям эксплуатации и разным видам данных. И по результатам собранных данных генерировать новые версии кода — это и есть динамическое программирование! И, само собой, помещать собранную статистику и версии кода в общую базу знаний — чтобы последующие генерации учитывали этот опыт.

И, кстати, зачатки такой стратегии перекомпилирования уже появились даже сейчас — NET 8 уже так умеет — его JIT-компилятор сначала может генерировать менее оптимальный код (но быстро) — затем запускать его — профилировать на реальном выполнении — и на основе карты быстродействия — параллельно компилировать (уже более длительно и вдумчиво) — новую версию коду. В дальнейшем код снова мог бы снова профилироваться — если будут предпосылки — он мог бы снова перекомпилироваться! Помоем и в Java такое тоже уже есть или ожидается (не помню точно)!

Данный фильм я уже очень давно видел — и всё давно хочу пересмотреть — лежит уже пару лет на винте (кстати на схожу тему — есть серия книг и недавний сериал «Укрытие»)

Но… есть куда более современны фильм, показывающий один из вариантов будущего — «Дитя робота» / «I Am Mother» — но — это лишь один из возможных сценариев! Как вариант будущего — это показанное в мультфильме «Валл-И». Но могут быть и другие сценарии… не обласканные кинорежиссёрами, а порой и не обласканные даже писателями фантастами (хотя те уже столько всего на прогнозировали — что тут уже сложно быть уверенным, что ещё придумаешь что-то оригинальное для всего человечества) — кстати все эти с материалы 100% послужат исходной базой обучения ИИ — который учтёт и проанализирует такие сценарии развития — и будет вести свою деятельность опираясь на эти знания (уж в какую строну — не знаю).

Но, всё-таки, во всех этих фильмах не про программирование и не про программистов (простите Сексмиссию в деталях не помню).

Всё же я выше написал пост в рамках сабжа статьи — про развитие технологий программирования с применением ИИ на ближайшие несколько столетий! А, в первую очередь, именно на вторую половину XXI века! Тут пока ещё не до роботов и продвинутых ИИ систем, с интеллектом, близким к человеческому!

Ещё на тему стратегий развития человечества и ИИ можно вот тут мой комментарий глянуть (да и другие комментарии, и всю статью )

В 1983 году поляки сняли весьма умную комедию «Сексмиссия» (поскольку в СССР секса, как известно, не было, то фильм — разумеется, с купюрами — крутили под названием «Новые амазонки»). Если коротко — в результате глобальной катастрофы передохли все мужики. Остались только двое, которые выжили благодаря эксперименту по замораживанию. Женщин катастрофа не затронула. Итого, на немеряную толпу женщин всего два самца. И понеслось…

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

Совершенно потрясающая статья, хоть и очень небольшая, от того не сильно содержательная, но отлично передающая дух надвигающейся эпохи — я с автором 100% согласен! За программированием с применением искуственного интеллекта (недалёакое) будущее — хотя оно уже наступает — всё-таки, я думаю это станет очевидным лишь ближе к середине века — а расцвет случится уже к концу века (или в начале следующего) — и всё что мы имеем сейчас, после данного этапа эволюции — покажется лишь детским лепетом — а кульминацию стоит ждать ещё через одно-два столетия (хотя может и существенно дольше — это как пойдёт) — когда программисты, в нынешнем их понимании — уже будут практически не нужны — ИИ сами будут писать свой код (и все прикладные и системные приложения будут функционировать и обновляться на основе AI). По оптимистическим мои прогнозам к XXV-век Останется только 3 класса не сильно многочисленных (может пара сотен ярдов) людей-программистов (это при условии развития общества в экспансию рождаемости — на триллионы в год) и удлинение периода активной жизни (на сотни, а затем тысячи лет), и, вероятно, применение технологий компактификации содержания органической жизни (от Матрицы… до… жизни в «пробирке» (колбе) — не помню сейчас у кого из фантастов была такая идея) и расселению людей хотя бы по Солнечной системе; хотя может быть и обратное (существенное сокращение числа людей до золотого миллиарда/триллиона, а то и ещё мельче — при жёстком контроле за рождаемостью, сокращению стремления размножаться и ограниченных ресурсах) — но это всё лирика! И так три класса будущих программистов:

— Исследователи — кто будут исследовать новые пути развития кодовой базы AI — в довесок к аналогичной деятельности самого ИИ

— Кураторы — кто будет следить за кодогенерацией ИИ, его исходной базой знаний и исходным кодом — чтобы не было ошибок и всё было «тип-топ». Они же будут отвечать и за разработку продуктивного кода, с применением ИИ, требующего особо высокого уровня ответственности. Кураторы далее вырастают до Исследователей.

— Аудиторы — это ещё не выросшие Кураторы — занимаются периодическим аудитом всего кода, что генерирует ИИ, от корректности до производительности — делают настройки и баг фиксы на местах — являются прямыми помощниками Кураторов

Но это всё ещё не скоро (XXV век или ещё гораздо позже — если к тому моменту ИИ не запретят вовсе (вспоминаю Френка Герберта) или он не уничтожит всё человечество, или оно само не вымрет или просто станет отупеет до обезьяньего уровня — в т.ч. как раз из-за того, что ИИ всё будет за них делать).

А в XXI и XXII веке — ещё очень как нужны будут программисты (и не только системные или нейро-программисты). В этих периодах ИИ ещё будет достаточно слаб, на фоне своего дальнейшего развития — и им нужно будет ещё очень специфически управлять (давать задачи), и контролировать его результат.

И тут я уже несколько лет пропагандирую, что грядёт эпоха ЯП 5-го поколения, которые будут спроектированы изначально под глубокое взаимодействие с ИИ, продвинутые IDE и последующую кодогенерацию. Их синтаксис, семантика и фреймворки — будут специально разработаны так, чтобы писать код наиболее обобщённо и абстрактно, но в то же время — оптимально для быстрого эффективного разбора для глубокого понимания целей и формирования деталей реализации!

На мой взгляд все актуальные ЯП — для этого не очень подходят — они проектировались для людей, а не для машин!

А ЯП 5-го поколения, с моей точки зрения, должен быть исходно — декларативным, но при этом гибким, и привычным для программистов привыкших императивному, ООП и функциональному стилям программирования. Но код — всё же должен скорее декларировать описание целей того, что надо сделать — как можно менее (но не исключая) затрагивая детали того — как это сделать! Всё остальное — уже дело ИИ-компилятора!

Код будет мало привяз и к платформам и к языкам и к фреймворкам — единая кодовая база — для кодогенерации подовсё!

Само собой, не всегда всё можно реализовать на абсолютно всех платформах — но это уже подскажет ИИ — не стоит писать игру Doom — для калькулятора (хотя — это уже сделали — но не на каждом калькуляторе она, всё-таки, запустится)! Не стоит писать программу расчёты космических полётов для умных лампочек (хотя… распределённая сеть умных лампочек в многоквартирном/офисном доме вполне себе может очень эффективно справляться с такой задачей)!

Само собой — для эффективной кодогенерации нужны хинты — для явного целеуказния ИИ — по-потребности!

Само собой — сама IDE должна активно содействовать как на этапе постпроцессинга, так на этапе ввода программного кода прям «на лету» — сразу проводя анализ и давая подсказки (всё это есть уже сейчас), предлагая хинты настроек конфигурации текущего контекста и дальнейшей кодогенерации! Так же IDE должна иметь средства по умному рефакторингу, применению шаблонов и встраиванию кода из базы знаний в текущий контекст с адаптацией под него. И средства глубокого анализа и подготовки тестирования программного кода! И быстрого предпросмотра генерируемого кода!

Ну и средства отладки таких программ должны быть тоже — особыми — адаптированными под декратаивный исходный код и последующую кодогенерацию

Среди огромного разнообразия нейросетей, количество которых только увеличивается с каждым днём, можно выделить несколько технологий, способных качественно обрабатывать и дорабатывать код. Одним из самых популярных и известных AI помощников безусловно является GitHub Copilot. Это современный инструмент, предназначенный для программистов, использующих технологию искусственного интеллекта. Он помогает создавать код быстрее с минимальными усилиями.

Ядром GitHub Copilot является алгоритм OpenAI Codex — новая система искусственного интеллекта. Авторы программного обеспечения подчеркивают, что оно «понимает» контекст гораздо лучше, чем другие продукты этого типа, предлагаемые на рынке. Независимо от того, работает ли разработчик над документом, комментарием или функцией, GitHub Copilot предоставляет контекстно-зависимые предложения на основе собранных данных. Буквально через секунды GitHub может представить пример использования новой функции или объекта.

Программа «узнает» то, как пишет данный программист, и на основе собранной информации предлагает автодополнение тех или иных элементов кода во время работы. Инструмент позволяет создавать код более эффективно и быстро, что делает GitHub Copilot все более популярным.

Серьезным плюсом является то, что GitHub Copilot доступен для установки в качестве расширения во многих широко используемых IDE, включая такие продукты, как Visual Studio Code, Neovim и JetBrains. Такая интеграция даёт возможность с удобством пользоваться всеми функциями и преимуществами ИИ непосредственно во время привычного процесса разработки без необходимости отвлекаться на обращение к сторонним ресурсам, отдельным чат-ботам и вебсайтам.

А вот насчет как использование Copilot может помочь разработчикам?

Использование Copilot предполагает ряд полезных возможностей для облегчения и упрощения работы программиста:

— генерация кода на основе запроса, в котором указана цель вашей работы

— генерация кода на основе повторяющегося шаблона

— проверка работоспособности кода

— проверка на наличие ошибок и варианты их исправления

— предложения оптимизации и замещающего контента для указанных фрагментов кода

— объяснение принципов работы кода и его отдельных фрагментов с учётом анализа кодовой базы текущего проекта

— поиск и вывод необходимой документации

— автоматическое написание документации к программным кодам

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

Наша компания задумала интеграцию на основе GitHub Copilot, как самого популярного на текущий момент инструмента, но конечно возникает вопрос — как использование GitHub Copilot может помочь разработчикам?

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

Создает ли GitHub Copilot идеальный код? К сожалению, нет. На официальном сайте можно прочитать, что, хотя создатели прилагают все усилия, чтобы инструмент предлагал наилучшее соответствие, нет гарантии, что предложенные решения будут работать на практике. Так, в рамках тестирования на языке Python, программа эффективно справилась с 43% запросов с первого раза и сгенерировала правильный работоспособный код после 10 попыток в 57% случаев. По этой причине очень важно тщательно проверять и тестировать каждое решение, предложенное нейросетью перед эксплуатацией.

Помимо Copilot также существует масса других специализированных ИИ-сервисов, таких как StarCoder, Wolverine, Blackbox AI. Эти инструменты предназначены для поддержки разработчиков в различных аспектах программирования, включая написание кода, автоматическую отладку, анализ и предложения по улучшению кода. Я с ними ознакомился лишь поверхностно, а потому буду признателен, если поделитесь своими впечатлениями и опытом работы в комментариях!
Заключение

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

Что думаете насчет Copilot?

Давайте рассмотрим, как правильно организовать переезд на DST Platform, основываясь на рекомендациях официальной технической поддержки. Этот процесс подходит не только для перехода с CS-Cart, но и для любой другой CMS.

1. Планирование процесса

Перед началом переезда важно тщательно спланировать все этапы, чтобы минимизировать риски и затраты времени. Определите, какие данные и функции необходимо перенести, а также какие ресурсы (время, деньги) вы готовы выделить на этот процесс.

2. Создание резервной копии

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

3. Оценка объема контента

В зависимости от объема вашего контента, подход к миграции может различаться:

— До 5000 товаров: В этом случае можно использовать встроенный инструмент импорта/экспорта через стандартный Excel. Это самый простой и недорогой способ переноса данных.

— От 5000 до 100000 товаров: Если у вас средний объем товаров, то также можно использовать Excel, но процесс может занять больше времени. Рассмотрите возможность привлечения контент-менеджеров или специалистов по миграции данных.

— Более 100000 товаров: Для больших объемов данных рекомендуется использовать специализированные инструменты или писать скрипты на основе API. Это может потребовать дополнительных затрат, но обеспечит более быстрый и точный перенос данных.

4. Перенос статического и информационного контента

Статический контент (описания товаров, категории, страницы и т.д.) можно перенести вручную или с помощью встроенных инструментов DST Platform. Убедитесь, что все ссылки и метаданные корректно переносятся.

5. Настройка дизайна

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

6. Тестирова- — ние и отладка

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

7. Обращение в поддержку

Если у вас возникнут сложности или вопросы в процессе миграции, не стесняйтесь обращаться в официальную поддержку DST Platform. Они всегда готовы предоставить дополнительную информацию и помочь с решением проблем.

Общие советы

— Тщательное планирование: Это ключевой этап, который поможет избежать ошибок и задержек.

— Резервное копирование: Всегда сохраняйте резервную копию данных перед началом миграции.

— Тестирование: Проверяйте все функции сайта после каждого этапа миграции.

— Профессиональная помощь: При необходимости привлекайте специалистов по миграции данных, веб-дизайнеров и контент-менеджеров.

Следуя этим рекомендациям, вы сможете успешно переехать на DST Platform и минимизировать риски и затраты времени. Удачи!

​SEO-данные (ЧПУ, мета-теги) расходились — перебивали вручную — ну вот это, Вы точно зря делали. В каталоге дополнений DST Platform есть отличный модуль «Менеджер мета-тегов». С его помощью можно быстро и легко привести всё в порядок. При этом вы сохраните информацию, которая уже была на другой CMS, а также сможете добавить или изменить нужные данные.

Мы тоже переезжали с CS-Cart на DST Platform полгода назад. Делимся опытом — что прошло гладко, а где пришлось повозиться.

Импорт данных из CS-Cart

DST Platform предоставляет CSV/Excel-импорт, но с CS-Cart есть нюансы:

— Товары и категории выгружались через стандартный экспорт в CSV, но пришлось править структуру полей (например, атрибуты в CS-Cart часто идут в нестандартном формате) в любом случае поправить CSV или в Exel поля, задача 20 минут.

— Заказы и клиенты переносили через API — написали кастомный скрипт (в DST есть документация и собственные API что очень окозалось удобным, но без программиста тут сложно обойтись, хотя задача на 1-2 часа работы).

— SEO-данные (ЧПУ, мета-теги) расходились — перебивали вручную.

Совет: Перед массовым импортом протестируйте на 10-20 товарах, чтобы избежать «мусора» в базе.

В целом переезд своими силами занял 3 дня, много ушло времени на проверку как потом все работает.

Всем привет! Задумались о переезде нашего сайта с CS-Cart на DST Marketplace. Кто уже проходил этот путь? Какие подводные камни стоит учитывать? Поделитесь опытом, пожалуйста! Особенно интересует:

— Как DST Marketplace справляется с импортом контента из других CMS, в моем случае с CS-Cart?

— Какие плагины/модули DST Marketplace лучше купить сразу?

— Насколько сложно адаптировать дизайн с CS-Cart на DST Marketplace?

Буду благодарен за любые советы!

И еще добавил бы — Питон в 70 раз медленнее и в 10 раз прожорливее Си. Это всё, что нужно знать о его пригодности для реальной жизни. Зато учить легко, да. Это вам не Джава.

Поймите не существует некого «программирования в вакууме»… это всегда некий язык с его парадигмами идеями и пр. А в условиях реальной работы это прикладная область + библиотеки и фреймворки. А голое знание сортировок… связанных списков… графов и пр. мало кому интересно.

Учить не языки надо, а программирование. Толку человеку зубрить языки если он программировать не умеет. Ну если только кодером сидеть где-то, чьи-то готовые алгоритмы реализовывать, вставляя туда куски чужого кода из stack overflow. Все равно что шурупы молотком забивать. Язык — всего лишь инструмент, а не самоцель.

Если коротко, то зависит от ваших интересов и направления, в котором планируете развиваться.

— Хотите строить карьеру в области анализа данных, ИИ или автоматизации — обратите внимание на Python. Это отличный выбор для новичков, результат будет заметен уже с первых дней обучения.

— Для веб-разработки и создания интерактивных интерфейсов подойдут JavaScript и TypeScript. Это современная база для тех, кто планирует войти в фулстек-разработку.

— Если привлекают высокопроизводительные системы (игровые серверы, системы обработки транзакций и др.), выбирайте Go. Язык подойдет и новичкам, и опытным — для расширения сферы разработки.

— Наиболее универсальный и при этом востребованный язык — Java. Он подходит для любых задач: от разработки Android-приложений до создания сложных корпоративных аппов. Новичкам стоит присмотреться.

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

— Для работы в российских компаниях будет полезно освоить 1С. А еще это идеальный шанс войти в IT, если пока не уверены в своем английском.