crower: (Crower)
На днях познакомили меня с портфолио одной фирмы. Сайты делает. И повергло меня созерцание этого «треша и угара» в уныние. Не, сайты, конечно, не плохие. Красивые даже. Но, блин, как это построено. Одна длинная страница на 4—8 экранов, куча ява-скриптов и картинок. Интерактив позволяет между этими экранами ходить, картинкам прикольно/глюкаво меняться… По сравнению с этим новогодние снежинки — это маленькая шалость, на которую обращать внимание просто не прилично.
Погрузившись в медитация, подумал я что началось это, ведь давно. И самый яркий пример сейчас — ОС в ОС. И речь даже не о виртуальных машинах, хотя и о них тоже.
Вот смотрите: Андроид в линуксе (1), ОС в браузере (2). Что получаем? Уже три вложения. Как тут не вспомнить сказку про Кощея?
crower: (Crower)
Сегодня довёл до ума новый вид бота, заметно отличающегося от предыдущих.
Забирает задания с MW-сервере, которые размещены на определённой странице. Страница обычная, но охватывается тегами source, так что выдёргивать его довольно удобно. Ну и секции тоже имеют значение - где, что и когда делается. Особая фишка в том, что содержимое его — фактический скрипт от winfiol-а. Бот фиоловые команды выполнять не умеет, значит и скрипты с фиолово-зависимыми командами ему совать нельзя. Просто скипает их.
Команды — в станцию, ответы — как обычно — в логи.
Ещё одна фишка — отчёты (с ответами) — в журнал, тоже на MW-сервере.
На мою голову сдох pywikipedia, но нет худа без добра — стал искать новые возможности и обнаружил MediaWiki::Bot.
Кстати, отсутствуют некоторые недостатки предыдущего. Ну и за компанию перестал RELCMDHDF грузить в MW. И правда нафига оно, если я их уже в специальную базу гружу. Поиск не мгновенный, но в любом случае быстрее чем в MW: за 12 лет под 5 тысяч файлов на 10 миллионов команд и с пол-гига объёмом. Правда три квартала выпали из-за одного краша. Но тут уж ничего не поделать. :(
Готовых скриптов у MediaWiki::Bot как у pywikipedia нет, но зато получается нативнее. Набросал тройку сабрутин, завернул в либу и теперь легко можно любого бота научить работать с викой. Одна из сабрутин даже категории спихивает в конец, сортирует и избавляет от дублирования. Красота-а-а! :)

Хочется придумать какое-нибудь новое название, типа smart-bot. БОльшего ума у него, конечно-же, нет, но «человеко-подобие» создаёт ощущение именно смартовости. :)
crower: (Crower)
Хочешь сделать хорошо — делай всё сам. ;)
Читать суть задачи... )
crower: (Crower)
Что лучше? Я тоже думал, что REPLACE проще, пока не понадобилось задействовать тригер.
Read more... )
crower: (Crower)
Подарил себе код. Почти законченный. Допилил — получил удивительное чувство удовольствия.
Read more... )
crower: (Crower)
…между программированием и эволюцией. :)
Read more... )
crower: (Crower)
Продолжаем препарирование любимой компании?

Read more... )

Единственно что мне непонятно, это "как?" так можно писать софт. Даже не разбираясь в технологических процессах, чисто интуитивно должна возникнуть мысль что так делать нельзя потому что:
1. Нарядов можеть быть дохрена и человек такое количество обработать просто физически не сможет.
2. Ручное выполнение чревато ошибками. Ошибка в роботе может быть, но живёт ровно до устранения. Ошибка человека (вероятность на несколько порядков выше) может повторяться и проявляться где угодно, когда угодно и гарантированно "устранить" их источник невозможно в отличие от ПО.
3. Эффективность выполнения нарядов роботом на несколько порядков выше. О какой производительности труда можно в такой ситуации говорить? Какие инвестиции? Какой ВВП? С таким подходом будет только хуже.
crower: (Crower)
Сидел давеча за кодом монитора станционных сообщений. Ничего особо сложного, но код отяжелён стремлением сделать его универсальным. Два режима, несколько параметров в разном сочетании. На основе этих данных формируется sql-запрос, запрашиваются данные и полученные отображаются. Засада в том, что с какого-то момента стал нещадно тормозить. Если дать sql-запрос компактненько, с указание всех интересующих критериев, то суточная сводка выдаётcя менее чем за секунду. Добавив "вкусную" таблицу получаю не более полутора секунд. В скрипте-же, с его универсально построенным запросом получается, блин, пол-минуты... Вот за что такое наказание? ;)

Вспомнил старую систему. Много лет назад (лет, наверно, 15) был у нас слабенький (по теперешним меркам) сервак на шапке. Крутился там интербейз. В базах я тогда практически не шарил. И в вебе тоже. В общем, только-только разбирался как это хозяйство работает. И в частности строил интерфейс. В базу загружались данные станционной статистики. Приятель, для того чтобы отображать интербейзовские данные на веб, наваял програмку-гейт, которой скармливались html-заготовки, в которых специальный тег заменялся на результат запроса. Эдакий cgi/ssi в одном лице. Это позже уже были и php, и perl, а тогда это всё было в новинку. В общем то, что сейчас сделано на одной странце одним скриптом (толстым, конечно), тогда выглядело как несколько каталогов с парой сотней html-шаблонов и приблизительно столько же sql-шаблонов. Блин! И ведь это работало! Да ещё как! А интерактив? Понятно что если что-то в базе существенно менялось, то приходилось править во многих шаблонах. Но зато это как-то просто получалось. А сейчас гляжу и начинает доходить, что вместо прокариотно-подобного кода ранее получил теперь эукариотно-подобный. Например, с кучей альтернативного сплайсинга. Поэтому приходится снимать показания в промежуточных точках и смотреть что за запрос получается. Но беда ещё в том, что режимы эти могут оказаться несовместимыми... Не вернуться ли к старой методике? ;)
crower: (Crower)
В продолжение реабилитации кактуса попытался всё-таки подсунуть правильные счётчики.

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

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

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

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

Результат.

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

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

Зачем всё это мне? Затем что Киберморф я не забросил. Проект находится на стадии очередного обдумывания направления дальнейшего развития. А для этого тема продолжает исследоваться. Изучается вопрос: чем отличается среда биохимии и генетики от среды программной. Какими дополнительными условиями требуется обеспечит программную среду, чтобы эволюция киберморфов не барахталась, застряв в топологических ямах, а стала двигаться, хоть в каком-то направлении.

Profile

crower: (Default)
crower

July 2017

S M T W T F S
      1
23 45678
910111213 1415
161718 19202122
23242526272829
3031     

Syndicate

RSS Atom

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 22nd, 2017 12:45 pm
Powered by Dreamwidth Studios