В конце 2018 года Google, не без помощи Open-Source сообщества, сделал большой подарок для мобильных разработчиков, выпустив первую стабильную версию кросс-платформенного фреймворка для мобильной разработки Flutter.

Однако, при разработке крупных приложений, немного больших, чем одностраничные 'Hello World'ы, разработчики могли столкнуться с проблемой неопределенности. Как стоит писать приложение? Фреймворк достаточно молод, ещё не существует достаточной базы хороших примеров с открытым кодом, основываясь на которых можно было бы понять плюсы и минусы применения различных паттернов, понять что стоит использовать в данном конкрентном случае, а что — нет.

Спасает ситуацию то, что Flutter имеет определенную степень схожести с React и React Native, а значит можно перенять некоторый опыт программирования на последних. Возможно, именно из-за этого появились такие библиотеки, как Flutter Flux, Flutter Hooks, MobX, а также сразу несколько реализаций Redux. Долгое время самой популярной была версия Брайана Игана под названием Flutter Redux.

Тем не менее, пару месяцев назад первый коммит увидела библиотека Fish Redux, опубликованная под именем компании Alibaba. Библиотека за короткое время собрала большую популярность, уже на первом дне обогнав реализацию Брайана по количеству звезд, а на втором опередив её в два раза.

Всем привет! На связи TestMace и мы продолжаем знакомить вас с самыми горячими новостями из мира JavaScript. На очереди перевод статьи о WASI — технологии, которая позволит использовать WebAssembly вне браузеров

Один формат, чтоб править всеми

Компания Mozilla на этой неделе представила проект под названием WASI (WebAssembly System Interface), призванный стандартизировать взаимодействие WebAssembly-кода с операционной системой. Если проект окажется успешным, он будет выполнять те же функции, что и виртуальная машина Oracle Java, но гораздо эффективнее и с расширенным функционалом.

Автор материала, перевод которого мы публикуем, недавно выпустил своё первое мобильное приложение, написанное на React Native. Так случилось, что это приложение стало и его первым проектом, который он создал как программист-фрилансер. Здесь он расскажет о том, с чем ему пришлось столкнуться в ходе работы — от инициализации проекта до его публикации в App Store и Google Play.

Привет, Habr. Меня зовут Илья Смирнов, я Android-разработчик в компании FINCH. Хочу показать вам несколько примеров работы с Unit-тестами, которые мы наработали у себя в команде.

В наших проектах используется два вида Unit-тестов: проверка на соответствие и проверка на вызов. Остановимся на каждом из них более подробно.

Java Challengers #4: Сравнение объектов с equals() и hashCode()

В преддверии запуска нового потока по курсу "Разработчик Java" мы продолжаем перевод серии статей Java Challengers, предыдущие части которых можно прочитать по ссылкам ниже:

• Перегрузка методов в JVM
• Сравнение строк
• Полиформизм и наследование

Поехали!

В этой статье вы узнаете, как связаны между собой методы equals() и hashCode() и как они используются при сравнении объектов.

«Защита» — хороший ярлык для плохих дел.
Милтон Фридман «Свобода выбирать»

Этот текст получился в результате анализа некоторых комментариев к статьям «Дефекты лайков» и «Экономика и права человека».

Интерпретируя какие-либо данные и делая выводы, некоторые комментаторы совершали типичную «ошибку выжившего».

Что такое «систематическая ошибка выжившего»? Это учет известного и пренебрежение неизвестным, но существующим.

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

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

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

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

Статья подготовлена по материалам моего доклада на MBLT DEV 2018, в конце поста — линк на видеозапись.

Последовательный стиль

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

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

Источник [Announcing Dart 2.2: Faster native code, support for set literals]

Сегодня (26 февраля 2019) мы объявляем о выпуске Dart 2.2 SDK — обновления для Dart 2, которое предлагает улучшенную производительность ahead-of-time (AOT) кода и поддержку Set литералов.

О чем пойдет речь?

Посмотрим на метаморфозы редьюсеров в моих Redux/NGRX приложениях за последние пару лет. Начиная с дубового switch-case, продолжая выбором из объекта по ключу и заканчивая классами с декораторами, блекджеком и TypeScript. Постараемся обозреть не только историю этого пути, но и найти какую-нибудь причинно-следственную связь.

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

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

Сейчас уже мало кто пишет на Perl'е, но известная максима Ларри Уолла "Keep simple things easy and hard thing possible" стала общепринятой формулой эффективной технологии. Ее можно трактовать в аспекте не только сложности задач, но и подхода: идеальная технология должна, с одной стороны, позволять быструю разработку средних и малых приложений(в т.ч. "write-only"), с другой — предоставлять инструменты для вдумчивого девелопмента сложных приложений, где на первое место ставиться надежность, поддерживаемость и структурированность. Или даже, переводя в человеческую плоскость: быть доступной для джунов, и в то же время удовлетворять запросы синьйоров.

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

"Вы будто бы храните все столы в одной комнате, а стулья — в другой"
— Юха Паананен, творец библиотеки Bacon.js, о Редаксе

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

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

Сразу скажу: я не считаю, что строить карьеру — это правильно, без этого никак и кто не строит — валенок. При этом я и не считаю, что не строить карьеру — правильно.

В карьере нет ничего плохого или хорошего. Так же, как нет ничего плохого или хорошего в изучении ERP, ремонте своей квартиры или прохождении курса «100 отжиманий». Карьера — это проект с определенной целью, в который человек сознательно вступает, чтобы чего-то получить. Взамен он должен потратить больше ресурсов, чем расходовал до этого — времени, нервов, денег.

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

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

Надеюсь, мы договорились. Возвращаемся к карьере.

В какой-то момент я заметил периодические разговоры о том, как же на самом деле работает ViewModel из гугловых архитектурных компонентов. Осознав, что и сам не понимаю до конца полез в интернеты и с удивлением обнаружил, что есть невероятное количество одинаковых статей о том как готовить ViewModel, дружить ее с LiveData, присунуть ей зависимости через Dagger, совокуплять с RxJava и других тайтлов различной степени полезности, однако нет почти ничего о том, что вообще происходит внутри.

Что это и зачем?

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

Если освоить небольшой список типичных ошибок, возникающих при написании юнит-тестов, то можно даже полюбить писать их. Сегодня руководитель группы разработки Яндекс.Браузера для Android Константин kzaikin Заикин поделится с читателями Хабра своим опытом.


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

^{Дисклеймер: я не связан с Google Play, Chrome или любой упомянутой компанией. Это не официальное заявление. Логотип и названия используются только для иллюстрации.}

В Chrome 72 для Android реализована долгожданная функция Trusted Web Activity. Это означает, что теперь мы можем распространять PWA через каталог Google Play и запускать Chrome без UI в автономном режиме для нативных пакетов! Я некоторое время поигрался с этой функцией, копаясь в API, а здесь расскажу, о чём речь, чего ожидать и что доступно уже сегодня.

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

TL;DR: базовая логика redux помещается в 7 строк JS кода.

О redux вкратце (вольный перевод заголовка на гитхабе):

Redux — библиотека управления состоянием для приложений, написанных на JavaScript.

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

Я склонировал репозиторий redux, открыл в редакторе папку с исходниками (игнорируя docs, examples и прочее) и взялся за ножницы клавишу Delete:

• Удалил все комментарии из кода
  Каждый метод библиотеки задокументирован с помощью JSDoc весьма подробно
  
• Убрал валидацию и логирование ошибок
  В каждом методе жёстко контролируются входные параметры с выведением очень приятных глазу подробных комментариев в консоль
  
• Убрал методы bindActionCreators, subscribe, replaceReducer и observable.
  
  … потому что мог. Ну или потому что поленился писать для них примеры. Но без корнер-кейсов они ещё менее интересны, чем то, что ждёт вас впереди.
  

А теперь давайте разберём то, что осталось

Часть 1. Реактивность и потоки

Данная серия статей посвящена реактивности и ее применению в JS с использованием такой замечательной библиотеки как RxJS.

Серия статей «Основы реактивного программирования с использованием RxJS»:

• Часть 2. Операторы и пайпы
• Часть 3. Higher Order Observables

Для кого эта статья: в основном, здесь я буду объяснять основы, поэтому в первую очередь статья рассчитана на новичков в данной технологии. Вместе с тем надеюсь, что и опытные разработчики смогут почерпнуть для себя что-то новое. Для понимания потребуются знания js(es5/es6).

Мотивация: впервые я столкнулся с RxJS, когда начал работать с angular. Именно тогда у меня возникли сложности с пониманием механизма реактивности. Сложности прибавлял еще тот факт, что на момент начала моей работы большинство статей было посвящено старой версии библиотеки. Пришлось читать много документации, различных мануалов, чтобы хоть что-то понять. И только спустя некоторое время я начал осознавать, как “все устроено”. Чтобы упростить жизнь другим, я решил разложить все по полочкам.

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

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

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

Он убежал по своим гейм-дизайнерским делам, а я — открыл IDE.