Bounce rate — показатель отказа. Термин в веб-аналитике, обозначающий процентное соотношение количества посетителей, покинувших сайт прямо со страницы входа или просмотревших не более одной

В индустрии программного обеспечения, все гонятся за ускорением всего и вся.

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

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

С появлением Java 8 Stream API позволило программистам писать существенно короче то, что раньше занимало много строк кода. Однако оказалось, что многие даже с использованием Stream API пишут длиннее, чем надо. Причём это не только делает код длиннее и усложняет его понимание, но иногда приводит к существенному провалу производительности. Не всегда понятно, почему люди так пишут. Возможно, они прочитали только небольшой кусок документации, а про другие возможности не слышали. Или вообще документацию не читали, просто видели где-то пример и решили сделать похоже. Иногда это напоминает анекдот про «задача сведена к предыдущей».

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

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

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

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

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

Компания Тензор tensor_sbis имеет свой удостоверяющий центр и выпускает сертификаты проверки ключа электронной подписи физическим и юридическим лицам.

Время от времени мне встречаются вопросы по математике, которые в каком-то смысле можно назвать «грамматически неверными».

Пример. «Интервал $$ является замкнутым или открытым?»
Пример. «Является ли $$ группой?»
Пример. «Каков ряд Фурье для $$?»

А вот ещё более глупые примеры.

Пример. «Является ли прямоугольник простым?»
Пример. "$$?"
Пример. «Каков ряд Фурье для пустого множества?»

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

Математические объекты обычно не воспринимаются явно как имеющие типы в том же смысле, что и объекты в языках программирования с системой типов. Предполагается, что обычная математика должна формализироваться в системе Цермело — Френкеля (ZF), возможно, с аксиомой выбора, а в ZF каждый математический объект конструируется как множество. В этом смысле все эти объекты имеют одинаковый тип. (В частности, вопрос "$$" вполне логичен в ZF! И это одна из причин, по которой стоит не любить ZF в качестве основы для математики.) Однако, мне кажется, что на практике математические объекты неявно воспринимаются, как имеющие типы, и такой образ мышления математики усваивают, но не часто обсуждают.

Длительная работа в IT натаскивает видеть несовершенства в пользовательском софте. Иногда это откровенные баги, которые хорошо бы исправить. Но сообщить об этом затруднительно из-за непрофессиональной работы поддержки. Публикация таких обзоров багов действительно помогает привлечь внимание разработчиков. В этом обзоре будут рассмотрены проблемы на сайтах ОнлайнТрейд и Ростелеком, в мобильном приложении банка Рокетбанк и даже Хабра! Про Ростелеком вообще детектив получился.

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

Yarn — менеджер пакетов для ноды — выпустили вторую версию. И, похоже, парни серьёзно вознамерились изменить статус-кво в экосистеме ноды, а то и вообще в пакетных менеджерах. Удаляйте все свои картинки про гигабайтные мамки node_modules, убирайте yarn install из скриптов CI, мы начинаем очередную великую JavaScript-смуту. Если вкратце:

• Режим Plug'n'Play стал дефолтным, а node_modules — вторичным, через плагин.
• Сделали плагин и воркфлоу для монореп — может и lerna будет не нужна.
• Встроили свой мини-шелл, чтобы скрипты пакета без этих ваших cross-env в винде запускать.
• Добавили пролог для проверки правил между воркспейсами.
• npx опять же свой запилили.

Если вы не хотите обновлять все ваши проекты, просто запустите yarn policies set-version ^1 (смотри legacy.yarnpkg.com/en/docs/cli/policies) в репозиториях, которые должны остаться на Yarn 1 и закомитьте результат. Тогда Yarn будет использовать локальные бинарники Yarn 1 вместо глобальных так что все в команде будут использовать одну версию!

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

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

Впервые на похожую задачу я наткнулся на прошлой работе. К слову, решена эта задача была методом 3 из данной статьи. «Как неэстетично», — подумал я. — «Дали бы мне эту задачу, я бы точно решил ее в 128 раз лучше. Но… как?»

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

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

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

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

Код это тоже текст. И написать его можно так, что чтение станет крайне неприятным и энергозатратным занятием. Если вам вдруг во время работы с особенно ужасными фрагментами корпоративного портала хочется закрыть редактор и посмотреть котиков, то дело, скорее всего, не в том, что вам лень или внезапно случилось то самое выгорание. Всё дело в том, что именно вы читаете.

Многие используют в своей работе Jupyter Notebooks. Но с ростом сложности проекта появляются проблемы. В блокноте появляются ячейки с красными пометками для самого себя «перед запуском укажи число...» или «задай количество итераций исходя из...». Какой-то откат к командной строке получается.

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

Захотелось мне сделать что-нибудь, пусть бесполезное, но зато своё. И не под чью-то копирку, а свое — с нуля. Так и родилась идея собрать процессор из микросхем 155-й серии (и немного других серий). А там так завертелось, что процессор плавно перерос в ЭВМ. В ЭВМ с собственной микроархитектурой и своим компилятором.. И главная «фишка» проекта: все это собрано на гетинаксе и микросхемах времен СССР.

Как быть, если дерево поиска разрослось на всю оперативку и вот-вот подопрет корнями соседние стойки в серверной? Что делать с инвертированным индексом, жадным до ресурсов? Завязывать ли с разработкой под Android, если пользователю прилетает «Память телефона заполнена», а приложение едва на половине загрузки важного контейнера?

В целом, можно ли сжать структуру данных, чтобы она занимала заметно меньше места, но не теряла присущих ей достоинств? Чтобы доступ к хэш-таблице оставался быстрым, а сбалансированное дерево сохраняло свои свойства. Да, можно! Для этого и появилось направление информатики «Succinct data structures», исследующее компактное представление структур данных. Оно развивается с конца 80-х годов и прямо сейчас переживает расцвет в лучах славы big data и highload.

А тем временем на Хабре найдется ли герой, способный пересковоговорить три раза подряд
[səkˈsɪŋkt]?

Многие программисты думают, что Quick Sort — самый быстрый алгоритм из всех существующих. Отчасти это так. Но работает она действительно хорошо только если правильно выбран опорный элемент (тогда сложность составляет O (n log n)). В противном же случае асимптотика будет примерно такой же как и у пузырика (то-есть O (n²)).
При этом, если массив уже отсортирован, то алгоритм всё-равно будет работать не быстрее, чем O (n log n)

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

«Дело было вечером, делать было нечего», — Сергей Михалков.

Требования:

1. Лучший случай O (n)
2. Средний случай O (n log n)
3. Худший случай O (n log n)
4. В среднем быстрее быстрой сортировки

А теперь давайте обо всём по порядку

Чтобы наш алгоритм всегда работал быстро, нужно чтобы в среднем случае асимптотика была хотя бы O (n log n), а в лучшем — O (n). Все мы прекрасно знаем, что в лучшем случае сортировка вставками работает за один проход. Но в худшем ей придётся гонять по массиву столько раз, сколько в нём элементов.

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

Такие запросы любят «кушать» процессорное время и активно почитывать данные практически на ровном месте. Причем, это вовсе не обязательно какие-то сложные запросы, наоборот — чем проще он написан, тем больше шансов получить проблемы. А уж если в дело вступает оператор JOIN…


Само по себе соединение таблиц не вредно и не полезно — это просто инструмент, но и пользоваться им надо уметь.

Захотев перейти на Linux дома или на работе, люди обычно ставят Ubuntu, Mint, Fedora, порой даже Debian. И очень зря не пробуют Manjaro Linux — на мой взгляд, этот дистрибутив удобнее Убунты (которая уже де-факто — Default Linux), и даже удобнее Минта.

Manjaro — производная от Arch Linux (так же как Ubuntu — производная от Debian), пилится европейской командой Manjaro Team. У Манжары почти такая же структура системы, как у Арча, но с некоторыми особенностями, которые делают его на 146% юзерфрендли.

Томас резко вывернул руль влево, все восемь колёс его «крабика» протестующе заскрипели, впиваясь в грунт.

— Даю тебе пять минут, — раздалось в наушниках. Голос Джулии с трудом пробивался через помехи — он отъехал от станции чересчур далеко.

— Мне достаточно трёх.

— Уверен?..

— Ты издеваешься? — завопил он в микрофон.

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

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

Демо-страница: Javascript Code Highlighter