User
Я тут набрела на январскую статью основателя Signal app [мессенджер, конфиденциально безопасно оупенсорс].
Если коротко, смысл статьи следующий: ребят, ну хватит писать кипятком от вашего веб3 — это же сказки.
Чтобы нас с вами вразумить, Moxie сделал два dApp (ну все конечно было не совсем так: нет Мокси до нас никакого дела, он это сделал по приколу).
Привет! Мы написали свою систему диплинков на основе кодогенерации. В этой статье поговорим, как мы упростили работу с диплинками и смогли отловить устаревшие, добавили мониторинг и как собрали все диплинки в одной статье в конфлюенсе.
Диплинк — это uri на конкретный ресурс в приложении. Они нужны бизнесу, чтобы упрощать пользовательский опыт. Так вместо нескольких переходов внутри приложения диплинки позволяют направить пользователя на определённый экран в один клик (польза для пользователя) и снимать статистику (польза для бизнеса). Например: на внешней площадке компания разместила баннер, в котором предлагается заказать виртуальную карту, пользователь может кликнуть по баннеру и сразу попасть на экран заказа карты, а бизнес сможет оценить, какая из площадок более эффективна.
Самая большая проблема — это проблема безопасности. Объясню на примере активити, которая открывает веб-страницы. Активити открывается по диплинку, в нём указывается URL в качестве параметра. Один из вариантов атаки — когда злоумышленник может заставить пользователя пройти по диплинку с URL на вредоносный сайт и таким образом провести атаку. Ещё одна из возможных проблем — на некоторых экранах нам нужно валидировать параметры, а это иногда занимает значительную часть активити. Было бы хорошо вынести валидацию в отдельное место.
Ещё у нас бывали случаи, когда маркетинг запускал промо-кампании либо с диплинками, в которых содержались ошибки, либо с устаревшими диплинками, которые уже не поддерживались, и мы могли об этом даже и не узнать. А при заведении новой кампании маркетинг обращался к разработчиками за диплинками и поиск занимал некоторое время. Если разработчик помнил название экрана и диплинк без параметров, то его можно было быстро найти, а если название экрана сразу не вспомнилось, то алгоритм поиска примерно такой: сбилдить проект -> пройти на нужный экран -> посмотреть в логах, какая активити открылась -> пойти в манифест для получения диплинка -> открыть исходных код активити для сбора входных параметров.
Посмотрев на это, мы поняли, что нам нужна единая точка обработки, анализа, мониторинга, и решили выбрать инструмент аннотаций и кодогенерации. Сейчас объявление диплинка у нас выглядит следующим образом.
Я была С++ разработчиком, когда мне предложили стать тимлидом. В моей новой команде были и разработчики, и QA-инженеры. В тестировании я имела поверхностные знания, поэтому долгое время не понимала, как подступиться к задаче по развитию QA-специалистов. Поиск решения занял несколько лет, и в этой статье я поделюсь своим опытом. Надеюсь, она будет полезна для тех тимлидов, которые в тестировании не так хороши, как в программировании.
Писать на С++ игры долго и дорого, но при этом по перфомансу получается хорошо. Но далеко не всё в играх, требовательно к производительности, особенно 2D. Например всякие окошечки не производят тяжелых расчетов внутри. А на больших проектах они могут занимать до 80% всего объема кода. И на С++ есть проблемы на продакшене - если где-то крешится или бажит, приходится перезаливать приложение.
Скрипты - решение всех бед. И код писать проще, и обновлять приложение можно через дозагрузку (да-да, сторы явно запрещают это, но на деле все так делают).
Совсем недавно прикрутил JS к своему движку. Кому интересны подробности - добро пожаловать под кат.
В моей жизни было четыре периода, когда я активно принимал участие в интервьировании людей на работу. В 1998 для своего стартапа в области программ для проектирования микросхем, в 2010-11 для MIPS Technologies (компания среднего размера но престижная в свое время в узком кругу процессоростроителей), в 2019 для Wave Computing (хайповый стартап в хардверном AI) и сейчас для Samsung (на позиции дизайнеров графических процессоров телефонов). Я не собирался писать длинный текст, но пока я пью чай, набросаю несколько тезисов, первое, что приходит в голову:
Про электронные ценники ЭЦ (в английской аббревиатуре ESL – electronic shelf labels) для розничных магазинов пишут и говорят уже с начала 2000-х годов. За четверть века технология удешевилась, усовершенствовалась и сейчас это зрелое решение, которое предлагают несколько поставщиков на рынке.
Привет! Мы в QIWI довольно давно применяем микросервисную архитектуру, но ее понимание не всегда было одинаковым: оно менялось со временем и эволюционировало. Наши первые микросервисы были достаточно большие по объему, но сейчас мы создаем сервисы гораздо меньшего размера с более узкой и ограниченной зоной ответственности.
Часто такой сервис отвечает за конкретную небольшую фичу в нашем продукте (или вообще за часть фичи), или же за часть какого-то большого процесса. Нам такой подход нравится, поскольку микросервисы имеют независимые жизненные и релизные циклы, мы можем релизить фичи независимо друг от друга. Кроме того, различные команды могут работать в рамках одного продукта параллельно над разными фичами, не мешая друг другу и не сталкиваясь лбами. Это даёт нам возможность независимо масштабировать микросервисы и гораздо быстрее проверять гипотезы. В общем, плюсов много.
Сейчас будет «Но», правда?
Но в системе, которая состоит из большого количества маленьких взаимодействующих компонентов, становится критически важным такое качество, как наблюдаемость. Нам нужны как некие высокоуровневые метрики, показатели, чтобы видеть, как система живет в целом, так и для каждого компонента, для каждого нашего микросервиса —нужно видеть его текущие рабочие показатели и получать уведомления, если эти показатели выходят за пределы нормы. Поскольку новые фичи мы делаем часто, то и новые микросервисы мы разрабатываем часто, получилось так, что настройка дашбордов и конфигурация алертов превратились в такую рутину, которая отнимает существенную часть времени. Так что всё это хотелось бы автоматизировать.
К хорошему быстро привыкаешь, причём иногда настолько быстро, что кажется, будто какая-то полезная штука с тобой уже чуть ли не всю жизнь. С дистанционным банковским обслуживанием такая же история: по ощущениям ДБО – это уже чуть ли не стандарт, который обязательно должен быть у всех. Хотя на самом деле эта опция не так давно отметила десятилетие. За все годы развития ДБО постоянно обрастало новыми возможностями: сначала можно было просто оставить заявку на открытие счёта, затем открыть сам счёт, оформить дебетовку (а потом и кредитку). Сейчас так же просто можно оформить ипотеку или взять срочный кредит.
В общем, ДБО – это про удобство и комфорт. Если какой-то банк сейчас начнёт сокращать перечень услуг, доступных дистанционно, то с большой долей вероятности сокращаться начнёт и число его клиентов. Поэтому ДБО должно быть, и быть работоспособным, безопасным, и не глючить.
Отдельно тут можно отметить пандемию, когда в условиях карантина и удалёнки популярность ДБО многократно возросла. Мы в МКБ в это время потихоньку готовили ряд новых возможностей и планировали выкатывать их постепенно, но надо было подстраиваться под новую реальность и форсировать процесс. Сейчас наша система обслуживания клиентов построена так, что человек де-факто может посетить офис МКБ лишь один раз, после чего ему в дистанционном формате будет доступен весь спектр наших банковских услуг. Причём что в мобильных приложениях, что в веб-версии – объём функций практически идентичен.
Но этого поста бы не было, если б на пути ускоренного расширения функциональности мы не встретили его – стремительно растущий набор регрессионных кейсов.
Меня зовут Егор и в этом посте я расскажу, как мы наладили регрессионное тестирование, на примере собственно ДБО, а также одного из важнейших столпов качественного дистанционного обслуживания — нашей CRM.
Уроки английской грамматики застали меня ещё в обычной советской школе, где пионеров учили, что London is the capital of Great Britain, что в первом лице будущего времени следует использовать “shall”, а в остальных лицах используется модальный глагол “will”.
Много позже практика общения сделала для меня очевидным, что советские учебники устарели; “will” используется повсеместно невзирая на лица, а рудимент глагола “shall” способен всего лишь выразить нотку нетерпения в вопросах типа: “Shall we play a game tonight?”
Стоило мне окончательно заменить свой школьный шаблон употребления модальных глаголов “shall” и “will” на клише, отлитое из десятилетий собственной практики, как дивный голос сэра МакКеллена одной-единственной фразой разрушил устоявшийся было стереотип.
Fail2ban — утилита чрезвычайно полезная во многих случаях. Думаю, многие используют её для того, чтобы в автоматическом режиме блокировать особенно назойливых «посетителей». К сожалению, если входящий поток становится слишком большим, fail2ban теряет все свои полезные свойства, потому что разбор лога безнадёжно отстаёт от реальности.
Лог nginx из 100 тысяч строчек fail2ban при самых простых настройках разбирает порядка 45 секунд. Нехитрыми манипуляциями его можно ускорить раз в 6, но этого оказалось недостаточно. Наивная реализация на аналогичного фильтра на Rust уже обеспечила требуемую производительность, но если уж взялся за оптимизацию, то остановиться трудно.
* только необходимую часть функционала
Всем привет, меня зовут Дарья Чернышева, я инженер по обеспечению качества команды RuScanner.
В этом посте я расскажу про процессы на проекте и о том, как мы при помощи специальных отладочных инструментов Android решили проблему со сканированием штрих-кодов в автоматизации.
Подробнее про продукт
RuScanner (RS) — приложение для сканирования маркированных товаров и коробов, в которые эти товары упаковываются. Товары сканируются посредством считывания специальной этикетки КИЗ (CIL), а короба — LPN, зашифрованных в штрихкоды.
Привет! В этом посте мы расскажем, как команда «Спортмастера» проектировала новую корзину сайта и процесс оформления заказа для нашего мобильного приложения.
Сейчас «Спортмастер» находится на этапе омнитрансформации — трансформируется формат взаимодействия с клиентами, сайт и мобильное приложение сразу. Масштаб работ впечатляет, но вначале расскажу о том, над чем сейчас работаю. В список моих задач входит проведение интерфейсных исследований и UX-проектирование. Если говорить проще, главная задача — сделать интерфейс сайта и мобильного приложения легким для использования и интуитивно понятным.
Меня зовут Андрей Кононов, я UX-эксперт Sportmaster Lab, а под катом — наш путь, советы и чеклист из 7 пунктов для тех, кто тоже занимается UX-тестированием.
for i = 1 to n do
for j = 1 to n do
if A[i] < A[j] then
swap A[i] and A[j]
Появилась вчера на Хабре такая вот статья. Когда компания, занимающаяся ИТ-безопасностью заявляет, что spf/dkim/dmarc не работают и существует минимум 18 способов подменить адрес на (вашем!) почтовом сервере, это вызывает озабоченность и желание разобраться в вопросе. Я прочитал оригинальную статью и кратко изложил свое понимание вопроса. Если тема для вас актуальна рекомендую непременно прочитать оригинал.
Правило №1: не бойтесь запускать продукт без машинного обучения.
Машинное обучение — это здорово, но для него требуются данные. Теоретически, можно взять данные из другой задачи и подстроить модель под новый продукт, но она, скорее всего, не справится с базовыми эвристиками. Если вы предполагаете, что машинное обучение придаст вам рост на 100%, то эвристика даст вам 50%.
Сейчас сложно представить себе стабильно работающий сервис, если у вас на должном уровне не налажен мониторинг. Это и постоянно обновляющиеся статусы инфраструктуры, и хороший сбор логов, и возможность вовремя посылать уведомления — в общем, вы знаете.
Меня зовут Юрий, в этом посте я хочу рассказать вам, как мы налаживали мониторинг сервисов в компании и делали так, чтобы к нам не страшно было обратиться с таким запросом.
Как было
Раньше наш мониторинг можно было описать так: куча очень умных людей ожесточенно программируют пробники на очень сложных языках, пытаясь замониторить все, что попадает в поле зрения. Несчастный заказчик, заходящий к ним побеседовать, сначала должен был заполнить десятки разных опросников и файлов, а потом долгое время отходить от услышанных слов вида “SNMP-трапы”, “пробы”, “агенты”.
Затем у нас появился E2E-мониторинг, способный эмулировать некоторые клиентские операции, именно так мы тогда и мониторили работу наших сервисов. Но были и печали: чтобы E2E в принципе начал что-то мониторить, нужно было составить ФТ объемом страниц эдак в 50 А4, а потом потратить несколько месяцев на разработку
Всем привет. Меня зовут Женя, я фулстек-разработчик в команде рекламы ВКонтакте.
В этой статье расскажу про высоконагруженное место в рекламном кабинете ВКонтакте. С похожей ситуацией может столкнуться в своём проекте любой разработчик. Материал будет полезен не только тем, кто занимается бэкендом, но и всем IT-специалистам, стремящимся сделать свои продукты быстрыми и отказоустойчивыми. Спойлер: в статье не будет кода.