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

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

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

                                                        QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------
 Sort  (cost=146.63..148.65 rows=808 width=138) (actual time=55.009..55.012 rows=71 loops=1)
   Sort Key: n.nspname, p.proname, (pg_get_function_arguments(p.oid))
   Sort Method: quicksort  Memory: 43kB
   ->  Hash Join  (cost=1.14..107.61 rows=808 width=138) (actual time=42.495..54.854 rows=71 loops=1)
         Hash Cond: (p.pronamespace = n.oid)
         ->  Seq Scan on pg_proc p  (cost=0.00..89.30 rows=808 width=78) (actual time=0.052..53.465 rows=2402 loops=1)
               Filter: pg_function_is_visible(oid)
         ->  Hash  (cost=1.09..1.09 rows=4 width=68) (actual time=0.011..0.011 rows=4 loops=1)
               Buckets: 1024  Batches: 1  Memory Usage: 1kB
               ->  Seq Scan on pg_namespace n  (cost=0.00..1.09 rows=4 width=68) (actual time=0.005..0.007 rows=4 loops=1)
                     Filter: ((nspname <> 'pg_catalog'::name) AND (nspname <> 'information_schema'::name))

Улучшаем внешний вид

Со временем вносить изменения в любой продукт становится сложнее, и растёт риск не только зарелизить новые фичи, но и сломать старые. Часто вместо того, чтобы руками проверять весь проект, этот процесс стараются автоматизировать. Если поговорить с людьми, которые занимаются тестированием интерфейсов, походить по конференциями, становится понятно, что в мире веб-тестирования правит Selenium, а в качестве организации кода подавляющее большинство используют Page Object.

Вот только мне, как программисту, этот паттерн и код, который я видел у разных команд, почему-то никогда не нравился — в голове звучали буквы SOLID. Но я уже был готов смириться с тем, что тестировщики пишут код, как им удобно, из-за отсутствия альтернатив, как где-то год назад, на Angular Connect, услышал я доклад, посвящённый тестированию Angular приложений c использованием Screenplay паттерна. Теперь хочу поделиться.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Wormholes in JavaScript" автора Mathius Buus.

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

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

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