Я не очень понял реальные юзкейсы, где может потребоваться использование циклических буферов такого типа. Буфер под ссылки с кешированием - тоже не очень буфер, имхо. Если есть короткая ссылка куда нибудь буду рад познакомиться
И зачем нужно, чтобы ссылки кешировались? Это будет влиять на производительность? Просто я видел использование кольцевых буферов в драйверах Ethernet и использовал из в драйверах АЦП, везде стат аллокация памяти и DMA. С boost не работал. Поэтому и не очень понимаю о чём речь, хотя идея и понятна
"Разумеется, это также означает, что, если вам приходится оперировать сравнительно крупными элементами, то вы особенно не выиграете от оптимизации кольцевого буфера"
на этом можно было бы и закончить с оптимизацией, имхо.
Во первых не все в пятницу отключают электричество, во вторых да, суббота у всех священна, зато в воскресенье вполне себе работают. Меня больше сентябрьские праздники удивляли - правильные их почти 2 недели "отмечали"
Всё через ПМ это не американские игры, а корпоративные. В стартапах это минимизировано, там и ПМов то может не быть), а по мере роста растут и прослойки, и им надо быть в курсе и руководить. В одной конторе мой начальник был СТО, в другой VP, но с CTO при необходимости я тоже мог легко пообщаться. Закончилось это структурой из CTO, старшего VP, моего прежнего VP и дев менеджера. При этом вокруг этой вертикали были продакт оунеры, релиз менеджмент, проджект менеджмент, комплианс и скорее всего кто то ещё. После какого нибудь тех митинга, на котором присутствовало только 3-4 инженера из 20 участников, некоторые подразделения проводили ещё митинг, на котором один инженер рассказывал своим начальникам на что они так позитивно и вежливо сказали great и ок)
Отличная статья и проект, насчёт аппетита - всё верно) Один из выводов -инженерка должна проектироваться с учётом совместимости с умным домом и особенно HA, поскольку интеграции через облака при отсутствии интернета будут отваливаться Странноватым показались следующие характеристики инженерки - котел на 36 кВт для дома менее 200 м - у меня на брикетах 28 кВт на 200 общей площади, топлю раз в сутки по 40-60 кг, отопление только тёплыми полами. Вентсистема на 15 кВт - она без рекуперации? Но это, конечно, к автоматизации не относится. Но автоматизацией, наверное, проблему этих 15 кВт можно решить - датчик CO2 в выхлопе и управление производительностью.
У нас на совсем другой платформе возникала проблема с tcp, причём на давно работавшем коде, на долгих запросах к бд. Неожиданно они стали зависать и отваливаться. Как всегда, никто ничего не делал) Проблема оказалась в изменении полиси роутеров, которые без трафика стали прихлопывать соединение через час, а дефолтный кипэлайв был 2 часа. И для сервера и для клиента сам разрыв соединения был незаметен. Вообще контроллировать доступность сервиса по таймаутам прикладного протокола конечно можно, но не достаточно, имхо
А разве менеджер запихивает задачи, а не команда их берет на основании своих оценок? А остатки времени забиваются тасками из бэклога как баблайтемы? И как аналитик может эстимировать объём работы по задаче и подводные камни?
А что, в канбане нет планирования и оценки? Откуда берутся таски, которых не более чем сколько то на разработчика? Как увязать тест план новой фичи по 3 командам с её разработкой и деплоем? Эстимейты фиксов и фич откуда берутся, или менеджмент не требует сроков и не считает ресурсы? Точно такие же статьи писали про аджайл и вотерфол - как трудно работать по второму и какое счастье по первому - теперь "они" начали пожирать себя изнутри, ха-ха-ха))) Команда могла бы выбрать способ организации работы сама, но есть продакты, проджект менеджеры, релиз менеджмент, адм деление на команды и отделы, и всем нужны какие то красивые доски с перманентно улучшающимися показателями. Всё это упирается в команду из нескольких "ресурсов", которая в итого и делает всех счастливее.) И во что превращается какой то конкретный аджайл определяется именно этим менеджментом. И как срезают углы в ясно прописанном скраме или канбане -тоже, а их срезают..
ПО следует разделять на архитектурные и конструктивные компоненты. Архитектурные имеют долговременную стабильность и переносимость между платформами, конструктивные предназначены для адаптации к платформам, вводу выводу и интерфейсам - забыл источник)
Не согласен. Я спорт вообще не использую - уведомления, пульсометр, иногда шаги и этажи, иногда навигатор. Но то, что часы надо заряжать раз в 10 дней делает их для меня существенно ценней, чем более электро продвинутые. И потом - они прочные)
Я не очень понял реальные юзкейсы, где может потребоваться использование циклических буферов такого типа. Буфер под ссылки с кешированием - тоже не очень буфер, имхо. Если есть короткая ссылка куда нибудь буду рад познакомиться
И зачем нужно, чтобы ссылки кешировались? Это будет влиять на производительность? Просто я видел использование кольцевых буферов в драйверах Ethernet и использовал из в драйверах АЦП, везде стат аллокация памяти и DMA. С boost не работал. Поэтому и не очень понимаю о чём речь, хотя идея и понятна
"Разумеется, это также означает, что, если вам приходится оперировать сравнительно крупными элементами, то вы особенно не выиграете от оптимизации кольцевого буфера"
на этом можно было бы и закончить с оптимизацией, имхо.
Во первых не все в пятницу отключают электричество, во вторых да, суббота у всех священна, зато в воскресенье вполне себе работают. Меня больше сентябрьские праздники удивляли - правильные их почти 2 недели "отмечали"
Всё через ПМ это не американские игры, а корпоративные. В стартапах это минимизировано, там и ПМов то может не быть), а по мере роста растут и прослойки, и им надо быть в курсе и руководить.
В одной конторе мой начальник был СТО, в другой VP, но с CTO при необходимости я тоже мог легко пообщаться. Закончилось это структурой из CTO, старшего VP, моего прежнего VP и дев менеджера. При этом вокруг этой вертикали были продакт оунеры, релиз менеджмент, проджект менеджмент, комплианс и скорее всего кто то ещё. После какого нибудь тех митинга, на котором присутствовало только 3-4 инженера из 20 участников, некоторые подразделения проводили ещё митинг, на котором один инженер рассказывал своим начальникам на что они так позитивно и вежливо сказали great и ок)
Полно проприентарщины с которой HA интегрируется только через сервис производителя, а не как с устройством
24 норм - быстрее прогрев, горячая вода, та же вентиляция, а вот 36 - подозрительно)
Отличная статья и проект, насчёт аппетита - всё верно) Один из выводов -инженерка должна проектироваться с учётом совместимости с умным домом и особенно HA, поскольку интеграции через облака при отсутствии интернета будут отваливаться
Странноватым показались следующие характеристики инженерки - котел на 36 кВт для дома менее 200 м - у меня на брикетах 28 кВт на 200 общей площади, топлю раз в сутки по 40-60 кг, отопление только тёплыми полами. Вентсистема на 15 кВт - она без рекуперации? Но это, конечно, к автоматизации не относится. Но автоматизацией, наверное, проблему этих 15 кВт можно решить - датчик CO2 в выхлопе и управление производительностью.
Ладно что без вирусов...)
У нас на совсем другой платформе возникала проблема с tcp, причём на давно работавшем коде, на долгих запросах к бд. Неожиданно они стали зависать и отваливаться. Как всегда, никто ничего не делал) Проблема оказалась в изменении полиси роутеров, которые без трафика стали прихлопывать соединение через час, а дефолтный кипэлайв был 2 часа. И для сервера и для клиента сам разрыв соединения был незаметен.
Вообще контроллировать доступность сервиса по таймаутам прикладного протокола конечно можно, но не достаточно, имхо
И манагеров так же перемешать - сегодня ты сто а завтра проджект менеджер))
А разве менеджер запихивает задачи, а не команда их берет на основании своих оценок? А остатки времени забиваются тасками из бэклога как баблайтемы?
И как аналитик может эстимировать объём работы по задаче и подводные камни?
А что, в канбане нет планирования и оценки? Откуда берутся таски, которых не более чем сколько то на разработчика? Как увязать тест план новой фичи по 3 командам с её разработкой и деплоем? Эстимейты фиксов и фич откуда берутся, или менеджмент не требует сроков и не считает ресурсы?
Точно такие же статьи писали про аджайл и вотерфол - как трудно работать по второму и какое счастье по первому - теперь "они" начали пожирать себя изнутри, ха-ха-ха)))
Команда могла бы выбрать способ организации работы сама, но есть продакты, проджект менеджеры, релиз менеджмент, адм деление на команды и отделы, и всем нужны какие то красивые доски с перманентно улучшающимися показателями. Всё это упирается в команду из нескольких "ресурсов", которая в итого и делает всех счастливее.) И во что превращается какой то конкретный аджайл определяется именно этим менеджментом. И как срезают углы в ясно прописанном скраме или канбане -тоже, а их срезают..
Не работает - как только Шахназаров попросил снять блокировки на десктопах, так сразу и стал подвисать на мобильном Мегафоне
ПО следует разделять на архитектурные и конструктивные компоненты. Архитектурные имеют долговременную стабильность и переносимость между платформами, конструктивные предназначены для адаптации к платформам, вводу выводу и интерфейсам - забыл источник)
Есть редактор LyX. С ним проще)
Спасибо за рекомендацию, начну копить)))
Не согласен. Я спорт вообще не использую - уведомления, пульсометр, иногда шаги и этажи, иногда навигатор. Но то, что часы надо заряжать раз в 10 дней делает их для меня существенно ценней, чем более электро продвинутые. И потом - они прочные)
Аналогично. Пару раз при переразряде долго не вставали на зарядку, но через сутки втыканий-вытыканий показался треугольник и всё завелось снова.
Нет. Он вообще был достаточно скромен)