Я уже более десяти лет веду собственные дотфайлы и за это время написал множество скриптов оболочки. В этой статье я решил поделиться с вами теми из них, которые сам применяю регулярно.
Взгляд на интеграцию ИИ в программирование от опытного программиста (миллион строк кода я, наверное, написал за всю жизнь). Текст писал я сам, это не мусор от 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. ИИ лишь стал дополнительным инструментом в руках некомпетентных людей.
Мне повезло в жизни, так как моя учительница русского языка и литературы в старших классах была педагогом с большой буквы. В выпускном классе мы особенно любили пятничные уроки литературы - читали стихотворение малоизвестного (нам) поэта или слушали песню какой-нибудь рок-группы и писали мини-сочинение об услышанном За спиной у нашей учительницы висел небольшой плакат с правилами и рекомендациями по написанию текстов. На эти правила она указывала, когда объясняла, как улучшить нашу малограмотную подростковую писанину.
Одно из правил - буквально слово в слово - я недавно встретил в одном популярном эссе о написании кода без ошибок (я расскажу об этом правиле позже). Мне стало любопытно, насколько применимы остальные правила со школьного плаката (короткий ответ – да), и есть ли у этого обоснование. Я немного зарылся в литературу, и вот что понял.
Сия заметка не столь для программистов, многие из которых уже сталкивались с подобным, и только улыбнутся "ну, открыл Америку" - а больше для разного рода менеджеров, заказчиков и всех кто считает что достаточно лишь нанять умных разработчиков, и дело в шляпе. Вот шляпой дело нередко и оборачивается.
Готовится релиз. Сроки подходят. Мне скидывают странный баг: Наше приложение вдруг стало жаловаться на невозможность соединиться с соседним.
А почему не может? Защищённое соединение не устанавливается.
А почему не устанавливается? Файлы сертификатов для этого соединения не удаётся загрузить.
А почему файлы не грузятся? А потому что путь к файлам "отсутствует в конфигурации".
А если руками залезть и глазами посмотреть - присутствует. Чудеса! Эффект Шрёдингера!
Привет Хабр! Как-то так случилось, что кто-то очень хитрый, в одном НИИ, подключил обычный бытовой увлажнитель BALLU UHB-1000 к фитотрону(ака гроубоксу). Вот и встала задача добавить управление этим устройством.
За годы в разработке я всё чаще ловлю себя на мысли, что современные программы - словно построены из пластмассы: аккуратные, масштабируемые, но холодные. И когда я читаю старые исходники - с комментариями, с юмором, с уважением к читателю - понимаю: там был человек. Эта статья - не попытка идеализировать прошлое, а скорее разговор о том, почему код, написанный сорок лет назад, часто выглядит честнее и человечнее, чем многое из того, что мы создаём сегодня.
Когда включаешь компьютер, видишь привычное окно с кнопкой «Пуск» и даже не задумываешься, что это результат десятков лет борьбы — технической, рыночной и даже судебной и политической. Операционная система Windows давно стала синонимом персонального компьютера. В этой статье мы разберём, как Microsoft смогла создать удобную систему и сделать её стандартом для всего мира: какие шаги, решения и ошибки привели Windows к господству на миллионах машин.
Мы переживаем величайший кризис качества программного обеспечения в истории вычислительной техники. Калькулятор теряет 32 ГБ оперативной памяти. ИИ-помощники удаляют рабочие базы данных. Компании тратят 364 миллиарда долларов, чтобы избежать решения фундаментальных проблем.
Когда вы работаете с объектами и массивами в JavaScript, может показаться, что они ведут себя странно: изменение одной переменной неожиданно влияет на другую. Все это — следствие работы ссылочных типов данных.
Привет, Хабр! Меня зовут Александр Дудукало, я автор базового курса по JavaScript. В этой статье я простыми словами расскажу, как работают ссылки, почему это важно знать и как правильно копировать объекты.
Привет, Хаброжители!
O’Reilly становится ближе! На книги из категории O'Reilly и Head First O'Reilly действуют скидки, теперь ваши любимые бестселлеры доступны ещё выгоднее!
