Соглашусь с вами. Лично мне данный (о чем я говорит) "шаблон" коммитов нравится и кажется достаточно информативным. Вместо scope, как описано в правилах, можно писать номер задачи:
fix(#1): реализация базового функционала чего-то
Реализовано то-то и то-то в таких-то местах
Ну да, еще с какой подкавыркой. В общем случае, захотелось как-то стандартизировать решение это. А деление на типы коммитов поможет определить кто, что и сколько делал. С другой стороны, можно поставить тэги на задачу, мол БАГ/ФИЧА и так далее, но тут я даже не знаю. Лично мне было бы круто видеть в истории гита не только то, что за задача была, а что именно человек делал, чтобы не лезть в хаб/лаб.
Статья вышла сразу как пришло сообщение с приглашением на тесты. Потом она обновилась, где был заменен текст на более корректный. Сейчас нового обзора не было на технологию, но можно попробовать сделать.
А в чем смысл статьи? Больше похоже на записку в блоге. Типовые запросы - это хорошо, если БД не меняется в процессе. То, что понимание структуры БД занижается - да, согласен, но есть ряд специальностей и задач, где это попросту не нужно. Вот например, сидит какой-нибудь HR и хочет выгрузить статистку там чего-то... Зачем ему структура БД? Ему сказали скрипт запустить, запустил, и все готово.
Для такого рода задач лучше иметь веб или десктоп приложение с графическим интерфейсом, чтобы пользователям было удобно искать нужные скрипты и настраивать из по необходимости.
Зачем Sealed Classes? Кто объяснит их реальное применение, а то кажется, что это какая-то избыточная штука, которой почти никто не будет пользоваться. Я просто реально не понимаю, зачем запрещать реализации классов и ограничивать наследников...
А как тестировать эти штуки и насколько это будет удобно? Вопросы к памяти тоже остались. Вы проводили тесты по объему памяти на примере больших данных? Что это дает кроме удобства (субъективно)?
Не думаю, что отдадут такой заказ компании, которая, как говорилось выше, "сидит в подвале"... Тут, скорее всего, отдадут более крупным разработчиком, например "Департамент информационных технологий города Москвы", "ФГАНУ ЦИТиС им. А.В. Старовойтова" или иным компаниям.
С одной стороны, опустили на землю. С другой стороны, перевыполнили план (уволился), но тут же всем легче стало, так что все закончилось для вас хорошо. Может быть, таким действием вы и ему помогли в будущих работах.
Да, ext4.vhdx файл
Понял, но есть ощущение, что это не сработает с wsl
Надо попробовать, но, что-то у меня есть ощущение, что wsl начнет ругаться.
Да, но мне выдавало в Яндекс решения, которые не работали. Из-за долгого поиска решил написать статью
Про ссылку писал. Покажите как, добавлю в статью
Если подскажите как, то смогу в будущем протестировать это решение и обновить статью на еще +1 метод.
Да, согласен. На Windows все остальное проще, но не разработка ?
Очень понравился подход, а можно получить какую-то болванку на примере реализации модуля, чтобы были разные виды API Gateways реализованы для него?
Соглашусь с вами. Лично мне данный (о чем я говорит) "шаблон" коммитов нравится и кажется достаточно информативным. Вместо scope, как описано в правилах, можно писать номер задачи:
Ну да, еще с какой подкавыркой. В общем случае, захотелось как-то стандартизировать решение это. А деление на типы коммитов поможет определить кто, что и сколько делал. С другой стороны, можно поставить тэги на задачу, мол БАГ/ФИЧА и так далее, но тут я даже не знаю. Лично мне было бы круто видеть в истории гита не только то, что за задача была, а что именно человек делал, чтобы не лезть в хаб/лаб.
Вы можете сделать коммит так, как вам удобно. Ведь, коммит делается после того, как вы добавили файлы.
Статья вышла сразу как пришло сообщение с приглашением на тесты. Потом она обновилась, где был заменен текст на более корректный. Сейчас нового обзора не было на технологию, но можно попробовать сделать.
А в чем смысл статьи? Больше похоже на записку в блоге. Типовые запросы - это хорошо, если БД не меняется в процессе. То, что понимание структуры БД занижается - да, согласен, но есть ряд специальностей и задач, где это попросту не нужно. Вот например, сидит какой-нибудь HR и хочет выгрузить статистку там чего-то... Зачем ему структура БД? Ему сказали скрипт запустить, запустил, и все готово.
Для такого рода задач лучше иметь веб или десктоп приложение с графическим интерфейсом, чтобы пользователям было удобно искать нужные скрипты и настраивать из по необходимости.
Зачем Sealed Classes? Кто объяснит их реальное применение, а то кажется, что это какая-то избыточная штука, которой почти никто не будет пользоваться. Я просто реально не понимаю, зачем запрещать реализации классов и ограничивать наследников...
А как тестировать эти штуки и насколько это будет удобно? Вопросы к памяти тоже остались. Вы проводили тесты по объему памяти на примере больших данных? Что это дает кроме удобства (субъективно)?
Отличная и очень полезная ссылка. Благодарю!
Не думаю, что отдадут такой заказ компании, которая, как говорилось выше, "сидит в подвале"... Тут, скорее всего, отдадут более крупным разработчиком, например "Департамент информационных технологий города Москвы", "ФГАНУ ЦИТиС им. А.В. Старовойтова" или иным компаниям.
С одной стороны, опустили на землю. С другой стороны, перевыполнили план (уволился), но тут же всем легче стало, так что все закончилось для вас хорошо. Может быть, таким действием вы и ему помогли в будущих работах.
В контексте ООП - нет
ТОП прироста числа женщин (%) в ИТ с 2016 по 2021 год.
На 15% в UI/UX-дизайнер
На 7% в Специалист по тестированию/QA
На 5% в Программист C++ и Администратор баз данных.
О чем говорит? Прогать не хотим, хотим "болтать"