Пользователь
loading = lazy, чтобы отложить загрузку изображения до тех пор, пока пользователь не домотает до них. <img src='image.jpg' loading='lazy' alt='Alternative Text'> <!DOCTYPE html>
<html lang="en" class="no-js">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width">
<title>Unique page title - My Site</title>
<script type="module">
document.documentElement.classList.remove('no-js');
document.documentElement.classList.add('js');
</script>
<link rel="stylesheet" href="/assets/css/styles.css">
<link rel="stylesheet" href="/assets/css/print.css" media="print">
<meta name="description" content="Page description">
<meta property="og:title" content="Unique page title - My Site">
<meta property="og:description" content="Page description">
<meta property="og:image" content="https://www.mywebsite.com/image.jpg">
<meta property="og:image:alt" content="Image description">
<meta property="og:locale" content="en_GB">
<meta property="og:type" content="website">
<meta name="twitter:card" content="summary_large_image">
<meta property="og:url" content="https://www.mywebsite.com/page">
<link rel="canonical" href="https://www.mywebsite.com/page">
<link rel="icon" href="/favicon.ico">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/my.webmanifest">
<meta name="theme-color" content="#FF00FF">
</head>
<body>
<!-- Content -->
<script src="/assets/js/xy-polyfill.js" nomodule></script>
<script src="/assets/js/script.js" type="module"></script>
</body>
</html>
Привет всем! У многих начинающих разработчиков, которые задумали создавать интерфейс своего очередного шедевра в Glade часто возникают трудности с конструированием различного рода списков. У меня тоже были похожие затруднения. Я решил написать данный пост, надеясь, что он поможет новичкам разобраться с созданием упомянутых элементов. Постараюсь разъяснить все максимально подробно.
Мы привыкли создавать некоторые элементы пользовательского интерфейса с помощью JavaScript, например аккордеоны, всплывающие подсказки (тултипы), усечение текста и т. д. Но, поскольку HTML и CSS постоянно получают новые функции, а старые браузеры больше не нужно поддерживать, мы можем использовать намного меньше JavaScript-кода для создания элементов пользовательского интерфейса и больше фокусироваться на логической части (проверки, обработка данных и т. д.). Специально к старту новых потоков по специализации Frontend-разработчик и Веб-разработчик делимся с вами несколькими хитростями.
Рассказываю, почему SQLite отлично подойдет вам в повседневной работе. И неважно, разработчик вы, аналитик, тестировщик, админ или продакт-менеджер.
Хорошее разрешение достижимо
В интернете много публикаций о том, как используя DVD-R диск и смартфон можно собрать спектрометр, однако характеристики таких устройств не позволяют проводить точные измерения. Мне же удалось сделать прибор с разрешением 0,3 нм.
В этом посте я расскажу, как мне удалось заставить STM32F4 измерять аналоговые сигналы в указанные моменты времени с помощью DMA не расходуя вычислительных ресурсов микроконтроллера.
style и привязывая к элементам классы.
Я уже довольно давно хотел написать пост о работе с виртуальной памятью. И когда @jimsagevid в ответ на мой твит написал о ней, я понял, что время пришло.
Виртуальная память — очень интересная штука. Как программисты, мы прекрасно знаем, что она есть (по крайней мере, во всех современных процессорах и операционных системах), но часто забываем о ней. Возможно, из-за того, что в популярных языках программирования она не присутствует в явном виде. Хотя иногда и вспоминаем, когда наш софт начинает тормозить (а не падать) из-за нехватки физической оперативной памяти.
Но, оказывается, с помощью виртуальной памяти можно делать довольно интересные вещи.
На волне ажиотажа вокруг новых карточек от Nvidia с поддержкой RTX, я, сканируя хабр в поисках интересных статей, с удивлением обнаружил, что такая тема, как трассировка путей, здесь практически не освящена. "Так дело не пойдет" - сказал я и решил, что неплохо бы запилить что-нибудь небольшое из этой темы, да и так, чтобы другим полезно было. Тут как кстати API собственного движка нужно было протестировать, поэтому решил - запилю-ка я свой простенький path-tracer прямо во фрагментном шейдере. Что из этого вышло, думаю вы уже догадались по превью к этой статье
Вопрос о том надо ли проверять то, что возвращает malloc является спорным и всегда порождает жаркие дискуссии.
Часть людей считает, что надо пытаться обрабатывать все виды runtime ошибок, в т.ч. и OOM ситуации. Другие считают, что с OOM всё равно мало что можно сделать и лучше дать приложению просто упасть. На стороне второй группы людей ещё и тот факт, что дополнительная логика обработки OOM с трудом поддаётся тестированию. А если код не тестируется, то почти наверняка он не работает.
Я полностью согласен с тем, что не стоит реализовывать логику обработки ошибок которую вы не собираетесь тестировать. Почти наверняка она ничего не улучшит, а может и того хуже — всё испортит.
Вопрос о том надо ли пытаться обрабатывать OOM ситуации в библиотеках/приложениях является противоречивым и мы не будем его здесь касаться. В рамках данной публикации я лишь хочу поделиться опытом того как можно тестировать реализованную логику обработки OOM ситуаций в приложениях написанных на C/C++. Разговор будет идти об операционных системах Linux и macOS. Ввиду ряда причин, Windows будет обойдён стороной.
