Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

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

Недавно мы опубликовали перевод материала, в котором были приведены полезные советы для Python-программистов. У того материала есть продолжение, которое мы представляем вашему вниманию сегодня.

Некоторое время назад на Quora я отвечал на вопрос: как успевать записывать за лектором конспект по математике на LaTeX. Там я объяснил свой рабочий процесс по конспектированию в LaTeX с помощью Vim и Inkscape (для рисунков). Но с тех пор многое изменилось, так что я хочу опубликовать несколько постов в блоге с описанием нового процесса. Это первая из статей.

Я начал использовать LaTeX для конспектирования во втором семестре курса математики, и с тех пор написал более 1700 страниц. Вот несколько примеров, как выглядит конспект:

Пятничный привет, Хабр!

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

В результате мы окунемся в период, когда слова Dendy и Sega вызывали трепет, и получим вот такую «карманную» консоль:


Под катом много картинок и краткое видео для тех кто любит смотреть, а не читать

C момента своего появления в декабре 2017-го дипфейки, видео с почти идеальной заменой лица, созданные нейросетью, наводили на экспертов панику. Многие, например, тогда боялись, что теперь еще проще станет «порно-месть», когда бывший бойфренд с достаточно мощным ПК может смастерить любое грязное порно с подругой. А Натали Портман и Скарлетт Йоханссон, о которых порно с deepfake снимали особенно много, публично прокляли интернет.

Чтобы бороться с подступающей угрозой, Facebook и Microsoft недавно собрали коалицию для борьбы с дипфейками, объявив призовой фонд $10 млн тем разработчикам, которые придумают лучшие алгоритмы для их обнаружения. Это помимо DARPA, управления исследованиями Министерства обороны США, выделившего на эту цель $68 млн за последние два года.

Ну так вот, уже поздно. Первое deepfake-преступление уже состоялось.

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

Совмещая работу и путешествия, я побывал уже в трех странах: Германия, Греция и Вьетнам. Ездил не сам, а с семьей — женой и двумя детьми (сейчас им 3 и 6 лет). Конечно же, поначалу я сомневался, а получится ли совмещать и работу, и активное получение новых впечатлений, но очень быстро втянулся и собираюсь продолжать в том же духе.

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

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

Например, архитектурно GAN [1] состоит из генератора (GEN) и дискриминатора (DIS), Состязательный Автокодировщик (AAE) [2] состоит из Автокодировщика (AE) [3] и DIS,. Каждый компонент является отдельной вершиной в данном графе, поэтому для AAE у нас будет ребро с AE и DIS.

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

Суть разработки программного обеспечения
— Нужно проделать 500 отверстий в стене, так что я сконструировал автоматическую дрель. В ней используются элегантные точные шестерни для непрерывной регулировки скорости и крутящего момента по мере необходимости.
— Отлично, у неё идеальный вес. Загрузим 500 таких дрелей в пушку, которые мы сделали, и выстрелим в стену.

Я занимаюсь программированием уже 15 лет. Но в последнее время при разработке не принято думать об эффективности, простоте и совершенстве: вплоть до того, что мне становится грустно за свою карьеру и за IT-отрасль в целом.

Для примера, современные автомобили работают, скажем, на 98% от того, что физически позволяет нынешняя конструкция двигателя. Современная архитектура использует точно рассчитанное количество материала, чтобы выполнять свою функцию и оставаться в безопасности в данных условиях. Все самолёты сошлись к оптимальному размеру/форме/нагрузке и в основном выглядят одинаково.

Только в программном обеспечении считается нормальным, если программа работает на уровне 1% или даже 0,01% от возможной производительности. Ни у кого вроде нет возражений.

В наши дни веб-сервисы постоянно подвергаются самым разным атакам. Поэтому безопасность — это то, о чём стоит помнить на всех этапах жизненного цикла проектов. Авторы материала, перевод которого мы сегодня публикуем, поддерживают репозиторий на GitHub, содержащий около 80 рекомендаций по обеспечению безопасности приложений, работающих на платформе Node.js. В этом материале, базой для которого послужило множество публикаций, посвящённых безопасности, собрано более двух десятков рекомендаций, касающихся Node.js, и некоторые советы общего характера. При этом данный материал покрывает топ-10 уязвимостей из списка проекта OWASP.

Всем привет. В статье хочу описать свой эксперимент по созданию «искусственной жизни» на компьютере.

Как это выглядит?

картинка кликабельна

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

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

А мне остаётся только наблюдать за развитием мира.

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

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

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

Внутреннее устройство кода — это самое интересное в проекте.

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

Предисловие от переводчика

На протяжении многих лет разработки ПО, будучи участником многих команд, работая с разными хорошими и опытными людьми, я часто наблюдал (да и чего греха таить, до определенного момента — создавал) одну и ту же проблему — тотальный бардак в репозитории. Каждый писал комментарии к коммитам в своем стиле (и хорошо, если постоянно в одном); половина комментариев была бесполезна (из разряда "это мост"), половина оставшейся половины — едва понятна.

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

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

Buffered Streams

//медленно
InputStream is = new FileInputStream(file);
int val;
while ((val = is.read()) != -1) {
}
//быстро
InputStream is = new BufferedInputStream(new FileInputStream(file));
int val;
while ((val = is.read()) != -1) {
}

Казалось бы — очевидная истина, неправда ли? Но как показал чужой код и опыт собеседования кандидатов, часть разработчиков определенно не понимает в чем преимущество буферизованных стримов. Кто до сих пор не разобрался — метод read() класса FileInputStream:

public native int read() throws IOException;

Согласитесь, каждый раз делать системный вызов, чтобы считать один байт несколько расточительно. Собственно для того, чтобы избежать этой проблемы и были созданы оболочки-буферы. Все что они делают — при первом вызове системного read() считывают несколько больше (в зависимости от указанного размера буфера, котрый по умолчанию равен 8 кб) и при следующем вызове read() считывают данные уже из буфера. Прирост производительности — на порядок. Системные вызовы, на самом деле, это не всегда плохо, например:

System.arraycopy(src, srcPos, dest, destPos, length);

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

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

Тем не менее, в этом году организаторы «Противостояния», главного конкурса конференции Positive Hack Days VII, сделали все возможное, чтобы решить эту противоречивую задачу — сделать состязание максимально приближенным к реальности, но при этом достаточно понятным и интересным для всех остальных посетителей конференции. И нам кажется, это удалось. Всего за тридцать часов конкурса команды хакеров продемонстрировали целый ряд успешных атак на объекты и инфраструктуры современного города, активно используя и беспроводную связь, и низкоуровневые уязвимости промышленных систем управления, и простые брутфорсы, и сложные многоступенчатые схемы вторжения.

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

Не так давно в комментариях к топику AlexS высказал идею использования соглашения об оформлении на Хабре кода примеров темы .Net написанных на C#.

Я немного поизучал имеющиеся предложения из этих источников:
submain.com/blog/FreeCVBNETCodingGuidelinesEbookDownload.aspx
idesign.net/idesign/DesktopDefault.aspx
и скомпилировал черновик который описывает самые базовые правила оформления кода написанного на C#.

Предлагаю:
— обсудить этот черновик;
— внести в него все необходимые изменения;
— утвердить как стандарт написания C# кода на Хабре.
Более того, предлагаю создать документ, который можно было бы предложить как рекомендации habrahabr comunity для всех других программистов C#.

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

Правила языка Java

Мы следуем стандартным соглашениям по оформлению кода на Java. Мы добавили к ним некоторые правила:

1. Исключения: никогда не перехватывайте и не игнорируйте их без объяснения.
2. Исключения: не используйте обобщенные исключения, кроме кода в библиотеках, в корне стека.
3. Финализаторы: не используйте их.
4. Импорты: полностью уточняйте импорты.