Category: происшествия

Category was added automatically. Read all entries about "происшествия".

Репликация таблицы БД с помощью очередей

Я тут, как обычно, подумываю, как бы заменить прямое обращение к БД из сервисов на хождение мессаг по очередям и посетила меня такая мысль: можно ли с помощью очереди, гарантирующей доставку "один раз или больше" реплицировать одну таблицу в БД, если у нее есть естественный ключ?

Мне что-то мерещится, что такая таблица является вариантом CRDT (если я воще правильно понимаю, что это такое) и можно гарантировать, что изменения с одной стороны, попавшие в очередь, дойдут до второй стороны и содержимое таблиц в конце-концов сойдется.

В случае гибели одной из БД и восстановления ее из резервной копии на какой-то момент времени, состояние рассинхронизируется и придется из второй БД принудительно передавать все данные, чтобы дозаполнить первую, или же хранить в БД полный лог изменений (заполняемый триггерами, например) и передавать изменения, начиная с момента логического времени, который видела умершая БД на момент своего резервного копирования.

Для случая нескольких таблиц со связями/FK уже так просто не получается - нужно чтобы таблицы, между которыми есть связи, реплицировались в правильном порядке - невозможно создать запись, в которой есть ссылки на другие, раньше их и удалить запись, на которую есть ссылки из других, до них невозможно.

Обычно я делаю распределенную транзакцию с двухфазной фиксацией с двумя БД и передаю данные лога транзакций и изменений между БД, пока оно работает как положено, за исключением того, что это прибивает гвоздями решение к протоколу Firebird, в котором эти распределенные транзакции предусмотрены и, например, убрать прямое обращение к БД и гонять данные по http(s) между сервисами не получается. Было бы интересно, опять же, рассмотреть вариант репликации данных между разными СУБД.

Пластиковый мусор

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

Скорее бы придумали какой-нибудь внятный способ это все рециклировать с хорошим КПД, запретили пластик нахрен и заодно ввели расстрелы за китайские игрушки и запланированное устаревание, потому что выбрасывание изготовленных людьми вещей, которые еще не превратились в труху и органическую слизь, вызывает у меня боль и страдания в мозгу.

Безумный день

Все утро провел на совещании по поводу интеграции с SAP R/3.
Вечером чинил утечку памяти в udf для Firebird.
В процессе диагностики этой же утечки опять сдуру открыл у клиента на 2012 винде стек 32-битного процесса в Process Explorer, тем самым навернув в красный экран смерти этот несчастный сервер, после чего пришлось призывать Chief Reboot Officer для восстановления работоспособности.

Жалею, что на работе не ввели наказания за косяки, сейчас можно было бы себя наказать показательно, чтобы запугать подчиненных.

PS: Нет, надо определенно завязывать с любыми попытками работать сегодня, а лучше и завтра тоже. Или делать что-нибудь принципиально не связанное ни с какими кишками софтов, сокетами, аллокаторами и стек-трейсами чужих процессов.

Собрался проверить проблему с Process Explorer на виртуалке, потом обратил внимание, что у меня на рабочем ноуте Thunderbird жрет 100% проца и 3 гига памяти, и полез в него Process Explorer посмотреть "что жрет". 8 винда, x64, тот же просмотр стека - экран смерти винды, точно такой же. Второй раз в день(!), слава богу не на продакшене уже.

http://forum.sysinternals.com/bugcheck-in-process-explorer_topic28949.html

fb trace

А вот интересно - почему разработчики формата трейс файлов для Firebird не посмотрели если не на log4j, то хотя бы на линуксовые плейн-текстовые логи?
Вот пример логов, последние 4 сообщения:
Collapse )
Обрабатывать это, например грепом - это смерть. Да и вообще оно выглядит одинаково слабо пригодным как для человекочитабельности так и для машинной обработки.

Назойливость, как ключевая бизнес-практика в России

Originally posted by alexdjachenko at Назойливость, как ключевая бизнес-практика в России
Подавляющее большинство людей и компаний, с которыми Вы столкнётесь в России, как двухглавые орлы: птицы гордые, но бессмысленные и без смачного пендаля будут только задумчиво кивать, переминаясь с ноги на ногу и гадить.

Ваш подчиненный принял задачу? Коллега обещал посмотреть документ к четвергу? Поставщик - привезти товар в среду?
И Вы им поверили?
Ха! Сюрприз отечественного бизнеса - ни к указанной дате, ни через неделю, ни через месяц ничего сделано не будет. Вообще ничего! Даже не начнут! Даже не вспомнят.

Единственный способ, сдвинуть дело с мертвой точки - задудонить "орлов" до такой степени, чтобы они даже во-сне беспокойно взрагивали и ворочились, потому что даже во-сне им должно сниться, как Вы им звоните и напоминаете.

Отбросьте в сторону свои сомнения и стеснительность. Вы просто делаете свою работу. И раздражаться этому могут только ленивые бездельники, которые не собираются исполнять данные обещания. Остальные все поймут и будут Вас уважать, как человека пунктуального и делового.

Встречи
Назначенная встреча не состоится, если сразу после договорённости о ней, вы не отправите всем участникам письмо со временем и местом. Еще одно - в понедельник утром той недели, на который запланирована встреча. В конце предыдущего дня необходимо обзвонить всех участников встречи и поинтересоваться, в силе ли договоренность. Еще раз - за 3 часа до встречи. Ну и за 5 минут до начала встречи необходимо позвонить всем, кого еще нет в условленном месте.

Доставки
Если у вас приняли заказ, это не значит, что его собираются доставить. И уж совсем не значит, что его собираются доставить в назначенный срок. Чтобы увеличить вероятность этого, необходимо напомнить звонком трижды: один раз - когда формируются маршруты на день доставки. Один раз - в самом начале дня доставки, когда еще не поздно вписать в маршрутный лист ваш адрес, который забыли вписать вчера, ну и еще раз звоните в конце интервала времени, когда вам обещали доставку и никто не приехал.

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

Партнеры и клиенты
Я Вам сочувствую, правда, мне Вас искренне жаль, очень очень. Потому что если у вас нет под рукой вентиля, перекрывающего нужному человеку кислород, или кнопки активации штырей в сиденье его стула - ситуация почти безнадёжна.
Ругаться в этом случае никак нельзя, звоните на пределе вежливости. Описывайте, как вам плохо от того, что вы еще не получили никакого ответа, как Вас ругает ваш руководитель/клиенты/поставщики, какие кары Вам грозят. Вашему контрагенту это всё абсолютно неинтересно, поэтому рассказывайте как можно дольше и подробнее.
Всеми правдами или неправдами просите назвать дату. Если дату не назвали - звоните не реже раза в день. Старайтесь беседовать как можно дольше, спрашивайте, чем можете помочь, живопишите новости совместного проекта. Контрагенту должно быть быстрее и проще один раз выполнить требуемое, чем ежедневно с Вами беседовать. Главное - не бойтесь надоесть, если ТАКОЙ контрагент предпочтет отказаться от дальнейшего сотрудничества - он этим окажет Вам услугу.


А штыри в стуле были бы решением!

scala spray slick restful ад заборы коровники коворкинги хипстеры

В целях недопущения упрощения жизни, а так же чтобы псить, при необходимости, со знанием дела, осиливаю скалу.
Причем начал практически с конца - клепаю RESTful сервис на основе spray с всякими json-маршалингами внутри через имплициты и прочую адову содомию.
При достаточном количестве type-level магии оно выглядит, конечно, так же просто, как какое-нибудь руби, или как лиспы без скобок и с инфиксной записью, но внутренняя сложность, по-моему, зашкаливает. "Импортируй себе немножечко имплиситов и получи на халяву сериализаторы в json для всего", "Оберни маршруты в директивы логгера" и прочее такое.

Сборку завел, сначала через sbt (простой способ), потом импортировал в IDEA (условно простой) и потом стырил у jdevelop конфигурацию для мавена (нормальный способ). Воедино надо это как-то свести, чтобы не редактировать при добавлении новых зависимостей все вручную. Плюс еще импорт sbt в IDEA выглядит как ад и смерть.

Завести то я это чюдо заведу, но вот что с ним дальше делать, не совсем понятно. На данный момент картина выглядит так: Clojure проще, но скобки и стектрейсы компилятора отпугнут новых пользователей, Scala дико сложнее, но поначалу она выглядит как "почти жаба", обработка ошибок более читабельна и есть шансы, что в эту западню попадутся и желающие новеньких языков и любители сойти с ума на почве вычислений на типах.

Зачем я это помню?

http://news.tut.by/hotline/311346.html
Задачка про террориста - адаптирована из очень старой задачки. Вот тащемта оригинал: http://thejam.ru/puzzle/inspektor-varnike.html
А помню я это из очень старой книжки советских времен с огромным количеством логических, математических и прикладных задачек, под названием "Твое свободное время": http://www.smekalka.pp.ru/download/bolhovitinov_01.html
Книжка, кстати, весьма забавная, после нее тесты на IQ проходить очень легко.

Почему меня не возьмут в линукс-рабство?

* Сижу в винде, проги пишу по ssh на виртуалке с линуксом
* Забываю сочетания кнопок в vim
* Постоянно промахиваюсь по кнопкам. В том плане, что например :q я один раз из 5 набираю так, что попадаю в список предыщущих команд. Сознательно я так это сделать и не смог. Для редакторов с состояниями и кучей команд на кнопках - это смерть.
* Изредка забываюсь и открываю редактирумый файл в фаре из винды по самбе. После сохранения из него: в файле напрочь убиваются табы, превращаясь в 4 пробела и меняются права доступа на файл (+x появляется)
* Не могу запомнить правильный стиль написания С кода - в основном, "где ставить пробелы".
* Не могу соблюсти лимит на 80 символов в строке. У меня на экране терминал шириной в 160 символов.
* Изобретаю велосипеды (у меня уже есть собственные строки и поверх-них - диалог с девайсом в continuation-passing style, причем уже планирую к этому диалогу прикрутить контекст, со стеком и обработкой исключений).
* Не знаю, как правильно делать вывод в лог ошибок и сообщений, поэтому периодически смешиваю собственные макросы типа ERROR(msg)/WARNING(msg) и тупой fprintf(stderr,..).

Проблема в следующем: в .NET и жабе я использую log4net/log4j, в дельфи - собственный примерно аналогичный логгер. При этом куда попадает результат лога и виден ли он - определяется конфигом логгера, в бинарниках ничего не меняется. Т.е. одна и та же либа у меня может писать лог в консоль, будучи использованной в приложении командной строки, или в файлы, будучи использованной внутри сервиса. Как такое _правильно_ сделать в С, я пока не соображу. Глобальный логгер какой-то тоже мудрить?

* Емакс я (пока) не осилил. Причина - см. выше, кривые руки, не могу более двух-трех кнопок запомнить и нажать без проблем.

И да, к вопросу о кривых руках: юзабилити вима, емакса, joe и прочего - кромешный ебаный ад.
Что будет происходить при следующем нажатии клавиши - на экране не видно НИКАК. В самом лучшем случае - внизу экрана (очень далеко от текущего положения курсора) одна строчка "VISUAL/INSERT/REPLACE" в vim или дикая последовательность нажатых кнопок в emacs, ничем не объясненная.

Или например vim, который при ошибке :make открывает файл с ошибкой не в том табе, где он был уже ранее мной открыт, а в текущем табе поверх уже открытого файла. При этом количество и списки открытых буферов как бы без явных действий не увидишь.

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

* Вместо следования священным юниксовым обычаям имею наглость их критиковать.

PS: Граждане юниксоиды, что вам непонятно в словах "невидимый контекст" или вам непонятно, какое это отношение имеет к юзабилити?

Выборы в америке

В честь свежеизбранного президента соединенных штатов группа "Коррозия Металла" исполняет песню "Ниггер":

Мертвый лушче чем живой
Черный нигер, голубой,
Ты пришел из Занзибара
Или черт с Мадагаскара.

ПРИПЕВ:
Кто ты? Кто ты?
Обезьяна, нигер, черт!

Эй, нигер, нигер
Да где ты был?
Эй, нигер, нигер
Ты гамадрил

Лучше мертвый, чем живой
Нигер жареный и злой
На костре горит в подвале,
Плачут девки в Занзибаре.