noTieinIT

@notieinIT Нравится 0

Об IT без галстуков. Мысли CTO о построении и развитии IT бизнеса, развитии команды, менеджменте и трендах
Обратная связь - @notieinit_bot
Гео и язык канала
Россия, Русский
Категория
Технологии


Написать автору
Гео канала
Россия
Язык канала
Русский
Категория
Технологии
Добавлен в индекс
09.12.2017 22:25
реклама
СысоевFM — канал о ресторанах.
Самый популярный канал о еде со скидками в ресторанах.
Началось!
Острые новости в твоём телеграме
Путеводитель в мир бизнеса
Начните с нуля. Инвестируй в себя и свои знания.
2 098
подписчиков
~1.4k
охват 1 публикации
~125
дневной охват
~22
постов / месяц
67.8%
ERR %
2.36
индекс цитирования
Репосты и упоминания канала
13 упоминаний канала
1 упоминаний публикаций
3 репостов
ДевОпс Инженер
CatOps
rxd_txd
Записки админа
ProgHub
Clean Code
ДевОпс Инженер
Жабаскрипт
Telegram Group List
Пятничный деплой
Экстраполяция IT
Новые каналы
Экстраполяция IT
Каналы, которые цитирует @notieinIT
Последние публикации
Удалённые
С упоминаниями
Репосты
noTieinIT 8 Sep, 16:40
​​🍿Анонс истории: релиз после года разработки и debug под новогодний звон бокалов

Более трёх лет назад мне довелось взять на себя ответственность по проектированию и построениею системы в доменной зоне в которой ни у меня, ни у команды не было экспертизы. Домен еще и сложен сам по себе в виду работы с real time video streaming и его доставкой для B2B клиентов, а там worldwide, low latency, масштабируемость и все такое.

Первым делом занялся трансляцией требований бизнеса в архитектуру что была бы приемлема по стоимости с одной стороны, а с другой стороны могла бы масштабироваться и могла бы быть реализована в срок. Если опыта за 10+ лет инженерии для построение архитектуры хватило, то экспертизы в технологическом стеке не было. Логично было начать искать подрядчиков для реализации этой системы. Они были найдены, UML диаграммы и описание API всех слоев были переданы на реализацию, через 4-6 месяцев получили систему и зарелизили первую версию. Год потребовался чтобы осознать две вещи:
🔸вылезли косяки имплементации что нарушали требования архитектур, а на приемке не могли быть найденными, слишком специфичные кейсы;
🔸с ростом инфраструктуры и пользователей косяки начали существенно мешать и негативно влиять на user experience;
🔸контракторы крайне вяло шли на контакт и устранялись от проблем.

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

Год заняло переписывание слоев видеостриминг платформы. Был только один core компонент что оставался 3rd party для нас - это Wowza Streaming Engine написанный на Java, с закрытым кодом и индусским саппортом. Но load tests показывали хорошие показатели и этот black box оставили в проекте. Был полностью переписан код логики управления слоями, внесена логика что не было реализована изначально, но было зафиксировано в архитектуре. Все тщательно тестировалось, даже нагрузочные были…

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

Мы занимались поиском причины на протяжении нескольких дней перед Новым Годом, ведь оставлять систему в таком состоянии на праздники было недопустимо. И вот, бьют куранты, шампанское 🍾 льется в бокалы , а я и дежурный админ пытаемся рездебажить и понять причину происходящего. Дебаг продолжился и в праздники, и еще недели после него. Что только не делали: статический анализ, анализ трафика, strace, смена ядер, замена сетевых карт, анализ кода ядра Linux и кода драйверов сетевых карт.

Это завязка истории которую я держал в заметках еще с марта 2018. В ней и борьба с собой, поиск решений без малейшего представления куда копать, работа в новых сферах и в сжатые сроки при постоянном стрессе. Не менее эпично ошибку фиксали, сделав из этого целый хакатон. Теперь пришло время историю поведать и лучшим местом для этого будет Highload Fwdays’19 что состоится 5 октября 2019 года в Киеве. Тем кто придет гарантирую полезный и увлекательный сторителлинг, отвечу на вопросу и понетворкаюсь. Для жителей других стран и регионов будет организована онлайн трансляция ближе к мероприятию.

Для подписчиков канала специальный дискаунт. Используйте при оплате промокод MENSHIKOV и получите 15% скидки. Для тех кто оставит запрос в @noTieInIT_bot (в свободной форме) получит записанное видео с мероприятия.

Увидимся на конференции!
Читать полностью
noTieinIT 18 Jul, 14:07
🧭 Network performance: уменьшение latency с DNS

Сразу спойлер. Выводы и рекомендации в самом конце! Поехали.

Независимо подключен ли CDN для раздачаи статики и основного контента браузеру пользователя потребуется узнать куда обращаться за данными. Дабы подключится к серверу необходимо знать его IP адрес. Пользователь мог бы явно обращаться и писать https://183.92.46.12/, но это неудобно. Второй минус прямого обращения в том, что это рушит принцип работы классических CDN. Потому был придуман протокол DNS (кстати, работает как по UDP, так и по TCP). Его задача состоит в преобразовании хостнеймов в IP адреса.

Разберем на примере как происходит определение IP адреса. Браузер получает запрос на открытие страницы и запрос содержит hostname, допустим mycfdistribution.cloudfront.net. Скорее всего у браузеров реализован свой кэш уровень и он сперва проверит налиие адресов в кэше. В случае наличия ответа в кэше сразу произойдет обащение на заданный IP адрес. Если в кэше записи нет, то начинается процедура определения и это уже задача операционной системы. Я ранее писал подробную публикацию о том как Linux системы определяют механизм получения адреса: это довольно подробный анализ и останавливаться не буду на этом... перейдем сразу к шагу общения с DNS-серверами.

Если ОС пользователя получила настройки сети от провайдера, то с большой вероятностью провайдер предоставил свой локальный DNS-сервер. ОС пользователя шлет запрос на этот DNS и у него тоже есть функционал кэширования. Кэширование эффективно работает при обращении а популярне домены, google.com и т.п. Для менее популярных сайтов записи в кэше вероятно не будет и DNS-сервер вынужден обращаться к другим серверам для получения информации. Но куда обращаться-то? Сперва обращение пойдет на root сервер который отвечает за всю зону .net (a.gtld-servers.net) с целью получить информацию о cloudfront.net. Получив ответ DNS-сервер знает authoritative DNS-сервер которых зранит информацию о конкретном сабдомене, т.е. mycfdistribution.cloudfront.net и обращается к нему для получения IP-адреса для получения контента.

В этой цепочке наверняка в кэше локального DNS резолвера будет информация о net зоне, а поскольку cloudfront довольно популярен, то вероятность что он тоже будет в кэше высока, потому запрос будет только к authoritative самого cloudfront.

Много текста. Какой вывод?
🍒 Чем меньше сабдоменов тем лучше, если делать CDN для статики только, то лучше на отдельный домен его повесить чем на сабдомен.
🍉 Свои NS сервера или сервера третьесортного хостера хуже чем Route53, Cloudflare, OpenDNS и т.п.
🥝 Клепать для дистрибьюции отдельно сабдомены для изображений, css, js - глупость, разные самбдомены для шардирования тоже.
🍓 Свои системы лучше настривать чтобы NS сервера были гугловыми или Cloudflare. Меньше лишних звеньев в цепи.
🍏 Учитывая что у многих пользователей вбиты NS от Google или Cloudflare, то выгоднее с точки зрения минимизации latency лучше использовать их. Для этих пользователей будет резолвится супер быстро.

Сделать взвешенный выбор поможет https://www.dnsperf.com/, но энивей в синтетике победитель Cloudflare, с чем его и поздравляем. О том как подходят большие пацаны в борьбе с latency в резолве будет в следующих постах.
👍 45
🦀 6
Читать полностью
noTieinIT 11 Jul, 19:01
​​🚀 Network performance: уменьшение latency через CDN

До того как перейдем к техническим деталям оптимизаций TCP скину самый дешевый вариант ускорения отдачи. Речь пойдет о Content Delivery Network (CDN).

Можно хранить, обрабатывать и отдавать всю информацию напрямую с хостинга (датацентра, облака и т.п.) где размещается сайт. Независимо от того 1 гигабайт в день отдается или 1000 гигабайт, проблема со скоростью загрузки страниц, скорость ответа ajax запросов и скорости загрузки изображений/статики остается. Если страницы грузятся долго, то пользователь уходит.

Дабы ускорить время отдачи используют кэширование и CDN. CDN - это сеть по раздаче контента, которая состоит из множества точек присутствия (PoP, Point of Presence), а в точках присутствия множество Edge серверов, для целей масштабирования. CDN настраивается с указанием сервера откуда брать данные (например, хостинг с сайтом) и этот сервер называется Origin сервером.

Ранее я обьяснял почему для протокола TCP (HTTP и HTTPS особенно) критично расстояние от пользователя до сервера к которому происходит подключение. CDN решает проблему latency благодаря близости к пользователю запрашивающего контент этих самых PoP. Чем ближе тем быстрее. "Воу, а если edge находится далеко от origin, то ему все равно надо делать handshake и это те же временные затраты", - скажет внимательный читатель. Эта проблема решается путем установки соединений и поддержании соединений между Edge и Origin, потому когда пользователь запрашивает с Edge данные требующего обращения на Origin, то запрос пойдет по уже установленному соединению и время ответа в лучшем случае будет равно 1 RTT.

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

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

CDN решений валом у клауд провайдеров, у того же Google Cloud, Amazon и т.п. Если ваш проект находится в клауде, то убедитесь что вы настроили отдачу через CDN этого клауда. Если отдача данных с Amazon S3, то проверьте не ходит ли напрямую пользователь на S3. Подключение CDN точное не будет дороже (для облака!), зато даст прирост производительности.

Итого, что имеем? В приведенном ранее примере с юзером в Далласе и сервером в Амстердаме можно ускорить время ответа с 450-460ms до 240-250ms. С кэшированием вплоть до 20-30ms.
👍 43
🦀 1
Читать полностью
noTieinIT 3 Jul, 10:49
🗣 Network performance: замеры ping’ов

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

Я использовал https://wondernetwork.com/pings. Этот сервис в real time из разных локаций пингует пул серверов, анализирует данные и позволяет получить примерное представление о задержках. Он считает минимальные и максимальные значения, а также среднеквадратические отклонения.

У реальных пользователей история будет другая ибо есть фактор последней мили. Но это уже другая история. Пишите боту свои вопросы!
👍 38
🦀 1
Читать полностью
noTieinIT 1 Jul, 15:07
​​🐢 Network performance: latency c TCP+TLS (HTTPS)

Для установки TCP соединения потребуется 3-way handshake. Одно лишь время на установку соединения и получения первого байта ответа может превысить 500-600мс для самых отдаленных уголков планеты. Тот же протокол HTTP, который является базовым для всего современного веба, работает поверх протокола TCP, потому загрузка контента по HTTP зависит от расстояния между клиентом и сервером и от потерь на канале.

Для защищенного протокола HTTPS latency еще больше. HTTPS является расширением протокола HTTP и тоже работает поверх TCP. Если же по протоколу HTTP данные ходят в незашифрованном виде и могут быть перехвачены, то в HTTPS данные отправляются в зашифрованном виде и перехват трафика не позволит увидеть передаваемые данные, например, пароли. Это достигается путем использования протокола TLS.

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

Только вот не дается это бесплатно и за безопасность платим latency. При скачивании файлов по HTTPS тоже потребуется установить TCP handshake, а затем установить и безопасное соединение произведя TLS handshake который требует аж 8 операций обмена данными. Возьмем реальные данные из прошлой публикации и подсчитаем минимальное количество времени что уйдет от момента запроса до момента получения данных… 900-910мс!

Для клиента из Далласа (США) запрашивающего контент из датацентра в Амстердаме на получение первого байта ответа потребуется:
🔸минимум 450-460ms для загрузки по HTTP;
🔸минимум 900-910ms для загрузки по HTTPS.

Как видно, это очень дорогая операция. Напомню, что по статистике половина пользователей ожидает загрузки сайта менее чем за 2 секунды, а мы минимум 0.9 секунды тратим на установку соединения. Представьте что еще стоит редирект и делается повторное соединение и еще +0.9 секунды… Но пути оптимизации существуют и я расскажу как уменьшить latency и сделать пользователей счастливее. Stay tuned!
👍 86
🦀
Читать полностью
noTieinIT 27 Jun, 14:07
​​Network performance: latency в TCP

На базе протокола TCP работает множество протоколов более высокого уровня: HTTP, HTTPS, Websocket, SMTP, POP3, IMAP, всякие самодельные и велосипедные протоколы. Большая часть современного веба построена на базе протокола TCP. В TCP в отличии от UDP требует установки соединения. Прежде чем поговорить о плюсах и минусах стоит углубиться в процедуру установки соединения, дьявол в деталях...

И так, у нас есть клиент что желает получить информацию с сервера, например, браузер хочет загрузить страницу вебсайта по HTTP. Клиент подключается по протоколу TCP к серверу. Установка соединения начинается с отправки клиентом пакета с флагом SYN (специальный флаг для индикации что это новое соединение). Затем сервер отправляет пакет с флагом SYN+ACK клиенту обратно. Вместе с этими двумя пакетами передаются еще флаги для настройки взаимодействия, чексума, номера портов. etc. После получения SYN+ACK клиент отправляет пакет с флагом ACK, который является последним звеном в handshake между клиентом и сервером. Вместе с третим пакетом можно отправлять данные. Пакеты ограничены по размеру и весь запрос и ответ может не уместиться в один пакет и тогда придется отправить больше пакетов.

В итоге, пока клиент ждет SYN+ACK никакого обмена информацией не происходит. Помните про Hibernia Express с их супербыстрым оптоволокном? Вот в той сети между Нью-Йорком и Лондоном round trip time (RTT) составляет 55ms, в один конец это 27.5ms, половина RTT. Даже с таким низким latency до момента получения ответа от сервера, если он отвечает моментально, потребуется 110ms. Для клиента из Далласа (США) до сервера в датацентре в Амстердаме требуется минимум 450-460ms на получение первого байта ответа.

Когда соединение уже установлено и используется повторно, то можно сэкономить и вместо 450-460ms обменяться данными за 1 RTT, т.е. 226ms.

Но это все идеальные сценарии. В реалиях все еще хуже...
👍 77
🦀 3
Читать полностью
noTieinIT 20 Jun, 14:07
​​✈️ Network performance: latency в UDP

В прошлой публикации разобрали что есть физические ограничения по latency ниже которых прыгнуть не получится и скорость света выступает ограничителем. Время обмена данными между узлами сети зависит еще и от протокола. В сетевой модели TCP/IP два самых распространенных протокола - это TCP и UDP. Протоколы не что иное как набор соглашений по обмену данными. Основное отличие у TCP и UDP заключается в гарантировании доставки данных и последовательности получения пакетов.

У UDP есть два основных минуса:
🔸 Отправитель не получает никакого подтверждения доставки. Если на стороне получателя пакеты не слушаются, то они пропадут так и не будучи обработанными.
🔸 Порядок тоже не гарантируется, потому отправитель может отправить сообщения в одном порядке, допустим, {A, B, C}, а получатель получит {B, C, A}. Может вовсе получить {B, A}, а C пропадет.

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

Так что если линия связи позволит доставить пакет за 59мс, то он и будет доставлен за это время.
На базе UDP строятся высокоуровневые протоколы, например, DNS (определение IP адреса по имени хоста/домену), NTP (синхронизация времени), VPN. Фактически все peer-to-peer видеочаты, звонки (telegram, viber, whatsapp) используют UDP.

За мою карьеру накопилось много примеров и фейлов связанных с UDP и реально крутого применения. Чтобы было понятно и интересно я сперва пройдусь по TCP и тогда казусов связанных с особенностями работы протоколов станет больше. Про TCP будет дальше. Свои предложения, пожелания, обратную связь вида "интересно", "не интересно", "расскажи об этом лучше" пишите в @noTieInIT_bot.
👍 144
🦀 3
Читать полностью
noTieinIT 29 May, 13:37
​​🚀 Network latency: снижение задержки на 5ms за $300m

Влияние скорости ответа сайтов и сервисов на доходность бизнеса порой крайне велика. Для крупного бизнеса это хорошо измеримо. Меня больше всего удивил кейс о котором пойдет речь сегодня.

Базовым ограничением в скорости передачи информации является скорость света. Как не крути, а быстрее скорости света доставить не получится. 10000 километров фотон, он же свет в простонародье, преодолеет за 33 миллисекунды. При передачи информации оптоволокном как раз используется передача фотонов, но при передаче по оптоволокну скорость снижается. Примерно до 50мс на 10000 км.

В конце 2015 года был запущен линк Hibernia Express между Канадой и UK. Он проходит через океан, имеет длину в 4600км. От Канады линк тянется до Нью-Йорка и общая задержка в передаче данных между Нью-Йорком и Лондоном составила 59мс (суммарное расстояние . Это на 5мс быстрее чем было возможно достичь ранее и на выигрыш в 5мс было потрачено более 300 миллионов долларов.

Пока что локомотивом выступают трейдеры: в Нью-Йорке и Лондоне находятся одни из крупнейших фондовых бирж мира. Те компании что на 5мс раньше получают информацию об изменении котировок получают преимущество на миллионы долларов. За эти миллисекунды и платят 💸.

В следующей публикации поговорим о выборе датацентра и поставщика каналов. А чтобы не скучали вот карта с задержками сети GTT, одной из крупнейших.
👍 39
🦀 5
Читать полностью
noTieinIT 20 May, 15:52
​​Вот уже несколько лет я и команда ведем борьбу за время загрузки страниц, время ответа сервисов и время реакции приложений. В современном мире наличие задержек крайне негативно влияет на доходы бизнеса: поисковые системы учитывают время ответа при ранжировании сайтов, пользователи с большей вероятностью уходят. По этой причине постоянно пытаюсь бороться с задержками.

Исследования и факты:
1) Google установил, что 53% пользователей мобильных устройств закроют вкладку если страница загружается дольше 3 секунд.
2) С июля 2018 Google в формуле ранжирования поисковой выдачи для мобильных учитывает скорость.
2) Amazon теряет по 1% продаж при увеличении времени ответа на каждые 100ms.
3) Более 52% от всего количества загружаемых страниц по всему миру приходится на мобильные устройства.
4) Исследование Akamai показало падение конверсии на 7% при увеличении времени ответа на 100ms. Задержка в 2 секунды срежет конверсию в два раза.
5) 47% респондентов ожидают что сайт должен загружаться быстрее 2 секунд, а 85% уверены что мобильные сайты должны грузиться быстрее десктопных версий.
6) У Yahoo ускорение сайта в 400ms увеличило трафик на 9%. Источник.
7) Mozilla понизив время загрузки ниже 2.2s увеличила количество загрузок на 15.4%.

В бизнесе везде есть trade off в принимаемых решениях и стоит применять холодный расчет, отбросив желание все оптимизировать. Если страница загружается за 7 секунд, то ускорив ее до 4 секунд можно получить рост конверсии. Но эти 3 секунды могут стоить тысячи и десятки тысяч долларов затрат на разработку или работу администраторов/девопсов. Бизнес всегда считает окупит ли он затраты на улучшения путем роста конверсии и когда.

Все же решили ускорят продукт? Тогда стоит определить какие оптимизации принесут максимум выгоды. Минимум затрат за максимум результата. Помочь в определении узких мест может Google PageSpeed Insights. Когда улучшать уже нечего и скорость загрузки упирается в скорость ответа сервера, то пора оптимизировать backend.

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

Но есть еще отдельная область для ускорения которую анализаторы не учитывают, но для сайтов работающих на разных континентах это крайне важно. Речь о network latency и ограничениях протокола TCP и HTTPS. При наличии нескольких балансировщиков нагрузки с динамической сменой IP адресов веб-серверов ситуация очень усугубляется. За последние месяцы была проделана огромная работа и результатами буду делиться в дальнейших публикациях.

@noTieInIT
👍 65
🦀 6
Читать полностью
noTieinIT 15 May, 16:28
#токсичность и #культура

Те кто родился 25-40 лет назад являются представителями сложного поколения. Думаю среди моей аудитории таких большинство, да и я сам отношусь в этой группе. Мы пережили смену строя, видели как становимся никому не нужными, брошенные на произвол.

Система воспитания времен СССР предполагала взращивание таких ценностей как честность, порядочность, бескорыстность, забота и уважение к окружающим. При этом еще со времен СССР присутствовала соревновательность на работе, в учебе, но с набором перечисленных ценностей это был некий fair play. Общество порицало жесткое, надменное и доминантное общение. Все стремились помочь друг другу, но соревновались против других отделов, но по правилам.

На смену этим ценностям в 90-е пришли более эгоистичные: личная выгода, независимость, беспринципность. Мы видели как убивали за власть и деньги, как силовыми методами решали вопросы. Кто-то не выдержал, сдался, спился и сторчался, средняя прослойка просто живет, а вот пласт успешных людей, способных людей, адаптировались к условиям и эгоистов с эгоцентристами среди них огромное количество. Их всегда больше среди успешных. Эти люди действуют по принципу "победи или умри", это те кто не сломались и доказали остальным что они чего-то стоят, что они лучше других. Мы и дальше продолжаем доказывать всем вокруг что способны на большее...

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

А теперь помните почему я говорил в самом начале что этот тренд в США набрал обороты? В США потерянное поколение лет на 10 старше чем в СНГ, там прослойка людей в возрасте 25-30 лет уже не застала сложный период, с ними работать нужно по другому, у них другие ценности уже. Другие ценности будут и у нас, нам придется подстроится под поколение Z и поменять риторику через несколько лет, но не сейчас. Еще есть время подготовится.

@noTieInIT
👍 67
🦀 16
Читать полностью
noTieinIT 25 Apr, 19:05

В прошлой публикации цикла #культура и #токсичность зашли со стороны заболеваний что могут трактоваться как проявления токсичного поведения. Сегодня речь пойдет о типах личности и их особенностях. Вникнув в суть вы будете лучше понимать как работать с людьми в вашей команде. Ведь понимание друг друга - это первый шаг к успешному бизнесу! А за этим следует все остальное.

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

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

Психотип человека в основах – это всем известные понятия: экстраверты и интроверты, малоизвестные амбиверты. Есть и подтипы.

Готовы к лонг риду по психологи? Поехали! https://telegra.ph/noTieInIT---tipy-temperamenta-04-25

@noTieInIT
noTieInIT - типы темперамента
https://t.me/noTieInIT Экстраверт – это не просто коммуникабельный человек, он питается энергией коммуницируя с разнообразными людьми. Интроверт же, считает, что коммуникация с большим количеством людей – отбирает его энергию и считает это пустой тратой времени. Амбиверт – это некая субстанция предыдущих двух типов. Они могут переключаться, меняя роли. Многие допускают ошибку, предполагая, что интроверты противоположность экстравертам и наоборот. Интроверты просто генерируют свой досуг самостоятельно, их психика…
👍 26
🦀 9
Читать полностью
noTieinIT 22 Apr, 10:14
​​В предыдущей публикации цикла о токсичности и культуре я заспойлерил красную нить цикла. Для того чтобы двигаться дальше и пройти путь осознания происходящего придется вникнуть в природу человеческого поведения.

Такого термина как токсичность не существует в литературе по психологии, термин отсутствует в классификации МКБ-10. Термин “токсичность” - это чистый маркетинг, создание собирательного образа из черт личностей, этапов развития личностей и особенностей темпераментов, иногда под критерии токсичности попадают симптомы заболеваний. Итого, под “токсичность” можно подвести вообще все что угодно.

Я составил список что зарубежные коллеги относят к признакам токсичности. Советую читать до конца и не пугаться терминов. Может узнаете кого из своего окружения. 😂

Токсичные люди:
🔸не хотят нести ответственность за свои чувства и эмоции;
🔸критикуют других людей и не признают своих ошибок;
🔸кричат или проявляют насилие, бьют посуду, кидаются вещами;
🔸подчеркивающих свое превосходство;
🔸соперничают с другими людьми;
🔸считают что виноваты во всем происходящем не они, а всегда другие люди или природа;
🔸спорят с мнением других людей;
🔸клевещут на других людей;
🔸не извиняются даже если не правы;
🔸перебивают собеседника в разговоре, уводят разговор в другое русло преследуя свои цели;
🔸пессимисты и негативщики (ааа, мы все умрем);
🔸вынуждают других людей им что-то доказывать и жертвовать интересами (других людей) ради своих интересов и целей;
🔸мало интересуются заботит участь других людей;
🔸вынуждают думать людей что те виноваты в бедах “токсика” и чувствовать вину за это.

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

Теперь давайте зайдем с другой стороны и поговорим про расстройства личностей. Кстати, знаете какое определение “расстройства личности” дает American Psychiatric Association? Расстройство личности - это способ мышления, проявления чувств и поведения отличный от принятых культурно (в социуме), вызывается расстройства или проблемы в функционировании и длится с течением времени. Что это означает? Если дети еще 20-30 лет назад развлекались привязывая кошкам консервные банки к хвосту и социум считал это приемлемой забавой, то дети были в приниципе-то нормальными. Сейчас же социум поменялся и попробуй выкини такую шутейку… сразу к психологам запрут или, и того хуже, к психиатрам. Настолько манипулятивно само понятие “нормальности”.

Cписок расстройств личности я вынес 📎 в отдельный пост (ниже ссылка), напомню, эти расстройства официально признаны заболеваниями и подлежат лечению, иногда медикаментозному. Если у “токсичного” человека проявляются симптомы заболевания, то введение культуры компании или введение запретов абсолютно не поможет человеку. Если менеджмент действительно желает помочь, то стоит учитывать менеджменту и коллективу особенности некоторых людей и пытаться вместе их преодолевать. На просторах СНГ, конечно, таким если и будут заниматься, то единицы, ведь проще уволить чем решать проблему. Ну и заодно пакет “Культура в компании 2.0 для чайников” у коучей заказать. Читая мою краткую сводку симптомов расстройств советую сравнивать с теми критериями токсичности что я упоминал выше.

📎 https://telegra.ph/noTieInIT---tokischnye-lyudi-i-rasstrojstva-lichnosti-04-22

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

@noTieInIT
Читать полностью
noTieinIT 17 Apr, 09:27
​​Цикл про токсичность и культуру зашел! Мне много людей писало в личку, некоторые даже успели заметить и воспользоваться свеженьким ботом @noTieInIT_bot (да-да, отныне обратную связь можно давать через хелпдеск бота). Из сообщений понятно, что внедрение культуры происходит прямо сейчас. Двигаемся дальше!

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

За это время комитеты ECMAScript хорошо потрудились, разработчики браузеров добавили множество крутых фич. Да вот индустрия не поспевает. Жаль что комитеты по архитектуре проектов на ECMAScript не созданы. Как следствие появляется множество проектов что становятся хайповыми, инструменты и библиотеки ставятся во главе угла, а архитектура отодвигается на второй план. Но ведь самое важное - это архитектура. Не фичи библиотеки, не холивар по выбору high order components против render props. Это всё менее важно чем архитектура. Она как раз позволяет переживать взлеты и падения библиотек и инструментов.

С образованием тоже беда. Толики полезной информации вытесняются потоком малополезной, побеждают маркетологи. Группы я читать не успеваю, да и глубинные проблемы разбирают там редко. Разбираемые проблемы таких групп ограничиваются нежеланием прочесть страницу документации. С новостями и отбором публикаций благо помогает habr/medium. Вопросы архитектуры периодически обсуждаем в группе @aofclub где разбираются проблемы архитектуры и особенности технологий. Иногда рассылки javascript weekly помогают, но проплаченного материала много, а качество со временем упало. Если у вас есть рекомендации качественного контента по архитектуре фронтенда - просьба писать боту @noTieInIT_bot.

Резюмирую. Уделяйте больше внимание архитектуре приложений, акцентируйте усилия на продумывании именно архитектуры. Библиотеки рождаются и умирают, как сверхновые, а архитектура и черные дыры остаются. В следующих публикациях по фронтенду будет инфа как мы приложение на SPA переписываем.
👍 38
🦀 1
Читать полностью
noTieinIT 15 Apr, 09:42
​​Слова “#культура” и “#токсичность” нынче слышна из каждого утюга.

Вы видели правила комьюнити на stackoverflow, самого крупного ресурса для обмена знаниями? Допустим, Петя постит кусок кода и спрашивает:
- Почему этот код не работает?
А Коля ему отвечает в духе: “Эй, друг, запусти дебагер и он тебе поможет!”.

По меркам комьюнити, Коля будет токсичным. Комьюнити хочет чтобы Коля работающий код написал, объяснил в чем была ошибка и еще статей на будущее накидал, предложил в любое время дня и ночи сопровождать свой код. Непонятно, надо ли еще на мостик становится?

А обратная связь? Если тимлид делает ревью, видит очевидную ошибку которая бы вылезла при первом запуске, а затем пишет: “Ты вообще проверял этот код?”, то это тоже попадает под определение токсичности. Эксперты по культуре говорят, что стоило написать: “Женя, ты такой молодец и такой крутой код написал, мне кажется тут маленькая проблемка есть, обрати внимание. Но ты хорошо постарался! Молодец!”. Ну да, молодец, код-то даже не запускается. Деньги компании тратятся, время тимлида тратится, тайм трекер крутится, лавэха мутится…

“Дайте людям делать ошибки! Нельзя за ошибки наказывать, иначе у людей мотивация пропадет проявлять творчество...”, - советуют коучи. Серьезно? Какой универсальный рецепт. Давайте применим в авиации. Хотя минуточку… Boeing часом не внедрил безопасную среду для экспериментов, поисков себя и внедрения инноваций? И вправду, больная тема: я вообще стараюсь не думать как писали и тестировали код систем от которых зависит моя жизнь и безопасность.

Знакомые ситуации? Бывали на позиции Пети или Коли, тимлида или Жени? А знаете почему корпорации озаботились понятием культуры? Для кого придумали детокс программы коучи и зачем? А всегда ли это нужно? И так, новый цикл на @noTieInIT о токсичности и культуре!

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

Не переключайтесь! @noTieInIT
Читать полностью
noTieinIT 9 Apr, 08:19
Стоит ли разделить контент по каналам?
Опрос
  • Бизнес и технологии с техничкой в одном канале
  • Техничку оставить в "Об IT без галстуков" и бизнес в отдельный канал
  • На канале "Об IT без галстуков" про бизнес, а техничку вынести в отдельный канал
269 голосов
noTieinIT 9 Apr, 08:18
​​Дорогие читатели! Почти год тишины был на канале. Увы, повлиять на причины этого я не мог. Каждый день этого молчания я думал о том кредите доверия что выдал мне каждый из вас и об ответственности которую я взял начав этот путь.

Сегодня этот лист переворачивается и начинается новый виток развития канала и контента.

Хочу поделиться планами и вектором дальнейшего движения, помимо основной тематики канала:
? финализирую про биткоин и дальше будет цикл про то как организовывается процессинг кредитных карт, альтернативные методы оплаты;
? рассуждения на тему современного финансового мира и материалы по организационным моментам современного технологического бизнеса, например, юрисдикции где стоит начинать, какие рынки есть, какие правила игры сейчас и куда идти не стоит;
? начну цикл для бизнеса о разнице взглядов предпринимателей и технарей на ведения бизнеса и разработку продуктов;

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

Поскольку направленность контента разная, то решил вынести на обсуждение возможность разделения контента по каналам. Прошу помочь вас и высказать свое мнение в голосовании ниже.
Читать полностью
noTieinIT 11 Jul 2018, 19:30
#техничка

Занимательная статистика проскочила на канале @devopsengineer.

Существует некий сервис Intricately, который позволяет давать insights по использованию облачных сервисов для своих пользователей. Этот сервис прогнозирует, что Netflix тратит в месяц $40M на облачные сервисы, в частности, на Amazon EC2 - $19M, ELB - $3M, CloudFront - $1M. Странно, конечно, что для Netflix расходы на доставку видео на порядок ниже затрат на сервера.

Что-то здесь не так… Все дело в методологию расчета. Intricately заявляет, что у них во многих датацентрах и провайдерах есть точки присутствия в виде агентов снимающих показатели по протекаемому трафику с маршрутизаторов. Наблюдая за потоками трафика невозможно достоверно определить что находится внутри самой облачной инфраструктуры. Откуда же тогда информация про потребление данных между Amazon CloudFront и S3/EC2? О количестве хостов? Обьеме данных на S3? Сам Amazon продает эти данные third party компаниям? Или сервис работает по принципу "пальцем в небо"?
👍 11
🦀 14
Читать полностью
noTieinIT 10 Apr 2018, 15:59
Сегодня важный день. Было опубликовано мое первое интервью в нетехническом СМИ и я запустил новый проект. Огорчает только то, что это все произошло при неприятных событиях. Латвийский Rietumu банк, фактически, обвинил меня в отмывании средств и финансировании терроризма, заблокировав счета моей компании.

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

Но я не сдаюсь и создал ресурс We Are Not Shell для обьединения усилий пострадавших. Там же есть и моя история со скриншотами переписки. Я прошу вашей помощи. Подробности публикую еще и в http://telegra.ph/Bezzakonie-bankov-ES-04-10. Для общения в рамках инициативы создана группа в telegram.

Искренне прошу помощи в распространении информации, волонтерстве и консультациях.
👍 22
🦀 3
Читать полностью
noTieinIT 28 Mar 2018, 21:08
​​#техничка

Сегодня я хочу поделиться своей первой технической статьей на этом канале. Когда я начал переносить docker контейнеры с centos 6 на centos 7, то столкнулся с ошибками в приложении связанными с resolve IP адресов вебсервером (nginx). Вопреки ожиданиям, хостнейм в upstream nginx резолвился в IPv4 и IPv6 адреса, а этого не ожидал сам сервис: он слушал только IPv4. Но фишка в том, что host, dig и т.п. определяли только IPv4 адрес, а IPv6 не было в списке. В /etc/hosts тоже не было информации. Это вынудило меня провести детальное исследование с результатами которого и делюсь.

Из статьи вы узнаете:
1️⃣ какой алгоритм в Linux для резолва хостнеймов;
2️⃣ как переопределить логику определения хостнеймов;
3️⃣ какие функции и библиотеки использует ОС;
4️⃣ какие ловушки существуют при конфигурировании и как их не допускать.

https://dmenshikov.com/2018-03-16-hostname-resolving-on-linux/
👍 42
🦀 10
Читать полностью
noTieinIT 19 Mar 2018, 15:30
​​#статистика

Stackoverflow опубликовала отчет с результатами опроса среди разработчиков за 2018 год. В обзоре я выделил основные вещи: какие языки наиболее популярны, какие угасают и на что будут мигрировать разработчики в ближайшие годы, какие хранлища и ОС популярны. Самое неожиданное - это рост популярности Python. Самое значимое - любовь к Rust и желание выучить JavaScript. Node.js в топе по популярности среди фреймворков, а самый любимый - TensorFlow. Среди РСУБД растет популрность PostgreSQL, а MySQL теряет позиции. MongoDB лидирующая среи нереляционных хранилищ.

Детали - http://telegra.ph/Rezultaty-oprosa-stackoverflow-sredi-razrabotchikov-03-19

@notieInIT
👍 43
🦀 7
Читать полностью