Android, iOS, Windows Phone и прочие
Всем привет!
Опен-сорс и почему в российских ПО появляется код из библиотек, расположенных на серверах из недружественных юрисдикций – самая модная тема сезона.
Поэтому Владимир Высоцкий, руководитель по развитию бизнеса продукта Solar appScreener, в этом материале решил напомнить об основных рисках открытого кода и как их можно избежать на этапе разработки вашего продукта.
Привет, Хабр! В России набирает популярность новый подход к созданию пользовательских интерфейсов — Backend Driven UI (BDUI). В нём сервер задаёт структуру и поведение интерфейса, а приложение просто отображает его на экране.
BDUI уже используют в своих приложениях многие коллеги из индустрии. Меня зовут Елена Зеликсон, я старший инженер по тестированию в VK. О том, какие преимущества у этого решения и как его применять, подробнее расскажу в этой статье.
Серия статей с очередным разбором MV* шаблонов, но с интересными деталями
Даже опытные разработчики смогут найти что-то новое для себя
Это вторая статья из серии,
в которой подробно разбираем MVVM
и является ли класс ViewModel от Google, сущностью ViewModel из шаблона
Статья 2: Подробнее про MVVM
- 🔨 Функции обратного вызова (Callback)
- 🛠 Паттерн Наблюдатель (Observer)
- 📜 MVVM (ViewModel)
- 🔨 Привязка данных (Data Binding)
Знакома ли вам ситуация, когда ключевые шаги релиза живут только в головах команды? Когда понять, что именно сейчас происходит с проектом — задача для ясновидящего с магическим шаром и кофейной гущей? Команда iOS-разработки в ПСБ столкнулась с этим и нашла решение.
Привет, Хабр! Я Александр Дровняшин, iOS-разработчик в ПСБ (и ответственный за выпуск приложения на iOS). И сегодня я расскажу, как простые чек-листы в Confluence резко повысили прозрачность нашего релизного процесса и помогли оперативно и просто собирать обратную связь.
Я работал аналитиком в одной из тир-4 команд, которая не могла пройти дальше полуфиналов. Мы выигрывали небольшие турниры, перебирали составы, готовились к матчам… но каждый раз сталкивались с одной и той же проблемой — нехваткой данных или их переизбытком.
Подбирать героев приходилось по ощущениям.
Считать средний винрейт — вручную, с нескольких источников.
Анализировать контрпики, синергию, мобильность, темп — только на глаз.
Это было долго. Неточно. Почти бесполезно.
Каждый день я сталкивался с тем, что данные есть, но нет инструмента, который бы их собрал, обработал и показал бы мне не просто прогноз, а понятное объяснение:
Почему один драфт сильнее другого? На какой минуте начнётся лейт? У кого преимущество в ерли?
И вот однажды я спросил себя: «Почему в 21 веке нет алгоритма, который поможет решить эту задачу?»
Не нашёл ответа. Значит, нужно было сделать самому.
Написал товарищу, который разбирается в коде. Расписал идею, почему она сработает, и почему её ещё никто не сделал. Мы начали. Первая версия была примитивной. Даже смешно сейчас перечитывать те первые сообщения — мы сами тогда не понимали, куда катимся.
Но со временем стало получаться. Очень быстро.
Сегодня DotaDiviner — это мультиплатформенный инструмент анализа драфтов , доступный через Telegram бот, мобильное и десктоп-приложение. Он строит график силы каждой команды поминутно, показывает, когда произойдёт камбек, кто доминирует в ерли, а у кого пик силы придётся на лейт.
А ещё он умеет отправлять автоматические уведомления о матчах, где есть явное преимущество — например, как на PGL Wallachia Season 5, где можно было легко ловить коэффициенты выше 10.
Продолжение под катом.
Если тебе интересно, как всё это работает — добро пожаловать 👇
Привет, Flutter-разработчики! 👋
Я автор телеграм-канал FlutterPulse! Месяц выдался жарким — и не только из-за погоды ☀️ Мы запустили новую рубрику, пересобрали формат пакетов и собрали для вас крутую подборку новостей, гайдов и видео. Поехали! 👇
Серия статей с очередным разбором MV* шаблонов, но с интересными деталями
Даже опытные разработчики смогут найти что-то новое для себя
Это первая статья из серии, которая является подводкой к самому интересному
Вспоминаем что такое MVC и MVP
Статья 1: Введение в MV шаблоны
- 📜 M‑V-подставь_свое
- 📜 MVC (Controller)
- 📜 MVP (Presenter)
- 🛠 Паттерн Команда (Command)
- 📜 MVP (Moxy)
Однажды в разгар рабочего дня я прикрыл глаза — и буквально за секунду провалился в сон. Просто отключился. Через минут 15 проснулся свежий, бодрый, и сразу пошел работать дальше. С тех пор я начал практиковать короткий сон. И это стало одним из трех моих секретов продуктивного дня.
Последние 14 лет я работаю в крупных корпорациях. Так случилось, что за это время сменил много ролей, должностей и даже локаций. И на каждой позиции я в той или иной мере вовлекался, участвовал или полностью управлял проектами.
Казалось бы, логично будет рассказать о кейсах успешных запусков, побед и какие инструменты мне пригодились (об этом я, кстати, писал). Но правда заключается в том, что любой, даже самый успешный проект делал мне, как проджект-менеджеру, больно. Несмотря на весь опыт, инструментарий, сильные команды находились слабые места, в которые злобный проект бил точно, сильно и с максимально разрушительными последствиями.
В этой статье я напишу о 5 способах проекта треснуть тебе так, что будет очень сложно подняться, и попробую рассказать, как этой боли избежать. Всем тем, кто ни разу не ошибался и всегда исключительно успешен и превращает в золото все, до чего дотрагивается, — статья будет нерелевантна, так что не тратьте нервы и силы. Для остальных — смотрим, от чего бывает особенно больно.
Немного предыстории, прежде чем начать — о том, что у меня за проект такой — Talkvio. Уже два года я в свободное от основной работы время разрабатываю свой пет-проект — Talkvio, альтернативу Пикабу, где всё должно быть лампово и плюшево.
Проект уже довольно сильно развился: там есть нейросети для проверки орфографии, автотегов и помощи в формировании контента и заголовков. Есть Android-клиент, а iOS-версия находится в разработке. Реализована похожая система кармы, как на Хабре, есть даже минусы (привет администрации Пикабу), и многое-многое другое.
У нас на ресурсе пользователи больше фокусируются на авторском контенте — всевозможных интересных статьях и т.п., помимо юмористического. То есть казалось, что ничего не предвещает беды.
Забегая вперед, чтобы читателю было интересно, ресурс НЕ использовал Cloudflare.
Рано или поздно любой разработчик мобильных приложений сталкивается с необходимостью внедрения в приложение работы с файлами. В этой статье я хочу рассказать о нашем опыте взаимодействия с файловой системой в рамках разработки приложения «Автоматизированная система управления мобильными бригадами».
Привет, Хабр. Меня зовут Даниил Смирнов. Я руководитель команды Android Core R&D в VK.
Не так давно я уже рассказывал о DeviceHub — инструменте от команды VK для одновременного управления несколькими смартфонами, который позволяет пользователям тестировать мобильные приложения и сайты на фермах, состоящих из сотен гаджетов. Подробнее почитать об этом можно здесь.
Пока менеджеры мечтают о мире, где можно просто шепнуть ChatGPT «сделай мне Uber, но подешевле» — и вуаля, готовый продакшен, разработчики делятся на два лагеря: одни паникуют, другие спокойно встраивают Copilot в рабочий процесс и смеются над его гениальными архитектурными решениями.
Но давайте будем честны: если бы ИИ действительно мог заменить разработчиков, мы бы уже жили в утопии, где техдолг исправляется одним кликом, баги фиксятся до того, как попадают на прод, а документация пишется без привычных «TODO: исправить позже».
Я Илья Некрасов, Android Team Lead KODE. В этой статье предлагаю разобраться, почему бизнес так любит идею «разработки без разработчиков» и почему она не работает.
Привет, Хабр! Это Вадим из команды AvitoTech. Весной мы собрали в московском офисе более сотни разработчиков, чтобы обсудить самые актуальные для Go-комьюнити темы: начиная со сложностей при переходе на язык Go и заканчивая извечным вопросом о пользе хард- и софт-скиллов. Выбрали девять самых «горячих» тем, поговорили с модераторами соответствующих дискуссий дринкапа, выделили главное и принесли вам в этой статье. Призываем ваши мнения в комментарии!
Дело было в Питере ― я шел по брусчатке и оступился. Чтобы сохранить лицо, я пожертвовал руками. Ну и как теперь жить и работать? ― спросите вы. Рассказываю. Спойлер: больничный я не брал.
Продолжаем погружение в мир функционального программирования! Тема новой статьи — функциональные типы данных и их структуры. Из неё вы узнаете о принципе неизменности данных, о понятии State Machine и о способах его применения в программировании.
А ещё мы исследуем функциональную библиотеку Kotlin Arrow, обсудим поддержку Null, поток данных и функциональную обработку ошибок, а также начнём проектировать Data и Domain слои демонстрационного приложения. В общем, скучать не придётся!
Если вы хоть раз вбивали в Google или Яндекс что-то вроде «куда сходить в Москве», «необычные маршруты по городу» или «экскурсии без гида», то вы знаете — в ответ чаще всего всплывает список из пяти переоценённых мест и пары скопированных текстов из TripAdvisor.
Я проверила десятки сервисов — от стандартных туристических агрегаторов до приложений с «альтернативными» маршрутами. Но везде натыкалась на одно и то же: коммерческие рекомендации, переписанные друг у друга списки "топ-10 мест" и полное отсутствие настоящей городской атмосферы.
А что, если маршрут по городу можно было бы придумать самому — не просто накидав точки, а собрав историю? С фото, видео, аудио, воспоминаниями, текстами, вайбом. Или, возможно, быстро открыть такой маршрут от коренного жителя района и пройтись по самым скрытым и уникальным местам, по-новому взглянув на город?
Всем привет. Меня зовут Татьяна Цикунова. Я системный аналитик в компании МойСклад. В этой статье расскажу о том, как организовать оперативный обмен информацией между участниками проекта и поддерживать документацию в актуальном состоянии Отдельное внимание уделю работе с таск‑трекерами — подробно опишу шаблон тикета, который успешно используется в нашей компании. Однако — если вы работаете без трекера задач, например, в ворд‑файлах, суть от этого не меняется ‑такой подход работает и с другими инструментами.
Я документирую системы больше 3 лет, и за это время успела поработать в разных сферах.. Начинала в финтехе, где успела поработать в разных командах. Потом перешла в МойСклад — здесь углубилась в e‑commerce направление. Сейчас вместе с командой делаем интеграции с интернет‑магазинами и маркетплейсами. За годы работы я убедилась, что не существует единого стандарта ведения документации — каждая компания и даже отдельные команды внутри одной организации вырабатывают свои подходы. маркетплейсами. В разных компаниях свой подход к ведению документации, даже в разных командах одной компании бывают разные подходы.
Однажды в МоемСкладе мы задумались: почему бы не начать системно собирать важные данные, которые появляются на разных этапах разработки? Ведь эти сведения могли бы стать отличной основой для обновления документации к реализованному ПО. Так и появились требования и рекомендации по описанию тикета.
Меня зовут Кристина Павлив, я руководитель продукта в МТС: с нуля прорабатывала идею и развиваю приложение МТС Field, которым пользуются наши полевые инженеры.
В техническом блоке МТС около 3 тысяч человек занимаются подключением интернета и обслуживанием абонентов. В какой-то момент, чтобы выполнить свою работу, им нужно было зайти и заполнить данные в шести разных системах. Любое уточнение информации шло через диспетчерский центр, а перенос времени визита к абоненту или поиск новых заявок осуществлялись по звонку руководителю. И это все при разъездном характере работы, когда каждая минута на счету, а к абоненту опоздать никак нельзя!
В прошлом году мы создали одно приложение и закрыли все потребности ребят, работающих «в полях». Это была нетривиальная задача: собрать несколько команд, распределить зоны ответственности и наладить взаимодействие с конечными пользователями. В этом посте я расскажу, почему мы не могли избежать роста числа приложений, как выстраивали общение разработчиков с инженерами и какие дополнительные плюсы можно получить от создания «единого окна».