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

Мы продолжаем серию статей об автотестах в ОК (материалы по этой теме мы можете почитать здесь, здесь и здесь). И сегодня рассказываем на примере анализа покрытия автотестами API, как с этими задачами справляется команда ОК.

Никогда особо не стремился в большие компании, по душе всегда были небольшие уютные игровые студии, где и "отеческий" нагоняй от лида получить легко, да и самому "парой ласковых" объяснить коллегам где они были не правы можно. Но конечно шальные мысли, а вот если бы в Я..., да какой-нибудь еще фейсгугл попробоваться. Жаль только они не делают игры, но мысль эта таилась на закорках подсознания, периодически напоминая о себе в моменты просмотра объявлений, да после писем рекрутеров на linkedin. Около года назад два моих знакомых, которые давно уже живут на другом континенте, но с кем застали еще распад питерского EA, вдруг объявились на страничке в linkedin, оставили отзывы да отсыпали скилов. Сначала я не придал этому особого значения, мало ли чего там себе люди думают, может просто сеть знакомых обновляют, есть у них там за океаном такая забава. И так получилось, что на эти отзывы сагрились hr-боты большого G..., что и привело в дальнейшем к очень интересному опыту взаимодействия с людьми, знакомством с кухней отбора, этапами собеседования и воронкой "смерти" входа. Осторожнее надо быть со своими желаниями.

Где-то уже на хабре были статьи и про G... и про Я..., такие, что читая описания задачек на собесах, волевым решением на следующее утро начинал решать leetcode. Воли обычно хватало где-то на неделю, а потом рутина боевых задач и митинги затаскивали обратно в уютную берлогу не очень большого игростроя. Почему я решил написать об этом только через год после всех событий? Да банально подмахнул на третьем собеседовании NDA о методах проведения интервью, а когда понял ЧТО подписал - уже было поздно.

Какие основные факторы влияют на перформанс-ревью и твой карьерный рост?

На самом деле, в этом вопросе играют роль два фактора.

Каждый фактор имеет свои аспекты и особенности. Понимая их, ты сможешь достигать своей цели карьерного роста более эффективно, быстрее и без лишнего стресса.

1. Первый фактор: бизнес-модель;

2. Второй фактор: твоя ценность для бизнеса и твоё позиционирование.

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

Кратко о правилах: игроки поочерёдно ставят точки двух цветов в перекрестия линий. Цель — окружить точки соперника замыканием вокруг них непрерывной цепи своих точек.

Статья для тех, кто делает приложения для себя или заказчика. Особенно если вы из horeca.

Сравнили несколько приложений — лидера рынка, на коде и на конструкторе. Поняли, что не у всех продумано юзабилити, из-за чего бизнес может терять прибыль. Поэтому делимся, что можно позаимствовать из приложения Яндекс.Еды.

Котлин очень лаконичный язык, но когда его код компилируется в Java bytecode, то изящные  конструкции kotlin распадаются на развесистые и монструозные конструкции Java. При этом применение аннотаций может сыграть с вами злую шутку.  

Настраиваем свой маленький, домашний и ламповый VPN на основе Shadowsocks (Outline). Нужен Raspberry и настраиваемый wi-fi-роутер. Пошаговая инструкция. Без абонентской платы и аренды VPS.

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

До этого блокировали пока что только коммерческие сервисы VPN. Пока под раздачу попадают протоколы WireGuard и OpenVPN (август 2023) (ссылка на СМИ, выполняющее функции иноагента). Первый очень популярен своей легкостью и быстродействием, быстрой настройкой. К сожалению, у такого трафика на лбу написано «Я — VPN соединение”. Второй протокол уже довольно старый и популярный, но тоже довольно легко обнаруживается РКН. На сегодня РКН только тренируется с блокировками, но похоже, что Shadowsocks пока работает без перебоев. Тем не менее, "эксперты «Роскомсвободы»* также предполагают, что следующим шагом властей может стать блокировка Shadowsocks, нестандартного протокола, созданного для обхода Великого китайского файрволла, и подобных ему инструментов” (ссылка на сайт некоммерческой организации выполняющей функции иностранного агента). Пока до этого протокола еще не добрались, на основе него, а точнее Outline, использующий технологию Shadowsocks, и настроим свой VPN-сервер.

^{*некоммерческая организация выполняющая функции иностранного агента}

Эта статья — заключительная (наконец‑то!) из моего огромного цикла про недетектируемые инструменты для обхода блокировок. В предыдущих публикациях я упоминал, что клиенты и серверы XRay (форк V2Ray) и Sing‑box при использовании протоколов VLESS/VMess/Trojan могут работать через веб‑сокеты и gRPC, что позволяет подключаться к даже заблокированным Роскомнадзором прокси‑серверам через CDN (content delivery или content distribution network) и дает дополнительные преимущества. Сегодня мы поговорим об этом поподробнее.

Всем известно, что pod в Kubernetes может включать в себя несколько контейнеров: для Service Mesh, работы с внешним хранилищем секретов, журналирования и т. д. В итоге это множество вызывает вопросы. Правильно ли использовать столько контейнеров? Как их изолировать от пользовательских приложений? Можно ли вообще исключить дополнительные контейнеры из пользовательских релизов?

Я Максим Чудновский, занимаюсь Synapse Service Mesh в СберТехе. Расскажу, какие есть паттерны применения дополнительных контейнеров в Kubernetes, как они могут помочь в платформенной инженерии, и, самое главное, как полностью автоматизировать процесс управления жизненным циклом таких контейнеров.

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

Во всем латиноамериканском регионе именно Мексика обладает большим потенциалом для развития в сфере информационных технологий. Страна является домом для более чем 4000 компаний, связанных с этой сферой. Данный рынок оценивается более чем в 32 миллиарда долларов. За год сектор растет быстрее, чем экономика в целом, что отражает беспрецедентный спрос на услуги цифровой трансформации. При этом индустрия IT-аутсорсинга в Мексике растет на 10–15% в год. AR, VR, Cognitive AI и IoT — это отрасли с самыми высокими годовыми темпами роста. Благо, крупных заказчиков хоть отбавляй. Вспомним про одного только северного соседа. 

При этом по данным Мексиканской интернет-ассоциации 75,7% населения страны имеют доступ в глобальную паутину. Так что еще есть, куда расти. В основном интернет-пользователи сконцентрированы в мегаполисах, в сельских же регионах только 48% жителей имеют доступ ко всемирной паутине. В этой статье мы расскажем о наиболее примечательных мексиканских IT-компаниях, как о старых, так и о новых.  

Как-то мне написали с Хабра и сказали: Саня, хочешь написать статью про программистов?

Разумеется, я отнёсся к этому скептически. Ладно там девопсины или вайтхэты какие - почитать про них было бы интересно, но вот жизнь программиста... Я сразу вспомнил эти мемы как на КДПВ, которые на самом деле не мемы, а правда.

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

Привет! Сегодня в статье не будет ничего про наши технологии, стэки или процесс разработки, UX или дизайн.

Тем не менее статья всё равно плотно касается мира IT. Она будет полезна всем начальникам, тимлидам, руководителям проектов, которые взаимодействуют с лицами, принимающими решения у заказчика (ЛПР). Я уверен, каждый человек найдёт в ней полезное для себя. Статья позволит лучше понимать других людей и найти ответ на вопрос «Я же говорю всё ясно, почему меня не понимают?».

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

Итак, в part I мы разбирали жизненный цикл homo sapiens, который уже дошел до знания, как обращаться с паролями, умеет их централизованно хранить и теперь ему надо научиться передавать это знание (точнее, менеджер паролей и цифровое завещание) потомкам на тот случай, если его догонит какой-нибудь лев-тигар. Ведь именно передача полезных знаний между поколениями позволяет социуму избегать повторения простых ошибок, например хранить мастер пароль под клавиатурой и верить новостям из телевизора.

Но в начале, надо обсудить еще один способ восстановления доступа к своим данным аутентификации, на самый крайний случай: если потеряны ВСЕ устройства с бэкапами.

Привет! Я Даша, Android-разработчик в команде онлайн кинотеатра PREMIER.

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

Сегодня разберемся, как автоматически опубликовать приложение в Google Play, Huawei App Gallery и Firebase на примере нашего приложения онлайн-кинотеатра PREMIER. Также расскажу, как мы отправляем сборку в Nexus.

На дворе 2023 год, и вот вы и ваша команда наконец решили отказаться от CI-пайплайна, которым вы пользовались, в пользу автономного Jenkins CI. Замечательно! В этой статье мы не будем разглагольствовать о плюсах и минусах использования одних CI-систем в сравнении с другими, а сразу сосредоточимся на том, как настроить полностью функциональную среду Jenkins CI для iOS.

Как ни крути, хардкорные статьи — соль Хабра. Они вдохновляют, обучают, информируют, разъясняют и задают высокую планку уровня публикаций. Их пишут легенды (как по значку в профиле, так и по жизни), известные тимлиды, уверенные мидлы и круто въехавшие в тему джуны (которые порой и не джуны вовсе). Их читают не все. А ещё к ним очень страшно подступиться. Попробуем разобраться, как писать супер сложную статью, чтобы она осталась в анналах истории, Хабра и в закладках самых строгих читателей. 

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

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

Кроме того, что этот протокол еще более устойчив к выявлению, приятным фактом будет и то, что настройка сервера XTLS-Reality гораздо проще, чем описанные ранее варианты - после предыдущих статей я получил довольно много комментариев типа "А что так сложно, нужен домен, нужны сертификаты, и куча всего" - теперь все будет гораздо проще.