Хотя составление SQL-запросов — это не самое интересное в работе дата-сайентистов, хорошее понимание SQL чрезвычайно важно для того, кто хочет преуспеть в любом занятии, связанном с обработкой данных. Дело тут в том, что SQL — это не только SELECT, FROM и WHERE. Чем больше SQL-конструкций знает специалист — тем легче ему будет создавать запросы на получение из баз данных всего, что ему может понадобиться.



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

1. Изучение механизмов, которые выходят за пределы базового знания SQL.
2. Рассмотрение нескольких практических задач по работе с SQL.

В статье рассмотрено 5 вопросов по SQL, взятых с Leetcode. Они представляют собой практические задачи, которые часто встречаются на собеседованиях.

Более полувека правительства всех стран доверяли единственной компании сокрытие переписки, которую вели их шпионы, солдаты и дипломаты

Эта компания, Crypto AG, первого своего успеха добилась, заключив во время Второй Мировой войны контракт на создание кодирующих машин для пехоты армии США. Как следует заработав на этом, она на десятилетия стала доминирующим производителем шифровального оборудования, и шла на переднем крае технологий, переходя от механических шестерней к электронным схемам, и, наконец, к кремниевым чипам и программному обеспечению.

Эта швейцарская фирма заработала миллионы долларов, продавая оборудование в более чем 120 стран, не только в XX, но и в XXI веке. Среди её клиентов были правительство Ирана, военные хунты Латинской Америки, обладатели ядерного оружия и соперники Индия и Пакистан, и даже Ватикан.

Однако все эти клиенты не подозревали, что ЦРУ в рамках совершенно секретного партнёрства с западногерманской разведкой тайно владела Crypto. Эти разведывательные агентства подправляли устройства компании так, что легко могли взламывать коды, используемые странами для обмена зашифрованными сообщениями.

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

Про принцип единственной ответственности (The Single Responsibility Principle, SRP) уже было написано множество статей. В большинстве из них даётся лишь поверхностное его описание мало чем отличающееся от информации в википедии. А те немногие статьи что затрагивают ключевые особенности SRP делают это вскользь, не акцентируя на них внимания и не развивая тему дальше.

Эта статья — попытка дать более глубокое объяснение принципу единственной ответственности, а также показать как его всё таки можно применять на практике. Кому интересно — добро пожаловать под кат.

Проектировщики самолёта отвечают на вопрос о его безопасности:
— Ничто не вечно, но современные авиалайнеры невероятно устойчивы, а самолёт — самый безопасный транспорт в мире.
Инженеры-строители отвечают о безопасности лифтов:
— Лифты защищены множеством отказоустойчивых механизмов. Их практически невозможно уронить в свободное падение.
Программисты отвечают на вопрос об электронном голосовании:
— Это просто ужасно.
— Серьёзно?
— Абсолютно. Не доверяйте программам для электронного голосования и не верьте никому, кто уверяет в их надёжности.
— Почему?
— Не совсем знаю, как это выразить, но вся наша область плоха в том, что мы делаем, и если вы будете полагаться на нас, то все умрут.
— Говорят, что надёжность гарантируется технологией под названием «блокчейн».
— А-а-а-а-а!!! Что бы они ни говорили, не прикасайтесь к этому! Закопайте поглубже. Не забудьте перчатки!
Источник: XKCD, лицензия Creative Commons 2.5

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

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

Несколько недель назад в разговоре за обедом коллега пожаловался на какой-то медленный процесс. Он подсчитал количество сгенерированных байт, количество циклов обработки, и в конечном счёте, объём оперативной памяти. Коллега заявил, что современный GPU с пропускной способностью памяти более 500 ГБ/с съел бы его задачу и не подавился.

Мне показалось, что это интересный подход. Лично я раньше не оценивал задачи производительности с такой стороны. Да, я знаю о разнице в производительности процессора и памяти.



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

Вот вам небольшая история о таинственных сбоях сервера, которые мне пришлось отлаживать год назад (статья от 05 декабря 2018, прим.пер). Сервера некоторое время работали нормально, а затем в какой-то момент начинали аварийно завершаться. После этого попытки запустить практически любую программу, что были на серверах, терпели неудачу с ошибками «На устройстве нет места», хотя файловая система сообщала только о нескольких занятых гигабайтах на ~20 ГБ дисках.

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

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

Рэй Брэдбери однажды сказал: «Я не пытаюсь предсказать будущее – я пытаюсь его предотвратить».

Для нас, детей 70-80-х годов, книги Рэя Брэдбери были маяком гуманности и надежды, что даже самое мрачное будущее когда-то закончится и начнётся рассвет.

На Западе многое изменилось за последние годы, а на место гуманистов-фантастов пришли дельцы. Теперь о будущем вещают Билл Гейтс, Илон Маск и Марк Цукерберг.

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

Последние несколько дней в СМИ появилось много статей с данными о смертности и летальности из-за 2019-nCoV. Люди часто путают эти понятия.

Чего только стоит это интервью в Московском комсомольце:

Ссылка на оригинал
Журналист спрашивает про смертность, собеседник отвечает про летальность! Это простая некомпетентность или в очередной раз "ученый изнасиловал журналиста"?
А в чём разница?

Речь пойдёт о способе защиты програмного обеспечения, который реализован в самом процессоре. Для экспериментов я выбрал мультимедиа приставку Comigo Quattro. Цель — запустить своё ядро линукс.

Краткий обзор

На первый взгляд ПО приставки является клоном Android. Доступ по ssh закрыт. Работает только с действующим абонементом от дистрибьютора. Стоковая прошивка полностью шифрована. Всё глухо, как в танке.

Подготовка

Первым делом я подробно ознакомился с техническим описанием процессора. Порадовали меня две вещи: у процессора был интерфейс UART и он поддерживал загрузку системы с разных источников (USB, SD и т.д.), которая могла настраиваться снаружи при помощи конфигурационного регистра. На борту приставки также имелось место для mSD карты, но разьём был не припаян. Для того, чтобы найти пятачки конфигурационного регистра и пины UART мне пришлось спаять процессор и прозвонить дорожки. Когда все контакты были найдены, я подключил адаптер UART и запустил приставку. На экрана высветился U-Boot. Загрузка системы прерывалась нажатием клавиш и U-Boot выходил в режим ввода, но ни на какие клавиши кроме enter, никак не реагировал. И эта лазейка тоже была закрыта.

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

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

Бортовые Часы Космические. Показывают время, имеют будильник («оповещатель») и секундомер

Недавно к нам в руки [в Музей компьютерной истории в Маунтин-Вью, Калифорния] попали часы, летавшие в космос с миссией «Союз» («Бортовые Часы Космические», или БЧК). Часы изготовлены в 1984 году и содержат более 100 интегральных схем (ИС) на десяти печатных платах. Почему же эти часы такие сложные? В данной статье я изучу схему часов и объясню, почему для них потребовалось так много чипов. Также часы дают нам возможность подробнее взглянуть на советскую аэрокосмическую электронику и сравнить её с американскими технологиями.

Космические корабли «Союз» были разработаны в рамках советской космической программы во время лунной гонки. Первый «Союз» полетел в 1966 году, а всего в рамках программы за последние 50 лет было совершено более 140 полётов. Космический корабль (см. фото ниже) состоит из трёх частей. Круглая секция слева – обитаемый модуль, где хранится груз, оборудование и находятся жилые отсеки. В середине находится спускаемый модуль, и это всё, что возвращается на Землю; космонавты находятся в спускаемом модуле во время запуска и возвращения. В сервисном модуле справа находится основной двигатель, солнечные панели и другие системы.

А никак они не развивались. С самых первых языков программирования и по сей день комментарии коду — это всего лишь статичный текст (за некоторыми исключениями, о которых я расскажу).



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

Если ваши микросервисы уже используют общую базу PostgreSQL для хранения данных, или ей пользуются несколько экземпляров одного сервиса на разных серверах, можно относительно «дешево» получить возможность обмена сообщениями (PubSub) между ними без интеграции в архитектуру Redis, RabbitMQ-кластера или встройки в код приложения другой MQ-системы.

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

Передавать и получать данные мы станем с помощью механизма NOTIFY/LISTEN, а модельную реализацию соберем для Node.js.



Но на этом пути лежат грабли, которые придется аккуратно обойти.

Привет, Хаброжители! Язык С++ выбирают, когда надо создать по-настоящему молниеносные приложения. А качественная конкурентная обработка сделает их еще быстрее. Новые возможности С++17 позволяют использовать всю мощь многопоточного программирования, чтобы с легкостью решать задачи графической обработки, машинного обучения и др. Энтони Уильямс, эксперт конкурентной обработки, рассматривает примеры и описывает практические задачи, а также делится секретами, которые пригодятся всем, в том числе и самым опытным разработчикам.

В книге • Полный обзор возможностей С++17. • Запуск и управление потоками. • Синхронизация конкурентных операций. • Разработка конкурентного кода. • Отладка многопоточных приложений. Книга подойдет для разработчиков среднего уровня, пользующихся C и C++. Опыт конкурентного программирования не требуется.

Каждый раз, когда мы пишем класс, управляющий ресурсами, мы задумываемся о том, что, скорее всего, для него придётся писать move-конструктор и move-присваивание. Ведь иначе объекты такого типа становятся неуклюжими, как std::mutex, ими тяжело пользоваться на практике: ни вернуть из функции, ни передать в функцию по значению, ни положить в вектор — а если положить его в другой класс как один из членов, то тот класс также «заболевает».

Положим, мы преодолели свою лень (хотя в Rust таких проблем нет!) и садимся писать move-операции для нашего класса. Проблема в том, что move-семантика в C++ имеет фундаментальное ограничение: каждый владеющий ресурсами тип с move-операциями должен иметь пустое состояние, то есть состояние с украденными ресурсами. Его нужно описывать в документации и предоставлять ему поддержку, то есть тратить время и силы на то, что нам не нужно.

Для абстрактных типов данных пустое состояние обычно бессмысленно — если у объекта украли его ресурсы, то он не сможет выполнять свои обычные функции. Но мы вынуждены это делать, чтобы реализовать move-семантику. Для некоторых типов пустое состояние недопустимо: open_file (в противовес теоретическому file), not_null_unique_ptr<T> (в противовес unique_ptr<T>).

Говоря словами Arthur O'Dwyer, мы заказывали телепорт, а нам дали «вас клонируют и убивают первоначальную копию». Чтобы вернуть себе телепорт, проходите под кат!

В настоящей статье приводится разбор вариантов устранения антипаттерна «Зомби», описанного в первой части: Сказ об опасном std::enable_shared_from_this, или антипаттерн «Зомби».

Временами бывает нужно отпрофилировать производительность программы или потребление памяти в программе на C++. К сожалению, зачастую это сделать не так просто как может показаться.

Здесь будут рассмотрены особенности профилирования программ с использованием инструментов valgrind и google perftools. Материал получился не очень структурированным, это скорее попытка собрать базу знаний «для личных целей», чтобы в будущем не приходилось судорожно вспоминать, «а почему не работает то» или «а как сделать это». Скорее всего, здесь будут затронуты далеко не все неочевидные случаи, если вам есть что добавить, пишите пожалуйста в комментарии.

Все примеры будут запускаться в системе linux.