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

Jetpack Compose — относительно молодая технология написания декларативного UI. Множество разработчиков даже не предполагают, что пишут неоптимальный код в такой критически важной части, и впоследствии это приводит к неожиданной низкой производительности и проседании метрик.

Наша команда Ozon Seller также столкнулась с этой проблемой. Мы решили собрать воедино все советы и наработки по написанию оптимизированного Compose-кода. Активное применение этих советов при оптимизации существующих экранов и написании новых существенно улучшило наши метрики: длительность лага по отношению к длительности скролла (hitch rate; чем меньше, тем лучше) экранов со списками упала в среднем с 15-19 % до 5-7 % (на 90-м перцентиле). Все эти советы и наработки мы описали в этой статье. Она будет полезна и начинающим, и опытным разработчикам, в ней подробно описаны оптимизации и механизмы Compose, а также рассказано про слабо задокументированных особенности и исправления ошибок, которые есть в других статьях. Давайте же начнём.

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

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

Три истории опубликованы здесь. Забегайте, читайте и делитесь мнением в комментариях (или просто читайте комментарии — там интересно). Пять новых историй — в этой статье.

Соблюдать принципы чистой архитектуры – значит обеспечить удобство тестирования, поддержки и модернизации приложения. Понимание архитектуры и state management – это база, необходимая начинающему специалисту для успешной командной работы. В этой статье мы расскажем, как с помощью Cubit реализовать чистую архитектуру на примере стартового приложения Flutter – счетчика нажатий на кнопку. 

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

Будет полезно тем, кто хочет быть в курсе рынка. Или иметь лишний повод обратиться к своему работодателю за повышением. Мы знаем, что подобные исследования проводит сам Хабр, но вряд ли дополнительная информация из других источников кому-то помешает.

Эта статья — с цифрами для разработчиков. Как до, так и после 21 сентября. Исследование по HR, менеджерам и дизайнерам выйдет позже, если этот пост вам понравится.

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

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

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

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

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

Будет нелишним, если вы прочитаете мою прошлую статью про основные принципы систем, которые помогают достигать поставленных целей.

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

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

Добро пожаловать под кат, обсудим.

Как вы думаете, какие характеристики сильнее влияют на скорость сборки вашего проекта: частота CPU или частота оперативной памяти? Количество ядер CPU или количество оперативной памяти? Влияет ли скорость постоянной памяти на скорость сборки? Однажды у меня в голове возникли такие вопросы, и я решил найти на них ответы. Лучший способ для этого — провести тесты. Поэтому представляю вам их результаты и попытаюсь их объяснить в меру своих знаний. Если хотите узнать, что больше всего влияет на скорость сборки, ну или, может быть, хотите обновить компьютер для сборки, но не знаете, во что лучше вложится, то добро пожаловать в статью.

Всем привет! Меня зовут Миша Вассер, я Head of Android в AGIMA. Мы занимаемся разработкой Digital-продуктов для больших и маленьких компаний, в том числе пилим мобильные приложения.

Не так давно — по сравнению со всей историей Android — Huawei выкатил собственную операционную систему и сказал: «Ребята, вот вам новая система, кайфуйте». Многие отнеслись к новой ОС скептически. Остальным пришлось адаптировать под нее свои Android-приложения.

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

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

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

Так появился сервис Хабр Эксперты — платформа для менти и менторов в IT, которая, мы надеемся, будет помогать учиться и учить всем, кто этого захочет. Рассказываем, что придумали в первой версии.