Посмотрел код, хорошо всё написано.
Но действительно не хватает поддержки других платформ.
Я бы начал ей пользоваться, но у меня macOS.
Требуется подключаться к windows и macOS.
А пока вынужден пользоваться teamviewer, но он всё больше и больше расстраивает.
Если вырастите проект до поддержки хотя бы двух OS (windows, macOS) будет просто великолепно!
Иодид серебра токсичен, при контакте или вдыхании концентрированных паров возможно отравление. Симптомы: головная боль, слабость, анемия, потеря веса, раздражение слизистых оболочек. При длительном контакте или вдыхании может развиться аргирия
Всё отлично, но есть один минус, в библиотеке «github.com/restream/reindexer» 66% С/С++ кода, а это значит что используется cgo с постоянным переключением между golang и C вызывающие соответствующие этому проблемы. Если таких переключений мало, то с этим можно кое как жить, но данный вопрос требует изучения.
Было бы идеально если бы вы избавились от С/С++ кода в библиотеке для golang и полностью её написали бы на Go.
Лично меня, с моим перфекционизмом, наличие cgo всегда напрягает, прежде чем использовать такое творение придётся смотреть количество вызовов переключения go -> c, c->go и только потом решать стоит ли…
Подумайте об этом, избавление от cgo добавит значительную часть производительности reindexer и снимет проблему переключения миров c <-> go!
Именно поэтому я никогда не пользовался r01 и подобными и никому не рекомендовал, а все домены которые были там зарегистрированы знакомыми или клиентами всегда переводил на другого регистратора.
Мой основной регистратор это nic.ru, там так домен не украсть, даже имея доступ к почте владельца домена или даже к аккаунту nic.ru владельца, домен не украсть… :)
В базе, сделано верно, надо хранить именно диапазон, начало и конец в виде чисел (не слушайте глупости других комментаторов).
Когда потребуется повысить скорость поиска, то сможете выкинуть SQL и перейти на более быструю базу в которой по sip, eip построить базу с BTREE индексами, они отлично ложатся именно на диапазон.
Тогда поиск станет моментальным, а скорость ответа возрастёт минимум в 100 раз.
Как пример, решение с бд в 40 миллионов записей (все провайдеры мира), база данных Tarantool, язык golang.
Скорость нахождения ответа через api (REST/JSON) — 1.8мс-2мс. То есть, фактически все реальные затраты это кодирование/декодирование json + tcp/ip конекты. :)
Кстати, по некоторым табличкам не хватает индексов, а они сильно влияют на скорость поиска в SQL!
Ну а по теме самой статьи и её сути, могу сказать только то что мельчает хабр, ежегодный постоянный регресс. И это печально… Целая статья о скачивании и заливке базы в бд :(
Грустно это.
Нет более раздражающих работников, чем выпускники ВУЗ-ов — они не только ничего не умеют, но пребывают в иллюзии, что умеют и обладают годами оттренированным паскудством — привычкой писать код так, словно его можно сдать, получить зачет и забыть навсегда.
И ведь ты действительно прав, точно такое же встречал и многократно.
Что самое поразительное, гуглу даже не стыдно!
Взяли блокчэйн от биткойна, назвали «Key Transparency», исключили всё что относится к биткойну (увы, от слова hash не удалось избавится, видимо расстроились на этом моменте).
Теперь осталось только запатентовать… Вот она вся суть аглосаксов, прут у всего мира всё, не краснея, и выдают за то что они это придумали…
Не разводите демагогию!
Без ТЗ это когда устно заказчик что-то рассказывает и показывает на пальцах. Через неделю всё забывает и надо переделывать потому что новый рассказ или «а я думал вы меня поняли» о совсем другом…
Так же без ТЗ это когда формально ТЗ есть но заказчик на него не смотрит и всё еще продолжает устно вносить противоречащие самому себе правки в ходе разработки заставляя тем самым многократно верстать одно и тоже или переписывать один и тот же код под другую логику.
То что вы написали это работа с ТЗ, только ТЗ вы делаете сами и утверждаете с заказчиком.
А наличие ТЗ в первую очередь заставляет делать работу один раз, а не переделывать еще не сделанное много раз.
До Go основным языком был perl, для перехода с perl выбирал между 15 языками, долго выбирал..., так как натыкался на огромные слабости во всех языках, они все не доросли до perl.
Обратил внимание на Go, он сразу понравился и стандартной библиотекой и github был аналогом CPAN и много чего, сделал ставку на него! Спустя 7 лет он остаётся лучшим, пишу на нем и буду продолжать писать!
Посмотрел код, хорошо всё написано.
Но действительно не хватает поддержки других платформ.
Я бы начал ей пользоваться, но у меня macOS.
Требуется подключаться к windows и macOS.
А пока вынужден пользоваться teamviewer, но он всё больше и больше расстраивает.
Если вырастите проект до поддержки хотя бы двух OS (windows, macOS) будет просто великолепно!
Результат агирии — синяя кожа. Агирия не лечится.
Привет смурфикам!
Было бы идеально если бы вы избавились от С/С++ кода в библиотеке для golang и полностью её написали бы на Go.
Лично меня, с моим перфекционизмом, наличие cgo всегда напрягает, прежде чем использовать такое творение придётся смотреть количество вызовов переключения go -> c, c->go и только потом решать стоит ли…
Подумайте об этом, избавление от cgo добавит значительную часть производительности reindexer и снимет проблему переключения миров c <-> go!
Мой основной регистратор это nic.ru, там так домен не украсть, даже имея доступ к почте владельца домена или даже к аккаунту nic.ru владельца, домен не украсть… :)
Когда потребуется повысить скорость поиска, то сможете выкинуть SQL и перейти на более быструю базу в которой по sip, eip построить базу с BTREE индексами, они отлично ложатся именно на диапазон.
Тогда поиск станет моментальным, а скорость ответа возрастёт минимум в 100 раз.
Как пример, решение с бд в 40 миллионов записей (все провайдеры мира), база данных Tarantool, язык golang.
Скорость нахождения ответа через api (REST/JSON) — 1.8мс-2мс. То есть, фактически все реальные затраты это кодирование/декодирование json + tcp/ip конекты. :)
Кстати, по некоторым табличкам не хватает индексов, а они сильно влияют на скорость поиска в SQL!
Ну а по теме самой статьи и её сути, могу сказать только то что мельчает хабр, ежегодный постоянный регресс. И это печально… Целая статья о скачивании и заливке базы в бд :(
Грустно это.
И ведь ты действительно прав, точно такое же встречал и многократно.
Чуток не хватает, хочу сделать рекорд!
Взяли блокчэйн от биткойна, назвали «Key Transparency», исключили всё что относится к биткойну (увы, от слова hash не удалось избавится, видимо расстроились на этом моменте).
Теперь осталось только запатентовать… Вот она вся суть аглосаксов, прут у всего мира всё, не краснея, и выдают за то что они это придумали…
У вашего комента больше всего ответов, вы видимо этого и добиваетесь.
Без ТЗ это когда устно заказчик что-то рассказывает и показывает на пальцах. Через неделю всё забывает и надо переделывать потому что новый рассказ или «а я думал вы меня поняли» о совсем другом…
Так же без ТЗ это когда формально ТЗ есть но заказчик на него не смотрит и всё еще продолжает устно вносить противоречащие самому себе правки в ходе разработки заставляя тем самым многократно верстать одно и тоже или переписывать один и тот же код под другую логику.
То что вы написали это работа с ТЗ, только ТЗ вы делаете сами и утверждаете с заказчиком.
А наличие ТЗ в первую очередь заставляет делать работу один раз, а не переделывать еще не сделанное много раз.
Обратил внимание на Go, он сразу понравился и стандартной библиотекой и github был аналогом CPAN и много чего, сделал ставку на него! Спустя 7 лет он остаётся лучшим, пишу на нем и буду продолжать писать!