Если вы знакомы с объектно-ориентированным программированием, то наверняка слышали и о принципах SOLID. Эти пять правил разработки ПО задают траекторию, по которой нужно следовать, когда пишешь программы, чтобы их проще было масштабировать и поддерживать. Они получили известность благодаря программисту Роберту Мартину.

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

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

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

Ну, приступим.

Полгода назад мы представили explain.tensor.ru — публичный сервис для разбора и визуализации планов запросов к PostgreSQL.



За прошедшие месяцы мы сделали про него доклад на PGConf.Russia 2020, подготовили обобщающую статью по ускорению SQL-запросов на основе рекомендаций, которые он выдает… но самое главное — собирали ваши отзывы и смотрели за реальными use case.

И теперь готовы рассказать о новых возможностях, которыми вы можете пользоваться.

Для тех, кто не знает, SNAFU — персонаж военных патриотических мультфильмов, созданных американцами во время войны. Этот раздолбай, ввиду природного идиотизма, все время попадает в катастрофические ситуации и, как правило, гибнет в конце серии. Правда, в следующей серии он снова оказывается живым — в этом смысле, его можно считать далеким прародителем Кенни из Южного Парка.

При наборе людей на позицию SQL server developer, я часто был покорен тем, как они отвечали на вопросы. Я готов был сказать им ДА, если бы меня не спасала небольшая задача в одну строчку, которую предложил мой коллега. Удивительно, сколько всего может дать эта задача в одну строку SQL. И вот уже кандидат уже с упоением ходит по граблям. А грабель, как вы увидите, там много. Конечно, ни один человек не собрал ВСЕ возможные грабли. Но, чтобы их все показать, мне и понадобился SNAFU.

Всем привет!

Продолжаем обзоры новостей свободного и открытого ПО, материалов о них и немного железа. Всё самое главное про пингвинов и не только, в России и мире. Open Source инкубатор от Huawei, нелёгкая и противоречивая доля GPL проектов в России, продолжение истории взаимоотношений Microsoft и Open Source, первый ноутбук на AMD компонентах и с предустановленным GNU/Linux и многое другое.

Эссе Айзека Азимова о творчестве от 1959 года. Айзек Азимов (1920–1992) – американский писатель и профессор биохимии Бостонского университета, известный как автор научно-фантастических и научно-популярных произведений. Азимов считается одним из «большой тройки» писателей-фантастов своего времени наряду с Робертом Хайнлайном и Артуром Кларком.

---

Заметка Артура Обермайера, друга автора:

В 1959 году я работал ученым в Allied Research Associates в Бостоне. Компания была порождением MIT и изначально изучала воздействие ядерного оружия на конструкции летательных аппаратов. Компания заключила с ARPA контракт с аббревиатурой GLIPAR (Guide Line Identification Program for Antimissile Research) с целью выявления наиболее творческих подходов к созданию противоракетной оборонительной системы. Правительство понимало, что сколько бы ни было потрачено на совершенствование и дополнение существующих технологий, они все равно останутся неудовлетворительными. Они хотели, чтобы мы и несколько других подрядчиков думали нестандартно.

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

Вспоминая Докинза, основную идею можно выразить так: если долго держать смерч над помойкой, то может собраться Боинг-747. Появление структуры из хаоса дуриком: перебирая и рекомбинируя всё подряд, из всех бессмысленных и беспорядочных процессов можно увидеть вполне осмысленные и упорядоченные. Если такие процессы каким-либо образом закрепляются и повторяются, то система, еще вчера представлявшая из себя броуновское движение, сегодня начинает выглядеть уже так, как будто ее поведение настроила невидимая рука, и что она совершает какие-то осмысленные с нашей точки зрения действия. При этом никакой руки и близко нет. Она настроила себя сама.

Чтобы в этом убедиться еще раз, я и стремлюсь написать некое подобие цифровой жизни, которая из хаоса и без лишних указаний от человека способна будет сама себе рандомно генерить логику и существовать по ней в своем естественном пространстве обитания — операционной системе. Да, в этом, вероятно, есть отличие от многих программ из направления «Искусственная жизнь», которые «живут» в загончиках, плодят «хищников» и «травоядных», и со-существуют на искусственных полях с «едой» и друг другом. Никакие из этих программ не взаимодействуют с объектами системы (процессами, файлами и т.д.), а значит код по-настоящему не живет. Кроме того, этот код так или иначе всё равно выполняет какую-то нужную человеку задачу и очень из-за этого ограничен рамками.

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

В прошлой статье, где я рассказывал о мониторинге БД PostgreSQL, была такая фраза:

Растут wait — приложение в кого-то «уперлось» на блокировках. Если это уже прошедшая разовая аномалия — повод разобраться в исходной причине.

Такая ситуация — одна из самых неприятных для DBA:

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

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

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

Разве что короткую запись в логе:

process ... still waiting for ...

А давайте попробуем зацепиться именно за нее!

Всем привет. Сегодня хотим поделиться с вами переводом статьи, подготовленным специально для студентов курса «Разработчик Java».

В моей статье Specification Pattern (паттерн Спецификация) я специально не упомянул о лежащем в основе компоненте, который сильно помог в реализации. Здесь я подробнее расскажу о классе JavaBeanUtil, который я использовал, чтобы получить значение поля объекта. В том примере это был FxTransaction.



Конечно, вы скажете, что для получения того же результата можно использовать Apache Commons BeanUtils или одну из его альтернатив. Но мне было интересно покопаться в этом и то, что я изучил, работает намного быстрее любой библиотеки, построенной на основе широко известного Java Reflection.

Прим. перев.: Jaana Dogan — опытный инженер из Google, которая в данный момент занимается вопросами наблюдаемости production-сервисов компании, написанных на Go. В этой статье, снискавшей большую популярность у англоязычной аудитории, она в 17 пунктах собрала важные технические детали, касающиеся СУБД (а иногда — распределённых систем в целом), которые полезно учитывать разработчикам крупных/требовательных приложений.



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

Простое копирование кода может быть опасным. Однако так можно сказать про множество других аспектов в разработке программного обеспечения при условии неосторожного с ними обращения. В этом посте я разберу такие вопросы как:

• Что на самом деле обозначает копирование кода в разработке ПО?
• Что значит правильное воровство кода?
• Каковы подводные камни неправильного копирования?

Ни для кого из программистов не секрет, что примерный код, который публикуют в качестве ответов на вопросы здесь, на Stack Overflow, часто оказывается в конечном варианте программ. Может быть вы задали вопрос, и вам в ответе прислали идеальную схему цикла for. Может быть вы нашли отличный ответ, в котором присутствовала часть кода с async await, которая подошла для вашего приложения.

Последняя книга по программированию, которая вам когда-либо понадобится:



Когда я наткнулся на твит, в котором говорилось о преимуществах воровства, я задумался: может ли копирование кода быть выгодным?


Вам на заметку, я не сторонник того, чтобы вы без разбора копировали код из нашего Q&A раздела. Иногда из-за этого у вас могут появиться проблемы. Но, как показала нам наша гостья в подкасте Anna Lytical, этот подход можно использовать для быстрой разработки функционирующих прототипов.

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

Решение рассказать свою историю и пройти процедуру “каминг-аута” является определенным долгом перед Богом, людьми, которых уже нет, и теми, кто ещё пытается тянуть свою лямку. Я многому научился, читая дневники больных и ушедших, благодаря этому не сделал много ошибок, и смог нащупать путь, не превратившись в героя картины Климта “Жизнь и Смерть”.

Я уже рассказывал, как мы «ловим» проблемы PostgreSQL с помощью массового мониторинга логов на сотнях серверов одновременно. Но ведь кроме логов, эта СУБД предоставляет нам еще и множество инструментов для анализа ее состояния — грех ими не воспользоваться.

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


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

Сегодняшняя статья — о том, какие выводы можно сделать, наблюдая в динамике различные метрики баз PostgreSQL-сервера, и где может скрываться проблема.

Tree of Dragons II by surrealistguitarist

Для тех, кто каждый день использует Git, но чувствует себя неуверенно, команда Mail.ru Cloud Solutions перевела статью фронтенд-разработчика Шейна Хадсона. Здесь вы найдете несколько трюков и советов, которые могут немного облегчить работу с Git, а также подборку статей и мануалов более продвинутого уровня.

За три года существования Лаборатория данных выпустила около тридцати интерактивных визуализаций, в формате заказных, собственных проектов и бесплатных советов. Мы в лаборатории визуализируем финансовые и научные данные, данные городской транспортной сети, результаты забегов, эффективность маркетинговых кампаний и многое другое. Весной мы получили бронзовую медаль на престижной премии Malofiej 24 за визуализацию результатов Московского марафона.

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

Я хочу поделиться с читателями Хабра результатами своих исследований.

Приветствую всех. Спасибо, что пригласили меня.

Позади меня вы видите кабину самолета Douglas DC-3. Итак, этот самолет был построен в 1935 году; обратите внимание на то, что каждый индикатор, каждая панель, каждый датчик и каждый переключатель каким-то образом связаны с самим самолетом. Таким образом, если вы тянете ручку управления этого судна, то на деле вы тянете все тросы и тяги, соединенные с плоскостями управления полетом самолета, а затем он движется через некую форму непосредственного управления. Это очень отличается от современного авиалайнера.



К примеру, на Airbus A380 у вас в распоряжении куча «айпадов» и стеклянных экранов, которые по сути являются устройствами вывода из компьютера, а куча кнопок и переключателей являются устройствами ввода в компьютер. То есть, само судно контролируется программным обеспечением, а пилот является связующим звеном. А вместо ручки управления у вас клавиатура, что очень удобно, если во время полета вы решите обновить вашу ленту на Facebook.

И ведь это метафора ко всему в современной жизни. Многие вещи, которые раньше мы делали при помощи непосредственного взаимодействия, сейчас используют программное обеспечение в своей работе. Мы больше не заводим будильники вручную – мы запускаем программу, которая нас разбудит. Вместо записок с информацией мы отправляем сообщения. Вместо того, чтобы стоять на улице и ловить такси, мы вызовем Uber… возможно когда-то мы сможем сделать это и в Хельсинки.

Всем привет, меня зовут Фёдор Индукаев, я работаю аналитиком в Яндекс.Маршрутизации. Сегодня хочу рассказать вам про задачу визуализации пересекающихся множеств и про пакет для Python с открытым кодом, созданный мной для её решения. В процессе мы узнаем, чем различаются диаграммы Венна и Эйлера, познакомимся с сервисом распределения заказов и по касательной заденем такую область науки, как биоинформатика. Двигаться будем от простого к более сложному. Поехали!

Из законов физики следует, что течение времени – всего лишь иллюзия. Чтобы избежать такого заключения, нам, возможно, придётся переосмыслить реальность чисел с бесконечной точностью.

Если числа нельзя записывать бесконечными последовательностями цифр, то и будущее не предопределено

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

К примеру, в теории относительности Эйнштейна время переплетено с тремя измерениями пространства, и формирует гибкий четырёхмерный пространственно-временной континуум – "блок-вселенную", охватывающую прошлое, настоящее и будущее. Уравнения Эйнштейна описывают всё в блок-вселенной, как предрешённое с самого начала; изначальные условия космоса определяют, что будет дальше, и никаких сюрпризов не происходит – они только кажутся сюрпризами. «Для нас, верящих в физику, — писал Эйнштейн в 1955, за несколько недель до смерти, — различие между прошлым, настоящим и будущим является лишь упорной и настойчивой иллюзией».

Меня зовут Александр Коцюруба, я руковожу разработкой внутренних сервисов в компании ДомКлик. Многим разработчикам, пишущим на Java, с опытом приходит понимание внутреннего устройства JVM. Чтобы облегчить этот путь Java-самурая, я решил простым языком изложить основы виртуальной машины Java (JVM) и работы с байткодом.

Что такое таинственный байткод и где он обитает?

Постараюсь ответить на этот вопрос на примере приготовления солений.

Если в переводном тексте кто-то что-то где-то начинает — то у меня сразу всплывают три дежурных варианта: begin/beginning, start/starting, first/firstly.

Судя по тому, что я вижу в присылаемых мне на проверку переводах, эта бедность речи наблюдается не только у меня. Зато у наших американских переводчиков я такого не наблюдаю — тут тебе и синонимы красивые, или вообще без всяких begin/start дело обходится.

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

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

Поехали.

Слова-синонимы

Через последовательность действий

Я принял все предложения без споров и оправданий и начал действовать.
I accepted their advice without arguing or defending and acted on it.

В сложных ERP-системах многие сущности имеют иерархическую природу, когда однородные объекты выстраиваются в дерево отношений «предок — потомок» — это и организационная структура предприятия (все эти филиалы, отделы и рабочие группы), и каталог товаров, и участки работ, и география точек продаж,…



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

Существует много способов хранения такого дерева в СУБД, но мы сегодня остановимся только на одном варианте:

CREATE TABLE hier(
  id
    integer
      PRIMARY KEY
, pid
    integer
      REFERENCES hier
, data
    json
);

CREATE INDEX ON hier(pid); -- не забываем, что FK не подразумевает автосоздание индекса, в отличие от PK

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


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