Как себя чувствуют ваши Gradle-сборки? Рассказываем, как проверить их состояние и как «подлечить», чтобы CI работал чётко.
Пользователь
Дикая природа Gradle Task: руководство по выживанию
19 мин
Туториал
Приветствую, Gradle-адепт! В статье тебя ждёт авторский тур по Gradle Task. В маршрут включено хождение по граблям, изучение секретных практик buildscript-тасок, проведение раскопок по deprecated API, а ближе к концу зарядимся силой Custom Gradle Task, попрактикуемся в строительстве билд-кеша и узнаем, кто такой Worker API.
Поздравляю, вы изобрели белую маркерную доску
9 мин
Было у вас такое: придумали что-то гениальное или хотя бы сочинили прикольное название домена, а потом загуглили, а там первые четыре страницы выдачи в ссылках на то, что вы только что изобрели? Пожалуй, у большинства было это «качельное» настроение: вдохновение — разочарование — осознание и продолжение обычной жизни. Такие ситуации кажутся смешными и не особо занимают наше с вами внимание. Между тем, сам факт «изобретения» говорит о том, что у вас есть потребность в этой идее, что вам её не хватает. А ещё это явление довольно распространено среди сотрудников компаний. Под катом — пример с CRM-системой, над которым стоит задуматься.
Культура разработки: как оценивают производительность и эффективность
8 мин
(c)
Практически с появления технологической отрасли в ней велась охота за «Белым китом» — метриками труда разработчиков. Возможно, само желание посчитать KPI программистов родилось из фразы, распространенной в традиционном бизнесе: «Вы не можете планировать, если не можете измерить».
Вслед за сотнями различных KPI, которыми пытались обвесить программистов, появилось множество различных методов анализа рабочих данных — от отслеживания направления взгляда на монитор до Scrum и Kanban. Измерения качества труда настолько хорошо работали во многих отраслях, что казалось вполне логичным перенести данный опыт на разработку программного обеспечения. Результат оказался обескураживающим.
Измерения и управление продуктивностью разработчиков не привели к появлению единого международного стандарта качества. Высокотехнологичные IT-компании разрабатывают собственные метрики… отдельные из них практически невозможно сравнить с традиционными KPI в других сферах деятельности.
В этой статье расскажем о самых интересных действующих метриках и о «метриках» в IT.
Никто (почти) не знает, что такое авторизация
5 мин
За время работы архитектором в проектах внедрения IdM я проанализировал десятки реализаций механизмов авторизации как во внутренних решениях компаний, так и в коммерческих продуктах, и могу утверждать, что практически везде при наличии относительно сложных требований они сделаны не правильно или, как минимум, не оптимально. Причиной, на мой взгляд, является низкое внимание и заказчика и разработчиков к данному аспекту на начальных этапах и недостаточная оценка влияния требований. Это косвенно подтверждает повсеместное неправильное использование термина: когда я вижу словосочетание «двухфакторная авторизация», у меня начинаются боли чуть ниже спины. Ради интереса мы проанализировали первые 100 статей на Хабре в выдаче по запросу «авторизация», результат получился неутешительный, боли было много:
Что не так с валидацией данных и при чем тут принцип подстановки Лисков?
3 мин
Если вы иногда задаете себе вопрос: «а всё ли хорошо мне в этот метод приходит?» и выбираете между «а вдруг пронесет» и «лучше на всякий случай проверить», то добро пожаловать под кат…
ООП, «святая троица» и SOLID: некоторый минимум знаний о них
43 мин
Необходимое вступление
Я не гарантирую, что изложенные здесь трактовки общепринятых терминов и принципов совпадают с тем, что изложили в солидных научных статьях калифорнийские профессора во второй половине прошлого века. Я не гарантирую, что мои трактовки полностью разделялись или разделяются большинством IT-профессионалов в отрасли или научной среде. Я даже не гарантирую, что мои трактовки помогут вам на собеседовании, хоть и предполагаю, что будут небесполезны.
Но я гарантирую, что если отсутствие всякого понимания заменить моими трактовками и начать их применять, то код вами написанный будет проще сопровождать и изменять. Так же я прекрасно понимаю, что в комментариях мной написанное будут яростно дополнять, что позволит выправить совсем уж вопиющие упущения и нестыковки.
Столь малые гарантии поднимают вопросы о причинах, по которым статья пишется. Я считаю, что этим вещам должны учить везде, где учат программированию, вплоть до уроков информатики в школах с углублённым её изучением. Тем не менее, для меня стала пугающе нормальной ситуация, когда я узнаю, что собеседник мой коллега, причём работающий уже не первый год, но про инкапсуляцию «что-то там слышал». Необходимость собрать всё это в одном месте и давать ссылку при возникновении вопросов зрела давно. А тут ещё и мой «pet-project» дал мне изрядно пищи для размышлений.
Тут мне могут возразить, что учить эти вещи в школе рановато, и вообще на ООП свет клином не сошёлся. Во-первых, это смотря как учить. Во-вторых, 70% материала этой статьи применимо не только к ООП. Что я буду отмечать отдельно.
ООП мертво, да здравствует ООП
18 мин
Перевод
Источники вдохновения
Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым ECS-архитектурам. Арас следует привычной схеме (объяснения ниже): показывает примеры ужасного ООП-кода, а затем демонстрирует, что отличным альтернативным решением является реляционная модель (но называет её «ECS», а не реляционной). Я ни в коем случае не критикую Араса — я большой фанат его работ и хвалю его за отличную презентацию! Я выбрал именно его презентацию вместо сотен других постов про ECS из Интернета потому, что он приложил дополнительные усилия и опубликовал git-репозиторий для изучения параллельно с презентацией. В нём содержится небольшая простая «игра», используемая в качестве примера выбора разных архитектурных решений. Этот небольшой проект позволил мне на конкретном материале продемонстрировать свои замечания, так что спасибо, Арас!
Слайды Араса выложены здесь: http://aras-p.info/texts/files/2018Academy — ECS-DoD.pdf, а код находится на github: https://github.com/aras-p/dod-playground.
Я не буду (пока?) анализировать получившуюся ECS-архитектуру из этого доклада, но сосредоточусь на коде «плохого ООП» (похожего на уловку «чучело») из его начала. Я покажу, как бы он выглядел на самом деле, если бы правильно исправили все нарушения принципов OOD (object-oriented design, объектно-ориентированного проектирования).
Спойлер: устранение всех нарушений OOD приводит к улучшениям производительности, аналогичным преобразованиям Араса в ECS, к тому же использует меньше ОЗУ и требует меньше строк кода, чем ECS-версия!
TL;DR: Прежде чем прийти к выводу, что ООП отстой, а ECS рулит, сделайте паузу и изучите OOD (чтобы знать, как правильно использовать ООП), а также разберитесь в реляционной модели (чтобы знать, как правильно применять ECS).
Полезный обзор. 28 книг, которые повлияли на мое мышление, вдохновили или сделали лучше
7 мин
Recovery Mode
Я не люблю читать книжные рейтинги по двум причинам. Во-первых, чаще всего они представляют собой список книг, отобранных неведомым автором по неведомым критериям. Во-вторых, описания книг больше напоминают рекламные тексты издательств, которым сложно верить.
Из-за этого большинство подобных материалов мало полезны, несмотря на то, что могут содержать толковые книги. Мне давно хотелось написать полезный обзор, который не станет навязывать определенные материалы, а позволит читателю выбрать наиболее подходящие.
Еще одна причина, почему тормозят Docker контейнеры
5 мин
Перевод
В последнем посте я рассказывал о Kubernetes, о том, как ThoughtSpot использует его для собственных нужд по поддержке разработки. Сегодня хотелось бы продолжить разговор о короткой, но от того не менее интересной истории отладки, которая произошла совсем недавно. Статья базируется на том, что containerization != virtualization. К тому же наглядно показывается, как контейнеризированные процессы конкурируют за ресурсы даже при оптимальных ограничениях по cgroup и высокой производительности машины.
Как организовать Performance Review в IT-компании: опыт Badoo
19 мин
Привет, Хабр! Меня зовут Алексей Рыбак, я – глава разработки в Badoo. В феврале в нашем московском офисе Badoo проходил Techleads-митап, где я рассказывал про наш процесс Performance Review. Эта статья написана по мотивам моего выступления.
Совместный просмотр Google I/O в офисе Avito
4 мин
17 мая стартует ежегодная конференция, проводимая компанией Google в Калифорнии. Она длится три дня, в течение которых будет проведено множество сессий по технологиям и проектам Google, ориентированных в первую очередь на разработчиков.
Трансляция KeyNote начнется в 20 часов по московскому времени. Если вы не хотите смотреть ее в одиночестве, а готовы сразу обсудить все новости и новинки с коллегами по цеху — приходите на коллективный просмотр к нам в Avito!
А в этом посте мы поделимся основными ожиданиями от конференции и догадками про анонсы новых продуктов.
Escape analysis и скаляризация: Пусть GC отдохнет
16 мин
В этот раз мы решили разнообразить поток технических интервью реальным хардором и подготовили материал на основе доклада Руслана cheremin Черемина (Deutsche Bank) про анализ работы пары Escape Analysis и Scalar Replacement, сделанный им на JPoint 2016 в апреле минувшего года.
Видеозапись доклада перед вами:
А под катом мы выложили полную текстовую расшифровку с отдельными слайдами.
Видеозапись доклада перед вами:
А под катом мы выложили полную текстовую расшифровку с отдельными слайдами.
Логика сознания. Часть 1. Волны в клеточном автомате
7 мин
Начнем разговор о мозге с несколько отвлеченной темы. Поговорим о клеточных автоматах. Клеточный автомат – это дискретная модель, которая описывает регулярную решетку ячеек, возможные состояния ячеек и правила изменений этих состояний. Каждая из ячеек может принимать конечное множество состояний, например, 0 и 1. Для каждой из ячеек определяется окрестность, задающая ее соседей. Состояние соседей и собственное состояние ячейки определяют ее следующее состояние.Наиболее известный клеточный автомат – это игра «Жизнь». Поле в игре «Жизнь» состоит из ячеек. Каждая ячейка имеет восемь соседей. Задается начальная комбинация. Затем начинается смена поколений. Если у занятой ячейки два или три занятых (живых) соседа, то ячейка продолжает жить. Если соседей меньше 2 или больше 3, то ячейка умирает. Когда у пустой ячейки оказывается ровно 3 соседа в ней зарождается жизнь. Задав произвольную начальную комбинацию можно пронаблюдать ее эволюцию.
10 техник, которыми пользуются манипуляторы (и как с ними бороться)
5 мин
Recovery Mode
Перевод
Психопаты — это не только злодеи из ужастиков и поучительных историй с Уолл-стрит. Мы ежедневно встречаемся с ними в офисе, и поначалу они кажутся нам обычными людьми. Одно исследование обнаружило: небольшая, но заметная часть бизнес-лидеров — 3—4% — подходит под клиническое определение психопата. Как защититься при взаимодействии с такими людьми?
Алгоритмы чат бота на базе рекуррентной нейронной сети и расширения языка AIML
5 мин
Recovery Mode
На сегодняшний день остается актуальным создание программ имитирующих общение человека. Простейшей моделью общения является база вопросов и ответов к ним [1]. В данном случае возникает проблема описания базы знаний и реализация программы интерпретатора. Язык разметки базы знаний может включать в себя паттерны вопросов и соответствующие им шаблоны ответов, также предысторию диалогов к ним и название соответствующей темы общения.
Чат бот может выполнять дополнительные функции, например, такие как поиск музыки, картинок, фактов, калькулятор, прогноз погоды, вывод курса валют. Большинство таких функций имеют реализацию в интернете и доступны в качестве внешнего API.
Альтернативным вариантом создания программы виртуального собеседника является использование алгоритмов машинного обучения на базе диалогов общения, именно искусственные нейронные сети. Подходящей моделью ИНС является рекуррентная нейронная сеть, способная хранить, обобщать и прогнозировать различные последовательности. В данной работе в качестве элементов последовательности предлагается использовать индексы соответствующие словам в базе знаний вопросов и ответов.
Чат бот может выполнять дополнительные функции, например, такие как поиск музыки, картинок, фактов, калькулятор, прогноз погоды, вывод курса валют. Большинство таких функций имеют реализацию в интернете и доступны в качестве внешнего API.
Альтернативным вариантом создания программы виртуального собеседника является использование алгоритмов машинного обучения на базе диалогов общения, именно искусственные нейронные сети. Подходящей моделью ИНС является рекуррентная нейронная сеть, способная хранить, обобщать и прогнозировать различные последовательности. В данной работе в качестве элементов последовательности предлагается использовать индексы соответствующие словам в базе знаний вопросов и ответов.
Что такое пространство-время на самом деле?
22 мин
Туториал
Перевод
Перевод поста Стивена Вольфрама "What Is Spacetime, Really?".
Выражаю огромную благодарность Кириллу Гузенко KirillGuzenko за помощь в переводе и подготовке публикации.
Примечание: данный пост Стивена Вольфрама неразрывно связан с теорией клеточных автоматов и других смежных понятий, а также с его книгой A New Kind of Science (Новый вид науки), на которую из этой статьи идёт большое количество ссылок. Пост хорошо иллюстрирует применение программирования в научной сфере, в частности, Стивен показывает (код приводится в книге) множество примеров программирования на языке Wolfram Language в области физики, математики, теории вычислимости, дискретных систем и др.
Содержание
Простая теория всего?
Структура данных Вселенной
Пространство как граф
Может быть, нет ничего, кроме пространства
Что есть время?
Формирование сети
Вывод СТО
Вывод ОТО (Общей теории относительности)
Частицы, квантовая механика и прочее
В поисках вселенной
Ок, покажите мне Вселенную
Заниматься физикой или нет — вот в чем вопрос
Что требуется?
Но пришло ли время?
Сто лет назад Альберт Эйнштейн опубликовал общую теорию относительности — блестящую, элегантную теорию, которая пережила целый век и открыла единственный успешный путь к описанию пространства-времени (пространственно-временного континуума).
Есть много различных моментов в теории, указывающих, что общая теория относительности — не последняя точка в истории о пространстве-времени. И в самом деле, пускай мне нравится ОТО как абстрактная теория, однако я пришел к мысли, что она, возможно, на целый век увела нас от пути познания истинной природы пространства и времени.
Я размышлял об устройстве пространства и времени немногим более сорока лет. В начале, будучи молодым физиком-теоретиком, я просто принимал эйнштейновскую математическую постановку задачи специальной и общей теории относительности, а так же занимался некоторой работой в квантовой теории поля, космологии и других областях, основываясь на ней.
Но около 35 лет назад, отчасти вдохновленный своим опытом в технических областях, я начал более детально исследовать фундаментальные вопросы теоретической науки, с чего и начался мой длинный путь выхода за рамки традиционных математических уравнений и использования вместо них вычислений и программ как основных моделей в науке. Вскоре после этого мне довелось выяснить, что даже очень простые программы могут демонстрировать очень сложное поведение, а затем, спустя годы, я обнаружил, что системы любого вида могут быть представлены в терминах этих программ.
Воодушевившись этим успехом, я стал размышлять, может ли это иметь отношение к важнейшему из научных вопросов — физической теории всего.
Во-первых, такой подход казался не слишком перспективным — хотя бы потому, что модели, которые я изучал (клеточные автоматы), казалось, работали так, что это полностью противоречило всему тому, что я знал из физики. Но где-то в 88-м году — в то время, когда вышла первая версия Mathematica, я начал понимать, что если бы я изменил свои представления о пространстве и времени, возможно, это к чему то бы меня привело.
Чатботы: массовая истерия
5 мин
Bots… Bots everywhere
Heather Rice Photography
Только ленивый сегодня не слышал, что чатботы — это будущее, а мобильные приложения скоро вымрут как динозавры. Все IT-издания возвещают о новой эпохе, а открытие магазина ботов для FB-мессенджера вообще обещало стать «самым значимым событием после открытия App Store». Похоже, пока не стало.
СМИ настолько убедительны, что невольно начинаешь задумываться о том, что надо бы уже отвыкать от красивого дизайна и полностью перемещаться в текстовую среду, где, конечно же, и одежду купить, и к доктору записаться, и деньги на другую карточку перевести будет гораздо проще.
Терзают меня смутные сомнения: почему же нажимать кнопочки в телеграме или тем более вводить "/show menu", "/choose pepperoni" — это удобнее, чем пользоваться сайтами? Понятно, что со временем платформы будут давать больше возможностей, появятся даже какие-то зачатки дизайна, но действительно ли боты убьют приложения?
Напомню, что мобильные приложения уже убили вебсайты, которые, в свою очередь, убили печатные издания, которые убили живое общение, которое убило наскальную живопись. Так почему же все убитые до сих пор так и не убились?
Разбираемся с многопоточностью в RxJava
10 мин
Когда описывают преимущества RxJava, всегда упоминают об удобстве организации работы многопоточного приложения средствами RxJava. То, как использовать операторы subscribeOn и observeOn, можно прочитать практически в каждой статье, посвященной основам RxJava. Например, здесь хорошо описаны случаи, когда использовать методы subscribeOn и когда observeOn. Однако, на практике часто приходится сталкиваться с проблемами, для которых нужно более глубокое понимание того, что именно делают методы subscribeOn и observeOn. В этой статье я хотел бы рассмотреть ряд вопросов, которые иногда возникают при использовании этих операторов.
Создание архитектуры программы или как проектировать табуретку
25 мин
Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.
К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».
Хотелось разобраться, что вообще в себя включает процесс создания архитектуры программы, какие задачи при этом решаются, какие критерии используются (чтобы правила и принципы перестали быть всего лишь догмами, а стали бы понятны их логика и назначение). Тогда будет понятнее и какие инструменты лучше использовать в том или ином случае.
Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.
К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».
Хотелось разобраться, что вообще в себя включает процесс создания архитектуры программы, какие задачи при этом решаются, какие критерии используются (чтобы правила и принципы перестали быть всего лишь догмами, а стали бы понятны их логика и назначение). Тогда будет понятнее и какие инструменты лучше использовать в том или ином случае.
Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.