Продолжаем делиться выдержками из руководства по выживанию для начинающих техлидов от Дж. Х. Рейнвотера. В первой серии мы рассказывали, с какими породами разработчиков руководителю обычно приходится работать; теперь попытаемся понять, что делать со всем этим зоопарком. Организационную деятельность в технической команде можно условно поделить на две части – более-менее родные вещи (вроде обзоров кода и управления архитектурой) и все то, к чему жизнь программиста не готовила – то есть управление людьми и процессами. Разберемся сначала с незнакомым.

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

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

Эта неделя была короткой, в понедельник и вторник я продолжал работать над системой 2D-освещения. Остальное время я потратил на реализацию деревьев квадрантов (quadtree).

В этой статье я поделюсь своей реализацией и мыслями, возникшими в процессе её проектирования.

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

Quadtree — это структура данных разбиения пространства. Её основное преимущество по сравнению с другими структурами данных заключается в адаптивности. Оно обеспечивает хорошую производительность при вставке, удалении и поиске. То есть мы можем использовать это дерево в динамическом контексте, где данные часто меняются. Более того, эту структуру довольно легко понять и реализовать.

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

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

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

В данной заметке я хочу рассказать, как достаточно просто организовать заголовочную библиотеку на языке C++ в системе CMake, чтобы получить следующую функциональность:

1. Сборку;
2. Автозапуск тестов;
3. Замер покрытия кода;
4. Установку;
5. Автодокументирование;
6. Генерацию онлайн-песочницы;
7. Статический анализ.

Кто и так разбирается в плюсах и си-мейке может просто скачать шаблон проекта и начать им пользоваться.

Перевели новую порцию слайдов. Права доступа в Unix, файловые дескрипторы, потоки, магия proc. И на закуску пара советов о том, как общаться, когда ты не согласен. А вдруг пригодятся =)

Тимлид – это снежинка. При детальном рассмотрении в каждой компании тимлид принимает разную форму. Где-то от него ждут только передвижения задач по доске, где-то – наймов и увольнений, а где-то просят одновременно проектировать архитектуру, ставить бизнес-цели и думать о болях пользователей продукта. На самом деле все обстоит еще сложнее. Различия встречаются не только между разными компаниями, но и даже в рамках команд, находящихся в одном офисе.

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

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

Привет, Хабр! Сегодня мы построим систему, которая будет при помощи Spark Streaming обрабатывать потоки сообщений Apache Kafka и записывать результат обработки в облачную базу данных AWS RDS.

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

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


(Источник картинки)

Привет, Хабр! Представляю вашему вниманию перевод статьи "Long Names Are Long" автора Bob Nystrom.

Одна из умных вещей, которые делает Google — это строгие code review. Каждое изменение, прежде чем вам разрешат его внести в основную ветку, рассматривается как минимум в двух направлениях. Во-первых, кто-то в команде делает обычную проверку, чтобы убедиться, что код выполняет то, что должен.

Но затем происходит вторая ступень, когда проверяется читабельность кода. Это гарантирует, что другие разработчики смогут поддерживать этот код в будущем. Легко ли понять и поддерживать данный код? Соответствует ли этот код стилю и идиомам языка? Хорошо ли задокументирован код?

Использование языка Dart в Google постепенно набирает обороты, и я много занимался подобными code review. Для разработчика языка это очень увлекательный процесс. Я получаю из первых рук представление о том, как люди используют Dart, что действительно полезно для его развития. У меня есть более четкое представление о том, какие ошибки являются общими, и какие функции интенсивно используются. Я чувствую себя как этнограф, ведущий дневник о жизни туземцев.

Но, в любом случае, дело не в этом. Черт бы его побрал, дело даже не в Darts. То, о чем я хожу поговорить, — это то, что я вижу во многих кодах, и что сводит меня с ума: излишне длинные имена.

В предыдущей статье про Qt roadmap я обещал рассказать про Qt 3D Studio и текущую ситуацию с лицензиями. Qt 3D Studio уже было выпущено два (пока писал статью, вышел третий) внутренних релиза, но статьи про неё пока не будет, так что сегодня расскажу про лицензии.

Система лицензирования Qt и раньше не особо отличалась простотой, но сейчас она особенно усложнилась, так как добавились (и добавляются) новые продукты и вместе с ними дополнительные условия соответствующих лицензий. Официальный сайт не сильно помогает разобраться, хотя и содержит текст условий и соглашений.

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

В последнее время все чаще можно встретить обсуждение интересной, но не очень популярной парадигмы — так называемой Data Oriented Design (DOD). Если вы устраиваетесь на работу, связанную с высокопроизводительными вычислениями, будьте готовы к соответствующим вопросам. Но я был очень очень удивлен, узнав, что некоторые мои коллеги не слышали об этом подходе и после недолго обсуждения отнеслись к нему скептически. В этой статье я постараюсь сравнить традиционный OOP подход с DOD.

В этой статье я хотел бы рассказать о том, как выглядит процесс разработки PostgreSQL глазами одного из контрибьютеров в этот самый PostgreSQL. Заниматься разработкой этой СУБД я начал в декабре 2015 года, когда устроился работать в компанию Postgres Professional. То есть, не так уж давно. А значит, еще свежи воспоминания о моментах, которые поначалу казались мне не вполне очевидными. Хотелось бы их законспектировать, чтобы новым людям, приходящим в нашу команду, а также всем тем, кто желает попробовать себя в роли разработчика открытой реляционной СУБД, было легче. Я расскажу о том, как выглядит процесс разработки PostgreSQL, какие инструменты я использую в своей повседневной работе, как следует оформлять патчи, и так далее. Заинтересовавшихся прошу проследовать под кат.