crower

Раз четвёрый уже отключают.

PS. Хоббийная деформация? ;)

С компа не вижу никакой рекламы, а с планшета - прёт всякая дрянь. Забавно, что через комповый веб-интерфейс в настройках нашёл возможности отключать тематическую рекламу, а на планшете, в андроидовом приложении ничего такого нет. Хотя ожидал, что экаунт-то и там, и там используется один и тот же и настройки должны быть общими. Получается - хрен. Более того, в андроидном приложении постоянно вываливаются в ленту старые твиты. Когда следил за посадкой Фил (#Philae, #CometLanding), очень раздражало появление всякой фигни, которая нафиг была не нужна.

«Хорнер: Участие Феттеля в квалификации будет ограничено». Всё понимаю, но как бы классно было, если бы на зло всем Феттель взял бы поул. ;)

В результате перевода времени случилось два сюрприза.

1. На одном компе (древний трастикс) время таки не перешло. Стал выяснять - обнаружил, что на нём /etc/localtime был не прилинкован, а скопирован. В результате новая информация в свежеоткомпилированном файле в /usr/share/zoneinfo не вошла в актуальный режим. Это я забегавшись между серваками, на которых всё чин-по-чину линками сделано, не обратил на это внимание. А с прошлой правки времени не вспомнил.


2. Крутится на одном проприетарном серваке древний скрипт на php. Занимается утрамбовкой станционных данных. В исходном виде 200-350 мег, жмётся на порядок. Места на серваке не много, так что такое решение освобождает очень ценное пространство. Можно раз в год удалять устаревшую инфу, а не раз в месяц. Так вот на серваке время перевелось правильно. А внутри скрипта, который находится в бесконечном цикле время бежало по старой схеме. Стало быть и часы, и правила перевода времени у php-ового скрипта внутри задачи свои.

Воодушевился прочитанным недавно "Перестаньте называть себя программистом". Вспомнил упавшее в почтовый ящик оповещение от корпоративного спамогенератора про то, что отныне заявки на внесение изменений в корпоратиную ЕСЭД будут рассматриваться придирчиво и не все будут выполнятся. Понятно что эффект от изменения может быть мизерным, а затраты - существенными.

А тут в очередной раз падает очередной спам от него мол тогда-то в такое-то время не будет работать (час) система самообслуживания. Полезная, конечно, штука.... Только будет это ночью, когда бодрствовать будут только единицы в ночные смены. А оповещение разослано всем.
Вопрос: а кто-нибудь посчитал, сколько затрачено усилий получается скрытых издержек за счёт того, что десятки тысяч (а может пара сотен тысяч?) работников должны отвлечься на этот спам чтобы хотя бы просто проверить что это за письмо пришло?
Такая технология сильно мне напоминает трупотурбовижин. Где он теперь. В нем тоже эвенты обходили всех подряд, чтобы обнаружить кому они нужны.
Думаете это только в централизованной рассылке такая хрень используется. Фигушки. У нас зачастую начальники вместо того чтобы выдать распоряжение по назначению, рассылают его всем своим подчинённым: пусть разбираются кому это надо. И помог этому прогресс: электронное письмо легче разослать всем, чем думать. Сделать такую-же пачку хардкопи сложнее и потому легче было подумать...

Так что любая оптимизация способствует том, что высвободившиеся ресурсы пожрёт бюрократия.

И что? Что Даня сможет выжать их машины, если она не едет? Что смог Феттель? А ведь он четырёхкратный чемпион. В принципе, да: он может быть и слабее, например, тех-же Льюса и Нандо, но на отличной машине делал всех. Что, может быть, подтвердил Риккьярдо, поехав лучше его. Но я бы так категоричен не был. Есть много нюансов. Но и Даниэль не смог серьёзно потягаться с Мерседесами. Хотя, конечно, три первых места - это тебе не хухры-мухры. Ну, да, Лотусы должны подтянуть двигатели. Хм. Если РБ не сменят их. А если сменят, то придётся адаптировать и, наверно, весьма серьёзно переделывать многое. Но самое главное - сможет ли РБ держать такую же высокую планку в отсутствии Ньюи? Вот чуть ли не самый главный вопрос. На отличной машине посредственный пилот вполне может сделать очень многое. А вот на посредственной машине даже отличный пилот вряд ли что сможет сделать. Достаточно посмотреть на Феррари. И, кстати, зря, на мой взгляд, они отказываются от услуг Алонсо. Впрочем, может они не в состоянии сделать машину ему, но смогут сделать для его сменщика? Но ведь и Кими не может ничего сделать? Выходит не в пилоте дело.

Исходя из вышеизложенного на следующий год не ожидаю чуда. Хотя, конечно, на подиумы рассчитываю. Может не с первых гонок - надо всё-таки теперь к новой машине приловчиться. Если её в отсутствие Ньюи не испортят. Но в первой-то пятёрке, надеюсь, должно быть среденестатистическое место.

Увы. Не стал "каркать", но каркай-не-каркай, а если машина слаба, то подниматься выше "своего места" Квяту (и Верню) позволяют только разнообразные случайности. Когда ещё Петров в эфире высказался за четвёртое Данино место, подумал: "Да, было бы не плохо, но он скорее высказал желаемое". Трасса оказалась слишком быстрой и не сильно наказывала за ошибки. В результате всё утрамбовалось "как положено" и даже Жан-Эрик оказался непосредственно впереди Дани. Единственно что ласкало глаз - как на последних кругах Даня нагонял Льюиса. Да, на свежей резине уже изношенную, но всё-таки это был Мерседес! К сожалению, времени не хватило, а было бы здорово, если бы ему удалось вернуться в круг. Вроде бы ерунда, но обогнать Хэмилтона - это был бы приятный символ.

В продолжение реабилитации кактуса попытался всё-таки подсунуть правильные счётчики.

Корковые по дескриптору, как и говорил, прицепились без проблем.

Процовый и мамковый однажды пытался по дексриптору опрашивать, но что-то не получилось. Вроде бы под руку попадались последние с одноимёнными дескрипторами.

Попробовал ещё раз, при этом внимательно разглядывая логи и экпериментально пытаясь понять где можно подкрутить чего.

И "о чудо!" - всё заработало.

Результат.

1. Так и не уловил откуда берутся дескрипторы. Перешерстил liblmsensors, snmp - пусто. Нигде не нашёл "CPU Temperature". Может в ядре? ;)
2. Если задать в кактусе Data Sources по имени, то он сам ресолвит номер сенсора и опрашивает счётчики по полученному номеру.
3. Поскольку в этот раз он по дескриптору выбрал первый (и правильный) счётчик, то лезть в исходники не понадобилось. Может потом как-нибудь, если заглючит.

Итого, пара вопросов остались не раскрыты. Но сейчас времени нет - ковыряю обновление реестра по приходу нового реестра. Давно была мысль такую штуку построить, когда нужно было вести актуальный реестр, закрывая устаревшие объекты, добавляя новые и апдейтя обновлённые. А тут попалась под руку национальный план нумерации и принялся кодировать эту задачу.
Наивняк. :)
Не то что бы это была супер сложная задача. Простая, в общем-то и нетрудная. Но требует очень высокой сосредоточенности при построении алгоритма. Одно дело обновлять объекты, которые суть точечные, а совсем другое - диапазоны, т.е. линейные объекты, которые нужно проверять на пересечения.
А правила при пересечении могут быть тоже разные. Может считаться что новый источник приоритетнее и просто закрывать перекрыващиеся. Но выцепить их не очень просто. Много критериев, которые нужно все держать в голове и поэтому легко что-нибудь упустить или запутаться. Сделал сначала пару индексируемых массивов, по которым и гулял. Всё бы хорошо, но где-то промахнулся и забыл сменить принцип закрытия (по уиду заменил на индекс) и в результате стал оживлять сплайснутые элементы массива. Пока искал где я из оживляю, и думать как избежать оного, пришла в голову мысль, а нахрена я использую индексный подход? Тут же в чистом виде получается стек. Собственно сам стек - это массив, который сортирую (из файла) или получаю (из базы) сразу сортированным. Но дальше индекс на элементы нафиг не нужет.
Сказано - сделано.
В итоге алгоритм существенно упростился, стал более наглядным и работает более эффективно. И кстати, без глюков.
На счёт того, что я учёл все состояния и правильно обрабатываю их - не уверен. В реальных данных этого может не оказаться. Поэтому придётся генерировать тестовые наборы и на них проверять корректность алгоритма.
В итоге прога работает довольно шустро, генерит офигительный sql-скрипт и скармливает в базу. И вот тут-то получаются сущие тормоза. Исходный реестр содержит чертверть миллиона записей, трамбующий алгоритм склеивает смежные однотипные записи ужимая реесть процентов на десяток, а трамбущий скрипт получается на 29 тысяч апдейтов (закрывающих обновлённые записи), и на 8.3 тысячи из длинног инсерта. Дольше всего выполняются апдейты. Их бы пооптимизировать надо. Чтобы сразу пачками... О, есть мысль... Пошёл делать...

В свете прочитанной уже части Кунина положительный отбор является второстепенным фактором, если не сказать, что он практически никакой роли не играет... Хе-хе. :) Делаем выводы.

Впрочем, весьма усложнившаяся и навороченная теория обрисовывает некоторые новые нюансы. Многие вещи являются следствием особенностей "биохимической вселенной". У киберморфов это может как не играть никакой роли, так и не позволять двигаться эволюции, ибо необходимых механизмов, которые присутствуют в молекулярной биологии, но не воспринимаются неотъемлемой частью, в киберморфовой вселенной отсутствуют.