Category: it

Category was added automatically. Read all entries about "it".

Проект Haven: система управления Docker



Шо это было?: Полагаю, не секрет что кроме хобби (которому посвящен сей блог), у меня есть еще и работа 8) Вот на это самой работе, я участвую в создании различного программного обеспечения. Сегодня как раз и пойдет речь об одном таком изделии.
Для меня оно выделяется тем, что это первый продукт который публично доступен. Да, нужен сей инструмент лишь узкому кругу специалистов: некоторым разработчикам, да системным администраторам (не буду писать про DevOps и т.п.).

Проект Haven построен над стеком технологий Docker. Предназначен как для управления кластерами (основанными на swarm) так и отдельными нодами. Имеет веб-интерфейс.
Collapse )

Достались тут мне занятные штуки, зажимы от Урал-альп: 10.21 Мышка и 10.20 Мини

зажим Урал-альп 10.21 Мышка и 10.20 Мини
Скажу сразу, к альпинизму, скалолазанию и всем подобным дисциплинам я имею крайне опосоредованное отношение. Тем не менее у меня есть кой какое снаряжение, а недавно оно пополнилось двумя изделиями от фирмы Урал-Альп (иногда они также упоминаются как AlvoTitanium) и так как в интернете даже фотографий сих предметов почти нет, то я решил заполнить сей пробел и непного описать сии штуки.

Collapse )

Используете Dependency Injection? Тогда у вас проблемы.

Далее будет описание ключевых проблем возникающих от использования одной из техник Inversion of Control (IoC): Dependency Injection (DI). Проблемы как проистекают как из самой идеи DI, так и из применения оной на языке java.
Collapse )

Мониторинг проблем веб-приложений: зависшие запросы.

article_01-sequence

С чего все началось

У нас было legacy веб-приложение (dojo, tomcat, oracle db, написанное как молитва ЛММ: бизнес логика была в js, jsp, servlet, неких объектах прибитых к субд и, что самое приятное, в sql процедурах) которое более менее стабильно работало и приносило деньги, но в силу архитектуры его старались лишний раз не трогать. В один сумрачный понедельник оно зависло прямо на сервере у клиентов - кончились коннекты к субд, в логах причина не засветилась, приложение не трогали гдето полгода, так что ошибка очень нехорошая. С того сумрачного дня сумрачность только сгустилась - приложение стало зависать в случайное время, то ночью на следующий день после рестарта, то работает две недели.

Collapse )

Проектирование настольных приложений.

Многие начинают разработку с "открыл дизайнер форм, кинул кнопку, кликнул на ней - начал писать код который загружает дынные" - этот подход многие заучили как единственно верный еще в с таких платформ как Borland Delphi (C++ Builder) и последующих приемников на C# и Java.
После чтения всяческих умных статей про паттерны и необходимость тестирования новички открывают свой код и думают: это все хорошо, а как это применить к нашим кнопочкам?
Один подход к организации внутренней архитектуры который решит эту задачу я сейчас и поведаю в данной статье.
Collapse )

suicide.txt - Файл который может изменить рунет.

Гдето года два назад или больше рОССИЙСКИХ пользователей интернета начали защищать от всяческой плохой информации.

В этом году прикрыли сайты оппозиции.

И вот эпическая вещь, закрытие одного из популярнейших среди программистов сайтов GitHub. За то что на нем расположили файл suicide.txt (думаю нетрудно догадатся о содержимом).

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

Ждем следуюущего этапа, блокировку google, у них также есть этот файл:
https://www.google.ru/search?q=cache:https://github.com/Anakros/objidlib/blob/master/suicide.txt

Немного о том где хранить sql запросы в программах.

Многие начинающие разработчики при проектировании очередного ПО задумываются, куда разместить такой объект как текст SQL запроса. Очевидное решение: в исходном коде программы (а то и в виде статических полей какогонить объекта), видится наиболее простым, особенно в купе с поддержкой со стороны некоторых IDE, множество недостатков такого подхода даже обсуждать не стоит, ибо там всего одно достоинство - макароны SQL кода перемешан с макаронами кода программы, блюда на любителя. Другой более продуманный подход: хранить в файлах, порождает вопрос "в каких?", на что просвещенный интернет заявляет "в XML". Казалось бы что ту можно обсуждать?
Но, тем не мене, предлагаю хранить запросы там где им самое место... в SQL файлах:Collapse )

Утилита анализа логов сервера Apache Tomcat.

Утилита написана на питоне (которого я не знаю, так что анекдоты в коде вполне возможны).

Задача утилитиы найти в лог-файле apache-tomcat все записи с уровнем SEVERE (как правило стектрейсы исключений / ошибок), подсчитать кол-во одинаковых и вывести отчетец где будет количество повторений записи, даты когда она возникала, и собственно ее текст. Т.к. утилитами типа grep задача не решилась, а изучать awk лень, ибо уж если писать программы то зачем это делать так затейливо на awk? НМВ тут уж улче использовать perl или python, тем более что последний мне чуть лучше знаком нежели первый.

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

В скрипте есть справка:

usage: log-analyzer.py [-h] [-t TIME_PATTERN] [-o OUT_FILE] log [log ...]
Java log analyzer
positional arguments:
log log files for analyzing
optional arguments:
-h, --help show this help message and exit
-t TIME_PATTERN time regular expression patten (for example like "([\d.]+ [\d:]+)|([\w]+ \d+, \d{4} [\d:]+ [A|P]M)" )
-o OUT_FILE analyze report file (XML)

Да, замечу что такой затейливый паттерн для времени записи ("([\d.]+ [\d:]+)|([\w]+ \d+, \d{4} [\d:]+ [A|P]M)") используется по умолчанию для лога сервера который коряво запускается то с LANG=C (при загрузке сервера), то с LANG=ru_RU.utf-8 (от пользователя), кстати юникод в логах поддерживается, а вот cp1251 - нет.

Скрипт работает по принципу: находим строку начинающуюся с SEVERE, предыдущую строку используем как дату, а все следующие до строки начинающейся с даты — как текст ошибки. Нетрудно догадаться, что таким образом можно янализировать не только логи томката, но и любого другого приложения, в том числе и не на java.

Код скрипта http://pastebin.com/6xMG8p0s, не заводить же аккаунт на гитхабе ради этого?


Почему python отстой.

Не, языки с динамической типизацией гуд, но иногда они позволяют выстрелить себе в ногу через висок.
На днях ковырял pymag для генерации карт, столкнулся с замечательной ошибкой: в методе проводится побитовый XOR чисел с плавающей точкой, есесно что интерпретатор питона охренел от такого и выругался нецензурно. Оказалось все феерично донизя:
class CellElement
  def __init__(self, coords): 
      self._coords = coords ## Discrete coordinates
  @property
  def coords(self):
      return self._coords

и есено везде наивно полагается что координаты целочисленные, но... в одном месте в дочернем классе, туда попадет float, и все работает отлично до тех пор пока мы не станем их XOR-ить, епт, еслиб это была java то такая бы проблема в принципе не возникла бы!
Кроме того в питоне, типы имеют "вирусную" особенность (вообще это какбы нормально, но имеет неприятный побочный эффект именно в языках с динамической типизацией), если вы сложите 1.0 + 1 то получите число с плавающей точкой, так как никто не проверяет результат, то достаточно в одном месте появится float, как везде начнут расползаться float-ы и вся программа начнет скрипеть и кидаться исключениями, причем найти откуда полезла зараза, оченно трудно.

linux: AMD E-350 (zacate) + cpuinfo = fail

Не так давно приобрел я себе таки нетбук, asus 1215b с новым и чудным процессором amd e-350, и озаботился втыканием на него линукса.

И все хорошо, и wifi поднялся и bluetooth завелся, и даже кнопка отключения вайфая заработала (правда перед этим пришлось зарегить на ЛОРе очередной акк., но там нихрена не помогли, мабуть не торт он уже) - пришлось ставить ядро из unstable. Но вот фокус с постоянно высокой частотой проца мне не понравился...
Решение простое: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627811
тамже и патч к скрипту.