index0h

См. https://golang.org/pkg/os/exec/#example_Cmd_Start

Смотри что жрется и чем. Htop + iotop

как происходит разработка в реальном проекте. Как проходят этапы? Сначала фронт, потом бэк добавляется или наоборот или одновременно всё делается?

1. Постановка продуктового ТЗ. Это определение того, что собственно нужно сделать, например добавить на главную календарь.
2. Согласование этапов и правил взаимодействия, документирование api.
3. Постановка задач, для верстки, для фронта, для бэка.
4. Создание общей ветки на фичу.
5. Для каждой задачи - имплементация -> покрытие тестами -> код ревью -> вливание кода в основную ветку.
6. Разворачивание ветки на тестовом стенде, постановка задачи для QA.
7. Вливание ветки в master.
8. Релиз фичи на production.
9. Повторное тестирование QA уже на production.

Проверьте, что ArrMid[i] существует, так же что item_sheet_ln не nil.
В принципе nil может быть и r.Is_factor

$this-session

ничего не смещает?

Вы пытаетесь скрестить ежа с ужом.

UML схемы действительно полезны, когда сразу уместить в голове сложную систему взаимодействия не получается. Например у вас есть 5 обособленных внешних систем со своими состояниями и вам необходимо спроектировать api между каждой из них. UML в этой ситуации вас очень выручит. Если в основном будете использовать sequence диаграммы - рекомендую смотреть в сторону PlantUML. Во всяких VisualParadigm на переделки (а они будут) вы потратите кучу времени, а с текстом в PlantUML это на порядки проще.

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

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

Попросили проверить код, на что смотреть нужно? первый пункт

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

в свою базу данных сохранять нельзя, так как данные в crm меняются иногда.

И в чем проблема? Заливаете данные в таблицы с префиксом например tmp. Когда зальется - меняете эти таблици с текущими рабочими местами. Старые таблицы удаляете.
Такой вариант подходит если у вас коллизий id не будет.

В случае когда коллизии таки возможны - все зависит от конкретно от вашей задачи.

это сложнее чем когда тебе объясняет опытный в этом деле человек.

Есть ли шансы получить нормальную работу с заработком от 30к,а если есть,то какие?

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

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

IT - идеальный вариант, как ни крути.

Войти в IT сейчас довольно сложно, так как конкуренция среди новичков довольно серьезная. Потому не факт.

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

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

Аналитика (в зависимости от компании абсолютно разные стеки знаний), но базы данных вам потребуются с большой вероятностью.
Аудит - это жестко, но если есть желание и рвение, почему бы и да.

По вашему бэкграунду самое близкое - это бухгалтерия, 1C, возможно финансирование.

symfony

request - запрос
request_once - в смысле require_once?
сессии - это способ хранения данных между запросами, как правило для них используются куки
куки - это данные, которые отправляются браузером при каждом запросе

вы бы сначала хоть чуть чуть почитали о том, что спрашиваете

Разделите понятия DEV контейнер и PROD контейнер.
DEV образ не содержит в себе код вашего проекта, он содержит только окружение, а код маунтится через volume. Инженер делает правки у себя лакально, sftp не требуется.
PROD контейнер содержит в себе конкретную версию код со всем и зависимостями, он только запускается для работы в связке с DEV контейнерами.

Например у вас есть сервисы: sa, sb, sc.
В docker-compose.yml вы прописываете 6 сервисов: sa_dev, sa_prod, sb_dev, sb_prod, sc_dev, sc_prod.
Пары *_dev и *_prod живут на одинаковых ip с одинаковыми DNS алиасами, это нужно для того, что бы обеспечить жесткую связь между вашими сервисами и не перехреначивать половину docker-compose.yml

Например вы хотите сделать правки на sb, но sa и sc используются sb. Вы поднимаете:
sa_prod, sb_dev, sc_prod.
Делаете свои правки, проверяете. Когда все ок - коммитите правки и собираете новый образ sb_prod, пушите его в регистр и обновляете версию в docker-compose.yml