А лучше ещё процессор получше core i7, например, nvme ssd неплох, хорошую видекарту добавить, и будет вообще огонь машина.
За $140 долларов машинка с экраном, клавиатурой и батареей, которая может работать и что-то выполнять — это очень круто.
Да, тоже удивился про количество. Брал на али на распродаже «комп» с подобным конфигом (только там ещё и атом до кучи), так из коробки без отключения всякого хлама где-то 1.1Гб было занято. И винда где-то 11Гб сожрала всего. Т.е. вполне реально пользоваться можно.
Да, ключи могут поменяться, могут утечь, мессенджер может сливать информацию. Гарантии никакой нет. С криптографией основные протоколы согласования давно придуманы, и не думаю, что придумают что-то ещё (кроме конкретных алгоритмов шифрования).
Поэтому я в этом плане поддерживаю политику Телеграма: удобные чаты для всех, секретные, чтобы говорили о том, что они есть, всякие забавные фишки вроде эмоджи на звонках, чтобы начать разговор со сверки смайликов.
Т.е. с маркетинговой точки зрения — абсолютно правильная политика. Большинству не нужны секретные чаты, нужны фразы о том, что они есть и специалисты довольны.
Проблема в том, что вы можете обменяться ключами безопасно по данному протоколу, но не ясно с кем. Т.е. посередине может быть человек, который будет посредником и пропускать всё через себя. Чтобы это обойти придумали сертификаты и доверие, т.е. мы начинаем доверять кому-то, кто говорит, что никого посередине нет. В мессенджерах пытаются обойти тем, что показывают секретный ключ, который можно (и нужно) сверить по отдельному каналу.
Ну обычно приложения всё-таки стараются писать так, чтобы они не падали от любого эксепшена, а креши бывают жёсткие, так что ничего пикнуть не успевает. И часто последние строчки в логах бывают очень важны. Классический пример — OOM убийство, когда по логам можно понять, где примерно всё случилось. Ну и всякие ребуты железа, убийство процессов и т.д.
Внимательный читатель наверняка предложит полностью перейти на синхронные логгеры. Почему бы и нет? У синхронных логгеров есть неприятность – они сильно нагружают cpu. Например, в моем случае с асинхронным логгером загрузка cpu ~100% (по данным утилиты top), а в синхронном варианте порядка 10-20%. Если асинхронных логгеров будет больше, то и загрузка cpu значительно поднимется.
Так кто больше нагружает CPU, синхронный или асинхронный?
У асинхронных логгеров есть другая проблема — в случае креша приложения, информация асинхронном логе может пропасть, т.е. как раз самая важная причина креша будет недоступна.
А Яндекс встречается? Какой-то странный довод. Да ещё «возможно». С учётом того, что у вас в профиле написано HR — не знать названия компаний, да ещё и коверкать их — какое-то странное поведение :)
А у меня есть примеры, что разработчики разрабатывают на .NET/.NET Core на Windows, а деплоят это и на Linux, и на Windows. Т.е. используется мультитаргет, а запускается где удобнее. И волосы густые и шелковистые.
С симуляциями как-то обойдён стороной момент, что мир за пределами симуляции может быть совершенно другим. Скорость света там может быть больше, или вообще бесконечная, так что для «компьютеров» там совершенно другие ограничения. Время может течь по-другому, размерность пространства тоже быть другой.
В итоге, по факту, доказательствами симуляции могут быть только какие-то концептуальные противоречия в нашей физике, что объекты ведут себя не так, как должны, и это никак не может быть объяснено (например, из-за ограничений симуляции и оптимизации расчётов).
С другой стороны, любые проблемы могут мгновенно перестать ими быть (всем людям исправят в голове устройство мира). Т.е., например, Земля была в прошлом плоская, а звёзды были обычными цветными пикселями. Но, когда начались исследования — всё поменялось и «отрендерилось» и стало по-другому. Впрочем, это уже как раз философия.
Про глубину legacy и скриншоты СБИСа мне понравилось :)
Но вообще, есть же вьюшки и триггеры в базе данных, т.е. можно изменить структуру, улучшить алгоритмы, а для legacy кода подснуть представление.
А как вы разрабатываете? Т.е. задача формулируется максимально абстрактно, и делается максимально абстрактно? Если вы настолько не знаете требования к своей же функциональности.
Через ID предка — самый простой вариант, но самый неэффективный. И оптимизировать его, вместо использования более логичных структур — интересное, но не очень полезное занятие.
Небольшую иерархию можно вообще засосать в память и не париться ни о чём. А если иерархия с 10 млн элементами, то стоит всё-таки подумать о конретных требованиях к задаче.
Конечно же, если статья написана с целью рассказать про CTE и рекурсивные джойны, а в реальности вы используете что-то другое, то это отдельный разговор.
Кирилл, твой ответ выглядит так, что ты пошёл гуглить что такое Nested Set и взял первую ссылку из гугла на википедию, и из этого сделал выводы :)
Отвечаю:
1. Да, Nested сет имеет более затратные операции изменения иерархии, при этом сильно упрощая операции поиска. Если у вас постоянная текучка кадров, что операции вставки становятся неприлично тяжёлыми, то стоило бы упомянуть это в задаче. Т.к. большинство иерархий достаточно редко меняются.
2. В Nested Set надо переупорядочивать только Left/Right указатели, Id — это отдельное поле, которое трогать не надо.
Т.е. куча страданий и потраченного времени программиста, лишь бы не вводить Lineage или какой-нить Nested set? Которые кучу проблем смогли бы решить гораздо проще.
Так опять же. Насколько он мешает? У нас идёт только вставка, т.е. мёртвых записей не должно быть, вакуум просто пропустит эту таблицу.
А вот пункт «4 — кое что меняется в данных», выглядит как объяснение всего что может быть. В общем-то это смысл существования базы данных — кое-что менять в данных :)
А стоят ли такие сложности выигрыша в сколько-то % производительности, даже не могу представить сколько 1? 2? (с учётом статьи, вакуум даже работать не будет на этих таблицах, т.к. по критериям очистки не подойдут).
А можно перечислить причины, почему нужно отключать автовакуум? Просто все статьи, упоминающие Постгре серьёзно настаивают и предупреждают, что ни в коем случае, никогда, ни при каких условиях не отключайте вакуум. Данная не исключение.
Соответственно, я никак не могу понять, откуда берутся люди, которые это делают? Это специальные вредители среди разработчиков и админов? Или классический гипотетический сотрудник, который только в рекламе и сериалах попадается?
За $140 долларов машинка с экраном, клавиатурой и батареей, которая может работать и что-то выполнять — это очень круто.
Поэтому я в этом плане поддерживаю политику Телеграма: удобные чаты для всех, секретные, чтобы говорили о том, что они есть, всякие забавные фишки вроде эмоджи на звонках, чтобы начать разговор со сверки смайликов.
Т.е. с маркетинговой точки зрения — абсолютно правильная политика. Большинству не нужны секретные чаты, нужны фразы о том, что они есть и специалисты довольны.
Так кто больше нагружает CPU, синхронный или асинхронный?
У асинхронных логгеров есть другая проблема — в случае креша приложения, информация асинхронном логе может пропасть, т.е. как раз самая важная причина креша будет недоступна.
В итоге, по факту, доказательствами симуляции могут быть только какие-то концептуальные противоречия в нашей физике, что объекты ведут себя не так, как должны, и это никак не может быть объяснено (например, из-за ограничений симуляции и оптимизации расчётов).
С другой стороны, любые проблемы могут мгновенно перестать ими быть (всем людям исправят в голове устройство мира). Т.е., например, Земля была в прошлом плоская, а звёзды были обычными цветными пикселями. Но, когда начались исследования — всё поменялось и «отрендерилось» и стало по-другому. Впрочем, это уже как раз философия.
Но вообще, есть же вьюшки и триггеры в базе данных, т.е. можно изменить структуру, улучшить алгоритмы, а для legacy кода подснуть представление.
А в течение 12 лет тратить на обогрев улицы ресурсы CPU постоянно делая неэффективные операции — это норма?
Через ID предка — самый простой вариант, но самый неэффективный. И оптимизировать его, вместо использования более логичных структур — интересное, но не очень полезное занятие.
Небольшую иерархию можно вообще засосать в память и не париться ни о чём. А если иерархия с 10 млн элементами, то стоит всё-таки подумать о конретных требованиях к задаче.
Конечно же, если статья написана с целью рассказать про CTE и рекурсивные джойны, а в реальности вы используете что-то другое, то это отдельный разговор.
Отвечаю:
1. Да, Nested сет имеет более затратные операции изменения иерархии, при этом сильно упрощая операции поиска. Если у вас постоянная текучка кадров, что операции вставки становятся неприлично тяжёлыми, то стоило бы упомянуть это в задаче. Т.к. большинство иерархий достаточно редко меняются.
2. В Nested Set надо переупорядочивать только Left/Right указатели, Id — это отдельное поле, которое трогать не надо.
А вот пункт «4 — кое что меняется в данных», выглядит как объяснение всего что может быть. В общем-то это смысл существования базы данных — кое-что менять в данных :)
Соответственно, я никак не могу понять, откуда берутся люди, которые это делают? Это специальные вредители среди разработчиков и админов? Или классический гипотетический сотрудник, который только в рекламе и сериалах попадается?