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 лет)!
Отличная новость. И у меня (нищебродский :) вопрос. Некоторые продукты JetBrains (в частности CLion) предоставляются разработчикам open source проектов бесплатно + по-моему есть какие-то скидки для студентов и еще что-то. Есть ли что-то подобное в отношении DataGrip? Алсо планируется ли community версия?
Как, пожалуй, с любой технологией, к Git применимо правило 80:20. 20% знаний дают 80% профита, остальные 80% знаний дают оставшиеся 20%. Эти 20% — тоже много и нужны и, как мне кажется, статья дает именно эти 20% которых многим не хватает. Спасибо!
Спасибо за интересную статью. Я с вашего позволения хотел бы дополнить ее ссылкой на еще одну статью, в которой речь идет об опыте практического использования Scala в течение одного года. TL;DR — язык не без косяков, но в целом годный и хорошо подходит для многих практических задач. И как минимум не хуже Java.
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 Мб размером.