Как известно, основной проблемой в тестировании является отчетность по прогонам. Некоторые компании собирают данные в отдельном хранилище. Вместо того, чтобы вручную организовывать хранение, было решено сохранять их в Test IT. Такие данные как: исход, время выполнения и количество автоматизированных кейсов позволяют разделить тесты на выборки и дать оценку покрытия автотестами.
Если вам случалось работать над очень крупным Android проектом, с большим количеством модулей, кода, или наоборот не самой удачной декомпозицией на модули и наличием легаси, то вы наверняка знаете что сборка подобного проекта может занимать довольно много времени. К тому же, этапы сборки множатся и усложняются, да и средние размеры проектов серьёзных мобильных приложений продолжают увеличиваться. По моим субъективным ощущениям, с каждым годом среднее время сборки проекта растёт и не похоже что эта тенденция будет меняться.
Бывает довольно обидно, когда в работу поступает задача, решение которой очевидно, фикс проблемы делается за пару минут, но чтобы проверить что всё исправлено нужно переключать ветки, пересобирать проект, потом переключаться обратно и пересобирать исходную ветку. Это может занимать очень много времени. Или бывает так, что находясь “в потоке” нужно что-то быстро проверить, но увидеть вступили ли изменения в силу можно только пересобрав и перезапустив проект, а если что-то пойдёт не по плану, или по каким-то причинам кэш сборки не отработает и проект будет собираться почти "на холодную"? Подобные, казалось бы, мелочи могут занимать огромное количество времени в течение дня, отвлекают, мешают сосредоточиться и продуктивно использовать рабочее время. Особенно много времени тратится если рабочий компьютер далеко не самый производительный, или если вы пользуетесь ноутбуком, не ориентированным на выполнение тяжёлых сборок.
В этой статье я хочу показать вам как можно собирать огромные Android проекты на далеко не самых производительных компьютерах или ноутбуках, утилизируя для этого вычислительные мощности удалённого сервера или отдельного домашнего настольного компьютера, не потеряв при этом ни капли удобства инструментов Android Studio - графического интерфейса, отладчика, и т.д.
Интересующихся приглашаю под кат.
Можно ли после работы менеджером переквалифицироваться в программисты? И, вообще, кем лучше работать: менеджером или программистом? Как лучше строить карьеру в IT? Что при этом важнее: образование или опыт?
По мере продвижения по карьерной лестнице многие программисты проходят путь от джунов до сениоров, далее некоторые из них становятся тим-лидами и техническими руководителями. Среди моих знакомых менеджеров IT-проектов большинство – бывшие программисты. Путь от программиста до руководителя проектов не является из ряда вон выходящим явлением. Но среди моих знакомых программистов нет ни одного, кто, наоборот, стал писать код после того, как несколько лет проработал менеджером проектов. Поэтому свой случай я считаю достаточно неординарным и хочу поделиться опытом такого карьерного шага. Возможно, кого-нибудь это сподвигнет на подобные смелые изменения в собственной карьере.
Привет! Меня зовут Иван, я бэкенд-разработчик-стажёр в KTS.
Недавно я нашел баг в Django, создал тикет с исправлением и его приняли.
В статье расскажу подробнее — над чем работал, в чем была ошибка и почему ее сложно встретить. А также еще про один баг, который по классике оказался фичей.
В этой статье я расскажу, как и для чего, на одном из своих проектов, мы прикрутили новую возможность Next.js – On-Demand ISR (инкрементная статическая регенерация по запросу).
Наверняка многие в детстве задумывались о том, как другие видят красный цвет? Так же, как и я, или иначе? И как это проверить? Поскольку ответов обычно не находилось, вопросы списывались в разряд «кто кого сборет, кит или слон?» и забывались. Лишь те немногие, кто с возрастом добирался до философских книжек, узнавали, что у этой проблемы есть свое название: принцип приватности сознания. Он формулируется просто: ни у кого нет доступа к чужому сознанию. Или еще проще: человеку принципиально не даны ощущения других. Никому недоступно, как другой видит красный цвет, как ощущает вкус селедки, как слышит терцию, как думает и даже как воспринимает формы. Или можно сказать, что зрительно-слухово-обонятельно-эмоционально-мыслительная «картинка», которую я воспринимаю здесь и сейчас, находясь в сознании, дана только мне и больше никому. Она приватна. Доступа к ней нет ни у кого, кроме меня. Чтобы подчеркнуть категоричность этого утверждения, принцип приватности сознания следует усилить, добавив в формулировку эпитет «абсолютный», то есть говорить об абсолютности принципа приватности сознания или о принципе абсолютной приватности.
С обыденной стороны принцип приватности сознания выглядит вполне понятным и даже тривиальным: ну да, кто же, кроме меня, может смотреть моими глазами и слушать моими ушами? Но несмотря на эту тривиальность, с принятием мировоззренческого, философского содержания принципа приватности возникают проблемы. Как это мы живем каждый в своем мире и не можем эти миры сравнить, сопоставить? А как же объективная реальность, которая одна на всех? Что это за солипсизм такой? И конечно же, практически всех (особенно философствующих) дико раздражает уточнение про абсолютность принципа приватности: мол, не может быть ничего абсолютного в нашем мире. Особенно, когда речь идет о таких простых вещах, как вкус селедки и цвет верхней секции светофора. Все относительно, где-то мы видим по-разному, где-то наши ощущения совпадают. И конечно же, чаще совпадают, поскольку мы устроены одинаково и живем в одной на всех объективной реальности.
Лонгрид посвящается любителям CLI в знак солидарности лучшего эмулятора терминала на OS Android, который испытывает «кошмарную» монополию Google.
В данной работе вербализация пойдет о нижеизложенном со всеми остановками:
[+] глубоко настраивать средý (флэшка, виджет, стиль, зеркала и конфиги);
[+] управлять серверами через ssh;
[+] скачивать ролики/отрывки с YouTube;
[+] нарезать видео, создавать gif;
[+] воспроизводить текст/музыку/радио прямо в CLI;
[+] нарезать mp3-бигфайлы (аналогов приложений на Android попросту нет), и склеивать аудиофайлы;
[+] редактировать документы;
[+] проверять орфографию: как текстовых файлов, так и различных статей по url, например, проверка орфографии статей на Habr-e;
[+] генерировать словари различной сложности со скоростью Си;
[+] создавать блок-схемы; графики; облако слов и даже 3D-визуализацию;
[+] заниматься Data Science на Android-мощностях;
[+] тестировать интернет соединение/интерфейс (требуется частично Root);
[+] сниффить/сканировать сети (требуется частично Root);
[+] запускать и управлять TOR-сетью (deleted);
[+] управлять приложениями и процессами в ОС Android (требуется Root);
[+] анализировать память;
[+] защищать любые данные от случайного редактирования/уничтожения (требуется Root);
[+] автоматически шифровать и бэкапить по ночам любые данные в своё облако;
[+] чекать username(s) и e-mail(s);
[+] проводить аудит безопасности (об опасности сердить скрипт-кидди с их любимыми: «сниффить, парсить, брутить, дампить, сканить, фишить»);
[+] работать с электропочтой;
[+] изучать UNIX/shell;
[+] программировать на Android (на выбор пользователя. В Termux портированы несколько интерпретируемых и компилируемых языков программирования);
[+] запускать python/php/npm скрипты в т.ч. в одно касание с рабочего стола;
[+] работать с криптографией, стеганографией и цифровыми подписями;
[+] парсить данные;
[*] и даже запускать GNU-GUI-софт из CLI.
Всем привет! Сегодня мы поговорим об интеграционном тестировании платежного шлюза, но перед этим расскажу немного про нашу команду и наш проект. Мы (ContactPay) — самостоятельный финтех-стартап внутри QIWI, строим высокопроизводительный отказоустойчивый платежный шлюз и соответствуем стандартам безопасности PCI DSS.
Как платежный шлюз мы интегрированы со множеством внешних API, это могут быть и платежные системы, и сторонние сервисы мониторинга, антифрода, KYC (know your customer) и так далее.
Как финтех — работаем с большим количеством финансовых данных, и нам важны и сохранность, и консистентность и безопасность данных. Исходя из требований к нашему продукту у нас есть высокие требования к нашему коду, поэтому мы определили критичные для нашего проекта метрики кода и стараемся поддерживать их на высоком уровне.
Мы стараемся писать корректный код с наименьшим количеством багов. Код должен быть читаемым, самодокументируемым и поддерживаемым. Кроме того, он должен быть безопасным, так как мы финтех и у нас PCI DSS, это накладывает определенные требования к безопасности. А ещё код должен быть тестируемым.
Сегодня мы поговорим о двух метриках — корректность и тестируемость. Одна метрика напрямую влияет на другую, через тестируемость мы добиваемся корректности в том числе, мы проверяем, насколько код ожидаемо работает.
Перед тем как говорить об интеграционном тестировании, нужно понять, какой процесс мы будем тестировать. Рассмотрим сценарий интеграционного тестирования из жизни. Это сценарий выставления счета, на самом деле процесс проходит в несколько этапов, но мы рассмотрим в посте первые две стадии этого сценария.
В этой статье идет речь о том, как выглядит современный фитнес, кардиотренировки, силовые упражнения, популярные "программы" и планирование тренировок с точки зрения программиста. Автор использовал пульсометры для изучения адаптации своей сердечно-сосудистой системы к интервальным и аэробным беговым тренировкам на дорожке с электрическим приводом.
Мои следующие статьи: Игра для тренировки мышц ног и мышц пресса. Прототип приложения для серьезной нагрузки без мучений в игровой форме.
Задачи окружают нас повсюду — и дома, и на работе, и во всяческих аспектах нашей повседневной жизни. У каждого со временем появляются собственные приёмы и методики работы со списками задач. Кто-то предпочитает модные приложения и продвинутые программы, кто-то по старинке всё записывает в бумажный ежедневник. А некоторые вообще не занимаются специальным планированием, но при этом чудесным образом всё успевают.
За долгие годы работы в IT такие методики и принципы выработались и у меня. Например, «Принцип пустого почтового ящика». Или «Принцип постепенного проявления». Они проверены временем и помогают мне успешно ориентироваться в окружающем потоке задач. В этой статье я хочу поделиться с вами этими принципами. Возможно, какие-то из них покажутся вам полезными и пригодятся.
Новшеств довольно много, о некоторых можно сказать кратко, а что-то лучше описать более развёрнуто. Те новшества, которые относятся к облачным хранилищам, мы тут и вовсе опустим ввиду неактуальности на сегодняшний день. Также тут не будет ничего про новый синтаксический «сахар» T-SQL и небольшие улучшения там и сям, типа сжатия XML.
Привет, Хабр!
И мы по-прежнему верим в светлое будущее в то, что в скором времени роботизированные системы будут внедрены повсеместно, помогая человеку в любой сфере. Сегодня один из трендов по делегированию задач искусственному интеллекту – это… сам процесс программирования. Но мы имеем ввиду не те инструменты, коих множество в любой среде разработки, а те, что создаются компаниями под собственные нужды. И это поистине одна из самых увлекательных головоломок, предоставляющая айтишнику возможность наконец-то проявить свою творческую сущность.
Так уж сложилось в нашей компании, что мы не раз создавали собственные автоматизированные системы и программное обеспечение для своих продуктов и сервисов.
А совсем недавно мы запустили собственный AI-генератор скриптов, ну, и решили рассказать вам об этом инструменте, который сокращает ручной труд при создании скриптов для голосовых роботов. Это будет большая статья, как и та работа, которую мы проделали.
На связи VS Robotics. Мы по–прежнему занимаемся машинным обучением и автоматизацией решений на базе речевых технологий.
Всем добрый день!
Ранее я писал об опыте создания новых исследовательских сценариев в мире исследовательского тестирования. Начало вы можете прочитать вот здесь.
Ну что ж, давайте продолжать, ведь мне ещё есть чем с вами поделиться :)
Хабр, привет! Меня зовут Екатерина Герт, я ведущий аналитик и ресурсный менеджер одной из групп аналитиков в КРОК. В этих двух ролях я много работаю с новичками. Как аналитик на уровне проекта знакомлю новичка с проектной командой и спецификой предметной области, а как руководитель погружаю в стандарты и практики работы аналитиков в компании.
За последние 3 года количество аналитиков-новичков, которые приходят к нам в команду, выросло почти в 6 раз. К нам приходят новички разного уровня, от младших до ведущих. У каждого – свой багаж знаний и практический опыт. Важно адаптировать этот опыт и знания к практикам работы, которые приняты компании. Если не заниматься адаптацией, то каждый новичок будет работать так, как он привык. Команда и заказчики будут ожидать совсем другого результата, к которому они тоже привыкли. В итоге – хаос неизбежен.
Помимо общих адаптационных материалов “на компанию” в нашей гильдии аналитиков есть своя программа – набор материалов, практических заданий и система бесед для проверки, насколько хорошо был усвоен материал. К этой системе мы пришли постепенно от стихийного наставничества к программе со своей структурой из теории и практики.
В этом посте хочу показать, как вы можете выстроить свою программу адаптации на примере эволюции нашей адаптационной программы.
Я не художник, но иллюстрации в тексте – мои :)
Фреймворк Angular используется при создании SPA и предлагает большое количество инструментов как для создания, непосредственно, элементов интерфейса, так и CLI для создания и управления структурой файлов, относящихся к приложению.
Для создания проекта с использованием библиотеки Angular, официальный сайт предлагает нам установить пакет angular-cli и далее из консоли запустить определенные команды, которые скачают нужные пакеты, создадут нужные файлы и останется только запустить приложение, однако что если мы не хотим использовать коробочное решение, мы хотим сами создать структуру папок, заполнить ее файлами, подключить нужные библиотеки и собрать, в общем полностью контролировать процесс создания приложения.
Я задался таким вопросом, и, после изучения этого вопроса я собрал это в туториал.
