BurdoBordo как генерализация FizzBuzz

Многим известно  тестовое задание FizzBuzz. Возникла (а почему бы и нет?) идея решить более общую задачу. Будут заданы два делителя и две соответствующих им строки. Результатом будет вывод исходного числа или строки в зависимости от делимости числа. Наивный, понятный, хорошо поддерживаемый первый вариант:

def BurdoBordo(x,BURDO="BURDO",burdo=3,BORDO="BORDO",bordo=5):
    if x%burdo==0 and x%bordo==0:
        return BURDO+BORDO
    elif x%burdo==0:
        return BURDO
    elif x%bordo==0:
        return BORDO
    else:
        return str(x)
FizzBuzz=lambda x: BurdoBordo(x,BURDO="Fizz",burdo=3,BORDO="Buzz",bordo=5)
for x in xrange(1,101):
    print FizzBuzz(x)

Следующий вариант, в котором более активно используются особенности python.

def BurdoBordo(x,BURDO="BURDO",burdo=3,BORDO="BORDO",bordo=5):
    return ((BURDO,)+('',)*burdo)[x%burdo]+((BORDO,)+('',)*bordo)[x%bordo] or str(x)

FizzBuzz=lambda x: BurdoBordo(x,BURDO="Fizz",burdo=3,BORDO="Buzz",bordo=5)
for x in xrange(1,101):
    print FizzBuzz(x)

И, наконец, последний вариант, с индексами и short-circuit evaluation.

def BurdoBordo(x,BURDO="BURDO",burdo=3,BORDO="BORDO",bordo=5):
    return (BURDO+BORDO)[x%burdo and len(BURDO):x%bordo and len(BURDO) or len(BURDO+BORDO)] or str(x)

FizzBuzz=lambda x: BurdoBordo(x,BURDO="Fizz",burdo=3,BORDO="Buzz",bordo=5)
for x in xrange(1,101):
    print FizzBuzz(x)

о необходимости использовать уместные термины

Я уже писал, что термины load sharing и load balancing зачастую используются не вполне корректно. Не так давно наблюдал, к чему это приводит. У человека, исключительно из-за использования термина 'балансировка', сформировалось неправильное представление о том, что он получит. Когда схема была реализована, расхождение между ожидаемым и реальностью породило закономерные вопросы. Всего этого можно было бы легко избежать, если бы автор статьи, которой вышеупомянутый человек руководствовался при настройке, ответственно подходил к выбору терминов.

'Среда передачи не прошла проверку' на ethernet-интерфейсе

Недавно позвонил товарищ, пригласил поучаствовать в траблшутинге сетевых проблем windows xp по телефону. Я, конечно, легко обойдусь без подобных развлечений, но ведь никто, кроме нас. Симптом - "нет интернета", порт на маршрутизаторе не загорается. После обычных махинаций (смена кабеля и прочая), обратил внимание на вывод ipconfig (продекламированный мне по телефону), а именно: в статусе ethernet-интерфейса было указано 'Среда передачи не прошла проверку подлинности'. Ключевые слова 'среда передачи' и 'проверка' натолкнули меня, не так давно сдавшего-таки 642-813 SWITCH,  на мысль, что в деле замешан 802.1x. Так и вышло. Единственное, что заставило потратить дополнительных 10 минут - 802.1x отключался не вместе с IPv4/v6, службой принтеров, LLDP и прочая, а на отдельной вкладке.

Из этого непримечательного, в общем-то, случая я сделал выводы:

1) Надо бы углубить знания настройки сети в ОС Windows. Думаю, команда netsh при правильном подходе помогла бы сократить время диагностики проблемы.

2) Баребоны (это был баребон, маленький такой компьютер) могут идти в комплекте с довольно специфическими колокольчиками и свистелками (вроде включенного 802.1x на 'медном' интерфейсе. А еще там была программа от Juniper для постройки тоннеля неизвестно куда) 

3) Системный подход часто помогает решить проблему даже при отсутствии релевантного опыта (ни разу не настраивал 802.1x в Windows, например)

клиенты-серверы

Читая книгу Робачевского-Немнюгина-Стесик про юниксы, поймал себя на мысли. Раньше, когда речь заходила о клиент-серверной архитектуре, я сразу представлял один мощный компьютер или их ферму (сервер/ы) и множество других компьютеров попроще, клиентов. Причем связь всегда подразумевалась через сетевые интерфейсы (чтоугодно-over-IP). В этой книге же представлена историческая перспектива  средств взаимодействия процессов, и соответственно сервер определяется как процесс, предоставляющий некие сервисы (вычисляющий, предоставляющий данные по запросу извне). Такое определение или, скорее, описание, кажется мне более общим и корректным.

Verification of your TeamViewer version failed

English version here.
Недавно попросили разобраться с утилитой Teamviewer, внезапно начавшей вываливаться с указанной в заголовке ошибкой. В качестве операционной системы выступала Windows XP. Как выяснилось, бинарник подписан ЭЦП, соответственно для прохождения проверки нужны :
1) рабочая крипто-инфраструктура.
2) загруженные корневые сертификаты.

Пункт 1) описан здесь http://support.microsoft.com/kb/958045/en-us, там же предложено решение (выполнить в консоли):

regsvr32 Softpub.dll /s
regsvr32 Wintrust.dll /s
regsvr32 Initpki.dll /s
regsvr32 Mssip32.dll /s

Пункт 2) заключается в установке корневых сертификатов отсюда: http://www.verisign.com/support/roots.zip (почитать: https://www.symantec.com/page.jsp?id=roots)

К сожалению, у меня не хватило компетентности провести надлежащее исследование проблемы, но по совершению вышеперечисленных действий утилита Teamviewer заработала штатно. Надеюсь, этот пост будет полезен не только мне.

о документировании сети

Задумался недавно о различных вариантах ведения документации на сеть, точнее о журнале адресации и различных (L3,L3 и т.д.) схемах сети.

Есть уже ощущение, что в 21 веке как-то грустно вносить руками префикс в excel-таблицу или дорисовывать новый линк в Visio, отдельно на L2-карте, отдельно на L3-карте. С другой стороны, многие автоматизированные решения предполагают использование CLI рабочего оборудования роботом с целью выяснения топологии. В таком варианте вполне вероятна ситуация, когда в результате ошибки робот начнет генерировать тяжелые для процессора запросы с высокой частотой, что приведет к высокой утилизации процессора и последующим неприятным событиям. Конечно, в некоторых устройствах некторых вендоров management plane и control plane независимы, но в общем случае не хотелось бы иметь такие риски. С другой стороны, в лучших домах Европы уже, как правило, реализовано архивирование и отслеживание версий конфигураций, так почему бы просто не парсить конфиги? Конечно, сначала необходимо задать базовую структуру сети (роли устройств и их связи), но затем добавление нового L3-линка, например, элементарно отследить по изменению конфигов. В случае включенных L2-discovery протоколов (CDP, LLDP) доступ к их данных можно [попытаться] получить через SNMP. В идеале из полученных данных можно собрать граф и визуализировать его стильным-молодежным js-фреймворком. Такие мысли.

TL;DR: пускать кого попало в cli неок, безопаснее парсить конфиги.

уна палабра нуэва

Недавно вычитал новое слово - "сормировать", в смысле направлять трафик на оборудование СОРМ-2. Занятно.