mat-ulyana Если ИП без сотрудников из РФ привлекает исполнителей (помощников) из РФ через Upwork, то у этого ИП без сотрудников не возникает дополнительной отчетности перед налоговой и необходимости платить НДФЛ/соц налоги?
И полностью ли корректно со стороны ИП платить исполнителям за работы через Upwork со своего личного счета, не регистрируя его в налоговой?
Тут довольно разные комментарии и комментаторы. Не удивляйтесь, но среди них есть даже такие, для которых вместо здравых суждений достаточно размышлений наподобие "пипец из либ", "сивой кабылы", "дич".
Насчет "пипца из либ" вспомнился коллега, который придерживался аналогичного мнения и стремился сделать проекты с минимум зависимостей. Если задачу не поставить максимально четко вплоть до выбора готовых либ — тратил бюджет проекта на разработку уже изобретенных велосипедов. Потом этот код еще и поддерживать приходилось, а что-то и переписывать, когда доставляло действительно много проблем. По мне лучше использовать готовое и проверенное, чем так.
Мне такое мнение понятно, я и сам лет 10 назад был приверженцем гумнокода. Но с практикой как то пришло понимание, что какой бы проект не начался, после разработки он не упрощается, а наоборот, появляются новые задачи и надо что-то дорабатывать, менять. Гораздо легче это делать, когда заложен сразу номальный подход.
Поделитесь примером, как на самом деле по вашему мнению надо проектировать код, мне не удалось найти вас на гитхабе.
Мне время от времени встречаются разработчики, которые тоже придерживаются мнения, что надо делать "по простому". Недавно вообще попался парень, который даже composer при разработке на PHP не использует. Но по факту код таких ребят оставляет желать лучшего. А истинная причина желания писать "по простому" в нежелании поработать над собой, чтобы научиться делать технологичный код.
У меня такое ощущение, что в гитлабе процентов 90 репозиториев приватные, а в гитхабе 90% публичных. Поэтому смысл анализировать приватные в гитлабе есть. Жаль, что не удается собирать информацию о вкладах, конечно.
В вашем приложении выбраны права read_user profile email. Если добавить read_repository, то должны быть доступны приватные репозитории. Или есть тонкости?
Попробуйте как-нибудь, очень удобно.
А насчет docker volume prune, он не удаляет, например, последние версии остановленных контейнеров (и это, конечно же, хорошо). Но если надо удалить и их, и вместе с волюмом, то удобнее, когда он именованный. Контейнер, кстати, тоже удобно именовать как написал выше. Тогда потом удобно, например, смотреть логи этого контейнера не разыскивая его по закодированным именам.
Частично согласен, интерфейсы в Go хорошо подходят, когда надо описать поведение. Для описания данных они не подходят.
Когда в Go реализуется, например, репозиторий, который должен работать с сущностями конкретного типа, хотелось бы использовать генерики вместо слишком общего interface{}.
Конечно можно, и примеры есть. Docker, например. На PHP 4 без классов тоже были довольно масштабные приложения.
Я о другом. Если в PHP без генериков можно спокойно обойтись, то в Go приходится либо пользоваться рефлексией, по сути отказываясь от статической типизации, либо использовать много где interface{}, либо копипастить, либо придумывать особые реализации.
Сервис-контейнеры тоже можно использовать по разному.
Одно дело, в коде приложения получать экземпляры из контейнера. Тогда ломается идея статической типизации, да и в коде бизнес-логики начинает светиться эта архитектурная подробность.
Другое дело, всю инициализацию прятать в описании сервис-контейнера и необходимые экземпляры прокидывать в конструкторы. Тогда получение экземпляров из контейнера будет только в роутере, и риск получить проблемы в рантайме очень мал.
Пока смотрел сторонние библиотеки, обратил внимание, что почти во всех есть go.mod. Но вот попробовал использовать go modules и столкнулся с тем, что возникают проблемы при выборе версий пакетов
Такой подход позволяет организовать донаты напрямую через платёжные сервисы, без каких-либо скрытых комиссий и без налоговой возни для нас.
Прокомментируйте еще, пожалуйста, для простого разработчика. Какие отноешения с налоговой должны быть у пользователя, получившего вознаграждение, например, на Яндекс Деньги?
mat-ulyana Если ИП без сотрудников из РФ привлекает исполнителей (помощников) из РФ через Upwork, то у этого ИП без сотрудников не возникает дополнительной отчетности перед налоговой и необходимости платить НДФЛ/соц налоги?
И полностью ли корректно со стороны ИП платить исполнителям за работы через Upwork со своего личного счета, не регистрируя его в налоговой?
А я вам ставлю пять за умение мыслить по-гуманитарному. Удачи.
Значит код показать не можете. Ок.
Тут довольно разные комментарии и комментаторы. Не удивляйтесь, но среди них есть даже такие, для которых вместо здравых суждений достаточно размышлений наподобие "пипец из либ", "сивой кабылы", "дич".
Насчет "пипца из либ" вспомнился коллега, который придерживался аналогичного мнения и стремился сделать проекты с минимум зависимостей. Если задачу не поставить максимально четко вплоть до выбора готовых либ — тратил бюджет проекта на разработку уже изобретенных велосипедов. Потом этот код еще и поддерживать приходилось, а что-то и переписывать, когда доставляло действительно много проблем. По мне лучше использовать готовое и проверенное, чем так.
Мне такое мнение понятно, я и сам лет 10 назад был приверженцем гумнокода. Но с практикой как то пришло понимание, что какой бы проект не начался, после разработки он не упрощается, а наоборот, появляются новые задачи и надо что-то дорабатывать, менять. Гораздо легче это делать, когда заложен сразу номальный подход.
Поделитесь примером, как на самом деле по вашему мнению надо проектировать код, мне не удалось найти вас на гитхабе.
Мне время от времени встречаются разработчики, которые тоже придерживаются мнения, что надо делать "по простому". Недавно вообще попался парень, который даже composer при разработке на PHP не использует. Но по факту код таких ребят оставляет желать лучшего. А истинная причина желания писать "по простому" в нежелании поработать над собой, чтобы научиться делать технологичный код.
Отложите пожалуйста
100 more things every designer needs to know about people
У меня такое ощущение, что в гитлабе процентов 90 репозиториев приватные, а в гитхабе 90% публичных. Поэтому смысл анализировать приватные в гитлабе есть. Жаль, что не удается собирать информацию о вкладах, конечно.
В вашем приложении выбраны права read_user profile email. Если добавить read_repository, то должны быть доступны приватные репозитории. Или есть тонкости?
Учитываются ли приватные репозитории?
Попробуйте как-нибудь, очень удобно.
А насчет
docker volume prune, он не удаляет, например, последние версии остановленных контейнеров (и это, конечно же, хорошо). Но если надо удалить и их, и вместе с волюмом, то удобнее, когда он именованный. Контейнер, кстати, тоже удобно именовать как написал выше. Тогда потом удобно, например, смотреть логи этого контейнера не разыскивая его по закодированным именам.На мой взгляд volume удобнее делать именованными. Например, volume для кода можно описать и использовать так:
В таком случае легче, например, грохнуть volume при надобности не разыскивая его среди закодированных названий.
Тут первая строка — обычный volume, а вторая строка — именованный volume. По названию можно легко понять, к какому проекту он относится.
Открыл статью чтобы посмотреть, почему "дорога ярости", но не нашел. Так почему дорога ярости?
Частично согласен, интерфейсы в Go хорошо подходят, когда надо описать поведение. Для описания данных они не подходят.
Когда в Go реализуется, например, репозиторий, который должен работать с сущностями конкретного типа, хотелось бы использовать генерики вместо слишком общего
interface{}.Конечно можно, и примеры есть. Docker, например. На PHP 4 без классов тоже были довольно масштабные приложения.
Я о другом. Если в PHP без генериков можно спокойно обойтись, то в Go приходится либо пользоваться рефлексией, по сути отказываясь от статической типизации, либо использовать много где
interface{}, либо копипастить, либо придумывать особые реализации.В PHP динамическая типизациия. Там это не очень то и нужно.
Сервис-контейнеры тоже можно использовать по разному.
Одно дело, в коде приложения получать экземпляры из контейнера. Тогда ломается идея статической типизации, да и в коде бизнес-логики начинает светиться эта архитектурная подробность.
Другое дело, всю инициализацию прятать в описании сервис-контейнера и необходимые экземпляры прокидывать в конструкторы. Тогда получение экземпляров из контейнера будет только в роутере, и риск получить проблемы в рантайме очень мал.
Пока смотрел сторонние библиотеки, обратил внимание, что почти во всех есть go.mod. Но вот попробовал использовать go modules и столкнулся с тем, что возникают проблемы при выборе версий пакетов
Посматривал на Wire, но после опыта с Dig взял вариант попроще. Но раз советуете, посмотрю на Wire внимательнее.
Являются ли DI и ORM антипаттернами в конкретных проектах, зависит от того, что предлагаете использовать взамен и в каких проектах.
Прокомментируйте еще, пожалуйста, для простого разработчика. Какие отноешения с налоговой должны быть у пользователя, получившего вознаграждение, например, на Яндекс Деньги?