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

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

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



В основе статьи — доклад Алексея Кудрявцева с Joker 2017. Алексей уже лет 10 пишет Intellij IDEA в JetBrains. Под катом вы найдете видео и текстовую расшифровку доклада.

Перевод материала Мартина Фаулера. В статье обсуждается общий подход к архитектуре UI и приводятся подробные описания таких шаблонов проектирования, как MVC, MVP, Presentation Model, Forms and Controls, Humble View, Passive View. Статья неплохо прочищает мозг. Для того, чтобы не упустить ни единого нюанса, решил заняться переводом.

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

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

Последние четыре года я работал разработчиком программного обеспечения в Google, но 1 февраля уволился, потому что они не сделали мне подарок на Рождество.

Шучу, на самом деле всё немного сложнее.

Первые два года

Первые два года я любил Google.

Когда при ежегодном опросе сотрудников мне задавали вопрос, вижу ли я себя в Google через пять лет, я отвечал «разумеется, без вариантов».

Ну конечно я буду в Google через пять лет. Я окружён лучшими инженерами в мире, использую самые продвинутые инструменты разработки в мире и кушаю самую бесплатную в мире еду.


Мой обычный день в Google.
— Ещё тортика, господин Программист? Он бесплатен в любом количестве.
— Не сегодня, Пьер. Я опаздываю на массаж, он тоже бесплатный.

Привет! Меня зовут Илья. Два года назад я присоединился к работе над мобильным клиентом IMAP. Ранние версии приложения долго загружали список писем и тратили большое количество трафика для обновления ящика. Встал вопрос об оптимизации работы с протоколом и о возможностях этого протокола вообще. О протоколе я не знал ничего и погрузился в чтение документации. Оказывается, все это время клиент использовал протокол напролом и совсем не учитывал особенности реализации. Эти особенности помогли ускорить загрузку почты в 2 — 3 раза. О том что такое IMAP и какие есть фишки для его оптимизации дальше в моей статье.

Каждый раз, когда в языке программирования появляется новый Фреймворк, рано или поздно, появляются люди, которые изучают язык именно с него. Вероятно так было и в IOS разработке во времена появления Swift: поначалу он рассматривался как дополнение к Objective-C — но я этого уже не застал. Сейчас, если начинаешь с нуля, выбор языка уже не стоит. Swift вне конкуренции.

То же самое, но в меньшем масштабе, происходит и с фреймворками. Появление SwiftUI — не исключение. Вероятно, я — представитель первого поколения разработчиков, кто стартовал с изучения SwiftUI, проигнорировав UIKit. У этого есть своя цена — обучающих материалов и примеров работающего кода пока очень мало. Да, в сети уже есть некоторое количество статей, рассказывающих о той или иной особенности, том или ином инструменте. На том же www.hackingwithswift.com уже довольно много примеров кода с объяснениями. Однако, они слабо помогают тем, кто решил изучать SwiftUI с нуля, как я. Большинство материалов в сети — это ответы на конкретные, сформулированные вопросы. Опытный разработчик легко разберется, как все устроено, почему именно так, и зачем это нужно применять. Новичку же, сначала нужно понять, какой вопрос задать, и только тогда он сможет добраться до этих статей.



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

Надеюсь статья поможет вам сэкономить некоторое время, когда вы тоже захотите ощутить немного магии.

Артикли — это самые распространенные слова в английском языке. Эти невзрачные a, an и the занимают около 8,5% объема любого текста. Если немного утрировать, то из каждого часа работы с текстом вы пять минут тратите только на прочтение артиклей.

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

В общем, сегодня мы решили рассказать вам именно об артиклях. Откуда появились, как развивались исторически и как их использовать правильно сегодня. Поехали!

Привет %username%. Меня, независимо от темы доклада, на конференциях постоянно спрашивают один и тот же вопрос — «как безопасно хранить токены на устройстве пользователя?». Обычно я стараюсь ответить, но время не позволяет полностью раскрыть тему. Этой статьей я хочу полностью закрыть этот вопрос.

171 слово, которое должен понимать любой программист

Лицензия MIT – самая популярная лицензия для программ с открытым кодом. Здесь приводится одно из её прочтений, с построчным разбором.

Читаем лицензию

Если вы разрабатываете программы с открытым кодом, и не читали эту лицензию подробно – а она состоит всего из 171 слова – вам нужно этим заняться. Особенно, если вы не занимаетесь лицензиями на ежедневной основе. Отметьте всё, что вам непонятно. А я повторю все эти слова, по порядку и по кусочкам, вместе с контекстом и комментариями. При этом важно представлять себе её целиком.

Добрый день, дорогие обитатели Хабра!

Как и следует из названия, данная статья является дополнением к написанной ранее Веб-приложение на Kotlin + Spring Boot + Vue.js, позволяющим усовершенствовать скелет будущего приложения и сделать удобнее работу с ним.

Интро

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

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

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

Привет! Меня зовут Юрий Влад, я Android-разработчик в компании Badoo и принимаю участие в создании библиотеки Reaktive — Reactive Extensions на чистом Kotlin.

В процессе работы мы столкнулись с тем, что в случае с Kotlin Multiplatform continuous integration и continuous delivery требуют дополнительной настройки. Необходимо иметь в распоряжении несколько виртуальных машин на различных операционных системах, чтобы собрать библиотеку полностью. В этой статье я покажу, как настроить continuous delivery для вашей Kotlin Multiplatform библиотеки.

В обсуждении поста «Что на самом деле значит наезд Rambler Group на Nginx и к чему готовиться онлайн-индустрии» разговор зашёл не только о том, кто виноват — но и что делать.

DarkHost Думаю, если бы все айтишники одномоментно, в знак протеста, уволились из рамблера, на этом рамблер бы и закончился.

alekciy Этого не будет, т. к нет профсоюзов.

vlsinitsyn работникам айти нужен профсоюз. И договор коллективный, в котором бы подобные статейки в контракте не имели возможности появится.

EgorKotkin Верно. И фрилансерам тоже.

Атака «Рамблера» на Nginx интернет-отраслью была воспринята как атака на неё саму, её основы, ценности, принципы и будущее — и привела к появлению множества идей, как на неё следует отвечать.

Что примечательно, все эти идеи — бойкот «Рамблера», получасовой блэкаут etc. представляют собой те или иные формы коллективного действия. Даже само массовое возмущение и обсуждение в ответ на эту атаку само по себе является реакцией и формой коллективного действия.

Не так давно я изучал вывод статического анализатора IntelliJ IDEA для Java-кода и наткнулся на интересный случай. Так как соответствующий фрагмент кода не является open source, я его анонимизировал и отвязал от внешних зависимостей. Будем считать, что он выглядел так:

private static List<Integer> process(Map<String, Integer> options, List<String> inputs) {
    List<Integer> res = new ArrayList<>();
    int cur = -1;
    for (String str : inputs) {
        if (str.startsWith("-"))
            if (options.containsKey(str)) {
                if (cur == -1) cur = options.get(str);
            }
            else if (options.containsKey("+" + str)) {
                if (cur == -1) cur = res.isEmpty() ? -1 :
                        res.remove(res.size() - 1);
                if (cur != -1) res.add(cur + str.length());
            }
    }
    return res;
}

Код как код, что-то преобразуется, что-то делается, но статическому анализатору он не понравился. Здесь мы видим целых два предупреждения:

Отображение текстовой информации — наверное, самая базовая и важная часть многих Android-приложений. В данной статье пойдет речь о TextView. Каждый разработчик, начиная с «Hello World», постоянно сталкивается с этим элементом пользовательского интерфейса. Периодически в работе с текстом приходится задумываться о реализации различных дизайнерских решений или улучшении производительности при отрисовке экрана.

Я расскажу об устройстве TextView и некоторых тонкостях работы с ним. Основные советы были взяты из докладов прошедших Google I/O.

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

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

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

Будущий «отец» советской космонавтики Сергей Королёв — по центру. Страсть к авиации у него зародилась в юности, когда он записался в планерный кружок. На его долю ещё выпадут тяжёлые испытания, но юношеский запал у него останется на всю жизнь.

«Можно сделать быстро, но плохо, а можно — медленно, но хорошо. Через некоторое время все забудут, что было быстро, но будут помнить, что было плохо. И наоборот.»
Сергей Королёв, конструктор

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

Современное железо и компиляторы готовы перевернуть с ног на голову наш код, лишь бы он работал быстрее. А их производители тщательно скрывают свою внутреннюю кухню. И все прекрасно, пока код выполняется в одном потоке.

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

Но все уже осознали, ведь жить с этим как-то надо. А Java программисты даже неплохо живут. Потому что в Java есть модель памяти — Java Memory Model (JMM), которая предоставляет достаточно простые правила для написания корректного многопоточного кода.

И правил этих достаточно для большинства программ. Если вы их не знаете, но пишите или хотите писать многопоточные программы на Java, то лучше как можно скорее ознакомиться с ними. А если знаете, но вам не хватает контекста или интересно узнать откуда растут ноги у JMM, тогда статья может вам помочь.