В программировании нет вообще никаких непреложных истин. Даже самые очевидные правила могут иметь контекст, в которых их применять нельзя. К сожалению в 99% организаций есть прям заповеди, обязательные к исполнению. И есть правила, которые считаются правилами хорошего тона (как не сморкаться в занавеску). Однако всегда бывают ситуации, когда лучше все-таки сморкаться.

Вот примеры.

1) Например, DRY — don’t repeat yourself. Хорошее полезное правило, но его можно довести до маразма. Из того что я встречал на практике: есть два разных по бизнес-смыслу раздела, которые начинались с простого CRUD, и многие части (и фронта и бека) выглядели во многом абсолютно одинаково. Если их объединить с помощью общей высосанной из пальца абстракции и тем самым избавиться от небольшого дублирования кода, то потом (очень скоро) можно будет сойти с ума, потому что эти две вещи скоро разъедутся, обрастая кастомными фичами, и абстракция будет только вредить. Нельзя абстрагировать неабстрагуемое, даже если DRY нарушен.

«[Немного] дублирования обходится гораздо дешевле, чем неправильная абстракция» — Сэнди Мец

Т.е. DRY — хороший принцип, но бывают исключения.

Представьте себе набор данных, состоящий из некоторого количества наблюдений. У каждого наблюдения имеется N признаков. Если преобразовать все эти признаки в их числовое представление, то можно будет сказать, что каждое из наблюдений — это точка в N‑мерном пространстве.

Если N — величина небольшая — взаимоотношения между точками будут именно такими, какими их можно представить на интуитивном уровне. Но иногда N достигает огромных значений. Это может произойти, например, когда множество признаков создают посредством прямого кодирования или чего‑то подобного. Для очень больших значений N наблюдения ведут себя так, как если бы они были бы представлены разреженными данными, или так, как если бы расстояния между ними были бы несколько больше, чем можно было бы ожидать.

Это — реальное явление. По мере роста N, при условии, что всё остальное не меняется, объём части N‑мерного пространства, содержащий наблюдения, тоже, в некотором смысле, увеличивается (или, как минимум, увеличивается количество степеней свободы). Увеличиваются и евклидовы расстояния между наблюдениями. Группа точек становится всё более разреженной структурой. Это — геометрическая база для такого понятия, как «проклятие размерности». Подобные изменения в данных влияют на поведение моделей и на приёмы работы, применяемые к наборам данных.

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

История эмиграции, блеск и нищета стартапов, техническое порно, непрерывная разработка, гидроакустика, нарциссизм, рефлексия, open-source и много фото.

Это все под катом.

Приветствую хабравчане!

Глава 1 - Нытье про то, что раньше было лучше

Десяток лет читаю Хабр, в основном разработка, программирование, старое железо и посты с адовым рейтингом. Видел несколько постов об ожирении сайтов, софта. О разочаровании в программировании с 2000+ постов. И пост, что в софте все ок, но никто не доволен или как оно там. А не важно. Хочу поделиться своими мыслями и наблюдениями на этот счет.

Ниже размещена картинка с ПК которые у меня были, не все, парочку ноутов я просто не помню. Эволюция их производительности, специально выделил производительность на одно ядро.

Бенчмаркингом я занимаюсь уже более 10 лет (заинтересовался, когда приобрёл первый одноплатный компьютер Odroid X2 в 2012 году, тогда только зарождалась субкультура по одноплатным компьютерам), а также мне всегда было интересно сравнить производительность современных процессоров с процессорами 80-х годов (конечно же я использую и современные бенчмарки). Для меня важно, чтобы у бенчмарков был доступен исходный код (особенно на языке C и без заморочек компиляции), легко собираемый и понятный в интерпретации результатов.

В тестах процессоров я применяю следующие бенчмарки: Dhrystone, Whetstone, Linpack 100, Coremark, MP MFLOPS, Scimark 2, STREAM, TLB, HPL. А также Geekbench, Cpu-z bench, Crystal Mark 2004, 7z и другие.

В данной статье рассмотрим Dhrystone.

Статья заряжена на повышение безопасности вашего кода :) Расскажем о трёх популярных анализаторах, какие типы уязвимостей они способны обнаружить и покажем результаты проверки реальных проектов.

В этой статье поговорим про команды GNU/Linux, которые удобно использовать разработчику для решения повседневных задач. Подборка ориентирована на тех, кто не хочет залезать глубоко в систему, но по работе вынужден иногда ходить на Linux-сервер. Здесь мы собрали то, чем пользуемся сами и к чему привыкли, однако почти все упомянутые задачи можно решить и другими способами.

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

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

Одного и того же - побольше дофаминчика (гормон счастья), поменьше кортизольчика (гормон стресса). Притом источники и дофамина, и кортизола у них одни и те же. Дофамин вырабатывается, когда фичи выпускаются в срок и без багов, а кортизол - когда сроки срываются и вылазят баги и регрессии. Бизнесу будет ближе финансовая версия — срыв сроков и баги очевидным образом приводят к увлечению стоимости разработки. Что приводит к выбросу кортизола уже у владельцев.

Сначала я хотел назвать эту заметку «Редактор связей? Это очень просто». Именно так называл свои прекрасные книжки Евгений Айсберг: «Радио? Это очень просто!», «Телевидение? Это очень просто!» Но поскольку я уже использовал эту шутку в статье о планировщике Windows, чтобы не повторяться, теперь использую любимую формулу многих журналистов: «Вся правда о…».

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

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