Сообщения

DI Container на примере bottle.js

Это продолжение заметки Dependecy Injection Если же развить паттерн Service Locator и представить себе центральный объект, в котором мы будем регистрировать все сервисы и зависимости и в конечном итоге получать центральный объект который и становиться нашей программой то мы получим паттерн DI Container. Здесь я продемонстрирую работу с библиотекой bottle.js как с примером реализации этого паттерна. Если почитать документацию то, как мне показалось, самым обобщённым и понятным подходом будет использование Service Factory var bottlejs = require('bottlejs'); let bottle = bottlejs(); class PostDB { posts = []; save(post){ this.posts.push(post); } getPosts(){ return this.posts; } removePost(id){ this.posts = this.posts.filter(post => post.id !== id); } getPostsById(id){ return this.posts.filter(post => post.id === id); } getPostsByBlogId(id){ return this.posts.filter(post => post.blogId === id); } } class Po

Dependecy Injection

Сразу оговорюсь что здесь я буду пытаться структурировать свои познания, причём делать это в процессе своей же учёбы. Так что ошибок тут будет тьма, столько же моего недопонимания и неверных выводов, так что если вы каким-то чудом набрели на эту статью то не в коем случае не принимайте ничего из нижесказанного за правду. Я пишу всё это исключительно для себя. О каких зависимостях идёт речь? О тех самых которые нужны программе и её частям чтобы работать, собственно это и есть её части. Возьмём простой пример: class DB {   posts = [];   save(post){     console.log(post);     this.posts.push(post);   }   getPosts(){     return this.posts;   } } class Post{   static id = 0;   constructor(title, message){     this.id = this.constructor.id++;     this.message = message;   } } db = new DB(); post = new Post('First Post', 'BLA-BLA-BLA'); db.save(post); 2 класса - Класс хранилища (DB) и класс сущности (Post), как видно из кода я просто хочу создавать объекты Post и

Функторы в JavaScript

Скорее всего вы уже использовали фанкторы, это map и filter. Сегодня я попробую разобраться что именно в map и filter заставляет отнести их к фанкторам. Также я попробую написать фаннктор. На для начала я напишу программу без использования фанкторов чтобы увидеть и понять проблему, которую фанкторы решают. Рассмотрим довольно бессмысленную функцию plus1: function plus1(value) { return value + 1; } console.log(plus1(3)) // 4 Настолько простая функция взята спецально, чтобы не отвлекатья от идеи, которую я хочу понять. Просто представьте что в реальной жизни эта функция делает что-то гораздо сложнее чем просто прибавляет 1 к полученному значению. Функция отлично обрабатывает переданные ей числа, но что будет если я передам ей массив [3,4]?Очевидно что она не сможет его обработать. Но я бы хотел получить назад массив [4,5], так что я перепишу plus1 вот так: function plus1(value) { if (Array.isArray(value)) { var newArray = []; for(var i=0; i < value.length; i++){

Пользовательские параметры в Zabbix (UserParameter)

Иногда требуется передавать собственные параметры на Zabbix сервер с помощью агента. Для этого в конфиге агента предусмотрен параметр UserParameter=<key>,<command> . Всё что нужно - это прописать его, перезапустить агента и создать элемент данных на сервере. Обратившись к официальной документации Zabbix об этой возможности можно прочитать подробнее. Покажу на примере из той же документации: UserParameter=ping,echo 1 Как видно из примера этот ключ всегда будет возвращать значение 1. Пропиываем в конфигурации агента (zabbix_agentd.conf), перезапускаем агент. Можно запустить агента с ключом -p, который выведет на экран все параметры и их состояния на момент запуска агента. Там можно найти и свой, вновь определенный. С помощью утилиты zabbix_get можно с сервера запросить параметр и убедиться что всё передается корректно: zabbix_get -s 10.10.10.10 -k ping Далее добавляем к узлу элемент данных, типа Zabbix Agent, прописываем имя получаемого параметра, в нашем случае

Загрузка CPU на Cisco Catalyst 4500 и Cat4k Mgmt LoPri

Столкнулся с проблемой необосновано выской загруженностью CPU на Catalyst 4500. Вывод  show process cpu sorted показывал самый прожорливый процесс -  Cat4k Mgmt LoPri. Обративышись к руковожствую cisco по решению проблем, связанных с высокой загруженностью cpu -  http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/troubleshooting/cpu_util.html выяснил что LoPri и HiPri можно развернуть, т.к. это множество сгруппированных процессов Вывод show process cpu sorted описывает два процесса, которые используют CPU: Cat4k Mgmt HiPri и Cat4k Mgmt LoPri. Эти процессы объединяют несколько платформо-зависимых задач, которые выполняют основные функции управления. Эти процессы занимаются обработкой control pane и data plane (Описание этих "логических плоскостей" можно прочитать тут ), которые должны быть обработаны CPU. Используйте команду  show platform health чтобы посмотреть развернутый вывод этих процессов  и определить какие конкретно задачи грузят процессор. В

Популярные сообщения из этого блога

Загрузка CPU на Cisco Catalyst 4500 и Cat4k Mgmt LoPri

Пользовательские параметры в Zabbix (UserParameter)

Функторы в JavaScript