Так получилось, что я вот уже 12 месяцев нахожусь во временном и очень интересном путешествии. И в этом путешествии я изначально столкнулся с проблемой отсутствия информации по моим профессиональным темам. Её не хватает. Процесс её ручного получения за все эти месяцы я организовал, но затем мне пришло письмо от одного человека по имени Пётр (о чём чуть ниже). Я понимаю, что то, о чём пишет Пётр будет актуально для очень многих представителей ИТ-сферы, по разным причинам оказавшимся в СИЗО и колониях. А таких ребят немало — мы всегда подбадриваем друг друга и помогаем маленькими делами даже в автозаках. Причём я встретил немало очень интересных людей, с которыми я пересекался, скажем, по разные стороны своей работы.

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

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

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

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

Всвязи с этим, "Руководство компании Google по проведению ревью" выглядит очень ценным документом, перевод первой части которого и представлен далее. Переводы остальных частей выйдут позже отдельными постами. Стоит отметить, что это адаптированный перевод, не все переведено слово-в-слово, во имя более русских формулировок и предложений.

Терминология:

CL: "changelist" — список изменений кода, отправленный в систему контроля версий на ревью. Аналог Pull Request в GitHub или Merge Request в GitLab.

Всем привет!

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

В качестве примера возьмем недавно отгремевшие муниципальные выборы в Москве. Сами данные можно взять с сайта мосгоризбиркома, в можно просто забрать датасеты с https://gudkov.ru/. Там даже есть какая-никакая визуализация, но мы пойдем глубже. Итак, что же у нас в итоге должно получиться?