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

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

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

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

Всем привет! Я тот самый человек, который учится на бакалавриате по направлению "Экология и природопользование" в обычном Российском ВУЗе. И будучи человеком, которому трудно утолить жажду знаний, мне приходится часто себя ловить на мыслях об улучшении и оптимизации многих процессов, в том числе и в образовании. В целом, образовательная программа моего ВУЗа достаточно неплоха, и мы получаем от преподавателей (конечно же, не от всех) информацию из научных кругов, говорим о инновационных исследованиях и приборах, которые дают новый толчок в изучении такой многокомпонентной науки как экология.

Я думаю, не трудно догадаться, что в современных реалиях все завязано на IT, в том числе и экология. Все меньше становится природных процессов, в которых не используются информационные технологии. Честно, даже затрудняюсь привести такой пример. И вот тут возникает реальная проблема подготовки квалифицированных кадров, которые должны отвечать современным требованиям. И я тут даже не про работодателей, а про жизнь – обычную человеческую бытовуху. Мир меняется бешенными темпами — это факт. Природные процессы меняются, как и мы с вами – также стремительно и безвозвратно. Научное сообщество даже не сразу успевает эти изменения детектировать и осмыслять, поэтому вопрос поиска и подготовки специалистов на стыке нескольких наук не менее актуальная проблема чем изменение климата.

С вашего позволения я попытаюсь рассмотреть некоторые проблемы и пути решения подготовки айтишников-экологов/экологов-айтишников, а также ответить на вопрос как IT-специалисты-экологи спасут планету.

Мне кажется, я нашел самое правильное применение генеративных сетей, рисующих по описанию. Это генерация раскрасок! 

У меня есть дети. Дети равно раскраски. Раскраски - это постоянный поиск всякой фигни, типа “хочу чтобы был единорог, а рядом его малыш панда, и чтобы малыш был похож на маму”. Интересно, что нейросети неплохо справляются с такими задачами. Причем, забавный момент - результаты начинающих нейросетей, типа того же Кандинского, принимаются более благосклонно, потому что рисуют они пока плохо. Но! эта “плохость” и ошибки в изображениях очень похожи на рисунки ребенка и воспринимается за творение собрата по детсаду/школе.

Привет! Меня зовут Игорь, я управляющий партнёр и системный архитектор в KTS.

В этой статье, подготовленной по мотивам моего доклада в «Школе мониторинга» Slurm, хочу поделиться своим набором best practice «Как лучше всего настроить Grafana Loki для сбора логов в инфраструктуре». 

На мой взгляд, порог входа в систему достаточно низкий, и в Интернете много туториалов. Поэтому я расскажу о более сложных и не совсем очевидных вещах, с которыми не раз сталкивался при работе с Grafana Loki. 

Обычно я такими непотребствами не занимаюсь и уважаю частную жизнь приложений. Однако на днях мне довелось исследовать одно мобильное приложение написанное индусом в метро под iOS, а затем адаптированное под Android пьяным студентом «в комнате раздумий». Все действия выполнялись с целью дебага и понимания оптимальных условий для работы. Само приложение мы анализировать не будем, но подготовим среду для проведения исследований.

Эта статья не про взлом и даже не исследования безопасности. Этой статьёй я хочу разработчиков клиентских приложений немного углубиться в матчасть передачи данных поверх HTTPS и оценить риски в своих приложениях.

Три месяца назад здесь на Хабре была опубликована статья “Интернет-цензура и обход блокировок: не время расслабляться”, в которой простыми примерами показывалось, что практически все популярные у нас для обхода блокировок VPN- и прокси-протоколы, такие как Wireguard, L2TP/IPSec, и даже SoftEther VPN, SSTP и туннель-через-SSH, могут быть довольно легко детектированы цензорами и заблокированы при должном желании. На фоне слухов о том, что Роскомнадзор активно обменивается опытом блокировок с коллегами из Китая и блокировках популярных VPN-сервисов, у многих людей стали возникать вопросы, что же делать и какие технологии использовать для получения надежного нефильтрованного доступа в глобальный интернет.

Мировым лидером в области интернет-цензуры является Китай, поэтому имеет смысл обратить на технологии, которые разработали энтузиасты из Китая и других стран для борьбы с GFW (“великим китайским файрволом”). Правда, для неподготовленного пользователя это может оказаться нетривиальной задачей: существует огромное количество программ и протоколов с похожими названиями и с разными не всегда совместимыми между собой версиями, огромное количество опций, плагинов, серверов и клиентов для них, хоть какая-то нормальная документация существует нередко только на китайском языке, на английском - куцая и устаревшая, а на русском ее нет вообще.

Поэтому сейчас мы попробуем разобраться, что же это все такое и как это использовать и не сойти с ума.

Привет, меня зовут Емельянов Михаил, я Python-программист и я хотел бы показать вам свой небольшой «проект выходного дня» — Flywheel, микро-платформу для изучения иностранных языков — смесь Duolingo и Anki, программу, которая может помочь вам правильно писать на английском. Flywheel доступен в исходниках, лежит на GitHub.

Как вы, возможно, знаете, обобщенное знание иностранного языка можно разложить на четыре относительно независимые составляющие: чтение, письмо, слушание и говорение. К сожалению, тренировка одной из этих способностей не будет напрямую отражаться на остальных компонентах, поэтому, например, развивая навык чтения, мы достаточно опосредованно влияем на навык письма. Flywheel — «точилка» именно для письменного английского.

Если вы когда-нибудь пользовались Duolingo, то имеете представление о формате, в котором будет идти обучение. Последовательность проста: вот тебе фраза, переведи её на другой язык; программа запомнит, когда ты в последний раз переводил ту или иную фразу и насколько успешно у тебя это получилось; в зависимости от правильности ответа будет определено время, когда тебе нужно задать эту же фразу еще раз. В целом, на мой взгляд, как сам Duolingo, так и используемый им подход — просто гениальны. Но… Есть нюансы, которые несколько портят впечатления от процесса учёбы, и именно для их устранения я и задумал Flywheel.

Среди программистов не утихают споры о том, надо ли знать "алгосики" для реальной работы, или же это просто некий странный ритуал для прохождения воронки собеседований в компании а-ля FAANG (MANGA). У нас в Каруне в разных командах есть разные мнения на этот счёт. Я, например, как тимлид Go-команды считаю, что некую элементарную базу знать точно бы не помешало, но всё же главное, чтоб человек был хороший.

Мнения могут различаться, но одно я знаю точно: разгадывать загадки бывает очень интересно. Я как-то из любопытства прорешивал задачки на hackerrank, и, если для решения простых задач тупо достаточно догадаться отсортировать данные или построить map (даже не надо ничего особо знать), то для некоторых придумать решение довольно проблематично.

Одна из таких задач — нахождение самой длинной общей подпоследовательности (longest common subsequence). Подобный алгоритм используется в реальной жизни, в таких программах как diff. Скажу сразу: я не смог решить задачу самостоятельно за разумное время (т.е. пока не надоело решать) и посмотрел алгоритм в Википедии.

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

Disclaimer: я точно не олимпиадник и не гуру алгоритмов, просто любопытствующий.

В какой ветке вести разработку? Из какой ветки деплоить на PROD? В какой ветке чинить багу, выявленную на IFT? Многие команды закрыли для себя этот вопрос, но для многих он остаётся открытым.

Этот пост не будет содержать каких-то особых ноу-хау и киллер-фич. В нём я расскажу наиболее простую и понятную (лично мне) практику релизных циклов на основе git flow. И постараюсь объяснить каждое своё решение и каждый подход.

Вы просили — мы сделали.

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

Обо всем этом и не только мы написали в нашей первой статье.

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

Вкратце есть база на mssql сервере есть хранимые процедуры. Есть база на postgres. Есть ETL процесс на Apache Air Flow. Запускаем процесс, по окончании в базе postgres появляются процедуры и данные.

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