float Q_rsqrt( float number )
{
    long i;
    float x2, y;
    const float threehalfs = 1.5F;

    x2 = number * 0.5F;
    y  = number;
    i  = * ( long * ) &y;                       // зловещий хакинг чисел с плавающей запятой на уровне битов
    i  = 0x5f3759df - ( i >> 1 );               // какого чёрта?
    y  = * ( float * ) &i;
    y  = y * ( threehalfs - ( x2 * y * y ) );   // первая итерация
//  y  = y * ( threehalfs - ( x2 * y * y ) );   // вторая итерация, можно удалить

    return y;
}

Может показаться, что разработка проекта для видеостриминга — это просто: слепи плеер, возьми контент с сервера — и готово. Когда мы сами начали делать такой проект, мы поняли, что всё не так просто. 

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

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

Тема с одной стороны в общем-то простая, а с другой - многогранная. Можно сделать “на коленке”, а можно и “по-взрослому” -  зависит от знаний конкретного девелопера и технического задания. Ну и не привязывается к конкретному языку. Что nodejs, что .net, что PHP - на ответы это не влияет. Ну и отлично же! Давайте попробуем.

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

Как бы вы ответили на конкретный вопрос? Попробуйте проверить себя и потратить пару минут на обдумывание прежде чем читать ответ.

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

Итак, за вёсла!

SQL - декларативный язык - то есть вы описываете "что" хотите получить, а СУБД сама решает, "как" именно она будет это делать. Некоторые из них при этом позволяют им "подсказывать", как именно лучше выполнять запрос, но PostgreSQL - нет.

Тем не менее, "синтаксический сахар" некоторых языковых конструкций позволяет не только писать меньше кода (учите матчасть!), но и добиться, что ваша база будет делать часть вычислений "лениво", только при фактической необходимости.

Люди уходят в IT отовсюду: из инженеров КИПиА, электротехников, начальников службы охраны, химиков, бухгалтеров, экономистов, металлургов, юристов, медбратьев, руководителей отдела рекламы. Люди уходят в IT в любом возрасте: в 20, 30, 40 лет и даже после 50. 

Зачем? Почему? Что им на месте не сидится? Почему все «прутся» в это IT? Есть несколько факторов, которые этому поспособствовали. Некоторые из них мы рассмотрим. Они на самые глобальные, но важные.

Прим. перев.: эту статью написал автор Open Source-утилиты HTTP Toolkit, предназначенной для исследования и модификации HTTP(S)-трафика для нужд отладки и тестирования. В материале собраны примечательные особенности стандарта HTTP, которые долгие годы живут вместе с нами, однако не каждый догадывается об их существовании.

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

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

Мы уже выяснили, что у нас есть дефицит рабочих рук во всех отраслях. На примере СССР увидели, что дефицит легко закрывается деньгами и плюшками, что сейчас и происходит в IT. Однако при дефиците рабочих рук в остальных отраслях зарплаты остаются на уровне Румынии и никак не подтягиваются. Почему?

Сегодня Mail.ru Group провела ребрендинг – отныне, она именуется VK Group. Вместе с ребрендингом произошло и изменение правил пользовательских соглашений.

Отныне каждый пользователь «Вконтакте», зарегистрированный в VK Connect/VK ID (https://connect.vk.com) автоматически передает свои персональные данные только что созданной «Экосистеме VK» (https://vk.com/vk_ecosystem_terms) и согласно пункту 4 автоматически соглашается со всеми пользовательскими соглашениями всех сервисов «Экосистемы» (полный список: https://vk.com/vk_ecosystem_services).

Размер современных приложений и сложность языка C++ превышают возможности людей по всестороннему анализу текста программ на обзорах кода. Компенсационная методология – статический анализ кода.

Эта статья является переводом материала «When to Mock».

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

Ни одна из этих практик не является достаточно хорошей. В этой статье Владимир Хориков покажет, какие зависимости следует мокать, а какие использовать как есть в тестах.

У меня есть рабочий макбук и я часто путешествую. Я боюсь потерять данные на нем, поэтому я делаю бекапы через родную Time Machine на удаленный сервер. Для этого я поднял в офисе сервер SMB, который всегда доступен через VPN.

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

Решение: я написал скрипт Time Machine Traveler, который проверяет скорость доступа к SMB шаре и запускает бекап только если качество соединения высокое.

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

В основе этого списка — мой личный опыт, и чтобы избежать предвзятости, я расскажу и об альтернативных инструментах, чтобы вы могли всё сравнить и принять решение, исходя из своих потребностей. Постараюсь дать информацию сжато и привести источники, чтобы при желании вы могли изучить всё самостоятельно. Описывая инструменты для различных задач разработки ПО, я хотел ответить на вопрос: «Как я могу сделать X в Kubernetes?»

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

Довольно очевидно, что junior-разработчику и тимлиду требуется сильно различающийся набор навыков. И если в случае hard skills всё уже миллион раз проанализировано и посчитано, то о необходимом наборе soft skills в зависимости от должности мы можем только понимать на уровне ощущений и здравого смысла. 

Более того, в нашей индустрии не принято говорить после собеседования, что кандидату отказано из-за его уровня soft skills, хотя мы даже не пытаемся конкретизировать, что конкретно в нём нас не устраивает. Вы наверняка слышали или сами употребляли фразы вроде «просто человек странный», «почему-то не нравится» или «чувствуем, что он не вольется в команду». Но почему? Что на самом деле с ним не так?

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

Совсем недавно я услышал замечательную историю о проекте внутри крупной российской IT-компании, ищущей руководителя в отдел тестирования. Задача была простая: есть отдел из 20 человек, которые за последние несколько лет наколбасили несколько тысяч автотестов и спроектировали пачку тестов ручных. В целом все работало, но СТО на собеседовании сказал примерно следующее: “Ваша задача — выкинуть все это к чертям собачьим и сделать нормально. А то когда предыдущий QA Lead ушел, мы поняли, что вся эта инфраструктура у нас нигде не используется.” 

Ситуация невообразимая. Так не бывает. У нас точно не так. У нас же не так? 

Проблема “works on my machine” и “ответственность за нерабочий код лежит на том, кто его деплоит” ровно о том же. И пока разработчикам рассказывали про спасительный DevOps, тестировщики и QA-специалисты как-то со стороны смотрели на это “не шаля, никого не трогая, примус починяя”. Ну что, пришло время набросить и на этот вентилятор.

В этой статье мы с Артемом Ерошенко из Qameta Software попробуем разобраться, что такое “делать тестирование нормально” в новых проектах и какие инструменты могут в этом помочь.