Привет, Хабр.

В предыдущей части был рассмотрен прием сигналов с помощью GNU Radio. Сейчас мы рассмотрим обратную задачу — передачу сигналов различного вида модуляции.



Как и в случае приема, с помощью GNU Radio можно создать сложную программную систему для передачи сигналов, не написав ни одной строчки кода. Но для начала рассмотрим SDR-устройства, способные работать не только на прием, но и на передачу, в диапазоне от мегагерц до гигагерц.

Продолжение под катом.

Привет! Сегодня я расскажу о том, как можно прийти в небо, что нужно для этого сделать, сколько оно все стоит. Также поделюсь своим опытом обучения на частного пилота в Великобритании и развею некоторые мифы, связанные с авиацией. Под катом много текста и фоточек :)

Привет, я занимаюсь созданием приложений для СУБД Tarantool — это разработанная в Mail.ru Group платформа, совмещающая в себе высокопроизводительную СУБД и сервер приложений на языке Lua. Высокая скорость работы решений, основанных на Tarantool, достигается в частности за счет поддержки in-memory режима СУБД и возможности выполнения бизнес-логики приложения в едином адресном пространстве с данными. При этом обеспечивается персистентность данных с использованием ACID-транзакций (на диске ведется WAL-журнал). В Tarantool имеется встроенная поддержка репликации и шардирования. Начиная с версии 2.1, поддерживаются запросы на языке SQL. Tarantool имеет открытый исходный код и распространяется под лицензией Simplified BSD. Также имеется коммерческая Enterprise-версия.


Feel the power! (...aka enjoy the performance)

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

Категорически приветствую.

Недавно мне понадобилось поработать с Mikrotik через его API. Вроде бы ничего примечательного, есть официальная библиотека, есть еще на гитхабе обёртка, но вот беда — мне надо было работать асинхронно через asyncio и c использованием плюшек async/await. И такой библиотеки я не нашел.

Оглавление для всех статей цикла «Как взять сетевую инфраструктуру под свой контроль» и ссылки.

На данный момент опубликовано 7 статей:

Глава 1. Удержание
Глава 2. Чистка и документирование
Глава 3. Сетевая безопасность. Часть первая
Глава 3. Сетевая безопасность. Часть вторая
Глава 3. Сетевая безопасность. Часть третья
Глава 4. Автоматизация. Темплейты

Дополнение. О трех компонентах необходимых для успешной работы IT

Всего будет порядка 10 статей.

21 мая 2019 Wolfram Researh объявили о том, что они дали доступ к Wolfram Engine для всех разработчиков софта. Вы можете скачать его и использовать в своих некоммерческих проектах по ссылке

Свободный Wolfram Engine для разработчиков дает им возможность использовать Wolfram Language в любом стеке разработки. Wolfram Language, который доступен в виде песочницы — это мультипарадигмальный вычислительный язык, лежащий в основе самых известных продуктов Wolfram: Mathematica и Wolfram Alpha. Бесплатный Wolfram Engine также имеет полный доступ к базе знаний Wolfram и ее предварительно подготовленным нейронным сетям. Но для его использования вам необходимо оформить бесплатную подписку на Wolfram Cloud.

Регулярные выражения в Python от простого к сложному

Решил я давеча моим школьникам дать задачек на регулярные выражения для изучения. А к задачкам нужна какая-нибудь теория. И стал я искать хорошие тексты на русском. Пяток сносных нашёл, но всё не то. Что-то смято, что-то упущено. У этих текстов был не только фатальный недостаток. Мало картинок, мало примеров. И почти нет разумных задач. Ну неужели поиск IP-адреса — это самая частая задача для регулярных выражений? Вот и я думаю, что нет.
Про разницу (?:...) / (...) фиг найдёшь, а без этого знания в некоторых случаях можно только страдать.

Плюс в питоне есть немало регулярных плюшек. Например, re.split может добавлять тот кусок текста, по которому был разрез, в список частей. А в re.sub можно вместо шаблона для замены передать функцию. Это — реальные вещи, которые прямо очень нужны, но никто про это не пишет.
Так и родился этот достаточно многобуквенный материал с подробностями, тонкостями, картинками и задачами.

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

Эта памятка писалась для внутренних нужд (открыть глаза менее опытным в вебе коллегам). Но, т.к. я насмотрелся велосипедов от довольно уважаемых, казалось бы, контор, — выкладываю на хабр. Мне кажется, многим будет полезно.

Зачем

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

• Стандарт HTTP это стандарт. Его несоблюдение вредно для кармы и ведёт к постоянным проблемам с безопасностью, кэшированием и прочими "закидонами" браузеров, которые совсем не закидоны, а просто следование стандарту.
• Велосипеды со всякими {error: "message","result":...} невозможно нормально тестировать и отлаживать
• Поддержка большим количеством готовых клиентских библиотек на все случаи жизни. Те, кто будет вашим api пользоваться, скажут большое человеческое спасибо.
• Поддержка автоматизированного интеграционного тестирования. Когда сервер на любые запросы отдаёт 200 ОК — ну, это такое себе развлечение.

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

Это оказалось очень нетривиальной задачей, и до конца мы её не решили. Но зато открыли много нового полезного в процессе. Например, мы уже поняли, что ИТ-отделов в компании должно быть два: тактический и стратегический. Тактический — это хелпдеск, железнячники, отслеживание ресурсов и лицензий, мониторинг и вообще всё то, что повторяется больше 2 раз. Стратегический — это реализация major-фич, планирование на 2-3 года вперёд и финансы.

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

Но давайте начну с методологии.

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

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

Я посмотрел, проанализировал, и составил перечень алгоритмов, которые успешно приводят ИТ-проекты к цели. Начнем с целей — чего же такого успешно достигается?

Внимание. Эта статья — только для людей из мира ИТ. Если вы не из ИТ, или, не дай Бог, какой-нибудь директор или собственник, вам лучше не читать эту статью. Иначе вы всё нам испортите.

И еще раз внимание. Эта статья — не сарказм, не попытка кого-то разгромить, не градация рынка и не поднятие чьего-либо ЧСВ, включая моё. Я, как и любой ИТ-специалист, и компания, в которой я работаю, как и любая другая ИТ-компания, подходят под определения из этой статьи.

Как-то я прочитал на Хабре статью про настройку BGP на роутере. Инструкции оттуда можно использовать для настройки домашнего роутера так, чтобы трафик на определённые IP-адреса шёл через другой канал. Однако здесь есть проблема: список IP-адресов может быть очень большим.

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

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

Но что делать тем, кто не хочет мириться с таким состоянием, и хочет одно кольцо один интерфейс, чтобы править всеми? Конечно же, написать его самим!



Я покажу, как с помощью Tarantool быстро сделать даже не визуализацию, а полноценную систему управления, с базой данных, кнопками управления и графиками. С её помощью возможно управлять устройствами умного дома, собирать и показывать данные с датчиков.

Что такое Tarantool? Это связка «сервер приложений — база данных». Можно использовать её как базу данных с хранимыми процедурами, а можно как сервер приложений со встроенной базой данных. Вся внутренняя логика, будь она пользовательской или в виде хранимых процедур, пишется на Lua. Благодаря использованию LuaJIT, а не обычного интерпретатора, в скорости она не сильно уступает нативному коду.

Еще один важный фактор — Tarantool это noSQL база данных. Это означает, что вместо традиционных запросов вроде «SELECT… WHERE» вы управляете данными напрямую: пишете процедуру, которая переберет все данные (или их часть) и выдаст вам их. В версии 2.x поддержку SQL-запросов добавили, но панацеей они не являются — для высокой производительности часто важно понимать, как именно исполняется тот или иной запрос, а не отдавать это на откуп разработчикам.

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

Поехали!

Чего воду в ступе толочь, вступления писать, сразу к делу.

Первый слой – кто хочет?

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

Но до реальных изменений дело доходит крайне – крайне редко. Это, наверное, даже не единицы процентов, а доли одного процента. Почему так?

Если собрать всех – например, программистов – и спросить: кто хочет что-то изменить в отделе, компании или отрасли? – то руки поднимут больше половины. Почему до конца, до реальных изменений, полезных и заметных, доходят эти несчастные доли? Где, и почему теряются остальные?

Этот процесс чем-то напоминает воронку, как в продажах. Помните же воронку продаж? Она показывает, сколько обращений переходят в деньги. Выглядит примерно так:


Ой, не то. Вот так:


Попробуем разобраться — кто, где отвалился и почему.

Итак, первый, самый широкий слой воронки – те, кто поднял руку.

Инструкций с разными вариантами обхода блокировок Интернет-ресурсов опубликовано огромное количество. Но тема не теряет актуальности. Даже всё чаще звучат инициативы на законодательном уровне заблокировать статьи о методах обхода блокировок. И появились слухи, что Роскомнадзор получит ещё одну пачку денег налогоплательщиков на «более лучшие» блокировки. Опытные пользователи ничего нового и полезного из статьи не узнают. А вот другие получат готовые пошаговые инструкции для простого и эффективного выборочного обхода блокировок на популярных маршрутизаторах с прошивкой Padavan и Keenetic.

Получилось так, что с 2012 года я курирую московский Techstars Startup Digest. Это — email-рассылка мероприятий для IT-специалистов, основателей стартапов и маркетологов.

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

Интересно, что в последнее время большая часть таких мероприятий проходит в коворкингах. Что удивительно, по моим наблюдениям, количество подобных площадок в Москве растет.

Этот тренд заинтересовал меня и стал отправной точкой для новых фотоэкскурсий — вроде тех, что я снимаю для компаний [например, вот самая первая из них и еще одна]. На этот раз мне захотелось рассказать про коворкинги и изучить новый подход к организации рабочих мест.

На Хабре я пока показал только #tceh, SOK и Ключ, а в период новогодних каникул переключился на изучение «мат.части», чтобы посмотреть, какие книги рассказывают об эволюции рабочего пространства: от первых опенспейсов 1900-х годов до коворкингов.

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

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

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

В большой организации работа централизованных служб часто имеет критическое значение.

Представьте, что Вы – руководитель службы поддержки, состоящей из 10 человек, и Ваша команда обслуживает коллектив из 200 команд, в каждой из которой по 7-10 человек. Это минимум 1400 человек, ежедневно засыпающих Вас работой.

Теперь добавим сюда ещё больше реальности и представим, что Вы выполняете некую централизованную функцию (например, настройку чего-нибудь), без которой команды не могут выдать результат.

Получается, что на Вас всё завязано, и чем быстрее и качественнее будет работать Ваша команда, тем быстрее будут выдавать результат все остальные команды в компании.

И тут начинаются жалобы на медленную отработку запросов…

Естественно, в этой ситуации руководителю нужны фактические данные, а не слова.

На помощь приходит когортный анализ.

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

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

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

Итак, сегодня Mikrotik (RouterOS), Suricata 4.1, Elasticsearch+Filebeat+Kibana 6.5.

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

Сергей Семёнов считает, что это происходит в основном по двум причинам.

• Нет инструментов и стандартов для оценки работы программистов. Менеджерам приходится прибегать к субъективной оценке, что в свою очередь приводит к ошибкам.
• Не используются средства автоматического контроля за процессами в команде. Без должного контроля процессы в командах разработки перестают выполнять свои функции, так как начинают исполняться частично или попросту игнорироваться.

И предлагает подход к оценке и контролю процессов на основе объективных данных.

Ниже видео и текстовая версия доклада Сергея, который по результатам зрительского голосования занял второе место на Saint TeamLead Conf.

Я хочу рассказать о такой штуке как DPDK — это фреймворк для работы с сетью в обход ядра. Т.е. можно прямо из userland писать\читать в очереди сетевой карты, без необходимости в каких либо системных вызовах. Это позволяет экономить много накладных расходов на копирования и прочее. В качестве примера я напишу приложение, отдающее по http тестовую страницу и сравню по скорости с nginx.

Мы живем в интересное время. Я бы даже сказал, в удивительное. По одну сторону мы видим неких лиц, которые очень хотят знать, о чем между собой разговаривают другие люди, и очень хотят указывать им, что можно читать, а что нельзя. С другой стороны граждане, которые хотят отстоять свои права тайны личной переписки и свободного получения информации, и не хотят, чтобы факты этой самой переписки и получения этой самой информации были использованы против них. Бонусом страдает огромное количество сторонних сайтов, сервисов и бизнесов, которых задевает «ковровыми блокировками».

Но нет, эта статья не об обществе, а о технологиях.