У меня на ладони лежит очень горячий сотовый телефон, который разогрелся из‑за того, что мессенджер отображает статичное сообщение с пузырем и текстом на экране при помощи браузерного движка и безумного количества сторонних библиотек. При этом я отлично помню время, когда десктоп был в 10 раз менее производительным, чем этот сотовый, а не‑кроссплатформенные мессенджеры тех времен, написанные на С++, отображали текст не нагружая эти допотопные процессоры и на 10%. Я считаю, что в такой деградации виноват в первую очередь комитет по стандартизации C++. Их близорукие решения и неспособность адаптироваться к реальным потребностям разработчиков привели к парадоксальной ситуации: несмотря на постоянное увеличение мощности компьютеров, программы работают медленнее и потребляют больше ресурсов, чем их аналоги десятилетней давности, а С++‑разработчики не могут создать даже простой мессенджер, который будет работать на 2–3 распространенных операционных системах, не используя массы сторонних библиотек.
C++ задумывался как язык, который должен был дать программистам возможность писать эффективный код с высоким уровнем абстракции. Однако комитет по стандартизации своими действиями превратил его в переусложненный инструмент, непригодный для решения базовых задач современного программирования. Давайте рассмотрим, как именно комитет саботирует развитие языка.
Комитет создал порочную практику бесконтрольного добавления новых возможностей без удаления устаревших. C++ превратился в настоящего монстра, где даже для такой базовой операции как создание строки или умного указателя существует множество способов. Такое разнообразие не только затрудняет обучение языку, но и создает реальные проблемы при разработке, когда разные библиотеки используют разные подходы к решению одних и тех же задач.
Часто слышу такой вопрос от коллег и знакомых. Очевидно, что короткого ответа тут недостаточно, собеседник приведёт контраргументы, что в итоге выльется в жаркий спор. Обычно в результате такого спора единое мнение не формируется, каждый остаётся при своём.
Всё дело в том, что этот вопрос сам по себе является риторическим, провоцирующим спор. «Правильность» ответа существенным образом зависит от контекста, который у каждого собеседника, как правило, свой собственный. Контекстом в данном случае будет разное понимание смысла слов вопроса.
Однажды мне захотелось изучить Kubernetes и мобильную разработку, но не знал, с чего начать. В то же время меня сильно тревожило отсутствие в интернете новостей без политической повестки и негативного окраса. Отовсюду лился поток манипулятивной информации, и я мечтал о фильтре, который бы отсеивал весь этот информационный шлак.
Это моя небольшая история, как я за месяц написал карманное медиа с полной автоматизацией, где роботы-ведущие заменили кожаных мешков и ведут подкасты, в которых шутят про AI
Осторожно: эта статья точно будет хабратортной, ведь в ней мы смоделируем, спроектируем и запрограммируем своё видение N-Gage 2! Я очень старался сделать статью интересной даже для тех читателей, кто не разбирается в теме 3D-печати и программирования микроконтроллеров :-)
Я очень люблю ретро-игры и игровые консоли. Иногда я люблю позалипать в какую-нибудь классику с NES, Sega Mega Drive или, например, PSP. Однако особое место в моём сердечке занимает игровой телефон Nokia N-Gage, который, к сожалению, не получил продолжения, как и его более современный собрат — Sony Ericsson Xperia Play. Недавно я пересматривал свою коллекцию девайсов и обнаружил на полочке Galaxy S4 Mini. И тут я подумал: а что если...
В мире IT профессий существует множество ролей и должностей, каждая из которых требует определенного уровня знаний и опыта. Одной из ключевых фигур в этой области является senior developer. Давайте обсудим в этой статье, кто же является сениором, а кто нет.
За последние три недели я устранил пару проблем с производительностью, что потенциально сэкономило компании несколько сотен тысяч долларов (я подрядчик, поэтому, к сожалению, не получаю никаких премий).
Как я нашёл эти проблемы? Можно назвать это необъяснимой, основанной на опыте интуицией, шестым чувством нёрда; у меня просто возникло ощущение, что с системой что-то не так. За свои двадцать с лишним лет опыта я видел множество приложений и знал, что где-то в этой системе есть узкое место.
Я создал тестовый сценарий, чтобы точно замерить пропускную способность системы от времени, запустил инстанс VisualVM и прошерстил десятки потоков, трассировок стеков, снэпшотов памяти и CPU. Я обнаружил проблемы, написал их исправления и запустил всё заново. Бум! Производительность возросла в десять с лишним раз. Мой начальник и коллеги были счастливы, а продуктивность повысилась. Меня похвалили, и я ощутил отдачу от выполненного долга.
Но стоит помнить, что, строго говоря, это не были баги. Успешно проходили все юнит-тесты и интеграционные тесты, тесты BDD, линтеры, статический анализ кода и было выполнено несколько раундов проверок кода. Проблемы заключались в двух невинных строках кода (спрятанных среди тысяч других), казалось бы, не вызывавших никаких трудностей. Слава Богу, проблемы были найдены на этапе разработки и не затронули ни одной системы в продакшене (мои коллеги теперь могли выполнять свои тесты быстрее, поэтому скорость разработки сильно возросла).
Расскажу вам историю о том, как я далеко не в первый раз столкнулась с багом компилятора. Дело в том, что я уже довольно хорошо научилась распознавать случаи, когда проблема заключается совсем не в моём коде.
На протяжении более двух лет я много времени уделял разработке моего собственного эмулятора Game Boy, GameRoy. Я немало успел сделать. В эмуляторе был готов графический пользовательский интерфейс (с отладчиком и дизассемблером), сама программа прошла многочисленные тесты и могла сравниться с некоторыми наиболее точными эмуляторами. Я даже портировал её на Android!
Если какое-то действие приходится выполнять слишком часто — значит, пора его автоматизировать.
Разбираю полезные скрипты — от работы с файлами до DevOps. В каждом разделе есть примеры для новичков и более опытных разработчиков. А в конце статьи — несколько простых правил, которые помогут писать удобный и надёжный код.
Мы часто рассказываем о KasperskyOS — микроядерной ОС для подключенных к Интернету систем с особыми требованиями к кибербезопасности. И периодически получаем закономерный вопрос: а где можно пощупать эту вашу KasperskyOS? Поскольку на данный момент KasperskyOS является закрытой операционной системой, мы пока не готовы раскрыть ее исходный код. Однако всем, кому это интересно, можем предложить познакомиться с KasperskyOS Community Edition SDK (KasperskyOS CE SDK). В этом посте мы расскажем, из чего состоит SDK, и разберемся, как взаимодействовать с нашей операционной системой.
KasperskyOS CE SDK — это общедоступная версия KasperskyOS, разработанная с целью демонстрации основных принципов разработки безопасных решений. С помощью Community Edition SDK вы можете разрабатывать свои проекты, основываясь на подходе Secure by Design, то есть с учетом безопасности, заложенной в архитектуру решения.
Привет! Это Леша Жиряков, техлид backend-команды витрины онлайн-кинотеатра KION. В прошлый раз я писал про Msgspec vs DataClasses, а сегодня поговорим о пакетных менеджерах.
В жизни каждого разработчика наступает момент, когда нужно воспользоваться сторонней библиотекой — для работы с данными или отправки запросов в БД. А после выбора библиотеки и версии — использовать менеджер пакетов.
Вы когда-нибудь оказывались в неловком положении на собеседовании, когда вас спрашивают: «Может, у вас есть к нам вопросы?» Это момент, которому не учат в университетах или на курсах по тестированию, но он может стать критическим развилкой на вашем профессиональном пути. Если вы только пробиваете себе дорогу в мире IT и это ваше второе или третье собеседование, то умение задать правильные вопросы может стать вашим личным компасом в определении, находитесь ли вы на пороге мечты или очередной галеры? На просторах Хабра можно найти множество статей на подобные темы, большая их часть сосредоточена на обсуждении таких аспектов, как зарплаты, отпуска, бонусы и так далее.
Меня зовут Влад я работаю в VK на позиции QA Engineer. Хочу поделиться своим топом вопросов для собеседования на позицию тестировщика, которые я собрал благодаря прохождению не одного десятка собеседований. Они помогут вам понять, с какой компанией вам предстоит иметь дело.
[Прим. пер.: на Хабре уже был перевод этой статьи, но незавершённый примерно на четверть.]
Неправда.
Калькулятор должен показывать результат введённого математического выражения. А это намно-о-ого сложнее, чем кажется.
В этом посте я расскажу величайшую историю о разработке приложения-калькулятора.
На изображении выше показан калькулятор из iOS.
Заметили что-нибудь?
Он посчитал неправильно.
(10100) + 1 − (10100) равно 1, а не 0.
Android считает правильно. А причина, по которой он это делает, абсолютно безумна.
Разрабатывая свою игру, движок или фреймворк, вы в любом случае столкнетесь с необходимостью реализации системы загрузки ресурсов, выполнения задач вне основного цикла игры, вынесения различных подсистем (звук, рендер, физика, эффекты) в отдельные потоки, чтобы снизить время подготовки кадра и улучшить общую производительность. Будучи классическим программистом, вы, наверное, знаете о проблемах реализации многопоточности, использовании блокировок и алгоритмов, которые основаны на блокировках.
В обычном программировании с блокировками, когда возникает необходимость пошарить данные, приходится использовать механизмы сериализации доступа к таким данным, чтобы операции, выполняющие работу с такими данными, были ограничены от одновременного вмешательства со стороны других потоков и возможности их поломать. В прямом смысле поломать. Даже такая простая операция, как ++count, где count имеет тип integer, требует блокировки, поскольку операция инкремента в общем случае представляет собой трехшаговую операцию (чтение, модификация, запись), которая не является атомарной. Про что-то более сложное и длительное я уже и не говорю.
За кажущейся простотой скрывается множество граблей и ловушек: взаимные блокировки (deadlock), «голодание» потоков, асинхронные ошибки. Это похоже на попытку дирижировать оркестром, где музыканты игнорируют ритм. Проще говоря, любые действия над данными могут привести к проблемам, и чтобы этого не происходило, операции над данными должны быть атомарными, это решается вводом в код примитивов синхронизации, вроде мьютексов, семафоров, спинлоков.
Первая хорошая сторона программирования с блокировками состоит в том, что пока ресурс заблокирован, никакая другая логика не может вмешаться. Вторая хорошая сторона — люди прекрасно понимают, читают и работают с таким кодом, потому что он хорошо вписывается в "естественное" понимание устройства мира. А вот дальше начинаются проблемы...
Меня заинтриговал комментарий GuB-42 на Hacker News:
При помощи последовательностей ZWJ (Zero Width Joiner) теоретически можно закодировать в один эмодзи неограниченный объём данных.
Действительно ли можно закодировать в один эмодзи произвольные данные?
tl;dr: да, однако я нашёл решение и без ZWJ. На самом деле, можно закодировать данные в любой символ Unicode. Например, в этом предложении есть скрытое послание: This sentence has a hidden message󠅟󠅘󠄐󠅝󠅩󠄜󠄐󠅩󠅟󠅥󠄐󠅖󠅟󠅥󠅞󠅔󠄐󠅤󠅘󠅕󠄐󠅘󠅙󠅔󠅔󠅕󠅞󠄐󠅝󠅕󠅣󠅣󠅑󠅗󠅕󠄐󠅙󠅞󠄐󠅤󠅘󠅕󠄐󠅤󠅕󠅨󠅤󠄑. (Попробуйте вставить его в декодер.)
