Пользователь
Всем привет! Я Сергей, работаю в B2B-команде Яндекс Маркета последние 3,5 года. Как уже понятно из заголовка, сейчас я вам расскажу про yet-another-миграцию с базы на базу, которая началась в середине 2021 года и заняла почти год. Получается, мемуары.
Вас ждёт рассказ о том, как мы:
- несколько месяцев чинили тесты и делали трансформер;
- десятки раз переливали данные;
- чинили баги незаметно для пользователей;
- заставили сервис работать на PostgreSQL быстрее, чем он работал на Oracle.
На тему тайны переписки есть шутка про школьника, который не прочел письмо Онегина к Татьяне, поскольку это нарушение статьи 138 УК. Однако ранее везде действовал противоположный негласный закон — вскрывать и просматривать любую корреспонденцию. Для этого в XVII веке во Франции, а следом и во всей Европе были созданы специальные подразделения со зловещим названием «черные кабинеты» (cabinet noir). Попутно их деятельность подстегнула бурное развитие и выход криптографии на государственный уровень.
Мы побеседовали с Анастасией Ашаевой, кандидатом исторических наук и старшим научным сотрудником московского Музея криптографии. Она рассказала о начале эпохи «черных кабинетов» и том, что это были за структуры, какой вклад они внесли в государственные дела, дипломатию и вообще жизнь людей. Зашла речь и о шифрах того времени, а также интересных случаях, когда работа cabinet noir повлияла на ход истории.
Когда в бизнес приходят «эффективные менеджеры», стоит ждать беды. С программами урезания расходов, подкручиваниями KPI и прочими странными решениями бизнес может в краткой перспективе получить даже какую‑то выгоду для себя, но довольно быстро сталкивается с проблемами: сложно продать или просто угробить курицу, несущую золотые яйца, и ожидать, что золотые яйца продолжат появляться.
Иногда решения этих эффективных менеджеров и вовсе приводят к техногенным катастрофам: крупным авариям с большим количеством пострадавших или даже погибших. В этой и следующей публикации мы с вами разберём больше дюжины подобных случаев, чтобы понять, какие ошибки, решения и системные проблемы к этому привели. Чтобы выделить, что не должен делать и чего должен остерегаться бизнес, чтобы не допускать воплощения критических рисков? Ведь для любого бизнеса могут сложиться обстоятельства, которые фактически мгновенно прекратят его работу, и в руках руководства — возможности и инструменты, которые бы предотвратили такой печальный исход.
Конечно, крушение ИТ‑компании, логистического оператора или юридической консалтинговой фирмы не будут так же эффектны или так же опасны, но вряд ли от этого собственники и адекватные руководители захотят наступления своих критических рисков и краха всего бизнеса.
Жадность и глупость - два всадника "Эффективного Менеджмента", из-за которых произошли многие техногенные катастрофы, аварии и банкротства.
В этой публикации вы сможете узнать, как компании могут противодействовать критическим рискам как из-за собственных ошибок, так и из-за внешних угроз:
Как можно внедрить систему управления критическими рисками в несколько простых этапов. И какие при этом могут возникать когнитивные ошибки.
Публикация будет интересна и тем, кто хочет избежать катастроф в управлении компанией, и тем, кто хочет лучше понимать про ментальные ошибки и их влияние на бизнес на конкретном примере.
Доброго времени суток, дорогие читатели! Сегодня я затрону одну интересную тему — графические дисплейные сервера и протоколы в Linux. В этой статье я расскажу вам о архитектуре X11 и Wayland, историю их создания и наконец-то сделаем вывод: Иксы на мороз, или вейланд на помойку?
Еще в далеком 2016 году вышла Fedora 25 с окружением GNOME 3.22 на базе дисплейного сервера Wayland. А в RHEL 10 выкинут X11 на мороз. Релиз RHEL 10 намечен на 2025 год, CentOS Stream 10 — на 2024 год. Для обеспечения работы приложений, требующих X11, будет использоваться XWayland. Таким образом, в 2029 году (к моменту окончания первого этапа поддержки RHEL 9) стоит ожидать появление первого аппаратного обеспечения, не поддерживающего X11.
И как я думаю — будущее за Wayland. Но пока X11 является стандартом. Давайте разберем это!
Иллюстрации к статье подготовлены нейросетью freepik.com.
Многие люди на планете играют в видеоигры. Игры помогают улучшить когнитивные способности, провести приятно свободное время. Данная статья посвящена тому, как запустить Windows-игры под Linux в Wayland.
Эта статья могла бы быть: ставим Wine(Proton) и XWayland, запускаем игры, успех, но нет. В данном материале мы будем сами собирать Wine, решать проблемы, а так же наш Wine будет работать напрямую с Wayland композитором без прослойки в виде XWayland. Плюсы такого метода — лучшая производительность и меньше инпут лаг. Благодаря Wine 9.0 это стало возможно, но не все так просто, как может показаться читателю с первого взгляда. Для примера мы запустим игры: Overwatch 2 через Battle.net клиент и Aimbeast, KovaaK's, Apex Legends через Steam.
Если вас заинтересовала статья, то добро пожаловать под cut.
В настоящее время искусственный интеллект (ИИ) стремительно развивается. Мы являемся свидетелями интеллектуальной мощи таких нейросетей, как GPT-4 Turbo от OpenAI и Gemini Ultra от Google. В Интернете появляется огромное количество научных и популярных публикаций. Зачем же нужна еще одна статья про ИИ? Играя с ребенком в ChatGPT, я неожиданно осознал, что не понимаю значения аббревиатуры GPT. И, казалось бы, простая задача для айтишника, неожиданно превратилась в нетривиальное исследование архитектур современных нейросетей, которым я и хочу поделиться. Сгенерированная ИИ картинка, будет еще долго напоминать мою задумчивость при взгляде на многообразие и сложность современных нейросетей.
moz_places.sqlite содержатся все посещённые URL-адреса и адреса закладок (то есть moz_bookmarks.sqlite базы данных SQLite). У меня получилось около 2000 закладок. Это меньше, чем я предполагал, так как многие оказались нерабочими из-за битых ссылок. 
Привет, Хабр. Меня зовут Дима и я разработчик, тимлид и по совместительству наставник на курсе «Мидл Python-разработчик» в Практикуме. Сегодня, с вашего позволения, я вставлю свои пять копеек и поделюсь опытом по такой заезженной теме, как технические собеседования. Много слов сказано, статей написано и копий сломано на сей благодатной почве, потому постараюсь быть максимально кратким.
Не буду писать много о себе, скажу лишь одно: я провёл много часов по обеим сторонам стола. Уповаю на то, что смогу кому-то быть полезным в этом нелёгком и, кажется, поднадоевшем деле. Я практически не буду затрагивать другие этапы, сконцентрируюсь только на техническом собеседовании и процессе подготовки к нему.
TL;DR: Внимательно читайте вакансию и анализируйте результат собеседования. Говоря о себе, фокусируйтесь на релевантном для слушателя. Будьте готовы ответить за обозначенный опыт. Задачи совсем не про код. Задавайте вопросы, интересуйтесь. И помните — «г-г-главное н-н-не бояться». Успехов!
Это ответ на статью, что алгоритмические собеседования не нужны. Простите за кликбейтный заголовок, но он такой и в статье, на которую я отвечаю.
Сразу скажу, что моя статья относится лишь к условному ФААНГу. Многие аргументы из этой статьи теряют значимость в других случаях: если у вас маленькая фирма, мало кандидатов или у вас всего 10 пользователей.
Я утверждаю, что алгоритмические интервью - лучший вариант для ФААНГа из всех пока придуманных.
Поезд, сделанный польской компанией, внезапно сломался во время техобслуживания. Специалисты были беспомощны — поезд был в порядке, только никак не хотел ехать. Доведённые до отчаяния, они вызвали на помощь команду Dragon Sector, члены которой нашли такие чудеса, о которых машинисты даже и не мечтали.
В этой истории мы отправимся в необычное путешествие. Путешествие, полное неожиданных открытий и событий, путешествие под давлением времени и больших денег, а также необычных технологий. Путешествие, в котором поезд играет самую важную роль — хотя, к сожалению, он не едет, а должен был бы. Пристегнитесь — или, по крайней мере, сядьте поудобнее, потому что дальше будут крутые повороты.
Scripts/ на Github есть файлы .Rmd, генерирующие показанные ниже графики. Для их работы требуются R, RStudio и пакет rmarkdown.
Привет! На связи Катя из мобильной разработки. Я выпускаю вторую часть статьи про собеседования в Альфе. С первой частью можно ознакомиться здесь.
Процесс отбора сотрудников проходит годы становления, как было и у нас. Требования далеко не жёсткие — они меняются, как и сфера, в которой мы работаем.
О том, как они менялись у нас последние 5 лет, я расскажу в статье. По ходу повествования буду указывать на наши ошибки и способы их пофиксить. Возможно, вам это пригодится в выстраивании ваших процессов.
Хочу вас огорчить, программисты не делают игры - их делают дизайнеры и арт. Можно уволить программиста и на его место придет другой и через условные месяц-два-полгода начнет закрывать таски не хуже. Если увольняется дизайнер, его монстр, пушка или контент повисает без хозяина и без "видения". Если её не перехватил сосед (а у соседа свой монстр), то в большинстве случаев его работа просто уходит в стол и монстра пишут заново на тех же ассетах и принципах, но заново.
Если увольняется арт-директор, который несет "видение" проекта, то проекту становится очень плохо, в большинстве случаев визуально он изменится до неузнаваемости, хотя ассеты могут быть те же самые. Программисты делают всё, кроме самой игры: рендер, звук, физику, сеть, AI, инверсную кинематику, поиск пути и т.д. Можем подискутировать в комментариях.
Привет, Хабр! Меня зовут Илья Казаков, я C++ разработчик в команде систем хранения данных компании YADRO, одна из моих задач — реализация эффективных IO-bound программ под Linux.
На одном из проектов мы с командой использовали Asio — библиотеку C++ для сетевого и низкоуровневого программирования ввода-вывода. Она предлагает свою асинхронную модель. Технология отлично справилась с нашей задачей, и я хочу поделиться с вами опытом ее использования. Под катом расскажу, какие решения я рассматривал для асинхронного ввода-вывода и почему остановился на Asio.
