Частично согласен, интерфейсы в Go хорошо подходят, когда надо описать поведение. Для описания данных они не подходят.
Когда в Go реализуется, например, репозиторий, который должен работать с сущностями конкретного типа, хотелось бы использовать генерики вместо слишком общего interface{}.
Конечно можно, и примеры есть. Docker, например. На PHP 4 без классов тоже были довольно масштабные приложения.
Я о другом. Если в PHP без генериков можно спокойно обойтись, то в Go приходится либо пользоваться рефлексией, по сути отказываясь от статической типизации, либо использовать много где interface{}, либо копипастить, либо придумывать особые реализации.
Сервис-контейнеры тоже можно использовать по разному.
Одно дело, в коде приложения получать экземпляры из контейнера. Тогда ломается идея статической типизации, да и в коде бизнес-логики начинает светиться эта архитектурная подробность.
Другое дело, всю инициализацию прятать в описании сервис-контейнера и необходимые экземпляры прокидывать в конструкторы. Тогда получение экземпляров из контейнера будет только в роутере, и риск получить проблемы в рантайме очень мал.
Пока смотрел сторонние библиотеки, обратил внимание, что почти во всех есть go.mod. Но вот попробовал использовать go modules и столкнулся с тем, что возникают проблемы при выборе версий пакетов
Такой подход позволяет организовать донаты напрямую через платёжные сервисы, без каких-либо скрытых комиссий и без налоговой возни для нас.
Прокомментируйте еще, пожалуйста, для простого разработчика. Какие отноешения с налоговой должны быть у пользователя, получившего вознаграждение, например, на Яндекс Деньги?
Вот у вас сотрудник, по сути внештатный. Что-то делал в течении месяца. Работал за этот период часов 50. Может быть и 150. Как вы будете считать сколько ему заплатить исходя из истории гита, чатов и таск трекера?
Я не пробовал. С виду хороший вариант. По описаниям правда не понял как учитываются случаи, когда надо отойти от IDE и подумать над решением, время, потраченное на созвоны, обсуждения. В моем случае еще важно считать балансы и делать выгрузки по спринтам, мне это экономит прилично времени.
Перед передачей задачи в разработку мы ее оцениваем вместе с разработчиками. В Gitlab для этого в комментарии к задаче пишем /estimate 5h — значит оценка задачи 5 часов. Потом по завершении работы над задачами проводим сверку, и при проведении ретроспективы спринта обсуждаем случаи, когда фактическое время значительно превысило расчетное.
Причины бывают разные. Бывает и так, что и объективно ошибаемся с изначальной оценкой, что-то не учитываем. Тогда особых вопросов не возникает. Но об этом в процессе работы прошу сообщать коллег, чтобы не было сюрпризов под конец спринта.
Да, ретроспективы проводить надо. Мы, например, проводим. С иллюзией не согласен, проверено на практике. Накладные расходы есть, но они не так велики, и отдача от этого — вовремя сданные проекты с хорошим качеством.
Человек в процессе работы может уйти по своим делам, покушать, поплавать, поспать, особенно если решение задачи растянулось на пару дней. Если считать от создания ветки до мерджа, то получится времени больше чем ушло на задачу в реальности.
Списывать время не обязательно постоянно в течении дня. Можно и один раз в конце дня, если это будут адекватные данные.
Да, любой инструмент можно использовать с пользой для дела, либо вовред. Забыл, кстати, добавить, что мы его используем для удаленной разработки взамен, на мой взгляд, довольно диких инструментов типа слежки за монитором.
Мне не важно в какое время человек работает и насколько интенсивно нажимает на клавиши. Некоторые задачи предполагают мыслительную активность, при которой вообще лучше отойти от компа. Благодаря этому инструменту, как я считаю, нам удается соблюсти баланс между доверием и контролем.
Разработчик отмечает время, которое он провел над каждой задачей. Это встроенный механизм в Gitlab. Можно написать комментарий /spend 3h — отметится, что человек работал над задачей 3 часа.
Сам Gitlab пока не имеет механизма для подсчета затраченного времени за период каждым сотрудником.
Для этой цели Gitpab работает с API Gitlab — получает все комментарии к задачам и извлекает из них информацию о затраченном времени каждым участником.
Результат складывает в локальную базу. Далее по этим данным строит необходмые отчеты — суммирует время, попутно решает и другие задачи.
Эх, знакомая история. Мне тоже такие попадались. Один еще по русски говорил не очень хорошо. Когда он мало стучал по клавиатуре, то от него приходили довольно развернутые ответы. Я их сразу копипастил в поисковик, по первой ссылке получал источник, откуда он их скопипастил.
В ответ на очередной вопрос он долго стучал по клавиатуре, видимо, не мог найти подходящий ответ, и ответил в итоге вот так:
Собеседование длилось очень не долго, но этот кандидат мне запомнился особенно.
Открыл статью чтобы посмотреть, почему "дорога ярости", но не нашел. Так почему дорога ярости?
Частично согласен, интерфейсы в Go хорошо подходят, когда надо описать поведение. Для описания данных они не подходят.
Когда в Go реализуется, например, репозиторий, который должен работать с сущностями конкретного типа, хотелось бы использовать генерики вместо слишком общего
interface{}.Конечно можно, и примеры есть. Docker, например. На PHP 4 без классов тоже были довольно масштабные приложения.
Я о другом. Если в PHP без генериков можно спокойно обойтись, то в Go приходится либо пользоваться рефлексией, по сути отказываясь от статической типизации, либо использовать много где
interface{}, либо копипастить, либо придумывать особые реализации.В PHP динамическая типизациия. Там это не очень то и нужно.
Сервис-контейнеры тоже можно использовать по разному.
Одно дело, в коде приложения получать экземпляры из контейнера. Тогда ломается идея статической типизации, да и в коде бизнес-логики начинает светиться эта архитектурная подробность.
Другое дело, всю инициализацию прятать в описании сервис-контейнера и необходимые экземпляры прокидывать в конструкторы. Тогда получение экземпляров из контейнера будет только в роутере, и риск получить проблемы в рантайме очень мал.
Пока смотрел сторонние библиотеки, обратил внимание, что почти во всех есть go.mod. Но вот попробовал использовать go modules и столкнулся с тем, что возникают проблемы при выборе версий пакетов
Посматривал на Wire, но после опыта с Dig взял вариант попроще. Но раз советуете, посмотрю на Wire внимательнее.
Являются ли DI и ORM антипаттернами в конкретных проектах, зависит от того, что предлагаете использовать взамен и в каких проектах.
Прокомментируйте еще, пожалуйста, для простого разработчика. Какие отноешения с налоговой должны быть у пользователя, получившего вознаграждение, например, на Яндекс Деньги?
Вот у вас сотрудник, по сути внештатный. Что-то делал в течении месяца. Работал за этот период часов 50. Может быть и 150. Как вы будете считать сколько ему заплатить исходя из истории гита, чатов и таск трекера?
Я не пробовал. С виду хороший вариант. По описаниям правда не понял как учитываются случаи, когда надо отойти от IDE и подумать над решением, время, потраченное на созвоны, обсуждения. В моем случае еще важно считать балансы и делать выгрузки по спринтам, мне это экономит прилично времени.
Перед передачей задачи в разработку мы ее оцениваем вместе с разработчиками. В Gitlab для этого в комментарии к задаче пишем
/estimate 5h— значит оценка задачи 5 часов. Потом по завершении работы над задачами проводим сверку, и при проведении ретроспективы спринта обсуждаем случаи, когда фактическое время значительно превысило расчетное.Причины бывают разные. Бывает и так, что и объективно ошибаемся с изначальной оценкой, что-то не учитываем. Тогда особых вопросов не возникает. Но об этом в процессе работы прошу сообщать коллег, чтобы не было сюрпризов под конец спринта.
Предложите более удачное решение для удаленной разработки.
Да, ретроспективы проводить надо. Мы, например, проводим. С иллюзией не согласен, проверено на практике. Накладные расходы есть, но они не так велики, и отдача от этого — вовремя сданные проекты с хорошим качеством.
Человек в процессе работы может уйти по своим делам, покушать, поплавать, поспать, особенно если решение задачи растянулось на пару дней. Если считать от создания ветки до мерджа, то получится времени больше чем ушло на задачу в реальности.
Списывать время не обязательно постоянно в течении дня. Можно и один раз в конце дня, если это будут адекватные данные.
Да, любой инструмент можно использовать с пользой для дела, либо вовред. Забыл, кстати, добавить, что мы его используем для удаленной разработки взамен, на мой взгляд, довольно диких инструментов типа слежки за монитором.
Мне не важно в какое время человек работает и насколько интенсивно нажимает на клавиши. Некоторые задачи предполагают мыслительную активность, при которой вообще лучше отойти от компа. Благодаря этому инструменту, как я считаю, нам удается соблюсти баланс между доверием и контролем.
Разработчик отмечает время, которое он провел над каждой задачей. Это встроенный механизм в Gitlab. Можно написать комментарий
/spend 3h— отметится, что человек работал над задачей 3 часа.Сам Gitlab пока не имеет механизма для подсчета затраченного времени за период каждым сотрудником.
Для этой цели Gitpab работает с API Gitlab — получает все комментарии к задачам и извлекает из них информацию о затраченном времени каждым участником.
Результат складывает в локальную базу. Далее по этим данным строит необходмые отчеты — суммирует время, попутно решает и другие задачи.
Да, внутренние проекты на Gitlab, а опенсурсное привычнее выложить на Github. Про SaaS посмотрю по активности, если будет спрос — сделаю.
Большущее спасибо. Не знал про T и Y. Это то, чего мне частенько не хватало. И, что интересно, проверил — в Gitlab тоже работают эти клавиши!
Эх, знакомая история. Мне тоже такие попадались. Один еще по русски говорил не очень хорошо. Когда он мало стучал по клавиатуре, то от него приходили довольно развернутые ответы. Я их сразу копипастил в поисковик, по первой ссылке получал источник, откуда он их скопипастил.
В ответ на очередной вопрос он долго стучал по клавиатуре, видимо, не мог найти подходящий ответ, и ответил в итоге вот так:
Собеседование длилось очень не долго, но этот кандидат мне запомнился особенно.