Говорят, что нельзя полностью понять систему, пока не поймёшь её сбои. Ещё будучи студентом я ради забавы написал реализацию TCP, а потом несколько лет проработал в IT, но до сих пор продолжаю глубже и глубже изучать работу TCP — и его ошибки. Самое удивительное, что некоторые из этих ошибок проявляются в базовых вещах. И они неочевидны. В этой статье я преподнесу их как головоломки, в стиле Car Talk или старых головоломок Java. Как и любые другие хорошие головоломки, их очень просто воспроизвести, но решения обычно удивляют. И вместо того, чтобы фокусировать наше внимание на загадочных подробностях, эти головоломки помогают изучить некоторые глубинные принципы работы TCP.

Обо мне

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

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

Во Вселенной работает довольно жестокий вид кармы.

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

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

Акронис на прошлой неделе попросил меня рассказать про опыт на Хабре. После семинара я обещал выложить основные тезисы. Возможно, вы найдёте что-то полезное ниже.

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

При этом активных (голосующих) пользователей всего около 3 тысяч. Уровень знаний аудитории на входе в пост — в примерно 95% случаев низкий, в 5% — экспертный (разбиение оценочное). Проще говоря, есть люди, которые вообще не понимают, что вы хотите сказать (и их большинство), и есть те, кто разбирается в теме на голову лучше вас. Поэтому лучший пост — это тот, что проходит от ликбеза к хардкору. На площадке довольно высокий уровень агрессии (точнее, желания проверить материал на прочность). Ранее был экстремально высок. Средняя или низкая внимательность читателя (ранее была высокая).

Разумеется, это всё моё личное мнение, и можно поспорить. Сейчас постараюсь объяснить, почему я так считаю, и как это влияет на посты. Я основываюсь на опыте примерно 1500 постов за 6 лет, которые написал сам или помогал готовить.

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


^{Данные тут на конец августа, я их к другому семинару (в Хабре для владельцев блогов) готовил.}

В этой статье мы поговорим об ошибках, совершаемых программистами на Bash. Во всех приведённых примерах есть какие-то изъяны. Вам удастся избежать многих из нижеописанных ошибок, если вы всегда будете использовать кавычки и никогда не будете использовать разбиение на слова (wordsplitting)! Разбиение на слова — это ущербная легаси-практика, унаследованная из оболочки Bourne. Она применяется по умолчанию, если вы не заключаете подстановки (expansions) в кавычки. В общем, подавляющее большинство подводных камней так или иначе связаны с подстановкой без кавычек, что приводит к разбиению на слова и глоббингу (globbing) получившегося результата.

PHP имеет всего одну структуру данных для управления всем. array — сложный, гибкий, гибридный, сочетает в себе поведение list и linked map. Но мы используем его для всего, потому что PHP придерживается прагматичного подхода: иметь предельно правильный, здравый и реалистичный способ решения проблемы, исходящий из практических, а не теоретических рассуждений. array позволяет делать работу, хотя о нем и так много рассказывают на лекциях по информатике. Но, к сожалению, с гибкостью приходит и сложность.

Последний релиз PHP вызвал большое оживление в сообществе. Мы не могли дождаться того, чтобы начать использовать новые возможности и почувствовать вкус ~2х прироста производительности. Одна из причин, почему это случилось — структура array была переработана. Но массивы все также придерживаются принципа «оптимизировано для всего; оптимизировано для ничего», еще не все идеально, есть возможности для совершенствования.

А что насчет структур данных SPL?

К сожалению… они ужасны. Раньше, до PHP7, они предлагали _некоторые_ преимущества, но сейчас мы дошли до точки, когда использование SPL не имеет практического смысла.

Почему мы не можем просто поправить и улучшить их?

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

«SPL data structures are horribly designed.»
— Anthony Ferrara

---

Введение: php-ds — расширение для PHP7, добавляющее структуры данных. Этот пост кратко охватывает поведение, производительность и преимущества каждой из них. Также в конце вы найдете список ответов на ожидаемые вопросы.

Github: https://github.com/php-ds
Пространство имен: Ds\
Интерфейсы: Collection, Sequence, Hashable
Классы: Vector, Deque, Stack, Queue, PriorityQueue, Map, Set

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



В статье ниже я рассмотрю концепцию “обучения во взаимодействии” на примере абстрактной web-системы. Данный подход хорошо можно объяснить примером из современного игрового мира. Сначала вы проходите tutorial. Вам на плечи не вешают сразу килотонны обучающего материала. Вас ведут по ранней стадии игры, в нужное время выдавая подсказки. Например, при первом взаимодействии с новым объектом игры. Накапливается положительный опыт. Вы обучаетесь взаимодействовать. Рискну предположить, что скорее всего Вы считаете себя продвинутым пользователем, когда речь касается приложений. Как и большинство из них вы мгновенно жмёте на кнопку “Пропустить” / “Приступить к работе” …

Кажется, не проходит и дня, чтобы на Хабре не появлялись посты о нейронных сетях. Они сделали машинное обучение доступным не только большим компаниям, но и любому человеку, который умеет программировать. Несмотря на то, что всем кажется, будто о нейросетях уже всем все известно, мы решили поделиться обзорной лекцией, прочитанной в рамках Малого ШАДа, рассчитанного на старшеклассников с сильной математической подготовкой.

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



Константин klakhman Лахман закончил МИФИ, работал исследователем в отделе нейронаук НИЦ «Курчатовский институт». В Яндексе занимается нейросетевыми технологиями, используемыми в компьютерном зрении.

Под катом — подробная расшифровка со слайдами.

За прошедшие почти 10 месяцев с релиза 1.0.0 была очень большая работа по улучшению программы.

Из основных изменений стоит отметить следующие:

• Возможность выявлять самые популярные виды атак: syn_flood, icmp_flood, udp_flood, ip_fragmentation_flood
• Добавление поддержки протокола Netflow, поддерживаются 5, 9 и 10 (IPFIX) версии
• Добавление поддержки протокола sFLOW v5, который поддерживается большинством современных сетевых коммутаторов
• Добавлена поддержка использования netmap (поддерживаются Linux и FreeBSD, для Linux предоставляется специальная версия драйвера ixgbe: github.com/pavel-odintsov/ixgbe-linux-netmap) для захвата пакетов. Данный режим обеспечивает наивысшую производительность захвата трафика наряду с PF_RING ZC.
• Добавлена поддержка PF_RING ZC (к сожалению, этот режим требует отдельной лицензии на библиотеку PF_RING)

Давным давно, в начале 1989 года, Рональд Рейган ещё был президентом, хотя до окончания его срока оставалось 19½ дней. А перед тем, как 1989 год подошел к концу, родилась Тейлор Свифт, а Андрей Сахаров и Сэмюэл Беккет скончались.

В долгосрочной перспективе, наиболее значительным событием 1989 скорее всего станет то, что Тим Бернерс-Ли заложил основы протокола HTTP и назвал результат «World Wide Web». (Одно примечательное свойство этого имени состоит в том, что аббревиатура «WWW» имеет в два раза больше слогов и требует больше времени для произнесения.)

Протокол HTTP, предложенный Тимом, работал в 10-мегабитных сетях с коаксиальными кабелями, а его компьютером был NeXT Cube с частотой 25 МГц. 26 лет спустя, в моем ноутбуке установлен процессор в сотни раз быстрее, а оперативной памяти в тысячи раз больше, чем было на компьютере Тима, но протокол HTTP всё тот же.

Несколько дней назад рабочая группа IESG (The Internet Engineering Steering Group) запросила последние комментарии по новому протоколу HTTP/2.0 (https://tools.ietf.org/id/draft-ietf-httpbis-http2) перед тем, как утвердить его в качестве официального стандарта.

[Спустя пару месяцев с минимальными изменениями стандарт был утвержден. — прим. пер.]

Часто клиенты спрашивают нас о p99-метрике (99-й перцентиль).

Это определенно разумная просьба и мы планируем добавить подобную функциональность в VividCortex (об этом расскажу позже). Но в то же время, когда клиенты спрашивают об этом, они подразумевают нечто совершенно определенное — нечто, что может быть проблемой. Они просят не 99-й перцентиль по какой-то метрике, они просят метрику по 99-му перцентилю. Это обычное дело для таких систем как Graphite, но все это дает не тот результат, который от таких систем ожидается. Это пост расскажет вам о том, что, возможно, у вас неверные представления про перцентили, о точной степени ваших заблуждений и о том, что вы все таки можете сделать правильно в этом случае.

(Это перевод статьи которую написал Baron Schwartz.)

Всем привет! Меня зовут Сергей Татаринцев. В Яндексе я работаю в группе разработки общих интерфейсов. Наша группа занимается созданием интерфейсных библиотек, используемых во многих сервисах, — в том числе в Поиске. Мы поддерживаем четыре библиотеки, которые в общей сложности включают в себя 62 блока.

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



Мы решили, что дальше так жить нельзя и решили процесс тестирования как-то автоматизировать. Начали мы с инструментов статического анализа. Для проверки стиля кода у нас используется инструмент jscs, написанный нашим коллегой Маратом Дулиным. Для статического анализа кода применяется всем известный JSHint. А для отлова регрессий в JS мы пишем юнит-тесты. Это в какой-то мере помогло справиться с проблемой: анализаторы отлавливали совсем уж глупые ошибки, а тесты позволили проверять функциональность блока. А вот с регрессиями в CSS был пробел. Тестирование внешнего вида по-прежнему проводилось руками и глазами тестировщика. Мы стали искать инструменты, которые помогали бы нам в автоматизации.

Так сложилось, что последние полгода я активно занимался тестами производительности и мне кажется, что в этой области IT царит абсолютное непонимание происходящего. В наше время, когда рост вычислительных мощностей снизился (vertical scalability), а объем задач растет с прежней скоростью, проблема производительности становится всё острее. Но прежде, чем броситься на борьбу с производительностью, необходимо получить количественную характеристику.

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

• Простейший тест: способы измерения теста, выбор статистики (квантили, медиана, среднее).
• Параметризованный тест: оценка сложности алгоритма, применения МНК к оценки линейности теста.
• Тесты на многоядерных машинах: сложность экстраполяции результатов тестов на многоядерные машины, закон Амдала и целесообразность измерений.
• Поведенческий тест: каким, при заданной модели поведения пользователей, будет время ожидание запроса и что может привести к коллапсу системы. Пропускная способность (throughput) и как его считать.
• Удивительное статическое распределение результатов performance теста.

Перевод статьи LOSING LOOSE COUPLING

Когда меня просят присутствовать на собеседованиях, я обычно задаю один вопрос кандидату: «Что такое хороший код?». Тревожит, что часто можно услышать от недавних выпускников: «Наличие хороших комментариев». Это неправильный ответ. Кто учит их этому? Пугающе. Но я отвлекся… Не думаю, что есть правильный ответ на мой вопрос, однако я бы принял что-нибудь вроде «сильное сцепление (high cohesion) и слабая связанность (loose coupling)». По крайней мере это что-то говорит о коде. Но если это собеседование Java разработчика, я не дам бедняге уйти без нескольких дополнительных вопросов. Потому что Java разработчики полностью обезумели. Они одержимы желанием порубить код на супер-пупер мелкие кусочки. Мы рубим и рубим до тех пор, пока практически ничего не останется. Как только маленькие дорогуши разделены мы начинаем беспокоиться о том, чтобы они не трогали друг друга. Ох, малышки! Мы должны защитить их друг от друга любой ценой. Каждый маленький кусок кода получает свой собственный интерфейс, чтобы он не мог замарать свои руки дотянувшись до других частей напрямую. Мы связываем их магическими фреймворками. Которые используют абстрактные прокси, создающие фабрики и так далее.

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

Корректное измерение конверсии сайта — непростая задача. А связь скорости сайта с конверсией — так вообще почти невозможная. По крайней мере, за последние 8 лет лишь немногие компании смогли корректно связать эти две величины: набралось чуть более 30 опубликованных кейсов. Мы аккуратно их все собрали, разложили по метрикам, нашли первоисточники и предлагаем вашему вниманию.

Внимание! В скорости сайта есть три основные метрики — время ответа сервера (TTFB), время отрисовки (DOMready) и время полной загрузки (onload). Часть исследований сфокусирована только на одной из метрик, а некоторые — вообще без этих метрик. Применяя результаты исследований (и предлагаемые методы) к вашему сайту, нужно четко понимать, о какой конкретно метрике (и ее улучшении) идет речь. Иначе проблемы вашего сайта не удастся соотнести с полученными результатами.

Началось всё год назад. Перед Новым 2014 годом несколько пришел в упадок жизненный тонус. Процесс самокопания привел к следующей мысли:



— А, что ж так темно-то, Господи? © День радио.

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

Всем привет. Это мой первый пост на хабре. Поэтому представлюсь для проформы. Веб-разработчик. Опыт 3,5 года. В настоящий момент — состоявшийся битриксоид. Занимаюсь всем — поддержкой крупных проектов, собственной разработкой, консультацией в вопросах маркетинга, обзором возможностей новых версий, нюансами интеграции сайта с 1С на стороне оной, написанием модулей для marketplace, внедрением бизнес-процессов в «Корпоративный портал». И многим другим. В рамках отдельно взятой CMS. К счастью ли, к сожалению ли (в статье об этом и пойдет речь) — без работы остаться невозможно. Рынок наполнен продуктами от 1С-Битрикс более, чем наполовину.

В статье речь пойдет о плюсах и минусах этой монополии. А в том, что тенденции для этой монополии есть — лично у меня никаких сомнений.

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

Добро пожаловать в мир типографики и относительных единиц измерения =)

Отрывок из книги "The End of Average" Тодда Роуза


В начале 1950-х американцы измерили тела более 4000 пилотов по 140 характеристикам, чтобы спроектировать идеальную кабину для среднего пилота

В конце 1940-х у американских военно-воздушных сил была серьёзная проблема: пилоты теряли контроль над самолётами. Тогда наступала эпоха реактивных двигателей, так что самолёты стали более быстрыми и сложными в управлении. Но катастрофы случались так часто и на таком количестве разнообразных самолётов, что ВВС США столкнулись с реальной проблемой спасения жизней. В худшее время разбивалось до 17 пилотов за день.

Если вы знаете, почему простая строка `strings` в Redis займёт в оперативной памяти 56 байт — вам, думаю, статья не будет интересна. Всем остальным я попробую рассказать, что такое строки в Redis и почему использующему эту базу данных разработчику важно понимать, как они устроены и работают. Это знание особенно важно, если вы пытаетесь рассчитать фактическое потребление памяти вашим приложением или планируете строить высоко нагруженные системы статистики или учёта данных. Или, как часто бывает, пытаетесь срочно понять, почему вдруг ваш экземпляр redis стал потреблять неожиданно много памяти.

В первой части я сказал, что хеш таблица это немного LIST, SET и SORTED SET. Судите сами — LIST состоит из ziplist/linkedlist, SET состоит из dict/intset, а SORTED SET это ziplist/skiplist. Мы уже рассмотрели словарь (dict), а во второй части статьи будем рассматривать структуру ziplist — вторую наиболее часто применимую структуру под капотом Redis. Посмотрим на LIST — вторая часть его «кухни» это простая реализация связного списка. Это пригодится нам, чтобы внимательно рассмотреть часто упоминаемый совет об оптимизацию хеш таблиц через их замену на списки. Посчитаем сколько памяти требуется на накладные расходы при использовании этих структур, какую цену вы платите за экономию памяти. Подведём итоги при работе с хеш таблицами, при использовании кодировки в ziplist.

В прошлый раз мы закончили на том, что сохранённые с использованием ziplist 1,000,000 ключей заняли 16 мб оперативной памяти, тогда как в dict эти же данные потребовали 104 мб (ziplist в 6 раз меньше!). Давайте разбираться какой ценой: