Случается в нашей жизни, уважаемые коллеги, что хочешь сделать как проще, а получается как у новичка. И, что интересно, существует не мало мощных инструментов, которые предлагают простое решение в обмен на душу. Я имею ввиду, что цена абстракции бывает несоразмерна красоте её использования. Для меня примером такого неравноценного обмена стал Django Rest Framework 3.4.0, его механизм ViewSets и необходимость вывести подробную документацию по разрабатываемому API.

Разработчикам удобно пользоваться консолью для отладки, но ещё удобнее, если будет оболочка, в которой учтены особенности реализации консоли в различных браузерах, поэтому тема обёрток для консоли устойчиво существует.

Рассмотрим ранее опубликованные решения, затем сделаем обзор методов консоли с помощью перевода недавней статьи Axel Rauschmayer-а, разработчика и консультанта с более чем 15-летним стажем, затем я опубликую некоторые свои решения, которые оказались удачными в процессе эволюции и отладки на ряде проектов.
UPD 2015: обновление таблицы команд до актуального состояния, Github (ru, en; разворачивание на javascript).

Доброго времени суток, друзья!

В этой небольшой заметке я хочу поделиться с Вами информацией о некоторых методах объекта Console, которые можно использовать наряду с console.log().

Полный список методов можно посмотреть здесь.

От слов — к делу. Да, для работы будет использоваться Chrome.

Console.debug() и сonsole.info()

Console.debug() и console.info() служат для вывода информационных сообщений в консоль и, по сути, являются аналогами console.log(). Одна из особенностей console.debug() состоит в том, что выводимое этим методом сообщение отображается только если консоль настроена на показ сообщений уровня отладки (для Chrome — галочка у Verbose вкладки Levels).

Сложно представить себе разработку на JS без вывода информации в консоль. Говоря метафорически, console.log() — лекарство от большинства болезней кода.

Отладка — почти как расследование преступления, где главный преступник тоже вы — Филипе Фортес

Но помимо повсеместно используемой функции console.log(), есть ещё много инструментов, позволяющий сильно упростить процесс. Давайте разберём некоторые из них на простых примерах.

Со времён систематизации методов объекта console прошло достаточно много времени, некоторые браузеры получили поддержку недостающих ранее методов. Таблица вызывает естественный интерес у разработчиков, поэтому — почему бы её не обновить, дополнив в одной статье описаниями? Github.

Привет, Хабр! Представляю вашему вниманию перевод статьи «How to use the JavaScript console: going beyond console.log()» автора Yash Agrawal.

Один из самых простых способов отладки чего-либо в JavaScript — вывод материала с помощью console.log. Но есть много других методов, предоставляемых консолью, которые могут помочь улучшить отладку.

Давайте начнем.

Самым базовым вариантом использования является вывод строки или группы объектов JavaScript. Довольно просто,

console.log('Is this working?'); 

Теперь представьте сценарий, когда у вас есть куча объектов, которые вам нужно вывести в консоль.

const foo = { id: 1, verified: true, color: 'green};
const bar = { id: 2, verified: false, color: 'red' };

Самый интуитивно понятный способ вывода просто console.log (variable) несколько раз. Проблема становится более очевидной, когда мы видим, как оно отображается в консоли.



Как видите, имена переменных не видны, что не очень удобно. Это можно решить объединив все переменные в единый console.log ({foo, bar}). Это также уменьшает количество строк console.log в нашем коде.

Доброго времени суток, %username%. Пора расчехлить блог после 6 лет простоя и попробовать опять что-то полезное принести сообществу.

Я крайне удивлен, что на хабре до сих пор нет ни одной статьи про Swarmpit. Я конечно понимаю, что наверняка большинство изучая Docker останавливаются собственно на нем и потом пытаются забраться на Эверест под названием Kubernetes. Не знаю точных чисел, но думаю тут большинство теряются и либо вообще забивают на Docker либо только его и используют. А зря!

PostgreSQL 12, последняя версия «лучшей в мире реляционной базы данных с открытым исходным кодом», выходит через пару-тройку недель (если все пойдет по плану). Это соответствует обычному расписанию — новая версия с уймой новых возможностей выходит раз в год, и, честно говоря, это впечатляет. Поэтому я и стал активным членом сообщества PostgreSQL.

По-моему, в отличие от прошлых выпусков, PostgreSQL 12 не содержит одной-двух революционных функций (как, например, секционирование или параллелизм запросов). Я как-то пошутил, что главная фишка PostgreSQL 12 — в большей стабильности. А разве не это нужно, когда вы управляете критически важными данными вашего бизнеса?

Но PostgreSQL 12 этим не ограничивается: с новыми возможностями и усовершенствованиями приложения будут работать лучше, а от вас всего-навсего требуется сделать апгрейд!

(Ну, может, еще индексы перестроить, но в этом релизе это не так страшно, как мы привыкли.)

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

• Количеством транзакций порядка 5'000 — 10'000 в секунду
• Объемом примерно в 100ГБ (который бодро растёт)
• Примерно равным количеством операций на чтение/запись
• Преимущественно мелкими транзакциями

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

Я опишу некоторые проблемы, с которыми мы сталкиваемся, и применённые решения. Если кто-то сочтёт это полезным — ради Бога. Если кто-то поправит — я буду только рад обнаружить уязвимость в используемых подходах и увеличить эффективность работы БД. Описанное может быть применено без вмешательства в логику приложения, исключительно путём модификации схемы БД.

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

На прошлой неделе фонд CNCF (Cloud Native Computing Foundation) объявил о принятии под своё крыло 10-го Open Source-проекта — CNI (Container Networking Interface). Его задача — обеспечить всё необходимое для стандартизированного управления сетевыми интерфейсами в Linux-контейнерах и гибкого расширения сетевых возможностей. В CNCF объяснили необходимость такого проекта активным распространением контейнеризированных приложений в мире production и утверждают, что «подобно тому, как Kubernetes позволяет разработчикам массово запускать контейнеры на тысячах машинах, этим контейнерам в больших масштабах требуется сетевое управление [и реализующий его фреймворк]».

Как же появился CNI и что он предлагает?

Прим. перев.: Автор статьи — Reuven Harrison — имеет более 20 лет опыта в разработке программного обеспечения, а на сегодняшний день является техническим директором и соучредителем компании Tufin, создающей решения для управления политиками безопасности. Рассматривая сетевые политики Kubernetes как достаточно мощное средство для сегментации сети в кластере, он в то же время считает, что они не так просты в применении на практике. Данный материал (довольно объёмный) призван улучшить осведомлённость специалистов в этом вопросе и помочь им в создании необходимых конфигураций.

Прим. перев.: Эта статья продолжает цикл материалов о базовом устройстве сетей в Kubernetes, что описывается в доступной форме и с наглядными иллюстрациями (впрочем, конкретно в этой части иллюстраций уже практически не оказалось). Переводя две предшествующие части этого цикла, мы объединили их в одну публикацию, в которой рассказывалось о сетевой модели K8s (взаимодействие внутри узлов и между узлами) и оверлейных сетях. Её предварительное чтение желательно (рекомендуется самим автором). Продолжение же посвящено сервисам Kubernetes и обработке исходящего и входящего трафика.
NB: Текст автора для удобства дополнен ссылками (преимущественно — на официальную документацию K8s).

Прим. перев.: Автор статьи — Amanpreet Singh — называет себя «всё ещё начинающим в мире сетей», однако именно это и побудило его разобраться в их базовом устройстве в Kubernetes (который он использует в production), а затем — поделиться с сообществом очень доступным материалом с наглядными иллюстрациями. В оригинале он разбит на две части, однако в этом переводе мы объединили их в одну статью.



Вот вы запустили множество сервисов в кластере Kubernetes и пожинаете плоды… или хотя бы собираетесь это сделать. Однако, даже несмотря на существование ряда утилит для настройки кластера и управления им, вам всё же интересно, как всё работает «под капотом». Куда смотреть, если что-то сломается? По себе знаю, что это важно.

1. Шар на пружине, ньютоновская версия
2. Квантовый шар на пружине
3. Волны, классический вид
4. Волны, классическое уравнение движения
5. Квантовые волны
6. Поля
7. Частицы – это кванты
8. Как частицы взаимодействуют с полями

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

$$

Где:
• z – положение шара как функция времени t,
• z₀ — положение равновесия шара (где он покоился бы, если бы не колебался),
• A – амплитуда колебаний (которую мы можем выбирать сколь угодно большой или малой),
• ν [ню] – частота колебаний (зависящая только от силы пружины К и массы шара М, и не зависящая от А).

Кроме того, общая энергия, хранящаяся в колебании, равна

$$

Изменяя А, мы можем сохранить в колебании любое количество энергии.

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

Райтнов любил работать по утрам. Для него это было то самое время, когда любой труд приносил наибольшие плоды – будь то работа головой или руками. Он подсоединил множество датчиков к двигателю, завел ровер и принялся искать неполадки, тщательно всматриваясь в графики. На первый взгляд все выглядело хорошо, но он решил дать двигателю поработать еще немного. Спустя десять минут энергия начала кончаться, и ровер переключился на питание топливом.

– А вот это уже непорядок, – заметил Райтнов, подсоединяя отводящий выхлопные газы шланг.

Лекс очнулся и открыл глаза. Его взору предстал всё тот же невесёлый ангар. Недалеко стоял его корабль с открытым люком и выдвинутой аппарелью. Лекс осторожно сел. Голова болела, но он уже не чувствовал слабости в теле, как в своё прошлое пробуждение.

«Что-то изменилось», — подумал Лекс. Он покрутил головой. «Точно – стула нет! — отметил он изменения в обстановке. — А вместе с ним исчез и хранитель – может они как-то связаны друг с другом?» Пришедшая в голову мысль настолько развеселила его, что он рассмеялся в пустоту ангара. Искажённое и пугающее эхо заставило его замолчать. Лекс попробовал подняться и у него это легко получилось. Он покрутил головой, но никаких изменений в обстановке ангара больше не заметил.

Приветствую всех! Статью про взгляд на проблему жиров с моей, химической точки зрения я обещал написать уже давно, да больно уж вопрос непонятен. Однако, попробуем разобраться. Хотя на эту тему существует громадное количество публикаций — ясности они не приносят — так как часто противоречат и друг другу и здравому смыслу. Так что, собравшись с духом, решил рыться в материалах до момента понимания. Вас же приглашаю ознакомиться с моими изысканиями. Нам придётся копать несколько глубже обычного, постараемся разобраться с этим вопросом «с точки зрения банальной эрудиции»… в смысле — логики. На вход — факты, только факты. Причём, моя цель просто выяснить для себя этот вопрос, каких-либо других целей не имею. Меня интересует — какие жиры более полезны, какие вредны, сколько их употреблять и каких, на чём жарить, как сохраняются, разъяснить странности с маргариновыми транс-жирами(для меня объяснения изготовителей выглядят туманными и неполными). Всё это в рамках официальных рекомендаций ВОЗ и российских уполномоченных органов — то есть никакой конспирологии. Если Вам это интересно — прошу под кат.

На самом деле патчим gnupg и libgcrypt…

Когда-то давным давно, чтобы использовать 8192 и 16384 RSA ключи я правил размер в keygen.c и размер SECMEM буффера по соседству. Дела давно минувших дней, теперь SECMEM вынесена в config.h и именуется SECMEM_BUFFER_SIZE.

В итоге после скачивания верии 2.0.29 под свежий debian 8.3, за место убитой 12й убунты апдейтом на 14ую, я быстренько подкрутил размер ключика и размер буфера и радостно сгенерировал на 5200U 16кбит ключ за 18 (или 19) минут, что раньше занимало 45-50 минут на P6200.

Но вот 32кбит дали мне пачку ошибок. Свободное время есть — разбираемся.

В сентябре 2013 я опубликовал крайне популярную статью с таким-же названием. Однако с тех пор всё радикально поменялось со стороны fail2ban — добавлена поддержка asterisk «из коробки», а также с версии 0.9 радикально изменился формат конфигурационных файлов. Поэтому я публикую новую статью на эту тему, так как действия по настройке теперь тоже радикально иные.

До момента появления лога security в Asterisk 10-й версии fail2ban не мог корректно защищать asterisk от популярного вида атак — подбора sip пароля к экстеншенам, т.к. в обычных логах asterisk ip-адрес атакующего не отображался.
С появлением лога security эта проблема решена.

Если у вас Asterisk 10 и новее, его успешно можно использовать на пару с fail2ban. Настройка довольно простая.