Всем привет, меня зовут Никита, я старший разработчик в компании Озон и работаю над iOS-приложением «Пункт Озон».

«Пункт Озон» — это мобильное приложение для работников и менеджеров пункта выдачи заказов (далее просто ПВЗ). В приложении множество различных разделов для повседневной работы. Самые популярные разделы — это «Приёмка», «Выдача» и «Инвентаризация», что в мобильной, что в web-версии. Именно они помогают выполнить главные задачи работников ПВЗ — принять заказы на баланс и позже выдать их клиентам.

Для скорости работы и защиты от ошибок работники ПВЗ производят эти действия через сканирование штрих-кодов, расположенных на самих заказах или на тарах, в которых они приезжают. Если брать web-версию, то там «все просто»: покупается нормальный/качественный отдельный сканер, подключается к ПК — и проблем, считай, нет. А вот с мобильным приложением дела обстоят немного не так. У смартфона есть только камера, и она явно не проектировалась под задачу «сканируем только штрих-коды». Но с другой стороны, камера делает фотографию, а раз у нас есть фотография, то можно там найти штрих-код. К счастью, Apple и Google предоставляют нам инструментарий для этого.

А раз я iOS-разработчик, то и рассказывать я вам буду о нашем iOS-приложении. И сегодня у нас в меню: 

• с какими проблемами столкнулись пользователи при использовании мобильного сканера, и почему мы стали искать возможность его улучшения;

• сравнение инструментов, которые предлагает Apple;

• технический обзор одного из них;

• история его внедрения в наше приложение и конечные результаты.

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

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

Привет, Хабр!

Я решил посвятить свою первую статью SQL. Вопросы, рассмотренные ниже мне задавали на собеседованиях на позицию python-разработчика. Естественно отвечать правильно получалось не всегда, а если точнее то чаще не правильно, однако проведя N часов в рефлексии я составил перечень ответов, которыми пользуюсь до сих пор.

Данная информация предполагает знание основ языка запросов и я надеюсь, она окажется полезной для разработчиков, которые сейчас активно ищут работу а также, что ты прочитаешь этот текст до конца и добавишь свой вопрос к перечню (ну или поправишь неточности в существующих)

Привет! Меня зовут Сергей, я более 11 лет в тестировании, и успел за это время перепробовать множество разных подходов в QA — начинал простым тестировщиком, затем строил и развивал всевозможные отделы тестирования и автоматизации, а сейчас работаю в QIWI.

В этой серии постов я хочу поговорить с вами про тестирование трех популярных так называемых не-REST-бэкендов. Самое главное для начала — определиться с терминами, договоримся, что везде в тексте, где я упоминаю REST — речь идет именно о REST HTTP-бэкенде. Наверняка многие из вас с ним работали и вообще неплохо знакомы.

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

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

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

Одна из самых старых и самых популярных площадок с деревьями комментариев — это Reddit. Правда, большая часть его пользователей едина в одном: его интерфейс ужасен. Но его API открыто, поэтому на выбор есть множество клиентских приложений, особенно для мобильных телефонов — Joey, Relay, Slide и Boost и другие. Их авторы — как правило, и сами недовольные стандартным интерфейсом Реддита — потратили много времени и сил на поиск удобного интерфейса для комментариев. И большая их часть пришла к очень похожим вариантам дизайна.

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

Инструменты покрытия кода помогают понять, какая часть кодовой базы выполняется (или, как еще говорят, покрывается) при выполнении данного набора тестов. Какое-то время Go поддерживал измерение покрытия кода на уровне пакета, введенное в Go 1.2, она включалась флагом команды go test -cover.

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

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

Двоичные файлы интеграционных тестов создаются командой go build, а не go test, поэтому инструментарий Go до сих пор не предоставлял простого способа сбора профиля покрытия этих тестов.

С версии Go 1.20 программы с инструментированием покрытия можно создавать командой go build -cover, а затем, чтобы расширить область покрытия, передавать эти инструментированные двоичные файлы в интеграционный тест.

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

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

Привет, Хабр! Это команда Eppie. Подробнее о нашем проекте бессерверной электронной почты можно почитать в этом посте.

Мы, параллельно с созданием собственного децентрализованного протокола, интегрируем в клиентское приложение Eppie популярные классические сервисы. Осенью мы познакомились с основателем Proton Энди Йеном и договорились добавить в Eppie возможность подключения почтового ящика ProtonMail. Насколько нам известно, ни один нативный десктопный клиент не умеет авторизоваться на сервере Proton — Eppie будет первым.

В Proton реализована собственная версия протокола SRP (Secure Remote Password). Наш криптограф портировал библиотеку на C#. Если хотите посмотреть код, вот ссылка на репозиторий в GitHub.

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

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

Статей о работе с PostgreSQL и её преимуществах достаточно много, но не всегда из них понятно, как следить за состоянием базы и метриками, влияющими на её оптимальную работу. В статье подробно рассмотрим SQL-запросы, которые помогут вам отслеживать эти показатели и просто могут быть полезны как пользователю.

Материал заботливо подготовлен на основе перевода части книги Go With The Domain, а именно — главы 9 «Чистая архитектура» за авторством Miłosz Smółka.

В этой части говорится о том, как из wtf-кода прийти к чистой архитектуре с помощью сочетания двух идей: разделении портов и адаптеров + ограничении того, как структуры кода ссылаются друг на друга.

Здравствуйте, давно читаю Хабр и все хотел написать кому-нибудь статью, но не знал с чего начать и о чем писать. Но решил что тянуть кота за причинное место. Надо просто взять и написать обзор о чем то что я знаю и что будет просто для начало. Поэтому решил описать алгоритмы сортировки в размере 37 штук. Я понимаю, что на Хабре есть подобные статьи, одна постараюсь их добавить количеством алгоритмов и приведением небольшого числа графиков.

Периодически меня на начальном курсе просят дать "список всех-всех команд с кратким описанием что делает"... Ну прям "всех-всех". И ведь если искать в интернете "такие" справочники существуют - либо про "20-30 команд, но самых важных", либо с неточностями и устаревшей информацией. Так что предлагаю вашему вниманию свою версию такого "краткого" справочника (на 300, 515, 612, 716, 842, 1005,... 1260 команд) с ссылками на wiki-описание и на cheat.sh-примеры наиболее важных команд.

К старту курса по Fullstack-разработке на Python показываем, как работают регулярные выражения, на примере их движка с визуализацией, которую вы видите на КДПВ. Под катом подробности и код.

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

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

В нашем полифункциональном заряднике есть небольшой графический дисплей. Разберём что тут можно подобрать. 

Попытаемся сделать зарядник 300 Вт с КПД 99% из тех деталей которые еще остались в стоках интернет-продавцов. Продумаем архитектуру. Cоздадим схему. Проведем симуляцию в LTSpice и Microcap. Научимся технологии оптимизации в симуляторе. Найдем применение методу Monte Carlo. Посмотрим на трассировку. Попробуем сравнительно новую фишку Altium Designer - PDN Analyzer.