Благодарю за перевод. Если позволите, хотел бы оставить пару замечаний, как пользователь FreeBSD на десктопе (пруф):
На счет драйверов. С ними действительно бывают сложности. Так, например, поддержка OpenGL 3.3+ для Intel HD Graphics 4000 появилась только во FreeBSD 11, которая на данный момент еще в бете. Все это портируется из линуксовых драйверов силами энтузиастов. Еще часто бывают проблемы с Wi-Fi адаптерами. Гибернация не работает практически нигде. К счастью, это не большая проблема в последнее время, так как полная загрузка системы сейчас занимает 1-2 секунды. В общем и целом — выбирать железо под FreeBSD приходится очень внимательно.
Про виртуализацию. Jails использовать очень неудобно по сравнению с тем же LXC. Попробуйте, например, настроить виртуальную сеть между контейнерами. VirtualBox использовал, работает нормально. По идее с ним должен работать и Vagrant.
В мире FreeBSD мне нравится отношение к документации. Она есть и она хороша. По тому же LXC информацию я собирал обрывками месяца два по ишьюсам на гитхабе и блог-постам.
Сообщество вокруг FreeBSD сравнительно небольшое, но технически грамотное и дружелюбное.
Спасибо, весьма интересно. Я, кстати, в свое время составлял шпаргалку по хоткеям IntelliJ IDEA. Смутно припоминаю, что многое из нее работает и для PyCharm, так что может кому-то пригодится.
Анастасия, спасибо за статью. Было бы очень интересно почитать про задачи, с которыми вы сталкиваетесь на работе, и их решение, какие инструменты, литературу или так далее вы при этом используете, читаете ли какие-то профессиональные интернет-ресурсы по теме, и так далее. Мне попадалось очень мало информации по теме в открытых источниках. Пишите еще!
Супер интересная библиотека, спасибо! Пара вопросов, если позволите:
Raft-кластер имеет одного лидера, в который идет вся запись. Верно ли я понимаю, что для распределения нагрузки предлагается создать несколько кластеров на разных портах?
Расскажите, пожалуйста, как вы тестировали вашу реализацию Raft? Доступны ли где-то исходники этих тестов?
git clone git@github.yandex-team.ru:Metrika/ClickHouse_private.git
Cloning into 'ClickHouse_private'...
ssh: connect to host github.yandex-team.ru port 22: Network is unreachable
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
В CMakeLists.txt этот сабмодуль числится как зависимость, без него ничего не соберется:
PVS находил у нас в коде очень серьезные ошибки которые другие статические анализаторы, названные выше, не видели. Код, правда, на чистом Си, про C++14 ничего не могу сказать.
Я тут тоже недавно заинтересовался статическим анализом. Пришел к выводу, что Clang Static Analyzer, к сожалению, является далеко не самым мощным анализатором. Зато он бесплатный и работает везде, это, бесспорно, большой плюс. И если в сочетании с MemorySanitizer то в целом хорошее решение.
Это понятно. На самом деле я всего лишь спрашиваю, не известно ли автору каких-то способов решения этих проблем, о которых я мог не подумать, без перекладывания на асинхронный вариант. Вот чуть ниже он пишет что возможно в случае а) такой способ есть, я правда пока не понял, в чем именно он заключается.
Мм… не могли бы вы пояснить переход к «необязательно выделять тред под коннект». Вот у меня крутится какой-то background процесс который в какой-то момент, не суть важно какой, приходит к пониманию, что пользователю с коннектом 12345 нужно послать в вебсокет очередной кусок данных. Что происходит дальше?
Спасибо за интересную статью.
Сам в последнее время часто думаю о дизайне вроде того что вы описали. Поправьте меня, если я неправ, но верно ли я понимаю, что описанный подход не сработает, если
а) вы хотите слать пользователю пуши, скажем по вебсокету или если у вас кастомный tcp протокол? В этом случае "по треду на запрос" превращается в "по треду на коннект". Или есть идеи как это обойти?
б) если в бэкенде вы ходите в другие бэкенды или СУБД которые выполняют долгие (скажем, больше 1 сек) операции. Опять же, ваши трэды будут висеть по много секунд в ожидании ответа и быстро кончатся.
Все верно? Если да, не боитесь в будущем столкнуться с этими проблемами при вашем текущем дизайне?
Очень интересно, спасибо. Пожалуйста, продолжайте.
Еще, скажите, пожалуйста. Что сейчас из книг считается актуальным по внутреннему устройству Windows? WinAPI / Native API уже не интересуют, интересно информация именно о том как оно работает внутри.
Если позволите, хотелось бы оставить пару ссылок на статьи со своими впечатлениями — раз и два. В дополнение хотелось бы сказать следующее.
В Erlang меня очень беспокоила скорость выполнения кода. Рабочая версия, что был выбран неподходящий под задачу язык, нужно было реально много считать, а Erlang тут не блещет. Также мне лично очень не хватало статической типизации в языке. Dialyzer — не то, слишком медленный, слишком прожорливый, находит далеко не все, половина разработчиков на него забивают. Ну и библиотеки, конечно же.
После Erlang писал на Scala+Akka (тут про впечатления). Хочу сказать, что боли заметно меньше, так как все названные проблему реально решены. Ну и как бонус область применения заметно шире, в частности коллеги вполне успешно разрабатывали на Scala под Android. Если найти сеньера, который будет бить по рукам за Scalaz, Akka Cluster и Shapeless, все будет хорошо. Больше всего неудобств доставляла необходимость изображать легковесные процессы вручную на футурах. Это не сложно, но по неопотности можно собрать кучу гонок и других косяков.
В настоящее время думается что оптимальный вариант для прикладного программирования — это все-таки Go. В нем решены все озвученные выше проблемы, плюс область применения еще шире, плюс для программирования на Go не требуется тяжелой IDE, можно обойтись простым Sublime Text. И на выходе не получаются jar-ники по 100-200 Мб размером.
Большое спасибо за перевод. Я в этом контексте хотел бы сослаться на свою подборку ссылок по OpenGL, а также собственную серию туториалов по нему (здесь начало). Может, кому-то пригодится.
Вопрос, который будоражит умы миллионов — будет ли прямая трансляция? Желательно с возможностью задавать вопросы через email, твиттер по хэштэгу или еще как-то. Насколько я понимаю, это сейчас не сложно реализовать — берем камеру (все равно будете на что-то записывать же), YouTube и вперед.
Ну а что же вы в посте так скромно об этом умалчиваете? Это же самое главное (для тех кто хоть раз пытался вкурить в схему из 250+ таблиц которая развивалась на протяжении 15 лет)!
https://github.com/yandex/ClickHouse/blob/master/.gitmodules
[submodule "private"]
path = private
url = git@github.yandex-team.ru:Metrika/ClickHouse_private.git
… и простым смертным его нельзя склонировать:
git clone git@github.yandex-team.ru:Metrika/ClickHouse_private.git
Cloning into 'ClickHouse_private'...
ssh: connect to host github.yandex-team.ru port 22: Network is unreachable
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
В CMakeLists.txt этот сабмодуль числится как зависимость, без него ничего не соберется:
add_subdirectory (private)
PVS находил у нас в коде очень серьезные ошибки которые другие статические анализаторы, названные выше, не видели. Код, правда, на чистом Си, про C++14 ничего не могу сказать.
Сам в последнее время часто думаю о дизайне вроде того что вы описали. Поправьте меня, если я неправ, но верно ли я понимаю, что описанный подход не сработает, если
а) вы хотите слать пользователю пуши, скажем по вебсокету или если у вас кастомный tcp протокол? В этом случае "по треду на запрос" превращается в "по треду на коннект". Или есть идеи как это обойти?
б) если в бэкенде вы ходите в другие бэкенды или СУБД которые выполняют долгие (скажем, больше 1 сек) операции. Опять же, ваши трэды будут висеть по много секунд в ожидании ответа и быстро кончатся.
Все верно? Если да, не боитесь в будущем столкнуться с этими проблемами при вашем текущем дизайне?
Еще, скажите, пожалуйста. Что сейчас из книг считается актуальным по внутреннему устройству Windows? WinAPI / Native API уже не интересуют, интересно информация именно о том как оно работает внутри.
В Erlang меня очень беспокоила скорость выполнения кода. Рабочая версия, что был выбран неподходящий под задачу язык, нужно было реально много считать, а Erlang тут не блещет. Также мне лично очень не хватало статической типизации в языке. Dialyzer — не то, слишком медленный, слишком прожорливый, находит далеко не все, половина разработчиков на него забивают. Ну и библиотеки, конечно же.
После Erlang писал на Scala+Akka (тут про впечатления). Хочу сказать, что боли заметно меньше, так как все названные проблему реально решены. Ну и как бонус область применения заметно шире, в частности коллеги вполне успешно разрабатывали на Scala под Android. Если найти сеньера, который будет бить по рукам за Scalaz, Akka Cluster и Shapeless, все будет хорошо. Больше всего неудобств доставляла необходимость изображать легковесные процессы вручную на футурах. Это не сложно, но по неопотности можно собрать кучу гонок и других косяков.
В настоящее время думается что оптимальный вариант для прикладного программирования — это все-таки Go. В нем решены все озвученные выше проблемы, плюс область применения еще шире, плюс для программирования на Go не требуется тяжелой IDE, можно обойтись простым Sublime Text. И на выходе не получаются jar-ники по 100-200 Мб размером.