Представьте: на заводе в Тобольске сломалась установка иностранного производителя. Нужен их эксперт. Он находится в Китае или в лучшем случае в Москве. Пока оформят визит, пока доберется — минимум трое суток. Установка стоит. Производство теряет миллионы рублей каждый день.
Один выезд такого специалиста стоит от 500 тысяч до миллиона рублей. А таких ситуаций десятки в год на каждом заводе...
Вообще-то на Хабре уже были статьи про Go-ассемблер, но они перегружены мудрёными терминами, разной низкоуровневой спецификой и не дают ясного понимания когда и зачем нам помогут помочь ассемблерные функции.
В этой статье я постараюсь дать больше сути, необходимый минимум, чтобы стало ясно, в каких случаях и зачем нам может помочь ассемблер в Го. Ну и с чем его едят.
За долгий период существования IT в прод уходила не одна тысяча багов. Большинство из них были безобидными и исчезали после следующего патча. Но отдельные приводили к катастрофам. Буквально. Анализируя тему крупных техногенных провалов, я удивился одному: за большинством этих инцидентов стояли не сложные цепочки событий, а маленькие, пустяковые на первый взгляд детали. Вот тут что-то забыли дописать, тут понадеялись, что пронесет, там решили что «и так сойдет». А итог — многомиллионные убытки, удар по репутации и потерянные жизни.
Рассмотрим на примерах, почему не стоит недооценивать баги.
Привет, Хабр!
Мне нравится рассказывать про красивые и удобные интерфейсы. Всю свою карьеру я старался делать всё, что мог для комфорта пользователя.
Но также я встречал фронтендеров, которые не тратили много времени, продумывая взаимодействие пользователя с интерфейсом. Им было всё равно, а некоторые даже хотели специально подложить какую-то «какашку».
Я подумал, что надо им помочь сделать ужасный интерфейс! Составил список решений, которые заставят пользователя подумать о разработчиках не очень хорошо.
Давайте посмотрим, что я вам подготовил.
Доброго времени суток, господа и дамы! Иногда у некоторых людей возникает желание заняться откровенным непотребством в программировании — то, что не несет практической пользы напрямую, но помогает развлечься. И я — не исключение. В этой статье я хочу рассказать вам о лайфхаках, трюках (магических и не очень), алгоритмах на языке C!
Идея написать эту статью зародилась из моего поста, после него я написал статью «Математика, биты, магия и немного ненормального программирования на C» и «Фокусы, хаки, магия и прочее ненормальное программирование на C», которые раскрывали много интересных моментов. Увидев, что многим понравилась, я задумался: почему бы не изучить еще какие-нибудь трюки, заодно практикуясь в программировании на C?
В этой статье будет еще больше всевозможных генераторов псевдослучайных чисел, гонок за скоростью и производительностью, алгоритмов, хаков и трюков!
Всех, кто заинтересовался — прошу под кат.
Когда инфраструктура растет, команды множатся, а сервисы переходят на распределенную архитектуру, специалистам становится сложнее отслеживать события, которые происходят в системе. Рано или поздно наступает момент, когда кто-то произносит фразу: «А кто это сделал?» Иногда она звучит спокойно, а иногда — с легкой дрожью в голосе, например, когда исчезла виртуальная машина, изменились права доступа или сбились настройки сети.
Здесь и начинается расследование. Если у компаний нет централизованных логов, анализ действий напоминает детектив без улик: много версий, мало фактуры. Чтобы со всем этим разобраться, мы создали сервис аудит-логов — это те самые факты, с помощью которых можно найти первопричину инцидента.
Привет! Меня зовут Кристина, я старший менеджер продуктов клиентских сервисов в Selectel. В этой статье расскажу, как устроен сервис, какие задачи решает, из чего состоят логи, а также — как интегрировать их с системами безопасности и аналитики.
Случалось такое? 19:00. Мы закрываем рабочие ноутбуки. Мы — Senior Developers, архитекторы, тимлиды. Люди, которые сегодня днем жонглировали абстракциями и решали проблемы на миллионы рублей. У нас был план: вечером покодить свой пет-проект, выучить Rust или хотя бы почитать ту самую доку по архитектуре.
Привет! Меня зовут Дима Кривопальцев, я тимлид бэкенд‑команды Яндекс Диска (Яндекс 360). Уже больше семи лет я занимаюсь разработкой высоконагруженных распределённых систем — и в статье расскажу об одной из них.
В Яндекс 360 есть сервисы с очень большими нагрузками — и по RPS, и по объёму хранимых данных, и по числу обрабатываемых асинхронных задач. Именно последняя часть — асинхронная обработка — будет в центре этого рассказа.
Тема может показаться немного провокационной: речь пойдёт об очередях поверх SQL‑баз, а в сообществе такое решение принято считать антипаттерном — и на это есть основания. На конференциях и в статьях обычно можно услышать скепсис: «Очередь на PostgreSQL? Не стоит даже пытаться». Действительно, подобных попыток было много, и почти все сталкивались с типовыми проблемами — от блокировок до деградации производительности.
Тем не менее, в реальности у многих крупных компаний всё равно есть свои очереди, построенные поверх SQL‑баз — как PostgreSQL, так и MySQL. Это решение встречается и в российских, и в зарубежных командах. Яндекс Диск здесь не исключение — у нас тоже есть своя реализация, о которой сегодня и пойдёт речь.
Небольшой рассказ про то, как копеечная деталь рушит всю концепцию, и почему обычный пользователь этого не заметит. А также про общую проблему всех мощных автомобильных зарядок.
Каждую пару лет кто-нибудь замечает, что крупные технологические компании иногда пишут на удивление мусорный код. Если вы не работали в большой компании, то вам может быть сложно понять, почему это происходит. Уровень зарплат в крупных технологических компаниях позволяет привлекать многих компетентных разработчиков. Они работают довольно неспешно, поэтому создаётся впечатление, что у них достаточно времени, чтобы выполнять работу качественно. Как же появляется плохой код?
Компании ежедневно генерируют большие объемы данных, но далеко не вся информация одинаково важна: со временем многие данные становятся менее востребованными, продолжая занимать дорогие и высокопроизводительные накопители (SSD, RAM). В результате хранение таких «холодных» данных обходится неоправданно дорого, поскольку потребность в постоянном доступе к ним минимальна.
Решение проблемы — технология охлаждения данных, которая предполагает перемещение редко используемой информации на более дешевые и емкие носители, то есть файлы остаются доступными, но перестают нагружать дорогие и быстрые устройства. Именно такой механизм охлаждения данных мы добавили в Tarantool DB 3.0.
Привет, Хабр. Меня зовут Сергей Фомин. Я старший менеджер продукта Tarantool DataBase. В этой статье я расскажу, как именно мы реализовали механизм охлаждения и какие бизнес-выгоды могут получить компании при его использовании.
Новые видеокодеки моментально улучшают жизнь миллионов людей. Тем не нужно прикладывать практически никаких усилий, разве что обновить железо или софт. После этого видеофайлы магически уменьшаются в размере, качество картинки становится лучше, видео в интернете перестаёт тормозить и т. д. Например, новый видеокодек AV2 уменьшает трафик на 30%.
Единственный недостаток — время кодирования увеличивается, потому что используются сложные интеллектуальные технологии (например, психофизические модели зрения и мозга, новые способы предсказания будущего (межкадровых изменений) по предыдущим кадрам, последние открытия в математике (вроде треллис-квантования). Появляется ощущение некоего волшебства. Вообще, эффективное сжатие напрямую связано с пониманием данных, то есть с уровнем интеллекта. Чем глубже понимание смысла, тем больше мы видим аналогий, паттернов, циклов и рекурсий, которые можно использовать для «упаковки» информации.
Как говорится, достаточно продвинутая технология неотличима от магии. Так и видеокодеки нового поколения — это настоящая программная магия.
Недавно на барахолке (вот предыдущая статья про нее) я наткнулся на Nokia N70. Это смартфон, который в середине нулевых был почти что идеальным средством общения, да еще и локальным медиацентром. Покупая этот гаджет, мы получали мощную по тем временам камеру, быстрый 3G и ощущение, что все «летает». Увидев это чудо на блошином рынке, я решил купить его, разобрать и глянуть, что там внутри. Мой девайс чуть побит жизнью, но ничего фатального. Поэтому не удивляйтесь, что на фото не «новье». Попутно расскажу, как появилась эта модель, что в ней было необычного и почему она до сих пор вызывает ностальгию у тех, кто застал ту эпоху.
Всё началось с внутреннего предложения на работе присоединиться к отделу по развитию и поддержке веб-сайтов (название другое, но это их обязанности, поэтому написал так). Это была одновременно лестная и пугающая перспектива. Возможность работать над реальными проектами манила, но мой опыт в веб-разработке был скорее теоретическим. Я понимал, что для старта мне нужен был собственный, понятный проект, который стал бы началом.
И тут я вспомнил о своей идее сделать сайт для консольной реализации шахмат на Python. Это была сухая игра, написанная на Pygame для двоих программистов, но не для людей, так как её нельзя было запустить на других устройствах. И у меня родилась идея: а что, если превратить этот скелет игры в веб-приложение на JS?
Из минусов было только то, что моя игра написана на языке Python, а для работы мне нужен JavaScript, и я решил, что это не проблема, и начал переписывать готовую логику на новый язык, параллельно добавляя новые функции.
Идея зацепила сразу, представьте: вы переносите свой проверенный, рабочий кейс, у которого вся шахматная логика (проверка ходов, матов и пат) уже работает и ничего нового придумывать не надо, нужно только сделать интерфейс для браузера и все новые идеи (например, таймер).
Самые интересные новости финансов и технологий в России и мире за неделю: РКН заблокировал FaceTime, Snapchat и Roblox, безвиз с Китаем и Саудовской Аравией, Россию внесли в черный список отмывания денег ЕС, в Южной Корее взломали домашние камеры наблюдения, Твиттер Маска оштрафовали в Европе, а также слухи о «чесночной» модели от OpenAI.
Что, если я скажу тебе, что у параметра нет вероятности?
Это самая распространенная и устойчивая когнитивная ошибка в Data Science. Она встречается в курсовых, в учебниках и даже в документациях библиотек.
Здесь мы напишем симуляцию на Python, увидим, как «прыгают» интервалы, поймем, как тут могут помочь пластмассовые игрушки советских детей, и узнаем, как же тогда математически точно отвечать менеджерам на их вопросы, чтобы они навсегда перестали с вами разговаривать.
Добро пожаловать в кроличью нору частотной статистики.
Три способа менять один объект из нескольких потоков. Больше нет
Mutex, CAS, акторы, STM, CRDT, иммутабельность, MVCC, Disruptor…
Когда читаешь про многопоточность, кажется, что способов — десятки, и каждый требует отдельного изучения.
На самом деле их ровно три. Всё остальное — реализации и комбинации.
Эта статья — попытка навести порядок в голове. После неё вы сможете:
за 5 секунд классифицировать любой подход к конкурентности;
понимать, почему Erlang выбрал акторы, а Java предлагает synchronized;
не изобретать велосипеды и не зацикливаться на «единственно правильном» решении;
проектировать многопоточный код, держа в голове простую модель.
Заодно, покажу почему ООП вообще не было изначально спроектировано под многопоток.
Думаю, что среди читательской аудитории Хабра многих бывших (а возможно, и действующих) олимпиадников, поэтому решил поделиться с сообществом наблюдениями и размышлениями об актуальных проблемах олимпиадного движения в стране. Коротко о том, какое я имею отношение к олимпиадному движению и почему считаю себя в праве публично высказываться на эту тему: я сам бывший олимпиадник (призёр Всероса по информатике), 15 лет веду кружки по информатике и программированию и, в том числе, готовлю школьников к выступлению на олимпиадах, среди моих учеников призёры Всероса по информатике, ВКОШП и других олимпиад по информатике и программированию, кроме того вот уже 10-ый год подряд я участвую в подготовке и проведении школьного и муниципального этапа ВсОШ по информатике в своём регионе.
Позавчера после опубликования результатов муниципального этапа по информатике этого года мама одного из участников прислала мне сообщение: "Я хочу сказать вам спасибо за дисквалы. Потому что списывание достигло какого-то маразма. И по другим предметам вообще ничего не боятся и ничего не стесняются". Речь идёт о том, что мы дисквалифицировали большое количество участников муниципального этапа за списывание друг у друга и за использование искусственного интеллекта при решении задач. В олимпиадах по информатике всё, что делает участник, фиксируется в тестирующей системе, и мы, жюри, имеем возможность анализировать это и на основании определённых критериев делать вывод о несамостоятельности выполнения работы. В силу специфики профессии мы, информатики, во-первых, имеем технические возможности бороться со списыванием, а, во-вторых, воспринимаем сложившуюся ситуацию как некий вызов, которому интересно попытаться что-то противопоставить. Но ситуация постепенно ухудшается. Ниже статистика дисквалификаций на муниципальном этапе ВсОШ по информатике по 9-11 классам по нашему региону:
Привет, Хабровчане!
Решил написать небольшую заметку о моем личном опыте взаимодействия с багбаунти программой Минцифры РФ. На самом деле у меня наберется много интересных историй так или иначе связанных с багбаунти, но некоторые из них являются особо примечательными. Об одной из них и пойдет речь в данной статье.
Для начала немного расскажу о себе. Опыт в ИБ у меня обширный и разнообразный. В данной сфере я уже чуть более 13 лет. Поработал на многих участках кибербеза, начиная от так называемого "папирсека" (специалист, отвечающий за подготовку всех необходимых документов по ИБ) до application security инженера. Работал и в органах государственной власти, и в компаниях с государственным участием и в чистой коммерции. В общем небольшое представление об ИБ имею.
ZX Spectrum я впервые увидел, ещё будучи школьником в гостях у одноклассника, и сразу решил, что совершенно точно хочу себе такой же компьютер. К сожалению, семья у нас была не из богатых, потому воплотить мечту в реальность я смог только в старших классах. Впрочем, приобрести готовый компьютер всё равно возможности не было, пришлось собирать «Спекки» из купленных на радиорынке запчастей при помощи старшего приятеля, имевшего навыки радиомонтажа. Увы, спаяли мы его плохо: комп перезагружался всякий раз, когда на кухне включался бабушкин холодильник, да и вместо монитора мне выделили старый чёрно-белый телевизор, категорически запретив распаивать разъём RGB на единственном в доме цветном «Рубине». В общем, вдоволь наиграться на «Синклере» у меня не получилось, потому сейчас, уже в зрелом возрасте, я купил незаконченный проект на базе современного ZX Evolution и решил довести его до ума. О том, что из этого вышло — мой сегодняшний рассказ.