Статья про то, как можно собрать docx-файл из git(adoc)-дерева.

По мнению автора, статья может быть интересна тем, кто хочет уйти от стандартных методов хранения документации. Ведь техническая документация всегда лежит на стыке кода, практик devops_а и нас, простых читателей.

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

Я менеджер менеджеров, отвечаю за разные команды с разными фокусами. У каждой команды свои проекты. В каждом проекте есть по несколько Миро-досок, гугл-доков, доков в конфлюенсе, эпик в джире и еще горка ВАЖНЫХ ссылок!

Все это богатство надо как-то организовать и перестать, наконец, дергать в слаке коллег с вопросом: "А напомни, плз, ссылку на...".

На эту статью меня вдохновил мем о «лёгкой» работе айтишников, которые, мол, просто включают компьютер и получают за это по 300к в секунду. В комментариях к нему кто-то написал: «Ребят, недостаточно просто работать, надо ещё и любить свою работу». Вот тут я и задумалась: а можно ли обойтись без любви? 

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

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

Если вы НЕ обнаружите у себя эти 5 признаков, приходите на курс «Аналитик данных» в Практикум, я там наставник. Если же всё это про вас — подумайте дважды.

Привет! Меня зовут Дима, я архитектор в Купере. Сегодня расскажу о шаблоне проектирования Strangler, который мы использовали для поэтапного выноса бизнес-логики из монолитной системы в отдельный сервис. 

Сначала обратимся к первоисточнику, а затем перейдем к практическим моментам, с которыми столкнулись в процессе работы. Поехали!

Сегодня предлагаем обсудить сжатие данных в Oracle.
 
Ситуация: один наш крупный клиент в сфере телекома стремится нарастить абонентскую базу, поощряет потребление услуг и рост трафика. Это позволяет развиваться компании в целом и каждой её системе в отдельности, включая нашу систему взаиморасчётов с партнёрами — Partner Relationships Managment.

Проблема: регулярный прирост информации в БД на 0.6 TБ в месяц превращается в 7.2 TБ в год. При этом востребованной для изменений является информация только за последние два-три месяца. Остальные данные накапливаются и хранятся для отчётности. При таком подходе база разрастается очень быстро, а каждый SSD системы хранения данных становится на вес золота. К тому же необходимо поддерживать согласованность резервной и тестовой БД. 

Есть два выхода: закидывать в базы, как «в топку», бесконечное количество дисков, либо оптимизировать хранение информации. Мы выбрали второе.

В этой статье главный инженер-программист по бизнес-системам Кирилл Солдатов расскажет, что конкретно сделали в Nexign. Информация будет полезна всем, кто как и мы сталкивается с необходимостью управления большими массивами в БД Oracle.

Однажды я устроился в проект на Erlang. Вообще мой профиль тогда был в основном Java и немного BigData. Но по результатам собеседования договорились что я попробую написать небольшое тестовое задание — и сам пойму нравится ли мне язык — и ребята оценят, гожусь ли я им. Ну и за выходные справился — язык непривычный но не очень сложный — и интересный, с необычными «фишками». Команде же, куда меня взяли, оказался удобен мой опыт в бигдате и амазоне.

Сейчас я расскажу на паре примеров про язык — он действительно по‑своему классный (если вам нравится функциональное программирование — это для вас) — и про то как, однако, он оказался неудачным выбором для проекта (данного‑конкретного).

Статья для широкого круга читателей, не знакомых с языком — знатоки же Эрланга в частности и ФП вообще возможно найдут неточности в моём повествовании — дело было лет 6 назад — так что можете смело поправлять и даже ругать при необходимости:)

Сравнение хранилищ данных AoS и SoA

* Не привлекая внимания санитаров

Меня зовут Илья, я занимаюсь фронтенд-разработкой вот уже 10 лет. Представьте, что вам нужно сделать стили для печати документов, а бегать к принтеру с линейкой, чтобы убедиться в корректности фактических размеров отдельных элементов, очень не хочется. Было бы куда проще иметь возможность приложить ту же линейку к экрану. Но размеры элементов на экране почти всегда не соответствуют их физическим размерам при печати. Казалось бы, зачем это вообще может быть кому-то нужно. Но это бывает важно. Например, в типографиях.

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

Что ж, вызов был брошен. И я поставил себе задачу (вы же тоже сами ставите себе задачи?) — нарисовать красивый красный квадратик размером 3 × 3 см. Тому, что у меня в итоге получилось, и посвящён мой необычный рассказ. 

Всем привет! Меня зовут Артем, я аналитик, занимаюсь автоматизацией бизнес процессов и учета, преимущественно в крупных производственных холдингах.

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

Привет! Я Женя, CPO в корпоративном мессенджере Compass. Было бы круто управлять временем, как в старенькой TimeShift, в которой я зависал в 2008 году, но нет. Зато можно поностальгировать, глядя на скриншоты.

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

Путь к нему оказался трудным и полным ошибок. До того, как я пришел к подходу, я попробовал несколько популярных методик контроля времени и внимания — ни одна не помогла, а иногда даже фрустрировали.

Поэтому мне пришлось подтянуть теорию и найти свое удобное решение.

Линус Торвальдс как-то написал в своей книге, что создавал Linux для развлечения, но в итоге это привело к революции. Git, его второе творение, также оказалось «случайной революцией» — и сегодня это стандартный инструмент для людей в ИТ. Однако процесс его создания был уже не таким «весёлым» — по крайней мере, для самого Линуса. 

Привет, Хабр! Меня зовут Мила, когда‑то я работала аналитиком в банках, а нынче делаю авторские туры в Африку. По работе мне постоянно приходится отправлять деньги за границу, оплачивать отели, трансферы, билеты онлайн и оффлайн.

Хочу поделиться опытом оформления одной конкретной карты банка Казахстана. Данный банк, опасаясь санкций, публично отрицает возможность открытия счетов для нерезидентов ОНЛАЙН. Поэтому помогающие конторы стараются не ссылаться на реальное название банка, а заменять его на псевдонимы: «зелёный банк», «свободный банк», «банк воландеморт». Так что тссс! мы все понимаем, что король голый, но вслух ни‑ни.

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

Итак, поехали.

Часто сталкиваюсь с тем, что люди смешивают понятия продуктового дизайна и UX/UI-дизайна. Это делают и работодатели, и работники, и даже авторы образовательных программ. В этой статье я хочу рассказать, в чём же заключается роль дизайнера продукта и чем она отличается от роли дизайнера интерфейса. И как это проявляется на практике.

У Теренса Тао, одного из величайших из ныне живущих математиков, есть свой взгляд на искусственный интеллект.

Перевод интервью из издания The Atlantic

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

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

Но давайте честно: Agile не идеален. На поздних стадиях разработки он может превращаться в настоящую головную боль. На этом этапе проект становится сложнее, требования начинают накладываться друг на друга, а команды, вместо того чтобы работать слаженно, часто начинают сталкиваться друг с другом. Сложно сосредоточиться на техническом долге, когда у тебя в голове только «первый спринт», «планирование» и «обсуждения».

Мы на Хабр Карьере помогаем IT-специалистам зарабатывать больше, а компаниям — быть в курсе трендов на рынке найма. 

Не так давно мы стали внедрять Индивидуальные Планы Развития (ИПР-ы) в Хабре и это оказалось непросто. Нам стало любопытно: каким специалистам они подходят, как влияют на мотивацию, повышение и как их собирать, чтобы сотрудникам было по-настоящему интересно по ним идти. 

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

К исследованию подключили команду платформы корпоративного обучения Грейд от Яндекс Практикума — оказалось, что ребята умеют круто наполнять ИПР-ы и собирают индивидуальные образовательные треки под каждого специалиста. 

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

Меня зовут Михаил Кузнецов, я product owner в команде, которая развивает внутреннюю платформу разработки Mindbox. В этой статье я расскажу, как мы отказались от легаси-фреймворка, который пронизывал все микросервисы. И убедились — такая трансформация осуществима даже в компании на 100+ разработчиков и 1000+ корпоративных клиентов.