Однако есть люди, покупающие лицензии

Хз почему

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

если бы у меня было время и я был джун, я бы форкнул и чонеть дописал в https://github.com/icexin/gocraft

If any network error occurs, the game will end with a panic, may changed in the future. И почему же я не удивлён.

@inside_the_tardis ну потому что во первых это правильно, во вторых бизнес за такое поиметь относительно легко могут

Ну вот. Поэтому хоть какая-то защита должна быть

Чтобы потом можно было предъявить за то, что её выпилили

так предъявить можно даже если защиты нет

Короче, проще делать это вообще без каких-либо механизмов защиты

Только геморорой лишний

а ее нигде нельзя комфортно делать, кроме явы и go

но именно технологическое преймущество у go ровно одно: связка goroutines - thread pool - event loop

и еще кросплатформенный ассемблер, кто понимает, зачем это

все остальное - вопросы синтаксиса

Короче, проще делать это вообще без каких-либо механизмов защиты

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

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

Шарп тоже можно протектить автоматом после компиляции

dnspy и de4dot не открывают Видимо надо как то руками ее отковыривать

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

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

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

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

коллеги, если не трудно, помогите с код ревью. сделал небольшой сервис по продаже файлов за деньги, через я.деньги. прошу объективно покритиковать код. 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 точно нужен, если может быть паника, которую кто-нибудь перехватит. И он удобен, если мьютекс защищает много кода.

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

resp.Write(...)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+++

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

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

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

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

это сарказм?

это сарказм?

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

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

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

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

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

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

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

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

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

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

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

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

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

эх..

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

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

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

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

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

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

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

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

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

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

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

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