Рубрика «Совершенный код»

Шпаргалка по безопасной сборке Docker-образов - 1

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

Привет! Меня зовут Эллада, я специалист по информационной безопасности в Selectel. Продолжаю рассказывать о безопасности в Docker. Под катом расскажу, как настроить сборку образов, обеспечить безопасность и добавить сканирование в пайплайн.Читать полностью »

Я люблю питон, и вот почему он меня бесит - 1

Вас приветствует ваш зануда!

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

1053_60_cpp_antipatterns_ru/image2.png

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

Читать полностью »

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

Читать полностью »

Blink: супербыстрый эмулятор x86_64 размером 119 КБ - 1

На Хабре когда-то писали про талантливую программистку Джастин Танни, автора маленьких и очень быстрых приложений. Приятно знать, что она не останавливает свою неординарную деятельность. Например, одна из её последних разработок — крошечный эмулятор под названием Blink размером всего 116 КБ, который очень быстро компилирует WASM и выполняет Linux-программы x86_64 под разными платформами и даже в браузере.
Читать полностью »

Укрощение имен. Как нейминг помогает оптимизировать код - 1

Что такое имя? Имя — это ярлык, дескриптор, указатель в вашей памяти. Это краткое изложение сложной идеи. Оно позволяет ссылаться на «экономику» или «догфудингЧитать полностью »

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

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

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

  • Отдавайте предпочтение полиморфизму, а не «if/else» и «switch»
  • Код не должен знать о внутреннем устройстве объектов, с которыми он работает
  • Функции должны быть маленькими
  • Каждая функция должна выполнять одну задачу
  • Принцип «DRY» — Don’t Repeat Yourself («не повторяйся»)

Эти правила достаточно чётко формулируют то, как должен создаваться конкретный фрагмент кода, чтобы быть «чистым». Но я задам такой вопрос: если мы создадим фрагмент кода, соответствующий этим правилам, какова будет его производительность?
Читать полностью »

Два типа разработчиков ПО - 1

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

Согласно моей теории, есть два типа разработчиков ПО:

Когда тип 1 узнаёт о задаче, он думает: «Это легко, люди просто могут делать X».

Когда о той же задаче узнаёт тип 2, он думает: «Это очень сложно, ведь для этого нужно, чтобы люди делали X».

Тип 1 предполагает, что задача проста, если она не техническая, потому что «можно просто попросить людей делать X». Тип 2 считает, что она сложна, потому что она не техническая.
Читать полностью »

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

Каждая собака знает (уже мемородный) заголовок статьи Дейкстры Letters to the editor: go to statement considered harmful («О вреде оператора Go To») (изначально эта статья называлась A case against the goto statementЧитать полностью »

Борьба за человекочитаемость кода: опыт Хабра - 1

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

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js