бинарник закоммитил, картинки, конфиги

структуры приложения нет - просто все на одном уровне накидано

шаблон впилен в код, без перекомпила шаблон не поменять

коллеги, если не трудно, помогите с код ревью. сделал небольшой сервис по продаже файлов за деньги, через я.деньги. прошу объективно покритиковать код. https://github.com/covrom/fileshare

На блокчейне хоть?

коллеги, если не трудно, помогите с код ревью. сделал небольшой сервис по продаже файлов за деньги, через я.деньги. прошу объективно покритиковать код. https://github.com/covrom/fileshare

Mutex явно не должен встраиваться в структуру. Логичнее выделить его в отдельную переменную

Я про структуру store

Blacklist.Clear логичнее использовать тикер ну и выглядеть будет понятнее чем sleep

Самое важное нет тестов...

Не выдержан общий стиль работы с локами. Где то снимаешь лок через defer где то сам снимаешь перед return

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

Некоторые уважают труд автора. И расчитывают на помощь в случае проблем.

Некоторые уважают труд автора. И расчитывают на помощь в случае проблем.

Но таких очень мало

Кто ради уважения труда разработчика будет платить деньги?

Кто ради уважения труда разработчика будет платить деньги?

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

Кто ради уважения труда разработчика будет платить деньги?

платят ради сапорта

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

Не выдержан общий стиль работы с локами. Где то снимаешь лок через defer где то сам снимаешь перед return

Это не проблема, если сделано ради скорости в месте, где не может быть panic. Всё-таки, у defer накладные расходы больше, чем взятие+отпускание мьютекса (если нет контеншена).

Это не проблема, если сделано ради скорости в месте, где не может быть panic. Всё-таки, у defer накладные расходы больше, чем взятие+отпускание мьютекса (если нет контеншена).

Да я знаю, я тому что лучше в одном стиле и желательно без defer

Кто ради уважения труда разработчика будет платить деньги?

Многие

Тем более нет сложных ветвлений

Да я знаю, я тому что лучше в одном стиле и желательно без defer

defer точно нужен, если может быть паника, которую кто-нибудь перехватит. И он удобен, если мьютекс защищает много кода.

Это да,но не в этом случае.код маленький и без паники ?

ребят, кто-нибудь может скинуть, как слать responce в GoLang ?

мануал какой-нибудь

resp.Write(...)

спасибо !

ок, спасибо коллеги! буду править. тестов добавлю.

Mutex явно не должен встраиваться в структуру. Логичнее выделить его в отдельную переменную

Почему вам это кажется логичнее?

Почему вам это кажется логичнее?

Потому что это часть внутренней кухни и не должна быть публичной. Если посмотрите ещё на stdlib то вряд ли найдёте (во всяком случае я не нашёл) структуру где мьютексы встроены в структуру. Они всегда являются явным приватным атрибутом.

Это вкусовщина, встраивание мутекса вполне обычная ситуация, чуть ли не в примерах с мутексами используется, а вот публичный Store у коллеги, это плохо, тк можно руками туда залезть

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

Также «единый стиль» работы с мутексами, то же вкусовшина, если в функции несколько точек выхода, я бы вешал дефер (если нет критичной производительности), но это не повод везде писать деферы

Также «единый стиль» работы с мутексами, то же вкусовшина, если в функции несколько точек выхода, я бы вешал дефер (если нет критичной производительности), но это не повод везде писать деферы

Да согласен про вкусовщину

поправил часть

Самое важное нет тестов...

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

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

> ну доступны локи снаружи пакета, не критично согласен

неприватные мапы опасны в том смысле, что использующий код разработчик может банально забыть про необходимость работы с мьютексом

ой, да когда это вообще случается?

забыл про мьютекс — сам виноват

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

забыл про мьютекс — сам виноват

это все прекрасно, но людям свойственно ошибаться

а приватные мапы задолбаешься парсить из json, например. придется лепить еще более сложные костыли. тут нужен баланс, не надо все инкапсулировать, тем более в таком простом проекте, имхо

+++

а приватные мапы задолбаешься парсить из json, например. придется лепить еще более сложные костыли. тут нужен баланс, не надо все инкапсулировать, тем более в таком простом проекте, имхо

а может не надо смешивать слой, отвечающий за ввод/вывод (парсинг) и слой, отвечающий за бизнес логику (конкурентная работа с мапой)

Глупости какие-то Вот как случится гонка — тогда и будем думать

Глупости какие-то Вот как случится гонка — тогда и будем думать

это сарказм?

это сарказм?

Как и все сообщения кроме сообщений Романа, который не прав и Андрея, который не выкупает сарказм

мне кажется андрей "не выкупает" сарказм, так как его там просто нет.

мне кажется андрей "не выкупает" сарказм, так как его там просто нет.

всё так, никакого сарказма

Есть, есть) Сергей же жирный тролль из расточата

донован одобряет встраивание мьютексов. а вот геттеры и сеттеры это инакомыслие

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

Херово что система типов никак не показывает, что с типом данных можно безбоязненно общаться конкуррентно

Херово что система типов никак не показывает, что с типом данных можно безбоязненно общаться конкуррентно

может им пропозал написать?

Приходится в код лезть смотреть как там реализованы методы доступа

может им пропозал написать?

Это дженерики нужны будут, не примут

эх..

Херово что система типов никак не показывает, что с типом данных можно безбоязненно общаться конкуррентно

это потому, что нельзя

обычно, об этом пишут в доке к структуре

ненене, это потому, что слишком сложно

это потому, что нельзя

ну если система типов адекватная, то можно:)

вот да. но могут же написать, а потом переписать

это потому, что нельзя

Ну а потом получается что на одной структуре висят дабл локи, один внутренний, другой внешний, потому что юзер не знал что внутри уже есть мьютекс)

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

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

пробрасывая immutable data structures?

ERROR: S client not available

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

В джаве она есть, это не сильно помогает. Все равно никаких гарантий, что новый джун не забудет написать кейворд synchronized в critical section

пробрасывая immutable data structures?

копию пробрасывая...

копию пробрасывая...

Ух

копию пробрасывая...

ну это то же самое в данном контексте (только не иммутабл)

Мач перформанс

ой, перестаньте

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

это как? даже в случаи банального int надо юзать мьютекст уже

если сотворили глобальный счетчик какой либо

это как? даже в случаи банального int надо юзать мьютекст уже

Открой для себя атомики

да знаю про них

ну вот

они же мьютекс оборачивают?

нет, наоборот

они же мьютекс оборачивают?

не знаешь

они же мьютекс оборачивают?

Видимо не знаешь

это мутексы сделаны на атомиках

не знаю

в кишки не лезу по возможности

работаю по возможности как с "черным ящиком"

а надо бы знать, если на перформанс топить

обычно перфоманс явно просаживается не на уровне приложения

в кишки не лезу по возможности

Это базовые вещи в параллельном программировании, хм.

"барьеры памяти" в нем базовые. с тех пор, как в проце есть кеш, и ядер больше одного

копию пробрасывая...

подлянка в том, что даже если саму структуру копировать, то её ссылочные поля передаются по ссылке, и всякие слайсы/мапы тоже, что делает процесс копирования генерацией бойлерплейта

на самом деле - это все вопрос дизайна

совершенно не обязательно шарить что попало

самое неприятное в каналах то, что они медленные

правда, узнать об этом можно только в очень специфических случаях

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

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

оставаясь в рамках го?

самое неприятное в каналах то, что они медленные

Они в го mpmc? (multiple producers, multiple consumers)

да