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

2025 год щедро раздаёт нейросети всем желающим. Кажется, уже невозможно открыть браузер, чтобы на тебя не посмотрела очередной умник, обещающий сгенерировать гениальный текст, как у Толстого, но быстрее.

Одни модели сочиняют музыку, другие красят фотографии, третьи уверяют, что понимают людей лучше психологов. Но за громкими именами вроде ChatGPT, Midjourney и Runway скрывается подлесок маленьких, но интересных проектов.

Мы собрали десятку инструментов, на которые стоит обратить внимание.

Приятного чтения!

Я — школьный учитель информатики с большим стажем работы. За это время я видел смену эпох: Pascal уступил Python, веб вытеснил десктоп, а сегодня центр внимания занимает машинное обучение. Казалось бы, я видел всё и мог бы безошибочно отличить живую технологию от музейного экспоната.

И вот, листая рейтинг TIOBE, я обнаружил в топ-20… Fortran. Более того, он поднялся с третьего десятка почти в топ-10, обогнав такие языки, как Swift и Ruby. Казалось, что этот «старичок» давно покоится в истории, но факты оказались упрямее стереотипов.

Некоторое время назад меня попросили обосновать, почему я за Pascal при обучении программирования. А я скорее не конкретно за Pascal, я за наличие у языка для обучения программированию ряда важных свойств. Получается, я скорее против Python (шутка). В результате получилась эта мини-статья.

Пару недель назад, когда я писал пост The Hidden Cost of URL Design, мне нужно было добавить подсветку синтаксиса SQL. Я направился на веб-сайт PrismJS, пытаясь вспомнить, можно ли добавить его в качестве плагина. Меня утомило количество вариантов на странице скачивания, поэтому я вернулся к своему коду. Поискав в файле PrismJS, я нашёл в его начале комментарий, содержащий URL:

/* https://prismjs.com/download.html#themes=prism&languages=markup+css+clike+javascript+bash+css-extras+markdown+scss+sql&plugins=line-highlight+line-numbers+autolinker */

Я совершенно забыл об этом. После нажатия на URL меня перенаправило на страницу скачивания PrismJS, где все чекбоксы, раскрывающиеся меню и опции были заранее выбраны и полностью соответствовали моей конфигурации. Подобраны темы. Настроены языки. Включены плагины. Всё идеально было воссоздано из этого единственного URL.

Это стало одним из тех моментов, когда ты внезапно снова осознаёшь важность чего-то. Передо мной был URL, не просто указывающий на страницу: он хранил состояние и позволял полностью воссоздать все мои настройки. Не нужна никакая база данных, никакие куки, никакое localStorage. Достаточно одного URL.

Я задумался: как часто мы, фронтенд-разработчики, забываем об URL как об инструменте управления состоянием? Мы пытаемся использовать для этого всевозможные абстракции: глобальные хранилища, контексты, кэши, забывая при этом одну из самых древних и изящных фич веба: скромный URL.

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

Ночь. Курсор мигает, как маяк в тумане. Логи шепчут о том, что в коде — своя улица, свои правила и кодекс общения. Объекты — не безмолвные элементы системы. У каждого свой характер, привычки и слабости. Один щёлчок и поведение меняется: кто-то отдаёт приказы, кто-то внимательно прислушивается, а кто-то терпеливо ждёт сигнала. Эта статья — карта такого города.

Всем привет! Меня зовут Бромбин Андрей и сегодня разберёмся в поведенческих паттернах ООП. Короткие определения, идеи через ясные метафоры и рабочие примеры на Java. Всё это для того, чтобы система не трещала по швам, а решения были ясными, предсказуемыми и поддерживаемыми.

Это началось со статьи «Алгебраические типы данных на самом деле не такие страшные». Мы знаем о типах‑суммах и типах‑произведениях. Но задумывались ли вы когда‑нибудь о том, откуда они получили такие имена, и как вообще были открыты они и их свойства? Я провел последнюю неделю в кроличьей норе истории, и я просто обязан поделиться тем, что я нашёл.

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

Взгляд на интеграцию ИИ в программирование от опытного программиста (миллион строк кода я, наверное, написал за всю жизнь). Текст писал я сам, это не мусор от GPT, ИИ здесь только исправил ошибки.
Если дать этот текст ИИ на фактчек, то он может как полностью подтвердить мою статью кучей проверенных фактов, так и полностью опровергнуть, и тоже с кучей фактов, т.е. по сути будет заниматься черри-пикингом - всё зависит от формулировки вопроса. И где же тогда правда? Правда, я думаю, у тех, кто в этой среде годами работает и получает много опыта как разработки с ИИ, так и без него. Т.е. имеет хоть какие-то экспертные знания. В этой статье мнение одного из таких людей. Мнения одного человека, конечно, мало, нужно обобщать опыт сотен людей из разных сфер программирования. Я вношу в это обобщение свой небольшой вклад.

Может ли Rust заменить C? Этот вопрос беспокоил меня много лет. Тем временем я успел написать upb — библиотеку C для работы с Protocol Buffers, и сейчас являюсь её техническим руководителем. Вполне понятно стремление обеспечить безопасность памяти в пределах всего программного стека — поэтому и возникла идея портировать upb на Rust.

Притом, что мне приятны базовые принципы Rust, я долгое время относился к этой идее скептически и сомневался, что, портировав upb на Rust, удастся сберечь её производительность и компактность кода, которые мы с коллегами так старались оптимизировать. На самом деле, исходно я собирался написать статью о том, почему именно применительно к upb языку Rust никогда не сравниться с C по производительности.

Но недавно я открыл для себя одну технику, которая заставила меня немного переосмыслить этот вопрос. Я назову её «Rust без паник». Притом, что этот метод определённо не нов, мне нигде не удалось найти подробного разбора, в котором бы рассказывалось, как именно этот метод используется и какие проблемы решает. Правда, интересная дискуссия по этому поводу велась в теме Enforcing no-std and no-panic during build, где есть ссылки на некоторые релевантные треды из почтовой рассылки, посвящённой разработке ядра Linux. Вот другой интересный тред: Negative view on Rust: panicking

Надеюсь, эта статья позволит заполнить данный пробел.

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

В каждом моём профессиональном и личном проекте рано или поздно требовался diff для визуализации изменения или применения патча. Однако меня никогда не устраивала ни одна из свободно доступных библиотек diff. В профессиональной деятельности это никогда не вызвало особых проблем, но в личных проектах я копировал и модифицировал из проекта в проект собственную библиотеку. Однажды я рассказал об этом коллеге, и тот наставил меня на путь публикации моей библиотеки на Go (порта библиотеки на C++, которую я раньше копировал и модифицировал). И оказалось, что я сильно недооценивал то, насколько близка моя библиотека к возможности публикации!

Как бы то ни было, я опубликовал её и узнал много нового об алгоритмах diff. Библиотеку можно найти по адресу znkr.io/diff, а в этой статье я расскажу о своих открытиях. Я ещё не завершил освоение, поэтому планирую дополнять статью в процессе изучения.

Представьте, что данные вашей компании украли злоумышленники и теперь просят баснословный выкуп. Или что вы безвозвратно утратили все свои рабочие и личные архивы — фото, документы, важные файлы.

Чувствуете неприятный холодок? Не бойтесь, в наших историях счастливый финал. Прочитайте их и проверьте, можете ли вы оказаться в подобной ситуации. А еще получите промокод на 1 000 бонусов в панели Selectel.

Привет, Хабр! Меня зовут Виктор Смирнов. В Yandex Infrastructure я c недавнего времени занимаюсь фронтендом YQL: транслятором и инструментами разработки.

В этом посте я расскажу про новый модуль автодополнения запросов на YQL, а также продемонстрирую, как он преобразил консольный клиент YDB CLI.

У 82-летнего Кена Томпсона сохранились потрясающие воспоминания о первых днях операционной системы Unix и о буйной команде её разработчиков-гиков.

В этом месяце Музей компьютерной истории Кремниевой долины в партнёрстве с Ассоциацией вычислительной техники выпустил специальный выпуск на четыре с половиной часа, записанный полтора года назад историком технологий Дэвидом Броком. В этом выпуске Томпсон подробно перечислил многие из важных моментов своей карьеры — от работы над языком программирования C и Unix до операционной системы «Plan 9 from Bell Labs» и языка программирования Go.

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

Также по ходу дела Томпсон рассказывает историю о маленьком аллигаторе, которого друг отправил его в офис в Bell Labs. («Его просто принесли, как почту… Не самый лучший из питомцев»).

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

Эта статья — впечатления о моём 600-дневном марафоне на этой платформе, динамике моих скилов и ответе на главный вопрос «надо ли решать там задачи?».

Все было спокойно, пока мы с другом не заключили спор — сможем ли мы решить 100 задач до конца 2023 года? А это было 50 задач всего за 1 месяц — декабрь.

На одном из моковых собеседований мы услышали, что для прохождения алгоритмического этапа может хватить решения 50 задач на Литкоде. 

Челлендж в 100 задач оказался достаточно легким — Новый год мы встречали уже с круглым числом выполненных задач в профиле. Так быстро мы решили не останавливаться — Покоренная вершина стимулировала покорить новую — 200 задач к началу лета (за 5 месяцев).

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

24 февраля 2024 в течении недели Leetocde предлагал неплохие и не очень сложные задачи на дейли челлендже, и у меня случайно получился стрик в районе 10 дней подряд.

Сбивать стрик было как‑то жалко — это же целых 10 дней. Так и началась долгая история в 600 дней...

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

Вот, казалось бы, что может быть проще: создать базу треков и исполнителей. Пишем имя артиста/группы, название альбома, список треков и даем возможность по ним искать. Но потом натыкаемся на исполнителя Prince, который изменил своё имя на знак, который не существует и начинаем печалиться, потому что непонятно, как его искать после переименования. Фанаты вроде как нашли выход и предложили использовать 4 спец.символа юникода Ƭ̵̬̊, что тоже похоже на костыль, а задавать старое имя как псевдоним, вроде как концептуально неправильно. Ну или попадаются металлюги Brouillard, у которых каждый альбом называется так же - Brouillard. А каждый трек внутри альбома имеет такое же название.

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

Хочу перенестись в нулевые, чтобы рассказать и показать, как работал ILOVEYOU. Для этого запускаю машину времени и рассказываю:

• Что бы случилось с моим компом в нулевые.
• Как вирус взломал 45 миллионов компьютеров?
• Почему Windows 2000 оказалась особенно уязвимой?
• Как автор избежал наказания?

Всем привет! Меня зовут Олег Смоляков, в Яндексе я больше 15 лет занимался разработкой, а теперь отвечаю за улучшение процесса найма разработчиков.

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

TLDR: мы решили обновить процесс найма, вместо порой хаотичных собеседований в каждом отдельном сервисе внедряем единую систему оценки по профессии и уровню (например, «Senior C++ Developer»), кандидат, успешно прошедший оценку навыков, теперь сможет претендовать на аналогичные вакансии в любом из 90+ сервисов компании, а всё это вместе делает процесс найма прозрачным, понятным, без дублирования технических интервью и в целом эффективным для всех участников.

А теперь подробнее о том, почему мы на это пошли и как всё устроено.

Утечка оперативной памяти в Apple Calculator достигает 32 ГБ.

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

Случись такое в 2000-х, это бы привело к внесению срочных патчей и служебной проверке. Сегодня же это лишь очередной баг-репорт в очереди.

Мы урегулировали программные катастрофы такой степени, что утечка 32 ГБ в калькуляторе уже не удивляет. И дело не в ИИ. Кризис с качеством ПО начался за несколько лет до появления ChatGPT. ИИ лишь стал дополнительным инструментом в руках некомпетентных людей.

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

Одно из правил - буквально слово в слово - я недавно встретил в одном популярном эссе о написании кода без ошибок (я расскажу об этом правиле позже). Мне стало любопытно, насколько применимы остальные правила со школьного плаката (короткий ответ – да), и есть ли у этого обоснование. Я немного зарылся в литературу, и вот что понял.

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

Готовится релиз. Сроки подходят. Мне скидывают странный баг: Наше приложение вдруг стало жаловаться на невозможность соединиться с соседним.

А почему не может? Защищённое соединение не устанавливается.

А почему не устанавливается? Файлы сертификатов для этого соединения не удаётся загрузить.

А почему файлы не грузятся? А потому что путь к файлам "отсутствует в конфигурации".

А если руками залезть и глазами посмотреть - присутствует. Чудеса! Эффект Шрёдингера!