Привет, Хабр! Представляю вашему вниманию перевод статьи «Do Flutter apps dream of platform aware widgets?»

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

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

В конкурсах, обычно, любят участвовать не айтишники, а всякие там… Не знаю, как назвать. Активные, короче. Те, кто любил, когда еще учился в школе или институте, участвовать в самодеятельности, кружках и осенних балах. Да, обычно это – женщины (это не stereotyping, а статистика).

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

Но есть у лифтов три неприятные особенности.

Данная статья является конспектом книги "Чистый Код" Роберта Мартина и моим пониманием того, каким Чистый Код должен быть. Тут нет разделов о тестировании, TDD, о том какая должна быть архитектура и т.д. Здесь все только о том, каким должен быть Чистый Код.

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

В этой статье мы поробуем реализовать пользовательский интерфейс, разработанный дизайнером Иваном Парфеновым для студии PLATES.

Привет, Хабр! Представляю вам перевод статьи автора Paulo Sato на тему использования Kotlin Coroutines вместо RxJava в своих Android проектах.

RxJava как базука, большинство приложений не использует и половины её огневой мощи. В статье пойдет речь о том, как заменить её корутинами (сопрограммами) Kotlin.

Я работал с RxJava в течении нескольких лет. Это определенно одна из лучших библиотек для любого Android проекта, которая и сегодня в ударе, особенно, если вы программируете на Java. Если же вы используете Kotlin, то можно сказать, что в городе новый шериф.

Большинство использует RxJava только для того, чтобы контролировать потоки и для предотвращения callback hell (если вы не знаете, что это такое, считайте себя счастливчиком и вот почему). Дело в том, что мы должны иметь ввиду, что реальная мощь RxJava — это реактивное программирование и backpressure. Если вы используете её для контроля асинхронных запросов, вы используете базуку, чтобы убить паука. Она будет делать свою работу, но это перебор.

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

Но… что такое корутины?

Корутин — это способ обработки конкурентных задач в потоке. Поток будет работать пока не остановлен и контекст будет меняться для каждого корутина без создания нового потока.
Корутины в Kotlin всё еще являются эксперементальными, но они вошли в Kotlin 1.3, так что я написал ниже новый класс UseCase (для clean architecture), использующий их. В этом примере, вызов корутин инкапсулирован в одном файле. Таким образом, другие слои не будут зависеть от выполняемых сопрограмм, обеспечивая более разъединенную архитектуру.

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

Цель этой статьи — помочь вам понять Корутины. Просто будьте внимательны при прочтении и у вас всё получится.

Функциональное программирование (ФП) может улучшить ваш подход к написанию кода. Но ФП непросто освоить. Многие статьи и руководства не уделяют внимания таким подробностям, как монады (Monads), аппликативность (Applicative) и т. д., не приводят в качестве иллюстраций практические примеры, которые могли бы помочь нам в повседневном использовании мощных ФП-методик. Я решил исправить это упущение.

Хочу подчеркнуть: в статье сделан упор на том, ЗАЧЕМ нужна фича Х, а не на том, ЧТО такое фича Х.

Вам больше не нужно ставить Log.d() в каждой строке кода!

Что такое Context?

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

В эпоху подрывных технологий и засилья фреймворков.

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

Переведено в Alconost

Модель конечного автомата (finite-state machine, FSM) находит применение в написании кода для самых разных платформ, включая Android. Она позволяет сделать код менее громоздким, неплохо укладывается в парадигму Model-View-Presenter (MVP) и поддаётся несложному тестированию. Разработчик Владислав Кузнецов рассказал на Droid Party, как эта модель помогает в развитии приложения Яндекс.Диск.


— Вначале поговорим по теорию. Думаю, каждый из вас слышал и про MVP, и про стейт-машину, но повторим.

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

— Саш, очевидно, работа не приносит тебе удовольствия, — Слава проговаривал бесспорные вещи. Четвертую неделю вместо работы я мчался на очередной детский турнир по футболу. Когда у тебя трое детей, можно 120% своего времени занять их увлечениями. — У меня есть к тебе предложение. Давай отправим тебя в отпуск на год? Я за это время закрою собой бизнес. Доходы, по-прежнему, пополам. Потом ты вернешься с новыми силами, и, может быть, я на год в отпуск схожу.

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

В последние несколько лет мои переживания по поводу российского рынка ИТ только усиливались. Все началось с кризиса рубля 2014 года (а может, и раньше), и с тех пор меня не покидает ощущение, что многие российские компании, особенно провинциальные, завязали себе глаза, заткнули ватой уши и все еще пытаются сделать вид, что ничего не происходит. Я много общался с разными компаниями, с HR, с разработчиками, и составил список неутешительных тезисов о том, что представляет собой как программистский рынок, так и культура разработки в целом, ведь это вещи взаимосвязанные. По моим субъективным оценкам, эти тезисы справедливы для ~60% российских компаний, хотя, казалось бы, те другие 40% компаний, которые мы знаем и любим, должны были заставить задуматься. Но я очень подозреваю, что это эти 60% просто надеются на русский “авось”, и подвергаются так называемой willful blindness, а иногда и намеренно мутят воду. Итак, по-честному, что же происходит?

Дисклеймер 1. Ни ссылок, ни имен, ни пруфов не будет. Как известно, в Интернете можно найти подтверждение или опровержение любому тезису, поэтому не вижу большого в том смысла, покуда это не диссертация, а мнение. Моя цель — предоставить другую точку зрения, основанную на личностном опыте веры на личном опыте.

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

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

От переводчика: этот текст написан UX-дизайнером из Бразилии. В процессе освоения новой для него профессии автору удалось выучить английский язык практически с нуля. Собственно, сам пост — отличный пример если не нового метода обучения, то способа совмещать работу и учебу.

Немного обо мне: я родился и вырос в Сан-Паулу, Бразилия, где прожил больше 20 лет. В Бразилии мы говорим на португальском, каждый день, в любом месте. Меньше 3% бразильцев бегло говорят на английском.

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

Перевод заметки Шикара Ша с medium.com

Перевод

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

В последнее время многим программистам очень понравилась библиотека для реализации внедрения зависимостей Dagger2. Хотя, как мне кажется, из-за неочевидной работы под капотом и большим семейством аннотаций Dagger долго заходил в комьюнити. И так получается что сейчас куда не глянь многие использую эту библиотеку почти везде. И уже Dependancy Injection становится синонимом этой самой библиотеки. Хотя это всего лишь библиотека. Да, хорошая, не спорю. Статья будет не о свержение Dagger'a с трона короля библиотек DI. А я бы хотел рассказать о другом инструменте для подобных целей — это Koin.

Первоначально опубликовано в /r/freelance на Reddit, но выкладываю здесь для потомков.

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

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

Используй это в качестве основы для расчёта своих тарифов. $90 в час может показаться дорогой альтернативой сотруднику, который получает зарплату $30 в час, но в реальности это эквивалент $90, и расходы прекращаются сразу по окончании проекта.

Если клиент просит 6+ часов в день, ты потратишь 8 часов

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

Основная часть кода большинства современных приложений наверняка была написана ещё во времена Android 4.0. Приложения пережили время ContentProvider, RoboSpice, различных библиотек и архитектурных подходов. Поэтому очень важно иметь архитектуру, которая будет оставаться гибкой не только к функциональным изменениям, но и готова к новым веяниям, технологиям и инструментам.

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

Или как сэкономить 15% и более от бюджета на разработку

Я профессионально работаю с Unreal Engine уже более 9 лет. За это время я освоил множество специальностей и занимал разные должности в разработке игр: от разработчика-«пехотинца» до менеджера больших команд разработчиков игр и даже консультировал инвесторов игровых компаний.

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

Если у игровой компании в Лос-Анджелесе появляется проблема с Unreal Engine 4, которую никто не может решить, в конце концов звонят мне. Я пишу эту статью, чтобы объяснить, почему мне звонят, как избежать необходимости таких звонков, и что я обычно делаю, получив такой звонок.

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