Привет, Хабр!

Меня зовут Артём Добровинский, я работаю Android-разработчиком в компании FINCH.

Однажды, за парой пинт с коллегой из компании, которая занимается размещением объявлений по продаже комиссованных МИГ'ов и комаров по имени Игорь, мы начали обсуждать статические анализаторы кода в CI (а что еще обсуждать). Прозвучала мысль о том, что их круто использовать — но только после того, как появится уверенность в логической надежности кода. Другими словами, о кодстайле можно думать только после того, как все тесты написаны.

Решил прислушаться к коллеге и задумался о том, как подсчитать масштаб бедствия для подручных приложений. Взгляд пал на Sonarqube и Jacoco. Процесс их подключения для hello-world проектов элементарен. Подключить их в Android-проект, разбитый на модули — уже сложнее. С целью помочь интересующимся и была написана эта статья.

Привет, Хабр! Меня зовут Артём Добровинский и я Android-разработчик в FINCH.

Однажды, кутаясь в дыму утренней сигары, я изучал исходники одной ORM для Android. Увидев там package под названием benchmarks сразу заглянул туда, и был удивлен тем, что все оценки выполнены с помощью Log.d(System.nanoTime()). Я видел такое не в первый раз. Если быть честнее, я видел даже бенчмарки, сделанные с помощью System.currentTimeMillis(). Обрушившееся осознание того, что что-то надо менять, заставило отставить в сторону бокал с виски и сесть за клавиатуру.

В популярном сериале «Рик и Морти» есть повторяющийся элемент — «Межпространственное ТВ». Это — специальная приставка к телевизору, с помощью которой герои получают доступ к всевозможным телевизионным каналам во всех параллельных вселенных. В нашей — этот прибор, к сожалению, не существует, но интернет позволяет нам наблюдать нечто очень похожее.

Если проанализировать «информационный шум», можно увидеть наш мир с новой точки зрения. И (скорее всего) он вам покажется незнакомым, непредсказуемым и даже немного инопланетным.

Расскажем, как все это осуществить.

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

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

Источник

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

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

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

В 2012 году Нобелевскую премия по экономике выдали Ллойду Шепли и Элвину Роту. «За теорию стабильного распределения и практики устройства рынков». Алексей Савватеев в 2012 году попытался просто и понятно рассказать в чем суть заслуг математиков. Предлагаю вашему вниманию конспект видеолекции.


Сегодня будет теоретическая лекция. Про эксперименты Эла Рота, в частности с донорством, я не буду рассказывать.

Когда объявили, что Ллойд Шепли (1923-2016) получил нобелевку, был стандартный вопрос: «Как!? Он ещё жив!?!?» Самый знаменитый его результат был получен в 1953 году.

Формально, премию дали за другое. За работу 1962 года за «теорему об устойчивом бракосочетании»: «Приём в колледжи и стабильность брака» (College Admission and the Stability of Marriage).

Об устойчивом бракосочетании

Matching (мэтчинг) — задача о нахождении соответствия.

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

Какие нужно сделать предпосылки в модели? Что не просто наугад переженить. Делается некий шаг в сторону свободного выбора. Допустим есть мудрый аксакал, который хочет так переженить, чтоб после его смерти не начались разводы. (Развод, это ситуация, когда муж хочет в жены стороннюю женщину больше, чем жену.)

Эта теорема в духе современной экономики. Она исключительно бесчеловечна. Экономика традиционно бесчеловечна. В экономике человек заменен на машину по максимизации прибыли. То что я буду рассказывать — совершенно безумные вещи с точки зрения морали. Не принимайте близко к сердцу.

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

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



Нельзя сказать, что реальным сеньорам известны какие-то секреты профессионального мастерства. Они, скорее, отличаются особой структурой знаний, особым мышлением. И то и другое поддаётся развитию.

Автор материала, перевод которого мы сегодня публикуем, говорит, что хочет рассказать о некоторых признаках, которые помогают отличить настоящего программиста-сеньора от программиста с «сеньорностью».

Привет, Хабр!

Меня зовут Артём Добровинский, я работаю в компании Finch. Предлагаю к прочтению статью одного из отцов библиотеки функционального программирования Arrow о том, как писать полиморфические программы. Часто люди, которые только начинают писать в функциональном стиле, не спешат расставаться со старыми привычками, и на самом деле пишут чуть более изящную императивщину, с DI-контейнерами и наследованием. Идея переиспользования функций вне зависимости от используемых ими типов может подтолкнуть многих думать в правильном направлении.

Enjoy!

Тема переезда в Европу, США или другие приятные регионы мира довольно часто поднимается на Хабре. Я решил собрать в одном месте список онлайн-сервисов, которые будут полезны тем, кто всерьез задумался об иммиграции. На удивление, «живых» и активных стартапов в этой сфере не так и много. Для статьи я отобрал четыре проекта.

Привет, Хабр!

Все любят runtime exceptions. Нет лучшего способа узнать о том, что что-то не было учтено при написании кода. Особенно — если исключения обваливают приложение у миллионов пользователей, и эта новость приходит паническим email'ом с портала аналитики. В субботу утром. Когда ты в загородной поездке.

После подобного всерьез задумываешься о обработке ошибок — и какие же возможности предоставляет нам Kotlin?

Первым на ум приходит try-catch. По мне — отличный вариант, но у него есть две проблемы:

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

Давайте посмотрим во что try-catch превращает код при попытке решения вышеозвученных проблем.

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

Так какого же чёрта моё прекрасное IT превращается в детский сад «Весёлый Програм-Мишка»?

Привет, Хабр! Сегодня я хочу рассказать о том, как писал Telegram-бота, да не простого, а подарочного. Прошу под кат тех, кому эта история кажется забавной, а также тех, кто пытается писать своих Telegram-ботов на Java. Возможно, мой небольшой опыт будет в чем-то полезен.

Привет, Хабр! Представляю вашему вниманию перевод статьи ViewModels and LiveData: Patterns + AntiPatterns автора Jose Alcérreca.

View и ViewModel

Распределение ответственностей

Типичное взаимодействие объектов приложения, построенное с помощью Архитектурных Компонентов:



В идеале ViewModel не должна ничего знать про Android. Это улучшает тестируемость и модульность, снижает кол-во утечек памяти. Основное правило — в Вашей ViewModel не должно быть импортов android.* (за исключением вроде android.arch.*). Это относится и к Presenter.

ViewModel (и Presenter) не должны знать о классах фреймворка Android