Технотекст

Долгое время я жил в районе, где общественный транспорт был скорее проблемой, чем благом (привет, Кудрово!). Приходилось в любую погоду ходить пешком до метро три километра, в мороз, слякоть и зной. Спустя некоторое время я переехал и появилась возможность доезжать от офиса до дома на прямом автобусе. Это звучит очень клево, но единственный маршрут ходит с большим интервалом и как попало. Приходилось или подолгу стоять на остановке, или нервно поглядывать на Яндекс.Карты и отслеживать перемещения ближайшего автобуса последние полчаса перед выходом, что сводило на нет остатки продуктивности и неслабо раздражало.

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

Это модное слово всё чаще используется в разговорной речи: обывателей плотнее окутывают угрозами бунта искусственного интеллекта и войны с роботами — с одной стороны, и рекламой нейросетевых продуктов — с другой. Отдельный котёл в аду — для тех, кто впаривает «курсы дата‑саентистов». А когда бедный юзернейм в поисках истины обращается к Гуглу своему любимому поисковику — то вместо простого ответа на простой вопрос, получает ещё больше вопросов — таких как тензорфлоу, сигмоида и, не дай Бог, линейная алгебра.

При работе с данными часто приходится сталкиваться с ситуацией, когда имеется некоторая функциональная зависимость y_i = f(x_i), которая получена в результате эксперимента или сбора статистики. То есть исходные данные представлены набором точек (x₁, y₁), (x₂, y₂) … (x_n, y_n), где n – количество экспериментальных значений. Если аналитическое выражение функции f(x) неизвестно или весьма сложно, то возникает чисто практическая задача: найти такую функцию Y = F(x), значения которой при x=x_i будут близки к экспериментальным данным. Приближение функции f(x_i) к более простой F(x) называется аппроксимацией. Аппроксимация позволяет исследовать числовые характеристики и качественные свойства объекта, сводя задачу к изучению более простых или более удобных объектов. Как правило, выбор модели аппроксимации определяется по минимальному значению погрешности на всем интервале исходных данных. Для расчетов необходимо использовать несколько видов аппроксимаций, чтобы определить более точное описание зависимости экспериментальных данных y = f(x_i).

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

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

Привет, Хабр! Меня зовут Евгений Кузьмин, я Java‑разработчик в CDEK. Надеюсь, все знают, что это за компания и чем занимается. Давайте представим, что вам нужно отправить посылку с гостинцами родственнику в Москву из Новосибирска. Вы приходите в ближайший пункт приёма посылок и оформляете услугу доставки. Что же происходит дальше? Казалось бы, всё очевидно: посылка сразу летит или едет из Новосибирска в Москву. Но всё не так просто...

Думаю, все согласятся, что не рационально гнать отдельную фуру с одной коробочкой для каждого заказа. Наша задача выстроить логистику таким образом, чтобы по пути загрузить и выгрузить как можно больше посылок и поехать дальше. В этой статье я поделюсь с своим опытом оптимизации задачи по редактированию и поддержке в актуальном состоянии огромного количества данных типа «куда направить товар». Классическая задача программирования на практике логистики. При этом мы не будем выходить за рамки стандартного стека Java Springboot и Postgres. Статья будет полезна разработчикам (от джуна до сеньора), которым интересно погрузиться в трудовые будни разработчика в сфере транспортной логистики.

Hola, Хабр! Я — технический писатель и за свою длинную карьеру в ИТ, нигде и никогда не сталкивался с ситуацией переизбытка в командах технических писателей. Наоборот, почти повсеместно в компаниях есть множество продуктов и проектов, в которых документация неполная, неточная, устаревшая и покрытая паутиной, а самих «техписов» хронически не хватает. Опытные спецы, умеющие читать код, документировать алгоритмы, описывать БД и API — это вообще люди уровня «ошибка выжившего». И, возможно, я нашел ответ на этот вопрос.

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

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

Мы спросили инженеров «Фланта» и экспертов из индустрии, как, по их мнению, будут развиваться Kubernetes, DevOps, Ops и Cloud Native-экосистема в ближайшее десятилетие. Наша задача была спрогнозировать будущее на основе тенденций в настоящем, а не просто «заглянуть в хрустальный шар» и пофантазировать. В результате родилась эта статья. Присоединяйтесь к нам в комментариях — давайте вместе подумаем, как будут выглядеть важные в нашей работе инструменты через 5–10 лет.

Ранее мы делали обзор инструментов для оценки безопасности кластера Kubernetes. Но что, если нам нужно обучить инженеров основам безопасности Kubernetes на реальных примерах и автоматизировать этот процесс? Недавно компания ControlPlane, специализирующаяся на Cloud Native-решениях, помогла решить этот вопрос. Она выложила в открытый доступ Simulator — инструмент для обучения инженеров поиску уязвимостей в Kubernetes. Мы во «Фланте» решили протестировать этот симулятор и понять, насколько он перспективен и полезен.

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

Что вам может дать продуктовый подход к pet-проекту? Если смотреть на pet-проект не как на лабораторную работу, а как на будущий продукт, начинаешь лучше понимать весь цикл разработки. При таком подходе ты сперва выступаешь в роли заказчика: определяешь, какую задачу пользователя решаешь, как это сделать наилучшим образом, а потом подбираешь технологии, которыми легче всего реализовать функционал или которые хочется попробовать. В тексте я расскажу о развитии моего pet-проекта по созданию музыкального стримингового веб-приложения и чему удалось научиться, используя данный подход.

Всем привет! Меня зовут Владислав Шиханов, я ведущий программист в CDEK. В этой статье я хочу рассказать о том, как мы пришли к проектированию и review плана разработки до начала реализации задачи, что это дало и как повлияло на скорость и качество разработки. Также поделюсь практическим руководством: как проектировать и проверять технический дизайн, чтобы это было быстро и удобно. Статья будет полезна разработчикам любой квалификации, но особенно тимлидам и менеджерам для внедрения практики в командах.

Наша команда Mobile Doc&Loc «Лаборатории Касперского» занимается подготовкой документации и локализации B2C-продуктов компании для мобильных устройств. Основная сложность (и одновременно фишка) нашей работы заключается в том, что необходимо регулярно подготавливать переводы на 34 языка в крайне сжатые сроки.

Меня зовут Юлиана Соломатина, я — Doc&Loc-инженер, и в этой статье я расскажу про инструменты-автоматизации, которые помогают нам справляться с наплывом задач и укладываться в дедлайны, не жертвуя при этом качеством. Кстати, многие из этих инструментов мы разработали сами.

Привет, Хабр! Я Нина Горохова, руководитель гиперлокальной логистики в СДЭК.

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

Технические писатели создают текстовые документы, но что если для процесса одного текста мало? Тогда приходится учиться монтировать и делать видеоинструкции.

В этой статье я рассказала, как и зачем в Компании «Актив» мы делаем видеоинструкции на примере одного важного кейса: здесь про цели, сценарий, запись звука и программы для монтажа.

Должно быть интересно!

Привет, Хабр! Я Ульяна, старший аналитик в направлении продуктового и системного анализа в отделе Tinkoff Mobile Core. Наш отдел разрабатывает общие технические решения — библиотеки, которые используются в мобильных приложениях экосистемы Тинькофф.

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

Документацию мы ведем в Confluence — и обычно, когда я рассказываю про Confluence, у многих он вызывает, мягко говоря, неприятные ассоциации. Миллион разделов, неудобная навигация, портянки бесконечного текста и многое другое, что отбивает желание даже открывать любую wiki. Но я спешу вас обрадовать — все может быть совсем иначе!

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

Данные - это важный компонент системы. Приложение может хранить их где угодно, но в результате все сводится к файлам. Файлы - это хорошая абстракция, но она протекает: если не знать того, как работают ОС или гарантии файловой системы, то легко выстрелить себе в ногу.

Меня увлекла тема отказоустойчивости, а конкретно - отказоустойчивой работы с файлами. В этой статье я попытался соединить все полученные знания:

Кто участвует в процессе записи

Ошибки, которые могут произойти

Что от нас зависит, а что нет

И самое главное - как это этого защититься

В текущих реалиях все IT-продукты разрабатываются с использованием какого-либо ПО, способного управлять репозиториями программного кода для Git. В нашем случае, хотелось бы рассказать про один из самых популярных продуктов — Gitlab. «Gitlab — наше всё» должно быть слоганом каждой компании, которая его использует, иначе могут произойти события, которые приведут к печальным последствиям. На Habr можно найти множество различной информации, связанной с кейсами, туториалами или просто интересными историями. Но сколько бы ни было написано, найти место где было бы собрано всё и сразу — не получилось. Придется исправлять.