Предлагаю ознакомиться с расшифровкой доклада Алексей Лесовский из Data Egret "Основы мониторинга PostgreSQL"

В этом докладе Алексей Лесовский расскажет о ключевых моментах постгресовой статистики, что они означают, и почему они должны присутствовать в мониторинге; о том, какие графики должны быть в мониторинге, как их добавить и как интерпретировать. Доклад будет полезен администраторам баз данных, системным администраторам и разработчикам, которым интересен траблшутинг Postgres'а.

10 апреля 2020 года компании Apple и Google анонсировали, что в следующих обновлениях их операционных систем iOS и Android появится поддержка совместно разработанного протокола отслеживания контактов.

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

24 апреля 2020 года Apple и Google анонсировали обновление совместно разработанного протокола отслеживания контактов (Apple & Google Contact Tracing Protocol), который они теперь называют исключительно технологией «уведомления о возможном заражении» (Exposure Notification Technology), поскольку указанное название лучше описывает суть протокола.

29 апреля вышла iOS 13.5 beta с первой реализацией данного протокола. Бета нацелена на тестирование разработчиками нового API и получение обратной связи. Доступ к API планируется выдавать только приложениям, официально связанным с государственными медицинскими учереждениями.

Эта статья расскажет о том, чем вызваны изменения в протоколе, остались ли уязвимости после обновления, а также удалось ли компаниям Apple и Google ответить на критику (часто необоснованную).

В данной статье я хочу поделиться опытом, полученным в ходе переписывания одного проекта с Perl на Go. В ней будет больше о минусах, чем о плюсах, ибо о достоинствах Go и так поведано немало, а вот о подводных камнях, ожидающих новых разработчиков, узнать зачастую, кроме как от собственных шишек — неоткуда. Пост никоим образом не преследует цели охаять язык Go, хотя, признаться, некоторые вещи я был бы рад не писать. Также в нем охвачено сравнительно небольшой срез всей платформы, в частности, не будет ничего о шаблонах, регекспах, распаковке/запаковке данных и подобного, часто используемого в веб-программировании, функционала.

В последние несколько лет MongoDB приобрела огромную популярность среди разработчиков. То и дело в интернете появляются всякие статьи, как очередной молодой популярный проект выкинул на свалку истории привычные РСУБД, взял в качестве основной базы данных MongoDB, выстроил инфраструктуру вокруг неё, и как все после этого стало прекрасно. Даже появляются новые фреймворки и библиотеки, которые строят свою архитектуру целиком на Mongo (Meteor.js например).

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

Все что описано ниже можно воспроизвести с использованием библиотеки PyMongo для работы с MongoDB из языка программирования Python. Однако скорее всего с аналогичными ситуациями вы можете столкнуться и при использовании других библиотек для других языков программирования.

В сентябре прошлого года была опубликована последняя статья о Центрифуге — сервере с открытым исходным кодом для обмена сообщениями в режиме реального времени. Теперь в списке хабов, в которые публикуется этот пост, присутствует Go. И неспроста, как можно понять уже из заголовка, Центрифуга была портирована с Python на Go — так появилась Centrifugo. О причинах миграции, о плюсах и минусах Go, а также о том, как эволюционировал проект с момента предыдущей публикации – читайте под катом.

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

В этой статье я расскажу о том, как мы автоматизируем тестирование наших приложений (ICQ и Агент Mail.Ru), поделюсь нашими наработками в этой области и упомяну о проблемах, с которыми мы сталкиваемся.

В наши дни разработчики ПО не могут прожить без их любимых тестовых фреймворков. Но вот чего разрабочики не хотят — так это обеспечивать постоянный запуск этих тестов. Также, команды разработчиков не хотят тратить время на доведение результатов теста до всех.

Появляется все больше и больше полезных приложений, библиотек и плагинов, которые частично облегчают головную боль, возникающую в ходе попыток сделать тесты полезными для всей команды. Примерами прекрасных инструментов, которые есть в нашем распоряжении, могут быть Hudson для непрерывной интеграции, Cucumber для интеграционных тестов и Selenium для автоматизированного тестирования веб-приложений в реальном браузере. Но организация совместной работы всего этого требует все больше и больше настроек и конфигураций на сборочном сервере.

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

Не так давно на Хабре уже был перевод статьи Раймонда Хеттингера Руководство к дескрипторам. В этой статье я постараюсь рассмотреть вопросы, которые возникли у меня после прочтения. Будет немного примеров кода, собственно вопросов и ответов к ним. Для понимания того, о чем речь, вам нужно знать, что такое дескрипторы и зачем они.

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

Краткое содержание поста:

1. тестирование веб-сайтов — это сложно и непонятно
2. юнит-тесты в django
3. тестовая БД и как с ней бороться
4. smoke testing
5. покрытие кода (code coverage)

Обзор и основы установки и настройки puppet уже публиковались Часть 1 и Часть 2 поэтому я не буду на этом останавливаться а сразу перейду к настройке фаервола.

Постановка задачи

В проекте используется некоторое количество серверов, большинство в из которых в облаке. Часть используется для обеспечения инфраструктуры компании, часть обеспечивают публичный сервис клиентам. Необходимо обеспечить централизованное управление доступом.

Selenium

Selenium — это очень удобный (имхо) инструмент для тестирования веб-приложений.

Тесты создаются с помощью дополнения для Firefox, которое может генерировать код теста на различных языках, в том числе и на Python. Затем эти тесты выполняются специальным сервером, Selenium RC.

Сам по себе Selenium не привязан ни к языкам ни к фреймворкам, поэтому чтобы интегрировать его в систему тестирования Django-приложений, нужно приложить очень небольшие усилия.

Для решения задачи интеграции я буду использовать библиотеку Django: Sane Testing. Это библиотека, расширяющая возможности стандартной системы тестирования Django, в том числе и поддержкой тестов Selenium.

В результате изучения функционального программирования в моей голове появились некоторые мысли, которыми я хочу с вами поделиться.

Введение

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

Как обычно бывает с ресурсами, набирающими популярность, железки на которых все крутится, перестают справляться. Ресурс стоял на стареньком двухпроцессорном сервере, на котором крутились практически все сервисы для пользователей. В то время начальство не воспринимало ресурс как нечто стоящее вложений, поэтому, к моему сожалению (а позже – счастью), денег под новую железку мне не выделяли.

Преамбула

В связи с выходными потратил немного времени на реализацию сервера Memcache с использованием python-фреймворка Twisted. В итоге я получил быстродействие в два раза более низкое, что я не считаю очень критичным, а также возможность реализовать парочку расширений оригинального протокола. Также возможны оптимизации, которые еще улучшат быстродействие.
Протокол не был реализован полностью — есть еще моменты над которыми можно поработать, но стандартные set/get вполне работоспособны и готовы к использованию.

Средства

Для хранения кеша используем базовый класс dict. Как вы догадываетесь, реализация dict в python быстра, этот базовый тип используется в python настолько активно, что его не оставили без детальной оптимизации. Таким образом, мы автоматом имеем структуру для хранения кеша в памяти. Осталось реализовать протокол memcache, для предоставления доступа к dict другим программам.

Для реализации сервера используем Twisted. Есть множество вариаций неблокирующего IO для python на сегодня, но Twisted это уже классика, и имеет в своем арсенале достаточно средств для легкого решения подобных задач.

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

О том, как заставит ноутбук работать под линуксами как можно дольше, написано немало, в том числе и на хабре. В какой-то степени я еще раз соберу все советы воедино, от очевидных до обскурных, заодно опишу несколько проблем и решений, которые у меня оказались достаточно «индивидуальными».

Устанавливал я Ubuntu 10.10 на ноутбук Acer Aspire Timeline 5810TG. Эта машина обладает экраном в почти 16 дюймов и относительно производительным железом, зато батарея достаточно емкая, чтобы ставить с ней личные рекорды.

Последние 15 недель мы активно работали над проектом «Стиллион», первым нашим мейнстрим-проектом, написанным на Django. Был приобретен интересный опыт, которым мы хотели бы поделиться с сообществом.
Статья, прежде всего, будет интересна новичкам в Django.

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

Клиенту неважно насколько красив ваш код, но ему важен результат. Качественный код нужен фирме, т.к. он надёжней и в будущем его будет легче поддерживать.

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

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

С ростом популярности web-приложения его поддержка неизбежно начинает требовать всё больших и больших ресурсов. Первое время с нагрузкой можно (и, несомненно, нужно) бороться путём оптимизации алгоритмов и/или архитектуры самого приложения. Однако, что делать, если всё, что можно было оптимизировать, уже оптимизировано, а приложение всё равно не справляется с нагрузкой?

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

Рассмотрена настройка через конфигурационный файл vimrc и приведены ссылки на статьи с описанием отдельных моментов.

Кого-то VIM оттолкнет, показавшись поначалу слишком сложным или неудобным. Однако не стоит недооценивать его гибкость и возможность настройки себя, ведь из VIM можно буквально вылепить идеальный редактор/IDE, таким, каким вы представляете его себе.

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

Я постарался писать как можно компактней, но без потери содержательной части, но статья все-равно вышла довольно объемной. Материал логически разбит на несколько разделов и совсем не обязательно читать его по порядку. Тем не менее, прочитать сведения по установке плагинов и настройке vimrc я рекомендую настоятельно.