Программирование *

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

Это моя небольшая история, как я за месяц написал карманное медиа с полной автоматизацией, где роботы-ведущие заменили кожаных мешков и ведут подкасты, в которых шутят про AI

Осторожно: эта статья точно будет хабратортной, ведь в ней мы смоделируем, спроектируем и запрограммируем своё видение N-Gage 2! Я очень старался сделать статью интересной даже для тех читателей, кто не разбирается в теме 3D-печати и программирования микроконтроллеров :-)

Я очень люблю ретро-игры и игровые консоли. Иногда я люблю позалипать в какую-нибудь классику с NES, Sega Mega Drive или, например, PSP. Однако особое место в моём сердечке занимает игровой телефон Nokia N-Gage, который, к сожалению, не получил продолжения, как и его более современный собрат — Sony Ericsson Xperia Play. Недавно я пересматривал свою коллекцию девайсов и обнаружил на полочке Galaxy S4 Mini. И тут я подумал: а что если...

За последние три недели я устранил пару проблем с производительностью, что потенциально сэкономило компании несколько сотен тысяч долларов (я подрядчик, поэтому, к сожалению, не получаю никаких премий).

Как я нашёл эти проблемы? Можно назвать это необъяснимой, основанной на опыте интуицией, шестым чувством нёрда; у меня просто возникло ощущение, что с системой что-то не так. За свои двадцать с лишним лет опыта я видел множество приложений и знал, что где-то в этой системе есть узкое место.

Я создал тестовый сценарий, чтобы точно замерить пропускную способность системы от времени, запустил инстанс VisualVM и прошерстил десятки потоков, трассировок стеков, снэпшотов памяти и CPU. Я обнаружил проблемы, написал их исправления и запустил всё заново. Бум! Производительность возросла в десять с лишним раз. Мой начальник и коллеги были счастливы, а продуктивность повысилась. Меня похвалили, и я ощутил отдачу от выполненного долга.

Но стоит помнить, что, строго говоря, это не были баги. Успешно проходили все юнит-тесты и интеграционные тесты, тесты BDD, линтеры, статический анализ кода и было выполнено несколько раундов проверок кода. Проблемы заключались в двух невинных строках кода (спрятанных среди тысяч других), казалось бы, не вызывавших никаких трудностей. Слава Богу, проблемы были найдены на этапе разработки и не затронули ни одной системы в продакшене (мои коллеги теперь могли выполнять свои тесты быстрее, поэтому скорость разработки сильно возросла).

1. Блокирует прикрепление к нему отладчиков.
2. Выполняет преждевременный выход при попытках инъецирования кода.
3. Приводит к вылету телефона целиком, если запустить её со включённым джейлбрейком (!).

• std::hive
• Constexpr, ещё больше constexpr
• Безопасность, контракты, hardening, профили, UB и std::launder
• Relocate
• #embed

[Прим. пер.: на Хабре уже был перевод этой статьи, но незавершённый примерно на четверть.]

Неправда.

Калькулятор должен показывать результат введённого математического выражения. А это намно-о-ого сложнее, чем кажется.

В этом посте я расскажу величайшую историю о разработке приложения-калькулятора.

На изображении выше показан калькулятор из iOS.

Заметили что-нибудь?

Он посчитал неправильно.

(10¹⁰⁰) + 1 − (10¹⁰⁰) равно 1, а не 0.

Android считает правильно. А причина, по которой он это делает, абсолютно безумна.

Меня заинтриговал комментарий GuB-42 на Hacker News:

При помощи последовательностей ZWJ (Zero Width Joiner) теоретически можно закодировать в один эмодзи неограниченный объём данных.

Действительно ли можно закодировать в один эмодзи произвольные данные?

tl;dr: да, однако я нашёл решение и без ZWJ. На самом деле, можно закодировать данные в любой символ Unicode. Например, в этом предложении есть скрытое послание: This sentence has a hidden message󠅟󠅘󠄐󠅝󠅩󠄜󠄐󠅩󠅟󠅥󠄐󠅖󠅟󠅥󠅞󠅔󠄐󠅤󠅘󠅕󠄐󠅘󠅙󠅔󠅔󠅕󠅞󠄐󠅝󠅕󠅣󠅣󠅑󠅗󠅕󠄐󠅙󠅞󠄐󠅤󠅘󠅕󠄐󠅤󠅕󠅨󠅤󠄑. (Попробуйте вставить его в декодер.)

Наверное, каждый второй разработчик на ПЛИС в начале своего пути пытался визуализировать работу своих схем. Кто-то подключал TFT-дисплей, кто-то — VGA монитор. А у меня под рукой оказался только телевизор с композитным входом. Ну что ж, работаем с тем, что есть!

Переезд большого сервиса с Perl на Golang едва ли кому-то покажется простой задачей. А теперь представьте, что это главная страница Яндекса, на которую ежедневно заходят миллионы пользователей. И что продукт постоянно дорабатывается, а значит, нельзя взять и остановить разработку на пару лет переезда. Представили? Сложно? А вот, оказывается, всё возможно. 

Привет, Хабр! Меня зовут Вячеслав Круглов. Я руковожу одной из команд разработки бэкенда главной страницы Яндекса. Расскажу, как мы переписывали бэкенд с Perl на Go, поделюсь интересными подробностями переезда, а также сравню компоненты и продуктовые блоки.

Привет, Хабр. Меня зовут Рогатнев Сергей. Я работаю в Контуре ведущим разработчиком уже более 7 лет. За это время я поработал как минимум над десятью разными проектами в разных командах. Это были и проекты с историей на 10 лет, и стартапы, делающие свои первые шаги. Где-то я был всего 2–3 месяца, а где-то задерживался на пару лет. Такой формат работы позволил мне увидеть совершенно разные подходы к работе и написанию кода. За это время я адаптировался к переходам и смене команд, но мой собственный code style практически исчез, потому что нет двух команд с одинаковым стилем.

В этой статье я хочу показать вам примеры таких холиваров, которые я встретил работая над разными C#-проектами.

// Смещение для корректировки кода ASCII каждого символа в строке кода ISO страны для определения соответствующего флага.
const EMOJI_CHARACTER_OFFSET = 127397;

const getEmojiForCountryCode = (countryCode: string) =>
  String.fromCodePoint(
    ...countryCode
      .toUpperCase()
      .split('')
      .map((char) => char.charCodeAt(0) + EMOJI_CHARACTER_OFFSET),
  );

// "en-US"
const currentLanguageCode = navigator.language;
// "US"
const currentCountryCode = currentLanguageCode.split("-")[1];
// "🇺🇸"
getEmojiForCountryCode(currentCountryCode);
// "🇫🇷"
getEmojiForCountryCode("FR");
// "🇸🇪"
getEmojiForCountryCode("SE");

Некоторое время назад я написал несколько статей о различных трюках, применявшихся в операционной системе DOS, чтобы вписаться в те жёсткие лимиты памяти, которые действовали в реальном режиме на архитектуре x86. Постоянно возникал и оставался без ответа один вопрос: а каковы были различные «модели», которые предлагались компиляторами тех времён? Взгляните, как выглядело меню для генерации кода в Borland Turbo C++.

Tiny (крошечный), small (маленький), medium (средний), compact (компактный), large (большой), huge (огромный)… Что означают эти опции? Каковы их эффекты? Ещё важнее… а так ли важен весь этот антиквариат сегодня, в мире 64-разрядных машин и гигабайтных ОЗУ? Чтобы ответить на этот вопрос, сделаем небольшой обзор архитектуры 8086 и тех двоичных форматов, которые поддерживались в DOS.

В СМИ много говорят о том, что разработчики ПО скоро потеряют работу из-за ИИ. Я в это не верю.

Это не конец программирования. Это конец программирования в том виде, в котором мы его знаем сегодня.

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

Тестовое задание

Перед собеседованием можно добавить этап выполнения тестового задания. Хорошее тестовое задание должно быть максимально приближено к реальным задачам. Чтобы оценить навыки, можно предложить что-то объёмное, например, разработку небольшого, но полнофункционального сервиса. Важно, чтобы кандидат сделал всё самостоятельно и в кратчайшие сроки — это покажет, насколько он заинтересован в позиции. Если человек отказывается от тестового задания, это говорит о недостаточной вовлечённости.

Собеседование

Сколько человек должно проводить собеседование? Оптимально 3-5. Один интервьюер может что-то упустить, а вот группа сможет задать вопросы с разных точек зрения.