Существует заблуждение, что дизайн — это вопрос вкуса, и у него нет объективных критериев оценки. Но не стоит забывать об условиях использования приложения. Например, таких факторах, как шум, низкое качество, старое тормозное оборудование или программное обеспечение, ограничение доступа в интернет из-за  безопасности. Если копнуть поглубже можно найти много критериев. Поэтому давайте наконец развенчаем этот миф!

Привет, Хабр! Меня зовут Кирилл Голубовский. И сегодня хочу поделиться информацией, которая пригодится всем, кто хочет понять, насколько удобным является их решение. Вы разберётесь, что нужно учесть при логическом проектировании сложных систем с запутанными сценариями. 

Сейчас я возглавляю дизайн Bimeister. Мы с командой занимаемся разработкой BIM и ERP-систем, способных эффективно цифровизировать предприятия.

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

Меня зовут Андрей Жуков, я директор по ML, AI и другим высокотехнологическим базвордам в ИТ-дочке авиакомпании С7, С7 ТехЛаб. Это подразделение создано в 2017 году под впечатлением от книги Skunk Works и было призвано привнести новые технологии в консервативный мир авиации. Так в авиакомпании и появились разные гики вроде меня. Я очень люблю играть в настолки, даже  коллекционирую их. Давно смотрел на Warhammer 40к как на большую и крайне необычную вселенную, читал лор, а недавно мне наконец подарили армию орков, которую в последние полгода я мучительно собираю и крашу. Именно вселенная вахи и будет развлекательным обрамлением для дальнейшего рассказа.

Привет, Хабр! Меня зовут Арина Шахтарина, я — инженер в Сбере, а ещё занимаюсь ткачеством. Сегодня поговорим о том, откуда появились первые компьютеры и разберём одну из версий — путь от ткачества к ЭВМ.

Кажется, что компьютеры начали разрабатывать совсем недавно, лет 50-70 назад. Но на самом деле предпосылки к этому были очень давно.

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

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

И голос «зачем этим заниматься, если это недооценивают» сегодня слышен довольно громко. Но программному комитету есть, что ответить.

Как выглядят паттерны DDD (Domain Driven Design) в большом проекте? А самое главное, стоит ли их вообще использовать? Рассмотрим, какими инструментами можно реализовать DDD на Go и оценим, насколько это больно.

Меня зовут Илья Сергунин, я backend-сочинитель в Авито: занимаюсь тем, что передаю смартфоны в хорошие руки. В этой статье попытаюсь объяснить, как можно натянуть DDD на Go без синтаксического сахара и магии Java-подобных языков, и без больших крутых ORM c Data mapper, которые также отсутствуют в Go.

Меня зовут Андрей Колнооченко. Я отвечаю за ядро файловой системы Яндекс Диска. Когда мы запускали сервис, то сразу ориентировались на рост и приняли решение шардировать базу метаданных о файлах. Но за 11 лет Яндекс Диск настолько вырос, что нам пришлось трижды менять подход к шардированию. В статье расскажу, с какими проблемами мы сталкивались по мере роста сервиса и как от MongoDB пришли в итоге к PostgreSQL.

Эта статья будет полезна, если вы планируете распределить нагрузку на вашу БД или вам просто интересен опыт развития БД для обработки большого числа запросов.

Привет, Хабр! Я Виктор, техлид продукта CI/CD в Samokat.tech. А это, :(){ :|:& };: fork-бомба, которая создаёт свои дочерние процессы бесконечно. Запуск такой штуки в контейнере без ограничений роняет всю ноду. Не используйте в проде! Если запустить в WSL, то винду тоже укладывает. Как же избежать запуска такой штуки на проде? Помогут квоты.

Давайте разберемся как работают квоты в Kubernetes. Там есть немало граблей. В этой статье поделюсь своим опытом по работе с квотами – расскажу, чем квоты хороши, что у них под капотом, в каких задачах используются и почему нужны даже в среде single-tenant.

Привет, Хабр! Мы системные инженеры X5 Tech — Алексей Кузнецов и Борис Мурашин. У нас за плечами больше 15 лет опыта, в том числе поддержка сервисов Rapida, CyberPlat, TeleTrade, сопровождение стека BigData и внедрение кластеров Hadoop. В этой статье мы расскажем, как выбирали систему управления конфигурациями, какими критериями руководствовались, что в итоге выбрали, с какими проблемами столкнулись и как их решали.

Рассматривать вопрос, зачем вообще нужна система управления конфигурацией, не будем. Потому что считаем, что если у вас больше одного сервера, она уже необходима. Перейдём сразу к тому, почему мы выбрали именно Ansible.

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

Мне удалось снизить влияние этих «узких мест» и «критичных звеньев» за счёт налаживания горизонтальных связей, построения ролевой модели большой команды и ещё нескольких приёмов.

Меня зовут Татьяна Сеземина, я директор по управлению проектами Холдинга Т1.

Я вырастила команду с 40 до более чем 150 человек и не потеряла управляемости.

Сейчас расскажу, как мне удалось этого добиться.

Как хранить сложные сущности в БД? Что нужно сделать, чтобы не перезаписывать весь рекламный баннер для обновления одного лишь заголовка? Рассмотрим как минимум 5 независимых и взаимно совместимых идей для многократного снижения нагрузки на чтение и запись подобных объектов.

Меня зовут Юрий Печатнов, я уже 6 лет работаю в Яндексе и занимаюсь сервисами потоковой обработки. Это большие распределенные системы, читающие сообщения из большой распределенной очереди и создающие полезный выход. Полезным выходом могут быть сообщения в другой распределенной очереди и/или обновление состояний в БД. Поговорим о том, как их эффективно обновлять.

Миграция с «железа» в облако в большинстве случаев уже не кажется чем-то сложным или удивительным — тенденция на развертывание решений в облаке общая и устоявшаяся. Но если с переносом в облачную среду небольших ИТ-компонентов все просто, то в случае с глобальными системами на сотни петабайт данных все несколько иначе — такие кейсы встречаются редко. 

Меня зовут Михаил Марюфич. Я руководитель Data Platform в ОК, отвечаю за инфраструктуру для Big Data и машинного обучения. В этой статье я расскажу о нашем опыте переноса Hadoop с Bare Metal в облако: с чего стартовали, какие варианты рассматривали, как выстроили миграцию и с чем сталкивались в процессе.

Меня зовут Виктор Попов, я — технический владелец продукта CI/CD в Samokat.tech. Мы с командой разрабатываем там комплекс CI/CD  инструментов. Это единый продукт, который должен удовлетворить потребности продуктовых команд. Правда, не так просто разобраться, а удовлетворяет ли. Чтобы это понять, нужна коммуникация. А коммуникацию я очень люблю! А ещё всё, что связано с пользователями и построением процессов. Кажется, в этой роли я даже полезнее, чем в инженерной.

Чем раньше команда задумается о проблеме безопасности, тем лучше. В этой статье обсудим, какие проблемы ИБ есть в стандартном контейнерном приложении, поговорим о безопасности использования Docker, Kubernetes и Terraform и разберём, как можно встроить проверки в стандартный пайплайн деплоя.

Материал написан и дополнен по мотивам выступления Любови Гринкевич и Алексея Миртова из Yandex Cloud на DevOpsConf. Он будет интересен DevOps-инженерам, специалистам по безопасности, владельцам продуктов и всем, кто хочет:

Привет, Хабр! Я Федор Щудло, team lead и fullstack-разработчик. Всего я в разработке 15 лет, из них 11 в роли team lead.

Три года назад я сменил работу и занялся проектом, состояние которого можно описать кратко: ему 25 лет.

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

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

Как результат, разработка шла с большими накладными расходами (все делали долго), и с высокими рисками (выкатили и разломали прод). А команда при этом работала на износ.

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

Последние двадцать лет привели к серьезной трансформации технологического ландшафта и работы архитекторов, которые за ним должны следить. Архитекторы работают с технологиями и людьми. Компьютерные технологии за последние десятилетия значительно изменились и продолжают это делать. Люди меняются не так быстро. Однако, для работы с людьми выделяются новые роли: продакт-менеджеры, прожект-менеджеры, тимлиды. Роль и влияние архитекторов не так велико, как раньше, они становятся прерогативой больших компаний.

В статье попробуем разобраться действительно ли роль архитектора незаменима, для чего она нужна, как возникла и работает в реальном мире?

Привет, меня зовут Олег Свидченко, я — Chief Data Scientist. Работаю в ассоциации «Цифровые технологии в промышленности». Если вы недавно перешли из крупной технологической компании в нефтегазовую или только планируете этот переход, либо слышали про машинное обучение только в теории, но у вас нет практики его применения в конкретных, особенно промышленных проектах, эта статья для вас.

Когда я искал новое место работы, сперва рассматривал крупные IT-компании, но решил, что мне неинтересно допиливать 0,1% к точности поиска. А в промышленности — непаханное поле, можно внедрять интересные технологии крупными мазками и решать задачи, которые еще не исследовались. Хотя меня пугали страшилками, что будет строгий дресс-код, жесткий график, неудобный офис и скучные проекты...

За последние пару десятилетий с ростом объёма данных на рынке СУБД сложился интересный ландшафт. Появились новые СУБД, при этом старые продолжали развиваться — и сориентироваться среди них становилось всё сложнее. 

В этой статье предлагаем рассмотреть эволюцию разных СУБД и сравнить их между собой. Поможет нам в этом Олег Бондарь, директор по продукту в Yandex Cloud, который отвечает за развитие YDB — это транзакционная реляционная база данных с открытым исходным кодом. Статья написана по материалам его доклада на Saint Highload++.

Привет, Хабр! Я — Алексей Диянов, технический директор Nedra Digital. Мы — IT в нефтегазовой отрасли. Компании чуть больше трёх лет. Мы быстро выросли как в численности персонала, так и в количестве проектов, но не избежали классических проблем в виде трудностей внутренней коммуникации, регулярного тушения пожаров и принятия управленческих решений на основе субъективного мнения.

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

Привет, Хабр! Меня зовут Дмитрий Архипов, я руководитель разработки в Сибур Диджитал. В IT 15 лет, занимаюсь цифровизацией почти 6 лет. Расскажу что это такое, какие задачи возникают в ходе цифровизации, какие бывают стратегии и способы реализации этих стратегий, а также какие проблемы из этого вытекают.

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