Skip to content

Флоатинг

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

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

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

Во всех рекламах, флоатинг преподносится прям как волшебство, зашел — полежал — вышел новым человеком с IQ 100500 (не ICQ) и кучей инсайтов, которые прям в очередь выстраивались на протяжении всей процедуры.

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

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

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

Одним из эффектов расслабления, который я заметил, это подергивание мышц, которые выходили из гипертонуса после тренировки.

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

Самый же кайф, который я ощутил в камере, это кромешная тьма и полная звукоизоляция, на фоне которой у меня даже были небольше звуковые галлюцинации.

Как итог: если вы чувствуете перегруженность информацией, усталость и вот это вот всё, то флоатинг может быть интересным опытом.

Выбираем ближайшие узлы в сети

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

Хорошим примером служит система доменных имен (DNS). DNS по природе своей является распределенной системой, корневые узлы которой разбросаны по всей планете. Чтобы просто зайти на любой сайт, сначала необходимо получить его IP-адрес.

Я не буду описывать весь процесс рекурсивного прохода по “дереву” доменных зон, а ограничусь тем, что для преобразования домена в IP-адрес нам требуется DNS резолвер, который выполнит всю эту работу за нас.

Итак, где же взять адрес DNS резолвера?

  1. Интернет-провайдер предоставляет адрес своего DNS резолвера.
  2. Найти в интернете адрес публичного резолвера.
  3. Поднять свой или использовать встроенный в ваш домашний роутер.

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

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

Когда список небольшой, то его легко можно “пропинговать” руками и сравнить время задержек, но если хотя бы взять список, упомянутый выше, то это занятие уже становится малоприятным.

Поэтому для облегчения этой задачи, я преисполненный синдромом самозванца набросал на Go proof-of-concept своей идеи под названием get-closer.

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

$ get-closer ping -f dnsresolver.txt -b=0 --count=10
Closest hosts:
1.0.0.1 [3.4582ms]
8.8.8.8 [6.7545ms]
1.1.1.1 [12.6773ms]
8.8.4.4 [16.6361ms]
9.9.9.9 [40.0525ms]


В своё время, когда я выбирал для себя резолвер, то ограничивался лишь проверкой основных адресов (1.1.1.1, 8.8.8.8, 9.9.9.9),- ведь они такие красивые, да и чего ждать от резервных некрасивых адресов.

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

Как показал тест, мне подходит больше “резервный” адрес Cloudflare, так как он воткнут в spb-ix, который для меня гораздо ближе, чем msk-ix, в который воткнут красивый 1.1.1.1

Разница, как вы видите, существенная, потому что даже самому быстрому лучику света не удается добежать из Питера до Москвы меньше чем за 10 мс.

Помимо простого пинга, в PoC есть еще возможность сравнить задержки и по другим протоколам, таким как http и tcp, а также время преобразования доменов в IP через определенный резолвер.

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

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

Без сервера сервера женили

Serverless computing - бессерверные вычисления

Бессерверные вычисления (serverless computing), на мой взгляд, крайне спорное название для технологии, которая использует серверы для своей работы. Бессерверные вычисления, которые выполняются серверами… Поскольку я провел очень много времени за построением инфраструктурных решений, то у меня от этого названия прям конкретно припекает.

С другой же стороны, когда смотришь на это со стороны потребителя, то всё выглядит очень заманчиво, но и в этом случае где-то на краю подсознания возникает какой-то когнитивный диссонанс, ведь что-то должно выполнять эти вычисления, а что если не серверы?

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

Впрочем, хватит философии, а то выйдет целый роман «СерверLess. Повесть о ненастоящем сервере».

Откуда же взялось это бессерверие?

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

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

Таким образом чтобы стать бессерверным, сервис должен:

  • не требовать администрирования;
  • иметь возможность авто-масштабирования;
  • предоставлять API или любой другой интерфейс для взаимодействия.

Почему только сейчас serverless начинает набирать обороты?

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

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

И здесь нам на помощь приходит Function as a Service, который и имеют в виду по умолчанию, когда говорят про serverless, ведь без него serverless не был бы serverless.

Не любое приложение можно реализовать бессерверно, но если ваше приложение:

  • выполняет работу в ответ на событие (event-based);
  • не хранит состояние (stateless);
  • выполняет непродолжительные задачи (ephemeral);
  • не изменяется в процессе работы (immutable);
  • может легко масштабироваться (auto-scaling).

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

Итого

Основной посыл данного поста это призыв к правильному употреблению терминологии. Если вы спрашиваете про serverless у программиста, то это нормально, но не стоит будить дракона, спрашивая это у админа.


Telegram опубликовал MTProxy

Война Telegram и РКН продолжается уже давно, но до сих пор нет явного победителя.

У РКН со своей стороны растет список IP адресов для блокировки, истерия в СМИ не стихает, принуждают Apple к удалению Telegram из App Store и отключить push уведомления для них.

Telegram же наращивает арсенал инструментов для обхода блокировок. Новым таким инструментом стал долгожданный MTProxy (о принципах работы которого можно ознакомиться здесь).

В лучших традициях сопротивления, код был опубликован на GitHub. Посмотрев на репозиторий, возникло ощущение, что ребята как-то в спешке публиковали код.

make просто так на Ubuntu 16.04 собрать проект не смог, так как требуется более свежая версия OpenSSL, которой в этой версии Ubuntu нет. Но есть PR, который решает эту проблему. Остальная же настройка по шагам описана в README файле.

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

Слухи о возможности встраивания рекламы Telegram каналов подтвердились, для этого нужно зарегистрировать свой прокси у @MTProxybot.

Заходите на канал в Telegram.

Визуализация связей процессов в Linux

lsofgraph python
Приходилось ли вам отслеживать зависимости системных процессов, «кто чей папка», найти императора и убить его, чтобы рабы не респаунились? Можно ps’ать и grep’ать, можно lsof погонять, ведь это так увлекательно 😉 Но любые связи, как мне кажется, всегда проще анализировать в визуальной форме, консольные утилиты рисуют хорошие таблички, но из них не всегда можно быстро понять, что с чем связано и в какой последовательности, а для диагностики это очень важно.

Read More →

Запуск канала в Telegram

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

Присоединяйтесь в Telegram

Новый TLS DNS резолвер от Cloudflare

Безопасность DNS становится все более актуальной темой, поэтому появляется все больше DNS резолверов с шифрованием (TLS), которые позволяют предотвратить перехват DNS запросов.

Когда я узнал о запуске резолвера quad9.net, то сначала даже нормально не смог зайти на их сайт (да и сейчас порой ощущение, что он лагает), пинги до резолвера были не значительно лучше чем у гугловых…

Но вот когда Cloudflare объявил о запуске нового публичного DNS резолвера, то они сразу правильно расставили акценты и приложили интересующие бенчмарки.

Read More →

pipenv: python packaging tool

pipenv demo
pipenv призван упростить управление виртуальным окружением и зависимостями для python проектов.

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

Те кто много работал со связкой pip + virtualenv должны оценить pipenv по достоинству.

sshportal: удобный доступ в DMZ

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

sshportal представляет собой простой способ организации доступа по SSH внутрь DMZ сети. По сути это всё те же самые ssh туннели, но централизованные и более удобные в управлении.
Более подробную доку можно посмотреть на гитхабе.

Мысли о подходе к изучению/обучению

Когда работаешь в команде, то очень важно чтобы вся команда находилась в одном контексте. Часто бывает, что когда кто-то один из команды прочитает новую книгу о какой-нибудь новой методологии, то он волей не волей начинает мыслить её канонами, но, к сожалению, остальная часть команды этого может не понимать и применение методологии никак не помогает «новоиспеченному адепту» понять необходимость её использования или соответствия собственным задачам.
В моем опыте было очень много примеров, когда одну и ту же книгу члены команды читали в разные периоды времени, им не удавалось погрузиться в единый контекст и использовать новые знания. Но когда все в команде прочитывали книгу до конца и имели одинаковое понимание контекста, то исчезало недопонимание в восприятии идей других членов команды. При наличии схожих знаний и общего контекста гораздо легче понять мотивацию других участников и воспринимать такие идеи становится гораздо легче и они выглядят более понятными. В современном мире мы обрабатываем так много различной информации из различных источников, что всего и не упомнишь.
Если ты руководишь несколькими разными командами с различной функциональностью, например, UX и программисты, то всегда хочется понимать в каком состоянии находится тот или иной контекст, синхронизированы ли знания ребят, в какую сторону перевес, почему это происходит. Вы как руководитель сами формируете контекст для отдела, саморазвитие отдела очень важное и ответственное дело. Чем лучше и правильнее вы сформируете процесс самообучения, тем быстрее вы сможете адаптировать новых специалистов, а главное меньше тратить на это времени.
Очень важно определять последовательность изучения материалов по той или иной теме, от введения, до глубоких деталей. Предоставив просто список литературы, человек может отранжировать его по заголовкам или любым другим субъективным параметрам, тем самым увеличив время изучения и погружения в контекст.
Структурный и последовательный подход к обучению всегда был самым эффективным, дома ведь тоже строятся с фундамента. Для определения жесткой последовательности изучения материалов необходимо проводить глубокий анализ на как можно большем количестве людей для наиболее объективного определения последовательности изучения материалов